Portability by Design

The first two parts of this series have built towards a fairly simple conclusion: if an organisation wants to preserve the business capability it creates on top of a BPM or case-management platform, it cannot wait until the replacement programme to work out what that capability is.

By then the most important knowledge may be distributed across product configuration, custom code, operating procedures, decision tables, integration logic, vendor frameworks, partner assets and the memories of people who were there when key choices were made.

Portability is not primarily an exit activity. It is a lifecycle discipline.

That does not mean every implementation should be designed for a hypothetical migration from day one. The cost would be difficult to justify and the result could undermine the very accelerators we bought the platform to use.

The more useful question is: what is the minimum governance needed to preserve meaningful optionality without slowing delivery to a crawl?

Make the dependency explicit

Enterprise architecture already spends a lot of time recording dependencies: applications depend on services, services depend on data, processes depend on teams, and critical capabilities depend on third parties.

But a BPM implementation introduces another dependency that is often less visible: a dependency on the way the platform expresses business behaviour.

A case lifecycle built around proprietary stages and steps is a dependency. A decision model embedded in a platform-specific rules engine is a dependency. A reusable industry framework is a dependency. So is a partner component that cannot be transferred to another supplier.

None of those dependencies are necessarily wrong. Architecture should not be a contest to eliminate dependency. It should make important dependencies visible enough that organisations can make conscious choices about them.

That suggests a simple governance question whenever a team uses a major accelerator or proprietary construct:

What value are we gaining from this dependency, and what would we need to preserve if the dependency changed later?

The value side of that question should be broader than cost and delivery speed. Automation, consistent execution, embedded controls, auditability and access to a mature vendor community may all be part of the benefit being consumed. If so, those qualities need to be visible in the future exit criteria too.

A Process IP Register

One practical response could be a lightweight Process IP Register.

The name sounds more formal than the idea needs to be. I am not suggesting a giant inventory of every rule, screen and workflow node in the estate. That would become stale almost immediately.

The register would instead identify where meaningful organisational knowledge has been added to a capability, where that knowledge currently lives, and how dependent it is on the surrounding platform.

The goal is not perfect documentation. It is enough traceability to prevent the platform itself becoming the only record of how and why the organisation operates.

Capture the delta, not every implementation detail

This is an important boundary because documentation programmes often fail by trying to describe everything.

If a vendor framework provides a standard case structure and the organisation uses it unchanged, there may be little value in creating a parallel internal model of the same thing. The vendor documentation already describes the foundation.

The thing worth preserving is the difference.

If the organisation changes a standard stage, adds a regulatory control, introduces a different decision threshold or replaces the vendor's routing with its own model, that is where the register should become interested.

In other words, the Process IP Register should behave a little like configuration management for business capability: what have we changed from the baseline, why, and what would we need to reproduce that change somewhere else?

Vendor communities can help sharpen that distinction. If several enterprises using the same framework are tackling the same issue, the answer may be a reusable pattern, a vendor enhancement or a community-agreed approach rather than five separate pieces of customer-specific design. Architecture teams should be able to benefit from that collective strength without losing sight of the genuinely organisation-specific delta.

Architecture decisions need an exit dimension

The same idea could be reflected in architecture decision records and design governance.

When a team chooses a proprietary product capability, the decision is usually assessed against delivery speed, cost, functional fit, security, resilience and maintainability.

For material capabilities, I think there is room for one more question:

What happens to our organisational delta if we stop using this capability?

The answer might be perfectly acceptable: this feature is highly proprietary, but it is commodity capability and we would simply adopt the equivalent offered by a replacement platform.

Or the answer might be more significant: this component contains business rules and operational learning accumulated over years, so we need an independent representation of those rules and the rationale behind them.

The important thing is not that every answer leads to portability. It is that the trade-off is visible when the decision is made.

Govern the outcomes, not only the artefacts

There is another design implication here. If a platform has created value by executing work consistently, enforcing controls and leaving an auditable trail, then a portability strategy that only preserves process definitions is incomplete.

For a material capability, architecture governance should make the required outcomes explicit: which controls must always fire, what evidence must be retained, which approvals cannot be bypassed, what segregation is required, how exceptions are handled and how an auditor or operations team reconstructs what happened.

Those become part of the acceptance criteria for any future target platform. The question is not simply whether the new process runs, or whether the business case still shows a financial benefit. It is whether the target reproduces the controlled and governable way in which the business capability operates.

Contracts can enable portability, but they cannot create it

Procurement and contracting naturally have a role here.

If the organisation expects to retain its own process knowledge, agreements need to be clear about customer-created IP, pre-existing vendor and partner IP, rights to generated artefacts, third-party components, documentation and the ability to provide relevant material to a successor supplier.

Exit provisions may also need to cover practical access: what can be exported, in what form, for how long, and what assistance is available during transition.

But contracts alone cannot solve a semantic portability problem.

A clause can give an organisation the right to receive "all customer configuration" and still leave it with thousands of proprietary artefacts that only make sense inside the source platform.

Likewise, ownership of custom code is of limited value if the code depends on vendor APIs, partner libraries or runtime behaviour that cannot travel with it.

Legal rights create permission. Architecture and engineering create usable options.

Do not apply the same portability bar everywhere

There is a danger that this becomes another enterprise control applied uniformly to every workflow in the organisation.

That would be a mistake.

A low-value internal approval process does not need the same portability discipline as a platform carrying a critical customer journey or years of regulatory decision logic.

A more pragmatic model would tier the requirement according to the value of the organisational delta and the difficulty of reconstructing it.

That keeps the governance proportional. The objective is optionality where optionality has meaningful business value.

The representation has to stay alive

There is one final challenge. A vendor-neutral representation created during implementation and never updated is probably worse than having none at all because it creates false confidence.

If the live application evolves, the representation has to evolve with it.

That does not necessarily mean manual documentation. This is where tooling becomes interesting. Could deployment pipelines identify changes to rules and process structures? Could AI explain changes in business terms? Could process mining compare the documented model with the process that is actually executing? Could the organisation continuously regenerate parts of its vendor-neutral representation from source artefacts and runtime behaviour?

If portability depends on a heroic documentation exercise, it will fail. If it can become a side effect of normal engineering and governance, it has a chance of becoming sustainable.

From policy to experiment

At this point the concept has moved from an abstract question towards something that could actually be governed.

We have a possible representation of the capability. We have an organisational delta worth preserving. We have a way of recording provenance and dependency while the solution changes.

But none of that proves that a transition would work.

The real test is technical: if we extracted that vendor-neutral representation from one platform, how much could a different platform actually do with it?

Would we get a functioning process, a useful starting point, or simply a sophisticated set of requirements for a rewrite?

That is the experiment for Part 4.