Download the authoritative guide: Cloud Computing 2018: Using the Cloud to Transform Your Business
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.
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.
EA, the process, is needed now more than ever. It is needed to rationalize the excess of applications that exists in most organizations. It is needed to provide some level of design, governance and control to the digital chaos that exists in many businesses. Why is it that the U.S. Federal Government requires all federal agencies to do EA? For fun? Because there is a surplus of tax dollars that simply must be spent? We have learned over time again that appropriate up-front analysis leads to better design and delivery of change -- change in processes, change in data sets, and change in systems. The U.S. Federal Government requires that all agencies do EA to both enable inter-agency interoperability, and avoid waste.
Service Oriented Architecture, a philosophy of interoperability and reuse, is heavily reliant on EA to assist not just with identification of standards around formats, identifiers, and protocols, but also in assisting with the determination of what will become services and how these services can be combined into composite applications. EA is also required to deal with the multiple levels of metadata that will be required to enable effective service-oriented architectures, including web services.
Certainly EA has changed over the years, in both focus and approach. It is less focused on optimization of hardware assets and more focused on rationalizing and standardizing the existing plethora of IT assets in most organizations to prepare for a future that includes exposing processes and data to a broader audience (e.g., web services), while complying with ever-increasing legislation around those very same processes and data (e.g., Sarbanes-Oxley, HIPAA, etc.).
EA is required now, more than ever. Different techniques and approaches are required to deal with different times, trends and technologies. However, EA as a planning discipline is a mandate. EA is dead! Long live EA!