Effective Enterprise Roadmaps are designed to make change and track ‘effect’

I’ve come to some interesting conclusions regarding Roadmaps that I thought might be interesting to others. About two years ago, I was given responsibility on behalf of the Enterprise Architecture team to provide Roadmaps on behalf of MSFT’s CIO that address 3 CIO concerns to all of Microsoft and they are; IT’s alignment to the business, Gaps and Overlaps in our portfolios, and Key Technology Investments. This responsibility came to our Enterprise Architecture team as a result of a less-than-successful attempt of an ask by our CIO to all groups of our IT organization for their roadmaps. The plan was to simply collect them all together and have an aggregated Roadmap that addresses the 3 CIO concerns. Unfortunately, the roadmaps returned from our IT organization were a collection of documents that no system or human could rationalize together to claim “across MSIT, here is how we are aligned to the business, here is where our gaps and overlaps are, and here are our key technologies to invest in”. When I looked at the roadmaps I learned that each of them were correct to varying levels but only the author could explain how it address the 3 concerns noted above – they didn’t stand on their own nor could they be aggregated to represent all of IT’s view. I discovered that the root cause was based on these problems:

1. Multiple Unmanaged Taxonomies: We had a litany of disparate and unmanaged taxonomies (Strategy, Platform, Program, Project, Business Process, Application)
2. Taxonomy Relationships are undefined and unmanaged (Process to Application, Program to Platform, etc)
3. Data Quality: Different terms with the same meaning as well as different meanings for the same term.
4. Lack of Analytics Ability: Analyzing the data sets is a manual, subjective and intensive activity. At the size of Microsoft, being able to scale quickly becomes an issue.
5. Local Data Not Centralized: Most taxonomies used in the roadmaps were generated from local data stores.
6. Lack of Unified Process: Manual process do not scale at the current level of data complexity and local processes for creating data sets are not coordinated. Depending on the time of the year asked, you may get different results.
7. Lack of Role Clarity: Several individuals claimed accountability for identifying Strategy, Platform, Application, Program et al. Some accountabilities not claimed by anyone.

Six months later I gained support to build a team with tool support to be the official provider of Roadmaps called Enterprise Strategic Planning (ESP) that has the mission statement “Enterprise Strategic Planning is a ‘Service’ provided by the Enterprise Architecture team. We provide a consistent, unified, rational, and collaborative planning capability within MSIT via Service Offerings based on people, process and tools.” The scope of our first release was to provide the foundational processes, role definitions and data to generate roadmaps that illustrate how IT addresses each of the three CIO concerns.

My ESP team built a data model that supports the 3 CIO concerns and we addressed each of the 7 problems above over the course of a about a year. We made major headway to delivering Roadmaps that address the 3 CIO concerns. I can generate roadmaps that show how IT things like IT Projects, Applications, Managed Information, etc associate to business things like Business Strategy, Business Process, Business People/Role, etc over time. I can generate roadmaps that show gaps and overlaps exist in our IT Project portfolio, Process portfolio and Application and Platform portfolios over time. I can show roadmaps that show which Technologies we will migrate to over time too. I wanted to share my learnings regarding roadmaps with you all about a year ago but I didn’t feel I could speak with confidence on them at the time because although I’ve addressed the 7 problems listed above, I discovered more challenges with the roadmaps that made me fear I might propose ideas that produce more bad ideas to the industry. (For those of you that follow my writing and presentations, I maintain an important principle in that I only share my experience and stay away from communicating theory. This is because the Enterprise Architecture discipline is so immature I think too much theory actually causes more damage than good sometimes.)

After producing those roadmaps I learned that they weren’t particularly effective in driving change, which I think is the purpose of Enterprise Architect’s existence…which is to drive change across the enterprise to help accelerate the company to achieve its strategy. This was both disappointing and ironic. The roadmaps communicated current state well but the future state was treated as more speculative rather than course-setting. So change, as it turns out in my experience, wasn’t driven by these roadmaps. This caused me to rethink how to drive change and then how should I position roadmaps to contribute to driving change.

In Microsoft, change happens via programs/projects/initiatives. Therefore, to drive change as an Enterprise Architect, we must influence decisions which projects to fund as well as set the scope of the project. The challenge is to know what influence should an Enterprise Architect provide to project portfolio managers so that they fund the right projects and define the scope to hold the projects accountable for. And on top of that, how to monitor change to track progress. So, to make the roadmaps more effective at driving change, we need roadmaps to have two fundamental principles:

1. Focus the information on roadmaps to be directly pertinent to making project funding decisions. That is, make sure that roadmaps include information that is used to drive project funding decisions. For our planning process here in Microsoft to make project funding decisions, its information like Strategy Alignment, Risk Avoidance, Cost Reduction, etc. Programs that offer the optimum spend to those areas are more likely to be funded. So, our roadmaps need to include which projects make the greatest change in those areas. This helps ease the pain for funding decision makers to make decisions that drive change that impacts IT’s ability to achieve our company strategy.
2. Focus the information on roadmaps to track the effect you wish to see. If we are to use roadmaps to track the progress, then the information on the roadmap must represent the change we are looking for so as change happens we can claim that the Program is on or off the roadmap to trigger a conversation. For example, the type of changes us Enterprise Architects wish to see at the moment are major shifts in IT’s ability to be more aligned to business strategy, security compliance, application and platform portfolio simplification, application and platform quality, data quality and availability, process reuse, information reuse, improved business continuity and disaster recovery, etc.

We will generate several types of roadmaps this year including Program Roadmap, Strategy Roadmaps, Application and Platform Roadmaps. One that is relatively new is the Program Roadmap and is based on the two principals above. That is, the information on the Program Roadmap is mostly the ‘affect’ of the Program rather than traditional stuff like features or functions delivered, or showing program milestone dates. Instead, it includes specifics like which business strategies will be enabled and when, which organizations will be supported and when, which processes will be automated and when, which applications and platforms will be created, modified, or retired and when, which corporate risks and issues will be addressed and when, which business information facets will be created/updated/deleted/used/published and when, etc.

The Program Roadmap is a bold step in a new genre of roadmaps referred to as ‘affected architecture’ (the good people from alfabet.com coined this I think.) What I really like about the concept of ‘affected architecture’ is that it incents the right behavior. It holds projects accountable to make certain changes. Therefore, it’s not about releasing code, delivering features, spending time and money. To track change at the enterprise level, it’s entirely about tracking changes to the enterprise architecture.

Comments

• Anonymous
  February 04, 2011
  The comment has been removed

• Anonymous
  February 08, 2011
  @ Greg, Thanks for your comments. I'm of like-mind that there are near-infinite roadmaps. The roadmap, in my view is our enterprise architecture information repository associated to investments. With this, we can view the model from various perspectives how our investements are currently and will make change to our enterprise architecture (eg Business Strategy, Process, Information, Application, Technolgies, etc). Each of these views are roadmaps in my opinion. So, to your question of making a roadmap relevant to all stakeholders, I suppose it depends on the stakeholder's concerns. That is, depending on the questions your stakeholders have drives what information you include from the repository on the roadmap for them. Sorry for the 'it depends' answer. I know this can be frustrating, however, I do think it is correct.

• Anonymous
  February 09, 2011
  Great post, Gabriel!