.png)
An API-first AODB is an airport operational database whose integration points are built and documented as separate, independently deployable interfaces rather than wired into the application itself. SkyCore AODB is built that way, and the difference shows up in procurement rather than in the demo. An airport running an API-first AODB can replace an adjacent system, add a specialist product, or feed a third-party platform without its database vendor standing between it and the change.
TL;DR
A monolithic AODB closes an airport's options one integration at a time. A modular, API-first one keeps the next ten procurement decisions with the airport.
1. The integration tax, not the licence fee, is the highest avoidable cost in a ten-year AODB contract.
2. SkyCore AODB is the operational data layer; the AirportLabs Data Router is the integration and API platform. Separate products, separately documented.
3. Stand and gate allocation is Allegra RMS, passenger screens are VisionAir FIDS, turnaround management is GCAM. The AODB feeds them rather than absorbing them.
4. ESB emulation mode lets a new AODB run in parallel with the legacy one on the same live data, so a replacement is proven before it is committed to.
What is the integration tax in an AODB contract?
The integration tax is everything an airport pays over a contract's life to connect systems it could not competitively source, because the only party able to build the connection is the vendor that sold the database. It almost never appears as a line item at tender stage, and over ten years it can exceed the licence fee.
The pattern is familiar to anyone who has sat through an airport IT procurement. A large, established vendor offers a comprehensive operational suite: AODB, resource management, FIDS, billing, ground handling coordination, all under one contract. The proposition is genuinely attractive. One vendor, one support relationship, one commercial conversation.
Ten years on, the airport wants to replace passenger processing with a specialist product. Or bolt on a stand allocation optimiser. Or push operational data into the analytics platform its parent group has standardised on. And it starts to matter, in a way it did not at signature, how many of those connection points are proprietary, and whose professional services team has to build the next one, on whose timeline, at whose price.
SkyCore AODB was built on a different premise.
What does a monolithic AODB cost an airport?
A monolithic AODB couples database, business logic, presentation layer and integration points into one indivisible unit, so changing any part carries the risk of destabilising the rest, and any new capability arrives through the vendor's release cycle. The cost is not paid in licence fees. It is paid in the capabilities the airport cannot adopt.
That shape is increasingly at odds with where the industry frameworks point. EUROCONTROL's standards catalogue covers airport integration alongside communications, navigation and surveillance, digitalisation and information management. An AODB that cannot handle IATA's SSIM schedule formats or ACI's ACRIS and AIDX data exchange is not making a neutral technical choice. It is accumulating an operational liability.
Deferred modernisation compounds in three directions at once. Maintenance cost rises, integration capability declines, and exposure grows as vendor support thins. In airport operations, the second of those is the one that quietly sets the ceiling on everything else the airport wants to do. An operation cannot adopt what it cannot connect.
What makes SkyCore AODB modular?
SkyCore AODB delivers its core functions as decoupled components, each developed, tested, and deployed independently on containerised microservices, so individual features can be enabled, disabled, or configured without disrupting the rest of the solution. A new version of one module ships without touching the flight data pipeline or the messaging layer.
It is a cloud-based system that runs in a browser with no on-site install, and it supports single-airport, multi-airport, and multi-terminal deployments. It unifies arrivals and departures, seasonal schedules, check-in and baggage particulars, delay and load data, aircraft and airline reference data, a full audit trail, and role-, group-, and organisation-based access.
The modularity is both commercial and architectural. An airport pays for the components that add value to its operation, which is a smaller-sounding claim than it is until you set it against a suite licence that bundles capabilities the airport neither uses nor can remove.
Configuration sits with the airport rather than in our development queue. The Rule Engine Editor lets authorised users build formatting, alerting and calculation rules over operational data without writing code, and every rule must pass a simulation, actual output matched against expected output, before the deploy action becomes available at all. One rule set is live at a time, and a superseded one can be force-redeployed to roll back.
Modular or monolithic: what changes in practice
The difference is not felt at go-live. It is felt every time the airport wants to change something afterward.
Read down the middle column. Every row is a decision the airport has handed to somebody else for the length of the contract.
Who governs the integrations, the AODB or the integration layer?
The integration layer is a separate product, not a hatch cut into the side of the database. The AirportLabs Data Router is a scalable, redundant, fault-tolerant data integration and API platform in its own right, and SkyCore AODB is the authoritative operational data layer. The Data Router is how data reaches and leaves it.
That separation is the substance behind the architecture argument, and it is evident in what the Data Router connects to: airline management systems, check-in and baggage systems, aviation authorities, schedule and slot coordinators, ground handler systems, FIDS, billing platforms, and business intelligence tools. Exchange runs in both directions, with per-field selection where several systems claim the same value, and selective parsing so a single field can be extracted without processing the whole message. The Data Router works with the message formats that an airport's counterparties already use, not a private dialect invented by a single supplier.
Monitoring works at the level of the individual interface rather than the aggregate: health indicators per interface, configurable alerts including self-adjusting thresholds, and message age, volume and errors collected per integration. An airport finds out which connection degraded, and often whose system caused it.
The same discipline applies across the portfolio. Stand and gate allocation is Allegra RMS. Passenger-facing screens are VisionAir FIDS. Turnaround task management is GCAM. Those are separate products with their own interfaces, fed from the AODB rather than fused into it. An airport buying SkyCore is buying the data layer, not a bundle that quietly re-monolithises under a different name.
What does an airport's AI strategy need from its AODB?
Clean, timestamped, source-attributed operational data, available in real time to something that is not the AODB. That makes it an integration question before it is a modelling question.
Turnaround prediction, stand allocation optimisation, queue forecasting and predictive maintenance all run on the same input. An airport that has to raise a change request to expose A-CDM timestamps such as ATOT and AIBT to its own data science team has an AI strategy running at its AODB vendor's release cadence.
SkyCore AODB's position here is deliberate. It is the authoritative record rather than the prediction engine, and the prediction and optimisation layers in our own portfolio are named separately: stand and gate allocation is Allegra RMS, queue and passenger flow prediction is Laminar. Different tools for different jobs, bought separately, and an airport should not have to buy one to get the other.
Data is sent via webhooks to downstream systems on configurable event-based or time-based triggers. Source attribution is tracked per field, not just per message: the platform shows the contributing sources behind a single value, an ATOT with three contributing source times being its own documented example, and user input counts as one of those sources. Whether that attribution travels in the outbound payload to a consuming model, rather than being visible only within the platform, is not documented.
Where determinism matters more than prediction, the rule engine handles it, and the airport writes the rules rather than requesting them. What the airport builds on top of the data layer, and who builds it, stays the airport's decision.
Can an airport migrate off a legacy AODB without a big-bang cutover?
Yes, by running both systems on the same live data until the comparison is no longer interesting. The Data Router has an ESB emulation mode: it extracts operational data from the airport's existing enterprise service bus or main data source without disrupting the current operational system, so the same feeds run into both platforms throughout implementation and testing.
The airport compares the new parsed output against the system it already trusts, adjusts as needed, and cuts over when it is satisfied, rather than on a date set by a migration plan. This is the part of an architecture story a closed system finds hardest to answer, because it requires the incoming platform to tolerate the outgoing one for as long as the airport needs.
What does this change for an airport IT director?
Three things: competitive procurement at every renewal, internal build capability, and a smaller integration bill. None of them also depend on AirportLabs winning the next tender.
Competitive procurement at every renewal. Because the components are separable and documented separately, the airport retains the option to tender any adjacent capability on its own merits. If a better FIDS product emerges, it can be integrated. If a specialist billing platform makes more sense, it can take that function.
Internal build capability. Every integration comes with an Interface Control Document, a per-integration technical guide that lets a third-party system or the airport's own team build directly against the data layer. That is a defined surface, not a support ticket and a quote. Whether an airport can see those documents before it signs is a separate question.
Lower integration cost. The hidden cost of a closed system is not the licence. It is the integration tax: custom connectors, proprietary middleware, professional services charges on every new connection. Standard formats and a documented connector model turn most of that from a project into routine work.
Three questions to ask your current AODB vendor
1. If you wanted to replace your FIDS with a competitor's product next quarter, could your AODB accommodate it without a major integration programme?
2. If you wanted to feed operational data to a third-party analytics platform, could you do it without your AODB vendor's professional services team?
3. If that vendor were acquired, exited the market or repriced sharply at renewal, would you have a credible path to an alternative, and could you run it in parallel while you proved it worked?
Three noes describe an architecture that has quietly become a constraint, and the operating environment is not getting simpler. EUROCONTROL's Seven-Year Forecast for 2026 to 2032 records significant reroutings and altered traffic patterns across affected corridors, and states plainly that it is impossible to predict when currently restricted airspaces will be fully reopened. That is not a software problem. It does get harder to answer from a system that cannot be extended without permission.
Architecture is now part of what an airport buys
The ability to integrate and adapt without asking a vendor's permission has become part of what an airport buys when it buys an AODB, whether or not the tender document says so. Operational suites built for stable, siloed systems made sense when airport IT looked like that. It no longer does.
SkyCore AODB's modular architecture and the AirportLabs Data Router exist to keep those decisions with the airport: adopt the best available product at each layer, connect it in the formats the industry already speaks, and prove a replacement works against live data before committing to it.
References
EUROCONTROL Standards Catalogue, updated 24 August 2026.
EUROCONTROL Seven-Year Forecast 2026 to 2032, Spring 2026.
IATA Aviation Information Data Exchange (AIDX).
IATA Standard Schedules Information Manual (SSIM).
EUROCONTROL, Airport Collaborative Decision-Making (A-CDM).
EUROCONTROL A-CDM Implementation Manual.
Frequently asked questions
What is an AODB?
An airport operational database is the authoritative record of an airport's flight operations: schedules, arrivals and departures, turnarounds, A-CDM timestamps, and the reference data behind them. Other systems, from passenger screens to billing, read from it rather than keeping their own version.
What is an API-first AODB?
An AODB whose integration points are built and documented as separate, independently deployable interfaces rather than wired into the application. It lets an airport replace an adjacent system, add a specialist product, or feed a third-party platform without its database vendor in the way.
What is the integration tax?
Everything an airport pays over a contract's life to connect systems it could not competitively source, because the only party able to build the connection is the vendor that sold the database. It rarely appears as a line item at tender stage.
Can an airport replace its FIDS without replacing its AODB?
With a modular architecture, yes. Passenger-facing screens are a separate product fed from the operational data layer, so the airport can tender that layer on its own merits and integrate the result through documented interfaces.
What is ESB emulation mode?
A mode in which the AirportLabs Data Router stands in for an airport's existing enterprise service bus, ingesting the same upstream sources and producing its own pipeline into SkyCore AODB while the legacy bus and AODB keep running. Both pipelines work the same source data at the same time, so the airport can compare outputs before cutting over.
Does a modular AODB mean managing more vendors?
It means keeping the option to. An airport can still buy several layers from one supplier; what changes is that it is no longer obliged to do so, and each renewal can be tendered on its own merits.
Book a 30-minute architecture review
Bring your current integration map. We will walk through which of your connection points could move to documented interfaces, which would remain with your existing vendor, and what a parallel run against your live operational data would entail. No slides.
