EAM#10: TCO ist nicht falsch aber blind - Warum dir die Architektur fehlt?

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. Letztens habe ich ja über Rannkosten gesprochen Und heute gehe ich wieder mal einen Schritt weiter. Weil die eigentliche Frage ist natürlich nicht nur, wie Kosten entstehen, sondern du fragst dich wahrscheinlich auch, warum wir sie so oft gar nicht richtig sehen. Wenn ich mir aktuell anschaue, was draußen in der Welt passiert, dann muss man schon ehrlich sagen, der Druck kommt gerade nicht von innen. Der kommt gerade stetig von außen. politisch, wirtschaftlich und ziemlich direkt spürbar für jedes Unternehmen, aber auch extrem für uns alle, die Verbraucher. Und ein Beispiel sieht man gerade extrem deutlich. Die Straße von Hormuz. Das ist kein abstraktes Thema. Wir machen hier auch keinen geschichtlichen oder geografischen Ausflug. Das ist ein Nadelöhr der Weltwirtschaft. Durch diese eine Meerenge laufen rund 20% des weltweiten Ölverbrauchs. Und das jeden Tag. Das ist ein Interface, was täglich genutzt wird, mit weltweiten Ausmaßen. Und nicht nur Öl. auch erhebliche Teile von Gas und gewissen Energienversorgungen und natürlich auch Vorprodukte, die wir täglich brauchen, gerade in der Industrie. Das heißt, ein einzelner Engpass auf der ganzen Welt entscheidet darüber, wie teuer Energie ist und wie stabil unsere Lieferketten dahinter wirklich sind und wie planbar die Wirtschaft überhaupt noch ist. Und jetzt passiert genau das, was passieren kann. Konflikt, Unsicherheiten und wir haben Blockaden, die sich politisch orientieren. Und plötzlich merkt man, wie abhängig das ganze System dahinter ist. Und jetzt wird es auch noch spannend, weil dieser Effekt trifft erstmal wirklich alle hier. Nicht nur dich, sondern jedes Unternehmen, jede Branche. Wir haben gleiche Energiepreise, natürlich unterschiedlich von den Steuern, aber gleiche Unsicherheiten, wie geht es weiter? Und wir haben alle den gleichen externen Druck, den wir alle ausgesetzt sind. Und trotzdem reagieren Unternehmen komplett unterschiedlich. Das eine bleibt handlungsfähig, passt Dinge an, findet einfach Alternativen und bleibt stabil. Und das andere kommt sofort unter Druck. Kosten steigen, Marge bricht weg, Reaktionsfähigkeit fehlt. Oh nein. Und genau da liegt für mich als Architekt der Unterschied. Nicht im Markt, sondern im Inneren. Wenn ich das vereinfache, dann sehe ich da zwei Arten von Unternehmen. Die einen sind extrem effizient aufgebaut, alles optimiert auf Stabilität, Kosten sind sauber reduziert und runtergebrochen. Und die anderen sind so aufgebaut, dass sie sich einfach bewegen können. Sie sind flexibler, sie sind veränderungsfähiger, nicht perfekt, aber anpassbar. Und das Spannende ist, in ruhigen Zeiten wirken diese Effizienten besser. Alles läuft, alles ist günstig, alles ist leihwand. Wenn man so schön in Wien sagt. Aber in genau solchen Situationen wie jetzt dreht sich das komplett, das Rad. Dann sind die Flexiblen im Vorteil, ich finde, weil sie reagieren können. Und das ist halt kein Zufall. Das ist nämlich Architektur, meine Lieben. Und du kannst selten beides gleichzeitig maximieren. Effizient und Flexibilität, das ist halt ein Trade-off. Und der entsteht nicht im Betrieb. Der entsteht in deinen Strukturentscheidungen, in deiner Architektur. Und ich mache es konkret. Wenn Energiepreise steigen, und das passiert ja gerade, durch genau solchen Engpässen wie in Hormos, dann kannst du das nicht verhindern. Das sind einfach deine Hände gebunden. Aber die Frage ist halt, wie abhängig bist du davon? Kannst du reagieren, kannst du Lieferketten anpassen oder kannst du da vielleicht auf andere Alternativen umswitchen, kannst du Prozesse verändern, um dagegen zu wirken oder bist du so stark gebunden, dass du einfach mitgehen musst. Und genau hier kommt Architektur ins Spiel. Man glaubt es kaum. Wenn deine Systeme, deine Prozesse und deine Daten so aufgebaut sind, dass du flexibel reagieren kannst, dann ist so ein externer Effekt ein Thema. Aber ein strukturelles Problem ist es halt nicht. Wenn du das nicht kannst, passiert etwas anderes. dann wird aus genau diesem externen Druck ein interner Kostentreiber. Und genau darüber habe ich in der letzten Folge gesprochen, die Run-Kosten. Wie sie entstehen, warum sie halt wachsen und warum sie oft strukturell sind. Und genau hier gehe ich jetzt mal wieder einen Schritt weiter. Weil es gibt ein Modell, das fast jedes Unternehmen nutzt, um genau diese Kosten zu verstehen. Ich glaube, du weißt welches ich meine. Genau. Der Total Cost of Ownership. Bevor ich da tiefer reingehe, ist mir ein Punkt echt wichtig. TCO, also der Total Cost of Ownership, ist nicht falsch. Im Gegenteil. TCO ist extremst wertvoll. Weil er oder es dir erstmal Transparenz gibt. Was kostet dich ein System, was kostet dich die Plattform oder auch dein Betrieb? Diese Antworten bekommst du davon. Und das ist alles richtig. Das Problem ist nur, die SEO zeigt nur ein Teil der eigentlichen Realität. Und genau deshalb sage ich dir, der TCO ist heute nicht falsch. Aber der TCO ist heute blind. Blind für das, was darunter liegt. Blind für das, was diese Kosten eigentlich wirklich verursachen. Und genau das sehe ich in der Praxis immer wieder. Da wird gerechnet. Sehr sauber sogar. Ein kleiner Outbreak, ich wohne seit mehreren Jahren in Deutschland und gerade hier ist ein großer Unterschied, gerade zwischen Österreich und Deutschland, was die Genauigkeit angeht. Wenn es um den letzten Euro geht, sind die Deutschen, glaube ich, ein Schritt vorne von der Nase, anders wie die Österreicher. In Österreich dreht man danach den Groschen vielleicht nochmal um und geht nochmal einen Schritt zurück und dann geht man weiter und kriegt nicht Panik, wenn mal nicht die Kasse stimmt. Zurück zu unserem TSEO. Lizenzen werden halt genauer verglichen, die Infrastruktur wird halt bewertet und Betriebskosten werden halt gegenübergestellt. Und dann wird halt entschieden, in dem Moment wirkt diese Entscheidung komplett logisch für jeden Einzelnen, was wir jetzt zu machen haben. Die Zahlen passen, denkt man, das Modell passt natürlich dahinter auch, denkt man, alles wirkt halt rational korrekt. Und ein Jahr später sitzt man halt wieder zusammen und das selbe Problem und schaut uns in die Augen und plötzlich ist das System teurer. Es ist nämlich nicht nur teurer, es ist nämlich vor allem komplexer geworden. Es ist schwerfälliger geworden, auch was Veränderungen angeht und auch im Betrieb. Und dann kommt genau dieser Satz. Das haben wir so nicht gesehen. Und die ehrliche Antwort sollte eigentlich danach natürlich drauf sein. Nein, konntest du auch nicht sehen. Nicht im TCO, mein Lieber. Weil TCO dir Kosten zeigt, aber halt nicht die Struktur dahinter. Und das sagt dir halt meistens nur ein guter Enterprise Architekt. Und genau das ist der große entscheidende Unterschied. Und jetzt kommt es. Was du auch auf Unternehmensebene gesehen hast. Das passiert auf Systemebene jeden Tag. Zwei Unternehmen, gleiche Situation. unterschiedliche Reaktion. Und jetzt, was die zwei Systeme auf den ersten Blick sind, sehr ähnlich, im TCO vielleicht sogar identisch, und trotzdem entwickeln sie sich komplett unterschiedlich. Und genau wie bei Unternehmen gilt auch hier, der Unterschied liegt heute nicht in den Kosten. sondern in der struktur dahinter und da müssen wir halt wirklich tiefer reinschauen du hast zwei systeme beide kosten die ich ungefähr das gleiche oder gleich viel wenn du sie in die so dann vergleichst sehen sie heute ähnlich aus vielleicht ist das eine sogar ein bisschen günstiger und jetzt triffst eine Entscheidung und sagst wir nehmen das günstigere es ist vielleicht ein paar tausend euro im jahr günstiger und du sagst halt genau das das das günstigere müssen wir nehmen aus folgenden gründen was du aber nicht siehst dass ein system ist stark gekoppelt vielleicht du siehst vielleicht nicht dass es halt extrem viele die Integrationen hat zu Außensystemen und diese Abhängigkeiten viel weitreichender sind. Und wenn ich halt von Abhängigkeiten rede, dann rede ich halt nicht immer nur von dem System als solches oder die Business-Komponente, die dahintersteckt, sondern von den Daten, die darüber verarbeitet werden, erstellt werden. Gerade diese Datentöpfe sind massiv, umso komplexer auch die Branche ist. Denn umso mehr Abhängigkeiten, umso mehr Schnittstellen kann ich natürlich danach ja auch haben, was Richtung Business geht. Und dann sind wir halt bei den Punkt Capabilities, aber das kommt noch in den nächsten Folgen irgendwann mal. Den Fokus nochmal zurück. Das andere System dahinter ist sauber aufgebaut. es ist klar getrennt wir haben da weniger abhängigkeiten und es ist halt viel einfacher zu verändern im tso siehst du heute diese und diesen unterschieden nicht da musst du immer tiefer schauen ich bin mir sicher du machst das auch aber ich kenne halt sehr viele unternehmen die dann oft diese bewertungen oder diese entscheidungen oft auf wirtschaftlicher ebene treffen diese nachvollziehbarkeit ist nicht gegeben und genau da liegt auch dieser und begraben den müssen wir eben im alltag spürst du ihn sofort weil halt jede änderung länger dort darüber haben wir auch schon mal gesprochen weil jede anpassung mehr abstimmung braucht und alt weil jede erweiterung dahinter immer komplexer wird. Ich kann mich noch gut erinnern als Entwickler, hatte ich immer wieder diese Baustellen, wo ich dann reingraben musste und mir Code anschauen musste oder auch die Schnittstellen von anderen und dachte, oh mein Gott, was ist denn da verbrochen worden, dann komme ich selber drauf, das war ich selbst. Ja, weil halt die Zeit mit sich bringt, die Komplexität erhöht sich und man sieht dann oft halt nicht die eigentlichen Probleme vor sich. Und genau das kostet halt. Nicht einmal, sondern halt immer. Und jetzt ist es halt so, weil das sind genau die Dinge, über die ich in den letzten Folgen gesprochen habe. Die technischen Schulden. Die horchen sich ja immer so einfach an Und ich bin mir sicher, du hast all diesen Schulden, das ist nur eine Handvoll gewesen. Ich recht erinnere, wenn ich meiner Liste nochmal nachschaue, haben wir über vier Schulden gesprochen. Schulden-Integrationen, wir haben über Datenschulden gesprochen, wir haben Customization-Schuld gesprochen und Betriebsschulden und Login. Das ist natürlich nur eine Handvoll. Wenn du dir mal tiefer in die Augen schaust, wirst du noch 10, 20 mehr finden. Und wenn ich ehrlich bin, das sind keine klassischen Schulden gewesen. Das sind Entscheidungen. Nur eben Entscheidungen, deren Auswirkungen du erst später siehst. Wenn wir uns Integration als Beispiel mal herziehen. Das ist halt schnell gemacht. verbindest halt ein CMS mit dein Asset Management System als Beispiel oder mit dem DUM. Und dann machst du halt noch ein Mapping dazwischen, weil das nicht zusammengreift. Und dann kommst du noch vielleicht drauf, da braucht man noch einen anderen Prozess, weil die Informationen nicht richtig korrekt verarbeitet sind. Das funktioniert, das ist auch schnell gemacht. Auch mit der heutigen Technik und Frameworks geht sowas ratzfatz. Im TCO ist es aber blöderweise kaum siegbar, das Ganze. Und es wird auch nicht gespiegelt, weil auch Enterprise-Architekten an der Stelle nicht zu Rate gefragt werden. Und das ist auch okay, wir können nicht alles machen. Aber wie kriegt man diese Spiegelung einfach zurück? Wie erkenne ich, dass hier so viel Customization passiert, so viel Mapping dazwischen passiert? Aus den klassischen Architektur-Artefakten wird das ein bisschen schwierig. Wo sind jetzt die Kosten sichtbar? Wo sehe ich das? Im TCO? Vergiss es. Nicht sichtbar. Im Betrieb? Jede Änderung davon zieht halt seine punktuellen Kreise und hinterlässt dann Brotkümmchen. oder Daten. Da auch. Wenn mehrere Systeme die gleichen Informationen einfach haben, würde er weiß, hat halt jedes System seine eigene Sicht. Im TCO ist es halt nur auf das einzelne System sichtbar. Im Betrieb da ist natürlich sehr viel Synchronisation und Abgleich notwendig. Wir haben sehr viele Fehler oder vielleicht Fehler, die sichtbar darauf hinweisen und auch auf die Inkonsistenzen dahinter. Oder auch die Customization. Am Anfang wirkt es natürlich sinnvoll. Wie gesagt, es ist schnell umgesetzt. Das Business ist happy. Aber trotzdem im TCO kaum relevant und nicht sichtbar. Aber später passiert was, dass halt jedes Upgrade dahinter einfach teuer wird. Gerade wenn man sich diese Mittelvers anschaut, die muss ich natürlich auch anpassen, wenn ich dahinter auch die Daten verändere. Und jede Änderung wird halt einfach komplexer. Genau, das ist halt das Problem, dass dieser Effekt, der taucht im Unternehmen, wenn man sich im TCO das genauer anschaut, einfach nicht auf. weil sie keine direkten Kostenpositionen sind, sondern einfach ein struktureller Effekt, der aus diesen Symptomen, wie zum Beispiel diese Integration zwischen zwei Systemen, auftretet. Genau deshalb werden sie einfach unterschätzt. Und jetzt kommt halt das Entscheidende, diese Effekte wirken halt nicht sofort. Das baut sich halt auf. Schritt für Schritt, Entscheidung für Entscheidung. Und irgendwann kippt das halt. Und plötzlich ist das halt teuer. Und dann beginnt man halt zum Optimieren. Die Betriebskosten mag man senken, die Verträge werden einfach neu verhandelt und Systeme werden einfach neu betrachtet. Das ist auch alles sinnvoll, aber halt zu spät. Und die falschen Entscheidungen werden leider dazu oft getroffen, weil die eigentliche Ursache nicht angegangen wird. Die Struktur, die Architektur, Leute. Und genau deshalb ist für mich die wichtigste Frage nicht, was kostet mich ein System, sondern warum kostet es mich so viel? Und was passiert, wenn ich es ändere? Was ist, wenn ich dann Schrauben verändere? Und genau hier kommt halt die Enterprise-Architektur wieder ins Spiel. Sie ist halt keine Dokumentation und sollte nicht als Modell betrachtet werden, wie so oft, sondern als Kontext für jede Entscheidung. Architektur macht sichtbar, was die SEO nicht zeigt. Die Abhängigkeiten, diese ganze Koppelung, die Veränderbarkeit und Geschwindigkeit und vor allem das Kalierungsverhalten. Und genau das brauchst du, weil sonst triffst du Entscheidungen auf Basis von Zahlen, ohne das System dahinter zu verstehen. Und genau das führt halt zu dem Effekt, den ich immer wieder sehe und selbst auch zu falsch beantwortet habe und betrachtet habe. Systeme wirken am Anfang einfach zu günstig und werden über die Zeit teuer. Und nicht, weil sich der Preis verändert hat, sondern weil sich die Struktur so eine Auswirkung zeigt. Und genau deshalb ist für mich klar, TCO ohne Architektur ist einfach blind. Und genau darauf bauen die nächsten Folgen einfach auf. Weil wenn du TCO wirklich verstehen willst, musst du anfangen ihn zu zerlegen in Einzelteile. Wir müssen den zerlegen und filetieren auf Anwendungen, wir müssen auf Domänebene uns das Ganze betrachten und vor allem wir müssen auf deine Capabilities achten und schauen. Weil erst dann siehst du, wo Kosten wirklich entstehen und wo du eingreifen und sie steuern kannst. Und genau das ist der Punkt, den ich dir heute mitgeben möchte. Der Total Cost of Ownership ist so wichtig, aber ohne Architektur bleibt sie oder es oder er einfach blind. Wir blinds Händler. Und genau, das war eine gute Anekdote, blinds Händler, mein Huhn, egal. Und genau deshalb ist Architektur halt kein IT-Thema, sondern ein Kostenthema. Ein Steuerungsthema und am Ende ein Business-Thema. Ich hoffe, du konntest etwas für dich mitnehmen. Möge die Enterprise Architektur mit dir sein. Servus und Baba und bis auf bald.