Seite 3: Zerteilung der bisher bereitgestellten Funktionalität

Inhaltsverzeichnis

Um eine strukturierte Datenlage sicherzustellen, die in der späteren Weiterentwicklung und Anbindung von Anwendungen enorme Wichtigkeit besitzt, hat das Projektteam bei der Ablösung der Legacy-Software am Anfang der Prozesskette angesetzt. Dieser Schritt stellte die schnelle Verfügbarkeit prozesskritischer Anwendungen sicher, die einen abgesteckten Funktionsumfang bieten und von den aufbereiteten Daten profitieren. Wie erwähnt, wurden einige Komponenten zu Beginn der Neuausrichtung sowohl an die Legacy-Software als auch an die neue Systemlandschaft angebunden. Das bot den Vorteil, dass sich der Betrieb nahtlos fortführen ließ und weiterhin die Neuentwicklung schon im produktiven Einsatz erprobt wurde.

Die Integration der Anwendungen untereinander setzt das Projektteam durch einfache Verlinkungen mit einem zentralen Login um. Damit entfallen aufwendige Integrationsaufgaben und Abstimmungen über die Teams hinweg. Die Benutzer der Software bekommen in den meisten Fällen nur wenig von einem Wechsel der Anwendungen mit. Dafür bieten die Anwendungen genau auf Benutzergruppen abgestimmte Ansichten, da das jeweilige Team sich auf die einzelne Fachdomänen konzentrieren kann. Die Teams untereinander können aber weitgehend unabhängig agieren und autark arbeiten.

Monolith versus Microservice – am Ende überwiegen die Vorteile

Der Service-Ansatz reduziert die Komplexität der einzelnen Applikationen, denn anstelle einer großen Anwendung, in der alles miteinander zusammenhängt und verknüpft ist, beschränken sie sich nun auf einen einzigen, fachlich klar abgegrenzten Aufgabenbereich. Die Applikation ist kleiner und damit der Quellcode weniger umfangreich, was ihn verständlicher und leichter testbar macht.

Die Entkopplung der einzelnen Systembestandteile voneinander führt auch zu einer höheren Systemrobustheit: Sollte es zu einem Fehler, zu Performanceproblemen oder gar einem Ausfall einer Anwendung kommen, ist nur ein kleiner Teilbereich des Systems und damit des Unternehmens betroffen. Während ein Monolith in diesem Fall vollständig auszufallen droht, kann man in einem verteilten System weiterarbeiten. Durch die fachliche Trennung der Anwendungen ist im konkreten Fall sogar nur genau eine Fachabteilung von einem Problem betroffen.

Möglich wird die hohe Unabhängigkeit durch das bewusste Zulassen von Datenredundanzen. Anders als in klassischen, relationalen Datensystemen lassen sich Daten in verteilten Systemen als Kopien in den einzelnen Anwendungen speichern. Das erhöht die Unabhängigkeit der einzelnen Systemteile – man muss sich jedoch Gedanken darüber machen, wie Änderungen von Daten über die verschiedenen Anwendungen hinweg verarbeitet werden.

Es zeigt sich, ganz ohne Kopfzerbrechen geht es nicht. Trotz aller Vorteile hat auch diese Architektur ihre Wermutstropfen: Zwar kann man die Komplexität einer Software-Applikation mit diesem Ansatz deutlich verringern, nicht jedoch die des Gesamtsystems. Die vielen, grundsätzlich voneinander unabhängigen Applikationen müssen permanent miteinander kommunizieren und Daten austauschen. Somit verschiebt sich die Komplexität aus der einzelnen Anwendung auf die Kommunikationsebene dazwischen.