Qué es la arquitectura de software según Bass, Taylor y Fowler. Cuáles son los problemas esenciales del desarrollo y por qué no hay bala de plata. Cómo clasificar y gestionar los cuatro tipos de deuda técnica. Y cuál es el rol del arquitecto frente a los distintos stakeholders del proyecto.
La arquitectura de software es uno de esos conceptos que todo el mundo usa pero pocos definen con precisión. ¿Es la estructura del código? ¿Las decisiones de diseño? ¿La forma del sistema? Dependiendo del autor, la respuesta cambia — y cada respuesta revela algo diferente sobre cómo entendemos el software.
Cada definición enfatiza algo diferente. Bass se centra en la estructura. Taylor pone el foco en las decisiones. Fowler, influenciado por las metodologías ágiles, sugiere que la arquitectura no es algo que se diseña por fuera del equipo: emerge de él como resultado de las decisiones importantes que se van tomando en el camino.
Frederick Brooks argumentó que los problemas del desarrollo de software se dividen en dos categorías: esenciales y accidentales. Esta distinción, conocida por su ensayo No Silver Bullet, sigue siendo vigente décadas después.
Tienen que ver con el problema que se va a resolver en sí mismo, no con la forma de implementarlo. Se dividen en cuatro tipos:
Son los detalles de implementación y producción: lenguajes, integraciones, servidores, frameworks. Generan ganancias cuando se resuelven y muchos son solucionables con una librería o una API. Pero lo verdaderamente importante siempre es resolver los problemas esenciales.
No hay ninguna bala de plata que solucione el problema esencial del desarrollo de software. — Frederick Brooks
Ward Cunningham introdujo el término deuda técnica en 1992. La metáfora es directa: la deuda técnica hace que un proyecto sea difícil de mantener y costoso de evolucionar, porque el código de baja calidad requiere mayor esfuerzo para interpretarse y modificarse. Cunningham identificó cuatro tipos, organizados por dos dimensiones.
La refactorización es el proceso de mejorar el código sin alterar su comportamiento, para que sea más entendible y tolerante a cambios. Es el mecanismo con el que se pagan las deudas. Antes de refactorizar, el código debe tener tests automáticos que validen el funcionamiento original — sin eso, no hay forma de garantizar que los cambios no rompan nada.
"Nuestro código tiene que ser simple y directo, debería leerse con la misma facilidad que un texto bien escrito." — Grady Booch
El arquitecto de software no es simplemente el técnico más senior del equipo. Su rol es conectar los requerimientos de distintos stakeholders con la implementación del sistema.
El proceso de desarrollo tradicional tiene cinco etapas — Análisis de Requerimientos, Diseño de la Solución, Desarrollo y Evaluación, Despliegue, y Mantenimiento y Evolución — aunque en metodologías ágiles varias ocurren de forma iterativa y simultánea.
Una distinción importante: el rol no es lo mismo que el puesto de trabajo. En equipos pequeños, una misma persona puede cumplir varios roles. En metodologías tradicionales existen el Experto del dominio, el Analista, el Administrador de sistemas, el QA, el Desarrollador, el Arquitecto y el Gestor de proyecto. En metodologías ágiles, los roles equivalentes son los Stakeholders, el Product Owner, el DevOps/SRE, el Equipo de desarrollo autogestiónado y el Facilitador.
La diferencia más significativa está en quién tiene autoridad sobre los requerimientos. En metodologías tradicionales, el Analista indaga qué hay que resolver. En metodologías ágiles, el Product Owner arma las historias de usuario, las prioriza y define iterativamente qué construye el equipo en cada sprint.