Framework para el desarrollo de arquitecturas de información en un contexto de arquitectura empresarial

Texto completo

(1)FRAMEWORK PARA EL DESARROLLO DE ARQUITECTURAS DE INFORMACION EN UN CONTEXTO DE ARQUITECTURA EMPRESARIAL. NIXON ALONSO DUARTE ACOSTA. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERIA, DEPARTAMENTO DE INGENIERIA DE SISTEMAS Y COMPUTACION MAESTRIA EN INGENIERIA DE SISTEMAS Y COMPUTACION BOGOTA, DC JULIO 2012.

(2) FRAMEWORK PARA EL DESARROLLO DE ARQUITECTURAS DE INFORMACION EN UN CONTEXTO DE ARQUITECTURA EMPRESARIAL. NIXON ALONSO DUARTE ACOSTA. Documento de tesis presentado como requisito parcial para el grado de: MAESTRIA EN INGENIERIA DE SISTEMAS Y COMPUTACION. Director: Profesor Asociado, PhD. José Abasolo. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERIA, DEPARTAMENTO DE INGENIERIA DE SISTEMAS Y COMPUTACION MAESTRIA EN INGENIERIA DE SISTEMAS Y COMPUTACION BOGOTA, DC JULIO 2012.

(3) AGRADECIMIENTOS. A Dios y María santísima que me permitieron realizar este estudio de maestría. A mi esposa Yenny, mis hijos Verónica y Samuel que son mi inspiración, y por brindarme su apoyo, tolerancia y comprensión durante largas horas de estudio. Al PhD. José Abasolo, por su confianza y asesoría durante el desarrollo de este interesante e importante tema..

(4) TABLA DE CONTENIDO. 1.. INTRODUCCION ..................................................................................... 12. 1.1. Justificación ........................................................................................... 14. 1.2. Objetivo general ..................................................................................... 15. 1.3. Objetivos específicos ............................................................................ 15. 1.4. Alcance ................................................................................................... 16. 1.5. Estructura del documento..................................................................... 17. 2.. ESTADO DEL ARTE ............................................................................... 19. 2.1. Enfoques de arquitectura empresarial ................................................. 19. 2.1.1. Zachman .......................................................................................... 20. 2.1.1.1. Las perspectivas ......................................................................... 21. 2.1.1.2. Las dimensiones ......................................................................... 22. 2.1.1.3. Zachman y la arquitectura de datos ............................................ 23. 2.1.2. Framework de arquitectura empresarial federal ........................... 24. 2.1.3. TOGAF (The Open Group Architecture Framework) ..................... 30. 2.1.3.1. El Ciclo ADM............................................................................... 31. 2.1.3.2. Alcance ....................................................................................... 36. 2.1.3.3. División de Arquitecturas ............................................................ 39. 2.1.3.4. Principios de Datos ..................................................................... 40. 2.1.3.5. TOGAF y La Arquitectura de Datos ............................................ 41. 2.1.4. Arquitectura de información empresarial según [1] ..................... 44. 2.1.4.1. Principios de arquitectura de información ................................... 45. 2.1.4.2. Dominios de datos ...................................................................... 45.

(5) 2.1.4.3 2.1.5 2.2 2.2.1. AIE y la arquitectura de datos ..................................................... 60 Análisis ............................................................................................ 61 GOBIERNO DE DATOS .......................................................................... 63 Diseñando gobierno de datos por Vijay Khatri y Carol V. Brown 63. 2.2.1.1. Principios de datos ..................................................................... 65. 2.2.1.2. Calidad de los datos ................................................................... 65. 2.2.1.3. Metadatos ................................................................................... 65. 2.2.1.4. Acceso a Datos ........................................................................... 66. 2.2.1.5. Ciclo de Vida de los Datos .......................................................... 66. 2.2.2. El proceso unificado de gobierno de datos de IBM ...................... 66. 2.2.3. Gobierno de datos: ¿Qué funciona y que no? por Rob Karel ...... 72. 2.2.3.1. Catalizadores de Gobierno de Datos .......................................... 73. 2.2.3.2. Framework de gobierno de datos................................................ 73. 2.2.3.3. Inhibidores de la Adopción de un Gobierno de Datos ................. 73. 2.2.3.4. Preparación del gobierno de datos ............................................. 74. 2.2.3.5. Diseñe el gobierno basado en la cultura de la empresa .............. 74. 2.2.4 3.. Análisis ............................................................................................ 76 FRAMEWORK DE ARQUITECTURA DE INFORMACION EN UN. CONTEXTO DE ARQUITECTURA EMPRESARIAL (FAI) ................................... 78 3.1. Elementos estructurales del framework .............................................. 80. 3.1.1. Repositorio de recursos ................................................................. 81. 3.1.2. Metodologías ................................................................................... 83. 3.1.3. Repositorio de arquitectura ............................................................ 83. 3.2. Metodologías ......................................................................................... 84.

(6) 3.2.1. Guía Metodológica para el proyecto inicial ................................... 84. 3.2.1.1. Elementos estructurales ............................................................. 85. 3.2.1.2. Desarrollo metodológico ............................................................. 86. 3.2.2. Guía metodológica para gobierno de datos ................................ 127. 3.2.2.1. Preparación .............................................................................. 129. 3.2.2.2. Diseño ...................................................................................... 129. 3.2.2.3. Evaluación de Madurez ............................................................ 130. 3.2.2.4. Mapa de proyectos ................................................................... 131. 3.2.2.5. Modelo Organizacional ............................................................. 131. 3.2.2.6. Definir Métricas ......................................................................... 132. 3.2.2.7. Gobierno de datos maestros ..................................................... 133. 3.2.2.8. Gobierno de análisis ................................................................. 133. 3.2.2.9. Gestionar la seguridad y privacidad .......................................... 133. 3.2.2.10. Medir Resultados ...................................................................... 134. 4. APLICACIÓN DE LA GUIA METODOLOGICA PARA EL PROYECTO. INICIAL DE ARQUITECTURA DE INFORMACION EN LA ADMINISTRADORA COLOMBIANA DE PENSIONES COLPENSIONES .......................................... 135 4.1. ETAPA 1: PREPARACION ................................................................... 136. 4.1.1. Conociendo la organización - COLPENSIONES.......................... 136. 4.1.2. Grupos de apoyo ........................................................................... 146. 4.1.3. Modelos de referencia .................................................................. 147. 4.1.4. Alcance de la arquitectura de información.................................. 147. 4.1.5. Herramientas y técnicas ............................................................... 148. 4.2 4.2.1. ESTADO ACTUAL DE ARQUITECTURA DE INFORMACION ............. 148 Entrevistas ..................................................................................... 149.

(7) 4.2.2. Entidades de negocio ................................................................... 149. 4.2.3. Modelo conceptual ........................................................................ 156. 4.2.4. Análisis del estado actual de la AI ............................................... 157. 4.2.4.1. Análisis de fuentes de datos ..................................................... 157. 4.2.4.2. Gobierno de datos .................................................................... 174. 4.2.4.3. Análisis de la Información ......................................................... 176. 4.3 4.3.1 4.4. ESTADO DESEADO DE ARQUITECTURA DE INFORMACION .......... 240 Blueprint de arquitectura de información.................................... 241 MAPA DE PROYECTOS ....................................................................... 256. 4.4.1. Definición de proyectos ................................................................ 256. 4.4.2. Priorización de proyectos ............................................................. 258. 5. CONCLUSIONES Y TRABAJO FUTURO ............................................. 260. 5.1. CONCLUSIONES DEL TRABAJO REALIZADO .................................. 260. 5.2. TRABAJO FUTURO ............................................................................. 262. 6. BIBLIOGRAFIA ..................................................................................... 263. ANEXOS ............................................................................................................ 267.

(8) TABLA DE PLANTILLAS. Plantilla 1. Procesos vs Entidades ...................................................................... 104 Plantilla 2. Descripción de una entidad de negocio [23] ...................................... 107 Plantilla 3. Inventario de Fuentes de Datos [23] .................................................. 109 Plantilla 4.Entidades de Negocio vs Fuentes de Datos [23] ................................ 110 Plantilla 5. Estado actual de gobierno de datos .................................................. 112 Plantilla 6. Matriz de consolidación de brecha, soluciones dependencias [16] ... 124 Plantilla 7. Definición incremental de arquitectura [16] ....................................... 125 Plantilla 8. Descripción de hallazgo [23] .............................................................. 275 Plantilla 9. Indicadores de calidad de datos [23] ................................................. 275 Plantilla 10. Mediciones de los indicadores de calidad [23] ................................. 276 Plantilla 11. Calculo de Indicadores [23] ............................................................. 277 Plantilla 12. Diagnóstico de calidad [23] .............................................................. 277.

(9) TABLA DE FIGURAS Figura 1. Marco de Referencia de Zachman ......................................................... 21 Figura 2. DRM Áreas de estandarización [35] ....................................................... 27 Figura 3. Contexto de los datos [34] ..................................................................... 28 Figura 4. Descripción de los datos [34] ................................................................. 28 Figura 5. Compartir Datos [34] .............................................................................. 29 Figura 6. Marco de implementación de DRM ....................................................... 29 Figura 7. Arquitectura Empresarial según TOGAF [14] ......................................... 30 Figura 8. El ciclo ADM [16] ................................................................................... 32 Figura 9. Desarrollo incremental de la arquitectura [16] ........................................ 38 Figura 10. Dominios de datos [1] .......................................................................... 46 Figura 11. Modelo de madurez de metadatos [1] .................................................. 47 Figura 12. Representación de la misma persona en diferentes contextos de aplicación [21] ....................................................................................................... 54 Figura 13. Sistema central de datos maestros [21] ............................................... 56 Figura 14. Sistema maestro principal [21] ............................................................. 57 Figura 15. Repositorio principal ............................................................................ 58 Figura 16. Visión general del proceso unificado de gobierno de datos de IBM ..... 67 Figura 17. Roles y responsabilidades [22] ........................................................... 73 Figura 18. Dimensiones de AE y sus relaciones [27] ............................................ 78 Figura 19. Elementos estructurales del framework de AI ...................................... 80 Figura 20. Repositorio de recursos de AI .............................................................. 82 Figura 21. Metodologías para Proyectos de AI ..................................................... 83 Figura 22. Elementos Estructurales Metodología Proyecto Inicial ......................... 85 Figura 23. Etapa de preparación de la metodología del proyecto inicial................ 86 Figura 24. Actividades en la etapa de preparación ............................................... 87 Figura 25. Grupos de trabajo ................................................................................ 88 Figura 26. Modelo para definir el alcance de la AI ................................................ 92.

(10) Figura 27. Dominios de Datos Empresariales ....................................................... 94 Figura 28. Gobierno de Datos Modelo de Referencia ........................................... 95 Figura 29. Etapa de Estado Actual de la metodología del proyecto inicial ............ 99 Figura 30. Actividades de la etapa de Estado Actual .......................................... 100 Figura 31 Modelo Conceptual nivel 0 [23] ........................................................... 105 Figura 32. Actividades del Análisis de Estado Actual de AI................................. 113 Figura 33. Método para análisis de calidad de datos .......................................... 115 Figura 34. Actividades en la etapa de Estado Deseado de AI ............................. 120 Figura 35. Blueprint de Arquitectura de Datos .................................................... 121 Figura 36. Etapa de Mapa de Proyectos en la metodología de proyecto inicial... 123 Figura 37. Actividades de la etapa de Mapa de Proyectos................................. 123 Figura 38. Técnica de evaluación del valor de negocio [16] ................................ 126 Figura 39. Guía Metodológica para Diseño de un Gobierno de Datos ................ 128 Figura 40. Blueprint de AI para Colpensiones .................................................... 242 Figura 41. Estado deseado de los Datos Maestros ............................................. 247 Figura 42. Grafica de evaluación del Riesgo vs Beneficio .................................. 259.

(11) LISTA DE TABLAS. Tabla 1. Evaluación de criterios por cada uno de los enfoques de AE .................. 62 Tabla 2. Dominios de decisión para gobierno de datos [18] .................................. 64 Tabla 3. Framework para los dominios de decisión de datos ................................ 64 Tabla 4.Evaluación de criterios por cada uno de las propuestas de gobierno de datos..................................................................................................................... 77 Tabla 5. Inventario inicial de fuentes de datos .................................................... 165 Tabla 6. Lista de las 16 fuentes de datos más importantes ................................ 167 Tabla 7. Otras fuentes de datos .......................................................................... 168 Tabla 8. Entidades de Negocio vs Fuentes de Datos .......................................... 170 Tabla 9. Matriz de consolidación de brecha, soluciones y dependencia. ............ 257 Tabla 10. Valores de evaluación del Riesgo vs Beneficio ................................... 259.

(12) 1. INTRODUCCION En un contexto empresarial, la Arquitectura de Información debe organizar, gestionar y gobernar la totalidad de los datos. Pero esto es un tema bastante complejo que se plantea en este trabajo desde dos perspectivas: la primera tiene que ver con la variedad existente de recursos que se deben considerar en un proyecto de Arquitectura de Información (en adelante AI). La segunda perspectiva aborda la complejidad que genera el organizar, gestionar y gobernar grandes volúmenes de información con su diversidad en usos y también su variedad de formatos en los que esta se puede encontrar almacenada. Algunos de los recursos con los que se cuenta actualmente para el desarrollo de una AI abordan temas como técnicas de integración de datos, enfoques arquitecturales para gestión de datos maestros (MDM por sus siglas en ingles), propuestas para gobierno de datos, marcos de arquitectura empresarial, aspectos de seguridad, calidad de datos, fuentes de datos, principios de datos, herramientas tecnológicas, técnicas de modelado de datos, dimensiones de calidad de datos, entre otros. Los marcos de Arquitectura Empresarial (en adelante AE), consideran algunos de los recursos mencionados dentro de sus propuestas (cada una diferente entre sí), desde un enfoque genérico que no describe cómo se deben orquestar e implementar estos recursos de forma organizada. La variedad de usos y el volumen de información en los contextos empresariales han crecido considerablemente en los últimos años. Esto porque las empresas actuales trabajan en línea a nivel mundial y acumulan enormes volúmenes de información principalmente sobre sus productos, servicios, sus clientes y sus comportamientos. Adicionalmente, las empresas suman a su entorno información no tradicional proveniente de redes sociales, multimedia, fuentes de datos. 12.

(13) heterogéneas y muchas de estas fuentes son desestructuradas. En consecuencia la complejidad de la información es bastante significativa y las empresas deben buscar mecanismos que les permitan organizar, gestionar y gobernar la información como un activo más de la empresa y que pueda ser utilizada como un insumo que apalanque las estrategias de negocio. En este trabajo se presenta un Framework para el Desarrollo de Arquitecturas de Información en un Contexto de Arquitectura Empresarial (en adelante FAI), con el fin de mitigar las problemáticas antes mencionadas. También con el ánimo de disminuir el vacío existente en los frameworks de AE para el tema de AI, en lo que respecta a guías metodológicas y modelos de referencia que faciliten las labores de organizar, gestionar y gobernar la información. El FAI toma elementos principalmente de varios Frameworks de Arquitectura Empresarial y de propuestas de gobierno de datos, para extenderlos y/o adaptarlos a las necesidades requeridas en proyectos de AI. El FAI, propone conceptualmente tres elementos estructurales que son el repositorio de recursos, metodologías y un repositorio de arquitectura de información. El repositorio de recursos, en este trabajo se centra principalmente en la propuesta de modelos de referencia para gobierno de datos, dominios de datos y alcance de la AI. También se describe un método para la calidad de los datos y se propone una serie de plantillas como un medio para documentar cada una de las actividades de acuerdo a la guía metodológica. El modelo de referencia para gobierno de datos propone los temas principales que se deben considerar en el desarrollo de AI. Para dominio de datos se propone un enfoque segmentado, donde para disminuir la complejidad de uso de la información se propone dividir los datos empresariales en los 5 dominios de datos propuesto en [1]. Para la definición del alcance de la AI, también se propone un enfoque segmentado y centrado principalmente en los datos operacionales y analíticos. Se toma como. 13.

(14) base específicamente los datos operacionales y analíticos, porque se considera que los metadatos y los datos maestros, aunque se trabajan de forma independiente, intervienen directamente y son considerados de forma implícita. En las metodologías se proponen tres guías metodológicas para el desarrollo de AI, a saber: guía metodológica para el proyecto inicial, para proyectos particulares y para el gobierno de datos. En la guía metodológica para el proyecto inicial se proponen cuatro etapas, empezando por la etapa de preparación donde se debe entender el contexto donde se desarrollara la AI, luego se debe entender el estado actual de los datos, posteriormente se deben entender las necesidades del negocio y proponer el estado deseado de los datos, y por último se deben identificar, priorizar y proponer la ruta de ejecución de los proyectos que ayudaran a superar la brecha entre el estado actual y el estado deseado. Este trabajo se enfoca en los datos operacionales, porque fue donde se identificaron los principales vacíos y por ende problemáticas al momento del desarrollo de una AI. Los datos analíticos no se consideran en este trabajo, porque ya existe una metodología completa y bien detallada propuesta por Ralph Kimball que ya aborda este tema. Los proyectos de datos analíticos se pueden llevar a cabo independiente del estado de los datos operacionales aunque éstos sean un completo caos, pero la complejidad de las técnicas de integración es considerable. Pero, si los datos operacionales son organizados, gestionados y gobernados adecuadamente, el desarrollo de los proyectos de datos analíticos serán menos complejos y las técnicas de integración de datos serán relativamente sencillas.. 1.1 Justificación Las necesidades de hoy exigen a las empresas flexibilidad de adaptación, operación eficiente para disminuir sus costos, heterogeneidad, operación orientada a los clientes, información precisa y oportuna que le permita hacer. 14.

(15) monitoreo constante, poder de prevención o reacción en tiempo real, manejo de indicadores de negocio y evolución en el tiempo. Pero actualmente las empresas sufren operacional y financieramente por tener silos de negocios soportados por componentes tecnológicos aislados, generando un alto costo de operación, integración y estandarización. En consecuencia difícilmente se puede contar con información actualizada y consolidada que muestre la operación diaria del negocio. Estos problemas, son generados porque el negocio e IT no tienen o no comparten la misma visión del negocio y no trabajan en la misma dirección. Con la propuesta del FAI se busca resolver los problemas operacionales que presentan. actualmente. las. empresas,. por. no. organizar. y. gestionar. adecuadamente la información de forma tal que sea un activo más que apoye adecuadamente las estrategias de negocio.. 1.2 Objetivo general Desarrollar un framework para el desarrollo de arquitecturas de información en un contexto de arquitectura empresarial.. 1.3 Objetivos específicos Para responder al objetivo general del proyecto se deben cumplir los siguientes objetivos específicos: . Identificar fortalezas y debilidades desde el punto de vista de la AI de los frameworks de arquitectura empresarial más utilizados empresarialmente.. . Identificar fortalezas y debilidades de las propuestas de gobierno de datos más representativas y utilizadas por las organizaciones.. . Hacer una propuesta para el framework de arquitectura de información que integre las fortalezas de los frameworks de arquitectura empresarial.. 15.

(16) . Hacer una propuesta de guías metodológicas que faciliten el desarrollo de arquitecturas de información en un contexto de arquitectura empresarial en su fase inicial.. . Hacer una propuesta de modelos de referencia y plantillas que apoyen el desarrollo de las guías metodológicas.. 1.4 Alcance Este trabajo de investigación propone un framework para el desarrollo de arquitecturas de información en un contexto de arquitectura empresarial. El framework consta estructuralmente de 3 componentes conceptuales, donde el primer componente es el repositorio de recursos de AI, el segundo las metodologías y el tercero el repositorio de arquitectura. En el repositorio de recursos de AI, para el alcance de este trabajo se proponen modelos de referencia para dominios de datos, gobierno de datos, alcance de la AI y una serie de plantillas como herramientas para organizar la información capturada durante el desarrollo de la AI. Se proponen tres guías metodológicas, una para el proyecto inicial, otra para proyectos particulares y una tercera para el gobierno de datos. Como parte de este trabajo solo se propone, desarrolla y valida con un caso de estudio la guía metodológica para el proyecto inicial de AI. La guía metodológica para proyectos particulares no se encuentra dentro del alcance y la guía para gobierno de datos solo se realiza la propuesta. La aplicación se hará en la Administradora Colombiana de Pensiones COLPENSIONES, la cual es una empresa del sector público, donde se aplicara la guía metodológica para el proyecto inicial de la AI. La información utilizada para ilustrar la aplicación de la propuesta, fue tomada del proyecto desarrollado por el. 16.

(17) CIFI 1 de la Universidad de los Andes, para la Administradora Colombiana de Pensiones COLPENSIONES. En este proyecto participo un grupo de profesionales que crearon una serie de documentos, pero principalmente se utiliza aquí la información de los documentos [23] y [31]. El documento [31] corresponde a un estudio previo de COLPENSIONES realizado por el Grupo de la Protección Social. El repositorio de arquitectura, donde se deben organizar y gestionar los artefactos generados durante el desarrollo de la AI, no se encuentra en el alcance de este trabajo.. 1.5 Estructura del documento Los siguientes capítulos de este documento se estructuran como se describe a continuación: En el capítulo 2 se presenta el análisis del estado del arte que sustenta la creación del FAI. A través de este capítulo se presentan dos análisis: en el primer análisis se realiza una revisión de los framework de arquitectura empresarial y en el segundo análisis se lleva a cabo una revisión de varias propuestas en el tema de gobierno de datos. En el capítulo 3 se presenta el Framework de Arquitectura de Información en un contexto de Arquitectura Empresarial (FAI). En este capítulo se presentan los elementos estructurales del framework y se describen tres metodologías que son los componentes principales de este framework. La primera metodología trata del primer proyecto que se debe realizar en todo trabajo de AI, la segunda metodología trata los aspectos de los proyectos particulares que son el resultado del primer proyecto y la tercera metodología cubre el tema de gobierno de datos.. 1. Centro de Estudios e Investigación de la Facultad de Ingeniería. 17.

(18) En el capítulo 4 se presenta un caso de estudio donde se ilustra la aplica del FAI con información tomada del proyecto desarrollado por el CIFI de la Universidad de los Andes, para la Administradora Colombiana de Pensiones COLPENSIONES. En el capítulo 5 se presentan las conclusiones y se definen los trabajos futuros para continuar con el desarrollo del FAI en los aspectos que no fueron desarrollados completamente.. 18.

(19) 2. ESTADO DEL ARTE. El estado del arte se aborda desde dos perspectivas. La primera desde la Arquitectura Empresarial enfatizando en lo que ofrecen específicamente en el área de Arquitectura de Datos y la segunda desde el Gobierno de Datos. En la primera parte se estudian tres enfoques de Arquitectura Empresarial: TOGAF, Zachman y la propuesta descrita en [1]. También se realiza un análisis comparativo de estos tres enfoques. En la segunda parte se aborda el tema de Gobierno de Datos desde tres perspectivas: Diseñando gobierno de datos por Vijay Khatri y Carol V. Brown, el Proceso unificado de gobierno de datos de IBM y Gobierno de datos ¿Qué funciona y que no? por Rob Karel. También se realiza un análisis respectivo de las tres propuestas.. 2.1 Enfoques de arquitectura empresarial Desde que se publicó el primer artículo en 1987 por J.A. Zachman según [1] se han publicado o surgido varias metodologías, entre las más reconocidas se encuentran: . The Open Group Architectural Framework (TOGAF). . The Zachman Framework for Enterprise Architectures (Zachman). . The Federal Enterprise Architecture (FEA). . The Gartner Methodology (formerly Meta Framework). Para el estudio del estado del arte se tomaran como referencia las tres primeras propuestas y adicionalmente la propuesta descrita en [1]. Para el alcance de este. 19.

(20) trabajo solo se analizara la propuesta de cada uno de los enfoques, desde la perspectiva que cada uno propone para el tema de Arquitectura de Datos. Ninguna de estas propuestas metodológicas son realmente completas y cada una tiene una fortaleza diferente a las otras. Otro aspecto a destacar es que estas propuestas metodológicas son realmente vistas como frameworks de arquitectura con propuestas macros y no llegan al nivel de explicar metodológicamente con el nivel de detalle necesario de cómo desarrollar un proyecto de arquitectura de datos en un contexto de arquitectura empresarial. En la práctica una empresa necesitaría un complemento de cada una para llevar a cabo un proyecto de arquitectura de datos, además de la experiencia de los arquitectos empresariales y de datos. Por estas razones se tomaran las fortalezas de las cuatro propuestas seleccionadas y adicionalmente se extenderá con el objeto de proponer una metodología mejorada.. 2.1.1 Zachman Según la propia descripción de John Zachman este enfoque se considera una taxonomía y no una metodología ni un framework, donde su definición es: “Una estructura lógica para clasificar y organizar las representaciones descriptivas de una Empresa, las cuales son especialmente significativas tanto para la dirección y control de la organización como para el desarrollo de sus sistemas” [4]. Como puede observarse en la Figura 1, el marco de referencia es una matriz de 6 filas (la sexta fila es la empresa en operación) por 6 columnas, donde cada tipo de artefacto es caracterizado por una celda, la que a su vez es resultado del cruce de una fila y de una columna. Cada fila representa una perspectiva o vista de cierto rol participante en la empresa (ejecutivo, negocio, diseñador, constructor, programador y usuario), la cual es combinada con seis dimensiones expresadas. 20.

(21) en forma de interrogantes (¿Qué?, ¿Cómo?, ¿Dónde?, ¿Quién?, ¿Cuándo? y ¿Por qué?).. Figura 1. Marco de Referencia de Zachman. 2.1.1.1. 2. Las perspectivas. El Ejecutivo se ocupa del contexto de la empresa, de su entorno competitivo, de las fuerzas internas y externas que influyen en su competitividad, del posicionamiento de sus productos y servicios, que lo obligan a especificar sus alcances a largo plazo; esta perspectiva cubre los componentes del nivel 2. Tomado de http://www.zachman.com/. 21.

(22) estratégico. El Negocio se interesa en la operación de la empresa, para lo cual requiere del modelado de la empresa mediante modelos de procesos, de flujos de trabajo, de logística empresarial, de modelos semánticos y de planes de negocio que le permitan controlar la operación de la empresa; esta perspectiva se centra en el proceso de negocio, por lo que constituye en buena medida el nivel de procesos. El Diseñador o Arquitecto tiene que ver con la especificación de los planos conceptuales de los sistemas de información que se requieren para soportar la operación de los procesos. El Constructor o Ingeniero se encarga del ensamblado y fabricación de los diversos componentes de los sistemas de información de acuerdo con las restricciones de la tecnología utilizada. El Programador trabaja en la fabricación de los componentes de acuerdo con las especificaciones del constructor. Las perspectivas del diseñador, constructor y programador se ubican claramente en el nivel de sistemas de información [13].. 2.1.1.2. Las dimensiones. El Dato responde a la interrogante ¿Qué?, para la perspectiva de nivel ejecutivo se refiere a la lista de cosas importantes para el negocio como clientes, proveedores, productos, servicios, contratos, facturas, etc.; conforme se va descendiendo. a. las. perspectivas. inferiores. se. van. teniendo. diferentes. descripciones relacionadas con la visión particular de cada perspectiva: desde la gestión del negocio se ven las cosas como entidades representadas en un modelo conceptual que caracteriza el negocio, pero al diseñador le interesa un modelo lógico que pueda conducir a una base de datos para su almacenamiento correspondiente, lo que la visión del constructor transforma en un modelo físico como una tabla de base de datos, que para el programador será una entidad de almacenamiento como un archivo o un registro. La Función se ocupa de la pregunta ¿Cómo?, cubriendo desde la lista de procesos esenciales del negocio (perspectiva del planeador), su modelado correspondiente (dueño), hasta la. 22.

(23) especificación de los programas (programador) asociados a la funcionalidad de negocio. La Ubicación representa el ¿Dónde?, reflejando desde la lista de las localidades donde se ubica el negocio (perspectiva del planeador), su modelado logístico (dueño), hasta la configuración de las direcciones de red (programador). La Persona tiene que ver con el ¿Quién?, considerando la lista de unidades organizacionales importantes para el negocio (planeador), su modelo de flujo de trabajo (dueño), hasta la especificación de las restricciones de seguridad (programadores y usuarios). El Tiempo captura el ¿Cuándo?, incluyendo desde la lista de eventos importantes para el negocio (planeador), su modelo de planeación operacional (dueño), hasta la especificación de temporizadores (programador). La Motivación explica la interrogante ¿Por qué?, abarcando desde la lista de objetivos y metas (planeador), su plan de negocio para operar la empresa (dueño), hasta la especificación de las reglas de negocio correspondientes (programador). [13]. 2.1.1.3. Zachman y la arquitectura de datos. El framework de Zachman es considerado como una meta modelo que define una estructura para clasificar y organizar una serie de artefactos que describen la empresa. En consecuencia no contempla aspectos de como iniciar un proyecto de arquitectura de datos, ni mucho menos cuales son las etapas a seguir. A nivel de datos define la dimensión Datos que corresponde al interrogante ¿Qué?, y a través de las perspectivas, identifica una serie de artefactos, empezando por la definición del contexto del negocio, seguido por el modelamiento del contexto, identificación las entidades de negocio y describiendo como se relacionan entre sí con la ayuda de un modelo conceptual. Posteriormente se especifica la necesidad de un modelo físico de datos que después será transformado en la implementación de una fuente de datos.. 23.

(24) Como se puede observar, este enfoque provee una estructura donde define una serie de entregables, pero carece de un proceso de transformación y ejecución de un proyecto de arquitectura de datos en un contexto de arquitectura empresarial.. 2.1.2 Framework de arquitectura empresarial federal El Framework de Arquitectura Empresarial Federal (FEAF por sus siglas en inglés) proporciona un estándar para el desarrollo y documentación de las descripciones de la arquitectura de áreas de alta prioridad. Este provee una guía para la descripción de las arquitecturas de segmentos funcionales de múltiples organizaciones del gobierno federal. La Arquitectura Empresarial Federal es una base de información de valor estratégico que define el negocio, la información necesaria para operar el negocio, las tecnologías necesarias para apoyar las operaciones del negocio y los procesos de transición para la aplicación de las nuevas tecnologías en respuesta a las necesidades cambiantes del negocio. El CIO Council3 propuso tres enfoques para FEAF4: . Enfoque convencional: este enfoque requiere de un gran esfuerzo en tiempo y dinero, porque se aborda el problema global para toda la federación. Este enfoque puede presentar problemas como parálisis por el análisis. a. consecuencia de la complejidad del esfuerzo federal. . Enfoque por segmentos: Promueve el desarrollo incremental de los segmentos de la arquitectura dentro de un marco de arquitectura empresarial estructurada. Este enfoque se centra en grandes áreas de negocio y es más probable que tenga éxito, porque el esfuerzo se limita a funciones comunes o empresas específicas.. 3 4. Chief Information Officer Council Federal Enterprise Architecture Framework. 24.

(25) . Enfoque de Status Quo: Este enfoque representa el funcionamiento normal del negocio tras el fracaso continuo del esfuerzo por compartir información y poder hacer frente a la rápida evolución del entorno. Este enfoque daría lugar a reproceso de negocios, disminución de la productividad y la pérdida de oportunidades.. FEAF consta de ocho componentes necesarios para el desarrollo y mantenimiento de la Arquitectura Empresarial Federal según el CIO Council. A continuación se realiza una descripción general sobre cada uno de estos ocho componentes según [33]: . Motivadores de Arquitectura: Representa dos tipos de estímulos externos para la AE, el primero, corresponde a los motivadores de negocio que pueden ser nueva legislación, fuerzas del mercado, nuevas iniciativas de administración. El segundo estimulo externo, hace referencia a los motivadores de diseño, lo cual incluye nuevo y mejoras en el software y hardware.. . Dirección Estratégica: guía el desarrollo de la AE deseada y consta de una visión, principios, metas y objetivos.. . Arquitectura Actual: define la situación actual de la AE y está compuesta de dos partes: la situación actual para el negocio y el diseño de arquitectura que consta de datos, aplicación y tecnología.. . Arquitectura Objetivo: define la situación deseada de la AE y también está compuesta de dos partes: la situación deseada para el negocio y el diseño de arquitectura que consta de datos, aplicaciones y tecnología.. . Procesos de Transición: soporta la migración de la situación actual a la situación deseada de la AE. Esto incluye capital IT, planificación de inversiones, plan de migración, gestión de la configuración y gestión del cambio.. . Segmentos de Arquitectura: un segmento es considerado como una empresa dentro de la empresa federada. Los segmentos son áreas de negocio transversales como por ejemplo las compras a través de comercio electrónico. 25.

(26) . Modelos Arquitectónicos: define los modelos de negocio y diseño que describen los componentes de los segmentos de la empresa.. . Estándares: este se refiere a todos los estándares o normas, directrices y mejores prácticas.. La arquitectura empresarial federal, consta de cinco modelos de referencia relacionados entre sí, diseñados para facilitar el análisis y la identificación de inversiones duplicadas, las carencias y colaboraciones entre las agencias [35].los cinco modelos de referencia son: . Modelo de referencia del rendimiento (PRM por sus siglas en ingles).. . Modelo de referencia del negocio (BRM por sus siglas en ingles).. . Modelo de referencia de componentes de servicio (SRM por sus siglas en ingles).. . Modelo de referencia técnico (TRM por sus siglas en ingles).. . Modelo de referencia de datos(DRM por sus siglas en ingles).. 2.1.2.1. Modelo de Referencia de Datos (DRM). El DRM es un marco de trabajo flexible basado en estándares que permiten el intercambio de información y la reutilización para todo el gobierno federal, a través de la descripción y descubrimiento estándar de datos comunes y la promoción de prácticas de gestión de datos uniformes [35]. El DRM proporciona un medio estándar a través del cual los datos se pueden describir, clasificar y compartir (ver Figura 2). El marco de implementación de DRM se presenta en la Figura 6. Este marco proporciona un mapa de ruta para ser utilizado por arquitectos empresariales y arquitectos de datos para guiar sus esfuerzos en el intercambio de datos dentro de. 26.

(27) las comunidades de interés. El mapa de ruta se basa en las siguientes afirmaciones básicas [34]:. Figura 2. DRM Áreas de estandarización [35]. El Contexto de los Datos es un área de estandarización de los datos en DRM. Una comunidad de interés, debe ponerse de acuerdo sobre los datos necesarios para satisfacer sus necesidades de negocio de misión compartida. Una comunidad de interés debe ser capaz de responder preguntas básicas acerca de los activos de datos que administra: ¿Cuáles son los datos que necesita?, ¿Quién es responsable de mantener los datos?, ¿Cuál es la vinculación con el modelo de referencia del negocio?, ¿Qué servicios están disponibles para acceder a los datos?, ¿Cuáles son las fuentes de datos donde se almacenan los datos? [34]. La Descripción de los Datos es un área de estandarización de los datos en DRM, donde una comunidad de interés debe ponerse de acuerdo en el significado y la estructura de los datos que necesita, con el fin de utilizar eficazmente los datos.. 27.

(28) Figura 3. Contexto de los datos [34]. Figura 4. Descripción de los datos [34]. Compartir Datos es un área de estandarización de los datos en DRM, donde se proporciona una guía para los tipos de servicios que deben ser provisionados en una comunidad de interés para que el intercambio de información sea posible.. 28.

(29) Figura 5. Compartir Datos [34]. Figura 6. Marco de implementación de DRM. 29.

(30) 2.1.3 TOGAF (The Open Group Architecture Framework) Es un frameworks de AE elaborado y aprobado por los miembros del Foro de Arquitectura The Open Group. Está basado en el Framework de Arquitectura Técnica para la Gestión de la Información (TAFIM5 por sus siglas en inglés) del departamento de defensa de los Estados Unidos de América. Actualmente se encuentra en la versión 9.1. TOGAF es un método detallado y un conjunto de recursos de apoyo para el desarrollo de una AE. Es uno de los frameworks de AE mas difundidos debido a que cuenta con una buena cantidad de información disponible y de acceso público. Este divide la organización en 4 dominios de arquitectura (ver Figura 7): Arquitectura de Negocio, Arquitectura de Aplicaciones, Arquitectura de Datos y Arquitectura de Tecnología [16].. Figura 7. Arquitectura Empresarial según TOGAF [14]. TOGAF se describe como un framework, pero la parte más importante de TOGAF es el Architecture Development Method, más conocido como ADM. ADM es como una receta para la creación de una arquitectura. Una receta puede ser calificada como un proceso. Dado que ADM es la parte más visible de TOGAF, podemos 5. Technical Architecture Framework for Information Management. 30.

(31) clasificar a TOGAF como un proceso arquitectónico en lugar de framework, o una metodología, ya que describe un proceso bien definido como ADM. TOGAF visto como un proceso arquitectónico, complementa a Zachman; recordemos, que es una taxonomía de arquitectura. Zachman indica la forma de clasificar los artefactos. TOGAF le da un proceso de creación de ellos. La versión 9 de TOGAF cuenta con 6 partes principales [16]: . ADM (Architecture Development Method): Describe 10 fases genéricas para el desarrollo de una AE.. . Directrices y Técnicas para ADM: Conjunto de buenas prácticas para el uso de ADM.. . Framework de Contenido de Arquitectura: Provee un meta modelo conceptual el cual describe los artefactos de arquitectura.. . Enterprise Continuum: Suministra un modelo para estructurar un “repositorio virtual” que contendrá los elementos de valor reutilizable para la AE como modelos, patrones y descripciones arquitectónicas entre otros.. . Modelos de Referencia: Son arquitecturas genéricas de un alto nivel abstracción que pueden ser utilizadas para construir la arquitectura de cualquier sistema.. . Framework de Gobierno de Arquitectura: Garantiza que la organización disponga de una estructura organizacional que permita la ejecución del proyecto, la cual incluye definición de roles, responsabilidades, recurso humano capacitado y modelos de certificación, entre otros.. 2.1.3.1. El Ciclo ADM. Continuamos con un repaso de ADM porque este contiene una fase C denominada Arquitectura de Sistemas de Información, donde encontramos la Arquitectura de Datos (AD), la cual es el componente de referencia más 31.

(32) importante en el desarrollo de esta propuesta metodológica. ADM es un método genérico para el desarrollo de AE, el cual está diseñado para hacer frente a la mayoría de los requisitos del sistema y de la organización. Sin embargo, a menudo será necesario modificar o ampliar ADM para adaptarse a necesidades concretas [16]. El ciclo ADM consta de 10 fases, mostradas en la Figura 8, donde incrementalmente se define, ejecuta y controla la AE de forma iterativa.. Figura 8. El ciclo ADM [16]. 32.

(33) Fase Preliminar: en esta fase la empresa se prepara para iniciar el proyecto de AI, definiendo el alcance, los principios, la estructura de gobierno y principalmente el compromiso con el nivel estratégico. En esta fase se deben definir los diferentes ajustes que se le deben hacer a ADM de acuerdo a las necesidades del proyecto. Fase A. Visión de la Arquitectura: marca el inicio de una iteración ADM al definir el alcance, restricciones y expectativas. Se realiza una primera validación del contexto del negocio. Aclarar y acordar el propósito de los esfuerzos de AE es una de las partes fundamentales de esta etapa, y el objetivo debe estar claramente reflejado en la visión que se crea. Los proyectos de arquitectura se realizan con un propósito específico en mente, un conjunto específico de motivadores de negocio que representan el retorno de la inversión para los interesados en el desarrollo de la arquitectura. Aclarar el propósito y demostrar cómo se lograra el desarrollo de la arquitectura propuesta, es la clave principal de la visión de arquitectura [16]. La visión de negocio define el estado deseado o futuro de una determinada organización o empresa en términos de su objetivo fundamental o dirección estratégica. La misión de negocio define el objetivo fundamental de una empresa y básicamente describe porque existe y como este soporta el avance hacia el logro de la visión [17]. La declaración de visión y misión de negocio se utilizan a menudo para apoyar proyectos de mejoramiento. En términos de arquitectura éstos proporcionan un objetivo estratégico y un medio para validar muchos de los objetivos de la arquitectura. La visión y misión también ayudan a validar los principios de arquitectura. Es importante revisar y validar la visión y misión en los compromisos de la arquitectura que soportan la transformación del negocio, ya que ayudara a la toma de decisiones en la reestructuración de la empresa [17]. Algunos ejemplos de misiones de negocio son:. 33.

(34) . 3M: “Resolver problemas sin resolver de forma innovadora.”. . Mary Kay Cosmetics: “Ofrecer oportunidades sin límite a las mujeres.”. . Merck: “Preservar y mejorar la vida humana.”. . Wal-Mart: “Brindar a la gente común la oportunidad de comprar lo mismo que los ricos.”. . Walt Disney: ”Hacer feliz a las personas.”. Fase B. Arquitectura del Negocio: No es diseñar el negocio es entender su estructura según el alcance definido en la fase A, se realiza una comprensión de la organización en aspectos como estructura organizacional, objetivos del negocio, motivadores, estrategias, funciones, servicios, procesos y la interrelación entre ellos. El objeto de esta fase es definir una situación actual y un estado deseado para los procesos de negocio respectivos. La estrategia de negocio proporciona la dirección y descripción de cómo una empresa quiere lograr su visión de negocio en un plazo determinado y la forma como se puede lograr mediante una serie de actividades claves. Es el “Que y Como”. La estrategia de negocio es importante para la arquitectura a corto y largo plazo porque brinda un marco de referencia para evaluar como la arquitectura debe apoyar o alinearse con la estrategia de negocio. La estrategia de negocio no siempre está disponible, ya que puede ser información confidencial. Sin embargo para un trabajo de arquitectura como parte de un proyecto de transformación de la empresa, es importante comprender la estratégica de negocio, para lo cual es necesario preparar entrevistas con los ejecutivos principales. Algunos ejemplos de estrategias de negocio; . Autoservicio.. . Flexibilidad.. . Automatización de procesos de negocio.. 34.

(35) . Indicadores y control de procesos.. . Ajustarse a algún marco de referencia.. Los motivadores de negocio deben ser: específicos, medibles, agresivos pero viables, orientados al resultado y limitados en el tiempo. Un motivador de negocio es una descripción corta que define clara y específicamente los resultados deseados de negocio de una organización así como las actividades necesarias para lograrlo [19]. Se deben identificar claramente los motivadores de negocio y encontrar las relaciones entre los motivadores de negocio y los objetivos de la AI. Fase C. Arquitectura de Sistemas de Información: en esta fase el objetivo es describir y entender la arquitectura de los sistemas de información que requiere el negocio para alcanzar su visión, soportando sus estrategias de negocio y evidenciando su integración. Aquí también se debe establecer el estado actual, el estado futuro y análisis gap del panorama de los sistemas de información. Esta fase cubre dos temas principales: . Arquitectura de Aplicaciones: el trabajo en esta etapa corresponde a identificar cuáles y como son las aplicaciones y su arquitectura que soportan y soportaran el negocio y su integración.. . Arquitectura de Datos: El objetivo de esta etapa es identificar y entender las entidades de datos relevantes para la empresa, no el diseño de sistemas de almacenamiento lógico o físico.. Fase D. Arquitectura Tecnológica: el objetivo en esta fase es identificar y definir los componentes tecnológicos básicos que soportaran la solución a nivel de sistemas de información. Principalmente se definen plataformas de hardware y software base. Fase E. Oportunidades y Soluciones: esta fase se debe evaluar y seleccionar opciones de implementación, tomar decisiones si se debe comprar o desarrollar. 35.

(36) internamente. También se debe definir las dependencias de los proyectos, costos y beneficios con el objeto de crear un plan general de implementación y migración. Fase F. Planeación de la Migración: en esta fase se debe priorizar los proyectos de implementación de acurdo a los aspectos definidos en la fase E tales como dependencia, costos y beneficios de los proyectos de migración, el resultado es un mapa de proyectos detallado de implementación, calidad de datos y migración. Fase G. Gobernabilidad de la implementación: el aspecto principal en esta fase es asegurar que se definan las condiciones de gobierno necesarias para llevar a cabo los proyectos de implementación, teniendo en cuenta actividades como: formular. recomendaciones. para. cada. proyecto,. diseñar. y construir. los. mecanismos y estructuras de gobierno para los proyectos, definir los roles de gobierno necesario y asegurar que los proyectos respetaran la arquitectura. Fase H. Administración del cambio de la Arquitectura: el objetivo principal es definir los procesos de gestión del cambio necesarios para mantener vigente la AE, las actividades principales de estos procesos deben ser: monitorear nuevos desarrollos, monitorear cambios en el entorno del negocio y determinar si es necesario iniciar un nuevo ciclo de evolución de la AE.. 2.1.3.2. Alcance. El alcance de la AI debe ser definido para asegurar el cubrimiento de los temas relevantes para el negocio. Este determina el nivel de granularidad y detalle para cada uno de los aspectos de las áreas a cubrir y asegura el apropiado cumplimiento de las expectativas según el acuerdo con las partes interesadas en el proyecto de AI. El alcance controla el desarrollo de la arquitectura y asegura que todas las actividades se enfoquen en solucionar los problemas del negocio. El alcance de arquitectura es un artefacto obligatorio, porque este define y. 36.

(37) proporciona un medio para asegurar el cumplimiento de las expectativas de los interesados en el proyecto de AI [17].. Cuatro dimensiones se suelen utilizar para definir y limitar el alcance de una arquitectura [16]: . Enfoque o alcance de la empresa: ¿cuál es la extensión total de la empresa y a cuanto de esa extensión debe enfocarse el esfuerzo de arquitectura? o Muchas empresas son muy grandes que pueden comprender una federación de unidades organizativas y que se podrían considerar empresas con derechos propios. o Las empresas modernas cada vez se extienden más allá de sus límites tradicionales de la empresa comercial tradicional para adoptar una combinación con proveedores, clientes y socios.. . Dominios de Arquitectura: una descripción completa de arquitectura empresarial debe contener los cuatro dominios de arquitectura (negocio, aplicaciones, datos y tecnología), pero. la realidad de las limitaciones de. recursos y tiempo a menudo significa que no hay tiempo o recursos suficientes para realizar un top-down de la arquitectura que abarque los cuatro dominios. . Alcance vertical o nivel de detalle: se debe tener cuidado para seleccionar el nivel de detalle adecuado a ser capturado, porque el uso previsto de la arquitectura y las decisiones se toman basados en este. Es importante que un nivel coherente y equitativo de la profundidad sea realizado en cada dominio de la arquitectura. Si se omite un detalle importante, la arquitectura puede ser no útil. Si se incluyen detalles innecesarios el proyecto de arquitectura puede exceder el tiempo y los recursos disponibles y la arquitectura resultante puede ser confusa.. . Periodo de tiempo: cuando el alcance de la empresa es grande y la arquitectura objetivo es particularmente complejas, el desarrollo de la. 37.

(38) arquitectura, puede encontrarse con grandes dificultades, e incluso resultar “misión imposible”, especialmente si se lleva a cabo por primera vez. En tales casos una visión más amplia se puede tomar, por el cual una empresa está representada por varias instancias de arquitectura diferentes, cada instancia representa a la empresa en un instante de tiempo determinado. Una instancia de arquitectura representara el estado actual de la empresa (As-Is), otra instancia de arquitectura puede definir parcialmente la arquitectura objetivo (To-Be). Las instancias de arquitecturas de transición o intermedias cada una compuesta por su propio conjunto de descripciones de la arquitectura objetivo. Típicamente el alcance de una arquitectura es primero expresada en términos del alcance de la empresa, periodo de tiempo y nivel de detalle:. Figura 9. Desarrollo incremental de la arquitectura [16]. 38.

(39) Existen dos enfoques básicos para el desarrollo de arquitecturas: . Vertical: la empresa se divide en segmentos, donde cada segmento representa una línea de negocio independiente dentro de la empresa en general y cada uno con su arquitectura empresarial junto con sus cuatro dominios (negocio, aplicaciones, datos y tecnología), estos dominios de arquitectura se pueden desarrollar separadamente con miras a una integración posterior.. . Horizontal: la empresa se divide en súper-dominios en el cual cada dominio de arquitectura (negocio, aplicaciones, datos y tecnología) cubre toda la empresa en general como un proyecto independiente de los otros, posiblemente con personal diferente y con miras a una integración posterior.. 2.1.3.3. División de Arquitecturas. Es necesario dividir las arquitecturas por las siguientes razones: . Porque abordar los problemas dentro de una única arquitectura es demasiado complejo.. . Para resolver conflictos entre arquitecturas correspondientes a trabajos realizados en diferentes líneas de tiempo. Esto porque el estado de la empresa cambia con el tiempo y una arquitectura desarrollada en una línea de tiempo es muy diferente a otra desarrollada en un momento diferente.. . Permite que diferentes personas trabajen en diferentes elementos de arquitectura al mismo tiempo, además permite la división de arquitectos por grupos especializados de trabajo en los diferentes segmentos de arquitectura.. Descripción de los criterios de clasificación:. 39.

(40) . Asunto: la división de arquitectura son naturalmente organizadas en grupos de acuerdo a la gestión operativa o de control. Ejemplos de particiones pueden ser: aplicaciones, departamentos, productos, servicios, procesos, entre otros.. . Punto de vista: Definición del tema específico de acuerdo a los requerimientos de negocio.. . Nivel de detalle: El nivel de detalle dentro de la arquitectura está directamente relacionado con el grupo de interés en la arquitectura. Las arquitecturas con menos detalle son de interés para los gerentes o ejecutivos, las arquitecturas con un incremento en el detalle es de interés para el personal operativo. Para la definición del nivel de detalle se propone la utilización del framework de Zachman en la dimensión de Datos para las perspectivas de esquema Contextual, conceptual, lógico y Físico.. . Nivel de abstracción: el nivel de abstracción de una arquitectura tiene una fuerte influencia sobre la forma en que la arquitectura será usada. Por ejemplo las arquitecturas que ofrecen una representación muy directa de las soluciones normalmente se utilizan para la compresión del estado actual y futuro de la empresa. las arquitecturas con un nivel de abstracción más alto normalmente se utilizan para comunicar los conceptos o modelos de referencia que se pueden aplicar a los problemas específicos en arquitecturas futuras.. . Precisión: Definición del gobierno y gestión del cambio para garantizar que la arquitectura evolucione de acuerdo a la realidad cambiante de la empresa, de tal forma que permita controlar las sucesivas versiones de los artefactos arquitectónicos.. 2.1.3.4. Principios de Datos. Los principios son normas y directrices generales, con la intención de que sean duraderos y que reara vez sean modificados, para informar y apoyar la forma que una organización establece para el cumplimiento de su misión. A su vez, los. 40.

(41) principios pueden ser sólo un elemento en un conjunto estructurado de ideas, que colectivamente definen y guían a la organización, a través de acciones y resultados. Los principios de datos proporcionan orientación sobre el uso y el despliegue de todos los recursos y activos en toda la empresa, con el fin de hacer el entorno de la información lo más productivo y rentable como sea posible. En [1] se encuentra una descripción detallada de ejemplos de principios de datos propuestos por TOGAF.. 2.1.3.5. TOGAF y La Arquitectura de Datos. TOGAF a través del método ADM dedica una sección al tema de arquitectura de datos donde hace referencia a tres consideraciones principales para Arquitectura de Datos [16]: . Gestión de Datos: cuando una empresa decide emprender un proyecto de AE, es importante entender y abordar los problemas de gestión de datos, para lo cual debe definir un método estructurado y exhaustivo que le permite un uso eficaz de los datos y aprovechar sus ventajas competitivas.. Las. consideraciones que se deben tener en cuenta son: o Identificar los principales componentes de aplicación que servirán de referencia en la identificación de los datos maestros de la empresa. o Identificar estándares propios de la empresa y analizar si es necesario adoptarlos. o Entender claramente cómo las entidades de datos son utilizadas por las funciones de negocio, procesos y servicios. o Es necesario entender cómo y dónde las entidades de datos de la empresa se crean, almacenan, transportan y consultan.. 41.

(42) o Identificar el nivel de complejidad de las transformaciones de datos necesarias para el intercambio de información entre las aplicaciones. o Identificar cuáles serán los requerimientos de software necesarios como apoyo para la integración de datos. Por ejemplo el uso de herramientas ETL o herramientas de perfilamiento para evaluar la calidad de los datos. . Migración. de datos: cuando. reemplazarlas,. existen aplicaciones y es necesario. surgirá la necesidad de. migrar los datos (maestros,. transaccionales y metadatos) a la nueva aplicación. En consecuencia se deben identificar las necesidades de migración de datos y establecer indicadores de transformación y limpieza requerida para obtener los datos en un formato que cumpla con los requisitos de las nuevas aplicaciones. Aquí es importante también asegurarse que toda la empresa tenga una definición común de datos. . Gobierno de datos: son las consideraciones para garantizar que la empresa tiene las dimensiones necesarias que permitan la transformación, de la siguiente forma: o Estructura: esta dimensión se refiere a si la empresa tiene la estructura organizacional necesaria y los organismos de normalización para gestionar los aspectos de transformación de las entidades de datos. o Sistema de gestión: en esta dimensión la empresa debe contar con un sistema que le permita gestionar los aspectos de gobierno sobre las entidades de datos durante todo su ciclo de vida. o Personas: esta dimensión se refiere a los datos relacionados con las habilidades y los roles que la empresa requiere para su transformación. Si la empresa carece de recursos y habilidades, se debe considerar tanto la adquisición de las habilidades críticas o de formación de recursos internos existentes a través de un programa bien definido de aprendizaje.. 42.

(43) TOGAF también define una serie de pasos a seguir para la ejecución de la fase de arquitectura de datos, los pasos son los siguientes: . Seleccionar modelos de referencia, puntos de vista y herramientas: se debe revisar, validar y definir si es necesario el conjunto de principios de datos (ver principios de datos). Seleccionar modelos de referencia como por ejemplo eTOM (enhanced Telecom Operations Map), ARTS Data Model for the Retail industry, Energistics Data Model for the Petrotechnical industry, entre otros.. Un modelo de referencia es un conjunto de convenciones o patrones usados para poder medir o determinar la situación actual de una empresa respecto al modelo de referencia. Esto permite realizar un análisis comparativo y así determinar o cuantificar la brecha que existe entre la situación actual y el marco de referencia. Seleccionar puntos de vista relevantes para la arquitectura de datos, como por ejemplo, puntos de vista de auditores, reportes de tiempo real entre otros. También se deben identificar las herramientas y técnicas necesarias que deben ser utilizadas para la captura, modelamiento y análisis en asociación con los puntos vistas seleccionadas, algunas técnicas de modelamiento de datos son: o Diagrama Entidad-Relación o Diagrama de clases. o Modelamiento de objetos o Diagrama de diseminación de datos o Diagrama de ciclo de vida de datos o Diagrama de seguridad de datos o Diagrama de migración de datos . Desarrollo de una descripción de la situación actual de la arquitectura de datos: desarrollo de una descripción de referencia de la arquitectura de datos existentes en la medida necesaria para apoyar la arquitectura destino. El. 43.

(44) alcance y nivel de detalle dependerá del alcance y objetivos del trabajo de arquitectura. . Descripción del desarrollo de la situación deseada de la arquitectura de datos.. . Realizar análisis de brecha.. . Definir componentes del mapa de proyectos. . Resolver los impactos sobre la arquitectura. . Revisión de la conducta formal de los stakeholder. . Finalizar la arquitectura de datos. . Crear documento de definición de arquitectura. TOGAF ofrece un método en general que aplica para todos los dominios de arquitectura empresarial, lo que implica un nivel de abstracción muy alto porque la arquitectura de negocios, aplicaciones, datos e infraestructura, aunque se relacionan entre sí son aspectos muy diferentes. Además TOGAF se limita a mencionar los temas que se deben tener en cuenta, pero no proporciona un método paso a paso con las tareas específicas de cómo, porque y para que ejecutar cada una de las tareas en el desarrollo de arquitectura de datos.. 2.1.4 Arquitectura de información empresarial según [1] La arquitectura de información empresarial (en adelante AIE) descrita en [1], describe los principios y directrices que permiten una implementación coherente de las soluciones de tecnología de la información, de cómo los datos e información son gobernados y compartidos en toda la empresa, así como también de qué se necesita para garantizar una visión de confianza sobre la información.. 44.

(45) 2.1.4.1. Principios de arquitectura de información. A continuación se presentan algunos ejemplos de los principios básicos que guían una arquitectura de la información: . El acceso y el intercambio de información: los servicios de información deben facilitar el acceso sin restricciones a los usuarios adecuados en el momento adecuado.. . Servicio. de reutilización: facilitar el descubrimiento, la selección y. reutilización de los servicios de información y siempre que sea posible fomentar el uso de interfaces uniformes. . Gestión de la información: tecnología de la información adecuada debe apoyar la ejecución eficaz de una estrategia de gestión de la información.. . Estándares: Un conjunto de normas coherentes para los datos y la tecnología debe ser definida para promover la simplificación a través de la infraestructura de la información.. 2.1.4.2. Dominios de datos. En una empresa existen varios tipos de datos que pueden ser usados en toda la empresa, como pueden ser usados solo en una línea de negocio de la empresa. Los datos pueden ser estructurados o no estructurados y también se pueden ver desde una perspectiva de cómo son almacenados. A continuación la AIE propone 5 dominios de datos:. 45.

(46) Figura 10. Dominios de datos [1].  Metadatos Definidos como datos sobre los datos, los metadatos son la información que describe las características de los datos corporativos y otras entidades. Los metadatos son el dominio de datos que convierte datos en información útil sobre el negocio. Los metadatos pueden ser vistos como una colección de datos e información. utilizada. para. medir,. desarrollar. y. operar. un. entorno. empresarial. También incluyen información crítica del negocio o vínculos a la información que se encuentra fuera de la visión tradicional pura de los datos. Los metadatos son a menudo divididos en metadatos técnicos y metadatos de negocio. Los niveles de madurez de uso en metadatos se pueden ver en la Figura 11:. 46.

(47) Figura 11. Modelo de madurez de metadatos [1]. Nivel 1: Metadatos Técnicos: Un ejemplo de este nivel más bajo de metadatos, es el catálogo de DB2, el cual consiste en un conjunto de tablas que contienen información sobre los datos de control de DB2. Las tablas del catálogo de DB2 contiene información sobre los objetos de DB2 tales como tablas, vistas, índices, procedimientos almacenados, funciones definidas por el usuario, etc. Nivel 2: Metadatos de Negocio: Definir y consumir metadatos de negocio es esencial para las empresas de hoy. Un buen ejemplo de metadatos de negocio es la descripción de términos y de reglas de negocio. Nivel 3: Metadatos de Negocio y Técnicos Alineados: El siguiente nivel de madurez en términos de generación y consumo de metadatos es la alineación. Es decir, es necesario que haya una relación o vínculo entre los metadatos de negocio y técnicos. Un ejemplo consistiría en tener un link entre un reporte de BI y los objetos de IT.. 47.

(48) Nivel 4: Metadatos Para Gestión del Negocio: El siguiente nivel de uso de los metadatos es caracterizado por los metadatos de escenarios de casos de uso que permiten la gestión y optimización del negocio. Esto permite al líder de ventas expresar requerimientos mediante el uso del lenguaje de negocio, donde a través del uso de metadatos éstos requerimientos son traducidos al dominio de TI. Nivel 5: Metadatos Para Innovación del Negocio: Permite mejorar la visión empresarial, innovación, ideas y oportunidades de negocio. Permitiendo un análisis y modelo de negocio predictivo. Para seguir analizando y optimizando el negocio es necesario orquestar todo mediante el uso y exploración de metadatos de negocio y técnicos. Hay diferentes niveles de detalle para los metadatos que corresponden a la arquitectura de información empresarial. Además del nivel conceptual, lógico y físico, se adiciona un nivel contextual al más alto nivel y un nivel de implementación al más bajo nivel: . Nivel Contextual: Describe el contexto de todos los objetos de metadatos y sirve como una base general para describir con más detalle las circunstancias y condiciones para las especificaciones de los objetos de metadatos en los niveles posteriores.. . Nivel conceptual: Proporciona una descripción de alto nivel de los objetos de metadatos. Este puede incluir una descripción de alto nivel de las estructuras de datos y sus relaciones incluyendo taxonomías.. . Nivel Lógico: Contiene los datos de nivel lógico de objetos de metadatos, como los componentes y sus relaciones. Incluye diagramas detallados del modelo de metadatos, detallando descripciones y las interacciones de los objetos de metadatos.. . Nivel físico: Describe todos los objetos de metadatos del nivel físico. Contiene los aspectos operativos, tales como quien es el propietario de un objeto de. 48.