Integration platform instead of point-to-point interfaces
IT/OT integration rarely fails on the technology of a single connection, but on its multiplication. As long as machines, MES, ERP, and analysis systems are wired together one by one, the number of connections to maintain grows quadratically. A shared integration layer turns that into one connection per system — and moves the work from development into configuration.
What it is about
In almost every grown production landscape, the same participants are present: controllers and SCADA on the shop floor, an MES for manufacturing execution, an ERP for orders and materials, a historian for trends, plus IIoT sensors and analysis systems in the cloud. Each of these systems makes sense on its own. The problem arises in between.
Because every requirement — a new metric, another plant, an additional analysis system — becomes a question of how many of these systems have to be opened, changed, and signed off again for it. An organization is only as agile as its hardest-to-change interface.
This is not a question of project methodology. Anyone who delivers every two weeks but sets up an integration project for every new data source is not fast — they are only regularly slow.
The math behind it
The difference between the two approaches is not a matter of taste, but of arithmetic. When systems are directly coupled, the number of connections grows quadratically with the number of systems; via a shared layer, it grows linearly.
| Connected systems | Point to point | Via a shared layer |
|---|---|---|
| 4 | 6 connections | 4 connections |
| 6 | 15 connections | 6 connections |
| 10 | 45 connections | 10 connections |
| 15 | 105 connections | 15 connections |
These numbers are not an estimate but combinatorics: n × (n−1) ÷ 2 versus n. Whether a given landscape is affected can therefore be answered without a study — it is enough to count your own systems. And every one of these connections has an author, a documentation gap, and an end date when that author leaves the company.
What actually slows things down
- Every source is a special case. Where connections are built individually, every requirement starts with specification and development instead of configuration.
- Change windows. In operational technology, changes are not made during production. Anything requiring an intervention in the line waits for the next scheduled downtime.
- Responsibilities. A change that affects IT, OT, and the plant at once takes as long as the slowest approval.
- Missing reuse. The second site starts from zero because the first was not built as a template.
- Dependence on individuals. If only one person knows the coupling, their calendar is the critical path.
The same requirement, two paths — the difference lies in the steps that are eliminated.
Four levers that actually change things
-
Decouple
Sources and consumers no longer know each other directly, only via a shared layer. A new target system then no longer touches any controller.
-
Configure instead of develop
Standard connectors and a maintained structural model shift work from development into setup — and thus out of the project and into operations.
-
Template instead of one-off
The first site is built so that the second is a copy. This costs time in the first project and saves it from the second onward.
-
Visibility
What is monitored may be changed. Without operational visibility, every change becomes a risk decision and therefore slow.
Change scenarios compared
| Scenario | Individual integration | Via a shared layer |
|---|---|---|
| New machine in an existing line | specify, develop, test, sign off an interface | set up a connector, place it in the model, release it |
| New target system (e.g. analytics) | one connection per source | subscribe once, sources stay untouched |
| Additional site | project from scratch | copy the structure, add sources |
| Changed metric | change in every system involved | definition in one place |
| Vendor change | rebuild the coupling | swap the target, structure stays |
The switch is more expensive in the first project. It pays off from the second comparable requirement onward — and anyone who never has a second one does not need it. So the question is not whether a shared layer is better, but how many connections are realistically going to be added over the next five years.
Where flexibility has to end
Agility is not an end in itself. Three limits remain:
- The plant takes priority. No data path justifies an intervention that endangers production availability.
- Security zones stay closed. Network segmentation is not loosened for the sake of speed — see secure data flows.
- Naming stays stable. Structure that keeps changing is not structure. It is the content that is flexible, not the organizing principle.
How pronubes shortens response time
- pronubes Edge connects new sources via standard connectors — OPC UA, MQTT, REST, SQL, file formats — without touching the controller.
- pronubes Zones holds the structure that turns a rollout into a copy instead of a rebuild.
- pronubes Insights shows what actually flows before and after a change — the prerequisite for taking responsibility for changes without a downtime window.
The result is not a faster IT, but one with fewer steps.
More about the platform
- Decoupling
- Separation of source and consumer via a mediating layer, so that changes on one side do not affect the other.
- Point-to-point integration
- Direct coupling of two systems for a specific use case; the number of connections grows quadratically with the number of systems.
- MES
- Manufacturing Execution System: controls and documents production between the ERP order and the machine.
- Time to market
- Time from the business idea to productive use — in production landscapes usually determined by integration effort.
- Change window
- Planned downtime during which interventions on plant equipment are permitted.
- Standard connector
- Prebuilt, configurable connection to a system type — as opposed to an individually developed interface.
- Store & forward
- Buffering data when a connection is interrupted and delivering it once the connection is restored.
Frequently asked questions
Isn’t this simply another system that needs to be maintained?
Yes — one instead of many individual connections. The comparison is not “a layer versus nothing,” but “one operated layer versus a growing number of self-built couplings with no fixed owner.”
How quickly is a first productive use case ready?
That depends on the number and condition of the systems to be connected. A reliable estimate only becomes possible after reviewing the actual landscape — which is exactly what the 30-minute architecture conversation is for.
Does production have to stop for this?
Usually not. Data capture happens by reading through existing interfaces. A downtime window only becomes necessary when something has to change on the controller itself — that is the exception, not the normal case.
What if we only have one plant?
Then the benefit is smaller, but not zero: connections add up even within a single plant. The honest answer is that the effort pays off from the second comparable requirement onward — whether that comes is something you know better than any calculation.
Does this tie us to one vendor?
The data stays reachable via open protocols, the structure is documented, and the same values can be delivered to a different target system without a rebuild. This requirement belongs in the tender — with every vendor.
An integration platform instead of point-to-point interfaces.
30 minutes about your system landscape: how many individual connections exist today and how that can be consolidated.
pronubes is a product of inray Industriesoftware GmbH. Over 30 years of industrial software from Germany. Innovative and reliable for manufacturing companies.
