When systems and processes are changing – and when the infrastructure they rely on doesn’t stay still either – it can become useful to see where the dependencies are. Roadmapping is a family of techniques to tackle that issue, and I went to a roadmapping workshop to delve deeper into them.

The workshop was organised by our architecture repository vendor (Avolution), but the idea is not dependent on that system. You can make a roadmap in PowerPoint. It’s just easier to marshal the data you need from a system that already has application and organisation data in it, and that knows about processes, projects and deliverables.

The reason you need so many different kinds of data indicates why a roadmap can be necessary: it can show the gaps, overlaps and dependencies between change programmes and projects. That is: while all the resources and what happens to them can be well understood and planned within a programme or project, there are aspects that can easily get lost between multiple programmes. For example, programme A could simply assume that some peripheral but crucial data will be available in two years’ time, only to find that another project B is planning to change that data within a year.

Roadmaps can also show when multiple predictable issues are due: new regulations, for example, or the end of life of technologies. Those are simple dates in principle, but often have multiple dependencies between them, and from there to the processes and people who rely on those technologies. For example, it’s easy to miss that one widely used webtool may have no planned successor, even though the application technology it is built with has a dependency on a platform or language that will come out of support in a few months’ time.

Roadmaps can take many forms, but there are broadly four different types, in ascending order of effort, complexity and sophistication:

Heatmaps and recommendation tagging can take the form of a simple table that uses colour to indicate which technologies are in what stage of their lifecycle. In the following example, a set of fundamental application server, database and operating system technologies are grouped together, tagged with their lifecycle stage and mapped to applications, databases, infrastructure and servers.

A lifecycle chart takes similar data and projects it on a timeline:

Work package diagrams take more data and start to map out what changes in which work package (of which project or programme).

Multiple architectures, finally, map out not one possible future, but multiple ones. This allows you to optimise the organisation around different goals, and compare what the results could be.

Pretty pictures, however, are not enough. Not even when they are based on real data. For success, a number of factors need attention:

1. Provide clear direction
2. Turn strategy into an executable plan
3. Provide a compelling case for change
4. Identify risks and the strategies to manage them
5. Remain current, accurate and relevant.

For the University, change programmes such as Service Excellence cover points 1 through 3 well. Where data driven roadmaps could add value is in point 4; the identification of risk between programmes and projects, and the support of strategies to manage them. The challenge, however, is in 5; to keep the roadmaps current, accurate and relevant. For that, we need to involve the right people, set up processes and automate data import and visualisation as much as possible. Stay tuned.

(All screenshots are from Avolution ABACUS example files and slides)

The why and how of road mapping / Information Services Applications Directorate Blog by is licensed under a