The Ten Most Common Mistakes Made By Corporate Adopters of Business Rule Management Systems (BRMS): And How to Avoid Them (Part 2)
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:
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:
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:
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:
- The business policies may not be consistent with the behaviour of upstream business systems.
- 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.
- The rules may use a parochial business vocabulary and therefore be hard to comprehend outside the specific department in which they were authored.
- 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.
- The rules-authoring project may appear to make progress and then serious omissions or misunderstandings in the policies are discovered late as integration begins.
- 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:
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.
# # #