Enterprise Architecture Framework – Background Description and Utility

The Zachman Framework for Enterprise Architecture classifies and organizes information that is important to management as well as for development, and includes all the artifacts for each role and product. The framework provides support for many functions, including enterprise data management

In the early 1980’s, there was little interest in the idea of enterprise engineering or enterprise modeling and the use of formal methods 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.  Architecture is defined as “the process and the product of planning, designing, and constructing complex structures, both tangible and intangible.”

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 for Enterprise Architecture,” that enlarged perspective could only now begin to be generally understood because 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 from the process of designing and producing complex physical products (e.g. buildings or airplanes, etc.)

In its simplest form, the Framework for Enterprise Architecture depicts the design artifacts that constitute the intersection between the perspectives represented in the design process (OWNER, DESIGNER and BUILDER) and the product abstractions.  These products are broken into components: WHAT (material) it is made of, HOW (process) it works and WHERE (geometry) the materials are, 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 used for scoping and for implementation. These additional perspectives are somewhat arbitrarily labeled PLANNER and SUB-CONTRACTOR and are included in the Framework graphic that is commonly exhibited.

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 “Enterprise definition” (i.e. the set of models identified in the Framework for Enterprise Architecture) should provide for an accumulation of a body of Enterprise knowledge to facilitate enormous increases in Enterprise sophistication and accommodation of high rates of Enterprise change over time.

The Framework for Enterprise Architecture 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 decisions out of context results 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 more than 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. The lack of enterprise data management capabilities is another challenge contributing to this condition.

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.  A good framework scheme allows for abstractions intended to:

1. simplify for understanding and communication, and
2. clearly focus on independent variables (primitives, individual framework cells) for analytical purposes, but at the same time,
3. 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
4. the creation of an infinite variety of implementation composites derived from normalized, enterprise-engineered primitives, as required to perform the work of the enterprise.

It makes little difference whether the object is physical, like an airplane, 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 so that it achieves its purpose without dissipating its value, raising its operating costs and inhibiting (or prohibiting) change by optimizing the pieces and sub-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 for Enterprise Architecture is “clean,” “normalized,” (one fact in one place).  There are no mixtures; “apples and oranges” are not found together 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 for Enterprise Architecture 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:

1. 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.
2. 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.
3. a LANGUAGE – it helps you think about complex concepts and communicate them precisely with few, non-technical words.
4. a PLANNING TOOL – it helps you make better choices as you are never making choices in a vacuum. You can position issues in the context of the enterprise and see a total range of alternatives.
5. 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.
6. 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.
7. 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 in dealing with the complexities and dynamics of the Information Age enterprise.

If the models as specified by the Framework for Enterprise Architecture 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.

Conclusion

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.  The representations and the Framework for Enterprise Architecture  allow the object to 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.