Sobre la arquitectura software

Puede que en la industria del desarrollo e ingeniería del software, algunos de los conceptos peor tratados (y peor entendidos), sean los de la arquitectura de un proyecto y el papel de un arquitecto software. En esos campos reina la confusión, las concepciones contrarias y una visión, me temo, poco práctica.

Es más, el mismo concepto de arquitectura software es dado a muchas interpretaciones (tantas como la misma evolución de cómo se afrontan proyectos durante las últimas décadas, me atrevería a decir), viniendo a crear aún más debate y falta de consenso claro la poca literatura que existe al respecto y que se centra más en patrones de arquitectura que en el papel real de un arquitecto dentro de una organización, cuando el trabajo de un reputado autor se contradice con el de otro igualmente alabado.

Para empeorarlo más, también se cree ingenuamente (formentado por la errónea cultura de muchas organizaciones), que ser arquitecto software supone un paso adelante en la escalera corporativa (más prestigio, mejor salario, etc.), de ahí el rechazo visceral de muchos desarrolladores a aceptar que venga alguien con un papel así cuando se entiende como una jerarquía tan pronto como perciben que su trabajo estará más o menos condicionado, definido y encorsetado desde la torre de marfil de un arquitecto.

Pero no tiene por qué ser así.

En El Libro Negro del Programador, dedico un capítulo ligero a este asunto sin profundizar (de título "El Mal Entendido Rol de Arquitecto de Software"), sin entrar demasiado en detalles, claro está, porque para mi mala suerte, una parte importante de mi experiencia con arquitectos ha sido más bien un desastre, y no lo digo con ánimo negativo o de devolver ningún agravio, cuando yo mismo he asumido ese papel en los últimos años en los productos que he dirigido y proyectos en los que he estado al frente.

Es un tema, digamos, delicado y controvertido, puesto que no existe una definición formal (te animo a que la busques, pronto te darás cuenta de que hay tantas como opiniones personales). Tanto es así, que en diferentes organizaciones nos podemos encontrar ese rol, pero con responsabilidades totalmente diferentes, cuando no ciertos equipos que se autodenominan ágiles creen que no hace falta cierta visión de arquitectura de los productos y proyectos que diseñan, o bien te encuentras al desarrollador al que han ascendido y por esa razón cree que sus decisiones van a ser mejores que la de sus antiguos compañeros de departamento (vamos, que se le ha subido el tema a la cabeza, quizá porque suena mejor decir que "eres arquitecto" a "soy programador").

Por otra parte, siento decir que se puede ser ágil, y al mismo tiempo, necesitar una arquitectura definida, y no es una contradicción (al menos en los términos que voy a indicar a continuación).

Para enredar más el asunto, antiguas prácticas sobre cómo a afrontaba el desarrollo de software hace unas décadas, siguen persistiendo en el inconsciente colectivo de los denominados arquitectos, me temo. Para muchos, todo lo que habla de arquitectura tiene que estar relacionado con diagramas UML tan espesos como inútiles que poco aclaran y estructuras en las que necesariamente todo el desarrollo debe encajar necesariamente (tan solo recuerdos de dinosaurio sobre cómo se afrontaba el desarrollo de software hace mucho tiempo pero que aún perduran), siendo más un obstáculo que un inconveniente. En otros equipos (lo digo porque me los he cruzado en algún momento de mi carrera profesional), sencillamente ignoran que exista tan siquiera ese concepto: el software de desarrolla de forma monolítica y se despliega como sea y punto (puff...), cuando no se confunde el diseño con la arquitectura, algo también muy habitual.

Puede que precisamente por todo lo anterior, no haya escrito hasta ahora demasiado sobre esto (ni me haya mojado en el asunto, para ser sincero), por suponer un concepto muy dado a la malinterpretación e incluso susceptible de acumular poder en ciertos entornos corporativos; no obstante, voy a hacer a continuación algunas aclaraciones que confío que ayuden un poco a tener una idea más clara de lo que para mí es un arquitecto software y que, afortunadamente, he visto confirmados en autores seguramente con más experiencia que yo (como Simon Brown y George Fairbanks).

El arquitecto software no es un puesto, sino un rol.

Llevo muchos años diriendo equipos de desarrollo, y siempre les digo lo mismo a mis compañeros: no soy el jefe de nadie, tan solo tengo el rol que me corresponde y mi trabajo consiste en ayudar a que el suyo lo hagan lo mejor posible. Del mismo modo, un arquitecto software no se puede parapetar tras un cargo, sino que asume un rol activo con determinadas funciones y responsabilidades. Tanto es así, que no es mejor profesional por tener ese rol que un desarrollador. Otra cosa es cómo se valore dentro de una compañía, pero en mi opinión lo único cuantificable económicamente debe ser la experiencia y el valor de lo que se aporta.

Un buen arquitecto no vive en su torre de marfil, sino que también programa.

El desarrollo de software no es como otras profesiones; no podemos seguir el símil de arquitecto de edificios / aparejador / albañil, etc., puesto que un arquitecto puede no haber tocado un ladrillo en su vida. No obstante, en software, un arquitecto debe haber desarrollado mucho software a lo largo de su carrera, y, además, en cuantos más proyectos diferentes se haya involucrado, mejor aún.

Es más, abandonar tu papel como desarrollador y dedicarse solo a la arquitectura, lo hace alejarse seguramente de ahí donde es bueno, de modo que para mí un buen arquitecto debe seguir implicado necesariamente a nivel de código en el proyecto.

El arquitecto conoce perfectamente el dominio.

El arquitecto debe conocer perfectamente lo que el cliente necesita o el universo del negocio que se va a modelar con el sistema que se pretende construir, ¿de qué modo si no se van a tomar las decisiones de arquitectura más relevantes?

Gestión de riesgos: no siempre hace falta una arquitectura.

La regla es sencilla: cuanto más grande va a ser un proyecto software y más largo su ciclo de vida (años), más necesario es la perspectiva de la arquitectura que se va a seguir.

Un proyecto pequeño no necesita el papel de un arquitecto.

Esto es, hay una relación directa entre la gestión del riesgo, tamaño del proyecto y su proyección a largo plazo.

Se confunde arquitectura de despliegue IT con la arquitectura de un producto/proyecto.

En ciertos entornos, he visto cómo se confundía una cosa con la otra. La arquitectura de un sistema software no es lo mismo que la arquitectura IT de despliegue final del sistema a desarrollar, pero están relacionados, obviamente. Si sabemos que el despliegue se va a realizar en una infraestructura IT cloud, o bien en un único servidor, la arquitectura propuesta puede cambiar.

Una mala arquitectura (o ausencia de ella) puede costar mucho dinero.

Lo he visto: un sistema que tenía que evolucionar pero cuyos desarrolladores trabajaban sin ese horizonte temporal y orden que pudiese proveer una arquitectura correcta para ese proyecto. El resultado era que esa falta de perspectiva (o inexperiencia) más muchos déficits de diseño, se cubría con muchos euros en hardware.

No hay conflicto entre lo ágil y definir una arquitectura al comienzo.

Así es, léelo de nuevo por si esta afirmación a estas alturas te choca. Como siempre me digo a mí mismo, la virtud está en el término medio.

Por alguna razón, quizá por el abuso en tiempos pasados de todo lo que huela a arquitectura, a los equipos que defienden lo ágil dogmáticamente, les parece una aberración plantearla, creyendo erróneamente que ésta emergerá. No se comprende que lo que emerge es, en el mejor caso, el diseño, y que la arquitectura va mucho más allá que definir cajas, trazar líneas e interacciones entre partes funcionales del proyecto, como veremos más adelante.

Algunos puntos del movimiento ágil se han malinterpretado, me temo; desde un punto de vista del concepto de arquitectura como visión y estructura de un sistema software, lo que emerge es el diseño de los componentes o piezas de software que lo componen, no ese marco más general. De nuevo, se pierde la perspectiva cuando uno cree que un proyecto de 10 KLOCs se debe gestionar y debe crecer igual que uno de 100 KLOCs.

La arquitectura consiste también en identificar riesgos.

Un arquitecto guía, documenta, propone, ayuda al resto del equipo, etc., pero también es capaz de identificar los riesgos que pueden presentar ciertas decisiones (elección de tecnología, licencias de terceros, puntos únicos de fallo, etc.).

No es imprescindible UML para documentar una arquitectura.

El abuso de diagramas UML (costosos de hacer, y que con el tiempo demostraban que aportan más bien poco), ha llevado a crear cierta atmósfera en contra de esta forma de modelado (cuando no un modo de justificar el trabajo poco productivo de quienes lo realizan), cuando no se creía que de esos diagramas directamente se sacaban la relación entre clases de una solución, etc. Los que llevamos en esta profesión varias décadas, quizá hayamos vivido esa carga, comprobando que es un enfoque muy poco práctico.

No obstante, no digo que no tengan su utilidad, sino que desde la perspectiva de la visión y estructura de una arquitectura, el propósito es comunicar de la forma más sencilla posible, no necesariamente con páginas y páginas de casos de uso cuyo único propósito no era el de ayudar a los desarrolladores del equipo a comprender lo que había que hacer, sino, me temo, abultar la documentación.

Cualquier diagrama tiene un propósito: comunicar lo que se quiere modelar, y en este contexto, puede que simples diagramas con cajas y líneas, sea más que suficiente (sí, así de sencillo).

La arquitectura se debe indicar de modo simple: el método C4 para modelar.

Contexto, contenedores, componentes y clases. El método C4 es una aproximación sencilla y elocuente con la que modelar prácticamente la arquitectura de cualquier sistema software, porque, ¿qué es en definitiva un sistema software? Siempre se puede modelar con esos cuatro conceptos.

(Nota: por contenedores no me refiero a nada que ver con Docker y tecnologías similiares).Hablamos de modelar la arquitectura como la estructura que da soporte a lo demás, no la definición de flujos de trabajo y casos de uso, etc.

Volvemos quizá a la necesidad de vanidad de algunos que se consideran arquitectos software, quienes, quizá inconscientemente porque han sido educados creyendo que la arquitectura debe tratarse de algo con gran enjundia, tratan de hacer complejo algo que se puede hacer con lápiz y papel, para así, quizá justificar un puesto dentro de la organización.

La principal función de un arquitecto debe ser, por encima de todas las demás, comunicar bien al resto del equipo. Punto

¿Qué es entonces la arquitectura de un proyecto software o qué debe cubrir un rol de arquitecto?

Una buena arquitectura tan solo persigue comunicar (insisto: CO-MU-NI-CAR) de la forma más sencilla posible la estructura y la visión del sistema que se va a construir para que todos los miembros del equipo (desarrolladores, Q&A, testers, etc.) la puedan compartir y comprender. Nada peor para un desarrollador que no saber por qué y para qué hace lo que hace. Y del mismo modo, nada de enlatar esa visión y estructura: ésta puede cambiar también a lo largo del tiempo, del avance del proyecto y de las retrospectivas.

Entonces, ¿qué diferencia la arquitectura del diseño? La primera va, como hemos dicho, de estructura y visión desde una perspectiva global del sistema y de las grandes decisiones (tecnologías a usar, división funcional, detección de riesgos, homogeneidad, etc.), la segunda está ligada a cómo se implementa el código.

Para ello, un buen arquitecto software cuenta con una experiencia multidisciplinar, para:

• Comprender los objetivos, los desafíos, el universo o dominio de lo que se va a construir, los requisitos (aunque cambien) y las restricciones.
• Codificar: el arquitecto también debe ser capaz de involucrarse en las tareas de programación (huir de la torre de marfil), pero no necesariamente tiene que ser el mejor desarrollador, para nada.
• Diseñar software: debe ser capaz de comprender bien las estrategias de diseño, basada en buenas prácticas, principios de diseño y hacer que éstos sean consistentes a lo largo de todo el proyecto.
• Identificar los riesgos de las decisiones tomadas.
• Calidad: debe guiar al resto del equipo para que se mantengan los parámetros de calidad deseados.
• Guiar al equipo: debe tener habilidades soft para comunicar bien, ayudar, mentorizar y hasta liderar a los miembros del equipo.

Esto es, el arquitecto debe ser también un guía, capaz de transmitir la visión general del producto y objetivos del proyecto, porque, como sabemos, el desarrollo de software es una actividad altamente colaborativa.

En mi opinión, solo después de cubrir lo anterior, entonces sí que el arquitecto podrá sugerir patrones de arquitectura como CQRS, Service Bus, event-driven, etc. Todos estos patrones de arquitectura son formas de resolver ciertos problemas, pero su simple elección es tan solo una parte del rol del arquitecto.