Was ist die Hauptherausforderung der Software-Architektur?

Also ich habe dazu natürlich irgendwie Meinung, aber ich dachte es sei irgendwie total spannend mal zu schauen, was halt andere Menschen dazu meinen, weil ich auch irgendwie sozusagen meine Meinung so ein bisschen checken wollte und da ist es jetzt so, dass ich bei Blue Sky Mastodon bei LinkedIn genau diese Frage gestellt habe und halt darum gebeten habe, dass es irgendwelche Antworten gibt und die werden wir uns jetzt irgendwie gemeinsam anschauen und genau dazu werde ich dann lieber zu irgendwas sagen und ihr könnt euch natürlich gerne wie immer im Chat oder eben über software-architektur.tv, also über das Formular, an der Diskussion beteiligen.

Das heißt, ich fange jetzt mal an und teile meinen Bildschirm und ich habe hier als erstes jetzt die Beiträge von Blue Sky gescreenshottet und das ist der erste der Alex Kasabacher von Embark, der sagt, die Hauptherausforderung ist halt ein tiefes Verständnis in der Organisation zu erzielen dafür, dass Architekturorganisationen, Organisationsstrukturen und menschliche Kommunikation miteinander irgendwie was zu tun haben.

So ein bisschen Conway’s Law und ich muss gestehen, ich habe mich erst gefragt, naja, also ist das jetzt wirklich die wichtigste Herausforderung, weil es gibt irgendwie so wahnsinnig viele, aber eigentlich ist das irgendwie nachvollziehbar, weil zum einen ist das nicht offensichtlich, also dieser Zusammenhang ist irgendwie nicht so klar und das andere Problem ist halt, das würde ich jedenfalls behaupten, dass halt unterschiedliche Menschen da diese Dinge in unterschiedliche Richtungen zwingen.

Das heißt also, es gibt irgendwie Menschen, die halt eher Architektur machen, die also irgendwie das in die eine Richtung bringen, dann gibt es irgendwie Menschen, die halt eher Management sind, die das versuchen, in eine andere Richtung zu bringen und eben dort die Organisation beeinflussen, während die ArchitektInnen typischerweise eben versuchen, die Architektur irgendwie zu beeinflussen und wenn nicht Management hat die Organisation beeinflusst und Architektur irgendwie die Architektur und das in unterschiedliche Richtungen, dann gibt es halt irgendwie einen Clash und da das nicht offensichtlich ist und die Auswirkungen dann irgendwie durchaus problematisch sind, finde ich das tatsächlich ein guter Punkt und würde sagen, das ist nachvollziehbar und gut.

Dann haben wir den Simon, der hat geschrieben Kommunikation und dadurch eben ein gemeinsames Verständnis des Problems und der Lösung, die jeder versteht und auf denen jeder sozusagen arbeiten kann, dass das die Hauptherausforderung ist.

Verbindung zu früheren Erkenntnissen

Das passt zum einen ganz gut zu der Episode, die wir gemacht haben vor einiger Zeit, wo wir gefragt haben, was ist eigentlich so der wichtigste Skill?

Das ist halt eine ähnliche Frage, damals auf dem Schrauber Form Stuttgart und da kam irgendwie tatsächlich Kommunikation raus mit einem sehr großen Abstand und das war so ein bisschen so die Richtung, die ich erwartet hatte und wo meine Antwort, ich habe jetzt gar nicht eine konkrete Antwort, über die ich dann auch reinpassen würde, die würde glaube ich auch in diese Richtung gehen und deswegen finde ich, ist das halt nachvollziehbar und so ein bisschen das, was ich halt erwartet hatte.

Dann kommt der Dackel und der hat geschrieben, der oder die, also der Dackel, hat geschrieben, dass die wichtigste Herausforderung ist, Menschen dazu hinzubekommen, dass sie halt verstehen und realisieren, dass wenn ich halt software-definierte Infrastruktur habe, dann halt meine Infrastruktur Software ist und ja, fand ich halt ganz spannend, wäre ich selber irgendwie nicht drauf gekommen.

Wir sind jetzt eben an der Stelle angekommen, wo oder so interpretiere ich das zumindest, wo irgendwie wir keine Server mehr haben, sondern wir haben virtuelle Maschinen, wir haben Cloud, das heißt also alle unsere Infrastruktur ist eben durch Software entwickelt und das bedeutet, dass wir da halt Software als Infrastruktur haben und das führt zu diesem DevOps, ja ein bisschen zu diesem DevOps Thema, dass eben Betrieb eigentlich auch irgendwie Software schreibt und Entwickler in Software schreiben und dass das halt sehr ähnliche Disziplinen sind, sodass halt ein starker Austausch im Sinne von DevOps eigentlich notwendig und sinnvoll ist, das wäre da ein Aspekt und dass eben diese beiden Tätigkeiten dann doch eigentlich sehr ähnlich sind und von daher fand ich das halt irgendwie spannend.

Das war so das, was bei BlueSky passiert ist und wir können uns jetzt mal genau den LinkedIn-Thread angucken, der halt deutlich, deutlich länger ist und wo halt irgendwie viel mehr drinsteht und der fängt halt an mit dem Martin Dilger, der schreibt klare Kommunikation und damit sind wir wieder bei dem Kommunikationsthema, können wir also noch einen Haken machen bei Kommunikation und genau, was ich dazu vielleicht noch ergänzen würde, ist eben, das impliziert halt, was auch so glaube ich gelebte Realität ist von vielen SoftwareentwicklerInnen, dass sie halt, dass man halt durch die Leute, durch die Gegend läuft und die ganze Zeit halt irgendwie kommuniziert und versucht irgendwie nicht Meinungen auszutauschen, Informationen zu bekommen, Entscheidungen zu treffen, Entscheidungen zu kommunizieren, Feedback zu Entscheidungen einzuholen, diese Entscheidung dann irgendwie zu revidieren anhand des Feedbacks und so weiter und so weiter und das ist eben das, was so Softwarearchitektur glaube ich im Wesentlichen ausmacht und ihr muss halt ein bisschen, also vielleicht an der Stelle noch ein kurzer Hinweis, was war nochmal eine Motivation für diese Episode, also wir haben ja jetzt so drei Episoden gemacht oder Ralf hat vor allem da daran gearbeitet, halt Episoden zu machen zum Thema LMS, AI und Softwarearchitektur und ein Grund, weswegen ich eben auch nochmal diese Frage stellen wollte, mit was eigentlich die Hauptherausforderung ist eben, weil ich finde man muss halt die Frage stellen, okay wenn wir also LMS benutzen, hilft uns das eigentlich bei der Hauptherausforderung, wenn man halt sagt Kommunikation ist die Hauptherausforderung, bin ich mir da sehr unsicher und zwar eben deswegen, weil wir ja gesehen haben, dass ich halt mit LMS-Unterstützung sehr schnell ein Architekturdokument erstellen kann, dass ich halt irgendwie damit auch Code erstellen kann, aber das Hauptproblem und da wollte ich halt irgendwie auch noch einen Sanity-Check zu meiner Meinung haben, ist eben Kommunikation und das bedeutet, dass es vielleicht besser ist, das Dokument zu mehr zu schreiben und eben tatsächlich zu schreiben und nicht sich generieren zu lassen, weil dadurch eben Kommunikation unterstützt wird und das war so ein bisschen sozusagen der Punkt.

Dann kam der Alexander von Zitzewitz, den hatten wir auch schon mal im Stream, der baut halt ein Werkzeug zum Architekturmanagement und war so freundlich uns das vorzustellen und schreibt halt dementsprechend, genau so nah drauf ist das Ding, was ist halt des Systems und ich habe jetzt irgendwie einen Kommentar bekommen, der hat, ich muss mal kurz dem nachgehen, Sekunde.

Ne, ignoriere ich glaube ich mal, beziehungsweise ich weiß nicht genau, was da passiert ist.

Ich habe gesehen, Details sind verborgen, aber ich kann mir da drauf ein Reimen machen.

Achso, ah, okay, das ist Windows, der mir sagt, dass Details während des Bildschirmshowns verborgen ist.

Okay, das macht Sinn.

Wartbarkeit und Codequalität

Gut, genau, der Alexander von Zitzewitz und der schreibt halt dementsprechend, dass das größte Problem ist, diesen Big Ball of Mud zu vermeiden, der in vielen Projekten entsteht.

Dafür brauche ich vernünftiges Design, vernünftiges Dependency Management und die Wahrnehmung, dass zyklische Abhängigkeiten, wo also zwei Dinge wechselseitig voneinander abhalten, wirklich schwierig sein können, wenn die eine bestimmte Größe überschreiten.

Also nachvollziehbar, ich komme dann irgendwie in ein Problem, weil das System eben am Ende nicht mehr wartbar ist und eben nicht mehr änderbar ist und ich dann halt irgendwie sozusagen einen Halt im Projekt habe.

Und deswegen haben wir auch ganz viele Episoden gemacht zum Thema Softwarearchitekturmanagement Werkzeuge, weil das eben tatsächlich ein wichtiges Thema ist.

Nicht nur das Werkzeug von dem Alexander, sondern auch verschiedene andere Werkzeuge.

Ich muss gestehen, dass ich diese Fokussierung auf Wartbarkeit, Codequalität und Codestrukturierung immer ein bisschen schwierig finde, weil eigentlich sollte ich mir erst mal überlegen, was die Qualitäten sind, die ich erreichen will und dann sollte ich mir die Lösung überlegen.

Und ich habe manchmal das Gefühl, dass Menschen anfangen und sagen, naja, das System soll irgendwie wartbar sein, deswegen brauchen wir Architekturmanagement und dann haben wir eine gute Architektur.

Die halt sozusagen eine Abkürzung nehmen und nicht die Frage stellen, okay, was ist denn mit Sicherheit, Performance, Skalierbarkeit, Benutzerfreundlichkeit und dann eben wie sehr stark nur fokussieren auf Wartbarkeit und so ein bisschen der Gefahr, die ich da sehen würde.

Aber die Frage war ja nach der größten Herausforderung.

Es war ja nicht die Aussage, dass das die einzige ist und das vielleicht nachvollziehbar.

Dann kommt der, hätte ich gesagt, nicht sicher, wie man es ausspricht, Moises, der hat gesagt, dass man Businessmanagement und TechnikerInnen zu einer gemeinsamen Strategie zusammenbekommen muss, statt dass die halt irgendwie unterschiedliche Strategien haben, die halt miteinander gekonflikt stehen.

Ist vielleicht sowas, was der Alex auch schon sagte, der hat es halt bezogen auf dieses Thema mit der Organisation und der Softwarearchitektur.

Hier ist es ein bisschen breiter, wenn also das Business sagt, wir müssen halt irgendwie einen Markt besetzen und die Softwareentwicklung das aber nicht in der Software abbildet und halt nicht die Software baut, die das halt irgendwie umsetzt, dann habe ich halt ein Problem.

Und er hier schreibt jetzt weiter, dass es darum geht, zum Beispiel Menschen einzustellen, Vertriebsziele, Refactorings, Architekturweiterentwicklung und nur wenn es halt irgendwie eine gemeinsame, klare Strategie gibt, dann kann es halt sozusagen die richtigen Entscheidungen geben.

Und ich habe das, glaube ich, nicht expandiert, deswegen würde ich noch mal kurz schauen, dass ich das nachhole.

Achso genau, und er schreibt dann halt weiter, ist das eigentlich eine Softwarearchitektur-Herausforderung, dass also diese Strategien irgendwie allein sein sollen.

Und er sagt halt weiter, das ist halt nicht notwendigerweise der Fall, aber eigentlich sind halt Softwarearchitekten ein wesentlicher Faktor oder wesentliche Menschen, die einen Beitrag dazu liefern können, dass diese Strategien irgendwie zusammenpassen.

Und ich finde, das ist ein sehr guter Punkt.

Also das passt halt aus meiner Sicht aus verschiedenen Gründen da rein.

Es passt halt einmal für mich, weil ich tatsächlich auch dazu tendiere, auch so in Trainings oder so Menschen zu sagen, es ist halt deine Verantwortung, wenn etwas liegen bleibt, was halt eigentlich für den Erfolg des Projekts notwendig ist, da sozusagen in die Bresche zu springen.

Das ist hier ja, glaube ich, irgendwie auch die Aussage.

Also wenn die Strategien nicht zusammenpassen, dann spring halt irgendwie in die Bresche und mach es halt.

Oder beziehungsweise du bist halt jemand, der da wesentlichen Beitrag leisten kann.

Und ich glaube, der andere Punkt ist halt, man merkt halt an vielen Stellen, nicht nur Design, sagt es ja schon, die Domäne treibt das Design.

Man muss sich eben mit der Domäne, dem Anwendungsbereich halt beschäftigen, kann nur dann erfolgreich sein, was eben bedeutet, dass man halt die Strategien und diese Sachen verstehen muss.

Dann kommt der Vyacheslav Wolf.

Sorry, wenn ich den Namen nicht vernünftig ausspreche.

Der sagt halt, die Konsistenz über die Zeit sicherzustellen, auch wenn die Technologien halt irgendwann veraltet sind.

Und Menschen halt davon zu überzeugen, dass man halt die Architektur kontinuierlich anpassen muss, damit das System skalierbar und wartbar bleibt.

Da sind ja eigentlich zwei Sachen drin.

Also einmal, dass ich halt, also eigentlich sind da sogar drei Sachen drin.

Einmal halt diese Konsistenz.

Ja, wünscht man sich, insbesondere deswegen, weil dadurch Wartbarkeit und Verständlichkeit des Systems und Weiterentwicklung des Systems einfacher wird.

Ich würde behaupten, dass das halt in vielen Fällen, man daran scheitert.

Und ich weiß halt auch nicht, also hier steht ja, dass man die halt sozusagen erhält.

Ich weiß nicht, ob das etwa, also wie soll ich sagen, das impliziert, dass sie halt schon da ist.

Und da bin ich mir halt schon nicht so sicher.

Also ich habe das Gefühl, dass halt viele Systeme eben gerade nicht so eine Konsistenz haben.

Und deswegen, ja, diese Konsistenz und die Intelligität des Systems ist eigentlich ein wichtiges Ziel.

Ich habe das Gefühl, wir scheitern häufig daran.

Ist aber dann, und dann ist es vielleicht eben tatsächlich eine große Herausforderung, weil es eben schwierig ist.

Und zum anderen halt diese kontinuierliche Anpassung, das finde ich halt, ist auch ein sehr guter Punkt.

Ich habe schon an verschiedenen Stellen so ein bisschen diese These ins Feld geführt, dass halt unser Problem nicht ist, dass wir am Anfang nicht genügend über Architektur nachdenken, sondern dass das Problem ist, dass wir eben sozusagen nicht nachjustieren.

Und das ist, glaube ich, das, was hier auch der Fall ist.

Und dann steht da aber, und zwar deswegen, um das System irgendwie wartbar und skalierbar zu halten.

Und da ist wieder diese Geschichte mit nicht von den vielen Qualitätsmerkmalen, die ich halt im Jahr haben kann.

Benutzerfreundlichkeit, Performance, Skalierbarkeit, Wartbarkeit, Sicherheit ziehe ich mir halt irgendwie Skalierbarkeit und Wartbarkeit raus.

Und das weiß ich nicht.

Ich würde mir halt wünschen, dass man halt irgendwie da breiter aufgestellt ist.

Und ich würde sogar behaupten, dass halt in der Realität häufig das Problem ist, dass man halt bestimmte Ziele hat einfach nicht mehr oder bestimmte, wie soll ich sagen, bestimmte Qualitätsziele eben einfach nicht mehr erreichen kann, weil eben Dinge veraltet sind, Technologien veraltet sind.

So, dann kommt der Mariano, der halt schreibt Kommunikation und Politik.

Also diese Gedanken von Menschen und Experten zusammenzubringen oder vielleicht die Expertinnen zusammenzubringen, nicht nur die Gedanken, damit halt jeder die Perspektive von anderen versteht.

So ein bisschen damit das, was wir schon gehört haben, nicht, dass wir verschiedene Rollen zusammenarbeiten müssen.

Und dann steht halt weiter, dass es dann deutlich einfacher wird, was nicht bedeutet einfach, sondern nur einfach her.

Und damit sind wir eigentlich so wieder bei dem Kommunikationsthema.

Menschen müssen halt zusammenarbeiten und das, finde ich, ist nachvollziehbar und macht sehr viel Sinn.

Dann, also nicht weiterer Strich für Kommunikation, wie gesagt, bei dem vom Stuttgart, da hatten wir irgendwie ganz viel, genau diese Kommunikationsgeschichte.

So, dann kommt der Ingo Eichhorst, der ja hier auch bei der letzten Episode dabei war.

Und er sagt halt, die größte Herausforderung sind die limitierenden Faktoren der Organisation.

Wir sind also wieder bei einem Organisationsthema und bei einem Menschenthema.

Und er fragt dann weiter, was ist das, was dich zurückhält, weiteren Fortschritt zu machen.

Das ist also da diese, was er meint mit diesen limitierenden Faktoren.

Und die sollte man halt identifizieren und sich darauf insbesondere fokussieren.

Und er schreibt halt weiter, dass man aus seiner Erfahrung heraus die Komplexität, die Kultur und Kommunikation, drei Ks beziehungsweise in Englisch drei Cs, sind halt meistens involviert.

Was auch wieder bedeutet, nicht ein Kommunikationsthema.

Da ist noch dieser Kulturaspekt, der, glaube ich, da auch ein wichtiger Punkt ist und eben Kommunikation in einer bestimmten Art und Weise beeinflusst.

Und ja, Komplexität, also das ist eigentlich interessant.

Es kommt jetzt, glaube ich, gerade zum ersten Mal vor, wobei man ja eigentlich ja bedenken würde, dass Softwarearchitektur eigentlich eben versucht, Komplexität handhaber zu machen.

Aber nicht.

Also haben wir bis jetzt noch gar nicht so oft gesehen.

Also das war diese großen Systeme bauen, die hat Menschen typischerweise nicht alleine verstehen können.

Und dass das halt die Hauptherausforderung ist, wäre halt etwas, was man sagen könnte, hat hier, also Ingo ist der Erste, der das so ein bisschen andeutet.

Dann kommt der Oliver Fischer.

Der schreibt, der Mangel von Anforderungen von Stakeholdern.

Und das fand ich halt spannend, weil das in gewisser Weise, also ich finde das erstmal nachvollziehbar, weil das ist etwas, was ich an vielen Stellen erlebe.

Also Consulting-Geschichten, wo ich halt im Prinzip sage, naja, ich muss das halt irgendwie versuchen herauszufinden, dadurch, dass ich mit Kundinnen spreche und das baue, was sie halt wollen.

Das ist ja für mich auch Domain-Driven-Design.

So, dann kommt halt irgendwie zurück, ja, aber die reden halt nicht mit uns und die wollen halt auch nicht mit uns reden.

Und das ist insofern paradox, als dass das, was wir tun, ja teuer ist und eine Dienstleistung ist für diese Menschen.

Trotzdem wollen die halt nicht mit uns reden oder uns keine Requirements geben.

Und das ist dann tatsächlich ein Problem, weil dann weiß ich, also nicht, wenn ich Domain-Getrieben vorgehen will oder Qualitäts-Getrieben vorgehen will, dann brauche ich halt die notwendigen Qualitäten beziehungsweise das Wissen über die Domäne.

Das ist etwas, was wir Stakeholder halt geben müssen oder Zugang dazu verschaffen müssen.

Wenn das nicht passiert, dann habe ich halt irgendwie ein Problem.

Und ja, tatsächlich, das ist eben in der Realität ein Problem, aber irgendwie meint er an sich nach ein paradoxes Problem.

Und von daher fand ich das halt, also mich hat es ein bisschen zum Schnurren zu gebracht und ich finde, der Oliver hat da recht und hat einen guten Punkt aufgeworfen.

So, dann kommt der Robin Konrad, der schreibt, die Punkte verbinden zwischen dem Geschäft und der IT, damit halt wirklich unabhängige und selbstorganisierende Teams entstehen.

Und das ist zum einen etwas, was sich halt, also was halt wieder in gewisser Weise auf Kommunikation basiert und halt auf dieses, denke ich, ich muss halt irgendwie wissen, wofür ich das baue und was eigentlich meine Herausforderungen sind, was wir gerade eben auch nochmal diskutiert haben.

Aber jetzt irgendwie nochmal er da sozusagen ein Ziel einbaut und zwar irgendwie sagt, naja, wir wollen halt Software-Architektur erreichen kann, dass Teams im Wesentlichen unabhängig sind, weil eben Änderungen, die halt ein Team macht, andere Sachen nicht beeinflussen.

Und das ist halt, würde ich sagen, nachvollziehbar und zeigt nochmal eben diesen Zusammenhang, der da irgendwie existiert.

Gut, dann kommt die Lea, die hat gesagt, ich bin keine Software-Architektin und will nur meine Perspektive als Frontend-Entwicklerin hinzufügen.

Ich glaube, der wichtigste und schwierigste Teil ist, Menschen davon zu, also Menschen zu überzeugen und zu kommunizieren mit allen Stakeholdern und allen Teammitgliedern.

Und das finde ich ist erstmal ein sehr guter Punkt.

Und dann steht da halt im Weiteren, insbesondere diese nicht-funktionalen Requirements irgendwie rauszufinden.

Und das finde ich halt auch ist total nachvollziehbar.

Nicht-funktionale Requirements sind eben ein wichtiger Architektur-Treiber.

Und da muss ich nochmal sehen, was sie weitergeschrieben hat.

Also zum Beispiel Robustheit.

Also haben wir mal ein anderes Qualitätsziel, nämlich Robustheit, nicht nur Wartbarkeit und Skalierbarkeit.

Und die halt so früh wie möglich im Prozess zu betrachten, finde ich ein guter Punkt, damit man halt weiß, wo man hin will.

Und Quality Assurance, also QA mit zu integrieren, Teststrategien festzulegen, mit Clients zu kommunizieren, wenn die sagen, wir brauchen keine Tests.

Das ist auch wieder eine interessante Sache, dass halt genau diese Geschichte, die wir vorhin schon hatten, man könnte sich ja zumindest sagen, ich bin halt Software-Architekt oder in dem Fall Front-End Entwickler.

Und ich möchte mich ja nicht darum kümmern, weil das ist ein anderes Thema.

Aber hier ist der Hinweis, dass das wichtig ist und dann muss ich mich vielleicht kümmern.

Und dann kommt halt Benutz-, also Usability-Tests oder Accessibility-Tests, also Tests in Bezug auf Barrierefreiheit und Benutzbarkeit, auch so früh wie möglich reinzubekommen, finde ich auch einen wichtigen Punkt.

Ich glaube, dass Benutzbarkeit tatsächlich etwas ist, was an vielen Stellen den Erfolg von irgendwelchen Systemen determiniert und zwar ganz stark determiniert.

Und sie schreibt halt weiter, es gibt einen Overlap zwischen Front-End-UX-Accessibility und Software-Architektur.

Genau.

Und ich hatte vor längerer Zeit schon diese Episode mit Aminata gemacht, genau irgendwie zu diesem Thema mit UX.

Und das ist ein bisschen mein Ergebnis auch oder das, was ich gelernt habe, ist, dass eben tatsächlich diese Bereiche schon ähnlich sind, weil ich will halt Dinge strukturieren.

Und sie schreibt dann weiter, dass das halt häufig outgesourced wird an irgendwelche externen, also UX-Menschen und dann halt anschließend als Wasserfall gemacht wird.

Ja, und das ist natürlich irgendwie ein Problem, sollte man irgendwie reinbekommen.

Jetzt ist da ein Kommentar von dem Michael.

Mal sehen, was der geschrieben hat.

Der schreibt, wenn man halt Requirements anfordert, dann sind halt Clients dazu gezwungen, eine Präzision anzubieten, die halt erstmal sozusagen zurückweisen.

Also sie müssen halt irgendwie was entscheiden und müssen halt sagen, das sind halt die Requirements.

Und das bedeutet, sie müssen halt Entscheidungen treffen und das ist halt irgendwie ein Problem.

Und dass man das ja nicht vollständig spezifizieren kann.

Und das bedeutet, dass alle Stakeholder glauben, dass halt so ein Big Design Upfront, also wo ich am Anfang all dieses Design mache, irgendwie Aufwand erzeugen in eine Richtung, die ja nicht wirklich hilfreich ist.

Das finde ich interessant, weil das würde bedeuten, dass halt Big Design Upfront abgeschafft wird.

Sehe ich nicht.

Also ich habe eher das Gefühl, gegenteilige Gefühl, dass da halt an vielen Stellen Sicherheit sozusagen erzeugt wird oder versucht wird zu erzeugen.

Ich hatte vor kurzem auch diese Episode mit der Illusion der Kontrolle.

Wenn ich also am Anfang mehr intensiv Gedanken mache und das funktioniert halt alles und ich denke halt wirklich intensiv nach, dann habe ich ja intensiv nachgedacht und dann wird es halt irgendwie funktionieren.

Dass Menschen halt diese Entscheidungen nicht treffen wollen, das finde ich total nachvollziehbar und ist auch ein sehr guter Punkt.

Bin nicht sicher, wie man damit umgehen will und damit sind wir wieder bei diesem Thema nicht, Requirements bekommen, den Oliver vorhin meinte.

So, was hat Konrad geschrieben?

Konrad hat geschrieben, seiner Meinung nach ist die größte Herausforderung, jede Implementierung eines Requirements zu Reviewen nach architekturellen Fragen und wenn nötig, die Zeit zu investieren in die architekturelle Analyse, weil es zu viele Beispiele gibt von Systemen, die halt ohne so etwas funktioniert haben.

Wie soll ich sagen, wenn ich halt das Gefühl habe oder wenn ich halt ohne diese Aufwände auskomme, dann sollte ich es halt nicht tun und ich bin halt der sehr festen Überzeugung, dass Softwarearchitektur eigentlich ein Mittel zum Zweck ist.

Das ist halt ein Werkzeug, das muss Ergebnisse produzieren.

Das heißt, ich muss irgendwie bessere Software erzeugen für irgendeine Definition von besser, sonst sollte ich es halt nicht machen.

Von daher finde ich das ein bisschen schwierig, weil die Aussage ist ja im Prinzip, ich habe Beispiele dafür, dass es ohne funktioniert, aber ich würde es trotzdem machen und ich würde behaupten, diese Beispiele, dass es halt ohne funktioniert, sind halt in gewisser Weise überraschend und ich sehe in der Realität, ich bin nun aber auch Berater, eher solche Geschichten, wo Systeme genau aus den Gründen in der Situation sind, wo man erheblich investieren muss, damit sie halt wieder wartbar, sicher, skalierbar, was auch immer halt irgendwie sind.

Und das ist, glaube ich, so ein bisschen der Hinweis und das ist auch für mich ein fundamentales Thema.

Also das wäre vielleicht eine der Herausforderungen, diesen Widerspruch halt irgendwie aufzulösen.

Ich habe das Gefühl, dass halt häufig Entwickler sagen, hey, wir müssen halt irgendwie mehr Qualität liefern und Management sagt halt, hey, wir sollen halt irgendwie schnell Features liefern, bis es dann irgendwann umspringt und halt Management sagt, hey, wir können ja keine Features mehr liefern, weil das System ist halt irgendwie vergurkt und Entwickler sagen, ja, schade eigentlich.

Also diese Konfrontation, die hat am Anfang scheinbar existiert mit, ich will Features, ich will eine saubere Architektur, wo eben Management sagt, ich will Features, schlägt an der Stelle um, wo es eben keine Features mehr gibt, weil die Architektur so vergurkt ist und dann bedeutet es aber, dass der Schlüssel dazu ist, eine Argumentation aufzubauen.

Die hat gesagt, wenn ihr jetzt da rein investiert, dann werdet ihr später eben auch dazu in der Lage sein, Features hinzubekommen.

So, dann haben wir die Katharina Schwarz, die richtige Information zur richtigen Zeit zu bekommen.

Auch wieder ein Kommunikationsthema, finde ich halt, ist sehr schön auf den Punkt gebracht da.

Christian Ibendorf hat geschrieben, herausfinden, welche Person mir sagen kann, warum irgendeine Entscheidung so getroffen worden ist, weil die möglicherweise nicht mehr in der Organisation sind und oft sind die Sachen halt irgendwie nicht aufgeschrieben.

Das finde ich interessant, weil das bedeutet halt, dass sozusagen ein Kommunikationsproblem, nämlich ich kriege nicht heraus, warum eine bestimmte Sache entschieden worden ist.

Das ist ja eigentlich ein Kommunikationsproblem.

Irgendjemand kommuniziert mir das nicht.

Das wird ein Menschenproblem, also ein Menschen zu identifizieren.

Ich finde es auch deswegen interessant, weil ich da beobachte, dass häufig dann ein Fokus gelegt wird auf eine Problemlösungsseite, die halt sagt, naja, dann schreiben wir halt mehr auf.

Ich bin halt sehr unsicher, ob das halt hilft.

Und hier ist halt die Aussage, ich will lieber diese direkte Kommunikation mit einer Person.

Also da steht ja nicht, ich möchte halt irgendwie, dass mehr Dokumentation geschrieben wird.

Michael Meyerhoff hat aufgeschrieben, das schwierigste Problem ist halt, die richtigen Entscheidungen auf Basis der richtigen Daten zu treffen.

Ja, guter Punkt.

Und schreibt dann halt weiter, dass halt die Entscheidungen oft durch politische und persönliche Sichten beeinflusst werden.

Ja, ich würde vielleicht noch hinzufügen, also sozusagen, das ist halt so.

Das Problem ist halt, wir müssen Entscheidungen treffen.

Wir haben nicht den Luxus, uns die richtigen Informationen zusammenzusammeln, weil das halt aufwendig ist.

Und dann läuft man halt in so eine Richtung.

Und das andere ist tatsächlich, dass eben diese Entscheidungen, das ist, glaube ich, ein extrem guter Punkt, nicht rein rational sind, sondern die sind ein Ergebnis der Organisation mit ihren Schwächen und Problemen, die halt da sind.

Dann kommt der Stefan Sonnenberg-Karstens, der geschrieben hat, dass man mit Lamans Gesetz von organisatorischem Verhalten oder über das Verhalten von Organisationen umgehen können.

Und da ist halt die Aussage, dass halt Lösungen oft die organisatorischen Strukturen nicht berühren dürfen, was halt wiederum dann dazu führt, dass halt der Lösungsraum eingeschränkt ist.

Ich also Aussage, lasst halt den Prozess so, wie er ist, aber macht es halt irgendwie schneller, besser oder dünner, also irgendwie leaner.

Also fand ich interessant, führt irgendwie wieder zu dieser Diskussion, die halt irgendwie da ganz viel ist, nicht?

Das hat Organisation und Softwarearchitektur zusammenhängt.

Und ich muss gestehen, bei mir hat das ausgelöst, dass es eigentlich so zwei Ebenen gibt.

Also es gibt einmal die Ebene von die Software, die wir halt bauen, soll eben die Prozesse unterstützen, die da sind, aber sie nicht ändern, was so ein bisschen unmöglich ist, nicht?

Weil dadurch, dass ich Software einführe, ändert sich ja der Prozess sozusagen automatisch.

Und das andere ist, glaube ich, die Softwareentwicklung an sich, nicht?

Also mache die Softwareentwicklung schneller, produziere bessere Software, aber der Prozess darf sich nicht ändern, nicht?

Also einmal der Prozess, den wir in Software implementieren und dann der Prozess, mit dem wir Software implementieren, Scrum oder sowas.

Da sind also diese beiden, also ich könnte mir sozusagen vorstellen, dass es für beide Ebenen gilt.

Evolutionäre Entwicklung

Janis hat geschrieben, dass für ihn der schwierigste Teil dieses Problem ist, dass Softwaresysteme dadurch einfach wachsen.

Dinge werden halt hinzugefügt, eingehackt und irgendwie reingepatcht.

Und wenn ich ein System habe, was ein bisschen Begröße hat, dann bricht das bei einer größeren Größe.

Und die Herausforderung ist halt, das System wachsen zu lassen, ohne dass das Chaos mitwächst.

Ich würde es ein bisschen reduzieren.

Ich würde halt sagen, oder etwas anders sagen, wenn ich sagen sollte.

Ich würde halt sagen, dass halt das Chaos nicht überhand nehmen darf.

Also wir müssen irgendwie dafür sorgen.

Erstmal würde ich behaupten, wir haben keine Chance.

Umgang mit Veränderung

Wir müssen Systeme evolutionär weiterentwickeln.

Und das ist etwas, was durch agile Softwareentwicklung, Iteration gegeben ist.

Wenn man sich von der Professor Christiane Fleute Episode anguckt, die hat eben gesagt, dass das in den 60ern schon klar ist.

Ich habe mit Hillel diese Episode gemacht darüber, weil wir nicht Engineers sind.

Die reden halt auch darüber, dass wir halt irgendwie iterativ arbeiten müssen.

Und das führt, glaube ich, automatisch dazu, dass wir dann irgendetwas haben, etwas einfügen.

Und wir können gar nicht das sozusagen völlig konstant so halten, sauber halten, weil das halt einfach zu aufwendig wäre.

Meine These zumindest.

Also Softwarearchitektur ist ja nur ein Mittel zum Zweck.

Das heißt, an einer bestimmten Stelle ist es eben vielleicht nicht mehr wirtschaftlich machbar oder auch nicht wirtschaftlich sinnvoll, das System noch sauberer zu machen.

Und dann komme ich halt in diese Situation.

Und das ist ein bisschen eben das Kreuz mit evolutionärer Softwareentwicklung.

Ich weiß nicht, ob ihr diese Jenga-Towers kennt, wo man halt so drei kleine Holzstücke und da sind dann irgendwie wieder drei Holzstücke drüber, um 90 Grad gedreht.

Also ich weiß ja nicht, die sind vielleicht so groß wie ein Finger oder so.

Dann zieht man halt eins von den Holzstückchen raus und legt das halt oben rauf.

Und was dadurch entsteht, ist halt ein höherer Turm, bis er irgendwie zusammenbricht.

Und das ist halt in gewisser Weise das evolutionäre Bauen eines Turms.

Und dabei kommt etwas raus, was man so nicht planen würde.

Wenn ich jetzt den höchsten Turm bauen wollen würde, dann würde ich ein Holzstück unten hinlegen, das nächste Holzstück drauflegen und so weiter.

Und dann habe ich eben nur ein Holzstück pro Stockwerk.

Das wird halt den höchsten Turm ergeben.

Wenn ich es evolutionär entwickle, werde ich irgendwas anderes haben.

Und das ist eigentlich so ein bisschen das Spielchen, was wir spielen.

Das werden wir mit Software weiterentwickeln.

Und dadurch kann ich den Endzustand des Jenga-Turms irgendwie sozusagen vorher planen.

Sondern da muss ich mich irgendwie dann entsprechend anpassen.

Und da ist vielleicht noch ein weiterer Hinweis.

Also das ist doch ein lustiges Ergebnis dieser Analogie.

Der Jenga ist dann zu Ende, wenn der Turm irgendwie zusammenbricht.

Das bedeutet nicht, die Architektur ist dann zu Ende, wenn man halt in dieser Metapher bleiben möchte, wenn das System zusammenbricht.

So, was hat der Michael geschrieben?

Architekturarbeit bedeutet, üblicherweise abstrakt, und bedeutet, dass man eine entsprechende Erfahrung haben muss.

Das bedeutet, dass Architekten anders denken als EntwicklerInnen oder andere Stakeholder, die eher konkret in spezifischen Beispielen denken und an irgendwelchen Ausnahmen hängen bleiben.

Während Architekten Trade-offs machen und Dinge generalisieren und die Zukunft im Blick haben.

Ja, das hat was für sich.

Ich bin nicht sicher, ob ich das unterschreiben würde, weil ich unterstellen würde, dass auch EntwicklerInnen Trade-offs machen, die Zukunft im Blick haben und auch Generalisierungen machen.

Ich würde zustimmen, deutlich zustimmen, dass EntwicklerInnen und ArchitektInnen unterschiedliche Ebenen haben.

Strukturierung versus Arbeit in kleineren Bereichen.

Ich finde es immer so wahnsinnig schwierig, das irgendwie klar zu trennen.

Ich glaube, dass das auch nicht wirklich möglich ist.

Ich habe diesen Talk von wegen, Softwarearchitektur muss das eigentlich sein, und da gab es auch eine Episode dazu.

Eigentlich ist meine Aussage, wenn sich irgendjemand hinsetzt und ein System baut, gibt es Architekturentscheidungen.

Ich strukturiere das System.

Ich muss Qualitätsziele, Wartbarkeit, Sicherheit oder so einhalten.

Da hat ein EntwicklerInnen und andere Menschen einen starken Einfluss und treffen Entscheidungen, die in diese Richtung gehen.

Er würde sagen, dass die Grenzen sehr fließend sind.

Ich glaube nicht, dass es Sinn macht zu sagen, es gibt die ArchitektInnen, sondern ich glaube, dass es fließende Grenzen gibt zwischen ArchitektInnen und EntwicklerInnen.

André, was hat der geschrieben?

Die Architektur wählen, die wirklich notwendig ist für meinen Kontext, statt eine Architektur zu wählen, die irgendwie hip oder toll ist.

Meiner Meinung nach ist das das, was passiert ist, als das mit dem Microservices passiert ist.

Ja, guter Punkt.

Wir sind sehr stark durch Modeströmungen beeinflusst.

Microservices ist so eine Modeströmung.

Ich habe mehrere Bücher darüber geschrieben.

Es ist dem so, dass es tatsächlich Probleme löst.

Es wird überbenutzt, ist glaube ich der Punkt.

Aber das kommt hier ja auch raus.

Die Aussage ist ja, dass ich die Architektur wählen sollte, die für mein Problem tatsächlich relevant ist.

Und das ist dann vielleicht nicht eine Microservices-Architektur.

Und es gibt eben tatsächlich häufig dieses Problem, dass gesagt wird, naja, wir machen es mit Microservices, weil das macht man ja so.

Und im Extremfall fehlt halt eine Begründung und dann geht es halt tatsächlich schief.

Fabian hat geschrieben, Menschen davon überzeugen, also meistens das Management, dass sie halt entsprechend den Requirements, den Zielen und den Strategien, die sie selbst halt eingeführt haben, dass sie dementsprechend handeln sollen.

Auch wieder diese Geschichte mit das Management und anderen Rollen, die wir da irgendwie beeinflussen müssen.

Das ist ein guter Punkt, passt glaube ich auch irgendwie zu dem, was Oliver schrieb, von wegen nicht, also dass es halt irgendwie keine Requirements gibt.

Eigentlich sollte das ja nicht so sein.

Eigentlich sollte es halt so sein, dass wir sagen, wir sind halt ein Werkzeug.

Architekten und Softwareentwicklung insgesamt, die müssen uns schon sagen, was die Ziele sind.

Hier ist halt die Aussage, nee, das ist halt irgendwie nicht konsistent und wir müssen irgendwie Feedback geben.

Ich sehe das genauso.

Wir müssen halt Feedback geben.

Das ist halt bedauerlicherweise die Welt, in der wir leben und von daher finde ich das halt gut.

Dann kommt der Barry O’Reilly, der ja auch einen Namen hat in der Software-Architektur-Szene und der hat halt gesagt, Architektur ist immer noch in der vorwissenschaftlichen Phase und niemand kann den Unterschied benennen zwischen dem, was halt Mythen sind, was halt Aberglaube ist und dem, was halt real ist.

Und ich muss gestehen, also nicht, es gibt Gründe, warum er das schreibt und das ist irgendwie auch nachvollziehbar.

Ich muss gestehen, dass ich aus bestimmten Gründen dem entschieden widersprechen wollen würde und zwar deswegen, weil ich das häufig in Diskussionen so etwas oder etwas ähnliches als eine Ausrede wahrnehme.

Also warum haben wir jetzt so komische Systeme?

Warum funktioniert das nicht mit den Systemen?

Warum können wir die nicht vernünftig machen?

Ich und bestimmte Dinge, mit denen ich auch rumlaufe, die wir auch im Stream diskutiert haben.

Module beispielsweise sind halt irgendwie auch etwas älter als ich.

Und ich habe dann halt schon die Erwartungshaltung, dass halt irgendwie diese Geschichte mit den Modulen und wie ich halt Software aufteile, was Schnittstellen sind, was Information Hiding ist und so weiter, dass das halt hätte sich durchgesetzt haben können.

Hat es sich aber noch nicht.

Es ist eben nicht so, dass alle Menschen das halt sozusagen verstanden haben, die in unserer Branche halt arbeiten.

Vorhin haben wir auch diskutiert, es gibt ja auch viele weitere Sachen.

Diese Geschichte aus dem Mr. K.

Maymonth aus den 70ern, 1975 ist glaube ich das Buch rausgekommen, wo halt irgendwie drinsteht, wenn ich einen Menschen in ein Projekt reinstecke, was halt irgendwie zu spät ist, dann wird das Projekt irgendwie sich noch weiter verzögern.

Das ist auch etwas, gegen das halt gehandelt wird, aber nicht deswegen, weil wir es nicht wissen als Community, sondern weil es sich irgendwie noch nicht durchgesprochen hat.

Das heißt, ich würde halt, ich hänge mich halt auf an diesem, niemand kann den Unterschied benennen.

Können wir schon.

Es ist nur irgendwie so, dass die Mehrheit der Menschen es nicht benennen kann oder diese Konzepte nicht kennt.

Das ist aber ein Bildungsproblem.

Das ist kein Problem, dass wir es nicht wissen können, prinzipiell.

Wir wissen es.

Es ist eher ein Problem von, wir handeln halt nicht dementsprechend und das Wissen ist halt nicht allgemein verfügbar.

So und das ist halt ein bisschen das, was ich meine, nicht?

Also ich sehe da halt eine Gefahr, dass man halt sagt, wir können es ja nicht besser wissen, weil das halt dann eine Ausrede dazu sein kann, dass man ja irgendwie sagt, ich muss es deswegen ja auch nicht nachrecherchieren und mich nicht damit beschäftigen und es nicht lernen, weil wir können es ja nicht wissen, ist halt so.

So und das finde ich halt irgendwie an der Stelle schwierig.

Dann kommt Raphael Freitas, der schreibt, Menschen davon zu überzeugen, dass sie halt irgendwie Zeit mit Architektur verbringen sollen.

Ja, guter Punkt.

Dann kommt Jan Zernisch, der schreibt Domainmodellierung.

Und da kommt irgendwie von dem Weiteren noch die Aussage, das größte und am stärksten unterschätzte, dass Domainmodellierung halt irgendwie so wichtig ist.

Ich würde auch, also Domainmodellierung als schwieriges Problem anzusehen, finde ich, ist nachvollziehbar und das ist ein sehr guter Punkt.

Gleichzeitig ist es so, dass wir einen DDD-Hype haben, sodass das Thema Schwung, glaube ich, als ein wichtiges Thema identifiziert ist.

Der Christian Beutemüller hat gerade geschrieben, ich denke, unsere Branche vergisst zu schnell, jede Generation erfindet das Rad neu.

Bin ich mir nicht sicher, haben wir halt mehrfach Modellisierung wieder erfunden, haben wir mehrfach Eventstorming und die Techniken rund um kollaborative Modellierung neu erfunden, haben wir mehrfach herausgefunden, dass halt Menschen, die wir in ein Projekt stecken, dass die halt irgendwie das Projekt verlangsamen, weiß ich nicht.

Also dann schreibt halt der Uli, aber warum?

Es sind durch jede Menge dauernde Herausforderungen beschrieben worden.

Ja, ich halte das für ein Ausbildungsproblem und ich habe gestern mit einem Kollegen gesprochen und möglicherweise ist das Ausbildungsproblem nicht auf unsere Branche beschränkt, was ein bisschen schade ist.

Christian schreibt weiter, bestes aktuelles Beispiel, i.e.

AI-Agenten-Frameworks entdecken gerade alle Kommunikationspatterns neu.

Ja, okay.

Ich würde nicht in Abrede stellen, dass das so ist, dass Dinge mehrfach neu erfunden werden, aber ich halte das nicht für das Hauptproblem.

Ich halte das für das Hauptproblem, dass wir einfach Dinge nicht wissen.

Also was ist ein Modul, wie funktioniert das, wie kriegen wir Software vernünftig strukturiert, das sind ja fundamentale Fragen.

Ich bin mittlerweile auch gar nicht sicher, wo Menschen das lernen sollten und dann haben wir halt keine Leute, die das können.

Wenig überraschend.

Das ist tatsächlich ein breiteres Thema.

Ich werde halt im Betriebswirtschaftslehre beispielsweise nicht lernen, wie ich Menschen anleite und führe.

Trotzdem sind Betriebswirtschaftler oft in genau so einer Situation und das ist wieder dasselbe Thema.

Ich habe einen Manager vor mir, der kann mit Menschen nicht umgehen. Überraschung, er hat Betriebswirtschaftslehre studiert.

Woher soll die Person das wissen?

Der Michael hat geschrieben, Barry O’Reilly vertritt die Auffassung, dass unser Bereich nicht genügend wissenschaftlich erforscht ist und deshalb setzen nachfolgende Generationen nicht auf Ergebnisse von Vorjährigen zurück.

Sorry, aber nee, ist halt nicht so.

Wir haben auch eine Episode gemacht zum Thema empirische Softwareentwicklung.

Es gibt Informatik als Disziplin und gerade das, was wir hier diskutieren, ist, dass Softwareentwicklung sehr stark von Organisation, Kommunikation und so weiter abhängt, was ja auch das ist, womit ich sozusagen reingekommen bin.

Interdisziplinäre Aspekte

Und wie Menschen kommunizieren und wie Organisationen funktionieren, das ist nun wirklich, wirklich, wirklich, wirklich erforscht.

Da gibt es noch nicht Soziologie und Psychologie, Pädagogik, also tonnenweise, wirklich tonnenweise Forschung darüber.

Wir kennen sie nur nicht.

Und das ist genau der Punkt, wir kennen sie halt nicht.

Und deswegen halte ich halt diese Ansicht tatsächlich für gefährlich, weil sie hat genau dieses Tor eröffnet mit, wir können es ja nicht wissen.

Nee, setzt euch irgendwie hin, versucht es halt herauszufinden, schaut halt nach, es gibt genügend Publikationen, zieht eure Schlüsse da draus.

Und wenn ich halt irgendwie ein Abrede stelle, dass es halt diese Dinge gibt, diese Fundamente gibt, dann verleite ich Leute dazu, genau das nicht zu tun.

Und das finde ich gefährlich, weil dann sorgen wir dafür, dass eben das Wissen, was wir haben und das haben wir, eben nicht weiter getragen wird.

Gut, Andrea hat noch geschrieben, mit Architekten umgehen sei das größte Problem.

Ja, also guter Punkt.

Und dann kommt noch Thorsten mit Menschen und Kommunikation.

Dann können wir, glaube ich, übergehen.

Genau, Christian schreibt, wir haben schon einen Hang dazu, viele unserer eigenen Forschungen auch zu ignorieren.

Wer hat wissenschaftliche Papers für Software-Engineering gelesen?

Genau, so, das heißt also, les Paper über Software-Engineering.

Und dazu muss ich jetzt aber erst mal realisieren, dass es das gibt und dass es Wissenschaft gibt.

Ist ja genau mein Punkt.

Wenn ich also sage, die gibt es aber gar nicht, diese Wissenschaft, dann sage ich halt, Paper kann ich nie lesen, gibt es ja nicht.

Das halte ich halt echt für schwierig.

Aber nicht, keine Ahnung, vielleicht habe ich ihn halt auch missverstanden.

So, dann gibt es noch den Mastodon-Threat.

Ich befürchte, oder ich vermute, dass wir den nicht ganz durchbekommen.

Erster ist halt Thane Piper, der oder die sagt, Menschen sind das Problem.

Dann kommt Peter Götz, der hat gesagt, dem würde ich zustimmen.

Und dass halt irgendwie diese unterschiedlichen Strategien da sind oder Ideen da sind, was das Produkt machen kann und wie ich es umsetzen kann.

Da würde ich sagen, ist irgendwie auch noch vorziehbar.

Dann hat da Sebastian Hans weitergeschrieben, ja, es sind irgendwie Menschen.

Und irgendwie, dass Menschen nicht herausgefordert werden wollen.

Und wenn ich jetzt anfange, eine Architektur zu bauen, dann sind da ganz viele Entscheidungen drin.

Und wenn ich halt irgendwie eine Entscheidung treffe, dann ist es halt der Tod vieler weiterer Optionen.

Und Menschen werden halt nicht 100 Prozent mit Entscheidungen übereinstimmen, sind vielleicht irgendwie persönlich, hängen sich halt in irgendwelchen Entscheidungen.

Das bedeutet, wenn jetzt jemand sagt, wir sollten was anderes machen, dann sind irgendwie die Leute, die die Entscheidung vorher getroffen haben, dass wenn jetzt jemand Änderungen an der Software vorschlägt, dann sind die Leute, die die Entscheidung vorher getroffen haben, die haben dann halt vielleicht ein Problem, weil sie sich halt persönlich da angegriffen führen.

Und das hängt vielleicht auch damit zusammen, dass eine Architektur etwas ist, was halt fertig ist, was halt nicht geändert werden soll.

Aber warum auch immer nicht.

Es geht darum, Menschen zuzuhören, sie halt zu überzeugen.

Es geht um Egos, Diplomatie und so weiter.

Und das ist etwas, worauf Menschen schlecht vorbereitet sind.

Und das würde ich auch so sehen.

Da sind viele gute Aspekte drin.

Ich finde dieser persönliche Aspekt, dass Architektur sozusagen mein Baby ist und dass ich mich dann angegriffen führe, wenn da ein Thema ist, das finde ich total nachvollziehbar.

Und nicht diese Beziehung zwischen Architekt und Menschen, da finde ich, ist das ein schönes Schlaglicht.

So, jetzt lassen wir uns mal schauen, was da drin steht in den Kommentaren.

Also Ulli hat geschrieben, aber das ist doch schon die Grundlage der CPSAF-Zertifizierung, also von dem, was der ISAQB macht.

Beziehungsweise Gernot Starke schreibt es ja auch in effektive Softwarearchitektur.

Und der erste Schritt muss sein, daraus zu finden, wie andere das Problem gelöst haben.

Ja, genau.

Nur das passiert halt nicht.

Und Gernot hat gesagt, also wenn es selbstverständlich wäre, müsste Gernot das nicht aufschreiben.

Und ich meine, der Stream hat auch ganz viele Beispiele für eben genau solche Sachen, wo es halt um Grundlagen geht.

Es geht ja auch um wissenschaftliche Sachen.

Wir haben eine Episode über das Thema empirische Softwareentwicklung mit dem Hilary Wayne und dem Laurent Bossavi.

Also natürlich gibt es da Wissenschaft und das ist halt bedauerlicherweise unterbelichtet so ein bisschen.

Christian schrieb, wenn Menschen das Problem sind, solltest du dich dringend mit Organisationssoziologie und Arbeitspsychologie auseinandersetzen.

Genau.

Das ist so ein bisschen das, was ich halt versuche zu sagen.

Und auch da ist es ja so, dass wir halt Episoden in diese Richtung gemacht haben.

Also wir hatten den Gerrit, der Soziologie studiert im Stream.

Und wir hatten auch die Melanie Schäfer, die ja tatsächlich im Bereich Arbeitspädagogik aktiv ist, weil ich genau diese Sachen halt wichtig halte.

Also und tatsächlich ist das einer der Punkte.

Ich glaube halt, dass es Informatikern gut tun wird oder Softwarearchitekten.

Softwarearchitekten ist eigentlich der Punkt, wenn sie halt in diesem Bereich irgendwie sich orientieren.

Christian schrieb dann weiter, Fertigarchitekturen gibt es nicht.

Das passt gut zu dem, was der Sebastian gerade gesagt hat.

Ich glaube, das, was er versucht hat zu sagen ist, die Menschen hätten halt gerne eine Fertigarchitektur wenn es ihre ist, mit ihren tollen Ideen und hängen dann da dran.

Nur die Realität sagt eben, dass ich es iterativ verbessern muss.

Und das ist glaube ich, was ich Christian nochmal sagen soll.

Und Christian schreibt noch, wir schreiben so viel für Menschen.

Exakt.

Und das ist vielleicht auch, also wir sind so ein bisschen am Ende, nähern uns ja dem Ende der Zeit heute.

Und das wäre jetzt sozusagen ein gutes Endwort.

Ich glaube, ich mache trotzdem noch ein paar Sachen weiter.

Das ist eigentlich das, worauf es hinausläuft.

Also es geht eben nicht darum, dass wir ein Software-Business haben, ein technisches Business, sondern es geht darum, dass wir irgendwie Software für Menschen bauen.

Und das bedeutet, dass wir die verstehen müssen.

Verstehen müssen, was die eigentlich wollen.

Dass halt irgendwie mit denen kommunizieren müssen.

Und ich würde vielleicht noch hinzufügen, dass wir Software mit Menschen für Menschen schreiben.

Weil dieser Aspekt, dass irgendwie da das Team ist und dass halt in dem Team verschiedene Menschen zusammenarbeiten, ist ja irgendwie der andere Aspekt.

Und damit reden wir tatsächlich über im Wesentlichen eine soziologische Geschichte.

Und da nochmal der Hinweis.

Also ich habe halt, in meiner Erinnerung ist es so, dass ich halt mal auf dem Panel gesessen habe und da hat halt jemand gesagt, naja, so ein Team von Menschen, das kann ich ja gar nicht vernünftig untersuchen.

Das ist kein, nichts was halt wissenschaftlich irgendwie eruierbar ist.

So erinnere ich es.

Es kann auch was in diese Richtung gewesen sein.

Ich habe irgendwie da gesessen und habe mir gedacht, du sprichst gerade, du sagst halt gerade, dass es keine Soziologie gibt.

Und das ist halt irgendwie weird.

Nur weil wir halt als Informatikerinnen glauben, dass halt ein technisch stark deterministisches Weltbild halt irgendwie das ist und dass halt Menschen irgendwie so ein bisschen nicht deterministisch sind, sollte uns nicht davon abhalten zu realisieren, dass es da ja irgendwie wissenschaftliche Grundlagen gibt und dass man da durchaus auch systematisch vorgehen kann.

Also es muss ja vielleicht gar nicht wissenschaftlich sein, es sollte dann irgendwie systematisch sein.

Und der andere Punkt ist halt, also Computer sind ja offiziell deterministisch.

In Wirklichkeit zweifeln wir glaube ich häufig genug daran.

So, genau, Tane Piper hat noch geschrieben.

Ah ja, genau, das war gut, dass wir das noch diskutieren.

Also er geht halt darauf ein, dass die Side, also Entscheiden, denselben Wortstamm hat wie Homicide, also jemanden umbringen.

Und was bedeutet das?

Eine Entscheidung bedeutet, dass ich viele Optionen töte.

Ich habe jetzt nicht nachgeschaut, ob das tatsächlich stimmt, dass die beiden Worte halt irgendwie etymologisch zusammengehören.

Aber das ist halt glaube ich wirklich ein wichtiger Punkt.

Wenn ich etwas entscheide, dann bedeutet es halt, dass die Anzahl der Optionen gerade auf eins reduziert worden ist.

Das heißt also ganz viele Optionen sind halt irgendwie tot und das ist halt nicht so cool.

Little Bobby Tables hat geschrieben, Menschen, Politik und Meinung.

Die Sachen hat er mit zusammenzubringen.

Und ich muss nochmal schauen, Vokabular steht hier noch.

Muss nochmal schauen, ob da irgendwie sozusagen Highlights waren.

Ich verlinke das irgendwie auch, das haben wir alles öffentlich.

So, genau, das nehme ich mir sozusagen als letztes Mal vor.

Das ist halt diese Idee, der Punkt, von dem einer, der halt letztendlich schreibt, Zeit ist das Problem.

Wo ich mir erst gedacht habe, ups, also weil nicht, was bedeutet das?

Und dann hat er geschrieben, dass man halt häufig sagt, wir haben nicht die Zeit, um etwas richtig hinzubekommen.

Aber das wirkliche Problem ist halt, dass Realität fließend wird, wenn es halt über die Zeit passiert.

Also weil sich Realität ständig ändert.

Das bedeutet, es ist halt lebendig.

Und wir bauen irgendwie Strukturen, die halt tot sind.

Und das finde ich einen guten Hinweis auf diese evolutionäre Weiterentwicklung, die ich halt irgendwie haben muss.

Also ich habe irgendwie Zeit, Dinge ändern sich, Anforderungen ändern sich, Technologien ändern sich.

Und das bedeutet, ich muss die Software nachlegen und eben versuchen herauszufinden, was da eigentlich Phrase ist über die Zeit.

So, dann hat Christian hier noch geschrieben, selbst programmieren ist ja nicht für den Computer, sondern für die anderen Entwickler im Team oder mich in sechs Monaten.

Im Compiler ist das ganz viel egal.

Genau.

Und deswegen gibt es überhaupt Compiler, weil wir als Menschen halt nicht die Sprache sprechen oder einfach verstehen können, die halt irgendwie die Maschine versteht.

Und das ist, glaube ich, ein extrem guter Punkt, den der Christian da nochmal macht, dass eben die Werkzeuge scheinbar technische Werkzeuge sind.

Eigentlich sind es Werkzeuge, damit Menschen halt irgendwas verstehen.

Gut, dann würde ich sagen, ich möchte mich bedanken erstmal dafür, dass es halt diese ganzen Beiträge gab und auch vielen Dank für die Diskussion heute.

Das fand ich auf jeden Fall schon mal super.

Ich verlinke, wie gesagt, die Threads, lese sie nochmal durch.

Ich muss mich entschuldigen, genau, das war der andere Punkt, dafür, dass ich es nicht geschafft habe, irgendwie alles durchzugehen.

Aber das Konzept von dem Stream ist eben, Zeit-Timebox vorzugehen und zu sagen, nach einer Stunde ist Schluss.

Und ich habe da dann noch ein paar Sachen, die ihr nachlesen könnt, wenn ihr möchtet.

Nächste Woche ist es so, dass der Professor der Grille kommt und wir sprechen über das Thema Open-Source-Komponenten richtig im Projekt oder Produkt verwenden.

Es gibt ja diese Open-Source-Lizenzen und da gibt es, glaube ich, ganz viel angstbehaftete Diskussion.

Dem wollen wir nachgehen und schauen, wie denn das nun tatsächlich ist, wie wir also mit Open-Source sinnvoll umgehen können.

Wir hatten den Dirk schon mal im Stream zum Thema Inner Open-Source.

Der ist Professor für Open-Source.

Das wird da, glaube ich, eine ganze Menge spannender und wichtiger, aber auch gleichzeitig sehr praxisrelevanter Sachen lernen können.

Ich würde mich freuen, wenn wir uns nächste Woche wiedersehen.

Ansonsten wünsche ich sozusagen schon mal ein schönes Wochenende und bis dahin vielen Dank für alles und vielleicht sehen wir uns nächste Woche wieder.

Bis dahin.