Togaf parte II PROFESOR`PASSARELLO ESPEDITO 2015

MAESTRIA Y ESPECIALIZACION
GESTION ESTRATEGICA DE SISTEMAS Y
TECNOLOGIAS DE LA INFORMACION.
El CIO como ejecutivo de Negocios.

PROFESOR: Mg Espedito Passarello
2015
ASIGNATURA: INFRAESTRUCTURA
Y ARQUITECTURA TECNOLÓGICA

UNIDAD 2
TOGAF PARTE II
(CONTINUA ADM)

FASES
RESTANTES
Framework
TOGAF.ADM

ADM
 Ciclo de Desarrollo de la Arquitectura
• Fase Preliminar: Framework y
Principios
• Preparar a la organización un
adecuado proyecto de arquitectura
TOGAF, definir los principios de
arquitectura, definir el Framework
y las herramientas.
• Gestión de Requerimientos • Asegurar que cada etapa del
proyecto TOGAF este
fundamentada en requerimientos
de negocio validados.

ADM
•Fase A: Visión de Arquitectura Establecer el alcance, restricciones, y las
expectativas del proyecto TOGAF; Crear
la Visión; determinar los stakeholders;
validar el contexto del negocio y crear el
“Statement of Architecture Work”;
Obtener aprobaciones.
•Fase B: Arquitectura de Negocios
•Fase C: Arquitecturas de Sistemas de
Información
•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 (“as is”) y el objetivo (“to be”) y
analizar gaps

ADM
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.

Resumen ADM
Fase G: Implementación del
Governance
Preparar y realizar los “Architecture
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.

FASE D
Arquitectura tecnológica,

Define la arquitectura TI integrada para el desarrollo
de las fases posteriores.
Se desarrolla la arquitectura tecnológica que
SOPORTARA los requerimientos de las arquitecturas
de negocio y de Siste4mas de información , que
se han creado en las fases B y C.
Primero paso; Establecer una línea base para la
arquitectura técnica existente usando el formato de
TOGAF. Esto implica partir la funcionalidad en
bloques de construcción arquitectónicos
reutilizables y describir las piezas en términos de la
arquitectura fundamental.

Consensuar visiones
Esto permite visualizar a todos (stakehoulder) los
responsables de proyecto;
- negocio,
- sistemas,
- técnicos o administrativos.
La madurez/experiencia del ambiente de trabajo.
Luego se profundiza creando el modelo objetivo de
bloques de construcción, especificando lo que
cada uno de esos bloques debe hacer y así
sucesivamente. También se realiza un análisis de la
diferencia para asegurarse que se están cubriendo
todos los aspectos

FASE E
Oportunidades y soluciones,

Permite determinar un inventario de elementos
con los cuales se cuentan para montar la fase D.
En ella se determina cuales componentes es
necesario comprar, modificar o arreglar para que
pueda ser útil en la arquitectura. En fases previas
se identifica tanto la línea base como la objetivo
de la arquitectura, partiéndolas en bloques de
construcción. En la fase E se miran todos esos
bloques para determinar qué se puede reutilizar,
qué se debe reemplazar y qué se debe proveer,
ya sea comprándolo o
construyéndolo.

En esta fase también se considera si los sistemas
existentes deberían ser reemplazados todos a la
vez o no y da opciones para que los nuevos
sistemas puedan coexistir con los LEGACY.
Acorde con TOGAF “la estrategia más exitosa
para la fase de Oportunidades y Soluciones es
concentrarse en proyectos que entregarán
ganancias en plazos cortos para que así creen un
efecto “sinérgico” que sentara bases seguras
para luego proceder con proyectos de más larga
duración. Esto implica acción de fortalecimiento
para el diagnostico realizado (Ej. FODA).

Esta fase puede también descubrir oportunidades
de aplicaciones adicionales en cuyo caso
podríamos encontrarnos iterando entre esta fase
y las anteriores

Prioriza los proyectos EN SIMULTANEIDAD y
gestiona un plan de migración de la empresa
hacia la nueva “ Arquitectura Empresarial”
establecidad.
En este punto deberíamos tener una muy buena
idea de donde estamos y lo que vamos a
Alcanzar, determindo cómo llegaremos allí
La fase anterior (E ) nos debe proveer todas los
block (piezas) de la arquitectura objetivo (al
menos las líneas bases).

Es muy dificil lograr la Arquitectura Objetivo en un
solo paso, o sea implementar la EA de una vez,
en forma completa. Si se pretende, es muy
posible enfrentarse con un resultado que podría
ser un caos).
En esta fase se determina el orden en el cual se
implementan nuevos sistemas, es decir, la
cartera de proyectos (Port folio).

La fase G, Implementación de la gobernabilidad, es
la ejecución de los proyectos para construir las
soluciones de TI.
Finalmente ya casi empezamos a construir. El
proceso de desarrollo actual está fuera de TOGAF
pero no está realmente separado. En esta fase se
ponen en lugar los procesos que asegurarán que
todo el desarrollo, sea este parte de la
implementación de una arquitectura o un
proyecto en marcha, está conforme con la
arquitectura objetivo. Este paso implica la
creación de un contrato arquitectónico y requiere
de la aprobación de aquellos trabajando en el
desarrollo. Al final de esta fase su arquitectura
objetivo debiera estar instalada.

La fase H, administración del cambio de la arquitectura,
monitorea y evalua los sistemas existentes para determinar
cuándo iniciar un nuevo ciclo de ADM. Una vez completada la
arquitectura empresarial es rara vez un sistema estático. En vez
de eso la necesidad (o percepción de necesidad) para el
cambio es inevitable y es la razón de existir de la fase H. Se
entra en la fase H luego de completar la fase de
Implementación del Gobierno y por lo tanto la completitud de
la arquitectura de la organización. En esta fase se monitorean
las solicitudes de cambio y se determinan si se procederá y
cómo. Algunos cambios, tales como la simplificación de un
proceso, pueden ser manejados por una buena política de
administración del cambio y no necesitará moverse de esta
fase. Otros tipos de cambio, como una nueva iniciativa de
estándares o una nueva tecnología, requiere solo de una
retrabajo arquitectónico parcial, tal vez iniciando desde la fase
D, Arquitectura Tecnológica. Otros cambios, tales como esos
que involucran los procesos de negocio subyacentes, requieren
regresar a la fase A, donde la arquitectura vigente se convierte
en la nueva línea base. En este caso el desarrollo procede justo
como se hizo la primera vez hasta que se arriba a este punto.

Habiendo analizado lo anterior se observa la
importancia de un buen proceso de Ingeniería
de Requerimientos por parte de ADM
Un requerimiento es una declaración que identifica
las capacidades, características o factores de
calidad de un sistema, a fin que tenga valor y
utilidad para el negocio, cliente y usuario.
Artech House, The requirements Engineering
Handbook

ENTREGABLES
Framework
TOGAF.ADM

of
The TOGAF Architecture
Development Method
H
Architecture
Change
Management
G
Implementation
Governance
F
Migration
Planning
E
Opportunities
& Solutions
D
Technology
Architecture
C
Information
System
Architectures
C
Information
System
Architectures
Requirements
Management
B
Business
Architecture
A
Architecture
Vision
Preliminary
Framework &
Principles
The ADM comprises the full life-cycle management of an
Enterprise Architecture from planning to operational
deployment and change.
OPERATIONAL
ENTERPRISE
ARCHITECTURE
Business
Architecture
Applications
Architecture
Data
Architecture
Technology
Architecture

Documentos y pasos generados por TOGAF
Lista de documentos y pasos generados por
TOGAF en cada una de sus fases
Fase A – Visión arquitectónica

Fase A – Visión arquitectónica
Artefactos de Entrada
1. Solicitud de Trabajo Arquitectónico
2. Estrategia, metas y conductores (driversI) del
negocio
3. Principios arquitectónicos, incluyendo los principios
de negocio cuando existan de antemano
4. Continuo empresarial (Enterprise Continuum),
documentación arquitectónica existente
(descripción del marco arquitectónico, descripciones
existentes de la línea base, etc.)

Pasos
1. Establecer el proyecto
2. Identificar las metas del negocio y los conductores
del negocio
3. Revisar los principios arquitectónicos incluyendo
los principios de negocio
4. Definir el alcance
5. Definir las restricciones
6. Identificar involucrados y sus preocupaciones,
requerimientos de negocio y la visión
arquitectónica
7. Desarrollar la Declaración del Trabajo
Arquitectónico y confirmarla

Artefactos de Salida
1. Declaración del Trabajo Arquitectónico aprobada incluyendo
a. Alcance y restricciones
b. Plan para el trabajo arquitectónico
2. Declaraciones refinadas de las metas del negocio y los
conductores estratégicos
3. Principios arquitectónicos incluyendo los de negocio
4. Visión arquitectónica (escenarios del negocio/visión
arquitectónica) incluyendo
a. Arquitectura de Negocio actual, versión 0.1
b. Arquitectura Tecnológica actual, versión 0.1
c. Arquitectura de Datos actual, versión 0.1
d. Arquitectura de las Aplicaciones actual, versión 0.1
e. Arquitectura del Negocio objetivo, versión 0.1
f. Arquitectura Tecnológica objetivo, versión 0.1
g. Arquitectura de Datos objetivo, versión 0.1
h. Arquitectura de las Aplicaciones objetivo, versión 0.1

Fase B – Arquitectura de negocio

1. Solicitud para Trabajo Arquitectónico
2. Declaración del Trabajo Arquitectónico aprobada
3. Declaración refinada de las metas del negocio y estratégias
4. Principios arquitectónicos, incluyendo los de negocio
5. Continuo empresarial
6. Visión arquitectónica
arquitectónica) incluyendo
a. Arquitectura de Negocio actual, versión 0.1
b. Arquitectura Tecnológica actual, versión 0.1
c. Arquitectura de Datos actual, versión 0.1
d. Arquitectura de las Aplicaciones actual, versión 0.1
e. Arquitectura del Negocio objetivo, versión 0.1
f. Arquitectura Tecnológica objetivo, versión 0.1
g. Arquitectura de Datos objetivo, versión 0.1
h. Arquitectura de las Aplicaciones objetivo, versión 0.1

Pasos
1. Desarrollar la descripción de la línea base de la arquitectura
de negocio
2. Identificar modelos de referencia, puntos de vista y
herramientas
3. Crear el(los) modelo(s) arquitectónico(s)
4. Seleccionar los bloques de construcción de la arquitectura
de negocio
5. Conducir puntos de revisión formales del modelo
arquitectónico y los bloques de
construcción con los involucrados
6. Revisar los criterios no funcionales (cualitativos) como
desempeño, costo, volúmenes
7. Completar la arquitectura de negocio
8. Desarrollar un análisis de brechas y crear reporte

1. Declaración de Trabajo Arquitectónico actualizada, si es
necesario
2. Principios y metas de negocio así como los conductores
estratégicos validados
3. Arquitectura de Negocio objetivo, versión 1.0, incluyendo
a. Estructura organizacional – identificando ubicaciones del
negocio y relacionándolas con unidades organizacionales
b. Metas y objetivos del negocio – para la empresa y cada unidad
organizacional
c. Funciones del negocio – un paso detallado y recursivo
incluyendo una descomposición sucesiva de las áreas funcionales
más grandes en sub-funciones
d. Servicios del negocio – los servicios que la empresa y cada
unidad empresarial
provee a sus clientes, tanto interna como externamente
e. Procesos de negocio incluyendo métricas y entregables

f. Roles del negocio incluyendo el desarrollo y modificación de los
requerimientos de habilidades
g. Modelo de datos de negocio
h. Correlación entre la organización y las funciones – relacionando
funciones del negocio en unidades funcionales en la forma de un reporte
tipo matriz
4. Línea base de la arquitectura de negocio, versión 1.0 detallada, si es
necesario
5. Vistas atienden las preocupaciones claves de los involucrados
6. Resultado del análisis de brechas
7. Requerimientos técnicos – identificando, categorizando y priorizando
las implicaciones del trabajo para los dominios arquitectónicos restantes,
por ejemplo, una matriz de dependencia/prioridad (por ejemplo, para
guiar la compensación entre velocidad del procesamiento de una
transacción y seguridad). Listar los modelos específicos que se
espera producir (por ejemplo, expresado como las primitivas del marco
de Zachman)
8. Reporte de la arquitectura de negocio
9. Requerimientos del negocio actualizados

Fase C – Arquitectura de Datos

1. Principios de datos, si existen
3. Declaración de Trabajo Arquitectónico
arquitectónica)
5. Requerimientos técnicos relevantes que aplicarán a esta fase
6. Resultado del análisis de brechas (de la Arquitectura de
Negocio)
7. Línea Base de la Arquitectura de Negocio, versión 1.0 detallada,
si es necesario
8. Arquitectura de Negocio objetivo, versión 1.0, detallada
9. Línea Base de la Arquitectura de Datos, versión 0.1, si está
disponible
10. Arquitectura de Datos objetivo, versión 0.1, si está disponible
11. Bloques de construcción reutilizables (desde el continuo de la
arquitectura, si están disponibles)

Pasos
1. Desarrollar la descripción de la línea base de la arquitectura
de datos
2. Revisar y validar principios, modelos de referencia, puntos de
vista y herramientas
4. Seleccionar los bloques de construcción de la arquitectura
de datos
6. Revisar los criterios cualitativos (como desempeño, costo,
volúmenes)
7. Completar la arquitectura de datos
8. Realizar y verificar el análisis de impacto

1. Declaración del Trabajo Arquitectónico actualizada, si es
necesario
2. Línea base de la arquitectura de datos, versión 1.0
3. Principios de datos validados, o nuevos principios de datos
4. Arquitectura de Datos objetivo, versión 1.0
5. Puntos de vista que atienden las principales preocupaciones
de los involucrados
6. Vistas correspondientes a esos puntos de vista seleccionados
7. Resultados del análisis de brechas
8. Requerimientos técnicos relevantes que aplicarán a esta
evolución del ciclo de desarrollo
arquitectónico
9. Reporte de la Arquitectura de Datos resumiendo lo que se
hizo y los hallazgos principales
10. Análisis de impacto
11. Requerimientos de negocio actualizados, si es necesario

Fase C – Arquitectura de Sistemas de Información

1. Principios de la aplicación, si existen
2. Principios de datos, si existen
4. Declaración del Trabajo Arquitectónico
5. Visión arquitectónica (escenarios del negocio/visión arquitectónica)
6. Continuo empresarial (una introducción)
7. Línea base de la arquitectura de negocio, versión 1.0 detallada, si es
necesario
8. Arquitectura de Negocio objetivo, versión 1.0 detallada
11. Línea base de la arquitectura de aplicaciones, versión 0.1
12. Arquitectura de Aplicaciones objetivo, versión 0.1
13. Requerimientos técnicos relevantes que aplicarán a las Fase C
14. Resultados del análisis de brecha (de la arquitectura de negocio)
15. Bloques de construcción reutilizables (desde el continuo de la
arquitectura, si están disponibles)

Pasos
1. Desarrollar la descripción de la línea base de la
arquitectura de aplicaciones
2. Revisar y validar principios, modelos de referencia,
puntos de vista y herramientas
4. Identificar sistemas de aplicación candidatos
6. Revisar los criterios cualitativos (como desempeño,
costo, volúmenes)
7. Completar la arquitectura de aplicaciones

necesario
2. Línea base de la arquitectura de aplicaciones, versión 1.0
3. Principios de aplicaciones validados, o nuevos principios de
aplicaciones (si se generan
aquí)
de los involucrados
7. Resultados del análisis de brechas
8. Reporte de la Arquitectura de Aplicaciones resumiendo lo
que se hizo y los hallazgos principales
9. Análisis de impacto
10. Requerimientos de negocio actualizados, si es necesario

Fase D – Arquitectura Tecnológica

1. Principios Tecnológicos, si existen
3. Declaración de Trabajo Arquitectónico.
arquitectónica)
5. Línea base de la arquitectura de negocio, versión 0.1 (de la
Fase A)
6. Arquitectura Tecnológica objetivo, versión 0.1 (de la Fase A)
7. Requerimientos técnicos relevantes de fases anteriores
8. Resultados del análisis de brechas (de la Arquitectura de
Datos)
9. Resultados del análisis de brechas (de la Arquitectura de
Aplicaciones)

10. Línea base de la arquitectura de negocio, versión
1.0 detallada, si es necesario
detallada, si es necesario
12. Línea base de la arquitectura de aplicaciones,
versión 1.0 detallada, si es necesario
13. Arquitectura de Negocio objetivo, versión 1.0
detallada
14. Bloques de construcción reutilizables (desde el
continuo de la arquitectura, si está
disponible)
16. Arquitectura de Aplicaciones, versión 1.0

Pasos
1. Desarrollar la descripción de la línea base de la
Arquitectura Tecnológica
2. Desarrollar la Arquitectura Tecnológica objetivo

necesario
2. Línea base de la arquitectura tecnológica, versión 1.0, si es
necesario
3. Principios tecnológicos validados o nuevos principios
tecnológicos (si se generaron aquí)
4. Reporte de la Arquitectura Tecnológica, resumiendo qué fue
hecho y los hallazgos
principales
5. Arquitectura Tecnológica objetivo, versión 1.0
6. Reporte de brechas de la Arquitectura Tecnológica
de los involucrados

Fase E – Oportunidades y soluciones

7. Bloques de construcción reutilizables (desde el
continuo de la arquitectura, si está
disponible)
8. Información del producto

Pasos
1. Identificar conductores claves de negocio que
restringen la secuencia de implementación
2. Realizar una lluvia de ideas acerca de los
requerimientos técnicos desde la perspectiva
Funcional.
3. Realizar una lluvia de ideas sobre la coexistencia e
interoperabilidad de los
requerimientos
4. Ejecutar una valoración de la arquitectura y un
análisis de brechas
5. Identificar los paquetes de trabajo y proyectos
principales.

1. Estrategia de implementación y migración
2. Plan de implementación de alto nivel
3. Análisis de impacto – lista de proyectos

Fase F – Planeación de la migración

7. Análisis de impacto – lista de proyectos

Pasos
1. Priorizar proyectos
2. Estimar los requerimientos de recursos y su
disponibilidad
3. Ejecutar una avaluación de costo/beneficio de los
diferentes planes de migración
4. Desarrollar un análisis de riesgos
5. Generar el mapa de carretera de la
implementación (en el tiempo)
6. Documentar el Plan de Implementación.
1. Análisis de impacto – Planes de implementación y
migración detallados

Fase G – Implementación de la gobernabilidad

3. Bloques de construcción reutilizables
4. Análisis de impacto – Planes de implementación y
migración detallados

Pasos
1. Formular la recomendación de los proyectos
2. Documentar el Contrato de Arquitectura
3. Revisar la gobernabilidad de la implementación en
ejecución y su conformidad con la
arquitectura
1Análisis de impacto – recomendaciones de
implementación.
2. Contrato de Arquitetura
3. Sistema implementado conforme a la arquitetura.

Fase H – Administración del cambio de la
arquitectura

1. Solicitud de cambio arquitectónico – cambios
tecnológicos
2. Solicitud de cambio arquitectónico – cambios de
negocio
Pasos
1. Actualizaciones de la arquitectura
2. Cambios al marco arquitectónico y a los principios
3. Nueva solicitud de cambio arquitectónico, para
mover a otro ciclo

PARTE 2
EJEMPLO DE CASOS
1) TOGAF SOA

Aplicabilidad
 TOGAF sirve para la creación de una Enterprise Architecture
y normalmente se aplica a:
 Creación de aplicaciones de misión crítica o core
business
 Minimizar riesgos de no-entendimiento entre Negocio y
Tecnología
 Generación de valor y descubrimiento de oportunidades
en Business Transformation
 Describir, documentar y continuar los sistemas y
aplicaciones construidos
 La metodología empleada en TOGAF se basa en modelos
descriptivos y en un ciclo de vida iterativo que permite
definir la arquitectura desde diferentes puntos de vista,
implicando a diferentes áreas de la empresa para lograr un
entendimiento global de las necesidades, restricciones y
oportunidades del proyecto.

Retos al iniciar un proyecto de AE y SOA

Consideraciones de ADM al aplicar la Orientación a Servicios

Consideraciones de ADM al aplicar la
Orientación a Servicios

EJEMPLO
2) APLICABILIDAD
TOGAF en una PYME

Visión empresarial de aplicabilidad
TOGAF.
 Ejemplo de aplicabilidad SCOPE
(Alcance):
Todos los sistemas administrativos (Logística,
ventas, contabilidad y recursos humanos),
cubriendo los 4 tipos de arquitectura
(negocios, data, aplicaciones e
infraestructura). Cubre alcance de tipo
vertical, pero debido a que se va a
desarrollar a nivel de varias unidades de
negocios y áreas, también se puede decir
que tiene características de un alcance
horizontal.

TOGAF.
 Objetivos
Los objetivos de la Arquitectura TI que se
propone :
 Definir las responsabilidades de cada uno de
los miembros de la organización.
 Definir los principios de la arquitectura que
informe los condicionantes (restricciones )para
el desarrollo de la arquitectura.
 Definir los componentes de TI necesarios para
la integración de la información, que permita
el flujo de información entre las áreas de una
organización.
 Definir una plataforma de interconexión de
infraestructuras.

 ADM Ciclo de Desarrollo de Arquitectura –
Expandido
Fase Preliminar
Maximizar el beneficio de la empresa: Las decisiones son hechas
siempre con el fin de maximizar las utilidades de la empresa.
Uso de aplicaciones comunes: Desarrollo de aplicaciones usadas
a través de la empresa es preferida sobre el desarrollo de
aplicaciones similares o duplicadas que son solo provistas
para una parte de la organización.
Data compartida: Los usuarios tienen acceso a los datos
necesarios para realizar sus labores por lo tanto la data es
compartida a través de la empresa, funciones y trabajadores.
Data accesible: Para que todos los usuarios puedan realizar sus
funciones de la mejor manera.
Fácil de usar: La tecnología que se implementa tiene que ser de
fácil manejo y aprendizaje para todos los usuarios, a fin de
que puedan concentrarse en las tareas que tienen que
realizar.

Fase A: Visión de la Arquitectura
El desarrollo de la arquitectura supone, en primer
lugar, el compromiso de la alta dirección para
llevar a cabo los objetivos. El diseño iniciará una
vez que el proceso de definición de arquitectura
esté terminado, y será implementado
gradualmente.
La arquitectura propuesta iría con la visión de la
empresa, así como con las recomendaciones
brindadas en el primer trabajo debería responder
a:
✓ Cumplir con el actual trabajo de las diversas
áreas, es decir, asegurar la conectividad con el
SAP R/3 para las áreas Comercial, Contabilidad,
Logística y Finanzas y con el WINBOX-Oracle para
el área de Recursos Humanos.

✓ Además debería contemplar la propuesta de
agregar dos nuevos módulos de SAP, Producción
y Gestión, de manera que se integre el
planeamiento y control de la producción de los
sacos multipliegos de FORSAC y se pueda dar un
seguimiento adecuado al planeamiento
estratégico de la empresa.
✓ Potenciar el Portal Web para FORSAC, de
manera que exista una mayor interacción con los
clientes, de manera que les sea más fácil enviar
sus pedidos.
✓ Establecer una relación fluida con nuestros
proveedores, abriendo un canal directo de
comunicación para que sepan en qué momento
necesitamos de insumos, de manera que no se
vea afectada la producción.

Fase B: Arquitectura del Negocio
Modelo de Procesos
El siguiente modelo ha sido realizado para conocer
las funciones y actividades que se realizan dentro de
Forsac para este fin se ha utilizado la notación BPMN.
Se describe desde la realización del pedido del
cliente hasta la entrega del pedido en forma general.
El proceso es como sigue:
1.Pedido del Cliente
2.Planificación de la Producción
3.Compra de Materiales y su almacenamiento
4.Producción y despacho
5.Elaboración de Estrategias y Estudio de Mercado

Fase C: Arquitectura de Datos
Principios de Datos
Accesibilidad de datos
Todas las áreas deben tener acceso a los
datos de acuerdo a sus funciones.
Fundamento:
El rápido acceso a los datos permite
eficiencia y efectividad en la toma de
decisiones y proporciona soluciones
oportunas a requerimientos de información
para optimizar los procesos de producción.
La flexibilidad y accesibilidad de la data
están íntimamente relacionadas.

 Datos son compartidos
Usuarios tienen acceso a los datos necesarios
para rendir sus tareas.
 Fundamento:
El acceso oportuno a datos correctos es
esencial para mejorar la calidad y eficiencia en
la toma de decisiones de la empresa. Hay un
menor costo en mantener acceso oportuno de
datos en una aplicación y luego compartirla que
mantener datos duplicados en múltiples
aplicaciones.

Seguridad de Datos
Los datos son protegidos del uso no
autorizado y de su revelación.
 Fundamento:
Información tienen que ser protegida
para evitar especulación no
garantizada, mal interpretación y uso
inapropiado.

 Aspectos Cualitativos
 Confidencialidad: asegura que la información
sea accesada solo por el personal autorizado
 Integridad: Asegura que la información solo
sea modificada por el personal autorizada.
 Disponibilidad: Asegura que la información y
los sistemas puedan ser accesados cuando
los necesite el personal autorizado.

 Fase C: Arquitectura Del Sistema De
Informacion – Aplicaciones
 Aplicación 1: SAP - Modulo de Planificación y
Control de la Producción (PP)
 Aplicación 2: SAP - Modulo de Administración
de Materiales (MM)
 Aplicación 3: SAP - Modulo de Ventas y
Distribución (SD)
 Aplicación 4: SAP - Modulo de Contabilidad
Financiera (FI)
 Aplicación 5: Tempus
 Aplicación 6: Osis

 Fase D: Arquitectura Tecnológica
 Paso 1: Descripción de los sistemas existentes en términos
de los servicios del marco TOGAF
 Paso 2: Considerar diferentes modelos de referencia, vistas
y herramientas
 Paso 3: Crear modelo de arquitectura con bloques de
construcción
 Paso 4: Seleccionar portafolio de servicios por cada bloque
de construcción
 Paso 5: Confirmar metas y objetivos de negocio
 Paso 6: Determinar los criterios para las especificaciones
 Paso 7: Completar la definición de la Arquitectura
Tecnológica

Conclusiones y
beneficios
de aplicar
TOGAF
.

TOGAF
Enfocar los proyectos de TI como
procesos de ingeniería en los que es
necesario diseñar correctamente las
soluciones que proveen.
 Arquitectura de Negocio: conocer el
negocio de su cliente, su negocio, su
organización, la motivación que le impulsa a
crear o transformar las aplicaciones software.
 Arquitectura de Aplicaciones: tener un
dominio de las diferentes aplicaciones
involucradas, sistemas existentes,
restricciones y relaciones existentes entre ello
y, sobre todo, la relación con procesos y
áreas de negocio de la empresa.

TOGAF
 Arquitectura de Información: la información
que la empresa necesita y maneja, cómo
se obtiene, se procesa, almacena, etc.
Ubicaciones, procesos de captura y
explotación es información necesaria para
explorar las capacidades y limitaciones
existentes.
 Arquitectura de Tecnología: el diseño de las
soluciones debe tener en cuenta las
infraestructuras disponibles y las
interrelaciones con los demás dominios de
arquitectura.

TOGAF
La metodología ADM y el framework TOGAF
se adecuan a las necesidades de las
operaciones de cada unidad de negocio en
diferentes proyectos de TI, aplicando los
siguientes criterios:
 Iteraciones sobre ADM, modificando los
primeros ciclos para hacer énfasis en los
dominios donde más riesgo o indefinición se
encuentran. La iteración sobre las primeras 3
fases (Prelim > A > B > C) es una práctica
común en proyectos con un gran número de
implicados de diferentes areas, necesario
para establecer un lenguaje común y una
visión compartida del proyecto.

TOGAF
 Adaptación de los artefactos o productos de cada una
de las fases de TOGAF, adecuando la profundidad de los
mismos a las necesidades del proyecto. Limitaciones de
tiempo, nivel de conocimiento de los implicados así
como la naturaleza en sí de las aplicaciones tienen
impacto en el alcance de la documentación a generar.
 Gobierno, dado que no hay dos empresas iguales, la
forma de gestionar y gobernar proyectos depende en
cada caso. Es crítico conocer el grado de implicación,
conocimiento y responsabilidad que cada stakehoulder
asume dentro de un proyecto, para adaptar las prácticas
de Gobierno a cada contexto
 Defunción de responsabilidades y competencias
(perfiles), pues no todos los proyectos y unidades de
negocio, requieren de los mismos perfiles: las
habilidades de negociación, coordinación y seguimiento
varían en función de la naturaleza del proyecto y de la
implicación del personal vinculado a las operaciones de

OPEN GROUP.
Beneficios al adoptar una arquitectura empresarial:
Procesos de Tecnología de Información más
eficientes
Menores costos de desarrollo, soporte y
mantenimiento de software
Mayor portabilidad de aplicaciones
Mejoramiento de la interoperabilidad y
administración de sistemas y redes
Una mejor capacidad para atender asuntos que
afectan toda la organización como la seguridad
Mayor facilidad para cambiar y actualizar
componentes de sistemas.

Ventajas
 TOGAF, como otros frameworks de
Enterprise Architecture, tiene como
principal objetivo establecer un enlace
entre Negocio y TI en las empresas,
aportando múltiples beneficios a ambas
áreas que a continuación se describen.
 Reducción de costos
 Reducción de Riesgos
 Identificación de Oportunidades
 Flexibilidad y Adaptación
 Lenguaje común

EVALUACION DE FRAME
Zachman y TOGAF. Aunque ambos están
catalogados como “frameworks empresariales”
difieren en el enfoque,
composición y los términos de referencia. Mientras
que “Zachman es un framework estructural
(estático) que es más efectivamente usado como un
modelo para el análisis y clasificación de los
artefactos y el meta-análisis de las metodologías y los
marcos de referencia, TOGAF es un
proceso (dinámico) que también incluye guías para
los modelos de proceso de referencia para
usarlos” [Temnenco 2007].

Mejor retorno en inversiones actuales y
un menor riesgo en inversiones futuras
Reducción en la complejidad de la
infraestructura de la tecnología de
información
Máximo retorno de inversión en la
infraestructura existente
Flexibilidad para hacer, comprar o tercerizar
soluciones de tecnología de información
Reducción en el riesgo en nuevas
inversiones y menores costos total de
tecnología de información

Un proceso de adquisición es más
rápido, sencillo y económico
Las decisiones de compra son más sencillas,
dado que la información para gobernar
este proceso está disponible a primera
manos en un plan coherente.
El proceso de adquisición es más rápido,
maximizando la velocidad y flexibilidad para
adquirir tecnología sin sacrificar la
coherencia de la Arquitectura

Togaf parte II PROFESOR`PASSARELLO ESPEDITO 2015

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Togaf parte II PROFESOR`PASSARELLO ESPEDITO 2015

Similar a Togaf parte II PROFESOR`PASSARELLO ESPEDITO 2015 (20)

Más de Espedito Passarello

Más de Espedito Passarello (20)

Último

Último (20)

Togaf parte II PROFESOR`PASSARELLO ESPEDITO 2015