Capas de servicios SOA

La filosofía SOA tiene todo que ver con el orden y la estructura, con la articulación inteligente y práctica de los componentes software con que se teje el entramado de los sistemas corporativos. En ese afán por poner orden, también tiene cabida la estructuración de la propia naturaleza de los servicios. Y una forma de poner orden es estructurar en Capas de servicios SOA, el conjunto de esos servicios, conforme a su diferente naturaleza.

En su libro 'Service-Oriented Architecture: Analysis and Design for Services and Microservices' Thomas Erl propone una estructura de cuatro capas de servicios SOA.

Antes de pasar a verlas conviene comentar la clasificación que menciona el autor en cuanto a servicios agnósticos y no agnósticos, basándose la diferenciación en si el servicio tiene 'conocimiento' y dependencia de su contexto y muy en concreto de la tarea en que se enmarca la funcionalidad del servicio, o es ajeno a él. En el segundo caso hablaríamos de servicio agnóstico y tienen como beneficio el hecho de ser más ampliamente reutilizables. Si existe ese 'conocimiento' y dependencia nos encontraríamos ante un servicio no agnóstico.

Según eso, y siguiendo una dirección de abajo a arriba, el autor distingue estas cuatro capas:

Capas propuestas por Thomas Erl antes de la llegada de los microservicios

• Servicios de tarea: Un servicio no agnóstico y que en general se corresponde con una actividad o tarea de un proceso de negocio.


• Microservicios: una capa que no se encontraba en el primer planteamiento de Erl (por eso no aparece en la figura superior) y que consiste en un servicio no agnóstico con un alcance funcional reducido. No suelen ser reutilizables de forma general, pero sí dentro de la aplicación en que se enmarcan.


• Servicios de entidad: Un servicio agnóstico y que se relaciona con una o más entidades de negocio (por ejemplo, Cliente, Factura o Contrato). Tienen un contexto agnóstico. Por ejemplo, un servicio 'Orden de compra' tendría como contexto el procesamiento de cada orden de compra específica.


• Servicios de utilidad: Un tipo de servicio agnóstico y reutilizable y que ofrece una funcionalidad puntual que no deriva de unas especificaciones de proceso. Suele encapsular funciones técnicas de bajo nivel como, por ejemplo, temas de seguridad o trazado (logs).

Existen otros planteamientos de tipos o capas de servicios no totalmente coincidentes con las propuestas por Erl, aunque sí bastante próximas en sus ideas.

Al final, se trata de poner orden en un conjunto amplio de servicios y diseñar de forma que se respeten algunos de los principios y objetivos de SOA como son la alta cohesión interna y bajo acoplamiento externo de los servicios y la 'reutilizabilidad' de los mismos en el contexto más amplio posible.

Objetivos y beneficios de SOA

Aunque el tirón mediático de SOA (Service Oriented Architecture) ya hace tiempo que pasó, lo cierto es que los beneficios de SOA siguen muy vigentes y es, por tanto, un planteamiento que a nivel de arquitectura y diseño de sistemas es plenamente actual.

Cualquier organización con un mapa de sistemas suficientemente complejo debería tenerlo como un elemento rector de su arquitectura.

Incluso hoy en día con la cada vez mayor prevalencia de las soluciones cloud (PaasS y SaaS, en especial) adquiere quizá mayor sentido. Y eso tanto como arquitectura interna a usar por proveedores de cloud como en la forma de relacionarse las empresas con el software que le proporcionan esos mismos proveedores cloud.

Sabemos que la arquitectura SOA promueve la estructuración del software en forma de servicios reutilizables y con contratos bien definidos. Recoge así los tradicionales principios de la alta cohesión interna y bajo acoplamiento externo tan propios de la ingeniería software, pero llevados ahora, si cabe, a un mayor protagonismo. Aunque esa filosofía se puede implementar a nivel técnico de muchas formas, lo cierto es que lo que predomina hoy día son unos servicios que se exponen como web services ya sea con arreglo a los estándares SOAP (Simple Object Access Protocol) o REST (REpresentational State Transfer).

Pero ¿cuáles son esos beneficios que ofrece SOA y que la convierte en una arquitectura tan interesante?

En su libro 'Service-Oriented Architecture: Analysis and Design for Services and Microservices', Thomas Erl, concentra en siete los puntos a tener en cuenta, cuatro objetivos estratégicos y tres beneficios que se derivan

Los objetivos estratégicos de SOA

• Incremento intrínseco de interoperabilidad: En ese sentido cabe recordar que SOA persigue una interoperabilidad nativa de servicios sin necesidad de trabajos adicionales de integración. En esa dirección colaboran aspectos como la estandarización de los contratos de servicio, la predecibilidad del comportamiento, la escalabilidad y la fiabilidad.


• Incremento de la federación: recordando que por federación se entiende el que recursos y aplicaciones colaboren y se encuentren de alguna forma unidos pero manteniendo su autonomía y auto-gobierno.


• Incremento de las posibilidades de diversificación de proveedores: ya que al basarse en estándares y promover la interoperabilidad se eliminan dependencias innecesarias de los proveedores del software.


• Incremento del alineamiento entre negocio y tecnología: ya que SOA promueve un primer nivel de abstracción precisamente en el nivel negocio de forma que sus conceptos son naturales para ese negocio.

Los beneficios de SOA que se derivan

• Incremento de ROI: ya que las soluciones SOA son más sencillas tanto de mantener como de evolucionar que las soluciones más a medida.


• Incremento de la agilidad organizativa: es decir, la capacidad de las organizaciones de responder al cambio. Factores anteriores como el alineamiento con el negocio,o la reutilización facilitan mucho el evolucionar el software y por tanto responder con esa agilidad.


• Reducción de la carga para TI: ya que las aplicaciones son más sencillas de evolucionar, la complejidad total es menor y el gobierno también resulta más sencillo.

Ni que decir tiene que las implementaciones reales en grandes empresas son complejas y que ni SOA, ni ninguna otra arquitectura alternativa van a traer 'el mundo feliz' ni a la organización de TI ni al negocio. Pero aún así, desde luego SOA es un paso decisivo en la buena dirección y los beneficios de una arquitectura SOA bien diseñada y aplicada son innegables..

Cuatro dominios para una arquitectura empresarial

El concepto de arquitectura empresarial, algo borroso y no del todo extendido, nos lleva a un modelo  estructurado de los principales elementos de gestión de una empresa desde una perspectiva de negocio pero con mucha orientación hacia sus sistemas de información. Entre los dominios para una arquitectura empresarial que podemos encontrar en la literatura se encuentran aspectos como los procesos, los sistemas, la información, la organización, etc.

En su libro, 'Dynamic SOA and BPM', el arquitecto de IBM, Marc Fiammante nos habla de cuatro dominios para una arquitectura empresarial, cuatro dominios que, además, y a modo de regla nemotécnica de naturaleza gráfica, estructura en unas capas que conforman la letra 'E' de 'Enterprise architecture'.

Los cuatro dominios que se identifican son:

• Negocio
• Aplicaciones
• Infraestructura
• Información

y se ilustran en la siguiente figura procedente del libro:

Aunque Fiammante no realiza una definición detallada, sí podemos entrever los elementos de cada nivel.

Dominio de negocio

En este dominio, hablamos del negocio con independencia de la base técnica con que se pueda operar. Elementos que se encuentran en este nivel son la organización y la asignación de responsabilidades.

Pero también, y aunque no se menciona explícitamente, los procesos de negocio. De hecho, el gráfico se ilustra con el mapa de procesos PCF (Process Classification Framework) cross-sectorial de la APQC (American Productivity and Quality Center) y en su disertación Marc Fiammante nos habla también de otros modelos de procesos como eTOM (enhanced Telecom Operations Map), propio del mundo de las telecomunicaciones o SCOR (Supply Chain Operation Reference model) para cadenas de suministro.

Dominio de aplicaciones

En este dominio se sitúa por un lado, el censo de servicios de negocio (no olvidemos que el libro habla de SOA) y el mapa de sistemas o aplicaciones de la empresa y donde se mapean esos servicios de negocio.

Como ejemplo de un modelo de aplicaciones estandarizado, el autor nos refiere a TAM (Telecom Application Map) que acompaña a eTOM pero ahora con perspectiva de aplicaciones y no procesos de negocio.

Dominio de infraestructura

Este es el dominio más técnico donde se recogen elementos como el repositorio de servicios, el Enterprise Service Bus, los servicios de infraestructrura, etc. Se trata de un dominio donde apenas existen resultados de estandarización.

Dominio de información

En la figura se delinea como transversal a las otras capas. En este caso se trata estructurar la información que se maneja en la empresa, agrupándola en dominios de información, entidades y datos concretos.

El modelo de referencia más conocido en ese sentido es SID (Shared Information Data) que, junto con eTOM a nivel de procesos y TAM en lo relativo a aplicaciones, conforman una arquitectura casi completa para el sector de las telecomunicaciones.

***

El modelo de arquitectura empresarial que propone Fiamante identifica, creo que con bastante acierto cuatro capas relevantes de la arquitectura empresarial aunque, bien es cierto que la capa de infraestructura queda algo desdibujada al no existir ningún tipo de estándar, normativa o buena práctica que se apunte y en el nivel de negocio quizá convendría una explicitación más clara de dos aspectos: la organización y los procesos.

No es, de todas formas, el concepto de arquitectura empresarial un tema sencillo por lo que cualquier modelo que proporcione una visión más o menos estructurada y comprensible, como es el caso, es de agradecer.

El enfoque riguroso para el Business Process Management de Martyn Ould

'Business Process Management. A rigurous approach' es un libro riguroso y muy bien trabajado que explica el campo del Business Process Management pero desde la perspectiva muy concreta de la metodología Riva definida por el autor.

Se trata de un libro muy cuidado y que, como anticipa el título, es realmente muy riguroso, estableciendo fronteras muy claras entre conceptos y proporcionando una sintaxis y semántica de modelado muy limpias.

El libro se estructura en trece capítulos, a saber:

• 'Basic process concepts': explica algunos conceptos básicos como son los roles, en los que pone mucho énfasis, acciones, interacciones, objetivos del proceso y entidades


• 'Modelling a process': Inicia la descripción formal del modelado usando la metodología Riva. Explica lo que son los RAD (Role Activity Diagram), cómo se representan en ellos los roles y sus estados, las acciones, los threads de acciones concurrentes, los distintos cursos de acción, las interacciones y disparadores (triggers). Es, en fin, un capítulo fundamental en que se explica la mayor parte de la sintaxis y semántica del modelado de procesos con Riva.


• 'Dynamism in the process': Capítulo muy corto donde se explica algún aspecto de la dinámica de los procesos, muy especialmente cómo se inician y finalizan.


• 'Process relationships': Otro capítulo breve, en este caso para hablar de las relaciones entre procesos y cómo reflejarlas en Riva. Se habla de interacciones, activación de procesos y encapsulación.


• 'The three basic process types': Con este capítulo inicia la segunda parte más orientada a la aplicación de Riva en una organización y empieza razonando sobre tres tipos de procesos: tratamiento de casos, gestión de los casos y estrategia de los casos, con la filosofía de que, por cada entidad/unidad de trabajo que se identifique en una organización, podemos asumir tentativamente que existirán esos tres procesos.


• 'Preparing a process architecture': Continuación un poco del anterior, explica ahora en detalle cómo a partir de las EBE (Esssential Business Entities), es decir, a partir de las entidades fundamentales que gestiona un negocio, pasando por las UOW (Units of Work), es decir, las unidades de trabajo habitual ligados a esas entidades, y teniendo en cuentra los tres tipos de procesos, podemos deducir la arquitectura de procesos de una organización.


• 'Dynamism in the world': Con base en unos casos concretos, estudia cómo tratar aspectos de la dinámica de procesos.


• 'Managing the modelling': Explica la mecánica que propone para gestionar el modelado de procesos y proporciona una receta en cinco pasos donde se incluye también un análisis bastante profundo de la operativa de un taller de procesos.


• 'Discovering and defining processess': Un capítulo muy breve con alguna recomendación referida al descubrimiento y definición de procesos.


• 'Analysing for process improvement': Proporciona directrices sobre la forma en que se pueden mejorar los procesos de negocio y alguna idea sobre la gestión de ese trabajo.


• 'Designing a process': De una forma muy concisa, aporta sugerencias para el diseño de procesos cuando éstos son nuevos, en lugar de tratarse de la modificación de uno existente.


• 'Processes and information systems': Pone Riva en contexto y relación con los sistemas de información que soportan procesos.


• 'Processes and process systems': Razona brevemente sobre unos sistemas de información orientados al proceso y fantasea al final con futuros deseables, a través de seis visiones posibles de ese futuro.

Como aportación originales del planteamiento del libro está la introducción frecuente de unos diálogos entre un profesor y un alumno que desentrañan algunos de los aspectos más complejos o conflictivos de la gestión de procesos o de la aplicación de la metodología.

Se trata, por tanto, de un buen libro. Sin embargo, es una obra a la que creo que ha perjudicado el paso del tiempo. ¿Por qué? Porque aunque el tratamiento es interesante y riguroso, está muy, muy orientado a la metodología y notación Riva propia del autor, más que a una visión más general de la gestión de procesos. Dado que, por lo que sea, esta metodología no ha triunfado y dado que hoy en día la notación dominante es BPMN, bastante diferente de Riva, toda la lectura del libro produce esa sensación de estar viendo algo 'demodé' y 'fuera de juego'.

Para aprovechar lo que de bueno tiene este libro, es preciso, por tanto, hacer una lectura atenta y consciente y ser capaz de abstraerse de los aspectos más formales y particulares de Riva, para aprovechar el rigor, sentido común e ideas, sin duda muy valiosas, que hay detrás.

Martyn Ould

(Fuente: Ligera elaboración propia de su biografía en Technoikal.)

Martyn Ould

Martyn Ould es consultor y formador en la definición, diseño y diagnóstico de los procesos organizativos y de negocio. Ha estado activo en el ámbito de procesos de negocio durante veinte de sus más de treinta y ocho años en la industria.

Un contrato de investigación en 1986 lo llevó a desarrollar una técnica de modelado de procesos de negocio como parte de la aplicación de flujo de trabajo y sistemas de gestión de documentos. El libro 'Business Processes: Modelling and Analysis for Re-engineering' (John Wiley, 1995) describe la técnica en su forma inicial. Basándose en la experiencia de diez años extendió el trabajo para crear Riva, un método completo para la definición, diseño y diagnóstico de los procesos de negocio. Riva es el tema central de su libro 'Business Process Management. A rigurous approach' (BCS, 2005). En la actualidad asesora en la gestión de procesos de negocio para los clientes, en particular, trabaja con ellos en la adquisición de las herramientas mentales y disciplinas de Riva para construir una comprensión profunda de los procesos dentro de su empresa. Su experiencia de gestión de procesos incluye la elaboración de productos farmacéuticos y servicios públicos y los departamentos gubernamentales a nivel nacional y local. Ha trabajado con los procesos de front-office así como los de back-office, administrativos y de grupos de investigación. Su trabajo ha incluido:

• La preparación de las arquitecturas de proceso para departamentos y organizaciones enteras.
• El diseño de nuevos procesos para nuevos grupos.
• El rediseño de los procesos y la reestructuración de las responsabilidades de la organización para alinearse con los nuevos procesos.
• La adaptación de los procesos existentes para dar cabida a las nuevas tecnologías.
• Formación en Riva.
• Facilitación de talleres de resolución de problemas.

Su foco es la comprensión y claridad, evitando largas listas o informes. Tiene una sólida reputación en la industria y la academia. Es ingeniero colegiado y miembro de la British Computer Society.

Ficha técnica:

TITULO: Business Process Management. A rigorous approach

AUTOR: Martyn Ould.

EDITORIAL: British Computer Society

AÑO: 2007

ISBN: 978-1-902505-60-2
PAGINAS: 346

Artículos de este blog relacionados

• Principios para el modelado de procesos
• Siete situaciones y media en que se necesita descubrir y modelar un proceso de negocio

Recordando las funciones de un Enterprise Service Bus

Parece que nos hubiéramos olvidado de SOA (Service Oriented Architecture) y de todo lo que supuso... y supone aún. Pero no nos debemos olvidar porque las necesidades de integración de sistemas y de arquitecturas que permitan estructurar el armazón funcional y de información siguen vivas, muy vivas. Un elemento arquitectónico muy importante a que dio lugar el desarrollo de SOA es el Enterprise Service Bus, una pieza de software, un middleware como se le dio en llamar, que se constituía en una especie de conector universal.

Definiciones académicas aparte, el Enterprise Service Bus es un software cuya misión, en esencia, es interconectar sistemas. No proporciona por sí mismo una funcionalidad para el usuario final, sino que hace más fáciles y racionales los intercambios de información y servicios entre diferentes sistemas para proporcionar funcionalidades más amplias o para, por ejemplo, implementar extremo a extremo un proceso de negocio.

El Enterprise Service Bus ofrece mecanismos tecnológicos (Web Services, colas de mensajes, conectores a aplicaciones populares, etc) para implementar servicios de interconexión pero, además, suele ofrecer funcionalidades adicionales como la traducción de datos o adaptación de formatos, la persistencia y transacionalidad de las interacciones o la implementación de pequeños workflows.

En su libro 'Dynamic SOA and BPM', Marc Fiammante agrupa en cuatro las responsabilidades de un Enterprise Service Bus:

• Enrutado de mensajes: Cuando utilizamos un ESB la aplicación que necesita un servicio de otra, no llama directamente a esa otra aplicación sino que lo hace a través del bus y es el bus quien sabe cómo hacer llegar esa invocación a la aplicación destino. Esto constituye un primer nivel de desacoplamiento o independización entre ambas aplicaciones


• Conversión de protocolos de transporte: Es decir, cada aplicación o servicio puede utilizar el protocolo que más le convenga y es el bus el que sabe utilizar en cada interacción el protocolo adecuado y realizar las conversiones oportunas cuando protocolo de peticionario y servidor no son iguales.


• Transformación de formatos de mensajes: El bus realiza, si es necesario, traducciones de formatos de argumentos y contenidos de mensajes con lo que, de nuevo, independiza a las aplicaciones que no tiene por qué usar los mismos formatos.


• Tratamiento de eventos de negocio dispares: con lo que, el mismo servicio ofrecido por una aplicación, puede ser invocado en diferentes contextos de negocio.

Como se puede ver, el Enterprise Service Bus viene a ser, dicho de forma muy sencilla, un facilitador de las interacciones entre aplicaciones, desacoplando sus lógicas, interfaces y liberando a éstas de la esclavitud e ineficiencia que suponen los acuerdos bilaterales de protocolos y formatos de mensajes en las interfaces tradicionales.

Se trata, pues, de una pieza de software injustamente olvidada, puesto que juega un papel esencial en la arquitectura de cualquier empresa con un mapa de sistemas complejo.

En Pulse: La caracola: Transformación Digital y procesos

La atención que se presta a los procesos de negocio desde el punto de vista tanto tecnológico como de ‘management’ está sometido a una suerte de oleaje que los acerca y aleja alternativamente del foco de atención.

La primera oleada se produjo hace ya muchos años cuando Japón, espoleado por la necesidad de superar las consecuencias de la Segunda Guerra Mundial, adoptó las teorías norteamericanas sobre calidad y las llevó a unas enormes cotas de éxito y excelencia. Nació el TQM (Total Quality Management) y más tarde otras disciplinas o filosofías como Lean Management o Six Sigma que, aunque quizá hayan perdido algo de foco, siguen plenamente vigentes y conforman una indudable, ‘mar de fondo’.

Más tarde vino la galerna de la Reingeniería de Procesos, con su apuesta por la hoja en blanco y la reinvención radical. El temporal que generó ha amainado en parte, pero nos dejó como indudable regalo, la apuesta por las tecnologías de la información como soporte e impulso de la innovación en procesos.

Unos vientos fuertes, aunque menos racheados, acompañaron al nacimiento, primero de los sistemas empresariales como ERP y CRM que incluían automatización de procesos, y al nacimiento del BPM (Business Process Management) que confirió a los procesos de negocio el valor de un activo a gestionar y que se acompañó de novedades tecnológicas como los sistemas de workflow, posteriormente evolucionados a BPMS (Business Process Management Suites) bien flanqueados todos ellos por el concepto de SOA (Service Oriented Architecture) y ESB (Enterprise Service Bus).

Y quizá, erróneamente, nos creíamos que se había alcanzado la culminación y que ya no teníamos que prestar tanta atención a los procesos de negocio y las tecnologías que los soportan.

Pero ha salido una Luna llena llamada Transformación Digital que está haciendo más viva esa marea, que hace crecer y crecer el oleaje con nuevas tecnologías y nuevas posibilidades.

La revolución digital nos ha traído consigo la evolución del BI hacia el Big Data, la capacidad de analizar en tiempo real volúmenes inmensos de datos y obtener análisis, y conclusiones sobre muchas cosas, entre ellas los indicadores sobre los propios procesos. Y nos habilita no sólo para monitorizar, sino también para tratar eventos complejos en tiempo real o para, incluso, descubrir procesos (process mining) a partir de los la información que los ‘logs’ que los sistemas dejan como herencia.

Y la marea trae consigo también Machine Learning e Inteligencia artificial que nos permiten automatizar tareas hasta ahora vedadas a los BPMS, tareas que implican inteligencia, reconocimiento de voz, procesamiento del lenguaje natural o visión artificial y nos abren las puertas a la automatización de los procesos de relación con clientes y usuarios mediante chatbots, o asistentes digitales de voz.

Y con la marea nos llega también la automatización robótica de procesos (RPA, Robotic Process Automation) que permite digitalizaciones no intrusivas y rápidas de tareas masivas y repetitivas y que, además, se ‘entiende muy bien’ con la inteligencia artificial.

Y por detrás de la tecnología, las tareas y los procesos que esas tecnologías digitalizan y automatizan. Los procesos de negocio de los que creímos habernos olvidado y que ahora, cual regalo en forma de caracola, nos trae el mar agitado de la revolución digital.

Si. Los procesos de negocio han vuelto con fuerza. Es hora de recoger esa caracola y retomar las disciplinas de gestión de procesos que nos llevarán a gobernar de forma inteligente las nuevas tecnologías que lo digital trae consigo. Escucha dentro de la caracola. Escucha la gestión de procesos. ¿Oyes el ruido del mar? ¿Escuchas el oleaje? ¿Percibes la marea digital? ¿Estás preparado para la transformación?

*****

Artículo publicado en Pulse el 23/10/2018 y en Medium en la misma fecha

Pulse es el servicio de noticias personalizadas de la red social profesional LinkedIn

Esa 'cosa' llamada reglas de negocio

El término 'reglas de negocio' es frecuentemente utilizado en ciertos contextos: fundamentalmente, aunque no únicamente, en la gestión de procesos de negocio, en el 'business analysis' o en la especificación de software empresarial.

Se trata de un concepto importante pero, probablemente, algo ambiguo y no siempre utilizado ni con rigor ni con un significado único. Vamos a hacer una pequeña reflexión sobre el mismo esta idea de reglas de negocio y realizar algunos apuntes sobre ese concepto.

Podríamos decir, improvisando un amago de definición, que las reglas de negocio son:

directivas explícitas y detalladas sobre cómo se deben hacer ciertas cosas en una empresa u organización. 

Dos apellidos en forma de adjetivos son son aquí importantes:

• El apellido 'de negocio' que se le pone a la palabra reglas nos hace ver que esas directivas no son de naturaleza tecnológica, sino decisiones sobre operativa al margen del soporte técnico que se pueda prestar a esas directivas.


• El apellido 'explícitas y detalladas' que añado yo a directivas es importante para tener claro que una regla de negocio no es una 'filosofía general' acerca de cómo debe funcionar la empresa. No son indicaciones del tipo 'se debe tratar con corrección al cliente' o 'buscamos el máximo valor para el accionista'. No, las reglas de negocio son explícitas, claras, detalladas y procedimentales, es decir, no dejan margen a la duda sobre cómo se aplican. Podrían de ser del tipo: 'Sólo concedemos préstamos por encima de un importe X si el scoring crediticio del cliente se encuentra entre Y y Z'.

Aunque las reglas de negocio son, eso, de negocio, lo cierto es que al tratarse de reglas explícitas y detalladas permiten que se las implemente con tecnologías o sistemas informáticos tales como ERP (Enterprise Resource Planning) CRM (Customer Relationship Management), Workflows, BPMS (Businss Process Management System) , RPA (Robotic Process Automation), etc Y por eso se habla tanto de reglas de negocio en el contexto de la tecnología.

Las reglas de negocio puede establecerse como una condición, como una tabla, como un árbol de decisión, etc En el libro 'Dynamic SOA and BPM' su autor, Marc Fiammante, se detiene unos párrafos a hablarnos de las reglas de negocio y a proporcionar una tipología de reglas. Estos son los ocho tipos de reglas que nos identifica:

• Regla simple: Es el esquema condicional: si se cumple una condición, se sigue una acción o consecuencia.


• Conjunto de reglas: Se realiza la acción o consecuencia si todas las condiciones del conjunto se cumplen, sin que exista ningún tipo de orden.


• Secuencia de reglas: Muy parecido al anterior pero en este caso las condiciones se evalúan en un orden o secuencia.


• Tablas de decisión: La acción o consecuencia depende de más de una condición. Esta situación se modela como una tabla en cuyas columnas encontramos las condiciones y en filas las verdaderas reglas, es decir, las posibles combinaciones de condiciones y la acción o consecuencia que se sigue.


• Plexo (red) de reglas: Consiste en un entramado de reglas donde cada regla depende de unos predecesores (más de uno; en caso contrario sería una secuencia). La acción o consecuencia depende de las reglas 'afluentes' a la última.


• Otras reglas de inferencia: Un caso algo desestructurado en que existen varias reglas a combinar pera determinar la acción o consecuencia pero sin una estructura clara de dependencias.


• Flujo de reglas: Es una suerte de workflow que incluye ramificaciones paralelas y puntos de decisión donde la evaluación de cada regla depende de lo que haya sucedido antes en ese workflow.


• Procesado complejo de eventos: Caso en que se añaden dependencias temporales y de eventos.

El propio autor advierte de que no existe una clasificación estandarizada de reglas de negocio y que lo anterior es sólo un conjunto de las, a su entender, más habituales.

Se puede apreciar el carácter algorítmico que tiene esa formulación de tipología de reglas. Eso ilustra y confirma a un tiempo, por un lado, el carácter explícito y detallado y, por otro, la tendencia hacia la implementacion informática  de esa 'cosa' llamada reglas de negocio.