Hands-on experience: Correctly assessing and implementing intralogistics investments

Anyone planning to invest in intralogistics IT first needs to understand the system as a whole. The next question is what solution to choose: a monolith or microservices? After all, the devil is often in the details.

“Hey, everything shines, so beautifully new.” This line, translated from the hit single ‘Alles neu’ by german music artist Peter Fox may express the mood of those responsible for logistics who come into contact with new IT offerings. During the demonstration, these products show themselves to be resilient and powerful, but when it comes to integrating them into their own company and its IT structures, it is not uncommon for enormous challenges to arise.
Successful investment decisions require a deep understanding of the overall system, because the devil is often in the details. One of the key questions here is whether a so-called software monolith is the better option or whether small-scale solutions, i.e. microservices, are the way to go. As always, the answer is a clear “yes and no”, which we will explain here.
We take a closer look at the decision-making process for new hardware to shed light on the opportunities, risks and possible approaches for the investment. The first step is to identify the existing processes and, above all, the stakeholders for the software architecture. An example from our work shows what must be considered in any case before the decision is made.

This case study is about the introduction of a hand scanner in the warehouse of an international automotive supplier, in which the product of a start-up is used. The connection to the mobile data terminal (MDT) is to be made via a software development kit (SDK), a collection of programming tools and program libraries. The attention of the responsible persons and stakeholders is already required to make the first important decision:
Although SDKs are the usual integration option, they are not the only one. The start-up’s approach is to implement the SDK directly into the software of the MDEs.
The advantages: high access speed and, when a new version is integrated, all features are available. The disadvantage of this option, which cannot be ignored, is that
the SDK “takes the software with it when it crashes”. If the error always occurs at a certain point in the dialog, process steps can no longer be carried out via the MDE until the error is corrected. Therefore, developers from your own company or from the MDE provider must be involved. They now have to deal with codes that they did not write themselves, which ties up important capacities, and not just in the short term.

When making purchasing decisions, those responsible urgently need feedback from experts at the software and process level in order to weigh up different arguments and come to a viable consensus. The process owner should always consider whether speed or security should take precedence. Where software and hardware meet, clear guidelines for system interaction must be drawn up. In the case described, Android, like a large proportion of intralogistics IT systems, communicates at the operating system level using a telegram software to which the respective applications for sending and receiving messages can register. Instead of integrating the hardware via an SDK, the hardware provider can therefore provide a dedicated application that registers with this telegram system. The application in question interacts with the picking application on the MDE via this intermediary instance.

If the decision is made in this way, then the picking software no longer communicates directly with the hardware, but this does not bring any advantages in a manual process anyway. Since the SDK is no longer directly integrated, this type of solution benefits
from increased security – with the added advantage that, in the event of a crash, the app for controlling the hardware does not affect any other applications. Initially, this means more work for the hardware provider, but this pays off in the long term in terms of cooperation. In a closed system in which hardware and software from a single provider is used and a highly automated facility is operated at high throughput, it can make perfect sense to opt for a centralized solution. However, this always entails the risk of the company entering a “walled garden”, i.e. a closed platform. Flexibility and the ability to innovate can suffer as a result. However, microservices are not always the be-all and end-all either. Because even with them, companies can score an own goal when it comes to optimizing processes. If all processes are separated from one another, the problems shift to the communication between the individual solutions, and there is often no common
The boundaries of the respective catchment areas are defended, so to speak, and a kind of “mistrust” arises in the flow of information. This often leads to mutually blocking work instructions or process steps that no longer build on each other.

The two most important questions that decision-makers should ask themselves with the help of the respective domain experts, i.e. the “rulers” of the specialist departments, are as follows:

• What are the tasks?
• Which available means can be used to solve them and how do they interact with each other?

The better a task is described, the faster the project participants can grasp its content. And all this before the first line of code is written!

As Albert Einstein said: “Recognizing the problem is more important than recognizing the solution, because the exact description of the problem leads to the solution.” If you approach it this way, effective investment decisions for modernizing or expanding warehousing capacities will emerge.

This article appeared in the special issue of the german trade journal Logistik Heute, Software in der Logistik 2024, and is available as a PDF (german).

Our projects
Our digitalization topics
Back to the homepage