¿Por qué iba alguien a «invertir» en arquitectura?

La deuda técnica es la carga de complejidad a menudo no planeada que cada proyecto de software acumula con el tiempo. No pretendemos agregar deuda a un sistema mientras lo desarrollamos, mantenemos, depuramos y extendemos, pero sucede de todos modos. Sucede porque el software es complejo, con muchas partes móviles; porque las dependencias entre las partes a menudo son indirectas e invisibles; y porque nuestra comprensión de esta complejidad es limitada en alcance e imperfecta. A veces (nuevamente, sin querer) agregamos a esta complejidad porque nos enfocamos en nuestra tarea, corrigiendo un error o implementando una función, y no nos damos cuenta de que nuestros esfuerzos están disminuyendo la integridad conceptual del sistema. Tal vez implementemos una funcionalidad "casi pero no del todo" como la que ya existe en alguna otra parte del sistema. Tal vez hagamos una dependencia directa entre dos partes de la base de código sin darnos cuenta de que deberíamos haber empleado una abstracción, a través de una API publicada.

Esta clase de degradación de una arquitectura sucede todo el tiempo , normalmente sin que los desarrolladores sean conscientes de que han contribuido a la deuda técnica del sistema.

Este tipo de deuda técnica se produce por varias razones, pero la principal es la combinación de un enfoque en las funcionalidades, normalmente impulsado por las demandas de las partes interesadas, y la incapacidad de los arquitectos y directores de proyecto para medir el retorno de la inversión de las buenas prácticas arquitectónicas. Las funcionalidades aportan un beneficio inmediato. La mejora arquitectónica genera costes inmediatos y, si se hace bien, beneficios a largo plazo. Dicho así, ¿por qué iba alguien a «invertir» en arquitectura? La respuesta es sencilla: Sin arquitectura, los beneficios que se supone que aporta el sistema serán mucho más difíciles de conseguir; la velocidad disminuirá y el sistema será cada vez más difícil de depurar, arreglar, escalar y evolucionar. En pocas palabras, si no se toman algunas decisiones arquitectónicas clave desde el principio, y si se permite que la arquitectura se degrade, no se podrá mantener la velocidad del sprint, porque no se podrá responder fácilmente a las solicitudes de cambio.

Para reiterar, la arquitectura permite la agilidad, y no al revés. Además, la arquitectura influirá, pero no determinará, otras decisiones que no son en sí mismas decisiones de diseño. Estas decisiones no influyen directamente en la consecución de los atributos de calidad, pero el arquitecto debe tomarlas. Por ejemplo, estas decisiones pueden incluir la selección de herramientas, la estructuración del entorno de desarrollo y la asignación de tareas. Por último, una arquitectura bien diseñada y adecuadamente comunicada es clave para lograr acuerdos que guíen al equipo. Los consensos más importantes son los relativos a las interfaces y los recursos compartidos. Acordar las interfaces desde el principio es importante para el desarrollo basado en componentes, y de vital importancia para el desarrollo distribuido utilizando enfoques como los microservicios.