Subscribe to the FREE Business Rules Journal Newletter


 

 

 

     ZACHMAN ARCHIVES ...

ENTERPRISE ARCHITECTURE ARTIFACTS vs APPLICATION DEVELOPMENT ARTIFACTS

By John A. Zachman, March 2000

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

January 2017
The Issue Is THE ENTERPRISE
By John A. Zachman


October 2016
Strategy Spectrum for Enterprise Engineering and Manufacturing
By John A. Zachman


July 2016
The New EA Paradigm
(4) The Assemble-to-Order Pattern

By John A. Zachman


June 2016
The New EA Paradigm
(3) The Provide-from-Stock Pattern

By John A. Zachman


May 2016
The New EA Paradigm
(2) The Make-to-Order Pattern

By John A. Zachman


April 2016
The New EA Paradigm
(1) Expenses and Assets

By John A. Zachman


March 2016
The Information Age: (3) Powershift
By John A. Zachman


February 2016
The Information Age: (2) The Third Wave
By John A. Zachman


January 2016
The Information Age: (1) Future Shock
By John A. Zachman


December 2015
Defining Enterprise Architecture: Economics and the Role of I.T.
By John A. Zachman


November 2015
Enterprise Physics 101
By John A. Zachman


September 2015
A Historical Look at Enterprise Architecture with John Zachman
By John A. Zachman


August 2015
Cloud Computing and Enterprise Architecture
By John A. Zachman


June 2015
The Zachman Framework Evolution (Part 2)
Special Guest: John P. Zachman


May 2015
The Zachman Framework Evolution (Part 1)
Special Guest: John P. Zachman


April 2015
Architecture is Architecture is Architecture
By John A. Zachman


April 2013
John Zachman's Concise Definition of The Zachman Framework
By John A. Zachman


November 2004
The Zachman Framework and Observations on Methodologies

 

November 2003

Framework Fundamentals: Frameworks, Reference Models, and Matrices

 

August 2003

Framework Fundamentals: A Dialog With John Zachman

 

June 2003

Framework Fundamentals: Miscellaneous Enterprise Engineering Concepts

 

April 2003

Framework Fundamentals: Framework Fundamentals: Level of Detail is a Function of a CELL

 

February 2003

Framework Fundamentals: Responding to Questions from the OMG

 

May 2002

Enterprise Quantum Mechanics (Part 2)

 

March 2002

Enterprise Quantum Mechanics (Part 1)

 

January 2002

"What" Versus "What"

 

November 2001

Security And The "Zachman Framework"

 

September 2001

Fatal Distractions (Part 2)

 

July 2001

Fatal Distractions (Part 1)

 

May 2001

You Can't "Cost-Justify" Architecture

 

March 2001

Conceptual, Logical, Physical: It Is Simple (Part 2 of 2)

 

January 2001

Conceptual, Logical, Physical: It Is Simple (Part 1 of 2)

 

September 2000

Building The Enterprise - An Infusion Of Honesty

 

July 2000

All the Reasons Why You Can't Do Architecture or ("We Has Met the Enemy and He Is Us")

 

May 2000

Enterprise Architecture Artifacts vs Application Development Artifacts (Part 2)

 

March 2000

Enterprise Architecture Artifacts vs Application Development Artifacts (Part 1)

 

November/December 1999 & January/February 2000

Enterprise Architecture: Issues, Ingibitors, and Incentives


July/August & September/October 1999

Packages Don't Let You Off The Hook

By John A. Zachman


January/February & March/April 1999

Life Is a Series of Trade-Offs and Change Is Accelerating!


November/December 1998

"Yes Virginia, There IS an Enterprise Architecture"


July/August 1998

Enterprise Architecture: Looking Back and Looking Ahead


January/February 1998

The Framework for Enterprise Architecture (The 'Zachman Framework') and the Search for the Owner's View of Business Rules

 

 

 about . . .

 JOHN A. ZACHMAN

 

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).

Mr. Zachman retired from IBM in 1990, having served them for 26 years. He is Chief Executive Officer of his own education and consulting business, Zachman International®.

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 (DAMA-I) 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.  In August 2011,  he was awarded the Gen. Colin Powell Public Sector Image Award by the Armed Services Alliance Program.

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 College 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 Managementat Emporia State University, on the Advisory Council to the School of Library and Information Managementat Dominican University and on the Advisory Board for the Data Resource Management Programat 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.

 

 

 

[ Home ] [ Staff ] [ About BRC Publications ] [ Editorial Feedback ] [ About BRCommunity ]
[ Contributor's Guidelines ] [ Privacy Policy ]