How Much Digital Complexity Has Your Organization Accumulated?

In short: Digital complexity goes beyond technical debt. It builds through overlapping platforms, fragmented data, integrations, and workflows that make change increasingly difficult. The real cost isn’t the number of systems an organization runs, but the time, money, and effort required to evolve them. Managing complexity means reducing unnecessary dependencies, improving governance, and building a digital environment that supports modernization, AI adoption, and long-term adaptability.

No transformation begins from zero. You start with every platform you’ve already paid for, every integration someone built under deadline, every workflow exception that got added for one important client, and every customer record that now lives in four places. You also inherit a decade of architectural decisions, each of which made perfect sense at the time.

The past doesn’t stay in the past here. It decides how fast you can launch a new customer experience, whether your data can be trusted when it moves between systems, and how painful your next modernization program will be. Lately, it’s also deciding whether AI ever makes it out of the pilot stage.

We find the term digital complexity helpful for describing this. It’s broader than technical debt and broader than “legacy.” Our working definition: digital complexity is the friction that builds up when your systems, data, interfaces, vendors, workflows, owners and change processes become more tangled and harder to understand than the business can afford to run and evolve.

Having a lot of technology isn’t the issue. A large enterprise is supposed to have a large digital ecosystem. Complexity becomes a business problem when the connections between all those pieces make ordinary change unreasonably slow and expensive.

So asking “how much legacy do we still have?” only gets leadership part of the answer. What they really need to know is how much of the organization’s ability to change is being consumed by the environment it has already built.

Digital Complexity Is Bigger Than Technical Debt

Technical debt is part of this, and most people already know what it looks like. A quick fix that became permanent. Software that should have been retired years ago. A one-off build nobody wants to touch. Those shortcuts eventually come due, usually at the worst possible moment.

But you can have very little technical debt and still be stuck.

Say your marketing and sales teams each picked a different SaaS tool for roughly the same job. Both are current, well supported and working fine. You’re still paying for two contracts, maintaining two sets of integrations, reconciling two copies of the same data and training two groups of users. Any future change to that capability now has to be made twice, and coordinated.

Or take integrations. You might have hundreds of clean, modern APIs, and still find that changing one field means a meeting with five teams. Or you might have excellent CRM, commerce, marketing and service platforms, each with its own slightly different idea of who the customer is.

None of that is legacy, and all of it slows you down. So we treat technical debt as one source of digital complexity among several. The rest comes from overlap, dependencies and the way teams and ownership are organized around the technology.

Some Complexity Is Supposed to Be There

It’s worth saying clearly that complexity doesn’t automatically mean someone made bad decisions. A bank operating across several regulatory regimes has more to deal with than a single-market lender. A retailer selling online, in stores, through a call centre and through partners needs more systems and connections than one that only sells online. Some complexity is just the shape of the business.

It helps to separate inherent complexity from accidental complexity. Inherent complexity comes from real requirements like scale, regulation, product range and the markets you serve. Accidental complexity creeps in through duplicate systems, inconsistent data, decisions nobody revisited, exceptions nobody removed and integrations nobody governs.

You’ll never get rid of the first kind, and you shouldn’t want to. The second kind is what quietly drains the capacity your teams need to run and change the business.

Complexity Builds Up One Sensible Decision at a Time

Nobody sets out to create an environment that no one understands. It happens gradually, through choices that were reasonable on the day they were made.

One business unit needs a capability fast and buys a platform. A year later, another department needs something similar with slightly different requirements, so it buys its own. A new customer experience needs data from an older system, so someone adds an integration. The core platform can’t handle a particular business rule, so it gets customized.

Each choice makes sense for the team that made it. The trouble is the pattern they form over time. Pressure leads to a local fix; the fix adds a system or an exception, which creates a dependency; the dependency makes the next change harder, someone builds a workaround, and the cycle starts again.

Teams see what a fix does for them. What it costs the rest of the organization, from another integration to another vendor to manage, tends to go unrecorded.

It gets worse because most organizations add technology much faster than they retire it. A shiny new front end goes on top of an old transaction system. A cloud service launches while the application it was supposed to replace stays switched on “for now.” A new integration layer is added, but the old point-to-point connections still need supporting. For a while, modernization can actually make things more complex.

Then there’s customization. Standard platforms slowly pick up workflows and exceptions that are hard to strip out once people’s jobs depend on them. And every new system needs connections to existing ones, each of which has to be understood, tested, monitored and maintained.

You Feel the Cost When Something Needs to Change

A fragmented environment can run for years without anything obviously breaking. The website loads. Records move between systems, more or less. People work around the awkward bits, and a few long-tenured employees know which report to trust and which spreadsheet fills the gap between two systems.

Then you need to change something. It could be a new digital service, a redesigned customer journey, a platform consolidation after an acquisition, a new regulation, or an AI assistant that has to work across several systems. At that point, all the connections nobody thought about start getting in the way.

We think of this as a complexity tax on change. Before a new initiative can deliver anything, the team has to figure out what already exists, how it behaves, who owns it, how to connect to it, how to test against it and which other teams need to be involved. That work rarely shows up in the original estimate.

Industry research suggests technical debt alone can add 10 to 20 per cent to project costs, and a big chunk of the budget meant for new products ends up going to debt-related work instead. Those numbers only capture part of the picture, as they don’t include the cost of duplicated tools, fragmented data, integration sprawl or the coordination overhead between teams.

Put simply, your past decisions keep making your future more expensive, and that cost lands on every new initiative you try to start.

Modernization Has to Deal With the Past First

Modernization plans are written about the future: a new platform, a cleaner architecture, better experiences, faster delivery. The work itself starts in the present, with everything that’s already there.

Research on modernization programs points to organizations losing a meaningful share of the value they expected because existing technology made the work slower and more expensive than planned.

We see a version of this all the time. A customer portal redesign kicks off as a UX project. A few weeks in, the team discovers identity needs consolidating, product information comes from three different systems, consent rules vary by channel, customer records don’t match, and several integrations need coordinated testing. The “front-end project” has quietly turned into an architecture program, with a timeline to match.

This is also why new technology doesn’t automatically simplify anything. Cloud architectures can be just as tightly coupled as what they replaced. Microservices can still require everyone to release on the same day. A stack of modern SaaS products can duplicate data and functionality as badly as any legacy platform. “Modern” tells you about the age of the technology. It doesn’t tell you whether you can change it easily.

AI Makes Complexity Much Harder to Ignore

If complexity was easy to live with before, AI is changing that quickly.

Getting AI beyond a few isolated tools depends almost entirely on what’s already underneath it. AI needs trusted data, interfaces it can act through, clear ownership and permissions, governance, and agreed-upon definitions of basic business concepts. In other words, how well your AI initiatives perform depends heavily on the state of everything else.

Research on AI adoption keeps pointing to the same obstacles. Data is consistently named as a primary barrier, even among high-performing organizations, alongside disconnected systems and aging infrastructure. There’s also growing concern that agentic AI could add complexity instead of value when integration and governance aren’t in place.

That second point deserves more attention than it gets. AI isn’t only held back by complexity, it can also create a lot more of it. Organizations are adding models, agents, vector stores, retrieval pipelines, gateways, APIs and AI features inside existing SaaS tools. If every business unit does this on its own, you end up with application sprawl all over again: the same content processed differently by several systems, the same data copied into multiple retrieval pipelines, agents doing overlapping jobs, and separate governance rules for each one. The tool you brought in to make things more efficient becomes one more layer to manage.

Teams with loosely coupled architecture and fast feedback loops get more out of it. Teams stuck with tightly coupled systems and slow processes find those problems getting bigger.

Digital complexity can put a ceiling on what AI will ever do for you. For most enterprises, access to good models isn’t the bottleneck. The bottleneck is whether the rest of the environment can give those models connected data, well-governed interfaces and clear ownership to work with.

A Big Digital Platform Isn’t Necessarily a Complex One

Knowing that a large enterprise has a lot of technology tells you almost nothing. What you want to know is how the pieces relate to each other and how much effort it takes to manage those relationships.

Digital complexity can show up in many ways. Structural complexity is about how many components you have, how varied they are and how they connect. Dynamic complexity comes from the fact that the environment never stops changing. Cognitive complexity is the one people tend to overlook: how hard it is for actual humans to understand the environment and work within it.

Cognitive complexity explains a lot. One company might run hundreds of applications but have clear owners, decent documentation, stable integration contracts, shared platforms and sensible boundaries. Another might run a fraction of that, but rely on undocumented integrations, duplicated data and three people who know how it all fits together. The second one looks simpler on paper. Try changing it, though, and you’ll find out quickly which is harder to work with.

Measuring Complexity Means Looking at Relationships

There’s no universally accepted “digital complexity score,” and honestly, that’s probably a good thing. Boiling everything down to one number would hide most of what makes complexity worth understanding.

A better approach looks across six areas:

Looking at all six tells you two separate things: how much complexity you have, and how well you’re equipped to manage it. The most useful assessments also tie back to specific customer journeys and strategic priorities, so you’re measuring complexity where it actually affects the business.

Architecture Diagrams Only Tell You So Much

A diagram shows how systems connect. It won’t show you what happens when one of them needs to change. For that, you need to look at how work actually moves through the organization.

How many teams are involved in a typical change? How many approvals does it need from outside the team? How often do releases have to be coordinated? How much testing depends on shared environments that someone else controls? How long do teams spend waiting on each other, and how many handoffs happen between an idea and a working feature? Answers to those questions describe complexity in terms a business leader recognizes.

Put a Dollar Figure on It

Technology budgets are reasonably good at tracking licences, infrastructure, staff and purchases. They’re bad at showing what the connections between systems cost.

We call that missing piece complexity-adjusted cost. On top of what it costs to build and run something, it counts the effort spent on integration, change, coordination, governance, reconciliation and eventual retirement, plus the opportunities you miss while your teams are busy with all of that.

Here’s a common example. A new tool comes in with a very attractive licence fee. Then it needs three integrations, creates yet another copy of customer data, adds a manual reconciliation step every month and requires someone with a specialized skill set to look after it. The cheap tool isn’t looking so cheap anymore.

Simpler Isn’t Always Better

If complexity is the problem, simplification sounds like the obvious answer. It’s not quite that easy, because complexity has a habit of moving around. Standardize one layer and another layer often gets harder. Consolidate five systems into one, and you might end up with a single platform buried in exceptions.

What you want is managed complexity. In practice, that means three things: remove complexity that isn’t earning its keep, contain the complexity you genuinely need, and stop unnecessary complexity from creeping back in. That turns modernization into something you keep doing, instead of a big cleanup you do once a decade.

Build Shared Foundations for Problems You Keep Solving

A lot of accidental complexity comes from different teams solving the same problem in different ways. Identity, consent, search, customer data, notifications, analytics and, increasingly, AI access are common culprits. When every business unit builds its own version, duplication is almost inevitable.

Shared platforms and capabilities let you solve those problems once and let everyone else build on top. Data is especially important here. As AI makes shared context more valuable, it’s getting harder to treat customer, product, employee and operational data as something each application owns for itself. Common definitions, clear ownership, reusable data products and consistent governance mean each new project doesn’t have to rebuild that context from scratch.

Make Retirement Part of the Plan

One reason enterprise technology keeps piling up is that buying something new is easy and switching something off is hard. New systems have champions. Old systems have dependencies, and nobody gets promoted for decommissioning one.

So most modernization programs add a new application, interface or data flow while leaving a good portion of the old environment running. “Temporary” coexistence turns into permanent architecture, and the estate grows again.

A modernization plan should spell out what’s going away: which applications get retired, which integrations are shut off, which customizations get removed, which duplicate data stores are deleted, which contracts end and which old processes stop. If a program adds a layer without removing one, it may have modernized a capability while making the organization as a whole more complex. That trade-off should be visible in the business case, not discovered two years later.

The Question Leaders Should Be Asking

If you take one thing from all of this, make it this question: is the next meaningful change getting easier or harder for us?

Most technology metrics won’t answer it. A platform can be perfectly stable while getting steadily harder to evolve. An application portfolio can come in on budget while every project inside it needs more coordination than the last. Individual teams can get faster while company-wide initiatives get slower, because the dependencies between those teams keep multiplying.

That’s why agility needs a broader definition. It’s partly about how fast a single team can build something, but much more about how much of the organization can change without setting off a chain reaction of coordination, rework and risk elsewhere.

Complexity Is Really About Adaptability

No organization is going to eliminate complexity. The hard part is separating the complexity your business genuinely needs from the complexity that piled up without delivering enough value to justify the friction.

Getting that right matters more now than it used to. Modernization, customer experience, operational efficiency and AI all sit on top of the digital ecosystem you already have. Modernization has to work around existing dependencies. Customer journeys cross existing system boundaries. AI depends on existing data and interfaces. And your operations teams absorb all the reconciliation and coordination that fragmentation creates. Every new initiative either lightens that load, keeps it in check or adds to it.

That’s why we think digital complexity deserves to be treated as a business problem on its own. The number of systems you run is rarely what holds you back. It’s the build-up of connections between systems, data, teams and processes that slowly erodes your ability to change as quickly and as affordably as your strategy demands.

Trew Knowledge helps organizations understand, reduce and keep managing that complexity over time. We bring together digital strategy, customer experience, architecture, data and integration, platform modernization, implementation and ongoing support to help turn fragmented environments into ones that are easier to understand, safer to change and ready for whatever comes next.

We can help you find where complexity is building up, where it’s holding back your priorities, and where modernization will make the biggest difference to how quickly you can change. Start a conversation with our experts.