Jedes Integrationsprojekt im Unternehmen hat ein Scope-Dokument. Fast keines davon erfasst den Teil, der am längsten dauert: das laufende Management der Integrationen.
Der verbreitete Fehler besteht darin, Integrationen als Projekte zu behandeln. Software-Integrationsmanagement ist die Arbeit, die am Tag nach dem Go-live einer Integration beginnt und so lange andauert, wie die Integration existiert: sie beobachten, sie ändern, sie dokumentieren und für sie geradestehen. Es ist eine eigene Disziplin mit echten Kosten, und in den meisten Unternehmen hat sie weder eine Budgetzeile noch einen Verantwortlichen.
Kernaussagen
- Software-Integrationsmanagement ist der laufende Betrieb einer Integrationslandschaft, nicht die Lieferung von Integrationen. Die Lieferung endet. Das Management nicht.
- Die Arbeit gliedert sich in acht Tätigkeiten. Eine Plattform unterstützt vier davon und übernimmt keine einzige.
- Tools und Managed Services sind keine konkurrierenden Produkte. Sie besetzen dieselben acht Tätigkeiten unterschiedlich, und die Verantwortungstabelle weiter unten ist der ehrliche Vergleich.
- Die entscheidende Variable ist selten die Funktionalität. Entscheidend ist, wer antwortet, wenn ein Datenfluss an der Grenze zwischen zwei Organisationen ausfällt, und ob diese Antwort in einem Vertrag steht.
- Tools sind die richtige Wahl, wenn ein Unternehmen Integrationskompetenz aufbauen und behalten will. Ein Managed Service ist die richtige Wahl, wenn sie Overhead ist.
Die Referenz für diese Arbeit. Das Integration-Ops-Buch beschreibt, wie Integrationsarbeit in einem Managed Integration Service operationalisiert, gemessen und skaliert wird. Buch herunterladen.
Was ist Software-Integrationsmanagement?
Software-Integrationsmanagement ist die koordinierte Planung, Verbindung und der laufende Betrieb der Softwaresysteme eines Unternehmens, damit sie dauerhaft zuverlässig Daten austauschen. Planung und Verbindung sind endlich. Der laufende Betrieb ist es nicht. Er umfasst das Monitoring der Integrationen, die Reaktion bei Ausfällen, ihre Anpassung, wenn sich verbundene Systeme ändern, die Kontrolle darüber, wer sie ändern darf, die Pflege von Dokumentation und Zuständigkeiten sowie die Berichterstattung darüber, ob sie noch leisten, was das Unternehmen braucht.
Die meisten veröffentlichten Leitfäden zu diesem Begriff behandeln Scope-Definition, Architekturwahl und Verbindungsarten und hören dort auf, wo die Integration live geht. Die Entscheidung, die über die Kosten bestimmt, liegt hinter dieser Linie.
Die grundlegenden Konzepte erläutern wir unter was Softwareintegration ist.
Das Integration-Ops-Buch formuliert die Haltung hinter dieser Sicht. Integration ist ein Lebenszyklus, keine Aufgabe, und das Management ist der Teil dieses Lebenszyklus, den niemand einplant, weil er kein Lieferdatum hat.
Das Buch unterscheidet drei Denkweisen, und die Lücke zwischen zwei davon ist der Ort dieser Entscheidung. Eine Projektdenkweise baut etwas einmal und misst Erfolg an der Lieferung. Eine Produktdenkweise übernimmt dauerhaft Verantwortung und fragt, ob das Ergebnis noch das richtige Problem löst. Eine Servicedenkweise behandelt Integrationen als kontinuierliche Lieferung von Ergebnissen, gemessen an Zuverlässigkeit, Transparenz und Anpassungsfähigkeit des Datenflusses selbst. Das Buch hält auch fest, wo die meisten Teams landen: Sie liefern Integrationen, als wären es Projekte, werden aber verantwortlich gemacht, als wären es Services.
Acht Kernbestandteile des Integrationsmanagements
Die beiden Ressourcenmodelle unterscheiden sich darin, wer jede dieser Tätigkeiten ausführt. Das Integration-Ops-Buch macht denselben Punkt aus der anderen Richtung. Die Verbindung läuft von selbst, die Arbeit drumherum nicht. Notieren Sie beim Lesen, wer in Ihrem Unternehmen jede Tätigkeit ausführt.
1. Monitoring und Erkennung. Wissen, dass ein Datenfluss stillsteht, sich verschlechtert oder falsche Daten liefert, bevor das Business es Ihnen mitteilt.
2. Incident Response und Wiederherstellung. Den Datenfluss wiederherstellen und anschließend abgleichen, was sich während des Ausfalls angestaut hat oder verloren gegangen ist. Die Wiederherstellung dauert regelmäßig länger als die Behebung.
3. Änderungen auffangen. Integrationen anpassen, wenn ein verbundenes System aktualisiert wird, eine API abgekündigt wird, ein Schema ein Feld hinzubekommt, ein Zertifikat abläuft oder ein Partner seine Plattform wechselt.
4. Onboarding. Einen neuen Kunden, Lieferanten oder ein neues System in planbarem Tempo anbinden, ohne jedes Mal eine Einzelentwicklung.
5. Tests und Validierung. Vertragstests, die prüfen, ob sich jede Seite noch wie erwartet verhält, und Regressionstests, die laufen, bevor eine Änderung in Produktion geht. Das Integration-Ops-Buch nennt dies als eine der wiederkehrenden Tätigkeiten, die es wert sind, einmal gestaltet und dann automatisiert zu werden, neben Onboarding, Monitoring und Dokumentation. In den meisten Landschaften ist es die Tätigkeit, die am wenigsten konsequent ausgeführt wird und deren Ausbleiben am teuersten ist, weil eine ungetestete Änderung vom Business entdeckt wird.
6. Versions- und Zugriffskontrolle. Wissen, welche Version einer Schnittstelle live ist, wer sie ändern darf und wie der Rollback-Pfad aussieht. Das Buch ist hier deutlich. Datenflüsse, Mappings und Konfigurationen sollten versioniert werden, damit alte und neue Varianten während einer Umstellung parallel laufen können und Teams schnell zurückrollen können.
7. Dokumentation und Zuständigkeit. Datenmappings und Schnittstellenverträge aktuell halten, mit einem namentlich benannten Verantwortlichen, damit die Änderung einer Integration nicht mit einer Untersuchung beginnt.
8. Geschäftliche Ausrichtung. Regelmäßig prüfen, ob das, was die Integrationen tun, noch dem entspricht, was das Unternehmen braucht, und diejenigen stilllegen, bei denen das nicht mehr der Fall ist. Das ist eine der drei Messdimensionen des Buchs. Die anderen beiden sind Lebenszykluseffizienz und operativer Zustand, und die geschäftliche Ausrichtung ist diejenige, die die Leistung der Integrationen mit Service-Zusagen, Onboarding-Geschwindigkeit und Kundenabwanderung verbindet.
Zwei Wege, das Integrationsmanagement zu besetzen
Die Wahl wird meist als selbst bauen oder kaufen dargestellt, und das verdeckt sie. Beide Optionen bedeuten, etwas zu kaufen. Der Unterschied liegt darin, welche der acht Tätigkeiten Sie einkaufen und welche Sie behalten.
Die Tool-Seite dieses Markts wird meist in Produktkategorien beschrieben: Integration Platforms as a Service, API-Management-Plattformen, Enterprise Service Buses und Embedded iPaaS, das in ein Produkt eingebaut ist. Diese Kategorien beschreiben, was Sie kaufen können. Keine davon beschreibt, wer die acht Tätigkeiten ausführt, sobald das System läuft.
Der Vergleich hier stellt zwei Betriebsmodelle gegenüber statt Anbieter, weil der Produktvergleich bereits existiert. Die wichtigsten ITSM-Integrationstools vergleicht native Connectoren, Sync-Engines, universelle iPaaS-Lösungen und Managed Services direkt miteinander, und unser Vergleich von über 45 Integrationsplattformen deckt den breiteren Markt ab. Nutzen Sie diese Artikel, um ein Produkt auszuwählen. Nutzen Sie diesen, um zu entscheiden, wer es betreibt.
Was eine Plattform für das Managementproblem tatsächlich leistet
Eine Integrationsplattform verbessert Tätigkeit 1 deutlich, stellt Mechanismen für die Tätigkeiten 5 und 6 bereit und verringert den Aufwand für die Tätigkeiten 3 und 4, weil sich Änderungen und Onboarding schneller umsetzen lassen. Ausführen kann sie keine davon. Ein Monitoring-Dashboard zeigt Ihnen, dass ein Datenfluss stillsteht. Jemand muss trotzdem hinschauen, entscheiden, dass es relevant ist, und handeln. Eine schnellere Umsetzung von Änderungen ist wertvoll, beantwortet aber nicht, wer bemerkt, dass eine Änderung nötig ist, wer den Kontext hat, sie umzusetzen, und wer an einem Montag um 09:00 Uhr verfügbar ist.
Die Tätigkeiten 2, 7 und 8 bleiben von der Plattformwahl im Wesentlichen unberührt. Sie sind operativ und organisatorisch, und genau dort liegen die Kosten. Das Integration-Ops-Buch formuliert den Unterschied klar.
„Skripte können Aufgaben automatisieren. Eine Plattform automatisiert, wie Aufgaben erledigt werden, wiederholt und einheitlich, über viele Integrationen und viele Teams hinweg.“ -- Integration Ops, Kapitel 5
Keines von beiden automatisiert die Entscheidung zu handeln, und diese Entscheidung ist die eigentliche Aufgabe. Das Buch benennt die Grenze deutlich. Tools allein garantieren keine Stabilität. Fehlt einem Unternehmen ein Betriebsmodell dafür, wie Integrationen verantwortet, überwacht, gewartet und betrieben werden, bleibt das Risiko bestehen. Die Tools ändern sich, die Verhaltensweisen nicht. Technologie macht Integrationsarbeit schneller und flexibler. Für sich allein kann sie sie nicht verantwortbar, beobachtbar oder nachhaltig machen.
Das ist kein Argument gegen Plattformen. Es ist ein Argument gegen die Annahme, mit dem Kauf einer Plattform sei die Managementfrage gelöst. Eine Plattform kann Ihnen jeder verkaufen und das Ergebnis Ihnen überlassen.
Was zum Anbieter wandert und was bleibt
Ein Managed Integration Service übernimmt die Tätigkeiten 1 bis 7 und teilt sich Tätigkeit 8 mit Ihnen. Der Anbieter betreibt die Plattform, überwacht die Landschaft, reagiert nach Service Level, fängt Änderungen der verbundenen Systeme auf, bindet neue Parteien an und pflegt Dokumentation und Zuständigkeiten.
Bei Ihnen bleibt der Teil, der bei Ihnen bleiben sollte. Sie entscheiden, was das Unternehmen integriert braucht, Sie verantworten die Beziehungen zu den angebundenen Parteien, und Sie halten den Anbieter an das Service Level.
Die kommerzielle Form folgt derselben Logik. Sie kaufen ein Abonnement gegen ein Ergebnis, bepreist im Verhältnis zu Plattformgebühren plus Personal, die es ersetzt.
Die Verantwortungstabelle
Der nützlichste Vergleich in dieser Kategorie ist keine Funktionsmatrix. Es ist die Frage, wer für jede Tätigkeit geradesteht und ob diese Verantwortung vertraglich festgelegt ist.
Der Kostenvergleich, auf den es ankommt
Ein Plattformabonnement mit einem Service-Abonnement zu vergleichen ist der falsche Vergleich, und es ist derjenige, den die meisten Business Cases anstellen. Der richtige Vergleich stellt die Plattformgebühren plus die Vollkosten der internen Kapazität, die für die Tätigkeiten 1 bis 7 nötig ist, dem Abonnement gegenüber. Zu diesen internen Kosten gehören die Arbeitszeit fest angestellter Mitarbeiter für Monitoring und Änderungsarbeit, die Rufbereitschaft oder ihr Fehlen und die Geschäftsunterbrechung, die das Unternehmen trägt, wenn eine Integration ausfällt und niemand hingeschaut hat.
Die zweite Hälfte haben die meisten Unternehmen nie berechnet. Deshalb wirkt die Inhouse-Option auf dem Papier zuverlässig günstiger und ist es zuverlässig nicht. Die drei Liefermodelle haben wir in unserem TCO-Vergleich von Integrationslösungen gegeneinander gestellt, die Entscheidung auf der Aufbauseite in Integrationen selbst entwickeln oder kaufen.
Welche Rolle Systemintegratoren spielen
Ein Systemintegrator ist eine dritte Option, die es wert ist, benannt zu werden. Bei ihm landen viele Unternehmen standardmäßig, wenn das interne Team keine Kapazität mehr hat.
Ein SI-Auftrag ist projektförmig. Er reicht von den Anforderungen über die Lieferung bis zur Übergabe, und dann endet er. Diese Form passt zu Programmarbeit, Migrationen und allem, was tatsächlich abgeschlossen wird. Auf das laufende Integrationsmanagement angewendet, erzeugt sie ein bestimmtes Muster. Jede Änderung wird zu einem Statement of Work, die Kosten wachsen mit den Change Requests, und das Wissen sammelt sich beim Integrator.
Systemintegrationsdienste im Vergleich zeigt, wo jedes Modell seinen Platz hat. Viele Unternehmen setzen Systemintegratoren gut ein und sollten das weiter tun. Die Fehlpassung ist eng umrissen und konkret: Man nutzt einen projektförmigen Auftrag, um einen serviceförmigen Bedarf zu decken, und ist dann überrascht, dass sich das kommerzielle Modell gegen kontinuierlichen Wandel sperrt.
Wann selbst betriebene Integrationstools die richtige Antwort sind
Es gibt Szenarien, in denen Sie Ihre Integrationen mit einem Self-Service-Integrationstool verwalten sollten, etwa mit einer iPaaS-Lösung.
Integrationskompetenz ist strategisch. Wenn die Art, wie Sie sich mit Kunden oder Partnern verbinden, Teil dessen ist, was Sie verkaufen, behalten Sie die Kompetenz, kaufen Sie gute Tools und statten Sie das Team angemessen aus.
Die Landschaft ist stabil. Wenige angebundene Parteien, Systeme, die sich nach einem planbaren Zeitplan ändern, und keine organisationsübergreifenden Datenflüsse. Der Managementaufwand ist tatsächlich gering, und mit einem Service würden Sie für Kapazität bezahlen, die Sie nicht brauchen.
Sie haben das Betriebsmodell bereits. Namentlich benannte Integrationsverantwortliche, aktuelle Dokumentation, standardisierte Muster und eine funktionierende Rufbereitschaft. Wenn die Tätigkeiten 1 bis 7 bereits Verantwortliche haben, ist eine Plattform die richtige Investition und ein Service eine Doppelung.
Trifft keiner dieser drei Punkte auf Ihr Unternehmen zu, findet die Managementarbeit trotzdem statt. Sie wird von Menschen aufgefangen, die für etwas anderes eingestellt wurden, und niemand misst sie.
Der Wechsel von einem Modell zum anderen
Unternehmen wechseln selten in einem einzigen Schritt zwischen Integrationstools und Managed Integration Services. Der folgende schrittweise Weg hat sich in der Praxis bewährt.
Phase 1. Bestandsaufnahme. Erfassen Sie jede Integration, ihre angebundenen Parteien, ihren Verantwortlichen und ihre letzte Änderung. Die meisten Unternehmen stellen fest, dass die Liste länger ist als erwartet und die Spalte für Verantwortliche größtenteils leer.
Phase 2. Die lauten zuerst verlagern. Übergeben Sie die Integrationen mit den meisten Incidents und Change Requests an den Service. Dort liegen die Kosten, und dort ist die Entlastung am schnellsten spürbar.
Phase 3. Die grenzüberschreitenden verlagern. Integrationen zu Kunden, Lieferanten und Partnern tragen das Verantwortungsproblem in sich und profitieren am meisten von einer vertraglichen Antwort darauf.
Phase 4. Über den Rest entscheiden. Die umfassendere Version dieser Entscheidung behandeln wir in welche IT-Services ausgelagert werden sollten. Stabile interne Integrationen können durchaus inhouse bleiben. Ziel ist nicht, alles zu verlagern. Ziel ist, nicht länger für die Illusion zu bezahlen, die Landschaft werde gemanagt, obwohl niemand damit beauftragt wurde.
ONEiO betreibt dieses Modell als Managed Integration Service. Wir betreiben Ihre Integrationen, Sie liefern Ihre Services: Die Tätigkeiten 1 bis 7 gehen unter einem Service Level an uns über, die Konnektivität ist any-to-any, sodass eine neue Partei keine neue Entwicklung bedeutet, und das Abonnement bewegt sich nicht, wenn sich Ihre angebundenen Systeme bewegen.
Fazit zu Software-Integrationsmanagement
Integrationsmanagement ist keine optionale Schicht über der Integrationslieferung. Dort spielt sich das eigentliche Leben der Landschaft ab, und es bindet echten Aufwand, ob jemand dafür budgetiert hat oder nicht.
Die Wahl zwischen Tools und einem Managed Service ist keine Frage der Funktionalität. Beide können dieselben Systeme verbinden. Es ist eine Entscheidung darüber, welche der acht Tätigkeiten Ihr Unternehmen selbst verantworten will und für welche jemand vertraglich geradestehen soll.
Treffen Sie diese Entscheidung bewusst. Der Standardfall, in dem das Management informell in den Lücken zwischen anderer Arbeit stattfindet, ist die teuerste Option und die einzige, die nie jemand gewählt hat.
Ordnen Sie die acht Tätigkeiten Ihrer Landschaft zu. Vereinbaren Sie ein 30-minütiges Gespräch, und wir gehen gemeinsam durch, wer heute für jede einzelne verantwortlich ist.
