EA Dynamics Logo

Specialists in Enterprise Architecture

TOGAF accreditation Logo

Specialists in Enterprise Architecture

Tel: 01443 449886 

Gap analysis.

TOGAF Enterprise Architecture gap analysis.

There are numerous references to gap analysis within enterprise architecture and business analysis – but often delegates want to understand more about how gap analysis fits into the modelling architecture with real life contextual examples.
This article keeps the focus on the high level principles of gap analysis. Organisations use a variety of frameworks - such as MODAF or Zachman to capture the various modelling diagrams for gap analysis.  The following examples therefore refer to strategic, operational and technology views that can relate to the various modelling frameworks, enabling this generic explanation to fit multiple modelling frameworks.

Some of the data required for a new capability may not yet exist.  Even if the data currently exists, it may not be located where needed, or is not readily available, or it may not have the correctly related to relevant data.

Consider also both the applications and the technologies that are impacted, eliminated or created by the new capability.

When conducting a gap analysis it is essential to have clear 'vision' of the target state required and to understand the drivers, goals and outcomes required from developing the new capability from the existing model.  Once there is a clear and documented understanding of the target state it  helps form the picture - where are we now, where do we want to be and finally how are we going to get there?  

Measuring the expected benefits is a more achievable task once this clear understanding of the present and target state along with the goals and drivers is documented.

If existing modelling data already exists within the organisational modelling repository it is possible to identify the relevant areas that require analysis. The first steps is  to identify the data and diagrams that fall within the scope of the baseline gap analysis. For example changes in developing enhanced e-capability for capturing customer leads will impact the marketing department but have a more limited impact on product research. This scoping of affected parts of the organisation from a function and role perspective, process, data, application and systems focuses the analysis enabling effort to be optimised appropriate to the task in hand.  The governance and principles will ensure that the focused capability developed fits into the overall enterprise model in line with the principles and constraints. (i.e. appropriate technology is sourced in line with the enterprise principles stated.)

As organisations create (or include existing) components stored in the enterprise models representing the baseline architectures, the various layers of viewpoints are linked based on analysis of the dependencies.  By studying the baseline or ‘AS IS’ architecture unlinked views for the ‘in scope’ a capability areas help to highlight current gaps in the capabilities. 

It is important when conducting gap analysis to ensure that the ‘area of interest’ is correctly scoped.  By working with the relevant stakeholders and generating the requirements for the capability the model is able to depict the people, process and technology components that are impacted by the capability development. 

Once the scope is bounded, effort can focus upon identifying the gaps between baseline and target architectures.  Gaps could include people ( either retraining in a new role, or new role required).  Gaps could also be uncovered showing process inefficiencies.  The tools associated with the processes could also have missing or duplicated functionality.  Whilst analysing the information gaps do not forget to include measurement gaps, financial data and facilities gaps - as additional  people may not fit into the existing office space and this could result in a requirement for additional facilities.

Gap depencies analysis

Figure 1 - Dependencies

By analysing  diagrams within the model, gaps become more apparent - for example  tracing system functions to operational activities/business function  which lies within the scope may highlight gaps such as the baseline having operational or function with no corresponding dependency link to the system functionality.  (Figure 1 middle column)

Gap analysis can also be used to discover overlaps and duplication, i.e. redundancy in the provision of operational capability from more than one system capability. For instance, it is possible to perform an analysis of capabilities and systems highlighting all the systems that are able to support a particular type of operational activity. Check for any unnecessary duplication of functionality (and if found, eliminate it by redefining the applications concerned).

The target architectures are created by examining the stakeholder concerns and developing the requirement set which captures the functionality and attributes required to develop the target architecture.  By examining the additional requirements it is also possible to identify missing or additional dependencies required to satisfy the new capability requirement set and enabling the target capability to become fully operational.

The unlinked dependencies between the associated strategic, operational and technology views at the various layers often highlight gaps in the capability – analysis of the missing dependencies will confirm whether a gap exists or not.

Capturing the existing ‘As Is’ systems in the modelling tool and identifying the interface dependencies and the common use of technology components will often generate the higher level business requirements and dependencies at the operational and strategic level. (This activity is often referred to as reverse engineering dependencies.)

gap analysis reverse engineering


The basis for conducting a gap analysis, highlighting gaps or anomalies, is that any incompleteness or inaccuracies in the model associated with the enterprise architecture might lead to incorrect decisions being taken at a later date.

As the building blocks and dependencies are captured for the baseline and target architectures a matrix can be drawn up to highlight gaps.
When drawing up the matrix the architectural baseline building blocks are placed on the vertical axis and target building blocks are placed on the horizontal axis.  A new row is placed on the vertical axis labelled ‘New’ and a new column labelled ‘Eliminated’ is placed on the horizontal axis.

This simplistic example shows a customer booking capability being enhanced in the target architecture to include web portal for customer booking.  The existing postal service is being discontinued.  

Example shown below


Baseline Architecture 
Telephone Booking
Customer Booking
On line web booking Eliminated
Telephone Booking
Postal Service X
Customer Booking
Potential Match
New X - includes interface into customer database


Benefits management.

By having an existing baseline architecture in place it is possible to use the existing performance metrics and capabilities as the initial metrics – as the new capability is realised the benefits analysis will be able to use the initial metrics to help demonstrate added value and additional outputs generated by the new capabilities ( It is beneficial to show hard figures for new capabilities, although please bear in mind some benefits may be ‘intangible’ or ‘soft’ benefits, which are harder to evaluate and measure.)

It is advisable to state how the benefits will be measured and quantified up front.  The measurements can then be monitored after the new capability is implemented to measure if the new capability brought about the expected benefits. 

If the benefits and measurements are agreed prior to implementation, there is more confidence by the stakeholders involved that the measurement targets were not deliberately retro fitted to give distorted results relating to the success of the new capability.