Die Gründe für die Situation sind vielfältig und der Versuch, alle Gründe zu beschreiben, würde dieses Editorial bei Weitem sprengen. Hier möchte ich deshalb nur eine aus meiner Sicht spannende Idee vorstellen. Beginnen wir bei einem der Kernprobleme: der Angst vor dem Abschalten von Systemen.
Die Angst vor dem Abschalten
Es ist häufig nicht nur der erwartete Aufwand für die Migration auf ein neues System, das Unternehmen zögern lässt. Es ist die Angst davor, was passiert, wenn man das System tatsächlich abschaltet. Was passiert dann? Läuft alles wie erwartet? Oder hat man etwas übersehen? Wird alles ordnungsgemäß verarbeitet? Werden die abhängigen Systeme korrekt mit Daten versorgt? Oder haben sich Inkonsistenzen eingeschlichen, die im schlimmsten Fall dafür sorgen, dass ganze Teile der Systemlandschaft nicht mehr ordnungsgemäß funktionieren?
Vielfach ist das nur sehr schwer vorhersagbar. Es fehlt Dokumentation. Es fehlt Wissen über Entscheidungen. Implementierungsdetails lecken unerkannt über Schnittstellengrenzen. Das abzulösende System stellt nach innen und nach außen ein unüberschaubares Knäuel dar, das zu entwirren praktisch unmöglich erscheint. Und die Personen, die diese Systeme entworfen und gebaut haben, haben das Unternehmen schon lange verlassen.
So steht man dann vor dem System von 1974, das immer noch produktiv läuft, einen signifikanten Datenbestand verwaltet, über mehrere Integrationsschichten an die aktuellen Systeme angebunden ist und von dem niemand mehr weiß, was es wie und warum tut. „Fass das bloß nicht an! Wir haben keine Ahnung, was passiert, wenn wir irgendetwas daran ändern“, bekommt man dann zu hören. Und das System läuft weiter und weiter und weiter. Und weil es nicht das einzige System der Art ist, wächst und wächst der Modernisierungsstau.
Zu kurz gedacht
Wie konnte es dazu kommen, dass man sich praktisch nicht mehr traut, ein System abzuschalten? Dass man lieber ein neues System danebenstellt und das alte System trotzdem weiterlaufen lässt? An der Stelle kommt eine Idee ins Spiel, die ich aus Architektursicht spannend finde: Construction for Deconstruction. Ich habe davon erstmals vor einigen Jahren in einem LinkedIn-Post gelesen.
Der Grundgedanken ist folgendermaßen: Wenn ich eine Eventbühne für ein Straßenfest aufbauen will, dann muss ich ein paar Auflagen dafür erfüllen. Eine der Auflagen ist üblicherweise, dass ich die Bühne im Falle eines Notfalls sehr schnell abbauen können muss, um den Weg für Rettungskräfte freimachen zu können. Damit habe ich beim Entwurf der Bühne nicht nur das Event an sich zu bedenken, sondern auch die Frage, wie ich diese Bühne im Notfall in kürzester Zeit wieder abbauen kann. Das ist „Construction for Deconstruction“: Beim Design schon darüber nachdenken, wie man das Ganze bei Bedarf schnell und einfach wieder abbauen kann.
Auf die Softwareentwicklung übertragen bedeutet das, sich beim Entwurf eines neuen Systems schon Gedanken darüber zu machen, wie man das System schnell und einfach wieder aus der Systemlandschaft entfernen kann. Um bei der Metapher der Eventbühne zu bleiben: Wenn wir ein System entwerfen, dann denken wir ausschließlich über das Event nach. Wir betonieren die Bühne ein, verlöten und verschweißen alle Versorgungsanschlüsse und verankern die Bühne so in die umliegenden Gebäude, dass wir bei dem Versuch, sie wieder abzubauen, mit ziemlicher Sicherheit den ganzen Straßenzug demolieren und dessen Versorgung über Tage oder Wochen hinweg lahmlegen.
Wir denken ausschließlich darüber nach, wie wir die Bühne möglichst billig so hingestellt bekommen, dass das Event stattfinden kann. Danach? Nicht unser Problem. Nicht im Scope. Nicht im Budget.
Zins und Zinseszins
Weil wir uns immer nur Gedanken über das Aufbauen und Erweitern machen, aber nie über das Abbauen, enden wir dann immer wieder in der Situation, dass das Abbauen extrem schwierig und teuer wird, oder im schlimmsten Fall ganz unmöglich. Dabei wäre es kein großer Mehraufwand, sich beim Aufbauen und Erweitern eines Systems schon mitzuüberlegen, wie man sicherstellen kann, dass man es leicht wieder aus der Systemlandschaft entfernen kann. Das führt zu einigen etwas anders getroffenen Designentscheidungen. Man macht sich etwas mehr Gedanken zu Datenflüssen und Kopplung. Man schreibt und pflegt eine Abbauanleitung, die einem als Seiteneffekt hilft, besser strukturierte und entkoppelte Systeme zu gestalten, was einem im Gegenzug Wartungs- und Weiterentwicklungskosten spart.
In Summe ist Construction for Deconstruction vor dem Abbau des Systems normalerweise ein Nullsummenspiel. Beim eigentlichen Ablösen des Systems spart man damit aber Unsummen. Zusätzlich ist es nicht nur so, dass der Ausbau eines Systems deutlich weniger Geld kostet. Die Angst vor dem Abschalten sinkt massiv. Damit überaltert die Systemlandschaft lange nicht mehr so extrem, schlicht weil man alte Systeme nicht mehr aus den am Anfang genannten Gründen weiterlaufen lassen muss. Die Landschaft wird kleiner, kompakter und leistungsfähiger.
Die Investitionen amortisieren sich nicht nur relativ zeitnah. Sie werfen satte Zinsen und Zinseszinsen ab. Je länger man darüber nachdenkt, desto offensichtlicher wird der Wert des Vorgehens, und man fragt sich, warum wir das nicht schon immer so machen.
Aller Anfang ist schwierig
Aber wie ich bereits weiter oben geschrieben habe: Es gibt viele Gründe dafür, warum die meisten Unternehmen einen massiven Modernisierungsstau vor sich herschieben, der sie immer weiter lähmt. Wir können die Vergangenheit auch nicht mehr ändern. Aber wir können den Grundstein für eine bessere Zukunft legen. Ich weiß, dass das nicht einfach ist. Die vorherrschenden Unternehmensreflexe versuchen, alle Investitionen zu unterdrücken, die nicht sofort wirksam werden, selbst wenn ein jetzt zusätzlich ausgegebener Euro in Zukunft Hunderte oder Tausende Euros einsparen wird. Wir stehen bei Construction für Deconstruction auch noch inhaltlich am Anfang und wissen noch gar nicht richtig, wie wir das konkret am besten umsetzen. Wir müssen das erst lernen und Good Practices erarbeiten.
Aber trotzdem: Die Vorteile sind einfach zu groß, um das Thema einfach beiseitezuschieben, wenn man einmal ernsthaft darüber nachdenkt. Oder? Irgendwie müssen wir dem Modernisierungsstau zu Leibe rücken, bevor er uns zum vollständigen Stillstand bringt. Warum nicht mit Construction for Deconstruction?
Uwe Friedrichsen
Herausgeber
