Der Integrationsarchitekt: Ein Spezialist mit Allrounder-Fähigkeiten

In großen Konzernen existieren oft gewachsene, heterogene IT-Systemlandschaften, die aus Fusionen und Neustrukturierungen resultieren. Im Spannungsfeld zwischen klassischer Softwareentwicklung, Analyse bestehender Systeme und Durchführung übergreifender IT- Projekte kann der Integrationsarchitekt seine ganze Stärke ausspielen.

Dabei steht er vor der Entscheidung die schwergewichtigen Produktsuiten großer strategischer IT-Partner einzusetzen oder aber den Einsatz schlanker und quelloffener Lösungen zu wagen.

Wenn Konzerne fusionieren, existieren danach immer heterogene Systemlandschaften. Altsysteme stehen nebeneinander und arbeiten oft nicht zusammen. Die Redundanz für Wartung und Betrieb fachlich deckungsgleicher Anwendungslösungen sowie mehrheitlich vorhandener Anwendungsplattformen reduzieren den angestrebten Einsparungseffekt der Fusion.

Der fusionierte Konzern hat zu entscheiden, entweder eine neue IT-Systemlandschaft zu erschaffen oder die bestehenden Teile zusammenzuführen. Beide Lösungen bieten Vor- und Nachteile und meist liegt der eingeschlagene Weg dazwischen. Denn selbst bei der Fokussierung auf eine Neuentwicklung müssen die Altsysteme übergangsweise am Leben gehalten werden.

IT-Professionals sind gefordert sich diesen Herausforderungen zu stellen und den fachlichen Abteilungen des Konzerns wert- und nachhaltige Lösungen zu liefern.

Zentral und vernetzt an vielen Fronten

Als Integrationsarchitekten können die IT-Mitarbeiter bezeichnet werden, die sich auf die konzeptionelle Zusammenführung bestehender Anwendungen und Plattformen spezialisiert haben. Sie konstruieren aus bestehenden Bausteinen neue IT-Landschaften, die dem aktuellen Stand der Technik entsprechen, soweit als möglich bestehende Altsysteme einbinden und so den Nutzen der IT-Unterstützung für den Fachbereich optimieren.

Der Integrationsarchitekt wirkt als eine Art „Mittelfeldspieler“, der auf mehreren Ebenen zentral und gleichzeitig vernetzt agiert. Das macht seine Position auf der einen Seite sehr bedeutsam, damit auf der anderen Seite aber auch sehr anspruchsvoll.

In der Diskussion über die Integrationsarchitektur fallen zwangsläufig Begriffe wie Geschäftsprozess und Service. Der Integrationsarchitekt ist dafür verantwortlich, Verfahren und Plattformen in die Systemlandschaft einzubinden, die eine IT-Unterstützung für diese Ansätze ermöglichen. Hier kommt das angesprochene Denken auf verschiedenen Ebenen zum Tragen.

Die Zusammenarbeit mit Fachbereich, Anwendungsentwicklern, anderen Architekten, dem Systembetrieb sowie weiteren beteiligten Rollen des Konzerns erfordert ein hohes Maß an adressatengerechter Kommunikations- und Arbeitsweise, ohne dabei das Gesamtbild aus den Augen zu verlieren.

Ein ‚fliegender Wechsel’ zwischen den Abstraktionsebenen ist dabei erfolgskritisch. Der Integrationsarchitekt muss in der Lage sein, auf der Ebene der Programmiersprache zu diskutieren oder selbst zu programmieren, als Verantwortlicher für die Integrationsplattform beratend und schulend den Fachentwicklern zur Seite zu stehen oder auch sein IT- Wissen soweit zu abstrahieren, dass er auf Augenhöhe mit dem Fachbereich Anforderungen aufnehmen und diskutieren kann.

Komplexität lässt sich nicht verstecken

Wesentliche Teile einer Integrationsplattform sind der Enterprise-Service-Bus (ESB) sowie ein Verfahren für das IT-gestützte Business-Process-Management. Hier lässt sich zwischen den Produktsuiten großer Hersteller wie IBM, SAP und Oracle wählen oder aber man implementiert eine schlanke und individuelle Lösung mit Hilfe von quelloffenen Tools und Bibliotheken.

Firmen tendieren häufig dazu, die Produktlösungen der strategischen IT-Partner einzusetzen, zumal die Versprechen dieser Suiten wie Kapselung der Komplexität, grafische „Programmierung“ und ein All-In- On-Ansatz auf den ersten Blick verlockend erscheinen.

Tatsächlich wird hier aber nicht beachtet, dass das technisch anspruchsvolle und vielschichtige Umfeld keine schwergewichtigen Anwendungen benötigt, die den Fokus auf einfache Bedienung und scheinbaren Komfort legen. Viel wichtiger ist es, auch bei unvorhergesehenen Problemstellungen bestmögliche Transparenz und Eingriffsmöglichkeiten zur Verfügung zu haben.

Der Integrationsarchitekt ist idealerweise ein Softwareingenieur mit einem entsprechenden Selbstverständnis. Dies bedeutet nicht, das Rad immer neu erfinden zu wollen, wohl aber selbst die Kontrolle über die Entwicklungsumgebung und das zu entwickelnde System zu haben. Im Zweifel muss er auch mal bis in den Quellcode einer Business-Process-Engine abtauchen können um individuelle Erweiterungen einzubauen oder hartnäckigen Fehlern nachzuspüren. Hier ist man bei geschlossenen Systemen häufig auf den Support der Hersteller angewiesen.

Teil der Gemeinschaft

Auch im Bereich der Integrationsarchitektur existieren entsprechende Bibliotheken und Lösungen, etwa zum Aufbau eines ESB oder einer Process-Engine. Diese haben gegenüber den Produktsuiten den Vorteil schlank und anpassbar zu sein und sich daher nahtlos in den bestehenden IT-Anwendungsrahmen integrieren zu lassen.

Bei Problemen und Fragen existiert meist eine große Gemeinschaft engagierter Entwickler und IT- Spezialisten. Als Teil dieser Community kann der Integrationsarchitekt ohne Abhängigkeit von einem Hersteller Fragen adressieren, Anregungen aufnehmen und bestenfalls auch Erfahrungen zurückgeben. Konzerne können bei Bedarf trotzdem auf spezialisierte Dienstleister zurückgreifen, die für die freien Bibliotheken professionellen Support bieten und auch Gewährleistungen übernehmen.

Fazit: Der hier vorgestellte Integrationsarchitekt ist IT-Spezialist, der große Firmen, Rechenzentren und Konzernen bei der Vernetzung, Konsolidierung und Neuentwicklung ihrer IT-Systeme und Anwendungslandschaften federführend unterstützt. Als Allrounder und Teamplayer greift er auf ein aktives Netzwerk von Kollegen anderer Abteilungen zurück.

Trotz der Affinität zur Konzeption und Implementierung technisch sauberer Systeme behält er auch die Kosten und den Business Case im Blick. Bei der Erschaffung einer Integrationsplattform zieht er schlanke, transparente und integrationsfähige Bibliotheken den starren und geschlossenen „Zero- Coding“ Produktsuiten großer Hersteller vor.