ARTÍCULOS

 

Diseño y Validación de Arquitecturas de Aplicaciones Empresariales

Design and Validation of Enterprise Application Architectures

 

Armando Cabrera ¹, José Carrillo², Marco Abad³, Danilo Jaramillo⁴, Freddy Romero ⁵,

^{1, 3,4,5} Universidad Técnica Particular de Loja, Campus UTPL, 1101608, Loja, Ecuador. E-mail: aacabrera@utpl.edu.ec, mpabad@utpl.edu.ec, djaramillo@utpl.edu.ec, fromero@utpl.edu.ec

² Universidad Politécnica de Madrid, Montegancedo, 28040 Madrid, España. E-mail: jcarrillo@fi.upm.es

 

RESUMEN

El presente trabajo muestra el proceso de diseño y validación de arquitecturas de aplicaciones empresariales utilizando el método de desarrollo arquitectónico ADM-TOGAF y un lenguaje de descripción arquitectónica ADL. En el proceso fue fundamental el levantamiento de la arquitectura de negocio en base a la definición de la estructura y  procesos de negocio organizacionales para su posterior adaptación con el  modelo “4 + 1” de Kruchten para la representación del estado actual y el estado futuro de la arquitectura de aplicaciones de acuerdo a los requerimientos definidos en la iteración de capacidad arquitectónica del ADM. Como resultado se obtuvo una arquitectura de aplicaciones orientada a servicios – SOA - contemplando el uso de un bus de servicios empresariales ESB¹. La arquitectura fue implementada en código Java en una abstracción de alto nivel que permitió su posterior diseño y validación utilizando el ADL Sonargraph Architect.

Palabras-clave: Arquitectura de Aplicaciones, Arquitectura de Negocio TOGAF, ADM, Arquitectura Empresarial, “Vistas 4+1”, SOA, ESB.

 

ABSTRACT

This work presents the results of the process of design and assessment of the enterprise applications using the Architectural Description Method ADM-TOGAF and an Architectural Description Language ADL. In order to get the results, a fundamental concern is getting the business architecture based on the structure and business process and it’s adaptation to Kruchten´s  4+1 architectural model, that was used for representing the actual and future state of the applications architecture according to the requirements obtained during the ADM’s architecture capability iteration.  As a result we have a SOA based applications architecture considering the use of ESB. The architecture model was implemented in Java code within a high level ESB – Enterprise Service Bus abstraction that allows it´s future design and validation using the ADL Sonargraph Architect tool.

Keywords: Applications Architecture, Business Architecture, TOGAF, Enterprise Architecture, “4+1”, SOA, ESB.

 

1. Introducción

El uso correcto de las herramientas tecnológicas más conocidas de Infraestructura Tecnológica (IT) representa una ventaja competitiva para las empresas, que implica una óptima gestión entre los objetivos de negocio y la IT. El enfoque tradicional es mantener separada gestión de IT con la gestión de negocio, lo cual ocasiona problemas de integración, adaptación e interoperabilidad entre aplicaciones de software, debido al constante cambio del negocio, las condiciones del mercado y a la falta de integración entre el negocio e IT.

El diseño de una Arquitectura Organizacional (AO) va más allá del diseño asociado con la Arquitectura de Sistemas de Información (ASI) (Crespo, 2014) Su inclusión tiene como objetivo ampliar el campo de utilización de la Arquitectura Empresarial (AE), dejando de ser un instrumento para el desarrollo exclusivo de sistemas de información y convertirse en una herramienta para el desarrollo de las organizaciones (Gama, Silva, Caetano, & Tribolet, 2006). La arquitectura de negocio (AN) describe como una organización opera funcionalmente, en este sentido define y describe los procesos y objetivos de  negocio necesarios para la implantación de la estrategia organizacional (Crespo, 2014).

La Arquitectura empresarial (AE) en contraste con  el enfoque tradicional propone la integración entre el negocio y la infraestructura tecnológica. Para la correcta aplicación de la AE existen marcos de arquitectura empresarial como Open Group Architecture Framework (TOGAF),  el cual incluye el Método de Desarrollo de la Arquitectura (ADM) que comprende: guías, técnicas y modelos de referencia. Las principales características de TOGAF son su aplicabilidad a diferentes contextos empresariales y su adaptabilidad con diferentes marcos de referencia que se basan entregables específicos, como el Modelo “4+1” (Kruchten, 1995).

El presente estudio se aplicó en el Grupo Empresarial Monterrey (GEM), que es uno de los principales ingenios azucareros del Ecuador, ubicado al sur del país en la provincia de Loja, cantón Catamayo. Fundado el año de 1959. Actualmente cuenta con más de 1000 trabajadores  los cuales cumplen sus funciones de forma distribuida las veinticuatro (24) horas al día.

Actualmente la empresa se encuentra en un proceso de trasformación empresarial para lo cual se desarrolló con diferentes grupos de trabajo tomando como referencia las iteraciones arquitectónicas y las fases definidas en ADM-TOGAF.

 

2. Arquitectura de Aplicaciones en en Contexto Empresarial

La arquitectura de aplicaciones (AA) define las aplicaciones necesarias para la gestión de la información del negocio (Vasconcelos, Sousa, & Tribolet, 2003). Los sistemas de información deben soportar la disponibilidad y mantenimiento del flujo de información integrada a través de la empresa, para que esté disponible en cantidad y calidad necesarias (Crespo, 2014). Por lo tanto la construcción de la AA es esencial para derivar el componente tecnológico en el que se especifiquen las principales tecnologías que serán utilizadas para el diseño de la infraestructura de implementación de los SI empresariales (Vasconcelos et al., 2003).

La arquitectura empresarial implica la organización lógica de los procesos de negocio y la infraestructura tecnológica (IT) de una empresa (Ross, Weill, & Robertson, 2006). (Ver figura 1)

 

 

TOGAF, es un Framework de Arquitectura Empresarial, el cual posee un método detallado para el desarrollo de la AE dentro de una empresa, y un conjunto de herramientas de apoyo, para la aceptación, producción, uso y mantenimiento de la arquitectura (The Open Group, 2009).

ADM es un método flexible, ya que permite su acoplamiento a necesidades específicas. Una de las actividades previas a la aplicación del ADM es adaptarlo a las circunstancias de la empresa. Proceso que incluyó la implementación de un ciclo arquitectónico a través de ADM, el que se fundamentó en la evaluación del nivel de madurez de la empresa para implementar la arquitectura empresarial. Las fases necesarias para el desarrollo del trabajo arquitectónico y el orden de dichas fases, se modifican de acuerdo a lo que sea requerido (The Open Group, 2009).

ADM, sugiere cuatro (4) ciclos de iteraciones que permiten la definición arquitectónica como se muestra en la figura 2.  A continuación se presenta una descripción de cada iteración:

• Iteraciones de capacidad. Apoya la creación y la evolución de la capacidad arquitectónica. Actividades que involucran la definición de propósitos, principios, alcance, visión y gobernanza de la Arquitectura Empresarial.
• Iteraciones de desarrollo. Facilita la creación del contenido arquitectónico de manera cíclica o por integración de las fases.
• Iteraciones de la Planificación de Transición. Apoya la creación de hojas de ruta para cambios formales en una arquitectura definida.
• Iteraciones de Gobernanza Arquitectónica. Permite gobernar las actividades referentes a los cambios potenciales a implementar en la arquitectura objetivo.

3. Propuesta de implementación de la arquitectura de aplicaciones

El proyecto se desarrolló en varios grupos de trabajo quienes tenían a su cargo el desarrollo de cada una de las fases del ADM, es necesario resaltar que, para que la presente propuesta se pueda llevar a cabo se trabajó específicamente en la iteración de desarrollo en la fases B (Cabrera, Carrillo, Abad, Jaramillo, & Gomez, 2015) – Arquitectura de Negocio y C – Arquitectura de Sistemas de Información (Arquitectura de Datos – Arquitectura de Aplicaciones).

Un proyecto de AE define una forma secuencial de fases que se deben seguir de  manera formal para asegurar el éxito del proyecto, es por esto que es fundamental que la arquitectura del negocio sea levantada previo al inicio de las actividades de la Arquitectura de Sistemas de Información, desde una perspectiva o vista de procesos que permita determinar el modelo empresarial desde varios aspectos o perspectivas, como la vista estratégica de la organización , la vista de procesos, la vista de información, la vista de aplicaciones y la vista tecnológica (Crespo, 2014).

La vista de procesos de negocio es la más importante de un modelo empresarial, debido a que esta muestra los flujos de actividades, así como sus entradas y salidas que se constituyen en la representación fidedigna de los procesos actuales y que podrían ser utilizados como apoyo en las tareas operacionales y de gestión que permitan tomar partido de las capacidades de captura, representación y distribución del conocimiento organizacional y que puedan ser transmitidas hacia las otras vistas organizacionales como por ejemplo la arquitectura de sistemas de información en la vista de aplicaciones. (Castela, N., Dias, P., Zacarias, M., & Tribolet, 2013)

La arquitectura de aplicaciones permitió identificar los sistemas y aplicaciones que son relevantes de la empresa, encargadas de gestionar la información necesaria para apoyar la ejecución de las funciones del negocio de una manera ordenada y óptima (Ross et al., 2006). En las tablas 1 y 2 se presentan los objetivos y pasos planteados por ADM-TOGAF en la fase de arquitectura de aplicaciones.

 

 

El marco de contenidos TOGAF propone un conjunto de artefactos para la Fase C-Arquitectura de Aplicaciones. Ver figura 3

 

 

Así mismo el marco de contenidos propone los entregables como salidas que representan los resultados de la fase (Ver figura 4).

 

 

La arquitectura de aplicaciones es una vista de alto nivel de los componentes de una aplicación y permite la toma de decisiones a nivel estratégico. La IEEE ( ISO/IEC/IEEE 42010, 2011) define a la arquitectura de sistemas/aplicaciones como “Conceptos fundamentales o propiedades en un ambiente determinado. Las propiedades como elementos y relaciones. Los conceptos relacionados con principios de diseño y evolución.”

El modelo de vistas “4+1” (ver figura 5), es un modelo para la  representación sistemas/aplicaciones de software. La representación del software muestra las necesidades o preocupaciones de los interesados de la aplicación. Las vistas son cuatro (4): vista lógica, vista de procesos, vista de desarrollo y vista de despliegue/física; más casos de uso.

 

 

• Vista Lógica: Se basa en la descomposición orientada a objetos, muestra diagramas de clases que soporta los requerimientos funcionales que brinda la aplicación.
• Vista de Procesos: Muestra los requerimientos no-funcionales de la aplicación, tales como rendimiento, integración y disponibilidad. Muestra como las unidades de ejecución se comunican entre sí.
• Vista de Desarrollo: Muestra la organización de los módulos en el ambiente de desarrollo. Como el software es empaquetado en pequeñas unidades para el desarrollo.
• Vista de Despliegue: Considera requerimientos no-funcionales tales como disponibilidad, rendimiento, escalabilidad. Muestra los elementos de red necesarios para el soporte la solución de software, como nodos, procesadores, servidores, computadoras.

 

3. Resultados

Para el desarrollo del estudio se tomó como referencia los entregables obtenidos en la iteración de capacidad arquitectónica – Fase Preliminar – Fase Visón Arquitectónica y en la iteración de desarrollo –Fase Arquitectura de Negocio- ADM TOGAF.

Las vistas arquitectónicas se obtuvieron directamente de los interesados IT de la empresa, por medio de reuniones presenciales y en base a documentación proporcionada por los mismos. 

La infraestructura tecnológica que posee actualmente el GEM es un conjunto de sistemas heredados los cuales presentan distintas limitaciones relacionadas con la integración y escalabilidad e interoperabilidad. Los sistemas heredados y su tecnología actualmente son obsoletos (Seacord, R. C., Plakosh, D., & Lewis, 2003).

En el análisis y definición de la arquitectura de línea base, se pudo encontrar dos tipos de aplicaciones: aplicaciones que interactúan con dispositivos físicos (hardware) como sensores y actuadores; y aplicaciones de software en general. Los sensores y actuadores forman parte de un sistema basado en un esquema de control avanzado de fábrica debido un proceso de automatización industrial. (Campoy, n.d.)

Los sistemas heredados están desarrollados bajo una arquitectura cliente/servidor básica, la cual se muestra en la  figura 6.

 

 

Los artefactos arquitectónicos definidos para la fase de Sistemas de Información –ADM TOGAF- se desarrollaron una vez definida la línea base de la arquitectura de aplicaciones representada con el modelo de “4+1.

La tabla 3 muestra la relación entre las vistas “4+1 y los artefactos arquitectónicos correspondientes a la fase de Sistemas de Información.

 

 

En la capa de seguridad propuesta se contempla la implementación de OpenLdap, el cual es un servidor que implementa LDAP (Lightweight Directory Access Protocol), mismo que mantiene un alto grado de cumplimiento de estándares y es el servidor de directorios de código abierto más rápido en el mercado.

El Bus Empresarial de Servicios (ESB) (Schmidt, Hutchison, Lambros, & Phippen, 2005) permitirá la orquestación de los servicios entre las aplicaciones con la finalidad de integrar de sistemas empresariales. En la capa de seguridad se gestiona la autenticación de usuarios y la gestión de excepciones.

La representación y validación de la arquitectura se realizó a través  Sonargraph-Architect (Sonargraph, n.d.), herramienta ADL que  permite evaluar y gestionar la arquitectura  propuesta con un plugin del IDE Eclipse. Evaluar la arquitectura involucra implementar código Java con la abstracción de alto nivel de una solución. La implementación contiene las principales especificaciones de la arquitectura “TO-BE”.

La herramienta brinda un conjunto de funcionalidades de las cuales se usó únicamente las necesarias para la evaluación de la arquitectura a través de la Vista de exploración, Vista Lógica, Vista de la Arquitectura y el Dashboard.

Los requerimientos arquitectónicos se los define mediante métricas y en relaciones entre capas. La definición de las capas con sus relaciones se las muestra en la figura 8.

 

 

 

La vista de exploración de la Vista Lógica (figura 9), nos muestra las relaciones entre las capas, paquetes, y clases de la solución. En caso de que exista un incumplimiento a los requerimientos arquitectónicos de diseño, las relaciones se pintan de color rojo y de verde si no existe incumplimiento.

 

 

La figura 10, muestra un listado de los resultados de la evaluación de la arquitectura. El código sometido a evaluación es un archivo comprimido con la extensión “.war” de un proyecto Web-Java (Oracle, n.d.). Se puede ver que no existen violaciones a nivel arquitectónico. En la sección tareas se listan las asignaciones por parte del arquitecto hacia el grupo de desarrolladores. Las asignaciones se muestran en eclipse como advertencias.

4. Conclusiones

La aplicación del ADM-TOGAF conduce a una empresa hacia un nuevo esquema de gestión empresarial en donde los objetivos estratégicos de negocio identificados en la arquitectura del negocio se encuentran alineados con la arquitectura de aplicaciones. Las guías brindadas por ADM-TOGAF adaptadas al nivel de madurez de la empresa permiten definir de manera eficiente arquitectura de sistemas de información. La arquitectura de negocio es fundamental para proyectos de transformación empresarial  debido a que comprime las funcionalidades y modelos de información, y su relación con la administración y las estructuras organizacionales de negocio. El uso del modelo de Kruchten “4+1 views” en adaptación con el Método de definición Arquitectónica  - ADM de TOGAF apoya la creación de la Arquitectura Línea Base y la Arquitectura Futura, debido a que representa una abstracción del negocio a través de diferentes vistas arquitectónicas que son gestionadas por escenarios empresariales definidos en casos de uso .

La adaptación de ADM-TOGAF con el modelo 4+1 de Kructhen fue fundamental para la definición de la arquitectura de aplicaciones empresariales, y de acuerdo a las características del caso de estudio planteado se definió trabajar con un estilo arquitectónico orientada a servicios (SOA) utilizando un ESB para lograr características de robustez y extensibilidad en la estructura arquitectónica de aplicaciones, permitiendo asumir los requerimientos del negocio para  soportar la integración de aplicaciones empresariales como Bizagi (BPM) y Apache Ofbiz (ERP).

Dadas las características de modelado que plantea el modelo 4+1 de Kructhen, la validación de la arquitectura aplicaciones se realizó sin contratiempos, debido a que esta se desarrolló a nivel de diseño y código de implementación a través del ADL SONARGRAPH, esto permitió la obtención de métricas para la evaluación de los diferentes niveles de implementación del estilo arquitectónico definido. Cabe resaltar que los ADL´s no realizan la validación de los sistemas empresariales como tal, se enfocan en la infraestructura de implementación de la arquitectura de aplicaciones definida en la vista del desarrollo y despliegue del modelo del modelo 4+1

 

Referencias

Cabrera, A., Carrillo, J., Abad, M., Jaramillo, D., & Gomez, J. (2015). Definition and implementation of the Enterprise Business Layer through a Business Reference Model, using the architecture development method ADM-TOGAF. Springer.

Campoy, P. (n.d.). “División De Ingeniería de Sistemas y Automática-UPM,.” Retrieved March 09, 2015, from http://www.disam.upm.es/~campoy/Pascual_Campoy/teaching_files/1_introduccion_al_control_de_procesos.ppt.pdf.

Castela, N., Dias, P., Zacarias, M., & Tribolet, J. (2013). Atualização Colaborativa do Modelo de Processos de Negócio. RISTI - Revista Ibérica de Sistemas e Tecnologias de Informação, (12), pp. 33–47. doi: 10.4304/risti.12.33-47

Crespo, P. J. D. A. (2014). Construção de Sistemas Integrados de Gestão para Micro e Pequenas Empresas. RISTI - Revista Ibérica de Sistemas e Tecnologias de Informação. doi: 10.17013/risti.15.35-49        [ Links ]

Gama, N., Silva, M. M. Da, Caetano, A., & Tribolet, J. (2006). Integrar a arquitectura organizacional na arquitectura empresarial. 7^a Conferência Da Associação Portuguesa de Sistemas de Informação (CAPSI 2006), 11. Retrieved from http://dspace.esta.ipt.pt/dspace_esta/bitstream/1234/3481/1/3814.pdf

International Organization Of Standardization. (2011). ISO/IEC/IEEE 42010:2011 - Systems and software engineering -- Architecture description. ISOIECIEEE 420102011E Revision of ISOIEC 420102007 and IEEE Std 14712000, 2011, pp. 1–46. doi:10.1109/IEEESTD.2011.6129467

Kruchten, P. (1995). The 4+ 1 view model of architecture. Software, IEEE, November 1, 9. doi:10.1109/52.469759

Oracle. (n.d.). Oracle Help Center. Retrieved March 20, 2015, from http://docs.oracle.com/javaee/6/tutorial/doc/bnaby.html.

Ross, J. W., Weill, P., & Robertson, D. C. (2006). Enterprise Architecture as Strategy - Creating a Foundation for Business Execution. Center for Infor mation Systems Research, MIT (pp. 1–234). doi:10.1016/S0923-4748(08)00049-0

Schmidt, M.-T., Hutchison, B., Lambros, P., & Phippen, R. (2005). The Enterprise Service Bus: Making service-oriented architecture real. IBM Systems Journal, 44, pp. 781–797. doi:10.1147/sj.444.0781

Seacord, R. C., Plakosh, D., & Lewis, G. A. (2003). Modernizing legacy systems: software technologies, engineering processes, and business practices. Addison-Wesley Professional.         [ Links ]

Sonargraph. (n.d.). Sonargraph. Retrieved March 20, 2015, from https://www.hello2morrow.com/products/sonargraph/architect.

The Open Group. (2009). TOGAF Version 9. Architecture (p. 778). Retrieved from http://books.google.com/books?hl=en&lr=&id=dNIf8TZaylcC&oi=fnd&pg=PT2&dq=TOGAF+Version+9&ots=W6dnwd5wtj&sig=C4emZBzdp5pkoMOeE9sy1FtaYX4

Vasconcelos, A., Sousa, P., & Tribolet, J. (2003). Information System Architectures: Representation, Planning and Evaluation. Proceedings of International Conference on Computer, Communication and Control Technologies Orlando, USA, 1, pp. 78–84. Retrieved from http://www.iiisci.org/Journal/CV$/sci/pdfs/P445853.pdf

 

Recebido / Recibido: 27/03/2015

Aceitação /Aceptación: 18/09/2015

 

NOTAS

¹ ESB – Enterprise Service Bu