Before you customise the platform

A strategic platform is an investment to protect

Enterprises select core and SaaS platforms because those products concentrate capability, operating discipline, vendor research and a supported upgrade path. The platform creates value when the organisation can continue to adopt those improvements. Heavy customisation and point-to-point integration gradually exchange that value for local control.

The first custom change may appear modest. Over time, the platform becomes surrounded by bespoke interfaces, duplicated logic, release dependencies and exceptions that must be retested at every upgrade. The organisation still pays for the strategic platform but increasingly operates a private fork of it.

Data Mediation introduces another option. When a requirement concerns the interaction around the platform rather than its durable internal semantics, the change can be programmed at the boundary and operated independently.

The hidden cost of customisation and integration

Customisation is not expensive only because it requires engineering. It changes the future cost of every platform decision. An upgrade must account for the custom data model, code, interfaces, workflows and downstream dependencies. A new channel inherits the assumptions of earlier integrations. A regulatory change can require coordinated releases across systems owned by different teams.

Point-to-point integration creates a similar burden. Each connection encodes the architectural style, data model, protocol and lifecycle of both endpoints. The connection becomes a dependency that neither platform can change independently.

This is how enterprise entropy grows: not through one bad decision, but through thousands of locally reasonable changes that make the whole estate harder to understand and move.

The clean upgrade path is not a vendor preference. It is an enterprise option to keep receiving the value of the platform it has already bought.

A better sequence of architectural decisions

Data Mediation should not become an automatic answer to every requirement. It is a best first alternative when the next options would be platform customisation or bespoke integration. A disciplined decision sequence keeps the architecture honest.

• Use native capability where it fits. Prefer supported configuration and platform services when the requirement is part of the platform’s intended domain.
• Ask where the semantics belong. A durable change to the platform’s core business meaning may properly belong inside it.
• Test the boundary. If the requirement concerns identity, context, translation, policy, orchestration, augmentation or cross-platform behaviour, evaluate Data Mediation before changing the core.
• Prove the alternative. Compare latency, resilience, support, operating cost, upgrade impact and reversibility before committing.
• Customise only with eyes open. Where an internal change remains the best option, make the future upgrade and dependency cost explicit.

What can move to the boundary

A programmable mediation layer can address a wide range of requirements that are often pushed into strategic platforms by default. It can expose or reshape data, introduce contemporary identity controls, translate protocols and structures, personalise an interaction, enforce policy, invoke AI, coordinate actions across systems or create a temporary stand-in behaviour during change.

The common feature is that the new requirement can be expressed through the observable interaction without corrupting the platform’s internal responsibility. The platform continues to perform the transaction or process for which it was selected. The mediated layer provides the changing context around it.

This separation also supports rationalisation. Multiple systems that provide similar capabilities can be presented through a consistent mediated contract while the enterprise decides which assets to retain, consolidate or exit.

Protect the clean upgrade path

A clean upgrade path requires more than avoiding source-code changes. External integrations can still bind the platform to specific schemas, versions and release timings. The mediated boundary absorbs those differences. Consumers depend on the governed external contract while Data Mediation translates to the version and protocol the platform currently supports.

When the platform upgrades, the mediated capability can be tested against the new version, adapted independently and progressively promoted. The connected channels, partners or agents do not all need to change at the same time.

The upgrade therefore becomes a controlled substitution behind a stable interaction rather than a coordinated enterprise event.

Support a platform-oriented enterprise

Modern enterprises do not have one platform. They have business platforms, data platforms, cloud platforms, security platforms, operational technology and specialist SaaS. Each has a bounded purpose and its own authority, language and lifecycle.

Data Mediation supports that plurality. It does not require one platform to become the integration hub for all others. A domain can own the mediated contract at its boundary and connect to another domain without either side adopting the other’s architecture.

This protects the autonomy of platform teams while allowing end-to-end outcomes to be composed across them.

Keep ownership with the team closest to the platform

The team that owns the strategic platform should remain accountable for the mediated deployment around it. Enterprise standards define the capability contract, non-functional requirements, evidence and certification. They do not take the solution away from the team that understands the platform and its users.

Reusable protocol definitions, controls and compositions can be drawn from the X Store. The platform team adapts them to its local context, proves the result and operates it inside the required security zone.

This gives the enterprise a consistent foundation without creating a central integration team that becomes the owner of every dependency.

Make reversibility part of the business case

The value of a boundary solution is not only speed. It is the ability to prove the intervention before the organisation becomes dependent on it. Traffic can be observed, shadowed, compared or progressively routed. Failure behaviour and latency can be measured. The platform remains available while the new capability is evaluated.

If the result does not justify itself, the mediated change can be withdrawn. If the requirement later belongs inside the strategic platform, the external implementation can provide a working specification and evidence for that migration.

This turns architecture choice into a measurable decision rather than a commitment made before the interaction is understood.

The role of Data Mediation in the target state

In the proposed target state, every strategic platform retains its own purpose, authority and upgrade path. Data Mediation becomes a standardised capability available at the platform boundary, deployed and owned by the relevant team. Shared guardrails and the X Store provide consistency and reuse.

The enterprise is not forced to adopt the pattern everywhere. It is simply available as the best first alternative whenever the next proposal is another customisation or another point-to-point integration.

That choice is enough to change the long-term shape of the estate. Each avoided coupling preserves future options.