personal<IT>y: „Architektur ist das stille Entwerfen unsichtbarer Dinge“, sagt ein Softwarearchitekt über Systemmodellierung, Systemgrenzen und die Schönheit verborgener Entscheidungen

Dort, wo unsichtbare Städte entstehen

Wie würdest du deine Rolle als Softwarearchitekt jemandem erklären, der sich überhaupt nicht in der IT bewegt?

Das ist eine ausgezeichnete Frage. Ich glaube, am einfachsten lässt sich das über einen Vergleich mit einem Architekten in der realen Welt erklären. Stell dir jemanden vor, der auf ein leeres Grundstück kommt und sagt: Hier bauen wir einen Wohnkomplex. Hier werden Wohnblocks stehen, hier ein Spielplatz, dort ein Brunnen, unten Dienstleistungen, kleine Läden, vielleicht ein Parkplatz, eventuell eine kleinere Bar oder ein Café.

Und eigentlich passiert genau das auch in der Welt der Software. Am Anfang steht ein Konzept. Jemand kommt mit einer Vision, was wo sein soll. Und dann gehst du – ähnlich wie bei einem physischen Bau – ins Detail. Ein Architekt in der realen Welt zeichnet am Ende sogar die letzte Tür in jeder Wohnung. In der Software ist das nicht anders: Der Architekt geht in der Planung so tief, damit die Entwickler es exakt implementieren können.

Also bleibt ein Softwarearchitekt nicht nur beim Konzept, sondern seine Arbeit umfasst auch detaillierte Entwürfe, die Auswahl geeigneter Technologien, Standards, berücksichtigt verschiedene Einschränkungen und Erwartungen. Am Ende übergibt er eine detaillierte Spezifikation an die Entwickler, die danach programmieren. Und auch wenn es manchmal passiert, dass jemand Dinge „auf seine Weise verbessert“, geht das nicht immer gut aus – so wie wenn du feststellst, dass sich eine Tür nur bis zur Kante der Stufen öffnen lässt.

Wenn ein System aufhört, nur Software zu sein

Ich habe auch mit einem Analysten gesprochen, und der hat mir gesagt, seine Aufgabe sei es, Anforderungen vom Kunden zu erheben, sie in technische Sprache zu übersetzen und an die Entwickler weiterzugeben. Wo ist in diesem Kreislauf der Platz des Architekten?

In der Praxis ist es oft noch etwas komplizierter. Neben Analyst und Entwickler kommt auch die Rolle des Designers hinzu. Im Idealfall ist der Designer irgendwo zwischen Analyst und Entwickler, aber seine Arbeit liegt sehr nah an der des Architekten. Im Grunde geht es nur um ein anderes Abstraktionsniveau.

Ein erfahrener Designer könnte mit der Zeit die Ambition haben, Architekt zu werden – ähnlich wie ein Architekt in der realen Welt zuerst fremde Projekte kopiert, dann ein eigenes Einfamilienhaus entwirft und ihm mit der Zeit, wenn er wirklich gut ist, ein ganzes Wohnviertel anvertraut wird. Der Unterschied zwischen Designer und Architekt besteht darin, dass der Architekt die Lösung von oben konzipiert – er hat eine Vision, denkt über das Gesamtkonzept des Systems nach. Der Entwickler löst dann die konkrete Implementierung. Der Entwurf ist also die Brücke zwischen ihnen.

Mit wem arbeitest du also am meisten zusammen?

Das hängt sehr von der Größe des Unternehmens ab. In kleineren Firmen überschneiden sich Rollen oft, Menschen müssen mehrere Funktionen gleichzeitig übernehmen. In größeren Firmen gibt es mehr Spezialisierung. Ich arbeite als Person mit einem breiten Spektrum an Menschen zusammen, auch weil ich in unserem Unternehmen mehrere Rollen übernehme – nicht alle stehen zwar auf meiner Visitenkarte, aber ich mache sie.

Aus Sicht des Architekten ist die Zusammenarbeit mit dem Analysten entscheidend – er bringt die Inputs vom Kunden. Dann sicher mit dem Projektmanager, der die Organisation des Projekts steuert. Und je nach Teamgröße entweder direkt mit den Entwicklern oder es gibt noch eine Design-Ebene dazwischen. Wichtig sind auch die Tester – nicht nur, weil die Entwickler mit ihnen Testszenarien abstimmen, sondern auch, weil Tester die Architektur und das Konzept des Systems verstehen müssen, um das gesamte System effektiv mit Tests abzudecken.

Die schwierigsten Entscheidungen sind die, die niemand sieht

In welchen Phasen der Entwicklung greift der Architekt also am häufigsten ein?

Theoretisch sollte der Architekt so früh wie möglich in den Zyklus einsteigen, noch während der Analyse. Denn architektonische Entscheidungen beeinflussen das gesamte Ergebnis grundlegend. Aber wie in der realen Welt werden oft bewährte Vorlagen, Stereotype genutzt, solche „sozialistischen Plattenbausiedlungen“. Einmal wird etwas ausgedacht und dann nur noch kopiert. In so einem Fall steigt der Architekt erst dann ein, wenn etwas „vom Standard abweicht“, zum Beispiel wenn eine Anforderung auftaucht, die unsere bestehenden Lösungen nicht abdecken.

Dann ist es nötig, entweder die bestehende Architektur zu erweitern oder eine neue Lösung zu entwerfen. Und ja – in kleineren Firmen bedeutet das, dass ich später auch in andere Rollen wechsle: Designer, Entwickler oder auch Berater. Nicht потому, dass das prinzipiell Aufgabe des Architekten wäre, sondern weil das Unternehmen nicht so groß ist, dass ich mich nur der Architektur widmen könnte.

Also entwirft der Architekt, genehmigt die Lösung und überwacht dann die Einhaltung während der Entwicklung?

Genau so. Die Architektur sollte so klar wie möglich sein, noch bevor die Entwicklung beginnt – zumindest in groben Zügen, idealerweise schon weitgehend detailliert durchdacht. Die Entwicklung findet dann innerhalb dieser Architektur statt. Und die Aufgabe des Architekten ist es, darauf zu achten, dass sich Entwurf und Implementierung nicht von der Architektur entfernen. Es ist wie wenn jemand sagt: Hier soll ein Wohnviertel sein – und du kannst dort nicht einfach ein Lager oder einen Hangar bauen, nur weil es dir gerade passt.

Du hast die Zusammenarbeit mit Testern erwähnt – wie sieht das konkret aus?

Zu einem großen Teil sind das Konsultationen. Oft passiert es nämlich, dass konzeptionelle Informationen im Team mit der Zeit verschwinden. Je mehr sich jemand auf Details konzentriert, desto mehr kann der Überblick verloren gehen. Und nicht jeder hat das Bedürfnis, Zusammenhänge zu verstehen – warum etwas so entworfen wurde, wie es ist. Das führt dann dazu, dass wenn so jemand seine Arbeit weitergibt, das Konzept völlig verloren geht. Und jemand anderes im Team sieht dann das große Ganze nicht mehr. Deshalb ist es wichtig, dass es jemanden gibt – typischerweise den Architekten –, der dieses Bild immer wieder ins Team zurückträgt.

Chaos, das man entwirren muss, damit es Form bekommt

Und was ist mit den Kunden? Inwieweit triffst du dich auch mit ihnen?

Das hängt vom Kundentyp und vom Projekttyp ab. Meistens ja – Software muss in einer konkreten Kundenumgebung funktionieren, mit konkreten Anforderungen an Sicherheit, Integration und Ähnliches. Manchmal äußert der Kunde diese Anforderungen sehr genau, manchmal deutet er nur etwas an und du musst herausfinden: Warum will er das eigentlich? Was verfolgt er damit? Was bringt es ihm? Und manchmal kann auch eine gut gemeinte „kleine Änderung“ aus Kundensicht, zum Beispiel ein neues Feld im Formular, das gesamte Konzept des Systems kaputtmachen. Und dann ist es meine Aufgabe zu erklären, dass diese „Kleinigkeit“ in Wirklichkeit ein Eingriff in die Fundamente ist. Manchmal machbar, manchmal nicht.

Heißt das, du gehst auch direkt zu Kundenterminen?

Ja, ziemlich oft. Vor allem dann, wenn sich zeigt, dass es nicht mehr um Business-Anforderungen geht, sondern um ein Problem im Konzept der Lösung selbst. Dann steige ich oft ein, erkläre, konsultiere, argumentiere.

Und gelingt es dir, das so zu erklären, dass der Kunde es versteht und annimmt?

Ich hoffe es. Der Kunde stellt nur eine Menge nicht immer konsistenter Anforderungen zusammen, und du beginnst, diese Bedingungen zu entwirren, versuchst zu verstehen, was sie eigentlich bedeuten. Und jetzt liegt es an dir – in dieser Rolle –, zu suchen, wie man sie zu einer konsistenten Lösung zusammensetzt. Und manchmal taucht genau in dieser Phase etwas auf, das mich wirklich begeistert: Dass aus diesem Chaos, aus dieser Menge an Anforderungen, die nach außen hin nicht einmal Sinn ergeben müssen, etwas entsteht, das Form, Struktur und Hand und Fuß hat.

Und wenn man das entwirrt, das Konzept formuliert, den Entwurf macht und dann verfolgt, wie sich die Software danach zusammensetzt – wie wenn nach Plänen ein Haus gebaut wird –, das ist dieser „Wow-Moment“. Denn dann weißt du, dass du Entscheidungen getroffen hast, die die Richtung des gesamten Projekts real beeinflusst haben. Und wenn es nach diesem Entwurf läuft, wenn sich die Entwickler auf die Architektur stützen können, wenn es für die Tester Sinn ergibt, wenn der Kunde anfängt, es zu greifen … dann ist das Zufriedenheit. Und obwohl sie verspätet ist, ist sie umso tiefer.

Und dabei ist es paradox: Oft passiert die größte Arbeit lange bevor die erste Zeile Code geschrieben wird. Und eigentlich weiß niemand davon. Denn wenn es funktioniert, merkt niemand, dass überhaupt etwas hätte schiefgehen können. Weißt du, das ist wie bei guter Infrastruktur: Wenn sie gut entworfen ist, nimmt sie niemand wahr. Aber wenn nicht, schimpft jeder.

Und dieser „unsichtbare“ Teil der architektonischen Arbeit, in dem viele Entscheidungen darüber getroffen werden, wie Dinge miteinander sprechen, wo die Grenzen sind, wie sich etwas unter Last verhält, was flexibel sein soll und was nicht … das ist genau das, was mich an dieser Arbeit am meisten hält. Denn es geht nicht darum, dass du nur etwas Technisches entwirfst. Es geht darum, das System als Ganzes zu verstehen – Technik, Menschen, Prozess, Anforderungen und reale Einschränkungen. Und wenn du das so zusammensetzt, dann zeigt sich darin diese Schönheit. Architektur ist für mich eigentlich so ein stilles Design unsichtbarer Dinge, die aber am Ende über alles entscheiden.

Und weißt du was noch? Manchmal, selbst wenn etwas schiefgeht – und das passiert gelegentlich –, kannst du trotzdem ein Gefühl von Erfolg haben. Denn wenn du rückblickend analysieren kannst, wo es nicht geklappt hat, und einen Weg findest, wie man es beim nächsten Mal vermeiden kann, bist du wieder einen Schritt weiter. Das ist dieser endlose Lernprozess. Und meiner Meinung nach: Wenn du in diesem Prozess das Interesse am Lernen verlierst, dann bist du fertig. Dann bist du nur noch Verwalter alter Entscheidungen.

Also freue ich mich eigentlich auch über die Momente, in denen etwas nicht klappt. Nicht über das Scheitern selbst, sondern darüber, dass ich die Möglichkeit habe zu verstehen, warum es passiert ist. Das ist für mich persönlich genauso wichtig wie die Momente, in denen alles zusammenpasst und funktioniert. Und das ist vielleicht die Eigenschaft, die den Architekten vom Entwickler oder Tester trennt. Der Architekt muss sich auch darum kümmern, was „danach“ passiert – wenn etwas kaputtgeht, wenn sich etwas verändert, wenn man das System erweitern, reparieren, verbinden muss. Denn ein System entsteht nicht nur einmal – es lebt. Und Architektur ist darüber, dass sie es nicht tötet.

Also ja, ich bin ein Enthusiast. Und ich habe immer noch das Gefühl, dass ich in diesem Lernprozess bin. Dass es nicht vorbei ist, dass es sich bewegt. Und wenn ich spüre, dass es sich bewegt – und ich mich mitbewege –, dass es wächst, dass es sich verändert und ich es verstehen oder beeinflussen kann, dann weiß ich, dass es immer noch Sinn hat.

Wenn du also zurückblickst: Glaubst du, dass du dich dieser idealen Vorstellung eines Softwarearchitekten irgendwie angenähert hast?

Das lässt sich wohl nicht ganz so sagen. Weißt du, es geht eher darum, was dir dabei hilft. Und oft ist es einfach Glück, den richtigen Menschen zu begegnen. Menschen, die dich irgendwohin weiterbringen, damit du nicht alles mit dem Kopf durch die Wand schlagen musst. Du weißt ja: Nicht alles muss man nur durch eigene Fehler lernen – manchmal ist es gut, wenn dir jemand etwas vorher sagt.

Ich hatte das Glück, mit ein paar wirklich fähigen Leuten zusammenzuarbeiten – egal ob das Coder waren, Analysten, Designer, Architekten … Menschen, die wussten, und vor allem schon etwas gesehen hatten. Und sie haben mir gezeigt, wie man Dinge besser, effizienter macht. Worauf man schauen soll, was man beachten soll. Das waren großartige Leute. Ihnen verdanke ich sicher auch vieles.

Du hast erwähnt, dass du in dieser Arbeit auch eine gewisse Kreativität hast, dass da immer Abstraktion dabei ist, auch etwas Mathematik. Was macht dir daran am meisten Spaß?

Weißt du was, ich glaube, das hat jeder ein bisschen anders. Aber für mich ist das Ermutigendste, Angenehmste, wenn das, was wir machen, am Ende tatsächlich funktioniert. Wenn das Ergebnis gelingt, wenn die Umsetzung – das System, das wir entworfen haben – wirklich das erfüllt, was wir wollten. Ja, manchmal sieht der Kunde gar nicht vollständig, was er dadurch alles gewonnen hat, aber wir sehen es. Wir sehen, dass es funktioniert, dass es sich so verhält, wie es sollte. Und das ist ein unglaublich gutes Gefühl. Ein starkes.

Aber gleichzeitig: Dieser „Erfolg“, diese Ermutigung kommt nicht sofort. Oft sieht man das erst später. Zum Beispiel bekommst du vom Kunden über den Analysten eine Liste von Anforderungen. Etwas, das irgendeinen Algorithmus oder Prozess erfüllen soll. Und jetzt liegt es an dir, das alles auseinanderzunehmen und Datenstrukturen, Implementierungswege zu entwerfen, die das alles abdecken.

Und wenn dir das gelingt, wenn du siehst, dass es wie ein Uhrwerk läuft, dann bist du zufrieden. Das ist sehr ermutigend. Nur ist der Weg dorthin natürlich ziemlich frustrierend. Denn manchmal findest du es einfach nicht. Manchmal hast du das Gefühl, du musst jedem immer wieder erklären, dass „das so nicht geht, weil es im Widerspruch zu dem und dem steht“. Und dem Kunden ist das oft nicht bewusst, weil man es auf den ersten Blick nicht sieht.

Weißt du, er sagt dir: „Ich will, dass ihr immer die älteste Ware aus dem Lager entnehmt.“ OK. Und dann sagt er: „Und es muss so schnell wie möglich gehen.“ Na gut, aber das muss nicht zusammenpassen. Denn wenn ich sofort an die älteste Ware will, muss ich vielleicht auf sie warten, sie unter anderer Ware hervorholen oder quer durchs halbe Lager laufen. Dann kann ich nicht den schnellsten Warenausgang erwarten. Nicht alle Anforderungen sind kompatibel – da braucht es ein Gleichgewicht.

Es ist wie in der Programmierung: Wenn du eine Aufgabe mit einer bestimmten Komplexität hast, hast du im Grunde nur zwei Möglichkeiten. Entweder du hast enorm viel Platz, Speicher, und machst es schnell, oder du hast wenig Speicher, und dann kostet es dich viel Rechenleistung. Irgendwo musst du investieren – entweder in Rechenkapazität oder in Speicher. Aber wenn du keines von beidem machst, wird es eben nicht schnell. Und in der Realität ist es dasselbe: Wenn du willst, dass das Lager schneller funktioniert, dann kauf dir ein größeres Lager. Aber das wird teuer.

Und das ist der Moment, in dem der Softwarearchitekt ins Spiel kommt: Beim Entwurf muss er über alle Prozesse nachdenken, die dort stattfinden. Über das komplexe Gesamtbild dessen, was passiert, was passieren wird, und welche Kompromisse akzeptabel sind. Und manchmal ist es einfach so, dass der Kunde „einen Knopf für alles“ will, und du musst ihm erklären, dass es so eine Software nicht gibt. Oder dass es sie gibt, aber sie wird eine Million kosten.

Also musst du beim Entwurf eigentlich das ganze System verstehen – was dort passiert –, nicht nur die Software, sondern die ganze Welt drum herum?

Nun … ja. Nur ist es nicht möglich, das ganze System bis ins letzte Detail im Kopf zu behalten. Das geht nicht. Das Lager wirkt auf den ersten Blick zwar einfach, ist innen aber ein sehr komplexer Organismus. Und weißt du, es ist, als hättest du eine Tasche mit Wasser. Dein Gehirn hat eine gewisse Kapazität, ein bestimmtes Volumen dessen, was es auf einmal verarbeiten kann. Und um dich herum hast du eine Menge Daten, Informationen, Prozesse.

Und manche sind nah an dem Problem, das du gerade löst – die musst du in der Tiefe verstehen. Andere sind weiter weg – die „ahnst“ du nur, du weißt, dass es sie gibt, aber du behandelst sie gerade nicht im Detail. Und je tiefer du in einen Teil eintauchst, desto mehr „drückt“ dir ein anderer Teil den Rest aus dem Kopf. Du musst also auswählen, was du gerade im Kopf behalten musst.

Und wenn du dir diese Prozesse ansiehst, gibt es verschiedene Arten von Interaktionen. Du hast zwei Prozesse, die dasselbe tun, aber in einem anderen Teil des Lagers. Du hast zwei Prozesse, bei denen das Ergebnis des einen der Input für den anderen ist. Und dann hast du den menschlichen Willen, stochastische Eingriffe. Etwas passiert, jemand ändert Prioritäten, blockiert etwas … Und im Entwurf musst du diese Möglichkeiten berücksichtigen. Du musst sie nicht immer lösen, aber du musst sie zumindest im Kopf haben.

Vielleicht sind auch wir nur ein gut entworfenes Modell

Und wenn du das alles durchdenkst und einen Entwurf machst, der die Hauptprozesse abdeckt … Hast du das Gefühl, dass man diese Welt vollständig verstehen kann?

Schwer. Uns hat es zum Beispiel etwa zehn Jahre gedauert, bis wir angefangen haben, das wirklich zu verstehen. Die ersten Versuche waren nicht ganz treffsicher. Das waren eher Simulationen, solche Experimente. Und ich weiß nicht, ob „Simulation“ überhaupt das richtige Wort ist.

Aber im Grunde musst du die reale Welt sehen, beobachten, was in ihr passiert. Und dann überlegen, was du davon in dein Modell übernehmen willst. Was wichtig ist und was nicht. Ja, ich habe da einen Lagerarbeiter – ist es wichtig, ob er blond ist oder nicht? Nein. Aber wichtig ist, wie schnell er reagieren kann, was er tun kann, wie er Systemausfälle bewältigt … Und das ist wichtig fürs Modell.

Denn ein Modell ist keine Beschreibung der Realität in jedem Detail, es ist nur ein Ausschnitt. Es geht darum, dass der Arbeitsplatz „Kommissionierung“ dies und das kann, auf solche Impulse so reagiert. Ob das Ganze Sinn ergibt, wenn man es zusammensetzt, siehst du erst später. Und manchmal ergibt es auch dann nur auf dem Papier Sinn.

Also … wenn du das so beschreibst – dass du als Architekt Modelle der realen Welt erstellst, die in einer digitalen Umgebung funktionieren, Regeln und Strukturen entwirfst und beobachtest, wie sich diese Entitäten verhalten –, dann bringt mich das zu der Frage, ob du denkst, dass es möglich ist, dass auch wir in einer Simulation leben?

Nun … Ich überlege, wie ich darauf richtig antworten soll. Die kurze Antwort ist: ganz sicher ja. Könnte sein. Zum Beispiel Matrix. Ja, das ist das einfache kulturelle Beispiel, aber … es steckt darin diese uralte philosophische Frage, was freier Wille ist und ob wir tatsächlich frei sind. Denn wenn wir eine Simulation wären, würde das bedeuten, dass wir nicht frei sind. Wir tun nur, was uns programmiert wurde. Ja, so als hätte jemand in der „Produktion“ unsere Gene festgelegt, und unsere Entscheidungen wären eigentlich nur rechnerisch vorherbestimmte Reaktionen auf gewisse Inputs.

Aber das ist die philosophische Ebene: Ob wir das Gefühl haben, frei zu handeln, oder ob wir nur eine Rolle in einem Szenario spielen. Und wir können es weder beweisen noch widerlegen. Denn selbst wenn du dir anschaust, wie das Gehirn funktioniert – wir wissen nicht, ob unsere Reaktionen rein biologisch sind oder etwas mehr. Und außerdem wirkt es auf den ersten Blick nicht vollständig deterministisch. Viele Dinge machen wir anders, auch wenn die Umstände ähnlich sind. Manchmal reagieren wir auf dieselbe Situation einmal so, ein anderes Mal ganz anders. Also ist die Frage, ob dieses System – wenn es also ein System ist – Zufall enthält, oder nur Chaos, das wir bislang nicht erklären können.

Also ist es eine schwierige Frage, aber … ja, ich kann mir vorstellen, dass wir Teil von so etwas sein könnten. Dass das, was ich mache – ein System zu schaffen, in dem sich Entitäten nach Regeln verhalten und mich manchmal überraschen –, dass das jemand mit uns genauso macht. Und wir sind nur diese Entitäten, die glauben, einen freien Willen zu haben. Oder anders gesagt: Vielleicht machen wir dasselbe, was dieser „jemand“ mit uns macht. Nur im Kleineren. Und durch das, was wir tun, lernen wir es vielleicht auch zu verstehen.

Und nein, das heißt noch nicht, dass ich glaube, dass hier alles von irgendeinem überirdischen Programmierer gesteuert wird. Aber die Vorstellung, dass unsere Welt ein Modell sein könnte, ist meiner Meinung nach völlig realistisch. Und vielleicht nicht ganz genau so, wie es Science-Fiction zeigt, aber im Prinzip … warum nicht? Schließlich: Wenn man sich anschaut, wie wir Software machen, beginnt das auch abstrakt. Entwurf, Regeln, Modelle … und dann läuft es. Und manchmal verhält es sich so, wie wir es wollten, und manchmal überrascht uns das System selbst. Weil darin neue Beziehungen, neue Situationen entstehen. Und vielleicht sind auch wir selbst nur ein so komplexes Ergebnis eines anderen Modells. Und irgendwo, vielleicht, stimmt jemand unsere Architektur ab.

Aber das ist wahrscheinlich schon mehr Metaphysik als Software.