In letzter Zeit sitze ich immer häufiger in Meetings, in denen der CIO fordert: Ich will alles agil! Damit meint er in der Regel, dass er nicht mehr zwischen langsamer und schneller IT unterscheiden will, sondern dass die Releasezyklen aller Systeme dramatisch verkürzt werden sollen. Ist die IT der zwei Geschwindigkeiten damit Geschichte? Warum wird diese Forderung überhaupt gestellt? Und ist sie realisierbar?

Warum Fassadensanierung nicht mehr reicht

Nun, der Wunsch IT-Systeme schneller weiterzuentwickeln ist nicht neu. Bislang war es aber so, dass diese Anforderung vor allem für Frontend-Systeme galt. Alles, womit der Kunde direkt in Kontakt kam, musste schnell die neuesten Trends aufgreifen und flexibel sein, um Wettbewerbern mit neuen Angeboten zuvorzukommen. Inzwischen besteht der Bedarf für Flexibilität aber nicht mehr nur am Frontend, sondern auch im Backend: Um beispielsweise neue Varianten eines bereits in der Produktion befindlichen Fahrzeuges anbieten zu können, müssen die Produktionsprozesse angepasst werden. Oder die Mitarbeiter in der Bankfiliale können ihren Kunden nur dann modernen Service bieten, wenn ihre IT-Systeme das auch hergeben, also mindestens genauso aktuell sind, wie das Online-Portal. Und der Softwarekonzern wird nur in der Lage sein, seinen Kunden schnell neue Features anzubieten, wenn seine Kernsysteme flexibel entwickelt werden können. Mit einem Facelift der Fassade ist es also nicht mehr getan. Es gilt, das ganze Gebäude zu erneuern.

Um auch das Backend flexibler zu machen, müssen sich aber so gut wie alle Application-Management- und Development-Prozesse verändern. Das fängt beispielsweise bei der Bereitstellung der Infrastruktur an. Die Bestellung und Lieferung von physischen Servern dauert sechs Wochen, das ist in einer agilen Welt eine halbe Ewigkeit. Selbst die Bereitstellung von Infrastruktur in einer Anbieter-Cloud geht nicht von jetzt auf gleich, es sei denn, man hat diesen Prozess bereits automatisiert und einen Self Service daraus gemacht. Ähnliches gilt für die Automatisierung der Tests und der Inbetriebnahme. Wie Entwicklungsanforderungen gehandhabt werden verändert sich ebenfalls: denn wo früher ein Team aus dem Support Fehler behoben und kleine Änderungen vorgenommen hat, während ein anderes Team an der Weiterentwicklung der Anwendung arbeitete, gibt es in der agilen Welt nur noch ein einziges Entwicklungsteam, das User Stories, Change Requests und Fehlerbehebungen umsetzt.

Kernsanierung der Ablauforganisation

In der geforderten Dimension, also der agilen Entwicklung von Backend-Systemen, würden dann vielleicht 100 Entwickler-Teams parallel an der Weiterentwicklung einer Kernanwendung arbeiten. Und damit die dann auch funktioniert, müssen alle zum Stichtag eine lauffähige Version ihrer Änderung bereitstellen, um Integrationstests durchführen zu können. Das verändert die gesamte Ablauforganisation der IT, genauso wie die Zusammenarbeit mit der Fachabteilung.

Machbar ist das, egal, ob es sich um Cobol- oder SAP-Anwendungen dreht. Sprachen und Architekturen machen es einem nur etwas leichter oder schwerer, aber prinzipiell ist Agilität immer möglich. Die Umstellung dauert natürlich etwas. Und manches geht auch selbst dann nicht, nämlich die Einführung komplett neuer Plattformen im Zwei-Wochen-Takt. Der Grund? Nun, selbst wenn einzelne Komponenten schneller als vorher fertig werden, lohnt sich die Migration auf eine neue Plattform erst, wenn die kritische Masse an Funktionalität erreicht ist. Deshalb müssen sich CIOs in diesen Fällen weiterhin etwas gedulden. Ansonsten wird die IT der zwei Geschwindigkeiten aber bald der Vergangenheit angehören, oder sind Sie anderer Meinung?