[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 arquitectura1, 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

Everything in software is a trade-off.

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

Why is more important than how.

Parte I: Fundamentos

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

Parte III: Técnicas y Soft-skills

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.

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

1 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.



15/09/2020 #software #libros #tldr
source | comments

Facundo Olano

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