en
.jpg){kind=avatar}
When the journey began in early 2019, everything was crystal clear: the ERP migration to the cloud had just been digested. An expensive, but necessary evil to stay ahead in the face of constant technological change.
In this regard, the next major project exuded a completely different allure. An investment in the company’s future viability. The factory floor transformed into prime example of data-driven efficiency. The introduction of an Industrial IoT (IIoT) platform was intended to cement the entry of the medium-sized automotive supplier into a new era.
As a Medium-Sized Automotive Supplier into the Industry 4.0 Era
The machining centers, stamping machines, and presses were all to be retrofitted to the OPC-UA standard to allow uniform access, logging, and storage in a central database within the company network. This database was to feature a structure perfectly tailored to the company and its processes, meticulously developed through countless workshops moderated by external software architects with all stakeholders. The integration with the somewhat aging MES was precisely defined. A perfect plan.
But above all, this time they wanted to get right what had caused so much frustration in the previous project. The consultants from the long-standing software partner had portrayed the costly migration project as almost unavoidable. An additional option here, a customization there—with every coordination meeting in the planning circle, the costs seemed to inflate a little further.
Never again vendor lock-in. There was no question that this software had to be built in-house. Because when you own the software and its source code, you are free—free from subscriptions, free from absurd price increases, and liberated from the feeling of having to fend off upselling attempts with every interaction with the supplier.
Today, one looks back on the decision made in 2019 with a more nuanced perspective. Of course, the platform was not built in-house. Neither the capacity nor all the necessary competencies were available within the company. After thorough evaluation, the implementation contract was awarded to a specialized development service provider. The quoted price in the low six-figure range even remained under budget. The implementation was carried out smoothly, as far as could be judged. Although the software was properly documented, the plan did not quite work out for the responsible project managers and the internal IT department to be able to “take over” the software after implementation. Too often, day-to-day operations during the implementation interfered, and training and knowledge transfer stood in the way. The two planned specialist positions in IT could not be filled during Corona and were cut again in 2023 due to declining orders.
In the past few years, practice has shown that the perfect planning process was not capable of anticipating every requirement in advance. Many were added, others turned out to be unnecessary. Implementation could only be handled by the development service provider. Additionally, necessary security updates and minor bug fixes were required. Even the internal support for the software ultimately could not be handled by the internal IT. Man-days turned into man-weeks and eventually man-months. To this day, no one has dared to add the actual price tag of the project.
Own Source Code – More Commitment Than an Asset
As software developers, we often feel most productive on days when we have a net negative amount of code written, meaning more lines of code deleted than written. Because from experience, we know: Code costs. In its maintenance. In its deployment. And in its further development.
Programming the company’s own software can make sense because, for software within the company to fulfill its value promise, it must be almost perfectly tailored to the processes it simplifies, automates, or enriches with information. The idea that an off-the-shelf solution can abstract a problem in such a way that it is applicable in different companies while remaining sufficiently specific to be useful may hold true in accounting, where legal requirements and guidelines enforce a standardization of procedures across company boundaries. However, in the decades of optimization-grown individuality of your manufacturing and its processes, there could be decisive competitive advantages.
I appreciate my co-founders and colleagues for their pragmatism as software developers and their willingness to individually immerse themselves as consultants in the challenges, processes, and even the functionality of our customers' machines. As in the case of the previously mentioned development service provider, we owe a significant part of our revenue to the individual needs of our customers. The preceding anecdote may describe an isolated case, but one that is similarly occurring today in thousands of medium-sized manufacturing companies in the DACH region when implementing their own IIoT platforms.
Within the spectrum of the extremes “Buy vs. Build,” we observe an unfavorable tendency among medium-sized companies to develop further parts of their own data platform in-house—detrimental to company finances and project success. We attribute the cause to a lack of transparency in a market where product categories and their features blur together, coupled with the limited practical experience of many companies in digitalization. In the course of deciding which parts of your solution concept your company builds or has built and which standard solutions serve as building blocks, I suggest you add three fundamental questions to your evaluation process.
1. Where exactly lies the uniqueness of my requirements?
“Connect, collect, store, analyze, visualize” – according to Industry 4.0 thought leader Walker Reynolds, these are the fundamental functions that characterize an IIoT platform. But it is precisely here that the question of the uniqueness of your requirements arises. In our projects, we have developed tailored solutions for various industries—from heavy industry to the beverage industry—based on these fundamental functionalities. We have implemented different use cases, such as monitoring critical components, predictive maintenance using artificial intelligence, usage-based billing, remote machine diagnostics, and recipe management.
When you look beyond standardized IIoT platforms and compare them with the toolkits of system integrators, you often notice similar technology choices and similar implementation decisions. However, the former come with the teething problems of an untested solution and do not benefit from the extensive experience gained through numerous implementations. Especially with fundamental functions like connecting, collecting, and storing data, robustness and security are crucial—factors that greatly benefit from economies of scale. However, the necessary individuality can be achieved through high configurability, which allows your employees to adapt the underlying data model to reflect the reality of your production and to store datasets beyond the standard.
The true uniqueness of your solution usually only appears in the proprietary logic used to analyze data and visualize it for users. This individuality, implemented in the form of in-house algorithms, process models, and user interfaces, stems from a deep understanding of your own processes and customer needs. However, it constitutes only a fraction of the overall solution scope. Even these individual components consistently rely on the same fundamental functionalities for our customers. Therefore, the question arises: Is it efficient to dilute your own capacities and resources to develop secondary quality modules at the expense of the actual differentiators?
2. What does the solution cost in the long run?
A common misconception is that in-house development will pay off within a few years when comparing the competitive lump-sum price with the cost calculation of a standard solution, including necessary adjustments. However, you need to look closely: Are all costs truly accounted for? Do you need to hire new employees in specialized roles to operate and further develop your own solution? Or is a maintenance contract required, which incurs additional costs?
Often, the so-called “partner lock-in” leads to additional costs in practice that can reach the original investment within three to five years. These extra costs arise from necessary adjustments, maintenance, and further developments that go beyond the initial plans. It is important to consider these long-term financial impacts before deciding on in-house development. Only then can you ensure that the solution remains economically viable not just in the short term, but also in the long term.
3. Where can I reduce dependencies without leaving the standard?
When evaluating standard solutions for your IIoT platform, the question arises of how closely these are linked with the highly optimized services of major cloud providers like AWS, Google, or Microsoft. Seamless integration with these providers' services may seem highly efficient at first glance, but it simultaneously locks you into dependencies that are expensive to resolve if you decide to switch providers in the future. A deliberately vendor-agnostic platform offers the advantage of benefiting from the scalability and flexibility of cloud infrastructure without being tied long-term to a single provider.
Similarly, it is important to question the dependency on the platform provider itself. Although almost every platform is advertised as “open,” the underlying business strategy of the provider often only becomes apparent in detail. Does the platform aim to embed your own software portfolio into a larger ecosystem with the apparent customer promise of a “one-stop shop,” thereby increasing dependency? Or is the platform genuinely intended as a useful building block in your solution, allowing you to understand and potentially adjust the implementation yourself?
Another aspect is the configurability and flexibility of the platform. Features such as an open data interface, a proprietary scripting language, or the ability to deploy your own applications as Docker containers according to the platform’s specifications are often indisputable requirements today. However, what is crucial is how these functionalities are implemented. The litmus test: If you decided to switch platform providers tomorrow, would the services and applications your company has built on this platform need to be rewritten from scratch?
