Table of Contents
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 🙂
¿Cuáles son sus expectativas con respecto a los eventos de arquitectura de software, crees que en 2021 todo será online?
Creo que quizás a finales de 2021 las cosas se equilibrarán de nuevo. Las conferencias seguirán siendo presenciales. Sí que creo que hay que reinventar el trabajo en la oficina para que sólo se mantenga en las reuniones en las que nos tenemos que ver (en persona) y que también hay que acostumbrarse a las pequeñas interacciones online.
¿Qué tendencias de arquitectura de software has observado este año?
La necesidad de prácticas de modelización en colaboración. En lugar de modelar una arquitectura a través de breves conversaciones 1 a 1, lo cual es caro pero más fácil de controlar. Necesitamos modelar nuestro diseño de forma colaborativa y tomar decisiones de diseño hacia una arquitectura sostenible.
¿Crees que las balas de plata existen en la arquitectura del software?
No
¿Cuál es tu opinión sobre la elasticidad frente a la escalabilidad?
No me entretengo con eso 😀
¿Podrías compartir tu opinión sobre los patrones de arquitectura de software?
Los patrones están ahí para la gente que entiende de arquitectura de software. El problema por el que la mayoría de los patrones, como los microservicios, van mal es que la gente sin experiencia los adopta y los implementa por las razones equivocadas de la manera equivocada (con las mejores intenciones). Necesitamos más tutoría y más colaboración y sobre todo ser conscientes de cómo la clasificación impacta en la toma de decisiones de diseño.
¿Qué recomendación darías a las grandes empresas internacionales en materia de arquitectura de software?
Respecto a este tema soy parcial, revisad las prácticas de modelado colaborativo del diseño dirigido por el dominio y el diseño estratégico y cómo se relaciona con la arquitectura empresarial. Recomiendo la página de github de ddd-crew.
¿Qué recomendación le darías a las startups en términos de arquitectura de software?
Empezar a utilizar el mapeo de Wardley para destilar el núcleo de sus modelos y saber en qué centrar sus experimentos.
¿Cuáles son los principales problemas de arquitectura de software?
La clasificación, el sesgo, las polaridades y la toma de decisiones colectivas autocráticas sobre las que tenemos consenso.
Tu viaje de arquitectura: ¿lecciones aprendidas?
Hay tanto conocimiento que perdemos, tantos libros y sabiduría que desconocemos. Busca esa información, mis héroes para eso en este momento son Ruth Malan y Rebecca Wirfs-Brock.
Siéntete libre de compartir cualquier otro pensamiento relacionado con la arquitectura de software.
Hablamos mucho de cultura, busca el conocimiento en el experto. Colabora y toma cursos de Antropología, realmente pueden ayudarte a mapear tu cultura y ayudarte a cambiarla de manera sostenible.
BIO y Contacto
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.
https://twitter.com/kenny_baas
https://www.linkedin.com/in/kenny-baas/
Baasie.com
Se pierden muchos conocimientos al diseñar y crear software: se pierden por el traspaso de manos en un juego telefónico, por una comunicación confusa al no tener un lenguaje compartido, por discutir la complejidad sin visualizarla y por no aprovechar todo el potencial y la sabiduría de la diversidad de las personas. Esos conocimientos perdidos mientras se crea el software repercuten en la sostenibilidad, la calidad y el valor del producto de software. Kenny Baas-Schwegler es un arquitecto sociotécnico. Combina enfoques de TI como el diseño orientado al dominio y la entrega continua y facilita el cambio mediante el uso de prácticas de colaboración visual, el marco Cynefin y la Deep Democracy. Kenny capacita y habilita de forma colaborativa a organizaciones, equipos y grupos de personas para diseñar y construir productos de software de calidad sostenible.
Uno de los principios fundamentales de Kenny es compartir el conocimiento. Lo hace escribiendo un blog en su sitio web baasie.com y ayudando a conservar la herramienta de colaboración visual del libro Leanpub. Además de escribir, también comparte su experiencia en la comunidad de diseño dirigido por el dominio como organizador de Virtual Domain-Driven Design (virtualddd.com) y Domain Driven Design Nederland. Le gusta ser un orador público dando charlas y talleres prácticos en conferencias y meetups.
