Scaled Agile Case Study: TfL Contactless Payment Card System

Scaled Agile Case Study: TfL Contactless Payment Card System

Large Scaled Agile Development Project for Transport for London

What was the Problem?

Under the Oyster system, the fare calculation took place inside a card reader mounted at each passenger gate when the passenger presented (tapped) their card. Since it was dedicated to use for mass transport by TfL, season tickets, journey history and cash balance was stored on the Oyster card itself.

Storm Consulting were invited to develop an architectural solution that would eliminate the need for processing at the gate, remove all data from the card and perform everything centrally as a smart billing system.

TfL were working with Visa and Consult Hyperion towards a proof of concept working for a replacement card reader that would support contactless (EMV) card transactions. Once that had been proven, the next biggest risk was the Fares and Aggregation Engine (FAE) that would re-construct journeys, price them, apply discounts and capping, and make a single payment request for each day’s travel.

How was the Problem Solved?

The solution design was based on a Service Oriented Architecture (SOA), breaking-up the component parts of the system. Services had the added benefit of providing time to integrate with existing platforms (eg the input data which came from the readers) and to develop the many new components which would be needed. (Eg. customer ‘self-service’ web site).

Two consultants from Storm led a small team at TfL’s Victoria St offices and in just three months had developed a proof of concept and a complete prototype in six months. This provided the support needed to make the business case for the full £75m upgrade project, which was approved and commission by the TfL board and London Mayor Boris Johnson.

What was Delivered

An engine that could: reconstruct journeys from logs of card ‘taps’; sequence and recreate the passenger journeys that triggered them; price the journeys; apply various discount and disruptions rules to them; and provide a per-traveler ledger for travel costs;

An aggregation module provided fares capping, allowing for a new weekly cap to be provided – something that had been considered impossible under the previous system.

  • Business analysis that led to the formal creation of Intellectual Property (IP) which TfL now license
  • Adoption of Agile development methodology
  • Architecture and design for the fares system
  • Enterprise-strength FAE engine able to process five million journey taps in under 10 minutes
  • Journey testing portal for fares analysts and stakeholders

Although socialised as a proof of concept, the system was developed to enterprise standards and formed the core of the production system.

Exceeding Expectations

A characteristic of Agile development is the ability to rapidly exploit a new development. In this project developers noticed that many people had ‘pet journeys’ they would use to see if the system could calculate the route and price correctly. Stakeholders and analysts had each developed quite sophisticated journeys and these quickly became integrated as unit tests.

Whilst figuring-out how to input these test journeys and inspired by an early Martin Fowler article, the team wrote a simple Domain Specific Language (DSL) that gave business stakeholders an easy and fun way to monitor the FAE’s calculation of their own journey data. Of course, this meant a much higher spread of user acceptance testing and wider acceptance of the system as it allowed people to do their own testing.

Follow-on Implementation

One member of the original Storm team stayed-on at TfL for four years as Agile Delivery Manager:

  • Building six agile development teams for the delivery of the components within the system;
  • Instigating, mentoring, and delivering agile processes to make a large project such as this work, using Scrum approaches;
  • Putting in place the quality control processes, and ensuring they were working effectively;
  • Instigating a ‘Scrum of Scrums’ inter-team communication processes;
  • Training analysts to take the roles of product owner within the agile teams;
  • Developing a dedicated Build and Deployment team to manage the automated continuous integration platforms, and the version control systems;
  • With the build team, establishing a branch and merge policy for managing releases and system versions;
  • Establishing and designing processes for live third-line support after deployment as a live application.

Technical Details

The Right Design

This complex and innovative project relied on the development of several features that had not been attempted in any mass transit system (although New York had sponsored a project with MIT to try to find a technical solution). An approach based on the existing Oyster model existed in draft form (as a working assumption so that a new ticket reader could be developed). Storm architect Russ Lewis took a modular and service-oriented approach which provided great flexibility.

Separating the components by functionality this way allowed for them to be developed separately and discreetly by different suppliers at different times, and maintained by different organisations if necessary. Also, it was clear that the overall project would take some years, so flexibility and availability were paramount.

Technology Stack

The system was constructed using the following software technologies: Microsoft .NET framework and C#; SQL Server enterprise editions, including SSRS and SSIS for reporting and customer notifications; Microsoft AppFabric for data caching; Java ESB technology and Microsoft WCF for interfacing to existing Oyster Online applications; Visual Studio and Team Foundation Server for application development, version control, and agile project management (using Urban Turtle TFS agile extensions);  HP ALM and Microsoft test tools for managing tests and automating them;

Summary

The core proof of concept for the fares engine developed for Transport for London was an industrial-strength application, developed in just three months. Because it was a PoC it had little in the way of user interfaces, or glamour. But the core architecture of the PoC is recognisable as the core of the production application that is at the heart of TfL’s £75m Contactless payment and ticketing system.

Benefits

Benefits to the Business

Eliminating cash handling on London’s buses and trams has saved TfL £24m.
Reducing the volume on Oyster is estimated to save £20m annually.

Benefit for Passengers

Contactless payment has been available in London from 2012 (bus and rail) and 2014 (rail):

  • Tube
  • Docklands Light Railway (DLR)
  • Trams
  • London Overground

Both phases went live without any issues, winning TfL much praise for “a public sector IT project that works”.

People that use Contactless payment are very positive and enthusiastic about it. The introduction of weekly capping has been successful.

“we couldn’t have done what we did without you.”

Will Judge, Project Director

You may also like...