Enterprise Architecture Roadmap: Template, Example and How to Present It
9 min read ยท 2026-10-25
An enterprise architecture roadmap is a time-based plan that shows how your business capabilities, applications, data and technology will move from where they are today to a target state, through a few planned transition states. It links each change to a business goal, names the initiatives that deliver it and shows the dependencies between them.
Many EA roadmaps end up as a wall of boxes that only architects read. The useful ones answer three questions for leadership: which business outcomes does this support, what changes when, and what do we stop doing. The 12-month plan below builds that roadmap in six phases, from capability map to the first funded transition, with a milestone for each. It then covers a filled-in example, who owns what, how to present it to the steering committee and the metrics that show the architecture is improving.
The approach borrows ideas from TOGAF, such as baseline and target architectures, gap analysis and transition architectures. You do not need to run the full framework to use it.
The roadmap at a glance
Goal: By month 12, leadership has approved a target architecture and a sequenced roadmap of transition states, the first initiatives are funded and running, and an architecture review board governs changes. Duration: 12 months (52 weeks)
Scope and business drivers (Weeks 1-4)
Tie the architecture work to the business strategy and agree on scope.
- Interview the CIO, CFO and business unit heads about the top three to five strategic goals for the next few years.
- Turn each goal into architecture drivers, such as one customer view, faster product launches or lower run costs.
- Agree on scope: whole enterprise or one business unit, and which layers (business, data, application, technology).
- Set up a steering committee with an executive sponsor and the business leads who will fund change.
Milestone: A signed architecture charter with the strategic goals, the drivers, the scope and the steering committee members.
Capability map and current state (Weeks 3-12)
Describe what the business does and which systems support it today.
- Build a business capability map with two or three levels, such as Customer Management, then Customer Onboarding.
- Inventory applications in a repository or spreadsheet: owner, users, capabilities supported, technology, contract end date, run cost and known issues.
- Map key data entities, such as customer, product and order, to the systems that create and use them.
- Document the main integrations and the infrastructure each application runs on.
- Score each application on business fit and technical health with its owners.
Milestone: A capability map and an application inventory reviewed by business and IT owners, with every application linked to at least one capability.
Target state (Weeks 10-18)
Agree on where the architecture should be in three to five years.
- Heat-map the capability map against the drivers to show which capabilities need the most change.
- Set architecture principles, such as buy before build for non-core capabilities or one system of record per data entity.
- Sketch the target application landscape and data flows for the capabilities that matter most.
- Classify each application with a disposition such as tolerate, invest, migrate or eliminate.
Milestone: A target state view and a disposition for every application, approved by the steering committee.
Gap analysis and initiatives (Weeks 16-24)
Turn the difference between today and the target into a list of initiatives.
- List the gaps per capability: missing functions, duplicate systems, poor data quality, end-of-life technology.
- Group gaps into initiatives, such as CRM consolidation or data platform build.
- For each initiative, write a short case with the business outcome, rough effort, dependencies and risks.
- Score initiatives on business value, risk reduction, effort and urgency, such as an expiring contract.
Milestone: A ranked initiative list with a one-page case for each of the top initiatives.
Transition states and sequencing (Weeks 22-30)
Order the initiatives into realistic steps toward the target.
- Define two or three transition states, each a stable architecture the business can run on.
- Place initiatives on a timeline by quarter, respecting dependencies such as data platform before analytics.
- Check capacity with delivery leads and budget with finance for each period.
- Align dates with contract renewals, end-of-support dates and planned business changes.
Milestone: A sequenced roadmap with transition states, initiative dates and dependencies, approved by the steering committee with funding for the first transition.
Governance and first transition (Weeks 28-52)
Start delivery and keep new decisions aligned with the roadmap.
- Set up an architecture review board with a lightweight process for new projects and exceptions.
- Add an architecture check to the project intake and funding process.
- Kick off the first initiatives and track them against the transition state they belong to.
- Update the repository as systems change and refresh the roadmap each quarter.
Milestone: Architecture review board running, first initiatives delivering on plan and the first quarterly roadmap refresh presented.
What goes on an enterprise architecture roadmap
The roadmap itself is usually one view with swimlanes by layer or by capability: business changes at the top, then data, applications and technology. Each lane holds initiatives as bars across quarters, with markers for transition states and key dates such as contract ends or system retirements. Arrows show dependencies between lanes.
Behind that one view sit the artifacts that justify it: the capability map, the application inventory with dispositions, the target state, the gap list and the initiative cases. Leadership sees the roadmap. Architects and delivery teams use the rest. Keep both in sync, or the roadmap drifts into a slide nobody trusts.
Example: a filled-in roadmap for a regional bank
Picture a bank with three customer onboarding systems from past mergers, a core banking platform near the end of vendor support and a strategy goal of a better digital experience. Here is how the first year of the roadmap could look.
Notice that the core banking replacement is not in year one. The roadmap first fixes the data and customer layers it depends on, so the larger program starts on firm ground.
- Q1, scope and current state: CIO as sponsor, capability map and inventory of around 300 applications. Owner: EA lead. Milestone: inventory reviewed by business owners.
- Q2, target and gaps: one onboarding system, a customer data hub and an API layer in the target; 40 applications marked eliminate. Owner: EA lead with domain architects. Milestone: target state approved.
- Q3, sequencing: transition state 1 is customer data hub plus onboarding consolidation; transition state 2 is core banking replacement. Owner: EA lead and PMO. Milestone: roadmap approved with funding for transition 1.
- Q4, governance and delivery: architecture review board live, customer data hub build started, first duplicate applications retired. Owner: CIO and delivery leads. Milestone: first quarterly refresh presented.
Who owns what
Enterprise architects own the map, not the change. The changes belong to the business and delivery leaders who fund and run them. If the roadmap is seen as an IT document, business units will ignore it when they buy their next tool.
Put names next to each role and each initiative. An initiative with no business owner is a wish.
- Executive sponsor (CIO or COO): chairs the steering committee and settles priority conflicts.
- Chief or lead enterprise architect: owns the roadmap, principles and repository.
- Domain architects (business, data, application, infrastructure): current and target state for their layer.
- Business capability owners: confirm needs, own the business case and accept the changes.
- Application owners: keep inventory data current and carry out dispositions.
- PMO or portfolio manager: links roadmap initiatives to funded projects and tracks delivery.
- Finance partner: run cost data and funding per transition state.
How to build it in a tool
You can start in Excel and PowerPoint. Keep the inventory in a workbook with one row per application and columns for owner, capabilities, disposition, health scores, contract end and cost. Build the roadmap slide with swimlanes as rows, quarters as columns and initiatives as colored bars: one color per transition state. Add milestone diamonds for retirements and go-lives.
As the inventory grows past a few hundred items, an EA repository such as LeanIX, Ardoq or a similar tool helps you link capabilities, applications and initiatives, and generate views from that data. Many architects use the ArchiMate modeling language for diagrams that need a shared notation. Whatever you use, generate the roadmap view from the same data as the inventory so they never contradict each other.
How to present it to the steering committee
Lead with the business goals, not the architecture. The first slide should show the three to five strategic goals and the capabilities that most need to change to reach them, as a heat map. The second slide is the roadmap: transition states, initiatives by quarter and the big retirements. The third is the ask: funding for the next transition and the decisions you need.
Leave out the full application list and detailed diagrams. Bring them as backup. Show what the business gets at each transition state in plain words, such as one onboarding process for all products, and what it stops paying for.
Metrics to track
Measure whether the architecture is getting simpler and better aligned, not only whether projects ship. Report a few numbers each quarter at the steering committee, with the baseline from the current-state phase.
Pick metrics your inventory can produce without manual counting each time, or they will stop being updated.
- Application count and redundancy: total applications and capabilities served by more than one system.
- Retirements: applications retired against the roadmap plan.
- Technical health: share of applications on supported technology versions.
- Run cost: total cost of the application portfolio, from finance.
- Roadmap alignment: share of new projects that passed architecture review and map to a roadmap initiative.
- Initiative delivery: initiatives on track, late or at risk per transition state.
Risks and dependencies
The biggest risk is the roadmap going stale. Business priorities shift, a vendor changes its product, or a merger adds a new set of systems. Refresh the roadmap each quarter and re-approve it once a year with the strategy cycle.
Give each risk an owner and a fallback, and review them at the steering committee.
- Poor inventory data: owner is the EA lead; fallback is to start with the top capabilities and expand.
- Business units buying outside the process: owner is the sponsor; fallback is an architecture check in procurement.
- Key initiative slips and blocks others: owner is the PMO; fallback is an interim integration so dependent work can start.
- Vendor end-of-support dates move: owner is application owners; fallback is a support extension agreed early.
Common mistakes to avoid
- Starting with technology diagrams instead of business goals makes the roadmap an IT document, so open every review with the strategic drivers.
- Trying to document everything before deciding anything burns months, so focus the current state on the capabilities the drivers point to.
- Jumping straight to the target state skips the steps the business can live with, so define stable transition states in between.
- Leaving initiatives without a business owner means nobody funds them, so assign a capability owner to every initiative.
- Keeping the inventory and the roadmap in separate files lets them drift apart, so generate the roadmap from the inventory data.
- Publishing the roadmap once and never updating it makes it irrelevant, so refresh it quarterly at the steering committee.
Frequently asked questions
What is included in an enterprise architecture roadmap?
Business drivers, a capability map, the current state, a target state, a gap analysis, initiatives, transition states and a timeline with dependencies. Most roadmaps show them as swimlanes by layer or capability across quarters. Governance keeps it current.
How far ahead should an enterprise architecture roadmap look?
The target state often looks three to five years ahead, while the detailed roadmap covers the next 12 to 24 months. Keep the near term specific and the later periods at theme level. Refresh it every quarter.
What is a transition architecture?
It is a stable state between today and the target that the business can run on. TOGAF uses the term for these intermediate steps. Planning them lets you deliver value along the way and stop safely if priorities change.
Who creates the enterprise architecture roadmap?
The enterprise architecture team leads it, usually under the CIO. Business capability owners, application owners, the PMO and finance all contribute. The steering committee approves it and funds the initiatives.
Do I need TOGAF to build an EA roadmap?
No. TOGAF offers a useful method and vocabulary, such as baseline, target and transition architectures. Many teams use a lighter process built on a capability map, an application inventory and a sequenced initiative list.