Aiger Data
Pattern 05 · Federated hub

Federated services on a shared hub.

A community-sized environment runs many services that each serve the same population badly because no shared layer exists between them. The temptation is a "smart everything" big bang; the discipline is a shared hub that compounds as more services join.

Exercises · Workflows · Trust

The situation

A community-sized environment — a campus, a building portfolio, a multi-tenant venue, a city district — runs many services for the same population. Each service has its own interface, its own data, its own onboarding. The shared population experiences disjointed daily interactions; peak-hour friction at the most-frequent services becomes a chronic complaint; vendors operating individual services lack the data to anticipate demand or tailor offerings to the population they actually serve.

The default move is a “smart everything” big bang. Procure an integrated platform; onboard every service at once; declare the environment digital. It fails at the first vendor onboarding, because vendors operate at different paces and on different timelines and an integrated platform that requires them all to move together cannot be moved by any one of them.

The discipline

The discipline is to start with the single most-frequent friction point, prove the hub-and-spoke pattern, and let it expand. The hub provides the shared layer — single identity, shared data, common interaction surface — and the first service plugs in. The second service plugs into the hub the first built; it is easier. The third service is easier still. The hub becomes more valuable as more services join, and the network effect is inside the platform — the compounding happens automatically as the federation grows.

The discipline also names what the hub is for. The hub is not the services. The hub is the shared layer that lets the services be federated rather than siloed — identity, data, observability, recourse. The services remain distinct, run by whoever runs them best.

Where it sits

This pattern exercises workflows and trust together. Workflows, because the federation is the workflow redesign — a service-by-service expansion replaces the all-at-once procurement, and the population’s daily experience is redesigned around the hub rather than around each vendor’s interface. Trust, because the operational data captured at every hub interaction becomes the shared evidence base — the vendors get demand signals they could not generate alone, the environment owner gets occupancy insights, and the population gets recommendations grounded on what the system has actually observed.

In the five-level autonomy model, the hub-and-federated pattern is one of the cleanest paths from Level 2 to Level 3 in environments where no single party owns the population. The hub owns the observability and the policy; the services own their delivery; the autonomy lives in the routing between them.