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 los proyectos durante las últimas décadas, me atrevería a decir), creando aún más debate y falta de consenso claro. La poca literatura que existe al respecto 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 aún 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 ese papel cuando entienden 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, dedicé un capítulo ligero a este asunto sin profundizar demasiado en detalles, bajo el título “El Mal Entendido Rol de Arquitecto de Software”. 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 ni para devolver ningún agravio, porque yo mismo he asumido ese papel en los últimos años en los productos que he dirigido y los proyectos en los que he estado al frente.
Es un tema 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, podemos encontrarnos ese rol con responsabilidades totalmente diferentes, cuando no equipos que se autodenominan ágiles y creen que no hace falta ninguna visión de arquitectura de los productos y proyectos que diseñan; o bien nos encontramos al desarrollador al que han ascendido y, por esa razón, cree que sus decisiones van a ser mejores que las de sus antiguos compañeros de departamento.
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 se afrontaba el desarrollo de software hace unas décadas siguen persistiendo en el inconsciente colectivo de los llamados arquitectos. Para muchos, todo lo que habla de arquitectura tiene que estar relacionado con diagramas UML tan espesos como inútiles, que poco aclaran, y con estructuras en las que necesariamente todo el desarrollo debe encajar (tan solo recuerdos de dinosaurio sobre cómo se afrontaba el desarrollo hace mucho tiempo pero que aún perduran), siendo más un obstáculo que una ayuda. En otros equipos (y me los he cruzado en algún momento de mi carrera), sencillamente ignoran que exista ese concepto: el software se desarrolla de forma monolítica y se despliega como sea y punto, 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, a continuación voy a hacer algunas aclaraciones que confío ayuden a tener una idea más clara de lo que para mí es un arquitecto software, y que, afortunadamente, he visto confirmados en autores 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 dirigiendo 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 del arquitecto de edificios, aparejador y albañil, etc., porque 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 el papel de desarrollador y dedicarse solo a la arquitectura lo aleja probablemente de ahí donde es bueno. 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, el tamaño del proyecto y su proyección a largo plazo.
Se confunde arquitectura de despliegue IT con la arquitectura de un producto o proyecto.
En ciertos entornos, he visto cómo se confundían estas dos cosas. La arquitectura de un sistema software no es lo mismo que la arquitectura IT de despliegue final del sistema a desarrollar, pero están relacionadas, 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 en la práctica en varias ocasiones: decisiones de diseño que parecen pequeñas al principio pero que acaban costando mucho esfuerzo en mantenimiento, cambios de requisitos, integraciones complejas o despliegues frágiles. En proyectos que crecen y evolucionan, una mala elección de estructura puede convertir el producto en una máquina de coste operativo elevado, con errores difíciles de depurar y una capacidad de evolución muy reducida.
No hay conflicto entre lo ágil y definir una arquitectura al comienzo.
Así es. Léelo de nuevo por si esta afirmación 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.
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 debe gestionarse y 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 aportar más bien poco) ha llevado a crear cierta atmósfera en contra de esta forma de modelado, cuando no a justificar el trabajo poco productivo de quienes lo realizan, o a creer que de esos diagramas se sacan directamente 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; lo que digo es 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 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. En este contexto, puede que simples diagramas con cajas y líneas sean más que suficientes.
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 o tecnologías similares. Hablamos de modelar la arquitectura como la estructura que da soporte a lo demás; no de 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í 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: comunicar) 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, QA, 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: 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.), mientras que la segunda está ligada a cómo se implementa el código.
Para ello, un buen arquitecto software cuenta con 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, 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 basadas en buenas prácticas, principios de diseño y hacer que éstas sean consistentes a lo largo de todo el proyecto.
- Identificar los riesgos de las decisiones tomadas.
- Garantizar 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 e incluso 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 los 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.