Business Scenarios & Gap Analysis
Start course

Course Description 

This module looks at the supporting guidelines and techniques of the Architecture Development Method, as well as governing the architecting process. This module is supported by videos and a PDF, and is followed by a quiz to help support your understanding. 

Learning Objectives

This module will cover:  

  • Architecture Governance  
  • Architecture Principles
  • Business Scenarios  
  • Gap Analysis  
  • Interoperability  
  • Business Transformation Readiness 
  • Risk Management  

 Intended Audience  

This course is intended for anyone looking to understand Enterprise Architecture.  It is helpful however to have several years' experience in IT in a variety of roles, or to have an understanding of Enterprise or IT Architecture. 

Prerequisites of the Certifications 

There are no formal pre-requisites for this course.  


We welcome all feedback and suggestions - please contact us at to let us know what you think. 


- Developing an architecture can be difficult. You need to understand the organizational context, as well as develop and build the architecture. Let's look at the Business Scenario and Gap Analysis techniques and how they can help with the ADM. In essence, it's a technique to validate, elaborate, and/or change the premise behind an architecture effort. The Business Scenario helps understand a crucial issue that needs to be resolved by understanding exactly what the business needs are and why they exist. The purpose of the Business Scenario is to gather information about real business problems and identify potential solutions to them. This can include the business and technology environments in which those problems occur, value chains that have been enabled by capabilities, and the desired outcomes of the proper execution of the system. It'll also want to include the human and computing actors who provide the capabilities to create or solve problems in the organization. The Business Scenario technique can be conducted in the preliminary phase, particularly when you are establishing the architecture practice and whenever it's necessary to understand key drivers and requirements. But it is mainly initiated in the Architecture Vision Phase as a means to understand the key drivers and the requirements of the organization. In Phase B, Business Architecture, it's used to understand additional business needs. Creating a Business Scenario can enable a greater understanding of the organizational context and is a helpful technique when developing an architecture. There's a guide on Business Scenarios in the TOGAF library that I would encourage you to read for a more in-depth understanding of the technique. Next, let's look at the Gap Analysis technique. Gap Analysis in the TOGAF framework are used to compare the target architecture with the baseline architecture. If something is needed in the target which is not in the baseline, then a gap of some kind exists. It can also be used to check if some gaps in the architecture exists, perhaps because of overlooking stakeholder concerns. The gaps are linked to the architecture domains. Business, data, application, and technology. When you've identified gaps, you'll need to identify the target building blocks you want to include in the architecture. They can then be compared with the existing, the baseline, building blocks, some of which may need completely new implementations, whilst others may need small amendments to meet the target. A useful way to visualize gaps is to use the Gap Analysis Matrix. The top row contains the target building blocks, those that you've already identified as being required for the enterprise. The left column contains the current building blocks. Notes appear within the matrix, adding further information about the gap. And crucially, the bottom row is used to confirm what gaps have been identified and how potentially to fill them. The final column is called Eliminated Services and is used to check if there are any gaps in the target architecture. In this example, the Broadcast building block is confirmed as being not required. But the Shared Screen, on reflection, does contain something useful which has been omitted from the original target. And that's it for this video. Next, we'll look at interoperability and business transformation readiness.

About the Author

In a varied career that began in 1974, John Coleshaw has trodden a relatively unusual path whereby his roles have split evenly between Business and IT. In the early 80s he was the Credit Manager for a multi-national electronics company, and at the same time built a computerised financial and credit analysis tool using the original version of the IBM PC. In the mid-80s, whilst performing the role of senior underwriter in the Credit Insurance industry, he managed the IT system, as well as developed an innovative risk analysis tool. At the start of the 90s, as a manager in a financial information company, he developed an early form of expert system whose purpose was to predict corporate failure.

His current career as an IT trainer began in 1998, specialising at the time in Object Oriented programming languages. In 2002 he started developing and delivering IT Architecture training and has now had the opportunity to meet and discuss architecture matters with over a thousand architects. The courses he trains now span both The Open Group (TOGAF and ArchiMate), and BCS.

He has a book to his name, one written in the late 80s on Credit Risk Analysis.