Agile Case Study: TfL Oyster Card Expansion onto National Rail

Successful Agile adoption in a traditional medium-sized organisation

£40m Expansion of Oyster travel card to National Rail network relies on Revenue Apportionment Engine developed by Storm.

The Problem

TFL and the 12 main operating companies (TOCs) signed a legal document that apportioned rail fares between TFL’s underground network and the commercial operators. The agreement apportioned revenue according to whose tracks the passenger had used during his journey. This presented several challenges:

  • Journey evidence is starting and ending station, sometimes with an interchange validation and there could be several hundred routes available for that journey.
  • The legal agreement was made without reference to technical, or operational limitations, so a team of just 3 people had 8 months to design and build a system to deliver the revenue apportionment information.

The Solution

When the National Rail Train Operating Companies (TOC’s) joined the Oyster payment card system it gave travellers a seamless payment mechanism across the different operators. Storm Consultants designed and built the Revenue Apportionment Engine, which made the partnerships between different transport operators work, and developed the team which carried out the implementation phase.

The Revenue Apportionment Engine calculates, from data at card readers at each point of entry, or exit the most likely routes taken by each of the system’s 4m per day users, and determines how much is due to each of the transport operators. In real terms, the 99.9% accuracy achieved by the system means that out of £75m revenue per week the error has never exceeded £8 – and is usually less than £2 since it went online in January 2010.

The Outcome

Nobody has ever designed a system like this, so each of the team brought their skills into the project to develop, iterate and prototype the solution. It wasn’t straightforward and the core engine was re-built on two separate occasions as limitations,or false assumptions were discovered.

Since the engine was really a resident of the logical and changing train system for greater London, the complexity was enormous. Of course, it is an evolving transport system so the computer model had to be able to support continued change.

An unexpected benefit of supporting change in this way provided TFL with a “scenario testing” module. By changing the model and running historical journeys through the engine. This allowed fares analysts to see what the effects of changing a gate, or connecting two adjacent stations would have on revenues.

What did TFL say:
“The introduction of Oyster route validators will mean that the Oyster system will identify when passengers have avoided travelling through Zone 1 for those journeys where there are several different choices of route.

This will mean that passengers who use the new readers, and touch in and out at the start and end of their journeys, will show that they have avoided Zone 1, and will be charged the appropriate fare.

The improvement is part of a £40m upgrade of Oyster that will enable the roll-out of pay as you go on National Rail services in London from January 2010.

The upgrade will also mean that Oyster can now charge a more accurate fare for journeys that have several different choices of route.”

You may also like...