‘Silo’ is so common as an industry buzzword we mostly just take it for granted. The usual sense is ‘functional’ silo or ‘organizational silo’. I recently heard ‘no man stands alone’ (‘alone’ = ‘silo-ed’) as a common-sense justification for Big-P process. (See http://goo.gl/Cuk3s) That logic is simply flawed. Here are other ways your business can be fundamentally ‘silo-ed’.

• You can stand alone (silo-ed) in your strategy – goals not aligned, tactics not aligned, policies not aligned.
• You can stand alone (silo-ed) in your timing – events, intervals and schedules not coordinated.
• You can stand alone (silo-ed) in your logistics – locations isolated, connections and transport linkages not optimized.
• You can stand alone (silo-ed) in your language – different vocabularies and meanings, producing semantic silos (a.k.a. a Tower of Babel).

And of course, you can stand alone (silo-ed) in your business rules. Any one of these ‘silo-ings’ can be worse than ‘functional’ or ‘organizational’ ones. My bias, of course, is toward language (nothing gets done effectively in a Tower of Babel) and strategy (if you’re storming the beaches, you’d better hope the generals already got it together strategy-wise). But that’s not the point. If an approach doesn’t evenly addresses all the ‘silo-ings’, it’s trouble. As we say in our new book (http://www.brsolutions.com/b_building_business_solutions.php) you need a well-factored approach. (And of course, John Zachman has been saying that for 25+ years.) The Big-P process view steers you in a harmfully simplistic direction … and probably right into the waiting arms of some eager consultancy or services provider.

For IT professionals the state of processes has always reigned supreme. In procedural approaches the internal state of a process is represented by some token. Most computer languages use that approach (the token generally falls through lines of code sequentially). Many current approaches to business process modeling do as well, at least implicitly. But why should business people care about the internal state of any process? For example, if a business person asks How far along are we in processing this order? the person is really asking: Has the order been credit-checked? Has it been filled? Has it been shipped? (etc.). In business operations it’s the state of each operational business thing that matters. True business agility cannot be achieved so long as business processes are perceived as managing state internally (privately). That’s a fundamentally flawed paradigm for business operation today. Instead, business processes must externalize semantics so business people can understand and manage the state of operational business things directly. Externalizing semantics is accomplished by means of SBVR-style structured business vocabularies (concept models) and single-sourced business rules. ~~~~~~~~~~~~~~~~~~~~~~~~~~ This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php  

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!

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

A practitioner recently commented: “Everyone has their biased view of what a data model is. Data modeling is art – not science. Give 6 data modelers one set of requirements and you’ll get 7 solutions all distinctively different.” My response: To me that’s a huge problem. No, ‘data’ modeling is not a science, but nor should it be an art. Actually, it should be engineering. Engineered solutions have to stand up to rigorous tests. But we lack that in ‘data’ modeling. Why? Because ‘data’ modeling is divorced from its initial business context, which is operational business communication, including business rules. You need nouns and verbs for that, and those nouns and verbs should stand for well-structured concepts. Give me a model of well-structured concepts that has been ‘proven’ by verbalizing business rules and other formal business communications and I guarantee I can come up with the best data model. I’m talking of course about concept models (sometimes called fact models).

As part of a continuing dialog, I recently asked these questions: What does the term “conceptual data model” really mean? Is it the best term for what is meant? To me, it sounds like “conceptual data model” might be about “conceptual data”. Surely not(?). What exactly then? (Some of my thoughts on the matter: http://goo.gl/8GX5o.) A practitioner responded with the following 3-part challenge below. With each challenge is my response. Challenge part 1: Which of the following, if any, would you see in a conceptual data model: primary keys, foreign keys, abstract keys, constraints, nulls, non-nulls, 1:1s, 1:Ms, optionality, cardinality, etc.? My response: Wrong approach. Bad definition practice one three counts. 1. Things should be defined in terms of their essence, what they are, not in terms of what are allowed or disallowed. 2. Suppose none of the above were allowed. You’d end up simply with a description of what the thing is not, not what it is. Since you can’t possibly list everything it’s not, the definition is woefully incomplete. 3. The list attempts to describe something in terms of an implementation or design of the thing, not in the thing’s own terms. That’s simply backwards. Challenge part 2: So let’s turn the question around. What would be the minimum types of objects you need to explore a concept, produce a mini model, and convey knowledge about the concept and its relationship to other concepts? My response: To develop a concept you need: 1. A concise definition for the concept, which distinguishes the concept from all other concepts and conveys its essence to the business. 2. A business-friendly signifier (term) for the concept that has only that one meaning (or is properly disambiguated by context). 3. A set of facts that indicates the place of the concept within a structure of other concepts (e.g., classification, categorization). 4. A set of verbs that permits the business to communicate unambiguously about how the concept relates to other concepts (e.g., customer places order). 5. A set of structural rules for the concept and its relations to other concepts, as needed. Why the verbs? Because you can’t write sentences without verbs and business rules can always be written in sentences. ‘Requirements’ should be too(!). Challenge part 3: When you are finished do you call that a ‘conceptual data model’? My response: You notice that I didn’t say anything, directly or indirectly, about “data”. That term is irrelevant. Taking away “data” leaves “conceptual model”. But that term suggests what the model is made of (concepts), not what it is about. Of course the kind of model we’re talking about is made up of concepts – it’s certainly not made of physical material (e.g., wood, plaster, etc.) or through use of math (some formula). That leaves “concept model” (also sometimes called “fact model”). Bingo. Is there a standard for this kind of model? Indeed there is: SBVR (Semantics of Business Vocabulary and Business Rules). See the SBVR Insider section on www.BRCommunity.com for more information.

Business Process Models: A completed transform often achieves a business milestone and a new state for some operational business thing(s). Example: claimant notified. Fact Models: In fact models (structured business vocabularies) such states are represented by fact types, for example, claimant is notified (or claimant has been notified if you prefer). A fact model literally represents what things the business can know (remember) about completed transforms and other operational business events. Business Rules: Business rules indicate which states are allowed or required. They should not reference business processes or business tasks by name, just the states they try to achieve. For example, a business rule might be: A claimant may be notified that a claim has been denied only if the specific reason(s) for denial have been determined.  ~~~~~~~~~~~~~~~~~~~~~~~~~~  This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php  

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

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

 

I’m an avid fan of soccer … and, of course, business rules. I recently found the following business rule via a Twitter search and just had to ask what it meant. FootballRascal – Can’t sign a player and then loan him out to another Premier League club in same window, business rule as fee charged Ronald_G_Ross – For U.S. audience, but avid football fans, what is motivation for not-in-same-window business rule? MeJonWhite – Personally, I have no idea, can’t see the logic. He could go on loan internationally, but not domestically. Ronald_G_Ross – Just one more ques. re not-in-same-window business rule. Uh, what’s a window? Period of time? Season? MeJonWhite – Summer window is July 1st – Sept 1st, it’s just the off season registration period. January is the Jan window. I am still in the dark, but I didn’t want to bug the kind folks any more. What I need is a blueprint to the concepts, a fact model, to bootstrap my way into a meaningful conversation quickly.