Map Your Software Ecosystem Before Integration

Every integration surprise we have ever untangled traces back to the same root cause: a system that was missing from the map. Sometimes it is a legacy tool only one department uses. Sometimes it is the Excel everyone pretends not to depend on. Once, it was a person, because a colleague re-typing orders from email into the ERP is an integration too, just an undocumented one that takes holidays.

This is why, before any integration or custom software project, we ask clients to put their entire software ecosystem on one page. Not an enterprise architecture programme. One page. This guide covers why skipping that page is the most expensive shortcut in software projects, what belongs on it, and how to build it without hiring an architect.

Why do integration projects blow their budgets?

Not because someone picked the wrong technology. The most consistent evidence comes from Panorama Consulting, an independent ERP consultancy that surveys implementation outcomes every year. In their 2026 ERP Report, more than a quarter of organisations exceeded their project budget, and the most common reason was an unexpected need to purchase additional technology [1]. Panorama's own wording is blunt: organisations "discover fatal misfits late in the project", then compensate with extra tools, scope expansion and custom builds.

The 2025 edition adds the second half of the picture: the number one reason projects ran late was data issues, meaning the integrity, consistency and accuracy of data coming out of existing systems [2]. And the 2024 edition connects both to preparation: among organisations that significantly exceeded their budget, only about a third had done a technology assessment before starting [3]. Two thirds of the worst overruns began with nobody auditing what was already there.

McKinsey's delivery practice has claimed that three quarters of ERP transformations fail to stay on schedule or budget [4]. Whatever the exact number in your industry, the mechanism is the one Panorama documents: the budget does not die at the demo. It dies when the project meets a system nobody mentioned.

Why do you know less about your own systems than you think?

Because software portfolios grew faster than anyone's mental model of them. Okta's Businesses at Work 2025 report, based on usage telemetry rather than a survey, found the average company now runs 101 applications, the first time the average has crossed one hundred [5]. And that is measured among companies mature enough to run single sign-on.

For companies closer to our clients' size, Cledara analysed over a million software transactions in businesses under 200 employees and found they consistently underestimate how many tools they use by around 40% [6]. For every ten tools the company knows about, roughly fourteen are in use. In the same study, companies with 100 to 200 employees wasted about a third of their software budget on tools nobody was really using (Cledara is a software management vendor, so read the numbers with that in mind, but the direction matches everything we see in discovery).

Leadership feels this without being able to quantify it. In IBM's 2025 CEO Study of 2,000 chief executives, half admitted that the pace of recent investment has left their organisation with "disconnected, piecemeal technology" [7]. Meanwhile Flexera's 2025 ITAM research found that the share of IT teams reporting full visibility of their technology estate fell year over year, from 47% to 43% [8]. More tools to see with, less seen.

If you cannot name every system, you cannot scope an integration honestly, and neither can your vendor. A vendor quotes what you can articulate; the gaps get filled with assumptions and change requests.

What belongs on a one-page ecosystem map?

The map we build with clients before any project answers four questions. None of them requires technical knowledge. All of them require honesty.

1. What systems are in place? Everything that stores or moves business data: ERP, CRM, the quoting tool, the file shares, the spreadsheets that act as databases, the WhatsApp group where the warehouse confirms shipments. If removing it on a Friday would cause a phone call on Monday, it belongs on the map.

2. Who owns each system, and what does it cost? A named person, not a department, plus the licence or subscription cost. This single column usually pays for the exercise: most companies find tools nobody has owned since the person who bought them left.

3. How do the systems interact? For each connection: what data flows, in which direction, how often, and by what mechanism (API, file export, manual re-typing). Manual bridges belong on the map with the same weight as APIs, because they fail more often and explain more delays.

4. Where are the gaps? Which data exists in two systems with two different truths? Which process dies when one specific person is on holiday? Which system will the new project need to talk to that currently talks to nothing?

We wrote before about what to prepare before you talk to any vendor, and this map is the preparation companies most often skip. It is also the one that determines the integration budget.

How do you map your ecosystem without an architect?

You do not need an enterprise architecture framework. Academic work on architecture for small and mid-sized companies (Ghent University's research on EA for SMEs) reaches the same conclusion we did in practice: classic frameworks are too heavy for a 50 to 500 person company, and a simplified model captures most of the value [9]. Three lightweight methods, in increasing order of effort:

A system inventory. A spreadsheet with the four questions above as columns, filled in over two or three afternoons by the people who use the systems day to day, not just IT. A spreadsheet is a fine snapshot for a project, even if it is a poor permanent management tool (in a Josys survey, 63% of companies track their software in spreadsheets year-round, which is how portfolios drift out of sight in the first place) [10].

A data flow sketch. One page, boxes and arrows: where does an order, a quote or a product record enter the company, and which systems does it pass through before it becomes an invoice? Follow one real transaction end to end. This is the fastest way to surface the manual bridges.

A capability check. List what the business must be able to do (quote, configure, plan production, invoice), then write next to each capability which system supports it. Duplicates and blanks jump out immediately. In Bizzdesign's 2025 State of Enterprise Architecture survey, only 23% of organisations said they have a very good understanding of their own capabilities [11], so a one-afternoon version of this already puts you ahead.

Whichever method you pick, timebox it. The map that gets finished in a week beats the perfect one that is still in progress when the vendor contract is signed.

Why does AI raise the stakes in 2026?

Because AI initiatives are now failing on exactly this. S&P Global Market Intelligence found that 42% of companies abandoned most of their AI initiatives in 2025, up from 17% a year earlier [12]. In Cloudera's survey of nearly 1,500 IT leaders, integration with legacy systems was the second biggest barrier to deploying AI agents [13], and Deloitte's 2026 enterprise AI research puts only 11% of organisations running agents in production [14].

The pattern underneath is consistent: models are rarely the problem, connections are. An AI agent cannot use a system you forgot you had, and it will confidently work around data it cannot reach. The same one-page map that de-risks an integration project is now the first document we ask for when a client wants to talk about AI, because it answers the question every AI project eventually hits: what does this company run, and can anything talk to it?

Frequently Asked Questions

What is a software ecosystem map?

A one-page overview of every system that stores or moves business data in your company: what the systems are, who owns them, what they cost, how they exchange data (including manual re-typing), and where the gaps and duplicates are. It is the minimum viable version of what large enterprises call enterprise architecture.

How long does mapping a software ecosystem take?

For a 50 to 500 person company, two or three afternoons of focused work with the people who use the systems, not just IT. Timebox it to a week. The goal is a working snapshot before a project decision, not a permanently maintained model.

Do we need special tools to map our systems?

No. A spreadsheet and one boxes-and-arrows diagram are enough for the project-preparation version. Dedicated tools make sense later, if you decide to keep the map alive; the thinking, not the tooling, is the value.

We already started our integration project. Is it too late to map?

No, and it is cheaper than the alternative. Panorama Consulting's data shows the most common budget overrun cause is technology "misfits" discovered late. A map made mid-project turns the remaining unknowns into a list you can price, instead of surprises you absorb.

How does an ecosystem map relate to AI readiness?

Directly. AI agents and assistants are only as useful as the systems and data they can reach. The map shows which systems have clean interfaces, which data has two conflicting sources of truth, and which processes run on manual bridges no agent can see. That is the starting point of any honest AI conversation.

The Bottom Line

Integration projects rarely fail on technology. They fail on the difference between what a company thinks it runs and what it really runs, and that difference is measurable: companies under 200 employees underestimate their own tool count by around 40%, and two thirds of the worst budget overruns started without a technology assessment. One page closes most of that gap: systems, owners, costs, connections, gaps.

We build custom software for manufacturers and operations-led companies, and mapping the existing ecosystem is the first thing we do in every engagement, whether it starts as technology strategy advisory or as a build. If you are planning an integration, an ERP change or an AI initiative, make the map before you sign anything. Book a welcome coffee and we will walk through your one page together, whether you build with us or not.

How to Map Your Software Ecosystem Before Any Integration Project