How to create an effective software architecture roadmap

What is a software architecture roadmap?        

Large-scale architecture initiatives, such as a shift from monolithic applications to microservices, contain an intimidating number of moving parts, steps and potential complications.

For example, team members want to automate a particular application process flow that touches many business units. They need to determine when the steps of this initiative can happen, how they'll control the costs and overhead involved and what data may become exposed from the changes, among other considerations. The software architecture roadmap details the steps involved in such an initiative, and how those changes will be implemented, explained Mark Richards, an independent software architecture consultant. Not all software initiatives warrant a comprehensive architecture roadmap. Architects should create them for large initiatives that cross multiple software systems across an organization.

But, why not use a roadmap for every initiative? Architecture roadmaps can be severe overkill, especially if the initiative is isolated to one particular system, Richards said. If the complexity of the documentation outweighs the scope of the project, developers will likely struggle to find the information they need quickly.

Iteration, portfolio and prioritization models

An effective software architecture roadmap contains three particular realms of planning, also called models:

• The iteration model, which addresses overall goals and project stages.
• The portfolio model, which details resource needs, work delegation and project timelines.
• The prioritization model, which identifies the most critical tasks to complete or changes in a project's priority.

All three models will shift and influence each other throughout the course of an initiative. "It's always a coordination between all three of these models -- each one influences the other," Richards said. "If a project is off track, it changes the priorities as well as the iterations."

Richards likened iteration, portfolio and prioritization models to cogs in a machine. "With cogs, if you change or move one, the other ones have to move as well," he said. "It's a great visualization for thinking about how all three of these models work in synergy."

Understanding the dynamic relationship between these three models can also help architects avoid what he refers to as irrational artifact attachment: a rigid preoccupation with completing certain projects or meeting particular deadlines without willingness to change.

"If you walk in after spending a month on that iteration plan, and say it isn't changing, you're simply setting yourself up for failure," he said. All three models will shift and influence each other throughout the course of an initiative.

The iteration model

The iteration model demonstrates how the architecture and related software systems will change and evolve on the way to a final goal. Each large iteration segment represents one milestone goal of an overall initiative, such as updating a particular application database or modernizing a set of legacy services. Then, each one of those segments contains a list of every project involved in meeting that milestone. For instance, a legacy service modernization iteration requires a review of the code, refactoring efforts, testing phases and deployment preparations.

While architects may feel pressured to create a realistic schedule from the start of the iteration modeling phase, Richards said that it's not harmful to be aspirational, imaginative or even mildly unrealistic at this stage. Since this is still an unrefined plan, try to ignore limitations like cost and staffing, and focus on goals.

"The iteration is the fun part, because you're starting with a blank piece of paper on a table," Richards explained. "In my mind, these boxes have no [real] cost associated with them whatsoever -- you asked me for a plan, I gave you a plan."

The portfolio model

Once an architect has an iteration model in place, the portfolio model injects reality into the roadmap. In this stage, the architect or software-side project lead analyzes the feasibility of the overall goal. They examine the initiative, the requirements for each planned iteration and the resources available for the individual projects within those iterations. The portfolio model documents what needs to happen in each of the small projects.  

Typically, architects answer questions such as:

• What is the size and scope of this project?
• What are the most important or business-critical projects?
• How many systems are affected by each iteration and project?
• What technologies and skills will we need in place?
• Can we build our own solutions, or will we need to buy?
• How much does our budget allow us to do?
• Do I have the staff needed for each project?

Dependencies are one of the most important things for architects to identify in the portfolio model, Richards said. For instance, if a project involves an update, migration or taking a particular set of application services offline, identify how many other software systems could be affected. Team dependencies are a factor, too -- if the work of one team relies on the results of another project, both teams' schedules will be affected. Project managers and architects should also account for the impact a project may have on other business or technology groups, such as security, which will likely affect the size and scope, Richards said. 

The prioritization model

The third component of the software architecture roadmap is prioritization. In this model, the architect, in conjunction with business analysts and stakeholders, reprioritizes and reschedules work based on factors like staff availability, budget size and conflicts between concurrent projects.

"You start reprioritizing the projects and moving them around, keeping the dependencies in mind ... and make sure that dependencies are actually preserved," Richards said.

Those dependencies identified in the portfolio model are a key part of the prioritization model. For instance, an architect sees that one project requires disconnecting a small server from a particular database, but this relatively simple task is scheduled late on the iteration's schedule. If that server has little or no systems that depend on it, the architect can move that project to an earlier date without issue. The team can tackle simple projects upfront, and then devote more time later to projects that will have a ripple effect on other systems.

How to draw a software architecture roadmap

Some organizations try to create roadmaps using Microsoft Excel and other text-based document types. To better illustrate and understand the project, Richards recommends a visual roadmap.

This is his advice for approaching this step-by-step:

1. Draw the iterations

Place each milestone of an initiative in the intended chronological order. Since large software departments typically work on two or more initiative projects at a time, the roadmap must contain a row or column that acts as a visual timeline of an overarching software initiative. This mockup reveals problems during development: overworked teams, conflicting projects, too many changes at once or gaps in the project where time goes to waste.

Richards recommends that architects create a table that places the iterative goals in a vertical column and lists the chronological segments in a horizontal row. The order of these iterations can change when the portfolio and prioritization models are solidified.

2. Add the details

Within each iteration segment, create boxes that indicate each individual project and outline the essential details. It's up to the architect's discretion how much detail to include, but the boxes need four fundamental pieces of information:

• the individual projects involved;
• the teams or individuals assigned to each task;
• the expected resource allocation; and
• the application services that the project will affect.

With details laid out, identify and map all the dependencies that exist between those projects. A simple approach is to draw connecting lines from one project's box to all the other tasks it will affect.

3. Prioritize projects

Review the software architecture roadmap for any concerning dependency relationships, schedule mismatches, redundant work, conflicting projects or other scenario that could threaten the overall initiative. Involve as many departments as possible in this stage, enabling security teams, business units and others the chance to weigh in and identify overlooked problems.

"Seeing the projects and the links between those boxes gives you a visual way to say 'wow, we have a long way to go,' or 'hey, we're pretty far along in this process,'" Richards said. "Most importantly, it allows me to see the dependencies."

Tools for creating roadmaps

Some vendors provide tools for enterprise-level roadmaps, such as ProductPlan and Asana. Since creating the visual doesn't require complex capabilities or software, freeform drawing tools fit the task. There are options such as Visio, a Microsoft-based diagramming and vector graphics app, and OmniGraffle, a diagramming app for macOS.

Software teams can get creative with roadmaps and find unique strategies to consolidate information. Richards recalled one approach that used a combination of the diagram and a dedicated wiki. Each box containing a project linked the user to a page within the wiki that provided all the necessary project details.