Fatal Distractions (part 2)
by John A. Zachman
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
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, here are my recommendations for you:
- 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.
- 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.
- 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."
- 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.
- 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!!