Viele IT-Manager diskutieren momentan technisch oder aus traditioneller IT-Management-Sicht die Einführung einer Microservice-Architektur. Der technologische Aspekt ist sicher herausfordernd, aber er greift zu kurz. Um den Nutzen einer Microservice-Architektur auszuschöpfen, müssen auch die Herausforderungen des fachlichen Zuschnitts, der Organisation und der Architektur-Governance gelöst werden.

Der fachliche Zuschnitt: Kandidaten für Microservices

Microservices sind dort sinnvoll, wo schnelle Veränderungen besonders wichtig sind. Das trifft vor allem auf marktdifferenzierende Geschäftsfunktionen zu. Erst mit ihnen hat das Unternehmen eine Existenzberechtigung. Folglich sollte darauf der Fokus liegen. Dieser kann sich allerdings rasch ändern. Beispielsweise wollen einige Banken und Versicherungen sich von der Produktorientierung hin zur Kundenfokussierung wandeln. Damit werden je nach Strategie einige Geschäftsfunktionen rund um den Kunden marktdifferenzierend, beispielsweise in Marketing, Verkauf und Service. Die klassischen Produkte der Banken sind nicht mehr marktdifferenzierend. Sie werden hochgradig standardisiert, um sie global mit sinkenden Grenzkosten zu betreiben zu können. Hier stehen Stabilität und Automatisierung im Vordergrund, bei relativ geringen Veränderungsanforderungen.

Als Microservices eignen sich also primär marktdifferenzierende Geschäftsfunktionen. Darin liegt zugleich die Krux. Neue Architekturen zu implementieren, birgt Risiken für Fehler und Ausfälle. Eben diese will man bei marktdifferenzierenden Funktionen vermeiden. Es empfiehlt sich deshalb, mit einer sehr kleinen Funktion anzufangen, deren teilweiser Ausfall verkraftbar ist.

Beispielsweise haben Banken Beraterarbeitsplätze, die Vorschläge für Cross-Selling Produkte machen. Hier liegt eine Möglichkeit, den Monolith Beraterarbeitsplatz stückweise aufzuspalten und eine erste Funktion herauszulösen. Die Cross-Selling-Funktion kann als Microservice separat neu implementiert und aus dem Beraterarbeitsplatz heraus aufgerufen werden. Der Bankberater selbst merkt im Idealfall von der Umstellung gar nichts. Im schlimmsten Fall bekommt er temporär keine Produktvorschläge.

Die Organisationsform: fachliche und technische Gesamtverantwortung

In der klassischen IT würde der Fachbereich beginnen, ein Fachkonzept für einen solchen neuen Service zu schreiben, die IT würde ihn entwickeln. Nach erfolgreicher Realisierung würde getestet, Fehler würden behoben und dann an den Betrieb übergeben. Das kann man so auch für Microservices machen. Bei EINEM Service würde das auch noch klappen. Allerdings nicht mehr bei mehreren Dutzend oder gar hunderten. Man würde sich damit nur die Nachteile einer hochverteilten Umgebung einkaufen und gleichzeitig die Vorteile von Agilität und Flexibilität nicht nutzen.

Die Innovation der Microservices liegt in der Gesamtverantwortung eines Teams für Fachlichkeit, Entwicklung, Test und Betrieb. Erst die kurzen Kommunikationswege und der gemeinsame Blick auf Entwicklung und Betrieb erlauben eine hohe Änderungsgeschwindigkeit.

Mitarbeiter, die in einer klassischen Unternehmens-IT arbeiten, müssen sich also neue Arbeitsweisen aneignen. Zudem müssen sie völlig neue Technologien lernen, da sich klassische Produkte wie SQL-Datenbanken, Application Server, Service Bus etc. in der Regel nicht für Microservice-Architekturen eignen. Daneben gilt es, eine hohe Automatisierung für Tests und Deployment zu schaffen, um so eine "Continuous Delivery" sicherzustellen.

Im Video: Microservices als Architekturmuster

(Quelle: video2brain, Trainer: Christopher Janietz)

Microservice Governance: Management der Abhängigkeiten und des Zusammenspiels

Auch die Anforderungen an die Governance der Unternehmensarchitektur ändern sich. Ein Service lässt sich noch leicht überblicken. Aber wie ist das Zusammenspiel hunderter Services zu beherrschen? Die Unternehmensarchitektur hat hier die Aufgabe, den fachlichen Überblick über die Geschäftsfunktionen und die Informationsobjekte zu gewährleisten. Es kommt darauf an festzulegen, welcher Service welche Geschäftsfunktion erfüllt und wer die Hoheit über welches Informationsobjekt besitzt.

Zudem muss die Integrationsarchitektur strenge Vorgaben für die technische Integration von Services machen. Der Fokus liegt hier auf leichtgewichtigen technologie-unabhängigen Interfaces (zum Beispiel REST), API Management und Choreographie statt auf Orchestrierung.

Microservices stellen völlig neue Herausforderungen an Querschnittsfunktionen wie Reporting, Monitoring, Backups und Skalierbarkeit. Nicht jedes Microservice-Team sollte das für sich neu erfinden. Es deshalb effizient, dafür zentrale Vorgaben zu entwickeln.

Ist das alles zu schaffen?

Neues Organisationsmodell, Arbeitsweisen, Technologien, Architektur-Governance - mit der Einführung von Microservices ändert sich sehr viel. Sie können die Gründung eines völlig neuen Unternehmens erfordern oder zumindest die langfristige Transformation von Teilen der klassischen Unternehmens-IT. Manche Organisationen gründen tatsächlich eigene Firmen, bevorzugt in Berlin, für die Microservice-Entwicklung und trennen damit die klassische Unternehmens-IT auf. Somit ist schon organisatorisch eine IT der zwei Geschwindigkeiten geschaffen.

Die Herausforderung liegt bei dieser Organisationsform in der übergreifenden Governance der Unternehmensarchitektur. Die klassische Unternehmens-IT, der klassische Fachbereich, das Microservice-Unternehmen müssen schließlich ein gemeinsames Geschäftsmodell verfolgen. Die Unternehmensarchitektur hat hier die Aufgabe, die unternehmensweiten Abhängigkeiten zu managen sowie das Alignment der hochverteilten IT mit der Unternehmensstrategie sicherzustellen.

Kritisch ist es, klare Grenzen und Übergänge zwischen der IT der zwei Geschwindigkeiten zu schaffen, damit sich die unterschiedlichen Paradigmen, Prinzipien und Standards nicht vermischen, sondern gut zusammenspielen.

Aber auch die Transformation von Teilen der klassischen Unternehmens-IT ist möglich. Wichtig wird dabei auch sein, eine neue Organisation zu schaffen, einen neuen Bereich. Entscheidend ist es in dieser Phase, die passenden Mitarbeiter zu finden, die in den neuen Bereich wechseln sollen. Es müssen Pioniere sein, die bereit sind, grundsätzlich neue Arbeitsweise und Technologien zu lernen. Sie benötigen Freiraum für Experimente und auch für ein Scheitern. Auch für neue Mitarbeiter frisch von der Universität sind solche Bereiche häufig sehr attraktiv.

Microservices: viele Chancen, aber hohe Transformationanforderungen

Unterm Strich gilt es, ein Bewusstsein dafür schaffen, dass sich Microservices nicht einfach wie eine klassische Applikation oder Technologie einführen lassen. Mit Microservices kann ein Unternehmen agiler und flexibler werden. Damit lassen sich marktdifferenzierende Wettbewerbsvorteile stark ausbauen, wie die Musterbeispiele Netflix und Amazon zeigen. Diese Firmen haben in ihren jeweiligen Märkten eine beherrschende Stellung erreicht, auch weil sie eine Microservice-Architektur kompromisslos implementiert haben. Allerdings setzt das Einführen von Microservices einen hohen Reifegrad im IT-Management voraus.

Mit der weiteren Digitalisierung der Märkte werden die Anforderungen an marktdifferenzierende Geschäftsfunktionen kontinuierlich steigen. Deshalb ist eine gezielte und klar abgegrenzte Transformation in Richtung Microservices für viele Unternehmen sinnvoll. Sie muss allerdings gut strukturiert und gesteuert werden, sonst ist ein Chaos programmiert. (wh)