TOGAF® ADM Phase E – Build the Architecture Roadmap

TOGAF ADM Phase E develops the architecture roadmap. Useful architecture roadmaps ensure the enterprise architects guide effective change. Without a roadmap, enterprise architecture is just a knowledge building exercise. TOGAF Phase E and architecture roadmaps deliver on the purpose of enterprise architecture. They enable effective change.

Guiding effective change requires the Architecture Roadmap developed in TOGAF ADM Phase E. Developing four foundational enterprise architecture domains. To create a complete enterprise architecture is pointless without the architecture roadmap. TOGAF 10 is direct – enterprise architecture guides effective change, and the architecture roadmap is central to change planning.

Digital transformation requires orchestrating change in business operations, organization design, the software portfolio, and infrastructure. You will never achieve the best enterprise without the right IT Architecture. Neither are possible without an architecture roadmap.

TOGAF separates the Phase E architecture roadmap from the Phase F implementation plan to highlight different purposes. Use the development of the architecture roadmap to perform trade-off and make value selections. When your stakeholders understand their choices, the costs, and benefits, and how they must govern change projects, they are ready to develop the implementation plan.

Learn about TOGAF Certification

TOGAF ADM Phase E – Build the Architecture Roadmap

At a Glance:

TOGAF ADM Overview

The TOGAF ADM sets the TOGAF Framework apart from other enterprise architecture frameworks. It is the only enterprise architecture framework includes all three parts of a framework – how to document an architecture, how to build an enterprise architecture team, and how to develop and architecture.

TOGAF ADM Develops an Enterprise Architecture

Each TOGAF ADM phase explains the activities to develop knowledge. Each ADM Phase develops knowledge about part of the enterprise architecture. The interactions between the Phases are information flows. These information flows coalesce into a few critical deliverables – one is the TOGAF ADM Phase E Architecture Roadmap.

>>> If you need an overview of the TOGAF ADM, please read the TOGAF ADM Phases Explained.

What is TOGAF Phase E?

TOGAF Phase E provides the steps and information inputs to create an Architecture Roadmap. Enterprise Architects lead the process for stakeholders and domain architects to create the architecture roadmap.

What is the Objective of TOGAF ADM Phase E?

The objective of Phase E is to move past the simplified target architecture in the Architecture Vision. The simplified candidate architecture developed in Phase A showed promise. Activity in Phase E determines whether the ideas are worth investing in.

Best practice architecture development following TOGAF ADM considers possible changes. Many possible changes fail key tests. Look for changes that are:

  • Too much work for the return
  • Success is too uncertain for the return
  • The return is only nice to have

Your organization has more potential improvements than it can complete. A key role of enterprise architecture is to focus attention on the best change. Winnowing weak change ideas frees resources for successful changes. The moment an idea looks weak, winnow it out. Hunt for chaff! Kill weak ideas! Then, celebrate your victory! Celebrate that you are enabling successful change!

You do this by bringing together the domain architecture developed in Phase B (Business Architecture), Phase C (Application Architecture), and Phase D (Technology Architecture) into a candidate enterprise architecture. You need to chase changes across every domain. The consolidated set of changes are foundation of the Architecture Roadmap.

Success requires:

  • You address the problem of how your enterprise cannot meet the preferences of the stakeholders (Complete Gaps)
  • You know the work that is worth doing (Focus Change & Winnow Distractions)
  • You know the work necessary to deliver complete change (Work Package)
  • You understand the interaction between changes and constraints in other architecture domains to protect the value expected (Architecture Requirements Specifications)

Interaction with TOGAF Phase B, Phase C, and Phase D

Waterfall approaches do not deliver. Best practice enterprise architecture is not a waterfall activity. The only successful approach requires developing the business architecture, application architecture, data architecture, technology architecture and security architecture simultaneously.

The reality of domains requires separate development. The language of the TOGAF ADM attempts to explain simultaneously and separately developing the candidate architecture. TOGAF uses the term iteration. Best practice simultaneous development uses the agile approach of just enough. Move a bit, test the cascading constraints in other domains.

Application architects are specialists in one architecture domain. This is the same for business architects, data architects, technology, and security architects. Enterprise architects are generalists. Where there are gaps, they need to fill in. Where there is strength, they fall back. They never give-up the critical role of crossing boundaries.

What is an Architecture Roadmap?

An architecture roadmap is a blueprint of work packages that change an enterprise from the ‘Baseline Architecture’ to the ‘Target Architecture.’ An architecture roadmap is your complete change plan. It tells you the options available at every transition stage.

One of our enterprise architecture consulting clients expressed the perfect architecture roadmap

… includes options and value statements associated with each Work Package. Value stated in terms of business capability, market reach and limitations .... Provide awareness of existing roadblocks. Including why they are roadblocks and implications of addressing them head on or continuing to detouring...

Let’s unpack these architecture roadmap definitions. First, the architecture roadmap is a blueprint for change. It links the work packages necessary to change the organization from where it 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. More valuable, easier, quicker, cheaper, less uncertain, better for efficiency, or better for enterprise agility. Help the stakeholders select the changes that are best.

Third, you need off-ramps and transitions. Never forget, you are with a successful organization. This provides evidence that we do not need to tackle every deficiency. Neither do we need to change. Change is a choice.

Why is an Architecture Roadmap Different From an Implementation Plan?

The TOGAF Standard ADM separates Phase E and Phase F, and the Architecture Roadmap from the Implementation and Migration Plan. The separation is based on best-practice planning. An architecture roadmap supports deciding your path, destination, and where decisions still have not been made. It also supports identifying where there are unresolved forks in the journey. The implementation and migration plan only support execution.

We can guarantee that your current roadmaps do not explain options in transition states. Not a single instance in our several thousand years of enterprise architecture consulting experience. Every roadmap we have seen was a simple linear plan. Usually built bottom-up. Usually aimed at reasonably possible changes. Usually heading nowhere.

Always separate an architecture roadmap from an implementation plan. Use the architecture roadmap to examine the future. Then build an implementation plan to drive to the first known destination.

Real roadmap development is done with a stakeholder. The enterprise architect, with the business architect, the application architect, and the technology architect, explores how to move forward. What are useful transition states? Look for, and drop, potential changes that deliver too little, require too much work, or have too much uncertainty.

Download the Enterprise Architecture Governor's Guide
TOGAF 10 Phase E Roadmap

TOGAF ADM Phase E Architecture Roadmap Deliverables

The central outcome of Phase E is an architecture roadmap. This is the action part of the enterprise architecture.

Most valuable use of the Architecture Roadmap

  1. Stakeholders performing trade-off and selecting transition states during the development of the Architecture Roadmap
  2. Guiding change projects at initiation, scope adjustment, and completion
  3. Guiding implementers regarding the value of their project, scope, and the project execution constraints

An Architecture Roadmap will help answer the following questions:

An architecture roadmap is the enterprise architecture planning tool. It pulls together the four aspects of change – value, cost, uncertainty, and option. We measure value and cost of change in criteria that matter to our stakeholders. Decrease potential value based on uncertainty. We recommend a geometric impact – every small increase in uncertainty has a large decrease in potential value.

If you use different labels than we do, please look at the purpose of the tool or technique. We always focus on what we are trying to accomplish when performing enterprise architecture consulting. We relax about what the tool or technique is called. We won’t care if you call it an Ishikawa diagram, fishbone diagram, or a cause-and-effect diagram. We will be performing a structured analysis of the root cause.

Reach for an effective technique. Consider the root cause. I’ll bet you thought about IT Incident. If you did, think again. Root cause analysis is powerful – what is the root cause of low enterprise agility? IT complexity? Change your architecture to remove the root cause, or life with the system recreating the problem.

Completion of Phase E Architecture Roadmap

All TOGAF ADM Phases lead you to developing the knowledge you need. The outcome of Phase E is an architecture roadmap and supporting candidate enterprise architecture.

Output & Outcome Essential Knowledge
A set of work packages that address the set of gaps, with a sign of value produced and effort required, and dependencies between the work packages to reach the adjusted target. Dependency between the set of changes. (Work Package & Gap dependency)

Value, effort, and risk associated with each change and work package.

How stakeholder priority and preference adjust in response to value, effort, and risk of change.

Table from TOGAF 10 TOGAF Series Guide: Enterprise Architect’s Guide to Developing Architecture

Phase E Bare Bones

In Phase E, the enterprise architect performs most of the heavy lifting to develop a target architecture. Improvements without work or risk are dreams. Architecture roadmaps require acceptance of work and uncertainty.

The bare bones of Phase E are:

  • Knowing when value will be delivered

We wish understanding value was easier. We wish the word value was, well, less valuable. The more work we do, the more nuance we find in the concept. As you move from strategy, to portfolio, to project, to solution delivery understanding of value shifts. Value expectations are more concrete the closer to a solution delivery or implementation conversation.

We lean towards Lean Six-Sigma’s explanation of value - something the customer will pay more for. We expect to understand value from two places, first the business architecture. The business architecture will explain where your organization creates value and will help to optimize architecture towards this value. The second place is the Stakeholder Map developed in Phase A. They may focus your architecture project on a specific outcome that indirectly enables your organization’s value generation.

Transition states are where your architecture can deliver specific value. When consulting, we use Value Resting Points as a synonym for architecture transition. Every transition is a future decision. It is an off-ramp on the current journey.

Stakeholder will exercise an off-ramp for two reasons:

  1. The work to reach the next value resting point exceeds the current assessment of value.
  2. The work to reach the next value resting point could apply to a different change that delivers a more exciting or rewarding resting point.

Developing the roadmap through transition and trade-off conversations is the provide one of the most valuable outcomes of a strategy or portfolio roadmap exercise. Resources are finite. Senior leaders are always on the look-out for the best-path-forward delivering on many criteria, not the best return on one criterion.

  • 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 impact value and work, expect dramatic change the scores on a heatmap.

  • 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: Scenario 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. Simply identifying that a change will be:

    • Evolutionary
    • Revolutionary
    • Greenfield

The Implementation Strategy Model is a powerful implementation governance tool.

The three completion essentials of Phase E:

  • First, definition of value? How will we measure success?
  • Second, scope of change? What will change in this transition state? What will not change?
  • Third, how will you know the change succeeded? What is your governance test for success? How will you guard value?

With these three essentials, the stakeholders are ready to develop an implementation plan. They know what they want done. They know what they do not want changed. They know how they will measure success.

The architecture roadmap will help them drive to value.

TOGAF ADM Phase E – Architecture Roadmap Deliverables and Enterprise Architecture Purposes

There are four core purposes for developing enterprise architecture. Either you are supporting Strategy, Portfolio, Project, or Solution Delivery. In most circumstances, you will not develop an Architecture Roadmap unless you are supporting Strategy or Portfolio. The TOGAF 10 patterns are explained in the Enterprise Architect’s Guide to Developing Architecture.

Different deliverables have different importance in each purpose.

Architecture to Support Strategy

When you are supporting strategy, you will provide an end-to-end Target Architecture and develop roadmaps of change. Your architecture will identify change initiatives and supporting portfolio and programs. The architecture roadmap will set terms of reference, identify synergies, and govern the execution of portfolio and programs.

Architecture to support Portfolio

When you are supporting a portfolio, you will normally address the single portfolio. Your architecture will identify projects, and set their terms of reference, align their approaches, identify synergies, and govern the project’s execution.

Architecture to Support Strategy Architecture to Support Portfolio Architecture to Support Project Architecture to Support Solution Delivery
Phase E Work Product: Candidate Enterprise Architecture During strategic planning session

Refresh as required in program budgeting

 Key deliverable

Before start of budget planning

Primary use is stakeholder acceptance of target and definition of gap

 Before project initiation and finalization of business case

Primary use is the creation of Architecture Requirements Specification

 Before engagement of execution partners (including internal providers)

Primary use is the creation of Architecture Requirements Specification
Phase E Work Product: Architecture Roadmap During strategic planning session

Refresh as required in program budgeting

 Key Deliverable

Before start of budget planning

Refresh as required to support budgeting and program management

 Limited use

Can be used as an input to projects with multiple interactive changes

 Before engagement of execution partners (including internal providers)

Primary use is identification of required change, and preferences of how to execute change, to manage solution delivery partner selection and engagement

Table from TOGAF 10 TOGAF Series Guide: Enterprise Architect’s Guide to Developing Architecture

Candidate Enterprise Architecture

The complete enterprise architecture will comprise the domain architecture models and the set of consolidated gaps.

Remember, your enterprise architecture comprises domain architectures. A powerful analysis and record keeping method is modeling.

Architecture Roadmap

The structure of your Architecture Roadmap changes whether you are working to support strategy, portfolio, or project. Roadmaps are used to make decisions or govern implementation.

  Architecture to support Strategy Architecture to support Portfolio Architecture to support Project Architecture to support Solution Delivery
Architecture Roadmap Type 1: Heatmaps Decision and governance Governance Governance
Architecture Roadmap Type 2: Lifecycle Chart Governance

Limited decision

 Governance Governance
Architecture Roadmap Type 3: Impact & Dependency Decision and governance Decision and governance Governance Governance
Architecture Roadmap Type 4: Scenario & Multiple Candidates Decision and governance Decision and governance
Implementation Strategy Model Decision and governance Decision and governance Governance Governance

 

What is the role of the Enterprise Architect in Phase E?

In TOGAF Phase E, we expect the Enterprise Architect to bring together to candidate roadmap components and synthesize enterprise change. They will lead trade-off analysis with stakeholders to determine the target architecture.

In TOGAF Phase E, the enterprise architect’s role is to guard the expected value. For example, a business architect may not see the outcome of changes they are driving into application and technology. Depending upon the skills of the domain architects, the enterprise architect will fill-in. They may not understand and effectively communicate with other domain architects.

The most important role of the enterprise architect is crossing boundaries. Whether they are domain, skill, or authority boundaries, the enterprise architect needs to cross them.

Two Central Facts about TOGAF Phase E – Architecture Roadmap

Our approach to developing enterprise architecture teams is pragmatic. We focus it on getting useful architecture. It is based on hard facts. There are two central facts we tell enterprise architects about TOGAF Phase E – Architecture Roadmap. First, unless you have stakeholders and concerns, you cannot proceed. Until you know what is valuable, the relative priority of speed, certainty, efficiency, enterprise agility, and change cost, your plan is a wild guess. Second, if they believe they need to jump into doing, they are useless. People who will charge forward in a random direction surround stakeholders. Stakeholder do not need enterprise architects for that.

Explore TOGAF Certification Training
TOGAF ADM Phase E Architecture Roadmap Models

Architecture Roadmap Models, Tools, and Techniques

The TOGAF ADM Phase E delivers the Architecture Roadmap. This Phase exists to enable action.

Phase E is often a translation between Architecture Views to decision. Architecture views force analysis of an architecture against a stakeholder concern. They are critical to best practice architecture development. However, they can be overwhelming to a stakeholder. There are six central roadmap development techniques that help stakeholders understand the choices and implications.

  • Scenarios
  • Architecture Roadmap Type 1: Tagging with Recommendation and Heatmaps
  • Architecture Roadmap Type 2: Lifecycle Charts
  • Architecture Roadmap Type 3: Work Package Impact & Dependency
  • Architecture Roadmap Type 4: Scenario Analysis across Multiple Candidates
  • Implementation Strategy Model

Architecture Roadmap Techniques

Potential changes and selection criteria require different architecture roadmap techniques. The different techniques support different decision making. TOGAF Phase C Architecture Roadmap is less about developing the Target Architecture that it is selecting outcomes and acceptable work.

Taken together, the techniques will highlight everything about a potential change.

Scenario

Scenarios allow you to explore a potential future, or architecture alternative. We look at two different scenario methods, the first explores implications of external change. The second explores either the implications or requirements of a change we will drive.

As an example, consider public cloud. In the first approach, you would look at the implications in your organization if the rest of the world moves to the public cloud. For example, you might not have enterprise systems commercially available from viable providers. In the second, what will your world look like if you drive to the public cloud?

Scenarios help us understand how to fit into a possible world, or how to reach a preferred future. Scenario development requires being able to weigh organization and stakeholder preference, the probable path of major external trends, and how forces come into play.

TOGAF 10 Architecture Alternatives and Scenarios

Learn more about Conexiam’s Scenario Workshops

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.
Archiecture Roadmap Type 1 - Heatmap

Learn more about Conexiam’s Architecture Roadmap Workshops

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 2 - Lifecycle

Learn more about Conexiam’s Architecture Roadmap Workshops

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 3 - Dependency

Learn more about Conexiam’s Architecture Roadmap Workshops

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 needs to select between architecture alternatives you must use Type 4: Senario Analysis and Multiple Candidate technique.

Most useful for discussions of trade-off and option selection.

Architecture Roadmap Type 4 - Scenario

Learn more about Conexiam’s Architecture Roadmap Workshops

Implementaion 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 Tools

We use a broad set of tools to develop and communicate an architecture roadmap.

  • Transition Architecture
    Transition states are best considered value resting points. A set of changes that deliverable relevant value. Do not confuse a transition state and project phases or calendar deliverables. Phases and calendar deliverables belong in an Implementation Plan.
    A Transition Architecture will only list dates as a ‘required by’, or ‘drop-dead’ date, which is driven by value calculations of a Type 2: Lifecycle Chart.
    We should create transition states when:

    • There is enough change that an organization can stop all work and harvest value
    • Architecture conformance changes
  • Bookends
    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.
  • 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.

Architecture Roadmap Techniques Aligned to Enterprise Architecture Purpose

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 Models for Enterprise Architecture Use Cases

Architecture Roadmap techniques provide better support for different enterprise architecture use cases. Depending on the use case, enterprise architects are more efficient in helping their stakeholders with different techniques.

While every enterprise architecture use case is about change, the type of change and drivers are different.

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

Applying Enterprise Architecture Principles to Architecture Roadmap Development

Your architecture principles will drive and constrain your roadmap development. Our consulting practices identified 7 Architecture Principles every enterprise architect should know. The following table provides a simple example of how a roadmap is driven and constrained by superior architecture delivered through principles. Any roadmap development that doesn’t conform to the letter and spirit of superior architecture needs to be caught by enterprise architecture governance and reworked.

Architecture Roadmap Implication
Don’t Mess With Success All change needs to be assessed by the possibility it will damage current success. Potential improvement needs to be constrained to ensure the baseline is maintained.
Focus On Excellence Change must be focused. All change without a direct line to enterprise value must be questioned. Use value definitions supporting excellence to assess the potential value of a change.

Do not be afraid to identify changes that do not improve enterprise excellence as ‘value free.’
Why Not One? Changes that create duplication need to be challenged, with value delivery decreased.

Changes that remove duplication need to have the value delivery increased.
Data is an Asset Ensure control of the data model is not surrendered in ways that diminish the value of data asset.
Systems Work Where We Work Work location and work style are foundational measures of value. Any change that cannot meet location and style needs value delivery decreased.
Painless User Experience Change costs need to be reviewed to ensure that user impact is properly assessed. Carefully look at change impact compared to potential benefit. You will always pay for impact, while you might not receive the expected benefit.
Self Service Self-service is an enterprise value measure. Look at self-service delivery through the baseline, transition, and target states. Adjust cost and benefit assessments to reward provisioning self-service and penalizing and damage to existing self-service. You always pay for damage. You might receive a benefit.

How does TOGAF Phase E align with Agile Development?

Every Architecture Roadmap will provide multiple constraints and guidance for agile development. We see Enterprise Architecture and Agile Development intersecting in four areas. The architecture roadmap will:

  1. define the agile approach
  2. guide the backlog in sprint
  3. constrain choices inside the sprints
  4. solve for cross product dependency

The Architecture roadmap will significantly impact defining the agile approach. For example, the Implement Strategy Model will force or prohibit using agile development. As will expected transition states. Transition states and roadmap value measures will inform product development or product release, which will guide the backlog.

How does TOGAF Phase E enable Enterprise Agility?

Remember, enterprise agility is about your organization's ability to respond to the unexpected. Roadmaps are about responding to the expected. Stronger architecture roadmap development skills will help an organization respond to the unexpected. When you consider the five aspects of the enterprise agility model, you can see a direct correlation to developing an architecture roadmap.

Enterprise Agility Model

  1. Alertness – Can you detect opportunities and threats?
  2. Accessibility – Can you access relevant information in time to respond?
  3. Decisiveness – Can you decide using the available information?
  4. Swiftness – Can you implement your decisions in the time available?
  5. Flexibility – What are you doing to reduce the barriers to action?
TOGAF ADM Phase E Architecture Roadmap
Be a Better Enterprise Architect - Free 12-week Kickstart Program

Final Thoughts on TOGAF ADM Phase E

There is nothing more important for an Enterprise Architecture Team than developing architecture roadmaps. Roadmaps are central to selecting change when the team supports strategy and portfolio. Also, roadmaps are central to guiding change for teams supporting project and solution delivery.

Teams that support project and solution delivery may need to reverse engineer a portfolio roadmap to get the guidance and constraints they need.

Enterprise architects working in TOGAF ADM Phase E have a complex role.

  • work with stakeholders and SME to both select desired changes and winnow every other change
  • work with domain architects to package solutions that minimize the number of potential changes that need to be considered
  • work with stakeholders to carry the change decisions into formal planning and change governance.

In TOGAF ADM Phase E, you bring together the enterprise architecture domains. The complete enterprise architecture is driven by selected change. TOGAF is very clear. The purpose of developing architecture is to guide effective change. An architecture needs an architecture roadmap to provide value.

High functioning EA Teams focus on architecture roadmaps. Everything they do is considered against the web of deficiencies, planned changes, and inflight changes.

TOGAF ADM Phase E develops the architecture roadmap. The architecture roadmap translates the enterprise architecture from a knowledge building exercise into action. Use TOGAF Phase E to deliver action. Action that constrains scarce change resources to the most enterprise value. Deliver on the purpose of enterprise architecture and deliver effective change.

Take the Plunge - Get TOGAF Certified
Scroll to Top