Ethik, Nachhaltigkeit und der Business Case

Warum Architekten Business Cases brauchen

Architekturarbeit konkurriert um Geld und Personal mit allem anderen, was eine Organisation tun will. Eine Migration, eine Plattform, ein Resilienzprogramm oder der Abbau von Schulden bringt selten ein Feature hervor, das Kunden sehen, also lässt sie sich leicht zugunsten von Arbeit verschieben, die das tut. Die Architekten, die solche Arbeit finanziert bekommen, haben meist nicht die elegantesten Designs, sondern können den Fall in den Begriffen darlegen, mit denen Entscheider Investitionen vergleichen: was es kostet, was es einbringt, wie schnell, wie sicher und was passiert, wenn wir es nicht tun. Dieses strukturierte Argument ist ein Business Case.

Das ist die geschäftliche Seite von allem, was dieser Kurs über Abwägungen gesagt hat. Ein Business Case ist ein Entscheidungsdokument für eine Investition: Kontext, Optionen, Kriterien, Konsequenzen und eine Empfehlung, wobei die Konsequenzen so weit wie möglich in Geld, Zeit und Risiko ausgedrückt werden. Er ersetzt nicht das architektonische Urteil, und vieles, was Architektur schützt (Sicherheit, Lernen, Optionalität), lässt sich schwer mit einem Preis versehen. Doch wer ehrliche Zahlen nennt, wo es möglich ist, und klar sagt, wo nicht, verdient sich das Recht, auch beim Rest gehört zu werden.

Organisationen nutzen unterschiedliche Formate. Das Green Book der britischen Regierung, herausgegeben vom HM Treasury, gliedert Fälle im öffentlichen Sektor nach fünf Fragen: der strategische Fall (warum Veränderung nötig ist), der wirtschaftliche Fall (welche Option das beste Preis-Leistungs-Verhältnis bietet), der kaufmännische Fall (ob es sich beschaffen lässt), der finanzielle Fall (ob es bezahlbar ist) und der Management-Fall (ob es umsetzbar ist). Die meisten Unternehmen nutzen etwas Leichteres, doch es lohnt sich, dieselben Fragen für jede bedeutende Architekturinvestition zu beantworten.

Optionen, Kosten, Nutzen und Risiken

Jeder Business Case sollte mindestens drei Optionen vergleichen: Nichtstun (die Ausgangsbasis), das Minimum tun und die empfohlene Option, dazu alle ernsthaften Alternativen. Nichtstun ist selten kostenlos. Der Supportvertrag des Altsystems wird teurer, die Incident-Rate wächst mit dem Traffic, und Änderungen werden immer langsamer; diese Entwicklung ist die Ausgangsbasis, an der der Nutzen der anderen Optionen gemessen wird, und wer sie weglässt, lässt jede Investition schlechter aussehen, als sie ist.

Kosten und Nutzen sollten nach Kategorien aufgeführt werden, damit nichts vergessen und nichts doppelt gezählt wird. Risiken gehören ausdrücklich in den Business Case: sowohl die Risiken, die die Investition verringert, und die sich als vermiedene erwartete Verluste bewerten lassen (Wahrscheinlichkeit mal Auswirkung), als auch die Risiken der Investition selbst, etwa Überschreitungen oder Störungen während der Migration. Don Reinertsens Cost of Delay aus The Principles of Product Development Flow (2009) ist eine nützliche zusätzliche Perspektive: der Wert, der jede Woche verloren geht, in der eine Arbeit nicht geliefert ist. Teilt man die Cost of Delay durch die Dauer (Weighted Shortest Job First), erhält man eine gut begründbare Reihenfolge für konkurrierende Arbeiten.

Strukturieren Sie die Investition schließlich als Folge von Stufen mit Entscheidungspunkten statt als eine große Verpflichtung. Die schrittweise Migration in Abschnitt 11.6 ist ein gutes Beispiel: Jeder Schritt liefert etwas und erzeugt Belege, sodass Mittel Schritt für Schritt freigegeben und das Programm gestoppt werden kann, wenn der Nutzen ausbleibt. Solche Stage Gates verwandeln eine riskante Wette in eine Reihe kleinerer Optionen; das ist das Denken in Umkehrbarkeit aus Abschnitt 1.6, angewandt auf Geld.

Kapitalwert und Amortisationszeit

Geld jetzt ist mehr wert als Geld später: Es lässt sich investieren, und späteres Geld ist unsicherer. Um Zahlungsströme aus verschiedenen Jahren zu vergleichen, rechnen Finanzteams jeden in seinen heutigen Wert um, mit einem Diskontsatz, der die Kapitalkosten der Organisation und das Risiko der Investition widerspiegelt. Der Satz wird normalerweise von der Finanzabteilung festgelegt, und Architekten sollten ihn verwenden, statt einen eigenen zu wählen.

Der Kapitalwert einer Investition ist die Summe all ihrer Zahlungsströme, jeweils auf heute diskontiert: NPV = Σ C_t ÷ (1 + r)^t, summiert über die Jahre t = 0 bis n, wobei C_t der Netto-Zahlungsstrom in Jahr t ist (negativ für Kosten) und r der jährliche Diskontsatz. Der Zahlungsstrom in Jahr 0 ist die Anfangsinvestition und wird nicht diskontiert. Ein positiver Kapitalwert bedeutet, dass die Investition mehr einbringt als den Diskontsatz; bei der Wahl zwischen Optionen mit ähnlichem Risiko schafft diejenige mit dem höchsten Kapitalwert den meisten Wert.

Die Amortisationszeit ist einfacher: wie lange es dauert, bis der kumulierte Zahlungsstrom positiv wird. Führungskräfte mögen sie, weil sie leicht verständlich ist und das Risiko grob erfasst (je früher das Geld zurück ist, desto weniger kann schiefgehen), aber sie ignoriert alles nach dem Amortisationszeitpunkt. Die diskontierte Amortisationszeit führt dieselbe Rechnung mit diskontierten Zahlungsströmen durch. Stellen Sie Kapitalwert und Amortisationszeit dar und zeigen Sie, wie empfindlich beide auf die wichtigsten Schätzungen reagieren.

def npv(rate, cash_flows):
    """cash_flows[0] is year 0 (the investment, usually negative)."""
    return sum(c / (1 + rate) ** t for t, c in enumerate(cash_flows))

flows = [-420_000, 150_000, 190_000, 190_000, 190_000]
print(round(npv(0.10, flows)))        # 145911
print(round(npv(0.15, flows)))        # 87663

pessimistic = [flows[0]] + [c * 0.7 for c in flows[1:]]
print(round(npv(0.10, pessimistic)))  # -23862

Technische Schulden in Geld und Zeit

Abschnitt 1.7 erklärte technische Schulden als Tilgungssumme (die Kosten, ein Problem zu beheben) und Zinsen (die Mehrkosten, die bei jeder Änderung anfallen, solange es besteht), und schätzte die Zinsen für ein verworrenes Modul. Ein Business Case braucht dieselben Größen in einer Form, die die Finanzabteilung kennt. Die Zinsen werden zu jährlichen Kosten, die Tilgungssumme wird zur Investition, und die Rückzahlung der Schulden wird zu einer Investition, deren Ertrag die nicht mehr gezahlten Zinsen sind, plus etwaige Risikominderung und ermöglichte Chancen.

Mehrere Arten von Belegen lassen sich umrechnen. Entwicklerzeit: zusätzliche Tage pro Änderung, aus Vergleichen mit ähnlichen Änderungen an anderer Stelle oder aus Schätzungen der Entwicklerinnen und Entwickler, multipliziert mit dem Änderungsvolumen und einem Vollkosten-Tagessatz. Verzögerung: längere Durchlaufzeiten mal Cost of Delay der betroffenen Arbeit. Incidents: Anzahl und Dauer der auf die Schulden zurückgeführten Incidents, multipliziert mit ihren Kosten. Risiko: Wahrscheinlichkeit und Auswirkung der Ausfälle, die die Schulden wahrscheinlicher machen, etwa ein Sicherheitsvorfall über eine nicht mehr unterstützte Komponente. Chancen: Geschäftsinitiativen, die die Schulden ganz blockieren.

Seien Sie vorsichtig mit den Schuldenzahlen statischer Analysetools, die typischerweise einen geschätzten Behebungsaufwand angeben (wie lange es dauern würde, jedes gemeldete Problem zu beheben). Das ist eine Schätzung der Tilgungssumme, nicht der Zinsen, und sie sagt nichts darüber, ob der Code überhaupt je geändert wird. Schulden in selten angefasstem Code kosten wenig; die Hotspots aus Abschnitt 1.7 sind die Stellen, an denen tatsächlich Zinsen gezahlt werden und an denen die Rückzahlung den besten Ertrag bringt. Schulden als Portfolio kleiner Investitionen darzustellen, jede mit geschätztem Ertrag und Amortisationszeit, überzeugt meist weit mehr als eine einzige Schlagzeilenzahl für die Gesamtschulden.

Ethik: was die Berufskodizes verlangen

Architekturentscheidungen prägen, was Systeme mit den Menschen machen, die sie nutzen, und mit denen, die sie ohne deren Zustimmung betreffen; daher tragen Architekten neben technischer auch ethische Verantwortung. Zwei Berufskodizes sind besonders relevant. Der ACM Code of Ethics and Professional Conduct, 2018 von der Association for Computing Machinery aktualisiert, beginnt mit allgemeinen Grundsätzen: zur Gesellschaft und zum menschlichen Wohlergehen beitragen und dabei anerkennen, dass alle Menschen Stakeholder der Informatik sind; Schaden vermeiden; ehrlich und vertrauenswürdig sein; fair sein und aktiv gegen Diskriminierung vorgehen; die Arbeit respektieren, die neue Ideen erfordern; die Privatsphäre respektieren; und Vertraulichkeit wahren. Zu den beruflichen Pflichten gehören umfassende und gründliche Bewertungen von Computersystemen und ihren Auswirkungen, einschließlich einer Analyse möglicher Risiken, sowie der Entwurf von Systemen, die robust und benutzbar sicher sind; die Führungsgrundsätze verlangen besondere Sorgfalt bei Systemen, die Teil der Infrastruktur der Gesellschaft werden.

Der BCS Code of Conduct von BCS, The Chartered Institute for IT im Vereinigten Königreich, ist um vier Pflichten herum aufgebaut: gegenüber dem öffentlichen Interesse (einschließlich öffentlicher Gesundheit, Privatsphäre, Sicherheit, Wohlergehen, Umwelt und gleichberechtigtem Zugang), gegenüber beruflicher Kompetenz und Integrität, gegenüber der maßgeblichen Stelle (Arbeitgeber oder Auftraggeber) und gegenüber dem Berufsstand. Der gemeinsame Software Engineering Code of Ethics von ACM und IEEE Computer Society (1999) ergänzt acht Grundsätze, beginnend mit dem öffentlichen Interesse, das Vorrang vor den Interessen von Auftraggeber und Arbeitgeber hat.

Für Architekten werden diese Kodizes zu konkreten Pflichten. Analysieren Sie die vorhersehbaren Auswirkungen eines Designs, nicht nur seine funktionale Korrektheit. Informieren Sie Entscheider ehrlich über Risiken, auch über solche, die sie lieber nicht hören würden. Weigern Sie sich, Systeme zu entwerfen, die täuschen oder schaden sollen, und eskalieren Sie, wenn Sie darum gebeten werden. Halten Sie Dissens aus ethischen Gründen im Entscheidungsdokument fest. Und wissen Sie, an wen Sie sich wenden können, wenn die interne Eskalation scheitert: Im Vereinigten Königreich zum Beispiel schützt der Public Interest Disclosure Act 1998 Beschäftigte, die bestimmte Arten von Fehlverhalten melden.

Dark Patterns und andere vorhersehbare Schäden

Die Tabelle nennt die Schäden, die am häufigsten im Einflussbereich eines Architekten liegen. Mehrere werden an anderer Stelle ausführlich behandelt: Datenschutz und Sicherheit in Kapitel 8, Barrierefreiheit als Qualität in Abschnitt 2.7 und Bias in Systemen des maschinellen Lernens in Kapitel 12. Barrierefreiheit ist zunehmend eine rechtliche wie auch eine ethische Randbedingung; in der EU gilt der European Accessibility Act seit dem 28. Juni 2025 für viele Verbraucherdienste, darunter den elektronischen Geschäftsverkehr.

Manipulatives Design verdient besondere Erwähnung, weil es oft bewusst verlangt wird. Harry Brignull prägte 2010 den Begriff Dark Pattern für Oberflächen, die Menschen zu Entscheidungen verleiten sollen, die sie sonst nicht treffen würden; heute bevorzugt er den Begriff Deceptive Patterns. Bekannte Beispiele sind Drip Pricing (Gebühren, die erst am Ende auftauchen), Confirmshaming (die Nein-Option soll beschämend wirken), falsche Dringlichkeit und Knappheit, vorangekreuzte Einwilligungskästchen und Abonnements, die leicht abzuschließen und schwer zu kündigen sind. Die Regulierung hat reagiert: Das Gesetz über digitale Dienste der EU (2022) verbietet Online-Plattformen, Oberflächen so zu gestalten, dass sie ihre Nutzer täuschen oder manipulieren, und die US Federal Trade Commission veröffentlichte 2022 einen Bericht ihrer Mitarbeiter über Dark Patterns. Viele dieser Muster brauchen Unterstützung durch die Architektur (eine Preis-API, die Gebühren bis zum Bezahlvorgang verbirgt, ein Kündigungsablauf, der über einen Kundenbindungsservice geleitet wird), daher sind Architekten in der Lage, sie zu bemerken und infrage zu stellen.

Der einfachste Weg, Schäden sichtbar zu machen, ist, gezielt nach ihnen zu suchen, und zwar in denselben Momenten, in denen Sie nach technischen Risiken suchen. Ergänzen Sie Bedrohungsmodellierung und Design-Reviews um eine Frage nach Schäden: Wer könnte durch dieses System zu Schaden kommen, wenn es wie vorgesehen funktioniert, wenn es ausfällt oder wenn es missbraucht wird? Praktiken wie das Consequence Scanning, entwickelt vom britischen Thinktank Doteveryone, geben Teams ein kurzes, strukturiertes Format für dieses Gespräch während der Planung.

Nachhaltigkeit: Green Software

Software verbrennt keinen Treibstoff, wohl aber der Strom und die Hardware, die sie nutzt, und Architekturentscheidungen legen einen Großteil dieses Fußabdrucks für Jahre fest. Die Green Software Foundation, 2021 unter dem Dach der Linux Foundation gegründet, beschreibt sechs Kernbereiche der Green-Software-Praxis: CO2-Effizienz (so wenig CO2 wie möglich ausstoßen), Energieeffizienz (so wenig Energie wie möglich verbrauchen), CO2-Bewusstsein (mehr tun, wenn der Strom sauberer ist, und weniger, wenn er schmutziger ist), Hardware-Effizienz (so wenig grauen Kohlenstoff wie möglich verursachen), Messung und Klimaverpflichtungen (genau verstehen, wie eine Reduktion erreicht wird).

Carbon-Aware Computing nutzt die Tatsache, dass die CO2-Intensität des Stroms je nach Stunde und Region mit dem Mix aus Wind, Sonne, Gas und anderen Quellen schwankt. Demand Shifting verlagert flexible Arbeit wie Batch-Jobs, Modelltraining, Backups und Berichtserstellung in Zeiten oder Regionen, in denen der Strom sauberer ist; Demand Shaping verringert, was die Software tut, wenn er schmutziger ist, etwa indem Medien in geringerer Auflösung ausgeliefert oder nicht dringende Neuberechnungen aufgeschoben werden. Netzdatendienste wie die Carbon Intensity API für Großbritannien und Open-Source-Tools wie das Carbon Aware SDK der Foundation liefern die Signale. Ein einfaches Beispiel: Ein nächtlicher Batch-Job mit einem Verbrauch von 400 kWh verursacht bei beispielhaft angenommenen 300 g pro kWh am frühen Abend etwa 120 kg CO₂e, in einer windigen Nacht mit 120 g pro kWh dagegen nur etwa 48 kg.

Grauer Kohlenstoff (Embodied Carbon), also die Emissionen aus Herstellung und Entsorgung von Hardware, ist der Grund, warum Hardware-Effizienz zählt: höhere Auslastung von weniger Maschinen, Skalierung auf null im Leerlauf und eine längere Lebensdauer von Geräten (auch der Smartphones der Kunden, indem man nicht für jedes Release neue Hardware verlangt) verringern ihn. Die Spezifikation Software Carbon Intensity der Foundation, veröffentlicht als ISO/IEC 21031:2024 und eingeführt in Abschnitt 2.7, kombiniert betriebliche und graue Emissionen pro funktionaler Einheit, etwa pro ausgelieferter Bestellung, und schließt Kompensationen aus, sodass nur echte Reduktionen den Wert verbessern.

Zu den Hebeln der Architektur gehören Right-Sizing und Autoscaling, das Entfernen ungenutzter Umgebungen, Aufbewahrungsfristen für Daten (gespeicherte Daten haben Energie- und Hardwarekosten), effiziente Datenformate und Caching, die Wahl von Regionen mit saubererem Strommix, wo Latenz und Datenresidenz es zulassen, und die Frage, ob wirklich jedes Feature einen Aufruf eines großen Modells braucht. Achten Sie auf den Rebound-Effekt, die moderne Form von William Stanley Jevons’ Beobachtung zur Kohle von 1865: Effizienz, die etwas billiger macht, kann den Gesamtverbrauch erhöhen; messen Sie daher die Gesamtemissionen ebenso wie die Intensität.