EAM#7: TCO verstehen (Special) - Was klassische TCO misst. Und was nicht

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 ERM. Servus, grüß dich und herzlich willkommen bei einer neuen Folge. Die Folge 7 ist ein Special und heute wird es ein bisschen länger werden. Also, nimm dir Zeit und genehmigt dir vielleicht einen Kaffee, den du wirst wahrscheinlich brauchen. Bevor wir richtig starten, möchte ich dir ein bisschen was Persönliches mitgeben, wie ich eigentlich zu dem Thema rund um Kosten gekommen bin. Es ist ja eigentlich nicht selbstverständlich, dass man aus der Softwareentwicklung sich Gedanken macht, was etwas kostet und als Lucian Architekt, um ehrlich zu sein, ist uns das auch egal. Aber dort waren für mich eigentlich immer die Kosten präsent und wie so ein negatives Schwert oben drüber und man musste immer auf Zeit arbeiten und Zeit ist am Schluss Budget. Ich habe viele Situationen erlebt, in denen wirklich jeder Euro mehrfach hinterfragt wurde. Und zwar nicht irgendwo, sondern genau dann, wenn es in der Tat um etwas Wichtiges gegangen ist. Ja, genau, um Qualität. Und dann sind so Fragen gekommen von den Projektleitern und Stakeholder. Brauchen wir diese Architektur wirklich? Müssen wir das so sauber bauen? Oder geht das nicht auch einfach einfacher und damit günstiger? Nein. Aber ja, das ging mir nicht nur in der Architektur so. Denn auch als Senior-Entwickler oder als reiner Dev war immer das Thema, für Dokumentation ist keine Zeit, für Code-Qualität interessiert am Schluss auch keinen und können wir nicht einmal richtig beweisen. Und saubere Architektur-Pattern im Code interessiert dann auch keinen. Und das ist ehrlich, die Diskussion hat dich so satt, immer wieder darüber zu argumentieren, warum man etwas so programmieren möchte oder so entwickeln möchte, weil man mit einem gewissen Mindset ja natürlich das Ganze tut und nicht einfach nur, weil ein Zirkusdirektor sagt, so schnell mal eine Runde spielen und dann sind wir fertig. Das war echt immer an einem Punkt, wo ich dann einfach nur den Kopf geschüttelt habe und dann rotzt man halt den Kot runter. Ja, schön. Und dann natürlich ist Geschwindigkeit das Thema. dass gerade Qualität kostet manchmal ein bisschen mehr Zeit, ja, aber am Schluss hast du ja wieder was davon und damit reduzierst du ja dann nachher Kosten. So, um ehrlich zu sein, ich habe damit eigentlich immer Zeit mit Kosten verbunden. Also Zeit gleich Kosten. Weniger Zeit, weniger Kosten. Mehr Zeit, mehr Kosten. Und das ist etwas, wo es mich, glaube ich, die ganzen letzten Jahre, also wie gesagt, ich mache seit 28 Jahren das Ganze und war Entwickler bis mindestens, ich glaube, 21, also nicht 21 Jahre, sondern 2021. Und da ist es immer um das Gleiche gegangen. Immer nur das Geschwindigkeit und damit Geschwindigkeit gleichgesetzt mit Kosten. Ich glaube, mit jetzt AI-Entwicklung wird sich da einiges verändern und die Code-Qualität, ich weiß nicht, ob sie besser wird oder schlechter wird, ich möchte das auch gar nicht jetzt an der Stelle beurteilen. Nebenbei, ich war auch sehr lange Zeit Projektmanager und mit sehr lange Zeit meine ich wirklich sechs Jahre. Und da hast du natürlich einen gewissen Druck und musst halt Deadlines gegenüber deinen Kunden einhalten, du musst liefern, du hast, du hast es nicht das Problem, du kannst es nicht wirklich steuern. Also aus der Projektmanagement-Sicht natürlich, aber du kannst nicht die Entwickler so steuern, dass sie jetzt nach deinen Coderegeln arbeiten, dass sie so coden, wie du selbst coden würdest, dass sie Architekturen so setzen, wie du das selbst machen würdest. Das sind natürlich die Aufgaben dementsprechend verteilt. Und dementsprechend verstehe ich natürlich auch aus der Projektmenschwenz-Sicht, dass Dokumentation wirkt wie Zeitverschwendung oder dass halt die geile Architektur wirkt wie purer Luxus. Und ja, Großqualität ist dann, wie man so schön sagt, nice to have. Aber genau das ist das Spannende, finde ich, immer wieder in Architektur. Denn da passieren eigentlich die Fehler. Und wir haben im März über technische Schulden vorrangig gesprochen. Und dieses Monat, also April, wird sich das in eine andere Richtung ziehen. Und ich hoffe, du wirst gleich feststellen, was es geht. Es wird hauptsächlich wirklich um den Total Cost of Ownership gehen. Und nochmal zurück zu der persönlichen Erfahrung dahinter. Diese Kosten, die dadurch entstehen, die entstehen nicht, weil die Leute schlechte Laune haben oder so. Aber der Fokus ist einfach falsch. Also es ist nicht immer die Geschwindigkeit, die im Endeffekt guten Projekte voraussagt. Es ist im Endeffekt mit einer gewissen Gründlichkeit Arbeit zu machen, um damit halt langfristig die Kosten zu reduzieren. So einfach ist es. Denn genau über die Zeit, so wie wir über die technischen Schulden gesprochen haben, kommt im Endeffekt dann die Wart schon von oben drauf. Und dann, ja, das habe ich leider zu oft gesehen. und darüber bin ich eigentlich über die Kosten am Ende des Tages gestolpert. Denn schnelle Lösungen werden am Schluss zum Problem und fehlen Dokumentationen, oft zum Risiko, weil kein Mensch mehr weiß, was man eigentlich gemacht hat. Und ja, blöder Code oder schlechter Code ist einfach eine echt schlechte Bremse, die man nicht angezogen haben möchte. Und dann passiert genau das, man eigentlich vorher vermeiden wollte. Es wird aber am Schluss teuer. Und leider, das ist genau, warum ich dann diese Architekturrichtung so ein bisschen auch für mich geändert habe. Es wird halt nicht sofort teuer. Das kommt erst ein bisschen später und über die Zeit. Und gute Architekten wissen das und spielen auch diese Erfahrung dann und geben das weiter. Es ist ein Bummering-Effekt. Am Anfang Spaß-Teilzeit und am Anfang sparst du Geld, aber später zahlst du dafür. Das sind einfach die Zinsen. Also eigentlich ist es wie eine technische Schuld, wenn man es genau nimmt. Und plötzlich dauert halt jede Änderung länger und plötzlich versteht auch niemand mehr, wie das System funktioniert. Und dann sitzt du da und denkst dir, warum ist das so kompliziert? Und die Antwort dahinter, Dafür habe ich sehr lange gebraucht. Und das ist vielleicht auch einer der Gründe, warum ich diese Gedanken auch mit dir teilen möchte. Und wie du vielleicht diese Zeit, die ich dafür benötigt habe, überspringen kannst. Die Antwort dahinter aus meiner Sicht ist, weil man früher Entscheidungen getroffen hat, deren Konsequenzen man damals überhaupt nicht gesehen hat. das beschäftigte mich damals schon sehr, sehr lange. Und eine Frage, die ich eigentlich damit mir eigentlich immer durch den Kopf gegangen habe, wie viel kostet das eigentlich? Also es geht mir gar nicht um diese Projektkosten, sondern um diese langfristigen Kosten für das Unternehmen des Projektes. Also von einem Rollout bis zu einer Maintenance-Phase, dann möchtest du da weiterentwickeln und dann fangen die Kosten eigentlich an. Deswegen waren für mich sehr spannende Fragen immer, wann entstehen diese Kosten eigentlich wirklich und warum sehen wir sie eigentlich nicht? Also warum ist es so schwer zu verstehen, zu verstehen, dass man diese Kosten einfach nicht aus tragfähig sieht? Sind das wirklich immer versteckte Kosten? Also eigentlich nicht, weil ein bisschen Krips anschwerfen und dann weiß man schon, dass vielleicht der Code dich irgendwann mal einholen wird. Und so bin ich gerade nicht von der Solution-Architektur gekommen, aber über die Enterprise-Architektur gibt es halt sehr viel Material und Modelle, Methodiken. Und ich bin immer vom Typ einer gewesen, der nicht eine Methodik nimmt oder ein Modell nimmt, eins zu eins und dann umsetzt, sondern sich daraus halt die wichtigsten Sachen rauszieht und danach kombiniert, so wie man das auch in der Entwicklung tut. Da bin ich halt zu viel Entwickler, um zu sagen, das Framework ist einfach das Beste. Nein, ich mag eine Kombi haben und meinen eigenen sinnvollen Input noch dazugeben, sodass das Ganze wirklich kompakt für mich ist. Und dass ich das auch so transportieren kann, dass du oder auch mein Gegenüber das richtig versteht. Und so bin ich eigentlich dann eigentlich zum TCO gekommen. Also wir werden heute in der Folge darüber noch sprechen. Ich werde noch ein bisschen einleiten im nächsten Abschnitt, im Teil 1 davon. was TCO genau ist, aber so bin ich eigentlich zu dieser Sicht gekommen. Also ich wollte immer das vollständige Bild von Kosten erfahren und verstehen und das auf eine sehr sinnvolle Art und Weise. Denn für mich ist TCO etwas, das adressiert etwas und das interessiert Architektur als komplettes Bild. Diese Kosten entstehen halt nicht am Anfang, sie entstehen halt über Zeit. Aber gleichzeitig hat man halt immer das Gefühl, da fehlt noch was. Irgendwas? Ist es die Würze? Und ja, weil ich auch in der Praxis gesehen habe, die wirklichen teuren Themen stehen nicht dort, wo wir bewusst auf Kosten schauen. Also genau das Beispiel mit dem Code und Qualität, Dokumentation, ich bin mir sicher, ich rede auch in deinen Gedanken. Das ist heute noch immer so wie vor 20 Jahren. Und ja, jetzt sind wir genau an dem Punkt. Und ich wollte dich ein bisschen teilhaben an meinen Gedanken, wie ich eigentlich zu dem ganzen Thema gekommen bin, da es eigentlich ein bisschen absurd ist, sich als Architekt über Kosten so intensiv zu beschäftigen. Aber es ist einer der wichtigsten Instrumente und gerade für die Entscheidungen, die man tagtäglich trifft, ist es einer der besten Steuerungsmittel. Teil 1. Die Entstehung von TCO. Und es folgt noch ein Teil 2 nebenbei, wo es eigentlich um die eigentliche Folge 7 geht, aber wie schon beim Prolog so ein bisschen eingebettet, ist das Thema sehr komplex und was ich nicht machen möchte, dich einfach mit Tatsachen zu überschütten. Damit ist wahrscheinlich dir nicht geholfen und ich bin damit nicht befriedigt, meine Informationen und meine Erfahrungen so weiterzugeben, dass das auch richtig am Ende des Tages aufgenommen wird. Wenn wir heute über IT-Kosten sprechen, dann wirkt das oft wie etwas sehr Rationales. Immer sehr strukturiert und super sauber. Aber wenn wir jetzt ein bisschen zurückgehen an der Geschichte, dann war das am Anfang, alles andere als sauber. Ich habe darüber sehr lange recherchiert und was ich herausgefunden habe, ist halt genau das, dass Ende der 80er, Anfang der 90er Jahre haben sich halt die IT in den Unternehmen wirklich massiv geändert. Da hat es irgendwie so einen Technologiesprung gegeben, Hardware-technisch, den ich jetzt nicht weiter recherchiert habe, kannst du vielleicht noch machen, der im Endeffekt etwas ausgelöst hat. Und plötzlich waren Systeme nicht mehr einzelne Maschinen oder irgendwelche Kasteln, die herumgestanden sind, denn die PCs, also die Personal Computer, die kamen in die Breite. Auch die User, also die Kunden, wie du und ich halt, zu Hause hatten auf einmal einen Rechner stehen oder konnten sich das irgendwie leisten. Also damit sind vielleicht auch diese Hardwarekosten irgendwie reduziert worden aus irgendwelchen Gründen. Und die Serverlandschaften unter Anführungszeichen, die sind einfach stetig gewachsen, weil einfach der Hunger nach Datenhaltung langfristig und auch Datenverarbeitung langfristig einfach extrem gewachsen ist. Und so entstanden auch diese ersten Netzwerke. Also erinnern wir uns an das Internet, woher das kommt eigentlich? Im Gerichtensinne war das eine militärische Geschichte dahinter. Und diese Vernetzung von Informationen, der Bedarf an Kommunikation, um im Endeffekt strategisch, langfristig oder taktisch Entscheidungen treffen zu können, hat da sicher einen großen Ausmaß gegeben. Und damit ist etwas Wichtiges passiert. Die IT ist auf einmal richtig teuer geworden, weil einfach der Hunger so groß war. Und nicht nur ein bisschen, sondern das ist richtig krass gewachsen. Aber gleichzeitig wurde die IT durch das, dass der Bedarf natürlich da ist und der Hunger, sehr wichtig. Wichtig für das Unternehmen, diese ganzen, heutzutage, wenn wir von Business-Prozessen reden, damals waren das nur reine Business-Prozesse, da hat es keine IT-Prozesse gegeben, oder so wie wir das heute kennen, natürlich in einer gewissen Art und Weise, aber nicht diese massive Breite. Und für IT brauchtest du einen Doktortitel, um irgendwas zu machen. Mathematiker musst du sein, vielleicht auch noch Physiker, um irgendwas zu verstehen. Nichts für mich, um ehrlich zu sein. Somit durch diese Wichtigkeit sind natürlich diese Prozesse und diese Koppelung massiv gestiegen. Auch natürlich das, was heutzutage immer wieder sichtbar ist, diese Abhängigkeiten oder unsichtbar. Und die Erwartungshaltung von der Geschäftsführung und vom Business ist enorm gewesen. Von 0 auf 100 ist das. Es ist nicht so gewesen, dass es wie heute gleichgesetzt ist, sondern es ist von 0 auf 100 gekommen. Und da ist halt ein extremes Spannungsfeld anscheinend. Und Unternehmen mussten halt einfach investieren, müssen am Ball bleiben, aber sie konnten etwas nicht. Sie konnten diese Kosten einfach nicht greifen. Und das ist nämlich genau da, wo es jetzt spannend wird. Wer hat eigentlich dieses Problem als erster gespürt? Ich habe mir gedacht, wie ich angefangen habe mit dieser Recherche, dass es irgendein cooler Softwareentwickler war oder irgendein Architekt, der gesagt hat, ey, wir müssen auf Kosten schauen. Genau das ist es nämlich nicht. Und wenn du meinen Prolog reingehört hast, habe ich ja gesagt, dass Architekt über Kosten sprechen ist immer so eine Sache. Und das war in der Tat früher so, dass das nicht aus der Architektur gekommen ist, sondern da, wo es eigentlich am naheliegendsten ist. das Controlling und natürlich am Schluss auch beim Einkauf. Also genau die Bereiche, die plötzlich Rechnung auf dem Tisch hatten, die sie nicht mehr sauber klären konnten. Und die hinterfragten das natürlich. Warum kostet ein PC plötzlich tausende von Euro, Dollar, D-Mark oder Schilling noch in meiner alten Sprache? Und warum stiegen eigentlich diese Betriebskosten? Warum steigt das die ganze Zeit? Und wer hat das eigentlich unter Kontrolle? Wer kontrolliert das? Etc. Und die IT ist natürlich auch jedes Jahr toll geworden. Und diese Fragen, die sind von heute auf morgen auf den Tisch gewesen. Und natürlich waren die Antworten darauf überhaupt nicht klar. Weil man vor allem wahrscheinlich nur auf Anz geschaut hat, man hat auf den Kaufpreis geschaut. Und natürlich auf die Anschaffungskosten. Was kostet jetzt ein Server oder so ein PC? Und Software-Lizenzen, ich hätte gesagt, ich habe da gar nichts Richtiges gefunden darüber, aber hat es wahrscheinlich auch genauso gegeben. Und die Hardware, die musste auch eingekauft und Main-Ketains, oh Gott, also im Endeffekt gewartet werden. Und damit war die Entscheidung halt oft schon abgeschlossen. Nebenbei kurze Geschichte, ich weiß nicht, die Folge wird extrem lang. Aber ich habe mal vor 2000 rum, also sehr, sehr lange Zeit, in Polen gearbeitet. Und da hat man, also nicht direkt in Polen, aber war dort ein Außenprojekt beschäftigt. Und da hat man mir so ein bisschen erzählt bezüglich der Serverkosten, die gerade irgendwie benötigt werden für dieses Environment, was wir da aufgebaut haben etc. Und dann habe ich halt so gefragt, was das kostet. Dann haben wir es mal keine wirkliche Zahl nennen können. Und es ist ja auch okay, aber was recht funny war in der Geschichte ist, haben die gesagt, ja, aber die Server, die sind jetzt am Zoll. Und diese Zollkosten, die sind richtig teuer, weil man muss da noch ein bisschen extra Geld drauf haben. Und wenn du es genau hinhörst, geht es ja nicht nur um das Geld des Zolls, sondern man muss da dann nachher noch ein bisschen... ich mag nichts von Bestechung, aber man hat schon im Effekt den Zoll ein bisschen Geld zugeschoben, um die Server jetzt schneller durchzureichen. Und dann, was auch noch recht witzig war, ich habe das ehrlich gesagt nie wirklich kontrolliert, aber ich glaube, ich habe das in BWL auch mal auch gelernt, in Österreich früher konnte man Bestechung sogar absetzen. Also es ist Teil von deinem Kostenblock gewesen. ob das jetzt heutzutage auch noch zutrifft und stimmt und ob das auch wirklich gestimmt hat. Ich habe zu der Zeit, dass ich mal in den Raum stehen habe. Ich wollte einfach dich teilnehmen lassen an dieser Erfahrung. Ich habe das damals so spannend gefunden. Zurück eigentlich noch einmal zu den Kosten. Nachdem diese Sachen eingekauft worden sind oder die Entscheidung getroffen worden ist, dann hat man eigentlich noch immer nicht ganz verstanden, was kostet mir der Betrieb, was kostet mir der Support und die Wartung dahinter. Schulung mal dahingestellt und die Energiekosten. Das ist noch spannender, die fahren enorm auf einmal. Klar hat das AKWs noch viel mehr gegeben wie heute, aber trotzdem war der Energiehunger extrem für diese Serverlandschaften, weil die natürlich damals nicht so kompakt waren wie heute. Also glaube ich, ein iPhone heute ist tausendmal stärker aus wie jeder Power-PC damals. Und gerade diese Energiekosten waren wirklich ein Thema und die wurden unterschätzt. Die wurden wirklich kaum nicht unterschätzt, denn diese Rechenzentren waren ja im eigenen Gebäude, meistens irgendwo im Keller, wo es schön kühl ist und kalt. Und die Kühlung auch dahinter, also jetzt die Klimaanlagen, das musst du ja irgendwie bezahlen, unabhängig von dem Server. Und das war einfach so eine Gelddruckmaschine. So viel Geld hat das Ganze gekostet, um das zu halten. Aber es war halt einfach nicht wirklich sauber sichtbar und man konnte diese Kosten auch nicht greifen. Und genau aus dieser Situation heraus ist dann nachher eigentlich dieses, was wir heute kennen, unter TCO entstanden. Vor allem geprägt durch Gartner. Wer kennt Gartner nicht? Es gibt halt sehr viele Sachen vor, wie sich manche Sachen entwickeln, manchmal ein bisschen sehr spooky, wie ich finde, und dahergerissen. Und jeder folgt ihm sofort und hinterfragt auch viele Sachen. Ich will jetzt nicht konkretisieren, was ich in die Richtung treiben möchte von meinen Gedanken. Aber der Punkt ist, Gartner hat damals das Ganze ein bisschen verfeinert. Natürlich hat man sich früher auch schon Modelle überlegt, wie man diese Kosten besser in den Griff bekommt, aus dem Controlling heraus. Und die haben das halt im Kontext von der Infrastruktur und den Arbeitsplatzsystemen in den Fokus gesetzt. Aber viel wichtiger jetzt unabhängig von dem ist, es ist halt damals kein Architekturmodell gewesen. Denn Architektur hat zu diesem Zeitpunkt praktisch nichts zu sagen. Und die klassische Enterprise-Architektur, die gibt es auch schon relativ lange, aber die war damals und leider auch heute in vielen Unternehmen nicht auf dieser Stelle, um überhaupt mit Kosten zu reden oder halt auch wirklich diese Entscheidungen tragen zu können. Und somit war das eigentlich das erste Mal, so wie ich auch herausgefunden habe, wo das danach wirklich sichtbar geworden ist, diese Kosten. Und die Idee war deshalb eigentlich relativ klar. Man wollte nicht nur auf diesen Kaufpreis schauen, sondern man wollte eigentlich diese Kosten über Zeit mehr in den Griff bekommen. Und das war dann einfach so, dass plötzlich dann Dinge sichtbar wurden, die vorher überhaupt kein Mensch auf dem Radar hatte. Also genau dieser Supportaufwand, die Betriebskosten dahinter, dieser Energiehunger, der Energieverbrauch, natürlich die Schulungen, die Wartung, dass ich exakt eine Dienstleister brauche, die im Endeffekt die Schraube da festziehen, mal ein bisschen salopp gesagt. Und damit kam zum ersten Mal so etwas wie ein Realitätscheck rein. Und das hat das Denken dann, glaube ich, komplett verändert. Das muss schon ein bisschen auch so ein Luftwatschen, wie man in Österreich auch sagt, gewesen sein. Und die Entscheidungen wurden dann natürlich besser, die dieses vollwertige Bild hatten. Und damit konnte man auch viel bessere Vergleiche setzen. Und auch diese Budgets wurden nachvollziehbarer. Somit bin ich der festen Überzeugung, dass gerade zu diesem Zeitpunkt auch, der TCO hat Ordnung in diesem wachsenden Kostenchaos gebracht. Und genau deshalb hat sich das Modell selbst durchgesetzt. Auch nicht, weil es perfekt ist. Ich habe mir das einmal genau in der Tiefe damals durchgelesen. Es ist staubtrockener Tobak, das. will man gar nicht angreifen. Und jetzt kommt nämlich das wichtige Teil von der gesamten Geschichte. Jedes Modell bringt nicht nur Klarheit, es bringt auch eine gewisse Perspektive mit sich. Und du als Architekt oder als Entscheider weißt, dass diese Perspektive nur ein Teil ist. Und du brauchst aber so eine komplette Rundumsicht. Also, wenn wir die TCO-Perspektive uns anschauen, dann bringt sie das System, weiter Kosten, weiter Lebenszyklus. Und das hat damals auch recht gut funktioniert, würde ich sagen. Weil einfach die Welt dazu einfach gepasst hat, die Geschichte dahinter. Auch dass diese ganzen Serverlandschaften halt im Haus waren und so. Und ich habe darüber eigentlich wirklich gute Kontrolle gehabt, jetzt durch diese Modelle an den Kosten. Weil die Systeme waren halt wirklich isoliert und klar abgegrenzt. Und man hat halt wenig Vernetzung, hat es gegeben. Klar hat es LAN schon gegeben und diese Vernetzung. Aber es war noch nicht so, dass Systeme so krass integriert waren und dass man sie so dezentral gesehen hat. Zudem gab es auch wenig Hersteller, die halt wirklich hochkomplexe Systeme erstellt haben. Wahrscheinlich einer der führenden war IBM oder HB, die halt da wirklich führend waren. Und jetzt kommt der Bruch. Die Welt hat sich verändert, gerade diese 2000er Jahre, 90er Jahre, 2000er, also die Zeit, wo ich eigentlich in die IT reingewandert bin und weg von den Lochkarten nebenbei, das habe ich Gott sei Dank nicht mehr erlebt. Für mich waren auch die Kassetten und Disketten, die 1.4er, das waren so meine, weil ich habe auch noch diese großen Disketten gehabt, komme ich gerade drauf, was war denn das? Eis, Eis, wurscht. Und das hat sich halt verändert und weil dann nachher die Systeme wirklich integrierter worden sind. Man hat ja viel mehr Informationen gehabt oder der Bedarf, der Datenhunger war immer höher und damit steht natürlich das eine mit sich und die Abhängigkeiten stiegen. Aber dieses Grundmodell ist gleich geblieben. Das hat sich nicht verändert. Und genau daraus entsteht eigentlich heute die Situation, die ich vor einem Prolog so ein bisschen beschrieben habe. Wir hatten zwar gute Zahlen, aber wir hatten keine Sicherheit in den Entscheidungen mehr. Und genau das ist der Punkt, an dem Architektur heute wirklich gut ins Spiel kommen kann. Und warum ich diesen Job auch so liebe, den ich hier auch ausführe. Und auch diese Erfahrung mit dir heute schere, auch wenn, wie gesagt, diese Serie heute ein bisschen sehr lange wird. Aber ich hoffe, dir wird auch klarer, warum ich da so eine Wertschätzung reinsetzen möchte, um dich da wirklich vollständig abzuholen, denn Kosten ist der einzige, finde ich, greifbare Mittel, um die Entscheider, was beim Einkauf und beim Controlling ist, richtig abzuholen. Es ist nicht möglich, mit technischen Argumenten zu kommen, es ist nicht möglich, mit Risiken zu kommen. Du kannst nur mit Kosten diese Bereiche richtig abholen und nebenbei Kosten verbindet auch damit auch die fachlichen Bereiche. Das ist sehr, sehr spannend und vielleicht siehst du das anders oder auch, wenn dann ähnlich, ich würde mich freuen natürlich, da auch ein Feedback zu bekommen, aber das ist wirklich für mich immer dieses Bindeglied und deswegen macht das auch für mich so viel Freude, mich da noch tiefer und weiter reinzufuchsen. Ja, das mal zu der Geschichte und wir hören uns gleich in Teil 2. Teil 2. Was klassische TCU misst und was nicht. Und genau an dieser Stelle möchte ich jetzt nun den Fokus setzen. Wenn wir über TCU sprechen, dann geht es am Ende nicht um die zentrale Frage, was misst dieses Modell eigentlich? Bitte verstehe mich hier nicht falsch. Und schon gar nicht, was misst es nicht? Diese Vergleiche finde ich irgendwie ein bisschen irreführend. Aber genau das ist der Ausgangspunkt für diese gesamte Reihe, über die wir die nächsten Wochen und speziell jetzt im April sprechen werden. Was ist TCO, was misst ihr und was eigentlich nicht? Und das wollen wir mal kritisch betrachten. Nicht um TCO schlecht zu machen oder es irgendwie falsch einzuordnen, sondern richtig einzuordnen. Was leistet es wirklich für dich oder was kann es leisten und wo liegen die Grenzen? Und man kann bei vielen Sachen gerade architektonische Methoden hier mit reinkoppeln. Und das ist nämlich genau das Spannende und das, was mich so fasziniert an dieser ganzen Thematik. Auch wenn es vielleicht für den einen oder anderen, der mit Architektur wenig zu tun hat, sehr eigenartig und trocken wirkt. Ich liebe es. Bevor wir uns damit richtig beschäftigen können, müssen wir uns anschauen, wie sich die Realität verändert hat zu den 80ern und 90ern, wo wir früher im Teil 1 davor gesprochen haben. Denn wir haben, für die, was nicht zugehört habe an der Stelle und gleich in die Folge gesprungen sind, wir haben gesprochen, Systeme sind mehr geworden. Man hat immer mehr Systeme im Keller benötigt oder halt im eigenen Rechenzentrum und umso mehr Systeme ich habe, was kommt dann oben drauf? Ja, mehr Daten. Ich brauchte mehr Daten. Aber das alleine ist es halt nicht, denn der eigentliche Bruch kam eigentlich aus meiner Sicht, das ist einfach meine Sichtweise darauf, kam glaube ich nicht nur mit, dass jetzt mehr Kasseln im Keller standen sind, sondern dass die Technologie sich ja verändert hat. Also vor 2000, gehen wir noch ein bisschen weiter zurück, vor 1990 hat man sehr analog kommuniziert. Es hat zwar schon die ersten Models gegeben und auch die ersten tragbaren Handykoffer, nebenbei ich hatte mein erster war ein Pager, also ich war schon vor 94 herum, damit konnte ich aber auch nur empfangen, aber nicht schicken. Das heißt, diese Internet-Technologie, die war eigentlich davor nicht wirklich gegeben und auch nicht wirklich anerkannt. Und wenn man Bill Gates zuhören möchte, in einer Aussage, wo er gesagt hat, das Internet wird sich nicht durchsetzen, dann hat er irgendwas, glaube ich, falsch verstanden. Apple war da schon ein bisschen gescheitert und hat auch die ganze Reihe mit diesem i ausgestattet. iMac, iMini, nee, iMini nicht, aber iPhone, das i steht ja für Internet eigentlich. So, habe ich das mal gelernt. Egal, das ist nicht ziel der Serie. Also, Ende der 90er und Anfang der 2000 hat sich ja etwas verändert, wie ich finde, und zwar, wie Systeme gebaut wurden. Also, das hat sich komplett verändert. Und die Technologie halt. Das ist einer der wichtigen Treiber auch heutzutage noch. Und damals ist man halt weg von diesen Desktopsystemen gegangen und hin zu reinen webbasierten, verteilten Anwendungen. Gerade Anfang der 2000er, also ich habe, wann habe ich angefangen mit Web, glaube ich, 98 rum, aber so ein richtiger Drill war dann oder Drill oder Verteilung und Umdenken war dann ab 2000 rum, wo auch die richtigen Skriptsprachen rausgekommen sind, mit denen du das auch umsetzen konntest. Und so wurde einfach Web viel stärker, weil es auch viel einfacher ist, das zu publizieren, auch das Kompilieren war nicht mehr notwendig und man konnte kurz schneller von, naja, ich mag nicht die Bläuen sagen, aber die Entwicklung wurde einfach beschleunigt. Ich glaube, das ist einer der wichtigsten Treiber dahinter, warum auch diese Geschwindigkeit von den Kosten in die andere Richtung gegangen ist. Denn die Systeme waren plötzlich nicht mehr an einem Ort, Also nicht mehr im Keller. Das ist immer ein bisschen salopp gesagt. Das ist natürlich Blödsinn. Aber im Rechenzentrum war es wahrscheinlich in ihr oder in bestimmten Räumlichkeiten. Aber was ich hinaus möchte, ist, diese Lokalität hat sich geändert, weil diese Systeme und die Orte haben sich verteilt. Klar, wenn ich halt Web bin, dann möchte ich ja, wenn ich jetzt hier in Deutschland eine Webseite erstelle und Content erstelle, möchte ich, dass es auch in Südaustralien schnell gelesen werden kann, von einer Sekunde auf die andere, mit derselben Geschwindigkeit. Somit mussten ja die Systeme verteilt werden, über Standorte, über die Länder und, wie gesagt, über Kontinente hinweg. Und damit kam halt ein wichtiges Thema dazu, mit dem man halt vorher überhaupt nicht gerechnet hat, und zwar Datenbewegungen. Denn diese Daten mussten plötzlich wirklich übertragen werden. Also vorher war das halt von einem Meter in den nächsten Meter oder innerhalb von einem Meter, weil das Kastel genau nebeneinander gestanden ist vom Server-Rack. Jetzt mussten sie auf einmal plötzlich übertragen werden. Die müssen auch noch synchronisiert werden. Die mussten mehrfach gehalten werden. Und diese Redundanten, die kosten einfach monströs viel Kohle. Und das war wirklich nicht trivial. Also ich kann mich noch gut erinnern, wie ich das erste damit in Kontakt war, wie kompliziert das war in der Entwicklung, diese Synchronisation aufrechtzuerhalten. Auch diese Erwartungshaltung, dass diese Daten sofort verfügbar sind. So schräg war das damals. Und diese Probleme waren gerade aus der Software-Seite sehr schwer handelbar. Und wenn etwas natürlich schwer handelbar ist, schon in der Entwicklung heraus, dann kannst du dir vorstellen, dass die Kosten dahinter explodiert sind. Also hat man eigentlich angefangen, diese technischen Probleme natürlich zu lösen. Man hat halt Replikationssysteme eingeführt, dann hat man mit Spiegelungen angefangen und Zwischenspeicherungen und Mittelwares, die halt Daten abgesaugt haben und dann weitergespielt haben, sie zwischengelagert haben und so weiter. Und du hörst schon, glaube ich, ein bisschen raus, damit ist halt diese Komplexität explodiert. Also das ist so, vor allem wenn man jetzt über das spricht, jetzt lacht man darüber, damals war es nicht so lustig. Denn plötzlich hattest du einfach zu viele Systeme und mit den selben Daten, das was wir ja eigentlich gerade jetzt in der Architektur probieren zu minimieren, nicht dieselben Daten immer an jeder Stelle zu haben, sondern dass man halt mehr zentralisierte Datenpools macht oder DataLakes und man sieht sich dann auch das an einer Stelle, um im Endeffekt den Datenstorage, den Usage zu reduzieren. Und was auch noch wichtig ist, was du auch damals das erste Mal hattest, dass diese Zustände der Daten unterschiedlich sind. Gerade wenn du ein Commerce-System aufbaust, dann hast du eine gewisse Transaktion oder auch ein Finance-System. Wenn du Transaktionen machst von einem Bankkonto zum anderen, dann geht halt diese Transaktion einen gewissen Weg und hat halt verschiedene Zustände. Und diese Zustände sind gerade durch diese Weitläufigkeit über die verschiedenen Länder und Kontinente waren unterschiedlich, weil die Zeit natürlich da ein Faktor war. Und genau das hatte halt wirklich direkte Auswirkungen auf die Kosten dahinter. Und das war halt nicht technisch, sondern das war reiner wirtschaftlicher Natur. Denn wenn es dann mal wirklich überlegt, was so eine Datenreplikation wirklich kostet, das ist unfassbar. Alleine, darauf mag ich jetzt gar nicht eingehen, Aber auch die Synchronisation dahinter. Und was noch viel schlimmer ist, diese Inkonsistenz an Informationen. Und ich rede noch nicht einmal vom Backup. Das lassen wir außen vor. Gleiche andere Geschichte einmal. Aber auf jeden Fall, diese Fragen lassen sich halt nicht mehr sauber einzelne Systeme zuordnen, sondern es ist dann natürlich danach über diese gesamte Systemlandschaft gesehen. So, naja, und der TCO damals, der funktioniert halt genauso. Wir haben das System, den Lebenszyklus und die Kosten. Und das ist halt wichtig. ein TCO misst sehr gut das Ganze, was einem System direkt zugeordnet werden kann. Also schau dir heute mal auch an, wie du deine Kosten siehst oder vielleicht fangst du auch gerade damit an, aber früher hat man halt die Kosten genau auf diesen Sichtweise gehabt. Man hat sich die Lizenzkosten angeschaut oder halt diese Anschaffungskosten über die Zeit dann, natürlich hat man das abgesetzt, die Infrastruktur, die ich habe, den Betrieb, die Wartung und vor allem die Energiekosten, die waren noch immer einer der treibenden Kostenträger dahinter. Und all diese Dinge, die sind natürlich greifbar auch aus der Controlling-Sicht. Vergiss nicht, wir sind damals auch noch immer in der Controlling-Sicht und Einkaufssicht gewesen. Wir waren nicht in der Architektur. Enterprise-Architekten waren, weiß ich nicht, irgendwelche Prinzessinnen, die im Elfenbeinturm herumgegurkt sind und sich niemals runtergetraut haben und Rapunzel gespielt haben. So ist meine Sicht so ein bisschen dahinter vielleicht ein bisschen sehr lächerlich übertrieben, aber wurscht. Aber wie gesagt, all diese Dinge, die sind ja greifbar und die konnte man messen. Also diese Beispiele, die ich vorhin genannt habe. Es waren natürlich noch viel mehr Punkte, die damit reinfließen, aber das geht es ja auch hier nicht. Und eins ist auch wichtig, wenn ich etwas messe, dann muss ich es ja auch reporten. Und das fällt ja danach auch in diese gesamte Budgetplanung rein und auch in diese Margenberechnungen und Co. Und genau deshalb ist ja der TSEO so stark, dass ich ein vollwertiges Bild habe oder haben sollte. Aber, jetzt sind wir wieder beim langen Aber, genau hier liegt auch die eigentliche Grenze jetzt. Da haben wir jetzt genau dieses Problem, denn was Tiso an der Stelle nicht gemessen hat oder misst, sind halt die Dinge, die zwischen den Systemen passieren. Das sind heute ganz entscheidende. Also die Abhängigkeiten, klar. Konkulationen, haben wir auch schon öfters gesprochen darüber, ist extrem nicht messbar aus dieser alten Sicht. Auch die Datenflüsse, nicht messbar, nicht sichtbar, nicht mal gewusst hat, dass es im Controlling, dass es Datenflüsse gibt. Der hat ja das Kastl vor sich gehabt, der hat nicht gewusst, dass das System mit dem anderen System redet und dass darüber pro Sekunde, weiß nicht, wie viele Transaktionen laufen. Und die Prozesskette war ihm natürlich auch nicht klar. Klassisches BPM hat es zwar schon gegeben, das ist auch sehr altes Methodik nebenbei. Vielleicht kommen wir da mal in einer Folge, wo ich über BPM ein bisschen spreche. Und diese Dinge haben aber halt Eigenschaften, die sehr schwer messbar sind, die Abhängigkeiten, Integration, Datenflüsse, Prozesskette und so weiter. Zu der Zeit gab es einfach keine Mittel, das zu messen und auch keine Methodiken. Man hat sich nicht damit beschäftigt. Denn sie sind halt verteilt, sie sind extrem dynamisch, schnell verändert, schnelllebig. Und genau deshalb sind halt diese klassischen Modelle einfach oft nicht ausreichend mehr. Und jetzt passiert halt etwas, das ich extrem spannend einfach auch wieder finde. Die Unternehmen haben halt angefangen wieder zu vereinfachen. diese Zyklen, man könnte wirklich da so eine Wellenzyklus machen, das ist immer wieder das gleiche Spiel. Wir fangen auch jetzt mit AI wieder alles so verkomplexieren. Wir machen uns alles die Welt komplexer und ich sage es, wie sie es in 15 Jahren, vielleicht auch schon früher, wird alles wieder einfacher. Wie auch immer, damals hat man halt genau das auch gemacht und weil es, weil sie es wahrscheinlich nicht besser wussten, weil sie es nicht besser wussten, weil sie mussten das vereinfachen. Und mehr Komplexität ist, du einführst, umso ungreifbarer wird das. Und damit sind wir wieder bei unseren bekannten Kategorien gelandet, die jeder kennt. Wir reden immer nur von Carpex und OPEX. Also ich habe Bücher hier, da schlafe ich schon nur auf der ersten Seite, wenn ich über Carpex lese. Und bei OPEX, die Bücher sind so staubtrocken und ich denke mir dann teilweise, dass das wird sicher auf irgendwelche komischen Unis danach präsentiert und jeder Studi lernt diesen Dreck. Entschuldigung, das letzte Wort habe ich nicht gesagt. Am Schluss redet man wieder nur von, was kostet etwas und was habe ich denn für Anschaffungskosten und was habe ich denn für Betriebskosten. Die Dinge muss man messen können und die Dinge muss man natürlich erklären können. Und das ist, ja, ich weiß nicht, ob es wirklich nachvollziehbar ist, diese Konsequenz oder halt dieses Verhalten, aber es ist so, wie es ist. Aber das Ganze hat leider auch eine Konsequenz und du misst nur das, was halt sichtbar ist, mit diesem Herangehen. Das ist aber nicht die Realität, Leute, und das ist euch, glaube ich, auch bewusst, und sonst würdet ihr wahrscheinlich auch hier nicht jetzt bei Minute 41 oder so noch dabei sein. denn hier genau entsteht halt genau dieses Spannungsfeld den du auch heute oft siehst dass halt eine sehr hohe Kostentransparenz und ein sauberes Modell oft halt keine Sicherheit bringt für deine Entscheidung und dieser Punkt, der hat mich dann weiter beschäftigt und probiert, wie kriegt man eigentlich diese Zahlen raus wie schaffe ich wirklich diese Entscheidung auf den Punkt zu bekommen für meine Stakeholder, dass die auf dem Zahlen, was ich ihnen präsentiere, den eigentlichen Fixkosten oder die Kosten eines Systems und dieses Rundum, sich auch richtig zu messen. Ja, und mit TCO alleine geht das halt leider nicht, weil die das falsch messen. Und TCO misst das genau, für was es gebaut wurde. Aber es misst nicht das, was wir heute für die Entscheidung brauchen. Und genau ist das der Ausgangspunkt für alles, was jetzt auch über die nächsten Folgen, speziell im April, kommen wird. Da reden wir nämlich genau über diese Dinge. Wo entstehen heute wirklich Kosten? Warum sind sie oft wirklich unsichtbar? Und wie kann ich sie trotzdem greifbar machen? Nicht um neue Modelle zu bauen oder zu erstellen, sondern um bessere Entscheidungen treffen zu können. Und das geht es am Ende des Tages. Wir wollen Entscheidungen treffen. Und wir sind Architekten. Und wir wollen steuern. Und wir wollen nicht, dass das Controlling uns steuert, in dem Sinne, was viel kostet oder was wenig kostet, dass du nutzen oder nicht nutzt. Und diese Fähigkeit auch dann bewusst nutzen zu können, dafür werden wir uns dann nachher genau die nächsten Folgen verknüpfen. Und ich freue mich darauf, dir auch meine Erfahrungen aus den Jahren mitzugeben. Wenn du verstehen willst, wo die Echtkosten entstehen, dann müssen wir genau dorthin schauen, wo die SEO heute nicht hinschaut. Servus und Baba und bis auf bald.