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.
Practice of EA 