The Zachman Framework is a thinking tool. Its abstract nature has led to the proliferation of some myths that hinder its understanding and adoption.
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.
Simple Zachman Framework Overview
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, 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.
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.
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.
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.
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