ARCHITECTURE ARTIFACTS vs APPLICATION DEVELOPMENT ARTIFACTS
John A. Zachman, March 2000
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!
are likely several reasons for the confusion.
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."
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.
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.
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.
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.
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.
essence of infrastructure is that it is something that is going to be used
more than one time.
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
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?"
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.
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
or interoperability, does not happen by accident. It is the result of
engineering. That is, reusability or interoperability has to be engineered at
occurs at the level of the primitive, not the composite.
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.
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.
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.
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
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?
(reuse) is engineered into the primitive components, not into the
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
will answer this question next time, with the first of three tests that can be
2000, Zachman International