Several months ago I was asked where an owner-operator should begin with Open Process Automation. The expectation was that we would spend the afternoon comparing suppliers, discussing controllers and debating technology roadmaps.
Instead, we stood in front of a whiteboard and drew the existing control architecture.
For the next two hours, nobody discussed replacing the DCS.
We mapped applications, engineering workstations, compute platforms, operator stations, historians and the relationships between them. Every time someone drew another connection, the same pattern emerged. Components that had once evolved independently had gradually become tied together through years of upgrades, integrations and sensible project decisions.
By the end of the session, the drawing explained something the asset register never had.
Years of sensible project decisions had accumulated into dependencies nobody intended to create.
No single project caused the problem. Every project solved a legitimate operational need. Together, they produced an architecture where changing one component increasingly meant changing several others.
That observation changes where an OPA programme should begin.
Many organisations assume Open Process Automation starts with selecting a new control platform. Once that assumption takes hold, the discussion quickly shifts to budgets, shutdown windows, procurement strategy and migration risk. Before long, OPA begins to look like another major capital programme that will eventually replace the DCS.
My experience has been very different.
The first objective is understanding how today's architecture behaves. Which applications depend on a particular runtime? Which engineering tools only support one execution environment? Which infrastructure changes automatically trigger supplier involvement, factory acceptance testing or application revalidation?
Those dependencies determine the size, cost and risk of every future project far more than the age of the hardware itself.
One owner-operator discovered that replacing a relatively small compute platform had quietly grown into a three-year programme because the surrounding applications, engineering tools and validation procedures had become inseparable. The hardware represented a small part of the investment. The real cost came from engineering effort, testing, documentation, supplier support and managing relationships that had accumulated over many years.
That is why I recommend building a dependency map before building a technology roadmap.
The exercise is straightforward. Select one production unit and draw every major application, engineering tool, compute platform and supporting service that keeps it operating. Then connect the components that must change together. Don't worry about documenting every interface. Focus on the dependencies that force work to travel from one layer of the architecture to another.
When the map is finished, one question usually becomes obvious.
Which dependency turns a routine lifecycle event into a major project?
That answer gives the engineering team something practical to work on immediately. Instead of evaluating another platform or writing another procurement specification, they can begin removing the dependency that creates the most engineering effort without adding operational value. Every dependency removed today reduces the size, cost and risk of the next modernisation project.
This thinking influenced much of the work behind the O-PAS Standard. The objective is to make it easier for applications, infrastructure and execution environments to evolve more independently over time. That gives owner-operators greater freedom to modernise individual parts of the architecture instead of waiting for another once-in-a-generation replacement programme.
The operational difference is easy to picture.
A compute platform reaches the end of vendor support and is replaced during a planned maintenance window. The environment is validated, the applications return to service and operators arrive on Monday morning using the same control strategies and graphics they relied on the previous week. Six months later, the engineering team deploys a new advanced control application because operations wants better process performance, not because ageing hardware forced the change.
Modernisation still happens.
It simply happens as a sequence of measured engineering decisions instead of recurring capital projects driven by accumulated dependency.
If your organisation is beginning to explore Open Process Automation, OPAcommunity.com provides vendor-neutral guidance on O-PAS principles, architecture and practical modernisation strategies. If your dependency map reveals that accumulated architectural constraints are driving the size and cost of your projects, that assessment is often the point where experienced external support can accelerate progress.
Where in your current architecture have dependencies accumulated to the point that changing one component now forces four or five others to change with it?