INSTITUTO POLITECNICO NACIONAL UNIDAD PROFESIONAL INTERDISCIPLINARIA DE INGENIERIA Y CIENCIAS SOCIALES Y ADMINISTRATIVAS EQUIPO: 8 INTEGRANTES: Chávez Sánchez Omar Christian Jiménez Pedroza Oscar López Soriano Karina Elizabeth Mejía Pérez Negrón Gabriela Nicolás Gastaldi Nallely Guadalupe

 En este capítulo se describe la parte Arquitectura de datos de la Fase C Objetivos El objetivo es definir los principales tipos y fuentes de datos necesarios para apoyar a la empresa, de una manera que es:  Comprensible por los interesados  Completa y consistente  Estable Es importante tener en cuenta que este esfuerzo no se refiere a diseño de base de datos. El objetivo es definir las entidades de datos relevantes para la empresa, no para diseñar sistemas de almacenamiento lógicos o físicos. (Sin embargo, los vínculos a los archivos y bases de datos existentes pueden desarrollarse, y puede demostrar importantes áreas de mejora).

Cuando una empresa ha optado por realizar gran escala transformación arquitectónica, es importante para entender y abordar los problemas de gestión de datos. Un enfoque estructurado y global de la gestión de datos permite el uso eficaz de los datos para sacar provecho de sus ventajas competitivas. Las consideraciones incluyen: › Una definición clara de los componentes de aplicación en el paisaje será el sistema de registro o de referencia para los datos maestros de la empresa › ¿Habrá un estándar en toda la empresa que todos los componentes de la aplicación, incluyendo los paquetes de software, tienen que adoptar (en los principales paquetes pueden ser preceptivo sobre los modelos de datos y no puede ser flexible)? › Claramente a entender cómo las entidades de datos son utilizados por las funciones de negocio, procesos y servicios

 Entender claramente cómo y cuando las entidades de datos empresariales son creados, almacenados, transportados, e informados  ¿Cuál es el nivel y la complejidad de las transformaciones de datos requeridas para apoyar las necesidades de intercambio de información entre las aplicaciones?  ¿Cuál será la necesidad de software de apoyo a la integración de datos con el introducir clientes y proveedores (por ejemplo, el uso de herramientas de ETL durante la migración de datos, herramientas de perfiles de datos para evaluar la calidad de los datos, etc.) de los premios?

 Cuando se sustituye una aplicación existente, habrá una necesidad crítica para migrar datos (master, transaccionales y de referencia) para la nueva aplicación. La arquitectura de datos debe identificar las necesidades de migración de datos y también proporcionar indicadores como el nivel de transformación y limpieza que se requiere para presentar los datos en un formato que cumpla con los requisitos y limitaciones de la aplicación de destino. El objetivo es que la aplicación de destino tiene datos de calidad cuando se llena. Otra consideración clave es asegurarse de que una definición común de datos en toda la empresa se ​​ ha establecido para apoyar la formación transformación.

 Consideraciones de gobernabilidad de datos asegurarse de que la empresa tiene las dimensiones necesarias en el lugar para permitir la transformación, de la siguiente manera: › Estructura: Esta dimensión se refiere a si la empresa tiene la necesaria estructura organizativa y los organismos de normalización para la gestión de los aspectos de entidad de datos de la transformación. › Sistema de Gestión: Aquí las empresas deben tener el sistema de gestión necesaria y programas de datos relacionados con la gestión de los aspectos de la gobernanza de las entidades de datos a lo largo de su ciclo de vida. › Gente: Esta dimensión aborda cuáles son las habilidades y roles de la empresa los datos relacionados requiere para la formación transformación. Si la empresa carece de tales recursos y capacidades, la empresa debe tener en cuenta tanto la adquisición de las habilidades o entrenamiento existentes recursos internos para satisfacer las necesidades a través de un programa de aprendizaje bien definidos críticos.

Como parte de esta fase, el equipo de arquitectura tendrá que considerar qué recursos de Arquitectura de datos relevantes están disponibles en el almacén de Arquitectura de la organización, en particular, los modelos de datos genéricos relacionados con la industria de la organización'' verticales '"sector. Por ejemplo: › ARTS ha definido un modelo de datos para la industria al por menor. › Energistics ha definido un modelo de datos para la industria petrotécnicos.

ENTRADAS ARQUITECTÓNICAS  Modelo Organizacional para Arquitectura de Empresa incluyendo:  Alcance de las organizaciones de afectados  Roles y responsabilidades de equipo de arquitectura  Restricciones en la arquitectura trabajo  Necesidades presupuestarias  La estrategia de apoyo

ADAPTANDO MARCO DE ARQUITECTURA INCLUYENDO: - Método de arquitectura adaptada - Contenido de la arquitectura adaptada (entregables y artefactos) -Herramientas de configurar e implementar principios -Datos Declaración de Arquitectura de Trabajo ARQUITECTURA REPOSITORIO INCLUYENDO: - Bloques de construcción reutilizables (en particular, las definiciones de los datos actuales) - Modelos de referencia disponibles al público - Modelos de referencia específicos de la organización - Normas de la Organización

PROYECTO DE ARQUITECTURA DEFINICIÓN DE DOCUMENTO INCLUYENDO: Línea de Base Arquitectura negocios, si procede - Objetivo Arquitectura negocios - Arquitectura de datos de línea de base - Arquitectura de datos de destino - Arquitectura de aplicaciones de línea de base - Objetivo Arquitectura Aplicación - Arquitectura de Tecnología de línea de base - Arquitectura Tecnología Target

PROYECTO DE ARQUITECTURA DE LA ESPECIFICACIÓN DE REQUISITOS INCLUYENDO: -Los resultados de análisis de lagunas (de Arquitectura Empresarial) - Los requisitos técnicos pertinentes que se aplicarán a esta fase

LOS PASOS EN LA FASE C SON LOS SIGUIENTES: -Algunos modelos de referencia, puntos de vista y herramientas -Desarrollo de Base de Datos Arquitectura Descripción -Desarrollar Arquitectura de Datos Descripción -Realizar análisis de brecha -Definir los componentes de la hoja de ruta

 Resolver los impactos en la Arquitectura del Paisaje ( véase la sección )  Conducta para mal interesados ​​ revisión (ver sección )  Finalizar la arquitectura de datos ( véase la sección )  Crear Arquitectura definición de documento ( véase la sección )

 Revisar y validar (o generar, si es necesario ) el conjunto de principios de datos. Normalmente, éstas formarán parte de un conjunto global de principios de arquitectura. Lineamientos para elaborar y aplicar los principios, y una muestra de un conjunto de principios de datos, figuran en la Parte III, Capítulo 23.  Seleccionar los recursos Arquitectura de datos relevantes (modelos de referencia, patrones, etc) sobre la base de los impulsores del negocio, las partes interesadas, las preocupaciones y la arquitectura de negocios.

 Seleccione los puntos de vista de arquitectura de datos relevantes (por ejemplo, las partes interesadas de los datos - los organismos reguladores, usuarios, grupos electrógenos, temas, auditores, etc, diferentes dimensiones de tiempo - en tiempo real, el período de notificación, eventos, etc, lugares, los procesos de negocio ), es decir, las que permitirán al arquitecto para demostrar cómo se están abordando las preocupaciones de los interesados ​​ en la arquitectura de datos.

 Identificar las herramientas y técnicas (incluyendo formas) que se utilizarán para la captura de datos, el modelado, y el análisis, en asociación con los puntos de vista seleccionados apropiados. Dependiendo del grado de sofisticación garantizada, estos pueden comprender documentos simples u hojas de cálculo, o más sofisticadas herramientas de modelado y técnicas tales como modelos de gestión de datos, modelos de datos, etc Ejemplos de técnicas de modelado de datos son:  Diagrama entidad-relación  Los diagramas de clases  Modelos de conducta objeto

 Para cada punto de vista, seleccione los modelos necesarios para apoyar el punto de vista específico necesario, utilizando la herramienta o método seleccionado.  Ejemplos de modelos de datos incluyen: › El Departamento de Defensa marco de arquitectura (DoDAF) modelo de datos lógicos › Modelo de datos ARTS para la industria al por menor

 Asegúrese de que todas las preocupaciones de los interesados ​​ están cubiertos. Si no lo son, crear nuevos modelos para abordar las preocupaciones no están cubiertos, o aumentar los modelos existentes.  El proceso recomendado para el desarrollo de una arquitectura de datos es el siguiente: › Recoge los modelos de datos relacionados de Arquitectura de negocios existentes y los materiales de la arquitectura de aplicaciones. › Racionalizar los requisitos de datos y alinear con ningún catálogo de datos empresariales existentes y modelos, lo que permite el desarrollo de un inventario de datos y la relación entre entidades. › Actualizar y desarrollar matrices a través de la arquitectura, relacionando los datos de servicio de negocio, la función empresarial, los derechos de acceso, y la aplicación › Elaborar visitas arquitectura de datos mediante el examen de cómo los datos se crean, distribuyen, migran, protegen y archivan.

 Inventario de datos de la organización se captura como un catálogo en el Repositorio de Arquitectura. Los catálogos son de naturaleza jerárquica y capturan una descomposición de una entidad metamodelo y también a través de descomposiciones entidades relacionados con el modelo (por ejemplo, datos lógicos componente, el componente físico de datos, entidad de datos).  Catálogos constituyen la materia prima para la elaboración de matrices y diagramas, y también actúan como un recurso clave para la gestión de la cartera de negocios y la capacidad de TI.  Durante la fase de arquitectura de negocio, un diagrama de Servicio / Información Empresarial fue creado mostrando las entidades de datos clave requeridos por los principales servicios de oficina. Este es un requisito previo para el éxito de las actividades de arquitectura de datos.

 Uso de la trazabilidad de la aplicación de la función empresarial de entidad de datos inherente al marco de contenido, es posible crear un inventor io de los datos necesarios para estar en el lugar para apoyar la visión de la arquitectura.  Una vez que los requisitos de datos se consolidan en un solo lugar, es posible refinar el inventor io datos para lograr la coherencia semántica y eliminar lagunas y superposiciones.  Los siguientes catálogos deben ser considerados para el desarrollo dentro de una arquitectura de datos: › datos de entidad / catalogo componente de datos.  La estructura de catálogos se basa en los atributos de las entidades metamodelo, tal como se define en la Parte IV, Capítulo 34.

 Matrices muestran las relaciones básicas entre las entidades del modelo relacionado.  Las matrices son la materia prima para la elaboración de diagramas y también actúan como un recurso clave para la evaluación del impacto.  En esta etapa, una entidad a la matriz de los sistemas de aplicación podría ser producido para validar este mapeo. Cómo se crean datos, gestionan, transforman y pasan a otras aplicaciones o utilizada por otras aplicaciones, a partir de ahora empieza a ser entendido. Lagunas evidentes, tales como las entidades que nunca parecen ser creadas por una aplicación o de datos creada, pero nunca utilizado, deben tenerse en cuenta para el análisis de las deficiencias más tarde.

 Una vez que las entidades de datos se han refinado, un diagrama de las relaciones entre las entidades y sus atributos puede ser producido.

 El nivel de detalle el modelo debe evaluarse cuidadosamente.  Algunos modelos de datos físicos del sistema existirán a un nivel muy detallado, mientras que otros sólo tienen las entidades centrales modeladas.

 No todos los modelos de datos se han mantenido al día sino que las aplicaciones se modificaron y extendieron en el tiempo.  Es importante lograr un equilibrio en el nivel de detalle (por ejemplo, la reproducción del sistema de esquemas de datos físicos detallados existentes o la presentación de mapas de procesos de alto nivel y los requisitos de datos).

■ Diagrama de clases ■ Diagrama de Divulgación de Datos ■ Diagrama del ciclo de vida de datos ■ Diagrama de seguridad de datos ■ Diagrama de migración de datos ■ Diagrama de jerarquía de las clases

Requisitos funcionales Requisitos no funcionales Supuestos Restricciones Principios de dominio específico arquitectura de datos Políticas Normas Directrices Especificaciones

 El alcance y el nivel de detalle que se define dependerán de la medida en que son susceptibles de ser transportados en la arquitectura de datos de destino y de si existen descripciones arquitectónicas.  En la medida de lo posible, el tipo de arquitectura bloques de construcción de datos pertinentes se hará basándose en un repositorio de arquitectura.

 El alcance y nivel de detalle que puede definir dependerá de la pertinencia de los elementos de datos a la consecución de la arquitectura destino, y si existe la descripción de la arquitectura.  En la medida de lo posible, el tipo de arquitectura bloques de construcción de datos pertinentes debe ser basándose en el repositorios de arquitectura.

 Crear matriz de separación  Identificar los bloques de construcción para ser prorrogados, clasificar, ya sea modificado o sin cambios  Identificar los bloques de construcción eliminados  Identificar nuevos bloques de construcción  Identificar y clasificar las lagunas como las que debe desarrollarse y los que deben ser adquiridos

 Una vez que la Arquitectura de Datos ha finalizado, es necesario entender los impactos o implicaciones más amplias.  En esta etapa, otros artefactos de arquitectura en la arquitectura del paisaje deben ser examinados para identificar:  ■ ¿Esta arquitectura de datos crea un impacto en las arquitecturas preexistentes?  ■ ¿Se han hecho los cambios recientes que afectan a la arquitectura de datos?  ■ ¿Existen oportunidades para aprovechar el trabajo de esta arquitectura de datos en otras áreas de la organización?  ■ ¿Esta Arquitectura de datos tiene impacto otros proyectos (incluyendo los previstos, así como los actualmente en curso)?  ■ ¿Esta arquitectura de datos se ve afectada por otros proyectos (incluyendo los previstos, así como los actualmente en curso)?

 Compruebe la motivación original para el proyecto de arquitectura y de la Declaración de Arquitectura de Trabajo contra la arquitectura de datos propuesta. Llevar a cabo un análisis de impacto para identificar las áreas donde las arquitecturas de negocio y la aplicación (por ejemplo, las prácticas comerciales) que tenga que cambiar para hacer frente a los cambios en la arquitectura de datos (por ejemplo, los cambios a para ms o procedimientos, sistemas de aplicación, o los sistemas de bases de datos).  Si el impacto es significativo, esto puede justificar el negocio y arquitecturas de aplicaciones se revisa  Identifique las áreas en las que la arquitectura de la aplicación (si se han generado en este punto) que tenga que cambiar para hacer frente a los cambios en la arquitectura de datos (o para identificar las limitaciones en la arquitectura de la aplicación punto de ser diseñado).  Si el impacto es significativo, puede ser apropiado para caer en una breve versión de la arquitectura de la aplicación en este punto.  Identificar las restricciones sobre la arquitectura de la tecnología a punto de ser diseñado, el perfeccionamiento de la arquitectura de datos prevista si es necesario.

  ■ Seleccionar las normas de cada uno de los bloques de construcción, reutilizando la mayor cantidad posible de los modelos de referencia seleccionados desde el repositorio Arquitectura   ■ documentar completamente cada bloque de construcción   ■ Conducir la última comprobación cruzada de la arquitectura general de los requerimientos del negocio, justificación documento para la construcción de las decisiones del bloque en el documento de la arquitectura   ■ Documente el informe final de trazabilidad de requisitos   ■ Documente el la asignación definitiva de la arquitectura en el Repositorio de Arquitectura, a partir de los componentes básicos seleccionados, identificar aquellos que pueden ser reutilizados, y publicar a través del Repositorio de Arquitectura   ■ Finalice todos los productos de trabajo, tales como análisis de las deficiencias

 Documente la justificación para la construcción de las decisiones del bloque de la arquitectura de Definición de documento.  Prepare secciones de arquitectura de datos de la arquitecturad de Definición de documento, que comprende una parte o todos los siguientes:  ■ modelo de datos de negocios  ■ modelo de datos lógicos  ■ Modelo de proceso de gestión de datos  ■ Entidad / Empresa Data Matrix Función  ■ requisitos de interoperabilidad de datos (por ejemplo, el esquema XML, las políticas de seguridad)  ■ Si es necesario, utilizar los informes y / o gráficos generados por las herramientas de modelado para demostrar vistas principales de la arquitectura, la ruta del documento para su examen por los interesados, e incorporar retroalimentación

 Los resultados de la Fase C (arquitectura de datos) incluyen:  ■ Versiones refinado y actualizado de la arquitecturad entregables fase Visión, en su caso:  - Declaración de Arquitectura Trabajo  - Validar principios de datos  ■ Proyecto de Arquitectura de definición de documento  ■ Proyecto de Arquitectura Especificación de Requisitos