architecture - ¿Cómo sabes cuándo necesitas una solución BPM?
workflow (5)
Mi cliente está buscando una solución de Business Process Management (BPM). Lo que necesitan es un simple enrutamiento de documentos y un sistema de aprobación. ¿Cuáles son los controladores para implementar un sistema BPM? ¿Cuál es el umbral en el que un desarrollador debe sugerir la implementación de una solución BPM frente a una herramienta de flujo de trabajo o desarrollo personalizado?
¿Cuándo encaja jBPM? ¿Cuándo encaja una máquina de estado integrada en una aplicación? ¿Qué problemas deberían existir que determinen que necesita ir con una solución similar a jBPM?
Estoy buscando algunos ejemplos reales de "intentamos construir la solución nosotros mismos, pero terminamos yendo con AquaLogic / jBPM / Lombardi debido a _ ". Por favor, rellene el espacio en blanco.
BPM Acid Test (de Essential Business Process Modeling por Michael Havey, publicado por O''Reilly).
... BPM es adecuado solo para aplicaciones con un sentido esencial de estado o proceso, es decir, aplicaciones que están orientadas a procesos. Una aplicación pasa la prueba de ácido BPM si está legítimamente orientada al proceso. La solicitud de la agencia de viajes, por ejemplo, pasa la prueba porque se entiende mejor en términos del estado del itinerario y se define en todo momento por lo lejos que ha llegado el itinerario. Otras características típicas de una aplicación orientada al proceso incluyen las siguientes:
- De larga duración
De principio a fin, el proceso abarca horas, días, semanas, meses o más.
- Estado persistido
Debido a que el proceso es de larga duración, su estado se mantiene en una base de datos para que supere al servidor que lo aloja.
- Bursty, duerme la mayor parte del tiempo -
El proceso pasa la mayor parte del tiempo dormido, esperando que ocurra el siguiente evento desencadenante, momento en el que se despierta y realiza una serie de actividades.
- Orquestación de sistemas o comunicaciones humanas.
El proceso es responsable de gestionar y coordinar las comunicaciones de varios sistemas o actores humanos.
... Por ejemplo, en un cajero automático, que permite a los usuarios consultar el saldo de su cuenta, retirar efectivo, depositar cheques y efectivo y pagar facturas: cualquier sentido del proceso es fugaz e inesencial; Un cajero automático es un procesador de transacciones en línea, no una aplicación orientada a procesos.
En última instancia, todos los sistemas comerciales que tratan con el procesamiento de información relacionada con la empresa son BPM o sistemas de flujo de trabajo. El procesamiento de la información de cualquier empresa se puede describir en términos de flujos de trabajo o "procesos empresariales", que incluyen roles y actividades.
El hecho de que estas actividades comerciales se describan a menudo en Java, C # u otros lenguajes de programación es básicamente el resultado de la automatización sin tecnología lo suficientemente madura para la prescripción y la descripción de los procesos comerciales con agentes automáticos.
El énfasis se ha puesto en el crecimiento, el tiempo de comercialización, etc., y la informatización se llevó a cabo sin una reflexión adecuada sobre el mantenimiento y la flexibilidad a largo plazo. El 99% de lo que está en el código ahora no debería ser.
En contraste, los sistemas de control en tiempo real, los videojuegos, la computación de alto rendimiento, la previsión, la inteligencia empresarial y el análisis matemático son ejemplos de problemas que no se prestan a la descripción del flujo de trabajo gráfico. Estas son cosas que deben ser hechas por computadoras y mantenidas por expertos en computadoras.
Los procesos de negocios deben ser prescritos, descritos y legibles por expertos en operaciones de negocios. Las ganancias de flexibilidad serán cada vez más reconocidas a medida que la tecnología que permite esto (sistemas de flujo de trabajo) mejore, y sea más ampliamente aceptada a medida que la economía mundial desestima el "crecimiento".
Escribí un motor de flujo de trabajo, porque mi empleador quería ser propietario de la IP, siguiendo el modelo de jBPM. Ahora, la razón por la que utiliza una herramienta de este tipo, en lugar de crear su propia máquina de estados finitos, es aceptar cambios sin alterar la persistencia y respaldar los casos de procesos de flujo de trabajo como lo explicaré.
Acomodando cambios sin alterar la persistencia
Su implementación de máquina de estado finito típica, o quizás mejor llamarlo "ingenua", cuenta con un conjunto de tablas de base de datos estrechamente unidas a los datos administrados y al proceso por el que fluye. Puede haber una manera de mantener las versiones anteriores y rastrear quién tomó qué acción durante el proceso también. Donde esto se encuentra con problemas, cambios en los datos y la estructura del proceso. Luego, esas tablas estrechamente acopladas deben modificarse para reflejar la nueva estructura y es posible que no sean compatibles con las anteriores.
Un motor de flujo de trabajo supera este desafío de dos maneras, utilizando la serialización para representar los datos y el proceso, y abstrayendo los puntos de integración, en particular la seguridad. El aspecto de serialización significa que los datos y el proceso pueden moverse juntos a través del sistema. Esto permite que las instancias de datos del mismo tipo sigan procesos completamente diferentes hasta el punto en que el proceso pueda alterarse en el tiempo de ejecución, agregando un nuevo estado, por ejemplo. Y nada de esto requiere cambiar el almacenamiento subyacente.
Los puntos de integración son medios para inyectar algoritmos en el proceso y vínculos con los almacenes de autenticación (es decir, los usuarios que deben tomar medidas). Los algoritmos inyectados pueden incluir determinaciones de si un estado se completa o no, mientras que el ejemplo de las tiendas de autenticación es LDAP.
Ahora la compensación es difícil la búsqueda. Por ejemplo, debido a que los datos están serializados, generalmente no es posible consultar información histórica, aparte de recuperar los registros, deserializarlos y analizarlos utilizando el código.
Casos Edge
El otro aspecto de una herramienta de flujo de trabajo es la experiencia incorporada en su diseño y funcionalidad, que probablemente no considerará hacer rodar la suya y puede arrepentirse cuando la necesite. Los dos casos que vienen a mi mente son tareas cronometradas y rutas de ejecución paralelas.
Las tareas programadas asignan a un actor la responsabilidad de los datos una vez transcurrida una cierta duración. Por ejemplo, digamos que un comunicado de prensa se escribe y se envía para su aprobación, y luego se queda sentado durante una semana sin revisión. Lo que probablemente desee que haga su sistema es identificar ese documento persistente y atraer la atención de las partes apropiadas.
Las rutas de ejecución paralelas son poco comunes en mi experiencia (Sistemas de gestión de contenido), pero siguen siendo una situación que surge con la frecuencia suficiente. Es la idea de que un dato determinado se envía por dos rutas diferentes de revisión o procesamiento, solo para ser recombinados en algún momento posterior. Este tipo de problema requiere tener algoritmos de fusión útiles y la capacidad de representar los datos de manera simultánea. Tejer eso en una solución casera después del hecho es mucho más complicado de lo que parece, especialmente si desea realizar un seguimiento de los datos históricos.
Conclusión
Si no es probable que su sistema cambie, su propia solución puede ser una solución más fácil, especialmente si los cambios pueden romper la información antigua. Pero si sospecha que necesita ese tipo de durabilidad o experimenta algunos de estos escenarios poco comunes pero espinosos, una herramienta de flujo de trabajo proporciona mucha más flexibilidad y seguro que no se verá afectado por los datos y procesos empresariales. cambio.
Tal vez hacer algunas preguntas podría ayudar.
¿Cambiarán los procesos? ¿Se mantendrá una versión anterior de un proceso mientras que una nueva versión del proceso se convierta en realidad? ¿Debe medirse el tiempo de ejecución de los procesos (y cada paso)?
¿Se trata de procesos de negocios (orquestando el estado de múltiples recursos) o ciclos de vida de recursos (solo el estado de un único documento / recurso)? ...
Lo siento si no es una gran respuesta.
Tomaría una mirada más cercana a la necesidad comercial que impulsa su esfuerzo (es decir, "caso de negocios"). A mi entender, BPM / flujo de trabajo puede tener uno o más de los siguientes objetivos :
1. Automatizar acciones.
Esto suele ser necesario para reemplazar humano con máquina mediante la automatización de tareas, como crear documentos, archivar información, notificar a usuarios, etc.
2. Seguimiento de cada proceso.
Las empresas necesitan establecer un seguimiento cuando hay un número significativo de procesos, y los usuarios comerciales los pierden, ya que normalmente los ejecutan en documentos de oficina, correos electrónicos. Cada solicitud externa de estado (por ejemplo, de un cliente) se convierte en una investigación.
3. Establecer el control.
Para los gerentes, generalmente es importante obtener una visión de alto nivel del proceso y estudiarlo de forma estadística: ver si se mantienen los indicadores clave de rendimiento (KPI), retrasos, excepciones, etc.
4. Gestionar el intercambio de documentos en proceso y la colaboración.
Los BPM a menudo sirven como una herramienta de intercambio de documentos, ya que a menudo permiten el cambio del correo electrónico y la comunicación verbal a un intercambio rastreable en un BPM.
5. Automatizar el intercambio de datos entre sistemas empresariales.
Este es un caso de integración pura y generalmente se exige en el caso de que ya se realizan varias acciones con (o mediante) varios sistemas, y existe la necesidad de automatizar el intercambio de información entre ellos.
Ahora, los BPM listos para usar con todas las funciones son buenos para 2, 3 y, a veces, 4. jBPM y otros motores de flujo de trabajo son buenos para 1 y 3, pero con una advertencia importante: requieren una configuración / desarrollo complejos.
Los motores de orquestación de procesos basados en SOA (a veces también llamados BPM) son buenos para (5) y (3).
Por favor, siéntase libre de agregar a la lista y discutir! He publicado esto como mi publicación de blog y he elaborado un poco más aquí: http://processmate.net/do-you-need-a-bpm-or-a-workflow/