UNIDAD 01

Aspectos generales de la arquitectura empresarial sistémica

Sesión 01
Definiciones Básicas de la Arquitectura Empresarial Sistémica.
 Arquitectura Empresarial: la
alineación estratégica entre
Tecnologías de Información (TI) y el
negocio
Reflexión:
Antes de empezar piense en si nos encargaran construir 2 torres de 50 pisos
cada una con los siguientes requerimientos:
1. 500 apartamentos tipo loft de 1, 2, 3 alcobas con parqueaderos
2. 145 oficinas desde 60 mts2 hasta 600 mts2
3. 200 locales comerciales desde 10 mts2 hasta 156 mts2
4. Zonas verdes y edificio ecológico
5. Ubicado en la zona centro de Bogotá
6. Etc,etc,
Y para esto solo contratamos Gerentes de Obra, Ingenieros Civiles y Obreros.
¿Qué resultado obtendríamos?
¿Qué y Quién nos hace falta?
 Arquitectura Empresarial: la
alineación estratégica entre
Tecnologías de Información (TI) y el
negocio
Pero Antes:
… qué elementos clave componen su organización/ entidad?
… hacia donde va su organización/entidad?
… dónde esta su entidad actualmente?
… cómo llegar a la entidad que tiene visualizada?
Problemas que queremos resolver con
la Arquitectura de TI
Problemas que queremos resolver con
la Arquitectura de TI
 Problemas que queremos resolver con
la Arquitectura de TI

La falta de Aplicaciones
alineación entre desintegradas
TI y el negocio (silos).
 La falta de alineación entre TI y
el negocio
• Como puede la TI apoyar la estrategia
• Tipos de estrategia:
– Operational excellence
• Eficiencia en los procesos
• Volumen y bajos costos
– Product leadership
• Innovación en producto y mercadeo
– Customer intimacy
• Excelencia en el servicio al cliente
 Aplicaciones desintegradas (silos)
• Duplicidad de datos y
funcionalidad
• Organización funcional
de la empresa
– Diferentes
departamentos para
diferentes funciones
– Cada departamento
tiene su propio sistema
• No existen procesos
¿Qué es Arquitectura Empresarial?

Arquitectura:
El Arte y Ciencia de diseñar para
edificar y construir

Arquitectura Empresarial:
El Arte y Ciencia de diseñar
estrategias de TI para las empresas
que innoven y agreguen valor
 Arquitectura
• Punto de enlace entre
lo bonito y lo funcional
– Casas o edificios que
sean lindos dentro de un
contexto, pero que sirva
para lo requerido
 ¿Qué es una empresa?

Depto Depto Depto

Cliente A B C
Proveedor
 ¿Qué es Arquitectura de TI?
• Organización fundamental de un sistema que
describe sus elementos y la relación entre
ellos. Guiado por unos principios y pensando
en su evolución.
• Generar una estructura con una visión
 Arquitectura de TI
• El arte y la ciencia de diseñar soluciones
tecnológicas que produzcan valor a las
organizaciones
• Punto de enlace entre el negocio(objetivos,
• innovación, valor) y tecnología.
• Estratega de tecnología para el negocio
• El innovador de la empresa apalancado en la
tecnología.
 Arquitectura de TI

• La ciencia de alinear las necesidades de

negocio y las soluciones de TI, tal como
existe hoy en día.

• El objetivo de la arquitectura empresarial es

maximizar el valor de negocio entregado por
la inversión en TI.
 Arquitectura Empresarial
Es la organización lógica de los procesos de
negocio y la infraestructura de TI, reflejando las
necesidades de integración y estandarización del
modelo de funcionamiento de la empresa.
La arquitectura empresarial ofrece una visión a
largo plazo de los procesos de la empresa,
sistemas y tecnologías para que los proyectos se
puedan ejecutar y no sólo satisfacer las
necesidades inmediatas.
 Elementos de la AE

Requerimientos
Stakeholders

logical layers,
Proceso tiers, Lenguaje
viewpoints/views

Modelos de Referencia
 Requerimientos o Requisito
• La arquitectura es un medio para asegurar que las
organizaciones pueden cambiar y satisfacer las
demandas del mercado y que operar de manera
• eficiente.
Un requerimientos describe una condición o capacidad
que un sistema debe cumplir, ya sea derivado
directamente de las necesidades del usuario, o dicho
en un contrato, norma, especificación u otro
• documento formalmente impuesto
Mecanismos para expresarlos
– Casos de Uso
– Historias de Usuario
 Stakeholders
• Quienes pueden afectar o son afectados por las
actividades de una empresa.
– R. E. Freeman.Strategic Management: A Stakeholder
Approach (Pitman, 1984)
– Deben ser considerados como un elemento esencial
en la planificación estratégica de los negocios
• Traducción literal: Parte Interesada
• También son llamados interesados o involucrados
en un problema determinado, y que necesitan
una solución
 Logical layers, tiers, viewpoints/views
• Cuando dividimos todo en: negocios, información, aplicaciones e
infraestructura, estamos hablando de capas (layers) de la arquitectura.
• Cuando dividimos software en: la presentación, lógica de negocio, y
componentes de datos, estamos hablando de niveles lógicos (tiers) en el
software.
• Cuando describimos el sistema de forma diferente dependiendo de la
perspectiva de la parte interesada(stakeholder), decimos que estamos
describiendo una visión (view) de la arquitectura desde un punto de vista
determinado (viewpoints).
Proceso

Seleccionar
Proyectos

Administrar Crear
Arquitectura Arquitectura

Comunicar
Arquitectura
 Lenguajes y Modelos
• La arquitectura
Lenguaje Alcance Audiencia Estilo
se expresa
usando Negocio, Arquitectos y
Archimate Información y Grafico
diagramas y Tecnología
Stakholders

modelos. Negocio, Arquitecto e

UML Información y Ingeniero de Grafico
• Existen Software Software
diferentes Negocio Analistas de
BPMN Grafico
lenguajes de (procesos) proceso

modelado. ERM (Entity

Ingeniero de
Relationship Información Grafico
Gráficos y Texto Model)
software
 Modelos de Referencia
Modelos genéricos de referencia (plantilla) que pueden ser
utilizados como punto de partida para las organizaciones,
para estructurar su propia arquitectura de la empresa.
Proporciona un vocabulario común.

• AQPC (procesos). http://www.apqc.org

• Business Information Services Library(BISL)
• Modelos de Referencia de TOGAF
• ETOM
Frameworks y Metodologías de AE
• The Zachman Framework for Enterprise
Architectures
• The Open Group Architecture Framework
(TOGAF)
• Federal Enterprise Architecture (FEA)
• Gartner

http://msdn.microsoft.com/en-us/library/bb466232.aspx
¿Por qué se necesita un Framework?

• Agiliza y simplifica la definición y el desarrollo de la arquitectura,

asegurando un cubrimiento más completo de la solución diseñada
• Asegura que la arquitectura seleccionada permita el crecimiento futuro
en respuesta a las necesidades del negocio.
• Por que diseñar una Arquitectura es un proceso técnicamente
complejo, y el diseño de arquitecturas heterogéneas de múltiples
proveedores es particularmente complejo.
• Desmitificar la Arquitectura Empresarial
ZACHMMAN
 ZACHMMAN
Es el primer modelo de Arquitectura
Empresarial. Año 1987.
– Framework for Information System Architecture
No propone un método específico para
obtener cada elemento
Demasiados elementos. Estructurados y
organizados
 ZACHMMAN
Este framework de arquitectura empresarial fue creado por John
A. Zachman en 1984. También se publicó en 1987 por IBM
Systems Journal. Cuenta con bastante popularidad, tiene sus años
ya de experiencia y uno de los más utilizados en la actualidad.

El Framework ™ de Zachman “normalmente es representado

como un acotado 6 x 6 "matriz" con los interrogantes de
Comunicación como las columnas y las Transformaciones como
Filas”26. – ver figura 5. Las clasificaciones del framework son
representadas a través de las celdas de la matriz, es decir, la
intersección entre las preguntas y transformaciones. Las
transformaciones pueden ser perspectivas o modelos, éstas se
presentan mediante combinaciones perspectiva/modelo.
 ZACHMMAN
Las columnas son denominadas nombres de
clasificación y comprenden los siguientes interrogantes
de comunicación.

¿Qué?
¿Cómo?
¿Dónde?
¿Quién?
¿Cuándo?
¿Por qué?
ZACHMMAN
 ZACHMMAN
¿QUÉ? - INVENTORY SETS.
“Describe las entidades involucradas en cada punto de vista de la empresa. Los
ejemplos incluyen los objetos de negocio, datos del sistema, las tablas
relacionales, las definiciones de campo”27. En efecto las partes interesadas de
la empresa como se verán relacionadas con la futura AE respecto a la data,
también entendido como los datos.

¿CÓMO? - PROCESS FLOWS.

“Muestra las funciones dentro de cada perspectiva. Incluyen procesos de
negocio, la función de la aplicación de software, la función del hardware del
equipo, y lazo de control del lenguaje”28. Enfocado así en la función de los
flujos de proceso que llevan a cabo.
 ZACHMMAN
¿DÓNDE? - DISTRIBUTION NETWORKS.
“Muestra las localizaciones y las interconexiones dentro de la empresa. Esto
incluye lugares geográficos empresariales importantes, secciones separadas
dentro de una red logística, la asignación de los nodos del sistema, o incluso
las direcciones de memoria dentro del sistema”29. En sí, la distribución de las
redes dentro de la organización.

¿QUIÉN? - RESPONSIBILITY ASSIGNMENTS.

“Representa las relaciones de las personas dentro de la empresa. El diseño de
la organización empresarial tiene que ver con la asignación de trabajo y la
estructura de autoridad y responsabilidad. La dimensión vertical representa la
delegación de autoridad, y la horizontal representa la asignación de la
responsabilidad”30. Asignando las responsabilidades a personas con roles
específicos.
 ZACHMMAN
¿CUÁNDO? - TIMING CYCLES.
“Representa el tiempo, o el caso de las relaciones que establecen los criterios
de rendimiento y los niveles cuantitativos de los recursos de la empresa. Esto es
útil para diseñar el programa maestro, la arquitectura de procesamiento,
arquitectura de control, y dispositivos de sincronización”31. Los ciclos de tiempo
son útiles a la hora de llevar un control sobre el desarrollo de la AE.

¿POR QUÉ? - MOTIVATION INTENTIONS.

“Describe las motivaciones de la empresa. Esto pone de manifiesto los objetivos
de la empresa y los objetivos, plan de negocios, la arquitectura del
conocimiento, y el diseño de los conocimientos”32. Las intenciones de
motivación deben ser claras a la hora mostrar los cambios que traería la
implementación de la AE.
 ZACHMMAN
Las filas están representadas por las transformaciones que pueden
ser perspectivas y modelos, éstas se presentan mediante
combinaciones perspectiva/modelo. El Framework presenta un
sistema de clasificación para registrar diferentes puntos de vista en
función de sus roles. Las perspectivas y modelos son:

Perspectiva Ejecutiva/contexto de alcance.

Perspectiva de gestión de Negocio/conceptos de negocio.
Perspectiva de la Arquitectura/lógica del sistema.
Perspectiva de Ingeniero/tecnología física.
Perspectiva Técnica/componentes de la herramienta.
Perspectiva Empresarial/instancias de operación.
ZACHMMAN
 ZACHMMAN
Perspectiva Ejecutiva/contexto de alcance.
Típicamente esta perspectiva es asumida por miembros
de la junta y líderes ejecutivos, quienes definen el
contexto del negocio junto con el alcance y límites de la
empresa.
Esta perspectiva es un nivel de planificación. Los
planificadores de contexto del negocio describen qué,
cómo, dónde, quién, cuándo y cómo se debe hacer. Los
contextos de alcance describen un alcance de los
modelos, arquitecturas, y las descripciones de la
organización.
 ZACHMMAN
Perspectiva de gestión de Negocio/conceptos de
negocio.
Típicamente esta perspectiva es asumida por el director
o administrador de la unidad de negocios de la
organización, es él, quien puede definir los conceptos de
negocio donde se describen modelos, arquitecturas,
requisitos de alto nivel para la empresa y descripciones
que son utilizadas por los propietarios de los procesos de
negocio.
 ZACHMMAN
Perspectiva de la Arquitectura/lógica del sistema.
En esta perspectiva trata de confundirse un poco con TI,
pues, es la perspectiva del diseñador quien debe crear el
modelo de la lógica del sistema que se describe por
medio de modelos, arquitecturas, y descripciones que
son utilizados por los diseñadores, ingenieros y
arquitectos que están en busca de un compromiso entre
lo que es deseable y lo que es técnicamente posible.
 ZACHMMAN
Perspectiva de Ingeniero/tecnología física.
La perspectiva del ingeniero se basa en crear un modelo de la
tecnología física mediante modelos, arquitecturas y descripciones
que se utilizan para diseñar y crear un proyecto real. En sí, traer
modelos cerca de la realidad física. El enfoque principal son las
limitaciones y la realidad a construir.

Perspectiva Técnica/componentes de la herramienta.

La perspectiva técnica tiene que ver con la implementación,
configuración de herramientas, la aplicación de herramientas y la
conversión de los modelos físicos en realidad. Los componentes de
la herramienta describen elementos particulares o partes de
elementos que se incluyen en el producto final (por ejemplo,
componentes de software, documentación, y así sucesivamente).
 ZACHMMAN
Perspectiva Empresarial/instancias de operación.
En esta última perspectiva se observa la empresa en
funcionamiento con todas las implementaciones de las
perspectivas anteriores. Esta es la perspectiva del usuario final y
cubre la ejecución real en sí muestra el objetivo del modelo. Usted
no tiene que definir modelos en esta perspectiva.

Es el producto final viéndolo de otra forma. por ejemplo, un

edificio, programa, o un sistema único de gestión de producto
extendido en 12 mercados físicos diferentes a través de todas sus
divisiones y así sucesivamente.
 ZACHMMAN
Perspectiva Empresarial/instancias de operación.
En esta última perspectiva se observa la empresa en
funcionamiento con todas las implementaciones de las
perspectivas anteriores. Esta es la perspectiva del usuario final y
cubre la ejecución real en sí muestra el objetivo del modelo. Usted
no tiene que definir modelos en esta perspectiva.

Es el producto final viéndolo de otra forma. por ejemplo, un

edificio, programa, o un sistema único de gestión de producto
extendido en 12 mercados físicos diferentes a través de todas sus
divisiones y así sucesivamente.
ZACHMMAN
 ZACHMMAN
Es útil resaltar aquello que dice Zachman en su pagina oficial – “It
is my opinion that Enterprise Architecture is the determinant of
survival in the Information Age” - Es mi opinión que la
arquitectura empresarial es el determinante de la supervivencia en
la era de la información.

En consecuencia a ello durante el desarrollo del trabajo y las

distintas fuentes que se han consultado, las organizaciones cada
día deben asociar todos sus procesos a la tecnología, pues, la
tecnología es la base de la era de la información en este siglo.
The Open Group Architecture
Framework (TOGAF)
 The Open Group Architecture
Framework (TOGAF)
Este framework de arquitectura empresarial fue desarrollado por The Open Group,
su nombre TOGAF proviene de las siglas (The Open Group Architecture Framework).
Su primer desarrollo se dio en 1995 basado en TAFIM (’Technical Architecture
Framework for Information Management’) un modelo de referencia para
arquitectura empresarial desarrollado por el Departamento de Defensa de los
Estados Unidos.
TOGAF se puede ver en 4 grandes grupos:
• En primera instancia TOGAF se enfoca en torno a la arquitectura empresarial,
comprendiendo sus 4 arquitecturas: arquitectura de negocio, arquitectura de
datos, arquitectura de aplicación y arquitectura de tecnología.
• Método de Desarrollo de Arquitectura (ADM).
• Continuum Empresarial.
• Repositorio de la Arquitectura.

Por otra parte la Arquitectura Empresarial basada en TOGAF conduce a detallar el

mejor plan estratégico para su organización incluyendo sus cuatro dimensiones
negocio, aplicaciones, datos y tecnología.
 The Open Group Architecture
Framework (TOGAF)
Arquitecturas Referidas por TOGAF
 The Open Group Architecture
Framework (TOGAF)
Arquitecturas Referidas por TOGAF
• Arquitectura de negocio: define estrategias, estructura, procesos y
gobernabilidad.
• Arquitectura de datos e información: se basa en la descripción de la
estructura de los datos y en el manejo de ellos.
• Arquitectura de aplicación: bases para cada uno de los sistemas y su
relación con el negocio.
• Arquitectura de tecnología: se basa en la estructura de software y
hardware incluyendo área de comunicaciones y soporte.
 The Open Group Architecture
Framework (TOGAF)
Architecture Development Method (ADM)

Las actividades en el método de desarrollo de arquitecturas son de forma

iterativa y todas basadas en los requisitos establecidos, llegando a cumplir los
objetivos planteados en la transformación de la empresa.

Este método proporciona las siguientes fases:

Fase Preliminar
Fase A – Visión de Arquitectura
Fase B – Arquitectura de Negocios
Fase C – Arquitectura de Sistemas de Información
Fase D – Arquitectura de Tecnología
Fase E – Oportunidades y Soluciones
Fase F – Planificación de Migración
Fase G – Gobernanza de la Implementación
Fase H – Gestión de Cambios de Arquitectura
 The Open Group Architecture
Framework (TOGAF)
Architecture Development Method (ADM)

Fase Preliminar
En esta etapa se define el ámbito de la organización afectado por la
iniciativa de EA, así como el equipo de EA y los principios de la arquitectura
aplicables. Por último, deben implementarse las herramientas necesarias
para el desarrollo de la arquitectura.
 The Open Group Architecture
Framework (TOGAF)
Architecture Development Method (ADM)

Fase Preliminar
En esta etapa se define el ámbito de la organización afectado por la iniciativa de EA,
así como el equipo de EA y los principios de la arquitectura aplicables. Por último,
deben implementarse las herramientas necesarias para el desarrollo de la
arquitectura.

Fase A – Visión de Arquitectura

Se deben identificar las partes interesadas, sus inquietudes y requerimientos de
negocio. En esta fase, es el momento en el que también se deben confirmar los
principios de arquitectura y desarrollar el documento de visión de arquitectura para
poder proporcionar una visión general de los cambios que se llevarán a cabo en la
organización como resultado de la iniciativa de EA.
 The Open Group Architecture
Framework (TOGAF)
Architecture Development Method (ADM)
Fase B – Arquitectura de Negocios | Fase C – Arquitectura de Sistemas de
Información | Fase D – Arquitectura de Tecnología
En estas tres fases, se desarrolla la línea base de arquitectura (AS-IS Architecture)
y la arquitectura final (es decir, la arquitectura objetivo de la iniciativa de EA, TO-
BE Architecture) para cada dominio de arquitectura (negocio, datos, aplicaciones y
tecnología).

Tras realizar las arquitecturas AS-IS y TO-BE, se debe realizar el gap analysis entre
ambos para producir la hoja de ruta de arquitectura (Roadmap Architecture) para
llegar a la arquitectura objetivo. El entregable principal de esta etapa es el
documento de definición de arquitectura. Este documento contiene los artefactos
arquitectónicos básicos creados durante el proyecto y toda la información
importante relacionada y abarca todos los dominios de la arquitectura (negocios,
datos, aplicaciones y tecnología) y también examina todos los estados relevantes
de la arquitectura (línea base AS-IS, transición y destino TO-BE).
 The Open Group Architecture
Framework (TOGAF)
Architecture Development Method (ADM)
El ejemplo que vamos a demostrar se trata de una tienda en línea que vende productos. El
proceso comienza cuando el representante de ventas recibe una orden de compra de un
cliente y procede a verificar el nivel de stock. Si hay suficientes existencias disponibles para
cumplir con el pedido, el representante de ventas las empacará. El proceso finaliza con el
envío junto con una factura. En caso de stock insuficiente, el representante de ventas
sugerirá al cliente que modifique la orden de compra.
 The Open Group Architecture
Framework (TOGAF)
Architecture Development Method (ADM)

AS-IS
Este es uno de los aspectos que siempre está en discusión, ya
que existen opiniones a favor y en contra respecto a si es
necesario generar los modelos As-is, mi opinión es que es
indispensable generar estos modelos debido a que:

• Ayuda a generar un alineamiento y entendimiento entre

las distintas áreas y locaciones de la empresa en cuanto a
cómo efectivamente se ejecuta el proceso de negocios.
 The Open Group Architecture
Framework (TOGAF)
Architecture Development Method (ADM)
AS-IS
• A menudo en las organizaciones grandes muchos ejecutivos y usuarios
claves no tienen la visión completa de cada uno de los pasos y detalles
de la operación del proceso de negocios. La documentación del As-Is
ayuda a generar claridad respecto a cómo se ejecutan las cosas y
cuáles son los desalineamientos.
• Ayuda a introducir los conceptos de BPM a los ejecutivos y a los
usuarios claves, en particular en el uso de los diagramas de procesos
de negocios (VAC, EPC, etc.)
• Permite establecer los puntos críticos y de mejoramiento del proceso.
• Afianza el equipo de trabajo del proyecto: Consultores, Usuarios Claves
y Ejecutivos Claves.
 The Open Group Architecture
Framework (TOGAF)
Architecture Development Method (ADM)

AS-IS
Para el levantamiento del proceso As-Is es importante considerar:
• Que a fin de generar la documentación del As-Is en un tiempo
razonable es necesario tener un método preestablecido de trabajo y
un estándar para modelar.
• Se necesita de herramienta de software para modelar, ojalá una que
maneje objetos como ARIS.
• Es indispensable, una vez generado el modelo As-Is, los gerentes
involucrados en el proceso validen formalmente el modelo. Esta acción
tiene más de una complicación debido a que a menudo el modelo
levantado no corresponde a la imagen que tienen del mismo los
ejecutivos.
 The Open Group Architecture
Framework (TOGAF)
Architecture Development Method (ADM)

AS-IS
• Por último, si su empresa necesita cumplir con alguna regulación (SoX,
Basilea II) o alguna certificación el disponer de la documentación de
los procesos de negocios actualizados es una obligación.
• La responsabilidad de generar y mantener actualizados los modelos
As-Is de los procesos de negocios debe estar formalmente asignada a
alguna unidad de la organización.
 The Open Group Architecture
Framework (TOGAF)
Architecture Development Method (ADM)

TO-BE
La generación de los modelos To-Be es indispensable para establecer que
se quiere de la nueva implementación, y ayuda a:
• Definir el nuevo modelo del proceso de negocios independientemente
del software a utilizar. Esto permite pensar sin restricciones dadas por
el software, por la costumbre, por el personal, etc. cuestión que
posibilita descubrir oportunidades de mejoramiento.
• Al tener los modelos To-Be y los As-Is es factible realizar un análisis de
GAP, que es fundamental para esta estrategia.
• El desarrollo del modelo To-Be permite establecer Indicadores de
Performance –KPI que apoyaran el mejoramiento del negocio y
el accountability.
• Posibilita realizar un efectivo alineamiento de los procesos de negocios
con la estrategia corporativa.
 The Open Group Architecture
Framework (TOGAF)
Architecture Development Method (ADM)

TO-BE
Para la generación del modelo To-Be se pueden trabajar con los siguientes
enfoques:
Utilizar Mejores Prácticas, que son modelos provistos, en general, por los
fabricantes del software o por alguna otra organización. La ventaja de su uso es
tiempo, costo y que son modelos probados en la práctica.
Variantes LLL (Legal, Language, Localization), modificaciones a una Mejor Práctica
originadas por un imperativo legal, una necesidad impuesta por el idioma o por
elementos físicos –no de idiosincrasia- de una locación, por ejemplo la
disponibilidad de un determinado elemento.
Prácticas Propias, son modelos generados por la propia organización y que se
justifican, dado su alto costo de generación, cuando el proceso o parte de el –
subproceso- no está presente en una Mejor Práctica y/o cuando su
implementación genera una ventaja competitiva muy significativa.
 The Open Group Architecture
Framework (TOGAF)
Architecture Development Method (ADM)

GAP
Simple es establecer cuáles son los cambios necesarios de realizar al proceso
actual para actualizarlo al Nuevo modelo.

En esta estrategia es necesario volver a tener en cuenta que el “Cambio de Rueda

es en Marcha”, esto significa que los ajustes, modificaciones y adiciones se hacen
en el landscape que está operando. Hecho que significa establecer con mucha
precisión cuales serán los cambios a realizar, cómo y dónde se harán y, muy
principalmente, cuál será el impacto que tendrán.
 The Open Group Architecture
Framework (TOGAF)
Architecture Development Method (ADM)

GAP
Resumiendo el Análisis de GAP, debe establecer las brechas en:
• Procesos y Subprocesos
• Parametrizaciones
• Desarrollos propios (existente y nuevos)
• Datos
• Roles
• Responsabilidades
• Documentación
• Performance
• Gobernabilidad
Cada uno de los tópicos anteriores debe ser documentado y en conjunto
constituirán en Business Blue Print que define el GAP a implementar.
 The Open Group Architecture
Framework (TOGAF)
Architecture Development Method (ADM)
Fase E – Oportunidades y Soluciones
En esta fase, se define la planificación inicial para la puesta en marcha de la
arquitectura objetivo, se identifican y agrupan los principales paquetes de trabajo
necesarios, así como las posibles arquitecturas de transición (es decir,
arquitecturas intermedias hacia la arquitectura objetivo). Además, debe definirse
la estrategia de alto nivel para la implementación y la migración a la arquitectura
TO-BE.

Fase F – Planificación de Migración

En esta fase, los proyectos de migración identificados en la etapa anterior son
priorizados. Para ello, se debe realizar la evaluación coste/beneficio, análisis de
riesgo y la asignación del valor para el negocio que se obtiene con ellos. Además,
la hoja de ruta de arquitectura debe ser confirmada, el documento de definición
de arquitectura debe ser actualizado y el plan de implementación y migración
debe ser finalizado.
 The Open Group Architecture
Framework (TOGAF)
Architecture Development Method (ADM)
Fase G – Gobernanza de la Implementación
En esta fase, se confirma y supervisa el alcance y las prioridades de los proyectos
de implementación. También, se realizan las revisiones de cumplimiento de EA, así
como las revisiones de post-implementación para validar cualquier proyecto
respecto a la arquitectura definida.

Fase H – Gestión de Cambios de Arquitectura

En esta fase, “se revisa que la arquitectura resultante alcanza el valor para el
negocio que se había establecido como objetivo. Además, también deben estar
establecidos los procedimientos necesarios para poder gestionar el cambio, tanto
el proceso para la implementación del cambio como el seguimiento y la gestión de
riesgos”.
 The Open Group Architecture
Framework (TOGAF)
Architecture Development Method (ADM)

Las actividades en el método de desarrollo de arquitecturas son de forma

iterativa y todas basadas en los requisitos establecidos, llegando a cumplir los
objetivos planteados en la transformación de la empresa.

Este método proporciona las siguientes fases:

Fase Preliminar
Fase A – Visión de Arquitectura
Fase B – Arquitectura de Negocios
Fase C – Arquitectura de Sistemas de Información
Fase D – Arquitectura de Tecnología
Fase E – Oportunidades y Soluciones
Fase F – Planificación de Migración
Fase G – Gobernanza de la Implementación
Fase H – Gestión de Cambios de Arquitectura
 The Open Group Architecture
Framework (TOGAF)
Architecture Development Method (ADM)

Las actividades en el método de desarrollo de arquitecturas son de forma

iterativa y todas basadas en los requisitos establecidos, llegando a cumplir los
objetivos planteados en la transformación de la empresa.

Este método proporciona las siguientes fases:

Fase Preliminar
Fase A – Visión de Arquitectura
Fase B – Arquitectura de Negocios
Fase C – Arquitectura de Sistemas de Información
Fase D – Arquitectura de Tecnología
Fase E – Oportunidades y Soluciones
Fase F – Planificación de Migración
Fase G – Gobernanza de la Implementación
Fase H – Gestión de Cambios de Arquitectura
 The Open Group Architecture
Framework (TOGAF)
Architecture Development Method (ADM)

Las actividades en el método de desarrollo de arquitecturas son de forma

iterativa y todas basadas en los requisitos establecidos, llegando a cumplir los
objetivos planteados en la transformación de la empresa.

Este método proporciona las siguientes fases:

Fase Preliminar
Fase A – Visión de Arquitectura
Fase B – Arquitectura de Negocios
Fase C – Arquitectura de Sistemas de Información
Fase D – Arquitectura de Tecnología
Fase E – Oportunidades y Soluciones
Fase F – Planificación de Migración
Fase G – Gobernanza de la Implementación
Fase H – Gestión de Cambios de Arquitectura
 The Open Group Architecture
Framework (TOGAF)
Architecture Development Method (ADM)

Las actividades en el método de desarrollo de arquitecturas son de forma

iterativa y todas basadas en los requisitos establecidos, llegando a cumplir los
objetivos planteados en la transformación de la empresa.

Este método proporciona las siguientes fases:

Fase Preliminar
Fase A – Visión de Arquitectura
Fase B – Arquitectura de Negocios
Fase C – Arquitectura de Sistemas de Información
Fase D – Arquitectura de Tecnología
Fase E – Oportunidades y Soluciones
Fase F – Planificación de Migración
Fase G – Gobernanza de la Implementación
Fase H – Gestión de Cambios de Arquitectura
 The Open Group Architecture
Framework (TOGAF)
Architecture Development Method (ADM)

Las actividades en el método de desarrollo de arquitecturas son de forma

iterativa y todas basadas en los requisitos establecidos, llegando a cumplir los
objetivos planteados en la transformación de la empresa.

Este método proporciona las siguientes fases:

Fase Preliminar
Fase A – Visión de Arquitectura
Fase B – Arquitectura de Negocios
Fase C – Arquitectura de Sistemas de Información
Fase D – Arquitectura de Tecnología
Fase E – Oportunidades y Soluciones
Fase F – Planificación de Migración
Fase G – Gobernanza de la Implementación
Fase H – Gestión de Cambios de Arquitectura
Enterprise Continuum

http://www.opengroup.org
Proceso Genérico de AE (Visión IASA)

Seleccionar
Proyectos

Administrar Crear
Arquitectura Arquitectura

Comunicar
Arquitectura
 Crear Arquitectura
(Punto inicial de TOGAF)
Innovación

TO - BE

Proyectos

Arquitectura Empresarial
The Open Group Architecture
Framework (TOGAF)
 Innovaciones Tecnológicas
CLOUD COMPUTING
MOVIL
INTERNET

AS-IS TO-BE
Arquitectura de Negocio Arquitectura de Negocio
proyecto

Arquitectura Arquitectura proyecto Arquitectura Arquitectura

de de de de
Información Aplicaciones Información Aplicaciones
proyecto

Arquitectura de Tecnología Arquitectura de Tecnología

Requerimientos del Negocio

Mercado y Competencia
Restricciones Legales
 Business Architecture
Arquitectura de Negocio

Procesos

Objetivos
Entidades
Actores de
Información
 Procesos en la Organización
APQC Marco de Referencia
• Excelencia Operativa http://www.apqc.org
– Estandarización e
Integración
– Simplificación
– Digitalización de Procesos
– Autoservicio
• Empresa 5 ceros
– 0 Inventario
– 0 Papel
– 0 Retardo
– 0 Desperdicio
– 0 Errores
 ¿Que es un proceso de negocio o
Business Process ?
• Es un flujo coordinado
de decisiones, eventos y BPMN
actividades, conducida
por participantes que
actúan sobre datos,
información o
conocimiento y que son
necesarias para lograr
un objetivo de la
organización
 Data Architecture
Arquitectura de Información
• La información es el
mayor activo de la
empresa Master Data

Metadata

Analítica
• Existen diferentes

Data
dominios de
Data Data No
información Estructurada Estructurada
• El modelo relacional y
SQL no es lo único que
existe
Arquitectura de Información
Ontologías
MOF
Meta Modelo de Datos
ECORE
Entity framewo

Master Data

Analítica
Metadata

Data
Data Data No
Estructurada Estructurada
 Application Architecture
Arquitectura de Aplicaciones
• Aplicaciones y servicios para cumplir los
objetivos del negocio.
• Las aplicaciones no se deben describir como
software complejos, sino como grupos lógicos
de capacidades y servicios.
 Arquitectura de Software
Aplicaciones Orientadas a Servicios
Antes de SOA Después de SOA

Cliente

GUI
Aplicación
Monolítica Lógica

Servidor BD

Archivos

SOA Open Group Reference

 Technical Architecture
Arquitectura de Infraestructura
• Describir la
infraestructura
tecnológica
– Servidores
– Sistemas operacionales
– Bases de Datos
– Middleware
– Redes
• Canales
• Routers
• Firewalls
 Ejemplo: Venta en mostrador
• Descripción de Negocio
– Venta directa de productos especializados como:
empanadas, arepas, etc. Con una receta original
– No existe ningún sistema de información
– El segmento de clientes las personas que pasan
por la tienda
– Propuesta de valor: la receta original y la atención
por parte del dueño
– Ventas diarias de 200 unidades
 Ejemplo
TO-BE

Objetivos del Negocio

Automatización del Servicio

Aumento de Ventas

Proyecto N
AS-IS Proyecto 2
Proyecto 1

Acceso Web
Dispositivos Electrónicos

Tendencias Tecnológicas
Lenguaje: Archimate
 ¿Por qué hacer AE?
• La empresa no cuenta con información confiable ni a
tiempo.
• Existen muchos proyectos de TI y esto se esta
volviendo complejo de manejar.
• Fusiones y adquisiciones de empresas
• La empresa quiere eliminar una unidad o esta
buscando oportunidades de outsourcing.
• Cambios en leyes que afectan el negocio.
• Automatización de la relación con clientes o
proveedores.
• Relación muy débil entre las áreas y TI
• Sistemas desconectados (silos)
 ¿Qué conocimientos y competencias
debe tener el AE?

Arquitectura de Arquitectura de Arquitectura de Arquitectura de

Dominios
Negocio Información Software Infraestructura

Fundamentos Estrategia de Tecnología y Negocios

Conceptuales
Entorno de TI

Requerimientos, Atributos de Calidad

Diseño

Dinámicas Humanas