John Zachman says you can (and probably should) develop each of the following three kinds of artifacts to “excruciating level of detail”.
1. For the business management’s perspective (row 2), a conceptual model (roughly CIM in OMG terms).
2. For the architect’s perspective (row 3), a business logic design (roughly PIM in OMG terms).
3. For the engineer’s perspective (row 4), a class-of-platform design (roughly PSM in OMG terms).
Because each is a different kind of model, there is a transform from one to the next. One implication is that it is possible to make a clear distinction between analysis (CIM) and design (PIM). Another implication is that concept models and logical data models are clearly distinct. Unfortunately, many people blur the line between them. That’s wrong.
A concept model is about the meaning of the words you use, and the business statements you make assuming those meanings. It’s about communication.
A logical data model is about how you organize what you think you know about the world so it can be recorded and logically manipulated in a systematic way.
I started my career in data. It took me as much as 15 years of intense work on business rule statements (1990-2005) to fully appreciate the difference. But now I am very clear that concept models do need to be developed to excruciating level of detail in order to disambiguate the intended business communication. Most businesses don’t do that today. They jump in at data design (conceptual, logical or even physical). And they unknowingly pay a big price for it. By the way, a good concept model can be readily transformed into a first-cut logical data model – just as Zachman says.~~~~~~~~~~~~~~~www.BRSolutions.com
OMG released version 1.3 of SBVR (Semantics of Business Vocabulary and Business Rules) last month – comprehensively reorganized for approachability, but not changed. Some thoughts …
Ever hear the conversation that three baseball umpires once had? If you don’t live in a baseball country, it’s an archetypical story, so you’ve probably heard some variant. By the way, in American English a ‘pitch’ is a throw of the ball for the batter to try to hit, not the field of play. Meanings matter!
The first umpire says, “Some pitches are balls and some are strikes. I call them as they are.”
The second umpire says, “Some pitches are balls and some are strikes. I call them as I see them.”
The third umpire says, “Some pitches are balls and some are strikes. But they aren’t nothing till I call them.”
Most modeling techniques primarily focus on modeling the real world as it ‘really is’. They essentially take a first-umpire point of view or maybe second-umpire. I come from that tradition too. My 1987 book Entity Modeling was about doing that … modeling the real world as it ‘really is’. Pretty much all professionals with some IT background come from that world.
Working with business people and business rules for the last 25 years, however, has taught me that business is really more of a third-umpire world. Think of laws, regulations, statutes, contracts, agreements, terms & conditions, policies, deals, bids, deeds of sale, warranties, prospectuses, citations, complaints, receipts, notices … and business policies.
Even businesses that deal with tangible stuff (e.g., railroads, electrical transmission, infectious diseases, etc.) live in a third-umpire world. And many of the most automated organizations around have no tangible product at all (e.g., finance, insurance, government, etc.). They really exist only in a world of words (between people).
It’s humbling to realize that the way the business world ‘really is’ is more directly the product of words exchanged by the players in a conversation game than anything IT professionals can model directly. But why would it be otherwise? Do IT professionals really know better than business owners, business managers, lawyers, engineers, subject matter experts, etc.? Really?!
SBVR, in contrast to almost all other standards, doesn’t try to model the way the real world ‘really is’. Instead, its focus is on modeling what is said about the way the world really is. It’s fundamentally a third-umpire standard. You simply have to understand what the words mean – and that’s a human-communication issue.
Yes, the SBVR world view is a game changer. It also happens to align closer with some of the most exciting new work in computerization today including cognitive computing and machine learning.
I stand accused by peers in the standardization community of wanting to go beyond the ‘capture, exchange and production of information’. Sure, I can live with that.
The Director of Business Analysis and Process Improvement at a major organization commented:Would you consider PDCA and/or DMAIC to be metaprocesses? My reply: First some background from Wikipedia:
PDCA(Plan–Do–Check–Act or Plan–Do–Check–Adjust) is an iterative four-step management method used in business for the control and continuous improvement of processes and products. It is also known as the:
control circle/cycle, or plan–do–study–act (PDSA).
Another version of this PDCA cycle is OPDCA. The added “O” stands for observation or as some versions say “Grasp the current condition.” This emphasis on observation and current condition has currency with Lean manufacturing / Toyota Production System literature.
DMAIC (Define, Measure, Analyze, Improve and Control) refers to a data-driven improvement cycle used for improving, optimizing and stabilizing business processes and designs. The DMAIC improvement cycle is the core tool used to drive Six Sigma projects. … All of the DMAIC process steps are required and always proceed in the given order.
Here’s how I would answer.
The first question is whether they are truly processes. The do have steps, but PDCA at least is described as a method. Are methods and processes the same? I’m a little dubious, but for the sake of argument let’s say they are. (Something is only meta- if it is the same kind of thing as the thing it is applied to.)
The second question is whether they have processes as inputs, and processes as outputs. They do seem to do that.
The third question is whether they do what all processes do – they (potentially) transform the inputs. They do appear to do that too. (In other words they satisfy the predicate.)
3b: of a higher logical type – in nouns formed from names of disciplines and designating new but related disciplines such as can deal critically with the nature, structure, or behavior of the original ones *metalanguage* *metatheory* *metasystem*
Here are what I firmly believe are three basic principles for business architecture. To me they are just common sense, but they are certainly not so common in prevailing industry practices.1. Business architecture should be of, by and for the business. (Otherwise, why add the modifier “business”?!). Our rule of thumb is that if business people don’t use a methodology term naturally, then it has no place in *business* architecture. Ever hear a business person use the term “business use case” or simply “use case” without prompting from IT?! The technique is an obvious misfit for *business* architecture. This is simply a case of IT trying to elevate its own tools to a problem it frankly often doesn’t understand.2. The blueprinting techniques used for business architecture should apply exactly the same no matter how wide the scope – project, business process, whole business, whole supply chain, etc. These are all business problems (first), just sitting in different ecosystems. Also, it should make no difference whether automation is anticipated or not. (Actually, running business operations by hand may be harder in some respects than if automated. Anyway, systems do sometimes go down.) If a blueprinting approach fails in these regards, it’s not about *business* architecture.3. A major shortcoming in most current approaches is the absence of attention to specifying semantics and knowledge. These need not be interpreted as anything arcane – they’re not. Basically, ‘semantics and knowledge’ simply means defining business vocabulary – words – in an organized manner, and practicable rules to run the business by. Now what business person hasn’t heard of “words”, “definitions”, and “rules”?! Yet traditional IT methods treat them as alien (or not at all). In a day and age of IBM Watson, how could such practices not be seen as archaic?!~~~~~~~~~ P.S. Yes, such blueprinting techniques for business architecture do exist, and we practice them – in-depth – all the time with our clients. This is what our book Building Business Solutions: Business Analysis with Business Rules (http://www.brsolutions.com/b_building_business_solutions.php) is all about, as well as our on-line training based on it (http://www.attainingedge.com/online-training-business-analysis-with-business-rules.php).www.BRSolutions.com
You can find definitions and discussion of all terms inblueon Business Rule Community:http://www.brcommunity.com/BBSGlossary.pdf~~~~~~~~~~~~~~~~~~~business model:a blueprint for a business capability based directly on real-world things and ideas strictly named and represented using words natural to business people
Discussion: Even the words used for the building blocks of business models (e.g., the vocabulary used to develop structured business vocabularies) must be natural for business people – again, real-world. Business people talk about real-world things!
A business model enables business people and Business Analysts to engage in discussion about what needs to be created, managed, operated, changed, and discontinued in the business in business terms. Developing a business solution using a future-form business model does not necessarily imply software development, but if software development does ensue (as it usually does) the business model provides a solid grounding.
Examples of business models include strategies for business solutions (Policy Charters), business process models, structured business vocabulary (fact models), business milestone models, and Q-Charts (for decision analysis). The term business model is also used collectively to designate all the business models for a particular business capability. A business model is always subject both individually and collectively to the business rules specified for it.
system model:a model that provides a design for an automatable system that is computationally competent
Discussion: For many years John Zachman, creator of the Zachman Architecture Framework, has explained that a business model is always about real-world things. These real-world things are as the business leads see or define them.
A system model in contrast comprises “… surrogatesfor the real-world things so that the real-world things can be managed on a scale and at a distance that is not possible in the real world.” Surrogates include data entities in place of real-world things; GUIs and use cases in place of face-to-face, real-world communication; network nodes in place of real-world locations; system events rather than operational business events; and so on.
Does the separation between business model and system model blur in eCommerce? No. If business leads see or define ePersons (for example) as real-world, then real-world they are. To ensure you have a winning business solution, the ePersons should be defined and shaped within a business model. Afterwards comes design of a computationally-competent system model so you can conduct actual business with the ePersons. [John Zachman, informal communication, June 2011]~~~~~~~~~~~~~~~~~~Excerpted from 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, October, 2011, 304 pp, http://www.brsolutions.com/bbs
In yesterday’s post I talked about the difference between business models and system models: http://goo.gl/CMMPi To make a long story short, business models talk directly about real-world things (as business people do); systems models talk about surrogates for real-world things (as system designers do). Not the same thing!
Some people argue that the separation between business model and system model blurs in eCommerce. Does it? No. If business leads see or define ePersons (for example) as real-world, then real-world they are.
To ensure you have a winning business solution, the ePersons should be defined and shaped within a business model. Afterwards comes design of a computationally-competent system model so you can conduct actual business with those ePersons.
We’re teaching our online training course next week: Business Analysis with Business Rules: From Strategy to Requirements. http://goo.gl/Vnko3Hope to see you there!
Naturally, we’ll be talking a lot about business requirements. Are business requirements the same as functional requirements? No!Functional Requirement vs. Business Requirement
Wikipedia describes a functional requirement as …
“a requirement that defines a function of a software system … what a system is supposed to accomplish” [emphasis added]
We define a business requirement as …
“something called for or demanded by a business model that a system model must support”
That’s a big difference! Appreciating the importance of the difference, however, requires clear understanding of the distinction between business model and system model.
We define a business model as follows …
a blueprint for a business capability based directly on real-world things and ideas strictly named and represented using words natural to business people
We stress that business people talk about real-world things! And why should we ask them to do any differently?!
A business model enables business people and Business Analysts to engage in discussion about what needs to be created, managed, operated, changed, and discontinued in the business in business terms. Developing a business solution using a to-be business model does not necessarily imply software development, but if software development does ensue (as it usually does) the business model provides a solid grounding.
Examples of business models include strategies for business solutions (Policy Charters), business process models, structured business vocabulary (concept models), business milestone models, and Q-Charts (for decision analysis).
Any business model is always subject both individually and collectively to the business rules specified for it(!) We believe business rules are key to creating effective business requirements.
We define a system model as follows …
a model that provides a design for an automatable system that is computationally competent
For many years John Zachman, creator of the Zachman Architecture Framework, has explained that a business model is always about real-world things. These real-world things are as the business leads see or define them. That idea is actually his, not ours.
Zachman describes a system model, in contrast to a business model, as comprising “… surrogates for the real-world things so that the real-world things can be managed on a scale and at a distance that is not possible in the real world.” Surrogates include …
data entities or business objects in place of real-world things.
GUIs and use cases in place of face-to-face, real-world communication.
network nodes in place of real-world locations.
system events rather than operational business events.
If you are developing ‘requirements’ using use cases, you are actually designing a system (creating a system model), not defining business requirements(!). We believe a focus on use cases with no prior business model puts your project at grave risk.
Building Business Solutions: Business Analysis with Business Rules, by Ronald G. Ross with Gladys S.W. Lam, An IIBA® Sponsored Handbook, 2011, 304 pp.http://www.brsolutions.com/bbs
In running facilitated sessions, we like to create each kind of business model on a different wall. We find that the physical act of walking or shifting focus from one wall to another helps participants rapidly grasp and remember what each wall represents. It also helps business leads and Business Analysts identify disconnects and gaps in the business solution more readily. We call this walking the walls. Our definition: managing complexity in developing a business model by figuratively, and as much as possible literally, addressing each primitive as a separate concern (i.e., on a different wall)In physically walking the walks, we usually put business process model(s) on the left wall and the structured business vocabulary (concept model) on the right wall. On the front wall we put reminders about the strategy for the business solution (Policy Charter) and on the back wall we capture business rules. Aside: Business rules go on the back wall to help resist the temptation of wordsmithing, which is better done offline. In an ideal world, there would be one surface for each of the six primitives of the Zachman Architecture Framework. (Alas the ceiling and floor are hard to use.) Business rules, serving as integration relationships, would occupy the 3D space between the six surfaces (even harder to use!). Our approach approximates the notions well enough in practice.
Guest Post by Senior Consultant to Large OrganizationI am struggling on a project right now where the requirements were never properly collected in the beginning. So we’re now going back to our requirements to try and sort out what the business really wants. As this process of validating the original requirements started, I had just decided to read your new book. While reading about Policy Charters it immediately came to my head that this activity was never done formally with the business! Honestly I have heard different business people state goals to us all the time as we were building this system, but nobody on the original scoping or blueprint team ever once did a formal strategy to determine what the business wants and how we can give it to them.I hacked together a simple Policy Charter in Powerpoint to show the business the strategy. It made a big difference to finally have everybody on the team sit in one room and see how different business goals and their business tactics actually link to each other via business risks, which then precipitate other business tactics or business policies. We never had an overall view of the business goals like that before. Now I feel the business finally sees how complex their goals were and the consulting team really understands them too. So even though it is very late in the game, doing the Policy Charter has still helped a lot in our efforts to get our project back on track.I just wanted to let you know that your new book has been very helpful so far. I love it! I will be recommending it to all my colleagues.
‘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.
“Instructors were very knowledgeable and could clearly explain concepts and convey importance of strategy and architecture.
It was a more comprehensive, holistic approach to the subject than other training. Emphasis on understanding the business prior to technology considerations was reassuring to business stakeholders.”
Bernard – Government of Canada
“You did a wonderful job!! The material was organized and valuable.”
Janell – Texas State University
“We actively use the BRS business-side techniques and train our business analysts in the approach. The techniques bring clarity between our BAs & customers, plus more robust requirements for our development teams. We’ve seen tremendous value.”