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

Capítulo 13 — Fase Preliminar y fase A: Visión de la Arquitectura

15 de octubre de 2026 Por: Artiko

togafarquitectura-empresarialfase-preliminararchitecture-visionstakeholdersprincipios

Fase Preliminar y fase A: Visión de la Arquitectura

Las dos primeras fases del ADM deciden si el trabajo de arquitectura tendrá sentido. La fase Preliminar construye la capacidad de hacerlo; la fase A acuerda qué se va a hacer, para quién y con qué alcance. Este capítulo las desarrolla y las aplica a un caso que acompañará el resto del módulo: una cadena de retail mediana que quiere unificar sus canales.

El caso: Almacenes Norte

Almacenes Norte opera 38 tiendas físicas, una tienda en línea y una aplicación móvil. Cada canal nació en un momento distinto y hoy tiene su propio catálogo, su propia política de precios y su propio inventario. Un cliente puede ver un producto disponible en la app, llegar a la tienda y no encontrarlo. Las devoluciones de compras en línea solo se aceptan por correo. La dirección ha decidido que en dos años el cliente debe percibir una sola marca con un solo inventario, cualquiera sea el canal.

Fase Preliminar

Objetivo

Preparar la organización para hacer arquitectura con éxito: decidir quién, con qué método, bajo qué principios y con qué gobierno.

Definir la organización afectada

La fase empieza acotando el alcance organizativo:

Tipo de unidad	Definición	En Almacenes Norte
Núcleo (core)	Unidades que más se benefician y más se ven afectadas	Comercial, Operaciones de tienda, Comercio electrónico, TI
Blandas (soft)	Unidades que verán cambios en su trabajo pero no están al centro	Logística, Finanzas, Atención al cliente
Extendidas (extended)	Unidades fuera de la empresa afectadas	Proveedores con integración de inventario, operador logístico, pasarela de pagos
Comunidades y gobierno	Grupos de interés y entes reguladores	Autoridad de protección al consumidor, autoridad de protección de datos

Definir la Architecture Capability

La capacidad de arquitectura (Architecture Capability) se compone de personas, procesos, herramientas y gobierno.

mindmap
  root((Architecture Capability))
    Personas
      Arquitecto empresarial líder
      Arquitectos de dominio
      Patrocinador ejecutivo
      Architecture Board
    Procesos
      ADM adaptado
      Revisión de cumplimiento
      Gestión de dispensas
      Gestión de requisitos
    Herramientas
      Repositorio de modelos
      Lenguaje ArchiMate
      Gestor de requisitos
    Gobierno
      Principios
      Estándares
      Contratos de arquitectura

En Almacenes Norte no existe un equipo de arquitectura. La fase Preliminar propone uno mínimo: un arquitecto empresarial a tiempo completo, dos arquitectos de dominio (negocio y aplicaciones) compartidos con TI y un Architecture Board formado por el gerente comercial, el gerente de TI, el responsable de comercio electrónico y el director de operaciones.

Adaptar los marcos

Se decide qué se toma de TOGAF y cómo convive con lo que ya hay:

Marco existente	Decisión
Scrum en los equipos de desarrollo	Las fases G y H se sincronizan con las revisiones de sprint y los Program Increments
PMO con metodología propia	Los paquetes de trabajo de la fase F entran como proyectos en el portafolio de la PMO
ITIL para operaciones	Los cambios de la fase H pasan por el comité de cambios de operaciones
Lenguaje de modelado	Se adopta ArchiMate para todos los artefactos

Principios de arquitectura

Un principio de arquitectura (Architecture Principle) es una regla duradera que guía decisiones. TOGAF propone un formato de cuatro partes:

Parte	Contenido
Nombre	Corto y memorable
Enunciado (Statement)	La regla en una o dos frases
Razón (Rationale)	Por qué conviene al negocio
Implicaciones (Implications)	Qué cambia en la práctica si se cumple

Principios de Almacenes Norte:

Nombre	Enunciado	Razón	Implicaciones
Un solo cliente	Toda interacción con un cliente, en cualquier canal, se asocia a una identidad única	La omnicanalidad exige reconocer al cliente en la tienda, la web y la app	Registro único, consentimiento de datos unificado, migración de las bases de clientes de cada canal
El inventario es un activo compartido	Existe una única fuente de verdad del stock, consultable en tiempo real por todos los canales	Evita vender lo que no hay y permite retirar en tienda lo comprado en línea	Servicio de inventario central, integración con los puntos de venta, reglas de reserva
Cumplimiento normativo	Los datos personales se tratan conforme a la ley de protección de datos vigente y los procesos de venta respetan la ley del consumidor	Reduce riesgo legal y reputacional	Clasificación de datos, consentimiento explícito, trazabilidad de devoluciones
Interoperabilidad por contrato	Los sistemas se integran mediante interfaces documentadas y versionadas, nunca por acceso directo a bases de datos ajenas	Permite reemplazar componentes sin romper los demás	Catálogo de API, gobierno de versiones, pruebas de contrato
Comprar antes que construir	Para capacidades no diferenciadoras se prefiere un producto de mercado	El equipo de desarrollo es pequeño y debe concentrarse en lo que distingue a la marca	Criterios de evaluación de proveedores, presupuesto de licencias

Herramientas y gobierno

Se elige una herramienta de modelado que soporte ArchiMate y un repositorio de requisitos. Se formaliza el Architecture Board con un reglamento: frecuencia de reunión, quórum, qué decisiones requieren su aprobación (nuevos principios, dispensas, cambios al roadmap) y cómo se registran en el Governance Log.

Salidas de la fase

Modelo organizativo para la arquitectura (Organizational Model for Enterprise Architecture).
Marco de arquitectura adaptado (Tailored Architecture Framework).
Principios de arquitectura aprobados.
Repositorio inicial con metamodelo y herramientas.
Solicitud de trabajo de arquitectura (Request for Architecture Work): el documento con el que el patrocinador pide formalmente que empiece un ciclo. En el caso, la emite la dirección comercial con el título “Unificación de canales de venta”.

Fase A: Visión de la Arquitectura

Objetivo

Obtener la aprobación de un ciclo de arquitectura con alcance, stakeholders, visión, propuesta de valor y riesgos acordados.

Pasos

flowchart TD
    S1["Establecer el proyecto de arquitectura"] --> S2["Identificar stakeholders, preocupaciones y requisitos de negocio"]
    S2 --> S3["Confirmar objetivos, drivers y restricciones"]
    S3 --> S4["Evaluar capacidades de negocio"]
    S4 --> S5["Evaluar la preparación para la transformación"]
    S5 --> S6["Definir el alcance"]
    S6 --> S7["Confirmar principios"]
    S7 --> S8["Desarrollar la Architecture Vision"]
    S8 --> S9["Definir propuesta de valor y KPI"]
    S9 --> S10["Identificar riesgos y mitigaciones"]
    S10 --> S11["Redactar el Statement of Architecture Work y obtener aprobación"]

Identificar stakeholders

Un stakeholder es cualquier persona o grupo con interés en la arquitectura. TOGAF adopta el vocabulario de la norma ISO/IEC/IEEE 42010:

Término	Definición
Preocupación (concern)	Interés de un stakeholder respecto al sistema: coste, seguridad, usabilidad, continuidad
Punto de vista (viewpoint)	Convención sobre cómo construir y usar una vista: qué modelos, qué notación, para qué preocupaciones
Vista (view)	Representación concreta de la arquitectura desde un viewpoint

La técnica de gestión de stakeholders (Stakeholder Management) clasifica a cada uno por poder e interés para decidir cómo involucrarlo:

quadrantChart
    title Mapa de stakeholders de Almacenes Norte
    x-axis Bajo interés --> Alto interés
    y-axis Bajo poder --> Alto poder
    quadrant-1 Gestionar de cerca
    quadrant-2 Mantener satisfechos
    quadrant-3 Monitorear
    quadrant-4 Mantener informados
    Dirección general: [0.55, 0.92]
    Gerencia comercial: [0.9, 0.85]
    Gerencia de TI: [0.88, 0.75]
    Responsable e-commerce: [0.95, 0.55]
    Gerentes de tienda: [0.7, 0.35]
    Finanzas: [0.3, 0.7]
    Operador logístico: [0.5, 0.3]
    Proveedores: [0.2, 0.25]
    Clientes: [0.8, 0.2]

Stakeholder	Preocupaciones principales	Viewpoint adecuado
Dirección general	Retorno de la inversión, plazo de dos años, riesgo reputacional	Visión de valor, roadmap de alto nivel
Gerencia comercial	Ventas cruzadas entre canales, precios coherentes	Flujos de valor, mapa de capacidades
Gerencia de TI	Integración, deuda técnica, capacidad del equipo	Diagrama de aplicaciones, estándares
Responsable e-commerce	Experiencia del cliente, conversión, rendimiento	Journey del cliente, diagrama de uso de aplicaciones
Gerentes de tienda	Que el punto de venta no se vuelva más lento, devoluciones claras	Diagrama de procesos de tienda
Finanzas	Coste total, licencias, amortización	Plan de migración con costes
Operador logístico	Interfaces de pedidos y stock	Diagrama de interfaces
Clientes	Ver el stock real, devolver en cualquier canal	Mapa de empatía y journey map del módulo 2

Esta tabla es el punto donde el trabajo de empatía del Design Thinking entra en TOGAF: las preocupaciones de los clientes no se inventan en una reunión, se traen de las entrevistas y los journey maps del capítulo 3.

Confirmar objetivos, drivers y restricciones

Tipo	Contenido en el caso
Drivers	Caída de ventas en tienda, crecimiento del canal digital, quejas por stock inconsistente
Objetivos	Un inventario único; devoluciones en cualquier canal; identidad única de cliente; retirar en tienda lo comprado en línea
Restricciones	Presupuesto anual fijo; el sistema de punto de venta no se cambia en el primer año; ley de protección de datos

Escenarios de negocio

La técnica de escenarios de negocio (Business Scenarios) sirve para descubrir y documentar requisitos de negocio con un problema concreto como hilo conductor. Un escenario describe:

Elemento	Contenido
Problema	La situación que se quiere resolver, en términos de negocio
Entorno de negocio y técnico	Dónde ocurre, con qué sistemas
Objetivos	Qué resultado se espera
Actores humanos	Quién participa y qué rol tiene
Actores informáticos	Qué sistemas intervienen
Roles y responsabilidades	Qué hace cada actor en el escenario
Medidas de éxito	Cómo se sabrá que se resolvió

Escenario de Almacenes Norte, “Compra en línea, retiro en tienda”:

Problema: una clienta compra en la app un producto marcado como disponible, elige retirar en la tienda más cercana y al llegar el producto no está. La tienda no tiene registro del pedido.
Actores humanos: clienta, vendedor de tienda, operador de bodega, agente de atención al cliente.
Actores informáticos: app móvil, plataforma de comercio electrónico, sistema de punto de venta, sistema de inventario de bodega.
Objetivo: que el pedido reserve el stock en la tienda elegida y la tienda lo tenga preparado.
Medidas de éxito: porcentaje de retiros completados en la primera visita, tiempo entre pedido y confirmación de la tienda.

El escenario se refina con los stakeholders hasta que todos lo reconocen como SMART: específico, medible, accionable, realista y acotado en el tiempo. De él salen requisitos que van al repositorio de la Gestión de Requisitos.

Evaluación de capacidades

La evaluación de capacidades (Capability Assessment) mide el punto de partida en tres planos:

Plano	Pregunta	Hallazgo en el caso
Capacidad de negocio	¿Qué sabe hacer hoy la organización y qué le falta?	Gestión de pedidos por canal madura; gestión de inventario unificado inexistente
Capacidad de TI	¿Qué puede entregar el área de TI?	Equipo pequeño, buena experiencia en integración, poca en datos maestros
Madurez de arquitectura	¿Qué nivel de práctica de arquitectura existe?	Inicial: no hay repositorio ni principios previos a la fase Preliminar

Preparación para la transformación

La evaluación de preparación para la transformación del negocio (Business Transformation Readiness Assessment) revisa factores como visión compartida, deseo y voluntad, necesidad percibida, financiación, patrocinio, gobierno, capacidad de absorber el cambio y habilidades de TI. Cada factor se puntúa en madurez actual, madurez objetivo y urgencia.

Factor	Actual	Objetivo	Riesgo si no se cierra
Visión compartida	Baja: cada canal defiende su autonomía	Alta	Resistencia de los gerentes de canal
Patrocinio	Alta: dirección general comprometida	Alta	Bajo
Financiación	Media: presupuesto aprobado solo para el primer año	Alta	Interrupción en el segundo año
Habilidades de TI	Media	Alta	Dependencia de consultores externos
Capacidad de absorber el cambio	Baja en tiendas: alta rotación de personal	Media	Formación continua, procesos simples

Definir el alcance

Dimensión	Decisión
Amplitud	Procesos de venta, devolución, inventario e identidad de cliente en los tres canales
Profundidad	Nivel de segmento: capacidades, procesos y aplicaciones; sin diseño detallado de interfaces
Periodo	Arquitectura objetivo a dos años, con una arquitectura de transición a los doce meses
Dominios	Los cuatro BDAT, con énfasis en negocio y datos

La Architecture Vision

La Visión de la Arquitectura (Architecture Vision) es una descripción de alto nivel de la arquitectura objetivo, suficiente para que los stakeholders la entiendan y la aprueben sin entrar en detalles de dominio. Suele incluir un diagrama de solución conceptual y un resumen de la propuesta de valor.

flowchart LR
    subgraph Canales
        T["Tienda física"]
        W["Tienda en línea"]
        M["App móvil"]
    end
    subgraph Núcleo["Servicios compartidos"]
        ID["Identidad única de cliente"]
        INV["Inventario único en tiempo real"]
        PED["Gestión de pedidos omnicanal"]
        PRE["Precios y promociones"]
    end
    subgraph Backend
        ERP["ERP"]
        BOD["Bodegas y logística"]
        PAG["Pagos"]
    end
    T --> ID & INV & PED & PRE
    W --> ID & INV & PED & PRE
    M --> ID & INV & PED & PRE
    PED --> ERP & BOD & PAG
    INV --> BOD

Enunciado de la visión para Almacenes Norte: “Una experiencia de compra única: el cliente es reconocido en cualquier canal, ve el stock real de cualquier tienda y puede comprar, retirar y devolver donde prefiera”.

Propuesta de valor y KPI

Beneficio	KPI	Línea base	Objetivo a dos años
Menos ventas perdidas por stock inconsistente	Pedidos cancelados por falta de stock	7 %	Menos de 1 %
Más retiros en tienda	Porcentaje de pedidos en línea retirados en tienda	4 %	25 %
Clientes reconocidos	Porcentaje de transacciones asociadas a una identidad	35 %	85 %
Devoluciones simples	Tiempo medio de devolución	9 días	1 día

Riesgos iniciales

Riesgo	Probabilidad	Impacto	Mitigación
Resistencia de los gerentes de canal	Alta	Alto	Incluirlos en el Architecture Board; medir KPI por canal y por total
Calidad de datos maestros de producto insuficiente	Alta	Alto	Proyecto de saneamiento previo en la fase C
Punto de venta no integrable en el primer año	Media	Alto	Arquitectura de transición con sincronización periódica
Presupuesto del segundo año no aprobado	Media	Alto	Paquetes de trabajo con valor demostrable a los doce meses

Plan de comunicaciones

El plan de comunicaciones (Communications Plan) define qué se comunica, a quién, con qué frecuencia y por qué medio.

Audiencia	Mensaje	Frecuencia	Medio
Dirección general	Avance frente a KPI y riesgos	Mensual	Informe de una página
Architecture Board	Decisiones pendientes, dispensas	Quincenal	Reunión
Gerentes de tienda	Qué cambiará en su trabajo y cuándo	Por hito	Reunión regional y vídeo corto
Equipos de desarrollo	Principios, estándares, contratos	Por sprint	Repositorio y sesión de arquitectura
Clientes	Nuevos servicios disponibles	Por lanzamiento	Marketing

Statement of Architecture Work

La Declaración de Trabajo de Arquitectura (Statement of Architecture Work) es el contrato entre el patrocinador y el equipo de arquitectura. Resumen para el caso:

Sección	Contenido
Título	Unificación de canales de venta de Almacenes Norte
Patrocinador	Dirección comercial, con respaldo de la dirección general
Alcance	Venta, devolución, inventario e identidad de cliente en tienda, web y app; nivel de segmento; cuatro dominios
Visión	Experiencia de compra única con inventario e identidad compartidos
Deliverables	Architecture Definition Document, Architecture Roadmap, Implementation and Migration Plan, contratos de arquitectura
Plan y hitos	Fases B a D en cuatro meses; E y F en dos meses; G durante veinte meses; H continuo
Recursos	Un arquitecto empresarial, dos arquitectos de dominio, consultoría de datos maestros
Criterios de aceptación	Aprobación del Architecture Board; KPI con línea base y objetivo definidos
Riesgos aceptados	Los cuatro de la tabla anterior con sus mitigaciones

Con la firma del Statement of Architecture Work termina la fase A.

Puente al capítulo 14

La fase A dejó una visión aprobada, un alcance, stakeholders con sus preocupaciones y un repositorio de requisitos que empieza a llenarse. El capítulo 14 toma esa base y construye las arquitecturas de negocio, de sistemas de información y tecnológica de Almacenes Norte: mapa de capacidades, flujos de valor, catálogo de aplicaciones, modelo de datos maestros y plataforma objetivo, con el análisis de brechas que alimentará el roadmap.

Ejercicio práctico

Aplica las dos fases a tu organización o, si prefieres, completa el caso de Almacenes Norte.

Clasifica las unidades de tu organización en núcleo, blandas, extendidas y comunidades para un cambio que conozcas.
Redacta tres principios de arquitectura con las cuatro partes (nombre, enunciado, razón, implicaciones). Revisa que las implicaciones sean concretas y verificables.
Construye el mapa de stakeholders en un quadrantChart de Mermaid y, para cada uno, escribe su preocupación principal y el viewpoint que la atiende.
Escribe un escenario de negocio completo con los siete elementos de la tabla y verifica que sea SMART.
Redacta la Architecture Vision en una frase y la propuesta de valor con al menos tres KPI con línea base y objetivo.
Resume el Statement of Architecture Work en una tabla de nueve filas como la del capítulo.

Autoevaluación

¿Qué documento formaliza la petición de un patrocinador para iniciar un ciclo de arquitectura?
- A. Architecture Definition Document
- B. Architecture Contract
- C. Statement of Architecture Work
- D. Request for Architecture Work
¿Cuáles son las cuatro partes del formato de un principio de arquitectura en TOGAF?
- A. Nombre, enunciado, razón e implicaciones
- B. Objetivo, alcance, riesgos y métricas
- C. Problema, actores, roles y medidas de éxito
- D. Driver, objetivo, restricción y supuesto
Según ISO/IEC/IEEE 42010, ¿qué es un viewpoint?
- A. Una representación concreta de la arquitectura
- B. El interés de un stakeholder respecto al sistema
- C. La convención sobre cómo construir y usar una vista para ciertas preocupaciones
- D. El conjunto de stakeholders con alto poder y alto interés
¿Qué evalúa la Business Transformation Readiness Assessment?
- A. La madurez técnica de las aplicaciones de línea base
- B. Factores como visión compartida, patrocinio, financiación y capacidad de absorber el cambio
- C. El cumplimiento de los proyectos con los contratos de arquitectura
- D. La calidad de los datos maestros

Respuestas

D. La Request for Architecture Work la emite el patrocinador; el Statement of Architecture Work es la respuesta del equipo de arquitectura y se firma al cerrar la fase A.
A. Nombre, enunciado (statement), razón (rationale) e implicaciones (implications).
C. El viewpoint es la convención; la vista (view) es la representación concreta; la preocupación (concern) es el interés.
B. Mide la preparación de la organización para transformarse, factor por factor, con madurez actual, objetivo y urgencia.

Checklist

Delimito la organización afectada en núcleo, blandas, extendidas y comunidades.
Redacto principios de arquitectura con sus cuatro partes.
Construyo un mapa de stakeholders con preocupaciones y viewpoints.
Escribo un escenario de negocio con sus siete elementos y lo verifico como SMART.
Produzco una Architecture Vision con propuesta de valor y KPI medibles.
Resumo un Statement of Architecture Work listo para aprobación.