Recently, Patrick Gray blogged on TechRepublic that IT has a Chicken and Egg problem.  In his post, he describes two mechanisms that CIOs take to become recognized as strategic leaders: a) work in anonymity to demonstrate that the work that they are doing is aligned, hoping someone will notice, and b) wait for the business to take on the responsibility for ensuring that IT’s efforts are aligned.  He charts out a course that involves a) get the utility aspect perfect, quietly, b) speaking the language of business value, and c) pitch the strategic expertise of IT. 

Reasonable advice in some ways but, as always, the devil is in the details.

1. Getting the utility aspect perfect is NOT a prerequisite.  Having IT to the point where it works reasonably well is sufficient.  Executive peers should not be distracted by bad service, but perfect service is an unattainable goal.  All services have tradeoffs, especially with respect to “time to market” and “cost.”  There is no one else at the executive table that has a perfect operational aspect.  Marketing sometimes runs an ineffective campaign.  Sales sometimes misses their targets.  Operations is not perfectly efficient and effective.  Customer support sometimes angers a customer or two (or ten).  Perfection is not necessary.
    
2. Speaking the language of the business can be tough when “the business” does not speak the language of business.  Read that twice.  The “Language of business” is not just dollars and cents.  It is often influence, power, and politics.  This requires an understanding of not only the language of “value” but also the language of “power.”
      

   How many times has a “business client” of IT asked for a project without any rational reason for believing that the project is actually a good expenditure of money?  How many times has a good, valuable project been cancelled or poorly funded while a pet project moved ahead.  The language of “value” is necessary, but not sufficient, to get business peers to include you in critical conversations.  They have to believe that they need your resources, your input, and your power to deliver.  For the CIO to exercise power, he or she must first have it, and then must demonstrate it.  I’ve seen many who either did not, or could not, do that. 

3. The strategic expertise of IT is interesting, but where exactly is IT exercising that muscle?  Why would IT have any strategic expertise at all, unless it is carefully developed and encouraged.  And what exactly would a strategic capability within IT look like?

Enterprise Architecture is a business function that allows the business to do a very important thing.  EA is based on the simple rule: “Do what you say you will do.”  Many a business executive will declare that they can’t actually get the business to do what they want it to do.  EA is part of the solution to that problem.  It is a necessary business function.  The leader who owns this function has an “ace” to play.  And if that leader is the CIO, then the CIO has a useful capability. 

Patrick Gray is right… you must not “live” with the hand you are dealt.  You must build a better hand.  Enterprise Architecture is one card that the CIO can build into his or her hand, and then play to great effect.

The writing is on the wall.  Adobe has abandoned Mobile Flash in favor of HTML5.  It is just a matter of time before the Adobe Flash developers switch over to producing HTML5 instead of Flash as a matter of course.  With the move to mobile devices, the dominance of Flash on the desktop will simply not matter anymore. 

I’ve been in this profession for 31 years.  I’ve seen a long list of technologies rise up to be one of the “top technologies” in a space, only to be relegated within a few years to the dust heap.  There is always a tipping point.  Apple pushed, and now, Adobe tipped. 

It is time to add Flash to the list.

I’ve been involved in a number of meetings recently as our IT teams try to come to consensus on answering this question: What is a Roadmap?  It’s been a fascinating series of discussions.  One thing that strikes me is that most of the internal discussions, and many of the discussions I’ve seen online, are only seeing part of the business process where a roadmap is used. 

If we don’t see all the process interactions, we can’t get the requirements right.  And if we don’t get the requirements right, the solution (the design of the roadmap) will not be as useful as it could be.

[Terminology Note: I don’t have any great love of the word “roadmap” to refer to the EA artifact.  I like “action plan” as a term, but I have no strong preference.  In keeping with prior posts on the subject, I’ll keep using the word “roadmap” unless and until we can get some consensus on an alternative word.]

Picking the correct approach

There are two different business processes where a roadmap is useful: deciding on the order of efforts, and tracking the efforts against that decided order.  IT folks tend to focus on the second.  I will focus on the first.

When we look at the notion of strategic planning from an EA perspective, we are trying to reduce unnecessary effort.  Just as a downhill skier in the Olympic games will surely lose if they are off course by a few degrees, adding a few extra meters to the length of their run, commercial enterprises are not asking for “any path down the hill” to win the race.  They are asking for “the best possible path down the hill.”  (If your company is run by a salesman, they may shout the words “win the race.” :-)

The business has created their strategy and we have assisted with creating the measurable scorecard to track our progress towards achieving it.  That is step one (most Enterprise Architects have NO idea that this is part of their job).

The first process that uses Roadmaps starts here (colored in brown above).  Enterprise Architecture collect information to produce a series of alternative approaches (“candidate roadmaps” in the diagram above).  The input information includes other roadmaps, as well as business rules, political needs, dependencies, parallel initiatives, resource constraints, technology standards, fiscal constraints, regulatory constraints, and business drivers.  Each approach allows the business to deliver on that strategy in a way that is feasible, fiscal, and forward looking.  We allow ideas that may require us to change big things (merge, split, and repurpose teams, systems, processes, assets, etc.). 

Why have many candidates?  Because there is nearly always more than one path.  Each path will have tradeoffs.  One may be quicker to see results, another less expensive, and another less disruptive to existing product plans.  We need the business to pick the path that they want to follow.  Moreover, we want them to debate the tradeoffs in front of their peers, and come to a resolution about which path they will collectively select.  Because the only thing worse than having no roadmaps is having many competing roadmaps.  It is tempting to come to the business with only one roadmap. “Here’s your solution, sir.” On occasion, that works. Depends on the organizational politics. Personally, I think that is not a good recipe for buy-in. Your mileage may vary.

At the end of this two-step process, we walk out of the room with something powerful: buy-in.  We come away with a clear decision: beyond “get this done,” we now have “go do these projects, in this order, to get it done.” 

The candidate roadmaps fuel the debate.  It is the tinder to which we strike a match.  Each one explains all of the information that a stakeholder needs to debate the pros and cons, and the collection of information is sufficient to allow business leaders to pick one with their eyes open to the tradeoffs. 

Delivering on the approach selected

In the second part of the process (in purple above), we bring up the roadmap on a regular basis as we review, with our business stakeholders, the status of our projects and whether there are dependencies that may be driving our decisions.  In other words, if two projects are on time and a third project is late, but the fourth project cannot kick off....  You get the picture.

This is a kind of decision-rich governance activity.  The “roadmap” in this context is used for expectation management.  While this is a very valuable activity, you do NOT need all the same data for this activity as you do for the previous one.   Whether you need one diagram or two will depend on your business and how it handles project governance.

Conclusion

I went to such trouble to explain the distinction between these two parts of the process because the first part (using a roadmap as a high-level decision making tool) is often misunderstood by EA stakeholders who only view EA from an IT context.  As such, much of the debate on “what belongs in a roadmap” is centered around delivery needs and not enough on the decision needs described above. 

To build a better roadmap, it helps to know where it will be used.