The Ten Most Common Mistakes Made By Corporate Adopters of Business Rule Management Systems (BRMS): And How to Avoid Them (Part 2)

Jan   Purchase
Jan Purchase Director of Business Rule Architecture, Lux Magi Ltd Read Author Bio || Read All Articles by Jan Purchase

5.  Lack of Governance

Many organisations view the decision to use BRMS as solely an issue of technical infrastructure adoption.  It is only a matter of installing software, and integrating it with the surrounding infrastructure and authoring rules.  However, achieving real and safe agility is not just a matter of installing tools; there is a need for a controlled process to review, manage change, document, test, deploy, and distribute rules (and related artefacts).

A governance process coordinates and controls all activities surrounding the evolution of rules project artefacts; it is a conscious attempt to preserve and evolve a business asset.  It defines who interacts with which project items, at what time, to what ends, and ensures this is recorded and coordinated with all other related activity.  (Figure 1 depicts a fragment of an example governance process.)  The process resolves conflicts, and prevents and handles mistakes due to human error.

Figure 1.  Fragment of a Governance Process

Insufficient thought about these processes can lead to chaos.  If your adoption of rules is motivated by financial regulation or legal compliance, it can result in serious legal repercussions.  Even if this is not the case, the up front investment in a governance process more than pays for itself in terms of safe development agility, lower frequency of mistakes, and enhanced accountability and traceability.  The tiny savings you make by omitting a governance process will quickly be overtaken by the mounting costs of production incidents, lack of accountability, meandering from the business drivers, and silent loss of intellectual property.

Check if your BRMS vendor has a rules governance process (most do) and use it!  Ensure the procedure is adapted to fit your corporate culture.  The key aspects of governance are:
  1. Authorization.  Structure your business community and your rules so that rule authors can only view and edit business polices (rules) appropriate to their job function and experience;

  2. Authentication.  Ensure that the security features of the BRMS (typically disabled by default) are activated, properly integrated with your security infrastructure (e.g. AD), and that business rule authors must authenticate themselves prior to entering the system;

  3. Audit/Traceability.  Ensure that changes to all rule artefacts (and the users submitting them) are logged, documented, and associated with established business goals and agreed policy decisions; ensure this is regularly updated;

  4. Review.  Ensure all rule changes are subject to independent assessment before release (4-eye principle) and that rules are only expressed in approved business terms;

  5. Testing.  Ensure all rule changes are subject to regression testing before release into a production environment; this will drastically lower the likelihood and severity of incidents.

For example:  the author has encountered two severe cases in which a governance process was not adopted.  In the first — involving a tier-one, international bank — the result was a ruleset that had no safe means of being modified and as a result was never changed post go-live.  This project neutralized the most compelling advantage of BRMS in a stroke.  In another case, involving an insurance company, an ad-hoc approach to governance was taken, which quickly resulted in a loss of accountability and chaos in the release of policy changes.

4.  Niche or 'Silo' Adoption

Many organisations procure BRMS technology on a piecemeal basis, spending $100,000s on a general-purpose toolset to adopt its use for a single project or specific business domain.  Naturally, one has to start somewhere.  However, the use of BRMS for a single project is rarely a cost effective approach, unless it is a pilot project for a wider adoption program, or you are buying a very restrictive BRMS licence for a narrow application and getting an excellent discount for doing so.  It is better to spread the licensing cost across several projects — not least because some vendors lack enough business knowledge to determine what constitutes a single business domain and would be willing to sell a domain-locked licence, at a discount, for business purposes like "trade processing" or "execution."  These terms are wide enough to cover the entire business activities of some organisations.

Ad-hoc, single project adoption also brings the risk of inadvertent adoption of multiple BRMS tools.  For example:  One bank recently found out that it was using three distinct BRMS technologies, in 'silos', without any mutual consultation!  Such was the mutual embarrassment at this inefficiency that the projects refused to share their findings or to even admit to each other's existence — a staggering example of short-termism.  Think of the cost saving and other efficiencies introduced if this had been a single tool and a coordinated adoption.

Reduce the cost of BRMS adoption by:
  1. Ensuring that no one else in your organisation is already using the technology successfully; and if not:

  2. Ensuring there is (or creating) a company-wide mandate to investigate this technology, which identifies you as 'project 0';

  3. Volunteering to be a pilot project and notifying secondary adopters that you will share the licence cost and project findings with them;

  4. Using your collective might (the promise of multiple projects) to bargain a better licence deal from the vendor.

Projects that successfully spawn 3-4 sister projects can expect to see their BRMS costs fall by the same factor, and the host company can maximise the return on its investment.

3.  Underestimating Rule Development Costs

A few companies can reasonably plan to use prefabricated rule collateral with their BRMS systems.  Some niches — like fraud detection, credit scoring, insurance, and healthcare — have entire rulesets available to buy.  However, the vast majority of companies will have to develop their own business rules, and over 85% of new adopters critically underestimate the costs of this by costing the development as they would conventional software development.

Developing rules is a serious undertaking, and arbitrarily allocating the job to business analysts or developers with no rule development experience will always lead to late delivery and poor results.  Do not imagine that you and your team can 'muddle through' by assigning the job to one of your bright young developers or, still worse, a business analyst and hope for the best.  Rule developers take 6-9 months to become productive (some never do), and the skill set is not the same as for Java or C# development.

Many BRMS adoptions fail for one reason alone:  they believe that a successful, tiny, proof of concept can be scaled up, merely by adding people.  Initially, with programmers authoring rules, some progress is made.  But increasingly, as more rules are developed, a coherent whole does not emerge and deadlines are slipped due to unexpected technical issues and the discovery that what works in the small does not necessarily scale to the large.  Several projects I been called in to 'rescue' have had thousands of unstructured rules (some duplicates), arrayed with no underlying structure or documentation, and written by untrained rule authors, with no means of determining, after the fact, why the system behaved as it did.  Consequently the ruleset was a constant, unpleasant surprise for the developers.  Introducing new rules frequently resulted in new and unexplained behaviour in apparently unrelated areas.  It need not be like this; these tragedies are easy to avoid.

Be prepared to give your project the best chance of success by:
  1. Ensuring all users of the BRMS tools receive the proper training (this may seem obvious, but many omit it in the interests of cost or time saving);

  2. Hiring a business rule mentor to work with your team — have them mentor the first two project iterations and design a scalable rule repository structure;

  3. If your team are not experienced rule authors, budgeting for the fact that they will make mistakes — use the project to 'build' experienced rule authors in your company;

  4. Documenting your rulesets and policies from the beginning — ensure their structure reflects the business;

  5. Planning to develop a rule audit function — enable the rule engine to describe what it has done and why (surprisingly few BRMS have this functionality enabled out of the box, but it is easy to enable).  This is vital when rule omission or collision starts to generate unexpected results;

  6. Organising an independent project review 50% into the project.

2.  Lack of Business Involvement

It is a sad fact that many BRMS deployments have little genuine, day-to-day involvement by business analysts, despite the fact that control of business policy by the business is part of the reason many adopt the technology in the first place.  This often occurs because the adoption decision is erroneously viewed as solely a technological one.  Also, very often the initial thrust of BRMS adoption is technically oriented (focussing on architectural integration, performance, etc.) and, therefore, the first rules are written by developers.  As a consequence, the rules developed are not really an accurate reflection of the business, nor are they written in business terminology but rather as a development team's inaccurate idea of the business written in technical language.

Such a mistake invariably leads to technology-centric, non-declarative, 'Java-esque' rules — reminiscent of programming — that are hard to understand and maintain by anyone outside the development team.  The rules, obfuscated by this technical orientation, prevent the business team from owning the business policy or enacting changes themselves.  Instead, they must direct requests for change to the IT team.  Such indirection adds to the turnaround time for (even minor) policy changes and increases the chance of semantic error.  Rules designed by technical teams tend to lack the correct degrees of freedom, and this becomes obvious when a change is required that appears trivial to the business but necessitates the refactoring of many rules.  Furthermore, business rules that are not designed by the business will (largely) be ignored by the business, reducing the chance of a lasting success.

For example: an investment bank — an inexperienced BRMS adopter — embarked on a twelve-month project with a strong technical team and a focus on performance.  After a long initial period, lacking any substantive business involvement and during which the system rule base exploded in size, an external business operations team reviewed the early version of the system.  They found it unfit for purpose.  The reason:  the business was unable to understand the rules because they were riddled with technical terms and artefacts.  Even technical users were sometimes unable to explain the behaviour of the system because the rules had become so 'buried' in the logic of the application.

The main value proposition of BRMS is safe agility achieved by the separation of business policy rules from technical artefacts.  This cannot be achieved without early and continued involvement from the business.  Figure 2 depicts the role of the business in the evolution of business rules.  Two separate business strata:  the business SME or analyst (in green) and the operational user of the system controlled by rules (in blue).  The dotted black arrows denote change stimuli that trigger actions.  In the business strata, this is the operations feedback from system business performance, which drives rule evaluation and change.

Figure 2.  Role of Business in Rule Evolution

For a better return on your investment, both technical and business teams need to be involved for the complete duration of the project.

Ensure you have one or two full-time business representatives on your team that are:  truly knowledgeable, respected, and authoritative in their domain; given adequate relief from their old duties to permit them to fulfill their new responsibilities; and willing and able to work with a rule developer to build a durable asset.  Ensure the rules are expressed in colloquial business terminology.  To further promote 'buy-in', submit an early version of the ruleset to an external business team for review.

The need for business analysts does not evaporate after the first release.  A full-time role is still justified to control rule evolution (see Figure 2).  Business rules that are invented by the business (under the watchful eye of IT professionals) will be:  easier to maintain, of more lasting use as an independent knowledge asset, and more effectively contribute to your agility.

1.  Ineffective Requirements Capture

Ultimately, the most common reason many BRMS projects under-deliver is the same reason that plagues all development projects:  lack of a deep understanding of the business requirements and/or behaviour of upstream business processes and systems.  In BRMS projects this can manifest itself in several ways:

  1. The business policies may not be consistent with the behaviour of upstream business systems.

  2. The business teams may have difficulty proposing test cases for the rules and keeping the expected results of these test cases consistent with the business logic they have specified.

  3. The rules may use a parochial business vocabulary and therefore be hard to comprehend outside the specific department in which they were authored.

  4. The rules may be too complex and obscure the business semantics, or too simplistic and hide volatile logic (i.e., business logic that frequently requires change) in the implementation layer.

  5. The rules-authoring project may appear to make progress and then serious omissions or misunderstandings in the policies are discovered late as integration begins.

  6. The rules are solving a problem that is not aligned with (or becomes misaligned with) the business goals motivating the project.

All of these are caused by a shallow and non-rigorous understanding of the business policies, how they will change, and how they are driven by the business' goals.

To keep your project grounded firmly in the business requirements, organise four distinct business support structures:
  1. At least two business representatives in your development team (as described above) that have an excellent (and updated) grasp of the key business drivers;

  2. Business and technical staff who have a complete understanding of the peripheral systems with which the rules must interact;

  3. An incremental delivery schedule to a separate, external business review team that assesses the utility of the rules and alignment with business drivers;

  4. A rigorous schedule of tests designed by the business and using, where possible, real data and specified expected results.  This should be in use from the first iteration.
In addition, ensure that the vocabulary and the structure of your ruleset are actively managed by a business-oversight team.  Don't use the behaviour of legacy systems as your requirements unless they are backed by an independent business source.

For example: an inexperienced adopter of BRMS embarked on a six-month project with a widely-distributed business team that had an incomplete grasp of the requirements and of the behaviour of upstream systems currently in place.  Unfortunately, they selected a systems' integrator with little BRMS experience.  Eighteen months later, the project was abandoned due to perpetual scope expansion, excessive complexity, and an inability to express a business policy that was consistent with the real underlying behaviour of existing systems or the business drivers.


Developing systems that integrate BRMS technology is no more difficult that any other infrastructure, providing you have the right vendor, experience, and expertise at hand.  Bearing in mind the ten points considered in these articles will help you to benefit from all the advantages BRMS has to offer.

# # #

Standard citation for this article:

citations icon
Jan Purchase , "The Ten Most Common Mistakes Made By Corporate Adopters of Business Rule Management Systems (BRMS): And How to Avoid Them (Part 2)" Business Rules Journal Vol. 11, No. 7, (Jul. 2010)

About our Contributor:

Jan   Purchase
Jan Purchase Director of Business Rule Architecture, Lux Magi Ltd

Dr Jan Purchase is Director of Business Rule Architecture with Lux Magi Ltd (, a consultancy specialized in helping financial institutions in the adoption and enterprise-wide use of business rules. Jan has focussed on the analysis and design of business rules systems for top tier investment and retail banks since 1999 and has been working alongside major BRMS vendors for over six years, serving as lead business rule architect in seven enterprise projects during this time. In the 18 years he has spent developing and architecting capital markets systems, Jan has become accomplished at bridging the gap between business experts and technologists — a vital skill for any business rule architect.

Read All Articles by Jan Purchase
Subscribe to the eBRJ Newsletter
In The Spotlight
 Silvie  Spreeuwenberg
 John A. Zachman
The Issue Is THE ENTERPRISE By John A. Zachman Jan. 2017 | Vol. 18, Iss. 1

Online Interactive Training Series

In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.