Gernot: Gernot, hallo Sven, Servus.

Sven: Hallo und herzlich willkommen zu einer neuen Folge vom INNOQ Podcast.

Sven: Heute habe ich den Gernot Starke zu Gast.

Sven: Ähm, wir sprechen heute über 20 Jahre A42, also ganz schön ganz schön lange, ein Leben, ich kenne gar kein Leben ohne A42 fast.

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

Sven: Genau, und wir wollen im Grunde genommen wollen wir einfach darüber reden, wie kam es dazu, ähm, wie hat sich es über die Jahre entwickelt, ähm, was habt ihr so gelernt, was ist noch mal reingeflossen, was ist neu neues passiert und vielleicht noch mal so einen kleinen Ausblick, was wir es eigentlich, was wir vielleicht noch mal so erwarten können, falls wir überhaupt noch was erwarten kann nach 20 Jahren, aber ich glaube schon.

Sven: Genau, ähm, liegen wir doch direkt mal los, wie kam es eigentlich dazu?

Gernot: Ja, gute Frage.

Ähm, ich hatte ein Projekt bei den Finanzbehörden, äh, die hatten damals so eine Dependance in Bonn, ne, war ein ganz spannendes Projekt, relativ viele Leute, also eher 50 als, ne, kleiner wird man heute kleiner schneiden, aber es war halt so.

Gernot: Und ähm, ich hatte zum damaligen Zeitpunkt schon so ein Architekturbuch geschrieben, das ist dem Projektleiter in die Hände gefallen, der hat gesagt, immer, 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, ne, und habe mich mit einem guten Freund Peter Ruschka halt drüber unterhalten, der sagte auch, ich bin gerade in so einer ganz ähnlichen Situation, aber im Embedded Umfeld.

Gernot: Ja, dann haben wir halt so ein bisschen, ne, gehirnt und überlegt, wie könnte man das machen, und gesagt, ja, wichtig ist halt, dass wir uns auf den Inhalt der Arbeit konzentrieren können, weniger mit auch den 50 Leuten über die Form reden müssen und hatten dann so die Idee, eigentlich bist du so eine Art Kleiderschrank machen, wo die Leute dann immer nur noch so diese Architektur Sachen einräumen können, also dieser Template Gedanke und Peter, also im im Sinne von beim Kleiderschrank weiß ich immer, wo ich die Socken und die Unterhose rein mache, und bei Architektur weiß ich immer, wenn ich eine Entscheidung treffe, kommt es dahin und wenn ich über Stakeholder rede oder.

Sven: Oder wenn du über eine Struktur redest, dann kommst du anders hin.

Gernot: Und Peter kannte aus seiner Historie als Requirements Engineer, das wohl Lehre Template, ja, 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, ne, so diese Idee als Vorlage, aber spezifisch ausgeprägt für Architektur.

Gernot: So und der ähm ein großer Treiber war dann, dass wir aus der Embedded Sicht, Embedded Realtime Safety Critical Sicht von Peter und meiner Sicht, ne, Finanzamt Software klassische sag mal eher einfachere strukturierte Informationssysteme, halt gesagt haben, ne, gibt's denn da Gemeinsamkeiten und erstaunlicherweise haben wir ganz ganz viele Gemeinsamkeiten gefunden, 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, ne, also wir wollten das nicht als irgendwas proprietäres haben, sondern war schon immer so die Idee, so ähnlich auch wie wohl Lehrer, lass uns da paar Artikel zu schreiben oder so, also irgendwas machen, so dass man das halt frei benutzen kann, weil da benutzen es vermutlich mehr Leute.

Sven: Ja.

Gernot: Und das ist bei unseren beiden Projekten, also sozusagen bei den Piloten ist das ganz gut angekommen.

Gernot: Also es gab für die für mein Projekt zumindest eben auch keine Alternative, also die mussten es halt machen, aber zumindest waren halt viele Projekt Stakeholder dann doch ganz zufrieden damit, so, so ist es halt entstanden.

Sven: Und wie gesagt, ob die Leute das gerne gemacht haben, weiß ich nicht, aber sie haben es halt gemacht.

Sven: Ja.

Sven: Wenn du sagst, die die waren zufrieden, also die die Entwickler und Architekten, die halt da dabei waren, die haben das, also zufrieden gleich gerne angenommen.

Sven: Und sie brauchten sich ja nicht Gedanken machen, wo packe ich jetzt die Socken hin und wo die die Handtücher, sondern das war halt, da gab es halt Handreichung für sie und sie konnten mich ja auch fragen, also letztlich habe ich ja nicht nur das Template vorgegeben, sondern auch versucht praktisch den Leuten halt die Hand zu reichen so, so oder so könntest du das machen.

Gernot: Gerne, darüber möchte ich gar nicht spekulieren.

Ja, es war klar, die Notwendigkeit auch im Projektauftrag formuliert, wir müssen halt was dokumentieren.

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.

Sven: Ja, das ging dann natürlich über diese reine Fächerstruktur ein bisschen raus, wo wie kriege ich denn jetzt so eine so eine Bausteinsicht beschrieben, also so ein Grundriss, also ein Komponentenmodell und wie kann ich jetzt vielleicht, ne, so Details eines Subsystems und eines anderen irgendwie zusammenbringen.

Sven: Also deswegen so im in Hindsight, so im Rückblick sage ich, dass allein schon deswegen hat es ganz gut funktioniert, weil wir halt Peter und ich und auch die Projekte gesagt haben, wir machen das weiter.

Sven: Na, wenn es halt komplett Grütze gewesen wäre, dann hätten wir irgendwann aufgehört und uns was anderes gesucht.

Sven: Es gab bei den Behörden ein Teilprojekt, die haben versucht mit einem sehr sehr formalen Dokumentationsansatz, ne, so mit so Metamodell vom Software Engineering Institute zu arbeiten, ne, 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.

Sven: Die sind alle dann am Ende zu unserem Ansatz übergelaufen und haben gesagt, daneben ist ja viel einfacher, da kommt, wir machen das auch so, ne, statt diesen eher theoretisierten Ansatz, ja, wo man über Metamodellebenen erst noch mal quasi seine eigenen Grundlagen modelliert, also seine seinen Schrank metamodelliert, bevor man dann zum eigentlichen Schrankinhalt kommt.

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

Ja.

Sven: Nicht weiter drüber reden.

Sven: Ich bin ja Fan vom SEI, aber.

Sven: Äh gibt paar Probleme.

Ähm, hat aber gerade was bei mir getriggert und zwar ähm, also du sagst, ihr habt euch an wo Lehre äh orientiert und an der Idee von der Idee genau, weil es gibt halt fest definierte Ja.

nennen wir so Schrankfächer, die eine ziemlich gut beschriebene Semantik haben, also wo klar ist, was bedeutet das?

Ja, sodass ich auch wo nachgucken kann, was meint er jetzt damit, wenn er so ein komisches Wort sagt, wie Draufsicht oder Verteilungssicht oder so, ne?

Sven: Und gab's damals andere Dokumentationsmöglichkeiten, also außer die vom Software Engineering Institute, ich denke so konkret, also ich hatte ja auch mal mit Unis zu tun vor einer Weile und dann, also es war eigentlich in so einem Forschungskontext äh und und dann haben die mich auch gefragt, ob ich mal so eine Gastvorlesung Remote halten kann, war eine amerikanische Uni.

Sven: Und äh dann habe ich, da im Grunde genommen habe ich über 42 geredet.

Ähm oder ja, im Grunde genommen, also sagen wir, ich habe über 42 geredet und dann meinten die, warum ich eigentlich 42 nehme und z.B.

nicht SDD, SDD nie gehört, also Software Development Design Method oder also irgendwie sowas, ne?

Und ja, nee, da stimmt, ich habe, ich bin ja im Grunde genommen mit, ich sag mal mit Garnot Starker bzw.

Simon Brown, also Simon Brown hat halt eine hat auch ein Buch geschrieben, englisch war sehr bekannt im englischsprachigen Raum und in dem Buch, er hat es kein Template gemacht, aber er hat in seinem Buch hat er ähnliche Sachen diskutiert wie ihr.

Sven: Ja, also amerikanisches Militär, britisches, australisches, die schon so ihre Vorstellungen hatten, wie zu dokumentieren ist.

Sven: Ähm, ohne dass ich da jetzt allzu weit reingeguckt habe, schon das erste drauf gucken hat, habe ich immer gedacht, boah, ist das aufwendig?

Sven: Mhm.

Sven: Und ähm äh aufwendig im Sinne von formal aufwendig und habe das dann für mich Akta gelegt, weil ich eher so diesen pragmatischen Gedanken verfolgen wollte, wir müssen das halt irgendwie im Projekt unter Zeitdruck schaffen und wir sind eben nicht per Contract verpflichtet, ne, diese Formalia einzuhalten.

Sven: Ja, ich meine, ja, ich bin eigentlich nur mit denen beiden groß geworden und äh und ich kenne gar nichts anderes, deswegen hat mich jetzt so ein bisschen kalt erwischt, ich habe noch nie gehört, sorry.

Ähm, aber aber gab's da was äh in der Vergangenheit?

Sven: Ja.

Sven: Und da statt 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.

Sven: Also meine ersten Schritte waren im Grunde so auf der grünen Wiese, ne, da habe ich auch denk zurück, ne, vor 20 Jahren war Googeln anders als heute Googeln ist, ne, da war das nämlich in die Bibliothek gehen und gucken so, findest du was im Stichwortverzeichnis?

Ähm, nicht nicht ganz so stimmt, ne, aber nahezu so und das heißt, wir haben schon im Grunde befreit von eben aus der wo Lehre angefangen.

Mhm.

Über die Zeit habe ich halt mitbekommen, dass es gerade im Defense Sektor Sven: Mhm.

Sven: Na, es gab mal von Hewlett Packard und von IBM so Versuche auch so Dokumentations Templates zu produzieren.

Ähm, ne, bei IBM kostet es Geld, das ist eingeschlafen und bei die Leute von Hewlett Packard haben es auch irgendwann von ihren Webseiten genommen, weil sie es einfach, glaube ich, nicht genügend Akzeptanz gefunden hat.

Sven: Ja.

Sven: Ja, also mir mir ist auch nichts in meinem ganzen Leben über den Weg gelaufen.

Also entweder sagen die Leute, also es gibt halt nur Arc 42 oder man kann also ich hätte jetzt fast gesagt, man kann natürlich Simon Brown kann man sich angucken, aber interessanterweise ähm ich ich kriege mir jetzt nichts an, wahrscheinlich muss man leider auf Englisch sagen, damit es sich wehren kann.

Aber persönlich hat er mir auch mal gesagt, dass äh viele seiner Kunden halt einfach sagen, wir nutzen Arc 42, aber C4.

Ja, also weil er halt halt nichts anderes, er hat halt C4, aber er hat der ganze Kram drum rum ist eigentlich nur im Buch beschrieben und es gibt kein Template Mechanismus.

Ja.

Wenn, das ist jetzt natürlich so ein im Nachhinein dazu gedichteter Witz, aber C4 ist halt schon Namensbestandteil von Arc 42.

Ja.

Simon weiß das auch, er macht ja auf seiner Webseite sogar nicht Werbung, ne, aber er weiß hat darauf hin, dass das gut zusammenpasst.

Mhm.

Und meiner Ansicht nach passt es wirklich ausgezeichnet gut zusammen, weil wir in Arc 42 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 guckt bei Simon, was kannst du in seiner C4 Notation alles machen und das passt eins zu eins in diese Fächer.

Ja.

Ja, und ich habe äh selber häufiger erlebt, dass mir Leute gesagt haben, ja, wir machen Arc 42, aber wir haben keine Lust auf UML, ne, aber wir wollen halt auch so ein bisschen Toolunterstützung, also nehmen wir den Structurizer von Simon und das passt super zusammen.

Ja.

Sagst du so, ne, dass eins zu eins so ist, aber der also ich habe so konkret zwei Dinge im im Hinterkopf, was was ich bei Simon finde und Arc 42 finde, was ich aber trotzdem mache.

Also was sozusagen Arc 42 ist ein Template, man kann es erweitern, also es ist die die Gernot starke Polizei kommt nicht vorbei, wenn jetzt da irgendwie.

Ja, genau.

Ähm, aber also er hat z.B.

Data Kapitel, ja, und er hat noch sowas, das finde ich eigentlich ziemlich interessant, ist so, es nennt sich Points of Interest.

Also man hat dieses große System, man kann das irgendwie gut beschreiben, aber Points of Interest sind so die fünf, sechs, sieben Stellen, wie auch immer, sowie ich bin auf einer Insel oder so und dann gibt's so, ich muss halt die ganze Insel absuchen, sondern da gibt's halt interessante Stellen für die Touristen, ja, und ähm jetzt die, also was will ich damit sagen, ist, ähm über die Zeit gab es ja wahrscheinlich einen Haufen Ideen, was da reinkommen soll oder was nicht reinkommen soll, ähm, dass du da vielleicht mal Das gehört auch zu den wenigen Punkten, wo wir ähm Kommentare aus der Userschaft bekommen haben, die dann Vorschläge gemacht haben, so, nehmt doch noch folgendes auf, das ist für mich wichtig.

Ja.

Eine Sache, die wir ein paar mal 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.

Ähm, architekurell habe ich immer gesagt, du kannst das prima in die Konzepte packen, also in unsere querschnittlichen Konzepte und wenn es wirkliche Flows sind, bieten die sich für die Laufzeitsicht an.

Ja, dafür muss man halt ein bisschen out of the box denken, was ist eine Laufzeitsicht und was ist ein Konzept, aber die Infos kriege ich gut untergebracht.

Ja.

Und ähm wir hatten Peter und ich hatten immer die die Vorstellung, dass wir die Anzahl Schrankfächer minimal halten wollen.

Gernot: Ja, er hat gesagt, so, du nimmst ist dir dann sowieso und packst nur eins, zwei dazu, ne, aber wir wollen jetzt nicht den Fehler, den wo Leere gemacht hat, also irgendwann mal auf 25 Kapitel zu kommen und kein Mensch kann sich mehr merken, was ist jetzt Kapitel 17 und 19, ne, wir sagten, wir beschränken uns auf dieses Dutzend.

Gernot: Und ähm erweitern es, na, das machst du, wenn du es brauchst, aber wir machen das nicht als Template Provide.

Gernot: So, die zweite Idee, die uns Leute gegeben haben oder gefragt haben, was mache ich mit Daten?

Gernot: Na, wo kommt mein Datenmodell hin?

Ich habe eine bestehende Datenbank, wo kriege ich die Struktur unter?

Und da war unsere Argumentation oder ist auch immer noch, dass Daten diese Baustein Charakter besitzen.

Ja, das heißt Daten, Datenstrukturen, Tabellenstrukturen passen für mich einerseits gut in die Bausteinsicht, ja, wenn ich das möchte und wenn das so Basisinformationen sind, die im System sowieso jeder braucht, dann ist es ohnehin Querschnittsthema.

Gernot: Das heißt auch bei diesem Hinweis, ja, was mache ich jetzt mit Daten, ne?

Tue ich mich schwer mit, ja, mach noch eine neue Sicht.

Gernot: Komma.

Ausnahmen bestätigen die Regel.

Ja, ich habe für Versicherer arbeiten dürfen, da drehte sich alles um Daten, ne?

Die Daten müssen wir 100 Jahre aufbewahren, ja, Verträge, Policen, irgendwann das muss die Feuerversicherung von 1872.

Ja, genau und da habe ich mich breitschlagen lassen und gesagt, du, ich sehe es ein, das erste, was er immer tut, ist über Daten, Datenstrukturen, DB2 Tabellen reden, dann gibt denen doch eine eigene Sicht, wenn das so wichtig ist, ähm ja, und wir müssen halt gucken, dass es konsistent mit Bausteinen und so weiter ist, aber ähm ja, das das könnte ich noch irgendwie mir vorstellen als wirklich ein Add-on Kapitel, was man so macht.

Gernot: So.

Dann hast du gesagt, Points of Interest.

Sven: Vielleicht eine ganz Kurzfrage zu den Daten.

Ähm, also, wenn man sich euer Template, also ich gehe mal davon aus, dass alle, also dass alle Leute, die hier reinhören, sowieso schon A 24 nutzen, wir haben jetzt kein Intro oder so gemacht.

Ähm, aber ihr habt ja nicht nur irgendwie Kapitel, wo ihr sagt Kapitel acht Entscheidungen oder sowas, ja?

Habe ich richtig gesagt?

Ich glaube neun, aber egal.

Also, ähm, es sind irgendwelche Kapitel, sondern ihr schreibt ja auch, ja, in diesem Kapitel, das sind so ein bisschen Hinweise, ja?

Also, was kommt hier rein?

Ja, ich habe querschnittliche Themen, das ist das, das, das, das, das, das, das, ne?

Und hier haben wir Bausteinsicht oder könnten natürlich in der Beschreibung auch drin stehen.

Ich habe, ich habe da früher mal reingeguckt, aber jetzt, dann frage ich mich, steht da bei Bausteinsicht auch, dass man potenziell Daten, dass man über Daten da spricht.

Ja, lass mich diesen Schritt zurückgehen, ja, was bringen Leute, was fragen uns Leute, ne?

Was kriegen wir für Kommentare?

Wir haben über die Zeit und ich habe es nachgeguckt, bevor wir gesprochen haben, es war um die 2016, ne, also da gab es A 24 so gute 10 Jahre.

Da haben wir halt gemerkt, ähm so vom vom Einsatz her und auch von den Fragen, die Leute stellen, hm, da sind echt noch ganz viele Dinge unklar.

Ja, der wir also wir müssten mehr erklären, wie irgendwas geht.

Wir wollten aber das Template minimal halten.

Ja, das war dann der Moment, wo wir gesagt haben, hm, lass uns doch mal Ratschläge sammeln, die wir Leuten geben, wie du das einsetzen kannst.

Mhm.

Also, wenn du eine ein großes Datenmodell hast und und und, dann setzt das A 24 wie folgt ein oder bilde das in A 24 wie folgt ab.

Ja, und ähm um die Zeit sind zwei Websites entstanden, also zwei Subdomänen, die eine heißt FAQ, ne, wo wir halt die Fragen der Leute versuchen zu beantworten.

Mhm.

Und die zweite heißt Docs, ne, weil wir sagen, so, wir nehmen uns jetzt zum Kapitel, so eine Sektion von A 24 und dann geben wir dazu ein Dutzend Tipps, wie du die einsetzen könntest.

Also hast du perversen Zeitdruck, dann lass den Teil schon mal direkt weg.

Ne, bist du aufgefordert, besonders gründlich zu arbeiten, dann schlagen wir vor, mach das so und so.

Mhm.

Kurze Zwischenfrage, seit wann gibt's die?

Seit 2016.

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

Ja, ja.

Das war auch die Zeit, wo wir auf Markdown Ja.

ähm Doku und Askidoc so Zeugs umgestiegen sind, ne, weil mit Markdown kann man sowas halt viel einfacher händeln, als wenn wir, na, so wie ganz, ganz früher gab es halt nichts außer Word und aus Word exportiertes HTML, also es Grütze und ja.

So und diese Docs Seite, da wir gucken so ein bisschen auf Page Views und das ist die mit Abstand am höchsten frequentierte Subdomäne, die wir halt haben und das ist noch eher noch mehr angespielt, seit wir auf diesen Docs Gernot: Pro Sektion Beispiele geben.

Gernot: Ja, weil wir wirklich sagen so hier ist eine Anwendung und in der Anwendung, ne, Gesundheitskarte oder in der Anwendung Nachverkontrolle oder so, haben wir die Bausteinsicht so und so aufgebaut.

Ja, dann kannst du da reinklicken und kriegst halt Bilder, also du kriegst wirklich Exemplare, ne, wo du sagen kannst, das gefällt mir gut, das passt zu meinem System, also tausche ich jetzt da, ne, das Bild, was ich hier im Beispiel sehe, aus durch mein eigenes und dann habe ich das.

Sven: Okay, okay.

Gut gemacht, ne?

Das ist, das ist wirklich gut angekommen.

Ja, ja.

Gernot: Ja, also, ich habe nämlich gerade eben habe ich so einen kleinen Schockmoment für, also persönlich Schockmoment für mich gehabt, wo ich gedacht habe, die Docs Seite, da war ich noch nie, aber jetzt wo du sagst, ihr habt diese Beispiele, ich hatte ja klar, war schon 77 mal, ne, aber ja, glaube ich gerne, ja.

Ja, und das, ja, das ähm.

Gernot: Ja, wir hatten immer so ein bisschen damit, dass wir natürlich in Docs und FAQ eine Menge Redundanz haben, dass die nicht gut genug quer vernetzt sind, weil wir das alles manuell gepflegt haben und ähm.

Gernot: Vielleicht fragst du mich ja noch nach Ausblick, aber das ist halt ein Ausblick, dass wir ernst vorhaben mal mit ein bisschen LLM Unterstützung da die Vernetzung zu verbessern.

Ja, machen wir später.

Ja, ja, machen wir später, wenn wir es schaffen, ne, aber das ist halt wirklich was, wo, ne, wo es noch ein Bedarf gibt, ne?

Ja, die Suche da besser ist.

Gernot: Ja, also ich muss sagen, ähm, also ich glaube das gerne, ne, weil in äh in unseren Schulungen, da hier in der von INNOQ B Foundation Level Schulung, um so kleine Werbung zu machen, gibt's natürlich auch noch Architektur Dokumentation Schulung, äh kann man auch alles buchen.

Gernot: Und da, es gibt ganz viele Leute, die die sehr interessiert sind, aber die so ein bisschen wie vor also, die denken halt, okay, ich habe hier diese Kapitel, aber eigentlich weiß ich nicht so genau, was ich da reinschreibe, und das fällt mir auch bei Kunden auf, dass ich manchmal so Kapitel sehe, wo ich denke, oh, hier hat, also was heißt manchmal, eigentlich in 100 % der Fälle, wo man halt denkt, oh, äh hier wurde zwanghaft was reingeschrieben, weil ich stehe halt vor dieser Wand, da steht Kapitel, ich sag jetzt mal Stakeholder oder Randbedingungen oder so und, was soll ich hier noch reinschreiben, ja, und dann ähm, dann wird irgendwas reingeschrieben.

Und dann verweise ich halt auch immer auf Beispieldokumentation, also ihr habt ja auch äh so unterschiedliche Systeme, ne, also nur du und Peter, sondern ähm, aber jetzt komme ich auf die Namen nicht, ehemaliger Kollege aus Ach.

Gernot: Michael Simons, ja.

Ja, Michael hat mitgeschrieben.

Wir haben jetzt Contribution bekommen von einem Senior Architekten von Zeis, der ein Buchkapitel beigesteuert hat, ne, Architektur, der Stefan Zörner hat was, der hat seine coole Schach Engine, ja, in dem, also es gibt Ja, du willst auf dieses 42 bei Example Buch, ja, es gibt ja so eine Jubiläumsausgabe, die es auch noch ein paar Monate lang sogar kostenfrei gibt.

Ja, es sind wirklich 350 Seiten.

Gernot: Ja, mit sieben oder acht, schlag mich nicht, äh konkrete real existierende Systeme, Softwaresysteme, die halt mit A 24 dokumentiert sind.

Ja, mehr oder weniger ausführlich, so dass, behaupte ich, jeder oder jeder da so ein bisschen was findet, was halt zu der eigenen Anwendungssituation passt.

Mhm, ja.

Ja, also ich ich muss muss auch noch mal hier unbedingt die Stefan Zörner Schach Engine empfehlen, weil ich fand, er hat ein Buch geschrieben, also gibt ja nicht nur dieses Beispiel auf der Webseite, aber sehr, ich finde sehr einfach zu benutzen ist, ja, sein Buch geschrieben und dann ist eigentlich super um äh um das so.

Gernot: Die Schach Engine ist, finde ich, auch ein toller Anwendungsfall, ne, was über dieses, Entschuldigung, langweilige Business System einfach ein Stück rausgeht.

Ja, Stefan ein gutes Händchen hat, äh Dinge ja, transparent nachvollziehbar zu vermitteln und zu formulieren.

Ja, da kann sich auch jeder was drunter vorstellen.

Also ich meine, wenn ich jetzt irgendwie ein Banking System oder so als Beispiel hätte, da muss man sich in die Domänen reinarbeiten, aber wenn man irgendwie so eine Domäne hat, Schach Engine oder ich sag mal irgendwelche berühmten Open Source Projekte, äh dann ähm, dann ist natürlich.

Gernot: Berühmte Open Source Projekte haben wir noch nicht dokumentiert.

Also wir nicht, andere von anderen weiß ich das nicht.

Ja.

Ja, also ich meine, die den gibt's, äh, die gibt's natürlich auch zu also zu üben, ne?

Also zu sagen, nimm dir Git und dokumentier Git im A21, also Git Architektur, nicht, wie nutze ich das, sondern im Architektur Style.

Okay, ähm, genau, was, guck gerade auf die Uhr, ähm, vielleicht noch, bevor wir auf die Zukunft blicken, noch mal, gibt's irgendwie so Veränderungen, also was sind so die die großen Veränderungen über die Zeit am Template?

Es ist noch.

Gernot: Äh, auf meinem Stack eine nicht beantwortete Frage von dir von eben, du hast nämlich nach diesen Points of Interest gefragt.

Sven: Ja, ach ja, stimmt.

Points of Interest.

Gernot: Und ähm das letzte, was in meiner Erinnerung dazu gekommen ist bei 42, ist diese sogenannte Lösungsstrategie.

Ne, über den Namen könnte man streiten, das ist der vierte, wenn man von oben guckt, ne, der vierte Teil, von dem wir glauben, dass es immer noch für alle, für alle Stakeholder interessant ist.

Nachdem ich erklärt habe, was ist das Problem, also die Aufgabenstellung, ne, komme ich dann ganz schnell zur Lösungsstrategie und ähm nachdem du jetzt Point of Interest gefragt hast, bin ich fast der Meinung, wir könnten als Untertitel Point of Interest da drunter schreiben.

Ne, My Take ist, da stehen die Sachen drin, die besonders sind, die speziell sind, die alle Leute wissen sollten.

Mhm.

Ne, das können bestimmte Technologien sein, die exotisch sind, das können Randbedingungen, so technische Dinge sein, die aus der Historie halt so sind, aber wo ich der Meinung bin, die sind für alle wichtig.

Ne, das können ganz kleine sein, ne, also irgendeine kleine Library, die wahnsinnswichtige Arbeit für dich erledigt oder manchmal sind es auch ganz teure Dinge.

Also Management hat entschieden, wir kaufen dieses teure Zeug, ne, und dann möchte halt Management auch, dass das irgendwie gebührend Erwähnung findet oder Ja, ja, ja.

Na, oder ja, also diese ähm längerfristig gültigen Entscheidungen oder ähm Sachverhalte, die halt wichtig sind.

Ja, und wir haben es, wie gesagt, Lösungsstrategie genannt.

Ähm, ne, die Zielsetzung ist, dass es kurz, ne, also ein kurzer Einblick.

Ja, ja.

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

Ja, ja.

Ah, okay, ja, so habe ich es eigentlich auch nie gesehen, aber genau, da könnten wir es eigentlich schon.

Ja, ist ein Ja, wenn wir hier fertig sind, muss ich Peter anrufen.

Weil wir gerade, ja, okay, vielleicht greife ich vor, ne, weil wir nämlich gerade eben in der Finalisierung von Version 9 sind.

Ja.

Ja, wo ich glaube, außer uns kaum jemand erkennt, dass es einen Unterschied zur Version 8 gibt, aber so ein bisschen ne, Wording Pflege haben wir betrieben und wir möchten halt auch Konsistenz dieser Schrankfächer haben, ne, Kompatibilität und ne, also sicherstellen, darum.

Aber so ein Untertitel Points of Interest unter Lösungsstrategie, das kann ich mir gut vorstellen.

Ja, also ich meine, als ich es zum ersten Mal gelesen habe, da ist mir auch direkt, also das war noch bei einem meiner ersten Arbeitgeber, äh da gab es so ein System, da mussten die abgeben an anderen Dienstleister und dann haben die immer gesagt, die werden niemals zum Laufen bekommen, niemals und die hatten Recht gehabt, also die hatten ein Jahr darum gefackelt und es gab kein neues Release, gar nichts.

Also weil halt nichts funktioniert und die haben gesagt, das liegt daran, dass hier gab es Zeitdruck, da gab es Zeitdruck, da gab es Zeitdruck, da haben wir gesagt, niemals, haben sie gesagt, doch, dann gesagt, die einzige Möglichkeit ist folgende Lösung, die ist aber völlig irre, weil fatale Konsequenzen, egal machen, ja, und das hat sich natürlich so akkumuliert und es war, das ist in der Codebase nicht so wirklich ersichtlich, also ist nicht so ganz klar, wieso jetzt unter der Haube jetzt zur Laufzeit irgendwelche Sachen ausgetauscht werden und so weiter.

Und da muss ich immer, wie gesagt, genau, das sind so diese drei Points of Interest, dann dann hätten die vielleicht ein halbes Jahr gebraucht, um zu sagen, jemand anderes.

Ja, jetzt sagen halt könnten Menschen sagen, ja, aber das sind doch typische Architecture Decisions, ne, du als Decision Record irgendwo ablegst.

Dann das kaufe ich nicht, weil es Architecture Decisions in der Regel ganz viele gibt, also eher 100, aber Points of Interest gibt's nur drei bis zehn.

Genau.

Ja.

Und zehn ist schon viel.

Ja.

Ne, und so diese kleine Handvoll ganz wesentliche, meinetwegen verweise ich dann auf die entsprechenden ADRs, kann ich machen, ne, aber das finde ich ist Dienst an den Stakeholdern, weil die halt sofort einen Einstieg finden und sagen, so, was ist denn das allerwichtigste hier.

Genau, genau.

Also ich meine, ich ja, also wenn ich jetzt an hier einen äh einen guten Bekannten von uns, auch der beim ISQB sehr busy ist, ne, wenn ich an Projekt denke, wo er involviert, also wo er sozusagen der Head of Architecture war, da gab's 500 ADRs oder so übers ganze Projekt.

Ja.

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

Gernot: Ja.

Gernot: Ah, eins wollte ich noch rein, also weil es gab ja, es gab gab kaum große Veränderung, aber es gab ja schon nebenwürdig.

Gernot: gab's schon so ein paar Veränderungen, ähm.

Gernot: Im Grunde ähm wirklich Kleinkram, ne, dass wir als Aspekt orientierte Programmierung in Java, ne, mit Aspect J und ne, als Spring dann angefangen, jetzt sowas auch unter der Haube zu verwenden, da haben wir gemerkt, hm, bei uns gibt's eine Sektion, die heißt Aspekte und plötzlich glauben die Leute, das ist Aspekt orientierte Programmierung, ich kann 42 nicht nehmen, weil ich mache das ja nicht und dann.

Gernot: haben wir halt, ich will nicht sagen panisch, aber ganz schnell gesagt, wir brauchen ein neues Wort dafür.

Ja, ja.

Ja, für diese querschnittlichen Themen, ja, querschnittliche Aspekte haben wir dann ersetzt durch querschnittliche Konzepte.

Ja.

Da kannst du jetzt, du du grinst, ne, das ist ja, das ist inhaltlich immer noch genau das gleiche wie vorher, aber das Wording geklärt.

Words matter, ja, ja.

Und ähm das ist auch schon sehr lange, dass diese Lösungsstrategie dazu gekommen ist, aber die ist halt mal dazu gekommen.

Ja.

Gernot: Wir haben diese Querschnittskonzepte von der Priorisierung her ganz früher eher klein gehalten, ne, da war uns eher wichtig, macht den Grundriss die Bausteinsicht, ne, bring die in den Vordergrund.

Das sehe ich heute nach paar Jahren Erfahrung differenzierter, ne, ich bin mittlerweile der Meinung, die Konzepte sind oftmals fast wichtiger als der Grundriss.

Mhm.

Also weil halt gerade im Sinne von Services oder Self Content System, die Grundrisse oft viel kleiner geworden sind, aber so strukturell haben wir hohe Konsistenz schon ganz von Anfang an.

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

Mhm.

Gernot: Entscheidung war immer dabei, technische Schulden, Risiken bin ich mir nicht, weiß ich nicht, was ganz am Anfang dabei war, aber das spielt ja letztlich auch keine Rolle, ne?

Du hast jetzt einen Platz dafür, Ja.

Ja.

der auch nur relativ selten verwendet wird.

Und dann ignorieren schon eher Leute und pennen ihre technischen Schulden anders, wenn überhaupt.

Ja, ja, ja.

Der Risiken, ich muss sagen, also Anekdote, ne, waren wir mit Peter Hushka, kannst dich ja schon erinnern, waren wir in Frankfurt beim Inder und dann dann hatte ich ihn auch mal irgendwie, ich hatte eine Diskussion mit ihm über Risiken und er hat ja auch bei der dieses Buch mal mindestens übersetzt, ne?

Das ist ja sozusagen Mr.

genau, ist ja Mr.

Risiken sozusagen.

Ja, schon.

Und äh und dann hat er irgendwie zu mir gesagt, also mit diesen Risiken, das kapiert eh keiner.

Also ganz wenige.

Ja, das fand ich ganz interessant, ja.

Alright, genau, vielleicht so zum Abschluss, du hast ja schon mal so ein bisschen mit LLM angekündigt, ähm, wo geht's denn hin?

42, was sind so die Ideen?

Wir haben 2023 das 42 Qualitätsmodell.

Gernot: Dazu gefügt, dass Qualitätsanforderungen sind ja eher Anforderungsthema, ja, sie spielen halt für uns in der Architektur eine ganz prägende Rolle, weil ich darauf wichtige Entscheidungen basiere und da gab's irgendwie zu wenig öffentlich sichtbare, ja, kostenfreie Informationen, also habe ich einfach gesagt, so, das passt gut in das 42.

Das dazu gekommen, wir verlinken es übrigens auch in den Shownotes, weil wir haben eine ganze Episode dazu, ne?

Ja.

Ähm, aber, ja, auch da merke ich halt Akzeptanz und es gibt so ein bisschen andere Bedürfnisse und in den Bereich wird sich noch ein bisschen was tun.

Jetzt gerade frisch dazu gekommen sind Qualitätsstandards, ne, so dass ich auch über Qualitätsstandards in dieses Q42 einsteigen kann.

Ihr könnt jetzt also sagen, so, ne, NIST 853, irgendwelche Dinge, so brauche ich, dann klicke ich da drauf und dann sehe ich, okay, folgende Attribute sind betroffen und so kann ich die, könnte ich die beschreiben.

Ach so, okay, ja.

Oh, nice, also auch so, also ich sag mal, wenn ich jetzt an, ich denke jetzt an Dora, also Digital Operations Resilience Act.

Ja.

Gernot: also Dorametriken sind Sven: Nee, die Dorametriken meine ich jetzt so, ich meine hier so, ja, das ist halt der Plan, also und wir haben halt, ich habe eine neue Metaklasse in diesem Q42 eingeführt, okay, okay, so dass ich jetzt ziemlich einfach auch Pull Request annehmen kann, wenn du sagst, dieser Dora Standard interessiert mich, ne, dann mach halt eine kurze Beschreibung und ich kann dann diese 170 bestehenden Eigenschaften einfach nur alle taggen und sagen so, ne, hier folgende sieben gehören zu diesem Bla Standard.

Gernot: Die sind sowieso.

unbekannt]: Äh.

Gernot: ISO 27001 Sven: ISO 26262, keine Ahnung, da gibt's halt ganz viele von.

Ja, ja, ja, ja, not bad, ja, und also das habe ich als Frage bekommen, ne, und habe dann selber irgendwie gedacht, na, das ist eine coole Idee und es ist halt einfach umzusetzen, weil ich, weil wir den Content sowieso haben.

Gernot: Ja, ja, ja, ja.

Sven: Das ist das eine, ne, da wird's weitergehen, da haben wir jemand dran, ein Contributor, Fabian Angst, der sich ein bisschen auch mit usability rumschlägt, hat so eine Grafenstruktur gemacht, dass man halt über einen Grafen einsteigen kann, ja, da arbeiten wir noch dran.

Sven: Und ähm ja, dieses LLM Thema, da experimentieren ja nicht nur wir jetzt INNOQ-seitig oder Peter und ich, wie kann ich halt ne, ähm den Content eines A42 Schrankes einem LLM geben oder wie kann ich vielleicht den A42 Content und ein Repo kombinieren, so dass wir einige Architekturfragen leichter beantwortet bekommen.

Sven: Und beispielsweise ähm die LLM, die KI Fragen, so hier sind 300 ADRs, ja, was haben wir denn zum Thema Caching entschieden?

Ja, und Caching, das kann ich auch temporäres Zwischenspeichern nennen, ne, so ein LLM ist halt ziemlich gut in der Lage, auch über unterschiedliche Ausprägung von Begriffen hinweg dir zu sagen, hier folgende fünf ADRs beziehen sich auf dieses große Thema.

Mhm, genau.

Und das ist, ich mag diesen Begriff Gamechanger, den versuche ich sporadisch zu verwenden, das ist für mich ein Gamechanger.

Ne, weil ich selbst in kleineren Systemen gemerkt habe, wie schnell ich von 50 ADRs vergessen habe, was ist gerade aktuell, was haben wir entschieden, was war da noch mal das Detail?

Mhm.

Und eine rein Textbasierte Suche kriegt das nicht hin, die die schafft's nicht.

Ja, und mein Ausweg war dann immer, ich gehe den Sven fragen oder ich gehe jemand anders Mensch fragen, und da ist ein LLM schon ziemlich gut.

Gernot: Ja.

Sven: Ja, also ich habe jetzt so, ich meine, wir dokumentieren hauptsächlich in Confluence, aber leider, ne, man könnte natürlich sagen, ja, warum macht man kein Markdown direkt am Code und so weiter, Gründe, accessibility, bla bla bla bla bla.

Aber jetzt denke ich mir auch, wenn ich praktisch mein A42 auch direkt, also ist so mein Gedanke, ne, in Zukunft immer ist immer Teil von meiner Codebase, dann habe ich egal in welcher ich bin, ich habe ein Coding Agent, der hat als Kontext nicht nur den Code, sondern auch mein A42 und dann kann ich den ja ganz anders, da kann ich dem ganz andere Dinge sagen, ja, und ich muss jetzt irgendwie alles lang und breit erklären, und ich sag, hier ist ein ADR, da ist ein Konzept, das haben wir übrigens da schon so umgesetzt und jetzt bitte.

Gernot: Da verlassen wir bei A42 halt schnell den Template Gedanken und kommen halt zum Prozess oder zum Vorgehen.

Mhm.

Ich möchte aber auch als mal Open Source Provider Contributor gerne in der Lage sein, so Fragen zu beantworten.

Ja, deswegen investieren wir da auch ein bisschen Zeit.

Ja, das ist halt in der LLM Szene ist nichts fertig, sondern es ist halt alles so im Fluss, aber da glaube ich, werden wir auch noch ein paar Blogposts zu schreiben oder möglicherweise auch ein paar Beispiele vorbereiten, wie kann ich jetzt konkret dieses A42 Universum mit LLM Hilfe vielleicht geschickter einsetzen, als wir das bisher gemacht haben, oder ein bisschen manueller arbeiten.

Sven: Ja, genau, genau, ja, ja, genau, genau, ja.

Ja, ich denke, da gibt's auf jeden Fall.

Also, ich würde mal sagen, es gibt einen Haufen interessante Ideen, man muss halt natürlich ausprobieren, weil ich meine Ideen, man glaubt immer, ja, es dann wird alles gut und dann funktioniert's doch zu, aber ich denke, ausprobieren ist auf jeden Fall, ja.

Gernot: Gut, er hat gerade nur was getriggert, ne, weil du gesagt hast, ist kein Template, es ist kein Vorgehensmodell, für mich ist tatsächlich ist ja doch so ein bisschen Vorgehensmodell, gebe ich zu, aber das ist vielleicht Topic von other day.

Sven: Das ist doch ein gutes Stichwort, lass uns doch daraus gerne noch mal eine Folge machen, das Vorgehen dahinter.

Tatsächlich hat das ja echte Konsequenzen gehabt auf so Vorgehen und selbst dieser QB und so weiter, das ist schon ein bisschen davon beeinflusst.

Genau, genau.

Gernot: Alright, dann Gernot.

Sven: Ich bedanke mich, ich bedanke mich für das nette Gespräch.

Genau, bis zum nächsten Mal.

Bis zum nächsten Mal.

Auch euch vielen Dank.

unbekannt]: Ciao, ciao.