Hands-on experience: Correctly assessing and implementing intralogistics investments

If you want to invest in intralogistics IT, you first need to understand the wider system. This raises the question of which solution to choose: Will it be a monolith or microservices? Because the devil is often in the detail.

Hey, everything is shiny and new.’ This line from the hit song “Alles neu” by Peter Fox may well sum up the mood of those responsible for logistics who come into contact with new IT products. During demonstrations, these products may appear resilient and powerful, but when it comes to integrating them into their own company and its IT structures, enormous challenges often 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 before the decision is made.

This case study is about the introduction of a handheld 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. This is where the attention of those responsible and the relevant stakeholders is already required to decide on the first important issue:

Although SDKs are the usual option for integration, 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 dialogue, process steps can no longer be carried out via the MDE until the error has been rectified. That is why developers from the company itself or from the MDE provider have to be involved. They now have to deal with source code that they did not write themselves, which ties up important capacities, possibly for more than just a short period.

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 reach a viable consensus. The process owner should always consider whether speed or security should take precedence. Where software and hardware meet, clear guidelines for the interaction of the systems must be drawn up. In the case described, Android, like a majority of intralogistics IT systems, communicates at the operating system level via a telegram standard 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 their own application that logs into this telegram system. The application in question interacts with the picking application on the MDE via this intermediary instance.

This means that the picking software no longer communicates directly with the hardware, which is not an advantage in a manual process anyway. Since the SDK is no longer directly integrated, this type of solution benefits
from increased security – with the added bonus that, in the event of a crash, the app for controlling the hardware will not affect any other applications. This initially involves 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 are used and a highly automated facility is operated at high throughput, it can make perfect sense to opt for a centralised solution. However, this is always accompanied by the risk of the company entering the ‘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 optimising processes. If all processes are separate from each other, the problems shift to the communication between the individual solutions, and there is often no longer a common denominator. The boundaries of the respective sphere of influence are defended, so to speak, and a kind of mutual mistrust in the flow of information arises. This often leads to work instructions that block each other or to 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: ‘Identifying the problem is more important than identifying the solution, because the exact description of the problem leads to the solution.’ If you approach it this way, effective investment decisions for the modernisation or expansion of warehousing capacities will follow.

This article appeared in the special edition available as PDF.

Our projects
Our digitisation topics
Back to the homepage