THE FRAMEWORK FOR ENTERPRISE ARCHITECTURE: Background, Description and Utility
By John Zachman
In the early ‘80’s, there was little interest in the idea of Enterprise Engineering or Enterprise Modeling and the use of formalisms and models was generally limited to some aspects of application development within the Information Systems community. The subject of architecture was acknowledged at that time, however, there was little definition to support the concept. This lack of definition precipitated the initial investigation that ultimately resulted in the “Framework for Information Systems Architecture.” Although from the outset, it was clear that it should have been referred to as a “Framework forEnterpriseArchitecture,” that enlarged perspective could only now begin to be generally understood as a result of the relatively recent and increased, world-wide focus on Enterprise Engineering.
The Framework as it applies to Enterprises is simply a logical structure for classifying and organizing the descriptive representations of an Enterprise that are significant to the management of the Enterprise as well as to the development of the Enterprise’s systems, manual systems as well as automated systems. It was derived from analogous structures that are found in the older disciplines of Architecture/Construction and Engineering/Manufacturing that classify and organize the design artifacts created over the process of designing and producing complex physical products (e.g. buildings or airplanes, etc.)
The Framework graphic in its most simplistic form depicts the design artifacts that constitute the intersection between the perspectives represented in the design process, that is, OWNER, DESIGNER and BUILDER; and the product abstractions, that is, WHAT (material) it is made of, HOW (process) it works and WHERE (geometry) the components are, relative to one another, WHO (operating instructions) is doing what work, WHEN (timing diagrams) do things happen and WHY (engineering design objectives) do things happen. Empirically, in the older disciplines, some other artifacts were observable that were being used for scoping and for implementation purposes. These additional perspectives aresomewhat arbitrarilylabeled PLANNER and SUB-CONTRACTOR and are included in the Framework graphic that is commonly exhibited.
The Framework as a classification structure, in its most generic form appears below:
The Framework, as it is employed classifying the descriptive representations of an Enterprise, that is, classifying Enterprise design artifacts (models) using Enterprise examples and terminology is as follows:
The older disciplines of Architecture and Manufacturing have accumulated considerable bodies of product knowledge through disciplined management of the “Product Definition” design artifacts. This has enabled enormous increases in product sophistication and the ability to manage high rates of product change over time. Similarly, disciplined production and management of “EnterpriseDefinition” (i.e. the set of models identified in the Framework for Enterprise Architecture) should provide for an accumulation of a body ofEnterpriseknowledge to facilitate enormous increases inEnterprisesophistication and accommodation of high rates ofEnterprisechange over time.
The Framework is a generic classification scheme for design artifacts, that is, descriptive representations of any complex object. The utility of such a classification scheme is to enable focused concentration on selected aspects of an object without losing a sense of the contextual, or holistic, perspective. In designing and building complex objects, there are simply too many details and relationships to consider simultaneously. However, at the same time, isolating sub-sets or components and making design decisionsout of contextresults in sub-optimization with all its attendant costs and dissipation of energy (entropy). Restoration of integrity or retrofitting the sub-optimized components of the resultant object, such that they might approximate the purpose for which the object was originally intended, may well be financially prohibitive if not logically impossible.
This is the condition in which many Enterprises find themselves today after about fifty years of building automated systems, out-of-context. They have a large inventory of current systems, built out-of-context, not integrated, not supporting the Enterprise, that are consuming enormous amounts of resource for maintenance and are far and away too costly to replace. As a matter of fact, the inventory of existing systems has come to be referred to as “the legacy,” a kind-of albatross, a penalty to be paid for the mistakes of the past.
A balance between the holistic, contextual view and the pragmatic, implementation view can be facilitated by a Framework that has the characteristics of any good classification scheme, that is, it allows for abstractions intended to:
- simplify for understanding and communication, and
- clearly focus on independent variables (primitives, individual Framework Cells) for analytical purposes, but at the same time,
- maintain a disciplined awareness of contextual (integrative) relationships of the Enterprise as a whole that are significant to preserve the integrity of the object thereby enabling
- the creation of an infinite variety of implementationcompositesderived from normalized, Enterprise-engineeredprimitives,as required to perform the work of the Enterprise.
It makes little difference whether the object is physical, like an airplane or a building or a computer, or conceptual, like an Enterprise. The challenges are the same. How do you design and build it piece-by-piece such that it achieves its purpose without dissipating its value, raising its operating costs1and inhibiting (or prohibiting) change by optimizing the pieces andsub-optimizing the object.
Although the Framework for Enterprise Architecture is an application of Framework concepts to Enterprises, the Framework itself is generic. It is a comprehensive, logical structure for descriptive representations (i.e. models, or design artifacts) of any complex object and is neutral with regard to the processes or tools used for producing the descriptions.
Like any good classification system, the Framework is “clean,” “normalized,” one fact in one place. There are no mixtures, “apples and oranges” in the structure. The classification is holistic, complete and it is stable. The same classification on both axes has been employed by humanity for hundreds if not thousands of years. It is not going to change. For this reason, the Framework, as applied to Enterprises, is helpful for sorting out very complex, Enterprise “engineering” choices and issues that are significant both to general management and to technology management.
In summary, the Framework is:
- SIMPLE – it is easy to understand … not technical, purely logical. In its most elemental form, it is five perspectives: Owner, Designer, Builder bounded by Scope (or, Strategist) and Detail (or, Implementer) … and six abstractions: What (Things), How (Process), Where (Location), Who (Organization), When (Timing) and Why (Ends). Anybody (technical or non-technical) can understand it.
- COMPREHENSIVE – it addresses the Enterprise in its entirety. Any issues can be mapped against it to understand their primitive (or elemental) composition within the context of the Enterprise as a whole.
- a LANGUAGE – it helps you think about complex concepts and communicate them precisely with few, non-technical words.
- a PLANNING TOOL – it helps you make better choices as you are nevermaking choices in a vacuum. You can position issues in the context of theEnterprise and see a total range of alternatives.
- a PROBLEM-SOLVING TOOL – it enables you to work with abstractions, to simplify, to isolate simple, single variables without losing sense of the complexity of the Enterprise as a whole.
- NEUTRAL – it is defined totally independently of tools or methodologies and therefore any tool or any methodology can be mapped against it to understand their implicit trade-offs and degree of completion … that is, what they are doing, and what they are NOT doing.
- the RAW MATERIAL FOR ENTERPRISE ENGINEERING – the primitive models, when operationalized for an Enterprise, are the design artifacts required for Enterprise Engineering just like the drawings, functional specs, bills-of-material, etc., etc. are the design artifacts required to engineer any physical object.
The Framework for Enterprise Architecture is not “the answer.” It is a tool … a tool for thinking. If it is employed with understanding, it should be of great benefit to technical and non-technical management alike in dealing with the complexities and dynamics of the Information Age Enterprise.
If the models as specified by the Framework were operationalized for a given Enterprise, engineering design objectives like alignment (quality), integration, flexibility, interoperability, etc. could be an operating reality employed to accommodate complexity and optimize the Enterprise. The models, if retained and maintained, would serve as a baseline for managing change. These are the characteristics of architecture for anything.
Architecture is not one thing. It is a set of things, in fact, a set of 30 descriptive representations relevant for describing a complex object such that it can be created (that is, engineered, optimized so it meets its design objectives) and relevant for changing (that is, improving the object over time). This is true for Enterprises just as it is true for buildings, airplanes, automobiles, bridges, super computers, battleships, semi-conductor chips or any other complex object.
1. “The Zachman Framework: A Primer for Enterprise Engineering and Manufacturing”. Published by Zachman Framework Associates. 2003. www.zachmaninternational.com
2. “A Framework for Information Systems Architecture.” John A. Zachman. IBM Systems Journal, vol. 26, no. 3, 1987. IBM Publication G321-5298. .
3. “Extending and Formalizing the Framework for Information Systems Architecture.” J.F. Sowa and J. A. Zachman. IBM Systems Journal, vol. 31, no. 3, 1992. IBM Publication G321-5488. .
1Energy expended compensating for discontinuities, that is, energy not available to do productive work, or “entropy.” Re: The second law of thermodynamics, the aging process, where entropy increases over time. When the energy required to support the system, that is energy required to compensate for increasing anomalies and discontinuities (or entropy) exceeds the energy in the system, the system dies.
About the Author
John A. Zachman is the originator of the “Framework for Enterprise Architecture” which has received broad acceptance around the world as an integrative framework, or "periodic table" of descriptive representations for Enterprises. Mr. Zachman is not only known for this work on Enterprise Architecture, but is also known for his early contributions to IBM’s Information Strategy methodology (Business Systems Planning) as well as to their Executive team planning techniques (Intensive Planning). Mr. Zachman retired from IBM in 1990, having served them for 26 years. He presently is Chairman of the Board of Zachman Framework Associates, a worldwide consortium managing conformance to the Zachman Framework principles. He is Chief Executive Officer of the Zachman Institute for Framework Advancement (ZIFA), an organization dedicated to advancing the conceptual and implementation states of the art in Enterprise Architecture. He also operates his own education and consulting business, Zachman International. Mr. Zachman serves on the Executive Council for Information Management and Technology (ECIMT) of the United States Government Accountability Office (GAO). He is a Fellow for the College of Business Administration of the University of North Texas. He serves on the Advisory Board for the Data Resource Management Program at the University of Washington and on the Advisory Board of the Data Administration Management Association International (DAMA-I) from whom he was awarded the 2002 Lifetime Achievement Award. He was awarded the 2004 Oakland University, Applied Technology in Business (ATIB), Award for IS Excellence and Innovation. Mr. Zachman has been focusing on Enterprise Architecture since 1970 and has written extensively on the subject. He is the author of the book, “The Zachman Framework for Enterprise Architecture: A Primer on Enterprise Engineering and Manufacturing.” He has facilitated innumerable executive team planning sessions. He travels nationally and internationally, teaching and consulting, and is a popular conference speaker, known for his motivating messages on Enterprise Architecture issues. He has spoken to many thousands of enterprise managers and information professionals on every continent. In addition to his professional activities, Mr. Zachman serves on the President’s Cabinet of the King’s College and Seminary, the Board of Directors of the Los Angeles Citywide Children’s Christian Choir, the Board of Directors of Native Hope International, a Los Angeles-based ministry to the Native American people and has served on the Elder Council of the Church on the Way (First Foursquare Church of Van Nuys, California) and on the Board of Directors of Living Way Ministries, a radio and television ministry of the Church on the Way. Prior to joining IBM, Mr. Zachman served as a line officer in the United States Navy and is a retired Commander in the U. S. Naval Reserve. He chaired a panel on "Planning, Development and Maintenance Tools and Methods Integration" for the U. S. National Institute of Standards and Technology. He holds a degree in Chemistry from Northwestern University, has taught at Tufts University, has served on the Board of Councilors for the School of Library and Information Management at the University of Southern California, as a Special Advisor to the School of Library and Information Management at Emporia State University, and on the Advisory Council to the School of Library and Information Management at Dominican University. Mr. Zachman can be reached at email@example.com