In der Gumpe: IT-Infrastruktur-Projekte am Ende des Wasserfalls

Am Ende des Was­ser­falls ist die Gumpe, das Tos­be­cken, in dem das fall­be­schleu­nig­te Was­ser unter meist gro­ßer Ver­wir­be­lung seine kine­ti­sche Ener­gie ver­liert, um anschlie­ßend mehr oder min­der ruhig wei­ter­zu­flie­ßen. Ähn­lich ver­lie­fen in den letz­ten Jahr­zehn­ten die meis­ten IT-Infra­struk­tur-Pro­jek­te: Meist eher lang­wie­ri­ge und große (Update‑)​Projekte wer­den nach Vari­an­ten des „klas­si­schen“​1 Was­ser­fall­mo­dells bis zum Release gema­nagt und gip­feln in einer mehr oder min­der auf­re­gen­den Phase des „Early Life Sup­ports“ (ITIL). Was auch immer man zuvor im frei­en Fall des Was­ser­fall-Pro­jek­tes getan hat, um diese Phase mög­lichst schmerz­frei zu über­ste­hen: Der Auf­prall ist häu­fig hart und die Stru­del der Gumpe wir­beln noch lange durch den ver­meint­lich längst beru­hig­ten Strom. Die Gumpe - das Tosbecken - IT-Projektmanagement am Ende des WasserfallsDen­noch: Irgend­wann „kehrt Ruhe ein“ und gleich­sam der „Ener­gie“ des Pro­jek­tes beraubt plät­schert die Wei­ter­ent­wick­lung der IT-Infra­struk­tur bis zum nächs­ten (Update‑)​Projekt ver­gleichs­wei­se ruhig vor sich hin. Den Takt ange­ge­ben hat bei der Wei­ter­ent­wick­lung der meis­ten IT-Infra­struk­tu­ren meist der Release-Zyklus des (Windows‑)​Betriebssystems – wobei häu­fig jede zwei­te Release aus­ge­las­sen wurde. Die Pha­sen rela­ti­ver Ruhe waren so eini­ge Jahre lang; die Menge der Kom­bi­na­tio­nen von Betriebs­sys­tem, Hard- und Soft­ware begrenzt und an Best Prac­tices ori­en­tiert. Bei aller Dyna­mik, die der IT oft nach­ge­sagt wird: eine ver­gleichs­wei­se ruhi­ge Welt!

Vie­les spricht m. E. dafür, dass es mit die­ser rela­ti­ven Ruhe vor­bei ist – und dass die „klas­si­schen“ IT-Infra­struk­tur-Pro­jek­te zuneh­mend der Ver­gan­gen­heit ange­hö­ren!

Takt­ge­ber für IT-Infra­struk­tur-Pro­jek­te ist natur­ge­mäß die tech­no­lo­gi­sche Ent­wick­lung – ins­be­son­de­re die der Betriebs­sys­tem- und Stan­dard-Soft­ware. Die­ser Takt aber ändert sich – was wohl viele Beob­ach­ter ange­sichts über­bor­den­der Kon­zern-Büro­kra­tie und -Poli­tik kaum für mög­lich gehal­ten hät­ten, ist Rea­li­tät gewor­den: Die bis­her eher behä­bi­gen Soft­ware-Rie­sen haben in den letz­ten Jah­ren mas­siv an Agi­li­tät gewon­nen, sind min­des­tens in ihrer Soft­ware­ent­wick­lung agil gewor­den. Soft­ware­ent­wick­lung wird auch von den Gro­ßen der Bran­che nicht mehr im mehr­jäh­ri­gen Zyklus gro­ßer „Was­ser­fall-Pro­jek­te“ betrie­ben, son­dern viel­mehr im eher monat­li­chen Takt agi­ler (Scrum‑)​Teams – und allen voran pro­du­ziert Micro­soft für viele der kon­zern­ei­ge­nen Pro­duk­te (und ins­be­son­de­re auch für sein Betriebs­sys­tem) nicht mehr nur monat­li­che Patches („Updates“), son­dern zusätz­lich meh­re­re (im Ver­gleich zu bis­he­ri­gen „Major Relea­ses“ natur­ge­mäß klei­ne­re) funk­tio­na­le Upgra­des pro Jahr. Was bis­her meist nur im Zusam­men­hang mit Win­dows 10 wahr­ge­nom­men und dis­ku­tiert wurde, gilt auch für viele ande­re Stan­dard­soft­ware-Pro­duk­te – und nicht nur für Micro­soft, son­dern auch für viele ande­re Soft­ware­her­stel­ler. Vom Release zum Kontinuum der UpgradesWas frü­her in Form von „Relea­ses“ – län­ger­fris­tig „ein­ge­fro­re­nen“ Kom­bi­na­tio­nen der jeweils aktu­el­len Ver­sio­nen der ein­ge­setz­ten Pro­duk­te – gema­nagt wurde, wird sich künf­tig nur noch als Kon­ti­nu­um von Updates mana­gen las­sen. Das klas­si­sche „Release­ma­nage­ment“ i. S. von ITIL ist m. E. zum Ster­ben ver­ur­teilt – und die bis­her übli­chen „Infra­struk­tur-Refresh-Pro­jek­te“ („ein­mal alles neu und dann ein paar Jahre Ruhe“) wird es über kurz oder lang nicht mehr geben. Neue Ver­sio­nen müs­sen nicht mehr im Mehr­jah­res­takt, son­dern eher im Monats­takt „ver­daut“ wer­den, pras­seln förm­lich auf die IT-Infra­struk­tu­ren ein – und das aus allen Rich­tun­gen.Kontinuum von Upgrades - von allen Seiten Sich davon ein­fach abzu­kop­peln, „das nicht mit­zu­ma­chen“, erscheint mir künf­tig unmög­lich: Nicht nur, dass die Her­stel­ler par­al­lel zu die­ser Beschleu­ni­gung auch die Sup­port-Zyklen ver­kür­zen, auch die immer umfang­rei­che­ren Inter­de­pen­den­zen der IT-Sys­te­me unter­ein­an­der dürf­ten zuneh­mend dazu zwin­gen, mög­lichst alle Sys­te­me auf einem aktu­el­len und ver­gleich­ba­ren Stand zu hal­ten. Wer­den Cloud-Tech­no­lo­gi­en – häu­fig in hybri­den Sze­na­ri­en und damit mit erheb­li­chen Inter­de­pen­den­zen zur „klas­si­schen“ IT-Infra­struk­tur – genutzt, ist man den Update-Zyklen ohne­hin gleich­sam pas­siv aus­ge­lie­fert – die Cloud war­tet nicht!

Stromschnellen im stetigen Fluss des UpgradesUm auf die Meta­pher der Gumpe zurück­zu­kom­men: Galt es frü­her, den Was­ser­fall und das Tos­be­cken mög­lichst gut zu über­ste­hen, ist es die Her­aus­for­de­rung der Zukunft, den vie­len klei­nen Strom­schnel­len des zuneh­mend schnel­le­ren Flus­ses aus­zu­wei­chen.

Was in klei­ne­ren IT-Orga­ni­sa­tio­nen noch mit der dort oft ver­brei­te­ten „Hacker-Men­ta­li­tät“ ein­fach fle­xi­bel (gewis­ser­ma­ßen auch „agil“) bewäl­tigt wer­den kann, stellt die oft gera­de erst in den letz­ten Jah­ren müh­sam pro­fes­sio­na­li­sier­te mit­tel­stän­di­sche IT vor große Her­aus­for­de­run­gen: Ein eher sta­ti­sches Release-Manage­ment i. S. von ITIL gehört womög­lich der Ver­gan­gen­heit an. Mög­li­cher­wei­se wer­den selbst ver­gleichs­wei­se adap­ti­ve Pha­sen-Model­le wie PRINCE2 zu behä­big, unge­eig­net für die extrem hohe (und extern von den ver­schie­de­nen Her­stel­lern gesteu­er­te) Ände­rungs­ra­te wäh­rend eines IT-Infra­struk­tur-Pro­jek­tes. Künf­tig zuneh­mend den „Out­put“ agi­ler „Soft­ware­fa­bri­ken“ „ver­dau­en“ zu müs­sen, bedeu­tet mehr als nur ein­fach eine höhe­re Update-Fre­quenz – wir haben es hier eher mit einer voll­stän­di­gen „Ernäh­rungs­um­stel­lung“ zu tun.

Anders for­mu­liert: Es ist vor­bei – alle 4 – 7 Jahre ein gro­ßes IT-Infra­struk­tur-Update-Pro­jekt zu machen und zwi­schen­durch mehr oder min­der gemüt­lich Tickets zu ver­wal­ten ist künf­tig zu wenig.

Um diese Ver­än­de­rung den­noch frucht­bar und gewinn­brin­gend zu gestal­ten, erschei­nen mir auf den ers­ten Blick eini­ge Dinge unab­ding­bar:

  • Die IT-Infra­struk­tu­ren selbst müs­sen ein­fa­cher wer­den: Da, wo die „Upgrade-Fes­tig­keit“ nicht in die Archi­tek­tur ein­ge­baut ist, soll­te der Grad des Custo­mi­zings redu­ziert wer­den; da, wo die APIs nicht klar und sta­bil sind, der Grad der Inte­gra­ti­on. Wie eigent­lich immer schon – aber auf­grund der beschleu­nig­ten Ent­wick­lung zuneh­mend wich­ti­ger: Abhän­gig­kei­ten zwi­schen Sys­te­men soll­ten auf das betriebs­wirt­schaft­lich not­wen­di­ge Mini­mum redu­ziert wer­den, der Wert­schöp­fung die­nen. Viele IT-Infra­struk­tu­ren ähneln m. E. inzwi­schen über­kom­ple­xen „gor­di­schen Kno­ten“; Gene­ra­tio­nen von Archi­tek­ten haben sich oft „Denk­mä­ler gesetzt“, Spe­zia­lis­ten sich „Kathe­dra­len gebaut“. Möch­te man den „Out­put“ „agi­ler Soft­ware­fa­bri­ken“ eini­ger­ma­ßen schmerz­frei ver­ar­bei­ten kön­nen, gilt es, zum Schwert zu grei­fen, den Kno­ten (schritt­wei­se) zu zer­schla­gen und sich künf­tig streng am KISS-Prin­zip und dem betriebs­wirt­schaft­lich Sinn­vol­len und Not­wen­di­gem zu ori­en­tie­ren.
  • IT-Infra­struk­tur-Abtei­lun­gen soll­ten sich auf Agi­li­tät ein­stel­len, selbst agil(er) wer­den [Update 10.03.2017: bei­spiels­wei­se wie hier beschrie­ben]. Damit meine ich nicht, dass jetzt jeder ein Kan­ban-Board braucht, aber: Jedes IT-Pro­jekt­ma­nage­ment, das nicht den agi­len Wert des „Reagieren[s] auf Ver­än­de­rung“​2 umsetzt, wird m. E. über kurz oder lang zum Schei­tern ver­ur­teilt sein. Nicht, weil „agil“ mir als „der Stein der Wei­sen“ erscheint, son­dern, weil fle­xi­bles (lies: agi­les) „Reagie­ren auf Ver­än­de­rung“ not­wen­dig ist, um auf die oben skiz­zier­te Ent­wick­lung reagie­ren zu kön­nen. Gibt es inner­halb der eige­nen Orga­ni­sa­ti­on keine Ent­wick­lungs-Abtei­lung, die bereits den Vor­rei­ter gespielt hat, wird der IT-Infra­struk­tur-Bereich „vor­weg­rei­ten“ müs­sen. Der Über­gang von „Pro­jekt“ zu „Betrieb“ wird m. E. zuneh­mend flie­ßend, das klas­si­sche in sich geschlos­se­ne Pro­jekt immer sel­te­ner wer­den. Auf IT-Orga­ni­sa­tio­nen, die das letz­te Jahr­zehnt damit ver­bracht haben, end­lich (ITIL‑)​prozessorientiert zu wer­den und par­al­lel eine (PRINCE2‑)​Projektorganisation auf­zu­bau­en, wirkt dies womög­lich gar wie eine Kehrt­wen­de – auf jeden Fall ist es her­aus­for­dernd. Ob im Pro­jekt oder im Betrieb: Jeder Pro­zess gehört auf den Prüf­stand – und ob die schar­fe Tren­nung zwi­schen Pro­jekt und Betrieb über­haupt noch sinn­voll ist, soll­te eben­falls kri­tisch hin­ter­fragt wer­den. Diese Gren­ze einem Dev­Ops-Ansatz ähn­lich auf­zu­lö­sen, erscheint mir künf­tig sinn­voll.

Exkurs: DevOps und Standard-Software

Als quasi uni­ver­sel­ler „Kitt“ für diese Bruch­li­nie scheint mir der­zeit Dev­Ops zu gel­ten. Dev­Ops wird (ähn­lich wie „Agi­li­tät“) i. d. R. mehr als Hal­tung denn als Metho­de (oder gar Werk­zeug) verstanden​3; Kern von Dev­Ops ist – ganz im Sinne des agi­len Wer­tes „Indi­vi­du­en und Inter­ak­tio­nen“​4 – eine Kul­tur der Zusam­men­ar­beit zwi­schen Soft­war­ent­wick­lern („Develop­ment“) und IT-Betriebs­ver­ant­wort­li­chen („Opera­ti­ons“).

Das Pro­blem ist: Dev­Ops scheint mir die hier dar­ge­stell­ten Pro­ble­me nicht zu lösen. Mit einer inter­nen Soft­ware­ent­wick­lungs­ab­tei­lung – also inner­halb der eige­nen Orga­ni­sa­ti­on – eng zusam­men­zu­rü­cken, eine Kul­tur der Zusam­men­ar­beit zu eta­blie­ren und so trag­fä­hi­ge Con­tin­ous Inte­gra­ti­on- und -Deli­very-Pro­zes­se zu eta­blie­ren, erscheint mir durch­aus mög­lich und erstre­bens­wert. In der Zusam­men­ar­beit mit exter­nen Her­stel­lern von Stan­dard-Soft­ware jedoch greift die­ser Ansatz m. E. nicht; auf­grund der Bruch­li­nie zwi­schen den Orga­ni­sa­tio­nen haben wir es eher mit „Dev|Ops“ als mit Dev­Ops zu tun.

DevOps vs. (Dev)(Ops)

Ein orga­ni­sa­ti­ons- und pro­dukt­über­grei­fen­des „Dev­Ops“ für die gleich­zei­ti­ge „Con­tin­ous Deli­very“ von Pro­duk­ten meh­re­rer Her­stel­ler muss m. E. noch ent­wi­ckelt wer­den.

  • IT-Infra­struk­tur-Spe­zia­lis­ten müs­sen sich auf ein qua­li­ta­tiv und quan­ti­ta­tiv ande­res Arbei­ten ein­stel­len – egal, ob im Pro­jekt oder im Betrieb. Nicht nur, dass das viel­zi­tier­te „lebens­lan­ge Ler­nen“ einen völ­lig neuen Stel­len­wert erhält und Metho­den­kom­pe­tenz und pro­dukt­un­ab­hän­gi­ges Fach­wis­sen ob der Geschwin­dig­keit der Ver­än­de­run­gen kon­kre­te (und damit extrem vola­ti­le) Produktkenntnisse​5 fast schon erset­zen dürf­ten, auch viele bis­her unzwei­fel­haf­te Annah­men und alt­her­ge­brach­te Vor­ge­hens­wei­sen ste­hen m. E. in Frage​6. Denn: Es gibt nicht ein­fach nur „mehr Updates“ – IT lässt sich künf­tig nicht mehr „sta­tisch“ betrei­ben! Wer einen Ein­druck von der Grö­ßen­ord­nung der Ver­än­de­rung erhal­ten möch­te, dem sei ein Gespräch mit einem älte­ren Soft­ware­ent­wick­ler, der sich an agi­les Vor­ge­hen gewöh­nen muss­te, ans Herz gelegt.
  • Auch die End­an­wen­der der Stan­dard-Soft­ware – die „Kun­den“ der inter­nen IT-Orga­ni­sa­ti­on – müs­sen sich auf kon­ti­nu­ier­li­che Ver­än­de­rung ein­stel­len, Ver­än­de­run­gen begrü­ßen ler­nen. Gera­de „digi­tal immi­grants“ (Marc Pren­sky) nei­gen dazu, selbst klei­ne­re Ver­än­de­run­gen bei­spiels­wei­se in der Benut­zer­ober­flä­che zum Anlass zu neh­men, quasi in Schreckstar­re zu ver­fal­len – ein Ver­hal­ten, das m. E. ange­sichts einer sich bei­spiels­wei­se bei Win­dows 10 mit jedem Update rele­vant ver­än­dern­den Ober­flä­che nicht mehr ange­mes­sen ist. Beson­ders pro­ble­ma­tisch erscheint mir, dass nach mei­nem Ein­druck der auf­grund der Beschleu­ni­gung der Ent­wick­lung fast zwangs­läu­fi­ge Man­gel an (aktu­el­ler) Doku­men­ta­ti­on und (aktu­el­len) Schu­lun­gen und Schu­lungs­un­ter­la­gen hier (quasi „am Ende der Nah­rungs­ket­te“) beson­ders stark aus­fällt. Selbst der gera­de­zu „hemds­är­me­li­ge“ Umgang der „digi­tal nati­ves“ mit IT scheint mir wenig hilf­reich. Sieht man ein­mal davon ab, dass die eher „trial-and-error“-ori­en­tier­te Stra­te­gie der „digi­tal nati­ves“ durch die „immi­grants“ kaum adap­tiert wer­den wird, dürf­te die­ses Vor­ge­hen zudem in vie­len Fäl­len wenig sinn­voll sein: Eine Buch­hal­tungs-Soft­ware bei­spiels­wei­se ist dafür nun ein­mal weni­ger geeig­net als eine Soci­al-Media-App – und auch ein „digi­tal nati­ve“ muss sich mit einer neuen Ver­si­on des ERP-Sys­tems ernst­haft aus­ein­an­der­set­zen. Auf die Anwen­dungs­be­treu­er in den Unter­neh­men kom­men harte Zei­ten zu – an der Bruch­li­nie zwi­schen „agi­lem“ Tempo und orga­ni­sa­to­ri­schem und indi­vi­du­el­lem Behar­rungs­ver­mö­gen wird die Span­nung zuneh­men!

Am m. E. wich­tigs­ten aber ist:

  • Soft­ware-Her­stel­ler müs­sen völ­lig anders mit Kun­den und Bera­tern inter­agie­ren. Der Wert der „Zusam­men­ar­beit mit dem Kun­den“​7 erscheint mir extern noch viel zu wenig umge­setzt – ein jähr­li­cher Kon­gress, ein paar fri­sche Vide­os, eine Feed­back-Web­site und eini­ge aus­ge­wähl­te Lieb­lings-Bera­ter erschei­nen mir eher aus der „alten“, „sta­ti­schen“ Welt zu stam­men. Agil auch an den Gren­zen der eige­nen Orga­ni­sa­ti­on und vor allem dar­über hin­aus zu sein, heißt m. E. bei­spiels­wei­se, Sup­port als not­wen­di­ge und frucht­ba­re „Inter­ak­ti­on“ zu betrach­ten, ihn nicht als (mit allen Mit­teln zu redu­zie­ren­den) Kos­ten­fak­tor wahr­zu­neh­men. „Indi­vi­du­en und Inter­ak­tio­nen“​8 soll­ten Orga­ni­sa­tio­nen, die agil ent­wi­ckeln, zu wich­tig sein, um an exter­ne Call-Cen­ter dele­giert zu wer­den. Model­le zum frucht­ba­ren Umgang mit­ein­an­der fin­den sich bei­spiels­wei­se in vie­len Open-Source-Pro­jek­ten – müs­sen aber m. E. für die „klas­si­sche“ Soft­ware­indus­trie noch müh­sam adap­tiert und vor allem zuerst noch orga­ni­sa­ti­ons­weit als not­wen­dig akzep­tiert wer­den.

In der IT zu arbei­ten, heißt seit jeher und ver­mut­lich mehr als in jeder ande­ren Bran­che, schnell und adap­tiv mit Ver­än­de­run­gen umzu­ge­hen. Ande­rer­seits gibt es mei­ner Erfah­rung nach trotz­dem auch in der IT eine erstaun­lich aus­ge­präg­te „Frü­her war alles besser“-Mentalität – die ich gera­de im Zusam­men­hang mit der zuneh­men­den Beschleu­ni­gung der letz­ten Jahre wahr­neh­me. Ver­än­de­run­gen zu begrü­ßen ist m. E. nicht erst seit der zuneh­men­den Ver­brei­tung agi­ler Metho­den ein Grund­wert der IT – und genau daran soll­ten wir uns auch im bis­her wenig agi­len IT-Infra­struk­tur­be­reich hal­ten!

Fuß­no­ten:

  1.  Viele Ver­tre­ter agi­ler Ansät­ze wür­den eher von „sta­ti­schen“ spre­chen.
  2.  Vgl. „Mani­fest für Agile Soft­ware­ent­wick­lung“ <http://​agi​le​ma​ni​festo​.org/​i​s​o​/​d​e​/​m​a​n​i​festo.html> (19.02.2017).
  3.  An die­ser Stel­le sei mir die viel­leicht ein wenig absei­ti­ge Anmer­kung erlaubt, dass m. E. die meis­ten durch irgend­wel­che neuen Ansät­ze ver­meint­lich gelös­ten Pro­ble­me bei einer auf­ga­ben­an­ge­mes­se­nen Hal­tung aller Betei­lig­ten gar nicht exis­tie­ren wür­den. Metho­den, deren wesent­li­cher Kern eine sinn­vol­le Hal­tung ist, exis­tie­ren also womög­lich nur, weil die Auf­for­de­rung „Nun seid doch mal alle ver­nünf­tig!“ noch nie gehol­fen hat.
  4.  <http://​agi​le​ma​ni​festo​.org/​i​s​o​/​d​e​/​m​a​n​i​festo.html> (07.02.2017).
  5.  Und übri­gens auch die lieb gewon­ne­nen Zer­ti­fi­zie­run­gen.
  6.  Bei­spiels­wei­se ist RTFM i. d. R. keine irgend­wie sinn­vol­le Ant­wort mehr (so sie es denn jemals war) – so etwas wie eine „com­pre­hen­si­ve docu­men­ta­ti­on“ (eben­da) kann man nur noch begrenzt erwar­ten.
  7.  Eben­da.
  8.  Eben­da.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*