While many an EA effort failed to provide expected value, this is the case of most transformation approaches when they were applied improperly -- including business process reengineering and "big bang" ERP.
Clearly Mr. Pickering brings a valuable perspective to us with his experiences of EA -- and he is correct that all change initiatives must provide near-term value to be sustainable. This is one of the reasons why Six Sigma is popular; it provides rapid and quantitative value.
Many, however, fail to understand EA. To understand EA, one must understand the roots of EA -- IBM's Business Systems Planning methodology (BSP), the precursor to most IT strategic planning approaches.
After the publishing of BSP, John Zachman produced a paper in the IBM Systems Journal titled "A Framework for IT Architecture," which included a 3-by-6 matrix of perspectives and interrogatories. This matrix was intended to describe the notion that different stakeholders within an organization care about different things even though they all work for the same organization, a notion now embodied in the IEEE 1471-2000 standard, which is gaining much acceptance in the IT community.
Zachman's matrix, intentionally called a "Framework for IT Architecture," was intended to graphically represent how many of the artifacts or models of BSP linked together to bring about alignment between strategic intent and operational reality. It was called a "Framework" because it was intended to be a frame of reference or a structure that pulls related parts into a whole.
Toward IT Anarchy
Recognizing that EA is a component of BSP, to pronounce EA dead is to pronounce BSP dead, and BSP is the foundation for IT strategy and planning. Thus, to take Mr. Pickering's argument to the extreme, we should let IT strategy and planning die, allowing IT anarchy within organizations in a world that is rapidly becoming more cost conscious, less secure, more regulated, and more connected.
Non sequitur? Not really. EA, by most interpretations, is a process of alignment between business and IT. It is a process of decomposing loose business strategies and requirements into meaningful operational design -- of systems, of processes, of information, and of infrastructure. Often this EA manifests itself as sets of models and diagrams. If a picture is worth a thousand words, a model is worth a million! Unfortunately, within the English language most verbs can also be nouns, so EA, the process, is often confused with EA, the models.
BSP was developed in the '70s to provide a mechanism to ensure that when an organization invested in IT, it invested optimally and in support of its strategy. BSP also helped to ensure that processes were fixed before they were automated. We all know that when bad processes are automated, things just get worse at a faster pace.
Up until the early '90s, EA planning was a viable approach in its initial instantiation. As software evolved, becoming commercially available in the late '80s, it forced commoditization of hardware. The mantra changed from "nobody ever got fired for buying IBM" to "let the software drive the hardware decisions."
This philosophical change also led to a change in the way in which EA planning should have been performed. Doing future-state 5th normal form E-R diagrams for the entire enterprise was no longer an appropriate EA planning technique. Why? As the software market began to mature in the '90s, a rash of enterprise products emerged, all with their own data models. These included ERP, SCM and CRM. Those who abandoned EA planning altogether, however, were those feeling the pains of having multiple enterprise applications installed, replete with overlapping functional support and overlapping data sets.
Alas, while EA was no silver bullet, neither were the enterprise class of commercially available applications, particularly when installed devoid of sound planning and control. It is common to see organizations with multiple ERP systems. By having more than one ERP, doesn't that fundamentally remove the "E" from ERP?
Our studies show, however, that those with governed enterprise architecture standards in place during this timeframe enjoyed a 30% reduction in end-user computing costs.
One of the ways around the issues of security and control that make some businesses wary of cloud computing is to build a private cloud -- one that remains within the corporate firewall and is wholly controlled internally. Private clouds also increase the agility of IT an organization's IT infrastructure and make it easier to roll out new technology projects. Download this eBook to get the facts behind the private cloud and learn how your organization can get started.