Integration over technology replacement: Why interoperability is the real challenge

Whether a system becomes a problem depends less on its age than on the operational dependencies around it

In control centers, we often see systems that have been operating reliably for many years. That alone is not a reason to replace them. 

Problems arise where more and more interfaces, workarounds, and manual handovers have been added over time. As long as everything works, these dependencies often remain largely unnoticed in day-to-day operations. They usually become visible only when something needs to change: a system is replaced, a new data source is added, or new security requirements need to be implemented. 

That is when it quickly becomes clear how closely systems, data, and processes actually depend on one another. So the key question is not: Which system do we replace first? Much more important is understanding how the individual systems need to work together so that operations continue reliably throughout the change. 

An interface alone does not create interoperability

Today, many systems can be connected technically. But that does not automatically mean the information can be used effectively in operations. A video feed, an alarm, and operational information may be technically connected and still remain separated across different applications and workflows. 

For employees, this often means searching for information, entering it again, or comparing it across multiple systems. For me, interoperability therefore goes beyond data exchange alone. Information needs to be available where it is needed, in the right context and at the right time. Only then can different sources of information form a shared operational picture and an end-to-end workflow. 

A lack of interoperability often becomes visible only during change

Many dependencies have become part of everyday operations over the years. Typical examples from projects include:

• Information is transferred manually between several applications.
• Different systems show different information states.
• Small technical changes require adjustments to several other systems.
• Maintenance and security measures become increasingly complex.
• Interfaces have evolved over time and are only partially documented.
• Important dependencies are known only to individual employees.

As long as the environment remains stable, many of these issues can be compensated for. The problem often emerges with the next change. If nobody knows exactly which systems depend on one another, even a small adjustment can have unexpected effects on other parts of the control room. 

That is why, for me, analyzing these dependencies belongs at the beginning of every modernization project. 

Not every existing system needs to be replaced

Modernization does not automatically mean replacing existing systems completely. In many projects, it makes more sense to continue using components that work well and focus on the areas where actual risks or unnecessary complexity arise. 

That may mean standardizing a critical interface, automating a manual handover, or replacing a single system whose lifecycle has become a risk. The operational benefit should always be the deciding factor. Replacing a system simply because a newer technology exists does not automatically improve operations. 

Clear structures make future changes easier

Interoperability is not a one-time integration task. Control centers continue to evolve. Systems are expanded, requirements change, and new sources of information are added. 

The more clearly interfaces, responsibilities, and technical dependencies are structured and documented, the easier future changes become. That is why we do not look at architecture, integration, and operations in isolation. A technically sound integration is of little value if it creates new operational dependencies or only works with additional manual effort. 

Understand dependencies before changing systems

From my perspective, this is one of the most important principles of successful modernization: Before systems are replaced or new technologies are integrated, the existing dependencies need to be understood. 

Which systems are connected? Where do knock-on effects arise? Which components can continue to be used without issue, and where is action genuinely required? Once these questions can be answered, modernization steps can be planned more precisely and risks assessed more effectively.