“Integration” has become a vague word in software.
Companies often say:
“We need all our systems integrated.”
But that's rarely the real requirement.
Most businesses don't need every system to know everything about everything.
They need the right information to move between the right systems at the right time.
More Integration Isn't Automatically Better
Imagine a business with:
CRM
Accounting software
ERP
Website
Customer portal
Internal application
Marketing platform
It is tempting to connect everything.
But every connection creates another dependency.
If System A depends on System B, and System B depends on System C, changes become harder to manage.
A large network of integrations can become its own legacy system.
Start With Information, Not Systems
Instead of asking:
“How do we integrate these two applications?”
Ask:
“What information needs to move?”
For example:
A website might need to send a new enquiry to the CRM.
The CRM might need to send customer status to another application.
The accounting system might need an invoice reference.
The internal application might only need a daily summary.
Those are much clearer requirements.
Real-Time Isn't Always Necessary
Another common assumption is that everything needs to happen instantly.
Often it doesn't.
If a report only needs to be updated once every night, a nightly process may be perfectly adequate.
If customer information needs to appear within a few minutes, near-real-time may be appropriate.
Real-time integration can introduce additional complexity.
Use it when the business actually needs it.
Not because it sounds more advanced.
Decide Who Owns the Data
This is one of the most important questions in integration work.
If both systems can modify the same customer information, which one is correct?
If an address changes in two places, which update wins?
If a record is deleted, what happens elsewhere?
If an integration fails, how do you know?
Integration isn't just about moving data.
It's about defining responsibility.
Good Integrations Are Boring
A good integration should usually be predictable.
Information moves where it is supposed to.
Failures are visible.
Duplicates are handled.
Changes can be traced.
Someone understands how it works.
Nobody needs to manually check it every morning.
That's much more valuable than building a complicated integration architecture that nobody wants to touch.
Don't Integrate for the Sake of Integration
Before building an integration, ask:
What business problem does it solve?
What information actually needs to move?
Which system owns that information?
How often does it need to move?
What happens if the transfer fails?
Who needs to know about the failure?
Once those questions are answered, the technical solution usually becomes much clearer.
The goal isn't to make systems talk more.
It's to make the business do less unnecessary work.