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
Ciclo de Desarrollo de la Arquitectura
•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
Ciclo de Desarrollo de la Arquitectura
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
Ciclo de Desarrollo de la Arquitectura
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
SLIDE 35 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
7. 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
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
Artefactos de Salida
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
2. Solicitud de Trabajo Arquitectónico
3. Declaración de Trabajo Arquitectónico
4. Visión arquitectónica (escenarios del negocio/visión
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
3. Crear el(los) modelo(s) arquitectónico(s)
4. Seleccionar los bloques de construcción de la arquitectura de datos
5. Conducir puntos de revisión formales del modelo
arquitectónico y los bloques de
construcción con los involucrados
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
9. Desarrollar un análisis de brechas y crear reporte
Artefactos de Salida
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
Artefactos de Entrada
1. Principios de la aplicación, si existen
2. Principios de datos, si existen
3. Solicitud de Trabajo Arquitectónico
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
9. Línea base de la arquitectura de datos, versión 0.1
10. Arquitectura de Datos objetivo, versión 0.1
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
3. Crear el(los) modelo(s) arquitectónico(s)
4. Identificar sistemas de aplicación candidatos
5. Conducir puntos de revisión formales del modelo
arquitectónico y los bloques de
construcción con los involucrados
6. Revisar los criterios cualitativos (como desempeño,
costo, volúmenes)
7. Completar la arquitectura de aplicaciones
8. Desarrollar un análisis de brechas y crear reporte
Artefactos de Salida
1. Declaración del Trabajo Arquitectónico actualizada, si es
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í)
4. Arquitectura de Aplicaciones 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. 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
Artefactos de Entrada
1. Principios Tecnológicos, si existen
2. Solicitud de Trabajo Arquitectónico
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
11. Línea base de la arquitectura de datos, versión 1.0
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)
15. Arquitectura de Datos objetivo, versión 1.0
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
Artefactos de Salida
1. Declaración del Trabajo Arquitectónico actualizada, si es
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
7. Puntos de vista que atienden las principales preocupaciones
de los involucrados
8. Vistas correspondientes a esos puntos de vista seleccionados
Fase E – Oportunidades y soluciones
Artefactos de Entrada
1. Solicitud de Trabajo Arquitectónico
2. Declaración del Trabajo Arquitectónico
3. Arquitectura de Negocio objetivo, versión 1.0
4. Arquitectura Tecnológica objetivo, versión 1.0
5. Arquitectura de Datos objetivo, versión 1.0
6. Arquitectura de Aplicaciones objetivo, versión 1.0
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.
Artefactos de Salida
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
Artefactos de Entrada
1. Solicitud de Trabajo Arquitectónico
2. Declaración del Trabajo Arquitectónico
3. Arquitectura de Negocio objetivo, versión 1.0
4. Arquitectura Tecnológica objetivo, versión 1.0
5. Arquitectura de Datos objetivo, versión 1.0
6. Arquitectura de Aplicaciones objetivo, versión 1.0
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.
Artefactos de Salida
1. Análisis de impacto – Planes de implementación y
migración detallados
Fase G – Implementación de la gobernabilidad
Artefactos de Entrada
1. Solicitud de Trabajo Arquitectónico
2. Declaración del Trabajo Arquitectónico
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
Artefactos de Salida
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
Artefactos de Entrada
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.
Visión empresarial de aplicabilidad
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 .
Visión empresarial de aplicabilidad
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.
Visión empresarial de aplicabilidad
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.
Visión empresarial de aplicabilidad
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.
Visión empresarial de aplicabilidad
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
?