Quick Navigation
- Start here — From systems thinking to portfolio thinking
- What the portfolio contains
- Dependency mapping
- Impact on sequencing
- Shared capabilities
- Portfolio health
- Making portfolio-aware decisions
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
Individual systems don't exist in isolation. They're part of a portfolio — a connected collection of systems, programmes, platforms, and investments. Decisions made about one system ripple across others. An investment in one programme constrains what's possible in another. A shared capability built twice is waste. A dependency missed is an outage waiting to happen. I've seen perfectly designed systems that couldn't integrate with the portfolio — and "suboptimal" systems that fit the portfolio constraints and were the right choice.
Portfolio thinking means seeing all systems, initiatives, and investments as a connected whole — understanding how they depend on each other and how decisions in one place ripple across others.
Most architects are trained to think about one system at a time. Enterprise and strategy architects must think about the portfolio — the system of systems. This shift from single-system to portfolio thinking is what separates solution architecture from enterprise architecture.
Keep it in mind.
1. From systems thinking to portfolio thinking — Expanding the lens
Architects who are excellent at designing individual systems often struggle when asked to think about the portfolio. The skills are related but different.
Systems thinking asks "how does this system work?" Portfolio thinking asks "how do all systems work together — and what happens when one changes?"
The shift:
| Systems thinking | Portfolio thinking |
|---|---|
| How does this system work? | How do all systems connect? |
| What are the components? | What are the dependencies? |
| How do we build this? | What order do we build things in? |
| What is the best design? | What is the best investment? |
| Who owns this system? | Who is affected when this system changes? |
flowchart TD
SINGLE["🔧 Systems Thinking\nHow does this work?"]
SINGLE --> S1["Components\nStructure\nDesign patterns"]
SINGLE --> S2["Single system\nSingle team\nSingle context"]
PORTFOLIO["🌐 Portfolio Thinking\nHow does everything connect?"]
PORTFOLIO --> P1["Dependencies\nSequencing\nShared capabilities"]
PORTFOLIO --> P2["Multiple systems\nMultiple teams\nCross-cutting concerns"]
S1 --> SHIFT["The Shift\nFrom one system\nto the system of systems"]
S2 --> SHIFT
P1 --> SHIFT
P2 --> SHIFT
Why this matters: A perfectly designed system that can't integrate with the portfolio is a failure. A "suboptimal" system that fits the portfolio constraints may be the right choice. The best single-system decision can be the worst portfolio decision. Portfolio thinking is what the EA and TS roles require — it's the difference between architect and enterprise architect.
The portfolio mindset: Interconnected — every system is connected to others — nothing is truly independent. Constrained — resources are finite — investing in one area means not investing in another. Sequenced — some things must happen before others — dependencies create ordering. Shared — capabilities, platforms, and services are shared — duplication is waste. Rippled — changes propagate — a change in one system affects others.
Portfolio thinking = seeing how everything connects, not just how one thing works.
Try it yourself — The lens check
Think of your last architecture decision. Did you consider:
| Question | Did you consider it? |
|---|---|
| How does this connect to other systems? | |
| What dependencies does this create? | |
| Who else is affected when this changes? | |
| Does this duplicate something that already exists? |
If you answered "no" to two or more, you were thinking about one system, not the portfolio.
2. What the portfolio contains — Systems, programmes, platforms, and investments
"Portfolio" can mean different things. Without scope, portfolio thinking stays abstract.
The portfolio contains four types of assets — each with different characteristics and management needs:
| Type | What it is | Example |
|---|---|---|
| Systems / Applications | The software the organisation runs | CRM, ERP, custom services |
| Platforms | Shared foundations that multiple teams consume | Cloud landing zone, integration platform, data platform |
| Programmes / Initiatives | Time-bounded efforts to change the portfolio | Cloud migration, digital transformation, AI programme |
| Investments | Financial commitments to technology | Licensing, development, infrastructure, skills |
flowchart TD
PORT["📐 The Portfolio"] --> SYS["📱 Systems\nWhat the org runs\nApplications, services, tools"]
PORT --> PLAT["🏗️ Platforms\nShared foundations\nCloud, integration, data"]
PORT --> PROG["📋 Programmes\nChange efforts\nMigrations, transformations"]
PORT --> INV["💰 Investments\nFinancial commitments\nLicences, dev, infra, skills"]
SYS --> MANAGE["Manage for health,\nlifecycle, and rationalisation"]
PLAT --> MANAGE2["Manage for adoption,\nevolution, and shared value"]
PROG --> MANAGE3["Manage for sequencing,\ndependencies, and delivery"]
INV --> MANAGE4["Manage for return,\nprioritisation, and alignment"]
What portfolio visibility reveals: How many systems we run — baseline for rationalisation. How much we spend on technology — foundation for investment decisions. What programmes are active — coordination and dependency management. What platforms are shared — shared capability identification. What is connected to what — dependency and risk management.
The portfolio register:
| Asset | Type | Owner | Health | Cost | Capabilities Served | Dependencies |
|---|---|---|---|---|---|---|
| Customer Portal | System | Team Alpha | Good | £200K | Customer Onboarding, Support | CRM, Auth, Payment |
| CRM | System | Team Beta | Ageing | £500K | Customer Onboarding, Support, Retention | Portal, Data Warehouse |
| Cloud Landing Zone | Platform | Platform Team | Good | £1.2M | Infrastructure for all | All systems |
| Integration Platform | Platform | Platform Team | Good | £400K | Integration for all | 30+ systems |
| Cloud Migration | Programme | Programme Office | Active | £3M | — | All systems |
| AI Programme | Programme | Data Team | Active | £1.5M | — | Data Platform, CRM |
Portfolio health indicators: System count — total applications. Depends on org size. Technology spend — annual technology cost. Tracked against budget. Active programmes — number of change initiatives. Shouldn't exceed delivery capacity. Platform adoption — teams using shared platforms. >70%. Dependency density — average dependencies per system. Lower is more manageable.
The portfolio = systems + platforms + programmes + investments — each type needs different management.
Try it yourself — The portfolio register
Can you describe your portfolio?
| Type | How many? | Can you list them? |
|---|---|---|
| Systems | ||
| Platforms | ||
| Active programmes | ||
| Major investments |
If you can't answer the second column, you don't have portfolio visibility.
3. Dependency mapping — Understanding what relies on what
Dependencies between systems create constraints on sequencing and change. If you don't know what depends on what, you can't plan safely.
Dependency mapping makes the connections between systems visible — so that changes can be planned, risks can be managed, and sequencing can be defensible.
Types of dependencies:
| Type | Example |
|---|---|
| Runtime | System A calls System B's API at runtime |
| Data | System A reads data that System B writes |
| Platform | System A and B both run on the same Kubernetes cluster |
| Deployment | System A must be deployed before System B can start |
| Team | Team A needs Team B to deliver a feature before they can proceed |
| Temporal | System A must be running before the data migration starts |
flowchart TD
DEP["Dependency Types"] --> RUN["⚡ Runtime\nSystem A calls System B"]
DEP --> DATA["📊 Data\nSystem A reads what B writes"]
DEP --> PLAT["🏗️ Platform\nBoth share infrastructure"]
DEP --> DEPLOY["📦 Deployment\nA must deploy before B"]
DEP --> TEAM["👥 Team\nTeam A needs Team B's output"]
DEP --> TEMP["⏰ Temporal\nA must be running\nbefore migration starts"]
RUN --> IMPACT["Impact: Changes to B\nbreak A at runtime"]
DATA --> IMPACT2["Impact: Schema changes\nbreak downstream consumers"]
PLAT --> IMPACT3["Impact: Platform changes\naffect all hosted systems"]
DEPLOY --> IMPACT4["Impact: Wrong order\ndeployments fail"]
TEAM --> IMPACT5["Impact: Team B's delay\ndelays Team A"]
TEMP --> IMPACT6["Impact: Wrong sequence\ndata loss or corruption"]
What dependency mapping enables:
| Use case | How dependencies help |
|---|---|
| Change planning | "What do we need to update when we change this?" |
| Risk management | "What's the blast radius if this fails?" |
| Sequencing | "What must happen before what?" |
| Rationalisation | "Can we retire this system? Who depends on it?" |
| Migration | "What needs to be re-pointed when we move this?" |
Dependency discovery methods: Team workshops — teams describe their dependencies. Medium effort. Code analysis — import chains, API calls, config files. Low-medium effort. Runtime tracing — real-time call graphs (Jaeger, Zipkin). Low effort. Architecture documentation — designed dependencies. Medium effort. Data flow analysis — data dependencies — who reads what. Medium effort.
Dependency mapping answers: "What relies on what?" — without it, every change is a risk.
Try it yourself — The dependency map
Pick your most critical system. What depends on it?
| Dependent system | Type of dependency | What happens if it breaks? |
|---|---|---|
If you can't answer this, you're one change away from an outage.
4. The impact of dependencies on sequencing — What must happen before what
Dependencies create ordering constraints. If the auth service must be built before the customer portal, you can't build the portal first — even if the portal is the higher priority.
Dependency-aware sequencing is the foundation of credible roadmaps and delivery plans. Without it, programmes collide, teams are blocked, and timelines slip.
The principle: Priority says: "Build the customer portal first — highest business value." Dependencies say: "You can't — auth service and CRM integration come first." Reality says: "The dependency-aware sequence is: Auth → CRM Integration → Portal."
flowchart LR
P1["🎯 Priority: Portal first\n(Highest business value)"]
P2["🔗 Dependencies: Auth first\n(Required by portal)"]
P3["📊 Reality: Auth → CRM → Portal\n(Dependency-aware sequence)"]
P1 --> CONFLICT["Conflict\nPriority vs Dependencies"]
P2 --> CONFLICT
CONFLICT --> RESOLVE["Resolve\nDependencies win —\nyou can't build what you can't connect to"]
RESOLVE --> SEQUENCE["✅ Sequence:\n1. Auth service\n2. CRM integration\n3. Customer portal"]
Sequencing rules: Dependencies first — you can't consume what doesn't exist. Shared platforms early — many systems depend on them — build the foundation. High-risk early — fail fast — discover problems before they compound. Quick wins alongside — maintain momentum — don't make teams wait for big dependencies. Retire last — only decommission after all dependents have migrated.
The sequencing algorithm: All initiatives → map dependencies (what depends on what?) → topological sort (order by dependency chain) → layer by layer (Layer 0: no dependencies, Layer 1: depends on Layer 0, Layer 2: depends on Layer 1) → apply priority (within each layer, prioritise by business value) → apply capacity (can we actually deliver this many things in parallel?) → sequenced plan (dependency-aware, priority-informed, capacity-realistic).
Example — layered sequencing: Layer 0 — cloud landing zone, auth service, data platform. No dependencies — foundation. Layer 1 — CRM integration, API gateway, notification service. Depend on Layer 0. Layer 2 — customer portal, mobile app, reporting. Depend on Layer 1. Layer 3 — legacy decommission, AI features. Depend on Layer 2.
Even with dependency-aware sequencing, organisations can't do everything at once. Capacity — team availability, budget, skills — limits how many initiatives can run in parallel. The sequenced plan must be realistic about delivery capacity.
Dependencies determine sequence — priority adjusts to dependencies, not the other way around.
Try it yourself — The sequencing check
Take your current programme. Is it sequenced by priority or by dependencies?
| Initiative | Business priority | Dependencies | Actual sequence |
|---|---|---|---|
If priority and dependencies conflict, dependencies win. Always.
5. Shared capabilities — Identifying where the portfolio can consolidate
When multiple teams independently build the same capability — authentication, logging, notifications, data pipelines — the portfolio accumulates duplication.
Portfolio thinking reveals shared capabilities — things that multiple systems or teams need, and that should be built once and shared.
Common shared capabilities:
| Capability | Why it should be shared |
|---|---|
| Authentication & authorisation | Every system needs it — building it N times is waste |
| Logging & monitoring | Centralised observability is more effective than per-system |
| Notification service | Email, SMS, push — one service, many consumers |
| API gateway | Centralised routing, rate limiting, versioning |
| Data platform | Shared ingestion, storage, processing — not per-team data silos |
| CI/CD pipeline | Consistent deployment across teams |
flowchart TD
PORT["📐 The Portfolio"] --> DUP["🔍 Duplication Found\nAuth built 3 times\nLogging built 4 times\nNotifications built 2 times"]
PORT --> SHARED["🎯 Shared Capabilities\nBuild once, use everywhere"]
DUP --> WASTE["💸 Waste\nRedundant development\nRedundant maintenance\nInconsistent behaviour"]
SHARED --> VALUE["✅ Value\nReduced cost\nConsistent behaviour\nFaster delivery"]
SHARED --> PLAT2["🏗️ Platform\nShared capability\nbecomes a platform"]
PLAT2 --> ADOPT["Teams adopt the platform\nInstead of building their own"]
How to identify shared capabilities: Look at the capability map — which capabilities are served by multiple systems? Look at the landscape — which technologies appear in many systems? Ask teams — "What are you building that you wish someone else provided?" Look at duplication — where are teams solving the same problem independently?
The shared capability assessment: Do 3+ teams build this independently? Strong candidate for shared capability. Is consistency important? Shared capability reduces variation. Is the capability commodity? Standardise and share. Would a platform reduce time-to-market? Invest in shared platform. Is the current duplication causing problems? Consolidation will fix known issues.
The build-vs-share decision: Capability is unique to one domain → keep domain-specific. Capability is used by 2 teams, different needs → may not be worth sharing yet. Capability is used by 3+ teams, similar needs → strong shared candidate. Capability is commodity (auth, logging, CI/CD) → always share.
Shared capabilities = build once, use everywhere — portfolio thinking reveals the duplication that single-system thinking hides.
Try it yourself — The duplication check
What capabilities are your teams building independently?
| Capability | How many teams built it? | Could it be shared? |
|---|---|---|
If any capability is built by 3+ teams, you've found a consolidation opportunity.
6. Portfolio health — How to assess and communicate the state of the whole
Individual system health is tracked — uptime, performance, defects. But portfolio health — the overall state of all systems, investments, and dependencies — is rarely assessed.
Portfolio health assessment provides a structured view of the whole — so leadership can see where the portfolio is healthy, where it's at risk, and where investment is needed.
Portfolio health dimensions:
| Dimension | What it measures |
|---|---|
| System health | Technical quality, supportability, lifecycle stage |
| Investment alignment | Are we investing in the right capabilities? |
| Dependency risk | How concentrated is risk? Are there single points of failure? |
| Technology currency | How much of the portfolio runs on current, supported technology? |
| Delivery throughput | How fast can the portfolio change? |
| Cost efficiency | Is the portfolio cost-effective? |
flowchart TD
PORT["📐 Portfolio Health Assessment"] --> SYS_H["📱 System Health\nTechnical quality\nLifecycle stage"]
PORT --> INV_H["💰 Investment Alignment\nAre we funding\nthe right things?"]
PORT --> DEP_H["🔗 Dependency Risk\nSingle points of failure\nCascading risk"]
PORT --> TECH_H["⚙️ Technology Currency\nHow much is current\nand supported?"]
PORT --> DEL_H["🚀 Delivery Throughput\nHow fast can\nthe portfolio change?"]
PORT --> COST_H["💷 Cost Efficiency\nIs the portfolio\ncost-effective?"]
SYS_H --> REPORT["📊 Portfolio Health Report\nExecutive-ready summary"]
INV_H --> REPORT
DEP_H --> REPORT
TECH_H --> REPORT
DEL_H --> REPORT
COST_H --> REPORT
REPORT --> DECISIONS["🧭 Decisions\nInvest · Rationalise\nSequence · De-risk"]
The portfolio health dashboard:
| Dimension | Metric | Healthy | At Risk | Unhealthy |
|---|---|---|---|---|
| System health | % of systems in "Good" status | >70% | 50-70% | <50% |
| Technology currency | % on supported versions | >80% | 60-80% | <60% |
| Dependency risk | Systems with no redundancy | <5 | 5-10 | >10 |
| Investment alignment | % of spend on strategic capabilities | >60% | 40-60% | <40% |
| Delivery throughput | Lead time for changes | <1 week | 1-4 weeks | >4 weeks |
| Cost efficiency | Cost per transaction/user/event | Decreasing | Stable | Increasing |
Portfolio health = the state of the whole — not just individual systems, but how everything connects and performs together.
Try it yourself — The health check
Rate your portfolio on each dimension (1-5):
| Dimension | Score | Gap action |
|---|---|---|
| System health | ||
| Investment alignment | ||
| Dependency risk | ||
| Technology currency | ||
| Delivery throughput | ||
| Cost efficiency |
Any dimension below 3 needs attention.
7. Making portfolio-aware decisions — How dependency thinking changes what you recommend
The best single-system decision can be the worst portfolio decision. Choosing the "best" database for one system may introduce a technology the organisation can't support. Building the "fastest" integration may create a point-to-point connection that becomes a maintenance nightmare.
Portfolio-aware decisions consider the ripple effects — not just what's best for one system, but what's best for the portfolio.
The portfolio-aware test — before making a decision, ask: Does this introduce a new technology the portfolio must support? Does this create a dependency others will rely on? Does this conflict with another initiative? Does this duplicate something that already exists? Does this align with the target state? Does this affect the sequencing of other work?
flowchart TD
DEC["Architecture Decision"] --> TEST["Portfolio-Aware Test"]
TEST --> Q1{"New technology?"}
TEST --> Q2{"Creates dependency?"}
TEST --> Q3{"Conflicts with\nanother initiative?"}
TEST --> Q4{"Duplicates existing?"}
TEST --> Q5{"Aligns with\ntarget state?"}
TEST --> Q6{"Affects sequencing\nof other work?"}
Q1 -->|"Yes"| R1["Assess support cost"]
Q2 -->|"Yes"| R2["Map downstream impact"]
Q3 -->|"Yes"| R3["Coordinate with other programme"]
Q4 -->|"Yes"| R4["Consider consolidation"]
Q5 -->|"No"| R5["Justify divergence"]
Q6 -->|"Yes"| R6["Update dependency-aware sequence"]
R1 --> FINAL["✅ Portfolio-Aware Decision"]
R2 --> FINAL
R3 --> FINAL
R4 --> FINAL
R5 --> FINAL
R6 --> FINAL
The portfolio decision framework:
| Question | If the answer suggests a problem | Mitigation |
|---|---|---|
| Does this introduce a new technology? | New technology = new support burden | Check if existing technology can serve the need |
| Does this create a shared dependency? | Shared dependency = concentrated risk | Design for failure, add redundancy |
| Does this conflict with another initiative? | Conflict = wasted effort or rework | Coordinate programmes, align roadmaps |
| Does this duplicate existing capability? | Duplication = waste | Use existing or consolidate |
| Does this diverge from target state? | Divergence = debt accumulation | Justify explicitly or redesign |
| Does this change the dependency sequence? | Changed sequence = roadmap impact | Update plan, communicate impact |
The portfolio-aware architecture review: Technology fit — does this use portfolio-standard technology? Integration fit — does this use portfolio-standard integration patterns? Capability fit — does this align to the capability map? Dependency impact — what does this depend on? What depends on this? Investment alignment — does this consume portfolio investment wisely? Target state alignment — does this move the portfolio toward the target?
Portfolio-aware decisions = considering ripple effects — not just what's best for one system, but what's best for the whole.
Try it yourself — The portfolio-aware test
Take your next architecture decision. Run it through the test:
| Question | Your answer |
|---|---|
| Does this introduce a new technology the portfolio must support? | |
| Does this create a dependency others will rely on? | |
| Does this conflict with another initiative? | |
| Does this duplicate something that already exists? | |
| Does this align with the target state? | |
| Does this affect the sequencing of other work? |
If any answer suggests a problem, you need to mitigate before proceeding.
Putting it all together
Here's the complete picture in one diagram. This is the mental model worth internalising.
flowchart TD
SYSTEMS["📱 Individual Systems\nEach designed well\nin isolation"]
SYSTEMS --> SEE["👁️ See the Whole\nPortfolio thinking\nAll systems, programmes, investments"]
SEE --> MAP["🔗 Map Dependencies\nWhat relies on what\nRuntime, data, platform, team"]
SEE --> SHARED["🤝 Find Shared Capabilities\nBuild once, use everywhere\nReduce duplication"]
SEE --> HEALTH["📊 Assess Portfolio Health\nSystem health, tech currency\nDependency risk, investment alignment"]
MAP --> SEQUENCE["⏱️ Sequence by Dependencies\nWhat must happen before what\nPriority adjusts to dependencies"]
SHARED --> CONSOLIDATE["🔧 Consolidate\nShared platforms\nReduce duplication"]
HEALTH --> INVEST["💰 Invest Wisely\nFund what matters\nDe-risk what is vulnerable"]
SEQUENCE --> DECISIONS["🧭 Portfolio-Aware Decisions\nConsider ripple effects\nOptimise the whole, not just the part"]
CONSOLIDATE --> DECISIONS
INVEST --> DECISIONS
DECISIONS --> VALUE["✅ Value\nCoherent portfolio\nReduced risk and cost\nFaster, safer delivery"]
The foundation:
Individual systems don't exist in isolation — they're part of a portfolio. Portfolio thinking means seeing how everything connects, not just how one thing works. Dependencies determine sequence — not priority. You can't build what you can't connect to. Dependency-aware sequencing is the foundation of credible roadmaps. Portfolio-aware decisions consider ripple effects. The best single-system decision can be the worst portfolio decision. Always ask: "How does this affect the whole?" See the whole. Map the connections. Decide with awareness.
Cheat Sheet — All the key terms
| Concept | One-Line Memory | Key Action |
|---|---|---|
| Portfolio thinking | See all systems as a connected whole | Shift from single-system to system-of-systems |
| Portfolio contents | Systems, platforms, programmes, investments | Register and track all four types |
| Dependency mapping | What relies on what | Map runtime, data, platform, team, temporal dependencies |
| Sequencing | What must happen before what | Dependencies first, priority adjusts |
| Shared capabilities | Build once, use everywhere | Identify and consolidate duplication |
| Portfolio health | The state of the whole | Assess system health, tech currency, dependency risk, investment alignment |
| Portfolio-aware decisions | Consider ripple effects | Test every decision for portfolio impact |
How to know if this landed
You'll know this has landed when someone stops optimising individual systems and starts asking "how does this affect the portfolio?" Can describe the full portfolio — systems, platforms, programmes, investments. Has mapped dependencies for the top 20 most critical systems. Can identify at least 3 shared capabilities that should be consolidated. Uses dependency-aware sequencing in roadmap planning. Considers portfolio ripple effects before making architecture decisions. Assesses portfolio health at least quarterly. And makes investment decisions based on portfolio data, not just single-system needs.
What changes when the mental model clicks
I've run this session with a telecommunications company where 200+ systems had no dependency map — changes caused unpredictable outages. 3 teams independently built customer notification services. Programme sequencing based on business priority alone — critical dependency chains blocked delivery. The gap at the start is usually not about understanding dependencies — it's about not seeing the portfolio as a connected whole.
What changes after this session:
Teams stop optimising individual systems and start asking "how does this affect the portfolio?" The dependency mapping exercise — "what relies on what?" — is always the moment things click. People stop treating sequencing as a priority exercise and start treating it as a dependency exercise. Their results get better. They stop building duplicate capabilities when the real problem was that nobody had mapped what already existed.
The portfolio-aware decision test tends to immediately change how teams think about their architecture decisions. They start asking "does this introduce a new technology the portfolio must support?" Their coherence goes up. They stop making locally optimal, globally suboptimal decisions when the real problem was that they hadn't considered the ripple effects.
Book a Workshop
Ready to see your portfolio as a connected whole and make decisions that optimise for the whole?
or
1-day workshop includes portfolio register creation — systems, platforms, programmes, investments, dependency mapping exercise — runtime, data, platform, and team dependencies, shared capability identification — finding duplication and consolidation opportunities, dependency-driven sequencing — building a realistic, dependency-aware delivery order, portfolio health assessment — identifying risks and investment priorities, portfolio-aware decision exercise — testing real decisions for ripple effects, and portfolio map template + dependency radar + investment alignment grid.