Affiliated with:

7 Common Myths about the Zachman Architecture Framework

New Project 17

The Zachman Framework is a thinking tool, and not a methodology. Its abstract nature has led to the proliferation of some myths that hinder its understanding and adoption, even among data management and architectural communities.

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, even among data management professionals.

Simple Zachman Framework Overview

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

The Zachman Framework’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 Zachman Framework.

  • The columns represent the primitives of engineering problems and correspond to the six interrogatives (business engineering questions): what, how, where, when, 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.
  • The rows represent reifications [reify]: convert mentally into something concrete or objective: give definite content and form to: MATERIALIZE. 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 are.

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. Training in the Framework and related principles is essential for effective use of the Framework.

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.

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, from an educated perspective.

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

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, and its data management and architectural communities, the ability to view an effort from different points and arrive at a holistic representation.

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, http://www.brsolutions.com/bbs

LinkedIn
Facebook
Twitter

Ronald G. Ross

Ronald G. Ross is Co-Founder and Principal of Business Rule Solutions, LLC (BRSolutions.com). BRS provides consulting, training and mentoring in support of concept modeling, business knowledge engineering, business rules, and rule management.

Ron’s 40+ year career has consistently featured creative, business-driven solutions. Ron is recognized internationally as the “father of business rules.”

Ron is also Executive Editor and regular columnist of BRCommunity.com. He was formerly Editor of the Data Base Newsletter from 1977 to 1998. Ron is co-author with John Zachman and Roger Burlton of the 2017 Business Agility Manifesto (busagilitymanifesto.org). 

Mr. Ross holds an M.S. in information science from the Illinois Institute of Technology and a B.A. from Rice University.

© Since 1997 to the present – Enterprise Warehousing Solutions, Inc. (EWSolutions). All Rights Reserved

Subscribe To DMU

Be the first to hear about articles, tips, and opportunities for improving your data management career.