First, some background. The Framework is a two dimensional classification scheme
for descriptive representations of an Enterprise. I discovered it by looking
at the structure of descriptive representations of airplanes ... and we examined
buildings, automobiles, battleships, and super computers as well. I simply
applied the same structure of product description artifacts to Enterprise descriptions.
It has nothing to do with systems analysis and design techniques or network architectures,
other than the fact that some of the descriptive representations of the Enterprise
may be produced over the process of employing stored programming devices and electronic
media for implementation purposes.
I might observe that it is equally conceivable that descriptive representations
could prove useful when using pencils, paper, and file cabinets as the implementation
technology. I also might observe that those are your two implementation options:
pencils, paper, and file cabinets, or stored programming devices and electronic media.
The same Framework for descriptive representations could be used to describe the
material handling and people moving technologies, but those technologies tend to
be beyond our area of interest. The technology constraints being employed in
the implementation of the Enterprise -- whatever they are -- simply affect the content
of the Cell models at Row 4 ... not the Framework itself.
Second, the Framework is a semantic structure and therefore does not imply
anything about process. Process is a methodology or tool issue ... and a meta
issue. Which Cell (or Cells) -- or which "sliver" of which Cell(s)
-- and in what sequence they are produced ... this is all a function of the value
system of the author of the methodology or tool. The Framework is inert relative
The reason why UML might not address Rows 1 or 2 models is probably because UML's
origin was Row 5 and subsequently, Row 4. I have a friend who quotes Grady
Booch as saying, "We know how to do design; we don't know how to do analysis."
I cannot validate the quotation but, assuming it is somewhat accurate, I would interpret
that to mean the object folks know how to do Row 4, not Row 3. People tell
me that there is some problem using UML to do Row 2 and I suspect that the underlying
problem is that the metamodel of UML does not support the differentiation between
Enterprise things (Row 2) and the logical representations of Enterprise things (Row
Regarding "removing the wall between Data and Process" ... that also
likely stems from the origin of the object community. I suspect that their
overiding value proposition was implementation, not architecture. For implementation
you need composite models (for example, data and process together) whereas for architecture,
you want primitives (data and process separate). Ultimately, you want both
composites and primitives because you want to create the composites from the primitives.
If you are only creating composites on an ad hoc basis, then you have point-in-time
solutions relative to a specific implementation ... and that's the heart of the "legacy"
The end objective of architecture is to create an inventory of reusable assets,
defined relative to the Enterprise -- not relative to a single implementation --
from which a wide variety of composites (objects) could be assembled to order,
NOT created to order.
Regarding CMM ... clearly CMM is a process issue by its very definition.
I think the question it is addressing is: how much formality and discipline
exists in the application development process? I suppose you could get some
insight into the amount of formality and discipline there is in an application development
process by assessing which slivers of which Cells of the Framework the process formally
produces and manages.
However, there is probably an even more profound question that could be exercised
and that has to do with composites and primitives.
- If the application development process produces composites, it is likely
a typical "job shop." In other words, it is making custom products
... applications. No engineering or manufacturing is being done until they
get the order.
- On the other hand, if the methodology is producing primitives, then it
is likely that they are changing the fundamental concept of I/S to "mass customization."
They are creating architectural primitives relative to the Enterprise before they
get the order for an application so that, when the order arrives, the time for implementation
is reduced to only the time required to assemble the composite from the primitives.
The engineering has already been done.
Clearly, if you want to reduce the "time-to-market" for systems implementations
and at the same time accommodate enormously-increased complexity in the Enterprise
(for example, CRM), you have to have something in inventory that has been engineered
to be assembled into more than one implementation before you get the order.
Clearly, CMM does not address that issue at all. It is merely measuring the
degree of formality and discipline in the process, whatever process is being employed.
On the other hand, if there is little formality in the process, the likelihood of
realizing architectural approaches (mass customization) for the Enterprise I would
judge to be low to zero.
I am very concerned about the gross misconceptions so many people have about my
Framework (specifically) and about Enterprise Architecture (in general). I
have been doing two-day seminars regularly in the U.S., Europe, Asia, and Africa
for over 10 years. I have been attempting to write more extensively for the
last several years and have written about 20 major articles during that time.
There are some highly knowledgeable Framework people with whom I have worked for
over 20 years who are now doing extensive, more technical seminars about Enterprise
Architecture and my Framework than I could possibly do. I have finally finished
writing "The Book." I am not too sure what else I can do in the face
of a growing body of 'experts' on the Zachman Framework who have never gone to my
seminars nor read any of my materials. At least, someone on the addressee list
of this note had the presence of mind to ask ... which I do appreciate.