We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Enterprise Architecture Matters

Adrian Grigoriu

The Enterprise Architecture design has to begin with the whole rather than the parts

user-pic
Vote 0 Votes

Not unexpectedly, one of the key business stakeholders from finance asked - while I was in the process of "selling" him the EA - "why do we need EA, since you, in IT, surely have an architecture, don't you, otherwise how can the technology properly function and be maintained today?".

Good question, how does the technology keeps working without an architecture to describe its layout that would facilitate our understanding, defect fixing, improvements and evolution?

Well, I did not dare alienate him by responding that it works the same way as the business works today without having a coherent  picture of the overall business operation.

But we, EAs, have to explain ourselves a lot, unlike other professionals. And patience is king.

What I said in exchange, is that indeed, IT has currently have quite a few architecture diagrams. In fact, everybody seems to have a model in his drawer. But this is also the problem since these models don't add up to give the big picture. And they don't, since they were not produced to that purpose, but in isolation, with different tools, conventions, naming, scope and purpose in mind.  

I proposed an architecture on a table exercise where all diagrams in existence would be exhibited on a table. Did they form the bigger picture? Obviously not, because the glue and rules that connected the parts and made them look consistent was missing. The artefacts were often overlapping and parts were missing.

This is what EA aims to do, I continued: rather than providing the partial architectures designed in separation, we start from the EA big picture that can be decomposed in these architectures for each and every stakeholder. These diagrams, unlike the existing ones, interconnect to each other and are consistent in terms of components, terminology, drawing tools... and so on. And they can be put back in whole, in the Enterprise picture. 

As such you can navigate from one artefact to another in order to analyse an end to end process or navigate to the executing technology resources and people so that you can come out with costs, impacts of change and propose fixes.

What do you, the EA team, have to do for that? You'll provide the EA framework that everyone should use in designing own part, so that every artefact would have the same look and feel and refer to the same components and links. (see the FFLV-GODS framework).

You'll provide the principles, constraints, tools, repository and support for the stakeholders to produce the bit of architecture they are concerned with. You'll make sure that the bits would fit back into the EA.

Today, the technology up-keep depends too much, for anyone's liking, on the people who manned it, on their expensive skills and experience. In the absence of  architecture, the process is marred by guessing and debate, by trials and errors and as such, delays that cost the enterprise much more. EA will come with the enterprise layout and with the up-keep process that would help optimise this process.

EA would enable the logical identification of a defect using the business architecture and afterward, its quick fix using the corresponding technology architecture.

You also need EA for the process of keeping update the existing designs to fit the picture of the consistent whole. 

Therefore, rather than coming bottom up to discover the enterprise with isolated parts, you come top down as well, to make sure that the parts fit the whole, that gives us the end to end picture. Again FFLV-GODS provides this big picture and framework.

Imagine now that the enterprise is a real tri-dimensional system. We can take out a part, document and fix it. And then put it back. But how could you put the parts back in the whole if there is no whole to begin with? 

You as EA architects do not improve the enterprise, but produce the EA framework and the governance that guides the enterprise stakeholders in consistently producing the EA artefacts of their concern. 
Then, based on the resulting EA, and with the guidance of the architect and EA method, stakeholders implement fixes and changes in their parts of the enterprise, in synergy but according to the EA roadmap.

EA methods today do not support the top-down design starting from the whole because they simply do not supply a framework in which the parts fit back. Also they do not have a concept of one page enterprise architecture that would be the EA artefact used by all stakeholders.

Enhanced by Zemanta

Leave a comment

Adrian Grigoriu blogs about everything relating to enterprise and business architecture, SOA, frameworks, design, planning, execution, organization and related issues.

Adrian Grigoriu

Adrian is an executive consultant in enterprise architecture, former head of enterprise architecture at Ofcom, the spectrum and broadcasting U.K. regulatory agency and chief architect at TM Forum, an organization providing a reference integrated business architecture framework, best practices and standards for the telecommunications and digital media industries. He also was a high technology, enterprise architecture and strategy senior manager at Accenture and Vodafone, and a principal consultant and lead architect at Qantas, Logica, Lucent Bell Labs and Nokia. He is the author of two books on enterprise architecture development available on Kindle and published articles with BPTrends, the Microsoft Architecture Journal and the EI magazine. Shortlisted by Computer Weekly for the IT Industry blogger of the year 2011.

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT