Buscando un workflow libre

workflowDurante 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:

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

10 comentarios en “Buscando un workflow libre

  1. Pingback: meneame.net

  2. Me parece una iniciativa muy interesante.
    He trabajado también con varios productos y mi conclusión es que no existe el producto, el estándar ni la tecnología universal que valga para cualquier sistema.
    He renunciado a la universalidad y cada día apuesto más por el desarrollo a medida basado en SOA. Los BPMS son demasiado genéricos y muchas veces no permiten crear procesos con la flexibilidad necesaria, teniendo que recurrir a módulos desarrollados a medida para resolver ese caso concreto. Al final, hemos tenido que utilizar el BPMS para 2 chorradas y, la mayor parte del trabajo, con desarrollos a medida.

  3. Hola Otrofox,

    ¿Que BPMS utilizasteis? A mi, que me considero experto en este campo, me está costando muchisimo incluso ejecutar los ejemplos de los sistemas que estoy evaluando

  4. Estamos empezando el mismo proceso que dices que empezaste en septiembre, seleccionar un workflow open source.
    ¿Has llegado a alguna conclusión?
    ¿Vas a colgar tu informe? ¿o puedes enviar por correo lo que tengas?

  5. Hola
    En la empresa donde trabajo estamos en la misma desición, elegir un buen sistema de workflow o suite BPM para ofrecer el servicio a empresas de distintos rubros.
    Aun estoy en ese estudio y aunque me gustaria probar efectivamente todas las herramientas que tengo en mi lista no se si sera posible ya que algunas son un poco complicadas de implementar.
    Actualmente estamos usando UEngine con Liferay en el servicio que ofrecemos, pero hemos tenido varios problemas, comenzando por el hecho de que un desarrollador agrego funcionalidades a UEngine, muy buenas por cierto, pero fuera del estandar, lo que llevó a que al salir una nueva actualización, la implementación de la misma fuese casi imposible. Asi que como moraleja, seguir el estandar al agregar nuevas funcionalidades.
    Apenas tenga algo mas maduro sobre el tema y sobre la desición que se tome la informaré aqui mismo, ya que me parece excelente que se abarquen estos temas sobre herramientas OpenSource.
    Inicialmente para Workflow me inclino por Bonita, la cual aun no pruebo pero he leído muy buenos comentarios y sobre sus caracteristicas tambien. Y para una suite BPM Intalo al igual que Jose Antonio.
    Nos hablamos.

  6. Buenas tardes, José Antonio.

    Me ha resultado evocador visitar el blog y los avatares compartidos con el workflow del que hablas.

    En cuanto a opciones libres, pienso que Bonita (Bull-Object Web) y jBPM serían las mejores opciones hasta donde yo sé.

    Bonita lo he llegado a probar con Posgresql y MySql para evaluar sus posibilidades de cara a un proyecto interno.

    Con jBPM, aunque no dispongo de tiempo, he estado dándole vueltas a una posible ampliación del API para incorporar documentos a tareas y procesos pero no he llegado a hacer nada al respecto.

    Otra idea que tengo bajo mi foco es el uso de OpenLaszlo (www.openlaszlo.org) para resolver la parte visual. Llegué a hacer una prueba de concepto para acceder al motor de jBPM

    Quizás te pueda ser util también el bpel Orchestra de Object Web.

    Con mis mejores deseos

    Aurelio Vahí Serrano

Los comentarios están cerrados.