Zachman Framework Parts 5 & 6 - The Metaframeworks and Conclusion

I have finally finished reading the Zachman Framework eBook and it is interesting and will take some more time to absorb!

Part 5 – The Metaframework

Chapter 12 - Introduction

Some people may be tempted to skip Part5: Meta and the Framework because it is discussing meta concepts and at the very mention of the word meta some people begin to get dizzy.

The model of any one Cell (the Cell metamodel) would depict the internal structure of all the occurrences of the one columnar variable from the perspective (audience) for which the model was constructed. The basic, simple meta entities for each Cell appear in the Framework graphic at the bottom of each Cell. For example, in Column 1, Row 2.

A number of standards groups are attempting to define standard metamodels for a number of the Cells, predominantly in Row 5 (whether they are aware that they are defining standard metamodels for Row 5 of the Zachman Framework, including the OMG, the MDC, the OSI, etc, etc.

Actually, I am not too embarrassed to admit that we do not have a standard metamodel of all the Cells in 2002. At least we have a pretty good understanding of what each Row is describing and what each Column is describing and therefore, what the essential contents are for each Cell. That may be all that is needed to get started.

But GOOD NIGHT!! This is the most complex engineering and manufacturing problem known to mankind, ENTERPRISE Engineering and Manufacturing, and this Enterprise Engineering and Manufacturing discipline is only about 50 years old!!

All repositories and some modeling tools have extensible metamodels, that is, they make it easy to extend their database design (or, change their semantic structures, that is, change the meaning of the metadata) to accommodate a specific metamodel for a specific Information Systems Enterprise.

Chapter 13 – Metaframeworks

The Enterprise Engineering and Manufacturing Framework models at Row 2 are meta relative to the Enterprise Framework.

This is exactly the same relationship that the Enterprise Framework has with its Product Framework. Every product has a set of models (a Framework) that are descriptive of the product. That’s where I learned about the Framework to begin with… I was looking at the descriptive representations (design artifacts) for airplanes, buildings, locomotives, computers, automobiles … complex engineering products.

CAUTION: Services of the Enterprise are different from Products in that Service does not exist independently of the Enterprise itself. Services, if they are sufficiently complex, may be considered to have a Framework of their own to help define and specify them, but if this is helpful, the Service Framework must be merged into (that is, integrated with) the Enterprise Framework or you will end up with a dis-integrated, Service stovepipe or a frustrating legacy of Services just like we have a frustrating legacy of applications today.

Chapter 14 – Knowledge Domains
In the discussion of metaframeworks, I have described three domains of knowledge that are increasingly critical to the on-going management of a modern, Information Age Enterprise:
1. Knowledge of the Product of the Enterprise,
2. Knowledge of the Enterprise itself and
3. Knowledge of the Enterprise (i.e. Information Systems et al) that is engineering and manufacturing THE Enterprise (EE&M)


Chapter 15 – Multiple Frameworks in the Same Enterprise
.. you could apply the Framework logic to every single business unit on a stand-alone basis. Enterprise-wide would mena Business Unit-wide and the analysis would likely be more manageable. The Business Unit Frameworks could potentially be integrated into one bigger Enterprise Framework. It is only a matter of how you graphically want to depict them.

You don’t get integration by accident. If you WANT integration, then you have to ENGINEER for integration. That means that you will have to DICTATE to the Business Units that you want such and such slivers of such and such Cells of their Frameworks to all be THE SAME.

In the Information Age, there is significant management advantage to knowing, having coherent visibility into the Enterprise and its environment. Change(maneuverability) is the dominant strategy option. The Enterprise that is optimized, knows sooner and can destabilize the market is the one that wins the game. These are the bnefits of integration. This is the reason why the definition of Enterprise is important to management.

The Framework is inert. It does not know what you are using it to think about. Only the analyst, or engineer determines what the analytical target is. It can be used to classify the descriptive representations of anything.

All of these characteristics of the Framework make it a good thinking tool … a thinking tool that will help thinking about a very complex subject like an Enterprise. Once we establish an analytical target, we can think about one thing (one Cell) at a time without losing sense of its Enterprise (Row and Column ) context. We can isolate a single variable and think about that Cell without getting mired down in the myriad of issues going on in the other 35 Cells. At the same time, we can maintain an awareness of thither related, peer, meta or granular Frameworks. We can think about slivers of Cells, vertical or horizontal slivers, and see the short term and long term implications of implementation strategies.

Part 6 – In Conclusion

Chapter 16 – Cheaper and Faster

How do you cost-justify Architecture?
The obvious answer to the question is, you can’t cost-justify Architecture because cost-justification is an expense-based concept and Architecture is not an expense. Architecture is an ASSET.

An example is given from one of the eastern states in the early 90’s

-The cost per new entity type/RDBMS table was reduced from something greater than $150,000 per table to something less than $10,000 per table (That’s a 15 times improvement … not too shabby.)
- Enterprise data handling labor reduced by 50%
- Reduced development time of 25% through improved communication and conflict resolutions
- Development time and cost reductions for every succeeding implementation of 50% compounded through reuse of database and application components with no modifications.(Actually, the exact quote was, every time we reuse something we get 100% return on our investment.)
- Reduced disk space for data(including history) of 20% - %80 through elimination of redundancy

A better way to ask the question how do you cost-justify architecture? Would be, where do you get the up-front money to do Enterprise Architecture?
Answer: You don’t need up-front money!!! Just go get the money they are already spending or about to spend and instead of dribbling it away writing code and implementing, use it judiciously and do some engineering(Architecture) first, before you start manufacturing(implementing).