Agilität trifft IT-Betrieb – die Sollbruchstelle der Transformation?

Wenn kürzere Planungszyklen, flexiblere Reaktionen und eine schnelle Time-to-Market gefragt sind, lautet die Antwort eigentlich immer “Agilität”. In vielen Unternehmen ist dieser Ansatz auf die Softwareentwicklung fokussiert, schließlich gibt es hier klare Vorgehensmodelle, die weit verbreitet sind und sich bewährt haben. Im Gegensatz dazu wurde der Keller nicht aufgeräumt: Bereiche wie Netze, Datenbanken, Support-Teams, Operations, Batch-Prozess-Verarbeitung und der Rest der IT-Infrastruktur arbeiten oft noch in alten Strukturen – die Teams nah am Kunden sind neu, Blech und Kabel nicht.

Doch wie können die Vorteile der agilen Softwareentwicklung trotzdem genutzt werden, auch wenn die Startbedingungen nicht optimal sind? Gerne wird der Weg gewählt, den agilen Fokus auf neue Anwendungen zu legen – schließlich kann man hier auf der grünen Wiese starten, ein agiles Team zusammenzustellen und von Beginn an in kurzen Release-Zyklen arbeiten, um gleich auch zielgerichteter auf Kundenanforderungen zu reagieren.

Agil hat Folgen für den IT-Betrieb

Für den IT-Betrieb bedeutet dies in der Regel, dass die Entwicklungsteams eine höhere Eigenverantwortung übernehmen, ihre Applikationen möglichst robust gegenüber Schnittstellen entwickeln und architektonisch viele „kleine“ (Mikro-)Services bauen, die autark laufen können. Aber spätestens dann, wenn es Schnittstellen zu Legacy-Anwendungen gibt, kann ein agiles Team nicht mehr autark in einem agilen Vorgehensmodell arbeiten, ohne betriebliche Risiken einzugehen, weil es auf Zuarbeit aus Infrastruktur- oder Anwendungsteams mit unflexiblen Release-Zyklen angewiesen ist. Es kommt darauf an, die Planung oben mit der Planung unten zu synchronisieren. Plus die Mindsets, Standards, Budgets und Entscheidungsbefugnisse.

Agil und klassisch laufen parallel

Der IT-Betrieb steht also vor der Herausforderung, die Stabilität zu gewährleisten und zugleich Agilität zuzulassen. So kann ein Change-Prozess mit langen Vorlaufzeiten für komplexe Legacy-Anwendungen im Backend genau das Richtige, für ein agil entwickeltes Frontend aber viel zu träge sein. Beispielsweise ist es im Incident-Prozess für komplexe Anwendungen häufig notwendig, viele verschiedene Teams einzubinden, da ein einzelner Ausfall mehrere voneinander abhängige Anwendungen betreffen kann.

Auf der anderen Seite kann ein neuer Service funktional unabhängig sein, wodurch der Ausfall nicht direkt auf die komplette Funktionalität anderer Applikationen durchschlägt und sich vom Team über Monitoring und schnelles Fehlerfixing auch ohne übergreifende Einheiten in kurzer Zeit lösen lässt.

Herausforderungen des agilen IT-Betriebs

Dabei können hohe Reibungsverluste entstehen: Beispielsweise weiten sich Liegezeiten von Tickets aus, es kommt zu Staus im agilen Team. Ein Grund ist die Überlast in den klassischen Strukturen, weil wenig Transparenz über die Anforderungen besteht und viele Eingangskanäle bedient werden müssen, darunter E-Mail, Tickets, persönliche Anfragen oder per MS Teams. Da den klassisch aufgestellten Teams oft die methodische Unterstützung fehlt, gibt es wenig bis keine Unterstützung in der Arbeitsweise, Priorisierung oder Entscheidungsfindung.

Die Lösung für agilen Betrieb

Aufgrund der individuellen Ausgangslage gibt es keine Lösungen von der Stange. Daher müssen Betriebsprozesse individuell auf den agilen Reifegrad und die Architektur der Softwarelandschaft eines Unternehmens angepasst sein, um Agilität und Stabilität in einem vorgegebenen Rahmen parallel zu ermöglichen. So kann sich die IT-Architektur kontinuierlich einer agilen-modularisierten Software-Landschaft annähern, während sich iterativ ein agiler IT-Betrieb dieser Transformation anpasst. Der Weg hängt aber immer auch vom agilen Reifegrad des Unternehmens sowie der Anwendungsarchitektur ab.

Unternehmen sollten an zwei Stellen ansetzen: den Menschen im IT-Betrieb (das ist einen eigenen Artikel wert) und den Strukturen beziehungsweise Prozessen. Sie müssen die passenden KPIs einführen, die Eingangskanäle reduzieren, Prioritäten zur Unterstützung von Entscheidungen festlegen, Probleme und Experten zusammenbringen sowie Eskalationen verringern. Gefragt sind etwa umfassende Transparenz (End-2-End) in der Wertschöpfung in Bezug auf Nutzen und Aufwand sowie klare Rollen und Abgrenzungen. Kommt es hingegen zu Verzögerungen im Abgleich, entstehen Fehl- und Doppelplanung. Damit der IT-Betrieb das Tempo der agilen Entwickler mitgehen kann, muss er sich neu aufstellen.

Quelle Titelbild: AdobeStock/alfa27