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

	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

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.

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.

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!

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.)

Our Editor for BRCommunity.com, Keri Anderson Healy, attended the announcement event last week for version 3.0 of the Framework. Now she’s back home and has had a chance to share the rest of her notes. If you missed the first post, here’s a zipped pdf of the new 3.0 version again (with permission): ZF3.0.zip [approx 1.5M]. An official version will be posted on http://www.zachman.com soon. Visit Zachman’s new website for the latest!  

• Terms in some of the Column names changed.

 “Location” was previously used for the “Where” Column, which caused some people to put in instances (e.g., “Sacramento”). So, Column 3 now uses “Distribution Networks.” 

The “Who” Column now uses “Responsibility Assignments” to emphasize that it covers roles rather than the individuals.

•  Better artifact terms for the “When” Column.

 The “When” Column previously used the terms “Cycle” and “Event” for artifact models, which were often misunderstood. The Column 5 primitive models now use “Interval (for “Cycle”) and “Moment” (for “Event”). For example, Row 2 now features “Business Interval” and “Business Moment”.

•  Swapped the sets of names shown on the left and right sides of the graphic.

 The Model Names used to be shown to the left, and the Audience Perspectives on the right. These have been swapped.  

 As part of the ongoing work to improve communication about the Framework, the “Audience” labels now use “Perspective”.  

 Also, use of “Planner” was removed because it conveyed the wrong idea about the nature of the audience for the top Rows. Row 1 now uses “Executive Perspective” and Row 2 uses “Business Management Perspective”.

• Did not swap the sets of names shown at the top and bottom of the graphic.

 Zachman seriously considered moving the Classification Names (What, How, Where, Who, When, Why) to the bottom of the graphic and moving the Enterprise Names to the top.  At the last minute he decided not to because a practitioner shared a compelling story with him about how W-H-W-W-W-W inspired an important discovery in his work.  

•  New emphasis that the Framework does not show a decomposition.

 To communicate that going down the rows does not indicate decomposition, crooked arrows are now shown between each of the Rows. These crooked arrows emphasize that moving from one Row to the next represents a transform. (Credit was given to Ron for this suggestion.)

 Note: The transforms relationship can be one-to-many, but that’s something you need to manage very carefully.

• Alignment shown for two dimensions of the graphic – at the top/bottom and on the two sides.

 For horizontal alignment (across a Row), make sure your tool supports the primitives and then helps you manage the compositions.

 For vertical alignment (up/down a Column), you cannot just ‘push the button’ (do the transform), then forget about managing the vertical relationships. Change is inevitable, so vertical alignment must be maintained.

 

Here’s a zipped pdf of the new 3.0 version of the Zachman Framework (with permission): ZF3.0.zip [approx 1.5M]. An official version will be posted on http://www.zachman.com soon. Visit Zachman’s new website for the latest!  Our Editor for BRCommunity.com, Keri Anderson Healy, attended the announcement event – she reports an excellent turnout. The following are some quick first-look notes from Keri (my own comments appear in brackets). 

• The Framework has a new subtitle: The Enterprise Ontology (TM). Zachman considered changing the main title word “Framework” to “Ontology” but decided to stay with the former. 

[Keri and I both think that was a good decision.]

• Some new terms appear as replacements, aiming to better convey the ‘business’ message. Zachman explains:

“Because I came from an ‘information’ community I had initially used words like ‘data’ in column 1. Big mistake!  People thought the Framework was about IT! The first thing people saw was the word ‘data’.

[The Framework has always been about business engineering – that was clear even from the earliest talks I heard Zachman give in the late 1980s and early 1990s. In truth, I would have never guessed it would still be an issue 20+ years later.]

• Faint grey lines now appear crossing column boundaries in a row. These new connections better convey that the Framework supports two kinds of models: engineering (the primitives) and manufacturing (the composites).

The Framework is well-known for its depiction of the engineering primitives (the columns, which are normalized – one thing in one place). The engineering models, however, don’t do anything in and of themselves. The enterprise also needs its manufacturing models – the composites. So these new faint gray lines have been added as a reminder that the composite models also exist and they are also important.

Note: These new faint gray lines are meant as ‘for example’ connections. In this sense they are like the examples shown in the Framework for the primitives in the columns.

• Adjustments have been made to row 6 to better convey what it is about. In early versions of the Framework graphic, row 6 was depicted as just a sliver. It has always been ‘the enterprise’. Row 6 is different in nature from the five rows above it, which are engineering specifications for things in the enterprise, rather than the actual things themselves     
• The rows are now color-coded and each cell icon reflects the color theme of its row. At the request of various Framework users, however, the background coloring has been removed from the cells of rows 1-5 so users can annotate their own specifics over the cell graphics.      
• For rows 1-5, the color progression is red, orange, yellow, green, blue. Rather than the next-in-series indigo, row 6 is color-coded orange emphasizing that it represents the realization of what row 2 specifies.

[The row 2 / row 6 alignment is consistent with the business-engineering theme that Zachman so ably promotes.]

For those of you who know or have ever heard Zachman speak, I know this will come as a shock. Part of his 3.0 Release? Source: Real-time photo supplied by Keri Anderson Healy, Editor, BRcommunity.com

There is much confusion in the Enterprise Architecture space over some of the most fundamental words in the English language: what, how, where, who, when, why. I’m afraid to say there’s some very loopy thinking out there. Zachman anticipated all this and brilliantly provided six generic models for the 6 question words. Here they are roughly as follows (and possibly needing to be adjusted slightly in his new 3.0): What:  thing-relationship-thing How:  input-process-output Where:  site-link-site Who:  role-workproduct-role When:  event-cycle-event (moment-state-moment) Why:  ends-means-ends For me, it’s hard to argue that these are not what each question is about from an architectural point of view. The only thing missing is how you relate instances of the 12 elements to comprehensively configure an enterprise at any given point in time. (Zachman calls these “integration relationships”. They’ve always been there, but only on the schematic in 3.0.) IMO, the best, most dynamic (agile) way to support the ‘integration relationships’ is business rules. What could possibly be better?