Equipo de Apiumhub ha entrevistado a Kenny Baas-Schwegler – arquitecto sociotécnico y de diseño orientado al dominio (DDD) en @Xebia. Facilitador del modelado visual y colaborativo utilizando Deep Democracy Domain-Driven Design para entender las tendencias de arquitectura de software.

Entrevista con Kenny Baas-Schwegler: Tendencias de arquitectura de software

¿Qué es para ti la arquitectura de software?

Describo el término arquitectura como lo describió Grady Booch, aprendido de Ruth Malan: «La arquitectura representa las «decisiones» significativas que dan forma a un sistema» y para continuar con esa cita «La arquitectura de software tiene que ver con las decisiones. Los modelos son en gran medida andamios que utilizamos para visualizar, razonar y documentar esas decisiones. El código es el medio por el que manifestamos esas decisiones».

¿Cuáles son las 3 principales habilidades soft que crees que necesitan los arquitectos de software?

Para mí, lo más importante es ser capaz de facilitar eficazmente las sesiones de modelado colaborativo. Y luego se requieren tres habilidades soft principales:

Obtener todas las percepciones y conocimientos del grupo sobre su modelo, siendo conscientes de ello y sabiendo cómo tratar las clasificaciones y los sesgos.

Tratar eficazmente los conflictos que surgen de esas diferentes perspectivas, y saber cómo tomar una decisión enriquecida en la que todos tengan un verdadero consenso con, por ejemplo, el método Lewis, Deep Democracy.

Algunos problemas no pueden ser resueltos y son polarizadores, detectarlos y gestionarlos (por ejemplo, la arquitectura big up-front frente a la arquitectura iterativa) y alejarse del pensamiento de uno o de otro hacia el de ambos.

¿Cuáles son las 3 principales responsabilidades de un arquitecto de software en la empresa?

Hacer que la información fluya y alinear a los equipos y a las personas con el sistema de software que se está construyendo manteniendo una vista de pájaro del sistema sociotécnico de la empresa. Facilitar las decisiones de diseño colaborativo que dan forma a la arquitectura. Ser un traductor entre el plazo de la estrategia del nivel C (varios años) hacia la gestión (año) y los equipos (sprints de 2 semanas) (Créditos: Jabe Bloom)

¿Cuáles son los atributos clave de la arquitectura de software?

Connascencia de nombre Observabilidad Fragilidad

¿Cuáles son las métricas clave de la arquitectura de software?

Cantidad de comunicación entre equipos

Cantidad de cambios de ruptura de la API

Complejidad cilomática

Coherencia

Pensamiento crítico frente a pensamiento sistémico en la arquitectura de software, ¿qué significa para ti?

Para mí se trata de una polaridad, es una cosa y otra para el arquitecto. La clave está en gestionar esa polaridad y, como dice Ruth Malan, pensar en la complejidad dentro de los límites, y pensar en lo que se extiende entre los límites.

¿Cuál es tu opinión acerca de la innovación versus pragmatismo?

De nuevo una polaridad, necesitamos ambas cosas y la clave es gestionar estas polaridades y saber cuándo terminas en la parte negativa de una de las polaridades. Para ello, utilizo la gestión de la polaridad de Barry Johnson.

¿Qué opinas del control intelectual?

En lugar de preocuparnos por el tamaño de algo (microservicios), preocuparnos por lo que podemos manejar en nuestro control intelectual, o como menciona Team topologies: software que cabe en nuestro cerebro, un enfoque de equipo primero.

¿Cuáles son tus ideas sobre el rendimiento y la capacidad de respuesta?

No tengo ninguna por el momento