C220 Part3e

Machine Translated by Google
Copia de evaluación
El estándar de grupo abierto
Estándar TOGAF® —Aplicación del ADM
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® — Aplicación del ADM
ISBN: 1-947754-90-4
Número de documento: C220
Publicado por The Open Group, 2005-2022.
Cualquier comentario relacionado con el material contenido en este documento puede enviarse por correo electrónico a:
ogspecs@opengroup.org
yo The Open Group Standard (2022)

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

1.1 Uso del marco TOGAF con diferentes
Estilos de arquitectura ................................................ .......................... 1
Capitulo 2 Aplicación de iteración al ADM.................................................... .3

2.1 Visión general................................................ ............................................. 3
2.2 Ciclos de iteración................................................. ............................... 4
2.3 Clases de Compromiso con la Arquitectura.......................................... 5
2.4 Enfoques para el desarrollo de la arquitectura ................................ 9
2.5 Consideraciones de iteración .................................................. .................... 10
2.5.1 Iteración entre ciclos ADM ............................................... ...... 10
2.5.2 Iteración dentro de un ciclo ADM ............................................... ........ 12
2.6 Conclusiones .................................................. ................................... 15
Capítulo 3 Aplicación de ADM en toda la arquitectura

Paisaje................................................. .................................... 17
3.1 Visión general................................................ .......................................... 17
3.2 Arquitectura Paisaje .................................................. .................... 17
3.3 Desarrollo de Arquitecturas en Diferentes Niveles .................................. 19
3.4 Organizando el Paisaje Arquitectónico para Comprender
el estado de la empresa ............................................... .................... 19
Capítulo 4 Particiones de la arquitectura .................................................... ......... 21

4.1 Visión general................................................ .......................................... 21
4.2 Aplicar clasificación para crear particiones
arquitecturas .................................................. .................................... 21
4.2.1 Actividades dentro de la Fase Preliminar .......................................... 23
4.3 Integración .................................................. ...................................... 24
Índice .................................................. ............................................. 27
Lista de Figuras
2-1 Ciclos de iteración................................................. .................................... 4

2-2 Clases de Compromiso con la Arquitectura Empresarial ........................... 5
2-3 Un ejemplo de jerarquía de procesos ADM .......................................... 10
2-4 Actividad por iteración para Baseline First Architecture
Definición ................................................. .......................................... 12
2-5 Actividad por iteración para Target First Architecture
Definición ................................................. .......................................... 12
3-1 Resumen del modelo de clasificación para la arquitectura
Paisajes .................................................. ...................................... 17
Estándar TOGAF® — Aplicación del ADM iii

© 2005-2022 The Open Group, Todos los derechos reservados
Contenido
3-2 Resumen de Arquitectura Continuum ............................................... ... 18

4-1 Asignación de Equipos al Ámbito de la Arquitectura.......................................... 24
4-2 Agregación de contenido de arquitectura ............................................... ...... 25
IV El estándar de grupo abierto (2022)

© 2005-2022 El Grupo Abierto, Todos los derechos reservados
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.
Estándar TOGAF® : aplicación de ADM v

Prefacio
Este documento
Este es el estándar TOGAF: aplicación del ADM.
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.
vi The Open Group Standard (2022)

redistribución
Marcas registradas
ArchiMate, DirecNet, Making Standards Work, el logotipo de Open O, Open O y el logotipo de Check Cer tification, The Open
Group, TOGAF, UNIX, UNIXWARE y el logotipo de Open Brand X son marcas comerciales registradas y flujo de información sin
límites, compilado con Integridad Compre con confianza, Arquitectura de referencia de aviación comercial, Fiabilidad a través de la
garantía, Cuerpo de conocimiento del profesional digital, DPBoK, EMMM, FACE, el logotipo de FACE, FHIM Profile Builder, el
logotipo de FHIM, FPB, Future Airborne Capability Environment, IT4IT, el logotipo de IT4IT , O-AA, O-DEF, O-HERA, O-PAS, Open
Agile Architecture, Open FAIR, Open Footprint, Open Process Automation, Open Subsurface Data Universe, Open Trusted
Technology Provider, OSDU, Sensor Integration Simplified, SOSA, y el logotipo de SOSA son marcas registradas de The Open
Group.
The Open Group reconoce que puede haber otros nombres de empresas y productos que podrían estar cubiertos por la protección
de marcas registradas y aconseja al lector que los verifique de forma independiente.
Estándar TOGAF® : aplicación de ADM viii

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.
viii 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: aplicación del ADM (este
documento).
El proceso del Método de desarrollo de arquitectura (ADM) se puede adaptar para manejar muchos escenarios de uso diferentes,
incluidos diferentes estilos de proceso (p. ej., el uso de la iteración) y también arquitecturas especializadas específicas (como la
seguridad). Las pautas incluidas en este documento son las siguientes:
ÿ Usar el Marco TOGAF con Diferentes Estilos de Arquitectura (ver Sección 1.1) discute cómo el
el marco se puede adaptar a diferentes estilos arquitectónicos
ÿ La aplicación de la iteración al ADM (consulte el Capítulo 2) analiza el concepto de iteración y muestra

estrategias potenciales para aplicar conceptos iterativos al ADM
ÿ La aplicación de ADM en el panorama de la arquitectura (consulte el Capítulo 3) analiza los diferentes tipos de compromiso
con la arquitectura que pueden ocurrir en los diferentes niveles de la empresa; esta sección también analiza cómo se puede
enfocar el proceso de ADM para admitir diferentes tipos de compromiso.
ÿ Arquitectura de particiones (consulte el Capítulo 4) explica cómo se utilizan las particiones para simplificar la
desarrollo y gestión de la Arquitectura Empresarial
1.1 Uso de TOGAF Framework con diferentes estilos de arquitectura

El marco TOGAF está diseñado para ser flexible y se utiliza con varios estilos arquitectónicos.
Los estilos arquitectónicos difieren en términos de enfoque, forma, técnicas, materiales, tema y período de tiempo.
El estándar TOGAF es un marco genérico destinado a ser utilizado en una amplia variedad de entornos. Es un marco
flexible y extensible que se puede adaptar fácilmente a una serie de estilos arquitectónicos.
Se puede esperar que el Paisaje Arquitectónico de una organización contenga trabajo de arquitectura desarrollado en
muchos estilos arquitectónicos. El estándar TOGAF garantiza que las necesidades de cada parte interesada se aborden
adecuadamente en el contexto de otras partes interesadas y la Arquitectura de referencia.
Al utilizar el estándar TOGAF para respaldar un estilo arquitectónico específico, el practicante debe tener en cuenta la
combinación de características distintivas en las que se realiza o expresa la arquitectura. Como primer paso, se deben
identificar las características distintivas de un estilo.
El segundo paso es determinar cómo se abordarán estas características distintivas. Abordar un estilo distintivo no
debería requerir cambios significativos en el marco TOGAF; en su lugar, debe ajustar los modelos, puntos de vista y
herramientas utilizadas por el profesional.
En la Fase B, Fase C y Fase D, se espera que el profesional seleccione los recursos de arquitectura relevantes,
incluidos modelos, puntos de vista y herramientas, para describir correctamente el dominio de la arquitectura y demostrar
que se abordan las preocupaciones de las partes interesadas (consulte el Estándar TOGAF: Técnicas ADM).
Dependiendo de las características distintivas, los diferentes estilos arquitectónicos agregarán nuevos elementos que
deben describirse, resaltarán elementos existentes, ajustarán la notación utilizada para
Estándar TOGAF® : aplicación de ADM 1

Uso del marco TOGAF con diferentes estilos de arquitectura Introducción
describir la arquitectura y enfocar al arquitecto en algunas partes interesadas o partes interesadas

preocupaciones.
Abordar las características distintivas generalmente incluirá extensiones al metamodelo de contenido de arquitectura y el
uso de técnicas específicas de notación o modelado y la identificación de puntos de vista. El predominio de un estilo
arquitectónico en particular puede llevar al practicante a revisar la Fase preliminar para realizar cambios en la Capacidad
de la arquitectura o para abordar una característica distintiva en el alcance esperado de un solo ciclo de ADM.
Los modelos de referencia específicos del estilo y los modelos de madurez son herramientas de uso común que apoyan a
un profesional.
Durante la vida útil del marco TOGAF, se han desarrollado muchos estilos arquitectónicos para abordar los problemas
clave que enfrentan los profesionales y para demostrar cómo el marco TOGAF puede volverse más relevante dentro de
contextos definidos.
Algunos de estos han sido desarrollados por los Foros y Grupos de Trabajo de The Open Group que trabajan en áreas
específicas y han sido publicados en Guías, Libros Blancos y Estándares. Ejemplos incluyen:
ÿ Guía de la serie TOGAF® : uso del marco TOGAF® para definir y gobernar el servicio
Arquitecturas orientadas
ÿ Guía de la serie TOGAF® : Integración del riesgo y la seguridad dentro de una empresa TOGAF®
Arquitectura
Algunos de estos han sido desarrollados en colaboración entre The Open Group y otros organismos.
Ejemplos incluyen:
ÿ Integración de TOGAF® y SABSA® ÿ Archi
Banking Group: combinación del modelo de referencia BIAN, modelado ArchiMate®

Notación y TOGAF® Framework
ÿ Exploración de sinergias entre TOGAF® y Frameworx ÿ TOGAF® 9 y
DoDAF 2.0
La biblioteca TOGAF (consulte www.opengroup.org/togaf-librar y) es una biblioteca estructurada de recursos que respaldan
el estándar TOGAF.
2 The Open Group Standard (2022)

redistribución
Capítulo 2: Aplicación de la iteración al ADM
2.1 Resumen
La representación gráfica de TOGAF ADM y la descripción de las fases de ADM discretamente en orden, como se
muestra en el estándar TOGAF — Método de desarrollo de arquitectura, puede interpretarse como una metodología
determinista en cascada. Este método de presentación se proporciona con el propósito de comunicar rápidamente los
conceptos básicos del desarrollo de la arquitectura y el ciclo de desarrollo de la arquitectura. En la práctica, se utilizan
dos conceptos clave para gestionar la complejidad de desarrollar una arquitectura empresarial y gestionar su ciclo de
vida: iteración y niveles (consulte el Capítulo 3). Los dos conceptos están estrechamente vinculados.
El ADM admite una serie de conceptos que se caracterizan como iteración. Primero, la iteración describe el proceso de
descripción de un Paisaje Arquitectónico integral a través de múltiples ciclos ADM basados en iniciativas individuales
vinculadas al alcance de la Solicitud de Trabajo Arquitectónico. En segundo lugar, la iteración describe el proceso
integrado de desarrollo de una arquitectura donde las actividades descritas en diferentes fases de ADM interactúan
para producir una arquitectura integrada. Para describir de manera concisa la actividad y los resultados, esta última
iteración se describe en términos secuenciales. En tercer lugar, la iteración describe el proceso de gestión de cambios
en la capacidad de la arquitectura de la organización.
Iteración para desarrollar un Paisaje Arquitectónico integral:
ÿ Los proyectos se ejercitarán durante todo el ciclo ADM, comenzando con la Fase A
Cada ciclo de la ADM estará vinculado por una Solicitud de Obra de Arquitectura. El resultado de la arquitectura
poblará el paisaje arquitectónico, ya sea extendiendo el paisaje descrito o cambiando el paisaje donde sea
necesario.
ÿ Los proyectos separados pueden operar sus propios ciclos de ADM al mismo tiempo, con relaciones entre los
diferentes proyectos
ÿ Un proyecto puede desencadenar el inicio de otro proyecto
Por lo general, esto se usa cuando las iniciativas de arquitectura de alto nivel identifican oportunidades o
soluciones que requieren una arquitectura más detallada, o cuando un proyecto identifica impactos en el paisaje
fuera del alcance de su Solicitud de trabajo de arquitectura.
Iteración dentro de un ciclo ADM (iteración de desarrollo de arquitectura):
ÿ Los proyectos pueden operar múltiples fases de ADM al mismo tiempo
Por lo general, esto se utiliza para gestionar la interrelación entre la arquitectura empresarial, la arquitectura de
sistemas de información y la arquitectura tecnológica.
ÿ Los proyectos pueden alternar entre las fases de ADM, en ciclos planificados que cubren múltiples fases
Por lo general, esto se usa para converger en una arquitectura de destino detallada cuando

Visión general Aplicación de iteración al ADM
la arquitectura no existe para proporcionar contexto y restricciones.
ÿ Los proyectos pueden volver a las fases anteriores para actualizar los productos de trabajo con nueva información
Por lo general, esto se usa para converger en una hoja de ruta de arquitectura ejecutable o un plan de implementación y
migración, cuando los detalles de implementación y el alcance del cambio desencadenan un cambio o una nueva
priorización de los requisitos de las partes interesadas.
Iteración para administrar la capacidad de la arquitectura (iteración de la capacidad de la arquitectura):
ÿ Los proyectos pueden requerir una nueva iteración de la Fase Preliminar para (restablecer) aspectos de la Capacidad de
Arquitectura identificada en la Fase A para abordar una Solicitud de Arquitectura
Trabajar
ÿ Los proyectos pueden requerir una nueva iteración de la Fase Preliminar para ajustar la
Arquitectura Capacidad como resultado de la identificación de requisitos nuevos o modificados para
Capacidad de la arquitectura como resultado de una solicitud de cambio en la fase H
2.2 Ciclos de iteración Los
ciclos de iteración sugeridos para TOGAF ADM se muestran en la Figura 2-1 y se pueden usar para agrupar de manera efectiva
actividades arquitectónicas relacionadas para lograr un propósito específico. Estos ciclos de iteración se mencionan en la
Sección 2.3 y la Sección 2.5.
Arquitectura
Capacidad
Iteración Preliminar
Arquitectura
Desarrollo
Iteración
UNA.
Arquitectura Visión de la
Gobernancia arquitectura
Iteración h
B.
Gestión de
Arquitectura
cambios de
empresarial
arquitectura
C.
GRAMO.
Requisitos Arquitecturas
Gobernanza de la
administración de Sistemas
implementación
de Información
F. D.
Migración Arquitectura
Planificación Tecnológica
MI.
Oportunidades y
Soluciones
Transición
Planificación
Iteración
© El Grupo Abierto
Figura 2-1 Ciclos de iteración

redistribución
Aplicación de iteración al ADM Ciclos de iteración
ÿ Las iteraciones de la capacidad de la arquitectura admiten la creación1 y la evolución de la

Capacidad de arquitectura
Esto incluye la movilización inicial de la actividad de la arquitectura para un propósito dado o un tipo de compromiso
con la arquitectura al establecer o ajustar el enfoque, los principios, el alcance, la visión y la gobernanza de la
arquitectura.
ÿ Las iteraciones de desarrollo de arquitectura permiten la creación de contenido de arquitectura mediante el ciclo o
la integración de las fases de arquitectura comercial, de sistemas de información y de tecnología.
Estas iteraciones aseguran que la arquitectura se considere como un todo. En este tipo de iteración, las revisiones
de las partes interesadas suelen ser más amplias. A medida que las iteraciones convergen en un objetivo, las
extensiones a las fases de Oportunidades y soluciones y Planificación de la migración aseguran que la
implementación de la arquitectura se considere a medida que se finaliza la arquitectura.
ÿ Las iteraciones de planificación de transición admiten la creación de hojas de ruta de cambios formales para una
arquitectura definida
ÿ Las iteraciones de Gobernanza de arquitectura respaldan la gobernanza de la actividad de cambio en progreso

hacia una arquitectura objetivo definida
2.3 Clases de Compromiso con la Arquitectura

Se puede solicitar una función de arquitectura o una organización de servicios para ayudar a una empresa en una serie de
contextos diferentes, ya que las arquitecturas desarrolladas pueden variar de resumen a detalle, de cobertura amplia a
estrecha y de estado actual a estado futuro. En estos contextos, el concepto de iteración debe utilizarse en el desarrollo
de la arquitectura.
Por lo general, hay tres áreas de compromiso para los arquitectos:
ÿ Identificación del cambio requerido: fuera del contexto de cualquier iniciativa de cambio, la arquitectura se puede
utilizar como una técnica para brindar visibilidad de la capacidad de TI a fin de respaldar la toma de decisiones
estratégicas y la alineación de la ejecución.
ÿ Definición de cambio: cuando se ha identificado la necesidad de cambiar, la arquitectura se puede utilizar como
técnica para definir la naturaleza y el alcance del cambio de forma estructurada.
Dentro de las iniciativas de cambio a gran escala, las arquitecturas se pueden desarrollar para proporcionar una
Definición de Arquitectura detallada para las iniciativas de cambio que están delimitadas por el alcance de un
programa o cartera.
ÿ Implementación del cambio: la arquitectura en todos los niveles de la empresa se puede utilizar como una técnica
para proporcionar gobernanza del diseño para cambiar las iniciativas proporcionando una visibilidad general,
suministrando restricciones estructurales y definiendo criterios sobre los cuales evaluar las decisiones técnicas.
La figura 2-2 y la siguiente tabla muestran las clases de participación de Enterprise Architecture.
1. La guía sobre cómo usar un ciclo ADM completo para establecer inicialmente la capacidad de arquitectura de una organización se encuentra en el
estándar TOGAF: capacidad y gobierno de arquitectura empresarial.

Clases de Compromiso de Arquitectura Aplicación de iteración al ADM
Identificación del cambio requerido Definición de cambio

La estrategia empresarial
Definición arquitectónica de
identifica una necesidad de cambio
donde no se entiende el Iniciativas de cambio fundamentales
objetivo
Los aspectos de las
La implementación de
grandes iniciativas de
la arquitectura debe
Apoyo a la estrategia empresarial cambio requieren sus
propias arquitecturas regirse
El negocio El negocio La estrategia comercial

estrategia estrategia identifica la necesidad
establece establece de cambiar donde el Definición arquitectónica de
prioridad para la cartera prioridad para la cartera objetivo se entiende bien
Iniciativas de cambio limitado
La evaluación de la cartera
identifica la necesidad
específica de cambiar
Implementación del cambio
La implementación de
Portafolio Arquitectónico la arquitectura debe
regirse
Gestión del Paisaje Los problemas
La cartera escalados
proporciona contexto influyen en la
para la gobernanza portafolio
Portafolio Arquitectónico Gobernanza Arquitectónica de
Gestión de Proyectos Implementación de cambios
Actividades de arquitectura que apoyen la identificación de una necesidad de cambio.

© El Grupo Abierto
Actividades de arquitectura que apoyan la definición de cómo se puede lograr el cambio.
Actividades de arquitectura que gobiernan la implementación del cambio.
Figura 2-2 Clases de Compromiso con la Arquitectura Empresarial
Cada uno de estos tipos de interacción con la arquitectura se describe en la siguiente tabla.
Area de Arquitectura
Compromiso Compromiso Descripción A
Identificacion de apoyando medida que cambian las estrategias comerciales, los
Cambio requerido Estrategia de negocios objetivos, las metas y los impulsores, es necesario que la
empresa cambie para mantener la alineación.
La creación de nuevas estrategias comerciales puede ser

apoyada por Enterprise Architecture mediante:
ÿ Proporcionar visibilidad de las

oportunidades de cambio
ÿ Proporcionar detalles sobre los impactos prácticos

de una elección estratégica particular
ÿ Proporcionar pruebas sobre la factibilidad o

viabilidad de una dirección estratégica particular

redistribución
Aplicación de iteración al ADM Clases de Compromiso de Arquitectura
Compromiso Compromiso Descripción
Arquitectónico Es una práctica común en las grandes
portafolio organizaciones que una organización de gestión de
Gestión de la servicios proporcione informes operativos y gestión de
Paisaje la cartera de TI.
La arquitectura empresarial puede agregar una

dimensión adicional a los informes de gestión de servicios,
al respaldar un vínculo entre el rendimiento operativo y
la necesidad estratégica de TI.
Utilizando la trazabilidad entre TI y el negocio inherente a

Enterprise Architecture, es posible evaluar la cartera de TI
frente a los datos de rendimiento operativo y las necesidades
del negocio (por ejemplo, costo, funcionalidad, disponibilidad,
capacidad de respuesta) para determinar las áreas donde
se produce la desalineación y las necesidades de cambio.
tomar lugar.
Arquitectónico Es una práctica común en las grandes

portafolio organizaciones que una organización de gestión de
Administración de programas proporcione informes operativos y gestión de
Proyectos la cartera de cambios.
Enterprise Architecture puede agregar una dimensión

adicional a los informes de gestión de carteras de
proyectos, al respaldar un vínculo entre el alcance del
proyecto, el impacto arquitectónico y el valor empresarial.
Los factores arquitectónicos se pueden agregar a otros

factores cuantitativos del proyecto para respaldar la toma de
decisiones estratégicas sobre la prioridad del proyecto y los
niveles de financiación.
Definicion de Arquitectónico Las iniciativas de cambio fundamental son esfuerzos
Cambio Definicion de de cambio que tienen un objetivo conocido, pero que no
Fundacional tienen un alcance estricto ni están limitados por una visión
Iniciativas de cambio o requisitos compartidos.
En las iniciativas de cambio fundamental, la prioridad

inicial es comprender la naturaleza del problema y
estructurar la definición del problema.
Una vez que el problema se comprende de

manera más efectiva, es posible definir soluciones
apropiadas y alinear a las partes interesadas en torno a
una visión y un propósito comunes.

Clases de Compromiso de Arquitectura Aplicación de iteración al ADM
Compromiso Compromiso Descripción
Arquitectónico Las iniciativas de cambio limitado son esfuerzos de cambio
Definicion de que normalmente surgen como resultado de una estrategia,
Cambio acotado evaluación o visión arquitectónica anterior.
Iniciativas
En las iniciativas de cambio limitado, el resultado
deseado ya se comprende y se acuerda. El enfoque
del esfuerzo arquitectónico en esta clase de compromiso
es elaborar de manera efectiva una solución de referencia
que aborde los requisitos, problemas, impulsores y
limitaciones identificados.
Implementación de Arquitectónico Una vez que se ha definido un modelo de solución

Cambio Gobernanza de arquitectónica, proporciona una base para el diseño y la
Cambio implementación.
Implementación
Para garantizar que los objetivos y el valor de la arquitectura
definida se realicen adecuadamente, es necesario continuar
con la Gobernanza de la arquitectura del proceso de
implementación para respaldar la revisión del diseño, el
refinamiento de la arquitectura y la escalada de problemas.
Las diferentes clases de compromiso con la arquitectura en los diferentes niveles de la empresa requerirán un enfoque en
áreas específicas, como se muestra a continuación.
Tipo de participación Ciclos de iteración de enfoque Alcance Enfoque

Negocios de apoyo Capacidad de arquitectura Consideración amplia y superficial dada al
Estrategia Paisaje Arquitectónico para abordar una pregunta
Arquitectura
estratégica específica y definir términos para
Desarrollo
esfuerzos de arquitectura más detallados para
(Línea de base primero)
abordar la realización de la estrategia.
Portafolio Arquitectónico Capacidad de arquitectura Concéntrese en la evaluación física de las

Gestión de la aplicaciones de referencia y la infraestructura
Arquitectura
Paisaje tecnológica para identificar oportunidades de
Desarrollo
mejora, generalmente dentro de las limitaciones
de mantener el negocio como de costumbre.
Portafolio Arquitectónico Planificación de transición Concéntrese en proyectos,

Administración de dependencias de proyectos e impactos en el paisaje
Arquitectura
Proyectos para alinear la secuencia de proyectos de una manera
Gobernancia
que esté optimizada desde el punto de vista arquitectónico.

redistribución
Aplicación de iteración al ADM Clases de Compromiso de Arquitectura
Tipo de participación Ciclos de iteración de enfoque Alcance Enfoque

Definición arquitectónica de Capacidad de arquitectura Centrarse en elaborar una visión a través de la
cambio fundamental definición de la línea de base e identificar qué debe
Arquitectura
Iniciativas cambiar para hacer la transición de la línea de base
Desarrollo
al objetivo.
Planificación de transición
Definición arquitectónica de Arquitectura Concéntrese en elaborar el objetivo para
cambio acotado Desarrollo cumplir con una visión, un alcance o un conjunto
Iniciativas (Objetivo primero) de restricciones previamente definido y acordado.
Utilice el objetivo como base para el análisis para
Planificación de transición
evitar la perpetuación de arquitecturas subóptimas
de referencia.
Arquitectónico Arquitectura Utilice la visión de la arquitectura, las
Gobernanza del Cambio Gobernancia restricciones, los principios, los requisitos, la
Implementación definición de la arquitectura objetivo y la hoja de
ruta de transición para garantizar que los
proyectos obtengan el beneficio previsto, estén
alineados entre sí y con las necesidades
comerciales más amplias.
2.4 Enfoques para el desarrollo de la arquitectura

Se pueden adoptar dos enfoques dentro del ADM para el desarrollo de arquitecturas:
ÿ Línea de base primero: en este estilo, se utiliza una evaluación del panorama de línea de base para identificar
áreas problemáticas y oportunidades de mejora
Este proceso es más adecuado cuando la línea de base es compleja, no se entiende claramente o no se acuerda. Este
enfoque es común donde las unidades organizacionales han tenido un alto grado de autonomía.
ÿ Objetivo primero: en este estilo, la solución objetivo se elabora en detalle y luego se vuelve a mapear
a la línea de base, con el fin de identificar la actividad de cambio
Este proceso es adecuado cuando se acuerda un estado objetivo a un alto nivel y cuando la empresa desea hacer una
transición efectiva al modelo objetivo.
Por lo general, si la línea de base se entiende ampliamente, se obtendrá un valor más alto centrándose primero en el objetivo y
luego en la línea de base en la medida necesaria para identificar los cambios.
En términos prácticos, un equipo de arquitectura siempre dará una consideración informal a la línea de base al analizar el objetivo
(y viceversa). En situaciones en las que se espera que las partes interesadas consideren la línea de base y el objetivo en paralelo,
se recomienda que el equipo de arquitectura centre la prioridad en un estado para mantener el enfoque y la consistencia de la
ejecución.

Consideraciones de iteración Aplicación de iteración al ADM
2.5 Consideraciones de iteración

Algunos ciclos de iteración se pueden ejecutar una vez, mientras que otros tienen un número mínimo natural de ciclos.
Para algunos ciclos de iteración, cada iteración sigue el mismo proceso; donde hay más de una iteración dentro de un
ciclo, el proceso difiere ligeramente para cada una de las iteraciones.
Al considerar el uso de ciclos de iteración, también es necesario considerar dónde colocar los puntos de control
apropiados dentro del proceso. Si el nivel esperado de participación de las partes interesadas es alto, puede ser sensato
llevar a cabo puntos de control muy frecuentes pero informales para garantizar que el proceso avanza en la dirección
prevista. Si las partes interesadas están menos involucradas, entonces los puntos de control pueden ser menos
frecuentes pero más formales. Los puntos de control al final de cada ciclo de iteración, o al final de varios ciclos de
iteración, son comunes.
2.5.1 Iteración entre ciclos de ADM Cada iteración
completa un ciclo de ADM en un único nivel de descripción de la arquitectura. Este enfoque del ADM utiliza la Fase F
(Planificación de la migración) para iniciar nuevos proyectos de desarrollo de arquitectura más detallados. Este enfoque
se ilustra en la Figura 2-3. Este tipo de iteración destaca la necesidad de una arquitectura de nivel superior para guiar y
restringir una arquitectura más detallada. También destaca que el paisaje arquitectónico completo se desarrolla mediante
múltiples iteraciones de ADM.

redistribución
Aplicación de iteración al ADM Consideraciones de iteración
Arquitectura Estratégica
Preliminar
UNA.
Visión de la
Arquitectura de segmento h
arquitectura
B.
Gestión de
Negocio
cambios de
Arquitectura
arquitectura
Preliminar
C.
GRAMO.
Requisitos Información
Implementación
administración Sistemas
Gobernancia
arquitecturas
UNA.
F. D.
Arquitectura
Visión
Planificación Tecnología
h de la migración Arquitectura
B. MI.
Gestión de
Negocio Oportunidades y
cambios de
Arquitectura
arquitectura
Soluciones
C.
GRAMO.
Requisitos Información
Implementación
administración Sistemas
Gobernancia
arquitecturas
F. D.
de la migración Arquitectura
MI.
Oportunidades y
Soluciones
Arquitectura de capacidad
Preliminar
UNA.
Visión de la
arquitectura
h
B.
Gestión de
Negocio
cambios de
Arquitectura
arquitectura
C.
GRAMO.
Requisitos Arquitecturas
Gobernanza de la
administración de Sistemas
implementación
de Información
F. D.
de la migración Arquitectura
MI.
Oportunidades y
Soluciones
© El Grupo Abierto
Figura 2-3 Ejemplo de jerarquía de procesos ADM

2.5.2 Iteración dentro de un ciclo ADM

Cada ciclo de iteración atraviesa varias fases de TOGAF ADM. Las siguientes tablas muestran a alto nivel qué fases
deben completarse para cada ciclo de iteración, mostrando la actividad central (es decir, el enfoque principal de la
iteración), la actividad que es ligera (es decir, el enfoque secundario de la iteración), y actividad que puede llevarse a
cabo informalmente (es decir, alguna actividad puede llevarse a cabo, pero no se menciona explícitamente en el ADM).
Arquitectura Transición Arquitectura

Desarrollo Planificación Gobernancia
Fase TOGAF Iteración 1 Iteración 2 Iteración n Iteración 1 Iteración n Iteración 1 iteración n
Preliminar Informal Informal Informal Luz

Visión de la arquitectura Informal Informal Informal Informal Informal Luz
Negocio Base Centro Luz Centro Informal Informal Luz

Arquitectura Informal Centro Centro Informal Informal
Objetivo Luz
Base Centro Luz Centro Informal Informal Luz
Solicitud
Objetivo Luz
Datos Base Centro Luz Centro Informal Informal Luz

Objetivo Luz
Base Centro Luz Centro Informal Informal Luz
Tecnología
Objetivo Luz
Oportunidades y Soluciones Luz Luz Luz Centro Centro Informal Informal
Planificación de la migración Luz Luz Luz Centro Centro Informal Informal
Gobernanza de la implementación Informal Informal Centro Centro
Gestión del cambio Informal Informal Informal Informal Informal Centro Centro
Núcleo: actividad de enfoque principal para la iteración
Luz: actividad de enfoque secundario para la iteración.

© El Grupo Abierto
Informal: actividad potencial para la iteración, no mencionada formalmente en el método
Figura 2-4 Actividad por iteración para la primera definición de arquitectura de línea base

redistribución
Arquitectura Transición Arquitectura

Desarrollo Planificación Gobernancia
Fase TOGAF Iteración 1 Iteración 2 Iteración n Iteración 1 Iteración n Iteración 1 iteración n
Preliminar Informal Informal Informal Luz

Visión de la arquitectura Informal Informal Informal Informal Informal Luz
Negocio Base Informal Centro Centro Informal Informal Luz

Arquitectura Centro Centro Informal Informal
Objetivo Luz Luz
Base Informal Centro Centro Informal Informal Luz
Solicitud
Objetivo Luz Luz
Datos Base Informal Centro Centro Informal Informal Luz

Objetivo Luz Luz
Base Informal Centro Centro Informal Informal Luz
Tecnología
Objetivo Luz Luz
Oportunidades y Soluciones Luz Luz Luz Centro Centro Informal Informal
Planificación de la migración Luz Luz Luz Centro Centro Informal Informal
Gobernanza de la implementación Informal Informal Centro Centro
Gestión del cambio Informal Informal Informal Informal Informal Centro Centro
Núcleo: actividad de enfoque principal para la iteración
Luz: actividad de enfoque secundario para la iteración.

© El Grupo Abierto
Informal: actividad potencial para la iteración, no mencionada formalmente en el método
Figura 2-5 Actividad por iteración para la definición de arquitectura Target First
Los ciclos de iteración sugeridos asignados a las fases TOGAF se describen en la siguiente tabla:
Ciclo de iteración Iteración Propósito Descripción

Arquitectura Iteración 1 Definir la Arquitectura Esta iteración comprende un paso a
Desarrollo de Línea Base. través de las fases de arquitectura
(Línea de base primero) empresarial, arquitectura de sistemas
de información y arquitectura
tecnológica del ADM, centrándose en
la definición de la línea de base.
También se consideran
oportunidades, soluciones y planes
de migración para desviar la
atención del cambio y probar la
viabilidad.

Ciclo de iteración Iteración Objetivo Descripción

Iteración 2 Definir el objetivo Esta iteración comprende un paso a
Arquitectura y través de las fases de arquitectura
brechas. empresarial, arquitectura de sistemas
de información y arquitectura tecnológica
del ADM, centrándose en la definición del
objetivo y analizando las brechas con
respecto a la línea de base.
También se consideran oportunidades,

soluciones y planes de migración
para probar la viabilidad.
Iteración n Refine la línea de base, el Las iteraciones posteriores del
objetivo y las brechas. desarrollo de la arquitectura intentan
corregir y refinar el objetivo para lograr
un resultado que sea beneficioso,
factible y viable.
Arquitectura Iteración 1 Defina la arquitectura Esta iteración comprende un paso a
Desarrollo de destino. través de las fases de arquitectura
(Objetivo primero) empresarial, arquitectura de sistemas
del ADM, centrándose en la definición del
objetivo.

para desviar la atención del cambio
y probar la viabilidad.
Iteración 2 Definir la línea de base Esta iteración comprende un paso a

Arquitectura y través de las fases de arquitectura
brechas. empresarial, arquitectura de sistemas
del ADM, centrándose en la definición de
la línea de base y analizando las brechas
con respecto al objetivo.

para probar la viabilidad.
Iteración n Refine la línea de base, el Las iteraciones posteriores del
objetivo y las brechas. desarrollo de la arquitectura intentan
corregir y refinar el objetivo para lograr
un resultado que sea beneficioso,
factible y viable.

redistribución
Ciclo de iteración Iteración Propósito Descripción La

Planificación de transición Iteración 1 Definir y acordar un iteración inicial de la Planificación de la
conjunto de oportunidades Transición busca obtener la aceptación de
de mejora, alineado con una cartera de oportunidades de solución
una Arquitectura de en la fase de Oportunidades y Soluciones
Transición provisional. de ADM.
Esta iteración también ofrece un plan

de migración provisional.
Iteración n Acordar la arquitectura de Las iteraciones subsiguientes de
transición, refinando las la Planificación de Transición buscan
oportunidades de mejora refinar el Plan de Migración,
identificadas para que retroalimentando los problemas en la
encajen. fase de Oportunidades y Soluciones para
su refinamiento.
Arquitectura Iteración 1 Movilizar la Gobernanza de La iteración inicial de
Gobernancia la Arquitectura y los procesos Gobernanza de la arquitectura
de gestión del cambio. establece un proceso para la
gobernanza del cambio y también pone en
marcha las personas, los procesos y la
tecnología apropiados para respaldar el
acceso administrado y el cambio de la
arquitectura definida.
Iteración y Realización de Las iteraciones posteriores del ciclo

Arquitectura de Gobernanza de la arquitectura se
Gobernanza y control centran en revisiones periódicas de las
de cambios. iniciativas de cambio para resolver
problemas y garantizar el cumplimiento.
Los resultados de una solicitud de
cambio pueden desencadenar la revisión
de otra fase; por ejemplo, retroalimentando
un nuevo requisito a la Fase Preliminar
para mejorar la Capacidad de la
Arquitectura, o un nuevo requisito para la
arquitectura en las fases de Desarrollo de
la Arquitectura.
2.6 Conclusiones
Todas estas técnicas son aplicaciones válidas del ADM. Combinados, representan cómo se puede utilizar el ADM en la práctica. El
ADM siempre debe usarse en un proceso iterativo.
La forma en que se ejerce este proceso depende de factores organizacionales. Los factores particulares a considerar incluyen:
ÿ La formalidad y la naturaleza de los puntos de control de procesos establecidos dentro de la organización.
¿La organización exige que ciertos grupos de actividades se lleven a cabo entre

Conclusiones Aplicación de iteración al ADM
puntos de control? ¿La organización exige que se finalicen ciertas actividades antes de que se puedan llevar a cabo
otras actividades?
ÿ El nivel de participación de las partes interesadas que se espera dentro del proceso
¿Esperan las partes interesadas participar de cerca en el desarrollo de una solución o esperan ver un conjunto
completo de entregables para su revisión y aprobación?
ÿ El número de equipos involucrados y las relaciones entre los diferentes equipos
¿La arquitectura completa está siendo desarrollada por un equipo específico, o existe una jerarquía de equipos con
relaciones de gobierno entre ellos?
ÿ La madurez del área de solución y la cantidad esperada de reelaboración y refinamiento

necesaria para llegar a una solución aceptable.
¿Se puede lograr la solución en un solo paso, o requiere un extenso trabajo de prueba de concepto y creación de
prototipos para desarrollar un resultado adecuado?
ÿ Actitud ante el riesgo
¿La cultura organizacional reacciona negativamente a la circulación de productos de trabajo parcialmente completos?
¿La cultura organizacional requiere que las soluciones se prueben en un entorno de prueba antes de que puedan
implementarse para la aplicación principal?
ÿ La clase de compromiso
¿Cuál es el contexto para el desarrollo de la Arquitectura Empresarial?
dieciséis
The Open Group Standard (2022)
redistribución
Capítulo 3: Aplicación de ADM en toda la arquitectura

Paisaje
3.1 Resumen
En una empresa típica, muchas arquitecturas se describirán en el Paisaje Arquitectónico en cualquier momento. Algunas
arquitecturas abordarán necesidades muy específicas; otros serán más generales.
Algunos abordarán los detalles; algunos proporcionarán un panorama general. Para abordar esta complejidad, el
estándar TOGAF utiliza los conceptos de niveles y Enterprise Continuum para proporcionar un marco conceptual para
organizar el paisaje arquitectónico. Estos conceptos están estrechamente relacionados con la organización del contenido
real en el Repositorio de Arquitectura y cualquier partición de arquitectura discutida en el Estándar TOGAF: Contenido
de Arquitectura.
3.2 Paisaje Arquitectónico

Los niveles proporcionan un marco para dividir el Paisaje Arquitectónico en tres niveles de granularidad:
1. La Arquitectura Estratégica proporciona un marco organizativo para la actividad operativa y de cambio y permite
establecer la dirección a nivel ejecutivo.
2. La arquitectura de segmento proporciona un marco organizativo para la actividad operativa y de cambio y

permite establecer la dirección y el desarrollo de hojas de ruta de arquitectura efectivas a nivel de programa o
cartera.
3. La arquitectura de capacidad proporciona un marco organizativo para la actividad de cambio y el desarrollo de

hojas de ruta de arquitectura efectivas que realizan incrementos de capacidad.
La Figura 3-1 muestra un resumen del modelo de clasificación para Paisajes Arquitectónicos.

Arquitectura Paisaje Aplicación del ADM en el paisaje arquitectónico
© El Grupo Abierto
Amplitud
Tiempo
Arquitectura Estratégica Empresarial
Nivel
Segmento Segmento
Arquitectura Arquitectura
Capacidad Capacidad Capacidad

Arquitectura Arquitectura Arquitectura
Figura 3-1 Resumen del Modelo de Clasificación para Paisajes Arquitectónicos
El continuo de arquitectura proporciona un método para dividir cada nivel del paisaje arquitectónico (consulte el estándar
TOGAF: contenido de arquitectura) por abstracción. Ofrece una forma coherente de definir y comprender las reglas
genéricas, las representaciones y las relaciones en una arquitectura, incluidas las relaciones de trazabilidad y derivación.
El continuo de la arquitectura muestra las relaciones desde los elementos básicos hasta la arquitectura específica de la
organización, como se muestra en la figura 3-2.
El continuo de la arquitectura es una herramienta útil para descubrir puntos en común y eliminar la redundancia
innecesaria.
Continuidad de la arquitectura © El Grupo Abierto
Generalización para reutilización futura

Genérico Específico
arquitecturas arquitecturas
Adaptación para el uso
Figura 3-2 Resumen de Arquitectura Continuum

redistribución
Aplicación del ADM en el paisaje arquitectónico Arquitectura Paisaje
Los niveles y el continuo de la arquitectura proporcionan un mecanismo integral para describir y clasificar el paisaje
arquitectónico. Estos conceptos se pueden utilizar para organizar el panorama arquitectónico en un conjunto de arquitecturas
relacionadas con: ÿ Complejidad manejable para cada solución o arquitectura individual ÿ Agrupaciones definidas ÿ Jerarquías
y estructuras de navegación definidas
ÿ Procesos, roles y responsabilidades apropiados adjuntos a cada grupo
No existe un modelo organizativo definitivo para la arquitectura, ya que cada empresa debe adoptar un modelo que refleje su
propio modelo operativo.
3.3 Desarrollando Arquitecturas en Diferentes Niveles

Las secciones anteriores han identificado que se requieren diferentes tipos de arquitectura para abordar las diferentes
necesidades de las partes interesadas en diferentes niveles de la organización. Por lo general, cada arquitectura no existe
de forma aislada y, por lo tanto, debe ubicarse dentro de una jerarquía de gobierno. Las arquitecturas amplias y resumidas
marcan la dirección de las arquitecturas estrechas y detalladas.
Se pueden emplear varias técnicas para usar el ADM como un proceso que admite tales jerarquías de arquitecturas.
Esencialmente hay dos estrategias que se pueden aplicar:
1. Las arquitecturas en diferentes niveles se pueden desarrollar a través de iteraciones dentro de un solo ciclo del proceso
ADM
2. Las arquitecturas en diferentes niveles se pueden desarrollar a través de una jerarquía de procesos ADM,
ejecutado concurrentemente
En los extremos de la escala, cualquiera de estas dos opciones puede adoptarse por completo. En la práctica, es probable
que un arquitecto necesite combinar elementos de cada uno para cumplir con los requisitos exactos de su solicitud de trabajo
de arquitectura. Cada uno de estos enfoques se describe en el Capítulo 2.
3.4 Organizar el paisaje arquitectónico para comprender el estado de la empresa Las siguientes características suelen
utilizarse para organizar el paisaje arquitectónico:
ÿ Amplitud: el área de amplitud (materia) es generalmente el área principal de organización.

carac terística para describir un Paisaje Arquitectónico
Las arquitecturas se descomponen funcionalmente en una jerarquía de áreas temáticas o segmentos específicos.
ÿ Profundidad: con áreas temáticas más amplias, se necesitan menos detalles para garantizar que la arquitectura tenga
un tamaño y una complejidad manejables
Las áreas temáticas más específicas generalmente permitirán (y requerirán) arquitecturas más detalladas.
ÿ Tiempo: para una amplitud y profundidad específicas, una empresa puede crear una Arquitectura de referencia y un
conjunto de Arquitecturas objetivo que se extienden hacia el futuro.
Las arquitecturas más amplias y menos detalladas generalmente serán válidas por períodos de tiempo más largos

estado de la empresa Aplicación del ADM en el paisaje arquitectónico
y puede proporcionar una visión para la empresa que se extiende más hacia el futuro.
ÿ Actualidad: finalmente, cada vista de arquitectura avanzará a través de un ciclo de desarrollo en el que
aumenta la precisión hasta que finalmente se aprueba
Después de la aprobación, una arquitectura comenzará a disminuir en precisión si no se mantiene activamente.

En algunos casos, la actualidad se puede utilizar como un factor de organización para las arquitecturas históricas.
Usando los criterios arriba de , Las arquitecturas se pueden agrupar en Estratégica, Segmento y Capacidad.
los niveles de Arquitectura, como se describe en la Figura 3-1.
20 El estándar de grupo abierto (2022)

© 2005-2022 El Grupo Abierto, Todos los derechos reservados
Capítulo 4: Arquitectura de particiones
4.1 Resumen
Las particiones se utilizan para simplificar el desarrollo y la gestión de Enterprise Architecture.
Las particiones se encuentran en la base de la gobernanza de la arquitectura y son distintas de los niveles y los conceptos
organizadores del continuo de la arquitectura (consulte el estándar TOGAF: contenido de la arquitectura).
Las arquitecturas se dividen porque:
ÿ Las arquitecturas de las unidades organizativas entran en conflicto entre sí
ÿ Diferentes equipos necesitan trabajar en diferentes elementos de la arquitectura al mismo tiempo y las particiones
permiten que grupos específicos de arquitectos posean y desarrollen elementos específicos de la arquitectura.
ÿ La reutilización eficaz de la arquitectura requiere segmentos de arquitectura modular que se puedan tomar y
incorporado en arquitecturas y soluciones más amplias
No es práctico presentar un modelo de partición definitivo para la arquitectura. Cada empresa necesita adoptar un modelo
de partición que refleje su propio modelo operativo.
Este capítulo analiza los criterios de clasificación que generalmente se aplican a las arquitecturas y cómo se pueden
aprovechar para dividir la empresa en un conjunto de arquitecturas con una complejidad manejable y una gobernanza
eficaz.
4.2 Aplicación de la clasificación para crear arquitecturas con particiones

Por las razones esbozadas en la sección anterior, es valioso dividir y organizar el
Introduzca Continuum en un conjunto de soluciones y arquitecturas relacionadas con:
ÿ Complejidad manejable para cada arquitectura o solución individual
ÿ Agrupaciones definidas
ÿ Jerarquías y estructuras de navegación definidas
ÿ Procesos, roles y responsabilidades apropiados adjuntos a cada grupo
La siguiente tabla muestra cómo se pueden usar los criterios de clasificación adecuados para respaldar la partición de
soluciones:

Aplicar clasificación para crear arquitecturas con particiones Partición de arquitectura
Característica Uso para respaldar la partición de soluciones

Materia temática (amplitud) Las soluciones se organizan naturalmente en grupos para respaldar la gestión
y el control operativos. Los ejemplos de particiones de solución según el
tema incluirían aplicaciones, departamentos, divisiones, productos, servicios,
centros de servicio, sitios, etc.
La descomposición de la solución por tema suele ser la técnica

fundamental para estructurar tanto las soluciones como las arquitecturas que
las representan.
Tiempo Los ciclos de vida de las soluciones generalmente se organizan en torno a una línea
de tiempo, lo que permite administrar el impacto del desarrollo, la introducción, el
funcionamiento y el retiro de la solución frente a otras actividades comerciales que
ocurren en períodos de tiempo similares.
Madurez/Volatilidad La madurez y la volatilidad de una solución generalmente afectarán la velocidad
de ejecución requerida para el ciclo de vida de la solución.
Además, la volatilidad y el vencimiento determinarán las prioridades de inversión.

Las soluciones existentes en entornos altamente volátiles pueden adaptarse
mejor a técnicas de desarrollo rápidas y ágiles.
La siguiente tabla muestra cómo se puede usar cada criterio de clasificación para admitir la partición de arquitecturas:
Característica Uso para respaldar la partición de la arquitectura El

Profundidad nivel de detalle dentro de una arquitectura tiene una fuerte correlación con los grupos
de partes interesadas que estarán interesados en la arquitectura.
Por lo general, las arquitecturas menos detalladas serán de interés para las partes
interesadas ejecutivas. A medida que las arquitecturas aumentan en detalle, también
aumentará su relevancia para la implementación y el personal operativo.
En términos prácticos, la disciplina de la arquitectura se utiliza para respaldar una serie de diferentes tipos de arquitectura
que se utilizan para diferentes objetivos. Los criterios de clasificación descritos anteriormente se pueden utilizar de diferentes
maneras para apoyar el logro de cada objetivo.
Las siguientes características generalmente no se utilizan para dividir un Paisaje Arquitectónico:
ÿ Las arquitecturas utilizadas para describir el Paisaje Arquitectónico generalmente no son abstractas
ÿ La volatilidad de la solución generalmente impide que se definan arquitecturas que están en un futuro lejano; la
volatilidad también reduce la precisión de las arquitecturas históricas a lo largo del tiempo, ya que la organización
cambia y se adapta a las nuevas circunstancias
Usando el criterio ia anterior , Las arquitecturas se pueden agrupar en particiones.

redistribución
Partición de arquitectura Aplicar clasificación para crear arquitecturas con particiones
4.2.1 Actividades dentro de la Fase Preliminar

El objetivo clave de la Fase Preliminar es establecer la Capacidad de Arquitectura para la empresa. En términos prácticos,
esta actividad requerirá el establecimiento de una serie de particiones arquitectónicas, proporcionando límites definidos,
gobernanza y propiedad.
En términos generales, cada equipo que lleve a cabo una actividad de arquitectura dentro de la empresa será propietario
de una o más particiones de arquitectura y ejecutará el ADM para definir, gobernar y realizar sus arquitecturas.
Si se espera que más de un equipo trabaje en una sola arquitectura, esto puede volverse problemático, ya que las
responsabilidades precisas de cada equipo son difíciles de establecer. Por esta razón, es preferible aplicar particiones a la
arquitectura hasta que cada arquitectura tenga un equipo propietario.
Finalmente, vale la pena considerar la distinción entre las capacidades permanentes de la empresa y los equipos
temporales movilizados para apoyar una iniciativa de cambio particular. Aunque el mandato de los equipos permanentes
dentro de la empresa se puede definir con precisión, es más difícil anticipar y especificar las responsabilidades de los
equipos de arquitectura temporales (posiblemente desconocidos). En los casos de estos equipos temporales, cada equipo
debe estar bajo la dirección de un equipo de arquitectura permanente y debe haber un proceso dentro del ciclo ADM de
estos equipos para establecer una partición de arquitectura adecuada.
Los pasos dentro de la Fase Preliminar para admitir la partición de la arquitectura son los siguientes:
ÿ Determinar la estructura organizativa de la arquitectura dentro de la empresa: la

Se deben identificar varios equipos permanentes que crearán la arquitectura.
Para cada uno de estos equipos, se deben establecer límites apropiados, que incluyen:
— Órganos de gobierno aplicables al equipo
— Membresía del equipo
— Líneas de reporte del equipo
ÿ Determinar las responsabilidades de cada equipo de arquitectura permanente: para cada equipo de arquitectura,
se deben identificar las responsabilidades. Este paso aplica la lógica de partición a la arquitectura empresarial para,
en primer lugar, identificar el alcance de cada equipo y, en segundo lugar, dividir la arquitectura bajo el mandato de
un solo equipo Una vez completado, este paso debería haber dividido todo el alcance de la empresa y debería
haber asignado la responsabilidad de cada arquitectura dividida a un solo equipo. La partición debe crear una
definición de cada arquitectura que incluya:
— Áreas temáticas que se cubren
— Niv el de detalle con el que trabajará el equipo
— Periodos de tiempo a cubrir
- Partes interesadas
ÿ Determinar las relaciones entre arquitecturas: una vez que se ha creado un conjunto de arquitecturas
particionadas, se deben desarrollar las relaciones entre arquitecturas.
Este paso permite formalizar las relaciones de gobierno y también muestra dónde se espera que los artefactos de
una arquitectura se reutilicen dentro de otras arquitecturas.

Aplicar clasificación para crear arquitecturas con particiones Partición de arquitectura
Las áreas de consideración incluyen:
— ¿Dónde se superponen, encajan o profundizan las diferentes arquitecturas?
— ¿Cuáles son los requisitos de cumplimiento entre arquitecturas?
Una vez completada la Fase Preliminar, se deben entender los equipos que realizan la arquitectura. Cada equipo debe
tener un alcance definido y deben entenderse las relaciones entre los equipos y la arquitectura. La asignación de equipos
al alcance de la arquitectura se ilustra en la Figura 4-1.
Equipos que realizan arquitectura
Tema
Asunto Capacidad corporativa de EA
Periodo de tiempo
Equipo
Capacidad
Línea de segmento
de negocio EA EA Grupo de proyecto
Empresa Línea de negocio
FunciónEA
Función
Equipo
detalle
Nivel
de
Equipo
Grupo de proyecto
Segmento Segmento
Equipo de cartera
Grupo de proyecto
Grupo de proyecto
Capacidad Capacidad Capacidad
Grupo de proyecto
© El Grupo Abierto
Figura 4-1 Asignación de equipos al alcance de la arquitectura
4.3 Integración
La creación de arquitecturas divididas corre el riesgo de producir una colección fragmentada e inconexa de arquitecturas
que no se pueden integrar para formar un panorama general (consulte el estándar TOGAF: método de desarrollo de
arquitectura).
Para empresas grandes y complejas, las arquitecturas federadas (arquitecturas desarrolladas, mantenidas y administradas
de forma independiente que luego se integran dentro de un marco de integración) son típicas. Las arquitecturas federadas
generalmente se usan en gobiernos y conglomerados, donde las unidades organizativas separadas necesitan arquitecturas
separadas. Dicho marco especifica los principios de interoperabilidad, migración y conformidad. Esto permite que unidades
comerciales específicas tengan arquitecturas desarrolladas y gobernadas como proyectos de arquitectura independientes.
Se pueden encontrar más detalles y orientación sobre la especificación de los requisitos de interoperabilidad para diferentes
soluciones en el estándar TOGAF: técnicas ADM.
Para mitigar este riesgo, se deben definir estándares para la integración de contenido y la gobernanza de la arquitectura
debe abordar la integración de contenido como una condición de arquitectura.

redistribución
Partición de arquitectura Integración
cumplimiento. Marcos de contenido, como el marco de contenido TOGAF (consulte el TOGAF

Estándar — Contenido de arquitectura) se puede usar para especificar elementos y bloques de construcción estándar
que son objeto de estándares de integración de contenido.
Por ejemplo, se puede acordar un catálogo estándar de procesos comerciales para una empresa.
Las arquitecturas posteriores pueden facilitar la integración utilizando la misma lista de procesos y haciendo referencias
cruzadas de otros aspectos de la arquitectura a esos procesos estándar.
La integración se puede abordar desde una serie de dimensiones:
ÿ La integración entre los dominios de la arquitectura proporciona una vista entre dominios del estado de un
segmento de la empresa para un punto en el tiempo
ÿ La integración en todo el ámbito organizativo de la empresa proporciona una vista de segmento cruzado
de la empresa
ÿ La visión de la arquitectura proporciona un resumen integrado de las definiciones de la arquitectura, que

proporcionar un resumen integrado de las Arquitecturas de Transición
La figura 4-2 muestra cómo se puede agregar contenido arquitectónico utilizando una variedad de técnicas.
© El Grupo Abierto
Organizativo
Alcance
Arquitectura
Dominios
Segmento 1 Visión
Segmento 1 Visión
Visión empresarial
Segmento 1 Visión
Segmento 1 Visión Segmento

Segmento Segmento Segmento
Negocio Datos Aplicaciones Tecnología
Segmento Segmento Segmento Segmento

Profundidad de detalleEmpresa Empresa
Negocio Empresa Empresade transición
Datos Arquitecturas
Aplicaciones Tecnología
Segmento Segmento Arquitecturas
Segmento de transición
Segmento
Arquitecturas de transición
Segmento Segmento Arquitecturas
Segmento de transición
Segmento
Negocio Datos Arquitecturas de transición
Aplicaciones Tecnología
Figura 4-2 Agregación de contenido de arquitectura
Estándar TOGAF® — Aplicación del ADM 25

© 2005-2022 The Open Group, Todos los derechos reservados
Partición de arquitectura

redistribución
Índice
iteración de ADM .................................................. .................................................... 3 aplicando

el ADM .............................................. ..........................................17 Capacidad de la
arquitectura.... .................................................... ..............................5 desarrollo de la
arquitectura .................. .................................................... .........5, 9 compromiso con la
arquitectura ............................... ............................................5 Gobernanza de la
arquitectura ... .................................................... ..........................5 Arquitectura
Paisaje ............................... .................................................... ..........17 particionamiento de la
arquitectura .................................. ..........................................21 estilos de
arquitectura.... .................................................... .....................................1 línea de base
primero......... .................................................... ....................................... 9 de
ancho ....... .................................................... ..........................................................19 Arquitectura
de capacidad................................................. ..................................17
clasificación .............. .................................................... ..................................21
profundidad ............... .................................................... ............................................19
iteración .... .................................................... .................................................... .10 ciclos de
iteración ............................................... .................................................... 4 iteración del
ADM ............................................... ..........................................3
actualidad ..... .................................................... .......................................... ........20 Arquitectura
de segmento ....................................... ............................................17 Arquitectura
Estratégica... .................................................... ...............................17 objetivo
primero................ .................................................... ..........................................9
tiempo .......... .................................................... .................................................... .19 Planificación
de la transición ........................................... .............................................5

Índice

redistribución

C220 Part3e

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

C220 Part3e

Uploaded by

Copyright:

Available Formats

Machine Translated by Google

El estándar de grupo abierto

Estándar TOGAF® —Aplicación del ADM

© 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® — Aplicación del ADM

Publicado por The Open Group, 2005-2022.

yo The Open Group Standard (2022)

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

Capitulo 2 Aplicación de iteración al ADM.................................................... .3

Capítulo 3 Aplicación de ADM en toda la arquitectura

Capítulo 4 Particiones de la arquitectura .................................................... ......... 21

Índice .................................................. ............................................. 27

2-1 Ciclos de iteración................................................. .................................... 4

Estándar TOGAF® — Aplicación del ADM iii

3-2 Resumen de Arquitectura Continuum ............................................... ... 18

IV El estándar de grupo abierto (2022)

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

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

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

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

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

Estándar TOGAF® : aplicación de ADM v

Este es el estándar TOGAF: aplicación del ADM.

vi The Open Group Standard (2022)

Estándar TOGAF® : aplicación de ADM viii

viii The Open Group Standard (2022)

ÿ La aplicación de la iteración al ADM (consulte el Capítulo 2) analiza el concepto de iteración y muestra

1.1 Uso de TOGAF Framework con diferentes estilos de arquitectura

Estándar TOGAF® : aplicación de ADM 1

Uso del marco TOGAF con diferentes estilos de arquitectura Introducción

describir la arquitectura y enfocar al arquitecto en algunas partes interesadas o partes interesadas

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

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

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

2 The Open Group Standard (2022)

Capítulo 2: Aplicación de la iteración al ADM

Iteración para desarrollar un Paisaje Arquitectónico integral:

ÿ Un proyecto puede desencadenar el inicio de otro proyecto

Iteración dentro de un ciclo ADM (iteración de desarrollo de arquitectura):

ÿ Los proyectos pueden operar múltiples fases de ADM al mismo tiempo

Estándar TOGAF® : aplicación de ADM 3

Visión general Aplicación de iteración al ADM

la arquitectura no existe para proporcionar contexto y restricciones.

Iteración para administrar la capacidad de la arquitectura (iteración de la capacidad de la arquitectura):

2.2 Ciclos de iteración Los

Figura 2-1 Ciclos de iteración

4 The Open Group Standard (2022)

Aplicación de iteración al ADM Ciclos de iteración

ÿ Las iteraciones de la capacidad de la arquitectura admiten la creación1 y la evolución de la

ÿ Las iteraciones de Gobernanza de arquitectura respaldan la gobernanza de la actividad de cambio en progreso

2.3 Clases de Compromiso con la Arquitectura

Por lo general, hay tres áreas de compromiso para los arquitectos:

Estándar TOGAF® : aplicación de ADM 5

Clases de Compromiso de Arquitectura Aplicación de iteración al ADM

Identificación del cambio requerido Definición de cambio

El negocio El negocio La estrategia comercial

Actividades de arquitectura que apoyen la identificación de una necesidad de cambio.

Actividades de arquitectura que gobiernan la implementación del cambio.

Figura 2-2 Clases de Compromiso con la Arquitectura Empresarial

La creación de nuevas estrategias comerciales puede ser