Diese Case Study ist auch auf Deutsch verfügbar
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.
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:
- How can we specify our interfaces on a functional and technical basis that will allow us to undertake development efficiently with multiple production teams?
- 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.
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.
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:
- “What does an API with AsyncAPI or OpenAPI look like?”
- “Let’s just set up an interface repository.”
- “How can we do that using the code generator?”
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.
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.
