Walk into the operations centre of a busy international airport and count the screens.

There is always more than you expect.

AODB. Gate management. BHS. ATC coordination. Ground handler scheduling. Turnaround management. Passenger flow. Security operations. Lounge management. Baggage reconciliation. Each one live. Each one staffed by someone who needs accurate information right now. Each one built by a different vendor, maintained by a different team, and speaking a completely different data language to all the others.

Nobody planned for this. It accumulated, one system at a time, over years, as airports grew and operational requirements evolved and technology vendors sold solutions to individual problems without anyone stepping back to ask how it was all supposed to work together.

The answer, at most airports, is that it does not. Not really. Not in the way it needs to.

According to Eurocontrol's Performance Review Report 2023, ground handling and turnaround coordination consistently rank among the leading causes of avoidable ATFM delay across European airports. Delays that trace directly back to information gaps between operational systems. The data exists. It simply does not reach everyone who needs it, at the moment they need it.

That gap, between the data that exists and the data that is actually shared, accurately, in real time, is where most preventable operational problems begin.

What each system actually produces

It helps to be concrete about this because the integration challenge only becomes real when you understand what each system is doing and who depends on it.

The AODB is the master record for everything flight-related. Planned times, actual times, stand allocation, terminal assignment. It is the source of truth – or it is supposed to be. Airlines, ground handlers, gate management teams, and passenger information systems all work from AODB data. When it is wrong, late, or inconsistent with what ATC has issued, the effects ripple immediately.

The BHS produces a continuous stream of baggage events. Every scan, every belt allocation, every transfer. The baggage operations team lives in this data. But so does turnaround management, because bag load completion is one of the signals that triggers pushback clearance. Two teams. One data source. Different needs from the same information.

ATC produces slot assignments, movement authorities, and runway sequencing. When ATC revises a CTOT, that change needs to reach the AODB, gate management, the ground handler, and the turnaround coordinator at the same moment. Research published in the _Journal of Air Transport Management_ documents that information asymmetry between ATC and ground operational stakeholders is a primary driver of coordination-related delay. Not process failure, not staffing, but data that does not arrive where and when it needs to.

Gate management produces stand assignments and live stand status. When a stand changes, and at a busy hub stands change constantly, the downstream impact is immediate. Ground crews reposition. Baggage belts reallocate. Passengers need updated gate information. That one data point touches at least six other systems the moment it moves.

PMS produces check-in status, passenger counts, and connection risk flags. According to IATA's Global Passenger Survey 2023, accurate real-time flight and gate information remains one of the top passenger experience priorities globally, which means the PMS data feed to passenger-facing systems is not just an operational concern. It is a commercial one.

Every one of these systems serves a different operational master. And all of them affect each other, constantly, in ways that cascade the moment any single data point changes and does not reach everywhere it needs to, fast enough.

This is the architecture problem. Not a technology problem. An architecture problem.

Three ways airports try to solve it

Over eleven years of deployments, we have seen airports approach this in three different ways. Two work up to a point. One actually scales.

Point-to-point integration

The instinctive first move. System A needs data from System B, so someone builds a direct connection. Then System A needs data from System C. Then System D needs to send to Systems E, F, and G.

At five systems it is manageable. At ten it is getting complicated. At thirty, which is not unusual for a large hub, you have potentially 870 individual point-to-point connections to build, certify, monitor, and keep alive. Each one has its own failure mode. Each system update risks breaking connections downstream. The whole thing becomes a web that no single person fully understands.

This is the most common integration model in aviation. Not because anyone chose it. Because it is what happens when you solve integration problems one at a time, over years, without a plan.

The mathematical reality here is straightforward: the number of potential connections in a fully connected network of n systems is n(n-1)/2. At 30 systems, that is 435 bidirectional pairs, each requiring its own integration logic, monitoring, and maintenance.

Hub-and-spoke/enterprise service bus

Better. Rather than every system connecting to every other system, all data routes through a central bus. Systems publish to the bus; subscribers receive what is relevant to them. The connection count drops significantly. The architecture becomes something you can actually draw on a whiteboard.

The problem is that most enterprise bus implementations were built for enterprise data: transactional, relatively low frequency, tolerant of a bit of latency. Aviation data is none of those things.

A gate change notification delayed by 90 seconds is not a rounding error. It is a ground handler already driving to the wrong stand. Airlines for America's 2024 cost data puts the average cost of U.S. aircraft block time at $100.76 per minute, which means that 90-second data lag, multiplied across an operation, carries a real and calculable financial consequence. Generic bus implementations route data. They do not understand what the data means operationally, and in aviation, that distinction matters enormously.

Purpose-built aviation data routing

This is the model that works. And it took eleven years of live deployments to build properly.

A purpose-built aviation data router does everything a bus does, and then a layer of things a generic bus cannot. It validates every update against aviation-specific business rules before it propagates anywhere. It knows which system is authoritative for EOBT when AODB and ATC disagree. It handles a BHS update for a flight that has already closed in the AODB, correctly, not generically. It monitors latency not in the abstract, but in the context of what flight phase each data element belongs to.

The difference between a general-purpose integration layer and a purpose-built aviation router is not configuration. It is architecture. Fricke and Schultz's research on turnaround performance identifies the complexity of real-time information exchange during turnaround as a fundamental operational challenge, one that requires systems designed specifically for the sequencing and dependency logic of aviation ground operations, not adapted from other industries.

You cannot configure your way to operational awareness. You have to build it in from the start.

What the architecture actually looks like

A purpose-built aviation data router is not a single integration. It is a layered architecture with four distinct functions, each of which has to work correctly for the whole thing to hold under operational pressure.

Layer 1: Ingestion

Every connected system sends data in its own format, on its own schedule, via its own protocol. AODB pushes IATA AIDX messages. BHS sends proprietary scan events. ATC issues EUROCONTROL-standard AMAN and DMAN sequences. Ground handler platforms use everything from ACARS to REST APIs to flat file exports.

A purpose-built router ingests all of it simultaneously, without any single feed blocking or delaying another. If a system goes offline, the router continues operating on the feeds it has, flags the gap, and resumes the missing feed the moment it recovers. A generic integration layer treats a dropped feed as an error. A purpose-built aviation router treats it as a known operational scenario with a defined handling protocol.

Layer 2: Normalisation

Raw data from twenty-plus sources arrives in different formats, different time zones, different reference systems. An EOBT in one system is an STD in another. A stand identifier in the AODB may not match the stand code used by the ground handler platform.

A purpose-built router maps every incoming data element to a single consistent aviation data model before it touches any downstream system. Not approximately. Exactly. Research on airport data standardisation identifies inconsistent system reference models as one of the most persistent sources of operational data error in airport environments. When two systems disagree on a stand reference, and the router has not resolved that conflict cleanly, the ground handler drives to the wrong location. This is not a hypothetical. It is a scenario that occurs regularly at airports with immature data normalisation layers.

Layer 3: Validation

This is the layer most generic platforms skip entirely. Before any update is distributed, a purpose-built aviation router checks it against operational business rules.

An EOBT that precedes the current time by more than a defined threshold gets flagged, not routed. A stand allocation that conflicts with an existing active occupancy gets held, not pushed. A BHS update for a flight that has already closed in the AODB triggers a specific alert protocol, not a standard distribution.

These are not hypothetical edge cases. They are scenarios that occur at every major airport, every day, and that require aviation-specific logic to handle correctly. A generic router has no concept of what a stand conflict means operationally. A purpose-built one was designed around it.

Layer 4: Distribution

The right data goes to the right system at the right moment, and the sequencing matters.

When a gate changes during active turnaround, the ground handler needs the update before the baggage team does, because the baggage team cannot act until the ground handler has repositioned. When an ATC slot revision arrives, the AODB needs to update before the turnaround management tool does, because the turnaround tool calculates from AODB data.

Distribution is not broadcast. It is sequenced, prioritised, and aware of operational dependency. That sequencing logic is not something that can be configured after the fact. It has to be built into the routing model from the beginning, because it reflects the actual operational dependency structure of airport ground operations.

The monitoring layer

Monitoring sits across all four layers above. Every data flow is tracked in real time, not against generic latency thresholds, but against flight-phase-specific ones.

A 30-second delay on a retail feed is irrelevant. A 30-second delay on a gate change in the final 20 minutes of a turnaround is a priority incident. The router knows the difference because it was built with aviation operational context embedded in its logic. Eurocontrol's CODA Digest consistently shows that airports with higher levels of operational system integration recover from disruption events significantly faster than those without. The monitoring layer is a significant part of why: when the data infrastructure itself surfaces issues in real time, the operations team responds to the actual problem, not to the symptoms that emerge 15 minutes later across five different systems.

What this looks like in a live environment becomes visible under pressure. When an EOBT update arrives simultaneously with a stand reassignment and an ATC CTOT revision, a generic integration layer routes three updates to its subscribers. A purpose-built aviation router identifies that all three relate to the same flight, resolves the sequencing dependency between them, validates each against current operational state, and distributes a coherent, conflict-free picture to every connected system, in the correct order, within milliseconds.

That is what a connected airport actually looks like from the inside. Not a set of integrations. A single live operational picture that every system and every stakeholder shares, at every moment, regardless of what is changing on the airfield.

Getting this right requires understanding aviation at the level of the operation, not the level of the integration specification. That understanding only comes from building it under live operational conditions, absorbing the failure modes that no specification document anticipates, and encoding the fixes into an architecture that holds at scale.

It is the kind of infrastructure that, when it works, nobody thinks about. Which is precisely the point.

Our data approach

At AirportLabs, we have been building this architecture for 11 years, across 100+ airports on four continents. Every layer described in this article – ingestion, normalisation, validation, distribution, monitoring – is live in production at airports worldwide, processing billions of data events every year.

If you want to understand what this looks like for your airport, we would be glad to walk you through it.

Get in touch: airportlabs.com/other/get-in-touch