Architekturqualität

Back to episode

Transcript

Sven Johann Hallo und herzlich willkommen zu einer neuen Folge vom INNOQ Podcast. Heute schönerweise mit dem Gernot Starke. Hallo Gernot.

Gernot Starke Hallo. Schön, dass du dich freust. Schön, dass ich dabei sein kann.

Sven Johann Wir wollen heute über Architekturqualität sprechen und über q42. Ja, der von uns allseits geschätzte, vielleicht noch mal ganz kurz, Gernot, dich kennen ja wahrscheinlich alle Leute, 99% der Zuhörer kennen dich bestimmt, aber 1% kennt dich wahrscheinlich auch nicht. Vielleicht willst du noch mal ein paar Worte sagen.

Gernot Starke Ich bin Gernot. Ich habe vor Urzeiten mal Informatik studiert und habe so ein Techniker/Architektur-Herz. Ich finde Softwarearchitektur ist der beste Job, den man so machen kann. Deswegen mache ich das total gerne und auch drum herum im Open Source Umfeld gerne. Und ja, ich glaube, deswegen sitzen wir gerade hier.

Sven Johann Ja, ich muss sagen, eins meiner Lieblingsthemen. Daher freue ich mich besonders. Der von uns allseits geschätzte Len Bass, also gute Bücher geschrieben, der hat mal gesagt: Die funktionalen Anforderungen beschreiben, was das System tun soll und die Qualität beschreibt, wie gut sie dieses tun soll.

Und ja, so zum Einstieg würde ich mal gern diesen Satz kurz auseinandernehmen, bevor wir dann auf quality.arg42.org nochmal zurückkommen.

Gernot Starke Da falle ich dir dann direkt mal ins Wort, weil der gute Len Bass, der meinte bestimmt, funktional beschreibt was, das tun soll und Qualitätsanforderungen beschreiben, wie es das tun soll. Also, dass wir dieses Pärchen Funktionale und Qualitätsanforderungen haben. Die einen sagen, dass was und die anderen das wie. Und ja, damit habe ich schon Bauchschmerzen.

Sven Johann Womit hast du schon Bauchschmerzen?

Gernot Starke Ich habe schon mit dieser Unterscheidung funktionale Anforderungen und Qualitätsanforderungen Bauchschmerzen, denn das Gerät, das nicht funktioniert, also das funktionale Anforderungen nicht erfüllt, der MP3-Player, der keine MP3s abspielt, der hat vielleicht 1000 Stunden Akkulaufzeit, aber niemand wird sagen, das Ding hat gute Qualität, weil er halt seine Funktion nicht erfüllt.

Funktionale Anforderungen sind ganz definitiv ein Teil von Qualitätsanforderungen. Ich weiß, das wird in der Literatur überall unterschieden, aber eigentlich ist die Unterscheidung Blödsinn.

Sven Johann Also du würdest einfach nur sagen Anforderungen.

Gernot Starke Ja, das macht es deutlich einfacher, als dass ich das künstlich gruppieren muss. Und wenn wir über Qualität reden, dann reden wir halt über irgendwelche Eigenschaften, die Systeme haben.

Und ja, das können so funktionale Eigenschaften sein. Das Ding kann halt MP3s abspielen oder Umsatzsteuer berechnen oder kann sonst irgendwie Funktionen erfüllen. Und dann kann man diese Funktionen noch um weitere Dinge anreichern. Aber da kommen wir bestimmt dann gleich nochmal zu.

Sven Johann Du hast ja schon mal angefangen. Daher vielleicht nochmal ganz konkret die Frage, was ist denn Architekturqualität?

Gernot Starke Ja, und auch da, Sven, möchte ich noch mal einen kleinen Schritt zurückgehen und erstmal über kurz die Frage anreißen, was bedeutet überhaupt dieses komische Wort Qualität?

Weil in der Umgangssprache ist das für uns immer etwas Positives. Aber niemand weiß so ganz genau, was das denn bedeutet. Und ich rede oft mit Leuten über Qualität und ich versuche, dass den Leuten ein Beispiel so alltäglicher Dinge klar zu machen. Eben zum Beispiel Kaffee oder Tee oder sonst irgendwie Nahrungsmittel. Aber nehmen wir Kaffee als Beispiel. Wenn wir sagen, Kaffee guter Qualität, was meinen wir denn damit?

Ich habe in der Verwandtschaft Menschen, für die ist Kaffee guter Qualität. Da ist letztlich nur entscheidend, wie viel Koffein ist da drin. Also meine Kinder machen total viel Sport und denen ist wichtig, das muss ordentlich Bums machen, also sprich hoher Koffeingehalt.

Ich habe andere Menschen im Bekanntenkreis, die sagen, Koffeingehalt ist mir völlig egal. Ich möchte, dass das mit Hafermilch aufgegossen ist. Also so ein Hafermilch-Cappuccino. Und ob das viel oder wenig Koffein hat, spielt für die überhaupt keine Rolle. Und die Qualitätsbegriffe dieser beiden, also einerseits Koffeingehalt, andererseits Hafermilch aufgeschäumt, das kriegt man irgendwie überein. Aber erstmal sind deren Vorstellungen von Qualitäte total unterschiedlich.

Und wenn man mit diesem Beispiel so aus der alltäglichen Welt, wenn man damit weitermachen würde, dann würde man auch eine ganze Reihe andere Dinge finden, die halt zum Beispiel dich jetzt vielleicht als Eigenschaft dieses Produktes Kaffee überhaupt gar nicht interessieren und andere Leute legen aber total viel Wert drauf.

Herkunft der Kaffeebohnen? Ist das eine durchgängige Lieferkette? Und, und, und. Und das ist halt ganz schwierig, wenn man diesen Begriff Qualität als solches erstmal schon so diffus verwendet. Also wenn man halt Architekturqualität sagt oder ganz schlimm ist auch der Begriff Codequalität. Der ist halt auch so beliebig interpretierbar, was das eigentlich bedeutet.

Architektur und Code, das hat ja viel miteinander zu tun. Da kann man das vielleicht auch als nächstes Beispiel mal hernehmen. Ist Code Qualität jetzt ausschließlich kurze Methoden und sprechende Bezeichner? Oder könnten wir sowas wie, das wird performant und ressourcenschonend ausgeführt, vielleicht auch als Codequalität bezeichnen? Oder eine Eigenschaft von Code, der das Ding zu gutem, also zu qualitativ hochwertigem Code macht?

Und das insgesamt, also diese, welche Eigenschaften machen überhaupt den Begriff Qualität aus oder die Qualität eines bestimmten Produktes aus, das ist schon das erste Problem, was wir in dem Umfeld überhaupt lösen müssen. Also wenn wir beide über Architekturqualität reden, und jetzt komme ich endlich auf deine Frage zurück, dann müssten wir uns zusammen überlegen, welche Eigenschaften einer Architektur sind denn für uns wichtig?

Und die können wir dann konkreter beschreiben und dann hätten wir beide eine gemeinsame Vorstellung, was Architekturqualität ist.

Sven Johann Wie komme ich denn zu diesen Eigenschaften?

Gernot Starke Ja, ich weiß ja, dass du im Umfeld so reliable systems arbeitest. Ich könnte mir vorstellen, dass für jemanden wie dich oder sogenannte Stakeholder, die vielleicht auch in deinem Umfeld arbeiten oder so ticken wie du, dass für die halt wichtig ist, die Systeme müssen zuverlässig sein.

Also sprich, selten abstürzen. Wenn sie abstürzen, nach extrem kurzer Zeit wieder automatisiert hochfahren. Die sollen Observability-Kriterien genügen. Also ich will den feingranular auf die Finger gucken können. Ich will von den 100 Services, die da laufen, will ich ganz genau sehen, welcher Service gerade wie gesund ist, wie viel Speicher, wie viel Threads der offen hat und keine Ahnung. Also das wäre vielleicht so ein Qualitätsbegriff, so eine Konkretisierung aus der Perspektive: Site Reliability.

Ich habe bestimmt ein paar wichtige Sachen vergessen für dich. Aber es ist ja nur ein Beispiel. So. Jetzt nehmen wir mal. Du hast ja auch eine Tochter. Ich habe auch eine Tochter. Nehmen wir mal die beiden. Wenn wir die fragen, was ist denn Qualität von so einer App, von so einer Applikation für die, dann würden die möglicher, weil die sagen, ja, es muss schick aussehen. Oder muss einfach bedienbar sein. Die Knöpfe müssen groß genug sein für die Finger auf dem Smartphone oder so.

Deren Vorstellungen von Qualität sind möglicherweise eben komplett anders. Und diese Ochsentour durch verschiedene Stakeholder durchzugehen und die zu fragen, Leute, was ist denn bitte für euch, für dieses konkrete System überhaupt eine wichtige Eigenschaft? Die Ochsentour kann ich dir nicht ersparen. Da müssen wir durch die wichtigen Stakeholder durchgehen und die fragen, Leute, was ist für euch überhaupt wichtig?

Und dann können wir für ein bestimmtes System erarbeiten, was denn für dieses System nun wirklich die gewünschte, die notwendige Architekturqualität ist. Pauschal ergibt das wenig Sinn. Muss performant sein, darf nicht abstürzen. Das ist zu unkonkret. Natürlich soll es nicht abstürzen. Aber wie wenig es abstürzen soll, kein einziges Mal in zehn Jahren.

Oder soll, während ich es benutze, nicht abstürzen, aber der Hintergrundservice, das ist mir egal. Das wäre ein großer Unterschied. Und wie gesagt, das müssen wir halt mit Stakeholdern erarbeiten.

Sven Johann Vielleicht ein lustiger Kommentar noch zum Thema, was ist unseren Töchtern wichtig? Also der Adrian Cockroft, früher mal Chief Architect bei Netflix, der meinte, ziemlich viel bei Netflix, was so diese Zuverlässigkeit angeht von den Systemen, kam von der Anforderung, Eltern wollen nicht, dass ihr fünfjähriges oder sechsjähriges Kind irgendeine Zeichentrickserie guckt.

Oder irgendwas guckt und dann fällt es, dann ist es kaputt und dann stoppt Streaming und dann flippen die Kinder aus. Das war sozusagen einer der wichtigen Anforderungen bei Netflix. Zuverlässigkeit, wenn Kinder gucken.

Gernot Starke Ja, nachvollziehbar.

Sven Johann Ja, also ich würde auf jeden Fall, also wie soll ich nicht zustimmen? Also man kann nie, alle Systeme sind unterschiedlich. Man muss halt irgendwie rauskriegen, was für so ein System wichtig ist für die Leute. Also ich finde es ja immer interessant, dieser Spruch: Skalierbarkeit ist die Nummer eins Anforderung, die niemand hat, aber alle umsetzen.

Gernot Starke Der ist gut. Der ist gut.

Sven Johann Also wir bauen ein unheimlich skalierbares System, aber niemand braucht dieses skalierbare System, weil wir sind eine Innendienstanwendung oder so. Stattdessen werden irgendwelche Sachen, also meinetwegen Security-Themen werden komplett übersehen.

Gernot Starke Ja, also Security ist ja auch ein wirklich schönes Beispiel, dass kaum jemand auf der Seite Endanwenderinnen oder Endanwender würde von sich aus möglicherweise sagen, ja, ich möchte gerne IT-Sicherheit mit Nicht-Abstreitbarkeit und Vertraulichkeit und Integrität und so weiter.

Die würden dann möglicherweise, wenn man sie drauf anspricht, dann würden sie sagen, ich möchte nicht, dass meine Daten missbraucht werden. Aber von der Endanwenderenseite bekommt man da vermutlich wenig zu hören. Man bekommt vielleicht irgendwelche Standards zu die Füße geworfen, DSGVO oder so. Aber es gibt auch Anwendungen ohne personenbezogene Daten, wo die Sicherheit, weil es vielleicht nur im Inneren abläuft, nur eine ganz untergeordnete Rolle spielt. Und der schon zitierte Len Bass hat in seinem übrigens großartigen Architecture in Practice Buch so ein schickes Beispiel für mangelnde IT-Sicherheit eines Systems bei der NASA. Die haben in dem Architektur Review bemängelt, euer System, da wird ja nichts verschlüsselt und überhaupt keine Vertraulichkeit und so weiter. Und dann haben die Betreiber dieses Systems nur müde gelächelt und gesagt, ja, brauchen wir nicht. Das System wird sozusagen in einem Riesentresor benutzt und nichts von dem dringt jemals nach außen. Und in dem System selber brauchen wir deswegen überhaupt gar keine Sicherheit umsetzen, weil das machen die vier Meter Betonmauer und Stahltresor außen drum rum schon von allein.

Ich fand das als Beispiel ganz großartig, weil wir eben selbst bei so einem vermeintlichen Basismerkmal wie Sicherheit nicht pauschal sagen können, wir brauchen das unbedingt in der Architektur.

Sven Johann Genau. Ja, also vor allen Dingen, wie viel brauchen wir davon? Da könnte man nachher noch mal ein bisschen genauer drüber reden, weil ich denke mir halt immer so, ja klar wollen wir ein sicheres System, aber ich benutze zum Beispiel 1Password als Passport Manager. Da habe ich halt ganz andere Anforderungen als mein, hier unser Zencastr-Account, ja. Also klar, wir wollen, da will man authentifiziert werden und so. Da gibt’s auch Bezahlinformationen, aber das ist eine ganz andere Hausnummer als so ein Passwortmanager.

Gernot Starke Ja, guter Punkt. Also, ich finde das ja schön, dass wir uns da einig sind, dass wir uns da einig sind, dass wir halt die Stakeholder spezifisch fragen müssen, was denn für eben genau ein System die notwendigen Qualitätsanforderungen sind.

Sven Johann Ja, ich finde, das ist auch immer so ein bisschen tricky. Also die Frage, wie gehe ich denn eigentlich mit meinen Stakeholdern um? Also da gibt es unterschiedliche Antworten, wie man darauf eingehen kann. Also zum Beispiel, was ich mache, ist, ich mache wirklich so banalste Stakeholder-Interviews einzeln. Also ich frage die, also ich versuche erst mal rauszufinden, wer die Stakeholder sind. Und dann frage ich die, was ist euch wichtig, was das System angeht. Und dann sagen die mir irgendwas in Prosa, mit dem man erstmal, wo man vielleicht sagen kann, also so nach dem Motto, es soll sicher sein, das könnten die tatsächlich so fuzzy, ne? Aber halt auch gute Performance für Akzeptanz und so weiter. Also relativ fuzzy, ja.

Aber so sammle ich dann zumindest mal die Anforderungen. Manchmal habe ich auch keinen Zugriff zu Stakeholdern, weil die sind zu wichtig. Die reden nicht mit mir irgendwelche wichtigen CEOs oder so. Dann lasse ich Leute so eine Einschätzung machen, was die glauben, was ihr CEO will. Und dann soll der PO die Sachen mal nach bestem Wissen und besten Wissen und Gewissen priorisieren. Das ist so meine Vorgehensweise. Aber es gibt ja auch noch andere und wie machst du das?

Gernot Starke Ich glaube, dass unsere Vorgehensweisen sich von der Struktur her sehr ähneln. Ich füge einen Zwischenschritt ein. Der Zwischenschritt ist, ich mache mir im Vorfeld mit Unterstützung, zum Beispiel durch eine PO oder zum Beispiel auch durch so eine kleine Gruppe bestehend aus Management, Architektur und so weiter. Also in einer ganz kleinen Runde möchte ich gerne mal so eine Vorabversion wesentlicher, wichtiger Eigenschaften vorbereiten. Das können wir in so einer kleinen Gruppe in der Regel ganz gut machen, weil da halt immer Leute beisitzen, die das Umfeld kennen, die Domäne kennen, die technische Basis kennen, also die sich halt im Umfeld dieses Systems, um das es geht, halt auskennen. Und ich habe sowas mal für einen Flughafenbetreiber gemacht und da habe ich halt mit dem Flughafenmanagement und jemand vom Zoll, weil es halt um Gepäckförderung ging und jemand aus der technischen Umsetzung, da haben wir halt zu viert zusammengesessen und haben halt erstmal gebrainstormt, was sind überhaupt für Eigenschaften wichtig. Und daraus kam dann so eine Art A4-Seite, zwei A4-Seiten, große Sammlungen von Stichpunkten und die habe ich dann als Grundlage für Interviews verwendet. Weil ich bin schon bei dir, ich möchte gerne Interviews führen, also wirklich so total locker nach dem Motto, hast du mal kurz Zeit oder lass uns doch mal zusammen einen Kaffee trinken. Ich will mal mit dir so ein paar Dinge ansprechen und wenn wir das mit einem weißen Blatt Papier machen und ich dann frage, was sind deine Anforderungen, dann sind die Leute halt so

Also ein bisschen im luftleeren Raum unterwegs und wissen sogar nicht so recht. Und dann ist das Risiko groß, dass sie sich vielleicht irgendwas ausdenken. Wenn ich das vorbereitet habe, ja, das kostet mich halt ein bisschen Zeit. Aber wenn ich das vorbereitet habe, dann könnte ich halt auch hergehen und sagen, guck mal, ich habe jetzt mit unserer PO oder sowas habe ich schon mal schon mal überlegt. Hier folgende Vorschläge wollte ich dir mal zeigen. Was hältst du denn davon?

Das ist dann nämlich für die Menschen, mit denen ich so Interviews führe, viel, viel leichter, zu einem schon vorgegebenen Sachverhalt Stellung zu nehmen und zu sagen, das ist ja totaler Blödsinn, brauche ich nicht. Oder, das ist ja viel zu langsam, das muss ja viel schneller sein. Das fällt leichter, als wenn ich den Leuten nur ein leeres Blatt gebe und sage, schreib mal auf, was dir wichtig ist.

Ansonsten bin ich genau, wie du sagst, wir suchen die Stakeholder. Wer ist überhaupt relevant in dem Umfeld? Wessen Meinung ist wichtig? Wessen Anforderungen müssen wir umsetzen? Und dann mit den Leuten kurz reden.

Sven Johann Also da bist du aber auch noch in so einem relativ groben, also du hast gerade gesagt, muss schneller sein oder so, aber es ist noch relativ grob.

Gernot Starke Ich würde das schon versuchen, also wir sprechen gleich noch über Qualitätsszenarien, über der Konkretisierung dieser Anforderungen. Das würde ich schon versuchen, so konkret und greifbar zu machen, dass Leute, mit denen ich spreche, sich wirklich was drunter vorstellen können.

Also nicht zu sagen, hier es geht um Performance oder es geht um Sicherheit, sondern da würde ich dann schon sagen, guck, wir haben halt hier, da hast du halt so einen Knopf, da drückst du 17 mal am Tag drauf und dann soll das System folgendes berechnen und hier soll das denn in einer Sekunde, 10 Sekunden oder 30 Sekunden erfolgen. Such dir was aus.

Und wenn die Leute sagen, na ja, ich drücke da drauf und dann mache ich erst mal sowieso lange Zeit was anderes, dann brauchen die halt keine Sekundereaktionszeit. Und wenn die sagen, boah, ich drücke auf den Knopf aber 300 Mal am Tag und nicht nur zehnmal, wie du sagst, dann weiß ich halt auch oder dann können wir halt gemeinsam erarbeiten, dass vielleicht diese Sekundereaktionszeit wichtig ist. Also wie gesagt, ich würde bei dieser Diskussion mit Stakeholder um diese Qualitätsanforderungen schon versuchen, so konkret wie möglich zu sein. Ja, dein Ansatz hätte halt den Vorteil, dass niemand vorbelastet ist.

Sven Johann Okay, okay. Ja, das mache ich tatsächlich nicht. Also ich breite es so ein bisschen auf, aber es gibt noch keine Szenarien. Also es ist noch relativ grob, so im Sinne von kein Zugriff ohne Zugriffskontrolle und so.

Gernot Starke Also ich komme halt mit so einem Vorschlag und vielleicht ist dieser Vorschlag dann eben macht ein zu enges Raster und die Leute denken dann nicht mehr out of the box. Das ist ein Risiko. Aber ich habe halt beide Varianten versucht und ich hatte das Gefühl, dass es produktiver ist, wenn ich halt mit ein paar Vorschlägen komme. In dem Vorschlag kann ja durchaus drinstehen, habe ich noch irgendwas vergessen. Also gibt es noch sonstiges.

Wir reden ja auch später noch über Qualitätsmodelle. Ich könnte den Leuten ja so eine Liste von möglichen sonstigen Punkten noch geben und sagen, guck, wir haben jetzt gesprochen über Performance und über Sicherheit, aber hier gäbe es noch folgende Optionen, ist irgendwas von denen vielleicht noch für dich wichtig.

Und das Ganze ist halt immer so ein Trade-off. Ich will ja auch keine wochenlange Forschung investieren als Vorbereitung. Ich muss ein bisschen auch auf die Zeit gucken. Deswegen machen wir auch diese Vorbereitung als eine Timebox und da wird man halt nie so final mit allen möglichen Punkten fertig. Genauso ist das auch in einem Stakeholder Interview. Da gibt es dann bestimmt immer noch ein paar Punkte, wo man sagt, ja, das vielleicht einen zweiten Termin machen, wenn dann auch irgendwas wichtiges ist und das dann mal konkretisieren.

Sven Johann Und so eine Stakeholderliste, die ist potenziell sehr lang. Da gibt es viele Leute, die viele Wünsche äußern. Ich denke, das ist kein Problem. Aber wie sollen wir denn priorisieren? Also welche Möglichkeiten gibt es denn da zu priorisieren?

Gernot Starke Du hast das ja auch schon gesagt, für so Priorisierung von Anforderungen gibt es eine Rolle und die Rolle heißt PO. Deswegen tue ich mich sehr schwer damit, dass wir aus der Architektur raus jetzt viel priorisieren, ohne dass da PO beisitzt. Ich stehe da sowieso sehr drauf, dass wir kollaborativ arbeiten, also sehr viel unserer Architekturarbeit gerade in Anforderungsklärung mit PO gemeinsam machen.

Also wirklich sich gegenüber sitzen und gemeinsam drüber reden. So würde ich das mit Priorisierung bei den Qualitätsthemen auch halten wollen.

Sven Johann Ja, also tatsächlich mein Vorgehen ist, ich breite die Sachen auf und dann soll der PO priorisieren. Und wenn Sachen, also so nach dem Motto, was brauchen wir unbedingt?

Also wenn wir das nicht machen, dann können wir nicht live gehen. Das muss auf jeden Fall passieren. Wenn das nicht passiert, völlig sinnlos. Also das muss passieren. Und dann wird es ja so, dann geht es irgendwie dahin, wenn wir das überhaupt nicht anpacken, bis wir live gehen, dann ist eigentlich auch erstmal nicht schlimm. Und dann soll die PO, der PO soll so ein bisschen priorisieren und also für mich funktioniert das ja tatsächlich relativ gut. Aber zum Beispiel in Schulungen oder in der Literatur wird ja auch gerne gesagt Ja, wir machen so ein wir machen so ein Workshop. Wir machen so ein Anforderungs-Priorisierungs-Workshop. Wie also wo alle Stakeholder zusammensitzen und wir dann priorisieren. Ich hab da so mein Problem mit. Aber ich weiß nicht, wie sieht es bei dir aus?

Gernot Starke Ich habe das gemacht und ich habe das, also ich habe auch diese großen Anforderungs-Priorisierungs-Workshops gemacht und ich habe es im kleinen Umfeld gemacht. Ich persönlich, ich will das jetzt gar nicht auf eine bestimmte Person Zahl festmachen, aber ich weiß nach drei Minuten in einem Workshop ist der zu groß oder ist die Größe passend? Und ich erinnere mich an so Workshops mit 35 Personen und das ist zu groß. Das dauert alles so lange, das ist so schwerfällig und ich werde dann ungeduldig und das macht keinen Spaß. Ich erinnere mich an Workshops mit fünf, sechs Leuten, wo wir Anforderungen aufgearbeitet und priorisiert haben, die super gelaufen sind.

Also ich will jetzt diese Workshop-Idee nicht pauschal ablehnen. Ich würde aber schon gucken, was ist das für ein Umfeld? Kennen sich die Leute? Können die sich gut leiden? Und haben die eine gute Teamstimmung, dann kann man auch mit einem größeren Team gemeinsam priorisieren. Das würde ich von der Situation abhängig machen.

Und zum Priorisieren, also im besten Falle, das bedeutet für mich dann, dass ich die wenigste Arbeit damit habe, im besten Falle kann ich einen PO oder einer PO, die es priorisieren, überlassen. Ich würde gerne POs darin unterstützen, in denen ich ihnen sage, wie schwer schätze ich was ein.

Also wenn jetzt jemand mit einer Wahnsinns-Performance-Anforderung kommt und ich brauche halt in 50 Millisekunden folgendes Ergebnis. Na dann klingt das vielleicht für jemand dem PO-Umfeld erstmal, boah 50 Millisekunden, das fährt krass schnell und wie soll das denn gehen?

Ja, aber wenn das Ergebnisse sind, die bei mir im Cash irgendwo rumschwirren und die ich in 5 Millisekunden habe, dann könnte ich das ja einem PO mitgeben und sagen, übrigens, die 50 Millisekunden, an der Stelle sind die übrigens einfach und die 800 Millisekunden an der anderen Stelle, die sind übrigens sau schwer, weil da ist Mechanik involviert und da muss so ein Motor anlaufen und der läuft nicht in den Millisekunden an und also da würde ich die POs schon gerne aus der Architektursicht raus unterstützen, weil das diese Priorisierung ein bisschen leichter fällt. Aber wie gesagt, das macht man eher am besten zusammen und dann geht das auch. Dann kriegt man das gut hin.

Sven Johann Also ich muss sagen, da habe ich auch hier von Len Bass geklaut, dass die Anforderungen sozusagen immer also eingefärbt werden, weil also der Len Bass meint ja auch, ja, also es gibt, es gibt Sachen, die sind einfach. Da kann man sagen, dass irgendwie das sehr, also geringer Aufwand, mittlerer Aufwand, extrem hoher Aufwand. Und dann, wenn man so ein, also wenn wir so eine Priorität haben, wo man vielleicht auch sieht, ja, der drittwichtigste Item, der ist aber tief rot und da steht ein dickes H mit, wegen hoch, hoher An, also viel Aufwand, dann weiß so ein PO, eigentlich auch bescheid finde ich finde ich auch eine gute Möglichkeit.

Gernot Starke Also ich halte das für, ja, muss man machen, ist aber nicht so beliebig schwierig. Also gehen wir mal davon aus, dass die Stakeholder sich alle halbwegs leiden können und wir ein ordentliches Arbeitsumfeld haben, dann ist das gut machbar. Dann kommen wir da mit einer PO auch zu einem vernünftigen Ergebnis.

Sven Johann Vielleicht noch eine abschließende Frage dazu. Es gibt ja auch Leute, die Wünsche haben, also meinetwegen so ein Chief Digital Officer oder wie auch immer, also ganz wichtige Personen, die in aller Regel gar nicht mit uns, also mit dir vielleicht, aber mit so normalsterblichen wie mir, die reden niemals mit mir. Die fragen sich vor allen Dingen, die sagen halt, ist also dieses eine System, ich interessiere mich nicht für Einzelsysteme, an denen ihr da arbeitet, sondern hier, das ist mein Wunsch für die gesamte Anwendungslandschaft und das ist mir so und so wichtig. Wie geht man mit wichtigen Personen um, wo der Zugriff schwer ist?

Gernot Starke Auch diese wichtigen Personen sollten ja in der Lage sein, die Anforderungen so konkret zu formulieren, dass sich die dass wir die oder ein Entwicklungsteam die angemessen verstehen kann, dass die angemessen konkret sind. Wenn das so superdehnbare Anforderungen sind, dann kann ich die vielleicht auch trivial erfüllen, weil sie halt so dehnbar ist, dass ich es auf jeden Fall erfülle. Wenn das konkrete Dinge sind, also muss das Corporate CI erfüllen, also muss halt bestimmte Farben oder Layout-Richtlinien folgen.

Das ist ja schon fast eine Randbedingung. Die müssen wir halt kennen. Aber auch da bin ich mir sicher, dass POs sowas durchaus wissen.

Sven Johann Also so meine Erfahrung ist, dass tatsächlich so die bei unseren Kunden jetzt die POs wirklich ganz gut wissen, weil die Sachen, die wichtig sind, die wiederholt so eine wichtige Person, natürlich gebetsmühlenartig, das kann man so sehen.

Ja, jetzt würde ich. Wir haben es ja eben schon gesagt. Manche Sachen sind ein bisschen. Also manche, die meisten Anforderungen sind so ein bisschen unspezifisch, wenig testbar. Jetzt haben wir unsere Stakeholder gefragt. Die Sachen sind priorisiert. Jetzt müssen wir die Anforderungen konkretisieren. Wie macht man sowas?

Gernot Starke Darf ich ein bisschen an deiner Reihenfolge drehen?

Sven Johann Ja, dreh mal.

Gernot Starke Wir haben die schon konkretisiert, bevor wir die priorisiert haben. So generische Begriffe wie Performance können wir nicht priorisieren. Das heißt, von der Reihenfolge her, also wir haben das Wortszenarien schon angesprochen, wir haben das aber noch nicht erklärt, aber diese Szenarien dienen dazu, Qualitätsanforderungen zu konkretisieren.

Wenn ich die konkret habe, dann kann ich sie priorisieren. Über Prios haben wir schon gesprochen, also greifen wir jetzt diese Szenarien auf.

Sven Johann Ja, ich wollte also nur gerade, um nochmal zurückzukommen. Also ich meinte gar nicht unbedingt im Sinne von wir haben nur Performance oder Security als Ziel. Sondern die sind noch nicht so wirklich testbar. Also so jetzt gerade bei so einem Kunden von mir, da haben wir also Zugriffskontrolle muss da sein. Oder intelligente Benutzerführung. Oder, man soll, also tatsächlich eine Anforderung, man will aus der Badewanne samstags Mittag einen neuen Tarif anlegen. Damit kann man schon mal so ein bisschen was anfangen, aber so richtig, das meinte ich mit, die sind schon einigermaßen konkret, aber nicht konkret genug oder findest du sowas auch noch nicht konkret genug, was ich gerade genannt habe.

Gernot Starke Also, dass ich einen neuen Tarif anlegen möchte mit weniger als fünf Klicks und das muss für unbedarfte neue User mit kurzer Einarbeitung erfolgen. Kann ich erstmal als Anforderungen nachvollziehen. Da könnte man vielleicht noch eine Iterationsschleife drüber legen und das noch besser konkretisieren, aber erstmal kann ich mir da was drunter…

Schritt zurück, wenn ich weiß, was ein Tarif ist und wenn ich die Domäne so ein Stück weit kenne, dann könnte ich mir da schon was darunter vorstellen. Da bin ich dann wieder bei dir, dass wir jetzt halt überlegen könnten, wie kann ich denn sowas validieren oder wie kann ich sowas dann irgendwie testbar machen. Meine Wunschvorstellung ist, dass ich bei Qualitätsanforderungen grundsätzlich weiß, oder dass die so konkret sind, dass ich eine Möglichkeit habe, das auch zu überprüfen. Manche sind ganz einfach zu überprüfen. Performance kann ich messen. Also ich kann messen, wie lange dauert das, nachdem ich da auf diesen Knopf gedrückt habe, bis die Antwort da ist. Das kann ich sogar automatisiert machen. Es gibt andere Anforderungen, die kann ich vielleicht relativ konkret beschreiben, aber das Überprüfen ist aufwendig.

Von 100 neuen Usern der App sollen 98 innerhalb von 10 Sekunden die Registrierung geschafft haben. Ja, theoretisch kann ich das prüfen. Ich kann mir 100 Leute greifen. Ich kann denen Geld dafür bezahlen, dass sie die App verwenden. Ich kann dann messen, wie lange brauchen sie zum Registrieren. Es fällt aber schon, also normalerweise kriege ich nicht das Geld, um 100 Leute zu bezahlen, um diese Anforderungen zu überprüfen. Also würde ich da zwischen theoretischer und praktischer Messbarkeit unterscheiden. Die 98 von 100 Usern sollen in der Lage sein, halte ich erstmal für okay als Anforderungen, weil mir das Indiz gibt, in welche Richtung soll das gehen.

Und auch da kann man mit Sicherheit, mit UX-Expertise noch eine Ebene weiter reingehen und sagen, ja, was beeinflusst denn die Dauer, die jemand braucht zum Registrieren, die vertikale, horizontale Menge an Mausbewegungen, die ich machen muss, die Anzahl Klicks etc. Das kann man schon noch weiter verfeinern, um es dann vielleicht wirklich automatisiert messbar zu machen. Aber irgendwo ist dann auch eine Grenze, wo wir sagen, da lohnt der Aufwand nicht mehr. Ich habe verstanden, das Management will das 98 von 100 völlig unbedarften Usern die Registrierung problemlos hinbekommen. Also auf Deutsch, ich will eine idiotensichere Registrierung haben. Manchmal sind mir solche Formulierungen gut genug, weil auch ein Entwicklungsteam weiß, so etwas haben wir schon mal gebaut, wir nehmen das Konzept der Registrierung von der Anwendung xy und dann ist das schon gut genug. Aber wie gesagt, andere hätte ich gerne automatisiert testbar, die vielleicht besonders wichtig sind oder so diese Verfügbarkeitsgeschichten, Korrektheitsgeschichten, muss auf sechs Nachkommastellen korrekt sein, soll auch unter hoher Netzlast noch zuverlässig mit geringer Latenz oder keine Ahnung, sowas kann ich ziemlich gut formulieren als Anforderung, sowas kann ich auch ziemlich gut testen oder validieren. Ja, das macht Aufwand, aber das kriege ich hin. Und damit kann ich dann auch zeigen, guck, Management, wir haben die gewünschten Eigenschaften erfüllt. Punkt. Also das, was ich mit einem Testfall, wo ich zeigen kann, ich habe die funktionale Anforderung korrekt umgesetzt, kann ich das für eine ganze Reihe Qualitätseigenschaften auch machen.

Sven Johann Also man kann sich auch, manche Metriken ist so meine Erfahrung, die entwickeln sich auch erst im Laufe der Zeit. Also man kann sich irgendwie, zum Beispiel bei dem, also dieses Onboarding anmelden, da hatten wir mal einen wirklich sehr interessanten Kunden gehabt und da wurde gemessen in Beschwerden, im Callcenter, wo Leute anrufen und sagen, das funktioniert nicht. Und dann haben wir gesagt, okay, es gibt so eine Baseline und wir wollen einfach, irgendeiner beschwert sich immer, aber wir wollen halt auf X Prozent runter.

Gernot Starke Ja, da bin ich total bei dir und das geht ja genau in die Richtung. Wir wollen Architekturarbeit oder Entwicklungsarbeit generell iterativ inkrementell machen und dann können wir auch mal mit einer groben Qualitätsanforderung starten und die im Laufe der Zeit verfeinern, weil uns vielleicht erst im Laufe der Zeit eine plausible und automatisierbare Metrik einfällt.

Gernot Starke Ich schiebe da jetzt mal kurz zwischen, das packen wir in die Show Notes. Da gibt es ja auch ein Buch Evolutionary Architectures von Rebecca Parson, Neil Ford, ist auch dabei, die ja auch vorschlagen, dass man halt so automatisierte Qualitätsüberprüfung baut. Und da fallen mir auch nicht am Tag eins direkt für jedes Qualitätsmerkmal irgendwie eine automatisierbare Prüfung ein. Aber sowas kann man halt ganz gut eben iterativ verfeinern.

Sven Johann Ich denke, ein weiterer Punkt, was so iterative Verfeinerung angeht, ist auch die Feststellung, ob meine Anforderung sinnvoll ist. Wenn ich jetzt über Verfügbarkeit oder Performance nachdenke, also bei Performance ist es normalerweise relativ einfach, weil da gibt es so, da können wir auch in die Show Notes packen, da gibt es so grundsätzliche Messungen, wann sind Nutzer eigentlich glücklich mit Performance. Also da gibt es einfach, da kann man messen. Das ist vorgegeben, man muss ein bisschen aufpassen.

Da gibt es Zahlen, weil wenn ich irgendwie zum Beispiel der Deutschen Bahn Verbindungen suche, also diese Suche ist natürlich sensitiver, zeit-sensitiver, als ich buche dann letzten Endes. Das kann ruhig ein bisschen länger dauern, aber grundsätzlich gibt es da so, gibt es eigentlich genügend Erfahrungswerte.

Bei Verfügbarkeit ist das natürlich wiederum was anderes und da it depends. Man kann sich immer viele wünschen, aber tatsächlich ist ja die Frage, sind die Kunden oder die Nutzer der Software damit zufrieden? Jetzt zum Beispiel bei Performance und Zuverlässigkeit.

Und wenn ich jetzt irgendwie die Zuverlässigkeitsanforderungen habe, 99,95 Prozent Verfügbarkeit, also keine Ahnung. Ich glaube, das sind 50 Minuten Ausfall pro Quartal oder so. Was ist eigentlich, wenn ich 60 Minuten Ausfall habe oder oder 90 Minuten Ausfall pro Quartal? Ist das dann? Also dann habe ich die Anforderungen offensichtlich gerissen. Aber ist das jetzt? Also muss ich handeln oder muss ich nicht handeln? Sowas kriegt man eigentlich auch nur incrementell raus.

Gernot Starke Das kann gut sein, dass du dafür auch mehr Wissen über den Kontext des Systems brauchst, also dass du den fachlichen Kontext, in welchem Umfeld wird das eingesetzt, gehen jetzt durch die zehn Minuten mehr Ausfall, geht damit vielleicht dem Unternehmen Ertrag verloren, muss das Unternehmen vielleicht Strafzahlungen leisten oder ähnliches. Dann würde ich natürlich handeln müssen bei einer Verletzung. Und es mag andere Anforderungen geben, die sind halt nice to have, aber wenn ich sie verletze um ein paar Prozent ist auch nicht so dramatisch.

Also das können wir auch nicht pauschalieren. Das ist dieses, wir werden im Laufe der Entwicklung als Team und auch in der Architektur hoffentlich schlauer und lernen halt dazu, welche dieser Anforderungen ich auf gar keinen Fall reißen darf. So kurz vor Weihnachten bin ich auch damit zufrieden, wenn mein Brief einen Tag später ankommt, ob der kommt überhaupt an.

Normalerweise über das Jahr erwarte ich das am nächsten Tag da, aber da gibt es halt Sonder-Situationen. Sowas gibt es in IT-Systemen ja auch. Da gibt es auch Situationen, da muss das unbedingt so und so sein, aber es gibt andere Tage. Am Wochenende sitze ich auf dem Sofa, bediene das System, während ich Netflix gucke, da kann das auch eine Sekunde länger dauern. Und auch sowas lernt man halt oft erst im Lauf der Arbeit.

Sven Johann Das hört sich jetzt erstmal nach Arbeit an. Also wir müssen mit Stakeholdern reden und so weiter und so weiter. Und da müssen wir priorisieren und wir müssen das beobachten.

Gernot Starke Ich weiß ja, dass du das auch so siehst, aber Anforderungsklärung ist Arbeit. Also Requirements Engineering, Requirements Management oder Business Analyse nennst, wie du willst. Das ist sogar viel Arbeit. Das ist wichtige und schwere Arbeit. Ich hab da so ein bisschen Fable für, weil das ist halt die Grundlage jeglicher Architekturarbeit. Ich kann mir ja Wolken Kuckucksheime ausdenken, wenn ich nicht weiß, was meine Anwenderinnen, Anwender, Stakeholder wirklich brauchen. Na, dann ist ja alles, was ich an Architektur entwickle, komplett auf Treibsand gebaut.

Sven Johann Ich wollte nur sagen, wo die Frage herkommt. Es gibt ja manche Systeme, also es sind neue Systeme. Wir wissen, das ist ein neues System, das wir bauen. Wir haben wenig Erfahrung damit. Und dann gibt es, also früherer Arbeitgeber von mir, wir hatten immer dieselben Systeme gebaut. Also wir hatten, war irgendwie, war implizit immer klar, was zu machen ist. Daher kommt so die Frage, also wann stecke ich wie viel Zeit da rein? Ist es immer, also machen wir das immer so, also ist das immer… Wir machen das immer explizit, also Fangfrage, also ich denke schon, oder gibt’s…

Gernot Starke Ja, wir machen das immer explizit. Also immer ist ja ein schwieriges Wort in der Softwareentwicklung, weil das immer eigentlich ja nicht gibt, weil es kommt ja immer darauf an auf die Situation, aber Qualitätsanforderungen explizit machen, das geht schon sehr in Richtung, das möchte ich gerne haben. Ich möchte schon gerne wissen, bitte, was sind die Leistungsmerkmale, die ich erfüllen muss. Oder habe ich halt vielleicht beliebig Freiheit, das darf beliebig lange dauern, bis irgendwie die Maschine fertig gerechnet hat. Das wüsste ich schon gerne, weil das macht oft wirklich Unterschiede aus, wie viel Entwicklungsarbeit, wie viel Optimierungsarbeit investiere ich, wie viel Mühe gebe ich mir irgendwo. Also da bin ich schon der Meinung, da sollten wir ein bisschen Arbeit investieren. Und da wir iterativ arbeiten, kann das durchaus mal eine Timebox von einer halben Stunde sein, um rauszukriegen, so was ist denn vielleicht überhaupt an kritischen Merkmalen da und im nächsten Sprint machen wir nochmal eine halbe Stunde. Das ist machbar. Und wenn wir medizinische Geräte bauen, wo es um Menschenleben geht, dann werden wir von Anfang an richtig ordentlich Zeit investieren, um die relevanten Safety-Anforderungen gründlich aufzuarbeiten.

Sven Johann Das eine ist halt die Dinge, die wir tun. Aber ich denke auch, die Dinge, die wir nicht tun oder noch nicht tun, die finde ich eigentlich auch ganz wichtig bei dem explizit machen, weil ich denke, so die ganzen, also alle Qualitätsmerkmale, ja, also ob das jetzt Performance Usability, Security und so weiter, das sind ja alles wünschenswerte Eigenschaften. Ich kann nicht alles machen. Wir haben priorisiert. Und rein durch die Priorisierung ist auch schon klar, was tun wir nicht? Dann ist auch keiner enttäuscht nachher, weil es vorher klar war. Gut. Vielleicht noch ein Punkt. Du hast ja schon gesagt, dass so die funktionalen Anforderungen, also bevor wir zu vielleicht zu q42 kommen oder zwei Punkte, die Funktionalen Anforderungen die treiben ja auch. Ich sag mal, die klassische Wartbarkeitsanforderungen, die wir eigentlich nie so explizit formulieren, also die Software soll wartbar sein, okay, was bedeutet das? Wir brauchen halt den richtigen Schnitt, ja, also wir brauchen lose Kopplungen und hohe Kohäsion. Wie geht man eigentlich damit um? Also mit diesem Wischiwaschi, mit dieser Wischiwaschi Aussage, ja, das System soll natürlich wartbar sein.

Gernot Starke Wenn ich ein System baue, das ich in eine Firmware gieße und nie wieder updaten kann, da muss ich nicht besonders viel dran ändern können. Wenn ich ein System in den App Store schiebe und jetzt schon weiß, dass ich einmal alle sechs Wochen irgendein Update liefern muss, damit meine Klientel irgendwie zufrieden ist und mich nicht mit schlechten Bewertungen abstrafen, da muss ich da grundsätzlich anders vorgehen. Und auch bei Wartbarkeit kann ich mir durchaus überlegen, ich muss in der Lage sein, weil das System halt so und so beschaffen ist, weil es vielleicht eine App im App Store sein wird oder eine App-Komponente hat, die im App Store läuft und die wir halt für unsere Klientel aktualisieren müssen. Das kann ich doch explizit formulieren. Da kann ich doch sagen, hör mal, liebes Entwicklungsteam, ihr müsst in der Lage sein, eine funktionale Ergänzung, einen neuen Use-Case, meinetwegen in einem Spiel eine neue Character-Klasse oder einen neuen Tarif oder mehr was auch immer innerhalb von so einem Update-Zyklus im App Store umzusetzen. Und wenn ich zumindest schon mal grob weiß, ah ja, wir haben sechs Wochen Update-Zyklus, warum auch immer wir den vielleicht haben, das kann ja im Management vorgegeben sein.

Dann kann ich mir als Entwicklungsteam auch überlegen, so was hat das für mich für Konsequenzen? Na, jetzt könnte ich diese Änderungen lokalisieren und sagen, okay, alle Änderungen, die diese App betreffen, will ich in ganz wenigen Stellen im System nur umsetzen müssen. Die soll immer garantiert ohne eine große Datenmigration und so weiter. Das kann ich dann auch wieder runterbrechen in, ja, zumindest mal feingranulare Details, mit denen ich als Entwicklungsteam dann auch was anfangen kann.

Sven Johann Das wären dann sozusagen zukünftige Änderungsszenarien beschreiben.

Gernot Starke Genau, ich kann mir dann überlegen, was soll denn Wartbarkeit für uns konkret bedeuten? Also rein theoretisch, das ist alles Source Code, da kann irgendjemand verstehen und da kann ich den auch ändern. Aber die Frage ist ja, in welcher Zeit will ich den ändern oder an wie vielen Stellen kann ich mehr leisten zu ändern oder muss das ein Entwicklungsteam ändern können oder sollen das auch komplett fremde Menschen ändern können? Was ja bedeuten würde, ich muss es vielleicht besser dokumentieren oder da irgendwie eine Schnittstelle offenlegen oder was auch immer.

Sven Johann Okay, jetzt aber wirklich letzter Punkt, bevor wir zu q42 kommen. Ganz kurz noch mal zu der Methodik. Wir haben ja irgendwie gesagt, wir können Stakeholderwünsche aufnehmen. Die müssen wir übersetzen, konkretisieren. Dann werden die priorisiert.

Dann können wir vielleicht nochmal genauer werden, indem wir die Szenarien oder wir werden genauer, weil wir die Szenarien beschreiben. Aber was dann? Also jetzt habe ich die und wie gehe ich dann vor?

Gernot Starke Im Grunde traue ich mich kaum, das laut zu sagen, weil das ist so banal einfach. Nehmen wir mal an, du hast jetzt da deine oder wir haben unsere Hausaufgaben gemacht, wir haben mit Stakeholdern geredet, wir haben jetzt so ein Dutzend wichtige Qualitätseigenschaften des Systems formuliert. Also wie wir das jetzt handwerklich machen, lassen wir mal aus und vor eben mit Szenarien, also messbar, entscheidbar, konkret. Wir haben jetzt ein Dutzend Punkte. Die stehen jetzt in so einer Liste oder Tabelle. Priorisiert. Da steht das Wichtigste oben und das weniger Wichtige steht halt weiter unten. Es gibt außer diesem Dutzend noch ein paar mehr. Die haben wir für uns später irgendwann aufgehoben. Aber wir haben jetzt ein Dutzend. Das ist ja eine überschaubare Menge. So, jetzt können wir doch hergehen und sagen, wir fangen bei eins an. Punkt eins. Dieser Use Case in fünf Millisekunden muss folgendes passieren. Na ja, nur fünf Millisekunden für Zeit. Dann kann ich mir doch mit dem Entwicklungsteam gemeinsam überlegen, bitte, was müssen wir dafür tun?

Ja, wir müssen sicherstellen, dass diese Zahlen immer vorberechnet im Cash liegen. Ja, wir müssen, wenn sie aus dem Cash Invalidation rausgeflogen werden, sofort für Nachlieferung sorgen. Keine Ahnung, da kann ich mir Punkte überlegen. Und ich nenne das gerne Quality Driven Architecture, also die Qualitätsanforderung treibt die Architekturentscheidung. Und der Weg dahin ist wirklich so simpel, wenn wir diese Qualitätsanforderung haben, dann können wir uns mit dem Team oder mit einigen aus dem Team hinsetzen und können Schritt für Schritt dieser Anforderungen durchgehen und konstruktiv überlegen, was machen wir bitte, um das zu erreichen. Welche Maßnahmen, welche Ansätze, welche Technologien, welche Pattern. Also was fällt uns ein, wie wir das schaffen können?

Ich habe das wirklich dutzendmal mit Leuten gemacht, mit verschiedenen Teams gemacht, in ganz verschiedenen Umfällen gemacht. Das funktioniert immer. Entwicklungsteams, das sind schlaue Menschen mit Erfahrung. Die haben immer eine Idee, wie kriege ich das hin.

Wie könnten wir das hinkriegen? Das mag viel Arbeit sein. Aber nochmal, wir reden über wichtige Qualitätseigenschaften, wichtige Qualitätsanforderungen. Da sind ja auch POs oder Auftraggebende durchaus bereit, ein bisschen was zu investieren. Wenn wir sagen, wir wollen da Millisekunden Antwortzeit, dann müssen wir halt das große Cloud-Paket kaufen oder die bessere Hardware kaufen oder die gute Grafikkarte oder was auch immer. Aber auf Basis der konkreten Anforderungen können wir uns auch konkrete Maßnahmenvorschläge überlegen, um diese konkrete Anforderung zu erfüllen. Also der Weg ist verhältnismäßig einfach und ist auch methodisch total einfach, ist leichtgewichtig. Du brauchst keine Tools dafür. Du brauchst eben nur diese Vorarbeit der konkreten Qualitätsanforderungen.

Sven Johann Die, ich sag mal, meine Frageziel hat so ein bisschen auch drauf abgezielt. Ja, ich muss mir irgendwelche Maßnahmen, Patterns und so weiter überlegen. Aber weil ich wieder und wieder auf so Len Bass zurückzukommen, aber auch viele andere, Frank Buschmann und so weiter, die haben ja im Grunde genommen so Maßnahmen, Kataloge angefertigt. Also ich denke immer so konkret, klar, ich kann mir immer einen Haufen Sachen selbst ausdenken, aber ich gucke doch mal gerne, was schlägt denn, was schlägt man denn so vor an Maßnahmenkatalogen? Und dann kann ich immer noch, vielleicht habe ich irgendwas vergessen oder ich kriege eine neue Idee. Also ich schaue schon immer ganz gern nach, was Leute so an Katalogen anbieten.

Gernot Starke Ich habe ja schon immer gewusst, dass du ein schlauer Kopf bist, Sven. Vielleicht mal nachgucken statt alles immer selber zu machen. Das halte ich schon für einen sauguten Plan. Ich habe nur die Befürchtung, dass so aktuell dieser Len Bass und seine Kollegen mit dem Software Architecture in Practice so ziemlich das einzige Buch sind, die so konkrete Maßnahmen, Vorschläge für Qualitätsanforderungen haben, dass ich da was ableiten kann, was direkt umsetzbar ist. Also ich wertschätze die Frank-Buschmann- und Co Pattern-Literatur sehr. Die stehen bei mir im Schrank. Ich gucke da wirklich ab und zu mal rein, weil ich das für wirklich guten Content halte.

Aber so ein Pattern, das ist oft schon noch von der konkreten Umsetzung oder von der konkreten Qualitätsanforderung so ein bisschen weit weg. Mag ein Schritt in die richtige Richtung sein, ja, bin ich bei. Aber, ja, da du mich nach Büchern gefragt hast, Lan Bass Software Architecture & Practice, das werden wir verlinken. Das ist aus meiner Sicht die aktuell beste Sammlung solcher Ansätze.

Mit dem kleinen Disclaimer, dass die vom Software Engineering Institute amerikanische sozusagen Hochfinanz, also die reden halt nie über Geld, weil das ist halt immer in rauen Mengen da. Das heißt, für geldbeschränkte Projekte mögen deren Vorschläge vielleicht nicht unbedingt immer das Gelbe vom Ei sein. Um auf paar Ideen zu kommen, ist das auf jeden Fall großartig.

Sven Johann Also ich finde jetzt aus dem Reliability Engineering, da gibt es tatsächlich noch, finde ich, gute Literatur. Also die Google Bücher, die haben auch ein paar Paper dazu mit, wo sie Maßnahmen, können wir auch alles da noch in die Show Notes packen, weil ich, Susan Fowler hat sowas wie Production Ready Microservices geschrieben, als sie bei Uber war. Mike Nygaard mit Release It, der hat ja auch einen Haufen interessanter Patterns beschrieben, die man einfach so kopieren kann.

Gernot Starke Ja, ich befürchte fast, dass wir in diesem Podcast nicht mehr so richtig viel zu q42 kommen. Vielleicht sprechen wir das gleich noch mal an. Der Plan ist, dass wir auch in diesem Open Source Qualitätsmodell zumindest mal ansatzweise so Maßnahmen sammeln oder zumindest auf Maßnahmen verlinken, die irgendwo anders publiziert sind.

Sven Johann Genau, dann sag doch einfach, also ich denke, wir haben noch ein paar Minütchen, haben wir ja noch. Können noch mal kurz drauf zurückkommen. Genau, wir schaffen es, wir halten uns kurz.

Gernot Starke Ja, das wäre ja gemein, wenn wir es ansprechen, aber dann doch nicht ansprechen. Ich gehe einen halben Schritt zurück. Wir haben Qualitätsanforderungen besprochen. Qualitätsanforderung ist ja letztlich erstmal eine Menge von Eigenschaften. Ich nenne das gerne Dimension 1. Ich zähle die Eigenschaften auf. Ich brauche beim Kaffee den Milchgehalt, den Koffeingehalt, die Temperatur, die Zubereitung, die Herkunft der Bohnen usw. Dimension 1. Dimension 2 ist die Ausprägung. Was genau brauche ich? Herkunftsland muss Peru sein, Koffeingehalt 180 Milligramm pro 300 Milliliter Kaffee oder so ähnlich. Das ist die Ausprägung. Dann habe ich konkret eine Ansage, was muss ich liefern? Das kann ich für Software auch machen. Und dann gibt es diese sogenannten Qualitätsmodelle, zum Beispiel den, ich glaube, relativ bekannten ISO-Standard 25010, seit über 20 Jahren verbreitet. Diese Qualitätsmodelle zählen Eigenschaften auf und bringen dann Definitionen mit. Aber die geben dir keine Ausprägung vor, die machen keine Vorschläge. Wie viel Performance könntest du denn brauchen oder wie kann ich Performance überhaupt konkreter beschreiben? Die zählen einfach nur Begriffe auf. Und ich habe diesen ISO-Standard ganz oft in Projekte mitgenommen, weil das ist halt eine vernünftige Aufzählung relevanter Eigenschaften für Software-Systeme. Von daher ist das schon mal gut. Aber dass die konkrete Ausprägung, wie du das auch gedacht hast, Validierbarkeit, Testbarkeit in den Standards komplett fehlt, das ist schade. Und das werfe ich denen so ein ganz klein bisschen vor. Also es gibt natürlich auch Standards, die den nächsten Schritt noch gehen. Die sind aber wahnsinnig teuer und kein Mensch kennt die. Oder kaum ein Mensch kennt die. Und deswegen habe ich vor einem Jahr ungefähr dieses arc42 Qualitätsmodell mal angefangen.

Weil ich gedacht habe, in der Softwareentwicklung ist ganz viel Open Source. Open Source finde ich super. Lasst uns doch so ein Qualitätsmodell Open Source machen, was einerseits Begriffe aufzählt. Übrigens haben wir viel mehr als ISO, also in deren Bindung sind wir besser als ISO. Und lasst uns dazu aber diese zweite Dimension, also diese Ausprägung anhand von Beispielen zeigen.

Und genau das ist eben q42 im Moment. Das zeigt halt, es gibt folgende, über 100 Eigenschaften, mögliche Eigenschaften für Software-Systeme oder für Architekturen. Und es gibt hier dazu Beispiele, wie könnte man die konkreter beschreiben. Und das eben frei verfügbar, Open Source. Man kann es von GitHub klonen, forken. Es gibt ein bisschen an erläuternder Doku dazu. Also das ist praktisch einsetzbar.

Sven Johann Also ich muss sagen, ich bin ja seit jeher war ich Fan von ISO 2510 im Sinne von, das ist ein guter Startpunkt, um mit Leuten zu sprechen. Aber ich habe auch Kunden gehabt, die haben sich dagegen gewehrt, diese Begriffe zu nutzen, weil die irgendwie zu klobig sind. Keine Ahnung, Unabstreitbarkeit oder so, das fanden die irgendwie doof. Muss halt so kompliziert sein.

Gernot Starke Das ist auch, es ist auch, es ist wirklich zäh. Die Begriffsdefinitionen vom ISO sind frei verfügbar, also dafür muss man den Standard nicht kaufen. Man muss den überhaupt nicht kaufen. Also alles Relevante ist frei verfügbar davon. Aber wenn ihr Lust habt, liebe Zuhörerinnen und Zuhörer, dann lest euch das mal durch vom ISO-Standard und es ist wirklich. Also da gibt es viele Sätze, die musste ich einfach dreimal lesen und ich habe es immer noch nicht verstanden. Das ist, ich sage mal an vielen Stellen, einfach zu abstrakt und zu weit weg von den Bedürfnissen der Praxis. Das macht die Begriffsammlung erstmal nicht schlechter. Also die Begriffe, die da drin stehen, die sind schon relevant. Aber die Definitionen sind, ich weiß nicht auf welchem Stern die gewohnt haben, als sie es gemacht haben, aber weit weg.

Sven Johann Also ich denke auch, dass quality.arc42, das auf jeden Fall eine niedrigere Einstiegshürde ist und ja, also ich habe ja auch vor, Beispiele beizusteuern, weil ich denke, die Beispiele sind schon. Also sind die das Wichtigste?

Gernot Starke Für mich ist das absolut das Wichtigste. Das sind die, die ich, also ich bespreche mit meinen Kundinnen oder Kunden, worum geht es überhaupt. Und dann sage ich, ich gebe mir mal eine halbe Stunde Zeit. Ich sammle jetzt von diesem q42, suche mal ein paar Beispiele für euch raus. Und das habe ich wirklich in einer Viertelstunde gemacht. So, und dann haben wir so einen Startpunkt auf der Basis, können wir diskutieren. Und das ist so viel schneller, als ich das vorher konnte, also bevor ich dieses q42 gemacht habe. Also das ist wirklich, ich will mich da gar nicht selber loben. Die Beispiele, ganz, ganz viele Contributed Beispiele, Beispiele, die ich verfälscht habe aus realen Kundensituationen raus, also anonymisiert habe. Also da ist ganz viel in der Gehirnschmalz anderer Menschen reingeflossen, aber die sind wirklich, wirklich die ergebenden positiven Unterschiede in der Projektarbeit, weil ich einfach sofort loslegen kann. Und mit Beispielen können auch Fach-Stakeholder was anfangen, also die nichts von IT verstehen. Die lesen das und können das Beispiel auf ihre eigene Situation transformieren.

Sven Johann Ja, also du nutzt, also wenn du jetzt quality.arc42 nutzt, dann, ich versuche gerade, also sagen wir mal, die Methodik nachzuvollziehen. Also du hast ja so ein paar Kern Properties definiert. Die kommen schon mal so raus im Gespräch mit den Stakeholdern. Und basierend darauf sagst du, okay, ich guck jetzt nochmal nach, was wir da für Beispiele zu diesen Properties haben. Wie: Ich suche nochmal gerade, was so die Beispielproperties sind. Reliable, flexible, efficient, usable, safe, secure, operable und suitable.

Gernot Starke Ja, das sind die, das sind so, also mein Anspruch war, dass wir halt so einen Einstieg haben mit High-Level-Begriffen, die praktisch alle Leute, wo praktisch alle Leute so eine intuitive Bedeutung für haben. Und reliable, flexible, da kannst du halt, glaube ich, viele Leute fragen, die sagen, ja, ja, kann ich mir was drunter vorstellen? Und dann ist das ja, also wenn sich jemand was drunter vorstellen kann, dann können wir ja an der Stelle schon mal weiter diskutieren. Dann könnten wir halt überlegen, lass uns ein paar Beispiele für deine Bedeutung von flexible nehmen. Was meinst du denn mit flexible? Solltest du Laufzeit flexibel oder bezüglich des Hyperscalers flexibel oder bezüglich der Datenstrukturen flexibel? Sag was du meinst. Und dann kann man sich da halt so lang hangeln.

Und das ist auch eine Idee, die habe ich natürlich von den anderen Qualitätsmodellen entlehnt, nämlich die hierarchische Aufbereitung dieser Qualitätseigenschaften. Na, ISO hat so eine zweistufige Hierarchie. Na, das habe ich in diesem q42, habe ich mich von der Hierarchie verabschiedet, aber ich habe trotzdem zwei Stufen, also habe so High-Level Properties, habe ich die genannt, also so eine Sammlung von so acht, neun Oberbegriffen. Und dann kann man diese hundert anderen Eigenschaften, die kann man dann zum Teil sogar mehreren dieser Oberbegriffe zuordnen.

Sven Johann Ja, genau. Ich denke, das ist auch noch mal so ein Punkt, der bei ISO manchmal ein bisschen problematisch ist. Man sagt, ihr gehört jetzt da rein oder da rein und hat mal 27 Jahre Diskussion über ein Thema, was eigentlich völlig uninteressant ist, ob es jetzt in die eine oder in die andere Kategorie gehört.

Gernot Starke Also da das Open Source ist, können wir da glaube ich problemlos Werbung für machen. Einfach mal angucken. Auf der Webseite sieht man halt einen sehr leichten Beispiel, also eine Übersicht vorhandener Beispiele. Das sind mittlerweile auch irgendwie gute 80, fast 90. Da einfach mal in ein, zwei Beispiele reingucken. Vielleicht auch in vier, fünf Beispiele reingucken und ich glaube, dass Leute dann schon eine Vorstellung kriegen, wie der Hase läuft. Und wie gesagt, ich habe da positive Rückmeldungen zu bekommen oder Leute haben gesagt, gefällt mir gut, hier hast du noch zwei Beispiele. Also das hat sich da schon ein ganzes Stück weiter entwickelt.

Sven Johann Also ich will auf jeden Fall auch beisteuern. Es wird in diesem Jahr passieren. In diesem Jahrzehnt wird es passieren.

Gernot Starke Ja Sven, das hast du jetzt öffentlich gesagt, aber du hast nicht gesagt, welches Jahr wir gerade schreiben.

Sven Johann Genau, genau. Okay. Ja, auf jeden Fall vielen Dank für deine Zeit zum Thema Qualität. Wir verlinken alles. Du hast auch ein paar Vorträge dazu, oder? Also gerade alles, was wir auch rund um Kaffee besprochen haben, das kann man sich noch mal in einem schönen Vortrag angucken. Das können wir alles verlinken.

Gernot Starke Ich bin damit auch gerne auf Meetups. Kommen auch gerne zu Ihnen oder euch liebe Zuhörerinnen und Zuhörer auf das Meetup eurer Wahl, wo wir dann auch über dieses Thema gerne mal face to face diskutieren können. Ich habe da Spaß dran. Ich glaube, dass das für die Branche schon wichtig ist, dass wir da bisschen weiterkommen. Domain Driven haben wir gut verstanden, das hat sich schon ein bisschen verbreitet für den Komponentenschnitt und jetzt müssen wir noch Quality Driven ein bisschen verbreitern und dann wird es schon ein bisschen besser.

Sven Johann Ja, das ist wirklich gut gesprochen zum Abschluss. Ich habe nichts hinzuzufügen.

Gernot Starke Danke Sven und vielen Dank fürs Zuhören.

Sven Johann Dann euch Zuhörern auch noch vielen Dank und bis zum nächsten Mal. Tschüss.

Gernot Starke Tschüss!