In the previous post, the process of roadmapping was introduced. In this post, I would like to present a custom method that can help you in your roadmapping process. The method refers to the TOGAF ADM and ArchiMate specification, but there is no strict dependence.
The TOGAF 9.1 ADM in support of roadmapping?
Like Enterprise Architecture, roadmapping should be considered as an iterative, incremental process. Since roadmapping is part of the EA effort, the TOGAF 9.1 ADM can be used as a guidance for the roadmapping process. We describe briefly the TOGAF 9.1. ADM phases as explained in the TOGAF 9.1. specification.
- The Preliminary Phase is about defining “where, what, why, who, and how we do architecture” in the enterprise concerned.
- Phase A – Architecture Vision aims to develop a high-level aspirational vision of the capabilities and business value to be delivered as a result of the proposed enterprise architecture. An approval for a Statement of Architecture Work need to be obtained that defines a program of works to develop and deploy the architecture outlined in the Architecture Vision.
- Phase B – Business Architecture aims to develop the Target Business Architecture that describes how the enterprise needs to operate to achieve the business goals, and respond to the strategic drivers set out in the Architecture Vision, in a way that addresses the Request for Architecture Work and stakeholder concerns. Candidate Architecture Roadmap components need to be identified based upon gaps between the Baseline and Target Business Architectures.
- Phase C – Information Systems Architectures aims to develop the Target Information Systems (Data and Application) Architecture, describing how the enterprise’s Information Systems Architecture will enable the Business Architecture and the Architecture Vision, in a way that addresses the Request for Architecture Work and stakeholder concerns
Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Information Systems (Data and Application) Architectures - Phase D – Technology Architecture aims to develop the Target Technology Architecture that enables the logical and physical application and data components and the Architecture Vision, addressing the Request for Architecture Work and stakeholder concerns. Candidate Architecture Roadmap components need to be identified based upon gaps between the Baseline and Target Technology Architectures.
- Phase E – Opportunities & Solutions aims to generate the initial complete version of the Architecture Roadmap, based upon the gap analysis and candidate Architecture Roadmap components from Phases B, C, and D. If an incremental approach is required Transition Architectures need to be defined that will deliver continuous business value.
- Phase F – Migration Planning aims to finalize the Architecture Roadmap and the supporting Implementation and Migration Plan. The Implementation and Migration Plan must be coordinated with the enterprise’s approach to managing and implementing change in the enterprise’s overall change portfolio. The business value and cost of work packages and Transition Architectures must be understood by key stakeholders.
- Phase G – Implementation Governance aims to ensure conformance with the Target Architecture by implementation projects. Architecture Governance functions appropriate for the solution and any implementation-driven architecture Change Requests need to be performed.
- Phase H – Architecture Change Management aims to ensure that the architecture lifecycle is maintained, that the Architecture Governance Framework is executed and that the enterprise Architecture Capability meets current requirements.
- Requirements Management aims to ensure that the Requirements Management process is sustained and operates for all relevant ADM phases. Architecture requirements identified during any execution of the ADM cycle or a phase need to be managed. aims to ensure that the Requirements Management process is sustained and operates for all relevant ADM phases. Architecture requirements identified during any execution of the ADM cycle or a phase need to be managed.
The TOGAF 9.1 ADM phases can be clustered in 4 areas:
- The Preliminary Phase and Phase A – Architecture Vision focus on the definition of the Architecture Context.
- Phase B – Business Architecture, Phase C – Information Systems Architectures and Phase D – Technology Architecture focus on the Architecture Definition
- Phase E – Opportunities & Solutions and Phase F – Migration Planning focus on Transition Planning.
- Phase G – Implementation Governance and Phase H – Architecture Change Management focus on Architecture Governance.
- Requirements Management is relevant for all areas.
The development of a consolidated and integrated roadmap is part of Transition Planning. The description of the current state (baseline architecture) and the desired future state (target architecture) based on goals and drivers is essential input for the definition of the roadmap. Once the roadmap is developed, an implementation and migration plan is developed that describes the necessary steps to realizes the desired future state. As a consequence, a program/projects are defined to execute the roadmap and all necessary governance structures are put in place.
Process
Step 1: Gathering requirements and draft architecture vision for the roadmap
The Preliminary Phase and Phase A – Architecture Vision of the TOGAF 9.1 ADM can be mapped on step 1.
Step 2: Assessing the current state
Phase B – Business Architecture, Phase C – Information Systems Architectures and Phase D – Technology Architecture of the TOGAF 9.1 ADM can be mapped on step 2.
Step 3: Designing the future state and performing gap analysis
Phase B – Business Architecture, Phase C – Information Systems Architectures and Phase D – Technology Architecture of the TOGAF 9.1 ADM can be mapped on step 3.
Step 4: Producing the roadmap and preparing for migration
Phase E – Opportunities & Solutions and Phase F – Migration Planning of the TOGAF 9.1 ADM can be mapped on step 4.
Each roadmap type needs an appropriate and specific approach. However, the high-level process is the same and should contain 4 steps that need to be executed . Each TOGAF 9.1 ADM phase can be mapped one or more steps.
Step 1: Gathering requirements and draft architecture vision for the roadmap
The first step aims to gather requirements and to draft architecture vision for the roadmap. This step encompasses the Preliminary Phase and Phase A – Architecture Vision of the TOGAF 9.1 ADM.
Required inputs
- Corporate mission, vision, strategy, critical success factors, strategy map, key performance indicators (KPIs)
- Business plans, business strategy and/or IT strategy, business and/or IT principles, business goals, and business drivers
- Major frameworks operating in the business e.g., portfolio/project management
- Governance and legal frameworks, including architecture governance strategy
Actions
- Identification and analysis of all stakeholders (decision makers, key influencers of business and IT) that need to be involved in the roadmapping process or that are impacted by the change (stakeholder analysis). This helps to ensure that stakeholders are involved meaningfully and effectively in developing or approving the roadmaps. Define an information plan to address their need for information.
- Identification of constraints (budget, timing, legal, …)
- Definition of the scope of the roadmap
- Definition of the approach for roadmapping
The ArchiMate Motivation Extension can be used to model the part of the above.
Stakeholders
- Business and/or IT key stakeholders (cfr. stakeholder analysis)
- Business and/or IT sponsor
- (Lead) Enterprise Architect, Chief Architect, Domain Architect, Business Architect, IT Architect
- Business Analist
Expected output
- Statement of Work for Roadmapping
- Project Proposal for the execution of step 2, step 3 and step 4 covering the following aspects:
- Context
- Goals and drivers
- Scope
- Assumptions
- Principles
- Project approach
- Project organization
- Planning
- Cost
- Risks
Step 2: Assessing the current state
The second step aims to assess the current state and encompasses Phase B – Business Architecture, Phase C – Information Systems Architectures and Phase D – Technology Architecture of the TOGAF 9.1 ADM.
Required inputs
- Statement of Work for Roadmapping
Actions
- Definition of real quantifiable objectives
- Definition of functional needs
- Definition of high impact business processes or cycles
- Definition of the organization context (current operating model)
- Definition of current capabilities
- Definition of cost and complexity drivers
- Definition of the baseline Architecture
- Definition of the baseline Business Architecture
- Definition of the baseline Information Systems Architecture (Application and Data Architecture)
- Definition of the baseline Technology Architecture
Stakeholders
- (Lead) Enterprise Architect, Chief Architect, Domain Architect, Business Architect, IT Architect (Application Architect, Information/Data Architect, Technology/Infrastructure Architect)
- Business Analist, Proces Analist
Expected output
- Current State Definition Document
Step 3: Designing the future state and performing gap analysis
The third step aims to design the future state and to perform a gap analysis between the current state and the desired future state. This step encompasses Phase B – Business Architecture, Phase C – Information Systems Architectures and Phase D – Technology Architecture of the TOGAF 9.1 ADM.
The ArchiMate Implementation and Migration Extension can be used to model the plateau for the future state and to model the gaps between the plateau that describes the current state and the plateau for the future state.
Required inputs
- Statement of Work for Roadmapping
- Current State Definition Document
Actions
- Definition of the target architecture
- Definition of the target Business Architecture
- Definition of the target Information Systems Architecture (Application and Data Architecture) that will enable the target Business Architecture
- Definition of the target Technology Architecture
The future state can be described by different models and viewpoints that must be consistent among each other. All models must support pre-defined principles, requirements, objectives and constraints.
Recommendations:
-
- Elaborate the future state iteratively
- Involve important stakeholders early in the process
- Balance between several options and possibilities, perform trade-off analysis to resolve conflicts
- Develop viewpoints that are relevant and comprehensible for specific stakeholders. Avoid ambiguity and unnecessary complexity.
- Formal validation of the desired future state
- Perform a gap analysis between the current state and the future state
- Identification of candidate roadmap activities based upon gaps between the current state and the future state
Stakeholders
- Enterprise Architect
- Business Architect
- IT Architect (Application Architect, Information/Data Architect, Technology/Infrastructure Architect, etc…)
- Domain Experts
- Subject Matter Experts
Expected output
- Formally validated Future State Definition Document
- Gap Analysis Document
- List of candidate roadmap activities
Step 4: Producing the roadmap and preparing for migration
The fourth step aims to produce the roadmap and to prepare for migration. This step encompasses Phase E – Opportunities & Solutions and Phase F – Migration Planning of the TOGAF 9.1 ADM.
The roadmap is incrementally developed throughout Phases E and F, and informed by roadmap components from Phase B, C, and D within the ADM. The roadmap lists individual work packages that will realize the Target Architecture and lays them out on a timeline to show progression from the Baseline Architecture to the Target Architecture. Transition Architectures necessary to effectively realize the Target Architecture are identified as intermediate steps.The roadmap highlights the business value of individual work packages that can be grouped into managed portfolios and programs at each stage.
The ArchiMate Implementation and Migration Extension can be used to model the work packages that individually contribute to the realization of the roadmap.
Required inputs
- Statement of Work for Roadmapping
- Current State Definition Document
- Future State Definition Document
- Gap Analysis Document
- List of candidate roadmap activities
Actions
- Prioritization of activities
Several approaches and techniques are available to support the prioritization of activities:
-
- Paired Comparison Analysis
- Action Priority Matrix
- Urgent/Important Matrix (Eisenhower Decision Matrix)
- Pareto Analysis (80/20 rule)
- Impact Analysis
- …
One or more techniques can be used, depending on the organizational context and the type of roadmap to be elaborated to prioritize the findings from the gap analysis into a coherent, thoughtful set of ordered actions. The combination of techniques can contribute to get consensus on priority decisions.
A general rule of thumb is to focus on activities that contribute to the realization of goals and that create the most added value.
- Definition the optimal sequence of activities
Once there is consensus on the priority of activities, we can define the optimum sequence of activities.
- Development and publication of the roadmap
The elaboration of the roadmap is the
Stakeholders
- Enterprise Architect
- Business and/or IT key stakeholders
- Program/Project Manager (proactive involvement)
Expected output
- Transition Architecture Definition Document
- The roadmap that will realize the future state
- List of sequenced work packages mapped on a timeline
- Description of the added business value for each work package
- Visual representation(s) of the roadmap
- Implementation and Migration Plan
- High-level Project/Program definition consisting of (a) grouping(s) of individual work packages.
Recommendations
- Perform stakeholder analysis for all stakeholders impacted by roadmaps — business and IT.
- Develop roadmaps that focus on decision-making needs and styles to help stakeholders visualize future business outcomes so they can make well-informed investment decisions.
- Socialize roadmaps earlier rather than later to ensure they meet stakeholder expectations for being usable, useful and at the right level of detail. Involve stakeholders in creating a common vision for realizing business outcomes. The development of a roadmap is an opportunity for collaboration and consensus building.
- Time box and sequence iterations with the stakeholders to optimize the balance between socialization and efficiency.
- Deliver roadmaps that focus on new business or IT capabilities, and demonstrate when outcomes can be realized.
- Focus on creating business value.