caso de estudio

PARADIGMA - REVISTA ELECTRONICA EN CONSTRUCCIÓN DE SOFTWARE

Caso de Estudio: Proyecto SIREP2 Estructura, rol e importancia de un ESB en un proyecto Empresarial centrado en

procesos de negocio (BPM) y soportados en reusabilidad de Servicios

(SOA)

Jaime Orlando Moreno, Jorge Humberto Arias Cámara de Comercio de Bogota

{jaimem,arquitectodes}@ccb.org.co

Resumen.

El presente artículo muestra un caso de estudio sobre un enfoque de arquitectura orientado a servicios (SOA: Services Oriented Architecture) en un contexto real. Por otro lado, se presenta como esta arquitectura a la vez se complementó con un enfoque de gestión de procesos (BPM: Business Process Management), monitoreo de procesos de negocio centrado en KPIs (BAM: Business Activity Monitoring) y una plataforma para manejar la heterogeneidad de plataformas (ESB: Enterprise Services Bus) involucradas durante el proyecto.

1 CONTEXTO Y MOTIVADORES DE NEGOCIO

Durante la planeación estratégica para el 2.000 al 2.005 la Cámara de Comercio de

Bogotá decidió transformar su modelo de gestión y pasar de ser una organización que se

gestionaba por funciones a una organización orientada a la gestión por procesos. Esto se

acompañó con la implementación del direccionamiento estratégico y el seguimiento a la

gestión a través del balance scoredcard.

Para el año 2.005 se había terminado el diseño de los procesos y la entidad los había

certificado siguiendo la norma ISO 9000; pero aparecieron interrogantes acerca de la

conformación de los procesos y su normatización a través de procedimientos que no

estaban siendo debidamente seguidos en la operación diaria. Además los indicadores de

estos procesos se calculan en tareas batch que se realizan cuando no se pueden tomar

acciones para mejorarlos. Pero los procesos se complicaron cuando surgieron retos de

integrar a otras entidades externas como la DIAN, la Secretaría de Hacienda Distrital, las

notarías y las otras 57 de cámaras de comercio del país, las cuales participan en los

procesos de prestación de los servicios a los clientes.

Lo anterior llevó a reflexionar si la tecnología de información que soporta el negocio

facilitaba el soporte a la transformación del negocio que pretendía hacer la entidad.

2 Jaime Orlando Moreno, Jorge Humberto Arias

VOL. 1 PARADIGMA - REVISTA ELECTRONICA EN CONSTRUCCIÓN DE SOFTWARE

Después de analizar la arquitectura monolítica implementada y las facilidades que ésta

ofrecía, se tomó la decisión de incluir para la planeación estratégica 2.005 – 2.009 la

adopción e implementación de una arquitectura empresarial de software orientada a

servicios y que su implementación se iniciara soportando los procesos de negocio que

hoy le generan cerca del 88% de los ingresos a la entidad.

El proyecto de cambio tecnológico se estructuró en el 2.005 y se decidió desarrollar

un proyecto que recibió por nombre SIREP2 y el cual debe incluir cuatro elementos

esenciales:

1. Implementar un modelo de desarrollo de software basado en principios de

ingeniería de software para construir un catálogo de servicios ante que una

aplicación.

2. Seguir metodologías para desarrollo de software orientado a servicios y que estas

metodologías ser soportaran en herramientas de software.

3. Implementar repositorios para que el conocimiento que se genere se conserve

como capital intelectual de la entidad

4. Desarrollar un programa bajo el modelo de competencias, para que los ingenieros

de desarrollo y de procesos se capacitaran y pudieran aportarle al proyecto su

conocimiento del negocio.

Hoy el proyecto muestra la madurez y el conocimiento que se adquiere con la práctica y

una buena formación conceptual y que se pule con los inconvenientes que se presentan en

el día a día. Los procesos que se tomaron como base para el modelamiento inicial se han

mejorado, los conceptos de la arquitectura orientada a servicios se han apropiado y sobre

todo se han simplificado para su cabal entendimiento. Las empresas externas

proveedoras de plataformas tecnológicas que intervienen en la prestación de un servicio

para conformar un proceso, han sido capacitadas y en la práctica ya exponen la

funcionalidad propia de su solución como parte del catálogo de servicio.

En conclusión la administración de la Cámara está convencida que el paso y la

orientación que se le dio a la estrategia tecnológica es la correcta y que antes que ver la

tecnología de la información como el desarrollo de programas se le ve como un soporte a

los procesos de negocio a través de la orquestación de servicios que hacen parte del

catálogo de servicios y que antes que ser un lastre para el desarrollo e innovación del

negocio se le ve como un facilitador a través de la facilidad y flexibilidad que le da el

modelamiento de los proceso, su implementación a través de la orquestación de servicios

y la generación en línea de sus indicadores.

El artículo está organizado de la siguiente manera. En la sección dos, se presenta la

estructura y visión de la solución. El rol del ESB dentro del proyecto SIREP2, es

presentado en la sección 3. Finalmente, se presentan las conclusiones y reflexiones

obtenidas como lecciones aprendidas del proyecto.

2 ESTRUCTURA Y VISIÓN DE LA SOLUCIÓN

Las necesidades de negocio claramente descritas en la sección anterior llevaron a que la

Cámara de Comercio de Bogota emprendiera el desarrollo de una solución tecnológica;

que como bien fue mencionado recibió el nombre de SIREP2. Este sistema debe apoyar

Caso de Estudio: Proyecto SIREP2 Estructura, rol e importancia de un ESB en un proyecto Empresarial

centrado en procesos de negocio (BPM) y soportados en reusabilidad de Servicios (SOA) 3

PARADIGMA - REVISTA ELECTRONICA EN CONSTRUCCIÓN DE SOFTWARE VOL. 1

la línea de negocio de Registros Públicos de la Camara de Comercio de Bogotá (CCB),

la cual se compone de 35 procesos de negocio, los cuales a bajo nivel requieren el apoyo

de cerca de 650 casos de usos, e integración con cerca de 10 entidades externas. Es por

esto que la estructura y conceptualización de SIREP2 como mínimo debe considerar los

siguientes lineamientos:

1. Automatización de procesos de negocio más que automatización de los

tradicionales procedimientos de negocio.

2. Publicación de funcionalidades de negocio como servicios reutilizables a partir

de las cuales se puedan componer de manera flexible procesos de negocio.

3. Composición de procesos de negocio a partir de funcionalidades de negocio

implementadas desde cero como parte del proyecto, y funcionalidades de negocio

existentes en sistemas externos tales como: SAP, DIAN, Redeban, SHD

(Secretaria de Hacienda Distrital), Microsoft Dynamics CRM, entre otros.

4. Medición de procesos negocio en tiempo real vía indicadores de desempeño KPI

(Key performance Indicator).

5. Integración con sistemas de externos en tiempo real vía un modelo de servicios

síncronos y eventos asíncronos.

6. Gobernabilidad y gestión de funcionalidades de negocio publicadas como

servicios para que se pudiera asegurar la reusabilidad, evolución y localización de

las mismas a lo largo de los 35 procesos de negocio que componen la línea de

negocio apoyada por SIREP2.

Estos lineamientos mínimos de base llevaron a que se tomará la decisión de emplear

como el enfoque de arquitectura más apropiado para el proyecto un enfoque de

arquitectura orientado a servicios (SOA: Services Oriented Architecture). Este enfoque de

arquitectura a la vez se complemento con un enfoque de gestión de procesos (BPM:

Business Process Management), monitoreo de procesos de negocio centrado en KPIs

(BAM: Business Activity Monitoring) y una plataforma que permitiera manejar de

manera transparente y bajo un enfoque de servicios la heterogeneidad de plataformas a la

que debíamos enfrentarnos durante el proyecto (ESB: Enterprise Services Bus).

A continuación se ilustra la estructura conceptual que integran las piezas enunciadas

en el párrafo anterior y que resume la visión bajo la cual se estructuro e implemento el

proyecto SIREP 2 (Fig.1). Como puede verse claramente en la figura, el proyecto

SIREP2 puede resumirse lógicamente en cuatro capas: Canales, BPM, servicios y

sistemas de información empresarial. Cada una de estas capas tiene asociadas

responsabilidades claramente definidas todo con el objetivo claro de apoyar una visión de

negocios y tecnología centrada en procesos de negocio y dirigida por servicios.



Figure 1. Arquitectura conceptual del Proyecto SIREP2

A continuación se describe brevemente el alcance y responsabilidades de cada una de las

capas:

1. Capa de sistemas de información empresarial (EIS Layer): Agrupa todos los

sistemas de información de magnitud empresarial que apoyan la operación back-

end de la Cámara de Comercio de Bogota. Entre este tipo de sistemas se destacan:

SAP (ERP), Royal Image (ECM), RUE (Sistema externo que centralizada

información de todas las cámaras de comercio del país), Microsoft Dinámica

(CRM), Muisca-DIAN, entre otros.

Estos sistemas de información en su interior tienen implementados las

funcionalidades de negocio que posteriormente son publicadas como servicios, a

partir de los cuales se componen y estructuran procesos de negocio.

2. Capa de Servicios (Services Layer): Se compone de todas las funcionalidades de

negocio implementadas por las plataformas de negocio de la CCB que se publican

como servicios reutilizables a partir de los cuales se pueden componer procesos

de negocio, a soportar escenarios de integración bajo un enfoque SOI (Services

Oriented Integration).

Alrededor de esta capa se define lo que hemos llamado al interior de la CCB

Portafolio de servicios. El portafolio de servicios es el agrupamiento de todos los

servicios o funcionalidades de negocio publicadas bajo estándares abiertos, tipos de

2. Los canales activan y consumen procesos de

negocio

EmpresariosEmpresarios

1. Los empresarios solicitan

servicios vía diferentes canales.

Estos servicios activan procesos de

negocio.

Registrar info

PagoLiquidar

Valor Servicio

Chequear

Homimia

Crear

Matricula Registrar info

PagoLiquidar

Valor Servicio

Chequear

Homimia

Crear

Matricula

SAPRUE CajaSIREP2

Inscripción de proponentes Registro Matrícula persona

NaturalRenovación matrícula

Mercantíl

3. Se llaman las funcionalidades de

negocio que estructuran los procesos

4. La ejecución de los procesos

generan indicadores de gestión

4. La ejecución de los procesos

generan indicadores de gestión

Tablero de control

(Dashboard)

Tablero de control

(Dashboard) Funcionarios

CCB

Funcionarios

CCB

Services Layer

EIS Layer

BPM Layer

Channel Layer Portal Client/server JSwing Webservices




datos estandarizados y lineamientos de seguridad y manejo transaccional que faciliten

su reutilización, y proveen flexibilidad a la hora de componer procesos de negocio.

La gestión y gobernabilidad del portafolio de servicios se realiza de manera

centralizada para evitar problemas de duplicidad de servicios, evolución o extensión

no controlada y/o versionada de servicios, y asegurar la reusabilidad de los mismos.

Finalmente, es importante anotar que esta capa puede ser potenciada con un a

plataforma de integración que asegure la entrega de mensajes enviados a un servicio,

provea soporte a requerimientos no funcionalidades de integración (Enrutamiento,

traducción y transformación, seguridad, manejo transaccional vía 2PC y enfoques de

compensación, entre otros)

3. Capa de BPM (BPM Layer): Esta definida en términos de los procesos de

negocio que estructuran la línea de negocio de Registros Públicos de la Cámara

de Comercio, y que fueron necesarios orquestar vía un enfoque de servicios, y

monitorear vía eventos de negocio generadores de KPIs (Key Performance

Indicator).

Es importante anotar, que para la CCB un proceso de negocio no es más que la

orquestación ordenada y bien definida de un conjunto de funcionalidades de negocio

que se encuentran publicadas como servicios. Dicha orquestación durante el tiempo

genera eventos de negocio a partir de los cuales se pueden tomar definiciones

centradas en un tablero de control o DashBoard.

Para la implementación de esta capa se emplearon enfoques BPM para procesos

de negocio de comportamiento predecible y rígidos en su estructura en el tiempo, y

máquinas de estados (State machines) para procesos de negocio de comportamiento

no predecibles y de estructura flexible. Estos tos enfoque permitieron al interior de

la CCB conceptualizar e implementar una capa centrada en el negocio y totalmente

flexible.

4. Capa de canales (Channel Layer): Esta capa permite manejar la interacción de

los empresarios, clientes y empleados con los servicios que presta la Cámara de

Comercio de Bogota, los cuales se materializan en la ejecución de procesos de

negocios.

Es decir, la CCB publica los servicios que presta como procesos de negocio, los

cuales implican atravesar diferentes áreas funcionalidades y sistemas de información.

Esto debido a que la CCB más que ser una organización orientada a funciones y

procedimientos de negocio es una organización orientada a procesos de negocio.

Los canales empleados por la CCB para prestar sus servicios son: Internet, sedes

(las cuales emplean una aplicación Cliente/Servidor en Java que emplean un front-end

en JSwing), webservices (empleados por la entidades de gobierno para solicitarles

servicios a la CCB), entre otros. Todos estos canales consumen la misma definición

de procesos de negocio para soportar la entrega ordenada, medible, flexible, rápida y

eficiente de los servicios que presta la organización a los empresarios y a la ciudad.



De esta manera, la CCB garantiza que independientemente del canal se presta el

mismo servicio, con lo mismo datos, y con las mismas reglas de negocio. Escenarios

que son difíciles de garantizar en organizaciones que soportan su operación en una

heterogeneidad de plataformas tecnológicas, necesitan responder de manera inmediata

a los cambios del mercado (para el caso en particular de la CCB, cambios en

regulaciones de gobierno).

Finalmente, desde esta capa se encuentra el tablero de control, el cual es el lugar

donde se publican los indicadores de negocio KPI que se calculan a partir de los

eventos de negocio generados por el BPM durante la orquestación de un proceso de

negocio. Este tablero de control publicado en un portal al grupo ejecutivo de la CCB

para que este último puede conocer en un tiempo cercano al real (NRT: Near to Real

Time) como se están prestando los servicios que ofrece la CCB y como va la

organización en general.

3 EL ROL DEL ESB DENTRO DEL PROYECTO SIREP2

La arquitectura conceptual que describe el proyecto SIREP2, la cual se detalla en el

numeral anterior, puede resumirse en términos de las siguientes estructuras lógicas

(Fig.2):

BPM

ESB

PORTAL

ERP CRMAplicaciones

J2EE

Aplicaciones

.net

Aplicaciones

Legadas

BAM

Repositorio

Servicios CCB

Traducción

Interceptores

Transformación

Seguridad

Transacciones

Aplicaciones

J2EE / .netCRM / ERP

Proyecto SIREP 2

Figure 2. Estructuras lógicas del Proyecto SIREP2

Como puede verse en esta figura, el bus de servicios (ESB) es un pieza estructural y

angular para soportar la arquitectura total del proyecto, ya que todos lo mensajes que

fluyen entre el BPM, CRM, ERP, aplicaciones legadas, aplicaciones J2EE, y aplicaciones




.NET y las aplicaciones proveedoras de las funcionalidades de negocio deben pasar por el

esta pieza intermedia.

El ESB ofrece robustez y confiabilidad en la entrega de mensajes a los escenarios de

negocio que consideran el flujo de información entre varias aplicaciones y/o plataformas

tecnológicas, gracias a la naturaleza asíncrona sobre la que se encuentra implementada

la comunicación de los diferentes elementos estructuradores del Bus.

Por ejemplo, cuando el BPM desea invoca una funcionalidad de negocio publicada

por la plataforma ERP (SAP) de la CCB, y la cual hace parte de una orquestación de un

proceso de negocio, delega la entrega del mensaje al ESB, el cual asume las siguientes

responsabilidades para garantizar la entrega del mensaje:

1. Toma el mensaje enviado por el BPM

2. Procede a transformarlo en el formato de mensajes que maneja la plataforma ERP,

3. Publica el mensaje a una cola JMS ó MQ Series,

4. Toma el mensaje de la cola, bajo un contexto transaccional JTA,

5. Envía a través de un adaptador el mensaje publicado en la cola a la plataforma

ERP

6. Sí este último se encuentra fuera de línea, el mensaje no es entregado y por ende

no es confirmado su consumo en el sistema de colas, para que luego vía un

mecanismos pull o push (Patrón Reactor/Proactor POSA) sea aplicado un

reintento de mensajes.

Este ejemplo refleja tres importantes requerimientos no-funcionales que deben ser

asegurados en un escenario de integración SOA y que son delegados en cuento a su

manejo a la plataforma ESB: Traducción y transformación de formatos de mensajes,

entrega y consumo transaccional de mensajes, y garantía de entrega de mensajes

apoyados en enfoques asincrónicos con activación dinámica Pull o Push.

Adicionalmente, el ESB esta siendo empleado en la CCB como proxy a los servicios

SOA publicados directamente por las plataformas de negocio y sistemas de información

sobre las cuales la Cámara soporta su operación diaria. Esto para ofrecer una capa

homogénea, bien formada, definida y estandarizada de acceso en cuanto a: Protocolos

invocación (binding), formato de datos y manejo de requerimientos no funcionales. Todo

esto desde la perspectiva de las aplicaciones consumidoras de servicios tales como: BPM,

Portal, BAM, entre otras. Lo cual promueve la reusabilidad desde diferentes sistemas de

las funcionalidades de negocio publicadas como servicios.

4 CONCLUSIONES Y REFLEXIONES

Las conclusiones y reflexiones que se presentan a continuación, está encaminadas al por

qué utilizar un ESB de acuerdo a las lecciones aprendidas en la CCB. A lo largo del

camino que se ha tenido que labrar para lograr la exitosa implementación del proyecto

SIREP2 pueden enunciarse las siguientes conclusiones sobre la relevancia e importancia

de un ESB dentro de la arquitectura tanto lógica como física de un proyecto SOA / BPM.

El ESB es una plataforma que ofrece y garantiza confiabilidad y robustez al

intercambio de mensajes se da entre aplicaciones consumidores de servicios (Portal,



BPM, BAM, Sistemas Cliente/Servidor, Sistemas externos, etc.) y aplicaciones

proveedoras de servicios donde residen las funcionalidades de negocio (ERP (SAP),

aplicaciones legadas, aplicaciones en .NET / J2EE, CRM (Microsoft Dynamics, etc.)

La implementación de los requerimientos no-funcionales que deben asegurarse a lo

largo de intercambio de datos, sea este de naturaleza síncrona o asíncrona, tales como:

Enrutamiento de mensaje, traducción y transformación de datos basados en programación

u ontologías, enriquecimiento de mensajes, entre otros, debe centralizarse y manejarse en

el ESB. Para garantizar de esta manera la reutilización de dichos manejos, y facilitar las

labores de mantenimiento.

Uno de los principales objetivos de un proyecto SOA es definir, estructurar e

implementar un completo catálogo de servicios. Si este catálogo no se evoluciona y

gestiona adecuadamente, todos los esfuerzos realizados no tendrán sentido y valor de

negocio para la organización. Ya que los principios de flexibilidad y reusabilidad que

propone SOA pronto van a terminar desvirtuándose.

La incorporación de una plataforma de ESB dentro de la solución va a permitir

realizar estas tareas de gobierno de una manera centralizada y versionada, garantizándose

así que el catálogo de servicio que define e inspira la arquitectura SOA de la organización

pueda crecer ordenadamente, y cumpla a cabalidad los principios de flexibilidad y

reusabilidad que promete SOA.

Finalmente, los principios de integración no-intrusiva bajo los cuales se soportan la

visión conceptual que define la implementación de un ESB permite que funcionalidades

de negocio implementadas y residentes en sistemas legados y sistemas desarrollados

sobre tecnologías cerradas puedan ser fácilmente publicadas como servicios, y por ende

ser promovidas como un potencial servicio reutilizable del portafolio de servicios

empresarial.

caso de estudio

Documents