Module 9 · Practice
Roadmaps and portfolio management
Current state, target state, transition architectures, application rationalization, and making the business case.
By the end of this module you should be able to
- Decide how much current-state modeling is enough
- Produce a capability-based architecture roadmap with transition states
- Run an application portfolio assessment using TIME
- Frame build vs buy vs SaaS decisions using pace layers
- Build a simple business case with TCO and cost of delay
Builds skills: Translating strategy into change , Financial literacy , Roadmapping & transition planning , Application portfolio management , Cloud & platforms
From strategy to a plan people fund
Modules 4–6 gave you the pieces: capabilities, target states, gaps, principles. This module is about turning them into a roadmap that leaders actually use in planning and funding, and about managing the portfolio of applications and technology that the roadmap changes.
This is where EA becomes visible to the CFO, and it’s often where an EA function earns or loses its seat at the table.
Current state: how much is enough?
A complete current-state model is a trap. It takes months, it’s out of date when it’s finished, and nobody makes decisions with it.
Model just enough current state to support the decisions in front of you:
- Always: an application inventory with owners (see below) and a level-2 capability map
- For the initiative in scope: the applications, data flows, and integrations it touches, in enough detail to find the gaps
- Not yet: everything else
Target state at the right altitude
A target state should be specific enough to drive decisions and vague enough to survive contact with reality. Describe it in terms of:
- Capabilities: which ones change, and to what level of maturity
- Principles: which ones the target embodies, e.g. “one customer, one identity”
- Key structural choices: single customer master, EU data store, one notification platform
- Not detailed designs. Those belong to solution architects when the work starts.
Roadmaps
Transition architectures
The journey from baseline to target is almost never one step. Transition architectures (or plateaus) are intermediate states. A good one is:
- Stable: the organization could stay there for a while
- Valuable on its own: if funding stopped, you’d be better off than at the baseline
- Coherent: not half a migration
Capability-based vs project-based roadmaps
| Project-based | Capability-based |
|---|---|
| “Q2: Notification consolidation project” | “Tenant Communication: from three inconsistent channels to one consent-aware platform by Q3” |
| Easy to build from existing plans | Takes more thought |
| Breaks when projects are reshuffled | Survives reprioritization; shows why |
| Speaks to delivery teams | Speaks to executives and delivery teams |
The best roadmaps show capabilities as the backbone, with work packages beneath them and transition states as milestones.
Now / next / later
For a scaling organization, precise dates more than two quarters out are fiction. A now / next / later structure is more honest:
- Now (this quarter and next): committed, resourced, specific
- Next (2–4 quarters): planned and sequenced; dates are targets
- Later (beyond that): direction and intent; no dates
Keeping it alive
A roadmap that isn’t updated dies within two quarters. Tie it to the organization’s existing rhythm:
- Review it as an input to quarterly planning, not separately
- Update it after significant ADRs and Phase H changes
- Keep one version. Publish a date on it so people know if it’s current.
Application portfolio management
Application portfolio management (APM) means keeping an inventory of applications with enough information to make rationalization decisions.
The minimum useful inventory
| Field | Why |
|---|---|
| Name and description | Obviously |
| Business owner and technical owner | Someone has to make decisions about it |
| Capabilities supported | Links it to the capability map and reveals duplication |
| Annual cost | Licenses, hosting, and people (roughly) |
| Business value / functional fit | Scored 1–5 by the business owner |
| Technical health | Scored 1–5 by the technical owner: maintainability, security, supportability |
| Lifecycle / end of support | Upcoming vendor or platform deadlines |
| Data classification | Does it hold personal or regulated data? |
Start in a spreadsheet. Move to an EA tool when people other than you need to query it regularly.
TIME
Gartner’s TIME model classifies applications on two axes, business value and technical quality:
| Low technical quality | High technical quality | |
|---|---|---|
| High business value | Migrate: valuable but on a poor platform; move or rebuild it | Invest: strategic; keep improving it |
| Low business value | Eliminate: retire it, consolidate onto something else | Tolerate: fine as is; minimize spend |
TIME gives you a shared language for portfolio conversations. “FixIt Pro’s auth is in Eliminate” is a much easier discussion than “we should get rid of FixIt Pro’s auth.”
Pace layers
Gartner’s pace-layered model classifies applications by how fast they need to change:
| Layer | Characteristics | Typical approach |
|---|---|---|
| Systems of Record | Stable, standardized, regulated (finance, HR, core ledger) | Buy or SaaS; change slowly and carefully |
| Systems of Differentiation | What makes you different from competitors | Configure or build; moderate change |
| Systems of Innovation | New ideas, experiments | Build fast, expect to throw away |
Pace layers are especially useful for build vs buy decisions and for setting different governance for different layers.
Investment decisions
Build vs buy vs SaaS
| Question | Leans build | Leans buy / SaaS |
|---|---|---|
| Does it differentiate us? | Yes | No, it’s commodity |
| Do mature products exist? | No | Yes |
| How fast does it need to change? | Fast and in ways only we know | At market pace |
| Do we have the skills to run it? | Yes, and want them | No, or not a good use of them |
| Data residency / regulatory constraints | Hard to meet with vendors | Vendors meet them |
Total cost of ownership
When comparing options, count the total cost of ownership over 3–5 years, not just the license or build cost:
- Licenses / subscription
- Build and integration effort
- Hosting and infrastructure
- Ongoing maintenance, support, and on-call
- Training and change management
- Exit or decommissioning cost
Building usually looks cheaper than buying because the run costs are hidden in team capacity. Make them visible.
CapEx vs OpEx
Finance teams care how costs are classified. Capital expenditure (CapEx) is often depreciated over several years. Operating expenditure (OpEx) hits the current year. Cloud and SaaS have shifted most technology spend to OpEx. Ask your CFO how they want options presented; it can change which option looks better.
Cost of delay
Cost of delay asks: what does it cost us for each month this isn’t done? It’s often more persuasive than ROI because it makes the trade-off between competing initiatives explicit. The idea is central to Don Reinertsen’s work on product development flow. Dividing cost of delay by duration (CD3, a technique developed by Joshua Arnold) gives a simple prioritization score.
Technical debt at portfolio level
At enterprise scale, technical debt shows up as Migrate and Eliminate applications that never get migrated or eliminated, because no single team owns the problem. EA’s job is to make that debt visible in the portfolio (cost, risk, what it blocks) so it can be prioritized against features with real numbers.
At Quillfeather
The portfolio
Building the inventory took three weeks and turned up 127 applications, including 74 SaaS subscriptions. Nineteen were found because finance flagged unexplained card payments. TIME results for the most contentious ones:
| Application | Value | Tech quality | TIME |
|---|---|---|---|
| Core platform | High | Medium | Invest |
| PayNest | High | High | Invest |
| FixIt Pro scheduling | High | Medium | Invest |
| FixIt Pro auth | Low | Low | Eliminate |
| Core notification service | Medium | Low | Migrate |
| PayNest notification service | Low | Medium | Eliminate |
| FixIt Pro notification service | Low | Low | Eliminate |
| Legacy reporting module | Medium | Low | Migrate |
The roadmap
| Now (next 2 quarters) | Next (2–4 quarters) | Later | |
|---|---|---|---|
| Identity & Access | Managed identity provider live in EU; core platform migrated | FixIt Pro migrated; dispensation closed | Partner / API identity |
| Communications | Notification platform built; consent from customer master | PayNest and FixIt Pro notifications retired | Multilingual templates for further markets |
| Payments & Collections | SEPA Direct Debit in PayNest | Local payment methods (NL, DE) | Instant payments |
| Customer Management | EU customer data store | Single customer master across products | |
| Transition state | T1 “Launch-ready” | T2 “One platform” |
The business case
For the notification consolidation, you presented the CFO with:
- Run cost today: three services, roughly 1.5 engineers’ worth of maintenance between them, plus three SMS/email vendor contracts.
- Run cost after: one service, one vendor contract, about 0.5 engineers.
- Build cost: one team for two quarters.
- Cost of delay: EU launch can’t proceed without GDPR-compliant consent handling, so every month of delay pushes back EU revenue. That made it a T1 must-have, not a nice-to-have.
The cost-of-delay framing is what got it funded ahead of two feature requests.
Reflection
- Could you produce a list of every application your organization pays for within a week? If not, what’s in the way?
- Which applications would you place in Eliminate today? Why haven’t they been eliminated?
- Does your organization’s roadmap show capabilities or projects? What would change if it showed capabilities?