Your SlideShare is downloading. ×
Caso de estudio
Caso de estudio
Caso de estudio
Caso de estudio
Caso de estudio
Caso de estudio
Caso de estudio
Caso de estudio
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Caso de estudio

994

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
994
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
35
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Caso de Estudio: Proyecto SIREP2Estructura, rol e importancia de un ESBen un proyecto Empresarial centrado en procesos de negocio (BPM) ysoportados 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 NEGOCIODurante la planeación estratégica para el 2.000 al 2.005 la Cámara de Comercio deBogotá decidió transformar su modelo de gestión y pasar de ser una organización que segestionaba por funciones a una organización orientada a la gestión por procesos. Esto seacompañó con la implementación del direccionamiento estratégico y el seguimiento a lagestió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íacertificado siguiendo la norma ISO 9000; pero aparecieron interrogantes acerca de laconformación de los procesos y su normatización a través de procedimientos que noestaban siendo debidamente seguidos en la operación diaria. Además los indicadores deestos procesos se calculan en tareas batch que se realizan cuando no se pueden tomaracciones para mejorarlos. Pero los procesos se complicaron cuando surgieron retos deintegrar a otras entidades externas como la DIAN, la Secretaría de Hacienda Distrital, lasnotarías y las otras 57 de cámaras de comercio del país, las cuales participan en losprocesos de prestación de los servicios a los clientes. Lo anterior llevó a reflexionar si la tecnología de información que soporta el negociofacilitaba el soporte a la transformación del negocio que pretendía hacer la entidad. PARADIGMA - REVISTA ELECTRONICA EN CONSTRUCCIÓN DE SOFTWARE
  • 2. 2 Jaime Orlando Moreno, Jorge Humberto AriasDespués de analizar la arquitectura monolítica implementada y las facilidades que éstaofrecía, se tomó la decisión de incluir para la planeación estratégica 2.005 – 2.009 laadopción e implementación de una arquitectura empresarial de software orientada aservicios y que su implementación se iniciara soportando los procesos de negocio quehoy 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ó desarrollarun proyecto que recibió por nombre SIREP2 y el cual debe incluir cuatro elementosesenciales: 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 yuna buena formación conceptual y que se pule con los inconvenientes que se presentan enel día a día. Los procesos que se tomaron como base para el modelamiento inicial se hanmejorado, los conceptos de la arquitectura orientada a servicios se han apropiado y sobretodo se han simplificado para su cabal entendimiento. Las empresas externasproveedoras de plataformas tecnológicas que intervienen en la prestación de un serviciopara conformar un proceso, han sido capacitadas y en la práctica ya exponen lafuncionalidad 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 laorientación que se le dio a la estrategia tecnológica es la correcta y que antes que ver latecnología de la información como el desarrollo de programas se le ve como un soporte alos procesos de negocio a través de la orquestación de servicios que hacen parte delcatálogo de servicios y que antes que ser un lastre para el desarrollo e innovación delnegocio se le ve como un facilitador a través de la facilidad y flexibilidad que le da elmodelamiento de los proceso, su implementación a través de la orquestación de serviciosy 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 laestructura y visión de la solución. El rol del ESB dentro del proyecto SIREP2, espresentado en la sección 3. Finalmente, se presentan las conclusiones y reflexionesobtenidas como lecciones aprendidas del proyecto.2 ESTRUCTURA Y VISIÓN DE LA SOLUCIÓNLas necesidades de negocio claramente descritas en la sección anterior llevaron a que laCá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 apoyarVOL. 1 PARADIGMA - REVISTA ELECTRONICA EN CONSTRUCCIÓN DE SOFTWARE
  • 3. 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) 3la 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 apoyode cerca de 650 casos de usos, e integración con cerca de 10 entidades externas. Es poresto que la estructura y conceptualización de SIREP2 como mínimo debe considerar lossiguientes 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 emplearcomo el enfoque de arquitectura más apropiado para el proyecto un enfoque dearquitectura orientado a servicios (SOA: Services Oriented Architecture). Este enfoque dearquitectura 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 demanera transparente y bajo un enfoque de servicios la heterogeneidad de plataformas a laque debíamos enfrentarnos durante el proyecto (ESB: Enterprise Services Bus). A continuación se ilustra la estructura conceptual que integran las piezas enunciadasen el párrafo anterior y que resume la visión bajo la cual se estructuro e implemento elproyecto SIREP 2 (Fig.1). Como puede verse claramente en la figura, el proyectoSIREP2 puede resumirse lógicamente en cuatro capas: Canales, BPM, servicios ysistemas de información empresarial. Cada una de estas capas tiene asociadasresponsabilidades claramente definidas todo con el objetivo claro de apoyar una visión denegocios y tecnología centrada en procesos de negocio y dirigida por servicios. PARADIGMA - REVISTA ELECTRONICA EN CONSTRUCCIÓN DE SOFTWARE VOL. 1
  • 4. 4 Jaime Orlando Moreno, Jorge Humberto Arias 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 SIREP2A continuación se describe brevemente el alcance y responsabilidades de cada una de lascapas: 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 deVOL. 1 PARADIGMA - REVISTA ELECTRONICA EN CONSTRUCCIÓN DE SOFTWARE
  • 5. 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) 5datos estandarizados y lineamientos de seguridad y manejo transaccional que facilitensu 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 maneracentralizada para evitar problemas de duplicidad de servicios, evolución o extensiónno 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 aplataforma 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 decompensació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 laorquestación ordenada y bien definida de un conjunto de funcionalidades de negocioque se encuentran publicadas como servicios. Dicha orquestación durante el tiempogenera eventos de negocio a partir de los cuales se pueden tomar definicionescentradas en un tablero de control o DashBoard. Para la implementación de esta capa se emplearon enfoques BPM para procesosde negocio de comportamiento predecible y rígidos en su estructura en el tiempo, ymáquinas de estados (State machines) para procesos de negocio de comportamientono predecibles y de estructura flexible. Estos tos enfoque permitieron al interior dela CCB conceptualizar e implementar una capa centrada en el negocio y totalmenteflexible.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, loscuales 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 yprocedimientos 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-enden JSwing), webservices (empleados por la entidades de gobierno para solicitarlesservicios a la CCB), entre otros. Todos estos canales consumen la misma definiciónde procesos de negocio para soportar la entrega ordenada, medible, flexible, rápida yeficiente de los servicios que presta la organización a los empresarios y a la ciudad. PARADIGMA - REVISTA ELECTRONICA EN CONSTRUCCIÓN DE SOFTWARE VOL. 1
  • 6. 6 Jaime Orlando Moreno, Jorge Humberto Arias 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 SIREP2La arquitectura conceptual que describe el proyecto SIREP2, la cual se detalla en elnumeral 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 SIREP2Como puede verse en esta figura, el bus de servicios (ESB) es un pieza estructural yangular para soportar la arquitectura total del proyecto, ya que todos lo mensajes quefluyen entre el BPM, CRM, ERP, aplicaciones legadas, aplicaciones J2EE, y aplicacionesVOL. 1 PARADIGMA - REVISTA ELECTRONICA EN CONSTRUCCIÓN DE SOFTWARE
  • 7. 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) 7.NET y las aplicaciones proveedoras de las funcionalidades de negocio deben pasar por elesta pieza intermedia. El ESB ofrece robustez y confiabilidad en la entrega de mensajes a los escenarios denegocio que consideran el flujo de información entre varias aplicaciones y/o plataformastecnológicas, gracias a la naturaleza asíncrona sobre la que se encuentra implementadala comunicación de los diferentes elementos estructuradores del Bus. Por ejemplo, cuando el BPM desea invoca una funcionalidad de negocio publicadapor la plataforma ERP (SAP) de la CCB, y la cual hace parte de una orquestación de unproceso de negocio, delega la entrega del mensaje al ESB, el cual asume las siguientesresponsabilidades 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 serasegurados en un escenario de integración SOA y que son delegados en cuento a sumanejo 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 mensajesapoyados 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 serviciosSOA publicados directamente por las plataformas de negocio y sistemas de informaciónsobre las cuales la Cámara soporta su operación diaria. Esto para ofrecer una capahomogénea, bien formada, definida y estandarizada de acceso en cuanto a: Protocolosinvocación (binding), formato de datos y manejo de requerimientos no funcionales. Todoesto desde la perspectiva de las aplicaciones consumidoras de servicios tales como: BPM,Portal, BAM, entre otras. Lo cual promueve la reusabilidad desde diferentes sistemas delas funcionalidades de negocio publicadas como servicios.4 CONCLUSIONES Y REFLEXIONESLas conclusiones y reflexiones que se presentan a continuación, está encaminadas al porqué utilizar un ESB de acuerdo a las lecciones aprendidas en la CCB. A lo largo delcamino que se ha tenido que labrar para lograr la exitosa implementación del proyectoSIREP2 pueden enunciarse las siguientes conclusiones sobre la relevancia e importanciade 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 alintercambio de mensajes se da entre aplicaciones consumidores de servicios (Portal, PARADIGMA - REVISTA ELECTRONICA EN CONSTRUCCIÓN DE SOFTWARE VOL. 1
  • 8. 8 Jaime Orlando Moreno, Jorge Humberto AriasBPM, BAM, Sistemas Cliente/Servidor, Sistemas externos, etc.) y aplicacionesproveedoras 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 lolargo 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ónu ontologías, enriquecimiento de mensajes, entre otros, debe centralizarse y manejarse enel ESB. Para garantizar de esta manera la reutilización de dichos manejos, y facilitar laslabores de mantenimiento. Uno de los principales objetivos de un proyecto SOA es definir, estructurar eimplementar un completo catálogo de servicios. Si este catálogo no se evoluciona ygestiona adecuadamente, todos los esfuerzos realizados no tendrán sentido y valor denegocio para la organización. Ya que los principios de flexibilidad y reusabilidad quepropone SOA pronto van a terminar desvirtuándose. La incorporación de una plataforma de ESB dentro de la solución va a permitirrealizar estas tareas de gobierno de una manera centralizada y versionada, garantizándoseasí que el catálogo de servicio que define e inspira la arquitectura SOA de la organizaciónpueda crecer ordenadamente, y cumpla a cabalidad los principios de flexibilidad yreusabilidad que promete SOA. Finalmente, los principios de integración no-intrusiva bajo los cuales se soportan lavisión conceptual que define la implementación de un ESB permite que funcionalidadesde negocio implementadas y residentes en sistemas legados y sistemas desarrolladossobre tecnologías cerradas puedan ser fácilmente publicadas como servicios, y por endeser promovidas como un potencial servicio reutilizable del portafolio de serviciosempresarial.VOL. 1 PARADIGMA - REVISTA ELECTRONICA EN CONSTRUCCIÓN DE SOFTWARE

×