Enterprise Architecture Artifacts vs. Application Development Artifacts (Part 1)

John A.  Zachman
John A. Zachman Chief Executive Officer, Zachman International Read Author Bio || Read All Articles by John A. Zachman

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

Standard citation for this article:

citations icon
John A. Zachman , "Enterprise Architecture Artifacts vs. Application Development Artifacts (Part 1)" Business Rules Journal Vol. 1, No. 3, (Mar. 2000)
URL: http://www.brcommunity.com/a2000/b003a.html

About our Contributor:

John  A. Zachman
John A. Zachman Chief Executive Officer, Zachman International

John A. Zachman is the originator of the "Framework for Enterprise Architecture" (The Zachman Framework™) which has received broad acceptance around the world as an integrative framework, an ontology for descriptive representations for Enterprises.

Mr. Zachman is not only known for this work on Enterprise Architecture, but is also known for his early contributions to IBM's Information Strategy methodology (Business Systems Planning) as well as to their Executive team planning techniques (Intensive Planning). He served IBM for 26 years, retiring in 1990 to devote his life to the science of Enterprise Architecture.

Mr. Zachman is the Founder and Chairman of his own education and consulting business, Zachman International®. He is also Founder of the Zachman Institute™, a nonprofit organization devoted to leveraging Zachman International's vast network of professionals and resources to offer services to small businesses and nonprofit organizations as they prepare for and experience growth.

Mr. Zachman serves on the Executive Council for Information Management and Technology (ECIMT) of the United States Government Accountability Office (GAO) and on the Advisory Board of the Data Administration Management Association International (DAMAI) from whom he was awarded the 2002 Lifetime Achievement Award. He was awarded the 2009 Enterprise Architecture Professional Lifetime Achievement Award from the Center for Advancement of the Enterprise Architecture Profession as well as the 2004 Oakland University, Applied Technology in Business (ATIB), Award for IS Excellence and Innovation.

Mr. Zachman has been focusing on Enterprise Architecture since 1970 and has written extensively on the subject. He has facilitated innumerable executive team planning sessions. He travels nationally and internationally, teaching and consulting, and is a popular conference speaker, known for his motivating messages on Enterprise Architecture issues. He has spoken to many thousands of enterprise managers and information professionals on every continent.

In addition to his professional activities, Mr. Zachman serves on the Elder Council of the Church on the Way (First Foursquare Church of Van Nuys, California), the Board of Directors of Living Way Ministries, a radio and television ministry of the Church on the Way, the President's Cabinet of The King's University, the Board of Directors of the Los Angeles Citywide Children's Christian Choir, the Board of Directors of Heavenworks, an international ministry to the French speaking world and on the Board of Directors of Native Hope International, a Los Angeles based ministry to the Native American people.

Prior to joining IBM, Mr. Zachman served as a line officer in the United States Navy and is a retired Commander in the U. S. Naval Reserve. He chaired a panel on "Planning, Development and Maintenance Tools and Methods Integration" for the U. S. National Institute of Standards and Technology. He holds a degree in Chemistry from Northwestern University, has taught at Tufts University, has served on the Board of Councilors for the School of Library and Information Management at the University of Southern California, as a Special Advisor to the School of Library and Information Management at Emporia State University, on the Advisory Council to the School of Library and Information Management at Dominican University and on the Advisory Board for the Data Resource Management Program at the University of Washington. He has been a Fellow for the College of Business Administration of the University of North Texas and currently is listed in Cambridge Who's Who.

Read All Articles by John A. Zachman
Subscribe to the eBRJ Newsletter
Enterprise Architecture Defined: (2) Complexity and Change
Enterprise Architecture Defined: (1) What is Architecture?
The Business Agility Manifesto — The Authors Speak Out Q&A with Roger T. Burlton, Ronald G. Ross, & John A. Zachman
Strategy Spectrum for Enterprise Engineering and Manufacturing
In The Spotlight

Online Interactive Training Series

In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.