|
untitled
Devil's Advocate View of Business Rule Engines
by Manny Gandarillas
Convincing a business-oriented decision maker to adopt business rules technology for an organization can be a tough sell. What follows are some of the difficulties I have encountered in making a clear case for the technology, as well as how some of the selling points have been tempered by experience.
I think one of the main impediments to a clear understanding of rules is that case studies only make sense to some business people if three factors are aligned. Let's call these the three axes X, Y, and Z.
X-axis — Particular industry or sector described in the case study:
Because of the nature of our work, technical people can easily make logical abstractions so that there isn't much difference between calculating tax rates and setting temperature thresholds. In both cases there are certain conditions that set a decimal. However, a non-technical person may wonder why you are speaking about taxes when he is in the semiconductor device industry — he may see little relevance as far as his business is concerned.
One of my previous employers' CEO would only consider solutions that had been successful in other insurance technology companies. Any success story from outside the industry was irrelevant in his view. I know this is an extreme case but there are such people out there.
Y-axis — Technical sophistication of the audience:
Traditional programming has been mainstream for decades. Non-technical people have a basic understanding of what it can do, even if it's only "whatever happens underneath" when the submit button is clicked. But most do not have a technical insight into the details.
However with rules, we are asking them to compare the details of sequential programming that they never fully understood (object-oriented, subroutines, etc.) with new and improved details (RETE, truth maintenance, backward chaining). So depending on the technical sophistication of the listener, some of these concepts may make little sense.
Z — BRE / BRMS vendor:
Each vendor's Business Rules Engine (BRE) offering is a different animal. There may be little commonality among the offerings in terms of user interface, testing options, knowledge representation, platforms supported, and so forth. So it's difficult to speak of BREs in the abstract or to make across-the-board generalizations. When the non-technical prospect reaches a eureka moment of understanding a difficult concept, it is usually tempered by "well, that's only true if you use Corticon" or "ILOG will do that in the next release."
So the point here is that for a particular prospect, there must be some alignment of these axes in order to generate the desired interest/commitment. Because of this, generic examples and case studies are not as effective.
For example if the listener is:
X — not technically inclined,
Y — in pharmaceuticals,
Z — knows a little about Pega.
He may not get much from a case study that's:
X — fairly technical,
Y — in commercial shipbuilding,
Z — using Haley.
If we go the business route and show the significant ROI achieved by a particular customer as an example, here too there are several variables that need to align. What is the difference between the number of rules in the example and the prospect's organization? The complexity of each customer's technical environment and integration with the BRE? The complexity of decisions in each of the industries? Success for one company may be a poor predictor to success in another if these variables are markedly different.
Many conversations about BREs must still start with "well a business rule is…." There are plenty of Java programmers, departmental VPs, technical recruiters (and anyone that sits next to me on a plane) that have never heard of a BRE. Even within an organization, a given business unit's use of rules says nothing about other business unit's awareness or understanding of rules.
Another advantage of Business Rule Management Systems (BRMSs) is that business people can write their own rules. In my experience with Haley and Mindbox this leaves much to be desired.
- Haley Expert Rules, the most English-like of BRMSs, can offer plenty of challenges to the business-oriented analyst. Some of the date calculations need to be expressed in such a convoluted manner that it no longer looks like natural English. Also the creation of a concept model and relations so that the statements are understood is not a trivial task. And the rules structure consists of modules, sentences, and hanging applicability conditions, making the whole thing very different from standard paragraphs.
- Similarly, Mindbox's Power Editor offers other advantages to a business person. A pre-defined concept model for the mortgage industry uses a spreadsheet metaphor so that rules are entered in simple IF-THEN columns. Even here, however, the business analyst must take care of some complexities. For example, to relate two attributes of a loan to one specific loan (and not to any of the other thousands of loans in working memory) is a steep learning curve for a business person.
The point is, in many cases the business-oriented analyst is able to modify the rules but less likely to construct the knowledgebase from the ground up. "Writing the rules of business" is more likely to be "Modifying the rules of business."
It is also a bit of an exaggeration to say that the knowledgebase can itself serve as the documentation for the rules, as is claimed by some. The artificial structure faced on the language and the hidden complexity (only visible by drilling way down) are part of the actual logic, but the business logic is hard to decipher because it is half exposed/half hidden, half easy/half cryptic.
Perhaps it is more realistic to say that business people can become responsible for certain segments and modify existing statements and/or spreadsheets, and that traceability back to the Business Requirements Documents (BRDs) and Functional Specifications can be tied to each statement. This way there is a clear mapping from the rules back to the original documents.
Although it is certainly beneficial to have centralization of knowledge for easier management, accomplishing this with existing legacy applications can be a different story. At Sungard Insurance Systems we had five different business units, each using its unique data model and a mix of COBOL and Microsoft. An effort to centralize rules for the entire organization failed when the time/resource/cost estimates exceeded even the most pessimistic projections. Resistance came from business units that had rules embedded in applications and from those whose motto was "if it ain't broke don't fix it."
A final point is that, for some major organizations, rules are a competitive advantage — their secret sauce. The last thing they want is for their competitors to follow suit. Therefore, the most convincing cases one can influence a prospect with are the ones most vigorously protected by NDA agreements. I can only talk about one of the most impressive projects I've been involved in in vague terms such as "a Fortune 10 company...."
I have assembled a Table that takes a light-hearted look into the "private thoughts" of three main roles impacted by rules technology — business executives, programmers, and SMEs as they react to each of the selling points. 
|
