Durante mi etapa de consultor-hombre orquesta en una gran multinacional, me pasé 7 años de mi vida dedicado a un producto de workflow, creado en base a las inversiones en I+D de la comisión europea y con muy pocas posibilidades de ser vendido en serio (al menos no teníamos la infraestructura para hacerlo). Durante este periodo aprendí un montón de workflow y descubrí la utilidad de este tipo de sistemas para organizaciones complejas.

Nuestro sistema no era, que dijeramos, sencillo. Estaba escrito en C++, basado en la Oracle y funcionaba exclusivamente en plataforma Sun. Para la época (hablamos de 1997) ésta era una plataforma avanzadísima y preparada para dar el mayor rendimiento (al mayor coste, eso si). Cuando me hice cargo del producto, conseguí hacerlo multiplataforma (linux primero y windows después, pasando por una versión para Alpha de digital). Contaba con la ventaja de que usamos compiladores GNU y que la mayor parte del código estaba bien escrita. Tabién conseguí que soportase otras bases de datos (sqlserver) y estuve a punto de que funcionase con postgresql, además le añadí la posibilidad de comunicarse remotamente mediante conectores y la posibilidad de un interfaz para móviles. El caso es que era una arquitectura basada en servidores corba, formularios web con javascript y herramientas clientes web y windows. En el año 2000 contabamos con un producto de workflow muy avanzado para la época. Pero no supimos venderlo

El caso es que, añoranzas aparte, me acostumbré a diseñar procesos de negocio, a definir las actividades dentro de un ciclo y a especificar quien hacía cada cosa, cuando y qué información manejaba. Este diseño era diréctamente traducible a un esquema de workflow que me ofrecía una puesta en marcha del proceso informático en minutos, algo impresionante, tanto para procesos de producción como para hacer un prototipo rápido que representase la actividad en las empresas.

Una vez que abandoné mi antigua empresa y mi producto (a veces tiendes a pensar en ellos como hijos que has abandondado) y tras constatar que el interés de mi antigua empresa en el producto consistía, básicamente, en evitar que te lo llevases (aunque no pensase venderlo ni hacer nada más con él) y que, por tanto, tendría que dejar de utilizarlo para mis proyectos busqué la manera de encontrar sistemas de workflow alternativos que me permitiesen la misma flexibilidad y rapided de implantación que el mío… Pero fracasé, en 2004 todos los productos de workflow que contenían el mínimo de elementos requeridos eran de pago. Y no estaba yo para licencias.

Desde ese año a esta parte la tecnología ha evolucionado bastante, el workflow ahora se llama BPM y está dentro de la filosofía SOA, los lenguajes han evolucionado, así como los estándares para cada cosa, xforms, xpdl, etc. Llegado este momento creo que se dan todas las circunstancias para que exista un sistema de workflow que sea open-source y que me aporte lo que hace 7 años ya tenía con mi software propietario y, a ser posible, algo más.

Aunque estoy en medio de ese proceso, y todavía no he visto todos los proyectos que pienso evaluar, me he decidido a crear una especie de «guia de evaluación» de productos workflow… Aunque sea a nivel personal, ya desde la perspectiva de desarrollador independiente y sin necesidad de promocionar ningún producto en concreto. Mis elementos básicos para evaluar una herramienta son estos:

1. Madurez del proyecto: ya he caido en la falta de soporte y/o evolución de algún proyecto muy interesante pero poco popular, por eso creo que es básico (para cualquier elección de software libre) examinar quien participa en el proyecto y si hay o no empresas detrás.
2. Uso de estándares: otro punto que se aplica al software libre y en el que este tiene ventaja es la adopción de estándares para evitar caer en la dependencia tecnológica. En este caso, por ejemplo, disponemos de estándares para la creación de formularios (xforms), para la definición del flujo (xpdl) e incluso para los modelos de flujo que debe soportar (workflow patterns), e incluso para el mundo SOA los WebServices sirven para interoperar.
3. Lenguaje e integración: aunque este es un punto secundario para evaluar funcionalidades, es crucial que el elenguaje que utiliza el motor de workflow y/o sus clientes puedan ser integrados con tu propia infraestructura, por eso y en mi caso, elijo aquellos que estén en Java.
4. Plataforma: casi todos los servicios de workflow requieren un servidor de aplicaciones o una plataforma de ejecución determinada. Hay que elegir la que más se adapte a nuestras necesidades y/o la que sea compatible con los proyectos en ejecución.
5. Documentación: de nada nos sirve un sistema supercompleto y megapotente si no sabemos siquiera como ponerlo en marcha y no encontramos recursos para documentarnos de sus posibilidades.
6. Diseñador de procesos: existencia de un diseñador gráfico de procesos o utilización de alguno estandar.
7. Bandeja de tareas: será posible disponer de una bandeja de tareas estándar y, además, se podrá definir una personalizada o integrar las tareas en un portal, sistema web o aplicación externa.
8. Administrador de procesos: el sistema permitirá auditar todas las ejecuciones de procesos de manera que se puedan buscar casos, tareas, etc. por criterios propios del mismo proceso y no solo por datos de ejecución.
9. Velocidad de implantación: mi sistema de wf ideal permitirá desplegar las aplicaciones en forma de prototipos inmediatamente sin requerir programar ni una sola línea de código (o al menos no salir del entorno de diseño).
10. Escalabilidad: si todo va bien y el sistema es completo, quizá querramos utilizarlo en proyectos grandes y, por eso, la arquitectura debe ser tal que permita ampliar los servidores o la capacidad de proceso fácilmente. Eso incluye la utilización de bases de datos para almacenar los datos de los procesos o posibilidad de ejecutar en un cluster.

Aunque hay muchos más criterios (que ya iré descubriendo), creo que me basaré en estos 10 para elegir mi próximo motor de workfow. Por el momento estoy evaluando estos:

• Bonita Workflow v3.0
• JBoss JBPM
  
• Intalio|BPMS

En proximas entregas os iré contando mis experiencias con estos productos (o alguno más, quien sabe).