SOA-Fehler vermeiden

Software-Architekturen der Zukunft

28.09.2016
Von Hajo Normann und
Senior Technology Architect bei Accenture
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:

  • den Schnittstellen,

  • der Datenhaltung,

  • der Infrastruktur sowie

  • der Fachlogik beziehungsweise den Workflows.

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.