SOA-Fehler vermeiden

Software-Architekturen der Zukunft

28.09.2016 von Hajo Normann und Jure Zakotnik
Monolithische Applikationsblöcke hängen wie ein Klotz an vielen Applikationsinfrastrukturen. Nachdem SOA die hoch gesteckten Erwartungen nach mehr Agilität und Flexibilität nicht erfüllen konnte, setzen die Anwender ihre Hoffnungen auf ein Ökosystem an modularen Elementen rund um Microservices, Schnittstellen, Daten und User Interfaces.

So mancher CIO ist bereits an der komplexen und kostspieligen Systemintegration verzweifelt. Selbst vermeintlich kleine Änderungen lassen sich oft nur mit großem Aufwand implementieren. Zudem sind Ursachen für Probleme in der Performance schwer ausfindig zu machen. Der Grund dafür sind nicht selten monolithische Applikations-Suiten in der Software-Architektur. Diese schwerfälligen 'Blöcke' sind genau das Gegenteil dessen, was in einer agilen IT-Organisation gefragt ist.

Deshalb waren in der Vergangenheit große Hoffnungen mit der serviceorientierten Architektur (SOA) verbunden. Im Alltag zeigte sich jedoch, dass die SOA dem Wunsch nach einer leichtgängigeren Architektur oft nicht entsprach. Die Software-Architektur der Zukunft baut zwar auf den Ideen der SOA auf, setzt dabei aber vor allem auf leichtgewichtige, modulare Komponenten.

In den vor einigen Jahren eingeführten SOAs lassen sich die einzelnen Dienste wie in einem Baukastensystem zusammenfügen und anschließend ausführen. Dank End-zu-End Monitoring eines Enterprise Service Bus (ESB) ist schnell und einfach nachvollziehbar, an welcher Stelle zusätzlicher Optimierungsbedarf besteht.

In der Theorie klingt das Konzept gut, doch die praktische Umsetzung läuft selten so reibungslos. Einer der häufigen Fallstricke: Oft wurde die SOA in einer monolithischen Plattform realisiert, so dass zusätzlich zu den monolithischen Applikationen noch eine Middleware nötig war. Zudem wurde die semantische Kopplung zwischen den Systemen nicht aufgelöst sondern lediglich auf den ESB ausgelagert.

Modulare Applikationen und ihr Zusammenspiel sind entscheidend

In der Software-Architektur der Zukunft müssen diese Fehler vermieden werden. Dafür ist ein Ökosystem nötig, in dem verschiedene Typen von Providern teilnehmen, die Services und Funktionalitäten anbieten. Standards und Konventionen sind dabei klar definiert. Das ermöglicht eine stärkere Modularität und ersetzt somit komplexe Integrationslösungen. Allerdings gehören dazu nicht nur eine technische Betrachtung von Microservices und REST-APIs, sondern auch diverse andere Aspekte, auf die wir noch zurückkommen werden.

Ein gutes Vorbild, wie zukünftige Architekturen im Enterprise-Umfeld aussehen können, bietet das Internet. Dort sind Applikationen integriert und spielen scheinbar mühelos zusammen, ohne dass dafür eine komplexe Integrationsplattform oder ein ESB nötig wäre. Die Nutzer finden Mikroabläufe vor, die ohne Workarounds zusammenspielen. Der Login bei AirBnB über den eigenen Facebook-Account und die gewohnte Google-Maps-Oberfläche bei der Suche nach Ferienwohnungen sind gute Beispiele dafür.

Diese Einfachheit legt die Messlatte für die Enterprise-IT weit nach oben - Stichwort Consumerization. Um solch reibungslos ineinandergreifende Anwendungen zu ermöglichen, muss die Software-Architektur der Zukunft auf mehreren Ebenen modularisiert sein:

Die fünf Aspekte eines modernen Ökosystems im Enterprise-Umfeld

Für die Umsetzung eines modernen Architektur-Ökosystems im Enterprise-Umfeld sind fünf Aspekte besonders wichtig: API-Orientierung, Datenintegration 2.0, integrierte Workflows, die User Experience und eine agile Evolution dieser vier Komponenten.

1. API-Orientierung durch standardisierte Schnittstellen

Mit Einführung der SOA wurden Applikationen in der IT-Landschaft massenhaft mit Web-Service-Adaptern ausgestattet. Dies tat man in dem Glauben, dass ein standardisiertes Format genüge, um die Systeme einfacher miteinander kommunizieren zu lassen. Allerdings änderte sich dadurch nichts an der komplexen Semantik der Web Services. Die erhoffte Vereinfachung konnte erst durch die Einführung des REST-Paradigmas erreicht werden, das auf einer Ressourcenorientierung mit simplen CRUD-Operationen (Create, Read, Update, Delete) basiert.

Die Nutzung von REST ermöglicht leichtgewichtige Komponenten für das API-Management, die sich hauptsächlich auf Management, Test, Dokumentation und Monitoring der REST-Schnittstellen fokussieren. Durch ihre Einfachheit sind komplexe Registries, wie in der SOA-Welt bisher üblich, nicht mehr notwendig. Die Standardisierung von REST-Schnittstellen ist vor allem dann von Nutzen, wenn Unternehmen für ihre eigenen digitalen Geschäftsmodelle die Daten externer Anbieter einbinden wollen. Angesichts der zahlreichen Open-Data-Initiativen wird dies immer wichtiger, etwa um in den eigenen Anwendungen beispielsweise auf Fahrplaninformationen der Deutschen Bahn zuzugreifen.

2. Datenintegration mit dem CQRS-Muster

In den zurückliegenden Jahren wurden zahlreiche ETL-Tools (Extract, Transform, Load) für eine bessere Integration von Daten in eine bestehende Software entworfen. Diese folgen einer ähnlichen Logik, wie sie bei der Integration von Services in einen ESB zur Anwendung kommt. Dabei sind jedoch oft monolithische Datendrehscheiben entstanden, die nicht zur gewünschten Entkopplung der Datenmodelle beitrugen. Das Problem: Trotz Middleware und Datenvirtualisierung führt eine Änderung in einem Tabellenschema zu zahlreichen Nebeneffekten in anderen Datentöpfen.

Ein Ansatz, um auch die Daten zu entkoppeln, sind kostengünstige Open-Source-Lösungen wie Hadoop oder Kafka. Darauf basiert auch das CQRS-Muster (Command, Query, Responsibility, Separation). In diesem Muster bleiben die existierenden Datentöpfe zwar erhalten, parallel wird jedoch ein separates Datenmodell aufgebaut, welches für Read-Only-Zugriffe und Analytics optimiert ist. Dieses zusätzliche Datenmodell kann Redundanzen enthalten, um eine einfachere oder schnellere Analyse zu ermöglichen. Da die ursprünglichen Daten nicht verändert werden, können Nutzer diese auf zahlreiche Art und Weise analysieren. Dies ermöglicht eine echte Entkopplung von missionskritischen Systemen die im Command-Pfad von CQRS erhalten bleiben.

3. Mehr Personalisierung durch Entkopplung und Modularisierung von Workflows

Makroflows, die in externen Applikationen ausgedrückt sind, gehören in einer modernen Software-Architektur der Vergangenheit an. An ihre Stelle rücken Microflows, die von den Endnutzern für die Erfüllung einer bestimmten Aufgabe pluggable und ad-hoc zusammengebaut werden können. Das ist die Grundlage für personalisierte Anwendungen, die den Nutzern in ihrer täglichen Arbeit einen großen Gestaltungsspielraum lassen. Diese wollen schließlich möglichst viel Kontrolle über Daten und Abläufe behalten statt in vorgegebene Systeme gezwängt zu werden.

Die Nutzung von Daten aus bestehenden Applikationen ist heute oft unnötig kompliziert und wenig nutzerfreundlich. Die Folge: Nutzer kopieren sich die Daten lieber mühselig aus der Applikation in andere Software-Tools wie zum Beispiel Excel, verarbeiten sie dort weiter, nur um sie am Ende wieder zurück in die Anwendung zu laden. Wesentlich komfortabler wäre hingegen ein eigenes User Interface (UI) für jeden Nutzer - eine Spielwiese, deren Aufbau sie verstehen und die sie ganz nach ihren Wünschen gestalten und kontrollieren können. Die heutigen Komponenten bieten diese Freiheitsgrade jedoch nicht, da sie auf standardisierten Softwarekomponenten aufbauen.

Deshalb muss eine Architektur der Zukunft so gestaltet sein, dass die einzelnen Module als Grundbausteine funktionieren, die der Nutzer ganz individuell kombinieren kann. So lassen sich personalisierte Abläufe und Benutzererfahrungen einfach umsetzen. Das hat aber auch Folgen für die Unternehmen: Statt wie bisher als monolithische Dienstleister aufzutreten, werden sie zu Anbietern von modularen Diensten, deren Funktionen gegen Bezahlung in konkrete Abläufe eingebaut werden.

Kurz gesagt: Die Module, aus denen sich ein Benutzer seine Abläufe zusammenstellt, werden nicht mehr nur von der eigenen Organisation bereitgestellt, sondern ergeben sich aus einem globalen Ökosystem ohne zentrale Kontrolle. Das stellt jedoch neue Herausforderungen an die Firmen-IT. Sie muss sicherstellen, dass die von den Mitarbeitern und den Endkunden benutzten Module sowohl fachlich wie auch sicherheitstechnisch im Einklang mit den Zielen der Gesamtorganisation stehen.

4. Exzellente User Experience entlang modularer Services

Die Nutzeroberfläche ist ein weiterer Baustein auf dem Weg zu modernen Software-Architekturen. In der SOA-Welt wurden die modularen Services bisher mit Hilfe von Mash-Applikationen in eigene UI-Plattformen eingebunden. Dieser Ansatz schlug jedoch aus zwei Gründen fehl: Zum einen konnten die UI-Plattformen mit modernen HTML5-Applikationen, wie sie im Internet gängig sind, nicht mithalten. Hinzu kommt, dass die User Experience in den Mash-Applikationen mit Wasserfall-orientierten Methoden entwickelt wurde. Deshalb konnten sie der schnellen Evolution der UI-Frameworks nicht folgen.

Für eine bessere User Experience ist eine stärkere Modularisierung der Applikationen unbedingt notwendig. Viele Unternehmen verfolgen heute bei der Entwicklung von Software einen Design-Ansatz, indem sie etwa User-Journeys gestalten. Weiterhin lassen sich durch die Vielzahl von Javascript-Frameworks heute sehr schnell HTML5 responsive Web-Applikationen erstellen, die wiederum eine sehr schnelle Evolution ermöglichen. Dadurch entfallen lange Analyse- und Design-Phasen, Benutzeranforderungen können innerhalb von wenigen Tagen statt wie bisher erst in Wochen umgesetzt werden. Eine spezielle UI- oder Mash-Plattform ist dafür nicht mehr notwendig.

5. Eine stetige Evolution im Sinne der Nutzer

Der letzte Punkt betrifft die Liefermethodik, also die Frage, wie die modularen Systeme entwickelt werden. Es gibt heute kaum noch Projekte, die den klassischen Wasserfall-Ansatz wählen. Das liegt vor allem daran, dass die modularen Paradigmen einen agileren Ansatz ermöglichen. Damit ist nicht nur das klassische Scrum gemeint, sondern auch andere Methoden aus der Open-Source-Community. Dazu gehören Voting-Systeme und Gamification-Konzepte, die das Feedback der User einbeziehen, um die Services daraufhin zu verbessern.

Die beschriebenen Konzepte ermöglichen ein agiles Update der Services oder Daten - wie zum Beispiel in einem Query-Datastore - ohne Risiken für das laufende System. Erst durch die raschen Feedback-Schleifen und kontinuierliche Updates von APIs, Daten, Workflows und UIs kommen die modularen Konzepte zum Tragen und liefern echten Mehrwert für das Business.

Fazit

Die Ansätze der SOA - einer lose-gekoppelten und leichtgewichtigen Architektur - sind eine wichtige Grundlage für moderne Software-Architekturen. Ihre Stärken kommen aber erst im Zusammenspiel mit modernen Konzepten für API Management, Datenintegration, Workflow-Modularisierung und einer perfekten User-Experience zum Tragen. Obwohl die SOA-Idee längst etabliert ist, werden ihre Prinzipien mit dem beschriebenen Architektur-Konzept und einem agilen Vorgehen endlich in der Praxis umsetzungsfähig.

Dafür braucht es nun keinen monolithischen ESB mehr. Stattdessen genügen leichtgewichtige, modulare Komponenten in den oben beschriebenen Dimensionen. Wichtig ist dabei, alle Aspekte gleichermaßen im Blick zu behalten und kontinuierlich zu entwickeln - von den Schnittstellen, über Daten und Workflows bis hin zur User Experience. Nur im Zusammenspiel aller Module entstehen ein optimales IT-System sowie eine zukunftsfähige Softwarearchitektur.