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.

Strategy Management and Enterprise Architecture

We have noticed that many organisations are currently looking to their EA to support their strategy management, whether that be business and IT or just IT focused.  This is quite a shift for some organisations in moving EA up the stack and out of project or domain focused architecture to one that provides a broader, higher level view.

Our Strategy Management release is, therefore, very timely.  It has been in development for some time and was the focus of ECP 4, we would like to acknowledge and thank the community for their contributions to the release.   We have been using it at one of our global clients for some time and it is, therefore, released with us knowing that it actually works in real life situations – in a global organisation that has distributed businesses with differing regional and organisational objectives. 

A very brief overview of the key elements in this release is given below, but for full details see the release documentation:-

  • Architecture States – represent the different states of your architecture.  Sometimes these are referred to as ‘current state’ and ‘future state’, but we think it is best to avoid these terms as your current state is always evolving and will eventually (one would hope!) become your future state, which makes everything somewhat confusing.  In our opinion it is better to actually refer to the state you are in (politely of course!) and the state you want to be in, including the steps in between.  So, an example of the type of naming we would suggest is ‘manual invoicing’, then ‘automated payment – UK’, followed by ‘automated invoicing – UK ’ and finally ‘fully automated invoicing’ , which allow you to understand exactly what each architecture state is referring to. 
    An architecture state can relate to one or all of the layers of the architecture, and this will depend on the type of project that is being transitioned. 
    We would expect there to be many of these very specific architecture states that reflect different areas of focus, rather than having a very few states that represent the entire EA at specific points in time.  We think the idea of lots of ‘smaller’, more specific architecture states is very powerful for managing the complexity of the progression of the architecture; break it into manageable chunks that deal with specific programmes or areas of interest and use lots of specific, focussed roadmaps rather than having one unwieldy uber roadmap.  However, if that is what you need to manage the transition of your EA then you can, of course, do just that! 
  • Roadmap Model – is the pictorial representation showing how the architecture(s) will transition between the various different states, which are shown as roadmap milestones on the model.  A timeline for this transitioning can also be included in the model.
  • Strategic Plans – hold the detail of how the organisation plans to transition from one state to another and are implemented by Projects, which can be grouped into Programmes.  Strategic Plans also hold the detail of what Issues are being addressed and Objectives are being met by the implementation of the Strategic Plans. 

There are a number of standard views released with the pack, but in true Essential spirit we expect users to develop their own views to meet the needs of their organisation.  The type of views we envisage being used are, for example, a view that maps Projects to Issues and Objectives, so you can see which projects support which Objectives and resolve which Issues.  This can be useful in allocating resources to the areas providing most benefit to the organisation. 

We feel that this is a key area of EA, and additionally it is one that is, or should be, the focus of many organisations at the moment as they move forward following the recession.  Using EA to assist with the strategy management within an organisation is really where the big pay back from EA can start to be seen.  Of course, all the underlying activities and effort are also crucial and can provide benefits on a project or region or domain basis, but using EA to support strategy management is the activity that can provide the overall view of where the organisation is now, where it wants to be, the plans it has for moving there and, crucially, can be used to ensure the organisation actually gets there.  It can do this by analysing information and then providing the insights, as stakeholder specific views, that highlight potential pitfalls and areas of opportunity and allowing these to be used to aid decision making and ensure the strategic plans are achieved.

We are always keen to hear your views, please let us know if you have any comments.

EA Maturity Self Assessment Tools

I have recently noticed a number of articles discussing the use of various maturity self assessment tools, and last week received notification that Forrester have launched a new tool.  In view of this current interest, I thought I would bring attention to a tool that we wrote and released a couple of years ago – EAvaluator – that is available for use from our EAS website.  The tool is free to use, and we collect no data about organisations so there is complete anonymity.

EAvaluator is a rules-driven assessment which takes the form of a multiple choice questionnaire.  Simply answer the sixteen questions, which should take about five minutes, and EAvaluator will provide an assessment of your organisation’s maturity broken down into eleven architecture disciplines.  The disciplines include things such as Architecture Process, Business Linkage, Decision Support and IT Investment and Acquisition.  For each of these eleven disciplines you are presented with a 12 bar indicator which gives you a rating for that category from 1-5 and some suggestions of what may be required to move to the next maturity level.

When we developed the tool we toyed with the idea of producing an overall assessment rating with some idea of priority regarding what to tackle first.  We decided not to do this as we were unsure of the benefit, thinking that actually focusing on the maturity level for each of the disciplines is more useful than simply looking at one overall score.

We have had feedback, however, that an overall assessment level is something that users of EAvaluator would like, and we noticed that Forrester did have an overall mark in their tool.  I guess that it is easier to monitor and report on one rather than eleven marks, so this is something that we have added to our list of things to look at – although unless we get feedback to the contrary – it is behind a number of Essential updates that we have planned.

However, creating this overall score is not as straightforward as simply adding up the scores and dividing by 16 as, obviously, some areas are more critical than others.  For example if you had a 5 for Architecture Communication but a 1 for Architecture Process and Architecture Development then actually the overall score should be nearer 1 than 2.5 as clearly there is little point doing fantastic communications if there is nothing of value to communicate – it isn’t always true that any publicity is good publicity!!  Any overall score would need to be rules driven and assess the maturity of each of the disciplines not only individually, but also compared to each other to give a true overall mark.

We think that maturity assessment tools are useful to allow you to take a step back, look at what is going well and areas that have maybe been overlooked and assess, with your particular organisation’s issues in mind, where to focus next.

We would be pleased to hear any feedback that you have on EAvaluator, or maturity assessments in general.