Un enfoque MDE para diseñar los puntos de vista de una arquitectura empresarial

Texto completo

(1)Un enfoque MDE para diseñar los puntos de vista de una arquitectura empresarial. Trabajo de Tesis presentado al Departamento de Ingenierı́a de Sistemas por. Carlos Orlando Peña Cuéllar Asesor: Ph.D. Jorge Alberto Villalobos Salcedo. Para optar al tı́tulo de Magister en Ingenierı́a de Sistemas y Computación. Ingenierı́a de Sistemas Universidad de los Andes July 7, 2010.

(2) Un enfoque MDE para diseñar los puntos de vista de una arquitectura empresarial. Approved by:. Ph.D. Jorge Alberto Villalobos Salcedo, Asesor. Ph.D. Ruby Casallas Gutiérrez. Ph.D. Darı́o Ernesto Correal Torres. MSc. Jorge Arias Bedoya. Date Approved:.

(3) iii. Para mi mamita, Que Dios te tenga en su gloria..

(4) iv. TABLA DE CONTENIDOS DEDICATORIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. iii. LISTA DE TABLAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. vi. LISTA DE FIGURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. vii. I. INTRODUCCIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 1. II. PLANTEAMIENTO DEL PROBLEMA Y OBJETIVOS . . . . . . . .. 4. III ESTADO DEL ARTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 7. 3.1. Arquitectura Empresarial . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 7. 3.1.1. Dominios de una Arquitectura Empresarial . . . . . . . . . . . . . .. 9. 3.1.2. Frameworks de Arquitectura Empresarial . . . . . . . . . . . . . . .. 11. 3.1.3. Conceptos de Modelamiento de la Arquitectura Empresarial . . . .. 17. 3.1.4. Lenguajes para el Modelamiento de la Arquitectura Empresarial . .. 20. 3.1.5. Herramientas de Arquitectura Empresarial . . . . . . . . . . . . . .. 30. Model Driven Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . .. 33. 3.2.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 34. 3.2.2. Meta-Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 35. 3.2.3. Transformación de modelos . . . . . . . . . . . . . . . . . . . . . .. 36. 3.2.4. Entretejido de modelos . . . . . . . . . . . . . . . . . . . . . . . . .. 37. 3.2.5. Técnicas de extensión de los lenguajes . . . . . . . . . . . . . . . .. 38. The Multi-Perspective Enterprise Modeling (MEMO) . . . . . . . . . . .. 40. IV SOLUCIÓN PROPUESTA . . . . . . . . . . . . . . . . . . . . . . . . . . .. 45. 3.2. 3.3. 4.1. Descripción general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 45. 4.2. El lenguaje de meta-modelado . . . . . . . . . . . . . . . . . . . . . . . . .. 47. 4.3. El lenguaje ArchiFusion . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 49. 4.3.1. ToLink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 50. 4.3.2. ToAddAttribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 51.

(5) 4.3.3. NewConcept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 51. 4.4. El motor de transformaciones . . . . . . . . . . . . . . . . . . . . . . . . .. 53. 4.5. La herramienta de definición de puntos de vista . . . . . . . . . . . . . . .. 56. 4.6. Las herramientas para el modelamiento de puntos de vista . . . . . . . . .. 62. VALIDACIÓN: CASO DE ESTUDIO MUEBLES DE LOS ALPES . .. 67. 5.1. Descripción del caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 68. 5.2. Identificación de stakeholders . . . . . . . . . . . . . . . . . . . . . . . . .. 69. 5.3. Especificación de puntos de vista . . . . . . . . . . . . . . . . . . . . . . .. 69. 5.4. Generación de herramientas de modelamiento de puntos de vista . . . . . .. 76. 5.5. Diseño de modelos de puntos de vista . . . . . . . . . . . . . . . . . . . . .. 76. VI CONCLUSIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 80. V. 6.1. Aportes de la Investigación . . . . . . . . . . . . . . . . . . . . . . . . . . .. 81. 6.2. Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 82. APÉNDICE A. — META-MODELOS DE ARCHIMATE . . . . . . . . .. 85. APÉNDICE B — META-MODELOS DE ARCHIMATE EXPRESADOS EN MEMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 APÉNDICE C. — DEFINCIÓN DE LENGUAJE ARCHIFUSION . . .. 90. APÉNDICE D — DEFINCIÓN DE LENGUAJE PARA ESPECIFICAR PUNTOS DE VISTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92. v.

(6) vi. LISTA DE TABLAS 1. Tipos de diagramas ofrecidos por UML . . . . . . . . . . . . . . . . . . .. 21. 2. Puntos de vista de RMD-ODP . . . . . . . . . . . . . . . . . . . . . . . .. 22. 3. Pesos asignados a relaciones de Archimate - Fuente [54] . . . . . . . . . .. 60. 4. Identificación de stakeholders de MDLA . . . . . . . . . . . . . . . . . . .. 69. 5. Descripción de puntos de vista para MDLA . . . . . . . . . . . . . . . . .. 70.

(7) vii. LISTA DE FIGURAS 1. Dominios de la arquitectura empresarial . . . . . . . . . . . . . . . . . . .. 8. 2. Niveles de una arquitectura de tecnologı́a o infraestructura . . . . . . . .. 10. 3. Roles de un framework de arquitectura empresarial - Fuente [52] . . . . .. 11. 4. Estructura TOGAF - Fuente [37] . . . . . . . . . . . . . . . . . . . . . . .. 14. 5. Estructura Zachman - Fuente [44] . . . . . . . . . . . . . . . . . . . . . .. 15. 6. Estructura DoDAF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 17. 7. Categorı́as de stakeholders - Fuente [30] . . . . . . . . . . . . . . . . . . .. 18. 8. Práctica de modelamiento de la arquitectura empresarial . . . . . . . . .. 20. 9. Elementos de negocio asociados con los procesos según BMM - Fuente [28]. 24. 10. Estructura de Archimate - Fuente [29] . . . . . . . . . . . . . . . . . . . .. 25. 11. Relaciones entre los conceptos de la capa de negocio y la capa de aplicaciones - Fuente [29] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 27. 12. Clasificación de puntos de vista según Archimate - Fuente [29] . . . . . .. 27. 13. Meta-Modelo de ARMOR- Fuente [51] . . . . . . . . . . . . . . . . . . . .. 30. 14. Meta-Modelo de Stakeholders- Fuente [51] . . . . . . . . . . . . . . . . . .. 31. 15. Principios de MDE - Fuente [18] . . . . . . . . . . . . . . . . . . . . . . .. 34. 16. Estrategia de MDA - Fuente [15] . . . . . . . . . . . . . . . . . . . . . . .. 36. 17. Entretejido sobre modelo base Vs Entretejido en arquitectura empresarial. 38. 18. Técnicas de extensión de los lenguajes . . . . . . . . . . . . . . . . . . . .. 39. 19. Arquitectura de MEMO - Fuente [24] . . . . . . . . . . . . . . . . . . . .. 41. 20. Modelo de MEMO SML (Strategic Modeling Language) . . . . . . . . . .. 42. 21. Modelo de MEMO OrgML (Organization Modeling Language) . . . . . .. 42. 22. Modelo de MEMO ITML (IT Modeling Language) - Fuente [25] . . . . .. 43. 23. Meta-Modelo de ITML (IT Modeling Language) - Fuente [25] . . . . . . .. 44. 24. Framework para diseñar puntos de vista de la AE . . . . . . . . . . . . .. 46. 25. Meta Meta-Modelo de MEMO - Fuente [24] . . . . . . . . . . . . . . . . .. 48. 26. Ejemplo de composición de meta-modelos . . . . . . . . . . . . . . . . . .. 49.

(8) 27. Modelo de instrucción ToLink . . . . . . . . . . . . . . . . . . . . . . . .. 51. 28. Modelo de instrucción ToAddAttribute . . . . . . . . . . . . . . . . . . .. 52. 29. Modelo de instrucción NewConcept . . . . . . . . . . . . . . . . . . . . .. 52. 30. Generación del Meta-Modelo de la arquitectura empresarial . . . . . . . .. 53. 31. Esquema de transformación para instrucción ToLink . . . . . . . . . . . .. 55. 32. Esquema de transformación para instrucción ToAddAttribute . . . . . . .. 56. 33. Modelo de punto de vista “uso de aplicaciones” - Fuente [29] . . . . . . .. 57. 34. Especificación de punto de vista “uso de aplicaciones” . . . . . . . . . . .. 58. 35. Derivación de relaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 59. 36. Relaciones anotadas con la propiedad “Weigth” . . . . . . . . . . . . . . .. 61. 37. Generación de la especificación de un punto de vista . . . . . . . . . . . .. 62. 38. Transformación de MEMO a Ecore . . . . . . . . . . . . . . . . . . . . . .. 64. 39. Meta-modelo de especificación de punto de vista anotado con Eugenia . .. 65. 40. Herramienta de modelamiento para el punto de vista “goalsRealization” .. 65. 41. Generación y uso de herramientas de modelamiento de puntos de vista. .. 66. 42. Meta-modelo de la arquitectura empresarial . . . . . . . . . . . . . . . . .. 73. 43. Herramienta para realización de objetivos de negocio . . . . . . . . . . . .. 76. 44. Herramienta para realización de servicios de negocio . . . . . . . . . . . .. 77. 45. Herramienta para uso de aplicaciones y tecnologı́a . . . . . . . . . . . . .. 77. 46. Modelo punto de vista: Realización de objetivos de negocio . . . . . . . .. 78. 47. Modelo punto de vista: Realización de servicios de negocio . . . . . . . .. 78. 48. Modelo punto de vista: Uso de aplicaciones y tecnologı́a . . . . . . . . . .. 79. 49. Meta-modelo de negocio - Fuente [29] . . . . . . . . . . . . . . . . . . . .. 85. 50. Meta-modelo de aplicaciones - Fuente [29] . . . . . . . . . . . . . . . . . .. 86. 51. Meta-modelo de tecnologı́a - Fuente [29] . . . . . . . . . . . . . . . . . . .. 86. 52. Meta-modelo de negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 87. 53. Meta-modelo de aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . .. 88. 54. Meta-modelo de tecnologı́a . . . . . . . . . . . . . . . . . . . . . . . . . .. 89. 55. Meta-modelo de ARMOR . . . . . . . . . . . . . . . . . . . . . . . . . . .. 89. viii.

(9) 1. CAPÍTULO I. INTRODUCCIÓN. En el contexto actual de negocios, donde las empresas requieren de un alto nivel de respuesta en un mercado globalizado y en constante evolución y donde la tecnologı́a proporciona más y mejores herramientas para soportar y mejorar las estrategias de negocio, es de vital importancia implementar herramientas de planeación que soporten la integración entre los dominios del negocio y la tecnologı́a, con el fin de incrementar el valor generado a partir de esta integración. La Arquitectura Empresarial (AE) surge como una poderosa herramienta que busca proporcionar una estructura para soportar la operación del negocio, mediante la definición de una arquitectura de TI coherente y consistente que abarca toda la empresa [32]. Un enfoque de AE proporciona un mejor entendimiento de las relaciones que existen entre los conceptos de diversos dominios, como la estrategia de la empresa, los procesos, las aplicaciones, la información y la infraestructura tecnológica. Este entendimiento a su vez, mejora el proceso de toma de decisiones estratégicas aplicadas a mediano y largo plazo. Existen tres áreas donde pueden surgir problemas crı́ticos durante el proceso de construcción de una arquitectura empresarial: El modelamiento, la administración y el mantenimiento [32]. El modelamiento tiene que ver con el diseño de las vistas de la AE, las cuales describen las relaciones entre los diferentes dominios. Estas vistas pueden reflejar el estado actual de la arquitectura, o el estado deseado, de acuerdo a las preocupaciones de los stakeholders y a los motivadores del negocio. La administración se refiere al control que se debe tener sobre los proyectos definidos para cumplir con los objetivos planteados en la arquitectura. Este control tiene que ver con la correcta sincronización de los recursos y cronogramas asignados a cada proyecto, como también con asegurar el cumplimiento de.

(10) los principios arquitecturales definidos por la organización, tales como interoperabilidad, seguridad de la información o flexibilidad en los procesos. Finalmente, el principal objetivo del mantenimiento de una AE es el de proporcionar una estructura formal que soporte la evolución de la AE y que permita reducir el impacto sobre las operaciones de la empresa. Es decir, gestionar de la forma más transparente posible para el negocio, los cambios a los que se someten los diferentes bloques estructurales de la arquitectura. Este trabajo está enfocado en los problemas que surgen en torno al modelamiento de una AE, especialmente aquellos relacionados con la difı́cil tarea de diseñar modelos que incluyan aspectos de múltiples dominios de una empresa, como los procesos, las aplicaciones, los datos, la seguridad, la estrategia, entre otros. La complejidad asociada con este problema se origina en un conjunto heterogéneo de lenguajes de modelamiento que no son fáciles de integrar. Enfoques como IDEF, BPMN, ARIS y UML proporcionan lenguajes para modelar la estructura de una organización, sus procesos y el conjunto de tecnologı́as que soportan su operación. Sin embargo, ninguno de estos enfoques proporciona un mecanismo para soportar la relación que existe entre los diferentes dominios de una arquitectura, y muchos de estos lenguajes no tienen una visión holı́stica de la arquitectura y se enfocan en un dominio especı́fico [37]. El análisis del problema del modelamiento de una AE, se realizó tomando como base el lenguaje de descripción arquitectural (ADL) Archimate [29]. El propósito de Archimate es proporcionar una sintaxis concreta, fácil de interpretar para cualquier stakeholder de la arquitectura. Mediante el uso de esta sintaxis, se pueden diseñar modelos de la arquitectura empresarial, que representan puntos de vista donde se expresa cómo en la arquitectura se están contemplando las preocupaciones de los diferentes stakeholders. Archimate esta especificado por tres meta-modelos interrelacionados, que se enfocan en conceptos del negocio, las aplicaciones y la tecnologı́a. A partir de estos meta-modelos, Archimate propone un conjunto de puntos de vista de la arquitectura. Sin embargo, estos puntos de vista pueden no ser suficientes para modelar todos los posibles aspectos de una AE. De hecho, definir nuevos puntos de vista podrı́a ser una tarea imposible si los conceptos necesarios no están. 2.

(11) incluidos en los meta-modelos de Archimate. Por lo tanto, surge la necesidad de proporcionar mecanismos que soporten la definición de extensiones de este lenguaje, con el fin de incluir nuevos conceptos que expresen dominios de la empresa, distintos a los contemplados por Archimate. Adicionalmente, se requiere de un mecanismo que permita componer los conceptos de los diferentes dominios, con el fin de establecer un meta-modelo de la arquitectura empresarial adaptado a las necesidades concretas de una empresa, el cual sirve de base para la definición de los puntos de vista de la arquitectura. La estrategia planteada en este trabajo está basada en la propuesta de un framework de AE soportado por el enfoque MDE (Model Driven Engineering). Este framework busca proporcionar herramientas que soporten la evolución de Archimate y por consiguiente el modelamiento de una AE. Usando este framework es posible definir el meta-modelo de la AE, como resultado de componer y personalizar los meta-modelos de Archimate y los de sus extensiones. De igual forma, a este framework se le incluye el lenguaje de meta-modelado MEMO [24], con el fin de proporcionar una herramienta que permita especificar estos metamodelos, lo cual asegura la interoperabilidad entre estos. Finalmente, se propone incluir herramientas que permitan definir la especificación de puntos de vista conformes con el meta-modelo de la AE y que permitan diseñar herramientas basadas en estos puntos de vista, que proporcionan un medio de interacción con los stakeholders. Este documento está estructurado de la siguiente manera: En el capı́tulo dos se presenta el planteamiento del problema y los objetivos de la investigación; en el capı́tulo tres se presenta el estado del arte en torno a la arquitectura empresarial y especı́ficamente a la actividad de modelamiento de la arquitectura; en el capı́tulo cuatro se describe la estrategia propuesta; en el capı́tulo cinco se valida la propuesta con un escenario del laboratorio de arquitecturas empresariales (LAE) del departamento de Ingenierı́a de Sistemas y Computación de la Universidad de los Andes; y en el capı́tulo seis se presentan la conclusiones del trabajo realizado, los aportes de la investigación y las propuestas para trabajos futuros.. 3.

(12) 4. CAPÍTULO II. PLANTEAMIENTO DEL PROBLEMA Y OBJETIVOS. El potencial que ofrece un enfoque basado en arquitectura empresarial a una organización está muy bien documentado y soportado por varias investigaciones y organizaciones que lo promueven, tales como The Open Group, Novay, Gartner y Forrester. Sin embargo, a pesar de la amplia aceptación que se ha generado en torno a esta disciplina y al diverso conjunto de estándares y buenas prácticas que se han propuesto para soportar su aplicación, aún se percibe la necesidad de establecer una visión convergente que formalice aún más esta área del conocimiento [36]. Esta visión deberı́a estar fundamentada en un conjunto de definiciones, metodologı́as, estándares, lenguajes y herramientas que reduzcan el nivel de ambigüedad que en ocasiones se percibe sobre esta actividad. Archimate hace parte de esta iniciativa, al proporcionar un lenguaje pensado exclusivamente para modelar una arquitectura empresarial, a la vez que mantiene la visión holı́stica de una empresa, mediante la integración de los diferentes dominios que la conforman. Ahora bien, la estructura base de este lenguaje contempla los conceptos más relevantes que sirven para describir los dominios del negocio, las aplicaciones que dan soporte al negocio y la plataforma tecnológica subyacente. Esta estructura fue diseñada desde un comienzo pensando en mantener un nivel de complejidad bajo del lenguaje, lo cual tiene mucho sentido, teniendo en cuenta que un lenguaje basado en un conjunto muy extenso de conceptos y relaciones, probablemente no podrı́a ser utilizado en su totalidad en contextos reales, debido a la dificultad que conlleva su entendimiento. No obstante, esta caracterı́stica deja planteada la necesidad de definir extensiones del lenguaje que expresen dominios no contemplados en la estructura base y por lo tanto, a pesar del esfuerzo inicial, esta estructura.

(13) podrı́a llegar a ser muy compleja. Una estrategia valida que puede ser aplicada para reducir la complejidad de un lenguaje que abarca tantos dominios, consiste en definir distintos puntos de vista, que utilizan un sub conjunto de conceptos del lenguaje y que están enfocados en proveer información especı́fica de la arquitectura a un conjunto identificado de stakeholders. Este enfoque tiene dos ventajas, primero, a pesar de que los puntos de vista son ortogonales, es decir, expresan diferentes aspectos de la arquitectura, su base conceptual surge de una terminologı́a común que es gobernada por el lenguaje, lo cual facilita la comunicación entre los distintos stakeholders. Segundo, a partir de los puntos de vista se puede establecer un modelo consolidado de la arquitectura, que integra todos los dominios y sobre el cual es posible realizar diferentes tipos de análisis que dan soporte a la toma de decisiones. Bajo este escenario, es necesario tratar de forma independiente los meta-modelos que describen los diferentes dominios contemplados en Archimate y en sus extensiones. Esto con el fin de fomentar la separación de preocupaciones y de establecer una estrategia que permita relacionar los conceptos de los diferentes dominios. De igual forma, sin ánimo de ir en contra de la estandarización, para una empresa serı́a muy útil contar con una herramienta con la cual pudiera definir la terminologı́a común que más se ajusta a su contexto, a partir de los meta-modelos que se plantearon para cada dominio, obteniendo ası́ un meta-modelo de la arquitectura empresarial, a partir del cual pudiera diseñar sus propios puntos de vista. Con el objetivo de fomentar la continuidad de Archimate como lenguaje para el modelamiento de la arquitectura empresarial, en este trabajo se propone un framework a través del cual es posible expresar los meta-modelos de Archimate y su extensiones, definir las relaciones que pueden existir entre los diferentes dominios de la arquitectura, establecer que conceptos de cada dominio son realmente relevantes para una empresa, agregar atributos sobre los conceptos, con el fin de mejorar la expresividad del lenguaje, agregar nuevos conceptos, y en general definir un meta-modelo de la arquitectura empresarial, adaptado a las necesidades de una empresa. De igual forma, se proponen herramientas para diseñar la estructura de los puntos de vista de la arquitectura, a partir de la terminologı́a común definida en el meta-modelo de la arquitectura empresarial. Finalmente, se propone una. 5.

(14) estrategia para construir herramientas de modelamiento basadas en las especificaciones de los puntos de vista. Estas son las herramientas que finalmente utilizarán los stakeholders para modelar y expresar los puntos de vista de la arquitectura. Los objetivos definidos para cumplir con la definición de esta estrategia son los siguientes: 1. Definir la estructura global del framework aplicando un enfoque MDE. 2. Seleccionar un lenguaje de meta modelado y expresar a través de éste los meta-modelos de Archimate y de sus extensiones. 3. Definir un lenguaje de dominio especı́fico (DSL) a través del cual se expresen las relaciones que existen entre los conceptos de diferentes dominios, se personalicen estos conceptos mediante la definición de nuevos atributos y se agreguen conceptos que no existen en los meta-modelos de los dominios contemplados. 4. Definir una estrategia basada en transformaciones entre meta-modelos, que permita generar el meta-modelo de la arquitectura empresarial a partir de la integración de las instrucciones definidas con el DSL y los meta-modelos fuente. 5. Proponer una herramienta para especificar la estructura de los puntos de vista de una arquitectura a partir del meta-modelo de arquitectura empresarial definido previamente. 6. Proponer una estrategia para generar herramientas de modelamiento de los puntos de vista.. 6.

(15) 7. CAPÍTULO III. ESTADO DEL ARTE. En este capı́tulo se presenta una descripción detallada de los conceptos que se abarcan en este trabajo, con el fin de proporcionar una base teórica firme a la estrategia de solución planteada. Se inicia con un análisis de los principales aspectos en torno al enfoque de arquitectura empresarial, como son los frameworks de arquitectura, los conceptos de modelamiento de una arquitectura empresarial, los lenguajes más significativos que existen para realizar la tarea de modelamiento y los distintos enfoques que proponen algunas de las herramientas, disponibles en el mercado, que están orientadas a soportan el desarrollo de una arquitectura empresarial. Se presentan los conceptos más relevantes en torno al enfoque de MDE y se finaliza con una descripción del enfoque de modelamiento de distintos dominios de una empresa planteado por MEMO.. 3.1. Arquitectura Empresarial. La arquitectura empresarial (AE) surge como una herramienta de planeación que apoya el proceso de toma de decisiones mediante la identificación de una visión integral de las relaciones que existen entre los principales elementos de negocio y los elementos de TI que soportan su operación. Permite analizar la coherencia de estas relaciones, con respecto al análisis de fuerzas internas y externas que marcan el contexto de la organización y determinar qué aspectos se deben fortalecer con el fin de generar y asegurar valor para el negocio, a partir de los requerimientos y las preocupaciones de los stakeholders. Una definición formal nos dice que “la arquitectura empresarial es un conjunto coherente de principios, métodos y modelos que son utilizados en el diseño y en la definición de la estructura organizacional, los procesos de negocio, los sistemas de información y la.

(16) infraestructura tecnológica de una empresa”[37]. Como tal, proporciona un modelo lógico para integrar estos activos organizacionales. En este contexto, se busca involucrar de una forma más activa a la alta gerencia en la toma de decisiones tecnológicas, mediante la consolidación del enfoque en el cual se interpreta a la tecnologı́a como un habilitador y apalancador de los objetivos y estrategias de negocio, más que como un artefacto de soporte y que por lo tanto ofrece un conjunto de capacidades independientes que pueden evolucionar y ser aplicadas en diferentes escenarios. Otra definición de arquitectura empresarial nos dice que es “el framework para analizar cómo la organización logra los objetivos de negocio actuales y futuros. Examina las estrategias claves de negocio, información, aplicaciones y tecnologı́a y su impacto en las funciones de negocio, reflejando estos aspectos en dominios arquitecturales separados que son integrados por la arquitectura empresarial”[50], tal y como se ilustra en la figura 1. Este enfoque de categorización de la arquitectura por dominios es desarrollado por muchos de los frameworks de arquitectura empresarial, como TOGAF, DoDAF y Zachman. A continuación se describen los principales elementos de cada uno de estos dominios.. Figure 1: Dominios de la arquitectura empresarial. 8.

(17) 3.1.1. Dominios de una Arquitectura Empresarial. 3.1.1.1. Arquitectura de negocio. El objetivo de la arquitectura de negocio es identificar y documentar la visión y misión, los motivadores, metas y objetivos del negocio, las polı́ticas y reglas que rigen el negocio, establecer la relación con las estrategias y definir los procesos que soportan estas estrategias. Adicionalmente, se hace un análisis de las funciones de negocio y se determina que servicios de negocio son proporcionados por la arquitectura, como también que unidades organizacionales son responsables de los procesos identificados y que roles y actores interactúan con estos. A partir de este conjunto de definiciones, se determina qué información fluirá a través de los procesos y en qué casos se requiere que estos sean automatizados a través de aplicaciones o sistemas de software. 3.1.1.2. Arquitectura de información. La arquitectura de información se enfoca inicialmente en formalizar y complementar los requerimientos de datos generados en la arquitectura de negocio, dándole una estructura lógica (modelo conceptual de la empresa: ontologı́a, KPIs, etc.) y fı́sica (esquemas de las bases de datos, estructura de los archivos, etc.) a las entidades del negocio. Teniendo este esquema definido, el siguiente paso es determinar quién, cómo, dónde y para que necesita las entidades de datos identificadas, como también quien o que unidad organizacional será encargada de cumplir el rol de administrador de los datos de negocio. 3.1.1.3. Arquitectura de aplicaciones. La arquitectura de aplicaciones se enfoca en determinar que aplicaciones de software se requieren para dar soporte a los procesos y a los servicios de negocio y por consiguiente procesar la información que fluye a través de estos. Sin embargo, dentro del contexto de la arquitectura empresarial, es necesario aclarar que en este dominio no se busca diseñar e implementar las aplicaciones que harán parte de la arquitectura, tal y como se aclara en [30] estas no son descritas como sistemas de software concretos, sino como grupos lógicos de capacidades que manejan los objetos de datos identificados en la arquitectura de información. 9.

(18) y soportan las funciones de negocio identificadas en la arquitectura de negocio. Adicionalmente, su definición incluye una ficha técnica que describe los servicios que proporciona, sus entradas y salidas, las configuraciones disponibles, los entornos de ejecución requeridos y se busca no referenciar alguna tecnologı́a en particular, evitando ası́ dependencias anticipadas sobre la plataforma tecnológica. En este dominio arquitectural, a demás de identificar las aplicaciones, se determinan los flujos de comunicación entre estas, la relación con sus usuarios potenciales, los diferentes entornos de ejecución requeridos para su funcionamiento, los servicios de tecnologı́a que utilizan y se establecen las polı́ticas para la gestión del catalogo de aplicaciones de la empresa. 3.1.1.4. Arquitectura de tecnologı́a. En la arquitectura de tecnologı́a es donde se define que servicios prestarán los diferentes componentes de software o hardware necesarios para soportar todos los requerimientos generados en los niveles superiores de la arquitectura empresarial y por lo tanto soportar la operación de la empresa. La definición de estos componentes va desde la plataforma de hardware y de comunicaciones, hasta el software especializado en servicios particulares requeridos por los componentes de aplicación y de información, tal y como se describe en la figura 2. Figure 2: Niveles de una arquitectura de tecnologı́a o infraestructura El software especializado comprende los sistemas que se enfocan en soportar procesos concretos de la empresa, como un ERP, un CRM o un ECM. El software o hardware de integración permite la operación entre diferentes aplicaciones distribuidas sobre plataformas heterogéneas. La infraestructura de comunicaciones proporciona los servicios básicos para interconectar los sistemas, se ocupa de la gestión de los dispositivos de hardware y software. 10.

(19) que permiten esta interconexión, como routers, switches y puntos de acceso, como también de la definición y gestión de las redes que se extenderán por la empresa (VPNs, LANs, Wireless Networks, VLANs, MANs, etc.). La identificación de los diferentes componentes de cada dominio arquitectural no aporta mayor valor al negocio de forma aislada y por lo tanto se deben establecer relaciones entre los cuatro dominios para verificar si realmente se puede aplicar una trazabilidad que demuestre que los aspectos del negocio están alineados con las capacidades de tecnologı́a de la organización, lo cual significa que las inversiones en tecnologı́a se realizan conforme el negocio las requiere para su operación y para cumplir con sus metas y objetivos. 3.1.2. Frameworks de Arquitectura Empresarial. Los frameworks de arquitectura empresarial surgen como respuesta a la necesidad de generar procesos de desarrollo de arquitectura estándares, mediante la definición de una estructura formal que defina una metodologı́a a seguir, sobre un vocabulario común que se vea reflejado en el conjunto de entregables que modelan y documentan los diferentes dominios de la arquitectura. Adicionalmente, proponen un conjunto de estándares recomendados para aplicar las mejores prácticas durante el proceso de definición y gestión de la arquitectura y definen un conjunto de roles y responsabilidades que se deben asumir durante el proceso. La figura 3 ilustra los roles de un framwork de arquitectura, según [52].. Figure 3: Roles de un framework de arquitectura empresarial - Fuente [52]. 11.

(20) Como herramienta de especificación, el framework de arquitectura empresarial propone metodologı́as para identificar los elementos de cada dominio de la arquitectura y un conjunto de puntos de vista que sirven como herramienta para documentar las relaciones entre los artefactos que componen la arquitectura y para reflejar de forma especializada las necesidades y preocupaciones de los stakeholders. El concepto de punto de vista entra a jugar un papel muy importante durante el desarrollo de la arquitectura empresarial, ya que éste es el mecanismo utilizado para transmitir los resultados generados durante el proceso, de una forma especializada sobre aspectos particulares de importancia para cierto grupo de stakeholders. Según [1] una vista es una representación de un sistema desde la perspectiva de un conjunto de preocupaciones relacionadas; y un punto de vista es una especificación de las convenciones para construir y usar una vista. Resumiendo, una vista corresponde a la imagen de la arquitectura que los stakeholders desean ver, de acuerdo a sus preocupaciones, y un punto de vista es la “receta” para generar esta imagen, a partir de una especificación. Como herramienta de planeación, el framework de arquitectura empresarial se concentra en el análisis de brecha entre el estado actual y el estado deseado de la arquitectura y en la definición de un mapa de proyectos que estén orientados a reducir esta brecha, a través de la implementación de diferentes arquitecturas de transición. Es decir, a partir de los entregables modelados, siguiendo la metodologı́a propuesta, se realiza un análisis para identificar qué aspectos del estado actual de la arquitectura deben mejorarse para llegar a un estado deseado con base en los motivadores del negocio y las preocupaciones de los stakeholders. En [39] proponen hacer un paralelo entre el concepto de framework de arquitectura y el de método de ingenierı́a, que según definición planteada en Method Engineering: Engineering of information systems development methods and tools (como se cita en [39]) es la disciplina para diseñar, construir y adaptar, métodos, técnicas y herramientas para el desarrollo de sistemas de información. A través de este paralelo se busca definir cuáles son los componentes básicos que deben estar presentes en un método de ingenierı́a y que por lo tanto serı́an la base para evaluar y determinar que framework de arquitectura responde más a las necesidades de una empresa. Por lo tanto, se propone que como mı́nimo se debe contar. 12.

(21) con un meta-modelo, un modelo procedimental, un conjunto de técnicas de modelamiento, un conjunto de roles involucrados en el proceso y un esquema de especificación de la documentación generada. Las técnicas de modelamiento reflejan lo que se está percibiendo en el contexto de la arquitectura, el meta modelo determina que elementos lingüı́sticos y que reglas se deben aplicar para expresar y comunicar la percepción modelada; el modelo procedimental determina que pasos se deben seguir en el proceso de análisis del problema planteado y el conjunto de roles y responsabilidades determina quienes deben hacer parte del proceso y que funciones deben ejecutar. A continuación se presenta una descripción de tres de los principales frameworks de arquitectura empresarial: TOGAF, Zachman y DoDAF. 3.1.2.1. The Open Group Architecture Framework (TOGAF). La figura 4 muestra los principales elementos de TOGAF documentados en su última versión [30]. El núcleo de este framework es su método de desarrollo de arquitectura (ADM). Este método plantea las fases que se deben seguir para definir y gestionar una arquitectura empresarial, partiendo de una visión de arquitectura, hasta llegar a un proceso de gestión del manejo del cambio sobre los artefactos de la arquitectura. Las fases definidas en el ADM generan un conjunto de entregables, expresados a través de diferentes puntos de vista. Estos artefactos se encuentran documentados en el Architecture Content Framework y están basados en el Architecture Content meta-model, que busca establecer una terminologı́a común en torno a la arquitectura empresarial. El Architecture Capability Framework plantea cuales son las estructuras organizacionales, los procesos, roles, responsabilidades y habilidades requeridas para operar una función arquitectural dentro de una empresa [37]. Finalmente, en el Enterprise Continuum se documentan los modelos de referencia que tiene en cuenta la empresa para hacer la definición de los bloques estructurales de la arquitectura. Estos modelos pueden tener diferentes niveles de abstracción, partiendo desde modelos altamente genéricos, como el Business Motivation Model (BMM) [28], pasando por modelos de industria, como eTOM [22], hasta llegar a modelos especı́ficos de la empresa aplicados sobre lı́neas de negocio, áreas funcionales o procesos de negocio.. 13.

(22) Figure 4: Estructura TOGAF - Fuente [37] Para cada fase del ADM, TOGAF recomienda un conjunto de puntos de vista que le dan forma a la descripción arquitectural. En su mayorı́a, los puntos de vista son conformes al meta-modelo de arquitectura. Sin embargo, el framework es ambiguo en la selección de los lenguajes y técnicas utilizadas para modelar estos puntos de vista. 3.1.2.2. Zachman. De acuerdo a [55] este framework proporciona una estructura lógica para organizar y clasificar los diferentes artefactos que describen la estructura y comportamiento de una empresa y que son significativos tanto para la administración de ésta, como para el desarrollo de los sistemas que la componen. Esta estructura se documenta a través de la matriz presentada en la figura 5. Cada una de las 30 celdas contiene los artefactos que se deben diseñar para expresar una dimensión en los términos requeridos por alguna de las perspectivas que pueden asumir los stakeholders que participan en el proceso de definición de la arquitectura. según [44] el framework incluye las siguientes dimensiones: • Qué: corresponde a las entidades que están involucradas en el proceso de arquitectura, 14.

(23) Figure 5: Estructura Zachman - Fuente [44] que van desde el modelo conceptual de la empresa (ontologı́a de negocio, KPIs, etc.), hasta la representación lógica y fı́sica de los datos (esquema de base de datos, de bodega de datos, de archivos, etc.). • Cómo: Representa las funciones, procesos de negocio o sistemas de información que procesan las entidades. • Dónde: Refleja la ubicación geográfica de las unidades organizacionales, la distribución fı́sica de los sistemas de información y en general la distribución de la plataforma tecnológica. • Quién: Identifica cuáles son las unidades organizacionales, roles y actores involucrados en el proceso de arquitectura y que tienen contacto con los sistemas de información. • Cuándo: Representa los eventos que gobiernan el proceso de arquitectura: eventos de negocio, ciclos de vida de componentes de aplicación, ciclos de vida de estrategias de negocio, etc. • Por qué: Expresa la motivación que tiene la empresa en torno a la arquitectura. Esta motivación tiene que ver con la estrategia, los principios, reglas y polı́ticas de la empresa. 15.

(24) Con respecto a las perspectivas de los stakeholders, Zachman identifica las siguientes: • Alcance: Tiene que ver con la definición del propósito y la estrategia del negocio. • Modelo de negocio: se concentra en la definición de la estructura empresarial: unidades de negocio, unidades organizacionales, procesos de negocio, etc. • Modelo del sistema: Se preocupa por definir cómo los sistemas de información satisfacen los requerimientos y objetivos del negocio. • Modelo tecnológico: Se enfoca en determinar cómo se construirán los sistemas de información identificados. • Representación detallada: Se concentra en detalles especı́ficos de la implementación de los sistemas de información. Zachman proporciona una clasificación de alto nivel de los puntos de vista que describen una arquitectura empresarial. Sin embargo, no es clara la definición de un meta-modelo de la arquitectura que exprese cuales son los conceptos y las relaciones entre estos. Por lo tanto, no es posible asegurar consistencia en la terminologı́a utilizada para describir cada punto de vista. Adicionalmente, el framework es independiente de metodologı́as especı́ficas [39] y por lo tanto no detalla cómo se deben construir los puntos de vista o que herramientas utilizar para este proceso. 3.1.2.3. Department of Defense Architecture Framework (DoDAF). DoDAF propone un framework de arquitectura unificado y común que deben seguir todas las agencias adscritas al departamento de defensa (DoD) de Estados Unidos, con el objetivo de tomar decisiones de forma más efectiva, soportadas en información compartida por todas las agencias del departamento [46]. La figura 6 muestra los principales componentes de este framework. Cuenta con un conjunto de metodologı́as que soportan todo el proceso de desarrollo de la arquitectura. Propone una clasificación de puntos de vista, que a su vez están especificados por el meta-modelo de DoDAF. Y finalmente, proporciona una serie de recursos que gobiernan el desarrollo de la arquitectura, cómo estándares de información,. 16.

(25) reglas y polı́ticas que se deben cumplir durante el proceso de definición de la arquitectura y sistemas de registro donde se almacenan arquitecturas de referencia. A pesar de que el framework recomienda una serie de técnicas de presentación de los puntos de vista de la arquitectura, estas no están basadas en lenguajes concretos de modelamiento y al contrario son técnicas informales donde es difı́cil validar si realmente se está cumpliendo con la estructura que se propone en el meta-modelo de DoDAF.. Figure 6: Estructura DoDAF. 3.1.3. Conceptos de Modelamiento de la Arquitectura Empresarial. Como se ha mencionado en secciones anteriores, la arquitectura empresarial busca proporcionar un medio a través del cual se logre definir una visión integral de la relación que existe entre los elementos de negocio y los elementos de tecnologı́a que soportan su operación. Esta visión se expresa en términos de modelos que reflejan diferentes escenarios, que a su vez soportan el proceso de toma de decisiones de la empresa. La labor de modelamiento de la arquitectura empresarial es una de las nociones claves en torno a ésta área del conocimiento. Esta actividad integra conceptos de diversos dominios de la empresa con el fin de ilustrar como las preocupaciones de los stakeholders están siendo consideradas a través del proceso arquitectural y de proporcionar una base para realizar análisis sobre los componentes del negocio y de TI. Sin embargo, existe una complejidad asociada a esta actividad, que surge 17.

(26) a partir de una gran variedad de stakeholders, con diferentes habilidades y perspectivas. La figura 7 muestra las categorı́as de stakeholders que podrı́an considerarse en un proceso de arquitectura empresarial según TOGAF.. Figure 7: Categorı́as de stakeholders - Fuente [30] La alta gerencia está interesada en los motivadores y objetivos del negocio y en cómo estos están soportados sobre procesos efectivos y sobre una arquitectura de TI eficiente. La oficina de gestión de proyectos está interesada en priorizar y sincronizar los proyectos definidos para cumplir con los objetivos propuestos en la arquitectura. Los stakehodlers encargados de compras están interesados en conocer que componentes estructurales de la arquitectura deben ser adquiridos y cuáles deben ser los criterios de selección. Recursos humanos se preocupa por asegurar que los roles y actores requeridos para el proceso de arquitectura estén presentes en la organización. Los stakeholdres de seguridad les preocupa cómo asegurar que la información y los sistemas de la organización estén disponibles solo para las personas que tengan los permisos requeridos. Los stakeholders de aseguramiento de la calidad les interesa tener claridad sobre los estándares, principios, reglas y polı́ticas que guı́an el proceso de gobierno de la organización. Los expertos de los diferentes dominios de negocio están interesados en los aspectos funcionales al rededor de los procesos y de 18.

(27) los sistemas de información de la organización. Los stakeholders encargados de la gestión de los servicios de TI están interesados en asegurar que los servicios que ofrece TI están alineados con los niveles de servicio que requiere el negocio para cumplir con sus objetivos. Los stakeholders encargados de la operación de TI a nivel de aplicaciones, infraestructura y comunicaciones les interesa cómo lograr que la plataforma tecnológica opere bajo los estándares establecidos y teniendo en cuenta los aspectos de reutilización, portabilidad y el tiempo requerido para pasar a producción los componentes estructurales de la arquitectura. A los proveedores les interesa conocer cuáles son los criterios establecidos por la organización para el intercambio de información con los agentes externos. Como se puede observar cada categorı́a tiene sus propias preocupaciones y niveles de participación en la arquitectura, y por esta razón es necesario desarrollar un buen entendimiento de los stakeholders, con el fin de establecer su nivel de influencia y de definir los puntos de vista requeridos donde se ilustren los aspectos arquitecturales más relevantes para éstos. Una buena práctica de modelamiento de la arquitectura empresarial deberı́a seguir la estructura de la figura 8. En este contexto, los stakeholders están interesados en uno o más dominios de la arquitectura, como los procesos de negocio, la estrategia del negocio, la integración de aplicaciones, la plataforma tecnológica, etc. Los stakeholders manifiestan sus preocupaciones y estas deberı́an ser analizadas por un conjunto de arquitectos con el fin de definir una descripción arquitectural que contemple estas preocupaciones. Esta descripción arquitectural agrupa un conjunto de puntos de vista diseñados por los arquitectos, donde se define la especificación de cada punto de vista, que finalmente le da estructura a las vistas de la arquitectura. Por último, los arquitectos definen las técnicas de visualización adecuadas (diagramas, matrices, catálogos, etc.), con el fin de proporcionar un medio de interacción con los stakeholders. De acuerdo a la información suministrada en la sección de frameworks de arquitectura se puede concluir que a pesar de la estructura proporcionada por estos frameworks, basada en sus metodologı́as, entregables, puntos de vista y meta-modelos, ninguno de estos proporciona de forma explı́cita un lenguaje concreto para modelar los puntos de vista que reflejan. 19.

(28) Figure 8: Práctica de modelamiento de la arquitectura empresarial las preocupaciones de los stakeholders. Por lo tanto, la opción de los arquitectos es hacer uso de lenguajes ya establecidos enfocados en ciertos dominios de la arquitectura, como BPMN y UML. Estos lenguajes están enfocados en modelar procesos de negocio (dominio de negocio) y en modelar la arquitectura y las aplicaciones de software (dominio de aplicaciones y tecnologı́a). A pesar de ser estándares reconocidos, que cuentan con el soporte de varias herramientas y que se utilizan ampliamente para describir sistemas de información, algunos problemas de integración surgen al utilizarlos para modelar una arquitectura empresarial [38], debido a que en este contexto es necesario diseñar puntos de vista que abarquen múltiples dominios, más sin embargo estos lenguajes son altamente especı́ficos y sus técnicas de modelamiento son aplicadas de forma aislada sobre un dominio especı́fico. 3.1.4. Lenguajes para el Modelamiento de la Arquitectura Empresarial. En esta sección se da una descripción de la forma en la que se utilizan algunos lenguajes para modelar los distintos puntos de vista de una arquitectura empresarial. 3.1.4.1. UML. Actualmente este lenguaje es considerado el estándar de industria para especificar, visualizar, construir y documentar los artefactos de un sistema de software [37]. La tabla 1 lista. 20.

(29) Diagramas de estructura Diagrama de clases Diagrama de objetos Diagrama de componentes Diagrama de estructura de composición Diagrama de paquetes Diagrama de despliegue. Diagramas de comportamiento Diagrama de casos de uso Diagrama de actividad Maquinas de estado Diagrama de comunicación Diagrama de secuencia Diagrama de tiempo Diagrama de interacciones. Table 1: Tipos de diagramas ofrecidos por UML los trece diagramas que se pueden modelar utilizando UML. Estos diagramas expresan la estructura y el comportamiento de un sistema. Los diagramas de estructura reflejan un visión estática del sistema, identificando sus componentes y las relaciones y dependencias que existen entre estos. Los diagramas de comportamiento identifican los aspectos dinámicos del sistema, como las funciones que deberı́a proporcionar, la descripción de la interacción que existe entre sus componentes y los diferentes estados que pueden presentarse durante su ejecución. “UML es un lenguaje de propósito general que puede ser aplicado a todos los dominios de aplicación (e.g., salud, financiero, telecomunicaciones, industria aeroespacial) y plataformas de implementación (e.g., J2EE, .NET)”[48]. Sin embargo, a pesar de esta caracterı́stica, dentro del contexto de una arquitectura empresarial, en su estructura básica este lenguaje se puede utilizar solo para modelar y especificar los dominios de aplicaciones y tecnologı́a. Cada uno de los diagramas soportados por UML se pueden interpretar como puntos de vista para estos dominios. Por ejemplo, el diagrama de clases se utiliza para diseñar las aplicaciones que soportan las funciones de negocio o el diagrama de despliegue se utiliza para definir sobre qué elementos de tecnologı́a se ejecutarán los distintos artefactos de software diseñados. La estrategia que se ha venido aplicado para ampliar el campo de acción de UML en el contexto de la arquitectura empresarial ha sido la definición de perfiles del lenguaje que están orientados a soportar ciertos dominios (en la sección 3.2.5 se analizan las técnicas que existen para extender un lenguaje, incluyendo el perfilamiento). Por ejemplo, en [34] definen un perfil de UML para modelar las reglas de negocio, expresándolas en términos de. 21.

(30) Punto de vista Empresarial. Información. Computacional. Ingenierı́a Tecnologı́a. Descripción Examina el sistema con respecto a su entorno, identificando los requerimientos de negocio, su alcance y su propósito. Tiene en cuenta las estructuras organizacionales que de alguna forma se relacionan con el sistema Se enfoca en la estructura de la información que manipula el sistema, en cómo ésta es modificada y en cómo ésta fluye a través del sistema Se enfoca en la descomposición funcional del sistema en objetos que interactúan a través de sus interfaces Se concentra en cómo es soportada la interacción distribuida entre los objetos del sistema Se concentra en los componentes de hardware y software que conforman el sistema. Table 2: Puntos de vista de RMD-ODP clases y modelando sus condiciones, conclusiones y acciones en diagramas de estado. El perfil conocido como UML4ODP [47] tal vez es el que más se enfoca en soportar la actividad de modelamiento de una arquitectura empresarial. Este perfil define los elementos necesarios para modelar los puntos de vista definidos en el estándar ISO RM-ODP (Reference Model for Open Distributed Processing), el cual “proporciona la especificación de un framework para el desarrollo de sistemas distribuidos basado en el concepto de puntos de vista”[13]. la tabla 2 resume los puntos de vista definidos en este estándar. Como se puede observar estos puntos de vista en conjunto proporcionan una visión holı́stica de la empresa, que no es posible modelar a través de los diagramas definidos en la especificación de UML. 3.1.4.2. BPMN. BPMN (Business Process Model Notation) es uno de los estándares administrados por el OMG (Object Management Group), su principal objetivo es proporcionar una notación para el modelamiento de procesos que sea fácil de entender para todos los actores del negocio: analistas de procesos, desarrolladores de software, alta gerencia, etc. De igual forma, el estándar busca cerrar la brecha que existe entre la sintaxis utilizada para diseñar procesos y la sintaxis utilizada para implementar estos procesos en un lenguaje ejecutable como. 22.

(31) BPEL4WS [49], a través de la definición de reglas de mapeo entre los elementos de estos lenguajes. Un modelo basado en BPMN refleja el flujo de actividades que tiene un proceso de negocio, los actores que intervienen en cada actividad, el flujo de mensajes que puede existir entre estos actores, los eventos que gobiernan el proceso (eventos de tiempo, de excepción, de condición, etc.), los datos que fluyen a través del proceso y los controles que dirigen el flujo del mismo (Condicionales sobre los datos del proceso, sincronización de flujos paralelos, etc.). Claramente BMPN está orientado a soportar el modelamiento de la dimensión de negocio de una arquitectura empresarial, especı́ficamente sobre el área de procesos. Sin embargo, estos activos de una empresa también interactúan con otros elementos del negocio que no están contemplados en este lenguaje. Por ejemplo, el BMM (Business Motivation Model) es otro estándar administrado por el OMG que proporciona un esquema para desarrollar, comunicar y manejar los planes de negocio en una forma organizada [28]. Este modelo establece a nivel general que una empresa define unos “fines” que quiere cumplir y unos “medios” que utiliza para llegar a los resultados deseados. El fin principal de una empresa es su visión, que se hace operativa a través del principal medio de la empresa que es la misión. La visión se especializa a través de metas cuantificadas con objetivos; y la misión se compone de cursos de acción que se expresan en términos de estrategias y tácticas. Estos cursos de acción se materializan en procesos de negocio, que a su vez son gobernados por la directivas del negocio, que se expresan en términos de reglas y polı́ticas del negocio. Finalmente, cada proceso de negocio es responsabilidad de una unidad organizacional. La figura 9 es un resumen de los principales elementos de negocio definidos en el BMM, donde se hace énfasis en las relaciones que tienen los procesos con los otros elementos. En este contexto se podrı́a decir que BPMN ofrece soporte a las relaciones que tiene un proceso con las unidades organizacionales, a través del concepto “Swimlane”’, el cual se define para modelar un proceso de forma particionada, a partir de las personas, roles o unidades organizacionales que participan en el [49]. Las reglas de negocio que guı́an el proceso se pueden soportar en el evento intermedio de condición que define BPMN, el cual. 23.

(32) Figure 9: Elementos de negocio asociados con los procesos según BMM - Fuente [28] hace referencia a un condición (regla de negocio) que se debe validar, más sin embargo no proporciona los elementos suficientes para modelar la regla. Las polı́ticas de negocio que gobiernan el proceso y los cursos de acción que materializa, no pueden ser mapeadas en ninguno de los elementos definidos en el lenguaje. Finalmente, en [49] se aclara que no se proporcionan elementos para modelar o integrar el lenguaje con especificaciones que modelen los sistemas de información que soportan los procesos, que modelen las reglas o las estrategias del negocio. 3.1.4.3. Archimate. Archimate es un lenguaje de descripción arquitectural (ADL) enfocado exclusivamente en modelar la arquitectura empresarial. Este lenguaje tiene más de cinco años de desarrollo por parte de un consorcio de empresas e institutos académicos de Holanda, cómo Novay [45] y el grupo de investigación en teorı́as para la ingenierı́a empresarial de The Radboud University Nijmegen [53]. La figura 10 proporciona una visión general de la estructura del lenguaje. Este fue diseñado para modelar la empresa utilizando una representación en capas, mediante la integración de conceptos del negocio, las aplicaciones o sistemas de software que lo soportan y la plataforma tecnológica subyacente. La capa del negocio incluye los productos y servicios proporcionados por la empresa 24.

(33) a sus clientes, como también los procesos del negocio que materializan estos productos y servicios. De igual forma, en esta capa se incluyen los roles y actores que se asignan a estos procesos y los objetos de negocio que son manipulados a través del ciclo de vida del proceso. La capa de aplicación soporta la capa del negocio, a través de servicios de aplicación que son proporcionados por componentes de software [51]. A nivel de aplicación también se tienen en cuenta las estructuras de datos manipuladas por las aplicaciones y las interfaces a través de las cuales es posible acceder a los servicios proporcionados por cada aplicación. Finalmente, la capa de tecnologı́a proporciona servicios de infraestructura que son soportados por artefactos tecnológicos, cómo servidores de aplicaciones o servidores de bases de datos. Estos servicios se intercomunican a través de una infraestructura de comunicaciones que también hace parte de esta capa.. Figure 10: Estructura de Archimate - Fuente [29] Además de la categorización en capas de los conceptos del lenguaje, Archimate proporciona otra dimensión de clasificación conocida como “aspectos”. A través de esta clasificación es posible separar los conceptos de cada capa en estructuras activas, de comportamiento y estructuras pasivas. El comportamiento básicamente está relacionado con los. 25.

(34) servicios que se proporcionan en cada capa y con los conceptos que materializan estos servicios, como los procesos de negocio, las funciones de negocio, las funciones de aplicación y los artefactos de tecnologı́a. Las estructuras activas están representadas por los conceptos que participan activamente en la ejecución de un concepto de comportamiento, por ejemplo los roles o actores asignados a un proceso o las aplicaciones que tienen asignadas funciones de aplicación. Finalmente, las estructuras pasivas representan los conceptos que se requieren para ejecutar un concepto de comportamiento, como las entidades de negocio que se manipulan durante el flujo de un proceso, o los productos que ofrece la empresa, junto con los contratos que los regulan. Este enfoque está sustentado en el principio que dice que “cada capa de la arquitectura empresarial puede ser expresada como un sistema dinámico, donde un sistema dinámico es cualquier sistema de eventos discretos en el cual uno o más sujetos (estructuras activas) despliegan cierto comportamiento, usando uno o más objetos (estructuras pasivas)”[40]. La estructura del lenguaje descrita en la figura 10 se detalla en un meta-modelo por cada una de las capas. Estos meta-modelos están documentados en el apéndice A. Uno de los aspectos más importantes de este lenguaje tiene que ver con la visión holı́stica que proporciona de la arquitectura empresarial, mediante la integración de conceptos de diferentes dominios. Aspecto que no es contemplado por los lenguajes descritos en las secciones anteriores. Esta integración está basada en la definición de un conjunto de relaciones entre los conceptos de los tres meta-modelos del lenguaje. Por ejemplo, la figura 11 refleja las relaciones que se definen entre los conceptos de la capa de negocio y los conceptos de la capa de aplicaciones. En este caso, un objeto de negocio puede tener una representación digital en un objeto de datos de la capa de aplicaciones. Un producto ofrecido por la empresa puede agregar servicios proporcionados por alguno de los componentes de aplicaciones, como por ejemplo el servicio de compra en lı́nea o el servicio de administración de información de clientes. Un elemento de comportamiento, como un proceso de negocio, puede hacer uso de los servicios de aplicaciones durante su ejecución. Un rol de negocio puede utilizar una interfaz de una aplicación, que para este caso es la interfaz de usuario que proporciona la aplicación, como una página web.. 26.

(35) Figure 11: Relaciones entre los conceptos de la capa de negocio y la capa de aplicaciones - Fuente [29] Además de la definición de los meta-modelos que representan las capas de la arquitectura y de la definición de las relaciones que existen entre los conceptos de cada dominio, Archimate define un conjunto de puntos de vista que pueden ser modelados utilizando los elementos del lenguaje. La figura 12 presenta los tipos de puntos de vista identificados por Archimate. Hay tres grandes clasificaciones:. Figure 12: Clasificación de puntos de vista según Archimate - Fuente [29]. • Puntos de vista de diseño: Están orientados a soportar el proceso de diseño de la arquitectura, desde modelos de alto nivel, como un diagrama de entidades de negocio, hasta modelos detallados, como la estructura de un proceso de negocio. • Puntos de vista de decisión: Su objetivo es soportar el proceso de toma de decisiones de negocio, haciendo énfasis en las relaciones que existen entre los diferentes dominios.. 27.

(36) Un ejemplo de este tipo de puntos de vista es un blue print de arquitectura, donde se hacen explicitas todas las decisiones que se toman en todos los dominios de la arquitectura. • Puntos de vista de información: Estos puntos de vista son útiles para comunicar a los stakeholders, de una forma amigable, las decisiones arquitecturales. Cada uno de estos puntos de vista puede contener información detallada de una sola capa y un solo aspecto de la arquitectura (Detallado), como el diagrama de un proceso o el diseño de una aplicación; o puede contemplar varias capas o aspectos (Coherencia), haciendo explicitas las relaciones entre los diferentes dominios, como el conjunto de aplicaciones utilizadas por un proceso; o pueden ofrecer una vista general de la arquitectura, que facilite la toma de decisiones, como un blue print de arquitectura. Intencionalmente, Archimate no incluye conceptos y relaciones para modelar otros aspectos de la arquitectura empresarial, como la motivación que hay en torno a la arquitectura (Objetivos, estrategias, motivadores, requerimientos, etc.), la evolución de la arquitectura (Cambios en el tiempo, estados actuales y futuros, etc.) o los aspectos relacionados con atributos de calidad (desempeño, costos, confiabilidad, etc.), ya que éste fue diseñado para incluir solo las relaciones y conceptos básicos que sirvan para propósitos generales del modelamiento de una arquitectura empresarial [29]. Sin embargo, al igual que UML, existen algunas técnicas de extensión que pueden ser aplicadas para mejorar el nivel de expresividad del lenguaje y ası́ soportar requerimientos adicionales desde diferentes dominios de la arquitectura empresarial. 3.1.4.4. ARMOR. ARMOR (A requirements Modeling Language For Enterprise Architecture) [51] es una extensión de Archimate creada para soportar el modelamiento de la motivación y los requerimientos que gobiernan una arquitectura empresarial. Este lenguaje proporciona a la estructura de Archimate un nuevo aspecto llamado “motivación”. Este aspecto incluye los dominios relacionados con los principios de una empresa, que se ven reflejados en su visión, misión, reglas o polı́ticas de negocio, con los stakeholders de la arquitectura, documentando 28.

(37) las preocupaciones que estos tienen y la evaluación que se hace sobre estas preocupaciones y con los objetivos y requerimientos que definen el alcance de la arquitectura. La figura 13 muestra el meta-modelo de ARMOR. El concepto “Meta” (“Goal”) es el centro del lenguaje, el cual representa un resultado deseado que debe ser materializado por la arquitectura empresarial, como por ejemplo reducir el costo de administración del inventario, o mejorar la calidad de la información que maneja la empresa. Las metas se especializan en “Metas Duras” (“Hard Goal”) y “Metas blandas” (“Soft Goal”). La primera clasificación define criterios claros y precisos que determinan el alcance de la meta, como por ejemplo, reducir el costo de administración del inventario en un 15% en los siguientes tres meses; mientras que los criterios para evaluar el segundo tipo de meta, por lo general son vagos o sujetos a interpretación [51], como por ejemplo, mejorar la satisfacción de los clientes. Entre las metas pueden existir relaciones de conflicto o de mutua contribución. Las metas entran en conflicto cuando los resultados esperados son contradictorios, un ejemplo serı́a una meta que busque reducir el presupuesto del departamento de TI, con otra que busque actualizar toda la plataforma tecnológica de la empresa. Las metas se pueden expresar en términos jerárquicos, es decir, partiendo de metas generales, hasta llegar a metas detalladas que aportan a la meta principal. Una empresa puede tener varias estructuras jerárquicas de metas de forma paralela, por ejemplo, una estructura puede iniciar con la meta general de mejorar la satisfacción de los clientes y ésta puede tener la sub-meta de implementar diferentes canales para atender los requerimientos de los clientes. Otra estructura puede iniciar con la meta general de incrementar el uso de tecnologı́as de información en los procesos de la empresa, y contar con una sub-meta que plantee la necesidad de implementar un canal web donde se implemente una estrategia de auto-servicio. Esta última meta contribuye positivamente a la meta planteada en la primera estructura, ya que a través de este canal se puede mejorar la satisfacción de los clientes. La expresión jerárquica de las metas esta soportada en el concepto “RefinementRelation”, ya que finalmente una sub-meta no es más que un refinamiento de una meta más abstracta. Este refinamiento puede ser obligatorio u opcional, es decir, todas las sub-metas deben cumplirse para lograr. 29.

(38) la meta principal (“AND-Refinement”) o al menos una sub-meta debe cumplirse (“ORRefinement”)[51]. Un requerimiento es el último nodo en la jerarquı́a de una meta, y se considera como el punto de integración con la estructura de Archimate, ya que éste es materializado por alguno de los conceptos de comportamiento de este lenguaje, cómo un proceso de negocio, una función de negocio o un servicio de negocio o de aplicación.. Figure 13: Meta-Modelo de ARMOR- Fuente [51] Otro dominio que incluye el lenguaje para expresar la motivación de la empresa, tiene que ver con los stakeholders. la figura 14 ilustra los conceptos que se tienen en cuenta en este dominio. Las preocupaciones de los stakeholders son identificadas y sobre estas preocupaciones se realiza una evaluación periódica, o cada vez que se presenta algún evento en particular [51], con el fin de identificar oportunidades, amenazas, debilidades o fortalezas al rededor de estas preocupaciones. A partir de esta evaluación, se definen las metas que están orientadas a dar solución a las preocupaciones planteadas por los stakeholders. 3.1.5. Herramientas de Arquitectura Empresarial. En esta sección se describen las capacidades que ofrecen las herramientas IBM System Architect y BizzDesign Architect con relación al modelamiento de la arquitectura empresarial.. 30.

(39) Figure 14: Meta-Modelo de Stakeholders- Fuente [51] En esta descripción se tienen en cuenta los lenguajes soportados por cada herramienta, las facilidades que ofrecen de personalización y especialmente de definición de puntos de vista de acuerdo a las preocupaciones de los stakeholders. 3.1.5.1. IBM System Architect. System Architect soporta una gran variedad de lenguajes de modelamiento para cada dominio de la arquitectura. A nivel de negocio tiene soporte de IDEF0, IDEF3 y BPMN para la especificación de procesos, a nivel de aplicaciones y tecnologı́a tiene soporte de UML 2.0 y a nivel de datos soporta IDEF1X y propone una notación para el manejo de diagramas de entidad-relación (ER). De igual forma, propone otras notaciones para modelar los principios (visión y misión) y motivadores de la empresa(metas y objetivos). Cada proyecto creado a través de la herramienta se almacena en una “enciclopedia”, la cual contiene diagramas, sı́mbolos, definiciones, propiedades y relaciones. Un diagrama está compuesto de sı́mbolos, cada uno de estos sı́mbolos tiene una definición subyacente, la cual tiene propiedades y relaciones con otras definiciones [2]. Por ejemplo, en un diagrama de procesos se utiliza un sı́mbolo para expresar un actividad del proceso, este sı́mbolo representa gráficamente la definición del concepto actividad que se tiene de BPMN y esta definición tiene asociados atributos como el nombre o la descripción y relaciones con otros conceptos del lenguaje,. 31.

(40) como eventos o gateways. La herramienta trae un meta-modelo predefinido donde se incluyen todos los elementos que pueden almacenarse en una enciclopedia. Es decir, se determinan previamente que diagramas se pueden modelar y que conceptos y relaciones se contemplan en cada diagrama [3]. Adicionalmente, se pueden definir relaciones entre conceptos de diferentes diagramas, como por ejemplo, una actividad de un diagrama de proceso de negocio está relacionada con un caso de uso de un diagrama de casos de uso. A pesar de proporcionar un mecanismo para adaptar el meta-modelo de la arquitectura, agregando nuevos diagramas, sı́mbolos y definiciones, éste no es muy amigable, ya que es necesario configurar los archivos de texto donde esta documentado el meta-modelo, lo cual no es una tarea fácil, teniendo en cuenta que el número de conceptos es bastante elevado. Finalmente, con el fin de expresar de forma más amigable las relaciones que existen entre los diferentes dominios de la arquitectura, System Architect proporciona herramientas de análisis que resumen estas relaciones en términos de matrices, donde se cruzan los elementos de cada dominio. 3.1.5.2. BizzDesign Architect. BizzDesign Architect [14] es una herramienta basada totalmente en el lenguaje Archimate. A través de esta herramienta es posible modelar todos los puntos de vista definidos en la especificación del lenguaje [29]. Un proyecto creado en la herramienta puede tener uno o más “modelos”, un modelo es el contenedor de los elementos que se utilizan en los puntos de vista, es decir, dentro del modelo se crean los conceptos que representan las diferentes capas de la arquitectura, como productos, procesos, actores, requerimientos, aplicaciones, datos, y en general todos los conceptos soportados en los meta-modelos de Archimate y de ARMOR. Al modelar un punto de vista se incluyen los elementos que existen en el modelo y se relacionan de acuerdo a la especificación definida para el punto de vista. De esta forma, en el modelo también se incluyen las relaciones diseñadas en los puntos de vista. Cada modelo es interpretado como la descripción completa de una arquitectura, por lo tanto es posible aplicar herramientas de análisis que proporciona BizzDesign Architect para identificar las. 32.

(41) diferencias entre dos arquitecturas (e.g., AS-IS Vs TO-BE). La estrategia definida para personalizar la herramienta está basada en el perfilamiento de los conceptos de los meta-modelos de Archimate. Este es uno de los mecanismos de extensión de lenguajes que se documentan en la sección 3.2.5. Básicamente se busca que los elementos existentes asuman roles distintos al rol para el que fueron definidos. Estos nuevos roles están caracterizados por un conjunto de atributos y relaciones que especifican como debe ser modelado el elemento cuando asume este rol. Sin embargo, al igual que en System Architect, esta personalización debe hacerse sobre archivos de texto, lo cual hace que esta también sea una tarea tediosa. Finalmente, la herramienta ofrece un lenguaje a través del cual es posible hacer consultas sobre el modelo, como por ejemplo, identificar las aplicaciones que están soportando un proceso. El resultado de estas consultas puede ser almacenado como un punto de vista de la arquitectura, lo cual facilita la definición de nuevos puntos de vista a partir de los elementos que ya existen en los meta modelos de Archimate.. 3.2. Model Driven Engineering. Model Driven Engineering (MDE) es un enfoque aplicado al ciclo de vida de desarrollo de sistemas de software, donde todo el proceso gira en torno a la construcción y explotación de un número de modelos interrelacionados que representan diferentes aspectos del sistema que se está desarrollando [21]. De acuerdo a [16] los objetivos de este enfoque incluyen la separación de las descripciones de negocio, de las implementaciones dependientes de una plataforma, es decir, que la definición del negocio no incluya términos de tecnologı́a, de tal forma que su implementación se pueda materializar en cualquier plataforma; la separación y descripción de diferentes aspectos de un sistema en términos de lenguajes de dominio especı́fico, es decir, que las diferentes preocupaciones que deben contemplarse en la construcción del sistema, como la seguridad, el monitoreo, o la transaccionalidad, puedan ser expresadas utilizando lenguajes diseñados pensando en el dominio de cada preocupación y no con lenguajes de propósito general; la forma de establecer relaciones entre estos lenguajes dentro de un framework global y la posibilidad de expresar transformaciones entre estos. 33.

(42) lenguajes. La figura 15 refleja los principios que gobiernan el enfoque MDE. Según [18] Estos principios se pueden resumir en dos afirmaciones: 1) La representación de cualquier tipo de sistema utilizando modelos y 2)la conformidad sintáctica de todo modelo con un metamodelo. De igual forma también se plantea que los modelos deben poder ser procesados de forma automática, aplicando un conjunto de operadores, donde uno de los principales operadores aplicados para procesar un modelo es la transformación de éste en términos de otro esquema de especificación. Por lo tanto, los elementos más importantes en torno a este enfoque tienen que ver con la noción de “modelo”, de “meta-modelo” y de “transformación de modelos”. A continuación se da una descripción de cada uno de estos elementos.. Figure 15: Principios de MDE - Fuente [18]. 3.2.1. Modelo. Un modelo en el contexto de MDE tiene dos propósitos, el primero es describir un sistema en términos de sus componentes y de las relaciones que existen entre estos, con el fin de analizar aspectos del sistema que tienen que ver con su estructura y comportamiento. El segundo propósito se centra en plantear una especificación que se debe seguir al momento de implementar un sistema; a través de dicha especificación se ilustran cuales son las restricciones a las que se debe someter el sistema, cuáles son sus componentes con sus atributos y relaciones y como se espera que interactúen bajo diferentes escenarios. Según [19] un modelo. 34.