Platforms, Journeys, and APIs

A platform is a business model that creates value by facilitating interactions between two or more participant groups, rather than by producing goods or services directly. Platforms provide the infrastructure, rules, and matching mechanisms that make those interactions possible.

Airbnb does not own hotels. Uber does not own vehicles. Amazon Marketplace does not own inventory. Each facilitates a transaction between supply (hosts, drivers, sellers) and demand (guests, riders, buyers). The platform captures a share of the value created by that facilitation.

Network effects are the mechanism by which platforms compound in value. Each additional participant makes the platform more valuable to all existing participants. Direct network effects (same-side): more drivers reduce wait times for all riders. Indirect network effects (cross-side): more buyers attract more sellers to Amazon Marketplace, making the selection better for all buyers.

Public sector platforms follow the same model. The NHS App is a platform connecting patients to services (GP booking, vaccination history, organ donation preferences, prescriptions). HMRC is a platform providing tax filing, VAT, PAYE, and self-assessment services through a single authenticated gateway. GOV.UK One Login is an identity platform. Each creates value by connecting participants, not by delivering a product.

A customer journey map is a visual representation of the steps a person takes to accomplish a goal, spanning every touchpoint with an organisation or service. A well-constructed map documents actions, emotional state, pain points, and the systems involved at each step.

Journey mapping should precede technology selection. Understanding the current journey reveals whether the problem requires a new application, an API integration, a process change, or no new technology at all. Vehicle tax renewal illustrates the method. A citizen who wants to tax a vehicle needs the vehicle taxed; nothing in that need names a counter, a form or a channel. Mapping the journey separates the steps that carry the need from the steps that exist because of how the previous system was built, and only the second kind can be removed without cost. GOV.UK now offers the service online, by phone and at a Post Office, so the counter survives as one route among several rather than as the route. A team that had skipped the mapping would have digitised the counter instead of asking whether it had to be there at all.

GOV.UK Service Standard, Point 1 of 14, requires digital teams to "understand users and their needs" before designing a service. This is journey mapping institutionalised as a quality gate.

API-first design means designing the API contract before writing any implementation. The API is the primary product. The user interface, if one exists, is a consumer of that API rather than the source of its design.

API-last design produces the opposite: an application is built first and an API is bolted on afterwards as an integration mechanism. API-last APIs reflect the application's internal structure rather than the needs of API consumers. They use inconsistent naming, break with application releases, and generate integration friction from the first external consumer onward.

GOV.UK API technical and data standards require API teams to design for user needs, security, documentation, versioning, monitoring, and clear support responsibilities. They recommend OpenAPI documents for RESTful APIs, but the current public standard should not be paraphrased as mandating a precise OpenAPI minor version, semantic versioning, or a universal fixed deprecation period unless a service standard or catalogue rule explicitly says so.

A webhook is a push-based notification mechanism: when an event occurs in a system, that system calls a URL registered by the consuming application. Stripe uses webhooks to notify merchants when a payment succeeds, fails, or is disputed. The merchant registers a callback URL; Stripe posts the event JSON payload to that URL when the event fires.

The alternative is polling: the consuming application repeatedly requests the producing system to check whether anything has changed. Polling introduces latency (missing events between poll intervals), generates unnecessary load on the producing system during quiet periods, and scales poorly as consumer count grows. For a fraud detection system that needs to act on a payment event within milliseconds, polling at 60-second intervals is not viable.

GitHub webhooks deliver build triggers, code review events, and deployment notifications to CI/CD pipelines. A push to a repository fires a webhook that triggers a build in GitHub Actions, Buildkite, or Jenkins. The push event is delivered within seconds; a polling approach would add latency proportional to the polling interval.

An API gateway sits between API consumers and backend services. It handles cross-cutting concerns that would otherwise be duplicated across every service: authentication and authorisation, rate limiting, request routing, protocol transformation, and logging.

Without a gateway, every backend service must implement its own authentication, rate limiting, and observability. In a microservices estate of 50 services, that is 50 independent authentication implementations that may be inconsistently maintained. A gateway implements these concerns once and applies them consistently to all traffic.

Kong (open-source, released 2015), AWS API Gateway (managed service), and Azure API Management are the most widely deployed solutions. The FCA's Open Banking directory required each of the nine CMA banks to deploy an Open Banking-compliant API gateway capable of handling third-party provider (TPP) authentication and consent management. That regulatory requirement standardised gateway patterns across UK retail banking.