Erfolgsfaktoren für eine Two-Speed-IT

Mit dem Stichwort Bimodale IT (Gartner) [1] beziehungsweise Two-Speed IT (McKinsey) [2, 3, 4] wurde eine Diskussion in der IT-Welt ge­startet, wie man ver­schiedene Ent­wicklungs­para­digmen in einem Unter­nehmen ver­wenden kann. Offen­sicht­lich hat das darin steckende Prinzip bei einigen Be­teiligten den Kern getroffen und zu euphorischer Be­geisterung aber auch zu empörter Ab­lehnung geführt.

Koexistenz von ver­schiedenen Ent­wicklungs­geschwindig­keiten

Mit dem Auf­kom­men der Popu­la­rität von agilen Soft­ware-Ent­wicklungs­modellen stellte sich die Frage, wie man diese mit einer ge­wachsenen Projekt­kultur verbinden kann. Die alt­ehr­würdigen Kern­systeme sind ge­prägt von dem Streben nach Sta­bi­li­tät und Sicher­heit:

• Die Funktionalität muss zur Ver­fügung stehen.
• Fehler sind kost­spielig und müssen ver­mieden werden.
• Nachvollzieh­barkeit und Do­ku­men­ta­tion spielt eine wichtige Rolle.

Auf der anderen Seite steht das Business. Hier dreht sich die Welt immer schneller. Produkte werden kurzfristig auf den Markt geworfen und ver­schwinden zum Teil auch ebenso schnell wieder. Das führt zu anderen Schwer­punkten bei der Wichtigkeit der Anforderungen:

• Time-to-Market ist essentiell, wenn man nicht vom Wett­bewerber ab­ge­hängt werden will.
• Das Produkt – und die unter­stützen­den IT-Systeme – sind zum Ent­wicklungs­beginn nur vage de­fi­niert und müssen erst mitwachsen.
• Nachvollziehbarkeit und Dokumentation spielen für kurzlebige Software-Features eine unter­geordnete Rolle.

Es ist in der Regel bei etablierten Firmen nicht möglich, die IT mit einem Schlag aus der „langsamen“ Welt der Kern­systeme in die „schnelle“ Welt der Front­end-Systeme zu trans­for­mie­ren. Damit sind auch gleich die zwei Bereiche genannt, die charak­te­ris­tisch für die ver­schie­denen Ge­schwindig­keits­an­forder­ungen stehen. Trotzdem sei bemerkt, dass diese Bereiche nicht zwangs­weise auf diese Weise zu­ge­ordnet werden müssen. Auch Kern­systeme können agil und Front­end-System klassisch er­stellt werden.

Es muss nun ein Weg gefunden werden, mit dieser Situation umzugehen. Ein Lösungs­ansatz dieses Dilemmas besteht darin, für die ver­schiedenen Bereiche unter­schiedliche Vor­gehens­modelle für die Software-Entwicklung vor­zu­sehen. Diese Abkehr von einem uniformen Vor­gehens­modell innerhalb eines Unter­nehmens führt zu einer „Two-​Speed-​IT“.

Erfolgsfaktor: Separierbarkeit der Komponenten nach Entwicklungs­modell

Ein Erfolgs­faktor für eine Two-​Speed-​IT ist eine Sepa­rie­rung der System­land­schaft in mehrere möglichst un­ab­hängige Teile. Diese kön­nen dann umso ein­facher nach den beiden Para­dig­men be­han­delt werden.

Wenn wir einen Schnitt der System­land­schaft in agile und klassische Kom­po­nen­ten in Be­tracht ziehen, dann müssen die fachlichen Appli­ka­tionen reali­sier­bar sein, die unter Um­ständen mehrere solcher Kom­po­nen­ten der beiden Arten nutzen müssen. Dem gegen­über steht die Mög­lich­keit, vollständig unabhängige Appli­ka­tionen nach jeweils eigenen Ent­wicklungs­modellen umzusetzen.

Ein Beispiel wäre in der Finanz­branche die Ab­wicklung eines neuen Produkts in einer eigenen App­li­ka­tion. Das be­deutet aber auch, dass der gesamte Prozess der Ab­wicklung separiert wird. Das kann bei­spiels­weise dann sinn­voll sein, wenn die Ziel­gruppe klein und das Produkt zeitlich begrenzt ist. Da in diesem Fall die Grenzen klar gezogen sind, be­ein­flussen sich die Ent­wicklungs­modelle nicht.

In der freien Wild­bahn sind die Über­gänge natürlich fließend, sodass auch die Separier­bar­keit nur graduell mög­lich wird. Je enger die Kopplung der ver­schiedenen Systeme ist, desto schwieriger wird ein Vor­gehen mit unter­schiedlichen Entwicklungs­modellen.

IT ist heute vernetzt

In früheren Zeiten wurden allein­stehende IT-Systeme ge­baut und be­trieben. Für unsere Kunden haben wir noch Anfang des Jahr­tausends solche Solitäre gebaut.

Heute findet man das kaum noch. Die Systeme stehen nicht mehr für sich alleine, sondern sind ver­netzt. Nur im Ver­bund kommen alle Aspekte des fach­lichen und techni­schen Know-hows des Ge­schäfts zum Tragen. Der Wert der Systeme für ein Unter­nehmen wandert zu­nehmend in die Ver­netzung. Mehr­fache Daten­pflege und potentielle Inkon­sis­tenzen werden ver­mieden. Hier­durch lassen sich dann auch ver­borgene Be­ziehungen zwischen den unter­schied­lichen Daten auf­spüren und ausnutzen.

Die einzelnen Komponenten erhalten Auf­gaben, die nur sie durch­führen. War es vor­mals üblich, quer­schnitt­liche Aufgaben wie bei­spiels­weise eine Kunden­ver­waltung in den di­ver­sen System separat zu halten, so wird diese Auf­gabe nun einer zen­tralen Kompo­nente über­tragen. Die anderen Kompo­nente benutzen jetzt deren Schnitt­stellen, ohne die Funktionalität zu duplizieren.

In der obigen Abbildung wird ver­sucht, dies im Kon­text einer Two-​Speed-​IT zu visu­a­li­sieren. Einer­seits sind hier Kom­po­nenten und ihre Ver­netzung über Auf­ruf­beziehungen zu sehen. Andererseits sind die Kom­po­nenten ent­sprechend ihres Ent­wicklungs­modells klassifiziert. Dabei stehen die Kompo­nenten A1 und A2 für Appli­ka­tionen, die nach einem agilen Vor­gehens­modell (A) weiter­ent­wickelt werden. C1, C2 und C2 sind Kompo­nenten mit einem klassischen Vorgehensmodell (C).

Erfolgsfaktor: Dienste für eine Two-Speed-IT

Dienste spielen in einer modernen System­land­schaft eine zentrale Rolle. Schon lange zieht die „service-oriented archi­tec­ture“ (SOA) ihre Kreise durch die IT. Neuer­dings werden einige Grund­ge­danken da­raus weiter voran getrieben und finden sich zu­nehmend als Micro-Services in neu kon­zipier­ten Systemen wieder.

Für eine Two-​Speed-​IT müssen wir auch die be­tei­lig­ten Dienste ins Auge fassen. Damit die schnell­lebigen A-Kom­pon­enten ent­wickelt werden können, müssen die be­nötigten Back­end-Dienste ge­nutzt werden können. Im Ideal­fall stehen die Dienste der C-Kom­po­nenten be­reits in einer tech­nisch ver­wert­baren Form zur Ver­fügung. Alter­na­tiv können Wege ge­sucht werden, um fehlende Dienste zu kompensieren.

Fehlende Dienste bremsen die A-Projekte

Die Entwicklung ist nicht mit der Ein­führung ab­ge­schlossen. Das ist nur der Start­punkt für die Weiter­ent­wicklung und Pflege eines Systems.

Wenn zu Beginn das A-Projekt die be­nötigten Dienste be­kommen oder sich Ab­hilfe ge­schaffen hat, so ver­stummt damit nicht der Ruf nach neuen oder über­arbeiteten Diensten.

Das Business – beispielsweise in Banken und Ver­siche­rungen – will und muss neue Produkte ein­führen. Dabei kommt man über kurz oder lang nicht an den C-App­li­ka­ti­onen der Kern­systeme vorbei. Dort werden neue Dienste be­nötigt. Durch die Träg­heit der C-Projekte kann dies nicht in der Ge­schwindig­keit ge­schehen, die von den A-Pro­jekten gewünscht wäre.

Erfolgsfaktor: Kompensation von fehlenden Diensten

Eine naheliegende Art, mit fehlenden Diensten um­zu­gehen, ist es, diese einfach im Rahmen des Projekts zu bauen. Dazu gibt es einige Muster, die hierbei An­wendung finden können:

• Die Dienste können idealer­weise aus der Kom­po­sition von anderen, be­stehenden Diensten ge­bildet werden. In solch einem Fall sollte man sich über­legen, ob es noch andere potentielle Ver­braucher solch eines Dienstes gibt. In diesem Fall ist eine all­ge­meine Bereit­stel­lung und lang­fristig eine enge Inte­gra­tion in das passende System empfehlenswert.

Die Agilität birgt in sich die Gefahr, dass ver­meintlich kurz­lebige Lösungen „unsauber“ um­ge­setzt werden, die da­nach mehr und mehr zu einem Problem werden können. Es ist also wichtig, sich auch über die länger­fristigen Aspekte früh­zeitig Ged­anken zu machen.

• Falls die Anforderungen an die Daten­aktualität und -verwendung dies zu­lassen, kann ein fehlender Dienst über eine asynchrone Daten­bereit­stellung kom­pen­siert werden. Dies kann bei­spiels­weise für Stamm­daten ge­nutzt werden, die sich selten ändern. Hier wäre eine Daten­ver­sorgung für eine lesende Kom­po­nente ein gang­barer Weg.
• Die schlechteste aller Mög­lich­keiten soll auch nicht un­ge­nannt bleiben. Dies wäre die schlichte Re­imple­men­tie­rung der fehlenden Funk­tio­na­lität. Damit bekommt man eine Dupli­zierung in die Systeme die absolut un­er­wünscht ist. Im besten Fall hat dies dop­pelten Auf­wand bei einer Anpassung zur Folge. Im schlechte­sten Fall laufen die beiden Im­ple­men­tie­rungen aus­einander und pro­du­zieren ver­schiedene Er­geb­nisse – fach­lich ge­sehen ein GAU. Leider ist das trotz­dem immer wieder einmal zu beobachten.
  
  

Erfolgsfaktor: Technische Anbindung von Diensten

Dass ein Dienst in einer C-Kom­po­nente vor­handen ist heißt noch nicht, dass er auch von einer A-Kom­po­nente an­ge­spro­chen werden kann. Hierzu müssen unter Um­ständen auch noch tech­nische Hürden über­wunden werden.

Auch wenn es prinzipiell tech­nische Mög­lich­keiten gibt, dass bei­spiels­weise Cobol-Pro­gram­me auf dem Host mit Programmen in C# oder Java auf virtuellen Servern kom­muni­zieren, so muss diese theo­re­tische Mög­lich­keit in einer kon­kreten Situa­tion doch auch ein­ge­setzt werden.

In der Regel wird hier eine Middle­ware zum Einsatz kommen, welche diese Hürde über­windet. Aber schon alleine die Einführung solch einer Middle­ware kann die Aus­maße eines C-Pro­jekts annehmen.

Auch C-Komponenten können mehr A werden

Wenn man in mehreren Ge­schwin­dig­kei­ten unter­wegs ist und Kop­plungen zwischen den ver­schie­denen Teilen exis­tieren, dann ergibt es sich mehr oder weniger zwangs­läufig, dass sich die ver­schiedenen Ge­schwin­dig­keiten be­ein­flussen:

• Die A-Komponenten werden etwas gebremst.
• Die C-Komponenten werden be­schleunigt.

Insbesondere der zweite Punkt kann ein durch­aus ge­wünsch­ter Neben­effekt sein. Durch die An­regungen aus den A-Kom­po­nenten werden die ein­ge­fahrenen Vor­gehens­weisen der C-Kom­po­nenten hinter­fragt und auf den Prüf­stand gestellt:

• Wer braucht die einzelnen Arte­fakte, die er­stellt werden müssen?
• Wann und in welcher Qualität müssen die ein­zel­nen Arte­fakte vorliegen?
• Warum müssen die Er­geb­nisse fest ge­taktet zu lange vorher defi­nier­ten Release-Terminen ein­ge­führt werden?
  
  

IT-Governance und regulatorische Anforderungen

IT-Governance und regu­la­to­rische An­forde­rungen werden von der Soft­ware-Ent­wick­lung oft als starre, von außen kom­mende Regel­werke em­pfun­den. Die eigent­lich in­hären­ten und sinn­vollen Ziele sind da­hinter verborgen:

• Risikominimierung
• Sicherheit
• Nachvollziehbarkeit

Diese haben sich im Laufe der Zeit zu Re­gu­la­rien ver­festigt, die unter dem da­maligen Stand der Kunst an­ge­messen waren. Jetzt müssen sie mit der neuen Situation auf den Prüf­stand ge­stellt und neu be­wertet werden.

Ausgehend von den gleiche Zielen kommen wir mit den ver­schie­den­en Vor­gehens­modellen zu unter­schied­lichen Vor­gaben für die Pro­jekte. Keines dieser Ziele wird auf­ge­geben. Nur die Um­setzung wird unter­schiedlich ausfallen.

Beispielsweise kann das Ziel der Nach­voll­zieh­bar­keit heute auf andere technische Rahmen­be­dingungen aufsetzen als die klassischen Projekte vor 30 Jahren:

• Die Anforderungen sind ver­si­o­niert und kon­se­quent in einem Re­quire­ments-En­gi­neering-Tool abgelegt.
• Die Design-Entscheidungen werden in einem Wiki ab­ge­legt – natürl­ich ver­sio­niert. Dabei wird je­weils der Be­zug zu den An­for­de­rungen mit dokumentiert.
• Der Source-Code ist unter Ver­sions­kon­trol­le. Bei Ände­rungen wird über Kom­mentare der Be­zug zu den An­forde­rungen und Design-Ent­schei­dungen hergestellt.
• Eine konsequente und auto­matische Num­merie­rung der Build-Arte­fakte im Build- und Deploy­ment-System sorgt dafür, dass immer genau fest­ge­stellt werden kann, welcher Stand der Soft­ware in jeder Um­ge­bung vor­handen ist.

Unter solchen Be­trach­tungen ver­lieren die Papier-Do­ku­men­te, die als Artefakte in klas­sischen Vor­gehens­model­len im Zen­trum stehen, ihre Be­deutung ohne dass die damit ver­bun­den­en Ziele auf­ge­geben oder ver­ändert würden.

Erfolgsfaktor: Vorgehensmodell für A und C

Ein Erfolgs­faktor ist das Vor­han­den­sein von Vor­gehens­model­len für die beiden Vor­gehens­weisen. In der Regel findet man nur ein starres, klas­sisches Vor­gehens­modell vor, das ver­bindlich für alle ein­ge­setzt werden muss. Hier fehlt es oft an der er­forder­lichen Flexibilität.

Ideal ist es, wenn es nur ein flexibles Vor­gehens­modell gibt, das an die Er­forder­nis­se des je­weiligen Pro­jektes an­ge­passt werden kann. Analog zu einem stufen­losen Schalt­ge­triebe wird dabei zu Pro­jekt­beginn die ge­wünschte Ausprägung des Pro­jektes fest­gelegt:

• Welche Artefakte werden erstellt?
• Wann sind die Artefakte ab­zu­liefern?
• Welche Quality-Gates müssen durch­laufen werden?
• Was sind die Qualitäts­an­for­de­rungen an den je­weiligen Quality-Gates?

Wenn die Regularien es er­lauben über ge­eig­nete Def­ini­ti­onen auf der einen Seite ein Pro­jekt­vor­gehen nach Wasser­fall oder V-Modell und auf der anderen Seite ein Projekt­vorgehen nach Scrum oder Kanban ein­zu­stellen, dann sind die Regu­la­rien in der agilen Welt an­ge­kom­men und eine gute Grund­lage für die Soft­ware-Ent­wicklung.

Erfolgsfaktor: Mentalität der Teams

Wenn wir in einem Unter­nehmen zwei Ge­schwin­dig­keiten haben, dann wird sich dies auch in mehreren Teams mani­festie­ren. Ein Schnitt, bei dem in einem Team zwei ver­schiedene Ge­schwindig­keiten ein­ge­setzt werden, bringt eine neue Komplexität mit sich und wird hier erst einmal nicht weiter betrachtet.

Damit ist es wichtig, dass die Teams die passende Mentalität mitbringen:

• Die Mitglieder der A-Teams sind daran in­te­res­siert, Neues aus­zu­pro­bieren und sich schnell in neue Techno­lo­gien ein­zu­arbeiten.
• Die Mitglieder der C-Teams sind daran in­te­res­siert, das Be­währ­te – App­li­ka­tionen und Vor­gehens­weisen – zu er­halten und gegen un­nötige Ver­ände­run­gen zu schützen.

Wenn jemand in einem Team ein­ge­setzt wird, das seiner Men­ta­li­tät nicht ent­spricht führt das zu Frus­tra­tion und De­moti­va­tion und ist einer posi­tiven Arbeits­atmosphäre ab­träg­lich. Also müssen die Teams so zusam­menge­stellt sein, dass die Menta­li­tät der Team­mit­glieder dem je­weili­gen Vor­gehens­modell entspricht.

Ein entscheidender Erfolgsfaktor für Two-Speed-IT ist eine Exit-Strategie

Two-Speed-IT kann ein Mittel sein, kurz­fristig mehr Agi­li­tät in eine Orga­ni­sa­tion mit einem eta­blier­ten, klas­sischen Soft­ware-Ent­wick­lungs­modell zu bringen. Mittel- bis lang­fristig kann ein Unter­nehmen es sich nicht leisten, un­be­weg­liche Unter­nehmens-IT zu unter­halten. Der Markt ist und bleibt in den meisten Branchen in Be­wegung. Dem muss die IT ge­recht werden.

Deshalb ist es wichtig, sich dessen be­wusst zu sein und früh­zeitig in Rich­tung einer Exit-Strate­gie für die Two-​Speed-​IT zu steuern. Dabei ist der Aus­weg nicht der Erhalt der Vor­gehens­weisen der C-Kom­po­nen­ten, son­dern die­jenige der A-Kom­po­nen­ten. Damit kann man über kurz oder lang mit der ge­sam­ten IT in der heute immer schnell­lebi­geren Welt ankommen.

Dr. Gerd Neugebauer - ist Senior IT-Architekt mit Leib und Seele – und davon gibt es nicht wenig. Er ist insbesondere auch im Web- und Portal-Umfeld seit vielen Jahren tätig. Aus Erfahrungen mit vielen Kundenprojekten heraus gespeist ist sein Interesse an Vorgehensmodellen für die Durchführung von IT-Projekten.

Referenzen