Subscribe to the FREE Business Rules Journal Newletter


 

 

 

     ZACHMAN ARCHIVES ...
untitled

Framework Fundamentals:  Responding to Questions from the OMG

by John A. Zachman

As the OMG's Business Rules Working Group was preparing its Request for Information (RFI) document, the Group's members had questions for John Zachman about the nature and role of the Framework.  This column presents part of that exchange.

~editor           

QUESTION:

Does the Zachman Framework apply only to design artifacts produced during the software development process, or do "design artifacts" apply to any and all architecture and engineering artifacts produced in the enterprise, including operational systems?

Who uses the Framework -- Enterprise Architects, Software Architects, both? That is, who creates the design artifacts and to what purpose?

MY RESPONSE:

The Framework is a classification structure for descriptive representations of an object, any object.  Since I am interested in Enterprises, I have enterprise names on the descriptive representations.  The descriptive representations can be used by anyone -- or everyone -- who is interested in the Enterprise and who is authorized to have access to the descriptions.

The creators of the artifacts are those who are "subject matter experts" relative to the artifact being created, probably limited to those experts who are authorized to create them, as assisted by experts trained in the concept transcription and design techniques.  For example, if I was the Owner of a building that I wanted built, I would define what I had in mind as to the building (Rows 1 and 2), but I would hire an Architect to transcribe it so I could recognize and approve it.  And, since it was being produced by an Architect, I would have a warm feeling that it was structurally sound for use by other participants in the process.

Furthermore, the Framework is neutral relative to Organization structure, that is, if I was the CEO and I wanted to write some programs (Row 5, Column 2), I would write some programs.  On the other hand, if I was a programmer, I may be constrained to only writing programs (Row 5, Column 2) based on the criteria that are found in the cell above (Row 4, Column 2) and constrained to reusing the data element specifications found in Row 5, Column 1.

Regarding the purpose of the artifacts ...

  • The purpose of the Row 1 artifacts is to define the boundaries of the Enterprise, what is being included (and conceivably, what is being excluded, should that be relevant or necessary).
     
  • The purpose of Row 2 artifacts is to define conceptually what the Enterprise "Owners" have in mind.
     
  • The purpose of Row 3 artifacts is to design how the Enterprise concepts will be realized systematically, quite independently of any technologies.
     
  • The purpose of the Row 4 artifacts is to define the Enterprise implementation based on the general technology constraints being employed.
     
  • The purpose of Row 5 artifacts is to specify the implementations to specific technology products being used for implementation.

Whether the descriptive representations are used for software or non-software implementations is dependent upon the technology constraints applied in the Row 4 models.  For example, if the technologies being employed are pencils, paper, and file cabinets, the implementation will likely be called a 'manual system.'

Quoting from my article, "The Framework for Enterprise Architecture:  Background, Description, and Utility":

The Framework as it applies to Enterprises is simply a logical structure for classifying and organizing the descriptive representations of an Enterprise that are significant to the management of the Enterprise as well as to the development of the Enterprise's systems.  It was derived from analogous structures that are found in the older disciplines of Architecture/Construction and Engineering/Manufacturing that classify and organize the design artifacts created over the process of designing and producing complex physical products (e.g., buildings or airplanes.)

The older disciplines of Architecture and Manufacturing have accumulated considerable bodies of product knowledge through disciplined management of the "product definition" design artifacts.  This has enabled enormous increases in product sophistication and the ability to manage high rates of product change over time.  Similarly, disciplined production and management of "Enterprise definition" (e.g., the set of models identified in the Framework for Enterprise Architecture) should provide for an accumulation of a body of Enterprise knowledge to facilitate enormous increases in Enterprise sophistication and accommodation of high rates of Enterprise change over time.

QUESTION:

Would you comment on the following points:

  1. An Enterprise (System) is defined (specified) by the complete set of models.
     
  2. These sets are classified and then organized in the Framework.
     
  3. Enterprise Subsystems (e.g., Business Rule Systems, Ontological Systems, Financial Systems, Middleware Systems, Process/Workflow Systems, etc., etc.) are defined by a subset of these models, and these subsystems define, in part, the Enterprise System.
     
  4. These models can represent the current state of the Enterprise on the one hand, and the future state on the other, given that a subset can be parsed for development, and new models can be created.
     
  5. New development can utilize the classification and organization scheme as well as reuse already existing models.  Likewise, there may be a subset that represents a future state of the enterprise without regard to development.
     
  6. The models are as much about the operational side of the enterprise as the development side.

Do these statements accurately reflect the intent for the use of the Framework?  To the degree that they do not, are they consistent with the intent?  In other words, would application of the Framework based on the above, violate the intent for use of the Framework or principles of Enterprise Architecture?


HERE ARE MY RESPONSES:

1. An Enterprise (System) is defined (specified) by the complete set of models.

An Enterprise system could be manual or automated.  In either case, the system creators may or may not build any models. 

Any models that are defined by the Framework that are not made explicit are implicit ... that is, the system creators are making assumptions about them.  In fact, any "slivers" (portions) of models that are not made explicit are implicit ... that is, assumptions are being made.

2. These sets are classified and then organized in the Framework.

The Framework is simply a classification scheme ... like the periodic table, it hypothesizes the existence of all of the primitive elements.  Any one primitive element that is not being made explicit is just not being made explicit.  It is implicit.

Also, any model that is produced can be classified by the Framework.  Since, historically, we were driven to implementation as the principle value proposition, we didn't have time or money to produce primitive models from which to create the composite models we needed for implementation.  Therefore, most models that have been produced over the last 50 years tend to be composite models. 

That is, the compounds existed before we understood the periodic table. You need the periodic table to turn the alchemy of systems development into a science of Enterprise Architecture (chemistry).

3. Enterprise Subsystems (e.g., Business Rule Systems, Ontological Systems, Financial Systems, Middleware Systems, Process/Workflow Systems, etc., etc.) are defined by a subset of these models, and these subsystems define, in part, the Enterprise System.

The "Enterprise Subsystems" (above) are implementations.  The question is, were they created from primitive, architectural models -- or were they simply created as composite models, ad hoc for a specific implementation?

If they were created ad hoc for a specific implementation, the probability of their being reused is low to zero.  If they were created from primitives that were defined relative to the Enterprise (not relative to a specific implementation), the probably of assembling many compounds from the same set of primitives is very high.  In this case, you would be "mass customizing" the Enterprise.

4. These models can represent the current state of the Enterprise on the one hand, and the future state on the other, given that a subset can be parsed for development, and new models can be created.

It is conceivable that you could have an "as is" Framework of primitives and a "to be" Framework of primitives ... It is more likely that you have an "as is" set of horizontal relationships between the primitives and a "to be" set of horizontal relationship between the primitives.

It is my opinion that if you define the primitives relative to the Enterprise, they likely do not change appreciably as long as you stay in the same business.  If you get out of airplane manufacturing and get into massage parlors (or something), then your primitive models are going to change.  As long as you stay in airplane manufacturing, the primitives probably won't change appreciably.

Now, having said that, nothing is exempt from change ... and clearly, as your Enterprise Architects gain experience, they are likely to learn more and improve their primitive modeling ability and therefore, their primitive models.  If they change the primitive models, however, they will likely have some scrap and rework on their hands.  That scrap and rework will be minimal as compared to the scrap and rework they would have if they only had composite models.  In the composite case, they are into throwing the whole thing out and starting over again.

5. New development can utilize the classification and organization scheme as well as reuse already existing models.  Likewise, there may be a subset that represents a future state of the enterprise without regard to development.

The periodic table exists whether you are analyzing existing compounds to discern their composition (reverse engineering) or trying to create new compounds (new development) or whether you are just trying to do pure research on the elements themselves (learn about Enterprises and/or Enterprise Architecture).

6. The models are as much about the operational side of the enterprise as the development side.

Implicit in the operating Enterprise are all of the primitive models ... it is only a question of whether you make them explicit or not.  Making them explicit enables you to remove the erroneous assumptions (defects), reconcile dissonant perceptions (entropy), or engineer improvements (change).  It is unlikely that you are going to be able to remove defects, reduce entropy, or change the Enterprise appreciably without somehow or other building primitive models.  Clearly, writing more code is not going to fix the problem.

I hope this is helpful.

Regards,

  John A. Zachman


standard citation for this article:
John A. Zachman, "Framework Fundamentals:  Responding to Questions from the OMG," Business Rules Journal, Vol. 4, No. 2, (February 2003), URL:  http://www.BRCommunity.com/a2003/b120.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 ]