BPMS o simplemente programación?

Question

¿Qué prefieres (desde el punto de vista de tu desarrollador) cuando se trata de implementar un proceso de negocios?

¿Un sistema de gestión de procesos empresariales (BPMS) o simplemente su IDE favorito con las herramientas y los marcos necesarios (una herramienta de informes, por ejemplo)?

¿Cuál es, desde su punto de vista, el mayor beneficio de un BPMS en comparación con un IDE con sus herramientas y marcos personales?

OK. Tal vez debería ser más específico ... Llegué a conocer un BPMS específico que debería facilitar la implementación de un proceso de negocios mediante la configuración de reglas. Pero para mí, como desarrollador, es difícil trabajar con el sistema. Me gustaría trabajar con archivos de texto que puedo refactorizar y me gustaría poder elegir la tecnología o el marco adecuado para el trabajo que tengo que hacer. En cambio, el sistema me obliga a configurar.

Hay reglas en el que puedo utilizar Java, pero incluso entonces tiene que pegarse al editor sistemas sin intelisense etc.

Así que esto me lleva a la respuesta de mi propia pregunta - Me gusta usar la herramientas a las que estoy acostumbrado en lugar de tener que aprender a trabajar con un BPMS (al menos el que yo conozco) porque me limita más de lo que me ayuda. ¡El BPMS que conozco es un marco del cual es difícil escapar! En este momento, preferiría un marco como Grail sobre cualquier BPMS que conozca.

Entonces, quizás la pregunta más específica es: ¿Sientes lo mismo o hay BPMS que te ayudan a ser un desarrollador y pensar como desarrollador o la mayoría te obliga a hacer tu trabajo de otra manera?

Answer 1

No estoy seguro de qué es exactamente lo que pregunta, pero la elección de BPM frente a la programación simple dependerá de los requisitos. Un "proceso de negocios" es un término relativamente vago en ingeniería de software.

Estas son algunas criterio para evaluar sus necesidades:

• complejidad de las normas - ¿Son las decisiones y/o normas incorporadas en su proceso simple, complicado, configurable, modificable?
• volatilidad del proceso - ¿Con qué frecuencia cambia su proceso? ¿Quién debería poder hacer el cambio?
• integración necesita - ¿Se realizó su proceso utilizando múltiples servicios heterogéneos, o todo se implementa en el mismo idioma?
• synchronous/asynchrounous - ¿Es su proceso "de larga duración" con la necesidad de manejar acciones asincrónicas?
• tareas humanas - ¿Su proceso involucra interacción humana, con tareas asignadas/enrutadas a personas según sus roles/responsabilidades?
• supervisión del proceso - ¿Cuál es el nivel de control que desea en las instancias de proceso existentes que se están ejecutando? ¿Necesita auditar las acciones, etc.?
• error management - Dependiendo de los puntos anteriores, ¿cómo piensa lidiar con errores, o reintentar la ejecución defectuosa del proceso?

En función de la respuesta a estas preguntas, usted puede darse cuenta de que su proceso está más cerca de un gráfico simple state con unas pocas acciones y decisiones que se pueden ejecutar en una secuencia, o puede darse cuenta de que se necesita algo más elaborado , y que no desea volver a implementar todo usted mismo.

Entre programación llanura y una solución BPM -fledge completo (por ejemplo Oracle BPM suite que contiene BPEL, rule engine, etc.), hay soluciones intermedias tal como jBPM o Windows Workflow Foundation y probablemente mucho de los demás. Estas soluciones intermedias suelen ser una buena solución de compromiso.

Answer 2

BPMS: una gran cantidad de casos de negocios comunes, casos de uso ya están implementados. Entonces solo debes saber cómo usarlo. Para un flujo de trabajo común, ni siquiera necesita escribir una sola línea de código, aunque en su mayoría tendría que escribir algunos scripts para cubrir cosas que aún no se han implementado.

Programación simple: solo use el IDE para hackear el código. El lado positivo: más control. ¿Lo negativo? Muchas veces se gasta en reescribir el código repetitivo. Y debes mantenerlos.

Por lo tanto, en pocas palabras, preferiría un sistema de gestión de procesos comerciales. Uno que yo recomendaría es ProcessMaker. Cuenta con un diseñador de procesos intuitivo que le permite diseñar flujo de trabajo con arrastrar y soltar. Y siempre puede escribir trigger para extender las funcionalidades del proceso. También es de código abierto.

Answer 3

En mi experiencia, los entornos de desarrollo proporcionados por los sistemas BPMS son de tercera clase, improductivos y prácticamente obligan a escribir código difícil de mantener, mal diseñado (debido a sus limitaciones). Casi todas las "características" (UI, integraciones, etc.) proporcionadas por el sistema BPMS con el que estoy familiarizado (el que vendió esa compañía llamada así por su base de datos) no valían el dinero que pagamos.

Si se ve obligado a utilizar BPMS, como desarrollador, mi consejo sería construir la mayor parte de su aplicación en un entorno de desarrollo convencional, como Java o .Net, construir lo menos posible en el entorno BPMS en sí, e integrar los dos. Lo único que debe ir en el BPMS es el mínimo para que el proceso de negocio funcione.

Answer 4

He trabajado con Biztalk en el pasado y más recientemente con JBPM. Mi opinión está sesgada en contra de BPM por las siguientes razones:

1. empinada curva de aprendizaje: Para hacer un trabajo de proceso, tengo que entender cómo funciona el sistema y funciona el editor. Ya es bastante difícil para un desarrollador entender el sistema, y ​​mucho menos un usuario de negocios. El arrastrar y soltar y la representación visual es una gran herramienta de demostración. Ciertamente impresiona a los gerentes (que en última instancia lo pagan), pero la productividad de un desarrollador simplemente disminuye.

2. No desarrolladores que cambian el flujo de trabajo: No he visto una solución de BPM hacerlo sin problemas. Aunque no se parece al código, haz clic derecho en la casilla y tienes que poner un código; de lo contrario, no funcionará. Entonces definitivamente necesitas un desarrollador para hacerlo. La mejor parte es que no es amigable para desarrolladores ni amigable para el usuario comercial, solo es fácil de usar para demostraciones.

3. Testablity y refactoring: es prácticamente imposible probar un BPMS. Usted tiene 'frameworks de pruebas unitarias' publicitados, pero la mayoría de ellos son pirateados y difíciles de usar.Recientemente probé el JBPM uno; Terminé escribiendo mucho código de pegamento y manejadores de flujos de trabajo falsos para hacerlo funcionar. Sin embargo, el factor decisivo para mí es la refactorización. Si el negocio cambia radicalmente, se trata de cómo debería verse un proceso de negocios, entonces, buena suerte, reorganizando las cajas, porque el simple hecho de reorganizarlas no funcionará, todas las variables vinculadas a los recuadros también deben reorganizarse. Preferiría el poder del IDE y las pruebas para refactorizar mi proceso comercial.

Si su aplicación tiene flujo de trabajo, entonces puede probar una biblioteca de flujo de trabajo (con o sin estado persistente). Todavía administrará sus flujos de trabajo sin toda la hinchazón que viene con un BPM. Si un usuario de una empresa necesita comprender el código, deje que la empresa prepare buenos diagramas de flujo de proceso y conviértalos en un buen código de dominio. Utiliza pruebas de aceptación del estilo de pepino para unir a los desarrolladores y al negocio. Un BPM es algo que trata de hacer demasiadas cosas y termina haciendo todas esas cosas mal.