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

FASE F Plan de migración

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

Artefactos de Entrada 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

Artefactos de Entrada 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.

4. Visión arquitectónica (escenarios del negocio/visión 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 negocio en el mismo.

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

Economy & Finance

Transcript of Togaf parte II PROFESOR`PASSARELLO ESPEDITO 2015