TOGAFF-Completo V2

1
TOGAFF 9
Francisco Javier Pulido Fajardo

frankpulido2007@yahoo.com
21/06/2021 09:30:29 1
2
Introducción
El libro de TOGAF se compone de 7 capítulos:
PART I (Introduction). Introducción a los conceptos de Arquitectura empresarial

PART II (arquitectura Development Method), La metodología de desarrollo de TOGAF
PART III (ADM Guidelines & Techniques). Describe el conjunto de guías y técnicas
disponibles para desarrollar el proceso de Arquitectura.
 PART IV (arquitectura Content Framework). Este framework incluye el metamodelo
para los artefactos, Bloques de construcción, y una descripción suscinta de los entregables
de cada fase.
 PART V (Enterprise Continuum & Tools). Taxonomia y herramientas para categorizar
y almacenar las salidas del proceso de Arquitectura.
 PART VI (TOGAF Reference Models), Modelos de referencia para la arquitectura (TRM
- III-RM).
 PART VII (arquitectura Capability Framework). Discute la organización, procesos,
habilidades, roles, y responsibilidades requeridos para establecer y operar una función de
arquitectura en la entidad.
21/06/2021 09:29:11
3
Introducción
Introducción de alto nivel de

Introducción y Conceptos Claves ( 1a Parte ) los conceptos de
Arquitectura empresarial
Architecture Development Method (2a Parte) El Core de TOAGFF, paso a

TOGAF ADM paso La metodología de
ADM Guías y Técnicas desarrollo de TOGAF
Y el (3a Parte) Describe el conjunto de
Content Framework guías y técnicas para
desarrollar ADM incluye el
Este framework
Architecture Content Framework metamodelo para los
(4a Parte) artifactos, Bloques de
construcción, y una
Enterprise Continuum and Tools (5a Parte) descripción de entregables
TOGAF Enterprise de cada fase.
Taxonomia y herramientas
Continuum & Tools TOGAF Reference Models (6a Parte) para categorizar y
almacenar las salidas del
proceso de Arquitectura
Dos modelos de referencia
que pueden ser aplicados a
la EA
TOGAF Capability
Architecture Capability Framework
Framework Como establecer y operar
(7a Parte)
EA en una Organización
21/06/2021 09:29:11 UT Interfactory 3
4
CAPITULO I: Introducción
Empresa es:
“Cualquier conjunto de organizaciones que tienen un

conjunto de metas en común.”
Por ejemplo:
• Agencia de gobierno
• Grupo empresarial
• Una compañía de un grupo
• Una unidad de negocio
• Un grupo de organizaciones ubicadas geográficamente apartadas pero con
un solo dueño
5
Por que necesito una Arquitectura empresarial?
El propósito de la arquitectura empresarial es optimizar en toda la

organización los procesos que, frecuentemente, se encuentran
desarticulados, fragmentados (Tanto manuales como automáticos) en
un ambiente integrado que es responsable de operativizar la estrategia
de la organización. Sus beneficios son:
 Mayor eficiencia en la Operación del negocio

 Una operación de IT más eficiente
 Mejor ROI, reduciendo los riesgos para futuras inversiones
 Un proceso de adquisición más simple, rápido y barato
6
En que me debería ocupar para desarrollar una AE?
 Identificar y refinar los requerimientos que tienen las partes

interesadas (stakeholders).
 Desarrollar vistas de la arquitectura que permitan presentar
como estos requerimientos se van a lograr.
 Presentar los acuerdos que deben efectuarse para
solucionar los conflictos entre los intereses de los diferentes
(stakeholders).
7
Arquitectura Empresarial
El análisis y la documentación de una empresa en sus estados

actuales y futuras de una estrategia de negocio, y la perspectiva de
la tecnología.
An Introduction to Enterprise Architecture © 2005
Líneasofde negocio Líneas de negocio

Lines
Network Business Network
Infrastructure
Network Network
Infrastructure
trabajo
C
Metas
Goals &
Infrastructure Infrastructure
Updated
Metas e inicativas
Strategic
Workforce
O
Network C Network
egocios –Estrategia
Iniciativas
Strategy
Initiatives O Estratégicas
Goals & Initiatives
actualizadas M
Infrastructure
Network Network
Infrastructure
/ Standards // Marco
M P
Products &
Productos
Infrastructure P ImprovedInfrastructure
Productos Business
y servicios O
Network
Services
Servicios
O
Gestión Products
mejorados Network
and Services N
N
Infrastructure
Network Network
Infrastructure E
Technology –NBusiness
E Arquitectura&
Security/ Estandares
DatosData &
Infrastructure N Enhanced
Flujos deInfrastructure
Información
Data and N
Plan Transición
Network
Information
Información
T
Information
Datos mejorados Network
Flows
T
S
E
Infrastructure
Network S Infrastructure E
Network
S
Sistemas
Systems &
Infrastructure Integrated
Sistemas Infrastructure
ySystems
Aplicaciones
Network
Tecnología
Network
Aplicaciones
Applications andintegrados
Applications
Seguridad
Infrastructure
Network Network
Infrastructure
Networks &
Redes
Infrastructure Optimized
Redes Infrastructure
e infraestructura
Networks
Infraestructura
Infrastructure and Infrastructure
optimizadas
ACTUAL FUTURO
ARQUITECTURA ARQUITECTURA
21/06/2021 09:29:11
8
Framework de Arquitectura:
Es un conjunto de herramientas que puede ser utilizado para desarrollar un

amplio espectro de diversas arquitecturas, y debe:
 Describir una metodología para la definición de un sistema de

información en términos de un conjunto de bloques constitutivos que
encajen entre sí adecuadamente.
 Contener un conjunto de herramientas
 Proveer un vocabulario común
 Incluir una lista de estándares recomendados
 Incluir una lista de productos que sean adecuados para la
implementación de la misma (Bloques de construcción).
9
Framework de Arquitectura:
 El diseño de la Arquitectura es un proceso complejo

 Un framework de arquitectura es una herramienta para:
 Diseñar una amplia variedad de arquitecturas
 Asistir en la evaluación de diferentes clases de arquitecturas
 Seleccionar y construir la adecuada arquitectura para una
organización
 Incorpora las mejores prácticas y el reconocimiento del
conocimiento.
 Presenta un conjunto de servicios, standards, conceptos
de diseño, componentes y configuraciones
 Guía el desarrollo de arquitecturas especificas
10
CAPITULO I: Conceptos Claves
Que es TOGAF?
Como otros frameworks de arquitectura empresarial, tiene como
principal objetivo establecer un enlace, en las empresas, entre el
negocio y TI aportando múltiples beneficios a ambas áreas como:
 Mayor usabilidad. Su estructura modular hace mas fácil

considerar un aspecto particular de las capacidades de la
arquitectura.
 Reducción de costes
 Reducción de Riesgos
 Identificación de Oportunidades
 Flexibilidad y Adaptación
 Lenguaje común
 Un enfoque holístico en el cambio empresarial
11
En TOGAF, una arquitectura es:
 “Una descripción formal de un sistema, o un plan

detallado del sistema a nivel de sus componentes que
guía su implementación“
 “La estructura de componentes, sus interrelaciones, y

los principios y guías que gobiernan su diseño y
evolución a lo largo del tiempo."
12
Tipos de Arquitectura TOGAF:
Define la estrategia de
Arquitectura negocios, la gobernabilidad,
Arquitectura de la estructura y los procesos
Empresarial clave de la organización.
Negocios
Arquitectura de IT Un plano para cada uno

de los sistemas de
aplicación que se requiere
implantar, las
Arquitectura de interacciones entre estos
sistemas y sus relaciones
Aplicaciones con los procesos de
negocio centrales de la
organización.
Arquitectura de Datos Estructura de los activos
de datos
Arquitectura de Tecnología Cómo la tecnología

une todo
13
En que consiste TOGAF:
 Un método de desarrollo de arquitectura (ADM)

 Arquitectura Base - Foundation arquitectura
 Un modelo técnico de referencia - Technical Reference Model (TRM)
 Una base de estándares - A Standards Information Base (SIB)
 Una base de bloques de construcción - Building Blocks Information
Base (BBIB)
 Una base de recursos que contiene:
 Vistas de arquitectura  Escenarios de negocio
 Gobierno de IT  Patrones de arquitectura
 Contratos de Arquitectura  Casos de estudio
 …  Principios de arquitectura
14
En que consiste TOGAF: Arquitectura Base
Foundation
Architecture
Arquitecturas objetivo
Método de desarrollo de la arquitectura
Base de
Modelo información
Base de
técnico de de bloques
información
referencia de
(standards) construcción
(servicios)
(futuro)
Requerimientos de Negocio
15
En que consiste TOGAF: Un método de desarrollo
 Inicia con la base de la

arquitectura
 Sigue las fases de ADM
 Resulta en
 Una arquitectura especifica de
la organización
 Mas activos (building block) re
usables en el Enterprise
Continuum
 Cada iteración se hace más fácil y
tiene más bloques de construcción
para usar
15
16
En que consiste TOGAF: III Reference Model
Política de Seguridad Cualidades Politica de mobilidad
Plataforma de aplicaciones
Aplicaciones que consumen información
Herramientas de Aplicaciones Gestión de

desarrollo distribución utilitarios
Aplicaciones que proven información
Desempeño SLAs Politica de gestión

16
17
Las interrelaciones de TOGAF
El proceso continuo de mejora de la arquitectura se conduce

alrededor de iteraciones a un método de desarrollo de la
arquitectura (ADM, arquitectura Method Development) operado
mediante las referencias del marco de capacidades de arquitectura
(ACM, Architecture Capability Framework) y soportado por unas
guías y técnicas (Guidelines & Techniques).
El método de desarrollo de la arquitectura produce contenido que

se guarda en un repositorio (ACF, Architecture Content Framework)
y se clasifica de acuerdo al continuo empresarial (Enterprise
Continuum). El contenido producido se construye usando modelos
de referencia (Refence Models).
18
Las interrelaciones La estructura de la organización , funciones,
responsabilidades , habilidades y proceso (Guia de Reuso) Es
Architecture Capability necesario para la práctica de Arquitectura una vista del
Empresarial repositorio
arquitectura que
Architecture Development Method proporciona
Enterprise Continuum métodos para
clasificar
Architecture Continuum arquitecturas y
artefactos de
Solution Continuum
solución a medida
Entregables que evolucionan
Artefactos
Repositorio Arquitectura
Bloques Metamodelo (Plantillas)
construcción Almacena
diferentes
Librería Referencia clases de
productos de
Técnicas Estándares arquitectura
ADM (Cómo se
Y Herramientas en diferentes
Hace) proporciona
un procedimiento niveles de
probado y Architecture Landscape abstracción.
repetible para la
entrega de
arquitecturas
19
Estructura de un documento TOGAF
PARTE I: Introducción
PARTE II: arquitectura
Development Method
PARTE III: ADM Guías y
Tecnicas
PARTE IV: arquitectura
Content Framework
PARTE V: Enterprise
Continuum &
Herramientas
PARTE VI: TOGAF
Modelos de Referencia
PARTE VII: arquitectura
Capability Framework
20
ADM. Architecure Development Method
Es el método definido por TOGAF para el desarrollo de

una arquitectura empresarial que cumpla con las
necesidades empresariales y de tecnología de la
información de una organización. Puede ser ajustado y
personalizado según las necesidades propias de la
organización y una vez definido se utiliza para gestionar
la ejecución de las actividades de desarrollo de la
arquitectura.
21
ADM. Características
 Consiste en un número de fases

 Es un proceso iterativo, en todo el proceso y dentro de las
fases
 Cada fase usa activos (assets) generados en fases previas
 Cada fase genera activos a que se utilizan en fases
posteriores
 Es un método genérico que se puede adaptar a cualquier
organización
 Agnóstico de cualquier tecnología
 Tiene en cuenta variables geográficas, sectores verticales y
distintos tipos de industria
 Se puede modificar o extender a necesidades particulares de
una organización
22
El ciclo de desarrollo de la Arquitectura
23
•Fase Preliminar Describe las actividades de preparación e inicio requeridas para
crear las capacidades de la arquitectura incluyendo la
personalización de TOGAF y las definiciones de los principios de
Arquitectura.
•Fase A: Visión de Arquitectura Describe la fase inicial del proceso de Arquitectura. Se debe
establecer el alcance, restricciones, y las expectativas del
proyecto TOGAF; Crea la Visión; determinar las partes
interesadas; valida el contexto del negocio y crear el “Declaración
de trabajo de la Arquitectura”; Obtener aprobaciones.
•Fase B: Arquitectura de Negocios Describe el desarrollo de las arquitecturas de negocios, sistemas

•Fase C: Arquitecturas de Sistemas de de información, y tecnología que esten acordes con la visión de
Información la arquitectura acordada.
•Fase D: Arquitectura Tecnológica
Desarrollar la arquitectura en tres niveles:
1.Negocio
2.Sistema de Información(aplicaciones y datos)
3.Tecnología
En cada caso desarrollar la arquitectura baseline (“Como es”) y el

objetivo (“Como será”) y analizar las brechas entre estas.
24
Fase E: Oportunidades y Soluciones Evaluar y seleccionar entre las opciones

de implementación identificadas en la
arquitectura objetivo; identificando los
proyectos de implementación más
importantes.
Fase F: Plan de Migración Analizar costos, beneficios y riesgos;

desarrollar una lista priorizada de
proyectos sobre las bases del plan de
implementación y migración.
25
Fase G: Implementación del Gobierno Conduce a la planeación inicial de la
implementación y a la identificación de los
entregables y los vehiculos hacia la arquitectura
definida en las fases anteriores.
Preparar y realizar los “arquitectura Contracts”

(Implementación del Governance Board);
asegurando que la implementación del proyecto
este acorde a la arquitectura.
Fase H: Gestión del Cambio Proveer un monitoreo continuo para asegurar que
la arquitectura responde a las necesidades de la
empresa.
Gestión de requerimientos Examina el proceso de gestión de requerimientos

de arquitectura a través de ADM.
26
Entregables, Artefactos y Bloques de Construcción:
Los arquitectos al desarrollar el ciclo de ADM generan una cantidad de
productos como resultado de su esfuerzo, como flujos de procesos,
requerimientos, planes de proyecto, assessments, etc.
El Architecture Content Framework proporciona un modelo de contenido

estructural que debe ser consistentemente definido, estructurado y presentado:
Deliverables: Es un producto de trabajo que se especifica, se revisa, se

acuerda, y se suscribe (firma) por las partes interesadas.
Artifacts: Es un producto de trabajo de la arquitecta que describe un aspecto

de la arquitectura, generalmente son : Catálogos (Listado de cosas), Matrices
(relaciones entre ellas) y Diagramas (Gráficos de cosas).
Building Blocks: Representan un (potentialmente re-usable) componente de

negocios, IT, o de las capacidades de arquitectura que pueden combinarse con
otros BB para generar soluciones
27
Entregables, Artefactos y Bloques de Construcción:
La relación entre estos elementos se presenta a continuación:
28
Enterprise Continuum
Es el método de clasificación de los productos generados al aplicar el método ADM
y que se ha almacenado en el repositorio Architecture Content FrameWork.
Normalmente es lo denominado taxonomía.
Para simplificar el proceso de creación de una arquitectura de empresa, que dé

respuesta a los requerimientos del negocio, esta se divide en subconjuntos de
arquitecturas relacionadas que enfocan la solución desde conceptos más abstractos
a más concretos, desde términos más lógicos a más físicos y desde un enfoque
más técnico que al de negocio.
29
Partiendo de este continuo de arquitecturas que nos explican y planifican

la SI/TI del negocio generaremos e implementaremos las soluciones en las
que se materializa cada arquitectura creando así un continuo de
soluciones.
Ambos continuos el de arquitecturas y soluciones, visualizan el proceso de

especificación de la arquitectura solución y forman el continuo de empresa.
30
Repositorio de la Arquitectura
Es quien soporta el Enterprise Continuum. Se emplea para

almacenar diferentes clases de productos del ejercicio de
arquitectura (ADM) a diferentes niveles de abstracción. Sus
principales componentes son:
 Arquitectura Metamodel. Describe la organización.

 Arquitectura Capability. Describe parámetros, estructuras que
soportan el gobierno.
 Arquitectura Landscape. Vista arquitectónica de los BB.
 Standards Information Base.
 Reference Library. Guías, patrones, plantillas, para acelerar la
creación de una nueva arquitectura.
 Governance Log. Proporciona una traza del gobierno de la entidad.
31
32
Empleando TOGAF con otros marcos de
Referencia
TOGAF
Guia o
Soporte
Zachman Framework
TOGAF ADM
Método de desarrollo
Federal Enterprise Otros Frameworks
Architecture Framework
32
33
CAPITULO II: ADM Preliminar
9 Fases
4 Dominios(B.D.A.T)
A.
Visión
arquitectura
H.
Gestión B.
Arquitectura 1.Negocios
Cambio Negocios
arquitectura
G. C. 2.Datos
Gestión Arquitectura
Implementación
Gobierno Requerimientos Sistemas
3.Aplicaciones
F. D.
Planeación arquitectura
Migración Tecnología 4.Tecnología
E.
Oportunidades
&
Soluciones
34
CAPITULO II: ADM
El enfoque iterativo
 ADM es iterativo, sobre todo

el proceso, entre fases, y
dentro de sus fases. Para
cada iteración una decisión
actualizada se debe tomar
para:
 — El nivel de cobertura que
se va a definir en la empresa
 — El nivel de detalle al que se
desea llegar.
 — La extensión de tiempo a
tomarse
 — Los activos de arquitectura
a ser entregados, incluyendo:
 — Activos creados en iteraciones

previas
 — Activos disponibles en otras
áreas de la industria
 — (otros marcos de trabajo,
modelos de sistemas, Modelos de
industria, etc.
35
Business Drivers
 Las personas
 La información
 Las condiciones laborales
 Los procesos, tareas y actividades
que apoyan o impulsan el cumplimiento de un(os)

objetivo(s) de negocio.
36 CAPITULO II: El método
Fase Preliminar
Describe las actividades de preparación e iniciación necesarios para

comparecer ante la Junta Directiva con ocasión de una nueva arquitectura
de la empresa , incluyendo la definición de un marco Arquitectura-
específico de la Organización y la definición de principios.
OBJETIVOS
•Preparar la organización para ejecutar proyectos exitosos de arquitectura TOGAF.
•Llevar a cabo las actividades de preparación e iniciación necesarios para cumplir la

directiva de negocios para una nueva arquitectura de la empresa , incluyendo la
definición de un marco de Arquitectura que sea específico a la Organización y
herramientas , y a la definición de principios.
•La Fase Preliminar trata de definir "dónde, qué , por qué, quién , y cómo
desarrollamos la arquitectura" en la organización.
37
CAPITULO II: ADM
Fase Preliminar
Enfoque:
Los principales aspectos son los siguientes:
 Definición de la empresa.
 La identificación de factores clave y elementos en el contexto
organizacional .
 La definición de los requisitos para el trabajo de la arquitectura.
 Definir los principios de la arquitectura que serán guía a cualquier trabajo
de arquitectura.
 Definición del marco de trabajo (framework) que se utilizará
 Definir las relaciones entre los marcos de gestión empleados
 Realizar evaluación de la madurez de la arquitectura de la empresa
38
CAPITULO II: ADM
Fase Preliminar
Definiendo la empresa:
“Que tan grande es el animal”
 El alcance de la empresa determinará los interesados a quienes se les

entregará mayor beneficio de la nueva o mejorada arquitectura
empresarial .
 Es importante nombrar a un patrocinador en esta etapa.
 La empresa puede incluir muchas organizaciones y el deber del
patrocinador es asegurar que todos los interesados se incluyen en alguna
parte de la obra de arquitectura .
39
CAPITULO II: ADM
Fase Preliminar
La identificación de factores clave y elementos en el contexto
de la organización:
Es necesario entender el contexto que rodea la arquitectura . Por ejemplo , las

consideraciones incluyen:
Los modelos comerciales y el presupuesto para la arquitectura empresarial.

Los grupos de interés.
Las intenciones y la cultura de la organización.
Los procesos actuales que apoyan la ejecución de los cambios y el
funcionamiento de la misma.
El paisaje Arquitectura Base .
Las habilidades y capacidades de la empresa.

40
CAPITULO II: ADM
Fase Preliminar
Definición de los requisitos para la
Arquitectura de Trabajo:
Imperativos comerciales dirigen los requisitos y parámetros de rendimiento.

Uno o más de los siguientes requisitos deben ser articulados para que el
patrocinador puede identificar a los tomadores de decisiones clave y a las
partes interesadas y generar una Solicitud de Arquitectura de trabajo:
Los requerimientos del negocio

Aspiraciones culturales
Los propósitos de la Organización
El propósito estratégico
Previsión Necesidades financieras

41
CAPITULO II: ADM
Fase Preliminar
Definiendo los principios de Arquitectura
 El trabajo de Arquitectura es informado por los principios de negocio , así
como los principios de la arquitectura.
 Los mismos principios de arquitectura también están normalmente
basados en parte en los principios de negocio.
 Los principios son normas generales y directrices, destinadas a ser
duraderas y de rara modificación, que informan y apoyan la manera en que
una organización se marca sobre el cumplimiento de su misión.
 Dependiendo de la organización , los principios pueden establecerse dentro
de los diferentes ámbitos y en diferentes niveles. Dos dominios clave
informan al desarrollo y la utilización de la arquitectura:
 Principios de la empresa proporcionan una base para la toma de decisiones en
toda la empresa, e informan cómo la organización va a cumplir su misión.
 Principios de Arquitectura: son un conjunto de principios que se relacionan con el
trabajo de arquitectura. Ellos reflejan un nivel de consenso en toda la empresa , y
encarnan el espíritu y el pensamiento de los principios empresariales existentes .
CAPITULO II: ADM
42
Fase Preliminar
Ejemplo de un Principio
Declaración:
Las operaciones de la empresa se mantienen a pesar de las interrupciones del sistema
Fundamento:
Como las operaciones del sistema se encuentran en toda parte , nos volvemos más dependientes de
ellas ; por lo tanto, debemos tener en cuenta la fiabilidad de este tipo de sistemas en todo su diseño
y uso. La premisa es que en toda la empresa se debe garantizar la capacidad para continuar sus
funciones de negocios, independientemente de los acontecimientos externos. Un Error de
hardware, los desastres naturales , y la corrupción de datos no deben interrumpir o detener las
actividades empresariales. Las funciones de negocio de la empresa debe ser capaz de operar en
los mecanismos de entrega de información alternativos.
Implicaciones
 La dependencia de las aplicaciones indica que los riesgos de interrupción del negocio deben ser
establecidos de antemano y gestionados.
 La gestión incluye, pero no se limita a validaciones periódicos, las pruebas de vulnerabilidad y
exposición, o el diseño de servicios de misión crítica para asegurar la función de continuidad de
negocio a través de capacidades redundantes o alternativos.
 La recuperabilidad, redundancia y capacidad de mantenimiento debería abordarse al momento del
diseño.
 Las aplicaciones deben ser evaluados para la criticidad e impacto en la misión de la empresa, con
el fin de determinar qué nivel de continuidad que se requiere y lo correspondiente plan de
recuperación es necesario
CAPITULO II: ADM
43
Fase Preliminar
TOGAF tiene que co-existir con otras capacidades operacionales de otros

frameworks que se emplean en cualquier organización sean formales o
informales.
Los frameworks que se sugieren sean co-ordinados con TOGAF son:
Capacidades de Negocios (Dirección y Planeación) que determina que
capacidades se requieren para generar la promesa de valor incluyendo la

definición de ROI y los requisitos de control/desempeño.
Gestión de Proyectos Que determina como se manejan las iniciativas en el
organización.
Gestión de Operaciones Que describe como opera la compañía día a día,
incluyendo las operaciones de IT.

Gestión de Soluciones Que formaliza la manera en que los sistemas se
entregan de acuerdo a las estructuras que defina el área de IT.
CAPITULO II: ADM
44
Fase Preliminar
El órden de los pasos se adaptan de acuerdo
a la situación. Deben definirse si es apropiado
efectuar una línea base de la Arquitectura o la 1. Revisar las organizaciones impactadas
Arquitectura objetivo .
2. Confirme los Frameworks de Gobierno y
Soporte
3. Defina y establezca la organización y el
equipo de arquitectura
4. Identificar y establecer los principios de
Arquitectura
5. Adaptar TOGAF y otros frameworks
seleccionados
6. Implementar las herramientas de
Arquitectura
CAPITULO II: ADM
45
Fase Preliminar
 Entradas:
1. Materiales de referencia externos a la empresa: TOGAF, otros
frameworks.
2. Información relacionada a no arquitectura: Estrategias, planes de
negocios, PETI, principios, metas de negocio, portafolio de
proyectos, acuerdos de servicio, alianzas.
3. Información de Arquitectura: Modelo organizacional de la
arquitectura, documentos de arquitectura (si existen)
 Pasos:
 Definir las areas de la organización impactadas
 Confirmar los marcos de trabajo para el soporte y el Gobierno
 Definir y establecer el equipo de trabajo y la organización que
desarrollará la arquitectura.
 Identificar y establecer los principios de arquitectura.
 Implementar las herramientas de arquitectura.
CAPITULO II: ADM
46
Fase Preliminar
Salidas:
 Modelo organizacional para la arquitectura
 Metodologia para la arquitectura
 Repositorio inicial para la arquitectura
 Restablecimiento de principios, metas , conductores del
negocio
 El modelo de gobierno de la arquitectura
21/06/2021 09:29:11 46
Fase A: Visión de la Arquitectura
Describe la fase inicial de un ciclo de Desarrollo de Arquitectura.

Incluye información acerca de la definición del alcance , la
identificación de las partes interesadas , la creación de la Arquitectura
Visión, y la obtención de las aprobaciones.
OBJETIVOS
• Desarrollar una visión de alto nivel de las capacidades y el valor de negocio a ser
entregado como resultado de la arquitectura propuesta.
• Establecer el alcance, limitaciones, y las expectativas para un proyecto TOGAF .
• Crear la visión de la Arquitectura.
• Definir los grupos de interés.
• Validar el contexto empresarial y crear la Declaración de Arquitectura de Trabajo .
• Obtener las autorizaciones para Declaración de Arquitectura de Trabajo .
48
CAPITULO II: El método
Creando la vision de Arquitectura:
 La Visión de la arquitectura ofrece al patrocinador una herramienta clave

para vender los beneficios de la capacidad propuesta a las partes
interesadas y a quienes toman decisiones dentro de la empresa .
 La Visión de la arquitectura describe cómo la nueva capacidad logrará los
objetivos de negocio y objetivos estratégicos y como se abordarán las
preocupaciones de los interesados cuando esta se implementa .
 La Visión de la arquitectura ofrece un primer corte, descripción de alto
nivel de la línea de base y de las Arquitecturas objetivo, que abarca los
dominios de negocio , datos, aplicaciones y tecnología.
 Los escenarios de negocios son una técnica apropiada y útil para
descubrir y requisitos de documentos de negocios , y para articular una
visión de Arquitectura que responde a esos requisitos.
49
50
Financiera Cliente Procesos Aprendizaje y
Desarrollo
Ser miembro activo de la
Desarrollar la eficiencia red de seguridad del Contar con capacidad de
financiera del fondo sistema ejecutar oportuna y Tener información
F.1 F.2 C.1 eficazmente los servicios de alta calidad***
MISIONAL
misionales del Fondo ** AD.2

P.1 P.2 P.3
Robustecer las
herramientas gerenciales Incrementar el indicador
de las entidades inscritas de conocimiento del seguro Tener un sistema de Tener un adecuado
para minimizar el riesgo del depósito información integrado modelo de gestión del
F.3 F.4 C.2 conocimiento***
***
P.4
AD.3
Tener un equipo
APOYO
Lograr la apropiación de los

humano
Corto plazo (Inicia 2017) procesos y la eficiencia en
sobresaliente y
Mediano plazo (Inicia 2018) su operación
P.5 P.6 comprometido
Largo plazo (Inicia 2019) AD.1
** Dentro de los servicios misionales se entienden incorporados los seguimientos y planes de visitas como medidas de prevención de riesgos de las cooperativas
inscritas tanto en operación como en estado de intervención, así como la selección de agentes especiales y/o liquidadores en procesos de intervención.
***Estos objetivos están orientados a desarrollar tanto la parte misional como de apoyo de la entidad.

Identificar , documentar y clasificar el problema de conducir
1. Problema el escenario
Identificar el entorno empresarial y técnica del escenario y

2. Ambiente documentar en modelos de escenarios.
Identificar y documentar los objetivos deseados ( los

3. Objetivos resultados del manejo de los problemas con éxito ) ;
conseguir "SMART" .
 eSpecifico La identificación de los actores humanos (
4. Actores Humanos participantes) y su lugar en el modelo de
 Medible negocio
 Actconable La identificación de los elementos de
 Realístico 5. Actores Sistemas computación y su lugar en el modo de
la tecnología
 Tiempo 6. Roles & Identificar y documentar los roles
Responsabilidad , responsabilidades
7. Refinar Comprobación de
"aptitud para el
propósito " y refinación
sólo si es necesario
1. Establecer el Proyecto de arquitectura
El orden de los pasos debería adaptarse a la 2. Identificar los grupos de interés , inquietudes y
situación. En particular, debe determinar si es requerimientos de negocio
apropiado hacer primero el desarrollo de línea
de base de Arquitectura de Negocios o la 3. Confirmar y Elaborar objetivos de negocio , conductores
Arquitectura de negocios objetivo comerciales y restricciones
4. Evaluar las capacidades de la empresa
5. Evaluar la preparación para la Transformación de

Negocios
6. Definir el alcance
7. Confirmar y elaborar los Principios de arquitectura,

incluyendo los Principios de negocios
8. Desarrollar la Vision de la arquitectura
9. Definir las propuestas de valor de la Arquitectura

objetivo y los KPIs
10. Identificar los riesgos de transformación empresarial y
las Actividades de mitigación
Salidas:
 Declaración de trabajo de la arquitectura aprobada
 Principios, metas , conductores del negocio
refinadas
 Principios de arquitectura
 Revisión de la capacidad
 Visión de la arquitectura
 Borrador del documento de definición de la
arquitectura
Fase B: Arquitectura de Negocios.
Describe el desarrollo de una arquitectura de negocios para

apoyar una visión de arquitectura acordada.
Objetivo:
 Desarrollar la arquitectura objetivo que describe como la organización
necesita operar para lograr los objetivos de negocio y responder a los
conductores estratégicos definidos en la visión de tal forma que cumpla
con la solicitud de arquitectura y los intereses de los stakeholder.
 Identificar la ruta (carta de navegación) de componentes de arquitectura

a desarrollar basados en las brechas existentes entre la arquitectura base
y la arquitectura objetivo.
 Si una empresa tiene descripciones de la arquitectura existente, se deben

utilizar como base para la descripción de línea de base .
 El enfoque normal desarrollo de la arquitectura de destino es de arriba
hacia abajo .
 En la descripción de línea de base , sin embargo , el análisis de la
situación actual a menudo se tiene que hacer de abajo hacia arriba, sobre
todo cuando existen pocos o ningún activos de arquitectura.
 Sea cual sea el enfoque, el objetivo debe ser reuso de materiales
existentes tanto como sea posible, y para recopilar y analizar únicamente
la información que permite tomar decisiones con conocimiento de causa
en relación con la arquitectura de negocios de destino.
"Es importante construir una imagen completa sin entrar en detalles

innecesarios."
 Enfoque:
 El conocimiento de la arquitectura de negocios es prerequisito de

cualquier otro trabajo en otro dominio (Datos, Aplicaciones,
Tecnología), y es la primera actividad de arquitectura que se
requiere.
 Se deben revisar todas las estratégias y planes de negocio
existentes.
 En resumen, la arquitectura de negocios describe la estrategia del
servicio y/o producto y los aspectos organizacional, funcional, de
procesos, de información y geográfico del ambiente de negocio.

Los modelos de negocio deben ser extensiones lógicas de los escenarios
de negocio de la visión de la Arquitectura, por lo que la arquitectura puede
ser trazada a partir de los requerimientos de negocio de alto nivel hacia
unos más detallados.
Una variedad de herramientas y técnicas de modelado pueden emplearse:
•Modelos de actividad ( también llamados modelos de procesos de negocio ):
describen las funciones asociadas a las actividades comerciales de la empresa, los
datos y / o información intercambiada entre las actividades .
•Casos de uso : pueden describir bien los procesos de negocio o funciones de los
sistemas , dependiendo del enfoque del esfuerzo de modelado.
•Modelos Clase: describe la información estática y las relaciones entre la información
.
58
Fase B: Arquitectura de Negocios
El repositorio de Arquitectura.
Como parte de la Fase B, el equipo de arquitectura tendrá que

considerar lo que están disponibles en el repositorio de recursos de
Arquitectura comerciales pertinentes . En Particular:
•Modelos de negocio genéricos relevantes con el sector de la

industria en la que está la organización . Estos son "Arquitecturas
Industria" , en términos del Enterprise Continuum.
•Los modelos de negocio relacionados con los dominios de

negocio de alto nivel comunes.
•Bloques de Construcción específicos de la empresa

(componentes de proceso , reglas de negocio , descripciones de
puestos , etc.).
59
Fase B: Arquitectura de Negocios
21/06/2021 09:29:11 UT Interfactory 59

Fase B: Arquitectura de Negocios. (Pasos).

a la situación. Deben definirse si es apropiado
efectuar una línea base de la Arquitectura o la
Arquitectura objetivo . 1. Seleccione modelos de referencia, puntos de vista y herramientas
2. Desarrollar la descripción de la línea base de la arquitectura de

negocios
3. Desarrollar la descripción de la arquitectura de negocios Objetivo
4. Desarrollar el Gap análisis
5. Definir los componentes claves de la carta de navegación
6. Resolver los impactos a sobre la Arquitectura actual (Landscape)
7. Llevar a cabo una revisión formal de las partes interesadas
8. Finalizar la Arquitectura de negocios
9. Crear el documento de la definición de la Arquitectura
21/06/2021 09:29:11 UT Interfactory 60

Que hace la empresa?
Cómo lo desarrolla?
Cuales son las piezas de información que

se requieren para lograr los objetivos?
Cuales son las funciones claves que deben

Proporcionar los aplicativos?
Cuales son las tecnologías que nuestros negocios

requieren?
Salidas:
 Versión refinada de los documentos revisados
 Borrador del documento de definición de la

arquitectura
 Borrador de la especificación de los requerimientos

de la arquitectura
Fase C: Arquitectura de Sistemas.
Describe el desarrollo de la Arquitectura de Sistemas de

Información para un proyecto de arquitectura, incluyendo el
desarrollo de arquitecturas de datos y de aplicaciones .
Objetivos:
 Desarrollar la arquitectura objetivo de los sistemas de información
(Datos y aplicaciones) describiendo como esta arquitectura
habilitará la arquitectura de negocios y satisfacerá las
preocupaciones de las partes interesadas.
 Identificar los componentes para el Roadmap de Arquitectura

basado en las brechas existentes entre la Arquitectura base y la
Objetivo (Datos y aplicaciones).
64 Consideraciones claves para la
arquitectura de datos
Gestión de datos
 Una definición clara de qué componentes de aplicación en el modelo será el

sistema de registro o de referencia para los datos maestros de la empresa .
 ¿Habrá un estándar en toda la empresa que todos los componentes de la
aplicación, incluyendo paquetes de software, tienen que adoptar ?
 Entender claramente cómo las entidades de datos son utilizados por las
funciones de negocio , procesos y servicios.
 Entender claramente cómo y dónde se crean, almacenan, transportan y reportan
las entidades de datos empresariales .
 ¿Cuál es el nivel y la complejidad de las transformaciones de los datos
requeridos para apoyar las necesidades de intercambio de información entre las
aplicaciones ?
 ¿Cuál será el requisito para el software en el apoyo a la integración de datos con
los clientes y proveedores?
Migración de datos
 Cuando se sustituye una aplicación existente, habrá una necesidad crítica para
migrar datos ( maestro , transaccional y de referencia ) para la nueva aplicación.
 La Arquitectura de datos debe identificar los requisitos de migración de datos y

también proporcionar indicadores en cuanto al nivel de transformación, deshierbe
y limpieza que se requiere para presentar los datos en un formato que cumpla
con los requisitos y limitaciones de la aplicación de destino.
 El objetivo es que la aplicación de destino contenga datos de calidad cuando se

transfiera.
 Asegúrese de que exista una definición común de datos en toda la empresa para
apoyar la transformación .
Gobierno de datos
Asegurarse de que la empresa tiene las dimensiones
necesarias en su lugar para permitir la transformación
 Estructura: Esta dimensión se refiere a si la empresa tiene la estructura organizativa necesaria y los
organismos de normalización para gestionar aspectos de entidad de datos de la transformación.
 Sistema de Gestión: Aquí las empresas deben tener el sistema de gestión necesaria y programas
relacionados con los datos para gestionar los aspectos de la gobernabilidad de las entidades de datos a
lo largo de su ciclo de vida .
 Gente: Esta dimensión aborda qué habilidades relacionadas con los datos y las funciones de la empresa
requiere para la transformación. Si la empresa carece de este tipo de recursos y habilidades , la
empresa debe considerar ya sea la adquisición de las habilidades críticas o la formación de recursos
internos existentes para cumplir con los requisitos a través de un programa de aprendizaje bien definido.
Finalmente se debe considerar el repositorio de datos, que recursos externos se pueden emplear para
construir una adecuada documentación de esta arquitectura.
Fase C: Arquitectura de Datos. Pasos.

a la situación.
1. Seleccione modelos de referencia, puntos de vista y herramientas

datos
3. Desarrollar la descripción de la arquitectura de datos Objetivo
8. Finalizar la Arquitectura de datos

Fase C: Arquitectura de Aplicaciones. Pasos.
a la situación.
1. Seleccione modelos de referencia, puntos de vista y herramientas

aplicaciones
3. Desarrollar la descripción de la arquitectura de Aplicaciones
Objetivo
8. Finalizar la Arquitectura de Aplicaciones

Fase C: Arquitectura de Sistemas.
Salidas:
 Borrador del documento de definición de la arquitectura.
Arquitectura base de datos y aplicaciones – arquitectura
objetivo de datos y aplicaciones, vistas de éstas arquitecturas
evidenciando como se cumplen las necesidades de las partes
interesadas.
 Borrador de la especificación de los requerimientos de la
arquitectura. Resultados de los análisis de brecha,
restricciones sobre la arquitectura de datos y tecnología a ser
diseñada.
 Componentes de los sistemas de información en el
Roadmap.
Fase D: Arquitectura de Tecnología.
Describe el desarrollo de la Arquitectura de tecnología de

Información para un proyecto de arquitectura.
Objetivos:
 Desarrollar la arquitectura objetivo de la tecnología describiendo
como esta arquitectura habilitará los componentes lógicos y
fisicos de datos y aplicaciones, la visión de la arquitectura y
satisfacerá las preocupaciones de las partes interesadas.
 Identificar los componentes para el Roadmap de Arquitectura

basado en las brechas existentes entre la Arquitectura base y la
Objetivo de tecnología.
71
Fase D: Arquitectura de Tecnología
 Enfoque:Se deben revisar

los recursos más
importantes del repositorio
referentes a la tecnología,
en particular:
 Sevicios de IT
existentes
documentados en el
repositorio o en el
catálogo de servicios.
 El TRM (Technical
Reference Model) de
TOGAF
 Modelos de tecnología
genéricos relevantes al
nicho de mercado y a
su sector.
21/06/2021 09:29:11
Fase D: Arquitectura de Tecnología. Pasos.

El órden de los pasos se
adaptan de acuerdo a la 1. Seleccione modelos de referencia, puntos de vista y herramientas
situación. 2. Desarrollar la descripción de la línea base de la arquitectura de
tecnología
3. Desarrollar la descripción de la arquitectura de tecnología
Objetivo
8. Finalizar la Arquitectura de tecnología

Fase D: Arquitectura de Tecnología.
Salidas:
Arquitectura de tecnología (Diagramas de redes, Componentes
de tecnología y sus relaciones, plataformas y su
descomposición Especificaciones de Hardware.
 Componentes de la arquitectura de tecnología que hacen parte
de la carta de navegación.
restricciones sobre la arquitectura de tecnología a ser
diseñada.
 Componentes de los sistemas de información en el Roadmap.
B
1 Cree una línea base
2 Considere las vistas 3 Cree un modelo de arq
6 Defina criterios 4 Seleccione servicios 5 Confirme Obj. Negocio
7a Defina arquitectura
7b Identifique Arch. Building Blocks
8 Conduzca análisis de brecha D

Fase E: Oportunidades y Soluciones.

Lleva a cabo la planificación de la implementación inicial y la
identificación de los vehículos que entregarán la arquitectura
definida en las fases anteriores .
Objetivos:
 Generar una versión inicial completa de la ruta de trabajo
(Roadmap) de la arquitectura basado en los análisis de

brecha y de los componentes de arquitectura identificados
en las fases B, C, y D
 Definir el enfoque incremental, si se requiere, y la transición
de las arquitecturas que entregaran la propuesta de valor.
21/06/2021 09:29:11 75

Objetivos
Generar• la Capacidades
versión completa inicial de
específicas la Hoja
dirigidas de laRuta
para de la Arquitectura
finalización será el , con
Interesados
base en lostemacomponentes
central de del análisis de
la Definición brecha
de la y de los
Arquitectura componentes
( Fases B,C de la
• yFase
Arquitectura E efectuadas
objetivo
D) y , en
es un esfuerzo
base a losenpaquetes
de colaboración
las fases B ,trabajo
de
con las Fase
C y D identificados
partes
E, interesadas
se conciben proyectos.de requerimientos tanto del
negocio como de TI .
Determinar si se requiere un enfoque gradual , y si es así identificar Arquitecturas
•• Los
de transición Debe incluir tanto
queincrementos
entregarán lasgradual,
de forma
de queserán
capacidad aplican y las queesperado.
los controladores
el valor del negocio para
operan
las la infraestructura
arquitecturas de Transición. ( Fase E) que estructuran los
• incrementos
También debe del proyecto.
incluir a los responsables de la
Confirmar la capacidad de la empresa para este proceso de cambio.
planificación estratégica , especialmente para la
• La entrega
creación realarquitecturas
de las será coordinada a través
de transición . de la
Generar y lograr consenso ysobre
implementación un esquema
los planes de implementación
de migración ( Fase F). y estrategia de
migración .
1. Determinar/Confirmar Atributos corporativos
Fase E: Oportunidades y Soluciones. claves de Cambio
2. Determinar restricciones comerciales para la
El órden de los pasos se Implementación
adaptan de acuerdo a la 3. Revisar y consolidar los análisis de brecha
situación. de las fases B a la D
4. Revise Requisitos consolidados en todas las
funciones de negocio relacionados
5. Consolidar y Conciliar Requisitos de
interoperabilidad
6. Refinar y Validar Dependencias
7. Confirmar Preparación y Riesgo para la

Transformación de Negocios
8. Formular la estrategia de Migración e
Implementación
9. Identificar y agrupar los paquetes de
trabajo
10. Identificar las Arquitecturas de transición
11. Crear la Hoja de Ruta de la Arquitectura

& El Plan de Implementación y Migración
Salidas:
Arquitectura de tecnología (Diagramas de redes,
Componentes de tecnología y sus relaciones, plataformas y
su descomposición Especificaciones de Hardware.
 Componentes de la arquitectura de tecnología que hacen
parte de la carta de navegación.
restricciones sobre la arquitectura de tecnología a ser
diseñada.
 Componentes de los sistemas de información en el
Roadmap.
Fase F: Planeando la migración.
Aborda la formulación de una secuencia detallada de

Arquitecturas de transición con una implementación de soporte y
el Plan de Migración.
Objetivos:
 Finalizar el Roadmap de la arquitectura y dar el soporte para el
plan de migración e implementación
 Asegurarse de que el plan de migración e implementación este
acorde con el enfique empresarial para gestionar e implementar
los cambios a lo largo de todo el portafolio de la organización
 Asegurarse que el valor de negocio y el costo de los paquetes de
trabajo y la arquitectura de transición es entendida por las partes
interesadas.

 Enfoque:
 El foco de esta fase es la creación del plan de implementación y
migración en co-operación con los gerentes de portafolio y de
proyectos.
 La fase E proporciona un Roadmap de Arquitectura incompleto y el
plan de implementación y migración que direcciona la solicitud de
trabajo de la arquietctura, por lo cual en esta fase este Roadmap y el
plan son integrados a la actividad de gestión del cambio de la
organización.
 Las activitidades incluyen asesorar las dependencias, costos, y
beneficios de varios proyectos de migración en las actividades de la
organización.
 El Roadmap, y el plan de la fase anterior (E) serán la base para el
plan final que incluirá los proyectos y el portafolio en detalle.
 El ciclo de desarrollo de la arquitectura se finaliza y las lecciones
aprendidas documentadas para habilitar la mejora contínua.
 Hacer análisis costo / Beneficio y de riesgos.

 Desarrollar de deforma
• El objetivo la Fase detallada el Plan
F es la creación de undePlanMigración
de e
implementación
Implementación. y Migración en cooperación con el
 portafolio
Finalizar la Hojade proyectos
de Rutayde administradores
Arquitectura . y el Plan que soporta
• Fase E eproporciona
la Migración una hoja de ruta completa de la
implementación.
Implementación de la Arquitectura y el Plan de Migración
 Asegúrese
que se de quedelala Solicitud
ocupan aplicación y el PlanObra.
de Arquitectura de EnMigración
la se
coordina
Fase con
F este el plan
enfoque de ylala empresa
de trabajo aplicación ypara la degestión e
el Plan
implementación
Migración sede cambios
integran conenel todo el portafolio.
proceso de cambio de la
 empresa.
Asegúrese de que el valor del negocio y el costo de los
• La Hoja
paquetes de Rutay de
de trabajo delalasArquitectura , Versión
Arquitecturas de 0.1 y
transición se
Ejecución y el Plan de Migración , Versión 0.1 de la Fase E
entiende por las partes interesadas.
será la base de la aplicación final y Plan de Migración , que
incluirá el portafolio y detalles a nivel de proyectos.
Fase F: Planeando la migración. Pasos.
El órden de los pasos se adaptan de acuerdo a

la situación.
1. Confirmar Interacciones entre gestión del Framework con

el Plan de Migración & Implementación
2. Asignar un valor de negocio para cada paquete de trabajo
3. Estimar las necesidades de recursos , tiempos de proyecto,

y los mecanismos de disponibilidad / Entrega
4. Dar prioridad a los proyectos de migración a través de la

realización de una evaluación de coste / beneficio y Validación
de Riesgos
5. Confirmar la Hoja de Ruta de la Arquitectura y Actualizar el

Documento de Definición de la Arquitectura
6. Generar el plan de Implementación y Migración
7. Completar el ciclo de Desarrollo de la Arquitectura y

documentar las lecciones aprendidas
Salidas:
El plan de implementación y migración con:
 — La estrategia de implementación y migración
 — Estructura del portafolio y de los proyectos
 — Ubicación de los paquetes de trabajo para el portafolio y los
proyecctos
 — Capacidades entegadas a los proyectos
 — Relación entre la arquitectura objetivo y las de transición
 — Tiempos y cronogramas
 — Estructura de desglose de trabajo
 — Diagramas de proyectos(optional):
 — Oferta de valor
 — Riesgos, tópicos, premisas, dependencias
 — Requerimientos de recursos y costos
Salidas:
 — Costos estimados
 Documento de definición de la arquitectura Finalizado
incluyendo:
 —Arquitecturas de transición Finalizadas
 Especificación de requerimientos de Arquitecturas Finalizadas
 Roadmap de Arquitecturas Finalizadas
 Bloques de construcción de Arquitecturas Re-Usable
 Solicitudes para trabajo de arquitectura para una nueva
iteración de ADM
 Modelo de gobierno de la Implementación.
 Solicitudes de cambio a la capacidad de la arquitectura
originadas de las lecciones aprendidas.
Fase G: Gobierno de la implementacion.

Proporciona una supervisión arquitectónica de la
implementación
Objetivos:
 Asegúrese de la conformidad de los proyectos de
implementación con la arquitectura objetivo.

 Desarrolle funciones apropiadas de gobierno para la
solución de cualquier solicitud de control de cambios

en la implementación.
 Prepara y gestiona los Contratos de Arquitectura
(Junta de Gobierno ) Implementación.
 Asegúrese de que el proyecto de implementación se
ajusta a la arquitectura.
• Tenga en cuenta que , en paralelo con la fase G , no es la

ejecución de un proceso de desarrollo organizacional
específica , donde ocurre el desarrollo real .
• Para activar la pronta realización de valor para el negocio y
los beneficios , y para minimizar el riesgo en el programa
de transformación y migración , el enfoque preferido es el
despliegue de la arquitectura destino como una serie de
transiciones .
• Cada transición representa un paso más hacia el objetivo,
y cada uno ofrece beneficio empresarial por derecho propio

 Enfoque:
En esta fase se trae toda la información recopilada para la gestión exitosa de los
proyectos de implementación al igual que ela ejecución de un proceso de desarrollo
organizacional
Para iniciar con la ofeta de valor y sus beneficios se va construyendo la arquitectura objetivo
a través de arquitecturas de transición para reducir el riesgo de una transformación
abupta. Cada una es un paso incremental hacia la meta y trae sus propios beneficios.
En esta fase:
 Establecer un plan de implementación de las arquitecturas de transición de acuerdo con
el plan de migracióngra
 Adoptar un cronograma en fases que refleje las prioridades de negocio dentro del
Roadmap de arquitectura.
 Seguir los estandares corporativos para IT, y el gobierno de arquitectura
 Use la metodología de gestión de programas y poyectos de la organización
 Defina un maco de trabajo para las operaciones para asegurar un adecuada entrega de
la solución.
 Se establece una conexión entre la Aquitectua base la implementación de la
Organización a través de un contrato de Arquitectura.
 Los proyectos se desarrollan incluyendo:

Nombre, descripción y objetivos
Alcance, entegables y restricciones
 Medidas de eficiencia
Criterios de aceptación
21/06/2021 09:29:11

 Análisis de riesgos

“Es la práctica y la orientación del por qué las arquitecturas
empresariales y otros arquitecturas son gestionadas y
controladas a nivel de toda la empresa.”
Los Dominios del gobierno en la empresa
 Gobierno corporativo
Cada uno de estos dominios de gobierno
 Gobierno de la tecnología pueden existir en múltiples niveles
geográficos - mundial, regional y local -
 Gobierno de IT
dentro de la empresa en general.
 Gobierno de Arquitectura
El gobierno corporativo es un tema muy amplio, más allá del

alcance de un marco de arquitectura empresarial como TOGAF .
89
Fase G: Gobierno de la Implementación
Características del Gobierno
La gobernanza de la arquitectura es la práctica y la orientación en la que las

arquitecturas empresariales y otras arquitecturas son gestionados y controlados
a nivel de toda la empresa . Incluye lo siguiente:
 La implementación de un sistema de controles sobre la creación y el seguimiento de todos

los componentes y actividades de arquitectura , para garantizar la efectiva introducción,
implementación y evolución de las arquitecturas de la organización.
 La implementación de un sistema que garantice el cumplimiento de las normas internas y
externas y obligaciones reglamentarias .
 El establecimiento de procesos que apoyan la gestión eficaz de los procesos anteriores
dentro de los parámetros acordados.
 El desarrollo de prácticas que aseguren la rendición de cuentas a una comunidad claramente
identificados los grupos de interés, dentro y fuera de la organización.
La gobernabilidad de la Arquitectura necesita ser apoyado por un framework de

gobernanza de Arquitectura que ayuda en la identificación de procesos eficaces para
que las responsabilidades empresariales asociados a la gobernabilidad arquitectura
pueden ser dilucidadas , comunicadas , y gestionadas con eficacia.
90
Fase G: Gobierno de la Implementación
Estructura Conceptual
91
Fase G: Gobierno de la implementación
Estructura Organizacional

El órden de los pasos se adaptan de acuerdo a la situación.
1. Confirmar Alcance y Prioridades para la

implementación de la Gestión del Desarrollo
2. Identificar recursos y habliidades requeridos para
implementación
3. Guiar la entrega de soluciones
4. Efectuar revisiones del cumplimiento de la

Arquitectura Empresarial
5. Implementar las operaciones de negocio y de IT
6. Efectuar revisiones post implementación y hacer el

Cierre formal del mismo
Salidas:
 Contrato de arquitectura suscrito.
 Assessments de cumplimiento
 Solicitudes de cambio
 Soluciones de acuerdo a la Arquitectura - incluyendo el sistema
implementado (de hecho es una salida del proceso de desarrollo).
 Repositorio de Arquitectura actualizado
 Recomendaciones y advertencias para el cumplimiento de la Arquitectura
 Recomendaciones para los requerimientos y la entrega de servicio
 Recomendaciones para las métricas de desempeño
 Acuerdos de niveles de servicio
 Vision de la arquitectura actualizada post-implementación
 Documento de definición de la arquitectura, actualizado post-implementación
 Modelos operativos de Negocio —IT para la solución implementada
Fase H: Gestión del cambio.
Establece procedimientos para la gestión del cambio a

la nueva arquitectura .
Objetivos:
 Proporcionar un proceso de gestión del cambio y la supervisión
continua para asegurar que la arquitectura responde a las
necesidades de la empresa y maximiza el valor de la arquitectura
para el negocio.
 Asegurarse de que el ciclo de vida de la Arquitectura se mantiene.
 Asegurarse de que el Marco de gobierno de la arquitectura se
ejecuta.
 Asegurarse que las capacidades de la Arquitectura cumplen con los
requerimientos actuales.

 Enfoque:
Esta fase debe garantizar que la arquitectura logra su oferta de valor, lo cual incluye gestionar los
cambios a la misma de una forma cohesiva y estructurada
Este proceso proporciona un monitoreo contínuo de las solicitudes de gobieno, nuevos desarrollos
tecnológicos y cambios en el ambiente de negocios. Cuando estos cambios surgen se debe
determinar si debe iniciarse un nuevo ciclo de evolución de la arquitectura
Este proceso de gestión del cambio ayuda a que el desarrollo de la Arquitectura sea un poceso
dinámico en la Oganización, que sea flexible para responder rápidamente a los cambios en los
negocios y en la tecnología. Es crucial monitorear el crecimiento o disminución de estos
ambientes.
En la mayoría de los casos la arquitectuta continua pero no todas las soluciones subyacentes
evolucionan y se requiere introducir cambios y la Organización debe ser consciente de esto.
Si la gestión del desempeño y su reporte se diseño para los productos de trabajo en esta fase se trata
de asegurar su efectividad.
Una vez establecida esta fase se determina:
 Las circunstancias bajo las cuales la arquitectura o alguno de sus compoenetes odrán tener modificaciones
despues de su entrega
 Las circunstancias que hacen que el ciclo de desarrollo se inicie de nuevo.
• 1.
En la El objetivo
Fase de un proceso
H es fundamental quede gestión de
el órgano delgobierno
cambio
arquitecturacriterios
establezca es asegurarse que la
para juzgar arquitectura
si una solicitud alcanza su
de cambio
objetivo original
garantiza sólo unadeactualización
valor de negocio. Esto incluyeo la
de la arquitectura si
gestión de
amerita cambios
iniciar un nuevo en laciclo
arquitectura
del Método dedeuna manera
Desarrollo
coherente con
Arquitectura la arquitectura.
( ADM ). Es especialmente importante evitar
2. Este proceso
• "elegancia progresiva"suele, prever la supervisión
y el órgano continua
de gobierno de
debe
asuntos como
continuar para solicitudes
buscar cambios de gobierno,
que se losrelacionan
nuevos
desarrollos encon
directamente la el
tecnología y los cambios en el entorno
valor de negocio.
empresarial.
• Cuando se identifican los cambios, gestión del cambio
determinará si ha de iniciar formalmente un nuevo ciclo
de evolución de la arquitectura.
97
Conductores del cambio.
Hay tres maneras de cambiar la infraestructura

existente que tienen que estar integrados:
 Estratégicos (Top – Down), dirige el cambio para mejorar o

crear nueva capacidad.
 Operativos. (Bottom – Up) para corregir o mejorar una
capacidad existente ( operación y mantenimiento ) en la
infraestructura para la gestión de operaciones
 Experienciales. Con los proyectos previamente entregados,
a través de la gestión de las operaciones, aportan a los
proyectos en marcha
Cambios arquitectónicos se pueden clasificar en una de tres

categorías :
 Simplificación: Un cambio simplificación normalmente se puede

manejar a través de técnicas de gestión del cambio.
 Incremental: un cambio incremental puede ser capaz de ser manejado
a través de técnicas de gestión del cambio , o puede requerir re-
arquitectura parcial, dependiendo de la naturaleza del cambio .
 Re - arquitectura : Un cambio de re- arquitectura requiere poner, de
nuevo, toda la arquitectura a través del ciclo de desarrollo.
Una Buena regla de oro es:
• Si el cambio impacta dos o más grupos de interés ,

entonces es probable que requiera un rediseño de
arquitectura y el reingreso a la ADM .
• Si los impactos del cambio sólo afecta una de las partes
interesadas , entonces es más probable que sea un
candidato para la gestión del cambio .
• Si el cambio se puede permitir bajo una dispensación,
entonces es más probable que sea un candidato para la
gestión del cambio.
Fase H: Gestión del cambio. Pasos

El órden de los pasos se
1. Establecer proceso de generación de Valor adaptan de acuerdo a la
situación.
2. Implementar herramientas de monitoreo
3. Gestionar los riesgos
4. Proporcionar Análisis para la gestión del Cambio

de la Arquitectura
5. Desarrollar las solicitudes de cambio para lograr
los objetivos de desempeño
6. Gestionar el proceso de Gobierno
7. Activar el proceso de implementación de cambio


Salidas:
 Contrato de arquitectura suscrito.
 Assessments de cumplimiento
 Solicitudes de cambio
 Soluciones de acuerdo a la Arquitectura - incluyendo el sistema
implementado (de hecho es una salida del proceso de desarrollo).
 Repositorio de Arquitectura actualizado
 Recomendaciones y advertencias para el cumplimiento de la Arquitectura
 Recomendaciones para los requerimientos y la entrega de servicio
 Recomendaciones para las métricas de desempeño
 Acuerdos de niveles de servicio
 Vision de la arquitectura actualizada post-implementación
 Documento de definición de la arquitectura, actualizado post-
implementación
 Modelos operativos de Negocio —IT para la solución implementada
Gestión de Requerimientos.
Examina el proceso de gestión de requisitos de arquitectura en todo el

ADM.
Objetivos:
 Asegúrese de que se mantiene la arquitectura del ciclo de vida .
 Asegúrese de que se ejecuta el Marco de Arquitectura de Gobierno.
 Asegúrese de que la capacidad de la Arquitectura empresarial cumple con
los requisitos actuales.
 Asegúrese de que el proceso de gestión de requisitos es sostenido y
funciona para todas las fases pertinentes de ADM
 Gestione los requerimientos de arquitectura identificados durate la
ejecución del ciclo de vida de ADM o de una de sus fases.
 Asegurese que todos estos requerimientos esten disponibles para
cualquier fase del ciclo.
Enfoque:
 La gestión de requerimientos es el centro de ADM, no es un proceso
estático por el contrario es dinámico.
 El arquitectpo debe lidiar con los nuevos requerimientos y los continuos
cambios que surgen en ocasión de la ejecución de ADM.
 Hay un ‘‘área gris’’ entre lo deseado por las partes interesadas y lo que se
especifica y diseña como una solución, a menudo hay motivadores y
restricciones (cambio en condiciones de mercado, nuevas leyes, etc.).
 El proceso de gestión de requerimientos no dispone, direcciona o prioriza
estos requerimientos, eso es responsabilidad de cada fase de ADM.
 Se debe usar un repositorio de requerimientos
Desarrollo de requerimientos:
El primer nivel de requerimientos se articula con la vision de la arquitectura
(Escenarios de negocio).
Desde la fase preliminar hasta la H se selecciona los requerimientos
apropiados y se almacenan en el repositorio incluyendo sus

especificaciones.
En cada fase de se deben identificar varios tipos de requerimientos :
 Functional requirements
 Non-functional requirements
 Al definir los requerimientos se considera:
 Premisas básicas (Suposiciones)
 Restricciones
 Principios específicos de dominio
 Políticas que afectan los requerimientos
 Standards que deben cumplirse
 Guias y procedimientos de la organización
21/06/2021 09:29:11 104
 Pasos:
Paso Fase de ADM

•1 Identificar y documentar los
requerimientos, empleando escenarios de
negocio u otra técnica.
•2 •Requerimientos Base
•A- Determine prioridades que surgen de
la fase de ADM
•B- Confirmar los interesados que están de
acuerdo con estas prioridades
•C-Registrar estos requerimientos y sus
prioridades en el repositorio
•3 •Monitorear los requerimientos base

 Pasos:
Paso Fase de ADM
•4 Identificar cambios en los requerimientos
A- Cambiar prioridades
B-Agregar requerimientos y reasignar
prioridades
C-Modificar requerimientos existentes
•5 Identificar los cambios y registrar
prioridades:
a.Señalar requerimientos cambiados y
asegurarse que son priorizados por los
arquitectos encargados de esa fase y los
interesados
b.Registrar nuevas prioridades
c.Asegurarse que cualeuier conflicto se
identifica y se gestiona hasta que se
soluciona
d.Declarar el impacto de estos
requerimientos
21/06/2021 09:29:11 106

 Pasos:
Paso Fase de ADM
•6 a. Valorar el impacto de los
requerimientos cambiados en la fase
actual
b. Valorar el impacto de los
requerimientos cambiados en las fases
anteriores
c. Determinar si se hace el cambio o se
pospone a una fase posterior, si hay
que hacerlo valorar el impacto en los
cronogramas
d. Remitir la declaracion de impacto en los
requerimientos ( Version n+1)
•7 Implementar requerimientos que surgieron
de la fase H
La arquitectura puede cambiar a lo largo del
ciclo de vida por la fase H (Gestión del
cambio). El proceso asegura que cualquier
cambio se gestiona adecuadamente
21/06/2021 09:29:11 107

 Pasos:
Paso Fase de ADM

•8 •Actualizar el repositorio de requerimientos
incluyendo las prioridades y los interesados
afectados
•9 Implementar el cambio en la fase actual
•10 Revisar y Valorar los análisis de brecha de

las fases anteriores. Estos análisis se han
efectuado en las fases B a la D. Algunas de
estas brechas generan requerimientos:
•Algo que esta en la línea base pero no en
la objetivo
•Algo que esta en la arquitectura objetivo
pero no en la de la línea base
Un ‘‘gap de brecha’’ es cualquier cosa

que ha sido eliminado ´por accidente y
requiere ser incluido en la arquitectura
21/06/2021 09:29:11 objetivo. 108
Salidas:
•Assessment del impacto de los requerimientos
•Especificación de requerimientos de arquitectura actualizada.
Cuando surge un nuevo requerimiento o cambia uno existente se debe

efectuar una declaración de impacto en los requerimientos la cual debe
identificar las fases de ADM que requieren ser revisadas
La declaración pasa por varias revisiones (iteraciones) hasta que su

versión final incluye todos los detalles (costos, cronogramas, y métricas
de negocio) en el desarrollo de la arquitectura
110
ADM: Gestión de requerimientos de Arq.
“Proporciona un modelo detallado de los productos de trabajo de

arquitectura , incluyendo entregables , artefactos dentro de entregables , y
Bloques de construcción de la arquitectura (ABBS) que representan los
entregables.”
 Ayuda a mejorar la consistencia de las salidas TOGAF presentándolas de
una manera coherente y estructurada , y también ayuda a hacer referencia
y clasificarlas .
 Proporciona una lista completa de los productos de arquitectura, que

promueve una mejor integración de los productos de trabajo, y proporciona
un estándar abierto detallada de cómo se deben describir las arquitecturas.
 Es una bodega estructurada para los productos del ciclo de ADM .

111 CAPITULO III: Guías y Técnicas:
Técnicas para el desarrollo de la Arquitectura
• Principios de arquitectura
• Gestión de partes interesadas
• Patrones de arquitectura
• Escenarios de negocios
• Análisis de brecha
• Técnicas para planear migraciones
• Requerimientos de interoperabilidad
• Evaluación de la preparación de la transformación de
negocios
• Gestión de riesgos
• Planificación de la capacidad base.
Guías para adaptar ADM
El proceso de (ADM) se puede adaptar para trabajar en diferentes

escenarios y para específicas arquitecturas, e incluye :
•Aplicar en la ejecución de ADM

•Aplicar ADM sobre arquitectura Landscape
•Revisar la arquitectura de seguridad y ADM
•Usar TOGAF para definir y gobernar SOAs
Iteraciones de ADM
Una iteración es el proceso de describir un punto de vista (Landscape)

de la arquitectura a través de múltiples ciclos de ADM basado en
iniciativas individuales que estan vinculadas a la visión de la solicitud
para el trabajo de arquitectura.
En segundo lugar una iteración describe el proceso integrado de

desarrollar una arquitectura donde las actividades de las distintas fases
de ADM interactuan para producir una arquitectura integrada.
Finalmente una iteración describe el proceso de gestionar el cambio en

las capacidades de arquitectura de la organización.
Iteraciones para un LandScape
Proyectos pasan por todo el ciclo de ADM, iniciando por la fase A ,

cada ciclo debe estar vinculado a una solicitud de trabajo de
arquitectura. El resultado es un landscape o una modificación del
existente.
Diferentes proyectos pueden operar en un mismo ciclo de ADM

concurrentemente e interrelacionados.
Un proyecto puede generar el inicio de otro. Normalmente pasa cuando

las iniciativas de arquitectura de alto nivel identifican oportunidades y
soluciones que requieren un mayor detalle de la arquitectura o cuando
se identifican impactos en el alcance de la solicitud de trabajo.
Iteraciones para un ciclo de ADM
• Proyectos pueden operar en multiples fases concurrentemente.

Interrelación entre negocios, sistemas y tecnología
• Los proyectos pueden efectuar ciclos entre fases de ADM.
• Los proyectos pueden retornar a fases previas para actualizar

productos de trabajo con nueva información.
Gestión de los stakeholders

“les ayuda a garantizar que sus proyectos tengan éxito donde otros fracasan al gestionar grupos
de interés.”
Clasifique las posiciones de los interesados
Determine su enfoque de gestión de los interesados
C D
Alto Mantener Jugadores
Satisfecho Clave
Poder
A B
Bajo Minimo Mantener
Esfuerzo informados
Bajo Alto
Nivel de interés
Análisis de brecha
“Empleado para validar una arquitectura que está siendo desarrollada.”
 Elaborar una matriz con todos los Architecture Building Blocks (ABBS) de la Arquitectura de
referencia sobre el eje vertical, y todos los de ABB de la Arquitectura de destino en el eje
horizontal.
 Añadir a la arquitectura de línea de base del eje A última fila con la etiqueta "Nuevo", y al eje
de Arquitectura de destino una última columna etiquetada "Eliminado".
 Cuando un ABB está disponible tanto en la línea de base y Target Arquitecturas, grabar esto
con "incluido" en la celda de intersección.
 Cuando un ABB de la arquitectura de línea de base no se encuentra en la arquitectura de
destino, cada uno debe ser revisado. Si fue eliminado correctamente, marcarlo como tal en la
celda "Eliminado" apropiada. Si fue, una omisión accidental en la Arquitectura objetivo, se ha
destapado que debe ser abordado por el restablecimiento de la ABB en la próxima iteración
del diseño de la arquitectura - marcarlo como tal en la celda apropiada "Eliminado".
 Cuando un ABB de la arquitectura destino no se puede encontrar en la arquitectura de línea
de base, marcarlo en la intersección con la fila "Nueva" como una brecha que necesita cubrir,
ya sea mediante el desarrollo o adquisición de bloque de construcción.
Análisis de brecha
Técnicas para planear migraciones

Planeación de la capacidad Instalada

“se centra en la planificación, ingeniería, y la entrega de las capacidades estratégicas
de negocio para la empresa.”
 Es el impulso de negocio y el liderazgo empresarial y combina los esfuerzos

necesarios de todas las líneas de negocio para alcanzar la capacidad deseada
.
 Planificación basada en la capacidad de alojar la mayoría, si no todos, los
modelos de negocio corporativos.
 Muchas capacidades son "horizontal " y van a contra del gobierno corporativo.
 Las trés dimensiones de las capacidades:
1. Gente: Entrenaniento
2. Procesos: de Negocios/Gestión de Información
3. Materiales: Infraestructura/Equipo Tecnológico
Planificación de la capacidad Instalada
Muchas capacidades
son horizontales y van
en contra del gobierno
corporativo
Las vistas y los puntos de vista de Arquitectura
Punto de Vista
Vista  Vista : Es una
Data Function Network People Time Motivation
(What) (How) (Where) (Who) (When) (Why) representación de un
Key: Arquitectura de Negocios
sistema
perspectiva
desde
de
la
un
List of List of List of locations
important processes where the
List of
Lit of business List of business
conjunto relacionado de
Planer View organization
things to
enterprise
the enterprise
performed
enterprise
operates
units
events/cycles objectives
preocupaciones. Una vista
Entity
es lo que se ve (o lo que
Business Logistics Organizational Business Master
Owner’s View Relationship
diagram
Process Model Network Chart Schedule
Business Rules ve una de las partes
interesadas) . Las vistas
Arquitectura de Información son específicas.
Essential data Distributed Human Dependency
Designer’s
Data model flow, application system interface diagram, entity
Business Rule  Punto de Vista: Donde
View architecture architecture architecture life history
model
usted está viendo: el
Arquitectura de Tecnología punto de vista
perspectiva. Los puntos
o
System design:
Builder’s View
Data
Architecture
structure chart,
Systems
Architecture
User interface
design
Control flow
diagram
Business Rule
design
de vista son genéricos .
pseudo code
Un modelo (o descripción)
Data design, Detailed Network Timing of
Rule de la información
Detailed View physical storage program design Architecture
Screens
definitions
specification in
program logic contenida en una vista.
123
Iteraciones de ADM
•Ciclo de arquitectura Capability. Las
iteraciones soportan la creación y
evolución de la capacidad de
arquitectura requerida, esto incluye el
ejercicio inicial de establecer principios,
visión, alcance y gobierno.
•Ciclo de arquitectura Development

Las iteraciones permiten la elaboración
del contación de ón enido al efectuar el
ciclo a través de las fases de Negocios,
sistemas de información y tecnología.
•Ciclo de Transition Planning Permiten

la creación de roadmaps para la
arquitectura definida.
•Ciclo de arquitectura Governance

Deben soportar el gobierno y el control
sobre los cambios.
124 Tipos de arquitectura en
las iteraciones (LandScape)
Panorama de la Arquitectura
Muestra como el AM (Modelo de Arquitectura) ha cambiado a través del tiempo.
Arquitectura Estratégica proporciona un marco organizativo para la actividad
operativa y el cambio y permite la configuración de dirección a nivel ejecutivo .
Arquitectura segmento ofrece un marco de organización para la actividad operativa
y el cambio y permite la configuración de la dirección y el desarrollo de los planes de
trabajo de arquitectura eficaces a nivel programa o cartera.
Arquitectura capacidad proporciona un marco de organización para la actividad de
cambio y el desarrollo de planes de trabajo eficaces arquitectura realizando
incrementos de capacidad.
2000 2005 2010 2015
Strategic Architecture
AM 1 AM2 AM3 AM4 Segment Architecture
Capability Architecture
Architecture Landscape
Clasificación de Arquitectura en la Organización

127
Engagement de la Arquitectura
Identificación de un cambio requerido: Fuera del contexto de cualquier iniciativa de cambio, la
arquitectura puede usarse como una técnica para proporcionar visibilidad de las capacidades de IT para
soportar la toma de decisiones y el alineamiento a la ejecución.
Definición del cambio: Cuando se requiere un cambio, la arquitectura puede usarse como una técnica
para definir la naturaleza del mismo y su forma.
Implementación del cambio: La arquitectura puede usarse a todo nivel de la organización para
proporcionar el gobierno sobre las iniciativas de cambio al proporcionar una visibilidad de big-picture,
aportar las restricciones estructurales y definir los criterios para evaluar las decisiones técnicas.
128
Iteraciones de ADM
Todas estas técnicas son aplicaciones válidas para ejecutar ADM. Este proceso se
emplea dependiendo de estos factores organizacionales:
 La naturaleza y formalidad de los puntos de chequeos establecidos a los

procesos dentro de la organización. La organización demanda que cierto grupo
de actividades se lleven a cabo entre los puntos de chequeo? Además demanda
que ciertas actividades estén finalizadas antes de ejecutar otras?
 El nivel de involucramiento de las partes interesadas en el proceso. Los
interesados están cercanamente involucrados en el desarrollo de una solución o
espera solo que se les entreguen los resultados para una revisión de aprobación.
 El número de equipos involucrados y su relacionamiento. El trabajo de
arquitectura lo realiza un solo equipo o existe una jerarquía de equipos con
relaciones de gobierno?
 La mayoría de la solución y el trabajo que se espera realizarse pueden llevar
a una solución aceptable. Puede la solución ser obtenida en un solo paso o
requiere una extensa prueba de concepto o el uso de prototipos.
 Apetito de riesgo. La cultura organizacional reacciones negativamente a
productos parciales? La cultura organizacional requiere soluciones a ser probadas
en un ambiente de pruebas antes de ser puestas en operación.
 La clase de Engagement. Cuál es el contexto del desarrollo de la arquitectura?
129
arquitectura Continuum
 El arquitectura Continuum proporciona un método para dividir de forma
abstracta cada nivel de arquitectura, ofreciendo una forma consistente
definir y entender las reglas genéricas, representaciones y relaciones de
la misma, incluyendo su trazabilidad y relaciones de derivación
 The arquitectura Continuum es una poderosa herramienta para identificar
rasgos comunes y elimina la redundancia innecesaria.
 Manejar la complejidad de cada arquitectura o solución individual.

 Definir agrupaciones
 Definir jerarquías y estructuras de navegación
 Apropiar procesos, roles, y responsabilidades atadas a cada grupo
130
Organizando el LandScape
Estas son las características para organizarlo:
 Amplitud: Conocido como (sujeto principal) la característica
primaria de la organización para describir el landscape. Las
arquitecturas están descompuestas funcionalmente en jerarquías
o segmentos
 Profundidad: En amplias áreas, menos detalle se requiere para
lograr un tamaño y complejidad adecuados. Cuando hay mas
áreas generalmente se requiere mas arquitecturas detalladas.
 Tiempo: De acuerdo al sujeto y a la profundidad se puede crear
una línea base y un conjunto de arquitecturas objetivo. Amplias y
menos arquitecturas detalladas serán válidas para ciertos
periodos de tiempo.
 Actualización: La vista de arquitectura progresa a través de ciclo
de desarrollo y mejora su contenido hasta su aprobación,
después de esto pierde su vigencia si no se mantiene
constantemente.
131 CAPITULO IV: Architecture Content FrameWork
 El Architecture Content Framework emplea las siguientes tres categorias para

describer el tipo de producto del trabajo de arquitectura en el contexto de uso:
Un Bloque de Construcción
representa un ( potencialmente
Un Artefacto es un producto de reutilizable ), componente de
Un Entregable es un producto la obra arquitectónica más granular negocio, de IT, o de la capacidad
de trabajo que se especifica que describe una arquitectura desde de arquitectura que se puede
contractualmente, es revisado, un punto de vista específico . Los combinar con otros bloques de
acordado y suscrito por las partes ejemplos incluyen un diagrama de red construcción para entregar
interesadas. , una especificación de servidor, una arquitecturas y soluciones. Bloques
Los entregables representan la especificación de casos de uso , una de construcción se pueden definir
salida de los proyectos y los lista de requisitos arquitectónicos , y en varios niveles de detalle y
entregables que se encuentran en una matriz de interacción de negocios pueden relacionarse con las
forma de documentación . Los artefactos se clasifican arquitecturas y soluciones, con
típicamente se archivan en la generalmente como catálogos ( listas bloques de construcción de
finalización de un proyecto, o como de cosas), matrices (que muestra las Arquitectura (ABB)
evoluciones del repositorio de relaciones entre las cosas) y típicamente describiendo la
arquitectura como un marco de diagramas (imágenes de las cosas ) . capacidad requerida con el fin de
referencia , estándar, o una foto Un entregable puede contener dar forma a los bloques de
instantánea de la arquitectura en muchos artefactos y estos artifactos construcción de la solución (SBB)
un momento dado. formarán el contenido del repositorio lo que representaría los
de Arquitectura . componentes para ser utilizados
para implementar la capacidad
requerida .
Relación entre estos elementos
 Arquitectura Building Blocks ( ABBS ) suelen describir la capacidad requerida y conforman la

especificación de Solución Building Blocks ( SBB ). Por ejemplo , una capacidad de servicio
al cliente puede ser necesaria dentro de una empresa , con el apoyo de muchos SBB, como
los procesos, datos y software de aplicación.
 Solución Building Blocks ( SBB ) representan los componentes que se utilizarán para
implementar la capacidad requerida. Por ejemplo , una red es un bloque de construcción que
se puede describir a través del artefacto complementaria y luego objeto de un uso para darse
cuenta de las soluciones para la empresa.
Artefactos
 Preliminary  Arquitectura de aplicaciones

 Catalogo de Principios  Catálogo Cartera de Aplicaciones
 Visión de la arquitectura  Catálogo Interface Sistema
 Matriz de los Stakeholder  Matriz Roles de Organización Rol
 Diagrama de la cadena de valor  Matriz Sistemas
 Diagrama conceptual de las soluciones  Matriz Funciones de Aplicación
 Arquitectura de Negocios  Matriz de interacción
 Catalogo de Organización/Actor  Diagrama de comunicaciones de la
aplicación
 Catalogo de roles
 Diagrama de Aplicaciones y usuarios
 Catálogo de Servicios/Funciones de
Negocio  Diagrama de Casos de Uso
 Matriz de interacción de Negocios  Arquitectura Tecnología
 Matriz de Roles/Actores  Catálogo de Estándares de
 Diagrama de Servicios de Tecnología
Negocio/Información  Catálogo de portafolio de Tecnología
 Diagrama de Descomposición Funcional  Matriz de Entornos Tecnológicos y
 Diagrama de ciclo de vida del Producto diagrama de las ubicaciones
 Diagrama de descomposición de la
 Arquitectura de Datos Plataforma
 Catálogo de datos Entidad
 Oportunidades y Soluciones
 Componente de Datos
 Diagrama de contexto de proyectos
 Diagrama de Clases
 Diagram de Beneficios
 Diagrama de Divulgación de Datos
 Gestión de Requerimientos
133  Catálogo de Requerimientos
Entregables
 Bloques de construcción de la  Plan de Comunicaciones

arquitectura  Valoración cumplimiento
 Contrato de la arquitectura  Plan de Implementación y de
 Documento de la definición de la migración
arquitectura  Implementación modeo de
 Principios de arquitectura Gobierno
 Repositorio de la arquitectura  Modelo Organizacional para la
 Requerimientos de arquitectura arquitectura empresarial
 Ruta de la arquitectura  Solicitud para el trabajo de
 Visión de la arquitectura arquitectura
 Principios de negocio, metas  Valoración del impacto de los
premilinares de negocio, y requerimientos
conductores de negocio  Bloques de construcción de
 Valoración de las Capacidades soluciones
 Solicitud de Cambio  Declaración de trabajo de la
arquitectura
 Framework de Arquitectura
Slide 134
 Arquitecturas de transición
Building Blocks
Los Building blocks tienen las siguientes características genéricas:
 Un bloque de construcción es un paquete de funcionalidades definidas para satisfacer

las necesidades de su negocio a través de una organización.
 Un bloque de construcción tiene un tipo que corresponde al contenido metamodelo
TOGAF (como actor, servicios a empresas, la aplicación o la entidad de datos )
 Un bloque de construcción tiene un límite definido y es generalmente reconocido como
" una cosa" por expertos de dominio.
 Un bloque de construcción puede interoperar con otros bloques de construcción,
interdependientes.
 Un buen bloque de construcción tiene las siguientes características :
 Se considera la implementación y uso, y evoluciona para explotar la tecnología y las normas.
 Puede ser montado a partir de otros bloques de construcción.
 Puede ser un subconjunto de otros bloques de construcción.
 Lo ideal es un bloque de construcción es reutilizable y reemplazable , y bien especificado.
135
136
Content Metamodel
Proporciona una
definición de todos los
tipos de bloques de
construcción que
puedan existir dentro de
una arquitectura, que
muestra cómo estos
bloques de construcción
pueden ser descritos y
relacionados entre sí
136
Entidades del metamodelo y sus interrelaciones
138 CAPITULO V: Enterprise Continuum
 Es una vista del Repositorio Arquitectura que ofrece métodos para clasificar la
arquitectura y artefactos de solución a medida que evolucionan a partir de
arquitecturas genéricas (de la Fundación) a las arquitecturas de Organización más
específicos.
 Comprende dos conceptos complementarios:
 Architecture Continuum- ofrece una forma coherente para definir y entender las reglas
genéricas, representaciones y relaciones en una arquitectura, incluyendo las relaciones de
trazabilidad y de derivación (por ejemplo , para demostrar que una Arquitectura Específica
de la Organización se basa en un estándar de industria). Representa una estructuración de
Building Blocks de Arquitectura (ABB).
 Solutions Continuum - Ofrece una manera consistente para describir y comprender la
implementación de los activos definidos en la Arquitectura Continuum. El Continuum
Soluciones define lo que está disponible en el entorno de la organización como lo es los
Solution Building Blocks (SBB ) reutilizables.
 Ofrece una vista del Repositorio Arquitectura que muestra la evolución de estas
arquitecturas relacionadas de lo genérico a lo específico, de lo abstracto a lo
concreto y de lo lógico a lo físico.
 Consta de todos los activos de la arquitectura; es decir, modelos (por ejemplo .
TRM) , modelos, descripciones de arquitectura , y otros artefactos producidos
durante la aplicación de la ADM.
Es un "repositorio virtual“ de todos los artefactos arquitectónicos

disponibles en una organización. Incluye modelos arquitectónicos,
patrones de arquitectura, descripciones arquitectónica, entre otros.
Estos artefactos pueden existir específicamente al interior de la
empresa, o en la industria de Tecnologías de Información.
Consiste en:
 Continuum Arquitectónico especifica la estructura de los artefactos

arquitectónicos reutilizables, incluyendo reglas, representaciones y
relaciones de los sistemas de información disponibles en la
organización.
 Continuum de Soluciones describe la implementación del
Continuum Arquitectónico mediante la definición de bloques
constitutivos de solución (solution building blocks, en inglés).
 Arquitectura Fundacional, es la más general y contiene los principios de arquitectura
(estándares y bloques de construcción reusables) que utilizará cualquier organización
de la IT. TOGAF provee la descripción de una arquitectura fundacional en su modelo
de referencia técnico, TRM.

Arquitectura Común de Sistemas, se soporta en la arquitectura base y a partir de la
elección e integración de los servicios adecuados genera soluciones de dominios
específicos como pueden ser seguridad, operaciones, etc. que a su vez se convierten
en bloques reusables. TOGAF provee de una arquitectura común de sistemas en su
modelo de referencia de diseño de una infraestructura de integración de información
que especifica partes de la TRM, III-RM.
 Arquitectura de Industria, se encarga de integrar las soluciones de dominio en

soluciones específicas para un tipo de industria determinada como puede ser la salud,
la energía, etc.
 Arquitectura de Organización, es la más específica y guía el despliegue de la

arquitectura solución, resultado de la integración de las soluciones de industria,
adecuada para una empresa en particular.
Architecture Continuum
Un Architecture Foundation es
una arquitectura
Arquitecturas de bloques
- organización de
Sistemas Comunes Arquitecturas
Arquitecturas Industria construcción
específica
guían la los ymás
son sus guian la selección e integración de
correspondientes
relevantes
integración de los componentes normasde
para la comunidad queservicios específicos de la
los
soporta
clientes
de los sistemas comunes de TItodos
con los describen
, ya que sistemas de
Architecture Foundation para crear
arquitecturas
y guían
componentes específicos comunesfinal
la implementación
de la y ,una
por arquitectura
lo útil para la
industria , y guían la tanto
decreación
los , de
el ambiente
componentes operativo
escritos por
construcción de soluciones
soluciones de la industriaempresarial.Eg
el usuario
parao de tercerosel modelo de
que comunes en un amplio número de
referencia
constituyen
los problemas específicos de los técnica (eficaces
soluciones TRM )dominios relevantes . Por ejemplo
paraindustria
clientes dentro de una determinadas empresas .Integrado de Información de
en particular. Referencia Infraestructura Modelo
(III -RM)
Foundation Arch. Common Systems Arch. Industry Arch. Organization Arch.

Solutions Continuum
Las Soluciones Comunes de
Sistemas representan colecciones
Una solución Específica acomunes la de requisitos y
Soluciones
organización base
es son conceptos
una muy
Una solución de Industria genéricos
es , una
herramientas, capacidades
productos , , en lugar de las
implementación de
servicios y componentes
una
específicas
de la solución,a un cliente o industria
implementación de una Arquitectura de
arquitectura
Industria, que proporciona que específica
son los
paquetes proveedores
de deen laparticular. Estas proporcionan a
fundamentales
organización-
componentes reutilizables que proporciona
de y capacidades.
servicios Por
las ejemplo:
organizaciones entornos
comunes específicoslaspara
funciones
Lenguajes requeridas
de
una industria. por la
programación,
operativos losespecíficos para las
Componentes empresa.sistemas operativos,
fundamentales son las estructuras operativas
necesidades y de
proporcionados porEllos fundamentales
sistemas comunes
contienen para la organización
buena cantidad de
información , tales como alta
Soluciones y / o Fundación las operaciones
Solutions, y se de TI (como ITIL).
de contenido único con el findisponibilidad
de
aumentan con componentes específicos de
de procesamiento de
conciliar los distintos procesos y
transacciones y sistemas de
la industria.
personas dentro de la empresa almacenamiento de datos
escalables. Ejemplos de estas
Foundation Arch. Common Systems Arch. Industry Arch. incluyen-:
soluciones Organization
Un ERPArch.
y un
producto de sistema de seguridad.
145
Categorización de la documentación
 Core
 Conceptos fundamentales que forman la esencia de TOGAF, p.e:
Estructura básica.
 Mandated
 Partes normativas de la especificación TOGAF
 Parte superior central de su uso
 No sería reconocible TOGAF si no se utiliza
 P.e: Objetivos, entradas, salidas.
• Recommended
 Pool de los recursos que se hace referencia específicamente en TOGAF
que puede ser utilizado para ayudar a los profesionales. P.e: Escenarios
de negocios, Análisis de brecha.
 Supported
 No se hace referencia en las otras tres categorías, pero puede
proporcionar una valiosa ayuda. P.e: Criterios de evaluación. Notas.
146
Manejo de Versiones
Fase Entregable Contenido Version Descripción

Business 0.1
Architecture
Data 0.1
Architecture Version 0.1 indica que un
A: Architecture Architecture
esquema de alto nivel de la
Vision Vision Application 0.1 arquitectura está en su lugar
Architecture
Technology 0.1
Architecture
B: Business Architecture Business 1.0
Architecture Definition Architecture
Document
C: Information Architecture Data 1.0
Systems Definition Architecture Versión 1.0 indica
Architecture Document Revisado formalmente ,
Application 1.0 arquitectura detallada.
Architecture
D: Technology Architecture Technology 1.0
Architecture Definition Architecture
Document
21/06/2021 09:29:11 UT Interfactory 146
147
CAPITULO VI: Modelos de Referencia
 Hay dos modelos técnicos de referencia
• TRM • III-RM
– Technical Reference – Integrated Information
Model Infrastructure
148
 La Arquitectura base se encarna en el Modelo de

Referencia Técnica (TRM ), que proporciona un modelo y
taxonomía de los servicios de la plataforma genéricos.
 La TRM es de aplicación universal y, por lo tanto, se puede
utilizar para construir cualquier arquitectura de sistema .
 Cualquier TRM tiene dos componentes principales : (igual
III- RM)
Taxonomia : Define la terminología, y proporciona una descripción
coherente de los componentes y una estructura conceptual del
modelo.
Gráfica : Proporciona una representación visual de la taxonomía, y la
interrelación de sus componentes.
149
Gráfica
TRM
Taxonomía
Foundation
architecture
Standards
Information Base
(SIB)
150
 Portabilidad de
aplicación
 Como las aplicaciones o el
uso de los servicios está
disponible a través de la
plataforma.
 Se hace a través de la
interface de plataforma de
aplicaciones
 Interoperabilidad
 Como se comunican las
plataformas de
Diversidad debe reducirse al mínimo aplicaciones entre sí
entre la plataforma de aplicaciones
y la infraestructura de  Se hace a través de la
comunicaciones
interface de infraestructura
de comunicaciones
151
“El problema a resolver es el flujo de información sin fronteras”
•Imagine una compañía normal con múltiple dependencias,

cada una, con sus sistemas y datos
Ventas Internal Space Compras
Sistemas Sistemas Sistemas Sistemas Sistemas
datos datos datos datos datos

Soporte al Producción Ensamblaje Adtva & Adquisiciones
cliente financiera
152
 Como entender el panorama?
Agrupación funcional
•No pueden ser entrenados en todos los sistemas !

•Todos los sistemas son propiedad y tienen diferentes medios de acceso
•El tiempo dedicado a la coordinación con los equipos, lo hace mas lento

cliente financiera

153
Integrated Information Infrastructure Reference Model (III-RM)
“La capacidad de la información a permear límites tales como los departamentos y

organizaciones.”
 El III- RM es un subconjunto de la TRM (TOGAF ) en términos de su alcance

general, pero además también expande ciertas partes de la TRM - en particular,
las aplicaciones empresariales y de infraestructura de aplicaciones - con el fin de
proporcionar ayuda en el tratamiento de una de los desafíos claves que enfrenta
el arquitecto empresarial de hoy : la necesidad de diseñar una infraestructura de
información integrada para permitir el Flujo de Información sin fronteras .
 El modelo asume la existencia subyacente de una plataforma de computación y
la red, como se describe en el TRM
Se trata de una
arquitectura común de
sistemas.
154
“El problema a resolver es que los sistemas son propietarios y

tienen diferentes medios de acceso”
•Libere los datos, proporcionando una interfaz abierta al sistema a

través de una interfaz, que haga los datos más accesibles .
•Estas aplicaciones tienden a trabajar por solicitud, dando respuesta a
la arquitectura, se hace un llamado a una interfaz abierta, que a su
vez llama a una interfaz propietaria en tiempo de ejecución , se
devuelve una respuesta que se convierte en la respuesta de interfaz
abierta .
•Abstrae la función de llamada de las llamadas de interfaz de
propiedad del sistema. Además, si el sistema de corrección se
sustituye el IPA tendrá que cambiar, pero la función de la persona que
llama no puede.
155
• Introduciendo aplicaciones proveedoras de información (IPA)

Cross functional
Group
Aun se mantienen muchas interfaces
Interfaces Abiertas
IPA IPA IPA IPA IPA

Interfaces Propietarias

cliente financiera
156
“El problema a resolver es que los sistemas son propietarios y

tienen diferentes medios de acceso”
•Si el número de interfaces es alto (API) y los requisitos de información

son amplios es probable que muchas interfaces pueden ser llamados
para satisfacer un tipo de solicitud de información.
•Estas aplicaciones (Brokering) sirven a una única solicitud que tiene
muchas fuentes de información. Lo hace mediante la ruptura de una
solicitud en varios despachos y recopila todas las respuestas
•Estas aplicaciones se pueden utilizar para permitir el acceso a la
información externa socios
157
• Introducing brokerage applications(BA)

Agrupación
Partner
Donde está la interface al usuario, que functional
las aplicaciones Brokerage no tienen cruzada externo
ninguna?
Interfaces abiertas
BA BA BA
Interfaces abiertas
IPA IPA IPA IPA IPA
Interfaces Propietarias

cliente Financiera
Ventas Ambiente interno
158
 Hay un numero de plataformas de servicio requeridos para que III-

RM trabaje:
 Servicios de ingeniería de Software
 Lenguajes de programación, Librerias etc
 Servicios de Seguridad
 Single Sign on, firewalls, etc
 Servicios de directorio y de localización
 Naming, Discovery, registering
 Servicios de intercambio de datos
 Mensajería entre aplicaciones
 Servicios de Interface al usuario
 Browser
 Servicios de gestión de datos
 Search, file, query
 Servicios de eventos y de flujos de trabajo
159
TRM Vs IIIRM
 IIIRM Consiste en : Aplicaciones, Plataforma de aplicaciones, y

Cualidades
 Pasa nuestra atención de plataforma de aplicaciones en TRM a

Aplicaciones en IIIRM
 TRM es una "Foundation Architecture“ en el Enterprise Continuum.

IIIRM es un "Common Systems Architecture" .
 IIIRM es un subconjunto de TRM en terminos de su alcance, pero

además extiende el aspecto de aplicaciones a el flujo de información sin
fronteras ("boundaryless information flow“).
160
Gráfica
IIIRM
Taxonomía
Common
System
Architecture
Standards
Information Base
(SIB)
161 CAPITULO VII: Architecture Capability FrameWork
Architecture Capability Framework
Capítulo Descripción
Establishing an Architecture Directrices para el establecimiento de la Capacidad de
Capability Arquitectura dentro de una organización.
Architecture Board Lineamientos para establecer y operar un Junta de
Arquitectura de la empresa .
Architecture Compliance Directrices para garantizar el cumplimiento de proyectos
de arquitectura.
Architecture Contracts Directrices para la definición y el uso de Contratos de
Arquitectura.
Architecture Governance Marco estratégico y lineamientos para la Gobernabilidad
de la Arquitectura.
Architecture Maturity Las técnicas para evaluar y cuantificar
Models la madurez de la arquitectura en una organización.
Architecture Skills Un conjunto de normas para roles, habilidades y
Framework experiencia que se comprometan con la arquitectura
empresarial.
Capacidades empresariales para la Arquitectura
Para llevar a cabo de

forma efectiva, el
desarrollo de la
arquitectura, se
requiere dar lugar a
las capacidades del
negocio dentro de la
organización a través
de estructuras, roles,
responsabilidades,
habilidades y
procesos.
Capacidades empresariales para la Arquitectura
Cuerpos de Gobierno
Asignar prioridad y Medida del éxito
Directo enfoque
prioridad y
enfoque
Asignar
Pool de recursos Gobierno Proyectos/
Participa en
Portfolio
Entrenamiento
Aumenta Roles y Proyectos/

Responsabilidade Portafolio
Requiere gobernado Operaciones
s Contrato
Habilidad Conocimiento contra los Negocio
(Tantp genericos
como especificos contratos
Requiere a un Proyecto
soluciones
particular)
alineadas
Posee Posee
Entregar
Participa en
Profesionales
Arquitectura
Asigna
Proyectos/ Portafolio
Conformando el Re-usar los building blocks y
repositorio cumplir con los estándares
Architecture Repository
21/06/2021 09:29:12 UT Interfactory 163
CAPITULO VII: Architecture Capability FrameWork
164
Componentes
Interesados externos Capacidad de la Interesados internos
arquitectura
Empleando ADM Consejo de
para establecer la arquitectura
capacidad de la
Modelos de arquitectura
Madurez de Contratos
Arquitectura Cumplimiento
Principios
Framework de las
habilidades de la Patrocinadores,
arquitectura proyectos
Architecture Governance Framework

La evolución y la mejora de Orientación en el gobierno de la arquitectura
la función EA mediante la definición de la mejor manera en
que la función EA debe interactuar con otras
• Recomienda el uso de ADM como un medio para
definir la función de la arquitectura y una vez definido • Definición de las partes
reglas de
de lagobierno
empresacon los principales
un plan de trabajo sobre la forma en que este debe interesados para acordar la mejor forma de gestionar la
mejorar arquitectura de la empresa
• El uso de Modelos de Madurez de EA para evaluar la • El uso de un Consejo de Arquitectura para asegurarse de que la
madurez de la empresa y que se utiliza como un medio compañía está siguiendo sus reglas de gobierno
de obtener orientación sobre cómo y dónde mejorar • El desarrollo de un proceso para evaluar Arquitectura
• Se utiliza el marco habilidades para asegurarse de que Cumplimiento
el equipo es lo suficientemente competente para • Desarrollo de contratos de arquitectura para indicar claramente
21/06/2021
desarrollar sus tareas 09:29:12 UT Interfactory 164 .
los acuerdos entre el arquitecto de la empresa y el patrocinador
El uso de ADM para
establecer la
capacidad de la
arquitectura
Como establecer las habilidades de la Arquitectura
• El establecimiento de un estudio de arquitectura sostenible dentro

de una organización se puede lograr mediante la adhesión a la
misma aproximación que se utiliza para establecer cualquier otra
capacidad - tales como la capacidad de gestión de procesos de
negocio - dentro de una organización .
• El ADM es un método ideal para ser utilizado para el arquitecto y
gobernar la aplicación de dicha capacidad . La aplicación de la ADM
con la Visión de la Arquitectura específica para establecer una
práctica de la arquitectura dentro de la organización es un objetivo a
lograr.
• Esto no debe ser visto como una fase de un proyecto de
arquitectura, o de un proyecto de una sola vez , sino más bien como
una continua práctica que proporciona el contexto, el medio
ambiente y los recursos para gobernar y habilitar la arquitectura y
entregar a la organización
166 CAPITULO VII: Architecture Capability FrameWork El uso de ADM para
establecer la
capacidad de la
arquitectura
Definir la visión, los
objetivos de negocio y los
conductores , y los Definir los procesos, puntos de vista
principios de la práctica de y cómo se utilizará el marco .
la arquitectura También las mediciones de
desempeño que se requieren
Definir los datos necesarios
a almacenar y cómo se
Los cambios en los procesos almacenará en el repositorio
o sistemas deben gestionarse de arquitectura. También
aquí qué aplicaciones se
necesitarán para ayudar con
El requerimiento debe los procesos definidos en la
estar claramente Fase B
articulado y alinear a la
visión
Definir la infraestructura
Gobernando la
tecnológica de soporte a la
implementación de la
práctica de la arquitectura
arquitectura de negocio
La mejor manera de
La mejor manera de gestionar los cambios
adoptar los nuevos organizacionales que se
sistemas y procesos requieren y cómo esto se
21/06/2021 09:29:12 166
logra
167 CAPITULO VII: Architecture Capability FrameWork Architecture Skills
Framework
• Proporciona una vista de los niveles de competencia requeridos para

funciones específicas. Define:
– Los roles dentro de un área de trabajo
– Las habilidades requeridas por cada rol
– La profundidad del conocimiento necesario para cumplir la función con éxito
• Por qué lo necesitamos
– Confusión en la industria sobre las competencias requeridas hace difícil reclutamiento .
– Asegurar una exitosa práctica de Arquitectura Empresarial necesita personal con la
experiencia y habilidades relevantes en o para cumplir sus funciones . Sin embargo,
estas funciones deben estar bien definidas en primer lugar. ! Esto es lo que el marco
habilidades intenta hacer.
– Tener personal menos calificado en el papel de la arquitectura empresarial aumentará
los costos de re- contratación y la calidad de su trabajo impactará negativamente a la
arquitectura empresarial de la compañía.
Framework de habilidades de Arquitectura

• Habilidades
1: Background
– Genéricas
No es una habilidad necesaria ,
aunque debe ser capaz de • Liderazgo, trabajo en equipo, habilidades
Miembros de La Patrocinador definir y gestionar la habilidad interpersonales , etc.
Arquitectura de ser necesario
Junta de – De método & Negocios
Arquitectos 2: Awareness • Casos de negocio , procesos de negocio ,
Entiende el fondo, los la planificación estratégica
Gerente
problemas y consecuencias lo
suficiente como para ser capaz
– De Arquitectura empresarial
Arquitectura de entender la forma de • Modelado, diseño de bloques de
proceder más allá y asesorar a construcción, diseño de roles y
los clientes adecuadamente.
aplicaciones, integración de sistemas
Arquitecto Arquitecto
3: Knowledge – De gestión de proyectos & Programas
Empresarial datos
negocios • La gestión del cambio empresarial ,
Conocimiento detallado de la
materia y capaz de métodos y herramientas de gestión de
proporcionar asesoramiento y proyectos
Arquitecto Arquitecto
orientación profesional.
aplicaciones tecnología Capacidad de integrar la – De conocimiento general de IT
capacidad en el diseño de la • Aplicaciones de corretaje , gestión de
arquitectura activos , planificación de la migración ,
SLAs
4: Expert
Gerentes de – Cónocimiento técnico de IT
proyecto Diseñador Experiencia práctica
extensa y sustancial y • La ingeniería de software , la seguridad ,
de TI
conocimiento aplicado de la el intercambio de datos , gestión de datos
asignatura – Ambiente legal
Niveles de • Protección de Datos, Ley Contractual,
Compras, fraude
competencia
Gobierno de la Arquitectura
Gerente General
Manda
Desarrolla Implementa Entrega

Alineación Alineación Gestión del
Comité Arquitectura Oficina de Proyectos
servicio
Guía Gestión Riesgos Monitoreo
Arquitecto empresa Implementación Sistemas
de Proyectos Cambio Operacionales
Cumple
REPOSITORIO
Arquitecturas Procesos Plantillas Standards

 Ejemplo de habilidades:
21/06/2021 09:29:12 UT Interfactory 170


• DESCRIPCION DEL CARGO • PRINCIPALES
– City Planner en lugar de un arquitecto del edificio . HABILIDADES
– No debe crear una visión técnica de la empresa , en lugar debe desarrollar – Habilidades y experiencia
relaciones profesionales con los ejecutivos de la empresa para reunir y
articular la visión técnica sobre la base de los planes de negocio de estos en la elaboración de
ejecutivos . diseños.
– Necesita trabajar estrechamente en el proceso de gobierno de la Arquitectura
para asegurar que todas las decisiones de diseño están siguiendo la – Amplio conocimiento
estrategia de negocios como de TI . Técnico, en una o pocas
– Produce la documentación de la arquitectura para los equipos de desarrollo disciplinas
de aplicaciones o equipos de aplicación de productos a ejecutar.
– Administrar y programar el trabajo de otros arquitectos de segmentos o – Enfoque de ejecución de
solución. métodos para la
• ACTIVIDADES CLAVES ejecución
– Entender e interpretar los requerimientos: Entendimiento y escucha para
obtener información , influir en las personas , facilitar la creación de – Full experiencia de
consenso, sintetizar y traducir las ideas en acciones concretas requisitos . gestión de alcance de los
Participa en el descubrimiento y la documentación de los escenarios de
negocio a los clientes que están impulsando la solución
proyectos
– Crear un modelo útil : Toma los requerimientos y desarrolla modelos bien – Liderazgo
formulados de los componentes. Mostrar varias vistas para comunicarse
efectivamente . Asegurar la integridad de la arquitectura y la visión y también – Habilidades personales y
tiene que entender todos los componentes de negocio . profesionales
– Validar, refinar y ampliar el modelo : verificar hipótesis , traer a expertos en
la materia , para mejorar el modelo y, además definirlo. – Habilidades y experiencia
– Administrar la arquitectura : Continuamente monitorear los modelos y en una o más industrias
actualizarlos cuando se producen cambios
171
 Garantizar el cumplimiento de los proyectos individuales

con la arquitectura de la empresa es un aspecto
esencial de la gobernabilidad arquitectura. Función de
Gobierno de TI dentro de la empresa normalmente
definir dos procesos complementarios
Desarrollar
arquitecturas de Arquitecturas de Solución
Solución
¿Estas arquitecturas de
la solución
cumplen con las
normas y principios de
Gobierno IT Arquitectura etc.?
172
• Ejemplo de un proceso de revisión
Cumplimiento
requerimientos
Para obtener
Coordinador de la revision antecedentes y la
de la Arquitectura información técnica.
Arquitecto Utilice las listas de
lider chequeo Comité
Arquitectura
Identificar Identificar Definir Definir Entrevistar Analizar Preparar Aceptar la

Definir listas Presentar
Organización Arquitecto alcance de session para directores de cumplimient informe de revision y
de chequeo hallazgos
Responsable lider revisión revision proyecto o revisión firmarla
Identificar qué otras unidades

de negocio / departamentos
están involucrados. Entender
Revise los estándares
que el sistema encaja en el corporativos. Identificar y
Lideres proyecto, resolver problemas . Lideres proyecto,
marco de la arquitectura
Clientes Hacer recomendaciones Clientes
corporativa
173
174
ADM y la arquitectura de Seguridad
Los métodos de desarrollo de la arquitectura son herramientas en las manos de quien es

responsable de la seguridad para crear mejores prácticas y una capacidad específica en la
organización.
Esta es una guía para quien desarrolla la arquitectura como para quien es responsable de la
seguridad y evitar errores de seguridad críticos
Normalmente la arquitectura de seguridad se tata de forma separada en un dominio de la

arquitectura de la empresa y requiere que se integre totalmente. El objetivo es fortalecer las
políticas de seguridad sin quitarle valor a la misma. Generalmente tiene las siguientes
características:
 La arquitectura de seguridad tiene su propia metodología

 La arquitectura de seguridad tiene sus propias vistas y puntos de vista
 La arquitectura de seguridad guía flujos no normativos a través de sistemas y aplicaciones.
 La arquitectura de seguridad introduce sus propios flujos normativos a trávés de sistemas y
aplicaciones.
 La arquitectura de seguridad introduce componentes únicos y de propósito específico en el
diseño.
 La arquitectura de seguridad demanda su propio equipo de trabajo con competencias y
habilidades específicas.
175
La arquitectura de seguridad se preocupa de aspectos no funcionales, preocupado en aspectos

intangibles, que no se comprometan los datos o las aplicaciones por ello tienen sus propios
SBB. Además respondes a intereses de seguridad de los interesados.
Las preocupaciones principales son:
 Autenticación: La verificación de la identidad de una persona o de una entidad en la

organización.
 Autorización: La definición y fortalecimiento de las capacidades permitidas a una persona o
entidad cuya identidad se ha establecido.
 Auditoría: La habilidad para proporcionar información forense de los sistemas usados de
acuerdo a las políticas de seguridad establecidas.
 Aseguramiento: La habilidad para probar y aprobar que en la arquitectura de seguridad tiene
los atributos requeridos para mantener las políticas establecidas..
 Disponibilidad: La habilidad de la organización para operar sin interrupción del servicio o de
la ocurrencia de efectos anómalos.
 Protección de activos: La protección de los activos de información de eventos de pérdida o
de acceso no autorizado.
 Administración: La habilidad de adicionar o modificar las políticas de seguridad y de cómo
estos cambios son aplicados en la organización y de incluir o reemplazar personal o entidades
a los sistemas.
 Gestión de riesgos: El apetito y la tolerancia al riesgo
176
La gestión de requerimientos de seguridad en ADM hace parte de la gestión de procesos (ciclo de

vida) y normalmente surgen a nivel ejecutivo y son agnóstico a la tecnología que se este
empleando o que se vaya a emplear.
Los nuevos requerimientos surgen de:

 Una nueva norma o requisito legal
 Una nueva amenaza que surge o se ha experimentado
 Una nueva iniciativa de arquitectura de IT que descubre nuevos requerimientos o interesados.
Los dos primeros se tratan en la fase H, el tercero se gestiona en “Gestión de requerimientos”.
La pregunta que se hace el arquitecto de seguridad es “Is our security good?”

177
FASE PRELIMINAR
Identifique las áreas impactadas por la arquitectura de seguridad
 Identifique dependencias claves — a quienes más afecta este trabajo de seguridad o a

quienes mas les aporte.
 Identifique dependencias colaterales (Soft Units) — Quienes verán el cambio que opera en
otras dependencias pero no se verán afectados directamente
 Identificar dependencias extendidas (Units) — Quienes están por fuera del alcance de estos
cambios pero se tendrán que adaptar por razones de interoperabilidad
 Identificar comunidades afectadas (enterprises) — Estos interesados se verán afectados y
están representados en comunidades o grupos.
 Identificar la organización de gobierno de seguridad, incluyendo marcos de trabajo federales y
geografías.
Identifique y defina las normas regulatorias y las políticas de seguridad que se deben
cumplir
 Los principios y el marco de trabajo rara vez cambian, por lo cual las implicaciones de
segundad deben ser revisadas cuidadosamente. Una política de seguridad debe establecerse
y debe tener una notificación y entrenamiento de forma regular a los empleados. La norma
ISO/IEC 17799: 2005 es un buen principio para establecer una política de seguridad. Sin una
política establecida es muy difícil el empoderamiento en la organización. Los aspectos a
revisar son muchos (Sistemas de información, acceso físico, acceso remoto, etc). Las
resticciones de la arquitectura se deben comunicar a los miembros del equipo.
 De forma similar, hay normas y requerimientos que el sistema debe cumplir o acciones que se
deben ejecutar.
178
FASE PRELIMINAR
 Defina las capacidades de seguridad como parte de la capacidad de la arquitectura

Acuerdos en el rol del arquitecto de seguridad en el proceso de arquitectura y en el gobierno
de IT deben establecerse. Las consideraciones de seguridad pueden entrar en conflicto con
requerimientos funcionales y una declaración de seguridad se requiere para asegurar que
todos los elementos involucrados o con conflictos de interés son revisados de forma explícita.
Las decisiones ejecutivas en materia de seguridad deben establecerse en este punto para
saber cuales son negociables y cuales deben cumplirse por razones de ley o por mandatos de
los estatutos.
 Implemente herramientas de arquitectura de seguridad

El nivel de formalidad empleado para definir y gestionar la arquitectura de seguridad debe
depender ampliamente del tamaño, sofisticación y cultura de la función de seguridad de la
organización.
Las herramientas a emplear deben estar basadas en aplicaciones estándar o en soluciones

especiales de seguridad que se despliegan.
179
 Entradas:
 Política de Seguridad
 Estatutos
 Lista de normas aplicables
Salidas:
 Lista de políticas de seguridad aplicables
 Equipo de seguridad definido
 Lista de consideraciones y de condiciones límite de seguridad
180
VISION DE LA ARQUITECTURA
Las consideraciones de seguridad tiene un amplio impacto en el ciclo de desarrollo (Fase A a

la H), y tienen implicaciones en la arquitectura (políticas, gobierno, artefactos , bloques de
construcción).
La definición de los interesados más relevantes y de sus intereses y preocupaciones requieren

el desarrollo de un escenario de alto nivel. Se recomienda el escenario de negocios
(herramienta de ADM).
Obtenga soporte en la gestión para la medición de la seguridad.

De igual forma que se debe obtener reconocimiento y empoderamiento para un proyecto de
arquitectura así se debe efectuar para los aspectos relacionados con la seguridad.
El reconocimiento sobre el impacto que tiene el desarrollo de un proyecto en la organización y

su infraestructura a veces no es tan claro y mas aun se puede considerar una perdida de
tiempo y de recursos aquellas actividades relacionadas con los aspectos de seguridad.
181
Defina los hitos mas relevantes en el ciclo de desarrollo de la arquitectura

La trazabilidad de las decisiones relacionadas a la arquitectura deben ser documentadas e
informadas al nivel ejecutivo apropiado y este canal de comunicación y de reporte debe
establecerse formalmente.
Debe reconocerse que la tensión entre entregar una nueva función de negocios y las politicas
de seguridad no debe existir, es parte de un todo. Y el proceso de resolver estas disputas
recae en el equipo de arquitectura y necesita ser entendido claramente para salvaguardar los
activos de la organización.
Determine y documente el plan de continuidad y de recuperación de desastres de la

entidad.
Cualquier plan de continuidad y recuperación de desastres debe ser entendido y la relación
cpn los sistemas planeados debe ser definida y documentada.
182
Identifique y documente los ambientes físicos y de negocio en los cuales los sistemas
deben desplegarse.
Todas las decisiones de arquitectura deben efectuarse en el contexto de los ambientes bajo
los cuales los sistemas van a instalarse y operarse. Los ambientes físicos deben
documentarse incluyendo aspectos comerciales, de competencia, móviles, etc.
De forma similar el ambiente de negocios debe estar definido incluyendo suposiciones como
interfaces, ambientes regulatorios sobre los cuales los sistemas pueden operar.
Determine y documente la criticidad del sistema: Seguridad Crítica / misión-Crítica/ No

Crítica
 Los sistemas de Seguridad Crítica están en peligro en caso de falla o mal funcionamiento
 Los sistemas de Misión Crítica están en el mercado de valores, market share, o de riesgo
de capital en caso de fallas.
 Los sistemas No Críticos no tiene ninguna consecuencia en caso de falla.
183
 Entradas:
 Lista de políticas de Seguridad aplicables
 Planes de continuidad y de recuperación de desastres
Salidas:
 Declaración del ambiente de seguridad físico
 Declaración del ambiente de seguridad de negocios
 Declaración del ambiente regulatorio
 Carta de la política de seguridad suscrito por el CEO o su delegado
 Lista de chequeo de los puntos de seguridad a ser revisados en la
arquitectura
 Declaración de la criticidad de los sistemas
 Lista de los Planes de continuidad y de recuperación de desastres
que son aplicables
184
ARQUITECTURA DE NEGOCIOS
Determine quienes son los actores legítimos que interactuaran con los productos/servicios
El desarrollo de casos de negocios y de alto nivel y los subsecuentes casos de
uso atraerán la atención de personas y de roles de sistemas involucrados, muchas
decisiones relacionadas con la autorización de los usuarios, administradores, y
operadores del sistema (Sus capacidades y características). Se debe considerar
que las aplicaciones pueden ser también usuarios.
Se deben identificar necesidades administrativas como operarios de copias de
seguridad o usuarios de internet.
Asesore y cree una línea base de los procesos de negocio específicos de seguridad
(Adicional al objetivo existente)
Los procesos de negocio relacionados a que actores se consideran usuarios del
sistema deben documentarse. Debe considerarse actores fuera de la organización
que son usuarios reales del sistema. Las organizaciones foráneas se determinan
en los escenarios de alto nivel de la fase A.
185
ARQUITECTURA DE NEGOCIOS
Determine quien / como es aceptable o inconveniente emplear ciertas métricas de seguridad

Las métricas de seguridad son importantes peo pueden imponer cargas
innecesarias al personal.
Juzgue entre incluirlas en el software, construirlas basados en reportes. Hay que
tener un claro balance entre lo funcional y lo seguro.
Identifique y documente los sistemas interconectados mas allá de su control de proyecto

Cada sistema nuevo puede basarse u operar sobre los ya existentes. Dichos
sistemas tienen ventajas / desventajas, riesgos y beneficios. Ejemplos: Domain
Name System (DNS) que resuelve un nombre de un servidor o servicio a la
Internet, la dirección que entrega el host puede no ser siempre de confianza.

TOGAFF-Completo V2

Cargado por

Información del documento

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

TOGAFF-Completo V2

Cargado por

Copyright:

Formatos disponibles

1

Francisco Javier Pulido Fajardo

PART I (Introduction). Introducción a los conceptos de Arquitectura empresarial

Introducción de alto nivel de

Architecture Development Method (2a Parte) El Core de TOAGFF, paso a

“Cualquier conjunto de organizaciones que tienen un

El propósito de la arquitectura empresarial es optimizar en toda la

 Mayor eficiencia en la Operación del negocio

 Identificar y refinar los requerimientos que tienen las partes

El análisis y la documentación de una empresa en sus estados

Líneasofde negocio Líneas de negocio

Es un conjunto de herramientas que puede ser utilizado para desarrollar un

 Describir una metodología para la definición de un sistema de

 El diseño de la Arquitectura es un proceso complejo

 Mayor usabilidad. Su estructura modular hace mas fácil

 “Una descripción formal de un sistema, o un plan

 “La estructura de componentes, sus interrelaciones, y

Arquitectura de IT Un plano para cada uno

Arquitectura de Tecnología Cómo la tecnología

 Un método de desarrollo de arquitectura (ADM)

 Inicia con la base de la

Política de Seguridad Cualidades Politica de mobilidad

Aplicaciones que consumen información

Herramientas de Aplicaciones Gestión de

Aplicaciones que proven información

Desempeño SLAs Politica de gestión

El proceso continuo de mejora de la arquitectura se conduce

El método de desarrollo de la arquitectura produce contenido que

Es el método definido por TOGAF para el desarrollo de

 Consiste en un número de fases

•Fase B: Arquitectura de Negocios Describe el desarrollo de las arquitecturas de negocios, sistemas

En cada caso desarrollar la arquitectura baseline (“Como es”) y el

Fase E: Oportunidades y Soluciones Evaluar y seleccionar entre las opciones

Fase F: Plan de Migración Analizar costos, beneficios y riesgos;

Preparar y realizar los “arquitectura Contracts”

Gestión de requerimientos Examina el proceso de gestión de requerimientos

El Architecture Content Framework proporciona un modelo de contenido

Deliverables: Es un producto de trabajo que se especifica, se revisa, se

Artifacts: Es un producto de trabajo de la arquitecta que describe un aspecto

Building Blocks: Representan un (potentialmente re-usable) componente de

Para simplificar el proceso de creación de una arquitectura de empresa, que dé

Partiendo de este continuo de arquitecturas que nos explican y planifican

Ambos continuos el de arquitecturas y soluciones, visualizan el proceso de

Es quien soporta el Enterprise Continuum. Se emplea para

 Arquitectura Metamodel. Describe la organización.

 ADM es iterativo, sobre todo

 — Activos creados en iteraciones

que apoyan o impulsan el cumplimiento de un(os)

Describe las actividades de preparación e iniciación necesarios para

•Llevar a cabo las actividades de preparación e iniciación necesarios para cumplir la

Los principales aspectos son los siguientes:

“Que tan grande es el animal”

 El alcance de la empresa determinará los interesados a quienes se les

Es necesario entender el contexto que rodea la arquitectura . Por ejemplo , las

Los modelos comerciales y el presupuesto para la arquitectura empresarial.

Las intenciones y la cultura de la organización.

Los procesos actuales que apoyan la ejecución de los cambios y el

Las habilidades y capacidades de la empresa.

Imperativos comerciales dirigen los requisitos y parámetros de rendimiento.

Los requerimientos del negocio

Los propósitos de la Organización

El propósito estratégico

Previsión Necesidades financieras

TOGAF tiene que co-existir con otras capacidades operacionales de otros