h1

Motores de reglas de negocio: pasado presente y futuro

02/06/2010

Wizdoc [Icon By Buuf]  Tips & Tricks.

La función de un buen software es hacer que lo complejo parezca simple.

Grady Booch, ingeniero de software estadounidense.

Hace algunos años llegué a ver la serie documental Conexiones, presentada por el historiador científico James Burke. El programa era muy bueno, pues narraba cómo descubrimientos en diferentes épocas y lugares que parecían no tener nada en común, convergían hasta desembocar en algunas de las invenciones más importantes de nuestro tiempo. Por ejemplo, un capítulo comienza mostrando cómo se logró la estandarización de metales preciosos en el Medio Oriente a través de la piedra de toque, y va describiendo la cadena de conexiones que pasa por piratas árabes, investigaciones sobre el magnetismo, meteorología y un sinfín de avances que poco a poco resultan en el radar, el estudio de la estructura del átomo por Ernest Rutherford y finalmente la bomba atómica. En fin, el programa explica de manera amena un árbol tecnológico muy parecido a esos juegos de estrategia como Civilization.

Pues bien, al generar una pequeña presentación sobre motores de reglas de negocio, encontré todo lo que viene detrás. Son 60+ años de historia que por cierto, es muy interesante:

Los inicios: El motor inferencial

Erase una vez… Allen Newell, un recién egresado de la Universidad de Princeton, que en 1950 ingresó a la Corporación RAND para realizar trabajos de investigación en teoría matemática y procesamiento de información. Durante su estancia en esta organización, Newell asistió a una presentación del investigador del Instituto Tecnológico de Massachusetts (MIT) Oliver Selfridge, donde exponía una introducción a su trabajo en reconocimiento de patrones, y cómo la interacción de unidades simples pueden lograr un comportamiento complejo. Esto le prendió el foco a Newell, quien inmediatamente empezó a preguntarse en la posibilidad de "enseñar a las computadoras a pensar". Para 1955, entre Newell, el programador Cliff Shaw y el profesor en economía Herbert Simon, desarrollaron la teoría e implementación de Logic Theorist (Teórico Lógico), un programa que demostraría eventualmente 38 teoremas del Principia Mathematica. En 1956, el también investigador del MIT John McCarthy organizó una conferencia donde Simon y Newell demostraron su creación; aunque fue recibido con bastante indiferencia, el evento marcó el inicio de una de las ramas de la ciencia informática más polémicas de la actualidad: la "Inteligencia Artificial" (Artificial Intelligence – AI). De hecho, McCarthy se inventó el término para el título de la conferencia, y actualmente se le reconoce su autoría.

Originalmente, Logic Theorist consistía de un conjunto de enunciados matemáticos/lógicos (también llamado base de conocimientos) y un árbol de búsquedas. Para evitar que la construcción del árbol creciese exponencialmente, los diseñadores decidieron "podar hojas" e impedir que el programa siguiera caminos que difícilmente llevarían a la solución. Newell y Simon decidieron nombrar a estas "reglas de sentido común" como Heurísticas. Así, con una base de conocimientos, un árbol de búsquedas y una serie de heurísticas, nació el primer motor inferencial.

Madurando la tecnología: los Sistemas Expertos

Avancemos un poco en el tiempo. En 1975, después de 10 años de investigación, Edward Feigenbaum y otros programadores del Heuristic Programming Project (Proyecto de Programación de Heurísticas) en la Universidad de Stanford, desarrollaron el sistema Dendral, que en base a un motor inferencial permitía identificar moléculas orgánicas desconocidas. Dendral es reconocido como el primer sistema experto: un programa que mediante una serie de reglas preestablecidas, comparación de resultados y aplicación de nuevas reglas de acuerdo a dicho resultado, facilita la solución a problemas que requieren un gran conocimiento sobre un tema específico. A partir de Dendral se produjo una explosión de sistemas expertos, primero en el ámbito académico y posteriormente en el ámbito comercial.

Un pequeño paréntesis: cuando Newell y su grupo desarrollaron Logic Theorist, ellos crearon un lenguaje denominado IPL (Information Processing Language – Lenguaje para Procesamiento de Información), que más tarde se convertiría en la plantilla que John McCarthy usaría para crear el lenguaje de programación LISP en 1958. Un poco más tarde, LISP se convertiría en el lenguaje de rigor para codificar motores inferenciales y sistemas expertos, incluyendo Dendral:

(define-syntax cond
  (syntax-rules (else =>)
    ((cond) (values))
    ((cond (test result …) clause2 …)
      (if test (begin result …) (cond clause2 …)))
    ((cond (test => result) clause2 …)
      (let ((temp test)) (if temp (result test) (cond clause2 …))))
    ((cond (else result …)) (begin result …))))

Un fragmento de código en LISP, realizando validaciones parecidas a las de un motor inferencial.

Deshaciéndose de LISP

Para el año de 1984, el departamento de investigación en Inteligencia Artificial de la agencia espacial norteamericana (NASA) había implementado varios prototipos de sistemas expertos como apoyo hacia otras áreas de la organización. Sin embargo, casi nadie los utilizaba precisamente porque habían sido desarrollados en LISP; y es que en aquél entonces dicho lenguaje incluía un alto costo de implementación, dificultad para integrarlo con otras aplicaciones y poco hardware con la capacidad para ejecutarlo. Es decir, era medianamente bueno para sistemas expertos en el ámbito académico, pero para temas empresariales (contabilidad, toma de decisiones), era prohibitivamente costoso e ineficiente.

Entonces, en dicho departamento se decidieron por crear un lenguaje propio para sistemas expertos basado en C. A principios de 1985 ya tenían un prototipo funcional, que denominaron CLIPS (C Language Integrated Production System – Sistema de Producción Integrado en Lenguaje C). Hacia finales del mismo año ya existía una versión del lenguaje bastante robusta, portable e integrable; a mediados de 1986, CLIPS v3.0 ya formaba parte del dominio público (es decir, era opensource).

Para 1987, CLIPS se había convertido en la mejor herramienta para desarrollar y ejecutar los sistemas expertos que necesitaba la NASA. Con CLIPS v4.0 se mejoró su desempeño y se hizo más modular y en 1991 CLIPS v5.0 introdujo y popularizó un nuevo paradigma: la Programación Orientada a Objetos. A mediados de los 90 la NASA sufrió una reestructuración por lo que finalizó su soporte a CLIPS; sin embargo la comunidad opensource tomó las riendas del proyecto, mejorándolo de forma continua. Actualmente en su versión 6.30, CLIPS es el motor inferencial más popular para desarrollar sistemas expertos.

Finalmente, el Dr. Ernest Friedman-Hill, investigador del Laboratorio Nacional Sandia, desarrolló a mediados de 1995 la herramienta JESS (Java Expert System Shell – Interfaz de Sistemas Expertos en Java), un motor inferencial basado en CLIPS y el primero programado en Java. Actualmente existe la versión 7.0 de JESS, e incluye características como definición de reglas en XML, un pequeño IDE para codificarlas o soporte para expresiones regulares. De hecho, JESS 1.0 se convirtió en la prueba de concepto que demostró la factibilidad de construir motores inferenciales y sistemas expertos en Java: actualmente existe una gran variedad de estas herramientas, e incluso las hay en modalidad opensource.

El surgimiento de los BRMS

Con herramientas disponibles públicamente para construir y ejecutar sistemas expertos, muchos departamentos IT y unidades de negocio reconocieron la posibilidad de crear aplicaciones basadas en conocimiento sin la necesidad de adquirir software comercial. Igualmente, por las fuerzas del mercado, muchas empresas surgieron con el fin de crear sus propios motores para implementar soluciones a la medida.

Con el pasar del tiempo, la competencia entre diferentes proveedores provocó que muchos de éstos incluyeran características adicionales: manejo de bases de datos para almacenar las reglas, editores gráficos para representarlas, flujos de trabajo para publicarlas, etcétera. Poco a poco fueron evolucionando de simples herramientas de parseo y ejecución de reglas a complejos sistemas para administrar su ciclo de vida, incluyendo monitoreo y detección de errores. Así surgieron los ahora denominados Sistemas de Gestión de Reglas de Negocio (Business Rules Management Systems – BRMS). Algunos ejemplos de éstos son Smart Rules de Kontac, ILOG JRules de IBM o Drools de JBoss.

ILOG JRules de IBM: Un ejemplo de la interfaz del BRMS integrado a Eclipse.

A finales del 2000 muchos de estos proveedores de BRMS implementados en Java se dieron cuenta de la poca portabilidad existente entre sus implementaciones. Es decir, si un cliente creaba un sistema experto con el software de BEA, no podría migrar fácilmente a la implementación de JESS. Esto se volvió especialmente crítico cuando conceptos como la Arquitectura Orientada a Servicios o los Servicios Web hicieron su aparición. Así, el 4 de Agosto de 2004 se publicó la versión final de la especificación JSR-94 (Java Specification Request – Solicitud de Especificación en Java), con el fin de estandarizar:

• El registro de reglas.
• El parseo de reglas.
• Inspección de los metadatos asociados a las reglas.
• Ejecución de reglas.
• Recuperación de resultados.
• Filtrado de resultados.

El detalle consiste en que se simplifican algunos aspectos, pero el funcionamiento interno de los motores sigue siendo propietario, sin que exista una especificación equivalente a la de los servidores de aplicaciones (específicamente, contenedores de servlets y EJBs, reflejados en las JSR-315 y JSR-220, respectivamente). Sin embargo, esta tecnología sigue madurando y al menos de momento una buena parte del software BRMS escrito en Java se está apegando a esta especificación.

Un uso alternativo

Durante los últimos años se ha encontrado un uso muy particular a los BRMS (ahora también llamados motores de reglas de negocio): permiten encapsular la lógica de negocio o base de conocimientos y separarla del código aplicativo. ¿Cómo es esto? En su forma más simple, un motor de reglas interpreta y ejecuta una serie de enunciados IF/ELSE (las reglas) y de acuerdo a las diferentes validaciones genera un resultado. Esto permite modularizar y externalizar código como el presentado a continuación:

  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
  }
}

Un fragmento de código en Java, realizando validaciones IF/ELSE.

Este código no es en absoluto mantenible; máxime si las reglas incrementan su complejidad, su variación es constante o los valores contra los que se les compara ("B203" o "A903" en el ejemplo proporcionado) sufren modificaciones. Entonces, con un BRMS es posible realizar cualquiera de las siguientes tareas:

• Encapsulamiento. En vez de tener una serie de IFs anidados en el código que hacen engorrosa su modificación, se les simplifica al definirlos como estructuras atómicas e independientes del resto de la aplicación.

• Agregación. Con el BRMS, se generan flujos de trabajo mediante conjuntos coherentes de reglas, estableciendo jerarquías de ejecución de acuerdo al dominio del problema. Es decir, ya no sólo se realiza una gestión de reglas, sino de procesos de negocio más complejos.

• Externalización. Se publican estas reglas de manera individual o en conjuntos previamente definidos en forma de servicios que serán consumidos por terceros. Así, se incrementa la agilidad de respuesta al cambio sin perder mantenibilidad.

Viendo hacia adelante

¿Qué dirección tomarán estas tecnologías en el futuro inmediato? Dependiendo del área de negocio o investigación se visualizan algunas predicciones, que pueden subdividirse en aquellas relacionadas a la especificación JSR-94, los BRMS así como los motores de reglas de negocio y finalmente a los sistemas expertos e inteligencia artificial en un contexto más amplio:

JSR-94. Aunque esta especificación es un buen comienzo para estandarizar la implementación de motores inferenciales en Java, es indispensable actualizarla e incrementar su rango de operación para que normalice la representación, ejecución y monitorización de reglas así como conjuntos de éstas. De momento trabajos como la Notación para Modelado de Procesos de Negocio (Business Process Modeling Notation – BPMN) se están convirtiendo en estándares de facto, pero es necesario hacerlos parte de la especificación.

Por otro lado, se está buscando estandarizar componentes ya existentes en muchos BRMS comerciales, como un API para monitoreo de ejecución de reglas, validación y depuración; un modelo de seguridad, ejecución y administración de conjuntos de reglas o selección de la mecánica de ejecución (por ejemplo: Forward Chaining vs. Backward Chaining).

BRMS. De acuerdo a la firma de consultoría e investigación de mercado Gartner, "… a partir del 2010 el foco principal de las arquitecturas tecnológicas pasará de la definición de estándares hacia la identificación y colaboración de servicios técnicos repetibles." Es decir, se buscará externalizar reglas de negocio y procesos en el contexto de una Arquitectura Orientada a Servicios, por lo que los BRMS poco a poco pasarán a formar parte de herramientas centradas en la gestión de procesos (Business Process Management SystemsBPMS), con el fin de crear lo que Forrester Research denomina "Aplicaciones Dinámicas de Negocio" (Dynamic Business Applications):

La mayoría de las aplicaciones empresariales son demasiado inflexibles para seguir el ritmo de los negocios que atienden. Las aplicaciones de hoy fuerzan a la gente a encontrar la manera de mapear fuentes aisladas de información y funciones para realizar sus tareas y procesos, obligando a los profesionales IT a gastar demasiado del presupuesto para mantenerse a la par con la evolución de los mercados, políticas, normas y modelos de negocio.

La principal meta de IT durante los próximos cinco años deberá ser inventar una nueva generación de software empresarial que se adapte a la empresa y evolucione con ella. Forrester llama a esta nueva generación como Aplicaciones Dinámicas de Negocio, haciendo hincapié en una estrecha alineación con los procesos de negocio y trabajo (diseñar para la gente) y la adaptabilidad a los cambios del negocio (construir para el cambio). En esta fase, los requisitos para Aplicaciones Dinámicas de Negocios son más claras que las prácticas de diseño necesarias para crearlas. Sin embargo, las herramientas ya están a la mano, y pioneros en la arquitectura orientada a servicios (SOA), gestión de procesos empresariales (BPM), y reglas de negocio – incluyendo los proveedores de software independientes (ISV) – han comenzado a mostrarnos el camino. El momento de empezar este viaje es hoy.

— John R. Rymer, et al. The Dynamic Business Applications Imperative. Forrester Research. Septiembre 24, 2007.

Sistemas Expertos e Inteligencia Artificial. Actualmente se continúa el progreso relacionado a sistemas expertos, especialmente en dos ámbitos: mejora arquitectónica y aplicaciones. El primero está enfocado en aumentar el desempeño y capacidad del sistema, así como la precisión de los resultados. Por ejemplo, mejorando el motor inferencial mediante diferentes algoritmos de búsqueda, como Redes Neuronales, Lógica Difusa o Redes Bayesianas. Otras áreas de oportunidad incluyen la integración de paralelismo, bases de conocimiento distribuidas o el aprovechamiento de otras tecnologías emergentes como los Discos de Estado Sólido. Por otro lado, se espera incrementar el número de aplicaciones, incluyendo diagnóstico en tiempo real, modelos predictivos y monitoreo y control automatizados. Vale la pena mencionar que los proyectos más ambiciosos en Inteligencia Artificial se están originando en la industria militar, con desarrollos como CALO (Cognitive Assistant that Learns and Organizes – Asistente Cognoscitivo que Aprende y Organiza), SEAS (Synthetic Environment for Analysis and Simulations – Ambiente Sintético para Análisis y Simulaciones) o CTE (Combat Zones That See – Zonas de Combate que Ven).

Conclusiones

Desde que se inició el campo de la Inteligencia Artificial hace 60 años, ésta ha evolucionado hasta convertirse en un apoyo indispensable para una gran variedad de aplicaciones, que van desde el diagnóstico médico, transacciones financieras, automatización y control, descubrimiento científico e incluso en el entretenimiento. Sin embargo, muchas de estas aplicaciones sufren del "Efecto AI": Una vez que se ha generalizado su adopción, ya no se le etiqueta como Inteligencia Artificial. Un ejemplo de este efecto es el motor de búsquedas Google, que funciona en gran medida gracias al "Googlebot", un web crawler o agente automatizado que mediante un conjunto de reglas indexa y recolecta información de todas las páginas localizadas en la Web. ¿Quién se imaginaría que sin la Inteligencia Artificial, Google no existiría?

Así entonces, la AI se está volviendo omnipresente, y aunque de momento su investigación y desarrollo se están enfocando en temas bastante pedestres como automatización o agilidad empresarial, un día de estos puede salirnos con alguna sorpresa:

Cuando empecé a escribir ciencia ficción en los años 60, parecía muy fácil encontrar ideas que tomarían décadas para filtrarse en la conciencia cultural; hoy el tiempo de espera parece más bien de dieciocho meses.

Vernor Vinge, escritor estadounidense.

5 comentarios

  1. me parece muy completo este articulo esta muy interesante y espero ver mas artículos como este gracias


  2. amigo re buena la info pero una cosa estoy haciendo mi tesis sobre toda la historia del BRM me gustaria sabes si me puedes ayudar con algunos links o libros para sacar mas info nesecito saber para dond van las reglas de negicio y mas info de dond viene si me puedes ayudar t dej0 mi correo gracias davidsan1065@hotmail.com


    • En la página se encuentran todos los links que puedes necesitar. Sin embargo, si necesitas alguna bibliografía, puedes encontrarla en los siguientes documentos:

      • Tony Morgan – Business Rules and Information Systems: Aligning IT with Business Goals
      • Malcolm Chisholm – How to Build a Business Rules Engine: Extending Application Functionality through Metadata Engineering
      • Ronald G. Ross – Principles of the Business Rule Approach
      • Barbara von Halle – Business Rules Applied: Building Better Systems Using the Business Rules Approach

      Especialmente bueno es el libro de Tony Morgan, pues explica el tema de las reglas de negocio desde un enfoque práctico.

      Saludos.


  3. Excelente artículo. Realmente muy completo… de lo mejor que encontré en la web. Gracias por compartirlo.


  4. hola me parecio muy bueno el articulo ademas me sirvio para el desarrollo de mi practica laboral , pero me haria falta mas informacion acerca de la generacion de informes inteligentes a partir de la herramienta drools basado en motores de reglas claro , si me pudieran ayudar se lo agradecieria mucho aqui dejo mi correo para ver si me pueden mandar algun tipo de informacion

    laline.lores@csd.uo.edu.cu

    muchas gracias



Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: