"Software Architecture Matters" mit Stefan Tilkov

Hallo und herzlich willkommen bei der Programmierbar, liebe Hörer*innen. Wir haben heute wieder einen Gast in echt vor uns sitzen, was wir immer sehr schön finden, nämlich im Rahmen unseres Meetups, das heute Abend noch stattfindet. Und im Vorfeld nehmen wir diesen Podcast auf zum gleichen Thema Software Architektur Matter. Darüber sprechen wir heute. Unser Gast ist Stefan Tielkow. Hallo zusammen, freut. Mich bei euch zu sein. Stefan, wer unseren Podcast schon sehr lange hört, der könnte deine Stimme auch schon kennen, denn du warst vor drei Jahren circa schon mal Gast bei uns. Wir haben schon mal über Architektur ein bisschen gesprochen und du warst damals auch schon für ein Meetup eingeplant? Ich meine ja. Ich glaube, wir haben da nur den Podcast gemacht, weil zumindest damals waren vielleicht virtuelle Meetups noch kein Thema. Und jetzt stellen wir fest, wir haben sie auch gar nicht mehr so gerne. Also merke ich zumindest, ich freue mich hier zu sein. Das stimmt ja. Das war wirklich unser letztes angekündigtes Meetup vor Corona, das dann durch Corona ausgefallen ist. Ja, drei Jahre später haben wir es geschafft. Von daher sehr, sehr cool, dass du heute die Zeit gefunden hast, hier vorbeizukommen und mit uns zum einen diesen Podcast aufzunehmen und zum Zweiten nachher das Meetup zu bestreiten. Magst du einfach von dir selbst noch mal zwei, drei Sätze erklären, wer du bist, was du so in deinem Arbeitsalltag machst, warum du gerne über Architektur sprichst? Mach ich gerne. Ich komme von einer Firma namens Indocue. Wir sind so eine Softwareberatung Softwareentwicklungsfirma und dort bin ich einer der Mitgründer und habe viele Jahre meines Lebens mit Softwareentwicklung und Softwarearchitektur verbracht. Zum Entwickeln komme ich jetzt kaum noch, leider. Das ist mehr so recreational Programming, was ich auch mache, aber nicht mehr in ernsthaften Projekten. Aber ich rede noch viel und oft über Architektur mit Kunden, Kundinnen, diskutiere oft darüber, was richtige Ansätze sind, bin viel unterwegs auf Konferenzen, mache Schulungen und Workshops und solche Dinge und richte Schaden an, den meine armen Kolleginnen und Kollegen dann ausbügeln müssen, wenn sie die eigentlichen Projekte dann durchführen. Genau. Und ich bin sehr interessiert daran, dass Dinge gut werden. Das ist aus meiner Sicht immer das zentrale Ziel und da beschäftigt mich Architektur einfach schon sehr, sehr lang. Und ich glaube, dass das ein wichtiges Thema ist, das man braucht, wenn man gute Sachen bauen möchte. Würdest du sagen, man kann nur ein richtig guter Architekt werden, wenn man in so einer Rolle ist, wo man sehr, sehr viele Projekte live sieht? Oder kriegt man das auch auf einem theoretischen Weg irgendwie hin? Also braucht es wirklich dieses Reallife? Du hast sehr viele Einblicke in sehr viele Projekte bekommen, so in deiner Laufbahn. Ist das ein wichtiger Faktor oder kann man das recht theoretisch auch abhandeln? Also man kann natürlich auch theoretisch da was machen. Also es gibt gute Bücher und Schulungen und Materialien und mittlerweile massenweise frei verfügbare Vorträge und Podcasts und alles mögliche zu dem Thema. Also man kann natürlich eine Menge theoretisches Wissen aufbauen. Wie bei allem anderen hilft es natürlich praktische Erfahrungen zu sammeln und je mehr, desto besser. Das ist immer so ein bisschen, weiß nicht, so ein leichter Gatekeeper-Verdacht, wenn man sagt: „Du musst mindestens 15 Jahre Berufserfahrung haben und sieben verschiedene Projekte. Mindestens verschiedene Quellen Code geschrieben haben. Ja, das finde ich jetzt auch irgendwie affig. Auf der anderen Seite fände ich es auch ein bisschen seltsam, wenn jemand sein Studium abschließt, sein oder ihr Studium abschließt, einen Kurs macht und danach Senior Architekt ist. Klingt irgendwie auch seltsam. Also so ein bisschen Erfahrung erwartet man, glaube ich schon. Passiert aber in der Realität. Also ist mir sogar passiert. Ich finde, in der Deutschen Bank, wo ich da war, bin ich, glaube ich, nach meinem Studium, wurde ich wegen der Restrukturierung auf einmal gab es für mein Thema keine direkte Linie mehr, wurde ich auf einmal IT-Architekt, weil mein Chef dann den Architekturbereich verantwortet hat. Und irgendwann hieß es dann nach einem halben Jahr, du bist ja Architekt, dann musst du jetzt auch … Also ich habe zwar ein anderes Projekt gemacht, aber dann mach doch hier noch mal Architekturaufgaben. Und eigentlich …. Das ist vielleicht dann eine begriffliche Verwirrung. Ich glaube, ich kenne so einen Begriff, der nennt sich Solution Architect, den kenne ich aus der Branche, damit meinen Unternehmen oft Leute, die nicht selbst Software bauen, sondern die das Bauen von Software überwachen. Also du bist ein großes Telekommunikationsunternehmen und hast Solution Architekten und die steuern den externen Dienstleister, der irgendwo irgendwas macht. Man kann Wörter ja für alles Mögliche benutzen und das ist natürlich auch eine legitime Verwendung. Dieses Wort ist aber überhaupt nicht das, was ich meine oder was wir wahrscheinlich meinen, wenn wir von Architektur oder Architekten oder Architektin sprechen, dann meint man, glaube ich, eher eine bestimmte Art von Aufgabe, eine bestimmte Rolle, die man vielleicht ausschließlich oder auch ausübt und wahrscheinlich nicht etwas, das man durch, wie gesagt, also ein Kurs oder ein Zertifikat oder so jetzt einfach hat, wenn man das gemacht hat. Weil das war eigentlich genau die Begrifflichkeit, die ich dann noch damals innehatte, mit Solution Architect. Aber in dem Fall war ja schon die Aufgabe eines Solution Architects, sagen wir mal, sich zumindest systemisch zu überlegen, wie sollen die Systeme miteinander interagieren? Welche Infrastrukturkomponenten? Das ist ja irgendwie schon sehr im Detail, aber nicht vielleicht so sehr: Wie ist der Code strukturiert, aber auch das, auch das wurde irgendwie erwartet. Nach welchem Architekturansatz soll denn die neue iOS App gebaut werden? Aber grundsätzlich eher so systemisch. Brauchen wir ein Caching Layer? Wenn ja, welcher? Solche Dinge zu entscheiden, wo man sich dann fragt … Wie ich damals gefragt habe: Ich habe es noch nie selbst gemacht. Wie soll ich es denn entscheiden? Ist es wichtig, dass ihr mich das fragt? Ja, ist vielleicht ein grundsätzliches Problem. Ich glaube, dass es immer dann gefährlich ist, wenn die Distanz zwischen der eigentlichen Entwicklung und der Architekturarbeit zu groß wird. Das perfekte Modell, das Idealmodell ist aus meiner Sicht, wenn im Team Architekturarbeit einfach mitgemacht wird. Das finde ich eigentlich das Beste. Das ist ein kleines Team, fünf, sechs Leute und da gibt es natürlich Architekturaufgaben, aber da muss nicht eine Person Architektin oder Architekt sein, sondern das ist einfach vielleicht auch mal die Person und mal die Person. Ja, da geht es vielleicht mehr Daten, da geht es mehr Oberfläche, da geht es mehr Netzwerk. Und dann gibt es halt unterschiedliche Leute, die die wesentlichen wichtigen Entscheidungen treffen. Und dann kann man vielleicht sagen, die haben da jetzt architekturrelevante Sachen gemacht. Und es ist halt so, je größer das wird, umso größer, behaupte ich jetzt mal, werden die Vorteile und umso eher akzeptiert man die Nachteile, die es hat, das jetzt zu einer expliziten Rolle zu machen und zu sagen: Das ist jetzt die eine Person. Wir haben so viele Leute, die sonst mitreden, wir kriegen nicht immer alle 35 in einen Raum und bewegen die dazu, dass die sich auf etwas einigen. Das schaffen wir nicht. Wir brauchen jetzt mal eine Person, die sich darum kümmert und die den Job hat, diese Entscheidung entweder zu treffen oder herbeizuführen. Man muss ja als Architekt oder Architektin auch nicht alles selbst machen. Man trägt aber irgendwie dann die Verantwortung, dass diese Sachen irgendwie schlüssig entschieden werden. Und ich glaube, das kann man eben auch übertreiben. Man kann das in einem noch guten Modell machen, wo das allen gefällt, wo das alle auch akzeptieren als etwas, was man halt machen muss, wo auch keiner moosert. Man kann das aber auch auf einer Ebene machen, wo für irgendein zentrales Architektur Team im Unternehmen für alle möglichen Entscheidungen verantwortlich ist, die ganz, ganz viele Leute ausbaden müssen, die dann das Gefühl haben, das hat nichts mit ihren eigenen Problemen zu tun. Also da hat irgendjemand irgendwo in irgendeinem Elfenbeinturm irgendeine Entscheidung getroffen, aber mein konkretes Problem passt überhaupt nicht dazu. Das ist tatsächlich ein echt heftiges Problem in ganz vielen Unternehmen. Und das ist auch, glaube ich, der Grund, warum ganz oft schlechte Architekturen in der Praxis dann da sind, weil es einfach die sind nicht … Das ist die erste, für mich immer wichtigste Weisheit. So eine Architektur kann nicht gut oder schlecht sein, sondern die ist halt kontextabhängig. Die muss zum Problem passen, die muss zu den Qualitätsanforderungen passen. Du willst irgendwas damit erreichen. Wenn du nicht sagen kannst, warum diese Architektur für dieses Problem jetzt die richtige ist, dann ist das keine gute Architektur. Dann ist das schon erledigt. Das kann nicht funktionieren. Erlebst du denn in der Praxis auch das Gegenteil? Gerade hast du gesagt, das ist dann eher schwierig ist, die Akzeptanz oder sitzt irgendeiner und gibt die Architektur vor. Gibt es auch die Teams, wo die Leute sagen, es ist richtig, also es ist Feiern, jemanden zu haben, der die Architektur vorgibt, weil sie das alles nachvollziehen können und happy sind, diese Vorgaben in Anführungsstrichen zu bekommen? Na also, das ist vielleicht ein bisschen übertrieben. Ich glaube, das hängt mit Developer-Mentalität zusammen. Man möchte ja Dinge schon irgendwie gerne selbst machen und hat am meisten Spaß, wenn man selbst die Entscheidung getroffen hat, glaube ich einfach so. Das heißt, dass man jetzt jubelt, weiß ich nicht. Was ich glaube gemerkt zu haben in den letzten Jahren, auch in den Architekturen, die wir so mitverantwortlich … Also wir sind oft in so einem Mischmodell. Wir machen oft Architekturarbeit, aber auch Entwicklung. Oft dann nicht alleine. Also es sind oft so große Projekte, wo irgendwie, weiß ich auch nicht, 50 oder 100 Leute involviert sind. Die kommen dann nicht alle von uns. Unsere ganze Firma hat 180 Leute oder so. Das heißt, wir sind vielleicht mit zehn oder 20, sage ich mal, 25 Leuten bei irgendeinem Kunden. Und wenn es jetzt so ein großes Projekt ist, dann machen wir Architekturarbeit und auch ein bisschen Entwicklung. Und das sind aber auch andere. Da sind Teams von anderen Dienstleistern, da sind Teams vom Kunden und die müssen sich alle irgendwie verstehen und irgendwie müssen die gemeinsam was nach vorne bringen. Und das, was – lange Rede, habe ich lange ausgeholt –, was ich glaube, was sehr gut funktioniert, ist, wenn man wenige Dinge festlegt, und zwar wenige Dinge, die man auch durchaus strikt durchsetzt, festlegt mit dem Ziel, dass man möglichst viele Dinge nicht festlegen muss, sondern den Teams überlassen kann. Das ist wie so ein Geben und Nehmen. Wir machen alle zusammen einen Deal. Wir legen ein paar Regeln fest, ein paar brauchen wir. Da nützt es nichts, wenn alle was anderes machen. Das macht nur Ärger. Also lass uns ein paar Sachen festlegen, aber wirklich nur die, die wir unbedingt müssen. Nur so wenige Regeln oder so viele Regeln wie unbedingt notwendig, an die halten wir uns dann auch. Und im Gegenzug gibt es große Freiheit innerhalb dieses Rahmens. Das ist für mich die erste Frage, die mich da direkt interessiert. Wie definiert man diese Grundregeln oder wie? Und vielleicht zu welchem Zeitpunkt definiert man sie? Sind das Dinge, dieman, dass man das komplett am Anfang macht? Und dann wie findet man raus, was ist genug Leitlinie, dass es ausreicht und die Leute sich darin frei bewegen können am Ende, dass es dann besser wird, wenn man es so grob macht? Oder wie sagt man, mittlerweile haben sich herauskristallisiert, dass ihr, dass ihr X Regeln einfach immer aufstellt. So der Grundsatz immer diese, das Grundgesetz sind zehn Regeln und dann je nach Kunde machen wir noch mal zwei, drei mehr, je nachdem, ob den Leuten das zutrauen, dass sie selbst entscheiden können oder wie findet man dieses Grundset und wann? Also zunächst mal ist das in gewisser Weise ja so eine ähnliche Frage wie die, oder man kann eine ähnliche Aussage treffen wie zu der Architekturfrage gerade. Auch das ist extrem kontextabhängig. Auf diese sehr berechtigte Frage gibt es nicht eine Antwort, die immer richtig ist, sondern in jeder Organisation wirst du das unterschiedlich machen. Da gibt es welche, die brauchen sehr strikte, dogmatische Regeln, weil sie vielleicht mit vielen externen Partnern zusammenarbeiten oder so. Und andere, die sind eingeschworene Teams, die sich super verstehen und schon ganz viel zusammen gemacht haben, die brauchen viel weniger. Das ist gar nicht nötig, so viel festzulegen. Also auch das ist sehr, sehr kontextabhängig. Das andere, was aus meiner Sicht wichtig ist, ist, dass man auch da das richtige Maß findet, wie viel man vorab machen will. Also man muss ein bisschen was vorab machen. Denn ihr euch vorstellt, also gerade in so großen Projekten, das ist so mein Hauptkontext, also wir machen nicht nur große, aber viele, in solchen großen Projekten, da kannst du nicht am ersten Tag 25 Leute loslaufen lassen. Was sollen die denn machen? Also du kannst in einem Raum zusammenholen und eine motivierende Rede halten, aber dann, da gehen die aus diesem Raum raus: Was machen die denn jetzt? Das heißt, da musste zumindest mal gesagt haben: Also was wir hier bauen, hat insgesamt diesen Zweck und das machen wir jetzt mit folgenden sieben Teil-Subsystemen oder so. Das hat Charmeb schon mal gesagt… Da hat ja schon jemand in einer Architektur Entscheidung getroffen, nämlich dass es sieben sind und nicht 23 oder fünf. Irgendjemand hat das geschnitten, hat gesagt: „So müssen wir das aufteilen. Und dabei hat er vielleicht vertikale Schnitte gemacht, also gesagt, das sind verschiedene Funktionsbereiche, oder hat horizontale Schnitte gemacht und gesagt: „Das ist das Backend, das ist das Frontend, oder das ist die Datenbank, das ist die Logik, das ist das UI, das ist die Dialogsteuer und keine Ahnung was auch immer. Das sind ja alles Entscheidungen, die irgendjemand da getroffen hat. Und jetzt kann man das zu weit treiben und versuchen, alles perfekt zu machen. Und dann geht man erst mal … Also ich kann mich daran sehr gut … So was habe ich früher gemacht, lange her, 20 Jahre her, 25. Da haben wir genau so was probiert, und gesagt: „Jetzt machen wir es mal richtig, jetzt schließen wir uns mal ein. Und dann hat ein Architektur Team von sieben Personen ein dreiviertel Jahr lang Architekturarbeit gemacht. Und das mit der Erfahrung, wenn man das mal gemacht hat, weiß man, dass das eine echt bescheuerte Idee ist, die man nicht wiederholen sollte, weil du machst dann halt irgendwas, das hat überhaupt keinen Realitätscheck hinter sich, gerade wenn es was Neues ist. Also viel besser ist, du machst zwei Wochen und wirfst das mal raus und guckst mal, was passiert in den nächsten drei Sprints oder so. Und dann entscheidest du, okay, das war blöd, das schmeißt man weg. Da fehlt uns eine Regel, da müssen wir uns irgendwas ausdenken. Da probieren wir in den nächsten vier Wochen mal das aus. Und wenn das gut geklappt hat, dann machen wir das zu einer neuen Regel. Also eher so: Wir machen so viel wie nötig, damit wir loslegen können und danach stellen wir das immer wieder in Frage. Also dieses immer wieder in Frage stellen ist für mich ein ganz zentrales Element bei Architekturarbeit. Man bewertet bei Architekturen immer. Es gibt so externe Architekturbewertung. Also jemand hört diesen Podcast, sagt: „Der Mensch, der hört sich aber an, was ist der, wovon er davon redet, den fragen wir jetzt mal an, ob die nicht einen Architekturreview bei uns machen können. Das machen wir auch. Dann bewertet man sozusagen eine Architektur extern. Aber Architekturbewertung ist auch, wenn ich meine eigene Architektur bewerte, nachdem ich sie drei Monate lang ausprobiert habe im Projekt. Und dann sage ich: „Okay, ich habe gedacht, Microservices sind total geil, die muss ich unbedingt haben. Und jetzt stelle ich fest, es macht nur Ärger, schmeiß ich den Quatsch wieder raus. Man muss irgendwie anpassen und lernen aus dem, was man da macht. Und das ist vielleicht auch so ein Vorwurf, den man Architekten, Architekten oft machen kann, oder zu Recht oder zu Unrecht – lasse ich mal dahingestellt –, dass sie zu wenig auf das Feedback hören, das von den entwickelnden Personen kommt. Weil wenn die immer kämpfen müssen wegen dieser Architektur, dann stimmt da irgendwas nicht. Also entweder stimmt es Skill-mäßig irgendwas nicht oder die Architektur ist halt die falsche für dieses konkrete Problem. Wenn du aber trotzdem jetzt ja gelernt hast, sechs Monate einschließen ist nicht die Lösung. Vielleicht zumindest trotzdem mal bei größeren Projekten vorz überlegen, was sind die groben Richtlinien? Ist auf jeden Fall der richtige Weg? Und hast du gesagt okay, ich kann das jetzt entweder schneiden nach vertikalen oder horizontalen wäre eine Option, also funktional oder nach irgendwie nach technischen Layern. So sind also was sind die, wenn ihr euch zwei Wochen, drei Wochen vorher hinsetzt? Was sind die Komponenten, die euch anschaut? Denkt ihr euch, denkt ihr vertikal und horizontal oder denkt ihr auch, also welche sind die Aspekte, die man sich vorher irgendwie anschauen sollte? Ich kann mir vorstellen, dass man einen kleinen Technologie-Stack vielleicht auch anhand der Firma irgendwie eher gegeben hat. Was für Technologien werden irgendwo eingesetzt? Aber was sind Bereiche, die man sich vielleicht vorher anschauen sollte, über die man sich Gedanken machen sollte? Also wir haben natürlich schon im Laufe der Jahre irgendwie so eine Art, ich will nicht sagen Methode etabliert, aber man hat so gewisse Sachen, die man so oder so ähnlich immer wieder macht. Eine Sache, die bei uns gut funktioniert, die ich auch mittlerweile bei vielen anderen gesehen habe, ist, dass man mit verschiedenen Architekturperspektiven arbeitet. Wir unterscheiden immer drei: Domänenarchitektur, Makroarchitektur, Mikroarchitektur. Das ist jetzt nichts aus der Schublade, sondern das ist einfach so ein Denkmodell. Domänenarchitektur ist der fachliche Schnitt. Also ich baue irgendwas und das versuche ich fachlich zu zerlegen. Dabei spielt die Technik kaum eine Rolle. Da geht es wirklich nur darum, wenn ich auf oberster Ebene ein fachliches Box-Line-Diagramm malen würde, welche fünf oder sieben oder 13 Kisten wären da? Dann habe ich vielleicht das Accounting System und ich habe das das Drucksystem und ich habe das Bestellsystem oder so. Das sind die drei Sachen, die zusammenwirken, meinen Lettershop zu bauen. Keine Ahnung, was auch immer. Das ist Domänenarchitektur. Und das ist eine sehr interessante Sache, die ist eher fachlich motiviert. Da brauchst du keine Leute und keine Kompetenz, die jetzt extrem technische Details irgendeines Frameworks oder irgendeiner Programmiersprache hat. Aber du brauchst sehr wohl Software Engineering Kompetenz, weil das Ziel dabei ist, Klötze zu schaffen, die möglichst lose gekoppelt sind. Das ist so eine, die lose Kopplung ist eines der Grundziele bei Architekturarbeit. Also ich will Dinge enkoppeln, die zusammengehören und lose koppeln, die nicht zusammengehören. Und dann komme ich mit so einem schicken Bild raus. Dazu brauche ich diese Software Engineering Kompetenz. Ich brauche aber auch fachliche Kompetenz, weil ich habe ja keine Ahnung, wenn ich jetzt einen Kreditgenehmigungsprozess IT-mäßig unterstützen sollte, was weiß ich, von Kreditgenehmigung, außer dass ich selber schon mal Kredite beantragt habe. Aber wie das in der Bank funktioniert, also ich brauche irgendjemanden, der das weiß. Das kann vielleicht ein ITler sein, kann aber auch jemand von der Fachabteilung sein. Und diese beiden Kompetenzen zusammenführen dazu, dass ich am Ende eine gute Domänenarchitektur habe. Eine Sache, die in den letzten Jahren immer klarer geworden ist, ist, dass dieser fachliche Schnitt auch enorme Auswirkungen auf die Teamzusammensetzung und die Teamorganisation später hat. Das gibt so einen Moment sehr populäres Buch, das nennt sich Team Topologie. Können wir sicherlich schon auspacken. Sehr empfehlenswert für eigentlich alle, die einen größeren Stil Software bauen. Und da ist es eben auch als eine der Ideen drin, dass man eben idealerweise solche interdisziplinären crossfunktionalen Teams hat, die so einen Bereich möglichst verantworten. Das ist so ein Baustein. Das war die erste Perspektive. Die zweite Perspektive ist die Makroarchitektur. Also wenn ich jetzt sieben Klötze habe, dann gibt es gewisse Dinge, die will ich oder muss ich übergreifend entscheiden. Zum Beispiel, wie werden denn die User Interfaces dieser sieben Klötze, wenn die eigene haben, integriert? Oder wie kommunizieren die Netzwerk-mäßig oder wie machen die OPs, also Deployment und Monitoring und Logging und Metrics und keine Ahnung, was ich so aus dem Betriebsaspekt brauche. Solche Aspekte, die irgendwas mit Integration oder allgemeinem Betrieb zu tun haben, die will ich in der Regel übergreifend festlegen, weil die ja alle zusammenspielen sollen. Das ist das, wo ich gerade von diesen wenigen Regeln vor allem gesprochen habe. Da will ich jetzt den Leuten, die später so ein Ding implementieren, möglichst wenig reinreden. Aber so ein bisschen Vorgaben will ich machen, wo es vielleicht Sinn ergibt. Und dann gibt es als letztes die Mikroarchitektur. Das ist jetzt sozusagen das, was in den individuellen Teilbereichen passiert. Und auch da macht man manchmal Architekturarbeit, manchmal sogar übergreifende Architekturarbeit und sagt: „Also wir legen jetzt einfach mal fest, weil diese Organisation braucht das, dass wir alles mit dieser Programmiersprache, diesen Bibliotheken, diesem Framework, dieser IdeeDiesen Kommandozeilentools, diesen Kommandosäulen-Tools, diesen Datenbanken … Also wir legen alles fest, obwohl es Mikroarchitektur ist. Das ist ein feiner, aber unglaublich wichtiger Unterschied. Wenn ich das festlege, dann mache ich das, damit alle einen Startpunkt haben und loslegen können. Aber ich kann das … Ich werde das weiterentwickeln. Also in zwei Jahren werde ich was anderes entscheiden. In fünf Jahren werde ich wieder was völlig anderes entscheiden, aber meine Software lebt meistens länger. Und dann müssen die Sachen, die mit der Mikroarchitektur Version 1 gebaut sind, zusammenspielen können mit den Sachen, die mit der Mikroarchitektur Version 3 gebaut sind. Das heißt, diese Makroarchitektur, die entwickelt sich mit einer anderen Geschwindigkeit als diese individuellen Mikroarchivelen, die gerade wild mit den Händen rum. Das können unsere Hörer und Hörerinnen natürlich nicht wahrnehmen. Aber dasDas ist etwas, was man ganz oft hat, wenn man eben langlebende Systeme hat, die sich Stück für Stück weiterentwickeln und weiter erneuern. Das ist auch etwas, was wir gelernt haben. Zu derselben Zeit, zu der ich diese – wir machen mal eben sieben Monate – Architekturprojekte gemacht habe, haben wir auch geglaubt, wir legen so eine Architektur fest und die gilt dann einfach für alles, denn die ist ja toll. Und dann stellst du fünf Jahre später fest: „Okay, ich habe jetzt zwölf Millionen Zeilen JavaScript Code, die kann ich aber alle nur on Block modernisieren. Also wenn ich da irgendwas austauschen will, dann immer für alles. Ich habe diesen riesigen monolithischen – Antivor überhaupt –, diesen großen monolithischen Block, den ich immer nur als Ganzes weiterentwickeln kann. Und all diese Ansätze, also Microservices, Self-Contain Systems, diese ganzen Ideen basieren eigentlich alle darauf, dass ich so kleinere Entscheidungs-Sphären schaffe. Also hier, das ist das eine Teil, das ist das andere Teil. Und das eine Teil, da kann ich jetzt in der Makroarchitektur eine Modernisierung schon machen, in dem anderen muss ich das noch nicht. Und trotzdem können die weiter miteinander sprechen, weil ich zum Beispiel die Schnittstellen oder die UI-Integration festgelegt habe. Das wäre so ein Beispiel. Ich glaube, wir sind da drauf gekommen, weil du mich vor ungefähr 20 Minuten gefragt hast, wie man sozusagen startet in so einem Ding. Und das habe ich auf der Meta-Ebene beantwortet. Das ist so eine Architekten-Marotte. Also in. Welchem Bereich man denken muss. Über diese Sachen. Denkt man nach. Das hast du schon beantwortet. Genau. Das heißt, wir würden in so einem Projekt, wenn man initial so was macht, würde man sagen: „Okay, lass uns mal ein bisschen workshopen, was man in diesem Domain Architekturbereich vielleicht schon hat, vielleicht schon weiß, vielleicht schon in der Vergangenheit gebaut hat, heute anders machen würde. Lass uns parallel dazu im Makroarchitekturbereich mal ein paar Sachen klären. Also haben wir hier überall Webfrontends oder machen wir Mobile Apps? Oder ist schon entschieden von irgendwem, dass das alles in einer bestimmten Cloud läuft oder so? Das sind so Makrosachen, die kann man auf den Tisch kriegen. Und Mikro hast du auch gerade schon gesagt, da gibt es dann vielleicht, vielleicht ist das schon irgendwas, sind alles PAP Experten oder die können alle super Java oder alle super C#. Dann kann man natürlich auch was anderes vorschlagen, aber in aller Regel tut man sich eher einen Gefallen, wenn man das halt nimmt. Da sage ich jetzt was ganz Gefährliches. Das ist ja letztendlich auch egal. So wahnsinnig wichtig ist das nicht. Also die anderen Sachen finde ich viel wichtiger. Ich finde die Domain Architektur viel, viel wichtiger als diese Mikroarchitektur Entscheidung. Das sind ja auch sehr von der Umgebung abhängig. Die Mikroarchitektur, wenn ich einen Haufen Java entwickle, macht es vielleicht auch Sinn, diese. Ressourcen zu nutzen. So ist das. Ich bin zum Beispiel persönlich, ich habe eine starke Meinung zu Programmiersprachen. Ich bin zum Beispiel extremer Fan einer wunderbaren Programmiersprache namens Closure, beste Programmiersprache der Welt. Super geil, finde ich ganz toll. Eigentlich finde ich, sollte man da drin programmieren. Aber wenn ich jetzt ein Team habe, das sich super mit C# auskennt und das total, also für eine völlig abfällige Idee hält, dann tue ich mir keinen Gefallen, wenn ich die jetzt zwinge, eine Programmiersprache zu benutzen, die sie nicht haben wollen, die sie blöd finden. Das weißt du ja jetzt schon, wie das ausgeht. Das geht auf jeden Fall schief. Dann ist die bessere Entscheidung, eine andere Programmiersprache zu nehmen. Also ich finde jetzt die Schab gar nicht so schrecklich. Das war nur ein Beispiel. Ja, bitte nicht mir vorhalten. Ich wollte nur sagen, dass diese Entscheidungen, die man da trifft, kann man vielleicht auch noch mal verallgemeinern in Architekturarbeit, diese Entscheidungen, die sind immer von ganz, ganz vielen Sachen beeinflusst. Und es gibt eigentlich nie so ein einfaches „Das ist gut und das ist schlecht, das ist besser und das ist weniger gut. Das ist super kompliziert, weil du eben all diese Faktoren mitberücksichtigen musst. Was habe ich denn für Leute? Was habe ich für Beauftragungsprozesse? Also wir machen manchmal in Architekturarbeit Diskussionen darüber, dass diese Architektur nur umsetzbar ist, wenn sich der Einkauf ändert, also der IT Einkauf des Kunden. Solange der IT Einkauf des Kunden immer den billigsten Anbieter mit den tollsten Sales Leuten in den besten Anzügen beauftragt, brauchen wir mit diesen anderen Sachen nicht anzufangen. Das hat gar keinen Sinn. Dann nimm lieber das Standard Produkt, das erledigt das dann. Und da brauchst du nicht gegen zu kämpfen, weil dieweil die anderen Sachen, die eben viel stärker da einen Strich durch die Rechnung machen. Also man trifft diese Entscheidung immer in so einer wilden Entscheidungs-Wolke aus ganz, ganz vielen technischen und nicht technischen Faktoren. Das ist aber vor allem jetzt bei besonders großen. Im kleinen ist das auch nett und macht auch Spaß und hat nichts mit Konzernpolitik zu tun. Das gibt es auch wieder. Zumindest, weil das mit auf dem Kleinen, darüber habe ich die ganze Zeit gedanklich sozusagen nachgedacht, so dieses, wenn man in etwas Bestehendes sehr Großes reinkommt, gibt es ja diese sehr vielen Beschränkungen, an denen man sich dann auch ein bisschen orientieren kann und daran sich viele Entscheidungen ableiten lassen. Sagen wir jetzt aber mal gemäß dem Fall, es wäre ein Greenfield. Projekt, so. Sind es, also ich kann mir vorstellen, Domänen, wenn die sich was entwickeln, wo sie, muss ich mir trotzdem erstmal überlegen, was sind denn meine Komponenten so? Gefühlt bei Makro und Mikro ist da ja weniger, wo man sagen kann, ich reibe mich erst mal daran so wie, wie würdest du da vorgehen? Sehe ich so. Also ich glaube, je kleiner das Projekt, umso eher fallen Mikro und Makro zusammen, weil das einfach nicht so eine große Rolle spielt. Ich kenne noch nie auf die Idee, einem Team von fünf Personen, die ein Startup gegründet haben, zu empfehlen, jetzt mit so einer Architektur anzukommen, die für große Teamgruppen gedacht ist. Also mit so Microservices Zeug, das brauchen die alles gar nicht. Ich bin zum Beispiel großer Fan von Rubi und Rales als Framework. Aber das ist immer noch mit riesigem Abstand das Schnellste, Produktivste und ich glaube sogar, das Beste, was du machen kannst, wenn du schnell eine gute Anwendung, eine genügend gute Anwendung bauen willst. Superklasse, also eine Webanwendung. Superklasse Anwendungsfall für ein Startup, das eine Webanwendung bauen will. Perfekt. Würde ich sofort empfehlen. Und da ist das ein Match Mikro und Makro. Zumindest wenn du startest. Man kann auch das machen. Man kann auch da sagen: „Ich definiere, lasse ich jetzt mal. Man kann sich auch das größer zusammenbauen. Man könnte auch ein sehr großes Projekt damit machen, macht man in der Regel nicht. Aber da würde ich halt angepasst für so ein kleines Team sagen, die müssten sich auch Gedanken machen über Domänenstrukturen. Aber die müssten jetzt nicht groß anfangen, da diese unterschiedlichen Regeln zu etablieren. Das müssen die erst in der nächsten Phase. Und dann müssen sie es definitiv. Also in der nächsten Phase, also auch da können wir wieder sagen: Was für ein Ziel hat Architekturarbeit? In dieser ersten Phase hat die Architekturarbeit das Ziel, dass du Funding für die zweite Phase bekommst. In dieser ersten Phase Architektur zu machen, die auf Skalierbarkeit oder langfristige Wartbarkeit oder sonst irgendwas geht, ist wahrscheinlich ein schlechtes Investment deines Geldes, weil so viel Geld hast du gar nicht. Du verzichtest auf dein Gehalt für die nächsten sechs Monate oder lebst von deinem Ersparten und musst es schaffen, gerade so viel zusammenzubauen, dass es ein von außen überzeugend aussehendes Ding ist, damit dir irgendjemand das Geld gibt, damit er es alles wegschmeißt und noch mal machen kannst. Und in dieses Wegschmeiß-Ding jetzt riesig viel langfristige Ideen rein zu investieren, ist total daneben. Diese Architektur ändert sich auch in den Lebenszyklus einer Produktfirma, was auch immer das dann ist. Würdest du mit dem Wegschmeißen sagen, dass das aber was ist, was passieren muss, wenn vorher keine gute Architektur da war? Also ist es praktisch oder kann man Architektur reparieren? Oder ist eigentlich …. Man kann Architektur so bauen, dass sie dieses Reparieren sozusagen unterstützt. Man kann Architekturen so bauen, dass sie so ein evolutionäres Modell unterstützen. Da hängen diese Sachen alle zusammen. Also diese Idee, dieses Domain Makro Mikro ist eigentlich eines, bei dem man sagt, wir schaffen es sowieso nicht, die eine richtige Architektur zu machen. Das ist unmöglich. Was auch immer wir glauben, was perfekt ist, werden wir zwei Jahre später bereuen. Deswegen lass uns das vergessen. Das machen wir nicht. Lass uns lieber jetzt etwas bauen, dass es uns später erlaubt, unsere Meinung zu ändern. Also wenn diese einzelnen Teile so sind, dass ich die angucken kann und sagen kann, im Zweifelsfalle kann ich es auch wegschmeißen und neu schreiben, dann kann ich da ganz andere Risiken eingehen, ganz andere Sachen ausprobieren. Ich kann irgendwelche proprietären Tools benutzen, ich kann Zwischenlösungen machen, was auch immer. Ich habe sozusagen mein Risiko begrenzt. Und das ist ja eine architekturelle Entscheidung, die ich da getroffen habe. Ich habe das so gebaut und so geschnitten, dass ich eben diese kleineren Sachen habe. Und diese Entscheidung, das so zu machen, also das sind unabhängige Dinge zu bauen, also zum Beispiel Microservices oder Self-Contain-Systems, das sind jetzt so die zwei, mit denen wir uns am meisten beschäftigen. Wenn ich so was mache, dann bezahle ich dafür, also dann muss ich dafür mehr Aufwand betreiben. Also ich betreibe jetzt mehr Aufwand, damit ich vielleicht später weniger Aufwand habe. Und das ist nur dann ein guter Deal, wenn dieses später auch mal kommt. Also wenn das nicht kommt, habe ich nur Geld verschwendet. Deswegen muss ich mir schonmuss ich schon wissen, wann ich das mache. Das klingt alles so. Ich wedel schon wieder mit den Händen wild. Immer wenn ich mit den Händen in der Luft rum wedel, merke ich, dass ich zu sehr abschweife. Also ich glaube, dass es wichtig ist, sich aufs Falschliegen vorzubereiten, ohne es zu übertreiben. Es kommt ganz darauf an. Man kann eben auch absolut in Schönheit sterben und sich für Eventualitäten vorbereiten, die nie kommen. Also man muss eben überlegen, wie viel man gerade macht. Macht ihr vor allem... Habt ihr vor allen Dingen neue Projekte oder geht ihr auch an Projekte, die schon bestehen und versucht da …? Kommt beides vor. Ich würde sagen, das meiste sind entweder neue oder Modernisierungsgeschichten und manchmal auch so in Schieflage geratene Dinge, wo man … Also so Entwicklungsprojekte, die in Schieflage geraten sind, wo man versucht, das in die andere Richtung zu bewegen. Genau, weil das war gerade so ein bisschen die Frage, ob das dann … Also wenn praktisch jemand kommt und sagt, da muss drauf geguckt werden, ob dann meistens so der Fall ist, okay, da hat irgendwas nicht funktioniert aus Architektursicht. Und dann die Frage, wurde das einfach nur … Also gibt es einen Unterschied zwischen es wurde vernachlässigt praktisch in der Architektur und es wurde schlecht entschieden? Genau. Und es war schlecht. Also es ist so, dass – ich weiß nicht, ob das eine Antwort auf die Frage ist – aber es ist tatsächlich interessanterweise so, dass die Systeme meistens erfolgreich sind und eine schlechte Architektur haben, was ja total seltsam klingt. Das klingt irgendwie so, als würde Architektur keine Rolle spielen. Das ist aber nicht so. Die Systeme, die erfolgreich … Also erstens hatten diese Systeme wahrscheinlich irgendwann mal eine gute Architektur, die hat sich halt nur nicht mit verändert. Also wenn so ein Unternehmen erfolgreich ist, dann gibt es da einen großen, großen Wunsch nach mehr Features, nach mehr Sachen, nach neuen Geschäftsmodellen, neuen Prozessen, neuen Monetarisierungsmöglichkeiten. Das Unternehmen wächst und in die Software kommt immer mehr rein. Und während man das macht, ist die Priorität immer ein neues Feature und noch ein neues Feature und noch ein neues Feature. Und wenn da jetzt einer kommt und sagt, es gibt erst mal keine neuen Features, wir machen jetzt erst mal ein bisschen Modernisierung und Umbau und sonst irgendwas, muss der schon sehr laut sprechen und ein sehr großes Gewicht haben, damit durchzukommen. Meistens werden die Features gebaut und irgendwann stellt sich fest okay, Feature mäßig wird es auf einmal auch langsamer, weil die Architektur mir jetzt im Wege steht und ich viel zu viel Zeit damit verbringen muss, da drüben zu flicken, was da vorne kaputt gegangen ist, weil ich da was Neues dran gebaut habe. Und dann überlegt man, was macht man? Und stellt fest: Ihr habt ein Architekturproblem, weil die Architektur vielleicht mal gut war, vielleicht auch da schon nur so mittel, vielleicht sogar super, ist egal. Heute auf jeden Fall passt das nicht mehr. Das passt nicht zu euren geänderten Anforderungen. Die Software ist gebaut worden für einen Einsatz zu Büroarbeitszeiten durch 200 Leute. Und jetzt habt ihr mit viel Klebeband das irgendwie hingefummelt, dass die im Internet verfügbar ist, 24 mal 7 von 100.000 Leuten benutzt wird. Aber dafür war es ursprünglich nicht gemacht und deswegen tut es jetzt weh. Und dann muss man sich halt überlegen, wie man von da aus weiterkommt. Und dann ist es einfach eine Frage, wie sehr es da schon schmerzt. Also wenn man das deutliche Gefühl hat, man fördert gerade auf einer brennenden Plattform Öl, dann muss man sich vielleicht schnell Gedanken machen. Wenn man sagt, kann da noch ein paar Jahre warten, dann vielleicht nicht. Aber meistens ist es so eine Situation. Meistens ist es nicht so, dass das System zum Beispiel nicht in Produktion ist. Das sind meistens Systeme, die sind in Produktion, die erzeugen Wert, die machen Geld, die unterstützen den Arbeitsprozess von ganz vielen Leuten, die die auch gut kennen. Das sind erfolgreiche Dinge. Die, die ein Problem haben, wo man sich irgendwie überlegen muss, wie man die entweder schlagartig oder sanft sukzessive über einen längeren Zeitraum irgendwie modernisiert und durch irgendetwas anderes ersetzt oder teilweise ersetzt. Und wo würdest du sehen, wenn man -also ich stelle mir jetzt vor, dann kommt ihr in so ein Projekt rein und dann habt ihr sowohl Entwickler, die in dem Projekt mitarbeiten, als auch vielleicht Leute wie du und Konsorten, die vielleicht eher auf einer höheren Ebene noch mal darüber diskutieren. Ich frage mich in dem -wir hatten vorhin auch das Bild des Solution Architects, wo irgendwie große Unternehmen und dann wird auf irgendwelchen anderen Ebenen so über Architektur geredet, wo keiner mehr wirklich am Produkt arbeitet. Was ist denn, wie ist man denn gesund aufgestellt? Wenn wir jetzt wirklich mal sagen, wir sind bei einem großen Projekt, du hast jetzt gesagt 100 Leute plus auf jeden Fall oder 200 plus. Und wie ist man denn sinnvoll aufgestellt? Also braucht es in jedem Team irgendwie einer, der für Architektur Entscheidungen im Gremium mitredet? Sind alle Modelle gangbar, dass man wirklich die Solution Architects irgendwie auf höherer Ebene hat und dann Architekturen nur noch im wirklich im kleinsten im Team selbst entschieden wird? Wie findet man eigentlich diese Architektur, wenn man nicht am Ende immer sagt okay, wir haben es jetzt gegen die Wand gefahren und holen jetzt in den Q, uns zu helfen und wenn sie weg sind, fahren wir es wieder gegen die Wand? Also zunächst mal finde ich es wichtig, dass wir natürlich gerne helfen. Man darf uns immer gerne mit Geld bewerfen und wir machen dafür Dinge. Aber wir wollen auch irgendwann mal wieder weg. Das heißt, ich finde es ganz wichtig, dass solche Organisationen, solche Kundenorganisationen, das selbst in die Hand bekommen. Und heute ist es ja nicht mehr so wie früher. Früher hast du ein Projekt gemacht und alle waren froh, wenn das Projekt vorbei ist, weil du dann wieder in einem stabilen Zustand bist und alles wieder gut ist. Das ist ja heute nicht mehr so. Heute hört das Projekt ja nie auf. Ist also auch kein Projekt mehr, sondern es ist ein Service. Das ist irgendwas, wovon das Unternehmen abhängt und das wird ständig, kontinuierlich immer wieder weiterentwickelt und immer weiter gemacht. Und deswegen glaube ich, ist es in den meisten Fällen so, dass die Unternehmen das selbst Ownen müssen, zumindest mittelfristig. Die können sich dann Unterstützung holen, vielleicht zum Aufbau oder für eine für eineErkrankung zwischendurch oder für eine große Transformation oder so. Aber irgendwann muss das Ziel sein, dass die das meiner Meinung nach eigenen Leuten aufbauen, gerade so große Organisationen. Wir haben auch Kunden, die sind kleiner oder Mittelstand, da ist das Quatsch, die werden nie eine eigene IT Entwicklungsabteilung aufbauen, sondern die verlassen sich auch langfristig auf Leute wie uns. Aber wir waren ja gerade bei diesen großen Trümmern, wenn du jetzt so ein Telko oder Versicherung oder von mir aus auch ein Internet, ein E-Commerce Unternehmen hast oder so, das muss meiner Meinung nach die Technik selber beherrschen, muss man selber machen können. Deswegen glaube ich auch nicht an dieses Solution Architect Modell, weil das aus meiner Sicht fundamental auf der Annahme beruht, dass die Entwicklung etwas Geringeres ist, was man nicht selbst messen kann. Das kann man outsourcen, das gibt man irgendwem. Und ich glaube, dass das nicht funktioniert. Oder meine Erfahrung ist, dass es nicht funktioniert, weil du diese Kopfarbeit nicht entkoppeln kannst von der vermeintlich geringen. Das ist keine geringere Arbeit. Die beiden, das hängt ganz eng zusammen. Das ist nur ein leicht anderer Fokus. Und das eine macht das andere so schneller kaputt, als du gucken, als dunach denken kannst. Das ist also keine gute Idee. Um auf deine Frage zu antworten, gibt es in der Tat viele verschiedene Organisationsmodelle, wenn man jetzt annimmt, dass ich in so einer Firma bin. Ich habe jetzt verschiedene Teams, die arbeiten da in diesem Kontext. Ich habe keine Ahnung, E-Commerce, großer Shop oder so, die bauen da alle verschiedene Bestandteile dieses Shops. Dann kann ich theoretisch sagen, da gibt es aus jedem Team eine Person oder zwei Personen, die treffen sich einmal in der Woche, tauschen sich aus und dann gehen sie wieder in ihre Teams. Das heißt, es ist sozusagen eher so Bottom-Up, so ein Organisationsmodell, wo packen die sich ab und zu mal zusammen, ohne irgendwas anderes. Die stimmen sich nur ab und wir vertrauen darauf, dass alles gut wird. Und wenn das funktioniert, super, finde ich ein tolles Modell. Manchmal sagst du, okay, das haben wir probiert, aber die haben nie so richtig Zeit. Die sind ja eigentlich in ihrem Team und klar können die sich einmal in der Woche unterhalten und finden auch die Probleme, aber die haben keine Zeit, die zu lösen, weil unklar ist, wer von denen dafür verantwortlich ist. Deswegen nehme ich mir jetzt mal eine oder zwei Personen, die mache ich verantwortlich dafür. Die arbeiten immer noch mit den anderen zusammen, aber sind jetzt die diejenigen, die sich am meisten darum kümmern, dass das irgendwie weitergeht. Und dann kriegen die vielleicht irgendwann ein eigenes Team, wo sie übergreifende Architekturarbeit mitmachen. Oder du sagst, die kriegen ein eigenes größeres Team und schicken jetzt Leute in die Teams rein. Das wäre die andere Richtung. Also nicht die Teams entsenden Architektinnen und Architekten in ein Gremium, wo sie einmal in der Woche tagen, sondern andersherum. Die Architekturtruppe schickt in jedes Projektteam eine Person rein, die da mitarbeitet und darauf achtet, dass die übergreifend Architektursachen gemacht werden. Kommt extrem darauf an, ist eine Frage, wie die Organisation tickt, wie die Leute sind, wie gut die sind. Ich erzähle mal so eine Story. Wir haben in einem Projekt, da hatten wir sehr, sehr viele Eigenverantwortliche, also konnten uns praktisch komplett alles selbst bestimmen können und haben, obwohl Kundenmitarbeiter mit dabei waren, die haben alle bei uns in den Büros gearbeitet. Und wir haben zwei Leuten von uns gesagt: Ihr seid die Architekten in dem ganzen Ding. Und die haben gesagt: „Jawoll, super, danke. Sind in das Projekt gegangen und haben das niemandem erzählt. Und das war gar kein Problem. Das war nicht nötig. Es gab unterschiedliche Leute, die zu unterschiedlichen Zeitpunkten die Verantwortung für bestimmte Sachen übernommen haben. Weil beim Standup irgendjemand gesagt hat: Hier, ich beschäftige mich damit, weiß nicht, wie das geht. Hat jemand anderes gesagt: „Habe ich schon mal gemacht. Lass uns beide doch gleich mal reden. Dann haben die eine Stunde geredet und gesagt: „Wir bauen einen Prototypen. Am nächsten Tag erzählt er: „Wir bauen nächste Woche einen Prototypen. Dann haben sie den gebaut, ausprobiert und gesagt: „Das ist die richtige Lösung. Und dann war das die Architektur Entscheidung. Finde ich perfekt. Ein besseres Modell kann ich mir nicht vorstellen. Niemand hat den Titel, niemand macht das exklusiv, sondern es ergibt sich einfach auf Basis der Kompetenz. Das geht aber dann, wenn die gesamte Truppe eben sehr gut harmoniert, sehr gut funktioniert. Wenn da keine... Wenn da nicht die falschen Leute irgendeine Motivation haben, ja keine Ahnung, Dienstleister wollen sich neue Aufträge holen, Produktanbieter wollen ihr Produkt stärker platziert sehen. Irgendjemand will seinen Head Count erhöhen. Es gibt tausend Gründe, warum die falschen Sachen entschieden werden und dann will man es vielleicht anders. Also du sagst, dass du das gerne sehr nah aneinander hast, das Entwickeln und die Architektur dessen. Ist Architektur unterrepräsentiert in normalen Entwicklungsteams? Also wäre es besser, dass der – fällt nichts besseres ein – die Standardentwickler*innen irgendwie mehr Architekturwissen hat, das überhaupt, die Need vielleicht dafür abzubauen? Ja, das glaube ich. Also ich glaube, dass wir eher einen Bedarf haben, dass Softwareentwickler:innen mehr über Architektur wissen, als dass wir jetzt einen Bedarf haben, ganz viele Architekt:innen auszubilden. Also Geschenke können wir auch gerne machen, aber eigentlich finde ich es wichtiger, dass diese Themen, mit denen man sich im Architekturumfeld beschäftigt, dass die sozusagen breiter gesehen werden. Weil das… Also es gibt leider berechtigt oder unberechtigt oft so eine negative Sicht von Architekturarbeit, weil Leute halt darunter schon mal gelitten haben, weil sie erlebt haben, wie ätzend das sein kann und wie nutzlos und wie doof. Das ist echt störend und das ist schade, weil das halt dazu führt, dass auch die guten Sachen eben als schlecht bewertet werden. Also so, wie heißt es auf Deutsch, Baby with the bad water. Ich weiß nicht, das Kind mit dem Bade ausschütten oder so. Also weil Architekturarbeit manchmal bescheuert ist, glauben wir einfach, dass alles aus diesem Umfeld doof ist. Ich glaube, die Denke hat sich geändert in den letzten Jahren. Auch bei modernen, agilen, hippen Entwickler:innen ist das ein anderes Bewusstsein. Ich nehme so wahr, es wird immer häufiger von Architektur geredet, auch in dem Kontext. Und wir fanden die Gedanken hinter agiler Softwareentwicklung schon immer cool. Wir fanden schon immer viel besser, frühzeitiges Feedback zu holen. Wir fanden es immer viel besser iterativ vorzugehen, als wasserfallmäßig. Ich habe noch nie daran geglaubt, dass es eine tolle Idee ist, 500 Seiten Architektur-Dokumentation zu machen, bevor man anfängt zu entwickeln. Außer in den ersten sechs Monaten damals. Ja, genau. Damals. Aber da haben wir auch entwickelt. Wir haben auch in diesen sechs Monaten Prototypen gebaut und Sachen ausprobiert. Das war trotzdem bescheuert, aber nicht nur Papier. Aber es gibt halt immer so ein Pendel, das zu weit ausschlägt. Und zu sagen, wir wollen jetzt mal wieder uns darauf konzentrieren, dass das, was wir hier eigentlich machen, Software bauen ist, finde ich genau richtig, sollte genauso sein. Das bedeutet aber nicht, dass man nicht mehr nachdenken darf. Man darf selbstverständlich einfach mal die Hände verschränken und einfach mal eine Stunde nachdenken, bevor man irgendwas baut, weil oft die beste Antwort ist, das nicht zu bauen. Also gar nicht. Nicht nur anders, sondern einfach gar nicht. Das ist eine Software, die sollten wir nicht anfangen. Das ist eine blöde Idee. Passiert viel zu selten. Ist für mich die wichtigste aller Architekturentscheidung. Soll ich das überhaupt bauen oder lieber nicht? Und heute noch viel mehr als früher, weil es ja heute auch noch ganz viele andere Gründe, ethisch, moralische, gesellschaftliche, sonstige geben kann, aus denen man ablehnen sollte, bestimmte Software zu bauen, aber auch rein technisch. Also nur weil irgendjemand mich und drei meiner Kolleg:innen in einen Raum gerufen hat, mir jetzt den Projektauftrag zu geben, heißt das ja noch lange nicht, dass das eine wohlüberlegte gute Entscheidung ist. Und da könnte ich durchaus mal sagen: „Entschuldigung, habt ihr daran gedacht, dass es das schon gibt? Oder habt ihr überlegt, dass es vielleicht auch eine Lösung wäre, eine Word-Datei zu bauen mit einem Makro drin, anstatt hier sechs Personen ein halbes Jahr arbeiten zu lassen? Also diese Fragen darf man durchaus stellen. Und gefühlt haben wir uns jetzt ja sehr stark über große Systeme unterhalten. Wir waren bei Makro-, Mikro-, Domänen-, Architektur. Architektur so. Aber wenn ich jetzt, ich denke jetzt an, also Architektur ist ja auch gefühlt, ist der Begriff ja auch, wird ja auch viel im Kleinen genutzt. Wie strukturiere ich überhaupt meine … Wenn wir jetzt einfach nur betrachten, es gibt ja auch Teams, so keine Ahnung, ich habe schon Szenarien gesehen, wo sechs Teams Scrum Teams an einer Mobile App, sagen wir mal, ist halt für iOS und Android, aber wo ein Architektur-Review auch sein könnte, wie ist überhaupt, also wie ist der Code an sich strukturiert, wo man gar nicht entscheidet, was ist mein Framework, sondern in dem man einfach nur schaut, wie ist denn die Architektur dieser App so? Und würdest du gerade so was wie davon auch so ein Review oder so was zu machen, was ist da eine gute Architektur, was ja schon sehr viel kleinteiliger irgendwie ist? Hast du darauf irgendwie eine Antwort, wie man da vorgeht, vielleicht auch da frühzeitig bessere Entscheidungen zu treffen? Wie man eigentlich bewertet, habe ich das jetzt hier gut gemacht, weil gefühlt sind da viele Faltstriche. Ja, also zunächst mal gebe ich dir völlig recht, das gibt es natürlich auch im Kleinen. Auch da kann man von Architektur sprechen. Meistens machen Leute den Unterschied, sagen also bis hierhin ist es Architektur und ab da ist es dann Design. Aber das ist eigentlich auch nur Spielerei mit Worten. Also wenn ich jetzt sage, ich gucke mir meine Software an, die ist strukturiert in Packages, dann kann ich definieren Packages sind eine Entwurfs Entscheidung oder Packages sind eine Architektur Entscheidung. Mir total egal. Wichtig ist es auf jeden Fall. Und es ist sozusagen immer eine Stufe, also praktisch von der Abstraktion gehst du immer eine Stufe nach oben und dementsprechend hat es eine andere Relevanz und einen anderen Detailgrad, über das, worüber du da gerade sprichst. Es könnte sein, dass ich jetzt mir die Architektur von einem Software Modul überlege, das ich alleine in den nächsten zwei Wochen baue. Man kann ja nicht von Architektur sprechen. Ich kann auch sagen, ich nenne das Entwurf oder Design. Das ist wirklich egal. Aber die Vorgehensweise ist aus meiner Sicht immer die gleiche. Zunächst mal ist ganz wichtig: Du solltest im Idealfall wissen, warum du etwas tust. Das heißt, egal was du machst, du solltest immer wissen, was du da eigentlich erreichen willst. Was ist denn überhaupt dein Ziel? Warum machst du das? Vielleicht baust du eine kleine Software, die soll modular sein, und zwar damit du auch in Zukunft neue Zahlungsmethoden hinzufügen kannst oder neue Charaktere in einem Spiel oder neue Plugin Module in einer Idee. Ich habe keine Ahnung, was dein Kontext ist. Du hast irgendeinen Need. Oder du sagst, die soll performanter sein als das Produkt meiner Konkurrenz, oder „Die soll besonders gut skalieren oder die soll besonders sicher sein, oder „Da will ich alles nachvollziehbar und besonders datenschutzkonform haben. Was weiß ich, alles sind Ziele. Und du kannst natürlich sagen: „Ich habe hier 100 potenzielle Ziele und die drehe ich alle auf zehn. Es muss alles in jeder Dimension perfekt sein, aber das ist halt Blödsinn. Das funktioniert nicht. Du priorisiert immer und sagst, also da ist mir das besonders wichtig und da ist mir das. Das heißt, du bekommst so ein ganz spezielles Qualitätsmodell, wenn du so willst, oder ein Qualitätszielmodell für deinen Kontext, was du da eigentlich erreichen willst. Und das kannst du sehr formell machen, kannst Monate damit verbringen und du kannst es auf einen Zettel oder auf dein Whiteboard in zehn Minuten mal hinschreiben. Das sind meine drei wichtigsten Architekturziele. Und dann sollte das, was du da entscheidest, irgendwas damit zu tun haben. Also warum habe ich das jetzt so implementiert? Weil ich das damit erreichen will. Ich habe das deswegen gemacht. Und dann kannst du bewerten, ob das das Ziel auch erreicht, wenn du das dann eben gemacht hast. Also ich habe das gemacht, damit das besonders performant ist? Also baue ich das mal und gucke, ob es performant ist. Und wenn nicht, dann frage ich mich, wo ich den Fehler da gemacht habe. Und ich optimiere nicht auf Ziele, die ich nicht habe, also zum Beispiel auf Portabilität zu optimieren. Wenn das niemand von mir verlangt hat, ist möglicherweise Verschwendung. Ich benutze irgendeinen proprietären Mechanismus, was weiß ich, irgendeinen Amazon Cloud Service benutze ich nicht, weil ich mir überlegt habe, dass ich nicht von einem Cloud-Anbieter abhängig sein möchte. Das ist in der Theorie absolut legitimes Ziel. Das könnte ich haben. Ich sollte es nur wissen, ob ich mir das gerade ausgedacht habe oder ob ich das wirklich habe, weil mich das ja was kostet. Ich kann diesen Service benutzen, da muss ich nichts machen oder ich kann ihn selbst bauen. Da bin ich portabel. Ihr wisst, was ich meine. Ich muss einfach wissen, warum ich irgendwas mache und sollte das irgendwie mit Leuten abgesprochen haben, die da auch Input zu haben. Vielleicht mit dem Datenschützer oder dem Betriebsrat oder der Geschäftsleitung oder wie auch immer. Und dann habe ich irgendwie ein Modell, an dem ich mich orientiere. Das heißt, da sind die Grundregeln einer gewissen Form von abstrakten Zielen, von denen ich dann meine Architektur Entscheidung irgendwie ableiten kann. Und. Da frage ich mich jetzt, weil wir haben vorhin über die Größe der Architektur gesprochen, Makro und Mikro, gefühlt so gesagt, so ja, dann gebe ich vor, das sind die Domänen Boxen, das sind vielleicht auf einer Makro Entscheidung so bestimmte Infrastruktur Komponenten, die man nutzen sollte. Und hier nutzen wir, gehen wir bis auf die ID runter und sagen was du nutzen sollst. Aber da klang es eher so wie ein, das sind die Dinge, die gemacht werden sollten. Und jetzt frage ich mich so ein Punkt, du Akzeptanz gefühlt hat es viel mehr mit mir räsoniert, dass du gesagt hast, das sind die, das sind unsere Ziele, die wir erreichen wollen. Gefühlt bei den anderen Dingen hat es für mich eher geklungen wie: Das sind die Entscheidungen, die wir schon mal getroffen haben. Inwiefern werden die, wenn ihr so was mitteilt, auch mit … Also inwiefern stehen da Ziele und unser. Lösungsvorschlag dafür? Hoffentlich immer. Hoffentlich stehen da immer Ziele und Lösungsvorschläge. Das ist immer eine Begründung, warum das so ist. Vielleicht hätte ich es gerade noch kurz ausführen müssen. Ich bin total dagegen, eine Idee festzulegen. Ich bin total dagegen, Mikroentscheidungen vorzugeben, wenn es nicht sein muss. Wenn du mich fragst, würde ich sagen: Ich habe so eine Makroarchitektur, ich habe so eine Domänenarchitektur und dann setze ich Teams darauf an und sage ich denen: „Macht, was ihr wollt, ist mir egal. Hier sind die Regeln, das ist die Domäne und das ist die Makro-Architektur. Können wir regelmäßig einmal in der Woche drüber reden, ob die noch stimmt oder ob die sich ändern muss. Aber damit lauf ich jetzt erst mal los und mir ist egal, worin ihr das implementiert. Wenn ihr GO programmieren wollt und ihr REST und ihr Java, mir doch wurscht, macht doch. Jetzt versucht mal mit der Einstellung zu so einer typischen Firma zu gehen, die sagte: „Entschuldigung, habt ihr denn noch alle? Sollen wir jetzt hier 24 verschiedene Programmiersprachen erlauben? Und ich muss dann zugeben, die haben ja recht. Also mir ist es zwar egal, aber ich muss es auch nicht ausbaden. Die haben recht, weil sie sagen: „Wir wollen doch irgendwie Leute von einem Team ins andere schicken können. Und dann hat man vielleicht eine andere Motivation. Das Qualitätsziel ist dann sozusagen eines auf der Entwicklungsebene. Ich möchte in der Lage sein, jemanden, der neu in dieses Team reinkommt, einsetzen zu können, nachdem der sich zwei Wochen eingearbeitet hat, soll er oder sie in der Lage sein, produktiv zu werden. Oder ich will auf dem Markt Entwickler:innen finden, die das können. Deswegen baue ich es nicht in Hascal. Das wäre zwar die coolste Sprache, aber ich finde keine Hascal-Programmierer:innen. Deswegen mache ich es lieber in Go oder so. Komischer Vergleich. Also diese Entscheidungen haben auch eine Motivation. Die findet man dann vielleicht gerade nicht so gut, aber sie hat trotzdem eine Begründung, warum sie da ist. Das ist vielleicht auch noch mal, kann man auch noch mal sagen. Also das finde ich generell eine extrem wichtige Sache. Auch das hast du gerade gesagt, was mit der Akzeptanz. Ich finde Akzeptanz auch aus Erfahrung unglaublich wichtig, weil du nur damit eine Chance hast, dass das auch irgendwie funktioniert. Wenn du lauter Sachen machst, die niemand akzeptiert, dann finden die Leute Wege drumherum. Immer. Sehr innovative und kreative Wege. Und deswegen ist es ganz wichtig, es zu machen. Ein Mittel, das wir oft benutzen, nicht immer, aber oft sind ADRs, Architektur Decision Record. Das sind im Prinzip so eine leicht formalisierte Form, das mal hinzuschreibenzu sagen. Also ich habe folgende Aufgabenstellung gehabt. Ich habe mir folgende sieben Alternativen theoretisch überlegt. Davon habe ich mir drei angeguckt und von den dreien habe ich diese gewählt, weil das und das gilt. Punkt. Schreibe ich hin, checke ich ein fertig. Ich kann aber in drei Monaten nachgucken, warum das so entschieden wurde und was die Alternativen waren und warum die verworfen wurden. Und dann kann ich mir überlegen, will ich die Diskussion noch mal aufmachen, weil sich vielleicht etwas geändert hat. Es gibt eine neue Alternative, die gab es damals noch nicht. Oder es gibt eine neue Erkenntnis oder eine neue Version oder was weiß ich. Ansonsten sage ich auch, das haben die damals überlegt, die haben das damals entschieden und das war der Grund. Und weil ich da nichts Neues dazu beitragen kann, dann ist das eben akzeptiert. Das heißt, ich habe so eine Kette von Architektur Decision Reports, die mir erklären, warum die Situation so ist, wie sie heute ist. Das hilft bei der Akzeptanz ganz enorm. Und das ist eigentlich so ähnlich wie das mit den Zielen. Ich finde, man muss Dinge rechtfertigen können. Man muss irgendwie erklären können, warum das so ist. Tatsächlich glaube ich, dass man als Architekt oder Architektin fast nichts anderes macht als ständig zu rechtfertigen, warum man irgendwas so oder so entschieden hat. Und das ist auch gut so. Man muss sich dieser Frage stellen, weil sonst … Also wenn die einzige Erklärung ist, das macht man heute so, finde ich das äußerst schwach. Das ist ja wahrscheinlich auch wichtig für die Weiterentwicklung dieser Architektur, wenn man sich dem nicht andauernd aussetzt und auch darüber diskutiert ist vielleicht der …. Das passiert tatsächlich auch häufiger als man denkt. Also wenn wir so ein Review machen, dann kommt man oft irgendwo hin, dann bekommt man irgendwas erklärt, also noch alle Buzwords abgehakt. Also gerade wenn Leute in frühen Phasen fragen, die haben so ein neues Projekt gestartet und wollen relativ früh Feedback dazu, ob das gut ist, was sie sich da ausgedacht haben. Und das ist dann schon verdächtig, dass zufällig immer gerade das, was diesen Monat auch auf den großen Konferenzen in der Agenda steht, sich auch in dieser Architektur wiederfindet. Weil das ist ja nicht so, als ob das jetzt automatisch gut wäre, ist auch nicht automatisch schlecht, aber eben auch nicht automatisch gut, nur weil es gerade hip ist. Und dann kann man schon fragen: Was genau ist das Ziel? Warum genau macht ihr da Microservice? Ich möchte es nur verstehen. Erklär mir, warum das bei euch die passende Architektur ist. Würdest du von der Dokumentation der Architektur, die du gerade angesprochen hast, ist das in jeder Projektgröße? Also würdest du auch sagen, in einem kleinen Team sollte man auch solche Architekturentscheidungen oder Entscheidungen, wie man was macht, dokumentieren? Also ich glaube, dass gerade diese Architektur Decision Reports, die funktionieren auch in sehr, sehr kleinen, weil die sind das sind ganz oft, typischerweise sind das wirklich Textfiles. Schreibt jemand eine Markdown Datei, schreibt das kurz rein. Das ist wie eine kleine Notiz, gar nicht gar nicht mehr. Eine DIN A4 Seite, da steht das kurz drin. Das haben wir überlegt, das haben wir entschieden, das ist festgehalten und dann wird das mit dem Source Code eingecheckt und ist einfach da. Das kostet fast nichts. Das muss kein MUL Modell malen, muss keine riesigen Prosa Word Dokumente machen. Einfach nur ganz kurz erklären, warum das da ist. Klar kann man sagen, das ist auch Aufwand. Jemand hätte in der Zeit auch irgendwas programmieren können. Ja, sehe ich ein. Aber meine Erfahrung ist, das ist alleine, wenn du neue Leute ins Projekt reinholst, da kommt irgendjemand oder ist beim Urlaub, war vier Wochen im Urlaub, was in der Zwischenzeit passiert. Wir haben das diskutiert, das diskutiert. Sonst kommst du aus dem Urlaub und auf einmal ist keine Ahnung, View durch React ersetzt oder andersrum. Und was soll das? Kann mir irgendjemand erklären, warum wir das jetzt gemacht haben? Kein Problem. Guckst du nach ADR 13 A? Okay, verstehe. Das ist der Grund. Finde ich doof. Möchte ich gerne anders. Also idealerweise kannst du es auch nachvollziehen, warum es denn so ist. Was hältst du davon, Fabi? Also ich finde auch gerade mit dem Ansatz, was Steffi auch sagt, dass man es im Endeffekt nur kleine Textfiles sind und ich meine die Komplexität dieser Dokumentation ja wahrscheinlich auch mit vielleicht Größe und Teamgröße ja auch wachsen kann. Aber ich habe zumindestens gedanklich gerade so ein paar Grundentscheidungen, die wir auch getroffen haben bei unseren Projekten. Ich glaube, ich fände es nicht schlecht, wenn sie noch mal irgendwo dokumentiert werden. Allein auch für mich. Also finde ich es nicht so, dass ich mich, nur weil ich die Entscheidung getroffen habe. Also ich weiß noch, von mir kam damals mal die Entscheidung, dass wir Big Table nutzen für einige unserer Projekte. Und ich könnte jetzt, wenn du mich jetzt heut fragst, was waren deine, was waren deine Gründe dafür? Ich könnte sie dir nicht Rezitieren. Gut, das ist jetzt auch schon wieder drei Jahre her oder so, aber. … Im schlimmsten Fall, im Zweifelsfalle ist ja auch das eine Aussage. Wir haben das genommen. Wir hatten keinen besonderen Grund. Das war in unserem Cloud Angebot halt irgendwie mit drin. Das sah aus wie der Default. Ich habe da drüben einen Artikel gelesen, fertig. Dann kann jemand sehen: „Okay, es gab keinen besonderen Grund. Es ist nicht so, als ob ich irgendwas nicht wüsste, das dazu geführt hat. Es wurde einfach entschieden. Es ist ja trotzdem entschieden worden. Das ist ja nicht das Kriterium dafür, dass es da reingeht. Jetzt kannst du sagen, je größer das Projekt, umso formaler wirst du dann vielleicht. Also ich war schon im Projekt, da wurde jeder ADR in einem Gremium von 25 Leuten diskutiert. Also man kann das auch super dysfunktional machen, wenn man gerne möchte. So muss das nicht sein, aber man könnte ja zum Beispiel sagen, wir wollen bei so einem ADR immer, wir wollen die vielleicht per Merge-Request oder Pull Request, wollen wir, dass dann die zweite Person mit drauf guckt und dann haben eben zwei Leute das gesehen und jemand kann zwischendurch. Könnte man ja so machen. Oder in meinem Beispiel von gerade, ich will ADRs für die Makroarchitektur regeln. Bevor ich jetzt für alle anderen festlegen kann, dass die ab sofort in diesem und jenem Format ihre Log-Dateien schreiben, sollte ich das einmal kurz erklären, warum ich das so will und dann kann da jemand anders draufgucken und sagen: „Okay, finde ich gut und dann wird es eben aktiv für alle. Weil für mich ist es gerade so, also ist vielleicht auch ein bisschen der Kontext von uns, dass wir kleinere Teams sind, aber es irgendwie so ein Ansatz … Weil eben genau das existiert. Entscheidungen werden sowieso getroffen und das sind ja irgendwie auch Architekturentscheidungen am Ende. Und ich glaube, die Klarheit darüber, dass das so ist, ist zum einen manchmal nicht so richtig da und tatsächlich auch, in Zukunft noch mal Sachen zu hinterfragen: Warum hat man das gemacht? Wie würde man es heute anders machen? Und so was, dass das wirklich ganz gut helfen kann und vielleicht auch tatsächlich einfach in dem Entwicklerkontext auch dazu führt, ein bisschen mehr Präsenz für das Thema zu haben. Was sind denn eigentlich Entscheidungen gewesen, die wir als eine Architektur Entscheidung betiteln würden jetzt? Und was vorher, also wie gesagt, die Entscheidungen passieren ja sowieso, aber dass man es einfach ein bisschen bewusster macht, was davon ist jetzt eine Architektur Entscheidung und lass uns das mal kurz festhalten. Auch vielleicht für Leute, die sonst diese Architektur, also bei uns gibt es das auch in den Teams durchaus, wenn wir jetzt mal irgendwie ein Senior und Junior unterteilen würden, schon Entscheidungen oftmals eher von den Senioren getroffen werden und aber auch für die Junioren gefühlt, so wirkt es gerade für mich, eine Option ist, daran zu lernen, sozusagen, wie wurde denn die Entscheidung getroffen? Und sonst musst du halt zur richtigen Zeit am richtigen Ort gewesen sein, mit dem Ohr bei der Entscheidung gewesen sein, dann lernst du daraus vielleicht. Aber irgendwie aus diesen vergangenen Entscheidungen zu lernen, kann ich durchaus auch forschen, dass das ein positiver ist. Selbst in unserem Kontext, wo wir es nicht so haben, dass wir andauernd neue Leute onboarden und auch nicht super groß skalieren, was die Teams angeht, glaube ich trotzdem, dass wir davon profitieren könnten, es zu tun. Deswegen, nimm es mal mit. Nimm es mal mit. Als Head of Development kannst du ja mit den Entwicklern diskutieren. Ja, sehr gut. Dass die mit dem einen mehr als mit dem anderen diskutieren müssen. So, ne? So. Mal gucken. Als erstes lassen wir die alle mal die Folge hören. Da brauchen wir nicht so viel erklären. Und dann kommen die vielleicht von selbst drauf, dass es eine gute Idee ist. Sehr schön. Wir haben noch diesen Fragenkatalog und wir wollen den ja mal eigentlich nicht am Ende machen, sondern einfach mal zwischendurch einbauen. Das mache ich jetzt. Du kannst deine Gedanken noch sammeln. Stefan, dich erwarten ein paar sehr einfache Fragen, die du schnell aus dem Bauch heraus beantworten darfst. Entweder oder Fragen. Erst mal entweder oder Fragen. Hund oder Katze? Hund. Tee oder Kaffee? Kaffee. Auto oder Fahrrad? Fahrrad. Java oder JavaScript? Nein. Java. Mac oder Windows? Mac. Ios oder Android? Ios. Büro oder Remote? Büro. Frontend oder Backend? Backend. Funktional oder objektorientiert? Funktional. Native oder Web? Web. Teamwork oder Individualist? Teamwork. Was war deine erste Programmiersprache? Das ist schwierig. Das sind so alte Leute, die mich fragen. Meine erste Programmiersprache war Turbo. Kannst du dich an deinen ersten Computer erinnern? Ein ZX 81. Wie alt warst du damals? 13. Ein Kilo bei Gramm. Was ist deine liebste Programmiersprache? Closure. Was ist dein liebstes Frontend Framework? Nichts. Was ist dein liebstes Open Source Projekt? Oh, das ist eine gute Frage. Closure hat Wiederverwendung angefangen. Ja. Hast du eine Lieblings App? Safari. Okay, dann vielen Dank. Gerne. Ich hätte Vanilla. Js sagen sollen. Für. Frontend Framework. Das ist die beste, das ist die raffiniertere Version von Nix. Deshalb die Antwort hätte mich nämlich interessiert. Warum hast du mit Nix darauf geantwortet oder mit Vanilla. Js? Weil die meisten Frontend Frameworks sind so ein typisches Ding, wo dir meiner Erfahrung nach meistens niemand eine befriedigende Antwort darauf geben kann, warum das eingesetzt wird, sondern so ein Frontend Web Framework setzt man ein, weil man so was halt heute so macht. Ja, also ich kann einen Schritt zurückgehen. Man baut eine SPA, weil man heute eben so Webanwendungen baut. Das ist aber in den allermeisten Fällen eine ganz schlechte Idee, eine Webanwendung so zu bauen. Es gibt welche, da ist es eine gute, meistens aber nicht. Aber das stellt gar keiner mehr in Frage, weil niemand die Grundfrage stellt und begründet, warum man so was macht. Hättest du einen guten Grund dafür, es zu machen? Für eine SPA? Ja. Wenn ich mir ganz sicher bin, dass ich nur einen bekannten Benutzerkreis habe, der Desktop-Computer benutzt und ein High-Speed Network hat und die Anwendung morgens startet und abends zumacht, würde ich SPA's eventuell in Erwägung ziehen. Okay. Ja, dann fangen wir es mal alles in die schauen? Können wir wahrscheinlich... Ich könnte weiter fragen. Aber bevor du mich so freundlich abgewürgt hast, da wollte ich eigentlich noch mal ein bisschen auf, woran ich selbst vielleicht noch erkennen kann, woran ich selbst die Qualität meiner Architektur bewerten kann. So aus dem, wenn ich jetzt probiere, aus dem Kontext herauszuhören, was wir bisher gesprochen haben, dann wirkt es so, so gefühlt wie ich möchte etwas Neues tun und mir gefällt, also gefühlt, eigentlich habe ich das Gefühl, ich merke es immer erst dann, wenn es nicht mehr gut ist. Wenn es schon knarrt und ich irgendwas mache, dann merke ich, fuck, wenn ich das anfasse, dann muss ich das auch anfassen. Oder so wieerkenne ich zur Laufzeit den Qualitätsstand meiner Architektur? Also ich glaube, es gibt wenige Dinge, die man sozusagen als Grundwahrheit oder Weisheit sozusagen benutzen kann. Oder die Indikation dafür sind, dass irgendwas schräg ist. Und das ist aus meiner Sicht vor allem Komplexität oder Verkomplizierung. Also es gibt so eine inhärente Problemkomplexität, die ist nun mal da. Also wenn du für sich eine Anwendung fürs deutsche Steuerrecht schreibst, die wird nie einfach sein. Da kannst du nichts machen. Aber an vielen Stellen hast du selbst Dinge verkompliziert. Und wenn es schwer ist, jemand anderem zu erklären, was du da überhaupt gemacht hast, dann ist das vielleicht ein Zeichen, dass du da noch mal drüber nachdenken solltest und dass das vielleicht zu kompliziert ist, weil du Sachen gemacht hast, die vielleicht jetzt noch gar nicht gebraucht werden, die erst da eingebaut für irgendwann mal, für irgendeinen Eventualitätsfall. Oder du hast einfach noch die Abstraktion nicht gefunden, die du da einbauen könntest, das alles viel schöner zu machen oder so. Das könnten so Gründe sein. Also Verkomplizierung oder Komplexität. Das ist aber eine von ganz wenigen Dingen, bei denen das so ist. Es gibt so ein paar Kennzahlen, da kannst du dann Metriken über dein Haus drüber laufen lassen. Also kann man, kann man, ja, zyklomatische Komplexität. Keine Ahnung. Ja, kann man auch machen. Tatsächlich finde ich es sehr spannend zu überlegen, warum du das gemacht hast und das dann mal als Trockenübung zu verproben. Also nehmen wir mal das Beispiel: Du hast dir eine Architektur ausgedacht, bei der du in deinem Shopsystem einfach neue Zahlungsmethoden einfügen kannst, weil das hat dir die Fachabteilung als Anforderung gesagt. Im alten System ist es viel zu schwierig. Immer wenn wir eine neue Zahlungsmethode haben, dann steht dreimal alles still und es dauert eben seit zehn Schritten geht immer irgendwas kaputt. Deswegen ist das dein Ziel gewesen, eine Architektur zu wählen, die das einfach macht, neue Zahlungsmethoden hinzuzufügen. Also spiel das doch auf dem Papier mal durch. Was wäre denn das Änderungsszenario? Also was müsstest du jetzt tun? Du müsstest da eine neue Klasse schreiben, da eine neue Klasse schreiben, in die Konfigurationsdatei was eintragen, den Endpoint umkonfigurieren, die Firewall-Regel ändern. Keine Ahnung. Du musst diese zehn Sachen machen. Guck dir das an. Fühlt sich das gut an? Wie lange würde das dauern? Ist das, erfüllt das deine Anforderung, dass so eine Änderung innerhalb von einer Woche erledigt sein können soll? Wenn ja, ist alles gut. Wenn du dann merkst, ach, ich will da gar nicht drüber nachdenken, ich kriege schon Kopfschmerzen bei den bloßen Gedanken, dann fehlt da irgendwas. Also so ein Szenario basierter Gedanke erlaubt dir sozusagen die Erkenntnis vorher zu gewinnen, bevor die Änderung tatsächlich kommt, spiel es mal durch, was da passieren würde. Und das kannst du mit solchen Änderungs-Szenarien machen. Das kannst du aber auch mit Laufzeit-Szenarien machen. Was passiert denn, wenn auf einmal die Benutzerzahl sich verzehnfacht? Also wenn das ein Szenario ist, auf das du dich vorbereiten willst, ja, könnte ja sein Black Friday, keine Ahnung, irgendwas oder besonders erfolgreiches Spiel. Ich habe keine Ahnung was das ist. Was würde sich dann alles ändern? Gar kein Problem. Dann würde hier der 'Load Balancer' würde da fünf neue Instanzen hochfahren und da hinten würde … Keine Ahnung, was passieren. Und dann hast du das ebenfalls auf dieser Ebene durchprobiert. Also ich glaube, dass die Änderbarkeit im ganz, ganz abstrakten Sinne, die Weiterentwickelbarkeit, also nicht nur Bugfixing, sondern generell das Stück, dass du immer noch das Gefühl hast, du bist noch nicht das herauszögern des Wartungsmodus, so nenne ich es malDas ist eigentlich, also du willst immer noch, kennt ihr das, wenn ihr in so einem Projekt drin seid und ihr seid gerade eingeschwungen, also ihr sagt nicht in der ersten Woche, sondern so eine Weile, irgendwann läuft das alles gut. Du weißt, du kennst die Umgebung gut, du weißt, wie das geht. Jede Anforderung kann ankommen, kein Problem, das baust du ein. Diesen Grad an Produktivität, den willst du ja eigentlich durchhalten. Darauf optimierst du sozusagen. Und dann ist das für mich auf jeden Fall ein guten Ansatz, mit mir Szenarien zu überlegen, was wäre, was wäre wenn? Du darfst es ja nicht übertreiben. Wenn du dir jetzt Szenarien ausdenkst, die keine Basis in der Realität haben, dann geht es nach hinten los. Aber ich glaube grundsätzlich, dass man – ich will mal sagen – in der Realität machen es Leute zu wenig als zu viel. Also ich glaube, von daher ist der Tipp schon mal …. Und ich glaube wahrscheinlich auch, dafür ein Gespür entwickeln, das hast du ja gerade gesagt. Ich glaube, das hat fast jeder mal erlebt, dass ein Projekt dann doch komplexer wird und irgendwann dieser Moment kommt, wo man so denkt: „Irgendwie müssen wir jetzt was ändern, weil wenn wir jetzt neue Anforderungen bekommen, dann fällt es uns schwer und vor einem Monat ist uns noch nicht schwergefallen. Und da ein Gespür zu entwickeln, genau den Moment anzupassen, wo es vielleicht noch nicht, wo es noch kein Problem geworden ist und wo man trotzdem schon die Weichen stellen kann, das besser zu machen. Ja, und das muss ich aber trotzdem direkt mir selbst widersprechen, weil das Schöne ist, das geht wirklich in beide Richtungen. Also du kannst auch ganz oft auf so was draufgucken und zu viel Abstraktion erkennen. Also ich verstehe, da sind fünf Klassen. Warum sind da fünf Klassen und eine Konfigurationszeit? Warum ist das nicht eine Klasse? Ich müsste nur zehn Zahlen lesen. Ich wüsste genau, was da passiert. Warum ist das so kompliziert? Ja, weil ich eventuell vielleicht mal … Dann ist da ein Änderungs-Szenario. Wenn das irgendwann kommt, dann baue ich das ein. Also wenn ich jetzt sozusagen ohne Funktionsverlust einfach diese komplette Abstraktion rausschmeißen und entsorgen kann, dann ist das erst mal besser. Ich kann mir das ja … Irgendwo mache ich mir eine Notiz. Wenn ich das mal brauche, baue ich das mit. Das kann sein. Ich habe, soll ich euch eine Anekdote erzählen dazu? Also ich hatte vor ewigen Zeiten ein Beispiel. Da hatten wir einen abgefahrenen Caching-Mechanismus gebaut, Objekte, die wir aus einer rationalen Datenbank geholt hatten, in so einer Memory Map zu halten. So eine Art-Resistenz-Layer selbst gebaut. Und das war, weil das eben sehr lange dauerte, diese Objekte zusammenzubauen. Wenn man sie einmal aus der Datenbank mit ganz vielen Joins sich zusammengesucht hat, musste man so ein kompliziertes Objekt zusammenbauen und das wollte man nicht ständig immer wieder machen. Das fühlte sich auch alles ganz gut an, bis man festgestellt hat: „Okay, es reicht ja vielleicht doch nicht, wenn da nur eine Instanz dieser Anwendung irgendwo läuft. Da müssten mehrere Instanzen laufen, also habe ich jetzt mehrere In-Memory Caches. Und dann haben wir auf einmal – oder da bin ich damals in Auftrag bekommen – „Denkt dir jetzt eine tolle Lösung aus, wie wir sozusagen diesen In-Memory Cache, der in mehreren Prozessen drin ist, so rausziehen, dass er als verteiltes Ding, aber ausfallsicher von allen genutzt werden kann. Habt ihr das ungefähr vor Augen? Das ist ein geiles Engineering Problem. Richtig. Cool. Richtig cool. Und dann haben wir genauer reingeguckt und auch immer experimentiert und ein bisschen gemessen und festgestellt: „Beste Lösung ist, diesen Cache rausschmeißen. Einfach weg, weil die Datenbank sowieso, die Cache sowieso, das ist deren Job, der ist dafür da, die ist auch redundant ausgelegt. Und wir haben uns nur Probleme gemacht mit dieser Lösung. Das heißt, wir hatten gedacht, wir hätten eine Performance Optimierung und haben das rausgeschmissen, weil die Probleme alle weg waren. Und das beeindruckendste war, die Performance war besser, weil unser toller Cache alles nur langsamer gemacht hat. Manchmal hast du so einen Effekt. Du schmeißt Code weg, du machst es einfacher und am Ende ist es schneller. Du sagst: „Hätten wir besser schon vorher gemacht. Und das ist eigentlich noch schöner. Noch schöner als was einzubauen, ist was ersatzlos zu löschen und dann ein besseres System zu haben. Aber gefühlt ist es auch so eine Entwicklung, die ich jetzt an mir selbst betrachte, auch irgendwie durchgemacht. Das ist ja irgendwann am Anfang, als man sehr grün hinter den Ohren war, irgendwie darüber wenig nachgedacht hat. Dann hat man das Gefühl gehabt, man denkt über Architektur zu wenig nach. Dann bin ich gefühlt in die Falle getappt, zu viel zu abstrahieren, dann wieder zu merken: „Ja, aber warum tue ich Dinge, die überhaupt, nur weil ich dann denke, ich mache eine gute Architektur, aber eigentlich nur Probleme bereiten, überhaupt gar keinen Benefit bringen sollen. Das finde ich irgendwie eine interessante Entwicklung, dass ich eigentlich eher nur dabei bin immer Abstraktion rauszuwerfen. Ich überlege dir wirklich, brauchst du diese Abstraktion oder warum. Tust du es gerade so? Es erinnert mich daran, das wird mir, glaube ich, jetzt erst wirklich klar, dass ich fest davon überzeugt bin, du musst mindestens zwei Personen an so was dran setzen. Wenn du es alleine entscheidest, dann such dir irgendwen, mit dem du darüber reden kannst, vorzugsweise jemand, der nicht genauso denkt, der dir sagt: „Ich verstehe das nicht. Wieso hast du das da eingebaut? Gerade mit einem Kollegen haben wir gerade diskutiert, weil bei uns ist der, die internen Slack Channels voll mit solchen Sachen. Irgendjemand hat geschrieben: „Ich verstehe nicht, wozu wir in diesem Kundenprojekt diese Datenbank brauchen. Ich würde die einfach rausschmeißen. Ich halte einfach alles in Memory und ab und zu serialisiere ich das mal raus. Alles wird schneller, alles wird einfacher. Ich muss kein OR Mapping machen. Der Footprint ist so, das passt 100 Mal in Memory. Es gibt keinerlei Begründung dafür, warum wir diese riesig komplizierte Angelegenheit haben. Ich kann das dramatisch vereinfachen, indem ich das tue. Und die ersten ein, zwei, drei Sachen, Zustimmung, ich habe noch einen Link auf irgendein altes Tool, das das schon mal vor 20 Jahren machte, keine Ahnung. Und dann kam irgendwann der Zweite: Was ist das denn für eine grauenhafte Idee? Dann musst du dich alles kümmern, warum sich die Datenbank kümmert. Du musst sicherstellen, dass das Ganze korrekt, korrekt, präsentiert wird, dass es einen Crash überlebt, dass es mit dem Pfeilsync zusammenpasst. Das haben andere schon 100 Mal gelöst. Und warum bauen wir das jetzt in die Anwendung ein, wenn das, also dieser Diskurs, dass du eben dich darüber unterhältst und dir dann darüber klar wirst, was die Fakten sind. Das ist eigentlich diese ADR Diskussion, die dann dazu führt, dass du am Ende sagst: Ich habe mir das alles überlegt, ich habe das oder wir haben uns das alles überlegt, wir haben das so und so reflektiert und am Ende das und das entschieden. Also man muss es nicht immer hinschreiben, aber man sollte es wahrscheinlich immer diskutieren, zumindest wenn es eine wichtigere Entscheidung ist. Also eine Definition von Architekturentscheidung ist ja die, die teurer zu ändern sind. Also wie ich jetzt eine Variable benenne, ist keine Architektureinstelle, das geht nicht unbedingt, wenn mir der Name nicht mehr gefällt. Und das hat wahrscheinlich nicht so riesige Auswirkungen. Aber wenn ich jetzt mich entscheide, keine Ahnung, ein OR Mapper einzusetzen und eine relative Datenbank oder nicht, das ist schon eine größere Entscheidung. Ja, das ist eine schöne Anekdote auf jeden Fall nochmal. Und ich glaube gerade auch mit der Dokumentation der Architektur Entscheidung und so, das ist ja auch so lange. Ich finde auch dieser Punkt, dass du meintest, sobald es dokumentiert ist, gibt es halt auch die Möglichkeiten, anderen mit mir darüber in den Diskurs zu gehen. Wenn ich alles, wenn ich es nicht dokumentiere, ist die Gefahr vielleicht auch höher, dass ich einfach mal so etwas entscheide, was vielleicht auch jemand anderes mal mit drauf geguckt hätte. Also wohin sende ich sonst überhaupt meine Architektur Entscheidung? Das wird bei uns aktuell. Also ich glaube, wir diskutieren es zu wenig, glaube ich schon. Also ich meine, vielleicht ist das schon eine coole Sache, wenn ihr zusammen einen Kaffee trinken geht und darüber mal sprecht, dass man sich überhaupt mal austauscht und die Meinung von jemand anderem einholt und dann darüber reflektiert. Das ist ja auch schon ein erster Schritt. Also beiuns ist bei uns sehr viel informell geregelt. Wir unterhalten uns schon darüber, aber es ist jetzt nicht so, dass jeder denkt, ich muss jede Architektur Entscheidung, die ich treffe, vielleicht noch mal irgendwie hier und da diskutieren. Ja, cool. Dennis, hast du noch eine Frage? Stefan, ich frage dich. Gibt es noch was aus dem Kontext, den wir bis jetzt besprochen haben, wo du sagst, den Aspekt hätte ich gerne noch in der Folge. Also ich glaube, mir ist es wichtig, falls jemand diese Illusion hat, dass das so was anderes, so eine abgekoppelte Geschichte ist. Also so Architekten sind diese anzugtragenden Leute, die Diagramme malen, auf die da ein Blatt Papierausdruck an die Wand hängen, die niemals irgendjemand anguckt. Also das ist sehr schade. Das ist nicht das. Also Architektur ist das. Das ist die Summe der wichtigen Entscheidungen über ein System. Wir alle treffen wichtige Entscheidungen, mal mehr, mal weniger. Je mehr man an diesen wichtigen Entscheidungen teilhaben möchte, umso mehr lohnt es sich, sich mit diesem Thema zu beschäftigen. Das hat nichts mit Titel zu tun, nichts mit Enterprise oder sonst irgendwas, einfach nur ein interessantes Feld. Und ich finde, das sind spannende Diskussionen. Und klar kann man auch sich auf eine reine Expertengeschichte in einem ganz, ganz schmalen Ding machen, aber wenn man eher so T-shaped unterwegs ist, wenn man eher ein breites Interesse hat und so an vielen Sachen mitreden will, ist das, glaube ich, eine ganz lohnenswerte Angelegenheit, sich damit zu beschäftigen. Vielen, vielen Dank. War wieder ein super spannender Einblick darin. Und ich muss auch ganz ehrlich zugeben, so in eigener Reflexion, gehörte ich in der Vergangenheit – das hat sich vielleicht auch schon über die Jahre ein bisschen gebessert –, aber habe ich viel in dieser Schublade gedacht, oder auch für unseren Kontext, so ne Architekturrollen oder so was, das wollen wir nicht. Also ist ja auch nicht das, dass wir das wollen aus dem Podcast heraus. Aber das ist einfach ein wichtiger Part ist, der Teil der Softwareentwicklung ist und wo es so sinnvoll ist, dass alle sich immer ein bisschen Gedanken machen. Und hoffentlich haben wir mit der Folge ein bisschen dazu beigetragen, dass ein paar sich da noch mehr Gedanken machen können. Wir haben noch unsere. Pics. Of the Day, die wir natürlich gerne mit euch teilen möchten. Im Vorfeld haben sie auf Stefan und Fabi aufund sehr wenige Informationen gedacht. Vielleicht haben wir den gleichen, ich bin sehr gespannt, was jetzt hinausläuft. Stefan, als Gast gebe ich dir gerne den ersten. Ich bin noch nicht ganz durch, aber was ich im Moment absolut genieße, ist ein wunderbares „Steef Jobs in has our Word Buch. Ich weiß nicht genau, wie der Titel ist. Wenn wir die Show noch packen ist kostenlos, kann man im Internet lesen, eine riesengroße HTML-Seite. Und das sind ganz viele Dinge aus E-Mails und aus irgendwelchen Vorträgen, aus irgendwelchen Reden. Das ist wirklich ein genialer Einblick in die gesamte Geschichte. Und da sind so tolle Sachen drin und vor allem, da ist mir wieder aufgefallen, obwohl das eine umstrittene Person ist, ich finde den keinesfalls ausschließlich toll, gerade so als Mensch. Aber auf jeden Fall ist das der beste Kommunikator in diesem Unternehmensumfeld, den ich je gesehen habe, ist mir wieder klar geworden. Cool, die packen wir nicht schon aus. Wette mal 5 €, das ist nicht Farbiges Tipp. Du. Hättest auf jeden Fall die Wette gewonnen. Bei mir geht es ein Buch, das ich letztens gelesen habe. Letztens habe ich auch schon ein Buch empfohlen. Na ja, viele Bücher, könnt ihr viel lesen. Und zwar fand ich ganz cool „Bad Blatt. Ich glaube, der Untertitel „Die wahre Geschichte des größten Betrugs im Silicon Valley über Teranos, dann ja das Unternehmen, was eigentlich mal damit geklärt hat, ein kleines Gerät zu bauen, was nur mit einem Tropfen Blut aus der Fingerspitze irgendwie alle möglichen Tests machen kann. Und das finde ich auch, apropos Kommunikation dann wieder interessant, wie Elisabeth Homes, die... Die ein großes Idole, die Jobs. Immer war. Ja, genau. Die hat ja auch so einen Rollkragenpulli getragen und so und sich immer sehr an ihm orientiert und irgendwie wollte auch immer gern so kommunizieren wie Apple und so und auf jeden Fall kommunikativ auch einiges kann. Ich finde es immer sehr beeindruckend, so ein Skill, der mir absolut fehlt aus nicht existenten Dingen eine Geschichte zu bauen, die jeder glaubt und irgendwie glaubt, du hast das größte Produkt, obwohl sie eigentlich niemals auch nur irgendetwas wirklich in der Hand hatte. Und es wirklich ist super. Also ich finde es ein super interessantes Buch, wie das Ganze vom Start bis zum Fall von Teranus ging. Hat Spaß gemacht zu lesen. Cool. Danke dir. Hast du denn was, Dennis? Ja, ich habe ein YouTube-Video von einem Talk, das wir intern relativ viel diskutiert haben, wo es AI geht und das nennt sich die AI Dilemma vom Center for Human Technologie. Und das sind die Macher oder was man bei uns nennt, die das Social Dilemma den Film gemacht haben und einen sehr kritischen Blick haben auf die aktuellen Entwicklungen, die es dort gibt. Aber ich finde irgendwie auch mit sehr nachvollziehbaren Gründen, also die skizzieren nicht, AI wird uns alle umbringen und das ist das Ding, sondern, also da sie wahrscheinlich auch das mit viel Background haben, sie vergleichen es auch ein bisschen so mit dem, was ist schiefgegangen bei Social Media in unserer Gesellschaft? Und wenn wir jetzt nicht frühzeitig bei AI versuchen, Regeln zu finden als Gesellschaft, dann wird uns das da genauso passieren. Ja, auf jeden Fall interessant, weil es mal so ein bisschen einen Diskurs aufmacht und einfach Gedanken einem gibt, so ein bisschen darüber nachzudenken. Ja, auch nicht alles unterschreiben oder genauso groß oder kritisch sehen, wie es da ist. Es tut mich ja wundern, wenn du es so sehen willst. Von daher, wenn es dir Gedanken anregt, dann muss es gut sein. Genau, den Link kommt dann, der kommt auch eigentlich schon an uns. Perfekt. Sehr schön. Dann vielen Dank euch beiden. Stefan und Fadi, vielen Dank. Danke euch für die Einladung. Sehr gerne. Wir freuen uns gleich schon auf deinen Meetup Talk. Und na gut, jetzt Werbung dafür brauchen wir nicht mehr machen. Das ist vorbei. Dafür keine Werbung machen. Können wir nur sagen, ein Pinselbefehl habt ihr verpasst. Das wird es nämlich auch noch gleich geben. Oh ja, gut. Und dann beim nächsten Mal doch vorbeikommen. Sehr schön. Vielen Dank. Habt eine gute Zeit. Feedback wie immer gerne an unsere E Mail Adresse podcast@programmier. Bar oder über unser Kontaktformular auf der Website oder über iTunes oder Spotify, wie auch immer, schickt uns Spotify. Fällt mir gerade ein, die haben irgendwie so eine Umfragefunktion jetzt neu. Man kann angeblich kann man, nachdem man eine Folge von uns gehört hat, kann man da so ein Textfeld reinschreiben, wie man die fand. Falls einer diese Funktion schon freigeschaltet hat, schreibt gerne mal da rein und …. Dann gucken Sie vielleicht den Weg zu uns oder was? Nein, da gucke ich rein. Das habe ich im Blick. Sehr gut. Bis bald. Macht's gut. Ciao. Ciao.