Architecture Repository, Enterprise Continuum, Content Framework y técnicas del ADM

El ADM describe un ciclo. Lo que hace que el ciclo sea repetible, y no un esfuerzo que empieza de cero cada vez, es un conjunto de estructuras que viven fuera de él: un lugar donde guardar lo producido, una forma de clasificarlo, un vocabulario común para describirlo, una organización que lo gobierne y un catálogo de técnicas que las fases aplican. Este capítulo recorre esas estructuras y cierra el módulo de TOGAF.

mindmap
  root((Soporte al ADM))
    Enterprise Continuum
      Architecture Continuum
      Solutions Continuum
    Architecture Repository
      Metamodel
      Capability
      Landscape
      Standards Library
      Reference Library
      Governance Repository
      Requirements Repository
      Solutions Landscape
    Content Framework
      Deliverables
      Artifacts
      Building Blocks
      Content Metamodel
    Capability Framework
      Architecture Board
      Governance
      Compliance
      Contracts
      Skills Framework
      Maturity Models
    Técnicas del ADM
      Principles
      Stakeholder Management
      Gap Analysis
      Risk Management
      Capability-Based Planning

Enterprise Continuum

El Enterprise Continuum (continuo empresarial) es una forma de clasificar activos de arquitectura y de solución según su grado de generalidad: desde lo que sirve a cualquier organización hasta lo que solo sirve a esta. Su utilidad es doble: ayuda a encontrar algo reutilizable antes de construir, y ayuda a comunicar en qué nivel se está hablando cuando dos personas discuten “la arquitectura”.

Tiene dos continuos paralelos. El Architecture Continuum clasifica arquitecturas (descripciones); el Solutions Continuum clasifica soluciones (implementaciones). Cada arquitectura de un nivel guía las soluciones de ese nivel, y cada solución de un nivel es una realización de la arquitectura correspondiente.

flowchart LR
    subgraph AC["Architecture Continuum"]
        direction LR
        FA["Foundation<br/>Architectures"] --> CSA["Common Systems<br/>Architectures"] --> IA["Industry<br/>Architectures"] --> OSA["Organization-Specific<br/>Architectures"]
    end
    subgraph SC["Solutions Continuum"]
        direction LR
        FS["Foundation<br/>Solutions"] --> CSS["Common Systems<br/>Solutions"] --> IS["Industry<br/>Solutions"] --> OSS["Organization-Specific<br/>Solutions"]
    end
    FA -. "guía" .-> FS
    CSA -. "guía" .-> CSS
    IA -. "guía" .-> IS
    OSA -. "guía" .-> OSS
    FS -. "soporta" .-> FA

Nivel	Architecture Continuum	Solutions Continuum	Ejemplo en el retail
Foundation	Servicios y estándares genéricos que cualquier sistema necesita	Productos genéricos: sistemas operativos, bases de datos, redes	Plataforma de contenedores, base de datos relacional gestionada
Common Systems	Arquitecturas de dominios comunes a muchas industrias: seguridad, integración, gestión de datos	Productos que implementan esos dominios	Proveedor de identidad, bus de eventos, API gateway
Industry	Arquitecturas y modelos propios de una industria	Soluciones de industria	Modelo de datos de retail, OMS y PIM de mercado
Organization-Specific	Lo que solo esta empresa necesita	Soluciones construidas o adaptadas	Reglas de disponibilidad por ubicación, adaptador del ERP personalizado

Leer el continuo de izquierda a derecha es leer la decisión build, buy o reuse de la fase E: cuanto más a la izquierda cae un building block, menos sentido tiene construirlo.

Architecture Repository

El Architecture Repository (repositorio de arquitectura) es el lugar físico, o lógico, donde se guarda todo lo que el ADM produce y consume. TOGAF lo describe con ocho áreas. No prescribe la herramienta; prescribe qué debe poder guardarse y relacionarse.

flowchart TB
    subgraph REPO["Architecture Repository"]
        MM["Architecture Metamodel<br/>vocabulario y reglas"]
        CAP["Architecture Capability<br/>organización, roles, procesos"]
        LAND["Architecture Landscape<br/>Strategic, Segment, Capability"]
        SIB["Standards Library<br/>estándares vigentes"]
        REF["Reference Library<br/>modelos y plantillas"]
        GOV["Governance Repository<br/>decisiones, contratos, dispensas"]
        REQ["Requirements Repository<br/>requisitos y trazabilidad"]
        SOL["Solutions Landscape<br/>soluciones desplegadas"]
    end
    MM --> LAND
    MM --> REF
    SIB --> LAND
    REF --> LAND
    LAND --> SOL
    GOV --> LAND
    REQ --> LAND
    CAP --> GOV
    EXT["Repositorios externos<br/>proveedores, industria, regulación"] -.-> REF
    EXT -.-> SIB

Área	Qué contiene	Qué guardaría el retail
Architecture Metamodel	La definición de los tipos de elementos y relaciones que la organización usa para describir arquitectura, derivada del Content Metamodel	Decisión de usar capacidades, flujos de valor, entidades, componentes de aplicación y tecnológicos, con la extensión de datos activada
Architecture Capability	Cómo se organiza la función de arquitectura: roles, procesos, habilidades	Composición del Architecture Board, proceso de revisión de conformidad, calendario
Architecture Landscape	Las arquitecturas en sí, en tres niveles de detalle y horizonte	Ver tabla siguiente
Standards Information Base (Standards Library)	Estándares aprobados que las arquitecturas deben cumplir	Integración por eventos con contrato versionado, identidad central, nube pública para componentes nuevos
Reference Library	Modelos de referencia, patrones y plantillas reutilizables	Modelo de datos canónico de retail, patrón de canal delgado, plantilla de contrato de arquitectura
Governance Repository (Governance Log)	Registro de decisiones, revisiones de conformidad, contratos, dispensas, capability assessments	Dispensa del PIM, actas del Architecture Board, contrato del OMS
Requirements Repository	Requisitos de arquitectura con origen, estado y trazabilidad	”El POS opera 4 horas sin conectividad”, trazado al estándar de caché local
Solutions Landscape	Los building blocks de solución desplegados, con su correspondencia a la arquitectura	Inventario de lo que está en producción en cada transición

Los tres niveles del Architecture Landscape

Nivel	Horizonte	Detalle	Para quién	En el retail
Strategic Architectures	Largo plazo, 3 a 5 años	Alto; dirección y prioridades	Dirección general	”Plataforma omnicanal compartida; canales delgados; ERP en centro de datos hasta nuevo ciclo”
Segment Architectures	Medio plazo	Por área de negocio o programa	Dueños de programas	Arquitectura del programa omnicanal: las tres transiciones del capítulo 15
Capability Architectures	Corto plazo	Detalle de una capacidad o proyecto	Equipos de proyecto	Arquitectura del OMS, de cliente único, del PIM

Las tres se relacionan: una Segment Architecture debe ser coherente con la Strategic que la contiene, y una Capability Architecture con la Segment. Cuando un proyecto pide un cambio que rompe esa coherencia, es una señal para la fase H.

Architecture Content Framework

El Architecture Content Framework (marco de contenido de arquitectura) responde a una pregunta simple: cuando el ADM dice “producir la arquitectura de negocio”, ¿qué cosas concretas hay que producir y cómo se llaman? El marco distingue tres tipos de producto de trabajo:

Tipo	Definición	Ejemplos
Deliverable (entregable)	Producto formal, revisado, aprobado y firmado; se guarda como un todo	Architecture Vision, Architecture Definition Document, Architecture Roadmap, Architecture Contract
Artifact (artefacto)	Descripción de un aspecto de la arquitectura; un catálogo, una matriz o un diagrama	Business Capability Map, Application/Data matrix, Environments and Locations diagram
Building Block (bloque de construcción)	Componente reutilizable de capacidad que se combina con otros	Architecture Building Block: “servicio de identidad de cliente”; Solution Building Block: el producto concreto que lo implementa

La relación entre ellos: los entregables contienen artefactos; los artefactos describen building blocks. Un Architecture Building Block (ABB) describe qué capacidad se necesita sin fijar producto; un Solution Building Block (SBB) es la realización concreta. La fase E es donde los ABB se convierten en SBB.

Content Metamodel

El Content Metamodel (metamodelo de contenido) define los tipos de entidad que pueden aparecer en una arquitectura y cómo se relacionan. Es el vocabulario que hace que “actor”, “capacidad”, “entidad de datos” o “componente tecnológico” signifiquen lo mismo en todos los artefactos.

Tiene un núcleo (core) que toda organización usa, y extensiones opcionales que se activan según la madurez y las necesidades:

Parte del metamodelo	Entidades principales	Cuándo activarla
Core	Actor, Role, Organization Unit, Business Capability, Value Stream, Business Function, Business Service, Process, Data Entity, Application Component, Technology Component, Technology Service, Principle, Requirement, Constraint, Work Package	Siempre
Governance Extension	Measure, Contract, Service Quality	Cuando se gestionan niveles de servicio y contratos de arquitectura
Services Extension	Business Service separado de Business Function, Information System Service	Cuando se diseña orientado a servicios
Process Modeling Extension	Event, Control, Product, Process detallado	Cuando los procesos se modelan con detalle
Data Extension	Logical Data Component, Physical Data Component	Cuando la arquitectura de datos requiere componentes lógicos y físicos
Infrastructure Consolidation Extension	Logical y Physical Application y Technology Components, Location	Cuando se consolidan centros de datos o aplicaciones
Motivation Extension	Driver, Goal, Objective, Measure	Cuando se traza la estrategia a la arquitectura

El retail activa Motivation (para trazar la estrategia omnicanal a objetivos), Data (porque el cliente único exige distinguir componentes lógicos y físicos) e Infrastructure Consolidation (porque consolida canales y servidores). Deja fuera Process Modeling y Services hasta que el programa madure.

Architecture Capability Framework

El Architecture Capability Framework (marco de capacidad de arquitectura) describe cómo debe organizarse la empresa para hacer arquitectura de forma sostenida. Si el ADM es el método y el repositorio es el almacén, el Capability Framework es el equipo y sus reglas.

Componente	Qué es	Decisión para el retail
Architecture Board	Órgano que supervisa la práctica: aprueba arquitecturas y contratos, resuelve conformidad, concede dispensas, escala conflictos	Cinco miembros: director de TI, arquitecto jefe, dueño del programa omnicanal, representante de operaciones de tienda, representante de finanzas; reunión quincenal
Architecture Governance	Prácticas y orientación para gestionar arquitecturas a nivel empresarial: procesos, autoridad, responsabilidades	Toda arquitectura de segmento se aprueba en el Board; las de capacidad las aprueba el arquitecto jefe e informa
Architecture Compliance	Proceso de revisión de conformidad y sus checklists por dominio	Tres puntos de revisión por proyecto, como en el contrato del capítulo 15
Architecture Contracts	Acuerdos entre arquitectura y quienes desarrollan u operan	Plantilla única en la Reference Library; obligatoria para proyectos del roadmap
Architecture Skills Framework	Roles de arquitectura y niveles de competencia requeridos por rol	Roles definidos: arquitecto jefe, arquitecto de negocio, arquitecto de datos, arquitecto de soluciones por proyecto
Architecture Maturity Models	Forma de evaluar la madurez de la práctica y planificar su evolución	Evaluación anual; objetivo del primer año: repositorio gobernado y revisiones de conformidad sistemáticas

Sobre la madurez

TOGAF no impone un modelo de madurez propio; remite a modelos existentes y pide que la organización evalúe su capacidad con uno y planifique mejoras. Los niveles suelen ir desde “no existe práctica de arquitectura” hasta “la arquitectura se mide y se optimiza de forma continua”. La evaluación de madurez se hace en la fase Preliminar y se revisa en cada ciclo; es también un insumo de la Business Transformation Readiness Assessment.

Técnicas del ADM

TOGAF agrupa en una sección propia las técnicas que se aplican en una o varias fases. No son fases; son herramientas que las fases invocan.

flowchart LR
    subgraph T["Técnicas"]
        PR["Architecture<br/>Principles"]
        SM["Stakeholder<br/>Management"]
        PT["Architecture<br/>Patterns"]
        GA["Gap<br/>Analysis"]
        MP["Migration Planning<br/>Techniques"]
        IR["Interoperability<br/>Requirements"]
        BTRA["Business Transformation<br/>Readiness Assessment"]
        RK["Risk<br/>Management"]
        CBP["Capability-Based<br/>Planning"]
    end
    PR --> P0["Preliminar, A"]
    SM --> P1["A y todas"]
    PT --> P2["B, C, D"]
    GA --> P2
    MP --> P3["E, F"]
    IR --> P2
    BTRA --> P4["A, E, F"]
    RK --> P5["A a G"]
    CBP --> P6["A, E, F"]

Architecture Principles

Un principio de arquitectura es una regla general y duradera que guía las decisiones. TOGAF pide que cada principio se documente con cuatro partes: nombre, enunciado, racional e implicaciones. Un principio sin implicaciones es una aspiración; las implicaciones son lo que lo hace exigible. Para el retail:

Parte	Contenido
Nombre	Un solo registro por entidad de negocio
Enunciado	Cada entidad de negocio crítica tiene un único sistema de registro; las demás aplicaciones consumen, no crean
Racional	Tres bases de clientes impiden reconocer al cliente entre canales y generan costos de conciliación
Implicaciones	Toda aplicación nueva declara qué entidades consume y de dónde; los proyectos que crean entidades fuera del registro requieren dispensa; hay que financiar la migración de datos existentes

Los principios se evalúan por cinco criterios: comprensibles, robustos, completos, consistentes entre sí y estables.

Stakeholder Management

La gestión de partes interesadas identifica quién tiene interés o influencia en la arquitectura, qué le preocupa y cómo comunicarse con cada uno. Su herramienta es el Stakeholder Map (mapa de partes interesadas), que registra para cada parte su clase, sus preocupaciones (concerns), su nivel de poder e interés y los viewpoints con los que se le va a presentar la arquitectura. Es la técnica que determina qué artefactos se producen: un artefacto que no responde a la preocupación de nadie sobra.

Parte interesada	Poder	Interés	Preocupación	Viewpoint que recibe
Dirección general	Alto	Medio	Retorno y plazo	Roadmap y transiciones
Gerentes de tienda	Medio	Alto	Operación sin cortes; roles nuevos	Proceso de retiro en tienda; matriz actor/rol
Equipo de datos	Bajo	Alto	Calidad del cliente único	Ciclo de vida y matriz aplicación/datos
Proveedor del ERP	Medio	Bajo	Alcance del adaptador	Interfaces y estándares de integración

Architecture Patterns

Un patrón es una solución probada a un problema recurrente, descrita de forma que pueda aplicarse en contextos distintos. TOGAF no cataloga patrones propios; describe cómo documentarlos (nombre, problema, contexto, fuerzas, solución, consecuencias) y pide guardarlos en la Reference Library. El “canal delgado sobre servicios compartidos” del retail es un patrón que se documenta una vez y se aplica al POS, la web, la app y el contact center.

Gap Analysis

Ya aplicada en el capítulo 14. Como técnica, lo esencial: matriz de building blocks base contra objetivo, fila “Nuevo”, columna “Eliminado”, y la regla de que todo eliminado no intencional es un hallazgo. Se aplica en B, C, D y se consolida en E.

Migration Planning Techniques

Conjunto de artefactos de las fases E y F: Implementation Factor Assessment and Deduction Matrix, Consolidated Gaps, Solutions and Dependencies Matrix, Architecture Definition Increments Table, Transition Architecture State Evolution Table y Business Value Assessment. El capítulo 15 los muestra sobre el caso.

Interoperability Requirements

Interoperabilidad es la capacidad de compartir información y servicios. TOGAF pide identificar los requisitos de interoperabilidad entre sistemas y entre organizaciones en las fases B, C y D, y clasificarlos (operacional, de información, técnica). La herramienta es una matriz de interoperabilidad que cruza sistemas y marca qué nivel de intercambio requieren. En el retail, el POS y el OMS requieren interoperabilidad de información en tiempo real; el ERP y el inventario unificado, de información con tolerancia de minutos.

Business Transformation Readiness Assessment

Evalúa si la organización está preparada para el cambio que la arquitectura implica, más allá de la tecnología. Se aplica en la fase A y se revisa en E y F. Se trabaja con factores de preparación (readiness factors) puntuados en madurez actual, madurez objetivo y urgencia:

Factor	Actual	Objetivo	Urgencia	Acción
Visión compartida del cambio	Media	Alta	Alta	Sesiones con gerentes de tienda antes de T1
Deseo y voluntad de cambiar	Baja en tiendas	Alta	Alta	Incentivos ligados a ventas omnicanal
Capacidad para ejecutar	Baja en datos	Media	Alta	Apoyo externo en WP2
Financiamiento asegurado	Alta	Alta	Baja	Ninguna
Gobierno del cambio	Media	Alta	Media	Formalizar el Architecture Board

Los factores en rojo se convierten en acciones del roadmap. Un plan técnicamente impecable con tiendas que no quieren cambiar no se implementa.

Risk Management

La gestión de riesgos del ADM clasifica cada riesgo por efecto e impacto, le asigna un nivel de riesgo inicial (initial risk), define mitigaciones y estima el riesgo residual (residual risk) tras aplicarlas. Los riesgos se registran en la fase A, se revisan en E y F y se monitorean en G.

Riesgo	Efecto	Frecuencia	Inicial	Mitigación	Residual
El adaptador del ERP se retrasa y bloquea inventario unificado	Alto	Media	Alto	Empezar el adaptador en T1 aunque se use en T2	Medio
Resolución de identidad produce duplicados o fusiones erróneas	Alto	Media	Alto	Reglas de fusión con revisión manual los primeros tres meses	Medio
Corte del OMS en temporada alta	Catastrófico	Baja	Alto	Congelamiento de noviembre y diciembre; modo degradado del POS	Bajo
Fin de soporte del proveedor de identidad	Medio	Baja	Medio	Cláusula de portabilidad en el contrato	Bajo

Capability-Based Planning

La planificación basada en capacidades conecta la arquitectura con el negocio en términos que la dirección entiende: no “implementar un OMS” sino “incrementar la capacidad de gestión de pedidos hasta el nivel que permite retiro en tienda”. Cada capacidad se desarrolla en incrementos, y cada incremento tiene dimensiones de personas, procesos y tecnología. Se aplica en A, E y F, y es lo que permite que el roadmap se lea como evolución de capacidades y no como lista de proyectos.

flowchart LR
    C["Capacidad: Gestión de pedidos"] --> I1["Incremento 1<br/>Pedido único por canal"]
    I1 --> I2["Incremento 2<br/>Pedido cruzado entre canales"]
    I2 --> I3["Incremento 3<br/>Devolución en cualquier canal"]
    I1 --> P1["Personas: dueño de pedido"]
    I1 --> PR1["Proceso: captura unificada"]
    I1 --> T1["Tecnología: OMS base"]
    I2 --> P2["Personas: coordinador de retiro"]
    I2 --> PR2["Proceso: retiro en tienda"]
    I2 --> T2["Tecnología: OMS con inventario unificado"]

ArchiMate como notación complementaria

TOGAF dice qué describir; no fija cómo dibujarlo. ArchiMate es un lenguaje de modelado de arquitectura empresarial, también publicado por The Open Group, diseñado para ser coherente con TOGAF. Su utilidad es dar una notación única a los artefactos de todos los dominios y permitir que una herramienta los relacione.

Capa de ArchiMate	Qué modela	Correspondencia con el ADM
Estrategia	Recursos, capacidades, flujos de valor, cursos de acción	Fase A y B: mapa de capacidades, value streams
Negocio	Actores, roles, procesos, servicios, objetos de negocio	Fase B
Aplicación	Componentes, interfaces, servicios y objetos de datos de aplicación	Fase C
Tecnología	Nodos, dispositivos, software de sistema, redes, artefactos	Fase D
Física	Equipamiento, instalaciones, redes de distribución, material	Fase D en organizaciones con operación física
Implementación y migración	Paquetes de trabajo, entregables, eventos de implementación, plateaus (mesetas) y brechas	Fases E y F: los plateaus son las arquitecturas de transición
Motivación (aspecto transversal)	Partes interesadas, drivers, evaluaciones, metas, principios, requisitos	Preliminar, A y Gestión de Requisitos

No es obligatorio usar ArchiMate para aplicar TOGAF. Lo que aporta es que la matriz aplicación/datos, el diagrama de comunicación y la tabla de evolución de estados dejen de ser documentos separados y pasen a ser vistas de un mismo modelo.

Herramientas

TOGAF describe criterios para elegir herramientas de arquitectura, no productos. Las categorías que conviene distinguir:

Categoría	Qué cubre	Qué pedirle
Repositorio de arquitectura con modelado	Modelo único con capas, viewpoints generados, trazabilidad, versiones	Soporte del metamodelo elegido; generación de catálogos y matrices desde el modelo; control de acceso por área del repositorio
Gestión de requisitos	Requisitos, trazabilidad, evaluación de impacto	Enlace bidireccional con los building blocks del repositorio
Gestión de portafolio y proyectos	Paquetes de trabajo, proyectos, financiamiento	Importar el roadmap; devolver estado de ejecución a la fase G
Diagramación ligera	Diagramas en texto o dibujo para comunicación rápida	Versionado junto al resto de la documentación
Gobierno y decisiones	Actas, dispensas, revisiones de conformidad	Búsqueda y vencimientos

Una organización que empieza puede cubrir las cinco categorías con herramientas simples y gobernadas; lo que no puede permitirse es que el repositorio viva en carpetas sin dueño. El retail del caso arranca con un repositorio de modelado para el Landscape y la Reference Library, la herramienta de la PMO para el roadmap, y una tabla gobernada para requisitos y gobierno, con la decisión de integrarlos cuando la práctica madure.

Cómo organiza el retail su repositorio

Área	Decisión inicial	Dueño
Architecture Metamodel	Core más extensiones Motivation, Data e Infrastructure Consolidation	Arquitecto jefe
Architecture Landscape	Una Strategic, una Segment para omnicanal, una Capability por paquete de trabajo	Arquitecto jefe y arquitectos de solución
Standards Library	Doce estándares iniciales con estado vigente, en evaluación o en retiro	Architecture Board
Reference Library	Modelo canónico de retail, patrón de canal delgado, plantillas de contrato y de revisión	Arquitecto de datos y arquitecto jefe
Governance Repository	Actas del Board, contratos, dispensas con vencimiento	Secretaría del Board
Requirements Repository	Tabla gobernada con origen, fase, estado y building block	Gestión de Requisitos
Solutions Landscape	Inventario de producción por transición	Operaciones de TI

Estándares que fija en el primer ciclo:

Estándar	Estado	Alcance
Integración entre aplicaciones por eventos con contrato versionado	Vigente	Toda integración nueva
API gateway como único punto de exposición de servicios a canales	Vigente	Todos los canales
Proveedor de identidad central para clientes y empleados	Vigente	Toda aplicación con usuarios
Nube pública con contenedores para componentes nuevos	Vigente	Componentes no ERP
ERP permanece en centro de datos propio	Vigente hasta nuevo ciclo	ERP y periféricos
Caché local en POS con operación de 4 horas sin red	Vigente	Tiendas
Un solo sistema de registro por entidad crítica	Vigente	Cliente, producto, pedido, inventario
Trazas, métricas y logs centralizados	Vigente	Componentes nuevos
Archivos batch nocturnos para integración	En retiro	Vence al cerrar T2
Interfaces punto a punto con el ERP	En retiro	Vence al cerrar T3
Modelado en ArchiMate para el Landscape	En evaluación	Decisión al cierre de T1
Datos personales con consentimiento registrado por canal	Vigente	Cliente único

Ejercicio práctico

Trabaja sobre el retail omnicanal o sobre tu organización.

1. Clasifica 10 building blocks de tu arquitectura objetivo en los cuatro niveles del Solutions Continuum. Para cada uno que caiga en Organization-Specific, escribe en una línea por qué no sirve una solución de industria.
2. Define el Architecture Metamodel de tu organización: lista las entidades del core que vas a usar y qué extensiones activas, con el motivo.
3. Dibuja en Mermaid la estructura de tu Architecture Repository con un dueño por área.
4. Escribe tres principios de arquitectura completos con nombre, enunciado, racional e implicaciones. Revisa que las implicaciones sean exigibles.
5. Construye el Stakeholder Map con al menos seis partes interesadas, su poder, interés, preocupación y el viewpoint que recibe cada una.
6. Completa una Business Transformation Readiness Assessment con cinco factores y una acción para cada factor con brecha alta.
7. Registra cinco riesgos con efecto, frecuencia, riesgo inicial, mitigación y riesgo residual.
8. Lista entre 8 y 12 estándares para la Standards Library con estado vigente, en evaluación o en retiro, y fecha de vencimiento para los que se retiran.
9. Decide si vas a usar ArchiMate: escribe en un párrafo qué ganarías y qué te costaría adoptarlo.

Autoevaluación

1. Un building block cae en el nivel Common Systems del Solutions Continuum. ¿Qué sugiere eso para la decisión de la fase E?

A. Que debe construirse a medida, porque es específico de la organización. B. Que pertenece a la arquitectura de negocio y no a la de tecnología. C. Que existen productos de mercado que lo resuelven y construirlo requiere justificación. D. Que no debe registrarse en el Architecture Repository.

2. ¿Cuál es la diferencia entre un artefacto y un entregable en el Content Framework?

A. El entregable es un producto formal aprobado y firmado que contiene artefactos; el artefacto describe un aspecto de la arquitectura como catálogo, matriz o diagrama. B. El artefacto se produce en la fase A y el entregable en la fase G. C. El artefacto es un building block de solución y el entregable es un building block de arquitectura. D. Son sinónimos; TOGAF usa ambos términos indistintamente.

3. ¿Qué parte de un principio de arquitectura lo convierte en exigible?

A. El nombre. B. El enunciado. C. El racional. D. Las implicaciones.

4. ¿En qué área del Architecture Repository se registran las dispensas concedidas por el Architecture Board?

A. Reference Library. B. Governance Repository. C. Standards Library. D. Solutions Landscape.

Respuestas

1. C. Common Systems agrupa dominios que muchas industrias comparten, como identidad o integración, con oferta madura de productos. Cuanto más a la izquierda del continuo, menos sentido tiene construir.
2. A. Entregable es el contenedor formal; artefacto es la descripción de un aspecto. Los building blocks son lo que los artefactos describen.
3. D. Las implicaciones dicen qué tiene que cambiar o cumplirse para respetar el principio; sin ellas el principio es una aspiración.
4. B. El Governance Repository guarda decisiones, contratos, revisiones de conformidad y dispensas. La Standards Library guarda estándares; la Reference Library, modelos y plantillas.

Checklist

• Los building blocks de la arquitectura objetivo están clasificados en el Enterprise Continuum y la decisión build, buy o reuse es coherente con esa clasificación.
• El Architecture Repository tiene las ocho áreas definidas, cada una con dueño y herramienta.
• El Architecture Metamodel declara qué entidades del core y qué extensiones usa la organización.
• Existe un Architecture Board con composición, calendario y atribuciones escritas.
• Los principios de arquitectura tienen nombre, enunciado, racional e implicaciones, y están en la Standards Library o la Reference Library.
• Hay un Stakeholder Map, una evaluación de preparación para la transformación y un registro de riesgos con riesgo inicial y residual.