Ich hatte für März 2020 einen Flug von München nach Berlin gebucht. Nichts Außergewöhnliches, ganz einfach eine Geschäftsreise, um einen Kunden zu besuchen. Aber dieses Mal sollte alles anders werden.
Ein paar Tage vor meinem geplanten Aufenthalt in Berlin hatte unser Kunde angesichts der Corona-Pandemie alle Mitarbeiter in Heimarbeit beordert. Da ich selbst damit auch nicht mehr vor Ort sein musste, stornierte ich meinen Flug für Sonntagabend (ich reise normalerweise am Vorabend eines Einsatzes an). Ich erhielt eine Bestätigungs-E-Mail, die mich über die Stornogebühren informierte. So weit, so gut und nichts Besonderes, wenn man einmal von der Tatsache absieht, dass die ganze Welt gerade dabei war, sich selbst angesichts einer noch nie dagewesenen Pandemie herunterzufahren.
Am Sonntag wurde die Sache dann allerdings seltsam. Ich erhielt eine weitere E-Mail von der Fluggesellschaft, in der ich dazu eingeladen wurde, für meinen Flug nach Berlin am Montag einzuchecken. Das klang irgendwie merkwürdig, daher stellte ich erste Nachforschungen an. Scheinbar hatte die Fluggesellschaft irgendwann den Flug am Sonntagabend, auf den ich ursprünglich gebucht gewesen war, gestrichen. Um kundenfreundlich zu sein, hatte man mich im Zuge dessen auf den nächsten verfügbaren Flug am Montag umgebucht. Das war natürlich völlig unnötig, da ich meine ursprüngliche Reservierung bereits storniert hatte.
Hinzu kommt, dass das Ganze unsinnig war, denn ich wäre zu einem Zeitpunkt in Berlin angekommen, zu dem ein wichtiges Meeting, das ich hätte mit moderieren sollen, bereits zu Ende gewesen wäre. Nun ja, wenigstens hatte die Fluggesellschaft versucht , hilfreich zu sein.
Ein bedauerlicher Einzelfall?
Man könnte jetzt annehmen, dass dies nur ein Einzelfall war. Ich bin als Informatiker schließlich darauf abonniert, Sonderfälle und Fehler zu finden. Ich denke, man kann mit ziemlicher Sicherheit sagen, dass sogar in dieser frühen Phase des beginnenden Lock-Down die IT-Systeme der Fluggesellschaft schon ziemlich durcheinander waren.
Mit Systemen, die massiv out of sync sind und einer großen Welle, die auf sie zurollt, scheinen viele Firmen Last von ihren Computersystemen nehmen zu wollen, indem man die Kunden auf die Telefonhotline verweist. Es entbehrt nicht einer gewissen Ironie, dass die software-basierten Telefonwarteschlangen, in denen man auf den Agenten im Call-Center wartet, so viel besser zu skalieren scheinen als die ach so skalierbaren, cloud-basierten Web- und Applikations-Server.
Zugegeben, gewisse Dinge manuell zu tun kann auch eine Geschäftsentscheidung sein, um beispielsweise die Stornierungsrate zu senken. So kündigte meine Fluggesellschaft denn auch zeitnah eine „Verbesserung“ an: anstelle Flüge jetzt online stornieren zu müssen, kann man diese telefonisch umbuchen. „ Bitte nur anrufen, wenn Sie innerhalb der nächsten 72h reisen möchen “, heißt es auf der Website.
Ob geschäftliche Entscheidung oder technische Limitierung: die Auswirkungen sind enorm und die Welleneffekte beträchtlich. Es wird eine Menge von Fehlerbeseitigungsmaßnahmen brauchen. Das erinnert mich übrigens stark an meine erste Reise durch das neu eröffnete Terminal 5 im Londoner Flughafen Heathrow am zweiten Tag nach der Eröffnung. Das war Chaos, Verwirrung und Durcheinander. Meine Koffer brauchten zwei Wochen, bis sie wieder zu mir nach Hause fanden - via Italien .
Disruptionen: nur eine Frage der Zeit
Im letzten Jahr (2019) hielt ich auf einigen Konferenzen den Vortrag Beyond Clean Code - Building the Right Software . Eine der zentralen Botschaften im Vortrag war, dass Software, wenn sie lang genug lebt, immer Disruptionen im Markt erleben wird, die wesentliche Veränderungen in der Software notwendig machen werden.
Das ist der Grund, weshalb Software leicht änderbar sein muss, und weshalb Testautomation entscheidend ist.
Damals gab ich einige Beispiele für Disruptionen. Die Einführung von SEPA beispielsweise, die für uns Deutsche die Abkehr vom gewohnten System mit Bankleitzahl und Kontonummer brachte. Die DS-GVO zwang viele von uns, das Thema Datenschutz und Privatsphäre neu zu denken, was teilweise massive Auswirkungen auf System- und Software-Architektur hatte.
Schon vor einiger Zeit wurde mit dem Euro eine neue Währung eingeführt, allerdings waren für eine Übergangszeit sowohl die Deutsche Mark als auch der Euro gültige Währungen. Erst kürzlich hat der Brexit einen Teil der Europäischen Union in ein Drittland verwandelt, allerdings ohne, dass es einen Zeitplan oder irgendwelche Klarheit über das Vorgehen gegeben hätte, was natürlich jegliche seriöse Planung im Keim erstickt hat.
Aus heutiger Sicht fehlte auf der Liste der Disruptionen natürlich der Begriff Pandemie .
Jede Disruption stellt fundamentale Annahmen infrage, die in ein System eingebaut waren, und macht daher substanzielle Änderungen an der Software nötig. Und das ist nicht so ganz einfach.
Einige Software-Projekte sind erfolgreich damit gestartet, dass sie irgendwann einen Feature-Freeze hatten und die Software manuell getestet haben, oder sie hatten eine lange öffentliche Beta-Phase, in der de facto die Endbenutzer die Software durchgetestet haben. Aber wie testet man nun Änderungen, die durch eine drohende oder gegenwärtige Krise notwendig werden?
Ohne Testautomation bleibt im Grunde nur eine der folgenden drei Möglichkeiten:
- Die Software bleibt unverändert, wie sie ist
- Wir gehen für eine Weile offline
- Wir lassen die Endbenutzer testen
Keine dieser Optionen ist besonders reizvoll. Man mag sich zur dritten Option hingezogen fühlen, weil die anderen beiden Optionen direkt zu manueller Bearbeitung führen würden. Wer die dritte Option wählt, zahlt allerdings einen hohen Preis.
Es wird eine Menge von Bugreports geben, die jeweils eingeordnet und abgearbeitet werden wollen. Die Kunden werden zunehmend ungeduldig werden, während sie auf Bugfixes oder zumindest auf eine Reaktion auf ihre Bugreports warten. In der Zwischenzeit wird die Hotline von Anrufen überflutet. Es wird eine Menge von Fehlerbeseitigungsmaßnahmen brauchen. Und jede dieser Fehlerbeseitigungen kann selbst auch wieder Folgen haben. Das ist ein Teufelskreis, in den niemand geraten möchte.
Software-Architektur ist der Schlüssel
Martin Fowler definiert Software-Architektur als Entscheidungen, die wichtig und schwer zu ändern sind . Wir haben bereits festgestellt, dass Geschäftsanwendungen niemals fertiggestellt sind.
Niemand kann vorhersagen, welche zukünftigen Änderungen an einer Software notwendig werden. Dies darf uns allerdings nicht auf den gefährlichen Pfad der zu generischen Software führen. Einige sind diesen Weg gegangen und haben auf die harte Tour gelernt, dass man dabei mit einer unwartbaren Software endet, denn niemand mehr kann, eben weil sie so generisch ist, aus der Software herauslesen, was sie eigentlich tut. Ich weiß, wovon ich spreche, weil ich einer von denen bin, die in der Vergangenheit diesen Weg versucht haben.
Wir können noch nicht einmal Disruptionen vorhersagen. Manche, wie beispielsweise die DS-GVO, tauchen schon relativ früh am Horizont auf, werden aber viel zu lange ignoriert. Andere, wie beispielsweise der Brexit, sind in sich nicht vorhersagbar: Keiner wusste, ob und wann der Brexit geschehen würde, und selbst heute weiß noch niemand, wie die Spielregeln im weiteren Verlauf sein werden.
Wir müssen der Wahrheit ins Auge sehen: Niemand kann die Zukunft vorhersagen. Verschiedene Sektenführer haben schon das Ende der Welt vorhergesagt. Mit Ausnahme derer, die klug genug waren, das Ende für ein Datum vorherzusagen, das lange hinter ihrer Lebenserwartung liegt, wurden alle Vorhersagen bisher durch die Tatsache widerlegt, dass wir noch hier sind. Die Welt ist ja beispielsweise am 21. Dezember 2012 nun doch nicht untergegangen, richtig?
Zugegeben: Wir wurden vor einer Pandemie gewarnt. Aber wir wurden auch vor einer weitere nuklearen Katastrophe, dem Dritten Weltkrieg, einem Börsencrash, dem erneuten Platzen einer Immobilienblase und vermutlich auch vor einer Zombie-Apokalypse gewarnt. Ganz egal, was geschieht, es findet sich immer jemand, der genau davor gewarnt hat. Zurückblickend ist es ja auch relativ, dies zu betonen.
Da wir nicht die Zukunft voraussagen können, müssen wir Systeme schaffen, die auf Veränderung ausgelegt sind. Wir müssen flexibler werden und mehr Möglichkeiten schaffen, vorhandene Software an eine sich rasch verändernde Welt anzupassen.
Macht Euch bereit!
Ein hohes Maß an Business-Automation ist ein kritischer Erfolgsfaktor, besonders in Krisenzeiten. Einen Automationsgrad nahe 100% zu erreichen, ist dagegen weiterhin nicht realistisch, ganz besonders in Krisenzeiten.
Traditionell werden Automations-Entscheidungen aufgrund von Kosten- und Umsatzüberlegungen getroffen. Das reicht aber nicht aus. Wir müssen auch risikobasierte Überlegungen anstellen, wenn wir das Potenzial und die Auswirkungen von Business-Automation analysieren. Manch einer verwendet an dieser Stelle den Begriff Digitalisierung , ich bevorzuge Automation .
Wir müssen unsere Software und Systeme flexibler gestalten, damit wir uns mit weniger manuellem Aufwand und weniger Wellenschlag an veränderte Gegebenheiten anpassen können. Alles, was wir heute verändert haben, müssen wir möglicherweise in Zukunft wieder rückgängig machen. Akademisch betrachtet ist eine Besonderheit der Corona-Pandemie, dass irgendwann in Zukunft alles wieder normal wird. Ist das wirklich so?
Eines ist sicher: Das Coronavirus wird nicht die letzte große Disruption sein, mit der wir es zu tun haben werden. Wir sollten uns daher vorbereiten, und zwar besser zu früh als zu spät.