IT-Organisation und VorgehenLesezeit 5 Minuten

Zwei Geschwindigkeiten in der IT – und wie Sie wieder herauskommen

Die bimodale IT hat einen schlechten Ruf, und zwar zu Recht. Als Dauerzustand spaltet sie die Organisation. Als Übergang mit festem Ausstiegspunkt ist sie eines der wenigen Mittel, die in einem gewachsenen Haus wirklich funktionieren.

Als Gartner den Begriff prägte, war die Idee einleuchtend: Die Kernsysteme laufen weiter in ihrem bewährten, sorgfältigen Takt, während daneben eine zweite IT entsteht, die schnell liefert. Zwei Modi, ein Unternehmen.

Die Kritik kam schnell und hat sich bestätigt. Wo die Trennung dauerhaft wurde, entstand eine Zwei-Klassen-IT: hier die interessanten Projekte, dort die Wartung. Die besten Leute wanderten in den schnellen Teil ab, der langsame Teil wurde zur Restmenge, und die Schnittstelle zwischen beiden wurde zum Ort, an dem Vorhaben liegen blieben.

Trotzdem halte ich den pauschalen Abgesang für falsch. Denn das Problem, auf das die bimodale IT antwortet, ist real und löst sich nicht dadurch auf, dass man den Begriff vermeidet.

Ich habe beide Seiten dieser Trennung verantwortet. Bei einem IT-Dienstleister der Versicherungswirtschaft lagen die Web- und Integrationsanwendungen in meinem Bereich – also genau der schnelle Teil, der neben den Bestandssystemen arbeitet, mit eigenem Java-Betrieb und eigener Auslieferungsstrecke. In einem Rechtsschutzversicherer habe ich später an der Gegenfrage gearbeitet: wie Innovationsthemen so entstehen, dass sie im Regelbetrieb tatsächlich ankommen und nicht als Insel enden.

Das Problem bleibt bestehen

Kernsysteme folgen einer eigenen Logik, und das aus gutem Grund:

• Die Funktion muss verfügbar sein, nicht nur meistens.
• Fehler sind teuer, manchmal aufsichtsrechtlich relevant.
• Nachvollziehbarkeit und Dokumentation sind keine Kür.

Im Geschäft gelten andere Prioritäten. Produkte kommen kurzfristig an den Markt und verschwinden ebenso schnell wieder. Time-to-Market entscheidet. Der Zuschnitt ist zu Beginn vage und muss mitwachsen. Für ein Feature mit einem halben Jahr Lebensdauer ist eine vollständige Dokumentation keine sinnvolle Investition.

Ein etabliertes Haus kann diese beiden Welten nicht mit einem Beschluss zusammenführen. Wer es versucht, bekommt entweder ein Kernsystem, das unter dem Tempo bricht, oder eine Produktentwicklung, die im Freigabeprozess erstickt. Die Übergangsphase ist also nicht die Schwäche des Ansatzes, sie ist der Punkt.

Drei Bedingungen, ohne die es nicht trägt

1. Die Systemlandschaft muss schneidbar sein

Zwei Modi funktionieren nur, wenn sich die Landschaft in hinreichend unabhängige Teile zerlegen lässt. Je enger Systeme gekoppelt sind, desto weniger lässt sich der eine Teil anders behandeln als der andere.

Sauber wird es dort, wo ein neues Produkt vollständig separiert abgewickelt werden kann – kleine Zielgruppe, zeitlich begrenzt, klare Grenzen. Dann beeinflussen sich die Vorgehensmodelle nicht. In der Praxis sind die Übergänge fließend, und die Trennschärfe ist nur graduell zu haben. Genau deshalb ist der Schnitt eine Entwurfsentscheidung, die man bewusst trifft, und keine, die sich von selbst ergibt.

2. Die schnelle Seite braucht Dienste, keine Datenkopien

Eine schnell gebaute Komponente ist auf Backend-Dienste angewiesen. Stehen die bereit, ist alles gut. Fehlen sie, gibt es drei Wege – in dieser Reihenfolge:

• Komponieren. Den fehlenden Dienst aus vorhandenen zusammensetzen. Lohnt sich besonders, wenn absehbar weitere Verbraucher dazukommen – dann gleich allgemein bereitstellen.
• Asynchron versorgen. Wenn die Anforderungen an die Datenaktualität es zulassen, etwa bei Stammdaten, die sich selten ändern, reicht eine lesende Datenversorgung.
• Nachbauen. Die schlechteste Variante. Sie erzeugt eine Dublette der Fachlogik. Im besten Fall kostet jede Änderung doppelt. Im schlechtesten laufen beide Implementierungen auseinander und liefern unterschiedliche Ergebnisse – fachlich ein GAU. Zu beobachten ist es trotzdem immer wieder.

Hier liegt die eigentliche Gefahr der schnellen Seite: Was als kurzlebige Lösung gedacht war, bleibt. Deshalb gehört zu jeder Kompensation von Anfang an die Frage, was mit ihr passiert, wenn sie das Quartal überlebt.

3. Technisch muss die Verbindung wirklich stehen

Dass ein Dienst existiert, heißt nicht, dass eine andere Komponente ihn ansprechen kann. Dass ein Cobol-Programm auf dem Host prinzipiell mit einem Java-Service auf virtuellen Servern sprechen kann, hilft im konkreten Fall wenig, solange niemand diesen Weg gebaut und betrieben hat. In der Regel übernimmt eine Middleware diese Aufgabe – und sie ist Teil des Vorhabens, nicht Voraussetzung, die man stillschweigend annimmt.

Der Punkt, an dem die meisten Programme scheitern

Zwei Geschwindigkeiten sind ein Mittel, um kurzfristig Beweglichkeit in ein Haus mit etabliertem klassischem Vorgehen zu bringen. Mittelfristig kann sich kein Unternehmen eine unbewegliche IT leisten; der Markt bleibt in Bewegung, und die IT muss dem gerecht werden.

Deshalb entscheidet eine Frage über den Erfolg, und sie gehört in die Vorlage für den Lenkungsausschuss, nicht in eine spätere Phase: Woran erkennen wir, dass wir den Zweitakt nicht mehr brauchen – und wer entscheidet das?

Ohne diese Antwort passiert verlässlich dasselbe. Der schnelle Teil wird zur Dauereinrichtung, der langsame zum Reservat, und nach drei Jahren steht die Organisation vor derselben Transformation wie zu Beginn, nur mit einer zusätzlichen Systemlandschaft, die ebenfalls migriert werden will.

Eine Ausstiegsstrategie muss nicht ausgefeilt sein. Sie braucht einen Zielzustand, zwei oder drei beobachtbare Kriterien und einen Termin, an dem jemand ernsthaft hinsieht. Das ist wenig verlangt für den Unterschied zwischen einem Übergang und einem Dauerzustand.

Überarbeitete Fassung eines Beitrags aus dem Jahr 2022, um die inzwischen belegte Kritik am bimodalen Modell und die Frage der Ausstiegsstrategie ergänzt.

← Alle Beiträge