Target Operating Model & Roadmapping

A Target Operating Model (TOM) describes the organization’s future capabilities, processes, data, applications, and technology once a transformation is complete.

At a glance

• What it is: A future-state description of the organization, connected to today’s baseline through transition architectures and a sequenced roadmap.
• Why it matters: A future-state vision with no roadmap is just a wish — the roadmap is what turns strategy into fundable, schedulable, trackable work.
• For developers: a roadmap item assigned to your team is usually one transition architecture, not the whole target state — confirm what the actual intermediate milestone is before you scope the work.
• When to use it: Planning any multi-year transformation, modernization, or major platform change.
• When not to use it: For a single, self-contained project with no dependency on broader organizational change.
• Prerequisites: The Four Architecture Domains (BDAT), since a TOM is described across all four.

Mental model

graph LR
    Base["Baseline<br/>(current state)"] --> T1["Transition 1"]
    T1 --> T2["Transition 2"]
    T2 --> Target["Target Operating Model<br/>(future state)"]
    Road["Roadmap"] -.sequences.-> T1
    Road -.sequences.-> T2

The gap between baseline and target is never closed in one leap — it’s closed through intermediate transition architectures, each sequenced and funded by the roadmap.

Step-by-step walkthrough

1. Document the baseline (current-state) architecture across all four BDAT domains.
2. Define the Target Operating Model — the desired future state.
3. Run a gap analysis, comparing baseline and target capability-by-capability.
4. Define transition architectures — realistic intermediate states between baseline and target.
5. Sequence the work into a roadmap, tied to funding and dependencies.
6. Review and adjust the roadmap on a regular cadence (e.g. quarterly or annually).

Worked example

An insurer modernizing claims processing:

• Baseline: manual claims intake and adjudication.
• Transition 1: pilot automated intake for one product line.
• Transition 2: extend automation to adjudication and full product coverage.
• Target: fully automated claims platform across all product lines.
• Roadmap: sequences these transitions against budget cycles and delivery capacity.

Common use cases

Use case	When to use	Notes
Multi-year platform modernization	Transformation spans several budget cycles	Break into transition architectures, not one giant leap
Post-merger integration	Two organizations need one target state	Baseline captures both starting points; gap analysis drives the plan
Annual planning cycle	Revisiting priorities	Roadmap is reviewed and adjusted, not fixed once and forgotten

Advanced details

• Gap analysis should compare capability-by-capability, not system-by-system, to stay technology-agnostic (see Business Capability Mapping).
• The current-state baseline is typically sourced from the application portfolio inventory (see Application Portfolio Management).
• Roadmap changes go through the same Architecture Governance process as other architecture decisions.
• The Technology BDAT domain of a TOM often converges on shared platform patterns rather than bespoke choices per team — e.g. a standard landing zone, a default compute/database/region topology — see Reference Architectures & Standards for how those defaults get published and reused.

Quick reference

Term	Meaning
Baseline architecture	How things work today
Target Operating Model (TOM)	How the organization should look once transformation is complete
Transition architecture	An intermediate, realistic state between baseline and target
Roadmap	The sequenced, fundable plan of projects that gets from baseline to target
Gap analysis	Capability-by-capability comparison of baseline vs. target

Troubleshooting

Symptom	Likely cause	Fix
Target state never arrives	No transition architectures or roadmap, just a vision	Define intermediate states and sequence them into a fundable roadmap
Transformation initiatives compete for the same budget	No agreed sequencing	Prioritize and sequence through the roadmap, reviewed on a regular cadence
Roadmap is followed but the gap doesn’t close	Baseline or target wasn’t defined across all four BDAT domains	Re-run gap analysis covering Business, Data, Application, and Technology

Check your understanding

• Why is a target-state vision without a roadmap described as “just a wish”?
• For a transformation you’re familiar with, what would one realistic transition architecture look like between today and the target state?

Related pages

Part of Introduction to Enterprise Architecture. See Application Portfolio Management for how the current-state application inventory feeds gap analysis, Architecture Governance for how roadmap changes get approved, and the Glossary for term definitions.