Buenas Tardes, mi nombre es Luciano Silveira, integro el equipo de soporte de Artech.En estos últimos meses he estado estudiando lo que son los motores de evaluación de reglas, en que escenarios se vienen utilizando y la idea es contarles un poco al respecto del resultado de ésta investigación.El objetivo es buscar alternativas que nos permitan poder construir aplicaciones adaptables, mas fáciles de mantener, con posibilidad de ser modificadas en run-time y a su vez que el usuario final pueda hacer modificaciones.
Contextualizando un poco de que se trata el “enfoque reglas de negocio”.Plantear algunas ideas de cómo podríamos utilizar esto en GX.A partir de esas ideas construimos un prototipo para experimentar con esas ideas, la idea es mostrar algún ejemplo.y finalizar con algunas reflexiones.Para comenzar me gustaría citar a Charles Darwin…
… sobre la adaptación de las especies; ésta frase aplica a la adaptación, al cambio que debemos lograr con nuestros sistemas para que puedan servir en forma efectiva y eficiente al negocio; que se puedan adaptar lo mas rápido posible en respuesta a regulaciones, tendencias, oportunidades y amenazas.
Contexto mundial del último año refleja claramente la necesidad de adaptación al cambio en todos los ámbitos.La necesidad de construir sistemas cada vez mas complejos va en aumento y necesitamos acompañar estos cambios.Necesitamos minimizar el time tomarket en donde prácticamente muchos cambios se tienen que hacer en “tiempo real”.Aumenta la incertidumbre y pasa a ser una “constante”, y será algo con lo cual nos tendremos que acostumbrar a manejar.Las regulaciones seguramente ya no tengan un contexto local, sino que sean complejas y de contexto global.En respuesta a estos cambios seguramente tenga que realizar cambios a nivel estratégico mas seguidos.En un mundo complejo mis objetivos seguramente no estén tan claros, y tengo que lograr balances (trade-offs).El proceso de Toma de Decisiones pasa de ser algo bien definido a algo cada vez mas complejo.Para hacer frente a estos desafíos el enfoque de “reglas de negocios” (Business Rules Approach (BRA)) comenta que buena parte de lo que es “adaptación” la logramos con una buena administración de reglas; la regla como elemento fundamental.
De manera informal, se pueden concebir las reglas de negocio como un conjunto de condiciones que expresan como deben llevarse a cabo los procesos del negocio de forma tal que su resultado sea aceptable.El conjunto de reglas de negocio es la colección de políticas y restricciones de negocio de una organización.
El enfoque de reglas de negocio plantea:_extraer las reglas de negocio de procesos y procedimientos es decir separar los procesos que lleva a cabo la empresa de las restricciones que se deben seguir._ expresar éstas restricciones en forma declarativa._ Las tecnologías van y vienen pero las reglas del negocio permanecen._ Externalizando la lógica de negocio de la forma de reglas simples asegura que las mismas son fácilmente comunicadas en toda la organización y administrada en forma separada del código de la aplicación._ proveer mecanismos para que estas reglas puedan ser evaluadas y modificadas.Un motor de reglas provee una alternativa que brinda capacidades de este estilo, en donde se declaran las reglas al nivel que el analista de negocio desea o similar y un motor toma estas definiciones y a partir de los datos recibidos ejecuta lo que indiquen las reglas.En la vida real algunos ejemplos de industrias que usan este enfoque…
_ Servicios financieros: créditosEn base al historial del cliente, a los números que ofrece el interesado y a factores externos al banco. _ Seguros: para analizar el riesgo de un cliente, si el doy o no un seguro._ Redes: Por ejemplo utilizado en Cisco en "Active Network Abstraction" una plataforma para administrar la redhttp://www.cisco.com/en/US/docs/net_mgmt/active_network_abstraction/3.6.6/administration/guide/intro.htmlUn ejemplo mas mundano, los clientes de mail._ Medicina: sistemas expertos que viene desde hace al menos 30 añosMYCIN que diagnostica enfermedades de la sangre y que sugiere un tratamiento.XCON usado por la DEC para configurar todos los PCs que saliesen de la DEC._ Help Desk
Me gustaría detenerme un minuto en un ejemplo bien interesante que encontré.Se trata de un programa que se lleva a cabo en conjunto UNICEF y la organización mundial de la salud denominado “Integrated Management of Childhood Illness” (http://www.economist.com/world/displaystory.cfm?story_id=9440765)La situación es que servicios de salud en muchos lugares del mundo no tienesuficiente personal médico capacitado.El plan IMCI entre otras cosas define en términos de “reglas de negocio” todo el conocimiento del experto, en este caso un médico.Cuando un chico llega a realizarse una consulta, el trabajador de la salud sigue instrucciones paso a paso que le permiten diagnosticar en forma acertada el caso.En este caso un gran conjunto de reglas que en su conjunto me permite llegar a diagnósticos bien sofisticados.http://www.who.int/child_adolescent_health/topics/prevention_care/child/imci/en/index.htmlPara este ejemplo la tasa de mortalidad de los niños menores de cinco años disminuyó un 27%.
Reglas de negocio están por todos lados, cuando estamos definiendo un “valuerange”, validaciones sobre fechas, cuando definimos un tipo de dato; cuando defino restricciones en la base de datos a nivel de Integridad referencial, cuando definimos Transacciones, cálculos, formulas, expresiones, find, max, etc…En GX además también existe el concepto de “reglas de negocio” plasmado sobre todo en lo que son las Transacciones; en donde entre otras cosas se soportan <<>>Muchas de estas “reglas de negocio” están ocultas, no tienen la suficiente visibilidad que plantea el enfoque de reglas… Tampoco estamos tan lejos de lograrlo….
Una aplicación hoy …<mostrar que las reglas de negocio están ahí “talladas” en piedra>
Supongamos que existe el concepto de “Rule” a nivel de KB para definir la regla, mantengo la definición declarativa y paso a tener las reglas de negocio sean un ciudadano de primera clase en el mundo GX (first-classcitizen).A su vez se agrupan en juego de reglas “Ruleset” y que tengo un mecanismo de indicar que quiero que se aplique un juego de reglas en un evento de disparo dado, pasándole la información de contexto necesaria.Utilizamos el patrón ECA Rules o “Production Rules”_ Evento: especifica cuando quiero evaluar las reglas._ Condición: test lógico que si se satisface causa que se ejecute la acción._ Acción: acciones a ser ejecutadas si la regla se dispara.Lo resuelvo en forma explícita con un objeto externo; RulesetEngine
Le cambiamos un poco la cara a las reglas ahora que son un objeto en si mismo, igualmente tomamos como referencia la sintaxis GeneXus de definición de reglas en Transacciones: Rule [ ifcondition ] [ onevent… ] [ levelatt… ] ;Supongamos que ahora como son un objeto en si mismo las defino de esta manera:<<>>Se encapsulan las reglas en objetos Ruleset que se van a llevar a producción para que se puedan modificar.Es decir paso de tener una aplicación ….
Para resolver el momento de disparo “ON Event” lo resolvemos unobjeto externo que le pasa al motor el juego de reglas y objetos sobre los cuales se quieren aplicar las reglas.Ahí queda armado el puzzleOlvidémonos por ahora de lo que serían las reglas “estáticas” las que ya tenemos en GX.
En este caso los objetos con los que se puede trabajar van a ser Business Components y SDTs.Para el prototipo estamos trabajando como si fuera un diálogo a pantalla completa.
Para probar un poco esta tecnología nos armamos lo que sería el ejemplo de la Factura GeneXus y tratamos de no incluir comportamiento de manera de experimentar con estos componentes de reglas. Fuimos precavidos e incluimos “puntos de extensión” con el motor de reglas usando el esquema “ECA” de manera de poder parametrizar comportamiento en tiempo de implantación:Nos interesa influir en los siguientes eventos:_ Cliente: Segmentación y asignación del máximo de compra permitido de clientes._ Producto: Inicialización del precio de un producto utilizando diferentes aspectos como por ejemplo, categoría y procedencia._ Factura: Aplicar diferentes tipos de validaciones, aplicar descuentos, utilizar promociones._ Workflow: en el diagrama de proceso relacionado con las compras; se separan ciertas decisiones del proceso en sí.
<<Demo>>
Quiero acercarme al usuario final y no estoy tan lejos.Que tal si al lenguaje de reglas le cambio un poco la cara para que el experto de negocio entienda ?
Algo así… supongamos acá que tengo las reglas instanciadas para clientes en ingles y españolCon algo así podría ser un esquema que me permita comunicar de otra forma con el experto.Las reglas son entendidas por el analista de negocio.
Inventamos un objeto nuevo para administrar un “lenguaje” a nivel del experto.Tiene como objeto hacer mas amigable el uso de reglas de negocio en particular acercarlas al experto del negocio para que las entienda y pueda modificar.Le pusimos “Rule DSL” (porque esto es un DSL especifico para la administración de reglas de negocio) y consta de:_ Scope: el alcance, es decir donde aplica la definición_ Language Expression: indica que el mapping puede ser utilizado en las condiciones de reglas_Mapping Expression: indica que el mapping sobre el lenguaje “GeneXus” de reglasAlgunas consideraciones_ con el "-" puedo definir múltiples condiciones sobre un mismo objeto_ CONDITION: indica que aplica sobre en condiciones_ CONSEQUENCE: solo se usa en consecuencia_ KEYWORD: para modificar diferentes palabras clave del lenguaje a algo “entendible”Estamos proveyendo una nueva capa de abstracción que oculta la complejidad, incluso la implementación de reglas de negocio "complicadas“, quedan “detrás” de lo que es la propiedad “Language Expression”.Algo así seria un ejemplo sobre el caso del Cliente que estuvimos viendo<ejemplo básico>En este caso estoy definiendo los mappings del DSL es decir defino el lenguaje "natural" que va a tener disponible el analista de negocio para visualizar y modificar las reglasEl resultado esperado es que las reglas se vean de esta forma:<.....>
Además con este esquema de sustitución básica me permite asistir aun mas al experto del negocio, defino exactamente que es lo que quiero que el usuario pueda modificar.<<>>A la infraestructura que tengo, agrego mas expresividad para potenciar el uso de la herramienta por el usuario final.Vamos a ver algunos ejemplos…
Un escenario mas interesante es sobre en la factura en donde intervienen varios actores, la idea es poder definir reglas que influyan sobre la factura, el cliente, las líneas de factura y los productos involucrados en la facturación.Rápidamente entre otras cosas vimos como directamente sobre un sistema en producción prácticamente sin comportamiento “la factura” incluimos_ Validaciones, manejo de restricciones_ Asignaciones de valores por defecto_ cálculos básicos_ manejo de promocionesAcá en este ejemplo me interesa destacar, lo importante de definir el QUE hacer, sin definir el COMO.Es decir con este enfoque la secuencia “no es importante” solo declaro que hacer cuando se cumple las condiciones. Tengo diferentes mecanismos (hints) para indicar precedencia, en el ejemplo vimos mecanismo como prioridad, grupos de reglas.
También puedo utilizar las reglas en procesos, de manera de tener cierto control en lo que es las decisiones que se toman para influir en lo que es el flujo del proceso.Es este caso supongamos que tenemos el siguiente flujo en donde se generan pedidos que deben ser autorizados por un administrativo y se toman algunas decisiones de cómo se sigue el flujo.En este caso en el condicional yo quiero tener la capacidad de pode modificarlo de manera de adaptarme a diferentes regulaciones que puedan surgir, supongamos que éstas son regulaciones por país.Por lo que siguiendo la misma idea mostrada en los ejemplos anteriores, en este caso el condicional esta llamando a un procedimiento GeneXus “myDecision001” por lo que yo desde ahí hago las conexiones necesarias para poder separar posibles decisiones en un formato de reglas, es decir algo así <<>>Pero vamos a ver el ejemplo en ejecuciónAlgunos puntos interesantes a resaltar_ simplicidad: algunas decisiones complejas son las fáciles de especificar utilizando reglas_ estoy utilizando dos formas de especificar comportamiento a muy alto nivel (procesos + reglas)_ Generalizando: al separar conceptualmente lo que es mi proceso de mis decisiones, estoy dejando los procesos mas genéricos, entendibles y con este esquema modificables.
El prototipo mostrado pretende validar alguna de las ideas mostradas_ por un lado usando el enfoque de reglas de negocio, investigar en lenguajes de definición de reglas como para que sean un ciudadano en la KB (algo similar a lo que le ocurrió al DataSelector). A partir de estas definiciones GX podría armar el esquema como lo hace actualmente de “estatizar” esta definición de “reglas de negocio” en tiempo de especificación y generación._ Si tengo un lenguaje definido externo a lo que es la aplicación e independiente de la tecnología explorar caminos como para acercarme al usuario final._ Analizar tecnología existente que pueda utilizarse para aumentar el dinamismo y parametrizaciónpersonalización de aplicaciones, para lograr productos personalizables, extensibles e integrablesEs decir, tengo reglas de negocio, y por ejemplo si pudiera decir que ciertas reglas las quiero dinámicas y ahí aplique lo que vimos; llevarlas a runtime para que se puedan modificar.Estas son las ideas que explora el prototipo.Por este lado se podría crecer muchísimo definiendo artefactos mucho mas sofisticados, yo aquí solo traje algunos ejemplos de lo que podríamos lograr.
También se pueden crear nuevas formas de presentación pensando en el experto de negocio como:_ Árbol Decisión_ Tabla Decisión: en este caso estoy mostrando algo similar al ejemplo del cliente, pero imagínense el caso de IRPF_ métodos visuales de definición de reglasEsto trae aparejado que me tengo que ocupar de la administración de reglas.Capaz que ya lo han escuchado hablar, lo que le denominan el BRMS
Necesito un repositorio para almacenar, versionar, administrar y auditar reglas.Es decir, al poder definir y modificar las reglas en runtime, necesito definir mecanismos de seguridad que me aseguren que solo usuarios autorizados puedan modificar las reglas.A su vez necesito trazabilidad total sobre el ciclo de vida de una regla o juego de reglas.Es decir cuando se modifica, por quién, como se probó, cuando entra a producción, cuando deja de estar el producción etc….Otro punto importante es la temporalidad en el sentido que mi programa tiene que saber con que juego de reglas trabajar, en el sentido que si se tiene que re-ejecutar algo se tiene que aplicar el mismo conjunto de reglas inicial que se usó.Traslada muchas de las tareas de Test y QualityAssurance a este punto porque cada vez que haga modificaciones, esos cambios se van a tener validar y verificar y asegurar que no se está “rompiendo” nada.Pero también esto permite que el experto de negocio tenga el control sobre las “reglas” que rigen las políticas que inciden sobre los sistemas, y pueda plantear diferentes escenarios de simulación (what -if).
Incluso el componente BRMS se puede convertir en un “centralizador de decisiones” que reutilizan todas las aplicaciones.
_ Formalizo conocimiento: tengo una transparencia mucho mayor; paso de conocimiento táctico (informal o sin codificar) a explícito (formal o codificado). Obtengo una visibilidad importantísima sobre ciertas “condiciones” que rigen mi negocio. Sé donde se usan las reglas, por ejemplo con el ejemplo de BPM tengo posibilidad de conocer exactamente el flujo y que decisiones se tomaron. _ Alto nivel y declarativo: permito que las reglas queden separadas del resto de la aplicación, en un formato de alto nivel y las posiciono para el cambio._ Estrecho el vínculo (me acerco al experto en el negocio) , tengo un mecanismo de comunicación y colaboración; le doy herramientas para que sean activos participantes en el desarrollo de la aplicación._ Ágil: tengo mecanismos para dar respuesta simple y rápida al cambio.De esta manera puedo obtener un sistema incluso que pueda ser modificado por los propios expertos del negocio en runtime!.Estamos construyendo aplicaciones "comandadas" por el negocio.
Keynote: Nicolás Jodalhttp://www.genexus.com/portal/hgxpp001.aspx?2,27,480,O,S,0,MNU;E;129;2;MNU;,Coronel John Boyd (http://en.wikipedia.org/wiki/John_Boyd_%28military_strategist%29)Para finalizar me gustaria referenciar una KeyNote que dió Jodal en el 2006 en el Encuentro de Usuarios GeneXus; "people, ideas, hardware …“ en donde entre otras cosas analiza una teoría desarrollada por el coronel (John Boyd) sobre la capacidad de crear cambios, capacidades de maniobra.El ejemplo que plantea es la lucha entre aviones de caza en la guerra de Corea. El F86 (americanos) y el Mig 15 (norcoreanos y chinos). Si bien el Mig 15 era superior en capacidad de giro y trepada que el F86, este tenia mandos completamente hidráulicos, lo que lo hacia mucho mas fácil de manejar. De esta manera cuanto mas avanzaba la pelea el piloto del F86 podía razonar mas precisa y rápidamente que el piloto del Mig 15 que se cansaba mucho mas. El resultado final fue que el F86 termino ganando 9 de cada 10 peleas.Con esta tecnología, no solo nos adaptamos al cambio (se acuerdan de aquello del inicio de la charla sobre Darwin ?) sino que estamos siendo proactivos y estamos dando herramientas para que el experto en el negocio tenga mayor capacidad de crear cambios.Para finalizar me gustaría hacer un resúmen minimalista de lo que vimos...
<Event>En el mundo actual<Condition>Se nos presentan desafíos en los cuales lo único claro o la única certeza es el cambio<Action>Se están investigando tecnologías, opciones como para que el desarrollador GX tenga herramientas para generar aplicaciones que permitan acompañar a éstos desafíos que impone el negocio; la generación de aplicaciones GX aptas al cambio.