TEN#42: 2008 Pearcey Awards and
Enterprise Convergence in Our Lifetime

Enterprise Convergence in Our Lifetime by Stan Locke, Managing Director, Zachman Framework Associates, Toronto, Canada

As I sit here at the cottage near Ottawa, this long holiday weekend, handwriting on my diminishing supply of A4 continuous tractor fed paper, I am reminded that this was the hot technology of the seventies for computer generated letters, thesis writing and QuicLaw from APL Selectric terminals.  This of course has passed into the history of the last century.  Now, I will send this note on to Clive in Perth who will redistribute it to you all over the globe.  What a phenomenal convergence in our ability to create, connect, convey and converse so quickly!

During those same years IBM was very strong in formulating Business Systems Planning (BSP) studies with their customers, but couldn’t really get these into implemented systems that could move the enterprise to where it need to go.  Along came an IBM planner John Zachman who proposed a convergence theory of the ‘architecture’ for information systems.  With his strong customer ties to the aerospace industry, manufacturing sectors, and personal architect friends, Zachman soon understood that moving the global plan to implementation involved several different ‘stakeholder’ representations.  Hence, the fundamental notions of owner, designer and builder perspectives were identified. 

But, every perspective needed to answer the basic communication interrogatives of who, how, what, where, when and why to be a complete description which when made explicit could remove assumptions and ambiguity. Zachman was afraid to tell anyone more than the what, how and where descriptors because even these three were complex  (although the latter three questions who, when and why appeared in the supporting material).  In addition, the convergence of BSP and Systems Development Life Cycles (SDLC) emerged in the ‘Framework for Information Systems Architecture’. This Zachman ‘framework’ was first published by the IBM Systems Journal in 1987, (and according to IBM this is the most requested article in the history of the Systems Journal.)

The eighties also saw the rise of several significant analysis components for information systems requirements. The great partitioning techniques of structured analysis and the attempted cohesion approach of structured design, but integrated components didn’t really excel until entity relationship modeling appeared.  All of these were basically systems analysis tools. These converged into the discipline of Information Engineering created by Clive Finkelstein at Information Engineering Services Pty Ltd (IES) after leaving IBM in 1976.  Essentially, this work became the hands and feet (the methodology) of implementing systems.

By the time the second IBM Systems Journal article Extending and formalizing the framework for Information Systems Architecture was published in 1992, John Zachman’s co-author John Sowa proposed the additions of the Scope perspective of the ‘planner’ (bounding lists common to the enterprise and its environment) and the Detailed Representation perspective of the ‘sub-contractor’ (being the out of context vendor solution components). The Who, When and Why columns were brought into public view, the notion of the four levels of metaframeworks and a depiction of integration associations across the perspectives were all outlined in the paper. Keri Anderson Healey assisted by creating a model of the models (the framework metamodel) which was also included in the article.  Enterprises could now see that the structure of Enterprise Architecture was much more than building systems, and that there was a formal way to evaluate the enterprise specification, which had a significant amount of credible theory supporting the logic.

However, when the framework schema is only materialized in matrix form, it can be easily misinterpreted. Sorely misunderstood, for instance, is that the ‘framework’ is a top to bottom decomposition where each perspective continues the hierarchy details from above. The truth is that adding detail is a function of a cell not a column. Also misunderstood is that the columns are ordered as depicted. The truth is that the columns have no set order and the ‘order’ of enterprise examination is a methodology value judgment. Another misconception is that having all the class (cell) contents would somehow magically deliver a functioning enterprise.  This occurs because most folks have missed the other two associations outside the relationship association within cell which creates primitive models. These associations are: the integration associations between each cell and every other cell across the row; and the transformation associations down the column linking all the items in the cell above with the cell below.

The integration associations bind the various columnar answers together into a cohesive answer for the entire perspective.  The transformation associations ensure the alignment of one independent variable throughout the perspectives in order to explain, design and change the functioning enterprise. Again the matrix view of the framework schema does not readily allow us to see that any component in any one class (cell) can be related to any other component in the same row or column on a many to many association. These associations bring about the convergence of classification with the implementation methodologies.

As we moved through the nineties, methodologists like Finkelstein, for instance, recognized that having a piece of system design logic and subsequent implementations without having the definition of the business concepts as reflected in the motivation, inventory, transformation and organization would not ultimately match the desired business model with the implemented operations.  His professional practice was refocused on the top two framework rows which he labeled Enterprise Engineering and has one of the most successful methods for converging the business needs with information engineering implementation, and determining a logical build sequence of the pieces. 

At the same time others have tried to focus on simplistic hierarchical decomposition of the Scope lists purporting to be ‘doing’ Zachman Enterprise Architecture. These consultants have fundamentally missed the mark by failing to transform the scope items into the rich semantic vocabulary defining the business concepts and the business rules which so clearly elicit the system logic, and then subsequently making the technology transformation and component selections for an engineered functioning enterprise. Most didn’t even make provision in the plan for any of this to be accomplished.

So what are the convergences of these first eight years of the naughties? The framework has been subject to scrutiny and implementation by a large world wide linguistics enterprise who have been extremely helpful in our clarification of the framework terms. Even the casual observer would notice that all the adjective words (conceptual, logical, physical) have been removed from the framework labels in favor of noun modified noun labels giving it better defined deliverables and intersection set theory constructs.  The chosen terms are a move toward more a generic business language on the enterprise framework as shown in the diagram below. 

(Click the above Figure for a full-size, Landscape Zachman Enterprise Framework² for printing)

Each class (cell) has a name derived from the mass noun answer shown at the bottom of the column in the diagram. These column footer terms (see bottom) are inventory, process, network, organization, timing, and motivation while the perspective row names (on the left-hand side) are scope, business, system, technology, component and instance. The enterprise contributors (on the right-hand side) are strategists, executive leaders, architects, engineers, technicians and workers. Using these labels for intersection naming not only allows for the exact positioning of the cell in the logic structure but it removes the need to arbitrarily assign meaningless codes, of r2c4 for example, as cell locators.

In addition, the normative framework terms have been projected onto enterprise framework adding the background rigor of broader context to the enterprise terms, while at the same time refining the overall meaning and enforcing the original framework logic. The column footer terms are sets, transformations, nodes, groups, periods and reasons. The row models (on the left-hand side) are contexts, concepts, logic, physics, assemblies and classes. The methods outcomes are identification, definition, representation, specification, configuration and instantiation, moving down the perspective rows. The generic contributors (on the right-hand side) are theorists, owners, designers, builders, implementers and participants.

Much of the confusion and misinterpretation about what constitutes a perspective model (as a single row), a single variable model (a single column), a primitive model (a single cell) and a composite model (more than one cell) has been removed by the refined framework terms. For example the scope context for the enterprise is the integrated set of lists identifying the items from the environment that will be included in or excluded from the enterprise operations.  The business concepts defined by the semantic models connects all the terms by associations for each of the six primitive models integrated across the row and aligned by transformation from the identified scope boundary lists.  Similarly, the system logic represented in the schematics models describe all of the defined business concepts in terms of their characteristics, properties and attributes in a manner that allows the each item to be aligned with the business definition.

What we have learned is that the perspectives are not really ‘stakeholder’ models but rather models that are based on the second century (B.C.) Greek philosophers notion of ‘reification’. This is a set of steps which transforms an idea into something real. It begins with the identification (description) of the mental thought, then moves through a definition stage where instances of the ‘thing’ and the relationships with other ‘things’ prove existence.  Next the representation of the ‘thing’ as evidenced by finding attributes or properties. This gives a complete notion of the idea. (The reader will note these converge with the first three perspective rows in the framework). 

Following the idea formulation, one can now examine the numerous manifestations possible given the various general technologies each with different physics specification constraints.  Next, the specification can be supported by the use, buying, or building of  component assemblies which when configured will support the desired idea. Finally the reality is made complete by the creation of instances which now can be seen in the real world.   (The reader can now observe that the last three perspectives support the reality of the idea). This notion of reification has parallel patterns and is supported by the ideas of cognitive thinking, testing and examination.

I encourage you to download a copy of John Zachman’s Concise Definition of the Zachman Framework, register at no cost to have a look at the Enterprise Standards and above all see if you too can see the Enterprise Convergence in our Lifetime.