Vendor lock-in does not start with the license agreement – it starts when your production knowledge is locked inside proprietary applications

KNOWLEDGE | Industrial Data

When people talk about vendor lock-in, the discussion usually revolves around vendors, licensing costs, proprietary interfaces or expensive migrations.

All valid concerns. But doesn’t the actual dependency start much earlier?

Namely when a company can no longer explain what its own production data actually means independently of a specific system. Sounds trivial, right?

In reality, however, we see exactly this again and again. A signal comes from the PLC. One application interprets it as a machine state. Another system calculates OEE from it. The historian may contain filtered raw values, sometimes with additional calculations. More logic sits inside the MES. Reporting looks at the same data from yet another perspective.

And at some point, nobody really knows anymore:

Where is the actual truth?

By Martin Waßmann – IT/OT Experts

Production data is not automatically information

A value such as "1" is initially just a value. It only becomes information through context – its meaning and the conditions surrounding it.

For example:

• Machine is running
• Order is active
• A fault is present
• Changeover is in progress
• Material is missing
• The line is waiting for a downstream process

The problem is obvious:

This context often does not exist in the data itself, but somewhere inside an application:

• perhaps inside a proprietary system that ties you in through multi-year licensing costs,
  • with interfaces that are time-consuming and expensive to develop,
  • and, in the worst case, a system that is not even well suited to solving your actual problem,
• perhaps inside a SQL query,
• perhaps inside an MES,
• perhaps inside a dashboard,
• perhaps inside an Excel file,
• or inside the head of an employee, team or system integrator who implemented the solution five years ago.

As long as the system keeps running and nobody wants to change anything, this may hardly be noticeable. Then it suddenly becomes interesting – and expensive.

Lock-in often becomes visible only when something changes

For example when another production line or another plant needs to be connected.
Or another application needs the same data.
Or the MES is replaced.
Or a company suddenly wants to use production data for AI or machine learning.

Then the questions start:

What does the tag DB42.DBX17.3 mean?

• What unit does this value use?
• Is it an instantaneous value or an average?
• When exactly is the machine considered “Running”?
• How are micro stops handled?
• Which signals actually belong to this asset?
• Which logic was used to calculate OEE?

And last but not least:
Who knows?

If the answer is:
“It is somewhere in the MES.”

or:

“Our system integrator probably knows.”

then dependency already exists.
Regardless of which vendor’s name is on the system.

Vendor-neutral means: production knowledge must not disappear inside proprietary applications

Of course, companies can and should use commercial systems. MES, historians, SCADA, analytics and BI all have their purpose. It becomes problematic, however, when the application also becomes the place where knowledge about production is locked away.

If only the MES knows when a machine is actually producing.
If the calculation of a KPI exists exclusively inside the historian.
If only a proprietary data structure describes which machine belongs to which production line.
Or if a new application first has to rebuild the logic of an existing system just to understand the same data.

That is exactly where vendor lock-in begins.

For me, vendor-neutral therefore means more than simply being able to choose between different vendors. It means that the fundamental description of production does not belong to a single vendor or a single application.

This includes, among other things:

• Data models
• Machine and asset structures
• Semantics
• Units
• States
• Calculation logic
• Relationships between assets
• Quality information
• Time context
• Data validity

This information should, wherever possible, be open, standardized and available independently of the applications currently using it.

An MES may consume it.
A historian may store it.
A dashboard may visualize it.
An AI application may use it.

But none of these applications should be the only place where its meaning exists.
Because if I first need a proprietary system in order to understand my own production data, I am already dependent.

The same knowledge is often built multiple times

The next problem follows directly from this. Many companies recreate the same logic several times. The MES defines a machine state. An OEE application defines it again. Another version is built inside the data lake. And for the next AI project, a data scientist once again starts by trying to understand the raw data.

Eventually, five different versions of the same truth exist.
And every application has to be maintained.

That is expensive.

But there is an even bigger problem:

The results can differ from one another.

Suddenly, people are discussing which OEE figure is correct instead of discussing why the production line is not achieving its expected performance.

Data should carry as much of its meaning as possible

This is exactly why I believe a different approach makes sense: production data should not simply be transported. It should carry as much of its context and meaning as possible with it.

Ideally, an application should not first require six months of reverse engineering before it can work with production data.

When a new application accesses a machine, it should be able to understand as quickly as possible:

• What kind of asset is this?
• Which signals exist?
• What do they mean?
• Which units are used?
• What state is the asset currently in?
• How current is the data?
• Is the data valid?
• What relationships exist with other assets?

In my view, this is one of the fundamental objectives of a modern industrial data architecture.

And this is exactly where concepts such as a Unified Namespace (UNS) become interesting.

Not because MQTT automatically solves all these problems. It definitely does not.

But because data, structures and context can be decoupled from individual consuming applications.

A UNS does not automatically prevent vendor lock-in

This is an important point.

You can also build a bad UNS.

If topics are unstructured, definitions are missing and every data producer does whatever it wants, all you have created is a new kind of chaos.

Only this time it runs over MQTT.

For me, a UNS is therefore not a product. It is an architectural principle.

And that principle only works if some fundamental questions are answered first:

• Which data is actually required?
• How are assets structured?
• Which semantics are used?
• Who is responsible for the data?
• Which logic belongs where?
• How are changes controlled?
• How is data quality made visible?

Technology comes afterwards.

Four questions we ask customers

If you want to understand how dependent your production data really is on individual systems, you can start with four simple questions:

1. Can I explain what my production data means without opening the application that currently uses it?

2. Can a new application use the same data without rebuilding the entire logic?

3. Can I replace a system without losing semantics, calculations or production knowledge?

4. Is it clearly defined who owns the data models, machine states and calculation logic?

Four “no” answers are, in my view, far more critical than an expensive software license. Even a single “no” already points to a significant problem.

The real objective is not less software

Companies will continue to use MES, historians, SCADA, BI, cloud platforms and specialized applications. And they should!

The goal of a sensible data architecture therefore cannot be to eliminate all of these systems.

The goal must be to avoid making the meaning of production data dependent on those systems.

Then a historian can simply be a historian.
An MES can simply be an MES.
An AI application can access the same data.
And if a better application becomes available tomorrow, the company does not have to start from zero again.

That is the decisive difference for me.

Vendor-neutral does not mean having no vendors.

It means:

The knowledge about my production still belongs to me.

What does this look like in practice?
In our case studies, we show how production data can be structured, standardized and made usable across different applications.

→ Explore our case studies

Frequently asked questions

What does vendor lock-in mean for production data?
Vendor lock-in occurs when production data, its meaning or the associated logic is so tightly bound to a specific system that other applications cannot use it without additional effort. It becomes particularly critical when semantics, machine-state logic, calculations or data models exist exclusively inside proprietary applications.

How can vendor lock-in in manufacturing be reduced?
Through open interfaces, open standards and a data architecture in which production data and its context are made available independently of individual applications. Systems such as MES, historians, BI or AI should be able to consume the data without becoming the only place where its meaning is defined.

Is a Unified Namespace automatically vendor-neutral?
No. A UNS can significantly reduce dependency on individual applications if data models, semantics and structures are clearly defined. A poorly structured UNS without governance, however, can simply create another technical dependency or a new data silo.

Do companies have to stop using proprietary software?
No. Proprietary systems can still be used where they provide value. The important point is that fundamental production knowledge such as asset structures, semantics, machine states and calculation logic should not exist exclusively inside those systems.

Why is this particularly important for AI and analytics?
AI and analytics applications need more than raw data. They require understandable and reliable information. Data altered through filtering or deadband processing can also become problematic. If meaning, units, states or relationships between assets are not clearly available, this context has to be reconstructed again for every new project.

How can I tell whether my company already has vendor lock-in?
A clear warning sign is when a new application cannot understand production data without help from the existing vendor or system integrator. The same applies if replacing a system would also mean losing data models, calculation logic or knowledge about machine states.

About the author

Martin Waßmann is the founder of IT/OT Experts and supports manufacturing companies with digital strategy, IT/OT integration and scalable production data architectures. His focus areas include brownfield integration, Unified Namespace, MQTT and OPC UA.

Learn more about Martin Waßmann