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

Concept Model vs. Data Model

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

Continue Reading 1 Comment

BPM and the Knowledge Economy: Nothing But Widgets?

BPM often overreaches. Understanding, modeling and managing a business capability effectively requires a balanced view of six basic questions, not just one, as given in the table below. I follow Zachman in these matters, so yes, the table is Zachmanesque.

Interrogative

Basic Business Question

Kind of Model

1. What What inventory of things needs to be managed to support business activity? structural model (e.g., concept model[1], data model)
2. How How do transforms of things in business activity need to take place to add value? process model
3. Where Where does business activity occur? network model
4. Who Who collaborates with whom to undertake business activity? interaction model (e.g., organizational chart, use case)
5. When When does business activity take place? temporal model (e.g., schedule, event model, milestone model)
6. Why Why are results of business activity deemed appropriate or not? strategy model (e.g., Policy Charter[2], constraint model)
  If your business does nothing but manufacture or produce physical widgets (forget all the meta-data about those widgets), you will probably emphasize question 2 (i.e., process) above the others. Your overall approach and architecture will reflect that. You will naturally gravitate toward BPM. That tendency has at least three basic risks, even for organizations that do fall into the nothing-but-widgets category:
  • Your metrics will largely focus on process productivity (e.g., throughput, bottlenecks, latency), rather than strategic goals and alerts centered on external risks. E-suite executives tend to be much more focused on the latter.
  • Your mindset will be procedural, rather than declarative, which can cause you to embed business rules in process flows rather than externalize them. As a result your process models will be unnecessarily complex and your overall solutions un-agile.
  • You approach will fall woefully short in addressing the intellectual capital that underlies your processes. Such operation business knowledge ranges from simple meta-data, to the business logic that underlies operational business decisions.
Fewer and fewer business problems these days fall into nothing-but-widgets category. Even for widget-centric businesses, at least three needs are increasingly urgent:
  1. Ensuring the quality of meta-data.
  2. Demonstrating compliance based actual rules, rather than the artifacts and effects that IT systems produce.
  3. Retaining, teaching and repurposing intellectual capital.
These are not strengths of common BPM practices. ~~~~~~~ Read more about the future for processes: What is the Future for Processes? http://www.brsolutions.com/2015/11/09/what-is-the-future-for-processes/ Are Processes and BPM Relevant in the Digital Economy? http://www.brsolutions.com/2015/10/19/are-processes-and-bpm-relevant-in-the-digital-economy/ Measuring Quality and Defects in the Knowledge Economy: http://www.brsolutions.com/2015/10/27/measuring-quality-and-defects-in-the-knowledge-economy/ Quality and Tolerances in the Knowledge Economy: http://www.brsolutions.com/2015/10/29/quality-and-tolerances-in-the-knowledge-economy/ ~~~~~~~~~~~~~~~ www.BRSolutions.com


[1] Refer to Refer to Business Rule Concepts:  Getting to the Point of Knowledge (4th ed), by Ronald G. Ross, 2013, Chapter 1 and Part 2.  http://www.brsolutions.com/b_concepts.php 
[2] Refer to Building Business Solutions:  Business Analysis with Business Rules by Ronald G. Ross and Gladys S.W. Lam, 2nd ed. (Sept, 2015), an IIBA Sponsored Handbook, Chapter 4.  http://www.brsolutions.com/b_building_business_solutions.php 

Continue Reading 3 Comments

Pleased to Announce Release of Our New Book Edition!

Building Business Solutions: Business Analysis with Business Rules (2nd Edition) … Just Out! http://www.brsolutions.com/b_building_business_solutions.php Get it on Amazon: http://goo.gl/HXxN1f What It’s About: How to develop business solutions working directly with business leads, create blueprints of the solutions, and then use those blueprints for developing system requirements. Engineering business solutions, not just requirements.We have applied the techniques described in this book successfully in hundreds of companies worldwide. Kind Words from a Practitioner: “We have based our whole business rules analysis practice on the methodology and techniques developed by the Business Rules Solution team. This book is an integral part of our practice. It’s an easy to read, useful guide with real life examples – we use it daily and couldn’t do without it!” – Michelle Murray, Inland Revenue Department NZ New in this Edition: How Business Architecture corresponds with your projects and requirements work. Developing a Concept Model and how it will help you. How business rules align with the new terminology in the recently released IIBA® BABOK® Guide version 3. ~~~~~~~~~~~~~~~~~ www.BRSolutions.com

Continue Reading

Re Zachman and What He Really Says …

One way of looking at the Zachman Architecture Framework is that it is about asking the right questions in the right ways at the right times of the right people. The number of transformations (between the rows) is fixed … either they happen in your head or they happen via specifications to tools. Some developers have great heads, but personally I prefer the answers to be traceable, auditable, and reversible over time. BTW, the lower-level transformations could be automatable and simple … if only the higher-level specification support were powerful enough. And with machines more powerful every day, they should be.

Continue Reading

Business Model vs. System Model – Very, Very Different … Do You Get the Difference?!

You can find definitions and discussion of all terms in blue on 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-worldBusiness 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 “… 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 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

Continue Reading 1 Comment

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

What’s the Difference Between Business Requirements and Functional Requirements?


We’re teaching our online training course next week: Business Analysis with Business Rules: From Strategy to Requirements. http://goo.gl/Vnko3 Hope 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. Business Model  We define a business model as follows[1]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. System Model 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.
  • etc.
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.
[1]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
 

Continue Reading

Creating a Business Model: Walk the Walls!

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.

Continue Reading

The Debate Continues … Business Rules in Zachman 3.0 … and the Upcoming Business Architecture Summit at BBC2011

At the Business Architecture Summit in Ft. Lauderdale (BBC2011 – Oct 31 – Nov 4) I will be joining John Zachman and Roger Burlton for one of our rabble-raising 3Amigo sessions. The session is only an hour long, so I’m sure there will be some fast talking(!). One of the first questions I want John to address is: “Where are the business rules in Zachman 3.0?” The following recent exchange represents my current understanding on the matter. I plan to come back on the record after the event to say what I got right and what I got wrong. Question: Can rules address more than one primitive (column) in the Framework? My Answer: Yes, atomic rules can address multiple primitives – e.g., An accounting must be given by the CFO in Delaware on March 15, 2012. (By ‘atomic’ I mean ‘can’t be reduced into two or more rules without losing meaning.’) In this rule you have a thing (‘accounting’), a person (the CFO), a place (Delaware), and a date (March 15, 2012). So even atomic rules are composites, not primitives. Question: Does rules not being a primitive mean that business rules shouldn’t be treated as a first-class citizen? My Answer: What ‘first-class citizen’ has always meant in the Business Rule Manifesto (http://www.businessrulesgroup.org/brmanifesto.htm) and elsewhere is that business rules shouldn’t be subordinate to other kinds of requirements for system design in general, and to what I call ‘Big-P’ processes in particular. Big-P processes are not primitive (think ‘input-process-output’), but rather they amalgamate (think ‘mash-up’) some or even all the other primitives. In other words, Big-P processes are also composite. Composites are about the configuration of the enterprise at any point in time. Business rules are one candidate for that capacity. I believe business rules are a far better choice in that regard than Big-P processes (think ‘business agility’). In any case, business rules being a composite in no way diminishes their importance. The enterprise is not built on primitives alone. If you had only primitives, there would be no configuration, and literally no enterprise.

Continue Reading 1 Comment