Los engranajes de un banco moderno giran de acuerdo con los procesos comerciales financieros. Son más complicados de lo habitual: esta regla funciona para todo, a lo que se agrega la definición de "financiero". Por un lado, todo es complicado por los reguladores, innumerables aprobaciones y partes involucradas. Por otro lado, el torpe monolítico BPMS (Business Process Management System). En esta publicación, le diremos cómo abandonó con éxito uno de esos sistemas y entró en un código abierto flexible y funcional.
Los programadores muestran procesos de negocios usando diferentes notaciones. Ahora el estándar es BPMN (Business Process Model and Notation): son archivos XML con imágenes adjuntas. Para trabajar con esta notación, se crean productos BPMS: sistemas monolíticos patentados que intentan acomodar las herramientas máximas para desarrollar BPM: desde el editor de interfaz de usuario hasta el sistema de control de versiones.
Solo los desarrolladores que han estado trabajando con estos sistemas durante mucho tiempo pueden expandirlos. En el BPMS empresarial, se proporciona una API REST, es decir, se puede acceder a los sistemas y recibirlos en respuesta. Pero modificar y ajustar BPMS en sí es casi imposible. Es posible trabajar con tales BPMS solo a través de un conjunto limitado de herramientas por parte del fabricante (un sistema de control de versión patentado, compilador, implementador), generalmente para cada BPMS grande se desarrolla un conjunto completo. Estas herramientas se desarrollan lentamente, los mismos problemas pueden persistir de versión en versión, porque no hay muchas personas involucradas en el trabajo, como es el caso del código abierto. En general, las capacidades de BMPS empresarial y las necesidades de sus usuarios coinciden muy raramente.
En la publicidad de dichos sistemas, hablan sobre el flujo de trabajo de extremo a extremo, dicen que el negocio en sí mismo puede cambiar los procesos de BPM sobre la marcha. Pero, de hecho, incluso los analistas no pueden hacer esto, solo los desarrollados pueden manejarlo.
Un proceso de negocio consiste en tareas de usuario y servicio cuyas secuencias conducen a la parada final. En BPMS, a través de dichos esquemas, puede realizar un seguimiento del tiempo de ejecución de los procesos comerciales, así como de varios indicadores comerciales, por ejemplo, KPI.A menudo tenemos que hacer cambios de varios tamaños en los procesos comerciales. Solíamos tener un proceso BPM para gerentes de clientes que se sientan en oficinas adicionales. En 2015, cerramos algunas de las oficinas y transferimos gerentes al trabajo de campo. Esto requirió grandes cambios en los procesos BPM, fue necesario introducir otros roles, acciones. O, por ejemplo, la regulación del servicio de seguridad económica ha cambiado, y en lugar de dos coordinadores, ahora hay tres.
Primero, hicimos cambios a través de IBM Lombardi BPMS. Habiendo recogido los defectos típicos de los sistemas de su clase, también se distinguió por la falta de documentación ordenada. Parecía que después de la compra de Lombardi Software, el gigante del software miró la nube amorfa de los artículos que lo acompañaban y decidió no tocar nada. E incluso después de leer toda la documentación, era imposible hacer muchas cosas. Por ejemplo, invoque una solicitud REST con autenticación HTTPS utilizando un certificado de usuario. Afortunadamente, la búsqueda de una alternativa fue un éxito.
Camunda resuelve problemas
Después de trabajar con IBM BPM, llegamos a la conclusión de que diferentes grupos de usuarios deberían poder cambiar los procesos comerciales. Algo insignificante en el modo en línea puede ser contribuido por empleados comunes de unidades de negocios. Los analistas de sistemas están cambiando la secuencia de tareas en los procesos empresariales. Las nuevas integraciones, los cambios en la interfaz de usuario y el código del programa permanecen del lado de los desarrolladores. Y para mantener esta flexibilidad, todos los BPMS deben implementarse en microservicios.
Podemos proporcionar este enfoque con BPMS Camunda de código abierto. Es una bifurcación del proyecto Actividad, que el equipo de desarrollo decidió hacer más ventas. Pusieron en orden la documentación y comenzaron a desarrollar Camunda por separado, ganan con la venta de soporte.
BPMS Camunda le permite editar procesos comerciales utilizando Java estándar y admite el uso compartido de microservicios. Cambiar BPMS a microservicios ofrece varias ventajas a la vez:
- Deshacerse del monolito. Podemos dividir los procesos comerciales por segmentos, uniéndolos entre sí utilizando Rabbit MQ o Kafka a través de la cola. Los procesos de negocios se pueden cambiar de forma aislada entre sí, pasar los cambios sin esperar a una versión completa.
- Deshacerse de un servidor de procesos de negocio.
- Escalado Si bajo carga algún servidor comienza a caer, entonces puede ser clonado. En las cargas máximas, puede aumentar fácilmente la productividad ejecutando múltiples instancias de procesos comerciales en diferentes servicios.
- Versionado Si, por ejemplo, necesita actualizar la versión de Java, puede recoger varios microservicios con diferentes versiones de Java y ejecutar la nueva versión en paralelo. Cada microservicio puede tener no solo diferentes versiones de software, sino también diferentes idiomas.
En el futuro, planeamos transferir uno de nuestros procesos comerciales más grandes a Camunda: los préstamos corporativos. Todo aquí es mucho más complicado que el de las personas e incluso que el de las pequeñas y medianas empresas. No es un producto sino un esquema de crédito limitado que se aplica, los límites son limitados en el tiempo, los prestatarios generalmente son parte de organizaciones más grandes como las tenencias, y las tenencias tienen algo más que hacer. Los límites se determinan por separado para cada una de estas estructuras, y cada estructura tiene sus propias coincidencias, cuya composición cambia constantemente. Obtenemos un proceso comercial de cientos de etapas. Pudimos cambiarlo con Camunda y decidimos permanecer en él. Incluso si los desarrolladores deciden ahora cerrar el proyecto, las capacidades actuales del sistema durarán otros tres años.
Nuestra primera versión de Camunda se basó en Websphere y, de hecho, no era muy diferente de IBM Lombardi. Decidimos escribir las aplicaciones a las que accedió el servicio en Spring Boot. Se desplegaron en Tomcat y no funcionaron solos. Luego resultó que Camunda podría funcionar en Tomcat, se desarrolló una versión para Spring Boot. Una arquitectura completa de microservicios ya está disponible allí. Todas las aplicaciones con las que trabajó el proceso de negocio se implementaron en una arquitectura de microservicio basada en Spring Cloud.
Luego resultó que puede cambiar rápidamente la funcionalidad no solo en los servicios que sirven al proceso comercial. El propio motor BPM se puede conectar a cualquier aplicación springboot como una biblioteca.
Camunda como microservicioSurgió la pregunta: ¿cuántos microservicios levantar? Era posible hacer un servidor para cada proceso, y colocar todos los microservicios allí, o hacer que cada microservicio y un proceso de negocio separado para cada tarea. El segundo sería más conveniente, pero sería necesario organizar la interacción de procesos dispersos en microservicios individuales. Probamos varias opciones y decidimos encontrar una solución cuando varios microservicios son responsables de un tema determinado y varios procesos se agrupan allí. La comunicación se realiza a través de REST o Rabbit MQ. Ahora han lanzado un piloto en Kafka.
Perspectivas para BPMS
Los procesos empresariales no solo muestran el flujo de trabajo empresarial, sino que también responden a eventos que ocurren en otros sistemas. Tenemos estos eventos acumulados por una división separada de Big Data. Con base en el análisis de estos eventos, se crean nuevos procesos comerciales o se modifican los existentes; esto sucede después del hecho, con una frecuencia de, por ejemplo, una vez al día.
Idealmente, los procesos comerciales deberían pasar a cambiar en línea; por ejemplo, cuando aumenta la demanda de ciertos servicios, priorizarán automáticamente su implementación y reasignarán recursos. Esto se puede lograr a través de la automatización, la interacción, por ejemplo, Kafka y Camunda, pero esto es una cuestión de al menos varios años. Quizás ahora en la dirección de los cambios en el modo en línea, el más avanzado es el Monzo Bank en inglés totalmente en línea. Y también estamos trabajando en ello.