Share this post
"We need DevOps on the factory floor."
It's a commonly repeated phrase we hear in industrial modernization right now. But before anyone adopts anything, especially something that originated in enterprise IT, it's worth slowing down to ask what it actually means in practice.
The question isn't whether DevOps has value. It's whether we're solving the right problem, or importing terminology that feels modern without fully understanding the operational implications.
DevOps is an ownership model, not a toolset
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. It collapses the boundary between development and operations and places end-to-end accountability on the same team. The team that builds the software owns it in production. They're 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 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, it's entirely reasonable to be 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's actually running in most industrial environments. DevOps assumes you own the application lifecycle. Not everyone does.
The industrial reality: vendor software and ownership gaps
Walk through a modern plant and you're far more likely to encounter commercial software than internally developed applications. Systems like Ignition, Litmus Edge, Softing dataFEED, MaintainX, or Tatsoft FrameworX running on servers or edge devices aren't applications written by an in-house development team living inside the codebase. They're 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 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 coordinating with the vendor and planning a controlled downgrade?
In most plants, the answer is obvious. You don't own the source, and you're not rewriting core functionality at 2 a.m. to restore production. You're operating within vendor-defined constraints.
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: deployment automation
What most factories actually need isn't DevOps in the purist sense. It's disciplined deployment automation. Repeatability. Consistency across sites. Reduced configuration drift. A way to make changes without introducing human error.
That's a very real requirement, especially as Industry 4.0 modernization projects scale from one pilot line to multiple facilities across regions.
Deployment automation means installing and configuring vendor software in a consistent way, ensuring environments look the same in Plant A and Plant B, and maintaining documented, auditable change processes. It doesn't mean adopting a full "you build it, you run it" culture for code you didn't write.
Know what you're actually solving for before you name it.
GitOps works — with the right trigger model
Even GitOps, which often gets presented as the natural extension of DevOps, needs to be examined through this lens. Tools like Argo CD and Flux provide a clean model where the desired state lives in Git and the runtime environment continuously reconciles itself to match. In a SaaS company optimizing for speed, that's 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 with 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. Continuous, autonomous deployment can directly clash with a plant manager's risk tolerance.
That doesn't mean automation is wrong. It means the trigger model matters. You can still define desired state in version control and use automated pipelines to execute changes, but gate execution behind an approval that aligns with operational reality.
Automation, yes. Blind reconciliation, no.
Being honest about which world you're in
There are industrial contexts where a true DevOps model makes complete sense. If your organization builds its own data pipelines, custom dashboards, proprietary optimization logic, or machine learning models that drive production decisions, the team that creates those assets should own them in production. In that scenario, DevOps isn't theater. It's accountability.
The key is being honest about which world you're in.
If your plant primarily deploys vendor products and integrates them at the configuration level, then what you're solving for is lifecycle management and deployment consistency. If you're building and evolving core logic that differentiates your operation, then DevOps becomes relevant as an organizational model.
Before declaring that "the factory needs DevOps," a few direct questions are worth asking: Do you actually write and maintain the software running your production environment? Who is accountable when it fails? How much autonomous change is the plant willing to tolerate in the name of agility?
Modernization in Industry 4.0 isn't about copying enterprise IT patterns wholesale. It's about applying the right operational constructs to the realities of production environments, separating buzzwords from mechanisms, and designing systems that respect both uptime and ownership.
The right model isn't the one that sounds most modern. It's the one that works when production is on the line.
Looking to learn more? Check out our Resource Hub
.png)