Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren

Wie wird eine Software-Architektur flexibel?

Einführung und Hintergrund

Ich habe dazu auf LinkedIn, Mastodon und BlueSky euch entsprechend gefragt und ich werde jetzt im Rahmen dieser Episode mal die Antworten durchgehen und dasselbe so ein bisschen kommentieren.

Und dazu habe ich diese ganzen Antworten auf dem PowerPoint gepackt.

Das können wir uns hier mal irgendwie anschauen.

LinkedIn Umfrage zur flexiblen Architektur

Das erste, was ich bei LinkedIn gemacht habe, ich habe gesagt, wie erreicht man eine flexible Software-Architektur?

Und da habe ich gesagt, die Möglichkeiten, die man jetzt wählen kann, ist technische Maßnahmen wie Microservices oder so genannte Architekturen.

Dann kommt eine geschickte fachliche Architektur oder organisatorische Maßnahmen und darunter könnt ihr abstimmen.

Und dann gab es eben noch die Möglichkeit, als vierte Option zu sagen, das ist irgendwie alles nicht das Richtige und ich möchte lieber da selber eine Idee haben und halt diese Idee kommentieren.

Und die Ergebnisse sind halt, dass 61 Prozent gesagt haben, eine gute fachliche Architektur, 20 Prozent haben gesagt, organisatorische Maßnahmen und dann haben sechs Prozent gesagt, Technik und 13 Prozent haben gesagt, anderes bitte kommentieren.

Und vielleicht so zum Hintergrund der ganzen und ich werde jetzt den Rest der Stunde die Ergebnisse jetzt Timebox durchgehen, also die subjektiv ich interessant finde.

Was wiederum bedeutet, wahrscheinlich werden nicht alle vorkommen.

Also ich habe irgendwie insgesamt 65 Folien.

Ich glaube nicht, dass wir das schaffen.

Das Konzept von dem Stream ist ja, da Timebox zu sein und nicht auch insbesondere, wenn ihr Fragen habt, noch die Fragen zu diskutieren.

Flex-Training und Dimensionen der Flexibilität

Und Hintergrund der ganzen Geschichte ist halt, ich mache für so Kreaturien dieses Flextraining.

Das ist vom ISA-KoB und ich habe tatsächlich auch mal den Lehrplan selber mit entworfen.

Die nächsten Termine sind am 14. bis zum 16.

Oktober online oder vom 16. bis zum 18.

Dezember online und dann vom 1. bis zum 3.

Dezember in Stuttgart vor Ort.

Und da gibt es die Rabattcodes, also Flex 1 bei Eberhardt, 1 bei 10, 1 bei 25, für das im Oktober und für die im Dezember ist es 1 bei 12, 1 bei 25.

Sonst wieder auch wieder Flex 1 bei Eberhardt, 1 bei 12, 1 bei 25 in dem Fall.

Und in den Trainings gucken wir uns tatsächlich alle drei Themen an.

Also wir schauen halt, wie wir so ein System technisch flexibel machen können.

Technische Flexibilität

Können wir ja machen, indem wir Microservices benutzen.

Dann haben wir die Möglichkeit, technische Entscheidungen dezentral zu fällen, für jeden Microservice eine Programmiersprache zu benutzen, die hat unabhängig voneinander zu deployen, unabhängig voneinander zu skalieren.

Also viele von den Entscheidungen können wir dann dezentral treffen und sind dadurch flexibel.

Nicht jeder Microservice kann anders aussehen.

Wir sprechen sehr viel über Fachlichkeit, wie wir also Fachlichkeit vernünftig strukturieren, was ja auch ein Thema ist, was wir im Stream öfter gemacht haben.

Und wir sprechen tatsächlich auch über so organisatorische Maßnahmen, die da halt helfen können.

Und das bedeutet so ein bisschen, meine Antwort wäre halt gewesen, alles drei.

Und im Training diskutieren wir deswegen auch alles drei.

Und das ist auch etwas, was sehr stark zu mitmachen ist.

Das heißt also, wenn ihr dort irgendwie das Gefühl habt, dass ihr oder dort könnt ihr selber eine Architektur bauen.

Wir treffen selber die Entscheidung mit den Technologien.

Wir reden über die organisatorische Aufteilung und so weiter und machen das halt irgendwie selbst.

Und das Ganze bereitet auch auf die nächste Kopie Advanced Level vor.

Und am Ende sind da eben eine ganze Menge an Abwägungen und Entscheidungen zu treffen.

Und ich würde behaupten, diese drei Dimensionen sind tatsächlich die wesentlichen Dimensionen, in denen wir dann flexibel sein können.

Und wenn ich die jetzt eben wie alle dort Entscheidungen und Abwägungen treffen, nicht mehr so überlege, will ich Microservices mit dieser starken technischen Unabhängigkeit oder will ich das vielleicht nicht, weil das zu viel Aufwand ist.

Dann komme ich halt am Ende am Ziel an.

Und das war so ein bisschen der Hintergrund.

Und natürlich ist es halt bei diesen Sachen immer ganz spannend zu schauen, was ihr denn halt so sagt.

Und ich habe jetzt die Präsentation aufgeteilt in so mehrere Bereiche.

Der erste Bereich ist das hier.

Das sind also Dinge, wo ich halt irgendwie nachgedacht habe.

Also wir sehen hier so ein Nachdenkendes Emoticon.

Das heißt, ich habe mir jetzt an den Anfang die Kommentare von euch gestellt, wo ich mir das gefühlt hatte.

Also das ist irgendwie spannend und ich würde halt gerne was dazu sagen, weil es mich so ein bisschen zum Denken anregt.

Genau, der oder die Mira Findley schreibt gerade, was charakterisiert flexibles Design, das Anpassen fit an den Kontext und das Anpassen des Systems an den Purpose.

Das ist übrigens eine von den interessanten Fragen.

Das ist auch eine Kategorie von Antworten, die da ist.

Also die Rückfrage, mit welcher Art von Flexibilität ist eigentlich gemeint, bis hin zu Leuten, die sagen, sowas wie Flexibilität gibt es gar nicht.

Und ich würde sagen, Flexibilität ist die Möglichkeit, irgendwie auf Änderungen zu reagieren.

Das wäre halt Flexibilität.

Und also durch eine gute fachliche Architektur, wie ich seit dem Training diskutiere, kann ich auf fachliche Änderungen reagieren.

Bei einer guten technischen Architektur kann ich auf technische Änderungen reagieren, neue Programmiersprache einführen, solche Sachen.

Bei der organisatorischen Ausrichtung kann ich eben darauf reagieren, sorge ich dafür, dass ich diese technischen Mechanismen ausnutzen kann und dass ich eben auch dort in der Organisation flexibel bin und mich also entsprechend unterschiedlich aufstellen kann.

Was macht ein Unternehmen?

Es passt sich an sich in einem anderen Kontext an.

Ja, und dafür ist das sozusagen relevant.

Genau, herzlich bedankt.

Sehr gerne.

Das ist ja die Idee von dem Stream, eben mal mit euch zu interagieren.

Gut, und der Erste, der mich zum Nachdenken gebracht hat, war Rainer Feike von LinkedIn.

Kritische Perspektiven zur Flexibilität

Er hat geschrieben, das ganze Thema flexibel braucht ein Redesign.

Ein Arzt gibt auch keine Armprothese, die nächstes Jahr als Bein verwendet werden kann.

Und ein Ingenieur braucht kein Auto, das fliegt, wenn man Flügel dran schraubt.

Unsere Disziplin ist sehr jung.

Wir müssen die Theorien schärfen.

Dazu gehört, es Schluss zu machen mit dem Anspruch, Software beliebig und jederzeit verändern zu können.

Mörtel ist auch flexibel, aber in Grenzen.

Und das hat mich halt deswegen dazu angerichtet, was dazu zu sagen, weil ich behaupten würde, die Dinge, die dort als Metaphern genutzt werden, also ein Arzt, der eine Armprothese rausgibt, die dann als Bein verwendet wird.

Wir bauen auch keine CRMs, die morgens als LLM genutzt werden.

Also wir haben eine Flexibilität.

Ich muss eben dafür sorgen, dass mein CRM auf irgendwelche Änderungen reagiert.

Wir brauchen eine Flexibilität.

Und diese Aussage mit unserer Disziplin ist sehr jung.

Also ich bin ja jetzt selber nicht mehr so der Jüngste.

Aber die Frage ist erstmal, was ist unsere Disziplin?

Ich würde behaupten, unsere Disziplin ist Softwareentwicklung im Team, auf Digitalkomputern.

Das gibt es ungefähr seit den 50ern.

Ich habe da auch eben eine Episode darüber gemacht, dass das Wasserfallmodell nicht existiert.

Da geht es genau darum, wann wir eigentlich das erste Mal angefangen haben, Systeme im Team gemeinsam zu bauen.

Das ist seit den 50ern.

Und das ist ein bisschen länger, als ich lebe.

Ich bin Jahrgang 72.

Das heißt, das ist gut 20 Jahre länger, als ich lebe.

Das bedeutet, ich kann tatsächlich mit den Erfahrungen dieser ersten Generation ganz locker ausgestattet werden.

Ich habe in den 90ern studiert, seit ab 93.

Das heißt, ich kann mit 40 Jahren Hintergrundwissen über Softwareentwicklung ausgebildet werden.

Ich bin das auch geworden.

Und ich würde behaupten, solche Sachen wie Conway’s Law 1968, Modularisierung, Parnas, auch Ende der 60er, Agilität.

Da verweise ich auf die Episode mit der Christiane Floyd.

Wenn wir das großzügig auslegen, also Softwareentwicklung, Iterationen, das ist auch ein Thema aus den 60ern.

Brooks’ Mythic Man-Month, nachdem man eben nicht, wenn man ein Projekt zu spät hat, noch mehr Menschen draufwerfen sollte und dann schneller wird.

Das Buch ist so 1975 herausgekommen.

Das heißt, wir sind vielleicht eine junge Disziplin.

Aber ich würde sagen, wir haben einen Erfahrungsschatz an Engineering und können darauf aufbauen.

Und ich glaube auch, dass wir uns der Herausforderung stellen müssen, dass wir Software bauen müssen, die sich einer ändernden Welt anpasst.

Das ist eben so.

Und ich glaube, da kann die Ansage nicht sein, das können wir nicht, weil wir haben keine Erfahrung, wir sind eine junge Disziplin.

Das finde ich schwierig.

Das erst mal dazu.

Das Nächste, was ich spannend fand, war diese Äußerung von Sven Müller.

Praktische Ansätze für Flexibilität

Er hat gesagt, Flexible Software, und das war auch tatsächlich einer der Spitzenreiter der Interaktion bei LinkedIn.

Er hat gesagt, das geht in drei einfachen Schritten.

Erstens, den Elfenbeinarchitekten rauswerfen.

Zweitens, DDD, also Domain-Domain-Design.

Drittens, akzeptieren, dass Architektur lebendig ist und niemals abgeschlossen.

Ich finde das aus mehreren Gründen schwierig.

Das Erste ist, dass damit impliziert wird, dass Architekten im Elfenbeinturm sitzen.

Also den Elfenbeinarchitekten rauswerfen impliziert, dass es jemanden Architekten gibt, der im Elfenbeinturm ist, dass man den entfernen will.

Ich bin bekennender Non-Coding-Architekt und ich hoffe, dass ich das Gegenteil bin.

Also dass ich kein Elfenbeinturm-Architekt bin, obwohl ich das eben nicht code, weil ich eben Entscheidungen moderiere, Hinweise auf Architektur, Ansätze gebe und so weiter.

Auch da gibt es Diskussionen, die ich geführt habe.

Ich finde, Coding-Architekten sind durchaus eine Alternative.

Das kann man so machen.

Ich würde aber auch behaupten, dass Non-Coding-Architekten wie ich auch eine Alternative sind und durchaus Wert generieren können.

Sonst wäre ich sozusagen arbeitslos.

Domain-Driven Design

Die Geschichte mit Domain-Driven Design ist insofern richtig, als dass das eben zu fachlicher Flexibilität führt.

Wir haben aber gerade darüber diskutiert, dass es drei Dimensionen sind.

Technische, organisatorische und fachliche Flexibilität.

Die anderen Dimensionen werden vernachlässigt.

Das stand in der Frage bei LinkedIn.

Von daher ist es ein bisschen komisch, das nicht aufzunehmen.

Und diese Geschichte mit der Lebendigen Architektur, genau.

Deswegen wollen wir ja irgendwie Flexibilität, damit sie eben lebendig ist und sich anpassen kann.

Und eben nicht, wie dort steht, abgeschlossen ist, sondern eben änderbar.

Führt aber zu der Frage, wie mache ich es denn jetzt?

Sich eben hinzustellen und zu sagen, ich akzeptiere das, dass sie eben nicht abgeschlossen ist.

Ja, finde ich gut, dass man es akzeptiert.

Aber das ist kein konstruktiver Vorschlag, der dazu führt, dass wir es jetzt im Endeffekt ändern können.

Dann kamen weitere Fragen.

Urs Enz hat gefragt, wieso hilft die Idee, dabei flexibel zu sein?

Und Sven Müller hat dann geantwortet, erstens erlauben saubere Domainschnitte, dass einzelne Module beziehungsweise Services von unabhängigen Teams entwickelt und getrennt voneinander skaliert oder auch komplett ausgetauscht werden können.

Und das Zweite, was Sven dann für die Idee ist, seiner Meinung nach der stärkere Grund, es sorgt für eine kollaborative Angehensweise, sodass die Architektur von allen relevanten Bereichen der Organisation mitgetragen wird.

Dadurch gibt es weniger blinde Flicken und ein besseres Verständnis auf allen Ebenen, wie neue Entstandeneinforderungen umgesetzt werden können.

Das ist insofern spannend, als dass das eben bedeutet, dass wir nicht über zum Beispiel taktisches Domain-Domain-Design, also über Domain-Domain-Design auf der Ebene von Klassen sprechen, sondern wir sprechen über kollaborative Praktiken, Event-Storming, solche Geschichten und Strategic Domain-Domain-Design, also wie wir Systeme in größere Teile aufteilen.

Und das finde ich schon spannend, aber es steht da dann irgendwie auch, dass es zu unabhängigen Teams führt, was eine organisatorische Geschichte ist.

Und das ist nicht zwangsläufig.

Also wenn ich die Teams sozusagen nicht freilasse und nicht dafür sorge, dass sie das eben tatsächlich auch tun dürfen, dann habe ich zwar vielleicht die Möglichkeit dafür eingebaut und meine Architektur, aber ich habe es nicht umgesetzt und dann habe ich halt ein Problem.

Dann gibt es eine weitere Diskussion.

DDD ist ja auch nicht in jedem Business-Kontext die ultimative Lösung.

Ist man hauptsächlich im Enterprise-Integration unterwegs, gibt es andere Design-Prinzipien, die angebrachter sind?

Wir haben zum Beispiel letzte Woche gesprochen, vorletzte Woche, über das, was Netflix da mit einem großen Aufwand macht in Bezug auf Datenintegration.

Und da kommt dann die Antwort, klar, auch DDD ist kein Silver-Bullet, so sagt Sven Müller.

Die gibt es einfach im echten Leben nicht, weil es bei DDD aber eben darum geht, dass Teams möglichst unabhängig voneinander Mehrwert schaffen können, glaube ich schon, dass man damit nicht ganz falsch gegenüber Flexibilität gefordert ist.

Sondern hat der Rainer Falke, den wir vorhin schon hatten, noch geschrieben, Sven Müller stimmt, dann ist aber keine Lösung, sondern Resignation.

Was wiederum bedeutet, tatsächlich würde ich auch sagen, DDD hat einen bestimmten Ansatz-Kontext, also den, wo es eben darum geht, mit sehr viel Geschäftslogik umzugehen.

Wir haben bei dem Netflix-Beispiel gesehen, von der letzten Episode, dass es eben andere Fälle gibt, wo es vielleicht eher darum geht, Daten zu analysieren, wo es vielleicht nicht so viele Geschäftslogik gibt.

Da hilft mir halt klassisches DDD vielleicht gar nicht so viel weiter.

Insgesamt, und das ist vielleicht so ein bisschen das Problem, ich bin der Meinung, wenn ich jetzt ja eigentlich die Aussage, ich habe irgendetwas, ein Team, eine Umgebung und ich kann das halt verbessern, indem ich eben sage, ich schmeiße den Architekten aus und ich mache nur mein Design.

Das finde ich schwierig, weil kann sein, dass das ja schon funktioniert und dass es halt andere Sachen gibt, die man optimieren muss.

Wenn die Architektin einen guten Job macht oder wenn du dein Design schon umgesetzt hast, dann hilft mir das halt nicht.

Und da muss ich halt irgendwie flexibel sein.

Ich muss mich adaptieren und gerade die These, dass Architekten grundsätzlich einen schlechten Job machen, finde ich, ist irgendwie eine steile These.

Genau, das dazu.

Dann haben wir als nächstes den Jan Rotkegel, der schrieb, hier wurden schon viele wertvolle Anhaltspunkte geliefert.

In meinem Umfeld entwickeln wir Inhouse Software für die eigene Fertigungslandschaft.

Flexibilität kann hier auch heißen, ich möchte in der Lage sein, inzusourcen, outsourcen und intern, sowie sie extern umzusourcen.

Dabei spielen dann der Technologie, der Kommunikation, aber auch heute noch die Sprache und ein gewisser Grad an Dokumentation eine Rolle.

Modularisierung und die Fähigkeit, Entwicklungskomplexe auf Ausführungsumgebung einfach bei Entwicklern hochzuziehen, Stichwort Docker, sind ein weiterer Pluspunkt.

Da gibt es jetzt, glaube ich, einen Punkt, den ich persönlich ganz spannend finde.

Und das ist der Punkt, also welche Art von Flexibilität meinen wir.

Hier meinen wir eine Flexibilität, oder das ist das, was der Jan im Prinzip sagt, wo wir sagen, es sind unterschiedliche Leute, die an dem System arbeiten können.

Ich muss gestehen, da gibt es diese Folge darüber, dass Softwareentwicklung eigentlich Lernen ist.

Ich finde es schwierig, einfach zu sagen, ich habe ein Stück Software und ich gebe das irgendwie jemand anders, weil das Erlernen der Domäne, das Erlernen des Systems ist sehr viel Aufwand.

Und ich glaube, tatsächlich einer der determinierenden Faktoren von dem, was wir überhaupt machen in der Softwareentwicklung.

Deswegen bin ich nicht sicher, ob ich das wirklich so als Ziel umsetzen wollen würde, weil es einfach dazu führt, dass ich eben andauernd neu dieselben Sachen lerne.

Aber das ist vielleicht eben etwas, was irgendjemand mir sozusagen aufzwingen.

Und da muss ich eben diese Flexibilität umsetzen.

Und wenn man sozusagen zu dem zurückkehrt, was wir gerade auf der Folie da vorgesehen haben, dann hilft mir sowas wie Domain-Tuning gar nicht weiter.

Und deswegen fand ich das eben spannend, weil eben hier eine ganz andere Interpretation von Flexibilität ist.

Und damit steht das halt sehr gut stellvertretend für die ganzen Anforderungen oder die ganzen Bemerkungen, die hinauslaufen auf, hey, das ist ja total cool, dass du flexibel sein willst.

Kannst du mal bitte sagen, was das genau bedeutet?

Und hier ist ein schönes Beispiel, wo die Aussage ist, dass mit der Flexibilität ein ganz anderes Thema ist.

So, jetzt habe ich über den Urs gerade eben gesprochen und er ist tatsächlich hier.

Und er sagt, ich könnte jetzt ja auch sagen, dass es nicht die Idee ist, sondern Kollaboration, Modularisierung, guter Fit, Domäne Software Design.

Ich habe diese Episode vor einiger Zeit gemacht, wo ich eben auch gesagt habe, dass vielleicht Modelle eigentlich das Interessante sind.

Und dieses Thema, also dass eigentlich Modelle interessant sind, das weist genau auf diese Sache hin, dass Modularisierung interessant ist, dass ich diesen Fit zwischen der Domäne und meinem Software Design hinbekommen muss.

Das ist etwas, was eben auch außerhalb von Domänen Software Design gilt.

Also ein Modell ist irgendwie etwas, was irgendwie eine Funktionalität aufteilt oder auch ein Modul.

Und das gilt halt allgemein.

So, genau, das dazu.

Dann lasst uns mal schauen, dass wir sozusagen weitermachen.

Genau, dann kam halt die Aussage von dem Ingo Eichhorst.

Also der hat geschrieben, Flexibilität ist eine Illusion.

Ingo hatten wir ja bei uns auch im Stream mit Ralf zusammen.

Es ist ja der Sinn von Softwareordnung und Struktur zu liefern.

Wir können zwar vorausdenken, was sich in Zukunft eventuell ändern wird und dafür Vorgehungen treffen, aber dann sind wir ja nicht mehr flexibel, sondern haben gut geplant.

Und ich finde das halt schwierig, weil ich glaube, die Änderbarkeit eines Systems auch auf nicht vorhergesehene Sachen ist etwas, was eine Eigenschaft einer Software sein kann oder eben auch nicht.

Deswegen würde ich behaupten, diese Flexibilität gibt es.

Also wenn ich jetzt sage, okay, wir haben das geändert haben, dann ist das eben etwas, wo die Software flexibel sein kann oder auch nicht.

Und was ich ja spannend finde, ist halt die Geschichte mit dem Vorausdenken.

Das ist tatsächlich auch etwas, wo eine ganze Menge an Antworten von euch gekommen sind, die eigentlich sagen, also Vorausdenken ist und absichtlich Abstraktionen einbauen.

Das ist vielleicht nicht so eine gute Idee.

Wir hatten auch eine Folge, wo wir das diskutiert haben und festgestellt haben, dass einmal gibt es eine Folge zur Wiederverwendung und Product-Line-Engineering.

Das sind zwei Folgen, wo wir im Prinzip sagen, also man kann im Nachhinein erst sagen, ob Dinge wiederverwendet werden sollen.

Und dann gibt es, das muss man kurz raussuchen, genau, mit dem Bert-Jan Schrievers über Generic oder Specific, wo er eben auch sagt, wenn ich halt irgendwie etwas habe und das halt baue, dann kann ich erst beim dritten Mal sozusagen Dinge wiederverwenden und neu bauen.

Und das ist eben auch etwas, was einige von euch irgendwie später gesagt haben, in diesem nicht einfach bauen und solche Sachen.

Und das impliziert hat, dass Vorausdenken die falsche Strategie ist, so ein bisschen.

Erlangt Strahle dafür aber auch einen Preis.

Option weiß ich nicht.

Ich will eigentlich sagen, die Software lässt sich gut anpassen auf irgendwas, was ich jetzt machen muss.

Und Ingo hat darauf geantwortet, es gibt ja die gute Idee, dass man Entscheidungen so spät wie möglich treffen sollte.

Genau, das ist für mich nicht der Last Responsible Moment.

Vor der Entscheidung haben wir also Flexibilität und nach der Entscheidung keine mehr.

Weiß ich nicht.

Also ich kann auch zum Beispiel entscheiden, das System flexibler zu bauen.

Das trifft in der Entscheidung ist Architekturarbeit.

Wir schränken Flexibilität ein und das ergreift dann eine valide Sichtweise.

Bin ich unsicher.

Also auf jeden Fall bedeutet Last Responsible Moment, dass ich mit einer gewissen Flexibilität sozusagen rechne.

So, jetzt noch mal kurz gucken, was da in den Kommentaren steht.

Der W3HR schreibt, wer gut plant, ist halt später flexibel.

Glaube ich nicht und das ist halt auch so.

Das würde ja implizieren, dass ich Änderungen vorhersehen kann.

Und da ist halt die Geschichte, dass ich eher versuchen würde, eine saubere fachliche Architektur zu bauen, um dann irgendwie zu sagen, ich habe ein gutes Domainmodell, was dann hoffentlich auf fachliche Änderungen vernünftig reagiert.

So weit sozusagen dazu.

Ich möchte gerne ergänzen, dass wir in der Planung eine Episode haben für den 19.9.

Das ist also in 14 Tagen über Residuality Theory mit dem Barry O’Reilly.

Das ist ganz spannend, weil der eben tatsächlich im Prinzip sagt, ich habe hier ein Maß, mit dem ich entscheiden kann, wie gut mein System auf unvorhergesehene Sachen reagieren wird und wie flexibel es ist.

Was ich ja ehrlich gesagt immer noch ein bisschen kontraintuitiv finde.

Aber die Idee ist halt sehr spannend und wir sollten uns mit der beschäftigen.

Und das wäre so ein bisschen die Episode, über die wir da sprechen können.

Genau, also Mia Ruff-Hindley schreibt, kann man Flexibilität als Begriff abstrakt betrachten?

Das ist ja ein bisschen das, was ich versucht habe, durch die Frage so zu implizieren, dass man das eben kann.

Und das ist mit so einem Konkreten nachvollziehbar.

Gut, dann lasst uns weiter durch die Folien gehen.

Der Michael Meyerhoff hat geschrieben, ich wähle anderes.

Das ist die vierte Option bei LinkedIn.

Flexibilität ist immer kontextabhängig, was in einem Atomkraftwerk gilt, unterscheidet sich von einem Internet-Plattform.

Am Ende misst sie sich an den Change-Kosten und entsteht erst im Zusammenspiel von Technik, Fachlichkeit und Organisation.

Und das Beispiel 1 ist der Flugzeug-versus-Online-Shop.

In der Luftfahrtsoftware bedeutet Flexibilität, dass Systeme auch nach Änderungen unter allen Umständen stabil und zertifizierbar bleiben müssen.

Im Online-Shop dagegen heißt Flexibilität, schnell neue Bezahlungsmethoden oder Features einzuführen, um den Marktanforderungen zu entsprechen.

Mein Problem dabei ist, dass das für mich nachvollziehbar ist.

Und wenn der Michael jetzt Software für Flugzeuge und Online-Shops geschrieben hat, dann nehme ich ihm das sozusagen ab.

Weswegen ich das rausgepickt habe, ist, weil ich in einer Beratungssituation erst mal anfangen würde und meine Intuition hinterfragen würde.

Ich würde behaupten, auch in der Luftfahrtindustrie ist es vielleicht so, dass ich neue Features haben möchte und Dinge haben möchte, die dann schnell gebaut werden.

Also auch die Entwicklungszeit eines Flugzeugs ist durchaus relevant und ist teuer.

Das heißt, wenn ich da Aufwand sparen kann, ist das vielleicht gut.

Das heißt also, dieses Maß, das jetzt angenommen wird für den Online-Shop, nämlich wie schnell kann ich eine Änderung in Produktion bringen.

Ich weiß nicht, ob das für Flugzeuge nicht gilt.

Ich könnte mir vorstellen, dass es dann doch gilt.

Vielleicht nicht ganz so krass.

Das zweite Beispiel ist ein Bankensystem versus Social-Media-Plattformen.

Ein Bankensystem bedeutet Flexibilität, regulatorische Änderungen zu Verlässlichung und Risiko umzusetzen.

Auf einer Social-Media-Plattform dagegen heißt es Flexibilität, ständig neue Interaktionsformen oder Features auszuprobieren.

Ich benutze Blue Sky, Mastodon und LinkedIn.

Ich weiß nicht, wann ich das letzte Mal als Feature gesehen habe oder neue Interaktionsformen.

Ich weiß es tatsächlich ad hoc nicht.

Auf der anderen Seite ist es so, dass Banken durchaus durch Fintech auch unter Druck stehen, neue Features zu liefern.

Das ja auch wieder dazu führt, dass ich mir eben nicht so sicher bin.

Das ist nochmal ein willkommener Grund.

Ich will eigentlich Qualitätsziele haben.

Ich möchte wissen, wo ich in diesem Fall flexibel sein soll.

Das ist ja auch genau das, was wir diskutiert hatten oder was viele von euch gesagt haben.

Ich muss eben sagen, wo ich genau flexibel sein möchte.

Das ist dann eine Geschichte, wo man mit Qualitätszielen, Qualitätsanforderungen und diesen ganzen Sachen zu einem Ergebnis kommen kann.

Das ist der Grund, weswegen wir viele Episoden haben, die sich genau damit auseinandersetzen.

Das heißt also, lange Rede kurzer Sinn, wenn ich ein System reviewe oder selber Architektur baue, würde ich versuchen, mich bewusst naiv zu stellen und herauszufinden, was tatsächlich die Qualitätsanforderungen sind und die umsetzen und mich nicht hinstellen und mit meiner Intuition darauf schlagen.

Ich kann nicht sagen, was bei mir jetzt der Fall ist, ob der solche Systeme schon gebaut hat.

Dann glaube ich ihm das und dann ist das seine Erfahrung.

Wenn es Dinge sind, die nur in einem Fußstrich, nur intuitiv klar sind, dann ist das etwas anderes.

Da muss man sich die Karten dann legen.

Das dazu.

Jetzt kommen ein paar inhaltliche Bereiche.

Soziale Mechanismen und Mindset

Das Erste, was ich total interessant fand, war so etwas, wo ich gesagt habe, es gibt einen Bereich, der sagt, ich muss soziale Mechanismen anwenden, um dafür zu sorgen, dass ich flexibel bin.

Das ist ein Aspekt, der jetzt bei diesen drei Fragen nicht drin ist.

Wobei die letzte Frage mit der Organisation geht schon in diese Richtung.

Deswegen diskutieren wir es auch in diesem Flextraining oder ich diskutiere das dort.

Diese Auswirkungen auf die Organisation oder der Einfluss, den finde ich da total spannend.

Ich habe mir erst mal die Silvia Enslen rausgesucht.

Sie sagt, ein flexibles Mindset der Entwicklenden.

In einem lebenden Software-System sollte man nie irgendetwas als fertig begreifen.

Nichts ist in Stein gemeißelt.

Deswegen heißt es auch Software.

Man muss merken, wenn eine vorhandene Architektur nicht mehr passt und dann auch den Mut haben, die Dinge zu ändern.

Sicher gibt es Basics, die man von Beginn an beachten sollte.

Ich bezweifle allerdings, dass man oft in der Lage ist, eine Architektur zu erstellen und umzusetzen, in der alle zukünftigen Anforderungen leicht integrierbar sind.

Der Wille zur Veränderung ist deshalb für mich das Wichtigste.

Das fand ich sehr schön, weil das tatsächlich ein netter Versuch ist.

Wenn du das alles hinbekommst und vielleicht sogar planst, du wirst trotzdem die Zukunft nicht vorhersagen können.

Du musst dann sagen, das, was du dir als Ansatz überlegt hast, ist doch nur begrenzt gut gewesen.

Ich muss es jetzt wegwerfen und neu machen.

Das finde ich nachvollziehbar.

Das ist ein guter Punkt.

Genau dieses Mindset, wie sie sagt, ist etwas, was notwendig ist.

Ich darf mich nicht hinstellen und sagen, meine Architektur kann es sicher ab, diese Änderungen umzusetzen, sondern ich muss darauf vorbereitet sein, dass sich die Architektur eben ändern muss.

Der Jan Moser hat etwas Ähnliches geschrieben.

Er hat geschrieben, auch für den Mindset, alle oberen Maßnahmen helfen dabei, flexibel zu sein.

Wenn aber das Team dies nicht ultimativ will oder versteht, verteilte Systeme sind komplexer als Mono oder Monolithische.

Mit dem Team meine ich Architektur sowie Development-Rollen.

Da bringt die Liebe Mühe nichts.

Ich muss daran denken, es steht in dem Accelerate Buch zum Thema Architektur, dass eben genau diese Diskussion rund um Microservices oder was auch immer es ist, häufig die falschen Diskussionen sind.

Wir wollen bestimmte Ergebnisse haben, also eben eine flexible Architektur.

Diese technischen Maßnahmen bringen dann eben nichts, wenn ich diese Ergebnisse nicht produziere.

Hier spielt es ein bisschen rein, wenn die Leute das sozusagen nicht auf die Reihe bekommen, weil sie es nicht verstehen, weil sie es vielleicht auch hassen oder so.

Dann bringt mir das eben auch nichts, diese technische Möglichkeit an der Stelle.

Micha Pitsch hat geschrieben, dass alle Entwickler im Team fortlaufen und dafür sensibilisieren.

Konkrete Beispiele besprechen Ruhe, Langsames, Präzises, schnell und so weiter.

Finde ich auch einen sehr guten Punkt und unterstützt halt diese Geschichte, dass seit Technik-Adapt schlechte Codequalität meiner Ansicht nach in erster Linie damit zusammenhängt, dass eben Stress erzeugt wird durch vielleicht sogar künstliche Deadlines und dann geht eben die Qualität runter.

Dann wird die Software unflexibel und Micha hat da glaube ich einen guten Hinweis, dass man eben, wenn man sozusagen Ruhe ins Team bekommt, dass dann die Ergebnisse gut sind, was halt tatsächlich in der Reihen eben organisatorische Maßnahmen ist.

Peter Fichtner hat geschrieben, leider keine Mehrfachauswahl möglich.

Neben einer guten Fachlichen Architektur ist für mich ein wesentlicher Aspekt die Befähigung der Mitarbeitenden.

Ich kann auch eine saubere Fachliche Architektur technisch komplett zementieren, so dass ich kaum noch Änderungen am System der Architektur des Systems vornehmen kann.

Da steht halt die Befähigung, das ist für mich eher so ein soziales Ding, dass ich die Mitarbeiter dazu empower in irgendeiner Art und Weise, das eben tatsächlich auch umsetzen zu können.

Gleichzeitig schwingt da für mich irgendwie sowas mit, dass man in einigen Situationen zumindest versucht hat, also ich identifiziere das so mit den 90ern und dem Anfang der 2000er, halt bewusst technische Frameworks einzuführen, die eben dafür sorgen, dass Entwickler nur bestimmte Dinge tun können.

Entwickler sind ja zu doof, bestimmte Entscheidungen zu treffen.

Deswegen kriegen sie halt sozusagen ihren vorgezeichneten kleine Box, in der sie arbeiten dürfen.

Da haben jetzt Leute vorgedacht, was irgendwie passieren soll.

Ich kenne ein Projekt, aber das hat die Aussage nicht.

Die Entwickler sind zu doof, SQL Statements zu schreiben.

Das heißt, wir bauen ein Framework, was das eben praktisch und möglich macht.

Das war ein bisschen suboptimal und weil ich dann eben nicht handoptimierte Queries bauen kann, weil da auch bestimmte andere Konzepte drin waren, die schlecht waren.

Das ist dann eben genau das, wo ich letztendlich eine technische Maßnahme ergreife, um nicht Entwicklern zu empowern, sondern das Gegenteil zu machen.

Eine ähnliche Geschichte der Billy85 bei BlueSky, zumindest nicht mit Zentralisierung, von der ich leider betroffen bin.

Ich kann also nur theoretisch davon plaudern, aber lose Kopplung ist das Erste, was mir einfällt.

Eine lose Kopplung wäre dann eben eine technische Eigenschaft des Systems.

Bei der Zentralisierung habe ich eher das Gefühl, aber das ist ein bisschen offen, dass das eben eine organisatorische Maßnahme ist, die eigentlich eine Flexibilität widerspricht.

Dann Daniel Nowak hat geschrieben, auch wieder bei LinkedIn, eine Erfahrung zeigt, dass es immer eine Dreier- Kombination ist, die auf Dauer am meisten Erfolg gebracht hat.

In den meisten Fällen wurde jedoch auf mindestens einen der Bausteine vergessen.

Erstens gute Architektur, die zum System passt.

Zweitens, kurz zur Sicherstellung der Requirements der Architektur, keine Architekturverletzung.

Drittens, Schulung und Verständnis der Prinzipien dahinter.

Meistens fehlt der Punkt drei, also dass ich eben die Prinzipien vermittle, egal ob bei Modulitech, Sagonalen Microservices, etc., weshalb Dinge unschön wurden und dann wieder der Plan nicht so aufgegangen ist, wie er sollte.

Wenn man neuen Kollegen, egal ob Senior oder Junior, nicht abholt und schult, bauen sie an den falschen Ecken rum.

Mich hat das erinnert an die Episode, die wir gemacht hatten über ArcUnit mit dem Peter Garfarth, wo es genau darum ging, dass man mit ArcUnit eine Architektur im Sinne einer Aufteilung eines Systems spezifizieren kann.

Wenn es eine Architekturverletzung gibt, dann gibt es zwei mögliche Szenarien.

Entweder die Person, die die Architekturverletzung durch Code erzeugt hat, hat nicht verstanden, wie die Architektur aussieht.

Dann sollte man miteinander reden.

Oder die Architektur hat das spezifische Szenario, auf das diese Person gerade gestoßen ist, nicht abgedeckt.

Dann sollte man auch miteinander reden und die Architektur ändern.

Das erinnert mich hier ein bisschen daran, also dass ich sage, ich habe damit Konzepte, aber die Menschen müssen sie verstehen.

Ich muss einen Prozess haben, um dafür zu sorgen, dass sie verstanden werden.

Was hier ein bisschen fehlt, ist dieser Feedback-Loop.

Wenn ich eine Architekturverletzung habe, dann bedeutet das nicht, dass die Person, die die Architekturverletzung erzeugt hat, dumm ist.

In dem Sinne, dass sie etwas nicht verstanden hat.

Sondern es kann eben sein, dass sie tatsächlich versucht, etwas zu tun, was sie eigentlich auch tun müsste und das sinnvoll ist.

Das hat die Architektur vermeidet.

Dann muss ich eben durch den Feedback-Loop sicherstellen, dass ich die Architektur ändere.

Nikolaj Wolko sagt, da stellt sich mir zunächst die Frage, was flexibel überhaupt bedeutet.

Für mich ist eine Architektur dann flexibel, wenn sie klare Verantwortlichkeiten, hohe Kohärenz und geringe Kopplung auffasst.

In der Praxis oft nur sehr schwer erreichbar.

Technik und Know-how allein reichen nicht.

Es braucht über längere Zeit geliebte Disziplin.

Dazu gehören technisches Können, ein Umfeld mit Bewusstsein für Qualität, von der Empfindungsermittlung bis zur Abnahme und der Wille, nicht dem schnellen Ergebnis hinterher zu laufen.

Das Wie ist oft bekannt oder zumindest erahnbar entscheidend.

Ist der konsequente Weg dahin, wenn ich es auf eine Antwort reduzieren sollte, dann wäre meine Disziplin.

Das ist genau das, worum es geht.

Ich habe ein bestimmtes Mindset, wie wir bei dem Begriff am Anfang gesehen hatten, von diesem Abschnitt.

Der Nikolaj ist eben zentral und ich finde das genau nachvollziehbar.

Was haben wir dann?

Ich habe mir dieses Kapitel genannt, nicht abstrahieren, wenig bauen.

Da ist erstmal achtsam Coden von Mastodon, der geschrieben hat, nur Funktionen einbauen, die man auch wirklich braucht oder dadurch wieder entfernen kann.

Den Code immer wieder vereinfachen, der Versuchung widerstehen, Dinge im Voraus möglichst abstrakt zu implementieren, damit man sie später erweitern kann.

Da man keine Kristallkugel hat, ist die Wahrscheinlichkeit groß, dass man die falschen Abstraktionen baut.

Viel mit dem Code arbeiten, ein Teil der Architektur ist im Kopf.

Wenn man sie vergisst, wird man sich mit Anpassung schwer tun.

Da ist genau diese Geschichte nicht das Gegenteil von Planung.

Also nur das bauen, was ich wirklich benötige.

Vereinfachen, reduzieren, nicht flexibel bauen und ich finde auch diesen Hinweis interessant, mit dem Code arbeiten.

Wenn man damit nicht arbeitet, dann vergisst man sie halt und dann werden Anpassungen schwierig.

Das ist ein interessanter spannender Punkt.

Nexos bei, ich meine das ist auch Mastodon, ja nicht, das ist Mastodon bei einem Logo.

Man nehme eine nicht flexible Architektur, bricht sie an all den Stellen, an denen sie nicht flexibel genug war.

Bei Bedarf noch ein großer Löffel unnötige Flexibilität an der anderen Stellen entfernen, gut umrühren und nicht dekoriert serrieren.

Was eben auch letztendlich bedeutet, typischerweise laufe ich in die Falle, dass ich Flexibilität an den Stellen genau baue, wo sie unnötig ist.

Und das hier ist so ein bisschen so ein Refactoring danach oder Umbau, sollte ich sagen.

Ein Umbau, der jetzt sagt, wir machen das jetzt mal richtig und lösen die ganzen Probleme, die wir in Bezug auf Flexibilität hatten.

Robert auch bei Mastodon hat geschrieben, don’t try to be clever, also nicht schlau versuchen zu sein.

Meiner Meinung, meiner Erfahrung nach stehen Libs, Tools, die tief abstrahieren, irgendwann im Weg.

Alles, was das Leben am Anfang leichter macht, macht es später schwerer.

Also auch wieder nicht das spezielle Ding, das wir bauen.

Bei den Libraries und den Tools bin ich mir nicht sicher.

Ich würde behaupten, gute Libraries funktionieren halt für einfache Fälle und auch für komplexe.

Aber es gibt Ansätze, die halt für einfache Fälle funktionieren, aber nicht mehr für komplexe.

Und ich glaube, wir kennen alle solche Sachen wie ein Excel-Makro, das skaliert halt nur bis zu einem gewissen Punkt und dann muss man es halt irgendwie sozusagen richtig ablösen, weil man dann irgendwie die Komplexität überschritten hat, die halt mit Excel vielleicht noch irgendwie geht.

Und das gilt halt auch für andere Umgebungen, die zum Prototyping oder so gedacht sind.

Und ich glaube, da ist Robert’s Hinweis genau gut.

Patrick Wunderlich schreibt, so viel wie nötig und so wenig wie möglich.

Sorry für die Mithandwort.

Passt aber.

Ich meine, meine Frage war auch fies.

Wie erreicht man Flexibilität?

Das ist eine super offene Frage, von der finde ich das passend.

Wolfgang Müller, ich fand beim Original-Paper über das Wasser vom Modell super interessant, dass da drin steht, ich mache das Ganze zweimal.

Einmal, um es zu lernen und einmal, um es zu machen.

Und das passt zu dieser Regel, über die wir auch schon gesprochen hatten.

Diese Episode mit dem Gärtner, also wenn ich Dinge mehrmals mache, erst dann weiß ich eigentlich, was der generische Teil ist.

Ich kann das nicht vorweg planen, sondern ich kann es nur danach entscheiden.

Also sollte ich erst danach tatsächlich den generischen Teil rausziehen.

Und Wolfgang schreibt weiter, ich denke eine sinnvolle flexible Struktur bekommt man, wenn Leute mit tiefer Erkenntnis von Software Engineering und tiefer Kenntnis des Problems zusammenarbeiten.

Das ist ein guter Punkt.

Es kann sein, dass Leute, die halt wirklich die Domäne sehr gut kennen, irgendwie antizipieren können, wo halt Änderungen sind und das halt rausfaktorisieren können.

Das will ich nicht in Abrede stellen.

Ich neige dennoch dazu, mich zu fragen, ob das dann eben tatsächlich so stimmt und dieses halt richtig vorlesen können.

Aber das könnte halt funktionieren.

PV hat geschrieben, auch bei BlueSky, Dinge erst dann umsetzen, wenn sie andersweichlich sind.

Nicht so tun, als hätte man gewusst, wie sich die Zukunft entwickelt.

Ich löse den Save-On.

Und Dinge erst vereinheitlichen, wenn sie wirklich mindestens dreimal vorkommen.

Das ist die Idee von dem Gerd.

Wenn man Optionen benötigt, um die Varianten abzubilden, eignet es sich wenig für dry.

Also don’t repeat yourself.

Sich nicht wiederholen.

Schade, dass es hier nicht mehr ernsthafte Antworten gab.

Ich hätte gerne etwas dazugelernt.

Ich hoffe, die Episode hilft dir.

Es gab eine ganze Menge an Antworten, nur eben über die verschiedenen Kanäle sozusagen verteilt.

Und Apollo, auch bei Mastodon, schreibt, ich denke durch KISS.

Also keep it simple, stupid.

Also halt es einfach, blöd Mann.

Lieber kleine, spezielle Programme als extreme Monolithen.

Aber Microservices müssen es in der Regel auch nicht sein.

Da kommt man durch sein Zweig zu viel Komplexität rein.

Eigentlich, ich behaupte halt, dass Microservices nur eine weitere Form der Modularisierung sind und einem nicht helfen.

Also Microservices zeigen nur, wie ich mein System aufteile.

Technisch in Docker Container.

Die sagen nicht, was ich dort aufteile.

Also die Fachlichkeit.

Deswegen ist es ja, glaube ich, so wichtig, beide Aspekte zu betrachten.

Das ist die Unix-Philosophie, die sagt, dass ich ein kleines Programm schreibe, das irgendwas kann.

Es gibt zum Beispiel Sort, mit dem ich Sachen sortieren kann.

Und das ist der Grund, warum ich mit ls-rtl, leicht zu merken, die Dateien sortiert nach Datum ausgegeben bekomme, weil eben Sort das Sort macht.

Also nicht diese angebliche Unix-Philosophie, die sagt, ich habe ein Programm, das genau eine Sache macht.

Sort sortiert die Sachen und ls listet die Files auf.

Stimmt halt nicht.

Es gibt eine Option, mit der ich in ls die Files nach Datum sortieren kann.

Und die ist super nützlich.

Deswegen bin ich mir eben nicht so sicher, ob diese kleinen speziellen Programme, ob das so stimmt.

Also man sieht halt, die Unix-Philosophie ist da zumindest an dieser speziellen Stelle durchbrochen.

Apollo schrieb weiter, wenn ich so darüber nachdenke, wird man die Architektur immer wieder hinterfragen und anpassen müssen, sodass das Flex seiner Anforderungen erfüllt.

Genau.

Also ich muss iterativ, inkrementell meine Architektur ändern, weil ich die Anforderungen nicht vorhersehen kann.

Was aber bedeutet, dass ein gewisses Maß an Flexibilität notwendig ist, sonst kann ich das halt nicht.

Und das ist eben dort genau der Fall.

So, dann hat auch Raubhach geschrieben, gar nicht erst anfangen.

Flexibel endet immer irgendwann.

Zoff ist irgendwie organisch.

Klein wächst, gedeiht.

Finde ich übrigens einen guten Punkt.

Also das ist eben tatsächlich etwas, was wächst und ich kann das Wachstum guiden.

Und ich glaube, das ist halt eine Möglichkeit.

Viele Ideen, Wünsche und Features.

Dann trägt es Früchte, man erntet und irgendwann sind es alte Riemen und es wird Zeit zu akzeptieren, dass die Software am Ende ist und pflanzt erneut.

Weiß ich nicht.

Ich bin halt nicht sicher, ob ich Sachen halt komplett neu schreiben will.

Das wäre das, was so ein bisschen impliziert wird.

Aber ja, ich weiß auch nicht, ob Flexibilität endet irgendwann, ob ich das unterschreiben würde.

Wenn man nicht aufpasst, geht es ja zurück.

Aber ich kann halt auch wieder investieren und dafür sorgen, dass es flexibler wird.

Der oder die Mira Findley hat geschrieben.

Nochmal zur Linux-Philosophie.

Inwiefern passt das zur Flexibilität und zu Microservices?

Also die, hatte ich nicht gesagt, die Unix-Philosophie ist eben angeblich ein Leitbild für Microservices.

Also kleine spezialisierte Programme schreiben, die ja zusammen dann als Microservices ein Ergebnis produzieren.

Und das passt zur Flexibilität, weil ich dann eben diese kleinen Teile austauschen oder ändern kann und das Rest geändert wird.

Und das ist eben so der Ansatz, mit dem eben Microservices oder eben auch die Unix-Philosophie, ich hatte vorhin darüber gesprochen, dass ich eben nicht glaube, dass es tatsächlich stimmt, zu einer Flexibilität führen.

Gut, Sven Riemann.

Auch bei LinkedIn hat geschrieben, aus meiner Erfahrung ist die Frage nach flexibler Software-Architektur so allgemein kaum gestellt, kaum zu beantworten.

Genau, das ist eine fiese Frage.

Wenn man Flexibilität als Anforderung formuliert, führt das oft zu Over-Engineering.

Es entstehen Frameworks, die alles können sollen, in der Praxis aber oft doch nicht alles abdecken oder nur mit einschränken können.

Zum Beispiel bei der UX, Relierbarkeit oder Wartbarkeit.

Entscheidend ist, dass der Business-Use-Case nie aus dem Blick gerät.

Der fachliche Kontext muss die Klammer sein, nicht eine vermeintlich universelle Architektur.

Das stimmt, das finde ich auch.

Wir müssen das Problem lösen, dann haben wir gute Chancen, eine Software zu bauen, die auch flexibel beantworten kann.

Und insbesondere das fachliche Problem müssen wir lösen.

So, er schreibt weiter.

Ich sehe das so.

Nicht versuchen, die perfekte Architektur für alle unbekannten Anforderungen vorauszubauen.

Genau, das geht irgendwie auch nicht.

Modularisierung einsetzen, um Bereiche klar zu trennen, Austauschbarkeit und Wartbarkeit zu erhöhen.

Module sind eine gute Idee.

Klare Ziele und Rahmenbedingungen definieren, zum Beispiel erwartete Nutzerzahlen, SLAs.

Wenn das dann geht, also wie viele Benutzer ich erwarte, kann man vorher oft, häufig schwer sagen.

Refactoring als normalen Prozess akzeptieren und bei größeren Änderungen auch den Austausch von Teilen und des Gesamtsystems.

Am Ende gilt, man kann nicht alles vordenken.

Flexibilität entsteht durch klaren fachlichen Rahmen, Modularisierung und die Bereitschaft zur laufenden Anpassung.

Genau, also diese Anpassung ist, glaube ich, wichtig.

Jens Reh sagt bei LinkedIn, schreibt, wie flexibel muss es denn sein?

Also welche Art von Flexibilität stellst du dir vor?

Genau, gute Rückfrage und in der Realität auch etwas, was man fragen sollte.

Wenn ich alles flexibel mache, was kann ich dann noch konkret erreichen?

Was habe ich übersehen?

Guter Punkt, also diese Idee zu sein, das System soll allgemein flexibel sein, die ich hier als Frage stelle, sollte man im realen Projektleben hinterfragen, um herauszufinden, welche Art von Flexibilität wir tatsächlich meinen.

Also Software ist erstmal soft, das heißt änderbar.

Einige behaupten, das hätte ein Zyniker sich überlegt, aber nicht.

Deswegen als Software im Software, weil sie soft ist und änderbar.

Stimmt ja auch prinzipiell, damit ist es ja nur eine Frage von Aufwand.

Und dann ist mir die Frage, welche Erinnerungen sollen denn mit möglichst wenig Aufwand funktionieren?

Und Jens schreibt dann weiter, vielleicht bin ich zu naiv, aber mein Ansatz ist KISS.

Also keep it simple stupid, worüber wir schon gesprochen haben und dann Prügel im Review abholen und dann zurück zu KISS.

Also ich finde, das passt schon, weil man darüber jetzt im Prinzip sagt, ich baue irgendetwas, ich baue es möglichst einfach.

Ich habe ein Feedbackloop im Review, kriege dadurch Feedback, was dann möglicherweise sagt, ist vielleicht doch keine so gute Idee.

Und dann arbeite ich halt weiter und das finde ich passt erstmal.

Urs Enzler schreibt noch und nochmals ein Gedanke, es regnet halt immer wieder Benachrichtigungen rein.

Flexibilität entsteht nicht dadurch, dass alles möglichst abstrakt generisch mit vielen Interfaces und überall mit Strategy Pattern gemacht wird.

Strategy Pattern ist dieses Ding, wo ich eine Klasse habe, die hat eine bestimmte Strategie, also einen Algorithmus implementiert.

Vielleicht für was ich nicht Kreditvergabe oder was auch immer, also eine bestimmte Logik.

Dann habe ich eben eine andere Klasse, die eine andere Logik dafür implementiert und so weiter.

Und er schreibt halt, das führt eher zu einem unverständlichen System, welches dann nicht mehr verstanden und somit nicht mehr angepasst werden kann.

Das ist ein guter Punkt, wenn ich halt das über, also wie soll ich sagen, ich kann prinzipiell statt einem If-Then-Else auch ein Strategy Pattern benutzen.

Ich weiß nicht, ob das mehr Flexibilität sorgt, aber auf jeden Fall sorgt es dafür, dass der Code wahrscheinlich schwieriger zu verstehen ist.

Das heißt, manchmal ist es einfach, die Sachen einfach runter zu koden und nicht.

Also das sind wir wieder bei KISS, dann ist man halt fertig.

Und er schreibt weiter, Flexibilität entsteht durch simplen Code, der einfach angepasst und ausgeliefert werden kann.

Also auch wieder kippel simpel.

So, was haben wir denn hier?

Flexibel.

Genau, da hat der Simon Martinelli auf Blue Sky mich zurückgefragt.

Flexibel denn wofür?

Genau, richtige Frage.

Dann hat PV gesagt, Flexibilität heißt, dass die Anforderungen vorher nicht bekannt sind.

Da hat Simon dann gesagt, nun unter Anforderung keine Architektur.

Und da würde ich dem Simon tatsächlich recht geben, denn wenn ich gar keine Anforderungen habe, kann ich kein System bauen.

Also nicht das flexible System ist dann, hier ist eine Programmiersprache, mach es halt selbst.

Das ist halt maximal flexibel und maximal unkonkret.

Und es ist maximal unnütz.

PV schreibt dann weiter, schade, Flexibilität ist meiner Meinung nach eigentlich immer gefordert.

Und es hätte ja sein können, dass du allgemeinere Anwendbarer Best Practices hast.

Und nicht, guter Punkt, Flexibilität ist so ein bisschen eine Anforderung.

Ich glaube, wenn ich zu jemandem hingehe und sage, sollte ich eine unflexible Software bauen, sagt die Person halt, nö.

Wenn ich aber hingehe, was halt de facto passiert ist, dass eben Features gegenüber besserer Flexibilität höher priorisiert werden.

Das heißt also, irgendwie ist Flexibilität dann doch nicht so wichtig.

Und das ist halt das, was Simon ja sagt, wo er sozusagen hinarbeitet.

Ich muss mir überlegen, wo will ich denn flexibel sein?

Also gibt es fachliche Anforderungen oder will ich technisch flexibel sein?

Da sind wir wieder bei den Qualitätsszenarien und da muss ich das halt genauer ausdefinieren, sonst wird es halt nichts.

Da kam dann halt zurück, wenn du keine Anforderungen hast, darfst du dich auch nicht über das Resultat beschweren.

Und da ist ein Bild aus dieser Simpsons Folge, wo Homer Simpson seinen Bruder findet.

Er ist irgendwie Chef von irgendeiner Autofirma und gibt halt Homer den Auftrag, das Traumauto zu bauen.

Und da kommt etwas Absurdes raus mit ganz vielen komischen Featuren.

Und das ist ein Ergebnis davon, dass eben Homers Bruder das, glaube ich, sagt, ist mir völlig egal.

Ich möchte gar nicht wissen, wie du genau vorgehst und was du entscheidest.

Ich will nur das Endresultat sehen, ich vertraue dir vollständig.

Und das ist vielleicht wirklich eine Metapher für, wenn ich keine Anforderungen habe, geht es sozusagen schief.

Urs hat bei Insta, über den wir schon gesprochen hatten, bei LinkedIn eben zurückgeschrieben.

Zuerst mal eine Frage zurück, Flexibilität bezüglich was?

In eine Business Anforderung, Evolution des Marktes, Business Model, Marktsegment, technische Aspekte, Modernisierung, Skalierung.

Ich weiß nicht, ob Modernisierung technisch ist, das bedeutet eher eine fachliche Änderung.

Architektur, Designkonzepte, wir wollen refaktorisieren können, wenn wir eine bessere, einfache, mächtige Lösung finden.

Je nach Antwort dazu sind die Mittel etwas anderes.

Genau und nicht, also in einer Business Anforderung, ein fachliches Ding, technische Aspekte, ein technisches Ding.

Und Urs schreibt weiter, so grundsätzlich wohl nie falsch, sind eine gute Modernisierung.

Ja, Modernisierung wissen wir seit Ende der 60er, dass es eine gute Idee ist.

Vielen Dank Business Capabilities, genau, eben um fachliche Flexibilität zu haben.

Und Entkopplung von Infrastruktur, Libraries, Frameworks, etwa wie Imports und Adapters, Architektur.

Da bin ich mir nicht so sicher, denn eine technisch neue Umgebung ist eher ein seltenes Thema.

Also im Mittel, also da werden jetzt irgendwelche Leute sein, die jetzt sagen, das passiert bei uns ja mit täglich.

Vielleicht nicht, aber wir bauen Standardsoftware und müssen eine Vielzahl an unterschiedlichen Datenbanken unterstützen.

Genau, gut, das ist etwas anderes.

Hier ist dann die Aussage, dass man sowas mit Imports und Adapters zum Beispiel bekommt.

Und ich glaube ein unterschätzter Punkt oder für mich der wesentliche Punkt bei Imports und Adapters ist Testbarkeit.

Das heißt, ich habe eben die Flexibilität, den Business Kern relativ einfach mit Testdingen zu umgeben.

Denn alles andere, also die Persistenz beispielsweise, hängt dann irgendwie vom Business Kern ab.

Die UI hängt vom Business Kern ab, sodass ich eben für Tests jetzt sagen kann, ich habe irgendwie so ein Ding, was halt den Business Kern treibt.

Also die UI ersetzt, ich habe irgendetwas, was statt der echten Datenbank da ist.

Und dadurch kann ich sehr einfach halt das System testen, ohne eben Datenbank, UI oder sowas zu haben.

Und dann schreibt er halt weiter, wenn diese beiden Konzepte anwesend sind, dann lässt sich die Software zu einem gewünschten umbauen.

Genau, es schrieb halt, es ist ja gerade auch persönlich sozusagen da und er schreibt halt, gute Testbarkeit, Förderflexibilität auch.

Genau, guter Punkt, aber das steht da sozusagen nicht drin.

Tatsächlich ist mit Testbarkeit nichts, was glaube ich, in den Antworten drin ist.

Aber deswegen ist es sehr gut, dass wir es vielleicht ergänzen.

Ich kann eben durch gute Testbarkeit das System leichter ändern, weil ich eben eher das System testen kann.

Das heißt, ich werde mich eher wagen, diese Änderung halt sozusagen zu machen.

Und ich würde, aber das hat man glaube ich schon diskutiert, nicht sehen, dass man eine Software zu einem gewünschten umbauen kann oder überhaupt will.

Einfach deswegen, weil es halt nur eine endliche Menge an Dingen gibt, die ich halt tatsächlich ändern möchte.

Und ich glaube, das herauszufinden und zu begrenzen, ist ein wichtiger Punkt.

Also natürlich lässt sich Software prinzipiell zu allem möglichen umbauen.

Klar, sie ist halt soft, aber es ist halt irgendwann so, dass die Aufwände zu hoch sind.

Und das ist so ein bisschen, glaube ich, eine Grundherausforderung.

So, Stefan Rote-Stübs hat geschrieben.

Das hängt davon ab, was in diesem Fall mehr flexibel gemeint ist und erreicht werden soll.

Lass uns kurz noch durch die weiteren Überschriften gehen.

Also ich habe dann Modularisierung in unterschiedlichen Variationen.

Also Stimmtheit, ich will mein System in Module aufteilen und dafür sorgen, dass es dadurch sinnvoll änderbar ist.

Modularisierung und Architekturentscheidungen

Dann gab es so Sachen, die mich halt irgendwie zum Lächeln gebracht haben.

Also da ist gerade so ein lächelnder Emoji.

Also der Stefan Ambruster hat zum Beispiel gesagt, wie die Frage, so die Antwort.

Typ Ernst, klar, also hilft nur leider nichts.

Tamo von Lassen hat geschrieben, das weißt du doch selbst, wie man Software flexibel bekommt.

Schön auch, ### Flexible Datenstrukturen

Roland Weissleder schreibt Map, Object, Object, Data.

Also nicht eine Map, wo ich ein Objekt reinwerfe und ich kriege ein Objekt raus.

Und das sind meine ganzen Daten.

Und das ist ein schönes Beispiel für, ja, das ist eine flexible Datenstruktur.

Das hilft mir nur irgendwie null.

Weil damit kill ich halt einen Typechecker, den ich halt möglicherweise habe.

Und ich kann irgendwie ganz wenig darüber sagen, was da eigentlich drin ist in meinem System.

Das ist ein sehr gutes, einfaches Beispiel für, ich kann sehr flexibel sein, aber es ist dann halt irgendwie auch sehr unsinnig.

Dann gab es die Antwort alles.

Also nicht alle drei Faktoren sind halt wesentlich für eine flexible Software.

Da gibt es verschiedene.

Ich gehe die jetzt nicht durch.

Dann halt diese Priorisierung auf Fachlichkeit, die sich auch bei der LinkedIn-Abstimmung so ergibt.

Da gibt es dann ganz viele Leute, die in die Richtung gehen.

Dann vielleicht noch anderes.

Da gibt es halt von dem Christian Gutrian bei Mastodon die Aussage, schreibe keinen Code, der sich leicht wiederverwenden lässt.

Schreibe einen Code, der sich leicht wegwerfen lässt.

Und Apollo hat geschrieben, oh, das gefällt mir.

Das ist so ein Teil von dieser Microservices-Idee.

Das war etwas, was man da diskutiert hat.

Ich will kleine Microservices haben, die ich leicht wegwerfen kann.

Ich bin mir nicht sicher, wie hilfreich das tatsächlich ist.

Also in gewisser Weise ist das nachvollziehbar, weil sozusagen das Entsorgen von Software, ich will Legacy-Software zum Beispiel loswerden.

Und da ist es vielleicht besser, kleine Teile erstmal wegwerfen zu können.

Aber eigentlich ist das die Abwesenheit und Flexibilität insofern, dass ich eben sage, ich kann das System nicht ändern, sondern ich will Teile davon wegwerfen.

Und ja, keine Ahnung.

Also für mich fühlt sich das so medium-toll an.

Also nicht nachvollziehbar.

Da gibt es auch einen starken Grund, warum man das einführen möchte.

Ich finde es gut, dass die Antwort da ist.

Der Punkt ist halt, ich hätte sie wahrscheinlich nicht gegeben und ich bin mir nicht sicher, ob das halt im Projektalltag wirklich hilft.

So, dann kommt halt von dem RAF Lefer, ich hoffe, dass ich das richtig sage, die Aussage Architektur, nicht der Prozess, dem man folgt.

Oder die Art und Weise, wie die Organisation aufgebaut wird, erzeugt halt eine gute Softwarefabrik.

Sondern es gibt irgendwie diese, also nicht alle drei spielen zusammen.

Und das ist, glaube ich, das, was wir im Training halt auch haben.

Evolution der Architektur

Und dann kommt nochmal Urs und der sagt, ich denke Architektur nicht in fixen Zuständen, sondern in Evolutionsphasen, denn die Architektur wird sich meist entwickeln müssen.

Als Beispiel, unsere Applikation ist mit 100 Benutzern gestartet und wir haben das ökonomische Ziel von 25.000 Benutzer.

So könnten wir mögliche Pfade entwerfen, wie wir die Architektur zu Beginn nicht überdimensionieren und so schnell der Markt sind und uns aber keine Sackgassen einfangen, wenn wir die Architektur weiterentwickeln.

Ich glaube, dass mit den Architekturpfaden stimmt.

Also es wird immer eine Evolution geben.

Also ich werde Architektur immer weiterentwickeln.

Also bei dem konkreten Beispiel bin ich mir nicht sicher, was die Implikation ist.

Ich habe also eine Anwendung mit 100 Benutzern.

Ich nehme mal an, das ist sowas, was ich jetzt auf meinem gut ausgestatteten Laptop, aber es ist halt ein Laptop, irgendwie laufen lassen kann.

Wenn ich 25.000 Benutzer habe, ist das 250 mal mehr.

Da werde ich wahrscheinlich ein ganz anderes System haben.

Es ist sinnvoll, nicht Dinge zu tun, die halt offensichtlich dumm sind.

Das ist eine Tautologie.

Würde halt bedeuten, es ist zum Beispiel sinnvoll, vielleicht einigermaßen zustandslos zu machen, sich damit schon mal rumzuschlagen, wie die Pilotbalance da reinkommt und solche Sachen zu machen.

Aber ich würde auch erwarten, dass ich auf dem Weg von 100 auf 25.000 Benutzer einige Hürden zu nehmen habe, die ich jetzt nicht vorhersehen kann und die ich nicht planen kann.

Und jedes Mal, wenn ich sozusagen eine Hürde oder einen Bollchenek eliminiere, komme ich irgendwie sozusagen einen Schritt weiter.

Und wenn das alles so ist, dann habe ich eigentlich nicht einen Pfad, sondern ich habe halt einfach evolutionäre Weiterentwicklung durch den Druck, also in diesem Fall durch steigende Benutzerinnenzahlen.

Und das ist sozusagen so.

Das heißt, eigentlich muss ich halt die Flexibilität, die sollte halt jeder Reise vorher sein, aber ich kann nicht genau sagen, wo die Bottlenecks sind.

Das kann ich nicht planen.

Also muss ich da irgendwie sozusagen durchlaufen.

Und genau, da kommen dann noch weitere Themen.

Dann noch dieser Hinweis auf Residuality Theory von dem Barry O’Reilly.

Und das ist genau das, wo der Urs wieder einen Hinweis gebracht hat, das ist genau das, wo wir dann am 19. drüber sprechen werden, dann in englischer Sprache.

Das ist übrigens etwas, wo uns die Agile Meets, Quatsch, das war Vertexture Gathering, unterstützt.

Barry hat da einen Vortrag und ich bin sehr gespannt darauf.

Ich hatte mit ihm schon das Vorgespräch.

Das wird, glaube ich, eine ganz spannende Episode.

So, der Urs hat jetzt nochmal live gesagt, es gibt mehrere mögliche Pfade ans Ziel mit jedem Entscheid, verändern sich aber die Optionen.

Genau, was halt impliziert, dass ich es eben nicht planen kann.

Also ich kann mich jetzt nicht hinstellen und kann sagen, wir haben ein System, das halt 100 Leute unterstützt.

Und hier ist halt der Plan, wo ich auf 25.000 komme, sondern ich werde eben das schrittweise weiterentwickeln und dann irgendwie mich entsprechend anpassen.

Gut, soweit dazu.

Es gibt am Freitag, also am 5., mit meinem neuen Kollegen, dem Lukas Domen, der war auch mehrmals im Stream schon, eine neue Episode, zusammen mit Lisa, über das Thema Web-Performance.

Das ist also die nächste reguläre Episode.

Und ansonsten, ja, vielen Dank für die Kommentare, vielen Dank fürs Dasein.

Wir sehen uns dann, wie gesagt, wahrscheinlich am 19. wieder, vielleicht mache ich zwischenzeitlich auch nochmal eine Episode.

Für den 12. wird noch nichts weiter geplant.

Und dann wünsche ich euch noch eine schöne Woche.

Wir haben ja gerade erst den Montag, also kein schönes Wochenende, sondern eine schöne Woche.

Schönes Wochenende dann auch.

Und dann, ja, vielen Dank fürs Zuhören, vielen Dank fürs Diskutieren und bis dahin.

Danke.