I've been working on Open Process Automation since 2017. The technical problems turned out to be the easy part.
The standard works. The conformance program works. Suppliers exist. Components interoperate. Portable control is real.
What turned out to be difficult was the organization around the architecture.
Who owns the architecture inside the operator? Who has the authority to enforce it when procurement pressure pushes the project back toward a single-supplier model?
Those are not technical questions. They are governance questions.
The operators that succeed with OPA won't be the ones with the best control engineers. They'll be the ones that build architectural authority, procurement discipline, lifecycle governance, and multi-vendor integration capability.
One of the simplest diagnostics is this: ask who in your organization owns interface governance across the lifecycle of the system. If the answer is unclear, or if it changes between engineering, procurement, operations, and maintenance, you already know where the future failure mode is likely to emerge.
The operators that get this right will look very different in year five. They'll be able to modernize incrementally instead of through full-system replacement cycles. They'll maintain leverage during procurement. They'll adopt new applications without rebuilding the control stack underneath them. And they'll govern the architecture as a long-term operational asset instead of a one-time project deliverable.
This is the part of OPA nobody told me to expect when I started. And it's the part that determines whether an organization achieves real architectural transformation or just nominal compliance layered on top of traditional vendor structures.
Some of this capability can be transferred from outside. None of it is fast. Operators working through the organizational side of OPA are comparing notes in the OPA Community Forum — it is a useful place to see how peers are framing these decisions.