Integrationsarchitekturen

Die Evolution der IT-Architekturen

18.02.2015
Von   
Bernhard Steppan arbeitet als IT-Chefarchitekt bei DB Systel GmbH (Deutsche Bahn) in Frankfurt am Main. Er hat 100+ Artikel und zahlreiche Bücher über C++ und Java verfasst. Er betreibt mehrere Blogs, unter anderem http://steppan.net, http://artouro.org und http://tourbine.com
Das Konzept der serviceorientierten Architektur (SOA) hat sich aus verschiedenen Integrationslösungen entwickelt. Dieser Beitrag beleuchtet die Stationen dieser Entwicklung.
Foto: vallepu - Fotolia.com

Die Anfänge der Integration verschiedene Anwendungen in einem Unternehmen reichen zurück zu sehr einfachen Architekturen. Wenn es nur darum geht, wenige Anwendungen zu verbinden, dann funktioniert das natürlich auch ohne komplexe SOA-Produkte. Eine Integration ohne entsprechende Produkte führt meistens zu Peer-to-Peer- oder Client-Server-Architekturen.

Peer-to-Peer-Architekturen

Peer-to-Peer-Architekturen sind der einfachste Weg zur Integration. Anwendungen werden hierbei direkt miteinander verbunden (Siehe Bild: Peer-to-Peer-Architektur). Vorteil des Peer-to-Peer-Verfahrens ist, dass die Integrationsmethode einfach zu erlernen ist. Die Integration liegt vollkommen in der Kontrolle des Entwicklungsteams, das zur Integration spezielle Adapter für andere Systeme entwickeln muss. In der Regel ist hier die Philosophie, dass das Nachbarsystem möglichst nicht verändert wird. Stattdessen liegt im Adapter die gesamte Integrationsarbeit. Ein anderer Weg ist es, dass das Nachbarsystem für die neuen Anforderungen angepasst und danach ein spezieller Adapter geschrieben wird.

Peer-to-Peer-Architekturen bauen Netzwerke mit vielen Abhängigkeiten auf. Diese Integrationsarchitektur birgt viele Risiken insbesondere bei Migrationen.
Peer-to-Peer-Architekturen bauen Netzwerke mit vielen Abhängigkeiten auf. Diese Integrationsarchitektur birgt viele Risiken insbesondere bei Migrationen.
Foto: Steppan

Diese Adapter sind der erste gravierende Nachteil dieser Architektur. Dadurch, dass kein Standardverfahren für die Entwicklung solcher Adapter existiert, besteht die Gefahr, dass die Entwicklungsteams sehr spezielle Lösungen programmieren. Zudem müssen diese Lösungen individuell dokumentiert werden. Ihre Funktion ist daher unter Umständen für Außenstehende nur schwer zu verstehen und zu warten. Ein weiterer Nachteil von Peer-to-Peer-Architekturen ist die schlechte Wiederverwendung. Lösungen, die innerhalb der Anwendungen existieren, sind meistens so speziell auf das System zugeschnitten, dass sie anderweitig kaum einsetzbar sind.

Problematisch ist auch, dass mit solchen Architekturen die Gefahr eines Spaghetti-Designs der Unternehmenslandschaft steigt. Ein Wildwuchs von Verbindungen schafft sehr viele Abhängigkeiten. Erfahrungsgemäß sind diese Abhängigkeiten schlecht dokumentiert. Existiert kein Bebauungsplan (siehe Kasten "Glossar"), müssen die Abhängigkeiten durch aufwändige Revisionsprojekte ermittelt werden, um die Risiken zu minimieren. Migrationsprojekte sind in solchen Architekturen wegen der vielen unbekannten Abhängigkeiten aufwendig und teuer. Da man meistens nicht alle Abhängigkeiten feststellen kann, sind solche Projekte zudem riskant. Und nicht zuletzt skalieren solche Architekturen sehr schlecht, weswegen sie meistens durch eine Client-Server-Architektur abgelöst werden.

Glossar

Ein IT-Bebauungsplan ist ein Konzept des Enterprise Architekturmanagements (EAM). Er soll die Unternehmensarchitektur verdeutlichen und die Abdeckung der Anwendungen in Bezug auf die vorhandenen Geschäftsprozessen aufzeigen.
Das Simple Object Access Protocol ist ein Standard für den Austausch von Nachrichten über Webservices.
Die XML Schema Definition (XSD) ist eine Sprache für die Beschreibung von XML-Dateien. Sie dient bei Web-Services dazu, Datenmodelle von SOAP- und Rest-Web-Services zu definieren.
Die Web Service Description Language (WSDL) ist eine Beschreibungssprache für – vor allem – SOAP-Web-Services, aber auch Rest-Web-Services.