Ask yourself …

Why should every business define its own business vocabulary even though almost everybody operates in some larger community of practice? 

Why should every business invent its own business rules even though perhaps only 20% of its business rules directly impact competitive advantage? 

Why should regulatory bodies issue regulations without adequate definitions and provably correct (anomaly-free) business rules? 

Why should contracts, agreements, and deals be signed with terms of agreement and definitions already spelled out, only to have IT implement them essentially from the ground-up? 

What’s the knowledge economy? According to Wikipedia:

“Various observers describe today’s global economy as one in transition to a ‘knowledge economy,’ as an extension of an ‘information society.’  The transition requires that the rules and practices that determined success in the industrial economy need rewriting in an interconnected, globalized economy where knowledge resources such as know-how and expertise are as critical as other economic resources.”

Catch that part about rules?! ~~~~~~~~~~~~~~~~~~~~~~~ from Building Business Solutions: Business Analysis with Business Rules, by Ronald G. Ross with Gladys S.W. Lam, An IIBA^® Sponsored Handbook, Business Rule Solutions, LLC, 2011, 304 pp,http://www.brsolutions.com/bbs    

I am certainly interested in what makes processes smart. But I’m a lot more interested in what makes business smart. My observations:

• A process lets you interact with customers, but doesn’t guarantee those interactions are the best possible.
• A process crosses silos and boundaries of place and time, but doesn’t ensure you communicate across those silos and boundaries.
• A process produces things, but doesn’t ensure you produce the right things.
• A process pays the bills, but doesn’t find you new money.
• A process lets you play the game, but doesn’t determine whether you will win.
• A process lets you act, but doesn’t guarantee you will learn from it.

Here are things I know are directly involved in making your business smart. All of them affect processes, but none of them are processes:

• Business rules
• Core business concepts
• Operational business decisions
• Strategy
• Policy monitors (KPIs)

So as you start hearing analysts say that smart processes are the next big thing, take it with a grain of salt. Be very clear about three things:

1. The target should be smart business – not smart processes per se.
2. Smart automation won’t go very far unless you specify the right things.
3. The things you need to specify are knowledge things, not process things.

(I suppose I could add there are no silver bullets, but I’m pretty sure you already know that.)

Excerpted from Business Rule Concepts: Getting to the Point of Knowledge (4^th ed, 2013), by Ronald G. Ross, 162 pp, http://www.brsolutions.com/b_concepts.php 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 and 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.  Knowledge Companions. Such built-in training 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[1].  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 that business rules bring to architecture is that operational business systems become knowledge companions for workers in the knowledge economy.  After all, isn’t making people smarter the whole point of knowledge?!

---

Excerpted from Business Rule Concepts: Getting to the Point of Knowledge (4^th ed, 2013), by Ronald G. Ross, 162 pp, http://www.brsolutions.com/b_concepts.php Let me use an example to sketch the workings of business rules in smart architecture based on points of knowledge[1].  Refer to the Figure to visualize how the system works.

Aside: I have been using this same slide since 1994(!).

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 — one or more business rules pertain to it.  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 can do it.
• 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.  So it could start off by literally saying, “A customer that has placed an order must have an assigned agent.”  We say the business rule statement is an error message (or better, a guidance message). 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 business agility.

Smarter and Smarter Responses

Is it enough for the system simply to return a 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 any time that applying know-how is key — which these days, is just about always! The Business Rules Manifesto (http://www.businessrulesgroup.org/brmanifesto.htm) 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 breaches (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 decision-making 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.

---

Excerpted from Business Rule Concepts: Getting to the Point of Knowledge (4^th ed, 2013), by Ronald G. Ross, 162 pp, http://www.brsolutions.com/b_concepts.php For me the point of knowledge (POK) is a real place.  POK is where elements of operational business know-how — business rules — are developed, applied, assessed, re-used, 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 operational business know-how (from here on I’ll just say know-how).
• 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, the 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.  It must  be deliberate.  After all, what’s exchanged  at the POK is know-how — something you can’t carry around in your hands. Today, much of your know-how is tacit — lose the people, you lose the know-how they carry in their heads.  How can you avoid that?  Make the know-how explicit as business rules.  That’s what POK are about. Critical success factors in engineering an effective POK include:

• Communication must be strictly in the language of the business, not IT.
• 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 to the level of the company’s most experienced workers.
• Know-how — business rules — must be presented and applied in a succinct, highly-selective fashion.
• Know-how — business rules — must 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.

We are already living in a knowledge economy – let’s start acting like it! It’s know-how (business rules) that makes your company smart. Let’s get to the point of that knowledge.  

1. All know-how expressed in business terms – no ITSpeak.
2. All know-how presented/applied selectively in exactly-as-needed fashion.
3. All know-how presented/applied in ‘just-in-time’ fashion.
4. All interactions gauged to the knowledge level of the role and the person.
5. All workers enabled to ‘play up’ to level of ablest workers.
6. All decisions made 100% consistently – no exceptions (except intentionally).
7. All applications of business rules traceable and transparent.
8. All know-how managed directly – by business people and business analysts.

~~~~~~~~ Adapted from: Business Rule Concepts: Getting to the Point of Knowledge (4th ed.), 2013.  http://www.brsolutions.com/b_concepts.php

I’m just back from the BBC2012 conference in Ft. Lauderdale (close to 1,000 attendees – in spite of Hurricane Sandy!).  One of the side topics of discussion was whether university students are getting the right kind of education to innovate and lead in a knowledge economy. I don’t know the answer – probably not. I’m posting this as an open question … in hope of spurring meaningful discussion. All thoughts welcome! As a starter, what do I think students need to learn about? Among other areas I’d say business architecture / business engineering. Our focus is on developing what makes business operations ‘smart’ – business rules and decision management – operational business IP. For that you need deep skills in concept analysis, plus precision in communication.

It’s been said that I claim the procedural paradigm won’t scale anymore. Guilty as charged! Let me explain. Procedural vs. Declarative In the big scheme of things, you have two basic choices for conceptualization, and ultimately implementation, of business capabilities: procedural vs. declarative. Let’s make sure we agree on what these terms mean. I’ll draw directly on Merriam-Webster Unabridged to make sure we’re on the same page. If the terms don’t mean what they’re supposed to mean, all bets are off. But I guess that goes without saying, doesn’t it?

procedure: 1a: a particular way of doing or of going about the accomplishment of something 1b (1): a particular course of action (2): a particular step adopted for doing or accomplishing something (3): a series of steps followed in a regular orderly definite way

You can spot the seeds of the scalability problem right away with repeated use of the word “particular” and with the phrase “regular orderly definite way” in the definition. Given the degree of product/service customization desired today, and the accelerating rate of change, how much business activity still occurs in a particular and regular orderly definite way? The answer, of course, is less and less all the time. ‘Exceptions’ have become the rule. The essential characteristic of procedures is that they flow. The flow comprises the steps by which a thing is intended to become a different thing (or the same thing in a different state). The essence of ‘procedure’ is therefore that something will be hopefully transformed. For sure, that’s a very basic, very important, very necessary part of any business capability. The problem arises taking procedure beyond that point. Something declarative, in contrast, doesn’t flow. It just states something that must (or should) be true.

declarative: 2: having the characteristics of or making a declaration : ASSERTIVE;  specifically : constituting a statement that can be either true or false

Business rules are that way; they simply give guidance. They don’t do anything. They don’t flow anywhere. They can’t be anything other than true or false. In short, business rules are fundamentally different than procedures. Big-P Process The traditional procedural paradigm (I’ll call it Big-P Process) embeds business rules in procedures (and in process models and in procedural code).What happens when you treat things that could be declarative in a procedural way? You get bloat. You lose business intent. You produce needless complexity. And you also get what I call configuration stagnation. As you scale, these problems grow exponentially. How many business rules are we talking about? Any given business capability easily has hundreds, sometimes thousands of business rules – especially when you begin to factor in the know-how needed to make smart operational business decisions. And don’t our businesses increasingly depend on ever more complex know-how? Is there any end to that trend in sight? At the scale of today’s business, the Big-P Process paradigm simply doesn’t work. It results in ungovernable business operations and unretainable know-how. Big-P solutions are like setting the business in concrete. It’s all so unnecessary and so counterproductive. It’s just not smart. Configuration Agility The key question for agile business capabilities is how the business is configured (and quickly reconfigured) for operation at any given point in time. In the Big-P paradigm, the building-blocks become thoroughly entangled with flow (procedure). The result is essentially a semantic dead zone. Because things that could be expressed declaratively aren’t, the opportunity is lost to use logic to automatically evaluate business rules (read ‘business practices’) for conflicts, anomalies and other logical defects. The future clearly does not lie in that direction. Instead, it lies with granular, declarative, semantically-rich specification of business configurations in building-block fashion. It lies with the paradigm that can produce the optimal configuration agility. In addition to procedures, smart configuration models will feature at least these other building blocks for business capabilities, all specified at the business level:

• business rules 
• operational business decisions 
• structured business vocabularies (concept models, also known as fact models) 
• business goals and risks 
• business events

From an engineering perspective, the secret to agile configuration is ‘late binding’ – that is, bringing all the pieces together for execution (i.e., performance of procedures) as late as possible. That way, performance can be as up-to-date and as flexible as possible. Smart configuration models should be the new mantra for enterprise architecture. In a world of constant and accelerating change, I simply see no alternative. Doing more of the same is simply not going to work anymore (and already hasn’t been for a good, long while). [Warning, plug coming]: Smart configuration schemes also address business governance and compliance – essential in a world of constant change – and just-in-time (JIT) delivery of know-how for operational workers. In our new book, Building Business Capabilities (see http://www.brsolutions.com/b_building_business_solutions.php) we call systems built using smart configuration models business operation systems (as opposed to ‘information systems’).  

I’m kicking off 2012 with a couple of things I just don’t get. Here’s the first one: Why is it that people discussing ‘knowledge management’ seem to have so little understanding of the core know-how actually needed to run (and change) day-to-day business activity? Core operational know-how consists of business vocabulary, business policies, and business rules. That ‘knowledge’ is currently locked away in IT applications and platforms (or in people’s heads) where it is virtually immune to change. That’s a boon to service providers and IT departments, but a bane to business agility. What business really needs today is agile governance … but few seem to be talking about that. P.S. Social media won’t help much here. You simply have to ‘do’ business rules.

Business Architecture Summit at BBC2011 – Thurs, Nov 3, 2011 – 10:10am I am giving a talk next week called The Architecture of Enterprise Know-How at the Building Business Capability (BBC2011) event in Florida. If you’re there, I hope you’ll come listen. I’ll be plowing new ground. We’ve done some fascinating work the past several years and now it’s time to talk about it … Does the know-how of the company have intrinsic structure at the enterprise level? Can you use that structure to assess and plan operational business capabilities? Where do business rules, business processes, and business analysis fit in? Every company depends on its special know-how, a point so obvious we often overlook it. The products and services we deliver to customers can never be better than our capacity to organize, manage, revise, and deploy that know-how. In a knowledge economy, operational know-how is king. Current techniques for creating enterprise architectures are largely IT-centric. They focus on processes, data and services rather than on business products and the business capabilities to produce and deliver them. We need to change all that using proven, pragmatic techniques that directly engage business managers. The new approach is highly innovative, business-driven, and surprisingly easy.

• How to conduct a deep, meaningful, rapid assessment of business capabilities
• How to identify life-cycle-long, enterprise-wide dependencies
• How to give Finance the crucial, coordinated touch points it needs
• How to plan for massive customization and reconfiguration of products
• How to put the ‘business’ into business architecture and business agility
• How to rekindle the spark of creative thinking in your organization