← Back to Blog
Data Architecture Methodology4 min read2 August 2026

Seven integrations, one destination, one method. That is a consolidation waiting to happen.

Seven integrations at one destination, all using the same method. Each one, viewed alone, is fine. The redundancy only becomes visible when you inventory by method and target together.

Scott Dudley

Scott Dudley

Data Architect · PRISM Methodology

On an assessment a while back, I catalogued the integrations feeding one particular system. Seven of them. All arriving at the same destination. All using the same method to get there.

Nobody had ever noticed, because nobody had ever listed them side by side. Each one had been built at a different time, by a different person, for a different immediate reason. Each worked. And because each worked, nobody went looking for the pattern.

This is how estates accrete. Not through bad decisions, but through a series of reasonable local decisions that nobody ever steps back to see as a whole. Someone needs data flowing into the system, they build an integration, it works, they move on. Do that seven times over three years and you have seven things where you could have had one.

The cost of seven is not seven times the cost of one. It is worse than that. Seven integrations are seven things to monitor, seven things to test when the destination changes, seven things that can each fail in their own way, and seven things someone has to understand before they can safely touch any of them. The maintenance burden compounds because the seven are subtly different, built by different hands, documented to different standards, or not at all.

And then a migration comes along. Now those seven redundant paths are seven separate cutover risks. Seven things to move, seven things to validate, seven chances for one of them to be the one nobody remembered until it broke. A single shared integration would have been one move and one validation.

The consolidation is usually straightforward once you can see it. One reusable integration, parametrised for the seven cases that currently each have their own copy. One thing to maintain. One thing to test. One thing to migrate. The seven collapse into a single job with seven configurations, and the maintenance surface shrinks accordingly.

But here is the point that matters more than the fix. You cannot consolidate what you cannot see, and you cannot see this pattern from inside any one of the seven integrations. Each one, viewed alone, is fine. The redundancy only becomes visible when you inventory the integrations by method and destination together, and look at the result as a whole.

That is what a structured assessment does that a diagram does not. A diagram shows you seven lines arriving at a box. An inventory that records the method and the target for each one shows you that the seven lines are the same line, drawn seven times.

The seven integrations were never the problem. Not seeing that they were seven was.

Ready to see your architecture in three dimensions?

Start with a conversation about your engagement.

Start a Conversation