Why the architectural decisions made on use case one determine the cost of use cases two, three, and beyond

There is a decision that every airport technology team faces, usually early in its AI programme, that is easy to defer and expensive to get wrong. It is not a decision about which use case to start with — that question gets significant attention. It is a decision about how to build the first use case in a way that does not require the architecture to be rebuilt from scratch when the second one arrives.

Most airport AI programmes begin with a single, well-defined problem: stand allocation, workforce scheduling, dynamic pricing. The team identifies the use case, scopes the solution, secures the investment, and builds. The solution goes live. It delivers results. And then the business asks the natural next question: can we do the same thing for check-in desk allocation? For cleaning team deployment? For security staffing?

If the first solution was built as a standalone application — with its own data connectors, its own optimisation logic tightly coupled to the specific constraints of stand allocation, its own user interface built for that one workflow — the answer to that question involves either a painful integration project or rebuilding significant portions of the stack. The second use case costs almost as much as the first. So does the third. The programme becomes a sequence of expensive, largely independent builds rather than a compounding investment.

Modular architecture is the design discipline that prevents this. It is not a technology choice — it is a set of intentional decisions about how to separate the components of an AI system so that the capabilities built for one use case can be reused, extended, and reconfigured for the next without structural redesign.

This article explains what those decisions are, why they matter specifically in airport operations, and what a modular architecture for airport AI looks like in practice.

The Monolithic Trap

The monolithic approach to airport AI is not the result of poor engineering. It is usually the result of good intentions applied under time and budget pressure. When a team is tasked with solving a specific problem — optimise stand allocation, reduce workforce planning overhead — the fastest path to a working solution is to build tightly around that problem. Hardcode the specific constraints. Build the data connectors for the specific systems that problem requires. Design the interface for the specific users who will operate that solution.

The result is a solution that works well and is delivered on time. It is also a solution that cannot be extended without significant rework. The data pipeline built for stand allocation connects to the Airport Operating System in a way that is specific to the stand allocation domain. The optimisation model encodes stand constraint logic in a form that cannot easily accommodate the different constraint types of workforce scheduling. The user interface is designed for the allocator role, not for a supervisor managing task assignments.

When the second use case arrives, the options are: build another standalone system (duplicating data connectors, integration logic, and monitoring overhead), attempt to extend the first system in ways it was not designed for (accumulating technical debt), or rebuild on a more extensible foundation (paying the architectural cost that should have been paid upfront).

None of these options is good. All of them are more expensive than designing for reuse from the outset.

>40%  of agentic AI projects will be cancelled by end of 2027 due to escalating costs, unclear business value, or inadequate risk controls — the majority of which trace to architectural decisions made at the start, not capability gaps (Gartner, 2025)

The cost of the second use case is determined by decisions made during the first. An architecture that is not designed for reuse will charge a structural redesign tax on every subsequent use case that attempts to build on it.

What Modular Actually Means in Practice

Modular architecture in the context of airport AI means decomposing the system into components that can be developed, deployed, and maintained independently — and that communicate through well-defined interfaces rather than direct coupling. The key components are:

The Data Integration Layer

The data integration layer is responsible for connecting to source systems — the Airport Operating System, Time and Attendance, airline booking data, ATC feeds, sensor networks, reservation platforms — and making that data available in a standardised form that other components can consume. It handles data ingestion, normalisation, quality validation, and the real-time update mechanisms that live operational systems require.

In a modular architecture, this layer is built once and shared. Stand allocation consumes flight schedule data through the same connector that workforce scheduling uses. The data quality logic applied when an ATC slot change arrives is applied consistently, regardless of which downstream optimisation model is consuming it. When a new source system needs to be integrated — a new airline booking feed, a new sensor network, a new financial system — it is integrated into the data layer, and all downstream components benefit automatically.

This is the layer that most monolithic architectures fail to abstract properly. When data connectors are built into specific use case applications, each new use case requires its own connectors to the same source systems. The integration cost is paid repeatedly. The maintenance overhead multiplies. And the risk of data quality inconsistencies between use cases — because the same source data is being processed by different, independently maintained pipelines — grows with every new addition.

The Optimisation Core

The optimisation core contains the algorithmic logic that generates recommendations: demand forecasting models, constraint-based allocation engines, predictive analytics, and simulation frameworks. In a modular architecture, this core is built around generalised capabilities that can be configured for specific domains through rules packs and constraint sets, not hardcoded for a single use case.

Consider the family of problems that airport AI addresses: stand allocation, workforce scheduling, check-in desk assignment, security lane management, car park pricing. At the algorithmic level, these are all variants of the same class of problem — optimising the assignment of resources (physical or human) to demand (flights, passengers, bookings) subject to a set of constraints (physical compatibility, regulatory requirements, business priorities) with the objective of maximising an operational or commercial outcome.

An optimisation core designed to be domain-agnostic — parameterised by constraint sets and objective functions rather than hardcoded for stands or staff — can be configured for each of these use cases by changing the parameters, not rebuilding the engine. Stand allocation uses one constraint set and one objective function. Workforce scheduling uses a different one. The underlying solver, the data consumption pattern, and the recommendation generation mechanism are shared.

The Rules and Configuration Layer

The rules layer is where domain-specific business logic lives: the eligibility criteria for assigning an aircraft type to a stand, the prioritisation framework for deploying staff when shortages occur, the pricing bands and demand thresholds for dynamic car park pricing. In a modular architecture, this layer is explicitly separated from both the data layer and the optimisation core.

This separation has a practical consequence that matters enormously in an airport context: the people who own the rules are not the people who built the system. Stand allocation rules are owned by airside operations. Workforce prioritisation rules are owned by the relevant operations managers. Car park pricing rules are owned by the commercial team. When rules are embedded in code, changing them requires a software development cycle. When rules are externalised into a configuration layer, the business teams can own, update, and test their rules directly — without involving engineering for every operational policy change.

The Decision Support Interface Layer

The interface layer presents AI recommendations to operational users and captures their responses — validations, overrides, adjustments, and the reasons behind them. In a modular architecture, the interface layer is built on a common framework that can be configured for different user roles and use cases, rather than rebuilt from scratch for each one.

The core UX requirements of airport AI decision support are consistent across use cases: present the recommendation clearly, show the rationale, allow override with reason capture, display confidence levels and flagged constraints, support scenario comparison. A common interface framework that instantiates these patterns for each use case — with domain-specific labels, data displays, and workflow steps — is significantly cheaper to build and maintain than a separate bespoke interface for each operational domain.

The Monitoring, Lifecycle, and Audit Layer

Production AI systems require ongoing monitoring: model drift detection, data quality alerts, recommendation accuracy tracking, user adoption metrics, and performance management. In a modular architecture, these capabilities are built as shared infrastructure that all use cases report into, rather than each use case managing its own monitoring independently.

The audit trail requirements of airport AI — who received which recommendation, what they did with it, what the outcome was — are also consistent across use cases, and are built into the shared monitoring layer. This produces a cross-use-case performance view that enables genuine programme-level optimisation: comparing the relative accuracy and adoption of recommendations across different domains, identifying where model improvement investment will deliver the highest return, and maintaining the audit records that regulatory and governance requirements demand.

The Airport Use Case Map: Why the Chassis Matters

The value of modular architecture becomes concrete when mapped against the actual portfolio of airport AI use cases that a programme will eventually address. Consider the following use cases that a typical mid-to-large airport operator would want to deploy over a three-to-five year horizon:

1. Demand Based Resource Allocation: Aircraft stand allocation across seasonal, tactical, and live operational time horizons.

2. Terminal Service Delivery: Daily task allocation plans for passenger-facing staff, driven by flight schedules and real-time demand.

3. Commercial Car Parks: Staff deployment across multiple car park locations based on occupancy and booking patterns.

4. Retail Staffing: Skills-based deployment of specialist and multi-skilled duty free staff aligned to passenger profile.

5. Check-in Desk Allocation: Assignment of check-in resources to airlines and flights based on passenger volume and dwell time requirements.

6. Security Lane Management: Lane opening and staffing recommendations based on real-time passenger throughput and demand forecasts.

7. Dynamic Pricing: Revenue optimisation for commercial car parks, lounges, and ancillary services based on demand elasticity and booking patterns.

8. Cleaning and Facilities: Deployment of cleaning and maintenance teams based on terminal occupancy, flight activity, and service standards.

Now consider what a modular architecture means for this portfolio. The data integration layer connects to the Airport Operating System, Time and Attendance, and booking data once. Every subsequent use case that needs flight schedule data, roster data, or booking data consumes it through the same validated, maintained pipeline. The optimisation core handles the assignment and scheduling logic for stands, staff, desks, and lanes — each configured through a different rules pack, but running on the same solver. The interface layer presents recommendations to allocators, supervisors, and commercial managers through a consistent, role-configured framework. The monitoring layer tracks performance and audit trails across all of them.

The first use case — typically stand allocation or workforce scheduling — funds the construction of the chassis. Every subsequent use case leverages it. The marginal cost of adding a new use case is the cost of building the rules pack and the domain-specific configuration, not the cost of rebuilding the data layer, the optimisation engine, the interface framework, and the monitoring infrastructure.

By 2028  Gartner predicts 50% of enterprises will have shifted from monolithic AI models to modular, composite AI architectures to improve agility and governance — a transition that airport operators designing programmes now can lead rather than follow

The Total Cost of Ownership Argument

The TCO case for modular architecture is compelling across three dimensions: development cost, operational cost, and innovation velocity.

Development Cost

The upfront investment in a modular chassis is higher than the upfront investment in a purpose-built standalone solution for a single use case. The data abstraction layer, the generalised optimisation core, and the common interface framework require more engineering effort than a tightly coupled application built for one domain. This cost difference is real and should be stated honestly.

It is also recovered rapidly. Industry analysis consistently shows that the second use case built on a modular platform costs 40–60% less than the first, because the shared infrastructure is already built. The third use case costs proportionally less again. By the time an airport programme has delivered four or five use cases, the cumulative investment in the modular approach is significantly lower than the cumulative investment in an equivalent sequence of standalone builds — while the operational coverage and cross-use-case integration are substantially better.

Operational Cost

Standalone AI applications each carry their own operational overhead: data pipeline maintenance, model monitoring, incident response, dependency management, and upgrade cycles. In a portfolio of six independent airport AI applications, this overhead is paid six times. In a modular platform, it is paid once — shared across all use cases, with the per-use-case marginal cost declining as the portfolio grows.

This matters particularly for model lifecycle management: the ongoing work of detecting when model performance has degraded, retraining on updated data, validating improvements, and deploying new versions without disrupting live operations. In a modular architecture, this capability is built into the shared infrastructure and applied consistently across all use cases. In a portfolio of standalone systems, each system manages its own model lifecycle independently — multiplying both the engineering effort and the risk of inconsistent quality standards across the portfolio.

Innovation Velocity

The third dimension of the TCO argument is the speed at which the organisation can respond to new requirements and opportunities. When a new operational need emerges — a new location, a new resource type, a new regulatory requirement — a modular platform can accommodate it by adding a new rules pack and configuring existing components. A portfolio of standalone systems requires each affected system to be individually updated, tested, and redeployed.

In a sector where passenger volumes, regulatory frameworks, and commercial models are all evolving continuously, this innovation velocity advantage compounds over time. The organisation that built its AI on a modular chassis can keep pace with change at low incremental cost. The organisation that built a sequence of standalone applications faces a growing maintenance burden and an increasing gap between its AI capabilities and its operational requirements.

The Design Decisions That Matter at the Start

For airport technology and operations leaders commissioning an AI programme, the architectural decisions that determine whether the programme delivers compounding value or a sequence of expensive rebuilds are made early — typically during the design of the first use case. The questions to ask at that point are:

1. Is the data integration layer being built as shared infrastructure, or as a component of this specific application? If the answer is the latter, every subsequent use case will need its own connectors to the same source systems.

2. Is the optimisation logic parameterised or hardcoded? A solver that takes constraint sets and objective functions as inputs can serve multiple domains. A solver whose logic is written for stand allocation cannot serve workforce scheduling without a rewrite.

3. Who owns the rules, and how do they change them? If operational policy changes require a software development cycle, the rules are embedded in the wrong place. Business-owned, externally configurable rules packs are both more operationally flexible and more architecturally reusable.

4. Is the interface built on a common framework or custom-built for this use case? A common decision support interface framework is an asset that every subsequent use case inherits. A bespoke interface is a cost that every subsequent use case repeats.

5. Is the monitoring and audit infrastructure shared or per-application? Cross-use-case performance visibility, consistent audit trail standards, and centralised model lifecycle management are only possible if the monitoring layer is built as shared infrastructure from the start.

These questions do not require a fully specified modular architecture before the first use case is built. They require a commitment to the design principles that will make subsequent use cases additive rather than duplicative. The detailed architecture can evolve as the programme matures; the principles must be established from the outset.

What the Industry Signals

The direction of the enterprise technology industry on this question is unambiguous. Gartner's top strategic technology trends for 2026 explicitly identify multi-agent systems — modular AI agents that collaborate on complex tasks — as a primary architecture pattern, alongside domain-specific models that deliver higher accuracy within defined domains. The composability principle is central to both.

Gartner's prediction that by 2028, 50% of enterprises will have shifted from monolithic AI models to modular composite architectures reflects the market reality that organisations that built monolithic AI are facing exactly the rework costs described above — and are rebuilding on more extensible foundations. Airport operators designing AI programmes today have the opportunity to skip that rework cycle by building modular from the start.

The parallel development of standardised integration protocols — including the Model Context Protocol (MCP), which enables AI systems to connect to external data sources and tools through a common interface — is making modular AI architecture increasingly practical to implement. The fragmentation that once made modular systems harder to build than monolithic ones is reducing as the standards layer matures.

For airport operators, the practical implication is that the technology ecosystem is moving in the direction that modular airport AI requires. The integration standards, the optimisation platforms, the monitoring infrastructure, and the interface frameworks that make a modular approach viable at manageable cost are more mature today than at any previous point. The window for building the right architecture from the start — rather than migrating from a monolithic one later — is open now.

From Use Case to Programme

The airports that will extract the most value from AI investment over the next decade are not necessarily the ones that build the most sophisticated first use case. They are the ones that build the first use case in a way that makes every subsequent use case faster, cheaper, and more reliable to deliver.

That is what modular architecture delivers: not just a better version of the first solution, but a compounding capability that grows more valuable with every use case added to the platform. The stand allocation system and the workforce scheduling system and the dynamic pricing system are not three separate investments — they are three instantiations of a shared platform that becomes more powerful and more defensible as the portfolio expands.

The decision to build for scale is made at the beginning of the programme, not the middle. It requires accepting a somewhat higher upfront investment in architecture and a somewhat longer initial delivery cycle. It produces, in return, a programme that delivers accelerating value as it matures — rather than one that accumulates technical debt with every new use case and eventually requires the kind of structural redesign that makes even well-resourced organisations wince.

For airport operators making AI investment decisions now, the most important question is not which use case to start with. It is: how are we going to build the first one so that the second one benefits from it? Visit us for more information.