Evolution and Modernization

Cambiar conservando lo que importa

Este MOC organiza preguntas sobre cambio en el tiempo, deuda, herencia y modernización. technical-debt y legacy-systems ofrecen el contexto inicial; evolutionary-architecture, architecture-erosion y fitness-functions conectan cambio guiado, intención y feedback. strangler-fig, parallel-change y branch-by-abstraction permiten explorar mecanismos; refactor-vs-rewrite y migration-strategy, elegir y organizar la transformación. cloud-migration y data-migration especializan preocupaciones de entorno e información; deprecation y sunsetting, preparación y retirada de capacidades. No presupone que evolucionar signifique reescribir ni que modernizar obligue a reemplazar todo lo existente.

Una intervención debe explicar qué necesita cambiar y qué comportamiento, datos o compromisos conserva. El diseño objetivo no basta: versiones coexistentes, operación, consumidores y retirada también pertenecen al problema. Este mapa ofrece navegación; los canónicos desarrollan definiciones y ejemplos, sin convertir una secuencia de lectura en proceso obligatorio.

Por qué cambiar es difícil

Pregunta	Recorrido
¿Por qué una condición técnica actual agrega carga a cambios futuros?	technical-debt: condición, consecuencias, principal, interés y tratamiento.
¿Por qué un sistema existente conserva valor y aun así resulta difícil de evolucionar?	legacy-systems: contexto heredado, conocimiento, contratos y alternativas.

Cómo cambia la arquitectura y conserva alineamiento

Pregunta	Recorrido
¿Cómo puede una arquitectura cambiar deliberadamente sin depender de reemplazos completos?	evolutionary-architecture: cambio guiado, incremental y multidimensional.
¿Cómo identificar debilitamiento de intenciones arquitectónicas relevantes?	architecture-erosion: intención vigente, realización y contexto.
¿Cómo obtener feedback repetible sobre características y restricciones?	fitness-functions: expectativa, mecanismo, evidencia y límites.

Mecanismos para una transición controlada

Pregunta	Recorrido
¿Cómo reemplazo gradualmente responsabilidades de un sistema existente?	strangler-fig: desplazamiento de trabajo, autoridad y retiro.
¿Cómo cambio un contrato o schema sin exigir migración simultánea?	parallel-change: Expand, Migrate y Contract.
¿Cómo sustituyo una implementación manteniendo ambos caminos integrados?	branch-by-abstraction: abstracción, coexistencia y reemplazo.

Elegir y organizar la transformación

Pregunta	Recorrido
¿Cuándo conviene transformar lo existente y cuándo reemplazar una parte significativa?	refactor-vs-rewrite: alcance, conocimiento y alternativas.
¿Cómo organizo la transición entre la arquitectura actual y la objetivo?	migration-strategy: estados, secuencia, autoridad y cierre.

Preocupaciones especializadas de migración

Pregunta	Recorrido
¿Qué cambia realmente al trasladar una carga hacia infraestructura o servicios cloud?	cloud-migration: entorno, responsabilidades y dependencias.
¿Cómo traslado datos preservando semántica, autoridad e integridad?	data-migration: estado, validación y cutover.

Terminar capacidades anteriores con obligaciones resueltas

Pregunta	Recorrido
¿Cómo aviso y gestiono que una capacidad ya no debería recibir nuevas dependencias?	deprecation: señal, política y preparación de consumidores.
¿Cómo retiro una capacidad, versión o sistema sin ignorar consumidores, datos y obligaciones restantes?	sunsetting: alcance, evidencia y retirada controlada.

Estas seis agrupaciones son navegación editorial del Atlas, no una taxonomía universal ni un lifecycle obligatorio. Los mecanismos no prescriben arquitectura final ni sustituyen decidir estrategia, secuencia y contingencias de una migración.

Deuda y legacy pueden coexistir; también puede haber deuda en software reciente y sistemas antiguos que continúan siendo adecuados. Una etiqueta no determina urgencia, reemplazo ni valor. Para comparar casos, elegir un cambio concreto y observar qué obligaciones lo hacen difícil.

Leer desde una decisión de Commerce

Orders necesita cambiar una integración de Payments mientras Inventory y Shipping mantienen su operación. La aplicación conserva datos históricos, reglas de refund y consumidores que no necesariamente aparecen en el diagrama. Separar las preguntas ayuda a no prometer una simplificación que pierda semántica.

Comenzar por legacy-systems si falta entender consumidores, conocimiento o restricciones del conjunto. Seguir hacia technical-debt cuando se identifica una condición que agrega trabajo: por ejemplo, Orders interpreta y escribe el schema privado de Payments.

Después consultar data-ownership, interfaces y dependency-structure para examinar autoridad y propagación. constraints permite distinguir contrato vigente de costumbre. Ninguna de esas lecturas obliga a extraer un servicio; puede justificar mantener, encapsular o cambiar una frontera existente.

Para una transición concreta, leer el ejemplo de composición de strangler-fig: desplazar Payments, sustituir su motor con branch-by-abstraction y evolucionar PaymentAuthorized con parallel-change. Volver a fitness-functions para separar mecanismo de cambio y evidencia. Refunds históricos y consumidores de BI impiden confundir éxito de un camino nuevo con cierre de toda la migración.

refactor-vs-rewrite compara si conviene conservar y transformar o reemplazar un alcance; migration-strategy organiza cómo realizar la decisión. Una reimplementación puede introducirse por incrementos. Ninguna de esas preguntas queda resuelta por elegir un mecanismo o instalar el destino.

Si el cambio involucra entorno, seguir hacia cloud-migration; si mueve estado o representación, hacia data-migration. Trasladar el web tier conservando Payments on-premises puede no mover esos datos. Llevar Payments a una base gestionada combina ambas preocupaciones, sin convertirlas en equivalentes.

Cuando v1 deja de ser la alternativa preferida, deprecation prepara el movimiento. Un partner mensual puede quedar fuera de una observación breve. sunsetting pregunta qué se retira después y qué conserva soporte: migrar autorizaciones no elimina refunds, lectores de BI ni historia requerida. Avisar, trasladar trabajo y cerrar obligaciones son preguntas distintas.

Complejidad y consecuencias económicas

essential-complexity ayuda a conservar distinciones necesarias del negocio. accidental-complexity pregunta por representación y mecanismos de solución. Technical Debt añade carga futura; las tres perspectivas se relacionan sin convertir dificultad, deuda y herencia en equivalentes.

cost-efficiency incluye ingeniería y operación además de runtime. Un mecanismo de compatibilidad puede agregar trabajo temporal y preservar entregas; mantenerlo indefinidamente puede cambiar la evaluación. Comparar valor, esfuerzo de transición, riesgos y horizonte de uso, sin una puntuación universal ni una promesa de ahorro por tecnología.

architectural-drivers devuelve el análisis a necesidades y compromisos. Un plan de renovación no sustituye la pregunta por el resultado esperado. Revisar el driver si desaparece la demanda que justificaba una extracción o si cambia una obligación externa.

Evidencia para una trayectoria

modifiability examina un cambio delimitado; evolvability permite razonar sobre sucesivas adaptaciones y retiro de decisiones. testability aporta evidencia de comportamiento y deployability pregunta cómo entregar combinaciones seguras. Las mediciones requieren escenarios; contar releases o tests no prueba toda la evolución.

operability incorpora diagnóstico y recuperación durante estados intermedios. systems-thinking ayuda a detectar si menos trabajo en un equipo se transformó en conciliación manual, dependencia de otro proveedor o mayor carga de usuarios. El alcance debe incluir a quienes reciben consecuencias relevantes.

El perfil elegido tampoco certifica modernización. architecture-profiles compara paquetes de decisiones; Microservices o Serverless pueden participar en una solución sin eliminar deuda, preservar historia o hacer barata la transición automáticamente.

Síntesis editorial del Atlas

Concepto	Pregunta que conserva separada
Evolutionary Architecture	¿Cómo orientar cambio arquitectónico deliberadamente?
Architecture Erosion	¿Qué intención vigente se está debilitando o evadiendo?
Fitness Functions	¿Qué evaluación aporta feedback sobre una expectativa seleccionada?
Technical Debt	¿Qué condición técnica agrega carga futura?
Legacy Systems	¿Qué herencia condiciona evolución y conserva valor?
Accidental Complexity	¿Qué dificultad introduce la solución y su contexto?

Un recorrido posible conecta drivers e intención actual, cambio acotado, Fitness Functions y otro feedback, evidencia y decisión de continuar, ajustar o remediar. Una desviación no gestionada puede conducir a erosión y carga futura; una revisión justificada puede cambiar intención sin erosión. Esta es una síntesis del Atlas, no un lifecycle obligatorio ni un método formal atribuido a las fuentes.

Alcance materializado de V0.3

Los temas previstos por Knowledge Map V0.3 para esta rama ya tienen canonical y recorrido en las seis agrupaciones anteriores. Esto completa su materialización editorial, sin convertir documentos draft en una especificación final ni cerrar futuras revisiones basadas en evidencia.

Deprecation comunica una dirección; Sunsetting gestiona retirada. Migration Strategy organiza el trayecto, Parallel Change permite compatibilidad, Strangler Fig desplaza responsabilidad y Data Migration trata estado y autoridad. Pueden componerse sin volverse sinónimos. Ninguna lista constituye una escala de madurez ni exige utilizar todos los mecanismos.

Volver al problema

Antes de escoger una intervención, declarar el cambio necesario, actores afectados, comportamiento valioso, datos autoritativos y restricciones. Separar lo observado de lo supuesto y definir qué evidencia mostraría mejora o daño desplazado. Una fecha de reemplazo no resuelve por sí sola consumidores pendientes.

La decisión puede ser pequeña: contener una dependencia, obtener pruebas representativas, revisar una obligación o conservar una solución adecuada. Volver a los canónicos cuando «todo es deuda» o «hay que reescribir porque es viejo» impida comparar alternativas con sus consecuencias.