Copyright © 2009 James Taylor. Visit the original article at Complementing IBM BPM with ILOG.A technical introduction to how ILOG’s product complement WebSphere Business Process Management products. ILOG, of course, has a full-fledged Business Rules Management Systems or BRMS as well as an optimization engine (CPLEX), visualization tools and applications for supply chain management. This […]
Copyright © 2009 James Taylor. Visit the original article at Complementing IBM BPM with ILOG.
A technical introduction to how ILOG’s product complement WebSphere Business Process Management products. ILOG, of course, has a full-fledged Business Rules Management Systems or BRMS as well as an optimization engine (CPLEX), visualization tools and applications for supply chain management. This session focused on how the ILOG BRMS integrates with and complements the WebSphere BPM products.
Business rules bring more agility to business processes and that business rules allow the business to be more involved and so ensure IT is more aligned with the business. Using a BRMS also improves communication between business and IT and breaks down some of the walls between the business and IT. The reasons for BRMS use include rules that change a lot, that need to be owned by the business, that have a change cycle different from the process itself and that represent complex logic. While you can consider a whole process to see if it should use a BRMS, I believe that this is a choice you make decision by decision not process by process. A failure to discuss decisions is a crucial omission – it is not enough to think about the rules in the application or the process you must think about decisions too.
Clearly a BRMS is essential for a BPM project to adopt rules quickly. It lets a project team take the rules from code, documents, processes and people and manage those rules explicitly. You need user tools to capture, manage, and analyze rules; a rule repository to share, version and audit rules; and a rule execution server. Building Decision Services using a BRMS can reduce service proliferation and allows rules to be reused across multiple decisions – a finer grained reuse than the service level. A separate lifecycle and update periodicity is possible and the decision logic is closer to the business. A BRMS complements a BPMS by bring business people more fully into the improvement loop, by allowing a more rapid improvement loop (rules are often changed daily while processes often change only over months).
One point of potential confusion is, of course, that the WebSphere Process Server has some rules support – primarily to capture integration logic and routing rules. Business Modeler supports these rules and Business Services Fabric can be used to define the business policies on which service to use. These are useful features but not the same as using a BRMS to automate and improve the decisions within a process. WebSphere Business Events is another source of confusion as it too has rules – correlation and time window rules. These event rules are very stateful and good at handling the streaming data but, again, not the same as decision-making.
The ILOG BRMS has the classic components for a BRMS:
- Rule Studio – a full IDE with source code control integration that supports ruleflow (decision flow), rule templates, a higher-level business language, decision trees, decision tables etc
- Rule Repository for managing the rules
- Rule Team Server allows web-based access for business users so they can manage the rules they own
- Rule Execution Server to execute the rules and deploy them as web services or POJOs etc.
- Synchronization, monitoring and versioning of rules
The typical use, of course, is to create and deploy decision services that are invoked from a process, execute the rules using inferencing or a sequential model and then return some set of results for the process to use. The key difference between the rules previously available in WebSphere and the ones available with ILOG is the tie to processes. Rules managed using WebSphere Process Server are within a process and must be owned by, changed by and versioned in synch with the process. Rules in a Decision Service can be managed by business users, changed on a different cycle and reused across processes. Separation of concerns is the primary driver for using business rules to manage decisions but you should also see if you have (my list, little different from theirs):
- Lots of rules
- Rules that change often
- Rules that are complex or interact in complex ways
- Rules that the business insists on owning
- Rules that require business domain know-how to understand
The good news for WebSphere customers is that ILOG has already done a ton of work integrating with the BPMS before being acquired – work around development, monitoring and lifecycle management:
- On the development side it is important to remember that the development threads for rules and process tend to be parallel and only come together as the BPM solution comes together. This is important because the iterations of the two are different as are the ownership and governance hierarchies. Ensuring a separation – a decoupling of the Decision Services from the process – is essential. Processes include decision points to which Decision Services can be attached and the service interface becomes the contract between the process and the decisions/business rules. Various Eclipse plugins exist to manage this, generating a SCA component that allows the process to access the Decision Service and do so in a nice controlled way.
- On the monitoring side, ILOG provides distinct monitoring services for rule execution. Every rule firing is logged and stored so that the exact way a decision was made can be recreated. This is separate from the process monitoring which can be awkward though, of course, decisions may support multiple processes and so some separation is essential. You will need to do some correlation yourself to build a single, integrated monitoring history.
- On lifecycle management ILOG provides a deliberately and completely separate lifecycle management environment. This is essential as rules are often not owned by the same people as the process definition and the rules often change at a very different rate.
Overall the products seem to have the kind of integration that is required to make them work well together though there is opportunity for still more going forward. And a very similar level of integration exists with the FileNet P8 solution.
