Review of Zachman Framework Parts 2 & 3

I have been trying to quickly absorb the Zachman Framework and the following are excerpts from the Zachman eBook.

Chapter 4 – Observations in Physics

The implications of having no Architecture are that once the assumptions start to change, it is extremely difficult, extremely time consuming to attempt to reverse engineer the assumptions (the Enterprise models) out of the existing systems, change them and reconstruct new implementations.

All those models identified by the Framework are always present. It is only a matter of whether you make them explicit or not.

The System is the Enterprise

Vertical Slivers
It is okay to build slivers of Cells, but if you want the slivers to be integrated (reusable, normalized, seamless, interchangeable, interoperable, etc., etc) you have to do something over and above just building a bunch of slivers.
Columns 1(the Data Column) ,3 (the Network Column), and 6(the Motivation Column) are the three columns that the Enterprise finds critical for scope(Enterprise-wide) integration.

In Summary of Enterprise Physics

First, all the models are always present. It’s only a matter of whether you make them explicit or not. If you don’t make them explicit, they are implicit which means you are making assumptions about them.

Second, the system is the Enterprise. Manual systems employ pencils, paper and file cabinets. Automated systems employ stored programming devices and electronic media.

Third, high level of detail descriptions (models) are good for planning, scoping, bounding, segmenting, etc. (High level descriptions are no good for implementation)

Fourth, narrow in scope descriptions (slivers of models) are quick. (Narrow in scope descriptions result in stovepipes)

Note: if you start thinking your Enterprise is exempt from these physical principles, I assure you, you are vulnerable to experiencing pain.

Chapter 5 – End State Vision

Change with minimum time, disruption and cost is dependent upon Architecture.
If you have no Architecture, there is NO WAY you are going to change anything with minimum time, distuption and cost.

The Methodology Message
- Build Models
- Store Models
- Manage (Enforce) Models
- Change Models

I am suggesting that the norm has to become the models and the exception has to be you start writing the code.

First, I am NOT saying, forget about short-term demand!
I am NOT saying: Never take the short-term option! Sometimes, because of the business exigencies, you are going to have to go directly to you start writing code…! There is nothing the matter with short-term options… as long as you recognize they are short-term options.

It should be an Enterprise decision whether to take the short-term option or the long-term option, not an information systems(or, technical) decision.


Part 3 – End State Vision
Chapter 6 – Introduction to Engineering Design Objectives

Design objectives include flexibility, adaptability, alignment, and quality
These only come by engineering… Enterprise Engineering

Reducing Time-to-Market

Make-to-Order
Shifting to an assemble-to-order environment. That is, the culture of the assemble-to-order (mass customization) environment is diametrically opposed to he make-to-order (job shop) environment.

The only way you are going to be able to reduce time-to-market to virtually zero is to Engineer and pre-fabricate the parts in the inventory such that they can be assembled into more than one product, that is, be reused in more than one implementation.
By the way, if you DO NOT have something in inventory before you get the order, you ARE a job shop, that is, in information systems terms, a waterfall.

Any Cell (primitive model) of the Framework is a candidate for engineering for reusability.

Chapter 7 – Additional Engineering Design Objectives

If you REALLY want the implemented Enterprise to align with what the Owners have in mind, you ARE going to take a top, down approach for building it out.

In summary on flexibility, change with minimum time, disruption and cost, there are several basic ideas:
-Separate the independent variables so you can change one variable
-Insert a conceptual schema (intersection) between many-to-many variables to reduce change liability from geometric to arithmetic
- Work with normalized, primitive models so you can change any concept once and it is changed for every employment
- Retain all primitive models to serve as a baseline for managing change (Someday, you are going to wish you had all those models… because I am equally convinced that the primitive models constitute the engineering basics!)

Chapter 8 – The Value Proposition for Architecture

Enterprise Architecture is an asset, not an expense. Architecture is a long term strategy. The basic idea is, you do the engineering before you start manufacturing in order to eliminate, minimize, or at least reduce the scrap and rework costs. You are investing in an inventory of assets that can be used(reused) in more than one implementation.

4 things you are unable to do in the Enterprise unless you invest in Architecture, an inventory of primitives engineered for reuse
- Alignment(quality). To ensure that the Enterprise implementations are consistent with the Owner’s intentions
- Integration(seamlessness, interoperability, standard interchangeable parts). To eliminate redundancy, duplication, discontinuity, incoherence, etc.
- Change (flexibility, adaptability). To change the Enterprise with minimum time, disruption and cost.
- Reduced time-to-market. Architecture coupled with an assemble-to-order strategy to reduce the time it takes to produce implementations to only the time it takes to assemble.


Part 2 – Analyzing the Enterprise