TomorrowX

Foundational paper

Thinking beyond the application boundary

Architecture has trained us to look for change inside boxes. Data Mediation begins by asking whether the better place to solve the problem is in the interaction between them.

Context

Why this paper exists

TomorrowX explored “outside the box” architecture because design conventions were constraining the available solution space. Systems, applications and databases appeared as tangible boxes; the lines between them appeared to be mere transport. To innovate without disruption, the team needed a method that treated the interaction itself as a legitimate computational and governance surface.

The box bias in enterprise design

When a requirement arrives, teams naturally ask which application should be changed. Should presentation logic move into the channel? Should validation be added to the server? Should the data model be altered? Each option assumes that meaningful computation must reside inside one of the boxes.

The assumption is reinforced by architecture diagrams. Boxes are named, owned and funded. Lines are thin, unnamed and often omitted from governance. The visible design vocabulary directs attention inward.

This is a cognitive constraint, not a law of computing. Every interaction already contains data, sequence and context. The question is whether that interaction should remain passive or become programmable.

Ask where the requirement naturally belongs

A requirement should be placed according to responsibility, not habit. Behaviour fundamental to a system’s enduring purpose may belong inside it. Behaviour that concerns the relationship between systems, a particular consumer, a changing policy or a transitional context may belong at the boundary.

Examples include translating one protocol into another, masking data for a partner, enforcing a new control before a legacy transaction, comparing old and new system outputs, or constraining what an AI agent may execute.

Boundary-first design does not move everything outside the application. It prevents the application from becoming the default location for requirements that do not naturally belong there.

Two Design SurfacesArchitecture diagrams contain two design surfaces: durable systems and the interactions between them. Data Mediation makes the latter explicit.
TWO DESIGN SURFACES
APPLICATIONS
Durable internal capability and state
INTERACTIONS
Requests, responses, events and protocol exchanges
BOUNDARY-FIRST CHANGE
Place each requirement where it naturally belongs
ARCHITECTURE INCLUDES THE LINES BETWEEN THE BOXES.
Architecture diagrams contain two design surfaces: durable systems and the interactions between them. Data Mediation makes the latter explicit.

The interaction as a computational surface

A Programmable Data Agent can understand messages in sequence, derive context, invoke services and intelligence, and act before the interaction completes. This turns the line on the diagram into a real runtime.

The runtime is not valuable merely because it can execute code. Its value comes from position. It sees the request before the system acts and the response before the consumer receives it. It can therefore mediate consequence at the point where two domains meet.

That position also creates a natural evidence point: the original data, applied logic, transformation, decision and resulting action can be retained as one journey.

A boundary-first design method

A practical method begins with the outcome rather than the product:

  1. Map the data journey. Identify the systems, protocols, identities and moments of consequence.
  2. Define the visible contracts. Record what each participant sends, receives and expects.
  3. Locate the change. Decide whether the requirement belongs inside a system, at a boundary or across the complete journey.
  4. Bind non-functional requirements. Define security, performance, resilience, location, evidence and failure behaviour.
  5. Prove in controlled scope. Measure the outcome before broad dependency is created.
  6. Operate the solution. Retain probes, telemetry, repair and retirement as part of the design.

Composition changes who can participate

When every solution is expressed as source code inside multiple applications, delivery depends on engineers with detailed knowledge of each stack. Domain experts and data analysts remain one step removed from the behaviour they are trying to define.

A composable mediation model makes mappings, decisions and interactions explicit. People closest to the process can participate directly in specifying and programming the functional outcome, while platform governance constrains deployment and operation.

This does not remove engineering. It uses engineering to create reusable capability and a governed environment, rather than consuming scarce engineering talent on every point-to-point change.

The boundary is an option, not an ideology

Some requirements should still be implemented inside applications. Data Mediation is unsuitable when it would duplicate critical internal state, create unnecessary latency or obscure responsibility that clearly belongs to the system.

The architectural advance is the availability of another valid location. Teams can compare internal change with mediated change according to risk, time, reversibility, reuse and long-term ownership.

Thinking beyond the application boundary expands the solution space. It allows innovation to occur where it creates the least disruption and the clearest accountability.

Next in Core architecture · Step 5 of 5

Why running systems need a change layer

Bring the work together as a multi-protocol change layer across technology generations.

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