El ADM: Architecture Development Method

El Método de Desarrollo de Arquitectura (Architecture Development Method, ADM) es el núcleo de TOGAF. Es un ciclo de fases que lleva una organización desde la decisión de hacer arquitectura hasta la gobernanza de los proyectos que la implementan, y vuelve a empezar cuando el contexto cambia. Este capítulo da la vista completa; los capítulos 13 a 16 entran en el detalle de cada fase y de las técnicas asociadas.

El ciclo

flowchart TD
    P["Preliminar"] --> A["A · Visión de la Arquitectura"]
    A --> B["B · Arquitectura de Negocio"]
    B --> C["C · Arquitecturas de Sistemas de Información"]
    C --> D["D · Arquitectura Tecnológica"]
    D --> E["E · Oportunidades y Soluciones"]
    E --> F["F · Planificación de la Migración"]
    F --> G["G · Gobierno de la Implementación"]
    G --> H["H · Gestión del Cambio de la Arquitectura"]
    H --> A
    RM(("Gestión de Requisitos"))
    RM <--> A
    RM <--> B
    RM <--> C
    RM <--> D
    RM <--> E
    RM <--> F
    RM <--> G
    RM <--> H

Tres observaciones sobre la figura:

• La fase Preliminar está fuera del ciclo principal porque prepara la organización para hacer arquitectura; se repite solo cuando la capacidad de arquitectura necesita cambiar.
• La Gestión de Requisitos (Requirements Management) no es una fase con inicio y fin, sino un proceso continuo que alimenta a todas las demás y recibe de todas nuevos requisitos y cambios.
• Las flechas de retorno existen en todas las fases: el método es iterativo, no lineal.

Fase por fase

Cada fase se describe con el mismo esquema: objetivo, entradas, pasos resumidos y salidas principales. Los deliverables se nombran en español con su nombre oficial en inglés la primera vez.

Fase Preliminar

Aspecto	Contenido
Objetivo	Preparar la organización: definir la Architecture Capability, los principios, el marco adaptado y el gobierno
Entradas	Modelo de negocio, estrategia, marcos existentes, políticas, acuerdos de asociación
Pasos	Delimitar la organización afectada; confirmar gobierno y soporte; definir el equipo; adaptar TOGAF y otros marcos; implantar herramientas; definir principios
Salidas	Modelo organizativo para la arquitectura (Organizational Model for Enterprise Architecture), marco de arquitectura adaptado (Tailored Architecture Framework), principios de arquitectura (Architecture Principles), repositorio inicial, solicitud de trabajo de arquitectura (Request for Architecture Work)

Fase A: Visión de la Arquitectura

Aspecto	Contenido
Objetivo	Acordar alcance, stakeholders, visión y aprobación formal de un ciclo de arquitectura
Entradas	Request for Architecture Work, principios, repositorio, estrategia de negocio
Pasos	Establecer el proyecto; identificar stakeholders y sus preocupaciones; confirmar objetivos y drivers; evaluar capacidades y preparación; definir alcance; confirmar principios; desarrollar la visión; definir la propuesta de valor y los KPI; evaluar riesgos; redactar el Statement of Architecture Work
Salidas	Declaración de trabajo de arquitectura (Statement of Architecture Work), Visión de la Arquitectura (Architecture Vision), plan de comunicaciones (Communications Plan), evaluación de capacidades (Capability Assessment)

Fase B: Arquitectura de Negocio

Aspecto	Contenido
Objetivo	Describir la arquitectura de negocio de línea base y objetivo y las brechas entre ambas
Entradas	Architecture Vision, principios, modelos de referencia de negocio, repositorio
Pasos	Seleccionar modelos de referencia, viewpoints y herramientas; describir línea base; describir objetivo; análisis de brechas; definir candidatos a componentes de roadmap; resolver impactos; revisar con stakeholders; finalizar; crear el Architecture Definition Document
Salidas	Documento de Definición de Arquitectura (Architecture Definition Document) parte de negocio, Especificación de Requisitos de Arquitectura (Architecture Requirements Specification), componentes del Architecture Roadmap

Artefactos típicos: mapa de capacidades, flujos de valor, mapa de organización, catálogo de procesos, matriz actor/rol, diagrama de casos de uso de negocio.

Fase C: Arquitecturas de Sistemas de Información

La fase C agrupa dos arquitecturas que pueden desarrollarse en cualquier orden, según lo que domine el problema.

Aspecto	Arquitectura de Datos	Arquitectura de Aplicaciones
Objetivo	Describir cómo se estructura, gestiona y gobierna la información	Describir qué aplicaciones existen, qué hacen y cómo se relacionan con procesos y datos
Pasos	Mismos nueve pasos que la fase B, aplicados al dominio	Mismos nueve pasos que la fase B, aplicados al dominio
Artefactos típicos	Catálogo de entidades, matriz entidad/función de negocio, diagrama de ciclo de vida de datos, diagrama de seguridad de datos	Catálogo de aplicaciones, matriz aplicación/función, diagrama de comunicación entre aplicaciones, diagrama de uso de aplicaciones
Salidas	Architecture Definition Document y Architecture Requirements Specification actualizados	Idem

Fase D: Arquitectura Tecnológica

Aspecto	Contenido
Objetivo	Describir la plataforma lógica y física que soporta aplicaciones y datos
Entradas	Arquitecturas B y C, modelos de referencia técnicos (por ejemplo, el TOGAF Technical Reference Model histórico o modelos del proveedor de nube), estándares
Pasos	Los mismos nueve pasos aplicados a tecnología
Salidas	Architecture Definition Document completo en sus cuatro dominios, Architecture Requirements Specification, componentes del roadmap

Artefactos típicos: catálogo de estándares tecnológicos, matriz aplicación/tecnología, diagrama de entornos y ubicaciones, diagrama de red.

Fase E: Oportunidades y Soluciones

Aspecto	Contenido
Objetivo	Convertir las brechas en paquetes de trabajo y decidir el enfoque de implementación
Entradas	Brechas de B, C y D, factores de implementación, Capability Assessment
Pasos	Determinar factores de implementación; consolidar brechas y requisitos; confirmar dependencias entre ellos; evaluar preparación y riesgos; formular la estrategia de implementación y migración; identificar paquetes de trabajo; identificar arquitecturas de transición; redactar el Architecture Roadmap
Salidas	Hoja de ruta de arquitectura (Architecture Roadmap), plan de implementación y migración preliminar, arquitecturas de transición (Transition Architectures)

Aquí los ABB de fases anteriores empiezan a convertirse en SBB: se decide comprar, construir o reutilizar.

Fase F: Planificación de la Migración

Aspecto	Contenido
Objetivo	Finalizar el plan detallado, con costes, beneficios, riesgos y secuencia
Entradas	Architecture Roadmap, portafolio de proyectos, marcos de gestión existentes (PMO, operaciones, presupuesto)
Pasos	Confirmar la interacción con otros marcos de gestión; asignar valor de negocio a cada paquete; estimar recursos y tiempos; priorizar con análisis de coste/beneficio y riesgo; confirmar el roadmap; completar el plan; cerrar el ciclo de desarrollo
Salidas	Plan de implementación y migración (Implementation and Migration Plan) final, Architecture Definition Document finalizado, contratos de arquitectura preparados

Fase G: Gobierno de la Implementación

Aspecto	Contenido
Objetivo	Supervisar que los proyectos construyan lo definido y gestionar las desviaciones
Entradas	Plan de migración, contratos de arquitectura, Architecture Repository
Pasos	Confirmar alcance y prioridades con el equipo de desarrollo; identificar recursos y habilidades; guiar el desarrollo de soluciones; realizar revisiones de cumplimiento (Architecture Compliance Reviews); implementar las operaciones de negocio y TI; cerrar la implementación
Salidas	Contratos de arquitectura (Architecture Contracts) firmados, evaluaciones de cumplimiento, solicitudes de cambio, soluciones desplegadas

Fase H: Gestión del Cambio de la Arquitectura

Aspecto	Contenido
Objetivo	Mantener viva la arquitectura: decidir si un cambio en el entorno exige ajustes menores o un nuevo ciclo del ADM
Entradas	Solicitudes de cambio, resultados de monitoreo, cambios de estrategia o tecnología
Pasos	Establecer el proceso de monitoreo y gestión de valor; gestionar riesgos; analizar cada cambio; clasificarlo (simplificación, incremental o rearquitectura); reunir al Architecture Board; activar el proceso que corresponda; producir los requisitos del siguiente ciclo
Salidas	Actualizaciones de la arquitectura, cambios al marco y a los principios, nueva Request for Architecture Work

Gestión de Requisitos

Aspecto	Contenido
Objetivo	Garantizar que todo requisito se identifica, se registra, se prioriza y se resuelve en la fase adecuada, y que los cambios se propagan
Entradas	Requisitos que emergen en cualquier fase
Pasos	Identificar y documentar; establecer la línea base; evaluar impacto; actualizar el repositorio; notificar a las fases afectadas
Salidas	Repositorio de requisitos (Architecture Requirements Repository) actualizado, Architecture Requirements Specification, evaluaciones de impacto

Resumen de deliverables por fase

Fase	Deliverable principal
Preliminar	Tailored Architecture Framework, Architecture Principles
A	Statement of Architecture Work, Architecture Vision
B, C, D	Architecture Definition Document, Architecture Requirements Specification
E	Architecture Roadmap, Transition Architectures
F	Implementation and Migration Plan
G	Architecture Contracts, Compliance Assessments
H	Change Requests, nueva Request for Architecture Work
Requisitos	Architecture Requirements Repository

Naturaleza iterativa

El ADM se dibuja como un círculo, pero rara vez se recorre una sola vez en línea recta. El documento Applying the ADM describe tres tipos de iteración:

Tipo	Qué se repite	Ejemplo
Entre ciclos	Un ciclo completo alimenta al siguiente	El ciclo estratégico define segmentos; cada segmento inicia su propio ciclo
Entre fases	Una fase posterior hace volver a una anterior	La fase E descubre que un paquete no es viable y reabre la fase C
Dentro de una fase	Los pasos se repiten hasta converger	En la fase B se refina el mapa de capacidades tras cada revisión con stakeholders

Además, el estándar agrupa las fases en cuatro ciclos de iteración que suelen ejecutarse como bloques:

flowchart LR
    subgraph I1["Architecture Capability"]
        P["Preliminar"] --- A1["A"]
    end
    subgraph I2["Architecture Development"]
        B["B"] --- C["C"] --- D["D"]
    end
    subgraph I3["Transition Planning"]
        E["E"] --- F["F"]
    end
    subgraph I4["Architecture Governance"]
        G["G"] --- H["H"]
    end
    I1 --> I2 --> I3 --> I4
    I4 -.nuevo ciclo.-> I1
    I3 -.ajustes.-> I2

Iteración	Fases	Propósito
Architecture Capability	Preliminar, A	Establecer o ajustar la capacidad de arquitectura y el alcance del ciclo
Architecture Development	B, C, D (y refinamiento de A)	Construir el contenido de la arquitectura
Transition Planning	E, F	Convertir la arquitectura en un plan ejecutable
Architecture Governance	G, H	Supervisar la implementación y gestionar el cambio

Dos estilos de iteración de desarrollo:

• Línea base primero (baseline first): se documenta el estado actual antes de diseñar el objetivo. Útil cuando el problema es la complejidad de lo existente.
• Objetivo primero (target first): se diseña el objetivo y luego se mira lo actual solo para calcular brechas. Útil cuando la transformación es profunda y lo existente se reemplazará.

Adaptar el ADM

El ADM es genérico por diseño. La fase Preliminar produce un marco adaptado (Tailored Architecture Framework) que ajusta:

• Terminología: nombres de deliverables acordes al vocabulario de la organización.
• Proceso: fases que se fusionan, se omiten o se intercalan con otros métodos (Scrum, PRINCE2, SAFe, ITIL).
• Contenido: artefactos obligatorios frente a opcionales; metamodelo extendido o reducido.
• Integración: cómo encaja con la gestión de portafolio, la PMO, la gestión de servicios y el presupuesto.

Una organización pequeña puede ejecutar las fases B, C y D en un solo taller y producir un único documento. Una multinacional puede tener equipos distintos por dominio y por segmento.

Niveles y partición

El capítulo 11 presentó los niveles estratégico, de segmento y de capacidad. El ADM se ejecuta en cada nivel con alcance distinto:

Nivel	Lo que produce el ciclo	Horizonte
Estratégico	Dirección, principios, segmentos prioritarios	3 a 5 años
Segmento	Arquitectura detallada de un programa o unidad	1 a 3 años
Capacidad	Diseño de una capacidad o incremento concreto	Meses

El alcance de un ciclo se fija en la fase A con cuatro dimensiones:

Dimensión	Pregunta
Amplitud (breadth)	¿Qué parte de la empresa cubre?
Profundidad (depth)	¿Hasta qué nivel de detalle?
Periodo (time period)	¿Para qué horizonte se diseña el objetivo?
Dominios	¿Los cuatro BDAT o un subconjunto?

La partición permite que varios ciclos convivan: un ciclo estratégico en curso, dos ciclos de segmento en paralelo y varios ciclos de capacidad bajo cada uno. El Architecture Repository mantiene la coherencia entre ellos.

El Architecture Repository en cada fase

El repositorio no es un deliverable de una fase: es la memoria que todas consultan y actualizan.

flowchart LR
    subgraph REPO["Architecture Repository"]
        MM["Architecture Metamodel"]
        LS["Architecture Landscape"]
        RL["Reference Library"]
        SIB["Standards Information Base"]
        GL["Governance Log"]
        CAP["Architecture Capability"]
        RR["Requirements Repository"]
    end
    P["Preliminar"] -->|define| MM
    P -->|configura| CAP
    A["Fase A"] -->|consulta| LS
    BCD["Fases B C D"] -->|crean y leen| LS
    BCD -->|reutilizan| RL
    BCD -->|cumplen| SIB
    EF["Fases E F"] -->|producen roadmap en| LS
    GH["Fases G H"] -->|registran decisiones en| GL
    ALL["Todas las fases"] -->|alimentan| RR

Componente	Qué contiene	Fase que más lo usa
Architecture Metamodel	Definición de los tipos de artefactos y sus relaciones	Preliminar
Architecture Landscape	Arquitecturas de línea base, transición y objetivo en los tres niveles	B, C, D, E
Reference Library	Modelos de referencia, patrones, plantillas reutilizables	B, C, D
Standards Information Base	Estándares obligatorios y recomendados	D, G
Governance Log	Decisiones, evaluaciones de cumplimiento, dispensas	G, H
Architecture Capability	Organización, roles, procesos del equipo de arquitectura	Preliminar
Architecture Requirements Repository	Todos los requisitos con su estado	Gestión de Requisitos

Ejercicio práctico

Sobre la cadena de retail que quiere unificar canales:

1. Dibuja en Mermaid el ciclo ADM y anota, junto a cada fase, el deliverable concreto que produciría para este caso (por ejemplo, en la fase A: “Architecture Vision: una experiencia de compra única en tienda, web y app”).
2. Decide si el ciclo conviene ejecutarlo con estilo “línea base primero” u “objetivo primero” y argumenta en cinco líneas.
3. Define el alcance del ciclo en sus cuatro dimensiones (amplitud, profundidad, periodo, dominios).
4. Propón una partición: un ciclo de segmento para canales y al menos dos ciclos de capacidad dependientes. Indica qué fase del ciclo de segmento debe terminar antes de que arranquen los de capacidad.
5. Lista tres requisitos que podrían aparecer en la fase D (por ejemplo, latencia del inventario en tiempo real) y describe cómo la Gestión de Requisitos los haría volver a la fase B o C.

Autoevaluación

1. ¿Cuál es el papel de la Gestión de Requisitos en el ADM?

   • A. Es la última fase, después de H
   • B. Es un proceso continuo que alimenta y recibe requisitos de todas las fases
   • C. Es una actividad exclusiva de la fase A
   • D. Sustituye a la fase Preliminar en organizaciones ágiles

2. ¿Qué fases componen la iteración de Transition Planning?

   • A. E y F
   • B. B, C y D
   • C. G y H
   • D. Preliminar y A

3. ¿En qué fase los Architecture Building Blocks empiezan a convertirse en Solution Building Blocks?

   • A. Fase A
   • B. Fase B
   • C. Fase H
   • D. Fase E

4. ¿Qué componente del Architecture Repository guarda las decisiones del Architecture Board y las evaluaciones de cumplimiento?

   • A. Reference Library
   • B. Standards Information Base
   • C. Governance Log
   • D. Architecture Landscape

Respuestas

1. B. La Gestión de Requisitos está al centro del ciclo y opera durante todas las fases.
2. A. Transition Planning agrupa E (Oportunidades y Soluciones) y F (Planificación de la Migración).
3. D. En la fase E se decide comprar, construir o reutilizar, y los ABB pasan a SBB.
4. C. El Governance Log registra decisiones, cumplimiento y dispensas.

Checklist

• Enumero las fases del ADM en orden y digo el objetivo de cada una en una frase.
• Nombro el deliverable principal de cada fase.
• Explico los tres tipos de iteración y los cuatro ciclos de iteración.
• Distingo los estilos “línea base primero” y “objetivo primero”.
• Fijo el alcance de un ciclo en sus cuatro dimensiones.
• Sé qué componente del Architecture Repository consulta cada fase.