C220 Part4e

Machine Translated by Google
Copia de evaluación
El estándar de grupo abierto
Estándar TOGAF® —Arquitectura Contenido
El grupo abierto
© 2005-2022 The Open Group, todos los derechos reservados

Copia de evaluación. No para redistribución
Copyright © 2005-2022, The Open Group
Reservados todos los derechos.
Ninguna parte de esta publicación puede ser reproducida, almacenada en un sistema de recuperación o transmitida, de ninguna
forma o por ningún medio, electrónico, mecánico, fotocopiado, grabación o de otro modo, sin el permiso previo de los propietarios
de los derechos de autor.
Cualquier uso de esta publicación con fines comerciales está sujeto a los términos de la Licencia comercial anual
correspondiente. Para obtener más información, consulte www.opengroup.org/legal/licensing.
El estándar de grupo abierto
Estándar TOGAF® — Contenido de la arquitectura
ISBN: 1-947754-90-4
Número de documento: C220
Publicado por The Open Group, 2005-2022.
Cualquier comentario relacionado con el material contenido en este documento puede enviarse por correo electrónico a:
ogspecs@opengroup.org
yo The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Contenido
Capítulo 1 Introducción................................................. .......................................... 1

1.1 Visión general ................................................ .................................................... 1
1.2 Marco de contenido TOGAF y metamodelo empresarial .......................... 3
1.2.1 Visión general ................................................ ............................................... 3
1.2.2 Marco de contenido ............................................... ............................. 4
1.2.3 Metamodelo empresarial .................................................. ............................. 4
1.2.4 El marco de contenido TOGAF ............................................... ............ 5
1.3 Marco de contenido y TOGAF ADM ........................................... ... 7
1.4 1.5 El continuo del premio empresarial ............................................... ......................... 8
El repositorio de arquitectura ............................................... ..................... 8
Capitulo 2 Marco de contenido TOGAF y metamodelo empresarial .... 9

2.1 Visión general ................................................ .................................................... 9
2.2 TOGAF Enterprise Metamodel Vision.................................................. ......... 9
2.2.1 Visión general del Metamodelo TOGAF Enterprise ........................................... 10
2.3 TOGAF Enterprise Metamodelo en detalle ........................................... ...... 11
2.4 Entidades del metamodelo empresarial TOGAF ........................................... ....... 12
2.5 Atributos del metamodelo TOGAF Enterprise ........................................... ... 15
2.6 Relaciones del metamodelo TOGAF Enterprise ........................................... 25
Capítulo 3 Artefactos Arquitectónicos .................................................. ....................... 31

3.1 Conceptos básicos ................................................ .......................................... 31
3.1.1 Ejemplo simple de un punto de vista de arquitectura y
Vista de la arquitectura .................................................. .................................... 33
3.2 Desarrollo de vistas de arquitectura en el ADM........................................... .. 34
3.2.1 Reglas generales ................................................ ............................... 34
3.2.2 Proceso de creación de la vista de arquitectura.................................... ........ 35
3.3 Vistas, herramientas e idiomas ............................................... ...................... 36
3.3.1 Visión general ................................................ ............................................... 36
3.4 Vistas de Arquitectura y Puntos de Vista de Arquitectura ................................ 36
3.4.1 Ejemplo de Arquitectura Vistas y Arquitectura
Puntos de vista .................................................. ............................................. 36
3.4.2 Arquitectura Vistas y Arquitectura Miradores en
Arquitectura empresarial ............................................... .......................... 37
3.4.3 Necesidad de un lenguaje común e interoperable
Herramientas para la descripción de la arquitectura .............................................. .......... 38
3.5 Conclusiones .................................................. ............................................. 38
3.6 Artefactos Arquitectónicos por Fase ADM.................................................. ........ 39
3.6.1 Fase Preliminar .................................................... ............................. 41
3.6.2 Fase A: Visión de la Arquitectura .............................................. ................... 42
3.6.3 Fase B: Arquitectura empresarial.................................................... ............... 43
3.6.4 Fase C: Arquitectura de datos .............................................. ..................... 49
Estándar TOGAF® — Arquitectura Contenido iii

© 2005-2022 The Open Group, Todos los derechos reservados
Contenido
3.6.5 Fase C: Arquitectura de la aplicación ............................................. .......... 52

3.6.6 Fase D: Arquitectura Tecnológica.................................................... .......... 57
3.6.7 Fase E: Oportunidades y Soluciones ............................................... ...... 61
3.6.8 Gestión de requerimientos ................................................ .................... 61
Capítulo 4 4.1 4.2 Entregables de la arquitectura .................................................. .......... 63

Introducción ................................................. ............................................. 63
Descripciones de entregables .................................................. .......................... 64
4.2.1 Bloques de construcción de la arquitectura ............................................... ................... sesenta y cinco
4.2.2 Contrato de arquitectura ................................................ ............................ sesenta y cinco
4.2.3 Documento de definición de arquitectura ............................................... .......... 66
4.2.4 Pr incipios de arquitectura ............................................... .......................... 67
4.2.5 Repositorio de Arquitectura y.................................................... .......................... 68
4.2.6 Especificación de los requisitos de la arquitectura ................................ 68
4.2.7 Hoja de ruta de la arquitectura .............................................. .......................... 69
4.2.8 Visión de la arquitectura .................................................. .......................... 70
4.2.9 Pr incipios comerciales, objetivos comerciales y
Conductores ........................................... .................................................... .70
4.2.10 Evaluación de la capacidad .................................................. .......................... 71
4.2.11 Solicitud de cambio .................................................. .................................... 72
4.2.12 Plan de comunicaciones................................................... .......................... 73
4.2.13 Evaluación del cumplimiento ................................................ ...................... 73
4.2.14 Plan de Implantación y Migración .................................................. ......... 74
4.2.15 Modelo de Gobernanza de Implementación.................................................. ....... 75
4.2.16 Modelo Organizativo para la Arquitectura Empresarial ................................ 75
4.2.17 Solicitud de Obra de Arquitectura ............................................... .......... 76
4.2.18 Evaluación del impacto de los requisitos ............................................... ........ 76
4.2.19 Bloques de construcción de la solución ............................................. ......................... 77
4.2.20 Declaración de Trabajo Arquitectónico ............................................... ............... 77
4.2.21 Marco de arquitectura a la medida ............................................... ............ 78
Capítulo 5 5.1 5.2 Bloques de construcción .................................................. .................................... 79

Visión general ................................................ .................................................... 79
Introducción a los bloques de construcción .............................................. ................... 79
5.2.1 Visión general ................................................ ............................................... 79
5.2.2 Características genéricas .................................................. .......................... 79
5.2.3 Bloques de construcción de la arquitectura ............................................... ................... 80
5.2.4 Bloques de construcción de la solución ............................................. ......................... 81
5.3 Los bloques de construcción y el ADM ............................................... ...................... 82
5.3.1 Principios básicos............................................... ...................................... 82
5.3.2 Proceso de especificación de bloques de construcción en el ADM ........................... 83
Capítulo 6 6.1 6.2 Continuidad empresarial ................................................ ....................... 85

6.3 Visión general ................................................ .................................................... 85
6.4 Enterprise Continuum y Reutilización de la Arquitectura.................................... 85
Componentes del Continuo Empresarial .................................................. ... 86
Continuidad empresarial en detalle.................................................. ................... 87
6.4.1 Continuidad de la arquitectura .................................................. ......................... 88
6.4.2 Soluciones continuas .............................................. ............................. 91
6.5 El Enterprise Continuum y el ADM .................................................. ...... 93
IV El estándar de grupo abierto (2022)

© 2005-2022 El Grupo Abierto, Todos los derechos reservados
Contenido
6.6 The Enterprise Continuum y su organización ........................................... 93

6.6.1 Relaciones .................................................. .......................................... 93
6.6.2 Su empresa ............................................................. .......................................... 95
Capítulo 7 7.1 7.2 Repositorio de arquitectura ................................................. ................... 97

7.3 Visión general ................................................ .................................................... 97
Arquitectura Paisaje .................................................. .......................... 98
Biblioteca de referencia ............................................... ..................................... 99
7.3.1 Visión general ................................................ ............................................... 99
7.4 Biblioteca de normas.................................................... ...................................... 100
7.4.1 Visión general ................................................ ............................................... 100
7.4.2 Tipos de Norma .......................................................... .................................... 101
7.4.3 Ciclo de vida de las normas .............................................. ............................... 101
7.4.4 Normas Clasificación dentro de las Normas
Biblioteca ................................................ .................................................... .102
7.5 Repositorio de Gobernanza .............................................. .......................... 103
7.5.1 Visión general ................................................ ............................................... 103
7.5.2 Contenido del Repositorio de Gobernanza ............................................... .. 103
7.6 El Repositorio de Requisitos de la Arquitectura.......................................... 104
7.6.1 Visión general ................................................ ............................................... 104
7.6.2 Contenido de los Requisitos de Arquitectura
Repositor y................................................ ............................................. 104
7.7 Panorama de soluciones ................................................ ............................. 105
7.8 El repositorio de Enterprise ............................................... ......................... 105
7.9 Repositorios Externos ................................................. ............................... 106
7.9.1 Modelos de referencia externa .................................................. ..................... 106
7.9.2 Estándares Externos .................................................. ............................... 106
7.9.3 Aprobaciones de la Junta de Arquitectura ............................................... .......... 106
Índice................................................. .................................................... ...... 107
Lista de Figuras
1-1 Relaciones entre entregables, artefactos y

Bloques de construcción ................................................ .................................... 2
1-2 Ejemplo: documento de definición de arquitectura ........................... 2
1-3 Marco de contenido por fase de ADM ........................................... ...... 5
1-4 Descripción general del marco de contenido ............................................... ............. 6
2-1 Uso del marco de contenido para estructurar el TOGAF
Participar premio Metamodelo.................................................... .......................... 10
2-2 Relaciones entre Entidades en la Empresa TOGAF
Metamodelo .................................................. .......................................... 11
3-1 Conceptos básicos de arquitectura .................................................. ............. 31
3-2 Ejemplo de vista de arquitectura: The Open Group Business
Dominios .................................................. .......................................... 33
3-3 Interacciones entre Metamodelo, Building Blocks,
Diagramas y partes interesadas ............................................... ............... 39
3-4 Artefactos asociados con el metamodelo Enterprise .......................... 40
5-1 Fases/Pasos clave de ADM en los que se encuentran los Building Blocks
Evolucionado/Especificado ............................................... ............................... 83
Estándar TOGAF® — Arquitectura Contenido v

Contenido
6-1 Continuum empresarial ............................................... ......................... 86

6-2 Continuidad de la arquitectura .............................................. ..................... 88
6-3 Soluciones continuas .............................................. ......................... 91
6-4 Relaciones entre Arquitectura y Soluciones
continuo .................................................. .......................................... 93
7-1 Vista general del Repositorio de Arquitectura ............................................... .... 97
7-2 Continuidad de la arquitectura .............................................. ..................... 99
vi El estándar de grupo abierto (2022)

Prefacio
El grupo abierto
The Open Group es un consorcio global que permite el logro de objetivos comerciales a través de estándares tecnológicos. Con más
de 870 organizaciones miembros, tenemos una membresía diversa que abarca todos los sectores de la comunidad tecnológica:
clientes, proveedores de sistemas y soluciones, proveedores de herramientas, integradores y consultores, así como académicos e
investigadores.
La misión de The Open Group es impulsar la creación de Boundaryless Information Flow™ logrado mediante:
ÿ Trabajar con los clientes para capturar, comprender y abordar los requisitos actuales y emergentes,
establecer políticas y compartir las mejores prácticas
ÿ Trabajar con proveedores, consorcios y organismos de estándares para desarrollar consenso y facilitar
interoperabilidad, para evolucionar e integrar especificaciones y tecnologías de código abierto
ÿ Ofrecer un conjunto integral de servicios para mejorar la eficiencia operativa de los consorcios
ÿ Desarrollar y operar el principal servicio de certificación de la industria y alentar las adquisiciones

de productos certificados
Más información sobre The Open Group está disponible en www.opengroup.org.
The Open Group publica una amplia gama de documentación técnica, la mayoría de la cual se centra en el desarrollo de estándares
y guías, pero que también incluye libros blancos, estudios técnicos, documentación de certificación y prueba, y títulos comerciales.
Los detalles completos y un catálogo están disponibles en www.opengroup.org/librar y.
El estándar TOGAF®
El estándar TOGAF es un marco abierto de consenso de la industria para Enterprise Architecture.
Es un marco fundacional, lo que significa que es aplicable al desarrollo de cualquier tipo de arquitectura en cualquier contexto. Este
marco fundamental se complementa con The Open Group TOGAF Librar y, una amplia y creciente cartera de material de orientación
1
que brinda orientación práctica en la aplicación del marco TOGAF en contextos específicos.
La Documentación TOGAF
La documentación TOGAF consta de un conjunto de documentos:
ÿ El estándar TOGAF, que describe el enfoque generalmente aplicable a empresas y TI.

Arquitectura
ÿ La Biblioteca TOGAF, una cartera de material de orientación adicional, que apoya la práctica
aplicación del enfoque TOGAF
1. La Biblioteca TOGAF (ver www.opengroup.org/togaf-library) es una biblioteca estructurada de recursos que respaldan el estándar TOGAF.
TOGAF® Standard — Arquitectura viii

Contenido © 2005-2022 The Open Group, Todos los derechos
reservados Copia de evaluación. No para redistribución
Prefacio
Este documento
Este es el estándar TOGAF: contenido de arquitectura.
Público objetivo
El estándar TOGAF está destinado a arquitectos empresariales, arquitectos comerciales, arquitectos de TI, arquitectos de datos,
arquitectos de sistemas, arquitectos de soluciones y cualquier persona responsable de la función de arquitectura dentro de una
organización.
Agradecimientos
The Open Group agradece la contribución de muchas personas y organizaciones en el desarrollo del estándar TOGAF. Consulte el
Estándar TOGAF: Introducción y conceptos básicos para obtener más detalles.
La figura 3-1 se reimprime y adapta de la figura 2 de ISO/IEC/IEEE 42010: 2011, Ingeniería de sistemas y software: descripción de la
arquitectura, con permiso de IEEE®. Copyright © 2011, por IEEE. El IEEE se exime de cualquier responsabilidad u obligación que
resulte de la colocación y el uso en el descrito
manera.
viii The Open Group Standard (2022)

redistribución
Marcas registradas
ArchiMate, DirecNet, Making Standards Work, el logotipo de Open O, Open O y el logotipo de Check Cer tification, The Open
Group, TOGAF, UNIX, UNIXWARE y el logotipo de Open Brand X son marcas comerciales registradas y flujo de información sin
límites, compilado con Integridad Compre con confianza, Arquitectura de referencia de aviación comercial, Fiabilidad a través de la
garantía, Cuerpo de conocimiento del profesional digital, DPBoK, EMMM, FACE, el logotipo de FACE, FHIM Profile Builder, el
logotipo de FHIM, FPB, Future Airborne Capability Environment, IT4IT, el logotipo de IT4IT , O-AA, O-DEF, O-HERA, O-PAS, Open
Agile Architecture, Open FAIR, Open Footprint, Open Process Automation, Open Subsurface Data Universe, Open Trusted
Technology Provider, OSDU, Sensor Integration Simplified, SOSA, y el logotipo de SOSA son marcas registradas de The Open
Group.
CMMI es una marca registrada de CMMI Institute.
Energistics es una marca registrada de Energistics en los Estados Unidos.
IEEE es una marca registrada del Instituto de Ingenieros Eléctricos y Electrónicos, Inc.
ITIL, MSP y PRINCE2 son marcas registradas de AXELOS Limited.
Object Management Group, OMG y UML son marcas comerciales registradas y BPMN, Business Process Modeling Notation y
Unified Modeling Language son marcas comerciales de Object Management Group.
PMBOK es una marca comercial registrada de Project Management Institute, Inc., que está registrada en los Estados Unidos y
otras naciones.
Zachman es una marca registrada de Zachman International, Inc.
The Open Group reconoce que puede haber otros nombres de empresas y productos que podrían estar cubiertos por la protección
de marcas registradas y aconseja al lector que los verifique de forma independiente.
TOGAF® Standard — Arquitectura ix

documentos de referencia
Consulte el Estándar TOGAF: Introducción y conceptos básicos: Apéndice A para ver los documentos a los que se hace referencia
en el Estándar TOGAF.
X The Open Group Standard (2022)

redistribución
Capítulo 1 Introducción
Este capítulo proporciona una introducción a la guía proporcionada en el estándar TOGAF: contenido de la arquitectura (este
documento).
1.1 Resumen
Los arquitectos que ejecutan el Método de desarrollo de arquitectura (ADM) producirán una serie de resultados como
resultado de sus esfuerzos, como flujos de procesos, requisitos arquitectónicos, planes de proyectos o evaluaciones de
cumplimiento de proyectos. El marco de contenido proporciona un modelo estructural para el contenido arquitectónico
que permite que los principales productos de trabajo que crea un arquitecto se definan, estructuren y presenten de
manera coherente.
El marco de contenido proporcionado aquí tiene como objetivo permitir que el marco TOGAF se use como un marco
independiente para la arquitectura dentro de una empresa. Sin embargo, existen otros marcos de contenido (como el
marco Zachman® ) y se anticipa que algunas empresas pueden optar por utilizar un marco externo junto con el marco
TOGAF. En estos casos, el marco de contenido TOGAF proporciona una referencia útil y un punto de partida para que
el contenido TOGAF se asigne a otros marcos de contenido.
El Marco de contenido de arquitectura utiliza las siguientes tres categorías para describir el tipo de producto de trabajo
arquitectónico dentro del contexto de uso:
ÿ Un entregable es un producto de trabajo que se especifica contractualmente y, a su vez, formalmente

revisado, aprobado y firmado por las partes interesadas
Los entregables representan el resultado de los proyectos y los entregables que se encuentran en la
documentación para m generalmente se archivarán al finalizar un proyecto o se trasladarán a un Repositorio de
arquitectura como modelo de referencia, estándar o instantánea del Paisaje arquitectónico en un momento dado.
ÿ Un artefacto es un producto de trabajo arquitectónico que describe un aspecto de la arquitectura .
Los artefactos generalmente se clasifican como catálogos (listas de cosas), matrices (que muestran las relaciones
entre las cosas) y diagramas (imágenes de las cosas). Los ejemplos incluyen un catálogo de requisitos, una
matriz de interacción de aplicaciones y un diagrama de cadena de valor. Un entregable arquitectónico puede
contener muchos artefactos y los artefactos formarán el contenido del Repositorio de Arquitectura.
ÿ Un componente básico representa un componente potencialmente reutilizable de la capacidad empresarial que

se puede combinar con otros componentes básicos para ofrecer arquitecturas y soluciones.
Los bloques de construcción se pueden definir en varios niveles de detalle, según la etapa de desarrollo de la
arquitectura que se haya alcanzado. Por ejemplo, en una etapa inicial, un bloque de construcción puede consistir
simplemente en un nombre o una descripción general. Posteriormente, un bloque de construcción se puede
descomponer en varios bloques de construcción de apoyo y puede ir acompañado de una especificación
completa. Los bloques de construcción pueden relacionarse con "arquitecturas" o "soluciones".
TOGAF® Standard — Arquitectura 1

Visión general Introducción
— Los bloques de construcción de arquitectura (ABB) suelen describir lo que se requiere de los SBB en
un nivel más lógico o independiente del proveedor; esos requisitos pueden incluir servicios a realizar,
recursos de datos y capacidades necesarias. Los ABB incluyen componentes lógicos de negocio,
aplicaciones y tecnología.
— Solution Building Blocks (SBB) representan componentes físicos o específicos del proveedor que tienen
la capacidad de realizar una parte o la totalidad de un ABB más lógico.
Hay SBB de negocios, aplicaciones y tecnología.
Las relaciones entre entregables, artefactos y bloques de construcción se muestran en la Figura 1-1.
© El Grupo Abierto
Entregables de arquitectura Repositorio de Arquitectura
Artefactos y bloques de construcción Edificio reutilizable

bloques
Catálogos Catálogos
Artefactos Matrices Matrices
diagramas diagramas
cuales son
describiendo describiendo
Bloques de construcción Bloques de construcción
Arquitectura
Otros entregables
Entregables
Figura 1-1 Relaciones entre entregables, artefactos y bloques de construcción
Por ejemplo, un documento de definición de arquitectura es un entregable que documenta una descripción de
arquitectura. Este documento contendrá una serie de artefactos complementarios que son vistas de arquitectura de los
bloques de construcción relevantes para la arquitectura. Por ejemplo, se puede crear un diagrama de flujo de proceso
(un artefacto) para describir el proceso de manejo de llamadas de destino (un bloque de construcción). Este artefacto
también puede describir otros componentes básicos, como los actores involucrados en el proceso (por ejemplo, un
representante de servicios al cliente). En la Figura 1-2 se ilustra un ejemplo de las relaciones entre entregables,
artefactos y bloques de construcción .
2 The Open Group Standard (2022)

redistribución
Introducción Visión general
Entregable: Arquitectura
Documento de definición
Artefacto: Los artefactos describen bloques de construcción

Describe
Diagrama de flujo del proceso
Describe
Bloque de construcción:
Proceso de gestión de llamadas de referencia
Los artefactos describen bloques de construcción Artefacto:
Describe Describe
Use el diagrama del caso
Representante de servicios al cliente
Artefacto: Describe
Describe Use el diagrama del caso
Proceso de manejo de llamadas objetivo
Describe Artefacto:
Describe
Los entregables contienen artefactos

© El Grupo Abierto
Figura 1-2 Ejemplo: documento de definición de arquitectura
1.2 Marco de contenido TOGAF y metamodelo empresarial

1.2.1 Resumen
TOGAF ADM proporciona gestión del ciclo de vida para crear y gestionar arquitecturas dentro de una empresa. En cada
fase dentro del ADM, una discusión de entradas, salidas y pasos describe una serie de productos de trabajo de
arquitectura.
Una tarea esencial al establecer la Capacidad de Arquitectura Empresarial específica de la empresa en la Fase Preliminar
del ADM es definir:
ÿ Un marco de categorización que se utilizará para estructurar las Descripciones de arquitectura, los productos de
trabajo utilizados para expresar una arquitectura y la colección de modelos que describen la arquitectura; esto se
conoce como el marco de contenido
ÿ Una comprensión de los tipos de entidades dentro de la empresa y las relaciones entre ellas que necesitan ser
capturadas, almacenadas y analizadas para crear la
Descripción de la Arquitectura; este metamodelo empresarial representa esta información en la forma de un
modelo formal
ÿ Los artefactos específicos a desarrollar (ver Capítulo 4)
Es probable que el marco de contenido elegido se vea influenciado por:
ÿ El Marco de Arquitectura seleccionado como base para la Arquitectura Empresarial

Capacidad
ÿ La herramienta de software elegida utilizada para respaldar la capacidad de arquitectura empresarial

Marco de contenido TOGAF y metamodelo empresarial Introducción
1.2.2 Marco de contenido
El marco de contenido define un marco de categorización que se utilizará para estructurar la descripción de la
arquitectura, el producto de trabajo utilizado para expresar una arquitectura y la colección de modelos que describen la
arquitectura.
El Repositorio de Arquitectura, que se explica en la Sección 4.2.5, está estructurado para almacenar los artefactos y
productos de trabajo identificados en el Marco de Contenido. El marco de contenido es un elemento del marco de
arquitectura específico de la empresa.
1.2.3 Metamodelo empresarial

El estándar TOGAF fomenta el desarrollo de un metamodelo empresarial, que define los tipos de entidad que aparecerán
en los modelos que describen la empresa, junto con las relaciones entre estas entidades.
Un metamodelo de empresa proporciona valor de varias maneras:
ÿ Da a los arquitectos un conjunto inicial de los tipos de cosas a investigar y cubrir en su

modelos
ÿ Proporciona un formulario de verificación de integridad para cualquier lenguaje de modelado de arquitectura, o

metamodelo de arquitectura, que se propone para su uso en una empresa Es
decir, ¿qué tan completamente maneja los tipos de entidad en el metamodelo de empresa y administra los
hechos requeridos sobre ellos, como sus atributos y relaciones?
ÿ Puede ayudar a garantizar:
- Consistencia
— Integridad
— Trazabilidad
Tenga en cuenta que el estándar TOGAF no tiene como objetivo restringir la capacidad de una empresa:
ÿ Selección de artefactos
ÿ Notación de modelado
El estándar TOGAF puede utilizar el lenguaje de modelado ArchiMate®, Business Process Modeling Notation™
(BPMN™), Unified Modeling Language™ (UML®), diagramas de entidad-relación, diagramas de flujo o cualquier
otra notación que pueda expresar algunas ideas TOGAF.
Los tipos de entidad dentro de una empresa y las relaciones entre ellos son específicos de la empresa individual.
Desarrollar un metamodelo de alta calidad es un aspecto importante para establecer la capacidad de arquitectura
empresarial.

redistribución
Introducción Marco de contenido TOGAF y metamodelo empresarial
1.2.4 El marco de contenido TOGAF
El marco de contenido TOGAF define un marco de categorización que se utilizará para estructurar la descripción de la
arquitectura, los productos de trabajo utilizados para expresar una arquitectura y la colección de modelos que describen
la arquitectura.
Existen muchos marcos de contenido alternativos (p. ej., el marco de contenido TOGAF, el marco Zachman, DoDAF,
NAF, etc.). La selección de un marco de contenido es esencial, aunque la elección del marco de contenido es menos
importante. El marco de contenido final generalmente se adapta para satisfacer las necesidades específicas de la
organización.
El marco de contenido TOGAF está destinado a:
ÿ Proporcionar un modelo detallado de los productos de trabajo
arquitectónico ÿ Impulsar la consistencia en los resultados creados al seguir el
ADM ÿ Proporcionar una lista de verificación completa de los resultados de la arquitectura que
podrían crearse ÿ Reducir el riesgo de brechas dentro del conjunto final de entrega de la arquitectura
ÿ Ayudar a una empresa a exigir conceptos, términos y entregables de arquitectura estándar
Al más alto nivel, el marco de contenido TOGAF (ver Figura 1-3) está estructurado de acuerdo con las fases del ADM.
Figura 1-3 Marco de contenido por fase de ADM

Marco de contenido TOGAF y metamodelo empresarial Introducción
ÿ Los modelos de Principios de arquitectura, Visión, Motivación y Requisitos están destinados a capturar el
contexto circundante de los modelos de arquitectura formales, incluidos los Principios de arquitectura generales,
el contexto estratégico que forma más información para el modelado de arquitectura y los requisitos generados
a partir de la arquitectura. El contexto comercial que ha dado lugar a la solicitud de trabajo de arquitectura
generalmente se investiga, refina, valida y registra en las fases preliminar y de visión de arquitectura.
ÿ Business Architecture captura los modelos de arquitectura del negocio, buscando específicamente
en los factores que motivan la empresa, su estructura y sus capacidades
ÿ Los modelos de arquitectura de sistemas de información capturan modelos de arquitectura de sistemas de TI,
observando aplicaciones y datos en línea con las fases TOGAF ADM
ÿ Los modelos de arquitectura tecnológica capturan activos tecnológicos que se utilizan para implementar y realizar
soluciones de sistemas de información.
ÿ Los modelos de Realización/Transformación de la arquitectura capturan hojas de ruta de cambios que

muestran la transición entre los estados de la arquitectura y las declaraciones vinculantes que se utilizan para
dirigir y gobernar una implementación de la arquitectura.
ÿ Los modelos de gestión de cambios en la arquitectura capturan eventos de gestión de realización de valor,
internos y externos, que impactan en la arquitectura empresarial y la generación de requisitos para la acción.

redistribución
Introducción Marco de contenido TOGAF y metamodelo empresarial
Figura 1-4 Descripción general del marco de contenido
1.3 Marco de contenido y TOGAF ADM

TOGAF ADM describe el proceso de pasar de un estado de referencia de la empresa a un estado objetivo de la empresa. El
ADM abordará una necesidad comercial a través de un proceso de visión, definición de arquitectura, planificación de la
transformación y Gobernanza de la Arquitectura. En cada etapa de este proceso, el ADM requiere información como entradas
y creará salidas como resultado de la ejecución de una serie de pasos. El marco de contenido proporciona una estructura
subyacente para el ADM que define entradas y salidas con más detalle y pone cada entregable en el contexto de la vista de
arquitectura holística de la empresa.
Por lo tanto, el marco de contenido debe utilizarse como complemento del ADM. El ADM describe lo que se necesita hacer
para crear una arquitectura y el Marco de contenido describe cómo debería verse la arquitectura una vez que esté lista.

El continuo de la empresa Introducción
1.4 El continuo empresarial

Por lo general, es imposible crear una única arquitectura unificada que cumpla con todos los requisitos de todas las
partes interesadas en todo momento. Por lo tanto, el Arquitecto Empresarial tendrá que tratar no solo con una sola
Arquitectura Empresarial, sino con muchas Arquitecturas Empresariales relacionadas.
Cada arquitectura puede tener un propósito diferente y las arquitecturas pueden relacionarse entre sí.
Limitar efectivamente el alcance de una arquitectura es, por lo tanto, un Factor Crítico de Éxito (CSF) que permite a los
arquitectos dividir un espacio de problemas complejos en componentes manejables que pueden abordarse
individualmente.
Enterprise Continuum proporciona una vista del repositorio de arquitectura que muestra la evolución de estas
arquitecturas relacionadas de lo genérico a lo específico, de lo abstracto a lo concreto y de lo lógico a lo físico.
el capítulo 6 trata sobre el continuo empresarial; incluyendo el Continuo de Arquitectura y el Continuo de Soluciones.
1.5 El repositorio de arquitectura

Operar una capacidad de arquitectura madura dentro de una gran empresa crea un gran volumen de producción
arquitectónica. La gestión eficaz y el aprovechamiento de estos productos de trabajo arquitectónico requieren una
taxonomía formal para diferentes tipos de activos arquitectónicos junto con procesos y herramientas dedicados para el
almacenamiento de contenido arquitectónico.
El Capítulo 7 proporciona un marco estructural para un repositorio de arquitectura que permite a una empresa distinguir
entre diferentes tipos de activos arquitectónicos que existen en diferentes niveles de abstracción en la organización.

redistribución
Capítulo 2: Marco de contenido TOGAF y Enterprise

metamodelo
2.1 Resumen
TOGAF ADM proporciona un ciclo de vida del proceso para crear y administrar arquitecturas dentro de una empresa.
En cada fase dentro del ADM, una discusión de entradas, salidas y pasos describe una serie de productos o artefactos
de trabajo arquitectónico, como el proceso y la aplicación.
El marco de contenido y el metamodelo empresarial proporcionados aquí definen una estructura formal para estos
términos para garantizar la coherencia dentro del ADM y también para brindar orientación a las organizaciones que
desean implementar su arquitectura dentro de una herramienta de arquitectura.
El marco de contenido define un marco de categorización que se utilizará para estructurar la descripción de la
arquitectura, el producto de trabajo utilizado para expresar una arquitectura y la colección de modelos que describen la
arquitectura.
El metamodelo empresarial define los tipos de entidades que aparecerán en los modelos que describen la empresa,
junto con las relaciones entre estas entidades.
2.2 Visión del metamodelo empresarial TOGAF

El estándar TOGAF incluye el metamodelo TOGAF Enterprise que captura las entidades y relaciones que probablemente
se encuentren en la mayoría de las empresas. Esto puede usarse como base para desarrollar un metamodelo específico
de la organización al establecer la capacidad de arquitectura empresarial en la fase preliminar y también proporciona el
contexto para los artefactos específicos a los que se hace referencia en las descripciones de las fases de ADM y que
se describen en detalle en el Capítulo 3.
Al desarrollar un metamodelo específico de la organización, los arquitectos pueden optar por no incluir entidades y
relaciones del metamodelo TOGAF Enterprise que no sean relevantes y/o agregar entidades y relaciones adicionales.
Esta sección proporciona una descripción general del metamodelo TOGAF Enterprise. Las secciones subsiguientes
discuten cada área del metamodelo con más detalle.

Visión y Conceptos Marco de contenido TOGAF y metamodelo empresarial
2.2.1 Descripción general del metamodelo TOGAF Enterprise

El Metamodelo TOGAF Enterprise incluye un conjunto de entidades, definidas en la Sección 2.4, que permiten capturar,
almacenar, filtrar, consultar y representar conceptos arquitectónicos de una manera que respalde la coherencia, la
integridad y la trazabilidad.
El mecanismo de categorización del marco de contenido se puede utilizar para estructurar una representación del
metamodelo TOGAF Enterprise, como se muestra en la figura 2-1.
Figura 2-1 Uso de Content Framework para estructurar el metamodelo TOGAF Enterprise

redistribución
Marco de contenido TOGAF y metamodelo empresarial Detalle del metamodelo
2.3 Metamodelo empresarial TOGAF en detalle

Las relaciones entre entidades en el Metamodelo TOGAF Enterprise se muestran en la Figura 2-2.
Figura 2-2 Relaciones entre entidades en el metamodelo TOGAF Enterprise

Detalle del metamodelo Marco de contenido TOGAF y metamodelo empresarial
2.4 Entidades del metamodelo empresarial TOGAF

La siguiente tabla enumera y describe las entidades dentro del Metamodelo Enterprise.
Entidad metamodelo Descripción

Actor Una persona, organización o sistema que tiene un rol que inicia o
interactúa con actividades; por ejemplo, un representante de ventas que
viajes para visitar a los clientes. Los actores pueden ser internos o externos a un
organización. En la industria automotriz, un equipo original
fabricante sería considerado un actor por una automotriz
concesionario que interactúa con las actividades de su cadena de suministro.
Servicio de aplicación Los elementos automatizados de un servicio empresarial. Una aplicación
el servicio puede entregar o respaldar parte o la totalidad de uno o más negocios
servicios
Suposición Una declaración de hecho probable que no ha sido completamente validada en este
etapa, debido a limitaciones externas. Por ejemplo, se puede suponer
que una aplicación existente soportará cierto conjunto de funciones
requisitos, aunque es posible que esos requisitos aún no se hayan cumplido.
validado individualmente.
Capacidad comercial Una habilidad particular que una empresa puede poseer o intercambiar para
lograr un propósito en particular.
Business Information Representa un concepto y su semántica utilizada dentro del negocio.
Business Service Respalda el negocio al encapsular un elemento único de
comportamiento empresarial; un servicio ofrecido externamente a la empresa puede
contar con el apoyo de los servicios empresariales.
Capacidad Habilidad que posee una organización, persona o sistema.
Nota: Esta es una definición de propósito general. Consulte Capacidad comercial para
cómo se refina este concepto para su uso en Business Architecture.
Restricción Un factor externo que impide que una organización persiga

enfoques particulares para alcanzar sus metas. Por ejemplo, datos de clientes.
no está armonizado dentro de la organización, a nivel regional o nacional,
restringiendo la capacidad de la organización para ofrecer servicios efectivos al cliente
Servicio.
Contrato Un acuerdo entre un consumidor y un proveedor que establece
parámetros funcionales y no funcionales para la interacción. esto se aplica
a todos los tipos de interacciones de servicio dentro del metamodelo.
Control Un paso de toma de decisiones con la lógica de decisión que lo acompaña que se utiliza para
determinar el enfoque de ejecución de la mina para un proceso o para asegurar que un
proceso cumple con los criterios de gobernanza ia. Por ejemplo, asignar
control sobre el proceso de procesamiento de solicitudes de compra que verifica
si el valor total de la solicitud está dentro de los límites de aprobación de
el solicitante, o si necesita escalar a una autoridad superior.
Curso de acción Dirección y enfoque provistos por metas y objetivos estratégicos, a menudo
entregar la propuesta de valor caracterizada en el modelo de negocio.
Entidad de datos Representa datos que son reconocidos por el negocio como un
concepto.
12 El estándar de grupo abierto (2022)

Marco de contenido TOGAF y metamodelo empresarial Entidades de metamodelo

Conductor Una condición externa o interna que motiva a la organización a definir sus metas. Un
ejemplo de un impulsor externo es un cambio en la regulación o las reglas de
cumplimiento que, por ejemplo, requieren cambios en la forma en que opera una
organización; es decir, Sarbanes-Oxley en los EE.UU.
Evento Un cambio de estado organizacional que desencadena eventos de procesamiento; puede
originarse dentro o fuera de la organización y puede resolverse dentro o fuera de la
organización.
Función Un conjunto de comportamientos comerciales basados en un conjunto elegido de criterios.
Las funciones suelen estar estrechamente vinculadas a/con unidades organizativas.

Brecha Una declaración de diferencia entre dos estados. Se utiliza en el contexto del análisis de
brechas, donde se identifica la diferencia entre la arquitectura de referencia y la de destino.
Nota: El análisis de brechas se describe en el Estándar TOGAF -

Técnicas ADM.
Meta Una declaración de alto nivel de intención o dirección para una organización.
Normalmente se utiliza para medir el éxito de una organización.
Ubicación Un lugar donde ocurren las actividades. Las ubicaciones se pueden componer y
descomponer.
Aplicación lógica Una encapsulación de la funcionalidad de la aplicación que es definible por los
Componente servicios ofrecidos y los datos mantenidos, independientemente de la implementación
y la tecnología.
Datos lógicos Una estructura de datos compuesta de entidades de datos relacionados lógicamente.
Componente
Tecnología lógica Una encapsulación de servicios tecnológicos independiente de la implementación.
Componente
Medida Un indicador o factor que se puede rastrear, generalmente de forma continua, para
determinar el éxito o la alineación con los objetivos y metas.
Objetivo Un objetivo organizacional que se declara de manera Simple, Medible, Accionable,
Realista y con Límites de Tiempo (SMART). Por ejemplo, "Aumentar la utilización de la
capacidad en un 30 % para fin de año, para respaldar el aumento planificado de la
participación de mercado".
Unidad organizativa Una unidad autónoma de recursos con metas, objetivos y
medidas. Las unidades organizativas pueden incluir partes externas y organizaciones
de socios comerciales.
Aplicación Física Una realización de la funcionalidad de la aplicación lógica usando componentes de
Componente funcionalidad en aplicaciones que pueden ser contratadas, adquiridas o construidas.
Datos físicos Una estructura de datos que realiza componentes de datos lógicos relacionados
Componente representados en el formato o esquema requerido por una tecnología particular.
Tecnología Física Una realización de la funcionalidad de la tecnología lógica utilizando un producto de

Componente tecnología particular que puede implementarse.

Entidades de metamodelo Marco de contenido TOGAF y metamodelo empresarial

Pr principio Una declaración cualitativa de intenciones que debe cumplir el
arquitectura. Tiene al menos una justificación de apoyo y una medida de
importancia.
Nota: En el TOGAF se define un conjunto de muestra de Principios de Arquitectura .

Estándar — Técnicas ADM.
Proceso Un proceso representa una secuencia de actividades que juntas logran un

resultado especificado, puede descomponerse en subprocesos y puede
mostrar el funcionamiento de una capacidad o servicio comercial (en el siguiente nivel de
detalle).
Los procesos también se pueden utilizar para vincular organizaciones, empresas

capacidades, servicios y procesos. Un proceso puede realizar una
servicio y/u orquestar servicios subordinados.
Producto Un resultado generado por el negocio para ser ofrecido a los clientes.
Los productos incluyen materiales y/o servicios.
Requisito Una declaración cuantitativa de la necesidad comercial que debe ser satisfecha por un
arquitectura particular o paquete de trabajo.
Role El comportamiento habitual o esperado de un actor, o el papel de alguien o
algo juega en un proceso o evento particular. Un actor puede tener
una serie de roles.
Véase también Actor.
Calidad de servicio Una configuración de requisitos o atributos no funcionales que pueden

asignarse a un negocio, aplicación o servicio tecnológico.
Servicio de tecnología Una capacidad técnica requerida para proporcionar infraestructura habilitadora que
apoya la entrega de aplicaciones.
Flujo de valor Una representación de una colección de actividades de extremo a extremo que crean
un resultado general para un cliente, parte interesada o usuario final.
Paquete de trabajo Un conjunto de acciones identificadas para lograr uno o más objetivos para el
business.Un paquete de trabajo puede ser parte de un proyecto, un completo
proyecto, o un programa.

Marco de contenido TOGAF y metamodelo empresarial Atributos del metamodelo
2.5 Atributos del Metamodelo Empresarial TOGAF

La siguiente tabla muestra los atributos típicos para cada una de las entidades del metamodelo descritas
previamente.
metamodelo
Entidad Atributo Descripción
ID de todas las entidades del metamodelo Identificador único para el
entidad de arquitectura.
Nombre Breve nombre de la arquitectura
entidad.
Descripción Descripción textual de la
entidad de arquitectura.
Categoría Categorización definible por el usuario
taxonomía para cada metamodelo
entidad.
Fuente Lugar desde donde se
se recopiló información.
Dueño Titular de la entidad de arquitectura.
Capacidad Valor de negocio Describe cómo esta capacidad
proporciona valor a la empresa.
Incrementos Enumera la posible madurez/calidad
niveles para la capacidad.
Restricción Sin atributos adicionales Esta entidad de metamodelo solo tiene
atributos básicos.
Brecha Sin atributos adicionales Esta entidad de metamodelo solo tiene

atributos básicos.
Ubicación Categoría Las siguientes categorías de
Ubicación aplica: Región (aplica
a una agrupación de países o
territorio; por ejemplo, el Sudeste de Asia,
Reino Unido e Irlanda), País
(se aplica a un solo país;
ej., EE. UU.), edificio (se aplica a un
sitio de operación; donde varios
las oficinas se recogen en un único
ciudad, esta categoría puede representar
una ciudad) y Ubicación específica
(se aplica a cualquier ubicación específica
dentro de un edificio, como un
Cuarto de servicio). la naturaleza de la
el negocio puede introducir otros
Ubicaciones: barco o puerto para un
empresa de ferry, la mía por un oro
empresa, Coche para una fuerza policial,
Hotel para viajes de cualquier empresa
trabajadores, y así sucesivamente.
Estándar TOGAF® — Arquitectura Contenido 15

Atributos del metamodelo Marco de contenido TOGAF y metamodelo empresarial
metamodelo
Pr principio Categoría Las siguientes categorías de
pr incipio aplica: Guía
Principio, Principio de negocio,
Principio de datos, aplicación
Principio, Principio de Integración,
Principio de tecnología.
Prioridad Prioridad de este principio relativo
a otros principios.
Declaración de principios Declaración de lo que es el principio
es.
Razón fundamental Declaración de por qué el principio es
requerido y el deseado
resultado a alcanzar.
Implicación Declaración de lo que es el principio
significa en términos prácticos.
métrico Identifica los mecanismos que
utilizarse para medir si la
pr inciple se ha cumplido o no.
Requisito Declaración de requisitos Declaración de lo que
requisito es, incluyendo un
definición de si el
se cumplirá el requisito,
debe cumplirse o puede cumplirse.
Razón fundamental Declaración de por qué la
existe el requisito.
Criterios de aceptación Los parámetros que serán
cumplido si el requisito es
siendo cumplido, junto con el
pruebas que se realizarán para
evaluar el estado de la
parámetros
Actor # FTE Número estimado de FTE que
operar como este actor.
Meta del actor Objetivos que tiene este actor, en
términos generales.
Tareas de actor Tareas que realiza este actor, en
términos generales.
Servicio empresarial clase de normas No estándar, propuesto
estándar, estándar provisional,
Estándar, Eliminación
Estándar, Estándar Retirado.
Fecha de creación estándar Si el servicio empresarial es un
estándar, cuando el estándar
fue creado.
Última fecha de revisión estándar Última fecha en que el estándar fue
revisados.
dieciséis
El estándar de grupo abierto (2022)
metamodelo
Próxima fecha de revisión estándar Próxima fecha para que la norma sea
revisados.
fecha de retiro Fecha en que el estándar fue/será
ser retirado.
Contrato Características del comportamiento Comportamiento funcional a ser
apoyado en el ámbito de
el contrato.
Nombre del servicio "llamador" Servicio de consumo.
Nombre del servicio "llamado" Brindando servicio.
Características de la calidad del servicio Comportamiento no funcional a ser
apoyado en el ámbito de
el contrato.
Características de disponibilidad Grado en que algo es
disponible para su uso.
tiempos de servicio Horas en las que el servicio
debe estar disponible.
Características de manejabilidad Habilidad para recopilar información
sobre el estado de algo
y controlarlo.
Características de capacidad de servicio Habilidad para identificar problemas y
tomar medidas correctivas, como
para reparar o actualizar un
componente en un sistema en ejecución.
Características de presentación Capacidad de un componente para
realizar sus tareas en un
tiempo apropiado.
Requisitos de respuesta Tiempos de respuesta que el servicio
proveedor debe cumplir para particular
operaciones.
Características de confiabilidad Resistencia al fracaso.
Calidad de la información requerida Requisitos contratados en
exactitud e integridad de
información.
Requisitos de control de contratos Nivel de gobernabilidad y
ejecución aplicada a la
parámetros contractuales para
servicio general.
Requisitos de control de resultados Medidas establecidas para garantizar
que cada solicitud de servicio cumple
criterio contratado ia.
Características de recuperabilidad Habilidad para restaurar un sistema a un
estado de trabajo después de un
interrupción.
Características de localizabilidad Habilidad de un sistema para ser encontrado
cuando sea necesario.

metamodelo
Características de seguridad Capacidad de un sistema para prevenir

acceso no autorizado a
funciones y datos.
Caracter ísticas de la privacidad Protección de datos de
Acceso no autorizado.
Características de integridad Capacidad de un sistema para asegurar
esos datos no han sido
corrompido.
Características de la credibilidad Capacidad de un sistema para asegurar
que la solicitud de servicio
o se origina en un autorizado
fuente.
Características de la localización Capacidad de un servicio para soportar
variantes localizadas para diferentes
grupos de consumidores.
Características de internacionalización Capacidad de un servicio para apoyar
variaciones internacionales en
lógica de negocios y datos
representación (como
conjunto de caracteres).
Características de interoperabilidad Capacidad del servicio para

interoperar con diferentes
entornos técnicos, dentro
y fuera de la organización.
Características de escalabilidad Capacidad del servicio para crecer o
shr tinta su rendimiento o
capacidad adecuada a la
demandas del medio ambiente en
que opera.
Características de portabilidad De datos, personas, aplicaciones,
y componentes
Características de extensibilidad Habilidad para aceptar nuevos
funcionalidad.
Características de capacidad Capacidad contratada del
proveedor de servicios para cumplir
peticiones.
Rendimiento Capacidad de rendimiento requerida.
Período de rendimiento Periodo de tiempo necesario para entregar
capacidad de rendimiento.
Crecimiento Tasa de crecimiento futura esperada de
petición de servicio.
Período de crecimiento Periodo de tiempo necesario para llegar
la tasa de crecimiento esperada.
Perfil pico a corto plazo Perfil a corto plazo del pico
tráfico de servicio.
Perfil pico a largo plazo Perfil de pico a largo plazo

metamodelo
Control Sin atributos adicionales Esta entidad de metamodelo solo tiene
atributos básicos.
Conductor Sin atributos adicionales Esta entidad de metamodelo solo tiene
atributos básicos.
Evento Sin atributos adicionales Esta entidad de metamodelo solo tiene
atributos básicos.
Función clase de normas No estándar, propuesto
Fecha de creación estándar Si el producto es un estándar,
cuando se creó la norma.
revisados.
revisados.
ser retirado.
Meta Sin atributos adicionales Esta entidad de metamodelo solo tiene
atributos básicos.
Medida Sin atributos adicionales Esta entidad de metamodelo solo tiene
atributos básicos.
Objetivo Sin atributos adicionales Esta entidad de metamodelo solo tiene

atributos básicos.
Unidad de organización Número de empleados Número de FTE que trabajan dentro

la organización.
Proceso clase de normas No estándar, propuesto
revisados.
revisados.
ser retirado.
Criticidad del proceso La criticidad de este proceso para
operaciones de negocios.
Manual o automatizado Si este proceso es
respaldado por TI o es un manual
proceso.
Volumetría de proceso Datos sobre la frecuencia del proceso
ejecución.

metamodelo
Producto Sin atributos adicionales Esta entidad de metamodelo solo tiene
atributos básicos.
Role Número estimado de FTE que Esta entidad de metamodelo solo tiene
operar en este Rol atributos básicos.
Calidad de servicio Sin atributos adicionales Esta entidad de metamodelo solo tiene
atributos básicos.
Servicio clase de normas No estándar, propuesto
revisados.
revisados.
ser retirado.
Clase de estándares de componentes de aplicación No estándar, propuesto

revisados.
revisados.
ser retirado.
Servicio de aplicaciones clase de normas No estándar, propuesto

revisados.
revisados.
ser retirado.
Aplicación lógica clase de normas No estándar, propuesto

Componente estándar, estándar provisional,

metamodelo
revisados.
revisados.
ser retirado.
Aplicación Física Estado del ciclo de vida Propuesto, En desarrollo,

Componente En vivo, Eliminación progresiva, Retirado.
clase de normas No estándar, propuesto
revisados.
revisados.
ser retirado.
Fecha de vida inicial Fecha en que se lanzó el primer lanzamiento de
la aplicación fue/será
lanzado a la producción.
Fecha del último lanzamiento Fecha de la última publicación de
la aplicación fue lanzada
en producción.
Fecha del próximo lanzamiento Fecha cuando el próximo lanzamiento de
la aplicación será liberada
en producción.
fecha de jubilación Fecha en que la solicitud
fue/será jubilado.
Características de disponibilidad Grado en que algo es
disponible para su uso.
tiempos de servicio Horas durante las cuales el
la aplicación debe estar disponible.
Características de manejabilidad Habilidad para recopilar información
sobre el estado de algo
y controlarlo.
Características de capacidad de servicio Habilidad para identificar problemas y
tomar medidas correctivas, como
para reparar o actualizar un
componente en un sistema en ejecución.
Características de presentación Capacidad de un componente para
realizar sus tareas en un
tiempo apropiado.

metamodelo
Características de confiabilidad Resistencia al fracaso.
Características de recuperabilidad Habilidad para restaurar un sistema a un

estado de trabajo después de un
interrupción.
Características de localizabilidad Habilidad de un sistema para ser encontrado
cuando sea necesario.
Características de seguridad Capacidad de un sistema para prevenir

acceso no autorizado a
funciones y datos.
Caracter ísticas de la privacidad Protección de datos de
Acceso no autorizado.
Características de integridad Capacidad de un sistema para asegurar

esos datos no han sido
corrompido.
Características de la credibilidad Capacidad de un sistema para asegurar
que la solicitud de servicio
o se origina en un autorizado
fuente.
Características de la localización Capacidad de un servicio para soportar
variantes localizadas para diferentes
grupos de consumidores.
Características de internacionalización Capacidad de un servicio para apoyar
variaciones internacionales en
lógica de negocios y datos

representación (como
conjunto de caracteres).
Características de interoperabilidad Capacidad del servicio para

interoperar con diferentes
entornos técnicos, dentro
y fuera de la organización.
Características de escalabilidad Capacidad del servicio para crecer o
shr tinta su rendimiento o
capacidad adecuada a la
demandas del medio ambiente en
que opera.
Características de portabilidad De datos, personas, aplicaciones,
y componentes
Características de extensibilidad Habilidad para aceptar nuevos
funcionalidad.
Características de capacidad Capacidad contratada del
proveedor de servicios para cumplir
peticiones.
Rendimiento Capacidad de rendimiento requerida.
Período de rendimiento Periodo de tiempo necesario para entregar
capacidad de rendimiento.
Crecimiento Tasa de crecimiento futura esperada de
petición de servicio.

metamodelo
Período de crecimiento Periodo de tiempo necesario para llegar
la tasa de crecimiento esperada.
Perfil pico a corto plazo Perfil a corto plazo del pico
Perfil pico a largo plazo Perfil de pico a largo plazo
Entidad de datos Categoría Las siguientes categorías de datos

entidad aplicar: Mensaje, Internamente
Entidad almacenada.
Clasificación de privacidad Nivel de restricción impuesto a
acceso a los datos.
Clasificación de retención Nivel de retención a colocar
sobre los datos
Datos lógicos clase de normas No estándar, propuesto

revisados.
revisados.
ser retirado.
Datos físicos clase de normas No estándar, propuesto

revisados.
revisados.
ser retirado.
Tecnología lógica clase de estándares No estándar, propuesto

revisados.
revisados.

metamodelo
ser retirado.
Categoría Tecnología lógica
Los componentes se clasifican
de acuerdo con lo definido
taxonomía (como TOGAF
Modelo de referencia técnica
(TRM)), adaptado para cumplir con las
necesidades de un individuo
organización.
Tecnología Física clase de estándares No estándar, propuesto
revisados.
revisados.
ser retirado.
Categoría Tecnología Física
Los componentes se clasifican
de acuerdo con lo definido
taxonomía (como TOGAF
TRM), adaptado para cumplir con las
necesidades de un individuo
organización.
Nombre del producto Nombre del producto que lo compone
el componente tecnológico.
Nombre del módulo Módulo, u otro subproducto,
nombre que compone la tecnología
componente.
Vendedor Proveedor que proporciona la tecnología.
componente.
Versión Versión de la fabricación del producto.
subir el componente de tecnología.
Servicio de Tecnología clase de normas No estándar, propuesto

metamodelo
Categoría Los servicios tecnológicos son
categorizados según el
taxonomía definida (como la
TOGAF TRM), adaptado para cumplir
las necesidades de un individuo
organización.
Capacidad comercial Sin atributos adicionales Esta entidad de metamodelo solo tiene
atributos básicos.
Clase de estándares de componentes tecnológicos No estándar, propuesto

Curso de acción Sin atributos adicionales Esta entidad de metamodelo solo tiene
atributos básicos.
Flujo de valor Sin atributos adicionales Esta entidad de metamodelo solo tiene
atributos básicos.
Paquete de trabajo Categoría Las siguientes categorías de trabajo

aplicación del paquete: Paquete de trabajo,
Flujo de trabajo, Proyecto, Programa,
Portafolio.
Capacidad entregada Describe la contribución de este
paquete de trabajo hace a
entrega de capacidad y.
2.6 Relaciones del metamodelo empresarial TOGAF
Entidad de origen Objetivo y entidad Nombre

Actor Actor Descompone
Actor Servicio empresarial consume
Actor Entidad de datos Suministros o consume
Actor Evento genera
Actor Evento resuelve
Actor Función Interactúa con
Actor Función realizar
Actor Unidad de organización Pertenece a
Actor Proceso participa en
Actor Proceso disparadores
Actor Role Realice la tarea en

Actor Flujo de valor Realizar una tarea en
Servicio de aplicaciones Servicio empresarial Automatiza algunos o todos
Servicio de aplicaciones Entidad de datos Usado por

Servicio de aplicaciones El componente de aplicación lógica se realiza a través de
Estándar TOGAF® — Contenido de la arquitectura 25

Relaciones de metamodelo Marco de contenido TOGAF y metamodelo empresarial
Servicio de aplicaciones Servicio de Tecnología es servida por
Capacidad comercial Información de negocios Usos
Capacidad comercial Curso de acción es influenciado por
Capacidad comercial Función es entregado por
Capacidad comercial Unidad de organización es usado por
Capacidad comercial Proceso es operacionalizado por
Capacidad comercial Flujo de valor Habilita
Información de negocios Capacidad comercial es usado por

Información de negocios Servicio empresarial Se utiliza para derivar
Información de negocios Curso de acción es influenciado por

Información de negocios Entidad de datos es realizado por
Información de negocios Proceso Usos
Servicio empresarial Actor se proporciona a

Servicio empresarial Servicio de aplicaciones Usos
Servicio empresarial Información de negocios Se deriva de
Servicio empresarial Calidad de servicio comercial Satisface
Servicio empresarial Servicio empresarial consume
Servicio empresarial Servicio empresarial Descompone

Servicio empresarial Contrato Se rige y mide por
Servicio empresarial Entidad de datos Se accede y actualiza a través de
Servicio empresarial Evento resuelve
Servicio empresarial Función Proporciona una interfaz gobernada para

acceso
Servicio empresarial El componente de tecnología lógica se implementa en

Servicio empresarial Unidad de organización es propiedad y está regido por
Servicio empresarial Proceso es realizado por
Servicio empresarial Proceso Soportes
Capacidad Paquete de trabajo es entregado por

Contrato Servicio empresarial Gobierna, mide
Contrato Calidad de servicio Satisface
Control Proceso Garantiza el correcto funcionamiento de

Curso de acción Capacidad comercial Influencias
Curso de acción Información de negocios Influencias
Curso de acción Función Influencias
Curso de acción Meta se da cuenta
Curso de acción Unidad de organización Influencias
Curso de acción Producto Influencias
Curso de acción Flujo de valor Influencias
Entidad de datos Actor Es suministrado o consumido por
Entidad de datos Servicio de aplicaciones Usado por
Entidad de datos Información de negocios se da cuenta
Entidad de datos Servicio empresarial Se accede y actualiza a través de
Entidad de datos Entidad de datos Descompone
Entidad de datos Entidad de datos Se relaciona con
Entidad de datos Componente de datos lógicos reside dentro

Marco de contenido TOGAF y metamodelo empresarial Relaciones de metamodelo

Conductor Conductor Descompone
Conductor Meta crea
Conductor Unidad de organización motiva
Evento Actor es generado por
Evento Actor se resuelve por
Evento Servicio empresarial se resuelve por
Evento Proceso es generado por
Evento Proceso se resuelve por
Función Actor Soportes
Función Capacidad comercial entrega
Función Servicio empresarial está delimitado por
Función Curso de acción es influenciado por
Función Función Se comunica con
Función Función Descompone
Función Unidad de organización Es propiedad de
Función Proceso orquesta
Función Proceso Descompone
Meta Curso de acción es realizado por
Meta Conductor direcciones
Meta Meta Descompone
Meta Objetivo se hace específico
Servicio de aplicación de componente de aplicación lógica Implementos
Componente de aplicación lógica Descomposición de componente de aplicación lógica
Componente de aplicación lógica El componente de aplicación lógica se comunica con
Componente de aplicación lógica Componente de datos lógicos Usado por
Componente de aplicación lógica Componente de tecnología lógica Es atendido por
Componente de aplicación lógica Componente de aplicación física Es realizado por
Componente de datos lógicos Entidad de datos Encapsula
Componente de datos lógicos Usos de componentes de aplicaciones lógicas
Componente de datos lógicos Componente de datos físicos es realizado por
Servicio empresarial de componente de tecnología lógica Proporciona una plataforma para
Componente de tecnología lógica Componente de aplicación lógica Servicios

Componente de tecnología lógica El componente de tecnología lógica se descompone
Componente de tecnología lógica Componente de tecnología lógica Depende de
Componente de Tecnología Lógica Componente de Tecnología Física Se realiza mediante
Servicio de tecnología de componente de tecnología lógica Suministros
Medida Medida Descompone
Medida Objetivo Establece los criterios de rendimiento para
Objetivo Meta se da cuenta
Objetivo Medida es rastreado contra

Objetivo Objetivo Descompone
Unidad de organización Actor Contiene
Unidad de organización Capacidad comercial entrega
Unidad de organización Servicio empresarial Posee y gobierna

Unidad de organización Curso de acción participa en
Estándar TOGAF® — Contenido de la arquitectura 27

Relaciones de metamodelo Marco de contenido TOGAF y metamodelo empresarial
Unidad de organización Conductor está motivado por

Unidad de organización Función Habilita
Unidad de organización Unidad de organización Descompone

Unidad de organización Producto entrega
Componente de aplicación física Componente de aplicación lógica Realiza

Componente de aplicación física Componente de aplicación física Descompone
Componente de aplicación física Componente de aplicación física Se comunica con
Componente de aplicación física Componente de datos físicos Usado por
Componente de aplicación física Componente de tecnología física Es atendido por
Componente de datos físicos Componente de datos lógicos se da cuenta
Componente de datos físicos Componente de aplicación física utilizado por

Componente de datos físicos Componente de datos físicos Descompone
Componente de tecnología física Componente de tecnología lógica Realiza
Componente de tecnología física Componente de aplicación física Servicios
Componente de tecnología física Componente de tecnología física Se descompone
Componente de tecnología física Componente de tecnología física Depende de
Proceso Actor es producido por
Proceso Actor Soportes
Proceso Capacidad comercial Operacionaliza
Proceso Información de negocios es usado por
Proceso Servicio empresarial orquesta
Proceso Servicio empresarial Descompone
Proceso Control es guiado por
Proceso Evento genera
Proceso Evento resuelve
Proceso Función Soportes
Proceso Función es realizado por
Proceso Proceso Descompone
Proceso Proceso Precede, sigue
Proceso Producto entrega
Proceso Role implica
Proceso Role es realizado por
Proceso Flujo de valor Operacionaliza
Producto Curso de acción es producido por
Producto Unidad de organización es producido por
Producto Proceso es producido por
Role Actor es realizado por
Role Proceso participa en
Role Proceso realizar
Role Role Descompone
Calidad de servicio Contrato Se aplica a
Calidad de servicio Servicio Se aplica a
Servicio de Tecnología Servicio de aplicaciones Sirve
Servicio de Tecnología El componente de tecnología lógica es suministrado por

Flujo de valor Actor implica

Marco de contenido TOGAF y metamodelo empresarial Relaciones de metamodelo
Flujo de valor Actor es desencadenado por
Flujo de valor Capacidad comercial está habilitado por

Flujo de valor Curso de acción es influenciado por
Flujo de valor Proceso es operacionalizado por
Paquete de trabajo Capacidad entrega
Estándar TOGAF® — Arquitectura Contenido © 29

2005-2022 The Open Group, Todos los derechos reservados
Marco de contenido TOGAF y metamodelo empresarial

redistribución
Capítulo 3: Artefactos arquitectónicos
Este capítulo analiza los conceptos relacionados con los artefactos de arquitectura y luego describe los artefactos que se
recomienda crear para cada fase dentro del ADM.
3.1 Conceptos básicos

Los artefactos arquitectónicos se crean para describir un sistema, solución o estado de la empresa. Los conceptos
discutidos en esta sección han sido adaptados de definiciones más formales contenidas en ISO/IEC/IEEE 42010: 2011
e ISO/IEC/IEEE 15288: 2015. Se ilustran en la Figura 3-1.
El "entorno" de un sistema es el contexto que determina el escenario y las circunstancias de todas las influencias sobre
un sistema. El entorno de un sistema incluye influencias de desarrollo, tecnológicas, comerciales, operativas,
organizacionales, políticas, económicas, legales, regulatorias, ecológicas y sociales.
Un "sistema" es una combinación de elementos que interactúan organizados para lograr uno o más propósitos
establecidos.
La "arquitectura" de un sistema son los conceptos o propiedades fundamentales de un sistema en su entorno

incorporados en sus elementos, relaciones y en los principios de su diseño y evolución.
Una "Descripción de Arquitectura" es un producto de trabajo utilizado para expresar una arquitectura; una colección de
vistas y modelos de arquitectura que juntos documentan la arquitectura.
Las "partes interesadas" son individuos, equipos, organizaciones o clases de los mismos, que tienen un interés en un
sistema.
Las "preocupaciones" son intereses en un sistema relevantes para uno o más de sus interesados. Las inquietudes
pueden referirse a cualquier aspecto del funcionamiento, desarrollo u operación del sistema, incluidas consideraciones
como el rendimiento, la confiabilidad, la seguridad, la distribución y la capacidad de evolución, y pueden determinar la
aceptabilidad del sistema.
Una "vista de arquitectura" es una representación de un sistema desde la perspectiva de un conjunto relacionado de
preocupaciones. Consiste en uno o más modelos de arquitectura del sistema.
Un "Modelo de Arquitectura" es una representación de un tema de interés. Un modelo proporciona una representación
a menor escala, simplificada y/o abstracta del tema.
Al capturar o representar el diseño de la arquitectura de un sistema, el arquitecto normalmente creará uno o más
modelos de arquitectura, posiblemente utilizando diferentes herramientas. Una vista de arquitectura comprenderá partes
seleccionadas de uno o más modelos, elegidos para demostrar a una parte interesada en particular o grupo de partes
interesadas que sus preocupaciones se están abordando adecuadamente en el diseño de la arquitectura del sistema.

Conceptos básicos Artefactos Arquitectónicos
Sistema de exhibiciones
Arquitectura
Interés 1 1
1 1 1
expresa
tiene intereses en
1..* 1
1
identifica Arquitectura
Interesado 1..* 1 Descripción
1..* 1
posee
1..*
1..*
Inquietud
1..* 1..*
marcos
1..* 1..*
1..* 1..*
Arquitectura gobierna Arquitectura
1 1 Vista
Punto de vista
1..* 1..*
1..* 1..*
gobierna Arquitectura
tipo de modelo 1 1..* Modelo
Figura 3-1 Conceptos básicos de arquitectura
Un "punto de vista de la arquitectura" es una especificación de las convenciones para un tipo particular de
vista de la arquitectura. También puede denominarse definición o esquema para ese tipo de vista de arquitectura.
Establece las convenciones para construir, interpretar y usar una vista de arquitectura para
abordar una preocupación específica (o conjunto de preocupaciones) sobre un sistema de interés.
Un "Tipo de modelo" establece convenciones para un tipo de modelado.
Un punto de vista de la arquitectura hace referencia a uno o más tipos de modelos; una vista de la arquitectura incorpora
uno o más modelos.
Una "biblioteca de puntos de vista" es una colección de especificaciones de puntos de vista de arquitectura contenidas en
la parte de la Biblioteca de Referencia del Repositorio de Arquitectura.
ÿ Una vista de la arquitectura es lo que ve; un punto de vista de la arquitectura es donde estás mirando
desde: el punto de vista o la perspectiva que determina lo que ves

Artefactos Arquitectónicos Conceptos básicos
ÿ Los puntos de vista de la arquitectura son genéricos y se pueden almacenar en bibliotecas para su reutilización; un
La vista de arquitectura siempre es específica de la arquitectura para la que se crea.
ÿ Cada vista de arquitectura tiene un punto de vista de arquitectura asociado que la describe, al menos
implícitamente
ISO/IEC/IEEE 42010:2011 anima a los arquitectos a definir los puntos de vista de la arquitectura de forma explícita. Hacer esta
distinción entre el contenido y el esquema de una vista puede parecer al principio una sobrecarga innecesaria, pero proporciona un
mecanismo para reutilizar los puntos de vista de la arquitectura en diferentes arquitecturas.
En resumen, las vistas de la arquitectura son representaciones de la arquitectura general en términos significativos para las partes interesadas.
Permiten que la arquitectura sea comunicada y entendida por las partes interesadas, para que puedan verificar que el sistema abordará sus
preocupaciones.
Las inquietudes suelen estar relacionadas con los requisitos. Una inquietud puede ser un tipo de requisito general, como la disponibilidad.
Puede conducir a la definición de varios requisitos particulares. Puede ser un interés relacionado con algún objetivo de un actor. La
identificación de preocupaciones ayuda a garantizar que se aborden los intereses de las partes interesadas y se identifiquen los requisitos.
Asociar preocupaciones con tipos generales de artefactos ayuda a los arquitectos a seleccionar y desarrollar artefactos particulares para
presentarlos a las partes interesadas.
3.1.1 Ejemplo simple de un punto de vista de arquitectura y una vista de arquitectura

Para muchas arquitecturas, un punto de vista de arquitectura útil es el de los dominios comerciales, que se puede ilustrar con un ejemplo del
propio The Open Group.
El punto de vista de la arquitectura se especifica de la siguiente manera:
Arquitectura
Elemento de punto de vista Descripción

Partes interesadas Consejo de Administración, Director Ejecutivo Muestre las
Preocupaciones relaciones de alto nivel entre los sitios geográficos de EE. UU./Reino Unido y las funciones
comerciales.
Técnica de modelado Diagrama de cajas anidadas.

Cajas exteriores=ubicaciones; cajas internas = funciones de negocio.
Semántica del anidamiento = funciones realizadas en las ubicaciones.
La vista de arquitectura correspondiente de The Open Group (en 2017) se muestra en la Figura 3-2.

Conceptos básicos Artefactos Arquitectónicos
Figura 3-2 Vista de arquitectura de ejemplo: los dominios comerciales de Open Group
3.2 Desarrollo de vistas de arquitectura en el ADM

3.2.1 Directrices generales
La elección de qué vistas de arquitectura particulares desarrollar es una de las decisiones clave que debe tomar el
arquitecto.
El arquitecto tiene la responsabilidad de garantizar la integridad (adecuación para el propósito) de la arquitectura, en

términos de abordar adecuadamente todas las preocupaciones pertinentes de sus partes interesadas; y la integridad de
la arquitectura, en términos de conectar todos los diversos puntos de vista entre sí, reconciliando satisfactoriamente las
preocupaciones en conflicto de las diferentes partes interesadas, y mostrando las compensaciones hechas al hacerlo
(entre seguridad y rendimiento, por ejemplo). ejemplo).
La elección tiene que estar restringida por consideraciones de practicidad y por el principio de adecuación al propósito
(es decir, la arquitectura debe desarrollarse solo hasta el punto en que sea apta para el propósito, y no reiterada ad
infinitum como un ejercicio académico).
Como se explica en el estándar TOGAF: método de desarrollo de arquitectura, el desarrollo de vistas de arquitectura es
un proceso iterativo. La progresión típica es de negocio a tecnología, utilizando una técnica como los escenarios de
negocio (consulte la Guía de la serie TOGAF® : Business

redistribución
Artefactos Arquitectónicos Desarrollo de vistas de arquitectura en el ADM
Escenario ios) para identificar adecuadamente todas las preocupaciones pertinentes; y desde una visión general de alto
nivel hasta detalles de bajo nivel, refiriéndose continuamente a las preocupaciones y requisitos de las partes interesadas a
lo largo del proceso.
Además, cada una de estas progresiones debe realizarse para dos entornos distintos: el entorno existente (denominado
línea de base en el ADM) y el entorno de destino. El arquitecto debe desarrollar vistas de arquitectura pertinentes tanto de
la Arquitectura de referencia como de la Arquitectura de destino. Esto proporciona el contexto para el análisis de brechas al
final de las Fases B, C y D del ADM, que establece los elementos de la Arquitectura de referencia que se llevarán adelante
y los elementos que se agregarán, eliminarán o reemplazarán.
Todo este proceso se explica en el Estándar TOGAF - Técnicas ADM.
3.2.2 Proceso de creación de vista de arquitectura
, ellamarco
IEEE 42010:2011. Por lo tanto, siguiente
TOGAF
descripción
alienta pero
cubre
notanto
exigelaelsituación
uso de Como
en la que
se mencionó
se ha adoptado
anteriormente,
ISO/IEC/IEEE
ISO/IEC/
42010: 2011 como en la que no.
ISO/IEC/IEEE 42010:2011 en sí mismo no requiere ningún proceso específico para desarrollar puntos de vista de
arquitectura o crear vistas a partir de ellos. Cuando se haya adoptado ISO/IEC/IEEE 42010: 2011 y se haya convertido en
una práctica bien establecida dentro de una organización, a menudo será posible crear las vistas requeridas para una
arquitectura en particular siguiendo estos pasos:
1. Consulte una biblioteca existente de puntos de vista de la arquitectura
2. Seleccione los puntos de vista de la arquitectura apropiados (basados en las partes interesadas y las preocupaciones)
que deben ser cubiertos por vistas)
3. Genere vistas del sistema utilizando los puntos de vista de arquitectura seleccionados como plantillas
Se puede esperar que este enfoque traiga los siguientes beneficios:
ÿ Menos trabajo para los arquitectos (porque los miradores de arquitectura ya han sido
definido y, por lo tanto, las vistas se pueden crear más rápido)
ÿ Mejor comprensibilidad para las partes interesadas (porque los puntos de vista de la arquitectura ya están
familiar)
ÿ Mayor confianza en la validez de las vistas (porque sus puntos de vista arquitectónicos tienen un historial conocido)
Sin embargo, siempre pueden surgir situaciones en las que se necesite una vista de arquitectura para la cual no se haya
predefinido un punto de vista de arquitectura adecuado. Esta también es la situación, por supuesto, cuando una organización
aún no ha incorporado ISO/IEC/IEEE 42010: 2011 en su práctica de arquitectura y no ha establecido una biblioteca de
puntos de vista de arquitectura.
En cada caso, el arquitecto puede optar por desarrollar un nuevo punto de vista de arquitectura que cubra la necesidad
pendiente y luego generar una vista de arquitectura a partir de él. (Esta es la práctica recomendada por ISO/IEC/IEEE
42010:2011). Alternativamente, un enfoque más pragmático puede ser igualmente exitoso: el arquitecto puede crear una
vista de arquitectura ad hoc para un sistema específico y luego considerar si una forma generalizada de la arquitectura
implícita El punto de vista debe definirse explícitamente y guardarse en una biblioteca, para que pueda reutilizarse. (Esta es
una forma de establecer inicialmente una biblioteca de puntos de vista de la arquitectura).
Sea cual sea el contexto, el arquitecto debe ser consciente de que cada vista de la arquitectura tiene un

Desarrollo de vistas de arquitectura en el ADM Artefactos Arquitectónicos
punto de vista de la arquitectura, al menos implícitamente, y que definir el punto de vista de la arquitectura de manera
sistemática (según lo recomendado por ISO/IEC/IEEE 42010:2011) ayudará a evaluar su eficacia; es decir, ¿el punto
de vista de la arquitectura cubre las preocupaciones relevantes de las partes interesadas?
3.3 Vistas, herramientas e idiomas

La necesidad de vistas de arquitectura y el proceso de desarrollarlas siguiendo el ADM se explica anteriormente. Esta
sección describe las relaciones entre las vistas de la arquitectura, las herramientas utilizadas para desarrollarlas y
analizarlas, y un lenguaje estándar que permite la interoperabilidad entre las herramientas.
3.3.1 Resumen
Para lograr los objetivos de completitud e integridad en una arquitectura, las vistas de la arquitectura generalmente se
desarrollan, visualizan, comunican y administran mediante una herramienta.
En el estado actual del mercado, normalmente se deben utilizar diferentes herramientas para desarrollar y analizar
diferentes vistas de la arquitectura. Es muy deseable que una descripción de la arquitectura se codifique en un lenguaje
estándar, para permitir un enfoque estándar para la descripción de la semántica de la arquitectura y su reutilización
entre diferentes herramientas.
Un punto de vista de arquitectura normalmente también se desarrolla, visualiza, comunica y administra utilizando una
herramienta, y también es muy deseable que se desarrollen puntos de vista de arquitectura estándar (es decir, plantillas
o esquemas), de modo que las diferentes herramientas que se ocupan de las mismas vistas puedan interoperar. , los
elementos fundamentales de una arquitectura se pueden reutilizar y la descripción de la arquitectura se puede compartir
entre herramientas.
Los problemas relacionados con la evaluación de herramientas para el trabajo de arquitectura se analizan en detalle en
el Estándar TOGAF: Método de desarrollo de arquitectura.
3.4 Vistas de la arquitectura y puntos de vista de la arquitectura

3.4.1 Ejemplo de vistas de arquitectura y puntos de vista de arquitectura
Para ilustrar los conceptos de vistas de arquitectura y puntos de vista de arquitectura, considere el ejemplo de un
sistema aeroportuario muy simple con dos partes interesadas diferentes: el piloto y el controlador de tránsito aéreo.
Se puede desarrollar una vista de la arquitectura desde el punto de vista de la arquitectura del piloto, que aborda las
preocupaciones del piloto. Igualmente, se puede desarrollar otra vista de la arquitectura desde el punto de vista de la
arquitectura del controlador de tránsito aéreo. Ninguna vista de la arquitectura describe completamente el sistema en
su totalidad, porque el punto de vista de la arquitectura de cada parte interesada restringe (y reduce) la forma en que
cada uno ve el sistema en general.
El punto de vista de la arquitectura del piloto comprende algunas preocupaciones que no son relevantes para el
controlador, como los pasajeros y el combustible, mientras que el punto de vista de la arquitectura del controlador
comprende algunas preocupaciones que no son relevantes para el piloto, como otros aviones. También hay elementos
compartidos entre los dos puntos de vista de la arquitectura, como el modelo de comunicación entre el piloto y el
controlador, y la información vital sobre el propio avión.
Un punto de vista de arquitectura es un modelo (o descripción) de la información contenida en una vista. En

redistribución
Artefactos Arquitectónicos Vistas de arquitectura y puntos de vista de arquitectura
nuestro ejemplo, un punto de vista de la arquitectura es la descripción de cómo el piloto ve el sistema, y el otro punto de vista
de la arquitectura es cómo el controlador ve el sistema.
Los pilotos describen el sistema desde su perspectiva, usando un modelo de su posición y vector hacia o desde la pista.
Todos los pilotos usan este modelo, y el modelo tiene un lenguaje específico que se usa para capturar información y completar
el modelo.
Los controladores describen el sistema de manera diferente, utilizando un modelo del espacio aéreo y las ubicaciones y
vectores de las aeronaves dentro del espacio aéreo. Nuevamente, todos los controladores usan un lenguaje común derivado
del modelo común para capturar y comunicar información pertinente a su punto de vista de arquitectura.
Afortunadamente, cuando los controladores hablan con los pilotos, utilizan un lenguaje de comunicación común. (En otras
palabras, los modelos que representan sus puntos de vista arquitectónicos individuales se cruzan parcialmente).
Parte de este lenguaje común se refiere a la ubicación y los vectores de las aeronaves, y es esencial para la seguridad.
Entonces, en esencia, cada punto de vista de la arquitectura es un modelo abstracto de cómo todas las partes interesadas
de un tipo particular (todos los pilotos o todos los controladores) ven el sistema aeroportuario.
Existen herramientas para ayudar a las partes interesadas, especialmente cuando interactúan con modelos complejos como
el modelo de un espacio aéreo o el modelo de un vuelo aéreo.
La interfaz para el usuario humano de una herramienta suele estar cerca del modelo y el lenguaje asociado con el punto de
vista de la arquitectura. Las herramientas únicas del piloto son los indicadores de combustible, altitud, velocidad y ubicación.
La principal herramienta del controlador es el radar. La herramienta común es una radio.
Para resumir del ejemplo anterior, podemos ver que una vista de arquitectura puede subdividir el sistema a través de la
perspectiva de la parte interesada, como el piloto versus el controlador. Este subconjunto se puede describir mediante un
modelo abstracto llamado punto de vista de la arquitectura, como un vuelo aéreo versus un modelo de espacio aéreo. Esta
descripción de la vista de la arquitectura está documentada en un lenguaje parcialmente especializado, como "habla del
piloto" versus "habla del controlador". Las herramientas se utilizan para ayudar a las partes interesadas y se relacionan entre
sí en términos del lenguaje derivado del punto de vista de la arquitectura ("lenguaje del piloto" versus "lenguaje del
controlador").
Cuando las partes interesadas utilizan herramientas comunes, como el contacto por radio entre el piloto y el controlador, es
esencial un lenguaje común.
3.4.2 Vistas de la arquitectura y puntos de vista de la arquitectura en la arquitectura empresarial

Ahora mapeemos este ejemplo a la Arquitectura Empresarial. Considere dos partes interesadas en un nuevo sistema
informático pequeño: los usuarios y los desarrolladores.
Los usuarios del sistema tienen un punto de vista de la arquitectura que refleja sus preocupaciones al interactuar con el
sistema, y los desarrolladores del sistema tienen un punto de vista de la arquitectura diferente. Es poco probable que las
vistas de la arquitectura que se desarrollan para abordar cualquiera de los dos puntos de vista de la arquitectura describan
exhaustivamente todo el sistema, porque cada perspectiva reduce la forma en que cada uno ve el sistema.
El punto de vista de la arquitectura del usuario se compone de todas las formas en que el usuario interactúa con el sistema,
sin ver ningún detalle, como aplicaciones o sistemas de gestión de bases de datos (DBMS).
El punto de vista de la arquitectura del desarrollador es uno de productividad y herramientas, y no incluye cosas como datos
reales en vivo y conexiones con los consumidores.
Sin embargo, hay cosas que se comparten, como las descripciones de los procesos que se

Vistas de arquitectura y puntos de vista de arquitectura Artefactos Arquitectónicos
habilitado por el sistema y/o los protocolos de comunicación configurados para que los usuarios comuniquen los
problemas directamente al desarrollo.
En este ejemplo, un punto de vista de la arquitectura es la descripción de cómo el usuario ve el sistema y el otro punto
de vista de la arquitectura es cómo el desarrollador ve el sistema. Los usuarios describen el sistema desde su
perspectiva, utilizando un modelo de disponibilidad, tiempo de respuesta y acceso a la información. Todos los usuarios
del sistema utilizan este modelo, y el modelo tiene un lenguaje específico.
Los desarrolladores describen el sistema de manera diferente a los usuarios, utilizando un modelo de software
conectado a hardware distribuido en una red, etc. Sin embargo, hay muchos tipos de desarrolladores (base de datos,
seguridad, etc.) del sistema, y no tienen un común. lenguaje derivado del modelo.
3.4.3 Necesidad de un lenguaje común y herramientas interoperables para la descripción de la arquitectura

Las herramientas existen tanto para usuarios como para desarrolladores. Las herramientas como la
ayuda en línea están ahí específicamente para los usuarios e intentan utilizar el idioma del usuario. Existen muchas
herramientas diferentes para diferentes tipos de desarrolladores, pero sufren de la falta de un lenguaje común que se
requiere para unir el sistema. Es difícil, si no imposible, en el estado actual del mercado de herramientas que una
herramienta interactúe con otra herramienta.
Los problemas relacionados con la evaluación de herramientas para el trabajo de arquitectura se analizan en detalle en
el Estándar TOGAF: Método de desarrollo de arquitectura.
3.5 Conclusiones
Esta sección intenta tratar las vistas de una manera estructurada, pero de ninguna manera es un tratado completo sobre
las vistas.
En general, el marco TOGAF abarca los conceptos y definiciones presentados en ISO/IEC/IEEE 42010:2011,
específicamente los conceptos que ayudan a guiar el desarrollo de una vista de arquitectura y hacen que la vista de
arquitectura sea procesable. Estos conceptos se pueden resumir como:
ÿ Seleccionar una parte interesada
clave ÿ Comprender sus preocupaciones y generalizar/documentar esas preocupaciones
ÿ Comprender cómo modelar y tratar esas preocupaciones

redistribución
Artefactos Arquitectónicos Conclusiones
3.6 Artefactos Arquitectónicos por Fase ADM

Concepto de Catálogo, Matriz y Diagrama El
Metamodelo de Empresa se utiliza como una técnica para estructurar la información arquitectónica de manera ordenada
para que pueda ser procesada para satisfacer las necesidades de las partes interesadas. La mayoría de las partes
interesadas en la arquitectura en realidad no necesitan saber cuál es el metamodelo de la arquitectura y solo les
preocupan cuestiones específicas, como "¿qué funcionalidad admite esta aplicación?", "¿Qué procesos se verán
afectados por este proyecto?", etc. Para satisfacer las necesidades de estos interesados, se utilizan los conceptos
TOGAF de bloques de construcción, catálogos, matrices y diagramas.
Los bloques de construcción son entidades de un tipo particular dentro del metamodelo (por ejemplo, un servicio
empresarial denominado "Orden de compra"). Los bloques de construcción transportan metadatos de acuerdo con el
metamodelo, que admite consultas y análisis. Por ejemplo, los servicios comerciales tienen un atributo de metadatos
para el propietario, que permite a una parte interesada consultar todos los servicios comerciales propiedad de una
organización en particular. Los bloques de construcción también pueden incluir entidades dependientes o contenidas,
según corresponda al contexto de la arquitectura (por ejemplo, un servicio comercial denominado "Orden de compra"
puede incluir implícitamente una serie de procesos, entidades de datos, componentes de aplicaciones, etc.).
Los catálogos son listas de componentes básicos de un tipo específico, o de tipos relacionados, que se utilizan con
fines de gobernanza o de referencia (por ejemplo, un organigrama que muestra ubicaciones y actores). Al igual que con
los bloques de construcción, los catálogos llevan metadatos de acuerdo con el metamodelo, que admite consultas y
análisis.
Las matrices son cuadrículas que muestran las relaciones entre dos o más entidades del modelo. Las matrices se
utilizan para representar relaciones basadas en listas en lugar de gráficas en su uso (por ejemplo, una matriz CRUD
que muestra qué aplicaciones crean, leen, actualizan y eliminan un tipo particular de datos es difícil de representar
visualmente).
Los diagramas son representaciones del contenido arquitectónico en un formato gráfico para permitir que las partes
interesadas recuperen la información requerida. Los diagramas también se pueden usar como una técnica para
completar gráficamente el contenido de la arquitectura o para verificar la integridad de la información que se ha
recopilado. El marco de contenido TOGAF define un conjunto de diagramas de arquitectura que se crearán (por ejemplo,
organigrama). Cada uno de estos diagramas se puede crear varias veces para una arquitectura con diferente estilo o
cobertura de contenido para adaptarse a las preocupaciones de las partes interesadas.
Los bloques de construcción, los catálogos, las matrices y los diagramas son conceptos que están bien respaldados por
las herramientas líderes de Enterprise Architecture. En entornos donde se utilizan herramientas para modelar la
arquitectura, dichas herramientas suelen admitir mecanismos para buscar, filtrar y consultar el repositorio de arquitectura
y.
Las consultas a pedido del Repositorio de arquitectura (como el ejemplo de propiedad de servicios comerciales
mencionado anteriormente) se pueden utilizar para generar catálogos, matrices y diagramas ad hoc de la arquitectura.
Dado que este tipo de consulta debe ser flexible por naturaleza, no está restringida ni definida dentro del metamodelo
empresarial.
Las interacciones entre el metamodelo, los bloques de construcción, los diagramas y las partes interesadas se muestran
en la Figura 3-3. La figura 3-4 muestra los artefactos asociados con el metamodelo TOGAF Enterprise.

Artefactos Arquitectónicos por ADM Phase Artefactos Arquitectónicos
Figura 3-3 Interacciones entre metamodelo, bloques de construcción, diagramas y partes interesadas

Artefactos Arquitectónicos Artefactos Arquitectónicos por ADM Phase
Figura 3-4 Artefactos asociados con el metamodelo Enterprise
Los artefactos recomendados para la producción en cada fase de ADM son los siguientes.
3.6.1 Fase Preliminar

A continuación, se describen catálogos, matrices y diagramas que pueden crearse dentro de la Fase Preliminar, como
se describe en el Estándar TOGAF: Método de Desarrollo de Arquitectura.
Catálogo de Principios
El catálogo de Principios captura los principios de los Principios de Negocios y Arquitectura que describen cómo debe
ser una solución o arquitectura "buena". Los principios se utilizan para evaluar y acordar un resultado para los puntos
de decisión de la arquitectura. Los principios también se utilizan como una herramienta para ayudar en la gobernanza
arquitectónica de las iniciativas de cambio.
El catálogo de Principios contiene las siguientes entidades de metamodelo:
ÿ Principio

3.6.2 Fase A: Visión de la Arquitectura
A continuación, se describen catálogos, matrices y diagramas que se pueden crear dentro de la Fase A (Visión de la
arquitectura) como se describe en el Estándar TOGAF: Método de desarrollo de la arquitectura.
Catálogo de partes
interesadas El propósito del catálogo de partes interesadas es identificar a las partes interesadas para el compromiso
de la arquitectura, su influencia sobre el compromiso y sus preguntas, problemas o preocupaciones clave que deben
abordarse en el marco de la arquitectura.
Comprender a las partes interesadas y sus requisitos le permite a un arquitecto enfocar el esfuerzo en áreas que
satisfagan las necesidades de las partes interesadas (consulte el Estándar TOGAF - Técnicas ADM).
Debido a la naturaleza potencialmente sensible de la información de mapeo de las partes interesadas y al hecho de que
la fase de Visión de la arquitectura está destinada a llevarse a cabo utilizando técnicas de modelado informales, no se
usarán entidades de metamodelo específicas para generar un catálogo de partes interesadas.
Diagrama de cadena de
valor Un diagrama de cadena de valor proporciona una vista de orientación de alto nivel de una empresa y cómo
interactúa con el mundo exterior. En contraste con el mapa organizacional más formal desarrollado dentro de la Fase B
(Arquitectura Comercial), el diagrama de la Cadena de Valor se enfoca en el impacto de la presentación.
El propósito de este diagrama es incorporar y alinear rápidamente a las partes interesadas para una iniciativa de cambio
en particular, de modo que todos los participantes comprendan el contexto funcional y organizacional de alto nivel del
compromiso de la arquitectura.
Diagrama del concepto de solución
Un diagrama de concepto de solución proporciona una orientación de alto nivel de la solución que se prevé para cumplir
con los objetivos del compromiso de arquitectura. En contraste con los diagramas de arquitectura más formales y
detallados desarrollados en las siguientes fases, el concepto de solución representa un "boceto a lápiz" de la solución
esperada al comienzo del compromiso.
Este diagrama puede incorporar objetivos, requisitos y restricciones clave para el compromiso y también resaltar áreas
de trabajo que se investigarán en más detalle con el modelado de arquitectura formal.
Su propósito es incorporar y alinear rápidamente a las partes interesadas para una iniciativa de cambio en particular, de
modo que todos los participantes entiendan qué busca lograr el compromiso de la arquitectura y cómo se espera que un
enfoque de solución particular satisfaga las necesidades de la empresa.
Diagrama de modelo de negocio
Un modelo que describe la lógica de cómo una empresa crea, entrega y captura valor.

redistribución
Mapa de capacidad empresarial
Un diagrama que muestra las capacidades comerciales que una empresa necesita para cumplir sus propósitos.
Mapa de flujo de valor
Un diagrama que representa una colección de extremo a extremo de actividades de valor agregado que crean un
resultado general para un cliente, parte interesada o usuario final.
3.6.3 Fase B: Arquitectura empresarial
A continuación se describen catálogos, matrices y diagramas que pueden crearse dentro de la Fase B (Arquitectura
empresarial) como se describe en el Estándar TOGAF: Método de desarrollo de arquitectura.
Catálogo de organizaciones/
actores El propósito del catálogo de organizaciones/actores es capturar una lista definitiva de todos los participantes que
interactúan con TI, incluidos los usuarios y propietarios de los sistemas de TI.
Se puede hacer referencia al catálogo de Organizaciones/Actor al desarrollar los requisitos para comprobar si están
completos.
Por ejemplo, se puede probar la integridad de los requisitos para una aplicación que presta servicios a los clientes
verificando exactamente qué tipos de clientes deben admitirse y si existen requisitos o restricciones particulares para los
tipos de usuarios.
El catálogo Organización/Actor contiene las siguientes entidades de metamodelo:
ÿ Unidad organizativa
ÿ actor
ÿ Ubicación (puede incluirse en este catálogo si no se cuenta con un catálogo de ubicación independiente).
mantenido)
Catálogo de impulsores /metas/
objetivos El propósito del catálogo de impulsores/metas/objetivos es proporcionar una referencia entre organizaciones
de cómo una organización cumple con sus impulsores en términos prácticos a través de metas, objetivos y (opcionalmente)
medidas.
La publicación de un desglose definitivo de impulsores, metas y objetivos permite que las iniciativas de cambio dentro de
la empresa identifiquen sinergias en toda la organización (p. ej., varias organizaciones que intentan lograr objetivos
similares), lo que a su vez permite identificar a las partes interesadas e iniciativas de cambio relacionadas. alineados o
consolidados.
El catálogo Impulsor/Meta/Objetivo contiene las siguientes entidades de metamodelo:
ÿ Conductor
ÿ Objetivo
ÿ Objetivo

ÿ Medida (puede incluirse opcionalmente)
Catálogo de
roles El propósito del catálogo de roles es proporcionar una lista de todos los niveles de autorización o zonas dentro de una
empresa. Con frecuencia, la seguridad o el comportamiento de las aplicaciones se definen en función de conceptos de
autorización entendidos localmente que crean consecuencias complejas e inesperadas cuando se combinan en el escritorio
del usuario.
Si los roles se definen, entienden y alinean entre organizaciones y aplicaciones, esto permite una experiencia de usuario más
fluida y, en general, aplicaciones más seguras, ya que los administradores no necesitan recurrir a soluciones alternativas
para permitir que los usuarios realicen su trabajo.
Además de respaldar la definición de seguridad para la empresa, el catálogo de roles también es una entrada clave para
identificar los impactos de la gestión de cambios organizacionales, definir las funciones laborales y ejecutar la capacitación
del usuario final.
Como cada rol implica el acceso a una serie de funciones comerciales, si alguna de estas funciones comerciales se ve
afectada, se requerirá la gestión del cambio, es posible que sea necesario redefinir las responsabilidades organizacionales y
es posible que se necesite una nueva capacitación.
El catálogo de roles contiene las siguientes entidades de metamodelo:
ÿ Rol
Catálogo de funciones/servicios comerciales
El propósito del catálogo de funciones/servicios comerciales es proporcionar una descomposición funcional en un formato
que se pueda filtrar, informar y consultar, como complemento de los diagramas gráficos de descomposición funcional.
El catálogo de funciones/servicios empresariales se puede utilizar para identificar las capacidades de una organización y
comprender el nivel de gobierno que se aplica a las funciones de una organización. Esta descomposición funcional se puede
utilizar para identificar nuevas capacidades necesarias para respaldar el cambio empresarial o se puede utilizar para
determinar el alcance de las iniciativas de cambio, las aplicaciones o los componentes tecnológicos.
El catálogo de servicios/funciones empresariales contiene las siguientes entidades de metamodelo:
ÿ Función comercial
ÿ Servicio comercial
ÿ Servicio de aplicaciones (puede incluirse opcionalmente aquí)
Catálogo de ubicaciones
El catálogo de ubicaciones proporciona una lista de todas las ubicaciones donde una empresa lleva a cabo operaciones
comerciales o alberga activos arquitectónicamente relevantes, como centros de datos o equipos informáticos de usuarios
finales.
Mantener una lista definitiva de ubicaciones permite que las iniciativas de cambio definan rápidamente un alcance de
ubicación y prueben la integridad al evaluar los paisajes actuales o las soluciones objetivo propuestas. Por ejemplo, un
proyecto para actualizar los sistemas operativos de escritorio deberá identificar todas las ubicaciones donde se implementan
los sistemas operativos de escritorio.
De manera similar, cuando se implementan nuevos sistemas, un diagrama de ubicaciones es esencial para

redistribución
para desarrollar estrategias de implementación adecuadas que comprendan la ubicación del usuario y de la aplicación e
identifiquen problemas relacionados con la ubicación, como la internacionalización, la localización, los impactos de la zona
horaria en la disponibilidad, los impactos de la distancia en la latencia, los impactos de la red en el ancho de banda y el acceso.
El catálogo de ubicaciones contiene las siguientes entidades de metamodelo:
ÿ Ubicación
Catálogo de procesos/eventos/controles/productos El
catálogo de procesos/eventos/controles/productos proporciona una jerarquía de procesos, eventos que desencadenan

procesos, salidas de procesos y controles aplicados a la ejecución de procesos.
Este catálogo proporciona un complemento a los diagramas de flujo de procesos que se crean y permite que una empresa
filtre, informe y consulte entre organizaciones y procesos para identificar el alcance, la similitud o el impacto.
Por ejemplo, el catálogo Proceso/Evento/Control/Producto permite que una empresa vea las relaciones de los procesos con
los subprocesos para identificar la cadena completa de impactos resultantes de cambiar un proceso de alto nivel.
El catálogo Proceso/Evento/Control/Producto contiene las siguientes entidades de metamodelo:
ÿ Proceso
ÿ Evento
ÿ controlar
ÿ Producto
Catálogo de contratos/medidas El
catálogo de contratos/medidas proporciona una lista de todos los contratos de servicio acordados y las medidas adjuntas a
esos contratos. Forma la lista maestra de niveles de servicio acordados en toda la empresa.
El catálogo de contratos/medidas contiene las siguientes entidades de metamodelo:
ÿ Servicio de aplicaciones (opcional)
ÿ Contrato
ÿ Medir
Catálogo de Capacidades Empresariales
Una lista de habilidades que una empresa puede poseer para lograr propósitos específicos.
Catálogo de flujo de valor
Una lista de colecciones de extremo a extremo de actividades de valor agregado que crean un resultado general para un
cliente, parte interesada o usuario final.

Catálogo de etapas del flujo de valor
Una lista de colecciones de extremo a extremo de las diferentes etapas para las actividades de valor agregado que crean un
resultado general para el cliente, parte interesada o usuario final.
El catálogo de Etapas de flujo de valor incluye las siguientes entidades de metamodelo:
ÿ Capacidad comercial
ÿ Flujo de valor
Catálogo del glosario empresarial
Este catálogo contiene el nombre y la descripción inequívoca de todos los elementos contenidos en la arquitectura empresarial
o que interactúan con ella.
La información opcional podría incluir sinónimos de empresas de elementos, abreviaturas/acrónimos y relaciones con otros
elementos. Este catálogo proporciona la semántica que deben utilizar todos los analistas (p. ej., negocios, información y
sistemas) para sus productos de arquitectura, incluidos los modelos de información/datos, y evoluciona a lo largo de ADM.
Matriz de interacción comercial
El propósito de esta matriz es representar las interacciones de las relaciones entre las organizaciones y las funciones
comerciales en toda la empresa.
Comprender la interacción comercial de una empresa es importante, ya que ayuda a resaltar la cadena de valor y las
dependencias entre organizaciones.
La matriz de interacción comercial muestra las siguientes entidades y relaciones del metamodelo:
ÿ Organización
ÿ Business Service se comunica con las relaciones de Business Service ÿ Business Service
depende de las relaciones de Business Service
Matriz de actor/rol
El propósito de esta matriz es mostrar qué actores desempeñan qué roles, apoyando la definición de los requisitos de
seguridad y habilidades.
Comprender las relaciones Actor-Role es una herramienta de apoyo clave en la definición de las necesidades de capacitación,
la configuración de seguridad del usuario y la gestión del cambio organizacional.
La matriz Actor/Rol muestra las siguientes entidades y relaciones del metamodelo:
ÿ Actor
ÿ Rol
ÿ Actuación de actores Relaciones de roles

redistribución
Matriz de flujo de valor/capacidad
El propósito de esta matriz es mostrar las capacidades requeridas para soportar cada etapa de un flujo de valor.
Matriz de estrategia/capacidad
El propósito de esta matriz es mostrar las capacidades requeridas para respaldar declaraciones de estrategia específicas.
Matriz de capacidad/organización El
propósito de esta matriz es mostrar los elementos de la organización que implementan cada capacidad.
La matriz Capacidad/Organización incluye las siguientes entidades del metamodelo:
ÿ Flujo de valor
Diagrama de huella empresarial
Un diagrama de Business Footprint describe los vínculos entre los objetivos comerciales, las unidades organizacionales,
las funciones comerciales y los servicios, y asigna estas funciones a los componentes técnicos que brindan la capacidad
requerida.
Un diagrama de Business Footprint proporciona una trazabilidad clara entre un componente técnico y el objetivo comercial
que satisface, al mismo tiempo que demuestra la propiedad de los servicios identificados.
Un diagrama de huella empresarial demuestra solo los hechos clave que vinculan las funciones de la unidad de la
organización para brindar servicios y se utiliza como una plataforma de comunicación para las partes interesadas de alto
nivel (CxO).
Diagrama de información/servicio comercial El
diagrama de información/servicio comercial muestra la información necesaria para respaldar uno o más servicios
comerciales. El diagrama de servicio comercial/información muestra qué datos consume o produce un servicio comercial
y también puede mostrar la fuente de información.
El diagrama Business Service/Información muestra una representación inicial de la información presente dentro de la
arquitectura y, por lo tanto, forma una base para la elaboración y el refinamiento dentro de la Fase C (Arquitectura de
datos).
Diagrama de descomposición funcional
El propósito del diagrama de Descomposición Funcional es mostrar en una sola página las capacidades de una
organización que son relevantes para la consideración de una arquitectura. Al examinar las capacidades de una
organización desde una perspectiva funcional, es posible desarrollar rápidamente modelos de lo que hace la organización
sin verse arrastrado a un debate extenso sobre cómo lo hace la organización.
Una vez que se ha desarrollado un diagrama básico de descomposición funcional, es posible superponer mapas de calor
sobre este diagrama para mostrar el alcance y las decisiones. Por ejemplo, las capacidades a implementar en diferentes
fases de un programa de cambio.

Diagrama del ciclo de vida del
producto Este diagrama muestra las posibles transiciones de estado de un producto empresarial, desde su creación o
recepción hasta su venta, eliminación o destrucción.
El producto puede ser un producto de cualquier tipo (físico, software o servicio).
Diagrama de Meta/Objetivo/Servicio de Negocios El
propósito de un diagrama de Meta/Objetivo/Servicio de Negocios es definir las formas en que un servicio de negocios
contribuye al logro de una visión o estrategia de negocios.
Los servicios empresariales están asociados con los impulsores, las metas, los objetivos y las medidas que respaldan, lo
que permite a la empresa comprender qué servicios empresariales contribuyen a aspectos similares del rendimiento
empresarial. El diagrama Meta/Objetivo/Servicio comercial también proporciona información cualitativa sobre lo que
constituye un alto rendimiento para un servicio comercial particular.
Diagrama de casos de uso empresarial
Un diagrama de caso de uso comercial muestra las relaciones entre los consumidores y los proveedores de servicios
comerciales. Los servicios comerciales son consumidos por actores u otros servicios comerciales y el diagrama de casos
de uso comercial proporciona una riqueza adicional en la descripción de la capacidad comercial al ilustrar cómo y cuándo
se usa esa capacidad.
El propósito del diagrama Business Use-Case es ayudar a describir y validar la interacción entre los actores y sus roles en
los procesos y funciones. A medida que avanza la arquitectura, el caso de uso puede evolucionar desde el nivel comercial
para incluir detalles de datos, aplicaciones y tecnología. Los casos de uso de negocios arquitectónicos también se pueden
reutilizar en el trabajo de diseño de sistemas.
Diagrama de descomposición de la organización
Un diagrama de descomposición de la organización describe los vínculos entre el actor, los roles y la ubicación dentro de
un árbol de la organización.
Un mapa de la organización debe proporcionar una cadena de mando de propietarios y tomadores de decisiones en la
organización. Aunque no es la intención del diagrama de descomposición de la organización vincular el objetivo con la
organización, debería ser posible vincular intuitivamente los objetivos con las partes interesadas desde el diagrama de
descomposición de la organización.
El propósito del diagrama de flujo del proceso es representar todos los modelos y asignaciones relacionadas con la entidad
del metamodelo del proceso.
Los diagramas de flujo de proceso muestran el flujo de control secuencial entre actividades y pueden utilizar técnicas de
carril de natación para representar la propiedad y la realización de los pasos del proceso. Por ejemplo, la aplicación que
admite un paso del proceso puede mostrarse como un carril de natación.
Además de mostrar una secuencia de actividad, los flujos de proceso también se pueden usar para detallar los controles
que se aplican a un proceso, los eventos que desencadenan o resultan de la finalización de un proceso y también los
productos que se generan a partir de la ejecución del proceso.
Los diagramas de flujo de procesos son útiles para elaborar la arquitectura con especialistas en la materia, ya que permiten
que el especialista describa "cómo se realiza el trabajo" para una función en particular. A través de este proceso, cada paso
del proceso puede convertirse en una función más detallada y, a su vez, puede elaborarse como un proceso.

redistribución
Diagrama de eventos de negocios
El propósito del diagrama de eventos comerciales es representar la relación entre los eventos y el proceso.
Ciertos eventos, como la llegada de cierta información (p. ej., el cliente envía un pedido de venta) o un determinado momento
(p. ej., final del trimestre fiscal), hacen que sea necesario emprender ciertas acciones dentro de la empresa. . Estos se
denominan a menudo "eventos comerciales" o simplemente "eventos" y se consideran desencadenantes de un proceso. Es
importante señalar que el evento debe desencadenar un proceso y generar una respuesta o resultado comercial.
Mapa de capacidad empresarial
Un diagrama que muestra las capacidades comerciales que una empresa necesita para cumplir sus propósitos.
Las capacidades empresariales pueden descomponerse en subcapacidades.
Mapa de flujo de valor
Un diagrama que representa una colección de extremo a extremo de actividades de valor agregado que crean un resultado
general para un cliente, parte interesada o usuario final.
El mapa de flujo de valor incluye las siguientes entidades de metamodelo:
ÿ Flujo de valor
Mapa de la organización
Un diagrama que muestra las relaciones entre las entidades principales que componen la empresa, sus socios y partes
interesadas.
Información Mapa
Una colección de conceptos de información y sus relaciones entre sí. Los conceptos de información, en efecto, reflejan el
vocabulario comercial; por ejemplo, cliente, cuenta o producto. La información de mapeo en Business Architecture comienza
con una lista de los elementos que son más importantes para el negocio y cómo se describen en términos comerciales.
3.6.4 Fase C: Arquitectura de datos
A continuación se describen catálogos, matrices y diagramas que se pueden crear dentro de la Fase C (Arquitectura de
datos) como se describe en el Estándar TOGAF: Método de desarrollo de arquitectura.
Catálogo de entidades de datos /componentes
de datos Este catálogo identifica y mantiene una lista de los datos utilizados en la empresa, relacionando entidades de datos
con componentes de datos que muestran cómo se estructuran las entidades de datos.
Su finalidad es:
ÿ Identificar todos los datos utilizados en la empresa
ÿ Fomentar el uso eficaz de los datos
El catálogo de entidades de datos/componentes de datos contiene las siguientes entidades de metamodelo:

ÿ Entidad de datos
ÿ Componente de datos lógicos ÿ
Componente de datos físicos
Matriz de entidad de datos/función comercial El
propósito de la matriz de entidad de datos/función comercial es representar la relación entre las entidades de datos y las funciones
comerciales dentro de la empresa. Las funciones comerciales están respaldadas por servicios comerciales con límites explícitamente
definidos y serán respaldadas y realizadas por procesos comerciales. El mapeo de la relación Entidad de Datos-Función de Negocio
permite que ocurra lo siguiente:
ÿ Asignar la propiedad de las entidades de datos a las organizaciones ÿ
Comprender los requisitos de intercambio de datos e información de los servicios comerciales ÿ Apoyar el análisis
de brechas y determinar si faltan entidades de datos y es necesario

ser creado
ÿ Definir aplicación de origen, aplicación de registro y aplicación de referencia para datos

entidades
ÿ Permitir el desarrollo de programas de gobierno de datos en toda la empresa (establecer

administrador, desarrollar estándares de datos pertinentes a la función comercial, etc.)
La matriz Entidad de datos/Función comercial muestra las siguientes entidades y relaciones:
ÿ Entidad de datos
ÿ Relación de la entidad de datos con la unidad organizativa propietaria
Aplicación/matriz de datos
El propósito de la matriz de aplicación/datos es representar la relación entre las aplicaciones (es decir, los componentes de la
aplicación) y las entidades de datos a las que acceden y actualizan.
Las aplicaciones crearán, leerán, actualizarán y eliminarán entidades de datos específicas que están asociadas con ellas. Por ejemplo,
una aplicación de gestión de relaciones con el cliente (CRM) creará, leerá, actualizará y eliminará información de la entidad del cliente.
Las entidades de datos en un entorno de paquete/servicios empaquetados se pueden clasificar como datos maestros, datos de
referencia, datos transaccionales, datos de contenido y datos históricos. Las aplicaciones que operan en las entidades de datos
incluyen aplicaciones transaccionales, aplicaciones de administración de información y aplicaciones de almacenamiento comercial.
El mapeo de la relación Componente de aplicación-Entidad de datos es un paso importante ya que permite que ocurra lo siguiente:
ÿ Asignar acceso de datos a aplicaciones específicas en la organización ÿ Comprender el
grado de duplicación de datos dentro de diferentes aplicaciones y la escala de la

ciclo de vida de los datos
ÿ Comprender dónde se actualizan los mismos datos por diferentes aplicaciones
50 The Open Group Standard (2022) ©

2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para redistribución
ÿ Apoyar el análisis de brechas y determinar si falta alguna de las aplicaciones y

como resultado es necesario crear
La matriz de aplicación/datos es una tabla bidimensional con el componente de aplicación lógica en un eje y la entidad de datos en
el otro eje.
Diagrama de datos conceptuales
El propósito clave del diagrama de datos conceptuales es representar las relaciones entre las entidades de datos críticos dentro de
la empresa. Este diagrama se ha desarrollado para abordar las preocupaciones de las partes interesadas del negocio.
Las técnicas utilizadas incluyen:
ÿ Modelos de relación de entidad
ÿ Diagramas de clases UML simplificados
Diagrama de datos lógicos
El propósito clave del diagrama de datos lógicos es mostrar vistas lógicas de las relaciones entre las entidades de datos críticos
dentro de la empresa. Este diagrama se ha desarrollado para abordar las inquietudes de:
ÿ Desarrolladores de aplicaciones
ÿ Diseñadores de bases de datos
Diagrama de difusión de datos
El propósito del diagrama de difusión de datos es mostrar la relación entre la entidad de datos, el servicio comercial y los
componentes de la aplicación. El diagrama muestra cómo los componentes de la aplicación deben realizar físicamente las entidades
lógicas. Esto permite realizar un dimensionamiento efectivo y refinar la huella de TI. Además, al asignar valor comercial a los datos,
se puede obtener una indicación de la importancia comercial de los componentes de la aplicación.
Además, el diagrama puede mostrar la replicación de datos y la propiedad de la aplicación de la referencia maestra para datos. En
este caso, puede mostrar dos copias y la relación maestro-copia entre ellas. Este diagrama puede incluir servicios; es decir, los
servicios encapsulan datos y residen en una aplicación, o servicios que residen en una aplicación y acceden a datos encapsulados
dentro de la aplicación.
Diagrama de seguridad de datos
Este diagrama muestra a qué datos acceden qué roles, unidades de organización y aplicaciones.
Puede mostrarse como un diagrama o presentarse como una matriz.
Su finalidad es:
ÿ Demostrar el cumplimiento de las leyes y reglamentos de privacidad de datos
ÿ Mostrar las amenazas a la seguridad que surgen como resultado del acceso
a los datos ÿ Mostrar qué partes ajenas a la organización tienen acceso a los datos ÿ Mostrar
las medidas de seguridad aplicadas al acceso a los datos

Diagrama de migración de datos
Este diagrama muestra cómo se extraen los datos de la(s) ubicación(es) de referencia o de origen y cómo se cargan en la(s)
ubicación(es) de destino. Puede mostrar dónde se transforman y/o limpian los datos en el camino. En la Fase C del ADM,
es probable que el diagrama se encuentre en un nivel general. Posteriormente, puede elaborarse para mostrar qué elementos
de datos de origen se corresponden con qué elementos de datos de destino.
Diagrama del ciclo de vida de
los datos El diagrama del ciclo de vida de los datos es una parte esencial de la gestión de datos empresariales a lo largo de
su ciclo de vida, desde la concepción hasta la eliminación dentro de las limitaciones del proceso empresarial.
Los datos se consideran una entidad por derecho propio, desvinculada del proceso y la actividad comercial. Cada cambio
de estado se representa en el diagrama que puede incluir el evento o las reglas que activan ese cambio de estado.
La separación de los datos del proceso permite identificar los requisitos de datos comunes, lo que permite compartir los
recursos de manera más eficaz.
3.6.5 Fase C: Arquitectura de la aplicación

A continuación se describen catálogos, matrices y diagramas que se pueden crear dentro de la Fase C (Arquitectura de
aplicaciones) como se describe en el Estándar TOGAF: Método de desarrollo de arquitectura.
Catálogo de cartera de aplicaciones
El propósito de este catálogo es identificar y mantener una lista de todas las aplicaciones en la empresa. Esta lista ayuda a
definir el alcance horizontal de las iniciativas de cambio que pueden afectar tipos particulares de aplicaciones. Una cartera
de aplicaciones acordada permite definir y gobernar un conjunto estándar de aplicaciones.
El catálogo de Application Portfolio proporciona una base sobre la cual basar las matrices y diagramas restantes. Por lo
general, es el punto de inicio de la fase de arquitectura de la aplicación.
El catálogo de Application Portfolio contiene las siguientes entidades de metamodelo:
ÿ Servicio de aplicación ÿ
Componente de aplicación lógica ÿ
Componente de aplicación física
Catálogo de interfaces
El propósito del catálogo de interfaces es abarcar y documentar las interfaces entre aplicaciones para permitir que las
dependencias generales entre aplicaciones se evalúen lo antes posible.
Las aplicaciones crearán, leerán, actualizarán y eliminarán datos dentro de otras aplicaciones; esto se logrará mediante
algún tipo de interfaz, ya sea a través de un archivo por lotes que se carga periódicamente, una conexión directa a la base
de datos de otra aplicación, oa través de alguna forma de API o servicio web.
El mapeo de la relación de entidad Componente de aplicación-Componente de aplicación es un paso importante, ya que

permite que ocurra lo siguiente:

redistribución
ÿ Comprender el grado de interacción entre aplicaciones, identificando aquellas que son centrales en términos de sus
dependencias en otras aplicaciones
ÿ Comprender la cantidad y los tipos de interfaces entre aplicaciones ÿ Comprender el grado
de duplicación de interfaces entre aplicaciones ÿ Identificar el potencial de simplificación de las
interfaces al considerar la aplicación de destino

portafolio

El catálogo de interfaz contiene las siguientes entidades de metamodelo:
ÿ Componente de aplicación lógica ÿ
Componente de aplicación física
ÿ La aplicación se comunica con la relación de la aplicación
Matriz de aplicación/organización
El propósito de esta matriz es representar la relación entre las aplicaciones y las unidades organizacionales dentro de la empresa.
Las operaciones comerciales son realizadas por unidades organizacionales. Algunas de las operaciones y servicios realizados
por esas unidades organizacionales serán respaldadas por aplicaciones. El mapeo de la relación entre el componente de la
aplicación y la unidad organizativa es un paso importante, ya que permite que ocurra lo siguiente:
ÿ Asignar el uso de aplicaciones a las unidades de la organización que realizan operaciones comerciales ÿ Comprender
los requisitos de soporte de aplicaciones de los servicios y procesos comerciales

llevado a cabo por una unidad de organización

ÿ Definir el conjunto de aplicaciones utilizado por una unidad de organización particular
La matriz de aplicación/organización es una tabla bidimensional con el componente de aplicación lógica/física en un eje y la
unidad de organización en el otro eje.
La relación entre estas dos entidades es un compuesto de una serie de relaciones de metamodelo que necesitan validación:
ÿ Servicios propios de las unidades
organizativas ÿ Los actores que pertenecen a las unidades organizativas
utilizan los servicios ÿ Los componentes lógicos/físicos de la aplicación realizan los servicios

Matriz de roles/aplicaciones
El propósito de la matriz de roles/aplicaciones es representar la relación entre las aplicaciones y los roles comerciales
que las usan dentro de la empresa.
Las personas de una organización interactúan con las aplicaciones. Durante esta interacción, estas personas asumen
un rol específico para realizar la tarea; por ejemplo, comprador del producto.
El mapeo de la relación Componente de aplicación-Rol es un paso importante ya que permite que ocurra lo siguiente:
ÿ Asignar el uso de las aplicaciones a los roles específicos de la organización ÿ
Comprender los requisitos de seguridad de las aplicaciones de los servicios y procesos comerciales
apoyar la función y verificar que estén en línea con la política actual

ÿ Definir el conjunto de aplicaciones utilizado por un rol comercial particular; esencial en cualquier cambio de rol
computación basada
La matriz Rol/Aplicación es una tabla bidimensional con Componente de aplicación lógica en un eje y Rol en el otro eje.
Matriz de aplicación/función
El propósito de la matriz Aplicación/Función es representar la relación entre las aplicaciones y las funciones comerciales
dentro de la empresa.
Las funciones comerciales son realizadas por unidades organizacionales. Algunas de las funciones y servicios
comerciales serán compatibles con las aplicaciones. El mapeo de la relación Función-Componente de la Aplicación es
un paso importante ya que permite que ocurra lo siguiente:
ÿ Asignar el uso de las aplicaciones a las funciones comerciales que son compatibles con ellas. ÿ
Comprender los requisitos de soporte de aplicaciones de los servicios y procesos comerciales.

llevado a cabo

ÿ Definir el conjunto de aplicaciones utilizado por una función comercial particular
La matriz de aplicación/función es una tabla bidimensional con el componente de aplicación lógica en un eje y la función
en el otro eje.
La relación entre estas dos entidades es un compuesto de una serie de relaciones de metamodelo que necesitan
validación:
ÿ La función está limitada por el servicio ÿ
Los servicios se realizan mediante componentes de aplicaciones lógicas/físicas

redistribución
Matriz de interacción de aplicaciones
El propósito de la matriz de interacción de aplicaciones es representar las relaciones de comunicación entre aplicaciones.
El mapeo de las interacciones de la aplicación muestra en matriz para m el equivalente del catálogo de interfaz o un
diagrama de comunicación de la aplicación.
La matriz de interacción de la aplicación es una tabla bidimensional con el servicio de la aplicación, el componente de
la aplicación lógica y el componente de la aplicación física tanto en las filas como en las columnas de la tabla.
Las relaciones representadas por esta matriz incluyen:
ÿ El servicio de aplicación consume el servicio de aplicación ÿ El
componente de aplicación lógica se comunica con el componente de aplicación lógica ÿ El componente
de aplicación física se comunica con el componente de aplicación física
Diagrama de comunicación de la aplicación
El propósito del diagrama de comunicación de aplicaciones es representar todos los modelos y asignaciones
relacionadas con la comunicación entre aplicaciones en la entidad del metamodelo.
Muestra los componentes de la aplicación y las interfaces entre los componentes. Las interfaces pueden asociarse con
entidades de datos cuando corresponda. Las aplicaciones se pueden asociar con servicios comerciales cuando
corresponda. La comunicación debe ser lógica y solo debe mostrar la tecnología intermedia cuando sea
arquitectónicamente relevante.
Diagrama de ubicación de aplicaciones y usuarios
El diagrama de ubicación de aplicaciones y usuarios muestra la distribución geográfica de las aplicaciones.

Se puede utilizar para mostrar dónde utiliza las aplicaciones el usuario final; la distribución de dónde se ejecuta y/o
entrega la aplicación host en escenarios de cliente ligero; la distribución de dónde se desarrollan, prueban y lanzan las
aplicaciones; etc.
El análisis puede revelar oportunidades para la racionalización, así como duplicaciones y/o lagunas.
El propósito de este diagrama es representar claramente las ubicaciones comerciales desde las cuales los usuarios
comerciales suelen interactuar con las aplicaciones, pero también la ubicación de alojamiento de la infraestructura de la
aplicación.
El diagrama permite:
ÿ Identificación de la cantidad de instancias de paquetes necesarias para brindar soporte suficiente al usuario
población que puede estar dispersa geográficamente
ÿ Estimación del número y tipo de licencias de usuario para el paquete u otro software ÿ Estimación del
nivel de soporte necesario para los usuarios y la ubicación del soporte

centro
ÿ Selección de las herramientas de gestión del sistema, la estructura y el sistema de gestión necesarios para
apoyar a los usuarios/clientes/socios de la empresa tanto local como remotamente
ÿ Planificación adecuada de los componentes tecnológicos del negocio, a saber, servidor

dimensionamiento y ancho de banda de la red, etc.

ÿ Consideraciones de rendimiento al implementar la arquitectura de aplicaciones y tecnología

soluciones
Los usuarios normalmente interactúan con las aplicaciones en una variedad de formas; por ejemplo:
ÿ Para respaldar las operaciones del día a día del negocio ÿ Para participar
en la ejecución de un proceso de negocios ÿ Para acceder a la información
(buscar, leer)
ÿ Para desarrollar la aplicación
ÿ Para administrar y mantener la aplicación
Diagrama de casos de uso de aplicaciones
Un diagrama de casos de uso de aplicaciones muestra las relaciones entre consumidores y proveedores de servicios de aplicaciones.
Los servicios de aplicaciones son consumidos por actores u otros servicios de aplicaciones, y el diagrama de casos de uso de la
aplicación proporciona una mayor riqueza en la descripción de la funcionalidad de la aplicación al ilustrar cómo y cuándo se usa esa
funcionalidad.
El propósito del diagrama de casos de uso de la aplicación es ayudar a describir y validar la interacción entre los actores y sus roles
con las aplicaciones. A medida que avanza la arquitectura, el caso de uso puede evolucionar desde información funcional para incluir
detalles de realización técnica.
Los casos de uso de aplicaciones también se pueden reutilizar en trabajos de diseño de sistemas más detallados.
Diagrama de capacidad de gestión empresarial
El diagrama Enterprise Manageability muestra cómo una o más aplicaciones interactúan con los componentes de aplicación y
tecnología que respaldan la gestión operativa de una solución.
Este diagrama es realmente un filtro en el diagrama de comunicación de aplicaciones, específicamente para el software de clase de
gestión empresarial.
El análisis puede revelar duplicaciones, brechas y oportunidades en la operación de gestión de servicios de TI de una organización.
Diagrama de realización de procesos/aplicaciones El
propósito del diagrama de realización de procesos/aplicaciones es representar claramente la secuencia de eventos cuando múltiples
aplicaciones están involucradas en la ejecución de un proceso de negocios.
Mejora el diagrama de comunicación de la aplicación al aumentarlo con cualquier restricción de secuencia y puntos de transferencia
entre el procesamiento por lotes y en tiempo real.
Identificaría secuencias complejas que podrían simplificarse e identificaría posibles puntos de racionalización en la arquitectura para
proporcionar información más oportuna a los usuarios comerciales. También puede identificar mejoras en la eficiencia del proceso que
pueden reducir el tráfico de interacción entre aplicaciones.

Diagrama de ingeniería de software El
diagrama de ingeniería de software divide las aplicaciones en paquetes, módulos, servicios y operaciones desde una
perspectiva de desarrollo.
Permite un análisis de impacto más detallado al planificar las etapas de migración y analizar oportunidades y soluciones.
Es ideal para equipos de desarrollo de aplicaciones y equipos de gestión de aplicaciones cuando gestionan entornos
de desarrollo complejos.
Diagrama de migración de aplicaciones
El diagrama de migración de aplicaciones identifica la migración de aplicaciones desde la línea de base hasta los
componentes de la aplicación de destino. Permite una estimación más precisa de los costos de migración al mostrar
con precisión qué aplicaciones e interfaces deben mapearse entre las etapas de migración.
Identificaría las aplicaciones temporales, las áreas de preparación y la infraestructura necesaria para admitir las
migraciones (por ejemplo, entornos de ejecución en paralelo, etc.).
Diagrama de distribución de software
El diagrama de distribución de software muestra cómo se estructura y distribuye el software de aplicación en todo el
estado. Es útil en proyectos de actualización de sistemas o consolidación de aplicaciones.
Este diagrama muestra cómo se distribuyen las aplicaciones físicas en la tecnología física y la ubicación de esa
tecnología.
Esto permite una visión clara de cómo se aloja el software, pero también permite que el personal de operaciones
administradas comprenda cómo se mantiene el software de la aplicación una vez instalado.
3.6.6 Fase D: Arquitectura tecnológica

La siguiente sección describe catálogos, matrices y diagramas que se pueden crear dentro de la Fase D (Arquitectura
tecnológica) como se describe en el Estándar TOGAF: Método de desarrollo de arquitectura.
Catálogo de estándares tecnológicos
El catálogo de estándares tecnológicos documenta los estándares acordados para la tecnología en toda la empresa y
cubre tecnologías y versiones, los ciclos de vida de la tecnología y los ciclos de actualización de la tecnología.
Dependiendo de la organización, esto también puede incluir información sobre estándares específicos de la ubicación
o del dominio comercial.
Este catálogo proporciona una instantánea de las tecnologías estándar de la empresa que se implementan o se pueden
implementar, y también ayuda a identificar las discrepancias en la empresa.
El catálogo de estándares tecnológicos contiene las siguientes entidades de metamodelo:
ÿ Servicio de tecnología ÿ
Componente de tecnología lógica

ÿ Componente de tecnología física
Si actualmente existen estándares tecnológicos, aplíquelos al catálogo de Portafolio de tecnología para obtener una
visión de referencia del cumplimiento de los estándares tecnológicos.
Catálogo de cartera de tecnología
El propósito de este catálogo es identificar y mantener una lista de toda la tecnología en uso en la empresa, incluido el
hardware, el software de infraestructura y el software de aplicación. Una cartera de tecnología acordada respalda la
gestión del ciclo de vida de los productos y versiones de tecnología y también constituye la base para la definición de
estándares tecnológicos.
El catálogo de Portafolio de tecnología proporciona una base sobre la cual basar las matrices y diagramas restantes.
Suele ser el punto de inicio de la fase de Arquitectura Tecnológica.
Los registros y repositorios de tecnología también brindan información a este catálogo desde una perspectiva de línea
de base y objetivo.
Las tecnologías en el catálogo deben clasificarse según la taxonomía definida en uso en la empresa, como TOGAF
TRM; consulte la Guía de la serie TOGAF® : El modelo de referencia técnica (TRM) TOGAF®, adaptado según sea
necesario para ajustarse a la clasificación de productos tecnológicos en uso.
El catálogo de Portafolio de tecnología contiene las siguientes entidades de metamodelo:
ÿ Servicio de tecnología ÿ
Componente de tecnología lógica ÿ
Componente de tecnología física
Matriz de aplicación/tecnología
La matriz de aplicaciones/tecnología documenta el mapeo de aplicaciones a la plataforma tecnológica.
Esta matriz debe alinearse y complementar uno o más diagramas de descomposición de plataformas.
La matriz de aplicación/tecnología muestra:
ÿ Componentes de aplicación lógicos/físicos ÿ
Servicios, componentes de tecnología lógica y componentes de tecnología física ÿ El componente de
tecnología física realiza relaciones de componente de aplicación física
Diagrama de entornos y ubicaciones
El diagrama de entornos y ubicaciones muestra qué ubicaciones alojan qué aplicaciones, identifica qué tecnologías y/o
aplicaciones se utilizan en qué ubicaciones y, por último, identifica las ubicaciones desde las que los usuarios
comerciales suelen interactuar con las aplicaciones.
Este diagrama también debe mostrar la existencia y la ubicación de diferentes entornos de implementación, incluidos
los entornos que no son de producción, como el desarrollo y la preproducción.

redistribución
Diagrama de descomposición de la
plataforma El diagrama de descomposición de la plataforma describe la plataforma de tecnología que admite las operaciones
de la arquitectura de sistemas de información. El diagrama cubre todos los aspectos de la plataforma de infraestructura y
proporciona una descripción general de la plataforma tecnológica de la empresa. El diagrama se puede expandir para mapear
la plataforma tecnológica a los componentes de aplicación apropiados dentro de un área funcional o de proceso específica.
Este diagrama puede mostrar detalles de especificaciones, como versiones de productos, número de CPU, etc. o simplemente
podría ser un "gráfico visual" informal que proporciona una descripción general del entorno técnico.
El diagrama debe mostrar claramente las aplicaciones empresariales. La plataforma tecnológica para cada área de aplicación
se puede descomponer de la siguiente manera:
ÿ Hardware:
— Componentes de tecnología lógica (con atributos)
— Componentes de tecnología física (con atributos)
ÿ Software:
— Componentes de tecnología lógica (con atributos)
— Componentes de tecnología física (con atributos)
Dependiendo del alcance del trabajo de arquitectura empresarial, se puede abordar información adicional de tecnología
cruzada (por ejemplo, comunicaciones, telecomunicaciones e información de video).
Diagrama de procesamiento
El diagrama de procesamiento se centra en las unidades de código/configuración implementables y cómo se implementan en

la plataforma tecnológica. Una unidad de implementación representa la agrupación de componentes de aplicación, servicio o
capacidad comercial. El diagrama de procesamiento aborda lo siguiente:
ÿ Qué conjunto de componentes de la aplicación deben agruparse para formar una unidad de implementación
ÿ Cómo una unidad de implementación se conecta/interactúa con otra (LAN, WAN y la

protocolos)
ÿ Cómo la configuración de la aplicación y los patrones de uso generan requisitos de carga o capacidad
para diferentes componentes tecnológicos
La organización y agrupación de las unidades de implementación depende de las preocupaciones de separación de las capas
de presentación, lógica comercial y almacenamiento de datos y los requisitos de nivel de servicio de los componentes. Por
ejemplo, la unidad de implementación de la capa de presentación se agrupa según lo siguiente:
ÿ Componentes de la aplicación que proporcionan interfaz de usuario o funciones de acceso del
usuario ÿ Componentes de la aplicación que se diferencian por ubicación y roles de usuario
Hay varias consideraciones para determinar cómo se agrupan los componentes de la aplicación. Cada unidad de despliegue
se compone de subunidades, tales como:
ÿ Instalación: parte que contiene el código ejecutable o la configuración del paquete (en caso de
paquetes)
ÿ Ejecución: componente de la aplicación con su estado asociado en tiempo de ejecución

ÿ Persistencia: datos que representan el estado persistente del componente de la aplicación
Finalmente, estas unidades de implementación se implementan en componentes tecnológicos dedicados o compartidos

(estación de trabajo, servidor web, servidor de aplicaciones o servidor de base de datos, etc.). Es importante señalar
que el procesamiento de la tecnología puede influir y tener implicaciones en la definición y granularidad de los servicios.
Computación en red/Diagrama de hardware
Comenzando con la transformación a sistemas cliente-servidor desde mainframes y más tarde con la llegada de e-
Business y J2EE, las grandes empresas se trasladaron predominantemente a un entorno de computación de red
distribuida altamente basado en redes con firewalls y desmilitarizado. zonas
Actualmente, la mayoría de las aplicaciones tienen un front-end web y, al observar la arquitectura de implementación de
estas aplicaciones, es muy común encontrar tres capas distintas en el panorama de la red; a saber, una capa de
presentación web, una capa de aplicación o lógica empresarial y una capa de almacenamiento de datos de back-end.
Es una práctica común que las aplicaciones se implementen y alojen en un entorno de infraestructura común y
compartido.
Por lo tanto, se vuelve sumamente crítico documentar el mapeo entre las aplicaciones lógicas y los componentes
tecnológicos (por ejemplo, el servidor) que respaldan la aplicación tanto en los entornos de desarrollo como de
producción. El propósito de este diagrama es mostrar la vista lógica "tal como se implementó" de los componentes
lógicos de la aplicación en un entorno informático de red distribuida. El diagrama es útil por las siguientes razones:
ÿ Permitir la comprensión de qué aplicación se implementa en qué lugar de la red distribuida k

entorno informático
ÿ Establecer autorización, seguridad y acceso a estos componentes tecnológicos
ÿ Comprender la arquitectura tecnológica que soporta las aplicaciones durante la resolución de problemas.
resolución y resolución de problemas
ÿ Aislar los problemas de rendimiento que encuentran las aplicaciones, determinar si están relacionados con el
código de la aplicación o con la plataforma tecnológica, y realizar la actualización necesaria a componentes de
tecnología física específicos.
ÿ Identificar áreas de optimización a medida que se disponga de tecnologías más nuevas que eventualmente
reducirán los costos
ÿ Habilite la auditoría de aplicaciones/tecnología y demuestre el cumplimiento con la tecnología empresarial

normas
ÿ Servir como una herramienta importante para introducir cambios en la Arquitectura Tecnológica, apoyando así la
gestión eficaz del cambio.
ÿ Establecer trazabilidad y cambiar la dirección del punto final de la aplicación mientras se mueve la aplicación
ya sea de un entorno compartido a un entorno dedicado o viceversa
El alcance del diagrama se puede definir adecuadamente para cubrir una aplicación específica, una función comercial
o toda la empresa. Si se elige desarrollarlo a nivel empresarial, entonces el panorama de la computación en red también
se puede representar de una manera independiente de la aplicación.

redistribución
Diagrama de red y comunicaciones El diagrama de
red y comunicaciones describe los medios de comunicación (el método de envío y recepción de información) entre estos activos
en la arquitectura tecnológica; en la medida en que la selección de paquetes de soluciones en las arquitecturas anteriores impone
requisitos específicos a las comunicaciones entre las aplicaciones.
El diagrama de red y comunicaciones tomará las conexiones lógicas entre los componentes del cliente y el servidor e identificará
los límites de la red y la infraestructura de la red necesaria para implementar físicamente esas conexiones. No describe el formato
o el contenido de la información, pero abordará cuestiones de protocolo y capacidad.
3.6.7 Fase E: Oportunidades y Soluciones

La siguiente sección describe catálogos, matrices y diagramas que se pueden crear dentro de la Fase E (Oportunidades y
soluciones) como se describe en el Estándar TOGAF: Método de desarrollo de arquitectura.
Diagrama de contexto del proyecto
Un diagrama de contexto del proyecto muestra el alcance de un paquete de trabajo que se implementará como parte de una hoja
de ruta de transformación más amplia. El diagrama de contexto del proyecto vincula un paquete de trabajo a las organizaciones,
funciones, servicios, procesos, aplicaciones, datos y tecnología que se agregarán, eliminarán o afectarán por el proyecto.
El diagrama de contexto del proyecto también es una herramienta valiosa para la gestión de la cartera de proyectos y la
movilización de proyectos.
Diagrama de beneficios
El diagrama de beneficios muestra oportunidades identificadas en una definición de arquitectura, clasificadas según su tamaño
relativo, beneficio y complejidad. Este diagrama puede ser utilizado por las partes interesadas para tomar decisiones de selección,
priorización y secuenciación sobre las oportunidades identificadas.
3.6.8 Gestión de requisitos

La siguiente sección describe catálogos, matrices y diagramas que pueden crearse dentro de la fase de Gestión de requisitos
como se describe en el Estándar TOGAF: Método de desarrollo de arquitectura.
Catálogo de Requerimientos
El catálogo de requisitos captura las cosas que la empresa debe hacer para cumplir sus objetivos.
Los requisitos generados a partir de compromisos de arquitectura generalmente se implementan a través de iniciativas de cambio
identificadas y analizadas durante la Fase E (Oportunidades y Soluciones).
Los requisitos también se pueden utilizar como una herramienta de garantía de calidad para garantizar que una arquitectura en
particular sea adecuada para el propósito (es decir, la arquitectura puede cumplir con todos los requisitos identificados).
El catálogo de requisitos contiene las siguientes entidades de metamodelo:

ÿ Requisito
ÿ Suposición
ÿ Restricción
ÿ brecha

redistribución
Capítulo 4: Entregables de la arquitectura
Este capítulo proporciona descripciones de los entregables a los que se hace referencia en el ADM.
4.1 Introducción
Este capítulo define los entregables que normalmente se consumirán y producirán en todo el
Ciclo TOGAF ADM. Como los entregables son típicamente los productos de trabajo formales o contractuales de un
proyecto de arquitectura, es probable que estos entregables se vean limitados o alterados por cualquier
gestión global de proyectos o procesos para la empresa (como CMMI®, PRINCE2®,
PMBOK® o MSP®).
Por lo tanto, este capítulo pretende proporcionar una línea de base típica de los entregables de la arquitectura en
para definir mejor las actividades requeridas en el ADM y actuar como punto de partida para la adaptación
dentro de una organización específica.
El marco de contenido TOGAF (consulte el Capítulo 1) identifica los entregables que se producen como
salidas de ejecutar el ciclo ADM y potencialmente consumidas como entradas en otros puntos en el
ADM. Otros entregables pueden ser producidos en otro lugar y consumidos por el ADM.
Los entregables producidos mediante la ejecución del ADM se muestran en la siguiente tabla.
Entregable Salida de... Entrada a...

Bloques de construcción de arquitectura F,H ABCDE
(consulte la Sección 4.2.1)
Contrato de Arquitectura GRAMO
G, H
(ver Sección 4.2.2)
Documento de definición de arquitectura A, B, C, D, E, F (consulte B, C, D, E, F, G, H
la Sección 4.2.3)
Principios de arquitectura Preliminar, Preliminar y,
(consulte la Sección 4.2.4) ABCD A, B, C, D, E, F, G, H
Repositorio de Arquitectura preliminar Preliminar y,
(ver Sección 4.2.5) A, B, C, D, E, F, G, H,
Gestión de requerimientos
Requisitos de arquitectura B, C, D, E, F, C, D,
Especificación (consulte la Sección 4.2.6) Gestión de requisitos Gestión de requisitos
Hoja de ruta de arquitectura B, C, D, E, FB, C, D, E, F
Visión de la Arquitectura A, E B, C, D, E, F, G, H,
(ver Sección 4.2.8) Gestión de requerimientos
Principios comerciales, objetivos Preliminar y, A,B un, b
comerciales y motores comerciales

Introducción Entregables de arquitectura
Entregable Salida de... Entrada a...

Evaluación de la capacidad A, E B, C, D, E, F
F, G, H —
Solicitud de cambio
Plan de Comunicaciones A B, C, D, E, F
Evaluación de Cumplimiento (ver GRAMO H
Sección 4.2.13)
Plan de Implementación y Migración E, F (ver Sección F
4.2.14)
Modelo F de Gobernanza de Implementación (ver G, H
Sección 4.2.15)
Modelo Organizacional para la Arquitectura Preliminar Preliminar y,
Empresarial (ver Sección 4.2.16) A, B, C, D, E, F, G, H,
Solicitud de Trabajo de Arquitectura (ver Preliminar y, F,H A, G
Sección 4.2.17)
Evaluación del impacto de los requisitos Gestión de requisitos Gestión de requisitos
Elementos básicos de la solución GRAMO
A, B, C, D, E, F, G
Declaración de Trabajo de Arquitectura A, B, C, D, E, F, G, H B, C, D, E, F, G, H,
(ver Sección 4.2.20) Gestión de requerimientos
Marco de arquitectura a medida Preliminar y,A (consulte la Sección Preliminar y,
4.2.21) A, B, C, D, E, F, G, H,
4.2 Descripciones de los Entregables

Las siguientes secciones proporcionan descripciones de ejemplo de entregables a los que se hace referencia en el ADM.
Tenga en cuenta que no es necesario que todo el contenido descrito aquí esté incluido en un entregable en particular.
Más bien, se recomienda que se utilicen referencias externas cuando sea posible; por ejemplo, el
Los planes estratégicos de una empresa no deben copiarse en una Solicitud de trabajo de arquitectura, pero
más bien se debe hacer referencia al título de los planes estratégicos.
Además, no se sugiere que estas descripciones deban seguirse al pie de la letra. Sin embargo, cada
elemento debe ser considerado cuidadosamente; ignorar cualquier elemento de entrada o salida puede causar problemas
río abajo.

Entregables de arquitectura Descripciones de entregables
4.2.1 Bloques de construcción de la arquitectura
Documentación y modelos de arquitectura del Repositorio de Arquitectura de la empresa; véase el Capítulo 5.
4.2.2 Contrato de Arquitectura
Objetivo
Los contratos de arquitectura son los acuerdos conjuntos entre los socios de desarrollo y los patrocinadores sobre los
entregables, la calidad y la idoneidad para el propósito de una arquitectura. La implementación exitosa de estos acuerdos se
logrará a través de una Gobernanza de la Arquitectura efectiva (ver el Estándar TOGAF — Capacidad y Gobernanza de la
Arquitectura Empresarial). Al implementar un enfoque gobernado para la gestión de contratos, se garantizará lo siguiente:
ÿ Un sistema de monitoreo continuo para verificar la integridad, los cambios, la toma de decisiones y la auditoría de todas
las actividades relacionadas con la arquitectura dentro de la organización
ÿ Cumplimiento de los principios, estándares y requisitos de las organizaciones existentes o en desarrollo.

arquitecturas
ÿ Identificación de riesgos en todos los aspectos del desarrollo e implementación de la(s) arquitectura(s) que cubre el
desarrollo interno frente a los estándares, políticas, tecnologías y productos aceptados, así como los aspectos
operativos de las arquitecturas, de modo que la organización pueda continuar su negocio dentro de un entorno
resiliente
ÿ Un conjunto de procesos y prácticas que aseguran la rendición de cuentas, la responsabilidad y la disciplina con
respecto al desarrollo y uso de todos los artefactos arquitectónicos.
ÿ Una comprensión formal de la organización de gobierno responsable del contrato, su nivel de autoridad y el alcance de
la arquitectura bajo el gobierno de este organismo
Contenido
Los contenidos típicos de un Contrato de Diseño y Desarrollo de Arquitectura son:
ÿ Introducción y antecedentes
ÿ La naturaleza del acuerdo ÿ Alcance
de la arquitectura
ÿ Arquitectura y principios y requisitos estratégicos
ÿ Requisitos de conformidad
ÿ Proceso y funciones de gestión y desarrollo de la arquitectura
ÿ Medidas de la arquitectura de destino
ÿ Fases definidas de entregables
ÿ Plan de trabajo conjunto priorizado
ÿ Ventana(s) de tiempo
ÿ Entrega de arquitectura y métricas comerciales
TOGAF® Standard — Arquitectura sesenta y cinco

Descripciones de entregables Entregables de arquitectura
Los contenidos típicos de un contrato de arquitectura de usuarios comerciales son:
ÿ Introducción y antecedentes
ÿ La naturaleza del acuerdo ÿ Alcance ÿ
Requisitos estratégicos ÿ Requisitos de
conformidad
ÿ adoptantes de la arquitectura
ÿ Ventana de tiempo
ÿ Arquitectura de métricas comerciales
ÿ Arquitectura de servicio (incluye acuerdo de nivel de servicio (SLA))
Para obtener más detalles sobre el uso de los contratos de arquitectura, consulte el estándar TOGAF: capacidad y gobernanza
de la arquitectura empresarial.
4.2.3 Documento de definición de arquitectura
Objetivo
El documento de definición de arquitectura es el contenedor de entrega de los artefactos arquitectónicos centrales creados
durante un proyecto y de información importante relacionada. El Documento de definición de la arquitectura abarca todos los
dominios de la arquitectura (Negocios, Datos, Aplicaciones y Tecnología) y también examina todos los estados relevantes de la
arquitectura (Línea base, Transición y Destino).
Una arquitectura de transición muestra la empresa en un estado arquitectónicamente significativo entre las arquitecturas de
referencia y de destino. Las arquitecturas de transición se utilizan para describir las arquitecturas de destino de transición
necesarias para la realización efectiva de la arquitectura de destino.
El Documento de Definición de Arquitectura es un complemento de la Especificación de Requisitos de Arquitectura, con un

objetivo complementario:
ÿ El Documento de definición de arquitectura proporciona una visión cualitativa de la solución y pretende comunicar la
intención de los arquitectos.
ÿ La especificación de los requisitos de la arquitectura proporciona una visión cuantitativa de la solución y establece los
criterios medibles que se deben cumplir durante la implementación de la arquitectura.
Contenido
Los contenidos típicos de un Documento de Definición de Arquitectura son:
ÿ Alcance
ÿ Metas, objetivos y limitaciones
ÿ Principios de arquitectura
ÿ Arquitectura de referencia

ÿ Modelos de arquitectura (para cada estado a modelar):
— Modelos de arquitectura empresarial
— Modelos de arquitectura de datos
— Modelos de arquitectura de aplicaciones
— Modelos de Arquitectura Tecnológica
ÿ Fundamento y justificación del enfoque arquitectónico
ÿ Asignación al repositorio de arquitectura:
— Mapeo al Paisaje Arquitectónico
— Mapeo a modelos de referencia
— Mapeo a estándares
— Evaluación de la reutilización
ÿ Análisis de brechas
ÿ Evaluación de impacto
ÿ Arquitectura de transición:
— Definición de estados de transición
— Arquitectura empresarial para cada estado de transición
— Arquitectura de datos para cada estado de transición
— Arquitectura de aplicación para cada estado de transición
— Arquitectura tecnológica para cada estado de transición
4.2.4 Principios de arquitectura

Objetivo
Los principios son reglas y directrices generales, destinadas a ser duraderas y rara vez modificadas, que informan y respaldan la
forma en que una organización emprende el cumplimiento de su misión.
A su vez, los principios pueden ser solo un elemento en un conjunto estructurado de ideas que colectivamente definen y guían a la
organización, desde los valores hasta las acciones y los resultados.
Contenido
Consulte el Estándar TOGAF - Técnicas ADM para obtener pautas y un conjunto detallado de normas genéricas.
Principios de Arquitectura, incluyendo:
ÿ Principios comerciales (consulte el Estándar TOGAF: Técnicas ADM) ÿ Principios de datos
(consulte el Estándar TOGAF: Técnicas ADM) ÿ Principios de aplicación (consulte el Estándar
TOGAF: Técnicas ADM) ÿ Principios tecnológicos (consulte el Estándar TOGAF: Técnicas ADM)

4.2.5 Repositorio de Arquitectura

Objetivo
El Repositorio de Arquitectura actúa como un área de espera para todos los proyectos relacionados con la arquitectura dentro
de la empresa. El repositorio permite que los proyectos administren sus entregables, ubiquen activos reutilizables y publiquen
resultados para las partes interesadas y otras partes interesadas.
Contenido
Consulte el Capítulo 7 para obtener una descripción detallada del contenido de un repositorio de arquitectura.
4.2.6 Especificación de requisitos de arquitectura

Objetivo
La especificación de requisitos de arquitectura proporciona un conjunto de declaraciones cuantitativas que describen lo que
debe hacer un proyecto de implementación para cumplir con la arquitectura. Una especificación de requisitos de arquitectura
generalmente será un componente principal de un contrato de implementación o un contrato para una definición de
arquitectura más detallada.
Como se ha mencionado más arriba , la especificación de requisitos de arquitectura es un complemento de la

Documento de Definición de Arquitectura, con un objetivo complementario:
ÿ El Documento de Definición de la Arquitectura proporciona una visión cualitativa de la solución y pretende comunicar la
intención del arquitecto.
ÿ La especificación de los requisitos de la arquitectura proporciona una visión cuantitativa de la solución y establece los
criterios medibles que se deben cumplir durante la implementación de la arquitectura.
Contenido
Los contenidos típicos de una especificación de requisitos de arquitectura son:
ÿ Medidas de éxito
ÿ Requisitos de la arquitectura
ÿ Contratos de servicios comerciales
ÿ Contratos de servicio de aplicaciones
ÿ Pautas de implementación
ÿ Especificaciones de implementación
ÿ Estándares de implementación
ÿ Requisitos de interoperabilidad
ÿ Requisitos de gestión de servicios de TI
ÿ Restricciones
ÿ Suposiciones

redistribución
4.2.7 Hoja de ruta de la arquitectura

Objetivo
La hoja de ruta de la arquitectura enumera los paquetes de trabajo individuales que realizarán la arquitectura de destino y
los presenta en una línea de tiempo para mostrar la progresión desde la arquitectura de referencia hasta la arquitectura de
destino. La hoja de ruta de la arquitectura destaca el valor comercial de los paquetes de trabajo individuales en cada etapa.
Las Arquitecturas de Transición necesarias para realizar efectivamente la Arquitectura Objetivo se identifican como pasos
intermedios. El Mapa de ruta de la arquitectura se desarrolla gradualmente a lo largo de las Fases E y F, y se basa en
componentes fácilmente identificables del mapa de ruta de las Fases B, C y D dentro del ADM.
Contenido
Los contenidos típicos de una hoja de ruta de arquitectura son:
ÿ Cartera de paquetes de trabajo:
— Descripción del paquete de trabajo (nombre, descripción, objetivos, entregables)
- Requerimientos funcionales
— Dependencias
— Relación con la oportunidad
— Relación con el documento de definición de la arquitectura y los requisitos de la arquitectura

Especificación
- Valor de negocio
ÿ Catálogo de factores de implementación, que incluye:
— Riesgos
- Problemas
— Suposiciones
— Dependencias
— Acciones
— Entradas
ÿ Matriz consolidada de brechas, soluciones y dependencias, que incluye:
— Dominio de la arquitectura
- Brecha
— Posibles soluciones
— Dependencias
ÿ Cualquier arquitectura de transición
ÿ Recomendaciones de implementación:
— Criterios para medir la eficacia de los proyectos

— Riesgos y problemas
— Bloques de construcción de soluciones
4.2.8 Visión de la Arquitectura
Objetivo
La visión de la arquitectura se crea al principio del ciclo ADM. Proporciona un resumen de los cambios en la empresa que se
derivarán de la implementación exitosa de la arquitectura de destino.
El propósito de Architecture Vision es proporcionar a las partes interesadas clave un resultado formalmente acordado. Un acuerdo
temprano sobre el resultado permite a los arquitectos concentrarse en los detalles necesarios para validar la viabilidad.
Proporcionar una visión de la arquitectura también respalda la comunicación con las partes interesadas al proporcionar una
versión resumida de la definición completa de la arquitectura.
Contenido
Los contenidos típicos de una Visión de Arquitectura son:
ÿ Descripción del problema:
— Las partes interesadas y sus preocupaciones
— Lista de cuestiones/escenarios que deben abordarse
ÿ Objetivo de la Declaración de Trabajo de Arquitectura ÿ Vistas
resumidas necesarias para la Solicitud de Trabajo de Arquitectura y el Anteproyecto de Negocio,

Creación de arquitecturas de datos, aplicaciones y tecnología; típicamente incluyendo:
— Diagrama de cadena de valor
— Diagrama del concepto de solución
ÿ Requisitos mapeados
ÿ Referencia al borrador del documento de definición de arquitectura
4.2.9 Principios comerciales, objetivos comerciales e impulsores comerciales
Objetivo
Los principios comerciales, los objetivos comerciales y los impulsores comerciales brindan un contexto para el trabajo de
arquitectura, al describir las necesidades y formas de trabajo empleadas por la empresa. Sin embargo, muchos factores que se
encuentran fuera de la consideración de la disciplina de la arquitectura pueden tener implicaciones significativas para la forma en
que se desarrolla la arquitectura.
Contenido
Es probable que el contenido y la estructura del contexto empresarial para la arquitectura varíen considerablemente de una
organización a otra.

4.2.10 Evaluación de la capacidad

Objetivo
Antes de embarcarse en una definición detallada de la arquitectura, es valioso comprender el nivel de capacidad objetivo
y de referencia de la empresa. Esta evaluación de la capacidad se puede examinar en varios niveles:
ÿ ¿Cuál es el nivel de capacidad de la empresa en su conjunto? ¿Dónde desea la empresa aumentar u optimizar la
capacidad? ¿Cuáles son las áreas de enfoque arquitectónico que respaldarán el desarrollo deseado de la
empresa?
ÿ ¿Cuál es el nivel de capacidad o madurez de la función de TI dentro de la empresa? ¿Cuáles son las implicaciones
probables de llevar a cabo el proyecto de arquitectura en términos de gobierno del diseño, gobierno operativo,
habilidades y estructura de la organización? ¿Cuál es el estilo, el nivel de formalidad y la cantidad de detalles
apropiados para que el proyecto de arquitectura encaje con la cultura y la capacidad de la organización de TI?
ÿ ¿Cuál es la capacidad y madurez de la función de arquitectura dentro de la empresa? ¿Qué activos arquitectónicos
existen actualmente? ¿Se mantienen y son precisos? ¿Qué estándares y modelos de referencia se deben
considerar? ¿Es probable que haya oportunidades para crear activos reutilizables durante el proyecto de
arquitectura?
ÿ Cuando existan brechas de capacidad, ¿en qué medida está lista la empresa para transformarse a fin de alcanzar
la capacidad objetivo? ¿Cuáles son los riesgos para la transformación, las barreras culturales y otras
consideraciones que deben abordarse más allá de la brecha de capacidad básica?
Contenido
Los contenidos típicos de una evaluación de capacidad son:
ÿ Evaluación de la capacidad empresarial, que incluye:
— Capacidades del negocio
— Evaluación del estado de referencia del nivel de rendimiento de cada capacidad
— Aspiración del estado futuro para el nivel de rendimiento de cada capacidad
— Evaluación del estado de referencia de cómo se realiza cada capacidad
— Aspiración del estado futuro sobre cómo se debe realizar cada capacidad
— Evaluación de los posibles impactos en la organización empresarial derivados de la

despliegue exitoso de la arquitectura de destino
ÿ Evaluación de la capacidad de TI, que incluye:
— Nivel de madurez objetivo y de referencia del proceso de cambio
— Nivel de madurez objetivo y de referencia de los procesos operativos
— Capacidad de referencia y evaluación de la capacidad
— Evaluación de los impactos probables en la organización de TI como resultado de la implementación exitosa

de la arquitectura de destino

ÿ Evaluación de la madurez de la arquitectura, que incluye:
— Procesos, organización, funciones y responsabilidades de Gobernanza de la arquitectura
— Evaluación de habilidades de arquitectura
— Amplitud, profundidad y calidad de la definición del paisaje con el repositorio de arquitectura
— Amplitud, profundidad y calidad de la definición de estándares con el repositorio de arquitectura
— Amplitud, profundidad y calidad de la definición del modelo de referencia con la Arquitectura

Repositorio
— Evaluación del potencial de reutilización
ÿ Evaluación de preparación para la transformación empresarial, que incluye:
— Factores de preparación
— Visión para cada factor de preparación
— Calificaciones de preparación actuales y objetivo
— Riesgos de preparación
4.2.11 Solicitud de cambio

Objetivo
Durante la implementación de una arquitectura, a medida que se conozcan más hechos, es posible que la definición y los requisitos
de la arquitectura original no sean adecuados o no sean suficientes para completar la implementación de una solución. En estas
circunstancias, es necesario que los proyectos de implementación se desvíen del enfoque arquitectónico sugerido o soliciten
extensiones de alcance. Además, los factores externos, como los factores del mercado, los cambios en la estrategia comercial y las
nuevas oportunidades tecnológicas, pueden abrir oportunidades para ampliar y refinar la arquitectura.
En estas circunstancias, se puede enviar una solicitud de cambio para poner en marcha un nuevo ciclo de trabajo de arquitectura.
Contenido
Los contenidos típicos de una solicitud de cambio son: ÿ
Descripción del cambio propuesto ÿ Justificación del
cambio propuesto ÿ Evaluación de impacto del cambio
propuesto, que incluye:
— Referencia a requisitos específicos
— Prioridad de las partes interesadas de los requisitos hasta la fecha
— Fases a revisar
— Fase para liderar la priorización de requisitos
— Resultados de las investigaciones de fase y prioridades revisadas

— Recomendaciones sobre la gestión de requisitos
ÿ Número de referencia del repositorio
4.2.12 Plan de Comunicaciones
Objetivo
Las arquitecturas empresariales contienen grandes volúmenes de información compleja e interdependiente.

La comunicación efectiva de información dirigida a las partes interesadas correctas en el momento correcto es un CSF para
Enterprise Architecture. El desarrollo de un Plan de Comunicaciones para la arquitectura permite que esta comunicación se
lleve a cabo dentro de un proceso planificado y gestionado.
Contenido
Los contenidos típicos de un Plan de Comunicaciones son:
ÿ Identificación de partes interesadas y agrupación por requisitos de comunicación ÿ Identificación
de necesidades de comunicación, mensajes clave en relación con la Visión de la Arquitectura,

riesgos de comunicación y CSF
ÿ Identificación de los mecanismos que se utilizarán para comunicarse con las partes interesadas y permitir el acceso a
la información de la arquitectura, como reuniones, boletines, repositorios, etc.
ÿ Identificación de un cronograma de comunicaciones, que muestre qué comunicaciones se llevarán a cabo

con qué grupos de partes interesadas, en qué momento y en qué lugar
4.2.13 Evaluación del cumplimiento

Objetivo
Una vez que se ha definido una arquitectura, es necesario gobernar esa arquitectura a través de la implementación para
garantizar que la visión de la arquitectura original se realice adecuadamente y que cualquier aprendizaje de implementación
se retroalimente en el proceso de arquitectura. Las revisiones periódicas de cumplimiento de los proyectos de implementación
brindan un mecanismo para revisar el progreso del proyecto y garantizar que el diseño y la implementación avanzan de
acuerdo con los objetivos estratégicos y arquitectónicos.
Contenido
Los contenidos típicos de una evaluación de cumplimiento son:
ÿ Vista general del progreso y estado del proyecto ÿ
Vista general de la arquitectura/diseño del proyecto ÿ
Listas de verificación de arquitectura completas:
— Lista de verificación de hardware y sistema operativo
— Lista de verificación de servicios de software y middleware
— Listas de verificación de aplicaciones

— Listas de verificación de la gestión de la información
— Listas de verificación de seguridad
— Listas de verificación de gestión del sistema
— Listas de verificación de ingeniería de sistemas
— Listas de verificación de métodos y herramientas
4.2.14 Plan de Implementación y Migración

Objetivo
El Plan de Implementación y Migración proporciona un cronograma de los proyectos que realizarán la Arquitectura Objetivo. El Plan de
Implementación y Migración incluye proyectos ejecutables agrupados en carteras y programas gestionados. La Estrategia de
Implementación y Migración que identifica el enfoque del cambio es un elemento clave del Plan de Implementación y Migración.
Contenido
Los contenidos típicos de un Plan de Implementación y Migración son:
ÿ Estrategia de implementación y migración:
— Dirección de implementación estratégica
— Enfoque de secuenciación de la implementación
ÿ Desglose de proyectos y carteras de ejecución:
— Asignación de paquetes de trabajo a proyecto y cartera
— Capacidades entregadas por proyectos
— Hitos y calendario
- Estructura de desglose del trabajo
— Puede incluir el impacto en la cartera, el programa y los proyectos existentes
Puede contener:
ÿ Cartas del proyecto:
— Paquetes de trabajo incluidos
- Valor de negocio
— Riesgo, problemas, suposiciones, dependencias
— Necesidades de recursos y costos
— Beneficios de la migración, determinados (incluido el mapeo a los requisitos comerciales)
— Costos estimados de las opciones de migración

4.2.15 Modelo de Gobernanza de Implementación

Objetivo
Una vez que se ha definido una arquitectura, es necesario planificar cómo se regirá la arquitectura de transición que
implementa la arquitectura a través de la implementación. Dentro de las organizaciones que han establecido funciones de
arquitectura, es probable que ya exista un marco de gobernanza, pero es posible que sea necesario definir procesos,
organizaciones, roles, responsabilidades y medidas específicos proyecto por proyecto.
El Modelo de Gobernanza de Implementación asegura que un proyecto en transición a la implementación también pase
sin problemas a la Gobernanza de Arquitectura adecuada.
Contenido
Los contenidos típicos de un Modelo de Gobernanza de Implementación son:
ÿ Procesos de gobernanza ÿ
Estructura de la organización de la gobernanza
ÿ Funciones y responsabilidades de la gobernanza
ÿ Puntos de control de la gobernanza y criterios de éxito/fracaso
4.2.16 Modelo Organizacional para Arquitectura Empresarial

Objetivo
Para que un marco de arquitectura se utilice con éxito, debe estar respaldado por la organización, las funciones y las
responsabilidades correctas dentro de la empresa. De particular importancia es la definición de los límites entre los
diferentes profesionales de la Arquitectura Empresarial y las relaciones de gobierno que se extienden a través de estos
límites.
Contenido
Los contenidos típicos de un Modelo Organizativo para la Arquitectura Empresarial son:
ÿ Alcance de las organizaciones afectadas
ÿ Evaluación de la madurez, brechas y enfoque de resolución
ÿ Funciones y responsabilidades de los equipos de arquitectura
ÿ Restricciones en el trabajo de arquitectura
ÿ Requisitos presupuestarios
ÿ Gobernanza y estrategia de apoyo

4.2.17 Solicitud de Trabajo de Arquitectura

Objetivo
Este es un documento que se envía desde la organización patrocinadora a la organización de arquitectura para
desencadenar el inicio de un ciclo de desarrollo de arquitectura. Las solicitudes de trabajo de arquitectura se pueden crear
como resultado de la fase preliminar, como resultado de solicitudes de cambio de arquitectura aprobadas o términos de
referencia para el trabajo de arquitectura que se originan a partir de la planificación de la migración.
En general, toda la información en este documento debe ser de alto nivel.
Contenido
Las solicitudes de trabajo de arquitectura suelen incluir:
ÿ Patrocinadores de la
organización ÿ Declaración de la misión de la
organización ÿ Objetivos comerciales (y
cambios) ÿ Planes estratégicos del negocio
ÿ Límites de tiempo
ÿ Cambios en el entorno empresarial ÿ Restricciones
organizativas ÿ Información presupuestaria,
restricciones financieras
ÿ Restricciones externas, restricciones comerciales
ÿ Descripción del sistema comercial actual ÿ
Descripción de la arquitectura/sistema de TI actual ÿ
Descripción de la organización en desarrollo ÿ
Descripción de los recursos disponibles para la organización en desarrollo
4.2.18 Evaluación del impacto de los requisitos

Objetivo
A lo largo de ADM, se recopila nueva información relacionada con una arquitectura. A medida que se recopila esta
información, pueden surgir nuevos hechos que invaliden aspectos existentes de la arquitectura. Una evaluación del impacto
de los requisitos evalúa los requisitos y especificaciones de la arquitectura actual para identificar los cambios que se deben
realizar y las implicaciones de esos cambios.
Contenido
Los contenidos típicos de una Evaluación de Impacto de los Requisitos son:
ÿ Referencia a requisitos específicos ÿ Prioridad
de las partes interesadas de los requisitos hasta la fecha
ÿ Fases a revisar

redistribución
ÿ Fase para liderar la priorización de requisitos
ÿ Resultados de las investigaciones de fase y prioridades revisadas ÿ
Recomendaciones sobre la gestión de requisitos ÿ Número de referencia
del depósito
4.2.19 Bloques de creación de soluciones
Bloques de construcción específicos de la implementación del repositorio de arquitectura de la empresa; véase el Capítulo 5.
4.2.20 Declaración de Trabajo de Arquitectura
Objetivo
La Declaración de trabajo de arquitectura define el alcance y el enfoque que se utilizará para completar un ciclo de desarrollo
de arquitectura. La Declaración de trabajo de arquitectura suele ser el documento contra el cual se medirá la ejecución exitosa
del proyecto de arquitectura y puede formar la base para un acuerdo contractual entre el proveedor y el consumidor de servicios
de arquitectura.
Contenido
Los contenidos típicos de una Declaración de Trabajo de Arquitectura son:
ÿ Título
ÿ Solicitud de proyecto de arquitectura y antecedentes
ÿ Descripción y alcance del proyecto de arquitectura
ÿ Visión general de Architecture Vision
ÿ Procedimientos específicos de cambio de alcance
ÿ Roles, responsabilidades y entregables
ÿ Criterios y procedimientos de aceptación
ÿ Plan y cronograma del proyecto de arquitectura
ÿ Aprobaciones

4.2.21 Marco de arquitectura a la medida
Objetivo
El marco TOGAF proporciona un estándar de la industria para la arquitectura que se puede utilizar en una amplia
variedad de organizaciones. Sin embargo, antes de que el marco TOGAF pueda usarse de manera efectiva dentro de
un proyecto de arquitectura, es necesario adaptarlo a dos niveles.
En primer lugar, es necesario adaptar el modelo TOGAF para la integración en la empresa. Esta adaptación incluirá la
integración con los marcos de gestión, la personalización de la terminología, el desarrollo de estilos de presentación, la
selección, la configuración y el despliegue de herramientas de arquitectura, etc. La formalidad y el detalle de los marcos
adoptados también deben alinearse con otros factores contextuales para la empresa. , como la cultura, las partes
interesadas, los modelos comerciales para la arquitectura empresarial y el nivel existente de capacidad de arquitectura.
Una vez que el marco se ha adaptado a la empresa, se necesita una mayor adaptación para adaptar el marco al
proyecto de arquitectura específico. La adaptación a este nivel seleccionará productos y artefactos apropiados para
satisfacer las necesidades del proyecto y de las partes interesadas.
Consulte el estándar TOGAF: método de desarrollo de arquitectura para obtener más consideraciones al seleccionar y
adaptar el marco de la arquitectura.
Contenido
Los contenidos típicos de un marco de arquitectura a medida son:

ÿ Método de arquitectura a la medida
ÿ Contenido de arquitectura a la medida (productos y artefactos) ÿ
Herramientas configuradas e implementadas ÿ Interfaces con modelos
de gobierno y otros marcos:
— Planificación empresarial corporativa
- Arquitectura empresarial
— Gestión de carteras, programas y proyectos
— Desarrollo/ingeniería de sistemas
— Operaciones (Servicios)

redistribución
Capítulo 5: Bloques de construcción
Este capítulo explica el concepto de bloques de construcción.
5.1 Resumen
Esta sección pretende explicar e ilustrar el concepto de bloques de construcción en arquitectura.
Siguiendo esta descripción general, hay dos partes principales:
ÿ Introducción a Building Blocks (consulte la Sección 5.2), analiza los conceptos generales de
bloques de construcción y explica las diferencias entre ABB y SBB
ÿ Building Blocks y el ADM (consulte la Sección 5.3), resume las etapas en las que se
el diseño y la especificación del bloque ocurren dentro del TOGAF ADM
5.2 Introducción a los bloques de construcción

Esta sección es una introducción al concepto de bloques de construcción.
5.2.1 Resumen
Esta sección describe las características de los bloques de construcción. El uso de bloques de construcción en el ADM se
describe por separado en la Sección 5.3.
5.2.2 Características genéricas
Los bloques de construcción tienen las siguientes características genéricas:
ÿ Un componente básico es un paquete de funcionalidad definido para satisfacer las necesidades comerciales en un
organización
ÿ Un bloque de construcción normalmente tiene un tipo que corresponde al metamodelo (como actor, servicio comercial,
aplicación o entidad de datos)
ÿ Un bloque de construcción tiene un límite definido y es generalmente reconocible como "una cosa" por
expertos en dominio
ÿ Un bloque de construcción puede interoperar con otros bloques de construcción interdependientes.
ÿ Un buen bloque de construcción tiene las siguientes características:
— Considera la implementación y el uso, y evoluciona para explotar la tecnología y

normas

Introducción a los bloques de construcción Bloques de construcción
— Puede ensamblarse a partir de otros bloques de construcción
— Puede ser un subensamblaje de otros bloques de construcción
— Idealmente, un bloque de construcción es reutilizable y reemplazable, y está bien especificado
El límite y la especificación de un bloque de construcción deben acoplarse libremente a su implementación; es decir, debería ser
posible realizar un bloque de construcción de varias maneras diferentes sin afectar el límite o la especificación del bloque de
construcción. La forma en que los activos y las capacidades se ensamblan en bloques de construcción variará ampliamente entre
las arquitecturas individuales. Cada organización debe decidir por sí misma qué arreglo de bloques de construcción funciona
mejor para ella. Una buena elección de componentes básicos puede generar mejoras en la integración, la interoperabilidad y la
flexibilidad de sistemas heredados en la creación de nuevos sistemas y aplicaciones.
Los sistemas se construyen a partir de colecciones de bloques de construcción, por lo que la mayoría de los bloques de
construcción tienen que interoperar con otros bloques de construcción. Siempre que eso sea cierto, es importante que las
interfaces de un bloque de creación estén publicadas y sean razonablemente estables.
Los bloques de construcción se pueden definir en varios niveles de detalle, según la etapa de desarrollo de la arquitectura que se
haya alcanzado.
Por ejemplo, en una etapa inicial, un bloque de construcción puede consistir simplemente en un nombre o una descripción
general. Posteriormente, un bloque de construcción se puede descomponer en varios bloques de construcción de apoyo y puede
ir acompañado de una especificación completa.
El nivel de detalle con el que debe especificarse un bloque de construcción depende de los objetivos de la arquitectura y, en
algunos casos, menos detalle puede ser de mayor valor (por ejemplo, cuando se presentan las capacidades de una empresa, de
forma única, clara y concisa). la imagen tiene más valor que una densa especificación de 100 páginas).
El Object Management Group® (OMG®) ha desarrollado un estándar para la especificación de activos reutilizables (RAS),1 que
proporciona un buen ejemplo de cómo se pueden describir y administrar formalmente los componentes básicos.
5.2.3 Bloques de construcción de la arquitectura

Los Bloques de Construcción de Arquitectura (ABB) se relacionan con el Continuo de Arquitectura (consulte la Sección 6.4.1) y
se definen o seleccionan como resultado de la aplicación del ADM.
5.2.3.1 Características
ABB:
ÿ capturar los requisitos de la arquitectura; por ejemplo, negocios, datos, aplicaciones y tecnología
requisitos
ÿ Dirigir y guiar el desarrollo de los SBB
1. Consulte www.omg.org/spec/RAS.

Bloques de construcción Introducción a los bloques de construcción
5.2.3.2 Contenido de la especificación
Las especificaciones de ABB incluyen lo siguiente como mínimo:
ÿ Funcionalidad y atributos fundamentales: semánticos, inequívocos, incluidas la capacidad de seguridad y la capacidad

de administración.
ÿ Interfaces: conjunto elegido, suministrado
ÿ Interoperabilidad y relación con otros componentes básicos
ÿ Bloques de construcción dependientes con la funcionalidad requerida e interfaces de usuario con nombre
ÿ Asignación a políticas y entidades empresariales/organizacionales
5.2.4 Elementos básicos de la solución

Los Bloques de Construcción de Soluciones (SBB) se relacionan con el Continuo de Soluciones (consulte la Sección 6.4.2)
y pueden adquirirse o desarrollarse.
5.2.4.1 Características
SBB:
ÿ Definir qué productos y componentes implementarán la funcionalidad ÿ Definir la
implementación ÿ Cumplir con los requisitos comerciales
ÿ Conocen el producto o el proveedor
5.2.4.2 Contenido de la especificación
Las especificaciones de SBB incluyen lo siguiente como mínimo:
ÿ Funcionalidad y atributos específicos ÿ
Interfaces; el conjunto implementado ÿ SBB
requeridos utilizados con la funcionalidad requerida y los nombres de las interfaces utilizadas ÿ Asignación
de los SBB a la topología de TI y las políticas operativas ÿ Especificaciones de atributos compartidos en
todo el entorno (que no deben confundirse con la funcionalidad) como seguridad, manejabilidad, localizabilidad,
escalabilidad
ÿ Rendimiento, configurabilidad
ÿ Impulsores y restricciones de diseño, incluida la arquitectura física
ÿ Relaciones entre SBB y ABB
TOGAF® Standard — Arquitectura Contenido 81

© 2005-2022 The Open Group, Todos los derechos reservados Copia
de evaluación. No para redistribución
Los bloques de construcción y el ADM Bloques de construcción
5.3 Bloques de construcción y el ADM

5.3.1 Principios básicos
Esta sección se centra en el uso de bloques de construcción en el ADM. Las consideraciones generales y las características de
los bloques de construcción se describen en la Sección 5.2.
5.3.1.1 Bloques de construcción en el diseño de arquitectura
Una arquitectura es un conjunto de bloques de construcción representados en un modelo arquitectónico y una especificación de
cómo se conectan esos bloques de construcción para cumplir con los requisitos generales del negocio.
Los diversos componentes básicos de una arquitectura especifican el alcance y el enfoque que se utilizará para abordar un
problema comercial específico.
Hay algunos principios generales que subyacen al uso de bloques de construcción en el diseño de arquitecturas específicas:
ÿ Una arquitectura solo necesita contener bloques de construcción que sean relevantes para el problema comercial que la
arquitectura intenta abordar
ÿ Los bloques de construcción pueden tener relaciones complejas entre sí
Un bloque de construcción puede admitir varios bloques de construcción o puede admitir parcialmente un solo bloque de
construcción (por ejemplo, el servicio comercial de "manejo de quejas" sería compatible con muchas entidades de datos y
posiblemente con múltiples componentes de aplicación)
ÿ Los bloques de construcción deben cumplir con los estándares relevantes para su tipo, los principios de la
empresa, y los estándares de la empresa
5.3.1.2 Diseño de bloques de construcción
El proceso de identificar bloques de construcción incluye buscar colecciones de capacidades o activos que interactúen entre sí y
luego unirlos o hacerlos diferentes:
ÿ Considere tres clases de bloques de construcción:
— Bloques de construcción reutilizables, como elementos heredados
— Elementos básicos que serán objeto de desarrollo, como nuevas aplicaciones — Elementos básicos
que serán objeto de compra; es decir, comercial listo para usar (COTS)
aplicaciones
ÿ Usar el nivel deseado de integración para vincular o combinar funciones en bloques de construcción; por ejemplo, los
elementos heredados podrían tratarse como grandes bloques de construcción para evitar separarlos
En las primeras etapas y durante las vistas de la empresa de más alto nivel, los componentes básicos a menudo se mantienen en
una definición de integración amplia. Es durante estos ejercicios que las definiciones de servicios a menudo se pueden ver mejor.
A medida que se abordan las consideraciones de implementación, a menudo se pueden usar vistas más detalladas de los
componentes básicos para abordar las decisiones de implementación, centrarse en las decisiones estratégicas críticas o ayudar a
evaluar el valor y el impacto futuro de la uniformidad y la reutilización.

Bloques de construcción Los bloques de construcción y el ADM
5.3.2 Proceso de especificación de bloques de construcción en el ADM El
proceso de definición de bloques de construcción se lleva a cabo gradualmente a medida que se sigue el ADM,
principalmente en las fases A, B, C y D. Es un proceso evolutivo e iterativo porque a medida que avanza la definición,
la información detallada sobre la funcionalidad requerida, las restricciones impuestas a la arquitectura y la disponibilidad
de productos pueden afectar la elección y el contenido de los componentes básicos.
Las fases y pasos clave del ADM en los que se desarrollan y especifican los componentes básicos se resumen en la
figura 5-1. El trabajo principal en estos pasos consiste en identificar los ABB requeridos para cumplir con las metas y
objetivos comerciales. El conjunto seleccionado de ABB luego se refina en un proceso iterativo para llegar a un conjunto
de SBB que se pueden comprar listos para usar o desarrollarse a medida.
B. Arquitectura empresarial C.
A. Visión de la arquitectura •
Arquitectura de datos/aplicaciones D.
Modelo de alto nivel de componentes básicos candidatos
Arquitectura tecnológica Paso 1: Seleccionar
modelos de referencia, puntos de vista y herramientas Paso 2: Desarrollar una
descripción básica de la arquitectura Modelo de alto nivel de bloques de construcción
•
existentes, reutilizando definiciones del Repositorio de arquitectura donde están
disponibles
Paso 3: Desarrollar la descripción de la arquitectura de destino

•
Desarrollar una vista de los componentes básicos necesarios mediante
UNA.
la creación de catálogos, matrices y diagramas de la arquitectura.
Visión de la
arquitectura •
h Documente completamente cada bloque de construcción
B. •
Arquitectura Justificación del documento para las decisiones de bloques de
Arquitectura construcción en el documento de arquitectura
Cambio
empresarial •
administración Identifique los bloques de construcción afectados, comparándolos con una
biblioteca de bloques de construcción dentro de la Arquitectura
Repositorio y reutilización cuando corresponda
•
Cuando sea necesario, definir nuevos bloques de construcción
•
Seleccione estándares para cada bloque de construcción, reutilizando
C. tanto como sea posible de los modelos de referencia seleccionados de
GRAMO.
Requisitos Arquitecturas Architecture Continuum

Gobernanza de la
administración de Sistemas •
implementación Documentar el mapeo final de los componentes básicos para el
de Información
Arquitectura Paisaje
•
De los bloques de construcción seleccionados, identifique aquellos que
podrían reutilizarse y publíquelos como estándares o modelos de referencia
a través del repositorio de arquitectura.
Paso 4: Realice un análisis de brechas
F. D. •
Identificar los componentes básicos que se han
Planificación Arquitectura trasladado • I dentificar loslos
componentes básicos
Tecnológica eliminados Identificar nuevos componentes
de la migración
•
MI. básicos Identificar las lagunas y determinar el
•
Oportunidades enfoque de realización (p. ej., a desarrollar o a adquirir)
y
Soluciones Paso 5: Definir los componentes candidatos de la hoja de ruta Paso 6:
Resolver los impactos en el paisaje de la arquitectura Paso 7: Revisión formal de las partes
interesadas Paso 8: Finalizar la arquitectura Paso 9: Crear el documento de definición de
la arquitectura
E. Oportunidades y Soluciones • Asociar

brechas de bloques de construcción con paquetes de trabajo que abordarán
los huecos
© El Grupo Abierto
Figura 5-1 Fases/pasos clave de ADM en los que se desarrollan/especifican los componentes básicos

Bloques de construcción

redistribución
Capítulo 6: Empresa continua
6.1 Resumen
Enterprise Continuum proporciona métodos para clasificar la arquitectura y los artefactos de solución, tanto internos
como externos al repositorio de arquitectura, a medida que evolucionan desde arquitecturas básicas genéricas hasta
arquitecturas específicas de la organización.
El Enterprise Continuum le permite al arquitecto articular la perspectiva amplia de qué, por qué y cómo se ha diseñado
la arquitectura empresarial con los factores y los impulsores considerados.
Enterprise Continuum es una ayuda importante para la comunicación y el entendimiento, tanto dentro de empresas
individuales como entre empresas de clientes y organizaciones de proveedores. Sin una comprensión de "en qué parte
del continuo se encuentra", las personas que discuten sobre arquitectura a menudo pueden hablar con propósitos
cruzados porque están haciendo referencia a diferentes puntos en el continuo al mismo tiempo, sin darse cuenta.
Cualquier arquitectura es específica del contexto; por ejemplo, hay arquitecturas que son específicas para clientes,
industrias, subsistemas, productos y servicios individuales. Los arquitectos, tanto del lado de la compra como del lado
de la oferta, deben tener a su disposición un lenguaje consistente para comunicar de manera efectiva las diferencias
entre las arquitecturas. Dicho lenguaje permitirá la eficiencia de la ingeniería y el aprovechamiento efectivo de la
funcionalidad del producto COTS. Enterprise Continuum proporciona ese lenguaje coherente.
Enterprise Continuum permite la organización de artefactos de arquitectura reutilizables y activos de soluciones para
maximizar las oportunidades de inversión de Enterprise Architecture.
6.2 Continuidad empresarial y reutilización de la arquitectura

La forma más sencilla de pensar en Enterprise Continuum es como una vista del depósito de todos los activos de la
arquitectura. Puede contener descripciones de arquitectura, modelos, bloques de construcción, patrones, puntos de
vista de la arquitectura y otros artefactos, que existen tanto dentro de la empresa como en la industria de TI en general,
que la empresa considera tener disponibles para el desarrollo de arquitecturas. para la empresa.
Ejemplos de arquitectura interna y artefactos de solución son los entregables del trabajo de arquitectura anterior, que
están disponibles para su reutilización. Ejemplos de arquitectura externa y artefactos de solución son la amplia variedad
de modelos de referencia de la industria y patrones de arquitectura que existen y surgen continuamente, incluidos
aquellos que son muy genéricos (como TOGAF TRM); los específicos de ciertos aspectos de TI (como una arquitectura
de servicios web o una arquitectura de capacidad de administración genérica); los específicos de determinados tipos de
tratamiento de la información, como el comercio electrónico, la gestión de la cadena de suministro, etc.; y los propios
de determinadas industrias ver ticales, como los modelos generados por consorcios ver ticales como TM For um (en el
sector de Telecomunicaciones), ARTS (Retail), Energistics® (Petrotécnica), etc.

Continuidad empresarial y reutilización de la arquitectura Continuidad empresarial
La arquitectura empresarial determina qué artefactos de arquitectura y solución incluye una organización en su
repositorio de arquitectura. La reutilización es una consideración importante en esta decisión.
6.3 Componentes del continuo empresarial

En la Figura 6-1 se muestra una descripción general del contexto y los constituyentes de Enterprise Continuum .
Los factores externos

proporcionan contexto
Empresa Continuidad empresarial

repositorios
(incluyendo Contexto y requisitos de la arquitectura
Repositorio de requisitos,
repositorio de arquitectura, Factores contextuales
Tiendas de diseño
arquitecturas de forma
y CMDB)
Continuidad de la arquitectura
Enterprise Continuum Generalización para reutilización futura

proporciona estructura y Genérico Específico
clasificación para activos en arquitecturas arquitecturas
Adaptación para el uso
Enterprise Repositories.
Guías y Guías y Guías y Guías y

apoyos apoyos apoyos apoyos
Los repositorios
Generalización para reutilización futura
empresariales proporcionan Genérico Específico
recursos para ser clasificados dentro del Soluciones Soluciones
Adaptación para el uso
Continuidad Empresarial.
Soluciones continuas
Las soluciones se instancian Las soluciones implementadas se convierten

dentro de una implementación Contexto de la arquitectura
Soluciones implementadas
© El Grupo Abierto
Figura 6-1 Entrar premio Continuum
El Enterprise Continuum se divide en tres continuos distintos de la siguiente manera:
ÿ El continuo empresarial (consulte la Sección 6.4) es el continuo más externo y clasifica

activos relacionados con el contexto de la arquitectura empresarial general
Las clases de activos de Enterprise Continuum pueden influir en las arquitecturas, pero no se utilizan directamente
durante el desarrollo de la arquitectura ADM. Enterprise Continuum clasifica los activos contextuales utilizados
para desarrollar arquitecturas, como políticas, estándares, iniciativas estratégicas, estructuras organizacionales
y capacidades a nivel empresarial. El Enterprise Continuum también puede clasificar soluciones (a diferencia de
descripciones o especificaciones de soluciones). Finalmente, Enterprise Continuum contiene dos especializaciones,
a saber, Architecture y Solutions Continua.
ÿ El continuo de la arquitectura (consulte la Sección 6.4.1) ofrece una forma coherente de definir y comprender
las reglas genéricas, las representaciones y las relaciones en una arquitectura, incluidas las relaciones de
trazabilidad y derivación (p. ej., para mostrar que una arquitectura específica de la organización se basa en un
industria o norma genérica)

redistribución
Continuidad empresarial Constituyentes del continuo empresarial
El continuo de arquitectura representa una estructuración de bloques de construcción de arquitectura (ABB) que
son activos de arquitectura reutilizables. Los ABB evolucionan a lo largo de su ciclo de vida de desarrollo desde
entidades abstractas y genéricas hasta activos de arquitectura específicos de la organización completamente
expresados. Los activos del Continuo de Arquitectura se utilizarán para guiar y seleccionar los elementos del
Continuo de Soluciones (ver más abajo). El continuo de la arquitectura muestra las relaciones entre los marcos
fundamentales (como el marco TOGAF), las arquitecturas de sistemas comunes (como el III-RM), las arquitecturas
industriales y las arquitecturas empresariales. El continuo de la arquitectura es una herramienta útil para descubrir
puntos en común y eliminar la redundancia innecesaria.
ÿ El continuo de soluciones (consulte la Sección 6.4.2) proporciona una forma coherente de describir y comprender
la implementación de los activos definidos en el continuo de arquitectura El continuo de soluciones define lo que
está disponible en el entorno organizacional como SBB reutilizables. Las soluciones son el resultado de acuerdos
entre clientes y socios comerciales que implementan las reglas y relaciones definidas en el espacio de la
arquitectura. El continuo de soluciones aborda los puntos en común y las diferencias entre los productos,
sistemas y servicios de los sistemas implementados.
Enterprise Continuum clasifica los activos de arquitectura que son aplicables en todo el alcance de Enterprise
Architecture. Estos activos, a los que se puede hacer referencia como bloques de construcción, pueden representar una
variedad de elementos que colectivamente definen y restringen la arquitectura empresarial. Pueden tomar la forma de
metas y objetivos comerciales, iniciativas estratégicas, capacidades, políticas, estándares y principios.
El Enterprise Continuum también contiene el Architecture Continuum y el Solutions Continuum. Cada uno de estos
continuos se describe con mayor detalle en las siguientes secciones.
6.4 Continuidad empresarial en detalle

El Enterprise Continuum pretende representar la clasificación de todos los activos que están disponibles para una
empresa. Clasifica los activos que existen dentro de la empresa junto con otros activos en el entorno más amplio que
son relevantes para la empresa, como productos, investigación, factores de mercado, factores comerciales, estrategias
comerciales y legislación.
El estándar TOGAF pretende ser un marco para llevar a cabo la arquitectura empresarial y, como resultado, muchos de
los activos que residen dentro de Enterprise Continuum están más allá de la consideración específica del marco TOGAF.
Sin embargo, las arquitecturas están formadas fundamentalmente por preocupaciones fuera de la práctica de la
arquitectura y, por lo tanto, es de suma importancia que cualquier arquitectura debe reflejar con precisión el contexto
externo.
Los factores contextuales específicos que se identificarán e incorporarán en una arquitectura variarán de una arquitectura
a otra. Sin embargo, es probable que los factores contextuales típicos para el desarrollo de la arquitectura incluyan:
ÿ Factores de influencia externos, como cambios regulatorios, avances tecnológicos y

actividad de la competencia
ÿ Estrategia y contexto comercial, incluidas fusiones, adquisiciones y otros requisitos de transformación comercial
ÿ Operaciones comerciales actuales, que reflejan arquitecturas y soluciones implementadas
Al observar el contexto de la arquitectura, se puede ver que la actividad de desarrollo de la arquitectura existe dentro
de un ciclo de vida empresarial más amplio de cambio continuo.

Continuidad empresarial en detalle Continuidad empresarial
Los ABB se definen en relación con un conjunto de factores contextuales y luego se realizan a través de los SBB. Los
SBB se implementan como soluciones activas y se convierten en parte del modelo operativo básico de la empresa. El
modelo operativo de la empresa y la información empírica sobre el desempeño de la empresa da forma al contexto y los
requisitos para el cambio futuro. Finalmente, estos nuevos requisitos para el cambio crean un circuito de retroalimentación
para influir en la creación de nuevas Arquitecturas Objetivo.
6.4.1 Arquitectura continua

El continuo de la arquitectura ilustra cómo se desarrollan y evolucionan las arquitecturas a lo largo de un continuo que
va desde las arquitecturas básicas, como la Guía de la serie TOGAF® : el modelo de referencia técnica (TRM) de
TOGAF® hasta las arquitecturas de sistemas comunes y las arquitecturas industriales, y hasta una arquitectura
empresarial. Arquitecturas específicas de la organización de ise.
Las flechas en el Continuo de la Arquitectura representan la relación que existe entre las diferentes arquitecturas del
Continuo de la Arquitectura. La dirección hacia la izquierda se enfoca en satisfacer las necesidades empresariales y los
requisitos comerciales, mientras que la dirección hacia la derecha se enfoca en aprovechar los componentes
arquitectónicos y los bloques de construcción.
© El Grupo Abierto
Figura 6-2 Arquitectura continua
Las necesidades de la empresa y los requisitos comerciales se abordan con mayor detalle de izquierda a derecha. El
arquitecto normalmente buscará elementos arquitectónicos reutilizables hacia la izquierda del continuo. Cuando no se
encuentran elementos, los requisitos para los elementos que faltan se pasan a la izquierda del continuo para la
incorporación. Aquellos que implementan arquitecturas dentro de sus propias organizaciones pueden usar los mismos
modelos continuos especializados para su negocio.
Los cuatro tipos particulares de arquitectura ilustrados en la Figura 6-2 pretenden indicar el rango de diferentes tipos de
arquitectura que pueden desarrollarse en diferentes puntos del continuo; no son etapas fijas en un proceso.
Muchos tipos diferentes de arquitectura pueden ocurrir en puntos intermedios entre los ilustrados en la Figura 6-2.
Aunque el continuo de transformación evolutiva ilustrado no representa un proceso formal, sí representa una progresión,
que ocurre en varios niveles:
ÿ Lógico a físico

redistribución
Continuidad empresarial Continuidad empresarial en detalle
ÿ De horizontal (enfocado en TI) a ver tical (enfocado en el negocio)
ÿ De generalización a especialización ÿ De taxonomía a
especificación de arquitectura completa y específica
En cada punto del continuo, se diseña una arquitectura en términos de los conceptos de diseño y los bloques de
construcción disponibles y relevantes para ese punto.
Las cuatro arquitecturas ilustradas en la Figura 6-2 representan clasificaciones principales de arquitecturas potenciales
y serán relevantes y familiares para muchos arquitectos. Se analizan en detalle a continuación.
Arquitectura de cimientos
Una arquitectura básica consta de componentes genéricos, interrelaciones, principios y directrices que proporcionan
una base sobre la que se pueden construir arquitecturas más específicas. TOGAF ADM es un proceso que apoyaría la
especialización de dichas Arquitecturas de Fundación para crear modelos específicos de la organización.
El TOGAF TRM es un ejemplo de Arquitectura de Fundación. Es una arquitectura fundamental sobre la que se pueden
basar otras arquitecturas más específicas. Consulte la Guía de la serie TOGAF® : El modelo de referencia técnica
(TRM) de TOGAF® para obtener más detalles.
Arquitecturas de Sistemas Comunes Las
Arquitecturas de Sistemas Comunes guían la selección e integración de servicios específicos de la Arquitectura Básica
para crear una arquitectura útil para construir soluciones comunes (es decir, altamente reutilizables) a través de un
amplio número de dominios relevantes.
Los ejemplos de arquitecturas de sistemas comunes incluyen: una arquitectura de seguridad, una arquitectura de
gestión, una arquitectura de red, una arquitectura de operaciones, etc. king, operaciones, etc.), de modo que las
soluciones que implementan la arquitectura constituyen bloques de construcción reutilizables para la creación de
estados operativos funcionalmente completos de la empresa.
Otras características de las Arquitecturas de Sistemas Comunes incluyen:
ÿ Refleja los requisitos específicos de un dominio de problema genérico ÿ
Define los componentes básicos específicos de un dominio de problema
genérico ÿ Define los estándares de negocio, datos, aplicaciones o tecnología para implementar estos
bloques de construcción
ÿ Proporciona bloques de construcción para una fácil reutilización y costos más bajos
Modelo de referencia de infraestructura de información integrada TOGAF (III-RM): consulte TOGAF®

Guía de la serie: El modelo de referencia de infraestructura de información integrada TOGAF (III-RM) — es un modelo
de referencia que admite la descripción de la arquitectura de sistemas comunes en el dominio de aplicación que se
enfoca en los requisitos, componentes básicos y estándares relacionados con la visión de Límite Flujo de información
sin flujo.

Industria Arquitecturas
Las arquitecturas industriales guían la integración de componentes de sistemas comunes con componentes específicos de la
industria y guían la creación de soluciones industriales para problemas de clientes específicos dentro de una industria en particular.
Un ejemplo típico de un componente específico de la industria es un modelo de datos que representa las capacidades comerciales
y los procesos específicos de una industria vertical en particular, como la arquitectura de "Tienda activa" de la industria minorista, o
una Arquitectura industrial que incorpora el Modelo de datos energéticos. (consulte www.energistics.org).
Otras características de las arquitecturas industriales incluyen:
ÿ Refleja los requisitos y estándares específicos de una industria ver tical ÿ Define bloques
de construcción específicos para un dominio de problema genérico ÿ Contiene datos lógicos
y modelos de procesos específicos de la industria ÿ Contiene aplicaciones y modelos de
procesos específicos de la industria, así como

reglas del negocio
ÿ Proporciona pautas para probar colecciones de sistemas ÿ Fomenta los
niveles de interoperabilidad en toda la industria
Arquitecturas específicas de la organización Las
arquitecturas específicas de la organización describen y guían la implementación final de los componentes de la solución para una
empresa en particular o una red extendida de empresas conectadas.
Puede haber una variedad de arquitecturas específicas de la organización que se necesitan para cubrir de manera efectiva los
requisitos de la organización definiendo las arquitecturas en niveles de detalle crecientes.
Alternativamente, esto podría resultar en varias Arquitecturas Específicas de la Organización más detalladas para entidades
específicas dentro de la empresa global. El desglose de las arquitecturas específicas de la organización en piezas constituyentes
se aborda en el estándar TOGAF: aplicación del ADM.
La Arquitectura Específica de la Organización guía la personalización final de la solución y tiene las siguientes características:
ÿ Proporciona un medio para comunicar y administrar las operaciones comerciales en los cuatro dominios de arquitectura.
ÿ Refleja los requisitos específicos de una empresa en particular ÿ Define los
componentes básicos específicos de una empresa en particular ÿ Contiene
modelos comerciales, datos, aplicaciones y tecnologías específicos de la organización ÿ Proporciona un medio para
fomentar la implementación de soluciones apropiadas para cumplir con los requisitos comerciales
necesidades
ÿ Proporciona los criterios para medir y seleccionar productos, soluciones y servicios apropiados
ÿ Proporciona un camino evolutivo para respaldar el crecimiento y las nuevas necesidades comerciales

6.4.2 Soluciones continuas

El Continuo de Soluciones representa la especificación detallada y la construcción de las arquitecturas en los niveles
correspondientes del Continuo de Arquitectura. En cada nivel, Solutions Continuum es una población de la arquitectura
con bloques de construcción de referencia, ya sean productos comprados o componentes construidos, que representan
una solución para la necesidad comercial de la empresa expresada en ese nivel. Un repositorio completo basado en
Solutions Continuum puede considerarse como un inventario de soluciones o una biblioteca de reutilización, lo que
puede agregar un valor significativo a la tarea de administrar e implementar mejoras en la empresa.
El continuo de soluciones se ilustra en la figura 6-3.
© El Grupo Abierto
Base Sistemas Comunes Industria Específico de la organización

Soluciones Soluciones Soluciones Soluciones
Figura 6-3 Soluciones continuas
"Moverse a la derecha" en Solutions Continuum se enfoca en brindar valor a las soluciones (es decir, las soluciones
básicas brindan valor al crear soluciones de sistemas comunes; las soluciones de sistemas comunes se usan para crear
soluciones de la industria; y las soluciones de la industria se usan para crear soluciones específicas de la organización). ).
"Moverse a la izquierda" en Solutions Continuum se centra en abordar las necesidades empresariales. Estos dos puntos
de vista son importantes para una empresa que intenta centrarse en sus necesidades mientras maximiza el uso de los
recursos disponibles a través del apalancamiento.
Las siguientes subsecciones describen cada uno de los tipos de soluciones dentro de Solutions Continuum.
Soluciones para cimientos
Las Soluciones Básicas son conceptos, herramientas, productos, servicios y componentes de soluciones altamente
genéricos que son los proveedores fundamentales de capacidades. Los servicios incluyen servicios profesionales, como
servicios de capacitación y consultoría, que garantizan el máximo valor de inversión de las soluciones en el menor
tiempo posible; y servicios de soporte, como Help Desk, que garantizan el máximo valor posible de las soluciones
(servicios que garantizan actualizaciones y actualizaciones oportunas de los productos y sistemas).
Las soluciones básicas de ejemplo incluirían lenguajes de programación, sistemas operativos, estructuras de datos
fundamentales (como EDIFACT), enfoques genéricos para la estructuración de organizaciones, estructuras
fundamentales para organizar las operaciones de TI (como ITIL® o la arquitectura de referencia IT4IT), etc.

Soluciones de sistemas comunes
Una Solución de Sistemas Comunes es una implementación de una Arquitectura de Sistemas Comunes compuesta por un
conjunto de productos y servicios, que pueden ser certificados o de marca. Representa el máximo común denominador para
una o más soluciones en los segmentos de la industria que admite Common Systems Solution.
Las soluciones de sistemas comunes representan colecciones de requisitos y capacidades comunes, en lugar de los
específicos de un cliente o industria en particular. Common Systems Solutions brinda a las organizaciones entornos
operativos específicos para las necesidades operativas e informativas, como procesamiento de transacciones de alta
disponibilidad y sistemas de almacenamiento de datos escalables.
Los ejemplos de soluciones de sistemas comunes incluyen un producto de sistema de gestión empresarial o un producto de
sistema de seguridad.
Los proveedores de sistemas informáticos son los proveedores típicos de soluciones de sistemas comunes centradas en la
tecnología. Los proveedores de "software como servicio" son proveedores típicos de soluciones de aplicaciones comunes.
Los proveedores de subcontratación de procesos comerciales son proveedores típicos de soluciones de sistemas comunes
centradas en la capacidad comercial.
Soluciones industriales
Una solución industrial es una implementación de una arquitectura industrial, que proporciona paquetes reutilizables de
componentes comunes y servicios específicos para una industria.
Los componentes fundamentales son proporcionados por Common Systems Solutions y/o Foundation Solutions, y se
complementan con componentes específicos de la industria. Los ejemplos incluyen: un esquema de base de datos física o
un dispositivo de punto de servicio específico de la industria.
Las soluciones industriales son adquisiciones agregadas específicas de la industria que están listas para adaptarse a los
requisitos de una organización individual.
En algunos casos, una solución de la industria puede incluir no solo una implementación de la arquitectura de la industria,
sino también otros elementos de la solución, como productos, servicios y soluciones de sistemas específicos que son
apropiados para esa industria.
Soluciones específicas de la organización
Una solución específica de la organización es una implementación de la arquitectura específica de la organización que
proporciona las capacidades comerciales requeridas. Debido a que las soluciones están diseñadas para operaciones
comerciales específicas, contienen la mayor cantidad de contenido único para adaptarse a las distintas personas y procesos
de organizaciones específicas.
Construir Soluciones Específicas de la Organización en Soluciones de la Industria, Soluciones de Sistemas Comunes y

Soluciones de la Fundación es el propósito principal de conectar el Continuum de la Arquitectura con el Continuum de las
Soluciones, según lo guían los arquitectos dentro de una empresa.
Se estructurará una Solución específica de la organización para admitir SLA específicos para garantizar el soporte de los
sistemas operativos en los niveles de servicio deseados. Por ejemplo, un proveedor de alojamiento de aplicaciones de
terceros puede ofrecer diferentes niveles de soporte para sistemas operativos. Estos acuerdos definirían los términos y
condiciones de ese apoyo.
Otros factores clave que deben definirse dentro de una solución específica de la organización son los parámetros operativos
clave y las métricas de calidad que se pueden usar para monitorear y administrar el entorno.
Enterprise Continuum puede proporcionar un enlace clave entre el personal de arquitectura, desarrollo y operaciones al
permitirles comunicarse y llegar a un acuerdo sobre los requisitos de soporte operativo anticipados. El personal de
operaciones puede, a su vez, acceder a Enterprise

redistribución
Continuum para obtener información sobre los conceptos de operación y los requisitos de soporte de servicio del
sistema implementado.
6.5 El continuo empresarial y el ADM

TOGAF ADM describe el proceso de desarrollo de una arquitectura específica de la empresa y una solución o soluciones
específicas de la empresa que se ajustan a esa arquitectura adoptando y adaptando (cuando corresponda) arquitecturas
y soluciones genéricas (de izquierda a derecha en la clasificación continua ). De manera similar, las arquitecturas y
soluciones específicas que demuestren ser creíbles y eficaces se generalizarán para su reutilización (de derecha a
izquierda en la clasificación continua).
En lugares relevantes a lo largo de TOGAF ADM, hay punteros a activos de arquitectura útiles en el nivel relevante de
generalidad en la clasificación continua. Estos activos pueden incluir modelos de referencia de The Open Group e
industrias en general.
La biblioteca TOGAF proporciona modelos de referencia para su uso en el desarrollo de la arquitectura de una
organización.
Sin embargo, al desarrollar arquitecturas en los diversos dominios dentro de una arquitectura empresarial general, el
arquitecto deberá considerar el uso y la reutilización de una amplia variedad de activos de arquitectura diferentes, y
Enterprise Continuum proporciona un enfoque para categorizar y comunicar estos diferentes activos.
6.6 El continuo empresarial y su organización

Las secciones anteriores han descrito el Continuo de la Empresa, el Continuo de la Arquitectura y el Continuo de las
Soluciones. Las siguientes secciones describen las relaciones entre cada uno de los tres continuos y cómo se deben
aplicar estas relaciones dentro de su organización.
6.6.1 Relaciones
Cada uno de los tres continuos contiene información sobre la evolución de las arquitecturas durante su ciclo de vida: ÿ
Enterprise Continuum proporciona un contexto general para arquitecturas y soluciones, y clasifica los activos que se
aplican en todo el alcance de la empresa
ÿ El continuo de la arquitectura proporciona un mecanismo de clasificación para los activos que definen
colectivamente la arquitectura en diferentes niveles de evolución, desde lo genérico a lo específico.
ÿ El continuo de soluciones proporciona la clasificación de los activos para describir soluciones específicas para la
organización que se pueden implementar para lograr la intención de la arquitectura.
Las relaciones entre el Continuo de Arquitectura y el Continuo de Soluciones se muestran en la Figura 6-4.

El continuo empresarial y su organización Continuidad empresarial
Común
Base Sistemas Industria Específico de la organización
arquitecturas arquitecturas arquitecturas arquitecturas
Base Sistemas Comunes Industria Específico de la organización

Soluciones Soluciones Soluciones Soluciones
© El Grupo Abierto
Figura 6-4 Relaciones entre Arquitectura y Soluciones Continua
La relación entre el Continuo de la Arquitectura y el Continuo de las Soluciones es de orientación, dirección y apoyo.
Por ejemplo, Foundation Architectures guía la creación o selección de Foundation Solutions. Foundation Solutions
respalda a Foundation Architecture al ayudar a realizar la arquitectura definida en Architecture Continuum. La
Arquitectura de la Fundación también guía el desarrollo de las Soluciones de la Fundación, al proporcionar la dirección,
los requisitos y los principios arquitectónicos que guían la selección y la realización de las soluciones apropiadas. Existe
una relación similar entre los otros elementos del Continuo Empresarial.
Enterprise Continuum presenta mecanismos para ayudar a mejorar la productividad a través del apalancamiento.
The Architecture Continuum ofrece una forma coherente de comprender las diferentes arquitecturas y sus componentes.
Solutions Continuum ofrece una forma consistente de comprender los diferentes productos, sistemas, servicios y
soluciones requeridas.
El Enterprise Continuum no debe interpretarse como una representación de relaciones estrictamente encadenadas. Las
Arquitecturas Específicas de la Organización podrían tener componentes de una Arquitectura de Sistemas Comunes, y
las Soluciones Específicas de la Organización podrían contener Soluciones Básicas.
Las relaciones representadas en la Figura 6-1 son una ilustración que muestra oportunidades para aprovechar la
arquitectura y los componentes de la solución.

redistribución
Continuidad empresarial El continuo empresarial y su organización
6.6.2 Su empresa
El estándar TOGAF proporciona un método para "diseñar" los sistemas de su empresa.
Su organización de arquitectura tendrá que lidiar con cada tipo de arquitectura descrito anteriormente.
Por ejemplo, se recomienda que tenga su propia arquitectura de base que gobierne todos sus sistemas. También debe
tener sus propias arquitecturas de sistemas comunes que rijan los principales sistemas compartidos, como el sistema
de red o el sistema de gestión. Puede tener sus propias arquitecturas específicas de la industria que rigen la forma en
que sus sistemas deben comportarse dentro de su industria. Finalmente, cualquier departamento u organización dado
dentro de su negocio puede necesitar su propia Arquitectura Específica de la Organización individual para gobernar los
sistemas dentro de ese departamento.
Su organización de arquitectura adoptará o adaptará las arquitecturas existentes, o desarrollará sus propias arquitecturas
desde cero. En cualquier caso, el estándar TOGAF es una herramienta de ayuda. Proporciona un método para ayudarlo
a generar/mantener cualquier tipo de arquitectura dentro de Architecture Continuum mientras aprovecha los activos de
arquitectura ya definidos, internos o externos a su organización. TOGAF ADM lo ayuda a reutilizar los activos de
arquitectura, lo que hace que su organización de arquitectura sea más eficiente y efectiva.

Continuidad empresarial

redistribución
Capítulo 7: Repositorio de Arquitectura
7.1 Resumen
Operar una capacidad de arquitectura madura dentro de una gran empresa crea un gran volumen de producción
arquitectónica. La gestión eficaz y el aprovechamiento de estos productos de trabajo arquitectónico requieren una
taxonomía formal para diferentes tipos de activos arquitectónicos junto con procesos y herramientas dedicados para el
almacenamiento de contenido arquitectónico.
Esta sección proporciona un marco estructural para un repositorio de arquitectura que permite a una empresa distinguir
entre diferentes tipos de activos arquitectónicos que existen en diferentes niveles de abstracción en la organización.
Este Repositorio de arquitectura es una parte del Repositorio empresarial más amplio, que brinda la capacidad de
vincular activos arquitectónicos a componentes de los Repositorios de diseño detallado, implementación y administración
de servicios.
En un alto nivel, se espera que las siguientes clases de información arquitectónica se mantengan dentro de un
Repositorio de Arquitectura:
ÿ El metamodelo de arquitectura describe la aplicación adaptada a la organización de un marco de arquitectura,

incluido un método para el desarrollo de la arquitectura y un metamodelo para el contenido de la arquitectura.
ÿ La capacidad de la arquitectura define los parámetros, estructuras y procesos que

apoyar la gobernanza del Repositorio de Arquitectura
ÿ El Paisaje Arquitectónico presenta una representación arquitectónica de activos en uso, o

planificado, por la empresa en puntos particulares en el tiempo
ÿ La biblioteca de estándares captura los estándares que deben cumplir las nuevas arquitecturas, que pueden
incluir estándares de la industria, productos y servicios seleccionados de proveedores o servicios compartidos ya
implementados dentro de la organización.
ÿ La Biblioteca de referencia proporciona pautas, plantillas, patrones y otras formas de material de referencia que
se pueden aprovechar para acelerar la creación de nuevas arquitecturas para la empresa.
ÿ El repositorio de gobernanza proporciona un registro de la actividad de gobernanza en todo el

ingresar premio
ÿ El repositorio de requisitos de arquitectura proporciona una vista de todos los requisitos de arquitectura
autorizados que se han acordado con la Junta de Arquitectura.
ÿ El paisaje de soluciones presenta una representación arquitectónica de los SBB que respaldan el paisaje
arquitectónico que ha planificado o implementado la empresa.
Las relaciones entre estas áreas del Repositorio de Arquitectura se muestran en la Figura 7-1.

Visión general Repositorio de arquitectura
© El Grupo Abierto
Repositorio empresarial
Metamodelo de arquitectura
Repositorio de Arquitectura
Método de arquitectura Metamodelo empresarial
Los artefactos
Referencia
en el paisaje
Biblioteca
están estructurados de Las mejores
acuerdo con el marco prácticas
Modelos de
crean una
referencia
Soluciones Arquitectura arquitectura de referencia
adoptados
Paisaje Paisaje Externo
Organización por la empresa
Referencia Referencia
Adoptado Materiales Modelos
Estratégico por la
arquitecturas empresa
Solución Habilita la
Edificio empresa
Segmento
arquitecturas Los estándares
bloques
Se cumplen tienen
las normas implementaciones de referencia
Capacidad Estándares
arquitecturas Biblioteca Estándares
Estándares comerciales adoptado

Las por la empresa Externo
Resultados
mejores Estándares de datos Estándares
comerciales
prácticas
entregados
crean estándares Normas de aplicación
Arquitectura El paisaje se rige

Estándares tecnológicos
Requisitos
El cumplimiento se rige
Repositorio
Repositorio de Gobernanza
Estratégico Visibilidad y
Impulsores para la empresa Cumplimiento Capacidad escalamiento
Requisitos Registro de decisiones
Evaluaciones Evaluaciones
Proyecto Actuación
Segmento Calendario Arquitectura
portafolio Medición
Requisitos Arquitectura Junta
La junta dirige
Capacidad de arquitectura y gestiona la
Capacidad capacidad.
Habilidades
Organización Arquitectura
Requisitos
Repositorio Estructura Carta
Figura 7-1 Vista general del repositorio de arquitectura
Las siguientes secciones describen la estructura y el contenido de las áreas del repositorio.
7.2 Paisaje Arquitectónico

El Paisaje Arquitectónico contiene vistas arquitectónicas del estado de la empresa en puntos particulares en el tiempo.
Debido al gran volumen y las diversas necesidades de las partes interesadas en toda la empresa, el paisaje
arquitectónico se divide en tres niveles de granularidad:
1. Las Arquitecturas Estratégicas (ver el Estándar TOGAF - Método de Desarrollo de Arquitectura) muestran una
vista resumida a largo plazo de toda la empresa. Las Arquitecturas Estratégicas brindan un marco organizativo
para la actividad operativa y de cambio y permiten establecer direcciones a nivel ejecutivo.
2. Las arquitecturas de segmento (consulte el estándar TOGAF: método de desarrollo de arquitectura) proporcionan
modelos operativos más detallados para áreas dentro de una empresa. Las arquitecturas de segmento se
pueden utilizar a nivel de programa o cartera para organizar y alinear operativamente la actividad de cambio
más detallada.

redistribución
Repositorio de Arquitectura Arquitectura Paisaje
3. Las arquitecturas de capacidad (consulte el estándar TOGAF: método de desarrollo de arquitectura) muestran de
manera más detallada cómo la empresa puede soportar una unidad particular de capacidad. Las arquitecturas de
capacidad se utilizan para proporcionar una descripción general de la capacidad actual, la capacidad objetivo y los
incrementos de capacidad, y permiten agrupar proyectos y paquetes de trabajo individuales dentro de carteras y
programas administrados.
7.3 Biblioteca de referencia

7.3.1 Resumen
La Biblioteca de referencia proporciona un depósito para almacenar materiales de referencia que deben usarse para
desarrollar arquitecturas. Los materiales de referencia que se tienen pueden obtenerse de una variedad de fuentes, que
incluyen:
ÿ Organismos de normalización
ÿ Proveedores de productos y servicios
ÿ Comunidades o foros de la industria ÿ
Plantillas estándar
ÿ Introduzca el premio a las mejores prácticas
La biblioteca de referencia debe contener:
ÿ Arquitecturas de referencia
ÿ Modelos de referencia
ÿ Biblioteca Viewpoint
ÿ Plantillas
Nota: Los términos arquitectura de referencia y modelo de referencia no se usan con cuidado en la mayoría de la literatura.
La arquitectura de referencia y el modelo de referencia tienen la misma relación que la arquitectura y el modelo.
Cualquiera puede existir como estado genérico o específico de la organización. Por lo general, una arquitectura de
referencia genérica proporciona al equipo de arquitectura un resumen de la arquitectura de referencia específica de
su organización que se personalizará para una organización específica. Por ejemplo, una arquitectura de referencia
genérica puede identificar que se necesitan modelos de datos. Un ejemplo de arquitectura de referencia es la
arquitectura de referencia de TI para TI, que también define un modelo de información común para la gestión de TI.
Otro ejemplo es el TM Forum eTOM y SID como arquitectura de referencia específica de la organización.
Con el fin de segregar diferentes clases de materiales de referencia de arquitectura, la Biblioteca de referencia puede
utilizar el continuo de arquitectura como método de clasificación.
TOGAF® Standard — Arquitectura Contenido © 99

2005-2022 The Open Group, Todos los derechos reservados Copia
de evaluación. No para redistribución
Biblioteca de referencia Repositorio de Arquitectura
© El Grupo Abierto
Figura 7-2 Arquitectura continua
El continuo de la arquitectura, como se muestra en la figura 7-2, puede verse como un esquema de clasificación de la
biblioteca de referencia. Como tal, ilustra cómo se pueden organizar las arquitecturas de referencia en un rango, desde
arquitecturas de base y arquitecturas específicas de la industria hasta una arquitectura específica de la organización.
Las necesidades de la empresa y los requisitos comerciales se abordan en abstracción decreciente de izquierda a
derecha. El arquitecto normalmente encontrará más elementos arquitectónicos reutilizables hacia la izquierda del rango.
Cuando no se encuentran elementos, los requisitos para los elementos que faltan se pasan a la izquierda del rango
para su incorporación.
A través de este ejercicio es importante tener en cuenta los conceptos de niveles y particiones. En diferentes niveles de
granularidad pueden existir materiales de referencia apropiados para el nivel, y se puede esperar que las particiones
dentro del Paisaje Arquitectónico utilicen diferentes materiales de referencia (ver el Estándar TOGAF — Aplicación del
ADM).
7.4 Biblioteca de estándares

7.4.1 Resumen
La biblioteca de estándares proporciona un área de depósito para contener un conjunto de especificaciones, a las que
deben ajustarse las arquitecturas. El establecimiento de una biblioteca de estándares proporciona una base inequívoca
para el gobierno de la arquitectura porque:
ÿ Los estándares son fácilmente accesibles para los proyectos y por lo tanto las obligaciones del proyecto
puede ser entendido y planeado para
ÿ Las normas se establecen de manera clara e inequívoca, de modo que el cumplimiento pueda evaluarse
objetivamente.

redistribución
Repositorio de Arquitectura Biblioteca de normas
7.4.2 Tipos de Norma

Los estándares generalmente se dividen en tres clases:
ÿ Obligaciones legales y reglamentarias: estas normas son obligatorias por ley y, por lo tanto, una empresa debe cumplirlas
o enfrentar graves consecuencias.
ÿ Estándares de la industria: estos estándares son establecidos por organismos de la industria, como The
Open Group, y luego son seleccionados por la empresa para su adopción. Los
estándares de la industria ofrecen potencial para la interoperación y el intercambio entre empresas, pero también quedan
fuera del control de la empresa y, por lo tanto, deben monitorearse activamente.
ÿ Estándares organizacionales: estos estándares se establecen dentro de la organización y se basan en las aspiraciones
comerciales (p. ej., selección de aplicaciones estándar para respaldar la consolidación de la cartera).
Los estándares organizacionales requieren procesos para permitir exenciones y la evolución de los estándares.
7.4.3 Ciclo de vida de los estándares

Los estándares generalmente no existen para todos los tiempos. Los nuevos estándares se identifican y gestionan a través de un
proceso de ciclo de vida.
Por lo general, los estándares pasan por las siguientes etapas:
ÿ Estándar propuesto : se ha identificado un estándar potencial para la organización, pero se ha

aún no ha sido evaluado para su adopción
ÿ Estándar provisional (también conocido como estándar de prueba): un estándar provisional ha sido identificado como un
estándar potencial para la organización, pero no ha sido probado hasta un nivel en el que su valor se comprenda por
completo. Los proyectos que deseen adoptar estándares provisionales pueden hacerlo, pero bajo condiciones piloto
específicas, para que la viabilidad del estándar pueda ser examinada con más detalle.
ÿ Estándar (también conocido como estándar activo): un estándar define una solución principal
que generalmente se debe utilizar como el enfoque de elección
ÿ Estándar de eliminación gradual (también conocido como estándar en desuso): un estándar de eliminación gradual se
acerca al final de su ciclo de vida útil. Los proyectos que reutilizan componentes existentes generalmente pueden continuar
haciendo uso de estándares de eliminación gradual. Por lo general, se desaconseja la implementación de nuevas instancias
del estándar de eliminación gradual.
ÿ Estándar Retirado (también conocido como Estándar Obsoleto): un Estándar Retirado ya no es

aceptado como válido dentro del paisaje
En la mayoría de los casos, se deben tomar medidas correctivas para eliminar el Estándar Retirado del paisaje. La
actividad de cambio en un estándar retirado solo debe aceptarse como parte de un plan general de desmantelamiento.
Todos los estándares deben revisarse periódicamente para garantizar que se encuentren en la etapa correcta del ciclo de vida de
los estándares. Como parte de la gestión del ciclo de vida de los estándares, se debe abordar el impacto de cambiar el estado del
ciclo de vida para comprender el impacto en el paisaje de un cambio de estándares y planificar la acción adecuada para abordarlo.

Biblioteca de normas Repositorio de Arquitectura
7.4.4 Clasificación de estándares dentro de la biblioteca de estándares

Los estándares dentro de la Biblioteca de Estándares se clasifican de acuerdo con los componentes básicos dentro del
Metamodelo TOGAF Enterprise. Cada entidad de metamodelo puede potencialmente tener estándares asociados con ella
(por ejemplo, Servicio de Negocios, Componente de Tecnología).
Los estándares pueden relacionarse con bloques de construcción "aprobados" (p. ej., una lista de componentes de
tecnología estándar) o pueden especificar el uso apropiado de un bloque de construcción (p. ej., escenarios donde la
infraestructura de mensajería es apropiada, se definen estándares de comunicación de aplicaciones).
En el nivel superior, los estándares se clasifican de acuerdo con los dominios de arquitectura TOGAF, incluidas las
siguientes áreas:
ÿ Estándares comerciales:
— Capacidades empresariales compartidas estándar
— Definiciones estándar de roles y actores
— Normas de seguridad y gobierno de la actividad empresarial
ÿ Estándares de datos:
— Codificación estándar y valores para los datos
— Estructuras estándar y formatos para datos
— Estándares para el origen y la propiedad de los datos
— Restricciones de replicación y acceso
ÿ Estándares de aplicaciones:
— Aplicaciones estándar/compartidas que soportan funciones comerciales específicas
— Estándares para la comunicación e interoperación de aplicaciones
— Normas de acceso, presentación y estilo
ÿ Estándares de Tecnología;
— Productos de hardware estándar
— Productos de software estándar
— Estándares para el desarrollo de software

redistribución
Repositorio de Arquitectura Biblioteca de estándares
7.5 Repositorio de Gobernanza

7.5.1 Resumen
El Repositorio de Gobernanza proporciona un área de depósito para mantener información compartida relacionada con la gobernabilidad
en curso de los proyectos. Es importante mantener un depósito compartido de información sobre gobernanza porque:
ÿ Las decisiones tomadas durante los proyectos (como las desviaciones estándar o la justificación de un enfoque arquitectónico en
particular) son importantes para retener y acceder de forma continua. Por ejemplo, si se va a reemplazar un sistema, tener a la
vista las decisiones arquitectónicas clave que dieron forma la implementación inicial es muy valiosa ya que resaltará las
limitaciones que de otro modo podrían quedar ocultas.
ÿ Muchas partes interesadas están interesadas en el resultado de la gobernanza del proyecto (p. ej., otros
proyectos, clientes del proyecto, Junta de Arquitectura, etc.)
7.5.2 Contenido del Repositorio de Gobernanza

El Repositorio de Gobernanza debe contener los siguientes elementos:
ÿ Registro de decisiones : un registro de todas las decisiones importantes desde el punto de vista arquitectónico que se han tomado en el
organización
Esto típicamente incluiría:
— Selecciones de productos
— Justificación de las principales características arquitectónicas de los proyectos
— Desviaciones estándar
— Cambios en el ciclo de vida de los estándares
— Evaluaciones y aprobaciones de solicitudes de cambio
— Evaluaciones de reutilización
ÿ Evaluaciones de cumplimiento: en los hitos clave del punto de control en el progreso de un proyecto, se llevará a cabo una
revisión formal de la arquitectura.
Esta revisión medirá el cumplimiento del proyecto con los estándares de arquitectura definidos. Para cada proyecto, este registro
debe incluir:
- Descripción del proyecto
— Visión general del progreso (línea de tiempo, estado, problemas, riesgos, dependencias, etc.)
— Listas de verificación de arquitectura completadas
— Evaluación de cumplimiento de estándares
- Acciones recomendadas
ÿ Evaluaciones de Capacidad: dependiendo de sus objetivos, algunos proyectos llevarán a cabo

evaluaciones de capacidad comercial, de TI o de arquitectura
Estas evaluaciones deben llevarse a cabo y monitorearse periódicamente para asegurar que se está logrando el progreso
adecuado. Este registro debe incluir:

Repositorio de Gobernanza Repositorio de Arquitectura
— Plantillas y modelos de referencia para ejecutar Evaluaciones de Capacidad
— Evaluaciones de capacidad empresarial
— Evaluaciones de capacidad, madurez e impacto de TI
— Evaluaciones de madurez de la arquitectura
ÿ Calendario: el Calendario debe mostrar un cronograma de proyectos en curso y sesiones formales de revisión
que se llevarán a cabo en relación con estos proyectos.
ÿ Portafolio de proyectos: el Portafolio de proyectos debe contener información resumida sobre todos los proyectos
en curso que caen bajo Arquitectura Gobernante, incluyendo:
— El nombre y la descripción del proyecto.
— Alcance arquitectónico del proyecto
— Funciones y responsabilidades arquitectónicas asociadas con el proyecto
ÿ Medición del desempeño: en base a un estatuto para la función de arquitectura, normalmente se definirá una
serie de criterios de desempeño. El registro de medición del desempeño debe capturar las métricas relacionadas
con la gobernanza del proyecto y cualquier otra métrica de desempeño relacionada con el estatuto de ese
desempeño puede medirse y evaluarse de manera continua.
7.6 El repositorio de requisitos de la arquitectura

7.6.1 Resumen
Todas las fases del ADM utilizan el Repositorio de requisitos de la arquitectura para registrar y gestionar toda la
información relevante para los requisitos de la arquitectura. Los requisitos abordan los muchos tipos de requisitos de
arquitectura; es decir, requisitos estratégicos, de segmento y de capacidad, que son los principales impulsores de la
arquitectura empresarial.
Los requisitos se pueden recopilar en cada etapa del ciclo de desarrollo de la arquitectura y deben aprobarse a través
de las diversas fases y procesos de gobierno.
La fase de Gestión de requisitos es responsable de la gestión de los contenidos del Repositorio de requisitos de
arquitectura y de garantizar la integridad de todos los requisitos y su disponibilidad para el acceso de todas las fases.
7.6.2 Contenido del repositorio de requisitos de arquitectura

El repositorio de requisitos de arquitectura contiene los requisitos de arquitectura del estado requerido de la empresa
en momentos específicos. Debido al gran volumen y las diversas necesidades de las partes interesadas a lo largo del
ciclo de desarrollo de la arquitectura, los requisitos de la arquitectura se dividen en tres niveles de granularidad:
1. Los requisitos de arquitectura estratégica muestran una vista resumida a largo plazo de los requisitos para
toda la empresa.
Los requisitos de la arquitectura estratégica identifican los requisitos operativos y de cambio para el
establecimiento de la dirección a nivel ejecutivo.

redistribución
Repositorio de Arquitectura El repositorio de requisitos de arquitectura
2. Los requisitos de arquitectura de segmento proporcionan requisitos de modelo operativo más detallados para áreas
dentro de una empresa.
Los requisitos de arquitectura de segmento pueden identificar requisitos a nivel de programa o cartera para identificar
y alinear una actividad de cambio más detallada.
3. Los requisitos de la arquitectura de capacidad identifican los requisitos detallados para un determinado
unidad de capacidad.
Los requisitos de arquitectura de capacidades identifican los requisitos para paquetes de trabajo y proyectos
individuales que se agruparán dentro de carteras y programas administrados.
Los resultados comerciales para los requisitos de arquitectura se reflejarán en el panorama de soluciones a lo largo del
tiempo. Cuando esto ocurre, los requisitos de la arquitectura se cumplen y se archivan con fines de auditoría.
7.7 Panorama de soluciones

El panorama de soluciones contiene los SBB que respaldan las especificaciones, el desarrollo y la implementación de ABBS.
Los componentes básicos pueden ser productos o servicios que pueden categorizarse de acuerdo con la categorización de
Enterprise Continuum y/o las especificaciones de ABB como SBB estratégicos, de segmento o de capacidad.
Los SBB también pueden incluir herramientas, sistemas, servicios e información que describen las soluciones reales que
pueden seleccionarse y su funcionamiento. Por ejemplo, aquí se definirían los modelos de referencia específicos del
proveedor o los niveles 4 y 5 específicos del proveedor de la arquitectura de referencia IT4IT.
Sin embargo, el Panorama de Soluciones no incluirá el contenido de información y datos producido por las soluciones
seleccionadas; esa es responsabilidad de las propias soluciones.
7.8 El repositorio empresarial

Si bien el repositorio de arquitectura contiene información sobre la arquitectura empresarial y las especificaciones y artefactos
asociados, existe una cantidad considerable de repositorios empresariales que respaldan la arquitectura tanto dentro como
fuera de la empresa.
Estos pueden incluir repositorios de desarrollo, entornos operativos específicos, instrucciones y repositorios de gestión de
configuración.

El repositorio empresarial Repositorio de Arquitectura
7.9 Repositorios externos

7.9.1 Modelos de referencia externa
Hay muchos modelos de referencia de la industria disponibles que pueden ayudar a comprender el papel y desarrollar
las arquitecturas de referencia.
7.9.2 Normas externas

Estos se relacionan con la industria, las mejores prácticas o los estándares formales definidos que utilizan las
organizaciones líderes. Los ejemplos incluyen normas ISO, IEEE y gubernamentales.
7.9.3 Aprobaciones de la Junta de Arquitectura

Las decisiones tomadas por el Consejo de Arquitectura que afectan a la Arquitectura Empresarial a menudo se registran
en las actas de las reuniones. Estas actas a menudo se guardan en archivos de documentación que están excluidos
del Repositorio de Arquitectura por razones legales o reglamentarias.

redistribución
Índice
ABB .................................................. .................................................... 65, 79-80 Tienda

activa ........................................... .................................................... ......90 Matriz de actor/
rol ....................................... .................................................... .46
ADM .................................................. .................................................... ..36, 82 Diagrama de
ubicación de aplicación y usuario .................................. .....................55 Diagrama de
comunicación de la aplicación ......................... ...................................55 Matriz de interacción
de aplicaciones ........... .................................................... ...........55 Diagrama de migración de
aplicaciones .................................. ..................................57 Catálogo de la cartera de
aplicaciones ......... .................................................... ...............52 Diagrama de caso de uso de
la aplicación ....... .................................................... ............56 Matriz de aplicación/
datos .................................. ..........................................50 Aplicación /Matriz de
funciones ............................................... ..........................54 Matriz de aplicación/
organización .................. .................................................... .53 Matriz de aplicación/
tecnología ............................................... ..........................58 Normas de
aplicaciones ............... .................................................... ........102 artefacto
arquitectónico ....................................... ...............................................31
conceptos . .................................................... ..................................................31 artefactos
arquitectónicos ................................................. .....................................39 bloque de construcción
de arquitectura ......... ..................................... .............................80 Capacidad de la
arquitectura .................. .................................................... ...............97 Arquitectura
continua .................................. ..........................................80, 88 Contrato de
Arquitectura ... .................................................... ...............................65 Documento de Definición
de Arquitectura ............... .................................................... 66 entregables de la
arquitectura ............................................... ..........................63 Descripción de la
arquitectura ............... .................................................... ...............31 Arquitectura
Paisaje.................................. ..........................................97-98 Arquitectura
Metamodelo.. .................................................... ............................97 modelo de
arquitectura ............... .................................................... ...................31 Arquitectura e
Principios .................................................. ....................................67 Repositorio de
Arquitectura ................ .................................................... .......8, 68, 97 Repositorio de requisitos
de arquitectura.................................... ..............97, 104 Especificación de los requisitos de la
arquitectura ............................... ........................68 Hoja de ruta de la
arquitectura ....................... .................................................... .........69 vista de la
arquitectura ....................................... .................................................... ...31
creación ............................................. .................................................... ......35
ejemplos .......................................... .................................................... .......36
directrices .............................................. .................................................... .......34 punto de
vista de la arquitectura ................................ .................................................... 32
ejemplos ................................................ .................................................... .36 Visión de la
Arquitectura.................................................... ..........................................70 Diagrama de
beneficios ..... .................................................... ..................................61 bloques de
construcción ........... .................................................... ..........................39, 79
características .................. .................................................... .......................79
diseño ......................... .................................................... .............................82

Índice
Catálogo de Capacidades Empresariales .............................................. ..........................45

Mapa de Capacidades Empresariales .................. .................................................... 43, 49
impulsores comerciales ............................................. .............................................70 Evento de
negocios diagrama .................................................. ..............................49 Diagrama de la Huella
de Negocio ............... .................................................... .........47 Catálogo del glosario
empresarial .................................. ..........................................46 objetivos de
negocio ......... .................................................... ..........................70 Matriz de interacción
empresarial ........... .................................................... ..............46 Diagrama del modelo de
negocio ............................... .......................................................42 principios
empresariales ......................... .................................................... ............70 escenarios de
negocio ............................... .................................................... ..70 Catálogo de servicios/
funciones empresariales.................................. .....................44 Diagrama de servicio comercial/
información .................. ....................................47 Estándares
comerciales ............ .................................................... ......................102 Diagrama de casos de
uso empresarial .................. .................................................... 48
Calendario .................................................. .................................................... ...104 Arquitectura
de capacidades.................................................... ..........................................99 Requisitos de la
arquitectura de capacidad ........ ..........................................105 Capacidad
Evaluación ................................................. ..........................71, 103 Matriz de capacidad/
organización ............................................... ..........................47
catálogo ........................ .................................................... ..........................39
catálogos ................ .................................................... ..........................................39 Solicitud de
cambio ......... .................................................... ..........................72
CMMI ................ .................................................... ..........................................63 Arquitecturas
de sistemas comunes .... .................................................... ............89 Soluciones de sistemas
comunes .................................. ..........................................92 Plan de
comunicación ........ .................................................... .........................73 Evaluación del
cumplimiento ....................... ..........................................73, 103 Diagrama de datos
conceptuales ............ .................................................... ...............51 preocupación
n................................. .................................................... .......................33
inquietudes ........................ .................................................... .............................31 Marco de
contenido .................. .................................................... .........1, 3-5, 9 Marco de contenido y
TOGAF ADM ........................... .........................7 Catálogo de contratos/
medidas.................... .................................................... .......45
CUNAS ............................................. .................................................... ...........82
CRM ............................... .................................................... .............................50
CRUD ............... .................................................... .......................................39 Diagrama de
difusión de datos ....... .................. ..........................................51 Datos Matriz de Entidad/
Función de Negocio ............................................... ..............50 Catálogo de entidades de datos/
componentes de datos .................. ..............................49 Diagrama del ciclo de vida de los
datos .................. .................................................... ...............52 Diagrama de migración de
datos ............................... .................................................... 52 Diagrama de seguridad de
datos .............................................. ..........................................51 Estándares de
datos ........... .................................................... ............................102 Registro de
decisiones .................. .................................................... ............................103
entregables .................. .................................................... .............................64 Repositorio de
implementación .................. .................................................... ....... .....97 Repositorio de Diseño
Detallado ............................................... ..........................97
diagramas ............... .................................................... ......................................39 Catálogo de
impulsores/metas/objetivos .... .................................................... ..........43

redistribución
Índice
Energética .................................................. .................................................... .90 Entrar premio

Continuum ............................................... ..................................8, 85 Diagrama de capacidad
de gestión empresarial ......... .................................................... .....56 Premio
metamodelo .................................................. ....................................3-4, 9
atributos ....... .................................................... ..........................................15
detalle ...... .................................................... .................................................... 11
entidades .................................................. .................................................... .....12 vista
general .......................................... .................................................... ........10
relaciones ................................................ .................................................... ....25 vi
sión .................................................. .................................................... ........9 Entrar en el
depósito de premios ....................................... .....................................97, 105 Diagrama del
entorno ........ .................................................... ..........................58
eTOM ...................... .................................................... ....................................99 Arquitectura
de cimentaciones ........... .................................................... ...................89 Soluciones para
cimientos .......................... .................................................... ......91 Diagrama de descomposición
funcional ........................................... .......................47 Diagrama de Meta/Objetivo/Servicio de
Negocios .................. ..........................48 Repositorio de
Gobernanza .............. .................................................... ........97, 103 contenidos
de ...................................... .. .................................................... ......103 III-
RM .......................................... .................................................... ...........89 Plan de
Implementación y Migración ........................... ..........................74 Modelo de Gobernanza de
Implementación ........... .................................................... .75 Arquitecturas
industriales .................................................. ..........................................90 Soluciones para la
industria ........ .................................................... ..............................92 mapa de
información ............... .................................................... ..........................49 Catálogo de
interfaces .................. .................................................... .....................52 Arquitectura de
referencia IT4IT.................... ..................................91, 99, 105
ITIL ........... .................................................... .................. ...............................91 Catálogo de
ubicaciones ............... .................................................... .............................44 Diagrama de
ubicación .................. .................................................... ......................58 Diagrama de datos
lógicos ........................... .................................................... ..........51
matrices ............................................ .................................................... ...........39 matriz
ix .............................. .................................................... ............................39 tipo de
modelo ............... .................................................... ....................................32
MSP ................. .................................................... ..........................................63 Diagrama de
Red y Comunicaciones. .................................................... .....61 Computación en red/Diagrama
de hardware .................................. ...............60 Diagrama de descomposición de la
organización.................... ............................48 mapa de la
organización ............... .................................................... .....................49 Arquitecturas
específicas de la organización .................. ......................................90 Soluciones específicas
de la organización ....... .................................................... ...........92 Catálogo de organizaciones/
actores .................................. ..........................................43 Modelo
Organizativo...... .................................................... ............................75 medición del
rendimiento .................. .................................................... .....104 Diagrama de descomposición
de la plataforma ........................................ ..........................59
PMBOK ...................... .................................................... ...................................63
PRÍNCIPE2 ............... ....................... .................................................... ..............63 Catálogo de
principios .................................. .................................................... ........41 Diagrama de flujo del
proceso ....................................... ............................................48 Diagrama de realización de
procesos/aplicaciones .................................................... ....56

Índice
Proceso/Evento/Control/Catálogo de productos ........................................... ..............45

Diagrama de procesamiento ............................... .................................................... ...59
Diagrama del ciclo de vida del producto.................................... ..................................48
Diagrama de contexto del proyecto ............ .................................................... ...........61 Cartera
de proyectos ............................... .................................................... ............104 Biblioteca de
referencia ............................... ..........................................................97 , 99 Solicitud de Obra de
Arquitectura........................................... ............................76 Catálogo de
requisitos ........................... .................................................... .............61 Evaluación del impacto
de los requisitos ............................... ............................76 Catálogo de
roles.................. .......................... .................................................... .....44 Matriz de roles/
aplicaciones ........................................... .............................................54
SBB ....... .................................................... ..........................................77, 79, 81 Arquitectura
de segmentos . .................................................... ..........................98 Requisitos de la
arquitectura del segmento .................. ............................................105 Repositorio de gestión
de ser vicios . .................................................... ..............97
S.I.D.................................. .................................................... ............................99
INTELIGENTE .................. .................................................... ...................................12 Diagrama
de distribución de software ........... .................................................... ..........57 Diagrama de
ingeniería de software ............................... ................... ...............57 componentes básicos de la
solución ............................... .................................................... 81 Diagrama del concepto de
solución ........................................... ..............................42 Continuo de
soluciones .................. .................................................... .............81, 91 Panorama de
soluciones ............................... .............................................97, 105 parte
interesada .. .................................................... .............................................31 Catálogo de
grupos de interés .................................................... ....................................42 Biblioteca de
estándares .......... .................................................... .............97, 100, 102 normas,
clasificación ............................... ..........................................................102 estándares, ciclo de
vida .............................................. ..........................................101 estándares, ty pes
de .................................................. ..................................101 Declaración de Trabajo
Arquitectónico ...... .................................................... ............77 Arquitectura
Estratégica.................................... ..........................................................98 Requerimientos de
Arquitectura Estratégica .............................................. ...........104 Matriz de estrategia/
capacidad .................................. ..........................................47 Marco de arquitectura a
medida ... .................................................... .............78 Catálogo de Portafolio de
Tecnología ........................... .............................................58 Estándares
tecnológicos ...... .................................................... ..........................102 Catálogo de estándares
tecnológicos ...................... ..........................................57 TM Para
eh .................................................. .................. ..................................99 TOGAF
ADM........... .................................................... .............................63, 93 TOGAF
TRM............... .................................................... .............................89 Diagrama de la cadena
de valor ............... .................................................... .....................42 Catálogo de flujo de
valor ........................ .................................................... .........45 mapa de flujo de
valor ...................................... .............................................43, 49 Valor Catálogo de Etapas de
flujo .................................................. .......................46 Matriz de flujo de valor/
capacidad .................. .................................................... 47

redistribución

C220 Part4e

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

C220 Part4e

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

El estándar de grupo abierto

Estándar TOGAF® —Arquitectura Contenido

© 2005-2022 The Open Group, todos los derechos reservados

Copyright © 2005-2022, The Open Group

Reservados todos los derechos.

El estándar de grupo abierto

Estándar TOGAF® — Contenido de la arquitectura

Publicado por The Open Group, 2005-2022.

yo The Open Group Standard (2022)

Capítulo 1 Introducción................................................. .......................................... 1

Capitulo 2 Marco de contenido TOGAF y metamodelo empresarial .... 9

Capítulo 3 Artefactos Arquitectónicos .................................................. ....................... 31

Estándar TOGAF® — Arquitectura Contenido iii

3.6.5 Fase C: Arquitectura de la aplicación ............................................. .......... 52

Capítulo 4 4.1 4.2 Entregables de la arquitectura .................................................. .......... 63

Capítulo 5 5.1 5.2 Bloques de construcción .................................................. .................................... 79

Capítulo 6 6.1 6.2 Continuidad empresarial ................................................ ....................... 85

IV El estándar de grupo abierto (2022)

6.6 The Enterprise Continuum y su organización ........................................... 93

Capítulo 7 7.1 7.2 Repositorio de arquitectura ................................................. ................... 97

Índice................................................. .................................................... ...... 107

1-1 Relaciones entre entregables, artefactos y

Estándar TOGAF® — Arquitectura Contenido v

6-1 Continuum empresarial ............................................... ......................... 86

vi El estándar de grupo abierto (2022)

ÿ Desarrollar y operar el principal servicio de certificación de la industria y alentar las adquisiciones

Más información sobre The Open Group está disponible en www.opengroup.org.

El estándar TOGAF es un marco abierto de consenso de la industria para Enterprise Architecture.

La documentación TOGAF consta de un conjunto de documentos:

ÿ El estándar TOGAF, que describe el enfoque generalmente aplicable a empresas y TI.

TOGAF® Standard — Arquitectura viii

Este es el estándar TOGAF: contenido de arquitectura.

viii The Open Group Standard (2022)

CMMI es una marca registrada de CMMI Institute.

Energistics es una marca registrada de Energistics en los Estados Unidos.

ITIL, MSP y PRINCE2 son marcas registradas de AXELOS Limited.

Zachman es una marca registrada de Zachman International, Inc.

TOGAF® Standard — Arquitectura ix

X The Open Group Standard (2022)

ÿ Un entregable es un producto de trabajo que se especifica contractualmente y, a su vez, formalmente

ÿ Un artefacto es un producto de trabajo arquitectónico que describe un aspecto de la arquitectura .

ÿ Un componente básico representa un componente potencialmente reutilizable de la capacidad empresarial que

TOGAF® Standard — Arquitectura 1

Visión general Introducción

Artefactos y bloques de construcción Edificio reutilizable

Artefactos Matrices Matrices

Bloques de construcción Bloques de construcción

Figura 1-1 Relaciones entre entregables, artefactos y bloques de construcción

2 The Open Group Standard (2022)

Introducción Visión general

Artefacto: Los artefactos describen bloques de construcción

Los entregables contienen artefactos

Figura 1-2 Ejemplo: documento de definición de arquitectura

1.2 Marco de contenido TOGAF y metamodelo empresarial

ÿ Los artefactos específicos a desarrollar (ver Capítulo 4)

Es probable que el marco de contenido elegido se vea influenciado por:

ÿ El Marco de Arquitectura seleccionado como base para la Arquitectura Empresarial

ÿ La herramienta de software elegida utilizada para respaldar la capacidad de arquitectura empresarial

TOGAF® Standard — Arquitectura 3

Marco de contenido TOGAF y metamodelo empresarial Introducción

1.2.2 Marco de contenido

1.2.3 Metamodelo empresarial