Vendor lock-in is rarely the result of a bad decision. It is the cumulative result of many reasonable ones. Each procurement looked sensible in isolation. Together, they delivered the organisation into a position where its operating model is no longer something it controls.

What Lock-in Actually Is

Lock-in is not just a contract length. It is the loss of practical optionality. The organisation can technically leave, but the cost of leaving is high enough, and the risk of a botched migration severe enough, that leaving is not a real option. The vendor knows this. The pricing reflects it. So does the roadmap.

The Three Layers Where Capture Happens

Data layer. Operational data lives in the vendor’s schema, in the vendor’s storage, accessible through the vendor’s APIs. Extracting it is a programme, not a query.

Logic layer. The business rules that govern the operation are encoded in the vendor’s policy engine, configured through the vendor’s interface, and not portable to anything else.

Skills layer. The people who know how to operate the system have invested years in vendor-specific certifications. Their muscle memory is the vendor’s muscle memory.

Each layer compounds the others. By the time the executive team realises the organisation has been captured, all three are in place.

Sovereignty is not a procurement clause. It is an architectural property. Either your operating layer is portable, or it is not.
Open architecture keeps your options open.

The Open-Architecture Posture

Open-architecture thinking treats portability as a non-negotiable design property of the operating layer. It does not require avoiding commercial software. It requires that the commercial software sit on portable foundations.

Data is yours. Stored in formats and locations you control, exportable in bulk on demand, and replicated to a customer-owned environment by default.

Logic is yours. Policies and decision flows are defined in standards-based, human-readable formats that you can take with you.

Integrations are yours. Connections to surrounding systems are mediated by open protocols, not by the vendor’s bespoke API surface.

How DOLIUM Approaches This

DOLIUM is built deliberately as the layer above your existing systems of record, not as a replacement for them. Customer data stays in customer environments. Decision logic is portable. Integrations route through MCP and other open patterns. The platform earns its renewal by being useful, not by being inescapable.

That posture is not a marketing position. It is the position our customers in defence, government, and regulated industry require. We built the product around it because anything else would have failed those customers’ assurance regimes on day one.

To audit your operating stack for capture risk, book a briefing.