How was Training?

more

Excellent, thought provoking and well laid out - Global Automation Manager, Experian, UK, Mar 2013

Recommend PEAF?

more

Yes - Given the practical nature of the approach I would recommend PEAF above other EA frameworks (Togaf, CEAF) - ECM Architect, EASA, Germany, Jan 2015

  Introduction   Context   Methods   Artefacts   Culture   Environment   Adoption  

Desktop

Mobile


 

<< Previous <<

>> Next >>

"Do I have to 'do' the whole Enterprise?"

"Can I start small and get some benefits first and then grow it out?"

"Can I start with one Department or Business Unit?"

The short answer is - No!

The long answer is - It depends!

When thinking about Enterprise Architecture, most people think about the noun - the structure of the Enterprise. This is perfectly understandable since an Enterprise Architecture is exactly that - the structure of the Enterprise. It therefore logically (albeit incorrectly) follows that you can decide to make the domain of "Enterprise Architecture" a sub-part of the whole Enterprise structure - like a Department or a Business Unit for example. Hence people often say "we will start small and just 'do' EA on one Business Unit". However, if you think about the purpose of EA and what it is used for, then this simplistic structural view breaks down.

If we think about the verb - "doing" Enterprise Architecture (primarily Roadmapping) we begin to understand that the domain we choose to "do" EA on, is not determined by selecting an arbitrary part of the Enterprise like a Business Unit, but upon what needs to be Transformed and why, which is driven by the Enterprise Strategy (or more specifically, the part of the Enterprise Strategy that the Enterprise cannot satisfy, or only partially satisfy, in its current structural state.

So, the structure of what is in scope in terms of EA is not defined by a Business Unit or a Department per se, but by the parts of the Enterprise that the people involved in Roadmapping deem requires Transformation. Hence "doing" EA is already descoped to comprise only the parts of the Enterprise that currently need to change in response to the current Enterprise Strategy.

Having now understood this view, if we consider again the initial questions regarding "starting small" and "reducing the scope", it is clear that we are now referring to reducing the scope of work undertaken by the people involved in Roadmapping. If we wished to do this, we are in effect saying we would utilise EA tools and techniques for doing some of the roadmapping work and not use them for the remaining roadmapping work. This does not make much sense.

So, the "scope" of EA (at any point in time) is determined by the Enterprise Strategy (at that point in time) not on a Department or Business Unit level.

However, there are two slight (but very important) exceptions to this rule.

      The first is when an Enterprise has more than one Roadmapping group. For example if a very large Enterprise is composed of some large parts and these large parts each have their own Roadmapping groups, then you could reduce the scope of EA to one of those groups. Not because they are a separate group, but because they have a separate Roadmapping group.

 

What do people in your Enterprise think about the scope of EA?

Are they arbitrarily trying to descope EA to a structural part of the Enterprise?

If they are, how does this fit in with the work being undertaken by the people involved in Roadmapping?

Does your Enterprise have more than one Roadmapping Group?

 

      The second is when there is an EA Catalyst...






 

2008-2016 Pragmatic EA Ltd