Intro to EA: The Paradigm Problem

 The advent of the commercial employment of computers in the 1950's ushered in an era of dramatic productivity improvements in both the private and public sectors. Clearly, using a computer to perform the processes of the business rather than people performing the processes is better because computers do things the same way every time whereas people make mistakes, computers perform in electrical (or electronic) cycle times and people in human cycle times and computers (in most cases) are cheaper than labor.

The advent of the commercial employment of computers in the 1950's ushered in an era of dramatic productivity improvements in both the private and public sectors. Clearly, using a computer to perform the processes of the business rather than people performing the processes is better because computers do things the same way every time whereas people make mistakes, computers perform in electrical (or electronic) cycle times and people in human cycle times and computers (in most cases) are cheaper than labor. Therefore, computers are "better, faster and cheaper" than people and there is enormous incentive to get the new computer systems implemented as quickly as possible. Every moment a new automated computer system is not implemented, it is costing the Enterprise quality, time and money (better, faster and cheaper)!

Better, faster, cheaper legislates the entire focus of the Information Technology (IT) community on implementation since its inception. In fact, if you ask someone from the Information community what they do for a living, the response typically is that they build and run systems... a manufacturing (that is, an implementation) concept. In fact, no value is perceived from the investment in IT until some full time equivalents (FTE's) are displaced by a new system saving (or making) money in the current accounting period. Very little effort has been focused on the Enterprise, that is on Enterprise Engineering, the design of the Enterprise itself.

This is entirely consistent with Fred Brooks' observation: "The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult…. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later. The most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements."

Since IT has been replacing people with machines since its inception, it has literally been manufacturing the Enterprise... but the Enterprise was never "engineered." Therefore, IT was not manufacturing the Enterprise, they were manufacturing "parts" of the Enterprise... "systems"... and the resultant "parts" (systems) don't fit together. That is, they are not "integrated." Fred Brooks is attributed with the observation that "programming is manufacturing, not engineering." If someone was building Industrial Age products like airplanes, buildings, automobiles, computers, etc and they manufactured parts that didn't fit together, what would have to be done?... Scrap and rework! There is no way to fix this problem after the fact. If you want parts to fit together, they have to be engineered to fit together before they are manufactured.

This elicits a quote Jay Forrester:

"Although social systems are more complex than physical systems, they belong to the same class of high-order, non-linear, feedback systems as do physical systems.

"People do not accept the idea that families, corporations, and governments belong to the same class of dynamic structures as do chemical refineries and autopilots for aircraft.

"Organizations built by committee and intuition perform no better than an airplane built by the same methods ... as in bad airplane design, which no pilot can fly successfully, such badly designed corporations lie beyond the ability of real-life managers.

"I anticipate that future management schools devoted to 'enterprise design'. ...a fundamental difference exists between an enterprise operator and an enterprise designer. A manager runs an organization, just as a pilot runs an airplane. Success of a pilot depends on an aircraft designer who created a successful airplane ... who designed the corporation that a manager runs?"

Historically, the programmer (or someone from IT) defined whatever components they want or need to get the code to run for implementation. In fact, I think this is the essence of the Agile programming community at present. No wonder we have so many different versions of the truth (data) and the plethora of "parts" (systems) that don't fit together (are not "integrated") in the Enterprise.

The "raw material" for doing engineering are the engineering design artifacts, the descriptive representations of the object being created. The collection of these design artifacts are its "Architecture."

I submit, if every plumber, every carpenter, every electrician, every architect, every electrical engineer, every hydraulic engineer, every structural engineer, every general contractor, every project manager, every building code inspector, every legislator, every lathe operator, every building owner, every building occupant defined Building Architecture the way only they wanted to define it, we would not have hundred story buildings ... we probably wouldn't have even 3 or 4 story buildings! (The same exists for airplanes, automobiles, computers, ocean liners, etc., etc.) To build complex objects that have any reliability, longevity, maintainability, quality, etc. the parts all have to be engineered such that they fit together (are integrated) into the whole of the object.

Is that important?

In the Public Sector, when publicly used complex objects fail ... automobiles crash, buildings fall down, airplanes crash, drugs harm people, etc. that is, when citizens get hurt, the government intervenes with regulatory action. "Before we allow you to build a building in downtown Los Angeles, we would like to see your Architecture." In Los Angeles, it is the Fire Department that does the "Plan Checks" ... they have to put out the fires and a plan check for a hundred story building takes several years and costs a lot of money. The Federal Aviation Administration is famous for evaluating airplanes and airplane manufacturers. The Food and Drug Administration is famous for enforcing regulations that provide for health safety of foods and medicines. Etc., etc.

By the same token, if every programmer, every database administrator, every data administrator, every systems analyst, every project manager, every IT manager, every network administrator, every business analyst, every CEO, every vice president, every CFO, every strategic planner, every Enterprise Architect insists on defining Enterprise Architecture they way only they want to define it, there is little wonder that the Enterprises of today are not integrated, not flexible, not aligned, not interoperable, not reusable and not meeting expectations!

It does not take too much imagination to speculate that if Enterprises cannot accommodate the dramatic escalation of complexity and the extreme rates of change incumbent in the Information Age environment and Enterprises fail and citizens become unemployed; that the government will intervene with regulatory action... "before we give you a license to operate in our geographic domain, we would like to see your Enterprise Architecture." In fact we presently see the Klinger-Cohen Act, the Federal Enterprise Architecture Policy, the Department of Defense Architecture Framework Standards, etc. in the United States alone.

Is this important?

If an airplane cannot accommodate the stresses of the external environment and crashes, you might lose 3 or 4 hundred people. If a hundred story building cannot accommodate the stresses of the external environment and implodes, you might lose 3 or 4 thousand people. If a pharmaceutical drug cannot accommodate the complexity of the human physiology, you might lose 30 or 40 thousand people. If a Private Sector Enterprise cannot accommodate complexity and vagary of the changing environment you might lose 3 or 4 hundred thousand people. If a Pubic Sector Enterprise cannot accommodate the changing demands of the global population you might lose 3 or 4 million people.