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

Where Rules Fit in the Zachman Framework … Conspicuous in Their Absence?

Celebrating the 10th Anniversary of the Business Rules Manifesto[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #8 Question: Why aren’t rules found in any of the cells of the latest Zachman Framework? The Manifesto says clearly (principle 1.1) that rules should be considered a first-class citizen of the requirements world. Yet rules cannot be found in any of the cells of the latest Zachman Framework. Contradiction? No. For an artifact to appear in a cell of the Framework it must represent a primitive. An artifact that references multiple primitives is considered a composite Rules are intrinsically composite. Even atomic rules can address multiple primitives. (Atomic means “can’t be reduced into two or more rules without losing meaning.”) An example: An accounting must be given by the CFO in Delaware on March 15, 2015. This rule refers to a thing (‘accounting’), a person (the CFO), a place (Delaware), and a date (March 15, 2012). Simply because an artifact is composite, however, doesn’t necessarily make it unimportant. Consider what Zachman calls integration relationships – the connections tying the six primitives together. Integration relationships serve to configure the enterprise at any given point in time. No integration relationships, no enterprise. To illustrate, Zachman frequently rolls the Framework into a cylinder and looks through it like a telescope. The primitives must be tied together through that empty cylinder by integration relationships. What can serve in that role? Traditionally, integration relationships have been implemented by procedural means – hardcoded into application programs. Unfortunately, that’s like setting the business in concrete. It also plays havoc with process as the simple, straightforward primitive it should really be. A much better alternative is rules. Rules, by comparison, are far easier to change. So consider rules as the first-class candidate to achieve configuration agility for the enterprise  


[1] The Manifesto is free, only 2 pages long, translated into 15 languages. Have a quick look (or re-look!). No sign up required. Well worth your time.

Continue Reading

Understanding Strategy as a Key Business Analysis Tool: It’s Not Business Process!

John Matthias recently wrote this about our new book, Building Business Solutions: Business Analysis with Business Rules[1]:

“I especially liked the discussion about the mission and goals. I still see business process analysis in organizations I visit where the goals are not articulated well, and the results are not useful. (I’ve done it myself.) It’s easy to get lost among the trees, unaware of the contours of the forest or what direction you’re going.”

Indeed! That’s why we came up with the Policy Charter, which is the deliverable in our approach that lays out the elements of strategy and their motivation.  A Policy Charter is all about business goals, business risks, and business policies. It’s not about business process! [2] How do you distinguish between good business strategy and bad business strategy? Noted strategy expert Richard Rumelt distinguishes the good and bad as follows.[3] Good Business Strategy Rumelt, p. 20: “good strategy requires leaders who are willing and able to say no to a wide variety of actions and interests.  Strategy is at least as much about what an organization does not do as it is about what it does.” Rumelt, p. 243: “good strategy is, in the end, a hypothesis about what will work.  Not a wild theory, but an educated judgment.  And there isn’t anyone more educated about your [business] than the group in [the] room.”  Bad Business Strategy Rumelt, p. 32: Bad strategy “… is not simply the absence of good strategy.  It grows out of specific misconceptions and leadership dysfunctions.  To detect a bad strategy, look for …
  • Failure to face the challenge. When you cannot define the challenge, you cannot evaluate a strategy or improve it.
  • Mistaking goals for strategy.  Many bad strategies are just statements of desire rather than plans for overcoming obstacles.”
Rumelt, p. 32: Bad strategy “… is long on goals and short on policy or action. …  It uses high-sounding words and phrases to hide [its] failings.”  He means (and says) fluff. The Three Skills of Good Business Strategy What do you need to be successful with strategy? Rumelt (p. 268) says: “… you must cultivate three essential skills or habits.
  • First, you must have a variety of tools for fighting your own myopia and for guiding you own attention.
  • Second, you must develop the ability to question your own judgment.  If your reasoning cannot withstand a vigorous attack, your strategy cannot be expected to stand in the face of real competition.
  • Third, you must cultivate the habit of making and recording judgments so that you can improve.”
Good stuff!


[2] The standard for organizing business strategy is provided by the Business Motivation Model (BMM). See www.BusinessRulesGroup.org
[3] Rumelt, Richard [2011].  Good Strategy Bad Strategy:  The Difference and Why It Matters.  New York, NY:  Crown Publishing, a division of Random House Inc.

Continue Reading 1 Comment

Business Agility vs. Agile in Software Development: Not Related!

Business agility results when the IT aspect of change in business policies and business rules disappears into the plumbing.  All artificial (IT-based) production-freeze dates for deployment disappear and the software release cycle becomes irrelevant.  The only constraint is how long it takes business leads and Business Analysts to think through the change as thoroughly as they feel they need to. We define business agility as follows: being able to deploy change in business policies and business rules into day-to-day business activity as fast as business people and Business Analysts can determine the full business impact of the change and assess whether the change makes good business sense Agile in software development is an IT development method featuring rapid iteration and prototyping.  Agile methods and business agility have nothing to do with each other.  Agile in software development leaves off exactly where business agility picks up – at deployment. In working with clients we frequently come across systems that feature a very ‘open’ environment with few enterprise controls.  Typically, this ‘flexibility’ resulted from diligent efforts by IT to satisfy many stakeholders individually.  But the ‘flexibility’ is just an illusion.  The failure of business-side stakeholders to come together and develop a collective business solution before ‘agile’ software development commences can plague the company for years to come.  It reduces overall productivity, lowers customer satisfaction, and diminishes the capacity to make sound operational business decisions.  It makes apple-to-apple financial comparisons virtually impossible.  And it always costs a lot in ‘maintenance’.  There are simply no magic bullets for building business solutions! ~~~~~~~~~~~~~~~ Excerpted 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  

Continue Reading 1 Comment

How Business Processes and Behavioral Rules Relate: The Fundamental Insight of Business Rules

In football, when a referee throws a flag, the results of the most recent transform (play) are undone. In effect, by enforcing a rule, the referee prevents or negates the new state (yardline and sometimes the down) and enforces some other state. That’s the way behavioral business rules[1] work. Speed through a school zone and see if your desired state isn’t modified if some policeman happens to be watching. The relationship between behavioral rules and business processes is an indirect one, through state. Business tasks try to produce new states; behavioral rules step in to modify or prevent the new state if a violation occurs … just like the policeman parked in the school zone with a radar gun. More precisely, business tasks precipitate events that try to change state (the outputs, final or interim), and behavioral rules ‘watch’ for the particular events that produce violations. A violation produces a response, which can be another process – e.g., the referee jumping in to whistle the play dead or the policeman putting down his doughnut and chasing you. Yes, it’s important know which business tasks can violate which behavioral rules, but their relationship more complexly networked than you might think. In general, every behavioral rule expressed declaratively can be analyzed to produce two or more events (I call them flash points) where it can be violated and needs to be evaluated. I can provide endless examples. (Refer to http://www.brcommunity.com/b623.php?zoom_highlight=flash+point or to Chapter 8 of Business Rule Concepts, 3rd ed.) These events are likely to be in different business processes (or procedures or use cases) … and sometimes a given process may not have been modeled at all (or the event occurs ‘spontaneously’). The fact that each behavioral business rule can be violated at two or more flash points is a fundamental insight of the business rule approach. It’s precisely where current platforms, tools and methodologies fall short, and why consistency and compliance are so difficult to achieve. In other words, it’s an essential idea in really ‘getting’ business rules.


[1] In SBVR, there are two kinds of business rules; the second kind is definitional rules. As their name suggests, definitional business rules shape concepts and provide criteria for making decisions.

Continue Reading

What Should Business Stakeholders and Business Analysts See (and Not See!) in a Business Process Model?

I was recently asked the question above. It’s a good one. It arose in response to another post, “What is the best way to simplify business process models?”. See http://goo.gl/gWnO0 for a very brief, very dramatic case study. Here’s my answer. Business people (and business analysts) should see only the core set of transforms (business tasks) that respond to some business event, and that lead transform-by-transform to appropriate business end-results through conditional flows. Many process modellers also try to include the criteria that resolve those conditional flows, which in a true business process model, are always business rules. The result is embedding the business rules procedurally within the model, rather than expressing them declaratively (and separately) in their natural form. The more scenarios the model covers, the more hopelessly complex it becomes. The issue has nothing to do with conventions per say, or with the media of presentation – electronic, paper or otherwise. I’m talking about the core stuff of the model itself. Just transforms, transforms, transforms!

Continue Reading

Want to Make Your Business Process Models Less Complex and More Approachable? There’s a Proven Solution!

The best way to simplify business process models is to take the business rules out and address them separately. Example: For a large pharmaceutical client, we reduced a complex 28pp model to just under 4 pages by doing that – nearly an order-of-magnitude reduction in size (and probably even more in terms of complexity). Everyone loved the results. There was nothing unusual or atypical about the result – we’ve seen it happen many, many times. By the way: If you know of similar cases, I’d love to hear about them!

Continue Reading 2 Comments

‘Concept Model’ vs. ‘Fact Model’ … Where in the World are the Instances?

In a dramatic development, the new release of SBVR (1.1) has replaced the term “fact type” with “verb concept”, and the term “fact model” with “concept model”, for all business-facing use.[1] Why the problems with “fact type” and “fact model”? Let me see if I can explain. First some background: Since its inception in the early 2000s, the OMG standard SBVR[2] has focused on “fact type” and “fact model”. That’s no accident – the underpinning of SBVR in formal logic is based on the work of Terry Halpin, who in turn based his work on Sjir Nijssen’s. Sjir Nijssen was using the terms for database models as early as the 1970s. By the way, both bodies of work are world-class. Now to the problems: If someone gives you an example or instance of a customer, where is that customer? In a database? No, of course not. The customer is out there in the real world. Similarly, suppose someone gives you an example of some customer visiting some retail store. Where did that visitation take place? In a database? Again, of course not. The visitation also happened out there in the real world. The bottom line is that when most people talk about things, those things exist or happen in the real world. But not if those people happen to be logicians or database gurus. Then instances of the things they talk about formally are likely to be in some database – i.e., data. The formal terminology is usually more refined – e.g., “population of facts” – but it is what it is. And it’s not the same stuff as is in the real world. Where does that lead you? If you’re a logician or database guru, you need to classify all the facts – hence “fact type”. You also need a model of all the fact types – hence “fact model”. If you’re not a logician or database guru, however, you’re clearly going to need something else. What exactly fits the bill? Here’s a clue: Databases hold data; those data represents facts. Those facts have meaning, but to understand that meaning you need to understand the concepts that are used. In business basically all we have is words to refer to things in the real world. What do those words communicate? The words communicate what you mean; that is, the ideas or concepts you have in your head when you say or write them. So what we need – or more precisely, what we need to share – is a model of what you mean by those words. In short we need a concept model. More on SBVR The world might or might not need another information modeling standard. The point is debatable. The soul of SBVR, however, lies in meaning[3] and language – what concepts we mean by the words we use in business communications (especially but not exclusively business rules). In the standards landscape that focus sets SBVR apart. What kind of language concepts do we need in organizing and expressing meaning? The answer is really quite simple (once you see it) – you need nouns and verbs. Those nouns and verbs stand for concepts – noun concepts and verb concepts, respectively. For example:
  • The noun “customer” might stand for what is meant by the definition “one that purchases some commodity or service”. 
  • The verb “visits” (as in “some customer visits a retail outlet”) might stand for what is meant by the definition “customer physically appears at retail outlet”
There is no other practical way to communicate business concepts and establish relationships among them. You need nouns and verbs to write sentences and convey meaning – it’s as simple as that. Once you look at the problem this way, forcing “fact model” and “fact type” on business people is unnatural and unnecessary. It commits a cardinal sin in business analysis – using unnatural terms for natural business concepts. The most natural terms for the concepts meant by SBVR are “concept model” and “verb concept”. About Business Rules For my part, I didn’t arrive at this understanding through the path above – or for that matter any other path you are likely to guess. The need for the shift dawned on me when I saw business rules being included in populations of facts. Hold on, how could a rule be treated as a fact?! Well, exactly! To a logician or database guru, however, treating a rule as a fact makes perfect sense. Formal logic is all about propositions. A business rule is a proposition taken to be true – in other words, a fact. So of course business rules belong in populations of facts and therefore in fact models. It couldn’t be any other way. And I agree. The only problem is that in SBVR we want to talk directly about the real world. The Bottom Line So a concept model in SBVR is a ‘map’ of noun concepts and their relationships based largely on verb concepts.[4] Actually, it’s more than that. By ‘map’ I don’t mean either of the following on its own:
  • A set of concepts and definitions loosely related (e.g., a glossary) – although definitions are clearly essential. 
  • Some diagram(s) – although often quite useful.
Rather, I mean a non-redundant, integrated, anomaly-free structure of concepts based on interlocking definitions – a blueprint of meanings. How is an SBVR-style concept model different from (and better than) a traditional “conceptual data model” (or entity-relationship diagram)? Instead of mere lines to represent relationships between noun concepts, with an SBVR-style concept model we have verbs. These verbs reveal the intended meanings of the relationships. With verbs I can verbalize – literally communicate (and demonstrate) what is meant. No more hidden meaning!


[1] But not in the underpinning of SBVR in formal logic.
[2] Semantics of Business Vocabulary and Business Rules. See the SBVR Insider section of www.BRCommunity.com for discussion. SBVR 1.0 was released by OMG in December, 2007.
[3] I refuse to use the “S” word here. There’s really no need for it. Few business people I’ve ever met say “semantics” in the course of normal business conversation, except perhaps in the sense of “Oh, that’s just a matter of semantics.” (which indeed, to be fair, it usually is).
[4] I say “largely” because certain important structural elements of concept models, including classifications and categorizations, are not based on verb concepts.

Continue Reading 3 Comments

How Important is Basic Business Vocabulary? … A Short (True!) Story

Guest Post I was teaching a BA class, trying to convey the value of having a prototype. The class was divided into ‘developers’, the BA, and the ‘executive’. The developers were given a bag of duplos, multiple shapes and colors. The executive was given a bag with a completed duplo creation. The instructions were for the BA to elicit information from the executive and provide it to the developers so they could build the creation. What I discovered is that they needed a common language (terms everyone knew the meaning of), and a frame of reference (location, name of layers or identity of corners, etc.). Without this information, communication was impossible.  After they created these ‘handles’, they were able to communicate and convey information. The value of having a prototype was demonstrated.  The value of common terms and clear understanding was priceless! ~~~~~~~~~~~~~ Acks: Thea Rasins Consultant, Educator and Professional Organizer KCIIBA Board Member and Vice President of Professional Development

Continue Reading 1 Comment

The ‘Process’ of Business Analysis is a Great Example of a Social Process

In a recent post, Jonathan ‘Kupe’ Kupersmith said:

“In manufacturing following a process step by step is a good thing. In our world [business analysis] this is not the case.  Following an A to Z process for every project is a bad thing.  Every project is different.  Different people, different risks, different priorities, etc.  You need to adapt your process to meet the needs of the project.”.

I believe what Kupe is saying is that the ‘business analysis process’ is not a traditional straight-line process (like old-style manufacturing). Instead, it is what is currently being called (variously) a ‘social process’ or ‘dynamic process’ or ‘case-based process’. Such a process is:
  • Social in that interactions at various times with various people with various kinds of know-how must be orchestrated for optimal results.  
  • Dynamic in that the ‘flow’ is highly situation-based rather than predictably straight-through (static).  
  • Case-Based in that the ‘flow’ of events is based on the particular characteristics of the case (project) at hand, rather on forced conformance with some ideal.
Let me make a couple of observations (which are not points of disagreement with Kupe): 
  • There are many, many companies (even in manufacturing) now beginning to understand that their core business processes should be organized as social/dynamic/case-based rather than traditional/static/straight-line. Customization and personalization of products and services demand it.  
  • Achieving manageable customization and personalization at scale requires an appropriate infrastructure that is business-based.  
  • The need for infrastructure leads inevitably to business vocabulary (business semantics) and business rules. (What’s the alternative??) So business rules are probably even more essential for social/dynamic/case-based processes than traditional/static/straight-line ones.
What do these observations specifically mean for the ‘business analysis process’? I would suggest the following: 
  • Having a standard business vocabulary for the ‘business analysis process’ is key. How many organizations really have one? I see this omission as a huge hole in current BA standards and practices. (Plug: Our new book, Building Business Solutions: Business Analysis with Business Rules, has a 55pp Annotated Glossary. We practice what we preach. http://www.brsolutions.com/b_building_business_solutions.php)  
  • The know-how to support a social/dynamic/case-based ‘business analysis process’ should be expressible as rules. If the know-how can’t be articulated and properly communicated, then how can the process be repeated, learned and scaled? Tacit know-how is simply no longer adequate in a knowledge economy.
~~~~~~~~~~~~~~~  You can find Kupe’s original post on: http://www.batimes.com/kupe-kupersmith/why-business-analysis-processes-are-a-waste-of-time.html

Continue Reading 2 Comments