Mit dem Stichwort Bimodale IT (Gartner) [1] beziehungsweise Two-Speed IT (McKinsey) [2, 3, 4] 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.
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:
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:
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“.
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.
In früheren Zeiten wurden alleinstehende IT-Systeme gebaut und betrieben. Für unsere Kunden haben wir noch Anfang des Jahrtausends solche Solitäre gebaut.
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.
In der obigen Abbildung wird versucht, dies im Kontext einer Two-Speed-IT zu visualisieren. Einerseits sind hier Komponenten und ihre Vernetzung über Aufrufbeziehungen zu sehen. Andererseits sind die Komponenten entsprechend ihres Entwicklungsmodells klassifiziert. Dabei stehen die Komponenten A1 und A2 für Applikationen, die nach einem agilen Vorgehensmodell (A) weiterentwickelt werden. C1, C2 und C2 sind Komponenten mit einem klassischen Vorgehensmodell (C).
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 C-Komponenten bereits in einer technisch verwertbaren Form zur Verfügung. Alternativ können Wege gesucht werden, um fehlende Dienste zu kompensieren.
Die Entwicklung ist nicht mit der Einführung abgeschlossen. Das ist nur der Startpunkt für die Weiterentwicklung und Pflege eines Systems.
Wenn zu Beginn das A-Projekt die benötigten Dienste bekommen oder sich Abhilfe geschaffen hat, so verstummt damit nicht der Ruf nach neuen oder überarbeiteten Diensten.
Das Business – beispielsweise in Banken und Versicherungen – will und muss neue Produkte einführen. Dabei kommt man über kurz oder lang nicht an den C-Applikationen der Kernsysteme vorbei. Dort werden neue Dienste benötigt. Durch die Trägheit der C-Projekte kann dies nicht in der Geschwindigkeit geschehen, die von den A-Projekten gewünscht wäre.
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 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.
Dass ein Dienst in einer C-Komponente vorhanden ist heißt noch nicht, dass er auch von einer A-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. Aber schon alleine die Einführung solch einer Middleware kann die Ausmaße eines C-Projekts annehmen.
Wenn man in mehreren Geschwindigkeiten unterwegs ist und Kopplungen zwischen den verschiedenen Teilen existieren, dann ergibt es sich mehr oder weniger zwangsläufig, dass sich die verschiedenen Geschwindigkeiten beeinflussen:
Insbesondere der zweite Punkt kann ein durchaus gewünschter Nebeneffekt sein. Durch die Anregungen aus den A-Komponenten werden die eingefahrenen Vorgehensweisen der C-Komponenten hinterfragt und auf den Prüfstand gestellt:
IT-Governance und regulatorische Anforderungen werden von der Software-Entwicklung oft als starre, von außen kommende Regelwerke empfunden. Die eigentlich inhärenten und sinnvollen Ziele sind dahinter verborgen:
Diese haben sich im Laufe der Zeit zu Regularien verfestigt, die unter dem damaligen Stand der Kunst angemessen waren. Jetzt müssen sie mit der neuen Situation auf den Prüfstand gestellt und neu bewertet werden.
Ausgehend von den gleiche Zielen kommen wir mit den verschiedenen Vorgehensmodellen zu unterschiedlichen Vorgaben für die Projekte. Keines dieser Ziele wird aufgegeben. Nur die Umsetzung wird unterschiedlich ausfallen.
Beispielsweise kann das Ziel der Nachvollziehbarkeit heute auf andere technische Rahmenbedingungen aufsetzen als die klassischen Projekte vor 30 Jahren:
Unter solchen Betrachtungen verlieren die Papier-Dokumente, die als Artefakte in klassischen Vorgehensmodellen im Zentrum stehen, ihre Bedeutung ohne dass die damit verbundenen Ziele aufgegeben oder verändert würden.
Ein Erfolgsfaktor ist das Vorhandensein von Vorgehensmodellen für die beiden Vorgehensweisen. In der Regel findet man nur ein starres, klassisches Vorgehensmodell vor, das verbindlich für alle eingesetzt werden muss. Hier fehlt es oft an der erforderlichen Flexibilität.
Ideal ist es, wenn es nur ein flexibles Vorgehensmodell gibt, das an die Erfordernisse des jeweiligen Projektes angepasst werden kann. Analog zu einem stufenlosen Schaltgetriebe wird dabei zu Projektbeginn die gewünschte Ausprägung des Projektes festgelegt:
Wenn die Regularien es erlauben über geeignete Definitionen auf der einen Seite ein Projektvorgehen nach Wasserfall oder V-Modell und auf der anderen Seite ein Projektvorgehen nach Scrum oder Kanban einzustellen, dann sind die Regularien in der agilen Welt angekommen und eine gute Grundlage für die Software-Entwicklung.
Wenn wir in einem Unternehmen zwei Geschwindigkeiten haben, dann wird sich dies auch in mehreren Teams manifestieren. Ein Schnitt, bei dem in einem Team zwei verschiedene Geschwindigkeiten eingesetzt 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:
Wenn jemand in einem Team eingesetzt wird, das seiner Mentalität nicht entspricht führt das zu Frustration und Demotivation und ist einer positiven Arbeitsatmosphäre abträglich. Also müssen die Teams so zusammengestellt sein, dass die Mentalität der Teammitglieder dem jeweiligen Vorgehensmodell entspricht.
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. Dabei ist der Ausweg nicht der Erhalt der Vorgehensweisen der C-Komponenten, sondern diejenige der A-Komponenten. Damit kann man über kurz oder lang mit der gesamten IT in der heute immer schnelllebigeren Welt ankommen.