Framework Fundamentals: Miscellaneous Enterprise Engineering

John A.  Zachman
John A. Zachman Chief Executive Officer, Zachman International Read Author Bio || Read All Articles 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:

citations icon
John A. Zachman , "Framework Fundamentals: Miscellaneous Enterprise Engineering" Business Rules Journal Vol. 4, No. 6, (Jun. 2003)

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
 Jim  Sinur
 John A. Zachman
The Issue Is THE ENTERPRISE By John A. Zachman Jan. 2017 | Vol. 18, Iss. 1

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.