C220 Part2e

Machine Translated by Google
Copia de evaluación
El estándar de grupo abierto
Estándar TOGAF® —Técnicas 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® — Técnicas 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
Capitulo 2 Principios de la arquitectura .................................................. .......... 3

2.1 Introducción................................................. .................................... 3
2.2 Características de los Principios de la Arquitectura ....................................... 4
2.3 Componentes de los Principios de Arquitectura ....................................... 4
2.4 Desarrollo de los principios de la arquitectura ............................................... .. 5
2.4.1 Cualidades de los principios .............................................. ................... 5
2.5 Aplicación de los principios de la arquitectura ............................................... ...... 6
2.6 Ejemplo de conjunto de principios de arquitectura ................................ 7
2.6.1 Principios empresariales ............................................... ...................... 7
2.6.2 Principios de datos ............................................... ............................. 11
2.6.3 Principios de aplicación ............................................... ................... dieciséis
2.6.4 Principios de la tecnología ................................................ .................... 17
Capítulo 3 Gestión de partes interesadas .............................................. ...... 21

3.1 Introducción................................................. .................................... 21
3.2 Enfoque de la gestión de las partes interesadas ................................ 21
3.3 Pasos en el Proceso de Gestión de Partes Interesadas .......................... 22
3.3.1 Identificar a los interesados .................................................. ................... 22
3.3.2 Clasificar las posiciones de las partes interesadas ............................................... ..... 24
3.3.3 Determinar el enfoque de gestión de las partes interesadas .......... 24
3.3.4 Compromiso a la medida Entregables ............................................... ... 25
3.4 Modelo de mapa de partes interesadas.................................... ............. 25
Capítulo 4 Patrones de arquitectura ................................................ ............... 39

4.1 Introducción................................................. .................................... 39
4.1.1 Fondo ................................................. .......................... 39
4.1.2 Contenido de un Patrón n ............................................. ....................... 40
4.1.3 Terminología .................................................. ............................. 41
4.2 Algunos patrones y recursos ............................................... .......... 42
Capítulo 5 Análisis de brechas .................................................. ............................... 45

5.1 Introducción................................................. .................................... 45
5.2 Pasos sugeridos .................................................. ............................. 46
5.3 Ejemplo................................................. .......................................... 46
Capítulo 6 Técnicas de Planificación de la Migración ................................ 49

6.1 Catálogo de Factores de Implementación................................................... ........ 49
6.2 Matriz consolidada de brechas, soluciones y dependencias ................ 50
6.3 Tabla de incrementos de definición de arquitectura ................................ 50
6.4 Tabla de evolución del estado de la arquitectura de transición ................ 51
Estándar TOGAF® — Técnicas ADM iii

© 2005-2022 El Grupo Abierto, Todos los derechos reservados
Contenido
6.5 Técnica de evaluación del valor comercial ....................................... 52
Capítulo 7 7.1 7.2 Requisitos de interoperabilidad ............................................. 53

7.3 Visión general................................................ .......................................... 53
7.4 Definición de interoperabilidad .............................................. .................... 53
7.5 Modelo operativo de la empresa ............................................... ............. 55
7.6 Refinando la interoperabilidad ............................................... .................... 55
Determinación de los requisitos de interoperabilidad ........................... 56
Conciliación de los requisitos de interoperabilidad con
Posibles soluciones .................................................. .......................... 58
Capítulo 8 8.1 Evaluación de la preparación para la transformación empresarial ...... 59

8.1.1 Introducción................................................. .................................. 59
8.2 Programa de Habilitación para la Transformación de Negocios (BTEP) ............... 60
8.3 Determinar los factores de preparación ............................................... ........ 60
8.4 Factores de preparación actual ............................................... ............. 62
8.4.1 Evaluar los factores de preparación ............................................... ............. 63
8.4.2 Visión del factor de preparación .................................................. ............... 64
8.4.3 Valoración del factor de preparación .................................................. ............. 64
8.5 Riesgos y acciones del factor de preparación ........................................... .. sesenta y cinco
8.6 8.7 Preparación y planificación de la migración ............................................... ... 66
Comercialización del Plan de Implementación ............................................... .. 66
Conclusión................................................. ..................................... 66
Capítulo 9 9.1 9.2 Gestión de Riesgos .................................................. ...................... 67

9.3 Introducción................................................. .................................... 67
9.4 Clasificación de riesgo .................................................. .......................... 68
9.5 Identificación de riesgo ................................................ .......................... 68
9.6 Evaluación inicial de riesgos .................................................. ..................... 68
9.7 Mitigación de riesgos y evaluación de riesgos residuales ........................... 70
9.8 Llevar a cabo una evaluación de riesgos residuales .................................. .70
Supervisión y Gobernanza del Riesgo (Fase G)................................... 70
Resumen ................................................. ............................................. 71
Capítulo 10 10.1 Alternativas de Arquitectura y Compensaciones ........................ 73

10.2 Concepto................................................. .......................................... 73
Método................................................. .......................................... 73
10.2.1 Criterios................................................ ............................................. 74
10.2.2 Identificar alternativas .................................................. ...................... 75
10.2.3 Elija entre alternativas y defina en detalle ................................ 76
Índice .................................................. ............................................. 77
Lista de Figuras
3-1 Ejemplos de partes interesadas y categorías ............................................... .23

3-2 Stakeholder Power Grid ............................................... ....................... 24
5-1 Ejemplo de análisis de brechas ............................................. ....................... 46
6-1 Catálogo de Factores de Implementación................................................... .......... 49
6-2 Matriz consolidada de brechas, soluciones y dependencias ........ 50
IV El estándar de grupo abierto (2022)

Contenido
6-3 Tabla de incrementos de definición de arquitectura ....................................... 50

6-4 Tabla de Evolución del Estado de la Arquitectura de Transición .......................... 51
6-5 Evaluación de proyecto de muestra con respecto al negocio
Valor y riesgo .............................................................. .................................... 52
7-1 Matriz de interoperabilidad de la información empresarial ........................... 57
7-2 Matriz de Interoperabilidad de Sistemas de Información ................................ 57
8-1 Evaluación de preparación para la transformación empresarial —
Modelo de madurez ............................................... .................................... 63
8-2 Cuadro resumen de preparación para la transformación empresarial
Evaluación ................................................. ...................................... 64
9-1 Esquema de Clasificación de Riesgos .............................................. .......... 69
9-2 Ejemplo de Evaluación de Identificación y Mitigación de Riesgos
Hoja de cálculo ................................................. .......................................... 70
10-1 Método de compensación de la arquitectura ........................................... ............. 73
Lista de tablas
2-1 Formato recomendado para definir principios .......................................... 4

3-1 Ejemplo de Análisis de Partes Interesadas ............................................... .......... 24
Estándar TOGAF® — Técnicas ADM 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 - Técnicas 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.
Estándar TOGAF® — Técnicas ADM 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.
FICO es una marca registrada de Fair Isaac Corporation en los Estados Unidos y otros países.
Java es una marca comercial registrada de Oracle y/o sus filiales.
PMBOK es una marca comercial registrada de Project Management Institute, Inc., que está registrada en los Estados Unidos y
otras naciones.
PRINCE2 es una marca registrada de AXELOS Limited.
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® — Técnicas ADM 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 guía provista en el Estándar TOGAF - Técnicas ADM (este documento).
Las pautas incluidas en este documento son las siguientes:
ÿ Principios de arquitectura (consulte el Capítulo 2) describe los principios para el uso y la implementación de los recursos de TI en
toda la empresa, y cómo desarrollar el conjunto de reglas y pautas generales para la arquitectura que se está desarrollando.
ÿ Gestión de partes interesadas (consulte el Capítulo 3) describe la gestión de partes interesadas, una disciplina importante que los
profesionales de la arquitectura exitosos pueden utilizar para obtener apoyo para sus proyectos.
ÿ Patrones de arquitectura (consulte el Capítulo 4) proporciona orientación sobre el uso de patrones de arquitectura
ÿ Análisis de brechas (consulte el Capítulo 5) describe la técnica conocida como análisis de brechas; es ampliamente utilizado en
TOGAF ADM para validar una arquitectura que se está desarrollando
ÿ Técnicas de planificación de la migración (consulte el Capítulo 6) describe una serie de técnicas para apoyar
planificación de la migración en las Fases E y F
ÿ Requisitos de interoperabilidad (consulte el Capítulo 7) describe una técnica para determinar la interoperabilidad
requisitos
ÿ Business Transformation Readiness Assessment (ver Capítulo 8) describe una técnica para
identificar problemas de transformación empresarial
ÿ Gestión de riesgos (consulte el Capítulo 9) describe una técnica para gestionar el riesgo durante un proyecto de transformación
de la arquitectura/negocio.
ÿ Alternativas de arquitectura y compensaciones (consulte el Capítulo 10) describe una técnica para identificar
Arquitecturas objetivo alternativas y realizar compensaciones entre las alternativas
Estándar TOGAF® — Técnicas ADM 1

Introducción
2 The Open Group Standard (2022)

redistribución
Capítulo 2: Principios de arquitectura
Este capítulo describe los principios para su uso en el desarrollo de una arquitectura empresarial.
2.1 Introducción
Los principios son reglas y directrices generales, destinadas a ser duraderas y rara vez modificadas, que informan y respaldan la
forma en que una organización emprende el cumplimiento de su misión.
A su vez, los principios pueden ser solo un elemento en un conjunto estructurado de ideas que colectivamente definen y guían a la
organización, desde los valores hasta las acciones y los resultados.
Dependiendo de la organización, los principios pueden establecerse dentro de diferentes dominios y en diferentes niveles. Dos
dominios clave informan el desarrollo y la utilización de la arquitectura:
ÿ Los Principios Empresariales brindan una base para la toma de decisiones en toda la empresa e informan cómo la
organización establece el cumplimiento de su misión.
Dichos principios se encuentran comúnmente como un medio para armonizar la toma de decisiones en toda la organización.
En particular, son un elemento clave en una estrategia exitosa de Gobernanza de la Arquitectura (ver el Estándar TOGAF
— Capacidad y Gobernanza de la Arquitectura Empresarial).
Dentro del amplio dominio de los principios empresariales, es común tener principios subsidiarios dentro de una unidad
empresarial o organizacional. Los ejemplos incluyen TI, recursos humanos, operaciones nacionales u operaciones en el
extranjero. Estos principios proporcionan una base para la toma de decisiones dentro del dominio subsidiario e informarán
el desarrollo de la arquitectura dentro del dominio. Se debe tener cuidado para garantizar que los principios utilizados para
informar el desarrollo de la arquitectura se alineen con el contexto organizacional de la capacidad de la arquitectura.
ÿ Los Principios de Arquitectura son un conjunto de principios que se relacionan con el trabajo de arquitectura
Reflejan un nivel de consenso en toda la empresa y encarnan el espíritu y el pensamiento de los principios empresariales
existentes. Los Principios de Arquitectura gobiernan el proceso de arquitectura, afectando el desarrollo, mantenimiento y
uso de la Arquitectura Empresarial.
Es común tener conjuntos de principios para una jerarquía, en ese segmento los principios serán informados y elaborados sobre los
principios a nivel de empresa. Los Principios de Arquitectura serán informados y restringidos por principios empresariales.
Los Principios de Arquitectura pueden reafirmar otras guías empresariales en términos y formas que guíen efectivamente el
desarrollo de la arquitectura.
El resto de esta sección trata exclusivamente de los Principios de Arquitectura.

© 2005-2022 The Open Group, todos los derechos reservados Copia
de evaluación. No para redistribución
Características de los principios de la arquitectura Principios de arquitectura
2.2 Características de los principios de la arquitectura

Los Principios de Arquitectura definen las reglas y directrices generales subyacentes para el uso y la implementación de todos
los recursos y activos de TI en toda la empresa. Reflejan un nivel de consenso entre los diversos elementos de la empresa y
forman la base para tomar futuras decisiones de TI.
Cada Principio de Arquitectura debe estar claramente relacionado con los objetivos comerciales y los impulsores clave de la
arquitectura.
2.3 Componentes de los Principios de Arquitectura

Es útil tener una forma estándar de definir los principios. Además de una declaración de definición, cada principio debe tener
declaraciones de fundamentos y implicaciones asociadas, tanto para promover la comprensión y aceptación de los principios
en sí, como para respaldar el uso de los principios para explicar y justificar por qué se toman decisiones específicas.
En la Tabla 2-1 se proporciona una plantilla recomendada .
Nombre Deben representar tanto la esencia de la regla como ser fáciles de recordar. Las
plataformas tecnológicas específicas no deben mencionarse en el nombre o declaración de un
principio. Evite palabras ambiguas en el Nombre y en la Declaración tales como: "apoyar", "abrir",
"considerar", y por falta de buena medida la palabra "evitar", en sí, tenga cuidado con "manejo(s)", y
buscar adjetivos y adverbios innecesarios (fluff).
Declaración Debe comunicar de forma sucinta y sin ambigüedades la regla fundamental.

En su mayor parte, las declaraciones de principios para administrar la información son similares
de una organización a otra. Es vital que la declaración de principios sea inequívoca.
Razón fundamental Debe resaltar los beneficios comerciales de adherirse al principio, usando terminología
comercial. Señale la similitud de los principios de información y tecnología con los principios que
rigen las operaciones comerciales. También describa la relación con otros principios y las intenciones
con respecto a una interpretación equilibrada. Describa situaciones en las que se dé prioridad a un
principio o tenga más peso que otro para tomar una decisión.
Implicaciones Deben resaltar los requisitos, tanto para el negocio como para TI, para llevar a cabo el principio, en
términos de recursos, costos y actividades/tareas.
Aunque a menudo puede ser evidente que los sistemas, estándares o prácticas actuales
serían incongruentes con el principio al momento de la adopción, el contexto determinará el grado
de alcance. El impacto en el negocio y las consecuencias de adoptar un principio deben establecerse
claramente. El lector debe discernir fácilmente la respuesta a: "¿Cómo me afecta esto?". Es
importante no simplificar demasiado, trivializar o juzgar el mérito del impacto. Algunas de las
implicaciones se identificarán solo como impactos potenciales y pueden ser especulativas en lugar
de analizarse completamente.
Tabla 2-1 Formato recomendado para definir principios
En la Sección 2.6 se proporciona un ejemplo de un conjunto de Principios de Arquitectura siguiendo esta plantilla .

redistribución
Principios de arquitectura Desarrollo de principios de arquitectura
2.4 Desarrollo de principios de arquitectura

Los Principios de Arquitectura generalmente son desarrollados por Enterprise Architects, junto con las partes interesadas
clave, y son aprobados por la Junta de Arquitectura.
Los Principios de Arquitectura se basarán en principios a nivel de empresa, si existen.
Los Principios de Arquitectura deben ser claramente rastreables y claramente articulados para guiar la toma de
decisiones. Se eligen para garantizar la alineación de la arquitectura y la implementación de la Arquitectura objetivo con
las estrategias y visiones comerciales.
Específicamente, el desarrollo de los Principios de Arquitectura suele estar influenciado por lo siguiente:
ÿ Misión y planes de la empresa: la misión, los planes y la infraestructura organizativa de la

ingresar premio
ÿ Iniciativas estratégicas de la empresa: las características de la empresa (sus fortalezas, debilidades,

oportunidades y amenazas) y sus iniciativas actuales en toda la empresa (como la mejora de procesos y la gestión
de la calidad)
ÿ Restricciones externas: factores de mercado (imperativos de tiempo de comercialización, expectativas del cliente,
etc.); legislación existente y potencial
ÿ Sistemas y tecnología actuales: el conjunto de recursos de información desplegados dentro de la empresa,

incluida la documentación de los sistemas, los inventarios de equipos, los diagramas de configuración de la red,
las políticas y los procedimientos.
ÿ Tendencias emergentes de la industria: predicciones sobre aspectos económicos, políticos, técnicos y de mercado.
factores que influyen en el entorno empresarial
2.4.1 Cualidades de los Principios

El simple hecho de tener una declaración escrita que se llama principio no significa que el principio sea bueno, incluso si
todos están de acuerdo con él.
Un buen conjunto de principios se basará en las creencias y valores de la organización y se expresará en un lenguaje
que la empresa comprenda y utilice. Los principios deben ser pocos en número, orientados al futuro y respaldados y
defendidos por la alta dirección. Proporcionan una base firme para tomar decisiones de arquitectura y planificación,
enmarcar políticas, procedimientos y estándares, y apoyar la resolución de situaciones contradictorias. Un conjunto de
principios deficientes rápidamente quedará en desuso y las arquitecturas, políticas y estándares resultantes aparecerán
y o egoísta, y por lo tanto carecen de credibilidad. Esencialmente, los principios impulsan el comportamiento.
Hay cinco criterios que distinguen un buen conjunto de principios:
ÿ Comprensible: los principios subyacentes pueden ser captados y entendidos rápidamente por
personas en toda la organización
La intención del principio es clara e inequívoca, de modo que se minimicen las violaciones, ya sean intencionales
o no.
ÿ Robusto: permite tomar decisiones de buena calidad sobre arquitecturas y planes, y

se crearán políticas y estándares exigibles Cada principio
debe ser lo suficientemente definitivo y preciso para respaldar la toma de decisiones coherente en situaciones
complejas y potencialmente controvertidas.

Desarrollo de principios de arquitectura Principios de arquitectura
ÿ Completo: se definen todos los principios potencialmente importantes que rigen la gestión de la información y la
tecnología para la organización; los principios cubren todas las situaciones percibidas
ÿ Coherente: la adherencia estricta a un principio puede requerir una interpretación flexible de otro
pr incipio
El conjunto de principios debe expresarse de manera que permita un equilibrio de interpretaciones.

Los principios no deben ser contradictorios hasta el punto en que adherirse a un principio violaría el espíritu de otro.
Cada palabra en una declaración de principio debe elegirse cuidadosamente para permitir una interpretación
consistente pero flexible.
ÿ Estable: los principios deben ser duraderos, pero capaces de adaptarse a los cambios.
Debe establecerse un proceso de enmienda para agregar, eliminar o modificar principios después de que se hayan
ratificado inicialmente.
2.5 Aplicación de los principios de la arquitectura

Los Principios de Arquitectura se utilizan para capturar las verdades fundamentales acerca de cómo la empresa utilizará e
implementará los recursos y activos de TI. Los principios se utilizan de diferentes maneras:
1. Proporcionar un marco dentro del cual la empresa pueda comenzar a tomar decisiones conscientes sobre la
arquitectura empresarial y los proyectos que implementan la arquitectura empresarial objetivo.
2. Como guía para establecer criterios de evaluación relevantes, ejerciendo así una fuerte influencia en la selección de
productos, soluciones o arquitecturas de solución en las etapas posteriores de gestión del cumplimiento de la
Arquitectura Empresarial.
3. Como impulsores para definir los requisitos funcionales de la arquitectura
4. Como insumo para evaluar tanto las implementaciones existentes como el portafolio estratégico, para el cumplimiento
de las arquitecturas definidas; estas evaluaciones proporcionarán información valiosa sobre las actividades de
transición necesarias para implementar una arquitectura, en apoyo de las metas y prioridades comerciales
5. Las declaraciones de fundamento dentro de un principio de arquitectura resaltan el valor comercial de las
implementaciones consistentes con el principio y brindan orientación para decisiones difíciles con impulsores u
objetivos en conflicto.
6. Las declaraciones de Implicaciones dentro de un Principio de Arquitectura proporcionan un resumen de las tareas
clave, los recursos y los costos potenciales para la empresa de seguir el principio; también brindan aportes valiosos
para futuras iniciativas de transición y actividades de planificación
7. Apoyar las actividades de Gobernanza de la Arquitectura en términos de:
— Proporcionar un "back-stop" para las evaluaciones de cumplimiento de la arquitectura estándar

donde se permite o requiere alguna interpretación
— Respaldar la decisión de iniciar una solicitud de dispensa cuando las implicaciones de una modificación
particular de la arquitectura no puedan resolverse dentro del procedimiento operativo local
Los principios pueden estar interrelacionados y deben aplicarse como un conjunto.
Los principios a veces competirán; por ejemplo, los principios de "accesibilidad" y "seguridad"

redistribución
Principios de arquitectura Aplicación de principios de arquitectura
tienden a tomar decisiones contradictorias. Cada principio debe considerarse en el contexto de "todas las demás cosas
son iguales".
A veces se requerirá una decisión sobre qué principio prevalecerá en un tema en particular. Siempre se debe documentar
la justificación de tales decisiones.
Una reacción común en la primera lectura de un principio es "esto es obvio y no necesita ser documentado". El hecho de
que un principio parezca evidente por sí mismo no significa que se siga la guía de un principio. Tener principios que
parecen obvios ayuda a garantizar que las decisiones realmente sigan el resultado deseado.
Aunque no se prescriben sanciones específicas en una declaración de principios, las violaciones de los principios
generalmente causan problemas operativos e inhiben la capacidad de la organización para cumplir su misión.
2.6 Ejemplo de conjunto de principios de arquitectura

Demasiados principios pueden reducir la flexibilidad de la arquitectura. Muchas organizaciones prefieren definir solo
principios de alto nivel y limitar el número a entre 10 y 20.
El siguiente ejemplo ilustra tanto el contenido típico de un conjunto de Principios de Arquitectura como el formato
recomendado para definirlos, como se explicó anteriormente.
2.6.1 Principios comerciales

Principio 1: Primacía de los Principios
Declaración: Estos principios de gestión de la información se aplican a todas las organizaciones dentro de la
empresa.
Razón fundamental: La única forma en que podemos proporcionar un nivel consistente y mensurable de información de
calidad a los tomadores de decisiones es si todas las organizaciones cumplen con los principios.
Trascendencia: ÿ Sin este principio, las exclusiones, el favoritismo y la incoherencia

socavar rápidamente la gestión de la información
ÿ Las iniciativas de gestión de la información no comenzarán hasta que se examine el

cumplimiento de los principios.
ÿ Un conflicto con un principio se resolverá cambiando el marco de

la iniciativa
Principio 2: maximizar el beneficio para la empresa
Declaración: Las decisiones de gestión de la información se toman para proporcionar el máximo beneficio a la
empresa en su conjunto.
Razón fundamental: Este principio encarna el "servicio por encima de uno mismo". Las decisiones tomadas desde una
perspectiva de toda la empresa tienen mayor valor a largo plazo que las decisiones tomadas desde
cualquier perspectiva organizacional en particular. La máxima rentabilidad de la inversión requiere
que las decisiones de gestión de la información se adhieran a los impulsores y las prioridades de
toda la empresa. Ningún grupo minoritario restará valor al beneficio del conjunto. Sin embargo, este
principio no impedirá que ningún grupo minoritario haga su trabajo.

Ejemplo de conjunto de principios de arquitectura Principios de arquitectura
Trascendencia: ÿ Lograr el máximo beneficio para toda la empresa requerirá cambios en la forma en que
planificamos y administramos la información; la tecnología por sí sola no provocará este cambio
ÿ Algunas organizaciones pueden tener que conceder sus propias preferencias para el
mayor beneficio de toda la empresa
ÿ Cuando sea factible, las prioridades de desarrollo de aplicaciones deben ser establecidas por
toda la empresa para toda la empresa
ÿ Los componentes de las aplicaciones deben compartirse entre los miembros de la organización.
límites
ÿ Las iniciativas de gestión de la información deben llevarse a cabo de acuerdo con el plan
empresarial.
Las organizaciones individuales deben emprender iniciativas de gestión de la información que

se ajusten a los planes y prioridades establecidos por la empresa. El plan se cambiará según
sea necesario.
ÿ A medida que surjan las necesidades, se deben ajustar las prioridades; un foro con una
representación integral de la empresa debe tomar estas decisiones
Principio 3: La gestión de la información es asunto de todos
Declaración: Todas las organizaciones de la empresa participan en las decisiones de gestión de la información
necesarias para lograr los objetivos comerciales.
Razón fundamental: Los usuarios de la información son las partes interesadas clave, o clientes, en la aplicación de la
tecnología para abordar una necesidad comercial. Para garantizar que la gestión de la información
esté alineada con el negocio, todas las organizaciones de la empresa deben participar en todos los
aspectos del entorno de la información. Los expertos en negocios de toda la empresa y el personal
técnico responsable de desarrollar y mantener el entorno de información deben unirse como equipo
para definir conjuntamente las metas y objetivos de TI.
Trascendencia: ÿ Para operar como un equipo, cada parte interesada o cliente deberá aceptar la responsabilidad
de desarrollar el entorno de información.
ÿ Se requerirá el compromiso de recursos para implementar este principio
Principio 4: Continuidad del Negocio
Declaración: Las operaciones de la empresa se mantienen a pesar de las interrupciones del sistema.
Razón fundamental: A medida que las operaciones del sistema se vuelven más generalizadas, nos volvemos más
dependientes de ellas; por lo tanto, debemos considerar la confiabilidad de dichos sistemas a lo largo
de su diseño y uso. Los locales comerciales en toda la empresa deben tener la capacidad de continuar
las operaciones independientemente de los eventos externos. No se debe permitir que las fallas de
hardware, los desastres naturales y la corrupción de datos interrumpan o detengan las actividades
empresariales. La empresa debe ser capaz de operar con mecanismos alternativos de entrega de
información.
Trascendencia: ÿ La dependencia de las aplicaciones de sistemas compartidos exige que los riesgos de
interrupción del negocio se establezcan por adelantado y se gestionen
La gestión incluye pero no se limita a revisiones periódicas, pruebas de

redistribución
Principios de arquitectura Ejemplo de conjunto de principios de arquitectura
vulnerabilidad y exposición, o diseñar servicios de misión crítica para garantizar la

continuidad del negocio a través de capacidades redundantes o alternativas.
ÿ La capacidad de recuperación, redundancia y mantenibilidad deben abordarse en el

momento del diseño
ÿ Se debe evaluar la criticidad y el impacto de las aplicaciones en la misión de la empresa, a

fin de determinar qué nivel de continuidad se requiere y qué plan de recuperación
correspondiente es necesario
Principio 5: Aplicaciones de uso común
Declaración: Se prefiere el desarrollo de aplicaciones utilizadas en toda la empresa al desarrollo de aplicaciones

similares o duplicadas que solo se proporcionan a una organización en particular.
Razón fundamental: La capacidad de duplicación es costosa y prolifera datos contradictorios.
Trascendencia: ÿ Las organizaciones que dependen de una capacidad que no atiende a toda la empresa
deben cambiar a la capacidad de reemplazo para toda la empresa; esto requerirá el
establecimiento y la adhesión a una política que requiera esto
ÿ No se permitirá que las organizaciones desarrollen capacidades para su propio uso que
sean similares o dupliquen las capacidades de toda la empresa; De esta manera, se
reducirán los gastos de recursos escasos para desarrollar esencialmente la misma
capacidad en formas marginalmente diferentes.
ÿ Los datos y la información utilizados para respaldar la toma de decisiones empresariales se

estandarizarán mucho más que antes.
Esto se debe a que las capacidades organizacionales más pequeñas que produjeron
diferentes datos (que no se compartieron con otras organizaciones) serán reemplazadas
por capacidades de toda la empresa. El ímpetu para agregar al conjunto de capacidades
de toda la empresa bien puede provenir de una organización que presente argumentos
convincentes sobre el valor de los datos/información producidos previamente por su
capacidad organizacional, pero la capacidad resultante se convertirá en parte de la
empresa. -todo el sistema, y los datos que produce se compartirán en toda la empresa.
Principio 6: Orientación al Servicio
Declaración: La arquitectura se basa en un diseño de servicios que reflejan las actividades comerciales del
mundo real que comprenden los procesos comerciales de la empresa (o entre empresas).
Razón fundamental: La orientación al servicio brinda agilidad empresarial y flujo de información sin límites.
Trascendencia: ÿ La representación de servicios utiliza descripciones comerciales para brindar contexto (es
decir, procesos comerciales, objetivos, reglas, políticas, interfaz de servicios y componentes
de servicios) e implementa servicios mediante la orquestación de servicios.
ÿ La orientación al servicio impone requisitos únicos a la infraestructura, y las implementaciones

deben usar estándares abiertos para lograr la interoperabilidad y la transparencia de la
ubicación.

ÿ Las implementaciones son específicas del entorno; están limitados o habilitados por el contexto
y deben describirse dentro de ese contexto
ÿ Se requiere una gobernanza sólida de la representación e implementación del servicio.

requerido
ÿ Se requiere una "prueba de fuego", que determina un "buen servicio".
Principio 7: Cumplimiento de la Ley
Declaración: Los procesos de gestión de la información empresarial cumplen con todas las leyes, políticas y
reglamentaciones pertinentes.
Razón fundamental: La política de Enterprise es cumplir con las leyes, políticas y reglamentos. Esto no impedirá las mejoras
en los procesos comerciales que conduzcan a cambios en las políticas y reglamentaciones.
Trascendencia: ÿ La empresa debe tener en cuenta el cumplimiento de las leyes, los reglamentos y las políticas
externas con respecto a la recopilación, retención y gestión de datos.
ÿ Educación y acceso a las reglas
La eficiencia, la necesidad y el sentido común no son los únicos impulsores. Los cambios en la
ley y los cambios en las regulaciones pueden generar cambios en nuestros procesos o
aplicaciones.
Principio 8: Responsabilidad de TI
Declaración: La organización de TI es responsable de poseer e implementar procesos e infraestructura de TI que

permitan que las soluciones cumplan con los requisitos definidos por el usuario en cuanto a
funcionalidad, niveles de servicio, costo y tiempo de entrega.
Razón fundamental: Alinee de manera efectiva las expectativas con las capacidades y los costos para que todos los
proyectos sean rentables. Las soluciones eficientes y efectivas tienen costos razonables y claros
beneficios.
Trascendencia: ÿ Se debe crear un proceso para priorizar los proyectos
ÿ La función de TI debe definir procesos para gestionar la unidad de negocio

Expectativas
ÿ Se deben crear modelos de datos, aplicaciones y tecnología para permitir

soluciones integradas de calidad y para maximizar los resultados
Principio 9: Protección de la Propiedad Intelectual
Declaración: La Propiedad Intelectual (PI) de la empresa debe estar protegida. Esta protección debe reflejarse en
los procesos de arquitectura, implementación y gobierno de TI.
Razón fundamental: Una parte importante de la propiedad intelectual de una empresa está alojada en el dominio de TI.
Trascendencia: ÿ Si bien la protección de los activos de propiedad intelectual es asunto de todos, gran parte de la
protección real se implementa en el dominio de TI; incluso la confianza en los procesos que no
son de TI se puede administrar mediante procesos de TI (correo electrónico, notas obligatorias,
etc.)

redistribución
ÿ Se requerirá una política de seguridad, que rija a los actores humanos y de TI, que pueda mejorar
sustancialmente la protección de la PI; esto debe ser capaz tanto de evitar compromisos como de
reducir responsabilidades
ÿ Los recursos sobre tales políticas se pueden encontrar en el Instituto SANS (consulte
www.sans.org/security-resources/policies)
2.6.2 Principios de datos

Principio 10: Los datos son un activo
Declaración: Los datos son un activo que tiene valor para la empresa y se gestionan en consecuencia.
Razón fundamental: Los datos son un recurso corporativo valioso; tiene un valor real y mensurable. En términos simples, el
propósito de los datos es ayudar en la toma de decisiones. Los datos precisos y oportunos son fundamentales
para tomar decisiones precisas y oportunas. La mayoría de los activos corporativos se administran
cuidadosamente y los datos no son una excepción. Los datos son la base de nuestra toma de decisiones, por
lo que también debemos administrarlos con cuidado para asegurarnos de que sabemos dónde están, podemos
confiar en su precisión y podemos obtenerlos cuando y donde los necesitemos.
Trascendencia: ÿ Este es uno de los tres principios estrechamente relacionados con respecto a los datos: los datos son un
activo; los datos se comparten; y los datos son fácilmente accesibles
La implicación es que existe una tarea educativa para garantizar que todas las organizaciones dentro
de la empresa comprendan la relación entre el valor de los datos, el intercambio de datos y la
accesibilidad a los datos.
ÿ Los administradores deben tener la autoridad y los medios para administrar los datos para
que son responsables
ÿ Debemos hacer la transición cultural del pensamiento de "propiedad de los datos" a

pensamiento de "administración de datos"
ÿ El papel del administrador de datos es fundamental porque los datos obsoletos, incorrectos o
inconsistentes podrían pasarse al personal de la empresa y afectar negativamente las decisiones en
toda la empresa.
ÿ Parte del rol del administrador de datos, que administra los datos, es garantizar
calidad de datos
Se deben desarrollar y utilizar procedimientos para prevenir y corregir errores en la información y para
mejorar aquellos procesos que producen información defectuosa. Será necesario medir la calidad de
los datos y tomar medidas para mejorar la calidad de los datos; es probable que también sea necesario
desarrollar políticas y procedimientos para esto.
ÿ Un foro con representación integral de toda la empresa debe decidir sobre los cambios de proceso
sugeridos por el administrador
ÿ Dado que los datos son un activo de valor para toda la empresa, los administradores de datos
responsables de administrar adecuadamente los datos deben asignarse a nivel de empresa.

© 2005-2022 The Open Group, todos los derechos reservados Copia de
evaluación. No para redistribución
Principio 11: Los datos se comparten
Declaración: Los usuarios tienen acceso a los datos necesarios para el desempeño de sus funciones; por lo tanto, los datos
se comparten entre funciones y organizaciones empresariales.
Razón fundamental: El acceso oportuno a datos precisos es esencial para mejorar la calidad y la eficiencia de la toma de decisiones
empresariales. Es menos costoso mantener datos oportunos y precisos en una sola aplicación, y luego
compartirlos, que mantener datos duplicados en múltiples aplicaciones. La empresa tiene una gran cantidad
de datos, pero se almacenan en cientos de bases de datos de chimenea incompatibles. La velocidad de
recopilación, creación, transferencia y asimilación de datos está impulsada por la capacidad de la organización
para compartir eficientemente estas islas de datos en toda la organización.
Los datos compartidos darán como resultado decisiones mejoradas, ya que confiaremos en pocas fuentes (en
última instancia, una virtual) de datos administrados más precisos y oportunos para todas nuestras decisiones.
Los datos compartidos electrónicamente darán como resultado una mayor eficiencia cuando las entidades de
datos existentes se puedan usar, sin volver a teclear, para crear nuevas entidades.
ÿ Para permitir el intercambio de datos, debemos desarrollar y cumplir con un conjunto común de políticas,
procedimientos y estándares que rigen la gestión y el acceso a los datos tanto a corto como a largo
plazo.
ÿ A corto plazo, para preservar nuestra importante inversión en sistemas heredados, debemos invertir en
software capaz de migrar datos de sistemas heredados a un entorno de datos compartidos.
ÿ También necesitaremos desarrollar modelos de datos estándar, elementos de datos y otros metadatos
que definan este entorno compartido y desarrollar un sistema de depósito para almacenar estos
metadatos para que sean accesibles.
ÿ A largo plazo, a medida que se reemplazan los sistemas heredados, debemos adoptar y hacer cumplir
políticas y pautas comunes de acceso a datos para los desarrolladores de nuevas aplicaciones para
garantizar que los datos en las nuevas aplicaciones permanezcan disponibles para el entorno
compartido y que los datos en el entorno compartido puedan continuar. ser utilizado por las nuevas
aplicaciones
ÿ Tanto a corto como a largo plazo, debemos adoptar métodos y herramientas comunes para crear,
mantener y acceder a los datos compartidos en toda la empresa.
ÿ El intercambio de datos requerirá un cambio cultural significativo. ÿ Este
principio de intercambio de datos "topará" continuamente con el principio de seguridad de datos; bajo
ninguna circunstancia, el principio de intercambio de datos hará que los datos confidenciales se vean
comprometidos.
12 The Open Group Standard (2022) ©

2005-2022 The Open Group, Todos los derechos reservados Copia de evaluación. No para redistribución
ÿ Todos los usuarios deberán confiar en los datos disponibles para compartir para ejecutar sus respectivas
tareas.
Esto asegurará que solo se confíe en los datos más precisos y oportunos para la toma de decisiones.
Los datos compartidos se convertirán en la "única fuente virtual" de datos para toda la empresa.
Principio 12: Los datos son accesibles
Declaración: Los datos son accesibles para que los usuarios realicen sus funciones.
Razón fundamental: El amplio acceso a los datos genera eficiencia y eficacia en la toma de decisiones y permite una respuesta
oportuna a las solicitudes de información y la prestación de servicios.
El uso de la información debe considerarse desde una perspectiva empresarial para permitir el acceso a una
amplia variedad de usuarios. Se ahorra tiempo del personal y se mejora la consistencia de los datos.
ÿ La accesibilidad implica la facilidad con la que los usuarios obtienen información. ÿ La forma en
que se accede a la información y se muestra debe ser lo suficientemente adaptable para satisfacer una
amplia gama de usuarios empresariales y sus correspondientes métodos de acceso.
ÿ El acceso a los datos no constituye una comprensión de los datos; el personal debe tener cuidado de no
malinterpretar la información.
ÿ El acceso a los datos no otorga necesariamente al usuario derechos de acceso a

modificar o divulgar los datos
Esto requerirá un proceso de educación y un cambio en la cultura organizacional, que actualmente

respalda la creencia en la "propiedad" de los datos por parte de las unidades funcionales.
Principio 13: Fideicomisario de datos
Declaración: Cada elemento de datos tiene un fideicomisario responsable de la calidad de los datos.
Razón fundamental: Uno de los beneficios de un entorno diseñado es la capacidad de compartir datos (p. ej., texto, video, sonido,
etc.) en toda la empresa. A medida que crece el grado de intercambio de datos y las unidades de negocio
confían en información común, se vuelve esencial que solo el administrador de datos tome decisiones sobre el
contenido de los datos.
Dado que los datos pueden perder su integridad cuando se ingresan varias veces, el administrador de datos
será el único responsable de la entrada de datos, lo que elimina el esfuerzo humano redundante y los recursos
de almacenamiento de datos.
Nota: Un administrador es diferente a un administrador: un administrador es responsable de la precisión y

vigencia de los datos, mientras que las responsabilidades de un administrador pueden ser
más amplias e incluir tareas de definición y estandarización de datos.

Trascendencia: ÿ La tutela real disuelve los problemas de "propiedad" de los datos y permite que
Los datos deben estar disponibles para satisfacer las necesidades de todos los usuarios.
Esto implica que puede ser necesario un cambio cultural de la "propiedad" de los datos a la "tutela" de
los datos.
ÿ El administrador de datos será responsable de cumplir con los requisitos de calidad

gravado sobre los datos de los que el fideicomisario es responsable
ÿ Es esencial que el fideicomisario tenga la capacidad de brindar confianza al usuario en los datos en
función de atributos como "fuente de datos"
ÿ Es esencial identificar la verdadera fuente de los datos para que los datos
a la autoridad se le puede asignar esta responsabilidad de fideicomisario
Esto no significa que se revelarán fuentes clasificadas ni significa que la fuente será el
administrador.
ÿ La información debe capturarse electrónicamente una vez e inmediatamente

validado lo más cerca posible de la fuente
Se deben implementar medidas de control de calidad para garantizar la integridad de los datos.
ÿ Como resultado de compartir datos en toda la empresa, el fideicomisario es responsable de la exactitud

y vigencia de los elementos de datos designados y, posteriormente, debe reconocer la importancia de
esta responsabilidad de fideicomiso.
Principio 14: Vocabulario común y definiciones de datos
Declaración: Los datos se definen de manera consistente en toda la empresa, y las definiciones son comprensibles y están
disponibles para todos los usuarios.
Razón fundamental: Los datos que se utilizarán en el desarrollo de aplicaciones deben tener una definición común en toda la Sede
para permitir el intercambio de datos. Un vocabulario común facilitará la comunicación y permitirá que el diálogo
sea efectivo. Además, se requiere para interconectar sistemas e intercambiar datos.
Trascendencia: ÿ Nos adormecemos al pensar que este problema se aborda adecuadamente porque hay personas con
títulos de trabajo de "administración de datos" y foros con estatutos que implican responsabilidad.
Se debe dedicar una cantidad significativa de energía y recursos adicionales a esta tarea. Es clave
para el éxito de los esfuerzos por mejorar el entorno de la información. Esto es independiente pero está
relacionado con el tema de la definición de elementos de datos, que es abordado por la comunidad en
el extranjero; es más como un vocabulario y una definición comunes.
ÿ La empresa debe establecer el vocabulario común inicial para el negocio; las definiciones se usarán
uniformemente en toda la empresa ÿ Siempre que se requiera una nueva definición de datos, el
esfuerzo de definición se coordinará y conciliará con el "glosario" corporativo de descripciones de datos
El administrador de datos de la empresa proporcionará esta coordinación.

ÿ Las ambigüedades resultantes de múltiples definiciones parroquiales de datos deben dar

paso a definiciones y comprensión aceptadas en toda la empresa.
ÿ Es necesario coordinar múltiples iniciativas de estandarización de datos
ÿ Deben asignarse responsabilidades de administración de datos funcionales
Principio 15: Seguridad de los datos
Declaración: Los datos están protegidos contra el uso y la divulgación no autorizados. Además de los aspectos
tradicionales de la clasificación de seguridad nacional, esto incluye, pero no se limita a, la protección
de información predecisiva, sensible, sensible a la selección de fuentes y de propiedad exclusiva.
Razón fundamental: El intercambio abierto de información y la divulgación de información a través de la legislación

pertinente deben equilibrarse con la necesidad de restringir la disponibilidad de información
confidencial, confidencial y clasificada.
Las leyes y reglamentos existentes exigen salvaguardar la seguridad nacional y la privacidad de

los datos, al tiempo que permiten el acceso libre y abierto. La información previa a la decisión
(trabajo en progreso, aún no autorizado para su publicación) debe protegerse para evitar
especulaciones injustificadas, interpretaciones erróneas y uso inapropiado.
Trascendencia: ÿ La agregación de datos, tanto clasificados como no, creará un gran objetivo que requerirá
procedimientos de revisión y desclasificación para mantener un control adecuado.
Los propietarios de datos y/o usuarios funcionales deben determinar si la agregación da

como resultado un mayor nivel de clasificación. Se necesitarán políticas y procedimientos
apropiados para manejar esta revisión y desclasificación. El acceso a la información basado
en una política de necesidad de saber obligará a revisiones periódicas del cuerpo de
información.
ÿ Es necesario repensar la práctica actual de tener sistemas separados para contener diferentes
clasificaciones. ¿Existe una solución de software para separar datos clasificados y no
clasificados? La solución de hardware actual es difícil de manejar, ineficiente y costosa. Es

más costoso administrar datos no clasificados en un sistema clasificado.
Actualmente, la única forma de combinar los dos es colocar los datos no clasificados en el
sistema clasificado, donde deben permanecer.
ÿ Para brindar acceso adecuado a la información abierta mientras se mantiene la información

segura, las necesidades de seguridad deben identificarse y desarrollarse a nivel de datos,
no a nivel de aplicación.
ÿ Se pueden implementar salvaguardas de seguridad de datos para restringir el acceso a "ver

solo" o "nunca ver"
Se debe determinar el etiquetado de confidencialidad para el acceso a información

predecisiva, decisional, clasificada, confidencial o patentada.
ÿ La seguridad debe diseñarse en elementos de datos desde el principio; no se puede agregar

despues
Los sistemas, datos y tecnologías deben protegerse del acceso y la manipulación no

autorizados. La información en la Sede debe ser

protegido contra alteración involuntaria o no autorizada, sabotaje, desastre o divulgación.
ÿ Se necesitan nuevas políticas sobre la gestión de la duración de la protección de la información

previa a la toma de decisiones y otros trabajos en curso, teniendo en cuenta la actualización del
contenido.
2.6.3 Principios de aplicación
Principio 16: Independencia tecnológica
Declaración: Las aplicaciones son independientes de las opciones tecnológicas específicas y, por lo tanto, pueden
operar en una variedad de plataformas tecnológicas.
Razón fundamental: La independencia de las aplicaciones de la tecnología subyacente permite que las aplicaciones se
desarrollen, actualicen y operen de la manera más rentable y oportuna. De lo contrario, la tecnología,
que está sujeta a la continua obsolescencia y la dependencia del proveedor, se convierte en el impulsor
y no en los requisitos del usuario en sí.
Al darse cuenta de que cada decisión que se toma con respecto a TI nos hace depender de esa
tecnología, la intención de este principio es garantizar que el software de aplicación no dependa de
hardware y software de sistemas operativos específicos.
Trascendencia: ÿ Este principio requerirá estándares que apoyen la portabilidad
ÿ Para Commercial Off-The-Shelf (COTS) y Government Off-The-Shelf

(GOTS), es posible que las opciones actuales sean limitadas, ya que muchas de estas
aplicaciones dependen de la tecnología y la plataforma
ÿ Será necesario desarrollar interfaces de subsistemas para permitir que las aplicaciones heredadas
interoperen con las aplicaciones y los entornos operativos desarrollados bajo la arquitectura
empresarial.
ÿ Se debe usar middleware para desacoplar aplicaciones de aplicaciones específicas.

soluciones de software
ÿ Como ejemplo, este principio podría conducir al uso de Java ®, y futuras

Protocolos similares a Java, que otorgan un alto grado de prioridad a la independencia de la
plataforma
Principio 17: Facilidad de uso
Declaración: Las aplicaciones son fáciles de usar. La tecnología subyacente es transparente para los usuarios, por lo
que pueden concentrarse en las tareas que tienen entre manos.
Razón fundamental: Cuanto más tiene que entender un usuario la tecnología subyacente, menos productivo es ese usuario.
La facilidad de uso es un incentivo positivo para el uso de las aplicaciones. Alienta a los usuarios a
trabajar dentro del entorno de información integrada en lugar de desarrollar sistemas aislados para
realizar la tarea fuera del entorno de información integrada de la empresa. La mayor parte del
conocimiento requerido para operar un sistema será similar a otros. La capacitación se reduce al mínimo
y el riesgo de usar un sistema de manera incorrecta es bajo.
El uso de una aplicación debería ser tan intuitivo como conducir un coche diferente.
dieciséis The Open Group Standard (2022)

redistribución
Trascendencia: ÿ Se requerirá que las aplicaciones tengan un "aspecto y tacto" común y soporten los
requisitos ergonómicos; por lo tanto, se debe diseñar el estándar común de apariencia y
funcionamiento y se deben desarrollar los criterios de prueba de usabilidad.
ÿ Las pautas para las interfaces de usuario no deben estar restringidas por suposiciones
limitadas sobre la ubicación del usuario, el idioma, la capacitación en sistemas o la
capacidad física.
Factores como la lingüística, las enfermedades físicas del cliente (agudeza visual,
capacidad para usar el teclado/ratón) y la competencia en el uso de la tecnología tienen
amplias ramificaciones para determinar la facilidad de uso de una aplicación.
2.6.4 Principios tecnológicos
Principio 18: Cambio basado en requisitos
Declaración: Solo en respuesta a las necesidades comerciales se realizan cambios en las aplicaciones y la
tecnología.
Razón fundamental: Este principio fomentará una atmósfera en la que el entorno de la información cambie en respuesta
a las necesidades del negocio, en lugar de que el negocio cambie en respuesta a los cambios de
TI. Esto es para asegurar que el propósito del soporte de información, la transacción comercial,
sea la base para cualquier cambio propuesto.
Se minimizarán los efectos no deseados en el negocio debido a los cambios de TI.
Un cambio en la tecnología puede brindar una oportunidad para mejorar el proceso comercial y,
por lo tanto, cambiar las necesidades comerciales.
Trascendencia: ÿ Los cambios en la implementación seguirán un examen completo de la propuesta

cambios utilizando la Arquitectura Empresarial
ÿ No hay financiación para una mejora técnica o desarrollo del sistema

a menos que exista una necesidad comercial documentada
ÿ Los procesos de gestión del cambio conforme a este principio serán

desarrollado e implementado
ÿ Este principio puede chocar con el principio de cambio receptivo
Debemos asegurarnos de que el proceso de documentación de requisitos no obstaculice

el cambio receptivo para satisfacer las necesidades comerciales legítimas. El propósito de
este principio es mantener el enfoque en el negocio, no en las necesidades tecnológicas;
el cambio receptivo también es una necesidad comercial.

Principio 19: Gestión de cambios receptiva
Declaración: Los cambios en el entorno de información empresarial se implementan de manera oportuna.
Razón fundamental: Si se espera que las personas trabajen en el entorno de información de la empresa, ese entorno
de información debe responder a sus necesidades. ÿ Deben desarrollarse procesos para gestionar
Trascendencia: e implementar el cambio

que no generen retrasos
ÿ Un usuario que sienta la necesidad de un cambio deberá conectarse con un "experto en

negocios" para facilitar la explicación e implementación de esa necesidad . ÿ Si se van a
realizar cambios, la arquitectura debe mantenerse actualizada.
ÿ La adopción de este principio podría requerir recursos adicionales
ÿ Esto entrará en conflicto con otros principios (p. ej., máxima

beneficios, aplicaciones en toda la empresa, etc.)
Principio 20: Controlar la Diversidad Técnica
Declaración: La diversidad tecnológica se controla para minimizar el costo no trivial de mantener la experiencia
y la conectividad entre múltiples entornos de procesamiento.
Razón fundamental: Hay un costo real y no trivial de infraestructura requerida para admitir tecnologías alternativas
para entornos de procesamiento. Se incurre en costos de infraestructura adicionales para
mantener las construcciones de múltiples procesadores interconectadas y mantenidas.
Limitar la cantidad de componentes admitidos simplificará la capacidad de mantenimiento y

reducirá los costos.
Las ventajas comerciales de la diversidad técnica mínima incluyen: embalaje estándar de

componentes; impacto de implementación predecible; valoraciones y rendimientos predecibles;
pruebas redefinidas; estado de utilidad; y una mayor flexibilidad para adaptarse a los avances
tecnológicos. La tecnología común en toda la empresa trae los beneficios de las economías de
escala a la empresa.
Los costos de soporte y administración técnica se controlan mejor cuando los recursos limitados
pueden enfocarse en este conjunto compartido de tecnología.
Trascendencia: ÿ Las políticas, normas y procedimientos que rigen la adquisición de tecnología deben estar
directamente vinculados a este principio
ÿ Las opciones tecnológicas estarán restringidas por las opciones disponibles dentro del
proyecto tecnológico.
Deberán desarrollarse e implementarse procedimientos para aumentar el conjunto de

tecnología aceptable para cumplir con los requisitos en evolución.
ÿ La línea de base tecnológica no se congela
Los avances tecnológicos son bienvenidos y cambiarán el modelo de tecnología cuando

se haya demostrado la compatibilidad con la infraestructura actual, la mejora en la eficiencia
operativa o la capacidad requerida.

redistribución
Principio 21: Interoperabilidad
Declaración: El software y el hardware deben cumplir con estándares definidos que promuevan
interoperabilidad de datos, aplicaciones y tecnología.
Razón fundamental: Los estándares ayudan a garantizar la coherencia, mejorando así la capacidad de gestionar
sistemas y mejorar la satisfacción del usuario, y proteger las inversiones de TI existentes,
maximizando así el retorno de la inversión y reduciendo los costos. Estándares para
la interoperabilidad también ayuda a garantizar el soporte de múltiples proveedores para sus
productos y facilitar la integración de la cadena de suministro.
Trascendencia: ÿ Se seguirán los estándares de interoperabilidad y los estándares de la industria a menos que
hay una razón comercial de peso para implementar un no estándar
solución
ÿ Un proceso para establecer estándares, revisarlos y revisarlos periódicamente,

y la concesión de excepciones debe establecerse
ÿ Las plataformas de TI existentes deben identificarse y documentarse

Principios de arquitectura

redistribución
Capítulo 3: Gestión de las partes interesadas
3.1 Introducción
La gestión de las partes interesadas es una disciplina importante que los profesionales de la arquitectura exitosos pueden utilizar
para obtener el apoyo de los demás. Les ayuda a garantizar que sus proyectos tengan éxito donde otros fracasan.
Los beneficios de una gestión exitosa de las partes interesadas son los siguientes:
ÿ Las partes interesadas más poderosas pueden identificarse temprano y su aporte puede usarse para dar forma a la
arquitectura; esto asegura su apoyo y mejora la calidad de los modelos producidos
ÿ El apoyo de las partes interesadas más poderosas ayudará a que el compromiso gane más
recursos, lo que hace que el compromiso de la arquitectura tenga más probabilidades de éxito
ÿ Al comunicarse con las partes interesadas de manera temprana y frecuente, el equipo de arquitectura puede asegurarse de
que comprendan completamente el proceso de arquitectura y los beneficios de Enterprise
Arquitectura; esto significa que pueden apoyar al equipo de arquitectura de forma más activa cuando sea necesario
ÿ El equipo de arquitectura puede anticipar de manera más efectiva las reacciones probables a los modelos e informes de
arquitectura, y puede incorporar al plan las acciones que serán necesarias para capitalizar las reacciones positivas
mientras evita o aborda las reacciones negativas.
ÿ El equipo de arquitectura puede identificar objetivos conflictivos o que compiten entre las partes interesadas de manera
temprana y desarrollar una estrategia para resolver los problemas que surjan de ellos.
Es esencial en cualquier iniciativa identificar a los individuos y grupos dentro de la organización que contribuirán al desarrollo de
la arquitectura, identificar aquellos que ganarán y aquellos que perderán con su introducción y luego desarrollar una estrategia
para tratar con ellos.
3.2 Enfoque para la gestión de partes interesadas

El análisis de las partes interesadas debe usarse durante la Fase A (Visión de la arquitectura) para identificar a los actores clave
en el compromiso y también actualizarse en cada fase; Se pueden descubrir diferentes partes interesadas a medida que avanza
el compromiso hacia Oportunidades y soluciones, Planificación de migración y Gestión de cambios de arquitectura.
Las arquitecturas complejas son extremadamente difíciles de administrar, no solo en términos del proceso de desarrollo de la
arquitectura en sí, sino también en términos de obtener el acuerdo de la gran cantidad de partes interesadas involucradas.
Por ejemplo, al igual que un arquitecto de edificios creará diagramas de cableado, planos de planta y elevaciones para describir
las diferentes facetas de un edificio a sus diferentes partes interesadas (electricistas, propietarios, planificadores).

Enfoque para la gestión de partes interesadas Gestión de los interesados
funcionarios), por lo que un Arquitecto Empresarial debe crear diferentes vistas de arquitectura del Negocio, Sistemas de Información y
Arquitectura de Tecnología para las partes interesadas que tienen inquietudes relacionadas con estos aspectos.
El estándar TOGAF identifica específicamente este problema en todo el ADM a través de los siguientes conceptos (consulte el estándar
TOGAF: contenido de la arquitectura):
ÿ Vista de arquitectura
ÿ Mirador de la arquitectura
ÿ Preocupación
ÿ Parte interesada
3.3 Pasos en el Proceso de Gestión de Partes Interesadas

Las siguientes secciones detallan la actividad recomendada de gestión de las partes interesadas.
3.3.1 Identificar a las partes interesadas

Identificar las partes interesadas clave de la arquitectura empresarial.
La primera tarea es averiguar quiénes son los principales interesados en Arquitectura Empresarial. Como parte de esto, piense en todas
las personas que se ven afectadas por él, que tienen influencia o poder sobre él, o tienen interés en su conclusión exitosa o no exitosa.
Puede incluir altos ejecutivos, roles de organización de proyectos, roles de organización de clientes, desarrolladores de sistemas, socios
de alianzas, proveedores, operaciones de TI, clientes, etc.
Al identificar a las partes interesadas, existe el peligro de concentrarse demasiado en la estructura formal de una organización como base
para la identificación. Los grupos informales de partes interesadas pueden ser tan poderosos e influyentes como los formales.
La mayoría de las personas pertenecerán a más de un grupo de partes interesadas, y estos grupos tienden a surgir como resultado de
eventos específicos.
Mire quién se ve afectado por el proyecto Enterprise Architecture:
ÿ ¿Quién gana y quién pierde con este cambio? ÿ ¿Quién controla
la gestión de cambios de los procesos? ÿ ¿Quién diseña nuevos sistemas?
ÿ ¿Quién tomará las decisiones?
ÿ ¿Quién adquiere los sistemas de TI y quién decide qué comprar?
ÿ ¿Quién controla los recursos?
ÿ ¿Quién tiene las habilidades especializadas que necesita el proyecto?
ÿ ¿Quién tiene influencia?
En particular, es necesario identificar a los influencers. Estos serán muy respetados y ascenderán, participarán en reuniones y comités
importantes (mirar las actas de las reuniones), sabrán lo que está pasando en la empresa, serán valorados por sus pares y superiores, y
no necesariamente estarán en cualquier formalidad.

Gestión de los interesados Pasos en el Proceso de Gestión de Partes Interesadas
posición de poder.
Aunque las partes interesadas pueden ser tanto organizaciones como personas, en última instancia, el equipo de
Arquitectura Empresarial deberá comunicarse con las personas. Son las partes interesadas individuales correctas dentro
de una organización de partes interesadas las que deben identificarse formalmente.
3.3.1.1 Ejemplo de análisis de partes interesadas
En la Figura 3-1 se muestra un análisis de muestra de las partes interesadas que distingue 22 tipos de partes
interesadas, en cinco categorías amplias . Cualquier proyecto de arquitectura en particular puede tener más, menos o
diferentes partes interesadas; y pueden agruparse en más, menos o diferentes categorías.
Funciones corporativas
CxO
Empresa Programa Control de calidad/Estándares

Obtención HORA
Seguridad Oficina de Administración Grupos
Usuario final Proyecto Sistema

Organización Organización Operaciones
Servicio de TI
Ejecutivos
Ejecutivos administración
Manejo de linea Servicio de mesa

Manejo de linea
Procesos de negocio/ Solicitud
Dominio de negocio Expertos funcionales administración
Expertos
Infraestructura
especialista en productos
administración
Propietarios de datos
Datos/Voz
Especialista Técnico
Comunicaciones
Proveedores Cuerpos reguladores
Externo
© El Grupo Abierto
Figura 3-1 Muestra de partes interesadas y categorías
Considere tanto el equipo visible (aquellos obviamente asociados con el proyecto/cambio) como el equipo invisible
(aquellos que deben hacer una contribución real al proyecto/cambio para que tenga éxito pero que no están obviamente
asociados con él (p. ej., proveedores de servicios de apoyo). vicios).

Pasos en el Proceso de Gestión de Partes Interesadas Gestión de los interesados
3.3.2 Clasificar las posiciones de las partes interesadas
Desarrollar una buena comprensión de las partes interesadas más importantes y registrar este análisis para
referencia y actualización durante el proyecto. Un ejemplo de análisis de partes interesadas se muestra en la Tabla
3-1.
Capacidad para Actual Requerido Actual Requerido

Interesado Interrumpir Bajo- Bajo- Compromiso- Compromiso- Requerido
Cambio de parte interesada del grupo permanente permanente Apoyo técnico
director de información John Smith HML H METRO
director de Finanzas jeff marrón MMM L METRO METRO
Tabla 3-1 Ejemplo de análisis de partes interesadas
También es importante evaluar la disposición de cada parte interesada a comportarse de manera poco solidaria.
(es decir, demostrar compromiso con la iniciativa Enterprise Architecture).
Esto se puede hacer haciendo una serie de preguntas:
ÿ ¿Está esa persona lista para cambiar de dirección y comenzar a moverse hacia el objetivo?
¿Arquitectura? Si es así, ¿qué tan listo?
ÿ ¿Es esa persona capaz de ser un defensor o agente creíble de la Empresa propuesta?
¿Iniciativa de arquitectura? Si es así, ¿qué tan capaz?
ÿ ¿Qué tan involucrada está la persona en la iniciativa de Arquitectura Empresarial? ¿Son simplemente un
observador interesado, o necesitan estar involucrados en los detalles?
ÿ ¿Ha contraído esa persona un compromiso contractual con el desarrollo de la Empresa?

Arquitectura, y su papel en la gobernanza del desarrollo de la organización?
Luego, para cada persona cuyo compromiso es crítico para asegurar el éxito, haga un juicio en cuanto a
su nivel actual de compromiso y el nivel futuro deseado de compromiso.
3.3.3 Determinar el enfoque de gestión de las partes interesadas
Los pasos anteriores identificaron una larga lista de personas y organizaciones que se ven afectadas por la
Participar proyecto de arquitectura premio.
Algunos de estos pueden tener el poder de bloquear o avanzar. Algunos pueden estar interesados en lo que
la iniciativa Enterprise Architecture está haciendo; a otros puede no importarles. Este paso permite al equipo
ver fácilmente qué partes interesadas se espera que bloqueen o critiquen, y qué partes interesadas son
probable que sean defensores y partidarios de la iniciativa.
Calcule el poder, la influencia y el interés de las partes interesadas, a fin de enfocar la arquitectura empresarial
participación de las personas clave. Estos pueden mapearse en una matriz de poder/interés, que
también indica la estrategia a adoptar para relacionarse con ellos. La Figura 3-2 muestra un ejemplo de potencia
matriz de cuadrícula.
24 El estándar de grupo abierto (2022)

Gestión de los interesados Pasos en el Proceso de Gestión de Partes Interesadas
© El Grupo Abierto
C D
Alto Mantener satisfecho Jugadores claves. Jugadores principales
Energía
A B
Bajo
Esfuerzo mínimo Mantenerse informado
Bajo Alto
Nivel de interes
Figura 3-2 Red eléctrica de las partes interesadas
3.3.4 Compromiso a la medida Entregables

Identifique catálogos, matrices y diagramas que el compromiso de la arquitectura necesita producir y validar con cada grupo de partes
interesadas para entregar un modelo de arquitectura efectivo.
Es importante prestar especial atención a los intereses de las partes interesadas mediante la definición de catálogos, matrices y
diagramas específicos que sean relevantes para un modelo de arquitectura empresarial en particular. Esto permite que la arquitectura
sea comunicada y entendida por todas las partes interesadas, y les permite verificar que la iniciativa Enterprise Architecture abordará
sus preocupaciones.
3.4 Modelo de mapa de partes interesadas

La siguiente tabla proporciona un ejemplo de mapa de partes interesadas para un proyecto de arquitectura TOGAF que tiene partes
interesadas identificadas en la Figura 3-1.

Plantilla de mapa de partes interesadas Gestión de los interesados
Catálogos, Matrices y
Stakeholder Preocupaciones Clase Diagramas
CxO (Funciones clave Los impulsores, metas MANTENER Diagrama int de huella empresarial
corporativas); por y objetivos de alto nivel de la SATISFECHO
Meta/Objetivo/Negocio
ejemplo, CEO, CFO, organización, y cómo se traducen en
Diagrama de servicio
CIO, COO un proceso efectivo y una arquitectura
de TI para hacer avanzar el negocio. Diagrama de descomposición de la
organización
Catálogo de capacidades
comerciales
Matriz de capacidad/organización
Mapa de capacidad empresarial
Matriz de estrategia/capacidad
diagrama de modelo de negocio
Catálogo de flujo de valor
Catálogo de etapas del flujo

de valor
Matriz de flujo de valor/capacidad
Mapa de flujo de valor

Gestión de los interesados Plantilla de mapa de partes interesadas
Interesado Preocupaciones Clase Diagramas
Oficina de clave Priorizar, financiar y alinear MANTENER Catálogo de requisitos

Gestión de Programas la actividad de cambio. Una comprensión SATISFECHO
Diagrama de contexto del proyecto
(Funciones Corporativas); del contenido del proyecto y las
por ejemplo, gerentes de dependencias técnicas entre proyectos Diagrama de beneficios
cartera de proyectos respalda la toma de decisiones de
Diagrama int de huella empresarial
gestión de cartera.
Aplicación Diagrama de comunicación
Mapa de organización
comerciales

de valor

Compras Comprender qué componentes básicos LLAVE Catálogo de Portafolio de Tecnología
(Funciones de la arquitectura se pueden comprar y JUGADORES
Catálogo de estándares
Corporativas); por qué restricciones (o reglas) son relevantes
tecnológicos
ejemplo, adquirentes para la compra.
Los adquirentes comprarán con

múltiples proveedores en busca de la
mejor solución de costo mientras se
adhieren a las restricciones (o reglas)

derivadas de la arquitectura, como los
estándares. La preocupación clave es
tomar decisiones de compra que se
ajusten a la arquitectura.

Recursos Humanos clave Se requieren roles y actores MANTENER Descomposición de la organización
(RRHH) para respaldar la arquitectura y diagrama INFORMADO
(Funciones los cambios en ella. La preocupación
Catálogo de organizaciones/actores
corporativas); clave es gestionar las transiciones de
por ejemplo, gerentes de las personas. Catálogo de ubicaciones
recursos humanos, gerentes
Aplicación y Usuario
de capacitación y desarrollo
Diagrama de ubicación
comerciales

Seguridad empresarial Garantizar que (la información, LLAVE Diagrama del ciclo de vida del producto
los datos y las funciones de lade
empresa);
la organización,
Los sistemas
por JUGADORES
Diagrama de difusión de datos
ejemplo, Riesgo Corporativo, están
Gerencia,
disponibles
que tiene
solo
permiso,
para la y los
Oficiales de Seguridad, TI quelos
protegen
Gerentes
la información,
de Seguridadlosy datos
los de Diagrama de seguridad de datos
sistemas contra la manipulación no autorizada.
Matriz actor/rol
Computación en red
Diagrama de hardware
Red k y
Diagrama de comunicaciones

Grupo de QA/ Preocupaciones Clase Diagramas
Estándares de Partes clave Garantizar el gobierno LLAVE Proceso/Evento/
Interesadas (Funciones coherente de los activos de JUGADORES Control/Catálogo de productos
Corporativas); p. ej., negocios, datos, aplicaciones y
Catálogo de contratos/medidas
propietarios de datos, tecnología de la organización.
propietarios de procesos, Catálogo de la cartera de aplicaciones
organismos de estándares
Catálogo de interfaces
técnicos
tecnológicos
Catálogo de Portafolio de Tecnología

de valor

Interesado Inquietudes clave Clase Diagramas
Ejecutivo Los impulsores, metas y MANTENER Diagrama int de huella empresarial
(Organización objetivos de alto nivel de la SATISFECHO
Meta/Objetivo/Negocio
de usuarios finales); organización, y cómo estos se
Diagrama de servicio
por ejemplo, directores de traducen en un proceso y una
unidades de negocios, CxO arquitectura efectivos para hacer Diagrama de descomposición de la
de unidades de negocios, avanzar el negocio. organización
jefes de TI/arquitectura de
Diagrama de flujo del proceso
unidades de negocios
comerciales

de valor

Gestión de línea clave Funciones y procesos de LLAVE Diagrama int de huella empresarial
(Organización de usuarios nivel superior de la organización, JUGADORES
Diagrama de descomposición de la
finales); por ejemplo, y cómo las aplicaciones clave
organización
gerentes comerciales respaldan estos procesos.
sénior, gerentes Mapa de organización
regionales de operaciones,
Diagrama de flujo del proceso
gerentes de TI
comerciales

de valor

Expertos en dominios clave Aspectos funcionales LLAVE Matriz de interacción comercial
de negocios (Organización de los procesos y sistemas de JUGADORES
Matriz actor/rol
de usuarios finales); por apoyo. Esto puede cubrir los actores
ejemplo, expertos en humanos involucrados en el sistema, Servicio empresarial/
procesos de negocios, los procesos de usuario involucrados Diagrama de información
analistas de negocios/ en el sistema, las funciones requeridas
procesos, arquitectos de para respaldar los procesos y la
procesos, diseñadores información requerida para fluir en Diagrama del ciclo de vida del producto
de procesos, gerentes apoyo de los procesos.
Diagrama de casos de uso
funcionales, analistas de
empresarial
negocios
Diagrama de caso de uso de
la aplicación
Entidad de datos/Negocio
Matriz de funciones

de valor

Gestión de Garantizar que los servicios de TI MANTENER Estándares tecnológicos
Servicios TI proporcionados a la organización catálogo INFORMADO
(Operaciones de cumplan con los niveles de servicio
Catálogo de Portafolio de Tecnología
Sistemas); p. ej., requeridos por esa organización para
gerente de entrega tener éxito en los negocios. Catálogo de contratos/medidas
de servicios
Proceso/Solicitud
Diagrama de realización
Diagrama de manejabilidad de premios

empresariales

Operaciones de Preocupaciones Clase Diagramas
TI de las partes clave Enfoque de desarrollo, LLAVE Proceso/Solicitud
interesadas — modularidad y reutilización de JUGADORES Diagrama de realización
Aplicaciones software, portabilidad, migración e
Aplicación/matriz de datos
(Operaciones del interoperabilidad.
sistema); por ejemplo, Diagrama de migración de
arquitectura de aplicaciones
aplicaciones, ingenieros de
Diagrama de ingeniería de
sistemas y software
software
Descomposición de plataforma
Diagrama
Computación en red/
Distribución de software
Diagrama
Operaciones de TI — Ubicación, modificabilidad, LLAVE Diagrama de descomposición de
Infraestructura reutilización y disponibilidad de todos JUGADORES la plataforma
(Operaciones del los componentes del sistema.
sistema); p. ej., Garantizar que los componentes
tecnológicos
arquitecto de apropiados se desarrollen y desplieguen
infraestructura, soporte dentro del sistema de manera óptima. Catálogo de Portafolio de Tecnología
de Wintel, soporte de rango
Diagrama de manejabilidad de premios
medio, DBA operativo,
empresariales
mesa de servicio
Computación en red/
Diagrama de procesamiento
Diagrama de entornos y ubicaciones
Operaciones de TI — Ubicación, modificabilidad, LLAVE Red k y

Comunicaciones de reutilización y disponibilidad de los JUGADORES Diagrama de comunicaciones
datos/voz (Operaciones servicios de comunicaciones y redes.
del sistema); p. ej.,

Gestión de red Garantizar que los
servicios de comunicaciones y redes
apropiados se desarrollen e implementen
dentro del sistema de manera óptima.

Ejecutivo clave Entrega a tiempo y dentro del MANTENER Catálogo de requisitos
(Organización presupuesto de una iniciativa de cambio INFORMADO
Catálogo de principios
de Proyectos); p. que generará los beneficios esperados
ej., patrocinador, para la organización. Diagrama de cadena de valor
administrador del programa
Diagrama del concepto de solución
comerciales

de valor

Gestión de Línea clave Lograr operativamente la MANTENER Comunicación de la aplicación
(Organización de entrega a tiempo y dentro del diagrama INFORMADO
Proyectos); por ejemplo, presupuesto de una iniciativa de
Gerente de Proyecto cambio con un alcance acordado.
Diagrama de entornos y ubicaciones
comerciales

de valor

Proceso de clave Agregar más detalles a los LLAVE Diagrama de flujo del proceso
negocio/experto funcional requisitos funcionales de una iniciativa JUGADORES
Diagrama de casos de uso
(organización de proyectos); de cambio basada en la experiencia y
empresarial
p. ej., consultor funcional la interacción con expertos en el
de finanzas FICO® , dominio comercial en la organización Negocio
consultor funcional de del usuario final. Diagrama de servicio/información
recursos humanos
comerciales

de valor

Especialista de Producto Especificar diseños de LLAVE Diagrama de ingeniería de
(Organización de productos de tecnología para cumplir JUGADORES software
Proyectos); p. ej., con los requisitos del proyecto y
especialista en productos cumplir con la Visión de Arquitectura
de portal de la solución.
En un entorno de
paquetes y servicios
empaquetados, la experiencia
del producto se puede utilizar para
identificar las capacidades del
producto que se pueden aprovechar
fácilmente y pueden proporcionar
orientación sobre estrategias para la
personalización del producto.

Interesado Preocupaciones clave Especialista técnico Clase Diagramas
Especificación de tecnología (diseños de de

con el fin productos del proyecto
Organización); LLAVE Diagrama de ingeniería de
cumplir con los requisitos del proyecto,
y cumplirpor
conejemplo,
la visiónlade
aplicación
la arquitectura JUGADORES software
de la solución Architect.
Diagrama de descomposición de
la plataforma
Proceso/Solicitud
Diagrama de realización
Diagrama de migración de
aplicaciones
Organismos Reguladores Recibir la información que necesiten MANTENER Diagrama int de huella empresarial
(Servicios Externos); p. ej., para regular la organización cliente, SATISFECHO
regulador financiero, y asegurarse de que sus
regulador de la industria requerimientos de información sean
debidamente satisfechos. Interesado
en los procesos de generación de

informes y los datos y las aplicaciones
que se utilizan para proporcionar

información reglamentaria sobre
declaraciones.

Proveedores de Preocupaciones Clase Diagramas
Partes Interesadas clave Garantizar que se MANTENER Diagrama int de huella empresarial
(Servicios Externos); p. cumplan los requisitos de SATISFECHO
Negocio
ej., socios de la alianza, intercambio de información para
Diagrama de servicio/información
proveedores clave poder cumplir los contratos de
servicio acordados con las Aplicación Diagrama de comunicación
organizaciones cliente.
comerciales

de valor

Capítulo 4: Patrones de arquitectura
Este capítulo proporciona pautas para el uso de patrones de arquitectura.
4.1 Introducción
Los patrones para describir las arquitecturas empresariales se están volviendo cada vez más importantes para los
profesionales. La naturaleza diversa y multidisciplinaria de Enterprise Architecture requiere que los patrones se
desarrollen en diferentes disciplinas, dominios y niveles de detalle.
Las versiones anteriores de este estándar no adoptaron completamente los patrones de arquitectura debido a su
percepción de falta de madurez. Hoy en día, muchas organizaciones utilizan patrones para describir sus arquitecturas
en varios niveles, desde patrones de diseño de software hasta patrones comerciales. Sigue siendo cierto que no existe
un estándar único para describir los patrones de arquitectura empresarial.
Sin embargo, se puede decir que existe un patrón para describir patrones.
4.1.1 Antecedentes
Un "patrón n" se ha definido como: "una idea que ha sido útil en un contexto práctico y probablemente lo será en
otros" (Fuente: Analysis Patterns — Re-usable Object Models, por M.
cazador).
En el estándar TOGAF, los patrones se consideran una forma de contextualizar los componentes básicos; por ejemplo,
para describir una solución reutilizable a un problema. Los bloques de construcción son lo que usas: los patrones
pueden decirte cómo los usas, cuándo, por qué y qué compensaciones tienes que hacer al hacerlo. Los patrones
ofrecen la promesa de ayudar al arquitecto a identificar combinaciones de Arquitectura y/o Bloques de Construcción de
Soluciones (ABBs/SBBs) que han demostrado ofrecer soluciones efectivas en el pasado y pueden proporcionar la base
para soluciones efectivas en el futuro.
En general, se reconoce que las técnicas de patrones fueron establecidas como una valiosa técnica de diseño
arquitectónico por Christopher Alexander, un arquitecto de edificios, quien describió este enfoque en su libro The
Timeless Way of Building, publicado en 1979. Este libro proporciona una introducción a las ideas detrás de el uso de
patrones, y Alexander lo siguió con otros dos libros (A Pattern n Language y The Oregon Experiment) en los que amplió
su descripción de las características y beneficios de un enfoque de patrones para la arquitectura.
Los arquitectos de software y edificios tienen muchos problemas similares que abordar, por lo que era natural que los
arquitectos de software se interesaran en los patrones como herramienta arquitectónica. Se han publicado muchos
artículos y libros sobre ellos desde el libro de Alexander de 1979, quizás el más renombrado sea Design Patterns:
Elements of Re-usable Object-Oriented Software (Gamma et al., 1994).
Este libro describe soluciones simples y elegantes a problemas específicos en el diseño de software orientado a objetos.

Introducción Patrones de arquitectura
4.1.2 Contenido de un Patrón

En la literatura se utilizan varios formatos diferentes para describir patrones, y ningún formato único ha logrado una amplia
aceptación. Sin embargo, existe un amplio acuerdo sobre los tipos de elementos que debe contener un patrón. Los
encabezados que siguen están tomados de Pattern n-Oriented Software Architecture: A System of Patterns (Buschmann et
al., 1996). Los elementos que se describen a continuación se encontrarán en la mayoría de los patrones, incluso si se usan
diferentes encabezados para describirlos.
Nombre Una forma significativa y memorable de referirse al patrón, generalmente una sola palabra o frase corta.
Problema Una descripción del problema que indica la intención de aplicar el patrón: las metas y los objetivos que se
pretende alcanzar dentro del contexto y las fuerzas que se describen a continuación (quizás con alguna
indicación de sus prioridades).
Contexto Las condiciones previas bajo las cuales se aplica el patrón: una descripción del estado inicial antes de que
se aplique el patrón.
Efectivo Una descripción de las fuerzas y limitaciones relevantes, y cómo interactúan o entran en conflicto entre sí
y con las metas y objetivos previstos. La descripción debe aclarar las complejidades del problema y hacer
explícitos los tipos de compensaciones que deben considerarse. (La necesidad de tales compensaciones
es típicamente lo que dificulta el problema y genera la necesidad del patrón en primer lugar). La noción de
"fuerzas" equivale en muchos sentidos a las "cualidades" que los arquitectos buscan optimizar, y las
preocupaciones que buscan abordar, en el diseño de arquitecturas. Por ejemplo:
— Seguridad, solidez, fiabilidad, tolerancia a fallos
— Manejabilidad
— Eficiencia, rendimiento, rendimiento, requisitos de ancho de banda, espacio

utilización
— Escalabilidad (crecimiento incremental bajo demanda)
— Extensibilidad, capacidad de evolución, mantenibilidad
— Modularidad, independencia, reutilización, apertura, componibilidad (plug and play), portabilidad
— Integridad y corrección
— Facilidad de construcción
- Facilidad de uso
- etc., .. .
Solución Una descripción, utilizando texto y/o gráficos, de cómo lograr las metas y objetivos previstos. La descripción debe
identificar tanto la estructura estática de la solución como su comportamiento dinámico: las personas y los
actores informáticos, y sus colaboraciones.
La descripción puede incluir pautas para implementar la solución. También se pueden describir variantes
o especializaciones de la solución.
Contexto resultante
Las condiciones posteriores después de que se haya aplicado el patrón. La implementación de la solución
normalmente requiere compensaciones entre fuerzas en competencia.

redistribución
Patrones de arquitectura Introducción
Este elemento describe qué fuerzas se han resuelto y cómo, y cuáles permanecen sin resolver. También puede
indicar otros patrones que pueden ser aplicables en el nuevo contexto. (Un patrón puede ser un paso para
lograr un objetivo mayor). Cualquier otro patrón se describirá en detalle en Patrones relacionados.
Ejemplos Una o más aplicaciones de muestra del patrón que ilustran cada uno de los otros elementos: un problema específico,
contexto y conjunto de fuerzas; cómo se aplica el patrón; y el contexto resultante.
Justificación Una explicación/justificación del patrón como un todo, o de los componentes individuales dentro de él, que indica
cómo funciona realmente el patrón y por qué, cómo resuelve las fuerzas para lograr las metas y objetivos
deseados, y por qué esto es "bueno". . El elemento Solución de un patrón describe la estructura externa y el
comportamiento de la solución: el Justificación proporciona información sobre su funcionamiento interno.
Patrones relacionados
Las relaciones entre este patrón y otros. Estos pueden ser patrones predecesores, cuyos contextos resultantes
corresponden al contexto inicial de este; o patrones sucesores, cuyos contextos iniciales corresponden al
contexto resultante de éste; o patrones alternativos, que describen una solución diferente al mismo problema,
pero bajo diferentes fuerzas; o patrones codependientes, que pueden/deben aplicarse junto con este patrón.
Usos conocidos Aplicaciones conocidas del patrón dentro de los sistemas existentes, verificando que el patrón de hecho describe
una solución comprobada para un problema recurrente. Los usos conocidos también pueden servir como
ejemplos.
Los patrones también pueden comenzar con un resumen que brinda una descripción general del patrón e indica los tipos de
problemas que aborda. El resumen también puede identificar la audiencia objetivo y qué suposiciones se hacen del lector.
4.1.3 Terminología
Aunque los patrones de diseño han sido el centro de interés generalizado en la industria del software durante varios años,
particularmente en los campos del software orientado a objetos y basado en componentes, solo recientemente ha habido un
interés creciente en los patrones de arquitectura, extendiendo los principios. y conceptos de patrones de diseño al dominio de la
arquitectura.
La literatura técnica relacionada con este campo se complica por el hecho de que muchas personas en el campo del software
usan el término "arquitectura" para referirse al software, y muchos patrones descritos como "patrones de arquitectura" son
patrones de diseño de software de alto nivel. Esto simplemente hace que sea aún más importante ser preciso en el uso de la
terminología.
4.1.3.1 Patrones de arquitectura y patrones de diseño
El término "patrón de diseño" se usa a menudo para referirse a cualquier patrón que aborde problemas de arquitectura de
software, diseño o implementación de programación. En Arquitectura de software orientada a patrones: un sistema de patrones,
los autores definen estos tres tipos de patrones de la siguiente manera:
ÿ Un Patrón de Arquitectura expresa una organización o esquema estructural fundamental para

sistemas de software
Proporciona un conjunto de subsistemas predefinidos, especifica sus responsabilidades e incluye reglas y pautas para
organizar las relaciones entre ellos.

Introducción Patrones de arquitectura
ÿ Un patrón de diseño proporciona un esquema para refinar los subsistemas o componentes de un

sistema de software, o las relaciones entre ellos Describe una
estructura comúnmente recurrente de componentes comunicantes que resuelve un problema de diseño general dentro
de un contexto particular.
ÿ Un modismo es un patrón de bajo nivel específico de un lenguaje de programación
Un modismo describe cómo implementar aspectos particulares de los componentes o las relaciones entre ellos usando
las características del lenguaje dado.
Estas distinciones son útiles, pero es importante tener en cuenta que los patrones de arquitectura en este contexto todavía se
refieren únicamente a la arquitectura del software. La arquitectura de software es sin duda una parte importante del enfoque
del estándar TOGAF, pero no es su único enfoque.
En esta sección nos ocupamos de los patrones para la arquitectura de sistemas empresariales. Estos son análogos a la
arquitectura de software y los patrones de diseño, y toman prestados muchos de sus conceptos y terminología, pero se
enfocan en proporcionar modelos y métodos reutilizables específicamente para la arquitectura de sistemas de información
empresarial, que incluyen software, hardware, redes y personas, a diferencia de los sistemas puramente de software.
4.1.3.2 Patrones y el continuo de la arquitectura
Aunque los patrones de arquitectura no se han integrado (todavía) en el estándar TOGAF, cada una de las primeras cuatro
fases principales del ADM (fases A a D) da una indicación de la etapa en la que los activos de arquitectura reutilizables
relevantes de la empresa. Se debe considerar el uso de Architecture Continuum. Los patrones de arquitectura son uno de
esos activos.
Una empresa que adopta un enfoque formal para el uso y la reutilización de patrones de arquitectura normalmente integrará
su uso en el Continuo de arquitectura empresarial.
4.1.3.3 Patrones y Vistas
Las vistas de arquitectura son partes seleccionadas de uno o más modelos que representan una arquitectura de sistema
completa, centrándose en aquellos aspectos que abordan las preocupaciones de una o más partes interesadas.
Los patrones pueden proporcionar ayuda en el diseño de dichos modelos y en la composición de vistas basadas en ellos.
4.1.3.4 Patrones y escenarios comerciales
Es posible que se identifiquen patrones de arquitectura relevantes en el trabajo sobre escenarios empresariales.
4.2 Algunos recursos de patrones

ÿ La página de inicio de Patterns (consulte hillside.net/patterns) alojado por Hillside Group proporciona información sobre
patrones, enlaces a patrones en línea, documentos y libros que tratan sobre patrones y listas de correo relacionadas
con patrones
ÿ Preguntas frecuentes sobre la discusión de patrones (consulte http://pur l.org/theopengroup/pd-FAQ) mantenido por
Doug Lea proporciona preguntas frecuentes muy completas y fáciles de leer sobre patrones
ÿ Patrones y software: Conceptos esenciales y terminología por Brad Appleton (consulte www.bradapp.com/docs/patterns-
intro.html) proporciona otra descripción completa y legible del campo de patrones

redistribución
Patrones de arquitectura Algunos recursos de patrones
ÿ El sitio web de la comunidad de patrones de arquitectura orientada a servicios (SOA) (consulte

www.soapatterns.org/), dedicado al desarrollo y expansión continuos de SOA
catálogo de patrones de diseño
ÿ El sitio web de la comunidad Cloud Computing Design Patterns (consulte a

www.cloudpatterns.org)

Patrones de arquitectura

redistribución
Capítulo 5: Análisis de brechas
La técnica conocida como análisis de brechas es ampliamente utilizada en el Método de Desarrollo de Arquitectura TOGAF (ADM) para validar una
arquitectura que se está desarrollando. La premisa básica es resaltar un déficit entre la Arquitectura de referencia y la Arquitectura de destino; es decir,
elementos que se han omitido deliberadamente, se han omitido accidentalmente o aún no se han definido.
5.1 Introducción
Un paso clave en la validación de una arquitectura es considerar lo que puede haberse olvidado. La arquitectura debe admitir todas las
necesidades esenciales de procesamiento de información de la organización.
La fuente más crítica de brechas que deben considerarse son las preocupaciones de las partes interesadas que no se han abordado en trabajos
arquitectónicos anteriores.
Las posibles fuentes de brechas incluyen:
ÿ Brechas de dominio empresarial:
— Brechas de personas (p. ej., requisitos de capacitación cruzada)
— Brechas del proceso (p. ej., ineficiencias del proceso)
— Brechas de herramientas (p. ej., funcionalidad de herramienta duplicada o faltante)
— Lagunas de información
— Brechas de medición
— Brechas financieras
— Brechas en las instalaciones (edificios, oficinas, etc.)
ÿ Brechas de dominio de datos:
— Datos no de suficiente vigencia
— Datos no ubicados donde se necesitan
— No los datos que se necesitan
— Los datos no están disponibles cuando se necesitan
— Datos no creados
— Datos no consumidos
— Lagunas en la relación de datos

Introducción Análisis de las deficiencias
ÿ Aplicaciones afectadas, eliminadas o creadas
ÿ Tecnologías impactadas, eliminadas o creadas
5.2 Pasos sugeridos

Los pasos sugeridos son los siguientes:
ÿ Dibuje una matriz con todas las ABB de la arquitectura de referencia en el eje ver tical y todas las ABB de la
arquitectura objetivo en el eje horizontal
ÿ Agregue al eje Arquitectura de línea de base una fila final etiquetada como "Nuevo" y al eje Objetivo
Eje de arquitectura una columna final etiquetada como "Eliminado"
ÿ Cuando un ABB esté disponible tanto en la arquitectura de referencia como en la de destino, regístrelo con
"Incluido" en la celda de intersección
ÿ Cuando falta un ABB de la Arquitectura de referencia en la Arquitectura de destino, cada

debe ser revisado
Si se eliminó correctamente, márquelo como tal en la celda "Eliminado" correspondiente. Si no fue así, se ha
descubierto una omisión accidental en la arquitectura de destino que debe abordarse mediante el restablecimiento
de ABB en la siguiente iteración del diseño de la arquitectura; márquelo como tal en la celda "Eliminada"
correspondiente.
ÿ Cuando no se pueda encontrar un ABB de la arquitectura de destino en la arquitectura de referencia, márquelo

en la intersección con la fila "Nueva" como un vacío que debe llenarse, ya sea mediante el desarrollo o la
adquisición del bloque de construcción.
Cuando se completa el ejercicio, cualquier cosa bajo "Eliminado" o "Nuevo" es una brecha, que debe explicarse como
eliminada correctamente o marcarse para ser abordada al restablecer o desarrollar/adquirir el bloque de construcción.
5.3 Ejemplo
La Figura 5-1 muestra un análisis de ejemplo para ABB que son servicios de la categoría de Servicios de Red del
Modelo de Referencia Técnica (TRM) de TOGAF, y muestra una cantidad de servicios de la Arquitectura de referencia
que faltan en la Arquitectura de destino.

redistribución
Análisis de las deficiencias Ejemplo
Objetivo
Arquitectura Video Mejorado
Lista de correo eliminado
Base conferencias Telefonía
Servicios Servicios Servicios Servicios
Arquitectura
Transmisión eliminado
Servicios intencionalmente
Video
conferencias Incluido
Servicios
Mejorado
Telefonía Coincidencia potencial
Servicios
Excluido
Pantalla compartida involuntariamente:
Servicios una brecha en Target
Arquitectura
Brecha: Servicios Brecha: Para

mejorados a ser ser desarrollado
Nuevo
desarrollados o o producido
producidos
© El Grupo Abierto
Figura 5-1 Ejemplo de análisis de brechas

Análisis de las deficiencias

redistribución
Capítulo 6: Técnicas de planificación de la migración
Este capítulo contiene una serie de técnicas utilizadas para respaldar la planificación de la migración en las Fases E y F.
6.1 Catálogo de Factores de Implementación

La técnica de crear un catálogo de factores de implementación se puede utilizar para documentar los factores que afectan el plan de
implementación y migración de la arquitectura.
El catálogo debe incluir una lista de los factores a considerar, sus descripciones y las deducciones que indican las acciones o restricciones
que deben tenerse en cuenta al formular los planes.
Los factores típicamente incluyen:
ÿ Riesgos
ÿ Problemas
ÿ Suposiciones
ÿ Dependencias
ÿ Acciones
ÿ Impactos
En la Figura 6-1 se muestra un catálogo de ejemplo .
Catálogo de Factores de Implementación
Factor Descripción Deducción
<Nombre del factor> <Descripción del factor> <Impacto en el Plan de Migración>
Cambio en la tecnología Cierre los centros de • Necesidad de

mensajes, ahorre 700 capacitación del personal,
empleados y reemplácelos reasignación • El correo
por correo electrónico. electrónico tiene importantes
ahorros de personal y se le debe dar prioridad
Consolidación de Servicios
Introducción de nuevos
Servicio al Cliente
© El Grupo Abierto
Figura 6-1 Catálogo de factores de implementación

Catálogo de Factores de Implementación Técnicas de planificación de la migración
6.2 Matriz consolidada de brechas, soluciones y dependencias

La técnica de crear una matriz consolidada de brechas, soluciones y dependencias permite al arquitecto agrupar las
brechas identificadas en los resultados del análisis de brechas de la arquitectura del dominio y evaluar posibles
soluciones y dependencias para una o más brechas.
Esta matriz se puede utilizar como herramienta de planificación al crear paquetes de trabajo. Las dependencias
identificadas impulsarán la creación de proyectos y la planificación de la migración en las Fases E y F.
En la Figura 6-2 se muestra un ejemplo de matriz .
Matriz consolidada de brechas, soluciones y dependencias
No. Arquitectura Brecha Soluciones potenciales dependencias
1 Negocio Procesamiento de nuevos pedidos Utilice la herramienta de software COTS Aplicaciones de accionamientos (2)
Proceso proceso
Implementar una solución
personalizada
2 Solicitud Procesamiento de nuevos pedidos Herramienta de software COTS X
Solicitud Desarrollar internamente
3 Información Cliente Consolidado Usar la base de clientes

Base de información de COTS
Desarrollar data mart de
clientes
© El Grupo Abierto
Figura 6-2 Matriz consolidada de brechas, soluciones y dependencias
6.3 Tabla de incrementos de definición de arquitectura

La técnica de crear una tabla de Incrementos de definición de arquitectura permite al arquitecto planificar una serie de
Arquitecturas de transición que describen el estado de la Arquitectura empresarial en momentos específicos.
Se debe elaborar una tabla, como se muestra en la Figura 6-3, enumerando los proyectos y luego asignando sus
entregables incrementales a través de las Arquitecturas de Transición.

redistribución
Técnicas de planificación de la migración Tabla de incrementos de definición de arquitectura
Definición de Arquitectura - Objetivos del Proyecto por Incremento

(Solo ejemplo)
Abril 2018/2019 Abril 2019/2020 Abril 2020/2021
Transición
Transición Arquitectura 2: Transición
Arquitectura 1: Operativo Inicial Arquitectura 3:
Proyecto Preparación Beneficios Comentarios
Capacidad
Empresa Formación y Negocios Licencias electrónicas e-empleo

e-servicios Proceso Capacidad Beneficios
Capacidad
Formularios electrónicos de TI
Diseño y construcción
Información electrónica de TI Diseño y construcción Datos comunes del cliente Empresa común
Ambiente Información Contenido web Componente de datos
Ambiente Diseño y construcción administración
Diseño y construcción
. . . . . . . .. .. . . . .
© El Grupo Abierto
Figura 6-3 Tabla de incrementos de definición de arquitectura
6.4 Tabla de evolución del estado de la arquitectura de transición

La técnica de crear la tabla de Evolución del Estado de la Arquitectura de Transición le permite al arquitecto
mostrar el estado propuesto de las arquitecturas en varios niveles utilizando la taxonomía definida (p. ej.,
el TOGAF TRM).
Se debe dibujar una tabla que enumere los servicios de la taxonomía utilizada en la empresa, el
Arquitecturas de transición y transformaciones propuestas, como se muestra en la Figura 6-4.
Todos los SBB deben describirse con respecto a su entrega e impacto en estos servicios. Ellos
también debe marcarse para mostrar la progresión de la arquitectura empresarial. En el ejemplo,
donde se ha alcanzado la capacidad objetivo, esto se muestra como "nuevo" o "retener"; donde esta la capacidad
en transición a una nueva solución, esto se marca como "transición"; y donde una capacidad debe ser
reemplazado, esto se marca como "reemplazar".
Estado Arquitectónico utilizando el Modelo Técnico de Referencia
Transición Transición Transición

Subdominio Servicio
Arquitectura 1 Arquitectura 2 Arquitectura 3
Infraestructura Información Solución Sistema A Solución Sistema B-1 Solución Sistema B-2
Aplicaciones Servicios de intercambio (reemplazar) (transición) (nuevo)
Gestión de datos Solución Sistema D Solución Sistema D Solución Sistema D

Servicios (retener) (retener) (retener)
. . . . . . . . . . . . . . .
© El Grupo Abierto
Figura 6-4 Tabla de evolución del estado de la arquitectura de transición

Tabla de evolución del estado de la arquitectura de transición Técnicas de planificación de la migración
Otra técnica (que no se muestra aquí) es usar códigos de colores en la matriz; por ejemplo:
ÿ Verde: servicio SBB en su lugar (ya sea nuevo o retenido)
ÿ Amarillo: servicio en transición a una nueva solución
ÿ Rojo: servicio a reemplazar
6.5 Técnica de evaluación del valor empresarial

Una técnica para evaluar el valor comercial es elaborar una matriz basada en una dimensión de índice de valor y una
dimensión de índice de riesgo. En la Figura 6-5 se muestra un ejemplo . El índice de valor debe incluir criterios como el
cumplimiento de los principios, la contribución financiera, la alineación estratégica y la posición competitiva. El índice de
riesgo debe incluir criterios como el tamaño y la complejidad, la tecnología, la capacidad organizativa y el impacto de
una falla. A cada criterio se le debe asignar un peso individual.
El índice y sus criterios y ponderaciones deben ser desarrollados y aprobados por la alta dirección. Es importante
establecer los criterios de toma de decisiones antes de conocer las opciones.
(Tamaño del proyecto indicado por el tamaño del círculo).
Proyecto A
Proyecto C
Proyecto B
Proyecto D
Valor Proyecto E
Proyecto F
Proyecto G
Proyecto H En problemas
En riesgo
En el blanco
© El Grupo Abierto
Riesgo
Figura 6-5 Evaluación de proyecto de muestra con respecto al valor comercial y el riesgo

redistribución
Capítulo 7: Requisitos de interoperabilidad
Este capítulo proporciona directrices para definir y establecer los requisitos de interoperabilidad.
7.1 Resumen
Una definición de interoperabilidad es "la capacidad de compartir información y servicios". Definir el grado en que se
compartirán la información y los servicios es un requisito arquitectónico muy útil, especialmente en una organización compleja
y/o empresa extensa.
La determinación de la interoperabilidad está presente en todo el ADM de la siguiente manera:
ÿ En la Visión de la Arquitectura (Fase A), la naturaleza y las consideraciones de seguridad de los intercambios de
información y servicios se revelan primero dentro de los escenarios comerciales.
ÿ En la Arquitectura Empresarial (Fase B), los intercambios de información y servicios son aún más
definido en términos comerciales
ÿ En la Arquitectura de Datos (Fase C), se detalla el contenido de los intercambios de información utilizando el modelo
corporativo de intercambio de datos y/o información.
ÿ En la Arquitectura de la Aplicación (Fase C), la forma en que las diversas aplicaciones deben
se especifica compartir la información y los servicios
ÿ En la Arquitectura Tecnológica (Fase D), los mecanismos técnicos adecuados para permitir
se especifican los intercambios de información y servicios
ÿ En Oportunidades y Soluciones (Fase E), las soluciones reales (p. ej., paquetes COTS) son
seleccionado
ÿ En la Planificación de la Migración (Fase F), la interoperabilidad se implementa lógicamente
7.2 Definición de interoperabilidad

Hay muchas formas de definir la interoperabilidad y el objetivo es definir una que se aplique de manera consistente dentro de
la empresa y la empresa extendida. Es mejor que tanto la empresa como la empresa extendida usen las mismas definiciones.
Muchas organizaciones encuentran útil categorizar la interoperabilidad de la siguiente manera:
ÿ La interoperabilidad operativa o comercial define cómo se van a gestionar los procesos comerciales.
compartido
ÿ La interoperabilidad de la información define cómo se comparte la información
ÿ La interoperabilidad técnica define cómo se van a compartir los servicios técnicos o al menos
conectarse entre sí

Definición de interoperabilidad Requisitos de interoperabilidad
Desde una perspectiva de TI, también es útil considerar la interoperabilidad de manera similar a Enterprise
Integración de aplicaciones (EAI); específicamente:
ÿ Presentación Integración/interoperabilidad es donde un enfoque de apariencia común a través de una solución similar a
un portal común guía al usuario a la funcionalidad subyacente del conjunto de sistemas
ÿ La integración/interoperabilidad de la información es donde la información corporativa es perfecta, por ejemplo, un conjunto

compartido entre las diversas aplicaciones corporativas para lograr información del , común
cliente
Normalmente esto se basa en una ontología corporativa comúnmente aceptada y servicios compartidos para la estructura,
calidad, acceso y seguridad/privacidad de la información.
ÿ La integración/interoperabilidad de aplicaciones es donde la funcionalidad corporativa se integra y se puede compartir

para que las aplicaciones no se dupliquen (p. ej., un cambio de servicio/componente de dirección; no uno para cada
aplicación) y se vinculen a la perfección a través de funcionalidades como el flujo de trabajo. Esto impacta en las aplicaciones
comerciales y de infraestructura y está muy relacionado con la unificación/interoperabilidad de los procesos comerciales
corporativos.
ÿ La integración/interoperabilidad técnica incluye métodos comunes y servicios compartidos para la comunicación, el

almacenamiento, el procesamiento y el acceso a los datos principalmente en la plataforma de aplicación y los dominios de
infraestructura de comunicaciones. Esta interoperabilidad se basa en el grado de racionalización de la infraestructura de TI
corporativa. , basado en estándares y/o plataformas informáticas comunes. Por ejemplo, varias aplicaciones que comparten
una infraestructura o 10 000 sitios web corporativos que utilizan un servidor web/administración de contenido centralizado
(en lugar de miles de servidores y webmasters repartidos por todo el país/el mundo).
Muchas organizaciones crean sus propios modelos de interoperabilidad, como se ilustra en el siguiente ejemplo del gobierno
canadiense. Tienen una definición de alto nivel de las tres clases de interoperabilidad e identifican la naturaleza de la información y
los servicios que desean compartir.
La interoperabilidad se acuña en términos de habilitadores electrónicos para el gobierno electrónico. Su desglose de interoperabilidad
es el siguiente:
ÿ Interoperabilidad de la información:
- Conocimiento administrativo
- Inteligencia de negocios
- Gestión de la información
— Identidad de confianza
ÿ Interoperabilidad empresarial:
— Redes de entrega
— e-Democracia
— comercio electrónico
— Administración de recursos empresariales

Requisitos de interoperabilidad Definición de interoperabilidad
— Gestión de relaciones y casos
ÿ Interoperabilidad técnica:
- Esa infraestructura
En ciertos enfoques arquitectónicos, como un sistema de sistemas o un modelo federado, la interoperabilidad es una
mejor práctica altamente recomendada que determinará cómo los sistemas interactúan entre sí. Una consideración
clave será el modelo operativo comercial de la empresa.
7.3 Modelo operativo empresarial

La clave para establecer la interoperabilidad es la determinación del modelo operativo corporativo, donde el modelo
operativo es "el nivel necesario de integración y estandarización de procesos comerciales para entregar bienes y
servicios a los clientes. Un modelo operativo describe cómo una empresa quiere prosperar y crecer". Al brindar una
visión más estable y factible de la empresa que la estrategia, el modelo operativo impulsa el diseño de la base para la
ejecución" .1 Por ejemplo, si las líneas de negocios o las unidades de negocios solo necesitan compartir documentos,
entonces los ABB y SBB pueden ser más simple que si fuera necesario compartir datos de transacciones estructuradas.
De manera similar, si la visión de la arquitectura incluye un entorno de servicios compartidos, entonces es útil definir el
nivel en el que se compartirán los servicios.
El modelo operativo corporativo normalmente indicará qué tipo de enfoque de interoperabilidad será apropiado. Este
modelo debe determinarse en la Fase A (Visión de la Arquitectura) si no en la Fase B (Arquitectura Empresarial), y
definitivamente en la Fase E (Oportunidades y Soluciones).
Las empresas complejas y/o las empresas extendidas (por ejemplo, la cadena de suministro) pueden tener más de un
tipo de modelo operativo. Por ejemplo, es común que el modelo operativo interno (y el modelo de interoperabilidad de
apoyo) difiera del que se usa para la empresa ampliada.
7.4 Mejora de la interoperabilidad

La implementación de la interoperabilidad requiere la creación, gestión, aceptación y aplicación de estándares realistas
que sean SMART (específicos, medibles, procesables, realistas y con límite de tiempo). Las medidas claras de
interoperabilidad son clave para el éxito.
La arquitectura es la clave para identificar estándares y las sesiones facilitadas examinarán formas pragmáticas
potenciales (que se ajustan a la cultura empresarial actual o emergente) para lograr el grado necesario de
interoperabilidad.
La interoperabilidad debe refinarse para que satisfaga las necesidades de la empresa y/o de la empresa ampliada de
forma inequívoca. Las medidas de interoperabilidad refinadas (grados, tipos y objetivos de alto nivel) deben ser parte
de la dirección estratégica de Enterprise Architecture o hacer referencia a ella.
Estas medidas se ejemplifican dentro de una estrategia de transformación que debe integrarse en la definición de la
Arquitectura objetivo e implementarse pragmáticamente en las Arquitecturas de transición. Al finalizar, también actualice
los resultados y las dependencias del análisis de brechas consolidado para garantizar que se capturen todos los
resultados de las sesiones facilitadas.
Un ejemplo de especificación de interoperabilidad son los Grados de Interoperabilidad (usados dentro del
1. Enterprise Architecture as Strategy (Ross et al., 2006) proporciona modelos potenciales.

Refinando la interoperabilidad Requisitos de interoperabilidad
Departamento Canadiense de Defensa Nacional y OTAN). Estas organizaciones se centraron en el intercambio de

información y propusieron cuatro grados de interoperabilidad de la siguiente manera:
ÿ Grado 1: Intercambio de datos no estructurados implica el intercambio de datos no estructurados interpretables

por humanos, como el texto libre que se encuentra en estimaciones operativas, análisis y documentos.
ÿ Grado 2: Intercambio de datos estructurados implica el intercambio de datos estructurados interpretables por
humanos destinados al manejo manual y/o automatizado, pero requiere compilación manual, recepción y/o envío
de mensajes.
ÿ Grado 3: Intercambio continuo de datos implica el intercambio automatizado de datos entre

sistemas basados en un modelo de intercambio común
ÿ Grado 4: Intercambio continuo de información es una extensión del Grado 3 a la interpretación universal de la
información a través del procesamiento de datos basado en aplicaciones cooperativas.
Estos títulos deben refinarse aún más y hacerse técnicamente significativos para cada uno de los títulos. A continuación
se muestra un ejemplo de refinamiento del Grado 3 con cuatro subclasificaciones: ÿ 3A: Intercambio formal de mensajes
ÿ 3B: Intercambio común de datos ÿ 3C: Intercambio completo de datos ÿ 3D: Intercambio de datos en tiempo real
La intención es especificar los grados detallados de interoperabilidad al nivel de detalle requerido para que sean
técnicamente significativos.
Estos títulos son muy útiles para especificar la forma en que se debe intercambiar la información entre los diversos
sistemas y proporcionar una dirección crítica a los proyectos que implementan los sistemas.
Se deben establecer medidas similares para determinar la interoperabilidad técnica y de servicios/negocios.
7.5 Determinación de los requisitos de interoperabilidad

La coexistencia entre los sistemas emergentes y existentes, especialmente durante la transformación, será un gran
desafío y las sesiones facilitadas deben intentar determinar qué se debe hacer para reducir el dolor. Es imperativo
involucrar al personal de gestión de operaciones y arquitectos en este paso, ya que serán responsables de operar los
entregables de la cartera.
Por ejemplo, podría ser necesaria una aplicación "envoltura" (una aplicación que actúa como interfaz [también conocida
como intérprete] entre la aplicación heredada y la infraestructura emergente).
De hecho, pragmáticamente, en el mundo de "si funciona, no lo arregles", el "envoltorio" podría convertirse en una
solución permanente.
Independientemente, utilizando los resultados del análisis de brechas y los escenarios comerciales como base, analice
los problemas de TI y trabájelos para garantizar que todas las brechas se identifiquen y aborden claramente y verifique
que se cumplan los requisitos específicos de la organización.
Es importante señalar que el proceso de desarrollo posterior debe incluir el reconocimiento de las dependencias y los
límites de las funciones y debe tener en cuenta qué productos están disponibles en el mercado. Un ejemplo de cómo
podría expresarse esto se puede ver en el

redistribución
Requisitos de interoperabilidad Determinación de los requisitos de interoperabilidad
ejemplo de bloques de construcción (consulte el estándar TOGAF: contenido de arquitectura).
Si se utiliza un mecanismo como los Grados de Interoperabilidad, entonces una matriz que muestra los
requisitos de interoperabilidad es una herramienta útil, como se ilustra en la Figura 7-1 y la Figura 7-2, señalando
que el grado de intercambio de información no es necesariamente simétrico o bidireccional entre
sistemas y/o partes interesadas.
La siguiente matriz se puede utilizar dentro de la empresa y/o dentro de la empresa ampliada como
manera de detallar que información y/o servicios pueden ser compartidos. La matriz debe comenzar en el
Business Architecture (Fase B) para capturar la naturaleza del intercambio de información entre
partes interesadas y evolucionar para determinar qué sistemas comparten qué información en la Fase C.
Fase B: requisitos de interoperabilidad de la información entre las partes interesadas

(Usando grados de interoperabilidad de la información)
Partes interesadas A B C D mi F GRAMO
A 2 3 2 3 3 3
B 2 3 2 3 2 2
C 3 3 2 2 2 3
D 2 2 2 3 3 3
mi 4 4 2 3 3 3
F 4 4 2 3 3 2
GRAMO 2 2 3 3 3 3
© El Grupo Abierto
Figura 7-1 Matriz de interoperabilidad de información empresarial
La Figura 7-1 muestra que la parte interesada A requiere intercambio de datos estructurados (Grado 2) con
Partes interesadas/Sistemas B y D, e intercambio continuo de datos (Grado 3) con
Actores/Sistemas C, E, F y G.
La matriz de interoperabilidad de la información comercial debe refinarse dentro de la Información

Arquitectura de Sistemas usando medidas refinadas y especificando los sistemas reales usados por el
partes interesadas. Un ejemplo se muestra en la Figura 7-2.

Determinación de los requisitos de interoperabilidad Requisitos de interoperabilidad
Fase C: requisitos de interoperabilidad entre sistemas
Sistema Sistema Sistema Sistema Sistema Sistema Sistema

A B C D mi F GRAMO
Sistema A 2A 3D 2B 3A 3A 3B
Sistema B 2E 3F 2C 3A 2B 2C
Sistema C 3E 3F 2B 2A 2A 3B
Sistema D 2B 2B 2B 3A 3A 3B
Sistema E 4A 4B 2B 3A 3B 3B
Sistema F 4A 4A 2B 3B 3A 2D
Sistema G 2B 2B 3A 3A 3B 3B
© El Grupo Abierto
Figura 7-2 Matriz de interoperabilidad de sistemas de información
En la Figura 7-2, la naturaleza del intercambio es más detallada (p. ej., Grado 3A versus solo Grado 3) y el intercambio
es entre sistemas específicos en lugar de partes interesadas. Por ejemplo, el Sistema A comparte información con los
otros sistemas de acuerdo con los estándares técnicos de la empresa.
En muchas organizaciones, las Arquitecturas comerciales describen la naturaleza de la información compartida entre
las partes interesadas y/o las organizaciones (p. ej., en defensa, el término es "nodo operativo"), y la Arquitectura de
datos especifica la información compartida entre los sistemas.
Actualizar los datos de destino definidos y la arquitectura de la aplicación (aprobada) con los problemas de
interoperabilidad que se plantearon.
7.6 Conciliación de los requisitos de interoperabilidad con posibles soluciones

El Enterprise Architect deberá asegurarse de que no haya conflictos de interoperabilidad, especialmente si existe la
intención de reutilizar los SBB y/o COTS existentes.
De hecho, la cuestión más importante que debe abordarse es la interoperabilidad empresarial. La mayoría de los SBB
o COTS tendrán sus propios procesos comerciales incorporados. Cambiar los procesos comerciales integrados a
menudo requerirá tanto trabajo que se perderán las ventajas de reutilizar las soluciones.
Hay numerosos ejemplos de esto en el pasado.
Además, hay que tener en cuenta el aspecto del flujo de trabajo entre los diversos sistemas. El Enterprise Architect
deberá asegurarse de que los Business Architects y los patrocinadores de la arquitectura aprueben cualquier cambio
en los requisitos de interoperabilidad comercial en una Declaración de trabajo de arquitectura revisada.

redistribución
Capítulo 8: Preparación para la transformación empresarial

Evaluación
Este capítulo describe una técnica conocida como Evaluación de la preparación para la transformación empresarial, utilizada para evaluar y
cuantificar la preparación de una organización para experimentar cambios.
Este capítulo se basa en el trabajo del Gobierno de Canadá y su Programa de habilitación para la transformación empresarial (BTEP).
8.1 Introducción
La arquitectura empresarial es un esfuerzo importante dentro de una organización y, en la mayoría de los casos, una visión de
arquitectura innovadora (fase A) y una definición de arquitectura de apoyo (fases B a D) implicarán un cambio considerable. Hay
muchas dimensiones que cambiar, pero la más importante con diferencia es el elemento humano. Por ejemplo, si la empresa prevé una
consolidación de las existencias de información y un cambio hacia un nuevo paradigma, como la orientación de servicios para la
prestación de servicios integrados, entonces las implicaciones de recursos humanos son importantes. Potencialmente junto con una
cultura de aversión al cambio y una mano de obra poco calificada, la arquitectura más sólida e innovadora no podría llegar a ninguna
parte.
Comprender la preparación de la organización para aceptar el cambio, identificar los problemas y luego tratarlos en los Planes de
implementación y migración es clave para una transformación exitosa de la arquitectura en las Fases E y F. Este será un esfuerzo
conjunto entre la empresa (especialmente los humanos). recursos) personal, líneas de negocio y planificadores de TI.
Las actividades recomendadas en una evaluación de la preparación de una organización para abordar la transformación empresarial
son:
ÿ Determinar los factores de preparación que afectarán a la organización
ÿ Presentar los factores de preparación usando modelos de madurez
ÿ Evaluar los factores de preparación, incluida la determinación de las calificaciones de los factores de preparación.
ÿ Evaluar los riesgos para cada factor de preparación e identificar acciones de mejora para mitigar los
riesgo
ÿ Trabaje estas acciones en las Fases E y F del Plan de Implementación y Migración

Introducción Evaluación de preparación para la transformación empresarial
8.1.1 Programa de habilitación de transformación empresarial (BTEP)

El Programa de Habilitación para la Transformación Empresarial del Gobierno de Canadá (BTEP, por sus siglas en inglés) brinda
orientación sobre cómo identificar los problemas relacionados con la transformación empresarial.
El BTEP recomienda que todos los proyectos realicen una evaluación de preparación para la transformación para, al menos,
descubrir los problemas de transformación empresarial. Esta evaluación se basa en la determinación y análisis/calificación de una
serie de factores de preparación. El resultado es una comprensión más profunda de los desafíos y oportunidades que podrían
presentarse en el curso del esfuerzo. Muchos de los desafíos se traducen directamente en riesgos que deben abordarse,
monitorearse y, si es posible, mitigarse.
Las siguientes secciones describen la Evaluación de preparación para la transformación empresarial utilizando el método BTEP,
incluidas algunas lecciones aprendidas. Los lectores deben tener en cuenta que la mayoría de las organizaciones tendrán su propio
conjunto único de factores y criterios, pero la mayoría son similares.
8.2 Determinar los factores de preparación

El primer paso es determinar qué factores tendrán un impacto en la transformación empresarial asociada con la migración de las
arquitecturas de referencia a las de destino.
Esto se puede lograr mejor mediante la realización de un taller facilitado con personas de diferentes partes de la organización. Es
importante que se busquen todas las perspectivas ya que los temas serán variados. En este taller es muy útil comenzar con una
lista tentativa de factores que los participantes pueden reutilizar, rechazar, aumentar o reemplazar.
A continuación se muestra un ejemplo de conjunto de factores extraídos del BTEP:
ÿ La visión es la capacidad de definir y comunicar claramente lo que se quiere lograr
Aquí es donde la gerencia puede definir claramente los objetivos, tanto en términos estratégicos como específicos. El
liderazgo en la definición de la visión y las necesidades proviene del lado comercial con aportes de TI. Existen procesos
predecibles y probados para pasar de la visión a la declaración de requisitos. Los impulsores principales de la iniciativa son
claros. El alcance y el enfoque de la iniciativa de transformación se han definido claramente en toda la organización.
impacto de hacer
, Voluntad
el trabajo
y Resolución
y la resolución
es ladepresencia
continuarde
y completar
un deseo de
el esfuerzo
lograr los resultados, ÿ Deseo la voluntad de aceptar el
Hay una discusión activa sobre el impacto que la ejecución del proyecto puede tener en la organización, con una clara
indicación de la intención de aceptar los impactos. Los recursos clave (por ejemplo, financieros, humanos, etc.) se asignan
para el esfuerzo y los altos ejecutivos proyectan el mensaje claro de que la organización seguirá adelante; un mensaje que
identifica tanto el esfuerzo como los beneficios. Desde el punto de vista de la organización, existe un historial de terminar lo
que se comenzó y de cerrar los problemas en los plazos necesarios y existe un acuerdo en toda la organización de que la
iniciativa de transformación es lo "correcto" que se debe hacer.
ÿ Necesidad, en el sentido de que existe una necesidad apremiante de ejecutar el esfuerzo
Hay declaraciones claras sobre lo que la organización no podrá hacer si el proyecto no avanza, y declaraciones igualmente
claras sobre lo que el proyecto permitirá que haga la organización. Hay consecuencias visibles y ampliamente entendidas
del fracaso del esfuerzo y los criterios de éxito han sido claramente identificados y comunicados.

Evaluación de la preparación para la transformación empresarial Determinar los factores de preparación
ÿ Existe un Business Case que crea un fuerte enfoque para el proyecto, identificando los beneficios que
debe lograrse y, por lo tanto, crear un imperativo para tener éxito
El documento de caso de negocio identifica los beneficios concretos (ingresos o ahorros) que la organización se
compromete a entregar y señala de manera clara e incuestionable las metas que la organización se compromete
a alcanzar.
ÿ Existe financiamiento, en la forma de una fuente clara de recursos fiscales, que cubre los gastos potenciales del
emprendimiento
ÿ El patrocinio y el liderazgo existen y son ampliamente compartidos, pero no tanto como para difundirse.
responsabilidad
El liderazgo mantiene a todos "a bordo" y mantiene a todos enfocados en las metas estratégicas. El esfuerzo
está patrocinado por un ejecutivo que está debidamente alineado para proporcionar el liderazgo que necesita el
esfuerzo y capaz de articular y defender las necesidades del esfuerzo al nivel de la alta gerencia. Estos
patrocinadores ejecutivos están y permanecerán comprometidos en todo momento.
ÿ Gobernanza es la capacidad de lograr la participación y el apoyo de todas las partes con interés o responsabilidad
en el esfuerzo con el objetivo de garantizar que se atiendan los intereses corporativos y se logren los objetivos.
Hay partes interesadas claramente identificadas y un sentido claro de su interés y responsabilidad hacia el
proyecto; una cultura que fomente la participación hacia objetivos corporativos en lugar de locales; un historial
de poder gestionar con éxito actividades que cruzan áreas de interés; una cultura que fomente la participación
significativa, en lugar de simbólica, en los procesos de gestión; y un compromiso con la revisión y el desafío
continuos del proyecto y la apertura al asesoramiento externo.
ÿ La rendición de cuentas es la asignación de responsabilidades específicas y apropiadas, el reconocimiento de

expectativas medibles por parte de todas las partes interesadas y la alineación de la toma de decisiones con las
áreas de responsabilidad y donde se sentirá el impacto de las decisiones.
La rendición de cuentas está alineada con el área donde se sentirán los beneficios del éxito o las consecuencias
del fracaso del esfuerzo, así como con las áreas de responsabilidad.
ÿ Enfoque viable y modelo de ejecución es un enfoque que tiene sentido en relación con
la tarea, con un entorno de apoyo, modelado a partir de un enfoque probado Hay nociones
claras del cliente y el papel del cliente en relación con el constructor o contratista principal y la organización tiene
experiencia con esfuerzos de este tipo para que los procesos, disciplinas, experiencia el manejo y la gobernanza
ya están implementados, probados y disponibles para aplicarlos al esfuerzo de transformación. Todos los
jugadores conocen sus roles porque los han jugado antes con éxito. En particular, los roles de "cliente" y
"constructor de sistemas" son maduros y estables. Existe un plan de comunicación que cubre todos los niveles
de la organización y cubre las necesidades que van desde la concientización hasta la disponibilidad de detalles
técnicos. Existe un plan de recompensas y reconocimientos para reconocer a los equipos y personas que utilizan
buenas prácticas de gestión del cambio, planificación y prevención de comportamientos de crisis, y que refuerzan
comportamientos adecuados a la nueva forma de hacer negocios. Está claro para todos cómo ocurrirá la
implementación, cómo se monitoreará y cómo se realizarán las acciones de realineación y se dedicarán los
recursos adecuados para la vida de la transformación.

Determinar los factores de preparación Evaluación de la preparación para la transformación empresarial
ÿ La capacidad de ejecución de TI es la capacidad de realizar todas las tareas de TI requeridas por el proyecto,
incluyendo las habilidades, herramientas, procesos y capacidad de gestión
Ha habido una ejecución exitosa reciente de un esfuerzo similar de tamaño y complejidad similares y existen
procesos apropiados, disciplina, habilidades y un modelo racional para decidir qué habilidades y actividades buscar
en el exterior.
ÿ Enterprise Capacity to Execute es la capacidad de la empresa para realizar todas las tareas requeridas por el
esfuerzo, en áreas fuera de TI, incluida la capacidad de tomar decisiones dentro de las estrictas limitaciones de
tiempo típicas de los entornos de proyectos en función de la ejecución exitosa reciente. de un esfuerzo similar de
al menos la mitad del tamaño y la complejidad Existen procesos, disciplina y habilidades no específicos de TI para
hacer frente a este tipo de esfuerzo. La empresa tiene una capacidad demostrada para lidiar con el tipo de
problemas y requisitos de gestión de proyectos/carteras en curso. Se reconoce la necesidad de desarrollar
conocimientos y habilidades para la nueva forma de trabajar, así como el valor de un análisis formal de brechas de
habilidades y comportamiento.
ÿ Capacidad de la empresa para implementar y operar los elementos de transformación y sus procesos comerciales
relacionados, absorber los cambios que surgen de la implementación y la capacidad continua para operar en el
nuevo entorno
La empresa tiene una capacidad comprobada reciente para lidiar con los problemas de gestión de cambios que
surgen de los nuevos procesos y sistemas y cuenta con un programa de gestión de servicios sólido, disciplinado e
impulsado por procesos que proporciona operaciones, mantenimiento y soporte para los sistemas existentes.
Una vez que los factores han sido identificados y definidos, es útil convocar un taller de seguimiento donde los factores
serán evaluados en detalle en términos de su impacto/riesgo. La siguiente sección se ocupará de la preparación para una
evaluación eficaz de estos factores.
8.3 Factores de preparación actual
Una vez determinados los factores, es necesario presentarlos de tal forma que la valoración sea clara y se derive el
máximo valor de los participantes.
Una de esas presentaciones es mediante el uso de modelos de madurez. Si cada factor se convierte en un modelo de
madurez (un activo de gobierno reutilizable también) acompañado de una plantilla de hoja de trabajo estándar que
contiene toda la información y las deducciones que deben recopilarse, puede ser una herramienta muy útil.
El modelo de madurez debe permitir a los participantes:
ÿ Evaluar su nivel de madurez actual (Arquitectura de referencia)
ÿ Determinar el nivel de madurez objetivo que tendría que alcanzarse para realizar el Objetivo
Arquitectura
ÿ Determinar un objetivo intermedio que sería alcanzable en un plazo menor
El cuidado dedicado a la preparación de los modelos (que no es insignificante) se recuperará con un taller enfocado que
pasará rápidamente por una cantidad importante de factores.
Es importante que cada factor esté bien definido y que el alcance del esfuerzo de Arquitectura Empresarial (planificación
preliminar) se refleje en los modelos para mantener a los participantes del taller enfocados y productivos.

redistribución
Evaluación de la preparación para la transformación empresarial Factores de preparación presentes
Sería útil hacer circular los modelos antes del taller para recibir comentarios, aunque solo sea para garantizar que estén completos y
permitir que los participantes se preparen para el taller. Tenga en cuenta que el modelo que se muestra a continuación también tiene un
estado objetivo recomendado establecido por Enterprise Architect; esto nuevamente actúa como gobierno.
En la Figura 8-1 se muestra un ejemplo de un modelo de madurez para uno de los factores BTEP.
Evaluación de la preparación para la transformación empresarial - Modelo de madurez
Clase Contexto organizacional

Factor 2: necesidad de empresa
Arquitectura informacional
Factor de preparación BTEP SÍ
Definición Hay un reconocimiento por parte de la organización de que la información es un activo corporativo estratégico que requiere administración.
También se reconoce que los datos no son universalmente comprensibles, de la calidad requerida y accesibles.
Niveles del modelo de madurez
0 1 2 3 4 5
No definida Ad hoc repetible definido Administrado optimizado
La información no se Los conceptos de gestión de Muchas partes de la Los datos se reconocen Los datos se reconocen Los datos se tratan en
reconoce como un datos (DM) se entienden organización valoran como un activo estratégico como un activo estratégico todos los niveles de la
activo. intuitivamente y se practican la información/los datos en la mayor parte de la en todas las partes de la organización como un
ad hoc . en una como un activo estratégico. organización y en la mayoría organización y en la mayoría activo estratégico para
No hay una de los niveles, desde las de los niveles, desde las ser explotado y reutilizado.
administración clara de los datos. La administración de los Los expertos internos operaciones hasta la alta dirección.operaciones hasta la alta dirección.
datos es informal. de DM mantienen líneas Los productos y
claras de responsabilidad Los recursos están comprometidos Los recursos están comprometidos servicios de datos están
Ciertos expertos internos y administración de los datos, para garantizar una para garantizar una fuertemente integrados
y la alta dirección reconocen organizados a lo largo de las sólida administración de los sólida administración de los con la práctica de gestión
que los datos tienen una líneas de negocio y en todos datos en los niveles más bajos datos a nivel de la alta dirección de la organización.
importancia estratégica para los niveles superiores. y expertos en información.
de gestión y expertos en información.
la organización. Todo el personal está
El personal pone en facultado y equipado para
práctica los principios y administrar la información y
La atención se centra estándares de DM en sus se les considera “trabajadores
principalmente en la actividades diarias. del conocimiento”.
gestión técnica de datos
redundantes a nivel de aplicaciones.
Recomendado
Estado objetivo
© El Grupo Abierto
Figura 8-1 Evaluación de la preparación para la transformación empresarial: modelo de madurez
8.4 Evaluar los factores de preparación
Idealmente, los factores deberían evaluarse en un taller multidisciplinario. Utilizando un mecanismo como los modelos de madurez, los
arquitectos empresariales normalmente tendrán que cubrir una gran cantidad de terreno en poco tiempo.
El uso de una serie de plantillas para cada factor aceleraría la evaluación y garantizaría la coherencia en toda la amplia gama de factores.
La evaluación debe abordar tres cosas, a saber:
ÿ Visión del factor de preparación
ÿ Calificación del factor de preparación
ÿ Riesgos y acciones del factor de preparación

Evaluar los factores de preparación Evaluación de la preparación para la transformación empresarial
8.4.1 Visión del factor de preparación
La visión de un factor de preparación es la determinación de hacia dónde debe evolucionar la empresa para abordar el factor. Primero,
el factor debe evaluarse con respecto a su estado base y luego a su estado objetivo.
Por ejemplo, si el factor de "capacidad de ejecución de TI" se califica como bajo, idealmente el factor debería estar en "alto" para
realizar la Visión de la arquitectura objetivo. Un objetivo intermedio podría ser útil para dirigir la implementación. Los modelos de
madurez son excelentes vehículos para guiar esta determinación.
8.4.2 Clasificación del factor de preparación

Una vez que se establecen las visiones de los factores, es útil determinar qué tan importante es cada factor para el logro de la
Arquitectura objetivo, así como qué tan desafiante será migrar el factor a un estado visionario aceptable.
El BTEP utiliza un esquema de calificación de preparación que se puede utilizar como punto de partida para cualquier organización en
cualquier vertical. Cada uno de los factores de preparación se califica con respecto a:
ÿ Urgencia, por lo que si un factor de preparación es urgente, significa que se necesita acción antes de que
la iniciativa de transformación puede comenzar
ÿ Estado de preparación, que se clasifica como Bajo (necesita un trabajo sustancial antes de continuar), Justo (necesita algo de
trabajo antes de continuar), Aceptable (existen algunos problemas de preparación; no hay obstáculos), Bueno (existen
problemas relativamente menores) o Alto (sin problemas de preparación)
ÿ El grado de dificultad para arreglar califica el esfuerzo requerido para superar cualquier problema identificado como
ya sea No se necesita acción, Fácil, Moderado o Difícil
Aunque se puede usar una plantilla más extensa en el taller, es útil crear una tabla de resumen de los hallazgos para consolidar los
factores y proporcionar una visión general de la gestión. En la Figura 8-2 se muestra un resumen .

Evaluación de la preparación para la transformación empresarial Evaluar los factores de preparación
Resumen de evaluación de factores comerciales
Grado de
Ser Factor de preparación Urgencia Estado de preparación
Dificultad de arreglar
1 Visión
2 Deseo/voluntad/resolución
3 Necesitar
4 Caso de negocio
5 Fondos
6 Patrocinio y liderazgo
7 Gobernancia
8 Responsabilidad
9 Enfoque viable y modelo de ejecución
10 Capacidad de TI para ejecutar
11 Capacidad departamental para ejecutar
12 Habilidad para implementar y operar
© El Grupo Abierto
Figura 8-2 Tabla de resumen de la evaluación de preparación para la transformación empresarial
8.4.3 Factor de preparación Riesgos y acciones
Una vez que los factores han sido calificados y evaluados, se derivan series de acciones que permitirán que los factores
cambien a un estado favorable.
Cada factor debe evaluarse con respecto al riesgo utilizando el proceso destacado en el Capítulo 9, incluida una
estimación del impacto y la frecuencia.
Cada factor debe evaluarse de forma discreta y delinearse una serie de acciones de mejora. Antes de comenzar de
nuevo, las acciones existentes descritas en las arquitecturas deben verificarse primero antes de crear otras nuevas.
Estas acciones recién identificadas deben incorporarse formalmente al Plan de Implementación y Migración emergente.
Desde una perspectiva de riesgo, estas acciones están diseñadas para mitigar los riesgos y producir un riesgo residual
aceptable. Como riesgos, deben ser parte del proceso de gestión de riesgos y ser monitoreados de cerca a medida que
se implementa la Arquitectura Empresarial.
Estándar TOGAF® — Técnicas ADM sesenta y cinco

Preparación y planificación de la migración Evaluación de la preparación para la transformación empresarial
8.5 Planificación de preparación y migración

El ejercicio de evaluación brindará una evaluación realista de la organización y será un aporte clave para la planificación
estratégica de la migración que se iniciará en la Fase E y se completará en la Fase F. Es importante tener en cuenta si
las acciones de transformación empresarial se llevarán a cabo la ruta crítica de la visión y, de ser así, determinar cómo
impactarán en la implementación. No tiene sentido implementar una nueva capacidad de TI sin empleados capacitados
para usarla y personal de soporte listo para mantenerla.
Los factores de preparación, como parte de un Plan general de Implementación y Migración, deberán monitorearse
continuamente (Fase G) y se deberán tomar acciones correctivas rápidas a través del marco de gobierno de TI para
garantizar que se puedan implementar las arquitecturas definidas.
La evaluación de los factores de preparación será un documento vivo y durante la planificación de la migración y la
ejecución de las Arquitecturas de Transición, las actividades de transformación empresarial desempeñarán un papel
clave.
8.6 Comercialización del Plan de Implementación

La definición de la arquitectura no debe circular ampliamente hasta que se identifiquen y mitiguen los problemas de
transformación del negocio y las acciones asociadas formen parte de un plan general de "mercadeo" para la visión y el
plan de implementación y migración.
Por ejemplo, la consolidación de las existencias de información podría dar lugar a la pérdida de cientos de puestos de
trabajo y esta visión no debe anunciarse antes de formular un plan de recursos humanos/transformación empresarial
de apoyo para volver a capacitar o apoyar la búsqueda de nuevos empleos por parte de los trabajadores.
Los talleres de transformación empresarial son una parte crítica del Plan de Comunicaciones en el que personas clave
dentro de la organización se reúnen para evaluar las implicaciones de la transformación de la empresa. Para ello,
conocerán la Visión de la Arquitectura y la definición de la arquitectura (si es que ya no se involucraron a través de los
escenarios comerciales y la Arquitectura comercial). Este grupo se sentirá dueño de la Arquitectura Empresarial,
reconociendo al Arquitecto Empresarial como un administrador valioso.
Su determinación de los factores volverá a crear una cultura de comprensión en toda la empresa y proporcionará
información útil para el Plan de implementación y migración.
Este último plan debe incluir un Plan de Comunicación, especialmente para mantener informado al personal afectado.
En muchos casos, la colaboración con los sindicatos y los enlaces sindicales contribuirá aún más a una transición
humana (y pacífica) al estado de destino.
8.7 Conclusión
En resumen, la implementación de Enterprise Architecture requerirá un profundo conocimiento y conciencia de todos
los factores de transformación empresarial que impactan la transición al estado visionario. Con la evolución de la TI, la
tecnología real ya no es el problema real en la arquitectura empresarial, pero los factores críticos suelen ser los
culturales. Cualquier Plan de Implementación y Migración debe tener en cuenta ambos. Descuidarlos y centrarse en los
aspectos técnicos invariablemente dará como resultado una implementación que no llega a cumplir la promesa real de
una arquitectura empresarial visionaria.

redistribución
Capítulo 9: Gestión de riesgos
Este capítulo describe la gestión de riesgos, que es una técnica utilizada para mitigar el riesgo al implementar un proyecto de arquitectura.
9.1 Introducción
Siempre habrá riesgo con cualquier esfuerzo de transformación de arquitectura/negocio. Es importante identificar, clasificar y mitigar
estos riesgos antes de comenzar para que puedan ser rastreados a lo largo del esfuerzo de transformación.
La mitigación es un esfuerzo continuo y, a menudo, los desencadenantes del riesgo pueden estar fuera del alcance de los planificadores
de la transformación (p. ej., fusión, adquisición), por lo que los planificadores deben monitorear el contexto de la transformación
constantemente.
También es importante tener en cuenta que el Arquitecto Empresarial puede identificar los riesgos y mitigar ciertos, pero es dentro del
marco de gobierno que los riesgos primero deben aceptarse y luego administrarse.
Hay dos niveles de riesgo que se deben considerar, a saber:
1. Nivel inicial de riesgo: categorización del riesgo antes de determinar e implementar medidas de mitigación
comportamiento
2. Nivel de Riesgo Residual: categorización de riesgo después de la implementación de acciones de mitigación (si
ningún)
El proceso para la gestión de riesgos se describe en las siguientes secciones y consta de las siguientes actividades:
ÿ Clasificación de riesgos
ÿ Identificación de riesgos
ÿ Evaluación inicial de riesgos
ÿ Mitigación de riesgos y evaluación de riesgos residuales
ÿ Seguimiento de riesgos

Clasificación de riesgo Gestión de riesgos
9.2 Clasificación de riesgos

El riesgo es omnipresente en cualquier actividad de arquitectura empresarial y está presente en todas las fases dentro del
ADM. Desde una perspectiva de gestión, es útil clasificar los riesgos para que la mitigación de los riesgos se pueda
ejecutar de la manera más expedita posible.
Una forma común de clasificar los riesgos es con respecto al impacto en la organización (como se analiza en la Sección
9.4), donde los riesgos con ciertos impactos deben ser abordados por ciertos niveles de gobierno.
Normalmente, los riesgos se clasifican en tiempo (programa), costo (presupuesto) y alcance, pero también pueden incluir
riesgos relacionados con la transformación del cliente, riesgos contractuales, riesgos tecnológicos, riesgos de alcance y
complejidad, riesgos ambientales (corporativos), riesgos del personal y riesgos del cliente. riesgos de aceptación.
Otra forma de delegar la gestión de riesgos es clasificar aún más los riesgos por dominios de arquitectura.
Clasificar los riesgos como negocios, información, aplicaciones y tecnología es útil, pero puede haber formas
organizacionales específicas de expresar el riesgo que la dirección corporativa de Arquitectura Empresarial debería
adoptar o ampliar en lugar de modificar.
En última instancia, los riesgos de la arquitectura empresarial son riesgos corporativos y deben clasificarse y administrarse
según corresponda de la misma manera o de manera ampliada.
9.3 Identificación de riesgos

Las evaluaciones de madurez y preparación para la transformación generarán muchos riesgos.
Identifique los riesgos y luego determine la estrategia para abordarlos a lo largo de la transformación.
El uso de modelos de madurez de capacidad (CMM) es adecuado para factores específicos asociados con la entrega de
arquitectura y para identificar primero los estados de referencia y objetivo y luego identificar las acciones necesarias para
pasar al estado objetivo. Las implicaciones de no alcanzar el estado objetivo pueden resultar en el descubrimiento de
riesgos. Consulte el Capítulo 8 para obtener detalles específicos.
La documentación de riesgos se completa en el contexto de un Plan de Gestión de Riesgos, para el cual existen plantillas
en metodologías estándar de gestión de proyectos, por ejemplo, Project Management Book of Knowledge (PMBOK®) y
PRINCE2® , así como con las diversas metodologías gubernamentales.
Normalmente, estas metodologías implican procedimientos para la planificación de contingencias, el seguimiento y la

evaluación de los niveles de riesgo, la reacción a los factores cambiantes del nivel de riesgo, así como los procesos para
documentar, informar y comunicar los riesgos a las partes interesadas.
9.4 Evaluación inicial de riesgos

El siguiente paso es clasificar los riesgos con respecto al efecto y la frecuencia de acuerdo con las escalas utilizadas
dentro de la organización. Combine el efecto y la frecuencia para llegar a una evaluación de riesgos preliminar.
No existen reglas estrictas y rápidas con respecto a la medición del efecto y la frecuencia. Las siguientes pautas se basan
en las mejores prácticas de gestión de riesgos existentes.

redistribución
Gestión de riesgos Evaluación inicial de riesgos
El efecto podría evaluarse utilizando los siguientes criterios de ejemplo:
ÿ Catastrófico infiere una pérdida financiera crítica que podría resultar en la bancarrota de la organización
ÿ Crítico infiere una pérdida financiera grave en más de una línea de negocio que conduce a una pérdida en
productividad y sin retorno de la inversión en la inversión en TI
ÿ Marginal infiere una pérdida financiera menor en una línea de negocio y un rendimiento reducido en
inversión en la inversión en TI
ÿ Insignificante infiere un impacto mínimo en la capacidad de una línea de negocio para prestar servicios y/o
productos
La frecuencia podría indicarse de la siguiente manera:
ÿ Frecuente: es probable que ocurra con mucha frecuencia y/o continuamente
ÿ Probable: ocurre varias veces en el transcurso de un ciclo de transformación
ÿ Ocasional: ocurre esporádicamente
ÿ Rara vez: remotamente posible y probablemente no ocurriría más de una vez en el curso de
un ciclo de transformación
ÿ Improbable: probablemente no ocurrirá durante el curso de un ciclo de transformación
La combinación de los dos factores para inferir el impacto se llevaría a cabo utilizando una base heurística pero
esquema de clasificación consistente para los riesgos. Un esquema potencial para evaluar el impacto corporativo
podría ser el siguiente:
ÿ Riesgo extremadamente alto (E): lo más probable es que el esfuerzo de transformación fracase con graves
consecuencias
ÿ Alto riesgo (H): falla significativa de partes del esfuerzo de transformación que resulta en
metas que no se alcanzan
ÿ Riesgo moderado (M): falla notoria de partes del esfuerzo de transformación que amenaza la
éxito de ciertos objetivos
ÿ Riesgo bajo (L): ciertas metas no serán completamente exitosas
Estos impactos se pueden derivar usando un esquema de clasificación, como se muestra en la Figura 9-1.
Evaluación de Impacto de Riesgo Corporativo
Frecuencia
Efecto Frecuente Probable Ocasional Raramente Improbable
Catastrófico mi mi H H METRO
Crítico mi H H METRO L
Marginal H METRO METRO L L
Despreciable METRO L L L L
© El Grupo Abierto
Figura 9-1 Esquema de clasificación de riesgos

Evaluación inicial de riesgos Gestión de riesgos
9.5 Mitigación de riesgos y evaluación de riesgos residuales

La mitigación del riesgo se refiere a la identificación, planificación y ejecución de acciones que reducirán el riesgo a un
nivel aceptable.
El esfuerzo de mitigación podría ser un simple monitoreo y/o aceptación del riesgo a un plan de contingencia en toda
regla que requiera redundancia completa en un Plan de Continuidad de Negocios (con todas las implicaciones asociadas
de alcance, costo y tiempo).
Debido a las implicaciones de esta evaluación de riesgos, debe realizarse de manera pragmática pero sistemática.
Dado que la prioridad se dirige a los riesgos frecuentes de alto impacto, cada riesgo debe mitigarse a su vez.
9.6 Realización de una evaluación de riesgos residuales

Una vez que se haya identificado el esfuerzo de mitigación para cada uno de los riesgos, vuelva a evaluar el efecto y la
frecuencia y luego vuelva a calcular los impactos y vea si el esfuerzo de mitigación realmente ha logrado una diferencia
aceptable. Los esfuerzos de mitigación a menudo requerirán muchos recursos y se debe desafiar un desembolso
importante para un riesgo residual pequeño o nulo.
Una vez que se mitiga el riesgo inicial, el riesgo que permanece se denomina "riesgo residual". La consideración clave
es que el esfuerzo de mitigación en realidad reduce el impacto corporativo y no solo mueve el riesgo a otro cuadrante
similarmente alto. Por ejemplo, cambiar el riesgo de frecuente/catastrófico a frecuente/crítico sigue generando un riesgo
extremadamente alto. Si esto ocurre, entonces se debe reconsiderar el esfuerzo de mitigación.
El entregable final debe ser una evaluación del riesgo de transformación que podría estructurarse como una hoja de
trabajo, como se muestra en la Figura 9-2.
Riesgo Preliminar Riesgo residual
Identificación de riesgo Riesgo Efecto Frecuencia Impacto Mitigación Efecto Frecuencia Impacto
© El Grupo Abierto
Figura 9-2 Hoja de trabajo de evaluación de identificación y mitigación de riesgos de muestra
9.7 Seguimiento y Gobernanza del Riesgo (Fase G)

Los riesgos residuales tienen que ser aprobados por el marco de gobierno de TI y, potencialmente, en el gobierno
corporativo donde se requiere la aceptación empresarial de los riesgos residuales.
Una vez que los riesgos residuales han sido aceptados, la ejecución de las acciones de mitigación debe ser monitoreada
cuidadosamente para asegurar que la empresa esté lidiando con un riesgo residual en lugar de un riesgo inicial. Las
hojas de trabajo de evaluación de identificación y mitigación de riesgos se mantienen como artefactos de gobernanza y
se mantienen actualizadas en la Fase G (Gobernanza de implementación) donde se lleva a cabo el monitoreo de riesgos.

redistribución
Gestión de riesgos Seguimiento y Gobernanza de Riesgos (Fase G)
El gobierno de la implementación puede identificar riesgos críticos que no se están mitigando y que podrían requerir
otro ciclo completo o parcial de ADM.
9.8 Resumen
La gestión de riesgos es una parte integral de la arquitectura empresarial. Se alienta a los profesionales a utilizar su
metodología de gestión de riesgos corporativos o ampliarla utilizando la guía de este capítulo. En ausencia de una
metodología corporativa formal, los arquitectos pueden utilizar la guía de este capítulo como una mejor práctica.

Gestión de riesgos

redistribución
Capítulo 10: Alternativas de arquitectura y compensaciones
Este capítulo describe una técnica para identificar arquitecturas objetivo alternativas y realizar compensaciones entre las alternativas.
10.1 Concepto
A menudo, hay más de una posible arquitectura de destino que se ajustaría a la visión de la arquitectura, los principios
y los requisitos de la arquitectura. Es importante identificar arquitecturas objetivo alternativas y desarrollar la comprensión
de las diferentes posibilidades e identificar las compensaciones entre las alternativas. La creación de una arquitectura
normalmente requiere compensaciones entre fuerzas en competencia.
Presentar diferentes alternativas y compensaciones a las partes interesadas ayuda a los arquitectos a extraer agendas,
principios y requisitos ocultos que podrían afectar la Arquitectura de destino final.
10.2 Método
Lo más común es que no exista una única alternativa que satisfaga las preocupaciones de todas las partes interesadas.
El estándar TOGAF respalda una técnica para investigar diferentes alternativas y discutirlas con las partes interesadas.
Comúnmente, las alternativas se definen por dominio. Esto se hace para simplificar el análisis de las diferentes
alternativas. Por supuesto, las alternativas por dominio se pueden fusionar en un análisis general de las alternativas
para toda la arquitectura.
La figura 10-1 ilustra el método de compensación de arquitectura.

Método Alternativas de arquitectura y compensaciones
Visión Principios Requisitos
Alternativas
Criterio A Criterio B Criterio C
Alternativa A Alternativa B Alternativa C
Seleccione
Alternativa seleccionada
© El Grupo Abierto
Figura 10-1 Método de compensación de arquitectura
La primera parte del método utiliza la visión, los principios, los requisitos y otra información para
seleccionar conjuntos de criterios ia apropiados para diferentes alternativas.
Esta segunda parte del método define alternativas basadas en los criterios y construye
comprensión de cada uno.
La tercera parte de este método seleccionará una de las alternativas o combinará características
de más de uno, para crear la alternativa propuesta. Realice las siguientes actividades en tan sólo
suficiente detalle para apoyar esa decisión. El método se puede utilizar para cualquier fase en cualquier nivel de un
arquitectura.
10.2.1 Criterios
Los criterios se utilizan para las diferentes alternativas y se derivan de muchas entradas diferentes para
la arquitectura. Considere la influencia de los principios de la arquitectura, los requisitos, la visión y
preocupaciones de las partes interesadas.
Cada alternativa tendrá distintas ventajas o desventajas que deberán discutirse

y acordado con las partes interesadas. Es posible que se necesiten puntos de vista y puntos de vista adicionales para permitir
partes interesadas para explorar las alternativas y comprender las dependencias, riesgos y
incertidumbres.
74 El estándar de grupo abierto (2022)

Alternativas de arquitectura y compensaciones Método
Los ejemplos típicos de tipos alternativos (basados en criterios) incluyen:
ÿ Alternativa flexible
ÿ Tiempo y costo de realizar la alternativa, incluidas las transiciones y mesetas ("islas

de estabilidad")
ÿ Período de tiempo durante el cual se lograrán los beneficios estimados de la alternativa
ÿ Cumplimiento de estilos o pautas de arquitectura
ÿ Método de entrega de la solución (p. ej., reutilización, desarrollo,
compra) ÿ Impacto mínimo en las capacidades comerciales durante la implementación de la alternativa
ÿ Riesgo minimizado asociado con la alternativa y cualquier acción de mitigación necesaria
ÿ etcétera, .. .
10.2.2 Identificar alternativas

Identificar un conjunto de posibles alternativas utilizando la Visión, los Principios y los Requisitos de la Arquitectura.
Para cada alternativa:
1. Definir los criterios generales para la alternativa
Utilice la visión, los principios y los requisitos de la arquitectura para definir los criterios de la alternativa. Los criterios
se pueden aplicar en diferentes niveles de abstracción y fases de ADM para identificar diferentes alternativas de
arquitectura.
2. Describa la arquitectura de la alternativa
Cree un conjunto de vistas de arquitectura necesarias para llegar a una comprensión adecuada del impacto de la
alternativa. Agregue cualquier otra información necesaria. No entre en demasiados detalles. Sin embargo, es
importante llevar a cabo una buena evaluación de impacto e identificar las interdependencias entre las alternativas
y el paisaje existente y tener una imagen completa de las implicaciones de la implementación alternativa.
3. Estimar las brechas entre la línea de base y esta alternativa
Con base en la comprensión actual del estado de la línea de base, describa las brechas que existen entre la línea
de base y esta alternativa. Si aún no se ha definido la línea de base, este análisis de brechas será informal. Más
detalles sobre cómo hacer un análisis de brechas aparecen en el Capítulo 5.
4. Comprender los impactos y las ventajas y desventajas de la alternativa en toda la Arquitectura

Paisaje:
— Identificar el impacto que tendrá la alternativa en cualquier arquitectura existente y en cualquier arquitectura
de transición dentro del paisaje arquitectónico.
— Identificar el impacto que tendrá la alternativa en cualquier proyecto de implementación planeado o en

ejecución
— Identificar las restricciones impuestas a esta alternativa por cualquier proyecto de implementación planificado
o en ejecución.

Método Alternativas de arquitectura y compensaciones
— Identificar impactos en la arquitectura en otras fases de ADM en este proyecto de arquitectura
— Identificar requisitos de arquitectura/solicitudes de cambio de esta arquitectura que

restringir otras arquitecturas
— Identificar el valor final entregado por la alternativa, en qué medida cubre la brecha
para alcanzar el estado futuro, y el propósito de la iteración
10.2.3 Elija entre alternativas y defina en detalle
Este paso se basa en las alternativas para seleccionar o definir una alternativa alternativa. Utilice el análisis de
compensación para resolver conflictos entre alternativas:
1. Comprender las fortalezas y debilidades de cada alternativa
2. Compare las alternativas en función de qué tan bien se alinean con los criterios definidos ia
3. Seleccionar la alternativa más adecuada o combinar características de más de una de las alternativas, para definir
una alternativa alternativa en colaboración con las partes interesadas
4. Montar la alternativa:
— Finalizar la descripción de la alternativa
— Asegurarse de que todos los puntos de vista de la arquitectura identificados hayan sido elaborados durante
La alternativa
— Asegurarse de que la alternativa se defina con suficiente detalle para respaldar la toma de decisiones.
5. Resolver los impactos en el Paisaje Arquitectónico
6. Llevar a cabo una revisión formal de las partes interesadas para determinar una decisión y financiamiento alternativos
El análisis de impacto de las alternativas se realizó con el detalle justo para elegir entre ellas.

redistribución
Índice
ABB .................................................. .................................................... ............39 ejemplos de

principios de aplicación .................................. .................................................... ...............16
alternativas de arquitectura ................................ .............................................73 Arquitectura
Continuo .................................................. ..............................42 patrón de
arquitectura .................. .................................................... ...............39, 41
contenido ............................... .................................................... .....................40 Principios de
arquitectura .......................... .................................................... ........3
características .......................................... .................................................... ....4
componentes ............................................ .................................... ..................4 criter
ios ............................... .................................................... ..........................5 vista de la
arquitectura.................... .................................................... ...............22, 42 punto de vista de
la arquitectura ............................... .................................................... ...22
BTEP ............................................. .................................................... ........59-60 Esquema de
calificación de preparación .................................. ..................................64 Plan de Continuidad
del Negocio .......... .................................................... ...............70 principios empresariales
ejemplos .................................................. .................................................... ..7 Evaluación de

la preparación para la transformación empresarial ..........................59 preocupación
norte................................................. .................................................... ......22
CUNAS .......................................... .................................................... ................16 ejemplos de
principios de datos ............................... .................................................... ...................11 Grados
de interoperabilidad ........................... ..........................................................56 patrón de
diseño................................................ ...................................................41 entrar premio modelo
operativo................................................ ..........................55 introducir principios de
premios .................. .................................................... ....................3 espacio a
analisis.................................................. ..........................................................45
GOTS .................................................. .................................................... .........16
gobernanza ....................................... .................................................... ..........70 Grupo de la
ladera ...................................... .................................................... ........42
modismo .......................................... .................................................... ...........42 evaluación
inicial de riesgos ....................... .................................................... ......68 interoperabilidad
categorias ................................................ .................................................... 53

refinación ................................................ .................................................... ....55
requisitos ................................................ ..........................................................53
JAVA .................................................. .................................................... ...........16 modelo de
madurez .................................. .................................................... .........62 Planificación de la
migración .................................. .................................................... 66 patrón n
recursos ............................................... ............................................42 página de inicio de
patrones. .................................................... ...................................42 patrón ns-discusión
Preguntas Frecuentes........ .................................................... ..................... 42 factores de
preparación ............................................... .............................................60

Índice
planificación de la preparación ................................................ ..........................................66

evaluación del riesgo residual ...... .................................................... ......................70 evaluación
de riesgos ......................... .................................................... .................68 clasificación de
riesgo .................................. .................................................... ...........68 identificación de
riesgos ............................... .................................................... .....68 gestión de
riesgos .......................................... ..........................................67 mejor
práctica ................................................. .............................................69 Plan de Gestión de
Riesgos. .................................................... .............................68 seguimiento de
riesgos .................. .................................................... ..........................70 SANS Insta
tuto .................................................. .............................................11
SBB ... .................................................... .................................................... ........39
INTELIGENTE .................................. .................................................... ...............55 parte
interesada ............................... .................................................... ..........22 gestión de grupos de
interés ............................... .............................................21 pasos del
proceso . .................................................... .............................................22
mayordomo ....... .................................................... ..........................................13 tecnología
principios ejemplos ................................................ .................................................... .17
evaluación de la preparación para la transformación .................................. .......... ....60
TRM ............................................ .................................................... ..........46
síndico ............................... .................................................... ..........................13

redistribución

C220 Part2e

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 Part2e

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

El estándar de grupo abierto

Estándar TOGAF® —Técnicas 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® — Técnicas ADM

Publicado por The Open Group, 2005-2022.

yo The Open Group Standard (2022)

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

Capitulo 2 Principios de la arquitectura .................................................. .......... 3

Capítulo 3 Gestión de partes interesadas .............................................. ...... 21

Capítulo 4 Patrones de arquitectura ................................................ ............... 39

Capítulo 5 Análisis de brechas .................................................. ............................... 45

Capítulo 6 Técnicas de Planificación de la Migración ................................ 49

Estándar TOGAF® — Técnicas ADM iii

6.5 Técnica de evaluación del valor comercial ....................................... 52

Capítulo 7 7.1 7.2 Requisitos de interoperabilidad ............................................. 53

Capítulo 8 8.1 Evaluación de la preparación para la transformación empresarial ...... 59

Capítulo 9 9.1 9.2 Gestión de Riesgos .................................................. ...................... 67

Capítulo 10 10.1 Alternativas de Arquitectura y Compensaciones ........................ 73

Índice .................................................. ............................................. 77

3-1 Ejemplos de partes interesadas y categorías ............................................... .23

IV El estándar de grupo abierto (2022)

6-3 Tabla de incrementos de definición de arquitectura ....................................... 50

2-1 Formato recomendado para definir principios .......................................... 4

Estándar TOGAF® — Técnicas ADM 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 - Técnicas ADM.

Estándar TOGAF® — Técnicas ADM viii

Java es una marca comercial registrada de Oracle y/o sus filiales.

PRINCE2 es una marca registrada de AXELOS Limited.

viii The Open Group Standard (2022)

Estándar TOGAF® — Técnicas ADM ix

X The Open Group Standard (2022)

Las pautas incluidas en este documento son las siguientes:

Estándar TOGAF® — Técnicas ADM 1

2 The Open Group Standard (2022)

Capítulo 2: Principios de arquitectura

El resto de esta sección trata exclusivamente de los Principios de Arquitectura.

Estándar TOGAF® — Técnicas ADM 3

Características de los principios de la arquitectura Principios de arquitectura

2.2 Características de los principios de la arquitectura

2.3 Componentes de los Principios de Arquitectura

En la Tabla 2-1 se proporciona una plantilla recomendada .

Declaración Debe comunicar de forma sucinta y sin ambigüedades la regla fundamental.

Tabla 2-1 Formato recomendado para definir principios

4 The Open Group Standard (2022)

Principios de arquitectura Desarrollo de principios de arquitectura

2.4 Desarrollo de principios de arquitectura

Los Principios de Arquitectura se basarán en principios a nivel de empresa, si existen.

ÿ Misión y planes de la empresa: la misión, los planes y la infraestructura organizativa de la

ÿ Iniciativas estratégicas de la empresa: las características de la empresa (sus fortalezas, debilidades,

ÿ Sistemas y tecnología actuales: el conjunto de recursos de información desplegados dentro de la empresa,

2.4.1 Cualidades de los Principios

Hay cinco criterios que distinguen un buen conjunto de principios:

ÿ Robusto: permite tomar decisiones de buena calidad sobre arquitecturas y planes, y