TomorrowX

Foundational paper

A parallel operating model for change

Data Mediation is not only a runtime architecture. It requires an operating model that can define, prove, deploy and sustain interaction-level capability without becoming another form of uncontrolled project work.

Context

Why this paper exists

TomorrowX explored a parallel operating model because architecture alone does not change enterprise delivery. If mediated capabilities are designed, governed and operated exactly like invasive application changes, their advantage disappears. If they are delivered without discipline, they become shadow technology. The research therefore defined a separate mission and lifecycle for Data Mediation, connected to the same enterprise accountability as the systems it surrounds.

Different missions require different operating models

The core-system operating model protects durable enterprise assets. It is optimised for deep internal change, long service life, controlled releases and specialised engineering ownership.

The Data Mediation operating model responds to changes in context: a new control, partner, protocol, model, migration or operational risk. It is optimised for explicit data journeys, bounded proof, composable capability and reversible deployment.

Neither mission is superior. Problems arise when one model is forced to perform the other’s work. Core delivery becomes overloaded with interaction-level demand, while rapid initiatives bypass the controls required for production.

Why the traditional SDLC is insufficient on its own

The software development lifecycle assumes that the main unit of change is an application or service whose internals are being designed and built. Data Mediation changes the interaction around running systems. Its unit of design is the data journey and its visible contracts.

The lifecycle must therefore connect functional behaviour to protocol context, non-functional requirements, deployment position, probes and operational evidence. Go-live is not completion; it is the point at which the mediated behaviour begins to encounter real conditions.

TomorrowX has pioneered an alternative lifecycle for Data Mediation solutions, not an exemption from lifecycle discipline.

Two Operating Models, Shared GovernanceThe core-system and Data Mediation operating models have different missions, but share governance, evidence and operational accountability.
TWO OPERATING MODELS, SHARED GOVERNANCE
CORE-SYSTEM SDLC
Durable internal product and platform change
SHARED ASSURANCE
Security, evidence, ownership and operations
MEDIATION LIFECYCLE
Fast, reversible interaction-level change
DIFFERENT MISSIONS NEED DIFFERENT LIFECYCLES, NOT DIFFERENT STANDARDS.
The core-system and Data Mediation operating models have different missions, but share governance, evidence and operational accountability.

The Data Mediation lifecycle

  1. Define: establish the outcome, boundaries, data journey, owners and evidence required.
  2. Program: express functional requirements, mappings, decisions and interactions in the Editor.
  3. Configure: select and bind security, performance, resilience, location and other non-functional requirements in the Console.
  4. Prove: simulate, test and measure capability and value in controlled scope.
  5. Deploy: promote the governed solution into the approved data path.
  6. Operate: probe, observe, repair, evolve and eventually retire the solution.

The lifecycle remains connected. A requirement can be traced into the deployed capability and its behaviour in operation.

Put the people closest to the problem closer to delivery

Traditional integration work often translates domain intent through several layers of documentation before an engineer implements it in code. Meaning is lost, feedback slows and the organisation becomes dependent on scarce specialists.

Composable Data Mediation allows data and business analysts, architects and domain specialists to work directly with visible solution behaviour. Engineers remain responsible for the platform, complex capabilities, protocol definitions and technical assurance. The division of work changes from “engineers build every solution” to “engineers create and govern the capability through which solutions are composed”.

This is essential for scale. Human expertise is captured in editable, reusable software rather than consumed once in a project.

Shared governance prevents a second shadow estate

A parallel operating model must remain connected to enterprise architecture, cyber, risk, change and service management. Solutions require named owners, approved environments, version control, deployment authority, support arrangements and retirement criteria.

The Console provides an operational system of record for non-functional requirements, deployment, probes and telemetry. Data Lineage™ can retain evidence of what happened to data during an interaction.

This makes the mediated estate visible and manageable. The organisation gains speed without creating an undocumented layer of scripts and appliances.

Proof before scale

Data Mediation lends itself to contained proof because it can be introduced at a defined boundary without replacing the surrounding estate. A Proof of Capability and Value can establish the outcome, measure functional and non-functional criteria and create an explicit decision point.

The organisation can then scale, revise or stop based on evidence. Proven capabilities can enter the reusable catalogue, reducing the effort required for subsequent solutions.

The operating model therefore converts experimentation into institutional capability: discovery informs a proof, proof informs a governed solution and the solution adds to what the platform can do next.

Next in Enterprise adoption · Step 4 of 6

A target-state blueprint for enterprise technology

Apply standardised Data Mediation with decentralised ownership across enterprise platforms.

Read the next paper
Shared introductionStart with the Forbes featureResearch pathsChoose another path