Sixteen Stadiums, One Screen: The Case for a Real Operational Command Layer

Sixteen venues. Three countries. Four time zones. 104 matches over five weeks, each one drawing tens of thousands of people through a handful of gates inside a ninety-minute window.

The operational answer for this tournament was a single command environment — Lenovo’s Intelligent Command Centre — giving tournament operators a unified view across all sixteen stadiums at once, with security, ticketing, crowd management, venue infrastructure and operational telemetry consolidated rather than siloed per venue. Digital twin models of the stadiums and their surroundings ran alongside it, monitoring crowd movement and predicting congestion before it formed. Around 350 engineers and over 17,000 devices sat underneath.

I bring this up not because most organisations need to run sixteen stadiums, but because most organisations already have the sixteen-stadium problem and are solving it with browser tabs.

The tab problem#

Walk into the operations office of a mid-sized hospital group, a university with four campuses, or a logistics operator with a dozen depots, and count the screens. Not the dashboards — the systems.

There is the access control system, which knows who came through which door. The ticketing or appointment system, which knows who was supposed to. The building management system, which knows the air handling is struggling in the east wing. The rostering tool, which knows two staff called in sick. The incident log, which is a spreadsheet. Somewhere there is a WhatsApp group where the actual coordination happens.

Every one of those systems is individually fine. The failure is that no single surface can answer a question that spans two of them, and every question that matters spans at least three. “Why is the east entrance backing up” requires access control plus rostering plus whatever is happening in the car park. Nobody can answer it in under ten minutes, and the congestion resolves or escalates in five.

That is the actual gap the command centre model closes. Not prettier dashboards. A join.

What a digital twin is and is not#

The phrase has been abused hard enough that it is worth being precise, because we get asked to build “a digital twin” by clients who mean six different things.

It is not a 3D render. A photorealistic model of your building with no live data behind it is architectural visualisation, and it is a very expensive screensaver.

It is not a dashboard. A dashboard shows you the present. A twin’s value is that it can be asked about a future that has not happened.

A useful operational digital twin is three things stacked:

1. A spatial model of the environment — where the gates, corridors, ramps, wards, and chokepoints physically are, and how they connect.
2. Live telemetry bound to that geometry — counts, flows, occupancy, and status attached to the specific places they describe, not floating in a metrics namespace.
3. A simulation you can interrogate — given current inflow and this gate closing, what does the concourse look like in eight minutes?

The third item is the one that earns the name. Without it you have a map with numbers on it. With it you have a system that lets an operator open extra lanes before the queue forms rather than after it appears on a camera.

The stadium version reportedly monitored crowd flow, anticipated congestion, and directed where to deploy staff — with smart cameras detecting unusual density in a section without necessarily identifying individuals. Operators could see which entrances were backing up, which concourses were clogged, and where concessions were overwhelmed, then open lines, shift staff, or redirect fans.

Read that list again. Detect, predict, act, verify. That is a control loop, and the reason it works is that all four steps happen on the same data in the same place.

The architecture underneath#

When we build this for clients, the shape is consistent and considerably less exotic than the marketing implies.

A spatial registry. Every physical location that matters gets a stable identifier and a place in a hierarchy — site, zone, area, point. This sounds trivial. It is the single hardest part of the project, because in almost every organisation the door is called EAST-02 in access control, Entrance B in the fire plan, and main east in the maintenance ticketing system, and nobody has ever reconciled them. Budget real time for this.

An event spine. Every subsystem publishes events against those identifiers rather than into its own silo. Card swipes, scans, counts, alarms, staff check-ins. Same schema, same clock discipline, one stream.

A fast operational store. Not the warehouse the finance team queries overnight. Operators ask questions with a five-second tolerance, which is why our default here is ClickHouse behind the event spine — sub-second aggregation over the raw grain, so the twin can answer “occupancy by zone over the last four minutes” without a pre-computed rollup for every question anyone might ask.

A prediction layer that is allowed to be simple. The forecast that prevents most congestion is not a deep model. It is inflow rate, service rate, and queueing theory, applied per chokepoint, refreshed every thirty seconds. Start there. Add learned models when the simple one demonstrably fails, not before.

One surface. If the operator has to switch context to act on what they see, you have built a reporting tool.

Why this matters well outside sport#

We deploy the same stack in two verticals constantly.

A Hospital Management System with a real command layer changes what a bed manager can do. Instead of phoning three wards to find out what is actually free, they see live occupancy against expected discharges, with the pharmacy and portering delays that gate those discharges surfaced in the same view. The predictive question — given current ED arrivals and the theatre list, when do we run out of beds in the medical assessment unit — is exactly the congestion forecast, with wards instead of concourses. The chokepoints are just as physical and the cost of finding out late is much higher.

A School ERP on a multi-campus trust has a smaller but structurally identical version: attendance, transport arrivals, facilities faults, and staff cover on one surface, so a cover manager at 07:40 can see the two absences and the late bus together instead of discovering them separately at 08:05.

In both cases the objection we hear is that the organisation is “not big enough to need a command centre.” That is the wrong axis. You do not need it because you are large. You need it because your questions cross system boundaries and your response window is shorter than your investigation time. A four-site clinic group hits that threshold comfortably.

The uncomfortable part#

The tournament had one enormous advantage most enterprises do not: a deadline that could not move and an owner who could mandate integration. Every subsystem vendor knew the date, and nobody got to opt out of publishing their data.

In a normal organisation, the barrier to a command layer is never technical. It is that the access control vendor’s contract does not include an API, the ticketing system is on-premise and version-locked, and the facilities team does not report to whoever is sponsoring the project. The engineering is a few months. The integration politics are the project.

Which is the actual advice: start by writing down, honestly, which of your operational systems can emit an event to a stream today, which could with a change request, and which never will without a replacement. That document is your real roadmap, and it takes an afternoon to produce.

---

A command layer is mostly a data platform with a map on top — and it lives or dies on whether your subsystems will talk. We have done this integration in hospitals, campuses and depots. Tell us what your operators are missing.