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

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.

image

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. 

BlurredRoadmap

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.

By |2010-05-31T03:08:05+00:00May 31st, 2010|Enterprise Architecture|10 Comments

About the Author:

President of Vanguard EA, an Enterprise Architecture consulting firm in Seattle focused on the Pacific coast of the US. Nick has over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

10 Comments

  1. Caprica May 31, 2010 at 4:40 am - Reply

    In order not to offend project managers and conductors, it is important to note that the fuzzy blue box is neither a plan (that would require more than a fuzzy time line) nor is it an orchestration (that would imply music).  

    The fuzzy blue box diagram is in fact a "schedule" (i.e. an ordered list of times at which things are planned to occur).

  2. NickMalik May 31, 2010 at 12:34 pm - Reply

    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.  

  3. Jörgen Dahlberg June 2, 2010 at 3:04 am - Reply

    Excellent post Nick. I generally refer to the EA roadmap as a type of "itinerary".

  4. Leo de Sousa June 4, 2010 at 9:19 am - Reply

    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

  5. Craig Martin June 4, 2010 at 4:01 pm - Reply

    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 ?

  6. Peter June 6, 2010 at 4:35 am - Reply

    When I was a child our family used to go on a number of road trips. We would use an item called a "Strip Map". It was commonly available from automotive stores and would show the route between two major centres as a set of thin maps. Each would show a stage of the journey with the major path up the centre and all the turn-offs marked clearly (with things like distance to the town). The scale and directions were obviously totally off but the concept worked well. There are some very clear restrictions in how the maps could be used and they were only practical when there are a limited number of possible routes (although you could move from one map book to another if you needed to). This is probably why they are no longer available.

    The point of the story is that THIS is the sort of map I always think of when I hear about architectural 'roadmaps'. You are going from here to there and only the main path + possible off-shoots needs to be shown – until you deviate from the path.

    Of course the implications is that there is a clear destination and a clear path to get there. Neither of which apply in enterprise architecture.

  7. Craig Brown June 7, 2010 at 5:41 pm - Reply

    Maybe "strategy"?

  8. NickMalik June 8, 2010 at 9:55 pm - Reply

    @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.

  9. RHW June 17, 2010 at 2:48 pm - Reply

    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.

  10. NickMalik June 18, 2010 at 1:08 am - Reply

    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

Leave A Comment

18 − 12 =