Am Ende des Wasserfalls ist die Gumpe, das Tosbecken, in dem das fallbeschleunigte Wasser unter meist großer Verwirbelung seine kinetische Energie verliert, um anschließend mehr oder minder ruhig weiterzufließen. Ähnlich verliefen in den letzten Jahrzehnten die meisten IT-Infrastruktur-Projekte: Meist eher langwierige und große (Update‑)Projekte werden nach Varianten des „klassischen“1 Wasserfallmodells bis zum Release gemanagt und gipfeln in einer mehr oder minder aufregenden Phase des „Early Life Supports“ (ITIL). Was auch immer man zuvor im freien Fall des Wasserfall-Projektes getan hat, um diese Phase möglichst schmerzfrei zu überstehen: Der Aufprall ist häufig hart und die Strudel der Gumpe wirbeln noch lange durch den vermeintlich längst beruhigten Strom. 
Dennoch: Irgendwann „kehrt Ruhe ein“ und gleichsam der „Energie“ des Projektes beraubt plätschert die Weiterentwicklung der IT-Infrastruktur bis zum nächsten (Update‑)Projekt vergleichsweise ruhig vor sich hin. Den Takt angegeben hat bei der Weiterentwicklung der meisten IT-Infrastrukturen meist der Release-Zyklus des (Windows‑)Betriebssystems – wobei häufig jede zweite Release ausgelassen wurde. Die Phasen relativer Ruhe waren so einige Jahre lang; die Menge der Kombinationen von Betriebssystem, Hard- und Software begrenzt und an Best Practices orientiert. Bei aller Dynamik, die der IT oft nachgesagt wird: eine vergleichsweise ruhige Welt!
Vieles spricht m. E. dafür, dass es mit dieser relativen Ruhe vorbei ist – und dass die „klassischen“ IT-Infrastruktur-Projekte zunehmend der Vergangenheit angehören!
Taktgeber für IT-Infrastruktur-Projekte ist naturgemäß die technologische Entwicklung – insbesondere die der Betriebssystem- und Standard-Software. Dieser Takt aber ändert sich – was wohl viele Beobachter angesichts überbordender Konzern-Bürokratie und ‑Politik kaum für möglich gehalten hätten, ist Realität geworden: Die bisher eher behäbigen Software-Riesen haben in den letzten Jahren massiv an Agilität gewonnen, sind mindestens in ihrer Softwareentwicklung agil geworden. Softwareentwicklung wird auch von den Großen der Branche nicht mehr im mehrjährigen Zyklus großer „Wasserfall-Projekte“ betrieben, sondern vielmehr im eher monatlichen Takt agiler (Scrum‑)Teams – und allen voran produziert Microsoft für viele der konzerneigenen Produkte (und insbesondere auch für sein Betriebssystem) nicht mehr nur monatliche Patches („Updates“), sondern zusätzlich mehrere (im Vergleich zu bisherigen „Major Releases“ naturgemäß kleinere) funktionale Upgrades pro Jahr. Was bisher meist nur im Zusammenhang mit Windows 10 wahrgenommen und diskutiert wurde, gilt auch für viele andere Standardsoftware-Produkte – und nicht nur für Microsoft, sondern auch für viele andere Softwarehersteller. 
Was früher in Form von „Releases“ – längerfristig „eingefrorenen“ Kombinationen der jeweils aktuellen Versionen der eingesetzten Produkte – gemanagt wurde, wird sich künftig nur noch als Kontinuum von Updates managen lassen. Das klassische „Releasemanagement“ i. S. von ITIL ist m. E. zum Sterben verurteilt – und die bisher üblichen „Infrastruktur-Refresh-Projekte“ („einmal alles neu und dann ein paar Jahre Ruhe“) wird es über kurz oder lang nicht mehr geben. Neue Versionen müssen nicht mehr im Mehrjahrestakt, sondern eher im Monatstakt „verdaut“ werden, prasseln förmlich auf die IT-Infrastrukturen ein – und das aus allen Richtungen.
Sich davon einfach abzukoppeln, „das nicht mitzumachen“, erscheint mir künftig unmöglich: Nicht nur, dass die Hersteller parallel zu dieser Beschleunigung auch die Support-Zyklen verkürzen, auch die immer umfangreicheren Interdependenzen der IT-Systeme untereinander dürften zunehmend dazu zwingen, möglichst alle Systeme auf einem aktuellen und vergleichbaren Stand zu halten. Werden Cloud-Technologien – häufig in hybriden Szenarien und damit mit erheblichen Interdependenzen zur „klassischen“ IT-Infrastruktur – genutzt, ist man den Update-Zyklen ohnehin gleichsam passiv ausgeliefert – die Cloud wartet nicht!
Um auf die Metapher der Gumpe zurückzukommen: Galt es früher, den Wasserfall und das Tosbecken möglichst gut zu überstehen, ist es die Herausforderung der Zukunft, den vielen kleinen Stromschnellen des zunehmend schnelleren Flusses auszuweichen.
Was in kleineren IT-Organisationen noch mit der dort oft verbreiteten „Hacker-Mentalität“ einfach flexibel (gewissermaßen auch „agil“) bewältigt werden kann, stellt die oft gerade erst in den letzten Jahren mühsam professionalisierte mittelständische IT vor große Herausforderungen: Ein eher statisches Release-Management i. S. von ITIL gehört womöglich der Vergangenheit an. Möglicherweise werden selbst vergleichsweise adaptive Phasen-Modelle wie PRINCE2 zu behäbig, ungeeignet für die extrem hohe (und extern von den verschiedenen Herstellern gesteuerte) Änderungsrate während eines IT-Infrastruktur-Projektes. Künftig zunehmend den „Output“ agiler „Softwarefabriken“ „verdauen“ zu müssen, bedeutet mehr als nur einfach eine höhere Update-Frequenz – wir haben es hier eher mit einer vollständigen „Ernährungsumstellung“ zu tun.
Anders formuliert: Es ist vorbei – alle 4 – 7 Jahre ein großes IT-Infrastruktur-Update-Projekt zu machen und zwischendurch mehr oder minder gemütlich Tickets zu verwalten ist künftig zu wenig.
Um diese Veränderung dennoch fruchtbar und gewinnbringend zu gestalten, erscheinen mir auf den ersten Blick einige Dinge unabdingbar:
- Die IT-Infrastrukturen selbst müssen einfacher werden: Da, wo die „Upgrade-Festigkeit“ nicht in die Architektur eingebaut ist, sollte der Grad des Customizings reduziert werden; da, wo die APIs nicht klar und stabil sind, der Grad der Integration. Wie eigentlich immer schon – aber aufgrund der beschleunigten Entwicklung zunehmend wichtiger: Abhängigkeiten zwischen Systemen sollten auf das betriebswirtschaftlich notwendige Minimum reduziert werden, der Wertschöpfung dienen. Viele IT-Infrastrukturen ähneln m. E. inzwischen überkomplexen „gordischen Knoten“; Generationen von Architekten haben sich oft „Denkmäler gesetzt“, Spezialisten sich „Kathedralen gebaut“. Möchte man den „Output“ „agiler Softwarefabriken“ einigermaßen schmerzfrei verarbeiten können, gilt es, zum Schwert zu greifen, den Knoten (schrittweise) zu zerschlagen und sich künftig streng am KISS-Prinzip und dem betriebswirtschaftlich Sinnvollen und Notwendigem zu orientieren.
- IT-Infrastruktur-Abteilungen sollten sich auf Agilität einstellen, selbst agil(er) werden [Update 10.03.2017: beispielsweise wie hier beschrieben]. Damit meine ich nicht, dass jetzt jeder ein Kanban-Board braucht, aber: Jedes IT-Projektmanagement, das nicht den agilen Wert des „Reagieren[s] auf Veränderung“2 umsetzt, wird m. E. über kurz oder lang zum Scheitern verurteilt sein. Nicht, weil „agil“ mir als „der Stein der Weisen“ erscheint, sondern, weil flexibles (lies: agiles) „Reagieren auf Veränderung“ notwendig ist, um auf die oben skizzierte Entwicklung reagieren zu können. Gibt es innerhalb der eigenen Organisation keine Entwicklungs-Abteilung, die bereits den Vorreiter gespielt hat, wird der IT-Infrastruktur-Bereich „vorwegreiten“ müssen. Der Übergang von „Projekt“ zu „Betrieb“ wird m. E. zunehmend fließend, das klassische in sich geschlossene Projekt immer seltener werden. Auf IT-Organisationen, die das letzte Jahrzehnt damit verbracht haben, endlich (ITIL‑)prozessorientiert zu werden und parallel eine (PRINCE2‑)Projektorganisation aufzubauen, wirkt dies womöglich gar wie eine Kehrtwende – auf jeden Fall ist es herausfordernd. Ob im Projekt oder im Betrieb: Jeder Prozess gehört auf den Prüfstand – und ob die scharfe Trennung zwischen Projekt und Betrieb überhaupt noch sinnvoll ist, sollte ebenfalls kritisch hinterfragt werden. Diese Grenze einem DevOps-Ansatz ähnlich aufzulösen, erscheint mir künftig sinnvoll.
Exkurs: DevOps und Standard-Software
Als quasi universeller „Kitt“ für diese Bruchlinie scheint mir derzeit DevOps zu gelten. DevOps wird (ähnlich wie „Agilität“) i. d. R. mehr als Haltung denn als Methode (oder gar Werkzeug) verstanden3; Kern von DevOps ist – ganz im Sinne des agilen Wertes „Individuen und Interaktionen“4 – eine Kultur der Zusammenarbeit zwischen Softwarentwicklern („Development“) und IT-Betriebsverantwortlichen („Operations“).
Das Problem ist: DevOps scheint mir die hier dargestellten Probleme nicht zu lösen. Mit einer internen Softwareentwicklungsabteilung – also innerhalb der eigenen Organisation – eng zusammenzurücken, eine Kultur der Zusammenarbeit zu etablieren und so tragfähige Continous Integration- und -Delivery-Prozesse zu etablieren, erscheint mir durchaus möglich und erstrebenswert. In der Zusammenarbeit mit externen Herstellern von Standard-Software jedoch greift dieser Ansatz m. E. nicht; aufgrund der Bruchlinie zwischen den Organisationen haben wir es eher mit „Dev|Ops“ als mit DevOps zu tun.
Ein organisations- und produktübergreifendes „DevOps“ für die gleichzeitige „Continous Delivery“ von Produkten mehrerer Hersteller muss m. E. noch entwickelt werden.
- IT-Infrastruktur-Spezialisten müssen sich auf ein qualitativ und quantitativ anderes Arbeiten einstellen – egal, ob im Projekt oder im Betrieb. Nicht nur, dass das vielzitierte „lebenslange Lernen“ einen völlig neuen Stellenwert erhält und Methodenkompetenz und produktunabhängiges Fachwissen ob der Geschwindigkeit der Veränderungen konkrete (und damit extrem volatile) Produktkenntnisse5 fast schon ersetzen dürften, auch viele bisher unzweifelhafte Annahmen und althergebrachte Vorgehensweisen stehen m. E. in Frage6. Denn: Es gibt nicht einfach nur „mehr Updates“ – IT lässt sich künftig nicht mehr „statisch“ betreiben! Wer einen Eindruck von der Größenordnung der Veränderung erhalten möchte, dem sei ein Gespräch mit einem älteren Softwareentwickler, der sich an agiles Vorgehen gewöhnen musste, ans Herz gelegt.
- Auch die Endanwender der Standard-Software – die „Kunden“ der internen IT-Organisation – müssen sich auf kontinuierliche Veränderung einstellen, Veränderungen begrüßen lernen. Gerade „digital immigrants“ (Marc Prensky) neigen dazu, selbst kleinere Veränderungen beispielsweise in der Benutzeroberfläche zum Anlass zu nehmen, quasi in Schreckstarre zu verfallen – ein Verhalten, das m. E. angesichts einer sich beispielsweise bei Windows 10 mit jedem Update relevant verändernden Oberfläche nicht mehr angemessen ist. Besonders problematisch erscheint mir, dass nach meinem Eindruck der aufgrund der Beschleunigung der Entwicklung fast zwangsläufige Mangel an (aktueller) Dokumentation und (aktuellen) Schulungen und Schulungsunterlagen hier (quasi „am Ende der Nahrungskette“) besonders stark ausfällt. Selbst der geradezu „hemdsärmelige“ Umgang der „digital natives“ mit IT scheint mir wenig hilfreich. Sieht man einmal davon ab, dass die eher „trial-and-error“-orientierte Strategie der „digital natives“ durch die „immigrants“ kaum adaptiert werden wird, dürfte dieses Vorgehen zudem in vielen Fällen wenig sinnvoll sein: Eine Buchhaltungs-Software beispielsweise ist dafür nun einmal weniger geeignet als eine Social-Media-App – und auch ein „digital native“ muss sich mit einer neuen Version des ERP-Systems ernsthaft auseinandersetzen. Auf die Anwendungsbetreuer in den Unternehmen kommen harte Zeiten zu – an der Bruchlinie zwischen „agilem“ Tempo und organisatorischem und individuellem Beharrungsvermögen wird die Spannung zunehmen!
Am m. E. wichtigsten aber ist:
- Software-Hersteller müssen völlig anders mit Kunden und Beratern interagieren. Der Wert der „Zusammenarbeit mit dem Kunden“7 erscheint mir extern noch viel zu wenig umgesetzt – ein jährlicher Kongress, ein paar frische Videos, eine Feedback-Website und einige ausgewählte Lieblings-Berater erscheinen mir eher aus der „alten“, „statischen“ Welt zu stammen. Agil auch an den Grenzen der eigenen Organisation und vor allem darüber hinaus zu sein, heißt m. E. beispielsweise, Support als notwendige und fruchtbare „Interaktion“ zu betrachten, ihn nicht als (mit allen Mitteln zu reduzierenden) Kostenfaktor wahrzunehmen. „Individuen und Interaktionen“8 sollten Organisationen, die agil entwickeln, zu wichtig sein, um an externe Call-Center delegiert zu werden. Modelle zum fruchtbaren Umgang miteinander finden sich beispielsweise in vielen Open-Source-Projekten – müssen aber m. E. für die „klassische“ Softwareindustrie noch mühsam adaptiert und vor allem zuerst noch organisationsweit als notwendig akzeptiert werden.
In der IT zu arbeiten, heißt seit jeher und vermutlich mehr als in jeder anderen Branche, schnell und adaptiv mit Veränderungen umzugehen. Andererseits gibt es meiner Erfahrung nach trotzdem auch in der IT eine erstaunlich ausgeprägte „Früher war alles besser“-Mentalität – die ich gerade im Zusammenhang mit der zunehmenden Beschleunigung der letzten Jahre wahrnehme. Veränderungen zu begrüßen ist m. E. nicht erst seit der zunehmenden Verbreitung agiler Methoden ein Grundwert der IT – und genau daran sollten wir uns auch im bisher wenig agilen IT-Infrastrukturbereich halten!
Footnotes:
- ↑ Viele Vertreter agiler Ansätze würden eher von „statischen“ sprechen.
- ↑ Vgl. „Manifest für Agile Softwareentwicklung“ <http://agilemanifesto.org/iso/de/manifesto.html> (19.02.2017).
- ↑ An dieser Stelle sei mir die vielleicht ein wenig abseitige Anmerkung erlaubt, dass m. E. die meisten durch irgendwelche neuen Ansätze vermeintlich gelösten Probleme bei einer aufgabenangemessenen Haltung aller Beteiligten gar nicht existieren würden. Methoden, deren wesentlicher Kern eine sinnvolle Haltung ist, existieren also womöglich nur, weil die Aufforderung „Nun seid doch mal alle vernünftig!“ noch nie geholfen hat.
- ↑ <http://agilemanifesto.org/iso/de/manifesto.html> (07.02.2017).
- ↑ Und übrigens auch die lieb gewonnenen Zertifizierungen.
- ↑ Beispielsweise ist RTFM i. d. R. keine irgendwie sinnvolle Antwort mehr (so sie es denn jemals war) – so etwas wie eine „comprehensive documentation“ (ebenda) kann man nur noch begrenzt erwarten.
- ↑ Ebenda.
- ↑ Ebenda.
Pingback: Welches Mindset braucht ein guter IT Engineer? – Falk Husemann