• Transit authorities historically contract out to build their own “cellular networks” (the fare collection back office and vehicle hardware, the CAD/AVL back office and vehicle hardware, the real-time passenger software)
o Typically there is a lack of interoperability with surrounding agencies and technologies
o The project is time consuming, resource consuming and capital consuming
• Each system has its own unique features and “phones” (building RFP’s for customized software and hardware requirements during the procurement of the systems)
o Large up-front capital expenditure on unique features and hardware rollout
o Some of the most advanced technology is unavailable to the smaller transit authorities due to cost and complexity of deployment
• Transit authorities maintain their own systems (procurement of these systems means the authority owns the hardware and the vendor supplies on-going services, maintenance and warranty fees)
o Software and hardware is locally maintained; software patches need to be pushed out to the local versions of client/server software applications
o System is maintained until the next capital procurement and “fork-lift” upgrade The example isn’t a perfect comparison, but it should make us consider if there are alternative ways in which vendors can offer these technologies. Utilizing a service model approach, agencies could save money, time and resources while receive cutting-edge technologies in a more efficient manner.
What a Service-Based World Would Look Like
Consider a service provider model for the above procurements. As they do today, the agency would still need to research the technology need, go out for a grant and issue an RFP. Instead of creating a unique technology RFP though, the agency would create a service-based RFP. In a service world, the vendor would build and maintain an enterprise class instance of their software preferably at a hosted facility. Network connectivity, server requirements and network management services would all be provided as a service level agreement with high availability and redundancy requirements.
Additionally, the vendor would deploy a large disaster recovery site — a full back-up site that would be capable of backing up all data, customer information and configuration files. As the vendor deploys a large-scale implementation of its central software, every agency would enjoy the benefits of this large-system deployment. An agency with 25 vehicles and an agency with 250 vehicles would have the same system availability, features and functionality. Through a secure network connection, agencies would be able to access the features and data of the CAD/AVL, RTPI or EFC through a Web browser.
Instead of the typical server/client software deployments where the applications are loaded onto individual computers, the hosted model supplies all of the content, functionality and features through a standard Web browser. The vendor service offering might include the supply of on-board hardware for either a nominally reduced rate, or subsidized as part of a monthly service charge. Because the back office software would be shared, updates would be pushed out and available to all subscribing customers providing constantly evolving feature-rich software to all agencies.
The agency would not need to own the on-board hardware, which would be refreshed every five years as part of the overall system health process. Similar to cell phone providers offering their subscribers discounted handsets every few years, this process ensure that the field hardware stays up to date and in good working order. Up front, the vendor would take in all agency configuration data and ensure a clean mapping between operational requirements and software features. This might only take a number of months, as opposed to a number of years as we see in the industry right now.