¿Cuándo usar motores de flujo de trabajo?

He trabajado anteriormente en algunos de los motores de flujo de trabajo como programador, pero nunca tuve una idea clara de por qué elegimos los motores de flujo de trabajo en primer lugar. Y como programador, sé que hay al menos 100 formas de hacer cualquier cosa cuando escribes código, ¡pero solo unas pocas son las mejores!

Todavía no entiendo qué casos de uso resuelven mejor los motores de flujo de trabajo (o más bien su concepto) que diseñar una buena aplicación habilitada para DI. Estoy buscando características generales de los casos de uso de dominio neutral, donde los motores de flujo de trabajo son una de las mejores opciones.

Entonces mi pregunta es: ¿Cuáles son las características generales de un requisito que se puede tomar como una señal para optar por un buen motor de flujo de trabajo y codificarlo?

Un motor de flujo de trabajo es útil cuando necesita ir de principio a fin, pero hay muchas rutas / lógica / reglas diferentes para llegar allí.

Por ejemplo, digamos que escribo un programa que publica contenido. Entonces, en mi caso, la publicación pasa por un proceso de revisión, legal y luego de aprobación final. Escribo el programa implementando la lógica y los pasos de mi proceso. Ahora esto funciona muy bien para mí y para mi empresa. Entonces, decido que otros deberían usar mi programa.

Desafortunadamente, no todos publican contenido usando el mismo proceso, por lo que en lugar de escribir procesos separados para cada caso diferente, implementaríamos un proceso de flujo de trabajo para que el programa sea flexible para acomodar a todos. No importa cuántos pasos, reglas o lógica se encuentren entre esos dos puntos, el resultado es el mismo.

Entonces, si tiene procesos que son variables de principio a fin, use un flujo de trabajo. Si todos pueden usar el mismo proceso, entonces no necesita un flujo de trabajo.

Sé que solicitó casos de uso, pero es más fácil enumerar las ventajas que imaginar todos los casos de uso posibles. Las ventajas, por supuesto, dependen del motor y el idioma que esté comparando, pero en general:

1. Mantener las reglas como datos en lugar de código significa que no tiene que volver a compilar, por lo que puede probar los cambios rápidamente, cambiar en tiempo de ejecución, etc. Sin embargo, no es una gran ventaja si no tiene que volver a compilar.

2. Se puede esperar más razonablemente que los usuarios editen las reglas. Potencialmente pueden jugar con ellos de manera interactiva de maneras que no son factibles cuando un programador escribe código para ellos.

3. Mantener las reglas como datos permite escribir herramientas para visualizar y cambiar los datos.

4. Mantener las reglas como datos permite una metaprogramación más fácil: puede escribir código para analizar los datos e insertar más de una manera compleja, lo que sería muy difícil para el código.

Todas estas cosas son posibles de hacer directamente con el código (p. Ej., Escriba un analizador C # para encontrar todas las reglas de cierto tipo y genere código para más reglas, insértelo dinámicamente en un ensamblaje de manera que permita la descarga del ensamblaje, escriba herramientas para los usuarios también pueden hacer esto usando su visualizador y editor) pero puede ser mucho más difícil dependiendo de su idioma (los programadores que usan un Lisp pueden referirse a los puntos 1-4 como "programación").

En mi humilde opinión, el ÚNICO caso en el que debe usar este tipo de cosas es cuando puede ser configurado por usuarios menos valiosos. Si puede resolver su problema dándoles una herramienta y luego volviendo a trabajar en otra cosa más importante, use una.

Si aún necesita configurarlo para ellos, entonces me imagino que podría pensar en 10 maneras diferentes de obtener el mismo resultado con una herramienta con la que está familiarizado y será mucho más fácil admitir y personalizar.

Esto parece una vieja pregunta, pero aparece en numerosas ocasiones en la naturaleza. Estoy de acuerdo con la respuesta de Jon . He encontrado que los motores de flujo de trabajo son altamente productivos en los siguientes escenarios:

1. Hay un proceso empresarial subyacente que está intentando representar / implementar a través de su software.
2. Hay una sola entidad comercial (quizás compuesta) en la que se trabaja en todas o algunas de las etapas del proceso. En el ejemplo que dio Jon, esta entidad o elemento de flujo de trabajo sería contenido o un artículo. Considere el seguimiento de errores como otro ejemplo de un flujo de trabajo, un error transiciones entre varios estados, en función de una acción que realiza un usuario.
3. Use Workflows para modelar sus procesos, solo si espera que cambie el proceso de negocio, por cambio me refiero a la secuencia o acción realizada como resultado de una acción o transición del usuario.

Sea muy cuidadoso y crítico para ver si su dominio / requisitos problemáticos tiene un proceso comercial, no intente "encajarlo" en un flujo de trabajo.

Tengo un par de pautas que uso para sugerir motores de flujo de trabajo.

1) Cuando los analistas de negocios no tienen antecedentes de codificación pero pueden dibujar diagramas.

Los motores de flujo de trabajo modernos utilizan la notación de modelado de procesos de negocio, o las versiones menos capaces disponibles en SharePoint y sistemas similares. Esto permite a los miembros del equipo técnicamente competentes pero con problemas de codificación diseñar y desarrollar muchos flujos de trabajo.

2) Cuando necesite monitorear el progreso del trabajo, realice escalamientos, cambie entre los procesos controlados por computadora y los procesos controlados por humanos.

El monitoreo y la autorreferencia son características de los motores modernos de flujo de trabajo.

Desde una perspectiva empresarial de recursos humanos, los motores de flujo de trabajo son muy importantes.

1. Proporcionan un proceso estructurado, incluso si es el mismo cada vez.

2. Proporcionan transparencia

   • ¿Quién solicitó el cambio?
   • Cuando fue solicitado,
   • Quién aprobó etc.

   Esta transparencia ayuda a impulsar el proceso y promueve la propiedad.

Asumiendo que los formularios son integrados e inteligentes, que soportan la lógica empresarial, también tiene un efecto dramático en la línea de tiempo, la eficiencia del procesamiento y la calidad de los datos. También se debe tener en cuenta la seguridad y es mucho más preferible que contenga información confidencial en un sistema seguro que tener formularios en papel a la espera de ser firmados. También es mucho más móvil. Después de una implementación reciente, un gerente me dijo que le ahorró muchas molestias al publicar cosas para que las firmara, ya que viajaba mucho.

En nombre de RRHH: ¡Viva el flujo de trabajo!