Do We Actually Want DevOps in the Factory, Or Does It Just Sound Good?

I keep hearing the phrase “we need DevOps on the factory floor,” and every time it comes up in conversation I find myself wanting to slow things down rather than speed them up, because before we adopt anything, especially something that originated in enterprise IT, we should be very clear about what it actually means in practice. We need to be asking whether we are solving the right problem, or whether we are importing terminology that feels modern without fully understanding the operational implications.

In IT, DevOps was never primarily about Kubernetes, CI pipelines, or dashboards, even though those tools often get bundled into the story. At its core, DevOps is an ownership model. The team that builds the software owns it in production. They are responsible for availability, performance, resilience, and support. Not as a final escalation point after three handoffs, but as the first call when something breaks.

That model makes a lot of sense in organizations that genuinely write and evolve their own business-critical systems. If you build the payment engine, the booking system, or the analytics platform, then it is entirely reasonable that you are accountable when it fails. You have the source code, you understand the design decisions, and you can instrument and iterate on it as needed.

Now compare that with what is actually running in most industrial environments.

The Industrial Reality: Vendor Software and Ownership Gaps

In that environment, what exactly does DevOps mean?

Walk through a modern plant and you are far more likely to encounter commercial software than internally developed applications. You will see systems such as Ignition, Litmus Edge, Softing dataFEED, MaintainX, or Tatsoft FrameworX running on servers or edge devices. These are not applications written by an in-house development team that lives inside the codebase. They are vendor products with their own release cycles, their own support models, and their own architectural constraints.

If Ignition has a module issue, are your engineers stepping through the vendor’s core code and issuing patches, or are they opening a support ticket? If a Litmus upgrade introduces unexpected behavior, are you rolling back via a Git commit that changes your own code, or are you coordinating with the vendor and planning a controlled downgrade? In most plants, the answer is obvious. You do not own the source, and you are not rewriting core functionality at 2 a.m. to restore production.

That distinction matters, because DevOps assumes ownership of the application lifecycle, not just ownership of the server it runs on.

What most factories actually need is not DevOps in the purist sense, but disciplined deployment automation. They need repeatability, consistency across sites, reduced configuration drift, and a way to make changes without introducing human error. That is a very real requirement, especially as Industry 4 modernization projects scale from one pilot line to multiple facilities across regions.

Deployment automation says we want to install and configure vendor software in a consistent way, we want environments that look the same in Plant A and Plant B, and we want documented, auditable change processes. It does not say that we are going to adopt a full “you build it, you run it” culture for code we did not write.

Even GitOps, which often gets presented as the natural extension of DevOps, needs to be examined through this lens. Tools such as Argo CD and Flux provide a clean model in which the desired state lives in Git and the runtime environment continuously reconciles itself to match. In a SaaS company optimizing for speed, that is elegant. A commit lands, the cluster updates, and the system converges automatically.

Now place that model inside a factory that runs twenty-four hours a day and has tightly scheduled maintenance windows. An automatic reconciliation that upgrades a critical service mid-shift may be technically correct, but operationally unacceptable. In many industrial environments, changes need to align with planned downtime, line changeovers, or explicit management approval. The concept of continuous, autonomous deployment can clash directly with the risk tolerance of the plant manager.

That does not mean automation is wrong. It means the trigger model matters. You might still define desired state in version control and use automated pipelines to execute changes, but you gate execution behind an external approval that aligns with operational reality. Automation, yes. Blind reconciliation, probably not.

Being Honest About Which World You’re In

There are, of course, industrial contexts where a true DevOps model makes sense. If your organization builds its own data pipelines, custom dashboards, proprietary optimization logic, or machine learning models that drive production decisions, then the team that creates those assets should absolutely own them in production. In that scenario, DevOps is not theater. It is accountability.

The key is being honest about which world you are in.

If your plant primarily deploys vendor products and integrates them at the configuration level, then what you are solving for is lifecycle management and deployment consistency. If you are building and evolving core logic that differentiates your operation, then DevOps becomes relevant as an organizational model.

Before we declare that “the factory needs DevOps,” it is worth asking a few direct questions. Do we actually write and maintain the software that runs our production environment? Who is accountable when it fails at 2 a.m.? How much autonomous change is the plant willing to tolerate in the name of agility?

Modernization in Industry 4 is not about copying enterprise IT patterns wholesale. It is about applying the right operational constructs to the realities of production environments. As engineers, we owe it to ourselves to separate buzzwords from mechanisms, and to design systems that respect both uptime and ownership, rather than assuming that what worked in a cloud-native startup will automatically translate to the factory floor.