Business rules management systems

Embedding rules in the infrastructure

Free IT resource Hear how top CIOs turn change into a competitive advantage. Sponsored by HP Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld DOWNLOAD PDF Click here to download InfoWorld's special report Putting rules engines to work

At a block diagram level, a BRMS-driven application looks much like a conventional enterprise app (see “How Apps Play by the Rules,” page 39). Think of a BRMS as another tier in an n-tiered system that contains the usual combination of Web server, application server, and database. The BRMS occupies a fourth tier that puts the logic in the hands of business analysts. Thanks to the English-like nature of BRMS statements, even the CEO can jump in and check the rules. Any rule can be changed, added, or deleted; be sent to the IT department for integration and testing; and be put into production in a matter of days or even hours.

Although enterprises can expect to save a bundle in change management, they should also prepare for a sizable initial investment in BRMS development and training. It’s almost impossible to evaluate how much time it will take to write the business rules because this depends on how many rules will be written — and that inevitably turns out to be more than originally anticipated. Moreover, business analysts may well balk at the notion of “coding” business rules. As with any big IT adventure, a BRMS project must begin with the understanding and support of upper management.

The decision whether to use a BRMS rests on the type of application and the nature of the existing infrastructure. Obviously, a BRMS would be overkill for a small-scale, single-function application. And many large-scale commercial enterprise applications, such as ERP or CRM systems, already include rules engines, although they may be invisible to end-users. But many big enterprise business applications developed in-house can benefit from a BRMS, particularly if the business logic is isolated from the rest of the application in the original design.

Things get trickier when determining whether to integrate a BRMS into an existing system. The IT department and business analysts must work together to extract business logic that has been intermingled with control logic and data validation code. Software components may break when the business logic is extracted — and deciding which rule goes where can be a laborious exercise. It may seem obvious, for example, that business rules do not affect data validation. But in some cases, data validation parameters change frequently and must be placed in the business analysts’ control (date ranges may shift, pick list categories may be dynamic, and so on).

Another stumbling block in refactoring existing systems is that the existing rules are rarely, if ever, entirely correct. Inconsistencies may create political problems or spawn long discussions on the business side as business analysts work to resolve difficult issues they may have otherwise avoided facing. Ultimately, each existing piece of business logic must be examined to see how it will fit in the new system. New objects may also be necessary, although most database applications can be “extended” by the BRMS without modification to the database. New GUI screens must be also considered because the entire application will be much more sophisticated and will require more information.

Many organizations hire consultants to help them determine the amount of work involved in deploying a BRMS. If upper management buys into using a BRMS and understands its value, it may be easier to scrap an existing application and start more or less from scratch, using the old data validation and control code only when it saves time and effort.

BRMS does finance

Financial institutions provide some of the best examples of BRMS solutions in action. For example, the past few years have seen an explosion in the number and variation of loan products, each governed by their own set of rules. BRMS enables the business side to get creative without fear of incurring excessive IT overhead.

Click for larger view.

One financial services company, E-Loan, did $6 billion last year, most of it approved via a BRMS developed with Jess, a Java rules engine. The company used the source code provided with Jess to write its own BRMS user interface so that business analysts could enter simple rules that generated code for loan approval. Etienne Handman, CTO of E-Loan, says that improved customer relations — stemming from the speed with which analysts can now make decisions — has more than made up for the app dev costs, which turned out to be lower than traditional solutions.

At CitiStreet, CIO Andy Marsh was in sore need of a solution that business analysts could understand. The BAL (Business Action Language) of ILOG’s JRules allowed him to express all of his rules in the lingua franca of both his company and the financial industry. The result has been that the average analysis time required by CitiStreet’s team of business analysts has been reduced from six months to three months. Marsh is now contemplating how to leverage the benefits of BAL and JRules into CitiStreet’s workflow management process.