Subscribe to the FREE Business Rules Journal Newletter





Framework Fundamentals:  Miscellaneous Enterprise Engineering Concepts

by John A. Zachman

As the OMG's Business Rules Working Group was preparing its Request for Information (RFI) document, OMG management had questions for John Zachman about the nature and role of the Framework ~ in particular, its relationship to OMG initiatives.  This column presents John's response.


What follows are some questions -- asked over the course of the past several months -- that would be too hard to articulate as individual points.  Hopefully, the underlying questions will be apparent in my answers here.


First, some background. The Framework is a two dimensional classification scheme for descriptive representations of an Enterprise.  I discovered it by looking at the structure of descriptive representations of airplanes ... and we examined buildings, automobiles, battleships, and super computers as well.  I simply applied the same structure of product description artifacts to Enterprise descriptions.  It has nothing to do with systems analysis and design techniques or network architectures, other than the fact that some of the descriptive representations of the Enterprise may be produced over the process of employing stored programming devices and electronic media for implementation purposes.

I might observe that it is equally conceivable that descriptive representations could prove useful when using pencils, paper, and file cabinets as the implementation technology.  I also might observe that those are your two implementation options: pencils, paper, and file cabinets, or stored programming devices and electronic media.  The same Framework for descriptive representations could be used to describe the material handling and people moving technologies, but those technologies tend to be beyond our area of interest.  The technology constraints being employed in the implementation of the Enterprise -- whatever they are -- simply affect the content of the Cell models at Row 4 ... not the Framework itself.

Second, the Framework is a semantic structure and therefore does not imply anything about process.  Process is a methodology or tool issue ... and a meta issue.  Which Cell (or Cells) -- or which "sliver" of which Cell(s) -- and in what sequence they are produced ... this is all a function of the value system of the author of the methodology or tool.  The Framework is inert relative to methods/tools.

The reason why UML might not address Rows 1 or 2 models is probably because UML's origin was Row 5 and subsequently, Row 4.  I have a friend who quotes Grady Booch as saying, "We know how to do design; we don't know how to do analysis."  I cannot validate the quotation but, assuming it is somewhat accurate, I would interpret that to mean the object folks know how to do Row 4, not Row 3.  People tell me that there is some problem using UML to do Row 2 and I suspect that the underlying problem is that the metamodel of UML does not support the differentiation between Enterprise things (Row 2) and the logical representations of Enterprise things (Row 3).

Regarding "removing the wall between Data and Process" ... that also likely stems from the origin of the object community.  I suspect that their overiding value proposition was implementation, not architecture.  For implementation you need composite models (for example, data and process together) whereas for architecture, you want primitives (data and process separate).  Ultimately, you want both composites and primitives because you want to create the composites from the primitives.  If you are only creating composites on an ad hoc basis, then you have point-in-time solutions relative to a specific implementation ... and that's the heart of the "legacy" problem!

The end objective of architecture is to create an inventory of reusable assets, defined relative to the Enterprise -- not relative to a single implementation -- from which a wide variety of composites (objects) could be assembled to order, NOT created to order.

Regarding CMM ... clearly CMM is a process issue by its very definition.  I think the question it is addressing is:  how much formality and discipline exists in the application development process?  I suppose you could get some insight into the amount of formality and discipline there is in an application development process by assessing which slivers of which Cells of the Framework the process formally produces and manages. 

However, there is probably an even more profound question that could be exercised and that has to do with composites and primitives

  • If the application development process produces composites, it is likely a typical "job shop."  In other words, it is making custom products ... applications.  No engineering or manufacturing is being done until they get the order.

  • On the other hand, if the methodology is producing primitives, then it is likely that they are changing the fundamental concept of I/S to "mass customization."  They are creating architectural primitives relative to the Enterprise before they get the order for an application so that, when the order arrives, the time for implementation is reduced to only the time required to assemble the composite from the primitives.  The engineering has already been done.

Clearly, if you want to reduce the "time-to-market" for systems implementations and at the same time accommodate enormously-increased complexity in the Enterprise (for example, CRM), you have to have something in inventory that has been engineered to be assembled into more than one implementation before you get the order.  Clearly, CMM does not address that issue at all.  It is merely measuring the degree of formality and discipline in the process, whatever process is being employed.  On the other hand, if there is little formality in the process, the likelihood of realizing architectural approaches (mass customization) for the Enterprise I would judge to be low to zero.

I am very concerned about the gross misconceptions so many people have about my Framework (specifically) and about Enterprise Architecture (in general).  I have been doing two-day seminars regularly in the U.S., Europe, Asia, and Africa for over 10 years.  I have been attempting to write more extensively for the last several years and have written about 20 major articles during that time.  There are some highly knowledgeable Framework people with whom I have worked for over 20 years who are now doing extensive, more technical seminars about Enterprise Architecture and my Framework than I could possibly do.  I have finally finished writing "The Book."  I am not too sure what else I can do in the face of a growing body of 'experts' on the Zachman Framework who have never gone to my seminars nor read any of my materials.  At least, someone on the addressee list of this note had the presence of mind to ask ... which I do appreciate.

Thank you.

  John A. Zachman

standard citation for this article:
John A. Zachman, "Framework Fundamentals:  Miscellaneous Enterprise Engineering Concepts," Business Rules Journal, Vol. 4, No. 6, (June 2003), URL:

January 2017
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 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 ]