EAM#8: Erst billig, dann teuer - Warum passiert das?

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. Sehr gut, grüß dich und herzlich willkommen zu einer neuen Folge. Heute sprechen wir über ein Muster, das du wahrscheinlich kennst. Projekte starten in der Regel immer günstig, oft leider zu günstig und am Ende sind sie alles andere als das. Die Frage ist nicht, ob das passiert. Die Frage sollte eher lauten, warum passiert das immer wieder? Und, vielleicht noch wichtiger, warum hat das weniger mit schlechten Entscheidungen zu tun und vielmehr mit deiner Struktur? Du gänst das. Da ist eine Idee. Ein neues Geschäftsmodell. Vielleicht auch ein neuer Channel. Als Beispiel ein klassischer Online-Shop, der plötzlich zum Marktplatz werden soll. Tora, tora, wir wollen mehr verdienen. Am Anfang klingt das alles als machbar. Jeder sagt, ja, wir können das. Da steckt man einfach das Interface mit dem, verändern da den einen Prozess und damit geht das schon irgendwie. Man fängt an, den Job einfach schnell zu erweitern oder da wird ein paar Services dazu gestoppelt. Ein bisschen Integration. Naja, du kennst das. und dann startet das Projekt einfach. Meistens kenne ich das auch aus dem klassischen POC oder dieser ominöse Begriff MVP, wo jeder etwas anderes darunter versteht. Budget passt. Naja, am Anfang halt. Und die Timeline auch am Anfang halt. Und alle sind zufrieden, denen sich zurück und dann das schon losgehen. Und dann passiert etwas interessantes und das ist nicht nur in einem Projekt so, sondern fast in jedem dieser Art von Projekten und zwar passiert es nicht plötzlich, sondern wieder wie alle Schulden, die wir so kennen schon, sehr schleichend und hinterlistig. Es kommen Fragen nämlich dazu. Wie und wo Wir die externen Händler, wie läuft das Pricing dahinter, wer verantwortet eigentlich welche Daten, können wir überhaupt dieselben Datentöpfe nutzen, müssen wir da vielleicht etwas umbauen, nein, nein, nein. Wir gehen hier überhaupt mit Retouren um oder was passiert bei diversesten Konflikten. Und jetzt wird es in der Regel immer super spannend und interessant. Und das, was ich hier auch ein bisschen wiedergebe, ist auch ein bisschen sarkastisch gemeint von einem Projekt oder zwei Projekte, die ich begleitet habe, die ein ähnliches Verhalten gehabt haben. Denn diese Fragen sind einfach keine Feature-Fragen, das sind reine Strukturfragen. Und du als Architekt bist eigentlich verantwortlich, diese auch gar nicht aufkommen zu lassen. Bedeutet vielleicht, dass der eine oder andere Asset fehlt, die eine oder andere Dokumentation oder dass auch deine Kommunikationskette nicht korrekt abläuft. Der erste Bruch dahinter sind halt genau das. Die Systeme werden mit Capabilities verglichen. Oder Systems-Worse Capabilities, wie es so schön im Englischen heißt. Am Anfang denkst du nämlich, ich baue ein komplettes System neu. also das ist in unserem Beispiel jetzt diese Marktplatzlösung, aber in Wirklichkeit baust du ja eine neue Fähigkeit auf und veränderst bestehende Fähigkeiten. Und genau hier kippt Limit das Ganze. Denn so ein Shop ist eigentlich relativ klar, also da ist jetzt keine Xenwirtschaft dahinter. Produkte, die angezeigt werden müssen in einer Art und Weise, wenn überhaupt vielleicht auch in der Zukunft noch, wird das vielleicht auch gerade durch ChatGDB und wie sie alle heißen, anders ausschauen. Wie auch immer, wir müssen Produkte am Ende des Tages haben, um sie verkaufen zu können. Wir brauchen einen Card und wir brauchen einen Checkout-Prozess. Aber wenn man sich jetzt einen Marktplatz anschaut, ist der natürlich viel komplexer. Denn da habe ich ein anderes Spiel, kommen andere Fähigkeiten, andere Perspektiven, die man einnehmen muss. Man hat ein Multivendor-Management, man hat extrem krasse Vertragslogiken, die eingehalten werden müssen, beiderseitig. Ich habe Transaktionen in verschiedenen Richtungen, nicht nur in eine, sondern genau auch in die andere Richtung. Ich habe Datenhoheiten auf einmal, die ich vorhin so nicht gehabt habe. Oder ich gebe sie auch raus. Und ich muss halt Governancen hochziehen, die ich so auch vorher nicht gehabt habe. Das ist nicht mehr gleich. Wir reden hier von komplett anderer Art von Capabilities. Und das ist dann wirklich eine andere Art von Architektur. Und warum ich nochmal kurz zu deinem Start zurückkommen möchte, warum schaut das am Anfang eigentlich so günstig aus für jeden? Warum glaubt jeder, das ist jetzt eine billige Aktion, wir sind in einem halben Jahr, Jahr fertig und das rogt man schon irgendwie runter? Weil du nur das siehst, was direkt vor dir liegt. Du schaust drauf auf deine Lizenzkosten, die sind gleich, die Entwicklungen, da wird sich ein bisschen was verändern, das kann eigentlich schon jeder schön planen und auch kalkulieren in der Regel, wenn man ein fixes Entwicklerteam hat. Und ich kenne auch meine Integrationen und auf welche Art und Weise wir Integration im Unternehmen machen. Das ist der klassische TCO-Blick oder auch die Sicht von Controlling aus der Perspektive. Aber der ist halt zu kurz. Denn was du leider nicht siehst dabei, sind die gesamten organisatorischen Anpassungen, die du an der Stelle machen musst. Und viel schlimmer sind genau diese Prozessbrüche, die einfach stattfinden müssen, um diese Fähigkeiten in Richtung ausbauen zu können oder zu verändern. Auch klar diese Datenverantwortlichkeiten, die dabei sich verschieben oder auch verändern, klarerweise. Und von den Abhängigkeiten möchte ich jetzt gar nicht reden. Aber, und genau die kommen dann alle später. Lass uns mal über den zweiten Bruch noch reden. Diese bestehenden Systeme, die du im Hause hast. Jetzt wird es nämlich richtig teuer. Gut zuhören, habe ich leider zu oft gesehen. Denn du startest ja nicht auf Greenfield. Das hast du ja nicht. Du hast ja schon einen Shop. Der läuft, der ist wahrscheinlich auch super modern. Oder auch nicht. Er nimmt auf jeden Fall eine gewisse Art von Kunden auf, Transaktionen, und das muss gesteigert werden. So, jetzt hast du halt drei Optionen, wenn du das Ganze drehst. Entweder du baust das halt direkt um, das heißt, du transformierst das bestehende System, das klingt immer in der Regel sehr effizient, ist halt aber immer oft super riskant, weil das System dafür natürlich nicht aufgebaut ist. Gerade dieser Wechsel, dieser massiver von klassischem B2C oder B2B-Shop zum Marktplatz, in welche Richtung das B auch geht, das ist halt eine komplett andere Hausnummer. Und du zwingst das in eine Rolle halt rein, für das es einfach nicht gebaut ist, Punkt das. Zweite Option, die natürlich noch im Rahmen steht, ist, wir bauen was parallel auf. Und wir kaufen uns was Neues ein. Das klingt am besten, weil das ist Greenfield. Da können wir tun und lassen, was wir möchten. Blöderweise ist das aber dann auch teuer, weil du natürlich ja plötzlich doppelte Strukturen hast. Und, ah ja genau, da ist ja noch was. Integration musst du auch alles doppelt machen. Ja, kommt drauf an, was für eine Art Integrationsarchitektur du hast. Aber ich rate mal, du machst alles doppelt. Die dritte Option. die natürlich auch im Raum steht oder stehen könnte ist halt dieses Schrittweise erweitern Stück für Stück das klingt meistens super logisch das ist aber witzigerweise die super teuerste Oriente warum? weil du natürlich dauerhaft in einer Art Zwischenzustand bist und genau dieser Zustand frisst dann Geld was ich davon rede sind diese klassischen Curve-Art-Konstrukte wo ich im Endeffekt Stück für Stück das immer wieder weitere ausbaue und danach immer wieder hin und her springe. Die eigentlichen Kostentreiber, die dahinter stecken, sind somit nicht klar die Technologie, die du einsetzt und schon gar nicht die Lizenzen, sondern eigentlich diese Transition, die stattfindet. Diese Phase wird massiv unterschätzt. Und oft einfach erst gesehen, wenn man an einem Punkt angelangt, wenn mal was nicht so funktioniert, wie es funktionieren sollte. Weil sie nicht geplant wird. Also diese Phase. Auf einmal ist sie da und man weiß jetzt nicht, was machen wir jetzt damit? Brauchen wir mehr Zeit? Brauchen wir mehr Entwickler? Am Ende braucht man mehr Budget. Das steht auf jeden Fall mal klar. Und genau hier entstehen eigentlich genau diese Workarounds. Ich brauche halt einfach von allem mehr. Ich brauche mehr Integration an der Stelle. Ich brauche gegebenenfalls mehr temporäre Lösungen. Ich muss irgendwie Mittelwärts dazwischen aufbauen, die irgendwelche Logiken abnehmen, weil ich sie einfach nicht auch später brauche. Und damit steigt einfach diese Komplexität und man differenziert dann nachher zwischen den einzelnen Lösungen komplett anders. Und oft bleiben genau dieser Sauhaufen, Entschuldigung für dieses Wort, aber der bleibt dann nachher drinnen, weil keiner das Ding nochmal anfassen möchte. Gerade wenn es um so Transaktionen geht oder Produktimporte oder irgendwelche Exporte zu Großsystemen. Die will man nicht immer wieder anfassen, aber genau hier fängt man mit solchen primären Lösungen an oder diesen blöden drei Buchstabenbegriffen. was ich vorhin gesprochen habe, von POC, MVP und TQB, wie die alle heißen. Alles halbe Lösungen. Ein klassisches Beispiel, gerade auch wenn man von Marktplatzlösungen oder so, von Multivendorlösungen redet, dass man, wenn man zum Beispiel so einen Dealer on-boardet, dann baust du in der Regel halt ein kleines Tool auf, was das halt ermöglicht. so ein Onboarding-Service oder Plattform oder Frontend, das muss halt irgendwie gemacht werden. Das Blöde ist, das ist in der Regel recht schnell gemacht, aber du merkst aber, wo es richtig hapert, sind diese Validierungsprozesse dazwischen. Natürlich gibt es immer schwarze Schafe bei den Händlern und die müssen halt vorab validiert werden. Du brauchst natürlich die Prozesse dahinter. Und vielleicht auch diese Legal Commitments, die dafür eigentlich zwingend notwendig sind, um zu prüfen, ist das ein guter Händler, ist der zahlungsfähig, liefert der auch brav, was hat der für ein Ranking. Also wächst ein Tool und irgendwann ist halt ein eigenes System, diese Temprimärerlösung, vor der ich vorher gesprochen habe. Und klar, meistens halt ohne klare Architektur, du hast überhaupt keine klare Verantwortung und das Ding bleibt einfach für die Ewigkeit und du hast einfach keinen Bock, weil das von Anfang an klar war, dass das in die Hose geht. Und der dritte Bruch noch, wer auf Organisationsebene der noch kommt. Und jetzt kommt nämlich der Punkt, der wirklich überhaupt kein Mensch auf dem Schirm hat. Und ist halt einfach die Organisation als solches. Denn ein Marktplatz verändert nicht nur die IT, sondern sie verändert eigentlich alles rum herum nochmal. Also die Rollen und Verantwortlichkeiten und vor allem diese Entscheidungswege. Man braucht sich nur anschauen, der ganze Delivery-Part von den Produkten, dieses Lagermanagement, also die Logistik dahinter, das verändert sich durch das. Und plötzlich hast du halt Fragen, wer entscheidet über die Händler, wer trägt welches Risiko, und wer steuert am Schluss die Qualität für uns, die für uns so zwingend notwendig ist, um eigentlich unser Hauptziel, was wir eigentlich erreichen wollen. Wir wollen mehr Transaktionen, wir wollen die Kunden länger auf unsere Plattform binden, wir wollen, dass diese Produkte, die da auch von Dritthändlern rausgeschickt werden, dem Standard entspricht, den wir auch verfolgen. Und verspricht diese Beschreibungen und diese Meta-Beschreibungen dem, was das Produkt am Schluss auch verspricht. Und wenn es am Kunden zurückkommt, das ist das eine. Und anderes Qualitätsmerkmal ist halt oft genau dieses Retourmanagement. Wenn wir uns Shops anschauen, die mit kleinen Produkten arbeiten, dann ist es ein bisschen einfacher. Aber sobald du halt wirklich große Teile dazwischen hast, wie einen Kühlschrank oder irgendeinen Fernseher, dann ist das Retourenmanagement immer so ein riesen Fiasco. Kennst du vielleicht privat auch? Hast du einen Kühlschrank gekauft, nach zwei Wochen ist das Ding kaputt. Dann darfst du dir die Spedition anrufen oder du darfst dich halt darum kümmern und jetzt stell dir vor, du hast halt da Händler, über Händler, wo genau diese Probleme auftreten. Weil Spedition in der Regel ja auf den Händler getragen wird, das schipperst ja du nicht alleine raus. oder du nicht das Architekt, aber dein Unternehmen. Und wenn das nicht klar ist, all diese Elemente, dann entstehen einfach unmaßviel Kosten und die sind halt einfach nicht sichtbar. Also sie werden halt permanent bleiben. Ist egal, wie gut deine Technologie dahinter ist und wie gut dein Shop war und wie auch deine Umsetzung dahinter ist. Wenn du das nur zuerst klar definierst, dann wirst du reitestellend auf die Schnauze fallen. Und warum eigentlich dann nachher hier der klassische TCO versagt aus meiner Sicht. Weil einfach der Total Cost of Ownership, der fragt nämlich etwas. Der fragt, was kostet das System? Aber die bessere Frage dahinter wäre eine andere, was kostet eigentlich die Fähigkeit in der Organisation? Oder vielleicht noch besser eine andere Frage, die du dir könntest was kostet die transition dieser capability also was kostet die veränderung dieser fähigkeit in der organisation und genau da liegt halt der große unterschied diese fähigkeiten die sind einfach nicht ausgebildet bei dir wahrscheinlich das nehme ich mal einfach in den raum rein ich kenne halt wenige unternehmen die ein wirklich gutes capability management haben und wissen was ihre Ecke über das Ende des Tages kosten. Die wissen, was das System vielleicht kostet, von technischen Schulden, das man mal aus und vor, aber sie wissen nicht, was die Fähigkeiten kosten und was eine Veränderung dieser Fähigkeit mit sich bringt, abgesehen von den Kosten selber. Die Realität dahinter ist natürlich, die Kosten entstehen nicht durch das, was du baust, sondern die entstehen halt durch das, was du veränderst. Das weißt du. Aber du weißt vielleicht nicht, dass du eher auf die KB-Bitte schauen solltest. Und je stärker diese Veränderung eintritt, desto höher die Kosten dahinter und desto länger dieser Übergang. Und viel schlimmer für das Management, desto größer die Unsicherheit, dass was schief geht. Der entscheidende Punkt. Die meisten starten günstig, weil sie zu klein gedacht werden. Nicht weil technisch oder die IT jetzt versagt, sondern weil die strukturellen Folgen einfach so massiv sind. Man sieht einfach nur Features vor sich. Wir brauchen der Ist, der Ist, das muss das und das können und das muss so schön aus sein und der Button muss so groß sein. Man fängt wirklich mit solchen Sachen zum Reden an. Die UI ist das Wichtigste. Aber nicht die eigentlichen strukturellen Abhängigkeiten dahinter. Organisation und die Transition wird aus dem Wind geschrieben. Und da kommen genau die Enterprise Architekten. Da ist ihre Stärke. Da ist deine Stärke. Was du daraus mitnehmen könntest oder solltest. Wenn du das nächste Projekt siehst, frag nicht, was das System kostet. Frag lieber, was diese Veränderungen kosten. Was sie bedeuten. Und auch, was bedeutet das für deine Architektur. Und wie lange leben wir mit diesem Übergang. Denn genau dort entstehen die echten Kosten in der Architektur und in deiner IT. Und genau darüber sprechen wir in der nächsten Folge. Denn wenn diese Kosten entstehen, dann sind sie oft nicht sichtbar. Nicht im Budget und schon gar nicht im Reporting. Aber sie sind halt da und sie wirken auf dich. Wenn du verstehen willst, warum deine Systeme teuer wirken, aber es eigentlich nicht die Systeme sind, Dann bleibt dran und wir sehen uns zur nächsten Folge. Servus und Baba und bis auf bald.