My first look at Drools

I recently attended a Drools bootcamp to expand some of my understanding of what they offer and to get some hands on experience to experiment with the tools they offer.

I was actually quite impressed with what Drools as a whole offers considering the size of the team working on it.

One of the things I did not realize is that as part of the Drools “suite” of products, they have support for many of the things that are really related:

  • Obviously, a rule engine (Drools Expert)
  • A Workflow (or BPM) component (Drools Flow)
  • An event processing (or CEP and temporal reasoning) component (Drools Fusion)
  • And a Management (BRMS and BPMS) component (Drools Guvnor)

One of the things I like about this is that in one product, you can get the rules, workflow and event processing which not all products necessarily provide.

What was clear from the presentations I saw and the discussions is that the Drools team obviously is inspired by some commercial products, but they will usually take it to the next level. As an example I can think of the ILOG JRules support for event reasoning, but in the last couple of years, ILOG has stayed away from pushing that functionality, and they have not made it evolve. It has the potential of being very powerful stuff, but ILOG did nothing about it. Drools did.

I also like that Drools v5.1 will support the BPMN v2 standard for the workflow piece. Having a tool that makes it possible for workflow diagrams to be created using some of the latest standards is great.

Most of the things that is shown in the presentations or in the examples that can be downloaded is relatively technical, but if you are familiar with the Pattern matching algorithms that are behind most rule engines, the structure of the rule will be easy to understand (in other words, in JRules, if you can write IRL rules this will be easy).

The Drools team designed things in such a way that starting with one component and then trying to use other components will be relatively natural since the language constructs will be similar.

The documentation for installing, and running the examples is a bit weak. There are a lot of things required to run the examples (non technical users should abstain) but once things are setup, it is pretty easy to understand how to work with it.

I am not finished playing with drools to my liking yet, but as a first exposure to it, I am impressed.

If I have time I will post more on the topic in the near future.

Update to ABRD published

Jerome Boyer posted on his blog about the latest update to the ABRD (Agile Business Rules Development) framework which can be downloaded at the following address.

I have used some of the contents of the previous ABRD release, although as a whole I thought it was not as good as it should have been (and yes, I know that it is meant to be improved by a community but I was not sure where it was going to go from there).

But this iteration of ABRD is better structured, and after a quick review, it seems to be of much better overall quality. As a starting point for people dealing with business rules, it might provide some insights and guidelines as to how to run a business rules project.

I only wish that contributing to it was a bit easier and more transparent and that people from companies other than ILOG would also contribute to it so that the best practices in ABRD have less of a bias.

There are still some holes and very simplistic descriptions used in some of the items, but the evolution from the first version to this one makes it a very promising tool for people that work on a business rules project.


I just listened to a webinar by ILOG that discusses the integration of the ILOG BRMS with BPM.


I am glad to see that they are starting to publicize the need for both BPM and BRMS and how they relate. This was a first from ILOG as far as I can remember.


In short, business processes should be calling business rules and this should avoid your business process to grow into something un-manageable over time since the decisions are being externalized into the BRMS.


ILOG mentions the following as reasons to separating process and rules:

  1. Increase business agility by allowing users to manage decision logic
  2. Streamline and stabilize processes by externalizing decision logic
  3. Enable re-use of decisions across different processes, applications and systems
  4. Enable automation of complex, variable decisions
  5. Effectively manage large and evolving sets of rules


The interesting thing here is that points number 2 and 3 are now presented with a business process component instead of the “application” as it used to be.


Obviously, part of the presentation was aimed at showing why IBM bought ILOG and where ILOG’s products complete IBM’s offering and how it fits with the IBM products.


Once slide I particularly liked was one where they presented their vision of the Agility Infrastructure. Which basically is presented as:


The Agility Infrastructure:

  • Detect (Business Events)
  • Orchestrate (Business Process Management)
  • Decide (Business Rules)
  • Monitor (Business Activity Monitoring)

This is a simple representation of the 4 concepts and how they relate, yet it is a very effective one.


The recorded session and slides should be available soon on the ILOG web site.

On CEP, BPM and BRMS – Part II

As it was to be expected, Carol-Ann Matignon’s post brought some reactions from which I extracted the following definition for Decision Management.

Decision Management: The ecosystem of technologies that contribute to solving decision making challenges (decision automation) and the management of those decisions. The ecosystem includes Complex Event Processing, Business Processes, Business Rules, Predictive Models, Optimization, etc.

I think I will be adding those definitions to my definitions page…


Carol-Ann Matignon posted her attempt at demystifying the terms CEP, BPM and BRMS here. It is a very interesting post in which she makes an analogy to the human body’s functions as a comparison and a helper to understanding her definitions. That post is worth the read, but I will quote here definitions here:

The CEP / BPM / BRMS world seems fairly simple after all:

  • CEP module receives or intercepts a flurry of events and processes them with the objective of figuring out what those events are relevant for; it triggers the appropriate business processes or decision services
  • BPM module receives the request for a given process to be applied to a higher level entity (an application, a document…); it automates the steps defined in the business process
  • BRMS module is invoked with a given context to apply business rules; it makes a business decision 


On meeting in the middle

Daniel Selman added an interesting post to his blog discussing the “Meet in the middle” approach which is a combination of top-down and bottom up. You can see the original post here.

I commented on the posts on his site, but I will reproduce one of those comments here. Enjoy

Meeting in the middle challenges

The challenges I have seen with this kind of approach is that if you are working on a project that is using the Zachman Framework, chances are the people working on the modeling (conceptual and logical data modeling) are not the same as the people who are working on the rules and who need to help the Subject Matter Experts work with rules. The model that data modelers will propose will most probably be different than what a model created for the business (and business rules) needs to be and therein lies the challenge of trying to steer the modeling in the direction required for the rules.

What I have seen is that the data modelers want to use best practices of their world which is great, but the vocabulary that they will create will be inevitably different than what the SMEs are used to in that business. For example, they will use some data modeling patterns (party-role for example) but these are not terms that the business uses. So what is the relationship between the models? Is there a relationship?

The solution? I’m not sure.

Does a completely separate modeling effort need to take place? And then an effort to try and map one to the other (i.e. map the business object model to the logical data model using view or some other technique)? Both models will end up influencing the other in the end, so changes are inevitable, but is it better to use that approach?

Or should the team try to collaborate on creating a model that will work for both purposes? This requires that both modelers (assuming there is one for the data modeling world and one for the BOM) collaborate and educate each other on reasons why they should go one way or another. Will you end up with 2 separate models anyway in that case?

There may be other solutions to this and hopefully we will see other people’s input to this.