1.- Fase de Diagnóstico: Corresponde a la identificación y descripción de la situación actual.

2.- Fase de Planificación de la Acción: Especifica las acciones que deben ser ejecutadas para mejorar el problema.

3.- Fase de Implementación de la Acción: Se implementa la acción planificada

4.- Fase de Evaluación: Después de ser completadas las acciones, los investigadores evalúan las salidas, utilizando técnicas apropiadas que aporten evidencia de la calidad de las acciones emprendidas.

5.- Fase de Especificación del Aprendizaje: en esta fase se reflexiona sobre los resultados de la fase de evaluación.

En esta sección se presenta una breve revisión de los conceptos fundamentales relacionados con el desarrollo de esta investigación.

• Arquitecturas Empresariales

A nivel empresarial existe una motivación conocida como Arquitectura Empresarial (AE) la cual promueve la integración de aplicaciones [6]. La AE se puede definir como un plan maestro de la organización con aspectos de planificación de negocio (objetivos, visión, estrategias); operaciones del negocio (estructura organizacional, procesos y datos); de la automatización y de la infraestructura tecnológica disponible (base de datos, redes) [11].

Una organización que cuente con su arquitectura empresarial, tiene a la mano la información necesaria para enfrentar los constantes cambios, avanzando de manera positiva en su agenda de modernización derrotando las barreras para el progreso. La arquitectura empresarial permitirá a la organización asegurar que su diseño y sus sistemas de información están alineados con la misión de la organización; servirá de guía en la toma de decisiones de desarrollos en SI (Sistemas de Información) y TI, promueve la interoperabilidad entre sistemas desarrollados , promueve la flexibilidad en la infraestructura de SI/TI para adaptarlas a nuevos requerimientos o necesidades de cambio imprevistas , cambios organizacionales así como promueve la longevidad y re-uso de los componentes de la infraestructura.

Existen frameworks o marcos de trabajo de AE, los cuales establecen un conjunto de condiciones, conceptos, valores y prácticas para modelar la realidad de las organizaciones [12], como ejemplos se pueden mencionar el Framework Empresarial de Zachman [1], TOGAF [2] , ArchiMate  [3][4] y el Enterprise Architecture Integration Framework(EAIF) [5][6]. El uso de estos frameworks se hace aun más relevante en aquellas organizaciones que pretenden ejecutar proyectos de integración, a fin de identificar el estado actual de los elementos involucrados (personas, procesos, sistemas, entre otros) y proponer distintos escenarios a partir de esta realidad.

• MDA

En el año 2000, la Object Management Group (OMG) [7] publicó un documento con el planteamiento de la Arquitectura Dirigida por Modelos (por sus siglas en Ingles, Model Driven Architecture) la cual se define como un enfoque para el desarrollo de sistema basado en la transformaciones de modelos. Este enfoque se basa en tres clase de niveles de abstracción que guían el desarrollo de la aplicación, estos son: CIM, PIM y PSM. Por su parte, el CIM constituye la vista del sistema independiente de la computación, el PIM representa la vista del sistema independiente de la plataforma y el PSM constituye la vista del sistema específica de una plataforma computacional. Con MDA, una vez que se ha desarrollado un modelo en determinado nivel, se puede derivar, automáticamente el resto de los modelos aplicando las correspondientes transformaciones. Todo esto sugiere una influencia directa en la productividad, portabilidad, interoperabilidad y mantenimiento de la aplicación.

• EAIF

El EAIF es un framework de arquitectura empresarial orientado a la integración, basado en el Modelo Conceptual de Integración de Brown [13] y las Vistas de Integración de Sandoe (backward, forward y upward ) [14]. Está formado por cuatro niveles: Procesos, Servicios, Mecanismos y Personas, los cuales corresponden con los procesos de negocio que intervienen en la integración, las aplicaciones empresariales que se adaptan a estos procesos, la implementación de los servicios requeridos y las personas que participan. Adicionalmente, las vistas de integración extienden los niveles de Procesos y Servicios. En cuanto al nivel de Mecanismos está compuesto por la Arquitectura de Software y la Tecnología de Información y Comunicación.

La versión original del EAIF contempla una correspondencia con los modelos de MDA y sus niveles: Personas, Procesos, Servicios y Mecanismos. Así mismo se han planteado propuesta de extensión con el enfoque SOA [15]. Es importante resaltar que en esta última versión del EAIF uno de los principales cambios es el cambio de nombre a la Clase Servicio por Aplicaciones, esto responde a la necesidad de evitar confusión con el concepto de Servicio manejado en el enfoque SOA.

En la Figura 1 se muestra un esquema completo de ambos enfoques (MDA y SOA) planteado en EAIF [6][15]. Se observa, como el CIM corresponde con los niveles Personas y Procesos, el PIM corresponde con el nivel de Aplicaciones. Con respecto al nivel de Mecanismos, la Arquitectura es parte el PIM ya que es una especificación de alto nivel. Y finalmente encontramos la Tecnología de Información es modelada por el PSM.

En esta sección se presentaran los resultados que se obtuvieron al aplicar cada una de las fases de la metodología descrita en la sección anterior.

Durante esta fase se identificó el contexto que enmarca al problema y se realizó la revisión bibliográfica de los principales conceptos relacionados a esta investigación.

En los últimos años, el tema de la integración de las aplicaciones de software ha ganado mayor atención de parte de las organizaciones que desean mantener y aumentar su nivel competitivo. Este tipo de integración involucra la combinación o fusión de las aplicaciones de software, que aún funcionan de manera independiente. Además, permite flexibilizar la comunicación entre las unidades de la organización y reducir la duplicación de esfuerzos [16]. En respuesta a esta necesidad, se han desarrollado frameworks como el de Zachman [1], TOGAF [2], ArchiMate [3][4] y el Enterprise Architecture Integration Framework (EAIF) [5][6], entre otros.

Adicionalmente, se presenta el enfoque de la Arquitectura Dirigida por Modelos (del inglés, Model Driven Architecture, MDA) la cual es una iniciativa de la OMG, que promueve el enfoque de desarrollo de software basado en la transformación sucesiva de modelos correspondientes a distintos niveles de abstracción desde el conceptual hasta la implementación [7]. Este enfoque persigue propiciar la portabilidad, productividad, reutilización, mantenimiento, integración, interoperabilidad y apoyo a la evolución de las aplicaciones de software adaptándose a los cambios en la plataforma tecnológica [17].

Con el surgimiento de nuevos enfoques, como es el caso de MDA, la utilidad y continuidad en el tiempo de cualquier herramienta en el campo de desarrollo de software, como lo son los frameworks de Arquitectura Empresarial, se ve afectada proporcionalmente al grado de su flexibilidad para adaptarse a estas nuevas tendencias tecnológicas. En este sentido, algunos de estos frameworks ya presentan extensiones o adaptaciones de los conceptos relacionados con la MDA, como una forma de garantizar su aplicabilidad a futuro, tales como TOGAF [8] y Zachman [9]. En este sentido, aunque EAIF posee ventajas, se hace necesario establecer mecanismos que faciliten su uso y lograr conservar su carácter competitivo con los otros frameworks.

En esta fase se describen el conjunto de actividades que se llevaron a cabo para cumplir con el objetivo planteado.

Rational 2004 [18] define que el CIM está conformado, entre otros, por el Modelo de Casos de Usos del Negocio [19]. También el Documento de Especificación de Requisitos de RUP puede ubicarse dentro del nivel CIM. Al comparar estos artefactos y los niveles Personas y Procesos del EAIF, podemos determinar la similitud entre los conceptos que ambos manejan. Por su lado, la Clase Persona del EAIF registra la información de las personas que pertenecen a la organización y el listado de aplicaciones a la cual tiene acceso, información que esta contenida en el Documento de Requisitos de RUP. De forma similar la clase Procesos del EAIF contempla la especificación de los procesos del negocio tales como, nombre del modelo de proceso, objetivo, elementos involucrados en el modelo de proceso, lista de políticas, reglas y restricciones utilizadas en el modelo de proceso en concordancia con la información especificada en el Modelo de Casos de Uso del Negocio. Esta correspondencia se ilustra gráficamente en la Figura 2.

Es así como basados en esta similitud identificada, se pueden establecer reglas de transformación para obtener la especificación de las clases Procesos y Persona del EAIF, partiendo de los Casos de Usos del Negocio y el Documento de Especificación de Requisitos en particular se utiliza la definición de los Actores del Negocio. Dichas reglas se presentan en la Tabla 1.

Las reglas de transformación planteadas en esta sección permiten obtener a partir de un conjunto de artefactos correspondientes al CIM de RUP, un CIM de EAIF.

3.2.2 Obteniendo la especificación del PIM de EAIF a través de artefactos RUP.

En relación a los artefactos generados en RUP aquellos que se consideran del nivel PIM se encuentra el Documento de Especificación de Requisitos en particular la definición de los requisitos no funcionales contenida en este, los Casos de Uso del Sistema y el Diagrama de Implementación. Por su parte según [6], el PIM del EAIF está compuesto por los niveles Aplicaciones y Mecanismos/Arquitectura de Software. El nivel de Aplicaciones describe la información relevante a los paquetes de software o servicios (del enfoque SOA) que posee la organización la cual puede ser obtenida a partir de los Casos de Usos del sistema y el Diagrama de Implementación. Por su parte la Arquitectura de Software como su nombre lo indica, especifica lo relacionado a los estilos arquitectónicos y patrones arquitectónicos utilizados en el diseño del sistema, las propiedades de calidad que la aplicación propicia. Toda esta información puede extraerse a partir del Documento de Especificación de Requisitos. En este sentido, podemos realizar una correspondencia entre los artefactos RUP y los niveles Aplicación y Arquitectura de Software de EAIF, tal como se muestra gráficamente en la Figura 3.

Las reglas de transformación para obtener la especi-ficación de las clases Aplicación y Mecanismos (Arquitectura) las cuales conforman el PIM del EAIF, partiendo de los artefactos RUP se describen en la Tabla II.

El PSM de RUP puede estar conformado por el Documento de Especificación de Requisitos y el Diagrama de Despliegue. En términos de EAIF el PSM está definido por el nivel de Mecanismo/Tecnología de Información. En este nivel, se especifica la Tecnología a utilizar para el desarrollo (Hardware, Software, Base de Datos, Comunicaciones). A partir del Documento Especificación de Requisitos se puede determinar los paquetes de software que se utilizara para el desarrollo de la aplicación, información relevante para el atributo software de la Clase Tecnología de Información. Así mismo del Diagrama de Despliegue provee información relevante al hardware, base de datos y comunicaciones requeridos en el desarrollo de la aplicación. La correspondencia entre los artefactos RUP y los niveles Aplicación y Arquitectura de Software de EAIF descrita anteriormente se muestra gráficamente en la Figura 4.

Luego de haber identificado el conjunto de artefactos relacionados al nivel PSM del EAIF se establecen reglas de transformación que permitan obtener la especificación de la Clase Mecanismos (Tecnología de Información) partiendo del documento de Especificación de Requerimiento y Diagrama de Despliegue tal como se muestra la Tabla III.

Las reglas de transformación planteadas en esta sección permiten obtener a partir de un conjunto de artefactos correspondientes al PSM de RUP, un PSM de EAIF.

En esta fase, se utilizan los resultados obtenidos en la sección anterior y se aplican al caso de estudio seleccionado.

En esta sección se describe la aplicación seleccionada como caso de estudio. El Help-Desk es una aplicación, la cual forma parte del Proyecto Link-all [20], la cual ha sido desarrollada con el enfoque SOA y Servicios Web.

Básicamente la aplicación cumple con los siguientes requerimientos:

• Gestión de incidentes: Incluye todo el manejo de los incidentes reportados por los usuarios, sus cambios de estado y su posterior resolución. Existe también un mecanismo inteligente de asignación de incidente a los diferentes técnicos.

• Comunicación en línea de usuarios y técnicos: Incluye un recurso por el cual los usuarios pueden chatear en línea con los técnicos.

• Generación de reportes: Incluye la generación de reportes gráficos de mediciones sobre incidentes. Se incluye aquí también los mecanismos de auto respuesta y envío de mensajería a los usuarios.

La herramienta Help Desk fue desarrollada haciendo uso de la metodología planteada por [21]. Parte de los resultados de estos artefactos se muestran en las siguientes secciones

Como parte del Documento de Especificación de Requisitos desarrollado para esta aplicación se encuentra que se han identificado tres actores principales: Administrador, es un actor que se encarga de gestionar y administrar los incidentes reportados; el Usuario es el actor encargado de reportar los Incidentes y el Técnico, el cual se encarga de encontrar las soluciones a los Incidentes reportados por los usuarios al Help Desk.

Para la aplicación Help Desk el modelo de casos de usos del Negocio consta de cinco casos principales a saber Transiciones, Ayuda en Línea, Reporte de Incidente, Acceso a base de Conocimientos y Alertas, tal como se ilustra en la Figura 5.

Del documento de Modelado de Negocio, se extrae la especificación del Caso de Uso Reporte de Incidente como se puede observar en la Figura 6.

Por restricciones de espacio, nos enfocamos a desarrollar la instanciación de las clases Personas y Procesos del EAIF, utilizando como insumo la información suministrada por artefactos antes presentados y aplicando las reglas de transformación (sección 3.2) propuestas para estas dos clases. Es así como podemos observar en la Figura 7 las instancias de la clase Persona, y en la Figura 8 instancia de la clase Proceso.

Basados en la correspondencia de RUP con MDA, se ha logrado relacionar un conjunto de artefactos de desarrollo de software (en los tres niveles planteados por la MDA) con los distintos niveles del EAIF. Es a partir de esta correspondencia, que sugerimos a una organización que posee documentación generada de RUP-MDA, utilizarla como insumo fundamental para iniciar la definición de su arquitectura empresarial aplicando las reglas de transformación propuestas.

Así mismo, se puede concluir que los Diagramas de Casos de uso del negocio aportan información requerida para realizar la especificación del nivel de Procesos en el EAIF. De la misma manera, a partir de la Especificación de Requisitos (actores del negocio) se puede instanciar la clase Personas del EAIF. Este análisis puede extenderse al resto de los diagramas (Casos de Usos del Sistema, Diagrama de Implementación y Diagrama de Despliegue) propuestos y obtener una versión de la arquitectura empresarial de la organización utilizando EAIF, considerando sólo los procesos involucrados en el desarrollo del sistema de software estudiado.

1. Establecer una correspondencia entre los niveles Personas, Procesos, Aplicaciones y Mecanismos del EAIF y el enfoque MDA puede contribuir significativamente en la elaboración de la especificación de una AE de cualquier organización, promoviendo la consistencia entre la información manejada por el departamento de TI y el arquitecto empresarial.

2. Las reglas de transformación planteadas permiten definir un moldeo CIM de EAIF a partir de un modelo CIM de RUP, de igual forma se obtiene un PIM de EAIF a través de un PIM de RUP y finalmente se puede generar un PSM de EAIF a partir de un PSM de RUP.

3. Con este planteamiento EAIF se convierta en una herramienta para facilitar y motivar al mismo tiempo, a las organizaciones a alinear la TI con la visión de la organización, creando una arquitectura empresarial base, la cual pudiera ser enriquecida en distintas iteraciones. A largo plazo, las organizaciones contarían con una AE, para facilitar la toma de decisiones estratégicas efectivas para propiciar su competitividad en el mercado.

4. Como trabajo futuro, se considera el desarrollo de un proyecto para generar las herramientas CASE de soporte para la automatización de las reglas de transformación que en esta investigación se plantean y de esta manera facilitar la aplicación de las mismas.

5. Así mismo se considera importante evaluar en un futuro la bidireccionalidad de la relación establecida entre los artefactos de RUP y las clases de EAIF, considerando el caso, cuando una organización cuente con una AE especificada con EAIF, y pueda utilizar esta especificación en el desarrollo de aplicaciones de software siguiendo un proceso de desarrollo.

1. Zachman J. "The Zachman Framework: The Oficial Concise Definition". Disponible desde http://www.zachmaninternational.com/index.php/home-article/13#maincol. Consultado en Diciembre 2010.         [ Links ]

2. The Open Group, The Open Group Architectural Framework (TOGAF). "Enterprise Edition". The Open Group, Reading, UK, 2006. The Open Group in association with Object Management Group http://www.opengroup.org/togaf/.        [ Links ]

3. Página official de ArchiMate. http://www.opengroup.org/archimate/doc/ts_archimate        [ Links ]

4. Enterprise Architecture Development and Modelling Combining TOGAF and ArchiMate http://www.via-nova-architectura.org/files/magazine/Lankhorst.pdf        [ Links ]

5. Losavio F. et al. Experimenting with the Expressive Power of an Enterprise Architecture Framework. TEAA 2006. Berlin. LNCS 4473. pp 255-269.2007.         [ Links ]

6. Ortega D. Arquitecturas Empresariales. Universidad Central de Venezuela. Tesis Doctoral. 2006.         [ Links ]

7. Object Management Group. Model Driven Architecture. Disponible desde http://www.omg.org/mda/. Consultado en Diciembre 2010         [ Links ]

8. The Open Group in association with Object Management Group. TOGAF ADM and MDA. May 2004.         [ Links ]

9. Object Management Group. The Zachman Framework and the OMG's Model Driven Architecture. Septiembre 2003. Disponible desde http://www.omg.org/mda/mda_files/09-03-WP_Mapping_MDA_to_Zachman_Framework1.pdf Consultado en Mayo 2010         [ Links ]

10. Baskerville, R. Investigating Information Systems with Action Research. Communications of the Associationfor Information Systems. Octubre, 1999.         [ Links ]

11. Schekkerman J. How to survive in the jungle of Enterprise Architecture Frameworks. ISBN 1-4120-1607. Segunda Edición. TRAFFORD. 2004         [ Links ]

12. O'Rourke C., Fishman N., Selkow W. Enterprise Architecture Using the Zachman Framework. Thomson Course Technology. 2003.        [ Links ]

13. Brown A., Crnery D., Morris E., Smith D., Zarella P. Principles of Case Tool Integration. Software Engineering Institute. Oxford University Press. 1994.         [ Links ]

14. Sandoe K., Corbitt G., Boykin R. Enterprise Integration. California State University, Chico. John Wiley & Sons, Inc.2001.         [ Links ]

15. Ortega, D. Uzcategui, E. Guevara, M.M. Enterprise Architecture and Web Services. ICIW '09. Venice/Mestre. May 2009. pp. 24 – 29.         [ Links ]

16. Turban E., Rainer K., Potter R. Introduction to Information Tecnology. John Wiley & Sons, Inc. 2001         [ Links ]

17. Czarnecki K., Helsen S. Classification of Model Transformation Approaches. OOPSLA. Workshop on Generative Techniques in the Context of Model-Driven Architecture. University of Waterloo. Canada, 2003.         [ Links ]

18. Rational Software Corporation. Tational Unified Process (RUP) (Versión 2004.06.00). New York. IBM Rational Software Corporation, 2004.         [ Links ]

19. Vargas X., Pérez M. Arquitectura para un CRM aplicando MDA. Universidad Simón Bolívar. 2007.         [ Links ]

20. Proyecto Link-all, Programa @lis, Unión Europea. http://www.fing.edu.uy/inco/cursos/ingsoft/pis/memoria/experiencia2005/material05/memoriaOOgrupo5.htm. Consultado Marzo 2009.         [ Links ]

21. Delgado A. Metodología de desarrollo para aplicaciones con enfoque SOA (Service riented Architecture). Tesis de Maestría. Instituto de Computación – Facultad de Ingeniería. Universidad de la República. Montevideo, Uruguay, 2007.        [ Links ]