Martin
Ja, hallo und herzlich willkommen zum Sandpapier, unserem Sandstorm Weekly Podcast, in dem wir Erfahrungen und unsere Herausforderungen und Experimente, die wir so machen, in unserem Alltag als Softwareentwickler mal so besprechen und darstellen, was für Themen uns da so begegnen und was uns auf dem Herzen liegt. Heute habe ich ein Thema mitgebracht. Heute soll es um Softwarearchitektur gehen und um Softwarearchitekten, diese ominöse Spezies, ich will mal ein bisschen hinterfragen, um wen oder was es sich dabei eigentlich handelt. Und dafür habe ich mir zwei kompetente Gäste eingeladen. Das ist zum einen der Sebastian Kurfürst, hallo Sebastian.
Sebastian
Hallihallo, freut mich, dass es dabei sein kann.
Martin
und den Christoph Dähne, hallo Chris.
Christoph
Hallo und vielen Dank für die Einladung.
Martin
Danke, dass du da bist. Wir bei Sandstorm, wir tragen ja alle denselben Titel. Wir heißen alle Softwarearchitekt oder Softwarearchitekt. Und ich habe das mal gegoogelt, weil ich selbst nicht weiß, was ein Softwarearchitekt eigentlich ist. Und die Antwort, die Google einem da entgegenwirft, als Definition ist ein Softwarearchitekt ist jemand, der als Software Development Experte High Level Design Entscheidungen trifft und vor allem technische Standards sowie die Nutzung von beispielsweise Coding Styles, Tools oder Plattformen durchsetzt. Da habe ich mich erst mal ein bisschen zurückgelehnt, habe darüber nachgedacht und habe festgestellt, das ist ziemlich High Level. Machen wir das alle? Ist das tatsächlich das, was wir täglich tun? Oder wie kommt es dazu, dass wir alle Softwarearchitekten sind? Vielleicht, Sebastian, willst du mal kurz einsteigen? Ich kann nicht...
Sebastian
probieren. Ich glaube, für mich sind da zwei Faktoren wichtig. Wo kam dieser Begriff eigentlich her bei Senstorm? Wir haben irgendwann mal Visitenkarten gemacht und hatten dieses Thema, was schreiben wir da eigentlich drauf? Das war letztendlich der Aufhänger davon. Wir sind ziemlich schnell innerhalb der Firma dazu übergegangen, dass wir uns halt nicht als monothematische Spezies verstehen, sondern eigentlich als vielseitige Facettenreiche, also dass wir die Aspekte betonen, die jeder so hat. Das sieht man auch bei uns auf der Webseite. Da haben wir auch so eine Themencloud quasi. Das Problem war jetzt so ein bisschen, naja, diese Themencloud passt natürlich schlecht auf eine Visitenkarte. Wir wollten halt gerade in der Kommunikation mit Externen irgendwas haben, was versucht zu beschreiben, was wir da tun und was wir tun wollen. Das heißt, wir wollten natürlich irgendeinen Begriff finden, der sozusagen in der externen Welt auch in irgendeiner Form bekannt ist. Für mich gibt es, ich würde sagen, eine Sache, die wir relativ stark anders machen als ganz viele andere Agenturen. Und zwar in vielen anderen Agenturen ist es so, da hat man häufig diese Rolle des Projektmanagers und die Rolle des Entwicklers. Und diese beiden Persönlichkeiten kommen quasi in einem, also arbeiten zusammen an einem Projekt. Also da kann es halt sein, dass sozusagen der Projektmanager, die Projektmanagerin meistens hat den Kundenkontakt, versucht, die Anforderungen aufzunehmen und die Anforderungen zu übersetzen. Und der, die Entwicklerin ist sozusagen dann in der Umsetzung derjenige, der das vorantreibt und implementiert. Und wir bei Senstorm haben ja nicht diese starke Trennung, sondern da wir machen es ein bisschen anders. Bei uns ist ja sozusagen das Ziel, dass ein Entwickler direkt mit einem, mit quasi dem Kunden oder der Kundin entsprechend redet. Und wie soll ich sagen, wir wollten halt das auch, also das erfordert halt häufig sozusagen einen größeren Blick und einen stärker rausgesundenen Blick. Und deshalb haben wir, als wir dann über diese Begrifflichkeiten geredet haben, wollten wir uns halt auch so ein bisschen von jetzt einem reinen Entwickler oder einer reinen Entwicklerin ein bisschen abgrenzen und sagen, hey, wir versuchen das mal ein bisschen anders zu formulieren. Ich glaube nicht, dass jetzt jeder von uns täglich sozusagen diese Softwarearchitektur beide buck macht, also im Sinne von das, was du gerade vorgelesen hast. Aber ich glaube schon, dass wir den Anspruch haben, dass jeder von uns im Team das kann, dass jeder im Team dieses Interesse hat und das auch gegenüber einem Kunden oder einer Kundin entsprechend, ich sag mal vertritt, also sprich, dass der Kunde beraten wird in der Tätigkeit oder in seinen Problemen und dass wir halt nicht einfach nur sagen, aha Kunde, du hast uns erzählt, was du machen willst, was du genau brauchst und jetzt bauen wir das eins zu eins, sondern wir fragen halt zurück, wir versuchen zu verstehen, warum der Kunde die Kundin das möchte. Und das ist für mich halt ein Teil, der sozusagen in dem Berufsbild eines Softwarearchitekten mit enthalten ist. Bei einem normalen Entwickler ist es halt so, dass es häufig an der Stelle ein Cut gemacht wird. Ja, das war so meine erste Einschätzung davon.
Martin
Chris, du bist Softwarearchitekt. Fühlst du dich wie einer?
Christoph
Ja, vor allem vor dem Hintergrund, den Sebastian jetzt erläutert hat. Der Begriff kam ja tatsächlich ins Handstorm rein vor dem Hintergrund der Visitenkarten. Und jetzt ist es natürlich so. Man kommuniziert ja damit vor allem mit Leuten, die man nicht kennt und die einen noch nicht kennen oder auch die Firma noch nicht, um damit die einen grob einordnen können. Und jetzt, wenn man jetzt sagt, okay, der ist Entwickler. Dann kommt man halt in eine Schublade. Und natürlich wird das bei uns den Leuten nicht richtig gerecht. Oder wurde es auch früher schon nicht, als wir noch weniger waren, sondern wir haben halt so ein bisschen uns um alles gekümmert. Und natürlich Software Architektur gehört dazu. Auch das, was du in der Definition jetzt ausgesucht hat, ist, die wichtigen Entscheidungen zu treffen und auch, sage ich mal, sehr überlegt zu treffen, gehört dazu. Aber bei Sandstorm gehört es auch dazu, die ein Stück weit auszubaden. Weil wir machen ja in der Regel zumindest meistens nicht die Architekturen und zeichnenden Bild, sondern wir machen die Architekturen und schreiben eine Software. Das heißt, das Ganze, was danach kommt mit dem Implementieren, das passiert ja auch.
Martin
Mhm.
Christoph
Und
Martin
Okay.
Christoph
Ich denke, an dem Begriff sind höhere Erwartungen geknüpft als an dem Begriff Entwickler. Das wäre jetzt so meine eigene subjektive Wahrnehmung. Deshalb fand ich den ganz passend. Eigentlich müsste dastehen Softwarearchitekt und noch mehr.
Martin
Okay, für mich resultieren da eigentlich direkt zwei Fragen raus. Die erste ist, hat euch schon mal jemals jemand gefragt, ob wir auch Software-Entwickler haben? Also für mich, kurzer Hintergrund, warum ist mir das gerade so durch den Kopf geschossen? Für mich, wenn ich auf einen Architekten treffe, frage ich mich natürlich dann immer, wer baut denn dann? Also haben wir je erklären müssen, dass wir nicht nur die Architektur machen, sondern eben auch das Ganze ausmalen.
Sebastian
Hm, also ich kann mich gerade nicht dran erinnern. Das müsste ich nicht, Chris.
Christoph
Ich habe auch gerade überlegt, wobei ich das meistens vorweggenommen habe in dem Gespräch. Also Martin, du hattest ja den Begriff Softwarearchitektur nochmal nachgeguckt, um zu sehen, was das wirklich ist und auch in dem Podcast geht es ja darum und ich hatte auch das Gefühl, wenn man sich jetzt über den Weg kennenlernt und über diesen Begriff ins Gespräch kommt, dass man den sofort erläutern muss oder dass ich den sofort erläutern muss und das habe ich dann auch gemacht. Und dann hatte ich natürlich sofort Gelegenheit zu sagen, übrigens, wir machen das dann auch, was wir uns überlegt haben oder wir machen es teilweise. Wir arbeiten ja auch gerne mit anderen IT-Firmen zusammen und übernehmen dann nur Teile der Aufgaben. Und das forensiciert vieles auch.
Martin
Okay, könnt ihr mit dem Begriff Solutions Architect was anfangen?
Sebastian
Jetzt nie ad hoc. Ich könnte eine erste Assoziation, aber ich könnte es jetzt nicht wirklich definieren.
Martin
Okay, dann übernehme ich mal kurz die Definition und schließe dann meine Frage an, was uns zum Solutions-Architekt eigentlich unterscheidet. Denn für mich ist das genau das, was du eben beschrieben hast, Sebastian, was wir so tun. Das ist nämlich derjenige, der eben nicht nur das Application-Design macht, also die Software-Architektur, sondern eben auch das, ich sag mal, Ausmalen entweder begleitet, überwacht oder vielleicht sogar selbst durchführt und darüber hinaus auch den Business-Case im Auge behält. Also das, ich sag mal, nicht nur Software-Architektonisch, sondern Business-Architektonisch ein Auge drauf hat. Würde das nicht noch viel besser passen?
Sebastian
jetzt ad hoc würde ich sagen ja also auf jeden fall ich glaube die wie soll ich sagen als wir diese begrifflichkeiten uns überlegt haben dass das ich sag mal da war das halt gar nicht so die riesen also gar nicht so dieses riesen thema wir hatten halt viele themen die wir uns kümmern mussten wir hatten relativ viel zeitdruck wir brauchten relativ dringend visiten karten ich glaube für eine konferenz und dann trifft man halt auch so eine entscheidung natürlich irgendwo aus dem bauch raus oder halt in einer recht kleinen gruppe wo man sagt na ja ganz kurz wie machen wir das und okay wir wollen das nicht das eine nennen wir nennen uns jetzt so und so aber klar da gibt es sicherlich noch begriffe die das noch mehr umreißen und vielleicht auch besser beschreiben was für mich halt immer wichtig ist dass die leute sozusagen die nicht ins senstum haben zumindest eine ganz grobe vorstellung haben also und und und ich glaube also was sie erwarten können da ist natürlich dieser begriff nur das erste nur diese erste sozusagen der erste aufhänger und die erklärung was auch chris meinte das ist glaube ich ganz ganz wichtig was mir auch mal ganz was mir ganz wichtig ist wie ich softwarearchitektur begreife oder auch mich in dieser rolle begreife zum beispiel ganz persönlich also für mich gehört da ganz viele reflektionen dazu nämlich wir treffen ja ganz viele entscheidungen wenn wir so ein software projekt machen zwar manche davon kleiner manche größer das heißt manche kann man schneller ändern und manche sind halt sozusagen das fundament und bei einem haus ein fundament auszutauschen ist schon richtig richtig viel arbeit das kann man mal machen aber das ist dann viel viel aufwendiger und für mich ist halt wichtig wir werden nicht alle entscheidungen richtig treffen und ich treffe ganz viele falsche entscheidungen beispielsweise wo man im nachhinein raus findet hey die entscheidung ist eigentlich die andere entscheidung wäre besser gewesen beispielsweise und diese art von reflektionsfähigkeit und reflekt also also trainieren und fördern das finde ich halt ganz ganz wichtig deshalb ist mir das auch wichtig dass wir halt auch nicht nur sage ich mal das diagramm malen an der grünen wiese oder auch an der wand die tapete produzieren wie soll das denn mal in der heilenwelt funktionieren sondern dass wir es halt auch umsetzen müssen damit wir permanent diese rückkopplung diese rückkopplung haben hat das dann geklappt welche teile haben geklappt und welche teile haben halt nicht geklappt weil wie gesagt ich denke es ist natürlich völlig illusorisch dass man immer die richtige in anführungszeichen entscheidung trifft sondern das ist aber trotzdem wichtig dass wir natürlich entscheidungen treffen damit es halt losgeht man kann das natürlich tot definieren solche dinge oder viel papier produzieren wenn man sich als architekt in anführungszeichen begreift und alle anderen machen lässt und das finde ich persönlich eher nicht so zielführend auf dauer
Martin
Also die Rolle des Sandstormers kombiniert, ich fasse nochmal zusammen, die Softwareentwicklung, die Softwarearchitektur, das Projektmanagement und den Solutions-Architekten, ist ja eigentlich auch ganz passend, dass wir irgendwie in letzter Zeit uns, also zumindest sehe ich das in E-Mails als als Signatur ganz häufig gar nicht mehr Softwarearchitekt hinschreiben, sondern Sandstormer, das finde ich eigentlich ganz schön, weil das beschreibt so die allumfassende Aufgabe, die wir so haben.
Sebastian
Das ist natürlich ein hoher Anspruch. Ich glaube, das ist wichtig. Wir werden dem manchmal gerechter und manchmal weniger gerecht. Ich glaube, das ist auch etwas, was man dazu sagen muss, weil wir natürlich nicht die Weißheit mit Löffeln gefressen haben, sondern auch ganz viele Fehler machen. Womit wir gute Erfahrungen gemacht haben, ist, dass wir immer versuchen, im Interesse des Kunden zu handeln. Dafür ist wichtig, dass wir auch verstehen, was denn das Interesse des Kunden ist. Nicht nur auf einer technischen Sicht, sondern auch auf einer Business-Sicht. Was hängt denn da dahinter für denjenigen oder diejenige? Unter dieser Prämisse kann man auch natürlich mal Fehler machen. Bis jetzt war das auch so, dass die Kunden das trotzdem immer geschätzt haben, diese ehrliche Art der Kommunikation. Und auch bereit waren, über einen Fehler hinwegzugucken, der natürlich passiert und wo wir auch ganz offen mit umgehen. Weil, ich sage mal, ein bisschen salopp gesagt, wo gehobelt wird, fallen Späne. Ich sage mal, immer wenn wir etwas machen, machen wir natürlich Fehler. Und das lässt sich gar nicht vermeiden nach meinem Empfinden.
Martin
Ja, absolut.
Christoph
Aber gerade, was du meintest, die Reaktion darauf, wenn wir Fehler ansprechen oder wo wir Fehler vermuten, das sehr früh ansprechen, die ist sehr, sehr positiv und das wirkt sich auch in der Regel sehr, sehr gut auf das Projekt aus. Also einen Fehler zu verschleppen oder im Extremfall zu hoffen, dass es der Kunde nicht merkt, das führt zu viel schlechteren Ergebnissen. Also von daher kann ich es auch eben ans Herz legen, das soll jetzt nicht so klingen, als wäre das was ganz Besonderes und was ganz mutiges und was ganz schwieriges. Das ist auch eine sehr rationale Entscheidung, die man treffen kann.
Martin
Ich würde gerne noch mal auf den Begriff kommen. Wir haben so ein bisschen das Bild des Architekten aus dem Bauwesen im Kopf, also ich zumindest, wenn es um Architektur geht. Das ist also jemand, der was Tolles zeichnet, eine Blaupause und sich vielleicht noch um die Statik bemüht, das Ganze, das mal ausrechnet. Und darauf aufbauend wird dann am Ende ein Haus gebaut und das jetzt mal übersetzt. Für mich ist mal ganz spannend zu erfahren. Was ist, was ist für euch eigentlich Software Architektur? Was, was macht dieser diesen Begriff aus? Also nicht als Software Architekt, sondern nur der Begriff Software Architektur. Willst du starten? Wer jetzt? Wer ist du? Ach so, Sebastian. Ja, das wars.
Sebastian
Ja, na klar. Genau, wir sind auch im Homeoffice, wir sehen uns alle nicht, deshalb gibt es manchmal diese lustigen Situationen. Genau, Softwarearchitektur, was bedeutet das für mich? Ganz kurz zusammengefasst würde ich sagen, ist es das Treffen der großen, wichtigen, wenigen Architekturentscheidungen am Anfang eines Projekts. Also die Basis legen, auf die dann alles weitere aufbaut. Und je weniger Entscheidungen, also man muss nicht viele Entscheidungen an diesem Punkt treffen, aber man muss sozusagen die großen Entscheidungen treffen, die man danach nur sehr schwer ändern kann. Das würde ich sagen, mal in der Essenz. Ich versuche es mal mit einer kurzen Antwort erstmal.
Martin
Okay, ich lasse dich aber noch nicht vermarken. Du hast gesagt, Softwarearchitektur ist für dich das Treffen der großen Architekturentscheidungen. Jetzt ist natürlich die Frage, was ist denn Architektur im Softwarekontext?
Sebastian
Genau, also es fängt mit sowas an, welche Programmiersprache verwende ich. Das ist natürlich eine recht, also eine grundlegende Entscheidung, welche Arten von Datenspeicherung verwende ich. Beispielsweise nutze ich eine Datenbank oder nutze ich eine andere Variante. Welche Datenbank-Arten nutze ich beispielsweise? Was sind Anforderungen an, die die Anwendung hat hinsichtlich Skalierbarkeit oder Performance, zum Beispiel. Wie kann ich die ermöglichen sicherzustellen? Dann brauche ich sowas wie Skalierbarkeit, also es gibt verschiedene Wege Skalierbarkeit zu realisieren, horizontal beispielsweise und da geht es eigentlich genau darum, da mal highlevel drüber nachzudenken, sich mal zu überlegen, wie viele Anfragen hat zum Beispiel die Anwendung, wie viele bewegliche Daten gibt es in der Anwendung, an welchem Punkt werde ich vermutlich ein Skalierbarkeitsproblem vielleicht bekommen und wie könnte ich das dann angehen, wenn ich es habe. Also das geht eigentlich so ein bisschen mal in die Zukunft denken und in verschiedene Wege mal abbiegen und mal überlegen, okay, wenn ich es jetzt hier so baue, was hätte das für Konsequenzen, wenn ich es hier so baue, was hätte das für Konsequenzen und so weiter. Und die Schwierigkeit ist dabei, dass man sozusagen auf der einen Seite immer in der Zukunft denkt und auf der anderen Seite nicht zu weit vorneweg rennen darf, weil natürlich, also wir denken sozusagen in zehn verschiedenen Zukunftsvarianten, mal ein bisschen bildlich gesprochen und am Ende wird halt nur eine davon wahr und in der Regel nicht mal die, die wir sozusagen vorgedacht haben, sondern halt eine Abwandlung von einer dieser Varianten und das ist genau das Spannungsfeld, dass man auf der einen Seite sozusagen Annahmen trifft, wie sich die Zukunft verhalten wird und daraus Entscheidungen ableitet und die Praxis wird aber eine andere sein und das weiß man schon, man weiß noch nicht, wie sie sein wird, aber sie wird halt anders sein.
Martin
Chris, wie findest du raus, welche Anforderungen deine Anwendung in Zukunft haben wird? Hast du deine Strategie dafür?
Christoph
Ja, in Zukunft ist natürlich gleich die ganz, ganz schwierige Frage. Eine Glaskugel, wo das drinsteht, habe ich leider nicht. Also es hilft natürlich als erstes, dem Kunden ganz aufmerksam zuzuhören. Und dann manchmal existiert ja auch eine ähnliche Anwendung, die ersetzt werden soll. Das ist dann natürlich sehr, sehr komfortabel, aber manchmal auch nicht. Und an der Stelle versuche ich dann nicht nur über die technischen Gegebenheiten zu sprechen, die ja durchaus existieren können. Es existiert ganz viel Know-how von mir aus, Java in dem Team. Und deshalb ist die Entscheidung der Sprache schon gefallen, das gibt es. Sondern auch mit dem Kunden über seine Vision zu sprechen, das hilft an der Stelle, denke ich, sehr gut. Und zwar die Vision, die über die nächsten konkreten Schritte hinausgeht. Manchmal findet man dort dann auch Hinweise, die schon am Anfang sehr wichtig sein können. Das ist eine Sache. Und die andere Sache ist das, was Sebastian auch schon gesagt hat, Entscheidung verschieben. Das ist auch etwas, was gut funktioniert. Ich war auch schon an Projekten beteiligt, das ganze Programm wurde quasi schon aufgezeichnet als Diagramm, bevor angefangen wurde zu implementieren und die erste Zeile kurz zu schreiben. Aber während man ein Projekt dann umsetzt, lernt man ja dazu, zum einen, man sieht natürlich Sachen, die man am Anfang noch nicht gesehen hat, und manchmal, wenn die Zeit vergeht, ändern sich auch die Anforderungen. Und wenn man Entscheidungen, die man noch nicht treffen musste, wie zum Beispiel beim Haus jetzt die Farbe der Fassade, wenn ich das erst einen Tag bevor die Maler kommen, entscheiden kann, dann habe ich da natürlich viel, viel Möglichkeit, mich an die ganz, ganz konkrete Situation noch anzupassen.
Sebastian
Für mich gibt es noch zwei coole Sachen oder gute Patterns im Kopf. Christoph hat es ja schon gemeint, das ist mit dem Kunden reden. Das ist für mich auch ganz, ganz essenziell und mir geht es häufig so, dass ich auf die Nebensätze achte. Also, wenn ein Kunde sowas sagt, also diese Sätze, die dann so ins Nichts wandern, also dass ein Kunde so leise vor sich hinmummelt, naja, das ist ja klar, Punkt, Punkt, Punkt. Na, das müsste, klar habe ich das erwartet, also solche Selbstverständlichkeiten in solche Richtungen zu hören, beispielsweise, weil da häufig sozusagen eine tiefere Wahrheit drunter liegt. Also, weil dann, da ergeben sich manchmal nochmal ganz Bereiche, die man auf den ersten Blick nicht erfasst und das ist für mich auch die Gefahr, dass man sozusagen, wenn jemand zu mir kommt zum Beispiel und mir was von einem Problem erzählt, dann bin ich im Kopf sehr schnell in der Lösungs-Skizze, also ich versuche zwar mit dem Kunden zu reden und draus zu finden, was sein Problem ist, aber ich mache mir im Kopf eine Vorstellung davon, wie ich es machen würde. Das ist auf der einen Seite gut, weil man damit, also bei mir das zum Beispiel hilft, wirklich eine konkrete, also wirklich auf eine konkrete Ebene runterzukommen und wenn ich irgendwann mal an dem Punkt bin, dass ich es mir wirklich konkret vorstellen kann, auf einer detaillierten Ebene, dann ist für mich eine Architektur irgendwie rund, aber die Gefahr dabei ist halt, dass man zu schnell dahin absteigt und für mich ist deshalb dieses Slow-Thinking, dieses langsame Denken, was wir auch schon manchmal, glaube ich, angesprochen hatten so wichtig, also dieses immer wieder sich selber hinterfragen, habe ich es wirklich verstanden, ist es wirklich genau das, also sozusagen versuchen, den Kunden zu spiegeln mit seinen eigenen Worten und nochmal versuchen, ganz explizit zu sein, möglichst eine klare Sprache zu haben, wenn der Kunde halt im Alltagssprache redet beispielsweise, dann halt versuchen, das wirklich Punkt für Punkt, Schritt für Schritt runterzubrechen zusammen mit einer Skizze am Whiteboard beispielsweise und wirklich jeden Schritt nachzuvollziehen, okay, ist das so, ist das so, ist das jetzt deine Annahme und dann halt auch so Fragen zu stellen, naja, passt das noch zusammen mit den anderen Dingen, die gesagt wurden und also häufig ist es, also was ja häufig passiert ist, dass es Inkonsistenzen gibt zwischen verschiedenen Anforderungen, also das heißt, dass verschiedene Anforderungen sich sozusagen in die Quere kommen, also der Kunde möchte A und möchte B und das widerspricht sich, aber das ist aber gar nicht so einfach zu erkennen, also das würde man später erst erkennen, wenn man es implementiert, mal ganz hart gesagt und das rauszuarbeiten und dann zu überlegen, wie könnte da denn eine Lösung aus sein, das ist für mich halt auch wichtig, quasi zu einer möglichst widerspruchsfreien Weltsicht zu kommen und widerspruchsfrei heißt, es muss quasi alles möglich sein, was sich der Kunde vorstellt, aber idealerweise an genau einer Stelle, dass ich halt nicht diese Wahlmöglichkeit habe, packe ich es dahin, packe ich es dahin, sondern dass halt klar ist, okay, du hast diese Anforderungen und die wird auf, ich sag mal genau diesen Wege umgesetzt, also das sozusagen die Architektur idealerweise, das klappt natürlich nicht immer, aber dass die sozusagen eine Richtschnur ist, wie dann später die Anforderungen sozusagen eingepuzzelt werden, also was sozusagen definiert, wie groß die Lego Steine sind, die man zusammenpacken möchte, welches Raster die haben und so weiter.
Christoph
Da kann ich dir nur zustimmen, Sebastian. Eine Sache würde ich aber auch noch ergänzen. Es gibt so bestimmte Worte, die mich sofort hellhörig machen. Und zwar immer, wenn irgendwas relativiert wird. Das sind so Worte, die normalerweise erstmal, eigentlich immer, da lohnt es sich nach meiner Erfahrung meistens auch noch mal ganz genau nachzufragen.
Martin
Ich finde, Erfahrung ist ein super Stichwort, Überleitung zu meiner nächsten Frage. Kann man Softwarearchitekt werden, dadurch, dass man Bücher liest oder was lernt? Oder ist das was, was man nur durch Erfahrung erreicht? Also, guter Softwarearchitekt zu werden. Ist das was, was man durch Erfahrung erreicht oder das man lernen kann?
Sebastian
Ich würde sagen, das ist ein Aspekt von beidem. Es ist natürlich schon hilfreich, mal eine gewisse Breite an Hintergrundwissen zu haben, das finde ich schon hilfreich. Ich lerne auch viel aus Büchern beispielsweise, dass ich mir angucke, wie funktionieren gewisse Technologien, was haben sich andere Gedanken gemacht hinsichtlich, wie kann ich Software zusammenstecken. Ein Buch, was mich z.B. extrem geprägt hat, damals war das Domain Driven Design Buch von Eric Evans oder noch davor das Thema Patterns of Enterprise Application Architecture von Martin Fowler. Das waren z.B. so Bücher, die wirklich meine Art des Denkens stark geprägt haben. Das andere, was mich geprägt hat, war sicherlich auch die Uni, nicht so konkret, dass ich sagen könnte, die Software-Architektur-Skills, aber eher so Denken über Komplexität, Überskalierbarkeit. Da hat die Uni für mich viel gebracht, für mich persönlich. Der dritte Aspekt ist aber schon, wie du gesagt hast, einfach Erfahrung, weil du gesagt hast, was braucht man denn, um ein guter Software-Architekt zu werden? Ich glaube, das ist eine schwierige Frage, weil was heißt denn gut? Ich könnte jetzt nie sagen, bin ich ein guter Software-Architekt? Ich nenne mich so. Aber je mehr ich weiß, desto mehr bin ich mir meiner eigenen Unzulänglichkeit bewusst. Also sprich, ich weiß, welche Fehler ich gemacht habe und welche Fehler ich in welchem Projekt gemacht habe und was ich daraus lerne, aber die Welt wird für mich immer bunter und weniger schwarz-weiß, auch in diesem Aspekt. Ich glaube aber, wenn man das werden möchte, dann muss man halt anfangen. Man muss halt anfangen, Entscheidungen treffen und die ausbaden und dann herausfinden, hey, war das jetzt eine gute oder eine schlechte Entscheidung und was lerne ich daraus fürs nächste Mal? Und genau diesen Zyklus halt wieder und wieder und wieder machen und dann kann halt zusätzlich sozusagen Inspiration in Form von Büchern, Blogartikeln und so weiter, kann schon helfen, wenn ich etwas vorbeis determine will, dass ich etwas vorbeifhomme und
Martin
macht einen guten Softwarearchitekten aus, dass er neugierig und lernwillig bleibt.
Christoph
Ich denke, dass es auf jeden Fall hilft. Gerade in einer, also nicht nur in der IT, aber der Blumenstrauß, den man hat, an Möglichkeiten, der ändert sich über die Zeit, der wird tendenziell gefühlt eher größer, wobei auch immer mal ein paar Sachen rausfallen und den Blick dafür zu haben, was um einen herum passiert, hilft einem in jeder Disziplin. Ich kann mir nicht vorstellen, dass ich auf die ganzen tollen Sachen, die mich packen, wenn ich die lese, alleine komme in meinem Leben, sondern ich brauche ganz doll diesen Input von außen.
Martin
Das war's für heute.
Sebastian
Ich sage mal, wenn man es mal fies formuliert, würde ich sagen, gut geklaut ist halb gewonnen. Also das ist jetzt sehr vereinfacht und sehr drastisch, aber es ist, finde ich, völlig okay und gut, wenn man sich halt aus anderen Bereichen inspirieren lässt. Also ich lese zum Beispiel auch sehr, sehr gerne fremden Quellcode und auch versuche herauszufinden, wie funktionieren denn große Software-Systeme, indem ich die Quellcode angucke, weil ich konkrete Fragen habe und das ist zum Beispiel etwas, was mich einfach interessiert. Aber das ist immer ganz verschieden. Ich würde sagen, ich glaube, da muss jeder auch so ein bisschen seinen Weg finden, sein oder ihren Weg, der halt zu jedem Einzelnen passt. Also für mich trifft es definitiv zu, diese Art von Neugier, aber ich glaube, es gibt natürlich viele Wege, das zu erreichen. Und ich würde mich jetzt, um Gottes Willen nicht hinstellen, sagen, ja, das muss alles mit diesem Weg passieren, sondern es gibt bestimmt auch viele Leute, die sagen, ja, okay, ich mache mein Daily Business und dann gehe ich einmal im Jahr auf eine Konferenz beispielsweise und da kriege ich viel Input oder ich schaue mir ein paar YouTube-Videos immer mal an, wenn ich Lust drauf habe oder mein Kollege erzählt mir was in der Kaffeeküche. Also ich glaube, das kann auf ganz vielfältige Art und Weisen passieren, diese Art des Wissensaufbaus. Das ist halt so verschieden, wie die Leute auch verschieden sind, welches Mittel und welcher Weg dafür sie gut passt.
Martin
Okay, ich glaube, wir haben relativ gut definiert, was wir unter dem Softwarearchitekten verstehen. Hab ich irgendwas Wichtiges vergessen? Wollt ihr noch was loswerden?
Sebastian
Nö, ich glaube nicht, nicht ad hoc. Ich bin gespannt aufs Feedback.
Martin
Ich auch. Genau.
Christoph
Ich glaube, wir haben das Thema ausführlich beleuchtet. Ich bin auch sehr gespannt, was an Meinungen zu kommen.
Martin
Genau. Feedback ist ein super Stichwort. Wir freuen uns natürlich sehr über Feedback per Twitter, per Mail, was auch immer ihr so bevorzugt. Und ansonsten würde ich euch beiden danken für die Folge. Es hat mir viel Spaß gemacht und wir hören uns nächsten Freitag wieder.
