Implementation Roadmap

This guide provides a structured approach to implementing the AURA Order-Centric Architecture, including module dependencies, parallel workstreams, and a 9-month launch scenario.

New to aviation? Start with the Glossary - a beginner's cheat sheet for all industry terms and acronyms.

Where to Start

The Golden Rule

┌─────────────────────────────────────────────────────────────────┐
│                                                                 │
│   START WITH THE ORDER MANAGEMENT SYSTEM (OMS)                  │
│                                                                 │
│   Everything else depends on it.                                │
│   The Order is the Single Source of Truth.                      │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Why OMS First?

Every other system queries, updates, or reacts to Orders:

SystemDependency on OMS
InventoryDecrements on Order.Status = PAID
PricingCreates offers that become Orders
PaymentsLinked to Order ID
DCSQueries Order.Status for check-in
Load ControlReads passenger count from Orders
NotificationsTriggered by Order state changes

Module Implementation Steps

Phase 1: Foundation (Months 1-2)

1.1 Order Management System (OMS) - CRITICAL PATH

Week 1-2: Data Model
├── Order entity with UUID primary key
├── OrderLineItem for products (seats, bags, etc.)
├── OrderStatus enum (OFFERED → PAID → FULFILLED)
└── Database migrations

Week 3-4: Core APIs
├── POST /orders (create order from offer)
├── GET /orders/{id} (retrieve order)
├── PATCH /orders/{id}/status (state transitions)
└── Order validation rules

Week 5-6: State Machine
├── State transition logic
├── Event emission on state change
├── Timeout handling (OFFERED → EXPIRED)
└── Business rules enforcement

Week 7-8: Integration Points
├── EventBridge integration (order events)
├── Payment callback handling
└── PNR generation (secondary identifier)

Deliverable: Orders can be created, paid, and fulfilled with full audit trail.

1.2 Inventory System (P1-P5 Model)

Week 1-2: Inventory Data Model
├── Flight inventory structure
├── P1-P5 tier definitions
├── Availability counts per tier
└── Database design

Week 3-4: Hold Management
├── Redis integration for 10-min holds
├── Hold creation/release APIs
├── Automatic expiration
└── Race condition handling

Week 5-6: Availability Logic
├── Cascading availability rules
├── Real-time availability queries
├── Inventory decrement on payment
└── Overbooking controls

Deliverable: Inventory can be queried, held, and decremented with proper locking.


Phase 2: Commercial (Months 3-4)

2.1 Offer Engine & Pricing

Week 1-2: Pricing Engine
├── Dynamic pricing algorithm
├── Demand factor calculation
├── Lead time adjustments
└── Competitor price inputs (optional)

Week 3-4: Offer Generation
├── Offer creation from availability
├── Offer validity windows (15 min)
├── Offer-to-Order conversion
└── Offer caching

Week 5-6: NDC Integration
├── /AirShopping endpoint
├── /OfferPrice endpoint
├── /OrderCreate endpoint
└── JSON response formatting

Deliverable: System generates dynamic offers that convert to orders.

2.2 Payment Vault

Week 1-2: Vault Architecture
├── Token storage design
├── Payment gateway integration
├── PCI-compliant data handling
└── No raw card storage (ever)

Week 3-4: Payment Flows
├── Authorization flow
├── Capture on fulfillment
├── Refund processing
└── Reconciliation

Week 5-6: Order Integration
├── Payment → Order.Status = PAID
├── Failed payment handling
├── Retry logic
└── Event emission

Deliverable: Payments processed securely with automatic order status updates.


Phase 3: Customer-Facing (Months 5-6)

3.1 Direct Channels (Web/Mobile)

Week 1-3: Web Booking Engine
├── Flight search UI
├── Offer display
├── Passenger details collection
├── Payment integration

Week 4-6: Mobile App
├── iOS/Android development
├── PKPASS integration
├── Push notifications
└── Offline boarding pass

3.2 Departure Control System (DCS)

Week 1-2: Check-in Service
├── OMS status query
├── IF Order.Status == PAID → allow
├── Seat assignment
└── Boarding pass generation

Week 3-4: Gate Operations
├── Boarding list from OMS
├── Real-time passenger status
├── Gate reader integration
└── Final manifest

Week 5-6: PKPASS & Digital
├── Apple Wallet integration
├── Google Wallet integration
├── QR code generation
└── Dynamic updates

Deliverable: Passengers can check-in and board with digital passes.


Phase 4: Operations (Months 7-8)

4.1 Load Control & EFB Integration

Week 1-2: Weight & Balance
├── Standard weights configuration
├── Actual bag weight capture
├── ZFW/TOW/LDW calculations
└── CoG computation

Week 3-4: EFB Push
├── API for pilot iPads
├── Real-time load sheet
├── Trim data push
└── Late change handling

4.2 Operations Control Center

Week 1-3: OCC Dashboard
├── Flight status overview
├── Delay management
├── Resource visualization
└── Alert system

Week 4-6: Disruption Management
├── IROPS detection
├── Rebooking automation
├── Passenger notification
└── Crew impact assessment

Phase 5: Optimization (Month 9+)

5.1 Cloud Hosting Optimization

Month 9-10: Load & Cost Optimization
├── Auto-scaling policies
│   ├── Lambda concurrency limits
│   ├── API Gateway throttling
│   └── Database connection pooling
├── CDN optimization (CloudFront)
├── Reserved capacity planning
└── Cost monitoring dashboards

Month 10-11: Performance Tuning
├── Database query optimization
├── Redis cache hit rate improvement
├── Cold start reduction (Lambda)
└── Load testing at 10x expected volume

5.2 Protocol & Connectivity

Month 11-12: Internal Service Communication
├── Evaluate gRPC for high-frequency paths
│   ├── Inventory lock/release (sub-ms critical)
│   ├── Internal service-to-service calls
│   └── Real-time load control updates
├── Keep REST/JSON for external APIs
├── HTTP/2 enablement
└── Connection reuse optimization

5.3 Legacy Fee Reduction

Ongoing: GDS Disintermediation
├── Track GDS vs Direct booking ratio
│   └── Target: 100% direct via NDC
├── Monitor savings per booking ($8-13)
├── Aggregator integration expansion
│   ├── Google Flights
│   ├── Skyscanner
│   └── Kayak
└── GDS sunset planning (if applicable)

5.4 Analytics & Intelligence

Month 12+: Revenue Management AI
├── Demand forecasting models
├── Dynamic pricing ML
├── Customer segmentation
└── Ancillary recommendation engine

Deliverable: Optimized cloud costs, sub-100ms response times, zero GDS fees.


Parallel Workstreams

Multiple teams can work simultaneously on independent modules:

┌─────────────────────────────────────────────────────────────────┐
│                    PARALLEL WORKSTREAMS                         │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  Month 1        Month 2        Month 3        Month 4          │
│    │              │              │              │               │
│    ▼              ▼              ▼              ▼               │
│  ┌────────────────────────────────────────────────┐            │
│  │ STREAM 1: OMS + Inventory (CRITICAL PATH)      │            │
│  │ Team: Backend Core                             │            │
│  └────────────────────────────────────────────────┘            │
│                                                                 │
│  ┌────────────────────────────────────────────────┐            │
│  │ STREAM 2: Pricing + Offer Engine               │            │
│  │ Team: Commercial Systems                       │            │
│  │ (Can start Month 2 with mocked OMS)            │            │
│  └────────────────────────────────────────────────┘            │
│                                                                 │
│  ┌────────────────────────────────────────────────┐            │
│  │ STREAM 3: Payment Vault                        │            │
│  │ Team: Payments/Security                        │            │
│  │ (Can start Month 1 - independent)              │            │
│  └────────────────────────────────────────────────┘            │
│                                                                 │
│  ┌────────────────────────────────────────────────┐            │
│  │ STREAM 4: Web/Mobile Frontend                  │            │
│  │ Team: Frontend                                 │            │
│  │ (Can start Month 2 with API contracts)         │            │
│  └────────────────────────────────────────────────┘            │
│                                                                 │
│  ┌────────────────────────────────────────────────┐            │
│  │ STREAM 5: DCS + Gate Operations                │            │
│  │ Team: Operations Systems                       │            │
│  │ (Can start Month 3 - needs OMS stable)         │            │
│  └────────────────────────────────────────────────┘            │
│                                                                 │
│  ┌────────────────────────────────────────────────┐            │
│  │ STREAM 6: Infrastructure + DevOps              │            │
│  │ Team: Platform                                 │            │
│  │ (Continuous from Day 1)                        │            │
│  └────────────────────────────────────────────────┘            │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Parallelization Rules

StreamCan StartDepends OnBlocks
OMSDay 1NothingEverything
Payment VaultDay 1NothingOrder Payment
Pricing/OffersMonth 2OMS contractsNDC, Frontend
FrontendMonth 2API contractsLaunch
DCSMonth 3OMS stableOperations
Load ControlMonth 5DCS, OMSEFB Push
InfrastructureDay 1NothingAll deployments

9-Month Aserca Launch Scenario

Strategic Approach: Hybrid Launch

For a 9-month timeline, we use temporary existing solutions for non-critical modules while building the Order-Centric core.

┌─────────────────────────────────────────────────────────────────┐
│              ASERCA 9-MONTH LAUNCH STRATEGY                     │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  BUILD IN-HOUSE (Critical for Order-Centric Vision):           │
│  ────────────────────────────────────────────────               │
│  ✓ Order Management System (OMS)                                │
│  ✓ Inventory (P1-P5 Model)                                      │
│  ✓ Pricing & Offer Engine                                       │
│  ✓ Payment Vault                                                │
│  ✓ Web Booking Engine                                           │
│  ✓ Mobile App (basic)                                           │
│  ✓ NDC API                                                      │
│                                                                 │
│  TEMPORARY SOLUTIONS (Replace Post-Launch):                     │
│  ──────────────────────────────────────────                     │
│  ◐ DCS: Amadeus Altéa / SITA Horizon (interim)                  │
│  ◐ Crew Management: Jeppesen / IBS (interim)                    │
│  ◐ Flight Ops: Lido / Sabre (interim)                           │
│  ◐ Revenue Management: Manual / spreadsheet (interim)           │
│  ◐ Loyalty: Manual program (interim)                            │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Month-by-Month Plan

Months 1-2: Foundation Sprint

ActivityOwnerDeliverable
OMS Core DevelopmentBackend TeamOrder CRUD, State Machine
Inventory P1-P5 ModelBackend TeamHold/Release, Availability
Redis SetupPlatform Team10-min holds infrastructure
Payment Gateway SelectionFinanceVendor contract signed
DCS Vendor ContractOps TeamAltéa/SITA interim agreement
STATUS AT MONTH 2:
├── OMS: Core APIs functional
├── Inventory: P1-P5 model working
├── DCS: Vendor selected for interim
└── Infrastructure: AWS foundation ready

Months 3-4: Commercial Systems

ActivityOwnerDeliverable
Pricing EngineCommercial TeamDynamic pricing algorithm
Offer EngineCommercial TeamOffer generation & caching
Payment VaultSecurity TeamPCI-compliant tokenization
NDC API v1Backend Team/AirShopping, /OfferPrice
Flight Ops VendorOps TeamLido/Jeppesen interim
STATUS AT MONTH 4:
├── OMS: Production-ready
├── Pricing: Dynamic offers generating
├── Payments: Tokenization live
├── NDC: API functional
└── Flight Ops: Vendor integrated

Months 5-6: Customer-Facing

ActivityOwnerDeliverable
Web IBE DevelopmentFrontend TeamSearch → Book → Pay flow
Mobile App (iOS/Android)Mobile TeamBasic booking + boarding pass
PKPASS IntegrationMobile TeamApple/Google Wallet
DCS IntegrationBackend TeamOMS ↔ Altéa API bridge
End-to-End TestingQA TeamFull booking simulation
STATUS AT MONTH 6:
├── Web: Booking engine live (staging)
├── Mobile: Apps in TestFlight/Beta
├── DCS: Integrated via API bridge
└── E2E: Full passenger journey tested

Months 7-8: Operations & Integration

ActivityOwnerDeliverable
OCC DashboardOps TeamFlight monitoring
Load Control BridgeBackend TeamOMS → Interim DCS → EFB
Disruption HandlingOps TeamBasic IROPS workflow
Crew System IntegrationOps TeamInterim vendor connected
Performance TestingPlatform TeamLoad testing at 10x volume
STATUS AT MONTH 8:
├── Operations: OCC dashboard functional
├── Load Control: Data flowing to EFB
├── Integrations: All vendors connected
└── Performance: Scale validated

Month 9: Launch

ActivityOwnerDeliverable
Soft Launch (1 route)All TeamsLimited route live
Monitoring & AlertsPlatform Team24/7 observation
Bug FixesAll TeamsRapid response
Gradual RolloutOperationsAdditional routes
LAUNCH STATUS:
├── Core OMS: ✓ In-house, Order-Centric
├── Inventory: ✓ P1-P5 model live
├── Pricing: ✓ Dynamic, no ATPCO
├── Payments: ✓ Zero-trust vault
├── Web/Mobile: ✓ Direct channels live
├── DCS: ◐ Interim vendor (Altéa/SITA)
├── Flight Ops: ◐ Interim vendor (Lido)
├── Crew: ◐ Interim vendor (Jeppesen)
└── Revenue Mgmt: ◐ Manual/Basic

Interim Solution Integration Patterns

DCS Integration Bridge

┌─────────────────────────────────────────────────────────────────┐
│                 DCS Integration (Interim)                       │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  ┌─────────────┐     ┌─────────────┐     ┌─────────────┐       │
│  │    OMS      │────►│   Bridge    │────►│ Altéa DCS   │       │
│  │ (In-house)  │     │   Service   │     │ (Interim)   │       │
│  └─────────────┘     └─────────────┘     └─────────────┘       │
│                             │                                   │
│                             │ Translates:                       │
│                             │ • Order → PNR format              │
│                             │ • Status queries                  │
│                             │ • Check-in requests               │
│                             │                                   │
│  Key Rule:                                                      │
│  OMS remains Single Source of Truth                             │
│  DCS is a VIEW, not a data owner                                │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Flight Ops Integration

OMS (Passenger Data)
    │
    └──► Load Control Bridge ──► Lido/Jeppesen (Interim)
                                       │
                                       └──► EFB (Pilot iPad)

Post-Launch Replacement Plan

Interim SolutionReplace ByPriority
DCS (Altéa/SITA)Month 15High (cost savings)
Flight Ops (Lido)Month 18Medium
Crew (Jeppesen)Month 18Medium
Revenue MgmtMonth 12High (value creation)
LoyaltyMonth 15Medium

Risk Mitigation

Critical Path Risks

RiskImpactMitigation
OMS delaysAll systems blockedAdditional resources, early warning
Payment integration issuesNo revenueStart early, multiple gateway options
DCS vendor delaysNo check-inHave backup vendor identified
Performance issuesPoor UXLoad test early and often

Go/No-Go Criteria (Month 9)

Must have for launch:

  • OMS handling 100+ orders without errors
  • Payment processing 99.9% success rate
  • DCS bridge functional (interim acceptable)
  • Web booking end-to-end working
  • Mobile app approved in stores
  • Load control data reaching EFB

Team Structure Recommendation

┌─────────────────────────────────────────────────────────────────┐
│                    TEAM ALLOCATION                              │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  Core Backend (OMS/Inventory): 4-5 engineers                    │
│  Commercial (Pricing/Offers): 2-3 engineers                     │
│  Payments/Security: 2 engineers                                 │
│  Frontend (Web): 2-3 engineers                                  │
│  Mobile: 2 engineers (iOS + Android)                            │
│  Platform/DevOps: 2 engineers                                   │
│  QA: 2 engineers                                                │
│  Product: 1-2 product managers                                  │
│  ─────────────────────────────────────                          │
│  TOTAL: 17-22 people                                            │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Summary

PriorityModuleBuild/BuyTimeline
1OMSBUILDMonths 1-2
2Inventory (P1-P5)BUILDMonths 1-2
3Pricing/OffersBUILDMonths 3-4
4Payment VaultBUILDMonths 3-4
5NDC APIBUILDMonths 3-4
6Web IBEBUILDMonths 5-6
7Mobile AppBUILDMonths 5-6
8DCSBUY (interim)Contract Month 2
9Flight OpsBUY (interim)Contract Month 4
10Crew ManagementBUY (interim)Contract Month 4

The Order is the Single Source of Truth. Build OMS first. Everything else follows.