Is the concept of a “roadmap” working against Enterprise Architecture?

Isaac Asimov once said, “It's not so much what you have to learn if you accept weird theories, it's what you have to unlearn.” 

When we first teach business stakeholders about Enterprise Architecture, we have to help them to unlearn some bad habits.  We have to help business people to unlearn their reliance on hierarchy and to begin to trust real data, analysis, and measurement to affect change in their own companies.  We have to replace old and worn out concepts, ones that led to early success but will not lead to ultimate success, with new ideas.  We have to replace bad practices with good ones.

So why do we replace “management by gut feel” with a flawed and incomplete metaphor: the concept of a roadmap?

The roadmap is one of the very first things that most Enterprise Architects ever produce that the business will actually see as valuable.  Don’t get me wrong… goals maps and capability assessments are valuable… but they are not so valuable that business people will pay to have highly paid people on staff to produce them over and over.  Once, yes, but not every year.  Not unless there’s something tangible and useful that they can use.  A roadmap, on the other hand, is directly useful.  It is the result of a great deal of thinking and planning and illustrates, for all stakeholders, the order in which a problem will be attacked, by which teams, with all the interdependencies, tradeoffs, and constraints considered.  It is the output that, we tell them, reduces the likelihood of failure in an area of business that normally fails: the effort of change.

There is no debate that the EA roadmap, properly executed, is valuable.  However, the roadmap, properly executed, is not a map of roads.  It is not an illustration of all of the possible connections between point A and point B across a landscape.  The metaphor is completely absurd.  The picture below is a roadmap.

And, in enterprise architecture, we would also refer to the following "thing” as a roadmap.  Each of the bars represents a project that takes place over time.  The picture is intentionally blurred. 

How is the first image is even remotely similar to the second?  They are not. 

So what, you say!  What’s the actual problem here?

The problem is simple: the word “roadmap” already has a meaning.  A map of roads is an illustration of all potential routes in a landscape.  It is most frequently used in a very specific context.  The person viewing a map is frequently interested in driving their individual car.  They are one person, in one car, driving from one origin to one destination.  Regardless of the origin, and the destination, the map doesn’t change.  As far as a map is concerned, there is no traffic.  There is no contextual analysis: only facts.  All of these statements are true of a “map of roads,” but none of them work in the context of Enterprise Architecture.

An Enterprise Architecture roadmap, on the other hands, represent many people, on many projects, all acting in tandem.  They are not going from a single origin to a single destination.  They are moving from many origins to many destinations, in a manner that provides benefit, with careful analysis of interdependencies and constraints.  An EA roadmap is a negotiated settlement that considers the needs of many stakeholders. 

By using the word “roadmap,” and then presenting an EA roadmap like the blurry image above,  and we are asking our stakeholders to unlearn the concept from the first image (a map of roads) and to learn a new meaning.  As if our job wasn’t already difficult enough!  We are asking them to unlearn years of bad business planning, and the first thing we do is given them a word that doesn’t match the thing we are trying to teach! 

If you want to cut down a tree, don’t start with a dull saw. 

Enough already.  Let’s stop using the word roadmap.  Let’s call it an “action plan” or an “orchestration.”  Something that implies that we are getting a group of people to  behave as one in order to benefit them all.  But most importantly, let’s teach a concept that we want our stakeholders to actually use.