The increasing need for agility, transparency, and control of business policy is coercing businesses to extract their business logic from obfuscated code in their IT components and to manage that business logic as a separate, independently-evolving asset, defined in business terms.  The appeal of using Business Rule Management Systems (BRMS) to achieve this is clear:  when used correctly, these tools can reduce policy change release cycles from weeks to hours and put business policy experts — not IT departments — in the driving seat.  In addition, business rules can be used to prevent loss of intellectual capital when staff leave.  Business rules offer the ability to federate partial control of business logic to third parties, providing a new way of doing business. 

Why then are so many adopters of this established technology jeopardizing their own efforts and reducing the return on their investment by making the same ten mistakes?  If you plan to adopt BRMS, how should you avoid doing the same?  In the first part of this two-part article, I discuss five common BRMS adoption mistakes I have witnessed over six years of mentoring BRMS pilots in the investment banking and insurance sector.

10.  Performance Anxiety

Business rules are often used in high-volume decision processes in which performance is critical.  Therefore, it is entirely reasonable that adopters of the technology should be wary about the performance of any BRMS product.  However, many organisations allow the introduction of a BRMS into their architecture to distract them from the big picture.  This leads them to err in three ways:  to assume that any performance issue encountered during the project is solely due to the (newly introduced) BRMS, to be obsessive about rule performance to the extent that other architectural flaws are overlooked, and to test performance in ill-conceived ways.

If a company adopts a BRMS product, surely any performance issues they experience from now on are the fault of the new product?  Surely representing business logic in a natural language is less efficient than Java or C#?  Well, almost always, the answer is no.  Most BRMSs are very efficient software components that, due to rule-oriented optimization techniques, offer better performance than third-generation programming languages.  By now, the market has eradicated products with serious performance impediments.  In fact, performance issues are most often caused by: 

• misuse due to inexperience (e.g., the application of RETE algorithms where it is not appropriate, database access during rule execution),
• mistakes in configuration (e.g., insufficient memory, low SAN bandwidth, or a poor integration),  or 
• 'knock-on' effects that are not directly attributable to the product (e.g., inefficient caching of reference data). 

There is rarely an inherent shortcoming with the tool.  Worse, this distraction with BRMS performance can lead to a disproportionate focus on 'optimizing the rules' at any cost, thereby obtaining a small benefit in performance by compromising the business clarity of rules, project budgets, or some other critical success factor.

For example:  a recent client achieved a four-fold increase in their rule performance after two man-months effort and was delighted.  However, the rule execution was less than 2% of their end-to-end run time.  Consequently their effort (an estimated 5% of their total budget) had only bought them a 1.5% improvement in end-to-end performance [((4-1)/4)*2%] — a poor ROI by anyone's standards.

9.  Not Working Your Vendor Hard Enough

The market for BRMS (particularly in the US and Europe) is ever more competitive because:

• rule-based approaches are now mainstream (thus clients are more discerning),
• there are more second- and third-generation products on the market, and
• the global belt-tightening brought on by the credit crunch is causing everyone to demand more for less.

This means that BRMS vendors are even more desperate to get your business, especially if it is a large, multi-part, or a key-niche project (e.g., financial services, healthcare, or insurance).  It is surprising, therefore, how many clients fail to capitalize on this, both by extracting every benefit possible during the contract negotiation stage itself and, more subtly, by being very demanding in the competitive, multi-vendor 'play-off' that precedes tool selection.

8.  Unsure Offshore

Although the off-shoring of 3GL development projects (critically, Java and C#) has had mixed success, the off-shoring of (business-oriented) rule development is still a recipe for disappointment.  This is largely because of a lack of offshore business skills and BRMS experience.  Worse still, some offshore vendors are willing to be completely dishonest about the competencies of their teams, especially when inexperienced clients are concerned.  There is a wealth of niche technologies that are utilized in enterprise applications, and not every offshore team can be trained in all of them.  The temptation is to cover the most commonly-used ones and bluff about the rest — including BRMS.  You should avoid your project being used as the offshore developers training opportunity ... unless, of course, it is priced on that basis and you have mitigated the risk.

For example:  two offshore development houses, with which the author has engaged in the past two years, each claimed many man-years experience with BRMS products.  When the first was asked to submit a prototype as proof of their expertise, they submitted a tutorial demo provided with the product.  When interviewed about their demo, they were unable to alter its behaviour or explain its operation in detail.  The second submitted personnel who subsequently admitted that their sole experience was a week 'cramming' on BRMS technology, prior to their involvement on the project.

7.  Deployment by Stealth — Subversion of Release Controls using BRMS

Some clients see the enhanced agility of a BRMS as a means of short-circuiting local controls (governing the deployment of code changes) imposed by their own governance bodies.  Most organisations, quite sensibly, have restrictions in place enforcing the need to fully unit test, package, and regression test every code change that is deployed into a production environment.  This policy frequently reduces production incidents and botched deliveries, at the cost of slowing the deployment cycle and forbidding last minute hot fixing of Jar files or CLR assemblies — a tradeoff that is onerous to some and, occasionally, unnecessarily restrictive.

However, in these organisations, last minute changes to the configuration of a system (typically driven by a text 'properties' file) — as opposed to system code changes — are often permitted with minimal testing.  Therefore, once the business policy is expressed as rules, rather than code, the rules are officially labelled 'configuration', thereby permitting fundamental last minute changes under the banner of 'reconfiguration'.  Many BRMSs represent the rule repository as an interpreted file, or database, which supports the appearance of configuration to the inexperienced.  However, this is misleading; although most BRMSs offer a much more controlled environment for defining a policy than any programming language, to equate this with a reduced need to test is reckless and ultimately self defeating.

The agility that BRMS promises cannot be safely achieved if testing is reduced or circumvented.

6.  Lack of IT Involvement

Some inexperienced clients are lured, by the optimistic sales copy of BRMS vendors, into believing that business users can adopt BRMS and develop rules with little need for IT practitioners.  After all, isn't this the value proposition offered by BRMSs:  control of business policy by the business?  Proponents of this approach perceive the entry threshold to the BRMS user community as very low; one only needs to understand one's business and express policies in natural language.  The vendor's IT consultants will analyse the object model, plumb in the BRMS technology, perhaps write a few sample rules, and the business team can take it from there.

However, without the sustained involvement of an IT team, most BRMS projects are doomed to be of very limited success.  There are four main reasons for this:

1. Technical Training.  Typical business users, unless they have prior BRMS experience, cannot make full use of the tools without extensive training and a period of mentoring by a rule expert.  Without both, much of the first few months work of the business rule authors will need to be rewritten or discarded later.  Many business users are quite unprepared for the level of precision required for a rule-based representation of their domain.  Nor are they ready for the wealth of important choices they must make, in advance, about organising their rule hierarchy — choices that later effect its scalability.
   
   
2. Debugging.  Some tools may claim to make rules completely business oriented, but this ends abruptly when executable rules are first tested.  Understanding and fixing rule redundancy, overlaps, subsumption (when one rule effectively subsumes one or more others), incompleteness (when there are situations not covered by any rules), cycles, contradictions, and other errors requires some expertise and understanding of mathematical logic.  Debugging the subtleties of RETE ordering of rule execution takes technical know-how.
   
   
3. Maintenance and Evolution.  Considerable technical set up is required to 'plumb' a BRMS into institutional infrastructure and its data architecture.  The use of XML may lessen these dependencies, but does not change the fact that most BRMSs require (at least a first draft of) an underlying object model on which to base the rules.  Even those that do not will require an integration to occur, once an object model is created by the first few rule set drafts.  In addition, as rules evolve, this business object model will require occasional refactoring.  The integration between the rules, the model, and the wider infrastructure will also require maintenance.
   
   
4. Version and Change Control.  Dovetailing the internal version control mechanisms and development workflow of a BRMS with the source code control of related artefacts outside the rule engine (on which the former are dependent) will require some custodian outside of the business team.

BRMS are often sold on the premise that they reduce the turnaround time for changes in business policy by cutting out the middle man (i.e., developers).  Does this obviate the need for developers?  No.  BRMSs facilitate an equal partnership between the IT development team (which harvests existing rules from applications, submits them for review, develops a object model that supports all the salient business concepts, interfaces this model to the company's infrastructure, and maintains the model by integrating it with new rules) and the business team (which reviews, amends, and takes ownership of business policy, as expressed in rules, and controls future changes).  Figure 1 shows the role of IT developers in the evolution of rules (in purple).  The dotted black arrows denote change stimuli that trigger actions:

• Infrastructure to IT, when a change to the infrastructure must be integrated with the existing rule base, and
  
  
• Business SME to IT, when a new rule function is required (perhaps access to new data or a new rule consequence).

Figure 1.  Role of IT Developers in Rule Evolution

The agility of BRMS is achieved by removing the need for IT development to support every business policy change (by decoupling of the purple and green processes in Figure 1), but it does not obviate the need for IT development teams entirely.

Conclusion

We have seen that BRMS adopters are prone to obsession with the technological details of their projects, or neglect them in favour of the business hype.  A balanced view is required, backed by experienced personnel.

In the next part of this article, we explore what happens when the importance of business input and processes is overlooked, as we address the five most common and debilitating mistakes made by adopters of BRMS technology.

# # #