Architecture Roadmapping is an important part of Enterprise Architecture. The creation of a roadmap enables an organization to develop initiatives that are in line with defined goals and corresponding objectives. In effect, a roadmap represents the realization of the organization’s strategy, visualized in concrete and defined steps.

A roadmap cannot be created without goals and objectives. These key components of the strategy are defined using SMART criteria. This makes them clear, realistic (or relevant) and, above all, measurable. The latter is especially important for translating goals and objectives into initiatives. The initiatives can then be plotted over time. Plotting initiatives over time is done using Architecture Roadmapping.

Essential elements

Goals and objectives are the foundation of an architecture roadmap. Although these elements are not the final components shown on the roadmap, they play an important role. The initiatives shown on the roadmap need to be related to the goals and objectives.

• Goals. The development of goals is critical for defining strategic objectives, guiding architectural decisions, and ensuring alignment between business needs and IT solutions. Goals provide a basis for prioritizing efforts, measuring success, and maintaining focus on achieving desired outcomes for the organization. A goal is a fundamental concept used to represent the desired outcome or objective that an organization seeks to achieve.
• Objectives. Like goals, objectives align with the organization’s strategy. Also like goals, they are defined in a specific, measurable, achievable, relevant, and time-bound manner. Objectives serve as actionable guidelines that guide architectural decisions, resource allocation, and performance measurement. Objectives provide a more concrete and detailed expression of the broader goals, breaking them down into manageable and achievable components. They serve as actionable targets that guide the organization’s efforts in pursuit of its strategic intent.
• Initiatives. Initiatives are actually a collection of high-level activities to be performed by one or more departments. Activities, as opposed to initiatives, are substantive and detailed work to be done. A set or cluster of activities is called an initiative.

Applying the method

Creating the roadmap is part of stage three of the Enterprise Architecture Implementation Wheel (Execute), and in particular step two of that stage. In order to complete the step of creating a roadmap, two things need to be accomplished.

First, an overview of the initiatives to be planned that will flesh out the roadmap is needed. In addition, it is desirable to be able to relate these initiatives to business goals and objectives. The Work Package Portfolio Map and Roadmap architecture deliverables provide the desired insight.

Work packages

High-level work packages are similar to initiatives. As mentioned a few paragraphs earlier, a grouping of multiple work packages can be considered an initiative. These clusters of work packages often form a project, program, or even a portfolio. Initiatives do the same.

A work package generally does not describe an ongoing activity such as a business process. The subject of the work package is performed once and produces a well-defined end result. This is usually a goal or objective. A work package can be used to model tasks within a project, entire projects, programs, or entire portfolios. In an agile context, a work package can be used to model the work done in an agile iteration (e.g., a sprint) or in a higher-level increment. Initiatives work similarly.

The TOGAF Standard defines a work package as a set of actions aimed at achieving one or more objectives.

A set of actions identified to achieve one or more objectives for the business. A work package can be a part of a project, a complete project, or a program [1].

Creating the roadmap

Once it is clear what the organization’s goals and corresponding objectives are, it is possible to develop initiatives. When implemented, these initiatives realize (part of) the objectives. Therefore, it is important to have a clear picture of the initiatives so that steering can take place at the right time. Having a roadmap of initiatives helps tremendously.

As we read earlier, initiatives are visualized using the Work Package element. A work package contains a description of the initiative and has a start and end date. Work packages can be associated with additional information such as status, cost, or ownership. The work packages are plotted over time in a roadmap using architecture tools.

The roadmap in the figure above shows a goal on the left side that encapsulates the objectives that belong to that goal. Each work package is horizontally aligned with its corresponding objective. The relation shown between the work packages tells us that the work packages are interdependent. In this example, this means that stage one must be completed before stage two can begin, and so on.

Adding information properties

By adding information properties to the work packages, it is possible to create various cross-sections of the roadmap. For example, the additional property status can be added to the work packages. This allows us to create a colored overview of the progress made of implementing the organization’s strategy. When there are several work packages associated with a single objective, it is possible to zoom in on a specific objective to show the status of its associated initiatives. This provides senior management with a very powerful steering tool.

Dependencies

An additional benefit of mapping initiatives over time using a roadmap is that it provides insight into the interrelationships and possible dependencies between and among initiatives. This is where the power of a roadmap comes into play. Being able to manage dependencies in the context of achieving organizational goals is usually one of the pain points in executing strategy correctly. A roadmap can show at a glance where the dependencies are between initiatives, what additional costs may be involved, and who in the organization is responsible for their implementation.

Further reading

For more information on the use and application of an Architecture Roadmap, see my book Getting Started with Enterprise Architecture. In the book, I describe in detail how to create a Work Package Portfolio Map and how to create a Roadmap based on it. I also provide information on how to create and properly formulate goals and objectives.

Conclusion

With this blog, I have tried to make the topic of Architecture Roadmapping more tangible. Of course, there are several ways to create a roadmap. The way described in this blog is one that is consistent with the Enterprise Architecture Implementation Wheel I developed.

Do you have other ideas or do you usually take a different approach? Let me know in the comments section below.

[1] The Open Group, The TOGAF® Standard, 10th Edition, Introduction and Core Concepts. ’s-Hertogenbosch: Van Haren Publishing, 2022.