EAM#6: Betriebsschulden - Warum Lock-in erst beim Exit teuer wird

Architektur entscheidet über Komplexität, über Kosten, über Steuerbarkeit. Ich bin David Hohl und heiße dich herzlich willkommen bei Enterprise Architektur wirkt, der Podcast zu EAM. Servus, grüß dich und herzlich willkommen zu einer neuen Folge. Wir sind noch immer mitten in unserer Serie über technische Schulden. In den letzten Folgen habe ich dir veranschaulicht, wie Schulden in Integration, Daten und vor allem in Customization entstehen. Heute schauen wir auf, was daraus eigentlich wird. Und zwar sind es die Betriebsschulden. Und viel konkreter möchte ich auf das Login einsteigen. Gerade heutzutage ein wichtiges Thema, gerade mit den politischen Situationen draußen im Lande. Aber wichtig, Login ist nicht das eigentliche Problem. Und das möchte ich dir heute ein bisschen näher bringen. Denn für mich ist das eigentliche Problem dahinter, sind die Abhängigkeiten. Denn Login ist oft gewollt. Wenn wir darüber sprechen, denken wir sofort an etwas Negatives. Ah, da machen wir uns abhängig. Mist, da kommen wir nie wieder raus. Aber das stimmt so nicht. Login ist oft eine bewusste Entscheidung. Und wenn du dich über eine Plattform entscheidest, entscheidest du dich selten nur für das eine System. Du entscheidest dich für das Ökosystem dahinter. Und genau das ist auch sinnvoll, wie ich finde. Denn dadurch bekommst du Geschwindigkeit, Standardisierung und vielleicht auch integrierte Lösungen. Ein aktuelles Beispiel, was gerade auch in meinem Umfeld immer wieder zur Sprache kommt, ist das Thema Cloud. Ja, die Wolke, die über uns schwebt und jederzeit verfügbar ist, solange das Rechenzentrum gerade nicht vor einer Rakete getroffen wird, siehe Iran-Krieg. Viele Unternehmen haben natürlich die Intention, in die Cloud zu gehen, weil sie damit einfach flexibler werden. Sie können damit schneller entwickeln, skalieren und müssen ihre eigene Rechenzentrum im Keller betreiben. Wobei, das gibt es natürlich auch noch. Und das funktioniert auch. Also, zumindest am Anfang, da ist die Intention und die Begeisterung ungebrochen. Wo die Abhängigkeit am Ende des Tages entsteht, ist an einer anderen Stelle. Denn am Anfang nutzt du die Cloud oft noch relativ neutral. Also virtuelle Maschinen, du packst ein paar Sachen, ein paar Sachen, eine Datenbank, eine Message-Proker da und vielleicht noch gutes Monitoring drauf und dann ist es schon eigentlich sehr attraktiv, weil sie nimmt halt uns die Arbeit ab. Und genau blöderweise, da beginnt die Abhängigkeit, da wo es wirklich schön ist. Der kritische Punkt, den diese Services mit sich bringen, sind nicht die Standardisierungen dahinter. Sie sind spezifisch für den Anbieter. Also das bedeutet, deine Architektur passt sich ja dann dementsprechend der AWS oder Azure oder Google Cloud Architektur an. Deine Anwendungen passen sich dann dementsprechend an. Und die Prozesse dahinter blöderweise auch noch. Und irgendwann kannst du diese Dinge auch nicht mehr einfach mitnehmen. Natürlich kann man entwicklungstechnisch dagegen lenken und dann nachher eher hybrid entwickeln, aber oft möchte man damit nicht mehr Kosten erzeugen, sondern man möchte ja Kosten reduzieren. Und somit nutzt man das, was da ist und das liest sich auch sehr spannend immer. der Client da, der Service hier, funktioniert alles ingeschlossen wunderbar. Und das ist auch, wie gesagt, noch immer alles fein, aber man muss halt bewusst diese Entscheidung treffen. Abhängigkeiten entstehen aus meiner Erfahrung nicht auf einmal. Sie ist nicht von heute auf morgen hier. Sie entsteht einfach Schritt für Schritt, also nach einer Integration, nach einem Service, eine Erweiterung im Prozess und jede Entscheidung, die du dahinter triffst, ist auch in dem Moment ja auch kaum nicht sinnvoll. Und gerade wenn man Richtung ADR schaut, die Abhängigkeiten sind dort auch selten wirklich aufsehbar. Denn diese Entscheidungen, die dahinter getroffen sind, wenn man sie jetzt auf Makroebene sieht, die machen alle Sinn. Da würde wahrscheinlich kein Architekt-Report sagen, das ist jetzt wahrscheinlich eine falsche Entscheidung. Aber in Summe entsteht blöderweise ein komisches Netz, wie so ein Spinnennetz. In der Mitte sitzt da jemand, der gerade in unserem Cloud-Beispiel, der Cloud-Betreiber, du kommst hier nicht mehr raus, du klebst hier fest. Der Entscheidermechanismus dahinter. Jede Verbindung schafft eine Abhängigkeit. Und jede Abhängigkeit reduziert dann am Schluss deine Freiheit. Also Freiheit im Sinne der Entscheidung. Am Anfang merkst du das wahrscheinlich nicht. Denn alles ist besser. Es ist schneller, effizienter. Es ist integrierter. Ich habe das auch selbst zu oft erlebt. Und habe mich davon hinreißen lassen und verführen lassen. Aber gleichzeitig wird es auch weniger beweglich. Wenn du das einmal genauer anschaust, dass man das System auf einmal integrieren muss, von außerhalb mit rein, dann muss man sich dementsprechend danach anpassen und die Beweglichkeit, die reduziert sich damit automatisch. Und das sind so diese ersten Anzeichen, wo man ein bisschen aufpassen sollte. Und das ist halt so wie dieser trüge Alltag, den man dann tagtäglich betritt. Im Betrieb selber ist halt alles stabil und wenn man das auf die Kosten mal kurz reflektiert, die sind sichtbar in Form von den Lizenzen Betrieb und Nutzung und wenn man sich diese riesen Kosten-Sheets dann nachher anschaut schaut das auch alles okay aus abgesehen jetzt ob man diese Kosten eingehen möchte oder nicht dass man das dahin gestellt und alles wirkt finde ich immer sehr kontrollierbar weil auch diese Serviceleister die sagen, du kannst dir nachher das wieder entfernen und durch was anderes ersetzen und dann bist du auch hier fein, aber wenn man genau hinschaut Und deshalb entsteht eigentlich für mich dieser Login. Der wird dabei vollkommen unterschätzt. Und das ist auch eine ganz schwierige Situation, glaube ich, für jeden Architekten und für dich auf jeden Fall auch. Der Moment der Wahrheit, der dahin kommt, der eigentliche Test, der kommt erst. Wenn du etwas verändern willst, genau das, was ich vorhin so ein bisschen angetriggert habe. Zum Beispiel, du willst den Anbieter auf einmal wechseln. Du willst jetzt von dem weg. Du willst auf eine komplett andere Plattform, du willst das Ding ablösen oder du möchtest, vielleicht das ist auch noch so ein Trigger, du möchtest da drinnen jetzt ein System, was du dort laufen hast, komplett transformieren. Zum Beispiel, du möchtest Zentralisierung einführen oder Dezentralisierung einführen. Das sind meistens immer die großen Changes in ein paar Großprojekten, wo sehr viele Transformationen oder Entwicklungsbedarf notwendig ist. Und jetzt zeigt sich das in der Realität. Wenn wir uns das Bild des Exits mal genauer anschauen, also mal ein Bild davon weg, von dem Dienstleister. Die Kosten entstehen nicht im System als solches, die sind natürlich da, aber das gehe ich ja von Anfang an ein und das ist mir auch bewusst. Sie entstehen halt in dieser Abhängigkeit. Denn beim Wechsel musst du ja nicht einfach nur ersetzen, geht auch gar nicht. Gerade in dieser Cloud-Geschichte, wenn du native Services machst, dann kannst du nicht einfach das eine mit dem anderen ersetzen. Denn du musst nämlich ein paar Sachen jetzt auflösen. Du musst die Integration auflösen, du musst die Datenstrukturen, die Services auflösen, die Prozesse gegebenenfalls ja noch und vor allem auch diese angrenzenden Systemen, unabhängig jetzt die in der Cloud jetzt werden zum Beispiel, sondern die außerhalb liegen in anderen Bereichen, von anderen Vendoren, wo breitgestellt wird oder halt von deinem eigenen Rechenzentrum oder dein Kellersystem. Und was ich auch gelernt habe, was man damit auch noch auflösen oder beziehungsweise ändern muss, sind die organisatorischen Abläufe. Die verändern sich auch noch sehr stark, wie ich finde. Also dass du halt auch die Prozesse, wie du etwas tust, wer die Entscheidungen trifft, das sind auf einmal andere Personen. Und somit ist das Ganze nicht mehr isoliert zu betrachten, sondern es ist alles übergreifend. entscheidende Effekt dahinter, wenn ich jetzt mal darüber noch mal laut nachdenke, das ist genau der Punkt, wo es jetzt teuer wird. Also das ist der Effekt da. An der Stelle wirst du merken, jetzt kommt die Lawine auf mich zu. Denn diese Kosten sind ja nicht mehr lokal und nicht sauber zuortbar. Und vor allem kannst du fast nicht mehr planen. die kommen wie so eine Labine auf dich zu. Es ist unmöglich aufzuhalten. Sie verteilen sich dann über mehrere Systeme, wahrscheinlich auch mehrere Budgets. Also da müssen ja verschiedene Budget-Teams oder beziehungsweise Budget-Holder mit reininvestieren für so einen Wechsel. Und die Teams vor allem auch. Denn die Projekte, die dahinter sind, die hören ja nicht von heute auf morgen auf. Die werden ja auch hier an der Stelle weiter getrieben und weiterentwickelt. Und da muss man halt an der Stelle gerade extrem aufpassen. Gerade Richtung Migrationen. Wer das schon einmal gemacht hat, weiß, wie aufwendig sowas ist. Und wenn du an der Stelle gerade so einen großen Dienstleisterwechsel machst, also gerade so ein Exit-Szenario durchführst, dann wirst du als Entscheider-Redefest feststellen, dass unabhängig von der Migration als solches, also die Daten, die ganzen Systeme, die damit betroffen sind, dass du halt sehr viele Prozesse auch umstellen musst. Und nicht nur die Prozesse, sondern Integrationen funktionieren halt von heute auf morgen nicht mehr. Und dann musst du anfangen, über diese Migration hinweg nochmal ein Projekt aufsetzen, dass so ein Exit überhaupt funktioniert. Die Erkenntnis, die ich dabei genau getroffen habe, bzw. was mich getroffen hat als solches in der Vergangenheit, genau deshalb ist Cloud kein Automatismus für Flexibilität. Ich verstehe bis heute nicht, warum das viele noch immer glauben, dass ich durch Cloud so flexibel bin. Klar, ich muss hier mal einen Stopp machen, weil sonst zerfressen mich die ganzen DevOps-Experten dieser Welt. Man kann mit Cloud, wenn man sich richtig aufsetzt, mit einer guten Strategie, Architektur, schon sehr sauber arbeiten und viele Unternehmen oder fast alle Systeme laufen ja in der Cloud. So ist es ja nicht. Nur was ich hinweisen möchte, gerade bei unserem Cloud-Beispiel, wir können auch ein ERP-System auseinandernehmen, da kommen wir auch auf dasselbe Szenario hin. Diese Flexibilität, die mir da versprochen wird, die ist nur so lange aktuell, solange ich darauf bleibe. Sobald ich da aber rausgehen möchte, dann bremse ich und muss mich auf andere Gegebenheiten geben. Natürlich auch diese Entwicklung kann ich dahin treiben, dass ich auf der Cloud entwickle mit meinen eigenen Services, ohne die nativen Tools zu nutzen oder ein Hybridmodell etc. Ich bin jetzt auch kein Cloud-Experte, aber es gibt auf jeden Fall Mechanismen dazu. Das ändert aber trotzdem nichts aus meiner Sicht an dieser Sicht dieses Spinnensverhalten. Du kommst halt sehr schwer wieder raus. Wichtig ist ja nur, wie du damit umgehst. Also ich finde noch immer, Abhängigkeiten gehe ich ja bewusst ein. Ich muss sie wissen, ich muss sie steuern können. Und diese Steuerbarkeit ist das A und O. Um zur Erkenntnis nochmal zurückzukommen. Aber wie gesagt, wenn du bewusst damit umgehst, dann gehst du auch im Endeffekt anders mit negativen Aspekten um. Denn sonst passiert das Gegenteil. Du baust dir die Abhängigkeit auf, die dich eigentlich tief in deine Architektur hineinreißt und da auch nie wieder rauslässt. Ein wichtiger Aspekt, den ich gerade bei Großsystemen immer wieder sehe, und ich möchte jetzt hier keine Vendoren auflisten, aber du kannst dir so drei Buchstaben auch merken, oder zwei Buchstabensysteme, die sind halt sehr politisch orientiert. Und das ist halt ein großer Punkt, der oft unterschätzt wird, die politische Dimension dahinter. Diese Lager, die dabei entstehen, du darfst nur dieses eine Ökosystem nutzen und wenn du nicht dieses Ökosystem nutzt, dann bist du auch out von hier. Und dann wird auch zum Beispiel von non-xx gesprochen und der Rest. Diese Entscheidungen sind nicht nur technische, sie sind halt einfach politisch. Und ich habe die Nase voll davon, diese politischen Entscheidungen auf technischer Basis zu setzen oder beziehungsweise auf diesem Level runterzulassen. Wenn du dich nicht für eine Plattform entscheidest, baust du darauf Kompetenzen auf. Ganze Teams richten sich danach aus, die Partner werden dazu halt ausgewählt und vor allem die Strategien, die nachrangig auch kommen werden, Die basieren darauf, die werden darauf abgestimmt und verlassen sich darauf. Und genau das macht halt einen Wechsel noch schwieriger. Du kommst davon nicht nur technischer Natur schwer wieder weg, sondern auch politischer Natur. Man lasst dich auch gar nicht. Ich denke, das kennst du. Denn du verlässt nicht nur die Technologie, du verlässt einfach eine Entscheidung. Und das bringt mich auch eigentlich zu diesem sehr sensiblen Punkt, wenn man halt Architekturentscheidungen trifft, dann hat man halt verschiedene Facetten, die man halt betrachten muss. Diese ganzen technischen Schulden, die wir dieses Monat gesprochen haben, die verweisen alle in diese Richtung. Klar, und mir ist auch vollkommen bewusst, dass man diese Schulden auch eingehen muss, um weiterzukommen. Man kann sich nicht da an den Kreis drehen und dann verlangen, dass sich das irgendwann einmal auflöst. Dennoch sollte man diese Entscheidung, gerade was die politische Dimension angeht, wirklich genau kontrollieren und diese auch zu challengen, finde ich. Also Login ist eigentlich nicht das Problem, wie ich finde, sondern es ist eigentlich das Ergebnis von eigentlichen Abhängigkeiten, die sich über die Jahre einfach aufgestellt haben. Und diese entstehen leider sehr bewusst. Und jedem ist das klar und dir ist es sich auch klar. Vielleicht diesmal, bevor ich hier auf meinen klassischen vier Fragen, wie du das erkennst, eingehe, die ich diesmal skippen möchte, im Gegensatz zu, welche vier Fragen du stellen könntest, zur Gegensteuerung, die packe ich dir natürlich auch in die Shownotes rein. Erstens, wo machen wir uns bewusst abhängig und warum? Also nicht jede Abhängigkeit ist ja schlecht. Aber sie sollte bewusst sein. Zähl dir das mal auf. Die zweite Frage, die du dir stellen könntest, wie würde ein Exit heute aussehen? Also nicht im Projekt solches, sondern als Gedankenexperiment. Nebenbei bei DORA, also dieser Digital Resilience Act von der EU Richtung Finanzen, die haben das als Hauptaufgabe mit drinnen. Da steht drinnen in dieser Liste, du musst halt deine kritischen Applikationen aufzeigen, was halt kritisch ist, ist halt klar, aber danach, wie kommst du da raus und was ist dein Exit-Szenario? Ich finde das einfach so geil, dass das ein Must-Have ist für diese Organe oder diese Branchen. Und das sollte eigentlich jeder Architekt als fixes Instrument mittreiben. Die dritte Frage, welche Abhängigkeiten sind kritisch und welche nicht? Nicht alles ist gleich relevant, hier entsteht natürlich Steuerung. Viertens und letztens, wie können wir gezielt entkoppeln? Natürlich nicht alles auf einmal, aber bewusst. Diese Entscheidungen müssen bewusst getroffen werden. Du wirst Lock-In nicht vermeiden können. Das ist natürlich nicht das Ziel. Verstehe mich da nicht falsch. Aber was ich dich eigentlich frage ist, wie gehst du damit um? Also was ist deine Strategie dahinter, was ist dein Entscheidungsweg? Und genau hier wird es nämlich dann spannend. Denn viele dieser Abhängigkeiten, die daraus entstehen, in Kosten tauchen in unserem klassischen Kostenmodell ja gar nicht auf. Die eigentliche Frage ist also, messen wir überhaupt das, was uns wirklich Geld kostet? Genau das schauen wir uns in der nächsten Folge an. Bis dahin wünsche ich dir eine gute Zeit, bleib gesund und wenn dir der Podcast gefällt, was ich natürlich hoffe, freue ich mich, wenn du ihn auch weiterempfiehlst. Bis dahin, Servus Papa und bis auf bald.