Architecture Erosion
Desalineación respecto de una intención vigente
Architecture Erosion describe degradación del alineamiento entre intención arquitectónica vigente y arquitectura realizada, cuando reglas, fronteras, dependencias o responsabilidades relevantes se debilitan, violan o evitan. No designa cualquier diferencia histórica ni toda dificultad de mantenimiento.
La intención puede incluir dirección de dependencias, autoridad de datos, independencia de entrega, aislamiento o restricciones de comunicación. boundaries, dependency-structure, data-ownership, deployment y constraints permiten precisar qué se pretendía conservar. Un diagrama es una representación parcial, no toda esa intención.
Esta es la convención operativa del Atlas. Requiere explicar qué compromiso sigue vigente, qué evidencia muestra su debilitamiento y por qué importa. No usa edad, número de servicios o cantidad de ciclos como un diagnóstico automático.
Erosion y drift en sus fuentes
Perry y Wolf distinguen architectural erosion, asociada a violaciones de arquitectura, de architectural drift, asociada a insensibilidad hacia ella que reduce coherencia y claridad y facilita posteriores violaciones. Foundations for the Study of Software Architecture, 1992, sección 2.3. Su drift no equivale simplemente a todo cambio intencional inocuo.
De Silva y Balasubramaniam reconocen esa distinción y no la mantienen para el alcance de su survey, atendiendo a causas compartidas. Controlling Software Architecture Erosion: A Survey, 2012, introducción. No existe una separación terminológica universal que deba imponerse a cada fuente.
El Atlas utiliza erosion para analizar degradación respecto de intención vigente y conserva el contexto al mencionar drift. No presenta ambos términos como una taxonomía exhaustiva ni convierte variación documental en incumplimiento demostrado.
La intención actual no es el diagrama más antiguo
Si un diseño anterior prescribía A y nuevos architectural-drivers justifican B, implementar B puede ser evolución legítima. Una documentación que todavía representa A necesita actualización; su desajuste no prueba que B haya erosionado la arquitectura.
Eso tampoco permite legitimar cualquier implementación cambiando el documento después. Revisar intención exige explicar driver, decisión, consecuencias y obligaciones afectadas. Una excepción aceptada con alcance y condiciones puede pertenecer al diseño vigente; un bypass no evaluado no se vuelve correcto porque ya existe.
Cuando no hay acuerdo sobre intención, explicitar la incertidumbre. El código permite recuperar parte de lo realizado, pero no decide por sí solo qué debería preservarse. Tampoco basta la memoria aislada de una persona para resolver contratos con otros participantes.
Supongamos que Module A tenía prohibido depender de B. Una reorganización puede asignarle otra responsabilidad y permitir A → B deliberadamente. Mantener un check antiguo sin revisar el acuerdo produciría un juicio de conformance equivocado, no evidencia suficiente de erosión actual.
Manifestaciones: síntomas que necesitan contexto
| Señal posible | Intención que habría que comprobar |
|---|---|
| Ciclos o dirección de imports modificada. | Restricciones elegidas de dependencia y responsabilidades. |
| Lecturas o escrituras sobre estado ajeno. | Autoridad y contratos de acceso acordados. |
| Internals usados como interfaces externas. | Qué representación se consideraba privada. |
| Releases que empiezan a requerir simultaneidad. | Independencia de deployment realmente prometida. |
| Excepciones temporales que se acumulan. | Alcance, vigencia y tratamiento acordados. |
Shared mutable state, duplicación de responsabilidades, saltos de capas o accesos no autorizados pueden aportar evidencia. No todos son violaciones en cualquier arquitectura. Una base compartida puede ser deliberada; lo decisivo es quién puede actuar sobre qué datos y bajo qué acuerdo.
En modularity, erosionar puede significar pérdida de information hiding o encapsulación. Una arquitectura poco modular desde su concepción puede ser inadecuada sin haber sufrido esa degradación. Mala calidad inicial y deterioro respecto de intención son diagnósticos distintos, aunque puedan coexistir después.
Un modelo que eligió dependencias hacia el dominio puede considerar Domain → implementación de Infrastructure una violación. Otra estructura puede permitir relaciones diferentes. El ejemplo no convierte Clean Architecture ni una regla de Layered en obligación universal.
Commerce: evolución deliberada y atajo de ownership
La intención vigente reserva a Payments la autoridad sobre el estado de pago. Orders utiliza una interface explícita; Inventory conserva reservas y Shipping espera confirmación válida. Son decisiones de la variante ilustrativa, no requisitos de toda aplicación Commerce.
Un nuevo análisis de fraude requiere autorización diferida. El equipo revisa contratos, estados pendientes, vigencia de reservas y resultados tardíos. Cambiar de interacción síncrona a workflow asíncrono es evolución intencional si se evalúan y conservan los compromisos elegidos. evolutionary-architecture examina cómo orientar esa trayectoria.
En otro recorrido, Orders comienza a leer tablas privadas de Payments para entregar rápido. Después escribe payment_status y duplica decisiones sobre autorización. Si el ownership acordado sigue vigente, esos cambios muestran debilitamiento progresivo de su frontera. Que el flujo feliz todavía termine no refuta la desviación.
El análisis pregunta qué escritores existen, qué identidades pueden modificar datos, cómo se confirma un resultado y quién valida transiciones. Revisar solo imports podría perder acceso mediante SQL o un intermediario. El síntoma observado y el contrato debilitado deben conectarse mediante evidencia.
Deployment independiente como intención comprobable
En una realización de microservices, puede pretenderse que Orders y Payments evolucionen y se entreguen de forma independiente. Si cada cambio interno de schema acaba exigiendo releases simultáneos, conviene examinar qué contratos perdieron compatibilidad y qué consumidores conocen detalles privados.
Artifacts separados no demuestran esa independencia. Una prueba de versiones soportadas puede aportar evidencia; también importa migración de datos, configuración y recuperación. deployability permite evaluar la entrega completa, mientras Deployment identifica unidades y secuencias.
Coordinación no implica erosión automáticamente. Puede responder a una transición explícita o a una arquitectura cuyo release conjunto siempre fue una decisión vigente. Definir independencia después solo para condenar el sistema actual confunde una nueva preferencia con una intención previamente incumplida.
Deuda, complejidad y herencia
technical-debt describe condiciones que agregan carga futura. Erosion puede producirlas: escribir sobre estado privado puede ampliar regresión y bloquear cambios de Payments. También puede existir deuda sin violación, como un adapter temporal previsto dentro de una migración aceptada.
accidental-complexity describe dificultad introducida por solución o contexto. Una implementación puede respetar su arquitectura y contenerla. A la inversa, violar una restricción puede añadir pocas líneas y casi ninguna complejidad inmediata; su significado no depende de que ya exista un incidente o un costo grande.
legacy-systems examina un contexto heredado que condiciona evolución y conserva valor. Antigüedad no prueba erosión: un sistema duradero puede conservar excelentes fronteras y uno nuevo debilitarlas rápidamente. No se deduce una secuencia obligatoria legacy → erosion → rewrite.
Estas diferencias orientan la respuesta. Una carga costosa puede requerir remediación aunque coincida con el diseño; una violación importante puede merecer atención antes de que resulte cara. Evitar etiquetas intercambiables ayuda a discutir intención, consecuencias y prioridad por separado.
Un camino marcado mediante deprecation puede permanecer intencionalmente por compatibilidad contractual. Esa decisión vigente no demuestra erosión. Si debía retirarse y pasa a dependerse de él sin control ni revisión de intención, sunsetting ayuda a examinar obligaciones de cierre; borrar código por su etiqueta no restaura por sí solo la arquitectura.
Causas sociotécnicas sin fatalismo
Presión de entrega, reglas poco claras, pérdida de conocimiento, reorganización, ownership ambiguo y optimización local pueden interactuar con limitaciones de herramientas. Una revisión sistemática recoge factores técnicos y no técnicos entre los estudios analizados. Understanding Software Architecture Erosion, secciones 4.4 y 5.1.3.
Aquí esos hallazgos informan hipótesis contextuales; no se adopta una afirmación de inevitabilidad ni se trata entropy como ley física del software. Los mecanismos requieren decisiones, cambios y condiciones observables. Tampoco se atribuye toda violación a un error individual del developer.
systems-thinking permite examinar quién soporta el costo de una solución local y qué incentivos sostienen la repetición. Una regla obsoleta puede hacer atractivos bypasses; conviene revisar tanto la regla como los cambios. Analizar causas no convierte toda desviación en aceptable ni elimina responsabilidad de tratarla.
Conformance, reconstrucción y límites de evidencia
Los Reflexion Models de Murphy, Notkin y Sullivan comparan un modelo de alto nivel con relaciones extraídas del código mediante un mapping explícito. Hacen visibles acuerdos y diferencias para interpretar. Software Reflexion Models, 1995. Una diferencia abre una pregunta; no resuelve por sí sola si el modelo quedó antiguo o la implementación incumple intención.
El SEI describe reconstrucción como obtención de una representación as-built a partir del sistema existente. Architecture Reconstruction Guidelines, 2001. Conocer lo realizado permite razonar, pero todavía requiere contrastarlo con intención actual, contratos y operación.
fitness-functions puede detectar dependencias prohibidas, fallos de compatibilidad o algunas condiciones de runtime. Su cobertura depende del modelo, permisos, datos y entorno examinados. Static analysis no observa necesariamente acceso dinámico, autoridad efectiva o todos los recursos compartidos; pasar checks no demuestra ausencia de erosión.
Documentación actual, conversaciones y evidencia complementaria ayudan; documentar por sí solo no previene desvíos. Una arquitectura no deja de existir por estar poco documentada, aunque recuperar y evaluar su intención resulte más difícil.
Reaccionar sin congelar el pasado
Confirmar primero intención, manifestación y alcance; después decidir si restaurar una frontera, revisar un contrato, tratar una excepción o cambiar justificadamente el diseño. Actualizar feedback junto a la decisión evita conservar restricciones obsoletas como si fueran características eternas.
En la síntesis del Atlas, Evolutionary Architecture orienta cambio, Fitness Functions aporta feedback seleccionado y Architecture Erosion identifica degradación de intención vigente. Ninguna sustituye technical-debt como análisis de carga futura. evolution-and-modernization conecta esas lecturas para intervenir con evidencia en lugar de proteger diagramas por antigüedad.