Fases E, F, G y H: de las oportunidades a la gestión del cambio

Las fases B, C y D dejan una arquitectura objetivo y una lista de brechas por dominio. Las cuatro fases siguientes convierten esa lista en trabajo que alguien ejecuta, aseguran que lo ejecutado respete la arquitectura y deciden cuándo la arquitectura misma tiene que cambiar. En el medio de todas ellas, la Gestión de Requisitos (Requirements Management) recibe y redistribuye los cambios que surgen en cualquier fase.

flowchart TD
    D["Fase D<br/>Arquitectura Tecnológica"] --> E["Fase E<br/>Oportunidades y Soluciones"]
    E --> F["Fase F<br/>Planificación de la Migración"]
    F --> G["Fase G<br/>Gobierno de la Implementación"]
    G --> H["Fase H<br/>Gestión del Cambio de la Arquitectura"]
    H --> A["Fase A<br/>nuevo ciclo"]
    H -. "cambio incremental" .-> E
    RM(("Gestión de<br/>Requisitos")) <--> E
    RM <--> F
    RM <--> G
    RM <--> H

Hay un cambio de naturaleza entre E y F. Hasta E, el ADM responde a la pregunta “¿qué hay que hacer?”; desde F, responde “¿cuándo, en qué orden y quién?”. La fase E es la última que produce arquitectura; la F produce un plan.

Fase E: Oportunidades y Soluciones

Objetivo

Generar la primera versión completa del Architecture Roadmap (hoja de ruta de arquitectura) a partir de las brechas de B, C y D, y decidir si el objetivo se alcanza de una vez o por etapas con Transition Architectures (arquitecturas de transición). También decide, para cada componente, si se construye, se compra o se reutiliza.

Consolidar brechas en paquetes de trabajo

El primer paso es juntar las tres listas de brechas en una sola y agruparlas en paquetes de trabajo (Work Packages). Un paquete de trabajo es un conjunto de acciones que cierran una o varias brechas y que tiene sentido ejecutar junto. Puede convertirse en un proyecto, en parte de uno o en un cambio dentro de una operación existente. Las brechas del retail se consolidan así:

Paquete de trabajo	Brechas que cierra	Dominios
WP1 Fundaciones de integración e identidad	Integración punto a punto; sin proveedor de identidad	Tecnología
WP2 Cliente único	Tres registros de cliente; consentimientos	Datos, negocio
WP3 Información de producto	Atributos distintos por canal; catálogo web duplicado	Datos, aplicaciones
WP4 Inventario unificado	Disponibilidad sin stock de tienda en tiempo real	Datos, aplicaciones
WP5 Orquestación de pedidos	Sin OMS; dos módulos de pedido; devolución cruzada	Aplicaciones, negocio
WP6 Roles y procesos omnicanal	Roles sin dueño; proceso de devolución	Negocio
WP7 Retiro de duplicados	Módulos de pedido y bases de cliente a retirar	Aplicaciones
WP8 Conectividad de tiendas	Enlaces sin redundancia	Tecnología

Factores de implementación y dependencias

TOGAF pide registrar en una Implementation Factor Assessment and Deduction Matrix (matriz de evaluación de factores de implementación) los factores que condicionan el plan: riesgos, restricciones, supuestos, dependencias y acciones derivadas. En el caso:

Factor	Tipo	Deducción
El contrato del e-commerce actual vence en 14 meses	Restricción	La migración del canal web debe terminar antes o renegociar
El ERP no cambia de versión en el horizonte del plan	Supuesto	Los adaptadores se construyen contra la versión actual
Temporada alta en noviembre y diciembre	Restricción	Ningún corte de producción en esos meses
El equipo de datos no tiene experiencia en resolución de identidad	Riesgo	Contratar apoyo externo para WP2 o adquirir producto
OMS requiere cliente, producto e inventario unificados	Dependencia	WP5 no empieza antes de que WP2, WP3 y WP4 estén en producción

Las dependencias entre paquetes se registran en una matriz de dependencias (Consolidated Gaps, Solutions and Dependencies Matrix) que es la base para secuenciar.

Build, buy o reuse

Para cada building block de solución se decide si se construye, se adquiere o se reutiliza algo que ya existe en el repositorio o en el mercado. La decisión se apoya en el Solutions Continuum (capítulo 16): si existe una solución de industria para el problema, construir desde cero requiere justificación.

Building block	Decisión	Racional
Proveedor de identidad	Comprar o servicio gestionado	Problema resuelto por el mercado; sin diferenciación
Bus de eventos y API gateway	Servicio gestionado en nube	Operación fuera del núcleo del negocio
Cliente único	Comprar con integración propia	Resolución de identidad es compleja; integración es específica
PIM	Comprar	Mercado maduro
Inventario unificado	Construir	Reglas de disponibilidad por ubicación son diferenciadoras
OMS	Comprar y extender	Núcleo maduro; reglas de orquestación propias
Adaptador ERP	Construir	Específico del ERP y de sus personalizaciones

Arquitecturas de transición

Cuando la distancia entre línea base y objetivo no se cubre de una vez, se definen Transition Architectures: estados intermedios estables, cada uno con valor de negocio propio, que la empresa puede operar durante meses. No son hitos de proyecto; son arquitecturas completas, documentadas con los mismos artefactos. Para el retail se definen tres:

flowchart LR
    B0["Línea base<br/>Canales en silos<br/>ERP como centro"] --> T1["Transición 1<br/>Fundaciones<br/>Identidad, eventos, PIM"]
    T1 --> T2["Transición 2<br/>Cliente e inventario únicos<br/>Canales consumen datos compartidos"]
    T2 --> T3["Transición 3<br/>OMS en producción<br/>Pedido único, retiro en tienda"]
    T3 --> TG["Objetivo<br/>Duplicados retirados<br/>Devolución cruzada"]

Arquitectura de transición	Qué incluye	Valor de negocio que entrega por sí sola
T1 Fundaciones	WP1, WP3, WP8	Catálogo único para web y app; inicio de sesión único para clientes
T2 Datos compartidos	WP2, WP4, WP6 parcial	Perfil de cliente visible en tienda; disponibilidad real en web
T3 Pedido único	WP5, WP6 completo	Compra en web y retiro en tienda; pedido en tienda con envío a domicilio
Objetivo	WP7	Costo de licencias y operación reducido; devolución en cualquier canal

Salidas de la fase E

• Architecture Roadmap, versión 0.1: paquetes de trabajo, transiciones, dependencias.
• Architecture Definition Document actualizado con las transiciones.
• Implementation and Migration Strategy (estrategia de implementación y migración): enfoque general, por ejemplo “ola por canal” frente a “ola por capacidad”. El retail elige por capacidad, porque el valor está en compartir datos entre canales, no en migrar canales uno a uno.
• Capability Assessment actualizado: qué capacidades de negocio y de TI necesita la empresa para ejecutar el plan.

Fase F: Planificación de la Migración

Objetivo

Finalizar el Architecture Roadmap y producir el Implementation and Migration Plan (plan de implementación y migración), coordinado con la gestión de portafolio, la oficina de proyectos y la gestión de operaciones. La fase F es donde la arquitectura deja de ser un plan de arquitectos y pasa a ser parte del plan de la empresa.

Priorización por costo, valor y riesgo

Cada paquete de trabajo se evalúa con una Business Value Assessment (evaluación de valor de negocio). TOGAF no fija la técnica; la práctica habitual es puntuar valor, costo y riesgo y representar los paquetes en un cuadrante.

quadrantChart
    title Paquetes de trabajo por valor y costo
    x-axis "Costo bajo" --> "Costo alto"
    y-axis "Valor bajo" --> "Valor alto"
    quadrant-1 "Planificar con cuidado"
    quadrant-2 "Hacer primero"
    quadrant-3 "Posponer"
    quadrant-4 "Reconsiderar"
    "WP1 Integracion e identidad": [0.45, 0.70]
    "WP2 Cliente unico": [0.60, 0.85]
    "WP3 Informacion de producto": [0.35, 0.60]
    "WP4 Inventario unificado": [0.55, 0.80]
    "WP5 Orquestacion de pedidos": [0.85, 0.95]
    "WP6 Roles y procesos": [0.20, 0.55]
    "WP7 Retiro de duplicados": [0.30, 0.40]
    "WP8 Conectividad tiendas": [0.25, 0.50]

El cuadrante informa, no decide. WP5 tiene el valor más alto y también el costo más alto, pero además depende de WP2, WP3 y WP4; por eso va tercero aunque sea el que más vale.

Tablas de incrementos y de evolución de estados

Dos artefactos propios de la fase F:

Architecture Definition Increments Table (tabla de incrementos): para cada transición, qué incrementos de cada dominio se entregan.

Transición	Negocio	Datos	Aplicaciones	Tecnología
T1	Rol de dueño de catálogo	Modelo canónico de producto	PIM en producción	Proveedor de identidad, bus de eventos, API gateway, enlaces redundantes
T2	Roles de asesor omnicanal; consentimientos	Modelo canónico de cliente e inventario	Cliente único, inventario unificado, adaptador ERP	Plataforma de datos
T3	Rol de coordinador de retiro; proceso de retiro en tienda	Modelo canónico de pedido	OMS, canales delgados	Observabilidad centralizada
Objetivo	Proceso de devolución cruzada	Retiro de bases duplicadas	Retiro de módulos de pedido y bases de cliente	Baja de servidores liberados

Transition Architecture State Evolution Table (tabla de evolución de estados): para cada building block, en qué estado queda en cada transición.

Building block	Línea base	T1	T2	T3	Objetivo
Módulo de pedidos web	Activo	Activo	Activo	Solo lectura	Retirado
Módulo de pedidos POS	Activo	Activo	Activo	Solo lectura	Retirado
Catálogo web	Activo	Retirado
Base de clientes CRM	Activo	Activo	Migrada, solo lectura	Retirada
PIM		Nuevo	Activo	Activo	Activo
Cliente único			Nuevo	Activo	Activo
Inventario unificado			Nuevo	Activo	Activo
OMS				Nuevo	Activo

Roadmap de 18 meses

gantt
    title Roadmap omnicanal del retail
    dateFormat YYYY-MM
    axisFormat %Y-%m
    section Transicion 1
    WP1 Integracion e identidad      :wp1, 2027-01, 4M
    WP3 Informacion de producto      :wp3, 2027-02, 4M
    WP8 Conectividad de tiendas      :wp8, 2027-01, 3M
    Hito T1 en produccion            :milestone, m1, 2027-05, 0d
    section Transicion 2
    WP2 Cliente unico                :wp2, 2027-04, 5M
    WP4 Inventario unificado         :wp4, 2027-05, 4M
    WP6 Roles y procesos parte 1     :wp6a, 2027-06, 3M
    Hito T2 en produccion            :milestone, m2, 2027-09, 0d
    section Transicion 3
    WP5 Orquestacion de pedidos      :wp5, 2027-09, 2M
    Congelamiento temporada alta     :crit, freeze, 2027-11, 2M
    WP5 Orquestacion continua        :wp5b, 2028-01, 3M
    WP6 Roles y procesos parte 2     :wp6b, 2028-01, 2M
    Hito T3 en produccion            :milestone, m3, 2028-04, 0d
    section Objetivo
    WP7 Retiro de duplicados         :wp7, 2028-04, 3M
    Hito arquitectura objetivo       :milestone, m4, 2028-06, 0d

El congelamiento de noviembre y diciembre sale directamente de la matriz de factores de implementación. Un roadmap que lo ignore es un roadmap que la operación va a rechazar.

Integración con portafolio y PMO

El Implementation and Migration Plan no vive aislado. La fase F exige confirmar con la gestión de portafolio que los paquetes de trabajo se convierten en proyectos financiados, con la PMO que los proyectos adoptan el plan y con operaciones que las ventanas de cambio son viables. El resultado es que los proyectos nacen con la arquitectura como entrada y no la descubren a mitad de camino.

Salida de la fase F	Destinatario
Implementation and Migration Plan, versión 1.0	Comité de portafolio, PMO
Architecture Roadmap finalizado	Architecture Board, patrocinador
Architecture Definition Document finalizado	Repositorio de arquitectura
Solicitud de trabajo de arquitectura para el siguiente ciclo, si aplica	Patrocinador

Fase G: Gobierno de la Implementación

Objetivo

Asegurar que los proyectos que implementan el roadmap construyen lo que la arquitectura dice, y gestionar formalmente las desviaciones. La fase G no construye nada; supervisa. Es la fase que dura más tiempo en calendario, porque corre en paralelo con todos los proyectos del plan.

Contrato de arquitectura

El Architecture Contract (contrato de arquitectura) es el acuerdo entre la función de arquitectura y quien implementa: qué entregables de arquitectura recibe el proyecto, qué estándares debe respetar, qué puntos de revisión hay y qué pasa si se desvía. Se firma al inicio de cada proyecto y se basa en la Architecture Requirements Specification. Para el proyecto del OMS en el retail:

Cláusula	Contenido
Alcance	Implementar WP5 conforme a la Transición 3
Entregables de arquitectura recibidos	Diagrama de comunicación objetivo, modelo canónico de pedido, catálogo de estándares de integración
Requisitos vinculantes	Publicación de eventos con contrato versionado; consumo de cliente, producto e inventario desde los servicios compartidos, nunca desde el ERP directamente
Puntos de revisión	Diseño de solución, antes de la primera integración, antes de salida a producción
Métricas	Latencia de confirmación de pedido, porcentaje de pedidos orquestados sin intervención manual
Tratamiento de desviaciones	Solicitud de dispensa al Architecture Board con plazo y plan de remediación

Evaluación de conformidad

La Architecture Compliance Review (revisión de conformidad de arquitectura) es el mecanismo de la fase G. TOGAF define seis niveles para describir la relación entre una implementación y la arquitectura:

Nivel	Significado
Irrelevant (irrelevante)	La implementación no tiene relación con la especificación de arquitectura
Consistent (consistente)	Hay rasgos en común, pero algunos de la especificación no se implementan y algunos implementados no están cubiertos por la especificación
Compliant (cumplidora)	Algunos rasgos de la especificación no se implementan, pero todo lo implementado está cubierto por la especificación
Conformant (conforme)	Todos los rasgos de la especificación se implementan, y la implementación tiene rasgos adicionales no cubiertos por ella
Fully conformant (plenamente conforme)	Correspondencia completa entre especificación e implementación, sin más ni menos
Non-conformant (no conforme)	Hay rasgos de la especificación que se implementan de forma distinta a la especificada

La diferencia entre compliant y conformant confunde a menudo. Compliant es implementar un subconjunto de lo especificado sin salirse; conformant es implementar todo lo especificado y además algo más. Non-conformant no es “falta algo” sino “hay algo hecho de otra manera”.

flowchart TD
    S["Solicitud de revisión<br/>del proyecto"] --> P["Preparar: checklist por dominio<br/>y entregables del proyecto"]
    P --> R["Reunión de revisión<br/>con arquitecto líder y equipo"]
    R --> V{"Resultado"}
    V -- "Fully conformant o conformant" --> OK["Aprobar y registrar"]
    V -- "Compliant" --> OK2["Aprobar con observaciones<br/>sobre lo pendiente"]
    V -- "Consistent o non-conformant" --> D{"¿El proyecto solicita dispensa?"}
    D -- "Sí" --> AB["Architecture Board evalúa<br/>plazo y plan de remediación"]
    D -- "No" --> RW["Rehacer y volver a revisar"]
    AB -- "Concede" --> W["Dispensa registrada<br/>con fecha de vencimiento"]
    AB -- "Rechaza" --> RW
    W --> RM["Gestión de Requisitos<br/>registra el impacto"]

Dispensas

Una dispensa (dispensation o waiver) autoriza una desviación por un plazo y con condiciones. No es una excepción permanente: tiene fecha de vencimiento y un plan de remediación, y queda en el Governance Repository. En el retail, el proyecto del PIM pide dispensa para cargar el catálogo inicial por archivo batch en lugar de por eventos, con plazo de tres meses hasta que el adaptador del ERP esté listo. El Architecture Board la concede porque el estándar de eventos se cumple en operación continua y la carga inicial es única.

Architecture Board

El Architecture Board (comité de arquitectura) es el órgano que aprueba contratos, resuelve revisiones no conformes, concede dispensas y escala conflictos. Su composición y funcionamiento se describen en el Architecture Capability Framework (capítulo 16). En la fase G es el destinatario de toda desviación que no se resuelve entre el arquitecto y el proyecto.

Salidas de la fase G

• Contratos de arquitectura firmados por proyecto.
• Evaluaciones de conformidad y dispensas registradas.
• Solución implementada y conforme, o con desviaciones documentadas.
• Recomendaciones de cambio para la fase H, cuando la implementación revela que la arquitectura misma tiene problemas.

Fase H: Gestión del Cambio de la Arquitectura

Objetivo

Mantener la arquitectura viva. La fase H vigila los cambios en el negocio y en la tecnología, recibe solicitudes de cambio sobre la arquitectura aprobada y decide, para cada una, si se trata dentro del ciclo actual o si justifica abrir un ciclo nuevo del ADM.

Tres tipos de cambio

Tipo	Descripción	Tratamiento
Simplification change (cambio de simplificación)	Reduce inversión o complejidad sin cambiar la arquitectura: retirar un componente, consolidar licencias	Se gestiona por técnicas de gestión del cambio normales, sin nuevo ciclo
Incremental change (cambio incremental)	Añade valor dentro de la arquitectura existente: una nueva integración, un canal adicional sobre el OMS	Se evalúa; si el impacto es acotado se gestiona como incremento; si no, puede requerir un ciclo parcial
Re-architecting change (cambio de rearquitectura)	Modifica los fundamentos: nuevo modelo de negocio, cambio de plataforma central, adquisición de otra empresa	Abre un ciclo nuevo del ADM desde la fase A, con nueva Solicitud de Trabajo de Arquitectura

La regla práctica de TOGAF para distinguirlos: si el cambio afecta a una sola parte interesada o a un solo building block, suele ser simplificación o incremental; si afecta a varias partes interesadas o a varios dominios, o cuestiona principios, es rearquitectura.

Monitoreo

La fase H instala dos vigilancias permanentes. El monitoreo de tecnología sigue cambios en productos, estándares y proveedores que afectan al catálogo tecnológico: fin de soporte de una versión, un proveedor adquirido por otro. El monitoreo de negocio sigue cambios en objetivos, regulación y mercado: nueva ley de datos personales, apertura de un canal de marketplace.

Solicitud de cambio de arquitectura

Toda petición formal de modificar la arquitectura aprobada entra como Request for Architecture Change (solicitud de cambio de arquitectura). Se registra, se evalúa su impacto con la Gestión de Requisitos y se clasifica en uno de los tres tipos.

Ejemplos en el retail, seis meses después de alcanzar la Transición 3:

Solicitud	Origen	Clasificación	Decisión
Vender a través de un marketplace externo como canal adicional	Dirección comercial	Incremental	Nuevo canal delgado sobre OMS, PIM e inventario unificado; sin ciclo nuevo
Retirar el servidor del catálogo web ya migrado	Operaciones de TI	Simplificación	Aprobada, sin revisión de arquitectura
El proveedor del proveedor de identidad anuncia fin de soporte en 24 meses	Monitoreo de tecnología	Incremental con riesgo	Se abre evaluación de alternativas; se registra riesgo
Adquisición de una cadena de tiendas con otro ERP	Dirección general	Rearquitectura	Nuevo ciclo del ADM; nueva Solicitud de Trabajo de Arquitectura

Cuándo reiniciar el ciclo

El ciclo se reinicia cuando el cambio invalida la Architecture Vision: cambian los objetivos, las partes interesadas, los principios o el alcance. No se reinicia por acumulación de incrementos; para eso existe la actualización periódica del Architecture Definition Document. El reinicio produce una nueva Solicitud de Trabajo de Arquitectura que entra por la fase A, y la arquitectura actual pasa a ser la línea base del nuevo ciclo.

Gestión de Requisitos: la fase central

La Gestión de Requisitos no es una fase secuencial; es un proceso continuo con el que todas las demás fases intercambian información. Su función es asegurar que ningún requisito se pierda y que todo cambio en un requisito se evalúe contra las fases afectadas.

sequenceDiagram
    participant G as Fase G Gobierno
    participant RM as Gestión de Requisitos
    participant C as Fase C Sistemas de información
    participant E as Fase E Oportunidades
    participant F as Fase F Migración
    G->>RM: Dispensa del PIM: carga inicial por batch
    RM->>RM: Registrar en Requirements Repository
    RM->>C: Evaluar impacto: ¿cambia el modelo de datos?
    C-->>RM: Sin cambio de modelo, cambia una interfaz temporal
    RM->>E: Evaluar impacto: ¿cambia el roadmap?
    E-->>RM: Añadir tarea de retiro del batch tras adaptador ERP
    RM->>F: Actualizar plan con la tarea de retiro
    F-->>RM: Plan actualizado
    RM-->>G: Impacto cerrado, dispensa vigente con fecha

Repositorio de requisitos

Los requisitos viven en el Requirements Repository, parte del Architecture Repository (capítulo 16). Cada requisito tiene origen, fase que lo generó, prioridad, estado y trazabilidad hacia los building blocks que lo cumplen. En la práctica el repositorio es una herramienta de gestión de requisitos o, en organizaciones pequeñas, una tabla gobernada.

Evaluación de impacto

Cuando un requisito aparece o cambia, la Gestión de Requisitos produce una evaluación de impacto (Requirements Impact Assessment): qué fases, artefactos y building blocks se ven afectados, y si el cambio se absorbe en la fase actual o se devuelve a una anterior. Un nuevo requisito regulatorio sobre consentimientos descubierto en la fase G, por ejemplo, puede devolver trabajo a la fase C de datos sin reiniciar el ciclo.

Cómo fluyen los cambios

Origen del cambio	Fase que lo detecta	Hacia dónde fluye
Parte interesada nueva con una preocupación no cubierta	A, B	Fases B a D para incorporar el viewpoint
Restricción técnica descubierta al diseñar	C, D	Fase B si cambia una capacidad; E si solo cambia el roadmap
Dependencia que el plan no puede resolver	F	Fase E para redefinir transiciones
Desviación de un proyecto	G	Fase C o D si el estándar era inviable; H si la arquitectura debe cambiar
Cambio en el negocio o la tecnología	H	A si es rearquitectura; E o F si es incremental

Ejercicio práctico

Trabaja sobre el retail omnicanal o sobre tu organización, partiendo de las brechas del capítulo anterior.

1. Agrupa las brechas en 6 a 8 paquetes de trabajo. Para cada uno indica los dominios que toca.
2. Completa una matriz de factores de implementación con al menos un riesgo, una restricción, un supuesto y una dependencia, cada uno con su deducción para el plan.
3. Decide build, buy o reuse para cada building block de solución y escribe el racional en una línea.
4. Define 2 o 3 arquitecturas de transición. Para cada una escribe qué valor de negocio entrega por sí sola; si una transición no entrega valor propio, fusiónala con la siguiente.
5. Puntúa los paquetes por valor, costo y riesgo y dibújalos en un quadrantChart de Mermaid. Compara el orden que sugiere el cuadrante con el que imponen las dependencias.
6. Construye la tabla de evolución de estados para 6 building blocks.
7. Dibuja el roadmap en un gantt de Mermaid que respete las ventanas de congelamiento de tu negocio.
8. Redacta un contrato de arquitectura de una página para el paquete de mayor valor, con requisitos vinculantes y puntos de revisión.
9. Inventa tres solicitudes de cambio posteriores y clasifícalas como simplificación, incremental o rearquitectura. Justifica cuál reinicia el ciclo.

Autoevaluación

1. ¿Qué caracteriza a una Transition Architecture?

A. Es un hito del plan de proyecto sin documentación propia. B. Es un estado intermedio estable y operable, con valor de negocio propio y descrito con los mismos artefactos que el objetivo. C. Es la arquitectura de línea base renombrada para el siguiente ciclo. D. Es un paquete de trabajo que agrupa varias brechas.

2. Una implementación cumple todos los rasgos de la especificación y además incorpora rasgos adicionales que la especificación no cubre. ¿Qué nivel de conformidad le corresponde?

A. Compliant. B. Fully conformant. C. Conformant. D. Consistent.

3. La empresa adquiere otra cadena con un ERP distinto y la dirección quiere integrarla. ¿Cómo clasifica la fase H este cambio?

A. Cambio de simplificación, porque consolida sistemas. B. Cambio incremental, porque añade tiendas al modelo existente. C. No es un cambio de arquitectura; es un proyecto de integración. D. Cambio de rearquitectura, que abre un nuevo ciclo del ADM desde la fase A.

4. ¿Cuál es la función principal de la Gestión de Requisitos en el ADM?

A. Recibir cambios de cualquier fase, registrarlos, evaluar su impacto y redirigirlos a las fases afectadas. B. Aprobar los contratos de arquitectura antes de la fase G. C. Definir los requisitos funcionales detallados de cada proyecto. D. Priorizar los paquetes de trabajo por valor y costo.

Respuestas

1. B. Una transición es una arquitectura completa que la empresa puede operar durante un tiempo; no es un hito ni un paquete de trabajo.
2. C. Conformant es “todo lo especificado más algo adicional”. Fully conformant exige correspondencia exacta; compliant es un subconjunto de lo especificado.
3. D. Afecta a varias partes interesadas, a todos los dominios y cuestiona el alcance de la visión; es rearquitectura y reinicia el ciclo.
4. A. La Gestión de Requisitos es el proceso central de intercambio; no aprueba contratos ni prioriza paquetes, eso corresponde a G y F.

Checklist

• Todas las brechas de B, C y D están asignadas a un paquete de trabajo.
• La matriz de factores de implementación incluye riesgos, restricciones, supuestos y dependencias con su deducción.
• Cada arquitectura de transición entrega valor de negocio por sí sola y está documentada.
• El Implementation and Migration Plan está acordado con portafolio, PMO y operaciones, y respeta las ventanas de congelamiento.
• Cada proyecto del roadmap tiene contrato de arquitectura y puntos de revisión de conformidad definidos.
• Existe un procedimiento para clasificar solicitudes de cambio y decidir cuándo se reinicia el ciclo.