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 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 3 is a sample of lists of things you would expect to find in the 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.

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

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 7 is a sample list of things you would expect to find in a metamodel of the 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.)

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!!

# # #