The seam between OT and IT is where industrial projects fail
Machines know what they just did. Business systems need to know it in a form they can act on. Almost every Industry 4.0 project I've seen struggles at exactly that boundary — here's why.
Every factory I have worked in already had data. Machines were logging cycle counts, alarms, temperatures, and part numbers long before anyone used the phrase "Industry 4.0". The data existed. What did not exist was a path from that data to anybody who could act on it.
That path crosses a boundary — operational technology on one side, information technology on the other — and that boundary is where projects quietly fail. Not at the PLC. Not at the ERP. At the seam.
Two worlds with incompatible assumptions
Operational technology optimises for determinism. A PLC scan cycle runs in milliseconds, every cycle, forever. It does not retry. It does not buffer politely while you deploy. Downtime is measured in money per minute, so the prevailing engineering instinct is: if it is running, do not touch it.
Information technology optimises for change. Services get redeployed, schemas migrate, APIs version, and the assumption is that anything can be restarted because something else will pick up the slack.
Put an engineer from each side in a room and they will agree on the goal within five minutes and disagree about everything else for the rest of the project. The OT engineer hears "we'll push an update" and thinks about a line stopping. The IT engineer hears "we can't change that" and assumes obstruction.
Neither is wrong. They are optimising for different failure modes.
What actually goes wrong
In practice, the failures are unglamorous and repeat themselves:
The data means something different on each side. A machine reports a part as "complete" when the cycle ends. The ERP considers it complete when it passes inspection. Nobody writes this down, so the two systems disagree by a few hundred parts a week and everyone blames the integration.
Nobody owns the middle. The automation team owns up to the PLC. The IT team owns from the database inwards. The gateway, the protocol translation, the buffering layer — the part that actually determines whether the project works — belongs to whoever touched it last.
The network was never designed for this. Shop-floor networks are flat, old, and full of devices that will fall over if you scan them. "Just expose an endpoint" is not a sentence that survives contact with a factory VLAN.
There is no plan for being offline. The link to the ERP will drop. The question is not whether, but what happens to four hours of production data when it does. If the answer is "it's lost", the business will stop trusting the numbers within a month — and once trust is gone, people go back to the spreadsheet.
What works
The projects that hold up share a few characteristics.
Buffer at the edge, always. The gateway stores locally and forwards when it can. This single decision converts a network outage from an incident into a delay. Everything downstream gets simpler when you can assume data eventually arrives.
Write down what each field means, in the plant's language. Not a schema — a glossary. What counts as a cycle. When a part becomes a part. What the operator does when a machine is in setup. This is boring and it prevents more problems than any technology choice you will make.
Make the flow observable before you make it clever. Before predictive anything, you need to be able to answer: is data flowing right now, from which machines, with what lag? If you cannot see the pipeline, you cannot debug it, and you certainly cannot build analytics on top of it.
Give the middle an owner. One person or one team responsible for the gateway, the translation, and the contract between the two worlds. The seam needs an owner more than either end does.
The unglamorous conclusion
The interesting part of industrial software is not the machine learning. It is getting a number out of a machine, reliably, in a form that means the same thing tomorrow as it did today, and keeping that true while the plant runs three shifts and nobody is allowed to stop the line.
Everything above that layer — dashboards, MES, predictive maintenance — is straightforward once the seam holds. And essentially impossible while it does not.
AI & Industrial Automation Engineer, based in Bengaluru, India. I build the systems that connect factory floors to business software — and take on freelance support and documentation work for developer-tool teams.