Está en la página 1de 9

DATA ARCHITECTURE

Identifica y define la data que soportaran las funciones de negocio definidas en el modelo de negocio.
- Entidad: cualquier persona, lugar, concepto, cosa o evento que es importante para el negocio.
- Atributo: forma parte y define que es una entidad.
- Relacin: atributo de otra entidad, que sirve para definir otra entidad del negocio (FK)
PASOS:
Forman parte del 15% de desarrollo del Planeamiento de la Arquitectura Empresarial.

1. Listar entidades candidatas (10%)
Identificar todas las potenciales entidades de datos necesarias para soportar el negocio.

Entregables:
- Lista de nombres de las entidades candidatas.
o Task 1: Dividir el modelo del negocio entre los miembros de equipo:
o Task 2: Cada miembro de equipo debe desarrollar una lista de entidades. Se deben de escoger entidades
segn las funciones de negocio.
o Task 3: Combinar las listar realizadas en una sola, sin importar la duplicidad. Luego se proceder a retirar
los duplicados obvios. Las entidades deben ser generalmente el 50% del nmero de las funciones de
negocio.

2. Definir entidades, atributos y relaciones (60%)
Crear una definicin estndar y descripcin de cada entidad en la Arquitectura de Datos. Tambin se debe
brindar una ilustracin grafica de las interrelaciones. El propsito es definir entidades, no bases de datos.

Entregables:
- Entidades documentadas y definidas
- Diagrama Entidad-Relacin
ENTIDAD
Entity name: definicin de la entidad.
Alternate name: nombres aceptables para la entidad, pero no el preferido.
Indentifier: cada entidad debe tener un identificador. Es un valor que puede distinguir
nicamente a cada entidad, para empleado seria el DNI.
Definition: descripcin textual de la entidad:
Is-a-kind-of entity: es til para diferenciar entidades entre entidades similares.
ATRIBUTO
Attribute name: nombre asignado a una caracterstica.
Definition: descripcin textual del atributo.
Value set: el rango de valores, dominios o tipos de valores para el atributo.
Business Rule: reglas o condiciones que controlan el valor del atributo.
RELATIONSHIP: asociacin entre 2 entidades.
Relationship name: todas las relaciones tienen nombre. Es un verbo que describe la relacin
entre 2 entidades.
Related entity name: el nombre de la segunda entidad en la relacin.
Cardinality: describe el nmero de entidades envueltas en la relacin, expresadas en trminos
de 0, 1, o *,
Definition & rules: una explicacin ms extensa de las relaciones entre entidades.

o Task 1: Prepararse para la definicin de entidades, los nombres de las entidades deben escogerse en
conceso total.
o Task 2: Definir las entidades de la lista de candidatas.
o Task 3: Simplificar relaciones y definiciones complicadas
Generalizacin: juntar dos entidades similares
Abstraccin: relacionar dos o ms entidades.
Asimilacin: eliminar una entidad dependiente.
Separacin: separar entidades compuestas en entidades bsicas.
o Task 4: Asegurarse que las definiciones de entidades sean consistentes con las dems.
o Task 5: Elaborar diagramas Entidad-Relacin para ilustrar el modelo de la Arquitectura de Datos.
o Task 6:
Un buena Arquitectura de Datos es: Comprensible, Completa y Consistente; y Estable.
3. Relacionar las entidades a las funciones de negocio (20%)
Determinar las entidades que son creadas, recuperadas, actualizadas y eliminadas por las funciones de negocio.

Entregables:
- Entity-to-business function lists and matrices
- Entity-to-current application lists and matrices

o Task 1: Relacionar cada funcin al menor nivel de detalle en el modelo de negocio al conjunto de
entidades. Pueden ser CREATED, UPDATED y REFERENCED. Matriz CRUD.
o Task 2: Crear una matriz de relacin Funcin-Entidad
o Task 3: Revisar en una reunin, las relaciones Funcin-Entidad, al relacionar cada entidad a un grupo de
funciones de negocio.
o Task 4: Relacionar las entidades a aplicaciones existentes o fuentes de informacin que las relacionen.

4. Distribuir la Arquitectura de Datos (10%)
Se elabora el documento y se distribuye.

Entregables:
- Documento de Arquitectura de Datos:
o Introduccin
o Lista de los nombres de las entidades
o Definicin completa de entidades
o Diagrama de las relaciones de entidades
o Matriz de uso de entidades
- Material de presentacin
- Solicitar comentarios de usuarios

o Task 1: Escribir una introduccin a la Arquitectura de Datos, con una introduccin de cmo interpretar
los reportes.
o Task 2: Preparar material de presentacin. Debe depender del tipo de negocio al que pertenece la
Arquitectura de Datos.
o Task 3: Recolectar comentarios escritos por los implicados en el negocio.

APPLICATIONS ARCHITECTURE
Define los tipos de aplicaciones necesarias para administrar la data y dar soporte a las funciones de negocio de la
empresa. Define lo que las aplicaciones van a hacer para administrar la data y proveer de informacin a las personas que
usen las funciones de negocio.
Incluye actividades como: introducir, editar, clasificacin, cambio, archivar, analizar y referenciar data. Corresponder a la
columna de Owners View del framework de Zachman.
PASOS:
Forman parte del 15% de desarrollo del Planeamiento de la Arquitectura Empresarial.

1. Listar aplicaciones candidatas (10%)
Identificar cada aplicacin posible, que sea necesaria para administrar la data y dar soporte al negocio.

Entregables:
- Lista de las posibles aplicaciones, que debe contener un definicin preliminar, la funcion de negocio a la que dan
soporte y la informacin administrada.

o Task 1: Identificar aplicaciones candidatas. Usar la matriz CRUD para proponer aplicaciones que realicen
las actividades de administracin de data y aplicaciones que automaticen o provean de data a las
funciones de negocio.
El nombre de la aplicacin debe indicar el propsito de la misma.
o Task 2: Identificar aplicaciones que mejoren el negocio o provean de ventaja competitiva. Usar la matriz
CRUD para garantizar que toda la data est siendo administrada.
o Task 3: Combinar todas las listas de aplicaciones propuestas por los miembros de equipo en una sola
lista.

2. Definir la aplicacin (50%)
Proveer una definicin estndar para cada aplicacin en la Arquitectura de Aplicaciones.

Entregables:
- Definicin de aplicaciones
- Esquema de la arquitectura de aplicaciones.

o Task 1: Asignar aplicaciones a los miembros de equipo para su definicin.
o Task 2: Definir cada una de las aplicaciones, la descripcin debe incluir los siguientes puntos: propsito,
descripcin general, las oportunidades de negocio y el beneficio. Debe estar en un lenguaje no tcnico.
o Task 3: Colocar las definiciones en una herramienta para que el equipo revise y edite las definiciones de
las aplicaciones.
o Task 4: Simplificar aplicaciones complicadas y eliminar la redundancia. Si una aplicacin parece muy
compleja puede ser que contiene muchas aplicaciones en una sola.
o Task 5: Anotar ideas sobre software externo que puedan ayudar o formar parte de las aplicaciones de la
empresa.
o Task 6: Dibujar planos o esquemas de la Arquitectura de Aplicaciones.
o Task 7: Asegurar la calidad de la Arquitectura de Aplicaciones.
La arquitectura debe ser comprensible: la definicin tiene sentido y es entendible entre todas
las personas de la empresa.
Debe est completa: las aplicaciones deben soportar todas las funciones de negocio y cada
entidad debe ser administrada.
Debe ser estable: debe estar basada nicamente en el modelo de negocio y la Arquitectura de
Datos y es independiente al usuario que la use.

3. Relacionar aplicacin a funciones (15%)
Identificar las funciones de negocio que son directamente soportadas y realizadas por las aplicaciones.

Entregables:
- Lista y matriz de Aplicaciones-Funciones
- Lista y matriz de Aplicaciones-Organizacin

o Task 1: Para cada aplicacin, identificar la funcin de negocio soportada. Eliminar sobrecargo de
aplicaciones. Las funciones de negocio soportadas debern ser listadas directamente en el reporte de
definicin de aplicaciones.
o Task 2: Listar las funciones no soportadas y explicar la razn. No necesariamente todas las funciones son
soportadas.
o Task 3: Relaciones las aplicaciones alas unidades organizativas a travs de las funciones de negocio.

4. Analizar el impacto a aplicaciones actuales (15%)
Determinar el impacto de las aplicaciones en las aplicaciones existentes en la empresa.

Entregables:
- Declaracin del Impacto de la Arquitectura de Aplicaciones en el sistema existente.

o Task 1: Relacionar cada aplicacin en la Arquitectura al sistema existente definido en el Catalogo de
Recursos Informticos. Indicar si cada aplicacin existente va a ser:
Completamente remplazada, parcialmente remplazada o retenida.
Tambin se debe incluir el anlisis de impacto.
o Task 2: Revisar que la Valoracin del impacto este completa. Cada aplicacin existente debe estar
relacionada mediante el impacto a una Arquitectura de Aplicaciones.

5. Distribuir la Arquitectura de Aplicaciones (10%)
Informar a las personas de la empresa de la definicin de la Arquitectura de Aplicaciones y preguntarles sobre
sus comentarios y sugerencias.

Entregable:
- El Documento de la Arquitectura de Aplicaciones est completo y distribuido.

o Task 1: Escribir una introduccin para la Arquitectura de Aplicaciones.
o Task 2: Generar reportes, con una introduccin para cada uno, para explicar el reporte y discutir
resultados significantes o el impacto en el negocio.
o Task 3: Preparar un presentacin y materiales apropiados.
o Task 4: Presentar la arquitectura de aplicaciones para administrar y distribuir el reporte.
o Task 5: Recolectar los comentarios escritos.

TECHNOLOGY ARCHITECTURE
Define la mayor cantidad de tipos de tecnologa necesitados para proveer un ambiente para las aplicaciones que estas
administrando la data. Corresponde al Owners View en Zachman. Es un modelo conceptual para definir plataformas.
1. Identificar los principios de tecnologa y plataformas.
Definir los principios de las plataformas de tecnologa y las potenciales plataformas necesarias para soportar a
toda una empresa.

Entregables:
- Technology platform priciples.
- Lista de las plataformas de tecnologa candidatas.

o Task 1: Formular los principios de plataformas tecnolgicas. Obtener descripciones y predicciones sobre
tendencias tecnolgicas de expertos sobre el tema. Se debe llegar a un consenso sobre los principios.
o Task 2: Listar las potenciales plataformas tecnolgicas. La lista no debe indicar los vendedores o
proveedores de la tecnologa. Colocar definiciones dentro de un glosario de trminos.

2. Definir las plataformas y distribucin de Data y Aplicaciones.
Determinar una estrategia para distribuir aplicaciones y data, y definir la plataforma tecnolgica que los
soportara.

Entregables
- Lista de Distribucin de la Data y aplicaciones.
- Configuracin de las plataformas tecnolgicas.
- Evalucaion de la Arquitectura Conceptual

o Task 1: Listar las ubicaciones de las funciones de negocio, mostrar las unidades organizacionales y las
funciones realizadas.
o Task 2: Definir la distribucin de data y aplicaciones. Determinar la ubicacin conceptual (lugar fsico)
para almacenar data y ejecutar aplicaciones. detallar procedimientos y criterios para distribuir las
aplicaciones y datos. Sealar:
Por cada ubicacin conceptual, la data y aplicaciones que contendr
Por cada entidad y aplicacin, su localizacin
o Task 3: Definir la configuracin de la plataforma tecnolgica.
The Conceptual Workstation: son los equipos usados por los usuarios para acceder a las aplicaciones o
data. Consiste en unidades de almacenamiento y compartimientos.
Localizaciones de almacenamiento: un repositorio que soporta aplicaciones y data. Son
computadoras, gabinetes.
Compartimientos: proveen un gran rango de facilidades, como correo electrnico,
administrador de informacin personal, navegadores, etc.
The Conceptual Enterprise Network: consiste en computadoras, dispositivos de almacenamiento y
facilidades de telecomunicaciones. Todos los elementos de computacin estn conectados.
The Business System Architecture: es la tecnologa usada para implementar y mantener las aplicaciones
y bases de datos de la empresa. Propsitos:
Actualizar informacin, crear, o eliminarla.
Dar acceso a las aplicaciones a la data.
Realizar reportes.
Acceder a la data mediante gestores de datos.
Ingresar reglas de negocio para autorizar ingreso de usuarios, o reglas que gobiernen las
funciones de negocio.
o Task 4: Evaluar la Arquitectura Tecnolgica Conceptual, realizar modelos de performance para
determinar que la arquitectura conceptual va a satisfacer los requerimientos del negocio.

3. Relacionar las plataformas de tecnologa a aplicaciones y funciones de negocio.
Establecer una justificacin a la plataforma tecnolgica al relacionarla con las funciones de negocio que la
utilizaran.

Entregables:
- Referencia de relacin plataforma tecnolgica-aplicacin.
- Referencia de relacin plataforma tecnolgica-funcin de negocio.

o Task 1: Relacionar la plataforma tecnolgica a las aplicaciones.
o Task 2: Relacionar la plataforma tecnolgica a las funciones de negocio.
o
4. Distribuir la Arquitectura Tecnolgica.

IMPLEMENTATION PLAN
Preparar el plan para la implementacin de la Arquitectura. Tambin es conocido como estrategia de migracin.
1. Secuenciar las aplicaciones.
Establecer prioridades y formular una secuencia en la que las aplicaciones deben ser implementadas.
Aplicaciones que CREAN data deben ser implementadas antes que las aplicaciones que USAN
data.
Consideraciones para elegir que estructura debe ser construida primero:
a. Construir el suite ejecutiva primero, luego construir los pisos debajo de l.
b. Tener la suite ejecutiva en el stano o el primer piso y no en el techo.
c. Al comienzo tener la suite ejecutiva en el primer piso mientras se construyen los pisos de arriba.
d. Comenzar la construccin con los cimientos y stano y continuar agregando pisos, la suite ejecutiva en
el tope debe ser construida al final.

Consideraciones para implementar las facilidades del sistema:
o Construir el EIS (Executive Information System) primero, conectarla mediante interfaces temporales
para transferir data de archivos existentes y base de datos a la base de datos interna del EIS.
o El EIS es implementada primero con su propia base de datos interna.
o El logro tradicional para establecer prioridades es construir aplicaciones en orden de importancia.
o Construir primero las aplicaciones que crean datos, la fuente de datos crecer con el tiempo.

Entregables:
- Tabla y matriz de relacin Aplicacin-Entidad de datos.
- Prioridades de secuencia.
- Aplicaciones en orden de implementacin.
- Plan para convertir y/o remplazar sistemas existentes.
- Aplicaciones agrupadas en proyectos.
- Secuencia de implementacin de tecnologa.

o Task 1: Relacionar las aplicaciones a entidades de datos a travs de las funciones de negocio, usando la
matriz CRUD.
o Task 2: Reordenar la matriz aplicacin-data para determinar la secuencia de data. Se deben poner en el
topo de la matriz las aplicaciones con ms data asignada para implementarlas primero.
o Task 3: Ajustar la secuencia de data-driven para acomodarla a lo que el negocio necesita. El principio de
dependencia de datos para secuenciar aplicaciones es el criterio ms importante. Las aplicaciones con
mejor recuperacin de dinero deben ser implementadas lo ms pronto posible.
Criterios a tener en cuenta si se decide mover la secuencia de implementacin de una aplicacin:
Mover la aplicacin en la secuencia y construir interfaces temporales para archivos existentes y
bases de datos para datos necesarios que no sern parte del recursos de data compartida.
Mover la aplicacin en la secuencia y aadirle capacidades de creacin y mantenimiento de toda
la data necesaria.
Dividir la aplicacin. Partes de la aplicacin que solo consumirn data disponible pueden ser
movidas a las primeras posiciones de la secuencia.
o Task 4: Hacer ajustes a la secuencia.
o Task 5: Mostrar la secuencia de los remplazos de sistema existentes y adquisiciones tecnolgicas.

2. Estimar el esfuerzo, recursos y elaborar un horario.
Estimar el esfuerzo requerido para la implementacin, determinar los recursos necesarios, y producir un horario
para implementar la arquitectura.

Entregables:
- Determinar los recursos necesarios para la implementacin.
- Esfuerzo estimando para la implementacin de cada aplicacin.
- Horario para la implementacin y/o migracin.

o Task 1: Estimar el tiempo para adquirir e implementar paquetes de software. La arquitectura de
aplicaciones no indica que se va a comprar o desarrollar internamente. Se debe tratar de evitar la
compra de paquetes de software por los siguientes motivos:
El cdigo de la data y aplicaciones no es fcilmente compartida, modificable o expandida.
Las plataformas tecnolgicas pueden ser incompatibles.
El paquete de software puede no satisfacer los requerimientos bsicos definidos en la
arquitectura.
o Task 2: Hacer estimaciones acerca de la disponibilidad de recursos y estimar el esfuerzo para
implementar las aplicaciones.
o Task 3: Producir el horario de implementacin. Las estimaciones y recursos asumidos deben ser
combinados para producir un calendario de implementacin.
o Task 4: Obtener la aceptacin preliminar de la estrategia de implementacin de los ejecutivos clave.
Hacer reuniones claves con los responsables de aceptar el plan final. Hacer cambios segn las
indicaciones dadas.

3. Estimar los costos y beneficios del plan.
Muchas organizaciones basan sus decisiones en base a consideraciones financieras. Un anlisis de costos y
beneficios debe ser parte del plan de implementacin.

Entregables:
- Anlisis costo-beneficio.
- Resumen de los beneficios y oportunidades.

o Task 1: Realizar un anlisis costo-beneficio, el anlisis debe abarcar costos operaciones y de desarrollo.
Las categoras de costos son: personas, hardware y tecnologa, software, redes y comunicaciones.
Los beneficios deben ser cuantificados en unidades monetarias.
o Task 2: Obtener la aprobacin previa del anlisis costo-beneficio de la administracin.
o Task 3: Listar la oportunidades intangibles y beneficios.

4. Determinar los factores de xito y hacer recomendaciones.
Determinar los factores de xito necesarios para implementar la arquitectura y el plan, se debe formular
recomendaciones a la administracin para obtener decisiones favorables.

Entregables:
- Reporte preliminar de factores de xito.
- Requerimientos de entrenamiento determinados.
- Calendario le la fase de Transicin.

o Task 1: Preparar las recomendaciones, listar los factores crticos de xito para implementar el plan. Se
debe incluir lo siguiente:
Establecimiento de nuevas organizaciones de los sistemas de informacin o funciones.
Iniciacin inmediata de la Fase de Transicin.
Aprobacin de los planes.
Adopcin de nuevos mtodos de desarrollo de sistemas.
Evaluacin, seleccin, adquisicin, instalacin de las nuevas tecnologas.
Estndares y procedimientos.
Polticas aprobadas.
Lder de la implementacin.
Presupuesto aprobado.
Entrenamiento.
Reorganizacin de los Sistemas de Informacin.
Se debe describir en detalle cada factor de xito crtico para la implementacin de las arquitecturas y el
plan.
o Task 2: Confirmar las recomendaciones con la administracin.
o Task 3: Definir los requerimientos de entrenamiento.
o Task 4: Desarrollar un calendario de la fase de transicin.