The challenges of Mobility as a Service

Where you go (partly) determines the way you travel. An afternoon of shopping in Amsterdam? Then public transport is the easiest way, possibly with Park & Ride. For a trip to the United States from the Netherlands, flying is the most obvious. The question ” How can I travel from A to B?” can be answered in multiple ways. You often see this: you have a choice that can consist of several means of transport and providers. Car, public transport and bicycle are the main ingredients in the Netherlands. This is called intermodal mobility. This can be part of Mobility as a Service where modes of transportation are not owned but consumed as a service. But planning such a trip is not that easy.

Put your ride together

One of the challenges is getting and keeping the overview. Which train / tram / bus should I take, does it run and is it on time? If I want to use Park & Ride, is there still room? Ditto for bike sharing services in cities. Do you want to go by car but you don’t have one? Then a shared car might be something for you, but there are also several platforms of that. In order to be able to choose you need an overview of available services. The overview is missing. But, you might argue, if that is the case why don’t you simply build the overview? Well, because it is a simple question to ask, but not to answer. The problem is creating the overview. Not from a technical perspective  but from a business perspective.

It is a matter of will

Linking systems together is, in principle, a technical challenge. Not difficult, but a lot of work. What is lacking is often the will. View it from the company that has built a platform for users to use the service. They have put a lot of time into developing and building a group of users with whom they (hopefully) earn money. Now suddenly another party comes and says “thank you, I am taking over!”.

We see it as well in the area of hospitality. Being part of a site like thefork (part of TripAdvisor) in the beginning has been beneficial for restaurants. It has the potential to increase traffic to the restaurant but lately the power of the platform and the fees that need to be paid to theFork has triggered  Koninklijke Horeca Nederland (association representing hospitality businesses in the Netherlands) to build their own platform for reservations. Some restaurants are on both, others have their own site / use other platforms. There are even platforms that aggregate another platform’s content like Trivago.

The problem is of course the amount of money that needs to be handed over and the control that the platforms have. The last couple of years we see that large platform providers being scrutinized by the European Commission.

Users=Power

The problem is that when users go to a platform the control lies with the platform provider. They can steer and throttle the traffic to sites, in some cases to the highest payer. Rather than via their own site the users now will find the service (or not) through a different path. Often with a price to the platform owner. No wonder platforms are hesitant.

Real time and connected

Let’s say I want to travel from Haarlem (the Netherlands) to Princeton, New Jersey (USA). I have multiple options for each leg. Let’s say that there are three legs:

• Getting to the airport
• Flying to the US
• Getting to the final destination

Let’s say I want to take the car to Schiphol and park there. I want to have a guaranteed parking space so I need to book online. I have six options for parking already. The flight to the US can be done using a multitude of airlines, airports and booking options. From the airport, I again have multiple options to get to my final destination. Typically, this trip requires at least three separate payments (one for each leg). Delays in travel are a fact of life, so missing a flight can have consequences for the legs that follow.

The idea that I can pay one provider for the whole trip is not realistic. Technically feasible but in practice not. It would require a system that take charge and responsibility over the entirety of the trip. What happens if the train from the airport to Princeton is delayed and a miss my taxi? Apart from the blame part there is also the part where the information needs to be exchanged and changes need to be made.

A long way to go

We literally have a long way to go in this scenario. From a business perspective, a dominant player that owns the platform will not sit well with other stakeholders that make up the ecosystem. Not on an international scale or even a national or regional scale. The solution might be to define a system where you do not have a dominant player but allows booking from all entry points. This however is hard to implement from a business perspective (risk, reward and blame).

But also technically. For one, the NJ Transit App on Android cannot be downloaded on non-American Google Accounts. Furthermore, connecting all these systems and making the flow fluid (and real time) is a lot of work. But, if we are able to put a person on the moon we should be able to create a seamless travel experience as well.

The components of such a solution basically comprise the entire WSO2 stack. From the Enterprise Integrator to the API Manager, Stream Processor and Identity and Access management solution as well. The reason for this full stack deployment is simple. The individual services and interfaces are developed without any reason for compatibility, standards and agreements and so on. The primary purpose was to let customers access the service using a website, mobile phone or kiosk. At that moment, there was no requirement for service chaining or other features that Mobility as a Services require, like reservations, changes / updates because of delays and so on.

To learn more about Smart Mobility e.g. Smart Transit, download the Smart Transit White Paper.

Some say we should go to Mars, I say we should go to Princeton!