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

Capítulo 17 — Integrar TOGAF, Doble Diamante y Design Thinking

15 de octubre de 2026 Por: Artiko

togafdesign-thinkingdoble-diamanteadmintegraciongobernanza

Integrar TOGAF, Doble Diamante y Design Thinking

Los capítulos anteriores presentaron cada marco por separado. Este capítulo los junta. La tesis es sencilla: los tres marcos responden preguntas distintas, operan en escalas distintas y se pueden encajar sin forzar ninguno.

Marco	Pregunta que responde	Escala	Unidad de trabajo
Design Thinking	¿Qué necesitan las personas y qué solución lo resuelve?	Un problema, un servicio, un producto	Una iteración de empatía a test
Doble Diamante	¿Estamos resolviendo el problema correcto y de la forma correcta?	Un proyecto o iniciativa	Dos diamantes: problema y solución
TOGAF	¿Cómo evoluciona la empresa completa para sostener esas soluciones?	La organización o un segmento	Un ciclo del ADM (Architecture Development Method)

Ninguno sustituye a los otros. Design Thinking sin TOGAF produce prototipos que nadie puede operar a escala. TOGAF sin Design Thinking produce arquitecturas correctas para problemas que nadie tiene. El Doble Diamante aporta la forma que permite ver cuándo se está divergiendo y cuándo convergiendo, en cualquiera de las dos escalas.

flowchart TD
    DT["Design Thinking: método de trabajo con personas"] --> DD["Doble Diamante: forma del proceso de una iniciativa"]
    DD --> TG["TOGAF ADM: ciclo de evolución de la empresa"]
    TG -->|"requisitos y restricciones"| DD
    DD -->|"brief y criterios"| DT
    DT -->|"insights y prototipos validados"| TG

17.1 Design Thinking dentro del ADM

El ADM tiene dos puntos donde la incertidumbre sobre las personas es máxima y, por lo tanto, donde Design Thinking rinde más: el inicio del ciclo (fases Preliminar y A) y el momento de decidir qué soluciones construir (fase E).

Fases Preliminar y A: visión con empatía

La fase A (Architecture Vision) produce un Statement of Architecture Work, los stakeholders con sus concerns, y uno o más Business Scenarios. TOGAF describe el Business Scenario como una técnica para capturar el problema de negocio, el entorno, los actores humanos y de cómputo, y los resultados deseados. Esa descripción es compatible, casi literal, con lo que produce la fase Empatizar y Definir de Design Thinking.

La integración consiste en reemplazar la fuente de información del Business Scenario. En lugar de armarlo solo con entrevistas a ejecutivos y documentos, se arma con:

Mapas de empatía de los actores humanos reales del escenario.
Journey maps del proceso actual con dolores observados, no declarados.
Personas que representan segmentos de usuarios y que luego se convierten en stakeholders del ciclo.
Un Point of View (POV) y preguntas How Might We que acotan el problema antes de dibujar cualquier arquitectura.

flowchart LR
    subgraph Empatizar
        E1["Entrevistas y observación"] --> E2["Mapa de empatía"]
        E1 --> E3["Journey map actual"]
    end
    subgraph Definir
        E2 --> D1["Personas"]
        E3 --> D2["POV y How Might We"]
    end
    subgraph FaseA["Fase A: Architecture Vision"]
        D1 --> A1["Stakeholders y concerns"]
        D2 --> A2["Business Scenario"]
        A1 --> A3["Statement of Architecture Work"]
        A2 --> A3
    end

La fase Preliminar también se beneficia: los principios de arquitectura se escriben mejor cuando el equipo ya observó a usuarios. Un principio como “la información se captura una sola vez” tiene más fuerza si viene de haber visto a un asegurado escribir el mismo dato en tres formularios.

Fase E: idear y prototipar antes de comprometer

La fase E (Opportunities and Solutions) agrupa brechas en work packages y propone arquitecturas de transición. Es el punto donde se decide qué construir. En la práctica, muchas organizaciones llegan a E con una solución ya elegida, a veces por un proveedor. Design Thinking introduce una pausa deliberada:

Idear varias soluciones por brecha prioritaria, no una.
Prototipar las dos o tres más prometedoras en baja fidelidad.
Testear con usuarios reales antes de que la solución entre al roadmap.
Solo entonces convertir el prototipo validado en un Solution Building Block (SBB) candidato.

El beneficio concreto es que los work packages de la fase F (Migration Planning) parten de algo que ya se vio funcionar con personas, no de un supuesto.

17.2 El Doble Diamante como forma del ciclo ADM

El Doble Diamante no agrega fases al ADM. Agrega una lectura: en qué momento el equipo debería estar abriendo opciones y en qué momento cerrándolas. Hay dos formas de aplicarlo.

Lectura macro: un ciclo ADM completo

Diamante	Movimiento	Fases del ADM	Qué se abre o cierra
Primer diamante	Descubrir	Preliminar, A	Se abre la comprensión del problema, los stakeholders, el contexto
Primer diamante	Definir	A, B	Se cierra en una visión, principios y arquitectura de negocio objetivo
Segundo diamante	Desarrollar	C, D, E	Se abren opciones de datos, aplicaciones, tecnología y soluciones
Segundo diamante	Entregar	F, G, H	Se cierra en un roadmap, se implementa y se gobierna el cambio

La frontera entre diamantes queda en la salida de la fase B. Es un punto sensible: si la arquitectura de negocio se cierra sin haber descubierto lo suficiente, el segundo diamante construirá sobre un problema mal definido. El Doble Diamante hace explícito ese riesgo con una pregunta de control al cruzar: ¿estamos resolviendo el problema correcto?

flowchart LR
    P["Preliminar"] --> A["A Visión"]
    A --> B["B Negocio"]
    B --> C["C Sistemas de Información"]
    C --> D["D Tecnología"]
    D --> E["E Oportunidades y Soluciones"]
    E --> F["F Planificación de Migración"]
    F --> G["G Gobernanza de Implementación"]
    G --> H["H Gestión del Cambio"]
    H -.->|"nuevo ciclo"| P
    subgraph Diamante1["Primer diamante: el problema correcto"]
        P
        A
        B
    end
    subgraph Diamante2["Segundo diamante: la solución correcta"]
        C
        D
        E
        F
    end
    subgraph Entregar["Entregar extendido"]
        G
        H
    end

Lectura micro: cada iniciativa del roadmap

Cada work package que sale de la fase F es, a su vez, un proyecto. Ese proyecto puede correr su propio Doble Diamante completo dentro de la fase G, con el Architecture Contract como brief inicial y la revisión de conformidad como punto de cierre. Esta lectura es la que conecta mejor con equipos ágiles: el diamante del problema corresponde al descubrimiento de producto y el diamante de la solución a la entrega iterativa.

17.3 La Gestión de Requisitos como puente

La fase central del ADM, Gestión de Requisitos (Requirements Management), recibe y distribuye requisitos durante todo el ciclo. Es el lugar natural donde los hallazgos de Design Thinking entran a TOGAF.

Salida de Design Thinking	Se convierte en	Dónde vive en TOGAF
Insight de empatía	Concern de un stakeholder	Stakeholder Map, fase A
How Might We	Requisito de arquitectura abierto	Architecture Requirements Specification
Criterio de éxito del POV	Requisito no funcional o métrica	Architecture Requirements Specification
Dolor del journey map	Brecha de capacidad	Gap Analysis, fases B, C, D
Resultado de un test de prototipo	Requisito confirmado, descartado o modificado	Requirements Repository

El flujo tiene dos sentidos. Un requisito descubierto en la fase D (por ejemplo, una restricción de infraestructura) vuelve al equipo de diseño como criterio para el siguiente prototipo. La Gestión de Requisitos registra ese ida y vuelta, lo que evita que el diseño y la arquitectura mantengan listas de requisitos distintas.

sequenceDiagram
    participant DT as Equipo de diseño
    participant RM as Gestión de Requisitos
    participant AR as Arquitectura fases B a D
    DT->>RM: Insights, HMW, criterios del POV
    RM->>AR: Requisitos y concerns
    AR->>RM: Restricciones y brechas detectadas
    RM->>DT: Criterios para el siguiente prototipo
    DT->>RM: Resultado del test, requisito confirmado o descartado
    RM->>AR: Requisitos actualizados

17.4 Mapa de artefactos entre marcos

La tabla siguiente es la más útil para el trabajo diario. Indica qué artefacto de un marco alimenta directamente a cuál del otro, sin traducción intermedia.

Artefacto de origen	Marco	Artefacto de destino	Marco	Transformación necesaria
Mapa de empatía	Design Thinking	Stakeholder concerns	TOGAF fase A	Agrupar lo que piensa, siente y necesita en concerns verificables
Journey map	Design Thinking	Value stream	TOGAF fase B	Abstraer etapas del journey en stages de valor con stakeholders y valor entregado
Personas	Design Thinking	Actores del Business Scenario	TOGAF fase A	Nombrar rol, objetivo y medida de éxito
Design brief	Doble Diamante	Statement of Architecture Work	TOGAF fase A	Agregar alcance, entregables, roles y aprobación
Principios de diseño	Doble Diamante	Principios de arquitectura	TOGAF Preliminar	Escribir con nombre, enunciado, justificación e implicaciones
Prototipo validado	Design Thinking	Solution Building Block candidato	TOGAF fase E	Describir interfaces, dependencias y encaje con ABB existentes
Resultado del test	Design Thinking	Requisito confirmado	TOGAF Gestión de Requisitos	Registrar evidencia y fecha
Architecture Contract	TOGAF fase G	Brief de la iniciativa	Doble Diamante micro	Extraer criterios de diseño y restricciones
Métrica de cambio	TOGAF fase H	Criterio de éxito del siguiente diamante	Doble Diamante	Convertir en pregunta de investigación

17.5 Roles y responsabilidades

La integración falla con más frecuencia por roles que por métodos. Un RACI mínimo evita que el diseñador de servicio y el arquitecto empresarial compitan por el mismo artefacto.

Actividad	Arquitecto empresarial	Diseñador de servicio	Product owner	Architecture Board
Investigación con usuarios	C	R	A	I
Mapa de empatía y journey map	C	R	A	I
Business Scenario	R	C	C	A
Principios de arquitectura	R	C	I	A
Arquitectura de negocio objetivo	R	C	C	A
Ideación y prototipos	C	R	A	I
Test con usuarios	I	R	A	I
Selección de SBB	R	C	C	A
Roadmap y work packages	R	I	C	A
Architecture Contract	R	C	C	A
Revisión de conformidad	R	C	I	A
Medición de impacto	C	C	R	I

R es responsable de hacerlo, A aprueba, C es consultado, I es informado. El patrón que se observa es que la responsabilidad alterna: el diseñador lidera cuando el foco está en personas y el arquitecto cuando el foco está en la empresa, y el product owner aprueba lo que afecta al producto.

17.6 Ritmos y cadencias

Los tres marcos tienen tiempos distintos. Un ciclo ADM puede durar meses; una iteración de Design Thinking, días. Forzarlos a un solo calendario rompe a uno de los dos.

El patrón que funciona es dual-track: un carril de descubrimiento continuo con sprints cortos de Design Thinking y un carril de arquitectura con hitos del ADM. Los puntos de sincronización son las puertas de fase del ADM: al cerrar A, al cerrar B, al cerrar E y al cerrar F.

gantt
    title Dual-track: descubrimiento y arquitectura
    dateFormat YYYY-MM-DD
    axisFormat %b
    section Descubrimiento
    Sprint de empatía 1      :d1, 2026-01-05, 14d
    Sprint de empatía 2      :d2, after d1, 14d
    Sprint de ideación       :d3, after d2, 14d
    Sprint de prototipo 1    :d4, after d3, 14d
    Sprint de prototipo 2    :d5, after d4, 14d
    Test con usuarios        :d6, after d5, 14d
    section Arquitectura
    Preliminar               :a0, 2026-01-05, 21d
    Fase A Visión            :a1, after a0, 21d
    Fase B Negocio           :a2, after a1, 28d
    Fases C y D              :a3, after a2, 35d
    Fase E Soluciones        :a4, after a3, 21d
    Fase F Roadmap           :a5, after a4, 14d
    section Puertas
    Cierre de A              :milestone, m1, 2026-02-16, 0d
    Cierre de B              :milestone, m2, 2026-03-16, 0d
    Cierre de E              :milestone, m3, 2026-05-11, 0d

Reglas de cadencia:

Ninguna puerta del ADM se cruza sin al menos un sprint de descubrimiento cerrado que la alimente.
Ningún prototipo pasa a SBB candidato sin un test con usuarios documentado.
Los sprints de descubrimiento no esperan al ADM; si se adelantan, sus hallazgos entran al Requirements Repository y esperan allí.

17.7 Gobernanza ligera

TOGAF propone un Architecture Contract entre la función de arquitectura y los equipos que implementan. Para que la integración no se quede en el papel, el contrato incluye criterios de diseño verificables junto a los criterios técnicos.

Tipo de criterio	Ejemplo	Cómo se verifica en la revisión de conformidad
Técnico	Usa el servicio de identidad corporativo	Revisión de arquitectura de la solución
De datos	No duplica el maestro de clientes	Inspección del modelo de datos
De experiencia	El usuario completa la tarea principal en menos de 3 pasos	Test de usabilidad con 5 usuarios antes de la salida a producción
De experiencia	Mantiene los principios de diseño del brief	Checklist de principios revisada por diseño
De cambio	Existe plan de adopción para los usuarios internos	Entregable de la fase H revisado

La revisión de conformidad de la fase G se convierte así en un punto donde el Architecture Board escucha a diseño, no solo a tecnología. Esto no requiere más reuniones: requiere que la agenda de la reunión existente tenga un bloque para experiencia.

17.8 Relación con las guías de la serie TOGAF

El TOGAF Standard, 10th Edition se compone de contenido fundamental y guías de la serie (TOGAF Series Guides). Dos de ellas son relevantes para esta integración:

La guía sobre arquitectura ágil (Enabling Enterprise Agility y los documentos sobre Agile Architecture) describe cómo correr el ADM en iteraciones cortas y con múltiples ciclos concurrentes en distintos niveles de la empresa. El dual-track del apartado 17.6 es una aplicación directa de esa idea.
La guía de Business Architecture incluye conceptos de value streams, capability maps, information maps y organization maps. El journey map de Design Thinking es el insumo natural de un value stream, y la guía reconoce explícitamente el customer journey como una vista complementaria del value stream centrada en la experiencia de un actor externo.

mindmap
  root((Integración))
    Design Thinking
      Empatizar y Definir alimentan la fase A
      Idear y Prototipar alimentan la fase E
      Test alimenta Gestión de Requisitos
    Doble Diamante
      Lectura macro del ciclo ADM
      Lectura micro por work package
      Principios del Framework for Innovation
    TOGAF
      ADM como columna vertebral
      Business Architecture y value streams
      Guías ágiles y multinivel
      Architecture Contract con criterios de diseño

17.9 Antipatrones

Los siguientes patrones aparecen cuando la integración se hace de forma parcial.

Antipatrón	Síntoma	Causa habitual	Corrección
Arquitectura sin usuarios	Arquitectura objetivo aprobada sin que nadie haya hablado con un usuario final	Business Scenario armado solo con ejecutivos	Exigir mapas de empatía como entrada de la fase A
Diseño sin restricciones de empresa	Prototipos que ganan el test pero no se pueden construir con la plataforma existente	El equipo de diseño no conoce la Architecture Landscape	Incluir al arquitecto como consultado en ideación y compartir el repositorio
Design theater	Talleres con post-its que no cambian ninguna decisión	Design Thinking usado como actividad de comunicación, no de decisión	Ligar cada taller a un requisito o brecha del repositorio
Architecture astronauts	Modelos exhaustivos de la empresa sin ningún work package en ejecución	Fases B a D sin presión de un diamante de solución	Fijar la salida de E como fecha límite y limitar la profundidad de B a D a lo necesario para esa salida
Diamante único	Se salta del brief a la solución sin diverger en el problema	Presión de un proveedor o una fecha	Hacer explícita la puerta entre diamantes con la pregunta de problema correcto
Requisitos duplicados	Diseño y arquitectura mantienen listas separadas que se contradicen	No se usa la Gestión de Requisitos como único punto de entrada	Un solo Requirements Repository con origen etiquetado

Ejercicio práctico

Toma el caso de tu organización o uno de los casos del curso (clínica dental, municipalidad, retail) y dibuja su ciclo ADM con los dos diamantes superpuestos, marcando dónde queda la frontera entre el problema y la solución.
Lista los artefactos que ya existen en tu organización y clasifícalos con la tabla del apartado 17.4: cuáles son de origen, cuáles de destino y cuáles faltan.
Completa el RACI del apartado 17.5 con los nombres reales de los roles de tu organización. Identifica al menos una actividad donde hoy hay dos responsables o ninguno.
Escribe tres criterios de experiencia verificables para un Architecture Contract de una iniciativa concreta, siguiendo la tabla del apartado 17.7.
Revisa los seis antipatrones y marca cuáles reconoces en un proyecto pasado. Para cada uno, anota qué puerta o artefacto habría permitido detectarlo antes.

Autoevaluación

¿En qué fase del ADM encaja de forma más directa la ideación y el prototipado de soluciones antes de comprometer work packages?
- A. Fase B, Business Architecture
- B. Fase H, Architecture Change Management
- C. Fase E, Opportunities and Solutions
- D. Fase Preliminar
En la lectura macro del Doble Diamante sobre el ciclo ADM propuesta en este capítulo, ¿dónde queda la frontera entre el diamante del problema y el diamante de la solución?
- A. A la salida de la fase B
- B. A la salida de la fase D
- C. A la salida de la fase E
- D. A la salida de la fase Preliminar
¿Qué artefacto de TOGAF es el destino natural de un journey map de Design Thinking?
- A. Architecture Contract
- B. Solution Building Block
- C. Principio de arquitectura
- D. Value stream de la arquitectura de negocio
¿Cuál es la función de la Gestión de Requisitos en la integración descrita?
- A. Aprobar los prototipos antes del test con usuarios
- B. Registrar el ida y vuelta entre hallazgos de diseño y restricciones de arquitectura en un único repositorio
- C. Reemplazar al Architecture Board en las revisiones de conformidad
- D. Definir la cadencia de los sprints de descubrimiento

Respuestas

C. La fase E es donde se deciden soluciones y arquitecturas de transición; idear y prototipar antes de ese compromiso evita entrar al roadmap con supuestos no validados.
A. El primer diamante cubre Preliminar, A y B; la salida de B cierra la definición del problema en una arquitectura de negocio objetivo.
D. El journey map describe etapas y dolores de un actor; abstraído en stages de valor con stakeholders y valor entregado se convierte en un value stream.
B. La Gestión de Requisitos es el punto único de entrada y salida de requisitos durante todo el ciclo, lo que evita listas duplicadas entre diseño y arquitectura.

Checklist

Puedo explicar qué pregunta responde cada marco y en qué escala opera.
Sé en qué fases del ADM entra Design Thinking y con qué artefactos.
Puedo superponer el Doble Diamante a un ciclo ADM y señalar la puerta entre diamantes.
Tengo un RACI que evita responsables duplicados entre diseño y arquitectura.
Mi Architecture Contract incluye al menos un criterio de experiencia verificable.
Reconozco los seis antipatrones y sé qué artefacto los detecta.