Eliciting expert knowledge is a critical step in any business rules project.  It is sometimes straightforward because the regulations or business manuals that dictate what needs to be automated are well-documented.  But real-life projects are typically not that easy.  Why not?  The human brain has a way to accumulate experience over time that turns into "know-how" that is often hard to formulate and yet plays a critical role in the quality of the decisions made.  This month I explore the different kinds of knowledge that drive your decisions and the techniques used for knowledge elicitation, as well as the impact of business uncertainty.

Business Rules as Facts

In order to capture the business rules, a good knowledge worker needs to explore all aspects of the business, collect every single statement that describes how companies do business today, and anticipate the needs of the business tomorrow.  There is a fine line though between facts and logic in the body of knowledge that is harvested.  This modeling exercise produces both facts that are the basis for the data/object model and logic that is the basis for what we also call "production business rules."

Let me use an example to illustrate.  A business might state that "an application may include multiple applicants but one and only one needs to be identified as the primary policy-holder."

One might argue that this statement is a business rule, from a discovery perspective.  Once implemented, it is likely that this source rule will be codified directly in the object model as an array.  Agreed semantics will dictate whether the primary policy holder is the one stored in the first position in this array or whether a separate attribute will hold this particular value.  This is true for most statements that are about structure, e.g., 'a car has 4 wheels'. 

A fair number of those factual statements end up in the object model.  You may recall the Great West Insurance speaker at Business Rules Forum 2010 revealing that only 3 of their 300 source rules turned up in a rules engine.

This is where business rules capture blurs with data modeling.  Techniques overlap for getting the substance and for transforming it.  In many consumer-facing applications, the data/object model is an abstraction of 'paper' forms that already exist, such as the standard Freddie Mac paperwork for mortgages.

Business Rules as Business Terms

I make a distinction between the vocabulary that is captured in the object model and the expressions that are derived from this vocabulary.  For the sake of this discussion I will refer to business terms as the definitions or calculations that are defined by the business and contribute to enriching the object model.

As an example, calculations such as Life-Time-Value (LTV) or the definition of a customer segment such as VIP would fall into that category.  They are made of either a mathematical or Boolean expression that can then be leveraged as if they were mere attributes.

How do you come up with business terms?  Those are similar to the facts we discussed earlier.  Both definitions and calculations are typically documented by the involved stakeholders, such as the Business Unit (for LTV) or a Marketing department (for the VIP customer segment).  These metrics often already exist.  Those that do not will eventually come up in the elicitation of 'true' business rules, as we will cover below.

Could those business terms be implemented as a business rule?  Business terms can be implemented either way.

Some projects implement business terms in the application code or data/object model because those definitions do not change very frequently.  The main argument in favor of a code approach is the need for performance.  Calculations can be costly, especially if they require additional data to be retrieved.

The trend has been to push those calculations into the rules world even though they may not change as often as the cut-off rules that use them.  Visibility is the Number-one factor.  Being able to understand the definition behind the variables increases the opportunity for reuse and, quite effectively, reduces the chances they will be misused.

The performance trade-off is not as drastic as it may seem.  Business rules can make the calculations opportunistic.  The key design decisions for performance reside in the availability of data, but that is a topic for another article.

Business Rules as Known Exceptions

The rest of the business rules harvesting falls into the category of deeper and more volatile knowledge acquisition.  The knowledge worker will answer questions on how he/she does business today.

The harvested knowledge includes both the business processes and the decision points in those processes, including how to treat exceptions.  Business rules are a natural partner to BPM as they remove the clutter created by those many exceptions and get them well-packaged into decision points.  The resulting process map is clear and crisp — easy to maintain in the long run — while exceptions can be added as they arise.  Both evolve at different pace:  Processes are relatively well established until a business or organizational disruption occurs, while business rules tend to change on a daily or weekly basis in many businesses.  Separating them helps manage those life cycles properly.

Let's take an example for illustration.  An expert in Collections & Recovery can talk about the necessary steps for handling a new case, which will turn into the business process model.  At some point in time, assuming that the service is not getting much success fixing the situation with the delinquent account, the case will be sent to a Collection Agency.  Lots of decisions come into play:  Is it more cost-effective to handle internally or to subcontract?  Do the local regulations allow me to pursue this treatment?  How long does my internal policy state we should wait before we send the case out?  Which Collection Agency will I choose? 

For each decision involved in that process many business rules need to be harvested:  "If the customer is VIP, I will forgive up to…" and "Customers with those and those characteristics will receive a letter to remind then to pay; those other customers will be charged a fee immediately; those other customers will get a phone call, etc."

The role of the business analyst is to extract those pieces of knowledge and to structure them.

The modeling techniques adopted by most of the vendors/consultants in that arena tend to organize those thoughts in a formalism that lends itself to an easy codification into executable business rules.  Some prefer to use formal and structured grammar to describe those requirements; others capture them in a spreadsheet.  The methodologies that I see today focus on the translation from language to structure.  Of course, those modeling methodologies sometimes complement the analysis of existing documentation as business manuals or rating tables that already exist.

Why did I refer to 'known exceptions' in this section? 

Some business rules state the appropriate treatment for the general case, of course, but the value of using business rules is to package the hundreds or thousands of atomic pieces of logic in a bucket that will handle execution without the need to code them in a programming language.  This is the ideal way to decouple exceptions from the software code.  The exercise is all the more effective when you know what you are looking for, hence the term known exceptions.  The experts and/or the business analysts need to know what exceptions need to be harvested.  The details may not be known yet but the types of rules and the types of decisions must be known (to some extent) so that they can be elicited from the expert.

Business Rules as Unknown Exceptions

So, what happens for the remaining business rules that we do not know about?

First of all, let me make the case that they exist.

If you had to spell out every single rule you execute in your subconscious when you drive (for example) are you confident that you will be able to come up with an exhaustive list?  Do you know where to get started?  Will you think about adding a catch-all rule that will make you look in the car booklet or ask a specialist when a dashboard indicator you are not familiar with turns on?  ... or when your kids discover how to unbuckle themselves in full traffic?

Exceptions exist today, and fortunately your skilled workers know how to address them most of the time, as they arise.  Making them bubble up from the deep subconscious of the knowledge worker is the difficult part.

Consider also the case for unknown exceptions that you have not even encountered yet.  If there is one thing we learned or realized during the recent recession, it is that we live in a world of uncertainty.  Black Swans happen.  I would venture that complexity is increasing due to phenomena like globalization — addressing a wider array of market segments and cultural diversity — and also to the explosion of data and channels available.  Social Media has opened the door for a world of connectivity that previously we could not dream of.  Information is available in a grand scale!  Making decisions based on a subset of the available information will soon become competitive weakness.  Some current fraud detection systems do leverage social information to investigate fraud rings and the likes.  The pressure is building to incorporate more and more data points into our decision-making processes.

To add insult to injury, those technologies and information stocks are maturing as we are trying to improve our decisions, making it hard to know what strategy is right for the business.

I am personally very passionate about those unknown exceptions because I see the value of your decisions slowly shifting toward your manual decisions.  Most companies will be able to do a decent job with automated decisions (what I described as the known exceptions) but treating effectively what are today manual decisions will be how companies differentiate themselves, both in terms of service and in terms of operational efficiency.  I also got involved very early on with expert systems, which presented the same challenge.  Experts systems were only as good as the expertise you could capture.

So how do you capture unknown exceptions?  It certainly sounds like a conundrum.  Is it even possible to capture something you cannot formulate?

I believe it is.  The key is to shift the focus away from the exercise itself — away from the end product you are trying to produce.  I believe that the key is to consider the decisions that must be made in their own business context.

How?  I was quite inspired by a concept that Jim Sinur developed in his blog at Gartner on "Design by Doing."  We all agree that some of the business rules are implemented by design — per the section on Known Exceptions ("I know that when this occurs, I want to do that.").  But we need to complement what we know with a mechanism to capture on the job what we do not yet know.

The concept of Design by Doing applied to Decision Management is to let knowledge workers make decisions as they are already doing in call centers or underwriting departments (etc.) and capture the logic behind those decisions as they are being made.  This does not mean that you have to necessarily intrude into the intensive volume-oriented productivity of the group.  This small overhead can be spent at any point in time, real-time or batched.  The important concept is to remain focused on the decision at hand in the context of the current case or current portfolio.

Design by Doing addresses the ability to extract the knowledge out of skilled knowledge workers in an objective manner.  Additional tooling and techniques must be provided for dealing effectively with uncertainty, but this will be my topic next time.

# # #