 So, willkommen zur Carzone. Der Nächste ist über Softwarearchitektur und das ist eine der Sachen, die junge Programmierer früh lernen sollten. Und ich hoffe, das tun Sie auch. Eine Lösung für die Probleme, die wie Sie und unser Sprecher ist Big Alex und er hat Informatik studiert und ganz normale Karriere und hatte da ein Job in der Industrie und wurde dann ein Trainer. Konzultant und spricht über Projektmanagement und Architektur und redet darüber wann und warum Softwarearchitektur wichtig ist für Hacker und Maker und gibt eine einfache Einführung und hat einige Wochen konzentriert auf einen kurzen Videostream und hat versucht sein Bestes zu kämen. Softwarearchitekturen führen vielleicht manchmal zu einem nicht dokumentierten Spaghetti-Code oder einen riesen Matchklumpen. Vielleicht kann Big Alex bessere Beispiele geben in den nächsten 40 Minuten und bühnefrei. Ja, vielen Dank für die nette Einführung. Ich will gar nicht hier über Prototypen anfangen zu reden, aus denen dann Produktionssoftware wird oder sowas in der Art. Ich bin immer noch ein bisschen abgeschreckt davon und etwas, was auch nur, es ist einfach schwierig auch nur eine ganz einfache Einführung in der Architektur zu machen in 40 Minuten. Aber ich habe versucht, meinen Bestes zu geben, um eine Präsentation zu halten, die was zu sagen hat und ich hätte wirklich das besser wissen sollen. Ich wurde hier angekündigt und ich rede regelmäßig über Softwarearchitektur, wenn Leute wirklich sich damit beschäftigen wollen und man kann natürlich Stunden damit verbringen, auch nur über die grundlagenden Ideen zu reden. Aber warum ich diesen Vortrag gemacht habe, es gibt immer einige Dinge, die ich schon gerne gewusst hätte, als ich angefangen habe, mit komplexen Projekten zu machen und langfristige Softwareprojekte. Und ich will euch eine kurze Einführung geben, was Softwarearchitektur eigentlich ist, worum es geht und worüber man nachdenken sollte und wie man die sehen sollte. Und das Problem, was ich mit diesem Vortrag habe, ist, was mich mir noch mehr Angst macht, ist das Publikum von diesem Vortrag. Und viele kennen natürlich ihren eigenen Horrorgeschichten über Softwarearchitektur und Softwarearchitekten und als Hacker oder Maker müssen wir uns mit schlechter Softwarearchitektur auseinandersetzen. Und manche denken auch, dass Architekten Leute sind, die nicht mehr programmieren können oder wollen und alle haben auch schon mal jemanden getroffen in seinem Arbeitsleben. Leute, die Architektur Astronauten genannt wurden von Jules Bulski. Und er hat gesagt, es gibt einen tollen Rent über solche Architekten und er sagt, die sind so hoch in der Abstraktion und denken so abstrakt, dass das, was sie erzeugen, wirklich nutzlos ist. Sie machen noch High-Level-Abstraktionen und Ideen über das System. Aber die sind alle wunderbar, aber die nützen niemanden, der das implementieren will, irgendwas. Und wir wollen das natürlich auf jeden Fall vermeiden. Und die anderen Horrorgeschichten, die die meisten von uns wahrscheinlich schon mal gehört haben, ist, das heißt, konferenzgesteuerte Architektur. Und es gibt ganz tolle Topics, Themen, die gerade gehypt werden in der Gemeinschaft, in der Community. Und man braucht Microservices und der Kunde will Blockchains. Und es ist ein krisadampfender Haufen von Müll. Aber das ist, was der Kunde will oder was andere für wichtig halten oder was die führenden Architekten für wichtig halten. Das kommt von den Marketing-Vorträgen. Und das schadet eher den Entwicklern, wenn man das ohne gute Gründe macht. Ich will nicht sagen, dass alle diese Technologien schlecht sind oder schrecklich. Microservices kann durchaus Sinn machen, aber es muss einen Grund geben dafür. Und nicht nur einfach, weil irgendjemand gesagt hat, euren Projektmenscher gesagt hat, wir müssen jetzt eine Microservices-Architektur machen, weil Netflix oder Google das machen, es muss einen guten Grund geben dafür. Aber was ich machen will in diesem Vortrag, wir können nur wirklich einfach fundamentale Grundlagen von Software-Architektur streifen. Und ich will anfangen damit, wann könnte die Architektur für dich relevant sein, für Hacker und Maker, für diese Gemeinschaft, warum glaube ich, dass das wichtig sein könnte. Der nächste Punkt ist, worum es wirklich geht. Was meinen wir, wenn wir Software-Architektur sagen? Das ist, was ich wünschte, dass mir das jemand ganz am Anfang schon gesagt hätte, bevor ich wirklich mich damit beschäftigt habe mit dem Thema. Und dann, warum es wichtig ist. Und dann entweder gebe ich eine ganz kurze Einführung, was ihr machen könntet, um eine gute Architektur zu machen oder was eine gute Architektur ist, was immer das auch ist. Dann, wir reden darüber später dann noch. Und lass uns einfach mal mit einigen Annahmen anfangen. Warum sollte für dich Architektur relevant sein? Und warum sollte es dich interessieren? Was ich, was für ein Eindruck ich habe in der Chaos-Community, in der Chaos-Gemeinschaft, warum sollten sie sich überhaupt um Architektur kümmern? Was sie normalerweise machen ist, die machen das genaue Gegenteil von Architektur. Die wollen einfach nur Spaß haben mit der Technologie, neue kreative Nutzen finden von den Mittensachen. Aber wenn man wirklich ein System benutzen will in einem, auf eine andere Art, als es vorgesehen ist, dann hilft es wirklich eine gemeinsame Struktur finden oder Design regeln oder die Grenzen des Systems, was du dir anguckst. Und typischerweise jede Systemklasse hat Trade-offs und Kompromisse. Und es gibt dunkle Nebenstraßen und es wurden kurze Abkürzungen genommen, um es schneller auf den Markt zu bringen. Und die Software Architektur, möglicherweise kann dir die Architektur was darüber sagen. Für die Maker-Community ist es auch nicht unbedingt offensichtlich, warum wir Architekturen benutzen wollten. Ja, und einer, der nun umspielt mit Technologie und rumbastelt und Sachen machen will, dann ist es okay und dann braucht man vielleicht auch keine Architektur. Das kann völlig okay sein. Aber sobald du eine längerfristige Software bauen willst, eine nachhaltige und ein Framework oder eine Arduino-Applikation, eine Anwendung, die du vielleicht für eine längere Zeit benutzen willst oder du willst eine Gemeinschaft von Entwicklern und Benutzern bauen willst und dann kann man eigentlich nicht leben, ohne etwas von Software Architektur zu wissen. Und es kann ein ganz wichtiger Volksfaktor werden, damit es funktioniert. Und ohne Software Architektur will man das vielleicht gar nicht erst versuchen. Und die letzten Leute in unserer Gemeinschaft sind hier neben den Software-Professionals. Die müssen natürlich jeden Tag sich damit beschäftigen, aber die sociopolitischen Leute, die mit Netzpolitik sich beschäftigen, die Leute, die wirklich sicherstellen wollen, dass wir in unserem Alltagsleben bessere Software kriegen, von Regierungsprojekten zum Beispiel. Und das Ding mit der Software Architektur, da geht es nicht nur um technische Entscheidungen, sondern Projektversagen und Projekte, die schief gehen. Das ist nicht nur unbedingt, weil es schlechte Entwickler sind oder schlechte Architekten, sondern es gibt viele andere Probleme und viele andere Faktoren hier in IT-Systemen, die manchmal einen viel größeren Einfluss haben als die Technologie selbst. Und es gibt politische Gründe und der Kontext, warum people zu sehen, wenn Softwareprojekte schiefgehen und niemand was tut, auch in großen Organisationen. Und dieses Jahr hatten wir eine Gefälle von großen Softwareprojekten, die eine großartige Architektur hatten und waren aber nicht so erfolgreich wie kommerzielle Projekte, die keine so gute Architektur hatten. Das heißt, wenn man ein Politiker ist und dann will man vielleicht auch wissen, was dahinter steckt. Wovor wir weitermachen, wollen wir erstmal klären, was die einzelnen Termini bedeuten. Wenn ich von Softwarearchitektur rede, könnte es natürlich bedeuten, dass es Teil der Ingenieurwissenschaft und andere Bedeutungen von diesem Wort sind einfach, es gibt zum Beispiel die ISO Definition und das kommt eigentlich richtig auf den Punkt. Softwarearchitektur geht es um die fundamentalen Konzepte und Eigenschaften von dem System, was verkörpert wird in den Elementen und wie es dekomponiert wird, auseinandergenommen wird, wie die einzelnen Teile miteinander interagieren und wie es mit der Umgebung interagiert. Und das ist auch aus Sicht eines Programmierers noch wichtig. Und es geht auch um die Prinzipien von Design und Entwicklung des Systems, wie man es aufteilt in Untersysteme und was sind die Regeln für Kommunikation und Beziehung der einzelnen Teile untereinander. Und eine andere Bedeutung ist natürlich das, was man am Ende hat, was am Ende dabei rauskommt. Und das ist eben, das ist die Menge der Designentscheidungen, die, wenn sie falsch getroffen werden, dazu führen können, dass das Projekt stondiert wird, dass das Projekt beendet wird. Und am Ende ist es, wenn wir über Softwarearchitektur nachdenken, dann ist das einfach nur eine Eigenschaft des Systems, von einem IT-System. Und ein System hat einfach eine Architektur und das ist nicht die Beschreibung des verfolgten, des gewünschten Designs. Und es sollte auch nicht, manche behandeln das so, aber es sollte auch nicht von vornherein etwas gemacht werden in Enterprise-Architekt oder so, oder jemand gemacht von jemandem, der dir vorschreibt, wie du programmieren solltest. Das ist nicht die richtige Benutzung von Softwarearchitektur. Und das Problem ist, man kann natürlich sich entscheiden, das völlig zu ignorieren und das ist okay. Wenn du gute Gründe hast, das zu ignorieren, dann kannst du das machen. Aber man kann nicht keine Architektur haben. Man muss immer eine Architektur haben. Und wenn man sich nicht um die Architektur kümmert von dem System, was man baut, dann entwickelt es ein Eigenleben. Und wenn man nicht wirklich darum kümmert, die Architektur selbst zu formen, und wenn es einfach nur das Ergebnis deiner Designbescheidung ist, dann muss man damit leben. Und das kann ziemlich hässlich werden, je länger das Projekt weitergeht. Und am Anfang von diesem Projekt ist jedes richtig schön. Man hat ganz wunderbare Sachen. Und je mehr Release man macht, desto schwieriger wird es, Änderungen zu machen. Und das ist ein echtes Problem, wenn man sich nicht um seine Architektur kümmert. Und die Architektur sollte einem eigentlich helfen dabei. Lass uns mal ein super einfaches, sehr vereinfachtes Beispiel nehmen. Wir wollen zum Beispiel euren Hacker Space nicht beleuchten. Und wenn das jetzt einfach nur ein Projekt, was jetzt im Spaß macht, dann einfach günstig und einfach auch wieder wegzuwerfen, dass man sich nicht ärgert hinterher, dann könnt ihr euch einfach die Arduino-Alois-Schnappen und losprogrammieren. Und die Architektur mag in dem Fall völlig egal sein oder zumindest nicht so relevant. Ihr könnt einfach eure Idee aufmachen. Nehmt irgendein der schon existierenden Open Source Projekte für die Beleuchtung rausziehen und einfach loslegen. Aber was, wenn das Ganze dann doch mal größer wird? Stellt euch dann vor, ihr wollt dann plötzlich ein ganzes Gebäude irgendwie beleuchten oder die Assembly beim nächsten Kongress oder so. Und ihr habt dann plötzlich hunderte LEDs oder es wird dann ein Open Source Projekt, was bei anderen eingesetzt, wie das B-Let zum Beispiel, das ist ein wahnsinnig cooles Projekt. Also wenn man einfach nur Licht will, muss man das gar nicht mehr selber machen. Man muss einfach nur anschließen und mit dem hier verknüpfen und das passt. Aber wenn das, was ihr baut, dann in so eine Sorte Projekt sich entwickelt, was mehrere Leute benutzen werden, wo mehrere Entwickler daran arbeiten, dann, was vielleicht auch verschiedene LEDs benutzen muss, was Benutzererweiterungen haben will als Feature, dann braucht man langsam Architektur und dein System hat sowieso immer eine Architektur, die ist einfach da. Was du aber eigentlich tun willst, ist, du musst sie wählen. Du solltest sie designen. Du musst eine gute Architektur auswählen, weil du hast sowieso immer eine. Und man muss dann ein bisschen vorausschauen, denken, dass man die Architektur für die nächsten Jahre plant. Und wenn man einfach anfängt zu entwickeln, dann hat, wählt man, macht man einfach Designentscheidungen, die sind relativ fundamental. Also zum Beispiel, welches Paradierprogramm, Paradigman wählt oder welche Sprache, vielleicht auch welche Plattform, welche Technologie soll es auf einem Raspberry Pi laufen, zum Beispiel, oder auf einen älteren Arduino oder sowas. Und die nächste Wahl, die treffen, ist das noch komplizierte. Das ist wie euer System in handhabbare kleinere Teile aufteilt, die dann auch idealerweise isoliert voneinander arbeiten können. Wie ihr das aufteilt in kleinere Teile. Und die Sache ist einfach die, wo auch immer mit ihr gerade arbeitet, das hat immer einen Satz Einschränkungen. Du kannst nie alles machen. Du hast immer einen Satz Anforderungen zum Beispiel, wir wollen mit mehr mit mehreren LEDs haben und die sollten irgendwie Effekte haben wie Fäden und das sind verschiedene Funktionalitäten, die ihr haben wollten. Da gibt es auch verschiedene Eigenschaften, die das haben muss. Es gibt die Ideen, also ihr habt relativ abstrakt die Ideen von den Qualitäten, die dieses Ding haben soll, die kann man auch ändern bei den meisten Projekten. Da gibt es keine harten Anforderungen an diese Qualitäten, die das haben soll. Man legt einfach mal los, ohne sich zu viele Gedanken zu machen über Nutzbarkeit oder Sicherheit. Und dann muss man leider auch viele Sachen mitdenken, die man auch gar nicht kennt, die einfach muss Annahmen treffen über die Zukunft. Wenn das dann mal eine Langzeit projekt wird, dann muss man nicht nur über das IT-System selbst nachdenken, sondern man muss auch über den Entwicklungsprozess nachdenken. Das ist etwas, wo man Monate oder Jahre mit verwenden kann, wo Firmen sich viele Gedanken zu machen bei großen IT-Projekten und dieser Entwicklungsprozess, der macht dann auch wiederum weitere Einschränkungen an eure Lösungen, die in vielerlei Hinsicht gar nicht technisch sind in ihrer Natur. Also du hast zum Beispiel einfach ein Satz Leute, die damit machen wollen, und das sind vielleicht Ingenieure, aber die keine Zeit haben, sich zu befassen mit der Software oder du hast zum Beispiel einfach nicht die Fähigkeiten und du musst erst lernen. Und dann muss man halt erstmal lernen, wie man zum Beispiel die Arduino IDE verwendet und die anderen Hacker und Maker, die du weißt vielleicht noch gar nicht, wer von denen verfügbar ist, wo die ihre Stärken haben und ihre Schwächen. Sondern jetzt, wenn man auf die nächsten Jahre hinaus denkt und gerade bei einem Open Source-Kom-Projekt, das ist ja oft ein Problem, dass die Leute des Commitments gar nicht abschätzen können und die haben einfach Spaß dran und die wollen das machen, aber sie haben halt nicht zwingend Zeit dafür. Und das ist natürlich auch ein bewegliches Ziel. Also das kann sich jederzeit wieder ändern, egal was du jetzt planst, das wird sich wieder umwerfen in den nächsten Jahren. Alles, die Einschränkungen, die Anforderungen, die Rahmenbedingungen, die Technologie, die Plattform, alles kann unabhängig von eurem Projekt sich ändern und das muss man halt irgendwie noch ein bisschen unter Kontrolle haben und dann noch versuchen trotzdem, eine halblich vernünftige Architektur zu haben. Und das führt uns jetzt zu der eigentlich spannenden Frage, wie sieht denn eine gute Architektur aus oder zumindest eine, die gut genug ist für das, was ihr erreichen wollt. Und die nächste Frage, die daran anschließt ist, wie mache ich Design-Entscheidungen, die in einer guten Architektur resultieren, ohne gleich von vornherein die komplette Architektur oder die komplette Projekt durch zu planen. Und das läuft meistens drauf raus, dass man halt irgendwie Änderungen, Offenveränderungen ist und damit umgehen kann. Niemand hat eine Kristallkugel und kann die Zukunft sehen. Also wollen wir mit der ersten Frage befassen, was ist jetzt eine gute Architektur und die Antwort, die jeder Software architekt, die sagen wird, und hier war keiner am Markt, das hängt davon ab. Das liegt einfach, ein wirklich guter Softwarearchitekt wird dir noch sagen, wovon es abhängt. Das heißt, es hängt auch ein bisschen von deinen Zielen ab. Also es ist einfach nur ein Projekt, was du zum Spaß machst oder willst du jetzt den nächsten Fusionsreaktor bauen und dann hängt davon ab, was du die nächsten Jahre möchtest. Es gibt keine gute oder schlechte Architektur, ohne den Kontext zu verstehen, unter dem die entstanden sind. Und da muss man dann halt erstmal die Anforderungen klar definieren, diese Rahmenbedingungen klären, welchen Skillset habt ihr, wie gut sind die Entwickler, wie viel Zeit habt ihr dafür, wie großen die Erfahrungen mit dem Problem. Und erst wenn man diesen ganzen Kontext mit einbezieht, kann man eine gute Architektur definieren. Und im Allgemeinen gilt, eine gute Architektur sollte einem helfen, die Ressourcen, die man braucht, um das zu bauen und zu warten, minimieren. Besonders das Unterhalten oder Erwarten vergessen viele Leute gerne, die denken immer nur ans Bauen. Aber wenn das Projekt mal jahrelang lebt, dann muss man die ganze Zeit weiter daran arbeiten, geänderte Anforderungen einbasteln, neue Features. Und das sind Dinge, die in der Zukunft passieren, die können wir halt jetzt nicht wissen. Auch Dinge, über die ihr keinerlei Kontrolle habt, also wie zum Beispiel eine Bibliothek, die ihr verwendet, dass sie sich ändert und ihr nachziehen müsst. Oder jetzt so ein Disaster wie bei Lock4J und man muss dann ganz plötzlich updaten in kurzer Zeit. Das muss man alles mit berücksichtigen. Und das nächste, was man tun sollte, ist, dass die Architektur soll den Entwicklern helfen, das System zu verschienen. Also das Feld- und das System-Engineering. Wie sollten die Systeme werden immer komplexer? Es wurde mal gesagt, vor dem zweiten Weltkrieg alles einfach, danach hatten wir Systeme. Und die Komplexität der Systeme ist so ausgebuffert inzwischen, dass der limitierende Faktor ist, dass die Menschen sie einfach gar nicht mehr verstehen können und dass sie teilweise auch gar nicht mehr wissen, wie sie auch nur kleine Änderungen machen können oder neue Features hinzufügen, um mit den geänderten Anforderungen Schritt zu halten. Deswegen muss man eine... Es ist sehr wichtig, dass man die Anwendungen aufteilt in kleine Teile, die handhabbar sind, dass man eine sinnvolle Aufteilung hat. Und damit man einfach das drum herum vergessen kann und sich nur auf die Komponenten konzentriert, die man sich in dem Moment anguckt. Und ihr solltet natürlich auch immer offen sein für Änderungen. Das heißt, das muss man irgendwie so machen, dass man die berücksichtigen kann. Und es soll auch gleichzeitig noch trotzdem Rahmenbedingungen schaffen, die man sich halten kann. Und es gibt... Man kann Designentscheidungen klassifizieren. Es gibt zwei Sorten. Du hast irgendwie rationale Entscheidungen. Du schaust dir alle Optionen an und nimmst dann einfach die Beste. Das passiert leider nicht sonderlich oft, wenn man sich bei Architektur-Fragen anschaut. Sondern meistens hat man beschränkt rationale Informationen. Man hat einfach nicht alle Informationen, die man braucht. Und es ist so... Ich weiß es, wenn ich sehe, aber ich kann jetzt nicht alles vorausdenken. Wir sind überfordert mit der allgemeinen Formulierung. Ich weiß es, wenn ich sehe. Es gibt einfach... Man hat meistens nicht die Zeit, um alle Optionen, also wirklich alle Optionen auszuschöpfen und alle zu verstehen, weil man muss ja irgendwann nochmal fertig werden. Und oft ist auch einfach die mentale Kapazität irgendwann erreicht, dass man nicht alles mehr überblicken kann. Das heißt, wie kommen wir auch sinnvolle Entscheidungen für das Design, die uns zu einer guten Architektur führen in der Zukunft? Und der erste Schritt dabei muss sein, seid einfach sicher, was eure Anforderungen sind und dann was euch voranbringt, was euch motiviert, was euch wichtig ist. Sonst kann man keine wirklich guten Design-Scheidungen machen, denn man muss immer an Kompromiss eingehen und manche Sachen opfern für andere Sachen. Und wenn man die Beschränkungen nicht kennt und weiß, was das Wichtigste und das Wertvollste ist für deine LED-Lichte, dann kann man keine guten Design-Entscheidungen machen. Und andere Sachen sind über Anforderungen und Beschränkungen. Und wenn man die Anforderungen nicht erfüllt, alle Karten in der AC3-World zu verbinden, dann wird das die Anforderungen nutzlos. Das heißt, man muss auch wissen, wie die Anforderungen sich ändern und wie stabil die sind. Und wenn man jemanden fragt, ob er oder sie es wirklich braucht, dann ja, jemand hat gesagt, ich brauche das unbedingt und ich muss das unbedingt haben. Aber es stellt sich raus, das ist nichts, was einen interessiert oder mit dem man Geld verbient. Es wurde ihm nur gesagt von jemandem, dass man das haben muss. Aber man muss wissen, was sind die Ziele, was sind die Einflüsse auf die Architektur und wie wichtig sind die und wie stabil sind die. Und wenigstens muss man irgendwelche Anmarmarber machen, wie sie sich mit der Zeit verändern werden. Und was ganz besonders wichtig ist, sind Qualitätsanforderungen. Denn die Funktionalen Requirements, die Funktionalanforderungen ändern sich und da kann man mit umgehen, auch in unserem täglichen Leben. Aber wenn ein Qualitätsanforderungen an das System sich ändern, z.B. die LEDs sollten jetzt eine bestimmte Frequenz von 1000 Hertz liefern können und nicht nur 200 Hertz, dann kann es ein großes Problem werden. Das könnte das Gesamtsystem ändern und man müsste vielleicht das nochmal komplett neu designen, das System. Also sollte man wirklich gucken, dass man die wichtigsten Qualitätsanforderungen kennt und dass man weiß, wie gut das System und wie stabil das System und wie enderbar das System sein soll. Denn eine dieser Qualitätsanforderungen kann bedeuten, dass das Systemdesign obsolet wird und man muss eine ganz neue Architektur bauen. Und damit es nicht passiert, ist eine gute Idee, inkrementell zu arbeiten. Versucht nicht ganz auf einmal alles richtig zu machen, alles zu fixen mit einem großen Design von Anfang an, das funktioniert meist nicht. Man weiß am Anfang oft noch gar nicht alles, sondern macht das in Interationen, benutzt kleine Schritte, um die Architektur zu ändern. Es ist okay, man sollte eine grobe Idee haben, wie die Architektur aussehen sollte, eine Richtlinie am Anfang, eine Richtschnur, sonst kann man keine Designentscheidungen treffen. Aber man muss darauf vorbereitet sein, dass es sich ändert. Und was deine Architektur ermöglichen sollte, ist, dass man mit diesen Änderungen umgehen kann. Und eine wichtige Sache, die man machen kann, ist, dass man die Kompromisse kennt. Und ich glaube, wenn man versucht, alles in eine Architektur zu bauen, dann ist das auch mal ein Kompromiss. Und dass ein Korolla dazu ist, wenn man als Architekt etwas gefunden hat, was kein Kompromiss ist, dann hat man den Kompromiss den Trade-off nur noch nicht gefunden an der Stelle. Das heißt, um gute Designentscheidungen zu treffen, muss man herausfinden, welche Komponenten von dem System verbunden sind, wie die gekoppelt sind miteinander. Und wenn ich eine Komponente ändere oder die Anforderung für eine Komponente, wie beeinflusst das die anderen Komponenten, die mit dieser Komponente verbunden sind. Und wenn man nur ein ganz einfaches Beispiel nimmt, wie unsere LED-Lächter, da sind schon so viele Kompromisse und Trade-offs. Und das könnte nur noch schlimmer werden. Und man muss eine Designentscheidung machen, ob man ein Software-PWM hat, ob man ganz viele benutzt, oder mit deinem Hardware-PWM, was ein geringer System verursacht. Und man hat vielleicht dann weniger Feature, oder will man vielleicht eine höhere Modulationsfrequenz haben. Und wenn man einen bestimmten Hack macht, aber je höher die Modulationsfrequenz ist, desto niedriger ist die Dynamikumfang, den man hat. Man kann dann vielleicht, man hat viel weniger Schritte dazwischen und lasst uns jetzt nicht davon anfangen, wie man Frame-Raten optimiert. Vielleicht hat man eine sehr hohe Frame-Rate für Animationen und man hat eine sehr hohe System-Belastung, hat vielleicht dann Dropouts und vielleicht kann man das dann nicht mehr synchronisieren, wenn man eine Bühne damit beleuchten will und wenn man alle Blamp zusammenmeinschalten will, das ist vielleicht, ist auf jeden Fall immer ein Kompromiss, wenn man eine hohe Frame-Rate hat und wenn man das synchronisieren will und lasst uns nicht über Features und Qualitätsattribute reden. Also will man over-the-air-Updates haben oder dass man nicht zu jeder Lampe extra hingehen muss, um die Firmware zu aktualisieren und das hat natürlich ganz viele Security-Probleme. Will man das haben in deinem Netzwerk? Man verliert auch viel Speicher, wenn man over-the-air-Updates macht. Alle Design-Decisions, alle Design-Entscheidungen sind Kompromisse und man muss identifizieren, was man gegen was hier abwägt, Qualität gegen Features oder Systemeigenschaften und es gibt etwas, was man offen machen sollte, offenlegen sollte, dass es sichtbar ist und es ist gut zum Beispiel ein Architecture-Decision-Record machen. Man sollte die Kompromisse offenlegen, denn im Code sind die nicht unbedingt sichtbar. Die sind eigentlich nur in deiner Dokumentation zu finden. Das Nächste ist, man muss natürlich mit Änderungen umgehen können und man muss gut mit den Änderungen umgehen können. Man muss die Sachen identifizieren, die wirklich schwer zu ändern sind und was die sind, hängt natürlich von deinem spezifischen Projekt ab oder von dem System, aber Sachen, die hart schwer zu ändern sind, sind zum Beispiel die Programmierparadigmen oder die Programmiersprachen und es ist schwer, das Spare-Time-Projekt zu ändern. Da muss man alles neu schreiben oder auf welcher Plattform das laufen soll oder auf welcher Middleware oder welche öffentlichen APIs oder wenn dein System eine öffentliche API hat, die veröffentlicht wird für andere, für ganz viele anderen Benutzer, die die viele benutzen. Und dann ist es immer schwierig, solche Systeme zu ändern und auch teuer. Man kann von diesen Änderungen entkoppeln. Das ist möglich, aber selbst das Entkoppeln bringt zusätzliche Komplexität und Complexity ist das, was vielleicht dein Projekt unmöglich machen wird, was dein Projekt killen wird. Man hat nur bestimmte Menge Ressourcen. Und was würde UNIX machen, wenn Sachen, die schwer zu ändern sind, sich trotzdem ändern? Und UNIX hatte eine Strategie dafür. Im Wesentlichen hat es einen Satz kleiner Tools, die genau eine Sache machen, aber die gut machen und die kommunizieren über ein Standard-Protokoll. Das heißt, die sind sehr schön entkoppelt. Das bedeutet, alle von diesen kleinen UNIX-Werkzeugen kann Stück für Stück ausgetauscht und geändert werden. Ich habe schon ein bisschen über Koppelung gesprochen und es ist ein interessantes Konzept, was man haben kann. Was ist diese Koppelung? Koppelung bedeutet, es gibt eine Art Abhängigkeit zwischen den Komponenten. Wenn man eine Komponente ändert, dann könnte das wahrscheinlich Einfluss haben auf andere Komponenten. Und man kennt das natürlich, wenn ich Leute frage in Trainings und dann fragen die, was ist Kappling? Das kennt man schon. Wenn man eine Funktion aufruft von einem anderen Objekt, dann hat man eine Koppelung. Natürlich können die über Datenstrukturen gekoppelt sein, über Nachrichten austauscht und so. Wenn man eine gesamte Datenbank benutzt und eine gemeinsame Datentypen und eine Ende davon ändert sich, dann muss man auch andere Komponenten angucken, die auch das benutzen, ob die mit dieser Änderung umgehen können. Das ist etwas, was ganz viele moderne Programmiersprachen, dass sie wirklich lösen für die Typesafely zum Beispiel. Aber man muss trotzdem immer gucken, ob man da vielleicht ein Problem hat. Man kann Daten als Text übergeben, zum Beispiel, oder JSON, oder wenn man ein JSON-Schema hat. Wenn eine Komponente jetzt das ändert, was in diesem JSON-Datei ist, und dann funktioniert es nicht mehr, das bedeutet, dass so eine Datenkoppelung hast, in diesem Fall. Was Programmiere meistens wissen, dass auch Vererbung eine Koppelung bedeutet. Klassen sind eine sehr starke Koppelung. Aber es gibt ganz viele andere Koppelungsarten. Und diese Liste ist natürlich auch immer noch nicht vollständig. Und natürlich kann man eine Koppelung haben, dadurch, dass die Komponenten auf demselben System laufen müssen, oder auf derselben virtuellen Maschine, oder manche Komponenten müssen andere Komponenten erzeugen. Das ist auch eine Art Koppelung. Oder man hat vielleicht eine Koppelung über die Zeit, dass man sich auf etwas verlässt, dass etwas passiert, bevor man was machen kann. Und das ist etwas, was oft nicht im Code sichtbar ist, in modernen Programmiere, moderne Programmiersprachen, stellen Konstrukte dafür bereit für manche von diesen Dingen. Aber die kann man nicht alle berücksichtigen. Und es gibt vielleicht Koppelungen, die hier überhaupt nicht im Code repräsentiert sind. Zum Beispiel alle Komponenten müssen zur selben Zeit ausgerollt werden, weil man eine monolithische Struktur hat, mit starken Abhängigkeiten. Und man muss einen Fix zu bestimmten Sachen implementieren, und so, dass man das wieder neu releasen kann. Man kann das alles entkoppeln, man sollte das sogar. Was ihr aber wirklich braucht, ist, dass ihr die Koppelung zwischen den Komponenten möglichst minimiert, weil das Änderungen am System sehr kompliziert macht. Und es gibt dann auch Folgewirkungen, die ihr bedenken wirst, wenn ihr etwas am System macht. Aber selbstlose Koppelung ist auch wiederum ein Schmelde, auf den ihr genau anschauen müsst. Es fügt auch auf anderer Seite wieder Komplexität hinzu, und ihr müsst euch sehr genau überlegen, wann ihr entwieger koppelt. Und man kann nicht einfach sagen, man entkoppelt, man muss das alles strukturieren. Und jetzt wollt ihr aber, dass die ... eure Architektur offen ist für Änderungen, aber ihr wollt die Auswirkungen der Änderungen möglichst minimieren und halt die Folgewirkungen von der Änderung kleinhalten. Und da helfen Design-Prinzipien. Manche davon klingen so offensichtlich, dass ihr das schon gar nicht mehr wahrnehmt, weil die meisten Programmiersprachen das für euch wegabstrahliert haben, ohne die Sprache eingebaut sind. Also sowas wie Information-Hiding. Das heißt, einfach verstecken von Informationen auch auftrennen von ... von ... von ... von ... Also man versucht im Prinzip, dass jeder nur mit einer Sache befasst ist und dass die Komponenten nicht untereinander gekoppelt sein müssen, um sich mit einer Sache zu befassen, sondern dass das sauber aufgeteilt ist zwischen Komponenten. Und darüber könnte man noch mal einen ganzen eigenen Vortrag machen. Das heißt, wenn ihr noch mal eine zweite Folge haben wollt, dann wäre das mal sehr spannend, dass man mal Design-Prinzipien auseinandernimmt und genau überlegt. Aber eine Warnung möchte ich mitgeben, ihr solltet auf keinen Fall versuchen, alle diese Bedingungen gleichzeitig erfüllen und alles perfekt durchzusetzen. Es ist okay, auch mal das von abzuweichen, weil selbst die Anwendung dieser Prinzipien ist auch wiederum eine Abwägung, die man treffen muss für jedes konkrete Projekt. Wenn man zum Beispiel Drive übertreibt, also don't repeat yourself und zu viel abstrahiert, dann holt man am Ende auch wieder wohin, wo man wahnsinnig viel Arbeit reinstecken muss und man muss halt die Vorteile für sich sehen und rausziehen. Also wenn man zum Beispiel entkoppelt, dann kann man das gut auf verschiedene Teams aufteilen oder auf verschiedene Leuten. Wir wollen Drive auch einfach mal verletzen manchmal, weil das kann für Schwierigkeiten mit der Kopplung machen, dass die dann sich verstärkt. Und hier müssen... alles ist hier eine Abwägung zwischen den verschiedenen Prinzipien. Die sind auch nicht alle miteinander immer kompatibel, und man muss im richtigen Moment die Richtige abdrücken. Aber eines der wichtigsten Dinge ist, man darf sich nicht dazu rüberleiten lassen, immer wieder alles neu zu erfinden. Es hilft sehr, dass man die schon erfundenen Muster, die viele Leute definiert haben, auch verwendet. Es hilft, eine gemeinsame Struktur und Sprache zu finden dafür. Es gibt Quellen dafür, es gibt tolle Bücher dafür, Pattern, also Muster werden nicht entwickelt, sondern die werden einfach nur gefunden. Und das haben schon viele gemacht. Die Liste war gerade auf der Früh. Und das Wichtigste ist aber, Schreibzeug auch einfach auf. Niemand hat da Lust drauf. Jeder weiß, Dokumentation spart hinten raus Zeit. Aber die aktuelle Zeit, die man reinstecken muss, ist natürlich die, die man investieren will. Trotzdem macht das. Wenn ihr Architektur macht, dann müsst ihr auch relativ schnell mit anderen Mentoren ausbilden. Ihr müsst sie darin ausbilden. Ihr müsst sie coachen. Wenn das Architektur nicht funktioniert in eurer Peer Group, dann habt ihr entweder ein Problem mit dem, was ihr designed habt, weil es nicht auf die Anforderungen des Teams oder des Projekts passt. Das kann auch der Hexbase sein in dem Fall. Dann müsst ihr eben rausfinden, ob Design noch passt auf die Anforderungen. Aber es gibt auch viele nicht technische Sachen, die schief gehen können. Also in Firmen ist es oft, dass man Hierarchieprobleme hat, dass Firmenpolitik mitspielt. Dann, du hast vielleicht nicht den richtigen Titel oder ihr habt nicht das Zertifikat. Dann führt das relativ schnell zu Rollenkonflikten. Manchmal kann es auch sein, dass ihr einfach den Titelarchitekt zum Beispiel bekommen habt. Aber das führt dann zu einem Nadelöhr, weil er nicht das nötige Level an Abstraktion erreicht und dann immer noch mitcoden will. Und wenn man dann selber alles programmieren will und nicht delegieren kann, dann wird man zum Nadelöhr, weil man nicht loslassen kann. Was wirklich funktioniert, man sollte auf jeden Fall versuchen, Architekturverantwortung anhand der Hierarchie zu verteilen. Also ich habe das Gefühl, in unserer Community funktioniert das ganz gut. Da passiert das selten. Aber wenn das in eurer Firma passiert, was da oft passiert ist, dass Architektur oft gemacht wird von jemandem, der keinen expliziten Titel hat und Ahnung hat. Und das muss man halt auch zulassen. Es ist oft so, dass Leute einfach in die Rolle reinwachsen. Und die machen es einfach intuitiv richtig. Und weil es sich darum, weil es ihnen wichtig ist. Und die Architekturverantwortung kommt sehr oft den, die einfach sowieso sich dafür verantwortlich fühlen. Und wenn du selbst keine Architektenrolle hast, dann kann man sie teilen. Einfach, wenn niemand die Aufgabe auf die Zelle übernimmt, dann kann man die auch im Team wiederum verteilen, dass man mehrere Leute hat, die die Aufgaben übernehmen. Und das, ihr könnt einfach mal in ein Meeting reinlaufen und sagen, hey, wer kann mir was sagen über die Updates, die die LED-Streifen kriegen. Und dann siehst du sofort, wer nachdenkt und was darüber sagen kann. Und das wäre dann vielleicht ein guter Kandidat für so eine Architektenrolle. Jetzt kommen wir langsam zum Schluss. Wir haben natürlich nicht alles abdecken können. Ich hätte Lust noch deutlich mehr zu sagen, ich habe nur ganz kurz anrichten, was das auf der Architektur ist, warum es wichtig ist, dann vielleicht ganz kurz nur was gute Architektur ausmacht und eben die Grundlagen von vernünftiger Architektur. Aber es gäbe so viel zu sagen über Performance, über wie man übergreifende Anforderungen umsetzt, wie man die Patterns besser umsetzt. Aber das hat leider alles nicht reingepasst in den Vortrag. Und wir sind jetzt am Ende. Danke euch. Vielen, vielen Dank. Und vielen Dank für eure Geduld. Und ich freue mich auf Feedback und eure Fragen. Und nach dem Talk können wir auch gerne in der Chaos so in uns treffen und noch ein bisschen diskutieren. Oder wenn ihr Fragen bei einem konkreten Projekt habt, ich habe wirklich viel Spaß daran, bei konkreten Projekten und Architekturfragen mit zu helfen. Wenn ihr mir erklärt, was ihr gemacht habt und was eure Probleme sind, dann kann ich euch vielleicht auch sagen oder einen Hinweis geben, wie man was besser machen kann, man kann immer viel lernen von anderen an der Stelle und ich möchte euch vielmals danken. Dann freue ich mich jetzt auf die Fragen. Wir haben hier ein bisschen Verzögerung. Ja, wir haben hier etwas Verzögerung. Nee, das ist so okay. Hallo. Gut, wunderbar. Vielen Dank. Wir haben nicht so viel genug Zeit für alle Fragen, aber lasst uns mal ein paar auswählen von den wichtigsten und die wir in der Zeit machen können. Also, ja, wir können... Ich gebe euch alle Antworten nach dem Talk. Also, Software-Architekturen sind... Sie helfen dem... Wir sind wie der Gordische Knoten und sie helfen dem, der den Knoten öffnen kann, aber wenn sie wirklich gut geknotet sind, dann weiß man nicht, wie die eine ist durch den Knoten. So, gibt es solche Knoten in der Standardisierung, in den ISO, IAC, IEEE, was noch immer. Und welche davon ist die Standardisierungsorganisation für Software-Architektur? IEEE interessiert sich für Software-Architektur. Die werden guter Kandidaten. In dem Sinne, das sind es als Teil von der Systemarchitektur behandelt. Wenn ihr euch den ISO und IEEE standard anschaut, die sich wie sie in den letzten Jahren geändert haben, dann gab es da früher eine Definition von Software-Architektur. Jetzt gibt es nur noch die Definition von Systemarchitektur, was voll in Ordnung ist, weil Software-Architektur ist am Ende des Tages nur System-Architektur für IT-Systeme. Und ich kann jetzt wenig über andere Architekten oder über andere Organisationen reden, in denen Architekten involviert sind. Es gibt welche, die interessieren sich für das Missen von Architekten. Da möchte ich jetzt keine Vorschläge machen. Es gibt aber eine sehr aktive Software-Architektengemeinde, die in meinen Augen voll ist, mit Leuten ist, voller cleverer und intelligenter Leute, sowohl in Deutschland als auch im weiteren Europa, auch in anderen Teilen der Welt. Da gibt es Leute, die sich wahnsinnig dafür interessieren. Aber ich kann nichts darüber sagen, inwieweit die da in Standardisierungsorganisationen involviert sind. Das weiß ich nicht genug. Das hört sich an wie die Standardisierung zu Beginn des Internets. Das Problem mit der Standardisierung ist, dass die Leute nicht mal die Terminologie standardisiert sind an vielen Stellen. Verträge, Artefakte, Interfaces, Schnittstellen. Wir bräuchten so etwas wie ein definitives Buch über die Technologie für Software-Architektur, um in die gemeinsame Kommunikation zu kommen. Danke für die Antwort. Wie interagiert Software-Architektur mit System-Architektur? Das ist schon darüber gesprochen. Wie beeinflusst Software-Architektur mit Software-Architektur, Firmenware und Licensing? Das sind jetzt zwei Fragen. Das erste ist interagiert Software-Architektur und System-Architektur. Software-Architektur ist ein Teil von der System-Architektur. Wenn dein System größere Anteile mit Architektur hat, dann ist es einfach Teil davon. Es interagiert dann sehr stark, weil man hat in der Regel viel Abhängigkeiten und die ganzen Beschränkungen und Anforderungen werden dann von der IT auch beschränkt und umgekehrt. Es interagiert dann auch mit anderen Architekturen. Zum Beispiel die Informations-Architektur oder die Business-Architektur. Es kann aber auch mit der Hardware-Architektur interagieren. Manche Software funktioniert z.B. nicht gut auf einem Single-Vertile-Prozessor. Das heißt, man braucht eine Architekturtrennung zwischen diesen verschiedenen Varianten. Wenn man über verschiedene Architekturen oder über Software-Architekturen nachdenken kann, dann kann man das meistens auch mit Systemen und umgekehrt. Die Anwendung des Architektur ist schon mal schwieriger, aber meistens braucht man da mehr Ideen von dem eigentlichen Geschäftsobjekt. Was war die zweite Hälfte nochmal, sorry? Wie kommunizieren die Menschen im optimalen Fall? Im optimalen Fall, das natürlich. In Requirements, Documents oder so. Zum Beispiel beim Anforderungsdokument. Die Frage ist, was ist jetzt der optimal Fall? Der optimal Fall ist, wenn alles am Ende wunderbar funktioniert. Was, wie dieses optimal Fall genau aussieht, ist eine Frage davon, was für Ressourcen du hast, die dein Team sich verteilt. In der Vergangenheit hatten wir eine gute Aufteilung nach Aufgaben. Da hatte man Teams, die haben sich nur um Hardware gekümmert, man hatte Teams, die haben sich nur ums Rondent gekümmert und dann gab es noch die Backendentwickler und so weiter. Das funktioniert leider nicht mehr so wirklich, funktioniert manchmal, aber was besser funktioniert ist, wenn man so übergreifende Teams hat, dass man die Entscheidungen auch verteilt. Aber es hat auch damit zu tun, dass Convays Lore existiert. Die Struktur des Systems, die man aufbaut, die Gestalt von diesem System, wird auch von der Struktur deines Teams bestimmt. Also, wenn man eine starke Trennung zwischen den Teams hat, dann wird automatisch auch dein System eine solche Schnittstelle aufbauen, die ziemlich genau mit der von den Grenzen der Teams zusammenhängt und dann braucht es ein Haufen Arbeit, um das zu überwinden. Wenn ihr optimale Kommunikation zwischen den Systemarchitekten und den Softwarearchitekten haben wollt, dann müssen Sie zunächst mal ein Haufen Dokumentationen schreiben. Die sollten miteinander reden, rausfinden, welche Informationen die anderen beteiligten Leute brauchen. Man muss es einander erklären, um zu verstehen, was die Abwägungen sind und warum sie getroffen hat. Ja, und der große Rosaelefantebraum, gibt es bestimmte Architektur-Muster, die alle kennen sollten? Wir hatten... Das ist jetzt tatsächlich ein sehr großer Elefant. Und es ist jetzt auch nicht besonders... Ja, es ist riesig. Also, wir haben 26 Minuten, aber... Also, welches Muster ihr braucht, hängt sehr stark von dem System, ab das ihr bauen wollt und auf welchem Level ihr operiert. Als Entwickler sollte man... sollte man das Ganger Vorbuch haben, dass diese Design-Patterns niedergeschrieben hat, weil es hilft bei Design und Implementierung und Programmieren sogar. Aber es gibt auch Architektur-Pattern, die hängen sehr davon ab, welches System man bauen will. Also, in der Software-Architekten-Community ist es viel Diskussion darüber, welche Pattern oder welche Mustern man in die Ausbildung aufnehmen würde. Und wir haben die meisten wieder rausgenommen, weil wir eine Liste von 30 Mustern hatten. Und viele dieser Muster haben nicht funktioniert für die anderen Leute, die auch das Training übernommen haben. Da gab es irgendwie Layer, Microservice, das Filter. Das sind die Pattern, die man wissen muss, aber die sind nur relevant fürs Training. Nicht, weil sie relevant sind für jeden, der damit in der Praxis arbeiten muss. Was ich anbieten kann. Was ich... Dass wir uns nachher treffen und ich mit den Leuten unterhalte. Was wollen sie gerade arbeiten und dann vielleicht Mustervorschlagen, die für ihre Anwendung relevant sind. Das ist aber verteilt über verschiedene Bücher, was man wissen sollte. Und es hängt sehr davon ab, von der Software, die man baut, als wenn man zum Beispiel ein verteiltes System hat, dann hat man komplett andere Muster, als wenn man einen Monolithen baut. Und das hängt jetzt extrem davon ab, was man basteln will. Ja, und vielleicht haben wir es schon beantwortet, aber gibt es Literatur, die Entwickler lesen sollten. Und ich glaube, das ist auch fast schon unsere letzte Frage. Das Internet fragt nach einem zweiten Teil. Also, Bücher empfehlen ist für mich immer sehr schwierig. Ich würde gerne nur einen Buch empfehlen. Es gibt schon mehrere gute... Als Deutscher würde ich empfehlen. Ein Buch von Gernot Starke. Wenn es für die Englisch-Behörigen Bücher sein soll, dann das umfangreichste und beste ist das Mark Richard. Also die Grundlagen der Software-Architektur. Das ist von 2020. Wenn ihr Vorträge von Richard hört, dann seht ihr schon, dass der sehr aktuell und sehr gut ist. Hat auch ein neues Buch geschrieben über moderne Abwägungsanalyse, also dass man die Trade-offs analysiert, die man macht. Das ist eher für die Leute, die verteilte Systeme bauen, die über serviceorientierte Architekturen bauen müssen. Das ist etwas anderes als für die Leute, die z.B. aus Embedded-Systemen kommen. Aber das Grundlagen der Architektur ist definitiv gut. Simon Braun hat ein gutes Buch über Architekturen für Software-Entwickler geschrieben. Und gibt es noch ein paar ältere. Clemens und Kassmann. Ich bin auch ein bisschen älter, aber das sollte euch die meisten Grundlagen geben. Und jetzt Entschuldigung, alle, die ich jetzt nicht genannt habe, ist es echt schwierig aus der Masse guter Bücher, welche auszuwählen.