BPM y Arquitecturas de Software

junio 12, 2013

URL copied!

Categories: AutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology

La noción de arquitecturas de software involucra describir y especificar la interacción de componentes con un alto nivel de abstracción, mostrando la interacción entre los mismos y el flujo de comunicación. El gran impacto que tuvo el concepto de arquitecturas de software se debe a la inclusión de aspectos no funcionales como escalabilidad, disponibilidad, seguridad y performance.

Estos aspectos tienen su relevancia al momento de implementar y ejecutar una solución basada en herramientas BPM, filosofía que permite especificar cada uno de los pasos involucrados en un proceso de negocio: su identificación, modelado, desarrollo, puesta en ejecución y administración. De esta manera, existen conceptos de la arquitectura de software que pueden extrapolarse a la hora de llevar adelante una gestión de procesos según BPM. En [1] se enfocan estos conceptos desde tres puntos de vista: Puesta en producción o deployment, estilos arquitectónicos y estimaciones de hardware.

Deployment

Desde el punto de vista de deployment, es importante pensar en la configuración que tendrá la arquitectura BPM al momento de gestionar los procesos de negocio de la organización. Una correcta configuración explorará 4 ángulos diferentes: el ambiente de desarrollo, que incluye la configuración, test, y corrección de bugs que surjan de la aplicación de herramientas BPM; el ambiente de testing que, como la etapa tradicional del desarrollo de software, estará enfocado en corroborar que se cumplan los diferentes criterios de aceptación, el ambiente de “staging”, que en esencia funciona como un entorno virtual seguro para correr productos en producción (muchas veces es opcional según la escala del proyecto) y el ambiente de producción, donde se aplicarán los distintos procesos.

Estilos Arquitectónicos

La aplicación de un estilo arquitectónico dependerá del set de herramientas BPM seleccionadas. Un estilo “stand alone” o de una única capa provee una única estructura para almacenar todos los componentes BPM (motor BPM, manager de aplicaciones, bases de datos) en una única máquina o servidor. La principal ventaja de este enfoque es la simpleza y el menor “overead” en las gestiones de administración, aunque puestas en producción complejas requerirán otro tipo de enfoque.

Un estilo de dos capas permite ubicar el motor de BPM y el manager de aplicaciones en distintos servidores, lo cual permite una mayor concurrencia y mejor performance.

Un estilo con tres capas permite tener servicios dedicados para cada componente BPM de manera individual. Obviamente, el mantenimiento y supervisión se vuelven más complejos, pero aumenta la magnitud de proyectos que puede abarcar.

Finalmente en un estilo multi-capas (con 4 o más), los componentes BPM se ubican en capas separadas, con servidores dedicados. Este estilo requiere especial cuidado en cuestiones de balance de carga y sincronización entre las distintas capas, aspecto generalmente subestimado.

Estimaciones de hardware

Desde el punto de vista de estimaciones de hardware, se deben considerar aspectos propios de BPM. Este punto generalmente es pasado por alto, y constituye uno de los errores más comunes para la implementación de una solución BPM. Las principales cuestiones inherentes a BPM que influyen para la estimación son: el número de procesos por año/mes/día/semana, la cantidad de actividades en cada proceso, cantidad de usuarios involucrados, integración con servicios externos, experiencia de la organización en soluciones BPM, y la infraestructura actual de IT de la organización.

Un caso concreto

En la referencia [2] se ilustra un caso típico de una arquitectura BPM por capas, combinando el management BPM con orientación a servicios al estilo SOA.

La capa principal es la de aplicación de servicios, que representan el corazón del sistema. Esto muestra la unión entre BPM y SOA, como es detallado en [3].

Usando BPM, SOA se concentra en servicios de procesos para desarrollar flujos de negocio complejos. BPM agrega poder adicional para la composición de servicios y permite modificar un flujo de comunicación de manera dinámica. Finalmente, BPM da la posibilidad de controlar procesos y unidades de ejecución a largo plazo, ideal para el contexto de aplicaciones bajo transacciones.

La capa inmediata es la capa de flujo de comunicación. Existen diversas tecnologías que pueden ayudar en este aspecto. Por ejemplo, un motor de orquestación como BizTalk se adapta perfectamente para sistemas automatizados. El objetivo de esta capa es modelar la interacción entre servicios.

La capa de presentación es el clásico “Front End”, donde se exhiben los puntos de entrada a los servicios ofrecidos. Esta capa tiene su complejidad, incluyendo conceptos como seguridad, autenticación, internacionalización, y personalización de características y estructura.

Finalmente, una capa de integración permite combinar el sistema con sistemas externos.

Cómo encarar una arquitectura BPM

En la referencia [4] se describen algunos pasos previos a tener en cuenta al momento de encarar una arquitectura BPM. Un buen diseño BPM arquitectónico incluye examinar el proyecto desde el paso 0: es decir, tener un panorama amplio y completo del alcance del sistema. Esto incluye tener un conocimiento profundo del comportamiento del sistema y saber discernir entre el diseño detallado y el diseño a alto nivel. Sin tener en claro estos aspectos, el desarrollo arquitectónico sufrirá de serios riesgos para completar su éxito.

También en [4] se describen otros consejos útiles. Por ejemplo, un arquitecto BPM debe enfocarse en la perspectiva local de la empresa, y no considerar la visión global de todas las empresas socias involucradas. Este último aspecto sólo tiene que tenerse en cuenta para contemplar que los servicios satisfacen la integración con los socios. Otro consejo parte del viejo refrán de “no reinventar la rueda”: es raro tener que construir una arquitectura desde cero. Se debe tratar siempre de utilizar funcionalidades ya incluidas en muchos frameworks como seguridad, logging, manejo de conexiones y más.