Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence

TURNING OPERATIONAL KNOWLEDGE & COMPLIANCE INTO A COMPETITIVE EDGE

We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

The Debate Continues: Expert Systems vs. Business Rules

Here is my latest post in the on-going debate over decision management systems, expert systems, and business rules. ~~~~~~~~~~~~~ There is a fundamental difference between rules whose intent is enforcement (however strict) vs. rules whose intent is to make (expert) decisions. Rules whose intent is enforcement (e.g., speed limits) revolve around:

* detection of violations (think speed trap) * level of enforcement (e.g., strictly enforced) * violation message (electronic sign flashes ‘You’re speeding’) * violation response (cop chases you down the street with siren) * sanction or penalty (speeding ticket and a fine)

I chose an example that is probably not automatable (never be too sure) because such ‘behavioral rules’ (SBVR term) are everywhere in everyday life and therefore easy to comprehend independently of existing platforms and IT support. But there are a huge number that are automable; we just seem to be blinded to them sometimes for whatever reason (probably technical bias). Behavioral rules would not be involved in diagnosing (deciding) what’s wrong with a missle or classifying (deciding) the risk category of a prospect for insurance. In SBVR those are ‘definitional rules’ (or you could call them decision rules). They are about (encoding the know-how to make) smart (expert) decisions. It is true that decision rules often support behavioral rules in some fashion (e.g., is this particular speeder worth bothering over?). But it always comes down to this fundamental distinction: Is the end-point about enforcement, or is it about a decision. Enforcement and decisions are simply different. Are decision rules and behavioral rules both business rules? Yes. Should they be treated the same by platforms and methodologies? No. Why? They are different. Failing to understand the difference harms both business ‘users’ (poor governance processes) and decision management systems (oversell).

Continue Reading 4 Comments

Don’t Fall Victim to the Whirlpool of Decision Hype

Consider the following behavioral business rule: A renter must not have possession of more than one rental car. In discussing enforcement of this rule, one reviewer said something to the effect, “We have to think about what happens ‘at the time of the decision’. Hold on. What ‘decision’?! I don’t see any decision. What ‘decision’ could he possibly be talking about? When it comes to behavioral rules and their enforcement, there’s no ‘decision’ in a meaningful business sense. Let’s think it through.
  • There was the governance decision to create the business rule in the first place, but that’s not operational business activity per se.
  • There might be a decision about whether and how strictly to enforce the rule, but that is an enforcement question, not an operational business decision either.
  • If the decision is ‘Are we following our rules?’ that’s a bogus operational business decision. It might be valid as a test or simulation, but that’s not a decision per se either.
A good analogy for the enforcement of behavioral rules is a game of football. There are referees who ‘watch’ on-going (business) activity and throw a flag when a violation occurs. But they stand on the outside of the plays (processes) looking in. Now a player may ‘decide’ to violate a rule, but we frankly don’t care about individual ‘decisions’ of those kinds. We care only about the resulting (business) behavior (hence behavioral rules). Let’s return to the behavioral rule: A renter must not have possession of more than one rental car. Here’s the important point with respect to business processes. The rule is expressed declaratively. Although specified only once, it is presumably relevant to multiple business processes – e.g., for new bookings, rescheduling of existing bookings, extension of open rentals, late returns, etc. We call points in business processes where a rule needs to be tested ‘flash points’. Like the referees in a football game, a run-time business rule facility should be watching all on-going activity to detect violations anywhere and everywhere they might happen. You might say the facility is ‘deciding’ that violations occur, but who cares … again, those are not operational business decisions. For our purposes, violations either happen or they don’t. Don’t get me wrong. ‘Decisions’ do have an important place in both business rule thinking and in creating smarter business capabilities. But right now there seems to be a whirlpool of decision hype that’s sucking up altogether too many good brain cycles. We need to see what role decisions do play in business analysis clearly so we can exploit the new techniques to their fullest.

Continue Reading

A Buzzword Like ‘Decision’ that Covers Everything May Soon Cover Nothing

One thing that concerns me about ‘decision’ or ‘decision management’ is that everything potentially becomes a decision. Software vendors love it when complex problems can be reduced to a single buzzword. Engineers of true business solutions should hate it. I’m sure I’ll be accused of negativism, so for the record, let me say that top down analysis of operational business decisions is extremely useful, either along with, or outside of, business processes. We have a highly pragmatic approach for decision analysis based on ‘question charts’ (Q-Charts). We use it extensively to capture decision rules. But do I think that decision analysis is the most important part of delivering a winning business solution? Not by a long shot. Your strategy for the business solution is much more important. Even that’s not enough though – strategy only tells you why. We need business models that cover all aspects of a business solution (think what, how, where, who, and when). So no, it doesn’t (or at least shouldn’t) all boil down to ‘decisions’ … unless by that you mean anything and everything. And what good is that? I’m always very careful to say ‘operational business decision’ instead of simply ‘decision’. Immediately that excludes governance decisions (e.g., creating a business policy) and strategy ‘decisions’ (as in MBA-school ‘business strategy’). That’s an important first narrowing of the field. Something else commonly mistaken for an operational business decision is a simulation of “what would happen if we did this operational task right now”. For example, let’s run a claim by all the behavioral business rules and see if the claim is acceptable before we do it for real. That’s simply a test, not a decision. That’s a second important narrowing of the field. Clearly we need a solid definition of what a decision is and isn’t in the context of business analysis. We define an ‘operational business decision’ as: a determination in day-to-day business activity requiring know-how or expertise; the resolving of a question by identifying some correct or optimal choice. To make such decisions you need decision rules (think classification or inference rules) that ‘map’ cases to outcomes. Decision rules are one type of definitional rule. The two types of business rules in SBVR are definitional rules and behavioral rules. Business capabilities do usually involve large numbers of decision rules, but they also always involve large numbers of behavioral rules. Behavioral rules are rules you can violate, like speeding through a school zone. There’s no decision to that … you either are or you aren’t speeding. Well, you may have made a personal decision to speed, but let me tell you, City Hall doesn’t care. Personal decisions – out of scope too, a third important narrowing of the field.

Continue Reading

The Fundamental Problem of Software Engineering is Not about Decisioning

I am always very careful to talk about ‘business rules’, not ‘rules’. We define ‘business rule’ as a criterion used in business operations to guide behavior, shape judgments or make decisions. We have not perceived any poverty of guidance that fits that definition(!). One reason we always say ‘business rules’ is because we make no attempt to capture rules that mimic intelligent behavior in the original sense of expert systems. That problem is at least an order of magnitude more difficult than capturing organizational (business) rules … which is hard enough as it is. Business rules always trace to some source … even if the source is now unknown (or has gone to work for the competition). Organizations are dependent on people on the inside, and on interactions with people and organizations on the outside. So a great many business rules are about the behavior (of people and organizations). Ensuring conformance with such behavioral rules – and being able to change and redeploy them quickly – is the fundamental failing of traditional software development. It literally boils down to keeping your commitments (as expressed in contracts, agreements, MOUs, deals, certifications, regulations, acts, laws and so on). I’m all for better decision management, but fail to address the root problem of software engineering and we’re simply grasping at straws.

Continue Reading

How Business Rules, Decisions, and Events Relate in True-to-Life Business Models

What is operational business know-how? How can you model it? What results can you achieve by doing so? The answers lie with creating true-to-life business models based on behavioral rules, decision rules, operational business decisions, and operational business events — all as first-class citizens. Understanding their intertwined roles is key to creating top-notch business solutions and business operation systems unmatched in their support for business agility and knowledge retention. Find out what ideas and techniques you need to create know-how models: http://www.brcommunity.com/b623.php

Continue Reading 1 Comment

Business Analysis & Business Rules – Announcing Our New Book and BBC 2011 Conference – **Special Discounts** for Friends and Colleagues

Let me mention two important things happening soon and special discounts for them – Both discounts good only through **Friday, September 30**   1. ANNOUNCING OUR NEW BOOK … Coming in October! BUILDING BUSINESS SOLUTIONS: BUSINESS ANALYSIS WITH BUSINESS RULES … an IIBA Sponsored Handbook (304pp) … It’s all about taking Business Analysis to the next level of capability.  http://www.brsolutions.com/bbs >> Receive 25% off the book’s list price of $39.95 if you pre-order now. Use discount code **BBS1001**.  2. BUILDING BUSINESS CAPABILITIES CONFERENCE (BBC 2011) … Oct. 31 – Nov. 3, Ft. Lauderdale, FL  http://www.buildingbusinesscapability.com/  The must-attend conference of the year covering all things ‘business’.  Four conferences in one for a total of 9 tracks on pace this year to be a sell-out!  >> Receive a 15% discount on registration. Use discount code **RRBBCFL**.  * Business Analysis Forum, the Official Conference of the IIBA. http://www.buildingbusinesscapability.com/baf/ * 14th annual Business Rules Forum Conference. http://www.businessrulesforum.com/ * The 1st annual Business Architecture Summit. http://www.buildingbusinesscapability.com/bas/ * The Business Process Forum. http://www.businessprocessforum.org/

Continue Reading

Why Your IT Project May Be Riskier Than You Think

Several comments on a must-read HBR article for an organization considering any IT project of significant size …. Why Your IT Project May Be Riskier Than You Think by Bent Flyvbjerg and Alexander Budzier  Harvard Business Review – September, 2011 http://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think/ar/1 I found several points in this article particularly insightful:   1. “As global companies become even more reliant on analytics and data to drive good decision making, periodic overhauls of their technology systems are inevitable. But the risks involved can be profound, and avoiding them requires top managers’ careful attention.”   >>I’m afraid the large majority of IT professionals don’t really get this … even if they say they do. Prevalent IT requirements methodologies don’t address it well at all. It’s essential that the approach a company takes involves business people to develop business solutions based on business goals before creating system designs. There’s a business problem first, then and only then a technology problem.   2. “Insufficient procedures for financial reporting and internal controls …” >>We see this time and time again as IT designers create very ‘open’ designs that are not based on a common set of business concepts and do not embed a common business perspective. The inevitable result — “revenue leakage” … and as this article points out, much worse. Again, there’s a business problem first, then and only then a system problem. 3. “When we broke down the [IT] projects’ cost overruns, what we found surprised us. The average overrun was 27%—but that figure masks a far more alarming one. Graphing the projects’ budget overruns reveals a “fat tail”—a large number of gigantic overages. Fully one in six of the projects we studied was a black swan, with a cost overrun of 200%, on average, and a schedule overrun of almost 70%. [Only one in six? I think that figure is too low!] This highlights the true pitfall of IT change initiatives: It’s not that they’re particularly prone to high cost overruns on average … It’s that an unusually large proportion of them incur massive overages … By focusing on averages instead of the more damaging outliers, most managers and consultants have been missing the real problem. ” >>The point is simply that IT ‘change initiatives’ are risky propositions, and need to be addressed with … what else … upfront business strategy. That’s what we call a Policy Charter, and we’ve been guiding organizations through its creation for more than a decade. Doesn’t take that long … if you have the right people and the right motivation. Skip it … and pay the consequences!

Continue Reading

I talk about business rules – Roger Burlton and I both talk about recent problems of the financial sector

Here’s a short clip about business rules from an interview in Amsterdam not too long ago. I actually agree with what I said … http://www.youtube.com/watch?v=fhv7bGf3r3Y&feature=related There are several related clips there with John Zachman, Roger Burlton, and Silvie Spreeuwenberg (LibRT) worth a few minutes of your time — business rules, decisions, business processes, enterprise architecture, and more.

Continue Reading

Laws of Commerical Semantics … by Curt Monash

Ever suspect a high B.S. factor in the categories vendors use for their products? Wait, let me ask that differently: Has anyone not suspected a high B.S. factor in the categories vendors use for their products? I came across some older posts by Curt Monash that formalize the rules of software category B.S. I invite you to read them — good stuff. By the way, Curt Monash is an independent industry analyst I’ve greatly admired since his gutsy take-take of Cullinane some 30 years ago. [My comments in brackets.] Monash’s First Law of Commercial Semantics: Bad jargon drowns out good. “The idea behind the ‘Law’ is this:   If a term connotes some kind of goodness, marketers scarf it up and apply it to products that don’t really deserve it., making it fairly useless to the products that really do qualify for the more restrictive meaning. ‘Predictive analytics’ sounded cool, and now covers a fairly broad range of statistical analyses, most of which don’t involve any kind of explicit prediction.” [“Decision management” is already headed in the same direction … or worse.] http://www.strategicmessaging.com/monashs-first-law-of-commercial-semantics-explained/2009/01/09/ Monash’s Second Law of Commercial Semantics: Where there are ontologies, there is consulting. [Ooooh, the “O” word!] http://www.texttechnologies.com/2007/12/23/text-mining-myths-realities/ Monash’s Third Law of Commercial Semantics: No market categorization is ever precise. [This one is probably self-evident.] http://www.strategicmessaging.com/no-market-categorization-is-ever-precise/2011/03/01/ Most recently Curt invokes the Third Law for “Complex Event Processing” (CEP). He suggests that “Data Stream Management ” might be a better term. www.dbms2.com/2011/08/25/renaming-cep-or-not/ Although possibly on-target for current products and their technical orientation, I disagree with him here in the bigger picture. Events are simply a different primitive than what data represents (things). So the suggested name takes the focus off-target. Perhaps “Event Stream Management” would be better. Why does this interest me? Sooner or later, techniques and tools for business analysis need to come to grips with business events. This focus is essential for truly supporting business rules and know-how management. “Events” belong right up there with the other five primitives: things, processes, locations, roles, and goals. (Yes, there’s six — it’s a Zachman view.)

Continue Reading 1 Comment