Fleet Desk · Aer Lingus · Project Manager · 2026
From 15-Minute Lag to Near Real-Time Operations
Near real-time fleet visibility, delivered ahead of schedule by tracing a pipeline that kept silently breaking, closing a governance gap on the way, and validating change-data-capture technology new to the organization inside a fixed 60-day window.
Challenge
The Fleet Desk's existing tooling didn't reflect aircraft status in near real time, limiting how quickly operational decisions could be made during irregular operations.
Fixing it meant deploying technology the organization had never used (specifically a change-data-capture pipeline feeding a cloud data lakehouse into a live BI dashboard) inside a fixed 60-day window, while a parallel vendor RFP and Decision Support proof of concept competed for technical resources. Partway through, the pipeline repeatedly broke when source database refreshes silently wiped the replication server feeding the dashboard, exposing an unowned multi-team boundary.
Unproven Tech Stack, Firm Cut-Off
Change-data-capture streaming was new to the estate and had to be validated end-to-end within a strict 60-day delivery window.
Silent Upstream Overwrites
Three teams shared pipeline custody with zero contract boundaries, causing upstream database refreshes to silently corrupt downstream feeds.
Approach
Delivery was built around staged validation and explicit decisions, including one urgent detour to fix the pipeline itself.
Real-Time Fleet Data Pipeline & Governance Architecture
How cross-functional ownership boundaries isolated testing and slashed operational latency from 15 minutes to 90–120 seconds.
Cross-functional delivery structure
Data and reliability engineers, product and platform teams, architects, and governance ran weekly operations-modernization check-ins, with the Fleet Desk business lead and an on-site operations liaison representing end users.
Direct root-cause troubleshooting
When the pipeline kept breaking, ran a working session with the database reliability lead to trace it end-to-end and pin the cause: non-prod refreshes of the core operations system overwriting the replication server that fed the change-data-capture pipeline into the lakehouse. The fix isolated testing onto a dedicated, unused SQL instance fed by synthetic data, decoupling the pipeline from that system's own refresh cycle entirely.
Explicit ownership boundaries
Got each team's scope agreed out loud rather than left implicit: database reliability owns getting data out of the core operations system without harming its performance; the platform team owns the bridge into the lakehouse; the analytics team owns productionizing it from bronze to silver to gold.
Staged validation
The dashboard was shown in stages (visual layout first, then scenario accuracy, then latency) with two iterative releases (v0.2, v1.0) reviewed side-by-side with operations before rollout.
Negotiated, not assumed, decision points
When testing showed a 90–120 second refresh, it was raised directly with the business owner as a named decision: is this "low latency," or does it need more work, rather than treated as close enough.
Honest status reporting
With UAT status still undetermined and a parallel vendor POC also at risk, the project was reported amber rather than green, with senior-leadership-level RAG questions logged as formal decision items.
Critical Decision Points
Document the high-availability decision, don't default into it
The standalone replication server that came out of the root-cause fix was running on a single instance with no redundancy. Rather than let that carry into production by default, the call was made explicit: either accept single-instance risk as a documented business decision, or invest the extra effort to make it highly available; but either way, sign off on it on paper before go-live, not after an outage.
Is 90–120 seconds "low latency"?
Rather than assume the improvement from 15 minutes was self-evidently good enough, the team put the specific number to the Fleet Desk owner as an explicit go/no-go decision, with a fallback path (data pipeline adjustments) ready if the answer was no.
Protecting a deprioritized dependency
Fleet data was at one point deprioritized in favor of passenger data elsewhere in the program. The data architect flagged that fleet data was foundational to crew, passenger, and schedule data downstream, and that dependency had to be actively re-surfaced, not left to be rediscovered later.
Reporting amber instead of green
With two workstreams both at risk, the project was reported honestly at amber. Any RAG adjustment needing senior-leadership context was logged as a formal decision item rather than smoothed into a status update.
Outcomes
- A silently-breaking production pipeline was traced to root cause in a single working session, with a fix scoped to a same-week target.
- Three teams' responsibility boundaries were cleanly agreed, reducing the finger-pointing risk on the next incident.
- The high-availability question was logged as a documented risk decision rather than something that would only surface after a future failure.
- Fleet Dashboard v1.0 delivered one week ahead of the target date, inside a ~60-day window, using change-data-capture technology new to the organization.
- End-to-end pipeline validated from the core operations system through a cloud lakehouse (bronze/silver) to a live BI dashboard, with refresh latency confirmed at 90–120 seconds against a 15-minute baseline.