– SYSTEMINTEGRATION

Warum Systemintegration einen eigenen Ort benötigt

Und nicht nur das – Integration braucht auch ein neues Bewusstsein

Share on facebook
Share on twitter
Share on linkedin
Share on email

– Abstract

Herausforderungen und Risiken von Integrationsprojekten

Integrationsprojekte bergen nicht nur Risiken, sondern stellen vor allem eine ganze Reihe von Herausforderungen an IT-Organisationen. Ein klares Integrations-Mindset hilft hier, die Prinzipien von Systemintegration zu erkennen, zu verstehen und zu beachten – etwa die Vor- und Nachteile unterschiedlicher Integrationskonzepte wie Peer-to-Peer, Hub-and-Spoke und Logical Hub.

Laut Duden bedeutet Integration das Einbeziehen oder das Eingliedern in ein größeres Ganzes. Der Begriff steht jedoch auch dafür, eine Vielheit einzelner Personen zu verbinden. Oder Gruppen zu einer kulturellen oder gar gesellschaftlichen Einheit zusammenzuschweißen.

Was ist Integration?

Übertragen – nicht nur auf Software-Systeme – geht es bei Integration also um einen äußerst vielschichtigen und komplexen Prozess: Wer ein (neues) Software-System in eine bestehende Anwendungslandschaft eines Unternehmens integriert, muss vergleichbare Herausforderungen wie in sozialen Systemen bewältigen. Denn auch hier sprechen die beteiligten Systeme nicht nur unterschiedliche Sprachen (Java, Cobol, PL/I, etc.), sondern zu allem Überfluss auch noch verschiedene Dialekte (wie UTF-8 vs. EBCDIC).

Leitfragen für die Systemintegration

  • Welches sind die Herausforderungen, die zu Integrations-Schwierigkeiten führen?
  • Was macht eine gute Integration überhaupt aus?
  • Welche Prinzipien und Lösungsoptionen können wir daraus ableiten?

Auch der Lebensraum (wie Server, Cloud, Clients) und die Form der Kommunikation (wie synchron oder asynchron; REST, SOAP, File oder MQ), die für die beteiligten Systeme in Frage kommen, können sehr unterschiedlich ausfallen. Die System-„Kulturen“ und das dort abgebildete fachliche Verständnis können deutlich voneinander abweichen. Eine mögliche Konsequenz: Selbst eine funktionierende technische Integration wäre aus fachlicher Sicht nicht funktionsfähig. Doch warum sollte Integration bei Software-Systemen auch einfacher sein als in anderen Ökosystemen?

In allen Fällen gilt die Regel: Integration braucht einen (sic!) Ort

Denn zunehmende Anforderungen für neue, digitale Geschäftsmodelle führen zu einer steigenden Vernetzung unterschiedlicher Systeme. Genau das gestaltet sich komplex: Immer öfter werden zur Abbildung innovativer Geschäftsmodelle auch die Unternehmensgrenzen überschritten. Gleichzeitig spezialisieren sich die Systeme immer stärker. Neben großen, zunehmend modularer aufgebauten Systemen setzen sich sukzessive Microservices durch.

Hohe Komplexität: Integration bildet eine eigenständige Disziplin

Entsprechend standardisierte Funktionalitäten lassen sich in Form von Systemen und Services lizensieren oder per Software as a Service (SaaS) nach Bedarf beziehen. Individuelle Änderungen sind je nach Angebot in definierten Grenzen möglich. Für Integrationen hingegen gelten grundsätzlich höchst individuelle Ausgangssituationen. Diese bestimmen die Integrationsanforderungen und erfordern, Integration als eigenständige Disziplin zu verstehen und zu betreiben. Die Faktoren:

  • vorhandene Anwendungslandschaften
  • unternehmensspezifische Ziele
  • entsprechend gestaltete Produkte und Prozesse
  • neue Zusammenarbeits- und Geschäftsmodelle
  • sowie viele weitere Aspekte.

– Lösungen

Warum die Versicherungs- und Finanzwirtschaft Systemintegration braucht

Die Mehrzahl der Unternehmen aus dem Bankensegment und der Versicherungswirtschaft verzeichnet deutlichen Optimierungsbedarf bei ihrer IT. Gerade die traditionell geführten Player sehen sich mit in die Jahre gekommenen IT-Landschaften konfrontiert: Oft mangelt es bei einzelnen IT-Systemen und Datenbanken an Schnittstellen zum gegenseitigen Datenaustausch.

Viele aktuelle Architekturen erschweren Projekte, die darauf abzielen, digitale Geschäftsmodelle umzusetzen und Prozesse zu automatisieren. Zu diesem Ergebnis kommt die Lünendonk-IT-Studie 2020. Demnach beurteilt jeder dritte bzw. jede dritte befragte Digital- und IT-Entscheider:in eine verzweigte, komplexe IT-Landschaft in seinem Unternehmen als Hindernis für die digitale Transformation. Lediglich 26 Prozent der Befragten empfinden den Einfluss der hohen IT-Komplexität auf die Umsetzung der digitalen Transformation als „weniger stark“.

Integrationsevolution prägt Integrationsparadigmen – drei Konzepte im Wandel

Peer-to-Peer führt zu individuellen Fehlern und neuen Kopf-Monopolen

Software-Integration fing mit sogenannten Peer-to-Peer-Integrationen an. Bei diesen P-to-P-Integrationen sind alle Systeme „Punkt zu Punkt“ direkt miteinander verbunden. Die Zahl der Verbindungen wurde dadurch enorm groß. Im Extremfall verfügt jedes System über eine Verbindung zu allen anderen Systemen.

Konzept Peer-to-Peer-Integration

Aber genau das wird mit einer wachsenden Zahl von (kleineren) Systemen und Services zu einem immer größeren Problem. Systeme und Services müssen schließlich alle integriert sein. Der Nachteil: Die Integrationslogik verteilt sich auf alle beteiligten Systeme. Integration hat hier keinen Ort, sondern unüberschaubar viele. In der Folge erhalten Integrationen einen individuellen Charakter mit ebenso individuellen Fehlerquellen und Abhängigkeiten von – neu entstehenden – Kopfmonopolen.

Hub-and-Spoke-Architekturen machen Integrationen handhabbar

In der darauf folgenden Evolutionsstufe konzentrierten Hub-and-Spoke- oder auch Bus-Architekturen die Integration auf einen zentralen Punkt. Ein typischer Vertreter hiervon sind die Enterprise-Service-Bus-Systeme (ESB). Die Vorteile dieser Topologie liegen darin, dass sich bei ihr die Zahl der Verbindungen drastisch reduziert und die Systeme durch die zentrale Integrationslösung voneinander entkoppelt werden (Loose Coupling). Integration hat hier einen Ort.

Dieser Vorteil bringt allerdings auch den größten Nachteil von ESB-Systemen mit sich: Sie muten wie monolithische Kraken in der Infrastruktur an. Und sie sind nicht auf die individuellen Anforderungen neuer Geschäftsmodelle mit vielen beteiligten Partnern ausgelegt. Es ist zudem höchst unwahrscheinlich, dass sich eine Gruppe noch unbestimmter Partner auf ein kostenintensives, proprietäres System einigt, das einen Vendor-Lock-in des jeweiligen Herstellers mit sich bringt.

Logical-Hub-Mindset vereint das Beste aus zwei Welten

Eine, in der Integrations-Evolution fortgeschrittene Logical-Hub-Architektur vereint das Beste aus beiden Welten: die grenzenlose Flexibilität einer Peer-to-Peer-Architektur mit der Stringenz einer einheitlichen Integrationsarchitektur. Wie bei einer Hub-and-Spoke-Architektur konzentrieren sich – hier aber nur logisch – alle Integrationen auf einen Punkt. Damit erhält Integration auch hier einen Ort.

Das „logische Zentrum“ eines Logical Hub versammelt eine Menge einheitlicher, allerdings voneinander unabhängiger Integrations-Adapter. Zusammen fungieren diese wie ein logischer ESB. Diese einzelnen, als Microservice implementierten Integrationsadapter lassen sich auf die unterschiedlichsten Umgebungen verteilen.

Integration-Evolution, die fortgeschrittene Logical-Hub-Architektur

Die Bandbreite reicht hier von On-Premise- über (Multi-) Cloud-Installationen bis hin zu Integration-Platform-as-a-Service- (iPaaS) oder Software-as-a-Service-Lösungen (SaaS). Die Implementierung ist dabei grundsätzlich Technologie-agnostisch. Sie wird aber in der Praxis auf einem definierten Set unterschiedlicher, vorzugsweise Open-Source-Technologien basieren. Das hält Systeme wartbar. Außerdem verringern sich Abhängigkeiten. Architektonisch lässt sich dieses Set jederzeit ändern. Und es lässt sich schrittweise an technologische Weiterentwicklungen anpassen. Die logische Konzentration der Integrationen an einem Ort hat wesentliche Vorteile: Alle Integrationen folgen den gleichen Architektur- und Design-Regeln. Das verhindert wirksam Kopfmonopole. Darüber hinaus bildet sich ein organisatorischer Rahmen. Dieser lässt sich für eine koordinierte (Weiter-) Entwicklung aller Integrationslösungen sowie der benötigten Infrastruktur nutzen. Last, but not least ermöglicht eine offene Integrationsarchitektur die Zusammenarbeit mit unterschiedlichen Partnern. Mehr noch: Sie begünstigt solche Konstellationen sogar.

Integrationsszenarien auf und zwischen unterschiedlichen Architektur-Layern

Integrationen finden auf unterschiedlichen Ebenen statt

Integrationen können grundsätzlich auf und zwischen ganz unterschiedlichen Architektur-Layern stattfinden: Es lassen sich eine Vielzahl von Integrationsszenarien herausarbeiten. Das veranschaulicht auch diese Grafik.

Diese Integrationslösungen berücksichtigen konzeptionelle, technologische und Plattform-Aspekte

Entscheidend für Integrationslösungen sind die folgenden drei Sichtweisen:

Integrationslösungen berücksichtigen konzeptionelle, technologische und Plattform-Aspekte

Konzeptionelle Sicht: Integrationsmuster liefern Lösungsansätze

Unter Anwendung einer Vielzahl von Integrationspatterns lassen sich typische Integrationsprobleme lösen. In ihrem Kompendium „Enterprise Integration Patterns“ – dem Standardwerk zu Integrationspatterns – definieren die Autoren Gregor Hohpe und Bobby Woolf 65 Integrationspatterns, die eine sogenannte Pattern Language („Wörter“) bilden. Daraus lassen sich wiederum komplexere Patterns („Sätze“) zusammenstellen.

Technologische Sicht: Tech mit Frameworks einheitlich nutzbar machen

Integrationstechnologien, die für die Umsetzung notwendig sind, stehen hier im Mittelpunkt. Je nach Integrationsanforderung und beteiligten Systemen handelt es sich um sehr unterschiedliche Technologien. Es entstanden sogenannte Integration Frameworks: Das bekannteste ist Apache Camel. Es sorgt dafür, die Vielzahl der eingesetzten Technologien einheitlich nutzbar zu machen.

Plattform-Sicht: Den Betrieb von Integrationslösungen absichern

Integration Frameworks bilden zwar eine leistungsfähige Grundlage für die Entwicklung von Integrationslösungen. Allerdings stellen sie keine betreibbaren Integrationsplattformen dar. Hierfür bedarf es vieler weiterer Komponenten. Diese sind für den sicheren Betrieb der Lösung erforderlich. Integrationsplattformen wie ein Enterprise Service Bus (ESB) oder Plattformen, die der Logical-Hub-Architektur folgen, unterstützen hier. Mit der eigenen Integrationsplattform SIP („System Integration Platform“) hat beispielsweise IKOR eine leichtgewichtige und ausschließlich auf Open-Source-Technologien basierende Lösung entwickelt.

Hier schließt sich der Kreis: Für die Auswahl der Integrationsplattform müssen IT-Organisationen definieren, für welche Integrationsszenarien sich die Plattformen eignen sollen (siehe oben, Abschnitt „Integrationen finden auf unterschiedlichen Ebenen statt“). Zentrale Integrationsplattformen wie ein ESB sind hier beispielsweise auf die Nutzung der jeweils unterstützten Infrastruktur beschränkt. Somit stellt sich schnell die Frage, wie viele Integrationsarchitekturen wir für unterschiedliche Integrationsanforderungen einsetzen wollen. Und es gilt festzulegen, wie flexibel die Plattformen sein müssen, um in der sich schnell ändernden Technologielandschaft und einer Welt voller innovativer Geschäftsmodelle nicht ständig weitere Heterogenität zu verursachen.

Share on facebook
Share on twitter
Share on linkedin
Share on email
hans-juergen-von-henning
Hans-Jürgen von Henning ist als Partner von IKOR auf die Umsetzung von Integrationsprojekten spezialisiert.

Ansprechpartner

Hans-Jürgen von Henning

Partner
IKOR GmbH
finsure@ikor.one
+49 40 8199442-0

„Für neue, nutzbare Potenziale bedarf es neuer Lösungsansätze und der Weiterentwicklung“

Empfehlungen