NOTA:
La presente entrada es la traducción (no oficial) del articulo: "Lessons Learned: Best Practices for a Successful Introduction of Business Process Management (BPM)", publicado en el Service Technology Magazine
Abstract: BPM es compleja, costosa y a menudo falla! Si esta de acuerdo (en el año 2012+), entonces debería leer las siguientes reglas para implantar BPM correctamente en su próximo proyecto.
Caso de uso: Solicitud de crédito
Figura 1. Proceso de negocio para una solicitud de crédito
Mirando este caso de uso, permitanme discutir diferentes aspectos de BPM para aprender importantes buenas prácticas y errores en proyectos del mundo real.
Objetivos de BPM
BPM
intenta mejorar procesos continuamente. Por lo tanto puede ser descrito
como un "proceso de optimización de procesos". El alineamiento entre
negocio e IT es la clave para mejorar los procesos de forma continua. La
palabra importante aquí es "alineamiento". Esto no se refiere solamente
a IT! ni solamente al negocio! sino a trabajar juntos - uno de los
mayores desafíos en muchos proyectos BPM. Además de esto, BPM tiene
otros objetivos (a los que se pueden llegar como consecuencia del
alineamiento entre Negocio y IT):
- Incrementar la eficiencia
- Incrementar la transparencia
- Mejorar la calidad
- Reducir costos
- Habilitar nuevos modelos de negocio
Caso
de uso: El principal objetivo es alcanzar un alto grado de
transparencia y aumentar la comunicación entre el negocio e IT. Cuando
incorporamos BPM, la atención debe centrarse en este objetivo desde el
principio. El objetivo tiene que ser apoyado y hecho transparente
por los que toman las decisiones. Sería un error incorporar BPM sin
alguno de los objetivos clave. Adicionalmente, los indicadores de
desempeño (PKIs)también deben ser definidos para medir el éxito de BPM.
Regla 1: Si quiere introducir BPM correctamente, tenga en cuenta que su objetivo principal es mejorarla alineación entre negocio e IT!
BPM y SOA
Muchos riesgos se deben considerar cuando se persigue BPM sin SOA ya que las ventajas de BPM no se pueden obtener sin los servicios [REF-4].
Caso de uso: La solicitud de crédito ya está dividida en varios servicios bajamente acoplados (script y servicios de tarea en Java, interacciones humanas). Por lo tanto, está lista para ser realizada con BPM. Si todo es considerado como un silo, BPM no sería posible, y una mayor flexibilidad y eficiencia no podrían ser alcanzadas.
Regla 2: Si quiere introducir BPM correctamente, entonces no intente hacerlo sin arquitectura orientada a servicios!
Ciclo de vida BPM
Por supuesto, las herramientas deben apoyar todo el ciclo de vida. Por lo tanto, las herramientas BPM deben ser evaluadas después de que algunos procesos son modelados y diseñados, y cuando está claro cómo serán ejecutados y controlados los procesos de negocio.
Es importante introducir BPM iterativamente. No trate de "realizar la tarea titánica de tratar de implementar una solución BPM / SOA para un grupo empresarial completo o división haciendo un cambio completo de la organización. Los esfuerzos BPM y SOA son intrínsecamente evolutivos, así que son mejor implementados en pequeño, de forma restringida y liberando capacidades a intervalos frecuentes que se agreguen sobre las otras.". [REF-5]
Caso de uso: Iniciar escogiendo una herramienta y luego comenzar la realización es un enfoque equivocado, y puede llevar rápidamente al fracaso. Varios requerimientos pueden ser desconocidos al principio del proyecto. Por ejemplo, pueden no haber sido definidas reglas de negocio complejas. Así pues, una herramienta de BPM que integra un motor complejo (y caro) de reglas sería una muy mala decisión. Seguir el ciclo de vida de BPM iterativamente reduce esfuerzos, ayuda a analizar servicios y roles existentes, y permite la reutilización de conocimiento disponible y código fuente existente.
Regla
3: Si quiere hacer BPM correctamente, debe ser consciente que BPM no es
sólo herramientas, sino un proceso de ingeniería con un ciclo de vida
grande e iterativo!
Beneficios de BPM
Caso de uso: BPM es una excelente opción precisamente para los flujos de trabajo de larga duración con estado y que cuentan con interacción humana. Varios beneficios se obtienen, por ejemplo, una mayor transparencia y una mayor flexibilidad. La introducción de BPM se paga rápidamente. Implementar tal lógica de proceso uno mismo representa un gran esfuerzo, es propenso a errores, y simplemente innecesario.
Regla 4: Si quiere hacer BPM correctamente, entonces úselo solamente cuando realmente pueda obtener beneficios!
Mitos de BPM
1. Los analistas de negocio VAN a crear modelos de procesos ejecutables
2. Los analistas de negocio PUEDEN crear modelos de procesos ejecutables
3. Los analistas de negocio QUIEREN crear modelos de procesos ejecutables
4.El departamento de IT QUIERE que los analistas de negocio creen modelos de procesos ejecutables
Siempre van a existir personas en el negocio y en IT, y van a tener una comprensión diferente de las cosas. Las personas de negocio nunca serán capaces de modelar procesos de negocio complejos. Por lo tanto, la alineación entre negocio e IT es muy importante, y las herramientas no pueden resolver este problema. Negocio e IT tienen que trabajar juntos para hacer BPM con éxito.
Caso de uso: Los analistas de negocio tienen mucho conocimiento sobre el procedimiento de solicitud de préstamo. Si es posible, deje que ellos modelen el proceso. Los desarrolladores apenas añaden detalles técnicos. Sin embargo, mucha gente del lado del negocio no puede pensar de esta forma, o simplemente no quieren hacerlo. Por otro lado, los desarrolladores aprendieron esta forma de pensamiento y a modelar desde el inicio. Está bien si los desarrolladores modelan todos los procesos de negocio. Es mucho más importante traer la gente del negocio. Llevar a cabo reuniones para recabar información, a continuación, modelar procesos y realizar reuniones de revisión. Finalmente itere este proceso.
Regla 5: Si quiere hacer BPM correctamente, entonces no crea en los mitos de BPM!
Estándares BPM
El estándar más importante de BPM es BPMN [REF-7] (Business Process Model and Notation) - por lo menos desde la versión 2.0 (liberada en marzo de 2011). BPMN 2.0 añade un formato de descripción XML estandarizado. Ahora, BPMN no son sólo diagramas de flujo:cuenta con restricciones y limitaciones para especificar la ejecución de procesos de negocio de manera no ambigua. Otra novedad importante BPMN 2.0 son sus puntos de extensión estandarizados (ya que todos los proveedores siempre añaden sus propias características específicas de un producto). Por ejemplo, el framework BPM de código abierto Activiti ofrece una extensión para servicios de tarea Java.
WSBPEL [REF-8] (Web Services Business Process Execution Language, en su formacorta: BPEL) es la segunda norma BPM más importante. Sin embargo, BPEL sólo se puede utilizar para la ejecución de servicios web SOAP. Debido al hecho de que BPMN 2.0 también incluye la ejecución de procesos de negocio, los nuevos productos no necesitan utilizar BPEL para su ejecución. Sin embargo, una implementación de BPMN 2.0 se debe alinear a BPEL para ser 100% estándar. Si se pregunta acerca es la relación entre BPMN 2.0 y BPEL 2.0 y si BPMN 2.0 hace BPEL 2.0 redundante, entonces debe leer la interesante entrevista a [REF-9].
Caso de uso: BPMN es el estándar de facto para BPM en el 2012+. Es adecuado para las personas de negocio y de IT, y puede ser utilizado para el modelado y la ejecución. Muchas otras normas son obsoletas o demasiado complejas. Elegir WS-BPEL lugar de BPM añadiría varias restricciones y podría aumentar la complejidad. Si la herramienta disponible en su organización sólo admite WS-BPEL, puede seguir utilizando BPMN para el modelado y WS-BPEL para su ejecución.
Regla 6: Si quiere hacer BPM correctamente, entonces utilice BPMN 2.0!
Herramientas BPM
Error! Este procedimiento podría funcionar para la mayoría de las comparaciones de productos o frameworks. A menudo yo mismo me creé estas listas criterios. Sin embargo, para las herramientas BPM, hay un criterio importante, que debe ser discutido antes de mirar todos los demás: ¿Quiere usar una herramienta centrada en el desarrollador o una herramienta centrada en el diseñador?
¿Por qué son tan diferentes?
Por otro lado, están las herramientas centradas en el diseñador, que prometen cero codificación. Estas herramientas son productos reales, no sólo frameworks embebidos. Usted no escribe código fuente. Crea los procesos de negocio en un diseñador gráfico haciendo drag and drop. No se requiere codificación. Decida usted mismo si esto es un pro o un contra. A veces, cero codificación podría ser un contra (recuerde los cuatro mitos sobre BPM -el analista de negocios no puede modelar los procesos de negocio). Si no se puede codificar algo o si tiene que utilizar workarounds, entonces esta situación puede llegar a convertirse en un problema bloqueante para los proyectos del mundo real, donde la herramienta no ofrece la característica que se requiere.
Además de las pesadas herramientas BPM propietarias de los grandes proveedores como Oracle o IBM, también existen algunas herramientas de código abierto centradas en el diseñador disponibles en el mercado, por ejemplo, ProcessMaker o Bonita Open Solution. Son fáciles de instalar y aprender. Usualemnte, estas herramientas open source no son tan poderosas como lo son los productos propietarios. Sin embargo, puede agregar la funcionalidad requerida por sí mismo, ya que son de código abierto.
Regla 7: Si quiere hacer BPM correctamente,entonces seleccione la herramienta BPM adecuada para el trabajo!
BPM e integración de sistemas
Pero, ¿es esta una buena solución? Puede estar bien, si sólo tiene que llamar a uno o dos servicios en su proceso. En todos los demás casos, la palabra mágica (s) es "la separación de problemas" (separation of concerns). De lo contrario, va a terminar con complejas soluciones tipo espaguetti. Por ello, SOA es tan importante para la introducción de BPM.
Una herramienta de BPM no es una herramienta de integración, sino un motor de procesos (más algunos complementos, por supuesto). Utilice BPM por sus beneficios, por ejemplo,llevar a cabo la ejecución de procesos de larga duración con estado o interacciones humanas. Para la integración de sistemas, utilice una herramienta construida para este tipo de trabajo, es decir, un framework de integración ligero como Apache Camel, o un Enterprise Service Bus (ESB) como el IBM WebSphere Message Broker. Wolfgang Pleus escribió una gran entrada de blog sobre como combinar de un motor de BPM y un framework de integración [REF-10].
Caso de uso: Algunos de los servicios técnicos tienen que ser llamados desde el proceso de solicitud de crédito. Se requiere conocimiento técnico profundo para el enrutamiento, la transformación y la conectividad con diferente sistemas. Por lo tanto, esta lógica debe estar separada de la lógica del proceso. El proceso de negocio sólo contiene las interfaces. El resto de la lógica de integración se realiza con una solución de integración. Esfuerzo de aplicar la técnica "separation of concerns" es bajo debido a una base SOA flexible y bajamente acoplada.
Regla 8: Si quiere hacer BPM correctamente, entonces no lo use para integración de sistemas!
modernos
tales como BPM, cloud computing o mashups. Así, "BPM basado en SOA es
la respuesta de la tecnología a la creciente demanda de un entorno
empresarial flexible que no se ve obstaculizado por silos de
aplicaciones. La tecnología de integración debe acoplar bajamente las
aplicaciones y los recursos que componen el proceso, de lo contrario la
lógica de un proceso quedará hard-codeada en una plataforma tecnológica
particular, lo cual puede ser costoso de cambiar, lo que puede ir en
contra del propósito completo de BPM ". [REF-3]
Muchos riesgos se deben considerar cuando se persigue BPM sin SOA ya que las ventajas de BPM no se pueden obtener sin los servicios [REF-4].
Caso de uso: La solicitud de crédito ya está dividida en varios servicios bajamente acoplados (script y servicios de tarea en Java, interacciones humanas). Por lo tanto, está lista para ser realizada con BPM. Si todo es considerado como un silo, BPM no sería posible, y una mayor flexibilidad y eficiencia no podrían ser alcanzadas.
Permitanme
primero decir que no es BPM: BPM no son sólo herramientas. En lugar de
esto, BPM es parte de la ingeniería de procesos y cuenta con varios
actores, tecnologías y herramientas diferentes. El ciclo de vida de BPM
es iterativo y tiene las siguientes fases:
- Diseño
- Modelamiento
- Ejecución
- Monitorización
- Optimización
- Iniciar de nuevo: Diseño
Por supuesto, las herramientas deben apoyar todo el ciclo de vida. Por lo tanto, las herramientas BPM deben ser evaluadas después de que algunos procesos son modelados y diseñados, y cuando está claro cómo serán ejecutados y controlados los procesos de negocio.
Es importante introducir BPM iterativamente. No trate de "realizar la tarea titánica de tratar de implementar una solución BPM / SOA para un grupo empresarial completo o división haciendo un cambio completo de la organización. Los esfuerzos BPM y SOA son intrínsecamente evolutivos, así que son mejor implementados en pequeño, de forma restringida y liberando capacidades a intervalos frecuentes que se agreguen sobre las otras.". [REF-5]
Caso de uso: Iniciar escogiendo una herramienta y luego comenzar la realización es un enfoque equivocado, y puede llevar rápidamente al fracaso. Varios requerimientos pueden ser desconocidos al principio del proyecto. Por ejemplo, pueden no haber sido definidas reglas de negocio complejas. Así pues, una herramienta de BPM que integra un motor complejo (y caro) de reglas sería una muy mala decisión. Seguir el ciclo de vida de BPM iterativamente reduce esfuerzos, ayuda a analizar servicios y roles existentes, y permite la reutilización de conocimiento disponible y código fuente existente.
BPM
no es una navaja suiza, que puede resolver todos los problemas. No
utilice BPM en situaciones equivocadas. No me gusta ver a la gente
usando herramientas de BPM sólo porque hay un flujo de trabajo. No se
necesita una herramienta de BPM para realizar un workflow. En este caso,
se puede utilizar (por ejemplo) un método Java que hace algo de lógica
de negocio, y luego llama a otro método Java que hace algo de lógica de
negocio, y luego llama a otro método Java, y así sucesivamente ...
BPM trae beneficios especialmente si usted necesita:
- Flujos de trabajo de larga ejecución con estado
- Procesos que cambian frecuentemente
- Interacción humana
Caso de uso: BPM es una excelente opción precisamente para los flujos de trabajo de larga duración con estado y que cuentan con interacción humana. Varios beneficios se obtienen, por ejemplo, una mayor transparencia y una mayor flexibilidad. La introducción de BPM se paga rápidamente. Implementar tal lógica de proceso uno mismo representa un gran esfuerzo, es propenso a errores, y simplemente innecesario.
John Cingari ha definido cuatro mitos de los proyectos BPM, que son verdad en la mayoría de las organizaciones [REF-6]:
1. Los analistas de negocio VAN a crear modelos de procesos ejecutables
2. Los analistas de negocio PUEDEN crear modelos de procesos ejecutables
3. Los analistas de negocio QUIEREN crear modelos de procesos ejecutables
4.El departamento de IT QUIERE que los analistas de negocio creen modelos de procesos ejecutables
Siempre van a existir personas en el negocio y en IT, y van a tener una comprensión diferente de las cosas. Las personas de negocio nunca serán capaces de modelar procesos de negocio complejos. Por lo tanto, la alineación entre negocio e IT es muy importante, y las herramientas no pueden resolver este problema. Negocio e IT tienen que trabajar juntos para hacer BPM con éxito.
Caso de uso: Los analistas de negocio tienen mucho conocimiento sobre el procedimiento de solicitud de préstamo. Si es posible, deje que ellos modelen el proceso. Los desarrolladores apenas añaden detalles técnicos. Sin embargo, mucha gente del lado del negocio no puede pensar de esta forma, o simplemente no quieren hacerlo. Por otro lado, los desarrolladores aprendieron esta forma de pensamiento y a modelar desde el inicio. Está bien si los desarrolladores modelan todos los procesos de negocio. Es mucho más importante traer la gente del negocio. Llevar a cabo reuniones para recabar información, a continuación, modelar procesos y realizar reuniones de revisión. Finalmente itere este proceso.
Los
estándares son importantes para BPM para hacerlo a prueba de cambios
futuros e independiente del proveedor. De esta manera, diferentes
herramientas se pueden utilizar para diferentes fases / por diferentes
personas. Una gran cantidad de estándares existen para BPM, tales como
BPMN, XPDL, BPEL, jPDL, WF-XML, ARIS EPC y entre otros.
El estándar más importante de BPM es BPMN [REF-7] (Business Process Model and Notation) - por lo menos desde la versión 2.0 (liberada en marzo de 2011). BPMN 2.0 añade un formato de descripción XML estandarizado. Ahora, BPMN no son sólo diagramas de flujo:cuenta con restricciones y limitaciones para especificar la ejecución de procesos de negocio de manera no ambigua. Otra novedad importante BPMN 2.0 son sus puntos de extensión estandarizados (ya que todos los proveedores siempre añaden sus propias características específicas de un producto). Por ejemplo, el framework BPM de código abierto Activiti ofrece una extensión para servicios de tarea Java.
WSBPEL [REF-8] (Web Services Business Process Execution Language, en su formacorta: BPEL) es la segunda norma BPM más importante. Sin embargo, BPEL sólo se puede utilizar para la ejecución de servicios web SOAP. Debido al hecho de que BPMN 2.0 también incluye la ejecución de procesos de negocio, los nuevos productos no necesitan utilizar BPEL para su ejecución. Sin embargo, una implementación de BPMN 2.0 se debe alinear a BPEL para ser 100% estándar. Si se pregunta acerca es la relación entre BPMN 2.0 y BPEL 2.0 y si BPMN 2.0 hace BPEL 2.0 redundante, entonces debe leer la interesante entrevista a [REF-9].
Caso de uso: BPMN es el estándar de facto para BPM en el 2012+. Es adecuado para las personas de negocio y de IT, y puede ser utilizado para el modelado y la ejecución. Muchas otras normas son obsoletas o demasiado complejas. Elegir WS-BPEL lugar de BPM añadiría varias restricciones y podría aumentar la complejidad. Si la herramienta disponible en su organización sólo admite WS-BPEL, puede seguir utilizando BPMN para el modelado y WS-BPEL para su ejecución.
Existen
innumerables productos BPM disponibles en el mercado. ¿Cómo decidir
cuál elegir? Puede hacer una evaluación comparando varios criterios, por
ejemplo:
- Open Source vs Propietario
- Tecnologías soportadas
- Estándares soportados
- Diseñador GUI
- Comunidad, Documentación, Soporte Comercial
- ... etcétera
¿Cierto?
Error! Este procedimiento podría funcionar para la mayoría de las comparaciones de productos o frameworks. A menudo yo mismo me creé estas listas criterios. Sin embargo, para las herramientas BPM, hay un criterio importante, que debe ser discutido antes de mirar todos los demás: ¿Quiere usar una herramienta centrada en el desarrollador o una herramienta centrada en el diseñador?
¿Por qué son tan diferentes?
Una
herramienta centrada en el desarrollador como Activiti o JBoss jBPM
está integrada directamente en su contenedor o en una aplicación
standalone. Aquí se utilizan las herramientas y entornos de desarrollo
que se usan comúnmente. Se escribe el código fuente incluyendo las
pruebas unitarias correspondientes. Por lo general, las herramientas
enfocadas a desarrolladores son muy livianas y fáciles de usar, de
código abierto y ofrecen un API para su lenguaje preferido (por ejemplo,
Activiti es basado en Java). Puede comenzar a usarlo después de algunos
minutos. Las herramientas de código abierto centradas en el
desarrollador, sin embargo, no son perfectas. Por ejemplo, con
frecuencia proveen mala documentación y una interfaz web muy
rudimentaria para el modelado y monitoreo.
Por otro lado, están las herramientas centradas en el diseñador, que prometen cero codificación. Estas herramientas son productos reales, no sólo frameworks embebidos. Usted no escribe código fuente. Crea los procesos de negocio en un diseñador gráfico haciendo drag and drop. No se requiere codificación. Decida usted mismo si esto es un pro o un contra. A veces, cero codificación podría ser un contra (recuerde los cuatro mitos sobre BPM -el analista de negocios no puede modelar los procesos de negocio). Si no se puede codificar algo o si tiene que utilizar workarounds, entonces esta situación puede llegar a convertirse en un problema bloqueante para los proyectos del mundo real, donde la herramienta no ofrece la característica que se requiere.
Las
herramientas propietarias centradas en el diseñador son soluciones muy
costosas y pesadas (por ejemplo, usted no solo necesita comprar e
instalar la Oracle BPEL suite, sino también Oracle WebLogic Application
Server, y varios otros productos del stack de Oracle). Si inicia a
instalar la suite un día, probablemente no será capaz de utilizarlo al
menos hasta el segundo día (porque la instalación es muy compleja y
lenta). A diferencia de las herramientas de código abierto enfocadas en
el desarrollador, los productos propietarios ofrecen una gran
estabilidad, interfaces web potentes y una buena integración en otras
partes de su entorno de desarrollo (si se utiliza todo el stack de un
proveedor).
Además de las pesadas herramientas BPM propietarias de los grandes proveedores como Oracle o IBM, también existen algunas herramientas de código abierto centradas en el diseñador disponibles en el mercado, por ejemplo, ProcessMaker o Bonita Open Solution. Son fáciles de instalar y aprender. Usualemnte, estas herramientas open source no son tan poderosas como lo son los productos propietarios. Sin embargo, puede agregar la funcionalidad requerida por sí mismo, ya que son de código abierto.
Por
lo tanto, la primera pregunta a responder para escoger una herramienta
de BPM es: ¿Necesito/quiero una herramienta centrada en el desarrollador
o una herramienta centrada en el diseñador? Después de haber tomado
esta decisión, pueden evaluar las herramientas BPM por otros criterios:
¿Qué características son soportadas(por ejemplo, un motor de reglas
complejas)? Es la herramienta extensible, puede otro software ser
integrado fácilmente? ¿Qué tecnologías soporta? ¿Cómo se monitorizarán
los procesos de negocio? Y así sucesivamente ...
Caso
de uso: La lógica de proceso de la solicitud de crédito sólo contiene
información de negocio. No se necesitan lógicas o flujos complejos.
Información técnica no es importante a este nivel. Por lo tanto, los
analistas de negocio son capaces de modelar este proceso.
Posteriormente, los desarrolladores sólo tiene que añadir interfaces
técnicas para su ejecución. Este caso de uso es una combinación perfecta
para un producto ligero, orientado al diseñador.
Se
puede utilizar una herramienta de BPM para integrar sistemas. Por
ejemplo, existe un servicio de tarea estándar en BPMN para los servicios
web SOAP. De esta forma, usted puede utilizar la tecnología que desee.
Además, se pueden usar servicios de tarea tipo script (por ejemplo,
Groovy o JavaScript), servicios de tarea Java (como extensión), entre
otros.
Pero, ¿es esta una buena solución? Puede estar bien, si sólo tiene que llamar a uno o dos servicios en su proceso. En todos los demás casos, la palabra mágica (s) es "la separación de problemas" (separation of concerns). De lo contrario, va a terminar con complejas soluciones tipo espaguetti. Por ello, SOA es tan importante para la introducción de BPM.
Una herramienta de BPM no es una herramienta de integración, sino un motor de procesos (más algunos complementos, por supuesto). Utilice BPM por sus beneficios, por ejemplo,llevar a cabo la ejecución de procesos de larga duración con estado o interacciones humanas. Para la integración de sistemas, utilice una herramienta construida para este tipo de trabajo, es decir, un framework de integración ligero como Apache Camel, o un Enterprise Service Bus (ESB) como el IBM WebSphere Message Broker. Wolfgang Pleus escribió una gran entrada de blog sobre como combinar de un motor de BPM y un framework de integración [REF-10].
Caso de uso: Algunos de los servicios técnicos tienen que ser llamados desde el proceso de solicitud de crédito. Se requiere conocimiento técnico profundo para el enrutamiento, la transformación y la conectividad con diferente sistemas. Por lo tanto, esta lógica debe estar separada de la lógica del proceso. El proceso de negocio sólo contiene las interfaces. El resto de la lógica de integración se realiza con una solución de integración. Esfuerzo de aplicar la técnica "separation of concerns" es bajo debido a una base SOA flexible y bajamente acoplada.
Referencias:
[REF-1] Business Process Management (BPM) http://en.wikipedia.org/wiki/Business_process_management
[REF-2] SOA is dead http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html
[REF-3] SOA and BPM http://www.information-management.com/issues/20070501/1082553-1.html
[REF-4] Risks of BPM without SOA (http://artofsoftwarereuse.com/2009/09/03/risks-with-pursuing-bpm-without-soa/)
[REF-5] BPM Lifecycle http://www.ebizq.net/topics/bpm/features/11569.html
[REF-6] BPM Myths http://www.activevos.com/blog/soa/the-four-myths-of-bpm-projects-what-it-project-teams-need-to-know/2011/01/18/
[REF-7] Business Process Modeling and Notation (BPMN) http://www.bpmn.org/
[REF-8] WS-BPEL http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel
[REF-9] BPMN 2.0 and WS-BPEL www.infoq.com/articles/bpmn-2
[REF-10] Combination of a BPM Engine and an Integration Framework http://www.pleus.net/blog/?p=1028
[REF-1] Business Process Management (BPM) http://en.wikipedia.org/wiki/Business_process_management
[REF-2] SOA is dead http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html
[REF-3] SOA and BPM http://www.information-management.com/issues/20070501/1082553-1.html
[REF-4] Risks of BPM without SOA (http://artofsoftwarereuse.com/2009/09/03/risks-with-pursuing-bpm-without-soa/)
[REF-5] BPM Lifecycle http://www.ebizq.net/topics/bpm/features/11569.html
[REF-6] BPM Myths http://www.activevos.com/blog/soa/the-four-myths-of-bpm-projects-what-it-project-teams-need-to-know/2011/01/18/
[REF-7] Business Process Modeling and Notation (BPMN) http://www.bpmn.org/
[REF-8] WS-BPEL http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel
[REF-9] BPMN 2.0 and WS-BPEL www.infoq.com/articles/bpmn-2
[REF-10] Combination of a BPM Engine and an Integration Framework http://www.pleus.net/blog/?p=1028
No hay comentarios:
Publicar un comentario