Pregunta

¿Qué prefiere (desde el punto de vista de su desarrollador) cuando se trata de implementar un proceso de negocio?

¿Un sistema de gestión de procesos de negocio (BPMS) o simplemente su IDE favorito con las herramientas y marcos necesarios (una herramienta de generación 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?

DE ACUERDO.Quizás debería ser más específico...Conocí un BPMS específico que debería facilitar la implementación de un proceso de negocio 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 pueda 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 las que puedo usar Java, pero aun así tengo que ceñirme al editor de sistemas sin Intellisense, etc.

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

Entonces tal vez la pregunta más específica sea:¿Sientes lo mismo o existen BPMS que te ayudan a ser desarrollador y pensar como desarrollador o la mayoría de ellos te obligan a hacer tu trabajo de una manera diferente?

¿Fue útil?

Solución

No está seguro de qué es exactamente lo pide, pero la elección de BPM vs programación normal dependerá de los requisitos. Un "proceso de negocio" es un término relativamente vaga 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,,, modificable complicada configurable
  • ?
  • la volatilidad del proceso - ¿Con qué frecuencia lo hace el cambio de proceso? ¿Quién debe ser capaz de hacer el cambio?
  • de integración deben -? Es su proceso de realizar utilizando múltiples servicios heterogéneos, o se implementan en el mismo idioma
  • síncrono / asíncrono -? Es su proceso de "larga duración" con la necesidad de manejar las acciones asíncronos
  • tareas humanas - ¿Su proceso consiste en la interacción humana, con la que se le asigna la tarea / encaminado a las personas de acuerdo a sus roles / responsabilidades
  • ?
  • seguimiento del proceso - ¿Cuál es el nivel de control que desea en las instancias de proceso existentes que se está ejecutando? ¿Es necesario auditar las acciones, etc.?
  • tratamiento de errores -? Dependiendo de los puntos anteriores, ¿cómo va a lidiar con los errores, o volver a intentar de ejecución de procesos defectuosos

En función de la respuesta a estas preguntas, usted puede darse cuenta de que su proceso está más cerca de un simple estado carta con unas pocas acciones y decisiones que pueden ser ejecutados en una secuencia, o puede darse cuenta de que se necesita algo más elaborado, y que no desea volver a poner en práctica todo lo que usted mismo.

Entre programación llanura y un solución BPM-fledge completo (por ejemplo, Oracle BPM Suite que contiene BPEL , motor de reglas, etc.), hay soluciones intermedias como < a href = "http://www.jboss.com/products/jbpm/" rel = "noreferrer"> jBPM o Windows Workflow Foundation y probablemente muchos otros. Estos solución intermedia son frecuentemente buena compensación.

Otros consejos

En mi experiencia de los entornos de desarrollo que ofrecen los sistemas BPMS son de tercera categoría, improductivo, y prácticamente le obligan a escribir difícil de mantener, mal código diseñado (debido a sus limitaciones). Casi todas las "características" (UI, integraciones, etc.) proporcionados por el sistema BPMS Estoy familiarizado con (el vendido por esa compañía lleva el nombre de su base de datos) no vale la pena el dinero que pagamos.

Si uno se ve obligado a utilizar BPMS, como desarrollador, mi consejo sería construir mayor cantidad de su aplicación en un entorno de desarrollo convencional, como Java o .Net, construir lo menos posible en el propio entorno de BPMS e integrar los dos. Las únicas cosas que deben ir en el BPMS es el mínimo para hacer que el proceso de negocio.

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

  1. Curva de aprendizaje pronunciada:Para que un proceso funcione, tengo que entender cómo funciona el sistema y el editor.Ya es bastante difícil para un desarrollador entender el sistema, y ​​mucho menos para un usuario empresarial.La representación visual y de arrastrar y soltar es una excelente herramienta de demostración.Ciertamente impresiona a los gerentes (que finalmente pagan por ello), pero la productividad de un desarrollador simplemente cae.

  2. Los no desarrolladores cambian el flujo de trabajo:No he visto una solución BPM que lo haga a la perfección.Aunque no parece código, haga clic derecho en el cuadro y tendrá que poner algo de código; de lo contrario, no funcionará.Entonces definitivamente necesitas un desarrollador para hacerlo.La mejor parte es que no es fácil de usar para desarrolladores ni para empresas, solo es fácil de usar para demostraciones.

  3. Comprobabilidad y refactorización:Es prácticamente imposible probar un BPMS.Se anuncian 'marcos de prueba unitaria', pero la mayoría de ellos son trucos y difíciles de usar.Recientemente probé el JBPM;Terminé escribiendo una gran cantidad de código adhesivo y controladores de flujo de trabajo falsos para que funcionara.Sin embargo, el factor decisivo para mí es la refactorización.Si la empresa cambia radicalmente de opinión sobre cómo debe verse un proceso de negocio, entonces buena suerte reorganizando las cajas, porque simplemente reorganizarlas no funcionará, todas las variables vinculadas a las cajas también deben reorganizarse.Preferiría el poder del IDE y las pruebas para refactorizar mi proceso comercial.

Si su aplicación tiene un flujo de trabajo, puede probar una biblioteca de flujo de trabajo (con o sin estado persistente).Seguirá gestionando sus flujos de trabajo sin toda la sobrecarga que conlleva un BPM.Si un usuario empresarial necesita comprender el código, deje que la empresa prepare buenos diagramas de flujo de procesos y los traduzca en un buen código controlado por el dominio.Utilice pruebas de aceptación de estilo pepino para unir a los desarrolladores y las empresas.Un BPM es simplemente algo que intenta hacer demasiadas cosas y termina haciéndolas todas mal.

BPMS-- una gran cantidad de casos de negocio común, caso de uso ya se encuentran. Por lo que sólo tiene que saber cómo usarlo. Para flujo de trabajo común, que ni siquiera tiene que escribir una sola línea de código, aunque sobre todo tendría que escribir algunos guiones para cubrir lo que aún no se implementan.

Plain programming-- sólo tiene que utilizar el IDE para piratear el código. El lado positivo: más control. ¿Lo negativo? Muchas veces se gastan en volver a escribir código repetitivo. Y hay que mantenerlas.

Así que en pocas palabras, yo preferiría un Sistema de Gestión de Procesos de Negocio. Uno que yo recomendaría es ProcessMaker . Cuenta con un diseñador de proceso intuitivo que le permite diseñar el flujo de trabajo con arrastrar y soltar. Y siempre se puede escribir gatillo para extender las funcionalidades de proceso. Es de código abierto también.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top