Quick Navigation
- Start here — Why landscape mapping matters
- What to capture
- How to build the landscape
- Reading the landscape
- Technology heat maps
- Dependency analysis
- Using the landscape for decisions
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
Most organisations don't have an accurate picture of what they're running. Systems were built by different teams, in different years, for different reasons. Nobody mapped the whole thing. When someone asks "what do we have?" the answer is tribal knowledge — incomplete, contradictory, and out of date. I've seen organisations discover they had 2-3x more applications than leadership believed.
The application and technology landscape is the full picture of what an organisation runs — every application, platform, integration, and technology — and how they depend on each other. It's the foundation for every rationalisation, modernisation, and investment decision.
Without the landscape, decisions are made blind. With it, duplication becomes visible, dependencies become manageable, and investment becomes evidence-based.
Keep it in mind.
1. Why landscape mapping matters — The cost of architectural blindness
When you can't see what you have, you duplicate it, under-invest in it, or break it accidentally.
Architectural blindness — not knowing the full landscape — creates specific, predictable problems:
Duplication — three teams build three analytics platforms because nobody knew the others existed. Hidden dependencies — decommission a "minor" system and discover 12 other systems depend on it. Technology debt — systems running on unsupported versions because nobody tracked the risk. Wasted investment — buying a new platform that overlaps with an existing one. Failed migrations — planning a move without understanding what actually needs to move.
flowchart TD
BLIND["Architectural Blindness\nNo accurate landscape"] --> DUP["Duplication\nSame capability built 3 times"]
BLIND --> DEP["Hidden Dependencies\nDecommission breaks other systems"]
BLIND --> DEBT["Technology Debt\nUnsupported versions, unnoticed"]
BLIND --> WASTE["Wasted Investment\nNew platform overlaps existing"]
BLIND --> FAIL["Failed Migrations\nDon't know what needs to move"]
DUP --> COST["💸 Cost\nRedundant spend\nIncreased risk\nSlower delivery"]
DEP --> COST
DEBT --> COST
WASTE --> COST
FAIL --> COST
LANDSCAPE["Mapped Landscape\nAccurate, current, complete"] --> VIS["Visibility\nDuplication, dependencies,\ndebt — all visible"]
VIS --> DECISIONS["Evidence-Based Decisions\nRationalise, invest, migrate\nwith confidence"]
The reality: most organisations discover they have 2-3x more applications than they thought. Most organisations have dependencies they didn't know about. Most organisations have technology versions that are end-of-life without anyone noticing. Mapping the landscape is uncomfortable — but it's the only way to make informed decisions.
Research findings: Gartner estimates that the average enterprise runs 30-40% more applications than leadership believes. McKinsey finds that 60% of failed cloud migrations cite incomplete dependency mapping as a root cause. Forrester reports that organisations with mature application portfolio management reduce technology spend by 15-25%.
You cannot rationalise, modernise, or migrate what you cannot see — the landscape makes everything visible.
Try it yourself — The count test
How many applications does your organisation run?
| Question | Leadership's answer | Actual answer |
|---|---|---|
| How many applications? | ||
| How many integrations? | ||
| How many end-of-life technologies? |
If you don't have an actual answer for the second column, you're making decisions blind.
2. What to capture — Applications, platforms, integrations, data flows, and technologies
"Landscape" can mean different things. Without scope, teams either capture too little (useless) or too much (unmaintainable).
A useful landscape captures five layers — each answering a different question:
| Layer | Question it answers |
|---|---|
| Applications | What systems do we run? |
| Platforms | What shared foundations do they sit on? |
| Integrations | How do they talk to each other? |
| Data flows | How does data move between them? |
| Technologies | What languages, frameworks, databases, infrastructure do they use? |
flowchart TD
LAND["Landscape"] --> APP["📱 Applications\nWhat systems do we run?\nName, owner, purpose, health"]
LAND --> PLAT["🏗️ Platforms\nWhat shared foundations?\nCloud, middleware, data platform"]
LAND --> INT["🔗 Integrations\nHow do they connect?\nAPIs, messaging, files, databases"]
LAND --> DATA["📊 Data Flows\nHow does data move?\nSources, transformations, destinations"]
LAND --> TECH["⚙️ Technologies\nWhat do they run on?\nLanguages, frameworks, databases, infra"]
What to capture per layer:
Applications: Name, description, owner, business capabilities served, health status, lifecycle stage, hosting, cost. Platforms: Name, type (cloud, middleware, data platform), applications hosted, shared services, support status. Integrations: Source, destination, pattern (API, messaging, file, database), data exchanged, frequency, protocol, owner. Data flows: Source system, destination system, data domain, transformation, quality level, real-time vs batch. Technologies: Application, language, framework, database, cloud provider, version, support end date, licence type.
Lifecycle stages: Invest — actively developed, new features planned. Maintain — stable, receiving patches, no new features. Reduce — usage declining, planned for replacement. Retire — end of life, decommission planned. Unknown — status unclear, needs assessment.
Capture five layers — applications, platforms, integrations, data, technologies — each answering a different question.
Try it yourself — The layer audit
Which of these five layers do you currently have documented?
| Layer | Documented? | Last updated? |
|---|---|---|
| Applications | ||
| Platforms | ||
| Integrations | ||
| Data flows | ||
| Technologies |
If fewer than three are documented, your landscape is incomplete.
3. How to build the landscape map — Sources, workshops, and discovery techniques
Nobody has the full picture in their head. The landscape must be assembled from multiple sources and validated with the people who actually build and run the systems.
Building the landscape is a discovery exercise — part research, part workshop, part tooling.
Sources of truth:
| Source | What it provides | Limitation |
|---|---|---|
| CMDB / asset register | Known applications and infrastructure | Often incomplete or stale |
| Code repositories | What is actually being built | Doesn't cover legacy or vendor systems |
| Cloud provider consoles | What is deployed and running | Only covers that cloud provider |
| API gateway / middleware | How systems actually connect | Only covers managed integrations |
| Expense records | What the organisation pays for | Includes shadow IT |
| Team interviews | Tribal knowledge, workarounds, pain points | Subjective, incomplete |
| Network scanning | What is actually running on the network | Doesn't capture purpose or ownership |
flowchart TD
LANDSCAPE["Landscape Map"] --> CMDB["CMDB / Asset Register\nKnown systems"]
LANDSCAPE --> REPO["Code Repositories\nWhat is being built"]
LANDSCAPE --> CLOUD["Cloud Consoles\nWhat is deployed"]
LANDSCAPE --> API["API Gateway / Middleware\nHow systems connect"]
LANDSCAPE --> EXPENSE["Expense Records\nWhat we pay for"]
LANDSCAPE --> TEAM["Team Interviews\nTribal knowledge"]
LANDSCAPE --> NET["Network Scanning\nWhat is actually running"]
CMDB --> VALIDATE["✅ Validate with Teams\nCross-check all sources"]
REPO --> VALIDATE
CLOUD --> VALIDATE
API --> VALIDATE
EXPENSE --> VALIDATE
TEAM --> VALIDATE
NET --> VALIDATE
VALIDATE --> FINAL["📐 Landscape Register\nAccurate, owned, current"]
The workshop approach: Seed — pull everything you can from automated sources (CMDB, cloud, repos). Workshop — bring teams together: "What systems do you build? What do you depend on?" Validate — cross-check team input against automated sources. Assign ownership — every application must have an owner. Publish — make the landscape accessible to all architects.
Discovery techniques ranked by effort and accuracy: CMDB export — low effort, medium accuracy, starting point. Cloud API scan — low effort, high accuracy, cloud-deployed applications. Code repo scan — medium effort, high accuracy, custom-built applications. Network scan — medium effort, high accuracy, finding unknown running services. Expense audit — medium effort, medium accuracy, finding SaaS and shadow IT. Team workshops — high effort, high accuracy, validating and discovering tribal knowledge. Runtime dependency tracing — medium effort, very high accuracy, understanding real integration dependencies.
Build the landscape from multiple sources — then validate with the teams who actually build and run the systems.
Try it yourself — The source check
Which of these sources have you used to build your landscape?
| Source | Used? | What did it reveal? |
|---|---|---|
| CMDB | ||
| Cloud APIs | ||
| Code repos | ||
| Network scan | ||
| Expense audit | ||
| Team workshops |
If you've only used one or two sources, your landscape is incomplete. Combine at least four.
4. Reading the landscape — What the picture reveals about health, risk, and opportunity
Once you have the landscape, you need to read it. The raw register is just data. The patterns in the data tell you where the organisation is healthy, where it's at risk, and where the opportunities are.
Reading the landscape means looking for specific patterns:
| Pattern | What it indicates |
|---|---|
| Many applications serving one capability | Duplication — consolidation opportunity |
| One application serving many capabilities | Over-reliance — risk concentration |
| Old applications with no replacement planned | Technology debt — risk of unsupported systems |
| Integrations with no documented owner | Governance gap — who fixes it when it breaks? |
| Applications with no clear business capability | Zombie systems — are they still needed? |
| Clusters of point-to-point integrations | Integration debt — consider middleware or events |
flowchart TD
LAND["Landscape Register"] --> PAT["Pattern Analysis"]
PAT --> DUP["🔍 Duplication\nMany apps, one capability\n→ Consolidate"]
PAT --> OVER["⚖️ Over-reliance\nOne app, many capabilities\n→ Risk concentration"]
PAT --> OLD["📅 Old Technology\nNo replacement planned\n→ Technology debt"]
PAT --> ORPH["👻 Orphan Integrations\nNo documented owner\n→ Governance gap"]
PAT --> ZOMB["🧟 Zombie Systems\nNo clear capability\n→ Retire candidate"]
PAT --> SPAG["🔀 Spaghetti\nPoint-to-point everywhere\n→ Middleware opportunity"]
DUP --> ACTION["✅ Actionable Insight"]
OVER --> ACTION
OLD --> ACTION
ORPH --> ACTION
ZOMB --> ACTION
SPAG --> ACTION
The analysis dimensions: Business value — how critical is this application to business operations? Technical health — how well-built, supported, and current is the technology? Cost — how much does this application cost to run annually? Risk — what's the consequence if this application fails? Strategic fit — does this application align to the target state?
The portfolio bubble chart plots business value against technical health. High value, healthy = invest and enhance. High value, unhealthy = modernise — critical investment needed. Low value, healthy = tolerate — maintain, no new investment. Low value, unhealthy = retire — decommission candidate.
The landscape register is data — the patterns are insight — look for duplication, over-reliance, debt, and orphan systems.
Try it yourself — The pattern hunt
Look at your landscape. Which patterns do you see?
| Pattern | Evidence | Action |
|---|---|---|
| Duplication | ||
| Over-reliance | ||
| Technology debt | ||
| Zombie systems |
If you can name evidence for two or more, your landscape is telling you where to act.
5. Technology heat maps — Age, supportability, and strategic fit
The landscape register has hundreds of entries. Leadership needs a visual summary of technology health — which technologies are current, which are ageing, and which are at risk.
A technology heat map overlays colour onto the technology dimensions — green for current, amber for ageing, red for end-of-life or unsupported.
Dimensions to visualise: Age — how old is the technology version? Supportability — is the vendor still supporting it? When does support end? Strategic fit — does this technology align to the target state? Skill availability — can we hire or retain people who know this technology?
flowchart LR
subgraph HEAT["Technology Heat Map"]
direction TB
subgraph MODERN["Modern & Supported 🟢"]
M1["Python 3.12"]
M2["PostgreSQL 16"]
M3["Kubernetes 1.29"]
end
subgraph AGEING["Ageing — Plan Migration 🟡"]
A1["Java 11"]
A2["Angular 14"]
A3["MySQL 5.7"]
end
subgraph RISK["End-of-Life — At Risk 🔴"]
R1["Windows Server 2012"]
R2["Oracle 12c"]
R3[".NET Framework 4.5"]
end
end
What the heat map reveals: 🔴 Red technologies are security and compliance risks — they need immediate attention. 🟡 Amber technologies are not yet critical — plan migration before they go red. 🟢 Green technologies are current — maintain and keep updated.
Scoring criteria: 1 - Current — latest or recent version, full vendor support, strategic fit. 2 - Supported — not latest but fully supported, strategic fit. 3 - Ageing — version approaching end of support, or limited strategic fit. 4 - At risk — end of support within 12 months, or no strategic fit. 5 - End of life — unsupported, security risk, or completely misaligned.
The support lifecycle timeline: General Availability — full support, active development. Mainstream Support — bug fixes, security patches. Extended Support — security patches only, higher cost. End of Life — no support, security risk.
Technology heat maps turn a 200-row register into an executive-ready risk picture.
Try it yourself — The heat map check
What percentage of your technologies fall into each category?
| Category | % of your estate | Action needed |
|---|---|---|
| 🟢 Current | ||
| 🟡 Ageing | ||
| 🔴 End of life |
If more than 10% are red, you have a security problem. If more than 30% are amber, you have a migration backlog.
6. Dependency analysis — What breaks when something changes
Systems don't exist in isolation. They depend on each other — through integrations, shared data, shared platforms, and shared services. When you change one system, you need to know what else is affected.
Dependency analysis maps the connections between systems — so that changes, decommissions, and migrations can be planned without breaking things unexpectedly.
flowchart TD
A["System A\nCustomer Portal"] -->|"API call"| B["System B\nCustomer Service"]
A -->|"Data read"| C["System C\nCustomer DB"]
B -->|"Event"| D["System D\nNotification Service"]
B -->|"API call"| E["System E\nPayment Gateway"]
C -->|"Shared DB"| F["System F\nReporting"]
E -->|"Platform"| G["☁️ Shared Cloud Platform"]
A -.->|"If B breaks:\nA loses customer data"| IMPACT["Impact Analysis\nWhat else breaks?"]
Types of dependencies: Runtime integration — System A calls System B's API to get customer data. Data dependency — System C reads from the same database as System D. Platform dependency — System E runs on the same Kubernetes cluster as System F. Deployment dependency — System G must be deployed before System H can start. Shared service — Systems I, J, K all use the same authentication service.
Practical uses: before decommissioning a system: "What depends on this?" Before migrating a system: "What integrations must be re-pointed?" Before a major change: "What's the blast radius?" For risk assessment: "Which systems are single points of failure?"
Dependency depth matters: Direct dependencies — System A → System B. One hop. Manageable. Indirect dependencies — System A → B → C → D. Transitive. Complex — trace the chain. Hidden dependencies — shared database, shared infra. Not visible in API calls. Dangerous — often missed.
Dependency discovery methods: Manual workshops — high effort, medium accuracy. Teams describe what they depend on. Code analysis — medium effort, high accuracy. Parse imports, API calls, config files. Runtime tracing — low effort, very high accuracy. Distributed tracing (Jaeger, Zipkin) shows real calls. API gateway logs — low effort, high accuracy. Shows which services call which. Database link analysis — medium effort, high accuracy. Shows which applications access which databases.
Dependency analysis answers one critical question: "What breaks when this changes?"
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 for your critical systems, you're one change away from an outage.
7. Using the landscape for decisions — Rationalisation, consolidation, and investment
A landscape register that's never used has no value. The landscape must drive decisions — rationalisation, consolidation, investment, and migration planning.
The landscape becomes the evidence base for specific decisions:
| Decision | How the landscape helps |
|---|---|
| Rationalisation | Identify duplicate, redundant, or zombie systems to retire |
| Consolidation | Find systems that serve the same capability and should be merged |
| Investment | Show which systems are at risk and need modernisation funding |
| Migration | Map what needs to move and what depends on it |
| Vendor management | Identify concentration risk — too many systems on one vendor |
| Security | Find systems running unsupported technology |
flowchart TD
LAND["📐 Landscape Register"] --> RAT["⬛ Rationalisation\nRetire zombie and\nredundant systems"]
LAND --> CONS["🔗 Consolidation\nMerge systems serving\nthe same capability"]
LAND --> INV["💰 Investment\nModernise at-risk\nand high-value systems"]
LAND --> MIG["📦 Migration\nMap what moves and\nwhat depends on it"]
LAND --> VENDOR["🏢 Vendor Management\nIdentify concentration\nrisk"]
LAND --> SEC["🔒 Security\nFind unsupported\ntechnology"]
RAT --> VALUE["✅ Value\nReduced cost\nReduced risk\nFaster delivery"]
CONS --> VALUE
INV --> VALUE
MIG --> VALUE
VENDOR --> VALUE
SEC --> VALUE
The rationalisation decision framework: Does this application serve a business capability? No → retire candidate. Is there another application serving the same capability? Yes → consolidation candidate. Is the technology end-of-life? Yes → modernise or replace. Is the cost disproportionate to value? Yes → rationalise or replace. Is the application in the target state? No → plan transition. Does anyone depend on this? No → retire candidate.
Rationalisation categories: Tolerate — keep as-is, no investment. Low value, healthy technology. Invest — modernise and enhance. High value, unhealthy technology. Consolidate — merge with another system. Duplicate capability coverage. Replace — replace with new platform. End-of-life, misaligned with target. Retire — decommission. No capability, no dependents.
The landscape is only valuable when it influences decisions — rationalise, consolidate, invest, migrate.
Try it yourself — The decision test
What decisions has your landscape informed in the last quarter?
| Decision | Did the landscape inform it? | If not, why? |
|---|---|---|
| Rationalisation | ||
| Investment | ||
| Migration |
If the answer to any is "no," your landscape isn't being used. Fix that first.
Putting it all together
Here's the complete picture in one diagram. This is the mental model worth internalising.
flowchart TD
ORG["🏢 The Organisation\nRuns hundreds of systems\nNobody sees the whole picture"]
ORG --> BUILD["🔍 Build the Landscape\nMultiple sources + team validation\n5 layers: apps, platforms, integrations, data, tech"]
BUILD --> READ["👁️ Read the Landscape\nFind patterns: duplication,\nover-reliance, debt, orphans"]
BUILD --> HEAT["🌡️ Technology Heat Map\nAge, supportability,\nstrategic fit"]
BUILD --> DEP["🔗 Dependency Analysis\nWhat breaks when\nsomething changes?"]
READ --> DEC["🧭 Make Decisions\nRationalise · Consolidate\nInvest · Migrate"]
HEAT --> DEC
DEP --> DEC
DEC --> VALUE["✅ Value\nReduced cost and risk\nEvidence-based investment\nSafer migrations"]
The foundation:
Most organisations run 2-3x more applications than leadership believes. Mapping the landscape makes the invisible visible — duplication, debt, and hidden dependencies. The landscape has five layers — applications, platforms, integrations, data flows, technologies. Each answers a different question. Capture all five. The landscape must drive decisions — rationalisation, consolidation, investment, migration. A register that influences nothing is architecture theatre. The landscape is the factual foundation of enterprise architecture. Build it. Read it. Use it.
Cheat Sheet — All the key terms
| Concept | One-Line Memory | Key Action |
|---|---|---|
| Landscape register | The full picture of what the organisation runs | Capture 5 layers: apps, platforms, integrations, data, tech |
| Discovery | Building the landscape from multiple sources | Combine automated discovery with team workshops |
| Pattern analysis | Reading the landscape for insight | Look for duplication, over-reliance, debt, orphans |
| Technology heat map | Visualising age, supportability, strategic fit | Red = end-of-life risk, green = current |
| Dependency analysis | What breaks when something changes | Map direct, indirect, and hidden dependencies |
| Rationalisation | Using the landscape to reduce and consolidate | Tolerate, invest, consolidate, replace, retire |
| Maintenance | Keeping the landscape current | Quarterly refresh, event-triggered updates |
How to know if this landed
You'll know this has landed when someone can answer "how many applications do we run?" with a specific, accurate number. Has identified at least 3 cases of duplication or redundancy in the portfolio. Has mapped dependencies for the top 20 most critical systems. Has a technology heat map showing end-of-life exposure. Uses the landscape in rationalisation and investment decisions. Reviews the landscape at least quarterly — or after major changes. And every application has an identified owner.
What changes when the mental model clicks
I've run this session with teams where leadership believed the company ran 150 applications — actual count was 410. A "minor" system was decommissioned and broke 8 downstream systems nobody knew depended on it. The gap at the start is usually not about understanding landscapes — it's about not knowing what they don't know.
What changes after this session:
Teams stop making decisions blind and start treating the landscape as the factual foundation of every architecture decision. The discovery exercise — "pull from automated sources, validate with teams" — is always the moment things click. People stop treating landscapes as one-off projects and start treating them as living documents. Their results get better. They stop decommissioning systems that break others when the real problem was that nobody mapped the dependencies.
The pattern analysis exercise tends to immediately change how teams see their portfolio. They start spotting duplication, over-reliance, and zombie systems. Their rationalisation candidates multiply. They stop buying new platforms when the real problem was that they already had three doing the same thing.
Book a Workshop
Ready to see the full picture of what your organisation runs?
or
1-day workshop includes landscape discovery exercise — automated and workshop-based — with your real systems, technology heat map creation — identifying end-of-life and at-risk technologies, dependency mapping for your most critical applications, portfolio analysis — finding duplication, redundancy, and rationalisation candidates, integration planning — embedding landscape management in architecture governance, and application landscape register + technology heat map + dependency matrix.