HomeInsights › Four Things I Got Wrong About OPA

Founder Perspective

Four Things I Got Wrong About OPA

Four things I got wrong about Open Process Automation when I started in 2017. Some of it cost operators real money.

The part I underestimated was not the technology itself. It was everything around the technology.

First — I thought the conformance program would be the easy part

The logic felt straightforward: the standards body writes the specification, suppliers build to it, conformance verifies compliance, done.

In practice, building an enforceable conformance program — with credible test suites, reference implementations, independent test bodies, and continuous validation over time — turned out to be harder than writing the standard itself. The Open Group ultimately built it, but it took most of a decade.

That matters because without credible conformance, buyers end up evaluating architecture through marketing claims instead of evidence.

Second — I thought the supplier ecosystem would converge faster

I assumed that once the standards became credible, suppliers would move toward architectural openness because the alternative would become commercially irrelevant.

That is not what happened. The market split. Some suppliers committed to architectural openness. Others extended traditional platforms with open features. Both approaches are real, and both will continue to exist.

If you are evaluating a control system today, you are probably already seeing the consequence. Two suppliers can both claim "OPA-compatible" while delivering very different lifecycle behavior over the next 15 years.

Third — I thought operators would lead adoption faster

The bottleneck has not been operator interest. It has been operator capability.

Owning an OPA system requires internal architectural authority: people who can govern interfaces, portability, lifecycle strategy, and supplier boundaries over time. Building that capability takes years, and operators have approached it more deliberately than I expected.

Fourth — I thought integrators would be ready by now

They aren't. The integrator ecosystem has matured more slowly than the supplier ecosystem, and I increasingly think this is becoming the binding constraint on adoption pace.

That creates a practical implication for operators over the next 36 months: integrator selection may matter more than supplier selection. A few questions are worth asking early:

  • How are applications governed across lifecycle changes?
  • How is portability validated instead of assumed?
  • What happens when one supplier changes roadmap direction?
  • Can they explain interface ownership without referring back to a vendor presentation?

Those questions reveal capability very quickly.

What I got right

The structural argument. Architecture replaces platform. Openness is a property of the system itself, not a feature layered on top. The lifecycle behavior of those two approaches diverges over decades, and that argument has held up remarkably well.

The operators who internalize these lessons will likely modernize differently. Replacing one controller instead of renegotiating an entire system. Weekend migration events instead of plant-wide shutdown programs. Lifecycle decisions driven by operational need instead of synchronized vendor roadmaps.

Teams already working through OPA adoption — architecture decisions, supplier tradeoffs, implementation lessons — are comparing notes in the OPA Community Forum.

← All insights

Get OPA Insights

Analysis from inside the standard, in your inbox.

Occasional briefings on Open Process Automation — lifecycle economics, migration strategy, and the business case for open architecture. No noise.