TFL .NET Case Study

From the 2nd January 2010, the hundreds of thousands of passengers who travel on National Rail services within Greater London have been able to use Oyster pay as you go.

The extension of the ticketing system covered all commuter rail routes within Greater London, and saw Oyster pay as you go accepted on all Greater London services operated by Chiltern, National Express East Anglia, London Midland, First Great Western, First Capital Connect, Southern, Southeastern and South West Trains.

Prior to the go-live date, Transport for London (TfL) invested £40m to install or upgrade Oyster card reading equipment at every train station in London to deliver Oyster on National Rail. Each time an Oyster card was swiped at any of these readers, the information was sent in real time to a centralised database that had been designed to process and handle payments.

Jayne Davidson, Project Manager at TfL takes up the story.

"As passengers were using a combination of travel methods, we had to implement a system that would allocate the correct percentage of payment to both TfL and National Rail," she explained. "This is not as straightforward as it seems since there are a number of ways that a passenger can travel to a destination, using a variety of transports."

The project was a key part in the overall transportation strategy for London and with projected revenues of between £800M and £1bn a year, it was critically important to design and implement a system that would accurately apportion these revenues between TfL and National Rail.

TfL accepted that developing the application in-house was the most cost and time effective solution: outsourcing the development would have cost significantly more and taken much longer to deliver. However, recognising that the internal Fares and Ticketing development team would be up against tight deadlines, TfL decided to augment the team with external expertise. "We had the necessary in-house expertise to develop the Revenue Apportionment Engine," said Jayne. "But we could not take all of our specialists off the existing projects so we decided to bring in a highly proficient contractor to work alongside our development team."

As this was a temporary requirement, albeit for several months, Jayne ruled out recruiting an additional member of staff. "It was too expensive and we wouldn't need this specialist once the Revenue Apportionment Engine project had been completed," she added. "It would also have taken far too long for us to advertise the position, review candidate CVs, interview and hire."

Realising that TfL needed a highly experienced and knowledgeable consultant who would be able to become an effective part of the Fares and Ticketing development team, Jayne approached Ballard Chalmers - a Microsoft Gold Certified Partner with a track record of providing end-to-end services and systems including client consulting and bespoke IT solution development and implementation. Ballard Chalmers recommended one of their top consultants - Mike Hooper - and having discussed the project with him TfL decided to bring Mike on-board.

"I knew from the outset that Mike was the perfect fit," commented Jayne. "He undoubtedly had the knowledge, skills and experience that we needed but equally importantly, he would be able to work alongside our internal development team, effectively becoming part of the unit."

"The concept behind the Revenue Apportionment Engine was to take the data supplied by the network of Oyster card reading machines and work out the most likely route taken by the traveller from origin to destination through the London NR/TfL network," explained Mike Hooper. "For each route, the system would then calculate the percentage share of the revenues due to National Rail and TfL and apportion it accordingly."

Working together, Mike Hooper and the TfL Fares and Ticketing development team adopted an AGILE methodology - an iterative development process widely adopted by Ballard Chalmers which promotes a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organisation and accountability, a set of best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.

"The Revenue Apportionment Engine solution was designed as a 3-Tier system", explained Mike Hooper. "The presentation layer being a C# Asp.Net web application or C# .Net windows application, the business logic layer containing the classes and business rules consisting of C# .Net code compiled to windows Dlls, and the data layer being an Oracle database."

The Fares and Ticketing development team successfully delivered the Revenue Apportionment Engine system on time and within budget. Key deliverables, on which Mike played an important role, included the DataLoader - an application that loaded TfL and NR distance and Generalised Journey Time data , the MatrixGenerator - to generate a matrix that contains revenue shares between TfL and NR, and Serialiser - an application that serialises data for the Central System. Significant achievements included reducing the matrix generation time from 12 days to 2.5 days, and resolving memory usage issues.

Now live, the entire system is a success story for TfL and, as far as is known, is the only solution of its type.

"We are delighted with our overall solution", added Jayne. "The entire process was relatively painless and although Mike and the Fares and Ticketing team were under pressure and had massive amounts of development work to complete, the system has proved to be highly successful. Ballard Chalmers and the Fares and Ticketing team have worked extremely closely together and although this was the first development project undertaken by the Fares and Ticketing team, it was so successful that we will certainly undertake development in-house in the future."

Currently, the TfL Revenue Apportionment Engine is undergoing fine tuning but already allocates 99.9% of the revenues accurately between TfL and National Rail - an achievement way above expectations of 95% and so accurate that TfL has postponed implementing automated quality controls in the Revenue Apportionment Engine.

Return to .NET Case Studies