In Building Business Solutions: Business Analysis with Business Rules[1] Ron Ross provided a practical, proven guide to building great business solutions, emphasizing the importance of business architecture and the role of the Zachman Architecture Framework.[2] As part of that discussion he introduced some of the common myths about the Framework. Over the years that has been refined into a list of 'Seven Myths'. Recently, John Zachman shared his comments.

JAZ Comment: I really like Ron's characterization of myths relative to my Framework. I have simply added some comments that elaborate and/or rationalize the points that Ron makes — plus, I did add a Myth #8 that is significant because it affects many people's motivation to operationalize the Framework.

The Zachman Framework is a thinking tool. Its abstract nature has led to the proliferation of some myths that hinder its understanding and adoption.

JAZ Comment: Yes. The Zachman Framework is abstract because it is the meta model for the knowledgebase that constitutes the design of an Enterprise. That is, if there are no descriptive representations ("models") as prescribed by the Zachman Framework for a given Enterprise, that given Enterprise may exist, but it has never been DESIGNED … however big and complex it may be, it has only happened. The Zachman Framework is simply the same pattern of engineering design artifacts that are created for the production and maintenance of every tangible object that exists with Enterprise names instead of product names.

Introduction

Widely misunderstood and misrepresented, the Zachman Architecture Framework is simply a thinking tool, not a methodology. Its fundamentally-neutral position concerning methodology and implementation is the secret to its power and the reason it has proven so enduring. Many aspects of the Framework are misunderstood. The misunderstanding has resulted in the creation of some myths about the Zachman Framework and its value.

JAZ Comment: This is a VERY important point! The Framework is NOT a methodology. It is an Ontology, a classification structure that specifies 36 categories for facts relevant to the existence of an Enterprise. It is completely neutral as to which categories to formalize and which to ignore, the order of category formalization, the level of detail, the scope of completion, where to start, the nature of the Enterprise being designed, the tools, the technologies employed, etc., etc. All of these are methodological issues in nature, not ontological.

Simple Zachman Framework Overview

The Zachman Architecture Framework is the classification scheme or ontology created by John Zachman for engineering things of complexity.

Zachman's basic premise is that whenever anything of complexity is designed — a complex machine, a skyscraper, a microchip, a spacecraft, a product, a business (an enterprise), or some part of a business (a business capability) — there are two basic aspects that need to be addressed. These two aspects correspond to the columns and rows of the Framework.

The columns represent the primitives of engineering problems and correspond to the six interrogatives (business engineering questions): what, how, where, who, when, and why. (The order does not matter.) A primitive is a building block of software that can be used by other pieces of software to build a larger part of a system. If an artifact is not primitive, then it is a composite item and inevitably more complex and resistant to change (and NOT reusable — JAZ comment).

The rows represent reifications.[3] In engineering, an object is created for a particular audience with a certain perspective, set of needs, and agenda. The Framework recognizes six such reifications, or audiences. (Their order does matter.)

Six primitives (components) times six reifications (audiences) equals 36 cells in the Framework. An architect can think of those 36 cells as covering the universe of discourse for engineering things of complexity, a fundamental scheme for understanding and assessing completeness. Graphic depictions of the Framework naturally focus on the primitives for these cells.

Common Myths about the Framework

Myth #1. The Framework requires that an architect create an artifact for each and every cell. Wrong. The Framework is not a methodology; it is a classification scheme. Different methodologies emphasize problems of different kinds, so in practice some cells are likely to play a less prominent role than others.

Myth #2. The Framework can be applied only at the enterprise level. Wrong. It can be applied for an engineering problem of any size (scope) deemed to be meaningful.

Myth #3. The Framework discourages or precludes prototyping. Wrong. Again, the Framework is not a methodology, so no solution is implied. Much can be learned about the best solution for any given audience by prototyping alternative approaches.

Myth #4. The rows (i.e., reifications, or audiences) in the Framework are about increasing level of detail. Wrong. Each successive row represents a transformation of the previous reification into a new reification/audience. The new reification serves a new purpose for a distinct audience.

Any artifact in any row can be pursued to excruciating level of detail (as Zachman states) if deemed useful and productive. The fundamental idea is to make the next audience's job in creating the next reification that much easier.

Myth #5. The Framework does not recognize there are connections between the primitives (components). Wrong. A key question, in fact, is how the primitives are 'tied together' (configured) at any point in time to create a complete and workable solution.

Tying together (configuring) primitives is the purpose of integration relationships. The effectiveness of their configuration determines the degree of business agility that is achieved.

Two basic choices to support integration relationships are: procedural (processes) and declarative (business rules). Traditional processes with their hidden semantics are a poor choice (e.g., business rules hard-coded into software). Business rules, in contrast, support direct, business-friendly configuration, and rapid, traceable, continuous re-configuration.

JAZ Comment: I agree with the point Ron is making, however the Framework itself is completely declarative made up of SINGLE-variable, declarative, "Primitive," descriptions. One and ONLY ONE type of thing is classified in each Cell and each Cell varies independently with every other Cell. In contrast, every implementation is "Composite" in nature, that is, is made up of related Primitive components from more than a single Framework Cell in a Row. The problem is in the implementation methodology. If you have not designed your Enterprise, that is, if there are no populated Framework models, you can either create the Composite implementation structures procedurally (as is typical in application development methodologies) or, to Ron's point, separate the Rules as independent, declarative variables to avoid having to reverse engineer the rules from the procedural code and then re-write the code to accommodate changes.

If you have designed your Enterprise, that is, if you have populated the desired Primitive "models," (which you can do iteratively and incrementally — see Myth #8), you can REUSE the declarative rule relationships as defined in your Enterprise design (Primitive Models), enabling assembly of the Enterprise implementation Composites dynamically. That is, the Rules are derived declaratively from the "Means" (Strategies & Tactics of Column 6) in the Enterprise DESIGN, the populated Framework artifacts, and REUSED, on demand, in Composite implementations.

Myth #6. The Framework somehow induces complexity. Wrong. Engineering problems are inherently complex, with business engineering being perhaps the most complex of all (as Zachman contends.) In other words, the complexity already exists; the trick is to engage with it most effectively.

JAZ Comment: The way humanity has learned to address complexity is by reducing sample sizes through classification. Single dimension classification (e.g., hierarchical decomposition) is used by manufacturing to create smaller components that can be manufactured faster and cheaper. Multiple dimension classification (e.g., matrix, cube) is used by engineering to identify and eliminate "repeating groups" (eliminate redundancy, "normalization," i.e., Ted Codd). That is, the Framework significantly SIMPLIFIES the Enterprise by removing redundancy.

Redundancy is anathema to Architects because of escalating complexity, entropy (energy required, attempting to reconcile discontinuities caused by redundancies), and unintended consequences of change.

The Framework is a two-dimensional classification system defining (SPECIFYING) the engineering design artifacts for an Enterprise. Hierarchical decomposition can be employed within a single Cell (see Myth #4) for implementation (manufacturing) Composite structures.

Myth #7. The Framework slows down architecture and development. Wrong. That is not the experience of accomplished architects. Asking the right questions of the right audiences at the right times in the right ways does not slow down an initiative; it speeds up the effort, or at least avoids costly dead ends.

Remember, the cost and time needed for rework does not rise linearly for each subsequent reification (audience); it balloons. Overall acceleration is the desired outcome, and not just for the build activity. It is essential for the inevitable, myriad changes to business rules that always occur after the business rules are deployed.

JAZ Comment: This is REALLY important! I just wrote a nine-page article elaborating this point which likely constitutes the argument for why you are going to do Enterprise Architecture whether you like it or not!

Such solutions do not happen by accident; they require deliberate engineering. Zachman simply points out, like it or not, what such 'deliberate engineering' necessarily involves.

MYTH #8 (JAZ Addition): All the Cells of the Framework must be populated in order to build any systems. WRONG. Because, for Enterprises, the media of the architectural descriptions (Rows 1–5) is either manual (paper) or digital (automated), and the media of the operational Enterprise (Row 6) is either manual (paper) or digital (automated) — that is, there is no media transformation from Row 5 to Row 6. Therefore, the Enterprise does not have to be completely designed (Rows 1 through 5) before it can be operational (Row 6). It can be operating while it is being designed iteratively and incrementally using the Governance System (Plans and Controls) to maintain integration as it is being defined.

JAZ Continued: Furthermore, every Cell of the Framework exists either EXPLICITLY or IMPLICITLY. Any Cell or portion of Cell that is not made explicit is IMPLICIT, allowing anyone and everyone to make whatever assumptions they want about that Cell, which saves time and money. However, erroneous or inconsistent assumptions are the sources of DEFECTS in the end result, the Enterprise. Therefore, there is Enterprise RISK in choosing to save time and money by not formalizing a Cell or portion of a Cell.

Conclusion

The Zachman Framework for Enterprise Architecture is an excellent tool for classifying and organizing the perspectives required for successful enterprise architecture and its components. Focusing on the facts about the Framework instead of the myths can give any organization the ability to view an effort from different points and arrive at a holistic representation.

JAZ Comment: I would like to thank my friend Ronald G. Ross and our friend his editor, Keri A. Healy, for taking the time and expending the intellectual effort to actually think about and understand someone else's work. That clearly is friendship above and beyond the call of duty!

References / Notes

[1] Excerpted with permission from Building Business Solutions: Business Analysis with Business Rules (2nd Ed.), by Ronald G. Ross with Gladys S.W. Lam, Business Rule Solutions, LLC, 2015, 308 pp, https://www.brsolutions.com/publications/building-business-solutions/ p. 285-287.

[2] John A. Zachman, "John Zachman's Concise Definition of the Zachman Framework™," Zachman International, Inc. (2008) https://www.zachman.com/about-the-zachman-framework

[3] reify: convert mentally into something concrete or objective: give definite content and form to: MATERIALIZE [Merriam-Webster]

# # #