When the accelerator becomes the anchor

Enterprise BPM and case-management platforms have spent years competing on a compelling proposition: get to business value faster.

Few organisations want to buy an enterprise platform and then spend months recreating capabilities that have already been solved elsewhere. Vendors increasingly provide industry models, case patterns, workflows, integration components, decisioning capabilities and pre-built accelerators designed to shorten implementation and improve time to value.

In some domains, those accelerators contain significant industry knowledge. That is precisely the sort of capability organisations buy enterprise software for: start with something proven, configure the differences, deliver value sooner.

The value is more than speed

Time to value is only one part of the proposition. Mature BPM and case-management platforms can also create business value by automating work that would otherwise be manual, applying process consistently, embedding controls into the flow of work and creating a clear history of what happened, when and why.

For a regulated or operationally complex process, that consistency and auditability can be as important as the labour saving. A well-designed platform does not simply move work faster; it can make the process more governable, more repeatable and easier to evidence.

There is also an ecosystem effect. Enterprises adopting a common vendor framework are not always solving problems alone. Product communities, communities of practice, expert groups and user forums can expose teams to patterns learned elsewhere, help organisations compare approaches to common problem statements and sometimes influence the way a vendor evolves its framework.

That shared learning is another form of acceleration. It also means that the value surrounding a platform can extend beyond the software itself.

But it raises an architectural question that receives much less attention:

What happens to the value created on top of that accelerator when the organisation eventually wants to move to another platform?

Not the data. Not simply the application. The business capability that has evolved inside it.

The accelerator paradox

There is a tension here. The more capability a vendor provides, the less an organisation needs to create itself. That can improve delivery speed, lower implementation risk and bring forward the point at which an investment starts generating a return.

But those same accelerators inevitably introduce concepts belonging to the platform. The process may inherit the vendor's case model. The data structure may reflect the product's domain model. Work may be organised around proprietary stages, steps, states or rules. Exceptions may be handled using platform-specific constructs. And increasingly, AI may generate implementation artefacts based on the patterns and abstractions of the platform underneath it.

None of that is inherently undesirable. Deliberately refusing to use these capabilities in pursuit of theoretical portability would often be poor architecture. Organisations would spend more, deliver later and recreate commodity capability that the market already provides.

The interesting question is whether the dependency created as a consequence is sufficiently understood.

The thing that gets you to value faster may also make the value you subsequently create harder to separate from the platform that helped create it.

What are we actually trying to move?

This is where discussions about portability can become too simplistic. A tempting answer is to say that an organisation should export its process into an open standard such as BPMN.

BPMN is a useful example. It provides a standard notation and machine-readable representation for describing business processes. But BPMN was only ever one part of the proposition.

The real objective is not make everything BPMN.

Preserve enough of the business capability in a vendor-neutral form that another technology could understand, translate or reconstruct it.

That distinction matters because a modern BPM or case-management application is not simply a sequence of tasks. Its behaviour may depend on lifecycle state, stages and milestones, processes and individual steps, child cases, business decisions, case data, events, SLAs, escalation, security, integrations and exception handling.

It may also embody controls that are valuable precisely because they are executed consistently: mandatory checks, segregation of duties, evidential steps, approval thresholds, exception handling and an auditable history of decisions.

It might be possible to draw much of that behaviour as a BPMN model. But drawing it and preserving its meaning are not necessarily the same thing.

Flatten a rich case lifecycle into a process flow and some of the semantics may disappear. The diagram might travel. The business capability might not.

Syntactic portability isn't semantic portability

That leads to one of the most important distinctions in this discussion.

Syntactic portability asks: can another tool read this artefact?

Semantic portability asks: does another platform understand what this artefact was intended to mean?

Those are very different tests. A process file can be perfectly valid according to a standard and still leave significant questions unanswered about the application it came from.

What does entering a particular stage mean? What happens when its SLA expires? Can several pieces of work proceed independently? What creates a child case? What event changes its state? Which business decision caused a route to be selected? Which parts are mandatory because of regulation and which simply reflect a historical implementation choice?

Those things matter if the intention is to recreate capability rather than merely redraw a process. This isn't a failing of BPMN. It is asking a process notation to carry information that belongs elsewhere.

A vendor-neutral representation

Perhaps portability should not be based on finding one universal export format. Perhaps what is required is a vendor-neutral representation of the capability.

That representation might be composite.

Not every element needs an industry standard. And a vendor-neutral representation does not necessarily need to be executable.

Its purpose could simply be to provide a sufficiently complete and machine-readable description of the organisation's capability that the current platform is no longer the only place where that knowledge exists.

That changes the problem considerably. We are no longer trying to export an application. We are trying to preserve its meaning.

Portability is probably a spectrum

Even with a richer representation, expecting everything to move unchanged would be unrealistic.

A single case-management application could contain examples of all four. Its decision tables might be highly translatable. Some integrations might be rebuildable from well-defined contracts. Its core lifecycle might need mapping between different case paradigms. A particularly valuable piece of proprietary automation might reasonably remain platform-bound.

That doesn't mean the architecture has failed. It means the dependency is understood. And understanding that dependency creates a choice.

Optionality without sacrificing value

This is where the proposition becomes less about avoiding vendor lock-in and more about strategic optionality.

The goal should not be to minimise use of vendor capability. That would undermine much of the reason for buying an enterprise platform.

The goal could instead be to deliberately separate two things:

the capability we consume from the vendor

and

the additional business knowledge we create while using it.

If that second category can be represented independently, the organisation may be able to take advantage of highly opinionated proprietary platforms without allowing every subsequent process decision to become inseparable from them.

A replacement would still require engineering. User interfaces would still change. Integrations would still need implementing. Different platforms would still express case management in different ways. Some capability would inevitably need redesign.

And success could not be measured on migration cost alone. If the source platform created value through reliable automation, consistent processing, embedded business controls and auditability, the target needs to reproduce those outcomes — or improve on them. Preserving the control environment is part of preserving the capability.

But the organisation would not necessarily be starting again from requirements workshops, reverse engineering and years of accumulated operational knowledge trapped inside the previous implementation.

It would have a head start. Perhaps a substantial one.

The open question

So the question behind this series isn't whether BPM platforms should become completely interchangeable. That is unlikely to be realistic, and it may not even be desirable.

Vendors differentiate by developing better abstractions, industry solutions, automation and increasingly AI-assisted ways of building applications. Their communities add another dimension by allowing practitioners to share implementation lessons and work collectively on recurring problems. Removing those differences and ecosystems would also remove some of the innovation and value they provide.

Can organisations consume proprietary accelerators for the value they provide, while independently preserving the business capability they create on top of them?

And if the answer is yes, how far could we take it? Could a vendor-neutral representation materially reduce the cost of moving from one BPM or case-management platform to another? Could AI help translate between different process and case paradigms? Could process intelligence reconstruct parts of the capability that were never documented properly? Which elements should be portable, which merely need to be rebuildable, and which dependencies are sensible to accept?

Those are questions for later in the series.

Because before an organisation can decide how to preserve or move the value it has created, there is a more fundamental question:

Which part of that value is actually its own?

When an implementation combines an industry framework, vendor intellectual property, implementation-partner accelerators, AI-generated artefacts and organisation-specific business design, that boundary becomes surprisingly difficult to draw.

That is where Part 2 starts.