IBM Operational Decision Manager is one of the best products on the market for business rules because it allows you to separate your business decisions from applications and apply the rapid changes that are needed to respond to evolving business environments.
In this article I look at how you can build a better business rule application architecture for Rule Execution Server and enable quicker turnarounds for ruleset deployment and integration.
IT and Business Cycles
IBM Operational Decision Manager (ODM) enhances the day-to-day decision-making capacity of an organization. It both automates decisions and provides the means to rapidly change them, placing business rules "under business jurisdiction" (SBVR).
Business experts manage the logic of decisions using Decision Center. They change and create new rules and decision tables. IT developers produce new versions of decisions using Rule Designer. They add attributes and classes to the XOM, generate BOM business terms and facts and create new business rule applications.
Both tracks can evolve independently and in parallel with each other, but a change and deployment of the business rules application always requires a synchronization between Rule Designer and Decision Center, and new integration by decision clients.
Some decisions, such as those that are made in response to emergencies, need to be changed and put into production in a matter of hours. Others are made in response to regulatory changes, can be planned in advance and scheduled for a specific date. The timeframes in which a new version of a ruleset is required to be changed, tested, and deployed, are specific to type of the decision.
To build a truly agile ODM business rules application, all changes, tests, deployments and new integrations must be completed and delivered within the timeframe of weeks, days or sometimes hours demanded by the business.
Deployment and Integration
ODM out-of-the-box offers us a choice of two types of technologies for executing rulesets deployed to Rule Execution Server: Hosted Transparent Decision Services (HTDS) and Rule Execution Server Java API. Whether using the HTDS web services or the API, all clients must invoke the deployed rulesets using the ruleset path and parameter input data, and handle the output from the execution.
The ODM samples, tutorials, and code generators show how to use HTDS services and APIs that clients must use for integration. Over different versions of ODM they have been added to and removed.
In more recent versions the direction of travel has been towards integration with REST using JavaScript and jQuery, and away from the Rule Execution Server APIs.
The ruleset path takes the form /{ruleApp name}[/{version}]/{ruleset name}[/{version} and is appended to the HTDS URL, omitting the version numbers in order to invoke the ruleApp and ruleset with the highest version numbers. The input parameter data is sent as the ‘data’ attribute of the jQuery ajax request.
The integration looks simple and easy. It is immediate and direct, but the solution is brittle. Parameters and their types are tightly coupled and must match at either end. Each time the XOM is updated with new attributes and classes, and the ruleset deployed, all decision clients are impacted.
Is this enough?
Is this enough to build your rules application architecture to meet business requirements? Well, the answer is yes and no.
If you are 100% sure that the format of the data required to execute your rules will never change and you do not need to change the ruleset path, then the answer to a tightly coupled solution is yes.
But if the scope of your rules is likely to change – and it would be a highly unusual if the business did not discover new facts and terms, and the decision logic did not change - then the answer is an emphatic no! Clients will always be impacted by any changes in ruleset parameter data and required to change, resulting in an end-to-end test and a release of both the client and the rules application.
Building A Better Application Architecture
If you follow the ODM samples, tutorials, and code generators, you will end up with all the problems of a tightly coupled architecture, whereby when ruleset parameters change, all HTDS clients have to be changed, tested and re-deployed too!
A better solution for integrating clients and business rules is to create a loosely coupled application architecture based on the Mediator Design Pattern
and add a mediation component to your ODM business rules applications.
Using a mediation component, the client and the rules application are no longer tightly coupled. All communication between the two is through the component where differences in data and versioning are resolved. Clients are shielded from the impact of new versions of a ruleset. A ruleset can evolve with new versions without impacting clients.
The mediator component manages all interactions using:
- A stable set of decision APIs which require clients to provide only minimal key data and data accumulated by the client.
- A Decision Executor Manager which acts as the gateway to decision execution. It dynamically selects the version of Decision Executor for the operation and the version requested by the client.
- The versioned Decision Executor is associated with one or more versions of a ruleset in Rule Execution Server.
- The Decision Executor which enriches, validates, and transforms the data supplied by the client, and fetches any required additional data, and handles all errors.
- The Decision Executor which invokes its target ruleset using the selected Rule Execution Server API and handles the response.
The mediation component can be used to invoke a request/ response REST or SOAP webservice, emit an event or send a JMS message to start a business process, or be embedded as POJOs in a Java application. It is easily maintainable over the lifetime of the business rules application.
Once setup, the only point of change is the addition of new Decision Executors. Each Decision Executor is stand-alone and encapsulates all the information needed to perform the execution of a ruleset version. Data not passed by the client can be added to the ruleset parameters, and validated and transformed. The result is that the client now does not need to change. Everything can be managed within the business rule application team.
Implementing the Mediator Component
If you choose a loosely coupled integration the upside is clear, but the downside is the initial implementation and setup. Building your own mediator component will involve multiple applications, data aggregation, transformation, validation and error handling.
These types of processing are common to many applications playing an intermediary role. But a mediator that integrates decisions has also to provide:
- An API interface that handles versioning while hiding the decision technology.
- A mechanism for adding new Decision Executors without changing the Decision Executor Manager.
- An efficient selection mechanism by which the Decision Executor is chosen for both the operation and version requested by a client.
- Loading for the version of the XOM classes and payloads linked to the target ruleset prior to invocation.
Figuring out how to implement any of these can be highly challenging.
If you are using ODM in at enterprise level, you will ideally create a framework that can be reused across the enterprise. ODM unfortunately does not provide this out-of-the-box. If you want to accelerate the process of doing so, ODM Accelerator provides this missing piece of the jigsaw puzzle as the Business Rules Decision Service (BRDS) framework.
The BRDS provides not only a framework that you can extend, but also a working example of how to implement and govern it.
Wrap up
To build a truly agile ODM business rules application, all changes, tests, deployments and integrations of a decision service must be completed within the timeframe demanded by the business.
IBM ODM documentation and samples shows you how to make an integration, but the approach used results in a tightly coupled solution which is hard to maintain. Changes made to the service impact all clients and result in greater difficulty in meeting timeframes demanded by the business.
A better solution is to create a loosely coupled application architecture based on the mediator design pattern which allows you to decouple clients and rules applications. It is more maintainable and can be handled within the ODM team. It allows for a rapid deployment of business rules when the XOM changes. Once implemented API interfaces are stable and clients do not need to change when the business rules application evolves.
About
Peter Warde has created the ODM Accelerator for IBM Operational Decision Manager - a collection of resources for designing and building richer, better, more maintainable and higher quality ODM rule applications.
If you like this article, you can read his other ODM articles:
You can also find this article on LinkedIn with viewer comments.