Industry
Part of 9 pointers on software integrations that hold up
Native connector, export, or platform: picking a software integration shape
No ranking of software integrations tools for 2027. Decide the shape first: native connector, scheduled export, platform or code. Then run a build test.
The first question is not which connection tool to buy. It is whether you need one, because a large share of the connections organizations pay a platform to run could be a native connector somebody switched on, or a scheduled export nobody has to maintain.
No ranking appears here. What appears instead is a way to decide the shape of the answer, and then a build test that separates candidates in an afternoon rather than a quarter.
What to take away
- Count the connections you actually need. Under about five, a platform is usually the wrong answer.
- Native connectors first, scheduled exports second, a platform third, custom code last. Move down the list only when the one above genuinely fails.
- Evaluate by building the same real workflow in each candidate, including the part where it fails.
- The cost of a connection is not the build. It is who notices when it stops and who is allowed to fix it.
Decide the shape before the product
What it is
- Native connector
- A connection the two products already offer each other
- Scheduled export and import
- A file produced on a schedule and loaded elsewhere
- Connection platform
- A product that runs connections between many systems
- Custom code
- Something written against both interfaces
When it is right
- Native connector
- Almost always worth checking first, and often sufficient
- Scheduled export and import
- Reporting, backups, and anything that does not need to be immediate
- Connection platform
- Several connections, changing often, built by people who are not developers
- Custom code
- One connection that matters enormously and fits nothing else
Most organizations discover, after doing this honestly, that they need two native connectors and one nightly export. That is a good outcome and it is invisible to anyone selling a platform.
Four integration shapes compared
Native connector
- What it is
- Built-in link
- When right
- Check first
- Needs developer
- No
- Typical outcome
- Often sufficient
Scheduled export
- What it is
- Timed file transfer
- When right
- Reporting, backups
- Needs developer
- No
- Typical outcome
- Nightly job
Connection platform
- What it is
- Runs many links
- When right
- Many, changing links
- Needs developer
- No
- Typical outcome
- Invisible to sellers
Custom code
- What it is
- Written to interfaces
- When right
- One vital connection
- Needs developer
- Yes
- Typical outcome
- Fits nothing else
The build test
If a platform is genuinely the answer, evaluate it by building, not by watching. Pick one real workflow that somebody currently does by hand and construct it in each candidate.
Seven-step build test
- Build happy path, time it
- Break it with missing field
- Find the failed item
- Fix and replay one item
- Send same record twice
- Rename source field
- Hand workflow to colleague
Step five is worth more than the rest combined. A connection that produces duplicates under retry will eventually produce them at scale, and the property that prevents it is worth understanding rather than assuming: the plain definition of an idempotent operation is a good five minute read for anyone specifying this work without writing it.
Step seven is the maintenance test. A workflow only one person can read is a workflow with an expiry date attached to that person.
Questions the demonstration will not cover
- What happens when the source system is unavailable for two hours: does the platform queue, retry, or drop?
- How many times will it retry, and with what spacing?
- Where do failures appear, and can they be sent to a person rather than to a dashboard nobody opens?
- How is a run pricedper operation, per record, per connection, or per month?
- Whose credential does the connection use, and what happens when that person leaves?
- What does the platform do when the far end starts refusing requests because you are sending too many?
The last one is routine and worth understanding rather than hoping about, since a rate limit is a normal response rather than an error: the description of what a too many requests response means, and of the retry hint that comes with it, is enough to hold the conversation.
Questions demos skip
- Source down two hoursqueue, retry, drop?
- How many retries, what spacing?
- Where do failures appear, who is told?
- Priced per operation, record, connection, month?
- Whose credential, what if they leave?
- What happens when far end rate limits?
The credential question is the one that causes real incidents. A connection running under a departing employee's account fails at the worst moment, or worse, keeps working and gives that account a reason to stay open.
Interfaces you do not control
Every connection depends on an interface owned by somebody else, and those change. Ask each supplier what notice they give before a breaking change, whether old versions keep working during a transition, and where the change log lives. A supplier change log is the same evidence a software integrations review records for access, inputs, limits and export.
Then apply the same standard to whatever you build. Naming versions, documenting fields, and keeping a change log are the boring practices that make a connection survivable, and they are set out in a compact form in the published API and data standards used for public services. Where connections cross security boundaries, the security strategies for service based systems cover the authentication and authorization questions that a platform's default settings tend to gloss over.
What the decision usually comes down to
Three things, in practice. Whether the two products you actually care about already talk to each other, which makes the whole question moot. Whether the people who will build the connections can build them without a developer, which is the honest reason platforms exist. And whether anybody will notice when a connection stops. When the two products do not talk, an account administration comparison of incumbent against challenger settles the credential question.
What the decision comes down to
Do the two products already talk?
question is moot
compare account administration
That third one is the test nobody applies. A connection with no owner and no alert is a scheduled outage nobody has written down yet.
Where to read next
The category overview covers what connection work involves and where it goes wrong. If a platform looks like overkill, the simpler approaches applied to coordination make the same argument in a neighboring category: the honest answer is often a smaller one. And if the reason for connecting things is that work is scattered, the tracker configuration may remove the need entirely, while the administration layer is where the credential ownership question gets settled.
Common questions
Is a no code platform genuinely usable by non developers?
For the first workflow, yes. For the twentieth, the skills required look a lot like programming without the tools that make programming manageable, particularly around testing and version history. Plan for that rather than being surprised by it.
How many connections justify a platform?
There is no number that fits everyone, but the shape is: few connections that rarely change favor native connectors and exports; many connections that change often favor a platform. Volatility matters more than count.
Should connections run in real time?
Only where a person is waiting. Real time costs more, fails more often, and is harder to reason about. A great deal of what gets built as immediate could be hourly, and hourly is far easier to keep working.
What happens to our connections if we change the underlying product?
They break, all of them, and rebuilding them is usually the largest hidden line in a migration estimate. Keep an inventory from the first connection so that the answer to this question is a list rather than an afternoon of discovery.
