Subscribe to the FREE Business Rules Journal Newletter


 

 

 

     ZACHMAN ARCHIVES ...
untitled

ENTERPRISE ARCHITECTURE ARTIFACTS vs. APPLICATION DEVELOPMENT ARTIFACTS (part 2)

By John A. Zachman, May 2000

In the first installment of this article, I asserted that...

  • The essence of infrastructure is that it is something that is going to be used more than one time.
  • Reuse (or interoperability) occurs at the level of the primitive, not the composite.
  • Interoperability is engineered into the primitive components, not into the implementation.

And I posed the following question:

"How can you tell by looking at a model whether it is Enterprise Architecture, engineered to be used in more than one context,

or whether it is a work product being used for one specific implementation?"

In this installment, I provide some tests can help us answer this question.

The First Test

The first test might be,

"Is it a single variable model (primitive, all components occurring within a single cell of the Framework),

or is it a composite, multi-variable model (comprised of components from more than one cell of the Framework)?"

A single variable model would basically be:

 

a model of THINGS

 

  Thing -- Relationship -- Thing (e.g. a "semantic" model).
 

Or,

a model of PROCESSES

 

  Input -- Process -- Output. (e.g. a "transformation" model).
 

Or,

a model of LOCATIONS

 

  Node -- Line -- Node (e.g. a "connectivity" or "network" model).
 

Or,

a model of PEOPLE

 

  People -- Work -- People (e.g. a "work flow" model).
 

Or,

a model of TIME

 

  Event -- Cycle -- Event (e.g. a "dynamics" model).
 

Or,

a model of MOTIVATION

 

  Ends -- Means -- Ends (e.g. a "business rules" model).
 

A composite model would be a model that includes several primitives in the same model, for example, it might include some data being transmitted down some lines connecting to some points which include some processes updating some files, etc., etc, that is:

Some THINGS
  transformed by some PROCESSES
    in some LOCATIONS
      by some PEOPLE
        at some TIME
          for some REASONS.

(Content from more than one column of the Framework in the same model.)

If you are looking at a composite model, the high probability is that you are looking at an application development work product because that is the kind of thing you want to know, indeed you have to know in order to actually build a "system."

The Second Test

The next test you might apply is,

"Is this composite model being composed from primitive architectural representations (in which case, 'show me the primitive models!')

or is the composite simply representing a point-in-time
application solution?"

If there are no primitive models in evidence, then it is certain that you have an application development, point-in-time, work product in hand.

A very simple illustration is a typical application development work product that shows some data elements, their identifiers and definitions, the process that creates them, the process that uses them, and maybe some editing specifications. This is a composite in that it has both some data and some processes specified. It defines the "requirements" for writing a program, but the question is, "where is the data model from which the data is being derived?"

If there is no data model, then it is very misleading because what you have is not really data as it relates to the Enterprise, but "information," that is, data defined by its use in the context of a process -- a "view" of the data, which is highly subject to change, as well it should be.

There is nothing the matter with application development work products. They are helpful, useful, even mandatory for getting actual work done. They are just not "Architecture" in and of themselves.

Architecture, in its entirety, is the set of primitives from which application development work products could be derived.

Here are the problems with composite, application development work products that have no underlying architectural primitives:

  1. They are only good as long as nothing changes.

    As long as the same THING is transformed by the same PROCESS in the same LOCATION etc., etc., you are OK. However, if anything changes, you are into, "throw that one away and start over again."

  2. They are misleading.

    If you presume that the model actually represents Enterprise Architecture primitives, you are going to be surprised when you find they are not interoperable, and they are not reusable, as there are an infinite variety of combinations and permutations which look to be about the same, but are not exactly the same, that is, not same enough to be reused.

  3. They are complex.

    There are too many different things and different relationships being depicted in the same diagram and therefore they are very difficult to understand. By definition, they have to be limited in scope for comprehension purposes, therefore, inevitably represent "stovepipes."

  4. They are limiting.

    It is hard to see the array of alternatives when presented with a single composite model, representing a single (current) view at a given point in time.

If the work products are assembled from primitives on the other hand, they are likely flexible or adaptable, etc. because changing them is simply changing relationships between the primitives -- kind of like the idea of the old "table-driven" implementations of yesteryears.

The Last Test

However, even if the work products are derived from architectural primitives, they still may not be reusable or interoperable, which brings us to the last test,

"Are the architectural primitives designed such that they are Enterprise-wide in scope?"

If the architectural primitives are defined (or designed) for something less than Enterprise-wide scope ... or if you enlarge the scope of the Enterprise after you get the primitives defined (e.g. "value-chain," merger, acquisition, etc.), then they are only going to be reusable or interoperable within the scope for which you originally designed them.

It is increasingly significant to understand the scope of the Enterprise (or the changing scope of the Enterprise) because it is the Enterprise that is critical in the Information Age, not simply the implemented systems.

Is it possible to actually identify Enterprise boundaries and build Enterprise-wide models and manage architectural primitives? Not only is it possible, but early evidence (numbers) indicate that because of the reuse, interoperability, flexibility, and so on, it is actually cheaper and faster by more than an order-of-magnitude to take top-down, Enterprise-wide, model-driven, architectural approaches than to take the traditional, "you start writing the code" approaches that characterized the Industrial Age application development culture. (At ZIFA 2000, there will be at least one presentation on hard numbers that establish this point.)

The Framework as an Analytical Tool

The Framework for Enterprise Architecture can be a helpful analytical tool for evaluating your design artifacts. Are they work products, or are they architecture? Are they composites or are they primitives? Are they point-in-time solutions or are they Enterprise-wide? You could graphically depict the answers to these questions by over-laying the artifacts against the Framework.

Many people want to try to "put" existing, traditional (or even new) application development work products (and/or other documents and various other things) "into" the Framework. Actually, the idea is not to "put" work products "into" the Framework. Remember, the Framework is not a database for storing work products (or storing anything else, for that matter.)

It is a schema for classifying the primitive architectural constructs.

At best, the Framework as an "implementation" could be used as a kind of index (a classification scheme) to keep track of your artifacts, to remind you of the locations where they are stored, to analyze your artifacts to determine which primitives they contain or relate to ... kind of like a card catalog in a library. (Framework Software's Structure product uses the Framework is this fashion.)

But if used in this fashion, the "Librarian" would have to really understand the contents of the artifact, understand the logic of the classification scheme (the Framework), and understand where the artifact was being "shelved" (stored) in order to correctly index the artifact against the cell -- or, more likely, cells -- to which it relates.

The Framework is simply an analytical tool to help you figure out the composition of your work products or other artifacts in terms of the architectural primitives and to anticipate any potential deficiencies. You might have a work product that spans the scope of more than one cell (or row, or column, or framework, for that matter.) The question is, from what primitives is it being derived ... or more fundamentally, do any source primitives even exist?? ... or better yet, is anyone working on them?? And further ... what confusion or misunderstanding is potential from the composite nature of the work product?

Application Development work products -- or just plain old models for whatever reason -- are not Enterprise Architecture. They might look like Architecture. They might be helpful, useful or even mandatory for getting some kind of work done or getting something implemented. But if they have not been derived from some architectural primitives that were designed for the Enterprise as a whole, the work products are only going to be good for the job for which they were produced. They are not going to be reusable, interoperable, flexible, or adaptable except by some miracle or act of fate.

Of course, architectural primitives are not mystical or magical either. They are only going to be as good as the quality and experience of the Architect that produces them. At the same time however, if it is reusability, interoperability, flexibility, adaptability, reduced time-to-market, and so on that the Enterprise really requires, then...

Enterprise Architecture -- the architectural primitives -- are the engineering prerequisites!

In this case, the crisis is going to be enhancing the quality and experience of the people building Enterprise Architecture in as short a time as possible. It would be much better to be learning and gaining experience long before the crisis occurs.

In Conclusion...

In conclusion, producing application development work products for implementations was adequate, even exemplary, during the days of the Industrial Age. In those days, the end object was to get the Enterprise automated, replace people with machines, improve quality, reduce time and cost -- that is, to improve productivity.

However, the Information Age demands knowledge to manage complexity and respond to the dynamically changing marketplace. Reusability, interoperability, flexibility, adaptability, reduced time-to-market are the by-words of today's "agile" Enterprise. The gate you are going to have to go through to realize these modern Enterprise attributes is Enterprise Architecture, that is, actually producing ("engineering") the architectural primitives that constitute the knowledge infrastructure of the Enterprise.

Application development work products (even if they are "models") are not Enterprise Architecture, unless they are being derived from Architectural primitives -- primitives that have been designed with the Enterprise in mind.

Someday, you are going to wish you had all those models made explicit, Enterprise-wide, horizontally and vertically integrated at excruciating level of detail. (From these primitives, you could very quickly derive an infinite number application development work products.)

Architecture is the finite set of primitives. Work products are the infinite set of compositions.

Architectural primitives are the "elements." Work products are the "compounds."

Architecture is structural in nature. Work products are process derivatives -- the inputs and outputs of the application development process.

Enterprise Architecture and Application Development work products are both relevant and both necessary, but Application Development work products are neither a substitute for, nor a source of, Enterprise Architecture.

© 2000, Zachman International

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 ]