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

On starting a new EA group

Vote 0 Votes

Plan to fulfill the expectations of those who created or sponsored the EA group. After all, they pay the bill. So ask them what they expect.

In my experience, they would want to know how to select technology, what are the options, how to justify choices in order to minimise the cost and risk of IT. For that, they want you to come with principles and technology guidelines.

They would also want you to create a board to review solution architectures employing the principles. They would want you to provide an integrated IT view and standardise standardisation. They would like an IT roadmap and strategy.  But not least they would like you to come with a reference EA. Here is a Linkedin discussion on this topic.  

Still, in practice, most EAs do solution architecture work and reviews. That is because most current frameworks do not help much. 

They do also IT strategy and roadmapping. They usually come with a few principles which pass the practice test only occasionally. 

But they seldom come that with an EA reference model which is in fact the prime task of an EA without which no one should call himself an EA architect. Without the EA any solution review is subjective and roadmapping and strategy are patchy. Without it in fact, this work is performed as it was before the advent of EA.

That is, at best, EAs come bottom up with too many diagrams designed in isolation, that do not fit the enterprise architecture whole, in form, shape or content. 

The problem is how to do the modeling in an integrated manner. You need a framework that integrates the parts. Today's frameworks don't do that. The design should also start from the big picture, top-down, from a single page architecture cascading down to detailed domain architectures. I, personally, have seen no such architecture model till now.

Nevertheless, without the big picture of the business architecture, the technology architecture has little meaning since there is no indication of how it serves the business purpose, of how it delivers the products, how the business strategy maps to IT etc. 
As such, there is a small audience for the IT architecture alone. Not to mention that it is patchy failing to cover many business domains and end to end processes, which normally would be described by a business architecture. To realise a proper EA, I use own framework.

 also found that most EA frameworks look like EA development processes, which describe common and known good practices, rather than coming with frameworks that enable 

* your architecture models to fit in the integrated and coherent EA whole

* a generic business architecture that supports the IT architecture design 

* architecture templates that helps you jump start the EA modeling. 

In the first 100 days, an EA should come up with the EA framework and an one page architecture (covering both business and technology).

The EA should also plan the next steps, so that the stakeholders know what to expect.
At the six months milestone,  a strategy and roadmap should be proposed.
Tasks to be accomplished in the 100 days should be
* organise EA team
* establish EA governance (including principles)
* create EA site
* propose tool, if any (for EA repository)
* liaise with stakeholders to discover expectations and sell EA

I would procure and use the cheapest EA tool available, a free open source one, or none in the beginning, because they are taking your focus away from the EA. 

Tools may be a hindrance if you don't know what you are doing yet.  They need training. More often than not, they still look surviving from another IT era. Besides, the internal metamodel is seldom complete or right. You have to come with your own which may be hard, costly or impossible to implement in the tool. Tools are hard to maintain, upgrade and costly to license annually, in particular when you use them little, as it is the case much too often.

Archimate, for instance, is counter intuitive. It jumps directly to detail. It does not come with an intuitive framework so you can see the parts and the whole. The diagrams discourage the business audience. 

1 Comment

| Leave a comment

I like this article... simple and spot on with what I think right down to the Archimate tool. If starting a new EA one should do a high-level overview of the business and the IT and how they fit together in preparation for an eventual in depth breakout.

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