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

By |2010-05-31T03:08:05+00:00May 31st, 2010|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.

Update to Blogging Site

By |2010-05-25T10:14:04+00:00May 25th, 2010|Enterprise Architecture|

Hi Folks,

If you have wandered the wilds of the MSDN or Technet blogs in the past few days, you will have noticed that the blogging system has been given a facelift.  It takes a little getting used to, but it isn’t bad, all in all.  If there are articles or entries that are not rendering correctly, please let me know and I’ll work to get the problem fixed.  Thanks for your patience.

Doing Business without EA is like building a chain of “open” links

By |2010-05-11T00:00:31+00:00May 11th, 2010|Enterprise Architecture|

"There are a thousand hacking at the branches of evil to one who is striking at the root." – Thoreau

I had the occasion today to have a long chat with a senior architect about Enterprise Architecture.  The conversation turned to the “underlying problem” that EA is supposed to solve.  In other words, if we use terms like “alignment” or “simplification,” what is the problem that causes misalignment and complexity? 

To paraphrase Thoreau, I asked “what is the root of the evil we are striking at?”

The answer was simple, and glaringly obvious.  Communication. 

To whit:

  • When a leader communicates, no one under that leader wants to admit that they cannot (or did not) completely understand every word. 
  • When a project is planned, few people want to admit that the project is (or will be) incapable of producing the desired effect.  This is especially true if their leader is the one who thought the project up.

As long as communication is flowing in one direction, from a leader to his direct report, then it is easy for the next person down the line to “drift” a little, performing work that may or may not produce the result that the leader expected.  Such a system needs to be controlled in order to prevent that drift.

It would be like manufacturing a product on an assembly line without ever checking, along the way, that the intermediate parts are meeting quality control checks.  When a part consistently fails a quality control check, you would go back up the line to find the systemic causes of the defect, fix the root cause, verify the result, and continue with manufacturing.  This “quality feedback loop” is essential to producing a good product on a consistent basis by building quality into a product rather than trying to insert quality through massive inspection regimens.

The assembly line that EA addresses is the line that starts at strategy and ends at execution.

There is no question that being able to execute on good strategies is a required competency of a successful company.  Execution is everything.  And what is the mechanism that controls the quality of that execution, reducing defects and building quality into it along the way?  Enterprise Architecture.

I’m going to jump to another metaphor here… this one is more visual.  This is the metaphor that was going through my head during the conversation. 

The chain metaphor



A company can operate entirely without enterprise architecture, just as you can build a chain composed entirely of “open” (or incomplete) links (left). 

Such a chain will hold some weight, and it may lighter than a full chain.  Potentially such a chain may be inexpensive to create.  Sounds compelling, doesn’t it?

But look at the real world.  How many “open link” chains have you actually seen?  Why is that?

A chain of open links cannot absorb changes easily.  It is weak and frail.  A sudden change in the weight bearing load, or a strong push in one direction or another, and the chain fails. 

For this reason, chains have closed links (right).  Stronger, responsive to change, easier to handle.



Let’s apply this metaphor to the way a business operates.  The chain in question is the chain of planning activities that starts with the formulation of strategies and culminates in a series of key changes in the way a business operates.  The desired outcome of these changes, all summed up, is the realization of that business strategy. 




Enterprise Architecture is in the unique position of addressing these “open” links by creating a quality feedback loop at every step of the way.  Using Enterprise Architecture, Business Architecture, and Solution Architecture, the chain becomes stronger, more flexible, and less expensive to own.




This role of Enterprise Architecture is interesting, and completely distinct from that of other roles in the company.  Just as a developer who tests his own code is prone to bugs, and a lawyer who represents himself has a fool for a client, a business executive who both articulates strategy and tries to rationalize the subsequent goa
ls is betting against himself.

Enterprise architecture does not create the strategy.  But it is essential for helping to insure that execution follows effectively from it.

One day Alice came to a fork in the road and saw a Cheshire cat in a tree. Which road do I take? she asked. Where do you want to go? was his response. I don’t know, Alice answered. Then, said the cat, it doesn’t matter.—Lewis Carroll