Trade-off-Analyse
Eine Trade-off-Analyse macht sichtbar, welche Ziele eine Option stärkt und welche Kosten sie mit sich bringt. Sie verbindet Kriterien mit einer nachvollziehbaren Empfehlung.
- KriterienWoran Varianten gemessen werden.
- KostenJede Option hat eine Gegenseite.
- TreiberDer Kontext entscheidet.
Einordnung
Warum das wichtig ist
Ohne benannte Kriterien fällt die Strukturwahl nach Vorlieben oder Trends. Ein Vergleich zeigt, was eine Variante gewinnt und was sie kostet. Wie der Beschluss festgehalten wird, zeigen Architekturentscheidung und ADR.
Dieser Baustein strukturiert den Vergleich. Architekturentscheidung hält die gewählte Option und Gründe fest; ADR dokumentiert den resultierenden Beschluss.
Auf einen Blick · Optionen gegen Kriterien
Shopstruktur nach konkreten Kriterien
Der Shop prüft eine modulare Monolithstruktur und unabhängig bereitgestellte Dienste. Das Team vergleicht Änderungsautonomie mit Betriebs- und Netzwerkaufwand.
So liest du das Bild
- Kriterien Zeilen wie „Bereitstellung“, „Betriebsverantwortung“ und „Datenkonsistenz“.
- Kosten Spalte „Variante: getrennte Services“: „Netzwerkverträge mit Latenz und Fehlerfällen“.
- Treiber Zeile „Passender Treiber“: kleine Teams gegen nachgewiesenen Bedarf für unabhängige Bereitstellung.
| Kriterium | Modularer Monolith – Baseline | Variante: getrennte Services |
|---|---|---|
| Bereitstellung | Ein Shop-Artefakt | Dienste einzeln bereitstellbar |
| Laufzeitkommunikation | Modulvertrag im Prozess | Netzwerkverträge mit Latenz und Fehlerfällen |
| Betriebsverantwortung | Gemeinsame Anwendung betreiben | Pro Dienst Metriken, Alarmierung und Bereitschaft |
| Datenkonsistenz | Lokale Transaktionen innerhalb der Anwendung | Verteilte Abläufe und Abgleichregeln |
| Passender Treiber | Kleine Teams und gemeinsame Releasefähigkeit | Nachgewiesener Bedarf für unabhängige Bereitstellung |
Nutzen & Grenzen
Hilft, wenn
- Alternativen verteilen Qualität, Aufwand und Risiko unterschiedlich zwischen Entwicklung, Betrieb und Nutzung.
- Folgenreiche Entscheidungen benötigen einen expliziten Vergleich von Unsicherheit, Randbedingungen und Umkehrkosten.
Grenzen
- Gewichtete Punktwerte können zwingende Randbedingungen verdecken; Muss-Kriterien werden vor jeder Bewertung geprüft.
- Unsichere Annahmen verändern die Rangfolge; sensible Werte variieren oder vor der Festlegung messen.
- Der Vergleich ersetzt nicht die Entscheidung; festgehalten wird sie als ADR, geprüft mit Fitness Functions.
In der Praxis
- Vergleichsmaßstab übernehmen. Verwende bereits konkretisierte Qualitätsziele und verbindliche Randbedingungen. Prüfe, ob alle Alternativen unter denselben Bedingungen beurteilt werden. Die Ausarbeitung messbarer Szenarien vertieft der Baustein Qualitätsattribute.
- Alternativen und Randbedingungen prüfen. Erfasse praktikable Optionen, Ausschlussgründe und Folgen für Betrieb sowie Änderung. Unterscheide Messwerte von Schätzungen. Damit wird erkennbar, welche Wahlmöglichkeiten tatsächlich offen sind.
- Vergleich und Unsicherheit aufbereiten. Stelle Zielerfüllung, Umkehrkosten und sensible Annahmen nebeneinander. Benenne, welche zusätzliche Erkenntnis die Bewertung verändern könnte. Übergib diese Grundlage an die Architekturentscheidung, in der die verantwortliche Wahl getroffen wird.
Ausführliche Erklärung lesen
Eine Trade-off-Analyse macht sichtbar, wie Entwurfsoptionen mehrere Ziele gleichzeitig beeinflussen. Sie übernimmt die messbaren Ziele aus den Qualitätsattributen, prüft verbindliche Randbedingungen und vergleicht praktikable Alternativen nach Nutzen, Aufwand und Risiko. Ausschlusskriterien begrenzen die Auswahl; verhandelbare Ziele werden nach ihrer Bedeutung gewichtet.
Annahmen und Messwerte werden getrennt ausgewiesen. Eine Sensitivitätsprüfung untersucht, welche Änderungen an Last, Kosten oder Toleranz die Bewertung verändern würden. Kleine Experimente können solche Unsicherheiten reduzieren. Das Ergebnis ist ein begründeter Vergleich mit erkennbaren Zielkonflikten und offenen Fragen. Er liefert die Grundlage für die anschließende Architekturentscheidung.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Welche Datenkonsistenz hat die Variante mit getrennten Services?
Lösung mit Begründung ansehen
Verteilte Abläufe und Abgleichregeln. Der modulare Monolith nutzt lokale Transaktionen innerhalb der Anwendung.
AnwendenAuf eine neue Lage übertragen
Die Zahlungsfunktion braucht nachweislich unabhängige Bereitstellung, der Rest nicht. Welche Folgerung ziehst du?
Lösung mit Begründung ansehen
Der Treiber „unabhängige Bereitstellung“ trifft nur für Zahlung zu. Prüfe eine gezielte Servicevariante für diese Fähigkeit und lass die übrigen Module im modularen Monolithen.
BewertenEine Alternative abwägen
Das Team will alle Module sofort als Services bauen, um später flexibel zu sein. Wie bewertest du das?
Lösung mit Begründung ansehen
Der mögliche Autonomiegewinn ist nicht belegt, die Kosten für Betrieb, Netzwerk und Konsistenz fallen aber sofort an. Ohne nachgewiesenen Bedarf ist die Baseline die bessere Ausgangsbasis.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- SEI – ATAM: Method for Architecture Evaluation (öffnet in neuem Tab)Beschreibt die szenariobasierte Bewertung von Qualitätszielen, Risiken und Zielkonflikten.
- arc42 – Quality Requirements (öffnet in neuem Tab)Hilft, Qualitätsziele als prüfbare Szenarien für Architekturentscheidungen zu beschreiben.
- Microsoft – Performance Efficiency tradeoffs (öffnet in neuem Tab)Vergleicht Auswirkungen von Leistungsentscheidungen auf Kosten, Sicherheit und Zuverlässigkeit.