Desinformación y Verdades a Medias de Metodologías Ágiles

Timothy Fitz escribe en su blog una nota acerca de la definición real de una metodología ágil.

Inicia diciendo que está cansado de la desinformación:

• Agile means writing software without writing documentation.
• Agile means not caring about the long term.
• Agile means engineers get to decide the project’s features.
• Agile means not having strict practices.

También de las verdades a medias derivadas de ciertas prácticas:

• Agile means pairing.
• Agile means Test Driven Development.
• Agile means scrum.

Implementación de Procesos de Negocio con Reglas

Hay dos maneras de modelar un proceso de negocio: con un paradigma imperativo o declarativo. El primero utiliza un grafo que representa el orden o flujo de las tareas a realizar. El segundo es utilizando un conjunto de reglas que describen la relación entre las tareas.

El reto para los desarrolladores es entender el proceso y hacer la implementación de una solución con el paradigma adecuado. Si un procesos de negocio que no tiene una secuencia definida se implementa con BPM o BPEL, puede acabar con un grafo con cientos o miles de nodos y bifurcaciones (para un ejemplo ver figura de abajo), lo que lo haría difícil de mantener.

Por otro lado, no es recomendable modelar con reglas un flujo con una secuencia fija de acciones.

BPEL vs BPMN

Ambos conceptos son usados de forma indistinta por muchos consultores o vendedores. BPEL es un lenguaje para orquestación de servicios. BPMN es un lenguaje para el modelado de procesos de negocio en forma de flujos de trabajo.
De tal manera que una conversión de BPMN a BPEL no hace mucho sentido (aunque sea posible) y tampoco el usar BPEL para modelado de procesos de negocio.

En los siguientes enlaces se encuentra mayor información:
Process Component Models: The Next Generation In Workflow?
BPMN to BPEL: Lipstick On A Pig?
My Concluding Nuance On BPMN

¿Cuando utilizar un motor de reglas?

En  Give Your Business Logic a Framework with Drools se encuentra un buen ejemplo:

        if ((user.isMemberOf(AdministratorGroup) && user.isMemberOf(teleworkerGroup)) ||
                user.isSuperUser() {
            // more checks for specific cases
            if ((expenseRequest.code().equals("B203") ||
                    (expenseRequest.code().equals("A903") && (totalExpenses < 200) &&
                            (bossSignOff > totalExpenses)) && (deptBudget.notExceeded)) {
                // issue payments
            }
            else if {
                // check lots of other conditions
            }
        }
        else {
            // even more business logic
        }
    }

Este extracto de código muestra que las reglas son difíciles de programar y mantener en Java. Un problema potencial puede ser la frecuencia de cambio de las reglas, para este ejemplo, que los roles y los códigos cambien frecuentemente. Para aplicar un cambio de esta clase implica por lo menos modificar el código, compilar e instalar la aplicación, pudiendo llevar horas o días. Una forma de evitar este proceso es tener separadas las reglas de negocio del código y una manera efectiva de hacerlo es utilizando un motor de reglas.

En su forma más simple, un motor de reglas de negocio está compuesto de tres elementos: un conjunto de reglas, la base de conocimientos (conocida como área de trabajo) y el procesador de reglas. Las reglas son sentencias de la forma IF-THEN, de tal manera que si se cumplen todas las condiciones del IF se ejecutan todas las acciones del THEN. El motor utilizará la base de conocimientos para decidir que reglas deben activarse.