Why the back office route to the smart city is best, by Phil Silver.
As the “smart city” concept gains currency, there is an increasing realization that a vital component will be equally “smart” urban transit networks to move people around them. In such networks real-time data from multiple transport modes (tolling stations, car parks, buses, trains and even bike-share schemes), operated by multiple agencies, are aggregated in a central IT environment and used for the benefit of all transit stakeholders. Passengers plan and buy travel easily and conveniently, from operators who know the modes and routes they usually take and can tailor travel products accordingly. Meanwhile, operators, authorities and agencies understand who is using the network, how and when, can “talk” to them via their always-on mobile devices, and can make informed decisions about current and future transport provision. It’s a vision of intelligent transport and mobility that appeals to everyone.
The international gold standard for this concept is London’s Oyster scheme. Since its launch in 2003, Oyster has expanded to embrace almost every conceivable mode of public transport in and around London, paid for by both agency-provided and open-payment media, and is now poised to embrace the city’s car- and cycle-share schemes. Inspired by London’s example, other cities are at various points along the road to multi-modal, multi-agency integrated transport networks.
As the systems integrator for Oyster, Cubic is engaged with a number of the operators and agencies involved in these projects. As schemes evolve, many realise that integration is hindered by what can be described as a POS-heavy, device-centric architecture. To understand why, we need to go back a few years, to a period before integrated transport was considered feasible, when each stage of a journey — parking, tolling, ticketing, and so on — was a distinct process with its own approach to transaction management. Integration with other modes was not a priority for the designers of each system, who instead naturally focused on controlling and facilitating access to the system. Whether via the transponder at the toll plaza or the ticket or smartcard at the ticket barrier, their concern was proving users were authorised.
Technology-wise, therefore, the focus was on communication between the media presented — token, cash, magnetic-stripe ticket, smart card, transponder — and the access-control device. In these systems all the logic resides at the access point — at the point of sale (POS), not in the back office. The problem with this architecture is it doesn’t easily accommodate the ranks of multiple devices arrayed at toll plazas or subway stations. Install these and you have to add controllers to aggregate the data from each device and pass it up the chain to a host system, and further up the chain there has to be a financial processing system to record and audit transactions, produce reports for management, and so on.
Because these functions are essentially afterthoughts bolted to the original POS-focused design rather than an organic feature of the architecture, such systems are characterised by unacceptably high levels of lost transactions, which causes auditing difficulties and generally poor reporting. Furthermore, each modal system is a silo, built for a specific function and unable to communicate with other systems. The underlying technology in a subway fare gate system means it can’t “talk” to a tolling system or a parking system, and vice versa.
Agencies pursuing integrated multi-modal transit systems are now realizing the implications of this approach, and are living with financial back office systems that are not fit-for-purpose because of the data loss between the POS device and the general ledger that goes with depending on POS collection of data. The result for some agencies has been an inability to account for transactions, and the associated problems this creates for the public authorities who are supposed to administer and control these funds.
Work out from the back
The alternative approach, developed by Cubic for London, Chicago, Vancouver and Sydney, is to rotate the architecture 180 degrees, instead locating the access-control and transaction management intelligence in a dedicated back office specifically designed to handle multiple modes and multiple operators. By removing authorization from the point of access, data travels more directly and doesn’t get ‘lost’, so transactions are processed accurately, are auditable, and reporting is not only robust but also flexible enough to satisfy stakeholders’ different requirements. Systems can be configured to cover entire regions, taking the benefits way beyond the city boundaries, serving multiple agencies across widely distributed towns and cities.
Three factors make this approach possible. The first is the relatively recent development of reliable high-speed wireless networks to connect all the data capture and processing devices an intelligent transit system needs. The second is the ubiquity of “always on” mobile devices — particularly smartphones and tablet PCs — that enable two-way communication between the network operators and their customers.
These two factors are there for other transit system integrators to leverage. The third, I believe, is unique to Cubic: our experience in those cities I have cited has given us an in-depth understanding of the issues that determine the success of an integrated travel system. In turn — alone among integrators — we have applied this understanding to design and build a completely new platform, NextCity, that features a single scalable financial back office system specifically designed for multi-modal operation. This approach contrasts starkly with competitors whose offerings are built on integrating multiple back office systems, one for each mode; instead a single system interfaces with POS devices controlling access.
Open to the next
Fundamental to the NextCity back office concept is the fact that cities do not have to replace all their legacy systems to take advantage of it; the back office is designed to interface with existing systems in order to aggregate the data they generate. Not only does this reduce costs, aggregation means the businesses providing the transactions — the pay-by-phone parking company, for example — may benefit from economies of scale by paying lower transaction processing charges than those available from their current provider.
Costs are further minimized by building the financial and reporting systems on commercially available business intelligence, reporting and general ledger products that use open standards and thus can easily be interfaced with multiple IT systems. A welcome consequence of this non-proprietary approach has been to bring all-in-one integrated transport within the reach of smaller regions and communities that face the same transit challenges as larger conurbations, but on a lesser scale that has previously made them difficult to tackle commercially. That is now changing.
Looking to the future, demands on the back office are only going to grow as the components of the urban transport environment become increasingly integrated and increasingly higher priced. The era of POS-centric architecture has passed and future solutions will be uniformly driven from the back office.