Este artículo se centra en dos de esos problemas: la carga operativa de ejecutar ODM y el costo del vocabulario que mantiene a los usuarios de negocio dependientes de los desarrolladores. Cada problema se muestra tal como aparece en ODM y como se resuelve en DecisionRules.
Los patrones descritos son independientes del sector. Se aplican tanto si las reglas se refieren a elegibilidad para créditos, suscripción de seguros, paquetes de telecomunicaciones o prestaciones gubernamentales.
¿Qué es un motor de reglas de negocio?
Un motor de reglas de negocio (BRE) existe por una razón: permitir que las decisiones de negocio automatizadas sean económicas, rápidas y seguras de cambiar. Las decisiones pertenecen al negocio. El BRE permite que el negocio asuma su control.
El BRE adecuado demuestra su valor con una prueba sencilla: un gerente de producto, responsable de cumplimiento o responsable de riesgos puede abrirlo, ver qué está actualmente en production, cambiar un umbral y desplegar el cambio sin presentar un ticket al desarrollador. Eso es lo que realmente significa la «automatización».
Un BRE que crea nuevos roles especializados, nuevos pipelines de despliegue y nueva infraestructura que mantener está resolviendo el problema equivocado.
Problema 1: La carga de infraestructura
En ODM
Un despliegue no es un solo producto, sino un stack: un servidor de aplicaciones como WebSphere, Liberty, JBoss, WebLogic o Tomcat, una base de datos relacional para el repositorio de reglas, Decision Center como entorno de creación, Decision Server como entorno de ejecución, varios archivos desplegables, configuraciones de perfiles, agrupamiento en clúster opcional para alta disponibilidad y un entorno dedicado para cada etapa.
Cada entorno de ODM incluye un stack completo que el equipo instala, mantiene con parches y replica para cada etapa.
La aplicación de parches, las actualizaciones y la planificación de capacidad se realizan internamente. Las habilidades necesarias abarcan la administración de WebSphere, el funcionamiento interno de ODM y la integración empresarial con Java. Son áreas especializadas con su propio mercado de talento. Los usuarios de negocio pueden crear reglas en Decision Center, pero el despliegue subyacente sigue siendo responsabilidad de desarrolladores y administradores de sistemas.
En DecisionRules
Se ofrece como servicio administrado. Las opciones son Public Cloud, SaaS en AWS con regiones de Estados Unidos o la UE; Private Managed Cloud, un entorno dedicado en una región elegida por el cliente que normalmente está disponible en pocos días; o Self-Hosted, un despliegue con Docker o Kubernetes, incluso air-gapped.
Las tres opciones utilizan la misma UI, las mismas APIs y el mismo conjunto de habilidades.
Los tres modelos de despliegue comparten la misma UI, las mismas APIs y el mismo conjunto de habilidades.
Con Public Cloud y Private Managed Cloud, el cliente no tiene que instalar, aplicar parches ni escalar nada. DecisionRules opera la plataforma de extremo a extremo.
Los despliegues Self-Hosted constan de un solo contenedor y una instancia de MongoDB administrada por el equipo. Aun así, desaparecen el servidor de aplicaciones, la consola de creación separada y la replicación del stack para cada etapa.
Problema 2: El costo del vocabulario
En ODM
Los usuarios de negocio no escriben reglas en inglés libre. Componen las reglas a partir de un vocabulario controlado que los desarrolladores prepararon de antemano. La cadena tiene cuatro capas, y tres de ellas se encuentran detrás de una barrera que el usuario de negocio no puede cruzar.
Tres de las cuatro capas se encuentran detrás de una barrera que solo puede cruzar un desarrollador.
Cuando un usuario de negocio necesita un concepto que aún no existe en el vocabulario, como un nuevo indicador, un nuevo cálculo o un nuevo campo, un desarrollador debe ampliar el XOM, actualizar el BOM, verbalizar el nuevo elemento y volver a publicarlo antes de que la frase aparezca en el menú desplegable. El vocabulario también requiere mantenimiento continuo: las verbalizaciones predeterminadas no siempre son claras para el negocio, los BOM grandes producen vocabularios difíciles de manejar que ralentizan el editor y los desarrolladores dedican tiempo real a depurarlos mediante Categories y Virtual Methods.
En DecisionRules
El modelo se reduce a dos capas. Los esquemas de entrada y salida de la regla constituyen el vocabulario. El esquema y la regla se encuentran en el mismo entorno, los editan las mismas personas y pasan por el mismo ciclo de revisión.
El esquema y la regla se encuentran en un mismo entorno, por lo que un campo nuevo queda disponible en cuanto existe.
Cuando un campo existe en el esquema, queda disponible inmediatamente como columna de condición o columna de salida en la tabla. No hay un modelo de objetos separado, ningún paso de verbalización y ningún ticket para que un desarrollador exponga una nueva variable.
Un ejemplo real: Bonificación acumulada
Esta es una regla real de ODM procedente de un proyecto de cálculo de bonificaciones. La intención de negocio cabe en una frase: cuando un empleado tiene premios SMART y premios SYNERGY, se suman los importes de las bonificaciones SMART y ese total se agrega a cada premio SYNERGY.
El inglés legible que ve un analista se apoya en una clase Java que un desarrollador escribió previamente.
Al abrir esta regla en Decision Center, no aparece el código de la captura de pantalla. Se muestra la vista BAL, con un inglés legible que el analista puede editar:
for each award in smart awards do set 'smart total' to smart total + the bonus amount of the award;
for each award in synergy awards do set the bonus amount of the award to the bonus amount of the award + smart total;
La redacción es fluida. Es posible cambiar un umbral, agregar una condición o renombrar una categoría. Esa parte no es el problema.
Lo más difícil es cambiar el contenido del menú desplegable.
Cada frase que aparece en esa BAL, como «the bonus amount of the award», «smart awards» o «synergy awards», existe en el menú desplegable solo porque un desarrollador escribió una clase Java para Award, le agregó un campo bonusAmount , la expuso mediante un Business Object Model y escribió manualmente la verbalización en inglés. Si al día siguiente el negocio necesita agregar un regional bonus modifier a la regla, no puede hacerlo directamente.
La fluidez es real, pero funciona dentro del vocabulario que preparó el desarrollador.
La misma regla en DecisionRules queda bajo su control
En DecisionRules, la misma intención de negocio se implementa mediante un Decision Flow que llama a una Decision Table. Ambos se crean en el navegador. Ambos quedan bajo su control.
El Flow hace legible la orquestación y la tabla contiene la decisión para cada premio. Ambos pueden editarse en el navegador.
El Flow superior muestra todo el algoritmo de un vistazo: agrega una vez el total SMART, recorre la lista de premios, llama a la tabla inferior para cada premio y recopila los resultados en la salida. Ese límite marca el momento de la delegación. El Flow deja de gestionar la orquestación en ese punto y la tabla asume la decisión para cada premio.
Esa tabla es el núcleo de la regla y permite entender su funcionamiento en una sola lectura. Los premios SYNERGY reciben el total SMART en su bonificación y todo lo demás, ELSE, permanece igual. Para cambiar el umbral de «mayor que 0» a «mayor que 100», basta con modificar la celda y volver a publicar. Agregar una tercera fila para un nuevo tipo de premio funciona de la misma manera: se agrega la fila, se completan las celdas y se publica. No se necesita un desarrollador, una clase Java ni un ticket.
El Flow situado sobre la tabla justifica su presencia al hacer legible la orquestación. El paso de agregación es un nodo que cualquiera puede señalar. La iteración es otro nodo. La decisión para cada premio es un nodo, y ese nodo es la tabla que acaba de describirse. El nodo de recopilación indica exactamente dónde se guarda el resultado. No hay nada oculto debajo en un formulario generado que nadie pueda editar.
¿Qué ocurre con el modificador regional de bonificación que queda bloqueado en ODM? El punto no es que esta regla sea difícil. Incluso una regla pequeña alcanza un límite cuando requiere un concepto que el desarrollador no expuso previamente. En DecisionRules esa barrera no existe, porque tampoco existe la capa que la crea.
Correspondencias: La traducción entre plataformas
La migración es una traducción, no una reescritura. ODM y DecisionRules ofrecen distintos tipos de regla, y cada artefacto de ODM utilizado actualmente tiene un equivalente en DecisionRules.
En la mayoría de las reglas, el tipo se traduce directamente: una Decision Table de ODM se convierte en una Decision Table de DecisionRules, y un Decision Tree de ODM se convierte en un Decision Tree de DecisionRules.
La siguiente imagen no trata sobre la cantidad de tipos de regla. Muestra en qué se apoya cada tipo, dónde se crea, cómo se ejecuta y qué debe mantenerse para que continúe funcionando. La parte superior del stack se traduce y la inferior desaparece.
La parte superior del stack se traduce directamente y la parte inferior desaparece por completo.
Artefactos de reglas
Cada tipo de regla en ODM se apoya en un Business Object Model que envuelve un Java Execution Object Model. Cada propiedad y método se verbaliza manualmente para formar el vocabulario que ve el autor. Cada tipo de regla en DecisionRules se apoya en un esquema JSON tipado que se declara en la misma UI que la regla. La intención de negocio es la misma en ambos sistemas, pero DecisionRules utiliza la mitad de las capas.
Por separado, el artefacto de orquestación Ruleflow de ODM, con su archivo XML `.rfl`, se convierte en un Decision Flow sobre un lienzo visual.
Dónde se trabaja
ODM divide la creación de reglas entre dos herramientas: los usuarios de negocio abren Decision Center en el navegador y los desarrolladores abren Rule Designer en Eclipse. DecisionRules reúne ambos roles en un único entorno de navegador, donde trabajan conjuntamente sobre los mismos artefactos.
Los usuarios de negocio y los desarrolladores trabajan sobre los mismos artefactos, en lugar de utilizar dos herramientas separadas.
Cómo se ejecutan las reglas
Rule Execution Server se ejecuta en una instancia de WebSphere que el equipo instaló y mantiene con parches. En cuanto se publica, una regla de DecisionRules queda disponible como endpoint REST en una URL de Solver API. La forma del contrato que utiliza la aplicación no cambia. Solo cambian el endpoint y el protocolo.
Qué debe mantenerse
Esta fila desaparece por completo. La instalación de WebSphere, la base de datos relacional que contiene el repositorio de reglas, las réplicas por etapa para dev, SIT, UAT y production, los scripts de agrupamiento en clúster y la depuración del vocabulario desaparecen en los despliegues administrados en la nube que elige la mayoría de los equipos. La palabra «Nothing» en la esquina inferior derecha de la imagen no es una figura retórica. Representa literalmente la superficie operativa que se asume después de migrar.
La migración no se realiza en solitario
Leída de arriba abajo, la imagen cuenta la historia de la migración de un vistazo. La lógica de decisión se transfiere sin cambios. La traducción es mecánica en la mitad superior y supone una eliminación en la mitad inferior. Esa asimetría hace que la migración valga la pena.
La migración no se realiza en solitario. Nuestro equipo revisa el entorno de ODM, acuerda un plan de migración y después utiliza nuestro AI Assistant, que conoce la plataforma DecisionRules de extremo a extremo, para ayudar a implementar las reglas de forma rápida y coherente. Esto reduce los errores de transcripción manual que de otro modo se acumularían en una migración de gran escala.
Si ya existe un conjunto de pruebas de Decision Validation Services, los casos se traducen junto con las reglas y se ejecutan contra las nuevas versiones de DecisionRules. Así puede comprobarse la equivalencia antes del cambio. Si no existe un conjunto de pruebas, el AI Assistant crea uno a partir de la propia lógica de la regla. Esto aporta una red de seguridad para regresiones que quizá no existía en ODM.
La intención de negocio procede del cliente. Nosotros aportamos la traducción y la verificación.
IBM, Operational Decision Manager, ODM, WebSphere, Decision Center, Decision Server, Rule Designer y Decision Validation Services son marcas comerciales o marcas registradas de International Business Machines Corporation en Estados Unidos u otros países. Todos los demás nombres de productos mencionados pertenecen a sus respectivos propietarios. Este artículo no está respaldado por IBM Corporation ni está afiliado a ella.
Ivan Peresta trabaja en DecisionRules, donde su función abarca análisis de producto, servicios profesionales y soporte al cliente. Participa en todo el ciclo de vida de las funcionalidades del producto, desde el diseño inicial y la reflexión sobre UX hasta las pruebas prácticas, la documentación y la entrega orientada al cliente. Su trabajo cierra la brecha entre el desarrollo del producto y las personas que realmente lo utilizan, ya sea ayudando a un cliente a diseñar su sistema de reglas o asegurándose de que una nueva función se lance con guías claras y ejemplos funcionales.