Your Business Doesn't Have an Integration Problem. It Has a Data Problem.

Your Business Doesn't Have an Integration Problem.
It Has a Data Problem.

Most businesses don't actually need more integrations. They need to decide what their data means, where it lives, who owns it and what is allowed to change it.

I've lost count of how many times I've heard some version of:

“We just need to integrate these two systems.”

Sometimes that's exactly the problem.

Usually, it isn't.

The API isn't necessarily broken. The connector isn't necessarily bad. The developer hasn't necessarily done a terrible job.

The problem is often much less exciting:

Nobody has agreed what the data actually means.

The integration looks like the problem

Imagine a growing e-commerce business.

There's a website. An ERP or accounting system. Amazon. A marketplace. An email platform. A warehouse. A courier. An advertising platform. Maybe a CRM. Maybe a product information system.

Each system needs information from somewhere else.

The instinct is to connect everything.

So you get plugins. Middleware. Webhooks. Scheduled exports. CSV files. Custom scripts. Zapier-style automations. API calls. Someone's spreadsheet that everyone pretends isn't important.

Eventually, it looks something like this:

Technically, everything is connected.

Operationally, nobody knows what is going on.

The spaghetti doesn't start with APIs

This is the important distinction.

People often blame “spaghetti architecture” on bad integrations.

But integrations are usually just exposing an older problem.

Consider a product.

What is its name?

Is it the internal product name? The website title? The Amazon listing title? The warehouse description? The name used by finance?

What is its price?

Retail price? Sale price? Marketplace price? Price including VAT? Price excluding VAT?

What is its stock level?

Physical stock? Available stock? Allocated stock? Stock after a safety buffer?

Those sound like implementation questions.

They're actually business-definition questions.

Before you decide how data moves, decide what the data means.

One product should have one identity

One of the most useful ideas in integration work is deceptively simple:

Give important things a stable identity.

A product should have an internal identifier that doesn't change because somebody edits its title.

An order should have a stable order identifier even if it passes through three different systems.

A customer should not become three customers because three platforms happen to spell their name differently.

This sounds obvious until you inherit a real system.

Then you discover that one platform calls something SKU-123, another calls it 123, another uses a variation ID, another has an EAN, and somebody has been matching them by product title.

It works.

Until it doesn't.

Mapping is not architecture

One of the easiest traps in integration projects is building increasingly complicated mapping rules.

“If this field contains X, send Y to platform A. Unless the product is in category B. Unless it is a variation. Unless the marketplace is C. In that case use Z.”

After a while, you've built a second business inside the integration layer.

And nobody knows whether the rules describe the business or merely compensate for the fact that the systems disagree.

Mapping is useful.

But if every integration has its own interpretation of your products, customers and orders, you've created multiple versions of the truth.

The single source of truth is not always a single database

This phrase gets thrown around a lot:

“We need a single source of truth.”

Fine.

But which source?

Your website might be authoritative for content. Your ERP might be authoritative for accounting. Your warehouse might be authoritative for physical stock. Your marketplace might be authoritative for the status of an order once it has entered that marketplace.

The goal isn't necessarily one database containing everything.

The goal is something more useful:

For every important piece of information, you should know who is authoritative.

Once you've made that decision, the architecture becomes much easier to reason about.

Then the APIs become boring

And boring is good.

A well-designed integration shouldn't require everyone to understand every system.

If the warehouse changes how its API works, the rest of the business shouldn't suddenly need to change its understanding of a product.

If a marketplace changes its order format, that shouldn't redefine what an order means internally.

The integration layer should absorb those differences.

That's one of the reasons I like thinking in terms of domains and contracts rather than simply “connecting systems.”

The business says:

“This is an order.”

The marketplace says:

“This is what an order looks like to us.”

The warehouse says:

“This is what we need to fulfil one.”

Your system's job is to translate between those worlds without losing the meaning in the middle.

Good integrations also handle failure

This is where a lot of integrations fall apart.

People design the happy path:

Order created → API call → order imported → warehouse notified.

Great.

Now imagine the API is down.

What happens?

What if the request succeeds but the response times out?

What if you send the same order twice?

What if stock changes between the request and the response?

What if the marketplace accepts the order but your system doesn't record the acknowledgement?

What if the product exists in one system but not another?

What if somebody manually changes the data while the automation is running?

Those aren't edge cases.

They're Tuesday.

Idempotency: the unglamorous superpower

One of my favourite concepts in integration design is idempotency.

In plain English: doing the same thing twice shouldn't accidentally create two things.

If a job retries because a network request timed out, you don't want two identical orders.

If a webhook is delivered twice, you don't want two fulfilments.

If a scheduled sync runs again, you don't want duplicate records.

This is not exciting technology.

It is, however, the sort of detail that separates a demo from a system you can trust.

Observability matters more than people think

An integration that fails silently is worse than an integration that doesn't exist.

At least a missing integration is obvious.

A silent failure can sit there producing bad information for hours or days.

For anything business-critical, I want to know:

What ran? When did it run? What did it process? What failed? Why did it fail? Did it retry? Did the retry work? What is currently waiting?

You don't necessarily need a giant enterprise observability platform.

You need enough visibility to answer one simple question:

“Can I trust what happened?”

Technology should reduce cognitive load

This is the broader lesson I've taken from working across e-commerce and software.

Automation isn't valuable because it removes a click.

It's valuable because it removes something a person has to remember.

If someone has to remember to export stock every morning, that's cognitive load.

If someone has to remember which marketplace orders have already been imported, that's cognitive load.

If someone has to check three systems to understand why an order hasn't shipped, that's cognitive load.

Good systems remove that uncertainty.

The architecture I actually want

When I look at a messy integration landscape now, I don't start by asking:

“Which API should we connect next?”

I start with a different set of questions:

What are the important business objects?

Who owns each one?

What does each state mean?

Which systems need to know about changes?

What happens when something fails?

How do we know the system is behaving correctly?

Only then do I worry about the API.

The resulting architecture is usually much simpler.

Not necessarily fewer systems.

Not necessarily fewer lines of code.

Just fewer places where the meaning of the business can accidentally get lost.

And this is why “just integrate it” worries me

Integration work is often treated as plumbing.

Sometimes it is.

But at scale, integration architecture becomes part of the operating model of the business.

It determines how quickly you can launch a new channel. How safely you can change a product. How quickly you can recover from a failure. How much manual work operations needs to do. How confidently leadership can trust the numbers.

That's not plumbing.

That's infrastructure for decision-making.

The best integration is the one nobody notices

When everything works, nobody talks about the integration.

An order appears. Stock updates. A customer gets an email. The warehouse receives the right information. The marketplace gets the right status.

It just happens.

That's the point.

I've spent a lot of my career working in the space between systems: websites and marketplaces, software and operations, data and marketing, business requirements and technical implementation.

The biggest lesson is that the hard part usually isn't making two systems talk.

It's making sure they have something sensible to say to each other.

Good architecture doesn't just move data. It preserves meaning.

Once you get that right, the APIs become the easy bit.