1 year, 8 months ago

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

Author

John A. Zachman

1 year, 10 months ago

EA Manufacturing versus Engineering

Manufacturing descriptive representations are holistic descriptions of individual parts such that the part (system) can be manufactured quite independently of the entirety of the Enterprise. The description of the part must be complete, “holistic,” because any characteristic that is requisite to the existence of the part, if not made explicit, is potentially defective. That is, any characteristic not made explicit is implicit and therefore, assumptions are being made which may be right … or may be wrong. Erroneous assumptions are the sources of defects.

Manufacturing descriptive representations can conveniently be classified in ONE dimension; a taxonomy, a hierarchy, a decomposition, which is, reductionism, (“analysis”). It is convenient for manufacturing to reduce the size of the parts through decomposition because the smaller the part, the less costly and more quickly each part can be manufactured. However, the smaller the implemented parts (systems) the more potential disintegration of the Enterprise as a whole.

Engineering descriptions are the converse of manufacturing descriptions. They are descriptive of the whole object, partitioned not by reduction but by intrinsic characteristic. The engineering descriptions are classified in a TWO dimensional structure, a schema, an ontology, such that the whole object is depicted in the context of each single, intrinsic characteristic. The descriptive classifications for engineering employment are “normalized” … “one fact in one place.” This is important for engineering so that redundancies, potential discontinuities, inconsistencies, incompatibilities, erroneous assumptions are identified and eliminated and therefore, every relevant characteristic is “integrated” in the context of the whole Enterprise (“synthesis”). In this fashion, if the implemented parts reuse components having characteristics that are integrated in the context of the whole Enterprise, the parts (systems), when implemented, will fit together, that is, the Enterprise will be “architected.”

See figure above for a comparison of Manufacturing Work and Engineering Work.

engineering v manufacturing

This engineering : manufacturing dichotomy can be seen the older disciplines. In Chemistry, the Chemical Engineering work is scientific, theoretical, focused on the single-variable theoretical elements as defined in the ontological structure of the Periodic Table. Chemical Manufacturing work is pragmatic, focused on assembling chemical products from multi-variable, holistic (in their own right) compounds (parts) that exist in nature or that can be created experientially. If no Chemical Engineering is done, alchemists can manufacture chemical products from compounds (parts) only if, by chance, the compounds (parts) “fit together,” that is, if they will “integrate.” Since the alchemists’ work is pragmatic, experiential, not theoretical, all progress is made by time-consuming, trial and error, (“best practices”) which severely limits the complexity and alacrity of the end results.

This can be seen in engineering and manufacturing of electrical and mechanical products as well. The engineering artifacts are descriptive of the whole object in the context of each single, intrinsic characteristic of the object. The manufacturing artifacts are descriptive of the total set of characteristics required for the implementation of a single “part” of the object.

I happened to discover the ontological classification of the Engineering Design Artifacts of an Enterprise, the “Zachman Framework,” by observing this pattern of descriptive representations in Architecture and Construction (buildings), and in Engineering and Manufacturing (airplanes, computers, ships, automobiles, etc.). I have written numerous articles and made a myriad of presentations about this experience and about the logic of the Framework for Enterprise Architecture, the Enterprise Ontology, the “Zachman Framework”.

Author

John A. Zachman

1 year, 10 months ago

Enterprise Architecture is an Enterprise issue, NOT an IT model-building exercise

The common perception (or more appropriately, mis-perception) of Enterprise Architecture in the general marketplace today is that it is one of an Information Technology (IT), model-building exercise. There is validity to that perception because, in order to engineer the Enterprise, the engineering design artifacts (the descriptive representations of the Enterprise) have to be created as they are the “raw material” for doing engineering work and the IT community seems to have the skills to produce those engineering design artifacts.

The engineering design artifacts include the transcription of what the end-owners of the Enterprise, the people responsible for the operation and performance of the Enterprise, have in mind as to what the Enterprise is or is to be. These “requirements” for the Enterprise have to be articulated in such a fashion that engineering kind of work can be done to transform the Enterprise as it is conceived into an operating reality and to maintain that reality consistently as the requirements dynamically change. Although the IT community may have the skills to transcribe the “Requirements” for the Enterprise and transform them into a dynamic reality, the implied descriptive representations are not IT conceptions, only IT transcriptions and transformations. That is, Enterprise Architecture is an Enterprise issue, NOT an IT model-building exercise. 

A problem occurs because, from the origin of the modern information industry in the 1950‘s, descriptive representations of the Enterprise have been perceived by the Information Technology community from a manufacturing perspective as opposed to an engineering perspective. Historically, IT is a manufacturing operation, “building and running systems.” Manufacturing work requires multi-variable, holistic descriptions of PARTS of the object. In contrast, engineering work requires single-variable, ontologically-defined descriptions of the WHOLE of the object.

If the engineering work is done prior to the manufacturing work, the parts can be designed in the context of the whole object and thereby designed “integrated” into the whole. If no engineering work is done before manufacturing, the parts can be successfully manufactured in and of themselves but will not be designed for integration into the whole. This is especially obvious if the parts are made of physical material as for an airplane or a building or a computer, etc. The parts simply don’t fit together, that is, they are DIS-integrated. What do you do if you have manufactured parts and they don’t fit together? Scrap and rework! Throw that stuff away and start over again! There is no way to fix that problem after the fact.

In an Enterprise, if the parts (systems) are not engineered to be “integrated” into the context of the whole (Enterprise), they will be DIS-integrated, that is, they won’t “fit” together. However, it is not as visibly obvious in the systems because the systems, in and of themselves, are “invisible” and can be successfully implemented, embodied in the “legacy”, the manual and/or automated collection of running systems of the Enterprise. The systems are perceived to be invisible, but they don’t physically work together as a whole Enterprise. They are discontinuous, inconsistent, costly to maintain, costly to “interface” (the after-the-fact attempt to post-integrate), difficult to change. The DIS-integration is painfully obvious to the Enterprise operationally as the systems, though “invisible” and successfully operating asynchronously, are no less tangible than metal or wooden parts of industrial products that don’t “fit” together.

1 year, 11 months ago

Zachman Enterprise Engineering – Primitive vs. Composite Review

Primitives and Composites – What’s the Difference?

It is useful to discuss the differences between Primitives and Composites because this is the paradigmatic problem of the Information community of the day.

It is useful to discuss the differences between Primitives and Composites because this is the paradigmatic problem of the Information community of the day.

Primitives are single-variable, ontologically-defined categories of the essential components upon which the Enterprise is dependent for existence. Only one type of Enterprise component can be classified in any one cell of the Zachman Framework. They are the domain of Engineering, that is, Architecture. They don’t “do” anything. In contrast, Composites are multi-variable, holistic constructs of parts or pieces of the Enterprise with components from multiple categories of the essential components. Representation of different categories of components (different Framework Cells) are prerequisite for implementation. They are the domain of Manufacturing. They implement (“run”).

There is a strong metaphorical correlation between the Elements and Compounds of the Chemistry discipline and the Primitives and Composites of the Enterprise Architecture domain. Elements (Primitives) are timeless. Compounds (Composites) are temporal. Elements (Primitives) have single types of components. Compounds (Composites) have multiple types of components. Elements (Primitives) are isolated theoretically for engineering work. Compounds (Composites) are integrated practically for manufacturing work. Elements (Primitives) are Architecture. Compounds (Composites) are implementations. Elements (Primitives) are needed for Engineering. Compounds (Composites) are used by and the result of Manufacturing. Compounds (Composites) can be manufactured without knowing anything about or reusing the Elements (Primitives), but for Compounds to be engineered to produce predictable and/or modifiable behavior, they must be created from “reusable” Elements (Primitives).

This brings up a very important point. If you had inventories of all of the Chemical Elements in their primitive states, you could manufacture ANY Chemical Compound you wanted. However, as soon as you create the compound, it is fixed … it is hard to change. By the same token, if you had all of the Enterprise Primitives in inventory in their pure Primitive state, you could create any Enterprise Composite implementation required. Once you create the Composite, it is fixed, a snapshot, a point in time instantiation… an implementation.

There is a metaphorical departure in Enterprise Architecture from Chemistry in the fact that the media of the Enterprise implementation is the same as the media of its descriptive representations, namely digital depictions. We do not have to go through a media transformation from our engineering descriptions to become our implemented reality. They can both be digital. We simply “compile” the implementation. However, we learned long ago that the moment you “bind” together the components of the Composite implementation, it is fixed … you can’t change it. Therefore, the optimum implementation strategy would be to “bind at execute time” … that is, don’t “compile” the implementation until you “click your mouse” … “late binding.”

Unfortunately, “bind at execute time” is not presently perceived to be technically feasible. I think most people would argue that it is because the current technology does not support the concept. I would suggest that this is not a technical issue at all. The fundamental problem is, we do not have an inventory of our Primitive (elemental) components in their pure Primitive state from which we could bind Composites together at the click of the mouse. The key to this capability is Enterprise Architecture, the inventory of Primitive components, “loosely coupled,” related only by “foreign keys” in a database (Repository). If we had the inventory of Primitive Models in a Repository, the current technology would, in fact, support the concept. This capability in Manufacturing, Industrial Age products, is called “Mass-Customization:” “Custom Products, Mass-Produced, in Quantities of One, for Immediate Delivery.” This is REALLY important for Enterprises in the Information Age … because of the dramatic escalation of complexity and of the rate of change, the ENTERPRISE needs to be mass- produced from reusable components already “in inventory” in quantities of one for immediate instantiation … dynamically creating (late-binding) a new Enterprise implementation. This is the urgent motivation for ENTERPRISE ARCHITECTURE!!!

2 years, 6 days ago

Zachman Framework Rows. What are they?

Rows = Perspectives = Reification

After 30 years of talking about this, I am still shocked at the predominant misconception that the Rows of Zachman Framework define “level of detail,” or “waterfall,” or “decomposition.” This is just not true. The Rows of the Zachman Framework define TRANSFORMATION, NOT decomposition. Level of detail is defined in the HEIGHT of each cell (or Row), NOT the height of the Framework itself. While I originally I called the Rows “Perspectives,” the underlying theory that defines the Rows is the philosophical concept of Reification.

One day in Houston, I was doing a seminar for some folks and was describing the Perspectives that constitute the second dimension (the Rows) of classification depicted by my Framework and some guy in the back of the room said, “Ohhh! That’s reification!” I said, “Re-if-a-what???” I never heard the word before. I said, “spell it for me” “R-e-i-f-i-c-a-t-i-o-n.”

It turns out that “reification” is a word that comes out of Philosophy. The etymology of the word is from the Latin, where “RE” means “thing” so “RE – IFICATION” would mean “Thing-ifcation,” making a thing, an instantiation, out of an idea that you can think about such that the thing (instantiation) bears a resemblance with the idea that you start with. Plato and Aristotle and apparently some assemblage of early Philosophers knew that an idea that you can think about is one thing but the instantiation of that idea is a totally different thing… and if you want the instantiation to bear any resemblance with the idea, the idea has to go through a well-known set of transformations.

Reification (Rows of the Zachman Framework):

  • Row 1: First you have to Identify it, name it so you can have some discussion about it.
  • Row 2: Next you have to Define it, the semantic intentions. The meaning, the structural definitions of the Enterprise components. The elements of Row 1 did not get more detail, they were transformed into a different perspective.
  • Row 3: Then you Represent it as all engineering is done with representations, not physical material. 
  • Row 4: Next you Specify it based on the implementation technologies available. 
  • Row 5: Next you Configure it based on the tooling to be used.
  • Row 6: Then, you Instantiate it- it becomes reality.

 ZF Reification

If the idea goes through this set of transformations, the Instantiation will bear resemblance with the idea. Reification is likely the more fundamental definition of the Rows of the Framework since it has been employed by humanity for several thousands of years. However, there is a strong correlation between Reification and the Perspectives as I identified them from the older disciplines of Architecture and Construction and Engineering and Manufacturing. This should not come as a great shock… there is a natural classification structure, it is manifest consistently in any application or discipline.

3 years, 7 months ago

The Zachman Framework Requires ZERO Documentation

The Framework is the Ontology

I have no idea where people get the idea that the Zachman Framework requires any documentation at all.  The Zachman Framework is an ontology – the theory of the existence of essential components of an enterprise (actually, of anything) that warrant description in order to successfully create it, operate it or change it. Whether any or all of those components are described (documented, made explicit) is a function of a methodology and the choice of the Enterprise… not a requirement of the Framework.

Models give you Power

Somehow or other, people hear me say, “Stop the music for 15 or 20 years until you get all of these models built and then you can start writing code again.” I have NEVER said anything even close to that.

What I have said is, “Some day… SOMEDAY, you are going to wish… forget you… SOMEDAY the ENTERPRISE is going to WISH they had all of these models made explicit, all of them Enterprise-wide, all of them horizontally integrated, all of them vertically integrated, all of them at excruciating level of detail.” Why?  Because, if they had all of those models made explicit, they would have a VERY powerful capability to accommodate extreme complexity and extreme rates of change. I have NEVER said when I thought that would be. I have ALWAYS said that might even be utopia… you might NEVER formalize all of the models. I have said, the 80/20 rule probably is in effect. If you have 80%, you might not need the other 20%. In fact, if you had 20% of the models, you might not need the other 80%. I also have said that in order to achieve the utopian condition of all the models formalized, it likely would require a lot of work and therefore, methodologically, you will probably have to figure out how to achieve that iteratively and incrementally over some longer period of time.

By the way, I ALSO always say, you can deliver substantial, immediate Enterprise value from a relatively small sub-set of Primitive Models. A little order goes a long way!

By the way again, there ARE implications to not producing any one of the Primitive Models identified by the Framework. Any model that you do not make explicit is implicit. By definition, you are making assumptions about any Framework Primitive Model that you have not made explicit and those assumptions may be right… or they may be wrong. Erroneous assumptions in manufacturing are called “defects.” Removing defects from anything is expensive and the closer you get to providing the implementation of the end result into the hands of your customers (“users”) before you discover the defect, the more costly it will be to remove it. (This is statistically provable… see Capers Jones work on “Software Quality”). Therefore, SOMEDAY, it would be in your best interests to have made all of the Framework Primitive Models explicit… however, you may be willing to assume the risk of some defects (the fewer, the better) at any given point in time.

The Framework gives you Power

The Framework is the ontology… NOT a methodology. The Framework implies nothing about which models you might want to produce (make explicit) or whether you want to produce any models at all. It implies nothing about how you might want to produce the models: top-down, bottom-up, left-to-right, right-to-left, where to start, etc. Although these are significant methodology choices, they are not prescriptions of the Framework. The Framework simply identifies the total set of architecture possibilities and therefore, the nature of the risks that may be or may have been assumed.

Author

John A. Zachman

3 years, 11 months ago

Unfounded Reasons People Tell Me Why They Can’t Do Enterprise Architecture

I have been working in the area of Enterprise Architecture for 40 years and people have been telling me (and are still telling me) the reasons why they think it is impossible to do Enterprise Architecture.  I think I have distilled these reasons down to five basic objections.  Let me enumerate their objections before I explain why these objections exist and why they are completely unfounded.

First of all, by its very name, Enterprise Architecture implies ENTERPRISE-WIDE descriptive representations, models, architectural depictions and:

a.  “It would take too long and cost too much … ”  

b.  “Enterprise-wide models would be so big and so complex, who could understand them or do something with them even if we could build them? … “

c.  “You don’t need Enterprise-wide models to get some one system built, deliver Enterprise benefit (immediate gratification) and actually, the SMALLER you make the systems the faster you can deliver them and derive benefits … “

d.  “To simply build Enterprise-wide models that could be understood and have any communication value, they would have to be so abstract they would have little implementation value.  They could not be correlated with the reality of instantiations … “

e.  “Enterprise-wide models, however robust, are only a picture, a snapshot, a point-in-time representation.  They would likely go on a shelf and never be referred to again … “

In fact, a very well-known CIO recently stated at a major IT conference that he had terminated a number of Enterprise Architecture projects that just produced pictures and went on shelves never to be used and he saved the Federal Government billions of dollars.

The problem with all of these objections is, the folks who are voicing them are NOT TALKING ABOUT ENTERPRISE ARCHITECTURE!!!

The REAL problem with all of these observations (objections) is, the underlying assumption is COMPOSITE, multi-variable, implementation models, typical models we employ in IT, the MANUFACTURING paradigm … the paradigm that has prevailed in the DP/IT community for 75 years since the inception of computer technologies.

Basically, the end object for 75 years or so has been (and is) to replace people with machines because machines are better, faster and cheaper than people.  Machines are better than people because they do things the same way every time (and people make mistakes), machines are faster than people because machines run at electrical cycle speeds (and people run at people cycle speeds) and machines are cheaper than people (in most cases).  Better. Faster. Cheaper.  The value proposition for system implementations is “cost-justification” (how many Full Time Equivalents will the new system replace? … or, how much value is delivered in terms of the development and implementation costs?), expense-based value propositions.  There is great incentive to get the systems implemented as quickly as possible because every moment the system is NOT implemented, it is costing the Enterprise quality (or capability), time and money (better, faster and cheaper)!

The problems (objections to) Enterprise Architecture is NOT Enterprise Architecture … the problem is what people typically PERCEIVE to be Enterprise Architecture which is derived from the expense-based, implementation value proposition which is NOT Enterprise Architecture, because…

Implementation is NOT architecture

Multi-variable models are NOT single-variable models

Composite models are NOT PRIMITIVE models

Manufacturing is NOT Engineering

Building and running systems is NOT engineering Enterprises

Expense-based valuation is NOT Asset-based valuation

AND

Enterprise-wide COMPOSITE models are NOT ENTERPRISE ARCHITECTURE

All the above reasons why you can’t do Enterprise Architecture are perceived from the perspective of building and running systems, which has been the DP/IT paradigm for 75 years.  Enterprise Architecture has nothing to do with building and running systems.  Oh yes, you could use stored programming devices and electronic media for realizing your Enterprise formalisms, but you also could use pencils, paper and file cabinets … and people.  And … if you had ENTERPRISE ARCHITECTURE, Single-Variable, PRIMITIVE models, they could be used (re-used) for formalizing systems, automated AND manual systems, for that matter.

I would suggest that the Information Age paradigm is not about Building and Running Systems (an expense-based concept) BUT about Engineering and manufacturing ENTERPRISES (as asset-based concept), that is, ENTERPRISE ARCHITECTURE, a different paradigm, a NEW paradigm, which has to do with engineering ENTERPRISES to be “lean and mean”, integrated, flexible, interoperable, aligned, dynamically reconfigured, “mass-customized”, etc. These are engineering-derived characteristics … NOT implementation-derived characteristics.  Building and running systems does not produce these characteristics for the Enterprise as evidenced by the preponderance of legacies that exist in Enterprises today.

The legacies were (are) GOOD … they served well for the Industrial Age.  Automated (and manual) systems are not going to go away.  However, the future, the Information Age, requires ENTERPRISES to be integrated, dynamic, “lean and mean” and so on.  ENTERPRISE ARCHITECTURE.  That is a DIFFERENT paradigm.  Yes, we must produce short term results.  No, short term demand is not going away.  Yes, some of those results may consist of replacing people with machines.  Yes, you must employ methodologies that create Enterprise-wide Architecture iteratively and incrementally but these methodologies require ENGINEERING Models, single-variable models, “PRIMITIVE” Models, different models from those multi-variable, composite models we have traditionally used for implementations, for building and running systems.

It is the composite model, implementation paradigm, building and running systems mentality that causes us to misperceive Enterprise Architecture as being unnecessary, impractical and impossible. In contrast, I just watched my friend Sunil Dutt Jha of iCMG, in the Zachman Certified Modeling Workshop, conclusively demonstrate use of and reuse of “primitive”, single variable Enterprise Architecture asset components to dynamically diagnose, address, simulate urgent CXO strategies while building Enterprise Architecture iteratively and incrementally. He proved it is cheaper and faster, a LOT cheaper and faster than the traditional building and running systems approach. It is not mysterious … it is simply changing the IT manufacturing strategy from producing finished goods (composites), implementations, to an IT engineering strategy, producing re-usables, assets, (primitives), for mass-customization of the Enterprise while solving immediate C-level executive problems.

I wrote an article in 1999, “Enterprise Architecture: The Issue of the Century” in which I argued that those Enterprises that can accommodate the concepts of Enterprise Architecture will have the opportunity to stay in the game … and, those Enterprises that cannot accommodate the concepts of Enterprise Architecture are not going to be in the game.  In fact, I actually believe that.  In fact, you can see a lot of Enterprises falling out of the game these days … big … and small … private … and public.  (Refer to the newspapers.)

Author

John A. Zachman

4 years, 4 days ago

Welcome to my blog!

Welcome to my blog!
I am very excited about the new developments in The Zachman Framework 3.0 and Zachman International! We have spent the last couple years “underground” refining our research, developing several new programs, forging new relations…

4 years, 7 months ago

The Zachman Framework Requires ZERO Documentation

The Framework is the Ontology

I have no idea where people get the idea that the Zachman Framework requires any documentation at all.  The Zachman Framework is an ontology – the theory of the existence of essential components of an enterprise (actually, of anything) that warrant description in order to successfully create it, operate it or change it. Whether any or all of those components are described (documented, made explicit) is a function of a methodology and the choice of the Enterprise… not a requirement of the Framework

4 years, 8 months ago

“Implementing” the Zachman Framework™

In answer to a question about “implementing” the Zachman Framework … here is my response:

Remember … the Framework is much like the Periodic Table … you wouldn’t necessarily “implement” the Periodic Table.  However, it would be really helpful if you could keep an inventory of as many of the Periodic Table elements as you can so when you get ready to produce a compound, a chemical implementation, it could be done very quickly and very cheaply.  

Similarly, the Framework.

I always say … “Some day … SOMEDAY, you are going to wish you had all these models …. etc. etc.”  You don’t NEED all the models … however, the more, the better … but maybe it would be UTOPIA to have all the Framework Primitive, single-variable models, all made explicit, all enterprise-wide, all horizontally and vertically integrated and all at excruciating level of detail!  If you had them all in inventory, you could manufacture Composite implementations (systems) from the Primitive Models (architecture) VERY quickly and VERY cheaply!  That effectively would be “mass-customization” of the Enterprise (“custom Enterprises mass-produced in quantities of one for immediate delivery”) … the actual realization of “late-binding” of system implementations … not to mention an actually “lean and mean”, deliberately designed, Enterprise reality!

4 years, 11 months ago

Unfounded Reasons People Tell Me Why They Can’t Do Enterprise Architecture

I have been working in the area of Enterprise Architecture for 40 years and people have been telling me (and are still telling me) the reasons why they think it is impossible to do Enterprise Architecture.  I think I have distilled these reasons down to five basic objections.  Let me enumerate their objections before I explain why these objections exist and why they are completely unfounded.