Systems that exchange data are connected. An operation is integrated when it behaves as one.
A truck pulls up to the gate of a busy plant. The camera reads the plate. The barrier opens. The yard system assigns a slot. The ERP shows an open purchase order for the delivery. A dock terminal lists a loading task.
Every one of these systems is working. Every one is connected to the others.
Then the driver is stopped at the yard entrance. The yard system says the truck has been admitted. The ERP shows the delivery as pending approval. The dock terminal has no record that the truck has arrived. A marshal calls the dispatcher. The dispatcher calls a supervisor. Someone decides, by phone, to let the truck through.
This is an illustrative scenario, not an account of any specific company or customer.
Nothing failed. Each system did what it was built to do. But the operation asked a simple question, where is this truck and what should happen to it, and received three different answers. A person had to settle the disagreement.
This article is for the operations or IT leader who has connected their systems and still finds people bridging the gaps by phone and by hand.
Connection moves data. Integration aligns the operation.
Two systems are connected when one can send data to the other, through an interface, an API, a file transfer or a message queue. That is a real achievement, and it is often necessary.
An operation is integrated when its systems, equipment and people behave as one. They share the same definitions, follow the same rules, know who owns each decision, agree on what to do when something goes wrong.
A connection can be complete while integration is not. The European Interoperability Framework, written to guide public services in Europe, offers a useful way to see why. It describes four layers of interoperability: legal, organisational, semantic and technical. The technical layer covers the applications and infrastructure that link systems and services. The semantic layer is about preserving the format and meaning of data as it moves between parties. The organisational layer covers processes, roles, responsibilities and decision making.
The framework was designed for public services, not plants, and we borrow only its layering. The layering travels well. A connection is a technical-layer achievement. The questions that decide whether an operation runs smoothly often sit in the semantic and organisational layers.
Where connected systems still disagree
These are the failure points we look for first. They are not findings from a survey of companies.
Identity. Does every system mean the same thing by "this truck"? One system may identify it by plate, another by driver, another by trip or purchase order. If the identifiers do not map cleanly, the systems hold records about the same vehicle that never meet.
State. What state is the vehicle in, and which system owns that status? Arrived, admitted, queued, at the dock, loaded and released can each be defined differently in different systems. This is the semantic layer at work.
Sequence and timing. Which events must happen before others, and what happens when a message arrives late or out of order? A system that assumes events arrive in order will fail the first time they do not.
Rules and ownership. When two systems conflict, which one decides? If the rules live separately inside each system, nobody owns the answer except the person on the phone.
Failure behaviour. What happens when one connected system is unavailable or wrong? Does the operation continue, continue with limits, or stop? If nobody defined it in advance, the guard decides on the day.
Each of these questions is about meaning and responsibility. None of them is about connectivity.
When integration is missing, people become the integration layer
We described this pattern in The Operational Mistakes That Keep Complex Businesses Running Below Their Potential. Someone makes the call. Someone keeps the spreadsheet. Someone confirms what another system should already know.
In Your Best Employees May Be Hiding Your Biggest Operational Problems we argued that these workarounds are a map of where the official systems fail to give people what they need. A set of connected systems that still needs a person to carry information between them is telling you exactly where the integration stops.
The effect can stay hidden for a long time. From the outside the operation looks integrated, because capable people absorb every gap.
Why this is an engineering problem, not a product problem
Software vendors build good products. Each usually does its own job well. The integration question sits between the products. It lives in how they define identity, how they handle failure, how the hardware and network behave, and how people use them. No single product owns that space, which is why it is easy for nobody to own it.
That is the gap a systems integrator exists to close. The work spans hardware, software, networks, processes and people, often from several manufacturers. The accountability is for the operation working as one, not for any single component.
It also changes the first question. A product vendor asks how its product will connect to yours. An integrator asks what the operation needs to know, decide and do, and which combination of technologies delivers that. Both roles matter. They answer different questions.
How this shapes The Bridge
The Bridge is our gate and yard management platform, and it is under active development. We are describing design principles here, not results from a completed deployment.
Each principle answers one of the disagreements above.
- One owner for identity and state. Every vehicle visit follows a single lifecycle, from arrival to exit, managed by one central service. Devices and other systems report events to it. They do not hold competing versions of the truth.
- Validation in one place. Terminals and other devices are input points. The rules are enforced centrally, so they cannot be bypassed at the edge. Physical sensor data must also corroborate what a person enters.
- Standalone first. The site is designed to operate at full capability without depending on external platforms. Integration with enterprise systems is an enhancement layer, not a condition for the gate to work. We set this out in 5 Principles That Shape How We Engineer.
- Exit gated on process completion. The platform is being built so that a vehicle leaves when its process is complete, not only when its pass matches. We made the argument for this in The Factory Gate Is Not a Security Problem. It's an Operations Problem.
- Failure behaviour as a requirement. For every connected system, we treat the answer to "what happens when it is unavailable or wrong?" as a requirement to define and test, not a side effect to discover in operation.
None of this is exotic. It is the work of making sure that when systems meet, the operation still knows what is true.
Five questions to ask before calling a system integrated
- When two systems disagree about the state of the same thing, which one wins, and who decided that?
- Do all systems use the same identifier and the same definition of each status?
- What happens to the operation when one connected system is unavailable?
- Which tasks still need a person to move information from one system to another?
- Can we follow one event across every system on a single timeline?
If the honest answers expose gaps, that is useful. It shows where the next piece of engineering effort belongs. It is usually cheaper to find out now than during a busy shift.
Connection is a start
Connecting systems is a technical achievement. Integrating an operation is an engineering responsibility: deciding what is true, who decides, and what happens when the systems disagree. When that work is done, people stop acting as the integration layer and go back to running the operation.
If your systems are all connected, where do people still carry information between them: identity, status, sequence, exceptions or approvals?
Not sure where your integration stops?
A Tennxt engineer walks one process with your team and delivers a written findings report. No cost. No sales presentation.
Further reading:
- The Factory Gate Is Not a Security Problem. It's an Operations Problem.
- Your Best Employees May Be Hiding Your Biggest Operational Problems
- The Operational Mistakes That Keep Complex Businesses Running Below Their Potential
- 5 Principles That Shape How We Engineer
- The Difference Between Visibility, Control and Intelligence in Complex Operations
Sources:
- European Commission, National Interoperability Framework Observatory, "Levels of interoperability" (European Interoperability Framework: legal, organisational, semantic and technical layers)
The framework was written for European public services. We use its layering as a concept, not as evidence about industrial operations. The gate scenario above is illustrative, and The Bridge is described by its design principles, not by deployment results.
Joshua Otomo is Founder and Chief Executive Officer of Tennext Core Ltd (TENNXT), an enterprise systems integrator focused on intelligent software, industrial automation and operational analytics. He writes about how large organisations get technology projects right and, more often, why they don't.
Contact: hello@tennxt.com · www.tennxt.com
