- SYSTEMINTEGRATION
Warum viele Integrationsprojekte scheitern – und 10 Tipps für ein positives Ergebnis
Wie Systemintegration zum Erfolg wird – Teil 1/2
- •
- Hans-Jürgen von Henning
– ABSTRACT
Integration ist vielschichtig und komplex
Dennoch wird Integration in fast allen Projekten – zumindest zu Beginn – als Disziplin unterschätzt. Die Ursachen, warum Integrationsprojekte scheitern oder regelmäßig in massive Schwierigkeiten geraten, sind vielfältig. Die gute Nachricht lautet jedoch: Wer die folgenden zehn Handlungsempfehlungen beherzigt, bereitet sich auf einen Erfolg versprechenden Integrationskurs vor.
10 Tipps für ein positives Ergebnis
Tipp 1:
Ermitteln Sie für die Planung alle relevanten Informationen zu den beteiligten Systemen
Ein Integrationsprojekt muss – in den meisten Fällen neben dem neu einzuführenden (Kern-) System – viele weitere Systeme aus der bestehenden Anwendungslandschaft eines Unternehmens berücksichtigen. Dabei weist jedes dieser Systeme seine ganz eigenen, vor allem aber sehr unterschiedlichen Charakteristika auf: Zum einen kommen oft Eigenentwicklungen, Standardprodukte oder sogenannte Customized Assets, eine Art Zwischenwelt, zum Tragen. Dem nicht genug „sprechen“ diese Systeme unterschiedliche Sprachen (wie Java, Cobol oder PL/I) in unterschiedlichen Formaten und Dialekten (wie UTF-8 oder EBCDIC). Oft findet der Betrieb dieser Systeme auf unterschiedlichen und meist zahlreichen Plattformen statt: Darunter fallen Host-Systeme mit verschiedenen Betriebssystemen und Transaktionsmonitoren. Aber natürlich werden auch Server mit unterschiedlichen Betriebssystemen (wie Linux oder Windows) eingesetzt. Ebenso wie Cloud-Umgebungen mit verschiedenartigen technologischen Stacks. Zum anderen verantworten meist unterschiedliche Betreiber Entwicklung und Operating. Gerade dies hat aber erheblichen Einfluss darauf, wie gut ein Integrationsprojekt vorankommt – hinsichtlich der eigenen IT, hinsichtlich Dienstleistungen des internen oder externen Rechenzentrums, hinsichtlich Cloud-Plattformen – und Mischformen.
Hinterfragen Sie außerdem die Ausgangslage genau:
- Lifecycle: Wollen oder müssen Sie das System noch länger betreiben? Wenn ja: wie lang? Und: Wie lange können Sie es noch betreiben? Fallen zum Beispiel Komponenten in absehbarer Zeit aus der Wartung – oder ist dies sogar bereits geschehen?
- Wartbarkeit: Ist das System einfach erweiterbar oder veränderbar?
- Skills: Wie viele Mitarbeiter:innen kennen (noch) das aktuelle System? Und wenn ja – handelt es sich hier um Experten-Skills? Oder können diese Mitarbeiter:innen lediglich Wartungsarbeiten übernehmen?
- Ressourcen: Verfügen Sie über genügend Kapazitäten – abseits des Personaleinsatzes, der den laufenden Betrieb aufrechterhält? Last, but not least: Wie gestaltet sich die demografische Situation? Über welchen Zeitraum werden die vorhandenen Skills noch verfügbar sein? Wie lang lässt sich eine Fluktuation kompensieren?
Zugegeben: Diese Ausgangssituation ist komplex. Daher ist es umso wichtiger, sich einen validen Überblick über die Anwendungslandschaft zu verschaffen. Am einfachsten überblicken Sie die Situation, wenn sich die Systeme im Monitoring Ihres Enterprise Architecture Management (EAM) befinden. Damit sollten Sie nicht nur Ihre Ausgangslage bewerten, sondern auch die Frage beantworten können, welche Systeme der Zielarchitektur Ihrer Bebauungsplanung entsprechen. Oder zumindest einer der Zwischenstufen auf dem Weg dahin. Die Eigenschaften der beteiligten Systeme sowie deren Rolle innerhalb der Bebauungsplanung sind jedoch häufig nicht klar definiert bzw. nicht transparent ausgewiesen. Dies führt einerseits dazu, dass die vielfältigen Fragestellungen, die es zur Planung eines Integrationsprojekts braucht, häufig nur ansatzweise berücksichtigt werden. Die daraus im Projektverlauf entstehenden Probleme ziehen allerdings häufig keine neue Planung nach sich. Die unzureichende Begründung: Es sei ja „nur“ etwas schwieriger als gedacht. Ein vermeintlich pragmatischer Ansatz greift aber dann leider doch meist zu kurz.
Tipp 2:
Richten Sie Ihren Blick nicht allein auf das neue System
Das Hauptinteresse der meisten Unternehmen liegt bei Projekten auf dem (neu) einzuführenden System – zumindest zunächst: Entscheider:innen haben Umsetzungsentscheidungen getroffen und erhoffen sich von dem neuen System viele Vorteile. Die Integration des Systems in die Anwendungslandschaft hat für viele Firmen eher den Charakter eines lästigen Übels – scheinbar ohne weitere Vorteile. Schließlich ergeben sich hieraus grundsätzlich zunächst keine Vorteile – wenn nicht sogar Nachteile – im Vergleich zum vorherigen Zustand.
Tipp 3:
Konzentrieren Sie die Integrationskompetenz an einer Stelle
Reduzieren Sie die Integrationslogik innerhalb der zu integrierenden Systeme. Diese gehört grundsätzlich weder in das zu integrierende noch in das integrierte System. Vielmehr handelt es sich um eine Eigenschaft der Integrationsbeziehung. Andernfalls würde Wissen aus den beteiligten Systemen in das jeweils andere System integriert. Das ist sicher nicht das, was eine lose Kopplung ausmacht. Denn schnell entstehen vielfältige Abhängigkeiten bei Analyse, Entwicklung, Test sowie Release- und Umgebungs-Management. In der Folge sind Verzögerungen und weitere Probleme geradezu vorprogrammiert.
Das Fatale einer nicht-zentralisierten Systemintegrations-Logik liegt darin, dass die Verantwortung für eine Integration auf zwei Seiten verteilt wird. Die ungesteuerte, individuelle Umsetzung von Integrationen führt zum einen zu kurzfristigen Problemen. Sie sorgt zum anderen aber auch nachhaltig für gravierende Nachteile: insbesondere mit erhöhten Fehlerquoten, Betriebsproblemen und einer mangelnden Wartbarkeit. Verantwortlich hierfür sind nicht zuletzt die aus individuellen Umsetzungen entstandene Kopfmonopole. Besser ist es daher, die Integrationslogik an einem Ort zu zentralisieren.
Nur ein interdisziplinäres und systemübergreifend handelndes Integrations-Team kann eine einheitliche Integrationsarchitektur vorantreiben. Damit entsteht die Basis für:
- einen sinnvollen Betrieb,
- die kontinuierliche Weiterentwicklung der Schnittstellen-Landschaft (siehe auch Teil 2 dieser Serie: „Integration hört niemals auf“) und
- Wartbarkeit: Zum Ende eines Projekts benötigen diese meist nur noch wenige Ressourcen. Fehlt eine einheitliche Integrationsarchitektur, kommt es im Test und bei der Stabilisierung zu Problemen, da nicht mehr alle Projektexpert:innen ad hoc verfügbar sind.
Fazit: Integration braucht einen Ort, damit diese Probleme erst gar nicht entstehen. Stattdessen zielt das Integrationsprojekt auf eine leistungsfähige, zuverlässige und wartbare Integrationsarchitektur. Dann gelten für alle Integrationen die gleichen Regeln – und diese sind damit auch für alle verständlich.
Tipp 4:
Sorgen Sie in Ihrem Projekt für ein hohes Maß an Integrations-Mindset
Die Annahme, dass durch die Integrations-Features des neuen Systems „mal eben“ ein paar Schnittstellen aufgerufen werden müssen und diese „einfach“ zu versorgen sind, ist leider immer noch weit verbreitet und fast immer falsch. Die Vorstellung, dass das gleiche fachliche Problem in unterschiedlichen Systemen ähnlich behandelt wird, hält dem Realitäts-Check oft nicht stand.
Vielmehr führen Systeme (vermeintlich) gleiche Inhalte oftmals redundant – teilweise aber mit stark abweichender Bedeutung. In der Folge ergeben sich anspruchsvolle Analyse- und Umsetzungsanforderungen, denn: Integration ist vielschichtig und komplex.
Tipp 5:
Sichern Sie die Startvoraussetzungen für das Integrationsprojekt ab
Ein neues System entsteht (im schlimmsten Fall auch für die Unternehmens-IT) in einer neuen Umgebung. Eine Integrationsentwicklung lässt sich dann oft erst verzögert starten. Häufig fehlen nämlich für die Integration der alten, anzuschließenden Systeme die technischen Integrationsmöglichkeiten. Die Umgebungen stehen also „nur“ nebeneinander. Die Integrationsfähigkeit – der häufig sehr unterschiedlichen Umgebungen – sicherzustellen, ist allerdings alles andere als trivial. Doch erst die Integrationsfähigkeit der Umgebungen schafft die Grundlage dafür, dass sich auch die Systeme integrieren lassen.
Häufig sind auch die Anforderungen an die benötigten Umgebungen zu Beginn eines Integrationsprojekts nicht ausreichend definiert. Und selbst wenn, priorisieren Unternehmen sie oft niedrig. Schließlich geht es ihnen meist primär um das neue (Kern-) System und nicht um dessen Integration. Unternehmen unterschätzen dabei häufig, dass bei einer Integration sehr komplexe Anforderungen umzusetzen sind. Dafür müssen mindestens drei Teststufen einen End-to-End-Test der Integrationen unterstützen.
Die Voraussetzung: Alle Testumgebungen des neuen (Kern-) Systems müssen mit den Testumgebungen aller Umsysteme integriert werden – umgesetzt mit konsistenten Testdaten und passenden Release-Ständen. Allerdings müssen sich die aktuellen Umsysteme hierzu parallel auch weiterentwickeln und testen lassen. Die Entwicklung und der Integrations-Entwicklertest benötigen schließlich auch noch eigene integrierte Umgebungen.
Tipp 6:
Erkennen Sie die Komplexität und die Auswirkungen von Querschnittsthemen an
Zu den eigentlichen fachlichen Integrationen gesellt sich eine Vielzahl weiterer Handlungsfelder wie Security, Monitoring, Logging sowie User- und Rechte-Verwaltung. Hier sind Timing und Planung gefragt: Viele grundlegende Fragestellungen müssen schon frühzeitig geklärt sein. Ansonsten drohen den einzelnen Integrationsumsetzungen oft (viel zu) spät weitreichende Änderungen. Wer es jeder einzelnen Integration überlässt, übergreifende Aspekte umzusetzen, erhält eine Vielzahl individueller Lösungen – und damit keine einheitliche Integrationsarchitektur, die diesen Namen auch verdient.
Viele individuelle Lösungen würden dann spätestens beim Test, bei der Fehleranalyse und der Fehlerbehebung zu massiven Verzögerungen führen. Grundsätzlich gehen alle Querschnittsthemen über den Fokus eines Projekts hinaus. Diese Fragestellungen zu klären, ist daher alles andere als einfach, weil Änderungen hier sogar zu zentralen Risiken führen können.
Tipp 7:
Gehen Sie agil vor, um Integrationen früh testen zu können
Gerade ein Integrationsprojekt ist für ein agiles Vorgehen geeignet. Wichtig ist hierbei, in konkreten Umsetzungsschritten früh lauffähige Integrationslösungen zu entwickeln. Hilfreich dabei ist ein Mocking, welches die zu integrierenden Systeme simuliert. Der positive Effekt: Mocking führt dazu, dass Änderungen auf der einen oder anderen Seite die Entwicklung der Integrationslösungen nicht ständig behindern. Hierdurch wird das Release-Management massiv entlastet. Schließlich ist im Test dann die Kompatibilität der beteiligten Systeme (oder ersatzweise deren Mocks) besser zu gewährleisten. Hierdurch steht netto wesentlich mehr Zeit für Tests zur Verfügung.
Tipp 8:
Gestalten Sie die Zyklen für agile Timeboxes („Sprints“) nicht zu kurz
Bei einer Integrationsentwicklung sind grundsätzlich viele unterschiedliche Ursachen für Verzögerungen zu berücksichtigen – etwa fachliche Rückfragen und Infrastrukturprobleme, um nur die Wichtigsten zu nennen. Genau diese Aspekte verzögern den Projektfortschritt immer wieder. Zwei-Wochen-Sprints sind – je nach Rahmenbedingungen – häufig zu eng getaktet. Dem gegenüber lassen sich mit Drei-Wochen-Sprints meist bessere Ergebnisse erzielen. Zumindest sollte ein „nicht-agiler“ organisatorischer Overhead („Wasserfall Mix-in“) so gering wie möglich ausfallen, damit er nicht zu zusätzlichen Belastungen und zu sinkenden Nettozeiten für die eigentliche Entwicklungsarbeit führt.
Tipp 9:
Testen Sie die Integration explizit
Der Test von Integrationslösungen wird im Kontext der fachlichen Systeme leider häufig nur „mitgemacht“. Auf organisatorischer Ebene sorgt dies jedoch für eine extrem enge Kopplung – genau das, was auf technischer Ebene nicht stattfinden sollte. Integrationsfehler lassen sich nur entdecken, wenn auch entsprechende Testfälle durchgeführt werden. Formuliert man diese Testfälle nur aus Sicht der fachlichen Systeme, werden viele Fehler erst sehr spät entdeckt. Dies sorgt für ein erhebliches Produktionsrisiko, denn: Die Testabdeckung für die Integrationslösungen ist oft viel zu niedrig angesetzt. Im Besonderen gilt dies für Last- und Performance-Tests. Um die Infrastrukturgrenzen gezielt zu analysieren, ist für diese Tests ein isolierter Integrationstest zwingend erforderlich.
Tipp 10:
Denken Sie früher an später
Sobald Sie die Einführung eines neuen (Kern-) Systems abgeschlossen haben, geht dieses für die Wartung und die Weiterentwicklung in einen Regelbetrieb über. Aber was geschieht mit den Ergebnissen der Integrationsprojekte? Diese sollten idealerweise auch in anderen Kontexten wiederverwendet und weiterentwickelt werden. Integrationen haben schließlich von ihrer Natur her grundsätzlich einen ganz eigenständigen Charakter und sind nicht an das Projekt gebunden, in dem sie ursprünglich entstanden sind. In Zeiten zunehmender Service-Orientierung entstehen durch sie vielmehr ganz neue Potenziale in der Anwendungslandschaft. Ein „Rollenwechsel“ hin zu allgemein verfügbaren Integrations-Services ist allerdings häufig kein Gegenstand der Einführungs- und Übergabeplanung. Um aber die neuen Potenziale nutzen zu können, bedarf es auch neuer Lösungsansätze und einer gezielten, koordinierten Weiterentwicklung.
– AUSBLICK
Ausblick auf die zweite Folge
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“