Die richtige Software-Architektur wählen: Trade-offs meistern mit den 3 Ps (Problemverstehen, Planen, Programmieren)

Einleitung: Warum es keine perfekte Architektur gibt

In der Session „Die Wahl der richtigen Software Architektur“ von Alexander Knapp (Objectbay) lag eine klare Botschaft über allem: Es gibt nicht die perfekte Architektur. Entscheidend ist nicht, welches Muster „hip“ ist, sondern wie wir Entscheidungen treffen. Oder, wie Knapp es sinngemäß formulierte: Everything in software architecture is a trade-off. Wer Architektur nach Bauchgefühl auswählt – etwa reflexartig „Microservices, keine Frage“ – läuft Gefahr, sich in unnötigen Patterns zu verheddern und künftige Probleme geradezu einzubauen.

Wir bei DevJobs.at haben die Session als praxisnahen Leitfaden erlebt. Sie liefert eine klare Herangehensweise, um vom diffusen „Welche Architektur nehmen wir?“ zum präzisen „Wie wählen wir auf die richtige Art?“ zu kommen. Der rote Faden: die 3 Ps – Problemverstehen, Planen und dann erst Programmieren. Dazwischen stehen konkrete Methoden aus dem Domain-Driven-Design-Umfeld, handfeste Dokumentationstechniken und die stete Erinnerung, dass „Warum wichtiger ist als Wie“.

Vom Marktplatz der Architektur-Patterns zum echten Bedarf

Knapp zeichnet das Bild eines virtuellen Marktplatzes voller Architektur-Patterns: Monolith, Microservices, Serverless-Varianten („SecureOS“ wurde in der Session angesprochen), und viele weitere Ausprägungen. In diesem Überangebot gibt es kein „über allem stehendes“ Muster. Der Worst Case: ein Team greift zu einem bekannten Pattern, implementiert dessen typische Bausteine – und stellt später fest, dass sie zum eigentlichen Problem gar nicht passen. Der Ursprung des Übels liegt oft in der Reihenfolge der Fragen: statt zu klären, welche Charakteristika das System wirklich braucht, wird vorschnell „das Wie“ entschieden.

Die Alternative: Die Auswahlmethode selbst in den Mittelpunkt rücken. Nicht „Welche Architektur ist richtig?“, sondern „Wie kommen wir zur passenden Architektur für unser Problem, unseren Kontext und unsere Ziele?“ Genau dazu führt Knapp anhand einer klaren, dreistufigen Vorgehensweise.

Die 3 Ps im Überblick

• Problemverstehen: Was ist das eigentliche Problem? Wie oft, durch wen und unter welchen Bedingungen soll es gelöst werden? Welche Qualitätsattribute müssen erfüllt werden? Wie sieht der organisatorische Kontext aus?
• Planen: Modellieren mit Augenmaß. Tiefe dort, wo nötig. Illities konkretisieren. Architekturentscheidungen bewusst dokumentieren. Was-wäre-wenn-Fragen stellen. „Warum“ vor „Wie“.
• Programmieren: Proof-of-Concept, schnelle Schleifen, Stakeholder-Feedback, BDD/TDD. Alles iterativ und „good enough“ – aber zielgerichtet.

Im Folgenden vertiefen wir jeden Schritt und fassen die praxistauglichen Werkzeuge zusammen, die Alexander Knapp dazu empfohlen hat.

Schritt 1: Problemverstehen – die richtigen Fragen vor den ersten Diagrammen

Der Startpunkt ist überraschend „unspektakulär“ – und zugleich entscheidend. Bevor Module, Services und Datenflüsse entstehen, muss das Team das Problem aus mehreren Blickwinkeln aufgefächert haben. In Knapps Worten: Erst durch Nachfragen bei Auftraggebern, Stakeholdern und Nutzerinnen/Nutzern kommen oft Aspekte zum Vorschein, die das zuerst „trivial“ wirkende Problem völlig neu rahmen.

Nutzungsszenarien und Lastprofil

• Wie oft wird das Problem gelöst? Eine einmal täglich ausgeführte Batch-Anwendung hat völlig andere Architekturansprüche als ein 24/7-System mit hoher Verfügbarkeit.
• Wie viele gleichzeitige User sind realistisch? Handelt es sich um ein Tool für wenige Fachanwender oder um eine Plattform für Millionen Benutzer pro Tag?
• Ist das Problem tatsächlich komplex – oder reicht ein simples Skript auf einer Workstation?

Diese Fragen bringen schnell die relevanten Qualitätsattribute („Illities“) auf den Tisch: Skalierbarkeit, Beobachtbarkeit/Observability, Wartbarkeit/Maintainability – und Leistungsmerkmale wie Durchsatz (Throughput). Wer hier ehrlich einschätzt, was wirklich benötigt wird, kann später bewusst abwägen. Ein Beispiel aus der Session: Hohe Skalierbarkeit schließt die Lösung als Einzelskript praktisch aus und verlangt nach einem tragfähigen Architektur-Pattern.

Organisatorischer Kontext

• Wie sieht die bestehende Systemlandschaft beim Kunden aus? Eine Standalone-Startup-App folgt anderen Zwängen als ein Enterprise-System, das über Jahre in verschiedenste Services integriert werden muss.
• Wie groß ist das Entwicklungsteam? Vier Personen, ein Zehnerteam oder hunderte Teams weltweit? Zehn Services mit nur vier Entwicklerinnen/Entwicklern zu betreuen, kann zur permanenten Unterdeckung werden. Umgekehrt können viele Teams von entkoppelten Services profitieren.
• Wie wird die Organisation voraussichtlich wachsen? Bleibt sie stabil und überschaubar – oder skaliert sie stark? Die Architektur muss diese Trajektorie mitdenken.

Geschäftswert vor Entwicklerlust

Knapp adressiert einen häufigen Fehltritt: Architektur „für den Spaß am Entwickeln“. Eine fancy Lösung, die zwei Jahre bis zum ersten Marktfeedback braucht oder die Kosten explodieren lässt, verfehlt den Auftrag. Die Architektur muss dem Geschäftszweck dienen – Time-to-Market und TCO inklusive.

Werkzeuge zum Problemverstehen

• Business-Model-Canvas: Ein einfaches einseitiges Schema aus dem Management-Kontext, das im Domain-Driven-Design-Umfeld gern zur High-Level-Orientierung verwendet wird. Es hilft, Ist und Zielbild greifbar zu machen.
• Event-Storming: Post-its auf dem Whiteboard für Ereignisse, Akteure und Systemteile. Noch ohne Technologieentscheidungen – es geht nur um das Verstehen des Prozesses und der Domäne.
• Domain-Storytelling: Ähnlich, oft noch etwas abstrakter. Die Interaktion zwischen Nutzerinnen/Nutzern und System in Geschichten erfassen.
• User-Story-Mapping: Gemeinsam mit dem Auftraggeber die großen Use-Cases und ihre Zerlegung strukturieren. So entsteht schnell ein geteiltes Verständnis über Umfang, Prioritäten und erste Schnitte.

Unser Eindruck: In Summe erzeugen diese Techniken eine robuste Grundlage für alle folgenden Entscheidungen. Sie verschieben den Fokus weg von „Wir könnten X bauen“ hin zu „Wir müssen Y können“.

Schritt 2: Planen – modellieren, dokumentieren, begründen

Ist das Problemraum sauber verstanden, beginnt die Architektur zu entstehen. Knapp strukturiert diese Phase mit drei Akzenten: Illities konkretisieren, Architektur sichtbar machen, Entscheidungen begründen und festhalten.

Illities: vom Bauchgefühl zur bewussten Anforderung

• Skalierbarkeit: Welche Lastspitzen, welche horizontale/vertikale Skalierung sind realistischerweise zu tragen?
• Durchsatz: Welche Transaktionsraten sind nötig? Wo sind Engpässe wahrscheinlich?
• Wartbarkeit: Wie bleiben Änderungen über den Lebenszyklus handhabbar?
• Observability: Wie behalten wir Verhalten, Fehler und Performance im Blick?

Hier wird aus den Antworten aus Schritt 1 eine technische Zielkurve. Sie leitet die Modellierung – und setzt Leitplanken gegen unnötige Komplexität.

Modellierung mit C4 – vom Big Picture bis zum Ablauf

Knapp empfiehlt die C4-Notation, weil sie verschiedene Zoomstufen ermöglicht – ganz wie bei Google Maps:

• Kontextsicht: Wer interagiert mit dem System? Welche externen Systeme gibt es?
• Container- und Komponentensicht: Wie teilt sich das System in beherrschbare Bausteine?
• Detailebene: Später, wenn nötig, Sequenzen und Abläufe im Code beschreiben.

Wichtig: Nicht jeder Teil braucht sofort maximale Tiefe. C4 erlaubt es, Stakeholdern das „Warum“ hinter den Schnitten zu zeigen – und dem Team das „Wie“ für die Umsetzung zu präzisieren.

UML oder „Kästen und Pfeile“ – was hilft, ist richtig

Wenn UML vertraut ist, lässt sich in dieser Phase tiefer modellieren. Ist das nicht der Fall, reichen auch einfache Diagramme. Die Regel: Visualisieren, was für Diskussion und Verständnis nötig ist.

Dokumentation: arc42 und ADRs

• arc42: Ein erprobtes Template, um Architekturentscheidungen strukturiert zu dokumentieren – inklusive Kontext, Qualitätszielen und Randbedingungen.
• ADRs (Architectural Decision Records): Kurz und prägnant festhalten, welche Option gewählt wurde – mit Datum, Begründung und Konsequenzen. Entscheidend ist nicht Unfehlbarkeit, sondern Transparenz: Entscheidungen sind Momentaufnahmen und können später durch neue ADRs revidiert werden.

„Was wäre, wenn …?“ – Systemfragen als Stresstest

Knapp prägte die Planungsphase mit gezielten Gegenfragen an den Entwurf:

• Was passiert, wenn aus 100 täglichen Nutzerinnen/Nutzern 10.000 werden?
• Was, wenn statt einem Produkt plötzlich 20 über die Software verkauft werden?
• Was, wenn neue Mandanten dazukommen und Mandantenfähigkeit gefragt ist?

Diese hypothetischen Szenarien zeigen früh, wo Schnitte, Datenflüsse oder Abhängigkeiten wackeln.

Zweites Gesetz der Softwarearchitektur: Das Warum schlägt das Wie

Knapp betont, dass Teams zu häufig beim „Wie“ starten – Tools, Patterns, Frameworks. In der Planungsphase muss das „Warum“ die Richtung vorgeben: Warum brauchen wir genau diese Schnittkante? Warum diese Kommunikationsart? Warum ist dieses Qualitätsziel vorrangig? Diese Begründung schützt vor Selbstzweck-Architektur.

Vom Modell in Richtung Code: Aggregate, Transaktionen, Kommunikation

Aus dem Domain-Driven-Design-Umfeld nennt Knapp das Aggregate Canvas als Werkzeug, um früh wichtige Strukturen zu klären:

• Welche Aggregate gibt es und wie sind sie abgegrenzt?
• Wie kommunizieren Komponenten miteinander?
• Welche Transaktionen gibt es, wie häufig treten sie auf, und was passiert nach einer geschriebenen Transaktion?

Ziel ist nicht Perfektion, sondern die Robustheit der Grundstruktur zu prüfen, bevor Code entsteht.

Schritt 3: Programmieren – Proof-of-Concept, Iteration, „good enough“

Jetzt wird gebaut – aber weiterhin mit Testcharakter. Knapps Empfehlung: mit einem Proof-of-Concept starten.

PoC als Whirlpool: kurz eintauchen, prüfen, anpassen

• Minimaler Start: Modulstruktur, erste Dummy-Implementierungen.
• Durchspielen gegen die Anforderungen und Illities: Hält der Entwurf den Erwartungen stand?
• Wenn tragfähig, Funktionsumfang iterativ erweitern.
• Laufende Rückkopplung mit Stakeholdern sicherstellen.

Das Leitmotiv: good enough. Nicht alles bis in die letzte Ecke durchdenken, sondern auf Basis des aktuellen Wissens den besten praktikablen Schritt gehen – und dann mit Lerngewinnen weiterjustieren.

BDD + TDD + Gherkin: Anforderungen schärfen, Risiken senken

Knapp schlägt vor, Behavior-Driven Development mit Test-Driven Development zu verknüpfen:

• Anforderungen in Gherkin-artiger Syntax grob festhalten.
• Tests daraus ableiten.
• Implementierung iterativ nachziehen.

So spiegeln sich Domäne und Qualitätsziele früh im Code wider, und Unsicherheiten werden mit jeder Iteration kleiner. Übergreifend gilt: Architektur ist kein Big-Bang, sondern ein kontinuierlicher Prozess – vom Problem über Planung zum Programmieren und wieder zurück.

Häufige Fragen und Missverständnisse – klar adressiert

Die Session schloss mit prägnanten Einordnungen zu gängigen Architekturdebatten.

„Microservice oder Monolith?“ – die falsche Frage

Es gibt mehr als diese beiden Extreme – und Mischformen sind legitim. Knapp nennt den modularen Monolithen („Modulith“) als Beispiel: eine einzelne Laufzeiteinheit, intern sauber modularisiert. So lassen sich Vorteile der Microservices (klare Schnitte, übersichtliche Module) mit der Einfachheit eines Monolithen verbinden. Entscheidend ist der Bedarf im Kontext des Teams und der Organisation.

„Ist das nicht Overengineering?“ – scheinbar am Anfang, langfristig notwendig

Gerade jüngere Teams empfinden saubere Architekturarbeit anfangs als „zu viel“. Knapp hält dagegen: Ziel der Softwarearchitektur ist es, Systeme so zu bauen, dass sie veränderbar bleiben. Wenn nach drei Monaten keine Änderung mehr möglich ist, war die Architektur falsch. Robustheit gegenüber Veränderung ist kein Luxus, sondern Kernziel.

„Welche ist die richtige Architektur?“ – es kommt darauf an

Die einzig richtige Architektur gibt es nicht. Stattdessen geht es um bewusste Trade-offs: Liegt die Priorität auf niedrigen Kosten, schneller Lieferung, maximaler Skalierung – oder einer ausgewogenen Balance? Knapp bringt ein prägnantes Bild: Ein Landwirt sollte seinen Acker nicht mit einem Formel-1-Wagen pflügen. Einzelne Vorteile ändern nichts daran, dass der Zweck verfehlt wird.

„Architektur ändert sich doch nicht mehr, oder?“ – doch, und das ist gesund

Architektur ist iterativ. Gute Architektur erkennt man auch daran, dass sie sich weiterentwickeln kann. Wer regelmäßig prüft, ob der eingeschlagene Weg noch trägt, trifft bessere Entscheidungen – und kann umrüsten, wenn der Kontext es verlangt.

„Es gibt nur ein Muster fürs ganze System.“ – selten sinnvoll

Ein System kann heterogen sein. Services lassen sich gezielt herauslösen, ohne sofort „volle Microservices“ fahren zu müssen. Mischformen sind normal – solange sie bewusst begründet werden.

Praxis-Checkliste: Leitfragen für die Auswahl der Architektur

Aus der Session lässt sich eine komprimierte Fragensammlung ableiten, die Teams vor jeder Architekturwahl beantworten sollten:

• Nutzung und Last
• Wie oft wird das System genutzt (Batch vs. 24/7 mit hoher Verfügbarkeit)?
• Wie viele gleichzeitige Benutzer sind realistisch – heute und perspektivisch?
• Welche Durchsatzanforderungen sind kritisch?
• Problemkomplexität
• Reicht ein Skript, oder ist ein Architektur-Pattern nötig?
• Welche Domänenteile sind wirklich komplex?
• Organisatorischer Kontext
• Welche bestehenden Systeme und Technologien müssen integriert werden?
• Wie groß ist das Team, wie verteilt, mit welcher Erfahrung?
• Wie wird die Organisation wachsen (stabil, moderat, stark)?
• Geschäftsziele
• Welche Time-to-Market ist erforderlich?
• Welche Kostenrahmen sind akzeptabel – initial und im Betrieb?
• Welche Qualitätsattribute haben Priorität (Skalierung, Wartung, Observability)?
• Architekturverifikation
• Welche „Was-wäre-wenn“-Szenarien gefährden unseren Entwurf?
• Welche ADRs dokumentieren die zentralen Entscheidungen – und ihre Gründe?
• Wie spiegelt sich das „Warum“ in C4/Modellen und PoCs wider?

Entscheidungs- und Dokumentationsroutine etablieren

Ein Kern-Learning aus Knapps Vortrag: Gute Architektur entsteht nicht durch einmalige Genialität, sondern durch Routine in Begründung und Feedback.

• Visualisieren: C4 für die richtige Flughöhe, bei Bedarf UML oder einfache Diagramme.
• Dokumentieren: arc42 als Struktur, ADRs für konkrete Entscheidungen.
• Prüfen: „Was-wäre-wenn“-Fragen regelmäßig stellen, Stakeholder aktiv einbinden.
• Iterieren: PoCs bauen, BDD/TDD einsetzen, „good enough“ zulassen – aber bewusst.

Diese Routine macht Entscheidungen nachvollziehbar – intern fürs Team wie extern gegenüber Stakeholdern – und hält Anpassungen leichtgewichtig.

Schlussgedanken: Aus „Wie bauen wir?“ wird „Warum und wofür bauen wir?“

Die Session „Die Wahl der richtigen Software Architektur“ von Alexander Knapp (Objectbay) rückt die Disziplin dorthin, wo sie hingehört: an die Schnittstelle zwischen Geschäftsanforderung, Teamrealität und Technik. Das Leitmotiv „Everything in software architecture is a trade-off“ wird hier zur Handlungsanweisung: erst Problemverstehen, dann Planen, dann Programmieren – und zwar iterativ.

Für uns bei DevJobs.at sind drei Punkte besonders hängen geblieben:

• Die beste Architektur ist jene, deren Gründe sauber geklärt und dokumentiert sind.
• Mixed Patterns sind normal – „Microservice oder Monolith?“ ist eine Scheinfrage.
• Veränderbarkeit ist das Zielbild. Overengineering ist es dann, wenn wir Gründe und Ziele aus den Augen verlieren – nicht, wenn wir Änderungen ermöglichen.

Kurz: Statt vorschnell ein Muster zu wählen, sollten Teams systematisch entscheiden. Die 3 Ps liefern das Gerüst, C4/arc42/ADRs die Sichtbarkeit, PoCs/BDD/TDD das Feedback. So wird Architektur nicht Selbstzweck, sondern eine belastbare Brücke zwischen Problem und Produktwert.

• 

  

  Serverless Applications with AWS Lambda

  Thomas Jäger von Objectbay geht in seinem devjobs.at TechTalk zu dem Thema Serverless Applications in die Tiefe und überprüft, ob die Marketing Slides von Amazon auch halten was sie versprechen.

  Jetzt ansehen
• 

  

  Microservices for Front Ends

  Michael Eder von Objectbay spricht in seinem devjobs.at TechTalk über einen Ansatz, wie man die gängige Architektur der Microservices auch im Front End anwenden könnte.

  Jetzt ansehen
• 

  

  Mutation Testing

  Alexander Knapp von Objectbay widmet sich in seinem devjobs.at TechTalk dem Thema Mutation Testing – was es ist und wie jedes Software Projekt davon profitieren kann.

  Jetzt ansehen

• 

  

  Alexander Knapp, Full Stack Software Engineer bei Objectbay

  Alexander Knapp von Objectbay schildert im Interview seinen Werdegang bis hin zu seiner aktuellen Rolle im Full Stack Engineering und was seiner Meinung nach für Beginner wichtig ist.

  Jetzt ansehen