Architected Futures™

Tools and strategies ... for boiling the ocean

Element Classification System

Classification Framework

In a 1987 IBM Systems Research Journal article John Zachman proposed a framework for rationalizing concepts and specifications in the development of information systems. He developed his framework while working for IBM and studying the operations and requirements of a great variety of IBM customers. The framework he documented in 1987 was extended and formalized in a 1989 IBM Systems Research Journal article which was co-authored by John F. Sowa. The Zachman Framework, as it has become known, is a widely used reference model used by enterprise architects to explain and measure various facets of enterprise architecture. We use an adapted form of the framework within the Enterprise Architecture Tool Suite as a comprehensive schema for the classification of architectural elements and as a measurement system for architectural evaluation and comparisons.

Element Classification Framework

Figure 1Element Classification Framework

The grid in Figure 6 depicts the adapted Zachman Framework using Architected Futures’ naming conventions and column arrangement. Each axis of the framework is comprehensive in scope with regard to its dimension, and defines its dimension in terms of a series of easily comprehensible primitives. While the number of cells within the model is rather large to be fully comprehended as a unit, its organization is easy to understand and the dimensions are easy to understand. Using these two dimensions, a comprehensive set of simple, primitive models of an enterprise can be built, providing a rich information space with very clear separation of concerns between elements.

The layers of the schema, defined by the rows, describe different perspectives of the architecture with regard to the attention to detail and the breath of vision. The higher level perspectives are course-grained and broad focused. They tend to deal with abstract, general things. The lower perspectives are fine-grained and narrow focused and tend to deal with specific things. Correspondingly, the potential volume of material that might be developed is much larger at the lower levels than at the high levels. At the top, the schema provides a mechanism to encompass the whole of the enterprise and define its bounds and its relationship to its environment. At the bottom, the schema provides facilities to define every detail component part of the functioning enterprise. Between them is a layered scheme for decomposition translating from the view of the whole to a potentially microscopic examination of the parts.

At each level of the framework, the columns address the fundamental questions of who, what, where, when, how and why. Each column of the framework defines a focal point class of entities associated with the response to the question posed by that column. They define different areas of concern that, when taken together, tend to create a holistic definition of the rationale, activities and operation of the enterprise; the structure and behavior of the architecture. They again describe differing perspectives of the architecture; but rather than varying the degree of abstraction, they vary the focal point in terms of subject matter.

By using these two elements together, the grid provides a comprehensive schema for classifying architectural information with respect to an abstraction level (indicating a perspective or viewpoint) and an area of focus, or data type. The cells at the intersections of the columns and rows define a comprehensive framework of primitive elements and models describing all aspects of the enterprise in a methodical manner, from scope and concept to operation.

Examining the rows:

  • The Contextual layer defines scope. It was originally defined as the Ballpark View and is sometimes referenced as the planner’s view. It determines what is to be included or excluded, and where the boundaries between the two are set. It defines environmental context and the relationship of the architected space and its elements to the elements in the environment.
  • The Conceptual layer defines the intent and policies for the architected element. It is sometimes referred to as the owner’s view or the business model view. It defines how the architected element chooses, within the constraints allowed by the environment, to accomplish its purpose. In broad terms it defines how the architected element is to be organized, to what purpose, and what means are to be used to achieve those ends.
  • The Logical layer defines the logical components that must exist as part of the architected element, and assigns characteristics and responsibilities to the components. It is sometimes referred to as the designer’s view, or the system model view. It describes how the components will interact with one another, and with external environmental agents, in order to achieve the purposes laid out in the conceptual architecture.
  • The Technical layer assigns specific technologies to the components in the Logical layer. In Zachman’s framework this is defined as the physical layer. It is also referenced as the builder’s view or the technology model. In some cases, multiple technologies might be used to accomplish selected roles, or single technologies might be used to perform multiple roles. The purpose of this layer is to translate the logical components and functions defined in the Logical layer into specific technologies. Those technologies might be generic automated technologies, but they might also be manual technologies with specific skill requirements.
  • The Physical layer defines the detailed composition of the elements defined at the technical layer. In Zachman’s framework this is layer is defined as out-of-context. It is also referenced as the detailed representations layer or the sub-contractor’s view.
  • The Operational layer defines the individual instances of the architected elements in the real world. In Zachman’s framework this is called the functioning enterprise layer. Architectural models maintained and activities accomplished at this level tend to track rather than specify. They tend to be focused on measurement and control and well as maintenance and monitoring. Data gathered at and about this layer forms the basis for feedback loop providing the actual operational metrics of the enterprise and defining how effective the architecture is in achieving the goals of the enterprise.

Examining the columns:

  • Motive (or Purpose) answers the question “Why?” and delineates rationale. It defines goals and objectives, and the strategies or other means used to achieve them. It describes purpose and provides direction.
  • Party answers the question “Who?” (or "Which?") and defines the actors or players. In the Zachman framework this is called People. It includes people, organizational entities and other agents of consequence to the life process of the enterprise and their role and responsibilities in relative to enterprise operations. In the Architected Futures’ application Party may include both human and non-human agents (actors) with roles and responsibilities.
  • Thing answers the question “What?” and defines the objects of consequence to the enterprise and the structural relationships they have with each other. These are the nouns of the enterprise. They include products and services and the resources used in their production or delivery. In the Zachman framework this is referred to as Data1. In addition to elements which may appear only here as resources, products or means of production, Things include the manifestation or instantiation of elements in the other categories (e.g., business objectives, personnel). What kind of Thing a Thing is relates to the role of the Thing in a system. In our classification scheme, we have six perspectives on Things:
    1. Things that have special interest as motives.
    2. Things that have special interest as system actors.
    3. Things that have special interest as functions.
    4. Things that have special interest as temporal mechanisms.
    5. Things that have special interest as geospacial mechanisms.
    6. Things that have no special interest as anything other than that they are things that relate to other things in the understanding and architecture of a system. They are simply of concern as system objects. They are data.
  • Function answers the question “How?” and defines processes of consequence to the enterprise. These are the verbs of the enterprise. Processes are the mechanisms by which selected things are transformed into other things over time. The define the mechanism of production: the raw materials used, the assembly or fabrication process, and the products produced
  • Time answers the question “When?” and defines the schedules for events and activities within the enterprise. Business and process cycles are defined here. The elements in this column provide temporal order to the activities of the enterprise.
  • Location answers the question “Where?” and defines the placement of things in time and space and the mechanisms for interconnection. In the Zachman framework this is referred to as Network.

The architecture layers of the Zachman Framework define a hierarchy. However, neither the approach advocated by John Zachman nor the use of the Enterprise Architecture Tool Suite requires the development of the architecture artifacts to follow any specific path. Both “top-down” and “bottom-up” techniques can be supported. And both may be done simultaneously. Real world situations most often require this flexibility. The framework provides a coordinate space and mapping mechanism that allows tracking of architectural elements as they are developed, and a measurement system to gauge the type of coverage being made as islands of information are populated on a project by project basis. It also provides the basis for validation and reconciliation as the detail islands are merged and assembled into a larger picture.

 

  • 1. The Zachman framework is focused on the specification of a comprehensive, normalized schema of architectural primitives. As such there is no overlap between elements. The Zachman framework is an important element, but only one of a series of frameworks that are utilized within the Architected Futures tool suite. Some primitive elements in the tool suite can play multiple roles in the architecture. Thing is a universal class that encompasses all elements.

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.