In an interval of 14 days, we take tasks and turn them into working, tested code, which is rolled out in live operation after completion. Software development is an individual art in which every developer is creative and contributes to the solution of a problem.
We are continuously working on our data management and on the connection and integration of our system with external systems. In particular, the “Mobility as a Service” (MaaS) integration – is an important milestone in our strategic development. For this purpose, we have designed our own interface, our “Platform API”, with which our partners, but also we internally, can develop various use cases. Specifically, we don’t just want our results to be displayed in other apps, but we want to enable our partners to search and book bindingly in the app: A deep integration where our partners create their own apps and use the ioki system in the background.
In cooperation with Mobimeo, it was now possible for the first time to offer on-demand bookings via a MaaS app – in other words, we have built a program part of our software available to another software system for connection. What possibilities do we offer our customers through the new interface function?
The successful integration of our interfaces by Mobimeo proves that the planned software architecture changes and data models of the ioki platform can be used in practice by other companies. This is not a test project or a feasibility study, but a real product that is now on the market and moves people. It also uses a real example to show what efforts and steps are necessary for deep integration. After the interfaces were jointly defined and implemented, the Mobimeo team provided the actual integration service within a few weeks.
The concrete new possibilities expand our API portfolio to include the use cases “information”, “binding journey request and booking” and “plan data synchronisation” with external systems.
What special requirements must be met to use the new ioki interface function?
The new interface is called “Platform API” – unlike the existing “Driver API” and “Passenger API”, it is not designed to develop mobile apps, but is primarily aimed at integration partners who can draw on development services to integrate their back-end systems with ours. When integrated into an existing backend system, our API is a powerful tool to control or influence selected parts or the entire mediation process. The biggest praise for our work recently was a word-for-word statement from developer to developer that read “It was fun integrating you guys”.
Are there certain technical hurdles that need to be considered for deep integration into other systems?
From our point of view, there was one particular hurdle to overcome: We are a multi-client capable system. For the development, this means that we have to ensure that all changes to the system are compatible with all existing requirements. Our solution separates customer data and thus makes it possible to build a common customer base in a DRT system with several integration partners who also legally conclude their own terms of use with their customers. Since all these processes are already handled by us, the integration partner has a finished roadmap of how the development can run in the end.
Leaving aside APIs, operating systems and IT infrastructure, what drives you personally to push forward the digital mobility transformation?
I want to design mobility that is demand-oriented and in line with the times. For me and my team, this means facing actual problems with smart solutions.
As a family father, I am also motivated by the thought of one day being able to give my three small children an affordable mobility flat rate and to know that they are mobile in our city without having to park five cars in the car park.
