Blog Series – Where should I start with my EA?

Play 1 – Anchoring on Applications, Bringing in Business Elements

When someone takes Essential, our Enterprise Architecture Management Tool, we are often asked where we would recommend that they start with their EA.  Being Enterprise Architect’s, our answer usually starts with “It depends…….”!!  But in truth, it really does depend.  The two key factors that need to be considered are; where are the biggest ‘fires’ in the organisation, i.e. what is everyone concerned about/shouting about, and what information  can you get hold of quickly?

The first thing to understand is who your key stakeholder is and what is keeping them awake at night.  If you can provide information that will support the decision analysis around this area, then that is a great start.  The second is to understand the information and data you will need to capture in order to enable this – if you can utilise data you already have access to, wherever and however that is held, then you can respond really quickly, in a matter of weeks.

In this series of blogs, we’re going to look at common scenarios that we encounter and the initial steps we recommend.

The scenario we encounter most frequently is the organisation that has grown organically with a federated approach or through mergers and acquisitions.  In both cases we often find that there is a push for application rationalisation to provide efficiencies through both cost saving and speeding up IT’s ability to respond to the business needs.  However, this is often hindered by the lack of visibility of IT assets across the organisation and how they support the business.

Below are condensed extracts from our EA Playbook that describe how to manage this scenario and to achieve a positive outcome.  The playbook assumes you have a target state defined for your IT estate, so you know where you are going, and against which you can anchor your work.

Before you start, the key things to note here are the pre-requisites to starting the play; it is imperative that you have the support of a senior leader and that they communicate to the IT Teams, and also that you have access to a friendly business contact with excellent knowledge of the business.  Once you can corral the data to produce an application list with the links to the business overlaid, you should expect to be able to engage both the CIO and the business leaders in conversations about exactly where efficiency opportunities exist.  By presenting your architecture models in a non-technical way that can engage senior leaders, they will be able to see clearly where there is duplication and understand why application X costs them more and why application Y slows them down.  Identifying the ‘low hanging fruit’ in terms of cost savings can provide a springboard for moving forward in allowing IT to become a true partner with whom the business want to engage to meet their strategic business goals.

The approach we’d suggest is:

  • Publish an up to date application catalogue
  • Engage the CIO by using the application catalogue as an anchor to create an application reference model and then identify duplication within the application estate from a capability perspective
  • Engage with your business contact to overlay the business view and identify potential duplication from a business perspective. Start with one business area and complete that first as a demonstrator
  • Bring in costs for those areas of interest, i.e. where there is application duplication
  • Start to understand complexity of integration for those high priority candidate applications

Some of the key Essential views that support this approach are:

Business Application Footprint  (See live view demo here)
Key business architecture view showing how applications map to business capabilities, with TOM and capability differentiation.

Application Reference Model  (See live view demo here)
Shows Application Capabilities and Services, with Applications mapped.  Highlights duplication across application services.

Application Rationalisation Analysis  (See live view demo here)
Displays opportunities for rationalisation across applications and application services, with various filters for specific criteria.

Business Process Family Summary  (See live view demo here)
Shows all the business processes contained in a process family, including performing organisations and applications used.  Highlights where there are non-standard processes and different supporting applications used across the organisation, supporting the identification of opportunities to re-engineer and automate processes.

We’ll be publishing extracts covering different scenarios on a monthly basis.  If you’d like further details on the scenarios or playbooks please contact us here.

Identify the problems your EA needs to solve

In my opinion, when introducing enterprise architecture into an organisation the most crucial aspect is the identification of the problem you need it to solve.  And to do this effectively I believe that you need to clearly understand the aims and objectives of the business at that time.

We often find the EA team sitting within the IT organisation, but the team still needs to ensure that the identification of need is business led and that the EA is not used simply to document technical IT issues.

For example, it may be that the most important objective for the business at a point in time is to reduce costs to remain competitive in its pricing.  Enterprise Architecture can meet this need in a number of ways depending on the company in question, but one way will be to capture the current state in the application architecture layer to allow consolidation of applications and thereby achieve cost reductions.

However, this would be a wholly inappropriate response if the business need were to expand into new markets.  In this case the Enterprise Architecture should be identifying common processes and services that could be shared across divergent businesses to aid speed of change and agility.

This is at the crux of the reason that, to date, many companies are not satisfied with their EA initiative.  All too often the EA will follow a prescribed, often IT based, root; lets capture the current state first; lets create an application catalogue; lets sort out our integration architecture; without first determining what the business needs it to do.

Once the link to business need is in place the EA can begin to provide what the business needs and positive results will be quickly seen.

Once the business need is identified, it’s time to consider the tools, people and processes needed to support it.  In terms of processes we have identified two major contributing factors to a successful EA, ‘understanding’ and ‘control’.

By ‘understanding’, we mean having a coherent view of the business and IT assets of your enterprise readily available and accessible in order to support well-informed tactical and strategic decision-making.  As the amount of information to pull together is often large, tools with the right information captured will give the understanding part of the equation.

By ‘control’, we mean having appropriate processes and techniques in place to manage and co-ordinate changes to these assets in line with these decisions.

In general, many of the problems that an EA will solve will be IT related, but the link with the business is imperative to ensure that the problem is the most relevant at that time and, crucially, that the EA Team are seen as making a real difference to the business in a relatively short time space.