Ahead of his Nordic APIs Summit 2026 talk on API coherence, London Stock Exchange Group’s Gareth Faull joins us to talk about the art of aligning APIs with organizational intent.

Measuring the performance of an API is a relatively straightforward process: ensure observability is in place, follow governance best practices, measure uptime, track usage statistics, and so on. Do all of this right, and you have yourself a “good API.”

But the story doesn’t end there, because a “good API” is actually fairly useless if it doesn’t align with an organization’s goals. Many companies still struggle with the management side of APIs, which may be exacerbated by duplicated APIs, overlapping capabilities, competing standards, and unclear ownership. The problem here is not performance, but coherence.

API platforms provide a uniquely visible window into how organizations make decisions, and often reveal how disconnected organizations, their technical stacks, and their consumers actually are. The structure behind those systems, Gareth Faull argues, should be comparable with that of spacetime crystals. But first things first: what is a spacetime crystal anyway?

The Coherence of Spacetime Crystals

Our conversation with Faull kicks off with a quick physics lesson: Crystalline structures, examined under a microscope, are highly ordered and repeating arrangements of matter in a solid material. Without getting too deep into the weeds, spacetime crystals are a phase of matter in which components exhibit a repeating pattern at regular, predictable intervals of time, like an internal self-sustaining clock.

In his talk, Gareth plans to use the concept as a gateway into talking about the coherence of APIs, as well as the wider organizations they sit within, so we won’t dwell and spoil too much of that here!

Suffice it to say, the analogy is a powerful one because it encapsulates the struggle of maintaining APIs at scale and mapping them to organizations. Here’s how we might think of it:

• Space = API landscape: Different APIs, teams, domains, consumers, and systems need to be able to fit together without unnecessary duplication or contradiction.
• Time = organizational change: APIs have to be able to survive new products, acquisitions, new technologies, changing standards, and changing consumer needs without the landscape becoming fragmented.
• Crystalline structure = underlying organizational logic: A coherent API estate reflects consistent decisions about ownership, capabilities, standards, and business objectives, rather than fracturing in the face of change.
• Disorder = API sprawl: Duplicated APIs, overlapping capabilities, competing standards, and unclear ownership are all signs that the underlying structure has lost coherence.

The rapid rise of AI-based decision-making in organizations, which is something that Faull has written about at length, makes all of this more important, not less. Quoting briefly from Faull’s work, “many such systems exhibit growing incoherence over time: decisions conflict, rationales are lost, and organizational intent drifts.” His paper argues that “these failures are structural rather than algorithmic.”

Indeed, the more an AI system ingests incoherence, the higher the risk it will reinforce it.

Strategic Alignment at Scale

Despite the obvious areas of overlap shared by API strategy and organizational strategy — driving revenue, reducing customer friction, building loyalty, and so on — these priorities aren’t always lined up as well as they should be. And there are various reasons for that.

Faull points out, for example, that coherence issues “might happen because a company bought other businesses. Different AuthN methods across an API estate, for example, are a sure sign other businesses were acquired but never became coherent within the wider organization.”

The chasm that can develop between developers and managers, especially non-technical C-level execs, when these groups operate in silos, is another organizational factor. Even architectural changes, such as the adoption of microservices, can result in an API estate becoming fractured if developers working across it fail to align on standards and approaches.

Before you can improve coherence in an organization, a vital first step is mapping out the situation as it currently stands: “When you ‘map’ in business gardening,” Faull says, “you’re trying to work out why things are the way they are; how goals connect to work, what actual long-lived products you have to steward and tend to, how they relate to each other, and so on.”

It’s easy, he suggests, to become fixated on a small part of the garden — a small suite of customer-facing APIs, for example — at the expense of looking at the organization holistically.

Although that technically improves coherence, he says, “you’re only tending a small part of a garden, rather than doing the hard work of making a whole organization more coherent. An individual product can be very coherent but, if the organizational goals above it are incoherent, then that product can’t affect anything about it. You’ll always hit the coherence ceiling.”

From Mapping to Business Gardening

Mapping out an organization is the first step in what Faull refers to as business gardening. Every organization, he states, “is an ever-evolving garden that needs to be tended.” Echoing the spacetime crystal analogy, he points out that it’s not enough to map an organization (and its APIs) once and feel confident you can rely on that later. “Organizations and APIs change constantly, and you need to be constantly evolving your map and measurements based on that.”

It’s this holistic view that casts light on decisions that might appear incoherent at first glance. For example, let’s imagine that we have two APIs that provide the same functionality. From an infrastructure perspective, it would be easy to see this as surplus to requirements and sunset one of them. If we zoom out, however, we might discover that one is tuned for a growing audience of agentic traffic with different rate limits and the other for “normal” system traffic.

This is another example of how achieving, or even approaching, structural coherence requires ongoing effort. Just a few years ago, agentic traffic wasn’t something that most organizations were thinking too much about. Fast forward to 2026, and it’s a growing priority for many businesses — with clear alignment on infrastructure decisions and business goals, different audiences inside organizations can work together on how to cater to such changes.

As machines become more autonomous API consumers, they become increasingly dependent on the coherence of the systems underneath them. But this isn’t just about optimizing organizations for machines: humans still need to understand and navigate these systems too.

How to Start Measuring Coherence

In the interest of pulling some “actionable tips” for the blog, we ask Faull where he would start looking if he was tasked with measuring the coherence of an organization and its APIs:

“I would look for an API I could map…using a ‘product tree.’ A structure that includes the goals, jobs, and work items of the product, then I would try to map all the organizational goals above it. That’s how I would get a first pass at a coherence measurement.”

It’s something that goes way beyond a passing interest for Faull, who hopes to release an open-source framework for measuring the coherence of an organization and its APIs. [We’re sure he’ll talk more about that at our Summit in October]. Still, he acknowledges, this is “a bit like aiming for perfection, and there’s no such thing as a 100% coherent organization.”

“What I’m looking for,” he continues, “is figuring out how much different parts of your organization make sense. We can measure APIs till the cows come home, but we need to look at them as long-lived products in a wider organization, and how to map and measure that.”

It’s something that, for a long time, has felt like an inexact science. And one that will be familiar to anyone who has found themselves juggling several inconsistent APIs, taking ownership of orphaned APIs, or trying to justify the cost of an upcoming project to a non-technical audience. The real goal here is not to create an organization in which nothing ever changes, but one in which the underlying structure doesn’t fracture or become disordered in the face of it.