Diese Case Study ist auch auf Deutsch verfügbar

Title: Hellmann Road: Clear Interfaces for Efficient Product Teams Subtitle: Label: Language: de Date: 2023–08–07 Reading Time: 7 minutes reading time published_at: not yet published Keywords: software-architecture, remote-work Excerpt: Hellmann Worldwide Logistics is a large global logistics provider with headquarters in Osnabrück. The family-owned company founded in 1871 is today represented in 173 countries, employs over 12,000 staff, and annually processes 20 million shipments – on land, on water, and by air.

With its transport management system HeRo (Hellmann Road), Hellmann initiated the largest in-house software development project in the company’s history. HeRo is a platform for every aspect of land transport. The aim is to introduce and standardize digital processes for all branches in Germany and Europe, thereby increasing efficiency and effectiveness, through optimal capacity utilization of freight transport on all direct links throughout Europe, for example. INNOQ provided support for the in-house development team over a period of 6 weeks to jointly make the increasingly complex platform more manageable by introducing clear interfaces.

Support for more independence

The HeRo development team deliberately opted for Event Sourcing in combination with CQRS (Command Query Responsibility Segregation) as an architectural style. Event Sourcing means that not only the current state of data is stored, but also all changes (events) that led to this state. Because this allows all functional events to be recorded and traced, Event Sourcing is particularly suitable for application in the logistics branch or for transport management systems.

Excerpt from the HeRo interface catalog
Excerpt from the HeRo interface catalog

However, the complexity of the platform increased due to the rapid growth of the team and the development of new features. This meant that HeRo eventually reached a point at which the system was no longer manageable because the level of technical debt was too high. Events were also used as the exchange format between individual services, for example, and this limited the platform’s operational capabilities. A type of “Gordian knot” developed, which required the skills of an external service provider to resolve. After several discussions, a decision was made in favor of INNOQ.

The problem statement

INNOQ was able to assist Hellmann in resolving the following issues:

  1. How can we specify our interfaces on a functional and technical basis that will allow us to undertake development efficiently with multiple production teams?
  2. And how can we use our technologies and architectures in such a way that they provide us with the necessary benefits and support in our functional goals?

INNOQ helped us on the path towards clear interfaces through a short yet powerful intervention. We can already feel the initial effects, such as faster development times­.

Roman SachseIT Teamlead/Solution Manager, Hellmann Worldwide Logistics

It was not a case of starting right at the beginning again. Too much time and money had already been invested in the existing platform. Rather, Hellmann wanted to bring in external support for 6 weeks, particularly to address the topic of interfaces. The aim was to find a solution during this time, which could ideally be implemented right away – with the help of experts who understand the problem, who could come up with a feasible roadmap for avoiding interface dependencies and who would work hands-on with the teams in developing and documenting a solution concept to enable the teams to then internally undo the “Gordian knot” on their own.

Radical simplification using the example of the HellScan software project: Instead of 27 internal domain events that were consumed by a number of other HeRo systems, there is now only one public domain event that can be explicitly consumed by other HeRo systems.
Radical simplification using the example of the HellScan software project: Instead of 27 internal domain events that were consumed by a number of other HeRo systems, there is now only one public domain event that can be explicitly consumed by other HeRo systems.

Significant technology decisions

  • The interfaces were documented for all to see in a Gitlab repository.
  • AsyncAPI and OpenAPI were used as specification languages. These are the most well-known and are easy for everyone to use.
  • The team based the exchange of messages on the CloudEvents standard.
  • The first interfaces that were developed together serve as a blueprint on how to design interfaces or on how to collaborate when establishing interfaces.
  • A concept was developed for every interface type (Events, Commands, and Queries), which was then jointly tested end-to-end.

Great results in minimal time

The collaboration between Hellmann and INNOQ started with a joint two-day kick-off workshop in Osnabrück. This start was valuable from both a technological and a personal standpoint. The participants in the workshop later formed the four-person core team – two senior consultants from INNOQ and two developers from Hellmann – as well as the IT team leader and the technical leads from the three HeRo product teams. Getting to know each other on a personal level enabled a basis of trust from the beginning. Especially since subsequent collaboration was exclusively remote.

Example of an API with AsyncAPI
Example of an API with AsyncAPI

The greatest challenge was to achieve sustainable results in a short period of time. Instead of relying on a comprehensive planning phase after the workshop, the core team immediately started using remote mob programming and intensive knowledge exchange. Technology decisions were made as fast as possible according to the motto “just do it”. After a short brainstorming session, a shortlist was defined and the prioritized proposed solution was tested directly:

This way, it quickly became clear which decisions were useful and which needed to be revised. The other teams were also fully included right from the start, their relevant interests sounded out, and decisions immediately agreed and consolidated. We all worked together in a very agile manner. Each day resulted in new plans, new priorities, and the use of free timeslots.

Coherence through openness

The development process was always transparent, which created greater trust and contributed to quick, positive results. Thanks to daily status reports, all participants, including the product teams, felt that they were in the loop and were able to provide direct feedback on interim results.

ADRs (Architectural Decision Records) enabled the team to document all decisions and processes in a transparent and consistent way. It was particularly helpful to work with concrete examples and demonstrate the resulting consequences. This meant that everyone who had read the ADRs got a feel for what effect a particular decision would have for daily work in the future. In addition, mutual exchanges which occasionally included intensive discussions ensured that the entire team was comfortable with these decisions.

Documenting all decisions and processes using ADRs: in this instance for code generation.
Documenting all decisions and processes using ADRs: in this instance for code generation.

The four expert developers in the core team also held many discussions, which were often intense, always exciting, and sometimes controversial as well. After all, the point of the collaboration was not for INNOQ to suggest complete solutions and processes or technologies. The goal of working together over a number of weeks was always knowledge transfer and enablement for Hellmann so that the teams could master and solve all challenges with respect to HeRo independently.

Conclusion

Naturally, not all problems could be solved in 6 weeks, but the goals set were reached. The team jointly developed a strategy and structure around interfaces. Every interface type was tested once on an end-to-end basis and a prototype was implemented – including a migration strategy. The first interfaces went live soon after the joint project phase. This meant that 27 internal events were reduced to a single functional interface event, for example. The plan for radical simplification is clearly already working. There is also a concrete plan as to which interfaces will be addressed step-by-step. The roadmap is clear, the direction determined, and the logistics company will now master the rest of the way on its own.

Avatar of Aminata Sidibe
Principal Consultant

We’d love to assist you in your digitalization efforts from start to finish. Please do not hesitate to contact us.

Get in touch!