Quick Navigation
- Start here — Why prioritisation is an architecture concern
- Building a business case
- Value and risk
- Portfolio prioritisation frameworks
- Sequencing
- Architecture's role in investment
- Common mistakes
- FinOps as investment input
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
Not every good idea can be funded. Budgets are finite, teams are finite, and attention is finite. I've seen investment decisions made on political power, whoever shouts loudest, or whatever was last discussed. And I've seen them made on value, risk, and dependency. The difference is whether architecture is at the table.
Investment prioritisation connects architecture to financial decisions and business outcomes. Business cases must connect investment to outcomes leadership cares about — not just to technical goals. Sequencing matters because some investments unlock others, and wrong order wastes money.
Architecture provides the dependency map that makes sequencing defensible. Without architecture input, investment decisions are guesswork. With it, they're structural.
Keep it in mind.
1. Why prioritisation is an architecture concern — Structure determines what can be done when
Investment prioritisation is often done by finance or product — without architecture input. The result is sequencing that ignores dependencies: teams are funded to build features on infrastructure that doesn't exist yet, or platforms are built for capabilities that no team is ready to use.
Architecture reveals the dependency structure that determines what must come first. Without this insight, prioritisation is guesswork. With it, sequencing is defensible.
flowchart TD
ARCH["🏗️ Architecture Knowledge\nDependencies · Constraints\nFoundation vs Feature"] --> INVEST["💰 Investment Decision\nWhat to fund\nIn what order"]
INVEST --> VALUE["✅ Value Delivered\nRight sequence\nNo wasted investment"]
NO_ARCH["❌ Without Architecture"] --> RANDOM["Random Sequence\nPolitics · Recency\nLoudest voice"]
RANDOM --> WASTE["💸 Wasted Investment\nFeatures built on\nnon-existent infrastructure"]
What architecture adds to prioritisation: Dependency knowledge — what must exist before what. Foundation identification — which investments are platforms others build on. Risk insight — which choices are high-reversal-cost and need early commitment. Constraint mapping — which initiatives block or enable others.
Architecture adds dependency insight to prioritisation — without it, sequencing is guesswork.
Try it yourself — The dependency map
Think of three initiatives competing for funding. For each one:
| Initiative | What must exist before this? | What does this unlock? |
|---|---|---|
| e.g. Build API gateway | CI/CD platform, observability | 5 downstream services can deploy independently |
If you can't answer the first column, the initiative isn't ready to fund. If you can't answer the second, it might not be worth funding.
2. Building a business case — Connecting investment to outcomes leadership cares about
Architecture teams struggle to get investment approved because they present technical justifications — "we need to refactor the monolith" or "we need to adopt Kafka." Leadership doesn't fund refactoring. They fund outcomes.
The business case must translate architecture investment into business language — outcomes, risk, and return.
flowchart TD
TECH["🔧 Technical Need\n'Refactor the monolith'"] --> TRANSLATE["🔄 Translate\nInto business language"]
TRANSLATE --> BIZ["📊 Business Case\n'Reduce feature delivery\ntime by 40%\nSaves £1.2M annually\nPayback: 8 months'"]
BIZ --> APPROVE["✅ Approved\nLeadership understands\nthe outcome and return"]
The business case template:
Investment — what we need: time, money, people. Outcome — business impact: revenue, speed, risk, cost. Current cost — what the problem costs today — quantified. Projected cost — what it will cost if not addressed — quantified. Return — ROI: payback period, ongoing value. Risk — what could go wrong — and mitigation. Request — what we need from leadership: approve, fund, decide.
The translation guide:
| Technical need | Business case translation |
|---|---|
| "Refactor the monolith" | "Reduce feature delivery from 6 weeks to 2 weeks — 3x velocity improvement" |
| "Adopt event-driven integration" | "Decouple services to reduce cross-team blocking — 40% fewer dependencies" |
| "Build a data platform" | "Enable real-time analytics that reduce customer churn by 15%" |
| "Migrate to cloud" | "Reduce infrastructure cost by 30% and improve deployment frequency by 5x" |
| "Pay down technical debt" | "Recover 30% of engineering capacity currently spent on rework — equivalent to £X" |
Leadership funds outcomes, not refactoring — translate every architecture investment into business impact.
Try it yourself — The translation exercise
Take a technical investment your team needs. Translate it:
| Technical need | Your business case translation |
|---|---|
| Outcome, current cost, projected cost, return |
If your translation doesn't mention money, speed, or risk — it's not a business case. It's a technical justification.
3. Value and risk — The two dimensions every investment must address
Investment decisions are often made on value alone — "this will save us money" or "this will speed up delivery." But value without risk assessment is dangerous. A high-value initiative with catastrophic risk needs different treatment than a high-value initiative with minimal risk.
Every investment must be evaluated on two dimensions — value and risk.
flowchart TD
INV["💰 Investment"] --> VALUE_D["📊 Value\nWhat does it deliver?\nRevenue · Speed\nCost · Risk reduction"]
INV --> RISK_D["⚠️ Risk\nWhat could go wrong?\nTechnical · Operational\nFinancial · Strategic"]
VALUE_D --> SCORE["🎯 Score\nQuantify both\nNot just stated"]
RISK_D --> SCORE
SCORE --> DECIDE["Decide\nWith full information"]
The value/risk matrix:
| Low risk | Medium risk | High risk | |
|---|---|---|---|
| High value | Fund immediately | Fund with mitigation | Fund with pilot first |
| Medium value | Fund if capacity allows | Evaluate carefully | Probably defer |
| Low value | Fund only if trivial | Defer | Reject |
Quantifying value: Revenue — additional revenue enabled. Cost reduction — direct savings. Speed — velocity improvement. Risk reduction — probability × impact.
Quantifying risk: Technical — probability of failure × cost of failure. Operational — impact on running systems. Financial — cost overrun probability. Strategic — opportunity cost.
Every investment needs both value and risk quantified — "high value" without numbers is an opinion, not a case.
Try it yourself — The value-risk scorecard
Take three competing initiatives. Score each one:
| Initiative | Value (quantified) | Risk (quantified) | Decision |
|---|---|---|---|
| Fund, mitigate, pilot, defer, reject | |||
If you can't quantify either column, you don't have a case — you have a hunch.
4. Portfolio prioritisation frameworks — How to compare dissimilar investments
Comparing a platform investment with a feature investment with a debt-reduction investment is like comparing apples, oranges, and bananas. Without a common framework, the comparison becomes political — whoever argues best wins.
Prioritisation frameworks create a common scoring mechanism that makes comparison defensible.
flowchart TD
A["🍎 Platform\nInvestment"] --> SCORE["🧮 Score\nValue × Urgency\n× Strategic Fit\n÷ Cost"]
B["🍊 Feature\nInvestment"] --> SCORE
C["🍌 Debt\nReduction"] --> SCORE
SCORE --> RANK["📊 Ranked List\nDefensible order\nNot political"]
The weighted scoring model:
| Criterion | Weight | Score 1-5 | Weighted |
|---|---|---|---|
| Business value | 30% | ? | ? × 0.30 |
| Strategic alignment | 25% | ? | ? × 0.25 |
| Urgency | 20% | ? | ? × 0.20 |
| Dependency impact | 15% | ? | ? × 0.15 |
| Cost (inverse) | 10% | ? | ? × 0.10 |
Frameworks compared: Weighted scoring — score each initiative on multiple criteria; weight and sum. Best for comparing dissimilar initiatives. Value vs effort — plot on 2x2 grid; prioritise high-value, low-effort. Best for quick prioritisation. WSJF (Weighted Shortest Job First) — value ÷ duration; prioritise highest ratio. Best for agile portfolio management. Cost of delay — quantify the weekly cost of not doing each initiative. Best for making urgency visible. Dependency-first — prioritise by what others depend on. Best for architecture-heavy portfolios.
Use a common scoring framework to compare dissimilar investments — without it, prioritisation is political.
Try it yourself — The scoring test
Take three initiatives. Score them on the weighted model:
| Initiative | Value (×0.30) | Alignment (×0.25) | Urgency (×0.20) | Dependency (×0.15) | Cost (×0.10) | Total |
|---|---|---|---|---|---|---|
The highest score wins. If you disagree with the result, your weights are wrong — not the framework.
5. Sequencing — Which initiatives must come first and why
Even with a ranked list of investments, the order matters. Building a feature before its platform is ready wastes effort. Building a platform before anyone needs it wastes investment. Sequencing is the discipline of ordering investments by dependency and readiness.
Architecture provides the dependency map that makes sequencing defensible.
flowchart TD
PLATFORM["🏗️ Platform\nMust come first\nFoundation for everything"] --> INTEG["🔗 Integration\nDepends on platform\nEnables service communication"]
INTEG --> SERVICES["⚙️ Services\nDepend on integration\nDeliver business features"]
SERVICES --> FEATURES["✨ Features\nDepend on services\nDeliver customer value"]
Sequencing principles:
| Principle | What it means | Example |
|---|---|---|
| Dependencies first | What must exist before what | Platform before services |
| Foundations before features | Shared capabilities before specific capabilities | API gateway before API consumers |
| Risk first | High-risk items early — fail fast | Pilot the hard technology first |
| Quick wins early | Build credibility with early value | Unblock a stuck team first |
The sequencing algorithm: map dependencies — what depends on what? Identify layers — foundation → platform → service → feature. Assess readiness — skills, platform, governance, operations. Order by layer, then by readiness, then by value.
Sequence by dependency and readiness — not by value ranking alone. Wrong order wastes money.
Try it yourself — The sequencing map
Take your investment portfolio. Map the layers:
| Layer | Initiatives | Ready? |
|---|---|---|
| Foundation | CI/CD, observability, data platform | |
| Integration | API gateway, event broker | |
| Services | Domain services, capabilities | |
| Features | Customer-facing features |
If you're funding features before foundations are ready, you're sequencing wrong.
6. The role of architecture in investment decisions — Dependency thinking applied
Investment decisions without architecture input ignore structural dependencies — leading to initiatives that can't land because their prerequisites aren't funded, or duplicate investments that could share a platform.
Architecture contributes three things to investment decisions.
flowchart TD
ARCH["🏗️ Architecture"] --> DEP["🔗 Dependency Map\nWhat must exist before what"]
ARCH --> SHARED["🤝 Shared Capabilities\nWhere the portfolio can consolidate"]
ARCH --> FOUNDATION["🧱 Foundation Identification\nWhat is the platform\neverything builds on"]
DEP --> INVEST["💰 Defensible Investment Decisions"]
SHARED --> INVEST
FOUNDATION --> INVEST
Architecture's contribution to each investment phase:
| Phase | Without architecture | With architecture |
|---|---|---|
| Identification | Teams propose what they want | Architecture identifies what the portfolio needs |
| Evaluation | Value assessed in isolation | Dependencies and shared capability considered |
| Sequencing | Political or random | Dependency-driven and readiness-based |
| Execution | Teams discover blockers late | Prerequisites identified and funded first |
Architecture adds dependency, shared capability, and foundation insight to investment — making prioritisation structural, not political.
Try it yourself — The architecture gap
What happened the last time an investment initiative hit a blocker?
| Question | Your answer |
|---|---|
| Was the blocker a dependency that wasn't funded? | |
| Could architecture have identified it beforehand? | |
| How much did the blocker cost in delay? |
If the answer to the first two is "yes," architecture wasn't at the investment table. It should have been.
7. Common investment mistakes — What organisations get wrong and what it costs
Investment decisions fail in predictable ways. Knowing the patterns helps prevent them.
The seven most common investment mistakes:
| Mistake | What it looks like | Cost | Fix |
|---|---|---|---|
| No dependency sequencing | Features funded before their platform | Wasted effort — features can't land | Map dependencies; fund foundations first |
| Value without risk | High-value initiatives funded without risk assessment | Surprises when risks materialise | Quantify both dimensions |
| Political prioritisation | Loudest voice gets funded | Sub-optimal portfolio; resentment | Use scoring frameworks |
| Duplicate investment | 3 teams build the same capability independently | 3x cost, 3x maintenance | Identify shared capabilities |
| Ignoring debt | Only new features funded; debt never addressed | Velocity declines; eventually blocked | Allocate 20% to debt reduction |
| No TCO | Build cost assessed; run cost ignored | Surprises in operational budget | Include run, change, and retire costs |
| No kill switch | Failed investments continue because nobody stops them | Ongoing waste | Review checkpoints; kill criteria |
The kill criteria — when to stop an investment: No adoption — is anyone using this? If no adoption after pilot, kill. Cost overrun — is it 50%+ over budget? Re-evaluate or kill. Strategic shift — does this still align with strategy? If strategy changed, reassess. Better alternative — has a better option emerged? Evaluate switch. Dependency failure — did a prerequisite fail? Re-sequence or kill.
Investment mistakes are predictable and preventable — dependency sequencing, value-risk, and TCO are the three most common gaps.
Try it yourself — The mistake inventory
Which of these mistakes exist in your investment portfolio?
| Mistake | Evidence | Cost |
|---|---|---|
Pick one. What would it take to fix it?
8. FinOps as an investment input — Real-time operational cost data grounding decisions
Investment cases are often built with estimated costs — projected infrastructure spend, assumed operational cost. In a cloud-native world, real-time operational cost data must ground these estimates. Business cases built without unit economics and TCO are theoretical at best and misleading at worst.
FinOps provides the real cost data that makes investment cases credible.
flowchart TD
BIZ_CASE["📋 Business Case\nProjected costs\nand returns"] --> FINOPS["💰 FinOps Data\nActual costs\nUnit economics\nTrends"]
FINOPS --> GROUND["🎯 Grounded Case\nReal data replaces\nassumptions"]
GROUND --> CREDIBLE["✅ Credible Case\nLeadership trusts\nthe numbers"]
FinOps inputs to investment: Cost per transaction — unit economics: is the architecture efficient? Cost trend — is cost growing faster than revenue? Waste identification — what are we paying for but not using? Cost by capability — which capabilities are expensive to run? Inference cost — for AI — what does each prediction cost?
The unit economics framework: Total Infrastructure Cost / Number of Transactions (or Users, or Events). If the target is lower than current, the gap is your architecture intervention opportunity.
FinOps provides real cost data that grounds investment cases — projected costs without actuals are guesswork.
Try it yourself — The unit economics check
What's your cost per transaction, per user, per event?
| Metric | Current | Target | Gap |
|---|---|---|---|
| Cost per transaction | |||
| Cost per user | |||
| Monthly cloud cost |
If you can't answer the first column, you don't have a grounded investment case. You have a projection.
Putting it all together
Here's the complete picture in one diagram. This is the mental model worth internalising.
flowchart TD
IDEAS["💡 Investment Ideas\nMore than can be funded"] --> CASE["📋 Business Case\nOutcome · Value · Risk\nTCO · Return"]
CASE --> SCORE["🧮 Score\nCommon framework\nNot political"]
SCORE --> SEQUENCE["🔗 Sequence\nDependency-driven\nFoundation first"]
SEQUENCE --> FUND["💰 Fund\nWith kill criteria\nand review checkpoints"]
FUND --> VALUE["✅ Value Delivered\nRight investments\nIn the right order"]
The foundation:
Architecture provides the dependency map that makes investment sequencing defensible — without architecture input, prioritisation is political. With it, sequencing is structural. Business cases must connect investment to outcomes leadership cares about — revenue, speed, cost, risk. "Refactoring the monolith" isn't an outcome. "3x delivery velocity" is. Sequence by dependency, not just by value. Building features before their platform is ready wastes effort. Foundations first, then capabilities, then features. Prioritise by value. Sequence by dependency. Justify by business outcome.
Cheat Sheet — All the key terms
| Concept | One-Line Memory | Key Action |
|---|---|---|
| Architecture's role | Dependency insight for sequencing | Map dependencies before prioritising |
| Business case | Connect to outcomes, not technical goals | Translate every investment into business impact |
| Value and risk | Both must be quantified | Score on two dimensions, not one |
| Prioritisation frameworks | Common scoring for dissimilar investments | Weighted scoring or WSJF |
| Sequencing | Dependency-driven, not value-driven | Foundations before features |
| Common mistakes | Predictable and preventable | Dependencies, value-risk, TCO |
| FinOps | Real cost data grounds investment cases | Unit economics, cost trends, waste |
How to know if this landed
You'll know this has landed when someone stops presenting technical justifications and starts presenting business outcomes. Architecture provides dependency input to every investment decision. Business cases connect to business outcomes — not just technical goals. Both value and risk are quantified for every significant investment. A common scoring framework is used to compare dissimilar investments. Sequencing is dependency-driven — foundations funded before features. FinOps data grounds investment cases — real unit economics, not estimates. And kill criteria exist for every investment — failed initiatives are stopped.
What changes when the mental model clicks
I've run this session with teams where 45 investment proposals competed for budget that could fund 12 — no dependency sequencing, business cases were technical, prioritisation was political. The gap at the start is usually not about understanding investment — it's about connecting architecture dependency knowledge to financial decisions.
What changes after this session:
Teams stop presenting "we need to refactor" and start presenting "3x delivery velocity, £1.2M annual saving, 8-month payback." The dependency mapping exercise — "what must exist before what?" — is always the moment things click. People stop treating prioritisation as political and start treating it as structural. Their results get better. They stop funding features before platforms when the real problem was that nobody mapped the dependencies.
The business case translation exercise tends to immediately change how teams pitch investment. They start connecting technical needs to business outcomes. Their approval rates go up. They stop getting rejected when the real problem was that leadership couldn't see the outcome.
Book a Workshop
Ready to make investment prioritisation structural instead of political?
or
1-day workshop includes dependency mapping exercise — map your investment portfolio dependencies, business case writing — translate your real architecture investments into business language, scoring framework creation — build a weighted model for your portfolio, sequencing workshop — order your investments by dependency and readiness, kill criteria design — define when and how to stop failing investments, FinOps integration — connect real cost data to investment decisions, and investment prioritisation model + business case guide (including TCO and unit economics) + sequencing criteria.