All of a sudden, I have been encountering a lot of confusion between Enterprise Architecture and classic Application Development Work Products, probably because the stark reality of the Information Age is upon us!

There are likely several reasons for the confusion.

One thing is, historically, in the Industrial Age, we have not been very precise about the definition of "Enterprise Architecture." To some people, Architecture is simply a high level description (model) of the system to be built. To others, Architecture is conceptual or logical as opposed to physical. To others, Architecture is "requirements" and to others, Architecture is simply "principles."

Probably the most confusing factor is that some of the work products (models) themselves that may be produced over the process of building traditional applications systems may actually look like architectural representations and it is hard to tell the difference.

Based on the Framework for Enterprise Architecture, I would suggest that Enterprise Architecture is the set of primitive, descriptive artifacts that constitute the knowledge infrastructure of the Enterprise. It is purely structural.

I would further suggest that ultimately, the Enterprise will require that these artifacts must necessarily be graphically presented because at the point in time when you will need the artifacts, you won't have time to read through a thousand pages of text to attempt to discern their implications. I am confident that at some point in time, the Enterprise is going to wish it had all of those design artifacts (models, cells of the "Zachman Framework," the Framework for Enterprise Architecture) made explicit, horizontally and vertically integrated at excruciating levels of detail because these models have everything to do with managing complexity and high rates of change, as those of you who have heard me talk, have heard the strength and force of that argument.

Now at any given point in time, this total set of models may or may not be perfectly conceived or may or may not be complete or defined to an excruciating level of detail. However complete or incomplete they might be, to qualify for being called Enterprise Architecture, they must, by definition, be descriptive of the Enterprise, not merely descriptive of an implementation within the Enterprise.

Since the models, in their aggregate, would be descriptive of the Enterprise in its entirety, they could be recombined for any (or many) implementations within the Enterprise. This is the reason they could be called "infrastructure." They are defined (or designed) for reuse, or interoperability in their creation.

The essence of infrastructure is that it is something that is going to be used more than one time.

In contrast, Application Development Work Products are created as inputs or outputs for the application development process. They are created for implementation purposes. They are process-specified. They are created at and for a given point in time. They constitute the actual work products for building systems.

The basic question is, "are these application development work products being derived from architectural primitives that were designed with the entire Enterprise in mind, or are they being created to specifically serve the implementation process at hand?"

If they (the work products) are being created for a specific implementation, the likelihood of their being interoperable or being reusable in subsequent implementations is low to zero, and the probability of changing them with minimum time, disruption, and cost is low to zero as well.

On the other hand, if the work products have been derived from architectural primitives, they are simply one temporal manifestation, that is one combination, or one composition (out of a virtually infinite number of manifestations, or combinations, or compositions) possible from the primitives.

Reuse, or interoperability, does not happen by accident. It is the result of engineering. That is, reusability or interoperability has to be engineered at the outset.

It occurs at the level of the primitive, not the composite.

It is extremely unlikely that something that is already built (composed, assembled) is going to be able to be reused or interoperable in a different context, even within the same Enterprise. This is so easy to see in physical objects, but we seem to have a great deal of difficulty envisioning this limitation for intangible objects like Enterprises.

No one would even dream of being able to manufacture a bunch of carburetors and then expect to attach them at random to any Ford, or any Chrysler, or any Buick, or any Toyota engine, or any whatever.

No. A carburetor has to be engineered to fit on a specific Ford engine in a specific Ford automobile. If you want the carburetor to fit on more than one Ford engine, it has to be engineered that way in the first place. After you get the carburetor built, if you haven't anticipated "reusing" it in other "applications," that is, if you haven't engineered it for multiple uses in the first place, there is not much you can do to make it fit on any different engine, short of throwing it (and/or the engine) away and starting over again.

Why would someone think that data, for example, is any different than carburetors? If data is designed to be used only with a specific process, why would one think it is going to be able to be interoperable (reused) with a different process?

To generalize a little further, if data, or function, or distribution, or presentation, or event/cycles, or business rules (each of which represents one of the six columns of the Framework) are designed to be used in a given implementation, why would one think that they could be interoperable (reused) in different implementations?

Interoperability (reuse) is engineered into the primitive components, not into the implementation.

This issue is at the heart of the confusion between Enterprise Architecture and Application Development work products. How can you tell by looking at a model whether it is Enterprise Architecture -- engineered to be used in more than one context -- or whether it is a work product being used for one specific implementation?

I will answer this question next time, with the first of three tests that can be applied. 

... continued

© 2000, Zachman International