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