20 Jahre arc42

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

Sven Johann: Hallo und herzlich willkommen zu einer neuen Folge vom INNOQ Podcast. Heute habe ich Gernot Starke zu Gast.

Gernot Starke: Hallo Sven.

Sven Johann: Wir sprechen heute über 20 Jahre arc42 , also ganz schön lange. Ich kenne fast kein Leben ohne arc42.

Gernot Starke: Ja, als 19-Jähriger. Spaß.

Sven Johann: Genau, und wir wollen im Grunde genommen darüber reden, wie kam es dazu? Wie hat es sich über die Jahre entwickelt? Was habt ihr gelernt, was ist noch mal reingeflossen, was ist Neues passiert und vielleicht noch mal so einen kleinen Ausblick, was wir vielleicht noch erwarten können. Falls man überhaupt noch etwas erwarten kann nach 20 Jahren, aber ich glaube schon. Genau, legen wir doch direkt mal los. Wie kam es eigentlich dazu?

Gernot Starke: Ja, gute Frage. Ich hatte ein Projekt bei den Finanzbehörden, die hatten damals so eine Dependance in Bonn. Es war ein ganz spannendes Projekt, relativ viele Leute, also eher 50. Heute würde man es kleiner schneiden, aber es war halt so. Und ich hatte zum damaligen Zeitpunkt schon so ein arc42hitekturbuch geschrieben. Das ist dem Projektleiter in die Hände gefallen, der hat gesagt: „Du kannst doch schreiben, du machst jetzt hier Doku. Architektur-Doku für 50 Leute, die wie wild entwickeln.” Hatte ich noch nie so in dieser Form gemacht. Ja, und habe mich mit einem guten Freund, Peter Hruschka, darüber unterhalten. Der sagte auch: „Ich bin gerade in so einer ganz ähnlichen Situation, aber im Embedded-Umfeld.” Ja, dann haben wir halt so ein bisschen gegrübelt und überlegt, wie könnte man das machen, haben gesagt, ja, wichtig ist halt, dass wir uns auf den Inhalt der Arbeit konzentrieren können, weniger mit den Leuten über die Form reden müssen. Und hatten dann so die Idee, eigentlich müssen wir so eine Art Kleiderschrank machen, wo die Leute dann immer nur noch diese Architektursachen einräumen können. Also dieser Template-Gedanke. Und Peter…

Sven Johann: Also im Sinne von: Beim Kleiderschrank weiß ich immer, wo ich die Socken und die Unterhose reinmache.

Gernot Starke: Genau.

Sven Johann: Und bei Architektur weiß ich immer, wenn ich eine Entscheidung treffe, kommt es dahin und wenn ich über Stakeholder rede oder strukturell…

Gernot Starke: Oder wenn du über eine Struktur redest, dann kommst du an das Ziel. Und Peter kannte aus seiner Historie als Requirements Engineer das wohl leere Template, das schon viel länger existiert als eine Schablone, eine sehr große Schablone, ein sehr großer Schrank für Requirements. Und dann haben wir gesagt, auch, so diese Idee als Vorlage, aber spezifisch ausgeprägt für Architektur. So und ein großer Treiber war dann, dass wir aus der Embedded-Sicht, Embedded Realtime Safety Critical-Sicht von Peter und meiner Sicht, Finanzamt-Software, klassische, sagen wir mal, eher einfache strukturierte Informationssysteme, halt gesagt haben, gibt es denn da Gemeinsamkeiten? Und erstaunlicherweise haben wir ganz, ganz viele Gemeinsamkeiten gefunden. Ja, und dann gesagt, oh, das ist ja super, weil dann können wir beide den gleichen Schrank benutzen für unsere Projekte. Und wir waren uns beide von Anfang an auch einig, wir wollten das verschenken, also wir wollten das nicht als irgendwas Proprietäres haben, sondern es war schon immer so die Idee, so ähnlich auch wie bei wohl Lehrer. Lass uns da ein paar Artikel zu schreiben oder so irgendwas machen, so, dass man das halt frei benutzen kann, weil dann benutzen es vermutlich mehr Leute.

Sven Johann: Ja.

Gernot Starke: Ja, und das ist bei unseren beiden Projekten, also sozusagen bei den Piloten, ganz gut angekommen. Ja, also es gab für mein Projekt zumindest auch keine Alternative, also die mussten es halt machen. Aber zumindest waren viele Projekt-Stakeholder dann doch ganz zufrieden damit. So ist es halt entstanden.

Sven Johann: Ja. Wenn du sagst, die waren zufrieden, also die Entwickler und Architekten, die dabei waren, die haben das gerne angenommen?

Gernot Starke: Gerne? Darüber möchte ich gar nicht spekulieren. Ja, es war klar, die Notwendigkeit war auch im Projektauftrag formuliert, wir müssen halt was dokumentieren. Ja, das soll halt eine sehr, sehr langlebige Software sein, die möglicherweise über viele Jahre oder sogar Jahrzehnte im Einsatz ist und dann ist klar, auch weiterentwickelt wird. Also die Notwendigkeit für Doku, die wurde gar nicht angezweifelt. Ja, und wie gesagt, ob die Leute das gerne gemacht haben, weiß ich nicht, aber sie haben es halt gemacht. Und sie brauchten sich ja nicht Gedanken machen, wo packe ich jetzt die Socken hin und wo die Handtücher, sondern das war halt, da gab es halt Handreichungen für sie und sie konnten mich ja auch fragen. Also letztlich habe ich ja nicht nur das Template vorgegeben, sondern auch versucht, den Leuten die Hand zu reichen, so, so oder so könntest du das machen. Ja, das ging dann natürlich über diese reine Fächerstruktur ein bisschen raus. So, wie kriege ich denn jetzt so eine Bausteinsicht beschrieben, also so einen Grundriss, so ein Komponentenmodell und wie kann ich jetzt vielleicht so Details eines Subsystems und eines anderen irgendwie zusammenbringen?

Also deswegen, im Rückblick, sage ich, dass es allein schon deswegen ganz gut funktioniert hat, weil Peter und ich und auch die Projekte gesagt haben, wir machen das weiter. Wenn es komplett Grütze gewesen wäre, dann hätten wir es irgendwann aufgehört und uns was anderes gesucht.

Sven Johann: Ja, klar.

Gernot Starke: Es gab bei den Behörden ein Teilprojekt, die haben versucht mit einem sehr, sehr formalen Dokumentationsansatz, mit so einem Metamodell vom Software Engineering Institute zu arbeiten, wo man erstmal die Viewpoints definiert, bevor man dann zu konkreten Sichten kommt und das hat nie einer verstanden, da ist nie irgendwas draus geworden. Die sind alle dann am Ende zu unserem Ansatz übergelaufen und haben gesagt, daneben ist viel einfacher, wir machen das auch so, statt diesen eher theoretisierten Ansatz, wo man über Metamodellebenen erst noch mal quasi seine eigenen Grundlagen modelliert, also seinen Schrank metamodelliert, bevor man dann zum eigentlichen Schrankinhalt kommt.

Sven Johann: Da muss man wahrscheinlich beim Software Engineering Institute auch noch mal eine Zertifizierung beantragen und eine Schulung, ne?

Gernot Starke: Nicht weiter drüber reden.

Sven Johann: Ich bin ja Fan vom SEI, aber ein paar Probleme. Das hat aber gerade was bei mir getriggert und zwar, du sagst, ihr habt euch an wohl Lehre orientiert und…

Gernot Starke: An der Idee, genau. Hat die halt fest definierte, nennen wir so Schrankfächer, die eine ziemlich gut beschriebene Semantik haben, also wo klar ist, was bedeutet das? Ja, so, dass ich irgendwo nachgucken kann, was meint er jetzt damit, wenn er so ein komisches Wort sagt, wie Laufzeitsicht oder Verteilungssicht oder so.

Sven Johann: Ja. Und gab es damals andere Dokumentationsmöglichkeiten, außer die vom Software Engineering Institute? Ich denke so konkret, also ich hatte auch mal mit Unis zu tun vor einer Weile und dann war eigentlich in so einem Forschungskontext und dann haben die mich auch gefragt, ob ich mal so eine Gastvorlesung Remote halten kann, war eine amerikanische Uni. Und dann habe ich im Grunde genommen über arc42 geredet. Oder ja, im Grunde genommen, also sagen wir mal, ich habe über arc42 geredet und dann meinten die, warum ich eigentlich arc42 nehme und zum Beispiel nicht SDD, statt SDD, nie gehört, also Software Development Design Methods oder irgendwie sowas, ne? Und ja, nee, das stimmt, ich bin ja im Grunde genommen mit, ich sag mal, mit Gernot Starke beziehungsweise Simon Brown, also Simon Brown hat auch ein Buch geschrieben, Englisch, war sehr bekannt im englischsprachigen Raum und in dem Buch, ja, hat es kein Template gemacht, aber er hat in seinem Buch ähnliche Sachen diskutiert wie ihr. Ja, ich meine, ich bin eigentlich nur mit den beiden groß geworden und ich kenne gar nichts anderes, deswegen hat mich das so ein bisschen kalt erwischt, habe ich noch nie gehört, sorry. Aber gab es da was in der Vergangenheit?

Gernot Starke: Also meine ersten Schritte waren im Grunde so auf der grünen Wiese, da habe ich auch, denk zurück, vor 20 Jahren war Google anders als heute Google ist, da war das nämlich in die Bibliothek gehen und gucken so, findest du was im Stichwortverzeichnis. Nicht ganz so schlimm, aber nahezu so und das heißt, wir haben schon im Grunde befreit von eben aus der wohl Lehrer angefangen. Über die Zeit habe ich halt mitbekommen, dass es gerade im Defense Sektor, also amerikanisches Militär, britisches, australisches, die schon so ihre Vorstellungen hatten, wie zu dokumentieren ist. Ohne dass ich da jetzt allzu weit reingeguckt habe, schon das erste Draufgucken hat, habe ich immer gedacht, boah, ist das aufwendig. Und aufwendig im Sinne von formal aufwendig und habe das dann für mich ad acta gelegt, weil ich eher so diesen pragmatischen Gedanken verfolgen wollte, wir müssen es halt irgendwie im Projekt unter Zeitdruck schaffen und wir sind eben nicht per Contract verpflichtet, diese Formalia einzuhalten.

Und stand heute bin ich tatsächlich auch überfragt, ob es jetzt gerade im militärischen Bereich, ob sich das eher vereinfacht hat oder ob es da immer noch so viele Formalia gibt. Es gab mal von Hewlett Packard und von IBM so Versuche auch so Dokumentationstemplate zu produzieren. Bei IBM kostet es Geld, das ist eingeschlafen und die Leute von Hewlett Packard haben es auch irgendwann von ihren Webseiten genommen, weil es einfach, glaube ich, nicht genügend Akzeptanz gefunden hat.

Sven Johann: Ja. Ja, also mir ist auch nichts in meinem ganzen Leben über den Weg gelaufen. Also entweder sagen die Leute, es gibt halt nur arc42 oder man kann. Also, ich hätte jetzt fast gesagt, man kann natürlich Simon Brown, kann man sich angucken, aber interessanterweise, ich stehe mir jetzt nichts an, wahrscheinlich muss man dann auf Englisch sagen, damit sich wehren kann. Aber persönlich hat er mir auch mal gesagt, dass viele seiner Kunden halt einfach sagen, wir nutzen arc42 , aber C4. Ja, also weil er hat halt nichts anderes, er hat halt C4, aber der ganze Kram drumherum ist eigentlich nur im Buch beschrieben und es gibt keinen Template-Mechanismus.

Gernot Starke: Und wenn das ist jetzt natürlich so ein im Nachhinein dazu gedichteter Witz, aber C4 ist halt schon Namensbestandteil von arc42. Simon weiß das auch, er macht ja auf seiner Webseite sogar nicht Werbung, aber er weist halt darauf hin, dass das gut zusammenpasst. Und meiner Ansicht nach passt es wirklich ausgezeichnet gut zusammen, weil wir in arc42 halt keine syntaktische Notation für Dinge vorgeben, sondern nur sagen, es gibt ein Schrankfach für die Außenschnittstelle Kontext, es gibt ein Schrankfach für den Grundriss, es gibt ein Schrankfach für Deployment. So und jetzt guck bei Simon, was kannst du in seiner C4 Notation alles machen und das passt eins zu eins in diese Fächer. Und ich habe selber häufiger erlebt, dass mir Leute gesagt haben, ja, wir machen arc42, aber wir haben keine Lust auf UML, aber wir wollen halt auch so ein bisschen Tool-Unterstützung, also nehmen wir den Structurizer von Simon und das passt super zusammen.

Sven Johann: Ja. Sagst du so, ne, dass eins zu eins so ist, aber ich habe so konkret zwei Dinge im Hinterkopf, was ich bei Simon finde und arc42 nicht finde. Was ich aber trotzdem mache, also man muss dazu sagen, arc42 ist ein Template, man kann es erweitern, also die Gernot Starke Polizei kommt nicht vorbei, wenn jetzt da irgendwie…

Gernot Starke: Gut, dass du das sagst, vielleicht sollte ich mal vorbeikommen.

Sven Johann: Genau. Er hat zum Beispiel ein Data-Kapitel und noch etwas, das finde ich ziemlich interessant: ein Kapitel, das sich Points of Interest nennt. Man hat dieses große System, das man gut beschreiben kann, aber Points of Interest sind die fünf, sechs, sieben Stellen, wie auch immer. Es ist wie auf einer Insel, wo man nicht die ganze Insel absuchen muss, sondern es gibt interessante Stellen für Touristen. Was ich damit sagen will, ist, dass es über die Zeit wahrscheinlich viele Ideen gab, was da reinkommen soll oder was nicht. Dass du da vielleicht mal.

Gernot Starke: Das gehört zu den wenigen Punkten, bei denen wir Kommentare von Nutzern erhalten haben, die Vorschläge gemacht haben, wie: ‘Nehmt doch noch Folgendes auf, das ist für mich wichtig.’ Eine Sache, die wir mehrmals gehört haben, ist: ‘UI, UX, Design, Screenflows und so weiter, nehmt das doch auf, das ist für mich wichtig.’ UI/UX ist total relevant für Systeme. Architekturell habe ich immer gesagt, du kannst das prima in die Konzepte packen, also in unsere querschnittlichen Konzepte, und wenn es wirklich Flows sind, bieten die sich für die Laufzeitsicht an. Dafür muss man ein bisschen ‘Out of the Box’ denken, was eine Laufzeitsicht und was ein Konzept ist, aber die Infos kriege ich gut untergebracht. Peter und ich hatten immer die Vorstellung, dass wir die Anzahl der Schrankfächer minimal halten wollen. Wir haben gesagt: ‘Du nimmst es dir dann sowieso, packst nur ein, zwei dazu, aber wir wollen jetzt nicht den Fehler machen, den Lehrer gemacht hat, irgendwann auf Kapitel zu kommen, sodass sich kein Mensch mehr merken kann, was Kapitel und ist.’ Wir haben gesagt, wir beschränken uns auf dieses Dutzend und erweitern es, wenn du es brauchst, aber wir machen das nicht als Template-Provider. Die zweite Idee, die uns Leute gegeben oder gefragt haben, war: ‘Was mache ich mit Daten? Wo kommt mein Datenmodell hin? Ich habe eine bestehende Datenbank, wo kriege ich die Struktur unter?’ Unsere Argumentation war und ist immer noch, dass Daten diesen Bausteincharakter besitzen. Das heißt, Daten, Datenstrukturen, Tabellenstrukturen passen für mich einerseits gut in die Bausteinsicht, weil ich das möchte, und wenn das Basisinformationen sind, die im System sowieso jeder braucht, dann ist es ohnehin ein Querschnittsthema. Das heißt, auch bei diesem Hinweis, ‘Was mache ich jetzt mit Daten?’, tue ich mich schwer damit, eine neue Sicht zu erstellen. Ausnahmen bestätigen die Regel. Ich habe für Versicherer arbeiten dürfen, da drehte sich alles um Daten. Die Daten müssen Jahre aufbewahrt werden: Verträge, Policen, irgendwann muss das.

Genau, da habe ich mich breitschlagen lassen und gesagt: ‘Ich sehe es ein, das Erste, was ihr immer tut, ist über Daten, Datenstrukturen, DB-Tabellen reden. Dann gebt ihnen doch eine eigene Sicht, wenn das so wichtig ist.’ Wir müssen halt gucken, dass es konsistent mit Bausteinen und so weiter ist, aber das könnte ich mir noch als ein Add-on-Kapitel vorstellen, das man so macht. Dann hast du Points of Interest gesagt.

Sven Johann: Vielleicht noch eine ganz kurze Frage zu den Daten. Wenn man sich euer Template ansieht – ich gehe davon aus, dass alle, die hier reinhören, sowieso schon arc42 nutzen, wir haben jetzt keine Intro gemacht – ihr habt ja nicht nur Kapitel, wo ihr sagt ‘Kapitel Entscheidungen’ oder so. Habe ich das richtig gesagt?

Gernot Starke: Ich glaube neun, aber egal.

Sven Johann: Es sind nicht irgendwelche Kapitel, sondern ihr schreibt ja auch, in diesem Kapitel sind Hinweise, was hier reinkommt. Ich habe querschnittliche Themen, das ist dies und das, und hier haben wir die Bausteinsicht, oder es könnte natürlich auch in der Beschreibung stehen. Ich habe da früher mal reingeguckt, aber jetzt nicht mehr. Ich frage mich, steht bei Bausteinsicht auch, dass man potenziell über Daten spricht?

Gernot Starke: Lass mich einen Schritt zurückgehen: Was bringen Leute, was fragen uns Leute, was kriegen wir für Kommentare? Wir haben über die Zeit – und ich habe es nachgeguckt, bevor wir gesprochen haben, es war um , da gab es arc42 schon gute zehn Jahre – gemerkt:

Vom Einsatz her und auch von den Fragen, die Leute stellen, sind noch viele Dinge unklar. Wir müssten mehr erklären, wie etwas geht. Wir wollten aber das Template minimal halten. Das war der Moment, wo wir gesagt haben: ‘Lass uns doch mal Ratschläge sammeln, die wir Leuten geben, wie du das einsetzen kannst.’ Wenn du ein großes Datenmodell hast und so weiter, dann setzt du arc42 wie folgt ein oder bildest das in arc42 wie folgt ab. Um die Zeit sind zwei Websites entstanden, also zwei Subdomänen. Die eine heißt FAQ, wo wir die Fragen der Leute versuchen zu beantworten. Und die zweite heißt Docs, weil wir sagen: ‘Wir nehmen uns jetzt ein Kapitel, eine Sektion von arc42, und dann geben wir dazu ein Dutzend Tipps, wie du die einsetzen könntest.’ Hast du perversen Zeitdruck, dann lass den schon mal direkt weg. Bist du aufgefordert, besonders gründlich zu arbeiten, dann schlagen wir vor, mach das so und so.

Sven Johann: Kurze Zwischenfrage: Seit wann gibt es die? Seit 2016 oder was?

Gernot Starke: 2016, meine ich, haben wir die Docs und die FAQ gemacht.

Sven Johann: Ja.

Gernot Starke: Das war auch die Zeit, wo wir auf Markdown-Doku und AsciiDoc umgestiegen sind. Mit Markdown kann man so etwas viel einfacher handhaben, als früher, als es nichts außer Word und aus Word exportiertes HTML gab – das ist Grütze. Diese Doc-Seite, wir schauen ein bisschen auf Page Views, ist die mit Abstand am höchsten frequentierte Subdomäne, die wir haben. Das ist noch mehr angestiegen, seit wir auf diesen Docs pro Sektion Beispiele geben. Wir sagen: ‘Hier ist eine Anwendung, und in der Anwendung, zum Beispiel Gesundheitskarte oder Nachverkontrolle, haben wir die Bausteinsicht so und so aufgebaut.’ Dann kannst du da reinklicken und bekommst Bilder, also wirklich Exemplare, wo du sagen kannst: ‘Das gefällt mir gut, das passt zu meinem System.’ Dann tausche ich das Bild, was ich hier im Beispiel sehe, durch mein eigenes aus, und dann habe ich das.

Sven Johann: Okay.

Gernot Starke: Gut gemacht. Das ist wirklich gut angekommen.

Sven Johann: Ja. Ich hatte gerade einen kleinen Schockmoment, wo ich dachte, auf der Doc-Seite war ich noch nie. Aber jetzt, wo du sagst, ihr habt diese Beispiele, klar, war ich schon Mal dort. Das glaube ich gerne.

Gernot Starke: Wir hatten immer ein bisschen damit zu kämpfen, dass wir in Docs und FAQ eine Menge Redundanz haben, dass sie nicht gut genug quervernetzt sind, weil wir das alles manuell gepflegt haben. Vielleicht fragst du mich ja noch nach einem Ausblick, aber das ist ein Ausblick, dass wir ernsthaft vorhaben, mit LLM-Unterstützung die Vernetzung zu verbessern.

Sven Johann: Machen wir später.

Gernot Starke: Ja, machen wir später, wenn wir es schaffen. Aber das ist wirklich etwas, wo es noch Bedarf gibt, dass die Suche besser ist.

Sven Johann: Ich muss sagen, ich glaube das gerne, denn in unseren Schulungen, hier in der ISAQB Foundation Level Schulung – um eine kleine Werbung zu machen, es gibt natürlich auch noch die Schulung ‘Architektur dokumentieren’, die man buchen kann – gibt es viele Leute, die sehr interessiert sind, aber die denken: ‘Okay, ich habe hier diese Kapitel, aber eigentlich weiß ich nicht so genau, was ich da reinschreibe.’ Und dann fällt mir auch bei Kunden auf, dass ich manchmal Kapitel sehe, wo ich denke: ‘Oh, hier wurde zwanghaft etwas reingeschrieben.’ Eigentlich in 100% der Fälle, wo man denkt: ‘Hier wurde zwanghaft etwas reingeschrieben, weil ich stehe vor dieser Wand, da steht Kapitel, ich sage jetzt mal, Stakeholder oder Randbedingungen oder so, und was soll ich hier noch reinschreiben?’ Dann wird irgendetwas reingeschrieben. Und dann verweise ich auch immer auf Beispieldokumentationen. Ihr habt ja auch unterschiedliche Systeme, nicht nur du und Peter, sondern ein Kollege aus Aachen.

Gernot Starke: Michael Simons.

Sven Johann: Michael hat mitgeschrieben.

Gernot Starke: Wir haben jetzt einen Beitrag von einem Seniorarchitekten von Zeiss bekommen, der ein Buchkapitel zur Architektur beigesteuert hat. Stefan Zörner hat auch etwas, er hat eine coole Schach-Engine in dem.

Gernot Starke: Du willst auf dieses ‘arc42 by Example’-Buch hinaus.

Sven Johann: Genau.

Gernot Starke: Es gibt eine Jubiläumsedition, die es auch noch ein paar Monate lang kostenfrei gibt.

Sven Johann: Okay.

Gernot Starke: Es sind wirklich 350 Seiten mit – ich glaube sieben oder acht, schlag mich nicht – konkreten, real existierenden Softwaresystemen, die mit arc42 dokumentiert sind. Mehr oder weniger ausführlich, sodass, behaupte ich, jeder etwas findet, das zur eigenen Anwendungssituation passt.

Sven Johann: Ich muss auch noch mal unbedingt die Stefan Zörner Schach-Engine empfehlen, weil ich finde, er hat auch ein Buch geschrieben – es gibt ja nicht nur dieses Beispiel auf der Webseite – das sehr einfach zu benutzen ist. Ein Buch geschrieben, das ist eigentlich super, um das so zu nutzen.

Gernot Starke: Die Schach-Engine ist finde ich auch ein toller Anwendungsfall, weil es über dieses – Entschuldigung – langweilige Business-System einfach ein Stück hinausgeht. Stefan hat ein gutes Händchen, Dinge transparent und nachvollziehbar zu vermitteln und zu formulieren.

Sven Johann: Da kann sich auch jeder etwas darunter vorstellen. Wenn ich jetzt ein Banking-System oder so als Beispiel hätte, müsste man sich in die Domänen einarbeiten. Aber wenn man eine Domäne wie eine Schach-Engine oder berühmte Open-Source-Projekte hat, dann ist das natürlich einfacher.

Gernot Starke: Berühmte Open-Source-Projekte haben wir noch nicht dokumentiert. Also wir nicht. Bei anderen weiß ich das nicht.

Sven Johann: Die Ideen gibt es natürlich auch zum Üben. Zum Beispiel: ‘Nimm dir Git und dokumentiere die Git-Architektur im arc42-Stil, nicht wie man es nutzt.’ Okay. Genau, ich gucke gerade auf die Uhr. Vielleicht noch, bevor wir auf die Zukunft blicken: Gibt es Veränderungen? Was sind die großen Veränderungen über die Zeit am Template?

Gernot Starke: Es ist noch eine nicht beantwortete Frage von dir auf meinem Stack. Du hast nämlich nach den Points of Interest gefragt.

Sven Johann: Ach, ja, stimmt.

Gernot Starke: Points of Interest. Das letzte, was in meiner Erinnerung bei arc42 dazugekommen ist, ist diese sogenannte Lösungsstrategie. Über den Namen könnte man streiten. Das ist der vierte Teil, wenn man von oben guckt, von dem wir glauben, dass er immer noch für alle Stakeholder interessant ist. Nachdem ich erklärt habe, was das Problem, also die Aufgabenstellung ist, komme ich dann ganz schnell zur Lösungsstrategie. Nachdem du jetzt nach Points of Interest gefragt hast, bin ich fast der Meinung, wir könnten als Untertitel Points of Interest darunter schreiben. Mein Ansatz ist, da stehen die Sachen drin, die besonders und speziell sind, die alle Leute wissen sollten. Das können bestimmte exotische Technologien sein. Das können technische Randbedingungen sein, die aus der Historie so sind.

Sven Johann: Ja.

Gernot Starke: Ja, aber ich bin der Meinung, die sind für alle wichtig. Das können ganz kleine Dinge sein, zum Beispiel eine kleine Library, die wahnsinnig wichtige Arbeit für dich erledigt, oder manchmal sind es auch ganz teure Dinge. Das Management hat entschieden, wir kaufen dieses teure Zeug, und dann möchte das Management auch, dass das gebührend Erwähnung findet.

Ja, also diese längerfristig gültigen Entscheidungen oder Sachverhalte, die wichtig sind. Wir haben es, wie gesagt, Lösungsstrategie genannt. Die Zielsetzung ist, dass es ein kurzer Einblick ist.

Sven Johann: Ja.

Gernot Starke: Und wenn du es ausführlicher wissen willst, verweise ich gerne auf die Querschnittskonzepte, wo ich dann diese Points of Interest, diese interessanten Dinge, erkläre.

Sven Johann: Ah, okay, ja, so habe ich es eigentlich auch nie gesehen, aber genau, da könnte man es eigentlich.

Gernot Starke: Ja, wenn wir hier fertig sind, muss ich Peter anrufen, weil wir gerade, ja, okay, vielleicht greife ich vor, weil wir gerade in der Finalisierung von Version 9 sind.

Sven Johann: Ja.

Gernot Starke: Ich glaube, außer uns kaum jemand erkennt, dass es einen Unterschied zur Version 8 gibt, aber wir haben ein bisschen am Wording gearbeitet. Wir möchten auch Konsistenz dieser Schreibfächer haben, Kompatibilität und ja, also das sicherstellen. Aber so ein Untertitel ‘Points of Interest’ unter ‘Lösungsstrategie’, das kann ich mir gut vorstellen.

Sven Johann: Ja, ich meine, als ich es zum ersten Mal gelesen habe, da ist mir auch direkt, es war noch bei einem meiner ersten Arbeitgeber, da gab es so ein System, das mussten sie an einen anderen Dienstleister abgeben, und dann haben die immer gesagt, die werden es niemals zum Laufen bekommen, niemals. Und die hatten Recht gehabt, die haben ein Jahr daran gearbeitet, und es gab kein neues Release, gar nichts, weil nichts funktionierte. Und die haben gesagt, das liegt daran, dass es hier Zeitdruck gab, da Zeitdruck, da Zeitdruck. Wir haben gesagt, niemals, die haben gesagt, doch. Die einzige Möglichkeit ist folgende Lösung, die ist aber völlig irre, weil sie fatale Konsequenzen hat, egal, machen. Ja, und das hat sich natürlich so akkumuliert, und das war, das ist in der Codebase nicht so wirklich ersichtlich, also es ist nicht so ganz klar, wieso jetzt unter der Haube zur Laufzeit irgendwelche Sachen ausgetauscht werden und so weiter. Und da muss ich immer auch, wie gesagt, genau, das sind so diese drei Points of Interest, dann hätten die vielleicht ein halbes, ein Jahr gebraucht, um zu sagen, ja, jemand anders.

Gernot Starke: Jetzt könnten Menschen sagen, ja, aber das sind doch typische Architecture Decisions, die du als Decision Record irgendwo ablegst. Das kaufe ich nicht, weil es Architecture Decisions in der Regel ganz viele gibt, eher 100. Aber Points of Interest gibt es nur drei bis zehn, und zehn ist schon viel. Ja, und so diese kleine Handvoll ganz wesentliche, meinetwegen verweise ich dann auf die entsprechenden ADRs, das kann ich machen. Aber das finde ich ist Dienst an den Stakeholdern, weil die halt sofort einen Einstieg finden und sagen, was ist denn das Allerwichtigste hier?

Sven Johann: Genau, genau. Also ich meine, ja, wenn ich jetzt an einen guten Bekannten von uns denke, der auch beim iSAQB sehr aktiv ist, und an ein Projekt, wo er involviert war, also wo er sozusagen der Head of Architecture war, da gab es 500 ADRs oder so übers ganze Projekt.

Gernot Starke: Ja, und da ist es auch, das könnte sich mit LLMs ändern, aber da ist so eine Priorisierung extrem schwierig zu kommunizieren oder irgendwie beizubehalten. Dann bläst du wieder deinen ADR-Mechanismus mit Prioritäten auf, das willst du alles nicht. Du willst es so einfach wie möglich halten, und dann ist diese Lösungsstrategie ‘Point of Interest’-Sektion wirklich wertvoll.

Sven Johann: Ja. Eins wollte ich noch sagen, es gab kaum große Veränderungen, aber es gab schon neben dem Wording ein paar Veränderungen.

Gernot Starke: Im Grunde wirklich Kleinkram. Als wir aspektorientierte Programmierung in Java mit AspectJ und als Spring angefangen hat, so etwas auch unter der Haube zu verwenden, da haben wir gemerkt, bei uns gibt es eine Sektion, die heißt Aspekte, und plötzlich glauben die Leute, das ist aspektorientierte Programmierung. Ich kann arc42 nicht nehmen, weil ich das ja nicht mache. Und dann haben wir, ich will nicht sagen panisch, aber ganz schnell gesagt, wir brauchen ein neues Wort dafür, für diese querschnittlichen Themen. Querschnittliche Aspekte haben wir dann durch Querschnittliche Konzepte ersetzt. Du grinst, das ist inhaltlich immer noch genau das Gleiche wie vorher, aber das Wording ist geklärt.

Sven Johann: Words matter, ja.

Gernot Starke: Und es ist auch schon sehr lange her, dass diese Lösungsstrategie dazugekommen ist, aber sie ist halt mal dazugekommen. Wir haben diese Querschnittskonzepte von der Priorisierung her ganz früher eher klein gehalten, da war uns eher wichtig, macht den Grundriss, die Bausteinsicht, bringt die in den Vordergrund. Das sehe ich heute nach ein paar Jahren Erfahrung differenzierter, ich bin mittlerweile der Meinung, die Konzepte sind oftmals fast wichtiger als der Grundriss.

Ja, weil gerade im Sinne von Services oder Self-Contained Systems die Grundrisse oft viel kleiner geworden sind. Aber strukturell haben wir schon ganz von Anfang an hohe Konsistenz.

Sven Johann: Ja, okay, also technische Schulden, Entscheidungen und so weiter war schon immer.

Gernot Starke: Entscheidung war immer dabei. Technische Schulden, Risiken, weiß ich nicht, was ganz am Anfang dabei war, aber das spielt ja jetzt auch keine Rolle. Du hast jetzt einen Platz dafür, der auch nur relativ selten verwendet wird. Und dann ignorieren Leute das eher und behandeln ihre technischen Schulden anders.

Sven Johann: Wenn überhaupt. Ja, Risiken, ich muss sagen, Anekdote, wir waren mit Peter Ruschka, kannst du dich vielleicht noch erinnern, in Frankfurt beim Inder, und dann hatte ich ihn auch mal irgendwie, ich hatte eine Diskussion mit ihm über Risiken, und er hat ja auch dieses Buch mindestens übersetzt, er ist ja sozusagen Mister Risiken.

Gernot Starke: Ja, schon.

Sven Johann: Und dann hat er irgendwie zu mir gesagt, also mit diesen Risiken, das kapiert eh keiner, ganz wenige. Das fand ich ganz interessant. All right, genau, vielleicht so zum Abschluss, du hast ja schon mal so ein bisschen mit LLM angekündigt, wo geht’s denn hin mit arc42, was sind so die Ideen?

Gernot Starke: Wir haben das arc42 Qualitätsmodell hinzugefügt. Qualitätsanforderungen sind ja eher ein Anforderungsthema. Sie spielen für uns in der Architektur eine ganz prägende Rolle, weil ich darauf wichtige Entscheidungen basiere, und da gab es irgendwie zu wenig öffentlich sichtbare, kostenfreie Informationen. Also habe ich gesagt, das passt gut in das arc42 . Das ist dazugekommen.

Sven Johann: Wir verlinken es übrigens auch in den Shownotes, weil wir eine ganze Episode dazu haben.

Gernot Starke: Ja, aber auch da merke ich Akzeptanz, und es gibt so ein bisschen andere Bedürfnisse, und in dem Bereich wird sich noch ein bisschen was tun. Jetzt gerade frisch dazugekommen sind Qualitätsstandards, so dass ich auch über Qualitätsstandards in dieses Q einsteigen kann. Ich kann jetzt also sagen, irgendwelche Dinge, die brauche ich, kriege ich da drauf, und dann sehe ich, okay, folgende Attribute sind betroffen, und so könnte ich die beschreiben.

Sven Johann: Oh, nice, also auch so, ich sag mal, wenn ich jetzt an Dora denke, also Digital Operations Resilience Act von der EU.

Gernot Starke: Ja, die sind sowieso, also Dora Metriken sind.

Sven Johann: Nee, die Dora Metriken meine ich jetzt, ich meine hier so, ja.

Gernot Starke: Das ist halt der Plan, und wir haben eine neue Metaklasse in diesem Q42 eingeführt.

Sven Johann: Okay.

Gernot Starke: So dass ich jetzt ziemlich einfach auch Pull Requests annehmen kann, wenn du sagst, dieser Dora Standard interessiert mich, dann mach halt eine kurze Beschreibung. Und ich kann dann diese bestehenden Eigenschaften einfach nur alle taggen und sagen, folgende sieben gehören zu diesem Standard. ISO27001 , ISO26262 , keine Ahnung, da gibt es halt ganz viele von.

Sven Johann: Ja.

Gernot Starke: Nicht schlecht. Ja, und das habe ich als Frage bekommen und habe dann selber gedacht, das ist eine coole Idee, und es ist halt einfach umzusetzen, weil wir den Content sowieso haben.

Sven Johann: Ja.

Gernot Starke: Das ist das eine, da wird es weitergehen, da haben wir jemanden dran, Contributor Fabian Angst, der sich ein bisschen auch mit Usability herumschlägt, hat so eine Graphenstruktur gemacht, dass man über einen Graphen einsteigen kann, da arbeiten wir noch dran. Und dieses LLM-Thema, da experimentieren ja nicht nur wir INNOQ-seitig oder Peter und ich, wie kann ich den Content eines arc42 Schrankes einem LLM geben, oder wie kann ich vielleicht den arc42 Content und ein Repo kombinieren, so dass wir einige Architekturfragen leichter beantwortet bekommen. Und beispielsweise die LLM, die KI fragen, hier sind ADRs, was haben wir denn zum Thema Caching entschieden? Und Caching, das kann ich auch temporäres Zwischenspeichern nennen, so ein LLM ist halt ziemlich gut in der Lage, auch über unterschiedliche Ausprägungen von Begriffen hinweg dir zu sagen, hier folgende fünf ADRs beziehen sich auf dieses große Thema. Das ist, ich mag diesen Begriff Game Changer, den versuche ich sporadisch zu verwenden, das ist für mich ein Game Changer. Ja, weil ich selbst in kleineren Systemen gemerkt habe, wie schnell ich von ADRs vergessen habe, was ist gerade aktuell, was haben wir entschieden, was war da noch mal das Detail? Und eine rein textbasierte Suche kriegt das nicht hin, die schafft es nicht. Und mein Ausweg war dann immer, ich gehe den Sven fragen oder ich gehe jemand anders fragen. Und da ist ein LLM schon ziemlich gut.

Sven Johann: Ja, also ich habe jetzt so, ich meine, wir dokumentieren hauptsächlich in Confluence, aber leider, man könnte natürlich sagen, ja, warum macht man kein Markdown direkt am Code und so weiter. Gründe, Accessibility, blablabla. Aber jetzt denke ich mir auch, wenn ich praktisch mein arc42 auch direkt, also so mein Gedanke, in Zukunft immer ist immer Teil von meiner Codebase, dann habe ich egal in welcher Umgebung ich bin, ich habe einen Coding Agent, der hat als Kontext nicht nur den Code, sondern auch mein arc42, und dann kann ich dem ja ganz andere Dinge sagen, und ich muss jetzt irgendwie alles lang und breit erklären, und ich sage, hier ist ein ADR, da ist ein Konzept, das haben wir übrigens da schon so umgesetzt und jetzt bitte ausprobieren.

Gernot Starke: Bei arc42 verlassen wir schnell den Template-Gedanken und kommen zum Prozess oder zum Vorgehen. Ich möchte aber auch als Open-Source-Provider und Contributor gerne in der Lage sein, solche Fragen zu beantworten. Deswegen investieren wir da auch ein bisschen Zeit. In der LLM-Szene ist nichts fertig, sondern alles im Fluss. Ich glaube, wir werden dazu auch noch ein paar Blogposts schreiben oder möglicherweise Beispiele vorbereiten, wie man das arc42 Universum mit LLM-Hilfe vielleicht geschickter einsetzen kann, als wir das bisher gemacht haben.

Sven Johann: Da kann ich ein bisschen manuelle Arbeit sparen. Genau. Ich denke, es gibt auf jeden Fall viele interessante Ideen. Man muss sie natürlich ausprobieren, denn man glaubt immer, es wird alles gut, aber manchmal funktioniert es doch nicht so. Also, ausprobieren. Das hat gerade etwas getriggert, weil du gesagt hast, es sei ein Template und kein Vorgehensmodell. Für mich ist das tatsächlich auch ein bisschen ein Vorgehensmodell, das gebe ich zu. Aber das ist vielleicht ein Thema für einen anderen Tag.

Gernot Starke: Das ist ein gutes Stichwort. Lass uns daraus gerne noch einmal eine Folge über das Vorgehen dahinter machen. Tatsächlich hatte das echte Konsequenzen für solche Vorgehensweisen, und selbst iSAQB ist schon ein bisschen davon beeinflusst.

Sven Johann: Genau. Alles klar, Gernot, ich bedanke mich.

Gernot Starke: Ich bedanke mich für das nette Gespräch.

Sven Johann: Genau. Bis zum nächsten Mal.

Gernot Starke: Bis zum nächsten Mal. Auch euch vielen Dank.

Sven Johann: Ciao.