Arquitectura Empresarial

TOGAF 9.2

Modulo 6
Agenda
• Ciclo de vida del ADM
• Fase C – Arquitectura de Sistemas de Información
• Arquitectura de Datos
• Arquitectura de Aplicación
Fase C – Arquitectura de Sistemas de
Información
Definición
La fase C consiste en documentar las arquitecturas de sistemas de
información para un proyecto de arquitectura, incluido el desarrollo de
arquitecturas de datos y aplicaciones. Esto describe los principales
tipos de información y los sistemas de aplicación que procesan la
información, y sus relaciones entre sí y el entorno.
Implica una combinación de datos y arquitectura de aplicaciones, que
se puede desarrollar de forma secuencial o simultánea:
• Arquitectura de datos
• Arquitectura de aplicaciones
Objetivos 1/2
PRELIMINAR

• Desarrollar arquitectura
destino de sistemas de A.
VISIÓN DE

información. H.
GESTIÓN DEL
ARQUITECTURA
B.
ARQUITECTURA

• Identificar componentes CAMBIO DE

ARQUITECTURA
DE NEGOCIO

candidatos de la hoja de GESTIÓN DE C.

G.

ruta de la arquitectura. GOBIERNO DE

IMPLEMENTACIÓN
REQUERIMIENTOS ARQUITECTURA
DE SISTEMAS DE
INFORMACIÓN

F.
PLANIFICACIÓN D.
DE LA ARQUITECTURA
E. DE TECNOLOGIA
MIGRACIÓN OPORTUNIDADES
Y SOLUCIONES
Objetivos (2/2)
01 02
Desarrollar arquitectura destino de sistemas de Identificar componentes candidatos de la hoja de ruta de
información la arquitectura.

 Desarrollar la arquitectura destino de  Identificar los componentes candidatos

sistemas de información (datos y de la hoja de ruta de la arquitectura
aplicaciones) describiendo como esta sobre la base de las brechas entre la
arquitectura atenderá la Arquitectura arquitectura de línea base y la
del Negocio y la Visión, atendiendo a Arquitectura Destino (Objetivo) de
los requerimientos de trabajo de la sistemas de información (datos y
arquitectura y las preocupaciones de aplicaciones).
los interesados.
Enfoque (1/2)
La fase C implica una combinación de datos y arquitectura de
aplicaciones, en cualquier orden. Existen defensores para
ambas secuencias, y el estándar TOGAF deja esto al usuario
para decidir.
Aunque hay autoridades en EA que recomiendan un enfoque
impulsado por los datos.
Por otro lado, algunas organizaciones favorecen el enfoque
guiado por las aplicaciones clave (ERP, CRM, etc.) tomando la
implementación e integración de éstas como el centro
principal de los esfuerzos de arquitectura.
Enfoque (2/2)
El Repositorio de Arquitectura
Como parte de esta fase, el equipo de arquitectura debe considerar qué recursos de Arquitectura
de Datos y Arquitectura de Aplicaciones están disponibles en el Repositorio (Depósito) de
Arquitectura de la organización; en particular, modelos genéricos relevantes para el sector
"vertical" de la industria de la organización.
Por ejemplo:
• I.1. Modelos de arquitectura de datos:
• I.1.1. ARTS ha definido un modelo de datos para la industria minorista
• I.1.2. Energistics ha definido un modelo de datos para la industria petroquímica.
• I.2. Modelos de Arquitectura de Aplicaciones
• El TM Forum ha desarrollado modelos detallados de aplicaciones relevantes para la
industria de las telecomunicaciones
• La Open Group ha desarrollado un modelo detallado de referencia de arquitectura de
aplicaciones para el segmento de TI de las organizaciones.
Arquitectura de Datos
Definición
• La gestión de datos efectiva proporciona
una perspectiva que permite una mejor
toma de decisiones, lo cual permite el
cumplimiento constante de las
regulaciones gubernamentales; la
reducción de los riesgos inherentes con una
calidad de datos perfeccionada; una mejor
productividad y eficiencia operativa;
mejoras en la satisfacción del cliente y un
aumento en la agilidad de la organización;
y, de este modo, se logra el alto
rendimiento.
Objetivos
01 02
Desarrollar una Arquitectura de Datos de Destino Identificar componentes candidatos de la hoja de ruta de
la arquitectura.

• Desarrollar una Arquitectura de Datos  Identificar los componentes candidatos

de Destino que sea funcional a la de la hoja de ruta de la arquitectura
Arquitectura de Negocio y a la Visión de sobre la base de las brechas entre la
Arquitectura, y que responda a la vez a arquitectura de línea base y la
la Petición de Trabajo de Arquitectura y Arquitectura de Datos de Destino
a las preocupaciones de los interesados. (Objetivo).
Enfoque (1/5)
La arquitectura de Datos tiene algunas consideraciones claves:
• I.1. Gestión de los datos
Cuando una empresa ha decidido emprender una transformación
arquitectónica a gran escala, es importante comprender y abordar
los problemas de gestión de datos. Un enfoque estructurado e
integral de la administración de datos permite el uso efectivo de
los datos para capitalizar sus ventajas competitivas.
Las consideraciones incluyen:
• Definición de componentes de aplicación que servirán como
sistema de registro o referencia para datos maestros de la
empresa.
Enfoque (2/5)
• Definición de estándares para toda la empresa que todos los componentes de
la aplicación, incluidos los paquetes de software, necesitan adoptar.
• Comprender cómo entidades de datos son utilizadas por funciones, procesos y
servicios de negocios.
• Comprender cómo y dónde se crean, almacenan, transportan e informan las
entidades de datos empresariales.
• Comprender el nivel y la complejidad de las transformaciones de datos
requeridas para soportar las necesidades de intercambio de información entre
aplicaciones
• Definición del requisito de software para admitir la integración de datos con
los clientes y proveedores de la empresa (por ejemplo, uso de herramientas
ETL durante la migración de datos, herramientas de creación de perfiles de
datos para evaluar la calidad de los datos, etc.)
Enfoque (3/5)
• I.2. Migración de los datos
Cuando se reemplaza una aplicación existente, habrá una necesidad
crítica de migrar datos (maestro, transaccional y de referencia) a la
nueva aplicación. La arquitectura de datos debe identificar los
requisitos de migración de datos y también proporcionar indicadores
en cuanto al nivel de transformación, desherbado y limpieza que se
requerirán para presentar los datos en un formato que cumpla con los
requisitos y restricciones de la aplicación de destino. El objetivo es
garantizar que la aplicación objetivo tenga datos de calidad cuando se
llene. Otra consideración clave es garantizar que se establezca una
definición de datos común para toda la empresa para respaldar la
transformación.
Enfoque (4/5)
• I.3. Gobierno de los Datos
Las consideraciones para el gobierno de datos deben garantizar que la
empresa tenga las dimensiones necesarias para permitir la transformación,
de la siguiente manera:
• Estructura: ¿Tiene la empresa la estructura organizativa necesaria y los
organismos de normalización para gestionar los aspectos de las entidades
de datos de la transformación?
• Sistema de gestión: ¿tiene la empresa el sistema de gestión y los
programas de datos necesarios para gestionar los aspectos de gobernanza
de las entidades de datos a lo largo de su ciclo de vida?
Enfoque (5/5)
• Gente: ¿Qué habilidades y roles relacionados con los datos
requiere la empresa para la transformación? Si la empresa
carece de tales recursos y habilidades, la empresa debería
considerar la adquisición de esas habilidades críticas o la
capacitación de recursos internos existentes para cumplir con
los requisitos a través de un programa de aprendizaje bien
definido.
Pasos
1. Seleccionar los modelos de referencia aplicables, punto de vista y
herramientas
2. Desarrollar la línea base de la arquitectura de datos (AS IS)
3. Desarrollar la descripción de la arquitectura de datos destino/objetivo (TO BE)
4. Realizar el análisis de brecha
5. Definir los componentes candidatos para la hoja de ruta
6. Resolver los impactos a través del panorama de la arquitectura
7. Realizar una revisión formal con los interesados
8. Finalizar la arquitectura de Datos
9. Crear el documento de definición de la arquitectura
1. Seleccionar los modelos de referencia
aplicables, punto de vista y herramientas
• Revisar, validar o desarrollar los Principios de Datos
• Seleccionar los recursos (patrones, modelos de referencia, etc.) r relevantes
para le trabajo.
• Seleccionar los puntos de vista de la arquitectura de datos que permitirán
demostrar la manera en la que se atienden los requerimientos.
• Identificar las herramientas y técnicas a usar para la captación, modelo y
análisis de datos. Ejemplo:
• Diagrama entidad/relación
• Diagrama de Clases
1.1 Principios Arquitectónicos de los Datos

• El dato es un activo
• El dato es accesible
• El dato es confiable
• Seguridad de los datos
• Accesibilidad de datos
• Datos Compartidos
• Aspectos cualitativos: Disponibilidad, Integridad, confidencialidad
2. Desarrollar la línea base de la arquitectura
de datos (AS IS)

Desarrollar la arquitectura de datos de línea base con el

alcance y al nivel de detalle suficiente como para dar
soporte a la Arquitectura de Datos de Destino/Objetivo.
3. Desarrollar la descripción de la arquitectura
de datos destino/objetivo (TO BE)

Desarrollar la arquitectura de datos de destino con el alcance

y al nivel de detalle suficiente como para dar soporte a la
visión y a la arquitectura de Negocio de Destino.
4. Realizar el análisis de brecha
• Análisis cruzado para resolver conflictos, de haberlos, entre las
diferentes vistas.
• Validación de que los modelos soporten los principios, objetivos y
restricciones.
• Considerar los cambios en el punto de vista representados en los
modelos seleccionados desde el repositorio y el documento.
• Realizar pruebas de los modelos de la arquitectura para asegurar
que cubren completamente los requerimientos.
5. Definir los componentes candidatos para la
hoja de ruta
• Posterior al desarrollo de la arquitectura de línea base, la arquitectura
de destino y el análisis de brechas, se debe elaborar una hoja de ruta
para priorizar las actividades (relacionadas con los datos) de la
siguiente fase.
• La hoja de ruta de la arquitectura de datos inicial se usará como
insumo para la definición, más detallada, de una hoja de ruta
transversal (que cubra todas las disciplinas) en la Fase E:
Oportunidades y Soluciones.
6. Resolver los impactos a través del panorama de
la arquitectura
Una vez finalizada la arquitectura de datos, es necesario comprender cualquier impacto o
implicación más amplia. En esta etapa, se deben examinar otros artefactos del panorama
de la arquitectura para determinar lo siguiente:
• ¿Afecta esta Arquitectura de Datos a cualquier arquitectura preexistente?
• ¿Se han realizado cambios recientes que afecten a la arquitectura de datos?
• ¿Hay alguna posibilidad de reutilizar el trabajo de esta arquitectura de datos en otras
áreas de la organización?
• ¿Afecta esta arquitectura de datos a otros proyectos (planificados o en progreso)?
• ¿Esta arquitectura de datos se verá afectada por otros proyectos (planificados o en
progreso)?
7. Realizar una revisión formal con los
interesados
• Verificar la motivación original para el proyecto de arquitectura y la Declaración de Trabajo de
Arquitectura en contra de la Arquitectura de Datos propuesta. Realice un análisis de impacto para
identificar las áreas donde las Arquitecturas empresariales y de aplicaciones (por ejemplo,
prácticas comerciales) pueden necesitar cambios a la luz de los cambios en la Arquitectura de
datos (por ejemplo, cambios en formularios o procedimientos, aplicaciones o sistemas de bases
de datos). Si el impacto es significativo, esto puede justificar que las arquitecturas empresariales y
de aplicaciones sean revisadas.
• Identificar las áreas donde la arquitectura de la aplicación (si existe en este momento) puede
necesitar cambios a la luz de los cambios en la arquitectura de datos o para identificar
restricciones en la arquitectura de la aplicación que va a diseñarse. Si el impacto es significativo,
puede ser apropiado hacer una breve iteración de la arquitectura de la aplicación.
• Identificar cualquier restricción en la arquitectura tecnológica que se va a diseñar, refinando la
arquitectura de datos propuesta solo si es necesario.
8. Finalizar la arquitectura de Datos
• Seleccionar estándares para cada uno de los bloques de construcción, reutilizando tanto
como sea posible de los modelos de referencia seleccionados del Depósito de
Arquitectura.
• Documentar completamente cada bloque de construcción, luego realice una verificación
cruzada final de la arquitectura general en función de los requisitos del negocio;
justificación del documento para las decisiones de bloques de construcción en el
documento de arquitectura.
• Documentar el informe de trazabilidad de los requisitos finales.
• Documentar el mapeo final de la arquitectura dentro del Repositorio de Arquitectura.
• A partir de los bloques básicos seleccionados, identifique los que podrían reutilizarse y
publíquelos en el repositorio de arquitectura. Finalice todos los productos de trabajo.
9. Crear el documento de definición de la
arquitectura
• Documentar la justificación de las decisiones acerca de los bloques de
construcción en el documento de arquitectura.
• Preparar las secciones de Arquitectura de Datos del Documento de
Definición de la Arquitectura (Evaluar las siguientes):
• Modelo de datos del Negocio
• Modelo de datos lógico
• Modelo de procesos de gestión de datos
• Matriz de Entidades de Datos/Funciones de Negocio
• Requerimientos de interoperabilidad de datos (esquemas XML,
políticas de seguridad, etc.)
Entradas (1/3)
• Solicitud de Trabajo de Arquitectura
• Evaluación de Capacidades
• Plan de Comunicaciones
• Modelo Organizacional de AE
• Marco de Referencia de AE Adaptado
• Principios de Datos
• Declaración de Trabajo de Arquitectura
• Visión de AE.
• Repositorio de AE.
Entradas (2/3)
• Versión Preliminar del Documento de Definición de la Arquitectura,
conteniendo:
• Arquitectura de Negocio de la Línea Base (detallada).
• Arquitectura de Datos de la Línea Base (de alto nivel).
• Arquitectura de Aplicación de la Línea Base (detallada o de alto nivel).
• Arquitectura Tecnológica de la Línea Base (de alto nivel).
• Arquitectura del Negocio de Destino (detallada).
• Arquitectura de Datos de Destino (de alto nivel).
• Arquitectura de Aplicación de Destino (detallada o de alto nivel).
• Arquitectura Tecnológica de Destino (de alto nivel).
Entradas (3/3)
• Especificación preliminar de Requerimientos de Arquitectura,
incluyendo:
• Resultados del Análisis de Brechas.
• Requerimientos técnicos relevantes.
• Componentes de la Arquitectura de Negocio que son parte de la
Hoja de Ruta de Arquitectura.
Salidas (1/2)
• Declaración de Trabajo de Arquitectura, actualizada si fuera
necesario.
• Principios de Datos validados o nuevos Principios de Datos
• Versión Preliminar del Documento de Definición de la
Arquitectura, conteniendo actualizaciones de contenido:
• Arquitectura de Datos de la Línea Base
• Arquitectura de Datos de Destino
• Vistas de la Arquitectura de Datos correspondiente a los Puntos
de Vista seleccionados que responden a las preocupaciones
clave de los interesados.
Salidas (2/2)
• Versión Preliminar de la Especificación de los Requerimientos de
Arquitectura, incluyendo actualizaciones de contenido:
• Resultados del Análisis de Brechas.
• Requerimientos de interoperabilidad de datos.
• Requerimientos técnicos relevantes que se aplicarán a esta evolución del
Ciclo de Desarrollo de la Arquitectura.
• Limitaciones de la Arquitectura Tecnológica.
• Requerimientos de negocio actualizados.
• Requerimientos de Aplicación Actualizados.
• Componentes de la Arquitectura de Datos que son parte del Plan de Itinerario
de Arquitectura.
Artefactos
N° Tipo Nombre
1 Catálogo Entidad de datos / Componente de datos
2 Matriz Entidad de negocio / Entidad de datos
3 Matriz Aplicación / Datos
4 Matriz Seguridad de datos
5 Diagrama Datos lógicos
6 Diagrama Diseminación de datos
7 Diagrama Seguridad de datos
8 Diagrama Jerarquía de clase
9 Diagrama Migración de datos
10 Diagrama Ciclo de vida de los datos
Ejemplo de Entidad de datos / Componente
de datos
Ejemplo de Matriz de Entidad de negocio /
Entidad de datos
Ejemplo de Matriz de Aplicación / Datos
Ejemplo de Matriz de Seguridad de Datos
Ejemplo de Diagrama Diseminación de Datos
Ejemplo de Diagrama Seguridad de Datos
Ejemplo de Diagrama Jerarquía de Clase
Ejemplo de Diagrama Migración de datos
Ejemplo de Diagrama de Ciclo de vida de los
datos
Arquitectura de Aplicación
Definición
Las empresas dependen de sus activos de información para la
toma de decisiones efectivas para la adecuada ejecución de
sus objetivos estratégicos. Por ésta razón, se requiere de una
Arquitectura de Aplicaciones que proponga la reutilización
del uso de las funcionalidades existentes. Con el diseño de
una arquitectura que sugiera un bajo acoplamiento entre sus
componentes y que promuevan la reutilización de los
mismos, favoreciendo la identificación de un conjunto de
servicios en red y la definición de los procesos por los cuales
interactúan, proporcionando información de alta
disponibilidad, confiable y oportuna.
Objetivos
01 02
Desarrollar una Arquitectura de Aplicación de Destino Identificar componentes candidatos de la hoja de ruta de
la arquitectura.

• Desarrollar una Arquitectura de  Identificar los componentes candidatos

Aplicación de Destino que sea funcional de la hoja de ruta de la arquitectura
a la Arquitectura de Negocio y a la sobre la base de las brechas entre la
Visión de Arquitectura, y que responda arquitectura de línea base y la
a la vez a la Petición de Trabajo de Arquitectura de Aplicación de Destino
Arquitectura y a las preocupaciones de (Objetivo).
los interesados.
Enfoque
El Repositorio de Arquitectura
El equipo de arquitectura debe considerar qué recursos de Arquitectura de Aplicaciones están
disponibles en el Repositorio (Depósito) de Arquitectura de la organización.
Por ejemplo:
• I.1. Modelos de Arquitectura de Aplicaciones
• El TM Forum ha desarrollado modelos detallados de aplicaciones relevantes para la
industria de las telecomunicaciones
• La Open Group ha desarrollado un modelo detallado de referencia de arquitectura de
aplicaciones para el segmento de TI de las organizaciones.
• El Object Management Group (OMG) tiene varias Fuerzas de Tareas de Dominio verticales
que desarrollan modelos de software relevantes para dominios verticales específicos tales
como Salud, Transporte, Finanzas, etc.
• Modelos de aplicaciones relevantes para funciones comerciales comunes de alto nivel,
como el comercio electrónico, la gestión de la cadena de suministro, etc.
Pasos
1. Seleccionar los modelos de referencia aplicables, punto de vista y
herramientas
2. Desarrollar la línea base de la arquitectura de aplicación (AS IS)
3. Desarrollar la descripción de la arquitectura de aplicación
destino/objetivo (TO BE)
4. Realizar el análisis de brechas
5. Definir los componentes candidatos para la hoja de ruta
6. Resolver los impactos a través del panorama de la arquitectura
7. Realizar una revisión formal con los interesados
8. Finalizar la arquitectura de aplicación
9. Crear el documento de definición de la arquitectura
 1. Seleccionar los modelos de referencia
aplicables, punto de vista y herramientas
• Revisar y validar los Principios de Aplicaciones
• Seleccionar los recursos relevantes (patrones, modelos de referencia, etc.) del
repositorio de Arquitectura.
• Identificar los catálogos, matrices y diagramas requeridos para el desarrollo de la
Arquitectura de Aplicaciones.
• Seleccionar los puntos de vista relevantes de la arquitectura de aplicaciones que le
permitirán al arquitecto demostrar cómo se abordan las preocupaciones de los
interesados en la arquitectura de la aplicación.
• Identificar las herramientas y técnicas apropiadas para ser usadas para la captura,
modelamiento y análisis de la Arquitectura de la Aplicación, en asociación con los
puntos de vista seleccionados.
2. Desarrollar la línea base de la arquitectura
de aplicación (AS IS)

Desarrolle la Línea Base de la Arquitectura de Aplicación existente en

la medida necesaria para soportar la Arquitectura de Aplicación de
Destino. El alcance y el nivel de detalle que se definirá dependerá de
la medida en que las aplicaciones existentes puedan transferirse a la
arquitectura de la aplicación de destino y de si existen las
descripciones de la arquitectura. Cuando sea necesario desarrollar
nuevos modelos de arquitectura para satisfacer las inquietudes de las
partes interesadas, utilice los modelos identificados en el Paso 1
como una guía para crear nuevos contenidos de arquitectura para
describir la arquitectura de referencia.
3. Desarrollar la descripción de la arquitectura
de Aplicaciones destino/objetivo (TO BE)
Desarrolle una descripción del objetivo para la arquitectura de la
aplicación en la medida necesaria para respaldar la visión de la
arquitectura destino, la arquitectura de negocios objetivo y la
arquitectura de datos objetivo. El alcance y el nivel de detalle que se
definirá dependerá de la relevancia de los elementos de la aplicación
para alcanzar la Visión de la arquitectura de destino y de si existen
descripciones arquitectónicas. Cuando sea necesario desarrollar nuevos
modelos de arquitectura para satisfacer las inquietudes de las partes
interesadas, utilice los modelos identificados en el Paso 1 como una guía
para crear nuevos contenidos de arquitectura para describir la
Arquitectura objetivo.
4. Realizar el análisis de brechas
En primer lugar, compruebe los modelos de arquitectura para la
coherencia interna y la precisión. Tenga en cuenta los cambios en el
punto de vista representado en los modelos seleccionados del
Repositorio de Arquitectura y documente los cambios. Luego, pruebe
los modelos de arquitectura para ver si están completos. Finalmente,
identifique las brechas entre la línea base y el objetivo usando la
técnica de análisis de brechas.
5. Definir los componentes candidatos para la
hoja de ruta
Después de la creación de una arquitectura de línea base, arquitectura
de destino y análisis de brechas, se requiere una hoja de ruta de
aplicaciones para priorizar las actividades en las próximas fases. Esta
Hoja de ruta de la arquitectura de aplicación inicial se utilizará como
materia prima para respaldar la definición más detallada de una hoja
de ruta consolidada e interdisciplinaria dentro de la Fase E:
Oportunidades y soluciones
6. Resolver los impactos a través del panorama de
la arquitectura
Una vez finalizada la arquitectura de aplicaciones, es necesario comprender cualquier
impacto o implicación más amplia. En esta etapa, se deben examinar otros artefactos del
panorama de la arquitectura para determinar lo siguiente:
• ¿Afecta esta Arquitectura de Aplicación a cualquier arquitectura preexistente?
• ¿Se han realizado cambios recientes que afecten a la arquitectura de aplicación?
• ¿Hay alguna posibilidad de reutilizar el trabajo de esta arquitectura de aplicación en
otras áreas de la organización?
• ¿Afecta esta arquitectura de aplicación a otros proyectos (planificados o en progreso)?
• ¿Esta arquitectura de aplicación se verá afectada por otros proyectos (planificados o en
progreso)?
7. Realizar una revisión formal con los
interesados
Compare la motivación original para el proyecto de arquitectura y la
Declaración de Trabajo de Arquitectura versus la Arquitectura de Aplicación
propuesta. Realice un análisis de impacto para identificar las áreas donde las
Arquitecturas de Negocio y de Datos (por ejemplo, prácticas comerciales)
pueden necesitar cambios a la luz de los cambios en la Arquitectura de la
aplicación (por ejemplo, cambios en formularios o procedimientos,
aplicaciones o sistemas de bases de datos). Si el impacto es significativo, esto
puede justificar la revisión de las arquitecturas de datos y negocios.
Finalmente, identifique cualquier restricción en la Arquitectura de Tecnología
(especialmente la infraestructura) a punto de ser diseñada.
8. Finalizar la arquitectura de Aplicaciones
Seleccione estándares para cada uno de los bloques de construcción, reutilizando tanto
como sea posible de los modelos de referencia seleccionados del Repositorio de
Arquitectura. Documente completamente cada bloque de construcción, y luego realice una
verificación cruzada final de la arquitectura general en función de los requisitos del
negocio. Documente los fundamentos de las decisiones de bloques de construcción en el
documento de arquitectura. Documente el informe de trazabilidad de los requisitos finales.
También documente el mapeo final de la arquitectura dentro del Repositorio de
Arquitectura. A partir de los bloques básicos seleccionados, identifique los que podrían
reutilizarse y publíquelos en el repositorio de arquitectura. Finalice todos los productos de
trabajo.
9. Crear el documento de definición de la
arquitectura
• Documentar la justificación de las decisiones acerca de los bloques de
construcción en el documento de arquitectura.
• Preparar las secciones de Arquitectura de Aplicaciones del
Documento de Definición de la Arquitectura .
• Envíe el documento para su revisión por las partes interesadas
pertinentes, e incorpore comentarios.
Entradas (1/3)
• Solicitud de Trabajo de Arquitectura
• Evaluación de Capacidades
• Plan de Comunicaciones
• Modelo Organizacional de AE
• Marco de Referencia de AE Adaptado
• Principios de Aplicaciones
• Declaración de Trabajo de Arquitectura
• Visión de AE.
• Repositorio de AE.
Entradas (2/3)
• Versión Preliminar del Documento de Definición de la Arquitectura,
conteniendo:
• Arquitectura de Negocio de la Línea Base (detallada).
• Arquitectura de Datos de la Línea Base (detallada o de alto nivel).
• Arquitectura de Aplicación de la Línea Base (de alto nivel).
• Arquitectura Tecnológica de la Línea Base (de alto nivel).
• Arquitectura del Negocio de Destino (detallada).
• Arquitectura de Datos de Destino (detallada o de alto nivel).
• Arquitectura de Aplicación de Destino (de alto nivel).
• Arquitectura Tecnológica de Destino (de alto nivel).
Entradas (3/3)
• Especificación preliminar de Requerimientos de Arquitectura,
incluyendo:
• Resultados del Análisis de Brechas.
• Requerimientos técnicos relevantes.
• Componentes de la Arquitectura de Negocio y Datos que son parte
de la Hoja de Ruta de Arquitectura.
Salidas (1/2)
• Declaración de Trabajo de Arquitectura, actualizada si fuera
necesario.
• Principios de Aplicación validados o nuevos Principios de Aplicación
• Versión Preliminar del Documento de Definición de la Arquitectura,
conteniendo actualizaciones de:
• Arquitectura de Aplicación de la Línea Base
• Arquitectura de Aplicación de Destino
• Vistas de la Arquitectura de Aplicaciones correspondiente a los Puntos de
Vista seleccionados que responden a las preocupaciones clave de los
interesados.
Salidas (2/2)
• Versión Preliminar de la Especificación de los Requerimientos de
Arquitectura, incluyendo actualizaciones de contenido:
• Resultados del Análisis de Brechas.
• Requerimientos de interoperabilidad de Aplicación.
• Requerimientos técnicos relevantes que se aplicarán a esta evolución del
Ciclo de Desarrollo de la Arquitectura.
• Restricciones de la Arquitectura Tecnológica.
• Requerimientos de negocio actualizados.
• Requerimientos de Datos Actualizados.
• Componentes de la Arquitectura de Aplicaciones que son parte del Plan de
Itinerario de Arquitectura.
Artefactos (1/2)
N° Tipo Nombre

1 Catálogo Portafolio de aplicaciones

2 Catálogo Interfaz

3 Matriz Aplicación / Organización

4 Matriz Roles / Aplicación

5 Matriz Aplicación / Función

6 Matriz Interacción de Aplicaciones

7 Diagrama Comunicación de aplicaciones

8 Diagrama Ubicación de aplicaciones y usuarios

Artefactos (2/2)

N° Tipo Nombre

9 Diagrama Caso de uso de la aplicación

10 Diagrama Manejabilidad de la empresa

11 Diagrama Realización del proceso / aplicación

12 Diagrama Ingeniería de Software

13 Diagrama Migración de aplicaciones

14 Diagrama Distribución de software

Ejemplo de Catálogo de Cartera de
aplicaciones
Ejemplo de Catálogo de Interfaz
Ejemplo de Matriz de Aplicación /
Organización
Ejemplo de Matriz de Roles / Aplicación
Ejemplo de Matriz de Aplicación / Función
Ejemplo de Diagrama de Comunicación de
aplicaciones
Ejemplo de Diagrama de Ubicación de
aplicaciones y usuarios
Ejemplo de Diagrama de Caso de uso de la
aplicación
Ejemplo de Diagrama de Manejabilidad de la
empresa
Ejemplo de Diagrama de Ingeniería del
Software
Ejemplo de Diagrama de Migración de
aplicaciones
Taller de Arquitectura de Sistemas de
Información
Taller de Arquitectura de Sistemas de
Información
1. Elaborar en grupo los catálogos:
a) Catálogo de Entidad de Datos
b) Catálogo de Portafolio de Aplicaciones
c) Catálogo de Interfaces de Aplicaciones

2. Elaborar en grupo las matrices:

a) Matriz de Entidad de Negocios vs Entidad de Datos
b) Matriz de Datos vs Aplicación
c) Matriz de Seguridad de Datos
d) Matriz de Aplicación vs Organización
e) Matriz de Roles vs Aplicación
f) Matriz de Aplicación vs Función

3. Presentar en clases.
 Gracias
www.newhorizons.edu.pe