Your developers may be great at writing code, but you don’t want them making ill-informed decisions about the way the business works. Likewise, business analysts should focus on making business decisions rather than try to translate them into excruciatingly detailed requirements. One way for a company to make the most of each side's strengths is by deploying a business rules management system (BRMS).
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
A BRMS can bring the business and IT much closer by giving control of the logic - and even the code - to business analysts. This heretical idea relies on a fundamentally different approach to development, where developers isolate an application’s business logic from its data validation logic and from its flow control. The business logic then gets its own container, the BRMS, in which business analysts "code" business rules in a simple, English-like programming language.
BRMS engines normally embed themselves in vertical enterprise applications which simulate human expertise, such as those that handle underwriting, loan applications or complex scheduling. It gives the business side direct control over the rules that govern how enterprise applications behave. And when business analysts decide that business rules have to change, they can make the alterations themselves rather than waiting for IT to get around to it.
The result is much lower maintenance costs and much higher confidence that software is implementing business rules properly.
Break the logic logjam
Business analysts typically have a far more distant relationship with enterprise applications than they do with, say, a desktop spreadsheet. If people on the business side want a new application built or changes made to an existing program, they submit a request to the IT department, which probably hasn’t the foggiest what they’re talking about. So begins an endless round of meetings between the business and IT to iron out the ambiguities.
At some point, developers start writing the code, either building business rules into software components running on an application server or implementing them in stored database procedures. The development team then tests the code and hands it back to business analysts for verification. It's at this point the code is rejected because the results are nothing like what the business analysts envisioned. A few months and a few code rewrites later, the business side finally gets something it can live with.
With a BRMS, business analysts not only determine the business logic, they write it too. All they need to know is how to write a rule in English.
A business rule typically goes like this: if certain events occur or conditions exist, then certain events should happen or else other events should happen. Each If-Then-Else statement is a business rule. Each rule is a declaration and may interact with other rules. A BRMS allows business analysts to see, understand, code and maintain rules with (almost) no help from IT.
A BRMS chews on a set of rules until it comes up with a solution. It loops through the rules again and again until no more can be executed. The idea is that changing data drives the way rules execute - and that interacting rules reduce the need for human intervention. Related sets of rules may govern loan approvals, insurance policies, choice of distributor, and so on.
By contrast, conventional application development arranges rules in an incredibly fragile, top-down fashion.
For example, if the Then part of a rule changes the data used by the If part of another rule, the whole process must be examined to put the rules in the right order. That’s why it takes so long to write, change, and maintain business rules using ordinary application development.
Tiers without fears
Diagrammatically, a BRMS-driven application looks much like a conventional one. In a multi-tier 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 chief executive can jump in and check the rules. Any rule can be changed, added or deleted; sent to the IT department for integration and testing; and put into production - all in a matter of days or even hours.
This can save companies a bundle in change management, but 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 it all depends on how many rules you will write - inevitably, you will end up with more than you originally anticipated.
Business analysts may also baulk at the notion of coding business rules. As with any big IT adventure, a BRMS project must begin with the understanding and support of top management.
A BRMS would be overkill for a small-scale, single-function application. And many big enterprise applications, such as ERP or CRM systems, already include rules engines, although they may be invisible to end-users. But many of the larger 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 collaborate in extracting business logic from the control logic and data validation code it is mixed up with.
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 - date ranges may shift, pick list categories may be dynamic - and so must come under the control of the business analysts.
Another stumbling block in refactoring existing systems is that the existing rules are rarely entirely correct. Inconsistencies may create political problems or spawn long discussions on the business side as business analysts work to resolve 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 database modifications. New GUI screens should also be considered because the entire application will be more sophisticated and require more information.
Many organisations hire consultants to help them determine the amount of work involved in deploying a BRMS. It may be easier to scrap an existing application and start from scratch, using old data validation and control code only when it saves time and effort.
Take the fire drill out of finance
Financial institutions provide some of the best examples of the BRMS in action because they allow the business side to get creative without incurring excessive IT overhead.
Financial services company E-Loan turned over $6bn (£3.24bn) last year, mainly via a BRMS developed with the Jess Java rules engine. The company used the source code provided with Jess to write its own BRMS user interface so business analysts could enter simple rules to generate code for loan approval. E-Loan's chief technology officer says the improvement in customer relations brought about by faster decision easily justified the application development cost, which was lower than with traditional solutions.
At CitiStreet, chief information officer Andy Marsh sorely needed a system that business analysts could understand. Ilog’s JRules allowed him to express all his rules in the lingua franca of both his company and the financial industry, halving the average analysis time required by the company's business analysts. He is now contemplating how to extend the benefits ot the company's workflow management process.
Lisa Fiondella, senior vice-president of product management at Equifax, says the driving force behind her adoption of JRules "was the reduction of translation errors between the business users and the programmers". Other reasons include greater efficiency in overall IT operations and a shorter time to market for a new web-based loan-credit product. Fiondella says using the BRMS eliminates the "fire drill" response to demands for business logic changes in existing applications.
BRMS technology is spreading to other areas too. Telecom companies often use a BRMS for everything from determining how to route messages, to scheduling maintenance downtime and handling customer relations. Another frequent telecom application is to help achieve compliance with statutory regulations.
In deploying a BRMS, companies often face a conceptual hurdle in teasing out the rules that govern various business functions. After that Rubicon is crossed, however, and analysts focus on rules that change dynamically, organisations can apply a BRMS in some unexpected places.
One business that gains from using a BRMS to react fast to competitive pressure and customer behaviour is casino giant Harrah. According to chief information officer Tim Stanley, the casino's marketing managers analyse activity at each location every day to come up with new promotions. Within 24 hours the new rules have been tested and gone into production.
"Sometimes I walk out of my office and see a group of customers actively playing at a time that used to be slow," he says, "and I say to myself, ‘They wouldn’t be here now if it weren’t for the one-off promotions I can do with our rules system.’"
Which is right for you?
BRMS tools cover everything from open-source languages to full-blown enterprise systems. If you want to test the BRMS water, you could begin with Jess, which is a free download.
But major development projects require collaborative communication between all participants - business analysts, coders, the chief executive, end-users, finance directors, and so on. And that means a BRMS with all the bells and whistles.
Ilog’s JRules (the Java version) and Rules (the C/C++ version), and Fair Isaac’s Blaze Advisor are enterprise tools with debugging, testing and analysis tools. Enterprise customers that need blinding speed but are willing to live with limited tools would do well to consider PST's Official Production System for Java (OPSJ).
An IT department that has staff already trained in OPS or the C Language Interface for Production Systems (Clips) might want to take a look at Haley’s Authorete, PST’s Clips/R2, or Sandia National Laboratories’ Jess.
New tools with new twists to consider include PegaRules from PegaSystems, and Corticon, which has a spreadsheet interface for rules input.
The more polished products, such as JRules or Blaze Advisor, make self-service rule changes easier for business analysts, but experts in business rules logic must always be available to ensure the BRMS works smoothly. According to Gartner analysts, a properly implemented and supported BRMS can cut IT operating costs by between 10% and 15%. And that estimate doesn’t take into account the soft benefits of rapid response to shifting business demands.
The idea of isolating and consolidating business logic may seem odd, but the pay-off is all but inevitable.
James Owen is a senior knowledgebase consultant at Knowledgebased Systems and has worked with expert systems since 1989