BPM_es

Workflow de código abierto vs Suites BPM con API’s

Estás desarrollando un nuevo proyecto de software, y te das cuenta que para una parte de él, precisas una máquina de estados. O en otras palabras, un workflow. Inmediatamente piensas en buscar un motor de workflow de código abierto que puedas incorporar en tu desarrollo. Haces las búsqueda y encuentras decenas. Todos dicen ser fáciles de usar e integrar. Ninguno lo es.

código abierto o API

La situación descrita es muy común. Las herramientas de código abierto para gestionar flujos de trabajo, por lo general son muy flexibles y potentes, e igualmente complejas de integrar, personalizar, hacer funcionar y sobre todo mantener en el futuro.

Algunas opciones de herramientas de workflow de código abierto son realmente muy potentes, robustas y flexibles. Por ejemplo Camunda, jBPM y Activiti, que además son compatibles con el estándar BPMN para la notación gráfica de los procesos. Otras herramientas, como Enhydra Shark, utilizan otras notaciones para el modelado gráfico de los proceso, y ofrecen un motor de ejecución específico para ellas.

En el otro extremo, están las herramientas de BPM denominadas low-code o no-code, como Flokzu, que se basan en no requerir programación ni conocimientos técnicos para ser utilizadas. En estos casos, el componente que permite integrarlas a otros sistemas, son sus interfaces públicas, o simplemente API’s.

Ventajas del workflow de código abierto

Las suites o herramientas de BPM de código abierto son especialmente ventajosas en estos escenarios:

  • Cuando requerimos un muy alto nivel de personalización de la solución. Es decir, adaptar la solución, el formulario, los procesos a una determinada necesidad o casuística de negocio. En estos escenarios, la herramientas de código abierto nos dan libertad total para hacerlo.
  • Cuando el componente de workflow y BPM es una parte pequeña en un gran desarrollo de software. En estos casos, todo el producto requerirá mantenimiento y evolución, por lo que el diferencial de hacerlo también para el componente de workflow, es marginal.
  • Cuando es necesario un desempeño (performance) específico y garantizado. En estos escenarios, tener acceso al código del motor de procesos puede ser de gran utilidad.
  • Cuando sólo se requieren algunas funcionalidades del motor de procesos, y se desea eliminar (u ocultar) las demás. En este caso, el poder acceder al código permite hacerlo y obtener una solución mucho más ajustada a las necesidades del aplicativo.

Restricciones al usar un workflow de código abierto

De la mano de la flexibilidad, vienen algunas restricciones relevantes:

  • Necesidad de un equipo de desarrollo de software. Integrar una herramienta de código abierto requiere desarrolladores de software. Considerando la alta (altísima?) demanda mundial de estos roles, esto constituye una restricción significativa.
  • Actualización e instalación de nuevas versiones. A medida que se liberan nuevas versiones del código de la herramienta de código abierto, es recomendable incorporarlas. Esto implica más tareas para el equipo de desarrollo de software. En algunos casos, cuando se han introducido personalizaciones o integraciones muy acopladas, esta actualización puede ser especialmente compleja.
  • Riesgo de obsolescencia. Puede suceder, que la branch de código abierto que se haya elegido quede obsoleta (sin evolución). En estos casos, el reemplazo por otra que sí tenga evolución y mantenimiento, puede ser muy costoso (en tiempo y riesgo).
  • Cumplimiento de estándares. Esto puede llegar a ser una restricción, cuando se liberen nuevas versiones, en particular de la notación BPMN (estándar OMG en la versión 2.0.2 al escribir este post). Es importante que el software de código abierto incorpore estas nuevas versiones. De no incorporarlas, será muy difícil para desarrollador de software incorporar estas nuevas versiones, dado que se trata de una notación amplia, compleja, muy potente y que incluye toda una componente gráfica relevante. Ver ejemplo a continuación extraído de la documentación de la versión 2.0.2 del estándar BPMN.
Ejemplo de proceso modelado con BPMN 2.0.2: Proceso de Envío de artículos.
Ejemplo de proceso modelado con BPMN 2.0.2: Proceso de Envío de artículos.
  • Soporte para comportamientos complejos. Los procesos de negocios y los workflows pueden ser muy complejos, involucrar cientos de etapas, y una gran cantidad de componentes en el flujo con comportamientos diversos. Para el desarrollador de software puede ser muy complejo entender, y luego limitar o personalizar dichos comportamientos en orden de hacerlos útiles a su aplicación particular. En la siguiente imágen se presenta un ejemplo de proceso con colaboración, también extraído de la documentación del estándar BPMN 2.0.2:
Ejemplo de Colaboración en el estándar BPMN 2.0.2: Orden y Entrega de Pizza.
Ejemplo de Colaboración en el estándar BPMN 2.0.2: Orden y Entrega de Pizza.

Alternativa: Suites de Workflow con API’s

Como alternativa a utilizar un workflow de código abierto, surge la opción de utilizar un producto comercial (un BPM Suite o Workflow Suite), que provea todas las capacidades de gestión de workflow y gestión de procesos, de código cerrado, y que provea un conjunto de API’s para poder integrarlo con otros sistemas o aplicativos.

A modo de ejemplo, Flokzu provee una API pública, que facilita que se puedan ejecutar acciones de los procesos, desde cualquier otra aplicación.

Tal vez el caso de uso más común en este sentido, es tener un sitio web optimizado para el onboarding de nuevos clientes, y que al finalizar, inicie un nuevo workflow de alta para ese cliente. Este workflow es iniciado mediante el método New Process Instance de la API de Flokuz. A este método se le pasan como parámetros los valores del nuevo cliente (nombre, dirección, etc). Estos valores se almacenan en variables de la nueva instancia de proceso, e inicia el flujo de trabajo.

Pero además, la comunicación puede ser bidireccional. En determinada etapa del proceso, el motor de workflow, puede invocar mediante una API a un web service en otro sistema, que realice otra operación. Siguiendo con el ejemplo, se podría dar de alta el cliente en otros sistemas de forma automática. El proceso, modelado en Flokzu se vería de la siguiente forma:

Alternativa a un workflow de código abierto: utilizar un producto cerrado e integrarlo mediante API's. Aquí ejemplo de proceso de nuevo cliente.
Integración de proceso mediante API – Ejemplo de nuevo cliente

Ventajas del enfoque Producto + API’s

Las ventajas del enfoque de utilizar un producto de workflow de código cerrado, y luego integrarlo al desarrollo mediante API’s, son justamente los opuestos a las restricciones previamente presentadas:

  • Si bien se mantiene la necesidad de un equipo de desarrollo para integrarlo mediante API’s, el trabajo será sensiblemente menor, y por ende la cantidad de horas y costos.
  • El producto de software será actualizado, y probablemente se mantengan las interfaces de la API, con lo que no hay que preocuparse de ello. Este desacople es muy importante para que tanto la aplicación que se está desarollando, como el producto de workflow que se esté integrando, puedan evolucionar de forma independiente.
  • En los productos comerciales, el riesgo de obsolescencia es mucho menor que en una branch de código abierto. Y más si se utiliza un producto líder a nivel mundial (como Flokzu 😀). Es de esperar que el fabricante se ocupe de actualizar el producto, por lo que ese costo y complejidad quedan de su lado.
  • Respecto al cumplimiento de estándares, sucede algo similar. El fabricante de un producto de workflow, para mantenerse en el mercado, deberá asegurar el cumplimiento de los estándares de la industria de procesos. En particular, deberá resolver el cumplimiento del estándar de notación BPMN (OMG).
  • Los comportamientos complejos que el estándar BPMN soporta, serán resueltos por el producto BPM, de forma transparente al desarrollador de software. Éste se limitará a utilizar las funciones que el producto provee a través de su API.

Conclusiones

Usar un workflow de código abierto como parte de un desarrollo mayor, presenta algunas ventajas y varias desventajas.

Entre las ventajas, destacan la flexibilidad, capacidad de personalización y control total sobre lo que se está ejecutando. Entre las desventajas, la principal es la alta complejidad que los productos de workflow tienen, por lo que su integración a otro desarrollo insumirá muchos recursos (tiempos y costos), y será de muy difícil mantenimiento posterior.

En este escenario, una alternativa que merece ser considera seriamente, es la utilización de un producto de workflow comercial, de código cerrado, e integrarlo mediante API’s.



Prueba Flokzu ya!

Agenda aquí y uno de nuestros consultores despejará las dudas adicionales que puedas tener para integrar Flokzu a tus sistemas mediante la API pública

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *