Contents of Enterprise Architecture Roadmap as Design
What is an Architecture Roadmap
- Developing a Roadmap is the Most Valuable Step
- Architecture Roadmap vs Implementation Plan
- TOGAF Architecture Roadmaps
When to Use an Architecture Roadmap
How to use an Architecture Roadmap
- Architecture Roadmap at Budgeting
- Architecture Roadmap at Project Initiation
- Architecture Roadmap during Project Execution
- Reacting to Change with the Architecture Roadmap
- Stakeholder Choices using the Architecture Roadmap
What is an Architecture Roadmap?
An architecture roadmap is a change planning and implementation governance tool. Architecture roadmaps are tightly aligned with architecture to support portfolio.
An enterprise architecture roadmap outlines the work package needed to achieve the target architecture. It uses a series of transition stages, where value is delivered to provide enterprise agility. At the transition stage, the roadmap helps you understand whether to continue, pause, or change direction.
An enterprise architecture consulting clients said the perfect architecture roadmap
… included options and value statements associated with each work package ...
... had value stated in terms of business capability, market reach and limitations ...
.... provided awareness of existing roadblocks. Including why they are roadblocks and implications of addressing them head-on or continuing to detouring ...
Let’s unpack these points about the perfect architecture roadmap.
First, the architecture roadmap provides an outline for change. It links the work packages to outcomes. The outcomes are a set of transition states leading to the target. The changes from where your organization is today to what the stakeholders want it to be.
Second, we position the work in terms of available options and value realization. There are many paths forward. Some routes deliver more value, are easier, are quicker, are cheaper, are less uncertain, or are better for enterprise agility. The architecture roadmap helps the stakeholders select the changes that are best.
Value is defined by:
-
- roadmap vision, goals, and objectives
- portfolio directions - performance expectations, constraints and risk appetite,
- key stakeholder concerns
Third, you need off-ramps and transitions. Never forget, you are with a successful organization. We do not need to tackle every deficiency. Change is a choice.
A dynamic architecture roadmap does reflect changes in the enterprise architecture, rather changes in the journey. This dynamism is inherent in the TOGAF architecture development method - Phase E stresses transition and value generation.
Developing a Roadmap May Be The Most Valuable Step
Let's start with three facts:
- Many enterprise changes fail to deliver the expected value
- Most bottom-up locally optimized changes move cost and risk rather than improve your organization
- Every organization has more improvement ideas than it can act upon
Now let's look at how most change initiatives are planned. Bottom-up, or top-down.
Bottom-up - Stakeholders are surrounded by bottom-up change champions. These champions constantly pitch a locally optimized solution. Solution rarely has any impact on reaching a portfolio's goals or transition state.
Top-down - Planning methods expect the stakeholder to develop a top-down plan that pre-determines every change. There is a high demand for omniscience.
Developing a roadmap allows the stakeholder to transition from selecting between different sales pitches to understanding contribution to value. Every roadmap provides the journey to a destination. That desitination realizes vision, goals, or objectives. Actition on the journey contributes to the target state.
Developing a roadmap helps stakeholders assess all change options in terms of value creation. It also helps them find value resting points. Points where they can stop one part of the journey and pivot to another.
Developing an architecture roadmap helps stakeholders find the most effective changes. They will find:
- different balances between objectives, benefits, work, and risk
- priority and dependency between work packages
- value of different transition stages
- a sense of what value they can deliver
- benefits they will delivery
- work and resources they need to commit
- risk
They are positioned to see which bottom-up initiatives fit into their portfolio and which top-down activity they need to initiate.
TOGAF Architecture Roadmaps
TOGAF describes candidate roadmap components as emerging from the gap analysis. The implied sequence is:
- develop the baseline architecture
- develop the target architecture
- identify gaps from the difference between the baseline and target architectures
- identify candidate roadmap components during domain architecture development
- develop a roadmap and transition stages by:
- looking at dependency
- looking at value creation (balancing benefit, effort, and risk)
The TOGAF Architecture roadmap is a deliverable of the architecture development method Phase E - Opportunities & Solutions.
Architecture Roadmap vs Implementation Plan
It's a common mistake to think of an architecture roadmap as a linear plan. The architecture roadmap and implementation plan are distinguishes because one is a planning tool, and the other an implementation tool. TOGAF clearly separates the ADM Phases that develop a roadmap from an implementation plan.
Look at a roadmap, or a GPS route. They provide alternatives. Like an architecture roadmap, the GPS route will dynamically change based on traffic and choices you made on the journey.
Remember, a roadmap show you many paths to the same destination. Often with stops. The implementation plan is used to drive to the first known destination.
When to use an Architecture Roadmap
Architecture roadmaps should be used when there is a cross-functional, multi-phase, and multi-project change initiative. When the roadmap owner has complexity they will value the power of an architecture roadmap.
Significant transformations, like digital transformation, acquisition integration, or Cloud Transformation, all benefit from an architecture roadmap.
Sustained portfolios, like IT Modernization, Application Portfolio Rationalization, and government initiatives should have architecture roadmaps to support focus over time.
Architecture Roadmaps with Low Maturity Planning
Architecture roadmaps also help organizations with low planning maturity. When your leaders race from one priority to another, the will benefit from understanding an aspirational target. That way they can judge an emerging design.
With low planning maturity, a dynamic architecture portfolio is tied to a vision statement. The vision statement is an actionable statement of strategic intent. These visions:
- contain simple statements of the demand
- identify key results expected
- include some some success criteria, usually stated as a bald performance expectation
With low planning maturity, it is natural for stakeholders to want to get moving. A dynamic architecture roadmap used as an execution management tool places a premium on supporting selection of bottom-up project ideas.
The enterprise architect need to:
- identify the features of the intermediate destinations
- assist resolution of duplication and conflicting direction
- help measure a project's value contribution to the strategic vison v
Approaching the target this way defers detailed architecture work “just in time.” This approach corresponds with the way thinking naturally occurs within most organizations.
Architecture Roadmap Objectives
These are normal roadmap objectives
- Strategic Change
- Incremental Improvement
- Improve Cost
- Improve Quality
- Improve Enterprise Agility
- Mitigating Technology Risk
- IT Modernization
- Digital Transformation
- Application Portfolio Rationalization
- Acquisition Integration
How to use an Architecture Roadmap
We know that an architecture roadmap is made-up of work packages. These work packages are aligned to deliver sustainable value at transition point. We know that different work packages and transition stages will deliver different benefits. Benefits will include things like:
- create business capability
- improve operations in terms like efficiency, enterprise agility, or customer intimacy
- modernize systems
- launch products
- integrate an acquisition
The primary use of an architecture roadmap is to iteratively answer planning and execution questions:
- what work should be pursued
- what work should not be pursued
- how should they sequence work
- when must they decide to act
We answer these questions at different points in time:
Architecture Roadmap at Budgeting
Budgeting is a top-down planning moment. The roadmap owner will be seeking financial resources to drive change in the next fiscal period.
Planners will be looking at available budget and resources. The architecture roadmap will provide transition stages and work packages that will help the planner remove work.
The primary questions at at budgeting are:
- what work should be pursued
- how should they sequence work
Unexpected Risk of Great Architecture Roadmaps
We once generated Executive VP wrath towards the architecture team. The organization went through budgeting and usually pulled 2/3 of project ideas out of the budget. The new EA Team offered to help each EVP. Only a few EVPs chose to engage in the roadmap process. Those that did had submissions that were smaller because weak bottom-up ideas were abandoned and the ask was tied to the ability to execute. The roadmapped budget submissions had dependency, value, and transition points that justified every request.
Sounds good, right? The wrath came from the different submission success rate. Roadmapped budget submissions were almost 100% approved, and the non-roadmapped had around 3/4 of their submission pulled. EVP wrath came from looking unprepared in front of the executive committee.
Architecture Roadmap at Project Initiation
Project Initiation is an implementation governance moment.
The primary use of an architecture roadmap is to ensure the strategic objectives that created the roadmap are addressed. The key questions are:
- what work must the project deliver
- what work must the project not do
- how is success measured
Architecture Roadmap during Project Execution
Project Execution is a detailed implementation governance moment.
The roadmap defines what must, and must-not be delivered. The supporting target architecture has a set of architecture specifications.
The primary use of the architecture roadmap to answer questions about project execution scope and risk.
The key questions are:
- what work must the project deliver
- what work must the project not do
- how is success measured
Reacting to Change with the Architecture Roadmap
Reacting to change is a bottom-up planning moment that is critical to enterprise agility.
Over-time the roadmap owner will face project successes and failures, external threats and opportunities. At these moments the portfolio owner needs to reassess the roadmap.
They will re-answer the core questions:
- what work should be abandoned
- what work should be bought forward
- how should the sequence change
- what decisions should be deferred
Stakeholder Choices using the Architecture Roadmap
Portfolio owners want meaning progress towards their objectives, not more spend.
This is the essence of portfolio implementation governance - directing and controlling the implementation projects in the portfolio.
Too many enterprise architects are shocked how often the value-producing choice is to stop.
The architecture roadmap should help your portfolio owner to know when to take which of their four choices:
- stop
- pivot
- continue
- double-down
How to Develop an Architecture Roadmap
Developing a roadmap is an exercise in managing complexity. The number of potential work packages and transition states approaches infinite. All roadmap development is a balance between managing complexity and having the information to make better choices.
To minimize complexity roadmap development start with eliminating change paths that have low value or unacceptable risk. Once you have eliminated what you will not do, look for candidate transition stages that delivery value early, or reduce the risk of follow-on work.
The window to deliver is always finite. The longer and bigger the change the more opportunity for the unexpected. Senior leaders look to minimize uncertainty. That means you should look for early value delivery, and less risky value delivery.
Roadmap Value Math
Value is made up of harvestable benefits after you subtract effort. Value is expressed in any criteria your stakeholder care about. They will care about financial value, agility, alignment, customer intimacy, or any other concern.
Potential harvestable benefit is reduced by uncertainty. Uncertainty the project will succeed. Uncertainty the benefit can be harvested.
Anticipated effort is increased by uncertainty. Uncertainty the total required scope is known. Uncertainty the estimates are accurate.
In a simple math equation uncertainty has a larger impact on value than benefit or effort. Roadmaps are developed through iterative transition and trade-off conversations.
Continually test options to find:
- the least risky paths
- the least costly paths
- paths to different value measures
- the minimum work to reach value resting points
Basic Roadmap Information Creation Steps
All architecture development is built on knowledge manufacturing. Architecture roadmaps require information and knowledge.
The central knowledge manufacturing steps are:
- develop the baseline architecture
- develop the target architecture
- identify gaps from the difference between the baseline and target
- identify candidate roadmap components during domain architecture development
- identify transition stages by:
- looking at dependency
- looking at value creation (balancing benefit, effort, and risk)
Developing an architecture roadmap will use:
Architecture Roadmap Techniques
To create an architecture roadmap, employ both standard architecture development techniques and those that are specifically designed for roadmaps.
Standard Architecture Techniques used for Roadmap Development
Architecture Roadmap Techniques
- Architecture Roadmap Type 1: Heatmap
- Architecture Roadmap Type 2: Lifecycle
- Architecture Roadmap Type 3: Work Package
- Architecture Roadmap Type 4: Scenarios
Aligning Roadmap Techniques to Use Cases and Concerns
Architecture Alternatives & Trade-off
Architecture alternatives and trade-off are the most important stakeholder engagement techniques. Architecture alternatives are a method of problem solving.
Typically, multiple potnetial target architectures are possible. Once we have a candidate target, there will be multiple paths to reach the target. Usually alternatives involve changes in different domains. The TOGAF Standard highlights that superior architecture and concerns frame the analysis of alternatives.
The architecture alternative technique starts with the problem's requirements. Use vision, principles, strategy, and other superior architecture directions. Then create assessment criteria drawn from stakeholder concerns. Finalize assessment criteria from your stakeholders value preferences - the balance between benefit, effort, and risk.
Then the alternatives that reach the target are assessed in terms of the concerns.
Transition States
Transition states are best considered value resting points. The transition state is a set of changes that deliver relevant value. A transition state should be supported by a transition architecture.
Using the diagram to the right stops along the way could be considered transition states. At every transition state the roadmap owner can:
- stop or delay the journey
- pick a new destination
- speed-up
This is especially true when they are reacting to change with their architecture roadmap. The ability to react to unexpected threats and opportunities, while creating value is enterprise agility.
Implementation Strategy Model
An Implementation Strategy Model is one of the most powerful guidelines for the next architect, an implementer, and agile software development. Simply identifying that a change will be:
- Evolutionary
- Revolutionary
- Greenfield
Architecture Roadmap Types
Potential changes and selection criteria require different architecture roadmap types. The different types support different decision making.
You can use these Roadmap Types as architecture roadmap templates. Make sure you use the right template for your use case and roadmap objective.
- Architecture Roadmap Templates Aligned to Enterprise Architecture Use Case
- Architecture Roadmap Templates Aligned to Enterprise Architecture Objectives
Taken together, the techniques will highlight everything about a potential change.
Architecture Roadmap Type 1: Tagging with Recommendation and Heatmaps
Simple visualization of work packages. Heatmap will represent attributes like value, work, risk, or transition state. Helps represent and assess information. Selection of attributes represented will change heatmap completely.
Architecture Roadmap Type 2: Lifecycle Charts
Simple visualization of work packages, architecture component, or initiatives across time. Used to represent change over time. Color can represent attributes such as work, risk, or transition state.
Architecture Roadmap Type 3: Work Package Impact & Dependency
Complex visualization of work packages, architecture components, or transition states. Diagram will represent impact or dependency. Colour will often represent attributes such as value, work, risk, or transition state.
Most useful for discussions of trade-off and development of transition states.
Architecture Roadmap Type 4: Scenario Analysis across Multiple Candidates
Complex visualization of work packages, architecture options or transition state options. Rad plot will typically represent concerns or attributes such as value, work, or risk. Points on the plot will usually represent architecture options or transition state options.
When your architecture roadmap is using a broad set of criteria and candiate targets to select between architecture alternatives you must use Type 4: Scenario Analysis and Multiple Candidate technique.
We use Type 4: Scenario Analysis architecture roadmaps to support Scenario Analysis. We can perform scenario analysis looking forwards and forwards and backwards. Backwards helps build the current roadmap. It helps us understand what it takes to reach a preferred futures. Looking forwards, we use scenario analysis to see how well a roadmap will fit into larger futures.
Architecture Roadmap Techniques Aligned to Enterprise Architecture Use Case
Architecture teams support different purposes. Whether you support Portfolio questions or Solution Delivery will change how you develop and use architecture roadmaps. For example, Architecture to support Solution Delivery won’t use an Architecture Roadmap Type 1: Heatmap to develop decisions. We will use it as superior architecture and a set of constraints on the architecture development and any implementation. Good architects always work within the constraints of superior architecture.
Architecture to Support Strategy | Architecture to Support Portfolio | Architecture to Support Project | Architecture to Support Solution Delivery | |
Scenarios | Key Deliverable | Key Deliverable | ||
Architecture Roadmap Type 1: Heatmap | Key Deliverable | Key Deliverable & Superior Architecture | Superior Architecture | |
Architecture Roadmap Type 2: Lifecycle | Key Deliverable | Key Deliverable & Superior Architecture | Superior Architecture | |
Architecture Roadmap Type 3: Impact & Dependency | Common Deliverable | Key Deliverable | Superior Architecture | Superior Architecture |
Architecture Roadmap Type 4: Multiple Candidate | Key Deliverable | Key Deliverable | Superior Architecture | Superior Architecture |
Implementation Strategy Model | Key Deliverable | Key Deliverable & Superior Architecture | Superior Architecture | Superior Architecture |
Architecture Roadmap Techniques Aligned to Enterprise Architecture Objectives
Strategic Change | Incremental Change | Improve Cost | Improve Quality | Improve Enterprise Agility | Mitigating Technology Risk | IT Modernization | Digital Transformation | Application Portfolio Rationalization | Acquisition Integration | |
Scenarios | Very useful | Key constraints | Very useful | Very useful | Critical | Critical | ||||
Architecture Roadmap Type 1: Heatmap | Very useful | Critical | Critical | Critical | Critical | Critical | Critical | Very Useful | ||
Architecture Roadmap Type 2: Lifecycle | Critical | Very useful | Very useful | Very useful | Critical | Critical | Useful | Critical | Very useful | |
Architecture Roadmap Type 3: Impact & Dependency | Critical | Useful | Useful | Useful | Useful | Critical | Very useful | Critical | Very useful | Critical |
Architecture Roadmap Type 4: Multiple Candidate | Critical | Useful | Useful | Useful | Critical | Very useful | Useful | Critical | Very useful | |
Implementation Strategy Model | Key constraints | Key constraints | Key constraints | Key constraints | Key constraints | Key constraints | Key constraints | Key constraint | Key constraint | Key constraints |
Architecture Roadmap Tools
Architecture roadmap development uses standard architecture development tools.
The two most important are:
Transition Architecture
Transition architectures are a specialized target. A transition architecture stops on the journey, and treats that interim state as a target.
A transition architecture will deliver relevant value. Do not confuse a transition with project phases or calendar deliverables. Phases and calendar deliverables belong in an Implementation Plan.
We should create transition architectures when:
- There is enough change that an organization can stop all work and harvest value
- Architecture conformance changes
Work Package Criteria
Implementation governance requires many Work Packages have success criteria. Use some combination of:
- Critical Success Factors
What is necessary in the change for the work package, or transition architecture, to deliver the expected outcome - Measures of Effectiveness
A measure assessing the ability of the target system to meet the needs the expected outcome - Key Performance Indicators
Measures that show performance against a set of targets, or the expected outcome - Implementation Strategy
Direction on how to proceed with the implementation
It is quickly apparent that CSFs, MoEs, and KPIs are almost synonyms.They are different ways of assessing whether the implementation, the target system, or target operations are delivering.
In the Portfolio Roadmap, we will translate these to OKRs (Objectives and Key Results). Here they will measure the implementation project. As always best practice is to leverage existing management practices.
Architecture Roadmap Methods
Developing architecture roadmaps both specific roadmap methods and standard architecture development methods.
Standard Architecture Methods used for Roadmap Development
Architecture Roadmap Methods
Scenario Analysis
Scenario Analysis enriches the development of architecture roadmaps. Scenarios represent plausible futures. We can perform scenario analysis looking forwards and forwards and backwards.
Backwards helps us understand what gets us to a plausible future. We use this to make active choices to reach more preferable futures. Looking backwards helps us helps build the current roadmap that will reach our preferred target.
Forwards uses the future as a jumping off point. It considered what we do next & whether our choices enable us in a plausible future. Looking forwards, we use scenario analysis to see how well a roadmap will fit into larger futures.
Gap & Solution
Every gap can be filled by one or more solutions. Any solution will fill more than one gap. Using solutions, you simplify complex analysis into fewer potential options.
Bookend Method
Bookend provides change impact. People try to seek a compromise, or reasonable change. It feels more realistic. Using bookending the enterprise architect takes the change to the limit. Then uses the bookend to discover the implications of the change. Once you understand the implications, pull back and see if any implications are not applicable. Where do you see a change in value, work, or uncertainty? We usually find ‘more reasonable’ changes carry all the negative aspects of a bookend with fewer of the benefits.
Architecture Roadmap Stakeholder Engagement
An Architecture Roadmap will help answer the following questions:
- When will value be delivered – Transition States
- What change to pursue given different criteria – Architecture Roadmap Type 4: Scenarios
- What work will deliver value, and the cost and uncertainty – Architecture Roadmap Type 1: Heatmap
- When work, change, and value delivery will occur – Architecture Roadmap Type 2: Lifecycle
- What is the dependency & impact of work and change – Architecture Roadmap Type 3: Work Package
- What decisions are deferred – Architecture Roadmap Type 4: Scenarios
- What kind of change are we pursuing – Implementation Strategy
Roadmap Stakeholder Question Discussion
- What change to pursue given different criteria?
Fastest or cheapest path? Do we deliver agility, efficiency, or capability? Is fastest to efficiency better than cheapest to capability? The potential choices are infinite. Stakeholders must choose. Most stakeholders are very good at choosing in situations of insufficient information. Architecture roadmap development helps stakeholders make better decisions. Use an Architecture Roadmap Type 4: Scenarios when there are many potential paths and criteria.
- What work will deliver value, and the cost and uncertainty?
You cannot always be selecting between equally weighted priorities. Some problems are more pressing. When you understand the definition of value, cost, and risk appetite switch to an Architecture Roadmap Type 1: Heatmap. It displays work packages and transition states against comparative criteria.
- When work, change, and value delivery will occur?
When. There is a massive interplay between when and the value of a transition state. There is the same interplay between when and the cost of work. An Architecture Roadmap Type 2: Lifecycle shows when.
Do not be surprised that your stakeholders will discount value or work at different points in time. When time impacts value and work, expect dramatic change the scores on a heatmap.
In a digital environment with ubiquitous digital products and IT services across your value chain understanding ITFM is mandatory. You must maintain a cost model of all digital products and services. The business architecture will provide cost and value requirements.
- What is the dependency & impact of work and change?
If you do not explain dependency and impact, your stakeholders cannot make informed decisions. The Architecture Roadmap Type 3: Work Package shows dependency.
- What decisions are deferred?
Architecture roadmaps are not implementation plans. They support future decision making.
Best practice scenario development helps your stakeholders know when they need to make the next decision. We worked with a client who was stuck with an expensive rigid legacy process because they could not decide on the future state. We developed a set of scenarios that can be simplified as stay stuck, move to temporary accommodation, jump to option 1, and jump to option 2. This allowed them to see that when they couldn’t decide between option 1 & option 2, they were selecting to stay stuck. They had been inadvertently selecting "stay stuck" for a decade. We had them do a pair-wise to find the worst option, stay stuck.
Next was a roadmap that eliminated the expensive legacy process and freed operational staff, application developers, and infrastructure operators from the drag of the legacy. We were knowingly moving to a temporary state, while the stakeholders could explore the choices available without the operational and planning constraints of the legacy.
Architecture Roadmap Type 4: Scenarios help identify points where future decision can be deferred. The more future decisions points your roadmap contains, the more enterprise agility you are providing. Every decision point is a transition state. There is an option to stop and harvest value.
- What kind of change are we pursuing
An Implementation Strategy Model is one of the most powerful guidelines for the next architect, an implementer, and agile software development.
Identifying that a change will be:
-
- Evolutionary
- Revolutionary
- Greenfield
The Implementation Strategy is a powerful implementation governance tool.
Conclusion of Architecture Roadmap as Design
Architecture Roadmaps answer the questions asked by the Stakeholder:
- what work should be pursued
- what work should not be pursued
- how should I sequence work
- when must I decide to act
Developing an architecture roadmap is a collaborative process. Enterprise architects work with stakeholders to define the target and the journey. Stakeholders will be selecting between architecture alternatives to create the roadmap and as transition stages.
Developing the Architecture Roadmap with the Stakeholder helps them understand the implications of their choices and perform architecture trade-off.
An Architecture Roadmap is a planning tool that helps an organization’s decision-makers. A dynamic Architecture Roadmap is designed to help them develop and travel the best path forward. It also helps them govern the projects that fulfill their portfolio.
Change is a choice. Dynamic architecture roadmaps facilitate better decisions. Then, track different project's progress towards the target.