Printer Friendly

Design and validation of enterprise application architectures/Diseno y validacion de arquitecturas de aplicaciones empresariales.

1. Introduccion

El uso correcto de las herramientas tecnologicas mas conocidas de Infraestructura Tecnologica (IT) representa una ventaja competitiva para las empresas, que implica una optima gestion entre los objetivos de negocio y la IT. El enfoque tradicional es mantener separada gestion de IT con la gestion de negocio, lo cual ocasiona problemas de integracion, adaptacion e interoperabilidad entre aplicaciones de software, debido al constante cambio del negocio, las condiciones del mercado y a la falta de integracion entre el negocio e IT.

El diseno de una Arquitectura Organizacional (AO) va mas alla del diseno asociado con la Arquitectura de Sistemas de Informacion (ASI) (Crespo, 2014) Su inclusion tiene como objetivo ampliar el campo de utilizacion de la Arquitectura Empresarial (AE), dejando de ser un instrumento para el desarrollo exclusivo de sistemas de informacion y convertirse en una herramienta para el desarrollo de las organizaciones (Gama, Silva, Caetano, & Tribolet, 2006). La arquitectura de negocio (AN) describe como una organizacion opera funcionalmente, en este sentido define y describe los procesos y objetivos de negocio necesarios para la implantacion de la estrategia organizacional (Crespo, 2014).

La Arquitectura empresarial (AE) en contraste con el enfoque tradicional propone la integracion entre el negocio y la infraestructura tecnologica. Para la correcta aplicacion de la AE existen marcos de arquitectura empresarial como Open Group Architecture Framework (TOGAF), el cual incluye el Metodo de Desarrollo de la Arquitectura (ADM) que comprende: guias, tecnicas y modelos de referencia. Las principales caracteristicas de TOGAF son su aplicabilidad a diferentes contextos empresariales y su adaptabilidad con diferentes marcos de referencia que se basan entregables especificos, como el Modelo "4 + 1" (Kruchten, 1995).

El presente estudio se aplico en el Grupo Empresarial Monterrey (GEM), que es uno de los principales ingenios azucareros del Ecuador, ubicado al sur del pais en la provincia de Loja, canton Catamayo. Fundado el ano de 1959. Actualmente cuenta con mas de 1000 trabajadores los cuales cumplen sus funciones de forma distribuida las veinticuatro (24) horas al dia.

Actualmente la empresa se encuentra en un proceso de trasformacion empresarial para lo cual se desarrollo con diferentes grupos de trabajo tomando como referencia las iteraciones arquitectonicas 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 gestion de la informacion del negocio (Vasconcelos, Sousa, & Tribolet, 2003). Los sistemas de informacion deben soportar la disponibilidad y mantenimiento del flujo de informacion integrada a traves de la empresa, para que este disponible en cantidad y calidad necesarias (Crespo, 2014). Por lo tanto la construccion de la AA es esencial para derivar el componente tecnologico en el que se especifiquen las principales tecnologias que seran utilizadas para el diseno de la infraestructura de implementacion de los SI empresariales (Vasconcelos et al., 2003).

La arquitectura empresarial implica la organizacion logica de los procesos de negocio y la infraestructura tecnologica (IT) de una empresa (Ross, Weill, & Robertson, 2006). (Ver Figura 1)

TOGAF, es un Framework de Arquitectura Empresarial, el cual posee un metodo detallado para el desarrollo de la AE dentro de una empresa, y un conjunto de herramientas de apoyo, para la aceptacion, produccion, uso y mantenimiento de la arquitectura (The Open Group, 2009).

ADM es un metodo flexible, ya que permite su acoplamiento a necesidades especificas. Una de las actividades previas a la aplicacion del ADM es adaptarlo a las circunstancias de la empresa. Proceso que incluyo la implementacion de un ciclo arquitectonico a traves de ADM, el que se fundamento en la evaluacion del nivel de madurez de la empresa para implementar la arquitectura empresarial. Las fases necesarias para el desarrollo del trabajo arquitectonico 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 definicion arquitectonica como se muestra en la Figura 2. A continuacion se presenta una descripcion de cada iteracion:

* Iteraciones de capacidad. Apoya la creacion y la evolucion de la capacidad arquitectonica. Actividades que involucran la definicion de propositos, principios, alcance, vision y gobernanza de la Arquitectura Empresarial.

* Iteraciones de desarrollo. Facilita la creacion del contenido arquitectonico de manera ciclica o por integracion de las fases.

* Iteraciones de la Planificacion de Transicion. Apoya la creacion de hojas de ruta para cambios formales en una arquitectura definida.

* Iteraciones de Gobernanza Arquitectonica. Permite gobernar las actividades referentes a los cambios potenciales a implementar en la arquitectura objetivo.

3. Propuesta de implementacion de la arquitectura de aplicaciones

El proyecto se desarrollo en varios grupos de trabajo quienes tenian 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 trabajo especificamente en la iteracion de desarrollo en la fases B (Cabrera, Carrillo, Abad, Jaramillo, & Gomez, 2015)--Arquitectura de Negocio y C--Arquitectura de Sistemas de Informacion (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 exito 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 Informacion, desde una perspectiva o vista de procesos que permita determinar el modelo empresarial desde varios aspectos o perspectivas, como la vista estrategica de la organizacion, la vista de procesos, la vista de informacion, la vista de aplicaciones y la vista tecnologica (Crespo, 2014).

La vista de procesos de negocio es la mas importante de un modelo empresarial, debido a que esta muestra los flujos de actividades, asi como sus entradas y salidas que se constituyen en la representacion fidedigna de los procesos actuales y que podrian ser utilizados como apoyo en las tareas operacionales y de gestion que permitan tomar partido de las capacidades de captura, representacion y distribucion del conocimiento organizacional y que puedan ser transmitidas hacia las otras vistas organizacionales como por ejemplo la arquitectura de sistemas de informacion en la vista de aplicaciones. (Castela, N., Dias, P., Zacarias, M., & Tribolet, 2013)

La arquitectura de aplicaciones permitio identificar los sistemas y aplicaciones que son relevantes de la empresa, encargadas de gestionar la informacion necesaria para apoyar la ejecucion de las funciones del negocio de una manera ordenada y optima (Ross et al., 2006). En las Tablas 1 y 2 se presentan los objetivos y pasos planteados por ADMTOGAF 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

Asi 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 aplicacion y permite la toma de decisiones a nivel estrategico. 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 diseno y evolucion."

El modelo de vistas "4 + 1" (ver Figura 5), es un modelo para la representacion sistemas/ aplicaciones de software. La representacion del software muestra las necesidades o preocupaciones de los interesados de la aplicacion. Las vistas son cuatro (4): vista logica, vista de procesos, vista de desarrollo y vista de despliegue/fisica; mas casos de uso.

* Vista Logica: Se basa en la descomposicion orientada a objetos, muestra diagramas de clases que soporta los requerimientos funcionales que brinda la aplicacion.

* Vista de Procesos: Muestra los requerimientos no-funcionales de la aplicacion, tales como rendimiento, integracion y disponibilidad. Muestra como las unidades de ejecucion se comunican entre si.

* Vista de Desarrollo: Muestra la organizacion de los modulos en el ambiente de desarrollo. Como el software es empaquetado en pequenas 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 solucion de software, como nodos, procesadores, servidores, computadoras.

Figura 3--Artefactos ADM-Fase C--Arquitectura de Aplicaciones.

ARTEFACTOS

Catalogos

Catalogos

Catalogo del portafolio de Aplicaciones.
Catalogo de Interfaces.

Matrices

Matriz Organizacion/Aplicaclon
Matriz Organizacion/Aplicacion
Matriz Rol/Aplicacion
Matriz Funcion/Aplicacion
Matriz de interaccion de Aplicaciones

Diagramas

Diagrama de comunicacion de Aplicaciones
Diagrama de ubicacion de Aplicaciones y Usuarios
Diagrama de Casos de Uso
Diagrama de Gestion de la Empresa.
Diagrama de Procesos/Aplicacion
Diagrama de Ingenieria de Software
Diagrama de Migracion de Aplicaciones.
Diagrama de Distribucion de Software

Figura 4--Entregables Fase C--Arquitectura de Aplicaciones.

Documento de Definicion Arquitectonica.
RoadMap de componentes
Especificacion de Requirimientos Arquitectonicos


4. Resultados

Para el desarrollo del estudio se tomo como referencia los entregables obtenidos en la iteracion de capacidad arquitectonica--Fase Preliminar--Fase Vison Arquitectonica y en la iteracion de desarrollo--Fase Arquitectura de Negocio--ADM TOGAF.

Las vistas arquitectonicas se obtuvieron directamente de los interesados IT de la empresa, por medio de reuniones presenciales y en base a documentacion proporcionada por los mismos.

La infraestructura tecnologica que posee actualmente el GEM es un conjunto de sistemas heredados los cuales presentan distintas limitaciones relacionadas con la integracion y escalabilidad e interoperabilidad. Los sistemas heredados y su tecnologia actualmente son obsoletos (Seacord, R. C., Plakosh, D., & Lewis, 2003).

En el analisis y definicion de la arquitectura de linea base, se pudo encontrar dos tipos de aplicaciones: aplicaciones que interactuan con dispositivos fisicos (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 fabrica debido un proceso de automatizacion industrial. (Campoy, n.d.)

Los sistemas heredados estan desarrollados bajo una arquitectura cliente/servidor basica, la cual se muestra en la Figura 6.

Los artefactos arquitectonicos definidos para la fase de Sistemas de Informacion--ADM TOGAF--se desarrollaron una vez definida la linea base de la arquitectura de aplicaciones representada con el modelo de "4 + 1.

La Tabla 3 muestra la relacion entre las vistas "4 + 1 y los artefactos arquitectonicos correspondientes a la fase de Sistemas de Informacion.

En la capa de seguridad propuesta se contempla la implementacion de OpenLdap, el cual es un servidor que implementa LDAP (Lightweight Directory Access Protocol), mismo que mantiene un alto grado de cumplimiento de estandares y es el servidor de directorios de codigo abierto mas rapido en el mercado.

El Bus Empresarial de Servicios (ESB) (Schmidt, Hutchison, Lambros, & Phippen, 2005) permitira la orquestacion de los servicios entre las aplicaciones con la finalidad de integrar de sistemas empresariales. En la capa de seguridad se gestiona la autenticacion de usuarios y la gestion de excepciones.

La representacion y validacion de la arquitectura se realizo a traves 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 codigo Java con la abstraccion de alto nivel de una solucion. La implementacion contiene las principales especificaciones de la arquitectura "TO-BE".

La herramienta brinda un conjunto de funcionalidades de las cuales se uso unicamente las necesarias para la evaluacion de la arquitectura a traves de la Vista de exploracion, Vista Logica, Vista de la Arquitectura y el Dashboard.

Los requerimientos arquitectonicos se los define mediante metricas y en relaciones entre capas. La definicion de las capas con sus relaciones se las muestra en la Figura. 8.

La vista de exploracion de la Vista Logica (Figura 9), nos muestra las relaciones entre las capas, paquetes, y clases de la solucion. En caso de que exista un incumplimiento a los requerimientos arquitectonicos de diseno, 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 evaluacion de la arquitectura. El codigo sometido a evaluacion es un archivo comprimido con la extension ".war" de un proyecto Web-Java (Oracle, n.d.). Se puede ver que no existen violaciones a nivel arquitectonico. En la seccion tareas se listan las asignaciones por parte del arquitecto hacia el grupo de desarrolladores. Las asignaciones se muestran en eclipse como advertencias.

5. Conclusiones

La aplicacion del ADM-TOGAF conduce a una empresa hacia un nuevo esquema de gestion empresarial en donde los objetivos estrategicos de negocio identificados en la arquitectura del negocio se encuentran alineados con la arquitectura de aplicaciones. Las guias brindadas por ADM-TOGAF adaptadas al nivel de madurez de la empresa permiten definir de manera eficiente arquitectura de sistemas de informacion. La arquitectura de negocio es fundamental para proyectos de transformacion empresarial debido a que comprime las funcionalidades y modelos de informacion, y su relacion con la administracion y las estructuras organizacionales de negocio. El uso del modelo de Kruchten "4 + 1 views" en adaptacion con el Metodo de definicion Arquitectonica--ADM de TOGAF apoya la creacion de la Arquitectura Linea Base y la Arquitectura Futura, debido a que representa una abstraccion del negocio a traves de diferentes vistas arquitectonicas que son gestionadas por escenarios empresariales definidos en casos de uso.

La adaptacion de ADM-TOGAF con el modelo 4+1 de Kructhen fue fundamental para la definicion de la arquitectura de aplicaciones empresariales, y de acuerdo a las caracteristicas del caso de estudio planteado se definio trabajar con un estilo arquitectonico orientada a servicios (SOA) utilizando un ESB para lograr caracteristicas de robustez y extensibilidad en la estructura arquitectonica de aplicaciones, permitiendo asumir los requerimientos del negocio para soportar la integracion de aplicaciones empresariales como Bizagi (BPM) y Apache Ofbiz (ERP).

Dadas las caracteristicas de modelado que plantea el modelo 4+1 de Kructhen, la validacion de la arquitectura aplicaciones se realizo sin contratiempos, debido a que esta se desarrollo a nivel de diseno y codigo de implementacion a traves del ADL SONARGRAPH, esto permitio la obtencion de metricas para la evaluacion de los diferentes niveles de implementacion del estilo arquitectonico definido. Cabe resaltar que los ADL's no realizan la validacion de los sistemas empresariales como tal, se enfocan en la infraestructura de implementacion de la arquitectura de aplicaciones definida en la vista del desarrollo y despliegue del modelo del modelo 4+1

Recebido/Recibido: 27/03/2015

Aceitacao/Aceptacion: 18/09/2015

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.). "Division De Ingenieria de Sistemas y Automatica-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). Atualizacao Colaborativa do Modelo de Processos de Negocio. RISTI--Revista Iberica de Sistemas e Tecnologias de Informacao, (12), pp. 33-47. doi: 10.4304/risti.12.33-47

Crespo, P. J. D. A. (2014). Construcao de Sistemas Integrados de Gestao para Micro e Pequenas Empresas. RISTI--Revista Iberica de Sistemas e Tecnologias de Informacao. doi: 10.17013/risti.15.35-49

Gama, N., Silva, M. M. Da, Caetano, A., & Tribolet, J. (2006). Integrar a arquitectura organizacional na arquitectura empresarial. 7a Conferencia Da Associacao Portuguesa de Sistemas de Informacao (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, 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, 781-797. doi:10.1147/sj.444.078i

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

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=C4emZBzdp5pkoMOeE9syiFtaYX4

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, 78-84. Retrieved from http://www.iiisci.org/Journal/CV$/sci/pdfs/P445853.pdf

[1] ESB--Enterprise Service Bus

Armando Cabrera (1), Jose Carrillo (2), Marco Abad (3), Danilo Jaramillo (4), Freddy Romero (5)

aacabrera@utpl.edu.ec, jcarrillo@fl.upm.es, mpabad@utpl.edu.ec, djaramillo@utpl.edu.ec, fromero@utpl.edu.ec

(1,3,4,5) Universidad Tecnica Particular de Loja, Campus UTPL, 1101608, Loja, Ecuador.

(2) Universidad Politecnica de Madrid, Montegancedo, 28040 Madrid, Espana.

DOI: 10.17013/risti.e4.79-91

Tabla 1--Objetivos ADM-Fase C--Arquitectura de Aplicaciones,
Adaptado de (The Open Group, 2009)

OBJETIVOS

Desarrollar una Arquitectura de Aplicacion Destino que sea
funcional a la Arquitectura de Negocio y a la Vision de la
Arquitectura, y que responda a la Peticion de Trabajo
Arquitectonico y a las preocupaciones de los interesados.

Identificar componentes candidatos del Plan de Itinerario de
Arquitectura basandose en las brechas identificadas entre la
Arquitectura de Aplicaciones de Linea de Base y la Arquitectura de
Aplicaciones Futura (destino).

Tabla 2--Pasos ADM-Fase C--Arquitectura de Aplicaciones.


PASOS

Seleccionar modelos de referencia, puntos de vista y herramientas.
Desarrollar la descripcion de la Arquitectura Linea Base.
Desarrollar la descripcion de la Arquitectura Futura.
Desarrollar el Analisis de brechas.
Definir la hoja de ruta de componentes.
Realizar una revision formal con los interesados.
Finalizar la arquitectura de Aplicaciones.
Crear el documento de Definicion Arquitectonica.

Tabla 3--Relacion artefactos Fase C-ADM/Modelo Kruchten

Artefacto                                   Modelo 4+1/Otros

Catalogo del portafolio de Aplicaciones.    Vista-Procesos.
Catalogo de Interfaces.                     Vista Procesos.
Matriz Organizacion/Aplicacion.             Vista Proceso/Organigrama
                                              de la empresa.
Matriz Role/Aplicacion.                     Casos de Uso.
Matriz Funcion/Aplicacion.                  Vista Logica /Matriz
                                              de Stakeholders.
Matriz de Interaccion de Aplicaciones       Vista Logica.
Diagrama de Comunicacion de Aplicaciones    Vista-Procesos.
Diagrama de Ubicacion de                    Vista Logica.
  Aplicaciones y Usuarios.
Diagrama de Casos de Uso.                   Casos de Uso.
Diagrama de Gestion de la Empresa.          Vista Logica.
Diagrama de Procesos/Aplicacion.            Vista-Procesos.
Diagrama de Ingenieria de Software.         Vista Fisica.
Diagrama de Migracion de Aplicaciones.      Vista Logica.
Diagrama de Distribucion de Software.       Vista Fisica.

Figura 10--Resumen de las evaluaciones de la
arquitectura SOA--Sonargraph-Architect.

Architecture Dashboard

System opened: 'gem-soa'

Workspace defined

Workspace parsed

Metrics calculated

Duplicate code computed

Structural debt Index:                          0
Packages:                                       6
Internal types:                                 7
Bytecode instructions:                          388
Build units:                                    1
Excluded internal types:                        0
Lines of code:                                  0

Structure

Relative package cyclicity:                     0.00%
Cyclic packages:                                0
Biggest package cycle group:                    0
Type dependencies to cut (approx.):             0
References to remove (approx.):                 0

Highest ACD:                                    0.00
Highest NCCD:                                   0.00

Warnings

Warnings:                                       0
Cycle group warnings:                           0
Duplicate code warnings:                        0
Threshold warnings:                             0
Workspace warnings:                             0
Ignored warnings:                               0

Architecture

Violating type dependencies:                    0
Violating types:                                0 (0.00%)
Violating references:                           0
Ignored violations:                             0 (0 ignore filters)
Cyclic architecture elements:                   0
Architecture consistency warnings:              0
Unassiqned internal types:                      0 (0.00%)

Tasks

Open tasks:                                     0
Applicable fix warning tasks:                   0 (0 task definitions)
Applicable refactoring tasks:                   0 (0 task definitions)
Non-applicable fix warning task definitions:    0
Non-applicable refactoring task definitions:    g
COPYRIGHT 2015 AISTI (Iberian Association for Information Systems and Technologies)
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2015 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Cabrera, Armando; Carrillo, Jose; Abad, Marco; Jaramillo, Danilo; Romero, Freddy
Publication:RISTI (Revista Iberica de Sistemas e Tecnologias de Informacao)
Date:Sep 1, 2015
Words:3260
Previous Article:Views of supervisors and supervisees about the online software for research management--IARS[R]/Visao de orientadores e orientandos sobre o software...
Next Article:Users involvement in defining of requirements: the case of WEBMAT plataform/Envolvimento dos utilizadores na definicao de requisitos: o caso da...

Terms of use | Privacy policy | Copyright © 2022 Farlex, Inc. | Feedback | For webmasters |