Subscribe to the FREE Business Rules Journal Newletter


 

 

 

     ZACHMAN ARCHIVES ...
untitled

Fatal Distractions (part 2)

by John A. Zachman

In the first part of this article, I presented the first three of four corruptions of architectural principles being inadvertently executed by well-meaning folks, who are think they are doing "Enterprise Architecture" using the Zachman Framework.   To recap from part 1, these are the first three:

1. First, they are renaming the Rows or Columns of the Framework in an effort to accommodate the current inventory of artifacts created during the Industrial Age.

2. Second, they are taking model-based approaches to implementations and presuming that the models constitute the Enterprise Architecture.

3. Third, they are "integrating" Frameworks by a process of aggregation.

In this concluding part I will cover the fourth:

4. Fourth, they are separating the services of the Enterprise on the basis that the Service is the equivalent of a Product.

Together, these are the "Fatal Distractions"!

Architects' Frameworks and Service Frameworks

Here is the fourth problem.

There are two (and only 2) possible relationships between Frameworks that exist within an Enterprise.   Either the metamodels are the same (in which case, they are "Peer" Frameworks), or the metamodels are different (in which case they are "Meta" Frameworks).

Within an Enterprise (or within an Enterprise Cluster) if two Frameworks have the same metamodel, then they are candidates for integration.   That is, it is extremely likely that there are at least some components of the primitive models of those two Business Units' Frameworks that can be shared between them.   That is, between them, you can leverage reusability, integration, interoperability, integration, etc. to their advantage.

On the other hand, if the metamodels of two Frameworks within the same Enterprise are different, the high probability is that the Row 2 models of one of the Frameworks have a meta relationship with all the Cells of the other Framework.   For example, one Framework may be the set of descriptive representations for the Product of the Enterprise and the other may be the set of descriptive representations for the Enterprise itself -- in which case the Row 2 models of the Enterprise Framework are going to be models of the models of the Product Framework (metamodels), because the Enterprise is manufacturing the Product and has to produce the Product Framework full of models in the process of manufacturing it.

For example, Figure 1 shows a sample lists of things you would expect to find in the Row 2 models of a Product Framework.

Figure 1. Sample lists of things you would expect to find in Row 2 Models of a Product Framework

Figure 2 is a sample list of things you would expect to find in a metamodel of the Row 2 models of a Product Framework.

Figure 2. Sample (partial) list of things you would expect to find in a metamodel of Row 2 Models of a Product Framework

Figure 3 is a sample of lists of things you would expect to find in the Row 2 models of an Enterprise Framework.

Figure 3. Sample lists of things you would expect to find in Row 2 Models of an Enterprise Framework

Figure 4 is a sample list of things you would expect to find in a metamodel of the Row 2 models of an Enterprise Framework.

Figure 4. Sample (partial) list of things you would expect to find in a metamodel of Row 2 Models of an Enterprise Framework

The metamodel of the Enterprise Framework (Figure 4) is DIFFERENT from the metamodel of the Product Framework. (See Figure 5.)

Figure 5. The metamodel of the Enterprise Framework is DIFFERENT from the metamodel of the Product Framework

The Column 1, Row 2 model of the Enterprise Framework is the metamodel of the Product Framework (see Figure 2 and Figure 3) because in order to manufacture the Product, the Enterprise has to define the standard manner in which to express each of the Cells of the Product Framework.   The Customer of the Enterprise (the "Owner" of the Product) will play a very significant part in specifying the CONTENTS of each of the Row 2 Cells for the Product, but the Enterprise will specify the format and structure, the METAMODEL of the Cells.   That is, the CUSTOMER will play a very significant part in defining the CONTENTS of the Row 2 Cells of the Product Framework IF the Enterprise intends to sell very many of the products to the customer!

It is the CUSTOMER that defines the CONTENTS.   It is the ENTERPRISE that defines the METAMODEL.   The Customer doesn't really care about the metamodel except that the Enterprise defined it and that they knew what they were doing when they defined it, that is, that they were a competent manufacturer.

When the metamodels of two Frameworks in any one Enterprise are DIFFERENT, it is likely that they have a meta relationship with one another and it does not make any sense to try to "integrate" them.   There is nothing in one Framework that is sharable with the other Framework the metamodels are different.   It is like one Framework is describing apples and the other Framework is describing oranges.   If you put them together you DON'T have cantaloupes.   You just have apples and oranges together.   They are simply different.

For example, you would not expect to find splines and curves and tangents (the geometry of the product) in the database of locations like Los Angeles, Seattle, and St Louis (the geometry of the Enterprise).   There is no logical relationship.   That is why you don't find the databases of CAD, CAM, and CAE applications integrated with the databases of Payroll, General Ledger, and Sales Analysis.   There is nothing sharable.   In fact, if you did try to integrate those two different kinds of databases (apples and oranges) you would have such complexity and performance and maintenance (etc.) problems, they would be unmanageable and un-maintainable!

Just like the metamodel of the Product Framework is the Column 1, Row 2 model of the Enterprise Framework, so is the metamodel of the Enterprise Framework the Column 1, Row 2 model of an Enterprise that is engineering and manufacturing THE Enterprise.   Now who is the Enterprise that is engineering and manufacturing your Enterprise (THE Enterprise) for you??

This may be very disconcerting for you, but I would suggest that, BY DEFAULT, the INFORMATION SYSTEMS people in your Enterprise are engineering and manufacturing your Enterprise for you!!

Are YOU engineering and manufacturing your Enterprise?   (Probably not.)   Are you even making yourself available to I/S as their CUSTOMER to define the contents of the Row 2 models of YOUR Enterprise Framework?   (Probably not again!)   If you, the CUSTOMER, the OWNER of THE Enterprise is not significantly involved in defining the CONTENTS of the Row 2 models of THE Enterprise Framework, how do you expect the people who are engineering and manufacturing your Enterprise for you to produce an Enterprise that is "aligned" with your requirements or expectations?

Let me take a little emotion out of this discussion.

Let's not call the Framework for the Enterprise that is engineering and manufacturing THE Enterprise, the "I/S Framework."   Let's call it something neutral like the "Architect's Framework," or the "Enterprise Architect's Framework," or simply the "Enterprise Engineering and Manufacturing Framework."

Actually, I don't care what you call it.   Any way you look at it, it is the Framework whose Row 2 models are "meta" relative to THE Enterprise Framework because somebody has to define what those models are going to look like in order to build them.   When I say "Enterprise Framework," I mean the "Business Unit Frameworks" and/or the "Cluster Frameworks" and/or the "Enterprise Framework" because all of those Frameworks have the SAME METAMODEL.   They are PEER Frameworks.

You will not find things that are sharable between any one enterprise Framework and its Meta-Framework.   The "Architect's (meta) Framework" will NOT contain a "library" of components that are sharable (or reusable) in the Business Unit, Cluster, or Enterprise Frameworks.   The "Architect's (meta) Framework" WILL contain a library of standard FORMATS and STRUCTURES (metamodels) (NOT standard CONTENTS) for each cell of a "peer" Framework within the Enterprise.

Sharable CONTENT components will be found in the "Cluster Frameworks" or the "Enterprise Framework" (the "Sameness Templates"), if the engineering for reuse has been accomplished.

The CONTENTS of the Enterprise Frameworks should be being dictated by the CUSTOMER, that is, the OWNER of the Enterprise.   The OWNER could defer to the Architect to decide the best way to EXPRESS a coherent model of the Things of the Enterprise (a Semantic Model), or a model of the Business Processes of the Enterprise (a Business Process Model), etc., etc., etc., but (the Owner would) be vitally interested in the CONTENTS of the Semantic Model, the Business Process Model, etc., etc., etc.

Similarly, the Owner of an Airplane would likely defer to the Airplane Manufacturer's Engineers (Architects) to decide the best way to express coherent Drawings or Functional Specs of the Airplane, etc., etc., although the Owner will be vitally interested in the CONTENTS of the Drawings, Functional Specs, etc., etc.

Now, here is the problem:   There are some folks that would like to use the "Zachman Framework" to describe the Services of an Enterprise on the basis that they are the equivalent of the Product and therefore different from the Enterprise and therefore should have their own Framework.

Figure 6 shows a sample list of things you would expect to find in the Row 2 models of a Service Framework.

Figure 6. Sample lists of things you would expect to find in Row 2 Models of a Service Framework

Figure 7 is a sample list of things you would expect to find in a metamodel of the Row 2 models of a Service Framework.

Figure 7. Sample list of things you would expect to find in a metamodel of Row 2 Models of a Service Framework

The metamodel of the Service Framework (Figure 7) is THE SAME as the metamodel of the Enterprise Framework. (See Figure 8.)

Figure 8. The metamodel of the Service Framework is THE SAME from the metamodel of the Enterprise Framework

Since the Service Framework metamodel is the SAME as the Enterprise (Cluster and/or Business Unit) metamodel, they are PEER Frameworks.

There is abundant advantage to be realized from integration, sharing, normalization, standard interchangeable parts, etc.   In fact, it becomes obvious that the Services are simply the Customer's (e.g. Citizen's) "view" of the Enterprise.   The Service is THE SAME as the Enterprise.

The Product is NOT the same as the Enterprise.   The Product exists independently from the Enterprise.   If, after the Product is manufactured, the Enterprise goes out of business, the Product still exists.

The Service is the same as the Enterprise.   The Service only exists as the Enterprise exists. If the Enterprise goes out of business, the Service doesn't exist. The Service is simply the customer's view of the Enterprise.

If you separate the Services out from the Enterprise and treat them as META Frameworks, you are going to DIS-integrate the Services from the Enterprise.   That is, you will build "stovepipes" around the Services and we are right back where we started from again focused on implementation overlooking integration not doing Architecture just building more legacy.

I probably don't have to remind you where this leads but, it is only a matter of time again before the Enterprise wakes up and says something like, "Well, Enterprise Architecture the Zachman Framework that didn't work!!   All we have is more of the same legacy!!"

In Conclusion

In conclusion, here are my recommendations for you:

  1. Don't rename anything in the Framework unless you have a lot of time to sit around and think about Theology and Philosophy and stuff like that.   Just take the Framework on faith and use it like it is.   You will be a lot safer.
  2. Start working on primitive models you probably have a lot to learn, and every day you put it off is just one more day before the Enterprise starts building up an inventory of primitive components it needs to survive the Information Age.
  3. Don't set your expectations about integration (reuse, normalization, sharing, commonalities, etc.) out of line with reality. Integration is the result of engineering.   If no primitive models are being engineered, there is no integration and therefore, no "Architecture."
  4. There are two and only two relationships between Frameworks:   Peer Frameworks and Meta Frameworks.   Where the metamodels are different, don't try to integrate them.   Where the Framework metamodels are the same (and in the same Enterprise), don't disintegrate them.
  5. Go back and read footnote number 6 in Part 1.

Anyone who would recommend differently is not necessarily a bad person, just a little mis-guided for the Information Age. They would be demonstrating their Industrial Age heritage, where the motivation was for implementation (not integration); point-in-time solutions (not reuse); short term (not long term); applications (not Architecture).

For goodness sakes don't let yourself get fatally distracted!!

If you're just going to go for implementation, then don't say (or even think) you are doing Architecture.   And, if I were you, neither would I tell management I was doing Architecture (long-term) things when I was actually doing systems design (short-term, implementation) things!!

It's okay to do short term things just don't expect long-term results!!   In that case, you'd better say something like: "we are building more legacy we're building it as fast as we can but, we'll have to pay the price (scrap and re-work the new legacy, just like we are having to scrap and re-work the old legacy right now) at some point later!!"   Otherwise, you are going to put yourself in the awkward position of being a fatality from the latest (and greatest) Silver Bullet!   And that Silver Bullet it is going to look a lot like Enterprise Architecture or the Zachman Framework!!

Then, it will be another 10 years before you will be allowed to try it again if the Enterprise can remain viable for 10 years in the meantime!!

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 ]