I started my career as a controls engineer. My attention was on the PLC, the HMI and the equipment they needed to run. Did the sequence work? Could the operator understand what was happening? Could maintenance troubleshoot it at two in the morning? Those questions still matter. But over the years, answering them has pulled me further up the stack, into networks, servers, virtualization, cybersecurity and the applications connecting production to the rest of the business.

I’m no expert in every one of those areas. Working across them has mostly taught me when to ask questions and bring in someone who knows more than I do. In my last article, I explored how industrial automation is becoming a software discipline. That shift raises another question: After startup is complete and the project team moves on, who keeps all of this working?

Moving up the OT stack

For much of my career, the systems surrounding the PLC followed familiar patterns. We installed industrial software on Windows servers, often virtualized, connected the applications and worked through startup. There were plenty of complexities, but we generally knew where to look when something went wrong.

Now, some of the OT platforms we work with are adopting cloud-native architectures. Containers, orchestration and independently running software services that handle functions such as data exchange, authentication and monitoring are becoming part of environments that control engineers help deliver and support.

Despite the name, cloud-native doesn’t necessarily mean the application runs in the cloud. These architectures can live within the plant. But they change how software is deployed, how its components interact and what maintaining the environment involves.

I may understand what an application needs to accomplish for production without knowing every detail of its underlying platform. An infrastructure specialist may understand that platform thoroughly while needing help understanding why a routine change requires careful coordination with operations. That’s where the working relationship becomes essential.

The control system is healthy. So why isn’t the system working?

Imagine a plant six months after startup. Production is moving, the PLC is executing its logic and the HMI looks normal. But an application sending production information to a business system has stopped updating. The controls team confirms the controller is communicating. IT confirms the server is available. The application supplier asks whether anything changed on the network.

Meanwhile, operations is waiting for the information.

Maybe a certificate expired, a service stopped or a security change affected an account the application depends on. Finding the cause requires people who understand different parts of the same system. It also requires someone to follow the problem across those boundaries.

Confirming that each individual component is available doesn’t necessarily explain why the overall application isn’t working. These are the dependencies we need to understand before handing over a system. Otherwise, the customer ends up discovering the support gaps during an incident.

IT and OT need a working relationship

We’ve talked about IT/OT convergence for years. In practice, cooperation can still be limited to project checkpoints: approve the architecture, provide the servers, open the connections and help through startup.

As industrial software becomes more interconnected, that relationship needs to continue into daily operation.

OT understands the process and the consequences of interrupting it. IT brings experience with infrastructure, identity, security and managing software throughout its lifecycle. Both groups need enough understanding of the other’s responsibilities to work through decisions together. An update might make sense from a security standpoint but require a production outage to implement.

Delaying it might preserve today’s production schedule while creating a growing support or security problem. Those decisions need a conversation about the actual plant conditions.

The practical questions are straightforward. How will we know a service has stopped working? Who maintains its credentials? Where do we test an update? If it fails, how do we recover? Those conversations belong in project planning, while the people designing the environment are still at the table.

Where integration partners can help

Manufacturers are building teams to support these environments, but that takes time. Hiring one person doesn’t automatically cover controls, networking, infrastructure, application development and software operations. Systems integration partners can help customers navigate that gap. Doing so requires a closer relationship than delivering a project and waiting for a support call.

At BW Design Group, one capability we bring to that relationship is a dedicated Industrial DevOps practice. It gives us specialists who can work through the deployment and ongoing operation of industrial software platforms alongside our controls and infrastructure teams.

For someone with my background, having that expertise available matters. I can bring the process requirements and operational concerns into the conversation, then work with colleagues who understand how to support the platform behind the application.

Together, we can help customers establish ways to monitor systems, manage changes and recover from failures while they develop their internal capabilities. We can also help define which responsibilities the customer is ready to take on and where continued partner support makes sense. That arrangement should evolve as the customer’s team develops.

A better handoff starts before commissioning

Commissioning will always be an important milestone. Getting equipment running reliably takes real effort, and nobody who has lived through startup takes that lightly. But a successful startup doesn’t answer every question about the years that follow.

Along with the application, drawings and training, the customer needs to understand how the environment will be supported. That includes ownership, access, monitoring, updates and a workable path for bringing IT, OT and integration partners together when needed.

Seeing the technology stack evolve, especially in recent years, has changed how I think about project delivery. I still care whether the sequence works and whether maintenance can troubleshoot it at two in the morning. Now I also want to know who they’ll call when the PLC is running perfectly and the problem is somewhere else.