It sounded that “Putting the business rules in the hands of the business people” was still one of the most popular mantra at the 2008 Business Rules Forum, a bit like a recurring vow from a political stump speech.
Here are some candid questions about this catch phrase that I would like to explore: Who exactly are these “business people” that we keep on talking about? And do they clearly understand what they’re in for when we propose to put the rules in their hands? Also, is there a reality to this purported urge of IT to retain control over every activity associated with business rules maintenance? Or do we sometimes yield to an easy, Manichean caricature?
So really, who are these business people? Strictly opposing IT personnel to Business people only makes sense in the restricted context of a company’s reporting org-chart, to determine who reports to the Line of Business EVP versus the CIO. From a competency point of view however, the spectrum between Business and IT comes in many shades of gray.
Let’s take an example of different roles from the (almost defunct) sub-prime mortgage business, as illustrated in the figure below.
At one end of the spectrum, we have an underwriting cabinet, a group of mortgage experts who manage the competitiveness of the loan products, either by updating the positioning of the existing products or by designing new ones.
A policy manager is then responsible to precisely codify the underwriting requirements, write the stipulations and conditions associated with the loan product, verify the regulatory aspects of the loan product through the different states, etc… Next up are the underwriters, who run the loan requests against the underwriting guidelines.
Straddling Business and IT territories is the Business Analyst, well versed in the practices and vocabulary of mortgage lending and at the same time, open to get his hands dirty with technology. The QA engineer also usually has a good grasp of business knowledge. We then enter core IT roles such as the Java developer, the DB Administrator or the Release Engineer.
Among these profiles, who has the desire, the time, and above all, the competencies needed to actually analyze, write and test rules in the long run, that is once the BRMS application has been deployed in production and is in its change-time phase. I insist on “in the long run”, because we’re not just talking about blocking a few days or weeks of time to work on the BRMS project. This is about ensuring the continuous stewardship of the rules for the life of the deployed application.
So let’s review our different profiles:
- The members of the Underwriting Cabinet certainly don’t want anything to do with the day-to-day BRMS activities. While they usually are the main project’s sponsor and are the first to understand its business value, the focus of their activity stays at a strategic level.
- The policy manager may be the first line of business people to have any actual interaction with the BRMS, but it is usually in a purely consultative mode, often in the form of reports. Also, there is only one policy manager: His time is precious and cannot usually be diverted (at least for too long) to direct BRMS maintenance tasks. His primary care is to see the policy changes he has authored are reflected as quickly and accurately as possible in the BRMS.
- The Underwriter can be tapped as the SME to harvest and analyze the rules. They can sometimes get enough involved in the processing of change requests through the BRMS that they feel comfortable browsing the rule repository to locate the rules that need to be changed. However, they usually lack the technical confidence to go through the rules authoring process. Moreover, their time and expertise is better used in the analysis part and also to create complex test cases.
- The Java developer certainly has the technical competencies to navigate through the business object model, the rule packages and so on. But he lacks the critical business knowledge ingredient. Also, he is usually the one to crave new technology challenges. Once familiar with the specifics of a BRMS implementation and deployment, he is ready to move on and discover another technology or another implementation.
- The Release Engineer and the DB administrator just have nothing to do with writing rules, nor do they really want any part of it.
It looks like we are left with our jack of all trades: the Business Analyst. With his right mix of competencies, he certainly looks like the best candidate. Besides his knowledge of business and technology, the Business Analyst is essentially a strong communicator, used to move information back and forth between Business and IT concepts. This is a critical advantage since communication between the stakeholders is the cornerstone of a successful BRMS project, as was underlined by this other mantra from multiple Business Rules Forum presentations: “Communicate, communicate, communicate...” (e.g. Gorman & Seer, Habraken).
As part of the organizational changes that naturally come with the adoption of the Business Rules paradigm, the designated Business Analyst then becomes the “Rule Plumber”, a combination of the Rule Steward, Rule Architect, Rule Analyst and Rule Writer hats, with many new responsibilities.
For complex projects or ones that support heavy volumes of change, these responsibilities can (should?) be shared among several persons, thus forming a Business Rule Management Group. In this case, Management should allow the group to borrow members with more business-oriented profiles (such as the Underwriter in our example) for rule analysis, as well as more technical profiles, such as a QA engineer for rule testing.
Note that in the process, we have not, strictly speaking, “put the rules in the hands of the business people”, nor have we surrendered the control of the system to the IT group. Instead, we have defined a person, or group of persons who are responsible for supporting the lifecycle of the business rules, solicit the input and expertise from Business or IT when needed, and enable the benefits of the business rules approach for the business people.
More than trying to find a fickle balance between the good: “Empowering Business Users” and the evil: “IT Control”, this is about recognizing the need for a nimble mediation entity that serves the business while using IT services with discernment.
- It is important to distinguish the development phase of a BRMS project from its production phase. While IT specialists are heavily involved in the development phase, their involvement naturally fades to a minimum once the project is in production. If the development has followed an Agile methodology such as ABRD, where all the stakeholders worked together toward a real business solution, the foundation of the system should be solid enough to go through the production phase with minimal IT involvement.
- Communication is central to the success of a BRMS project. The key first step to take is to establish a set of rule governance processes that formalizes the communication flow and content. The next step, for large and complex applications, is to form a Business Rules Management group who will initiate and control the communication between the different Business entities and involve IT when needed. For smaller or less complex applications, there should be at least one central person to foster the communication, and in most cases, get his hands dirty in the rule change implementations.
With such a pivotal role in supporting a BRMS application, Joe the Rules Plumber may well be worth more than the fatidic $250K threshold...!