DevOps-Automatisierung bedeutet in der Regel CI/CD. Innerhalb des Engineering-Teams ist diese Automatisierung ausgereift. Schwierig wird es beim Bindegewebe zwischen Entwicklungs-, ITSM-, Kommunikations- und Security-Tools – genau dort, wo die meisten DevOps-Strategien still und heimlich aufhören zu investieren, und genau dort, wo die tatsächlichen Kosten für den Betrieb einer modernen Software-Delivery-Organisation entstehen.
Dieser Artikel behandelt, was DevOps-Automatisierung über die vier Tool-Kategorien hinweg überbrücken muss, warum iPaaS allein das Problem nicht löst und welcher Wandel im Betriebsmodell dafür sorgt, dass die Geschwindigkeitsgewinne des Engineering-Teams tatsächlich beim Business ankommen. Für die umfassendere ITSM-Integrationsperspektive lesen Sie unseren DevOps-Integrationsleitfaden zur Verbindung von Jira, GitHub, Slack und Ihrem ITSM-System. Für die Azure-DevOps-Spezifika lesen Sie, wie Sie Azure DevOps integrieren.
Die wichtigsten Erkenntnisse
- DevOps-Automatisierung, die an der CI/CD-Pipeline endet, lässt die Geschwindigkeitsgewinne des Engineering-Teams bei den Übergaben an Betrieb, Support und Security auf der Strecke.
- Die vier Tool-Kategorien, die DevOps-Automatisierung überbrücken muss, sind Entwicklung, ITSM, Kommunikation und Security. Jede hat ihre eigene Änderungsfrequenz und ihre eigenen Verantwortlichen.
- iPaaS löst die Ebene der bidirektionalen Synchronisation. Es löst nicht die operative Verantwortung oder die Kostenplanbarkeit – und genau daran scheitern die meisten Unternehmen.
- Ein Managed-Integration-Service betreibt das Bindegewebe über die vier Kategorien hinweg als kontinuierlichen Service, mit planbaren Preisen und operativer Verantwortlichkeit.
Was DevOps-Automatisierung üblicherweise bedeutet – und was sie bedeuten sollte
Wenn die meisten Teams von „DevOps-Automatisierung" sprechen, meinen sie CI/CD. Continuous Integration. Continuous Deployment. Pipeline-as-Code. Vielleicht Infrastructure-as-Code. Das sind reale, wertvolle Disziplinen, und innerhalb des Engineering-Teams sind sie größtenteils gelöst.
Der Bereich, in den die meisten Teams zu wenig investieren, ist die Automatisierung, die rund um die CI/CD-Pipeline existieren muss, damit DevOps als Betriebsmodell funktioniert und nicht nur als Tool-Entscheidung. Wenn ein von Kunden gemeldeter Incident in Zendesk zu einem Jira-Issue, einer Slack-Benachrichtigung, einem Azure-DevOps-Work-Item, einem ServiceNow-Change-Record und einem Status-Page-Update werden muss, dann automatisiert das irgendjemand. Meist mit drei verschiedenen Tools, zusammengehalten von einer Konfiguration, deren Wartung nur zwei Entwickler noch im Kopf haben. Meist ohne jede Überwachung, ob die Kette überhaupt vollständig durchgelaufen ist. Oft ohne jede Eskalation, wenn sie es nicht getan hat.
Diese Übergabeebene ist der Ort, an dem DevOps-Automatisierung entweder geschäftlichen Mehrwert liefert oder still und heimlich scheitert. Sie ist das Bindegewebe zwischen dem Engineering-Team und dem Rest der Organisation.
Die vier Tool-Kategorien, die DevOps-Automatisierung überbrücken muss
Eine funktionierende DevOps-Automatisierungsstrategie überbrückt vier Tool-Kategorien. Die meisten Strategien behandeln eine davon als primär und die anderen drei als Integrationsprobleme, um die sich jemand anderes kümmern soll.
1. Entwicklung und Versionsverwaltung
Azure DevOps, GitHub, GitLab, Bitbucket. Die CI/CD-Pipelines, der Pull-Request-Flow, die Artefakt-Registry. Hier konzentriert sich historisch der Großteil des DevOps-Automatisierungsaufwands, und dieser Bereich ist vergleichsweise ausgereift.
Speziell für Azure DevOps behandelt unser Azure-DevOps-Integrationsleitfaden die API-Muster, die Marketplace-Optionen und das Setup der bidirektionalen Synchronisation im Detail.
2. ITSM und Betrieb
ServiceNow, Jira Service Management, Zendesk, Freshservice, BMC Helix. Das Incident-Management-System. Das Change Advisory Board. Der kundenseitige Service Desk. Hier muss die Arbeit des Engineering-Teams für Betrieb, Support und das Business sichtbar werden.
Unser DevOps-Integrationsleitfaden behandelt die Verbindung von Jira, GitHub, Slack und Ihrem ITSM-System als vernetzte Ebene. Für den Fall Jira-zu-ServiceNow im Speziellen lesen Sie unsere Story zur Drei-Wege-Integration von ServiceNow, Salesforce und Jira.
3. Kommunikation und Zusammenarbeit
Slack, Microsoft Teams, E-Mail, die Status Page. Die Orte, an denen Menschen tatsächlich erfahren, was gerade passiert. DevOps-Automatisierung, die diese Tools nicht erreicht, kann genauso gut gar nicht stattgefunden haben, denn das Team, das auf die Information reagieren muss, kann sie nicht sehen.
4. Security und Compliance
Der Vulnerability-Scanner, das SIEM, der Audit-Trail, das Compliance-Reporting-Tool. Dieser Bereich überschneidet sich mit DevSecOps. Unser DevSecOps-Integrationsleitfaden geht speziell auf die Security-Tooling-Ebene tiefer ein.
Jede Kategorie hat ihre eigenen Tools, ihre eigenen Zustandsautomaten, ihre eigenen Aktualisierungszyklen, ihre eigenen Verantwortlichen. Die DevOps-Automatisierungsstrategie, die ihre CI/CD-Pipeline ernst nimmt und die anderen drei als Nachgedanken behandelt, liefert innerhalb des Engineering-Teams schnell – und über den Rest des Business hinweg langsam.
Warum das Bindegewebe schlecht altert
Die CI/CD-Pipeline altert gut, weil ein Team sie besitzt und in einem gleichmäßigen Rhythmus aktualisiert.
Die Integration zwischen Azure DevOps und ServiceNow altert schlecht, weil keines der beiden Teams die Integration als seine primäre Verantwortung betrachtet und die Aktualisierungszyklen der beiden Teams nicht aufeinander abgestimmt sind. Das Engineering-Team liefert wöchentlich Änderungen aus. Das Betriebsteam liefert ServiceNow-Konfigurationsänderungen im halbjährlichen Release-Zyklus der Now Platform aus. Das Kundensupport-Team aktualisiert die Zendesk-Feldzuordnungen immer dann, wenn es auf eine Prozesslücke stößt. Das Security-Team hat seinen eigenen vierteljährlichen Review-Zyklus.
Wenn all das integriert werden muss, muss die Integration die Impedanz zwischen Änderungsraten absorbieren, die zueinander phasenverschoben sind. Diese Arbeit ist echte Engineering-Arbeit – und es ist die Arbeit, die die meisten DevOps-Strategien nicht einplanen.
Drei Dinge, die wahr sein müssen, damit DevOps-Automatisierung über das gesamte Estate funktioniert
Damit DevOps-Automatisierung ihr Versprechen über die vier Tool-Kategorien hinweg einlöst, müssen drei Dinge wahr sein.
Bidirektionale Synchronisation im großen Maßstab. Wenn ein Incident in ServiceNow erstellt wird, fließt er mit vollständigem Kontext nach Jira oder Azure DevOps. Wenn das Engineering-Team das Work-Item aktualisiert, fließt das Update mit voller Status-, Kommentar- und Anhang-Treue zurück ins kundenseitige Tool. Wenn die Änderung ausgeliefert wird, aktualisieren sich Status Page und Audit-Trail. Das geschieht über viele Tool-Paare hinweg, in Echtzeit, ohne Daten zu verlieren, wenn eine der Plattformen ein Update erhält.
Operative Verantwortung. Wenn die Integration bricht, ist jemand für die Behebung verantwortlich. Nicht das Engineering-Team, das ohnehin schon ein Backlog hat. Nicht das Betriebsteam, dem der Engineering-Kontext fehlt. Jemand, dessen primäre Verantwortung die Integrationsebene selbst ist und der im Takt von Incidents reagieren kann statt im Takt von Projekten.
Planbare Kosten. Wenn DevOps-Automatisierung skaliert, skaliert das Transaktionsvolumen mit. Ein verbrauchsbasiertes Integrationsmodell setzt das Business einer Kostenvolatilität aus, die sich in SLA-Verträgen nur schwer zusagen lässt. Die Integrationsebene, die DevOps-Automatisierung skaliert, muss dies zu planbaren Kosten tun – sonst wird die Finanzabteilung zum limitierenden Faktor.
Die meisten Unternehmen bekommen den ersten Punkt hin. Nur wenige bekommen alle drei.
Ansätze zur Automatisierung der DevOps-Integration über das gesamte Estate
Vier Ansätze decken den Großteil der praktischen Landschaft ab. Jeder passt zu einer anderen Phase der Betriebsmodell-Frage.
Native Integrationen und Marketplace-Apps
Atlassian Marketplace, ServiceNow Store, GitHub Marketplace, Slack App Directory. Jedes Ökosystem verfügt über native oder Marketplace-Integrationen für gängige Paare. Azure DevOps zu Jira, ServiceNow zu Slack, GitHub zu Teams.
Die Vorteile sind Vertrautheit und geringere Einrichtungskosten. Die Nachteile sind die Tiefe der Feldzuordnung, die Betriebsmodell-Frage, wer die Konfiguration pflegt, während sich beide Plattformen weiterentwickeln, und die begrenzte Reichweite, sobald die Integration drei oder mehr Tool-Kategorien überspannt.
Am besten geeignet für: kleine, abgegrenzte Automatisierungen zwischen benachbarten Tools.
iPaaS plus internes Team
Boomi, MuleSoft, Workato. Diese Plattformen decken das Problem der bidirektionalen Synchronisation im großen Maßstab ab. Ihr internes Team betreibt sie. Das ist ein Zwischenmodell. Der Plattform-Anbieter besitzt die Plattform-Ebene. Ihr Team besitzt die Konfiguration, den Betrieb und die Ergebnisse.
Unser iPaaS-Lösungsleitfaden behandelt die iPaaS-Entscheidung im Detail.
Am besten geeignet für: Unternehmen mit breiten iPaaS-Anforderungen über Daten, Anwendungen, APIs und KI-Agenten hinweg und mit den Engineering-Kapazitäten, um die Plattform selbst zu betreiben.
Eigenentwickelte Integrationen auf interner Infrastruktur
Manche Engineering-Teams bauen das Bindegewebe selbst auf interner Infrastruktur. Das funktioniert, wenn Integration ein strategisches Alleinstellungsmerkmal ist und das Team die Kapazität hat. Es skaliert jedoch nicht elegant, weil jede neue Tool-Kategorie, die dem DevOps-Estate hinzugefügt wird, Wartungsaufwand erzeugt, den das Team nicht abgeben kann.
Am besten geeignet für: Organisationen, in denen Integration zum Kern-IP gehört und das Team die Kapazität hat, sie zu betreiben.
Managed-Integration-Service
Ein Managed-Integration-Service betreibt das Bindegewebe im Auftrag des Kunden. Implementierung, Monitoring, Wartung, Reaktion auf Änderungen und Anpassung an Plattform-Updates sind alle als kontinuierlicher Service enthalten. Die DevOps-Automatisierung überspannt Tool-Kategorien, ohne dass das Team des Kunden zum Integrationsteam wird.
Das ist der Weg, der DevOps-Automatisierung über das gesamte Tool-Estate skaliert, ohne dass die Engineering-Personalstärke proportional mitwachsen muss.
Am besten geeignet für: Unternehmen, die DevOps-Automatisierung über mehrere Tool-Kategorien hinweg betreiben – insbesondere dort, wo Integrationsanzahl und Änderungsfrequenz über das hinausgewachsen sind, was ein internes Team aktuell halten kann.
Best Practices für DevOps-Automatisierung über das gesamte Tool-Estate
Vier Praktiken trennen die DevOps-Automatisierung, die geschäftlichen Mehrwert liefert, von der Art, die nur Pipeline-Kennzahlen liefert.
Bilden Sie die vier Kategorien explizit ab. Inventarisieren Sie die Tools, die Ihre DevOps-Automatisierung über Entwicklung, ITSM, Kommunikation und Security hinweg überbrücken muss. Die meisten Teams stellen fest, dass allein die Inventarisierung die Arbeit ist, die die Lücke im Betriebsmodell offenlegt.
Behandeln Sie die Integrationsebene als erstklassiges Engineering-Anliegen. Nicht als Konfigurationsproblem, das das Team löst, wenn es bricht. Die Integration zwischen Azure DevOps und ServiceNow ist Engineering-Arbeit, und sie als solche einzuplanen ist der Unterschied zwischen Automatisierung, die Bestand hat, und Automatisierung, die still und heimlich verfällt.
Überwachen Sie die Übergaben kontinuierlich. Die Integration, die die Demo bestanden hat und in Woche vier aufhört zu funktionieren, ist ein häufiges Muster. Kontinuierliche Überwachung der Datenfluss-Integrität (nicht nur der System-Verfügbarkeit) fängt die stillen Ausfälle ab, bevor sie den Kunden erreichen.
Verpflichten Sie sich zu planbaren Kosten auf der Integrationsebene. Verbrauchsbasierte Integrationsplattformen setzen das Business einer Kostenvolatilität aus, während DevOps-Automatisierung skaliert. Die Integrationsebene unter einer auf SLAs verpflichteten DevOps-Strategie braucht eine feste Form, mit der die Finanzabteilung planen kann.
Was sich ändert, wenn Integration zum Service wird
Der Unterschied zwischen dem eigenständigen Betrieb von DevOps-Automatisierung über das gesamte Estate und dem Bezug des Bindegewebes als Service liegt darin, was Sie einkaufen. Drei Dinge ändern sich gleichzeitig.
Sie gewinnen Planbarkeit. Ein planbarer Kostenposten, der alles abdeckt: Implementierung, Wartung, Monitoring, Behebung. Keine Verbrauchsüberraschungen, wenn Transaktionsvolumen sprunghaft ansteigt. Die Integrationskosten hören auf, von Quartal zu Quartal zu schwanken.
Sie gewinnen Transparenz. Transparente Integrationstechnologie. Keine Black-Box-Logik. Kein Code, den nur ein Spezialist lesen kann. Sie funktioniert mit Ihrem gesamten DevOps-Estate – mit welchen Tools auch immer Ihr Team arbeitet, mit welchen Plattformen auch immer Ihre Kunden und Partner arbeiten. Für die Datenresidenz erhalten Sie volle Kontrolle darüber, wo Ihre Daten verarbeitet und gespeichert werden. Sichtbar, prüfbar und rechenschaftspflichtig gegenüber jedem, der fragt.
Sie gewinnen Ergebnisse. Die Integration liegt in unserer Verantwortung – im Betrieb und in der Rechenschaft. Ihr Engineering-Team muss sich nicht länger mit Integrationsproblemen befassen. Ihr Betriebsteam beginnt, die Engineering-Arbeit in seinen Tools zu sehen. Die DevOps-Automatisierungsstrategie liefert, was sie liefern sollte.
„Zum ersten Mal kann ich tatsächlich sehen, was meine Integrationen tun. Kein Rätselraten. Kein Warten, bis etwas kaputtgeht, um es dann zu bemerken."— IT-Verantwortlicher, globaler Managed-Services-Anbieter
Zeit, das Modell zu ändern?
DevOps-Automatisierung liefert in der Regel Geschwindigkeitsgewinne innerhalb des Engineering-Teams und bleibt bei den Übergaben an Betrieb, Support und Security hinter ihren Möglichkeiten zurück. Die Lücke liegt nicht in der CI/CD-Pipeline. Sie liegt in der Integrationsebene, die das Engineering-Team mit dem Rest des Business verbindet.
Die meisten Unternehmen wissen das und behandeln es als das Problem von jemand anderem. Die Teams, die DevOps-Automatisierung richtig machen, tun das nicht. Sie behandeln das Bindegewebe als erstklassige Engineering-Arbeit und übergeben die operative Ebene an jemanden, dessen Spezialgebiet sie ist.
Dieser Wandel ist der Teil der DevOps-Automatisierungsstrategie, der CI/CD-Geschwindigkeit in Geschäftsergebnisse verwandelt.
Zeit für Veränderung? Sprechen Sie mit uns darüber, wie eine Managed Integration für Ihre DevOps-Automatisierungsstrategie aussehen kann.
