- SYSTEMINTEGRATION
Integration hört niemals auf – Herausforderungen und Lösungsansätze
Wie Systemintegration zum Erfolg wird – Teil 2/2
- •
- Hans-Jürgen von Henning
– Abstract
Kurze Entwicklungszeiten, modulare Architekturen und nutzerzentrierte Usability:
Viele Integrationslösungen entstehen zunächst projektbezogen. Doch viele dieser Projektlösungen schaffen nach Projektabschluss leider nicht den Sprung hin zu einem unternehmensweit verfügbaren Integrationsservice. Wer neue Business-Potenziale heben will, sollte aber genau das zum Ziel haben – Zeit für eine Konzeptänderung.
Die Entwicklung der häufig sehr vielen Schnittstellen im Rahmen eines Projekts zur Einführung neuer zentraler (Kern-) Systeme ist grundsätzlich sinnvoll. Eine vom Projekt losgelöste Entwicklung kann eine Entwicklungsorganisation allerdings kaum bewältigen: Die Abhängigkeiten in der Konzeption, der Umsetzung und dem gemeinsamen Test sind dafür einfach zu groß.
– Fast Lane
In diesem Artikel erfahren Sie:
- Welche Herausforderungen zu meistern sind, um Projektlösungen zu allgemein nutzbaren Integrationsservices weiterzuentwickeln
- 5 Empfehlungen, wie Sie Integrationslösungen zu Ihrem Vorteil koordinieren
- Welche Chancen aktuelle Integrationslösungen gegenüber Enterprise Service Bus (ESB) bieten
- Warum koordiniertes Test- und Release-Management über den Erfolg entscheidet
Wenn der Entwicklungsaufwand die Leistungsfähigkeit der internen Entwicklung übersteigt
Hinzu kommt, dass der Aufwand zur Entwicklung entsprechender Lösungen die Leistungsfähigkeit eines internen Entwicklungsbereichs in der Regel überfordert. Dieser muss sich schließlich auch um den laufenden Betrieb und die Weiterentwicklung bestehender Lösungen kümmern.
Nach Projektabschluss ändert sich die Situation: Die Entwicklung der potenziell vielen neuen Integrationslösungen ist zunächst beendet. Damit stehen fertig integrierte Systeme zur Verfügung. Auf deren Basis lassen sich auch andere Integrationen entwickeln. Bei einer Nutzung in anderen Kontexten – insbesondere neuen Projekten – sollten diese allerdings weitere, individuelle Projektlösungen vermeiden, denn: Projektlösungen müssen evolutionär zu allgemein nutzbaren Integrationsservices weiterentwickelt werden. Das hört sich einfach an – ist es aber meistens nicht. Hierfür gibt es eine Reihe von Gründen mit sehr unterschiedlichem Charakter. Zwei Beispiele:
Herausforderung 1
Anforderungen entstehen – mit der Zeit
Jede Integrationslösung wird so entwickelt, dass sie die gestellten Anforderungen erfüllt. Diese Anforderungen stammen allerdings aus dem Projekt, in dem die Lösung entwickelt wurde. Meist werden hier jedoch allgemeinere Anforderungen, die eine universelle Nutzbarkeit sicherstellen, nicht berücksichtigt. Das ist normalerweise auch gut so und folgt dem Motto „Setze keine Anforderungen um, die nicht gestellt wurden!“. Hier im ersten Entwicklungsschritt schon zu viel zu wollen, erhöht das Projektrisiko signifikant. Und das hat häufig auch inhaltlich nicht den gewünschten Erfolg. Anforderungen müssen immer einen konkreten Bedarf decken.
Ein Beispiel: Wer eine neue Bestandsverwaltung einführt, benötigt auch eine Integration zu einem Output-Management-System. Dabei ist es sehr wahrscheinlich, dass auch andere Systeme früher oder später eine solche Integration brauchen und dann andere und/oder zusätzliche Anforderungen haben werden. Das ist völlig normal. Notwendig sind also eine Analyse und die Weiterentwicklung des bestehenden Integrationsservices. Ziel ist es, schrittweise eine allgemeine Verwendbarkeit zu erreichen – so wie es das Prinzip der agilen Software-Entwicklung auch vorsieht.
Herausforderung 2
Testumgebungen sind endliche Ressourcen
Die Entwicklung und der Test von Integrationslösungen sind aus Infrastruktur-Sicht alles andere als trivial. Hierfür benötigen Sie unterschiedliche Entwicklungs- und insbesondere Testumgebungen. Diese wiederum müssen mit den Umgebungen der anzubindenden Kernsysteme oder Umsysteme integriert werden.
In der Praxis treten hier oft größere Probleme auf: Gerade Umgebungen für (alte) Umsysteme sind Mangelware. Sie lassen sich nicht für jedes Projekt im gewünschten Umfang bereitstellen. Testumgebungen müssen daher häufig gemeinsame Nutzungen von mehreren Projekten (vor allem auch Wartungsprojekten) erlauben. Allerdings darf kein Chaos aufkommen – weder bei den zu testenden Releases verschiedenster Lösungen unterschiedlicher Projekte noch bei den hierfür benötigten Testdaten.
Warum ist das „auf einmal“ ein so drängendes Problem?
Die Antwort hierauf ist in vielen Fällen tatsächlich relativ einfach: Sie haben es so entschieden! Mit dem Trend zu immer mehr Kauflösungen hat sich vieles sehr grundlegend geändert.
Bisher haben große Organisationen Kernsysteme und auch viele Umsysteme selbst entwickelt. Über Jahre hinweg ist so eine Systemlandschaft mit häufig sehr monolithischen Systemen gewachsen. Diese waren auf natürliche und in der Regel homogene Art und Weise integriert. Der Trend zu Kauflösungen führt jedoch mittlerweile dazu, dass viele Systeme unterschiedlicher Anbieter und Architekturen Integrationslösungen benötigen. Sie müssen diese allerdings nicht nur untereinander, sondern auch in ihre bestehenden Anwendungslandschaften integrieren.
IT-Organisationen wandeln sich zum Systemintegrator
Für die IT-Organisation ergibt sich hieraus ein Wandel ihrer Kernkompetenz vom Lösungsentwickler zum Systemintegrator. Die neuen Kernsysteme und Umsysteme werden von unterschiedlichen Software-Anbietern oder sogar als Software-as-a-Service-Lösungen (SaaS) bereitgestellt. Diese müssen „nur noch“ angepasst, konfiguriert und dann mit allen anderen Systemen – auch den alten Legacy-Systemen – integriert werden.
Bisher stehen immer noch große, monolithische Systeme im Fokus der Integration. Aber auch das wird sich ändern – es ändert sich bereits. Die Systeme werden kleinteiliger, spezialisierter – Microservices etablieren sich zusehends. Auch die Anforderungen durch neue Geschäftsmodelle erfordern hier eine neue Sicht: Unternehmen haben es nicht mehr nur mit ihrer eigenen Anwendungslandschaft zu tun. Auch unternehmensübergreifende Integration wird immer wichtiger.
Daher müssen sich Unternehmen völlig neuen Anforderungen stellen. Früher stand die Implementierung von fachlichen Anforderungen in der eigenen Infrastruktur im Vordergrund. Dabei sind fachlich hervorragende Systeme entstanden. Deren Wartung und Weiterentwicklung wurde aber aufgrund von immer mehr und anspruchsvolleren Anforderungen zu einer kaum noch bewältigbaren Herausforderung.
Wer sich für (Kauf-) Systeme entscheidet, befreit sich aus dieser Zwangslage. Allerdings ist jetzt ein ausgeprägtes Verständnis darüber gefragt, wie die neuen Systeme funktionieren. Denn Unternehmen benötigen dieses Verständnis, um ihre neue Aufgabe lösen zu können: sicherzustellen, dass eine Vielzahl unterschiedlichster Systeme oder sogar externer Services verschiedenster Anbieter in heterogenen Infrastrukturen reibungslos – idealerweise auch automatisiert – miteinander zusammenarbeiten. Immer besser. Dauerhaft.
Integration hört niemals auf
Wie gut Unternehmen dies gelingt, entscheidet darüber, welcher Business Value entsteht. Es reicht nicht mehr aus, die Integration dieser Systeme in diesen selbst zu entwickeln. Die entstehenden individuellen und über die Systeme verteilten Integrationslösungen würden die Komplexität der Gesamtlösung extrem erhöhen. Entsprechend hohe Wartungskosten – aufgrund mangelnder Wartbarkeit und Flexibilität – wären die Folge. Auch organisatorisch wäre dies nicht mehr handhabbar, da eine Vielzahl individueller Lösungen zu Kopfmonopolen führt. Um diesen Risiken zu begegnen, müssen Unternehmen Integrationsaufgaben sowohl technisch wie auch organisatorisch bündeln und koordinieren.
Integration braucht einen Ort: Wie Sie Integrationslösungen gebündelt koordinieren
Um all diesen Risiken zu begegnen, führt kein Weg mehr daran vorbei, Integrationsaufgaben sowohl technisch als auch organisatorisch zu bündeln und zu koordinieren. Fünf Empfehlungen:
1 Organisieren Sie Integrations-Infrastruktur zentral
Etablieren Sie eine Linienorganisation für das zentrale Management aller für die Integrationen notwendigen Ressourcen. Diese Einheit ist Dienstleister für alle Projekte und Systeme mit Integrationsanforderungen. Die Ressourcen umfassen Entwicklungsumgebungen, Testumgebungen für Entwicklung, Integrationstest und Abnahme sowie entsprechende Produktionsumgebungen. Außerdem müssen IT-Organisationen gewährleisten, dass automatisierte Prozesse zur Versorgung dieser Umgebungen über Continuous-Integration-/Continuous-Delivery-Pipelines (CI/CD) vorhanden sind. Ziel ist es, diese Umgebungen mit allen relevanten Umsystemen (von der Entwicklung bis hin zur Produktion) zu integrieren. Wichtig: Koordinieren Sie die Nutzung dieser Ökosysteme für alle Projekte und Systeme zentral, und stimmen Sie sich mit dem Test- und Release-Management dieser Projekte ab.
2 Etablieren Sie eine standardisierte (Cloud-) Infrastruktur für Integrationslösungen
Neue Projekte sollten ihre Integrationslösungen von vornherein direkt in einer standardisierten Infrastruktur entwickeln. Eine Cloud-Infrastruktur ist hierbei ideal; sie stellt neuen Projekten schnell die notwendigen Ressourcen bereit. IT-Organisationen, die eine Cloud-Infrastruktur aufbauen bzw. nutzen, werden handlungsfähiger. Tritt beispielsweise ein Problem auf, lässt sich eine Umgebung auch in kürzester Zeit wiederherstellen. Konflikte zwischen den Projekten lassen sich vermeiden, damit einhergehende Mitarbeiterkapazitäten (für die Bereitstellung von Umgebungen) schonen und unnötige Priorisierungsdiskussionen vermeiden.
3 Etablieren Sie eine standardisierte Integrationsarchitektur
Was für die Gestaltung von Landschaften gilt, hat auch für das Architekturdesign von Software-Systemen eine wichtige Bedeutung. Anwendungslandschaften und deren Integrationslösungen müssen ebenso nachhaltig gewartet und weiterentwickelt werden. Hierfür brauchen Sie eine standardisierte Integrationsarchitektur. Deren wichtigstes Prinzip besteht darin, dass Sie Ihre (neuen) Software-Systeme möglichst frei von Integrationslogik halten. Integrationslogik – und damit das Wissen aus anderen Systemen – gehört dort nicht hinein. Enge Kopplung und Kopfmonopole wären die Folge.
Stattdessen benötigen IT-Organisationen Integrationslösungen, die zwischen den zu integrierenden Systemen vermitteln – eigenständig. Enterprise Service Bus (ESB) sind in der Vergangenheit genau zu diesem Zweck entstanden und zum Einsatz gekommen. Allerdings stoßen auch ESB an ihre Grenzen. Daher müssen Sie für Ihre Organisation bewerten, ob diese „Integrationsmonolithen“ mit einer zentralen Infrastruktur, den hohen Abhängigkeiten von der Lösung und dem Lösungsanbieter sowie einer prinzipbedingt eingeschränkten Flexibilität der richtige Ansatz für Sie sind.
Aktuelle Integrationslösungen bieten Vorteile gegenüber Enterprise Service Bus
Moderne Integrationslösungen sorgen für deutlich mehr Spielraum bei der Entwicklung: Sie machen Unternehmen nicht von einem einzigen zentralen Integrationssystem abhängig. Sonst stoßen sie schnell an Grenzen, wenn bei der Gestaltung neuer Zusammenarbeits- oder Geschäftsmodelle ganz neue Integrationsanforderungen entstehen.
Wir empfehlen daher Integrationslösungen grundsätzlich als Microservices zu entwickeln. Denn sie sind vom Charakter her genau das: eigenständige Lösungen mit einer klar umrissenen Aufgabe. Cloud Native. Als Basis stehen hierfür Open Source Lösungen wie beispielsweise das Integration Framework Apache Camel und Spring Boot zur Verfügung. Diese verwenden wir auch in der IKOR-eigenen System Integration Platform – der SIP.
4 Bauen Sie ein Management für Integrationslösungen auf
Die Building Blocks der Integrationsarchitektur führen zu einer Gliederung in zwei Themenkomplexe: Management und Support für die Integrationsplattform sowie Management der einzelnen Integrationslösungen. Hierfür kann es durchaus sinnvoll sein, eine hybride Organisation aufzubauen. Beim Management und Support für die Integrationsplattform geht es darum, alle Integrationsentwicklungen zentral zu unterstützen. Dies umfasst Standardlösungen, Frameworks, Tooling, Prozesse für Continuous Integration und Continuous Delivery (CI/CD) sowie ein entsprechendes Beratungsangebot.
Das Management der einzelnen Integrationslösungen hingegen hat einen völlig anderen Charakter. Hier geht es um konkrete fachliche Lösungen wie der Integration eines Output-Management-Systems. Daher kann die Verantwortung für die Wartung und Weiterentwicklung auf inhaltlich spezialisierte Integrations-Teams verteilt werden. Diese sind dann gefragt, wenn ein neues Projekt Integrationsanforderungen zu dem jeweiligen Thema hat. Und eben auch dafür verantwortlich, dass mit der Zeit einheitliche Integrationsservices entstehen. Zentrale Integrationsplattformen wie ein ESB führen dagegen auch organisatorisch zu einer zentralen Verantwortung der einzelnen Integrationen. In Kombination mit den damit entstehenden Kopfmonopolen entsteht ein Single-Point-of-Failure – technisch wie organisatorisch.
„Denke beim Gestalten immer auch an das Erhalten“
Hansjörg Spielmann, Bergführer und Hotelier
5 Koordinieren Sie das Test- und Release-Management
Last but not least: Der Test in gemeinsam genutzten Umgebungen kann zu erheblichen Verwerfungen in den betroffenen Projekten führen. Allerdings ist es nicht praktikabel, nur ein einziges Test- und Release-Management für alle Projekte zu betreiben. Sorgen Sie deshalb dafür, dass das Test- und Release-Management aller Projekte ineinandergreift und koordiniert wird. Dies kann, muss aber nicht zentral geschehen. Ein Beispiel: Zwei Projekte führen zwei unterschiedliche neue Systeme ein. Diese müssen mit dem gleichen Umsystem integriert werden. Im Test kann es leicht vorkommen, dass beim ersten Projekt (zeitweise) mit einem anderen Release des Umsystems getestet werden muss wie bei dem anderen Projekt. Griffe jedes Projekt auf eine andere Testumgebung des Umsystems zu, wäre das unproblematisch. Aber gerade bei alten Host-Systemen ist das häufig nicht der Fall. Genauso verhält es sich mit den Testdaten: Beide Projekte haben hier andere Testdaten-Konstellationen. Die getesteten Systeme dürfen die jeweils anderen Testdaten beim Test nicht gegenseitig zerstören.
– Rückblick
Blick auf den ersten Teil
Was dies genau bedeutet, skizzieren wir im zweiten Teil dieser Serie – „Integration hört niemals auf – Herausforderungen und Lösungsansätze“. Hier geht es um Potenziale, Lösungsansätze und Weiterentwicklungen, wenn bereits integrierte Systeme sich zu allgemein verfügbaren Integrations-Services wandeln müssen.
Ansprechpartner
„Für neue, nutzbare Potenziale bedarf es neuer Lösungsansätze und der Weiterentwicklung“
