Zachman International - The Official Home of The Zachman Framework™

Two years ago, some of my friends pressed me intensely to be more definitive about the Framework concepts. Even though, I had written “The Book”, they were specifically asking me for definitions of the entities that comprise the metamodel of Row 2 of the Enterprise Framework. It has taken me and a team of dedicated folks two years, however we have progressed far beyond the original requirement.

We have produced descriptions, not only of the entities of Row 2 of the Enterprise Framework, but also we have definitions of the entities of Row 1, Row 2, Row 3, Row 4, Row 5 and Row 6 of the Enterprise Framework plus descriptions for the Product Framework (where I learned about the Framework classification in the first place), for the Profession Framework (that I used to call the I/S Framework, the “meta Framework” relative to the Enterprise Framework) and for the Zachman Classification Framework (the Framework classification for all Frameworks).

This work is particularly significant at this point in time for several reasons.

Reasons for Framework Standards

Clarification. Although I first articulated the concepts of the Framework around 1980, some 25 years ago, and although the concepts have never changed, and although I have written a book and 30 or more substantive articles about the Framework, there still is some confusion as to the specific contents of the models prescribed by the Framework classification. This is likely due to several reasons.

First, Enterprise Architecture constitutes a paradigm shift and many people have not yet been inclined to make the mental, cultural and behavioral adjustment to engineer and manufacture the enterprise. Second, in some cases we haven’t chosen words, or there have not even been English words available, that accurately convey all of the Framework concepts. Third, we have not used common, universally agreed-upon dictionary definitions for the words used to express the concepts. Fourth, our understanding of the Framework has been enhanced and refined immeasurably over 25 years.

It is only appropriate to review the choice of words to ensure the concepts are conveyed as accurately and clearly as possible.

Enterprise Orientation as Opposed to Information Systems Orientation. From its inception, the Framework has been a classification of descriptive representations of the Enterprise, that is, all of the descriptive representations embodied in the Framework are descriptive of the ENTERPRISE, not simply descriptive of a limited subset of the Enterprise that is related to Information Systems.

The Enterprise descriptions may or may not have anything to do with information systems technologies depending upon whether such technologies are used as the ‘Builder’s Constructs’ in the Row 4 models or not. Unfortunately, around 1980 when I first drew the Framework graphic, the only words I had at my disposal for the Framework concepts were words from my information systems vocabulary. Because of my choice of words and because many of the skills required to do the work of Enterprise Architecture are typically found in the Information Systems community, some people misconstrue the Framework intent as an Information Systems schema rather than its true intent as an ENTERPRISE schema.

In the Framework Standards we have attempted to select words from an ENTERPRISE, general ‘business’ vocabulary, not an information systems or technical vocabulary, to correctly convey the idea that Enterprise Architecture is an ENTERPRISE issue, not simply an information or technology issue.

The end object is to engineer and manufacture the ENTERPRISE, not simply to build and run systems.

First, there is the universal consistency in the world at large. As global communication and collaboration expands, there is an increasing requirement for semantic coherence. If people’s words do not mean the same thing there is neither communication nor collaboration. It is imperative for any communication or collaboration within or among Enterprises to define Enterprise Architecture consistently. The instances of Architecture in different Enterprises may be expressed with different content however the underlying classification and components of Architecture must be consistent for any interoperability (internal or external) to be effected.¹

A second dimension of consistency is that between the ‘meta’ Frameworks of any given Enterprise. The instances of models of one Framework are determined by the Row 2 models of its meta-Framework.² Inconsistencies in the meta-structures within an Enterprise would render Enterprise Architecture unmanageable.