Machine Translated by Google

Copia de evaluación

El estándar de grupo abierto

Estándar TOGAF® —Introducción y conceptos básicos

El grupo abierto

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

Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluació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 [Link]/legal/licensing.

El estándar de grupo abierto

Estándar TOGAF® — Introducción y conceptos básicos

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@[Link]

yo The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Contenido

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

Resumen ejecutivo ................................................ ............. 2
1.2 Estructura de este documento .............................................. ..... 6
1.3 Información sobre el uso del estándar TOGAF ....................... 6
1.3.1 Condiciones de Uso ............................................... ............... 6
1.3.2 ¿Cuánto cuesta el estándar TOGAF? ................... 7
1.3.3 Descargas .................................................. .......................... 7
1.4 ¿Por qué unirse al grupo abierto? .................................................. 7

Capítulo 2 2.1 El conjunto de documentación TOGAF ........................... 9

Estructura del Conjunto de Documentación TOGAF ........................ 9
2.2 El estándar TOGAF.................................................... ............ 10
2.3 La Biblioteca TOGAF ............................................... .......... 13

Capítulo 3 3.1 Conceptos básicos .................................................. ................... 15

3.2 ¿Qué es el estándar TOGAF? ............................................... . 15
Qué es la Arquitectura en el Contexto del TOGAF
¿Estándar? .................................................... ........................... 15
3.3 ¿Qué tipo de arquitectura tiene el estándar TOGAF?
¿Tratar con? .................................................... .......................... 15
3.4 Método de desarrollo de la arquitectura ................................. 16
3.5 Servicios de Arquitectura Empresarial .......................................... 18
3.5.1 Servicios de apoyo a empresas .................................. .. 20
3.5.2 Servicios de apoyo al diseño ............................................... ...... 20
3.5.3 Servicios de apoyo al desarrollo .......................................... 20
3.5.4 Obtención y comprensión de requisitos
servicios ................................................ ............................. 20
3.5.5 Servicios de Planificación de Arquitectura ................................ 21
3.5.6 Desarrollo de práctica de arquitectura empresarial
Servicios de apoyo .............................................. .......... 21
3.6 Entregables, artefactos y bloques de construcción .......................... 21
3.7 Abstracción arquitectónica ................................................ ........ 23
3.7.1 Nivel de Abstracción Contextual ............................................. 24
3.7.2 Nivel de abstracción conceptual .......................................... 24
3.7.3 Nivel de abstracción lógica ............................................... .... 24
3.7.4 Nivel de abstracción física .................................................. .. 24
3.8 3.9 Pr incipios de arquitectura ............................................... .......... 24
Interoperabilidad .................................................. ..................... 25

Estándar TOGAF® — Introducción y conceptos básicos iii

© 2005-2022 El Grupo Abierto, Todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Contenido

3.10 Continuum empresarial ............................................... ............ 26

3.11 Repositorio de Arquitectura y ............................................... ......... 27
3.12 TOGAF Content Framework y Enterprise Metamodel ...... 29
3.12.1 Visión general................................................ ............................. 29
3.12.2 Marco de contenido ............................................... ............ 29
3.12.3 Metamodelo empresarial .................................................. ........ 31
3.12.4 Desarrollando el metamodelo empresarial .................................. 32
3.13 Establecimiento y mantenimiento de una empresa
Capacidad de la arquitectura ................................................ .......... 33
3.14 Establecimiento de la capacidad de la arquitectura como un
Entidad Operativa .............................................. .......... 34
3.15 Uso del estándar TOGAF con otros marcos ............ 35
3.16 Uso del marco TOGAF con diferentes
Estilos de arquitectura ................................................ .......... 36
3.17 Arquitectura Vistas y Puntos de Vista ....................................... 37
3.18 Agilidad empresarial ............................................... ..................... 38
3.19 Gestión de riesgos ................................................ .......... 39

Capítulo 4 Definiciones.................................................. .......................... 41

Apéndice A Documentos de referencia ................................................ 55

apéndice B Glosario de Definiciones Suplementarias ................ 61

Apéndice C Abreviaturas.................................................. ..................... 69

Índice................................................. ..................................... 73

Lista de Figuras

2-1 El conjunto de documentación TOGAF .................................................. 9

2-2 Estructura de la Norma TOGAF ............................................. 10
2-3 El estándar TOGAF.................................................... ............... 12
2-4 La Biblioteca TOGAF y Continuum ............................................... .. 14
3-1 Ciclo de Desarrollo de la Arquitectura .......................................... 16
3-2 Relaciones entre entregables, artefactos y
Bloques de construcción ................................................ ......................... 22
3-3 Ejemplo: documento de definición de arquitectura ........... 22
3-4 Continuum empresarial ............................................... ............... 27
3-5 Estructura del repositorio de arquitectura TOGAF .......................... 28
3-6 Marco de contenido por fase ADM .......................................... 30
3-7 Aplicando el Continuo Empresarial ............................................. 32
3-8 El metamodelo TOGAF Core Enterprise ................................ 33
3-9 Visión general de la capacidad de la arquitectura TOGAF .................. 33
3-10 Conceptos básicos de arquitectura .................................................. .... 37

IV El estándar de grupo abierto (2022)

© 2005-2022 El Grupo Abierto, Todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Contenido

Estándar TOGAF® — Introducción y conceptos básicos v

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Prefacio

The Open Group

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 la interoperabilidad, para evolucionar e integrar especificaciones y tecnologías de código
abierto
ÿ Ofrecer un conjunto completo de servicios para mejorar la eficiencia operativa de
consor tia

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

adquisición de productos certificados
Más información sobre The Open Group está disponible en [Link].

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 [Link]/librar y.

Este documento

Este es el estándar TOGAF: introducción y conceptos básicos.

Este documento es parte del estándar TOGAF y proporciona una introducción al estándar, incluida una
descripción general ejecutiva de la arquitectura empresarial, una descripción de cómo está organizado el
estándar y un resumen de los conceptos básicos. También contiene el material común a los documentos
individuales que componen la norma, como las definiciones, así como las referencias y abreviaturas de los
documentos.

vi The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Prefacio

La Documentación TOGAF

El conjunto de documentación TOGAF comprende una cartera de documentos, construidos alrededor del
estándar TOGAF.

El estándar TOGAF® El

estándar TOGAF® es un marco abierto de consenso de la industria para la arquitectura empresarial.

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, una amplia y creciente cartera de
Group TOGAF Librar y, 1 material de orientación, que proporciona

guía práctica en la aplicación del marco TOGAF en contextos específicos.

El estándar TOGAF se presenta como una serie de documentos independientes, pero estrechamente vinculados,
y se complementa con una cartera extensa y creciente de material de orientación, que brinda orientación
práctica en la aplicación del estándar TOGAF en contextos específicos.

El estándar TOGAF es un estándar de The Open Group. The Open Group trabaja con clientes y proveedores
de productos y servicios tecnológicos, y con consorcios y otras organizaciones de estándares para capturar,
aclarar e integrar los requisitos actuales y emergentes, establecer estándares y políticas y compartir las mejores
prácticas. Los estándares garantizan la apertura, la interoperabilidad y el consenso.

En el momento de la publicación, el estándar TOGAF comprende los siguientes documentos:

ÿ Estándar TOGAF — Introducción y conceptos básicos

ÿ Estándar TOGAF: método de desarrollo de arquitectura

ÿ Estándar TOGAF — Técnicas ADM

ÿ Estándar TOGAF — Aplicación del ADM

ÿ Estándar TOGAF — Contenido de la arquitectura

ÿ Estándar TOGAF: capacidad y gobernanza de la arquitectura empresarial

ÿ Estándar TOGAF — Guías de la serie TOGAF (conjunto de documentos)

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.

Otras audiencias son profesionales digitales y ágiles, gerentes de productos y C-Suite. Estas audiencias
encontrarán una guía más detallada sobre cómo aplicar el estándar para satisfacer necesidades específicas en
el conjunto de documentos de las Guías de la serie TOGAF.

1. La Biblioteca TOGAF es un recurso de acceso público ubicado en [Link]/togaf-library.

Estándar TOGAF® — Introducción y conceptos básicos viii

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Prefacio

Palabras clave

arquitectura, marco de arquitectura, método de desarrollo de arquitectura, arquitecto, arquitectura de

empresa, arquitectura de empresa, marco de arquitectura de empresa, método de arquitectura de
empresa, método, métodos, abierto, grupo, modelo de referencia técnica, biblioteca de normas

viii The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Marcas registradas

ArchiMate, DirecNet, Making Standards Work, el logotipo de Open O, el logotipo de Open O y 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, construcción con integridad Compre con confianza,
Arquitectura de referencia de aviación comercial, Confiabilidad 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 El logotipo de SOSA son marcas registradas de The Open Group.
CMMI es una marca registrada de CMMI Institute.
COBIT es una marca registrada de la Asociación de Auditoría y Control de Sistemas de Información (ISACA)
y el Instituto de Gobernanza de TI.
FICO es una marca registrada de Fair Isaac Corporation en los Estados Unidos y otros países.

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.
Java es una marca comercial registrada de Oracle y/o sus filiales.
MDA, Model-Driven Architecture, Object Management Group, OMG, SysML y UML son marcas registradas
y BMM, BPMN, Business Motivation Model, Business Process Modeling Notation, ITPMF, IT Portfolio
Management Facility, SPEM, Systems Modeling Language y Unified Modeling Language son marcas
registradas de Object Management Group.
Merriam-Webster Collegiate Dictionary es una marca registrada de Merriam-Webster, Incorporated.

OASIS es una marca registrada de OASIS, el consorcio de estándares abiertos.

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.

Estándar TOGAF® — Introducción y conceptos básicos ix

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Participantes

El estándar TOGAF, décima edición, fue preparado por The Open Group Architecture Forum.
Cuando The Open Group aprobó este estándar para su publicación en abril de 2022, los Oficiales del Foro de Arquitectura
eran los siguientes:

Mick Adams, EY, copresidente

Paul Homan, IBM, copresidente (2018-2021)
Céline Lescop, AXA, copresidenta (desde marzo de 2021)
Sonia González, The Open Group, Gerente de Producto TOGAF
Mark Dickson, The Open Group, Director del Foro de Arquitectura
Daniel Hutley, The Open Group, Director del Foro de Arquitectura

Revisores técnicos del foro de arquitectura

Los revisores técnicos son aquellas personas que enviaron comentarios durante la revisión de la empresa o que participaron
en una reunión de resolución de problemas durante el desarrollo del estándar TOGAF, 10.ª edición (dispuestos en orden
alfabético).

(Tenga en cuenta que las afiliaciones estaban vigentes en el momento de la aprobación).

ÿ Adam Art, Tecnologías Raytheon ÿ Graham

Berrisford, Avancier

ÿ Terence Blevins, Enterprise Wise LLC y miembro de The Open Group

ÿ Ken Block, Tecnologías Raytheon ÿ Steve

Dupont, Boeing

ÿ Ivan Eikenberry, Raytheon Technologies ÿ Chr is

Forde, Vicepresidente de Arquitectura Empresarial, The Open Group ÿ Mats Gejnevall, Biner

Consulting ÿ David Gilmour, Mundo Cognito ÿ Susan Gottschlich, Raytheon Technologies ÿ

Heidi Hasz, Global Knowledge Training LLC

ÿ Judith Jones, ATE Enterprises ÿ Andrew

Josey, vicepresidente de estándares y certificación, The Open Group ÿ Rolf Knoll,

Novatec Consulting GmbH

ÿ Br yan Lail, Raytheon Technologies

X The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Participantes

ÿ Mike Lambert, miembro de The Open Group

ÿ Frédér ic Lé, DXC
ÿ Seshu Madabhushi, Tata Consultancy
ÿ Stephen Marshall, IBM
ÿ Terence McKiernan, Tecnologías Raytheon
ÿ Jon McLeod, EA Learning Pty Ltd.
ÿ Marc Perna, Raytheon Technologies
ÿ David Pham, Tecnologías Raytheon
ÿ Luke Ranck, Tecnologías Raytheon
ÿ James Renfro, Tecnologías Raytheon
ÿ G. Edward Roberts, Elparazim
ÿ Naveen Sharma, Tecnologías HCL
ÿ Ralph Shaw, Tecnologías Raytheon
ÿ Dir k Vollmerhaus, Scape Consulting GmbH
ÿ Robert t Weisman, Construir la visión
ÿ Mark Whitbread, Raytheon Technologies

Miembros del Foro de Arquitectura

Puede encontrar una lista actualizada de los miembros del Foro en: [Link]/architecture.

Estándar TOGAF® — Introducción y conceptos básicos xi

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Agradecimientos

The Open Group agradece a The Open Group Architecture Forum por desarrollar el estándar TOGAF.

The Open Group agradece la importante contribución a la evolución de esta versión del estándar TOGAF por parte de
Mike Lambert, miembro de The Open Group y Paul Homan,
IBM.

El Open Group reconoce con gratitud a los miembros pasados y presentes del Foro de Arquitectura que se han
desempeñado como oficiales (presidentes y vicepresidentes) desde su creación. En orden alfabético:

mick adams Céline Lescop

Chr ister Askerfjord Stuar T Macgregor
Terence Blevins Ian McCall
Bill Estrem Tara pagador
hugo pescador Barry Smith
Chr es Forde walter stahlecker
Chr es Greenslade sheena thompson
Ed Harrington Paul van der Merwe
Pedro Haviland Dave Van Gelder
Pablo Homán Jane Varnus
Dave Hornford Vish Viswanathan
david jackson rober t weisman
mike lambert hal wilson

xi The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Capítulo 1 Introducción

El estándar TOGAF es un marco para la arquitectura empresarial. Puede ser utilizado libremente por cualquier organización que
desee desarrollar una Arquitectura Empresarial para su uso dentro de esa organización (consulte la Sección 1.3.1).

El estándar TOGAF es desarrollado y mantenido por miembros de The Open Group, que trabajan dentro del Architecture Forum
(consulte [Link]/architecture). El desarrollo original de TOGAF Versión 1 en 1995 se basó en el marco de arquitectura
técnica para la gestión de la información (TAFIM), desarrollado por el Departamento de Defensa de EE. UU. (DoD). El DoD otorgó
a The Open Group permiso explícito y aliento para crear la Versión 1 del estándar TOGAF basándose en TAFIM, que en sí mismo
fue el resultado de muchos años de esfuerzo de desarrollo y muchos millones de dólares de inversión del gobierno de EE. UU.

A partir de esta sólida base, los miembros del Foro de Arquitectura de The Open Group han desarrollado versiones sucesivas del
estándar TOGAF y publicado cada una en el sitio web público de The Open Group.

Esta versión se basa en versiones anteriores del estándar TOGAF y actualiza el material disponible para los profesionales de la
arquitectura para ayudarlos a construir una arquitectura empresarial sostenible. El trabajo en documentos técnicos y guías que
describen cómo integrar y usar este estándar con otros marcos y estilos arquitectónicos ha resaltado las partes del marco universal
del estándar, así como la industria, el estilo de arquitectura y las herramientas, técnicas y orientación específicas. . Este trabajo
está incorporado en la Biblioteca TOGAF.
1

Aunque toda la documentación TOGAF funciona en conjunto, se espera que las organizaciones la personalicen durante la adopción
y elijan deliberadamente algunos elementos, personalicen algunos, excluyan algunos y creen otros. Por ejemplo, una organización
puede desear adoptar el metamodelo TOGAF, pero optar por no utilizar ninguna de las guías sobre cómo desarrollar una
arquitectura tecnológica interna porque son grandes consumidores de servicios en la nube.

Se recomienda leer primero la Descripción general ejecutiva (consulte la Sección 1.1), que incluye un resumen de la comprensión
de The Open Group de la arquitectura empresarial y respuestas a preguntas fundamentales, como
como:

ÿ ¿Por qué se necesita una arquitectura empresarial?

ÿ ¿Por qué utilizar el estándar TOGAF como marco para la arquitectura empresarial?

1. La Biblioteca TOGAF proporciona una lista estructurada disponible públicamente en línea de Guías, Libros Blancos y otros recursos. Consulte TOGAF
Biblioteca en [Link]/togaf-library.

Estándar TOGAF® — Introducción y conceptos básicos 1

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Resumen ejecutivo Introducción

1.1 Resumen ejecutivo

Esta sección proporciona una descripción general ejecutiva de la arquitectura empresarial, los conceptos básicos de lo
que es (no solo otro nombre para la arquitectura de TI) y por qué es necesaria. Brinda un resumen de los beneficios de
establecer una arquitectura empresarial y adoptar el enfoque TOGAF para lograrlo.

¿Qué es una empresa?

El estándar TOGAF considera que una "empresa" es cualquier conjunto de organizaciones que tienen objetivos comunes.

Por ejemplo, un premio de entrada podría ser:

ÿ Toda una corporación o una división de una corporación

ÿ Una agencia gubernamental o un solo departamento gubernamental

ÿ Una cadena de organizaciones geográficamente distantes unidas entre sí por una propiedad común ÿ

Grupos de países, gobiernos u organizaciones gubernamentales (como las fuerzas armadas) que trabajan juntos
para crear productos o infraestructuras comunes o compartibles

ÿ Asociaciones y alianzas de empresas que trabajan juntas, como un consorcio o suministro

cadena

El término "Empresa" en el contexto de "Arquitectura empresarial" se puede aplicar a una empresa completa, que abarca
todas sus actividades comerciales y capacidades, información y tecnología que conforman toda la infraestructura y el
gobierno de la empresa. empresa, o a una o más áreas específicas de interés dentro de la empresa. Una empresa puede
incluir socios, proveedores y clientes, así como unidades de negocios internas. En todos los casos, la arquitectura cruza
múltiples sistemas y múltiples grupos funcionales dentro de la empresa.

El concepto de modelo operativo empresarial es útil para determinar la naturaleza y el alcance de la arquitectura
empresarial dentro de una organización. Muchas organizaciones pueden comprender varias empresas y pueden
desarrollar y mantener una serie de arquitecturas empresariales independientes para abordar cada una. Estas empresas
a menudo tienen mucho en común entre sí, incluidos los procesos, las funciones y sus sistemas de información, y a
menudo existe un gran potencial para obtener ganancias más amplias en el uso de un marco de arquitectura común. Por
ejemplo, un marco común puede proporcionar una base para el desarrollo de bloques de construcción y soluciones
comunes, y un repositorio de arquitectura compartible para la integración y reutilización de modelos comerciales, diseños,
información y datos.

¿Por qué es necesaria una Arquitectura Empresarial?

El propósito de Enterprise Architecture es optimizar en toda la empresa el legado de procesos (tanto manuales como
automatizados) a menudo fragmentado en un entorno integrado que responda al cambio y apoye la entrega de la
estrategia comercial.

La gestión y explotación eficaz de la información y la Transformación Digital son factores clave para el éxito empresarial
y medios indispensables para lograr una ventaja competitiva. Una arquitectura empresarial aborda esta necesidad al
proporcionar un contexto estratégico para la evolución y el alcance de la capacidad digital en respuesta a las necesidades
en constante cambio del entorno empresarial.

Además, una buena arquitectura empresarial le permite lograr el equilibrio adecuado entre la transformación empresarial
y la eficiencia operativa continua. Permite unidades de negocio individuales

2 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Introducción Resumen ejecutivo

para innovar de manera segura en su búsqueda de objetivos comerciales en evolución y ventajas competitivas. Al mismo tiempo,
Enterprise Architecture permite satisfacer las necesidades de la organización con una estrategia integrada que permite las sinergias
más cercanas posibles en toda la empresa y más allá.

Y, por último, gran parte de la legislación mundial sobre privacidad exige que los procesos en torno a los datos personales estén
completamente documentados de una manera que los lectores no capacitados puedan entender fácilmente, como los interesados,
los jueces y los abogados. Las sanciones por no tener esto pueden ser muy significativas. Claramente, la creación de esta
documentación básica surge de las consideraciones fundamentales cambiadas y esto ahora es crucial.

¿Cuáles son los beneficios de una Arquitectura Empresarial?

Una arquitectura empresarial eficaz puede aportar importantes beneficios a la organización. Los beneficios potenciales de una
arquitectura empresarial incluyen:

ÿ Toma de decisiones estratégicas más eficaz por parte de ejecutivos de nivel C y líderes empresariales:

— Respuesta rápida al cambio y soporte para la agilidad empresarial alineada con el

estrategia de organización

— Transformación organizacional, adoptando nuevas tendencias en negocios y tecnología

— Cambio organizativo para apoyar la Transformación Digital

— Cambios en el modelo organizativo y operativo para mejorar la eficiencia y la eficacia

ÿ Operaciones comerciales más eficaces y eficientes:

— Menores costos de operación comercial

— Organización más ágil

— Capacidades comerciales compartidas en toda la organización

— Menores costes de gestión del cambio

— Mano de obra más flexible

— Mejora de la productividad empresarial

— Mejora de la integración de la organización en apoyo de fusiones y adquisiciones.

ÿ Transformación digital y operaciones más efectivas y eficientes:

— Extender el alcance efectivo de la empresa (p. ej., a través de la capacidad digital)

— Llevar todos los componentes de la empresa a un entorno armonizado

— Menores costos de desarrollo, implementación, operaciones, soporte y mantenimiento

— Interoperabilidad mejorada

— Gestión mejorada del sistema

— Capacidad mejorada para abordar problemas críticos de toda la empresa (p. ej., seguridad)

— Actualización e intercambio más sencillos de los componentes del sistema

Estándar TOGAF® — Introducción y conceptos básicos 3

© 2005-2022 The Open Group, todos los derechos reservados Copia
de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Resumen ejecutivo Introducción

ÿ Mejor retorno de la inversión existente, menor riesgo para futuras inversiones:

— Reducción de la complejidad en el negocio y TI

— Rentabilidad maximizada de la inversión en negocios y TI existentes

— La flexibilidad para fabricar, comprar o subcontratar soluciones comerciales y de TI

— Comprender cómo cambia el retorno de la inversión con el tiempo

ÿ Adquisiciones más rápidas, sencillas y económicas:

— Las decisiones de compra son más sencillas, porque la información que rige la contratación está fácilmente
disponible en un plan coherente

— El proceso de adquisición es más rápido: maximiza la velocidad y la flexibilidad de la adquisición sin sacrificar
la coherencia arquitectónica

— La capacidad de adquirir sistemas abiertos heterogéneos de múltiples proveedores

— La capacidad de asegurar más capacidades económicas

¿Qué impulsaría específicamente el desarrollo de una Arquitectura Empresarial?

Las razones para embarcarse en una revisión o desarrollo de Enterprise Architecture son variadas, entre ellas:

ÿ Iniciativas impulsadas por el negocio para permitir la transformación del negocio; por ejemplo, para aprovechar los
servicios y productos digitales como activos generadores de ingresos

ÿ Iniciativas impulsadas por la tecnología para la eficiencia y la reducción de costos; por ejemplo, iniciativas de
consolidación de tecnología, donde el destino de consolidación puede ser físico, virtual o una combinación

ÿ Fusión o adquisición, donde el retorno de la inversión solo se realiza después de la tecnología

se realizan eficiencias

ÿ Gestión de la deuda técnica acumulada por iniciativas de desarrollo ágil

En todas estas situaciones, se necesita la revisión o el desarrollo de la arquitectura empresarial para gestionar la
complejidad cuando el cambio involucra múltiples sistemas con múltiples interdependencias.

A menudo, las personas clave identifican las áreas de cambio necesarias para cumplir los nuevos objetivos comerciales.
Estas personas se conocen comúnmente como las "partes interesadas" en el cambio. El papel del arquitecto es abordar
sus preocupaciones mediante:

ÿ Identificar y refinar los requisitos de las partes interesadas ÿ Desarrollar

vistas de la arquitectura que muestren cómo se abordarán las inquietudes y los requisitos

ÿ Mostrar las ventajas y desventajas que se van a realizar al reconciliar los elementos potencialmente conflictivos
preocupaciones de las diferentes partes interesadas

Sin la arquitectura empresarial, es muy poco probable que se consideren y cumplan todas las inquietudes y requisitos.

4 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Introducción Resumen ejecutivo

¿Qué es un marco de arquitectura?

Un marco de arquitectura es una estructura fundamental, o un conjunto de estructuras, que se pueden utilizar para
desarrollar una amplia gama de arquitecturas diferentes. Debe incluir un método para describir tanto el estado de referencia
como el objetivo de la empresa, en términos de un conjunto de componentes básicos para mostrar cómo encajan los
componentes básicos y planificar la evolución desde la línea de base hasta los estados objetivo.

Un marco generalmente se adapta para satisfacer las necesidades específicas de la organización. La adaptación del marco
debe establecer un conjunto de herramientas y un vocabulario común.

¿Por qué utilizar el estándar TOGAF como marco para la arquitectura empresarial?

El estándar TOGAF se ha desarrollado a través de los esfuerzos de colaboración de toda la comunidad. El uso del estándar
TOGAF da como resultado una arquitectura empresarial que es consistente, refleja las necesidades de las partes
interesadas, emplea las mejores prácticas y da la debida consideración tanto a los requisitos actuales como a las
necesidades futuras percibidas del negocio.

Desarrollar y mantener una arquitectura empresarial es un proceso técnicamente complejo que involucra a muchas partes
interesadas y procesos de decisión en la organización. El estándar TOGAF juega un papel importante en la estandarización
y elimina los riesgos del proceso de desarrollo de la arquitectura. El estándar TOGAF proporciona un marco de mejores
prácticas para agregar valor y permite a la organización crear soluciones viables y económicas que aborden sus problemas
y necesidades comerciales.

La propuesta de valor del estándar TOGAF es permitir que las organizaciones operen de manera eficiente y efectiva
utilizando un conjunto de mejores prácticas probadas y reconocidas, en toda la empresa y en diferentes sectores para
abordar tendencias comerciales y tecnológicas específicas.

Una consideración clave es que la orientación proporcionada por el estándar está destinada a adaptarse para abordar
diferentes necesidades y casos de uso particulares. Eso significa que se puede utilizar para crear una arquitectura
empresarial sostenible para una amplia gama de casos de uso, incluidas las empresas ágiles y la transformación digital.

¿Quién se beneficiaría del uso del estándar TOGAF?

Cualquier organización que emprenda, o planee emprender, el desarrollo y la implementación de una arquitectura
empresarial para respaldar la transformación empresarial se beneficiará del uso del estándar TOGAF.

Las organizaciones que buscan Boundaryless Information Flow™ pueden usar el estándar TOGAF para definir e
implementar las estructuras y procesos para permitir el acceso a información integrada dentro y entre empresas.

Las organizaciones que diseñan e implementan arquitecturas empresariales utilizando el estándar TOGAF tienen la
garantía de un diseño y una especificación de adquisiciones que pueden facilitar la implementación de sistemas abiertos,
lo que permite los beneficios de los sistemas abiertos con un riesgo reducido.

Organizaciones que necesitan adaptarse para afrontar nuevos retos de negocio y mercado, para mejorar las propuestas
de valor a sus clientes como parte de la Transformación Digital.

Estándar TOGAF® — Introducción y conceptos básicos 5

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Resumen ejecutivo Introducción

¿Cuándo se debe hacer Arquitectura Empresarial?

Para obtener el mayor beneficio de Enterprise Architecture, debe hacerse temprano y durante todo el proceso de cambio
para ayudar a los tomadores de decisiones a comprender las implicaciones de sus decisiones.
Sin esta comprensión, se pueden cometer errores costosos y Enterprise Architecture no está sirviendo todo su potencial.
La arquitectura empresarial hecha después de que se toman las decisiones es simplemente la documentación de esas
decisiones o, en el mejor de los casos, la aplicación de esas decisiones. No se obtiene información sobre el efecto de
esas decisiones que podrían ser de gran alcance y quizás perjudiciales.

1.2 Estructura de este Documento

Este documento presenta el estándar TOGAF y la biblioteca TOGAF, e incluye definiciones y materiales de referencia
relevantes para los elementos individuales del estándar.

ÿ Este capítulo proporciona una introducción general a Enterprise Architecture y TOGAF.

Estándar

ÿ El Capítulo 2 describe:

— El alcance y la estructura de los materiales que componen el Estándar TOGAF

— El alcance y la estructura de la Biblioteca TOGAF

ÿ El Capítulo 3 describe los conceptos básicos que se utilizan en los componentes del
Estándar TOGAF

ÿ El Capítulo 4 contiene definiciones de términos que se usan de manera uniforme en todos los componentes.
de la Norma TOGAF

ÿ El Apéndice A contiene una lista de documentos a los que se hace referencia en el estándar

TOGAF. ÿ El Apéndice B contiene una lista complementaria de definiciones de términos que pueden encontrarse.
al leer los materiales que componen el Estándar TOGAF

ÿ El Apéndice C contiene una lista de abreviaturas de uso común

1.3 Información sobre el uso del estándar TOGAF

1.3.1 Condiciones de uso

El estándar TOGAF está disponible gratuitamente para su visualización en línea sin licencia. Alternativamente, se puede
descargar y almacenar bajo licencia, como se explica en el sitio web de información TOGAF.

En cualquier caso, el estándar TOGAF puede ser utilizado libremente por cualquier organización que desee hacerlo
para desarrollar una arquitectura para uso dentro de esa organización. Ninguna parte de este 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, para cualquier otro propósito, incluidos, entre otros, cualquier uso con fines
comerciales, sin el permiso previo de los propietarios de los derechos de autor.

6 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Introducción Información sobre el uso del estándar TOGAF

1.3.2 ¿Cuánto cuesta el estándar TOGAF?

The Open Group se compromete a brindar una mayor eficiencia comercial al reunir a compradores y proveedores de sistemas de
información para reducir las barreras de integración de nuevas tecnologías en toda la empresa. Su objetivo es hacer realidad la
visión del flujo de información sin límites.

El estándar TOGAF es una parte clave de su estrategia para lograr este objetivo, y The Open Group quiere que se adopte y utilice
en proyectos prácticos de arquitectura, y que la experiencia de su uso se retroalimente para ayudar a mejorarlo.

Por lo tanto, Open Group lo publica en su servidor web público y permite y fomenta su reproducción y uso de forma gratuita por
parte de cualquier organización que desee utilizarlo internamente para desarrollar una arquitectura empresarial. (Sin embargo,
existen restricciones sobre su uso comercial; consulte la Sección 1.3.1.)

1.3.3 Descargas

Las descargas del estándar TOGAF, incluidos los archivos PDF imprimibles, están disponibles bajo licencia en el sitio web de
información TOGAF (consulte [Link]/togaf/downloads). La licencia es gratuita para cualquier organización que desee
utilizar el estándar en su totalidad para fines internos (por ejemplo, para desarrollar una arquitectura empresarial para uso dentro de
esa organización).

1.4 ¿Por qué unirse al grupo abierto?

Las organizaciones que deseen reducir el tiempo, el costo y el riesgo de implementar soluciones de múltiples proveedores que se
integren dentro y entre las empresas necesitan The Open Group como su socio clave.

Open Group reúne a compradores y proveedores de sistemas de información en todo el mundo y les permite trabajar juntos, tanto
para garantizar que las soluciones de TI satisfagan las necesidades de los clientes como para facilitar la integración de TI en toda la
empresa. El estándar TOGAF es un habilitador clave en esta tarea.

Sí, el estándar TOGAF está disponible gratuitamente. Pero, ¿cuánto gastará en desarrollar o actualizar su arquitectura empresarial?
¿Y cuánto gastará en adquisiciones basadas en esa arquitectura? El precio de la membresía de The Open Group es insignificante
en comparación con estas cantidades.

Además de los beneficios generales de la membresía, como miembro de The Open Group, podrá participar en The Open Group
Architecture Forum, que es el programa de desarrollo dentro del cual se desarrolla el estándar TOGAF y en el que se reúnen los
usuarios de TOGAF. para intercambiar información y retroalimentación. Los miembros del Foro de Arquitectura ganan:

ÿ Acceso inmediato a los frutos del programa de trabajo actual de TOGAF (no disponible públicamente hasta la publicación de
la próxima edición del estándar TOGAF); en efecto, la información más reciente sobre el estándar.

ÿ Intercambio de experiencias con otras organizaciones de clientes y proveedores involucradas en

Empresa de arquitectura en general y trabajo en red con arquitectos que utilizan TOGAF
Estándar en importantes proyectos de desarrollo de arquitectura en todo el mundo

ÿ Revisión por pares de material de estudio de caso de arquitectura específico

Estándar TOGAF® — Introducción y conceptos básicos 7

© 2005-2022 The Open Group, todos los derechos reservados Copia
de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Introducción

8 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Capítulo 2: El conjunto de documentación TOGAF

2.1 Estructura del conjunto de documentación TOGAF

El conjunto de documentación TOGAF consta de una cartera de documentos ilustrados en la Figura 2-1.

Figura 2-1 Conjunto de documentación TOGAF

Estándar TOGAF® — Introducción y conceptos básicos 9

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Estructura del conjunto de documentación TOGAF El conjunto de documentación TOGAF

El estándar TOGAF

El estándar TOGAF describe el enfoque generalmente aplicable a la arquitectura empresarial y de TI. Se presenta como
una serie de documentos independientes, pero estrechamente vinculados, como se muestra en la Figura 2-1.

El estándar TOGAF es un estándar de The Open Group. The Open Group trabaja con clientes y proveedores de
productos y servicios tecnológicos, y con consorcios y otras organizaciones de estándares para capturar, aclarar e
integrar los requisitos actuales y emergentes, establecer estándares y políticas y compartir las mejores prácticas. Los
estándares garantizan la apertura, la interoperabilidad y el consenso.

La Biblioteca TOGAF La

Biblioteca TOGAF es una cartera de material de orientación adicional, que respalda la aplicación práctica del enfoque
TOGAF.

2.2 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 que brinda orientación práctica en la aplicación del marco TOGAF en contextos
específicos.
La estructura del Estándar TOGAF refleja la estructura y el contenido de una Capacidad de Arquitectura dentro de una
empresa, como se muestra en la Figura 2-2.

10 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

El conjunto de documentación TOGAF El estándar TOGAF

Figura 2-2 Estructura del estándar TOGAF

El contenido fundamental del estándar TOGAF se presenta en seis documentos independientes:

ÿ El estándar TOGAF — Introducción y conceptos básicos (este documento)

ÿ El estándar TOGAF: método de desarrollo de arquitectura

Este documento describe el método de desarrollo de arquitectura TOGAF (ADM), un enfoque iterativo para
desarrollar una arquitectura empresarial.

ÿ El estándar TOGAF — Técnicas ADM

Este documento contiene una colección de técnicas disponibles para su uso en la aplicación del enfoque TOGAF y
TOGAF ADM.

ÿ El estándar TOGAF — Aplicación del ADM

Este documento contiene pautas para adaptar TOGAF ADM para abordar el estilo de arquitectura específico
requerido en un contexto práctico.

ÿ El estándar TOGAF: contenido de la arquitectura

Este documento describe el marco de contenido TOGAF y un metamodelo estructurado para artefactos
arquitectónicos, el uso de bloques de construcción de arquitectura (ABB) reutilizables y una descripción general de
los entregables típicos de la arquitectura.

Estándar TOGAF® — Introducción y conceptos básicos 11

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

El estándar TOGAF El conjunto de documentación TOGAF

ÿ El estándar TOGAF: capacidad y gobernanza de la arquitectura empresarial

Este documento analiza la organización, los procesos, las habilidades, los roles y las responsabilidades
necesarios para establecer y operar una función de arquitectura dentro de una empresa y describe un marco de
gobierno de arquitectura empresarial.

La intención de dividir el Estándar TOGAF en estos documentos independientes es permitir que las diferentes áreas de
especialización se consideren en detalle y potencialmente se aborden de forma aislada.
Aunque todos los documentos constitutivos funcionan juntos como un todo, también es factible seleccionar documentos
particulares para su adopción y excluir otros. Por ejemplo, una organización puede desear adoptar el proceso ADM,
pero optar por no utilizar ninguno de los materiales relacionados con Capacidad de arquitectura. Como marco abierto,
se recomienda dicho uso, en particular en las siguientes situaciones:

ÿ Organizaciones que son nuevas en el enfoque TOGAF y desean adoptar gradualmente

Se espera que los conceptos TOGAF se centren en documentos constituyentes particulares del estándar para
su adopción inicial, con otras áreas presentadas para su consideración posterior.

ÿ Las organizaciones que ya han implementado marcos de arquitectura pueden optar por fusionarse
estos marcos con aspectos del estándar TOGAF

El estándar TOGAF comprende el contenido fundamental de TOGAF y una colección de guías de la serie TOGAF, que
brindan orientación práctica en la aplicación del estándar TOGAF.

La Figura 2-3 muestra la estructura y el alcance del estándar TOGAF.

Figura 2-3 El estándar TOGAF

,
Además del contenido del marco central cubierto por los seis documentos explicados anteriormente, el estándar brinda
orientación para abordar inquietudes específicas y casos de uso a través de las Guías de la serie TOGAF.

Las guías de la serie TOGAF están diseñadas para satisfacer las necesidades más específicas de los profesionales
que necesitan más explicaciones o más detalles que los proporcionados en el contenido principal.

No todas las guías de la serie TOGAF serán relevantes en todas las situaciones. Sin embargo, ingrese el premio

12 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

El conjunto de documentación TOGAF El estándar TOGAF

Los arquitectos que estén planeando la implementación del estándar TOGAF deben conocer la guía disponible.

Este contenido evolucionará más rápidamente que el contenido principal para cubrir nuevas necesidades a medida que
surjan de las tendencias del mercado y las necesidades de la industria. Hay un conjunto de actividades que se ejecutan
continuamente en The Open Group Architecture Forum para entregar este contenido siguiendo una canalización de
entrega continua e incremental.

Ejemplos de las áreas cubiertas por este material de orientación son:

ÿ Toma de decisiones estratégicas y decisiones orientadas al valor empresarial

ÿ Arquitectura empresarial y descripción del modelo operativo

ÿ Gestión de información y datos ÿ Guía del

sistema de información ÿ Modelos de

referencia de información y modelos de integración de datos

ÿ Arquitectura tecnológica: cómo se puede aplicar la arquitectura empresarial como práctica para adoptar nuevas
tendencias tecnológicas para evaluar si la organización posee las capacidades adecuadas para respaldar la
adopción de nuevas tecnologías

ÿ Arquitectura de seguridad: cómo se puede aplicar el estándar TOGAF para brindar y brindar soporte
Arquitectura de seguridad y gestión de riesgos

ÿ Cómo se puede aplicar la arquitectura empresarial como práctica y el estándar TOGAF para respaldar la empresa
ágil, para que se entregue siguiendo un estilo ágil, y cómo el estándar puede respaldar a las organizaciones que
utilizan metodologías ágiles

ÿ Cómo la arquitectura empresarial como práctica y el estándar TOGAF respaldan la empresa digital para que las
organizaciones puedan entregar productos digitales y mejorar su oferta digital y su propuesta de valor digital

ÿ Cómo se puede aplicar el estándar con otros estándares y metodologías de The Open
Grupo como el estándar O-AA™ , el estándar DPBoK™ , la referencia IT4IT™
Arquitectura, la especificación ArchiMate®, la arquitectura de microservicios (MSA), los estándares de seguridad
y también con los estándares y las mejores prácticas de otros organismos de estándares.

de TOGAF Series Guides puede El conjunto completo

[Link]/librar y/guides/togaf/togaf-series-guides. ser encontrado a

2.3 La biblioteca TOGAF El estándar

TOGAF está acompañado por una amplia cartera de material de orientación, conocida como biblioteca TOGAF, para
2
respaldar la aplicación pautas,
prácticaplantillas,
del enfoquepatrones
TOGAF.y otras
La Biblioteca
formas deTOGAF
material
esde
una
referencia
biblioteca
para
de referencia
acelerar laque
creación
contiene
de
nuevas arquitecturas para la empresa.

La Biblioteca TOGAF se mantiene bajo el gobierno de The Open Group Architecture Forum.

La biblioteca TOGAF es compatible con una de las clases de información del repositorio de arquitectura empresarial
TOGAF, la biblioteca de referencia.

2. La Biblioteca TOGAF es un recurso de acceso público ubicado en [Link]/togaf-library.

Estándar TOGAF® — Introducción y conceptos básicos 13

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

La biblioteca TOGAF El conjunto de documentación TOGAF

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.

La biblioteca TOGAF es una biblioteca de referencia de recursos potencialmente útiles. La Biblioteca TOGAF sigue un
modelo de categorización basado en capacidades y funciones que se pueden ofrecer al mercado a través de diferentes
conjuntos de documentos y recursos, como se muestra en la Figura 2-4.

Figura 2-4 Biblioteca TOGAF Continuum

14 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Capítulo 3: Conceptos básicos

A los efectos del estándar TOGAF, se aplican los conceptos básicos proporcionados en este capítulo.

3.1 ¿Qué es el estándar TOGAF?

El estándar TOGAF es un marco de arquitectura. Proporciona los métodos y herramientas para asistir en la aceptación,
producción, uso y mantenimiento de una Arquitectura Empresarial. Se basa en un modelo de proceso iterativo respaldado
por las mejores prácticas y un conjunto reutilizable de activos de arquitectura existentes. Consulte la Sección 2.2.

3.2 ¿Qué es la arquitectura en el contexto del estándar TOGAF?

ISO/IEC/IEEE 42010: 2011 define "arquitectura" como:

"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".

El estándar TOGAF adopta pero no se adhiere estrictamente a la terminología ISO/IEC/IEEE 42010: 2011. Además de la
definición de "arquitectura" ISO/IEC/IEEE 42010: 2011, el estándar TOGAF define un segundo significado según el
contexto:

"La estructura de los componentes, sus interrelaciones y los principios y directrices que rigen su diseño y evolución
a lo largo del tiempo".

El estándar TOGAF considera la empresa como un sistema y se esfuerza por lograr un equilibrio entre la promoción de los
conceptos y la terminología extraídos de los estándares relevantes y la terminología comúnmente aceptada que es familiar
para la mayoría de los lectores de TOGAF. Para obtener más información sobre la terminología, consulte el Capítulo 4 y el
Estándar TOGAF: contenido de la arquitectura.

3.3 ¿Qué tipo de arquitectura trata el estándar TOGAF?

Hay cuatro dominios de arquitectura que se aceptan comúnmente como subconjuntos de un conjunto
Arquitectura empresarial, todo lo cual el estándar TOGAF está diseñado para soportar:

ÿ La Arquitectura Empresarial define la estrategia empresarial, el gobierno, la organización y

procesos clave de negocio

ÿ La arquitectura de datos describe la estructura de los activos de datos físicos y lógicos de una organización y los
recursos de gestión de datos.

Estándar TOGAF® — Introducción y conceptos básicos 15

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

¿Qué tipo de arquitectura trata el estándar TOGAF? Conceptos básicos

ÿ La arquitectura de la aplicación proporciona un modelo para las aplicaciones individuales que se implementarán,
sus interacciones y sus relaciones con los procesos comerciales centrales de la organización.

ÿ La arquitectura tecnológica describe la arquitectura digital y las capacidades y estándares de infraestructura de

software y hardware lógicos que se requieren para respaldar la implementación de servicios comerciales, de datos
y de aplicaciones. Esto incluye servicios digitales, Internet de las cosas (IoT), infraestructura de redes sociales,
servicios en la nube, infraestructura de TI, middleware, redes, comunicaciones, procesamiento, estándares, etc.

Hay muchos otros dominios que podrían definirse mediante la combinación de vistas apropiadas de los dominios de
Negocios, Datos, Aplicaciones y Tecnología. Por ejemplo:

ÿ Arquitectura de la información

ÿ Arquitecturas de riesgo y seguridad

ÿ Arquitectura digital

El marco TOGAF permite la creación de estas vistas multidimensionales y las categoriza para crear dominios específicos
que permiten a una empresa considerar el alcance más amplio de su empresa y capacidades.

3.4 Método de desarrollo de la arquitectura

El método de desarrollo de arquitectura TOGAF (ADM) proporciona un proceso probado y repetible para desarrollar
arquitecturas. El ADM incluye el establecimiento de un marco de arquitectura, el desarrollo de contenido de arquitectura, la
transición y el gobierno de la realización de arquitecturas.

Todas estas actividades se llevan a cabo dentro de un ciclo iterativo de definición y realización continua de la arquitectura
que permite a las organizaciones transformar sus empresas de manera controlada en respuesta a las metas y oportunidades
comerciales. Esto se ilustra en la Figura 3-1.

dieciséis
The Open Group Standard (2022)
© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Conceptos básicos Método de desarrollo de arquitectura

Preliminar

UNA.

Visión de la
arquitectura
h
B.
Gestión de
Arquitectura
cambios de
empresarial
arquitectura

C.
GRAMO.

Requisitos Arquitecturas
Gobernanza de la
administración de Sistemas
implementación
de Información

F. D.
Planificación Arquitectura
de la migración Tecnológica
MI.

Oportunidades y
Soluciones

© El Grupo Abierto

Figura 3-1 Ciclo de desarrollo de la arquitectura

Las fases dentro del ADM son las siguientes:

ÿ La Fase Preliminar describe las actividades de preparación e iniciación necesarias para crear una Capacidad de
Arquitectura, incluida la personalización del marco TOGAF y la definición de los Principios de Arquitectura.

ÿ Fase A: Architecture Vision describe la fase inicial del desarrollo de una arquitectura.
ciclo

Incluye información sobre la definición del alcance de la iniciativa de desarrollo de la arquitectura, la identificación
de las partes interesadas, la creación de la Visión de la arquitectura y la obtención de la aprobación para
continuar con el desarrollo de la arquitectura.

Estándar TOGAF® — Introducción y conceptos básicos 17

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Método de desarrollo de arquitectura Conceptos básicos

ÿ Fase B: Business Architecture describe el desarrollo de una Business Architecture para respaldar la visión de la
arquitectura acordada

ÿ Fase C: Arquitecturas de Sistemas de Información describe el desarrollo de la Información

Arquitecturas de sistemas para apoyar la visión de la arquitectura acordada

ÿ Fase D: Arquitectura Tecnológica describe el desarrollo de la Tecnología

Arquitectura para apoyar la Visión de la Arquitectura acordada

ÿ Fase E: Opportunities & Solutions lleva a cabo la planificación inicial de la implementación y la identificación de
los vehículos de entrega para la arquitectura definida en las fases anteriores.

ÿ Fase F: La planificación de la migración aborda cómo pasar de la línea de base al objetivo

Arquitecturas mediante la finalización de un plan detallado de implementación y migración

ÿ Fase G: Gobernanza de implementación proporciona una supervisión arquitectónica de la

implementación

ÿ Fase H: Gestión de cambios en la arquitectura establece procedimientos para gestionar

cambio a la nueva arquitectura

ÿ Gestión de requisitos opera el proceso de gestión de requisitos de arquitectura en todo el ADM

La descripción de las fases del ADM en el estándar TOGAF — Método de desarrollo de la arquitectura se centra en las
recomendaciones sobre lo que se puede hacer para definir e implementar una arquitectura empresarial.

Puede encontrar orientación sobre cómo hacer lo que se especifica en las Guías de la serie TOGAF (consulte la Sección 2.2). En
el Apéndice A se incluye una lista completa de las guías de la serie TOGAF a las que se hace referencia .

El marco TOGAF recomienda que el ADM se adapte para satisfacer las necesidades de la empresa y admitir diferentes
estilos de arquitectura (consulte la Sección 3.16).

En particular, la ADM no:

ÿ Exigir que las fases se realicen en una secuencia específica

ÿ Exigir un método de "cascada"

El estándar TOGAF describe cómo se puede usar el ADM de forma iterativa para desarrollar un panorama integral de
arquitectura empresarial. En lugar de ver el gráfico de ADM como un modelo de proceso, es útil verlo como un modelo
de referencia que define lo que se debe hacer para brindar soluciones de forma arquitectónica e identifica los componentes
que interactúan en la empresa y las relaciones entre ellos.

3.5 Servicios de arquitectura empresarial

Las actividades descritas en el ADM a menudo se proporcionan a través de un modelo de prestación de servicios. Los
servicios están organizados y presentados en categorías de servicio. Estos servicios abordan necesidades específicas
independientemente del modelo de operación específico de una organización. Cualquier servicio dado descrito utiliza las
actividades apropiadas en el ADM para abordar una necesidad dada.

La Tabla 3-1 resume las categorías de servicios propuestas y proporciona algo de contexto. Las primeras cuatro
categorías están centradas en el cliente y las otras están más centradas internamente en los arquitectos.
Cada categoría de servicio se describe brevemente en las siguientes subsecciones.

18 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Conceptos básicos Servicios de arquitectura empresarial

Tabla 3-1 Categorías y descriptores de servicios

descriptor
Típico Típico
Categorías Cliente Proveedor Entregable(s) Resultado deseado
Centrada en el cliente

Ingresar premio gestión Ingrese a los respuestas a Mejores decisiones

Servicios de apoyo de nivel C analistas de premios usando preguntas empresariales
Ingresar premio
Informes de Menor riesgo
La arquitectura como
evaluación
herramienta
Recomendaciones

Soporte de diseño Tomadores de Ingresar premio MVA (incluidos Mejores decisiones

Servicios Arquitecto
decisiones a nivel de programa estándares y criterios de diseño
constructor/modelador de cumplimiento,
Programas y
hojas de ruta) para
proyectos exitosos
programas

Guía de
cumplimiento

Informes de
cumplimiento
Desarrollo Tomadores de Ingresar premio MVA (incluidos Mejores decisiones
Servicios de apoyo Arquitecto
decisiones a nivel de proyecto estándares y criterios de producto
constructor/modelador de cumplimiento) para
Productos
proyectos/productos
exitosos

Guía de
cumplimiento

Informes de
cumplimiento
Requisitos Producto Ingresar premio Interesado Sólida vista de afuera
Obtención y gerentes Arquitecto con preocupaciones hacia adentro de los
Comprensión especialidad en requisitos y el valor de
Requisitos
Servicios comprensión de las soluciones
requerimientos Evaluaciones equilibradas entre las
(valor, habilidad, etc.) partes interesadas

Interno-céntrico
Arquitectura Líderes de experimentado planos de Equipo de
Planificación equipo de arquitectura Ingresar premio proyectos de arquitectura arquitectura con recursos
Servicios Arquitecto

Estándar TOGAF® — Introducción y conceptos básicos 19

© 2005-2022 The Open Group, todos los derechos reservados Copia
de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Servicios de arquitectura empresarial Conceptos básicos

descriptor
Típico Típico
Categorías Cliente Proveedor Entregable(s) Resultado deseado
Ingresar premio Tomadores de Ingresar premio Ingresar premio Altamente calificado y
Arquitectura decisiones de la Expertos en Arquitectura organizada
Práctica organización de arquitectura
prácticas de arquitecturaCapacidad Ingrese
Desarrollo evaluaciones de premios Organización
Servicios de apoyo de la práctica
Ingresar premio
de arquitectura
Arquitectura
(interna o
externa)
Recomendaciones
de mejora de la capacidad

3.5.1 Servicios de apoyo empresarial

Esta categoría de servicio contiene servicios candidatos que permiten tomar decisiones empresariales informadas en apoyo del
cambio organizacional. Estos servicios podrían proporcionarse independientemente de cualquier proyecto individual. Estos
servicios se enfocan en responder preguntas y proporcionar análisis empresariales en apoyo de las decisiones estratégicas.

3.5.2 Servicios de apoyo al diseño

Esta categoría de servicio contiene servicios candidatos que permiten decisiones de diseño informadas en apoyo del cambio de
la organización. Estos servicios generalmente se brindarían después de que se haya financiado un proyecto, ya sea grande o
pequeño, en cascada o ágil. Estos servicios incluyen el desarrollo de arquitecturas mínimas viables (MVA) y análisis asociados
para respaldar las decisiones de diseño.

3.5.3 Servicios de apoyo al desarrollo

Esta categoría de servicio contiene servicios candidatos que permiten tomar decisiones de desarrollo informadas para respaldar
el cambio de la organización. Estos servicios normalmente se proporcionarían durante la fase de desarrollo de un proyecto, ya
sea grande o pequeño, en cascada o ágil. Estos servicios se enfocan en responder preguntas y proporcionar análisis
empresariales en apoyo de las decisiones de desarrollo.

3.5.4 Servicios de obtención y comprensión de requisitos

Esta categoría de servicio contiene servicios candidatos que permiten la comprensión de los requisitos.
Dando un paso más allá de la gestión de requisitos, estos servicios ayudan a acercarse a la necesidad real que brindará un
mayor valor empresarial.

20 The Open Group Standard (2022) ©

2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Conceptos básicos Servicios de arquitectura empresarial

3.5.5 Servicios de Planificación de la Arquitectura

Esta categoría de servicio contiene servicios candidatos que permiten proyectos de arquitectura bien planificados y
ejecutados para respaldar el cambio de la organización. Estos servicios normalmente se proporcionarían al comienzo
de un "proyecto", ya sea grande o pequeño, en cascada o ágil.

3.5.6 Servicios de apoyo al desarrollo de prácticas de arquitectura empresarial

Esta categoría de servicio contiene servicios candidatos que permiten el desarrollo y la gestión de una práctica de
arquitectura empresarial. Estos servicios se centran en mejorar la capacidad de la arquitectura empresarial.

3.6 Entregables, artefactos y bloques de construcción

Los arquitectos que ejecutan el ADM generarán una serie de resultados como resultado de sus esfuerzos, como flujos
de procesos, requisitos arquitectónicos, planes de proyectos, evaluaciones de cumplimiento de proyectos, etc. El marco
de contenido de arquitectura TOGAF (consulte el estándar TOGAF: contenido de arquitectura) un modelo estructural
para el contenido arquitectónico que permite que los principales productos de trabajo se definan, estructuren y presenten
de manera coherente.

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

revisados, aprobados y firmados por las partes interesadas Los

entregables representan el resultado de los proyectos y los entregables que están en la documentación para m
generalmente se archivarán al finalizar un proyecto, o se trasladarán a un repositorio de arquitectura como un
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 uno o más artefactos y los artefactos formarán el contenido del Repositorio de Arquitectura. Un artefacto
puede o no ser considerado un entregable según la especificación contractual.

ÿ Un bloque de construcción representa un componente potencialmente reutilizable que se puede combinar con
otros bloques de construcción 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".

— Los bloques de construcción de la arquitectura (ABB) suelen describir la capacidad requerida y dan
forma a la especificación de los bloques de construcción de la solución (SBB); por ejemplo, una empresa
puede requerir una capacidad de servicio al cliente, respaldada por muchos SBB, como procesos, datos
y software de aplicación

Estándar TOGAF® — Introducción y conceptos básicos 21

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Entregables, artefactos y bloques de construcción Conceptos básicos

— Los componentes básicos de la solución (SBB) representan los componentes que se utilizarán para
implementar la capacidad requerida; por ejemplo, una red es un bloque de construcción que puede
describirse a través de artefactos complementarios y luego ponerse en uso para realizar soluciones para
la empresa

Las relaciones entre entregables, artefactos y bloques de construcción se muestran en la Figura 3-2.

© 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 3-2 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 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 3-3 se ilustra un ejemplo de las relaciones entre entregables, artefactos y bloques de
construcción .

22 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Conceptos básicos Entregables, artefactos y bloques de construcción

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 Use el diagrama del caso Describe
Bloque de construcción:
Representante de servicios al cliente
Artefacto:
Describe
Describe Use el diagrama del caso
Bloque de construcción:
Proceso de manejo de llamadas objetivo

Describe Artefacto:
Diagrama de flujo del proceso Describe

Los entregables contienen artefactos

© El Grupo Abierto

Figura 3-3 Ejemplo: documento de definición de arquitectura

Los conceptos de entregables, artefactos y bloques de construcción se describen con más detalle en el estándar TOGAF:
contenido de arquitectura.

El estándar TOGAF: técnicas ADM describe el método de desarrollo de la arquitectura e incluye listas resumidas de
entregables y artefactos que se pueden crear en cada fase. El estándar TOGAF: contenido de arquitectura contiene
descripciones detalladas de estos.

3.7 Arquitectura Abstracción

Una técnica arquitectónica para dividir un área problemática en áreas problemáticas más pequeñas que son más fáciles
de modelar y, por lo tanto, más fáciles de resolver.

Los niveles de abstracción están en capas en la naturaleza, pasando de modelos de alto nivel a modelos más detallados.

El esfuerzo de la arquitectura se puede dividir en cuatro niveles distintos de abstracción que cruzan el Negocio,
Dominios de datos, aplicaciones y tecnología para responder preguntas fundamentales sobre una arquitectura:

ÿ ¿Por qué? ¿Por qué se necesita la arquitectura?

ÿ ¿Qué? ¿Qué funcionalidad y otros requisitos debe cumplir la arquitectura?

ÿ ¿Cómo—cómo estructuramos la funcionalidad?

ÿ ¿Con qué — con qué activos implementaremos esta estructura?

Tenga en cuenta que por qué, qué y cómo no tienen conexión con su uso en Zachman® Enterprise .
Marco de arquitectura.

Estándar TOGAF® — Introducción y conceptos básicos 23

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Abstracción de arquitectura Conceptos básicos

3.7.1 Nivel de abstracción contextual

Este nivel de abstracción se centra en comprender el entorno en el que opera una empresa y el contexto en el que se
planifica y ejecuta el trabajo de arquitectura. Responde por qué una empresa emprende un trabajo de arquitectura, cuál es
el alcance del trabajo y la motivación en términos de metas, impulsores y objetivos.

3.7.2 Nivel de abstracción conceptual

Este nivel de abstracción se centra en descomponer los requisitos para comprender el problema y lo que se necesita para
abordar el problema, sin centrarse indebidamente en cómo se realizará la arquitectura. Responde a lo que es necesario
para realizar los requisitos y generalmente se modela utilizando modelos de servicio (servicio comercial, servicio de
aplicación, servicio de tecnología) que representan el comportamiento deseado.

Tenga en cuenta que este nivel de abstracción también puede denominarse abstracción de servicio o abstracción de
comportamiento.

3.7.3 Nivel de abstracción lógica

Este nivel de abstracción se centra en identificar los tipos de componentes de negocio, datos, aplicaciones y tecnología
necesarios para lograr los servicios identificados en el nivel conceptual. Se trata de identificar cómo se puede organizar y
estructurar una arquitectura, de manera independiente a la implementación. Habrá potencialmente varias formas de agrupar
servicios en componentes lógicos, basados en principios y otros criterios de agrupación, proporcionando diferentes
alternativas de solución lógica.

3.7.4 Nivel de abstracción física

Este nivel de abstracción gestiona la asignación e implementación de componentes físicos para cumplir con los componentes
lógicos identificados. Se trata de determinar con qué componentes físicos se pueden realizar los componentes de nivel
lógico. Potencialmente, habrá muchas formas de usar componentes físicos para realizar componentes lógicos, basados en
principios y otros criterios de agrupación, proporcionando diferentes alternativas de solución física.

3.8 Principios de arquitectura

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.

Dependiendo de la organización, los principios pueden establecerse dentro de diferentes dominios y en diferentes niveles.
Dos dominios clave informan el desarrollo y la utilización de la arquitectura:

ÿ Los Principios Empresariales brindan una base para la toma de decisiones en toda la empresa e informan cómo la
organización emprende el cumplimiento de su misión. Dichos principios se encuentran comúnmente como un medio

para armonizar la toma de decisiones en toda la organización. En particular, son un elemento clave en una estrategia
exitosa de Gobernanza de la Arquitectura (ver Estándar TOGAF — Capacidad y Gobernanza de la Arquitectura
Empresarial).

24 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Conceptos básicos Principios de arquitectura

Dentro del amplio dominio de los Principios Empresariales, es común tener principios subsidiarios dentro de una unidad
empresarial o organizacional; por ejemplo, principios específicos de TI, recursos humanos, operaciones nacionales u
operaciones en el extranjero. Estos principios proporcionan una base para la toma de decisiones dentro del dominio
subsidiario e informarán el desarrollo de la arquitectura dentro del dominio. Se debe tener cuidado para garantizar que los
principios utilizados para informar el desarrollo de la arquitectura se alineen con el contexto organizacional de la capacidad
de la arquitectura.

ÿ Los Principios de Arquitectura son un conjunto de principios que se relacionan con el trabajo de arquitectura

Reflejan un nivel de consenso en toda la empresa y encarnan el espíritu y el pensamiento de los Principios empresariales
existentes. Los Principios de Arquitectura gobiernan el proceso de arquitectura, afectando el desarrollo, mantenimiento y
uso de la Arquitectura Empresarial.

Dentro de una empresa, la jerarquía de principios comienza con los Principios de empresa. Los principios del segmento subsidiario
deben existir dentro de los límites de estos Principios empresariales que son generales. En consecuencia, en cada nivel jerárquico,
el conjunto de principios se basará en los principios heredados del nivel superior y se elaborará a partir de ellos, y no podrá traspasar
sus límites.

Los Principios de Arquitectura pueden reafirmar otras guías empresariales en términos y formas que guíen efectivamente el
desarrollo de la arquitectura.

Los Principios de Arquitectura definen las reglas generales subyacentes y las pautas para el uso y la implementación de todos los
recursos y activos en toda la empresa. Reflejan un nivel de consenso entre los diversos elementos de la empresa y forman la base
para tomar futuras decisiones de arquitectura.

Cada Principio de Arquitectura debe estar claramente relacionado con los objetivos comerciales y los impulsores clave de la
arquitectura.

Los principios de arquitectura se explican con más detalle en el estándar TOGAF: técnicas ADM.

3.9 Interoperabilidad
Una definición de interoperabilidad es "la capacidad de compartir información y servicios". Definir el grado en que la información y
los servicios se compartirán o no es un requisito arquitectónico muy útil, especialmente en una organización compleja y/o empresa
extensa.

La determinación de la interoperabilidad está presente en todo el Método de desarrollo de arquitectura (ADM) de la siguiente manera:

ÿ En la Visión de la Arquitectura (Fase A), la naturaleza y las consideraciones de seguridad de los intercambios de información
y servicios se revelan primero dentro de los escenarios comerciales.

ÿ En la Arquitectura Empresarial (Fase B), los intercambios de información y servicios son aún más
definido en términos comerciales

ÿ En la Arquitectura de Datos (Fase C), se detalla el contenido de los intercambios de información utilizando el modelo
corporativo de intercambio de datos y/o información.

ÿ En la Arquitectura de la Aplicación (Fase C), la forma en que las diversas aplicaciones deben
se especifica compartir la información y los servicios

ÿ En la Arquitectura Tecnológica (Fase D), los mecanismos técnicos adecuados para permitir
se especifican los intercambios de información y servicios

Estándar TOGAF® — Introducción y conceptos básicos 25

© 2005-2022 The Open Group, todos los derechos reservados Copia
de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

interoperabilidad Conceptos básicos

ÿ En Oportunidades y Soluciones (Fase E), las soluciones reales (p. ej., Comercial Off-The
Paquetes de estante (COTS)) están seleccionados

ÿ En la Planificación de la Migración (Fase F), la interoperabilidad se implementa lógicamente

Hay muchas formas de definir la interoperabilidad y el objetivo es definir una que se aplique de manera consistente dentro de
la empresa y la empresa extendida. Es mejor que tanto la empresa como la empresa extendida usen las mismas definiciones.

Muchas organizaciones encuentran útil categorizar la interoperabilidad de la siguiente manera:

ÿ La interoperabilidad operativa o comercial define cómo las diferentes partes de la empresa

trabajar juntos a nivel empresarial

ÿ La interoperabilidad de la información define cómo se va a compartir la información. ÿ La

interoperabilidad técnica define cómo se van a compartir los recursos técnicos o al menos
conectarse entre sí

Desde una perspectiva de TI, también es útil considerar la interoperabilidad de manera similar a Enterprise
Integración de aplicaciones (EAI); específicamente:

ÿ Presentación Integración/interoperabilidad es donde un enfoque de apariencia común a través de una solución

similar a un portal común guía al usuario a la funcionalidad subyacente del conjunto de sistemas

ÿ La integración/interoperabilidad de la información es donde la información corporativa es perfecta, por ejemplo, un

compartido entre las diversas aplicaciones corporativas para lograr información , conjunto común
del cliente

Normalmente esto se basa en una ontología corporativa comúnmente aceptada y servicios compartidos para la
estructura, calidad, acceso y seguridad/privacidad de la información.

ÿ La integración/interoperabilidad de aplicaciones es donde la funcionalidad corporativa se integra y se puede

compartir para que las aplicaciones no se dupliquen (p. ej., un cambio de servicio/componente de dirección; no uno
para cada aplicación) y se vinculen a la perfección a través de funcionalidades como el flujo de trabajo. Esto impacta
en las aplicaciones comerciales y de infraestructura y está muy relacionado con la unificación/interoperabilidad de los

procesos comerciales corporativos.

ÿ La integración/interoperabilidad técnica incluye métodos comunes y servicios compartidos para la comunicación, el

almacenamiento, el procesamiento y el acceso a los datos principalmente en la plataforma de aplicaciones y los
dominios de infraestructura de comunicaciones.

La interoperabilidad y los requisitos de interoperabilidad se abordan en detalle en el estándar TOGAF: técnicas ADM.

3.10 Continuidad empresarial

El estándar TOGAF incluye el concepto de Enterprise Continuum, que establece el contexto más amplio para un arquitecto y
explica cómo se pueden aprovechar y especializar las soluciones genéricas para respaldar los requisitos de una organización
individual.

Enterprise Continuum es una categorización de los activos guardados en los Repositorios de Enterprise que proporciona
métodos para clasificar los activos, incluida la arquitectura y los artefactos de la solución a medida que evolucionan desde las
Arquitecturas básicas genéricas hasta las Arquitecturas específicas de la organización. los

26 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Conceptos básicos Continuidad empresarial

Enter prise Continuum comprende dos conceptos complementarios: el Continuum de Arquitectura y el Continuum de
Soluciones.

El Enterprise Continuum se describe en detalle en el estándar TOGAF: contenido de arquitectura.

En la Figura 3-4 se muestra una descripción general de la estructura y el contexto 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 3-4 Entrar premio Continuum

3.11 Repositorio de Arquitectura

El apoyo a Enterprise Continuum es el concepto de un repositorio de arquitectura que se puede utilizar para almacenar
diferentes clases de salida arquitectónica en diferentes niveles de abstracción, creado por el ADM. De esta manera, el
Estándar TOGAF facilita la comprensión y la cooperación entre las partes interesadas y los profesionales en diferentes
niveles.

Por medio de Enterprise Continuum and Architecture Repository, se alienta a los arquitectos a aprovechar todos los
demás recursos y activos arquitectónicos relevantes en el desarrollo de una Arquitectura Específica de la Organización.
En este contexto, se puede considerar que TOGAF ADM describe un ciclo de vida de proceso que opera en múltiples
niveles dentro de la organización, opera dentro de un marco de gobierno holístico y produce resultados alineados que
residen en un repositorio de arquitectura.
Enterprise Continuum proporciona un contexto valioso para comprender los modelos arquitectónicos: muestra los
bloques de construcción y sus relaciones entre sí, y las restricciones y requisitos en un ciclo de desarrollo de arquitectura.

Estándar TOGAF® — Introducción y conceptos básicos 27

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Repositorio de Arquitectura Conceptos básicos

La estructura del Repositorio de Arquitectura TOGAF se muestra en la Figura 3-5.

© El Grupo Abierto
Repositorio de Arquitectura

Metamodelo de arquitectura

artefactos en el
paisaje están
estructurados de acuerdo
con el metamodelo
Las mejores
Modelos de
prácticas
referencia
crean una
adoptados Externo
arquitectura de referencia Referencia por la empresa Referencia
Soluciones Biblioteca Modelos
Paisaje Habilita el Adoptado
empresa por la
empresa La referencia
Arquitectura Los estándares La biblioteca
tienen se rige
Paisaje
implementaciones de referencia
Se cumplen
Resultados
las normas
comerciales Estándares
Externo
entregados Estándares adoptado por Estándares
Biblioteca la empresa
Las
mejores
prácticas
crean estándares
El paisaje se rige El cumplimiento
Arquitectura
se rige
Requisitos Visibilidad y
Repositorio Conductores para el escalamiento
empresa Arquitectura
Repositorio de Gobernanza
La junta dirige Arquitectura
y gestiona la Junta
Capacidad de arquitectura capacidad.

Figura 3-5 Estructura del repositorio de la arquitectura TOGAF

Los componentes principales dentro de un repositorio de arquitectura son los siguientes:

ÿ El metamodelo de arquitectura describe la aplicación adaptada a la organización de un

marco de arquitectura, incluido 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 es la representación arquitectónica de los activos desplegados dentro de la empresa

operativa en un momento determinado: es probable que el paisaje exista en múltiples niveles de abstracción
para adaptarse a los diferentes objetivos de la arquitectura.

ÿ 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

28 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Conceptos básicos Repositorio de Arquitectura

ÿ 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.

El repositorio de arquitectura TOGAF se describe en el estándar TOGAF: contenido de arquitectura.

3.12 Marco de contenido TOGAF y metamodelo empresarial

3.12.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 arquitectónico.

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 Sección 3.6)

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

3.12.2 Marco de contenido

El marco de contenido define un marco de categorización que se utilizará para describir los componentes básicos y los
artefactos que reflejan las decisiones tomadas en la creación de los entregables de la arquitectura general.

El Repositorio de Arquitectura, que se explica en la Sección 3.11, 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.

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.

Estándar TOGAF® — Introducción y conceptos básicos 29

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Marco de contenido TOGAF y metamodelo empresarial Conceptos básicos

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 3-6) está estructurado de acuerdo con las fases del ADM.

Figura 3-6 Marco de contenido por fase de ADM

ÿ 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

30 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Conceptos básicos Marco de contenido TOGAF y metamodelo empresarial

ÿ 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.

El marco de contenido TOGAF se describe en detalle en el estándar TOGAF: contenido de arquitectura.

3.12.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.

Por ejemplo, un tipo en un metamodelo de empresa podría ser Rol. Luego, los modelos de arquitectura comercial de la
empresa podrían incluir instancias de Rol como Cajero, Piloto, Gerente, Voluntario, Cliente o Bombero. Por supuesto,
sería una empresa inusual que tuviera todos estos roles.

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 usar una variedad de lenguajes de modelado, como el lenguaje de modelado
ArchiMate® , Business Process Modeling Notation™ (BPMN™), Unified Modeling Language™ (UML®),
diagramas de relaciones entre entidades, diagramas de flujo o cualquier otra notación. que puede 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.

Estándar TOGAF® — Introducción y conceptos básicos 31

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Marco de contenido TOGAF y metamodelo empresarial Conceptos básicos

3.12.4 Desarrollo del metamodelo empresarial

El metamodelo empresarial es una parte importante de la arquitectura específica de la organización
Framework, como se destaca aquí. La Figura 3-7 muestra cómo el Enterprise Continuum (consulte la Sección
3.10) proporciona una manera de considerar los recursos en una escala que va desde la más general
("Fundación") a la más específica ("Específico de la organización"):

© El Grupo Abierto

Adaptación para el uso

Base Común Industria Específico de la organización

Figura 3-7 Aplicación de Enterprise Continuum

Para apoyar el desarrollo del metamodelo de la empresa, la Biblioteca TOGAF incluye una
Metamodelo de empresa central de nivel básico, detallado en el estándar TOGAF — Arquitectura
Contenido. Muestra los tipos de entidad, y las relaciones entre ellos, que es probable que se requieran en
modelando la mayoría de las empresas y proporciona un contexto para los artefactos sugeridos en el ADM.

32 El estándar de grupo abierto (2022)

© 2005-2022 El Grupo Abierto, Todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Conceptos básicos Marco de contenido TOGAF y metamodelo empresarial

El metamodelo Foundation Enterprise se ilustra en la figura 3-8.

Figura 3-8 Metamodelo TOGAF Core Enterprise

3.13 Establecimiento y mantenimiento de una capacidad de arquitectura empresarial

Para llevar a cabo la actividad arquitectónica de manera efectiva dentro de una empresa, es necesario establecer una
capacidad empresarial adecuada para la arquitectura, a través de estructuras de organización, roles, responsabilidades,
habilidades y procesos. En la Figura 3-9 se muestra una descripción general de la capacidad de la arquitectura TOGAF .

Estándar TOGAF® — Introducción y conceptos básicos 33

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Establecimiento y mantenimiento de una capacidad de arquitectura empresarial Conceptos básicos

Capacidad empresarial para la arquitectura (

Operando a un nivel de madurez )

Órganos de Gobierno
Órganos de Gobierno
Órganos de Gobierno

Establecer Midiendo
Directo
prioridad y enfoque el éxito

Grupo de recursos calificados

Proyecto portafolio
Participar
en

Desarrollo profesional Gobernancia

Establecer
prioridad
yenfoque

mejora mejora

Roles y Proyectos/
carteras Negocio
Requiere Responsabilidades Contrato
Habilidades Conocimiento regidas Operaciones
( como
tanto genéricas
específicas de
contra sus
un proyecto en contratos
Requiere particular )
soluciones
alineadas
entregando

Poseer Poseer
Proyectos/Portafolios
Arquitectura Asignado
Participar
en

Profesionales

Poblando Reutilización de
el Repositorio bloques de construcción y
cumplimiento de las normas

Enterprise Continuum (utilizado para clasificar entradas y salidas del Repositorio)

Repositorio de Arquitectura
© El Grupo Abierto

Figura 3-9 Vista general de la capacidad de la arquitectura TOGAF

3.14 Establecimiento de la capacidad de la arquitectura como una entidad operativa

A excepción de las Capacidades de Arquitectura configuradas para respaldar puramente los programas de entrega de
cambios, se reconoce cada vez más que una práctica de Arquitectura Empresarial exitosa debe asentarse sobre una
base operativa firme. En efecto, una práctica de Arquitectura Empresarial debe ejecutarse como cualquier otra unidad
operativa dentro de una empresa; es decir, debe tratarse como un negocio. Con este fin, y más allá de los procesos
centrales definidos en el ADM, una práctica de Arquitectura Empresarial debe establecer capacidades en las siguientes
áreas:

ÿ Gestión financiera

ÿ Gestión del Desempeño ÿ Gestión

de Servicios ÿ Gestión de Riesgos y

Oportunidades (ver Sección B.34)

ÿ Gestión de recursos

ÿ Comunicaciones y gestión de partes interesadas (consulte la Sección 4.36)

34 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Conceptos básicos Establecimiento de la capacidad de la arquitectura como una entidad operativa

ÿ Gestión de calidad ÿ Gestión

de proveedores (consulte la Sección B.40) ÿ Gestión de

la configuración (consulte la Sección B.7)

ÿ Gestión del Medio Ambiente

Un elemento central de la noción de operar una arquitectura en curso es la ejecución de una gobernanza bien definida y efectiva,
mediante la cual toda la actividad significativa desde el punto de vista de la arquitectura se controle y alinee dentro de un marco
único.

Dado que la gobernanza se ha convertido en un requisito cada vez más visible para la gestión organizacional, la inclusión de la
gobernanza dentro del estándar TOGAF alinea el marco con las mejores prácticas comerciales actuales y también garantiza un
nivel de visibilidad, orientación y control que respaldará todos los requisitos y obligaciones de las partes interesadas de la
arquitectura. .

Los beneficios de la Gobernanza de la Arquitectura incluyen:

ÿ Mayor transparencia en la rendición de cuentas y delegación informada de autoridad

ÿ Gestión proactiva de riesgos y oportunidades

ÿ Protección de la base de activos existente mediante la maximización de la reutilización de arquitectura existente

componentes

ÿ Mecanismos proactivos de control, seguimiento y gestión

ÿ Reutilización de procesos, conceptos y componentes en todas las unidades de negocio de la organización

ÿ Creación de valor mediante el seguimiento, la medición, la evaluación y la retroalimentación ÿ

Mayor visibilidad que respalda los procesos internos y los requisitos de las partes externas; en particular, una mayor
visibilidad de la toma de decisiones en los niveles inferiores garantiza la supervisión a un nivel apropiado dentro de la
empresa de las decisiones que pueden tener consecuencias estratégicas de gran alcance para la organización

ÿ Mayor valor para los accionistas; en particular, Enterprise Architecture representa cada vez más la propiedad intelectual
central de la empresa: los estudios han demostrado una correlación entre el aumento del valor para los accionistas y las
empresas bien administradas

ÿ Se integra con los procesos y metodologías existentes y complementa la funcionalidad al

agregando capacidades de control

En el estándar TOGAF: capacidad y gobernanza de la arquitectura empresarial se proporcionan más detalles sobre cómo
establecer una capacidad de arquitectura empresarial.

3.15 Uso del estándar TOGAF con otros marcos

Dos de los elementos clave de cualquier marco de arquitectura empresarial son:

ÿ Una definición de los entregables que la actividad de arquitectura debería producir. ÿ Una

descripción del método por el cual esto debería hacerse.

Con algunas excepciones, la mayoría de los marcos de Enterprise Architecture se enfocan en el primero de estos, el conjunto
específico de entregables, y son relativamente silenciosos sobre los métodos que se utilizarán para generarlos (intencionalmente,
en algunos casos).

Debido a que el estándar TOGAF es un marco genérico y está destinado a ser utilizado en una amplia variedad

Estándar TOGAF® — Introducción y conceptos básicos 35

© 2005-2022 The Open Group, todos los derechos reservados Copia
de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Uso del estándar TOGAF con otros marcos Conceptos básicos

de entornos, proporciona un marco de contenido flexible y extensible que sustenta un conjunto de entregables de
arquitectura genérica.

Como resultado, el marco TOGAF se puede utilizar por derecho propio, con los entregables genéricos que describe; o
bien estos entregables pueden ser sustituidos o ampliados por un conjunto más específico, definido en cualquier otro
marco que el arquitecto considere pertinente.

En todos los casos, se espera que el arquitecto adapte y se base en el marco TOGAF para definir un método
personalizado que se integre en los procesos y estructuras de organización de la empresa. Esta adaptación de la
arquitectura puede incluir la adopción de elementos de otros marcos de arquitectura o la integración de métodos TOGAF
con otros marcos estándar o mejores prácticas, como ITIL®, CMMI®, COBIT®, PRINCE2, PMBOK y MSP®. También
puede incluir la adopción de materiales de referencia de la biblioteca TOGAF, como la arquitectura de referencia
IT4IT™ . Las pautas para adaptar TOGAF ADM de tal manera se proporcionan en el Estándar TOGAF - Técnicas ADM.

Como marco y método genérico para Enterprise Architecture, el estándar TOGAF proporciona la capacidad y el entorno
colaborativo para integrarse con otros marcos.
Las organizaciones pueden utilizar completamente los dominios comerciales verticales, las áreas tecnológicas
horizontales (como la seguridad o la capacidad de administración) o las áreas de aplicación (como el comercio
electrónico) para producir un marco de arquitectura empresarial competitivo que maximice sus oportunidades comerciales.

3.16 Uso de TOGAF Framework con diferentes estilos de arquitectura

El marco TOGAF está diseñado para ser flexible y se utiliza con varios estilos arquitectónicos.

Los estilos arquitectónicos difieren en términos de enfoque, forma, técnicas, materiales, tema y período de tiempo.
El estándar TOGAF es un marco genérico destinado a ser utilizado en una amplia variedad de entornos. Es un marco
flexible y extensible que se puede adaptar fácilmente a una serie de estilos arquitectónicos.

Se puede esperar que el Paisaje Arquitectónico de una organización contenga trabajo de arquitectura desarrollado en
muchos estilos arquitectónicos. El estándar TOGAF garantiza que las necesidades de cada parte interesada se aborden
adecuadamente en el contexto de otras partes interesadas y la Arquitectura de referencia.

Al utilizar el estándar TOGAF para respaldar un estilo arquitectónico específico, el practicante debe tener en cuenta la
combinación de características distintivas en las que se realiza o expresa la arquitectura. Como primer paso, se deben
identificar las características distintivas de un estilo.

El segundo paso es determinar cómo se abordarán estas características distintivas. Abordar un estilo distintivo no
debería requerir cambios significativos en el marco TOGAF; en su lugar, debe ajustar los modelos, puntos de vista y
herramientas utilizadas por el profesional.

En la Fase B, Fase C y Fase D, se espera que el profesional seleccione los recursos de arquitectura relevantes,
incluidos modelos, puntos de vista y herramientas, para describir correctamente el dominio de la arquitectura y demostrar
que se abordan las preocupaciones de las partes interesadas (consulte el Estándar TOGAF: Técnicas ADM).
Dependiendo de las características distintivas, los diferentes estilos arquitectónicos agregarán nuevos elementos que
deben describirse, resaltarán los elementos existentes, ajustarán la notación utilizada para describir la arquitectura y
enfocarán al arquitecto en algunas partes interesadas o partes interesadas.
preocupaciones.

Abordar las características distintivas generalmente incluirá extensiones al contenido de la arquitectura.

Metamodelo y el uso de notación específica o técnicas de modelado y la identificación de

36 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Conceptos básicos Uso del marco TOGAF con diferentes estilos de arquitectura

puntos de vista El predominio de un estilo arquitectónico en particular puede llevar al practicante a revisar la Fase preliminar
para realizar cambios en la Capacidad de la arquitectura o para abordar una característica distintiva en el alcance esperado
de un solo ciclo de ADM.

Los modelos de referencia específicos del estilo y los modelos de madurez son herramientas de uso común que apoyan a
un profesional.

Durante la vida útil del marco TOGAF, se han desarrollado muchos estilos arquitectónicos para abordar los problemas
clave que enfrentan los profesionales y para demostrar cómo el marco TOGAF puede volverse más relevante dentro de
contextos definidos.

Algunos de estos han sido desarrollados por los Foros y Grupos de Trabajo de The Open Group que trabajan en áreas
específicas y han sido publicados en Guías, Libros Blancos y Estándares. Ejemplos incluyen:

ÿ Guía de la serie TOGAF® : uso del marco TOGAF® para definir y gobernar el servicio
Arquitecturas orientadas

ÿ Guía de la serie TOGAF® : Integración del riesgo y la seguridad dentro de una empresa TOGAF®
Arquitectura

Algunos de estos han sido desarrollados en colaboración entre The Open Group y otros organismos.
Ejemplos incluyen:

ÿ Integración de TOGAF® y SABSA® ÿ Archi

Banking Group: combinación del modelo de referencia BIAN, modelado ArchiMate®

Notación y TOGAF® Framework

ÿ Exploración de sinergias entre TOGAF® y Frameworx ÿ TOGAF® 9 y

DoDAF 2.0

La biblioteca TOGAF (consulte [Link]/togaf-librar y) es una biblioteca estructurada de recursos que respaldan
el estándar TOGAF.

3.17 Vistas y puntos de vista de la arquitectura

La capacidad de crear "vistas" específicas de partes de una arquitectura compleja es fundamental para poder comunicarse
y disipar las preocupaciones de las partes interesadas o grupos de partes interesadas. Para obtener la comprensión y el
apoyo completos de las partes interesadas, es necesario presentar la información en un formato que cada parte interesada
pueda relacionar y comprender.

La función de las vistas de arquitectura se muestra en la Figura 3-10, adaptada de definiciones más formales contenidas
en ISO/IEC/IEEE 42010: 2011 e ISO/IEC/IEEE 15288: 2015.

Estándar TOGAF® — Introducción y conceptos básicos 37

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Arquitectura Vistas y Miradores Conceptos básicos

exhibiciones
Sistema de
1 1
Arquitectura
Interés
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-10 Conceptos básicos de arquitectura

3.18 Agilidad empresarial

La agilidad empresarial es un término de uso común, pero la definición exacta difiere entre los profesionales.
Independientemente de cómo se defina el término, es importante porque permite que una empresa
reaccionar al cambio estando más centrados en el cliente y el producto, más eficientes y más capaces de
garantizar el cumplimiento normativo.

El término "ágil" se asocia frecuentemente con procesos ágiles de desarrollo de software asociados
con el Manifiesto para el Desarrollo Ágil de Software.

Si bien estos principios y técnicas "ágiles" se pueden aplicar para adaptar el marco TOGAF,
La agilidad empresarial es un contexto más amplio que el desarrollo ágil de software. Por lo tanto, adicional
Se emplean técnicas para adaptar el marco TOGAF a una empresa ágil.

La arquitectura empresarial proporciona un marco para el cambio, vinculado tanto a la dirección estratégica como a la
Valor de negocio. Proporciona una visión suficiente de la organización para gestionar la complejidad, apoyar

38 El estándar de grupo abierto (2022)

© 2005-2022 El Grupo Abierto, Todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Conceptos básicos Agilidad empresarial

cambio continuo y gestionar el riesgo de consecuencias imprevistas.

El marco TOGAF ha acogido el llamado a responder a las necesidades de la empresa de manera oportuna, a través de los conceptos de
“particiones” y “niveles”. Las particiones definen cómo se divide el trabajo en múltiples iniciativas de arquitectura. Los niveles definen
cómo se puede desarrollar la arquitectura general en diferentes niveles de granularidad y detalle.

Además, TOGAF ADM admite una serie de conceptos que se caracterizan como iteración.

Se pueden encontrar descripciones más detalladas de cómo adaptar TOGAF ADM para respaldar la agilidad empresarial en:

ÿ Guía de la serie TOGAF® : Aplicación de ADM mediante Agile Sprints ÿ Guía de la serie

TOGAF® : Activación de la agilidad empresarial ÿ El estándar Open Agile Architecture™

3.19 Gestión de riesgos

Siempre habrá riesgo con cualquier esfuerzo de transformación de arquitectura/negocio. Es importante identificar, clasificar y mitigar
estos riesgos antes de comenzar para que puedan ser rastreados a lo largo del esfuerzo de transformación.

La mitigación es un esfuerzo continuo y, a menudo, los desencadenantes del riesgo pueden estar fuera del alcance de los planificadores
de la transformación (p. ej., fusión, adquisición), por lo que los planificadores deben monitorear el contexto de la transformación
constantemente.

También es importante tener en cuenta que el Arquitecto Empresarial puede identificar los riesgos y mitigar ciertos, pero es dentro del
marco de gobierno que los riesgos primero deben aceptarse y luego administrarse.

Hay dos niveles de riesgo que se deben considerar, a saber:

ÿ Nivel inicial de riesgo: categorización del riesgo antes de determinar e implementar medidas de mitigación.
comportamiento

ÿ Nivel residual de riesgo: categorización del riesgo después de la implementación de acciones de mitigación (si corresponde)

El proceso para la gestión de riesgos consta de las siguientes actividades:

ÿ Clasificación de riesgos

ÿ Identificación de riesgos

ÿ Evaluación inicial de riesgos

ÿ Mitigación de riesgos y evaluación de riesgos residuales

ÿ Seguimiento de riesgos

En el Estándar TOGAF - Técnicas ADM se describe un enfoque cualitativo para la gestión de riesgos.

Los conceptos de riesgo están incluidos en la Arquitectura de Seguridad Empresarial descrita en el TOGAF®
Guía de la serie: Integración del riesgo y la seguridad dentro de una arquitectura empresarial TOGAF® .

Un enfoque cuantitativo más riguroso se describe en Open FAIR™ Body of Knowledge, que comprende dos estándares de The Open
Group: Open Risk Taxonomy (O-RT) y Open Risk Analysis (O-RA).

Estándar TOGAF® — Introducción y conceptos básicos 39

© 2005-2022 The Open Group, todos los derechos reservados Copia de
evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Conceptos básicos

40 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Capítulo 4: Definiciones

A los efectos del estándar TOGAF, se aplican los siguientes términos y definiciones. Se debe hacer referencia al Apéndice B para
definiciones complementarias no definidas en este capítulo. Se debe hacer referencia al Diccionario Colegiado Merriam-Webster®
para los términos no definidos en esta sección o en el Apéndice B.

4.1 Abstracción
La técnica de proporcionar descripciones resumidas o generalizadas de contenido detallado y complejo.

Nota: Abstracción, como en "nivel de abstracción", también puede significar proporcionar un enfoque para el
análisis que se preocupa por un nivel de detalle o abstracción consistente y común. Abstracción en este sentido
se usa típicamente en arquitectura para permitir que se logre un nivel consistente de definición y
comprensión en cada área de la arquitectura para apoyar la comunicación y la toma de decisiones efectivas.
Es especialmente útil cuando se trata de arquitecturas grandes y complejas, ya que permite identificar
problemas relevantes antes de intentar obtener más detalles.

4.2 Actor
Una persona, organización o sistema que tiene uno o más roles que inicia o interactúa con actividades; por ejemplo, un
representante de ventas que viaja para visitar a los clientes. Los actores pueden ser internos o externos a una
organización.

Nota: En la industria automotriz, un fabricante de equipos originales sería considerado un actor por un
concesionario automotriz que interactúa con las actividades de su cadena de suministro.

4.3 Arquitectura de la aplicación

Una descripción de la estructura y la interacción de las aplicaciones que brindan capacidades comerciales clave y
administran los activos de datos.

Nota: La arquitectura de la aplicación se describe en el estándar TOGAF: método de desarrollo de arquitectura.

Estándar TOGAF® — Introducción y conceptos básicos 41

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Componente de aplicación Definiciones

4.4 Componente de aplicación

Una encapsulación de la funcionalidad de la aplicación alineada con la estructura de implementación, que es modular y
reemplazable. Encapsula su comportamiento y datos, proporciona servicios y los pone a disposición a través de
interfaces.

Nota: Por ejemplo, una aplicación comercial como un sistema de contabilidad, nómina o CRM.

Un componente de aplicación normalmente mantiene un componente de datos. Está habilitado por servicios
tecnológicos proporcionados por componentes tecnológicos.

4.5 Plataforma de aplicaciones La colección

de componentes tecnológicos de hardware y software que brindan los servicios utilizados para respaldar las aplicaciones.

4.6 Servicio de aplicación Comportamiento

discreto que se puede solicitar desde una aplicación; un elemento automatizado que soporta o entrega parte o la
totalidad de uno o más servicios comerciales.

4.7 Estilo Arquitectónico

La combinación de características distintivas relacionadas con el contexto específico dentro del cual se realiza o expresa
la arquitectura; una colección de principios y características que guían o restringen cómo una arquitectura es para la
medicina.

4.8 Arquitectura
1. 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. (Fuente: ISO/IEC/IEEE 42010: 2011)

2. La estructura de los componentes, sus interrelaciones y los principios y directrices

que rigen su diseño y evolución en el tiempo.

4.9 Bloque de construcción de arquitectura (ABB)

Un componente arquitectónico que especifica los componentes básicos de la solución (SBB) necesarios en un nivel
más lógico (o independiente del proveedor).
Véase también la Sección 4.26.

42 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Definiciones Continuidad de la arquitectura

4.10 Arquitectura continua

Un mecanismo de categorización, con mayor detalle y especialización, para los componentes y artefactos almacenados en el Paisaje
Arquitectónico o Biblioteca de Referencia (parte del Repositorio de Arquitectura).

Nota: Este Continuum comienza con definiciones fundamentales como modelos de referencia, estrategias centrales y
bloques de construcción básicos. A partir de ahí, se extiende a las arquitecturas de la industria y todo el camino a
una arquitectura específica de la organización.

Véase también la Sección 4.44.

4.11 Método de desarrollo de arquitectura (ADM)

El núcleo del marco TOGAF. Un enfoque iterativo de varias fases para desarrollar y utilizar una arquitectura empresarial para dar forma
y gobernar la transformación empresarial.

Nota: El ADM se describe en el estándar TOGAF - Técnicas ADM.

4.12 Dominio de la arquitectura

El área arquitectónica que se está considerando. El marco TOGAF sigue la tradición de dividir la arquitectura empresarial en cuatro
dominios principales de arquitectura: negocios, datos, aplicaciones y tecnología. Otros dominios (motivación, seguridad, gobernanza,
etc.) pueden abarcar esos cuatro dominios principales.

4.13 Marco de arquitectura

Una estructura conceptual utilizada para planificar, desarrollar, implementar, gobernar y sostener una arquitectura.

4.14 Gobernanza de la arquitectura

La práctica de monitorear y dirigir el trabajo relacionado con la arquitectura. El objetivo es entregar los resultados deseados y adherirse
a los principios, estándares y hojas de ruta relevantes.

Consulte también la Sección 4.48.

4.15 Arquitectura Paisaje

La representación arquitectónica de activos en uso, o planeados, por la empresa en momentos particulares.

Estándar TOGAF® — Introducción y conceptos básicos 43

© 2005-2022 The Open Group, todos los derechos reservados Copia de
evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Nivel de arquitectura Definiciones

4.16 Nivel de arquitectura

Los niveles proporcionan un marco para dividir el Paisaje Arquitectónico en niveles de granularidad.

Nota: Los niveles de arquitectura son distintos de las particiones de arquitectura.

4.17 Modelo de Arquitectura

Una representación de un tema de interés.

Nota: Un modelo de arquitectura proporciona una representación a menor escala, simplificada y/o abstracta del tema.

Consulte también la Sección 4.75, la Sección 4.20 y la Sección 4.21.

4.18 Partición de arquitectura

Un subconjunto de arquitectura resultante de dividir esa arquitectura para facilitar su desarrollo y gestión.

4.19 Principio de arquitectura

Una declaración cualitativa de intenciones que debe cumplir la arquitectura.

Nota: En el estándar TOGAF — Técnicas ADM se define un conjunto de muestra de Principios de arquitectura.

4.20 Vista de arquitectura

Una representación de un sistema desde la perspectiva de un conjunto relacionado de preocupaciones.

Nota: En algunas secciones de este estándar, el término "vista" se usa como sinónimo de "vista de arquitectura".

Consulte también la Sección 4.75 y la Sección 4.21.

4.21 Punto de vista de la arquitectura

Una especificación de las convenciones para un tipo particular de vista de arquitectura.

Nota: Un punto de vista de la arquitectura también se puede ver como la definición o el esquema para ese tipo de vista de la arquitectura.
Establece las convenciones para construir, interpretar y usar una vista de arquitectura para abordar una preocupación
específica (o un conjunto de preocupaciones) sobre un sistema de interés.

En algunas secciones de esta norma, el término "punto de vista" se utiliza como sinónimo de "punto de vista de la
arquitectura".

Véase también la Sección B.25.

44 The Open Group Standard (2022) ©

2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Definiciones Visión de la arquitectura

4.22 Visión de la Arquitectura

Una descripción sucinta de la arquitectura de destino que describe su valor comercial y los cambios en la empresa que resultarán de su
implementación exitosa. Sirve como una visión aspiracional y un límite para el desarrollo de arquitectura detallada.

Nota: La fase A (visión de la arquitectura) se describe en el estándar TOGAF: método de desarrollo de la arquitectura.

4.23 Artefacto
Un producto de trabajo arquitectónico que describe un aspecto de la arquitectura.

Véase también la Sección 4.26.

4.24 Línea base

Una especificación que ha sido formalmente revisada y acordada, que a partir de ese momento sirve como base para un mayor
desarrollo o cambio y que solo puede cambiarse a través de procedimientos formales de control de cambios o un tipo de procedimiento
como la gestión de configuración.

4.25 Flujo de información sin fronteras™

Una representación abreviada de "acceso a información integrada para respaldar mejoras en los procesos comerciales" que representa
un estado deseado de la infraestructura de una empresa específica para las necesidades comerciales de la organización.

Nota: La necesidad de un flujo de información sin límites, una marca registrada de The Open Group, se describe en la
Guía de la serie TOGAF® : El modelo de referencia de infraestructura de información integrada TOGAF (III-RM).

4.26 Bloque de construcción

Un componente potencialmente reutilizable que se puede combinar con otros componentes básicos para ofrecer arquitecturas y
soluciones.

Nota: 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".

Los bloques de construcción se describen en el estándar TOGAF: contenido de arquitectura.

Véase también la Sección 4.23.

Estándar TOGAF® — Introducción y conceptos básicos 45

© 2005-2022 The Open Group, todos los derechos reservados Copia de
evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Arquitectura empresarial Definiciones

4.27 Arquitectura empresarial

Una representación de puntos de vista empresariales holísticos y multidimensionales de: capacidades, entrega de valor
de extremo a extremo, información y estructura organizativa; y las relaciones entre estos puntos de vista y estrategias
comerciales, productos, políticas, procesos, iniciativas y partes interesadas.

Nota: Business Architecture relaciona elementos comerciales con objetivos comerciales y elementos de otros
dominios.

La arquitectura empresarial se describe en el estándar TOGAF: método de desarrollo de arquitectura.

4.28 Capacidad comercial

Una habilidad particular que una empresa puede poseer o intercambiar para lograr un propósito específico.

4.29 Función comercial

Una colección de comportamiento empresarial basada en un conjunto elegido de criterios, estrechamente alineados con
una organización.

4.30 Gobernanza empresarial

Preocupado por garantizar que los procesos y políticas comerciales (y su operación) brinden los resultados comerciales y
se adhieran a la regulación comercial relevante.

4.31 Modelo de negocio

Un modelo que describe la lógica de cómo una empresa crea, entrega y captura valor.

4.32 Servicio comercial

Respalda el negocio al encapsular un "elemento de comportamiento comercial" único.

Nota: Un servicio ofrecido externamente a la empresa puede ser respaldado por servicios comerciales.

4.33 Capacidad
Habilidad que posee una organización, persona o sistema.

Nota: Esta es una definición de propósito general. Consulte la Sección 4.28 para conocer cómo se refina este concepto para su uso
en la arquitectura empresarial.

46 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Definiciones Arquitectura de capacidad

4.34 Arquitectura de capacidad

Una arquitectura que describe las capacidades que posee una empresa.

Consulte también la Guía de la serie TOGAF® : un enfoque de los profesionales para desarrollar una arquitectura empresarial siguiendo
el TOGAF ADM.

4.35 Incremento de capacidad

Una parte discreta de una arquitectura de capacidad que ofrece un valor específico. Cuando se han completado todos los incrementos,
la capacidad se ha realizado.

4.36 Comunicaciones y gestión de partes interesadas

La gestión de las necesidades de los stakeholders de la práctica de Enterprise Architecture. También gestiona la ejecución de la
comunicación entre la práctica y las partes interesadas y la práctica y los consumidores de sus servicios.

Nota: La gestión de las partes interesadas en la arquitectura se describe en el estándar TOGAF - Técnicas ADM.

4.37 Preocupación
Un interés en un sistema relevante para una o más de sus partes interesadas.

Nota: 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.
Véase también la Sección 4.75.

4.38 Curso de Acción

Dirección y enfoque proporcionados por metas y objetivos estratégicos, a menudo para entregar la propuesta de valor caracterizada en
el modelo de negocios.

4.39 Arquitectura de datos

Una descripción de la estructura de los principales tipos y fuentes de datos, activos de datos lógicos, activos de datos físicos y recursos
de gestión de datos de la empresa.

Nota: La arquitectura de datos se describe en el estándar TOGAF: método de desarrollo de arquitectura.

Estándar TOGAF® — Introducción y conceptos básicos 47

© 2005-2022 The Open Group, todos los derechos reservados Copia de
evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Entregable Definiciones

4.40 Entregable

Un producto de trabajo arquitectónico que se especifica contractualmente y, a su vez, se revisa, acuerda y firma formalmente
por las partes interesadas.
Nota: Los entregables representan el resultado de los proyectos y los entregables que están en forma de
documentación generalmente se archivarán al finalizar un proyecto, o pasarán a un Repositorio de
Arquitectura y como modelo de referencia, estándar o instantánea del Paisaje de Arquitectura en un
momento dado.

4.41 Arquitectura digital

La arquitectura inclusiva se centró en una combinación de arquitectura empresarial, ciencia de datos, telecomunicaciones e
IoT, seguridad, inteligencia artificial, ciencia cognitiva, neurociencia, robótica y redes sociales para brindar servicios operativos.

4.42 Empresa
El nivel más alto (típicamente) de descripción de una organización y normalmente cubre todas las misiones y funciones. Un
premio empresarial a menudo abarcará varias organizaciones.

4.43 Servicio de arquitectura empresarial

Un elemento encapsulado de la capacidad de Enterprise Architecture que ofrece una funcionalidad específica de Enterprise
Architecture.

4.44 Continuidad empresarial

Un mecanismo de categorización para clasificar la arquitectura y los Bloques de creación de soluciones (SBB) a medida que
evolucionan de una aplicabilidad genérica a una específica (o viceversa).

Consulte también la Sección 4.10 y la Sección 4.74.

4.45 Arquitectura de cimientos

Bloques de construcción genéricos, sus interrelaciones con otros bloques de construcción, combinados con los principios y
pautas que proporcionan una base sobre la cual se pueden construir arquitecturas más específicas.

4.46 Marco

Una estructura de contenido o proceso que se puede utilizar como herramienta para estructurar el pensamiento, asegurando
la coherencia y la integridad.

48 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Definiciones Brecha

4.47 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.

4.48 Gobernanza
La disciplina de monitorear y guiar la gestión de un negocio (o panorama de SI/TI) para entregar los resultados comerciales
requeridos.

Consulte también la Sección 4.14, la Sección 4.30 y la Sección B.27 en el Apéndice B.

4.49 Información
Cualquier comunicación o representación de hechos, datos u opiniones, en cualquier medio o forma, incluyendo formas
textuales, numéricas, gráficas, cartográficas, narrativas o audiovisuales.

4.50 Tecnología de la información (TI)

La gestión del ciclo de vida de la información y la tecnología relacionada utilizada por una organización.

4.51 Interoperabilidad
1. La capacidad de compartir información y servicios.

2. La capacidad de dos o más sistemas o componentes para intercambiar y utilizar información.

3. La capacidad de los sistemas para proporcionar y recibir servicios de otros sistemas y para utilizar los servicios
intercambiados para permitirles operar juntos de manera efectiva.

4.52 Lógico
Independiente de la implementación.

Nota: Una arquitectura lógica es una definición independiente de la implementación de la arquitectura.

4.53 Metadatos
Datos sobre datos, de cualquier tipo en cualquier medio, que describen las características de una entidad.

4.54 Metamodelo
Un modelo que describe las entidades utilizadas en la construcción de una Descripción de Arquitectura, sus características
y las relaciones clave entre esas entidades.

Estándar TOGAF® — Introducción y conceptos básicos 49

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Método Definiciones

4.55 Método
Un enfoque definido y repetible para abordar un tipo particular de problema.

4.56 Modelado
Una técnica a través de la construcción de modelos que permite representar un tema en una forma que permite el razonamiento, la
comprensión y la claridad con respecto a la esencia del tema.

4.57 Tipo de modelo

Convenciones para un tipo de modelado.

Nota: un punto de vista de la arquitectura hace referencia a uno o más tipos de modelos; una vista de arquitectura incorpora
uno o más modelos.

4.58 Objetivo
Un objetivo organizacional que se declara de manera específica, medible, factible, realista y con límite 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".

4.59 Patrón
Una técnica para poner bloques de construcción en contexto; por ejemplo, para describir una solución reutilizable a un problema.

Nota: Los bloques de construcción son lo que usas: los patrones (de arquitectura) pueden decirte cómo los usas,
cuándo, por qué y qué compensaciones tienes que hacer al hacerlo.

Véase también la Sección 4.26.

4.60 Físico
Mundo real, tangible.

Nota: Una arquitectura lógica se realiza a través de una arquitectura física.

4.61 Principio
Consulte la Sección 4.19.

4.62 Producto
Un resultado generado por el negocio para ser ofrecido a los clientes. Los productos incluyen materiales y/o servicios.

50 The Open Group Standard (2022) ©

2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Definiciones Modelo de referencia (RM)

4.63 Modelo de referencia (RM)

Un marco abstracto para comprender las relaciones significativas entre las entidades de [un] entorno y para el desarrollo
de estándares o especificaciones consistentes que respalden ese entorno.

Nota: Un modelo de referencia se basa en una pequeña cantidad de conceptos unificadores y se puede utilizar como
base para la educación y la explicación de los estándares a un no especialista. Un modelo de referencia no
está directamente vinculado a ningún estándar, tecnología u otros detalles de implementación concretos,
pero busca proporcionar una semántica común que se pueda usar sin ambigüedades entre diferentes
implementaciones.

Fuente: OASIS®; consulte [Link]/committees/tc_home.php?wg_abbrev=soa-r m.

4.64 Requisito
Una declaración de necesidad, que es inequívoca, comprobable o medible, y necesaria para la aceptabilidad.

4.65 Hoja de ruta

Un plan abstracto para el cambio tecnológico o empresarial, que normalmente opera en múltiples disciplinas durante
varios años. Normalmente se utiliza en las frases Technology Roadmap, Architecture Roadmap, etc.

4.66 Rol
1. El comportamiento usual o esperado de un actor, o la parte que alguien o algo juega en un proceso o evento
particular. Un actor puede tener varios papeles.

2. El papel que juega un individuo en una organización y la contribución que hace a través de la
aplicación de sus habilidades, conocimientos, experiencia y habilidades.
Véase también la Sección 4.2.

4.67 Arquitectura de segmento

Una descripción detallada y formal de áreas dentro de una empresa, utilizada a nivel de programa o cartera para
organizar y alinear la actividad de cambio.
Consulte también la Sección 4.77.

Estándar TOGAF® — Introducción y conceptos básicos 51

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Servicio Definiciones

4.68 Servicio
Un elemento de comportamiento encapsulado que proporciona una funcionalidad específica en respuesta a solicitudes de
actores u otros servicios.

Nota: Un servicio tiene una interfaz y una descripción.

4.69 Orientación al Servicio

Visualización de una empresa, sistema o componente básico en términos de servicios proporcionados y consumidos.

Consulte también la Sección 4.70.

4.70 Arquitectura Orientada a Servicios (SOA)

Un estilo arquitectónico que apoya la orientación al servicio.

Consulte también la Sección 4.7 y la Sección 4.69.

4.71 Cartera de servicios

Una colección de servicios, potencialmente una definición de interfaz.
Nota: Se utiliza en el marco TOGAF para definir el requisito de un bloque de construcción o sistema.

4.72 Arquitectura de la solución

Una descripción de una operación o actividad comercial discreta y enfocada y cómo SI/TI respalda esa operación.

4.73 Bloque de creación de soluciones (SBB)

Un componente físico o específico de la implementación que realiza parte o la totalidad de uno o más bloques de construcción
de arquitectura (ABB) lógicos.
Nota: Hay SBB de negocios, aplicaciones y tecnología.

4.74 Soluciones continuas

Un mecanismo de categorización, con mayor detalle y especialización, para los componentes y artefactos almacenados en el
Paisaje de Soluciones o Biblioteca de Referencia (parte del Repositorio de Arquitectura).

Consulte también la Sección 4.44 y la Sección 4.10.

52 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Definiciones Interesado

4.75 Parte interesada

Un individuo, equipo, organización o clase de los mismos, que tiene un interés en un sistema.

4.76 Biblioteca de estándares

Una biblioteca de estándares que se pueden utilizar para definir los servicios particulares y otros componentes de una
arquitectura específica de la organización.
Nota: La biblioteca de estándares se describe en el estándar TOGAF: contenido de arquitectura: repositorio de
arquitectura.

4.77 Arquitectura Estratégica

Una descripción formal resumida de la empresa, que proporciona un marco organizativo para la actividad operativa y de
cambio, y una visión a largo plazo a nivel ejecutivo para establecer la dirección.

4.78 Arco de destino

La descripción de un estado futuro de la arquitectura que se está desarrollando para una organización.
Nota: Puede haber varios estados futuros desarrollados como una hoja de ruta para mostrar la evolución de la
arquitectura a un estado objetivo.

4.79 Taxonomía de Vistas de Arquitectura

La colección organizada de todas las vistas de arquitectura pertinentes a una arquitectura.

4.80 Arquitectura Tecnológica

Una descripción de la estructura y la interacción de los servicios tecnológicos y los componentes tecnológicos.

Nota: La arquitectura tecnológica se describe en el estándar TOGAF: método de desarrollo de arquitectura.

4.81 Componente Tecnológico

1. Un bloque de construcción de tecnología. Una tecnología de infraestructura genérica que admite y habilita
aplicaciones o componentes de datos (directa o indirectamente) al proporcionar servicios de tecnología.

2. Una encapsulación de infraestructura tecnológica que representa una clase de producto tecnológico o un producto
tecnológico específico.

Estándar TOGAF® — Introducción y conceptos básicos 53

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Servicio de Tecnología Definiciones

4.82 Servicio de tecnología Una capacidad técnica

requerida para proporcionar una infraestructura habilitadora que apoye la entrega de aplicaciones.

4.83 Arquitectura de transición

Una descripción formal de un estado de la arquitectura en un punto arquitectónicamente significativo en el tiempo.

Nota: Se pueden usar una o más arquitecturas de transición para describir la progresión en el tiempo desde la línea de base
hasta la arquitectura objetivo.

La arquitectura de transición se describe en el estándar TOGAF: contenido de arquitectura: documento de definición de

arquitectura.

4.84 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.

4.85 Ver
Consulte la Sección 4.20.

4.86 Mirador
Consulte la Sección 4.21.

4.87 Biblioteca de puntos de vista

Una colección de las especificaciones de los puntos de vista de la arquitectura contenidas en la parte de la Biblioteca de Referencia del
Repositorio de Arquitectura.

4.88 Paquete de trabajo

Un conjunto de acciones identificadas para lograr uno o más objetivos para el negocio. Un paquete de trabajo puede ser parte de un
proyecto, un proyecto completo o un programa.

54 The Open Group Standard (2022) ©

2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Apéndice A: Documentos de referencia

Las guías de la serie Open Group TOGAF

ÿ Guía de la serie TOGAF® : Aplicación de ADM mediante Agile Sprints (G210), publicada por The Open Group, abril
de 2022; consulte: [Link]/library/g210

ÿ Guía de la serie TOGAF® : un enfoque de los profesionales para desarrollar la arquitectura empresarial Siguiente
TOGAF ADM (G186), publicado por The Open Group, abril de 2022; consulte:
[Link]/library/g186

ÿ Guía de la serie TOGAF® : Modelos de madurez de la arquitectura (G203), publicado por The Open Group, abril de 2022;
consulte: [Link]/library/g203 ÿ Guía de la serie TOGAF® : Gestión de proyectos de arquitectura (G188),

publicada por The Open Group,

abril de 2022; consulte: [Link]/library/g188

ÿ TOGAF® Se ries Guide: Architecture Skills Framework (G198), publicado por The Open Group, abril de 2022; consulte:
[Link]/library/g198

ÿ Guía de la serie TOGAF® : capacidades comerciales, versión 2 (G211), publicada por The Open Group,
abril de 2022; consulte: [Link]/library/g211

ÿ Guía de la serie TOGAF® : Modelos comerciales (G18A), publicada por The Open Group, abril de 2022; referirse
a: [Link]/library/g18a

ÿ Guía de la serie TOGAF® : escenarios empresariales (G176), publicada por The Open Group, abril de 2022;
consulte: [Link]/library/g176

ÿ Guía de la serie TOGAF® : Adopción de tecnología digital: una guía para la evaluación de la preparación y el desarrollo
de la hoja de ruta (G212), publicada por The Open Group, abril de 2022; consulte: [Link]/library/g212

ÿ Guía de la serie TOGAF® : Arquitectura de la información — Gestión de datos maestros del cliente (G21B), publicada
por The Open Group, abril de 2022; consulte: [Link]/library/g21b

ÿ Guía de la serie TOGAF® : Mapeo de información (G190), publicada por The Open Group, abril de 2022;
consulte: [Link]/library/g190

ÿ Guía de la serie TOGAF® : Integración del riesgo y la seguridad dentro de una arquitectura empresarial TOGAF®
(G152), publicada por The Open Group, abril de 2022; consulte: [Link]/library/g152

ÿ Guía de la serie TOGAF® : Mapeo de la organización (G206), publicada por The Open Group, abril de 2022;
consulte: [Link]/library/g206

ÿ Guía de la serie TOGAF® : Habilitación de la agilidad empresarial (G20F), publicada por The Open Group, abril de
2022; consulte: [Link]/library/g20f ÿ Guía de la serie TOGAF® : El modelo de referencia de infraestructura

de información integrada TOGAF (III-RM): un enfoque arquitectónico para el flujo de información sin límites™ (G179), publicado
por The Open Group, noviembre de 2017; consulte: [Link]/library/g179

Estándar TOGAF® — Introducción y conceptos básicos 55

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

documentos de referencia

ÿ Guía de la serie TOGAF® : Guía del líder TOGAF para establecer y desarrollar una capacidad de EA (G184), publicada
por The Open Group, abril de 2022; consulte: [Link]/library/g184 ÿ Guía de la serie TOGAF® : El modelo

de referencia técnica TOGAF (TRM) (G175), publicado por The Open Group, septiembre de 2017; consulte:
[Link]/library/g175

ÿ Guía de la serie TOGAF® : uso del marco TOGAF® para definir y gobernar la orientación a servicios
Architectures (G174), publicado por The Open Group, septiembre de 2017; consulte:
[Link]/library/g174

ÿ Guía de la serie TOGAF® : flujos de valor (G178), publicada por The Open Group, abril de 2022; consulte:
[Link]/library/g178

Otras publicaciones de The Open Group

ÿ Un enfoque práctico para la consolidación de la cartera de aplicaciones utilizando el estándar TOGAF® , The Open Group
Guide (G18B), publicado por The Open Group, julio de 2018; consulte: [Link]/library/g18b

ÿ Archi Banking Group: combinación del modelo de referencia BIAN, la notación de modelado ArchiMate® y el marco
TOGAF® , estudio de caso (Y201), publicado por The Open Group, marzo de 2020; consulte: [Link]/library/
y201

ÿ Especificación ArchiMate® 3.1, un estándar de The Open Group (C197), publicado por The Open
Grupo, noviembre de 2019; consulte: [Link]/library/c197

ÿ Estándar Digital Practitioner Body of Knowledge™ (también conocido como Estándar DPBoK™ ), un estándar de
The Open Group (C196), publicado por The Open Group, enero de 2020; consulte: [Link]/library/
c196

ÿ Exploring Synergies between TOGAF® and Frameworx, White Paper (W114), publicado por The
Grupo Abierto, mayo de 2011; consulte: [Link]/library/w114

ÿ Arquitectura de la información: Business Intelligence & Analytics and Metadata Management Reference Models, The Open
Group Guide (G201), publicado por The Open Group, enero de 2020; consulte: [Link]/library/g201

ÿ Open Risk Analysis (O-RA), Versión 2.0, un estándar de The Open Group (C20A), publicado por The Open Group,
noviembre de 2020; consulte: [Link]/library/c20a

ÿ Open Risk Taxonomy (O-RT), Versión 3.0, un estándar de The Open Group (C20B), publicado por The
Grupo Abierto, noviembre de 2020; consulte: [Link]/library/c20b

ÿ El estándar Open Agile Architecture™ , un estándar de The Open Group (C208), publicado por The Open Group,
septiembre de 2020; consulte: [Link]/library/c208

ÿ The Open Group IT4IT™ Reference Architecture, versión 2.1, un estándar de The Open Group
(C171), publicado por The Open Group, enero de 2017; consulte: [Link]/library/c171 ÿ TOGAF® 9 y

DoDAF 2.0, White Paper (W105), publicado por The Open Group, julio de 2010; consulte: [Link]/library/w105

ÿ TOGAF® and SABSA® Integration, White Paper (W117), publicado por The Open Group, octubre de 2011; consulte:
[Link]/library/w117

56 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

documentos de referencia

Otros documentos de referencia

ÿ Una guía de la Guía del Fundamento de la Dirección de Proyectos (PMBOK®) , Gestión de Proyectos
Instituto; consulte: [Link]/pmbok-guide-standards

ÿ Un método para identificar oportunidades de reutilización de procesos para mejorar el modelo operativo, M. de Vr ies,
A. van der Merwe, P. Kotze, A. Gerber, en las actas de la Conferencia internacional IEEE de 2011 sobre ingeniería
industrial y gestión de la ingeniería (IEEM)

ÿ Patrones de análisis — Modelos de objetos reutilizables, M. Fowler, ISBN: 0-201-89542-0, Addison-Wesley ÿ ANSI/IEEE

Std 1471-2000: Ingeniería de sistemas y software — Práctica recomendada para

Descripción arquitectónica de los sistemas intensivos en software

ÿ Un lenguaje de patrones: ciudades, edificios, construcción, Christopher Alexander, ISBN: 0-19-501919-9,

Prensa de la Universidad de Oxford, 1979

ÿ Business Motivation Model™ (BMM™), Object Management Group (OMG); consulte: [Link]/
spec/BMM/About-BMM

ÿ Especificación Business Process Modeling Notation™ (BPMN™) , Grupo de gestión de objetos (OMG); consulte:
[Link]

ÿ Programa de Habilitación para la Transformación Empresarial (BTEP), Gobierno de Canadá; Referirse a:

[Link]
ÿ Objetivos de control para la información y tecnología relacionada (COBIT®), Versión 4.0, Gobierno de TI
Instituto, 2005

ÿ Gobernanza corporativa, Ranami Naidoo, ISBN: 1-919-903-0086, Double Storey, 2002 ÿ Patrones de

diseño: Elementos de software orientado a objetos reutilizable, Erich Gamma, Richard Helm,
Ralph Johnson, John Vlissides, ISBN: 0-201-63361-2, Addison-Wesley, octubre de 1994

ÿ Arquitectura empresarial como estrategia, Jeanne Ross, Peter Weill, David C. Rober tson, ISBN:
1-59139-839-8, Harvard Business School Press, 2006

ÿ Enterprise Architecture Capability Maturity Model (ACMM), versión 1.2, Departamento de Comercio de los Estados Unidos,
diciembre de 2007

ÿ Modelo de madurez de la arquitectura empresarial, versión 1.3, Asociación Nacional de CIO estatales (NASCIO),
diciembre de 2003

ÿ Planificación de arquitectura empresarial (EAP): desarrollo de un plan para datos, aplicaciones y

Tecnología, Steven H. Spewak, Steven C. Hill, ISBN: 0-47-159985-9, John Wiley & Sons, 1993

ÿ Principios del Cuartel General de la Fuerza Aérea para la gestión de la información, Fuerza Aérea de EE. UU., 29

de junio de 1998 ÿ ISO/IEC 20000: 2011, Tecnología de la información — Gestión de servicios ÿ ISO/IEC/IEEE 15288:

2015, Ingeniería de sistemas y software — Vida útil del sistema Procesos de ciclo ÿ ISO/IEC/IEEE 42010: 2011, Ingeniería

de software y sistemas: descripción de la arquitectura ÿ Especificación de IT Portfolio Management Facility™ (ITPMF™) ,

Grupo de gestión de objetos (OMG); consulte: [Link]/spec/ITPMF

ÿ Manifiesto para el desarrollo ágil de software, 2001; consulte: [Link] ÿ Merr iam-

Webster Collegiate Dictionary, Merr iam-Webster, idioma inglés, 11.ª edición, abril de 2008, ISBN-10: 0877798095,
ISBN-13: 978-0877798095; consulte: [Link] [Link]

Estándar TOGAF® — Introducción y conceptos básicos 57

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

documentos de referencia

ÿ Especificación Model-Driven Architecture® (MDA®) , gestión de objetos (OMG); consulte: [Link]/mda

ÿ OCDE Principios de Gobierno Corporativo, Organización para la Cooperación Económica y

Desarrollo, diciembre de 2001; consulte: [Link]

ÿ Organigraphs: Drawing How Companies Really Work, H. Mintzberg y L. Van der Heyden,
Harvard Business Review, octubre de 1999; consulte: [Link] how-companies-really-work

ÿ Arquitectura de software orientada a patrones: un sistema de patrones, F. Buschmann, R. Meunier, H.

Rohner t, muchacho de P. Sommer, M. Stal, ISBN: 0-471-95869-7, John Wiley & Sons, 1996

ÿ Patrones y software: conceptos esenciales y terminología, Brad Appleton, 2000; consulte: [Link]/docs/patter
[Link]

ÿ Especificación de activos reutilizables (RAS), versión 2.2, Grupo de gestión de objetos (OMG), noviembre
2005; consulte: [Link]/spec/RAS

ÿ Especificación de Arquitectura de Componentes de Servicio (SCA), desarrollada por la colaboración de Arquitectura Orientada
a Servicios Abiertos (OSOA); consulte: [Link]/sca ÿ Especificación de objetos de datos de servicio (SDO),

desarrollada por la arquitectura abierta orientada a servicios

(OSOA) colaboración; consulte: [Link]/sdo

ÿ Especificación del metamodelo de ingeniería de procesamiento de software (SPEM™) , versión 2.0, objeto
Grupo de Gestión (OMG), abril de 2008; consulte: [Link]/spec/SPEM ÿ Lenguaje de

Modelado de Sistemas™ (SysML®), Grupo de Gestión de Objetos (OMG); Referirse a:

[Link]

ÿ El arte de la arquitectura de sistemas, Eberhardt Rechtin, Mark W. Maier, 2000 ÿ El experimento

de Oregón, Christopher Alexander, ISBN: 0-19-501824-9, Oxford University Press,

1975

ÿ The Timeless Way of Building, Christopher Alexander, ISBN: 0-19-502402-8, Universidad de Oxford
Prensa, 1979

ÿ El Marco Zachman® , Zachman International; consulte: [Link]

ÿ Perfil UML y Metamodelo para Servicios (UPMS) RFP (OMG soa/2006-09-09), Gestión de Objetos
Grupo (Dios mío), junio de 2007

ÿ Especificación de Unified Modeling Language™ (UML®) , Grupo de gestión de objetos (OMG); Referirse a:
[Link]

Los siguientes sitios web proporcionan material de referencia útil:

ÿ El sitio web de la comunidad Cloud Computing Design Patterns (consulte: [Link] [Link]) ÿ El Instituto de

Gobernanza de la Tecnología de la Información: [Link]/About-ISACA/IT-Governance

Instituto
Este sitio web tiene muchos recursos que pueden ayudar con la evaluación corporativa tanto de TI como de gobierno
en general.

ÿ Preguntas frecuentes sobre la discusión de patrones: [Link] [Link]/theopengroup/pd-FAQ

Este sitio web es mantenido por Doug Lea y proporciona preguntas frecuentes completas y fáciles de leer sobre patrones.

58 The Open Group Standard (2022) ©

2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

documentos de referencia

ÿ La página de inicio de Pattern ns: [Link]/pattern ns

Este sitio web está alojado por The Hillside Group y proporciona información sobre patrones, enlaces a patrones en línea,
documentos y libros que tratan sobre patrones y listas de correo relacionadas con patrones.

ÿ El sitio web de la comunidad SOA Patterns (consulte: [Link]/), dedicado al desarrollo y expansión
continuos del catálogo de patrones de diseño SOA

Estándar TOGAF® — Introducción y conceptos básicos 59

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

documentos de referencia

60 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Apéndice B: Glosario de definiciones complementarias

Este apéndice contiene definiciones adicionales para complementar las definiciones contenidas en el Capítulo 4.

B.1 Software de aplicación

Entidades de software que tienen un propósito comercial específico.

B.2 Disponibilidad
En el contexto de los sistemas de TI, la probabilidad de que las capacidades funcionales del sistema estén listas para ser
utilizadas por un usuario en cualquier momento, donde se considera todo el tiempo, incluidas las operaciones, la reparación, la
administración y el tiempo logístico. La disponibilidad se define además por categoría de sistema para operaciones tanto de
rutina como prioritarias.

B.3 Sistema de Negocios

Hardware, software, declaraciones de políticas, procesos, actividades, estándares y personas que, en conjunto, implementan
una capacidad comercial.

B.4 Catálogo
Una lista estructurada de productos arquitectónicos de tipo similar, utilizada como referencia. Por ejemplo, un catálogo de
estándares tecnológicos o una cartera de aplicaciones.

B.5 Cliente
Un componente de aplicación que solicita servicios de un servidor.

B.6 COBIT
Un acrónimo de Control OBjectives for Information and related Technology, creado por la Asociación de auditoría y control de
sistemas de información (ISACA) y el Instituto de gobierno de TI (ITGI), que proporciona un conjunto de mejores prácticas
recomendadas para el gobierno/gestión de la información. sistemas y tecnología.

Estándar TOGAF® — Introducción y conceptos básicos 61

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Gestión de la configuración Glosario de definiciones complementarias

B.7 Gestión de la configuración

Disciplina que aplica la dirección y vigilancia técnica y administrativa a:

ÿ Identificar y documentar las características físicas y funcionales de un elemento de configuración ÿ Controlar

los cambios en esas características

ÿ Registrar e informar cambios en el estado de procesamiento e implementación

Además, la gestión de la configuración de los activos y las líneas base de la práctica de Arquitectura Empresarial
(propiedad intelectual) y el control del cambio de dichos activos.

B.8 CxO
El director general dentro de una función particular del negocio; por ejemplo, director ejecutivo, director financiero,
director de información, director de tecnología.

B.9 Diccionario de datos

Un tipo especializado de base de datos que contiene metadatos; un depósito de información que describa las
características de los datos utilizados para diseñar, monitorear, documentar, proteger y controlar datos en sistemas de
información y bases de datos; un sistema de aplicación que soporta la definición y gestión de metadatos de bases de
datos.

B.10 Elemento de datos

Una unidad básica de información que tiene un significado y que puede tener subcategorías (elementos de datos) de
distintas unidades y valores.

B.11 Base de datos

Una colección estructurada u organizada de entidades de datos, a la que se accede mediante una computadora.

B.12 Sistema de gestión de base de datos

Un programa de aplicación informática que accede o manipula la base de datos.

B.13 Usuario final

Persona que finalmente utiliza la aplicación informática o la salida.

62 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Glosario de definiciones complementarias Sistema de planificación de recursos empresariales (ERP)

B.14 Sistema de planificación de recursos empresariales (ERP)

Un conjunto completo de aplicaciones integradas que respaldan las principales funciones de soporte comercial de una
organización; por ejemplo, finanzas (AP/AR/GL), recursos humanos, nómina, existencias, procesamiento de pedidos y
facturación, compras, logística, fabricación, etc.

B.15 Hardware
La infraestructura física necesaria para ejecutar el software; por ejemplo, servidores, estaciones de trabajo, equipos de
red, etc.

B.16 Dominio de la información

Agrupación de información (o entidades de datos) por un conjunto de criterios tales como clasificación de seguridad,
propiedad, ubicación, etc. En el contexto de la seguridad, los dominios de información se definen como un conjunto de
usuarios, sus objetos de información y una política de seguridad. .

B.17 Sistema de Información (SI)

La parte basada en computadora (o TI) de un sistema comercial.

B.18 Interacción
Una relación entre bloques de construcción arquitectónicos (es decir, servicios o componentes) que encarna la
comunicación o el uso.

B.19 Modelo de interacción

Vista arquitectónica, catálogo o matriz que muestra un tipo particular de interacción. Por ejemplo, un diagrama que
muestra la integración de aplicaciones.

B.20 Interfaz
Interconexión e interrelaciones entre, por ejemplo, personas, sistemas, dispositivos, aplicaciones o el usuario y una
aplicación o dispositivo.

B.21 Indicador clave de rendimiento (KPI)

Una forma de cuantificar el desempeño del negocio o proyecto.

Estándar TOGAF® — Introducción y conceptos básicos 63

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Ciclo vital Glosario de definiciones complementarias

B.22 Ciclo de vida

El período de tiempo que comienza cuando se concibe un sistema y termina cuando el sistema ya no está disponible para su uso.

B.23 Gestión de Programas Exitosos (MSP)

Una metodología de mejores prácticas para la gestión de programas, desarrollada por la Oficina de Comercio Gubernamental
(OGC) del Reino Unido.

B.24 Matriz
Un formato para mostrar la relación entre dos (o más) elementos arquitectónicos en un formato de cuadrícula.

B.25 Metavista
Un patrón o plantilla de la vista, a partir del cual desarrollar vistas individuales. Establece los propósitos y la audiencia de una
vista, las formas en que se documenta la vista (p. ej., para el modelado visual) y las formas en que se utiliza (p. ej., para el
análisis).

Ver también la Sección 4.21 en el Capítulo 4.

B.26 Sistema abierto

Un sistema que implementa suficientes especificaciones abiertas para interfaces, servicios y formatos de soporte para habilitar el
software de aplicación diseñado correctamente:

ÿ Para ser portado con cambios mínimos a través de una amplia gama de sistemas

ÿ Interoperar con otras aplicaciones en sistemas locales y remotos

ÿ Para interactuar con los usuarios en un estilo que facilite la portabilidad del usuario

B.27 Gobernanza operativa

El rendimiento operativo de los sistemas frente a los niveles de rendimiento contratados, la definición de los niveles de rendimiento
operativo y la implementación de sistemas que aseguren el funcionamiento eficaz de los sistemas.

Ver también la Sección 4.48 en el Capítulo 4.

B.28 Servicios paquetizados

Servicios que se adquieren en el mercado de un proveedor comercial disponible (COTS), en lugar de construirse a través de la
creación de código.

64 The Open Group Standard (2022) ©

2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Glosario de definiciones complementarias Portabilidad

B.29 Portabilidad
1. La facilidad con la que se puede transferir un sistema, componente, datos o usuario de un
entorno de hardware o software a otro.

2. Una métrica de calidad que se puede usar para medir el esfuerzo relativo para transportar el software para usarlo
en otro entorno o para convertir el software para usarlo en otro entorno operativo, configuración de hardware o
entorno de sistema de software.

B.30 Cartera
Una colección de programas, proyectos y/u operaciones gestionadas como un grupo para lograr objetivos estratégicos.
Por ejemplo, cartera de proyectos, cartera de aplicaciones, cartera de tecnología o cartera de servicios.

Nota: La gestión de carteras es el acto de gestionar carteras.

B.31 PRÍNCIPE2
Acrónimo de PRojects IN Controlled Environments, que es un método estándar de gestión de proyectos.

B.32 Programa
Un conjunto coordinado de proyectos de cambio que brindan beneficios comerciales a la organización.

B.33 Proyecto
Un único proyecto de cambio que aporta beneficios empresariales a la organización.

B.34 Gestión de riesgos

La gestión de riesgos y problemas que pueden amenazar el éxito de la práctica de Enterprise Architecture y su
capacidad para cumplir con su visión, metas y objetivos y, lo que es más importante, su prestación de servicios.

Nota: La gestión de riesgos se describe en el estándar TOGAF: contenido de la arquitectura.

B.35 Escalabilidad
La capacidad de usar el mismo software de aplicación en muchas clases diferentes de plataformas de hardware/
software, desde PC hasta supercomputadoras (amplía el concepto de portabilidad). La capacidad de crecer para
adaptarse a mayores cargas de trabajo.

Estándar TOGAF® — Introducción y conceptos básicos sesenta y cinco

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

Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Seguridad Glosario de definiciones complementarias

B.36 Seguridad
Servicios que protegen los datos, asegurando su confidencialidad, disponibilidad e integridad.

B.37 Servidor
Un componente de aplicación que responde a las solicitudes de un cliente.

B.38 Calidad del Servicio

Una configuración preestablecida de atributos no funcionales que pueden asignarse a un servicio o contrato de servicio.

B.39 INTELIGENTE
Acrónimo de Specific, Measurable, Actionable, Realistic y Timebound, que es un enfoque para garantizar que las metas
y los objetivos se establezcan de una manera que se pueda lograr y medir.

B.40 Gestión de proveedores

La gestión de proveedores de productos y servicios para la práctica de Enterprise Architecture en conjunto con
actividades de adquisiciones corporativas más grandes.

B.41 Sistema
Una combinación de elementos que interactúan organizados para lograr uno o más propósitos establecidos.
(Fuente: ISO/IEC/IEEE 15288: 2015)

B.42 Período de tiempo

El marco de tiempo durante el cual se medirá el impacto potencial.

B.43 Caso de uso

Una vista de la funcionalidad de la organización, aplicación o producto que ilustra las capacidades en contexto con el
usuario de esa capacidad.

66 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Glosario de definiciones complementarias Usuario

B.44 Usuario
1. Cualquier persona, organización o unidad funcional que utilice los servicios de un sistema de procesamiento de
información.

2. En un lenguaje de esquema conceptual, cualquier persona o cualquier cosa que pueda emitir o recibir
comandos y mensajes hacia o desde el sistema de información.

Estándar TOGAF® — Introducción y conceptos básicos 67

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Glosario de definiciones complementarias

68 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Apéndice C: Abreviaturas

TEJIDO Bloque de construcción de arquitectura

Modelo de madurez de la capacidad de la arquitectura ACMM

ADM Método de desarrollo de arquitectura

ANSI Instituto Americano de Estándares Nacionales

API Interfaz de plataforma de aplicación

LETRAS Asociación para Estándares de Tecnología Minorista

BMM Modelo de Motivación Empresarial

BPM Gestión de Procesos de Negocio

BPMN Notación de modelado de procesos de negocio

BTEP El Programa de Habilitación para la Transformación Empresarial del Gobierno de Canadá

MMC Modelos de madurez de capacidad

CMMI Integración del modelo de madurez de capacidad

COBIT Objetivos de control para tecnologías de la información y relacionadas

CUNAS Aplicaciones comerciales listas para usar

CRM Gestión de la relación con el cliente

CRUD Crear/Leer/Actualizar/Eliminar

LCR Factor crítico de éxito

administrador de bases de datos Administrador de base de datos

SGBD Sistema de administración de base de datos

Doc Departamento de Comercio de EE. UU.

Departamento de Defensa
Departamento de Defensa de EE. UU.

DODAF Marco de arquitectura del Departamento de Defensa

IAE Integración de aplicaciones empresariales

EDIFACT (Naciones Unidas) Intercambio electrónico de datos para administración, comercio y transporte

ERP Planificación de recursos empresariales

ETL Extraer, Transformar, Cargar

FICO Corporación Fair Isaac

Estándar TOGAF® — Introducción y conceptos básicos 69

© 2005-2022 El Grupo Abierto, Todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

abreviaturas

ETC Equivalente a tiempo completo

GOTS Aplicaciones estándar del gobierno

HIPAA Ley de Responsabilidad y Portabilidad del Seguro de Salud

ICAM Fabricación integrada asistida por computadora

ICOM Entradas, Controles, Salidas y Mecanismos/Recursos

IDEF Fabricación integrada asistida por computadora (ICAM) DEFinición

CEI Comisión Electrotécnica Internacional

IEEE Instituto de Ingenieros Eléctricos y Electrónicos

III-RM Modelo de Referencia de Infraestructura de Información Integrada

internet de las cosas

Internet de las Cosas

ISACA Asociación de Auditoría y Control de Sistemas de Información

ISACF Fundación de Auditoría y Control de Sistemas de Información

YO ASI Organización de Estándares Internacionales

ESO
Tecnologías de la información

ITGI Instituto de Gobernanza de TI

ITIL Infor mación Tecnología Infraestructura Biblioteca

ITPMF Facilidad de gestión de cartera de TI

J2EE Java2Platfor m, edición Enterprise

KPI Indicador clave de rendimiento

LAN Red de área local

MDA Arquitectura basada en modelos

MSA Arquitectura de microservicios

MSP Gestión de programas exitosos

MVA Arquitectura Mínima Viable

NAF Marco de arquitectura de la OTAN

NASCIO Asociación Nacional de Oficiales Principales de Información del Estado

OCDE Organización para la Cooperación Económica y el Desarrollo

OGC Oficina de Comercio del Gobierno del Reino Unido

OLA Acuerdo de nivel operativo

OGP Oficina de Gerencia y Presupuesto

DIOS MÍO grupo de administración de objetos

ORBE Agente de solicitud de objetos

OSI Sistemas abiertos de interconexión

70 El estándar de grupo abierto (2022)

© 2005-2022 El Grupo Abierto, Todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

abreviaturas

OSOA Arquitectura abierta orientada a servicios

PDF Formato de Documento Portable

Cuerpo de conocimientos de gestión de proyectos del PMBOK

PRÍNCIPE Proyectos en Ambientes Controlados

QoS Calidad de servicio

RAS Servicios de acceso remoto

RFC Solicitud de cambio

RFI Solicitud de Información

RFP Solicitud de propuesta

RM Modelo de referencia

SBB Bloque de creación de soluciones

SCA Arquitectura de componentes de servicio

SDO Objetos de datos de servicio

SEI Instituto de Ingeniería de Software

SGML Lenguaje de marcado generalizado estándar

ANS Acuerdo de nivel de servicio

SMART específico, medible, procesable, realista y con límite de tiempo

SOA Arquitectura orientada a Servicios

SPEM Metamodelo de ingeniería de procesamiento de software

SysML Lenguaje de modelado de sistemas

TAFIM Marco de arquitectura técnica para la gestión de la información

TRM Modelo de referencia técnica

UML Lenguaje de modelado unificado

PÁLIDO Red de área amplia

XML Lenguaje de marcado extensible

Estándar TOGAF® — Introducción y conceptos básicos 71

© 2005-2022 El Grupo Abierto, Todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

abreviaturas

72 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Índice

ABB .................................................. .................................................... ............42

abreviaturas .................................... .................................................... ...........69
abstracción .......................................... .................................................... .......23, 41 abstracción,
conceptual..................................... ............................................24 abstracción,
contextual .. .................................................... ..............................24 abstracción,
lógica ................ .................................................... ..................24 abstracción,
física ........................ .................................................... ...........24
actor .................................. .................................................... .......................41
ADM ......................... .................................................... ................... ..........25, 43
aplicación .................................... .................................................... ...............42 Arquitectura de
la aplicación ................................ ..........................................16, 41 Plataforma de aplicación
m.. .................................................... ....................................42 Servicio de
aplicaciones ............. .................................................... ..........................42 Software de
aplicación ....................... .................................................... ............61 estilo
arquitectónico.................................... .................................................... .....42
arquitectura ................................................ .................................................... ......42
definición .......................................... .................................................... ........15 Bloque de
construcción de arquitectura ............................... ......................... ............42 Capacidad de la
arquitectura .................................. ..........................................28, 33 Continuo de
Arquitectura .... .................................................... ....................27, 43 Método de desarrollo de la
arquitectura.................... ..........................................43 dominio de la
arquitectura ....... .................................................... .............................43 Foro de
Arquitectura .................. .................................................... ......................1 Marco de
arquitectura ......................... .................................................... .....43 Gobernanza de la
arquitectura ....................................... ....................................43 Arquitectura
Paisaje ........... .................................................... .............28, 43 nivel de
arquitectura................................ .................................................... .........44 Metamodelo de
arquitectura........ .................................................... ..........................28 modelo de
arquitectura ......................... .................................................... .............44 partición de
arquitectura ............................... .................................................... .44 Principio de
arquitectura ............................................... ..........................................44 Principios de
arquitectura ......... .................................................... ...........24-25 Repositorio de
Arquitectura ........................... .................................................... ...27 Repositorio de requisitos
de arquitectura........................................... ..............29 estilos de
arquitectura.................................... .................................................... ......36 vista de la
arquitectura.................................... .............................................37, 44 mirador de la
arquitectura . ........................................ ....................................37, 44 Visión de la
arquitectura ......... .................................................... .............................45
artefacto .................. .................................................... .......................................45
disponibilidad ......... .................................................... ..........................................61 línea de
base ...... .................................................... ..........................................45 Límite Flujo de
información sin datos ............................................... ..........................45 bloque de
construcción ......................... .................................................... .....................45 Arquitectura
empresarial .......................... .................................................... .15, 46

Estándar TOGAF® — Introducción y conceptos básicos 73

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Índice

capacidad de negocio .................................................. ..........................................46 función

empresarial ....... .................................................... ..................................46 gobierno
empresarial .............. .................................................... ..................46 modelo de
negocio ............................... .................................................... ..........46 servicio
comercial ............................... .................................................... ..........46 sistema de
negocios ....................................... .................................................... ....61
capacidad ................................................ .................................................... .........46 Arquitectura
de capacidades....................................... .............................................47 incremento de
capacidad ... .................................................... ...............................47 catálogo
g .................................................. .................................................... .......61
cliente ............................................. .................................................... ....................61
COBIT ............................... .................................................... ..........................61 gestión de las
comunicaciones ............... .............................................34, 47 preocupación
n. .................................................... .................................................... ....47 condiciones de
uso.......................................... .................................................... .6 gestión de la
configuración ............................................. .......................35, 62 Marco de
contenido ...................... .................................................... ...............29 conceptos
básicos ................................ .................................................... .............15 curso de
acción ................................................. ..........................................47
CxO ..... .................................................... .................................................... ......62 Arquitectura
de datos ......................................... ..........................................15, 47 diccionario de
datos .. .................................................... ..........................................62 elemento de
datos ..... .................................................... ..........................................62 base de
datos ...... .................................................... .............................................62 gestión de base de
datos sistema................................................. ....................62
entregable ................................ .................................................... .......................48 arquitectura
digital.......................... .................................................... ...............48 abajo
cargas ............................................... .................................................... ....7
IA .................................................. .................................................... ....................26 usuario
final ............................... .................................................... .........................62 entrar
premio ...................... .................................................... ..........................2, 48 entrar premio
agilidad .................. .................................................... ........................38 Arquitectura
empresarial ...................... .................................................... ...........2 Servicio de arquitectura
empresarial .................................. ...................................48 Servicios de arquitectura
empresarial .......... .................................................... .......18 Entrar premio
Continuum ....................................... ..........................................26, 48 Participar premio
Metamodelo.................................................... ..............................29, 31 Principios
empresariales .............. .................................................... .....................24 Sistema de
planificación de recursos empresariales .................. ...................................63 gestión del medio
ambiente ............ .................................................... ..............35
ERP ............................... .................................................... ..........................63 gestión
financiera ............... .................................................... ............34 Arquitectura de
cimentación.................................... .............................................48
marco ... .................................................... ..........................................48
brecha .................................................... .................................................... ............49
gobernanza ............ .................................................... .....................................49 Repositorio de
Gobernanza .......... .................................................... ....................28
ferretería ......................... .................................................... .........................63 infor
mación ...................... .................................................... ............................49 dominios de
información .................. .................................................... ..........63

74 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Machine Translated by Google
Copia de evaluación

Índice

sistema de informacion ............................................... .............................................63 tecnología

de la información ..... .................................................... ..........................49
interacción .......................... .................................................... .............................63 modelo de
interacción.................. .................................................... ........................63
interfaz ........................ .................................................... ..............................63
interoperabilidad .................. .................................................... .....................25, 49
ES ......................... .................................................... ..........................................63 ISO/IEC/
IEEE 42010:2011 . .................................................... ........................15
TI ............................. .................................................... ......................... ................49
iteración ................................ .................................................... .......................39 Indicador clave
de rendimiento .................. .................................................... .....63
KPI .......................................... .................................................... ...................63
nivel................................. .................................................... ..........................39 ciclo de
vida ................ .................................................... .......................................64
lógico ......... .................................................... ..........................................................49 Gestión
de programas exitosos .............................................. ....................64 matriz
ix ........................... .................................................... ..............................64
metadatos .................. ..................................... ..........................................................49
metamodelo .................................................. .................................................... .49
metavista.................................................... .................................................... ......64
método .................................. .................................................... ..............50
modelo .................................. .................................................... ........................50 tipo de
modelo ....................... .................................................... ..........................50
MSP .......................... .................................................... ..........................................64
MVA ......... .................................................... .................................................... .20
objetivo................................................... .................................................... .......50 sistema
abierto ............ .................................................... ...................................64 gobernanza
operativa ............ .................................................... ....................64 paquetes de
servicios ............................. .................................................... .........64
partición ...................................... .................................................... .................39 patrón
n.................................. .................................................... ..........................50 gestión del
rendimiento .................. .................................................... .......34
físico ............................................. .................................................... ..............50
portabilidad .................................. .................................................... ...................65
cartera ................................ .................................................... ..........................65 IMPRIMIR
CE2 .................................................. .................................................... ...65 por
principio .................................................. .................................................... ..........50
producto .................................. .................................................... ....................50
programa ............................... .................................................... .........................65
proyecto ....................... .................................................... ....................................65 gestión de
la calidad ............. .................................................... ......................35 Biblioteca de
referencia ........................ .................................................... ...............28 modelos de
referencia ................................ .................................................... ........51
requisito ................................................ .......................................... ................51 gestión de
recursos .................................. .................................................... .34 gestión de
riesgos ............................................... ..........................34, 39, 65
RM ............ .................................................... .................................................... 51 hoja de
ruta .................................................. .................................................... ......51
función ................................................ .................................................... ....................51
SBB ................................. .................................................... ..........................52

Estándar TOGAF® — Introducción y conceptos básicos 75

© 2005-2022 The Open Group, todos los derechos reservados
Copia de evaluación. No para redistribución
Machine Translated by Google
Copia de evaluación

Índice

escalabilidad .................................................. .................................................... ...65

seguridad ................................................ .................................................... ...........66 Arquitectura
de segmento .................................. .......................................................51
servidor .................................................... .................................................... ........66
servicio ....................................... .................................................... ..52 categor ías de
servicio ........................... .................................................... ...........18 modelo de entrega de ser
vicios ........................... ..........................................................18 Gestión De
Servicios ............................................... .....................................34 servicio o
orientación........ .................................................... ............. ...........52 cartera de ser
vicios ........................... .................................................... ................52 calidades de
servicio ............................... .................................................... ............66 Arquitectura Orientada
a Servicios ............................... .......................................52
INTELIGENTE ......... .................................................... ........................................50, 66
SOA ...... .................................................... .................................................... ....52 Arquitectura
de la solución ........................................... ..........................................52 bloque de construcción
de la solución.... .................................................... .............................52 Continuo de
soluciones .................. .................................................... ...........27, 52 Panorama de
soluciones ............................... ...................................... ............29 parte
interesada .................................... .................................................... .............53 gestión de
grupos de interés ............................... .....................................34, 47 Biblioteca de
normas ....... .................................................... ..........................28, 53 Arquitectura
Estratégica.................... .................................................... ...............53 gestión de
proveedores ................................ .............................................35, 66
sistema . .................................................... .................................................... .....66
TAFÍM ........................................... .................................................... ................1 Arquitectura de
destino .................................. .................................................... .......53 taxonomía de vistas de
arquitectura .................................. ...............................53 Te Arquitectura de
tecnología .............................................. ..........................16, 53 componente
tecnológico.................... .................................................... .............53 servicio de
tecnología ............................... .................................................... ....54 El Grupo
Abierto................................................ .................................................... .7 período de
tiempo .............................................. .................................................... ....66
TOGAF .................................... .................................................... ..............1 ADM
TOGAF ............................... .................................................... ..............25 Marco de contenido
TOGAF ............................... .......................................29 Biblioteca
TOGAF..... .................................................... ..........................10, 13 Estándar
TOGAF .......... .................................................... ..............................10 Arquitectura de
transición .................. .................................................... ..........54 Departamento de Defensa de
EE. UU. ............................. .................................................... ..........................1 caso de
uso ...................... .................................................... .............................66
usuario ............... .................................................... .............................................67 flujo de
valor . .................................................... ...................................................54
ver.. .................................................... .................................................... .........54
mirador ....................................... .................................................... ..............54 biblioteca de
puntos de vista ................................ .................................................... .......... 54 paquete de
trabajo .............................................. ..........................................................54

76 The Open Group Standard (2022)

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución