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

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

Requirements are Rules: True or False?

This is an excerpt from our new book: Building Business Solutions: Business Analysis with Business Rules coming out in October. Watch for it! “Requirements are rules.” Perhaps you’ve heard the argument. Maybe you’ve even made it yourself. Are they? No! Basic reasons why requirements are not rules:  Business people don’t naturally think of a ‘requirement’ as a ‘rule’. To ensure the best possible communication with business people, use of ‘rule’ should remain consistent with the real-world understanding of ‘rule’. Say ‘rule’ to business people and they will naturally think “guide for conduct or action” or “criteria for making judgments or business decisions.” If a business person says ‘rule’ he/she almost certainly means a rule for the business (e.g., no shirt, no service), not ‘requirement for a software system’. Many ‘requirements’ never become rules. The “no shirt, no service” rule doesn’t happen to be automatable (at least easily). Many other rules of the business are – e.g., no credit card, no sale. When interpreted into an implementation form, the business rules ideally should still be recognizable as a form of rule. The same cannot be said, however, for other aspects of a business model, say processes. In designing a business process for implementation, why would you ever say, “Now it represents rules.”?! Rules are rules, processes are processes, locations are locations, people are people. Each can be cast into some design-level counterpart (e.g., GUIs can substitute for face-to-face communication between people.) Nonetheless, each retains some sense or reflection of what it was originally (or should anyway). Looking at operational business design any other way inevitably leads to a break-down in communication and needless complexity.  Avoid confusing business people or IT professionals – or yourself – by calling requirements ‘rules’. Requirements are not rules! But Are Business Rules ‘Requirements’?? Clearly, requirements are not rules. What about the reverse question? Can it be helpful to think of business rules as requirements? To answer it’s essential to keep in mind what business rules are about. In plain English, business rules are about guiding and shaping day-to-day operations of the business. Business people would need business rules to operate the business even if there were no systems. The business rules just are what they are. And if well-specified, they essentially speak for themselves. All the following, though, are certainly true about business rules:
  • They should arise from, or at least be approved by, business people.  
  • They should be considered very carefully in designing a system.  
  • They should be automated whenever possible.
All said and done, whether business rules are a form of requirement is really a judgment call. The best answer is whichever is likely to prove most productive for your work.

Continue Reading 4 Comments

When is a Door Not a Door? … The Basic Ideas of Business Rules

One of the interesting things about consulting with different organizations on business rules and publishing a Journal on that subject (the Business Rules Journal on BRCommunity.com) is that a lot of really silly rules cross my desk. Sometimes it feels like a Dilbert parade! We’ve even started a LinkedIn group about them – Rules Say Must Not.  A colleague recently forwarded a rule that raises some interesting questions. He observes that in his apartment building the doors to the stairwells all have signs on them saying, Door must be kept closed at all times. His question was, “Is a door you must never open really a door?” If the rule is followed religiously, he observed, the door might as well be considered part of the wall. Well obviously not quite! Before addressing that tongue-in-cheek question, let’s do some analysis of this rule. I think we can safely assume that the rule as stated is actually a shorthand. A more complete and accurate version might be, You may use this door for entry, but it must be closed behind you. If we wanted to be very complete, we might explain the basic motivation for the rule by adding, Fire Door. Further analysis of this simple rule reveals the basic ideas of business rules: 
  • The rule was posted; that is, written down. Why? The answer lies in the motivation for the rule – its purpose is to protect the inhabitants against the dangers of fire. When a rule becomes important enough, it is always written down.
  • The rule was written in plain English. If the rule were difficult to understand, or encoded in such way that many of the inhabitants could not readily interpret it, it would not serve its purpose very well. A rule important enough to write down is worth writing down plainly.
  • A process or procedure for this situation is not really needed. We could write one, of course, but in this case, it would probably be trivial (approach door; grasp doorknob with hand; twist doorknob is clockwise direction; pull/push carefully …). Nonetheless, the rule is still crucial. Rules can exist independent of processes.
  • This rule – like all rules – serves to shape behavior. The posting of the rule reminds inhabitants, staff and others to close the door, and presumably they are therefore less likely to forget, or perhaps even block the door open. The purpose of a rule is always to guide or influence behavior in desired ways.
  • The rule serves a purpose – it is neither frivolous nor arbitrary. Fire is a deadly risk, and all reasonable measures must be taken to protect against it. Business rules never arise in a vacuum; there are always by identifiable and important business factors motivating them.
  • The rule was posted right where the action is – that is, where actual entry can occur. This proximity to the action helps ensure the rule is followed as events actually unfold. The best way to ensure rules are followed is to get them right in front of people at the exact point where the guidance is relevant.
  • The rule is undoubtedly part of a larger body of fire code rules for buildings. Even though the rule may be posted thousands of times for enforcement purposes, these postings arise from a single source. This ensures consistency. If rules are important enough to be enforced, they are important enough to be single-sourced.  
  • The body of fire-code regulations was undoubtedly produced by experts experienced in the field, and is backed by the political authority of the city or state. Changes must be reviewed, incorporated, and disseminated carefully. Because new dangers and liabilities can be discovered at any time, this process should be streamlined and efficient. In other words, the rules must be managed.
These commonsense observations represent the basic ideas of business rules. Your business has many hundreds or thousands of such rules guiding its operational business activity. Yet in practice, these basic business rule principles are seldom followed. Can you do anything about it? Yes! The business rules approach offers proven solutions. Now back to that question, “Is a door you must never open really a door?” The answer is obvious – yes, of course it is. A wall without a door will always just be a wall. If you need a door sometime in the future, you must remodel, and that means time and money (not to mention disruption for the inhabitants). If you have ever remodeled your home, you know exactly what I mean. The wall with a door acts like a wall until such time that the must-remain-closed rule is discontinued. Then, with relatively little delay, expense or disruption, it becomes a functional door. Think of business rules as a relatively inexpensive way to build potential doors for your business in all those many cases they might one day be needed. That way you can avoid walling yourself in. In a world of constant and accelerating change, business agility is the name of the game!

Continue Reading 2 Comments

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

Where are Your Business Rules … In a Big-P Process Dead Zone?

On an EA LinkedIn group last week, Nick Malik wrote the following about business rules in Zachman Framework 3.0: I’ll bite. If the ‘enterprise ontology’ is similar to the periodic table of elements, then business rules are molecules. They are compositions of elements with specific implications, embedded in event handling logic. Why would you expect to see them, or models of them, on the Zachman Framework? OK… that was my humble, and perhaps uninformed, opinion. You are the master of business rules. You tell me where you’d see them.” Nick, You know the definition of ‘master’, right? Same as ‘expert’ … someone who has made all the known mistakes. Zachman and I have had over-dinner conversations for many years about the question of where business rules fit (or don’t) in the Framework, even more so in the past couple of years. I won’t speak for John, but I think he agrees. Yes, business rules are ‘molecules’ and yes, they are ‘composites’. So you don’t see business rules anywhere in Framework 3.0. Instead, if you look at the new cross-column thin gray lines, at row 2 in particular, some or many of those could be business rules. Aside: For convenience, here’s a zipped pdf of the new 3.0 version (with permission): ZF3.0.zip [approx 1.5M]. Visit Zachman’s new website for all the latest. The thing about molecules or composites – unlike the primitives – is that they can be conceived in many different ways. Each conceptualization leads you to a different representation approach, and each representation approach leads you ultimately to a particular implementation strategy. Some implementation strategies, of course, are better than others (by a mile!). Moving Beyond the Big-P Approach At the risk of over-simplification, you have two basic choices for conceptualization, and ultimately implementation, of composites: procedural or declarative. Historically, we have embedded business rules in process models and in procedural code. We have taken the column 2 (how) primitive, process, and used it to create composites. At the scale of today’s business, this Big-P process paradigm simply doesn’t work. Why? The thin gray lines in Zachman 3.0 are really about how the business is configured for operation. (At row 6 the thin gray lines represent the current actual configuration of the operational business.) In the Big-P paradigm, all building-block ‘molecules’ become thoroughly entangled with flow (input-transform-output). The result is essentially a semantic dead zone. You’re never sure what things really mean, and you can’t easily disentangle them. There are no built-in impediments to replication … and no opportunity to use logic to automatically evaluate configurations (models/designs) for conflicts, anomalies and other logical defects. Aside: The Big-P approach also has implications for data models. In current practices, there is no way to automatically perform any meaningful verification of data models either. The future lies with granular, declarative, semantically-rich specification of building-block composites (‘molecules’) for configuration. I know I used the ‘S’ word there (‘semantics’) but I’m simply talking about structured business vocabularies (SBVR-style fact models). Fact models, by the way, must cover anything with a name, including instances from columns 2-6, so they too are composite rather than primitive. Aside: Was I happy to see John use the ‘O’ word (‘ontology’) in 3.0? I think I know why he did it – to emphasize the Framework is not a simple taxonomy, but rather something rigorous enough to potentially reason over. I’ll let others judge that choice. Re-factoring the Big-P Paradigm Clearly, business rules are one building-block composite for disentangled forms of enterprise configuration. Another thing not considered a primitive – Nick mentioned them – are events. They too possess the granular, configurable potential of business rules. And yes Nick is right – events and business rules have a very close relationship, one not widely appreciated. (If the industry did, it would already be taking a very different approach to process modeling.) Aside: But no, Nick, I would not ’embed’ business rules in ‘event handling logic’ … no more than I would embed ‘event handling’ in business rules. Unfortunately, expert systems do allow you to do that. What else do we need as building-block composites to configure an enterprise at a given point in time? Let me propose decisions – but with caution. ‘Decision” is the buzzword de jeure. No, decisions are not a cure-all, no they do not replace business rules or events, and no they do not solve all our problems. But in proper perspective, yes, they are most definitely a building-block composite. Smart Configuration Models Big-P configuration of the enterprise is like setting it in concrete. To replace that flagging paradigm we need smart configuration models. Such models will feature at least: (a) business rules, (b) business events, and (c) operational business decisions. And of course, structured business vocabularies (fact models). Smart configuration models should be the new mantra for enterprise architecture. In a world of constant and accelerating change, I see no alternative. By pinning down the primitives definitively in 3.0, Zachman has opened the door to a whole new realm of rich architectural potential. But there’s more. Smart configuration schemes must address additional challenges facing business today. These include 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 coming out the end of September, we call systems built using smart configuration schemes business operation systems (BOS), as opposed to ‘information systems’. I think you’ll find these new ideas quite exciting. Watch for them!

Continue Reading 2 Comments

Are BPM and EA a Perfect Match? … With Business Rules Far Better!

@SergeThorn asks “Are Business Process Management and Business Architecture a perfect match?” http://goo.gl/kLYvs With business rules far better! There is an important overlap of concerns between business rules and enterprise architecture. The overlap actually comes in two forms: 1. Operation-time. Here the issue is really rethinking compliance. I just blogged about this today: http://goo.gl/Gl9wT 2. Business-analysis-time. A business needs to know the rules it plays by. That inevitably brings you to rulebook management. For more: http://www.brcommunity.com/b500.php?zoom_highlight=rulebook (and other articles).

Continue Reading

Audit Trails and Tracing the Impact of Operational Errors … It’s Ultimately about Compliance and Business Rules

Robin Bloor wrote  a very interesting piece about why business needs explicit audit trails for data: http://www.dataintegrationblog.com/robin-bloor/the-quality-of-data-is-not-strained/ Here’s the gist: “… data has no explicit audit trails, so we lose information, some of which may be critical. This has the effect of hiding the record of and the impact of data errors.” He says all data should be time-stamped. I agree … but it’s not enough. I’ve believed for decades (before it was conceivably practical) in the concept of the ‘perfect machine’. In the perfect machine, there are really no such things as changes or deletes; instead, all data just get time-stamped when created and the newer data takes active preference over the older. That gives you built-in audit trails — of data — and more importantly, (mechanized) business memory.  There is, however, at least one circumstance in which data really does need to be deleted (purged). That’s when the business is required for legal reasons to expunge all ‘records’ about some sensitive matter (e.g., the legal transgressions of a minor at age 18). In other words, there are *business rules* that sometimes require true ‘deletes’. Business rules can trump ‘perfect memory’.  Actually, there are business rules for virtually all ‘changes’ made to operational data. Failure to apply the correct business rules consistently is the rrot cause of poor data quality. And good luck trying to reconstruct after-the-fact what really happened (what business rules were actually applied) at some past point in time when things downstream go awry. And they will, of course.  What’s needed is not just an audit trail of changes to data, but an audit trail of all business rules tested at each point in time some data ‘changed’ (or was created or deleted). If the system automatically logs the relevant business rules, then you have a true, complete and indisputable record of ‘history’.  I’m talking here about nonething less here than built-in (mechanized) methods of addressing compliance. No human intervention. Compliance across the board … with external regulations, contracts, agreements, deals, business policies … whatever.  If you want your business to be both extremely agile and highly compliant (which is to say, always meet operational expectations), there’s untimately no alternative. How else can you support one-on-one customized relationships with a million customers? Of course, first you would have to know your business rules. There’s the rub. Do you?! 

Continue Reading

Business Rules & Events: Two Questions for Zachman re: 3.0

The next time I have dinner with John, I have two questions for him. (He knows I always have new questions for him every time I see him, so he’s more or less prepared for it after all these years.) If anyone talks to him sooner, be sure to ask John these two questions … and please post the answers(!). 1. Where are business rules? (I think I know what he’ll say about this one.) 2. Why did events disappear in this rendition of the Framework? (I don’t know the answer to this one, and though subtle, it may prove to have the most important implications of any adjustment he’s made this time around.)

Continue Reading 2 Comments

To: Business Process Manifesto … From: Business Rules Manifesto … Re: How Business Processes and Business Rules Relate

When the Business Rules Manifesto was published in 2003 (http://www.businessrulesgroup.org/brmanifesto.htm), I co-proposed the six items below related to business processes as an additional (eleventh) Article. The Business Rules Group (BRG) decided (probably wisely) to avoid that potentially controversial area, however, and concentrate on the core message of business rules. Since a Business Process Manifesto has been in the works, it’s worth going back over the proposed items. I believe they remain valid. So I dug them out of my Editor archives, cleaned them up a bit, and presented them below. Aside: In 2003 the BRG wasn’t careful about saying “business rule” (instead of just “rule”) and business process (instead of just “process”). But that’s what we meant – real-world rule and real-world process – not technical specifications. I’m very careful about that clarification these days. A great many people have a hard time seeing the difference. Item 1. Business rules guide business processes.

Comment: If this one is not self-evident, all bets are off.

Item 2. Business rules should be substituted for any activity in a business process where the result(s) of that activity can be produced by the business rules.

Comment: This item refers to what SBVR calls definitional rules – business rules that can derive, classify or compute something. For any given ‘something’, there might be only a single business rule, or a very large number of business rules. The ‘something’ could be an operational business decision requiring many dozens or hundreds of decision rules organized into decision tables.

One thing the item doesn’t say is that not all such ‘somethings’ need to be supported by business rules from the very beginning. In fact as Item 8.5 says, they don’t need to be. Business rules are very good for incremental development. (Development of what? Smart business processes.)

Item 3. Business rules can cause business processes to be initiated under appropriate circumstances.

Comment: Circumstances can arise that require the business to respond in a pre-scripted manner – e.g., low inventory status, potential fraud or intrusion, etc. Some business rule(s) should identify the circumstances involved in such ‘spontaneous’ business events.

Item 4. The default explanation or message for any error that occurs in a business process for a business reason is a business rule.

Comment: This item is truly ground-breaking. Business rules express the do’s and ‘don’ts’ of business activity; therefore, any error that occurs under a business process for a business reason is ‘explained’ by a business rule. What else could it be?!

Keeping systems carefully aside, and noting the obvious possibility of providing additional or alternative ‘explanations’, I like to say ‘the business rules are the error messages’. By the way, I’ve been saying that since 1994 – I have the slides (transparencies actually) to prove it. If you have doubts about this item, please provide examples(!).

Item 5. Any delay in the ability to enforce a business rule must be coordinated with business processes.

Comment: In SBVR, behavioral rules are business rules that can be violated. (Definitional rules can’t be.) An example where such delay might occur is a business rule that requires an approval or sign-off on something (e.g., an extra-large order on credit) by somebody (e.g., the branch manager) who is not immediately available. The business process for that particular something must be suspended until some future time.

Note: Additional business rule(s) providing appropriate suspense criteria (e.g., 24 hours) would be wise in such cases. We don’t want an order sitting in limbo forever(!).

Item 6. Business rules cannot constrain the workings of a business process directly, but only the following: (a) the state required for the business process to be performed; (b) the state while the business process is being performed; and (c) the results – that is, the state – the business process seeks to leave behind when finished.

Comment: I think of a business process as being like a black box with respect to business rules. The business rules cannot and should not ‘look’ inside. Instead, all matters of state should be externalized so business rules – and business people – can know it and talk about it. Get ready for this: This item indicts BPMN with its token-based approach to process state. The future lies with externalizing semantics. Sorry guys!

Continue Reading 24 Comments