Creating a back-end modernization concept for a manufacturing client

The client has been developing innovative solutions in the manufacturing industry for several years, using technology to ensure the security of sensitive data. 

The challenge was to develop and propose a new system architecture with a migration path to a new one tailored to current needs.

The migration’s primary purpose was, among other things, to:

• Increase the processing capacity required by production machines – A new production control process system was needed to improve operational speed. This was because, in the monolith, adding more elements prolonged the testing process, so help was required to develop a better architecture.
• Detect bottlenecks in the system and optimize them – Moving to containers would make it easier to make regular updates and create more instances to manage information flow difficulties.
• Scale the current system.
• Add solutions for new products easily.
• Improve stability, Increase reliability, and fault tolerance – managing the monolith has been challenging, especially due to failures.

STAGE I 

INITIATION – Discuss a common understanding of the client’s tasks and goals

Our main task was to understand the client’s production processes, architecture, and scope of operations. Additionally, we focused on establishing a shared perspective to eliminate any misunderstanding of requirements. We defined what the client wanted to achieve and what the final product of this project should be. The most important thing for us was to know their expectations, needs, and the scope of the tasks.

The team from Germany told us their goals and objectives, which made it easier for us to divide the requirements into two types – technical and business.

Business objective – The client wants to increase the scalability of its system and deploy new products with low resource usage and a fast time-to-market.

Technical goal – consisted primarily of an optimization of the data flow process, detection of possible disruptions (bottlenecks), and reduction of data reprocessing time to a maximum of 15 minutes.

The client’s main need was a technology recommendation, specifying the preparation of an architectural description as a strictly substantive approach to a technology proposal.

DESIGN THINKING – data collection and introduction to the initial concept

In the next stage, we discussed all the components in the customer’s current systems and the elements of their network and infrastructure. We then smoothly moved on to analyzing all of the production equipment. In preparing the data, we learned more about the machines and how they work; for this purpose, we asked many questions, such as how the system works, the processes, dependencies, boundary systems, etc.

After learning the client’s documentation, we defined the goals we wanted to achieve. We used various Agile methodologies during the development process, such as use case diagrams and activity diagrams. We outlined the system architecture with the client and discussed which modules and functionalities should be replaced or improved. The chosen technology stack was to be supported for a long time (LTS) and based on containers.

A technical discussion facilitated the modeling of business processes (BPMN/Activity Diagram) and the proposal of new solutions. After the first workshop, we defined a solution proposal. We then prepared a technology recommendation, including information on all the benefits and risks of the given solutions and a sketch of the architecture. Furthermore, we defined weekly meetings with the client, during which we exchanged comments, suggestions, and proposals.

STAGE II 

PLANNING

We again pointed out the design goals and objectives during the second workshop. We then discussed a first draft of the architecture based on the technical documentation we received. In the next stage, we presented two concepts comparing the current and the new Event-Driven Architecture approach combined with a hybrid solution based on the microservices and modular monolith pattern. Among other things, we outlined the technology stack we recommended and the architecture proposal.

We decided on Event-Driven Architecture because with this approach, you get the following:

1. Loose linkages between components – Components can communicate using asynchronous event-based messaging, enabling greater flexibility and scalability of the system.
2. Scalability – In this architecture, processing can be separated into multiple components, where each handles incoming events independently. This makes it easy to scale the system when workloads increase and ensure even resource utilization.

In the next stage, we showed how we envisioned the new system and discussed the main assumptions.

We then presented a strategy of two approaches to transition from the current system to the new one. It consists of two parts:

• An evolutionary concept – involves changing the way we communicate.
• A revolutionary concept – we thoroughly changed the way modules communicate. Creating “queues” improved the modules’ performance, communication, and processing time was reduced.

The scope of technology planning included the selection of appropriate technologies. In this case, it was Java 17 (JDK 17) and Spring Boot 3.1 / Spring 6. The primary factor in choosing an appropriate technology stack was knowledge of the system requirements and the availability of resources and developers.

What did the customer receive after the product workshop?

After the workshop, the client received complete documentation in German, gathering all the conceptual findings into one. The document contains all the previously described steps, such as the definition of objectives, the selection of the technology stack, and the definition of the target evolutionary or revolutionary approach.

The client was very satisfied with the product workshop, as we met virtually all his expectations. Thanks to excellent communication, we created an entirely new architectural proposal. The client’s expectation was not to create a migration plan, project pricing, or a breakdown of implementation phases.

The benefits that the client received from the Design Thinking workshop include:

• Cost savings – instead of experimenting in-house, pulling their own developers away from the main tasks, the client received a ready-made solution.
• Innovative out-of-the-box strategy – thanks to an objective approach, we took a factual look at the client’s current architecture and the goals it wants to achieve.
• Modern technological and architectural solutions. 
• Active cooperation – the client actively participated in the process, from exchanging experience on the technological approach to actively participating in workshops, including modeling.
• Significant risk reduction – by not having to experiment with new technology solutions themselves, the client saves time from making mistakes in early system adoption.

After an in-house presentation, the final result was so impressive that we developed 2 PoC (Proof of Concept) projects with the client. Each project consisted of several stages, developed in intervals. At the end of each stage, we conducted a demo to present to discuss the progress of the work.

1. The scope of future projects we have identified with the client includes the following:
2. Implementation of the concept of Event-Driven Architecture based on containers. The basis will be building the infrastructure, creating a basic queue configuration, and basic monitoring with documentation.

Automatic scaling of the solution based on queue or resource load. The work also involves performing various operations on application availability, queues, etc., and documentation.