# Human-Centric Software Architecture Reviews

**Podcast:** Software Architektur im Stream
**Published:** 2026-02-06

## Transcript

Hallo, ich bin Ibert Wolf.
Freitags mache ich oder Lisa Moritz ein Livestream zum Thema Softwarearchitektur.
Oft zusammen mit Gästen.
Dieser Podcast ist das Audio des Streams.
Weitere Folgen, Sketchnotes und vieles mehr findet ihr unter software-architektur.tv.
Software.
So, dann herzlich willkommen zu einer weiteren Episode von Softwarechitektur im Stream.
Diesmal mit Hans-Jörg Gute.
Jonas konnte es leider heute nicht schaffen, weil er erkrankt ist.
Genau, Hans-Jörg, willst du erstmal ein paar Worte über dich sagen?
Sehr gerne.
Erstmal herzlichen Dank für die Einladung here.
Ich freue mich natürlich sehr heute dabei zu sein und bin auch gespannt auf Fragen, Anmerkungen, Meinungen natürlich.
Vielleicht kurz zu mir, Hans-Jakude.
Ich bin Mitgründer, Geschäftsführer und Berater bei Swag Lab.
Mein Hintergrund ist, ich bin Wirtschaftsingenieur, habe als Entwickler tatsächlich gestartet bei Gruna und Ja hier in Hamburg, war zehn Jahre dort, am Ende im IT-Management.
Hab dann eine Firma gegründet für Software, Verlacksoftware, also ERP, CRM, E-Commerce, so diese ganze Schiene modular aufgebaut.
Das Ganze war ziemlich erfolgreich.
Wir haben das dann nach zehn Jahren an Gruna und Ja verkauft.
Und bin dann eine ganze Zeit als freier Berater unterwegs gewesen und dort am Ende dann beim großen Hamburger Optiker gelandet, bei dem wir uns auch kennengelernt haben.
Das heißt, die Leute, die dann Spec Lab gegründet haben, und das Kernteam heute bilden.
Und das kennzeichnet uns auch ein Stück weit.
Wir haben dort halt auf ganz verschiedenen Ebenen zusammen sehr große Projekte gefahren, sehr große Transformationen im Unternehmen durchgeführt und dabei eben auf ganz verschiedenen Ebenen gearbeitet.
Das heißt, also sowohl im Management, Top Management als auch im technologischen Bereich, im Architecturbereich.
Und habe dabei eben nicht nur in der Technik liegen, sondern öfter, sag ich mal, in der Organisation, im menschlichen Bereich.
And da haben wir halt für uns Arbeitsmethoden entwickelt, die halt gut funktioniert haben.
And the idea bei der Spec Lab-Gründung war eigentlich genau das mitzunehmen und für uns zu leben natürlich und auch beim Kunden zu leben und das dort eben einzuführen.
And dabei steht der menschliche Faktor halt bei uns immer im Mittelpunkt, das kann man ganz klar sagen.
Und das begründet auch das Star-Review, was wir durchführen.
And I glaube wir starten einfach mal mit dem ersten Beispiel, oder Eberhard?
Ja, genau.
Und ich glaube, du hast das schon sehr gut gesagt.
Also, wir, ich arbeite ja auch bei Spec Lab, haben eben diese Geschichte, dass eben der Mensch im Mittelpunkt steht.
And we won't jetzt eigentlich gar nicht so viel anfangen mit irgendwelchen theoretischen Zeug, sondern eigentlich darüber sprechen, welcher Fall oder welche Ansatz weiter sozusagen in der Praxis erlebt.
And I have the idea sozusagen los zu legen.
Und jetzt halt some beispielsweise, also da ist irgendwie die Frage, okay, soll ich halt irgendwie eine gemeinsame Plattform bauen.
And da gibt es halt irgendwelche Funktionalitäten.
Und dann habe ich eben am Ende irgendwie eine Plattform with gemeinsam fachlichem Code.
And ich habe jetzt drei Kästen gemalt with Funktionalitäten.
Dahinter verbirgt sich nicht nur Code, sondern eben auch drei Teams.
And then it's irgendwie die Idee: eine Plattform to bauen von einem anderen Team, die halt diesen gemeinsamen fachlichen Code irgendwie umsetzen.
Und das ist eine Frage, die halt auf den ersten Blick sehr stark architektonisch aussieht, und wo wir im Stream an verschiedenen Stellen Diskussionen hatten über Wiederverwendung.
Und wir hatten irgendwie auch dieses Thema über Product Line Engineering.
Und das ist halt eine Geschichte, die auf dieser architekturellen Ebene erstmal interessant aussah.
Und wo ich, als das eben in dem Kundenprojekt das Thema war, also sollen wir so eine gemeinsame Plattform aufbauen mit einem eigenen Team, das halt eben auch als eine spannende Herausforderung aus dem Aspekt sozusagen gesehen haben.
Und was ich dann halt ergabe, ist, also es gibt irgendwie fachliche Gemeinsamkeiten, was so medium überraschend ist, sonst würde man ja nicht auf die Idee kommen, so eine Platform to bauen.
Das heißt, also man kann sowas irgendwie im Prinzip bauen.
Und dann ist irgendwie eben diese Geschichte mit der Wiederverwendung, das ist halt ein kompliziertes Thema, and da kann man jetzt irgendwie drüber diskutieren, man baut sich halt abhängigkeiten ein.
Es ist schwer herauszufinden, ob Sachen tatsächlich generisch sein sollen und so weiter and so weiter.
So, und als wir das Review gemacht haben, haben wir eigentlich festgestellt, dass das so eine sehr toxische Umgebung war, wo Probleme halt nicht communiziert werden und wo Menschen, die halt Probleme zugeben, dann bestraft werden.
Also in dem Sinne, dass sie nicht geholfen wird, sondern dass sie dann eben wirklich, also dass man sich halt jemand anders sucht, der es halt vielleicht irgendwie besser kann, and dadurch man vielleicht Karriereprobleme hat oder nicht, was auch immer da halt irgendwie passiert.
Man kann das ja von so dysfunktionalen Organisationen.
And das Ergebnis ist halt misstrauen, was eben damit zusammenhängt, wenn, auch wenn ich halt in so einer organization erarbeiten würde, die halt irgendwie so aussieht, würde ich eben anfangen, Probleme nicht zu communizieren, was halt bedeutet, dass ich eben andere Leute nicht erzähle, was gerade Phase ist, was halt bedeutet, dass sich andere Leute nicht darauf verderzen können, dass das, was ich sagen oder zusagen, eben tatsächlich auch passiert anders.
So, and then other Leute mir misstrauen, and ich halte das halt für perfect nachvollziehbar, dass das halt so ist, weil das sind halt die Gegebenheiten, unter denen dort irgendwie dann gearbeitet werden muss.
And for the fall, den we jetzt haben, bedeutet das, dass wir halt an dieser Stelle, wo dieses Platform-Team aufgebaut wird, this platform team eben auch Probleme nicht transparent machen wird, so wie alle anderen eben auch.
Was halt wiederum bedeutet, dass halt Menschen, die halt jetzt, oder Teams, die halt versuchen, diese Plattform to nutzen, unter der Voraussetzung, dass das eben irgendwie fachlich, inhaltlich sinnvoll is, denen halt nicht trauen werden, weil die eben Probleme nicht communizieren werden, so wie alle anderen irgendwie auch.
And that bedeutet halt, dass ich dann ein Problem habe, weil wenn ich jetzt eins von diesen fachlichen Teams leite, die halt diese Plattform halt nutzen oder da irgendwie für aktiv bin, dann habe ich halt möglicherweise das Problem, dass ich halt die Ziele nicht erreiche, weil eben das Plattformteam nicht liefert.
Das kann ich noch nicht mal ernsthaft managen, weil ich keine Transparenz habe in dem, was dort halt an Problem existiert.
Und dann habe ich selber ein Problem, weil ich irgendwie ja auch bestraft werde, wenn ich halt meine Ziele nicht erreicht habe.
Und das, was sie, also was ich machen würde in der Situation, ich halte das für komplett nachvollziehbar und auch völlig logisch.
Ich würde halt meine eigene Plattform bauen.
Und zwar nicht deswegen, weil die jetzt fachlich besser oder schlechter ist, sondern deswegen, weil ich die unter Kontrolle habe.
Und das werden wahrscheinlich alle Teams machen.
Und dann habe ich eben am Ende eben lauter eigene Plattform, beziehungsweise dieses Plattformteam wird halt irgendwie nicht funktionieren.
Und das führt dann dazu, dass man halt, also sicher ein Foliensatz produzieren kann, der jetzt irgendwie darüber diskutiert, ob halt die Wiederverwendung von Systemen in diesem spezifischen fachlichen Kontext halt irgendwie hilfreich und sinnvoll ist.
Das ist auch ein spannendes Thema, also um das ich mich sehr gerne kümmern möchte und auch sehr gerne kümmere, aber es ist halt egal, was halt wiederum bedeutet, wenn man dieses Architekturreview machen würde, also wenn man jetzt irgendwie sagen würde, okay, wir gucken uns das halt an, wir gucken uns an, was es denn dort fachlich zu bauen, wie kriegen wir das vereinheitlicht, wie könnte so eine Plattform aussehen.
Das kann eigentlich keine ernsthaft relevanten Informationen erbringen, weil diese Plattform eigentlich eine Tutgeburt ist aufgrund der Umgebung, in der sie halt aufgebaut werden müsste, die halt dafür nicht irgendwie umgesetzt werden kann.
Was halt bedeutet, dass das Problem eigentlich auf einer sozialen Ebene ist.
Also ich müsste jetzt irgendwie dafür sorgen, dass halt Vertrauen existiert gegenüber diesem Plattform-Team.
Ich müsste dafür sorgen, dass eben Teams, die halt sagen, wir haben übrigens ein Problem, auch tatsächlich nicht bestraft werden, sondern dass man ihnen hilft und so weiter und so weiter.
Was das bedeutet, die Lösung wäre dann eben auch auf dieser sozialen Ebene.
Und an der Stelle war das eben tatsächlich das Ergebnis, was wir da im Wesentlichen präsentiert haben.
Und das war an der Stelle auch interessant und ausreichend.
Wir werden gleich noch Beispiele sehen, wo das halt irgendwie weitergeht und was man da sozusagen sonst noch erreichen kann.
Genau, und ich glaube, das ist das, wo du Hans-Jörg dann sozusagen übernehmen willst.
Ja, sehr gerne.
Genau.
Das zweite Beispiel ist ja ein Merger von zwei großen Unternehmen.
Und folgerichtig wurde dann halt ein Projekt ins Leben gerufen, ein großes Projektprogramm in der Tat, das eben die Konsolidierung der Systemlandschaften zum Ziel hat, nicht, weil man einfach konsolidieren will, sondern weil man eben keine Dinge doppelt entwickeln will, wenn man schneller am Markt sein will und so weiter und so weiter.
Vielleicht mal die nächste Folie.
Und da ist der, sag ich mal, der Einstieg schon sehr interessant gewesen.
Und zwar waren da schon mehrere Beratungen drin gewesen.
Das Projekt war schon einige Jahre alt und hatte auch da nicht wirklich produktive Ergebnisse erzeugt.
Fünf Jahre war der Merger her.
Das heißt also, da ist schon ein bisschen Zeit ins Land gegangen und auch bestimmt eine ganze Menge Geld.
Und wir hatten dann ein Beratungs-, also ein Vorstellungsgespräch eigentlich gemeinsam mit dem Architektur und dem Management-Team dort, also Top-Manager, zwei, drei, die da sich dazu gesellt haben.
Und die haben sich, haben wir hinterher erfahren, eigentlich dazu gesellt, weil sie verhindern wollten, dass eine weitere Beratung da jetzt irgendwie tätig wird, weil vorher hat das halt nicht viel gebracht.
Und wir haben ihnen dann im Grunde genommen erzählt, was wir machen.
Und das sind wir, glaube ich, noch gar nicht so genau drauf eingegangen.
Ja, gemäß des Anspruchs, eben technologisch irgendwie exzellent beim Kunden aufzutreten und Managementkompetenz eben halt auch reinzubringen, machen wir das eigentlich immer mit zwei Personen.
Das heißt also mit zwei verschiedenen Schwerpunkten, sicherlich mit Überschneidungen.
Und wir gehen dann so vor, dass wir mit den betroffenen Menschen halt sprechen.
Das heißt also, wir machen Interviews, die eben halt im Grunde genommen mit einem Menschen des Kunden sozusagen stattfinden und mit zwei von uns, sodass wir eine vertrauensvolle Atmosphäre erzeugen.
Die sind natürlich auch vertrauensvoll, die Interviews.
Und da das Top-Management auch schon gesehen hat, offensichtlich, das eben halt die Probleme auch auf sozialer Ebene liegen, sind wir dann sozusagen von Flagback tatsächlich engagiert worden, was gar nicht so geplant war und sind dann auch direkt reingegangen.
Das heißt also, wir haben sehr schnell eine Akzeptanz erzeugt.
Das mit den zwei Personen ist natürlich dafür auch günstig, weil man eben halt in der Spannungsumfeld menschliche soziale Führungsthemen und Technologie eben halt auch da einfach ein Stück weit besser agieren kann.
Wenn man sich sehr gut ergänzt in so einer Situation.
Diese Gespräche sorgen natürlich dafür, dass erstmal Vertrauen entsteht, weil die Menschen fühlen sich gehört, ja, sind auch wirklich gehört.
Also wir haben ja wirklich, sag ich mal, den ernsthaften Ansatz und glauben daran, dass die Menschen, die an so einem Thema arbeiten, das heißt sowohl User eines Systems als auch das Management, das darauf angewiesen ist, dass die Systeme funktionieren, als auch natürlich die Entwickler und Leute, die in den Entwicklungsteams arbeiten, dass die eigentlich wissen, wo das Problem liegt und meistens auch die Lösungsansätze kennen.
Das heißt also, wir sprechen mit den Menschen, stellen natürlich auch möglichst die richtigen Fragen und kommen auf diese Art und Weise sehr viel schneller zu Ergebnissen.
Also ein normales Review, ein traditionelles Review würde ja eher vielleicht Systeme angucken, den Code analysieren und so weiter und so weiter.
Und würde dann eventuell auch Probleme kommen, die vielleicht da sind, die aber keinen wirklich stören.
Einerseits, andererseits dauert das natürlich viel länger.
Und das macht das Ganze sehr effizient und auch effektiv.
Ja, vielleicht eine eine Folie weiter.
Dazu gehört natürlich auch, dass die Ergebnisse dann nicht irgendwie im stillen Kämmerlein bleiben, sondern dass sie im Grunde vor dieser gesamten Truppe, die wir dann interviewt haben und zusätzlichen Interessierten eben halt dann auch diskutieren, präsentieren in mehreren Iterationen, dass man eben halt auch Feedback dafür bekommt, dass man eventuell Fehler, die man, die man auf dem Weg vielleicht gemacht hat, vielleicht falsche Wahrnehmungen oder oder dass wir die eben halt herausbekommen.
Und es ist natürlich auch so, dass man in einzelnen Gesprächen sehr gut herausbekommt, was für unterschiedliche Perspektiven unterschiedliche Leute haben, die mit diesem Thema zu tun haben.
Das ist natürlich eigentlich das Wertvollste, dass man da natürlich auch Konfliktpotenzial oder Konflikte dann eben genau herausbekommt.
Und das reicht natürlich nicht aus, dass man das einmal macht und aufschreibt, sondern man muss eben halt sehen, dass man dann auch mit den Leuten wirklich in die Diskussion kommt und gegebenenfalls dann eben halt nochmal nachlegt.
Dadurch entsteht ein gemeinsames Bild, und das ist ja häufig das, was fehlt.
Ja, ruhig weiter.
Danke, danke ich überhaupt.
Und in diesem Fall war es jetzt so, dass eben halt das Team tatsächlich gesagt hat, wir hatten eigentlich ganz andere Vorstellungen von der Zielarchitektur und uns wurde vom zentralen Architekturteam da eine wichtige Architekturentscheidung, die uns wirklich massiv beeinflusst, eben halt aufgezwungen.
Während die zentrale Architektur sagte, wir haben eigentlich nur den Moderator gespielt in diesem Prozess und haben da eigentlich die eigene Meinung gar nicht deutlich einfließen lassen.
Das bedeutet ja schon, dass die Wahrnehmung komplett unterschiedlich waren.
Und es bedeutet natürlich auch, wenn das so ist, hätte eigentlich drüber geredet werden müssen vom Vorfeld, dass da ein ungelöster Konflikt auf war.
Und das Misstrauen war halt deutlich.
Es ging halt so weit, dass die Teams, die da betroffen waren, wirklich ein Stück weit blockiert waren.
Also da sind rein äußerlich Dinge passiert, dass zum Beispiel Entwickler, sag ich mal, den Hintergrundbildschirm immer schwarz hatten von dem Zeitpunkt an, weil die Lage halt Fenster war.
Solche Dinge sind da eben halt aufgekommen und man konnte das schon deutlich spüren, dass da eben halt Dinge schiefhängen, gerade in dem Umfeld, das eben nicht rein technisch Natur ist.
Einmal weiter.
Genau.
Das heißt also, das haben wir natürlich in den Interviews rausbekommen.
Und gleichzeitig war es aber so, dass, und das macht eigentlich dieses Review besonders interessant als Beispiel, dass auch keine echte Alternative angeboten werden konnte.
Und das lag on der Deadline, die vom Top Management vorgesehen war.
Sicherlich eine sinnvolle Deadline aus Business Sicht, aber sie hat halt dazu geführt, dass keine wirklich konsensfähige Entscheidung gemacht getroffen werden konnte.
Und es war auf that basis auch keine konstruktive Kritik möglich.
Das heißt, es musste eigentlich clashen.
Einmal weiter gerne.
Das Ergebnis des Reviews war dann, dass das Management tatsächlich diese Deadline verschieben wollte und das auch getan hat.
Und dass dadurch natürlich klar war, die Teams, die ja das Review sozusagen am stärksten beeinflusst haben und die zentrale Architektur, hatten wieder eine Stimme im Konzern.
Und konnten sich offensichtlich mit ihren wirklich wichtigen Anliegen, die ja für das gesamte Unternehmen wichtig waren, auch durchsetzen an der Stelle.
Und das hat dafür gesorgt, dass eigentlich das Ganze wieder richtig zum Laufen kam, die Blockaden sind weitgehend aufgehoben worden und das gegenseitig Vertrauen war einfach wieder da.
Und es hat auf der anderen Seite aber auch dazu geführt, vielleicht eine weiter, dass sich weitere Begleitungen in diesem Projekt ergeben hat.
Das heißt, das sind keine einfachen Probleme gewesen, die da noch übrig blieben hinterher, sondern es waren sehr komplexe, schwierige Probleme.
Und man hat sich dann darauf verständigt, dass eben halt von unserer Seite eine Teilprogrammleitung gestellt wurde, auch auf technischer Ebene weitergecoacht wurde, aktiv mitgearbeitet worden ist.
Und das zeigt natürlich, da war großes Vertrauen aufgebaut worden.
Leute wollten dann auch mit den Personen arbeiten.
Und ja, es ist weiterhin eben halt ein Projekt, das wir begleiten.
Was halt in gewisser Weise, und ich glaube, das ist so eine von den Sachen, die uns hier auch nochmal beschäftigen wird, eben bedeutet, dass es eigentlich mehr als ein Review ist.
Also nicht bei einem Review würde man ja vielleicht erwarten, dass halt das Ergebnis von Foliensatz ist.
Und hier liegt halt das Review, wie du ja gesagt hast, durch diese vertrauensvolle Zusammenarbeit, dass man halt vertrauliche Interviews führt.
Das legt halt den Grundstein für das, was hier auch auf der Folie steht, dass man eben gemeinsam vertrauensvoll and auch innerhalb der Teams vertrauensvoll weiterarbeiten kann.
Und das ist, glaube ich, ein gewaltiger Wert und glaube ich deutlich besser.
Und das ist ja auch das, was auf der Folie, glaube ich, was auf der Folie steht, als wenn man irgendwie sagt, an dieser Architekturebene kann man halt Folgendes irgendwie optimieren, weil das führt dann vielleicht dann mit zu einem Foliensatz, der irgendwie inhaltlich spannend ist, aber der halt einfach nichts im Extremfall nichts ändert und halt liegen bleibt.
Und da ist, glaube ich, der deutlich größere Wert.
Und das hängt eben damit zusammen, wie man es eben macht mit den Interviews und dem der entsprechenden vertrauensvollen Basis an der Stelle.
Ja, absolut.
Ich sag mal, aus meiner eigenen Vergangenheit weiß ich ja auch, wie das ist, wenn irgendwie Beratung von außen reinkommt und dann die Arbeit begutachtet, die man so gemacht hat.
Das ist ja zunächst mal eigentlich keine tolle Situation.
Und wenn man das andersrum macht, dass man eben halt zunächst mal die Probleme der einzelnen Person wirklich aufnimmt und das wirklich ernst nimmt, dass auch die entscheidenden Dinge sind, die man tut, im Grunde genommen, entsteht natürlich eine ganz andere Ebene.
Und die macht auch viel mehr Spaß.
Also mir auch viel mehr Spaß persönlich, als jemand, der dann eben halt mit dem Kunden da an der Stelle zusammenarbeitet.
Und genau, und das, wir haben das an irgendeiner Diskussion, äh an der Stelle, ich glaube, sogar zusammen diskutiert diese Woche.
Nicht ein Review, was sozusagen aus so einer aus einer kontrollenlierenden Perspektive kommt und irgendwie sagt, hey, ich weiß es halt besser und ich zeige euch mal den richtigen Weg, ist halt wenig hilfreich.
Also das ist nicht das, und auch irgendwie, also einmal ist es halt kein Setup, in dem man, glaube ich, gerne arbeitet, und zum anderen ist es halt auch deswegen daneben, weil nicht, wenn man halt von Externen kommt, kann man nicht die Person sein, die das System halt perfekt kennt.
Das sind die Personen, die einem gegenüberstehen, die oder sitzen, die halt irgendwie mit dem System schon lange arbeiten und dann muss man die halt irgendwie auch als Expertinnen für das System auffassen an der Stelle.
Absolut, die eigentliche Leistung, das Reviews auf unserer Seite besteht ja eigentlich nicht, sich tolle neue Lösungen aufzudenken in den meisten Fällen, sondern eben zu gucken, was ist vorhanden an Wissen, wie, welche Lösungsansätze sind eigentlich schon vorhanden und da eher, sag mal, die Perspektiven zusammenzubringen und auch ein bisschen Vermittler zu spielen zwischen den Perspektiven und da Konflikte aufzulösen.
Sicherlich kommen da auch eigene Ideen dazu, die man, die man dann hat und vielleicht diskutiert, aber wenn man mal ganz ehrlich ist, die meisten Themen sind eigentlich schon, sind vorhanden in den Köpfen der Menschen.
Das ist eindeutig so.
Ich würde es denn Nuance anders sehen.
Also ich glaube, du brauchst halt eine fachlich inhaltliche Qualifikation und solltest halt eigene Ideen einbringen, logischerweise, deswegen ist es ja ein Review.
Aber wie soll ich sagen, die Informationen erstmal aufzunehmen und zu verstehen, was da ist und was tatsächlich das Problem ist, das ist, glaube ich, erstmal die Herausforderung und das Thema und die Menschen halt als Expertinnen für das System zu verstehen.
Wenn man dann irgendwie sagt, okay, ihr habt also folgende Lösungsansätze gehabt, ihr habt halt folgende Ideen gehabt.
Was wäre noch mit diesen folgenden anderen Ideen oder das ist halt irgendwie komisch, in meiner Erfahrung funktioniert das nicht.
So ein inhaltliches Feedback ist halt sinnvoll und halt sehr hilfreich.
Aber umgekehrt ist es, der wichtige Punkt ist, sich sozusagen leiten zu lassen, so wie du es ja auch auf der Folie gesagt hattest, durch die Menschen, die halt in dem Projekt sind, um halt zu identifizieren, was erstmal die Hauptherausforderungen sind und nicht irgendwie hinzugehen und zu sagen, naja, ich habe halt eine Idee, wie man sowas typischerweise löst und die ich setze das als Benchmark, sondern eben also zusätzliche Sachen reinzubringen, das ist schon hilfreich, aber eben da nicht zu sehr mit dem eigenen Bias reinzugehen.
Nein, genau.
Also das sehe ich ja genauso.
Also, ich meine, man sieht das ja auch.
Ich wäre vor was weiß ich, zehn Jahren wahrscheinlich noch nicht in der Lage gewesen, solche Dinge durchzuführen, weil man, um die richtigen Fragen zu stellen, auch schnell zu erkennen, was eigentlich die Punkte sind.
Ohne dass man ja das tiefe Detailwissen so schnell aufbauen kann und so weiter, das macht natürlich die Erfahrung bei mir jedenfalls.
Also das muss reifen, dass man so etwas kann.
Bei mir musste es jedenfalls reifen, sagen wir mal so.
Ja, und sich selber halt auch zurückzunehmen und zu sagen, nicht, also ich bin nicht die Person, die irgendwie alles weiß und weiß, wie es halt gelöst wird, sondern immer erstmal zu schauen, okay, die haben halt auch irgendwas versucht, die sind, die beschäftigen sich ganz lange damit.
Offensichtlich haben die halt Herausforderungen.
Warum denn eigentlich?
Und das halt irgendwie sozusagen ernst zu nehmen.
Ich glaube, das ist halt so ein Punkt.
Absolut.
Ja.
Genau.
Ich mache mal die nächste Folie, nicht?
Genau.
Genau, vielleicht noch ein drittes Beispiel, das ist dann auch das letzte.
Das kommt aus einem Unternehmen, auch mit auch ein großes Unternehmen, mehr als 500 Millionen Umsatz.
Und deren Situation, Ausgangssituation, mit der sie bei uns sozusagen aufgeschlagen sind, war eigentlich, dass ein ERP-System ein Update bekommen muss.
Der Update ist eigentlich fast zu wenig gesagt, praktisch ein kompletter technologischer Sprung zwischen diesen beiden, zwischen diesen beiden Releases und das letzte Release, was sie eingesetzt haben, war auch schon einige Jahre alt, viele Jahre alt, konnte nicht mehr abgedährt werden, weil eben halt sehr viele Individualisierungen stattgefunden hat.
Und es war eigentlich ein kompletter Systemwechsel, kann man sagen.
Und das war das Problem.
Das haben sie seit auch mehreren Jahren versucht mit verschiedenen Ansätzen.
Und es ist halt nichts Produktiv ist dabei rausgekommen.
Hier haben wir halt schnell bemerkt, dass das ERP den strategischen Anforderungen nicht gerecht werden kann im Moment in dem Zustand.
Und dass halt außerhalb vom ERP-Problem eine ganze Menge weitere Themen auf der Uhr sind, die auch schon lange liegen und die eigentlich dringend bearbeitet werden müssen.
Das heißt, es ist wirklich massiver Handlungsdruck an der Stelle gewesen, gerne eine Folie weiter.
Das Thema wollen wir gar nicht gar nicht so großartig hier, sag ich mal, inhaltlich jetzt weiter beschreiben.
Es ist auf jeden Fall so gewesen, dass einer der Marktführer in der Beratungswelt da ein Review mit größerer Mannschaft halt durchgeführt hat, zu, denke ich mal, entsprechenden Kosten.
Und das Ergebnis ist hier eben ein Foliensatz gewesen, aber eben keine Handlungsempfehlung, was macht man jetzt eigentlich anders um aus dieser Lage rauszubekommen und wir haben das Ganze mit zwei Personen in wenigen Wochen halt durchgeführt und das Ergebnis ist, dass eben halt ein kompletter Ruck durch die ganze Organisation geht.
Das alte Vorgehen ist sozusagen gestoppt worden, das ganze Projekt ist gestoppt worden, wird jetzt neu initiiert unter ganz anderen Voraussetzungen mit ganz anderen Vorgehen unter Einbeziehung der Business-Ziele und der Projekte, die ansonsten noch wichtig sind.
Das heißt also ein iteratives Vorgehen, dann dieses EIP-System letztlich abzulösen durch ein neues Release.
Und das ist eben sehr, sehr effizient und effektiv gewesen.
Nicht weil wir alles wissen und alles können, wie eben schon gesagt, sondern weil es liegt halt an dem Vorgehen, dass wir rund 25 Personen wirklich interviewt haben, vom Top-Management, also wirklich der Geschäftsführung des Gesamtunternehmens bis hin zu Key Usern und Entwicklern, Spezialisten im ERP-Bereich durch die verschiedenen Business Units durchgegangen sind.
Und das bringt uns halt schnell in die Lage, ein Gesamtbild eben halt zu haben, dass dann auch eine kausansfähige Entscheidung hervorbringt.
Was halt vielleicht dazu führt, dass man Reviews sozusagen an was anderem messen sollte, nicht?
Also nicht an dem Erkenntnis gewinnen, sondern an dem, was man sozusagen auf die Straße bekommt.
Und das zeigt sich hier ja sehr deutlich.
Also, vielleicht ist in diesem Foliensatz ganz viel Informationen drin, was halt irgendwie total spannend is.
Aber es halt eben nichts geändert.
Und das wird eben wie anders, wenn man es eben so, wie du, wie ihr es hier gemacht habt, da proaktiv macht und eben gleich eben auch ins sozusagen ins Doing halt rüber geht und eben auch diese vertrauensvolle Basis schafft und auf derart sozusagen exekutiert.
Und das ist, glaube ich, da eine wesentliche Vorteil.
Genau.
Ich mach mal weiter, oder?
Sehr gerne.
Genau, also führt zu der Frage, was sind die denn eigentlich, diese Star Reviews?
Und da steht, genau, das war, wolltest du, glaube ich, nochmal sagen.
Ja, das kann ich gerne machen.
Also ich glaube, wir haben es schon ein Stück weit natürlich jetzt erläutert, einfach nochmal zusammenfassend.
Aus unserer Sicht ist es eben halt so, Architektur ist natürlich, umfasst die technischen Aspekte eines Software-Systems, das ist ganz klar und dagegen will auch niemand was sagen.
Aber die Architektur ist eben auch sehr stark abhängig von der Organisation drumherum.
Und einerseits abhängig von der Organisation, andererseits hat sie auch Auswirkungen auf diese Organisation im Gegenzug.
Und deshalb sind wir halt der Meinung, dass wir beide Aspekte betrachten müssen.
Das reflektieren wir, indem wir auch mit zwei Beraterinnen eben halt auftreten, die unterschiedliche Schwerpunkte haben, sicherlich Überschneidungen haben, aber unterschiedliche Schwerpunkte haben.
Und nach unserer Erfahrung ist halt der organisatorische soziale Aspekt wesentlich häufiger der Ursprung von Problemen als wirklich technische Dinge.
Und durch dieses Vorgehen haben wir halt schnell Akzeptanz, wir schaffen schnell Vertrauen und damit auch die Basis, dass Konsensentscheidungen hinterher stattfinden können und die Dinge wirklich bewegt werden und nicht nur erkannt werden, die eventuell da sind.
Achso, genau, vielleicht kurz dazu.
Also die sozusagen zwei kleinen Ergänzungen.
Die eine Sache ist, diese Idee, dass man halt im Unternehmen rumläuft und mit Menschen redet.
Die hatte der Nick Tune irgendwann, ich glaube, sogar auch im Stream diskutiert, was halt generell eine gute Idee ist.
Also auch an der Stelle, wo man zum Beispiel in einem neuen Job anfängt.
Tatsächlich habe ich das in einem Job das Vergnügen gehabt, so etwas organisiert zu bekommen und das ist halt super hilfreich.
Also einfach durch die Organisation durchlaufen mit verschiedenen Leuten reden und das macht man hier als Teil des Reviews.
Und das andere, diese Kombination aus Technologie und Management ist, glaube ich, wichtig.
Und zwar deswegen, weil halt die Probleme in den, also das ist ja auch der Grund, warum ich glaube, dass wir halt irgendwie als Wacklet da gut aufgestellt sind.
Ich kann halt in der Architektur nur die technischen Herausforderungen, die mir halt geschildert werden, lösen.
Wenn ich die falschen technischen Herausforderungen habe, ist es halt nett, dass ich sie löse, aber es bringt halt nichts.
Weil eben es die falschen sind.
Und deswegen brauche ich eigentlich beide Perspektiven.
Ich brauche halt eigentlich eine Geschichte, wo ich halt sage, okay, was ist eine Management-Perspektive, wo wovon wir aus dem Business hin, wie sollen die Produkte aussehen, welche Produkte wollen wir eben launchen und dann brauche ich halt eine Idee, wie ich es halt immer entschließende Umsetze.
Und das ist, glaube ich, auch nicht unbedingt eine Einbahnstraße.
Also es gibt ja auch technisch jetzt Möglichkeiten, also oft Möglichkeiten, die man dann sozusagen zurückgeben kann und sagen kann, lass uns doch darüber mal reden oder dieses halt tun.
Und deswegen ist halt diese Kombination halt sehr wichtig.
Was halt wiederum bedeutet, eine Architekturreview, was halt nur sagt, so sieht die Architektur aus.
Und die hat halt anfangen in schnellen Herausforderungen, ist zu kurz, also viel zu kurz gesprungen.
Weil nicht auf eine perfekte Architektur in dem falschen Business-Kontext bringt halt nichts.
Und deswegen ist, glaube ich, diese Kombination ganz wichtig.
Genau, ich mach mal weiter, oder?
Sehr gerne.
Genau.
Genau, das fußt natürlich auf der Erkenntnis, haben wir, glaube ich, auch jetzt mehrfach schon gesagt, dass wir daran glauben, dass eben halt diejenigen, die an dem System arbeiten, die mit dem System arbeiten, die das Management drum herum machen, dass die Probleme im Prinzip kennen und dass die Hinweise eben halt dann auch kommen, weil man im Vertrauensvoll der Umgebung zusammenarbeitet.
Und das macht das Ganze effizient und effektiv und natürlich auch für die Beteiligten angenehm, weil relativ schnell eine gute Diskussion aufkommt, weil relativ schnell Parteien miteinander reden, die vielleicht nicht genügend miteinander geredet haben und so weiter und so weiter.
Das sind alles Themen, die das Ganze einfach angenehm und effizient machen.
Und das merkt man eben halt auch bei den Menschen beim Kunden.
Ja.
Und da hat übrigens bei mir auch so ein Wandel stattgefunden.
Also es ist halt häufig genug so, dass man sich halt ein System irgendwie anguckt und halt irgendwie feststellt und irgendwie das Gefühl hat, dass es halt sehr suboptimal, das sind halt irgendwie katastrophale Entscheidungen getroffen worden.
Und ich glaube, also wie soll ich sagen, wenn man das halt schnell feststellt, bedeutet das, dass das eigentlich nicht intellektuell offensichtlich keine Herausforderung ist.
Also will heißen, wenn man schnell zu dem Ergebnis kommt, dass es suboptimale Entscheidungen gibt, dann ist das ja mehr oder minder offensichtlich.
Dann kann man es entweder bedeuten, dass halt da sozusagen ein Wissensdefizit ist, also dass den Leuten nicht klar ist, dass das eine suboptimale Entscheidung ist, das ist super, dann kann man halt Feedback geben.
Oder sie wissen es, dann ist aber die Erkenntnis, dass es halt keine gute Entscheidung ist, gar nicht so sehr das Thema, sondern dann ist irgendwie die Frage, wie sind die dazu gekommen?
Und da gibt es halt wahrscheinlich soziale Aspekte und die muss man halt irgendwie aufdröseln.
Du hattest das halt, ja vorhin gesagt, diese grundlegende Architekturentscheidung, nicht das führt dann, die dann irgendwie auch die verschiedenen Teams unterschiedlich wahrgenommen haben, wie die überhaupt gefällt worden ist.
Sie konnten aber auch keine Alternativen nennen.
Dann bedeutet es halt, dass die Entscheidung halt so ist, wie sie ist und man halt mit der lieben muss, das müssen die aber irgendwie akzeptieren und da sind irgendwie ganz, also da ist man weit weg davon, überhaupt darüber zu reden, ob diese Entscheidung oder ob diese Entscheidung damals gut oder schlecht war.
Sondern man ist ja an der Stelle, wo man irgendwie die Frage ist, ja, was machen wir jetzt?
Und an der Stelle, wo man irgendwie diese sozialen Probleme kitten muss, weil sonst ist die nächste Entscheidung genauso schlecht.
Und das ist eigentlich der Punkt.
Und dann ist man nicht mehr bei diesem konkreten Architekturthema, sondern eben auf dieser anderen Ebene.
Absolut.
Und häufig sind es ja auch so einfache Entscheidungen oder Rahmenbedingungen, die einfach nicht stimmen, wie zum Beispiel eine Deadline, ja, die dazu führt, dass ein Projekt in die Katastrophe läuft.
Und das kriegt man halt nur durch die unterschiedlichen Perspektiven raus im Prinzip, woran liegt das jetzt eigentlich, dass diese Deadline halt da ist und dann eben halt vielleicht diese ausgleichende Wirkung zu haben, dass das Top-Management versteht, dass das Probleme, sehr große Probleme verursacht und wahrscheinlich, dass diese Deadline auch gar nichts nützt, weil sie es nicht erreichbar auch unter den Bedingungen, die man jetzt hat.
Also ich glaube, gerade so dieser, diese verschiedenen Perspektiven zu haben und daraus dann die richtigen Schlüsse zu ziehen, das ist einfach ein großes Thema dabei.
Soll ich die nächste Folie oder ich war mir nicht sicher, ob du noch was sagen wolltest zu diesem mit der Problemwahrnehmung?
Nein, das war das war alles.
Genau, ich glaube, du hattest es schon kurz angesprochen vorhin, Eberhard, Reviews münden ja oft darin, dass man das Problem dann genau kennt, sozusagen.
Wir versuchen ja eben halt die Lösungen auch aufzuzeigen.
Und da sind wir auch sehr ehrlich und sagen, was wir in der Situation tun würden.
Das heißt, wir sind da auch nicht beeinflussbar oder so, sondern wir versuchen halt alle Perspektiven so gut wie möglich auszuwerten und dann wirklich unsere Meinung uns zu bilden und die dann auch zu vertreten in der Diskussion.
Das heißt, sie kriegen eine ehrliche Meinung von uns auf der Basis dessen, was wir, was wir gehört haben, was wir selber wissen.
Und das führt halt in der Erfahrung der letzten Jahre wirklich dazu, dass die Organisationen sich verändern.
Das heißt, dass es wichtige Entscheidungen vielleicht anders getroffen werden, dass auch wie in Zukunft Entscheidungen entstehen beeinflusst wird, was ja beinahe noch wichtiger ist, ja.
Zum Beispiel in dem einen Fall, dass das Team eben wieder eine klare Stimme in diesem Konzernumfeld hat.
Und das ist aus unserer Sicht halt ein wesentlich wertvolleres Ergebnis und offensichtlich auch aus Kundensicht, als dass man eben halt nur das funktionale Problem sozusagen auflöst.
Und das ist halt nach unserer Erfahrung bei anderen Reviews, ist dieser Anspruch eigentlich gar nicht da, sondern der Anspruch ist umgrund die Problemerkennung und sicherlich auch noch technologisch zu gucken, was könnte man da jetzt eigentlich tun.
Da geht unser Review halt ein ganzes Stück weiter und macht die Ergebnisse aus unserer Sicht auch für den Kunden wesentlich wertvoller.
Und es führt natürlich auch dazu, dass beim Kunden und auch mit uns eine sehr vertrauensvolle Zusammenarbeit entsteht und dass wir dann auch natürlich weiterhelfen können.
Also dass wir den Kunden nicht alleine lassen, sondern dass wenn da Bedarf entsteht, dass wir eben halt aus dieser Kenntnis aus dem Review heraus auch tiefer reingehen können und mit Coaching, mit der Übernahme von tatsächlichen Rollen in Projekten, mit Managementberatung oder Architekturberatung eben wirklich auch weiterhelfen können und das Problem, wenn es dann größer ist, was es ja meistens ist, eben halt dann auch miteinander lösen können.
Und das ist auch etwas, was mir persönlich sehr liegt, nicht irgendwie shoot and forget oder so, sondern dass man eben halt sagt, wir stehen dann auch zur Seite und das wird auch gerne angenommen dann von allen Seiten.
Und wir halt sind nicht die Intruder, sondern es wird gerne angenommen und wir helfen tatsächlich weiter.
Oder?
Wie macht du es?
Ja.
Ja, ich finde halt diesen ersten Punkt mit die Reviews, sollten halt tatsächlich nächste Schritte zeigen.
Ich finde denen halt wahnsinnig wichtig.
Das sind nach meinem Empfinden halt auch Schritte, die man halt priorisieren muss, wo man halt sagen muss, es gibt Sachen, die halt wichtig sind und Sachen, die ja dringend sind.
Und das sind ja zwei Skalen sozusagen.
Also, was sind Sachen, die ich jetzt zeitlich sehr schnell machen muss, was sind Sachen, die sehr wichtig sind.
Das können es ja vielleicht Sachen, die ich halt irgendwie langfristig machen will.
Und dabei ist es gar nicht so, also der Anspruch ist dabei halt zu sagen, wenn wir in eurer Rolle wären, das wären die Sachen, die wir halt tun würden.
Und für mich hat das was, wie soll ich sagen, das ist eigentlich ein Anspruch, den ich an uns oder an mich selbst halt auch habe.
Ich finde es schwierig, wenn ich jemanden sage, hör mal zu, du hast da ein Problem, das ist übrigens eins.
Viel Spaß.
Ich fühle mich halt eigentlich dazu verpflichtet zu sagen, du hast halt einen Problem.
Und wenn ich dieses Problem so hätte, würde ich halt folgendes tun.
Und das, also das Ergebnis kann ja dann immer noch sein, dass halt die andere Person sagt, nee, will ich halt irgendwie nicht machen.
Fein, nicht, und dafür gibt es halt vielleicht auch gute Gründe.
Aber ich glaube, man muss halt tatsächlich in dieser Situation so weit gehen.
Die andere Sache, um das sozusagen ein bisschen, also wie soll ich sagen, das hat ja potenziell vielleicht den Anschein von Aktionismus oder von so einer Absolutheit, dass man halt irgendwie sagt, hey, wir glauben halt, nachdem wir uns jetzt irgendwie das Review angezeigt haben, also nachdem wir das Review gemacht haben, dass wir jetzt irgendwie alles wissen.
Und deswegen kommen wir zu folgendem Ergebnis.
Eine Aktion kann halt auch sein, dass man halt sagt, naja, hier ist halt ein Thema, da sollte man irgendwie nochmal drauf gucken, weil das wirkt komisch.
Wir haben es jetzt irgendwie noch nicht ganz durchdrungen, aber da sollte man halt irgendwie drauf gucken.
Und das sollte man halt schnell machen oder eben nicht so schnell, weil das ist etwas, was halt potenziell gigantische Auswirkungen hat oder irgendwie kleiner.
Also sprich, eine mögliche Aktion ist halt tatsächlich zusätzliche Informationen zu sammeln.
Und dadurch ist das halt nicht unbedingt ein Aktionismus-Sache oder eine Sache, die halt den Anspruch hat, die absolute Wahrheit zu haben, sondern nicht, also ist halt sozusagen so ein etwas, wo es um eine Gefährdung sozusagen geht.
Genau, und das anderes zu glaube ich, das andere ist eben dieser Punkt, dadurch, dass man wir eben mit allen gesprochen haben, dass wir alle gehört worden sind und ihre Meinung halt zu messen gegeben haben, dadurch ergibt sich halt dieses vertrauensvolle Verhältnis, was eben dazu führt, dass man dann eben auch gleich sozusagen in die Lösung reingehen kann.
Genau.
Und wie du halt richtig sagt, dass bei komplexen Problemen hat man natürlich nicht das gesamte Problem dann in der Kürze verstanden, sondern man hat das erste Inkrement und kann dann auch die nächsten Inkremente sozusagen bestimmen.
Also wenn man die ersten Ergebnisse dann hat, dann werden sie auch die Erkenntnisgewinne größer sein und man kann dann auch in die nächste Runde an der Stelle gehen.
Ja, genau, und das ist etwas, was er aus irgendwelchen Gründen in den Folien fehlt, aber er hat tatsächlich auch eigentlich ein Teil ist von dem, was wir halt irgendwie tun.
Das wäre eben, wie wir sagen nicht, wir machen halt ein Review, wir machen dann erst einen Aufschlag und zeigen halt die Ergebnisse, wie du ja auch gesagt hast, dann halt im großen Kreis, also mit allen Leuten, idealerweise mit allen Leuten, mit denen wir halt immer auch geredet haben.
Und sammeln dann eben Feedback ein, was eben dazu führen kann, dass es dann eine zweite Iteration gibt, respektive, dass man dann vielleicht so direkt an dem Problem arbeitet.
Und das, also für mich ist das halt ein Thema, also nicht Iteration, iterative Softwareentwicklung ist Grundlage davon, wie wir halt vernünftig Software entwickeln.
Ich habe im Stream ja auch ganz viel darüber diskutiert, dass das etwas ist, was eigentlich allgemein ingenieursmäßigen Vorgehen entspricht.
Wir bauen halt Prototypen, da machen wir halt das richtige Ding.
Das heißt, Iterationen sind halt fundamental und das machen wir hier halt genauso.
Und das, also wie soll ich sagen, ich wüsste gar nicht, wie man es sonst machen wollen würde.
Also, wenn ich mich irgendwie hinstelle und sage, okay, ich habe halt mit den Leuten geredet, ich habe halt vorhin Erkenntnisse, das sind meine Ergebnisse.
Dann kann es halt sehr gut sein, dass halt ich irgendwas übersehen habe oder man irgendwo nochmal reingucken muss.
Ja, komplett anmaßen zu sagen, jetzt hat man das Ergebnis.
Also ganz klar.
So, und das führt eben dazu, dass diese Sachen halt in der Realität dann eben mehr in Iterationen laufen oder eben dann rübergehen in okay, cool, ihr habt also gesagt, da sind irgendwie Herausforderungen.
Ihr habt gesagt, ihr würdet das halt gerne tun, der macht halt oder unterstützt uns dabei.
Und das ist, glaube ich, so dieser Bestandteil, der irgendwie dazugehört.
Und dazu führt, dass die eben so produktiv und hilfreich sind.
Also nicht, deswegen machen wir ja auch iterative Software-Entwicklungen, weil wir eben vielleicht mit der ersten Iteration schon ein paar Bonnet mehr erschlagen, weil wir durch das Feedback dann ein bisschen weiter vorgehen können.
Das machen wir halt mit den Reviews ganz genau so.
Ich glaube, fest daran, dass auch bei organisatorischen Veränderungen Iterationen die bessere Lösung ist.
Keine großen Reorganisationen, die erstmal alles umkrempeln, sondern eben halt da anfangen, wo wirklich ein Problem ist und aufzeigen, dass das Problem damit gelöst werden kann und dann weitermachen.
Das sind ja auch Themen, die für uns auch wichtig sind, glaube ich, insgesamt.
Weil die Maßnahmen sind halt auch auszuprobieren in einem Unternehmen und zu testen, wie sie dann funktionieren und ob sie tatsächlich funktionieren.
Ja, und das schiebt ja auch dem einen Riegel vor, dass man irgendwie sagt, wir wenden jetzt irgendwas an.
Und dann stellt man halt fest, dass es am Ende halt irgendwie genauso wie vorher nicht.
Und deswegen bin ich auch dankbar, dass halt solche solche Ansätze wie Team Topologies eben sagen, dass es halt Magneten sind, wo man sich hin entwickeln will.
Vielleicht an der Stelle noch ein Hinweis, die jetzt habe ich dem Pfand verloren.
Also, dass diese Iterationen sind halt.
Achso, das war der Punkt.
Ich glaube, oder meine Erfahrung ist, dass man in der absoluten Mehrheit der Fälle, zumindest wenn man halt Leute fragt, wie sie halt Systeme migrieren und modernisieren wollen, dass sie dann irgendwie sagen, das mit dem Big Bang wollen wir nicht.
Also tatsächlich mache ich das halt in Trainings relativ gewöhnlich üblich, dass das hier irgendwie das Frage.
Auf der anderen Seite ist eben das Problem, dass wenn man halt sagt, man will irgendwie schrittweise vorgehen, ist irgendwie die Frage, was ist der erste Schritt und wie generiere ich halt irgendwie ein Wert.
Und das ist eigentlich so ein bisschen die Herausforderung.
Das kriegt man aber, also bei Reviews ist das jetzt nicht so, glaube ich, nicht so ein Drama, weil man meistens halt in so einem Kickoff und am Anfang des Settings halt irgendwie mitbekommt, wo eigentlich, also nicht, da gibt es halt meistens eine konkrete Fragestellung, die halt diskutiert werden soll.
Dann kann man sich der halt irgendwie nähern in Softwareentwicklung an sich ist das sonst bei den Iterationen, glaube ich, eine Herausforderung.
Genau, dann haben wir die Folie noch mit dem Hinweis einmal auf unsere Webseite, wo man eben, die Links gibt es dann auch in den Shownotes, wo wir halt auch mal was aufgeschrieben haben zum Thema Star Reviews und zum anderen gibt es halt die Möglichkeit, mit mir oder Hans-Jörg oder auch Jonas, der halt Leute heute leider verhindert ist, so ein virtuell Kaffee zu machen, wo man nochmal speziell Themen diskutieren kann in dem jeweiligen Setting und da halt sozusagen auch individuell drüber reden kann und zu einer Lösung kommen kann.
Genau, ich weiß gar nicht, wir haben jetzt keine Fragen.
Das heißt, das wäre jetzt noch die Chance, Fragen zu stellen.
Haben wir aus deiner Sicht, Hans-Jörg, sonst noch was vergessen oder etwas, was wir noch erzählen sollten?
Ich habe auch gerade darüber nachgedacht, aber ich denke nicht.
Zumindest konnten wir im Moment kein weiterer Gedanke.
Genau.
Hinweis sonst noch für die nächste Woche.
Nächste Woche bin ich leider am Freitag verhindert und es hat sich auch sonst sozusagen niemand gefunden.
Es wird aber nächste Woche BPSode geben, wo ich einen Talk wieder verwende, wo mit der Aufzeichnung von einem Talk über Team Topologis Architektur Inverse Conway, den wir als Vorbereitung, den die Airchamets Architecture aufgenommen hat in einem Stream und den wird es dann hier geben als Podcast und eben als normales Video.
Genau, Fragen habe ich tatsächlich sonst jetzt hier nicht noch gesehen.
Wenn wir sonst sozusagen keine weiteren Themen haben.
Ich glaube, wir haben es auch im Wesentlichen alles so weit diskutiert.
Dann würde ich sagen, Hans-Jörg, vielen Dank, dass du da warst.
Tja, vielen Dank nochmal, dass ich da sein konnte.
Und ja, vielen Dank für die Aufmerksamkeit.
Und dann hören wir uns sozusagen nächste Woche wieder.
Bis dahin.
Alles klar, herzlichen Dank.