Die Kunst der Microservices – The Art of Microservices

Das moderne Architekturkonzept der Microservices liegt im Trend. Studien zeigen, dass etwa 85 Prozent der Unternehmen eine Microservices-Architektur im Einsatz haben oder gerade aufbauen. Kleinere Einheiten mit klaren APIs sind ein wichtiger Baustein für die Agilität.

Im Gegensatz zu einem Monolithen aus einer einzigen Codebasis ist eine Microservices-Architektur eine Sammlung unabhängiger und modularer Dienste, die zusammen eine umfassende IT-Lösung bilden. Jeder dieser Services erfüllt eine klar umrissene fachliche Funktion und kann so unabhängig von anderen entwickelt, bereitgestellt und skaliert werden. Damit digitale End-to-End-Geschäftsprozesse entstehen, die übergreifende fachliche Anforderungen erfüllen, werden verschiedene dieser Microservices integriert.

Einsatzbedingungen für Microservices

Trotz dieser Vorteile sind Microservices keine One-Size-Fits-All-Lösung: Erst ab einer gewissen Komplexität und Größe der Systemumgebung sind sie wirklich geeignet, da ihre Architektur selbst zur Komplexität neigt und Aufwand und Nutzen sonst in keinem guten Verhältnis stehen. In kleineren Systemen können sie mehr Probleme als Vorteile bringen; hier kann auch ein Monolith effektiv verwaltet werden. Es besteht sonst die Gefahr, dass sich Teams zu sehr mit der Microservices-Architektur beschäftigen, anstatt sich auf die Entwicklung der Fachlogik zu konzentrieren. Daher ist es wichtig, den Nutzen der Komplexität von Microservices sorgfältig abzuwägen. Zusätzlich benötigen Microservices angepasste Entwicklungsprozesse, um Chaos zu vermeiden, wie etwa die Standardisierung von Technologien und Vorgehensweisen.

Bei komplexeren Systemumgebungen aber bieten Microservices-Architekturen strategische Vorteile – mit der richtigen Integration und Steuerung. Sie sind besonders nützlich für die Automatisierung von Geschäftsprozessen in größeren Unternehmen, da sie die IT-Landschaft flexibler und agiler gestalten. Die erfolgreiche Implementierung von Microservices hängt jedoch davon ab, wie gut ein Unternehmen die damit verbundenen Herausforderungen meistern kann.

Denn der Umstieg auf eine Microservices-Architektur ist kein Selbstläufer – schon gar nicht mit über Jahr(zehnt)e gewachsenen, monolithischen Legacy-Systemen. “Bing Bang”-Migrationen aller kritischen Unternehmensanwendungen auf einmal sind keine Option. Stattdessen hat sich eine schrittweise Methodik, unterstützt durch Prozessorchestrierung, bewährt. Dabei werden Unternehmensprozesse modelliert, getrackt, rekonstruiert und schließlich orchestriert.

Schritt Eins: Process Tracking

Zur effektiven Integration und Orchestrierung von Microservices ist das Process Tracking ein sinnvoller erster Schritt. Indem Prozesse visualisiert und verschiedenen Stakeholdern zugänglich gemacht werden, wird ein Verständnis für den aktuellen Ablauf geschaffen. Process Orchestration Plattformen, die Prozesse im BPMN-Standard modellieren und ausführen können, spielen dabei eine zentrale Rolle.

Eine Plattform zur Prozessorchestrierung kann solche Modelle direkt ausführen. Normalerweise würde der Prozess dann auch gleich Systeme integrieren und orchestrieren. Das funktioniert aber in Schritt 1 meistens noch nicht, da ein Großteil der Integration unter der Haube in den Legacy-Systemen passiert. Hier kommt das Process Tracking ins Spiel: Ereignisse aus dem ursprünglichen Prozess werden ausgelesen, um so im Orchestrator Prozessinstanzen zu starten oder weiterzuschieben. Der Prozess wird so quasi zum Zwilling des legacy-integrierten Prozesses. Dies erfolgt mit wenig Aufwand und ohne großes Risiko, da man noch nicht in bestehende Systeme eingreifen muss. Trotzdem werden Prozesse sofort sichtbar, und es können beispielsweise Durchlaufzeiten überwacht oder Fehlersitationen automatisch erkannt werden.

Schritt Zwei: Prozessorchestrierung

Nach dem ersten Schritt des Process Trackings kann die graduelle Umstellung von reinem Tracking auf Orchestrierung erfolgen. Dies geschieht durch Einbindung spezifischer Endpunkte in den Prozess, beispielsweise durch das Aufrufen einer API oder das Zuweisen von Aufgaben an Personen. Bei der Prozessorchestrierung hat es sich bewährt, Schritt für Schritt vorzugehen und eine Aufgabe im Prozess herauszusuchen, die als erste umgestellt wird. Die Umstellung geht dann so:

1. Entfernung der impliziten Integrationslogik aus dem bestehenden System, um eine zielgerichtete Steuerung durch den Orchestrator zu ermöglichen.
2. Entwicklung geeigneter Schnittstellen für die Funktionalitäten, die orchestriert werden sollen.
3. Orchestrierung der Endpunkte anhand des in BPMN modellierten Prozessmodells.

Ob bei der Integration technischer Systeme oder der Organisation menschlicher Aufgaben, der Ansatz bleibt ähnlich: Systeme erfordern eine API-Anbindung, menschliche Aufgaben werden etwa durch strukturierte Listen und Formulare angestoßen. Diese Umstellungen sind trotz ihrer Komplexität mit geringem Risiko durchführbar. Schrittweise lässt sich so der Übergang von unübersichtlichen Altsystemen zu einer klaren, orchestrierten Struktur vollziehen, bis das Ziel der Microservices-Architektur erreicht ist.

Prozessorchestrierung ermöglicht es Unternehmen zudem, neue Technologien wie Künstliche Intelligenz (KI) einfacher in ihre Prozesse zu integrieren, da man endlich weiß wo genau diese Aktivitäten eingebunden werden sollen. Im Bankenwesen ermöglicht dies zum Beispiel eine KI-gestützte Risikoabschätzung in bestimmten Szenarien. Dadurch wird die Prozessorchestrierung zu einem wesentlichen Bestandteil für die Evolution und Modernisierung von Unternehmensprozessen.

Fazit

Der Übergang von monolithischen Strukturen zu Microservices ist für viele Unternehmen ein erstrebenswertes, aber auch anspruchsvolles Ziel. Durch den Einsatz von Process Tracking und schrittweiser Orchestrierung von Geschäftsprozessen können Legacy-Systeme risikoarm transformiert werden. Diese Herangehensweise eröffnet zudem Möglichkeiten, neue Technologien wie KI über APIs einzubinden. Zwar ist die Modernisierung einer IT-Architektur mit Aufwand verbunden – doch je früher sie in die Hand genommen wird, desto früher lassen sich auch die Vorteile ausschöpfen.

The modern architecture concept of microservices is in vogue. Studies show that about 85% of enterprises have a microservices architecture in place or are developing one. Smaller units with clear APIs are an important building block for agility.

Unlike a monolith consisting of a single code base, a microservices architecture is a collection of independent and modular services that together form a comprehensive IT solution. Each of these services performs a well-defined business function and can be developed, deployed, and scaled independently. Several of these microservices are integrated to create end-to-end digital business processes that meet high-level business needs.

Operating Conditions for Microservices

Despite these advantages, microservices are not a one-size-fits-all solution: they are only really suitable once the system environment reaches a certain level of complexity and size, because their architecture itself tends to be complex and the cost/benefit ratio is not good otherwise. In smaller systems, they can cause more problems than benefits; here, too, a monolith can be effectively managed. Otherwise, there is a risk that teams will become too preoccupied with the microservices architecture instead of focusing on developing the business logic. It is therefore important to carefully weigh the benefits of the complexity of microservices. In addition, microservices require adapted development processes to avoid chaos, such as standardization of technologies and procedures.

In more complex system environments, however, microservices architectures offer strategic advantages-with the right integration and control. They are particularly useful for automating business processes in larger enterprises, making the IT landscape more flexible and agile. However, the success of microservices depends on how well an organization overcomes the challenges they present.

After all, moving to a microservices architecture is not a sure-fire success-especially with monolithic legacy systems that have grown over decades. „Bing-bang“ migrations of all critical business applications at once are not an option. Instead, a step-by-step methodology supported by process orchestration has proven effective. This involves modeling, tracking, reconstructing, and finally orchestrating business processes.

Step One: Process Tracking

Process tracking is a useful first step in effectively integrating and orchestrating microservices. By visualizing processes and making them accessible to different stakeholders, an understanding of the current process is created. Process orchestration platforms that can model and execute processes in the BPMN standard play a central role.

A process orchestration platform can execute such models directly. Normally, the process would also integrate and orchestrate systems. However, this does not usually work in step 1 because a large part of the integration takes place under the hood in the legacy systems. This is where process tracking comes in: events are read from the original process to start or move process instances in the orchestrator. The process becomes the twin of the legacy-integrated process. This is done with little effort and without much risk, as there is no need to interfere with existing systems. Nevertheless, processes are immediately visible, and throughput times can be monitored or error situations automatically detected.

Step Two: Process Orchestration

After the first step of process tracking, you can gradually move from tracking to orchestration. This is done by integrating specific endpoints into the process, such as calling an API or assigning tasks to people. When orchestrating a process, it is a good idea to take a step-by-step approach and select one task in the process to convert first. The conversion then proceeds as follows:

1. remove the implicit integration logic from the existing system to allow targeted control by the orchestrator.
2. Develop appropriate interfaces for the functionality to be orchestrated.
3. orchestrate the endpoints using the process model modeled in BPMN.

Whether integrating technical systems or organizing human tasks, the approach remains similar: systems require an API connection, human tasks are triggered by structured lists and forms, for example. Despite their complexity, these changes can be implemented with low risk. The transition from confusing legacy systems to a clear, orchestrated structure can be made incrementally until the goal of a microservices architecture is achieved.

Process orchestration also makes it easier for organizations to integrate new technologies, such as artificial intelligence (AI), into their processes because they finally know exactly where these activities should be integrated. In banking, for example, this enables AI-based risk assessment in certain scenarios. This makes process orchestration an essential component of business process evolution and modernization.

Bottom line

The transition from monolithic structures to microservices is a desirable but challenging goal for many organizations. By using process tracking and incremental orchestration of business processes, legacy systems can be transformed at low risk. This approach also opens the door to integrating new technologies such as AI via APIs. Modernizing an IT architecture is an effort, but the sooner it is done, the sooner the benefits can be realized.