Caso de estudio

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.

PARADIGMA - REVISTA ELECTRONICA EN CONSTRUCCIÓN DE SOFTWARE

2 Jaime Orlando Moreno, Jorge Humberto Arias

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

VOL. 1 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) 3

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.

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


1. Los empresarios solicitan Tablero de control
servicios vía diferentes canales. (Dashboard)
Funcionarios
Estos servicios activan procesos de
CCB
negocio. 4. La ejecución de los procesos
generan indicadores de gestión
Empresarios

Channel Layer Portal Client/server JSwing Webservices
2. Los canales activan y consumen procesos de
negocio

BPM Layer
Inscripción de proponentes Registro Matrícula persona Renovación matrícula
Natural Mercantíl

3. Se llaman las funcionalidades de
negocio que estructuran los procesos

Crear Chequear Liquidar Registrar info
Services Layer Matricula Homimia Valor Servicio Pago

EIS Layer

SIREP2 RUE Caja SAP

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



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):
Proyecto SIREP 2

Aplicaciones
PORTAL BAM CRM / ERP
J2EE / .net

BPM

Traducción Transformación Transacciones

Interceptores
ESB Repositorio
Servicios CCB
Seguridad

Aplicaciones Aplicaciones Aplicaciones
ERP CRM
J2EE .net Legadas

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

Más contenido relacionado

La actualidad más candente

Similar a Caso de estudio

Más de sandrariveram

Caso de estudio