Todos los que estamos de una manera u otra vinculados con el desarrollo de software sabemos que hay un enemigo a combatir: la complejidad. El libro que hoy comento es una oda a la simplicidad. Que entendamos las fuentes de la complejidad, sus manifestaciones y las tácticas con las que contamos a la hora de combatirla es la clara motivación que llevo a Roger Sessions.
El libro tiene, a mi modo de ver partes bien diferenciadas, que no necesariamente se corresponder con capítulos determinados.
Hay partes del libro que tratan las matemáticas subyacentes en la complejidad y que ‘prueban’ matemáticamente como las diferentes tácticas que propone para acotar esa complejidad son efectivas. Es la parte más árida del libro, para muchos lectores será prescindible, aunque yo he disfrutado con enormemente con ella. Que nadie piense en formulas matemáticas si no en un tono de divulgación matemática bastante logrado.
Otra parte del libro, lleva al mundo real, mediante fabulas, ejemplos e historias reales la teoría expuesta de manera matemática. La fabulas son en general divertidas y algunas de ellas han inspirado post en este blog: Velocidad de iteración vs Calidad de iteración y Ya, ya… Keep It Simple, Stupid… ¿pero cómo?. De especial interés me ha resultado la explicación que da el autor del enorme fallo de proyecto que se produjo con el sistema informático de la seguridad social del Reino Unido y como lo liga con la complejidad del sistema… aunque mi conclusión tras leer el tema fue que la complejidad estaba en la maraña de subcontrataciones que se transluce… además de en la propia arquitectura.
Otra parte del libro, la dedica el autor a describir de manera formal una metodología, SIP, basada en el concepto de partición (el autor a estas alturas ya ha demostrado que particionar los problemas arquitectónicos es la manera más eficaz de evitar la complejidad) y los principios descritos por las cinco leyes de las particiones:
1ª Ley: Las particiones deben ser verdaderas particiones.
2ª Ley: Las particiones deben ser adecuadas al problema.
3ª Ley: El número de subconjuntos en una partición debe ser adecuado.
4ª Ley: El tamaño de las particiones debe ser aproximadamente igual.
5ª Ley: Las interacciones entre subconjuntos deben ser mínimas y bien definidas.
Nada nuevo bajo el sol, si cambiamos particiones por subsistemas, y elementos por clases, algo que todo desarrollador con experiencia conoce. De hecho, en la última parte del libro, que quizás sea la más importante desde un punto de vista de pura arquitectura del software, el autor desarrolla un método de análisis, sustentado en las leyes anteriores que permite idéntica los elementos y las particiones en una arquitectura de software. Podéis introduciros en las ideas explicadas en el libro leyendo este artículo del autor: A Better Path to Enterprise Architectures.
El merito del autor, es crear una metodología formal para atajar la complejidad en las arquitecturas empresariales. Esto es algo que ningún otro framework arquitectónico anterior, como TOGAF, FEA o Zachman ha logrado. Estos framework no han ido más allá de construir taxonomías para catalogar nuestros artefactos arquitectónicos, pero sin dotarnos de ningún proceso. En el libro también encontraremos una descripción de los frameworks arquitectónicos más comunes. Podéis leer una comparción entre estos frameworks realizada por el autor en A Comparison of the Top Four Enterprise-Architecture Methodologies.
En definitiva, el libro es interesante, pero sin duda no es una obra imprescindible aunque si es interesante y novedosa. Lo que sí es cierto que la aproximación que el autor hace a la arquitectura empresarial es muy original y totalmente agnóstica de la tecnología empleada. Sea el que sea el tipo de arquitectura empresarial que quieras establecer (una intranet corporativa, un sistema de correo, un ERP…) lo expuesto en el libro es de interés. En cualquier caso, si estás interesado en la arquitectura de más alto nivel, en la arquitectura a nivel empresarial, este es un libro que sin duda debes comprar.
¡Feliz lectura!