Subscribe to the FREE Business Rules Journal Newletter


 

 

 

     ZACHMAN ARCHIVES ...
untitled

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

by John A. Zachman

As the OMG's Business Rules Working Group was preparing its Request for Information (RFI) document, the group's members discussed how the Framework related to this work. And, sometimes, the exchanges were not quite 'on the mark.' This column presents part of one exchange, where John stepped in to set the record straight on this often-misunderstood point.

~editor           

I was sent an email that contained the following TOTALLY INCORRECT assumptions about the Framework:

..."higher rows of ZF differ from lower ones largely by abstraction, by suppressing detail.  In other words, rows are not different viewpoints (electrical, plumbing) (functional, non-functional) of same problem domain.  ROWS [are] increasing greater level of detail as required by various observers or listeners to a story.  Some observers require only a very high level of detail, while some require an in-depth, technical description of the story."

Once again, THE ABOVE IS TOTALLY INCORRECT!

HERE IS MY RESPONSE:


'Level of detail' is a function of the Cell, NOT of the Column.  In any one Cell, you could have a high level of detail (that is, little detail), a medium level of detail, or an excruciating level of detail.  Anyone who has EVER heard me talk has heard me say that ... "excruciating level of detail" is related to a Cell.  What is making the Rows different is NOT more detail.

The Rows are different, that is, different models occur in every Row within any one Column.  It is just like in classic building architecture ...

  • Row 2 is expressing the usage constraints of the end result as expressed by the "Owner" of the end result, e.g., the Architect's Drawings.
     
  • Row 3 is expressing the constraints of the laws of nature as addressed by an Architect (or "Designer"), e.g., the Architect's Plans.  (In the Enterprise domain, this would be the expression of the logical, systematic manner in which the conceptual requirements of the Owner might be effected.)
     
  • Row 4 expresses the constraints of the Builder in terms of the construction process and machine tool technologies being employed, e.g., the Contractor's Plans.
     
  • Row 5 expresses the "Sub-Contractor's" tool-specific constraints (out-of-context constraints).
     
  • Row 1 is the "universe of discourse" relative to the analytical target.  In the case of Enterprises, out of the total universe of Things, Processes, Locations, Organizations, Cycles, and Objectives, what is the subset relevant to this Enterprise that they are willing to put forth effort to manage?

Row 2, Row 3, and Row 4 are equivalent of Conceptual, Logical, and Physical, where:

    • Conceptual is what the Owners have in mind as to what their Enterprise is or what they want it to be.
    • Logical is the systematic expression of how the Owner's intent could be logically realized.
    • Physical is the technology-constrained representation for implementation purposes.

Conceptual, Logical, Physical -- this is the equivalent of:

  • the Work Breakdown Structure/Product Structure (Row 2),
  • the Engineering Bill-of-Materials (Row 3), and
  • the Manufacturing Engineering Bill-of-Materials (Row 4). 

In other words, they are DIFFERENT ... NOT increasing levels of detail, because they are expressing different constraints.

In Column 1, for example, Row 2 is a model of the actual Things of the Enterprise that the Owners care enough about to manage.  Row 3 is a model of the logical representations of the things of the Enterprise, which are DIFFERENT than the actual things because the "Designer" is trying to figure out how to keep track of the information (the filing system) needed to take inventories of all the Things of the Enterprise when the Owners need to know how many things there are or whether they are all present or not.  Row 4 is a model of the technology manifestations of the Things, which are DIFFERENT that the logical representations of Things and DIFFERENT from the Things themselves, because the "Builder" is trying to figure out where to put the actual data about the things, which is going to take up space on some device and you want to make sure the same data is in the same place every time you send an arm in to grab it off of the disk (or whatever you are storing it on) and you don't want to wait for long periods of time while looking for the data.

This is REALLY important ... because you are trying to do different things with each different model.  The models are RELATED to one another, but they are not the SAME model just in increasing levels of detail. 

Any one Row model has to support the intent of the next higher Row or else you are going to have a quality problem.  If the intent of any one Row is NOT supported by the next lower Row, when you get down to Row 6, the Row 6 implementation is not going to be "aligned" with the intent of the Owners of the Enterprise at Row 1/2.

Conceptual is like the card catalog in the library; Logical is like the Dewey Decimal System; and Physical is the shelf allocation for the books.  Similarly, Conceptual is like the subject matter index, Logical is the file folder identification, and Physical is the location of the file folders in the file cabinets.  Row 2 is the Architect's Drawings, Row 3 is the Architect's Plans, and Row 4 is the Contractor's Plans.  Row 2 is the Customer's requirements, Row 3 is the Engineering Design, and Row 4 is the Manufacturing Engineering Design.

Why is it that those of us in the Data Processing Department are having so much trouble with this idea???  The Library people, the Document Management people, the Architecture and Construction people, and the Engineering and Manufacturing people don't seem to have any trouble with this at all!!


I hope this is helpful.

Regards,

  John A. Zachman

standard citation for this article:
John A. Zachman, "Framework Fundamentals:  Level of Detail is a Function of a CELL," Business Rules Journal, Vol. 4, No. 4, (April 2003), URL:  http://www.BRCommunity.com/a2003/b134.html.

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 ]