How to Build a Solid Roadmap

A Roadmap provides the direction to the future.

A "roadmap" is simply a plan for moving or transitioning, from one state to another. There are different types of roadmaps, an Enterprise Architecture roadmap, application roadmap, business architecture roadmap, etc. 

A roadmap shows the time sequence of a strategy, then by default the strategy is the main supporting artifact that provides direction. To build a roadmap, one would also need the following artifacts: As-Is architecture, To-Be Architecture and possibly a Reference Architecture as input. 

1 What kind of Roadmap do you build?

The roadmap is contextual: A roadmap from where to where? From no EA to a mature EA practice? Or from a legacy architecture to modern architecture? and, on and on. There are different types of Road Map. Depending on nature of requirement of the stakeholder, the road map will take on the different characteristics. For example, if the roadmap is heavily focused on the technical aspects of the investment, it may dictate and determine the type of artifacts that you need to garner. Thus, business processes and capability assessments are two examples of artifacts that have lesser importance in that scenario. Elements such as Technical Reference Models and Licensing philosophies become prevalent for a Technical Road Map. If the road map is an overall business justification for funding, then the map will be more inclusive with roads and detours describing the full enterprise taking into consideration the technical nuances as well as all the business artifacts that make up the road map. But if the roadmap focuses on a specific "road" within the map, technical infrastructure or software development, then the map is more tactical and in turn determines the importance of what artifacts are necessary to define the road...

An Enterprise Transformation Roadmap: EA team needs to provide a plan aligned with Business Strategy. An Enterprise Transformation plan should cover the business value aspect in terms of capabilities delivered at Strategic, Segment, and Operational Level. The following can be artifacts to get the desired state of an Enterprise aligned with Business Goals and Objectives 

-Business Drivers, Goals, Objectives and Milestones agreed with Stakeholders
-Current Architecture Capability and Governance Framework
-Enterprise Transformation Plan
-Business Case for Architecture Work (Business KPI’s and Metrics)
-Stakeholder Map with Vision for Strategic, Segment and Operational Level
-Architecture Communication Plan and Business Capability Map and the associated -Transformation plan
-Enterprise Capability Architecture (“AS IS “and “TO BE”) Outline with initial Gap Analysis and Risk Assessment  

2. How to Define Roadmap

The roadmap is the outcome to mind gaps between TO-BE and AS-IS, You can define any type of roadmap within the context of an Enterprise Architecture by "doing" the exercise of developing a "To-Be" state first, then defining the strategic roadmap based upon the fallout of what has been discovered from that exercise. What you need in order to define your starting point, your end-state, and how to get there is completely dependent on the journey you want to take. 

The TO-BE should have to be defined first of all by collaboration with Business Architects: System Matter Expert with the following outcomes and two dimensions (TO-BE vs. AS-IS via color shape), You have first to gather the Business strategy and environmental trends and IT as well to identify Architecture Principles with agreement on level of details.
- Business capabilities, business models, process description on critical ones
Then a business reference model will be shared with all stakeholders as the glue with IT.
EA will provide application landscape, flow description, functions that will map the business reference models.

When you place the "To-Be" state first, it creates a paradigm shift in your approach. Capabilities, Issues, Risk, etc. will be quickly discovered. A roadmap should then typically contain or be informed by capabilities needed to get there, interdependencies, risks, approach, milestones

3. The Roadmap Sets Milestones and Timelines 

The transition plan, or roadmap, is the set of investments, programs, projects and milestones that take you from the current architecture to the target architecture. The end result is a dynamic tree-like structure of roadmaps with interlocking deliverables and schedules. It is a Gantt chart or schedule. It is interference with the process where EA places strategic goals to domains and they "reply" with estimated capabilities and timelines.

The stepwise process from here to there should include a rough timeline and should provide the business benefit each interim state provides. 

(1) what do we have? (processes, artifacts, staffing,..... )
(2) what can we achieve in the time frame (3-5) years??
(3) what element do we add in which fiscal years, what benefit does it provide us and why were these selected over others

You should manage a two dimensions space:
Supporting architectures: enterprise, information systems, and platforms.
Processes: business, systems engineering, support processes (services operations).
On that basis, you define objectives in terms of:
Business objectives > Business Processes >
>> Functional architecture > Engineering processes
>> Technical architecture > Support processes 

Assuming you have done the current state assessment (Business/IT) pain points, alignments on different dimensions, etc, against reference architecture /EA. Also completed the gap analysis against To-Be and armed with prioritized/desired capabilities, you are good to define a roadmap for strategic (long term) /tactical (quick wins) timeline. The artifact becomes one that covers the following:
(1) what the application portfolio looks like today
(2) what it needs to look like to achieve the business goals
(3) the series of initiatives/changes/steps that bring the portfolio from here to there. 

Posted in: EA,Enterprise Capability,IT Strategy/Roadmap