Cómo realizar un diagnóstico de Arquitectura de Software

¿Qué es la Arquitectura de Software?

Hoy en día, las tecnologías de la información (IT) están omnipresentes en la estrategia de las organizaciones. Se apoyan en ellas para ganar ventajas competitivas y perfiles como CIO o CTO tienen pesos significativos en los consejos de administración. El Diagnóstico de la Arquitectura de Software evalúa la capacidad de los sistemas IT para soportar los objetivos de negocio. Su atención ha pasado del contexto técnico a extenderse por todos los ámbitos de gestión. Pero ¿Qué queremos decir cuando hablamos de Arquitectura de Software?

La Arquitectura de Software o de Sistemas (vamos a emplear los dos términos indistintamente) es central al desarrollo de software. Así que vas a encontrar corpus documental gigante al respecto. Las definiciones son muy técnicas y llenas de contexto. Creo que una definición sencilla puede ser: El conjunto de piezas con los que está construido un sistema IT y la forma en la que se comunican entre sí para implementar los servicios de la organización. Si, ya sé que “piezas” no suena muy técnico. 

Para entenderlo mejor, déjame hacer un paralelismo con la arquitectura de un edificio. Sus espacios, distribución y atributos (capacidad, versatilidad, cumplimiento de normativas) definen lo bueno que es el edificio para los usos que la compañía le quiere dar. De la misma forma, en el ámbito de los servicios IT, sus componentes (orígenes de datos, servidores de aplicaciones, sistema de monitorización, …), la forma en la que se comunican (canales, protocolos, políticas, …) y sus atributos (capacidad de adaptarse a la demanda, modificabilidad, cumplimiento de estándares, …) nos informan sobre lo conveniente que es para el negocio.

Nota.- Esto es solo un ejemplo. Que me disculpen los miembros de la Architect Registration Board que defiende el uso del término “Architect” en exclusiva en el contexto de la edificación.

Descripción de la Arquitectura de Software

Las características de la arquitectura no siempre son evidentes y, desde luego, no son conocidas por todos los miembros de la organización. La documentación sobre la arquitectura puede ser costosa de mantener y suele estar expresada en un lenguaje muy técnico. Lo que nos va muy bien a los ingenieros para crear una barrera de protección. Pero, en organizaciones ágiles, basadas en equipos autosuficientes y multidisciplinares, esta distancia acaba siendo un gran problema. El objetivo de una descripción de la arquitectura es que toda la organización entienda la situación actual, y las decisiones de negocio y técnicas que están detrás de esa realidad. Con el objetivo de que toda la organización entienda su aplicación y límites.

Para describirla, debes crear visión de la arquitectura actualizada y real. Sin idealizaciones basadas en diagramas y opiniones (mánchate las manos, revisa código y la realidad de producción). Exprésala de forma que puede ser comprendida, en sus aspectos fundamentales (vamos, lo que de verdad importa),  y compartida por equipo técnico y de negocio (prioriza lenguaje natural y abstracciones de alto nivel cuando uses diagramas). Identifícala como los objetivos de negocio clave tienen su soporte (o no!) en las decisiones arquitectónicas y, finalmente, las soluciones técnicas para implementarlas.

¿Cuándo debemos realizar un diagnóstico de la arquitectura de software?

El foco en la arquitectura de software debe ser constante en cualquier proyecto IT. La abordamos desde las primeras iteraciones de desarrollo y nos preocupamos de que sus líneas directrices sean familiares a todos los miembros de la organización. Los equipos realizan diagnósticos de la arquitectura de software como parte normal de su proceso de evaluación y adaptación.  Revisan los atributos clave, sus implementaciones y posibles alternativas. En el caso de equipos Scrum, el Product Owner y el Equipo de Desarrollo hablan de la arquitectura como parte de la retrospectiva, es evolucionada como contenido del Backlog y el mantenimiento de su documentación se incluye en la Definition of Done.

El diagnóstico de la arquitectura de software puede también iniciarse como un proceso ad-hoc, a demanda de un interesado en el sistema (ej. CTO, Product Owner, Development Team). En este artículo, Grady Booch, presenta algunas motivaciones frecuentes. Debajo te dejo algunos ejemplos de momentos en los que deberíamos realizar este ejercicio. Sobre todo en situaciones en los que efectuamos cambios significativos en el negocio o en la plataforma tecnológica de la organización:

• Migración a la nube
• Cambio de Monolito a SOA
• Organización DevOps
• Lanzamiento en nuevos mercados
• Ampliación de servicios

El error es parte del aprendizaje, así que también es común realizar el diagnóstico cuando el sistema tiene problemas concretos conocidos por la organización. En este caso, el análisis tendrá un foco muy concreto, con ejemplos como:

• Elevado coste de mantenimiento o adaptación de los servicios.
• Incumplimiento de normativas.
• Un prolongado time-to-market
• Percepción de baja calidad por los clientes

¿Quién debe realizar el diagnóstico de arquitectura?

Lo puede realizar internamente la organización. Evidentemente, los equipos que han venido trabajando en el sistema son los que mejor lo conocen. Además, tiene la ventaja de que las conclusiones van a emanar de forma natural y son asumidas como propias. El riesgo estará en que el diagnóstico esté condicionado por nuestra vinculación con decisiones pasadas y acabe reflejando el status quo de la organización.

Frecuentemente, recurrimos a una tercera parte que aporte un nuevo enfoque y cierta distancia sobre la historia y las relaciones de influencia establecidas. La llegada de un consultor externo puede percibirse como una amenaza por el equipo. Por ello es importante aclarar los objetivos del diagnóstico e implicar a las personas clave en la elaboración de las conclusiones.

El análisis comienza con una sesión de presentación a interesados. Y, uno de los primeros objetivos consiste, en obtener una definición consensuada sobre el alcance. Cuando iniciamos el diagnóstico para resolver preguntas o problemas concretos, el alcance está relativamente claro. Con proyectos más abiertos, puede necesitar algún refinamiento. En cualquier caso, es importante entender que no todos los interesados sabrán o querrán expresar abiertamente sus expectativas. Hay una labor muy importante de facilitación, comunicación y transparencia para hacer emerger posibles agendas ocultas.  

El diagnóstico debe contar con un patrocinador a un nivel ejecutivo.  De esta forma se asegurará la disponibilidad de los miembros clave del equipo (siempre ocupados) y el acceso a recursos restringidos de la compañía (código fuente, entorno de producción, etc.)

¿Cuál es el objetivo del diagnóstico?

Los sistemas basados en software son construcciones muy complejas, con multitud de interrelaciones y dependencias. Sería irrealista esperar que en una o dos semanas de trabajo (duración típica de un proyecto de diagnóstico) se alcancen conclusiones detalladas sobre un sistema que puede llevar años en evolución. El diagnóstico de la arquitectura de software debe centrarse en sus aspectos menos volátiles y el alcance del mismo de limitarse a uno o dos atributos prioritarios para el negocio. Este es el enfoque que recomendamos en nuestro servicio de Diagnóstico de Arquitectura de Software

La limitación en su duración controla el coste (interno y externo), facilita que nos enfoquemos en generar resultados concretos y adelanta el feedback.

Los componentes más estables de la arquitectura son los más viejos, los que han acumulado durante su vida más dependencias. También lo puedes ver al revés. Los componentes con más dependencias son los más difíciles de modificar (por los cambios en cascada que generan) y, por lo tanto, son los más estables. Sea como sea, están en en el centro de la red de dependencias de la arquitectura y, como tal, son los que tienen mayor peso en sus características. La lógica de negocio y, especialmente, la gestión de entidades maestras, suele jugar este rol central en la arquitectura.

Si nos centramos en aspectos que cambian con facilidad o que, de hecho, deben ser fácilmente modificables sin necesidad de consenso, generará resultados que se volverán rápidamente obsoletos. Un ejemplo son los patrones o frameworks empleados en la construcción de interfaces de usuario. Con esto no quiero minusvalorar, ni mucho menos, estos componentes tecnológicos. Pueden aportan un valor diferencial al servicio y, de hecho, suelen ser objeto de trabajos de diagnóstico específicos. Solo digo que no suelen ser objeto prioritario de un diagnóstico general.

La arquitectura representa las decisiones significativas de diseño que dan forma al sistema, donde significativas se mide por el coste de su modificación.
Grady Booch

Los requerimientos no funcionales suelen ser los marginados de los proyectos IT. Tanto en análisis como en documentación. Frecuentemente, nos centramos en los la funcionalidad del sistema y los atributos se limitan a una WishList del estilo “las interfaces de usuario deben ser fluidas y atractivas”.  Sin embargo, los requerimientos no funcionales, alias, atributos cualitativos, alias, ilities (de usab-ility, deployab-ility, etc), son el principal motor de las decisiones sobre arquitectura.

A la hora de explorarlos puedes usar mapas. Las taxonomías de atributos cualitativos se pueden emplear como referencia y se encuentran fácilmente en Internet (aquí te dejo un ejemplo). Las hay especializadas en aspectos como seguridad o robustez y en ámbitos tecnológicos como operaciones y desarrollo.  Algunos atributos muy habituales son:

• Prestaciones, medida en tiempo de respuesta (mean response time) o capacidad para atender peticiones por segundo (throughput).
• Resistencia, medida en tiempo de medio de recuperación ante errores (Mean Time to Restore).
• Modificabilidad entendida como el tiempo necesario para llevar un nuevo servicio a producción (Change Lead Time), o la tasa de errores tras un cambio (Change Fail Percentage).

¿Cuál es el objetivo del diagnóstico?

El objeto del diagnóstico de la arquitectura de software será identificar los atributos cualitativos de la arquitectura que tiene mayor impacto en el negocio y las decisiones de técnicas que los soportan. Por ejemplo, en organizaciones enfocadas a mercado, la capacidad de reaccionar rápidamente es fundamental. Vemos que la modificabilidad es un atributo clave y el diagnóstico se centrará en los aspectos técnicos que lo facilitan: desacoplamiento, arquitecturas de servicios, test automáticos, independencia de despliegue, etc. Una empresa centrada a la gestión de maestros priorizará la veracidad y coherencia, o el cumplimiento de estándares. Más en general, los atributos de Testabilidad y Facilidad de Despliegue son objeto de especial atención en las organizaciones DevOps y se han demostrado claramente correlacionados con el éxito de las compañías basadas en uso intensivo de IT.

Como ves, las opciones son ilimitadas. Si te limitas a preguntar, todos queremos que nuestros sistemas tengan todas las -ilities: seguro, modificable, interoperable, usable, … Como responsable del análisis tienes que limitar su alcance. Para ello, hay que concretar el significado de los atributos con definiciones claras (implementables y mensurables). Poniendo sobre la mesa la relación coste-beneficio de su análisis. Debe realizar un esfuerzo de facilitación para alcanzar un consenso sobre uno o dos atributos claves para la organización. De otra forma, se corre el riesgo de que la diagnóstico se quede en la superficie y no llegue a conclusiones accionables.

¿Qué resultados genera el Diagnóstico?

El principal objetivo del diagnóstico de la arquitectura de software es generar conocimiento sobre la arquitectura real del sistema y su adecuación a los objetivos de la compañía. Las conclusiones se deben reflejar en documentación que los equipos puedan mantener tras la finalización del proyecto. Aunque su contenido puede variar en función de los objetivos concretos del diagnóstico, es habitual que se genere un informe recogiendo los siguientes puntos:

• Vista de la arquitectura de software: Modelo del estado actual de la arquitectura.
• Puntos sensibles, Riesgos y Fortalezas del sistema. Elementos de la arquitectura que hay que vigilar para mantener los niveles de calidad;  decisiones arquitectónicas que no están claramente definidas o que no soportan convenientemente los atributos de calidad en los niveles esperados y; finalmente diseños que se demuestran como sólidos activos de la solución.
• Acciones Recomendadas. Lista priorizada de oportunidades que pueda llevarse a un plan de acción o roadmap para su desarrollo.

Además de la documentación detallada para los equipos, es común crear un resumen ejecutivo con las conclusiones más relevantes.

En futuros artículos te hablaré sobre ámbitos en la Arquitectura de Sistemas, formas de visualizar la arquitectura y metodologías para su diagnóstico Diagnóstico de Arquitectura.