Architektur-Reviews

Anja Kammer: Hallo und herzlich willkommen zum INNOQ Podcast. Heute habe ich meinen Kollegen Gernot Starke eingeladen, um über Architektur zu sprechen. Hallo Gernot.

Gernot Starke: Hallo Anja!

Anja Kammer: Du bist bei INNOQ die erste Person, die einem so in den Sinn kommt, wenn man Fragen zur Architekturarbeit, Dokumentation und Architektur Reviews hat. Mit welchen Themen beschäftigst du dich denn noch?

Gernot Starke: Naja, noch beschäftigen mich Architektur und Doku und Reviews und dieses arc42-Universum schon ganz ausreichend. Ganz nebenbei, ein paar Prozent Freizeit gönne ich mir und Bücher schreiben sich auch nicht so einfach nebenbei. Aber diese Themen, die du genannt hast, das sind schon so meine Kernthemen.

Anja Kammer: Wir wollen heute über Architektur-Reviews sprechen und ich finde, die wichtigste Frage, die man sich stellen sollte, ist: Wozu benutzt man eigentlich Architektur Reviews? Wie kommt man auf die Idee, dass ein Architektur-Review jetzt sinnvoll ist? Welche Probleme will man damit eigentlich lösen?

Gernot Starke: Damit, Anja, stellst du direkt die Frage, die ich den Mandantinnen oder Mandanten stelle, wenn sie nach Reviews anfragen. Weil ich gerne aus dem Mund der Menschen hören möchte: Warum macht ihr das denn überhaupt? Wollt ihr damit vielleicht eure Architekturentscheidungen, technische Entscheidungen hinterfragen? Wollt ihr euer organisatorisches Setup hinterfragen? Generell, welche Details interessieren euch bei dieser Frage: Sind wir überhaupt auf einem vernünftigen Weg, mit der Art und Weise, wie wir das tun? Und wenn du möchtest, könnten wir mal ein paar Beispiele aufzählen, warum Leute denn Reviews gemacht haben.

Anja Kammer: Ja, bitte.

Gernot Starke: Eines der größten, die ich gemacht habe und der Sinn und Zweck dieses Reviews ist möglicherweise typisch für eine große Zahl dieser Reviews, war für ein System, das einerseits sehr groß und andererseits schon über relativ lange Zeit, also 10+ Jahre, sagen wir mal, hysterisch gewachsen, mit einer großen Zahl beteiligter Personen, beteiligter Organisationseinheiten. Und irgendwann hat dann einer der Verantwortlichen mal gesagt: So, wir investieren jetzt seit Jahren viel Geld in dieses Produkt. Wir erzielen auch hohe Erträge mit dem Produkt. Aber lass uns doch mal eine unabhängige Meinung einholen, ob wir denn mit der Art, wie wir da überhaupt vorgehen, noch zeitgemäß sind oder ob sich vielleicht Dinge eingeschlichen haben, die heute eleganter, einfacher, schlicht besser gehen? Das war so eine sehr generische Fragestellung, die sich aber wirklich auf die Breite bezog. Da waren wir, sowohl was die Technologieauswahl, was Code, Codestruktur, aber auch was so organisatorische Entwicklungsprozessthemen betraf, waren wir gefragt. Dieses Review ging sehr in die Breite. Ich nehme als zweites Beispiel deutlich kleiner, wo es wirklich um eine konkrete Technologieanalyse ging. Der Mandant hatte ein Content-Management-Problem, hatte ein internes Informationssystem. Und hatte sich da aus einer Mischung aus selbst gebaut und zugekauft, also Open-Source, eine Content-Plattform gebaut. Und wollte eben eine konkrete Aussage: Ist diese Plattform vernünftig gebaut? Da ging es überhaupt um Entwicklungsprozesse, sondern da ging es wirklich sehr darum, sich diese Technologie anzugucken und die Eignung der Technologie und der Erweiterung, die man gemacht hatte, für diesen speziellen Anwendungsfall zu betrachten. Das ist Beispiel Nummer 2, ein Review mit sehr technischem Fokus. Und das dritte Beispiel, was ich erwähnen möchte, das ist ein sehr großes Unternehmen, das ein System hatte, das mittel erfolgreich ist. Man wollte das schon auf jeden Fall behalten, aber die damalige Projektleiterin, die verantwortlich für sowohl die Teams wie auch das Produkt, also diesen gesamten Bereich war. Die hat das Team übernommen. Sie hatte den Verdacht, dass sie viel zu viele Leute hat und hat gar nicht so genau verstanden: Warum brauche ich so viele Leute für so ein an sich kleines Produkt? Da war eher die Prozessfrage. Das Staffing. Die Teamdynamik, passt die überhaupt zu dem Produkt, was wir da so haben?

Anja Kammer: Das heißt, ich muss mir schon meiner Probleme bewusst sein, um dann im dritten Fall zu sagen: Okay, jetzt brauche ich ein Architektur-Review oder ich brauche ein Review der Organisationsstrukturen.

Gernot Starke: Ich bräuchte ein Review. Ja, genau, so ein bisschen. Wenn Leute nach einem Review rufen, meiner Erfahrung nach haben sie dann zumindest schon so ein Bauchgrummeln. Entweder klare Fakten, wo sie sagen, irgendwas wird teurer oder irgendwas wird technisch schlechter, die Performance wird schlechter oder wie auch immer. Oder sie haben so ein Bauchgrummeln und sagen: Irgendwie sagt mir mein Gefühl: Da ist was zu teuer, da ist was zu langsam, da gibt es irgendwie so Schmerzen, die sie vielleicht nicht so ganz genau benennen können, aber dann ist so ein Review auch mit möglicherweise Beteiligten von außen, die nicht persönlich involviert sind im Plan. Und da komme ich jetzt noch mal zurück zu deiner ersten Frage. Ich möchte diese Frage gerne explizit stellen. Ich möchte ungern in so eine Review Situation gehen und irgendetwas untersuchen, vielleicht an den Bedürfnissen der Auftraggebenden vorbei. Und wenn mir jemand sagt: Du, schaue dir nur meine Technik an oder schaue dir nur mein Thema XY an, dann könnten wir darüber reden und sagen: Ja, das können wir tun. Wir können aber auch so ein bisschen umfassender schauen. Und letztlich entscheiden das diejenigen, die so ein Review beauftragen, wie breit oder auf welche Dinge fokussiert das nun sein soll.

Anja Kammer: Macht man diese Absprache, welche Themen Teil des Reviews sind, bereits weit im Vorfeld oder erst ab dem Kick-Off Termin? Ich kann mir vorstellen, dass es wichtig ist, bei einem Kick-Off viele Leute am Tisch zu haben, um dann gemeinsam zu entscheiden, wie der Scope ist von diesem Review. Wenn das vor einem Kick-Off gemacht wird, irgendwie nur zwischen Auftraggebenden und INNOQ zum Beispiel, kann ich mir vorstellen, dass dann gar nicht alles auf den Tisch kommt.

Gernot Starke: Ja, aber es könnte durchaus sein, dass jemand, der diesen Reviewauftrag vergibt, auch gar nicht möchte, dass alles auf den Tisch kommt und nicht bereit ist, für alles zu bezahlen. Das müssten wir respektieren. Und ich möchte gerne im Vorfeld sicherstellen, dass wir überhaupt die richtigen Leute in den Kick-Off bekommen. Das wäre ja fatal, wenn wir beim Kick-Off feststellen, dass wir riesenviele Themen im Betrieb, in Delivery Pipelines oder sowas haben. Und dann ist aber niemand da, der die Expertise besitzt oder der dazu im Kick-Off auch irgendwas sagen könnte. Deswegen finde ich so eine Kombi gut, dass wir in einer Art Vorgespräch beispielsweise mit INNOQ und 1, 2, 3 Leuten auch seitens der auftraggebenden Organisation schon mal darüber reden: Was ist denn Scoping, was sollen die Reviewgegenstände sein? Und dann gemeinsam zu überlegen: Was sind die Beteiligten, die bei so einem Kick-Off dabei sein sollten? Und wie sollte der überhaupt organisiert sein? Weil den könnte man auch auf unterschiedliche Arten und Weisen durchführen.

Anja Kammer: Ich habe auch ein paar Architektur-Reviews mitgemacht. Das machen wir natürlich auch in einem Team mit mehreren Leuten. Machst du Architektur-Reviews auch alleine?

Gernot Starke: Ich würde mich sehr fürchten, wenn ich das alleine machen müsste. Das meine ich ernst mit dem Fürchten, weil ich mich davor fürchten würde, dass ich Dinge total übersehe ode ich zu sehr durch spezifische Erfahrung vorgeprägt bin und mir dann da Dinge nicht auffallen würden. Ich glaube, Sparringspersonen sind unbedingt notwendig. Nehmen wir jetzt mal den Worst Case an: Ein Kunde, eine Organisation möchte definitiv nur eine einzelne Person beauftragen und sagen: So, liebe Anja oder liebe X von INNOQ, du bist die einzige Person, die das jetzt machen darf. Dann würde ich mir zumindest ausbedingen wollen, dass wir eine dedizierte Ansprechperson beim Kunden bekommen, aus diesem Mandat bekommen, die als Sparringsperson auch fungieren kann. Auch ein bisschen Architekturerfahrung, also nicht allzu voreingenommen, nicht gerade jemand, der Hard Core entwickelt mit in diesem Produkt hat. Dass da die Möglichkeit besteht, auch innerhalb des Reviewprozesses ein Feedback zu bekommen.

Anja Kammer: Das kann ja auch noch mehr Vorteile haben.

Gernot Starke: Ja, dieses Staffing vom Review, vielleicht lege ich dir diese Frage mal in den Mund. Ob du mich nicht aus dem Staffing von Reviews fragen möchtest.

Anja Kammer: Ja erzähl mal was.

Gernot Starke: Ja, im Grunde ist immer die Frage: Warum kann ich das nicht selbst? Warum sollen wir jetzt eine INNOQ oder jemanden von außen beauftragen? Und wenn man sich so vorstellt, ich kann natürlich selber meine Suppe abschmecken beim Kochen, aber ich bin vorgeprägt. Ich habe ja eine bestimmte Meinung und ich habe vielleicht die Zutaten reingeworfen, weil ich die gut finde und dann ist die Tendenz: Ja, die Suppe schmeckt mir, weil ich die gemacht habe. Und irgendwie sind Softwareprojekte oft komplizierter als Suppe kochen und es gibt viel mehr Aspekte, wo meine Vorbelastung mich halt negativ beeinflussen könnte. Und darum schätze ich das sehr, wenn wir in Reviews die Möglichkeit haben, uns einerseits zum Beispiel zwei Personen von INNOQ ein Feedback zu geben, aber andererseits auch mit internen Beteiligten diskutieren zu können, um beispielsweise Spezialfragen viel schneller beantworten zu können. Wir sind als Außenstehende nie so tief in der Materie drin, gerade fachlich in der Materie drin, wie die Leute, die das System bauen oder die am System arbeiten. Und fachliche Fragen kann ich viel besser mit jemand intern klären als mit jemand extern. Deswegen finde ich die perfekte Kombi für so ein Review zwei extern, zwei intern. Jetzt nicht unbedingt Vollzeit die ganze Zeit zusammenhocken, aber dass zumindest zwei Personen intern benannt sind. Als Ansprechpersonen vielleicht eher jemand mit fachlichem Hintergrund, Product Owner oder jemand mit Subject Matter Expert und jemand aus der Technik. Und genauso auch von außen zwei Personen. Und das ist wirklich die perfekte Kombi aus Breite und Tiefe und auch Geschwindigkeit.

Anja Kammer: Genau, gerade die Geschwindigkeit. Man hat eine Person, die sich schon mit der Organisation auskennt. Diese Person kann auch vermitteln, kann sagen: Ach, ihr braucht Informationen zu dem und dem Ding. Da kenne ich diese Person, mit der kannst du dann reden. Das geht natürlich viel schneller, wenn man eine Person intern hat, die einem solche Kontakte vermittelt, als wenn man das selber irgendwie herausfinden muss und über mehrere Wege dann die richtigen Personen bekommt.

Gernot Starke: So diese interne Vernetzung.

Anja Kammer: Ja.

Gernot Starke: Das ist wirklich, das ist Gold wert, jemanden zu haben, die oder der halt genau Bescheid weiß: Ah ja, da gab es doch mal oder gibt es doch diese Abteilung so und so, die sich genau mit dieser speziellen Frage, dieser speziellen fachlichen oder technischen Situation auskennt, die wir fragen können.

Anja Kammer: Ja.

Gernot Starke: All das, das wäre für Staffing des Reviews wirklich perfekt, wenn man das so organisiert bekäme. Ich glaube, dass das auch den Output, den Wert dessen, was man so an einem Review zutage fördern kann, wirklich maximiert. Das ist wirklich gut investierte Zeit und Geld, das eben nicht nur auf einem paar Schultern abzuladen, sondern das da schon so ein bisschen zu verbreitern.

Anja Kammer: Mir ist auch aufgefallen bei den Reviews, bei denen ich dabei war, dass manchmal diskutiert wird über die Zeit, die Entwicklungsteams und Architektinnen zur Verfügung stehen können für Fragen und für Interviews. Weil dann manchmal gesagt wird: Die Entwicklungsteams sind gerade in einer harten Zeit, die müssen ihre Features fertig kriegen. Bitte versucht da so wenig wie möglich deren Zeit zu klauen. Dabei ist es doch super wichtig, gerade bei so etwas wie ein Architektur-Review die richtigen Personen an die Strippe zu bekommen und da vielleicht doch extra Zeit zu investieren.

Gernot Starke: Ich glaube, dass wir das ziemlich gut kalkulieren können. Auch da sprechen wir vielleicht später noch über dieses Thema, Interviews mit den beteiligten Personen. Ich stehe da sehr darauf, mit diesen beteiligten Personen, die aktiv am System arbeiten, wirklich persönlich zu sprechen. Also face to face ist sicherlich noch effektiver als das dann online zu machen, aber das Medium ist dann egal. Ich möchte gerne mit diesen Leuten reden. Und ich möchte nicht mit denen acht Stunden hintereinander reden.

Anja Kammer: Ja, genau.

Gernot Starke: Das wäre übertrieben. Deswegen, meine ich, kann man das relativ gut auch kalkulieren. Wenn wir ein Entwicklungsteam von zehn Personen haben, dann will ich nicht mit jedem davon reden, sondern vielleicht mit 1, 2. Im ersten Schritt mal eine Stunde und dann aber bestimmt noch mal. Und dann habe ich zwei Personen jeweils eine Stunde und dann vielleicht noch mal, das kann man zusammenzählen. Und das ist gar nicht so viel. Das ist jetzt nicht so der Mörderaufwand und versetze ich mich jetzt mal in die Situation von jemand, der in Sprint lang gerade stressig Features bauen muss. Eine Stunde, Entschuldigung, das machen wir mit einer verlängerten Mittagspause. Da freuen sich die Leute, dass sie mal ein bisschen Abwechslung haben und mal ein paar Beschwerden loswerden können. Das kriegt man schon unter. Ich will jetzt nicht am Freitag vor dem wichtigsten Release aller Zeiten, nachmittags um 15:00 Uhr, bevor man den Schalter umlegt, dann die Leute interviewen. Das wäre verrückt. Aber wenn man so einen Review plant, dann macht man das nicht mit: Morgen muss alles fertig sein, sondern mit so ein bisschen Vorlauf. Und das kriegt man dann eingeplant.

Anja Kammer: Bevor wir über die Interviews sprechen, die du angesprochen hast, wie lange läuft dann so ein Review? Wie viel Zeit muss eine Organisation einplanen, um so ein Architektur-Review durchführen zu lassen?

Gernot Starke: Wie immer: You get what you pay for. Oder: Kommt darauf an, ist die andere Ausprägung. Du kannst natürlich Reviews machen in sehr, sehr kompakter Zeit. So, schau da doch mal zwei Tage lang als eine Art Bestandsaufnahme darauf und gib mir mal so ein erstes Feedback. Kann man machen. Und in zwei Tagen, mit ein paar Interviews dabei und ein paar kundige Stakeholder dabei, kriegt man bestimmt ein bisschen Indikation. Aber du kannst nirgendwo in die Tiefe schauen. Die riesigen Reviews, an denen ich beteiligt war, wo es so eher um 20, 50 oder noch mehr Personentage geht. Das sind aber auch Reviews von Systemen gewesen, wo 100 Leute und noch mehr parallel daran arbeiten. Die meisten Menschen, die Auto fahren, die kennen das Budget, was sie investieren müssen für jährliche Inspektionen, Wartung und Ähnliches. Und für mich ist so ein Review so was Ähnliches wie so ein Werkstatttermin von meinem Auto, wo mir wichtig ist, dass das auch sicher über den Winter kommt. Mal nach dem Öl, nach der Bremsflüssigkeit usw. schauen. Da gebe ich nicht 30 % meines Einkommens im Jahr für diese Autoinspektion aus. Aber mit 0 % wär es auch etwas wenig. Und wenn wir im kleinen einstelligen Prozentbereich von Halbjahres- oder Jahresbudgets reden, dann ist das natürlich als absolute Summe viel Geld, aber aufs Jahr betrachtet ist das ein Marginalbetrag. Deswegen ist auch in so einem Vorgespräch natürlich die Diskussion: Wie viel Zeit sollen wir denn investieren? Und wenn es zu kurz ist, dann kann ich schon prophezeien: Ja, einen ersten Eindruck kann ich liefern, aber das ist dann ein erster Eindruck, ohne dass ich den validieren oder verifizieren kann.

Anja Kammer: Da ist bestimmt wichtig, auch die Erwartungshaltung schon vorhinein zu steuern.

Gernot Starke: Genau.

Anja Kammer: Jetzt hast du gesagt, in zwei Tagen bekommt man auch ein Review hin und dann ist mir eingefallen: Naja, wenn ich jetzt beispielsweise Montag und Dienstag ein Architektur-Review mache, dann kann ich mir nicht vorstellen, dass das funktioniert. Du meintest bestimmt zwei Tage als Gesamtsumme. Weil innerhalb von zwei Tagen kommt man nicht mal zu irgendwelchen Zugängen, um sich Dinge anschauen zu können. Das heißt, es streckt sich dann schon auf ein oder zwei Wochen.

Gernot Starke: In diesen zwei Tagen, sagen wir mal so eine von außen Betrachtung zur Lage der Nation. Ich rede mit ein paar Stakeholdern. Ich schaue nicht in einen konkreten Source Code rein. Das schaffe ich in zwei Tagen nicht. Das wäre skurril, das zu versuchen. Aber ich rede mal mit ein paar Stakeholdern, ich sammle ein bisschen Stimmung auf und ich vergleiche das, was ich da sehe, im Sinne von Benchmarking mit dem, was ich aus anderen Organisationen kenne. Das kann ich machen. Aber wie gesagt, die Ergebnisse, die dann daraus kommen, sind eher so Hinweise wie: Ah, euer Deployment, euer CI habt ihr aber gut im Griff, aber dafür sind eure Requirements Substandard. Die sind schlechter als sie sein sollten. Und das kann man dann bestimmt auch nach zwei Tagen an ein paar Beispielen belegen, ohne dass ich, wie gesagt, in den Code reingefasst habe. Und wenn ich dann eine Abstraktionsebene weiter reinschaue, also mir wirklich konkret Dinge im Code, in der Config, in Testfällen, im Bugtracker usw. anschaue, dann brauche ich auch entsprechend mehr Zeit. Oder aber die interne Sparringsperson, neben die ich mich dann an Schreibtisch setzen kann und sagen kann: Zeig du mir doch mal was in eurem Confluence oder zeig du mir doch mal die Liste der offenen Bugs und wir gucken da dann mal zusammen durch. Ich will jetzt auch gar nicht auf diesen zwei Tage rumreiten. Ein bisschen mehr Aufwand bringt auch dann schon deutlich höhere Erträge, also deutlich inhaltlich tiefer gehende und belastbare Ergebnisse, als wenn man eben einfach nur mal so eben guckt.

Anja Kammer: Genau. Ich kann mir vorstellen, wenn man auch mal nur so mal eben guckt, kommen häufig Dinge zu Stande, die den Auftraggebenden schon bewusst sind. Und das dauert natürlich für dich länger, um da erst einmal dein Ramp-up abzumachen, um diese Dinge sehen zu können.

Gernot Starke: Ja, wobei meine Erfahrung über wirklich viele Jahre Reviews mir gesagt hat, dass ganz ganz viele Probleme innerhalb der Organisation ohnehin bekannt sind. Sie werden nur nicht gehört oder Leute haben sich daran gewöhnt.

Anja Kammer: Also man sieht den Wald vor lauter Bäumen nicht.

Gernot Starke: Genau, du siehst den Wald nicht, oder du hast dich halt daran gewöhnt, dass man auf so eine, entschuldigung, ganz bescheuerte Art irgendwelche Dinge programmiert. „Machen wir schon immer so“, „geht halt auch so.“ Und dann fällt dir irgendwann gar nicht mehr auf, dass es eigentlich eine bescheuerte Art ist. Aber du hast dir vielleicht schon ein kleines Skript geschrieben. Das legt dir dann diese fünf Dateien an, in denen du irgendwas machen musst. Und wenn du dann von außen darauf schaust, dann fasst du dir an die Stirn und sagst: Hä, warum ist das so mörderkompliziert? Das geht doch viel einfacher. Aber das sind dann Dinge, wo man eben ein bisschen tiefer reinschauen muss, auch ein bisschen länger Zeit braucht.

Anja Kammer: Ja, dann lass uns doch jetzt über die Interviews sprechen. Das heißt, ein wichtiger Teil von Architektur-Reviews ist es, Interviews zu führen mit Entwicklungspersonen, mit Architektinnen. Welche Ziele verfolgst du da?

Gernot Starke: Ich gehe noch mal einen Schritt zurück. Mit welchen Leuten ich Interviews führen, wünsche ich mir als ein Ergebnis aus so einem Kick-Off zum Beispiel. Ich würde in dem Kick-Off schon so ein initiales Brainstorming mit Leuten machen wollen. Was für Art von Problemen habt ihr überhaupt? Wo nervt irgendwas? Dann kommen natürlich Leute aus dem Entwicklungsteam, die sagen: „Hey, da ist diese Komponente im Code oder diese Art Abhängigkeiten“ oder: „Immer müssen wir in fünf Dateien irgendwas machen“. Dann gibt es jemanden aus einem Team, das sich eher mit Daten beschäftigt, die sagen: „Menschen, wir haben da diese zentrale Tabelle und an der hakt es immer“. Und es wird vielleicht Leute vom Fachbereich geben, die sagen: „Boah ey, wenn solche Anforderungen kommen, dann brauchen die immer ein ganzes Jahr, bis sie das umgesetzt haben“. Und daraus kriegt man dann schon so eine schöne Bandbreite an, nennen wir die mal Problemkategorien. Und diese Kategorien, diese Klassentypen von Problemen, die würde ich zum Ausgangspunkt nehmen und sagen: Mit welchen Leuten möchte ich über diese Kategorien von Problemen ein bisschen genauer sprechen? Und das sind, ja, da gebe ich dir ganz Recht, oft Personen aus dem Entwicklungsteam, mit denen ich darüber reden will. Das sind aber auch oft Leute, die rein mit fachlichen Dingen beschäftigt sind, vielleicht im Support arbeiten und sich ständig die Anfragen genervter End-User anhören müssen. Und mit wem ich dann spreche, ist eben davon abhängig, was wir in diesem Kick-Off da so an Kategorien gefunden haben.

Anja Kammer: Ach, das ist das erste Mal, dass ich das höre, dass man mit einer Supportmitarbeiterin, einem Supportmitarbeiter sprechen möchte. Ich finde das auch super spannend und wichtig. Schön.

Gernot Starke: Das ist total Augen öffnend und ich habe auch mit Organisationen zu tun gehabt, wo die Leute aus dem Entwicklungsteam ab und zu mal für eine Woche im Support arbeiten mussten und sich selbst anhören mussten, was denn eigentlich End-User über die Produkte sagen. Und da kann man wirklich, ich will nicht sagen, anfangen zu weinen, aber da trifft dann diese Erwartungshaltungen der Entwicklungsseite auf die harte Realität von Leuten. Ja, es steht zwar da, aber sie übersehen es halt alle. Es steht ganz eindeutig: Diesen Button nur drücken, wenn folgendes…Aber das liest halt keiner. Und wenn Entwicklungsteams das mal mitbekommen haben, das ist wirklich ein großer Schritt. Aber ich glaube, das passiert zu selten. Darum könnten wir das in Reviews übernehmen. Und die Supportleute würden sich übrigens sehr freuen, wenn mal einer mit ihnen redet. Dass man auch mal nach ihren Problemen fragt.

Anja Kammer: Auf jeden Fall. Du hattest auch gesagt, dass du nicht nur einmal mit den Personen sprichst, sondern meistens zweimal oder öfter. Und mir ist das auch aufgefallen, dass es wichtig ist, eher viele kleine Termine zu machen, weil während des Reviews fallen dann einem noch mehr Fragen ein, die man vorher nicht stellen konnte, weil man den Kontext nicht umfassender gesehen hat. Und deswegen passiert das häufig, dass man mehrfach mit den Leuten spricht.

Gernot Starke: Ja, das kann gut sein, dass dir neue Fragen einfallen. Es könnte auch so was passieren wie, jemand äußert einen Verdacht. Er sagt so: „Ich glaube, an der und der Stelle ist irgendwas“. Und im Interview kann ich dazu keine Stellung nehmen. Ich kann es aufnehmen und sagen. Der Verdacht ist: Mittwochs Nachmittag um 16:00 Uhr ist meistens das System immer so langsam. Da gehen die bestimmt alle Kaffeetrinken. Und dann könnten wir dem nachgehen und könnten dann feststellen: Oh, was ist denn Mittwochnachmittag? Und dann stellen wir vielleicht fest: Oh, Mittwochnachmittag. Die gehen gar nicht Kaffeetrinken, aber da läuft immer so ein Backup Skript. Dann könnten wir auf dieses Thema „mittwochnachmittags alles langsam“, vielleicht im zweiten Schritt dann mal wieder zu sprechen kommen. Oder wir haben im Code irgendwas nachgeguckt. Die Option, ein zweites Mal zu sprechen, möchte ich mir gerne in Interviews offenhalten. Es sei denn, jemand sagt: „Ich bin wirklich im Moment so unter Dampf und die Stunde habe ich jetzt mir gerade rausgeschnitten aus dem Kalender. Aber ich kann jetzt halt nicht.“ Auch das müssten wir akzeptieren. Da kann man nichts gegen tun, aber das ist schon immer nett, wenn man noch ein zweites Mal sprechen könnte. Insbesondere mit so Kernrollen wie Architektur oder PO Rolle. Es gibt in Organisationen wirklich auch noch so betriebsverantwortliche Personen, mit denen vielleicht auch noch ein zweites Mal reden, wenn man was mehr gelernt hat. Das ist, glaube ich, schon häufig der Fall.

Anja Kammer: Bei meinem ersten Architektur-Review, das ich zusammen mit einem Kollegen durchgeführt hatte, hatten wir versucht, die ATAM-Methodik zu folgen, um eine Struktur in solch ein Architektur-Review zu bringen und nicht nur einfach sinnlos irgendwelche Interviews zu führen. ATAM, für unsere Hörerinnen, ist die Abkürzung für Architecture Tradeoff Analysis Method. Und das macht man um Qualitätseigenschaften und die Risiken eines Systems zu analysieren, um dann eine Aussage zu treffen, ob das Projekt gerade irgendwie in Schieflage ist oder ob ein Termin eingehalten werden kann oder welche Arbeiten noch unbedingt vorher gemacht werden müssen, bevor die ersten Kundinnen das System beispielsweise benutzen. Benutzt du auch ATAM als Methodik, als Grundgerüst oder welche Struktur benutzt du da?

Gernot Starke: Wir oder ich haben ab und zu ATAM oder ATAM Verschnitte, also vereinfachte Versionen von ATAM verwendet, zum Beispiel im Kick-Off. Das Kick-Off schon so zu organisieren, dass das ganz stark auf konkrete Qualitätsanforderungen fokussiert. Im Kick-Off mit den Leuten schon erarbeitet, welche dieser Anforderungen denn schlecht erfüllt sind oder gar nicht erfüllt sind oder nur mit Mühe erfüllt werden können. Was für Lösungsansätze für diese Qualitätsanforderungen eingegangen waren. Und ich würde das vielen Stakeholdern im Kick-Off auch gar nicht erzählen, dass das ATAM ist, was wir da gerade tun. Sondern ich schlage dann vor, dass wir uns diese Qualitätsanforderungen gemeinsam erarbeiten. Das geht nicht mit 25 Leuten parallel, aber im überschaubar großen Kick-Off Meeting. In einem überschaubar kleinen Kick-Off Meeting mit vielleicht 5 bis 10 Personen geht das ganz prima. Macht richtig Spaß. Die Leute befinden sich in ihrem System, es ist ihre Begrifflichkeit, die wir da verwenden. Und dann kommt man in dem Kick-Off schon auf eine ganze Reihe Ansatzpunkte eben zu Qualitätsdefiziten oder zu sehr konkreten Qualitätsanforderungen, die vielleicht nicht erfüllt sind. Oder auch, und das ist auch ein ganz schönes Review Ergebnis, besonders gut erfüllt sind. Dass man eben auch im Kick-Off schon feststellt: Es gibt Aspekte im System, die sind einfach saugut und die will man auf gar keinen Fall ändern. Das ist ein sehr schönes und wichtiges Review Ergebnis, auch mal festzuhalten: Irgendwas ist besonders positiv. Damit Entwicklungsteams das dann auch beibehalten.

Anja Kammer: Hattest du schon mal als Review Ergebnis, dass bestimmte Qualitätsanforderungen, die gar nicht so wichtig waren, viel zu übererfüllt waren? Also viel zu hohe Performance gar nicht notwendig ist, viel zu…Ich weiß es nicht. Ich kann mir so schlecht was ausdenken. Dass irgendwelche Qualitätsanforderungen, die gar nicht so notwendig sind und gar nicht so hoch priorisiert sind, dass da viel zu viel Fokus drauf liegt und deswegen Ressourcen anderweitig viel besser aufgehoben werden?

Gernot Starke: Ja, dieses Thema übererfüllend. Ich will das jetzt auch gar nicht allzu sehr verallgemeinern, aber aus meiner Sicht ist das fast ein Klassiker, dass Entwicklungsteams implizit annehmen, Dinge zu gerade Änderbarkeit und Performance beispielsweise: Das muss schnell sein. Das muss diese Performance, ähnlich wie die großen Internetdienstleister haben. Ich drücke auf den Knopf und unmittelbar sind Ergebnisse da. Und das an dieser Stelle dann vom Entwicklungsteam optimiert wird, um das auch in diese Größenordnung performen zu bekommen. Das kriegt man auch hin. Und dann stellt man fest: Oh, die Endanwenderinnen oder Menschen, die das bedienen, klicken da drauf, kurz bevor sie in Feierabend gehen und schauen sich ihre Ergebnisse am nächsten Morgen an. Das heißt, die gesamte Optimierung an dieser Stelle war für die Katz. Das hätte man auch bleiben lassen können. Gründe dafür liegen oft darin, dass die Anforderungen an der Stelle unsauber sind oder unklar sind oder aber so ein Kommunikations-Mismatch zwischen der Fachseite und dem Entwicklungsteam besteht. Die reden nicht miteinander. Und das ist auch ein interessantes Review Ergebnis, um festzustellen: So, ihr habt dazu was gemacht. Technisch ist das ziemlich kompliziert und vielleicht auch pflegeaufwendig und ihr habt einfach übererfüllt. Ihr habt einfach mehr geliefert als wirtschaftlich nützlich oder hilfreich oder sinnvoll. Und das ist ein Thema, das kommt schon vor. Ich würde nicht sagen in jedem System. Aber das kommt schon öfter vor.

Anja Kammer: Und wie findest du das dann? Welche Methodik wendest du an, um herauszufinden, ob Dinge übererfüllt werden?

Gernot Starke: Ich stehe auf Qualitätsanforderungen in konkret. Ich möchte gerne konkret wissen, und das sind eben, wie gesagt, Fragen, die ich auch schon im Kick-Off platzieren möchte. Wie ist das denn mit euren Qualitätsanforderungen? Wie performant? An welchen Stellen braucht ihr Änderbarkeit? Wo sind wirklich eure sicherheitskritischen Daten? Ich möchte da schon so früh wie möglich und spätestens in Interviews mit Leuten auf konkrete Qualitätsanforderungen zu sprechen kommen. Und dann können wir uns anschauen, was das System an diesen Stellen denn leistet. Und wenn wir dann merken: die Anforderung an der Stelle, beispielsweise irgendwelche Reporting Dinge. Die Fachseite sagt, die können ruhig über Nacht laufen. Und im konkreten System merke ich dann, dass sehr viel Aufwand betrieben wurde, um Performance zu optimieren. Dann fällt, glaube ich relativ schnell auf, dass wir da so ein Mismatch haben.

Anja Kammer: Ja spannend. Das hat also schon ein Workshop Charakter dort, dieses Kick-Off.

Gernot Starke: Ja, das Kick-Off auf jeden Fall. Das ist keine Vorlesung, wo wir jetzt irgendeine Theorie erklären, das würde überhaupt keinen Sinn ergeben, sondern da möchte ich schon auch im Kick-Off möglichst viel wissen. Und ich gehe noch einen Schritt zurück. Ich formuliere das noch mal anders. Die beteiligten Stakeholder, die kennen doch die Probleme, weil die leiden unter den Problemen, die es gibt. Die Entwicklungsteams haben mit hoher Komplexität und enger Kopplung und schlechtem Code zu kämpfen. Sie haben mit suboptimaler Technologie zu tun. Die Fachseiten leiden darunter, dass die Time-to-market zu langsam ist. Der Schmerz ist bei den Menschen konkret vorhanden. Und den im Kick-Off herauszukitzeln, dass die auch wirklich das Forum nutzen können, um sich nicht generisch zu beschweren, sondern konkret zu beschweren, dass jemand sagen kann: Hier sind drei Feature Requests. Die habe ich vor sechs Monaten gestellt und die sind immer noch im gleichen Status, in dem JIRA oder wie immer wir das managen. Das ist so ein schönes Thema für ein Kick-Off, wo man dann eben so ein Pack anhat und kann das auch in Interviews weiter verfolgen. Warum ist das so? Wer ist alles beteiligt? Wie sind die Prozesse? Das ist gar nicht das böse Entwicklungsteam, das absichtlich so ein Feature liegen lässt. Und es gibt Gründe, warum das so ist. Im Kick-Off ist mir schon begegnet. Ich kann mich wirklich erinnern, als wäre es gestern gewesen. Bei einem Mandat in der Schweiz, wo es um ein System geht, das seit Jahren, seit wirklich mehr als zehn Jahren in Betrieb ist und das von einem ganz heterogenen Team entwickelt wird. Wir haben uns in Bern getroffen, haben so einen Kick-Off Workshop gemacht. Und dann haben die mir gesagt: Das ist das erste Mal seit ein paar Jahren, dass wir uns persönlich treffen und über diese fachlichen Probleme reden. Und dann habe ich mit dem Kopf geschüttelt und gesagt: Ab und zu mal reden ist schon eine gute Sache. Auch die technische Seite und die fachliche Seite miteinander reden ist eine gute Sache. Sowas geht im Kick-Off. Das ist schon im Kick-Off mir öfter passiert. Das steht übrigens auch in der ATAM Literatur, dass diese ATAM Workshops als Nebeneffekt haben, die Leute reden mal miteinander, und zwar konkret über spezifische Qualitätsanforderungen. Nicht, wir unterhalten uns über das Wetter, sondern wir unterhalten uns konkret darüber, dass das System an dieser einen Stelle ein bestimmtes Leistungsmerkmal erbringen muss. Das ist eine ganz schöne Teamdynamik, die dann auch entsteht.

Anja Kammer: Was meinst du mit Teamdynamik?

Gernot Starke: Wenn so ein Entwicklungsteam dann mal aus erster Hand von den Fachseiten zum Beispiel hört, dass Dinge wichtig sind und oftmals Dinge über zum Beispiel POs gefiltert werden. So ein PO kommt dann und äußert eine Meinung. Das Entwicklungsteam ist irgendwie angenervt von diesem PO, die oder der an der angeblich immer irgendwas runterpriorisiert und das dann mal von der Fachseite im Original zu hören. Das kann schon für Entwicklungsteams ganz interessant sein.

Anja Kammer: Aber nur ab und zu. Die PO Version hat trotzdem eine Daseinsberechtigung.

Gernot Starke: Ja, hat sie auf jeden Fall. Aber im Falle von zum Beispiel Time-to-market Problemen, dass Dinge eben zu langsam funktionieren. In der perfekten Welt würden die Leute kontinuierlich ihre Prozesse anpassen und dafür sorgen, dass Blocker beseitigt werden. Aber Reviews sind ein Zeichen davon, dass die Welt nicht überall perfekt ist und dass es da eben Nachsteuerbedarf gibt.

Anja Kammer: Ich finde generell Reviews gut, die wirklich viele Workshops haben, wo man wirklich alle Personen mitnimmt und man gemeinsam an einem Ergebnis arbeitet, anstatt dass man nach einem Zwischenergebnis eine Präsentation und einen Bericht abliefert. Da finde ich Workshops ganz interessant. Ich glaube, auch dadurch sind die Ergebnisse viel vollständiger. Aber wichtig für mich ist auch das Verständnis und die Aha-Erlebnisse, die dann durch die Teilnehmenden passieren. Und am Ende führt das auch, finde ich, zur besseren Akzeptanz der Ergebnisse, weil sie eben auch an den Ergebnissen mitgearbeitet haben durch diese Workshops.

Gernot Starke: Ja, unbedingt. Und ein Thema, das wir auch noch ansprechen sollten, ist diese Beschwerde, die ich persönlich sehr oft gehört habe. Ich zitiere: „Auf mich hört hier ja keiner“. Zitat Ende. Und ich sitze in dem Interview und ich frage halt: Leute, was ist schlecht? Was ist gut? Was könntest du dir vorstellen, vielleicht zu verbessern? Ich höre ganz oft sehr konkret bezeichnete Probleme: „An dieser Stelle ist irgendwas im Argen“. „An jener Stelle haben wir eine bescheuerte Datenstruktur. Und ich habe sogar einen Vorschlag, wie man es verbessern könnte. Aber auf mich hört halt keiner.“ Und der großartige, leider vor ein paar Jahren schon verstorbene Consultant Guru Jerry Weinberg, der hat das mal sehr treffend auf den Punkt gebracht. Du musst in den ersten fünf Minuten einfach nur sehr genau zuhören und alles mitschreiben, denn die Leute sagen dir genau, wo die Probleme sind. Die Leute, die in den Teams arbeiten, wir sind ja nicht schlauer als die. Die erleben die Probleme, die kennen genau die Stellen im Code, die dubios sind. Und manchmal ist das so, dass wir da 2 + 2 zusammenzählen müssen. Die Beschwerde der einen und die Beschwerde der anderen Person irgendwie matchen und daraus dann vielleicht eine tieferliegende Ursache ableiten. Aber es ist schon häufig so, dass wir dann auch als Reviewer das Sprachrohr werden oder der Meinungsverstärker oder wir die Meinungen oder die Beschwerden, die wir da aus dem Entwicklungsteam hören, vielleicht in etwas andere Worte fassen, aber dann im Management vielleicht auch anders erklären können. Ich finde das immer sehr traurig, dass ein Management den eigenen Mitarbeitenden nicht so sehr glaubt wie uns, als externe Reviewer. Aber das Faktum, dass das so ist, das können wir nicht leugnen. Das ist manchmal so. Und vielleicht hat auch ein Management schlechte Erfahrungen damit gemacht, dass Entwickler versucht haben, da Dinge durchzudrücken, die wirtschaftlich gar nicht sinnvoll waren. Das kann auch sein. Und da können wir als Reviewer schon sehr gut, dadurch, dass wir Außenstehende sind, eine neutrale Position einnehmen. Und dann eben auch zwischen diesen Stakeholderrollen glaube ich ganz gut vermitteln. Und ich bin komplett bei dir. Wenn wir mit Interviews arbeiten haben. Ich frage meine Interviewpartnerin oder -partner immer, ob ich sie zitieren darf.

Anja Kammer: Ja.

Gernot Starke: Das finde ich nur fair. Meistens nicken sie dann und sagen: Na klar. Aber dann kann ich in so einer Abschlusspräsentation beispielsweise auch sagen: So, hier ist halt ein Faktum. Darauf bin ich aufmerksam gemacht worden durch das Interview mit der Frau Kammer. Die Frau Kammer hat mir sehr genau gesagt: „An dieser Stelle ist was im Argen.“ Wir haben das überprüft, wir haben das verifiziert. Wir sind ebenfalls der Meinung und schlagen Folgendes vor. Dann gehen die Credits für das Problem eben an die Person, die das uns mitgeteilt hat. Okay, wir haben es überprüft, wir haben es vielleicht mal gerüttelt, ob es wirklich ein Problem ist, aber das führt, wie du gesagt hast, dann eben auch zu besserer Akzeptanz von solchen Ergebnissen.

Anja Kammer: Ja, bei Interviews frage ich dann auch konkret: Was sind Dinge, die als Ergebnis auf jeden Fall auftauchen sollten? Was sind Dinge, die du in etwa noch loswerden möchtest? Das passiert in so einem Interviewrahmen häufiger, dass sie dann eher aus dem Nähkästchen plaudern und vor allem, wenn man vorher versichert hat, dass dieses Interview nicht dazu da ist, um einen Finger zu zeigen an irgendwelchen Schuldigen. Und dann frage ich aber auch: Welche Dinge laufen denn besonders gut? Das hilft mir, um dann den Fokus immer wieder setzen zu können. Wenn die Person sagt: „Folgende Prozesse funktionieren gut“, dann weiß ich: Okay, da muss ich jetzt in dieser kurzen Zeit nicht so tiefer reingehen, wenn es mir jetzt mehrere Personen schildern.

Gernot Starke: Ja, da bin ich auch komplett bei dir, dass du dieses Spektrum aufspannst von Fragen nach: Was läuft schlecht? Aber definitiv auch Fragen: Was läuft gut? Was gefällt dir besonders gut? Was findest du erhaltenswert? Was sind vielleicht besonders positive Aspekte deiner Implementierung oder deiner Strukturen oder deiner Technologien? Das ergibt total Sinn. Weil in dem Review soll auch durchaus rauskommen: Was sind Dinge, die ihr erhalten solltet, also an denen ihr nicht ändern solltet?

Anja Kammer: Genau. Gut, ich habe noch eine abschließende Frage an dich. Und zwar mir wurde diese Frage einmal gestellt bei einer Ergebnispräsentation von den Auftraggebenden. Und ich würde diese Frage gerne an dich stellen, bevor ich meine Antwort gebe. In welcher Entwicklungsphase lohnt sich ein Architektur-Review?

Gernot Starke: Ich stehe wirklich fundamental auf Feedback. Auf eine Rückmeldung zu dem, was ich gemacht habe, was wir gemacht haben. Und ein Architektur-Review oder ein Review generell ist eine sehr strukturierte, intensive Art, Feedback zu bekommen und zu geben. Und meiner Ansicht nach kann ich in nahezu jeder Phase. Relativ früh, wenn wir anfangen, uns über ein System Gedanken zu machen, könnte ich schon jemanden fragen: Was hältst du von den Gedanken? Wenn wir erste Sprints hinter uns gebracht haben, könnte ich durchaus jemanden fragen und sagen: Spiegel mir das mal, ob wir auf dem richtigen Weg sind. Und wenn Systeme schon lange laufen, wenn sich Dinge eingeschwungen, eingelaufen haben, wo dann vielleicht sehr stark dieses Thema Betriebsblindheit droht, dass wir auch dann erst recht fragen: Wind wir da noch auf einem vernünftigen Weg? Meiner Ansicht nach gibt es eigentlich kaum eine Phase in einer Software oder IT Entwicklung generell, in der nicht rütteln an den Dingen, die wir entschieden haben, ein Mehrwert bieten kann. Natürlich, wenn wir am Anfang erst mal zu zweit eine halbe Stunde Brainstorming gemacht haben, dann können wir nicht direkt ein Review machen. Das lohnt nicht, dann ist das nicht genügend fertig. Aber wenn man so die ersten, sagen wir mal größeren, vielleicht etwas teureren Entscheidungen vorhat, dann mal jemand zu fragen, ist auch eine Art Review. Und dann durchaus auch mal vielleicht gar nicht extern vergeben, aber in die Nachbarabteilung gehen und fragen: Hier, könnt ihr uns mal eine kurze Rückmeldung geben zu dem, was wir da vorhaben? Ist auch ein Review, nur halt im kleineren Kontext, im kleineren Scope und das ergibt für mich Sinn.

Anja Kammer: Ja, machen wir auch tagtäglich mit unseren Code-Reviews.

Gernot Starke: Sollten wir machen. Wir sollten aber auch vielleicht ein paar mehr Dinge als nur Code gucken.

Anja Kammer: Genau. Gut, wie habe ich jetzt diese Frage beantwortet? Das war jetzt ein Sonderfall, weil es ging da um ein soziotechnisches Review, das heißt, es ging sehr viel um Organisationsstrukturen, Prozesse und Kommunikation. Solcher Art von Review lohnt sich, wenn sich Strukturen schon gesetzt haben, Prozesse sich schon bereits gefunden haben und schon mehrmals durchlaufen wurden. Denn dann weiß man erst, wo es knirscht. Prozesse müssen sich erst einschleifen, Strukturen, mit dem muss man erst mal gearbeitet haben, um dann zu sehen, was das Problem daran sein kann und dann vielleicht nachzujustieren. Siehst du das auch so?

Gernot Starke: Das war aber eine sehr, sehr schöne Antwort, Anja. Viel schöner als meine Antwort.

Anja Kammer: Naja, das war ja auch ein anderes Thema.

Gernot Starke: Ja.

Anja Kammer: Gut.

Gernot Starke: Darf ich noch eine Bemerkung loswerden?

Anja Kammer: Ja, gerne.

Gernot Starke: Wir haben das Wort bisher in unserem Gespräch gar nicht verwendet. Das würde ich aber unseren Zuhörerinnen und Zuhörern gerne noch mitgeben. Wir haben gar nicht über Tooling oder Werkzeuge oder konkrete Review Gegenstände gesprochen. Und ich möchte schon gerne noch diesen zentralen Begriff loswerden, wie wir auch bei INNOQ gerne Reviews angehen, nämlich als Breitensuche. Dass wir eben nicht nur so, Entschuldigung dieser Ausdrucksweise, codeverliebt uns jetzt angucken: Sind die Programmierkonstrukte, die Coding Guidelines ordentlich eingehalten? Das ist ein wichtiges Thema. Es ist auch ein wichtiges Thema, auf Kopplungen, Kohäsion oder Kompliziertheit von Code zu gucken, also Schachtelungstiefe oder so anzuschauen. Aber komplett unabhängig davon Themen wie: Wird richtig getestet? Ist unser Deployment in Ordnung? Ist unsere technische Infrastruktur dem Problem angemessen? Sind unsere Datenbanken so gebaut oder werden die so verwendet, wie sie verwendet werden sollen? Ich habe schon Clean Code gesehen mit Entschuldigung, wenn ich schlechte Sprache verwende, aber völlig verkackten Datenstrukturen. Wenn man in den Code guckt, denkt man: Das ist wie Lehrbuch und da guckst du in die Datenbank. Das sehen unsere Zuhörerinnen nicht, aber ich habe praktisch keine Haare mehr. Wegen solcher Dinge. Und was wir unter Breitensuche ganz genau verstehen, haben wir mal in so einen Primer geschrieben. Den verlinken wir bestimmt in den Shownotes.

Anja Kammer: Ja.

Anja Kammer: Das ist schon so eine kleine Broschüre, wo wir mal so ein paar Themen aufgeschlüsselt haben, an denen wir uns ganz gerne langhangeln. Und das kann ich wirklich empfehlen, nicht nur so einen SonarQube anzuwerfen und das ist dann das Review. Nein, das ist nicht das Review. Das ist ein Teilaspekt, das bestimmt auch wichtig ist, aber es ist definitiv nur ein Teilaspekt. Und du hast soziotechnische Systeme, organisatorische Prozesse, Entwicklungsprozesse genannt. Und es gibt wirklich noch eine ganze Reihe mehr Dinge, die sich lohnen anzugucken. Wo wirklich wirtschaftlich Wert drinsteckt, wenn man die ein bisschen verbessert. Außer Code besser machen.

Anja Kammer: Sehr gut. Das ist doch ein super Schlusswort. Dann bedanke ich mich für das Gespräch, Gernot. War sehr schön.

Gernot Starke: Ja, dir auch ganz, ganz vielen Dank.

Anja Kammer: Ciao.