Roadmap of Roadmaps
An Architecture tool, a planning metaphor and perhaps even an organizational framework.
One of the most recognizable deliverables produced by an IT or Enterprise Architect (EA) is the Roadmap. There is some confusion as to what these are and how they’re used though. I had an interesting discussion with another EA on Linkedin.com the other day (based on a post that she had made) about whether Roadmaps where limited to Portfolio Management or not and during that discussion I coined the expression “Roadmap of Roadmaps” to distinguish a Portfolio-level effort from more tactical ones. At this point, it’s a good idea to posit some definitions…
Generic Roadmap - This refers to a graphical representation of programs and / or project timelines, typically arrayed in relation to one another and often times separated in thematic groups. These Roadmaps can be created ad hoc using tools such as PowerPoint or in specialized diagramming, EA, Project Management or DevOps related software.
Note, that the definition above does not indicate whether the Roadmaps are Enterprise scale or not.
Roadmap of Roadmaps - While this might also be referred to as a Portfolio or Enterprise Roadmap, it may not be (it could for example just represent a large Transformation initiative. The main premise here is that there is a top-level timeline view which can be expanded or drilled-down into many smaller, more tactical Roadmaps. We could also refer to this as a Meta-Roadmap.
How is this different than a Project Plan? Well, it’s not as detailed and it doesn’t need to be created in a Project Management tool (something like MS Project), thus it doesn’t have to be in Gantt Chart format. The one above uses a “Milestone” convention, but Roadmaps don’t have to and I’ve created many without them.
Why Do We Need Roadmaps Anyway? The Map Metaphor
Once upon a time, before Google Maps, people used physical maps to help navigate their way on trips. There was even a variation of the standard maps produced by AAA called a TripTik (which has since been digitized, although I’m not sure if anyone uses it now), that broke down the proposed journey into segments, highlighting the route and sometimes pointing out things along the way. In that context, the state level or perhaps national-level map was the Roadmap of Roadmaps and the TripTik was the proposed itinerary for a specific vacation. This is the basis for the Architectural metaphors here - Roadmaps should visually illustrate where our travels will take us and explicitly point out how we’re getting from A to B. But it’s also important to mention that this metaphor is also a recognition of the power of “visual planning.” In other words, the Roadmap is more than a simple map, it’s a way to chart our expectations over time (this is how we go from a geographic to a temporal metaphor).
In other words, locations or destinations on a map become “abstracted” into timelines across capability categories (as opposed merely to project abstractions).
So, the reason we have Roadmaps to facilitate the ability to condense or abstract complex planning into an easily communicable / readable format. At this point, it’s worthwhile to step back in history a little bit. In 1990’s I first became acquainted with something referred to as Program Management Plans (PMPs). These had been around at least since the 1980’s and in most cases they were associated with Government projects as Contract Deliverables - (or CDRLs). A PMP was typically a long document (dozens of pages and maybe more than 100 depending on the nature or size of the project or program) that described how the program would be managed. Sometimes such documents included visualizations of project schedules, but sometimes they didn’t. Interestingly, few of these documents were built by or with the aid of Information Architects (even though such roles were becoming fairly commonplace by the early 1990s). The PMPs were typically the province of the Program and Project Managers.
The whole point of having one though was to demonstrate that the folks who won contract had actually thought through their plan (and used some sort coherent methodology to accomplish that). These PMPs were applied to all sorts of programs, but IT programs became the most common place to see them after awhile. Within the field of Project Management we also had the Gantt Chart became more universally prevalent too. Yes, these types of charts weren’t new per se, but they got built into common practice for IT projects around the 1990’s.
A Gantt Chart is a visual project management tool that uses horizontal bar charts to schedule tasks against a timeline, showing start/end dates, durations, and dependencies. (these charts tend to follow very specific conventions are often more specific on dates etc. than Roadmaps as they are tied to Project Management tracking software - in other words, they’re used more for tracking than actual planning).
Let’s tie this together then to get a better picture. In the 1990’s, we started getting a lot of rather huge IT related projects or programs (some of them involving budgets in the $100’s of millions and requiring years to complete) that employed many subprojects each with their own Gannt Charts and supporting documentation like PMPs and almost none of that was being written or even reviewed by Architects. Not surprisingly, the lack of tech oversight in the planning of these programs or projects was starting to be blamed for the relatively poor success rates associated with them. And the trend seemed clear, the larger and more complex the program, the lower the odds or rates of success seemed to be. This trend was directly responsible for the rise of Enterprise Architecture as a practice and that in turn was codified in many places through laws like the Clinger Cohen Act (1996). It turns out that Roadmaps were perhaps the first and most obvious tool that EAs were able to apply to the problem-space and in particular - Meta-Roadmaps that helped to tie all of the smaller pieces together.
Why is this Valuable and How should Roadmaps be Used?
Interestingly, Roadmaps don’t tend to get pulled into Enterprise Architecture Frameworks (except through the most abstract or high level views). There’s always been a tension between Architects who came in with their Roadmaps and the Project Managers and all of their Gannt Charts (later replaced by Agile artifacts in many cases), but in terms of the value proposition - Roadmaps earned their rightful position at the top of the heap early on.
Well, what is that value proposition, you ask? The true value proposition is not documenting the project structure and tracking timelines after the fact - if that was all there was too it we could have stuck with Gantt Charts. Roadmaps instead allow us to do three crucial things that other project management artifacts don’t:
They allow us to brainstorm planning in real time (in advance). In other words, every program or project plan should be mapped out before being fully fleshed out and approved.
Roadmaps allow us to connect everything (that’s occurring) in motion within a coherent context both in advance and in motion without having to link every detail across the various portions (which can be a fairly time consuming effort).
And if the Roadmap produced by or in cooperation with Architects, they’ve got technical guidance and oversight baked in. This then becomes perhaps the single most important Architecture-driven risk avoidance mechanism for IT, period.
The last point there is particularly important; if a technical project management specialist who doesn’t perhaps fully understand the technologies being applied in a particular project is given full planning responsibility, what are the odds that this person is going to get it right? They’re actually pretty low and this has been borne out by a lot of IT industry projects statistics over the past 35 or more years. This is not to knock tech managers; in fact many of them are quite knowledgeable about the technology they tend to work with - but unfortunately, many aren’t. This also implies that Architects should have a highly technical background and it turns out that some of them don’t either. But typically, Architects will have a) a more technical background than managers and b) a job role that includes them tracking all of the various technologies being applied in their organization and not just one. This then gives Architects a somewhat better chance at:
Identifying false assumptions being made up front that could later blow up the project.
Identifying dependencies and constraints that others might not have seen.
Aligning business goals with technical realities.
And all of those things it turns out are critical to IT Program or Project success. In our next article in this series, we’re going to delve into the process of constructing Roadmaps.
Copyright 2026, The IT Architecture Journal (ITAJ)