Como encaja jBPM en el mercado? (Introducción)

Que tema complicado para escribir, ya que conozco poco de estrategias de marketing y mucho menos sobre la política por parte de JBoss para vender servicios sobre el producto jBPM.

La idea de este post es comentar algunas ideas que se me han venido a la cabeza al darme cuenta de que la competencia directa de JBoss y jBPM , tiene algunas estrategias de entrada al mercado que actualmente no he visto por parte de Red Hat/JBoss.

El planteo general es tratar de encontrar una manera real aca en la Argentina (por nombrar un pais donde  la situación del mercado es bastante especial) de poder acercar jBPM a los clientes finales o por lo menos que las empresas en el mercado empiecen a conocer el producto.

Para todo esto creo que hay dos cosas que hay que tener en claro:

  1. Limitaciones del producto
  2. Estrategias de venta

Limitaciones del Producto:

jBPM (www.jbpm.org) es un producto que nos permite tecnicamente resolver un gran rango de situaciones que involucren cualquier tipo de proceso que pueda ser representado por un grafo dirigido. Esto es, representar un proceso de negocio empresarial, orquestación de servicios, workflows de documentos, o cualquier caso donde tengamos que representar un proceso a cualquier escala en cualquier rubro de la industria.

A nivel técnico el producto ya tiene una madurez bastante importante y estan bien delimitadas las funcionalidades que se pueden obtener del mismo. Y creo que ahi es donde empiezan algunos de los problemas y los puntos que debemos analizar.

Las funcionalidades y alcances que propone jBPM están perfectas a nivel técnico ya que los problemas que nos permite solucionar presentan grandes ventajas con los métodos normales de programación se utilizan actualmente en el mercado.

El problema principal viene dado a otro nivel, y es un nivel mucho menos técnico y de apreciación mas “marketinera”, a lo que me refiero exactamente es que jBPM al ser un producto Open Source, guiado por la comunidad, no esta pensado para satisfacer la parte mas visible para un usuario final o un cliente que pueda llegar a verse interesado. El planteo de JBoss y la comunidad en general es mas que nada proveer a los desarrolladores una biblioteca de clases que nos permita programar cumpliendo la disciplina de BPM y dándonos un motor de ejecución bastante maduro (se encuentra en la versión 3.2.2 actualmente y la versión 4.0 ya tiene fecha aproximada de salida) que nos permite ejecutar nuestros procesos en entornos de producción.

Y entonces porque lo nombre como problema? porque en realidad esta visión, en gran parte dada por la comunidad, deja al producto afuera de toda apreciación comercial, ya que lo visible para los clientes es bastante técnico y carece de herramientas de facil uso por personas que no se encuentran altamente capacitadas para utilizar herramientas de desarrollo.

Para citar algunos ejemplos de esto, basta con decir que cuando queremos empezar a usar jBPM de la pagina oficial bajamos un jar (archivo de bibliotecas Java) y que el único diseniador gráfico de procesos es un plug in para una herramienta de desarrollo.

Cómo solucionamos esto? es la pregunta que surge a simple vista. Y la respuesta no es para nada alegre, ya que la solución seria dedicar horas de desarrollo (de la comunidad, o de los mismos empleados de JBoss) de estas herramientas que cumplan con la funcionalidad de simplificar la interacción de los usuarios finales (analistas de negocio en gran parte) con la herramienta. Tema que es complicado ya que por lo general en este tipo de proyectos son las partes que mas cuestan, ya que la mayoría de los desarrolladores que están al nivel para desarrollar herramientas complejas no están entrenados para el desarrollo de aplicaciones orientadas a usuarios finales y menos aun se cuenta con gente especializada en estos temas.

Cabe también destacar que jPDL, el lenguaje de descripción de procesos que utiliza por “defecto” el motor de jBPM (me refiero a jPDL – JBoss/Java Process Definition Language), si bien es extensible, carece de extensiones básicas para el momento donde necesitamos representar procesos de negocios donde por lo general necesitamos poder representar tiempos asociados a cada tarea dentro del proceso y costos asociados al mismo(O asociado a los recursos que realizan ciertas tareas) . Estos dos detalles (falta de tiempos y costos) producen que nos veamos obligados a extender el lenguaje y tener que programar una extensión para administrar estos cálculos.

Estrategias de venta:

Parte oscura si las hay…, al parecer no existe una estrategia específicamente dedicada a implementaciones de BPM por parte de JBoss / Red Hat, ya que las estrategias o productos que actualmente ofrece JBoss son distintas plataformas que incluyen a BPM como es la SOA Platform que además de BPM incluye productos como JBoss Rules (Drools), JBoss ESB, y los clásicos (JBoss AS, Hibernate, etc).

Conclusión:

Teniendo en cuenta estos dos puntos, seguiré posteando algunas de las cosas que tiene que ver con jBPM y la apreciación del mercado Argentino sobre este tipo de productos (apreciación personal). También tratare de definir las herramientas que actualmente faltan y algún proceso (serie de tareas) que pueda ayudar a involucrar mas a los clientes con jBPM.

Espero un poco de feedback para poder tener post mas elaborados.. sientanse comodos de aportar..de criticar y de dejar sus ideas..

Advertisements

3 thoughts on “Como encaja jBPM en el mercado? (Introducción)”

  1. Hola, estoy intentando recopilar algo de informacion acerca de jBPM, para decidir si es una buena solucion para implementar un flujo de trabajo, y me gustaria preguntarte, si es posible definir la estrucutura del mismo (y que este sea realmente funcional no del estilo de los ejemplos de “Hello world” o el “bussines trip request” que viene con la suite de jBPM3.2.3), de forma mas o menos grafica(mediante el plugin para eclipse), sin que se necesiten demasiados conocimientos de programacion Java, ya que por lo que he visto, la unica forma de definir las acciones es mediante la creacion de clases que implementan la interface ActionHandler, y que no pueden ser generadas de forma “grafica”, sino solo mediante la escritura de los ficheros de clase correspondientes. Lo de q no se necesiten demasiados conocimientos de programacion, es debido a que los futuros usuarios, yo creo que podrian aprender a crear nuevos flujos con el Eclipse y el GPD, pero no podemos suponer que para crearlos sean capaces de desarrollar sus propias clases para las acciones que necesiten implementar.
    Ummm me salio un poco lioso.. creo..
    Bueno en cualquier caso gracias por tus post y espero que sigas añadiendo mas informacion ya q me estas ayudando mucho.
    Por cierto .. sabes si con la suite Pentaho es posible desarrollar workflows porque creo que a partir de la version 1.7 dejaron de incluir el modulo de creacion de workflow.

    .

    Like

  2. Primero que nada gracias por tu comentario! Espero que sirvan los Post para ir aclarando un poco los concepto de este producto Open Source.

    Como respuestas a tus preguntas puedo comentarte que tienes a GPD como plug in de ecplise para diagramar tus procesos nuevos y a JBPM Web Console para ejecutarlos.

    Tambien me parece preciso contarte de que aparte de escribir los ActionHandlers en Java puedes escribir logica sencilla con expresiones de JSF para resolver temas sencillos como tomar decisiones, imprimir valores de variables, y cosas por el estilo.

    Si vas a necesitar comunicarte con otros sistemas o realizar logica de negocio compleja te recomiendo que mires JBoss Rules (Drools) que sirve para abordar de manera elegante las reglas de negocio, lo que te permitira expresar en un lenguaje sencillo las mismas y las separaria del flujo de ejecucion que definas en tu proceso.

    Para el tema de comunicacion tiene a JBoss ESB que te permitira comunicarte con cualquier plataforma o cualquier sistema en un ambiente donde se hablen distintos protocolos y necesites intercomunicarlos. Si bien tendras que programar estas llamadas dentro de los ActionHandles que estan en Java esto te solucionara y podrias llegar a hacer algunos ActionHandlers genericos que tus usuarios finales invocarian solo pasandole parametros. (los cuales te darian los distintos compartamientos)

    Espero haber clarificado alguna de tus dudas.. y espero mas comentarios si quieres seguir charlando sobre el tema.
    Saludos!

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s