Vom Elfenbeinturm zum Enabler: Software-Architektur im agilen Wandel

Wolfgang: Hallo und herzlich willkommen bei Digital Future, dem Podcast zur Technologie

Wolfgang: und Unternehmenskultur.

Wolfgang: Mein Name ist Wolfgang Schoch und ich bin Agile Coach bei Inovex.

Wolfgang: Ich habe aber auch schon ein paar andere Sachen gemacht und so die IT-Branche

Wolfgang: aus verschiedenen Blickwinkeln kennengelernt.

Wolfgang: Zum Beispiel als Softwareentwickler, als Experte für Suchtechnologie oder im Vertrieb.

Wolfgang: Ich freue mich, euch in jeder Folge des Podcasts eine Kollegin oder einen Kollegen

Wolfgang: vorzustellen und mich mit ihr oder ihm über das jeweilige Fachgebiet zu unterhalten.

Wolfgang: So bekommt ihr einen Einblick in unseren technologischen und unternehmenskulturellen Alltag.

Wolfgang: In der heutigen Folge spreche ich mit meinen Kollegen Ulrich Becker und Marvin

Wolfgang: Klosek über die Rolle von Architekten in Softwareprojekten.

Wolfgang: Wir sprechen darüber, was Softwarearchitektur eigentlich ist und wie sich das

Wolfgang: Verständnis dafür in den letzten Jahren entwickelt hat.

Wolfgang: Außerdem klären wir, wie moderne Architekturarbeit betrieben werden kann und

Wolfgang: welche große Rolle Kommunikation dabei spielt.

Wolfgang: Und jetzt wünsche ich euch viel Spaß beim Zuhören.

Wolfgang: Ja, hallo ihr beiden. Ich freue mich, dass wir heute endlich zusammengekommen

Wolfgang: sind zu diesem spannenden Thema.

Wolfgang: Aber bevor wir über das Thema sprechen, würde ich mich freuen,

Wolfgang: wenn ihr beide euch mal kurz vorstellen könnt. Wer seid ihr?

Wolfgang: Wie lange seid ihr schon bei InnoVex? Und was macht ihr so den lieben langen

Wolfgang: Tag, wenn ihr nicht gerade hier im Podcast seid?

Wolfgang: Und Marvin, vielleicht magst du ja anfangen.

Marvin: Ja, hallo Wolle, danke für die Einladung. Ich bin Marvin, bin seit circa sechs

Marvin: Jahren jetzt bei InnoVex, arbeite hier als Data Engineer, bin im Fokus auf ETL-Strecken

Marvin: und Data Warehousing und habe in der Kapazität auch häufiger mal mit Softwarearchitektur,

Marvin: Softwarearchitekturentscheidungen, Softwaredesign zu tun und freue mich deswegen

Marvin: darauf, hier mit euch heute darüber diskutieren zu können.

Wolfgang: Ich freue mich, dass du da bist, Marvin. Man kennt dich vielleicht ja noch.

Wolfgang: Wir haben uns vor ein paar Monaten ausgiebig über Datenbanken unterhalten und

Wolfgang: über Data Warehousing und ich habe das noch gut im Hinterkopf. Das war sehr spannend.

Wolfgang: Uli, du bist das erste Mal heute dabei. Ja, wer bist du denn eigentlich?

Ulrich: Ja, mein Name ist Ulrich Becker. Ich bin seit Anfang des Jahres,

Ulrich: also seit Januar bei Innovex als Softwarearchitekt und Trainer unterwegs und

Ulrich: bin schwerpunktmäßig mit dem Thema Softwarearchitektur unterwegs.

Ulrich: Also zum einen mal wirklich Hands-on-Architekturarbeit in den Projekten,

Ulrich: aber auch beratend, wenn es zum Beispiel um Architekturdokumentation oder Architekturanalysen geht.

Ulrich: Und dann ist so, ja, Ausbildung von Softwarearchitektinnen noch so ein Herzensthema von mir.

Ulrich: Da bin ich halt gerade in diesem IS-AQB Certified Professional for Software

Ulrich: Architecture Umfeld unterwegs mit verschiedenen Trainings, also als Trainer

Ulrich: für Foundation Level oder für die Advanced Level Module Embedded und Agiler,

Ulrich: also agile Software Architektur und verlässliche eingebettete Systeme.

Ulrich: Ja, und ich freue mich auch hier zu sein und bin sehr gespannt auf das Gespräch mit euch beiden.

Wolfgang: Ja, und das Thema von unserem heutigen Gespräch ist ja Software-Architektur

Wolfgang: beziehungsweise die Rolle von Software-Architekten im Projekt oder ja,

Wolfgang: so im Alltag, im Software-Alltag.

Wolfgang: Ich habe ein bisschen nachgedacht vor unserem Gespräch und ich selbst habe ja

Wolfgang: Anfang der 2000er Informatik studiert und da sprach man auch schon mal über

Wolfgang: Software-Architekten in der männlichen Form.

Wolfgang: Bei mir gab es leider wenig Kommilitoninnen damals in meinem Studiengang.

Wolfgang: Aber meine Erinnerung an diese Definition von Anfang der 2000er Jahre,

Wolfgang: die sah noch so aus, dass das eben eine allwissende Person ist,

Wolfgang: die ganz schön viele Entscheidungen trifft und letztendlich auf Basis der Erfahrung

Wolfgang: irgendwie festlegt, wie dann später so ein Software-System aussieht.

Wolfgang: Und bevor wir jetzt über die Rolle von Software-Architektinnen in Projekten sprechen,

Wolfgang: fände ich es total wertvoll, wenn wir mal darüber sprechen, was bedeutet es

Wolfgang: eigentlich, diese Rolle Software-Architektin innezuhaben, beziehungsweise was ist das eigentlich,

Wolfgang: Software-Architektur, also heute im Jahr 2025?

Wolfgang: Uli, du hast schon gesagt, du bist Trainer für solche Weiterbildungen.

Wolfgang: Du bist quasi dafür zuständig, unter anderem Menschen anzuleiten und zu befähigen,

Wolfgang: ja irgendwas mit Softwarearchitektur gut umzusetzen.

Wolfgang: Vielleicht hast du ja so eine erste Definition.

Ulrich: Also ich würde erst mal sagen, so wahnsinnig viel, was man grundlegend unter

Ulrich: Softwarearchitektur versteht, hat sich gar nicht geändert.

Ulrich: Was sich sehr, sehr stark geändert hat, ist allgemein das Umfeld,

Ulrich: wie Architektur entsteht.

Ulrich: Also eben genau typischerweise nicht mehr von dieser einen allwissenden Person

Ulrich: und auch nicht primär vielleicht jetzt zu Beginn eines Projektes,

Ulrich: sondern wie es halt in so ein agiles Vorgehen halt reinpasst,

Ulrich: dann eben wirklich auch mit Einbindung des Teams Und eben entsprechend auch

Ulrich: immer reagierend auf das, was an Änderungen, an den Anforderungen reinkommt.

Ulrich: Aber so dieser grundlegende Ansatz, dass wir sagen, okay, wir überlegen uns,

Ulrich: was ist eine sinnvolle Zerlegung praktisch von unserem System,

Ulrich: was sind Technologien, die wir einsetzen, die einfach zu unseren Anforderungen dazu passen.

Ulrich: Also das ist ganz zentraler Punkt natürlich immer, dass es darum geht,

Ulrich: eine Architektur zu finden, die dann auch zu dem Problem, das wir lösen wollen, passt.

Ulrich: Das hat eigentlich soweit Bestand und dann eben auch so dieses ganze Thema,

Ulrich: wie gehen wir mit Querschnittskonzepten, Querschnittsthemen um.

Ulrich: Also wenn es jetzt zum Beispiel um Themen wie Fehlertoleranz oder Performance

Ulrich: oder was auch immer jetzt ein anderes Querschnittsthema sein mag,

Ulrich: dass eben diese grundlegenden Fragen dann praktisch in der Architektur behandelt werden.

Ulrich: Also dieser ganz grundlegende Ansatz, wie zerlege ich ein System,

Ulrich: wie ist das Zusammenspiel der verschiedenen Systembestandteile,

Ulrich: was sind sinnvolle Technologieentscheidungen oder auch Zerlegungsentscheidungen,

Ulrich: das ist im Kern das, was Architektur ausmacht für mich.

Wolfgang: Marvin, du nickst ein kleines bisschen, siehst du das genauso?

Marvin: Also ja genau, das ist ja praktisch die Lehrbuchdefinition, die Zerlegung der

Marvin: Komponenten, der Beziehungen, der übergreifenden Prinzipien.

Marvin: Ich finde persönlich gibt es auch eine sehr praxisnahe und einprägsame Definition,

Marvin: die immer gefallen hat, dass es Softwarearchitektur ist, die Summe aller Entscheidungen

Marvin: im Projekt, die uns richtig wehtun, wenn wir sie falsch treffen.

Wolfgang: Eine sehr schöne Definition, die merke ich mir auf jeden Fall.

Wolfgang: Naja, jetzt sagt ihr, es geht darum,

Wolfgang: hier diese Struktur mehr oder weniger richtig zu entwerfen, richtig zu entwickeln

Wolfgang: vielleicht auch, die richtigen Entscheidungen zu treffen.

Wolfgang: Das ist ja schon eine große Herausforderung, oder? Also wenn wir jetzt mal kein

Wolfgang: System haben, das trivial ist, weil wenn es was Triviales ist,

Wolfgang: okay, dann brauchen wir uns wahrscheinlich viele Gedanken gar nicht machen.

Wolfgang: Aber wir sprechen ja schon über große Systeme, über komplexe Systeme,

Wolfgang: die vielleicht eine einzelne Person gar nicht so super gut überblicken kann.

Wolfgang: Wie geht man denn da ran, wenn man so eine Rolle hat, Softwarearchitektin,

Wolfgang: dass man diese Entscheidung vielleicht so gut wie möglich trifft?

Wolfgang: Ist das nur die Erfahrung, die man irgendwie braucht, weil man schon 20 Jahre

Wolfgang: lang in der Branche unterwegs ist?

Ulrich: Also ich würde sagen, es ist eine Mischung auf jeden Fall. Natürlich ist Erfahrung,

Ulrich: also wirklich Hands-on-Entwicklungserfahrung in einer bestimmten Domäne,

Ulrich: ist absolut essentiell, um dann eben wirklich diese Rolle tatsächlich ausfüllen zu können.

Ulrich: Natürlich geht es auch darum, sich up-to-date zu halten, was eben Technologien

Ulrich: und auch Methodiktrends betrifft.

Ulrich: Und grundsätzlich ganz, ganz wichtig finde ich eben auch, dass das eben nie

Ulrich: Entscheidungen sind, die jetzt eine Person alleine trifft,

Ulrich: sondern dass eben ein ganz zentraler Punkt ist, dass diese Rolle Architekt,

Ulrich: Architektin, dass das was extrem kommunikationsintensives ist.

Ulrich: Das fängt eben bei den Anforderungen an, dass man überhaupt erstmal rauskitzelt,

Ulrich: was ist denn das, was am Ende wirklich relevant ist für die Architektur,

Ulrich: was wir auch dann erfüllen müssen am Ende,

Ulrich: weil das ist eben häufig nicht so klar oder liegt nicht auf dem Tisch,

Ulrich: sondern muss tatsächlich erhoben werden.

Ulrich: Und dass man zum anderen dann eben auch intensiv spricht eben mit anderen ArchitektInnen

Ulrich: oder schlicht und ergreifend auch mit den Mitgliedern der Entwicklungsteams

Ulrich: und sich da eben auch Input holt und dann eben wirklich auch eine gemeinsame

Ulrich: Entscheidungsfindung am Ende dann moderiert.

Wolfgang: Ja.

Marvin: Ja genau, das ist nämlich eben das Risiko, wenn wir rein von der technischen Variante drauf gucken,

Marvin: dann entscheiden wir jetzt vielleicht, okay, wir bauen jetzt eine riesige Microservice-Landschaft,

Marvin: weil das technisch cool ist,

Marvin: obwohl jetzt aber eigentlich wir irgendwie die Software für den Betrieb einer

Marvin: kleinen Stadtbibliothek umsetzen und das dann hinterher keiner betreiben kann

Marvin: und die sich auch das gar nicht leisten können.

Marvin: Also das Entscheidende ist wirklich zu gucken, was sind unsere Anforderungen

Marvin: und vor allem, was sind nicht unsere fachlichen Anforderungen,

Marvin: weil darin sind Product Owner heutzutage ja Weltmeister, rauszuschreiben,

Marvin: was der Kunde alles haben will, sondern eher das Wie.

Marvin: Wie erreichbar muss unser System sein? Wie viel darf es kosten?

Marvin: Erst wenn ich diese Fragen geklärt habe, kann ich einen, sag ich mal,

Marvin: fundierten technischen Entwurf machen.

Wolfgang: Das bedeutet dann aber, dass man auf der einen Seite natürlich diese technische

Wolfgang: Expertise benötigt, um Dinge auch einschätzen zu können.

Wolfgang: Um einschätzen zu können, ist es machbar vielleicht mit einer Technologie,

Wolfgang: was spricht vielleicht dafür, was spricht vielleicht aber auch dagegen,

Wolfgang: die eine Technologie, die andere Technologie einzusetzen.

Wolfgang: Das ist so der eine Teil, den man braucht. Darüber hinaus muss man aber auch

Wolfgang: sehr gut in der Fachdomäne irgendwie unterwegs sein,

Wolfgang: um die richtigen Fragen zu stellen und vielleicht um auch diese Menschen aus

Wolfgang: den Fachabteilungen richtig zu verstehen.

Ulrich: Würde ich definitiv bejahen. Also ich sage mal, es ist das Technische,

Ulrich: es ist das Methodische, dann eben auch wirklich die fachliche Domäne, die man kennt.

Ulrich: Und ich würde eine Sache noch ergänzen.

Ulrich: Am Ende, sage ich mal, die meiste Software, die wir am Ende entwickeln,

Ulrich: die erfüllt ja Geschäftsziele.

Ulrich: Also es gibt natürlich auch nicht kommerzielle Software, ganz klar,

Ulrich: aber der Großteil der Software, mit der wir zu tun haben, mit der soll am Ende

Ulrich: in irgendeiner Art und Weise Geld verdient werden.

Ulrich: Das heißt, das ist auch sowas, was ich eben immer im Hinterkopf haben sollte,

Ulrich: gerade auch wenn es darum geht, dann eben mit entsprechenden Stakeholdern zu reden.

Ulrich: Wie kann am Ende eine geeignete Architektur wirklich auch die Geschäftsziele

Ulrich: des Unternehmens unterstützen?

Ulrich: Weil das dann natürlich am Ende die wirtschaftlich und insgesamt erfolgreichen

Ulrich: Produkte dann häufig sind.

Wolfgang: Wo sortiert sich so ein Software-Architekt, so eine Software-Architektin dann überhaupt ein?

Wolfgang: Weil in modernen Projekten, die oftmals ja agil durchgeführt werden,

Wolfgang: da haben wir ja so ein paar etablierte Rollen.

Wolfgang: Wir haben den Scrum Master, wir haben den Product Owner, den hast du schon erwähnt, Marvin.

Wolfgang: Wir haben so ein Development Team mit Menschen, die eben halt die ganzen technischen

Wolfgang: Skills mitbringen und die Software schreiben.

Wolfgang: Wir haben oftmals noch eine Handvoll Stakeholder aus unterschiedlichsten Bereichen

Wolfgang: und wir haben ja schon dann den Product Owner und den Scrum Master und die hantieren

Wolfgang: ja schon irgendwie mit ganz vielen Bällen in der Luft,

Wolfgang: um Dinge zu klären, um Dicke abzustimmen.

Wolfgang: Wo sortiert sich denn da jetzt noch die Rolle Softwarearchitekter,

Wolfgang: Softwarearchitektin ein?

Marvin: Wenn wir davon ausgehen, wir haben einen dedizierten Architekt,

Marvin: Architektin, dann ist das, würde ich mal fast sagen, das technische Counterpart zum PO.

Marvin: Eben mit demselben Fokus auf Kommunikation, aber halt einfach mit einem anderen

Marvin: Blick auf die Anforderungen zu gucken und genau wie der Product Owner eben zwischen

Marvin: Team und Stakeholdern die Kommunikation zu organisieren.

Wolfgang: Das bedeutet, ich hätte dann zu meinem klassischen Projekt Setup noch eine zusätzliche Rolle.

Wolfgang: Eine Person, die dann auf der einen Seite sicherlich mit dem Entwicklungsteam

Wolfgang: kommuniziert, um da vielleicht technische Sachen auch ein bisschen abzuklären,

Wolfgang: auf der anderen Seite aber auch mit Stakeholdern kommuniziert und natürlich

Wolfgang: auch mit dem PO kommuniziert,

Wolfgang: um dann aus diesen ganzen Informationen so das Richtige rauszukondensieren.

Marvin: Exakt.

Ulrich: Und das bringt uns natürlich auch wieder in die Ecke, dass es ganz viele unterschiedliche

Ulrich: Ausprägungen geben kann von dieser Rolle.

Ulrich: Und das, was du jetzt angesprochen hast, das wäre jetzt wirklich eine Person,

Ulrich: die vielleicht Vollzeit nichts anderes macht als Architekturarbeit.

Ulrich: Gerade in einem überschaubaren Team kann es aber auch sehr gut sein,

Ulrich: dass man sagt, es gibt das gar nicht als eine dedizierte Person,

Ulrich: sondern man sieht das Ganze eher als Teamskill.

Ulrich: Oder vielleicht übernimmt viele von diesen Aufgaben dann eben auch eine Person,

Ulrich: die eher so eine Tech-Lead-Developer-Mütze irgendwo auf hat,

Ulrich: wo dann aber eben auch so Architekturthemen irgendwie drunter zu sehen sind.

Ulrich: Und dann gibt es natürlich auch Architekten, Rollen oder Ausprägungen davon,

Ulrich: die jetzt gar nicht direkt einem Entwicklungsteam zugeordnet sind,

Ulrich: sondern die vielleicht irgendwo auf höherer Ebene, sage ich jetzt mal,

Ulrich: im Unternehmen praktisch rumschwören.

Wolfgang: Ist das sowas wie dieser ominöse Enterprise-Architekt, den es oftmals in sehr,

Wolfgang: sehr großen Firmen gibt?

Ulrich: Das wäre eine Rolle. Was ich auch kenne, ist zum Beispiel sowas wie ein Schiefarchitekt,

Ulrich: wenn man jetzt beispielsweise größere Projekte hat, wo mehrere Entwicklungsteams

Ulrich: da sind und ich einfach eine Person praktisch haben will, die sich wirklich

Ulrich: um die Architekturbelange, die so teamübergreifend sind, dann kümmert.

Ulrich: Ja, praktisch eine Abgrenzung dann zu einer Rolle wie ein Teamarchitekt,

Ulrich: wo dann eben eine Person praktisch die Architekturaufgaben und auch die Schnittstelle

Ulrich: dann eben im Team bereitstellt.

Ulrich: Und dann gibt es teilweise auch noch so Rollen wie Plattformarchitekten zum Beispiel.

Ulrich: Also wenn ich eine plattformbasierte Entwicklung habe, dann gibt es da vielleicht

Ulrich: auch einfach, ja, dedizierte Architekten, Architektinnen, die auf dieser Ebene unterwegs sind.

Marvin: Genau, und wenn ich dann in meinen Kontext denke, haben wir da ganz oft die

Marvin: Rede von einem sogenannten Data-Architekt, dessen Aufgabe es ist,

Marvin: meistens auf unternehmensweiter Ebene dafür zu sorgen, dass,

Marvin: sag ich mal, Austauschformate, Schnittstellen und vielleicht auch Datenflüsse

Marvin: irgendwie geregelt sind.

Ulrich: Mhm.

Ulrich: Genau, und wo du das erwähnst, gibt es auch so andere Themen,

Ulrich: wo man sagt, da gibt es vielleicht spezialisierte Rollen.

Ulrich: Jemand, der sich jetzt mit Security zum Beispiel im Umfeld Architektur sehr,

Ulrich: sehr gut auskennt und da dann eben auch unterstützen, zum Beispiel in bestimmte

Ulrich: Projekte dann mit reingeht.

Wolfgang: Das wären jetzt aber schon so einzelne Personen, die dediziert für gewisse Bereiche

Wolfgang: verantwortlich sind, da vielleicht nicht jetzt alles nach gut dünken entscheiden,

Wolfgang: sondern viel Kommunikation betreiben,

Wolfgang: sich viele Meinungen einholen und dann das alles irgendwie zusammenbringen,

Wolfgang: um dann wahrscheinlich dann doch eine Entscheidung zu treffen.

Wolfgang: Also auch so einzelne Personen, die dann die Verantwortung haben für Security,

Wolfgang: für Data oder vielleicht auch für so eine Plattform.

Marvin: Vielleicht auch nicht unbedingt die Verantwortung haben, sondern vielleicht

Marvin: einfach einzelne Teams beraten und wenn wir daran denken, dass wir in hoffentlich

Marvin: agierenden Projekten unterwegs sind, trägt ja eigentlich an sich das Team die

Marvin: Verantwortung für den Code und für das Projekt.

Marvin: Da wäre wirklich ein interessantes Konzept, einfach Leute mit gewissen Skills

Marvin: dann eben eine Dauer auf dem Team zu haben oder die beratend reinkommen zu lassen,

Marvin: um mit dem Team über gewisse Problemkontexte zu diskutieren und bei einer Entscheidung zu helfen.

Wolfgang: Mhm.

Ulrich: Ja, und andere Ergänzung ist auch immer noch diese Abgrenzung Verantwortung

Ulrich: versus wer tut es oder wer es involviert.

Ulrich: Das heißt, in bestimmten Situationen ist es schon so, dass ich als Architekt,

Ulrich: als Architektin vielleicht so eine Gesamtverantwortung für die Architektur habe.

Ulrich: Aber das bedeutet jetzt eben nicht, dass ich alles selber entscheiden will,

Ulrich: sondern dass ich eben auch gucke, wer kann sich wo sinnvoll einbringen.

Ulrich: Also dass ich einfach die Leute, die eben das entsprechende Wissen haben,

Ulrich: um bestimmte Entscheidungen zu treffen oder zu unterstützen,

Ulrich: dass ich die eben auch ganz bewusst in diesen Entscheidungsprozess mit involviere.

Ulrich: Oder vielleicht auch sage gewisse Dinge. Da sage ich jetzt, okay,

Ulrich: das muss jetzt nicht ich entscheiden, sondern das ist vielleicht ein Thema,

Ulrich: wo ich einfach sage, Das entscheidet jetzt ein Entwicklungsteam beispielsweise

Ulrich: autonom, ohne dass da jetzt irgendein Chief- oder Plattformarchitekt reinredet.

Wolfgang: Ja, es ist oftmals ja auch relevant, dass Dinge einfach bewusst getan werden.

Wolfgang: Dass man bewusst sagt, okay, hier ist vielleicht irgendwie ein Bereich,

Wolfgang: da ist es völlig okay, wenn das Team das Beste macht, was das Team gut findet.

Wolfgang: Und vielleicht gibt es aber manche Themen wie Security, die vielleicht auch

Wolfgang: einheitlich sein sollten,

Wolfgang: weil man, ich weiß nicht, irgendwelche Guidelines befolgen muss,

Wolfgang: unternehmensweit oder weil es vielleicht gesetzliche Vorgaben gibt,

Wolfgang: die man vielleicht auch einhalten muss und man da sicherstellen möchte,

Wolfgang: dass dieser Teil von so einer Architektur auch dementsprechend ausgeprägt ist,

Wolfgang: dass es überall passt und dass man da nicht irgendwo ein Defizit hat.

Wolfgang: Passt das ungefähr so in eure Definition?

Marvin: Ja, das kann ja auch quasi auch noch mal als Definition von Softwarearchitektur

Marvin: gesehen werden, dass wir versuchen Leitplanken zu ziehen, ziehen die Teams den

Marvin: möglichst höchsten Freiheitsgrad erlauben, ohne dass wir dabei auf organisatorischer

Marvin: Ebene ins Chaos abdriften.

Ulrich: Mhm.

Wolfgang: Also ich finde das schon mal sehr, sehr spannend, weil das unterscheidet sich

Wolfgang: schon ein gutes Stück von dem, was ich irgendwie Anfang der 2000er gelernt habe,

Wolfgang: weil da gab es halt wirklich so diesen allwissenden Menschen,

Wolfgang: der dann wirklich gesagt hat, wie so ein König, ja, das machen wir so,

Wolfgang: hier machen wir so, hier brauchen wir eine Dreischichtenarchitektur,

Wolfgang: hier brauchen wir zwölf Schichten, Microservice gab es damals noch nicht.

Wolfgang: Und das finde ich sehr spannend und ich weiß gar nicht, wer es von euch beiden

Wolfgang: gesagt hat, aber das ist ja schon auch ein sehr agiles Vorgehen, oder?

Wolfgang: So, dass man da sagt, hey, wir müssen viel kommunizieren, wir müssen vielleicht

Wolfgang: irgendwo die besten Ideen rausarbeiten, wir müssen schauen, dass wir die ganzen

Wolfgang: Stimmen hören, wir übertragen Verantwortung an ein Team,

Wolfgang: wo es sinnvoll ist oder wir führen halt irgendwelche Entscheidungen zusammen.

Marvin: Ich glaube, der Hilfenbein-Architekt ist genau aus demselben Grund vom Aussterben

Marvin: bedroht, warum es der Wasserfall ist. Es funktioniert halt einfach nicht.

Marvin: Man kann nicht einfach irgendwie sich in einem Turm einschließen,

Marvin: die technischen Entscheidungen treffen und dann mit der Realität konfrontiert.

Wolfgang: Ja, Marvin, du nimmst mir jetzt schon meine obligatorische nächste Frage weg

Wolfgang: zu einem Großteil, denn wenn man über Softwarearchitektur spricht und man jetzt

Wolfgang: vielleicht selbst nicht so tief in der Softwareentwicklung drinsteckt,

Wolfgang: da drängt sich einem ja oft diese Frage auf, ist das nicht dasselbe wie die

Wolfgang: Architektur bei einem Haus?

Wolfgang: Und da ist es ja so, ich bin Architekt, ich sperre mich irgendwo ein,

Wolfgang: ich plane alles, ich habe vielleicht noch irgendwie Unterstützung für die Statik

Wolfgang: und dann ist der Plan fertig und dann kann das dann irgendwie gebaut werden.

Wolfgang: Und da drängt sich, finde ich, oft so die Frage oder der Vergleich auf,

Wolfgang: ist das bei der Software nicht auch so? Ich bin im Elfenbeinturm,

Wolfgang: da hat man eine schöne Aussicht da oben.

Wolfgang: Ich plane alles und dann gebe ich den Plan raus und dann wird es halt ausprogrammiert

Wolfgang: und dann passt. Aber da hast du mir jetzt die Antwort schon vorher gegeben.

Ulrich: Also ich würde mal sagen, auch als Häuslebauer

Ulrich: bist du mit einem Elfenbeinturmarchitekten auch nicht glücklich.

Ulrich: Auch da ist die Interaktion und die Abstimmung wichtig.

Ulrich: Ja, diese, ich sage mal, diese Metapher oder dieser Vergleich ist ja schon durchaus kontrovers.

Ulrich: Also es gibt ja auch so die Idee, dass so ein Architekt eher so in Richtung

Ulrich: Landschaftsarchitekt geht, weil es einfach irgendwo insgesamt praktisch alles formbarer ist.

Ulrich: Dass eben auch so, was weiß ich, wie ich jetzt irgendwie einen Park zum Beispiel

Ulrich: auch irgendwo anlege, dass das dann eben auch was ist, was sich ständig ändert,

Ulrich: wo ich vielleicht auch auf irgendwelche Änderungen reagieren muss,

Ulrich: dass vielleicht, so wie wir es momentan angelegt haben, bestimmte Anforderungen

Ulrich: nicht erfüllt sind und dann wird halt mal irgendwo ein Beet neu angelegt zum Beispiel.

Ulrich: Und das ist natürlich, was in der Software eher geht, als wenn wir jetzt eben

Ulrich: wirklich an Gebäudearchitektur denken, Ja, weil da reiße ich eben nicht so mal

Ulrich: eben das Fundament unten raus und ersetze es durch was anderes.

Marvin: Und zweitens bewegen wir uns im Softwareprojekt ja häufig in,

Marvin: sage ich mal, etwas neueren oder nicht komplett ausgewürfelten Themen.

Marvin: Ich meine, Häuser bauen wir jetzt als Menschheit seit 5000 Jahren vielleicht

Marvin: und Statik ist, glaube ich, physikalisch ziemlich ausgefuchstes Thema.

Marvin: Aber wenn wir jetzt dann denken, dass irgendwelche Businessprozesse neu leben

Marvin: und sich vielleicht eine Organisation weiterentwickelt, dann hat man wahrscheinlich

Marvin: immer teilweise rapide Änderungen, auf die man reagieren muss.

Wolfgang: Ja, also ich finde, das ist halt super wichtig, weil Hausbau ist halt kompliziert

Wolfgang: und Statik ist auch kompliziert, aber halt nicht komplex, so wie Softwareentwicklung.

Wolfgang: Und bei einer Statik, jo, die rechne ich durch. Und wenn ich irgendwann mal

Wolfgang: vielleicht später noch einen Balkon an mein Haus ranzimmern will,

Wolfgang: dann kann ich es ausrechnen und kann sagen, ja, funktioniert.

Wolfgang: Oder Haus abreißen, neues Haus hinbauen, können Sie sich ausdenken.

Wolfgang: Aber vielleicht machen Sie sich lieber eine schöne Terrasse hin,

Wolfgang: das ist günstiger. Und Software ist ja durch den ganzen agilen Gedanken ja von

Wolfgang: vornherein irgendwie so ausgelegt,

Wolfgang: dass sie im Wandel ist und dass es immer wieder zu Änderungen kommen kann.

Wolfgang: Und ich glaube, die spannende Frage ist natürlich bei Software vielleicht,

Wolfgang: wie teuer wird es denn, wenn sich grundlegend was verändert?

Wolfgang: Aber so diese Agilität und Dynamik, die ist ja irgendwie schon generell drin,

Wolfgang: oder? In der Softwareentwicklung. Vielen Dank.

Ulrich: Also ich glaube, was man halt schon berücksichtigen muss, ist,

Ulrich: dass auch Architektur dann wiederum was ist, was Agilität ermöglicht.

Ulrich: Also sozusagen auf architektureller Ebene kann ich eben auch Grundlagen schaffen,

Ulrich: damit es dann eben möglich ist, eine Software am Ende in eine bestimmte andere

Ulrich: Richtung praktisch weiterzuentwickeln oder zu verändern.

Ulrich: Das heißt, da gibt es schon Dinge, wo ich mir wahrscheinlich auch dann relativ

Ulrich: frühzeitig schon mal Gedanken machen muss, Weil manche Dinge lassen sich im

Ulrich: Nachgang leicht ändern, andere Dinge sind entsprechend teuer.

Ulrich: Das heißt, auch genau da dann eben so diese Entscheidung oder diese Abwägung

Ulrich: zu machen, wann ist jetzt für eine bestimmte Art von Architekturentscheidung

Ulrich: der richtige Zeitpunkt? Also was sollte ich vielleicht relativ frühzeitig mal berücksichtigen?

Ulrich: Und was sind andererseits halt Punkte, wo wir sagen, ja, da wird sich auch viel

Ulrich: verändern im Laufe der Zeit.

Ulrich: Und da müssen wir jetzt vielleicht auch noch gar nicht ultimativ jetzt irgendwelche

Ulrich: Entscheidungen festzurren, sondern können da auch einfach gucken,

Ulrich: wie sich das ganze Projekt, wie sich die Anforderungen weiterentwickeln.

Marvin: Um das vielleicht mal mit einem praktischen Beispiel zu beleben.

Marvin: Wenn wir so eine klassische Dreischichtarchitektur nehmen und wir haben unsere

Marvin: Datenbank sauber gekapselt, dann haben wir im Projekt immer noch die Möglichkeit,

Marvin: unsere Datenbank zur Not auszutauschen, ohne allzu viel von der Software bei

Marvin: Mitleidenschaft zu ziehen.

Marvin: Stattdessen, wenn wir in unserer UI-Layer die Datenbank direkt ansprechen und

Marvin: wir versuchen, die Datenbank auszutauschen, dann wird das schein höllisch aufwendiger.

Marvin: Und das hat genauso was, wo Architektur helfen kann.

Wolfgang: Wie geht man denn jetzt in einem Projekt ran, wenn man jetzt nicht dediziert diese Rolle hat?

Wolfgang: Weil ich kann mir vorstellen, in vielen Projekten ist es erstmal eine Hürde,

Wolfgang: eine zusätzliche Person zu haben und vielleicht braucht man es auch nicht,

Wolfgang: wenn das Projekt nicht so riesengroß ist.

Wolfgang: Also gerade die Projekte, in denen ich in den vielleicht, weiß nicht,

Wolfgang: letzten zehn Jahren gearbeitet habe, die meisten davon waren nicht so riesengroß.

Wolfgang: Also so 20-Personen-Projekte waren da eher die Seltenheit.

Wolfgang: Viele Projekte, in denen ich tätig war, da gab es so irgendwie drei Leute,

Wolfgang: die entwickelt haben, vielleicht auch mal fünf, sechs Leute.

Wolfgang: Und dann lief so ein Projekt ein Jahr oder zwei Jahre, bis man mal so ein erstes

Wolfgang: marktfähiges Release hatte.

Wolfgang: Und da wäre es oftmals wahrscheinlich schwierig gewesen, jetzt noch eine Person

Wolfgang: mit reinzunehmen, die dediziert sich um sowas kümmert.

Wolfgang: Zum einen, weil es ein Kostenfaktor ist, natürlich.

Wolfgang: Zum anderen, weil vielleicht gar nicht so super viel Arbeit da ist,

Wolfgang: wenn das Projekt nicht so riesengroß ist.

Wolfgang: Deswegen frage ich mich jetzt oder ich frage euch deswegen, ich habe ja zwei Experten hier vor mir,

Wolfgang: wie kann man denn in der normalen, in Anführungszeichen, klassischen agilen

Wolfgang: Softwareentwicklung beispielsweise nach Scrum vorgehen,

Wolfgang: um auch jetzt so diese ganzen Softwarearchitektur-Gesichtspunkte irgendwie adäquat zu berücksichtigen.

Wolfgang: Und ich meine, was du jetzt gerade als Beispiel gebracht hast,

Wolfgang: Marvin, das ist der Klassiker, diese Dreischichtarchitektur.

Wolfgang: Da hat man mir im Studium damals auch schon gesagt, hey, das ist voll gut,

Wolfgang: da kann man dann die Datenbank austauschen, wenn man zum Beispiel auch so einen

Wolfgang: OR-Mapper nimmt. Das war damals ziemlich cool.

Wolfgang: Der neueste Schrei irgendwo. Ich habe es jetzt nie erlebt, dass die Datenbank

Wolfgang: ausgetauscht wurde, aber es war immer ein schönes Gefühl zu wissen, es ist möglich.

Wolfgang: Es ist möglich.

Ulrich: Ja, also ich würde erst mal damit anfangen, wie wir schon gesagt haben vorhin,

Ulrich: dass es eben nicht unbedingt dedizierte Personen geben muss,

Ulrich: sondern dass es eben auch ein Teamskill einfach sein kann, also dass wir Architektur

Ulrich: wirklich als Teamverantwortung sehen.

Ulrich: Das setzt eben ein gewisses Bewusstsein voraus, bestimmte Skills,

Ulrich: die man durch Training oder was auch immer natürlich auch bekommen kann,

Ulrich: dass man einfach ein Gefühl dafür bekommt, okay, wie gehe ich eigentlich methodisch

Ulrich: sinnvoll vor, um zu entscheiden,

Ulrich: was sind die Architekturthemen, mit denen ich mich jetzt beschäftigen sollte

Ulrich: und wie treffe ich dann eben nachvollziehbar Entscheidungen und alles,

Ulrich: was dann an der Stelle noch dranhängt.

Ulrich: Also das wäre erstmal der Punkt, dass man wirklich sagt, nein,

Ulrich: es gibt nicht zwangsläufig eben eine dedizierte Person, sondern das kann auch

Ulrich: einfach aufgeteilt sein.

Ulrich: Und zum anderen ist natürlich auch die Frage, wie plane ich dann jetzt in so

Ulrich: einem agilen Umfeld Architekturarbeit,

Ulrich: weil das ist ja so ein bisschen eine Gefahr, dass das Backlog vielleicht sehr

Ulrich: feature-zentrisch ist und da am Ende eben genau diese Architekturthemen keinen Platz finden.

Ulrich: Aber dass wir da eben auch sagen, wenn es bestimmte Themen gibt,

Ulrich: Lösungskonzepte zum Beispiel, die einfach zu einem bestimmten Zeitpunkt entwickelt werden müssen,

Ulrich: weil einfach viel weitere Arbeit drauf aufbaut, dass das dann eben auch was

Ulrich: ist, was wir entsprechend in unserem Backlog einplanen und dann auch priorisieren.

Ulrich: Und da dann eben auch genau mit dieser Architekturbrille sozusagen,

Ulrich: dass wir eben sagen, okay, was sind denn jetzt hochpriore Architekturthemen

Ulrich: und was sind vielleicht andere Themen, die einfach zu einem späteren Zeitpunkt

Ulrich: relevant werden können.

Wolfgang: Dann brauche ich im Team aber auch die richtigen Leute, die hier die Brille

Wolfgang: aufhaben für das Thema Softwarearchitektur.

Wolfgang: Und ich brauche Leute, die im richtigen Moment dann auch irgendwie die Hand

Wolfgang: heben und sagen, hey, hier müssen wir mal drüber sprechen, ob das für dich die

Wolfgang: beste Entscheidung ist.

Wolfgang: Da muss man wahrscheinlich nachfragen, hey, was habt ihr sonst noch für Ideen?

Wolfgang: Also was habt ihr sonst noch für Pläne? Weil hier ist vielleicht ein kritischer

Wolfgang: Punkt, da müssen wir jetzt eine Entscheidung treffen.

Wolfgang: Und ich brauche zusätzlich natürlich auch einen Product Owner,

Wolfgang: der das Verständnis hat und der nicht nur auf seine Features guckt.

Wolfgang: Was ich durchaus schon erlebt habe in Projekten, dass Product Owners sehr,

Wolfgang: sehr featurezentrisch unterwegs waren.

Wolfgang: Und da war es oftmals sehr schwer, so irgendwie zu vermitteln,

Wolfgang: hey, wir haben hier eine technische Story.

Wolfgang: Da sieht man später erstmal nichts im Review, aber das ist voll gut,

Wolfgang: weil es uns mehr Stabilität bringt oder irgendwie was anderes bringt,

Wolfgang: von dem wir später profitieren.

Marvin: Ich finde so, Kommunikation mit dem Backlog raus sind ja effektiv meistens das,

Marvin: was uns retten kann, ja wirklich Qualitätskriterien und Qualitätsszenarien,

Marvin: weil wenn die quasi mit dem Backlog getrackt sind und so der Product Owner auch versteht, okay,

Marvin: wir müssen das jetzt nicht machen, weil wir sagen, es ist ein technisches Feature,

Marvin: sondern wir müssen das machen, weil das zahlt auf unsere SLAs ein,

Marvin: die Software muss hochverfügbar sein, deswegen müssen wir das jetzt tun,

Marvin: um unser Szenario erfüllen zu können.

Marvin: Dann hat auch der Product Owner das leichter, das einzuplanen und abzuwägen,

Marvin: brauche ich jetzt das Feature oder muss ich jetzt gucken, dass ich meine Qualitätsanforderungen erfülle?

Marvin: Und ich finde da auch, da müssen wir auch bei der Weiterbildung des Teams nicht

Marvin: nur die Entwickler, sondern potenziell auch eben den PO und auch den Scrum Master,

Marvin: mit ausbilden in Richtung Architektur, weil ich finde, erst wenn das komplette

Marvin: Team da die Brille drauf hat, kannst du aber wirklich die Skills und die Synergien des Teams,

Marvin: verwenden, weil vielleicht ist der PO auch generell besser darin,

Marvin: Qualitätsanforderungen zu erheben, weil er eh schon weiß, wie er Anforderungen erheben soll.

Marvin: Und im Team hast du dann sicherlich Entwickler mit verschiedenen Spezialisierungen,

Marvin: wo der eine dann Frontend-Architekturentscheidung besser treffen kann als der

Marvin: andere Backend-Architekturentscheidung.

Wolfgang: Jetzt musst du aber ganz kurz noch zwei Begriffe erklären, Marvin,

Wolfgang: die du gerade sehr selbstsicher verwendet hast.

Wolfgang: Und zwar, ich habe es mir aufgeschrieben, Qualitätskriterien und Qualitätsszenarien.

Wolfgang: Was genau verstehst du denn darunter?

Marvin: Genau, also das leitet sich ja beides ab aus eben der Tatsache,

Marvin: dass wir in einem Softwareprojekt nicht nur fachliche Anforderungen haben,

Marvin: sondern eben auch qualitative oder

Marvin: anders genannt auch nicht funktionale Anforderungen, die eben beschreiben,

Marvin: unser System soll wartbar sein, unser System soll irgendwie erweiterbar sein, verfügbar sein.

Marvin: Eben solche Eigenschaften von einem System, die man nicht so einfach greifen

Marvin: kann wie einzelne Features, jeweils das System bezeichnen,

Marvin: Entweder funktionieren lassen oder halt nicht, wenn sie nicht da sind.

Marvin: Und um sowas ein bisschen zu systematisieren und greifbar zu machen,

Marvin: hat man sich da das sogenannte Qualitätsszenario ausgedacht,

Marvin: was dann einfach sagt, okay,

Marvin: nicht unser System muss schnell sein, sondern unser System muss innerhalb von

Marvin: 100 Millisekunden auf eine Nutzeranfrage antworten, dass du halt eine,

Marvin: sag ich mal, messbare Größe hast, die du auch irgendwie testen kannst,

Marvin: die halt auf deine Qualitäten, die du haben willst, irgendwie einzahlt.

Wolfgang: Okay, das klingt auf jeden Fall nachvollziehbar, denn ich meine,

Wolfgang: die nicht funktionale Anforderung, das System muss wartbar sein,

Wolfgang: da habe ich noch nie irgendwie jemanden erlebt, der gesagt hat,

Wolfgang: nö, unser System muss nicht wartbar sein.

Wolfgang: Was bedeutet das, Wartbarkeit? Ja, muss wartbar sein.

Wolfgang: Also das finde ich super, wenn man das so ein bisschen konkretisiert,

Wolfgang: weil dann kannst du ja wirklich draufschauen.

Wolfgang: Wenn du zum Beispiel hast, irgendwie 100 Millisekunden Antwortzeit für eine

Wolfgang: User-Interaktion, dann kann man ja draufschauen.

Wolfgang: Sind es 100, sind es 200, sind es nur 95?

Wolfgang: Und dann kannst du ja wirklich sagen, das passt oder das passt nicht.

Wolfgang: Und das macht es ja auch wirklich einfacher, da zu wissen, wo man steht.

Ulrich: Und das hat halt auch den Vorteil, dass es wirklich greifbar und konkret ist

Ulrich: und das ist auch für Stakeholder hilfreich.

Ulrich: Ja, weil im Prinzip jetzt mit sehr abstrakten Metriken zu arbeiten,

Ulrich: ist dann auch schwierig.

Ulrich: Aber wenn ich jetzt wirklich sagen kann, okay, es passiert jetzt dieses und

Ulrich: jenes Ereignis und innerhalb von so und so vielen Millisekunden soll mein System darauf reagiert haben,

Ulrich: dann ist das eben was, was wirklich konkret und greifbar ist und damit dann

Ulrich: eben zum Beispiel auch priorisiert werden kann.

Ulrich: Ja, weil mein Beispiel ist immer, ja, ist jetzt Wartbarkeit oder Security wichtiger?

Ulrich: Das kann man jetzt nicht wirklich beantworten, aber wenn ich jetzt eben wirklich

Ulrich: konkrete Wartbarkeitsanforderungen habe und konkrete Security-Anforderungen

Ulrich: habe, dann bin ich eben auch in der Lage, die entsprechend zu priorisieren.

Wolfgang: Ja, das ist auf jeden Fall super, wenn es greifbar ist und wenn es messbar ist,

Wolfgang: weil dann kann ich ja auch mir irgendwie, keine Ahnung, zeitliche Verläufe und

Wolfgang: Statistiken anschauen,

Wolfgang: kann schauen, ob ich besser geworden bin, kann schauen, oh,

Wolfgang: wie sieht es in den letzten drei Monaten aus, vielleicht bin ich irgendwo schlechter

Wolfgang: geworden, muss ich da vielleicht das mehr Fokus drauf packen,

Wolfgang: weil in den anderen Bereichen bin ich super dick im grünen Bereich,

Wolfgang: das ist erstmal vielleicht gar nicht so wild, wenn es ein bisschen schlechter

Wolfgang: wird, weil es immer noch sehr, sehr gut ist.

Marvin: Es schlägt auch wieder eine Brücke zurück, warum der Elfenbeinturm nicht funktioniert,

Marvin: weil wenn ich mich alleine einschließe und versuche irgendwie die Qualitätsszenarien

Marvin: für ein System irgendwie mir aus den Fingern zu saugen, hätte ich die Hälfte vergessen.

Marvin: Aber wenn es das Team gemeinschaftlich macht, auch mit den Stakeholdern und

Marvin: mit den Product Ownern, vielleicht im Rahmen meines irgendwie gearteten Workshops,

Marvin: dann habe ich eine viel bessere Chance, dass ich irgendwie alle Facetten meines

Marvin: Systems zumindest irgendwie mal anschneide und priorisieren kann.

Wolfgang: Ja, ich meine, ich weiß nicht, ob ihr schon in eurem Leben vielen Universalgenies

Wolfgang: begegnet seid. Also ich bin es noch nicht.

Wolfgang: Es wird immer wieder davon gesprochen, dass es doch solche Leute gibt,

Wolfgang: die alles irgendwie extrem gut können.

Wolfgang: Ich glaube aber persönlich, das ist eine Illusion und je stärker man sich davon

Wolfgang: löst und hingeht zum Team,

Wolfgang: ich glaube, desto mehr profitiert man davon, denn mir geht es so oft so,

Wolfgang: wenn ich irgendwie mit Teams zu tun habe und ich persönlich irgendwie eine Meinung

Wolfgang: habe oder eine Überzeugung und glaube, so geht es richtig und dann mit Teams

Wolfgang: oder mit mehreren Personen drüber spreche,

Wolfgang: es passiert so oft, dass ich mir danach denke, ja cool, jetzt habe ich was dazugelernt.

Wolfgang: War vielleicht komplett falsch, was ich dachte oder war zu 30 Prozent falsch,

Wolfgang: aber ich bin noch nie gefühlt aus irgendeinem Termin rausgegangen und habe gedacht,

Wolfgang: boah, also ich wusste alles am aller allerbesten, war Zeitverschwendung.

Ulrich: Also wo ich auch nochmal anknüpfen würde, du hast ja vorhin die Frage gestellt,

Ulrich: wie ist es denn jetzt, wenn ich ein sehr kleines Entwicklungsteam habe,

Ulrich: wo jetzt vielleicht gar nicht eine Person als Vollzeit-Architekt,

Ulrich: Architektin wirklich machbar ist.

Ulrich: Was da zum einen mal ein Modell ist, dass man sagt, man kann sich natürlich

Ulrich: auch punktuell unterstützen lassen, ja, von eben zum Beispiel mal Know-how sozusagen

Ulrich: abzwacken von erfahrenen Architektinnen oder dass man eben auch sagt,

Ulrich: über jetzt Projekte oder Teams hinweg, dass man zum Beispiel sowas wie eine

Ulrich: Architecture Community of Practice etabliert, wo man eben sagt,

Ulrich: okay, wir haben hier ein Thema,

Ulrich: mit dem wir gerade ein bisschen am strugglen sind vielleicht.

Ulrich: In unserem Projekt und dass man dann eben schaut, okay, was haben zum Beispiel

Ulrich: andere Teams oder andere EntwicklerInnen eben für Erfahrungen gemacht in dem Umfeld,

Ulrich: dass man eben wirklich auch in der Lage ist, da sozusagen das Wissen der anderen auch anzuzapfen.

Ulrich: Dass das eben nicht alles jetzt was ist, was so ein Zwei-, Drei-Personen-Team

Ulrich: irgendwie alleine stemmen muss, sondern dass man da eben auch sich praktisch

Ulrich: die Unterstützung von anderen Teams holt.

Wolfgang: So eine Community of Practice, die du gerade erwähnt hast, das ist letztendlich

Wolfgang: so eine Interessengemeinschaft oder so eine Community von Leuten,

Wolfgang: die dasselbe machen, die sich darüber austauschen und dann von ihren Erfahrungen profitieren.

Wolfgang: Ist das was, was hauptsächlich unternehmensintern funktioniert?

Wolfgang: Das heißt, wenn ich jetzt ein riesengroßes Unternehmen habe,

Wolfgang: wo es super viele Teams sind, dass ich da sowas etabliere?

Wolfgang: Oder funktioniert es auch bei kleineren Unternehmen unabhängig davon,

Wolfgang: also als Meetup-Format vielleicht?

Wolfgang: Habt ihr da Erfahrung?

Marvin: Du hast ja schon ein Format reingestreut mit den Meetups und es gibt ja auch

Marvin: andere Beispiele, zum Beispiel sowas wie Java oder Golang, Usergruppen, Internetforen etc.

Marvin: Also es gibt heutzutage, denke ich, viele Möglichkeiten, sich da auch von außen

Marvin: noch Ressourcen ranzuholen und sich in größere Communities mit zu integrieren

Marvin: als kleines Unternehmen vielleicht.

Ulrich: Ja, also ich glaube, es sind auch einfach zwei Dinge, die sich ergänzen können.

Ulrich: Also gerade das Externe mit einem Meetup-Format hat natürlich dann einfach den

Ulrich: Vorteil, dass man sozusagen aus der eigenen Unternehmenssuppe vielleicht nochmal

Ulrich: draußen ist und ein paar Impulse wirklich von außen bekommt.

Ulrich: Und auf der anderen Seite kann so eine interne Community of Practice natürlich

Ulrich: super hilfreich sein, weil man einfach offener mit seinen konkreten Problemstellungen

Ulrich: kommen kann, was jetzt dann eben bei einem Meetup-Format nicht so funktioniert,

Ulrich: wo man vielleicht erstmal sehr viel tun müsste,

Ulrich: um Dinge irgendwie zu abstrahieren, weil es einfach Dinge gibt,

Ulrich: über die man jetzt auf einem offenen Meetup vielleicht nicht reden kann.

Wolfgang: Ja klar, wenn man da mit anderen Leuten außerhalb des Unternehmens spricht,

Wolfgang: dann muss man natürlich schon immer ganz gut überlegen, was man da jetzt preisgeben

Wolfgang: darf, muss gegebenenfalls Dinge anonymisieren, vereinfachen und dann wird alles

Wolfgang: natürlich auch ein bisschen unschärfer.

Wolfgang: Wenn ich euch jetzt aber so richtig verstanden habe, dann geht es beim Thema

Wolfgang: Software-Architektur zu einem

Wolfgang: sehr großen Teil um Kommunikation mit verschiedensten Personengruppen,

Wolfgang: Stakeholder, Product Owner, Entwicklungsteam etc.

Wolfgang: Gewürzt oder kombiniert mit einer gewissen Erfahrung, dass man eben halt auch

Wolfgang: schon andere Projekte gesehen hat. Ich glaube, das ist immer super wertvoll.

Wolfgang: Aus Büchern lernt man oftmals nicht so viel wie aus Projekten,

Wolfgang: wo man wirklich live dabei war.

Wolfgang: Und dann aber auch noch, Marvin, was du angeschnitten hast, ja,

Wolfgang: gehört noch was Methodisches dazu, oder?

Wolfgang: Also du hast das mit diesen Qualitätskriterien, mit diesen Qualitätsszenarien gesagt.

Wolfgang: Ich meine, da gehört sicherlich auch ein bisschen Übung dazu,

Wolfgang: dass man sowas vielleicht korrekt formuliert.

Wolfgang: Ich habe im Kopf so ein bisschen das Beispiel, wenn man anfängt,

Wolfgang: irgendwie agil zu arbeiten, da geht es hier um diese ominösen User-Stories.

Wolfgang: Und wenn Leute zum allerersten Mal sowas machen, dann ist das super holprig.

Wolfgang: Und wenn man sich ein Projekt anschaut, so die ersten Storys,

Wolfgang: die irgendwie so ein Product Owner vielleicht geschrieben hat versus Storys so ein Jahr später,

Wolfgang: dann ist da meistens ein großer Unterschied, weil die Erfahrung ist da,

Wolfgang: man hat vielleicht die Methodik ein bisschen besser verinnerlicht und so weiter und so fort.

Wolfgang: Und ich würde sagen, was du da jetzt so ein bisschen angeschnitten hast,

Wolfgang: das ist doch dann sicherlich auch was, was man lernen muss bzw.

Wolfgang: Sollte oder kann.

Marvin: Ja, definitiv. Also es gibt da glücklicherweise mittlerweile,

Marvin: sag ich mal, so einen systematischen Methodenkopfer, wo über die Jahre jetzt

Marvin: viele schlaue Köpfe sich hingesetzt haben und Sachen zusammengeschrieben haben,

Marvin: Sachen zusammengetragen haben, die gut funktionieren.

Marvin: Wenn man da, sag ich mal, einen sehr niederschwelligen Einstieg haben will,

Marvin: man ist jetzt ein neues Team und sagt jetzt mal, wir wollen jetzt mal ein bisschen

Marvin: Softwarearchitektur machen diesmal, kann sich zum Beispiel einfach mal das ARC-42-Template

Marvin: nehmen, so als wirklich grundlegende Einstiegsmethode.

Marvin: Das ist erstmal ein Template für Architekturdokumentation, aber da stehen halt

Marvin: genau solche Dinge wie zum Beispiel eben Qualitätsszenarien als Beispiele drin,

Marvin: an denen man sich so ein bisschen entlanghangeln kann, wie man denn da vorgehen würde.

Wolfgang: Und das ist letztendlich dann schon, wie du es gesagt hast, ein Einstieg,

Wolfgang: wo man sagen kann, hey, das ist ein Startpunkt, damit fangen wir mal an.

Wolfgang: Das ist auf jeden Fall dann schon mal so eine grundsätzliche Sammlung von verschiedenen

Wolfgang: Gesichtspunkten oder Bereichen, die man da dann berühren muss,

Wolfgang: weil es eben halt im Template drin ist.

Marvin: Genau, wenn man dann versucht, sich da vielleicht ein bisschen systematischer

Marvin: vorzubilden, dann haben wir in Deutschland ja das Glück, dass wir hier den Isa

Marvin: QB haben, der sich da viel Gedanken gemacht hat zum Thema, wie mache ich eigentlich

Marvin: Softwarearchitektur und wie vermittle ich anderen Leuten Softwarearchitektur?

Marvin: Ich glaube, das wäre jetzt die ideale Stelle, um mal an den Uli zu übergeben.

Wolfgang: Denn der Uli hat es schon angeteasert, als er sich vorhin vorgestellt hat,

Wolfgang: ungefähr vor einer Dreiviertelstunde.

Wolfgang: Uli, was steckt denn hinter diesen vielen Buchstaben, die ich jetzt nicht wiederholen

Wolfgang: werde, weil ich sie definitiv durcheinander bringe?

Ulrich: Ja, da gibt es ganz viele Buchstaben. Also erstmal ISAQB steht für International

Ulrich: Software Architecture Qualification Board.

Ulrich: Das ist aktuell ein Verein von eben ExpertInnen, sowohl aus Trainingsunternehmen,

Ulrich: aus der Industrie, auch aus dem universitären Umfeld.

Ulrich: Und letztlich hat sich die ISACOB eben das Ziel gesetzt, die Ausbildung von

Ulrich: SoftwarearchitektInnen zu verbessern.

Ulrich: Und dafür gibt es dann so ein Zertifizierungsschema, den CPSR,

Ulrich: Certified Professional for Software Architecture,

Ulrich: der eben ja einen Rahmen praktisch bereitstellt, um sich eben im Bereich Architektur

Ulrich: weiterzubilden und da gibt es zum einen mal diesen CPSR Foundation Level,

Ulrich: das ist eben ein Grundlagentraining,

Ulrich: wo im Grunde genommen wirklich diese Grundlagen der methodischen Architekturarbeit vermittelt werden.

Ulrich: Also wirklich von sozusagen der Anforderung dann eben bis zu der daraus abgeleiteten

Ulrich: Architekturentscheidung, auch wie halte ich Dinge fest, wie kommuniziere ich sie,

Ulrich: weil es ist ja schön, wenn ich mir was überlegt habe, aber wenn es niemand anders

Ulrich: dann im Projekt irgendwo weiß oder versteht, ist auch wenig geholfen.

Ulrich: Also auch so dieses ganze Thema Dokumentation und Kommunikation spielt da auch

Ulrich: eine wesentliche Rolle.

Wolfgang: Aber wenn ich kurz einhaken darf, da geht es dann um die ganzen methodischen

Wolfgang: Skills, die man in diesem Kurs lernt.

Wolfgang: Also da geht es nicht um konkrete technologische Dinge, die man vielleicht dann

Wolfgang: im Projekt benötigt, sondern es geht um die Methodik, dorthin zu kommen,

Wolfgang: Entscheidungen überhaupt zu treffen.

Ulrich: Genau, also das ist der Foundation-Level und dann gibt es eben drauf aufbauend

Ulrich: den Advanced-Level und da kann

Ulrich: man sich dann eben in sehr unterschiedliche Richtungen weiterentwickeln.

Ulrich: Das heißt, da gibt es ein großes Portfolio von Modulen, roundabout 20 Advanced-Level-Module

Ulrich: aktuell, wo ich mir eben praktisch rauspicken kann, was für mich relevant ist.

Ulrich: Ja, und das können eben zum Beispiel Module sein, die auch primär in eine Methodikrichtung gehen.

Ulrich: Also, wenn ich mich in Architekturdokumentation oder Architekturbewertung zum

Ulrich: Beispiel vertiefen will, gibt es da entsprechende Module.

Ulrich: Es gibt auch ein Modul, wo es rein um das Thema Soft Skills geht und dann gibt

Ulrich: es auf der anderen Seite Module, die dann schon eher in eine technische Richtung

Ulrich: gehen, also zum Beispiel das Embedded-Modul, wo es dann eben um eingebettete Systeme geht.

Ulrich: Dann aber auch sowas wie Flex, wo es um flexible Architekturen geht,

Ulrich: also sowas wie Microservice-Architekturen zum Beispiel oder auch sowas wie Cloud-Infra,

Ulrich: wo es dann eben um Infrastruktur für Cloud-Native-Systeme geht.

Ulrich: Das heißt, da kann ich dann wirklich schauen, okay, was ist für mich praktisch sinnvoll.

Ulrich: Dann picke ich mir praktisch als Grundlage dann für meine Advanced Level Zertifizierung

Ulrich: dann eben typischerweise drei Schulungen raus,

Ulrich: die für mich eben relevant sind, die ich dann eben wirklich auch in meiner Arbeit

Ulrich: einsetzen kann oder anwenden kann.

Ulrich: Und dann kann ich praktisch im Anschluss daran dann tatsächlich diese Zertifizierung

Ulrich: zum Advanced Level machen, die dann in Form von so einer Hausarbeit,

Ulrich: Fallstudie im Endeffekt abläuft.

Wolfgang: Und wie viele solche Module gibt es denn da insgesamt?

Wolfgang: Du hast es ein paar erwähnt, zum Beispiel dieses Embedded-Modul oder dieses Cloud-Native-Modul.

Wolfgang: Wie groß ist da dieser ganze Blumenstrauß an unterschiedlichsten Facetten?

Ulrich: Also so 20 plus minus kommt immer mal wieder eins dazu.

Ulrich: Ganz selten fällt auch mal eins weg, weil es vielleicht ein Thema ist,

Ulrich: was nicht mehr so relevant ist.

Ulrich: Und es gibt eben auch Module, die dann eher so verschiedene Kompetenzbereiche

Ulrich: streifen, also Agile haben wir auch schon drüber gesprochen.

Ulrich: Das wäre eben auch eines, wo dann eben Soft-Skill-Aspekte drin sind und dann

Ulrich: eben methodische Aspekte drin sind, also wo sich dann einfach verschiedene Themen,

Ulrich: verschiedene Kompetenzbereiche auch drin wiederfinden.

Wolfgang: Und diese Zertifizierung, die du jetzt angesprochen hast, dieses Advanced Level

Wolfgang: Zertifizierung hieß es, glaube ich,

Wolfgang: ist das dann so das Höchste, was man machen kann, wenn man jetzt in diesem Bereich

Wolfgang: weitermachen möchte oder ist das irgendwie so eine Zwischenstufe und es gibt

Wolfgang: darüber noch den Super Advanced Level oder Enterprise Level oder irgendwas anderes?

Ulrich: Also es gibt einen Expert Level, der ist praktisch in den letzten Stadien der

Ulrich: Vorbereitung, würde ich sagen, dass das Ganze launcht.

Ulrich: Das heißt momentan, Stand heute ist praktisch Advanced Level das höchste,

Ulrich: aber es ist eben geplant, dass es oben drüber dann auch noch eine Ebene gibt.

Wolfgang: Und das wäre jetzt für Leute, die jetzt im Projekt ganz normal arbeiten und aber Bock haben,

Wolfgang: da jetzt einfach besser zu werden im Bereich Softwarearchitektur oder vielleicht

Wolfgang: auch mal ein bisschen neue Perspektiven zu entwickeln und dann vielleicht auch

Wolfgang: künftig solche Rollen mit zu übernehmen in Projekten,

Wolfgang: wäre das so ein greifbarer Entwicklungspfad, oder?

Ulrich: Auf jeden Fall, ja. und was eben beim,

Ulrich: Dieses AGB-Zertifizierungsschema auch schön ist, man kann wirklich erstmal einzelne Schulungen,

Ulrich: einzelne Module praktisch besuchen und kann sich dann irgendwann überlegen,

Ulrich: okay, will ich jetzt wirklich diese Advanced Level Zertifizierung machen, ja oder nein.

Ulrich: Das heißt, das sind alles Module, die für sich genommen, sage ich jetzt mal,

Ulrich: einfache sinnvoll sind, einen praktischen Nutzen haben und die auch nicht verfallen.

Ulrich: Also es ist nicht so die extreme Gelddruckmaschine, wie manche Organisationen

Ulrich: das perfektioniert haben, wo ich dann irgendwie alle paar Jahre nochmal Geld

Ulrich: einwerfen muss, um irgendwas aktuell zu halten.

Ulrich: Sondern es ist tatsächlich so, ich besuche diese Schulungen,

Ulrich: sowas wie Agila oder Embedded zum Beispiel und bekomme praktisch Credit Points,

Ulrich: die ich sammle für den Besuch und die bleiben auch gültig.

Ulrich: Und wenn ich irgendwann sage, okay, ich habe jetzt genug Credit Points beisammen,

Ulrich: um dann wirklich auch die Zertifizierung zu machen, dann kann ich das jederzeit tun.

Marvin: Und ich finde auch eine coole Sache in dieser Modalisierung ist,

Marvin: dass ihr auch, sag ich mal, die Tür öffnet für andere Profile als,

Marvin: sag ich mal, den klassischen Softwareentwickler, der jetzt sich vorgenommen

Marvin: hat, die Advanced zu machen.

Marvin: Weil er Architekt werden will, ermöglichen so Module wie Agila eben oder Flex

Marvin: auch mal einem Product Owner oder einem Scrum Master mal zu sagen,

Marvin: ich will mir so ein gewisses Grundverständnis für Softwarearchitektur aufbauen,

Marvin: ohne dass ich mich da jetzt groß committe, das so in einem Studiengang aufzunehmen.

Wolfgang: Ja, das ist auf jeden Fall spannend. Also ich glaube ja, in der Softwareentwicklung

Wolfgang: gibt es natürlich immer ein bisschen Spezialisierung.

Wolfgang: Und wenn du, Marvin, jetzt der Profi bist für Datenbanken, dann ist das natürlich

Wolfgang: eine gute Sache für alle Projekte, in denen du bist, wenn es um Datenbanken irgendwie geht.

Wolfgang: Aber ich finde, so dieses methodische Grundverständnis ist halt für alle Rollen super spannend.

Wolfgang: Und ich meine, das ist ja auch so ein bisschen diese agile Idee oder diese Scrum-Idee,

Wolfgang: dass alle Leute im Team Ahnung von allen anderen Bereichen haben,

Wolfgang: aber nicht jede Person muss Experte irgendwie sein für alles Mögliche.

Wolfgang: Aber so wie es, glaube ich, für die Frontend-Entwicklerin spannend ist,

Wolfgang: so grundlegend zu wissen, was eine Datenbank macht, ist es sicherlich auch für

Wolfgang: so einen Product Owner wichtig und spannend zu wissen, wie funktioniert denn

Wolfgang: jetzt sowas wie Software-Head-Tour?

Wolfgang: Was ist das? Warum sollte man denn irgendwas überhaupt strukturieren?

Wolfgang: Etc. pp. Also das ist dann schon mal wirklich interessant auf jeden Fall.

Ulrich: Ja, ich habe auch in den Foundation-Level-Trainings immer mal wieder entwicklungsferne Rollen drin.

Ulrich: Also eben zum Beispiel jemanden aus der Projektleitung oder teilweise auch Leute

Ulrich: aus der Qualitätsmanagement beispielsweise, die einfach sagen,

Ulrich: okay, ich möchte einfach besser verstehen,

Ulrich: worüber die Leute eigentlich reden.

Ulrich: Wenn sie irgendwie über Architektur reden oder wenn es generell um Entwicklungsthemen

Ulrich: auch geht, um da einfach so ein Verständnis dafür zu entwickeln.

Wolfgang: Ja, also...

Wolfgang: Ich war in genügend Projekten, wo ich mir gewünscht hätte, dass vielleicht der

Wolfgang: eine Stakeholder oder der Projektleiter ein bisschen mehr Verständnis hat für

Wolfgang: manche Themen in der Softwareentwicklung und zwar Verständnis im Sinne von Wissen einfach,

Wolfgang: weil es oftmals schon Situationen gab, die schwierig waren, weil da zwei unterschiedliche

Wolfgang: Welten irgendwo sind und man die Brücke erst bauen musste und das teilweise

Wolfgang: halt sehr anstrengend war.

Wolfgang: Und wenn natürlich überall so ein gewisses Grundverständnis da ist,

Wolfgang: ich glaube, das macht vieles einfacher, macht vieles angenehmer und sorgt sicherlich

Wolfgang: auch dafür, dass Projekte besser laufen.

Wolfgang: Das heißt jetzt aber für mein Projekt in meiner Firma, das vielleicht noch nicht

Wolfgang: so 100% gut läuft und wo vielleicht auch jetzt keine Leute drin sind,

Wolfgang: die jetzt irgendwie 20 Jahre Erfahrung irgendwo mitbringen,

Wolfgang: wären solche Weiterbildungen mal ein guter Schritt oder vielleicht ein guter erster Schritt,

Wolfgang: um mein Projekt jetzt so einfach ein Stück weiter zu bringen,

Wolfgang: vielleicht auf so eine nächste Stufe zu bringen, ohne dass ich jetzt eine schnellen

Wolfgang: Ausschreibung für einen Enterprise-Architektur hin, wo die Zeitung setzen muss.

Marvin: Anderes, sag ich mal, niederschwelliges Angebot wäre vielleicht auch,

Marvin: ich hole mir ja vielleicht auch nur für ein paar Tage dann externen Architekten

Marvin: rein, der einfach mal ein Architektur-Review durchführt.

Marvin: Einfach mal guckt, haben wir überhaupt eine Architektur? Ist die vielleicht

Marvin: irgendwie einfach rein zufällig entstanden?

Marvin: Wo sind unsere Haupt-Bain-Points? Und der dann einfach, sag ich mal,

Marvin: dem Team so ein paar Baustellen mitgeben kann, an denen sie sich dann noch,

Marvin: die sich dann weiterhin beschäftigen können wieder.

Wolfgang: Ist das eine philosophische Frage? Haben wir vielleicht zufällig eine Architektur

Wolfgang: oder hat man immer eine Architektur und die ist entweder gut,

Wolfgang: passend oder schlecht und unpassend?

Ulrich: Also ich würde sagen, jedes System hat eine Architektur. Die Frage ist zum einen,

Ulrich: ist sie irgendwo explizit festgehalten?

Ulrich: Also finde ich da irgendwas, wo das Ganze überhaupt beschrieben ist?

Ulrich: Und dann eben wirklich die Frage, ist das Ganze systematisch entstanden durch

Ulrich: eine Folge bewusster Entscheidungen oder was wir eben häufig haben,

Ulrich: sind das einfach Ad-Hoc-Entscheidungen?

Ulrich: Ja, man hat vielleicht nicht in der Tiefe drüber nachgedacht,

Ulrich: man hatte vielleicht auch nicht das nötige Wissen zu einem gewissen Zeitpunkt

Ulrich: und hat dann auf eine suboptimale Art und Weise eine ad hoc Entscheidung getroffen.

Wolfgang: Solche Architektur-Reviews durch so einen externen Experten sind sicherlich

Wolfgang: aber auch sinnvoll, wenn man schon irgendwelche Legacy-Projekte hat, oder?

Wolfgang: Dass man jetzt wirklich sagt, hey, das Projekt, die Leute, die es angefangen

Wolfgang: haben, sind vielleicht gar nicht mehr im Unternehmen, wir müssen das so irgendwie

Wolfgang: weiterführen und bräuchten vielleicht jetzt mal irgendwie diesen externen Blick

Wolfgang: für so eine Bewertung irgendwo.

Marvin: Genau, das ist ein guter Einstiegspunkt, gerade bei einem Legacy-Projekt,

Marvin: das heute schon länger verwaist ist,

Marvin: gehört auch, brauchst du auch noch ein bisschen mehr, da gehört eine ganze Stange

Marvin: an Softwarearchäologie dazu, bis du mal versuchst, rauszuwenden,

Marvin: okay, was waren die Intentionen von dem System,

Marvin: was hat man sich dabei gedacht, als es entworfen wurde, wo sind die Punkte,

Marvin: an denen recht viel geändert werden muss, wo sind die Punkte,

Marvin: an denen recht wenig regelmäßig geändert werden muss,

Marvin: damit man sich langsam sicher mal ein Bild machen kann, wo soll das denn eigentlich hin?

Marvin: Und da kann man auch hinterher dann versuchen, einfach mal Qualitätsanforderungen

Marvin: zu erheben und dann einfach mal gegensetzen, okay, so wie dieses Ding jetzt

Marvin: ist, tut es deine Qualitätsanforderungen erfüllen oder wie müsste ich es verändern, damit ich da hinkomme?

Ulrich: Also im Grunde muss man es, also genau das, was du gesagt hast,

Ulrich: muss man definitiv machen, denn eine Architektur ist halt nie für sich genommen

Ulrich: gut oder schlecht, sondern sie ist immer mehr oder weniger geeignet für die

Ulrich: Anforderungen, die wir haben.

Ulrich: Und das ist bei so Architekturanalysten auch manchmal das Problem,

Ulrich: dass man sich in der Vergangenheit nie so explizit Gedanken gemacht hat,

Ulrich: zum Beispiel über das Thema Qualitätsanforderungen.

Ulrich: Das heißt, das ist dann oft auch schon der erste Schritt, wirklich mal aus den

Ulrich: Stakeholdern praktisch rauszuholen, was sind denn am Ende eigentlich die wichtigen

Ulrich: Qualitätsziele und Qualitätsanforderungen in Form von solchen Szenarien eben,

Ulrich: wie es Marin vorhin auch beschrieben hat,

Ulrich: um dann wirklich mal die Architektur dagegen zu halten.

Wolfgang: Und für so eine Analyse ist es natürlich auch hilfreich, wenn man dann diese

Wolfgang: entsprechende Ausbildung, sage ich mal, genossen hat.

Wolfgang: Die kann man ja dann anwenden für ein neues Projekt oder halt auch für die,

Wolfgang: Marvin, du hast ein schönes Wort benutzt, Softwarearchäologie.

Wolfgang: Ich habe sowas ein einziges Mal erlebt, so ein Architektur-Review.

Wolfgang: Boah, das ist sicherlich schon mehr als 15 Jahre her.

Wolfgang: Liegt lang, lang in der Vergangenheit und da ging es um ein Kundenprojekt,

Wolfgang: das verkauft wurde, also ein Produkt an ein anderes Unternehmen und da war ich

Wolfgang: dann involviert als Entwickler.

Wolfgang: Und da gab es auch einen externen Architekten, der da ganz viel Zeit investiert

Wolfgang: hat, um das alles mal zu begutachten und dann ein sehr ernüchterndes Dokument verfasst hat,

Wolfgang: das auf jeden Fall viele Punkte aufgeführt hat, die man dann angegangen ist.

Wolfgang: Hat uns viele Arbeitspakete geschnürt damals, dieses Architektur-Review.

Ulrich: Aber das ist halt auch eine häufige Situation, dass man sagt,

Ulrich: man hat ein System, das lebt schon eine ganze Weile und Anforderungen ändern sich ja.

Ulrich: Das heißt, selbst eine Architektur, die vielleicht vor fünf oder zehn Jahren

Ulrich: vielleicht mal sinnvoll war, ist es vielleicht heute nicht mehr.

Ulrich: Und wo es dann auch genau darum geht, eben das rauszuarbeiten,

Ulrich: ob das eben auch zum heutigen Stand tatsächlich noch eine geeignete Architektur

Ulrich: ist und dann eben, was ein Pfad dann sozusagen davon ausgehend auch sein könnte,

Ulrich: um die Architektur halt zu modernisieren.

Marvin: Ja, natürlich gibt es für Architektur-Reviews ja auch komplette,

Marvin: sag ich mal, Frameworks, die man sowas durchführen kann.

Marvin: Man hat ja den Klassiker mit Atom aus den frühen 2000ern, dass er wirklich ein

Marvin: größerer Prozess ist, den man durchführen kann, aber auch leichtgewichtige Sachen

Marvin: heutzutage, wie zum Beispiel Laser, was man irgendwie mit dem Thema am Vormittag

Marvin: einmal durchziehen kann, um dann schon mal gewisse Sachen rauszuarbeiten.

Wolfgang: Also für so eine erste Einschätzung im Prinzip, so ein leichtgewichtiger Prozess.

Marvin: Und das andere, was dazukommt, ist, das macht man ja nicht nur,

Marvin: wenn man jetzt sagt, okay, ich habe hier so ein längstes System vor mir und

Marvin: muss das jetzt mal auseinandernehmen, sondern auch wenn man,

Marvin: sage ich mal, schon sauber startet und von vornherein seine Qualitätsanforderungen

Marvin: erhebt, kann es durchaus sich lohnen, gerade weil wir eher agiert arbeiten,

Marvin: alle paar Monate mal die Architektur zu re-reviewen und zu gucken,

Marvin: sind wir noch auf dem richtigen Pfad oder hat sich irgendwas in unseren fundamentalen

Marvin: Annahmen geändert und müssen wir dagegen steuern.

Marvin: Das ist genau wie, dass wir jetzt unsere Sprint so planen, dass wir regelmäßig

Marvin: unsere Software zeigen und an den fachlichen Anforderungen fallen können,

Marvin: müssen wir genauso die Qualitätsanforderungen über das ganze Projektverlauf im Blick halten.

Wolfgang: Also das klingt super nachvollziehbar und super sinnvoll. Und diese Qualitätskriterien

Wolfgang: und Qualitätsszenarien, die du vorhin angesprochen hast, Marvin,

Wolfgang: die sind ja dann auch optimal, um das auch bei den Stakeholdern und beim Product

Wolfgang: Owner irgendwo zu verankern.

Wolfgang: Weil die Demonstration vor meinem Software-Inkrement, das am Ende vom Sprint

Wolfgang: rausputzelt, das den Leuten zu zeigen, ich glaube, das ist super einfach,

Wolfgang: weil man sieht ja was zum Angucken.

Wolfgang: Und das sind ja die Features, die tollen Features für mein Produkt.

Wolfgang: Und das ist auch was super Etabliertes. Aber was halt Qualität etc.

Wolfgang: Angeht, da habe ich es oft erlebt, dass das halt hinten runterputzelt.

Wolfgang: Das interessiert niemand so stark vielleicht wie jetzt das Feature und wenn

Wolfgang: ich jetzt aber solche Kriterien habe, die ich messen kann und sagen kann, hey,

Wolfgang: jetzt wird es mal wieder Zeit, wir schauen alle, weiß nicht,

Wolfgang: Monate, alle zwei Monate drauf und haben vielleicht auch hier ein wunderschönes

Wolfgang: Dashboard mit ganz tollen Zahlen, die jetzt besser oder schlechter sind.

Wolfgang: Das ist ja auch was, was ich meinen Stakeholdern dann zeigen kann,

Wolfgang: weil letztendlich, die investieren ja Geld und wenn ich denen zeigen kann,

Wolfgang: hey, das Geld sorgt dafür, dass es nicht nur Features gibt, sondern dass die

Wolfgang: auch eine gute Qualität haben und wir dann, weiß nicht,

Wolfgang: am Markt gut bestehen können, weil wir halt schneller sind als die Konkurrenz

Wolfgang: und die Website keine 10 Sekunden braucht, bis sie lädt, das ist ja auch ein schönes Argument.

Marvin: Ja, genau. Du hast halt gerade bei Qualitätsanforderungen das Problem,

Marvin: dass solange die impliziert sind, interessieren sie keinen bis zu dem Zeitpunkt,

Marvin: wo sie nicht mehr erfüllt sind und dann brennt plötzlich die Hütte.

Marvin: Also wenn plötzlich die Software dann nicht mehr schnell genug antwortet,

Marvin: weil dann sind Product Owner plötzlich immer oder Stakeholder relativ gut darin

Marvin: zu formulieren, was ihnen nicht mehr gefällt und deswegen hilft es da wirklich,

Marvin: wenn man die explizit ausformuliert hat und vielleicht auch mit einem Dashboard

Marvin: irgendwie, vielleicht sogar mit einem einfachen Ampelsystem darstellt und am

Marvin: Ende von jedem Sprint zeigen kann, so stehen wir aktuell.

Ulrich: Also ich würde auch sagen, es interessiert schon irgendwann Leute,

Ulrich: nur dann ist es häufig einfach zu spät für bestimmte, doch eher grundlegende Entscheidungen.

Ulrich: So ein Security, Fehlertoleranz, Performance, das sind eben genauso Beispiele.

Ulrich: Das ist schmerzhaft, irgendwie zu versuchen, das im Nachhinein noch in ein System reinzubekommen.

Ulrich: Ja, das heißt gewisse Dinge, da ist es einfach sinnvoll, sich eben schon frühzeitig

Ulrich: auch Gedanken dazu zu machen und das dann eben wirklich auch bei der Feature-Entwicklung

Ulrich: immer gleich mitzudenken.

Wolfgang: Wenn ich jetzt mal die Rolle von einem Kunden annehme, der möchte,

Wolfgang: dass was entwickelt wird, weil ich selbst als Kunde vielleicht keine Ahnung

Wolfgang: habe von Softwareentwicklung und deswegen zu einem Dienstleister gehe,

Wolfgang: dann wäre zumindest meine implizite Annahme auch oder Erwartung,

Wolfgang: dass der Dienstleister sich um solche Dinge auch kümmert.

Wolfgang: Weil ich habe das ja nicht auf dem Schirm, dass ich mich um irgendwelche Qualitätssachen überkümmer.

Wolfgang: Also wenn ich mir Brot kaufe, dann erwarte ich auch, dass es durchgebacken ist

Wolfgang: und sage zu Bäckern nicht.

Wolfgang: Aber passen Sie auf, Kruste, Bräunungsgrad 7, komplett durchgebacken und die

Wolfgang: Brotporn, also nicht größer als 0,3 Millimeter, sonst fällt mir da immer die

Wolfgang: Butter rein, dann schmeckt es mir nicht mehr so gut.

Wolfgang: Also dann erwarte ich auch, dass das ein Profibrot ist, dass der Brotarchitekt

Wolfgang: darauf achtet, dass hier die ganzen Parameter stimmen und so weiter und so fort.

Wolfgang: Aber nee, Spaß beiseite.

Wolfgang: Letztendlich erwarte ich das doch implizit zumindest und ich weiß,

Wolfgang: in der Software ist es immer ein bisschen anders wie bei solchen handwerklichen

Wolfgang: Sachen, weil jeder Mensch hat natürlich Ahnung von Brot und von Autos,

Wolfgang: aber von Software halt nicht, weil die so schwer greifbar ist irgendwie.

Wolfgang: Wie genau so diese Qualitätssachen oftmals nur gut greifbar sind, wenn die schlecht sind.

Wolfgang: Aber ja, ich finde es großartig, wenn man sowas in der Entwicklung gut verankern kann.

Wolfgang: Und ich habe auch die Hoffnung, dass wir vielleicht irgendwann in der Zukunft

Wolfgang: von einem Punkt sind, wo man auch nicht mehr so viel darüber diskutieren muss, dass es wichtig ist.

Wolfgang: Sondern es wäre ja auch schön, wenn Kunden oder alle Leute, die mit Software

Wolfgang: irgendwo zu tun haben, von vornherein fragen, ja, und wie sieht denn hier diese

Wolfgang: nicht funktionale Anforderung aus? Was habt ihr denn da?

Wolfgang: Das wäre natürlich sehr, sehr schön.

Ulrich: Ich würde sagen, wir arbeiten auf jeden Fall dran, genau. Ist auf jeden Fall,

Ulrich: würde ich sagen, schon ein Thema, was auch definitiv wieder Aufmerksamkeit gewonnen hat.

Ulrich: Es gab ja so eine erste Welle des Themas Softwarearchitektur.

Ulrich: Das war eben genau so die Ära der Wasserfallarchitektur und der Elfenbeinturm-Architekten-Untertitelung,

Ulrich: Genau das hat dann eben danach auch zu so einem Dämpfer geführt,

Ulrich: weil man eben einfach gesehen hat, okay, das war jetzt vielleicht doch nicht

Ulrich: der richtige Ansatz, aber eben genau diese Ansätze,

Ulrich: die jetzt wirklich stärker in die Teamarbeit mit integriert werden und eben

Ulrich: auch besser mit einem agilen Vorgehen zusammenpassen.

Ulrich: Also da sehe ich schon, dass das Adresse sehr, sehr stark auf jeden Fall auch zunimmt.

Marvin: Und ja, das ist, was ich manchmal denke, dass wir vielleicht mit der agilen

Marvin: Revolution so ein bisschen eine Überkorrektur hatten in manchen Belangen,

Marvin: wo wir jetzt einfach versucht haben, irgendwie gar nichts mehr zu planen und

Marvin: nur davon Sprint zu Sprint vorzugehen.

Marvin: Das Problem ist halt, Architektur muss man doch irgendwie langfristig und zukunftsorientiert

Marvin: machen und da muss man so ein bisschen immer den Kompromiss finden zwischen

Marvin: wir sind agil, aber wir müssen schon irgendwie noch gewisse Sachen planen und abschätzen.

Wolfgang: Ja, das sehe ich aber so ähnlich wie du, Marvin. Also ich glaube,

Wolfgang: durch die ganze Agilität und durch den großen Erfolg von Scrum in den letzten,

Wolfgang: weiß nicht, 15 Jahren vielleicht,

Wolfgang: hat man schon irgendwann diesen Punkt gehabt, wo gar nichts mehr geplant wurde.

Wolfgang: Also ich habe das auch erlebt, dass man dann wirklich von Sprint zu Sprint gearbeitet

Wolfgang: hat und dass es auch offiziell in Anführungszeichen gesagt wurde,

Wolfgang: ja Leute, also wir wissen nicht, was die Zukunft bringt.

Wolfgang: Also wir müssen für diesen Sprint so arbeiten, dass da alles passt.

Wolfgang: Und da gab es auch früher mal diese ominösen Stabilisierungssprints,

Wolfgang: die es so theoretisch zumindest gab.

Wolfgang: Es wurde öfter mal gesagt, ja, wir machen ab und zu so einen Stabilisierungssprint

Wolfgang: und dann beheben wir technische Schulden und so.

Wolfgang: Habe ich aber nie erlebt, dass sowas tatsächlich passiert ist.

Wolfgang: Aber es wurde oft darüber gesprochen.

Wolfgang: Und ja, ich glaube, manche Sachen sollte man schon, da sollte man schon ein

Wolfgang: bisschen mehr drüber nachdenken, weil, so wie du es auch vorhin gesagt hast,

Wolfgang: Uli, glaube ich, manche Sachen sind halt teuer, wenn man sie ändern muss, also,

Wolfgang: Wir können alles ändern, wenn wir genug Zeit und Geld haben,

Wolfgang: aber vielleicht irgendwie, manche Sachen sind einfach und manche kosten super

Wolfgang: viel Geld und wenn man vielleicht ein bisschen mehr drüber nachdenkt und was

Wolfgang: ihr beide jetzt so oft gesagt habt,

Wolfgang: mit vielen Leuten drüber spricht, um sich so ein gesamtes Bild irgendwie zu verschaffen,

Wolfgang: dann kann man hier und da vielleicht das Risiko minimieren, dass es extrem große,

Wolfgang: teure Änderungen irgendwann gibt.

Wolfgang: Ja, gibt es von eurer Seite noch eine Facette zum Thema Rolle von Softwarearchitekten

Wolfgang: im Projekt oder vielleicht auch zum Thema,

Wolfgang: was ist generell eigentlich Softwarearchitektur im Jahr 2025?

Ulrich: Also was ich gerne ergänzen würde, ist auf jeden Fall, dass das immer was ist,

Ulrich: wo man auch experimentiert.

Ulrich: Also wie man diese Rolle interpretiert, was es vielleicht für verschiedene Arten

Ulrich: von ArchitektInnen-Rollen irgendwo gibt im Unternehmen.

Ulrich: Eben auch, wie man so ein bisschen aushandelt, wer jetzt was entscheidet,

Ulrich: wie bestimmte Entscheidungen getroffen werden,

Ulrich: dass das eben nichts ist, wo man sagt, okay, so machen wir es jetzt und so machen

Ulrich: wir es dann auch immer für alle Zeit, sondern dass man da eben auch experimentiert,

Ulrich: was für Modelle funktionieren für uns gut.

Ulrich: Und wenn man dann eben sieht, okay, irgendwas passt nicht, dann muss ich eben

Ulrich: einfach entsprechend nachsteuern.

Ulrich: Also, dass das eben nichts Statisches ist, sondern auch was,

Ulrich: wo wir uns immer wieder einfach basierend auf den Erfahrungen,

Ulrich: die wir im Projekt machen, dann auch adaptieren.

Marvin: Ja, genau. Wie es halt auch gerade immer fürs Team passt, kann man halt auch

Marvin: mal mehr und mal weniger Architekt oder mal mehr konzentrierte Architekte oder

Marvin: mal mehr das Team macht die Verantwortung. Und das muss man halt immer,

Marvin: Case by Case sehen.

Wolfgang: Ja und wie so oft ist es wahrscheinlich einfach wichtig, dass man miteinander

Wolfgang: spricht und dann kann man halt auch die besten Entscheidungen treffen, finde ich immer.

Wolfgang: Was mir gut gefallen hat und was ich auf jeden Fall mitnehme aus unserem Gespräch ist, die Idee,

Wolfgang: dass Softwarearchitektur für viele Projekte eine gute Sache ist,

Wolfgang: wenn im Team genügend Leute sind, die die Erfahrung mitbringen und zwar die technische,

Wolfgang: die methodische und aber auch so die wirtschaftliche fürs ganze Projekt und

Wolfgang: die Leute miteinander sprechen, um dann einfach gute Entscheidungen zu treffen.

Wolfgang: Das klingt super simpel, bin ich ehrlich, aber die große Kunst ist natürlich,

Wolfgang: das dann auch in der Praxis jeden Tag umzusetzen.

Wolfgang: Aber ich habe gelernt, es gibt ja auch spannende Weiterbildungen, die man machen kann.

Wolfgang: Und ich bin großer Fan von Weiterbildungen. Also ich habe beispielsweise damals

Wolfgang: auch diese ganzen Scrum-Weiterbildungen gemacht und fand es auch immer spannend,

Wolfgang: obwohl dann so eine Weiterbildung vielleicht nur eine Woche dauert oder so,

Wolfgang: dass man da immer viele spannende Impulse mitnimmt und dann im Laufe der Zeit

Wolfgang: in seiner Arbeit auch merkt, das ist ja eigentlich ganz spannend.

Wolfgang: Das eine Ding an sich ist vielleicht super einfach, aber das bringt ganz schön viel.

Wolfgang: Vielen Dank für eure Zeit und

Wolfgang: vielen Dank fürs Teilen von eurer Sichtweise und von euren Erfahrungen.

Wolfgang: Ich fand das auf jeden Fall super spannend und ich glaube, wir müssen beim Thema

Wolfgang: Architektur sicherlich mal noch ein Follow-up machen, weil ich habe ja noch

Wolfgang: ein paar spannende andere architekturrelevante Themen auf dem Zettel,

Wolfgang: über die ich mich gern mit Experten unterhalten würde.

Ulrich: Immer gerne. Hat Spaß gemacht.

Marvin: Jedes Mal wieder eine Freude hier zu sein.

Wolfgang: Das freut mich. Das war das Gespräch mit Ulrich und Marvin.

Wolfgang: Ich hoffe, es hat euch Spaß gemacht. Wenn ihr Feedback habt,

Wolfgang: dann erreicht ihr mich per E-Mail unter podcast.innovex.de.

Wolfgang: Wir hören uns in der nächsten Folge wieder.

Wolfgang: Und bis dahin wünsche ich euch viel Spaß und eine gute Zeit.