FASE C: ARQUITECTURA DE LOS SISTEMAS DE INFORMACION

Compuesta por dos arquitecturas, la de Datos y la de Aplicaciones, las cuales deben desarrollarse coordinadamente para obtener un resultado integrado y completo. La Arquitectura de Datos define las principales entidades de datos que son necesarias para el funcionamiento de la organizacin de una forma completa, consistente y estable; se deben definir las entidades de datos relevantes para la organizacin y no el diseo lgico o fsico de las bases de datos. Se analizan archivos y bases de datos existentes. Validar que no se han dejado de lado servicios y elementos de datos importantes para los objetivos e intereses de los usuarios, por ejemplo, data que no est localizada o disponible donde se la necesita, data no creada, data creada pero no utilizada. Los principales entregables Diagrama Entidad Relacin y Matriz Funcin Entidad (CRUD).

 La Arquitectura de Aplicaciones define las principales clases de aplicaciones que apoyarn al negocio y procesarn los datos, no es una descripcin en trminos computacionales, sino como grupos lgicos que gestionan objetos de datos y dan soporte a las funciones de la arquitectura de negocios. Validar que no se han dejado de lado servicios y aplicaciones importantes para los objetivos e intereses de los usuarios, ya sea por error, equivocacin o por que an no se definieron.

Es necesario hacer previamente una descripcin de la arquitectura de aplicaciones existente, siendo los principales entregables modelos de servicios para aplicaciones comunes, para la interoperabilidad de las aplicaciones, la Matriz Aplicaciones Funciones de Negocio y la Definicin de las Aplicaciones Candidatas.

MATRIZ PROCESOS - ENTIDAD

Se construye una matriz con todas los Procesos identificadas para la empresa como filas y todas las Entidades de Datos determinadas como columnas. Esta matriz es una de las ms importantes del PEI, ya que permite relacionar las dos arquitecturas que generan los Sistemas de

Informacin, la arquitectura de Procesos y la de Datos. Es el embrin de todos los sistemas de informacin a construir o modificar.
Los elementos de esta matriz que lo ameriten deben indicar el tipo de relacin entre Proceso y Entidad; si el Proceso crea una Entidad se coloca C, si slo la consulta o lee se coloca R, si la actualiza en sus datos se coloca U y si la puede borrar se coloca D.

 Este anlisis nos indica a nivel empresa cules Procesos estn relacionadas de alguna forma con las Entidades de Datos, permite ver si hay Procesos que no utilizan Entidades, o Entidades que no son creadas por alguna Proceso o Entidades creadas por varios Procesos. Este Anlisis por Excepcin nos obliga a corregir situaciones problema

como las mencionadas en el punto anterior.

A partir de esta matriz tambin se hace un Anlisis de Afinidad para agrupar Procesos, en base a su pertenencia a Areas de Negocio comunes y a las Entidades que crean. Se puede iniciar el Anlisis de Afinidad agrupando a los Procesos segn el ciclo de vida del Negocio. Se deben verificar las relaciones entre Procesos y Entidades para ver que sean vlidas y no falte ninguna. Se debe chequear esta Matriz con el Diagrama Entidad-Relacin y con el Diagrama de Descomposicin de Procesos, deben ser consistentes entre ellos.

CLUSTERING DE MATRIZ PROCESO - ENTIDAD

La Matriz Proceso-Entidad debe ser agrupada para mostrar cules procesos y datos van juntos en forma natural. Este agrupamiento es la base para definir los Sistemas con sus principales procesos y data a utilizar, as como para establecer las Areas de Negocio a analizar. El mtodo para el clustering comienza con una lista de los Procesos en base al ciclo de vida del negocio, para ir agrupando y reacomodando las Entidades de Datos segn los Procesos que las crean.

Por ejemplo, se pueden listar primero los procesos de planeacin del negocio, luego los de financiamiento, marketing, produccin, distribucin, administrativas, etc.
Respecto a las Entidades deben reacomodarse en las columnas tal que los elementos con C queden en diagonal de izquierda a derecha en la matriz.

 Una vez que se tiene la diagonal de Cs, se definen submatrices que contengan grupos afines de Procesos relacionados a las Entidades que crean y que representan los Sistemas de Informacin requeridos, a los cuales se les da un nombre. Cuando existen utilizaciones de data (R U) que caen fuera de algn

agrupamiento, quiere decir que el Proceso que origina esta accin requiere acceder a una Entidad de otro grupo, por lo que deben anotarse estas relaciones con lneas dirigidas entre Sistemas.
Se puede construir un Diagrama de Dependencia de Procesos a partir de todas las interrelaciones halladas por la utilizacin de datos entre Procesos en la Matriz Proceso - Entidad.

Proceso A

Proceso B

El Proceso A genera o actualiza data que es requerida por el Proceso B, la data puede pasar directamente de A hacia B o a travs de la actualizacin de algn registro de base de datos usado por B.
Los Diagramas de Dependencia de Procesos son tiles ya que clarifican el entendimiento del funcionamiento de la empresa, y permiten minimizar hasta lo necesario las relaciones entre Sistemas, pero no son obligatorios.

DEFINICION DE GRUPOS DE APLICACIONES

Al terminar el anlisis de procesos se debe tener una idea clara y priorizada de las aplicaciones a desarrollar o modificar para toda la empresa, incluyendo sistemas urgentes para informacin de ejecutivos (EIS) y para apoyo a la toma de decisiones (DSS).
Si la empresa tiene los recursos necesarios y los equipos entrenados para la gestin y desarrollo de sistemas (especialmente base de datos y aplicativos), puede empezarse con el desarrollo de varias aplicaciones a la vez, caso contrario escoger los de mayor rentabilidad o por requerimiento de los Directivos.

Se define un Grupo de Aplicaciones a partir del agrupamiento de la Matriz Proceso - Entidad, considerando :
No se tiene un mismo Proceso en dos Grupos. Generalmente no se actualiza data de un Grupo a otro, aunque alguna data debe pasar entre Grupos. Debe ser lo suficientemente pequea para un anlisis efectivo, y lo suficientemente grande para compartir data en forma coherente.

 Un Grupos de Aplicaciones puede contener varios Sistemas de Informacin, la delimitacin de stos se da en el Desarrollo posterior.

Criterios para priorizar Grupos de Aplicaciones

Beneficios Potenciales Retorno de la Inversin, tangible o intangible Logro de FCE Logro de Metas Solucin de problemas serios
Demanda Presin de Ejecutivos por nuevos y mejores sistemas Necesidades evaluadas Razones polticas

Impacto Organizacional Nmero de organizaciones y personal afectado Si las organizaciones estn geogrficamente dispersas

 Sistemas Existentes Adecuacin o valor de sistemas existentes Relacin con sistemas existentes Estimado de costos de mantenimiento futuro Exito Muy Probable Complejidad menor Grado de aceptacin del negocio Longitud del proyecto Prerrequisitos y Riesgos Recursos Requeridos Existencia de modelos de datos y procesos Existencia de herramientas y software ya instalado Calidad de analistas disponibles Fondos requeridos Implantacin Concurrente Si varias aplicaciones o grupos se pueden dar a la vez Si se puede preparar gente que rpidamente vaya a otro proyecto Si ya se tiene un buen modelado de datos para un grupo

MODELOS DE REFERENCIA PARA EL MARCO TOGAF

TOGAF presenta dos modelos de referencia genricos y completos, a partir de los cuales se puede obtener la arquitectura de servicios y plataformas de software requeridas por una organizacin especfica. El mtodo ADM utiliza estos modelos genricos para configurar la Arquitectura Tecnolgica de una empresa, en el caso de las arquitecturas de datos y de negocio se pueden utilizar otros modelos de negocio existentes y la metodologa los permite. El Modelo de Referencia Tcnico (TRM), presenta un conjunto de plataformas de servicios genricos y funciones que cubren de una forma muy completa las arquitecturas TI; as como una base de informacin completa de estndares abiertos y especificaciones (SIB Standard Information Base) para definir servicios y componentes interoperables y portables.

 El Modelo de Referencia de Infraestructura Integrada de Informacin (III-RM), est basado en el modelo TRM y es til para disear arquitecturas orientadas a negocios electrnicos .

La arquitectura empresarial para una organizacin debe ser el resultado del trabajo de diseo de la arquitectura TI utilizando el mtodo ADM, refleje sus requerimientos especficos, contenga los modelos de procesos, datos, aplicaciones y reglas de negocio de la organizacin, lleve a la implantacin de las TI adecuadas, de criterios apropiados para seleccionar y evaluar los productos, servicios y soluciones, y brinde una arquitectura flexible para el crecimiento y nuevas necesidades.