_Christian, in this project, agile methods and microservices were used. What’s behind that?

Since the business vision of smide initially formed slowly and over time, it was decisive that the architecture and implementation keep pace with the dynamic development. For this reason, from the very beginning, we designed and developed a new increment of the solution at short iteration intervals and put it into production at the latest every two weeks. Of course, this was not a linear process – again and again, we changed and improved functions that had already been built, in order to adapt them to new findings from real life. In order to also keep control of the architecture and structure of the system, we broke it down according to functional criteria into several highly independent subsystems or microservices. Both approaches were absolutely decisive to the success of smide.

Is it true that at INNOQ the boundaries between IT and business consulting are blurred? How do you handle that?

Yes, I see it that way, too, and, personally, I find it very exciting. Furthermore, it is simply necessary, if we want to help our customers succeed. Even in the digital age, it’s not just about hip technologies; it’s about knowing the business, the relevant goals, and the constraints. Since the customer – particularly a start-up – often does not yet have this perspective 100%, we help to actively shape this perspective through critical questions and alternative ideas. For smide, therefore, we slipped into different roles depending on the situation: sometimes coach or sparring partner, sometimes software specialist, but often mediator as well – for example between e-bike manufacturers, external suppliers, smide, and other stakeholders. In order to help our customers, it goes without saying that we assume the necessary responsibility, even going beyond programming.

For the nerds among us: What was technologically exciting about the project?

Even though, as already mentioned, it was not primarily about technologies, there are still a few aspects that should be mentioned. For smide, historical data and events, for example, are very important, so they can be used for new business models. For that reason, we use an Apache Kafka cluster, which can store the entire event history as an ideal basis, so that it can be analyzed as needed or used for new functions. And, of course, the implementation of the overall system in the form of multiple microservices, which also use Kafka for inter-communication of technical events and are thus highly independent of each other. The large number of individual services naturally necessitates an automated testing and deployment pipeline and a suitable container environment for operations, in our case a Kubernetes cluster.