A client recently asked me for guidance in establishing a center of excellence concerning business rules within their organization. Their objectives included:
- Accumulate requisite skills for productive success.
- Establish methodologies for productive, reliable and repeatable success.
- Accumulate and reuse content (e.g., definitions, requirements, regulations, and policies) across implementations, departments or divisions.
- Establish multiple tutorial and reusable reference implementations, including application development, tooling, and integration aspects.
- Establish centralized or transferable infrastructure, including architectural aspects, tools and repositories that reflect and support established methodologies, reusable content, and reference implementations.
- Establish criteria, best practices and rationale for various administrative matters, especially change management concerning the life cycles of content (e.g., regulations or policies) and applications (e.g., releases and patches).
I was quickly surprised to find myself struggling to write down recommendations for the skill set required to seed the core staff. My recommendations were less technical than the client may have expected. After further consideration, it became clear than any discrepancy in expectations arose from differences in our unvoiced strategic assumptions. Objectives, such as those listed above, are no substitute for a clearly articulated mission and strategy.
Some organizations still use rule engines solely as a means of interpreting externalized technical rules so that the behavior applications can change without recompiling or re-linking code or re-booting systems. Generally, anyone using CLIPS, JESS, or Oracle (i.e., as in Fusion or in the database but excluding Siebel) is in this camp, as is anyone using Prolog, RuleML or any of the semantic web rule languages. The same is true for the OMG’s Production Rule Representation (PRR) and will be true for W3C’s Rule Interchange Format (RIF).
Most organizations now adopt rules with a less technical but more business-oriented perspective. They place greater emphasis on the capture and management of business rules by less technical users. Organizations in this camp have inevitably selected one of the commercial vendors of business rules managements systems (BRMS), including Ilog, Fair Isaac‘s Blaze Advisor, Haley / Ruleburst / Siebel, Yasu / SAP, Corticon, or Inrule.
The market for rule engines is similar to the market for SQL or Java. It is quite mature. The market for business rule management systems is now in the mainstream. It ranges from early to later majority, depending on the industry and application. Decision-intensive industries tend to be more mature, with more complex areas, such as commercial loans or insurance being less developed than conforming mortgages or personal lines.
As the following graphical summary of Moore’s Crossing the Chasm indicates, people now adopting rules technology for the first time are laggards while those adopting BRMS are pragmatists or conservatives, but not innovators or visionaries. That is, they are driven by tactical needs rather than strategic thinking.
Our advice concerning skill acquisition and development differs significantly based on my clients’ mix of tactical and strategic objectives. More strategic clients emphasize objectives such as:
- reducing the effort involved in translating definitions, requirements, regulations and policies as they are understood by the business into technical specifications
- minimizing the critical path between identifying and deploying dynamic requirements, regulations or policies by eliminating pre-requisites, such as:
- minimize the impact of change by managing the definitions of vocabulary used in requirements, regulations and policies and how they relates to various implementations in a loosely-coupled manner
- minimize analytic translation into “if-then” rules from definitions, requirements, regulations and policies as they are naturally provided, expressed, or captured
In other words, more strategic organizations place greater emphasis on the separation of the capture and management of knowledge from its implementation or use at run-time.[1] The merit of such strategies are reflected in the increasing use of words like “semantics”, “vocabulary”, and “ontology” by vendors, analysts, customers and standards bodies, as well as continuing investment in increasingly natural rule languages by vendors.
Continuing improvements in natural language understanding will maximize the benefits of knowledge management and facilitate further use beyond technical staff by achieving these strategic objectives. Additional metaphors, such as decision trees or tables, spreadsheets or form-based templates are also useful, of course, but they are inherently less agile, require more setup and impose limits on either the user community or system functionality or both. Interestingly, to the extent that mixed metaphors are appropriate, users interpret each of them using natural language! That is, they “read” structured expressions, such as decision tables, as sentences.
For the simple reason that people already communicate and understand using their own natural language which can easily express any statement (e.g., of policy), the ability to elicit or harvest and manage unambiguous, grammatical sentences is among the principal skill requirements for staff in a center of excellence.
Proficient ability to elicit sentences requires certain strong oral communication and interpersonal skills. In addition, written communication skills are also critical in order to validate elicited understanding with the source or other parties. The reduction of elicited or harvested knowledge to writing is obviously necessary and critical if that knowledge is to be shared and managed over time.
The closer captured knowledge is to sentences the easier it will be to automate. Content that cannot be reduced from a paragraph to independent sentences requires more effort. Any interdependency among sentences in a paragraph or any context to a paragraph must be made explicit in order to automate (i.e., implement) the paragraph. Fortunately, most of this structure corresponds to the flowchart typically captured using business process management (BPM) tools.
A skilled member of the center of excellence staff should therefore also be able to capture and confirm business processes. Any programmatic tendencies should be suppressed, however. The essential objective is to find truth rather than to invent flows. Also, from a knowledge management perspective, confirming a complex business process is impractical. Furthermore, perhaps paradoxically, a business process with a complex flow chart is most likely poorly understood. Apparently complex business processes typically result from failing to isolate the statements that govern decisions and actions from the process flow. This is precisely the benefit of externalizing rules and it is these externalized, natural language statements that we aim to manage as knowledge.
The deep objective of staff should be to uncover truth more than flow. This should be reflected in their skill set. Mathematicians and philosophers are ideal candidates in that they are highly trained in seeking and contemplating the implications of truth. The same holds for pure scientists in mathematically rigorous fields, such as physicists. Each of these disciplines emphasizes truth without emphasizing process. Communication skills may be a challenge in some cases, but not typically with philosophers since they use natural language intensively. Lewis Carroll would probably excel as a “knowledge engineer”! Regrettably, computer scientists tend to pursue sequence more than truth. This is especially true for programmers but less so for data modelers or theoreticians.
In order to introduce rules engines into the enterprise architecture, the center of excellence will certainly need programmers, but the level of effort required is measured in man months, not years. It takes very little coding to integrate a rules engine. Once the engine is integrated the change should be external (i.e., to the rules). On the other hand, if a rules engine is being used without a BRMS then programming skill will be needed to codify the rules themselves. In this case you should consider the use of a tool like RuleTrack to capture, formalize and manage the relevant knowledge. We agree with RuleXpress that neither Word nor Excel support the work effectively.
Consultants are particularly effective for such work. Since you don’t need programming skill full-time, year-round, why not let a consultant accept responsibility? Certainly they should be productive! And if you are manually translating managed knowledge into technical rules, consultants should offer predictable costs and responsiveness with extremely low risk or variability. A consultant should be willing, for example, to give a fixed price and timeframe for translating a collection of grammatical sentences that use a defined vocabulary which maps to an object or data model in technical rules. In the limit, the billed time per rule might not exceed 15 minutes but should not exceed an hour in any case. Whether consultants or staff, you might require at least two such people available full-time in order to handle any crisis with some redundancy.
Once again the key skill to be developed and retained in the center for excellence is the interpersonal and communication skills to clarify knowledge and establish consensus where appropriate. In addition to the innate pursuit of knowledge and truth, the skill of listening is critical to elicitation. If rules are to be harvested rather than elicited, listening may seem less important at first, but clarifying conversations with stakeholders and subject matter experts are inevitable. Whether elicited or harvested, it is critical to validate knowledge by confirming its ramifications.
The validation of knowledge usually proceeds through several phases. As knowledge is being acquired, ramifications are derived by mental inference and considered. Such ramifications often lead to inconsistency, usually as a result of imperfect knowledge (i.e., a misunderstanding). As scenarios are considered and the body of acquired knowledge grows and matures, scenarios may naturally become more detailed “use cases” for application development. Eventually, as many scenarios of varying detail accumulate, they may become a substantial body of test cases and be used within a technical architecture to test versions of knowledge bases, such as before releasing them into production.
Scenarios can be extremely useful in acquiring knowledge, whether by clarifying the ramifications of policy among stakeholders or extracting further knowledge from subject matter experts through protocol analysis. The mental skill of simulation, the ability to recognize inconsistencies, and the social skill to discuss ramifications in hypothetical scenarios productively are all important. In addition to listening, one of the key social graces required to elicit and validate knowledge is considerate patience. It is all too easy (and common) for those eliciting or clarifying knowledge, like children, to impetuously ask “why”. Finally, it is important to remain dispassionate. It is also too easy to become confident in one’s accumulating knowledge to the point of professing as an expert or out of insecurity when stakeholders’ or subject matter experts’ questions should indicate missing knowledge or a misunderstanding.
Now, finally, I can summarize the characteristics that my experience indicates are most important for success – and, therefore, development within a center of excellence:
- a controlled passion for knowledge and truth
- extraordinary attentiveness and listening skills
- excellent oral and written communication skills
- powerful mental simulation and problem solving skills
- a mature and secure sense of self, especially when incorrect or not in authority
- the absence of tendency to see the world from the perspective of a tool or technique, especially procedurally but not strictly in terms of rules, either
Of course, there are specific skills aside from personal traits, many of them somewhat obvious. Experience documenting requirements, regulations, and policies with subject matter experts or stakeholders is great but it is much better if that experience includes personally and iteratively reviewing the resulting documents with them. Experience defining data models and class taxonomies is also helpful in defining and managing vocabulary and ontologies, but care should be taken to avoid technologist who place too much emphasis on any one technical perspective, whether process centric, object- or service-oriented or rule-based. Experience with the rule engine or language to be used is clearly nice to have, but it is not needed in large quantities. The same is true for any particular BRMS.
Additional skill requirements arise from tool limitations. For example, requirements often use the modal verbs “must” or “shall”. No BRMS currently supports automating such statements. In addition, I know of only one BRMS that supports statements that use the word “unless”, which is also quite natural and common in my experience. There are also few rule engines that can compute quantifiers such as “only”, aggregates such as “average”, or superlatives such as “minimum” or “most recent”.
Each of these limitations requires manual translation from the more naturally acquired and managed form. Most systems, for example, will require sentences that negative disjunctions (e.g., use the word “neither”) or that have exceptions (e.g., use the word “unless”) to be converted into a collection of if-then rules, as in disjunctive normal form (DNF). For practical reasons, therefore, the staff should be familiar with formal logic, especially first-order logic (i.e., predicate calculus) and relational algebra (as in SQL).
The only thing remaining is to map business vocabulary to implementation details. Such tasks require an analytically skilled member of the technical staff who is comfortable relating object or data models to definitions of business vocabulary, such as an enterprise architect. Such tasks may involve defining a model to be used internally by a rule engine in addition to mapping to services or models that exist in the enterprise infrastructure. This activity is evolutionary and low bandwidth except when first mapping a vocabulary to an implementation or when a technical model is substantially revised.