L-3 Security & Detection Systems was a US-owned business operating in the airports, ports and borders sector. The UK operation was based in Bracknell with around 450 employees, including back-office teams, field engineers, trainers, warehouse staff, service functions and depots located at major UK airports.
The flagship product during my tenure was the ProVision 2 - a full-body security scanner used by airport security staff to detect threats on passengers passing through security checkpoints.
The ProVision 2 was a standalone device containing a Dell PowerEdge server. Despite this onboard processing power, the machines were not connected to any network or fleet intelligence system. Each one operated in isolation.
The engineers who maintained them were typically ex-forces - strong mechanical and electrical specialists. Highly skilled at the physical hardware. Less experienced in software, networking or data architecture. That distinction mattered when it came to connecting the machines.
My role - and what it formally was not
My formal remit was UK Head of IT - internal IT operations and infrastructure. I was not asked to develop product strategy, customer intelligence platforms or new revenue models. What follows is entirely outside that remit.
The airport operating context
Airports are not just transport hubs. They are commercial operations - car parks and shopping centres with a runway. They want passengers through security quickly and safely so those passengers can enter the retail environment. Security matters, but so does flow, throughput and operational efficiency.
Airport Operations Directors care about machine uptime, lane availability, passenger throughput, queue length, operational visibility and evidence-based planning. They want data to hold their suppliers to account.
London City Airport - the turning point
London City Airport had 24 ProVision 2 machines across two baggage halls. When they needed data, the process was: schedule an engineer, close the baggage hall, extract logs via USB, wait for processing. That took two to four days, often longer. By the time the customer received anything, it was stale.
L-3 could not charge properly for an engineer callout just to retrieve data. Repeated demands for data cost L-3 money. We were effectively offering that service at a loss. London City were paying £200 per callout - revenue that did not cover the true cost of the visit.
The machine logs existed. Scan events, outcomes, usage data. L-3 simply was not collecting, centralising, visualising or commercialising them.
I was asked to help extract logs. I went to site. That decision changed everything.
During the walk through the supplier route to the baggage hall, the Airport Operations Director asked directly: why could they not have a dashboard showing machine status, traveller throughput, detection metrics, false positives and usage patterns?
The immediate task was to extract logs. The strategic opportunity was to turn standalone machines into a connected fleet intelligence platform.
Market validation - Heathrow T3IB
I secured a security-cleared visit to the Heathrow Terminal 3 Intelligent Bagging Hall. This was a control room beneath the terminal where operators watched bags on conveyors via large screens with red and green flag buttons, pulling items for manual inspection. That visit directly informed the later proposal for granular log capture and operator feedback buttons.
Market validation - Schiphol Airport
Through the National Sales Director, I secured a Zoom call with the Director of Airport Technology at Schiphol. They were already pulling data from machines remotely, using a Lean Six Sigma approach to redesign checkpoint layouts and optimise machine numbers per hall.
Move L-3 from selling and maintaining standalone devices to operating a connected fleet intelligence platform. Give the data a name. Give it a product. Call it Overwatch.
The Overwatch concept
Overwatch would pull machine data from ProVision 2 scanners into a single branded customer dashboard. Data ingest every 30 to 60 minutes via GSM modules - because airport Wi-Fi access was not available and installing new network infrastructure was not permitted. The dashboard presented KPIs and visual reporting in a Power BI-style layout.
The proof of concept used AWS-hosted infrastructure with SQL storage, Elasticsearch for indexing, and open-source dashboarding. The open-source stack protected the commercial viability by keeping licensing costs low.
Security as a design constraint
The original USB model had been chosen for security reasons. A connected model had to be more secure, not less. I explored GSM modules, scheduled transmission, packet encryption, hidden network broadcast, end-to-end certificates, endpoint keys and data obfuscation. The principle: intercepted data would have no useful meaning to a third party.
Securing buy-in
I presented to the Finance Director, National Sales Director and National Service Director. Each had something to gain. The Finance Director and I had built a genuine strategic partnership - he understood the commercial opportunity, I understood the data and the platform. We built the business case together and presented it credibly.
I was not formally asked to create a new product strategy. I was asked to help extract logs. The gap between those two things is the story.
- Identified the customer need directly by going to site and listening to the Airport Operations Director
- Wrote the log extraction script that created the immediate fix and proved the data existed
- Investigated the security model to make connected data defensible in airport environments
- Secured GSM modules and worked hands-on with engineers to install them, going airside with security clearance
- Worked with the mechanical engineer team lead who opened the ProVision 2 panels and accessed the Dell PowerEdge servers
- Worked with Ovi, an engineer with Elasticsearch and ETL expertise, who built the data pipeline and dashboards
- Validated the market direction through the T3IB visit and the Schiphol call
- Built the business case jointly with the Finance Director
- Designed the commercial model - subscription tiers by machine volume, pay-per-report at £14.99, self-funding within 18 months
- Stood up the proof of concept on London City Airport Hall 4 and on 20+ machines in the L-3 warehouse and training centre
- Presented to the US parent company and positioned Overwatch for wider productisation
POC investment
The benefit to L-3
Under the old model, retrieving data from London City required an engineer to attend site in the early hours, pass through airport security, wait for the baggage hall to be closed, manually connect to each machine, extract the logs and leave. That process cost time and engineer hours - none of which could be charged back properly.
Overwatch replaced that entirely. With 60-minute scheduled ingest, the data was already in the platform. Producing a report became a 10-minute desk task. For subscription customers, it was entirely self-service.
The commercial model
Overwatch was priced by machine volume, reflecting the GSM cost of £2 per machine per month. Subscription covered SQL infrastructure, AWS hosting and licensing. Elasticsearch open-source dashboards kept licensing costs low.
Customers who did not subscribe could request reports at £14.99 per report - profitable after 8 reports. The London City arrangement was £200/month plus £24/month GSM, replacing unpredictable £200 callout costs.
- Secure airport, port and border environments with strict access controls
- US-owned corporate structure requiring US approval to scale
- UK team effectively foreign nationals developing solutions for a US security market
- TSA requirements and US security expectations
- Different GSM protocols in the US market
- Original USB model chosen for security - connected model had to be demonstrably more secure
- Machines not designed as connected fleet devices
- Field engineers skilled in hardware but not software or networking
- This was entirely outside my formal remit - buy-in had to be earned
- Around 2018, L-3 SDS USA began centralising IT services, reducing UK autonomy
- L-3 machines deployed at major airports, ports and borders - large captive installed base
- Machines already produced event logs - the data existed
- London City provided a real, live customer pain point
- Heathrow T3IB and Schiphol validated the market direction
- Finance Director and I built genuine strategic alignment
- National Sales and Service Directors saw direct value
- Open-source dashboarding kept costs manageable
- Platform supported existing service contracts
- Overwatch continued after my departure and was used to win new business
- Data proved customers could reduce machine commitments without reducing throughput
I left L-3 in October 2018. Overwatch was live on London City Airport Hall 4 and on more than 20 machines in L-3's warehouse and training centre. The UK presentation had been made. The US presentation had followed shortly before my departure. The concept was taken. The POC was allowed to continue.
Given the nature of the industry - security and defence, airports, borders - and the fact that the UK team were effectively foreign nationals inside a US-run operation, the solution had to be adopted and developed by the US for the US market. GSM protocols were different. The TSA had extremely stringent expectations. That is the reality of working in this environment.
Two colleagues I had brought into the strategy continued working on the platform as their full-time roles. Overwatch was used to good effect in winning new business and securing renewals with customers who had previously been unhappy with L-3's service.
I would have pushed harder for a formal product ownership structure from the start - someone whose role was explicitly to take Overwatch from proof of concept to product. The platform had genuine commercial potential. It deserved a dedicated owner earlier than it got one.
The Overwatch strategy was not about airport scanners. It was about recognising that data already existed inside a business, that customers needed it and were not getting it, and that surfacing it in a structured, commercial way could transform the service relationship, support renewals and create new revenue.
Clarke Willmott generates data constantly - through ELITE 3E, iManage, time recording and matter management. The question I would bring to CW is the same one I brought to L-3: what does the data already tell us, who needs it, and what would change if they could see it clearly?
At L-3, I was not asked to build a product strategy. I was asked to extract logs. At Clarke Willmott, I would not start with systems or dashboards. I would start with the people who rely on data every day - the fee earners, the practice group heads, the support teams - and ask what they cannot currently see that would help them do their jobs better.
The L-3 experience also reinforced that strategy gets built in organisations that are sceptical of abstract ideas by making it tangible. Build the thing, show it working, let the evidence do the arguing. At Clarke Willmott, the same principle applies.