Architekturentscheidungen im Team ermöglichen

Dieses Transkript wurde automatisiert erstellt und nicht manuell überprüft. Es kann daher Fehler enthalten. Maßgeblich ist immer das im Mitschnitt gesprochene Wort.

Sven Johann: Hallo und herzlich willkommen zu einer neuen Episode vom INNOQ Podcast. Heute eine lang ersehnte Folge mit Holger Kraus. Hi Holger, wie geht’s?

Holger Kraus: Hallo Sven, mir geht’s sehr gut. Ich freue mich auf diesen Podcast.

Sven Johann: Was machst du eigentlich so bei INNOQ? Vielleicht mal so als Selbstvorstellung.

Holger Kraus: Was mache ich bei INNOQ? Ich mache schon sehr lange Dinge bei INNOQ. Ich bin seit 2010 bei INNOQ, also jetzt schon 16 Jahre, und war in verschiedenen Rollen in Projekten, am Anfang ganz viel als Entwickler. Dann habe ich in verschiedenen Projekten Architektenrollen übernommen und jetzt in den letzten zwei Jahren habe ich das INNOQ Lab geleitet. Das ist unsere interne Organisationseinheit, die unsere internen Projekte durchgeführt hat.

Sven Johann: Genau. Wir waren ja auch mal in einem Projekt, zumindest bei einem Kunden zusammen. Da warst du Architekt in einem ziemlich beeindruckenden Projekt in China. Vielleicht kommen wir darauf auch noch mal zurück. Ich war tief beeindruckt. Worüber reden wir denn heute? Du hast einen Artikel geschrieben, den hängen wir auch in die Shownotes, und der heißt: „Jeder kann Architekt sein.“ Im Prinzip geht es darum, wie man eine Rampe für Leute bildet, die Interesse an Architektur haben. Darüber würde ich sprechen. Der Artikel hat ziemlich viel Ähnlichkeit mit dem Buch von Andrew Hamel Law, „Facilitating Software Architecture“. Wir werden auch ab und zu mal darauf zurückkommen. Aber ein paar Dinge sind doch anders als bei Andrew. Zum einen ist unser Kontext ein bisschen anders als bei ihm. Das finde ich, das ist das, was mich am heißesten macht, warum ich diesem Podcast so lange hinterhergerannt bin. Du hast auch eine Facilitator-Ausbildung gemacht, und das bringt, glaube ich, noch mal eine ganz andere Sicht und andere Möglichkeiten rein. Ich habe von dir schon einen Haufen geklaut und wahrscheinlich falsch angewendet, aber es wird trotzdem sehr viel genutzt. Gut, würde ich sagen. Du hast ja gesagt, du warst Entwickler und dann hattest du Zweifel, diese Architektenrolle übernehmen zu sollen. Das kann ich verstehen. Ich weiß nicht, ob das, zumindest dieses China-Projekt, da hätte ich ganz schön Schiss gehabt, das hat sich ziemlich kompliziert angehört. Aber dann lief das eigentlich ganz gut, sage ich mal. Wie kam es eigentlich dazu? Was war dein Ursprungsbild von der Architektenrolle und wie hast du das noch mal so grundlegend überdacht?

Holger Kraus: Das Interessante ist tatsächlich, dass die Fragen, die ich mir in diesem Artikel gestellt habe, gar nicht die Fragen waren, die mich zum Beispiel zu Beginn dieses China-Projekts stark beschäftigt haben, weil das aus meiner Sicht den Vorteil hatte, dass da viel klarer war, was eigentlich von mir erwartet wird. Da ging es halt konkret darum, dass wir eine Plattform, die schon in Europa lief, nach China bringen sollten. Das war eine Plattform, die aus vielen Self-Contained Systems bestand, und die Herausforderung war, dass wir für eine Domäne ein Self-Contained System brauchten, das von einem chinesischen Dienstleister entwickelt werden musste, weil es einfach auf den chinesischen Markt angepasst sein musste. Mein Job war da quasi, dem Team dabei zu helfen zu verstehen, was sie da technisch bauen müssen.

Ich sag mal, da war für mich im Kopf klar, ich bin der Typ, der jetzt irgendwie weiß, was Self-Contained Systems sind, und habe angenommen, das kennt man in China wahrscheinlich noch nicht so gut. Mittlerweile würde ich sagen, hat sich das geändert.

Genau, also ich hatte da quasi das Expertentum, was ich dachte, was man in der Rolle auch braucht. Also, dass ich da klar sagen kann, bitte macht Dinge so oder so. Die Fragen, die ich mir dann im Zusammenhang mit dieser Architektenrolle stellte, die ich in dem Artikel thematisiere, waren dann, sollte ich irgendwann nach diesem Projekt für denselben Kunden Architekt für ein Self-Contained System oder für eine Vertikale auf der europäischen Plattform sein, was zu, ich weiß gar nicht mehr genau, ich glaube 90 % aus INNOQ-Land bestand. Da konnte ich mein Selbstverständnis nicht davon ableiten, dass ich sagen konnte, ich bin jetzt der Typ, der Self-Contained Systems kennt.

Und irgendwie alles viel besser weiß als der Rest. Ich glaube, uns INNOQ teilt eine Erfahrung, wenn wir neu bei INNOQ anfangen, dass wir dann alle erstmal denken, oh Gott, sind die alle schlau hier, und man wird innerlich erstmal klein und traut sich nichts mehr.

Und dann merkt man, dass auch nur Menschen sind. Aber ich sag mal, die Rolle, jetzt da jemand zu sein, der dem Team sagt, was sie technisch tun sollen, quasi so als Alleinentscheider, mit der Rolle habe ich mich nicht wohlgefühlt. Das hat mich schon viel Überwindung gekostet, diesen Job dann auch anzutreten, aber ich habe tatsächlich dann einfach darauf vertraut, dass ich während der Arbeit dann schon irgendwann feststellen werde, wann wird denn jetzt wirklich ein Architekt gebraucht. Und das habe ich in dem Artikel eigentlich dargelegt.

Sven Johann: Ja, ich stelle mir das auch schwierig vor. Du kommst, ich sag mal, wenn du so in diese, wenn ich jemanden nach dieser Rolle frage und man hofft ja immer, dass man ziemlich gute Leute im Team hat und man weiß ja auch, ah ja, diese Person kennt sich da auf jeden Fall viel besser aus, ist ein ziemlich hoher Druck, finde ich auch, weil man denkt jetzt so, oh, ich stehe jetzt hier im Wind, aber da gibt’s einen Haufen Leute, die können eigentlich viele Sachen besser als ich. Genau, aber du sagst, ich habe, dass du gesagt hast, das wird schon irgendwie. Wie wurde das denn irgendwie? Du bist dann da losgelaufen und ich sag mal, das ist ja sowas wie was jeden First Timer, also du warst ja kein First Timer mehr, aber viele Leute, die jetzt zum ersten Mal so eine Rolle haben, sind natürlich schon unter Druck. Und wie lief das da für dich? Du hast ja praktisch neu überdacht. Was waren da so Auslöser?

Holger Kraus: Ja, ich war halt erstmal dabei, habe mir angeschaut, was da eigentlich entwickelt werden muss, und habe mir auch angeschaut, an welchen Punkten wir als Team eigentlich noch nicht wissen, was wir bauen. Habe dann versucht, diese Dinge zu klären und auch aufzuschreiben und abzustimmen. Mir sind dann zunehmend im Alltag immer mehr Situationen aufgefallen, wo ich gemerkt habe, im Daily berichten Entwickler von ihrer aktuellen Story, die sie gerade bearbeiten, und stellen sich während der Arbeit Fragen und wissen nicht so richtig, was jetzt das beste Vorgehen da wäre.

Und da habe ich dann irgendwann gemerkt, eigentlich ist das genau der Punkt, wo ich jetzt gebraucht werde. Nämlich quasi zu sagen, ich glaube, wir brauchen hier eine Entscheidung als Team. Lass uns das doch mal zusammen angucken. Und das ist dann das, wo ich dann auch in dem Artikel darauf eingehe, dass ich mich dann halt als Gastgeber einer Entscheidung wahrnehme. Also quasi wahrnehme, hier wird eine Entscheidung gebraucht.

Jetzt müssen wir mal Raum schaffen und jetzt stelle ich mal ein Meeting ein und überlege mir, wie wir in diesem Meeting vorgehen und genau, lasse dann im Grunde den Leuten, die es gerade entwickeln, den Raum, dann zu einer vernünftigen Entscheidung zu kommen.

Sven Johann: Ja, also im Grunde genommen anders als das alte Führungsbild mit Architektenklischee, dass eine Person die Entscheidung treffen muss?

Holger Kraus: Genau, also als Schlüsselelement habe ich tatsächlich empfunden, dieses Gespür dafür zu entwickeln, hier schwebt gerade eine nicht getroffene Entscheidung. Da dann quasi derjenige zu sein, der den Weg dafür frei macht, dass das getan werden kann.

Sven Johann: Ja, jetzt hatten wir ja Andrew Harmel-Law erwähnt. Ich würde sein Buch auf jeden Fall auch in die Shownotes packen. Ich finde, das Buch ist am Anfang ein bisschen komisch, in Anführungszeichen, weil er einfach in einem anderen Kontext unterwegs ist. Er ist wirklich in diesem Kontext – autoritärer Architekt gleich autoritäre Führungsperson. Das war bei uns eigentlich nie so, aber dann finde ich, hat er wirklich sehr gut beschrieben, wie man gemeinsam zu einer sehr guten Entscheidung kommt. Ich muss natürlich sagen, unsere Erlebnisse waren vor der Buchpublikation, aber er hat es zumindest mal als Buch aufgeschrieben. Wie schaffst du denn diesen Raum? Wie kann ich denn so einen Raum schaffen und wie kann ich eine gute Entscheidung hervorrufen?

Holger Kraus: Genau. Da gehe ich ja auch in dem Artikel drauf ein. Da steht für mich der Architecture Decision Record im Zentrum als Struktur. Der gibt auch eine gewisse Struktur vor. Wenn ich jetzt zum Beispiel so eine Besprechung ansetze mit den Leuten, die ich für eine Entscheidung brauche, dann finde ich zum Beispiel einen ganz wichtigen Punkt, dass man zuerst mal Einigkeit erzielt, welches Problem wir eigentlich lösen wollen. Weil da kommt oft schon zum Ausdruck, dass eigentlich gerade jeder ganz unterschiedliche Dinge unter dem versteht, was wir eigentlich lösen wollen.

Da finde ich tatsächlich ist es sehr fruchtbar, wenn man dann irgendwann feststellt, so jetzt haben wir uns auf eine Definition geeinigt und jetzt wissen wir auch, worüber wir gerade reden. Einen wichtigen Punkt habe ich jetzt gerade vergessen, weil ich gerade in diesem Team-Kontext gedanklich unterwegs war. Also, eigentlich der wichtigste Punkt am Anfang ist erstmal zu überlegen, wer sind die Stakeholder? Also, wer ist von der Entscheidung wirklich betroffen?

Sven Johann: Genau, vielleicht noch mal ganz kurz zurück, weil du hast ADR gesagt. Wir können gar nicht davon ausgehen, dass jeder weiß, was ein ADR ist. Vielleicht genau, wir gehen jetzt noch mal, wir gehen jetzt sozusagen Stück für Stück durch den ADR-Aufbau durch, ne? Weil du hast gesagt, das ist der Prozess. Genau, also, wer sind die Betroffenen? Da waren wir stehen.

Holger Kraus: Ja, beziehungsweise nicht nur die Betroffenen, sondern auch eventuell Experten, die sich gerade zu dem Thema, was wir bearbeiten, besonders gut auskennen.

Und da muss ich halt auch irgendwie einen Weg finden, diese Stakeholder halt irgendwie in den Prozess mit zu integrieren. Und das kann halt sehr unterschiedlich sein, weil ich würde halt so Sachen, die jetzt das Team betreffen, in dem ich gerade unterwegs bin, schon ein bisschen anders beurteilen als jetzt eine Entscheidung, die jetzt vielleicht meine Systemgrenzen überragt.

Ich finde die Unterscheidung von Mikro- und Makroarchitektur immer sehr wichtig. Mikroarchitektur, das kommt auch aus diesem Self-Contained Systems Kontext, ist quasi das, was ich innerhalb meines Systems tue, wo die Owner dieses Systems eigentlich frei sind, Entscheidungen zu treffen, von denen sie überzeugt sind, dass sie die Ziele, die dieses System erfüllen soll, auch erreichen können. Das ist zum Beispiel die Frage, welche Datenbank für meine Business-Domäne gerade die richtige ist.

Wie schneide ich meine Komponenten und so weiter? Und dann gibt es diese Makroarchitekturebene, wo man Einigkeit darüber erzielen muss, wie die Kommunikation zwischen diesen Systemen läuft. Zum Beispiel im Self-Contained Systems Kontext ist es so, dass man möglichst nur über asynchrone Mechanismen kommuniziert, damit man kein System hat, das zum Bottleneck wird und alle anderen mit herunterreißt, wenn es nicht verfügbar ist.

Das sind Architekturentscheidungen auf dieser Makroarchitekturebene, und da würde ich den Entscheidungsprozess grundsätzlich anders gestalten.

Sven Johann: Ja, ich habe gerade noch mal eine Situation, wo sehr viele Teams involviert sind. Wir benutzen den Begriff Makroarchitektur nur spärlich. Auf Mikroarchitekturebene reicht es eigentlich, dass die Teammitglieder die Betroffenen sind, und wir laden noch Experten ein, wenn wir zum Beispiel ein Security-Thema haben und uns nicht so gut mit Security auskennen. Aber auf Makroebene würdest du praktisch alle Stakeholder-Gruppen einladen. Wenn da zehn Teams sind und du hast so eine Makroentscheidung, dann muss praktisch aus jedem Team jemand dabei sein.

Holger Kraus: Da finde ich tatsächlich die entscheidende Frage, was gibt es denn schon in dem Kontext, in dem ich mich bewege?

Normalerweise kommen wir ja irgendwo hin, und dann gibt es schon irgendeine Architektur. Irgendwann hat sich jemand überlegt, wir wollen Self-Contained Systems als unsere Architektur verwenden. Dann ist die Frage, ob die schon ein Entscheidungsgremium geschaffen haben, in dem wir sprechen. Deshalb finde ich auch, man kann da keine allgemeine Empfehlung geben, oder ich will auch gar nicht sagen, ich mache das allgemein so oder so, sondern ich muss mir schon genau angucken, in welchem Kontext ich mich da gerade bewege und die angemessene Lösung finden. Wichtig ist, dass ich derjenige bin, der sieht, ich glaube, wir haben hier eine Entscheidungslücke, und wir müssen da mal einen Prozess initiieren.

Dann versuche ich möglichst, den zu organisieren, wenn es noch keine Instanz gibt, die das vielleicht schon tun könnte. Zum Beispiel könnte das sein, indem ich mich mit meinem Team zusammensetze und einen ADR schreibe, der erstmal so einen Vorschlagscharakter hat. Wir analysieren zusammen das Problem und sagen, das ist unsere Sichtweise, und dann kann man das ins Wiki stellen und gezielt Leute ansprechen und um Feedback bitten.

Sven Johann: Ja. Wir sollten vielleicht, bevor wir weitermachen, noch mal den Überblick über so ein ADR abschließen, damit. Also, wir haben Problemkontext, welches Problem wollen wir lösen, das hatten wir. Wir hatten die Stakeholder, also alle Leute, die Interesse haben, betroffen sind oder etwas beitragen können. Was ist noch Teil von so einem Architecture Decision Record? Würdest du noch mal so kurz?

Holger Kraus: Genau, am Anfang ist es wichtig, erstmal eine Einigung darüber herzustellen, was das Problem ist, das wir lösen wollen. Für mich gehört auch dazu, den Kontext zu beschreiben, in dem diese Entscheidung stattfindet, also Tragweite, was sind Faktoren, die diese Entscheidung beeinflussen. Aber auch schon mal sich Gedanken zu machen, anhand welcher Kriterien wir bewerten wollen, ob das, was wir uns jetzt überlegt haben, eine geeignete Lösung ist. Und dann kommt der spannende Schritt, den Andrew auch in seinem Buch beschreibt, das Option Making. Also, dass man sich wirklich überlegt, welche Optionen habe ich, um dieses Problem zu lösen.

Sven Johann: Ja, ich finde, das ist auch der interessante Teil. Wenn wir später auf Code gucken, sehen wir immer nur die implementierte Option, aber wir wissen nicht, welche anderen Optionen es gab und warum wir uns für diese Option entschieden haben. Das ist schon ein guter Teil. Genau, wir haben die Optionen, und dann müssen wir irgendwann noch mal entscheiden. Kannst du noch mal ein Beispiel für Kriterien nennen? Meine Frage kommt daher, weil man oft sieht, wenn man ADRs einführt, dass immer die Option gewählt wird, die am meisten grüne Pluspunkte hat, und nicht die am wenigsten Minuspunkte. Aber man kann nicht einfach nur Plus und Minus zählen, sondern es kommt wirklich auf die Kriterien an. Hättest du mal ein paar Beispiele für ein Kriterium?

Holger Kraus: Das fällt mir tatsächlich schwer, das jetzt einfach aus dem Ärmel zu schütteln.

Sven Johann: Okay, ja.

Holger Kraus: Was mir spontan einfällt, wäre aber eher schon etwas auf Makroarchitekturebene. Mikroarchitekturentscheidungen sind ja teilweise sehr spezifisch. Zum Beispiel, wie kann ich es hinkriegen, dass meine Gesamtplattform möglichst stabil läuft und ich unnötige Abhängigkeiten vermeide? Oder wie kann ich es – das sind jetzt eigentlich eher Fragen, aber das kann man auch als Kriterium formulieren. Oder ich möchte bestimmte Domänen unabhängig von anderen skalieren können.

Sven Johann: Ja.

Holger Kraus: Das wäre ein Kriterium zum Beispiel.

Sven Johann: Genau, dann werden die einzelnen Optionen bewertet. Die Frage ist, jetzt haben wir diesen ADR schriftlich, wir können über diesem Dokument brüten. Du organisierst die Stakeholder. Was ich auch interessant finde, ist, wie schaffst du es, Optionen zu generieren, weil du sagst ja, du willst es gar nicht alleine machen, du machst das im Team. Gibt es irgendwelche besonderen Facilitator-Kniffe jenseits von, wir müssen jetzt mal über Optionen nachdenken?

Holger Kraus: Es gibt keine besonderen Kniffe.

Sven Johann: Okay.

Holger Kraus: Der wichtigste Kniff ist, dass man sich nicht sofort auf eine Option stürzt. Das kennen wir alle: Jeder hat ein neues Lieblingsframework und möchte es gerne ausprobieren, aber da ist dann primär die Lust, es ausprobieren zu wollen, der wichtigste Faktor und nicht ein klares inhaltliches Kriterium.

Es hilft schon, wenn man sagt: „Okay, ich verstehe jetzt deinen Beweggrund dafür. Aber gibt es vielleicht Alternativen?“ Und dann merkt man dabei vielleicht auch, dass es einfach – manchmal entwickeln sich dann auch noch zusätzliche Kriterien, weil man sieht, eine andere Lösung hat einen ganz anderen Charakter, und das schärft dann quasi auch noch mal die Bewertungskriterien. Ich den Raum diese Option zu bilden nicht zu früh zu schließen.

Sven Johann: Ja. Das ist mir tatsächlich eben vor zwei Stunden auch aufgefallen. Gestern hatten wir Lösungsoptionen für ein Problem diskutiert. Ich sagte, okay, wir haben das jetzt besprochen, und ich kippe die in Text. Beim Schreiben mit einem Kollegen ist dann aufgefallen, und als wir dann nachdiskutiert haben, es gibt ja eigentlich noch andere Möglichkeiten, keine Ahnung, warum wir da, also noch andere Optionen, die völlig valide sind, müssen wir noch mit aufnehmen. Ich gebe dir auf jeden Fall Recht, dass man nicht zu früh schließen sollte.

Holger Kraus: Ja, in heutiger Zeit kann man natürlich auch KI bemühen. Einfach mal gucken, was dafür Vorschläge so kommen. Oder davor hat man halt einfach mal eine Internetrecherche gemacht. Gibt es Produkte, die dieses Problem schon lösen? Ein bisschen recherchieren gehört dann halt auch dazu. Oder die entsprechenden Experten interviewen.

Sven Johann: Ja, die sowieso, weil die können auf jeden Fall noch mal, also wenn wir keine Experten sind, dann ist immer die Gefahr, dass wir naive Optionen aussuchen. Jetzt muss ich sagen, ich war immer aus meiner Sicht hat es ganz gut funktioniert, dass ich bis hierhin ganz gut unterwegs bin. Ich kann Leute, ich weiß, wen ich einladen muss, ich weiß, wie ich die Kriterien definiere, ich komme eigentlich auch ganz gut auf Optionen zusammen mit einem Team. Aber jetzt müssen wir irgendwie entscheiden und müssen die Leute mitnehmen. Also das heißt mitnehmen, wir wollen eigentlich gemeinsam entscheiden. Und das ist schwieriger, als man denkt, das ist für mich. Und da habe ich auch ein bisschen von dir geklaut, als du mal von deiner Facilitator-Ausbildung erzählt hast und vielleicht, also deswegen, ich würde noch einmal ganz kurz fragen, wie du überhaupt diese Facilitator-Ausbildung gemacht hast, was da drin vorkommt und dann würde ich noch mal auf die Entscheidungsfindung kommen, sozusagen Personal Consulting von dir. Wie man das vielleicht nutzen kann. Genau, also du hast halt eine Weiterbildung in Facilitation gemacht und wie kam es eigentlich dazu? Was war die Motivation?

Holger Kraus: Die Motivation war tatsächlich, ich habe irgendwann mal, ich weiß gar nicht mehr genau in welchem, ich glaube auch durch die, ich habe die Ausbildung bei den Kommunikationslotsen in Köln gemacht, die ich sehr empfehlen kann. Und die hatten auch lange so eine Sparte Visual Facilitation, Bikablo mag dem ein oder anderen etwas sagen. Das sind so Meetings visualisieren mit einfachen grafischen Elementen, die man lernen kann, und dann haben selbst Leute, die immer von sich dachten, ich kann nicht malen, plötzlich ein Handwerkszeug an der Hand, mit dem sie doch erstaunliche Bilder kreieren können. Und so zum Beispiel für Klarheit in Meetings sorgen können. Wir haben bei der INNOQ tatsächlich mal so Schulungen angeboten zu Bikablo, die von den Kommunikationslotsen durchgeführt wurden, und da bin ich das erste Mal mit denen in Kontakt gekommen und habe dann auch noch bei irgendwelchen anderen Veranstaltungen von denen mal teilgenommen und fand das immer einen sehr interessanten Ansatz, den die so verfolgt haben und fand es einfach super interessant. Und genau. Also schreibe ich auch im Artikel, als ich mich da angemeldet habe, war mir tatsächlich nicht völlig klar, ob ich das, was ich da lerne, eins zu eins in meinem beruflichen Alltag umsetzen kann.

Sven Johann: Okay, ja. Ich habe gedacht, du hättest das so tatsächlich gezielt rausgesucht. Aber es war dann eher so, mir gefällt, was die tun, da kann ich bestimmt.

Holger Kraus: Nee, genau, ich würde sagen, da ist einfach das passende Angebot um die Ecke gekommen und hat mich angesprochen.

Sven Johann: Ja. Ich kann mich erinnern an dieses Bikablo, weiß gar nicht, warum ich da nicht dabei war.

Holger Kraus: Ich würde sagen, es ereilte mich der Ruf und ich bin ihm gefolgt.

Sven Johann: Ja, ich finde, die Fähigkeit, Klarheit in Meetings herbeizuführen und Struktur reinzubringen, ist auf jeden Fall etwas, wonach ich noch suche.

Ich möchte betonen, weil du dich gerade an dieser Struktur so festgebissen hast, dass es mir nicht darum geht, hier ein Rezept zu predigen.

Holger Kraus: Der Punkt, der mir wichtig ist, ist, dass ich mich als Architekt in der Rolle sehe, Entscheidungen zu organisieren und dafür zu sorgen, dass die richtigen Leute miteinander reden. Und dass am Ende eine gute Entscheidung dabei herauskommt. Ob diese Struktur die absolut beste der Welt ist, würde ich gar nicht behaupten. Ich habe das Gefühl, das machen viele andere auch so. Es sollte kein totaler Blödsinn sein.

Sven Johann: Nee, genau.

Holger Kraus: Aber wenn ein Team sagt, wir finden das nicht ideal, können wir das nicht anders machen? Es muss halt auch zum Team passen.

Sven Johann: Ja, stimmt. Ich arbeite zum Beispiel mit ziemlich vielen unterschiedlichen Teams und versuche, sie zu unterstützen. Teams sind halt einfach unterschiedlich. Aber ich hätte jetzt trotzdem gesagt, du hast wahrscheinlich einen Methodenkoffer, wie es so schön heißt. Du kannst dich wahrscheinlich relativ einfach anpassen, wobei ich immer das Gefühl habe, ich muss noch mehr an meinem Methodenkoffer arbeiten. Deswegen interessiert mich ja auch die Dinge, die du da in der Facilitator-Ausbildung gelernt hast. Gibt es irgendwelche Eckpunkte, wo du sagst, das sind so Key Learnings oder interessante Bausteine, die man nutzen kann, um das so zu organisieren, dass wir zu einer guten Entscheidung kommen mit den richtigen Leuten?

Holger Kraus: Das erwähne ich auch in dem Artikel. Der wichtigste Punkt für mich war nicht, dass ich einen zauberhaften Methodenkoffer bekommen habe, sondern eher der Aspekt des facilitativen Denkens. Eher mein Blick, wie ich auf eine Gruppe schaue. Das finde ich den viel entscheidenderen Aspekt.

Sven Johann: Ja. Wie guckt man auf so eine Gruppe? Mit welchem Blick oder mit welchen Blicken?

Holger Kraus: Vor allen Dingen, ein wichtiger Aspekt war ja noch das Thema Grundannahmen. Ich glaube, da wolltest du auch später noch mal drüber reden, oder?

Sven Johann: Eigentlich hatte ich das vorher, aber ja, wir können direkt darauf umschwenken. Wenn du erst über Grundannahmen reden willst, dann können wir das direkt jetzt machen.

Holger Kraus: Ja, das war für mich eines der wichtigsten Aha-Erlebnisse, das zu verstehen und wie einen das selbst prägt und wie ich durch die Veränderung von Grundannahmen tatsächlich Veränderungen bewirken kann.

Sven Johann: Ja, was ist eine Grundannahme?

Holger Kraus: Grundannahmen sind im Grunde Glaubenssätze, die ich mir angeeignet habe, durch Erfahrungen, oft nicht super reflektiert, sondern eher ein Grundgefühl im Hintergrund, das meine Sicht der Welt sehr stark beeinflusst.

Sven Johann: Mhm. Also zum Beispiel, der Software-Architekt trifft alle Entscheidungen, könnte eine sein, oder die andere könnte sein, der Software-Architekt hilft dem Team, Entscheidungen herbeizuführen. Sowas?

Holger Kraus: Finde ich jetzt nicht das beste Beispiel. Da würde ich eher auf das erste zurückkommen wollen. Dieses Bild: Ich als Architekt bin der seniorigste Mensch im Team, habe den meisten Durchblick und deshalb steht mir das zu.

Und beziehungsweise die Annahme, dass andere glauben, ich müsste dieser Mensch sein.

Das finde ich tatsächlich den viel entscheidenderen Aspekt an der Stelle, als dass ich das selbst von mir glauben wollen würde. Mein Zweifel an der Rolle war ja eher, ich befürchte, andere glauben, dass ich das so tun müsste, obwohl es mir eigentlich völlig widerstrebt.

Ich ticke selbst nicht so, und wenn ich dann das Gefühl habe, jetzt soll ich eine Rolle übernehmen, die mit genau diesen Erwartungen bewertet wird, dann fühle ich mich dieser Rolle nicht gewachsen.

Das bringt es eher zum Ausdruck. Die Grundannahme ist: Andere glauben, der Architekt muss alles wissen. Aber in Wirklichkeit ist das nur in meinem Kopf. Und danach treffe ich aber Entscheidungen, die dann zu einer Wirklichkeit werden.

Ein Aspekt, der dich im Vorgespräch interessiert hat, war ja dieser Aspekt: Bei Grundannahmen ist nicht der entscheidende Punkt, ob sie wahr sind, sondern ob sie hilfreich sind, oder?

Genau. Und da habe ich ein schönes Beispiel: Wir haben in der Weiterbildung die Grundannahme diskutiert, jeder gibt immer sein Bestes. Wenn du das Leuten sagst, kommt schnell eine Diskussion auf, ob das denn wirklich stimmt.

Sven Johann: Ja.

Holger Kraus: Was sind deine Gedanken dazu?

Sven Johann: Also ich würde sagen, ja. Zum Beispiel in meinem Kundenprojekt passieren an manchen Stellen wirklich verrückte Dinge. Aber wir versuchen trotzdem, wir sagen jetzt nicht, die haben einen an der Klatsche oder so, sondern wir sagen, hey, die stehen morgens nicht auf, um uns alle in den Abgrund zu reißen. Sondern die haben das beste Interesse der Firma oder zumindest mal, also ja, ich sage einfach mal, die haben das beste Interesse im Hinterkopf. Das stimmt nicht immer, manchmal sind natürlich Eigeninteressen dabei. Aber grundsätzlich würde ich sagen, das ist kein 100 % Fall, aber in, weiß ich nicht, 80 % der Fälle würde ich sagen, das ist eine richtige Grundannahme. Ich weiß nicht, wie du darüber denkst.

Holger Kraus: Die Erfahrung, die ich in diesen Diskussionen gemacht habe, war, dass viele Leute sofort Personen im Kopf haben, denen sie unterstellen, dass sie nicht immer ihr Bestes geben oder im Sinn haben. Da kommen schnell Bilder von jemandem, der sich nur profilieren will, in den Sinn. Wenn du das aus dieser Perspektive anschaust, ist es hilfreich, so zu denken. Ich würde sagen, es ist sehr hilfreich, weil es mir erlaubt, ohne eine nicht äußerbare Verdächtigung in eine Situation zu gehen und wirklich offen das Gespräch zu suchen. Wenn etwas nicht funktioniert, arbeite ich nicht unbewusst mit einer Unterstellung, sondern kann wirklich interessiert ergründen, ob es gerade Dinge gibt, die das Fortkommen blockieren, ob es etwas gibt, das man vielleicht lösen kann, und dann funktioniert es. Im Grunde ist das eine Grundannahme, die es ermöglicht, relativ vorurteilsfrei in eine Situation zu gehen, weil sie quasi jedem erstmal das Beste unterstellt.

Und das finde ich halt, das sind so Elemente, die ich total wertvoll fand, weil ich gemerkt habe, es hängt ganz viel davon ab, wie ich, wenn ich in dieser Rolle unterwegs bin, auf die Welt gucke. Und das lässt sich auch nicht, es gibt keine Methode, die du jetzt einfach abarbeiten kannst und dann kommen immer haargenau dieselben Ergebnisse raus. Viel wichtiger ist tatsächlich, mit welcher Haltung begegne ich meinen Mitmenschen und sehe ich sie als Leute, die Experten sind für die Dinge, die sie tun, die ganz viel wissen, von dem ich was lernen kann, oder sind das Leute, die ich irgendwie anleiten muss, damit sie genau das tun, was ich will? Das beeinflusst sehr stark, was hinten rauskommt, würde ich sagen.

Sven Johann: Ja, das stimmt.

Holger Kraus: Ich hatte mir im Vorfeld überlegt, wir könnten überlegen, ich habe hier ein paar Grundannahmen rausgesucht, die könnten wir einzeln besprechen. Ich stelle dir die vor und du kannst dann versuchen zu bewerten, was diese Grundannahme aus deiner Perspektive ermöglicht.

Sven Johann: Ja, machen wir mal.

Holger Kraus: Genau. Ich benutze hier ein Kartenset von den Kommunikationslotsen. Ich lese das vor. Die erste Grundannahme ist: Change kann man nicht bestellen, wie man eine Pizza bestellt.

Sven Johann: Da würde ich auch sagen, ja, weil die Pizza, die suche ich mir aus und dann bekomme ich die geliefert. Aber bei Change ist es natürlich, du kannst vielleicht mit so einem gewissen Methodenkoffer daran. Ich sage immer Methodenkoffer. Aber Organisationen sind halt unterschiedlich, also ist ein komplexes System mit ziemlich vielen Reaktionen und Gegenreaktionen. Ich glaube, man kann sich da nur inkrementell voranarbeiten. Und vielleicht scheitert es auch. Die Pizzalieferung scheitert ja in aller Regel nicht, aber der Change kann scheitern.

Holger Kraus: Was ermöglicht mir denn diese Grundannahme?

Sven Johann: Sie ermöglicht mir, glaube ich, dass ich nicht versuche, nach einem Algorithmus vorzugehen, sondern dass ich immer im Hinterkopf habe, dass ich vielleicht Sachen probieren muss und Feedback bekomme und mich auf das Feedback einstellen muss. Das würde ich so sehen. Ich würde es vielleicht mal dabei belassen.

Holger Kraus: Für mich steckt da vor allen Dingen drin, dass Change bestellen so wäre, als würde ich jemandem den Auftrag geben, sich zu verändern. Oder ein anderes Bild, was auch schief ist: Wir rollen Change jetzt mal aus. Es geht ja im Kern darum, dass wir uns, wenn wir Veränderungen wollen, gemeinsam auf den Weg machen müssen. Und wenn ich in irgendeiner Position bin, dass ich diese Veränderung bewirken möchte, dann muss ich mich auch mit den Leuten zusammen auf den Weg machen, und das heißt auch, dass ich unter Umständen mich selbst verändern muss.

Okay, ja. Im Grunde weitet das so ein bisschen den Blick und macht deutlich, worum es bei Veränderungen geht. Das wäre jetzt so meine Antwort.

Sven Johann: Ja. Ich hänge noch ein bisschen an dem Ausrollen, aber ist egal. Ich würde sagen, machen wir weiter. Du hast noch einen weiteren?

Holger Kraus: Einer geht noch, würde ich sagen.

Sven Johann: Ja gut, einen haben wir noch.

Holger Kraus: Bedeutung liegt nicht in den Dingen, wie der Keks in der Schachtel.

Sven Johann: Bedeutung liegt nicht in den Dingen, wie der Keks in der Schachtel. Gut, da würde ich jetzt sagen, das passt super zu meinem Berufsalltag. Die Bedeutung, wie Leute handeln oder welche Anforderungen sie haben, ist ziemlich oft ein vielschichtiges Problem. Es hat Historie und so weiter. Ich versuche, nicht vom oberflächlichen Handeln auszugehen und zu sagen, das ist doch idiotisch, warum machen die das denn, sondern ich versuche, dem Ganzen nach und nach auf den Grund zu gehen. Ich kann die Bedeutung nicht einfach öffnen, wie ich eine Schachtel öffne und dann sehe ich es, sondern das entsteht in einem längeren Dialog. Ich weiß nicht, ob das Sinn macht, aber das wäre so mein Versuch.

Holger Kraus: Nein, das macht Sinn. Meine Sicht darauf wäre, dass wir Dingen ja selber eine Bedeutung geben. Nur weil eine Sache für dich eine bestimmte Bedeutung hat, heißt das nicht, dass das für jeden anderen dieselbe Bedeutung hat. Es macht Sinn, sich mit den Leuten, die dich umgeben und in deinem Team sind, in einen Dialog zu begeben, um zu klären, was das für uns bedeutet und welche unterschiedlichen Perspektiven es darauf gibt. Welche unterschiedlichen Bedeutungen messen Leute dem zu? Es geht immer auch darum, eine gemeinsame Basis zu schaffen, damit wir ein Verständnis davon haben, worüber wir hier eigentlich reden.

Sven Johann: Ja. Die Amerikaner haben ja den Spruch: „We are on the same page.“ Es ist erstaunlich schwer, hinzubekommen, dass alle das gleiche Verständnis auf eine Situation haben. Ich hatte mal einen interessanten Workshop, bei dem der CTO und aus jedem Team ein Lead Developer dabei waren. Wir haben über die wichtigsten Ziele des Unternehmens gesprochen, die Auswirkungen auf die Softwarearchitektur haben. Wir haben ewig diskutiert, die Leute in dem Workshop, ich sage mal die neuen Team Leads. Dann hat der CTO irgendwann gesagt: „Ich habe jetzt keine Lust mehr, euch zuzuhören, ist alles Quatsch.“ Das war mit einem Lächeln, aber es war schon interessant. Er hat gesagt, die wichtigsten Ziele für die Architektur aus Geschäftssicht sind das, das, das und das. Wir fanden es alle sehr interessant, dass wirklich jeder eine andere Meinung hatte und es war völlig unklar, auch nach Jahren, wo sie in dieser Firma arbeiten, was eigentlich die Architekturziele sind, zumindest die Prioritäten. Da war es eigentlich nicht schlecht, dass alle dasselbe Grundverständnis von dem Problem haben, das wir hier versuchen mit der Architektur zu lösen. Gut. Oh, schon 50 Minuten. Grundannahmen. Okay, wir hatten jetzt schon mal zwei Grundannahmen. Du hattest gesagt, du hast ein paar mitgebracht, oder?

Holger Kraus: Ja, hier liegen noch ein paar. Die könnten wir vielleicht. Eine andere wäre noch: Nichtwissen ist meine Ressource, Fragen sind mein Potenzial. Was ermöglicht mir das?

Sven Johann: Bevor ich das beantworte oder versuche, wir können die ja alle in die Shownotes packen. Da können die Zuhörer noch mal selber schauen. Jetzt noch mal kurz zurück. Mein Nichtwissen ist mein…

Holger Kraus: Nichtwissen ist meine Ressource, Fragen sind mein Potenzial.

Sven Johann: Ja, das weckt bei mir eine Erinnerung an eine Beraterqualifizierung, die ich mal gemacht habe. Teil davon waren systemische Fragetechniken. Wir hatten da eine Demo-Session, bei der ein Kollege das Problem von einem der Trainer lösen sollte. Er ist nicht mit Nichtwissen herangegangen, sondern hat ständig versucht, Lösungen vorzuschlagen, wie: „Hast du schon mal das probiert oder das probiert?“ Die Antwort war immer: „Nee, nee.“ Das tat sehr weh, zuzuhören. Dann kam der systemische Coach, der einfach Nichtwissen hatte und systemische Fragen nutzte. Er hat durch diese Fragetechniken wahnsinnig viel aus dem Gegenüber herausgeholt. Das war wirklich sehr beeindruckend. Ich dachte mir: „Krass, wenn man sich dumm stellt, im übertragenen Sinne, und ich stelle einfach nur einen Haufen Fragen und ich kenne die richtigen Fragen, die ich stellen muss, dann kann ich wirklich zu sehr guten Lösungen kommen.“ Alle Beteiligten haben ein gutes Verständnis von dem Problem, weil wir dieses Problem so tief erörtert haben, einfach nur durch Fragen. Das hat bei mir ziemlich viel freigesetzt. Ich sage: „Ja gut, wenn ich nichts weiß oder vielleicht weiß ich auch ein paar Sachen, aber ich stelle mich einfach dumm.“ So kann ich sehr viel selbst über das Problem lernen, aber auch den Blick der Person weiten, die eigentlich das Problem lösen will, indem sie spricht und meine Fragen beantwortet. In Kürze, ich habe jetzt so viel geredet, drei Minuten oder so, in Kürze befreit mich das einfach, wenn ich sage, ich weiß jetzt nichts in Anführungszeichen, dann kann ich viel offener an so eine Diskussion herangehen. Ich sage nicht vorzeitig ja, wenn ich das Problem nicht wirklich verstanden habe, und durch dieses Nichtwissen kann ich sehr gut dem Problem auf die Spur kommen beziehungsweise auch Optionen erarbeiten. Wenn ich sage: „Verstehe ich nicht“, tut es immer ein bisschen innerlich weh zu sagen: „Ich habe jetzt leider überhaupt nichts kapiert. Kannst du das noch mal erklären?“ Aber das befreit mich davon, Angst zu haben, dass ich nicht frage und dadurch das Problem oder die Lösungsoption nicht gut verstehe.

Holger Kraus: Ich würde sogar noch einen Schritt weitergehen. Vielleicht befreist du damit sogar Leute in deinem Team. Wenn du ihnen zeigst, dass du dich nicht schämst, wenn du etwas nicht weißt, trauen sich vielleicht auch Leute, eine Frage zu stellen, wo sie denken: „Eigentlich darf ich das nicht fragen, weil jeder von mir erwartet, dass ich das weiß.“ Dadurch kommt eventuell auch ein Kommunikationsprozess in Gang, der vielleicht dringend nötig ist. Leute werden dann plötzlich wieder ins Boot geholt, die vielleicht schon abgehängt waren. Das wäre jetzt meine Interpretation.

Sven Johann: Ja, okay, stimmt. Das würde ich auf jeden Fall.

Holger Kraus: Ich würde sagen, es zahlt total auf das ein, was mein Problem mit dieser ursprünglichen Vorstellung von Architekt angeht. Ich muss nicht derjenige sein, der auf alles die Antwort hat. Ich muss derjenige sein, der identifiziert, wenn hier gerade eine offene Frage im Raum steht. Das wäre meine Interpretation.

Sven Johann: Mir fällt dazu noch ein, als ich im Studium am Lehrstuhl war, da waren ja auch einige sehr smarte Leute, alte Professoren mit langen Bärten, die berühmt waren, aber auch, ich sage mal, ich hatte so einen Betreuer, Big Shoutout hier Alexander Egel, jetzt Professor in Linz. Die hatten zum Beispiel überhaupt gar kein Problem damit. Das fand ich immer ziemlich interessant. Genau das, was du sagst. Wir haben uns immer gedacht, wenn der jetzt hier eine Frage stellt, wir hatten dieselbe Frage, aber wir haben gesagt, wir können das nicht fragen, das würde uns irgendwie zeigen, dass wir überhaupt nichts kapiert haben, dass wir überhaupt nicht zugehört haben. Aber der stellt die Frage auch. Das war ziemlich befreiend. Ich fand das auch, es gibt auf jeden Fall in den Gruppen eine gute, relaxte Stimmung. Das darf man auch nicht vergessen, und du hast viel weniger Angst, so ein Problem zu verstehen. Da stimme ich zu. Ja, verdammt, jetzt hast du mich angefixt, komm, einer geht noch. Einer geht noch und dann ziehen wir weiter.

Holger Kraus: Jetzt muss ich erst noch mal ein bisschen gucken. Veränderung ist an erster Stelle Selbstveränderung.

Sven Johann: Schwer. Meine Reaktion dazu war, ich hatte heute einen ähnlich gesprächsreichen Tag. Wir hatten auch über eine gewisse Veränderung gesprochen, also wie ein Kollege Veränderung bringt oder bringen soll, und das hat nicht so gut funktioniert. Meine Meinung war, immer wenn du Veränderungen in eine Organisation bringst, reagiert die Organisation auf irgendeine Art und Weise, und meistens nicht so, wie du das erwartest. Dein Ziel ist nicht, deinen Schuh durchzudrücken, sondern der Organisation oder Leuten in Teams zu helfen. Organisation ist vielleicht schon ziemlich viel. Diese Person hat sich nicht verändert. Es gab ständig Feedback, und die Veränderungsrufe wurden nicht angenommen, aber diese Person hat ihr Verhalten gar nicht angepasst. Und jetzt ist sie weg, vielleicht auch aus anderen Gründen. Aber da habe ich gedacht, ja, wenn man die Veränderung einbringt, funktioniert es nicht auf Anhieb. Ich muss mich selbst auch verändern und auf das Feedback eingehen. Vielleicht so, das wäre mein Interpretationsversuch.

Holger Kraus: Ich stelle mir bei dem Beispiel, das du gerade präsentiert hast, die Frage: Konnte diese Person an der Veränderung mitwirken? Konnte sie Einfluss darauf nehmen, in welche Richtung die Veränderung stattfinden sollte?

Sven Johann: Ja, die also beziehungsweise.

Holger Kraus: Hatte diese Person überhaupt einen guten Grund, sich selber zu verändern?

Sven Johann: Ja, sagen wir mal, sie hatte das Mandat, eine gewisse Veränderung in die Organisation zu bringen. Also, von daher, du hast das Mandat, Mandat bedeutet auch die Rückendeckung, von daher würde ich sagen, ja.

Holger Kraus: Mandat ist für mich aber nicht gleich Motiv. Für mich heißt es, Selbstveränderung ist, Veränderung passiert dann, wenn ich selber die Entscheidung getroffen habe, dass ich jetzt etwas ändern möchte.

Sven Johann: Ja, also das würde ich mal sagen, in dem Fall war das auf jeden Fall so. Dass du das Mandat hattest, das kam halt auch durch Selbstmotivation, sozusagen. Ich will das Mandat, ich will das ändern. Wenn es das ist, was du meinst. Genau. Was hilft, aber vielleicht kannst du mal sagen, wobei hilft mir das? Also, ich will was ändern, deswegen muss ich mich ändern. Also, es kommt aus einer inneren Motivation raus.

Holger Kraus: Genau, es kommt aus der inneren Motivation, und die Frage ist, ich möchte etwas ändern. Die Frage ist dann aber gleichzeitig auch, will sonst noch jemand etwas ändern? Gibt es überhaupt eine gemeinsame Wahrnehmung eines Problems? Im Grunde heißt es, dass man erstmal damit starten sollte, wie eine Situation von unterschiedlichen Beteiligten wahrgenommen wird. Und dann kann man eventuell auch, also wenn man dann zusammen zu dem Schluss kommt, ja, wir alle fühlen eine Belastung mit dieser Situation. Dann hat man vielleicht auch eine Situation geschaffen, wo sich eine Dynamik entwickeln kann, dass man zusammen an einem Strang zieht und eine Veränderung herbeiführen will.

Sven Johann: Vielleicht die letzte Frage, bevor wir ein abschließendes Kapitel machen: Wie schaffe ich das? Also, machst du dann Einzelinterviews, oder kommt es immer auf den Kontext an? Aber wie kriegst du heraus, wie alle Leute über die Situation denken? Wer will sich überhaupt ändern? Machst du da Einzelinterviews, besprichst du das in der Gruppe, machst du Umfragen, oder was wären da so Möglichkeiten, um dieses Wissen aufzubauen?

Holger Kraus: Das ist ein Punkt, wo ich wieder sagen würde, es kommt mehr auf die Haltung als auf die Methoden an. Die entscheidende Frage ist: Interessiere ich mich denn dafür, was andere denken? Wenn ich mich ernsthaft interessiere, dann brauche ich auch keine Einzelinterviews.

Sven Johann: Und aber im gegebenen Fall interessiert es mich wirklich, ja? Dann.

Holger Kraus: Dann finde ich, gibt es auch da kein Patentrezept. Es gibt immer eine spezifische Gruppenkonstellation, es gibt spezifische Charaktere, die vielleicht auch unterschiedlich auf bestimmte Ansprachen reagieren, keine Ahnung. Ich finde, deshalb betone ich das immer, die Haltung ist tatsächlich der entscheidende Punkt, und wenn ich dann offen für die Situation bin, dann fällt mir gegebenenfalls das Richtige ein. Das ist quasi kein Patentrezept, nicht wahr? Und um da den Kreis zu schließen, das ist eigentlich auch, ich schreibe in meinem Artikel ganz viel über den ADR und so. Das ist halt nicht unbedingt das eigentliche. Ich finde das eigentliche, worum es mir tatsächlich geht, aber das kann man nicht so leicht auf den Punkt bringen, ist wirklich diese innere Haltung: Ich als Architekt fühle mich dafür verantwortlich, dass wir gute Entscheidungen treffen. So. Und ich bin aufmerksam, identifiziere, wann eine Entscheidung gebraucht wird und bereite dann den Raum dafür, dass diese Entscheidung getroffen werden kann und dass die Leute, die zusammen diese Entscheidung treffen sollten, dann wenig Hindernisse haben, um sie treffen zu können. Wenn ich zum Beispiel dann einfach schon mal einen Besprechungstermin anberaumt habe, quasi so ein Meeting eine bestimmte Agenda hat, wenn ich mir vorher bestimmte Fragen überlegt habe, die wir besprechen sollten, wenn ich ein klares Ziel für diese Besprechung definiere, dass es halt nicht irgendwie so ist, ja, ich habe da diese Besprechung, ich weiß auch nicht, was wir da machen und am Ende haben alle miteinander verbracht und ist nichts dabei rausgekommen, nicht wahr? Also, so würde ich die Rolle dann sehen.

Sven Johann: Ja, das stimmt. Ich muss sagen, für mich war das Meeting das zentrale Element, weil ich mit vielen unterschiedlichen Teams zusammengearbeitet habe und mir aufgefallen ist, dass die Meeting-Organisation und wie ich sie leite und wie man dem Ganzen Struktur gibt, ein riesiges Thema war. Ich hatte auch dazu zum Beispiel mit INNOQ einen Podcast darüber gemacht, wie man erfolgreich solche Meetings durchführt. Und wir haben das dann auch tatsächlich jetzt bei uns im Team ziemlich strikt zeitweise durchgetaktet: Welche Arten von Meetings haben wir? Was ist eigentlich der Outcome und wie müssen die aufgebaut sein, damit wir die Zeit der Leute nicht verschwenden und sehr effektiv zu dem gewünschten Ergebnis kommen? Gut. Vielen, vielen Dank. Eine Frage hätte ich noch zum Abschluss. Ich meine, du hast ja eigentlich schon vieles kann man schon herauslesen oder heraushören vielmehr, aber wenn ich jetzt, weil ich es immer ganz interessant finde, ich bin Junior oder Midlevel Entwickler oder ich bin auch Senior Entwickler. Ich bin schon eine Weile dabei, aber ich will mich jetzt mehr Richtung Architektur entwickeln. Also, wie du sagst, ich will die Entscheidungen herbeiführen, will den Leuten da helfen. Gibt es so einen praktischen Rat von dir für jemand, der morgen damit anfangen will und sich da mal ausprobieren will, ohne dass er jetzt offiziell diese Rolle bekommt?

Holger Kraus: Also, da würde ich auch sagen, es geht nicht um die Rolle, sondern es geht um die Architektur-Entscheidung. Also, wenn ich jetzt Entwickler in einem Team bin und feststelle, mir ist gerade nicht klar, wie ich da jetzt am besten dieses Feature implementiere. Dann kann ich erstmal versuchen, ein Gespür dafür zu entwickeln, solche Situationen wahrzunehmen, und dann kann ich im Grunde selber anfangen, zum Beispiel schreibe ich schon mal für mich einen ADR. Bitte dann meine Kollegen, sich das mal anzugucken. Oder setze eben auch selber eine Besprechung an und sage, lass uns doch das Thema mal zusammen besprechen. Also, ich finde tatsächlich den wichtigsten Punkt, lernen so diese Situationen erstmal wahrzunehmen, weil das Schlimmste ist, wenn sich so eine Architektur einfach rausbildet, ohne dass ich mir bewusst darüber Gedanken gemacht habe. Und ich habe halt auch die Erfahrung gemacht, dass, wenn man so etwas ein, zweimal in einem Team gemacht hat, dann entwickelt sich eine Eigendynamik und Leute fangen selber an, ADRs zu schreiben.

Sven Johann: Ja, das stimmt. Das habe ich auch festgestellt, sozusagen einmal ADR, immer ADR. Und wie du sagst, wenn man sich auch Gedanken darüber macht, wen betrifft diese Entscheidung und wer ist Experte für die Entscheidungsfindung? Wenn man das so ein paar Mal durchgenudelt hat, dann kann man eigentlich nicht mehr anders. I cannot be unseen.

Holger Kraus: Genau.

Sven Johann: Dann hat man dabei.

Holger Kraus: Und der Aspekt, den ich halt auch wichtig finde, ist, es geht eigentlich darum, so eine Kultur von Architektur-Entscheidungen zu entwickeln, in dem Kontext, in dem ich mich bewege. Sodass ich als Person gar nicht dafür unbedingt gebraucht werde. Zu dieser facilitativen Grundhaltung gehört halt auch, dass man im entscheidenden Moment dann auch aus dem Weg gehen kann. Wenn alle sich eigentlich schon, also wenn alle quasi das Handwerk gelernt haben, dann wird man nicht mehr gebraucht und vor allen Dingen haben die Leute sich selber davon überzeugt, dass das der Weg ist, den sie bestreiten wollen und dann leben sie das auch irgendwie weiter.

Sven Johann: Verdammt, ich merke schon, ich bin gefeuert, aber niemand weiß es.

Holger Kraus: Ja, nee. Also, ich fand noch ganz interessant, du hattest in deinen Fragen, die du mir vorher geschickt hattest, geschrieben, muss jetzt jeder Architekt eine Facilitator-Ausbildung machen? Dazu ist mir halt die Frage in den Kopf geschossen, braucht man denn, wenn man diese Architekturrolle so begreift, überhaupt noch quasi Architekturwissen? Das wäre auch eine naheliegende Frage, die man mir stellen könnte.

Sven Johann: Ja.

Holger Kraus: Und da bin ich halt schon der Meinung, dass ich es schon als Voraussetzung sehe, weil ich ja, also ich muss schon in der Lage sein zu verstehen, mit welchen Problemen sich das Team gerade beschäftigt. Und dieses Gespür zu entwickeln, jetzt hier wird ja eigentlich gerade eine Entscheidung gebraucht. Ich weiß nicht, ob das so gut funktioniert, wenn man diesen Background nicht hat.

Sven Johann: Nee, das auf jeden Fall. Mir ging es ja darum, dass ein Facilitator jetzt Architektur-Entscheidungen treffen kann, aber wenn man die Architektenrolle annimmt, ob man halt auch, also wie viel, vielleicht ist eine Facilitator-Ausbildung zu viel, aber wie viel muss man sich eigentlich damit beschäftigen, also mit diesen Facilitator-Inhalten? Weil ich meine, wir machen ja auch Soft Skills Schulungen, wo wir uns mit Konflikten auseinandersetzen, zum Beispiel mit Teamdynamiken und so weiter, und ob so Facilitation eigentlich auch dazu gehören sollte.

Holger Kraus: Also, ich glaube tatsächlich, dass eine komplette Facilitation-Weiterbildung dafür nicht unbedingt nötig ist. Ich glaube tatsächlich, dass der Gedanke, ich bin nicht die Person, die alles wissen muss. Ich bin vor allen Dingen nicht die Person, die alles besser weiß. Und der Gedanke, dass Architektur-Entscheidungen eher umgesetzt und gelebt werden, wenn auch alle entscheidenden Personen das Gefühl hatten, daran beteiligt gewesen zu sein. Das sind so ein paar Grundpfeiler, die ich schon sehr hilfreich finde.

Sven Johann: Alright. Auf jeden Fall vielen Dank, sehr erhellend, muss ich sagen für mich.

Holger Kraus: Sehr gerne.

Sven Johann: Und ja, an alle, die, ich wiederhole mich immer, nicht wahr? Patrick Kua sagte ja immer, alle, die es bis hierhin geschafft haben, vielen Dank. Und bis zum nächsten Mal. Ciao, ciao.

Holger Kraus: Danke schön.

Diese Zusammenfassung wurde automatisiert erstellt und nicht manuell überprüft. Es kann daher Fehler enthalten. Maßgeblich ist immer das im Mitschnitt gesprochene Wort.

Wie können Softwarearchitekt:innen und -entwickler:innen eine Kultur der gemeinsamen Entscheidungsfindung etablieren, die über traditionelle Hierarchien hinausgeht und das gesamte Team befähigt?

Die Neudefinition der Architektenrolle: Vom Alleinentscheider zum Entscheidungs-Organisator

Holger Kraus ist seit 2010 bei INNOQ und hat verschiedene Rollen durchlaufen, vom Entwickler bis zum Architekten. In dieser Episode reflektiert er seine anfänglichen Zweifel an der Architektenrolle. In einem großen Projekt in China, bei dem eine europäische Plattform mit Self-Contained Systems an den chinesischen Markt angepasst werden sollte, war seine Rolle noch klar: Er war der Experte, der wusste, wie Self-Contained Systems funktionieren, und konnte dem Team entsprechende Vorgaben machen. Schwieriger wurde es, als er später in einem Team arbeitete, das hauptsächlich aus erfahrenen INNOQ-Mitarbeiter:innen bestand. Das Selbstverständnis als Wissender, der Anweisungen gibt, trug ihn dort nicht mehr.

Sven und Holger sprechen darüber, wie belastend dieser Druck sein kann, alles wissen und entscheiden zu müssen. Holgers Erkenntnis: Seine eigentliche Aufgabe bestand darin, zu erkennen, wann das Team vor einer Entscheidung steht, und den Raum zu schaffen, sie gemeinsam zu treffen. Er begreift sich seitdem als Gastgeber:in einer Entscheidung: jemand, der Meetings organisiert und den Prozess so strukturiert, dass eine fundierte Lösung entstehen kann. Ein Gegenentwurf zum klassischen Bild der Architekt:in als autoritäre Führungsperson.

Der Architecture Decision Record (ADR) als Werkzeug für kollaborative Entscheidungen

Im Zentrum von Holgers Ansatz steht der Architecture Decision Record (ADR) als Strukturierungshilfe. Ein ADR beginnt mit der Klärung des eigentlichen Problems und der Frage, wer von der Entscheidung betroffen ist oder fachlich etwas beitragen kann. Holger unterscheidet dabei zwischen Mikro- und Makroarchitekturentscheidungen: Mikroarchitekturentscheidungen betreffen das Innere eines Systems, etwa die Wahl einer Datenbank oder den Komponentenschnitt, und können oft im Team selbst getroffen werden. Makroarchitekturentscheidungen hingegen, etwa wie Systeme miteinander kommunizieren, erfordern eine breitere Einigkeit und entsprechend mehr Stakeholder.

Sven und Holger gehen die Bestandteile eines ADRs durch: Problembeschreibung, Kontext, Bewertungskriterien und die Erarbeitung von Optionen. Dabei betont Holger, wie wichtig es ist, den Optionsraum nicht zu früh zu schließen. Wer zu schnell auf eine Lösung zusteuert, übersieht möglicherweise bessere Alternativen. KI, Internetrecherche oder Gespräche mit Expert:innen können helfen, den Blick zu weiten. Und die Bewertungskriterien sollten nicht auf das bloße Zählen von Plus- und Minuspunkten reduziert werden, sondern konkrete Ziele widerspiegeln, etwa Systemstabilität, vermiedene Abhängigkeiten oder die unabhängige Skalierbarkeit einzelner Domänen.

Facilitative Thinking: Was Grundannahmen mit Architektur zu tun haben

Das wichtigste Learning aus Holgers Facilitator-Ausbildung war kein Methodenkoffer, sondern eine veränderte Haltung: Facilitative Thinking, also die Art, wie man auf eine Gruppe schaut. Dabei spielen Grundannahmen eine zentrale Rolle. Sie prägen, oft unreflektiert, wie wir Situationen wahrnehmen und darauf reagieren. Eine der Grundannahmen, die Holger besonders beschäftigt hat: Jede:r gibt immer sein Bestes. Ob das objektiv stimmt, ist weniger entscheidend als die Frage, ob diese Annahme hilfreich ist. Und das ist sie, weil sie ermöglicht, ohne versteckte Unterstellungen in Gespräche zu gehen und wirklich ergründen zu wollen, was eine Situation schwierig macht.

Weitere Grundannahmen, die Holger und Sven besprechen:

1. „Change kann man nicht bestellen, wie man eine Pizza bestellt.” Veränderungen lassen sich nicht einfach delegieren oder ausrollen. Sie erfordern, dass alle Beteiligten mitgehen, und das bedeutet manchmal auch, sich selbst zu verändern.
2. „Bedeutung liegt nicht in den Dingen, wie der Keks in der Schachtel.” Bedeutungen sind subjektiv und entstehen im Dialog. Was für eine Person selbstverständlich ist, kann für eine andere völlig anders konnotiert sein. Ein gemeinsames Verständnis lässt sich nicht voraussetzen, es muss erarbeitet werden.
3. „Nichtwissen ist meine Ressource, Fragen sind mein Potenzial.” Wer zugibt, etwas nicht zu wissen, schafft Raum für echte Gespräche. Und wer gezielt fragt, kommt oft tiefer ans Problem heran als jemand, der vorschnell Lösungen anbietet. Dazu kommt: Wenn jemand in einer Gruppe offen zeigt, dass er oder sie etwas nicht weiß, ermutigt das andere, dasselbe zu tun.
4. „Veränderung ist an erster Stelle Selbstveränderung.” Wer Veränderung anstoßen möchte, muss zunächst prüfen, ob alle Beteiligten überhaupt eine gemeinsame Wahrnehmung des Problems haben. Und ob sie einen eigenen Grund haben, sich zu verändern. Ohne das bleibt jeder Veränderungsimpuls von außen wirkungslos.

Praktische Schritte zur Entwicklung einer Architektur-Entscheidungskultur

Holger gibt einen konkreten Rat für Entwickler:innen, die sich in Richtung Architektur entwickeln möchten: Fang damit an, solche Situationen wahrzunehmen. Wer merkt, dass gerade unklar ist, wie ein Feature am besten umgesetzt werden soll, kann selbst die Initiative ergreifen: einen ADR schreiben, Kolleg:innen um Feedback bitten oder ein kurzes Meeting einberufen. Es braucht keine offizielle Rolle dafür.

Ziel ist eine Entscheidungskultur, in der das Team selbstständig Entscheidungsbedarfe erkennt und strukturiert angeht. Holger betont, dass es dabei nicht darum geht, als Architekt:in unersetzlich zu sein, sondern im Gegenteil: Wenn das Team das Handwerk einmal gelernt hat, braucht es einen nicht mehr. Und genau das ist der Punkt.