What’s in a Name: Bimodale IT

Dr. Gernot Starke

„Bimodal is the practice of managing two separate but coherent styles of work: one focused on predictability; the other on exploration. Mode 1 is optimized for areas that are more predictable and well-understood. It focuses on exploiting what is known, while renovating the legacy environment into a state that is fit for a digital world. Mode 2 is exploratory, experimenting to solve new problems and optimized for areas of uncertainty.“

Bedeutet im Klartext also:

1. Gewachsene (Legacy-) Systeme bleiben in Modus 1 bei den etablierten Entwicklungs- und Betriebsprozessen, oftmals mit 2–4 Releases pro Jahr.
2. Neue Systeme, mit deren Hilfe Unternehmen neue Märkte oder Geschäftsfelder adressieren, entwickeln sie im (agilen) Modus 2. Hier geht es um Innovationen, frühzeitiges Feedback von Anwendern und Kunden sowie schnelle Time-to-market.

Als Metapher für bimodale IT gelten zwei Typen von Schiffen (siehe Abbildung 1): Einerseits die großen, stabilen aber auch extrem schwerfälligen Riesen von Modus 1, die historisch gewachsenen Legacy-Anwendungen.

Auf der anderen Seite steht Modus 2 für moderne, innovative Systeme, neue Märkte oder digitale Transformation. In der Analogie sind dies wendige Schnellboote, die Stabilität und Robustheit gegen Agilität tauschen.

Modus 1: Bestandssysteme

Systeme dieser Art benötigen Stabilität und Robustheit. Bei diesen so genannten Systems of Record (SoR [1]) sollten niemals Fehler auftreten, die negative Konsequenzen für die Gesamtorganisation nach sich ziehen könnten.

Diese Systeme verwalten wichtige und kritische Daten, die hohen Wert für die Organisation besitzen (etwa Kunden-, Vertrags-, Auftrags- oder Kontodaten).

Da es in vielen Unternehmen diese Systeme bereits seit langer Zeit gibt, unterliegen sie oftmals etablierten Entwicklungs-, Rollout- und Betriebsprozessen, bei denen Agilität und feedbackintensives Vorgehen nur marginal praktiziert werden. Gartner empfiehlt in diesem Zusammenhang [1] ausdrücklich Wasserfall-Prozesse als geeignete Vorgehensweise. Wer hierbei an Mainframe denkt, hat sicher in vielen Fällen Recht.

Modus 2: Front-Office oder „Systems of Engagement“

Dies sind interaktive Anwendungen oder Apps, über die Anwender oder Kunden Dienste des Unternehmens nutzen. Oftmals sind das Systeme, die grafische Schnittstellen per Browser oder über mobile Endgeräte bereitstellen.

Entwicklung und Betrieb dieser Systems of Engagement (SoE) [2] sollten auf Anpassungsfähigkeit und kurzfristige Reaktion auf Kundenwünsche optimiert werden: Iterative Entwicklung, kurze Feedbackzyklen sowie weitgehend automatisierte Test- und Deploymentprozesse bestimmen das Vorgehen.

SoE-Anwendungen unterstützen innovative Geschäftsfelder mit Hilfe neuer Technologien, beinhalten daher erhebliche wirtschaftliche und technische Unwägbarkeiten.

Konkretes Vorgehen bleibt offen

Die Erschaffer des Begriffes bleiben leider bezüglich des konkreten Vorgehens in Unternehmen einige Anworten schuldig: Sollen Organisationen ihre bestehenden IT-Teams jetzt aufteilen, oder besser für die Modus-2-Systeme neue Personen einstellen? Oder vielleicht direkt ein Tochterunternehmen für die innovativen System gründen oder ein passendes Startup einkaufen?

Hier ist Change Management gefragt: Wie eine gewachsene IT-Organisation in eine bimodale Struktur zu transformieren ist, bleibt völlig offen, möglicherweise weil erfolgreiches Change-Management eine schwierige und hochgradig organisationsspezifische Aufgabe darstellt.

Erlauben Sie mir einige kritische Bemerkungen zu dieser Zweiteilung von IT-Organisationen:

Dilemma

Bei einer Einführung von zwei Geschwindigkeiten oder zwei Modi befürchte ich eine ganze Reihe von Risiken:

1. Bimodale IT zementiert eine Zweiklassengesellschaft und die Bildung von Wissens- und Kompetenz-Silos.
2. Bimodale IT geht von der fundamental falschen (!!) Annahme aus, dass „Langsamkeit“ (Modus 1) höhere Qualität, Stabilität und Verlässlichkeit liefert, dass also agile Entwicklung (Modus 2) Produkte geringerer Qualität liefert.
3. Bimodale IT sieht die Systeme aus Modus 2 in hohem Maße unabhängig von den (etablierten) Systemen aus Modus 1. Das Gegenteil ist der Fall: Jede auch noch so kleine moderne Front-End-Anwendung benötigt Daten aus bestehenden Systemen. Die Schnellboote sind immer (!!) an die Supertanker gekoppelt.
4. Bimodale IT erklärt die bisherigen IT-Prozesse als unfähig, eine digitale Transformation zu unterstützen: Ich interpretiere das als Offenbarungseid.

Diese Risiken möchte ich etwas aufschlüsseln:

Silos – in Stein gemeisselt

Wenn Unternehmen auf bimodale IT setzen, zementieren sie damit eine Zwei-Klassen-Gesellschaft, sowohl in Entwicklung wie auch im Betrieb von Systemen.

Damit riskieren Unternehmen eine „Wir gegen Die“-Mentalität innerhalb der Entwicklung: Statt für die Organisation an einem Strang in dieselbe Richtung zu ziehen, werden die beiden „Modi“ jeweils ihre eigenen Interessen verfolgen und in Fehler- und Krisenfällen jeweils mit dem Zeigefinger auf die „anderen“ deuten.

Weiterhin halte ich den agilen Modus 2 für die weitaus attraktivere Variante für die beteiligten Personen: Insbesondere engagierte und gut qualifizierte Menschen werden meiner Einschätzung nach kurz- und mittelfristig alle in Modus 2 arbeiten wollen, was einen Brain-Drain in den wichtigen und unternehmenskritischen Backend-Systemen provozieren könnte.

Langsamkeit gefährdet Qualität

Meine These – und damit befinde ich mich in bester Gesellschaft (u.a. Fowler, Humble):

Agile Entwicklung liefert höhere Qualität als Wasserfall-Prozesse.

Bestandssysteme, die hochgradig kritisch für Unternehmen sind, im (Wasserfall-)Modus 1 entwickeln und betreiben zu lassen, halte ich der aktuellen Zeit für nicht mehr angemessen. Agile Methoden haben bei vielen Gelegenheiten bewiesen, dass sie sowohl für kritische wie auch für große Systeme taugen!

Mir ist durchaus bewusst, dass die Einführung von Agile- und Lean-Methoden langwierig und aufwändig sein kann – aber die Ergebnisse werden diesen Aufwand definitiv rechtfertigen.

Schnellboot an Tanker gefesselt

Um nochmals die Analogie der Schiffe zu strapazieren: Nach meiner Erfahrung mit vielen Organisationen hängen praktisch alle modernen, innovativen Front-Office-Systeme (SoE, Modus 2) direkt von Daten oder Prozessen in Back-End-Systemen (Modus 1) ab, d.h. die Schnellboote sind an die Riesenschiffe gefesselt (siehe Abbildung 2).

Diese Abhängigkeiten beziehen sich sowohl auf Entwicklungs-, Rollout- als auch Betriebsprozesse. Zwischen den verschiedenen Systemen besteht also Koordinations- und Klärungsbedarf auf verschiedenen Ebenen. Eine starke organisatorische Trennung, wie bimodale IT sie vorsieht, provoziert hier dramatische Reibungsverluste.

Mir persönlich sind Fälle bekannt, in denen diese Friktionen zwischen Tankern und Schnellbooten zu massiver Unzufriedenheit und letztlich zu Kündigungen innerhalb der Modus-2-Teams geführt haben, obwohl vordergründig die Arbeitsbedingungen der agilen Teams gut aussahen. O-Ton beteiligter Personen: „Wir leisten hier gute Arbeit – aber werden durch die zwei Geschwindigkeiten systematisch ausgebremst.“

Offenbarungseid

Wenn IT-Organisationen die Transition von Entwicklung und Betrieb in Richtung agil nicht schaffen, also ihre Liefer- und Reaktionsgeschwindigkeit nicht steigern können, kommt das aus meiner Sicht dem Offenbarungseid gleich: Das IT-Management legt damit die eigene Unfähigkeit zum konstruktiven Wandel offen.

Sicher mag es Fälle geben, in denen langfristige Verträge oder verkrustete Strukturen die Einführung neuer Arbeitsprozesse bremsen – aber strategisch sollten Unternehmen immer (praktisch ohne Ausnahme) in der Lage sein, ihre internen Prozesse an aktuelle Gegebenheiten anzupassen. Verkrustete, unflexible Prozesse als „Modus 1“ zu bezeichnen, und mit neuen Modus-2-Teams sozusagen neu zu starten, ist meiner Ansicht übermäßig optimistisch: Wenn ich mit einem Teil des Unternehmens (Modus 1) nicht agil arbeiten kann, warum sollte mir das mit einem anderen (Modus 2) plötzlich so viel besser gelingen? Bitte gestatten Sie mir Zweifel an dieser Idee.

Aber…

Gesetzt den Fall, Ihre IT-Organisation steckt bezüglich agiler Methoden, DevOps und Continous Delivery noch in den Kinderschuhen – aber Sie möchten oder müssen trotzdem die Herausforderung von digitaler Transformation und hochdynamischen Märkten meistern: Ihre bestehenden Entwicklungsprozesse werden das nicht schaffen, was sollen Sie tun?

In dieser fatalen Zwickmühle bleibt Ihnen möglicherweise nichts anderes übrig, als eine IT der zwei Geschwindigkeiten als Übergangslösung einzuführen: Selbst wenn Sie in der Entwicklung relativ schnell agile Methoden einführen könnten – in Management, Rollout und Betrieb kann das zu einem langjährigen Unterfangen werden… und derart lange lassen Ihnen dynamische Märkte kaum Zeit.

Daher: Trotz vieler gravierender Probleme mit bimodaler IT werden hoher Marktdruck und steigende Kundenansprüche eine zumindest zeitweise Zweiteilung der IT praktisch erzwingen.

Lassen Sie auf keinen Fall eine Übergangslösung zum strategischen Ziel Ihrer IT mutieren!

Fazit

Bimodale IT, die Differenzierung von Entwicklungs- und Betriebsprozessen in zwei Modi, birgt jede Menge Risiken und Unwägbarkeiten. Modernes IT-Management sollte so bald wie möglich die Transition zu dynamischen und feedback-intensiven Prozessen auf allen Ebenen angehen. Das macht die lästige Frage „Wie schaffen wir die Transition zu bimodaler IT?“ komplett obsolet.

Versuchen Sie lieber, ohne die Risiken unterschiedlicher Vorgehensweisen zu angemessener Liefergeschwindigkeit und agileren Architekturen zu kommen: DevOps und ContinousDelivery funktionieren prima auch ohne Trennung verschiedener Modi! Trauen Sie sich dabei (endlich mal) an Ihre etablierten Backend-Systeme, denn die werden von einer Verschlankung und Agilisierung ganz ungemein profitieren!

Quellen und weitere Infos

• Das Gartner IT Glossary definiert den Begriff, ohne weitere Erläuterung.
• Bossert, Ip und Laartz von McKinsey sagen „IT der zwei Geschwindigkeiten“ dazu, ihre These lautet „Delivering an enriched customer experience requires a new digital architecture running alongside legacy systems.“
• Martin Fowler argumentiert strikt gegen bimodale IT, sondern schlägt statt dessen eine Differenzierung zwischen Utility-IT und Strategic IT vor. Seiner Argumentation kann ich mich in wesentlichen Teilen anschliessen.
• Die Analysten von Forrester Research sprechen sich deutlich gegen bimodale Organisation der IT aus, und werfen dem Ansatz erhöhte Komplexität und schlechte Kundenorientierung vor.
• @Cloud_Opinion wettern auf Twitter gegen bimodal: Es sei die Verneinung der lernenden Organisation. Wohl gesagt, finde ich.
• Jez Humble beschreibt einige aus seiner Sicht fehlerhaften Annahmen über bimodale IT, The Flaw at the Heart of Bimodel IT.
• Oliver Laitenberger vom CIO-Magazin über „Fluch oder Segen“ bimodaler IT
• H. Vaske im CIO-Magazin beschreibt Forresters Abgesang auf die bimodale IT, nennt dabei insbesondere steigende Komplexität als Hinderungsgrund.

Danke

Danke an Oliver Wolf (@owolf), Stefan Tilkov (@stilkov) sowie Phillip Ghadir für ihre konstruktiven Anmerkungen zu frühen Versionen dieses Posts und Claudia Rauch für ihre unermüdlichen 2readable Transformationen meiner holprigen Satzkonstrukte. Die Abbildungen basieren auf Clips aus Openclipart.