Who Owns the Delta?

Part 1 left us with a deliberately uncomfortable question. If a business capability has been created on top of a proprietary accelerator, and we want to preserve enough of that capability to move somewhere else later, which part are we actually trying to preserve?

The obvious answer is: the part that belongs to the organisation. But modern BPM and case-management solutions rarely have a clean line between "vendor" and "customer" capability.

They are assembled from layers: the platform, an industry framework, reusable partner assets, organisation-specific configuration, custom code, business decisions, operating knowledge and increasingly AI-generated design. The result may feel like one application, but its provenance is anything but simple.

If we cannot separate the organisational contribution from the product that currently expresses it, ownership becomes an abstract idea rather than a useful source of optionality.

Start with the value of the framework

The complication exists for a good reason. Industry frameworks are designed to give organisations a head start.

Take payment exceptions and investigations as an example. Pega Smart Investigate packages domain capability around investigation workflows, work allocation, SWIFT messaging and case structures. The current product extends that further with generative and agentic automation.

That is valuable precisely because the customer does not need to invent the whole operating model from scratch. The vendor has already encoded a view of the domain into the product.

In a mature vendor ecosystem, that view can also be reinforced by a community around the platform. Practitioners exchange implementation lessons, compare common problem statements and share patterns through forums, communities of practice and expert groups. For enterprises working in similar domains, that can create strength through collective learning rather than each organisation solving the same problem independently.

The framework therefore represents more than reusable code. It can carry accumulated product knowledge, industry interpretation and community learning. That makes it more valuable — and makes the boundary between what was consumed and what was subsequently created even more interesting.

Now imagine an organisation spends five or ten years adapting that framework. It introduces its own routing, thresholds, controls, customer treatments, escalation patterns, regulatory interpretations and exception handling. It learns from incidents and operational experience. It changes the process because the business itself changes.

The resulting capability is no longer simply the vendor's framework. But nor is it wholly independent of it.

That difference is what I mean by the organisational delta.

The organisational delta

The delta is the additional business meaning an organisation creates on top of the foundations it consumes.

That might include:

Some of those things may be represented as rules or process steps. Others may be hidden inside configuration, documentation, code, work instructions or simply the reasoning behind a design decision.

Which is why I do not think the useful ownership question is simply "who owns the process model?" The process model may only be one expression of the asset.

The organisation may also have created value through the way the platform now executes that process: automation, consistent routing, embedded controls, escalation and a reliable audit trail. Those outcomes may not be intellectual property in the same sense as a rule or design artefact, but they are still part of what a future migration needs to preserve.

Now add the implementation partner

Large enterprise implementations often add another contributor: the systems integrator or specialist implementation partner.

Partners quite reasonably bring reusable assets of their own: connectors, case patterns, test harnesses, UI components, delivery frameworks and accelerators created across multiple clients. Reusing those assets can reduce cost and delivery risk.

But it creates another provenance boundary. Was a component created specifically for this organisation, or was it pre-existing partner IP? Was it developed jointly? Can it be modified? Can it be taken to another platform? Can the organisation give it to a different supplier as part of a future migration?

In the UK, the default position for commissioned copyright work is a useful reminder not to assume that payment automatically equals ownership: the creator is normally the first owner unless ownership is transferred by agreement. Work created by an employee in the course of employment is treated differently. Enterprise contracts will of course define far more detail, and this is not legal advice, but the architectural implication is straightforward.

"We paid for it" is not a provenance model.

AI makes provenance more important, not less

Generative AI adds another layer because the distance between business intent and implementation is shrinking.

A team can increasingly provide policies, requirements and natural-language descriptions to an AI-assisted development capability and receive process designs, case structures, rules or application artefacts in return.

The business supplied the context. The vendor supplied the model and tooling. The platform supplied its abstractions and patterns. A person reviewed and refined the output. So where does the resulting design come from?

Pega's current GenAI FAQ provides one concrete example of how vendors are starting to address this. It states that Pegasystems does not own results from a client's use of Pega GenAI, while also noting that similar responses may be produced for different users and that rights in generated results may not be enforceable against third parties.

That illustrates an important distinction. A vendor saying "we do not own the output" is not necessarily the same thing as the customer having exclusive, portable and enforceable rights to everything in that output.

More importantly for architecture, an AI-generated artefact can still inherit proprietary platform concepts even when the vendor makes no claim over the result itself.

The ownership position may be relatively clear while the portability position remains difficult.

Ownership, usage and portability are different

I think there are three questions that need to be separated.

An organisation could own its business requirements but have no practical mechanism to extract the implementation created from them.

It could have broad rights to customise an industry framework while having no right to reproduce the framework itself outside the product.

It could own bespoke code created for it while discovering that the code depends on partner-owned libraries.

Or the contractual position could be completely clear while the architecture team simply cannot tell which parts of a ten-year-old solution were standard, customised, generated or inherited.

In each case, "customer owns customer IP" may be legally useful but architecturally insufficient.

The delta grows after go-live

There is another reason this matters: process IP is not created once during implementation.

It accumulates.

A control changes after an incident. A regulator clarifies an expectation. Fraud or customer behaviour changes. Operations discovers a better route. A temporary workaround becomes a permanent pattern. A new service introduces an exception that the original framework never anticipated.

Each of those changes adds a little more organisational knowledge to the capability.

So a solution that was perhaps 80% vendor framework on day one may be something quite different years later. The difficult part is that the organisation-specific knowledge is rarely accumulated in a neat layer above the product. It becomes interwoven with it.

That creates a form of lock-in that is more subtle than proprietary technology alone: knowledge dependency.

Perhaps the question is not "do we own it?"

I do not think the goal should be for organisations to own every part of their BPM or case-management capability. That would remove much of the value of buying an enterprise product in the first place.

The goal is to understand the boundary.

Can we identify the organisational contribution independently of the product, framework, partner assets and AI tools that helped create it?

If we can, then the vendor-neutral representation from Part 1 starts to become more concrete. It does not need to reproduce the whole application. It needs to preserve the parts of the capability that the organisation has a reason, and a right, to retain.

If we cannot identify those parts while the solution is being built and changed, trying to disentangle them during an exit programme will be expensive, slow and contentious.

Which suggests that portability cannot be something we think about only when we want to leave.

It has to become a design and governance concern much earlier.