Framework Fundamentals: Miscellaneous Enterprise Engineering
|As the OMG's Business Rules Working Group was preparing its Request for Information (RFI) document, OMG management had questions for John Zachman about the nature and role of the Framework ~ in particular, its relationship to OMG initiatives. This column presents John's response.
|What follows are some questions -- asked over the course of the past several months -- that would be too hard to articulate as individual points. Hopefully, the underlying questions will be apparent in my answers here.
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 to methods/tools.
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 3).
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" problem!
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.
John A. Zachman
# # #
About our Contributor:
All About Concepts, Policies, Rules, Decisions & Requirements
We want to share some insights with you that will positively rock your world. They will absolutely change the way you think and go about your work. We would like to give you high-leverage opportunities to add value to your initiatives, and give you innovative new techniques for developing great business solutions.