The Point of Knowledge

by Ronald G. Ross

Excerpted from Chapter 10, Business Rule Concepts:  Getting to the Point of Knowledge (Third Edition), by Ronald G. Ross (August 2009). ISBN 0-941049-07-8   http://www.brsolutions.com/publications.php

For me, the point of knowledge (POK) is a real place.  POK is where elements of know-how for business operations are developed, applied, assessed, and ultimately retired.  In other words, POK is where business rules happen.  Knowledge is power, so you can also think about POK as point of empowerment.

POK corresponds to point of sale (POS) in the world of commerce.  POK and POS are similar in several ways:

• In both, something is exchanged.  In POS, it's goods.  In POK, it's knowledge — the know-how of day-to-day business operations.
  
  
• In the world of commerce, we often say that consumer and supplier are parties in point-of-sale events.  Each of us is a consumer in some point-of-sale events, and many of us act as suppliers in others.  The same is true for POK.  Each of us is a consumer of know-how in some POK events, and many of us act as suppliers in others.  Sometimes we switch roles within minutes or even seconds.

A well-engineered experience at the point of sale has obvious benefits both for the consumer — a positive buying experience — and for the business of the supplier — real-time intelligence about sales volume, cash flow, buying trends, inventory depletion, consumer profiles, etc.  A well-engineered experience at the POK likewise has obvious benefits.  For the consumer, it means a positive learning experience.  For the business of the supplier, benefits include real-time intelligence about the 'hit' rate of business rules, patterns of evolving consumer (and supplier) behavior, emergence of compliance risks, etc.

The consumer/supplier experience at the POK is crucial to worker productivity and job satisfaction.  In no small measure, optimizing this experience is the real challenge in POK engineering.  And it must be deliberate.  After all, what's exchanged at the POK is know-how — something you can't carry around in your hands.  Nonetheless, your company's know-how is very real.  Here is what I mean by know-how.^[1]

know-how:  accumulated practical skill or expertness ... especially:  technical knowledge, ability, skill, or expertness of this sort

Today, much of your know-how is tacit — lose the people, you lose the know-how.  How can you avoid that?  Make the know-how explicit as business rules.  The POK is how you make that happen.  Critical success factors in engineering an effective POK include:

• All communication must be strictly in the language of the business, not IT.
  
  
• All interaction must be gauged to the knowledge level (and authorization) of each individual party.
  
  
• Less-experienced parties playing the consumer role must be enabled to perform as closely as possible at the level of the company's most experienced workers.
  
  
• Basic business know-how — business rules — must be presented and applied in a succinct, highly-selective fashion.
  
  
• Basic business know-how — business rules — must also be presented and applied in a timely fashion (i.e., 'just-in-time') to accommodate fast-paced refinement and change in business policies and practices.

Point-of-Knowledge Architecture

Let me use an example to sketch the workings of business rules in smart architecture.  Refer to Figure 10–1 to visualize how the system works.

Figure 10–1.  Point of Knowledge Architecture (POKA)

Suppose you have a process or procedure that can be performed to take a customer order.

• An order is received.  Some kind of event occurs in the system.  It doesn't really matter too much what kind of event this is; let's just say the system becomes aware of the new order.
  
  
• The event is a flash point^[2] — an event where one or more particular business rules need to be evaluated.  One is:  A customer that has placed an order must have an assigned agent.
  
  
• We want real-time compliance with business policy, so this business rule is evaluated immediately for the order.  Again, it doesn't much matter what component in the system does this evaluation; let's just say some component, service, or platform knows how.
  
  
• Suppose the customer placing the order does not have an assigned agent.  The system should detect a fault, a violation of the business rule.  In other words, the system should become aware that the business rule is not satisfied by this new state of affairs.
  
  
• The system should respond immediately to the fault.  In lieu of any smarter response, at the very least it should respond with an appropriate message to someone, perhaps to the order-taker (assuming that worker is authorized and capable).

What exactly should the error message say?

Obviously, the message can include all sorts of 'help'.  But the most important thing it should say is what kind of fault has occurred from the business perspective.  In other words, it should start off simply by literally saying, "A customer that has placed an order must have an assigned agent."  We say the error message (or preferably guidance message) is the business rule statement.

That's a system putting on a smart face, a knowledge-friendly face, at the very point of knowledge.  But it's a two-way street.  By flashing business rules in real-time, you have an environment perfectly suited to rapidly identifying opportunities to evolve and improve business practices.  The know-how gets meaningful mindshare.  That's a ticket to continuous improvement and true agility.

Smarter and Smarter Responses

Is it enough for the system simply to return a business rule statement as the guidance message and stop there?  Can't it do more?  Of course.

For the order-taking scenario, a friendly system would immediately offer the user a means to correct the fault (again assuming the user is authorized and capable).  Specifically, the system should offer the user another procedure, pulled up instantaneously, to assign an appropriate agent.  If successful, the user could then move on with processing the order.

This smart approach knits procedures together just-in-time based on the flash points of business rules.  It dynamically supports highly-variable patterns of work, always giving pinpoint responses to business events (not system events).  In short, it's exactly the right approach for process models wherever applying know-how is key — which these days, is just about everywhere!

The Business Rules Manifesto^[3] says this:  "Rules define the boundary between acceptable and unacceptable business activity."  If you want dynamic processes, you must know exactly where that boundary lies and how to respond to transgressions (at flash points) in real time.

Is that as smart as processes can get?  Not yet.  Over time, the business rules for assigning appropriate agents might become well enough understood to be captured and made available to the system.  Then when a fault occurs, the system can evaluate the business rules to assign an agent automatically.  At that point, all this knowledge work gets tucked very neatly under the covers.  Even if the business rules you can capture are sufficient for only routine assignments, you're still way ahead in the game.

Smart architecture based on business rules is unsurpassed for incremental design, where improvement:

• Focuses on real business know-how, not just better GUIs or dialogs.
  
  
• Continues vigorously after deployment, not just during development.
  
  
• Occurs at a natural business pace, not constrained to software release cycles.

The Manifesto says it this way:  "An effective system can be based on a small number of rules.  Additional, more discriminating rules can be subsequently added, so that over time the system becomes smarter."  That's exactly what you need for knowledge retention, as well as to move pragmatically toward the knowledge economy.  Business rules give you true agility.

Smarter and Smarter Workers

Now let's talk about smart architecture from a consumer point of view.  What people-challenges face your business today?  What role should business systems play?

Time shock.  As the rate of change accelerates, workers are constantly thrust into new roles and responsibilities.  They must be guided through unfamiliar procedures or business know-how as thoroughly and as efficiently as possible.  The business pays a price, either directly or indirectly, if getting workers up to speed is too slow (or too painful).  Time shock is like culture shock — very disorienting if you're not prepared for rapid immersion.

Training.  The flip side of time shock is training — how to get workers up to speed.  Training is expensive and time-consuming.  Yet as the rate of change accelerates, more and more (re)training is required.  Where do you turn for solutions?

The foremost cause of time shock for business workers is rapid change in the business rules.  At any given time, workers might be found at virtually any stage of time shock.  Sometimes, you might find them completely up-to-speed; other times, completely lost.  Most of the time, they are probably somewhere in between.  That poses a big challenge with respect to training.

The only approach to training that will truly scale is on-the-job self-training.  That requires smart architecture, where pinpoint know-how can be put right in front of workers in real time as the need arises — that is, right at the point of knowledge.  What that means, in effect, is that the relevant portion of the company's know-how — its rulebook — is 'read' to the worker on-line, right as the worker bumps up against the business rules.

So a key idea in the business rules paradigm is that operational business systems must become knowledge companions for workers in the knowledge economy.  After all, isn't making people smarter the whole point of knowledge?!

References

[1]  from Merriam-Webster Unabridged Dictionary

[2]  For discussion, refer to Business Rule Concepts:  Getting to the Point of Knowledge (Third Edition), by Ronald G. Ross, August 2009, Chapter 8.

[3] Business Rules Manifesto ~ The Principles of Rule Independence.  2nd ed.  The Business Rules Group (2003).  Updated Nov. 1, 2003.  PDF.  Available at http://www.BusinessRulesGroup.org