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 meta model 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 definitions, not only of the meta entities of Row 2 of the Enterprise Framework, but also we have dictionary definitions of the meta entities of Row 1, Row 2, Row 3, Row 4, Row 5
and Row 6 of the Enterprise Framework plus dictionary definitions 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, 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 engineering and manufacturing 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 Constraints” 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.
Consistency.
There are two dimensions to the consistency issue.
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 expression in different Enterprises may be different, however the underlying classification and components of Architecture must be consistent for any
interoperability (internal or external) to be effected.[1]
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.[2] Inconsistencies in the meta-structures within an Enterprise would render Enterprise Architecture unmanageable.
Differentiation.
Enterprises are complex. Managing the knowledgebase of the Enterprise that is required for Enterprise operation and change is complex. The key to managing complexity is classification. The
Zachman Framework is a classification system for descriptive representations that constitute the knowledgebase of Enterprises. However, each Enterprise potentially has four knowledgebases of
importance to them: a) knowledge about their Product (if a product is produced); b) knowledge about the Enterprise itself; c) knowledge about the Professional (likely “indirect”, “Staff”)
community that is engineering (designing) their Enterprise; and, d) knowledge about the classification of knowledge itself.
Although the classification of knowledge (the Zachman Classification system) is the same, the knowledgebases within the Enterprise are different, but related in a deterministic fashion. The impact
of inconsistencies between knowledgebases within an Enterprise is amplified (probably) exponentially.[3] The Framework Standards clearly differentiates the three
knowledgebases, the Profession Framework, the Enterprise Framework and the Product Framework but maintains complete conceptual consistency with knowledge classification itself, the Zachman
Classification Framework.
Certification.
This may be the most pressing reason for publishing Framework Standards at the present time.
As the Information Age becomes more experientially real, the issues of complexity and change become more urgently confrontational for Enterprises which intensifies the demand for Architecture.
Humanity for seven thousand years has found no mechanism for accommodating complexity and change other than Architecture. Therefore, there presently is an increasing demand for “certified”
Enterprise Architects.[4] In fact, if Enterprises are seen to fail because they cannot accommodate complexity and change and people are forced out of work and
pension funds cannot be sustained, there might even be regulatory action requiring certification of Enterprise Architecture in the process of licensing Enterprises to operate in any particular
political jurisdiction, or to meet federal regulation or meet management behavior control.
If there are no published standards (criteria against which certification can be measured), certification is purely cosmetic. The concept of certification could be applied not only to Enterprise
Architects or to work produced by Enterprise Architects but also to Enterprise Architecture methods and tools. Furthermore, there is also a requirement to establish a standard, “public access”
basis for accommodating unique requirements through an elaboration of the base standards as the body of knowledge continues to explode.
Elaboration.
The enormous complexity of Enterprises and the vast experience of those people who tend to focus on Enterprise Architecture mandate a capability to accumulate elaborations of the Framework
Standards as practitioners’ experience grows.
There has to be a single, authorized facility to publish certified elaborations as well as to publish certified compliance of methods, tools, skills or models to the Zachman Framework Standards.
Hopefully this will protect the integrity of the Framework concepts from some of the misperceptions or even distortions of the Framework that derive from maybe well-intentioned, but misinterpreted
or misguided self-proclamations of compliance, or even of misunderstanding of basic Framework concepts.
In Conclusion.
The graphic and the meta-model standards overview for the most widely deployed Framework, the Enterprise Framework, will have “open Access” through a personal use license. The graphics for the
other three Frameworks with complete meta-model standards for all four Frameworks, along with associated elaborations and certifications, will be made available as they are completed on an “open
access,” personal use, subscription basis.
I hope you will find the Zachman Framework Standards of great value to your Enterprise Architecture practice.
[1] The instances of Architecture only have to be common in those specific areas of the Enterprise (“slivers” of Framework Cells) in which
inter-operation is to be effected but the definition of Enterprise Architecture has to be common throughout.
[2] See “The Zachman Framework: A Primer for Enterprise Engineering and Manufacturing” www.zachmaninternational,com
[3] See the comments on Consistency above.
[4] Just as you would want certified engineers engineering your building, certified chemists designing your pharmaceuticals, certified accountants
designing your chart of accounts, certified mechanics maintaining your Mercedes, etc., etc., etc. … so should you probably want certified Enterprise Architects engineering (designing) your
Enterprise.
Copyright © 2005 Zachman International
