Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren

Folge 301 - Soziotechnische Architektur Reviews mit Hansjörg Gude

So, dann herzlich willkommen zu einer weiteren Episode von Software-Architektur im Stream.

Diesmal mit Hansjörg Gude.

Jonas konnte es leider heute nicht schaffen, weil er erkrankt ist.

Genau, Hansjörg, willst du erstmal ein paar Worte über dich sagen?

Sehr gerne.

Erstmal herzlichen Dank für die Einladung hier.

Ich freue mich natürlich sehr, heute dabei zu sein und bin auch gespannt auf Fragen, Anmerkungen, Meinungen natürlich.

Vielleicht kurz zu mir, Hansjörg Gude.

Ich bin Mitgründer, Geschäftsführer und Berater bei Swaglab.

Mein Hintergrund ist, ich bin Wirtschaftsingenieur, habe als Entwickler tatsächlich gestartet bei Gruner & Jahr hier in Hamburg, war zehn Jahre dort, am Ende im IT-Management.

Habe dann eine Firma gegründet für Software, Verlagssoftware, also ERP, CRM, E-Commerce, so diese ganze Schiene, modular aufgebaut.

Das Ganze war ziemlich erfolgreich.

Wir haben das dann nach zehn Jahren an Gruner & Jahr verkauft und bin dann eine ganze Zeit als freier Berater unterwegs gewesen.

Dort am Ende dann beim großen Hamburger Optiker gelandet, bei dem wir uns auch kennengelernt haben, das heißt die Leute, die dann Swaglab gegründet haben und das Kernteam heute bilden.

Das kennzeichnet uns auch ein Stück weit.

Wir haben dort 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 Architekturbereich und haben dabei eigentlich gelernt, dass Probleme eben nie nur in der Technik liegen, sondern beinahe öfter, sage ich mal, in der Organisation, im menschlichen Bereich.

Da haben wir für uns Arbeitsmethoden entwickelt, die gut funktioniert haben.

Die Idee bei der Swaglab-Gründung war eigentlich, genau das mitzunehmen und für uns zu leben natürlich und auch beim Kunden zu leben und das dort einzuführen.

Und 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.

Und ich 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 der Swaglab, haben eben diese Geschichte, dass eben der menschliche Mittelpunkt steht.

Und wir wollen jetzt eigentlich gar nicht so viel anfangen mit irgendwelchen theoretischen Zeug, sondern eigentlich darüber sprechen, welche Erfolge oder welche Ansätze wir da halt sozusagen in der Praxis erlebt haben.

Und ich habe die Ehre, da sozusagen loszulegen.

Und hier ist halt zum Beispiel, also da ist die Frage, okay, soll ich eine gemeinsame Plattform bauen?

Und da gibt es halt irgendwelche Funktionalitäten.

Und dann habe ich eben am Ende irgendwie eine Plattform mit gemeinsamen fachlichen Code.

Und ich habe jetzt drei Kästen gemalt mit Funktionalitäten.

Dahinter verbirgt sich nicht nur Code, sondern eben auch drei Teams.

Und dann war die Idee, eine Plattform zu 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 nämlich 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 habe.

Und was sich dann halt ergab ist, also es gibt irgendwie fachliche Gemeinsamkeiten, was so medium überraschend ist.

Sonst würde man ja nicht auf die Idee kommen, so eine Plattform zu 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.

Und da kann man jetzt irgendwie darüber diskutieren.

Man baut sich halt Abhängigkeiten ein.

Es ist schwer herauszufinden, ob Sachen tatsächlich generisch seien und so weiter und so weiter.

Und als wir das Review gemacht haben, haben wir halt eigentlich festgestellt, dass das so eine sehr toxische Umgebung war, wo Probleme halt nicht kommuniziert werden und wo Menschen, die halt Probleme zugeben, dann bestraft werden.

Also in dem Sinne, dass ihnen nicht geholfen wird, sondern dass sie dann eben möglich, also dass man sich halt jemand anders sucht, der es halt vielleicht besser kann und dadurch man vielleicht irgendwie Karriereprobleme hat oder nicht.

Was auch immer da halt irgendwie passiert.

Man kennt das ja von so dysfunktionalen Organisationen.

Und das Ergebnis ist halt Misstrauen.

Was eben damit zusammenhängt, auch wenn ich halt in so einer Organisation arbeiten würde, die halt irgendwie so aussieht, würde ich eben anfangen, Probleme nicht zu kommunizieren.

Was halt bedeutet, dass ich eben anderen Leuten nicht erzähle, was gerade Phase ist.

Was halt bedeutet, dass sich andere Leute nicht darauf verlassen können, dass das, was ich sage oder zusage, eben tatsächlich auch passiert und funktioniert.

So und dann werden andere Leute mir misstrauen und ich halte das halt für perfekt nachvollziehbar, dass das halt so ist, weil das sind halt die Gegebenheiten, unter denen dort irgendwie dann gearbeitet werden muss.

Und für den Fall, den wir jetzt haben, bedeutet das, dass wir halt an der Stelle, wo dieses Plattformteam halt irgendwie aufgebaut wird, dieses Plattformteam 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 zu nutzen, unter der Voraussetzung, dass das eben irgendwie fachlich inhaltlich sinnvoll ist, denen halt nicht trauen werden, weil die eben Probleme nicht kommunizieren werden, so wie alle anderen irgendwie auch.

Und das 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 Problemen existiert.

Und dann habe ich selber ein Problem, weil ich irgendwie ja auch bestraft werde, wenn ich meine Ziele nicht erreiche.

Und das, 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 Plattformen bzw. dieses Plattformteam wird halt irgendwie nicht funktionieren.

Und das führt dann dazu, dass man halt also sicher einen 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, 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 Architektur-Review machen würde.

Also wenn man jetzt irgendwie sagen würde, okay, wir gucken uns das halt an, wir gucken uns an, was ist 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 Totgeburt 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 halt 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, ich glaube, das ist das, wo du, Hans-Jörg, dann sozusagen übernehmen willst.

Ja, sehr gerne.

Genau, das zweite Beispiel ist ein Merger von zwei großen Unternehmen.

Und folgerichtig wurde dann halt ein Projekt ins Leben gerufen, 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 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, 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 dazugesellt haben.

Und die haben sich, haben wir hinterher erfahren, eigentlich dazugesellt, 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 da sind wir, glaube ich, noch gar nicht so genau darauf eingegangen.

Ja, gemäß des Anspruchs eben technologisch irgendwie exzellent beim Kunden aufzutreten und Management-Kompetenz 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, dass eben halt die Probleme auch auf sozialer Ebene liegen, sind wir dann sozusagen vom Fleck weg tatsächlich engagiert worden, was gar nicht so geplant war und sind dann auch direkt reingegangen.

Das heißt, wir haben sehr schnell eine Akzeptanz erzeugt.

Das mit zwei Personen ist natürlich dafür auch günstig, weil man eben halt in dem Spannungsumfeld menschliche soziale Führungsthemen und Technologie eben halt auch da einfach ein Stück weit besser agieren kann, wo man sich sehr gut ergänzt in so einer Situation.

Diese Gespräche sorgen natürlich dafür, dass erst mal Vertrauen entsteht, weil die Menschen fühlen sich gehört, sind auch wirklich gehört.

Also wir haben ja wirklich 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, 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 sich vielleicht Systeme angucken, den Code analysieren und so weiter und so weiter und würde dann eventuell auf 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 noch 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 auf dem Weg vielleicht gemacht hat, vielleicht falsche Wahrnehmung oder, 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, lieber Heid.

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 Wahrnehmungen 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 den Hintergrundbildschirm immer schwarz hatten von dem Zeitpunkt an, weil die Lage Fenster war.

Solche Dinge sind da eben halt aufgekommen und man konnte das schon deutlich spüren, dass da eben halt Dinge schief hängen, gerade in dem Umfeld, das eben nicht rein technische Natur ist.

Einmal weiter.

Genau, das heißt also, das haben wir natürlich in den Interviews rausbekommen und gleichzeitig war es aber so, und das macht eigentlich dieses Review besonders interessant als Beispiel, dass auch keine echte Alternative angeboten werden konnte und das lag an der Deadline, die vom Top-Management vorgegeben war.

Sicherlich eine sinnvolle Deadline aus Business-Sicht, aber sie hat halt dazu geführt, dass keine wirklich konsensfähige Entscheidung getroffen werden konnte und es war auf der Basis auch keine konstruktive Kritik möglich.

Das heißt, es musste eigentlich clashen.

Ich kann mal 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 Zentralarchitektur, 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 gegenseitige Vertrauen war einfach wieder da.

Es hat auf der anderen Seite aber auch dazu geführt, dass sich weitere Begleitung in diesem Projekt ergeben hat.

Das heißt, es sind keine einfachen Probleme gewesen, die da noch übrig blieben hinterher, sondern es waren sehr komplexe, schwierige Probleme.

Man hat sich dann darauf verständigt, dass 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.

Die Leute wollten dann auch mit den Personen arbeiten und es ist weiterhin ein Projekt, das wir begleiten.

Was halt in gewisser Weise, und ich glaube, das ist so eine von den Sachen, die uns hier nochmal beschäftigen wird, eben bedeutet, dass es eigentlich mehr als ein Review ist.

Also nicht bei einem Review würde man vielleicht erwarten, dass das Ergebnis so ein Foliensatz ist.

Und hier liegt das Review, wie du ja gesagt hast, durch diese vertrauensvolle Zusammenarbeit, dass man vertrauliche Interviews führt.

Das legt den Grundstein für das, was hier auf der Folie steht, dass man eben gemeinsam vertrauensvoll und 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 steht, als wenn man sagt, an dieser Architekturebene kann man Folgendes optimieren, weil das führt dann vielleicht zu einem Foliensatz, der inhaltlich spannend ist, aber der im Extremfall nichts ändert und liegen bleibt.

Und da ist, glaube ich, der deutlich größere Wert.

Und das hängt eben damit zusammen, wie man es macht mit den Interviews und der entsprechenden vertrauensvollen Basis an der Nachstelle.

Ja, absolut.

Ich sage 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 Personen wirklich aufnimmt und das wirklich ernst nimmt, dass auch die entscheidenden Dinge sind, die man tut, 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 mit dem Kunden an der Stelle zusammenarbeitet.

Und wir haben das an irgendeiner Stelle, ich glaube, sogar zusammen diskutiert diese Woche.

Nicht ein Review, was sozusagen aus einer kontrollierenden Perspektive kommt und sagt, ich weiß es halt besser und ich zeige euch mal den richtigen Weg, ist halt wenig hilfreich.

Also einmal ist es halt kein Setup, in dem man gerne arbeitet.

Und zweitens ist es halt auch deswegen daneben, weil wenn man halt von extern kommt, kann man nicht die Person sein, die das System halt perfekt kennt.

Das sind die Personen, die einem gegenüberstehen oder sitzen, die halt irgendwie mit dem System schon lange arbeiten.

Und da muss man die halt irgendwie auch als Expertin für das System auffassen an der Stelle.

Absolut.

Die eigentliche Leistung des Wettbewerbs 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?

Welche Lösungsansätze sind eigentlich schon vorhanden?

Und da eher 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 dann hat und vielleicht diskutiert.

Aber wenn man mal ganz ehrlich ist, die meisten Themen sind eigentlich schon vorhanden in den Köpfen der Menschen.

Das ist eindeutig so.

Ich würde es in Nuance anders sehen.

Also ich glaube, du brauchst eine fachlich inhaltliche Qualifikation und solltest halt eigene Ideen einbringen, deswegen ist es ja ein Review.

Aber die Information erstmal aufzunehmen und zu verstehen, was da ist und was tatsächlich das Problem ist, das ist, glaube ich, erst mal die Herausforderung und das Thema.

Und die Menschen als Expertinnen für das System zu verstehen.

Wenn man dann irgendwie sagt, okay, ihr habt also folgende Lösungsansätze gehabt, ihr habt folgende Ideen gehabt, was wäre noch mit diesen folgenden anderen Ideen?

Oder das ist irgendwie komisch.

In meiner Erfahrung funktioniert das nicht.

Ein inhaltliches Feedback ist sinnvoll und sehr hilfreich.

Aber umgekehrt ist es der wichtige Punkt, sich sozusagen leiten zu lassen, so wie du es ja auch vorher gesagt hattest, durch die Menschen, die in einem Projekt sind, um zu identifizieren, was erstmal die Hauptherausforderungen sind und nicht irgendwie hinzugehen und zu sagen, naja, ich habe eine Idee, wie man sowas typischerweise löst und ich setze das als Benchmark, sondern eben zusätzliche Sachen reinzubringen.

Das ist schon hilfreich, aber eben da nicht zu sehr mit dem eigenen Bias reinzugehen.

Nein, genau.

Das sehe ich ja genauso.

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 die Erfahrung bei mir jedenfalls.

Das muss reifen, bis 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, ich bin nicht die Person, die alles weiß und weiß, wie es gelöst wird, sondern immer erstmal zu schauen, okay, die haben halt auch irgendwas versucht, 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, vielleicht noch ein drittes Beispiel.

Das ist dann auch das letzte.

Das kommt aus einem Unternehmen, auch ein großes Unternehmen mit mehr als 500 Millionen Umsatz.

Deren Situation, Ausgangssituation, mit der sie bei uns sozusagen aufgeschlagen sind, war eigentlich, dass ein ERP-System ein Update bekommen musste.

Update ist eigentlich fast zu wenig gesagt, praktisch ein kompletter technologischer Sprung zwischen diesen beiden Releases.

Das letzte Release, was sie eingesetzt haben, war auch schon einige Jahre alt, viele Jahre alt, konnte nicht mehr abgedatet werden, weil eben halt sehr viele Individualisierungen stattgefunden haben.

Und es war eigentlich ein kompletter Systemwechsel, kann man sagen.

Und das war das Problem.

Das haben sie seit mehreren Jahren versucht, mit verschiedenen Ansätzen, und es ist halt nichts Produktives dabei herausgekommen.

Hier haben wir halt schnell bemerkt, dass das ERP den strategischen Anforderungen nicht gerecht werden kann, im Moment in dem Zustand, und dass 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.

Das Thema wollen wir gar nicht so großartig hier inhaltlich weiter beschreiben.

Es ist auf jeden Fall so gewesen, dass einer der Marktführer in der Beratungswelt ein Review mit größerer Mannschaft 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 rauszukommen?

Und wir haben das Ganze mit zwei Personen in wenigen Wochen durchgeführt.

Und das Ergebnis ist, dass eben ein kompletter Ruck durch die ganze Organisation geht.

Das alte Vorgehen ist sozusagen gestopft worden.

Das ganze Projekt ist gestopft worden, wird jetzt neu initiiert unter ganz anderen Voraussetzungen, mit ganz anderem Vorgehen, unter Einbeziehung der Business-Ziele und der Projekte, die ansonsten noch wichtig sind.

Das heißt also, ein iteratives Vorgehen, dann dieses ERP-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 zu haben, das dann auch eine kursansfähige Entscheidung hervorbringt.

Was vielleicht dazu führt, dass man Reviews sozusagen an was anderem messen sollte.

Also nicht an dem Erkenntnisgewinn, 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 Information drin, was halt irgendwie total spannend ist.

Aber es hat eben nichts geändert.

Und das wird irgendwie anders, wenn man es eben so, wie ihr es hier gemacht habt, da proaktiv macht und eben gleich auch sozusagen ins Doing halt rübergeht und eben auch diese vertrauensvolle Basis schafft und auf der hat sozusagen exekutiert.

Und das ist, glaube ich, da der wesentliche Vorteil.

Genau.

Ich mache mal weiter, oder?

Sehr gerne.

Genau.

Also zu der Frage, was sind die denn eigentlich, diese Star-Reviews?

Und da steht, genau, das war, das 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 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 dieser 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.

Vielleicht kurz dazu zwei kleine Ergänzungen.

Die eine Sache ist diese Idee, dass man halt im Unternehmen rumläuft und mit Menschen redet.

Die hatte der Nick Thune irgendwann, ich glaube, sogar auch im Stream diskutiert, was generell eine gute Idee ist.

Also auch an der Stelle, wo man zum Beispiel in einem neuen Job anfängt.

Tatsächlich habe ich in einem Job das Vergnügen gehabt, sowas organisiert zu bekommen und das war 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.

Das ist der Grund, warum ich glaube, dass wir als Racktap da gut aufgestellt sind.

Ich kann in der Architektur nur die technischen Herausforderungen, die mir geschildert werden, lösen.

Wenn ich die falschen technischen Herausforderungen habe, ist es nett, dass ich sie löse.

Aber es bringt halt nichts, weil es die falschen sind.

Und deswegen brauche ich eigentlich beide Perspektiven.

Ich brauche eigentlich eine Geschichte, wo ich sage, was ist eine Management-Perspektive, wovon wir aus dem Business reden, wie sollen die Produkte aussehen, welche Produkte wollen wir launchen und dann brauche ich eine Idee, wie ich es entschließend umsetze.

Und das ist, glaube ich, auch nicht unbedingt eine Einbahnstraße.

Es gibt ja auch technisch Möglichkeiten, die man zurückgeben kann und sagen kann, lass uns doch darüber mal reden oder dieses tun.

Und deswegen ist diese Kombination sehr wichtig.

Was wiederum bedeutet eine Architektur-Review, was nur sagt, so sieht die Architektur aus.

Und die hat an folgenden Stellen Herausforderungen, ist viel zu kurz gesprungen, weil nicht eine perfekte Architektur in dem falschen Business-Kontext bringt halt nichts.

Und deswegen ist, glaube ich, diese Kombination ganz wichtig.

Das fußt natürlich auf der Erkenntnis, haben wir, glaube ich, auch jetzt mehrfach schon gesagt, dass wir daran glauben, dass diejenigen, die an dem System arbeiten, die mit dem System arbeiten, die das Management drumherum machen, die Probleme im Prinzip kennen und dass die Hinweise dann auch kommen, weil man in vertrauensvoller 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.

Das sind alles Themen, die das Ganze einfach angenehm und effizient machen.

Und das merkt man eben halt auch bei den Menschen, beim Kunden.

Da hat übrigens bei mir auch so ein Wandel stattgefunden.

Es ist häufig genug so, dass man sich ein System anguckt und das Gefühl hat, dass es sehr suboptimal ist.

Da sind katastrophale Entscheidungen getroffen worden.

Wenn man das schnell feststellt, bedeutet das, dass das eigentlich nicht intellektuell offensichtlich eine Herausforderung ist.

Wenn man schnell zu dem Ergebnis kommt, dass es suboptimale Entscheidungen gibt, dann ist das ja mehr oder minder offensichtlich.

Dann kann es entweder bedeuten, dass da ein Wissensdefizit ist, dass den Leuten nicht klar ist, dass das eine suboptimale Entscheidung ist.

Das ist super, dann kann man Feedback geben oder sie wissen es.

Dann ist aber die Erkenntnis, dass es keine gute Entscheidung ist, gar nicht so sehr das Thema.

Sondern dann ist die Frage, wie sind die dazu gekommen.

Da gibt es wahrscheinlich soziale Aspekte und die muss man aufdröseln.

Du hattest das vorhin gesagt, diese grundlegende Architekturentscheidung, die verschiedenen Teams unterschiedlich wahrgenommen haben, wie die gefällt worden ist.

Sie konnten aber auch keine Alternativen nennen.

Dann bedeutet es, dass die Entscheidung so ist, wie sie ist und man mit der leben muss.

Das müssen die aber akzeptieren.

Da ist man weit weg davon, darüber zu reden, ob diese Entscheidung damals gut oder schlecht war.

Sondern man ist an der Stelle, wo die Frage ist, was machen wir jetzt?

Und an der Stelle, wo man diese sozialen Probleme kitten muss, weil sonst ist die nächste Entscheidung genauso schlecht.

Das ist eigentlich der Punkt.

Dann ist man nicht mehr bei diesem konkreten Architekturthema, sondern auf dieser anderen Ebene.

Absolut.

Häufig sind es auch so einfache Entscheidungen oder Rahmenbedingungen, die einfach nicht stimmen, wie zum Beispiel eine Deadline, die dazu führt, dass ein Projekt in die Katastrophe läuft.

Das kriegt man nur durch die unterschiedlichen Perspektiven raus.

Woran liegt es eigentlich, dass diese Deadline da ist und vielleicht diese ausgleichende Wirkung zu haben, dass das Topmanagement versteht, dass das sehr große Probleme verursacht und wahrscheinlich, dass diese Deadline auch gar nichts nützt, weil sie nicht unter den Bedingungen erreichbar ist, die man jetzt hat.

Gerade diese verschiedenen Perspektiven zu haben und daraus die richtigen Schlüsse zu ziehen, das ist einfach ein großes Thema dabei.

Soll ich die nächste Folie?

Nein, das war alles.

Du hattest es schon kurz angesprochen, Eberhard.

Reviews münden oft darin, dass man das Problem genau kennt.

Wir versuchen eher, die Lösungen aufzuzeigen.

Da sind wir auch sehr ehrlich und sagen, was wir in der Situation tun würden.

Das heißt, wir sind auch nicht beeinflussbar.

Wir versuchen, alle Perspektiven so gut wie möglich auszuwerten und dann wirklich unsere Meinungen zu bilden und die dann auch zu vertreten in der Diskussion.

Das heißt, wir kriegen eine ehrliche Meinung von uns auf der Basis dessen, was wir gehört haben, was wir selber wissen.

Das führt in der Erfahrung der letzten Jahre wirklich dazu, dass die Organisationen sich verändern.

Das heißt, dass wichtige Entscheidungen vielleicht anders getroffen werden.

Auch wie in Zukunft Entscheidungen entstehen, beeinflusst das, was ja beinahe noch wichtiger ist.

Zum Beispiel in dem einen Fall, dass das Team wieder eine klare Stimme in diesem Konzernumfeld hat.

Das ist aus unserer Sicht ein wesentlich wertvolleres Ergebnis und offensichtlich auch aus Kundensicht, als dass man nur das funktionale Problem auflöst.

Nach unseren Erfahrungen bei anderen Reviews ist dieser Anspruch eigentlich gar nicht da, sondern der Anspruch ist, um die Problemerkennung und sicherlich auch noch technologisch zu gucken, was könnte man da jetzt eigentlich tun.

Da geht unser Review ein ganzes Stück weiter und macht die Ergebnisse aus unserer Sicht auch für den Kunden wesentlich wertvoller.

Das 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.

Dass wir den Kunden nicht alleine lassen, sondern dass, wenn da Bedarf entsteht, wir eben aus dieser Kenntnis, aus dem Review heraus auch tiefer reingehen können.

Mit Coaching, mit der Übernahme von tatsächlichen Rollen in Projekten, mit Managementberatung oder Architekturberatung wirklich auch weiterhelfen können und das Problem, wenn es dann größer ist, was es ja meistens ist, auch miteinander lösen können.

Das ist auch etwas, was mir persönlich sehr liegt.

Nicht shoot and forget oder so, sondern dass man sagt, wir stehen dann auch zur Seite und das wird auch gerne angenommen von allen Seiten.

Wir sind nicht die Intruder, sondern es wird gerne angenommen und wir helfen tatsächlich weiter.

Oder?

Ja, ich finde diesen ersten Punkt mit den Reviews sollten tatsächlich nächste Schritte zeigen.

Ich finde den wahnsinnig wichtig.

Das sind nach meinem Empfinden auch Schritte, die man priorisieren muss, wo man sagen muss, es gibt Sachen, die wichtig sind und Sachen, die dringend sind.

Das sind ja zwei Skalen.

Was sind Sachen, die ich zeitlich sehr schnell machen muss?

Was sind Sachen, die sehr wichtig sind?

Das sind Sachen, die ich langfristig machen will.

Der Anspruch ist, dabei zu sagen, wenn wir in eurer Rolle wären, das wären die Sachen, die wir tun würden.

Für mich ist das ein Anspruch, den ich an uns oder an mich selbst habe.

Ich finde es schwierig, wenn ich jemandem sage, hör mal zu, du hast ein Problem.

Das ist übrigens eins.

Viel Spaß.

Ich fühle mich eigentlich dazu verpflichtet, zu sagen, du hast ein Problem.

Wenn ich dieses Problem so hätte, würde ich Folgendes tun.

Das Ergebnis kann ja immer noch sein, dass die andere Person sagt, will ich nicht machen.

Dafür gibt es vielleicht auch gute Gründe.

Aber ich glaube, man muss in dieser Situation so weit gehen.

Die andere Sache hat potenziell den Anschein von Aktionismus oder von Absolutheit.

Dass man sagt, wir glauben, nachdem wir das Review gemacht haben, dass wir irgendwie alles wissen.

Deswegen kommen wir zu folgendem Ergebnis.

Eine Aktion kann auch sein, dass man sagt, das ist ein Thema, da sollte man nochmal draufgucken.

Das wirkt komisch, wir haben es noch nicht ganz durchdrungen, aber da sollte man irgendwie draufgucken.

Das sollte man schnell machen oder eben nicht so schnell, weil das ist etwas, was potenziell gigantische Auswirkungen hat oder kleine.

Eine mögliche Aktion ist tatsächlich, zusätzliche Informationen zu sammeln.

Dadurch ist das nicht unbedingt eine Aktionismus-Sache oder eine Sache, die den Anspruch hat, die absolute Wahrheit zu haben.

Es ist etwas, wo es um eine Gefährdung geht.

Das andere ist der Punkt, dass wir mit allen gesprochen haben, dass wir alle gehört worden sind und ihre Meinung zu messen gegeben haben.

Dadurch ergibt sich dieses vertrauensvolle Verhältnis, was dazu führt, dass man gleich in die Lösung reingehen kann.

Bei komplexen Problemen hat man natürlich nicht das gesamte Problem in der Kürze verstanden, sondern man hat das erste Inkrement und kann dann auch die nächsten Inkremente bestimmen.

Wenn man die ersten Ergebnisse hat, dann werden sie auch die Erkenntnisgewinne größer sein und man kann dann auch in die nächste Runde an der Stelle gehen.

Das ist etwas, was aus irgendwelchen Gründen in den Folien fehlt, aber tatsächlich auch ein Teil ist von dem, was wir tun.

Wir machen einen Review, einen ersten Aufschlag und zeigen die Ergebnisse, wie du ja auch gesagt hast, im großen Kreis, also idealerweise mit allen Leuten, mit denen wir geredet haben.

Wir sammeln dann Feedback ein, was dazu führen kann, dass es eine zweite Iteration gibt, respektive dass man dann vielleicht direkt an den Problemen arbeitet.

Für mich ist das ein Thema.

Iteration, iterative Softwareentwicklung ist Grundlage davon, wie wir vernünftig Software entwickeln.

Ich habe im Stream auch ganz viel darüber diskutiert, dass das etwas ist, was eigentlich allgemeinen ingenieursmäßigen Vorgehen entspricht.

Wir bauen halt Prototypen, dann machen wir das richtige Ding.

Das heißt, Iterationen sind fundamental und das machen wir genauso.

Ich wüsste gar nicht, wie man es sonst machen wollen würde.

Wenn ich mich irgendwie hinstelle und sage, ich habe mit den Leuten geredet, ich habe volle Erkenntnisse, das sind meine Ergebnisse, dann kann es sehr gut sein, dass ich irgendwas übersehen habe oder man irgendwo noch mal reingucken muss.

Das führt eben dazu, dass diese Sachen in der Realität dann in mehreren Iterationen laufen oder eben dann rübergehen in Okay, cool, ihr habt also gesagt, da sind Herausforderungen.

Ihr habt gesagt, ihr würdet das gerne tun, macht halt oder unterstützt uns dabei.

Das ist, glaube ich, dieser Bestandteil, der dazugehört und dazu führt, dass die eben so produktiv und hilfreich sind.

Deswegen machen wir auch iterative Softwareentwicklung, weil wir eben vielleicht mit der ersten Iteration schon ein paar Probleme erschlagen und weil wir durch das Feedback wissen, wie wir weiter vorgehen können.

Das machen wir mit den Reviews ganz genau so.

Ich glaube auch fest daran, dass auch bei organisatorischen Veränderungen Iterationen die bessere Lösung ist.

Keine großen Reorganisationen, die erstmal alles umkrempeln, sondern eben da anfangen, wo wirklich ein Problem ist und aufzeigen, dass das Problem damit gelöst werden kann und dann weitermachen.

Das sind auch Themen, die für uns auch wichtig sind, glaube ich, insgesamt.

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 sagt, wir wenden jetzt irgendwas an und dann stellt man fest, dass es am Ende genauso wie vorher nicht.

Deswegen bin ich auch dankbar, dass solche Ansätze wie Team Topologies sagen, dass das Magneten sind, wo man sich hinentwickeln will.

Vielleicht an der Stelle noch ein Hinweis.

Meine Erfahrung ist, dass man in der absoluten Mehrheit der Fälle, zumindest wenn man Leute fragt, wie sie Systeme migrieren und modernisieren wollen, dass sie dann irgendwie sagen, mit dem Big Bang wollen wir nicht.

Tatsächlich mache ich das in Trainings relativ üblich.

Auf der anderen Seite ist das Problem, dass wenn man sagt, man will schrittweise vorgehen, ist die Frage, was der erste Schritt ist und wie man einen Wert generiert.

Das ist eigentlich die Herausforderung.

Bei Reviews ist das nicht so ein Drama, weil man meistens in einem Kick-Off und am Anfang des Settings mitbekommt, wo meist eine konkrete Fragestellung diskutiert werden soll.

Dann kann man sich da irgendwie nähern.

Insofern ist das bei den Iterationen eine Herausforderung.

Dann haben wir die Folie noch mit dem Hinweis auf unsere Webseite.

Die Links gibt es dann auch in den Shownotes, wo wir auch mal etwas aufgeschrieben haben zum Thema Star Reviews.

Zum anderen gibt es die Möglichkeit, mit mir, Hansjörg oder auch Jonas, der heute leider verhindert ist, ein Café zu machen, wo man nochmal speziell Themen diskutieren kann in dem jeweiligen Setting und da auch individuell drüber reden kann und zu einer Lösung kommen kann.

Wir haben jetzt keine Fragen.

Das wäre jetzt noch die Chance, Fragen zu stellen.

Haben wir aus deiner Sicht, Hansjörg, sonst noch etwas vergessen oder etwas, was wir noch erzielen sollten?

Ich habe auch gerade darüber nachgedacht, aber ich denke nicht.

Zumindest konnten wir.

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 niemand gefunden.

Es wird aber nächste Woche so gegeben, wo ich mit Aufzeichnung von einem Talk über Team Topologies, Architektur, Inverse Conway, den wir als Vorbereitung, den die Architektur aufgenommen hat, in einem Stream und den wird es dann hier geben als Podcast und eben als normales Video.

Fragen habe ich tatsächlich sonst jetzt hier nicht noch gesehen.

Wenn wir sonst sozusagen keine weiteren Themen haben, haben wir im Wesentlichen alles soweit diskutiert.

Hansjörg, vielen Dank, dass du da warst.

Ja, vielen Dank nochmal, dass ich da sein konnte.

Vielen Dank für die Aufmerksamkeit und dann sehen wir uns nächste Woche wieder.

Bis dahin.

Alles klar.

Herzlichen Dank.