TTC is the transit committee for the municipal of Toronto area. There are many other transit committees in the surrounding area, no rx such as Go transit, ed York Region Transit, Mississauga transit, etc. Many commuters utilize more than one transit system on a daily basis.
Currently, TTC has fare-per-ride fare system: to use the service, riders pay fare once at fixed amount (token) per ride, and one ride is defined as one-way continuous trip with no backtracking. The fare is fixed prices regardless of distance traveled. And there is no discount offered when rider utilizes 2 transit system in one single trip; a full additional fare for the second transit system is required.
As the GTA expands and cross-border ridership increases every year. The need of a more integrated fare system between TTC and all surrounding transit boards also increases. For example, one integrated transit fare model is zone-based-fare model. In Zone-based-Fare model, the entire area is divided into zones, and the fare of one single trip is defined by the number of zones the trip covered. The zone-based-fare model implies that the rider is paying as per distance traveled, instead of the number of transit providers the trip uses. It is a more effective reflection of the cost per ride, compared to the current fixed fare per ride model.
Another benefit of implementing zone-based-fare model is the dynamic pricing business capability. Since ridership data will be associated with the trip data, and the cost of the trip is only calculated individually at the end of the trip, therefore the transit price can be variable, and determined based on business needs. For example, in order to provide public welfare to low income families, riders from low-income background could be provided with special transit ID and lower fare price. Another example is: lower than usual fare price during peak hour can be implemented to encourage off-peak transit usage. The dynamic pricing capability enables flexibility in business strategy, and therefore would enhance business performance.
Scope and Requirements
In order to achieve the zone-basis-fare with dynamic pricing, both the trip start point and end point, along with the time stamp, need to be recorded for every single trip. The time stamp is required for every start point or end point in order for backend algorithm to determine the start and end belong to the same trip and to calculate the revenue distribution to different transit service provider for that trip.
The current TTC’s enterprise architecture of fare system does not have the full capability to collect, capture, compute and store these data marks. An enterprise architecture solution is required for the fare system. Here are some key requirements for this integrated architecture:
High-level Functional requirements:
- Collect the ridership data:
The solution should be able to capture the start point or end point location and time
- Collect the user data:
The solution should be able to associate the ridership data with the user data, if available. Existing user Identification infrastructure such as Presto Card can be used
- Compute the trip data
The solution should be able to interpret the ridership data and user data to calculate the price of the trip, deduct from user’s current balance, and distribute the price to appropriate service providers
- Storage of all data
The solution should contain data storage capability, and provide appropriate levels of access to different stakeholders, such as rider, service provider, governance body, and the public.
High-level Non-functional requirements:
- Time-sensitivity and performance
The solution should be capture, store, compute and analyze the data in real time, with negligible response time
Since there will be large number of ridership during peak hours, the solution should be able to hold large number of transactional volume during the peak time without sacrificing performance
- utilization variability
The solution should be able to support high utilization variability because the daily ridership volume pattern from peak time to off-peak time
The solution should be operational available for all time when there is transit service
The solution should be reliable with downtime less than industry standard
The solution should ensure the data security, for all data including user data, trip data and ridership data. High level of data integrity and confidentiality is required for the user and financial balance data
The solution should be scalable for capabilities such as new transit route, new zone definition, and new service provider integration.
Project Management Consideration
Based on the TTC architecture problem described above, the following project management aspects were considered important:
- Presto Card, a fare payment smartcard by Metrolinx, is already implemented for TTC [METROLINX OVERVIEW]
- the new fare system entails a new way of providing transit service, and therefore new establishment of TTC business framework
- It is a public infrastructure project with restricted non-functional requirements such as performance and availability
- It has large impact on many stakeholders such as riders, taxpayers, government, and citizen. These stakeholders have very different concerns and requirements, and therefore the framework has to be comprehensive and cover multiple views and viewpoints
- Since it is a public funded project, public visibility and compliance requirement for traceability and QA measurement between business vision and technical implementation are required throughout the architecture design and project management
- This project has dynamic business requirements because the city develops at a rapid rate, so there is less emphasis on the building the best architecture
- Again, since it is a public funded project, funding might be released in stages, and funding timeline might be conditional to progress up to date.