Integrating means making two systems exchange data reliably and repeatably. Automating means reducing the human effort of a task. When the manual work consists of copying information from one screen to another, the problem is integration — and automating the copying only hides the cause.
Below: how to tell the two problems apart, the options from most stable to most fragile, when the fragile one is right, the debt bad choices create, and the order that avoids rework.
There is a pattern that recurs in process diagnostics: somebody describes a task consuming hours and, on detail, it turns out to consist almost entirely of taking a value from one system and typing it into another.
The instinctive reaction is to automate that transcription. It works, and it leaves the reason it existed completely intact: two systems that ought to talk and do not. The symptom is treated and the cause is now harder to see, because the hours it used to cost have disappeared.
How to tell the two problems apart
The question that separates them is simple: if the systems exchanged data on their own, would any human work remain? If the answer is no, the problem is integration. If judgement, validation or decision remains, there is an automation problem as well.
The distinction matters because the solutions have very different lifespans. A well-built integration survives interface changes; an automation operating on screens breaks when somebody moves a button.
The options, most stable to most fragile
Native API. If both systems expose an interface, it is the right path: stable, documented and cheap to maintain. It should be ruled out only when it does not exist.
File exchange. A file deposited in an agreed location with a fixed format. Inelegant and surprisingly durable; it remains how many accounting and banking systems in the region are integrated.
Intermediate database. A shared space where one writes and another reads. It works, and it creates a coupling that has to be governed: two systems depending on the same table can no longer be changed independently.
Automation over the interface. The robot does what a person would. It is the right answer when none of the above is available, and unnecessary debt when one was.
When the fragile option is the right one
Worth saying plainly, because the usual discourse dismisses it on principle. Automating over the interface is the correct decision when the system belongs to a third party that exposes nothing, when it will be replaced within a short horizon and does not justify investment, or when the volume is so low that building an integration costs more than it saves.
What makes it a mistake is not the technique but using it by default. The question you have to be able to answer is: did an API exist and we did not use it? If the answer is yes, debt is being taken on knowingly.
The debt a bad choice creates
An interface-based integration accumulates three costs absent from the estimate. It breaks with every visual change to the source system. It needs credentials that rotate. And it leaves no useful trace: when it fails, what happened has to be reconstructed from screenshots rather than a log.
That last point weighs more than it appears in audited operations. An API exchange leaves evidence of what was sent and when; a robot that filled in a form leaves considerably less.
There is a fourth cost that only shows up at replacement time. When the integration is a robot driving screens, nobody ever had to write down what data actually moves between the two systems — the robot encodes it implicitly, in click order. Replacing either system then starts with reverse-engineering your own integration, and that archaeology routinely costs more than the original build.
Batch or event, and why it is not a preference
Once the mechanism is chosen there is a second decision that shapes everything downstream: does the exchange happen on a schedule or when something changes.
Batch is simpler, easier to reason about and easier to recover: if tonight fails, run it again tomorrow. It suits anything where the consuming side decides on a daily or weekly rhythm, which is most administrative processes.
Event-driven exchange sends the change as it happens. It suits cases where someone acts on the information immediately — a stock level a salesperson quotes from, a payment that unblocks a shipment. It costs more, because handling a message that arrives twice or out of order is now your problem rather than the schedule's.
The failure worth naming is choosing event-driven for a process whose consumers decide once a day. All the complexity is paid for and none of the benefit is collected, and the reason is almost always that real time sounded more modern in the design meeting.
The order that avoids rework
When a process needs both integration and automation, the order matters. Integrating first reduces the scope of what has to be automated, and sometimes eliminates it: a good share of candidate tasks disappear on their own once data stops moving by hand.
Doing it the other way round produces an automation sized for a problem that then changes. The robot copying between two screens loses its purpose the day the integration is built, and that work is discarded whole.
The reasonable exception is timing: if the integration depends on a third party and will take months, automating in the meantime is a legitimate decision — provided it is taken knowing it is temporary and recorded as such, rather than discovered two years later.
The pattern that decides maintainability
Whichever option is chosen, one design decision separates integrations that age well from those that do not: whether failure is visible.
An exchange that silently stops is the worst outcome available, because the organisation carries on believing the data is current. Both sides should be able to answer when the last successful exchange happened, and somebody should be told when that answer is older than expected.
It costs very little to build alongside the integration and is disproportionately expensive to add afterwards, because by then several consumers depend on data whose freshness nobody has been tracking.
How the decision is made with evidence
With an inventory of the exchanges people perform today: which value moves, from where, to where, how often, and what interfaces exist at each end. It is a table, not a project, and it answers most architecture questions.
That survey is part of a process automation assessment, which evaluates the technical feasibility of each candidate alongside its volume. From it comes what moves to automation and what should be resolved by integrating.
The business case is calculated with local costs: an hour of transcription saved is not worth the same in Bogotá, in Mexico City, or at a European head office.
Frequently asked questions
When is the problem integration rather than automation?
When the manual work consists of moving data between systems and no human task would remain if they communicated on their own. If judgement, validation or decision also remains, both problems are present.
Is automating over a system interface always wrong?
No. It is the right answer when no API is available, when the system will be replaced soon, or when the volume does not justify an integration. It is unnecessary debt when an interface existed and was not used.
Is file exchange still valid?
Yes. It is inelegant and very durable, and remains how many accounting and banking systems in the region are integrated. A fixed format and an agreed location resolve more than its reputation suggests.
Which comes first, integration or automation?
Integration, when both are needed. It reduces the scope of what has to be automated and sometimes removes it entirely. The exception is timing: if the integration depends on a third party and will take months, automating in the interim is legitimate if recorded as temporary.
What makes an integration age badly?
Failure that is not visible. An exchange that silently stops is the worst outcome, because the organisation carries on believing the data is current. Both ends should be able to report the last successful exchange.
What is needed to decide?
An inventory of the exchanges people perform today: which value moves, between which systems, how often, and what interfaces exist at each end. It is a table, and it answers most of the questions.
