Mit dem Stichwort Bimodale IT (Gartner) 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:

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:

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.

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.

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 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.

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 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.

Erfolgsfaktor: Technische Anbindung von Diensten

Dass ein Dienst in einer Kom­po­nente vor­handen ist heißt noch nicht, dass er auch von einer anderen 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.

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, damit kann man über kurz oder lang mit der ge­sam­ten IT in der heute immer schnell­lebi­geren Welt ankommt.

Leave a Reply

Your email address will not be published. Required fields are marked *