Enterprise Architecture 101 - Notes

I attended training on Zachman Framework in 2007 and have just found some of the notes I made. I am putting them here for those that may find them useful and for posterity. Most people lack fundamentals when it comes to ZF and here are some key points to think about when considering ZF:
EA formally started in 1987 - when J. Zachman published his framework.
In the old days, the approach was first, you understand the enterprise then you develop appropriate infrastructure.
Enterprise architecture is meant to solve chronic problems, not acute problems.
EA is not a silver bullet but is about a long-term solution to chronic problems.
Envision the enterprise as a concrete thing, not as an intangible thing.
Nothing is exempt from the laws of nature, including enterprises (survival for the fittest). You have to understand the fundamentals of change and complexity so that things can be predictable.
The law of conservation of complexity states that complexity cannot evaporate: somebody has to deal with it.
Architecture is engineering and implementation is like manufacturing. The implementer/builder uses tools. The Architect uses an EF. If you start with manufacturing, you pay the price later in the form of scrap and rework.
When you start with engineering, you are creating assets for later reuse. Expense-based approach is short-term.
Architecture bridges strategy and implementation.
Analysis-->Strategy-->Architecture-->Implementation
Engineering is the primitive, manufacturing is the composite.
Before Mendelev discovered the periodic table, Chemistry was alchemy. Its the framework (periodic table) that moved it to the next level. After the P. Table, it took off.
Frederick Taylor and Walter Scheward created the Plan Do Check Act cycle and Demmings popularized it (really?)
Invention is a function of time, not personality. When the world is ready for something, it will appear.
Technology is a tool for the builder. Not for the engineer. The end object of EA is not to build systems but to engineer an enterprise.
The definition of an enterprise defines the boundary for integration. Anything outside the enterprise requires an interface (not integration).
Too small a boundary creates integration and too broad a scope creates lack of jurisdiction.
A revolution is simply the gap between the ages.
"Captain cook syndrome" is manifest when we are looking at the information age through industrial age eyes.
The ZF is not theoretical but empirical because it is derived from actual application in industry.
If you cant describe it, you cant create it.
The Key point about technology is manoeuvrebility: You have to have technology architecrure if you are to have dynamism in technology - Bernie.
A picture is worth a thousand words and a model is worth a thousand pictures. Diagrams are easier to check and are therefore better than text. Architecture is about diagrams, not text.
Start by building the most independent thing first and the dependent ones last.
When you leave the model implicit, you are making basic assumptions about it and these assumptions can hide defects and can be themselves defective.
The cost of correcting a defect increases a hundredfold as you approach maintenance.
If you dont make a model explicit, ask yourself how many assumptions you are making about it. If you dont make it explicit, you are allowing everybody to assume whatever they want about it.
Erroneous Assumptions = Defects.
A framework makes the unorganized organized and coherent but it doesnt tell us how to put the artifacts together - what does that is methodology.
A Framework gives you a point of reference.
Words are hard to understand when complexity increases. That is why we use blueprints.
Architecture only stops when the enterprise stops changing.
Architecture is not a project but a process because it is continuous.
Dont take the short-term perspective when implementing change.
Remember crash diets crash.
The plan should not be the goal. What is important is the thought process behind the goal.
If you never want to be criticized, dont do anything. If you dont do anything, you cant achieve anything - Daryl Conner.
Winners adapt, learn and respond. They view life as challenging but full of opportunities.
Automating a bad business process doesn't help anybody.
If you cannot see it on the architecture, the implementation cannot be done.
A fool with a tool is still a fool.
All goals must be SMART. If we don't have SMART goals, we cannot be smart.
Only 20% of knowledge is retained after 45-60b days. This is the knowledge decay rate.
Strategic intent is not equals to strategy.
Platitudes (statements of desire) are not goals. State the mechanism for achieving the goals.
Functions are implemented by mechanism.
Functions are developed to achieve the goals of the organization.
Think things first then write them down. Then construct the structure.
You do engineering to make each element (content of a cell in the Framework) as simple as possible.
The classification of each cell must be comprehensive and non-redundant to ensure each cell in the network is unique.
If there is no underlying structure there can be no discipline. The framework helps in this.