All the Clams We Can Eat!

"Pismo Beach, and all the clams we can eat!” declare Bugs Bunny and Daffy Duck in the 1954 classic, Ali Baba Bunny.  They emerge from their tunnel, shovel and pail in hand, only to realize they are in the middle of the Arabian Desert. Scanning his map, Bugs goes on to blame their misfortune on missing the left turn at "Alba-koi-kee”. 

Many organizations undertook Portfolio Rationalization, hoping to get to Pismo, only to end up somewhere else. They were missing an Enterprise Roadmap, which would have marked the turn left at Albuquerque. Portfolio management was a huge advancement for organizations seeking a means to handle their burgeoning inventory of departmental applications, however it ultimately fails because it is not driven by a cohesive business strategy and does not enable tough, enterprise trade-offs regarding limited resources. 

In my November 2009 post, Real Architects Don't Wear Ties, I offer a definition of Enterprise Architecture, 

"Enterprise Architecture - a body of information that reconciles competing organizational forces and perspectives into a cohesive, enterprise blueprint and roadmap. The Enterprise Architecture supports making the tough decisions necessary to get from where the organization is now (current state) to where it wants to be (future state) in an efficient manner. At the end of the day it's about investing limited resources in the right people, process, financial and technology changes to move to a desired state."

A key feature of that definition is the identification of an Enterprise Roadmap as the critical EA deliverable and a crucial organizational governance tool. The remainder of this post describes key characteristics of an Enterprise Roadmap and some hurdles you may encounter developing one.

Key characteristics of a successful Enterprise Roadmap:

• It is written in business language - the roadmap is a tool to help executive's make trade off decisions regarding limited resources. The language and graphics in the roadmap must resonate with those executives. How much "technospeak" it can contain is a function of the business you are in and the executive's IT knowledge.
• It is sponsored, and potentially co-written, by senior business leaders - this goes hand-in-hand with the first bullet. The best way to get the roadmap written in business language is to partner with the business in writing it. It is crucial to have a few key executives and the CIO bought in to the roadmap to assist in selling it to the rest of the business.
• It illustrates the future state of the business in a compelling manner - successful roadmaps are broadly accepted by the business, adding a sales component to the development process. Its is not enough to have a technically sound deliverable. The future state description must be compelling. Consider "Case Studies" targeted at specific executives to tell a story about how the Enterprise Roadmap impacts them and drives outcomes they desire.
• It describes the organization in terms of a functional capability model  - an Enterprise Roadmap is not simply an aggregation of portfolio roadmaps, even though that is not a bad place to start. The roadmap over comes organizational and IT politics exactly because it addresses stakeholder concerns in a neutral way according to organizational capabilities. Gartner calls this a Business Anchor Model, while IBM provides a Component Business Model. You can see an example of one on slide 13 of this presentation.  Use such a model to organize sections of the roadmap and provide a basis for aggregating financials.
• It calls out gaps and identifies capabilities needed to fill them - the business is most interested in the capabilities IT will deliver, not the applications or technology. Put another way, unless the business is extremely IT savvy, talking in terms of future application or software platform names will mean very little. Instead, do an analysis of business goals against current-state capabilities, identify gaps, and define future-state capabilities as key objectives of the roadmap; then link investments to delivering these.
• Dependencies are identified - be sure to identify critical dependencies between  investments. Since resources are always limited, part of the roadmaping process will be constraining the desired "all in" investment total to something that is achievable. This inevitably means trade-off decisions. The roadmap should allow executives to know what investments must be funded and in what order to achieve desired capabilities.
• It provides an aggregate financial view the future - one of the ways you know a roadmapping effort is sucessful is the question, "so how much will all this cost". The roadmap should come loaded with the answer in terms of financial models (charts and graphs). These models should illustrate total required investment and the impacts of capitalization on annual expense. It should also provide a projection of future impacts to the company bottom line (the benefits). 
• Progress against it can be measured - another question that indicates you are on the right track is, "So how will we know if we are achieving the roadmap?". A successful roadmap uses the capability milestones and financial metrics as markers to measure progress. A series of "interim states" can be identified in the roadmap that call out capabilities delivered and the impacts of those capabilities on business Key Performance Indicators (KPIs). This will go along way to making the roadmap compelling.
• It addresses organizational readiness - a final question the roadmap must answer is, "Are we ready to do this?". Since an IT objective of the roadmap is to build confidence and credibility in the technology organization's ability to deliver, having a frank analysis of readiness will build credibility. Also, in developing the technology component of the roadmap, take care to avoid early solutions that the business is not ready for. As an example, an ERP or CRM technology might be indicated by business requirements, but if the business is not ready for the level of process change required to be successful in these types of implementations, recommending them early in the roadmap is not advisable. In this example, the roadmap can call out business process change management as a key dependency that must precede an ERP implementation.
• It supports drill down to the detail - inevitably some executive will latch on to something in a roadmap and "go down the rabbit hole". The underlying detail to support the high-level direction of the roadmap must be available. Without supporting detail, a roadmap's credibility is in jeopardy. I cover some useful techniques for clearing political hurdles and overcoming objections next.
• It illustrates the impacts on technology cost - a common requirement of most large organizations is to manage the cost of technology and almost always reduce it. Two main contributors to technology cost are application environment complexity and shared infrastructure cost. An Enterprise Roadmap should show how the proposed investments impact these over time.

On the journey, you may encounter a few obstacles; overcoming these is crucial to success. Here are a few   -

• Resources and organizational focus - developing a roadmap requires significant organizational focus and substantial time from senior executives. It also requires Enterprise Architects with the knowledge and skill to work closely and directly with business partners to get beyond technospeak and down to the brass tacks of what is needed. Because of this, expectations regarding the amount of time and collaboration required to create the roadmap must be set with the "C" level. If the "C" executives are not committed to the roadmap, the next tier of executives will not be available to the extent needed. Expect 6-9 months of continuous effort for a Fortune 500 sized organization's initial enterprise roadmapping endeavor.
• Over coming line-of-business politics - the level to which executives are willing to trade-off benefits to their lines of business for enterprise ones will affect the severity of this obstacle. The difficulty manifests when influential leaders are less than enthusiastic about the roadmap because a trade-off decision works against their agenda and performance metrics. Organizational incentives are a contributing factor. When a manager's performance is tied to KPIs specific to their line of business and not the enterprise, this obstacle is more likely. This is where "C" level sponsorship is crucial - managers are less likely to oppose or drag their feet for an initiative that is strongly supported by the CEO. 
• Over coming IT Cost Allocation issues - since a roadmap should describe the proposed investment's impact on Total Cost of Ownership, the issue of IT cost allocation may cause problems. In my post, Calling Out Pesky Pachyderms, I name this issue as the big white elephant that many organizations do not want to deal with. In order to illustrate the technology cost impacts of the roadmap, you have to agree to what technology actually costs and assign accountability for that cost among portfolios that need to manage it. As an example, the roadmap model must have a way to indicate that the cost of a legacy accounting application is $XM, and that retiring that application will result in some % of the $XM in savings. Ensure that part of your organization's commitment to having a roadmap includes the development of a cost allocation model that will be accepted by business and technology executives.
• Constraining the Roadmap - since most enterprise roadmaps start off as a aggregation of all business unit desires for IT investment, the total price tag is likely to be much more than your organization is willing to spend. The really hard work of a roadmap, once the "all in" financials are known, is answering the question, "what of all this really drives us to where we need to be?" Inevitably, trade-offs will be needed and projects will end up on the editing room floor. Trying to over come this obstacle in the midst of creating the roadmap can be extremely difficult because there may be the unspoken expectation among executives that this roadmapping effort will finally make some things happen in their business unit that are high on their agenda. The key to solving this is a strong, centralized IT investment governance body that includes representatives from all business areas. Make it clear that this body is the roadmap approving authority and responsible for setting priorities and making constraining decisions. Ensure this body reports directly to the CEO (not the CIO), and ensure the CEO is the final arbiter. 

In closing, you may have noticed that I say little about the format of the roadmap or provide references to templates other than the anchor model. There are an abundance of roadmap examples out there; the Enterprise Architecture Executive Council has a nice package as does Gartner and Forrester.  I deliberately stay away from this because I believe that the exact format of a roadmap is something each organization has to find for itself. Because the roadmap must communicate to business and IT executives in a way that they understand, it is very difficult to get it right when starting with somebody else's template. My suggestion for those of you starting the journey is to research examples, but start with a series of questions the roadmap should answer. Work with leadership to ensure you are answering the right questions, then create a blank presentation with slides for each question or group of questions. You can then have conversations with decisions makers about the information contents of each slide that would best answer the target questions. Last, design some models, charts or tables of data as appropriate to supplement bullet text and narrative for each slide. Then iterate.

Before you know it, you'll be in Pismo eating Clams!