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.

Comments

• Anonymous
  May 30, 2010
  The comment has been removed
• Anonymous
  May 31, 2010
  Thank you Caprica.  I appreciate the suggestion.  "Schedule" is an interesting word and one worth considering.  According to Bing Dictionary, the definition of schedule include the following two applicable meanings:

1. list of meetings, commitments, or appointments: an outline description of the things somebody is to do and the times at which they are to be done "Her busy work schedule didn't permit us to meet for lunch."
2. work plan: a plan of work to be done, showing the order in which tasks are to be carried out and the amounts of time allocated to them "The project was completed ahead of schedule." "draw up a production schedule" The problem with "list of meetings" is that it captures the "one point of view" aspect a little too well.  The second definition is more applicable, but it does seem odd to use the term "schedule" when you mean "work plan."  Personally, I think "action plan" is a more useful term because you are trying to get agreement.  People prefer to agree to "action."   One of the many roles I've played was a project manager.  I would not be offended by calling the deliverable in question an "action plan" because project managers understand that you have to create a summary view of the project plan before you present it to executives.  Since the people that Enterprise Architects present to (and work for) are mostly business leaders, they will be quite supportive of a view that is clearly a summary view of a much more detailed plan.  

• Anonymous
  June 01, 2010
  Excellent post Nick. I generally refer to the EA roadmap as a type of "itinerary".

• Anonymous
  June 04, 2010
  Nick, Once again a thought provoking post! Interesting how we "EAs" just take for granted the words we use without thinking that they can be confusing.  I will think about a name for this and let you know my ideas in a bit.  What strikes me is that our "EA Action Plans" are more like when you visit the AAA or CAA and ask them to build a trip map for you.  We did this for a family trip to Europe. Maybe it helps with focusing the actions ... more to come.   Hope you are doing well, Leo

• Anonymous
  June 04, 2010
  I like yr thinking and yr view. But don't u find that architects spend an inordinate amount of time discussing and arguing definitions. Is this really the best value we as EAs can give to business - a definition of terms and some cool wallware ?

• Anonymous
  June 05, 2010
  The comment has been removed

• Anonymous
  June 07, 2010
  Maybe "strategy"?

• Anonymous
  June 08, 2010
  @Craig Martin, you ask "Is this really the best value we as EAs can give to business - a definition of terms and some cool wallware ?" Hmmm.  Kind of a loaded question.  Methinks you are a bit frustrated. There are two things going on here, and they are quite different.  a) conversations between the business and EA, and b) conversations among Enterprise Architects.  This post represents the latter. Perhaps if you are looking for the discussions of how EA should talk to the business, some of my other posts, or the posts from some of my friends in the blog roll, would be helpful.   While we must strive to offer value, and we do, we must also continue to refine the art itself.  EA is not so well described and so consistently performed that we can do without community discussions to refine the practices and processes of EA itself. Thank you for joining in the conversation, and I hope that these simple musings will be useful to you.  Good luck.

• Anonymous
  June 17, 2010
  Hi Nick, I enjoyed this peice but would like to offer a different perspective. I like the roadmap metaphor it can and does explain the start and destination of a 'trip'. Perhaps the reason it doesn't work well if that some architects are not visualizing it correctly. Though the roadmap you presented was blurred, I was struck by the absence of what final destination each project would take the company to? This goes back to business architecture coupled with busness modeling if someone is to provide a roadmap that overlays on the destination a company is trying to reach. I embrace a roadmap in that context and visulization.

• Anonymous
  June 17, 2010
  Hi RHW, In one sense, your response makes perfect sense.  How can I criticize the use of the word "roadmap" as it is applied to a particular diagram, if the diagram I am using looks entirely different from the diagram you are using?  If there is a particular example of a business architecture roadmap that you wish to point out to me, I'm more than willing to listen. That said, the image above of a "map of roads" is clearly an accurate use of the term "roadmap" as it applies to the world outside of EA.  That is the concept that people bring in.  In that concept, there is NO indication of a destination or a trip.  There is simply a visual "list" of roads.   So I'm curious about the visualization that you imply that would match that concept yet still illustrate the things you say you are illustrating.  Perhaps you are comfortable using the term "roadmap" to refer to that type of diagram.  I'm questioning the use of the word, not the diagrammatic style. --- Nick