[tl;dr] Fundamentals of Software Architecture

Dejo algunas notas de mi lectura de Fundamentals of Software Architecture: An Engineering Approach, de Mark Richards y Neal Ford.

Comentario

Ingresé al libro con algunos prejuicios: por mi experiencia personal, tengo cierta desconfianza hacia el rol de Arquitecto de Software separado de los equipos de desarrollo. Especialmente, me asusta la idea de un área de arquitectura separada del área de desarrollo en una organización mediana o grande. No obstante lo cual, sí me parece útil la noción de Arquitectura de Software como actividad. No obstante lo cual, antes de leer el libro (y pese a haber estudiado más o menos los mismos temas en la Facultad), no creo que hubiera podido dar una definición precisa de Arquitectura de Software, que la diferenciara del Diseño de software. Mi noción intuitiva era que la Arquitectura se ocupa de la infraestructura y la interacción entre los componentes de uno o varios sistemas, más que en cómo se implementan esos componentes.

El libro hace un poco más de hincapié del que me gustaría en el título de Arquitecto de Software dentro de una organización. Pero también reconoce y se ocupa de la clase de situaciones con las que tuve malas experiencias: arquitectos que trabajan desde una “torre de marfil”, que toman decisiones estructurales sin involucrar a los desarrolladores, no transmiten la lógica con la que esas decisiones fueron tomadas y no acompañan a los desarrolladores durante su ejecución.

Efectivamente, hay muchas formas en que la relación entre arquitecto y equipo de desarrollo puede funcionar mal. Pero habiendo leído el libro y contrastándolo con mi práctica cotidiana, tengo que admitir que hay un espacio técnico, principalmente en lo que respecta a las relaciones entre equipos y las dependencias entre proyectos, que es difícil de ocupar si no hay alguien con una visión global de la organización, con un conocimiento amplio (antes que profundo) de los problemas concretos que resuelve cada sistema y las características de cada equipo.

No sé si hay libros “clásicos” de arquitectura¹, pero incluso si los hay, es interesante de este el que aporte una visión contemporánea de la actividad. Con esto no me refiero a que incluya patrones o tecnologías “modernos” (e.g. microservices, containers), sino a que considera las reglas de juego tal como las encontramos actualmente en la industria. Por ejemplo, el libro se aleja de la idea de que la arquitectura de un sistema es “la parte que no cambia”, porque hoy en día hasta la infraestructura es dinámica. Por esta misma razón, es probable que este libro no envejezca bien. Tal vez pedirle a un libro de arquitectura que siga siendo válido en cinco o diez años, sea demasiado. Pero ya que Fundamentals of Software Architecture fue publicado este año, vale la pena leerlo.

Notas

Introducción

• El libro empieza por definir la Arquitectura de Software y el rol del Arquitecto de software en una organización.
• La arquitectura de un sistema consiste en su estructura combinada con sus características arquitecturales (sus “-ilidades”), las decisiones de arquitectura y los principios de diseño.
• No hay una división estricta entre Arquitectura y Diseño de software, los dos son parte de un continuo. Lo que es más: una de las tareas del arquitecto es priorizar qué características del sistema se garantizan mediante decisiones estructurales de arquitectura y cuáles se pueden resolver en el diseño.
• Primera ley de la arquitectura de software:

Everything in software is a trade-off.

• Corolario de la primera ley:

If an architect thinks they have discovered something that isn’t a trade-off, more likely they haven’t identified the trade-off yet.

• Segunda ley de la arquitectura de software:

Why is more important than how.

Parte I: Fundamentos

• Los autores empiezan por distinguir profundidad y amplitud del conocimiento técnico. Para el programador es más importante profundizar el conocimiento (e.g. tener gran dominio de una tecnología específica) y para el arquitecto es mejor ampliarlo (e.g. tener un dominio elemental de varias tecnologías alternativas).
• Si dividimos todo el conocimiento posible en “cosas que sé”, “cosas que sé que no sé” y “cosas que no sé que no sé”, el programador se tiene que concentrar en aumentar la cantidad de cosas que sabe; el arquitecto en achicar las cosas que “no sabe que no sabe”.
• Uno de los conceptos fundamentales que introduce el libro es el de características de arquitectura. Se refiere a los requerimientos que debe cumplir el software más allá del “negocio” o “dominio” del problema, a veces llamados requerimientos no funcionales. Son las “-ilidades” del sistema: escalabilidad, disponibilidad, extensibilidad, etc.
• El grueso de la Parte I consiste en definir esas características, inferirlas de los requerimientos de un sistema, y medirlas.
• Se introduce la práctica de Architecture Katas para ejercitar tareas como la identificación de características a partir de los requerimientos de negocio y el diseño de sistemas que posean tales características.

Architects shouldn’t stress too much about discovering the exactly correct set of architecture characteristics —developers can implement functionality in a variety of ways. However, correctly identifying important structural elements may facilitate a simpler or more elegant design. Architects must remember: there is no best design in architecture, only a least worst collection of trade-offs.

Parte II: Estilos de Arquitectura

• Los estilos son a la arquitectura lo que los patrones al diseño: un catálogo de soluciones probadas, con un nombre para reconocerlos. Ejemplos: Layered, Event-Driven, Service-Based, Microservices, etc.
• Como con los patrones de diseño, es más interesante estudiar el razonamiento que los hace emerger y por qué son preferibles en determinados contextos, que memorizar el catálogo.
• Cada estilo de arquitectura favorece determinadas características (y desfavorece otras). Una de las tareas fundamentales del arquitecto, una vez definidos los requerimientos funcionales e identificadas las características de arquitectura deseadas, es elegir un estilo (o una combinación de estilos) que produzca trade-offs aceptables para el sistema.
• Se agrupan los estilos en arquitecturas monolíticas (e.g. Layered) y arquitecturas distribuidas (e.g. Microservices). Se previene sobre las falacias de la computación distribuida antes de elegir unas u otras.

Parte III: Técnicas y Soft-skills

• Una de las cosas que más me atrajo de este libro es que no se limita a cuestiones tecnológicas:

Almost every decision an architect makes will be challenged. Architectural decisions will be challenged by product owners, project managers, and business stakeholders due to increased costs or increased effort (time) involved. Architectural decisions will also be challenged by developers who feel their apporach is better. In either case, the architect must navigate the politics of the company and apply basic negotiation skills to get most decisions approved. This fact can be very frustrating to a software architect, because most decisions made as a developer did not require approval or even a review.

• En esta parte se discuten varias tareas relacionadas con “soft skills” y se sugieren técnicas específicas para resolverlas: registros de decisiones de arquitectura, matrices de riesgo, escalas para medir el nivel de autonomía de los equipos, radares de tecnología, etc.
• Se dedican unos absurdos dos párrafos a explicar la mejor manera de hacer un apretón de manos.
• Más allá de lo inchequeables que sean las técnicas, estos capítulos sirven para formarse una idea de qué clase de responsabilidades debería asumir un arquitecto y cómo adpotar un enfoque pragmático para ejecutarlas.
• En resumidas cuentas, aunque la llamen arquitectura, la actividad se parece bastante a la ingeniería:

A good software architect is one that strives to find an appropriate balance between being pragmatic while still applying imagination and wisdom to solving problems.

Notas

¹ Años atrás me llevé una gran decepción con Patterns of Enterprise Application Architecture, que se ocupa de patrones para implementar un estilo de arquitectura, pero no de la necesidad (o posibilidad) de usar otros estilos.