C220 Part5e

Machine Translated by Google
Copia de evaluación
El estándar de grupo abierto
Estándar TOGAF® : capacidad y gobernanza de la arquitectura empresarial
El grupo abierto
© 2005-2022 The Open Group, todos los derechos reservados

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

© 2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para
redistribución
Contenido
Capítulo 1 Introducción .................................................. ................................ 1
Capitulo 2 Establecimiento de una capacidad de arquitectura ........... 3

2.1 Visión general................................................ ............................................. 3
2.2 Fase A: Visión de la Arquitectura................................................ ............. 4
2.3 Fase B: Arquitectura empresarial.................................................... ........ 5
2.4 Fase C: Arquitectura de datos ............................................... ............... 6
2.5 Fase C: Arquitectura de la aplicación ........................................... ..... 6
2.6 Fase D: Arquitectura Tecnológica ............................................... .... 6
2.7 Fase E: Oportunidades y soluciones ............................................... ... 6
2.8 Fase F: Planificación de la migración ............................................. ............. 6
2.9 Fase G: Implementación Gobernanza ............................................. 6
2.10 Fase H: Gestión del Cambio de Arquitectura...................................... 7
2.11 Gestión de requerimientos ................................................ .......... 7
Capítulo 3 Gobernanza de la arquitectura .................................................. ....... 9

3.1 Introducción................................................. .................................... 9
3.1.1 Niveles de Gobernanza dentro de la Empresa ........................... 9
3.1.2 Naturaleza de la Gobernanza .................................................. .................... 10
3.1.3 Gobernanza de la tecnología .................................................. ............. 11
3.1.4 Gobernanza de TI .................................................. ............................. 11
3.1.5 Gobernanza de la arquitectura: visión general ................................ 12
3.2 Marco de Gobernanza de la Arquitectura ....................................... 13
3.2.1 Marco de Gobernanza de la Arquitectura — Conceptual
Estructura................................................ ...................................... 13
3.2.2 Marco de Gobernanza de la Arquitectura —
Estructura organizativa ................................................ .............. dieciséis
3.3 Gobernanza de la arquitectura en la práctica ............................................... 18
3.3.1 Gobernanza de la arquitectura: factores clave de éxito .................. 18
3.3.2 Elementos de una Gobernanza de Arquitectura Efectiva
Estrategia ................................................. ...................................... 19
Capítulo 4 Junta de Arquitectura ................................................. ..................... 21

4.1 Role................................................. ............................................... 21
4.2 Responsabilidades................................................. ............................. 21
4.3 Configuración de la placa de arquitectura ............................................ ..... 22
4.3.1 Desencadenantes .................................................. .......................................... 22
4.3.2 Tamaño de la Junta .................................................. .......................... 23
4.3.3 Estructura de la Junta .................................................. ............................. 24
4.4 Funcionamiento de la Junta de Arquitectura .............................................. .. 24
4.4.1 General ................................................. .......................................... 24
4.4.2 Preparación ................................................. ............................. 25
Estándar TOGAF® : capacidad y gobernanza de la arquitectura empresarial iii

© 2005-2022 El Grupo Abierto, Todos los derechos reservados
Contenido
4.4.3 Agenda................................................. .......................................... 25
Capítulo 5 5.1 5.2 Contratos de arquitectura ................................................ ............ 27

Role................................................. ............................................... 27
Contenido .................................................. .......................................... 29
5.2.1 Declaración de Trabajo Arquitectónico ............................................... ...... 29
5.2.2 Contrato entre Diseño de Arquitectura y
Socios de desarrollo ............................................... .................... 29
5.2.3 Contrato entre Función Arquitectónica y
Partes interesadas de la empresa .................................................. .......... 30
5.3 Relación con la Gobernanza de la Arquitectura ....................................... 30
Capítulo 6 6.1 6.2 Cumplimiento de la arquitectura ................................................... ........ 31

6.3 Introducción................................................. .................................... 31
Terminología: el significado de la conformidad con la arquitectura ........... 31
Revisiones de Cumplimiento de la Arquitectura .............................................. ... 33
6.3.1 Objetivo ................................................. ...................................... 33
6.3.2 Momento................................................. .......................................... 34
6.3.3 Escenarios de Gobernanza y Personal ............................................. 35
6.4 Proceso de revisión del cumplimiento de la arquitectura .......................... 36
6.4.1 Visión general................................................ ...................................... 36
6.4.2 Papeles .................................................. .......................................... 37
6.4.3 Pasos ................................................. .......................................... 38
6.5 Listas de verificación de revisión del cumplimiento de la arquitectura .................. 39
6.5.1 Lista de verificación de hardware y sistema operativo .......................... 39
6.5.2 Lista de comprobación de servicios de software y middleware ................ 40
6.5.3 Listas de verificación de aplicaciones .................................................. .......... 42
6.5.4 Listas de control de la gestión de la información ........................... 44
6.5.5 Lista de control de seguridad ................................................ ........................ 45
6.5.6 Lista de verificación de la gestión del sistema ............................................... .... 46
6.5.7 Ingeniería de sistemas/Arquitectura general
Listas de control .................................................. .................................... 47
6.5.8 Lista de verificación de ingeniería de sistemas/métodos y herramientas ........ 50
6.6 Directrices de revisión del cumplimiento de la arquitectura .......................... 51
6.6.1 Adaptación de las listas de verificación ............................................... .................... 51
6.6.2 Realización de revisiones de cumplimiento de la arquitectura ............ 52
Índice .................................................. ............................................. 53
Lista de Figuras
3-1 Marco de Gobernanza de la Arquitectura — Conceptual

Estructura................................................ ............................................. 13
3-2 Marco de Gobernanza de la Arquitectura — Organizacional
Estructura................................................ ............................................ dieciséis
6-1 Niveles de Conformidad con la Arquitectura.................................................. ..... 31
6-2 Proceso de revisión del cumplimiento de la arquitectura ............................ 36
IV El estándar de grupo abierto (2022)

© 2005-2022 El Grupo Abierto, Todos los derechos reservados
Contenido
Estándar TOGAF® : capacidad y gobernanza de la arquitectura empresarial v

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

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

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

redistribución
Prefacio
Este documento
Este es el estándar TOGAF: capacidad y gobernanza de la arquitectura empresarial.
Público objetivo
El estándar TOGAF está destinado a arquitectos empresariales, arquitectos comerciales, arquitectos de TI, arquitectos de datos,
arquitectos de sistemas, arquitectos de soluciones y cualquier persona responsable de la función de arquitectura dentro de una
organización.
Agradecimientos
The Open Group agradece la contribución de muchas personas y organizaciones en el desarrollo del estándar TOGAF. Consulte el
Estándar TOGAF: Introducción y conceptos básicos para obtener más detalles.
Estándar TOGAF® : capacidad y gobernanza de la arquitectura empresarial viii

Marcas registradas
ArchiMate, DirecNet, Making Standards Work, el logotipo de Open O, Open O y el logotipo de Check Cer tification, The Open
Group, TOGAF, UNIX, UNIXWARE y el logotipo de Open Brand X son marcas comerciales registradas y flujo de información sin
límites, compilado con Integridad Compre con confianza, Arquitectura de referencia de aviación comercial, Fiabilidad a través de la
garantía, Cuerpo de conocimiento del profesional digital, DPBoK, EMMM, FACE, el logotipo de FACE, FHIM Profile Builder, el
logotipo de FHIM, FPB, Future Airborne Capability Environment, IT4IT, el logotipo de IT4IT , O-AA, O-DEF, O-HERA, O-PAS, Open
Agile Architecture, Open FAIR, Open Footprint, Open Process Automation, Open Subsurface Data Universe, Open Trusted
Technology Provider, OSDU, Sensor Integration Simplified, SOSA, y el logotipo de SOSA son marcas registradas de The Open
Group.
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.
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.
viii The Open Group Standard (2022)

redistribución
documentos de referencia
Consulte el Estándar TOGAF: Introducción y conceptos básicos: Apéndice A para ver los documentos a los que se hace referencia
en el Estándar TOGAF.
Estándar TOGAF® : capacidad y gobernanza de la arquitectura empresarial ix

documentos de referencia
X The Open Group Standard (2022)

redistribución
Capítulo 1 Introducción
Este capítulo proporciona una introducción a la orientación proporcionada en el estándar TOGAF: capacidad y gobernanza de la
arquitectura empresarial (este documento).
Para operar con éxito una función de arquitectura dentro de una empresa, es necesario establecer estructuras de organización,
procesos, roles, responsabilidades y gobierno apropiados.
Las pautas incluidas en este documento son las siguientes:
ÿ El establecimiento de una capacidad de arquitectura (consulte el Capítulo 2) proporciona pautas sobre cómo usar el ADM
para establecer una capacidad de arquitectura
ÿ Gobernanza de la arquitectura (consulte el Capítulo 3) proporciona un marco y pautas para la arquitectura.

Gobernancia
ÿ El Consejo de Arquitectura (consulte el Capítulo 4) brinda pautas para establecer y operar una empresa
Junta de arquitectura
ÿ Contratos de Arquitectura (consulte el Capítulo 5) proporciona pautas para definir y usar Arquitectura
Contratos
ÿ Cumplimiento de la arquitectura (consulte el Capítulo 6) proporciona pautas para garantizar el cumplimiento del proyecto con el
arquitectura
Estándar TOGAF® : capacidad y gobernanza de la arquitectura empresarial 1

Introducción
2 The Open Group Standard (2022)

redistribución
Capítulo 2: Establecimiento de una capacidad de arquitectura
Este capítulo proporciona pautas sobre cómo utilizar el ADM para establecer una capacidad de arquitectura.
2.1 Resumen
Al igual que con cualquier capacidad empresarial, el método de desarrollo de arquitectura TOGAF (ADM) puede
respaldar el establecimiento de una capacidad de arquitectura empresarial. El uso exitoso de ADM proporcionará una
práctica de arquitectura sostenible, de valor agregado y enfocada en el cliente que habilita el negocio, ayuda a maximizar
el valor de las inversiones e identifica de manera proactiva oportunidades para obtener beneficios comerciales y
administrar el riesgo.
El establecimiento de una práctica de arquitectura sostenible dentro de una organización se puede lograr adhiriéndose
al mismo enfoque que se utiliza para establecer cualquier otra capacidad, como una capacidad de gestión de procesos
comerciales (BPM), dentro de una organización. El ADM es un método ideal para diseñar y gobernar la implementación
de dicha capacidad. Aplicar el ADM con la Visión de Arquitectura específica para establecer una práctica de arquitectura
dentro de la organización lograría este objetivo.
El establecimiento de la práctica de la arquitectura no debe verse como una fase de un proyecto de arquitectura, o un
proyecto único, sino como una disciplina continua que proporciona el contexto, el entorno y los recursos para gobernar
y permitir la entrega de la arquitectura a la organización. . A medida que se ejecuta un proyecto de arquitectura dentro
de este entorno, podría solicitar un cambio en la práctica de la arquitectura que desencadenaría otro ciclo del ADM para
extender la práctica de la arquitectura.
La implementación de cualquier capacidad dentro de una organización requeriría el diseño de las cuatro arquitecturas
de dominio: Negocios, Datos, Aplicaciones y Tecnología. Por lo tanto, establecer la práctica de la arquitectura dentro de
una organización requeriría el diseño de:
ÿ La Arquitectura de Negocios de la práctica de la arquitectura que destacará la Gobernanza de la Arquitectura,

los procesos de la arquitectura, la estructura organizativa de la arquitectura, los requisitos de información de la
arquitectura, los productos de la arquitectura, etc.
ÿ La Arquitectura de Datos que definiría la estructura de la Empresa de la organización

Repositorio Continuum y Arquitectura
ÿ La arquitectura de aplicaciones que especifica la funcionalidad y/o los servicios de aplicaciones necesarios para
permitir la práctica de la arquitectura
ÿ La arquitectura tecnológica que describe los requisitos de infraestructura de la práctica de arquitectura y la

implementación en apoyo de las aplicaciones de arquitectura y la empresa.
continuo
Los pasos para establecer una práctica de arquitectura se explican a continuación, en el contexto de las fases de ADM.
Por lo tanto, el lector debe consultar la fase ADM relevante en el estándar TOGAF: método de desarrollo de arquitectura
para comprender el alcance completo de cada paso.

Visión general Establecimiento de una capacidad de arquitectura
En esta sección, se resaltarán los aspectos clave para cada fase de ADM que deben considerarse y son específicos para
establecer una práctica de arquitectura. Por lo tanto, la intención no es repetir la descripción de cada fase de ADM, sino
guiar al lector para que aplique cada fase de ADM dentro del contexto de establecer una práctica de arquitectura.
2.2 Fase A: Visión de la Arquitectura

El propósito de esta fase dentro del contexto de establecer una práctica de arquitectura es definir o revisar la visión, las
partes interesadas y los principios de la práctica de arquitectura. El enfoque en esta fase estaría en la práctica de la
arquitectura como un todo y no en un proyecto de arquitectura en particular.
Se debe considerar lo siguiente en términos de comprensión de los pasos en el contexto de establecer una práctica de
arquitectura:
ÿ Establecimiento del Proyecto: este paso debe centrarse en definir las partes interesadas en la práctica de la
arquitectura .
Las partes interesadas incluirían los roles y las unidades organizativas que participan en la práctica de la
arquitectura, así como las personas que se beneficiarán de los productos generados por la práctica de la arquitectura
y que, por lo tanto, pueden definirse como clientes de la práctica de la arquitectura.
ÿ Identificar las partes interesadas y las preocupaciones, los requisitos comerciales y la arquitectura
Visión: este paso genera las primeras definiciones de muy alto nivel de los entornos de referencia y de destino,
desde la perspectiva de los sistemas y la tecnología de información empresarial, para la práctica de la arquitectura.
ÿ Identificar los objetivos comerciales y los impulsores comerciales: una comprensión de los objetivos comerciales
y drivers es esencial para alinear la práctica de la arquitectura con el negocio
ÿ Definir el alcance: definir el alcance de la práctica de la arquitectura es un plan de proyecto de alto nivel de
lo que se tiene programado abordar en cuanto a arquitectura para el próximo período
ÿ Definir restricciones: el enfoque en este paso son las restricciones de toda la empresa que impactan en
todos los proyectos de arquitectura
ÿ Revisar los Principios de arquitectura, incluidos los Principios comerciales: la intención de este paso es definir
los principios que rigen y guían el funcionamiento de la práctica de la arquitectura.
Donde los Principios de Arquitectura generalmente rigen los entregables de la arquitectura, los principios de la
práctica de la arquitectura abordan la organización, el contenido, las herramientas y el proceso de la práctica de la
arquitectura.
ÿ Desarrollar Declaración de Trabajo de Arquitectura y Aprobación segura: este paso genera la

visión y alcance de la práctica de la arquitectura
Otro paso que se puede considerar durante esta fase es realizar una evaluación de la madurez de la arquitectura. Consulte
la Guía de la serie TOGAF® : Modelos de madurez de la arquitectura para obtener orientación sobre este tema.

redistribución
Establecimiento de una capacidad de arquitectura Fase B: Arquitectura Empresarial
2.3 Fase B: Arquitectura empresarial

Las áreas clave de enfoque durante esta fase de establecimiento o perfeccionamiento de la arquitectura comercial de la
práctica de la arquitectura son:
ÿ Una Ontología de Arquitectura que define los términos arquitectónicos y las definiciones que se utilizarán en la
organización para establecer un entendimiento común de estos términos
ÿ El proceso de arquitectura donde el ADM formaría la base del proceso y debe personalizarse para cumplir con
los requisitos de la organización y la visión de la práctica de la arquitectura. Consulte el estándar TOGAF: método
de desarrollo de arquitectura para obtener orientación sobre el desarrollo de este proceso. Los procesos
requeridos de Gobernanza de la Arquitectura deben incluirse en el proceso de arquitectura general.
ÿ Los puntos de vista y vistas de la arquitectura que enumeran todos los puntos de vista y vistas que debe abordar
la práctica de la arquitectura
Las partes interesadas de la práctica de la arquitectura identificadas guiarían el desarrollo de esta definición. Uno
de los puntos de vista a incluir es el de Gobernanza de la Arquitectura; consulte el estándar TOGAF: contenido
de la arquitectura para obtener orientación sobre este resultado.
ÿ El marco de arquitectura que describe los diversos entregables de arquitectura que generará la práctica de la
arquitectura, las interrelaciones y dependencias entre los entregables de arquitectura, así como las reglas y
directrices que rigen el diseño de estos entregables.
Los puntos de vista y puntos de vista de la arquitectura definidos deben usarse para guiar la definición del marco
de la arquitectura. El estándar TOGAF: método de desarrollo de la arquitectura y el estándar TOGAF: contenido
de la arquitectura son referencias útiles que ayudarán a describir el marco de la arquitectura.
ÿ La Matriz de Responsabilidad de la Arquitectura que define los roles en la práctica de la arquitectura y asigna
la responsabilidad de los roles a los entregables y procesos de la arquitectura. Esta matriz incluiría las estructuras
y los roles necesarios para el Gobierno de la Arquitectura. El estándar TOGAF: Método de desarrollo de
arquitectura, así como el Capítulo 4, el Capítulo 3 y la Guía de la serie TOGAF® : Marco de habilidades de
arquitectura brindarían orientación sobre este resultado.
ÿ Las métricas de desempeño de la arquitectura que identifican y describen las métricas que se utilizarán para
monitorear el desempeño de la práctica de la arquitectura en comparación con la visión y los objetivos establecidos
de la práctica de la arquitectura.
ÿ El Marco de Gobernanza de la Arquitectura, que es una vista específica del proceso de arquitectura definido y
la Matriz de Responsabilidad de la Arquitectura.

Fase C: Arquitectura de datos Establecimiento de una capacidad de arquitectura
2.4 Fase C: Arquitectura de datos

La Arquitectura de Datos de la práctica de la arquitectura especificaría y regiría la estructura del Continuo Empresarial
y el Repositorio de Arquitectura de la organización. La arquitectura de datos debe definirse en función del marco de la
arquitectura. La arquitectura de datos a veces se denomina el metamodelo de la práctica de la arquitectura.
2.5 Fase C: Arquitectura de la aplicación

La arquitectura de aplicaciones de la práctica de la arquitectura define la funcionalidad requerida para generar, mantener,
publicar, distribuir y gobernar los entregables de la arquitectura como se define en el marco de la arquitectura. Un
enfoque clave debe estar en los conjuntos de herramientas de modelado necesarios para el modelado, pero no debe
ser el solo enfoque. Consulte el estándar TOGAF: método de desarrollo de arquitectura para obtener orientación sobre
cómo seleccionar un conjunto de herramientas. La publicación de los entregables de la arquitectura para abordar vistas
específicas en el marco de la arquitectura a veces requeriría una funcionalidad especializada o personalizada y no debe
descuidarse.
2.6 Fase D: Arquitectura Tecnológica

La Arquitectura Tecnológica de la práctica de la arquitectura debe definir la infraestructura tecnológica que soporta la
práctica de la arquitectura.
2.7 Fase E: Oportunidades y Soluciones

Un factor crítico a considerar durante esta fase de planificación del establecimiento de la práctica de la arquitectura es
el cambio organizacional que se requiere y cómo se logrará.
2.8 Fase F: Planificación de la migración

El enfoque no debe estar solo en los componentes de la Arquitectura de Sistemas de Información en esta fase, sino
que debe incluir la Arquitectura de Negocios. La adopción del proceso y el marco de la arquitectura tendrá un gran
impacto en el establecimiento general de la práctica de la arquitectura en la organización.
2.9 Fase G: Implementación Gobernanza

La implementación de la Arquitectura de Negocios de la práctica de la arquitectura debe ser el foco de esta fase.
Cambiar las prácticas dentro de la organización para adoptar un enfoque más estructurado y disciplinado será un
desafío y debe abordarse con las técnicas de cambio organizacional apropiadas.

redistribución
Establecimiento de una capacidad de arquitectura Fase H: Gestión del cambio de arquitectura
2.10 Fase H: Gestión de cambios de arquitectura

Los cambios en la arquitectura de la práctica de la arquitectura deben ser gestionados por esta fase.
Estos cambios generalmente se desencadenan durante la ejecución de proyectos de arquitectura. Un cambio atípico
sería el requisito para una nueva arquitectura entregable. Esto impactaría en todos los dominios de la arquitectura de la
práctica de la arquitectura.
2.11 Gestión de requisitos

Comprender y gestionar los requisitos para la práctica de la arquitectura es crucial.
Los requisitos deben estar claramente articulados y alineados con la visión de la práctica de la arquitectura.
Puede encontrar orientación adicional sobre cómo construir una capacidad de arquitectura empresarial en la Guía de la
serie TOGAF® : La guía del líder TOGAF para establecer y desarrollar una capacidad de EA.

Establecimiento de una capacidad de arquitectura

redistribución
Capítulo 3: Gobernanza de la arquitectura
Este capítulo proporciona un marco y directrices para la Gobernanza de la Arquitectura.
3.1 Introducción
Esta sección describe la naturaleza de la gobernabilidad y los niveles de gobernabilidad.
3.1.1 Niveles de Gobernanza dentro de la Empresa

La Gobernanza de la Arquitectura es la práctica y la orientación mediante la cual las Arquitecturas Empresariales y otras
arquitecturas se gestionan y controlan a nivel de toda la empresa.
La Gobernanza de la Arquitectura normalmente no opera de forma aislada, sino dentro de una jerarquía de estructuras de
gobernanza que, particularmente en las empresas más grandes, pueden incluir todo lo siguiente como dominios distintos
con sus propias disciplinas y procesos:
ÿ Gobierno corporativo
ÿ Gobernanza tecnológica
ÿ Gobernanza de TI
ÿ Gobernanza de la arquitectura
Cada uno de estos dominios de gobierno puede existir en múltiples niveles geográficos (global, regional y local) dentro de
la empresa en general.
El gobierno corporativo es, por lo tanto, un tema amplio, más allá del alcance de un marco de arquitectura empresarial
como el marco TOGAF.
Esta y otras subsecciones relacionadas se centran en la gobernanza de la arquitectura; pero lo describen en el contexto del
gobierno de toda la empresa, debido a la jerarquía de las estructuras de gobierno dentro de las cuales normalmente opera,
como se explicó anteriormente.
En particular, esta y las siguientes secciones tienen como objetivo:
ÿ Ofrecer una visión general de la naturaleza de la gobernanza como disciplina por derecho propio
ÿ Describir el contexto de gobernanza en el que la Gobernanza de la Arquitectura normalmente funciona dentro de la

empresa
ÿ Describir un marco práctico de gobernanza de la arquitectura que se pueda adaptar y aplicar, tanto para la arquitectura
empresarial como para otras formas de arquitectura de TI.

Introducción Gobernanza de la arquitectura
3.1.2 Naturaleza de la gobernanza
3.1.2.1 Gobernanza: una perspectiva genérica

La gobernanza se trata esencialmente de garantizar que los negocios se lleven a cabo correctamente. Se trata menos
del control excesivo y el cumplimiento estricto de las reglas, y más de la orientación y el uso efectivo y equitativo de los
recursos para garantizar la sostenibilidad de los objetivos estratégicos de una organización.
A continuación se describen los principios básicos del gobierno corporativo, identificados por la Organización para la
Cooperación y el Desarrollo Económicos (OCDE):
ÿ Se enfoca en los derechos, roles y trato equitativo de los accionistas ÿ Divulgación y
transparencia y las responsabilidades de la junta

ÿ Garantiza:
— Orientación estratégica sólida de la organización
— Supervisión eficaz de la gestión por parte del consejo
— Responsabilidad del directorio ante la empresa y ante los accionistas
ÿ Responsabilidades de la Junta:
— Revisar y orientar la estrategia corporativa
— Establecimiento y seguimiento del logro de los objetivos de rendimiento de la dirección En apoyo
de esto, la OCDE considera una visión tradicional de la gobernanza como: "... el sistema mediante el cual se dirigen y
controlan las sociedades mercantiles. La estructura de gobernanza empresarial especifica la distribución de derechos y
responsabilidades entre los diferentes participantes en la corporación, como la junta directiva, los gerentes, los
accionistas y otras partes interesadas, y detalla las reglas y procedimientos para tomar decisiones sobre asuntos
corporativos Al hacer esto, también proporciona la estructura a través de la cual se establecen los objetivos de la
empresa. se establecen, y los medios para alcanzar esos objetivos y monitorear el desempeño" (Fuente: OCDE, 2001).
3.1.2.2 Características de la Gobernanza
Las siguientes características han sido adaptadas de Corporate Governance (Naidoo, 2002) y se ubican aquí para
resaltar tanto el valor como la necesidad de la gobernabilidad como un enfoque a adoptar dentro de las organizaciones
y sus tratos con todas las partes involucradas:
Disciplina Todas las partes involucradas tendrán el compromiso de adherirse a los procedimientos, procesos
y estructuras de autoridad establecidas por la organización.
Transparencia Todas las acciones implementadas y su apoyo a la decisión estarán disponibles para inspección por
parte de la organización autorizada y las partes proveedoras.
Independencia Todos los procesos, toma de decisiones y mecanismos utilizados se establecerán para
para minimizar o evitar posibles conflictos de intereses.
Rendición de cuentas Los grupos identificables dentro de la organización, por ejemplo, juntas de gobierno que toman
acciones o toman decisiones, están autorizados y son responsables de sus acciones.
Responsabilidad Cada parte contratada está obligada a actuar de manera responsable con la organización y sus
partes interesadas.

redistribución
Gobernanza de la arquitectura Introducción
Justicia No se permitirá que todas las decisiones tomadas, los procesos utilizados y su implementación
creen una ventaja injusta para ninguna de las partes en particular.
3.1.3 Gobernanza tecnológica

El gobierno de la tecnología controla cómo una organización utiliza la tecnología en la investigación, el desarrollo y la
producción de sus bienes y servicios. Aunque puede incluir actividades de gobierno de TI, a menudo tiene un alcance
más amplio.
El gobierno de la tecnología es una capacidad, un requisito y un recurso clave para la mayoría de las organizaciones
debido a la omnipresencia de la tecnología en todo el espectro organizacional.
Estudios recientes han demostrado que muchas organizaciones tienen un equilibrio a favor de los intangibles en lugar
de los tangibles que requieren gestión. Dado que la mayoría de estos intangibles son activos digitales y de información,
es evidente que las empresas se están volviendo más dependientes de TI: y el gobierno de TI (gobierno de TI) se está
convirtiendo, por lo tanto, en una parte aún más importante del gobierno de la tecnología.
Estas tendencias también resaltan las dependencias de las empresas no solo de la información en sí, sino también de
los procesos, sistemas y estructuras que la crean, la entregan y la consumen. A medida que aumenta el cambio hacia
el aumento del valor a través de intangibles en muchos sectores de la industria, la gestión de riesgos debe considerarse
clave para comprender y moderar nuevos desafíos, amenazas y oportunidades.
Las organizaciones no solo dependen cada vez más de TI para sus operaciones y rentabilidad, sino que también su
reputación, marca y, en última instancia, sus valores también dependen de esa misma información y tecnología de
soporte.
3.1.4 Gobierno de TI
El gobierno de TI proporciona el marco y la estructura que vinculan los recursos y la información de TI para emprender
objetivos y estrategias. Además, el gobierno de TI institucionaliza las mejores prácticas para planificar, adquirir,
implementar y monitorear el rendimiento de TI, para garantizar que los activos de TI de la empresa respalden sus
objetivos comerciales.
En los últimos años, el gobierno de TI se ha vuelto parte integral del gobierno efectivo de la empresa moderna. Las
empresas dependen cada vez más de TI para respaldar funciones y procesos comerciales críticos; y para obtener con
éxito una ventaja competitiva, las empresas deben administrar de manera efectiva la tecnología compleja que está
generalizada en toda la organización para responder de manera rápida y segura a las necesidades comerciales.
Además, los entornos regulatorios en todo el mundo exigen cada vez más un control empresarial más estricto sobre la
información, impulsado por el aumento de los informes de desastres en los sistemas de información y fraude electrónico.
La gestión de riesgos relacionados con TI es ahora ampliamente aceptada como una parte clave del gobierno
empresarial.
De ello se deduce que se debe establecer una estrategia de gobierno de TI y una organización apropiada para
implementar la estrategia con el respaldo de la dirección ejecutiva, aclarando quién es el propietario de los recursos de
TI de la empresa y, en particular, quién tiene la responsabilidad final de su empresa. amplia integración.

Introducción Gobernanza de la arquitectura
3.1.4.1 Un Marco de Controles de TI — COBIT
Al igual que con el gobierno corporativo, el gobierno de TI es un tema amplio, más allá del alcance de un marco de
Arquitectura Empresarial como el marco TOGAF. Una buena fuente de información detallada sobre el gobierno de TI
es el marco COBIT® (Control OBjectives for Information and Related Tecnología). Este es un estándar abierto para el
control de TI, desarrollado y promovido por el IT Governance Institute (ITGI), y publicado por la Information Systems
Audit and Control Foundation (ISACF). Los controles de COBIT pueden proporcionar ayudas útiles para ejecutar una
estrategia de cumplimiento.
3.1.5 Gobernanza de la arquitectura: descripción general

3.1.5.1 Características de la Gobernanza de la Arquitectura
La Gobernanza de la Arquitectura es la práctica y la orientación mediante la cual las Arquitecturas Empresariales y otras
arquitecturas se gestionan y controlan a nivel de toda la empresa. Incluye lo siguiente:
ÿ Implementar un sistema de controles sobre la creación y el seguimiento de todos los componentes y actividades
de la arquitectura, para garantizar la introducción, implementación y evolución efectivas de las arquitecturas
dentro de la organización.
ÿ Implementación de un sistema para garantizar el cumplimiento de las normas internas y externas y las obligaciones
regulatorias
ÿ Establecer procesos que apoyen la gestión eficaz de los procesos anteriores dentro
parámetros acordados
ÿ Desarrollar prácticas que garanticen la rendición de cuentas ante una parte interesada claramente identificada
comunidad, tanto dentro como fuera de la organización
3.1.5.2 Gobernanza de la arquitectura como responsabilidad a nivel de directorio
Esta sección tiene como objetivo proporcionar el ímpetu para abrir la Gobernanza de TI y Arquitectura para que las
responsabilidades comerciales asociadas con las actividades y los artefactos de la arquitectura puedan dilucidarse y
administrarse.
3.1.5.3 El estándar TOGAF y la gobernanza de la arquitectura
La fase G de TOGAF ADM (consulte el estándar TOGAF: método de desarrollo de arquitectura) está dedicada a la
gobernanza de la implementación, que se ocupa de la realización de la arquitectura a través de proyectos de cambio.
La gobernanza de la implementación es solo un aspecto de la gobernanza de la arquitectura, que cubre la gestión y el
control de todos los aspectos del desarrollo y la evolución de las arquitecturas empresariales y otras arquitecturas dentro
de la empresa.
La Gobernanza de la Arquitectura debe estar respaldada por un Marco de Gobernanza de la Arquitectura (descrito en
la Sección 3.2) que ayuda a identificar procesos efectivos para que las responsabilidades comerciales asociadas con la
Gobernanza de la Arquitectura puedan dilucidarse, comunicarse y administrarse de manera efectiva.

redistribución
Gobernanza de la arquitectura Marco de Gobernanza de la Arquitectura
3.2 Marco de Gobernanza de la Arquitectura

Esta sección describe un marco conceptual y organizativo para la Gobernanza de la Arquitectura.
Como se explicó anteriormente, la Fase G de TOGAF ADM (consulte el Estándar TOGAF: Método de desarrollo de
arquitectura) está dedicada a la gobernanza de la implementación, que se ocupa de la realización de la arquitectura a
través de proyectos de cambio.
La gobernanza de la implementación es solo un aspecto de la gobernanza de la arquitectura, que cubre la gestión y el

control de todos los aspectos del desarrollo y la evolución de las arquitecturas empresariales y otras arquitecturas
dentro de la empresa.
La Gobernanza de la Arquitectura debe estar respaldada por un Marco de Gobernanza de la Arquitectura, como se
describe a continuación. El marco de gobernanza descrito es un marco genérico que se puede adaptar al entorno de
gobernanza existente de una empresa. Su objetivo es ayudar a identificar procesos y estructuras organizacionales
efectivos, de modo que las responsabilidades comerciales asociadas con la Gobernanza de la Arquitectura puedan
dilucidarse, comunicarse y administrarse de manera efectiva.
3.2.1 Marco de gobernanza de la arquitectura: estructura conceptual 3.2.1.1

Conceptos clave
Conceptualmente, Architecture Governance es un enfoque, una serie de procesos, una orientación cultural y un conjunto
de responsabilidades propias que aseguran la integridad y eficacia de las arquitecturas de la organización.
Los conceptos clave se ilustran en la Figura 3-1.

Marco de Gobernanza de la Arquitectura Gobernanza de la arquitectura
Contexto
Impulsores (negocios, tecnología, regulatorios)
forma organizativa
Proceso Contenido
Gestión y adopción de políticas Requisitos
Cumplimiento SLA y OLA
Dispensa Estructuras de autoridad Repositorio
Monitoreo e informes Estándares organizacionales
Control de Negocios Soluciones
Gestión del Medio Ambiente arquitecturas
Control de flujo de procesos
© El Grupo Abierto
Figura 3-1 Marco de gobernanza de la arquitectura: estructura conceptual
La división de proceso, contenido y contexto es clave para el apoyo de la iniciativa Gobernanza de la Arquitectura, al
permitir la introducción de nuevo material de gobernanza (legal, regulatorio, basado en estándares o legislativo) sin
impactar indebidamente los procesos. Este enfoque independiente del contenido garantiza que el marco sea flexible.
Los procesos suelen ser independientes del contenido e implementan un enfoque probado de mejores prácticas para la
gobernanza activa.
El Marco de Gobernanza de la Arquitectura es parte integral de Enterprise Continuum y gestiona todo el contenido
relevante tanto para la arquitectura en sí misma como para los procesos de Gobernanza de la Arquitectura.
3.2.1.2 Procesos clave de gobernanza de la arquitectura
Los procesos de gobierno son necesarios para identificar, gestionar, auditar y difundir toda la información relacionada
con la gestión, los contratos y la implementación de la arquitectura. Estos procesos de gobierno se utilizarán para
garantizar que todos los artefactos de la arquitectura y los contratos, los principios y los Acuerdos de nivel operativo
(OLA) se supervisen de forma continua con una auditabilidad clara de todas las decisiones tomadas.

redistribución
Gestión y toma de pólizas
Todas las enmiendas a la arquitectura, los contratos y la información de respaldo deben someterse a control a través de
un proceso formal para registrar, validar, ratificar, administrar y publicar contenido nuevo o actualizado. Estos procesos
garantizarán la integración ordenada con el contenido de gobierno existente, de modo que todas las partes, documentos,
contratos e información de respaldo relevantes se gestionen y auditen.
Cumplimiento
Las evaluaciones de cumplimiento con respecto a los acuerdos de nivel de servicio (SLA), los OLA, los estándares y los
requisitos reglamentarios se implementarán de forma continua para garantizar la estabilidad, el cumplimiento y la
supervisión del rendimiento. Estas evaluaciones serán revisadas y aceptadas o rechazadas según los criterios definidos
en el marco de gobernanza.
Dispensación (también conocida como Exención)
Se puede rechazar una evaluación de cumplimiento cuando el área en cuestión (diseño, funcionamiento, nivel de
servicio o tecnología) no cumple. En este caso el área temática puede:
1. Ajustarse o realinearse para cumplir con los requisitos de cumplimiento
2. Solicitar una dispensa
Cuando se rechaza una evaluación de cumplimiento, se proporciona una ruta alternativa para cumplir con la conformidad
provisional a través de dispensas. Estos se otorgan por un período de tiempo determinado y un conjunto de criterios
operativos y de servicio identificados que deben cumplirse durante la vigencia de la dispensa. Las dispensas no se
otorgan indefinidamente, sino que se utilizan como un mecanismo para garantizar que se cumplan los niveles de servicio
y los niveles operativos, al mismo tiempo que se proporciona un nivel de flexibilidad en su implementación y calendario.
La naturaleza limitada en el tiempo de las dispensaciones asegura que sean un desencadenante importante en el ciclo
de cumplimiento.
Monitoreo y Reporte
La gestión del rendimiento es necesaria para garantizar que tanto los elementos operativos como los de servicio se
gestionen con arreglo a un conjunto de criterios acordado. Esto incluirá el seguimiento de SLA y OLA, retroalimentación
para ajustes e informes.
La información de gestión interna se considerará en Gestión Ambiental.
Control de Negocios
Business Control se relaciona con los procesos invocados para garantizar el cumplimiento de las políticas comerciales
de la organización.
Gestión del Medio Ambiente
Esto identifica todos los servicios necesarios para garantizar que el entorno basado en el repositorio que sustenta el
marco de gobierno sea eficaz y eficiente. Esto incluye la gestión del repositorio físico y lógico, el acceso, la comunicación,
la formación y la acreditación de todos los usuarios.
Todos los artefactos de la arquitectura, los acuerdos de servicio, los contratos y la información de respaldo deben estar
bajo control a través de un proceso formal para registrar, validar, ratificar, administrar y publicar contenido nuevo o
actualizado. Estos procesos garantizarán la integración ordenada con el contenido de gobierno existente, de modo que
todas las partes, documentos, contratos e información de respaldo relevantes se gestionen y auditen.

El entorno de gobierno tendrá una serie de procesos administrativos definidos para efectuar un servicio gestionado y un
entorno de procesos. Estos procesos incluirán la gestión de usuarios, los SLA internos (definidos para controlar sus
propios procesos) y la generación de informes de información de gestión.
3.2.2 Marco de gobernanza de la arquitectura: estructura organizativa

3.2.2.1 Vista general
La gobernanza de la arquitectura es la práctica y la orientación mediante la cual se gestionan y controlan las

arquitecturas empresariales y otras arquitecturas. Para asegurar que este control sea efectivo dentro de la organización,
es necesario tener las estructuras organizativas correctas establecidas para apoyar todas las actividades de gobierno.
Una estructura de Gobernanza de la Arquitectura para implementar de manera efectiva el enfoque descrito en esta
sección normalmente incluirá los siguientes niveles, que en la práctica pueden implicar una combinación de procesos
de gobernanza de TI, estructuras organizacionales y capacidades existentes. Por lo general, incluirán lo siguiente:
ÿ Junta de gobierno mundial
ÿ Junta de gobierno local
ÿ Autoridades de diseño
ÿ Grupos de trabajo
La organización de la arquitectura ilustrada en la Figura 3-2 destaca los principales elementos estructurales necesarios
para una iniciativa de Gobernanza de la Arquitectura. Si bien cada empresa tendrá diferentes requisitos, se espera que
los conceptos básicos del diseño organizacional que se muestran en la Figura 3-2 sean aplicables e implementables en
una amplia variedad de tipos de organizaciones.
dieciséis The Open Group Standard (2022)

redistribución
Ambiente de Gobernanza
CIO/CTO
Arquitectura
Junta
Desarrollar Implementar Desplegar
Jefe Programa Servicio

Arquitecto Oficina de Administración administración
Arquitectos empresariales Proveedores externos
Dominio Implementación Operacional

Dominio de arquitectos Proyectos de Implementación Sistemas Operacionales
Dominio de arquitectos Proyectos de Implementación Sistemas Operacionales
Arquitectos Proyectos Sistemas
Repositorio de Arquitectura
arquitecturas Procesos Soluciones SLA/OLA
Regulador Autoridad Organizativo

Requisitos Estructuras Estándares
© El Grupo Abierto
Figura 3-2 Marco de gobernanza de la arquitectura: estructura organizativa
3.2.2.2 Áreas clave
La Figura 3-2 identifica tres áreas clave de la gestión de la arquitectura: Desarrollar, Implementar y Desplegar. Cada
uno de estos es responsabilidad de uno o más grupos dentro de la organización, mientras que Enterprise Continuum
se muestra para respaldar todas las actividades y artefactos asociados con el gobierno de las arquitecturas a lo largo
de su ciclo de vida.
Las responsabilidades, los procesos y las estructuras de desarrollo generalmente están vinculados a TOGAF ADM y su
uso, mientras que las responsabilidades, los procesos y las estructuras de implementación generalmente están
vinculados a la fase G (consulte el estándar TOGAF: método de desarrollo de arquitectura).
Como se mencionó anteriormente,
, el Marco de Gobernanza de la Arquitectura es parte integral de Enterprise Continuum
y administra todo el contenido relevante tanto para las arquitecturas mismas como para los procesos de Gobernanza
de la Arquitectura.
3.2.2.3 Beneficios Operacionales
Como se ilustra en la Figura 3-2, el gobierno de las arquitecturas de la organización proporciona no solo control directo
y orientación de su desarrollo e implementación, sino que también se extiende a las operaciones de las arquitecturas
implementadas.

Se ha encontrado que los siguientes beneficios se derivan a través de la gobernanza continua de las arquitecturas:
ÿ Vincula los procesos, los recursos y la información de TI con las estrategias y los objetivos de la organización
ÿ Integra e institucionaliza las mejores prácticas de TI
ÿ Se alinea con los marcos de la industria como COBIT (planificación y organización, adquisición y
implementando, entregando y apoyando, y monitoreando el desempeño de TI)
ÿ Permite que la organización aproveche al máximo su información, infraestructura y

activos de hardware y software
ÿ Protege los activos digitales subyacentes de la organización ÿ Respalda
los requisitos reglamentarios y de mejores prácticas, como auditabilidad, seguridad,

responsabilidad y rendición de cuentas
ÿ Promueve una gestión de riesgos visible
Estos beneficios posicionan al TOGAF Architecture Governance Framework como un enfoque, una serie de procesos, una
orientación cultural y un conjunto de responsabilidades propias, que en conjunto aseguran la integridad y eficacia de las
arquitecturas de la organización.
3.3 Gobernanza de la arquitectura en la práctica

Esta sección proporciona pautas prácticas para la implementación efectiva de Arquitectura.
Gobernancia
3.3.1 Gobernanza de la arquitectura: factores clave de éxito

Es importante considerar lo siguiente para asegurar un enfoque exitoso de la Arquitectura
Gobernanza, y a la gestión eficaz del Contrato de Arquitectura:
ÿ Las mejores prácticas para el envío, la adopción, la reutilización, la generación de informes y el retiro de políticas,
procedimientos, roles, habilidades, estructuras organizacionales y servicios de soporte de la arquitectura.
ÿ Responsabilidades organizacionales y estructuras para apoyar la Gobernanza de la Arquitectura

procesos y requisitos de informes
ÿ Integración de herramientas y procesos para facilitar la asimilación de los procesos, tanto procesal como culturalmente
ÿ Criterios para el control de los procesos de Gobernanza de Arquitectura, dispensaciones, evaluaciones de

cumplimiento, SLAs y OLAs
ÿ Requisitos internos y externos para la eficacia, la eficiencia, la confidencialidad, la integridad, la disponibilidad, el

cumplimiento y la confiabilidad de toda la información, los servicios y los procesos relacionados con la Gobernanza
de la Arquitectura

redistribución
Gobernanza de la arquitectura Gobernanza de la arquitectura en la práctica
3.3.2 Elementos de una estrategia eficaz de gobierno de la arquitectura

3.3.2.1 Gobierno de la arquitectura y política corporativa
Una arquitectura empresarial impuesta sin el apoyo ejecutivo apropiado y la alineación política corporativa está
destinada al fracaso. Para tener éxito, la arquitectura empresarial debe reflejar las necesidades de la organización. Los
Arquitectos Empresariales, si no están involucrados en el desarrollo de la estrategia comercial, deben tener al menos
una comprensión fundamental de la misma y de los problemas comerciales predominantes que enfrenta la organización.
Incluso puede ser necesario que participen en el proceso de implementación del sistema y que, en última instancia,
sean dueños de las decisiones de inversión y selección de productos que surjan de la implementación de la Arquitectura
Tecnológica.
Hay tres elementos importantes de la estrategia de Gobernanza de la Arquitectura que se relacionan particularmente
con la aceptación y el éxito de la arquitectura dentro de la empresa. Si bien son relevantes y aplicables por derecho
propio aparte de su función en la gobernanza y, por lo tanto, se describen por separado, también forman parte integral
de cualquier estrategia efectiva de gobernanza de la arquitectura.
ÿ Se debe establecer una Junta de Arquitectura interorganizacional (consulte el Capítulo 4) con el respaldo de la
gerencia ejecutiva para supervisar la implementación de la Empresa.
Arquitectura Gobernanza estrategia
ÿ Un conjunto integral de principios de arquitectura (consulte el estándar TOGAF — ADM

Técnicas) deben establecerse para guiar, informar y apoyar la forma en que una organización se propone cumplir
su misión a través del uso de las TI.
ÿ Debe adoptarse una estrategia de Cumplimiento de la arquitectura (consulte el Capítulo 6): medidas específicas
(más que una simple declaración de política) para garantizar el cumplimiento de la arquitectura, incluidas las
Evaluaciones de impacto del proyecto, un proceso formal de revisión del Cumplimiento de la arquitectura y,
posiblemente, la participación de el equipo de arquitectura en la adquisición de productos

Gobernanza de la arquitectura

redistribución
Capítulo 4: Tablero de Arquitectura
Este capítulo proporciona pautas para establecer y operar una Junta de Arquitectura Empresarial.
4.1 Rol
Un elemento clave en una estrategia exitosa de Gobernanza de la Arquitectura (consulte el Capítulo 3) es una Junta de Arquitectura
entre organizaciones para supervisar la implementación de la estrategia. Este organismo debe ser representativo de todas las partes
interesadas clave en la arquitectura y, por lo general, estará compuesto por un grupo de ejecutivos responsables de la revisión y el
mantenimiento de la arquitectura general.
Los Consejos de Arquitectura pueden tener un alcance global, regional o de línea de negocio. Particularmente en las empresas más
grandes, las Juntas de Arquitectura suelen estar compuestas por representantes de la organización en un mínimo de dos niveles:
ÿ Local (expertos en el dominio, responsabilidad de línea)
ÿ Global (responsabilidad de toda la organización)
En tales casos, cada tablero se constituirá con identificables y articulados:
ÿ Responsabilidades y capacidad de toma de decisiones
ÿ Límites de mandato y autoridad
4.2 Responsabilidades
La Junta de Arquitectura generalmente se responsabiliza y rinde cuentas por lograr algunos o todos los siguientes objetivos:
ÿ Proporcionar la base para toda la toma de decisiones con respecto a las arquitecturas
ÿ Coherencia entre subarquitecturas
ÿ Establecimiento de objetivos para la reutilización de componentes
ÿ Flexibilidad de la Arquitectura Empresarial:
— Para satisfacer las necesidades comerciales cambiantes
— Aprovechar las nuevas tecnologías
ÿ Aplicación del cumplimiento de la arquitectura
ÿ Mejorar el nivel de madurez de la disciplina arquitectónica dentro de la organización
ÿ Garantizar que se adopte la disciplina del desarrollo basado en la arquitectura

© 2005-2022 The Open Group, todos los derechos reservados Copia de
evaluación. No para redistribución
Responsabilidades Junta de arquitectura
ÿ Admite una capacidad de escalamiento visible para decisiones fuera de los límites
Otras responsabilidades desde una perspectiva operativa deben incluir:
ÿ Todos los aspectos de seguimiento y control del Contrato de Arquitectura
ÿ Reunirse periódicamente
ÿ Garantizar la gestión e implementación eficaz y coherente de las arquitecturas . ÿ Resolver ambigüedades, problemas
o conflictos que se han escalado . ÿ Brindar asesoramiento, orientación e información.
ÿ Asegurar el cumplimiento de las arquitecturas y otorgar dispensas acordes con la estrategia y los objetivos
tecnológicos
ÿ Considerar cambios de política (horario, SLA, etc.) donde se solicitan y otorgan dispensas similares; por ejemplo,
nueva forma de requisito de servicio
ÿ Garantizar que toda la información relevante para la implementación del Contrato de Arquitectura se publique bajo
condiciones controladas y esté disponible para las partes autorizadas.
ÿ Validación de niveles de servicio reportados, ahorro de costos, etc.
Desde una perspectiva de gobernanza, la Junta de Arquitectura también es responsable de:
ÿ La producción de material y actividades de gobernanza utilizables ÿ
Proporcionar un mecanismo para la aceptación y aprobación formal de la arquitectura a través de

consenso y publicación autorizada
ÿ Proporcionar un mecanismo de control fundamental para asegurar la implementación efectiva de

la arquitectura
ÿ Establecer y mantener el vínculo entre la implementación de la arquitectura, la estrategia arquitectónica y los

objetivos incorporados en la Arquitectura Empresarial, y los objetivos estratégicos del negocio.
ÿ Identificar la divergencia de la arquitectura y las actividades de planificación para la realineación mediante

dispensas o actualizaciones de pólizas
4.3 Configuración de la placa de arquitectura

4.3.1 Activadores Uno
o más de los siguientes sucesos suelen desencadenar el establecimiento de un Consejo de Arquitectura:
ÿ Nuevo director de información
ÿ Fusión o adquisición
ÿ Reestructuración organizativa ÿ
Consideración de un cambio a formas de computación más nuevas
ÿ Reconocimiento de que la TI está mal alineada con el negocio

redistribución
Junta de arquitectura Configuración de la Junta de Arquitectura
ÿ Deseo de lograr una ventaja competitiva a través de la tecnología
ÿ Creación de un programa de arquitectura empresarial ÿ
Cambio comercial significativo o crecimiento rápido ÿ
Requerimiento de soluciones complejas y multifuncionales
En muchas empresas, el patrocinador ejecutivo del esfuerzo de arquitectura inicial es el CIO (u otro alto ejecutivo). Sin
embargo, para obtener un amplio apoyo corporativo, un organismo patrocinador tiene más influencia. Este organismo
patrocinador se denomina aquí Junta de Arquitectura, pero el título no es importante. Cualquiera que sea el nombre, es
el grupo de nivel ejecutivo responsable de la revisión y el mantenimiento de la arquitectura estratégica y todas sus
subarquitecturas.
El Consejo de Arquitectura es el patrocinador de la arquitectura dentro de la empresa, pero el Consejo de Arquitectura

mismo necesita un patrocinador ejecutivo del más alto nivel de la corporación.
Este compromiso debe abarcar el proceso de planificación y continuar en la fase de mantenimiento del proyecto de
arquitectura. En muchas empresas que fracasan en un esfuerzo de planificación de la arquitectura, hay una falta notable
de participación ejecutiva y de estímulo para el proyecto.
Una fuente frecuentemente pasada por alto de los miembros de la Junta de Arquitectura es la Junta Directiva de la
compañía. Estas personas invariablemente tienen conocimientos diversos sobre el negocio y su competencia. Debido a
que tienen un impacto significativo en la visión y los objetivos comerciales, pueden tener éxito en la validación de la
alineación de las estrategias de TI con los objetivos comerciales.
4.3.2 Tamaño del Directorio

El tamaño recomendado para una Junta de Arquitectura es de cuatro o cinco (y no más de diez) miembros permanentes.
Para mantener el Consejo de Arquitectura en un tamaño razonable, al mismo tiempo que se garantiza la representación
de toda la empresa en él a lo largo del tiempo, la membresía del Consejo de Arquitectura puede rotar, otorgando
privilegios y responsabilidades de toma de decisiones a varios gerentes senior. Esto puede ser necesario en cualquier
caso, debido a que algunos miembros de la Junta de Arquitectura encuentran que las limitaciones de tiempo impiden la
participación activa a largo plazo.
Una organización puede establecer su Junta de Arquitectura utilizando medios representativos, de modo que a cada
miembro de la Junta se le asigne un conjunto de partes interesadas para representar en las reuniones. Luego,
corresponde a los miembros de la Junta reunirse con las partes interesadas para obtener sus puntos de vista sobre los
diversos puntos de la agenda.
Sin embargo, debe existir cierta continuidad en la Junta de Arquitectura, para evitar que la arquitectura corporativa varíe
de un conjunto de ideas a otro. Una técnica para asegurar la rotación con continuidad es establecer plazos para los
miembros y hacer que los plazos expiren en diferentes momentos.
En el proceso de arquitectura en curso que sigue al esfuerzo de arquitectura inicial, la Junta de Arquitectura puede
volver a ser constituida. El patrocinador ejecutivo normalmente revisará el trabajo de la Junta de Arquitectura y evaluará
su efectividad; si es necesario, el proceso de revisión del cumplimiento de la arquitectura se actualiza o cambia.

Configuración de la Junta de Arquitectura Tablero de arquitectura de arco
4.3.3 Estructura de la Junta
El marco de gobierno de la arquitectura TOGAF (consulte la Sección 3.2) proporciona un marco organizativo genérico que
posiciona al Consejo de Arquitectura en el contexto de las estructuras de gobierno más amplias de la empresa. Esta
estructura identifica los principales grupos organizativos y responsabilidades, así como la relación entre cada grupo. Esta
es una estructura de mejores prácticas y puede estar sujeta a cambios según la forma de la organización y las estructuras
existentes.
Se debe tener en cuenta el tamaño de la organización, su forma y cómo se implementan las funciones de TI. Esto
proporcionará la base para diseñar la estructura de la Junta de Arquitectura dentro del contexto del entorno de gobierno
general. En particular, se debe considerar el concepto de propiedad global e implementación local, y la integración de
nuevos conceptos y tecnologías de todas las áreas implementadas contra arquitecturas.
La estructura del Consejo de Arquitectura debe reflejar la forma de la organización. La estructura de Gobernanza de la
Arquitectura requerida puede ir más allá de las estructuras genéricas descritas en el Marco de Gobernanza de la
Arquitectura TOGAF (consulte la Sección 3.2). Es posible que la organización deba definir una combinación del proceso
de gobierno de TI implementado y las estructuras y capacidades organizacionales existentes, que generalmente incluyen
los siguientes tipos de organismos:
ÿ Junta de gobierno global
ÿ Junta de gobierno local
ÿ Autoridades de diseño
ÿ Grupos de trabajo
4.4 Funcionamiento del Tablero de Arquitectura

Esta sección describe el funcionamiento de la Junta de Arquitectura en particular desde la perspectiva de la gobernanza.
4.4.1 Generalidades
Las reuniones de la Junta de Arquitectura deben llevarse a cabo dentro de agendas claramente identificadas con objetivos
explícitos, cobertura de contenido y acciones definidas. En general, las reuniones de la junta estarán alineadas con las
mejores prácticas, tal como se indica en el marco COBIT (consulte la Sección 3.1.4.1).
Estas reuniones proporcionarán una dirección clave en:
ÿ Apoyar la producción de material y actividades de gobernanza de calidad ÿ Proporcionar
un mecanismo para la aceptación formal a través del consenso y autorización

publicación
ÿ Proporcionar un mecanismo de control fundamental para asegurar la implementación efectiva de

las arquitecturas
ÿ Establecer y mantener el vínculo entre la implementación de las arquitecturas y

la estrategia y los objetivos declarados de la organización (negocio y TI)

redistribución
Junta de arquitectura Funcionamiento de la Junta de Arquitectura
ÿ Identificar divergencias del contrato y planificar actividades para realinearse con el contrato a través de dispensas o
actualizaciones de políticas
4.4.2 Preparación
Cada participante recibirá una agenda y cualquier documentación de respaldo, por ejemplo, solicitudes de dispensa,
informes de gestión del desempeño, etc., y se espera que esté familiarizado con el contenido de cada uno.
Cuando se han asignado acciones a un individuo, es responsabilidad de esa persona informar sobre el progreso con
respecto a estas.
Cada participante deberá confirmar su disponibilidad y asistencia a la reunión del Consejo de Arquitectura.
4.4.3 Orden del día

Esta sección describe el contenido de la agenda de una reunión del Consejo de Arquitectura. Cada tema de la agenda se
describe únicamente en términos de su contenido.
Actas de reuniones anteriores Las
actas contienen los detalles de las reuniones anteriores de la Junta de Arquitectura según el protocolo organizativo
estándar.
Las solicitudes de artículos
de cambio bajo este encabezado son normalmente solicitudes de cambio de enmiendas a arquitecturas, principios, etc.,
pero también pueden incluir control comercial con respecto a contratos de arquitectura; por ejemplo, asegúrese de que se
prohíba el tráfico de voz a números premium, como los informes meteorológicos, y se controle el tráfico de datos a ciertos
sitios web.
Cualquier solicitud de cambio se realiza dentro de los niveles de autoridad acordados y los parámetros definidos por el
Contrato de Arquitectura.
dispensaciones
Se utiliza una dispensa como mecanismo para solicitar un cambio a las arquitecturas, contratos, principios, etc. existentes
fuera de los parámetros normales de operación; por ejemplo, excluir la prestación de servicios a una subsidiaria, solicitar
niveles de servicio inusuales por razones comerciales específicas, implementar tecnología o productos no estándar para
respaldar iniciativas comerciales específicas.
Las dispensas se otorgan por un período de tiempo determinado y un conjunto de servicios identificados y criterios
operativos que deben cumplirse durante la vigencia de la dispensa. Las dispensas no se otorgan indefinidamente, sino
que se utilizan como un mecanismo para garantizar que se cumplan los niveles de servicio y los niveles operativos, etc.,
al mismo tiempo que se brinda un nivel de flexibilidad en su implementación y tiempo. La naturaleza limitada en el tiempo
de las dispensas garantiza que sean un desencadenante de la actividad de Cumplimiento de la Arquitectura.

Funcionamiento de la Junta de Arquitectura Tablero de arquitectura de arco
Evaluaciones de cumplimiento El
cumplimiento se evalúa frente a SLA, Acuerdos de nivel operativo (OLA), objetivos de costo y actualizaciones de arquitectura requeridas.
Estas evaluaciones serán revisadas y aceptadas o rechazadas según los criterios definidos en el Marco de Gobernanza de la Arquitectura.
El informe de evaluación del cumplimiento de la arquitectura incluirá los detalles descritos.
Resolución de conflictos
Las disputas que no se han resuelto a través de los procesos de Dispensación y Cumplimiento de la Arquitectura se identifican aquí para
tomar medidas adicionales y se documentan a través de las evaluaciones de Cumplimiento de la Arquitectura y la documentación de
dispensación.
Arquitectura Estrategia y Dirección Documentación
Esto describe las estrategias, la dirección y las prioridades de la arquitectura y solo será formulado por la Junta de Arquitectura global.
Debe tomar la forma de documentación de arquitectura estándar.
Acciones asignadas
Este es un informe sobre las acciones asignadas en reuniones anteriores de la Junta de Arquitectura. Se utiliza un rastreador de acciones
para documentar y mantener el estado de todas las acciones asignadas durante las reuniones de la Junta de Arquitectura y debe contener
al menos la siguiente información:
ÿ Referencia
ÿ Prioridad
ÿ Descripción de la acción
ÿ Propietario de la acción
ÿ Detalles de la acción
ÿ Fecha en que se planteó
ÿ Fecha de vencimiento
ÿ Estado
ÿ Tipo
ÿ Fecha de resolución
Gestión de la documentación del contrato Esta es una
aceptación formal de actualizaciones y cambios en la documentación de la arquitectura para su posterior publicación.
Cualquier otro negocio (AOB)
Descripción de temas no cubiertos directamente por ninguno de los anteriores. Es posible que no se describan en la agenda, pero deben
plantearse al comienzo de la reunión. Cualquier documentación de respaldo debe administrarse de acuerdo con toda la documentación
de Gobernanza de la arquitectura.
Calendario de reuniones
Todas las fechas de las reuniones deben ser detalladas y publicadas.
26 The Open Group Standard (2022) ©

2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para redistribución
Capítulo 5: Contratos de Arquitectura
Este capítulo proporciona pautas para definir y utilizar Contratos de Arquitectura.
5.1 Rol
Los contratos de arquitectura son los acuerdos conjuntos entre los socios de desarrollo y los patrocinadores sobre los
entregables, la calidad y la idoneidad para el propósito de una arquitectura. La implementación exitosa de estos acuerdos se
logrará a través de una Gobernanza de Arquitectura efectiva (consulte el Capítulo 3).
Al implementar un enfoque gobernado para la gestión de contratos, se garantizará lo siguiente:
ÿ Un sistema de monitoreo continuo para verificar la integridad, los cambios, la toma de decisiones y la auditoría de todas
las actividades relacionadas con la arquitectura dentro de la organización
ÿ Cumplimiento de los principios, estándares y requisitos de las organizaciones existentes o en desarrollo.

arquitecturas
ÿ Identificación de riesgos en todos los aspectos del desarrollo e implementación de la(s) arquitectura(s) que cubre el
desarrollo interno frente a los estándares, políticas, tecnologías y productos aceptados, así como los aspectos
operativos de las arquitecturas, de modo que la organización pueda continuar su negocio dentro de un entorno
resiliente
ÿ Un conjunto de procesos y prácticas que aseguran la rendición de cuentas, la responsabilidad y la disciplina con
respecto al desarrollo y uso de todos los artefactos arquitectónicos.
ÿ Una comprensión formal de la organización de gobierno responsable del contrato, su nivel de autoridad y el alcance de
la arquitectura bajo el gobierno de este organismo
El Contrato de Arquitectura tradicional es un acuerdo entre el patrocinador y la función de arquitectura o el departamento de

Sistemas de Información (SI). Sin embargo, los integradores de sistemas, los proveedores de aplicaciones y los proveedores
de servicios brindan cada vez más servicios, coordinados a través de la función de arquitectura o el departamento de SI. Por
lo tanto, existe la necesidad de un Contrato de Arquitectura para establecer acuerdos conjuntos entre todas las partes
involucradas en el desarrollo y entrega de la arquitectura.
Los Contratos de Arquitectura pueden ocurrir en varias etapas del ADM; por ejemplo:
ÿ La Declaración de Trabajo de Arquitectura creada en la Fase A del Estándar TOGAF —

El método de desarrollo de arquitectura es efectivamente un contrato de arquitectura entre la organización de
arquitectura y el patrocinador de la arquitectura empresarial (o la función de gobierno de TI)
ÿ El desarrollo de uno o más dominios de arquitectura (Negocio, Datos, Aplicación,

Tecnología) y, en algunos casos, la supervisión de la arquitectura empresarial general, pueden contratarse con
integradores de sistemas, proveedores de aplicaciones y/o proveedores de servicios.
Cada uno de estos arreglos se regirá normalmente por un Contrato de Arquitectura que

Role Contratos de Arquitectura
define los entregables, la calidad y la idoneidad para el propósito de la arquitectura desarrollada, y los procesos
mediante los cuales los socios en el desarrollo de la arquitectura trabajarán juntos.
ÿ Al comienzo de la Fase G (Implementation Governance), entre la función de arquitectura y la función responsable

de implementar la Arquitectura Empresarial definida en las fases anteriores de ADM; por lo general, será la función
de desarrollo de sistemas interna o un contratista principal a quien se subcontrata el trabajo
— Lo que se está "implementando" en la Fase G del ADM es la Empresa general

Arquitectura
Por lo general, esto incluirá la infraestructura tecnológica (de la Fase D) y también las aplicaciones
empresariales y las capacidades de gestión de datos que se han definido en la Arquitectura de aplicaciones
y la Arquitectura de datos (de la Fase C), ya sea porque son para toda la empresa en o porque son
estratégicas en términos comerciales y, por lo tanto, de importancia y visibilidad en toda la empresa. Sin
embargo, normalmente no incluirá aplicaciones comerciales no estratégicas, que las unidades comerciales
implementarán posteriormente sobre la infraestructura tecnológica que se implementa como parte de la
arquitectura empresarial.
— En implementaciones a mayor escala, bien puede haber un Contrato de Arquitectura por

equipo de implementación en un programa de proyectos de implementación
ÿ Cuando el Documento de Definición de Arquitectura finalizado esté disponible (al final de la Fase F), normalmente
se redactará un Contrato de Arquitectura entre la función de arquitectura (o la función de gobierno de TI, incluida la
función de arquitectura) y los usuarios comerciales que posteriormente construirán e implementarán sistemas de
aplicaciones en el entorno diseñado
Es importante tener en cuenta en todos estos casos que el objetivo final no es solo una Arquitectura Empresarial, sino una
Arquitectura Empresarial dinámica; es decir, uno que permita una evolución flexible en respuesta a la tecnología cambiante
y los impulsores comerciales, sin restricciones innecesarias. El Contrato de Arquitectura es crucial para habilitar una
Arquitectura Empresarial dinámica y es clave para gobernar la implementación.
A continuación se explican los contenidos típicos de estos tres tipos de Contrato de Arquitectura.

redistribución
Contratos de Arquitectura Role
5.2 Contenido
5.2.1 Declaración de Trabajo de Arquitectura
La Declaración de Trabajo de Arquitectura se crea como un entregable de la Fase A, y es efectivamente un Contrato de

Arquitectura entre la organización de arquitectura y el patrocinador de la Arquitectura Empresarial (o la función de gobierno
de TI, en nombre de la empresa).
Los contenidos típicos de una Declaración de trabajo de arquitectura son los definidos en el estándar TOGAF: contenido de
arquitectura.
5.2.2 Contrato entre socios de diseño y desarrollo de arquitectura

Esta es una declaración de intenciones firmada sobre el diseño y desarrollo de Enterprise Architecture, o partes significativas
de ella, de organizaciones asociadas, incluidos integradores de sistemas, proveedores de aplicaciones y proveedores de
servicios.
Cada vez más, el desarrollo de uno o más dominios de arquitectura (negocios, datos, aplicaciones, tecnología) puede
subcontratarse, y la función de arquitectura de la empresa proporciona supervisión de la arquitectura empresarial general y
coordinación y control del esfuerzo general. . En algunos casos, incluso esta función de supervisión puede subcontratarse,
aunque la mayoría de las empresas prefieren conservar esa responsabilidad central internamente.
Cualesquiera que sean los detalles de los acuerdos de subcontratación, los propios acuerdos normalmente se regirán por
un Contrato de Arquitectura que defina los entregables, la calidad y la idoneidad para el propósito de la arquitectura
desarrollada, y los procesos por los cuales los socios en el el desarrollo de la arquitectura trabajará en conjunto.
Los contenidos típicos de un Contrato de Diseño y Desarrollo de Arquitectura son:
ÿ Introducción y antecedentes
ÿ La naturaleza del acuerdo ÿ Alcance
de la arquitectura
ÿ Arquitectura y principios y requisitos estratégicos
ÿ Requisitos de conformidad
ÿ Proceso y funciones de gestión y desarrollo de la arquitectura
ÿ Medidas de arquitectura objetivo
ÿ Fases definidas de entregables
ÿ Plan de trabajo conjunto priorizado
ÿ Ventana(s) de tiempo
ÿ Entrega de arquitectura y métricas comerciales
La plantilla para este contrato normalmente se definirá como parte de la Fase Preliminar del ADM, si aún no existe, y el
contrato específico se definirá en la etapa apropiada del ADM, dependiendo del trabajo particular que se subcontrate. .

Contenido Contratos de Arquitectura
5.2.3 Contrato entre la función de arquitectura y las partes interesadas del negocio
Cuando se haya acordado el Plan de Implementación y Migración (al final de la Fase F), se puede redactar un Contrato de
Arquitectura entre la función de arquitectura y las partes interesadas del negocio que posteriormente construirán e implementarán
las soluciones comerciales diseñadas.
El contrato de arquitectura de una parte interesada comercial puede incluir:
ÿ Introducción y antecedentes
ÿ La naturaleza del acuerdo ÿ Alcance ÿ
Requisitos estratégicos
ÿ Entregables de la arquitectura que cumplen con los requisitos del negocio
ÿ Requisitos de conformidad
ÿ adoptantes de la arquitectura
ÿ Ventana de tiempo
ÿ Arquitectura de métricas comerciales
ÿ ANS
Este contrato también se utiliza para gestionar los cambios en la Arquitectura Empresarial en la Fase H.
5.3 Relación con la Gobernanza de la Arquitectura

El documento del Contrato de Arquitectura producido en la Fase G del ADM ocupa un lugar destacado en el área de Gobernanza
de la Arquitectura, como se explica en el Capítulo 3.
En el contexto de la Gobernanza de la Arquitectura, el Contrato de Arquitectura se utiliza a menudo como un medio para impulsar
el cambio de la arquitectura.
Para garantizar que el Contrato de Arquitectura sea efectivo y eficiente, es posible que sea necesario introducir los siguientes
aspectos del marco de gobernanza en la Fase G:
ÿ Procesos simples
ÿ Autoridad centrada en las personas
ÿ Comunicación sólida ÿ
Respuestas oportunas y un proceso de escalado efectivo ÿ Estructuras
organizativas de apoyo ÿ Seguimiento del estado de implementación de la
arquitectura

Capítulo 6: Cumplimiento de la arquitectura
Este capítulo proporciona pautas para garantizar el cumplimiento del proyecto con la arquitectura.
6.1 Introducción
Asegurar el cumplimiento de los proyectos individuales con la Arquitectura Empresarial es un aspecto esencial de la
Gobernanza de la Arquitectura (ver Capítulo 3). Con este fin, la función de gobierno de TI dentro de una empresa
normalmente definirá dos procesos complementarios:
ÿ La función de Arquitectura deberá preparar una serie de Proyectos de Arquitectura; es decir, vistas específicas
del proyecto de la Arquitectura Empresarial que ilustran cómo la Arquitectura Empresarial impacta en los
principales proyectos dentro de la organización (consulte las Fases A a F de ADM)
ÿ Las funciones de Gobernanza de la Empresa y TI definirán un proceso formal de revisión del Cumplimiento de
la Arquitectura (ver Sección 6.3) para revisar el cumplimiento de todos los proyectos con la Arquitectura de la
Empresa.
Además de definir procesos formales, la función de Gobernanza de la Arquitectura (ver Capítulo 3) también puede
estipular que la función de la arquitectura debe extenderse más allá del rol de definición de la arquitectura y selección
de estándares, y participar también en el proceso de selección de tecnología, e incluso en la relaciones comerciales de
prestación de servicios externos y compra de productos. Esto puede ayudar a minimizar la oportunidad de mala
interpretación de la Arquitectura Empresarial y maximizar el valor de la negociación comercial centralizada.
6.2 Terminología: el significado del cumplimiento de la arquitectura

Una relación clave entre la arquitectura y la implementación radica en las definiciones de los términos "conforme",
"conforme", etc. Si bien el uso de la terminología puede diferir entre organizaciones, los conceptos de niveles de
conformidad ilustrados en la Figura 6-1 deben ser útil para formular una estrategia de cumplimiento de TI.

Terminología: el significado del cumplimiento de la arquitectura Cumplimiento de la arquitectura
© El Grupo Abierto
Irrelevante:
Arquitectura la implementación no tiene características en común con la
Implementación
Especificación especificación de la arquitectura (por lo que no surge la cuestión de la
conformidad).
Consistente:
la implementación tiene algunas características en común con la
especificación de la arquitectura, y esas características comunes se
implementan de acuerdo con la especificación. Sin embargo, algunas
características de la especificación de arquitectura no están
implementadas y la implementación tiene otras características que no
están cubiertas por la especificación.
Compatible:
algunas características de la especificación de arquitectura no
están implementadas, pero todas las características implementadas
están cubiertas por la especificación y de acuerdo con ella.
Conforme:
todas las características de la especificación de arquitectura
se implementan de acuerdo con la especificación, pero se
implementan algunas características más que no están de
acuerdo con ella.
Totalmente conforme:
existe una correspondencia total entre la especificación de la
arquitectura y la implementación. Todas las funciones especificadas
se implementan de acuerdo con la especificación, y no hay
funciones implementadas que no estén cubiertas por la
especificación.
No conforme:
cualquiera de los anteriores en los que algunas
características de la especificación de la arquitectura no
se implementan de acuerdo con la especificación.
Figura 6-1 Niveles de conformidad con la arquitectura
La frase "de acuerdo con" en la Figura 6-1 significa:
ÿ Respalda la estrategia establecida y las direcciones futuras ÿ
Se adhiere a los estándares establecidos (incluidas las reglas sintácticas y semánticas especificadas)
ÿ Proporciona la funcionalidad establecida ÿ Se adhiere a los principios establecidos; por ejemplo:
— Abierto siempre que sea posible y apropiado
— Reutilización de componentes básicos siempre que sea posible y apropiado

redistribución
Cumplimiento de la arquitectura Revisiones de cumplimiento de la arquitectura
6.3 Revisiones de cumplimiento de la arquitectura

Una revisión del cumplimiento de la arquitectura es un escrutinio del cumplimiento de un proyecto específico con respecto a los
criterios arquitectónicos establecidos, el espíritu y los objetivos comerciales. Un proceso formal para dichas revisiones normalmente
constituye el núcleo de una estrategia de Cumplimiento de Arquitectura Empresarial.
6.3.1 Propósito
Los objetivos de una revisión del cumplimiento de la arquitectura incluyen algunos o todos los siguientes:
ÿ En primer lugar, detecte los errores en la arquitectura del proyecto de manera temprana y, por lo tanto, reduzca el
costo y riesgo de cambios requeridos más adelante en el ciclo de vida
Esto, a su vez, significa que el tiempo total del proyecto se acorta y que la empresa obtiene el beneficio final del desarrollo
de la arquitectura más rápidamente. ÿ Asegurar la aplicación de las mejores prácticas al trabajo de arquitectura ÿ
Proporcionar una visión general del cumplimiento de una arquitectura para la empresa obligatoria
normas
ÿ Identificar dónde los estándares mismos pueden requerir modificación ÿ Identificar los
servicios que actualmente son específicos de la aplicación pero que podrían proporcionarse como parte de la
Ingrese al premio Infraestructura
ÿ Documentar estrategias para la colaboración, el intercambio de recursos y otras sinergias entre varios equipos de arquitectura.
ÿ Aprovechar los avances tecnológicos ÿ Comunicar a la
gerencia el estado de la preparación comercial y técnica del proyecto ÿ Identificar los criterios clave para las actividades de
adquisición; por ejemplo, para su inclusión en los documentos de solicitud de información (RFI)/solicitud de propuesta (RFP)
de productos comerciales estándar (COTS)
ÿ Identificar y comunicar brechas significativas en la arquitectura a los proveedores de productos y servicios.
,
Además de los objetivos genéricos relacionados con la garantía de calidad descritos anteriormente, existen motivaciones
adicionales, más orientadas políticamente, para realizar revisiones de cumplimiento de la arquitectura, que pueden ser relevantes
en casos particulares:
ÿ La revisión del cumplimiento de la arquitectura puede ser una buena forma de decidir entre alternativas arquitectónicas, ya
que los encargados de la toma de decisiones comerciales que normalmente participan en la revisión pueden guiar las
decisiones en términos de lo que es mejor para el negocio, en oposición a lo que es técnicamente más agradable o elegante
ÿ El resultado de la revisión del cumplimiento de la arquitectura es uno de los pocos

entregables a la dirección ejecutiva para ayudar en la toma de decisiones
ÿ Las revisiones de la arquitectura pueden servir como vía para que la organización de arquitectura participe en proyectos de
desarrollo que, de otro modo, podrían continuar sin la participación de la función de arquitectura.
ÿ Las revisiones de la arquitectura pueden demostrar un apoyo rápido y positivo al negocio de la empresa.
comunidad:

© 2005-2022 The Open Group, todos los derechos reservados Copia
de evaluación. No para redistribución
Revisiones de cumplimiento de la arquitectura Cumplimiento de la arquitectura
— La arquitectura empresarial y el cumplimiento de la arquitectura ayudan a garantizar la alineación de los proyectos

de TI con los objetivos comerciales.
— A veces se puede considerar que los arquitectos están muy metidos en la infraestructura técnica y muy alejados del
negocio principal.
— Dado que una revisión de Cumplimiento de la arquitectura tiende a observar principalmente las áreas críticas de
riesgo de un sistema, a menudo destaca los principales riesgos para los propietarios del sistema.
Si bien se requiere el cumplimiento de la arquitectura para el desarrollo y la implementación, el incumplimiento también

proporciona un mecanismo para resaltar:
ÿ Áreas que deben abordarse para la realineación ÿ
Áreas que deben considerarse para la integración en las arquitecturas a medida que se descubren en los procesos de
cumplimiento
El último punto identifica el cambio continuo y la adaptabilidad de las arquitecturas a los requisitos que pueden ser impulsados
por la indisciplina, pero también permite que los cambios se registren por cambios más rápidos en el entorno operativo. Por lo
general, las dispensas (consulte la Sección 3.1.4) se utilizarán para resaltar estos cambios y poner en marcha un proceso para
registrar, monitorear y evaluar la idoneidad de cualquier cambio requerido.
6.3.2 Temporización
El tiempo de las actividades de cumplimiento debe considerarse con respecto al desarrollo de las arquitecturas mismas.
Las revisiones de cumplimiento se llevan a cabo en los hitos o puntos de control apropiados del proyecto en el ciclo de vida del
proyecto. Se deben incluir puntos de control específicos de la siguiente manera:
ÿ Desarrollo de la propia arquitectura (cumplimiento de ADM) ÿ Implementación
de la(s) arquitectura(s) (cumplimiento de la arquitectura)
Los tiempos del proyecto de arquitectura para las evaluaciones deben incluir:
ÿ Iniciación del proyecto
ÿ Diseño inicial
ÿ Cambios importantes en el diseño
ÿ Ad hoc
La revisión de Cumplimiento de la arquitectura suele estar dirigida a un punto en el tiempo cuando los requisitos comerciales y la
Arquitectura empresarial son razonablemente firmes y la arquitectura del proyecto está tomando forma, mucho antes de su
finalización.
El objetivo es llevar a cabo la revisión tan pronto como sea posible, en una etapa en la que todavía haya tiempo para corregir
cualquier error o deficiencia importante, con la condición obvia de que debe haber habido algún desarrollo significativo de la
arquitectura del proyecto para que exista. ser algo para revisar.
Los aportes a la revisión del cumplimiento de la arquitectura pueden provenir de otras partes del ciclo de vida del proyecto
estándar, lo que puede tener un impacto en el tiempo.

Cumplimiento de la arquitectura Revisiones de cumplimiento de la arquitectura
6.3.3 Escenarios de Gobernanza y Personal
En términos de la gobernanza y la realización de la revisión de Cumplimiento de la Arquitectura, y el personal involucrado,

existen varios escenarios posibles:
ÿ Para proyectos de menor escala, el proceso de revisión podría simplemente tomar la forma de una serie de preguntas
que los arquitectos del proyecto o los líderes del proyecto se plantean a sí mismos, utilizando las listas de
verificación que se proporcionan a continuación, tal vez cotejando las respuestas en algún tipo de informe del
proyecto para administración
La necesidad de llevar a cabo dicho proceso normalmente se incluye en las políticas generales de gobierno de
toda la empresa.
ÿ Cuando el proyecto que se está revisando no ha involucrado a un arquitecto en ejercicio o de tiempo completo hasta
la fecha (por ejemplo, en un proyecto de nivel de aplicación), el propósito de la revisión suele ser aprovechar la
experiencia arquitectónica de una empresa de arquitectura. función En tal caso, la función de Enterprise Architecture
estaría organizando, liderando y realizando la revisión, con la participación de expertos en el dominio del negocio.
En tal escenario, la revisión no reemplaza la participación de los arquitectos en un proyecto, pero puede ser un
complemento o una guía para su participación. Es probable que sea necesaria una base de datos para gestionar el
volumen de datos que se produciría en el análisis de un gran sistema o conjunto de sistemas.
ÿ En la mayoría de los casos, en particular en proyectos de gran escala, la función de arquitectura habrá estado
profundamente involucrada en el proyecto de desarrollo que se está revisando, y tal vez lo haya liderado.
(Este es el escenario típico de TOGAF). En tales casos, la revisión será coordinada por el Enterprise Architect
principal, quien reunirá un equipo de expertos en dominios técnicos y comerciales para la revisión y recopilará las
respuestas a las preguntas. planteadas durante la revisión en alguna forma de informe. Las preguntas normalmente
se plantearán durante la revisión por parte de los expertos en dominios comerciales y técnicos. Como alternativa,
la revisión podría estar dirigida por un representante de un Consejo de Arquitectura o algún organismo similar con
responsabilidades en toda la empresa.
En todos los casos, el proceso de revisión del Cumplimiento de la Arquitectura necesita el respaldo de la alta dirección y,
por lo general, será obligatorio como parte de las políticas corporativas de Gobernanza de la Arquitectura (consulte el
Capítulo 3). Normalmente, el CIO de la empresa o la Junta de Arquitectura de la Empresa (consulte el Capítulo 4) exigirá
revisiones de arquitectura para todos los proyectos importantes, con revisiones anuales posteriores.

Revisiones de cumplimiento de la arquitectura Cumplimiento de la arquitectura
6.4 Proceso de revisión del cumplimiento de la arquitectura

6.4.1 Resumen
El proceso de revisión del cumplimiento de la arquitectura se ilustra en la Figura 6-2.
Determinar Calendario
Arquitectura Identificar Identificar Arquitectura
Ámbito de aplicación de Sastre
Revisar Responsable Guiar
Revisar listas de verificación Revisar
Solicitud Organización Arquitecto
( ) Descubrimiento Reunión
(según lo dispuesto por
Gobernanza de TI/
Políticas y procedimientos Arquitectura Arquitectura Arquitectura Arquitecto principal: Arquitectura
de la Junta de Arquitectura) Revisar Revisar Revisar • Determinar las Revisar
Coordinador: Coordinador Coordinador: preguntas Coordinador:
• • • Colaborar para
Identificar Identificar otras apropiadas de la lista de verificación
la unidad de unidades de negocio configurar la reunión
negocio responsable involucradas
• Identifico losdel • Comprender
directores
proyecto dónde encaja el
sistema en el marco
corporativo
Presente Preparar Entrevista

Evaluación Arquitectura Analizar
Aceptar, revisar y Revisar
Informe/Resumen Revisar Terminado Proyecto
cerrar sesión
Recomendaciones listas de verificación directores
Reporte
Arquitectura Arquitecto principal: Arquitecto principal Arquitecto principal: Arquitecto líder,

• Al cliente •
Junta, Revisión contra Líder del proyecto,
Cliente • A la Junta de Arquitectura
estándares corporativos Clientes:
• •
Identificar y Proyecto informal –
resolver problemas estándares en persona
• Determinar • –
© El Grupo Abierto COTS en persona o
recomendaciones vía RFP
• Usar listas de verificación
Figura 6-2 Proceso de revisión del cumplimiento de la arquitectura
Nota: Otra forma de obtener controles de conformidad en la arquitectura es mediante el uso de trazabilidad en
modelos y diagramas de "desglose". En esta técnica, Enterprise Architect crea una vista de nivel superior
de una arquitectura que los Solution Architects refinan aún más rastreando sus elementos hasta el modelo
de Enterprise Architecture. Estos refinamientos se pueden gestionar a través de los llamados diagramas
"drill down" que contienen todos los elementos de refinamiento y su trazabilidad. De esta manera, la
conformidad puede ser revisada y al menos parcialmente automatizada por herramientas (como tener un
script que verifique que todos los elementos de la Arquitectura Empresarial tengan mejoras en la
Arquitectura de la Solución).

redistribución
Cumplimiento de la arquitectura Proceso de revisión del cumplimiento de la arquitectura
6.4.2 Funciones
Los roles principales en el proceso se tabulan a continuación.
No. Role Responsabilidades notas
1 Junta de Arquitectura Para asegurar que Enterprise Patrocinar y monitorear actividades de

Las arquitecturas son consistentes y arquitectura.
respaldan las necesidades comerciales
2 Líder de Proyecto R generales. responsable de todo el proyecto.
(o Junta de Proyecto)
3 Arquitectura Administrar todo el proceso Es más probable que esté orientado a los
Revisar de desarrollo y revisión de la negocios que a la tecnología.
Coordinador arquitectura.
4 Empresa líder Para garantizar que la arquitectura sea Un especialista en arquitectura apropiado.
Arquitecto empresarial y técnicamente coherente y
preparada para el futuro.
5 Arquitecto Uno de los asistentes de Lead
Enterprise Architect.
6 Cliente Asegurar que los requisitos Gestiona aquella parte de la organización que
comerciales se expresen y dependerá del éxito de la Arquitectura
entiendan claramente. Empresarial.
7 Dominio comercial Asegurar que los procesos para Sabe cómo opera el dominio comercial;
Experto satisfacer los requerimientos del negocio también puede ser el cliente.
estén justificados y entendidos.
8 Principios del proyecto Asegurar que los arquitectos tengan un Miembros de la organización del
conocimiento suficientemente detallado de cliente que tienen información sobre los
los procesos del departamento de clientes. requisitos comerciales que debe abordar la
Pueden proporcionar información al arquitectura.
experto en el dominio empresarial oa los
arquitectos.

Proceso de revisión del cumplimiento de la arquitectura Cumplimiento de la arquitectura
6.4.3 Pasos
Los principales pasos del proceso se tabulan a continuación.
No. Acción notas Quién
1 Solicitar revisión de Según lo dispuesto Cualquiera, ya sea de TI o de

arquitectura. por las políticas y procedimientos negocios, con interés o
de gobierno. responsabilidad en el área
comercial afectada
2 Identificar la parte responsable de la Revisión de arquitectura

organización y los directores Coordinador
relevantes del proyecto.
3 Identifique al Arquitecto Principal Revisión de arquitectura
de Empresa ya otros arquitectos. Coordinador
4 Determinar el alcance de la Identifique qué otras Revisión de arquitectura

revisión. unidades de negocio/departamentos Coordinador
están involucrados.
Comprender dónde encaja el
sistema en el marco de la
arquitectura corporativa.
5 Listas de verificación a medida. Para atender los requerimientos L ead Enterprise Architect
del negocio.
6 Programar una reunión de Coordinador de revisión de
revisión de la arquitectura. arquitectura con la colaboración de
Lead Enterprise Architect
7 Entreviste a los principales Para obtener antecedentes e Arquitecto principal de empresa y/
del proyecto. información técnica: o arquitecto, proyecto
líder y clientes
ÿ Para proyecto interno:
presencial
ÿ Para COTS: en persona o

vía RFP
Utilice listas de verificación.
8 Analizar las listas de Revisión contra los estándares L ead Enterprise Architect
verificación completadas. corporativos.
Identificar y resolver problemas.
Determinar las
recomendaciones de las minas.
9 Preparar el informe de Puede incluir personal de apoyo. Arquitecto principal de empresa M

revisión del cumplimiento de la arquitectura.
10 Presente los resultados de la revisión. Arquitecto principal de empresa

ÿ Al cliente
ÿ A la Junta de Arquitectura
11 Acepte la revisión y cierre Junta de Arquitectura y

la sesión. Cliente

Cumplimiento de la arquitectura Proceso de revisión del cumplimiento de la arquitectura
No. Acción notas Quién

12 Envíe el informe/ Guiar Arquitecto Empresarial
resumen de evaluación
al coordinador de revisión de
arquitectura.
6.5 Listas de verificación de revisión del cumplimiento de la arquitectura

Las siguientes listas de verificación de revisión brindan una amplia gama de preguntas típicas que se pueden usar para realizar
revisiones de Cumplimiento de la arquitectura, en relación con varios aspectos de la arquitectura. La organización de las preguntas
incluye las disciplinas básicas de ingeniería de sistemas, gestión de la información, seguridad y gestión de sistemas. Las listas de
verificación se basan en material proporcionado por un miembro de The Open Group y son específicas para esa organización.
Otras organizaciones podrían usar las siguientes listas de verificación con otras preguntas adaptadas a sus necesidades particulares.
Las listas de verificación proporcionadas contienen demasiadas preguntas para una sola revisión: están destinadas a adaptarse
selectivamente al proyecto en cuestión (consulte la Sección 6.6). Las listas de verificación que se utilizan normalmente serán
desarrolladas/seleccionadas por expertos en la materia. Están destinados a ser actualizados anualmente por los grupos de interés
en esas áreas.
Algunas de las listas de verificación incluyen una breve descripción del Principio de Arquitectura que provoca la pregunta y una
breve descripción de qué buscar en la respuesta. Estas extensiones de la lista de verificación están destinadas a permitir la
reformulación inteligente de las preguntas y a dar al usuario de la lista de verificación una idea de por qué se hace la pregunta.
Ocasionalmente, las preguntas se redactarán por escrito, como en las solicitudes de propuesta, o al trabajar con un arquitecto de
proyecto sénior. Más típicamente se expresan oralmente, como parte de una entrevista o sesión de trabajo con el proyecto.
Las listas de verificación proporcionadas aquí están diseñadas para su uso en proyectos de arquitectura individuales, no para la
arquitectura de dominio comercial o para la arquitectura en múltiples proyectos. (Hacer una revisión de la arquitectura para una
esfera de actividad más amplia, a través de múltiples procesos comerciales y proyectos de sistemas, implicaría un proceso similar,
pero las categorías de la lista de verificación y sus contenidos serían diferentes).
6.5.1 Lista de verificación de hardware y sistema operativo

1. ¿Cuál es el enfoque del ciclo de vida del proyecto?
2. ¿En qué etapa se encuentra el proyecto en su ciclo de vida?
3. ¿Qué problemas clave se han identificado o analizado que el proyecto cree que impulsarán las evaluaciones de hardware y
sistemas operativos para redes, servidores y dispositivos de usuarios finales?
4. ¿Qué capacidades del sistema implicarán transferencias de datos de gran volumen y/o alta frecuencia?
5. ¿Cómo impacta el diseño del sistema o cómo involucra a los dispositivos del usuario final?
6. ¿Cuál es la cantidad y distribución (regional y global) del uso, almacenamiento de datos y

¿Procesando?

Listas de verificación de revisión del cumplimiento de la arquitectura Cumplimiento de la arquitectura
7. ¿Qué aplicaciones tienen afinidad con su proyecto por similitudes en datos, servicios de aplicación, etc.? ¿Hasta qué
punto los datos están relacionados con su proyecto?
8. ¿Qué opciones de hardware y sistema operativo se han realizado antes del diseño funcional de los elementos clave
del sistema?
9. Si las decisiones de hardware y sistema operativo se tomaron fuera del control del proyecto:
— ¿Qué conciencia tiene el proyecto de la razón de ser de esas decisiones?
— ¿Cómo puede el proyecto influir en esas decisiones a medida que toma forma el diseño del sistema?
10. Si se han elegido algunos no estándares:
— ¿Cuáles son los requisitos comerciales y técnicos esenciales para no utilizar

normas?
— ¿Está respaldado por un caso de negocios?
— ¿Se han sometido a escrutinio los supuestos del caso empresarial?
11. ¿Cuál es su proceso para evaluar los costos del ciclo de vida completo del hardware y la operación?
sistemas?
12. ¿Cómo se ha involucrado la gestión financiera corporativa en la evaluación de los costos del ciclo de vida?
13. ¿Ha realizado un análisis financiero del proveedor?
14. ¿Ha asumido compromisos con algún proveedor?
15. ¿Cree que sus requisitos pueden ser cumplidos por un solo proveedor?
6.5.2 Lista de verificación de servicios de software y middleware
1. Describir cómo se definen, generan y propagan las condiciones de error entre aplicaciones
componentes
2. Describir el patrón general de cómo se definen y organizan los métodos en varios módulos de aplicación.
3. Describir el patrón general de cómo se definen y organizan los parámetros del método en varios módulos de
aplicación. ¿Los parámetros [in], [in/out], [out] siempre se especifican en el mismo orden? ¿Los valores booleanos
devueltos por los módulos tienen un resultado consistente?
4. Describa el enfoque que se utiliza para minimizar la cantidad de viajes de ida y vuelta entre las llamadas del cliente y
del servidor, en particular para llamadas fuera de proceso y cuando se involucran estructuras de datos complejas.
5. Describa las principales estructuras de datos que se transmiten entre los principales componentes del sistema.
6. Describir los principales protocolos de comunicación que se utilizan entre los principales sistemas
componentes
7. Describa las técnicas de cálculo de referencias que se utilizan entre varios componentes del sistema.
Describa los arreglos de clasificación especializados que se utilizan.
8. Describa en qué medida el sistema está diseñado con componentes con estado y sin estado.

redistribución
Cumplimiento de la arquitectura Listas de verificación de revisión del cumplimiento de la arquitectura
9. Describa cómo y cuándo se guarda el estado para los componentes con estado y sin estado.
10. Describa la medida en que los objetos se crean, usan y destruyen en comparación con la reutilización a través de
la agrupación de objetos.
11. Describa hasta qué punto el sistema se basa en subprocesos o codificación de secciones críticas.
12. Describa el enfoque y la documentación interna que se utiliza internamente en el sistema para documentar los
métodos, los argumentos de los métodos y la funcionalidad de los métodos.
13. Describa el proceso de revisión de código que se usó para construir el sistema.
14. Describa las pruebas unitarias que se han utilizado para probar los componentes del sistema.
15. Describa las pruebas previas y posteriores a la condición que se incluyen en varios módulos del sistema.
16. Describa las pruebas de afirmación que se incluyen con el sistema.
17. ¿Los componentes admiten todos los tipos de interfaz que necesitan admitir o se hacen ciertas suposiciones
sobre qué tipos de componentes llamarán a otros componentes en términos de enlaces de lenguaje u otras
formas de cálculo de referencias?
18. Describa hasta qué punto los problemas de formato de datos big-endian o little-endian deben manejarse en
diferentes plataformas.
19. Describa si los números o cadenas deben manejarse de manera diferente en diferentes plataformas.
20. Describa si el software necesita verificar errores de redondeo de punto flotante.
21. Describa cómo las funciones de hora y fecha manejan las fechas para evitar el manejo inadecuado del cálculo o
visualización de la hora y la fecha.
22. Describa qué herramientas o procesos se han utilizado para probar el sistema en busca de fugas de memoria,
accesibilidad o solidez general.
23. Describa las capas del software de servicios de sistemas. Describa el número general de enlaces entre los
principales componentes del sistema. ¿El sistema está compuesto por muchas interfaces punto a punto o en
su lugar se utilizan las principales redes troncales de mensajería?
24. Describa en qué medida los componentes del sistema están acoplados débilmente o estrechamente
acoplado.
25. ¿Qué requisitos necesita el sistema de la infraestructura en términos de bibliotecas compartidas, soporte para
protocolos de comunicación, equilibrio de carga, procesamiento de transacciones, monitoreo del sistema,
servicios de nombres u otros servicios de infraestructura?
26. Describa cómo se diseñan el sistema y los componentes del sistema para la refactorización.
27. Describa cómo el sistema o los componentes del sistema se basan en una infraestructura de mensajería común
frente a una estructura de comunicación única de punto a punto.

6.5.3 Listas de verificación de aplicaciones

6.5.3.1 Aplicaciones de infraestructura (productividad empresarial)
1. ¿Existe la necesidad de capacidades que no se proporcionan a través del estándar de la empresa?

productos de aplicación de infraestructura? Por ejemplo:
ÿ Colaboración
— Uso compartido de aplicaciones
- Videoconferencia
— Calendario
- Correo electrónico
ÿ Gestión del flujo de trabajo ÿ
Aplicaciones de edición/procesamiento de textos
— HTML
— SGML y XML
- Formato de Documento Portable
— Tramitación de documentos (formato propietario)
— Autoedición
ÿ Aplicaciones de hojas de cálculo
ÿ Aplicaciones de presentación
— Presentaciones de negocios
- Imagen
— Animación
- Video
- Sonido
— TCC
- Navegadores web
ÿ Aplicaciones de gestión de datos
— Interfaz de base de datos
- Gestión de documentos
- Manejo de datos de producto
— Almacenes de datos/mar t
ÿ Aplicaciones de gestión de programas
- Gestión de proyectos
— Visibilidad del programa

redistribución
2. Describa los requisitos comerciales para las capacidades de aplicación de infraestructura empresarial que no cumplen los
productos estándar.
6.5.3.2 Aplicaciones comerciales
1. ¿Alguna de las capacidades requeridas es proporcionada por productos estándar que admiten una o más aplicaciones de
línea de negocio? Por ejemplo:
ÿ Aplicaciones de adquisición de negocios
- Ventas y marketing
ÿ Aplicaciones de ingeniería
- Diseño asistido por ordenador
- Ingenieria asistida por computadora
— Análisis matemático y estadístico
ÿ Aplicaciones de gestión de proveedores
- Gestión de la cadena de suministro
— Gestión de las relaciones con los clientes
ÿ Aplicaciones de fabricación
— Aplicaciones de planificación de recursos empresariales (ERP)
— Sistemas de ejecución de fabricación
— Calidad de fabricación
— Ingeniería de procesos de fabricación
— Máquina y control adaptativo
ÿ Aplicaciones de atención al cliente
— Apoyo logístico a líneas aéreas
- Ingenieria de mantenimiento
ÿ Aplicaciones financieras
ÿ Aplicaciones de personas
ÿ Aplicaciones de instalaciones
ÿ Aplicaciones de sistemas de información
- Ingeniería de Sistemas
- Ingeniería de software
— Herramientas para desarrolladores web
— Entornos de desarrollo integrados
— Categorías del ciclo de vida
— Categorías funcionales

— Categorías de especialidad
ÿ Fabricación asistida por ordenador
ÿ habilitación de comercio electrónico
ÿ Ingeniería de procesos comerciales
— Control de calidad estadístico
2. Describir los requisitos del proceso para las capacidades de las aplicaciones comerciales que no cumplen los
productos estándar.
6.5.3.3 Enfoque de integración de aplicaciones
1. ¿Qué puntos de integración (proceso/actividad comercial, aplicación, datos, computación

entorno) son el objetivo de esta arquitectura?
2. ¿Qué técnicas de integración de aplicaciones se aplicarán (objetos comerciales comunes [Object Request Brokers
(ORB)], definiciones de datos estándar [XML, etc.], presentación/escritorio de interfaz de usuario común)?
6.5.4 Listas de verificación de gestión de la información

6.5.4.1 Valores de datos
1. ¿Cuáles son los procesos que estandarizan el manejo y uso de los datos?
2. ¿Qué proceso comercial respalda la entrada y validación de los datos? ¿Uso de los datos?
3. ¿Qué acciones comerciales corresponden a la creación y modificación de los datos?
4. ¿Qué acciones comerciales corresponden a la eliminación de los datos y se considera parte de un

registro comercial?
5. ¿Cuáles son los requisitos de calidad de datos requeridos por el usuario empresarial?
6. ¿Qué procesos existen para respaldar la normalización o la integridad referencial de los datos?
6.5.4.2 Definición de datos
1. ¿Cuáles son el modelo de datos, las definiciones de datos, la estructura y las opciones de hospedaje de los
aplicaciones (COTS)?
2. ¿Cuáles son las reglas para definir y mantener los requisitos y diseños de datos para todos los componentes del
sistema de información?
3. ¿Qué repositorio compartible se usa para capturar el contenido del modelo y la información de respaldo para los
datos?
4. ¿Cuál es la definición del modelo de datos físicos (derivada de los modelos de datos lógicos) utilizada para
diseñar la base de datos?
5. ¿Qué herramientas de desarrollo de software y gestión de datos se han seleccionado?
6. ¿Qué propietarios de datos se han identificado como responsables de las definiciones de datos comunes, eliminando
la redundancia no planificada, brindando información consistentemente confiable, oportuna y precisa, y protegiendo
los datos contra el uso indebido y la destrucción?

redistribución
6.5.4.3 Seguridad/Protección
1. ¿Cuáles son las reglas de acceso a atributos y entidades de datos que protegen los datos de
alteraciones, divulgación y distribución no intencionales y no autorizadas?
2. ¿Cuáles son los mecanismos de protección de datos para proteger los datos de terceros no autorizados?
¿acceso?
3. ¿Cuáles son los mecanismos de protección de datos para controlar el acceso a datos de fuentes externas?
que temporalmente tienen residencia interna dentro de la empresa?
6.5.4.4 Alojamiento, tipos de datos y uso compartido
1. ¿Cuál es la disciplina para administrar datos de autoridad única como una fuente lógica con
actualizar las reglas para los datos físicos que residen en diferentes plataformas?
2. ¿Cuál es la disciplina para gestionar datos replicados, que se derivan de datos operativos de autoridad única?
3. ¿Qué servidor de datos de nivel se identificó para el almacenamiento de datos críticos altos o medios?
¿Datos operacionales?
4. ¿Qué nivel de servidor de datos se ha identificado para el almacenamiento de datos operativos de tipo C?
5. ¿Qué nivel de servidor de datos se ha identificado para el almacenamiento de datos de soporte de decisiones?
contenido en un almacén de datos?
6. ¿Qué sistemas de gestión de bases de datos (DBMS) se han implementado?
6.5.4.5 Servicios Comunes
1. ¿Cuáles son los servicios de gestión de datos distribuidos estandarizados (p. ej., validación, controles de consistencia,
edición de datos, encriptación y gestión de transacciones) y dónde residen?
6.5.4.6 Método de acceso
1. ¿Cuáles son los requisitos de acceso a datos para archivos, mensajes y datos estándar?
¿administración?
2. ¿Cuáles son los requisitos de acceso a los datos de apoyo a la toma de decisiones?
3. ¿Cuáles son las ubicaciones de almacenamiento de datos y lógica de la aplicación?
4. ¿Qué lenguaje de consulta se está utilizando?
6.5.5 Lista de verificación de seguridad
1. Conciencia de seguridad: ¿Se ha asegurado de que las políticas y pautas de seguridad corporativas que está diseñando
sean las últimas versiones? ¿Los has leído? ¿Está al tanto de todos los procesos relevantes de cumplimiento de
seguridad informática y aceptación de riesgos?
(El entrevistador debe enumerar todas las políticas y pautas relevantes).

2. Identificación/Autenticación: Haga un diagrama del flujo del proceso de cómo se identifica un usuario en la aplicación y
cómo la aplicación autentica que el usuario es quien dice ser.
Proporcione documentación de respaldo al diagrama que explique el flujo desde la interfaz de usuario hasta los
servidores de aplicaciones/bases de datos y de regreso al usuario. ¿Cumple con las políticas corporativas sobre
cuentas, contraseñas, etc.?
3. Autorización: Proporcione un flujo de proceso de principio a fin que muestre cómo un usuario solicita acceso a la
aplicación, indicando los controles de seguridad asociados y la separación de funciones. Esto debe incluir cómo el
propietario de los datos apropiado aprueba la solicitud, cómo se coloca al usuario en el perfil de clasificación de nivel
de acceso apropiado, cómo se crea y proporciona al usuario la ID de usuario, la contraseña y el acceso. Incluya también
cómo se informa al usuario de sus responsabilidades asociadas con el uso de la aplicación, se le entrega una copia del
acuerdo de acceso, cómo cambiar la contraseña, a quién llamar para pedir ayuda, etc.
4. Controles de acceso: documente cómo se agregan, modifican, eliminan y documentan los ID de usuario, las contraseñas
y los perfiles de acceso. La documentación debe incluir quién es el responsable de estos procesos.
5. Protección de la información confidencial: proporcionar documentación que identifique los datos confidenciales que
requieren protección adicional. Identifique a los propietarios de los datos responsables de estos datos y el proceso que
se utilizará para proteger el almacenamiento, la transmisión, la impresión y la distribución de estos datos.
Incluya cómo se protege el archivo/campo de contraseñas. ¿Cómo se evitará que los usuarios vean la información
confidencial de otra persona? ¿Existen acuerdos con partes externas (socios, proveedores, contratistas, etc.) sobre la
salvaguarda de la información? Si es así, ¿cuáles son las obligaciones?
6. Pistas de auditoría y registros de auditoría: identifique y documente las cuentas de grupo requeridas por los usuarios o
el soporte de aplicaciones, incluidas las cuentas de grupo del sistema operativo. Identificar y documentar cuentas y/o
roles individuales que tienen privilegios de tipo superusuario, cuáles son estos privilegios, quién tiene acceso a estas
cuentas, cómo se controla, rastrea y registra el acceso a estas cuentas, y cómo se manejan el cambio y la distribución
de contraseñas. incluidas las cuentas del sistema operativo. También identifique los registros de auditoría, quién puede
leer los registros de auditoría, quién puede modificar los registros de auditoría, quién puede eliminar los registros de
auditoría y cómo se protegen y almacenan los registros de auditoría. ¿La ID de usuario está oculta en los registros de
auditoría?
7. Consideraciones de acceso externo: ¿Se utilizará la aplicación solo internamente? Si no, son
¿Cumple con los requisitos corporativos de acceso externo?
6.5.6 Lista de verificación de gestión del sistema

1. ¿Cuál es la frecuencia de los cambios de software que se deben distribuir?
2. ¿Qué herramientas se utilizan para la distribución de software?
3. ¿Se permiten múltiples versiones de software y/o datos en producción?
4. ¿Cuál es la frecuencia de la copia de seguridad de los datos del usuario y el tiempo de restauración esperado?
5. ¿Cómo se crean y administran las cuentas de usuario?
6. ¿Cuál es la estrategia de gestión de licencias del sistema?
7. ¿Qué herramientas generales de administración del sistema se requieren?

8. ¿Qué herramientas de administración de aplicaciones específicas se requieren?
9. ¿Qué herramientas específicas de administración de servicios se requieren?
10. ¿Cómo se reciben y envían las llamadas de servicio?
11. Describa cómo se desinstala el sistema.
12. Describa el proceso o las herramientas disponibles para comprobar que el sistema está correctamente instalado.
13. Describa las herramientas o instrumentación que están disponibles para monitorear la salud y
rendimiento del sistema.
14. Describa las herramientas o el proceso que se puede utilizar para determinar dónde se ha instalado el sistema.
15. Describa qué forma de registros de auditoría existen para capturar el historial del sistema, en particular después de una
percance.
16. Describa las capacidades del sistema para enviar sus propios mensajes de error al servicio
personal.
6.5.7 Listas de verificación de ingeniería del sistema/arquitectura general

6.5.7.1 Generalidades
1. ¿Qué otras aplicaciones y/o sistemas requieren integración con el suyo?
2. Describa el nivel de integración y la estrategia con cada uno.
3. ¿Qué tan distribuida geográficamente está la base de usuarios?
4. ¿Cuál es la importancia estratégica de este sistema para otras comunidades de usuarios dentro o
fuera de la empresa?
5. ¿Qué recursos informáticos se necesitan para brindar servicio del sistema a los usuarios dentro de la empresa? ¿Fuera
de la empresa y utilizando los activos informáticos de la empresa? ¿Fuera de la empresa y utilizando sus propios
activos?
6. ¿Cómo pueden los usuarios fuera del entorno de entrega nativo acceder a sus aplicaciones y
¿datos?
7. ¿Cuál es la expectativa de vida de esta aplicación?
8. Describa el diseño que se adapta a los cambios en la base de usuarios, los datos almacenados y la tecnología del sistema
de entrega.
9. ¿Cuál es el tamaño de la base de usuarios y su nivel de rendimiento esperado?
10. ¿Qué técnicas de prueba de rendimiento y estrés utiliza?
11. ¿Cuál es la organización general del software y los componentes de datos?
12. ¿Cuál es la configuración general del servicio y del sistema?
13. ¿Cómo se configuran y asignan el software y los datos al servicio y al sistema?

¿configuración?
14. ¿Qué tecnología patentada (hardware y software) se necesita para este sistema?
Estándar TOGAF® : capacidad y gobernanza de la arquitectura empresarial

47
15. Describa cómo se pueden reproducir y volver a implementar todas y cada una de las versiones del software.
tiempo extraordinario.
16. Describa la base de usuarios actual y cómo se espera que esa base cambie en los próximos tres a cinco años.
17. Describa la distribución geográfica actual de la base de usuarios y cómo esa base es
se espera que cambie en los próximos tres a cinco años.
18. Describa cuántos usuarios actuales o futuros necesitan usar la aplicación en una capacidad móvil o quiénes
necesitan trabajar sin conexión.
19. Describa qué hace generalmente la aplicación, los principales componentes de la aplicación y los principales
flujos de datos.
20. Describa la instrumentación incluida en la aplicación que permite la salud y

rendimiento de la aplicación a monitorear.
21. Describa la justificación comercial del sistema.
22. Describa la justificación para elegir el lenguaje de desarrollo del sistema sobre otras opciones en términos de
costo de desarrollo inicial versus costo de mantenimiento a largo plazo.
23. Describa el proceso de análisis de sistemas que se usó para generar la arquitectura del sistema y la fase de
selección de productos de la arquitectura del sistema.
24. ¿Quién además del cliente original podría tener un uso o beneficiarse del uso de este
¿sistema?
25. ¿Qué porcentaje de los usuarios utiliza el sistema en modo navegación versus modo actualización?
26. ¿Cuál es la duración típica de las solicitudes que son transaccionales?
27. ¿Necesita una entrega o actualización de datos garantizada, o el sistema tolera fallas?
28. ¿Cuáles son los requisitos de tiempo de actividad del sistema?
29. Describa dónde la arquitectura del sistema se adhiere o no a los estándares.
30. Describa el enfoque de planificación y análisis del proyecto utilizado en el proyecto.
6.5.7.2 Procesadores/Servidores/Clientes
1. Describa la arquitectura de la aplicación cliente/servidor.
2. Anote la imagen para ilustrar dónde se ejecuta la funcionalidad de la aplicación.
6.5.7.3 Cliente
1. ¿Se realizan otras funciones además de la presentación en el dispositivo del usuario?
2. Describa los datos y la función de ayuda al proceso que se proporciona.
3. Describa la técnica de navegación de pantalla a pantalla.
4. Describa cómo navega el usuario entre esta y otras aplicaciones.
5. ¿Cómo se lanza esta y otras aplicaciones desde el dispositivo del usuario?

redistribución
6. ¿Existen capacidades para compartir procesos y datos entre aplicaciones? Si es así, describa qué se está
compartiendo y mediante qué técnica/tecnología.
7. Describa los volúmenes de datos que se transfieren al cliente.
8. ¿Cuáles son los requisitos adicionales para el almacenamiento local de datos para admitir la aplicación?
9. ¿Cuáles son los requisitos adicionales para el almacenamiento/memoria de software local para admitir el
¿solicitud?
10. ¿Existen conflictos conocidos de hardware/software o limitaciones de capacidad causados por otros requisitos o
situaciones de la aplicación que podrían afectar a los usuarios de la aplicación?
11. Describa cómo se compara la apariencia de su capa de presentación con la apariencia

de las otras aplicaciones existentes.
12. Describa en qué medida el cliente necesita soportar asíncrono y/o síncrono
comunicación.
13. Describa cómo se separa la capa de presentación del sistema de otras capas computacionales o de transferencia
de datos del sistema.
6.5.7.4 Servidor de aplicaciones
1. ¿Pueden/se ejecutan la capa de presentación y las capas de aplicación en procesadores separados?
2. ¿La capa de aplicación y la capa de acceso a datos pueden ejecutarse en procesadores separados?
3. ¿Se puede colocar esta aplicación en un servidor de aplicaciones independiente de todos los demás?
aplicaciones? Si no, explique las dependencias.
4. ¿Se pueden agregar fácilmente servidores de aplicaciones paralelos adicionales? Si es así, ¿cuál es la carga?
mecanismo de equilibrio?
5. ¿Se ha medido la demanda de recursos generada por la aplicación y cuál es el valor? De ser así, ¿se ha confirmado
la capacidad del servidor planificado a nivel de aplicación y agregado?
6.5.7.5 Servidor de datos
1. ¿Existen otras aplicaciones que deban compartir el servidor de datos? En caso afirmativo, identifíquelos y
describa los datos y los requisitos de acceso a los datos.
2. ¿Se ha medido la demanda de recursos generada por la aplicación y cuál es el valor? De ser así, ¿se ha confirmado
la capacidad del servidor planificado a nivel de aplicación y agregado?
6.5.7.6 COTS (cuando corresponda)
1. ¿Es el vendedor sustancial y estable?
2. ¿Recibirá la empresa el código fuente tras la muerte del proveedor?
3. ¿Este software está configurado para el uso de la empresa?

4. ¿Existen datos o procesos peculiares de A&D que impidan el uso de este software?
— ¿Este software está disponible actualmente?
5. ¿Se ha utilizado/demostrado para requisitos de volumen/disponibilidad/nivel de servicio similares a los de la empresa?
— Describa el historial financiero y de participación de mercado del proveedor.
6.5.8 Lista de verificación de ingeniería de sistemas/métodos y herramientas
1. ¿Existen métricas para la forma actual de hacer negocios?
2. ¿Ha creado el propietario del sistema criterios de evaluación que se utilizarán para guiar el proyecto?
Describa cómo se utilizarán los criterios de evaluación.
3. ¿Se han realizado investigaciones de arquitecturas existentes para aprovechar el trabajo existente? Describa el método
utilizado para descubrir y comprender. ¿Se integrarán las arquitecturas? En caso afirmativo, explique el método que se
utilizará.
4. Describa los métodos que se utilizarán en el proyecto:
— Para la definición de estrategias comerciales
— Para definir áreas que necesitan mejoras
— Para definir los procesos comerciales de referencia y de destino
— Para definir procesos de transición
— Para la gestión del proyecto
— Para la comunicación del equipo
— Para la gestión del conocimiento, la gestión de cambios y la gestión de la configuración
— Para el desarrollo de software
— Para referenciar estándares y declaraciones de dirección
— Para el aseguramiento de la calidad de los entregables
— Para revisiones de diseño y aceptación de entregables
— Para capturar métricas
5. ¿Los métodos están documentados y distribuidos a cada miembro del equipo?
6. ¿Hasta qué punto están familiarizados los miembros del equipo con estos métodos?
7. ¿Qué procesos existen para garantizar el cumplimiento de los métodos?
8. Describa la infraestructura que existe para respaldar el uso de los métodos hasta el final del proyecto y las liberaciones
anticipadas.
— ¿Cómo se proporciona la consulta y resolución de problemas?
— ¿Cómo se coordina la formación?
— ¿Cómo se incorporan y conectan en cascada los cambios y las mejoras?
50
The Open Group Standard (2022) ©
— ¿Cómo se capturan y comunican las lecciones aprendidas?
9. ¿Qué herramientas se están utilizando en el proyecto? (Especificar versiones y plataforma). A qué

¿En qué medida los miembros del equipo están familiarizados con estas herramientas?
10. Describa la infraestructura que existe para respaldar el uso de las herramientas hasta el final del proyecto y los
lanzamientos anticipados.
— ¿Cómo se proporciona la consulta y resolución de problemas?
— ¿Cómo se coordina la formación?
— ¿Cómo se incorporan y conectan en cascada los cambios y las mejoras?
— ¿Cómo se capturan y comunican las lecciones aprendidas?
11. Describa cómo el proyecto promoverá la reutilización de sus entregables y entregables

contenido.
12. ¿Los diseños de arquitectura "vivirán" después de que se haya implementado el proyecto? Describa el método que se
utilizará para incorporar los cambios nuevamente en los diseños de arquitectura.
13. ¿Se definieron los procesos actuales?
14. ¿Se documentaron, calificaron y asociaron los problemas a los procesos actuales? Si no, ¿cómo
¿Sabes que estás arreglando algo que está roto?
15. ¿Se identificaron y asociaron las actividades de mejora de procesos existentes/planificadas a los procesos actuales? Si
no es así, ¿cómo sabe que esta actividad no está en conflicto o es redundante con otras declaraciones de trabajo?
16. ¿Tiene métricas actuales? ¿Tiene métricas pronosticadas? Si no, ¿cómo sabes
estas mejorando algo?
17. ¿Qué procesos implementará para recopilar, evaluar y reportar métricas?
18. ¿Qué impactos tendrá el nuevo diseño en los procesos comerciales, organizaciones y sistemas de información
existentes? ¿Se han documentado y compartido con los propietarios?
6.6 Directrices de revisión del cumplimiento de la arquitectura

6.6.1 Adaptación de las listas de verificación
ÿ Concéntrese en:
— Zonas de alto riesgo
— Diferenciadores esperados (y emergentes)
ÿ Para cada pregunta de la lista de verificación, comprenda:
— La pregunta en sí
— El principio detrás de esto
— Qué buscar en las respuestas
ÿ Pida a los expertos en la materia sus puntos de vista

Directrices de revisión del cumplimiento de la arquitectura Cumplimiento de la arquitectura
ÿ Corrija las preguntas de la lista de verificación para su uso
ÿ Tener en cuenta la necesidad de retroalimentación a la Junta de Arquitectura
6.6.2 Realización de revisiones de cumplimiento de la arquitectura

ÿ Comprender claramente los objetivos de quienes solicitan la revisión; y mantener el rumbo y entregar lo que se pidió. Por
ejemplo, normalmente quieren saber qué está bien o mal con el sistema que se está diseñando; no lo que está bien o mal
con la metodología de desarrollo utilizada, su propia estructura de gestión, etc. Es fácil desviarse y discutir temas que son
interesantes y quizás valiosos, pero no lo que se solicitó. Si puede arrojar luz y comprensión sobre los enfoques técnicos,
pero la discusión no es necesaria para la revisión, ofrézcase como voluntario para brindarla después de la revisión.
ÿ Si se vuelve obvio durante la discusión que hay otros problemas que deben abordarse, que están fuera del alcance de la
revisión solicitada, tráigalo luego al presidente de la reunión. Luego se puede desarrollar un plan para abordar los problemas
de acuerdo con su grado de gravedad.
ÿ Manténgase "científico". En lugar de: "Nos gusta ver grandes bases de datos alojadas en ABC en lugar de XYZ", diga cosas
como: "El tiempo de inactividad asociado con los entornos de bases de datos XYZ es mucho mayor que en los entornos de
bases de datos ABC. Por lo tanto, no recomendamos alojar los tipos M y N sistemas en un entorno XYZ".
ÿ Haga preguntas "abiertas"; es decir, preguntas que no presuponen una respuesta particular.
ÿ A menudo hay "agendas ocultas" o temas controvertidos entre quienes solicitan una revisión, que probablemente no sabrá
por adelantado. Un enfoque despersonalizado de las discusiones puede ayudar a cerrar las brechas de opinión en lugar de
exacerbarlas.
ÿ Trate a los entrevistados con respeto. Es posible que no hayan construido el sistema "como debería ser", pero probablemente
lo hicieron lo mejor que pudieron bajo las circunstancias en las que se encontraban.
ÿ Ayude a que el ejercicio se convierta en una experiencia de aprendizaje para usted y los presentadores.
ÿ Las revisiones deben incluir actividades de evaluación detalladas contra las arquitecturas y deben
Asegúrese de que los resultados se almacenen en Enterprise Continuum.

Índice
ADM .................................................. .................................................... ...........27 Tablero de

Arquitectura ............................... .................................................... ..21 Capacidad de la
arquitectura........................................... ..........................................3 Cumplimiento de la
arquitectura ........ .................................................... .....................31 listas de
control .......................... .................................................... ..........................39
directrices ................................ .................................................... ......................51
reseña ................................ .................................................... ............................33 proceso
de revisión ............... .................................................... ..........................36 Contrato de
Arquitectura .......................... .................................................... ........27 Arco Gobernanza de la
literatura .............................................. ....................9, 12, 21
implementación ........................ .................................................... ..........18 Marco de
Gobernanza de la Arquitectura ............................... .........................9, 13
estructura.................... .................................................... ..............................13
COBIT ............... .................................................... ..........................................12 Marco
COBIT ........ .................................................... ..............................24 gobierno
corporativo ............... .................................................... ....................9
CUNAS ................................ .................................................... ..............................33
dispensación .................. .................................................... .............................15 carácter de
gobernanza i stics .................................................. ..........................................10
ISACF ...... .................................................... .................................................... .12 Gobernanza
de TI .............................................. .............................................9, 11 Gobernanza de TI
Instituto................................................. ..........................12
OLA ................ .................................................... .............................................15, 26 acuerdo a
nivel operativo .... .................................................... ..............15, 26
ORBE ................................ .................................................... ............................44 acuerdo de
nivel de servicio ................ .................................................... ..............15
ANS ................................. .................................................... ...............15, 22, 30 Declaraciones
t de Obra de Arquitectura.................................................... .......................29 Gobernanza de la
tecnología ....................... .................................................... ...9, 11

Índice

redistribución

C220 Part5e

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

C220 Part5e

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

El estándar de grupo abierto

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

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

Copyright © 2005-2022, The Open Group

Reservados todos los derechos.

El estándar de grupo abierto

Estándar TOGAF® — Capacidad y gobernanza de la arquitectura empresarial

Publicado por The Open Group, 2005-2022.

yo The Open Group Standard (2022)

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

Capitulo 2 Establecimiento de una capacidad de arquitectura ........... 3

Capítulo 3 Gobernanza de la arquitectura .................................................. ....... 9

Capítulo 4 Junta de Arquitectura ................................................. ..................... 21

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

4.4.3 Agenda................................................. .......................................... 25

Capítulo 5 5.1 5.2 Contratos de arquitectura ................................................ ............ 27

Capítulo 6 6.1 6.2 Cumplimiento de la arquitectura ................................................... ........ 31

Índice .................................................. ............................................. 53

3-1 Marco de Gobernanza de la Arquitectura — Conceptual

IV El estándar de grupo abierto (2022)

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

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

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

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

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

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

vi The Open Group Standard (2022)

Este es el estándar TOGAF: capacidad y gobernanza de la arquitectura empresarial.

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

viii The Open Group Standard (2022)

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

X The Open Group Standard (2022)

Las pautas incluidas en este documento son las siguientes:

ÿ Gobernanza de la arquitectura (consulte el Capítulo 3) proporciona un marco y pautas para la arquitectura.

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

2 The Open Group Standard (2022)

Capítulo 2: Establecimiento de una capacidad de arquitectura

ÿ La Arquitectura de Negocios de la práctica de la arquitectura que destacará la Gobernanza de la Arquitectura,

ÿ La Arquitectura de Datos que definiría la estructura de la Empresa de la organización

ÿ La arquitectura tecnológica que describe los requisitos de infraestructura de la práctica de arquitectura y la

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

Visión general Establecimiento de una capacidad de arquitectura

2.2 Fase A: Visión de la Arquitectura

ÿ Desarrollar Declaración de Trabajo de Arquitectura y Aprobación segura: este paso genera la

4 The Open Group Standard (2022)

Establecimiento de una capacidad de arquitectura Fase B: Arquitectura Empresarial

2.3 Fase B: Arquitectura empresarial

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

Fase C: Arquitectura de datos Establecimiento de una capacidad de arquitectura

2.4 Fase C: Arquitectura de datos

2.5 Fase C: Arquitectura de la aplicación

2.6 Fase D: Arquitectura Tecnológica

2.7 Fase E: Oportunidades y Soluciones

2.8 Fase F: Planificación de la migración

2.9 Fase G: Implementación Gobernanza

6 The Open Group Standard (2022)

Establecimiento de una capacidad de arquitectura Fase H: Gestión del cambio de arquitectura

2.10 Fase H: Gestión de cambios de arquitectura

2.11 Gestión de requisitos

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

Establecimiento de una capacidad de arquitectura

8 The Open Group Standard (2022)