Deep Dive 63 –

“Good Enough” Architecture mit Stefan Tilkov, CEO von INNOQ

05.06.2020

// Podcast
// Deep Dive 63

Shownotes

Zu wenig Fokus auf die Architektur eures Projekts wird euch vor genauso große Probleme stellen wie zu viel Fokus darauf. Doch wie findet man dann das richtige Maß in der Architekturarbeit? In Folge 63 sprechen wir mit Stefan Tilkov über die Frage der richtigen Priorisierung. Wie die goldene Mitte zwischen Over-Engineering und fehlender Weitsicht erreicht werden und wieso es keine Musterlösung für jedes Projekt geben kann, erzählte er uns im Livestream dieser Folge.

Weitere von Stefan angesprochene Begriffe und Themen findet ihr hier:

Definitionen von “Softwarearchitektur” gesammelt auf Software Engineering Institute
You Aren’t Gonna Need It (yagni)-Prinzip
Cargo Cult Programming

Stefan ist Autor und Mitherausgeber folgender Bücher, die euch weiterführende Informationen zu dieser Folge liefern:
Tilkov, Stefan et. al. (2015): „REST und HTTP”. dpunkt.
Tilkov, Stefan; Starke, Gernot (Hg.) (2007): „SOA-Expertenwissen“. dpunkt.

Download

/transkript/programmierbar/deep-dive-63-good-enough-architecture-mit-stefan-tilkov-ceo-von-innoq

Dennis: Es ist wieder Zeit für die programmier.bar. Herzlich willkommen zu Folge 63 unseres Podcasts. Wir reden heute über Good enough Architecture. Das heißt, wie viel Fokus sollte man auf die Architektur legen in Software Produkten. Das tun wir heute wieder mit einem Gast und keinem geringeren als Stefan Tillkow. Schön, dass Du dabei bist.
Stefan Tilkov: Danke für die Einladung.
Dennis: Du bist Geschäftsführer 1 Firma, die heißt NNOQ und bist Berater letztendlich für genau diese Fragen, nämlich für Software Architektur. Und ihr berratet viele Firmen, wie sie denn dieses große Thema angehen. Bevor wir gleich einsteigen, einmal noch begrüßen von unserer Seite, den Fabi, der auch wieder dabei ist, Hello und Jojo, den wir auch zugeschaltet haben. Hi. Meine Wenigkeit ist Dennis. Da wir auch wieder auf Youtube live sind, wir freuen uns auf eure Fragen. Falls ihr zwischendurch irgendwas wissen wollt, dann könnt ihr jederzeit gerne kommentieren und wir versuchen die Fragen möglichst live und zeitnah einzubauen. Ich hab ja gleich am Anfang,
Fabi: ich war ja Stefan, als ich auf eurer Seite von INNOQ war, hab ich immer 'n bisschen geguckt, was sind denn eure Success Stories und hab als eine Success Story mal direkt Vorwerk und Thermomix rausgegriffen, weil meine Freundin und ich, das ist jetzt schon sehr spießig auf jeden Fall, aber seit 'n paar Monaten hier stolzer Besitzer 1 Thermomix sind. Da habe ich natürlich ganz angetan und hab mir zuerst die Architektur des vom Thermomix angeschaut. Wird ja wer weiß. Vielleicht wird es ja heute ein Referenzbeispiel bei bei Sachen, wo wir über gute Architektur reden, wie man das so wie der wie wir es bei Vorwerk und Thermomix gemacht hat. Interessiert mich auf jeden Fall brennend. Aber funktioniert bisher übrigens sehr gut bei mir. Ich hab noch keine Ausfälle gehabt. Von daher ist vielleicht 'n guter Einstieg.
Stefan Tilkov: Nur vielleicht die Vorwarnung, da muss ich immer total aufpassen, weil eigentlich darf ich nur genau das sagen, was in dieser Case Study drinsteht, wie bei allen Kunden, bei denen man so was veröffentlicht ist. Das Ja, klar. Durch die Presseabteilung und wen auch immer freigegeben. Und wenn ich da einbaut mehr sage, dann werde ich enthauptet, morgen hier vorm Büro.
Fabi: Ja, das glaube ich. Also, ich wollte einfach nur mal das Feedback geben. Hat mich auf jeden Fall sehr gefreut mit der Architektur. Bisher funktioniert alles gut, muss gar nicht so schlecht sein.
Dennis: Ist ja die Frage, ob man dafür gute Architektur braucht oder ob man
Fabi: Das stimmt.
Dennis: Solche Applikationen auch ohne gute Architektur auf die Beine gestellt bekommt. Kannst Du Stefan für uns mal vielleicht definieren, was überhaupt der Begriff Architektur bedeutet im Softwareumfeld? Also welche Parts von der Softwareentwicklung zählen diesen Blockarchitekturen?
Stefan Tilkov: Also ich glaube, es gibt bestimmt viele 1000 Definitionen davon, was Software Architektur ist. Es gibt eine relativ bekannte Website in der traditionellen Software Architektur Community, das ist die vom SEI, vom Software Engineering Institute an 1 amerikanischen Uni und die haben das mal gesammelt. Also da gibt's irgendwie so Hunderte von kontribuierten Software Architekturdefinitionen. Es gibt so ganz formale, also so rein formal sagt man, das ist das sind die wichtigen Entwurfsentscheidungen in einem in 1 System in 1 Systemkonzeption, 1 Systemarchitektur, also die Elemente, die Beziehungen zwischen diesen Elementen und die Regeln, die bestimmen, wie sich diese Dinge weiterentwickeln. Die Grundprinzipien, denen das Ganze unterliegt, ist relativ formal. Das ist sogar irgendwann in son ISO Standard reingekommen. Und es gibt aber auch welche, die sagen, find ich eigentlich ganz gut, stammt, glaub ich, von von Gradue Booge. Das ist das, was teuer ist, wenn man seine Meinung dazu ändert. Absolut. Ich sag immer so mal gerne, also es ist eigentlich das, was die Leute, die irgendwie sich Architekten oder Architektinnen schimpfen, für wichtig genug erachten, sich damit zu beschäftigen. Also ist eine sehr persönliche Sache, ja. Manche Leute stellen Dinge in den Mittelpunkt, die ich vielleicht als Detail betrachten würde und die halten vielleicht Dinge für irgendwelche Implementierungsdetails, die ich ganz wichtig fände. Aber eine Sache finde ich immer sehr, sehr wichtig, die die sag ich immer, das muss ich vielleicht auch noch grad ergänzen, weil das uns immer so falsch rüberkommt. Also wir als Firma machen ganz viel Software Architektur, aber wir machen noch viel, viel mehr Softwareentwicklung. Also wir sind so 20 Prozent Berater und 80 Prozent Entwickler und Entwicklerinnen, weil wenn man immer nur drüber redet, wie's wäre, wenn man mal was bauen würde, ist das 'n bisschen langweilig. Also wir bauen das Zeug auch und ich finde, Softwarearchitektur ist eben nicht nur eine Beschreibung. Also manche Leute haben so dieses Bild Softwarearchitektur machen so große Diagramme, die dann wandfüllend ausgedruckt werden und die man dann bestaunen kann, die aber faktisch niemanden wirklich interessieren. Das das finde ich genau die falsche Sicht der Architektur ist das, was das System hat. Also das hat auf jeden Fall eine Architektur, ob ich will oder nicht, ist total egal. Das hat eine und die ist vielleicht gewollt und vielleicht zufällig entstanden und vielleicht gut und vielleicht schlecht und vielleicht nützlich und vielleicht nicht. Das kann man alles diskutieren, aber es hat auf jeden Fall eine. Es gibt kein System ohne Architektur, was auch klar ist, genauso wie's 'n wie's kein Haus ohne Architektur gibt, gibt's eben auch kein Softwaresystem ohne Architektur.
Fabi: Okay, also ist sozusagen irgendwas, was Architektur ist ja klar. Das heißt, wenn ich wenn ich selbst wenn ich mich für keine Architektur im Vorhinein entscheide, meine Software hat am Ende eine Architektur dadurch, dass sie bauen und in 1 Weise baut. Dann sind es vielleicht Entscheidungen, die ich auf dem Weg treffe und mir nicht vorher geplant sind, aber irgendwie muss ich diese Entscheidung ja treffen. Ob die vorher groß geplant sind als Bild oder ob die im Kleinen, sobald ich meine erste Zeile Code schreibe, entschieden werden, ist eigentlich egal, aber eine Architektur kommt am Ende raus.
Stefan Tilkov: Genau. Und ich würde sagen, das, was Du gerade gesagt hast, zeigt auch die die Bandbreite von Möglichkeiten, die man da, die man die man auf diesen auf denen man diesen Weg sozusagen gehen kann, ne. Man kann rein theoretisch absolut versuchen, am Anfang alles komplett durchzuplanen und das alles vorher festzulegen theoretisch und dann genau das Bauen, was man vorher festgelegt hat. Meiner Erfahrung ist, es klappt nicht, da kommt Mist raus. Man kann genauso gut sagen, ich denk überhaupt nicht nach. Ich lass auch immer was auf mich zukommen. Ich ne, fang einfach an zu hacken und guck mal, wo's mich hinführt. Meiner Erfahrung nach funktioniert das auch nicht. So, es ist irgendwas in der Mitte. Und das muss man eben abstimmen und das kommt sehr, sehr, das ist Standardberaterspruch, ne. Es kommt ganz drauf an, je nachdem, in was für 'ner Situation man ist, was das für eine Sortesystem ist, die man da baut und mit was für Menschen man dieses System baut und was da für Anforderungen gelten, wie lange das Ganze dauert, wie groß das Ganze ist und vielleicht was es für eine Kritikalität hat. Also ob da irgend 'n Programm abstürzt und irgendwie sagt, oder ob ich einen nuklearen Super GAU auslöse, möcht ich vielleicht auch anders vorgehen. Also man muss es sehr abgestimmt auf die Rahmenbedingungen machen. Und da hat man irgendwo zwischen diesen beiden extremen 'n richtigen Weg, sich mit dem Thema zu beschäftigen.
Fabi: Ja. Ich mein aber, das ist was, was wir, glaub ich, auch am liebsten hier in unserem Podcast sagen, so. Es kommt drauf an, auch immer, wenn's Entscheidungen geht, was für eine Technologie willst Du, wenn wir irgendwas vorstellen? Ist das der richtige Weg oder ist das der richtige Weg? Ich glaub, es kommt drauf an, ist 1 der wichtigsten Sätze so oder so in der Softwareentwicklung. Von daher passt's halt auch auf Architektur. Aber Du hast ja son bisschen auch in deinem Thema Goodynough Architecture geht ja darum, was ist denn, also welche Architektur ist denn gut genug? Ich denk mal, da geht's ja immer stark darum sozusagen abzuwägen, was Du ja grade meintest. Was was ist, wie viel muss ich planen und wie viel entscheide ich denn auf dem Weg? Und wahrscheinlich, vielleicht gibt's denn son paar Punkte oder Dinge, die Du die Du Du benennen kannst, so die man typischerweise falsch macht, eben bei diesem bei bei dieser Entscheidung? Also ich denk mal, das ist ja etwas, wenn's jetzt halt so es kommt darauf an, wird's wahrscheinlich auch sein, wirst Du wahrscheinlich in deinen in deinen Jahren, wo Du jetzt bei INNOQ bist, auch schon viele Pfund gesehen haben, wo sich eben falsch entschieden wurde und kristallisiert sich da irgendwas raus, was man welche Fallstricke man da eingehen kann?
Stefan Tilkov: Ja, also ich glaub schon, es gibt so sich wiederholende Musterpatterns oder vielleicht eher Antipatterns. Also wenn Du das irgendwie drei- oder fünfmal gesehen hast, dann Du irgendwie das Gefühl, ja, das kenn ich doch schon. Also das ist genauso wie da, da haben wir das auch gemacht, dann hat man das Gefühl, man hat son wieder wiederkehrendes Muster identifiziert. Und davon gibt's, glaub ich, schon 'n paar. Also vielleicht das das Offensichtlichste, was wahrscheinlich wirklich jeder kennt, was man auch vom Namen her schon kennt, weil's schon Mustercharakter hat, wäre so was wie Overengineering. Ne, also ich hab einfach mehr Intelligenz in dieses Thema reingesteckt, als ich hätte tun sollen. Also ich hab einfach, ich wollte unbedingt, ich aus welchen Gründen auch immer, vielleicht weil ich mich selbst verwirklichen wollte, vielleicht weil ich schon immer mal mit Technologie x y spielen wollte, vielleicht weil ich grade auf 'ner Konferenz war oder auf 'nem coolen Podcast gehört habe oder 'n Youtube Video gesehen habe, wo irgendjemand mir jemand eine ganz tolle Technologieoption geschildert hat und die möchte ich jetzt einfach gerne mal ansetzen, weil das das ist irgendwie sone sone interessante Relation. Ich weiß nicht genau, ob das ob man das verallgemeinern kann, aber aus meiner Erfahrung sind die Leute, die Architekturaufgaben übernehmen, egal ob sie Architekt, Architektinnen heißen, das auf der Visitenkarte stehen haben oder ob sie das einfach nur intim sind, also diejenigen, die die Architekturentscheidungen am ehesten treffen. Das sind typischerweise Spielkinder. Insbesondere wenn sie wenn sie noch nicht so so viel graue Haare haben wie ich Also ne, ne, das kann ich also kenne ich von mir selbst, kenne ich von ganz vielen Kollegen, Kolleginnen, also wenn man mit so was startet, man ist einfach wahnsinnig voll Tatendrang und möchte einfach Dinge machen und man möchte auch spannende und interessante Dinge machen. Und jetzt ist wahrscheinlich noch, also ihr seid ja in 'ner coolen Domäne tätig, ne, aber je nachdem in welcher Domäne man jetzt unterwegs ist, ist das möglicherweise gar nicht so wahnsinnig spannend, womit man sich da grade.
Fabi: Ich komme aus dem Bankenumfeld, also ich kenn auch die Langweilig.
Stefan Tilkov: Also, also ich persönlich, auch wieder, ich find das gar nicht langweilig, ne. Ich find den Bankenumfeld, gibt's total viele coole Sachen. Aber es gibt eben auch sehr viele Uncoole. Und wenn Du jetzt irgendwas baust, indem Du sagst, also ich ich ich will mich mit diesem Thema nicht beschäftigen, dann neigt man irgendwie dazu, andere coole Sachen zu finden, ja. In meinen Vorträgen hab ich ab und an mal dieses Bild der generischen Dingemaschine, ja. Ich stelle fest, Sachen sind irgendwie langweilig, dann baue ich eine Maschine, mit der man richtig cool langweilige Sachen erledigen kann und wenn ich die Maschine einmal gebaut hab, ist der Rest nur noch Konfiguration, alles wird ganz leicht. Ja, also jeder, der schon mal so was super generisches gebaut hat, der kennt das. Und das ist son schönes Beispiel. Also da baut man einfach ganz, ganz viel Mechanik, ganz, ganz viele tolle Lösungsansätze und wenn man am Ende drauf guckt, sagt man, na ja, vielleicht hätte es 'n bisschen weniger auch getan. Eine meiner Lieblingsgeschichten, es gab mal so eine Zeit, ist schon wieder 'n paar Jahre her, vielleicht so 5, 6, 7 Jahre, da war das Big Data Thema das Superhypehema, so wie's jetzt vielleicht m l ist, ne. Also Big, der jeder hatte Big jeder hatte unbedingt Big Data und jeder wollte unbedingt Haduop einsetzen und irgendwelche Clusterfallsysteme und irgendwelche riesigen Sachen machen, auch mal so cool zu sein wie Google, ja. Also auch mal diese diese schicken Sachen zu machen, die wir alle machen und deswegen hatte jeder son Ding und dann gab es sonen coolen Post, wo jemand wirklich auch sehr gut und sehr schön beschrieben hat, wie er irgendwie son großes Dataset bearbeitet und eben erklärt hat, wie man das mit halt Dooke macht. Also irgendwie HDFS aufsetzen, also fatalsystem und dann diesen Map Reduce Kram aufsetzen, sodass sich da irgendwelche Algorithmen zu den Daten wandern und so alles. Also wirklich, es ist echt, das ist 'n mühseliges Zeug, was man da macht, wirklich viel. Hat also gemacht, dauerte ewig lang und hat dann irgendwie die ganze Aufgabe erledigt in, ich weiß es nicht mehr, in 'ner Stunde oder so was, in 1 Stunde parallel auf Endknoten dieses ganze Ding gemacht. Und irgendwo hat diesen Blogpost gelesen und hat 'n eigenen Blogpost geschrieben, so was machte man früher vor vor Twitter Und hat gesagt, das ist total cool und ich will den auch gar nicht angreifen, der das gemacht hat. Ich will nur mal zeigen, wohin es führen kann, wenn man das auf die falsche Größe des Datasets ansetzt und hat das Gleiche, was da verarbeitet wurde. Ich weiß nicht, wie viel das waren, 100 Gigabyte Daten mit 'nem Shellskript in 30 Sekunden bearbeitet. Und wenn ich sozusagen ein zehnzeitiges Shellskript daneben stehe, gegen den unglaublichen Aufwand, den man allein betrieben hat, das blöde halt zu konfigurieren, das ist son typisches Beispiel für für Overengineering. Hat wahrscheinlich jeder schon mal erlebt und nach 'ner Weile, wenn man das 'n paarmal gemacht hat, entwickelt man da son Gefühl für oder man guckt auf so was drauf und sagt, sag mal, also ich, also ehrlich gesagt, was Du hier machst, Du hast da vorne Datei und die wird hier verarbeitet und dann wird sie zweimal konvertiert und dann wird am Ende irgendwas rausgeschrieben. Das klingt für mich jetzt nicht nach etwas, wo 7 Leute 6 Monate lang dran arbeiten müssen, weil da also das das irgendwas passt hier nicht. Lass uns mal reingucken, warum das so so kompliziert ist.
Jojo: Ich hab auch das Gefühl, dass man manchmal als Entwickler son bisschen dazu tendiert hat, so Systeme irgendwie gleich, also diese eierlegende Wollmilchsau eigentlich konzipieren zu wollen. Und dass man sich eigentlich oft hinterfragen muss, ist das jetzt wirklich notwendig? Also immer dieses pragmatische Herangehen an Aufgaben. Und grade wenn man sagt, man möchte Frameworkkomponenten, also irgendwie, sagen wir mal, sone Basis schaffen, tendiert man, glaub ich, sehr leicht dazu, irgendwie alle möglichen Use Cases, die in der Zukunft eventuell entstehen könnten, gleich mit abzubilden. Und da würde ich sagen, aus meiner Erfahrung macht's absolut Sinn, halt erst mal sich auf die Use Cases zu beschränken, die ich aktuell abdecken will und dann eigentlich erst einmal evolutionär zu gucken, was muss ich denn vielleicht noch an weiteren Bestandteilen an die Software heranflanschen?
Stefan Tilkov: Genau, aber sozusagen den Punkt zu machen. Also das stimmt genau, was Du gerade gesagt hast. Und 'n bisschen ist es so, wenn man weiß, was die Leute denken, mit denen man grade spricht, kann man immer über den Gott man dieses oder das genau entgegengesetzte Argument führt, ne. Was Du sagst, ja, das das Jackdi Argument, you eng gerne need it. Das stammt so aus der Agile Community, find ich auch 'n gutes Argument, ja. Und es sagt ja eigentlich, was immer Du jetzt glaubst, was Du später an Flexibilität brauchst, ist genau die Flexibilität, die Du nachher nachher nicht brauchen wirst. Ne, also Du baust immer, Du baust das immer in 'ner falschen Stelle ein. Du hast immer irgendwas konfigurierbar gemacht, was nachher immer gleich konfiguriert wird. Du hast immer mit 1 zu n Beziehung eingebaut, wo's nachher immer 1 zu 1 ist. Und Du machst immer diesen Blödsinn, weil Du machst das im luftleeren Raum und Du hast eigentlich keine Ahnung, was die Anforderungen sind und deswegen lass es besser auf dich zukommen und bau das einfachste simpelste, was Du bauen kannst. Und das stimmt. Das ist 'n schönes Dogma. Das Blöde ist, es ist halt 'n Dogma, ne. Und das Dogmatische ist immer gut, wenn Du etwas illustrieren willst. Also wenn Du, ne, wenn Du grade didaktisches Mittel brauchst, irgendwie so was zu erklären. Oder wenn Du vielleicht Leute, die sehr, sehr Junior sind, am Anfang erst mal einnorden willst, damit die sich erst mal an was gewöhnen, bevor sie das hinterfragen. Also so das Drivefuß Model of Learning, wo man sich so weiterentwickelt mit dem, ne, wie wie weit man die Regeln verletzen darf, hängt davon ab, wie viel Erfahrung man hat. Wenn man Experte ist, dann sind die Regeln bestenfalls eine Informationsquelle. Wenn man keine Ahnung hat, dann hält man sich besser an die Regeln und alles dazwischen. Und in dem konkreten Beispiel von grade könnt ich auch sagen, also das stimmt alles mit dem Yagnie Prinzip. Aber wenn ich, sagen wir mal, E-Commerce-System baue, dann ist am Anfang eine gute Idee zu fragen, soll das denn mehr währungsfähig sein? Soll das mehr länderfähig sein? Soll das internationalisierungsfähig sein? Soll das mehrere Marken unterstützen können? Wenn ich das am Anfang frage, dann beeinflusst das einige Architekturentscheidungen oder zumindest kann ich kann ich bewusst nicht entscheiden, das nicht zu machen. Ich sag, ja, ich also ich ich mach's noch nicht mehrsprachig, aber ich mach hier und da und an den und den Stellen weiß ich schon, das sind die Stellen, an die ich später mal ran muss, deswegen isolier ich das schon. Wenn ich so was nämlich nach 3, 4, 5 Jahren merke, dann kann es sein, dass es bedeutet, dass ich radikal alles umbauen muss. Also das Jagenprinzip ist gut und richtig und sinnvoll, aber es ist kein Denkverbot. Das bedeutet nicht, dass ich am Anfang nicht mal nachdenken darf über Anforderungen, die ich schon kenne. Und das ist, vielleicht werd ich auch noch mal die Brücke machen, ich hab das ja Goody Nach Architecture genannt, irgendwann bei bei gut genug, es ist ja eigentlich genau die Stoßrichtung, die Du gerade gesagt hast, also gut genug für die Anforderung. Das bedeutet aber auch, dass es eben für diese Anforderung auch gut genug sein muss. Und dazu muss ich die Anforderungen erst mal kennen. Also ich, es gibt keine gute Architektur und schlechte Architektur. Die ist immer nur gut oder schlecht relativ zu irgendwas. Also wenn das eine Unternehmen sagt, also ich möchte jetzt hier in Windeseile innerhalb der nächsten 3 Jahre Marktführer in 27 Ländern werden und 'n anderes Unternehmen sagt, ich möchte in meinem Heimmarkt, den ich schon habe, der Kostenführer werden, dann dann sind das vielleicht völlig unterschiedliche Rahmenbedingungen für die Architektur und bedeutet, dass ich völlig andere Entscheidungen treffen muss. Wenn ich also eine Architektur bewerte, dann muss ich mir ja mal angucken, warum ist die da? Also was hat was hat derjenige oder was haben diejenigen, die sich diese Architektur ausgedacht haben für eine Motivation gehabt, das zu machen? Also haben die sich angeguckt, was die Anforderungen waren, hoffentlich? Und können mir erklären, warum diese Architektur, die da rausgekommen ist, was mit diesen Anforderungen zu tun hat. Also diese Plug in Architektur haben wir gewählt, weil wir damit neue Produkte, konfigurativ und mit neuem Code hier einbauen können. Und wir wissen, dass die Flexibilität, schnell neue Produkte in den Markt zu bringen, ein entscheidender Wettbewerbsvorteil gegenüber unseren Konkurrenten ist. Das find ich 'n cooles Argument. Dann gibt's da 'n klaren Bezug. Wenn jemand sagt, hab ich gemacht, weil ich will immer alles konfigurierbar und ich hasse 'n Konstanten. Ja, und ich hasse hartkodieren, sag ich, ja, sorry. Also das ist kein gutes Argument.
Fabi: Ja, das stimmt auf jeden Fall. Das sind ja all diese Sachen. Ich kann einerseits muss ich mir überlegen, okay, was sind denn eigentlich meine Anforderungen? Das ist wahrscheinlich etwas, was ich zusammen mit dem Business abklopfe. Okay, was sind denn meine Anforderungen, was soll meine Applikationen irgendwie können. Aber dann ist ja trotzdem so, dass ich Architekten, von der Architektur her ja Dinge auf 10 verschiedene Weisen umsetzen kann. Also zum Beispiel könnte ich mir auch vorstellen, jetzt die die einfache Frage, die aufgestellt wird, microservice oder Monolith so? Und es ist ja schon etwas, wenn ich mal etwas mehr als Microservice Ansatz umgesetzt hab und etwas als Monolith umgesetzt hab, dann kenne ich so die typischen Fallstricke vielleicht auch. Kann, nachdem ich in bei beiden mal in die Fallstricke gelaufen bin, das auch ganz gut entscheiden oder zumindest besser entscheiden. Aber ich mein, mittlerweile gibt's ja nicht nur Also gibt's ja so viele Arten, wie ich Dinge umsetzen kann, dass ich nicht alles einmal ausprobiert haben kann, es gut für mich zu entscheiden. Und da frage ich mich son bisschen, gibt's da Ich mein, klar, ihr als als Firma und als Berater habt natürlich schon viel gesehen, aber auch auch ihr beschäftigt euch ja mit neuen Themen. Wie bewerte ich denn für mich so, was jetzt wirklich technologisch gesehen die Architektur angeht, wie wie bewerte ich denn da Themen für mich so? Also Mhm. Ich könnte mich auch erst mal wochenlang einschließen und jegliche Technologien ausprobieren, erst gucken, wo kann ich etwas falsch machen? Aber irgendwann zu 'nem Zeitpunkt muss ich ja eine Entscheidung treffen. Ich kann mich ja nicht 3 Monate lang mit 'ner Entscheidung befassen, also doch in bestimmten Firmen kann man das auf jeden Fall auch über 'n Jahr strecken. Aber so, das ist ja son bisschen auch gerade das Interessante so, da ist ja so viel, der der Wald ist so groß, aber irgendwann siehst Du, sieht man ja den Wald vor lauter Bäumen nicht mehr. So was wie gehe ich da ran?
Stefan Tilkov: Also zunächst mal die die die grundsätzlich immer richtige Antwort ist, uns ganz viel Geld zu geben. Also das hilft immer.
Fabi: Ja, klar.
Stefan Tilkov: Wenn man also uns beauftragt wird, alles gut. Das als Grundaussage nur hier mal kurz damit meine Marketingkolleginnen und Kollegen zufrieden sind. Die andere Antwort ist, jeder vernünftige Architekturansatz behauptet von sich, bestimmte Dinge gut zu können. Und wenn es auch in meinem Ansatz vernünftig ist, wie es beschrieben ist, dann steht da auch, was mich das kostet. Also es ist nichts umsonst. Es gibt keine Architekturentscheidung, die mich nicht irgendwas kostet. Also Microservices sind 'n gutes Beispiel. Jetzt auch ganz viele verschiedene Ausprägungen, wie Du auch gesagt hast, ne. Aber es gibt jetzt Varianten, also sind ganz besonders dicke, ja. Irgendwelche Serverarchitekturen sind ganz besonders kleiner und da gibt's eine Bandbreite dazwischen. Jetzt kann ich mir irgendwas davon angucken. Und ich kann durchaus, sollte auch Artikel lesen, Podcasts hören und und Bücher dazu, was auch immer. Ich habe an Informationen, mir erst mal 'n Bild dafür zu machen, was ist 'n das, was da gemacht ist. Wenn ich mich jemanden habe, der das alles schon weiß, mit dem ich vertraue, dann ist es gut anderes. Aber wenn ich dir das ja jetzt aneigne, dann guck ich mir erst mal an, was ist denn der behauptete Vorteil und was sind die Trade offs, die dafür gemacht werden? Weil das ist immer so. Es gibt immer irgendwelche gewünschten Vorteile, für die man irgendwelche Kompromisse eingehen muss. Zum Beispiel bei Microservices, jeder jeder Microserviverfechter, jede Microserviver Verfechterin wird immer sagen, das hat den Vorteil, das fang ich auch immer so ganz kurz und das hat den Vorteil, ich kann Dinge unabhängig deployen, ich kann schneller Änderungen rausbinden, ich hab mehr Isolation zwischen diesen Microservices, Ich kann Dinge einfacher ausprobieren. Ich muss nicht überall die gleiche Technologie verwenden. Ich kann son Ansatz machen. Das Ganze wird kleiner und isolierter und damit sind die Einzelteile besser zu managen, ja. Und ich habe mehr Evolutionsfähigkeit, bla bla bla. Zur Liste 20 50 behauptete Vorteile von Microservices. Und alle werden auch sagen, aber dafür hab ich eine gewisse Komplexität. Ich hab viele von diesen Dingern. Ich muss die irgendwie verwalten. Ich muss überlegen, ich muss mich entscheiden, wie abhängig oder unabhängig sind die? Wenn die nämlich nicht unabhängig sind, da muss ich mir überlegen, ob das Ziel, was ich vielleicht damit erreichen will, eigentlich erreicht wird. Also es gibt immer ganz viele Trade offs. Und ich muss mein aktuelles Problem dagegen messen. Also das ist das ist auch überhaupt keine abstrakte, abstruse theoretische Übung, die nur irgendwelche Spinner machen. Das macht man eigentlich immer. Das macht auch jeder Entwickler und jede Entwicklerin im Kleinen. Also ich hab hier irgend eine kleine Aufgabe zu lösen und überlege ich, mach ich das Ganze mit 'nem Shell Skript oder mit 'nem Ruby oder mit 'nem Paul Programm oder von mir aus mit 'nem Visual Basic Programm. Oder nehm ich dafür eine eine kompilierte Sprache? Mach ich da mach ich da 'n UI oben drauf, mach ich das Ganze zu 'ner Webanwendung, was auch immer. All diese Dinge haben Vor- und Nachteile und davon wähl ich das aus, was am besten zu den Anforderungen passt. Das wäre ein guter Prozess und so sollte es eigentlich sein. Ist es leider nicht immer. Es gibt viele Gründe, warum man das eben nicht tut. Also der der vielleicht Offensichtlichste ist, man kann die eine Sache und die andere nicht. Die eine kann man beurteilen. Man weiß auch vielleicht, dass sich nicht so ganz gut passt, aber man weiß auch, was alles, wie man das vielleicht trotzdem hinfummeln kann. Ne, also ich hab zum Beispiel Leute gesehen, die haben die die waren sehr, sehr gute PHP Entwickler. Ist jetzt nicht meine Haus- und Hochsprache, ich kann damit nicht umgehen, aber es waren sehr, sehr gute PHP Entwickler, die damit normalerweise Webanwendungen bauen. Und weil das die Technologie war, diese kannten haben sie damit eben auch eine ganze Reihe von von Badge Prozessen gebaut, also Kommandozeilenozeilenprogramme, ne, die im Prinzip Multi Trade irgendwas tun oder parallel irgendwas tun sollten. Das war jetzt nicht unbedingt die allerbeste Wahl. Da hätte man was anderes nehmen können. Aber ich will gar nicht sagen, dass das falsch ist, weil die die Menschen, die da involviert sind, sind ja ein Teil des, ist ja ein Teil der Rahmenbedingungen unter Umständen. Also wenn ich das Team nicht austauschen kann und wer will und sage, das sind diese Leute, die können das schon, das können sie nicht. Klar würd ich das vielleicht lieber in c oder in Java oder in C-Sharpe oder was auch immer programmieren, aber dann müssten die das erst lernen und das sind auch wieder Risiken und die wollen das auch gar nicht, die finden das doof. Dann treff ich vielleicht bewusst die Entscheidung, die machen das trotzdem da drin. Kann sein. Kann auch sein, dass ich sage, nee, also hier, das nach allem, was ich jetzt analysiert habe, ist, hier die beste Variante, hab ich noch nie im Leben benutzt, aber ist offensichtlich das Richtige und in dem Projekt leiste ich mir das und probier das aus mit, ne. Das ist das jetzt komm ich ja nicht auf das, was Du vor 10 Minuten, bevor ich angefangen habe, so lange vor mich hinzuplapper, schon gefragt hast, was mache ich denn, das rauszukriegen? Also am schönsten ist es natürlich, wenn ich das relativ gefahrlos ausprobieren kann, ne. Am gefahrlosesten kann ich es in 'nem Spielprojekt ausprobieren, also an an dem niemand Interesse hat, ist aber irgendwie am witzlosesten. Und irgendwie gibt's viele Abstufungen zwischen dem und dem hochkritischen Produktionssystem. Wenn ich zum Beispiel ein System habe, das sone sone modulare Architektur hat, also irgendwie so was Microservices Server Contained Systems mäßiges, da kann ich Experimente vielleicht an 'nem kleinen Teil machen. Ich muss nicht gleich mein ganzes System in oder schreiben, aber ich kann mir da son kleines Ding nehmen, dann liest sich das alles gut, das programm ich mal aus. Und wenn das richtig klasse läuft, hab ich danach 'n tolles Beispiel. Und wenn das total ätzend schief gegangen ist und schmeiß ich's weg, kann ich auch 'n gutes Beispiel und bauste neu mit PHP oder c plus plus oder was auch immer meine Außennotsprache ist. Also Experimente sind durchaus notwendig, ja. Vorher würd ich mir selber nichts glauben, bevor ich's nicht mal ausprobiert habe oder hilft sozusagen das Team, das es tut, das nicht ausprobiert hat, muss ja nicht selbst sein. Aber bis dahin kann man durchaus auch eine Menge einfach auf Basis der Informationen, die man so findet, entscheiden. Das Microservices Thema ist so ein wunderbares Beispiel, weil das zeigt auch 'n anderes, sehr bekanntes Antipatter, das ist das Cargo Culting. Ja, also Cargo Culting ist im Prinzip, ist ja wohl das Kennt ihr das? Kennt ihr den kennt ihr den Begriff?
Fabi: Nee, das
Jojo: ist ja nicht.
Fabi: Erklär's gerne.
Stefan Tilkov: Ich krieg die Geschichte nicht mehr so ganz genau zusammen, aber es war, glaub ich, so, dass irgendwann im Zweiten Weltkrieg hatten die Amerikaner irgendwo in 1 Gegend, in der Menschen lebt, die noch nie vorher Flugzeuge gesehen hatten, eine Basis eingerichtet, sone Militärlandebasis. Die sind dann immer da gelandet, so wurde wurde wurde ein kleiner Flugblatt betrieben. Und dann da wurden eben auch Nahrungsmittel auf diese Insel transportiert. Und irgendwann haben die, also die Amerikaner abgezogen, haben diesen Flughafen ausgelöst. Und dann haben die Leute, die dort wohnen, versucht, die Flugzeuge wieder zu holen, indem sie Dinge gemacht haben, die so ähnlich aussahen wie das, was vorher war. Zum Beispiel Feuer angemacht am Rande der der Fläche und gewedelt mit irgendwelchen Dingen in der Hoffnung, dass davon Flugzeuge kommen. Jetzt ist die Story vielleicht nicht so geil, weil sie son bisschen so koloniale Herablassung darstellt. Aber nein, ich glaub der Begriff halt, den Carokalting, ja, aber ich glaube, dass ich das damit Das ist das machen ganz viele Leute. Also die Firma da drüben, die hat 'n total cooles Produkt, die ist richtig stark, die wird von allen bewundert und die macht x. Wenn ich auch x mache, dann bin ich bestimmt auch total cool und werde von allen bewundert. Und wenn ich jetzt, wenn das der Grund ist, warum ich eine Architekturentscheidung treffe, ist das der sichere Weg ins Verderben. Ja, weil ich mach dann Microservices nicht, weil ich weil die gut sind, sondern weil man das eben so macht. Wenn ich das höre, das macht man heute so. Das krieg ich, werd ich immer wahnsinnig. Obwohl ich Microservices durchaus gut finde, ja, ist das nichts, was ich für eine gute Basis für eine Architekturentscheidung halte.
Jojo: Du sagst aber, Du musst halt ganz stark den Anwendungsfall eigentlich dann betrachten. Also nur weil jetzt, wie Du's ja auch in einem Vortrag von dir gesagt hast, Netflix zum Beispiel Microservices nutzt, heißt das nicht, dass es auch für dein Projekt letztendlich der der richtige Ansatz ist. So sieht's aus. Ich meine, vielleicht
Stefan Tilkov: machst Du eine Videostreaming Plattform für viele 100000000 Benutzer, dann ist Netflix 'n 'n super Rolemodel, ja? Aber wenn Du eine Bankinganwendung für 300 parallele Benutzer machst, ist es vielleicht nicht das Richtige. Könnte ja sein.
Fabi: Ja, das stimmt schon. Wir hatten auch jetzt vor einiger Zeit, als wir unser Backend neu geschrieben haben für eine unserer Spiele, haben wir uns auch für einen Microservice Ansatz entschieden, weil wir halt im Vorhinein uns auch schon stark angelesen haben und so und die die Vorteile, die Microservices eigentlich so auf dem Papier, wir dachten für uns für uns da sind, also wirklich grad diese unabhängige Skalierbarkeit, dass wir sie unabhängig entwickeln können, unabhängig deployen können, waren einige Dinge, die wo wir auf jeden Fall dachten, das ist eigentlich etwas, was wir definitiv brauchen oder was worin wir einige Vorteile gesehen haben. Unter anderem auch zum Beispiel, dass da jetzt so Microservices haben, natürlich unsere Domains ganz klar getrennt sind. Ich hatte nämlich vorher auch mal bei Monolithen die Problematik, dass manchmal vielleicht die Domains nicht so ganz klar getrennt waren, weil man eine Monolit ja die Möglichkeit hat, auch mal über Domains hinweg vielleicht etwas zu tun, weil das nicht von der Code Struktur her so untersagt ist. Aber uns war klar, als wir die Entscheidung getroffen haben, hey, es kann sein, dass Microservices am Ende keinen Sinn machen. Das heißt, wir haben's schon so aufgebaut, dass wir relativ einfach, indem wir unsere API Schicht wieder wegwerfen, auch daraus wieder einen Monolithen bis zu 'nem gewissen Grad machen können. Und wir haben jetzt erkannt, dass eigentlich am Ende von den Vorteilen, die wir dachten, die wir haben, nur noch geblieben ist, dass unsere Domains ganz klar getrennt sind, so. Das ist auf jeden Fall auch 'n Punkt, den wir supergut finden, aber halt im Vergleich zu dem, was wir als Negativpunkte sehen und zwar 'n sehr hoher DevOps Aufwand. Wir sind halt, das muss man mal sehen, wir sind eigentlich nur ein Team, das alle Microservices macht, vielleicht auch etwas, was wir forschen hätten riechen können so, dass Microservices in 1 großen Firma mit verschiedenen Teams noch mal mehr Vorteile ausspielen. Wir hatten erhöhten Devops Aufwand, eigentlich erhöhten Entwicklungsaufwand, weil wir immer mehrere Container hochfahren mussten für die einzelnen Services und am Ende war es, obwohl wir es so, zumindest im Nachgang so gut getrennt haben, wie wir, wie es irgendwie möglich war, war's dann doch so, dass Features selten nur einen einzigen Service betroffen haben. Und wo wir jetzt am Ende gemerkt haben, okay, eine Architektur, die für die wir uns am Anfang entschieden haben, hat dann einfach dem Ganzen nicht standhalten. Wir wussten das schon vorher, dass das eine Gefahr ist so und haben dementsprechend dann danach auch modelliert, dass wir das leicht wieder aufbrechen können. Ja, aber das fand ich auf jeden Fall dann durchaus schon noch mal eine interessante Erfahrung, weil es war 'n relativ durchaus auch 'n hoher Invest, bis wir das erst mal so aufgesetzt hatten. Und da zumindest, weiß ich jetzt nicht, wenn ich jetzt noch mal rückblickend schaue, ob wir damals eine bessere Entscheidung hätten treffen können, so. Aber es ist dann durchaus noch mal interessant, wie der am Anfang auch gesagt hast, so wenn man sich mal dafür entscheidet, es zu verändern, ist Architektur der Teil, der dann sehr teuer ist. Also er ist er ist teuer zu verändern, war's jetzt zum Glück nicht so, aber die initiale Entscheidung war schon relativ teuer. Deswegen hab ich son bisschen nachgefragt, was man in in dem Zuge noch besser machen kann, weil ich doch schon glaube, dass man einige Dinge halt auch erst merkt, wenn man sie auf Scale testet so. Ob dann wirklich diese ganzen Vorteile, die man sich vorher auf dem Papier ausmalt, halt auch wirklich funktionieren.
Stefan Tilkov: Also ich weiß nicht, ob ich schon gesagt habe, dass man uns ganz viel Geld geben kann. Ja, ich
Fabi: weiß nicht. Wann Dennis, hast Du's gehört? Ja, aber
Dennis: vielleicht kann ich da noch eine Frage davor, die wahrscheinlich in eine ähnliche Richtung geht. Vielleicht kannst Du auch noch ein bisschen dann auf InnoQ nämlich eingehen, weil ich mich nämlich dann auch so ein bisschen frage. Also klar, auf der einen Seite sagst Du, man muss das immer Fall für Fall unterscheiden, aber gerade wenn man son Unternehmen hat wie Du und wo es auch viel diese Entscheidung geht und wo man sich irgendwie Projekte anguckt, muss man wahrscheinlich unter euch, würdet ihr wahrscheinlich, wenn ihr 'n Projekt seht, trotzdem irgendwie das Gleiche entscheiden oder irgendwelche Diskussionen darüber führen. Vielleicht kannst Du da auch noch in dem Zuge noch mal kurz drauf eingehen, wie man da son gemeinsames Verständnis dann trotzdem für entwickeln kann vielleicht.
Stefan Tilkov: Also, wir sind, glaube ich, jetzt 170 Leute oder so. Und ich bin mir jetzt sicher, dass wir 340 Meinungen zu jedem Thema haben. Also, wir haben einfach da ganz viel Diskussion über diese Dinge und ich fände es tatsächlich schlimm, wenn wir eine zentrale einheitliche Firmenmeinung hätten. Es gibt schon son paar Grundwerte, aber son Grundwert ist dann eher so was wie die Architektur sollte der Problemstellung angemessen sein. Und wir machen Technologie nicht zum Selbstzweck, sondern im Sinne, dass am Ende was Gutes rauskommt. Und der Endanwender oder die Endanwenderin, wer auch immer die Leute, die das Zeug am Ende benutzen, das sind die, für die man ein System baut und nicht nur die Leute, die einen zufällig dafür bezahlen, das zu bauen. Also das sind schon das sind so Werte, auf die wir uns alle einigen können. Aber bei technischen Entscheidungen, da können wir immer heftig diskutieren. Trotzdem gibt's son paar son paar Mehrheitsdinge, die sich irgendwie im Laufe der Zeit ergeben und da findet man zumindest sagen wir mal viele Leute bei uns, die diese Meinung haben. Also es gibt zum Beispiel viele Leute bei uns, die skeptisch sind, was diese sehr fein granularen Microservices angeht, ne, sondern die eher son son grobgranularer. Also das heißt, das benutze ich immer diesen Begriff selfcontainct Systems, weil ich Microservices, da finde ich den Namen schon so doof, ja. Also ist das Micro blöd und ich find das Service blöd. Ich kann auch gleich erklären, warum. Ich find aber die Grundidee, diese unabhängigen Deployment Units zu haben, die finde ich sehr gut, weil die hab ich tatsächlich auch schon in der Praxis funktionieren sehen und die hat tatsächlich 'n Mehrwert gebracht. Das hat, das ist ja auch eine persönliche Erfahrung, ne. Wenn man gesehen hat, dass es gut funktioniert, dann kann man das in bestimmten Fällen anwenden. Aber ich glaube, es gehört immer dazu, dass egal, wie toll man irgendeinen Ansatz findet, man sich immer bewusst macht, ob man in der aktuellen Situation, wo man ihn empfiehlt, das tut, weil er wirklich zu dieser Situation passt oder nur deswegen, weil man sich so dran gewöhnt hat, dass das schon immer passt. Das da ist man selber, also muss man immer son gesundes Misstrauen gegen die eigenen Entscheidungen haben. Das gehört, glaube ich, auch dazu, dass man einfach immer sich selbst hinterfragt. Also Architekturen anderer Leute bewerten ist der eine Teil, das ist immer leicht. Man muss aber die eigene Architektur auch kontinuierlich bewerten. Es gibt so, auch da gibt's alle möglichen Anti Patterns. Also ein ein Anti Pattern, wenn wir nicht immer, Emotional Miss Attachment. Das ist, wenn Du dich an etwas so verliebt hast, dass Du dich davon nicht trennen kannst, also Du hast irgendwie eine coole Bibliothek gebaut, ja, die da waren auch alle total begeistert und was sie so weiterentwickelt ist, sind immer noch alle begeistert und dann wird die Stimmung son bisschen neutral und dann kommt irgendjemand und sagt, also ich würd das lieber nicht benutzen. Ich kenn was anderes, als es Open Source ist, viel besser. Und dann spürst Du selbst wieder son Widerstand, weil das kann doch nicht sein. Also ich hab doch all die Zeit investiert in dieses Ding. Es hat mich total irrelevant, wie viel Zeit Du in der Vergangenheit da investiert hast. Die Frage ist ja, wie viel es dich jetzt kostet, dieses Ding zu benutzen, statt das kostenlose oder günstigere Open Source oder sonst wo so woher stammende Produkt. Also das ist, da muss man eben sich sehr, sehr hinterfragen die ganze Zeit. Oft auf dieses konkrete Thema, diese ganze Microservediskussion zurückzukommen, da da gab's schon sehr lange Diskussionen. Ich glaube, immer, wenn etwas gefühlt nur positiv dargestellt wird, also wenn etwas gehypt wird, dann lohnt es sich immer auch zu gucken, wer sagt denn was dagegen? Und was sagen die Leute dagegen? Und irgendwie so zu überlegen, also haben die vielleicht auch 'n Punkt und wenn ja, welche? Und wie kann ich das adressieren? Also hier mal 'n anderes, was vielleicht noch gehypt da ist, diese ganze Serveress Geschichte, ne, also so was wie ABS Lambda oder so. Das ist cool. Ich find das cool. Ich find das ist beeindruckend, wie schnell man damit irgendwas machen kann. Ich finde die Idee selber, sag ich mir noch mal was dazu, die Idee, keine große Infrastruktur selbst aufzusetzen, etwas zu benutzen, finde ich finde ich total klasse, kann ich total nachvollziehen. Deswegen klingt das für mich wie 'n interessanter Ansatz. Also ich hab 'n paar Kollegen, Kolleginnen, die das verfolgen und die das benutzen und die damit richtig, richtig coole Sachen in absolut minimaler Zeit bauen. Das spricht alles dafür, dass das 'n toller Ansatz ist. Und jetzt guck ich mich was Leute dagegen sagen. Da gibt es ein Argument dagegen, das sagen die meisten dieser Ansätze, die verheiraten dich sehr mit irgendeinem Anbieter. Also machste jetzt ne, so ABS Lambda Zeug bist Du halt mit Amazon verheiratet, machst Du das Ganze bei Azure, Microsoft wartest oder bei Google Ads irgendwo. Und das kann man machen. Da kannst Du vielleicht Bibliotheken ansetzen, die versuchen, das wegzukapseln. Okay. Ich bin 1, der sagt, also für mich sieht das alles gut aus, aber irgendwie hab ich son nagendes unangenehmes Gefühl in der Magengegend bei dieser Vorstellung, dass meine Fachlichkeit auf so viele kleine nebeneinander stehende Funktionen verteilt ist. Ich hab das Gefühl, da fehlt irgendwie sone organisierende Struktur. Ich kann mir nicht vorstellen, wie man ein großes System damit baut. Für mich sieht das alles 'n bisschen aus wie Oracle, PDF, SQL, Datenbubräger and Cool. Ich weiß nicht, ich bin son bisschen skeptisch. So, und das kannst Du dir anhören und dann kannst Du dir entscheiden, was Du damit machst. Vielleicht ist die Entscheidung dann, okay, wir probieren das erst mal in 'nem kleineren Projekt aus Gewalten. Im Blick fühlt sich das immer noch wartbar an, also oder ist das jetzt schon vielleicht nach 2 Monaten, in denen ich mit 2 Leuten daran gearbeitet habe, hab ich dann schon Probleme zu kapieren, was da passiert? Dann ist das vielleicht 'n berechtigter Ansatz, ja. Oder wenn ich merke, ich muss jetzt irgend eine Preiserhöhung mitmachen von meinem Cloud Anbieter, die ich nicht mehr mitziehen will und ich muss das jetzt machen, das ist dann vielleicht auch unangenehm, so was zu tun.
Fabi: Ja, definitiv. Und also was ich mich jetzt son bisschen frage, was sind denn so die Kenngrößen, nach denen ich eine Architektur oder auf was soll ich denn achten bei soner Architekturentscheidung? Also hattest der, also was Du jetzt schon genannt hattest, war ja einerseits, okay, es gibt Businessanforderungen, die ich habe. Das heißt sozusagen, wie können die sich verändern? Wie soll ich's zu meiner Applikation bauen, dass diese Businessanforderungen unterstützt werden? Und was ich mir jetzt ein Part, den ich mir natürlich auch gut vorstellen kann, ich mein, Du hast ja gesagt, das hängt davon ab, was bin ich für eine Firma? Wir sind nicht alle Netflix und dazu gehört ja auch irgendwie Entwicklergrößen oder Teamgrößen so. Und weil wenn ich jetzt bei bei uns schaue, ich glaube einfach, dadurch, dass wir eigentlich immer nur ein Team sind, was an einem Produkt arbeitet ist und selten mal, wenn arbeitet ein Team auf mehreren Produkten, aber niemals 2 Teams auf einem Produkt, glaube ich, werden wir ganz andere Architekturentscheidungen treffen als eine große Firma, die mit mehreren Teams an an einem Produkt arbeitet, so. Also hast Du da irgendwie so Also kann man Korrelationen ziehen von von Teamgrößen, Firmengrößen zu auch grundsätzlich, in welchen Architekturregionen wir uns beschäftigen? Also im Zweifel, was ich meinte, ich hab das Gefühl, dass dieser Microservice Ansatz nicht gemacht ist für ein Team, was sich ein Produkt kümmert, so. Ich, ist einfach son so im Moment meine Meinung son bisschen, ich glaube, die viele Vorteile von Microservice werden da nicht, hat man da ganz einfach nicht. Und deswegen frage ich mich, gibt's da Korrelation?
Stefan Tilkov: Also es kommt 'n bisschen drauf an, wie Du Skalierbarkeit meinst, wenn Du sagst, dass Du Microservices für Skalierbarkeit einsetzt. Ich seh's eigentlich meistens so, wie Du's grade geschildert hast. Ich bin der Meinung, dass man Microservices meistens einsetzt, weil man sich davon Skalierbarkeit während der Entwicklung verspricht. Ich verspreche mir davon, dass ich in einem großen, in 'ner großen Entwicklertruppe, wo ich viele Entwicklerinnen und Entwickler habe mit mehreren Teams, dass ich diese Teams parallel arbeiten lassen kann, ohne dass die sich ständig gegenseitig auf die Füße treten. Ich versuche Meetings zu vermeiden. Ich sage immer, das Ganze ist eine große Meeting Vermeidungsarchitektur, ja. Über Meetings sind blöd, die wollen nicht haben, das überlässt dich, da muss ich erst 'n Besprechungsraum finden und dann sone schreckliche Zoom Session aussetzt. Besser nicht, besser, ich mach das mit den Leuten, mit denen ich sowieso die ganze Zeit zusammenhänge, mit denen ich direkt eine Entscheidung treffen, dann diskutieren wir das aus während für Kickern und dann sind wir fertig und dann haben wir das entschieden. Und und Also das ist eine ganz andere, das ist eine eine ganz andere angenehmere Zusammenarbeit, wenn ich nicht diese diese diese großen Meetings haben muss, sondern kleinere Einheiten habe und dabei helfen mir Microsoftservices. Wenn ich also zum Beispiel 10 Teams mit jeweils 7 Leuten habe. Wenn ich insgesamt nur 7 Leute habe, dann ist das offensichtlich nicht das entscheidende Argument. Ist leider nicht, ich hab so eine so gespaltende Persönlichkeit, dass ich mich selbst von mir selbst isolieren muss und jetzt unbedingt meine eigene Arbeit auf dem System oder Endservice aufteilen will, find ich meistens keine gute Idee. Skalierbarkeit kann aber auch anders gemeint sein. Skalierbarkeit kann so gemeint sein, dass Du mit einem Team von 7 Leuten oder 10 Leuten etwas baust, was zur Laufzeit unbeschreiblich skalieren muss, was viele 100000000 von Benutzern braucht, wo vielleicht das Skalieren 1 Monolithen prohibitiv teuer wäre. Weil Du das ganze Ding eben skalieren musst und damit das ganze Rahmen und die ganzen Plattplatz und was auch immer Du noch an sonstigen Ressourcen hast, alles gleich skalieren musst. Vielleicht würdest Du davon profitieren, wenn Du nur die die 5 Services, die was mit dem Lesen zu tun haben, zehntausendfach installierst und die 2 Services, die Du was mit dem Schreiben zu tun haben, nur hundertfach oder so. Dann hast Du's eine, eine ganz andere Dimension, ist eine andere Dimension der Skalierung. Da würd es dir vielleicht helfen. Aber das ist eben das Kontextwissen, ne. Du hast, muss Kontextwissen haben über die Entwicklungsstrukturen, über die Entwicklungsumgebung, über die Laufzeitstrukturen, über die kommerziellen Aspekte, über die Roadmap, über das Wachstum, ja. Vielleicht ist es dir egal, dass Du jetzt 'n bisschen mehr bezahlst, wenn Du nur später, wenn dich, weiß ich nicht, wenn dich sone Pandemie erwischt oder so, wenn Du dann in der Lage bist, in Windes eine hoch zu skalieren. Also Zoom ist 'n cooles Beispiel, ja. Ich kenn deren interne Architektur nicht, weiß nicht genau, wie die aussieht, aber sie hat war offensichtlich gut genug, damit umzugehen, dass die Benutzerzahlen sich mal eben was verzehnfacht haben innerhalb von von wenigen Wochen. Es gibt nicht viele Architekturen, die das abkönnen. Also die haben offensichtlich was richtig gemacht. Die haben eine eine Wette auf die Zukunft gemacht und haben richtig gelegt.
Fabi: Ja, definitiv. Ich mein, Dennis, wollen wir mal 'n paar Fragen noch mal hier aus dem aus der Community einstreuen?
Dennis: Ja, können wir gerne machen. Eine fand ich nämlich auch sehr interessant, die Kevin grade gestellt hat. Du hast anfangs eingangs erwähnt, Architekten zeichnen Diagramme und hängen die an die Wand, was teilweise vielleicht auch ohne Nutzen dann ist. Kannst Du vielleicht mal 'n bisschen drauf eingehen, was Du denkst, wie viel und welche Art der Dokumentation eine Architektur denn angemessen ist und sinnvoll ist?
Stefan Tilkov: Also wenn das vorhin so geklungen hat, als fände ich Architekturdiagramme blöd, dann war das überhaupt nicht so gemeint. Ich find Architekturdiagramme total super, wenn sie nicht nur produziert, sondern auch konsumiert werden. Also wenn das nützliche Diagramme sind, dann ist das eine total hervorragende Angelegenheit. Und dazu zählt aus meiner Sicht erst mal 'n Strukturdiagramm, das sozusagen die Bausteinsicht meines Gesamtsystems darstellt, also aus welchem. Erinnert euch an die Definition, welche Elemente, welche Beziehungen zueinander? Das sollte ich bitte irgendwo visualisieren können. Da möchte ich eigentlich nicht Datenhaltung, Logik und User Interface sehen, das generische Architektudialräume, das ich überall verwenden kann, sondern lieber etwas, das mir sagt, keiner, es gibt hier Billing und Accounting und Katalog und Suche und was weiß ich. Es gibt hier diese Komponenten und die hängen auf diese und jene Art miteinander zusammen, weil das ja ganz viel beeinflusst von dem, was ich zum Beispiel parallelisieren kann, was ich in welcher Reihenfolge ändern kann, was Auswirkungen auf was anderes hat. Also es ist absolut nützlich, so was zu machen. Eine Kontextsicht ist was extrem Nützliches. Also das ist drin und das ist draußen. Das sind die Extension Stellen, mit denen ich mich auseinandersetzen muss. Was ich sehr nützlich finde, sind an den Stellen, an denen ich vielleicht komplexe Abläufe illustrieren will, so was wie Sequenzdiagramme. Muss jetzt nicht UML sein, ich hab überhaupt nichts gegen UML. Ich bin alt genug, dass ich da keine Berührungsängste habe. Wer UML nicht mag, der kann sich ja was eigenes malen, Hauptsache es irgendwo definiert.
Jojo: Aber ich glaub, das ist auch immer für mich immer so der Punkt, wenn ich dich kurz unterbrechen kann, dass ich mich frage, muss es denn immer 'n UML Diagramm sein? Kann ich nicht einfach sagen, wenn ich das mal an 'ner Tafel hatte und irgendwie mal irgendwo anders festgehalten habe? Reicht das eigentlich völlig aus? Ich brauch dieses Bild, ich brauch diese Übersicht, aber es muss nicht unbedingt irgend 'ner Software irgendwie abgelegt sein.
Stefan Tilkov: Also auch da, gibt wieder diese, es kommt drauf an, ne, Antwort. Also Natürlich. Ja, Du hast recht. Also ich mach ganz viele Diagramme oder meine Kollegen, Kolleginnen auch, wir malen ganz viele Diagramme auf irgendwelche Whiteboards. Die sind dann genau in dem Moment da, wenn sie gemalt werden und danach werden sie weggewischt. Vielleicht wird mittlerweile macht man 'n Foto und 'n Telefon, aber die werden nicht in eine Tour gepackt. Das ist absolut in Ordnung. Im Moment kollaborieren wir aber ganz häufig nicht, indem wir in einem Raum vor einem Whiteboard stehen, sondern wir kollaborieren mit irgendwelchen Werkzeugen. Der nützliche Effekt ist, das Ganze ist 'n bisschen strukturierter, man kann das einfacher teilen. Das ist bei uns schon sehr lange so, also wir kollaborieren schon lange auch remote und da sind Werkzeuge eine nützliche Sache. Notation ist nicht grundsätzlich was Schlechtes. Also Du machst da son Strich zwischen 2 Kästen, ist das jetzt 'n Datenfluss? Das 'n Kontrollfluss? Ist das in die Richtung oder in die Richtung? Ist das eine Abhängigkeit? Warum ist dieser Strich dick und der ist dünn? Warum ist der gestrichelt und der ist mit 'ner anderen Farbe gemalt? Also wenn Du mir das irgendwo sagen kannst, ja, prinzipiell, also ich finde es schlecht, wenn die Notation, die Du da verwendest, dich einengt, wenn die dazu führt, dass Du etwas machen musst, nur ein blödes Werkzeug zu befriedigen. Das finde ich sehr, sehr störend. Ich finde es aber genauso störend, wenn da wenn ich irgendwas konsumiere will und ich verstehe nicht, warum warum diese Kisten gleich aussehen, obwohl sie sowas völlig anderes sind. Und das passiert bei so ad hoc hingemalten Diagrammen eben sehr schnell. Deswegen, also es gibt nicht die eine richtige Antwort, sondern es muss eben so formal sein, wie es wie es zu der zu den Anforderungen passt. Auch da kann man sich die Zielgruppe überlegen. Wer soll das konsumieren? Ja, manche Leute verschreckt mit 'nem UML Diagramm. Es gibt aber auch Dinge wie zum Beispiel ein ein State Chart, ja, das das gab's auch schon vor UML, das hat sich die UML einfach gegriffen und wird auf mit aufgesogen. Das ist 'n supernützliches Diagramm, ja? Ich will mir fällt keine bessere Notation ein, Statusübergängekomplexe darzustellen, eine Lifecycle von irgend 'ner Order oder irgend 'nem anderen Objekt darzustellen. Warum soll ich das nicht mitm State Chart machen, sondern wir was anderes ausdehnen?
Fabi: Ja, es klingt doch gut. Es klingt so, ich mein, Kevin, Du kannst ja mal schreiben, ob das deine Frage beantwortet hat, aber klingt auf jeden Fall sehr gut. Ich lass uns doch direkt noch noch eine weitere Frage einstreuen, weil das son bisschen ja, ich mein, da merkt man wieder, es hat dann doch viel mit Arbeitsweisen und auch den der Firmenkultur und so was zu tun. C-TutorialsGerman schreibt, was ich öfters erlebe, ist, dass Architektur durch das Projektmanagement maßgeblich bestimmt wird, von Entwicklerteams aber nicht mitgetragen wird. Und ja, ich glaube, das beschreibt etwas, was ich mir durchaus vorstellen kann, was ihr als Berater ja auch durchaus das ein oder andere Mal vorfinden werdet. Also das sozusagen eine Ebene, sei es jetzt das Projektmanagement in dem Fall, über eine Architekturentscheidung und die, die sie umsetzen, eben nicht mittragen, weil sie wahrscheinlich auch nicht im Entscheidungsprozess mit drin sind, so. Wie sind denn da, ja, wie sind da eure Erfahrungen und wie kann man so was am besten umgehen?
Stefan Tilkov: Also das kenn ich sehr gut. Ich glaube, das war vor 20 Jahren schon eine bekloppte Idee. Also ich so meine ersten, also In und Tür gibt's seit 20 Jahren, ja. Ich selber mach das jetzt seit fast 30. Und diese diese Idee, dass irgendwelche Leute die Architektur machen und irgendwelche anderen Leute, die dann umsetzen, die war schon immer falsch. Das war schon immer eine schlechte Idee und es wird auch immer eine schlechte Idee bleiben aus ganz, ganz vielen Gründen. Also erstens, es funktioniert einfach nicht gut. Es funktioniert auch für die Leute nicht gut, die sich die Architektur ausgedacht haben. Also es ist eine Illusion, dass man damit die eigenen Vorstellungen umgesetzt bekommt. Das Einzige, was man damit bekommt, ist 'n unzufriedenes Entwicklungsteam und ganz, ganz viel Ärger im Arbeitsalltag. Also es gibt keinen Grund, jemals so vorzugehen. Es ist immer besser, das anders zu machen. Und das kann ganz viele Dinge bedeuten. Also es gibt auch da auch bei uns sehr, sehr unterschiedliche Teamzusammensetzungen. Es gibt manchmal Teams, die praktisch nur mit Rechtsenioren Leuten besetzt sind, die sehr genau wissen, was sie können und was sie nicht können, deren Ego sich schon abgeschliffen hat und die einfach souverän das Projekt zum Erfolg führen wollen und gemeinsam Dinge ausdiskutieren. Und dann gibt's 'n Stand-up und dann diskutieren die, was Du anschließt, sondern na ja, ich will 'n bisschen hier mir mal entscheiden, ob wir mit der Architektur da links rum oder rechts rum gehen. Und dann ist relativ offensichtlich, dass diese 3 Personen sind, die das mal diskutieren sollten und dann verschwinden die. Und am nächsten Tag sagen, die werden das diskutiert. Wir haben 3 Alternativen diskutiert. Diese 2 verwerfen wir, aber diese eine halten wir für die besten. Die würden wir gerne in den Prototypen die nächsten 2 Wochen mal validieren. Und dann machen die das, dann stellen sie das vor und dann sagen sie, das haben wir jetzt entschieden, das ist der richtige Ansatz. Hat irgendjemand was gesehen, was wir übersehen haben und sagen alle, total cool, machen wir genauso. Das ist eigentlich, find ich, optimal ist toll. Wenn das so läuft, wenn ein Team so tickt, dass diese Architekturentscheidung und diese Architekturkompetenz dynamisch einfach je nach Thema bei den kompetentesten Leuten angesiedelt wird und alle das mittragen, ist eine absolute Traumsituation. Das gibt's, ist leider selten, aber es gibt das. Es gibt auch die andere Situation, da sind entweder sehr juniore Leute zusammengemischt mit sehr Senioren, was nicht unbedingt immer mit Kompetenz und Erfahrung und und Wissen probieren aber oft. Es gibt es auch, dass man zu viele senioren Leute hat, die alle unbedingt das so machen wollen, wie sie das für richtig halten und nicht akzeptieren, dass irgendwer anderer Meinung ist. Und in solchen Fällen braucht man vielleicht irgend eine andere Teammynamik und eine andere Struktur. Dann gibt's irgendjemanden, der oder die im Zweifelsfall eine Entscheidung trifft, sich Argumente anhört. Aber auch in dem Fall ist es so, dass so jemand unbedingt dafür sorgen muss, bei Ihnen vom vom Team zu bekommen. Also wenn ich wenn ich mit Architekten und Architektinnen rede, also so klassischen, früher trugen die immer Krawatte, tun sie heute nicht mehr, aber ne, mit soner klassischen Runde, wo ganz viele Architekten sind, dann sag ich immer, also für mich ist die wichtigste, unerkannte Aufgabe von Leuten, die Architektur machen, zu akzeptieren, dass sie im Marketing arbeiten. Ihr seid Marketing Leute, ihr müsst eure eigene Architektur vermarkten. Ihr müsst Leute überzeugen, dass die cool ist. Ihr müsst sie toll darstellen. Ihr müsst erklären, warum die diesen Fehler nicht hat, von denen die Leute das glauben. Ihr müsst sie auch mal modifizieren und ändern können, wenn euch Leute sagen, dass das blöd ist, was ihr euch da ausgedacht habt. Ihr müsst selber mit Hand anlegen können, wenn's drauf ankommt. Ihr müsst belegen, ihr müsst bereit sein, eure Meinung zu erinnern. Also es ist ganz, ganz wichtig, dass man das macht, wenn man will, dass son Projekt 'n Erfolg wird. Das Projekt ist ja nicht 'n Erfolg, wenn die Architektur auf Papier super ist, weil das System aber misst. Die Architektur ist nur dann 'n Erfolg, wenn das System, was am Ende herauskommt, gut ist und seine Architekturziele erreicht. Dass alles andere ist nur Mittel zum Zweck.
Fabi: Ja, krass. Also ich find diese den Ansatz mit dem, ja, man ist im Marketing als Architekt auf jeden Fall eine Sache, weil meine nächste Frage wäre gewesen, damals, als ich bei meinem ersten Arbeitgeber war, war ich eigentlich in der Entwicklung und im Innovationbereich tätig und dann hat sich die Firmenstruktur verändert. Und ich war auf einmal nicht mehr im Innovationbereich, sondern ich hing im Architekturbereich, weil mein Chef in die Architektur gegangen ist. Ab dem Zeitpunkt war ich auf einmal auf dem Papier ein Architekt. Aha. Die ersten 3 Wochen hat mich mein Chef auch noch meine alten Arbeiten machen lassen, aber irgendwann hieß dann, na ja gut, Du bist jetzt Architekt, jetzt mach doch noch mal die Architektur für folgendes System, so. Und wenn ich so an mein Ich damals zurückdenke, dass auf jeden Fall noch nicht der senore Architekt war, dessen Ego abgeschliffen ist, frage ich mich so, gibt es etwas, was Du mir als diesem jungen Architekten etwas mitgegeben hast, so einen Fallstrick, über den ich nicht fallen sollte, so? Wahrscheinlich der Erste ist schon mal, ich seh's als eine falsche Entscheidung, jemand, der so wenig Erfahrung hat, in eine Architekturrolle zu stecken, aber wenn Du jemandem, der am Anfang seiner seiner Karriere ist, einen Rat mitgeben könntest. Marketing hab ich mitgenommen. Gibt's da noch irgendwas, was Du so sagst, so passt darauf auf und fall darauf nicht rein.
Stefan Tilkov: Genau. Es ist halt, also das ist aber, glaub ich, jeder immer, wenn man in irgendeiner Form befördert wird und so klang das ja grad son bisschen, ne. Das war ja in gewisser Weise eine Beförderung eine andere Rolle, dann ist immer die Gefahr, dass man halt sich zu sehr in die eigene Wichtigkeit verliebt. Und das ist zutiefst Mensch, das kann ich aus persönlicher eigener Erfahrung sagen, ne? Ich war hatte, als ich sehr jung war, hatte ich auf einmal 'n Team mit Leuten und gefragt, coole Sache, 25 und hab da irgendwie 20 Leute unter mir. Sich total cool, hätte ich nie so gesagt, ja, vor 25 Jahren, aber hat sich schon irgendwie so eingefühlt. Und das ist, das finde ich erst mal normal, ja? Und man muss da einfach gegensteuern, wie bei allen anderen Dingen auch. Also es ist schon in Ordnung, man hat ja diese Verantwortung bekommen, weil man wahrscheinlich irgendwas erreicht hat, irgendwas gemacht hat in irgend 'nem anderen Kontext gezeigt hat, dass man das kann. Und die Leute, die das mit einem gemacht haben, erwarten auch zurecht, dass man dieser Verantwortung gerecht wird und vielleicht im Zweifelsfall Dinge entscheidet. Aus meiner Erfahrung heraus, das, was am besten funktioniert, nicht nur in soner Architekten oder auch in allen anderen vergleichbaren Dingen, ist, dass man eben das Ganze kooperativ versucht. Dass man nicht versucht, durch die Position, also durch son Argument einfach nur deswegen richtig zu finden, weil weil's von demjenigen kommt, der irgendwie den höchsten Paygrade hat oder so. Das ist nie gut. Also es ist immer besser, das Ganze kooperativ zu machen. Und trotzdem, ich kann wieder dieses kommt drauf andingen, nicht zu versuchen, alles basisdemokratisch zu entscheiden, weil das ja auch nicht Sinn der Sache ist, ne, wenn das geklappt hätte. Ansonsten kann man hinterfragen, ob's generell eine gute Idee ist, das als Beförderung zu empfinden. Würd ich tendenziell vermeiden, also find ich eigentlich nicht gut. Finde, also bei uns zum Beispiel gibt es das nicht, bei uns gibt's keine Architekten und Entwickler, Architekten und Entwicklerinnen. Bei uns gibt's Consultants und Senior Consultants. Und das ist noch eine Frage der Erfahrung, ab 'ner gewissen Erfahrung. Wenn wir das mit Fug und Recht sagen können, dann ist man eben Senior Consultant. Und als Senior Consultant kannst Du in einem Projekt eine eine Entwicklerrolle haben und im nächsten bist Teamleiter. Das ist, also das ist sehr, sehr, sehr, sehr dynamisch, weil das eben auch von Projekt zu Projekt sehr anders ist.
Dennis: Diese Unterscheidung zwischen Architekt und Entwickler gibt
Fabi: es aber trotzdem? Ja, das ist trotzdem Ja,
Stefan Tilkov: das ist bei uns halt 'n bisschen, weil wir eine Consultingfirma sind, ist das bei uns 'n bisschen anders als, glaub ich, in anderen Organisationen. Bei uns hängt das eben sehr vom Projekt und vom Kunden ab. Ne, wir haben wir haben kein vorgefertigtes Modell von Rollen im Projekt, sondern wir wollen halt, wenn wir Also also ich muss auch noch sagen, es ist auch unterschiedlich, wie stark wir involviert sind. In manchen Projekten sind wir einfach nur Sparringspartner und und helfen 'n bisschen mit. In anderen Projekten arbeiten wir mit anderen Firmen oder mit den Mitarbeiter Mitarbeiterinnen des Kunden zusammen und machen gemeinsam irgendwie mit 'nem Team von 50 Leuten, von denen wir vielleicht 10 stellen irgendwas. In wieder anderen Projekten gibt's beim Kunden überhaupt keine technologische Kompetenz, da machen wir alles von Anfang bis Ende. Und je nachdem, was für eine Situation wir da vorfinden, gibt's halt bestimmte Aufgaben zu erledigen. Und die mappen wir dann auf eine Menge von Leuten, die wir verfügbar haben. Das ist bei uns nicht 1 zu 1 zugeordnet. Also wir haben so Leute, die eher son Product Owner Schwerpunkt haben, aber auch da gibt's welche, die sind sehr stark im UX Umfeld und andere, die sind eher designmäßig und wieder andere sind eigentlich Entwickler. Und genauso gilt das für alle anderen Rollen auch, gibt's so grobe Clusters, so grobe Gruppen, aber eigentlich sind's immer die Individuen, die Personen. Sodass ich weiß, also wenn diese, wir wissen, wenn diese 5, 6, 7 Leute zusammen sind, dann ist eigentlich alles abgedeckt, was man in diesem in diesem Brief braucht. Das ist bestimmt anders, wenn Du in 'ner Struktur bist, die Produkte entwickelt. Ist nicht 1 zu 1 übertragbar, was wir machen auf das, was was andere Organisationen da machen.
Fabi: Mhm. Aber find ich auf jeden Fall einen interessanten Ansatz, weil ich mein, im Endeffekt ist es bei uns, gut, wir sind auch eine kleine Firma, aber ja auch so, dass wir sagen, Architektur kommt einfach aus den Entwicklungsteams heraus. Ja. Und also eine eine Architekturfrage ist eben nicht was, was irgendwo entschieden wird, sondern einfach die Leute, die es umsetzen zusammen mit Product online oder Ähnlichen einfach diskutieren, was ist denn einfach passend fürs Projekt? Und deswegen find ich's aber interessant, dass ihr das eben schafft, in einem in 1 größeren Skalierung diesen Ansatz weiterzufahren, weil das ist ja schon immer etwas, was wo man sagt, keine Ahnung, wenn ich jetzt dieses Beispiel bringe mit, bei uns ist das so nicht, dann sagt man vielleicht mein früherer Kollege, der noch immer noch im Enterprise arbeitet, na ja gut, aber wir sind halt auch 'n Enterprise, bei uns würde das so nicht funktionieren. Würdest Du sagen, Du könntest ein Enterprise auch aufbauen ohne eine dedizierte Architektenrolle und sozusagen immer eine, wo Leute nur solche Querschnittsrollen haben aus Entwicklern und Architektur?
Stefan Tilkov: Also mein mein aktuelles Lieblingsorganisationsmodell, dem ich auch ganz viel durch die Gegend trenne, ist so 1, bei dem man versucht, die Teamorganisation und die die Domainarchitektur, also die die oberste Architekturstufe sozusagen in Einklang zu bringen. Weil das erfahrungsgemäß am besten funktioniert, interessant vorhin auch schon mal gesagt, hast immer, wenn Du irgendwie 2 Teams hast, die an einem Produkt rumschrauben, dann tut's weh, ne. Also
Fabi: Ja.
Stefan Tilkov: Ein Team kann vielleicht 2 Produkte oder 2 Systeme verantworten, aber wenn an einem System 2 Teams rumschrauben, dann dann fängt's an zu knirscht. Und wenn ich jetzt irgendwo eine große, eine große Domäne habe, eine große Fachdomäne, also ich bau 'n System, an dem vielleicht eine Anwendungslandschaft, an der vielleicht 100 oder 150 Leute arbeiten, also nur etwas Größeres, ist auch nicht riesig, ne, aber mal etwas größer, dann gibt es aus aus meiner Sicht Sinn, aus unserer Sicht Sinn, so etwas explizit und viel Hirnschmalz aufzuteilen in kleinere Einheiten. Nicht so Microservices der Mini Minisorte, sondern so einzelne Systeme. Und diese Systeme dann mit Teams zu verbinden und denen möglichst viel Autonomie zu geben. Dass Du sone autonome Zelle hast, die sich ein System oder 2, 3 Systeme kümmert und darf hohe Entscheidungskompetenz und hohe Entscheidungsgewalt haben. Und in dem Fall gibt's ganz viel Architekturkompetenz in diesen individuellen Teams, aber damit das Ganze funktioniert, müssen 2 Dinge übergreifend geklärt werden. Das eine ist eben genau dieser Schritt, also die Entscheidung, ob ich jetzt 3 oder 5 oder 27 Systeme mache, das muss ja irgendwer mal irgendwann entscheiden. Und dann gibt's eine Reihe, das das wären wir in der Domainarchitektur. Und dann gibt's eine Reihe von technischen Entscheidungen, die getroffen werden müssen, damit das ganze Zeug irgendwie zusammenspielt. Also vielleicht, welche Schnittstellenstandard benutzen wir oder wie machen wir unser Monitoring oder wie deployen wir, ne, also oder was ist unsere Cloud Strategie, was weiß ich. Also irgendwelche übergreifenden Sachen, die die sozusagen zwischen diesen Systemen irgendwie geklärt sein müssen. Das eine ist eine fachliche, das andere ist eine technische Dimension, also technisch schnell wieder Makroarchitektur und dann bleibt für die einzelnen Zellen die Mikroarchitektur übrig. Und für diese Domainarchitektur und diese Makroarchitektur, da braucht's irgendwie eine übergreifende Verantwortung. Und das kann man machen, indem man son Gremium bildet, wo aus jedem Team 1 hingeht und das tagt dann einmal die Woche oder so. Das ist ein Lösungsansatz. Man kann auch sagen, es gibt 'n kleines Team, da sind 2 oder 4 Leute drin, die machen nichts anderes, als sich darum zu kümmern. Und es gibt beliebige Mischstrukturen aus diesen Dingern. Das hängt sehr von der Organisationskultur ab und von der Einbettung in andere Dinge. Aber wenn Du wirklich 'n großes Unternehmen hast, es hat ja nicht 150 Leute in der Softwareentwicklung, sondern 85000, dann ist es natürlich noch wichtiger, irgendwie zu überlegen, was muss denn insgesamt zusammengehören und was will ich übergreifend entscheiden? Wo ist das totaler Quatsch, irgendwas übergreifend entscheiden zu wollen? Also dieses Loslassen können, Ach, Du hast vorhin nach Tipps gefragt, ne, für für junge Architekten und Architekten.
Fabi: Ja, ich nehm ich nehm noch ganz viel an. Mein junges Ich sammelt noch.
Stefan Tilkov: Genau. Wär noch ein Tipp, also dass man sich sehr genau überlegt, was genau man sich dann alles ans Bein binden möchte. Also am Anfang nimmt man sich immer zu viel. Man möchte immer alles standardisieren. Das muss alles jetzt gleich, jetzt machen wir endlich mal alles richtig jetzt. Wir haben alles aus 1 Hand mit einem Ansatz gelöst. Das ist eine ganz schlechte Idee. Also man sollte sich auf ganz, ganz, ganz, ganz wenige Dinge reduzieren, ganz wenige Regeln, ganz wenige Vorgaben, die dann aber durchaus strikt durchsetzt, also mit den kurbasierten Ansatz und Argumentation und so weiter und so fort. Aber wenig stringglend durchzusetzen ist viel, viel besser als Tausende von Sachen, die nachher sowieso keinen Schwein interessieren, was das klassische Problem von solchen Architekturabteilungen ist.
Dennis: Stefan, ich hör dir sehr, sehr gerne zu und ich guck nur sehr traurig auf die Uhr, weil wir uns langsam schon 'n bisschen dem dem Ende nähern. Gibt es noch irgendeinen Bereich von diesem Thema, den wir auf jeden Fall noch besprechen müssen, wo Du sagst, okay, das ist sonst nicht keine runde Folge, wenn wir das nicht noch ansprechen?
Stefan Tilkov: Also eine einzige Sache würde ich vielleicht noch sagen, das habt ihr mir gerade mal durch den Kopf, dass wir darüber nicht gesprochen haben. Ihr habt vorhin über die Anforderungen gesprochen. Also wo bekommt man die Anforderungen her? Oder wir haben das son bisschen diskutiert. Und da ist, glaube ich, ganz wichtig, dass man als als Architekt, als Architektin auch bereit sein muss, in die Bresche zu springen, wenn die einfach fehlen. Also fachliche Anforderungen sind meistens zu Genüge da. Aber Architektur beschäftigt sich eben auch sehr, sehr viel mit Anforderungen, die erst mal nicht offensichtlich sind, die nicht fachlich sind. Früher hat man aber nicht funktional gesagt, sagt, weil's nicht mehr so gerne klingt, so als wird da was nicht funktionieren. Das ist nicht gemeint, sondern gemeint sind all diese Qualitätsmerkmale, ja, also wie skalierbar ist das Ding, wie testbar ist das Ding, wie wartbar, wie wie portabel, ne, wie interoperabel, was weiß ich? Also alle möglichen Faktoren, die auch alle wichtig sind, die insbesondere alle langfristig wichtig sind. Ja, Benutzbarkeit, Zugänglichkeit, Barrierefreiheit, also alles ist 'n so ist 'n richtig, das liegen mir enorm am Herzen, diese Anforderungen und die vertritt oft niemand. Ja, aber die Leute, die die Fachlichkeit vertreten, haben 'n anderen Job, die kommen eben aus ihrer Fachdomäne, die kennen das Geschäft, die kennen Geschäft, die kennen all diese Dinge. Und da finde ich's ganz wichtig, dass man das eben mal, dass man eben aus Architektursicht auch diesen anderen Punkt adressiert. Mittlerweile vermischt sich das son bisschen, dieses ganze Digitalisierungszeug, ja, großes Wort, führt dazu, dass Dinge wie klassisch rein technisches Implementierungsdet auf einmal ganz, ganz weit vorne auch in den fachlichen Anforderungen stehen. Das ändert also die Rolle schon son bisschen sowieso. Aber ich find das ganz wichtig, dass man als als als Architekt, als Architektin sich diese Rolle auch, dass man überhaupt diese Rolle auch annimmt und das akzeptiert, dass man eben auch Anforderungen definiert und mitgestaltet und sich son bisschen zum zum Anwalt des des Endanwenders oder der Endanwender macht und sagt, ja, kann man so machen, aber würd ich nicht machen, weil das will nachher, das will nachher keiner so haben, ja. Oder so was erwarten Leute nicht von sonem System. Entschuldigung, ihr könnt das so probieren, aber das wollt ihr nur deswegen machen, weil ihr nur Desktop Anwendungen kennt und eine mobile Anwendung funktioniert eben anders, ne. Eine Webanwendung funktioniert eben anders. Trennt euch mal von diesem alten Gedanken. Das macht man besser.
Fabi: Ja, das klingt doch gut. Also wenn ich jetzt noch mal an mein junges Architekten Ich zurückdenke, dann würde ich auf jeden Fall sagen, die Tipps, die Du auf jeden Fall gebracht hast, also ich werde auf jeden Fall meinem jungen Ich noch mal einen Brief schreiben und sagen, ich soll ein bisschen an meinem Ego feilen und sozusagen, ja, mir nicht zu viel von der Beförderung zu Kopf steigen lassen. Ich werd der Anwalt des des Users und schaue, dass ich auch da Anforderungen mit durchdrücke. Ja und würde ansonsten sagen, dass ich, ja, generell Diagramme nur so oder so viel mache, wie es halt notwendig ist, aber eben nicht alles überdokumentiere, nur das, was was am Ende auch konsumiert wird und ja, sag ihm am besten noch mal, schick ihm noch mal den folgenden Link und sag, hör dir den Rest noch mal im im Detail an. Ich glaub, wenn ich die Folge gehört hätte, hätt mein Jung und ich aber ihm von 'n bisschen was gebracht.
Dennis: Er hat vielleicht auch deinem alten Ich noch was gebracht. Ach das stimmt, ja. Cool. Sehr schön. Dann würde ich sagen, kommen wir noch zu unserer Rubrik, nämlich den Pick of the Days.
Fabi: Jo,
Dennis: dann frage ich dich mal als Ersten, was haben wir heute, was kriegen wir von dir als Tipp mitgegeben?
Jojo: Ich bin diese Woche eigentlich über 'n Tool gestoßen, was eigentlich jeder Chrome Browser für den Weg da mitbringt und was wir aber in der Vergangenheit eigentlich kaum genutzt haben, nämlich einfach der Performancetab, der wirklich sehr hilfreich ist, son bisschen genauer zu analysieren, wo grade es in der Ausführung der Webseite hängt. Und man hat auch die Möglichkeit, auch da sehr genau einzustellen, unter welcher CPU Performance. Also die CPU eigentlich runter zu regeln auf wirklich Low End Geräte, dich dann anzugucken, funktioniert man da in meine Seite dann immer noch. Und über die Flaame Creften kann man halt sehr genau identifizieren, wo passieren zum Beispiel Layout anpassen, die nicht notwendig sind und kann sehr genau letztendlich das Problem eingrenzen, das es eigentlich geht. Und ja, wir haben in der Vergangenheit, glaub ich, immer sehr viel auf alten Geräten getestet, zu sehen, okay, woran wo hängt das letztendlich, an welchen Bestandteilen. Und das hat die Arbeit sehr einfach, sehr vereinfacht, jetzt 2 Probleme zu identifizieren und die zu beheben.
Fabi: Habt ihr jetzt jetzt grad bei 4 Bilder ein Wort, im Web jetzt viel genutzt gerade, den Performance Tab?
Jojo: Genau. Also wir hatten natürlich, da ist speziell das Problem, dass wir Lotti für Animationen nutzen und die an manchen Stellen eben sehr inperformant waren. Und damit konnten wir halt genau identifizieren, wo es letztendlich bei dieser Lotti Performance oder bei dieser Lotti Animation zu den Performance Problemen kommt.
Fabi: Das heißt, die Dinge, die man eigentlich kennt, aber nie wirklich nutzt, so zumindest wir nicht. Klingt nach 'nem guten Tipp, müssen wir, glaube ich, auch bei Crystalblade auch noch 'n bisschen mehr nutzen. Ich glaube, wir könnten da vielleicht auch noch die ein oder andere Sache optimieren.
Jojo: Ich glaube auch sagen, der Tab an sich ist wirklich 'n bisschen komplizierter. Deswegen ist es gut, sich son paar Tutorials anzugucken, was da immer diese Flammegrafen gerade aussagen, wie man die Sachen interpretiert und dann hat man, ja, 'n Verständnis.
Dennis: Da wollte ich nämlich noch mal fragen. Ich glaub, das hatte mich auch mitbekommen, dass Du da 'n paar Sachen hier angeguckt hast. Vielleicht kannst Du in die Shownotes irgendwie ja noch 1, 2 Tutorials dazu hineinpacken, die dir den Einstieg erleichtert haben.
Jojo: Auf jeden Fall.
Dennis: Cool. Sehr gut. Fabi. Ich bin schon dran.
Fabi: Ja. Ich bring eine Kleinigkeit mit. Ich hab nämlich mich mit meiner Gartenbewässerung beschäftigt und ich dachte eigentlich, ich bin kein Heimautomatisierungsfreak. Hab aber gemerkt, nachdem man die ersten Sachen so mal macht, dass man dann doch denkt, warum ist das denn nicht automatisiert? Und da bin ich auf eine Kleinigkeit gestoßen und zwar den NodeMC. Das ist, wenn man man kennt ja den Raspberry Pi, man kennt den Arduino. NodeMC ist im Endeffekt son, na ja, eine Firmware als auch ein Development Board für so einen kleinen Chip, der sehr, sehr günstig ist, Wifi mit drin hat und man, wenn man eben diesen Node MQ Development Board nutzt per LUA supereinfach, ja, IoT Devices im Endeffekt schreiben kann, mit dem ich jetzt meine meine Automatisierung von meiner Bewässerungsanlage mal schreibe. Und irgendwie bin ich jetzt son bisschen in, ja, auf jeden Fall Spaß. Also ich kann sehr empfehlen, diese Note MQ zu kaufen, mal son kleines Development Board für 'n paar Euro und mal anzufangen mit einfachen Schaltungen, die mal zu steuern über son MQTT oder so was. Man kann auch 'n paar Lichter leuchten zu lassen. Es macht sehr viel Spaß für son paar Euro irgendwie wieder zurück in den Physikunterricht zu kommen und seine Entwicklerskills noch mal woanders nutzen zu können. Ich wahrscheinlich bin ich super spät auf diesen Zug jetzt aufgesprungen, aber ich hab noch mal gemerkt, wie viel Spaß sowas dann doch machen kann, wenn man mit sonem kleinen Gerät 'n bisschen spielt. Also NoiseCU kann ich dir empfehlen.
Stefan Tilkov: Bei mir
Dennis: hat's auf jeden Fall Interesse geweckt. Hier gibt's auch noch son paar Sachen, die ich noch gerne noch 'n bisschen mehr autonomatisieren hab.
Fabi: Also für, ich weiß gar nicht, ich glaub 5 Euro hat das Ding gekostet oder so und es hat allein Spaß gemacht, 'n paar LEDs blinken zu lassen, so. Also wenn's wenn's darin aufgehört hat und meine Bewässerungsanlage doch nicht gesteuert ist. Cool. Hat's schon Spaß gemacht.
Dennis: Sehr schön. Vielen Dank. Stefan, was haben wir bei dir?
Stefan Tilkov: Ich hab mir rausgesucht als Tipp Dark wie dunkel. Die Website ist Darklang dot com. Können wir durch die auch in die Shownotes packen, schätze ich. Mhm. Das eine sehr, sehr interessante Umgebung. Im Moment haben wir ganz viel ganz viele Projekte, in denen wir Infrastrukturen aufsetzen, Infrastrukturen aufsetzen, cloudbasierte, Kubernetis, sonst irgendwas Dinger. Und direct geht eigentlich eine Stufe weiter. Dann ist im Moment noch in soner Private Beta, also man muss seine E-Mail-Adresse eintragen und dann dauert's 'n bisschen, bis man da reingelassen wird. Die managen das grade noch. Und das ist aber eine Umgebung, in der man im Prinzip eine webbasierte IDE hat, mit der man in 1 überaus eleganten, funktionalorientierten Sprache Dinge entwickelt, die direkt live sind. Und zwar direkt in soner skalierbaren Infrastruktur, ohne dass man sich irgendwie darum kümmern muss. Aus meiner Sicht interessanter als son als son banaler Server das Ansatz, die ihn andere verfolgen, sondern auch nicht so die nächste Stufe, son bisschen, ja, Programmieren neu gedacht mit den Möglichkeiten, die man heute hat. Ist 'n cooles Zeug, muss man sehr schön mitrutsch.
Fabi: Okay. Und in was was programmiere ich da?
Stefan Tilkov: In Dark.
Fabi: Dass die Sprache ist auch Dark. Okay. Die Sprache ist auch Dark.
Stefan Tilkov: Genau, Sprache heißt Dark.
Fabi: Plattform und Sprache zugleich.
Stefan Tilkov: Genau, man baut damit halt Backends für irgendwelche Sachen, also HTTP Backends für irgendwelche oder andere Services, die man irgendwie benutzen möchte. Man kann damit dann wieder andere Dinge aufrufen, so 'n Integrationslayer bauen. Also im Prinzip, im Moment kann man damit nur Dinge bauen. Ich denke, UIs zu bauen ist wahrscheinlich auf der auf der Agenda. Die sind noch sehr, sehr früh in ihrer Entwicklungsphase und Venturecapital finanziertes Start up Dings halt, aber ziemlich cool. Okay. Und natürlich auch in Darkmode direkt optisch passt zum Jahr.
Fabi: Ja, sehr cool. Ich hab mich noch schon 'n bisschen rumgeklickt. Werde ich mir auf jeden Fall mal anschauen. Sehr cool.
Dennis: Sehr schön. Ja, wunderbar. Dann würde ich sagen, sind wir an dieser Stelle am Ende angelangt. Gerne noch mal, auch wir sind ja wie immer interessiert, ein Feedback. Also unter programmier Punkt bar Slash Feedback könnt ihr uns noch mal sagen, wie ihr diese Folge fandet und uns auch gerne sagen, was wir noch besser machen können. Wir haben jetzt, glaube ich, noch kein Teaserbild zum Einblenden, aber es hat sich heute erst ergeben. In 14 Tagen sind wir wieder live auf Youtube mit der nächsten Podcastfolge und zwar über Svelt. Mit Vanessa Böhner werden wir reden. Freu ich mich auf jeden Fall auch schon. Da hab ich nämlich noch nicht viel drüber gehört, was wir da für Einblicke bekommen.
Fabi: So als kleiner Teaser, steht hier. Also ich kenn mich auch noch nicht weiter aus als das. Ich bin auf jeden Fall auch mal sehr gespannt, so. Also, wenn ihr einen Radical New Approach wollt, dann seid ihr in 2 Wochen genau richtig. Genau.
Dennis: Stefan, vielen, vielen Dank, dass Du heute dabei warst. War eine sehr, sehr coole Folge. Danke für die Einladung. War super interessant. Und euch allen 2 schöne Wochen. Bis zum nächsten Mal.
Fabi: Bis dann. Bis dann. Tschau, tschau.
Jojo: Tschau.