Mit dem Stichwort Bimodale IT (Gartner) wurde eine Diskussion in der IT-Welt gestartet, wie man verschiedene Entwicklungsparadigmen in einem Unternehmen verwenden kann. Offensichtlich hat das darin steckende Prinzip bei einigen Beteiligten den Kern getroffen und zu euphorischer Begeisterung aber auch zu empörter Ablehnung geführt.
Koexistenz von verschiedenen Entwicklungsgeschwindigkeiten
Mit dem Aufkommen der Popularität von agilen Software-Entwicklungsmodellen stellte sich die Frage, wie man diese mit einer gewachsenen Projektkultur verbinden kann. Die altehrwürdigen Kernsysteme sind geprägt von dem Streben nach Stabilität und Sicherheit:
- Die Funktionalität muss zur Verfügung stehen.
- Fehler sind kostspielig und müssen vermieden werden.
- Nachvollziehbarkeit und Dokumentation 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 verschwinden zum Teil auch ebenso schnell wieder. Das führt zu anderen Schwerpunkten bei der Wichtigkeit der Anforderungen:
- Time-to-Market ist essentiell, wenn man nicht vom Wettbewerber abgehängt werden will.
- Das Produkt – und die unterstützenden IT-Systeme – sind zum Entwicklungsbeginn nur vage definiert und müssen erst mitwachsen.
- Nachvollziehbarkeit und Dokumentation spielen für kurzlebige Software-Features eine untergeordnete Rolle.
Es ist in der Regel bei etablierten Firmen nicht möglich, die IT mit einem Schlag aus der „langsamen“ Welt der Kernsysteme in die „schnelle“ Welt der Frontend-Systeme zu transformieren. Damit sind auch gleich die zwei Bereiche genannt, die charakteristisch für die verschiedenen Geschwindigkeitsanforderungen stehen. Trotzdem sei bemerkt, dass diese Bereiche nicht zwangsweise auf diese Weise zugeordnet werden müssen. Auch Kernsysteme können agil und Frontend-System klassisch erstellt werden.
Es muss nun ein Weg gefunden werden, mit dieser Situation umzugehen. Ein Lösungsansatz dieses Dilemmas besteht darin, für die verschiedenen Bereiche unterschiedliche Vorgehensmodelle für die Software-Entwicklung vorzusehen. Diese Abkehr von einem uniformen Vorgehensmodell innerhalb eines Unternehmens führt zu einer „Two-Speed-IT“.
Erfolgsfaktor: Separierbarkeit der Komponenten nach Entwicklungsmodell
Ein Erfolgsfaktor für eine Two-Speed-IT ist eine Separierung der Systemlandschaft in mehrere möglichst unabhängige Teile. Diese können dann umso einfacher nach den beiden Paradigmen behandelt werden.
Wenn wir einen Schnitt der Systemlandschaft in agile und klassische Komponenten in Betracht ziehen, dann müssen die fachlichen Applikationen realisierbar sein, die unter Umständen mehrere solcher Komponenten der beiden Arten nutzen müssen. Dem gegenüber steht die Möglichkeit, vollständig unabhängige Applikationen nach jeweils eigenen Entwicklungsmodellen umzusetzen.
Ein Beispiel wäre in der Finanzbranche die Abwicklung eines neuen Produkts in einer eigenen Applikation. Das bedeutet aber auch, dass der gesamte Prozess der Abwicklung separiert wird. Das kann beispielsweise dann sinnvoll sein, wenn die Zielgruppe klein und das Produkt zeitlich begrenzt ist. Da in diesem Fall die Grenzen klar gezogen sind, beeinflussen sich die Entwicklungsmodelle nicht.
In der freien Wildbahn sind die Übergänge natürlich fließend, sodass auch die Separierbarkeit nur graduell möglich wird. Je enger die Kopplung der verschiedenen Systeme ist, desto schwieriger wird ein Vorgehen mit unterschiedlichen Entwicklungsmodellen.
IT ist heute vernetzt
In früheren Zeiten wurden alleinstehende IT-Systeme gebaut und betrieben.
Heute findet man das kaum noch. Die Systeme stehen nicht mehr für sich alleine, sondern sind vernetzt. Nur im Verbund kommen alle Aspekte des fachlichen und technischen Know-hows des Geschäfts zum Tragen. Der Wert der Systeme für ein Unternehmen wandert zunehmend in die Vernetzung. Mehrfache Datenpflege und potentielle Inkonsistenzen werden vermieden. Hierdurch lassen sich dann auch verborgene Beziehungen zwischen den unterschiedlichen Daten aufspüren und ausnutzen.
Die einzelnen Komponenten erhalten Aufgaben, die nur sie durchführen. War es vormals üblich, querschnittliche Aufgaben wie beispielsweise eine Kundenverwaltung in den diversen System separat zu halten, so wird diese Aufgabe nun einer zentralen Komponente übertragen. Die anderen Komponente benutzen jetzt deren Schnittstellen, ohne die Funktionalität zu duplizieren.
Erfolgsfaktor: Dienste für eine Two-Speed-IT
Dienste spielen in einer modernen Systemlandschaft eine zentrale Rolle. Schon lange zieht die „service-oriented architecture“ (SOA) ihre Kreise durch die IT. Neuerdings werden einige Grundgedanken daraus weiter voran getrieben und finden sich zunehmend als Micro-Services in neu konzipierten Systemen wieder.
Für eine Two-Speed-IT müssen wir auch die beteiligten Dienste ins Auge fassen. Damit die schnelllebigen A-Komponenten entwickelt werden können, müssen die benötigten Backend-Dienste genutzt werden können. Im Idealfall stehen die Dienste der Komponenten bereits in einer technisch verwertbaren Form zur Verfügung. Alternativ können Wege gesucht werden, um fehlende Dienste zu kompensieren.
Erfolgsfaktor: Kompensation von fehlenden Diensten
Eine naheliegende Art, mit fehlenden Diensten umzugehen, ist es, diese einfach im Rahmen des Projekts zu bauen. Dazu gibt es einige Muster, die hierbei Anwendung finden können:
- Die Dienste können idealerweise aus der Komposition von anderen, bestehenden Diensten gebildet werden. In solch einem Fall sollte man sich überlegen, ob es noch andere potentielle Verbraucher solch eines Dienstes gibt. In diesem Fall ist eine allgemeine Bereitstellung und langfristig eine enge Integration in das passende System empfehlenswert.
Die Agilität birgt in sich die Gefahr, dass vermeintlich kurzlebige Lösungen „unsauber“ umgesetzt werden, die danach mehr und mehr zu einem Problem werden können. Es ist also wichtig, sich auch über die längerfristigen Aspekte frühzeitig Gedanken zu machen.
- Falls die Anforderungen an die Datenaktualität und -verwendung dies zulassen, kann ein fehlender Dienst über eine asynchrone Datenbereitstellung kompensiert werden. Dies kann beispielsweise für Stammdaten genutzt werden, die sich selten ändern. Hier wäre eine Datenversorgung für eine lesende Komponente ein gangbarer Weg.
- Die schlechteste aller Möglichkeiten soll auch nicht ungenannt bleiben. Dies wäre die schlichte Reimplementierung der fehlenden Funktionalität. Damit bekommt man eine Duplizierung in die Systeme die absolut unerwünscht ist. Im besten Fall hat dies doppelten Aufwand bei einer Anpassung zur Folge. Im schlechtesten Fall laufen die beiden Implementierungen auseinander und produzieren verschiedene Ergebnisse – fachlich gesehen ein GAU. Leider ist das trotzdem immer wieder einmal zu beobachten.
Erfolgsfaktor: Technische Anbindung von Diensten
Dass ein Dienst in einer Komponente vorhanden ist heißt noch nicht, dass er auch von einer anderen Komponente angesprochen werden kann. Hierzu müssen unter Umständen auch noch technische Hürden überwunden werden.
Auch wenn es prinzipiell technische Möglichkeiten gibt, dass beispielsweise Cobol-Programme auf dem Host mit Programmen in C# oder Java auf virtuellen Servern kommunizieren, so muss diese theoretische Möglichkeit in einer konkreten Situation doch auch eingesetzt werden.
In der Regel wird hier eine Middleware zum Einsatz kommen, welche diese Hürde überwindet.
Ein entscheidender Erfolgsfaktor für Two-Speed-IT ist eine Exit-Strategie
Two-Speed-IT kann ein Mittel sein, kurzfristig mehr Agilität in eine Organisation mit einem etablierten, klassischen Software-Entwicklungsmodell zu bringen. Mittel- bis langfristig kann ein Unternehmen es sich nicht leisten, unbewegliche Unternehmens-IT zu unterhalten. Der Markt ist und bleibt in den meisten Branchen in Bewegung. Dem muss die IT gerecht werden.
Deshalb ist es wichtig, sich dessen bewusst zu sein und frühzeitig in Richtung einer Exit-Strategie für die Two-Speed-IT zu steuern, damit kann man über kurz oder lang mit der gesamten IT in der heute immer schnelllebigeren Welt ankommt.