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.

---

The subtitle of my Business Rules Concepts handbook (now in its 3^rd edition) is ‘Getting to the Point of Knowledge’. I wasn’t trying to be cute, I meant it literally. Here’s an example. Try entering a URL in a LinkedIn invitation. I don’t know if it’s a new business rule or not, but I tried it for the very first time just the other day to point someone in the right direction on an EA question. Not allowed. I didn’t know that. I was informed and now I’m a wiser member of the social community. This is an example of what in our new book ‘Building Business Solutions: Business Analysis with Business Rules’ (Oct, 2011) we call real-time business operation systems (BOS). It takes a just-in-time (JIT) approach to the delivery of know-how. (A business rule always encodes know-how.) In my LinkedIn experience I was informed of the latest business rule in-line in a self-service, JIT manner. Violate business rules (the latest one or any of them) and if you’re authorized and capable, you’ll get back a ‘training’ message. Here’s what LinkedIn said back to me: We’re sorry, you cannot include website addresses in invitations. Please remove the website address and try again. Here’s a more direct statement of the business rule in RuleSpeak: A LinkedIn invitation must not include a URL. The RuleSpeak version conveys the same information as the LinkedIn message, just more succinctly. As I’ve been saying since at least 1994, the business rule statement is the error message. It’s the error message from a business, not system, point of view. That’s why it’s called a business rule. If you do want a friendlier version (as LinkedIn did) that’s fine. Think for a minute about your operational business processes. Many of your business rules either change frequently, unexpectedly or both. How can you keep all your operational staff up-to-speed? Constantly send them off to training classes?! Flood them with tweets or e-mails?! Not going to work. In a world of constant change, a system is not state-of-the-art unless it addresses continuous re-training. Business rules do. Ultimately there’s no alternative. I’ve been saying that for a long time too.