# Airport Operational Database The AODB is the central nervous system of an airport. Every operational system connects to it: flight information displays, gate management, baggage handling, ground handling coordination, billing, and the A-CDM platform. It holds the single source of truth for flight schedules, actual times, stand assignments, and resource allocation. The problem: most AODBs were built in the 1990s and 2000s as monolithic systems with bespoke integrations to every downstream application. Replacing the AODB is like replacing the foundation of a building while people are still living in it. Politically painful because every stakeholder depends on it. Technically painful because every integration is custom. This is a textbook [[data gravity]] problem. The AODB accumulates operational data from every system at the airport. The more systems connect to it, the harder it becomes to switch. Legacy vendors (SITA, Amadeus, Inform) understand this and use the AODB as an anchor for bundling additional services. See [[Incumbent Bundling Risk]]. The modern alternative: decouple the database from the integration layer. Build a real-time data fabric that ingests from the AODB and other sources, contextualizes it using [[Knowledge Graphs for Industrial Data]], and serves it to optimization systems through standard APIs. This lets new optimization layers sit above the legacy AODB without requiring replacement. The pattern is the same as [[API First Development]] in software: abstract the data layer so the intelligence layer can evolve independently. Related: [[Airport Collaborative Decision Making]], [[Airport Operations MOC]], [[data gravity]], [[Knowledge Graphs for Industrial Data]] --- Tags: #deeptech