Enterprise Architecture is Dead -- Long Live Enterprise Architecture

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

A recent column by Chris Pickering suggested that Enterprise Architecture (EA) be allowed to rest in peace — or die as a concept or approach. His premise is that it either is no longer, or possibly never was, a valid approach to anything.

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.

Now we are in the xWeb era, which is the convergence of computation and communication. Web services and service-oriented architecture are the next big things. In the absence of good enterprise planning and design, how well will we fare when having to expose functions of our applications over the network to customers and trading partners?

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!