Enterprise Architecture is Dead, Long Live Enterprise Architecture!

Okay, at the outset let me admit the title was a clickbait! Now that I have your interest, I will in this article argue that Enterprise Architecture (EA) long from being dead, is just about maturing into a discipline of strategic importance to all organisations, and I hope the best of EA is yet to come!

I first heard about EA way back in 2006 when I attended a couple of workshops including the one on TOGAF. I remember concluding at the end of these explorations that the field appears promising, but its time has not yet come – at least for me. For, I was working in manufacturing industry and the then IT landscape in such organisations had only a few boxes on the diagram (typically an ERP at the middle).  In hindsight, I would argue EA was relevant even if you had a simple landscape (and ERP by no means is simple, being a core system for a manufacturing organisation). The challenge was mainly seen as a technical implementation of a so-called off-the-shelf software, and that there was nothing there to design (and the rest, as they say, is history).

Fast forward 15 years and the number of organisations seeking EAs is growing, and rightly so, with all the complexities arising out multiple clouds, data proliferation, business complexity, and the speed of change in general. And yet there is scepticism in some quarters around the value of EA. Here are I wish to point out that the issue is not EA itself but our understanding of what it means and more importantly where, when, and how it is done, and also who does it. If the terms why, what, where, when, how, and who do not ring a bell, they are the so called “primitives” that the Zachman Framework for EA advocates. And what better way to explain EA than its own framework? So here we go.

What: So what is EA? As explained in my earlier post, EA as it is commonly understood in the IT world, is the alignment of IT strategy with the business strategy and guiding the IT systems development to align with this overall organisational objectives. However, purists like Zachman treat EA as literally architecting the enterprise – the all of it not just the IT part – essentially as a framework for representing and guiding the design of an enterprise.

Why: So why architect when you can build? I think the Why already follows from the What. Who would not want to align their IT strategy and delivery to the overall objectives of the organisation? Everyone has limited resources and the best outcome from IT spend comes from aligning with – and one could argue, leading – the business strategy.

How: This is where the EA rubber hits the road and this is also where it often skids off the road. EA is best done by understanding the constituent elements (business, application, data, technology) and defining principles that guide the evolution of these elements – the focus is on overall benefit of the organisation not just the individual product, project, or solution.

Who: It is tempting to say that the Enterprise Architect architects the enterprise. However, the reality is much more complex. I have seen in my over two decades of work at the coalface of IT projects, that there are varying levels of design and different domain expertise that can contribute to the overall EA objectives. In effect EA is a team effort. Often a full time Enterprise Architect role can bring these differing perspectives together, but at times it is not affordable (or necessary) as long as there is a mechanism equivalent of the Architecture Review Board to guide the design.

When: The short answer is all the time. But there are some critical points in organisational journey when it is most effective. Core systems replacement programmes are the typical territory of EA. So are times when several interdependent projects are in flight with the need to ensure cross-project design alignment. Finally, any major IT project would benefit from (and will benefit the organisation in turn) aligning to EA before, during, and at the end of the project. Special callouts to agile projects that prefer to “design on the fly” that may result in “operation successful, patient dead” outcomes.

Where: EA is a function that typically sits in IT under the sponsorship of the CIO, which makes sense considering that the bulk of EA’s attention is on getting the design right for all the IT programmes. However, in not so distant future I am predicting it will sit under the sponsorship of the CEO as more organisations see the blurring of the distinction between technology and business – particularly in service-based organisations.

What is Enterprise Architecture?

Enterprise Architecture (EA) is often seen as too complex and academic to be of practical use in business settings. Sure, a formal vocabulary is unavoidable when describing a generic framework, but at the core of EA is alignment of IT strategy to the business strategy.

So let us start with some basic definitions. What is an Enterprise in the context of EA? It can be anything – a single business unit, a collection of business units or just a single department. Preferably it is the “entire” organisation, but in practice, it can be whatever the organisation in question wants to apply the EA rigour to. As for Architecture, I think the best definition is the one provided by TOGAF: “A formal descripton of a system, or a detailed plan of a system at a component level to guide its implementaton.”

So what then is EA? Again TOGAF gives a simple definition: “Enterprise Architecture provides a conceptual blueprint that defines the structure and operation of an organisation.” The intent of EA is to provids a strategic context for IT to evolve and support the business strategy.

Whether organisations formally embrace EA or not, the reality is that their IT is always evolving to its business strategy and needs. But instead of leaving this evolution to chance and point decisions, EA can provide a framework to avoid the “spaghetti” state. In this context, EA is often cited as analogous to town planning. A well planned town is a delight to visit and live in. On the other hand a collection of badly built (even with a few individually well designed) buildings often results in a mess that prevents the growth of a city from evolving into what it could potentially have been.

With this strategic intent, the EA becomes more of an investment than a cost. The EA outputs are no longer a necessary evil but valuable foundation for a sound enterprise. The business strategy is formally defined first (Business Architecture) which defines and drives IT Strategy (Application, Data and Technology Architecture). The principles and guidelines drive the solution designs in individual IT projects, reusing the building blocks already delivered. Also by following a formal architectural development method (like the TOGAF ADM) and a governance structure (Architecture Review Board), organisations further increase the chance of a coherent IT evolution that is not left to chance.