Skip to content
Platform Docs

The Paved Road

"to empower our People to Provide Mobility Solutions Autonomously" 🚀

To illustrate why this is important and why the platform team made this their sole mission, lets take a look at the usual development workflow.

The Development Workflow

Looking at our Free2move Product, most customers will only get in contact with our mobile application on their phone. While this is an essential part of our product, most features and components rely on hundreds of services running in our cloud infrastructure. We call them microservices.

When a new feature or requirement is introduced to our product, developers will have to solve these technical challenges by implementing them in their microservices.

A typical development workflow of bringing a new idea to production involves many steps:

development workflow diagram

  • Technical changes have to be planned and prioritized
  • The actual code has to be written and shared with the team for collaborative work
  • Changes have to be verified and analyzed for potential security issues
  • The human-readable code has to be translated into software, which can run anywhere in the world (in the cloud, our local computers…)
  • New software version including the new features have to be released globally
  • The software has to be high-available and recover from failures automatically, so our customers do not experience downtime
  • We have to monitor the actual uptime of our software, to be able to react to issues immediately
  • Learnings will be established over time, which result in further input for our product backlog, and the cycle repeats

The average monthly changes in our codebase that go through this development cycle (we call them Merge Requests) are at around 2000. This results in about 70 larger changes per day across all development teams.

Considering this large number of changes, as well as all the components that are required during the development workflow, it would not be feasible for every development team to solve all the steps of the development life cycle on their own.

As most of those supporting components can be reused across teams, it makes sense to offer them as central services, so the development teams can focus on solving the technical challenges in their domain and bringing new features to our customers.

Introducing the Paved Road

We like to think of our internal tech platform as a paved road that developers are incentivized to travel on. When following this paved road, we can guarantee a smooth developer experience, as most of the cross concerns will be solved for you.

All the building blocks of the internal tech platform have been evaluated carefully and optimized over the past years, working in close relationship with the development teams. This also gives you the necessary confidence to trust in our solutions.

As always, all developers are more than happy to travel off the paved road and develop their own solutions, but keep in mind that the platform team support might then be more difficult.

Looking at the development life cycle we aim to provide a common set of tools and best practices for all development teams, to ensure a fast, secure and reliable way to build products:

paved road building block

The provided tools are selected by evaluating industry trends and standards and their interoperability with the current tech platform. Best practices emerge over time and are shared across development teams via the Architecture Guild.

These components result in the “Paved Road”, which streamlines the developer experience. One key aspect of the solution is offering as much self-service functionality as possible, to avoid development teams being blocked by the central platform team or waiting for tickets to get answered.

As every domain is different, solving all the cross-concerns of ~20 development teams centrally is not realistic. Therefore it is essential to continuously re-evaluate the current platform by staying in close contact with the development teams. By closing this feedback loop via various guilds, we can facilitate changes via our “internal source” culture and provide escape hatches to plug in and exchange different components based on the special requirements of a team.

Paved Road Quality Metrics

Finally, the effectiveness and quality of the internal tech platform can be ensured by following a metric-driven approach. Some exemplary metrics are:

  • Degree of Innovation per Component: How much time can we spend innovating in an area vs. time spend on maintenance
  • The number of Support Requests: How many requests do we get from developers in a specific area. Indicates a low degree of developer autonomy
  • 4 Key Metrics: Deployment Frequency and Change Failure Rate can indicate the effectiveness of the platform

Our Vision

The platform vision is structured into the three pillars Cloud Love, Developer Love and Business Love: platform vision pillars