← Volver al listado de tecnologías ← Índice de TOGAF, Doble Diamante y Design Thinking

Capítulo 14 — Fases B, C y D: negocio, sistemas de información y tecnología

15 de octubre de 2026 Por: Artiko

togafadmarquitectura-de-negocioarquitectura-de-datosarquitectura-de-aplicacionesarquitectura-tecnologicagap-analysis

Fases B, C y D: negocio, sistemas de información y tecnología

Con la visión aprobada en la fase A, el ADM entra en las tres fases que producen la arquitectura propiamente dicha. Las tres comparten la misma mecánica: describir la línea base (Baseline Architecture), describir el objetivo (Target Architecture), comparar ambas con un análisis de brechas (Gap Analysis) y registrar lo que sale en dos documentos que crecen fase a fase: el Architecture Definition Document y la Architecture Requirements Specification.

flowchart LR
    A["Fase A<br/>Visión de arquitectura"] --> B["Fase B<br/>Arquitectura de Negocio"]
    B --> C["Fase C<br/>Arquitecturas de Datos y Aplicaciones"]
    C --> D["Fase D<br/>Arquitectura Tecnológica"]
    D --> E["Fase E<br/>Oportunidades y Soluciones"]
    RM["Gestión de Requisitos"] <--> B
    RM <--> C
    RM <--> D
    B -. "Architecture Definition Document<br/>Architecture Requirements Specification" .-> D

Lo que cambia de una fase a otra es el dominio que se modela. TOGAF los llama los cuatro dominios de arquitectura: negocio, datos, aplicaciones y tecnología. La fase C cubre dos dominios a la vez (datos y aplicaciones), que juntos forman la arquitectura de sistemas de información.

La mecánica común a las tres fases

Los pasos del ADM son los mismos en B, C y D. Conviene aprenderlos una vez:

Paso	Qué se hace	Resultado
1	Seleccionar modelos de referencia, puntos de vista (viewpoints) y herramientas	Lista de artefactos que se van a producir y con qué notación
2	Desarrollar la descripción de la Arquitectura de Línea Base (Baseline)	Catálogos, matrices y diagramas del estado actual
3	Desarrollar la descripción de la Arquitectura Objetivo (Target)	Catálogos, matrices y diagramas del estado deseado
4	Realizar el análisis de brechas (Gap Analysis)	Matriz de brechas y lista de brechas
5	Definir los componentes candidatos del roadmap	Insumos para la fase E
6	Resolver impactos en el paisaje de arquitectura (Architecture Landscape)	Dependencias con otras arquitecturas en curso
7	Revisión formal con las partes interesadas	Observaciones registradas, viewpoints ajustados
8	Finalizar la arquitectura del dominio	Building blocks seleccionados, estándares fijados
9	Crear el Architecture Definition Document	Documento actualizado con la sección del dominio

El orden entre línea base y objetivo no es fijo. Cuando la organización no tiene documentación del estado actual, TOGAF admite empezar por el objetivo y describir solo la parte de la línea base que importa para la brecha. En el retail del caso, la línea base de aplicaciones está documentada en una hoja de cálculo de licencias; la de negocio no existe en ningún lado y hay que levantarla.

Tres tipos de artefacto

TOGAF organiza los artefactos en tres familias que reaparecen en cada dominio:

Catálogos: listas de elementos de un tipo (actores, entidades de datos, aplicaciones, tecnologías). Son el inventario.
Matrices: cruces entre dos tipos de elementos (actor/rol, aplicación/datos, aplicación/tecnología). Muestran relaciones.
Diagramas: representaciones gráficas para un público concreto (footprint de negocio, comunicación entre aplicaciones, entorno tecnológico).

Un artefacto describe un aspecto de la arquitectura. Un entregable (deliverable) es un producto de trabajo formal que se aprueba y firma, y que agrupa artefactos. El Architecture Definition Document es un entregable; el catálogo de aplicaciones es un artefacto que vive dentro de él.

Fase B: Arquitectura de Negocio

Objetivo

Describir cómo la empresa debe operar para alcanzar los objetivos fijados en la visión: qué capacidades necesita, cómo entrega valor, cómo se organiza y qué procesos ejecuta. La fase B es también la que da sentido a las otras dos: sin ella, los datos, aplicaciones y tecnología no tienen a qué servir.

Capacidades de negocio

Una capacidad de negocio (Business Capability) es algo que la empresa hace o necesita hacer, descrito con un sustantivo y sin decir cómo ni quién lo hace. “Gestión de pedidos” es una capacidad; “el sistema de pedidos de la tienda 12” no lo es.

El mapa de capacidades (Business Capability Map) las organiza en niveles. En el nivel 1 suele haber entre 8 y 15 capacidades; cada una se descompone en nivel 2 y, cuando hace falta, en nivel 3. El mapa de capacidades del retail del caso, en nivel 1, queda así:

Tipo	Capacidad nivel 1	Ejemplos de nivel 2
Estratégica	Gestión de la estrategia comercial	Planificación de surtido, definición de precios
Núcleo	Gestión de productos	Catálogo, atributos, contenido enriquecido
Núcleo	Gestión de clientes	Identidad de cliente, fidelización, consentimientos
Núcleo	Venta	Venta en tienda, venta web, venta por app
Núcleo	Gestión de pedidos	Captura, orquestación, cambios y devoluciones
Núcleo	Cumplimiento de pedidos	Picking, empaque, envío, retiro en tienda
Núcleo	Gestión de inventario	Disponibilidad por ubicación, reposición
Soporte	Gestión financiera	Facturación, cobranza, conciliación
Soporte	Gestión de personas	Dotación de tiendas, turnos
Soporte	Gestión de TI	Operación, seguridad

Sobre el mapa se dibuja el mapa de calor (heat map): cada capacidad se colorea según un criterio acordado con las partes interesadas, por ejemplo la brecha entre la madurez actual y la madurez requerida por la estrategia omnicanal. En el caso, “Gestión de pedidos” y “Gestión de clientes” quedan en rojo porque hoy hay un flujo de pedidos por canal y tres bases de clientes distintas.

Flujos de valor

Un flujo de valor (Value Stream) describe, de extremo a extremo, cómo la empresa entrega valor a una parte interesada. Se descompone en etapas, cada una con un valor entregado, y cada etapa se mapea a las capacidades que la habilitan. Ese mapeo es la pieza que conecta estrategia con arquitectura: muestra qué capacidades son críticas para el valor que la empresa quiere entregar.

flowchart LR
    subgraph VS["Value Stream: del pedido a la entrega"]
        direction LR
        E1["Elegir producto"] --> E2["Confirmar pedido"] --> E3["Preparar pedido"] --> E4["Entregar o retirar"] --> E5["Resolver posventa"]
    end
    E1 -.-> C1["Gestión de productos<br/>Gestión de inventario"]
    E2 -.-> C2["Venta<br/>Gestión de pedidos<br/>Gestión de clientes"]
    E3 -.-> C3["Cumplimiento de pedidos<br/>Gestión de inventario"]
    E4 -.-> C4["Cumplimiento de pedidos<br/>Gestión de personas"]
    E5 -.-> C5["Gestión de pedidos<br/>Gestión de clientes<br/>Gestión financiera"]

Etapa	Valor para el cliente	Parte interesada interna	Capacidades habilitadoras
Elegir producto	Encontrar lo que busca con disponibilidad real	Comercial, tiendas	Gestión de productos, Gestión de inventario
Confirmar pedido	Comprar en cualquier canal con un solo perfil	Ventas, Marketing	Venta, Gestión de pedidos, Gestión de clientes
Preparar pedido	Pedido completo y a tiempo	Logística, tiendas	Cumplimiento de pedidos, Gestión de inventario
Entregar o retirar	Elegir dónde y cuándo recibir	Logística, tiendas	Cumplimiento de pedidos, Gestión de personas
Resolver posventa	Cambiar o devolver en cualquier canal	Atención al cliente, Finanzas	Gestión de pedidos, Gestión de clientes, Gestión financiera

Organización, modelo de negocio y procesos

El mapa de organización (Organization Map) muestra unidades, ubicaciones y relaciones entre ellas; en el retail aparecen la matriz, las regiones, las tiendas y el centro de distribución, además de los socios logísticos externos. El modelo de negocio describe cómo la empresa crea y captura valor (segmentos, propuesta, canales, fuentes de ingreso); TOGAF no prescribe una plantilla, pero sí pide que esté explícito.

Los procesos describen la secuencia de actividades, con roles y eventos, que realiza una capacidad. Es la única de las vistas de negocio que entra en el “cómo”. Se modelan solo los procesos que cambian con la arquitectura objetivo; en el caso, “Captura de pedido” y “Devolución” cambian; “Cierre de caja” no.

Artefactos de la fase B

Familia	Artefacto	Para qué sirve en el caso
Catálogo	Organization/Actor catalog	Inventario de unidades y actores: cliente, vendedor, picker, repartidor
Catálogo	Driver/Goal/Objective catalog	Trazabilidad de la estrategia omnicanal a objetivos medibles
Catálogo	Role catalog	Roles que cruzan canales: asesor omnicanal, coordinador de retiro
Catálogo	Business Service/Function catalog	Servicios de negocio que expone cada capacidad
Catálogo	Business Capability catalog, Value Stream catalog	El mapa de capacidades y los flujos de valor en forma tabular
Matriz	Business Interaction matrix	Qué unidades interactúan entre sí y por qué
Matriz	Actor/Role matrix	Quién asume cada rol; muestra roles sin dueño
Matriz	Value Stream/Capability matrix	Qué capacidad habilita cada etapa
Diagrama	Business Footprint diagram	Enlaza metas, unidades, funciones y servicios con los componentes técnicos que los soportan
Diagrama	Business Service/Information diagram	Qué información necesita cada servicio de negocio
Diagrama	Functional Decomposition diagram	Capacidades y funciones por nivel
Diagrama	Product Lifecycle diagram	Estados del pedido desde creado hasta cerrado
Diagrama	Goal/Objective/Service diagram	Qué servicio aporta a qué objetivo
Diagrama	Business Use-Case diagram	Interacciones de actores con los servicios de negocio
Diagrama	Organization Decomposition diagram	Estructura organizativa
Diagrama	Process Flow diagram	Secuencia de actividades de los procesos que cambian
Diagrama	Event diagram	Eventos que disparan procesos: pedido confirmado, stock agotado

La matriz actor/rol para el retail, reducida a lo que importa en la brecha:

Actor \ Rol	Vendedor de tienda	Asesor omnicanal	Coordinador de retiro	Agente de posventa
Personal de tienda	Sí	Objetivo	Objetivo	No
Personal de contact center	No	Objetivo	No	Sí
Personal de logística	No	No	Sí	No

Los “Objetivo” marcan roles que hoy nadie asume y que la arquitectura objetivo requiere. Son brechas de negocio antes de ser brechas de sistemas.

Fase C: Arquitectura de Datos

Objetivo

Definir qué información necesita la empresa para operar las capacidades objetivo, quién la posee, dónde nace, cómo se comparte y qué calidad requiere. No es un modelo físico de base de datos: trabaja con entidades de negocio y sus relaciones.

Entidades, propiedad y ciclo de vida

La unidad de trabajo es la entidad de datos (Data Entity): cliente, producto, pedido, inventario, tienda, pago. Para cada entidad se registra la definición, el propietario de negocio (data owner), el sistema de registro (system of record) y las aplicaciones que la crean, leen, actualizan o eliminan.

El diagrama de ciclo de vida (Data Lifecycle diagram) muestra los estados por los que pasa una entidad y qué proceso la mueve de uno a otro. Para “Pedido” en el retail:

stateDiagram-v2
    [*] --> Borrador : cliente agrega productos
    Borrador --> Confirmado : pago aprobado
    Confirmado --> EnPreparacion : asignado a tienda o CD
    EnPreparacion --> ListoParaRetiro : picking completo y retiro en tienda
    EnPreparacion --> EnReparto : picking completo y envío a domicilio
    ListoParaRetiro --> Entregado : cliente retira
    EnReparto --> Entregado : repartidor confirma
    Entregado --> DevolucionSolicitada : cliente pide devolución
    DevolucionSolicitada --> Cerrado : reembolso emitido
    Entregado --> Cerrado : plazo de devolución vencido
    Cerrado --> [*]

Gobierno y calidad

La fase C es donde se fijan los principios de datos que la fase Preliminar dejó enunciados: un solo sistema de registro por entidad, propietario nombrado, definiciones compartidas. En el caso, el principio “cliente único” obliga a decidir qué sistema es el registro maestro de “Cliente” y cómo las demás aplicaciones consumen esa identidad. También se registran requisitos de calidad (completitud, unicidad, vigencia) y de cumplimiento normativo (consentimientos, retención).

Artefactos de la fase C para datos

Familia	Artefacto	Para qué sirve en el caso
Catálogo	Data Entity/Data Component catalog	Inventario de entidades y de los componentes lógicos y físicos que las almacenan
Matriz	Data Entity/Business Function matrix	Qué función de negocio crea, lee o actualiza cada entidad
Matriz	Application/Data matrix	Qué aplicación maneja cada entidad; muestra entidades con varios registros
Diagrama	Conceptual Data diagram	Entidades y relaciones sin detalle de atributos
Diagrama	Logical Data diagram	Atributos principales y claves de negocio
Diagrama	Data Dissemination diagram	Cómo viajan los datos entre aplicaciones y servicios
Diagrama	Data Security diagram	Quién accede a qué datos y con qué nivel de protección
Diagrama	Data Migration diagram	Qué datos se mueven de dónde a dónde en la transición
Diagrama	Data Lifecycle diagram	Estados de cada entidad crítica

Matriz aplicación/datos de la línea base del retail, donde se ve la brecha de cliente único:

Entidad \ Aplicación	POS tiendas	E-commerce	App móvil	ERP	CRM
Cliente	Crea, lee	Crea, lee, actualiza	Crea, lee	Lee	Crea, lee, actualiza
Producto	Lee	Crea, actualiza	Lee	Crea, actualiza	No
Pedido	Crea, actualiza	Crea, actualiza	Crea	Lee	Lee
Inventario	Lee, actualiza	Lee	Lee	Crea, actualiza	No

Tres aplicaciones crean clientes y dos crean productos. Esa es la raíz de que el cliente web no exista en tienda y de que el catálogo tenga atributos distintos por canal.

Fase C: Arquitectura de Aplicaciones

Objetivo

Definir qué aplicaciones (componentes lógicos, no productos concretos) necesita la empresa para procesar los datos y soportar las capacidades, cómo interactúan entre sí y qué servicios exponen. La fase decide qué hace cada aplicación, no con qué tecnología está hecha; eso es la fase D.

Portafolio y comunicación

El portafolio de aplicaciones (Application Portfolio catalog) lista cada componente de aplicación con su propósito, propietario, estado (activa, en retiro, planificada) y las capacidades que soporta. Sobre el portafolio se construyen las matrices que muestran cobertura: aplicación/organización (quién la usa), aplicación/función (qué función de negocio soporta) e interfaz (quién habla con quién).

El diagrama de comunicación de aplicaciones (Application Communication diagram) es el artefacto más consultado de la fase. Muestra los flujos de información entre componentes y es donde se hace visible la duplicación. Arquitectura objetivo del retail:

flowchart TB
    subgraph Canales
        POS["POS tiendas"]
        WEB["E-commerce"]
        APP["App móvil"]
        CC["Contact center"]
    end
    subgraph Plataforma["Plataforma omnicanal objetivo"]
        OMS["OMS<br/>Orquestación de pedidos"]
        PIM["PIM<br/>Información de producto"]
        CDP["Cliente único<br/>Identidad y perfil"]
        INV["Inventario unificado<br/>Disponibilidad por ubicación"]
    end
    subgraph Backend
        ERP["ERP"]
        WMS["WMS centro de distribución"]
        PAY["Pasarela de pagos"]
    end
    POS --> OMS
    WEB --> OMS
    APP --> OMS
    CC --> OMS
    POS --> CDP
    WEB --> CDP
    APP --> CDP
    CC --> CDP
    WEB --> PIM
    APP --> PIM
    POS --> PIM
    OMS --> INV
    OMS --> PAY
    OMS --> WMS
    OMS --> ERP
    INV --> ERP
    INV --> WMS
    PIM --> ERP

En la línea base, cada canal habla directamente con el ERP y mantiene su propio pedido y su propio cliente. En el objetivo, los canales se vuelven delgados y la lógica de pedido, cliente, producto e inventario vive en cuatro componentes compartidos.

Artefactos de la fase C para aplicaciones

Familia	Artefacto	Para qué sirve en el caso
Catálogo	Application Portfolio catalog	Inventario de componentes con estado y propietario
Catálogo	Interface catalog	Interfaces entre aplicaciones, con protocolo y dueño
Matriz	Application/Organization matrix	Qué unidades usan cada aplicación
Matriz	Role/Application matrix	Qué roles acceden a qué aplicación
Matriz	Application/Function matrix	Cobertura de funciones de negocio; muestra huecos y solapes
Matriz	Application Interaction matrix	Qué aplicación consume o provee a cuál
Diagrama	Application Communication diagram	Flujos de información entre componentes
Diagrama	Application and User Location diagram	Dónde corre y desde dónde se usa cada aplicación
Diagrama	Application Use-Case diagram	Interacciones de actores con servicios de aplicación
Diagrama	Enterprise Manageability diagram	Cómo se operan y monitorean las aplicaciones
Diagrama	Process/Application Realization diagram	Qué aplicación realiza cada paso de un proceso
Diagrama	Software Engineering diagram	Estructura interna de componentes que se construyen
Diagrama	Application Migration diagram	De qué componente base a qué componente objetivo
Diagrama	Software Distribution diagram	Distribución de componentes en el entorno

Matriz aplicación/función (objetivo) con las funciones que importan en la brecha:

Función \ Aplicación	OMS	PIM	Cliente único	Inventario unificado	ERP
Capturar pedido	Primaria	No	Lee	Lee	No
Orquestar cumplimiento	Primaria	No	No	Lee	Informa
Mantener catálogo	No	Primaria	No	No	Origen de SKU
Resolver identidad de cliente	Lee	No	Primaria	No	No
Calcular disponibilidad	Lee	No	No	Primaria	Origen de stock contable
Facturar	Informa	No	Lee	No	Primaria

Fase D: Arquitectura Tecnológica

Objetivo

Definir las plataformas, la infraestructura, las redes y los estándares técnicos que soportan las aplicaciones y los datos. TOGAF llama a sus elementos servicios tecnológicos y componentes tecnológicos; la fase D los describe como componentes lógicos (por ejemplo, “plataforma de integración de eventos”) y como componentes físicos (el producto o servicio concreto que los realiza).

Plataformas y estándares

La fase D fija los estándares que las fases E a G harán cumplir: cómo se integran las aplicaciones, dónde se despliegan, cómo se autentican, cómo se observan. En el caso, el retail opera un centro de datos propio para el ERP y el POS, y la plataforma omnicanal objetivo se decide como nube pública con integración por eventos. Las decisiones se registran como estándares en el repositorio (capítulo 16).

Dominio técnico	Línea base	Objetivo
Integración	Interfaces punto a punto, archivos batch nocturnos	Bus de eventos y API gateway con contratos versionados
Despliegue	Servidores físicos en centro de datos propio	Contenedores en nube pública; ERP permanece en el centro de datos
Identidad	Usuarios locales por aplicación	Proveedor de identidad central para empleados y clientes
Datos	Bases relacionales por aplicación	Plataforma de datos con zona de integración y catálogo
Observabilidad	Logs por servidor	Trazas, métricas y logs centralizados
Red	VPN entre tiendas y centro de datos	Conectividad gestionada a nube con redundancia por tienda

Artefactos de la fase D

Familia	Artefacto	Para qué sirve en el caso
Catálogo	Technology Standards catalog	Estándares aprobados, en evaluación y en retiro
Catálogo	Technology Portfolio catalog	Inventario de productos y versiones en uso
Matriz	Application/Technology matrix	Qué tecnología soporta cada aplicación; muestra versiones obsoletas
Diagrama	Environments and Locations diagram	Qué corre en cada entorno y ubicación: tiendas, CD, centro de datos, nube
Diagrama	Platform Decomposition diagram	Capas de la plataforma objetivo
Diagrama	Processing diagram	Cómo se agrupan y despliegan las unidades de procesamiento
Diagrama	Networked Computing/Hardware diagram	Topología de red y hardware
Diagrama	Network Computing diagram	Conectividad lógica
Diagrama	Communications Engineering diagram	Enlaces físicos y anchos de banda

Matriz aplicación/tecnología objetivo (fragmento):

Aplicación \ Tecnología	Nube pública contenedores	Centro de datos propio	Bus de eventos	API gateway	Proveedor de identidad
OMS	Sí	No	Publica y consume	Expone	Consume
PIM	Sí	No	Publica	Expone	Consume
Cliente único	Sí	No	Publica	Expone	Consume
Inventario unificado	Sí	No	Consume y publica	Expone	Consume
ERP	No	Sí	Publica vía adaptador	Consume	Integra
POS tiendas	Parcial, caché local	Sí	Consume	Consume	Consume

Análisis de brechas

El análisis de brechas se ejecuta en cada fase con la misma técnica: una matriz con los building blocks de la línea base en las filas y los de la arquitectura objetivo en las columnas. En la intersección se registra si el bloque se mantiene (retained), si cambia, o si queda eliminado (eliminated). La última fila “Nuevo” recoge los bloques objetivo que no tienen origen en la base; la última columna “Eliminado” recoge los bloques base que no sobreviven. Eliminados que nadie decidió eliminar son hallazgos: algo se olvidó en el objetivo.

flowchart TD
    BL["Línea base<br/>building blocks actuales"] --> GA{"Matriz de brechas"}
    TG["Objetivo<br/>building blocks deseados"] --> GA
    GA --> R["Retenidos<br/>sin cambio o con cambio"]
    GA --> N["Nuevos<br/>fila Nuevo"]
    GA --> E["Eliminados<br/>columna Eliminado"]
    E --> Q{"¿Eliminación intencional?"}
    Q -- "No" --> F["Hallazgo: falta en el objetivo"]
    Q -- "Sí" --> OK["Registrar como brecha de retiro"]
    N --> G["Lista de brechas"]
    R --> G
    OK --> G
    F --> TG

Matriz de brechas de aplicaciones del retail:

Línea base \ Objetivo	OMS	PIM	Cliente único	Inventario unificado	ERP	Eliminado
Módulo de pedidos web	Migra lógica	No	No	No	No	Sí
Módulo de pedidos POS	Migra lógica	No	No	No	No	Sí
Catálogo web	No	Migra datos	No	No	No	Sí
Maestro de artículos ERP	No	Fuente de SKU	No	No	Retenido	No
Base de clientes CRM	No	No	Migra datos	No	No	Sí
Base de clientes web	No	No	Migra datos	No	No	Sí
Stock ERP	No	No	No	Fuente contable	Retenido	No
Nuevo	Sí	Sí	Sí	Sí	No

Brechas consolidadas de las tres fases para el caso:

Dominio	Brecha	Tipo
Negocio	Roles de asesor omnicanal y coordinador de retiro sin dueño	Nuevo
Negocio	Proceso de devolución cruzada entre canales inexistente	Nuevo
Datos	Tres registros de cliente sin identidad común	Consolidación
Datos	Atributos de producto distintos por canal	Consolidación
Datos	Disponibilidad no refleja stock de tiendas en tiempo real	Nuevo
Aplicaciones	No existe orquestación de pedidos entre canales	Nuevo, OMS
Aplicaciones	No existe repositorio maestro de información de producto	Nuevo, PIM
Aplicaciones	Dos módulos de pedidos y dos bases de clientes a retirar	Eliminación
Tecnología	Integración punto a punto y batch	Reemplazo por eventos
Tecnología	Sin proveedor de identidad para clientes	Nuevo
Tecnología	Conectividad de tiendas sin redundancia	Mejora

Los dos documentos que crecen

El Architecture Definition Document (documento de definición de arquitectura) es el contenedor cualitativo: describe línea base, objetivo, brechas, decisiones y racional para cada dominio. Se crea en la fase A con la visión y se completa en B, C y D con la sección de cada dominio. Lo lee quien necesita entender la arquitectura.

La Architecture Requirements Specification (especificación de requisitos de arquitectura) es el contenedor cuantitativo: requisitos medibles, criterios de aceptación, restricciones y supuestos que la implementación debe cumplir. Se usa como base del contrato de arquitectura en la fase G. Lo lee quien construye.

Documento	Contenido típico tras la fase D en el caso
Architecture Definition Document	Alcance, principios aplicados, mapa de capacidades y heat map, flujos de valor, diagramas de comunicación base y objetivo, catálogo tecnológico, matrices de brechas por dominio, decisiones de nube e integración
Architecture Requirements Specification	”El sistema de registro de Cliente responde una búsqueda por identidad en menos de 300 ms”, “Toda nueva integración publica eventos con contrato versionado”, “El POS opera 4 horas sin conectividad”, restricciones de cumplimiento de datos personales, supuestos sobre fechas de contratos vigentes

Roadmap de componentes candidatos

Cada fase cierra con una lista de componentes candidatos del roadmap: los building blocks que hay que crear, cambiar o retirar para cerrar las brechas, con dependencias preliminares. La fase E consolida las tres listas en un Architecture Roadmap único (capítulo 15). Para el retail, los candidatos tras la fase D:

Componente candidato	Origen de la brecha	Depende de
Proveedor de identidad	Tecnología, datos	Nada
Cliente único	Datos, negocio	Proveedor de identidad
Bus de eventos y API gateway	Tecnología	Nada
PIM	Datos, aplicaciones	Bus de eventos
Inventario unificado	Datos	Bus de eventos, adaptador ERP
OMS	Aplicaciones, negocio	Cliente único, PIM, Inventario unificado
Retiro de módulos de pedido y bases de cliente	Aplicaciones	OMS, Cliente único en producción
Redundancia de conectividad en tiendas	Tecnología	Nada

Ejercicio práctico

Trabaja sobre el retail omnicanal del caso o sobre tu propia organización.

Dibuja el mapa de capacidades de nivel 1 con 8 a 12 capacidades, separadas en estratégicas, núcleo y soporte. Pinta el heat map con un solo criterio: brecha entre madurez actual y requerida.
Describe un flujo de valor de extremo a extremo en 4 a 6 etapas. Para cada etapa escribe el valor entregado y las capacidades habilitadoras. Marca qué etapa concentra más capacidades en rojo.
Construye la matriz actor/rol de la arquitectura objetivo. Marca con “Objetivo” los roles que hoy no tienen dueño.
Lista las 6 a 10 entidades de datos críticas y completa la matriz aplicación/datos de la línea base. Identifica toda entidad con más de un creador.
Dibuja en Mermaid el diagrama de comunicación de aplicaciones de la línea base y el del objetivo. Cuenta las interfaces en cada uno.
Completa la tabla línea base/objetivo por dominio técnico (integración, despliegue, identidad, datos, observabilidad, red).
Arma la matriz de brechas de aplicaciones. Revisa que cada “Eliminado” sea intencional.
Escribe 5 requisitos medibles para la Architecture Requirements Specification y 5 componentes candidatos con dependencias para el roadmap.

Autoevaluación

1. ¿Qué distingue a una capacidad de negocio de un proceso de negocio?

A. La capacidad describe qué hace la empresa sin decir cómo; el proceso describe la secuencia de actividades y roles. B. La capacidad se modela en la fase C; el proceso en la fase B. C. La capacidad siempre corresponde a una aplicación; el proceso a una unidad organizativa. D. No hay diferencia; TOGAF usa ambos términos como sinónimos.

2. En la matriz de brechas, ¿qué significa un building block de la línea base que aparece en la columna “Eliminado” sin que nadie haya decidido retirarlo?

A. Que el bloque es obsoleto y debe retirarse de inmediato. B. Que el bloque pertenece a otro dominio de arquitectura. C. Que la arquitectura objetivo lo omitió por accidente y hay que revisarla. D. Que el bloque se mantiene sin cambios.

3. ¿Qué documento recoge los requisitos medibles y criterios de aceptación que la implementación debe cumplir?

A. Architecture Definition Document. B. Architecture Vision. C. Architecture Roadmap. D. Architecture Requirements Specification.

4. ¿Cuál de estos artefactos pertenece a la fase D?

A. Application Communication diagram. B. Environments and Locations diagram. C. Data Lifecycle diagram. D. Business Footprint diagram.

Respuestas

A. La capacidad es el qué, estable en el tiempo; el proceso es el cómo, con actividades, roles y eventos. Ambos se modelan en la fase B.
C. Un eliminado no intencional es el hallazgo clásico del análisis de brechas: algo de la línea base se olvidó al describir el objetivo.
D. La Architecture Requirements Specification es el contenedor cuantitativo; el Architecture Definition Document es el cualitativo.
B. El diagrama de entornos y ubicaciones es de arquitectura tecnológica. Los otros tres son de aplicaciones, datos y negocio respectivamente.

Checklist

El mapa de capacidades tiene niveles y un heat map con criterio acordado con las partes interesadas.
Al menos un flujo de valor está mapeado a capacidades etapa por etapa.
Cada entidad de datos crítica tiene propietario y un único sistema de registro en el objetivo.
Existen diagramas de comunicación de aplicaciones de línea base y de objetivo.
La matriz de brechas de cada dominio fue revisada y todo “Eliminado” es intencional.
El Architecture Definition Document y la Architecture Requirements Specification están actualizados con las secciones B, C y D y hay una lista de componentes candidatos con dependencias.