Architecture Roadmap

Identify actions to realize your architecture

The Architecture Roadmap is designed to identify and list the actions that are required to realize your architecture. You lay out the individual actions on a timeline to show sequence and progression from the baseline architecture to your target architecture. This method uses the architecture roadmap to discuss the optimal implementation sequence and its steps.

GOAL

Visualize actions and dependencies that are required to realize the solution

PARTICIPANTS

Enterprise Architect, implementation expert

TIME NEEDED

Depends on complexity of the solution (30min to multiple days)

PHASE

Design

Before You Start

Describe your solution with functional components
To understand which tasks you need to complete, it is crucial to understand how your architecture looks like in detail.

Materials you will need

Templates for Download

Steps

  • Depends on solution complexity

Identify solution capabilities

First, think about the individual technical capabilities that are needed to realize your solution. Use the gathered information from the previous exercises about architecture building blocks and solution building blocks, that showcase the structure of your solution, and build on that. Each building block can be expressed by either one or multiple capabilities and every capability can cover one or multiple building blocks. Those capabilities are noted on the outer edge of the architecture roadmap.
Also define different phases of your roadmap and note them down at the top.
Example phases are “Build foundation” or “Roll out MVP”. You should also add an estimation of the expected time required for a phase. This helps to get a better understanding of the time horizon of the project.

Completed Example

  • Depends on solution complexity

Identify work packages

In this step you want to identify all the relevant work packages needed in the Architecture Roadmap.
Work packages are the individual actions that need to be done to implement your solution capabilities. Therefore, when defining work packages think about what tasks need to be done to transform the baseline architecture to your target architecture.
This could be anything from “Set up authentication”, “Integrate the Launchpad service” or “Implement the user interface of the approval application”.

Try to be as detailed as possible as these work packages might be used to estimate the total project costs. The roadmap is a crucial work product to decide if a project is viable.

  • Depends on solution complexity

Define sequence and dependencies

Lay out your previously defined work packages on a timeline defining the sequence of implementation.
Think about which actions need to take place at what point in time to realize the progression from baseline architecture to target architecture. Organize the work packages along the swimming lane of the respective solution capability.
Mark dependencies of different work packages with an arrow pointing to the work package which must be implemented subsequently. Each work package can depend on none, one or multiple other work packages and each work package might be required for none, one or multiple other work packages.

Some tasks might be needed for multiple business capabilities. Make sure to find them to ensure scaling effects are leveraged. Place those work package between the two swimming lanes and mark dependencies with arrows. For example, this might be the case for setting up a database that is used by multiple capabilities. Those work packages should be implemented as early as possible to ensure a steady flow of the project.

  • 90 minutes

Communicate your Architecture Roadmap

Informing your stakeholders (e.g. project managers or other architects) of the Architecture Roadmap is very important, as it will lead them on the way forward.
You should take your time and enable every stakeholder in-depth on the parts of the roadmap so they can understand the way forward with the solution. Also, this is often your last contact point in the project so you should make sure to hand-over all relevant information.

If you created a stakeholder matrix and communication plan consult it to check how this verification should be done. (e.g. by email or as part of regular stakeholder meetings).

You are done!

Make sure to take the Architecture Roadmap into account when discussing the implementation plan of your solution.