# Be Software Architecture Wise

> Ein vollständiger Online-Kurs in Softwarearchitektur zum Lernen im eigenen Tempo von Be Wise (bewiseapps.com): dreizehn Kapitel und 104 Abschnitte, von der Funktionsweise von Software bis zur Architektur KI-gestützter Systeme. Jedes Kapitel hat eine gesprochene Videoeinführung und jeder Abschnitt eine kurze gesprochene Videolektion, mit Untertiteln und Transkript. Freiwillige Kapiteltests, eine Abschlussprüfung und eine Architektur-Fallstudie führen zum Be Wise Abschlusszertifikat (nicht akkreditiert). Ursprünglich in britischem Englisch verfasst. Bildungsinformationen, keine fachliche Beratung.

## Über den Kurs

- **Was ist Be Software Architecture Wise?** Ein vollständiger Onlinekurs in Softwarearchitektur in 13 Kapiteln und 104 Abschnitten mit 117 vertonten Videolektionen, von der Funktionsweise von Software bis zur Architektur KI-gestützter Systeme, mit optionalen Kapiteltests, einer Abschlussbewertung mit Fallstudie und einem überprüfbaren Be Wise Abschlusszertifikat.
- **Für wen ist der Kurs gedacht?** Einsteiger ohne technischen Hintergrund, Entwicklerinnen und Entwickler auf dem Weg zu Senior-, Lead- oder Architekturrollen, erfahrene Architekten, die eine strukturierte Auffrischung suchen, Engineering- und Produktmanager, KI-Ingenieure sowie Studierende.
- **Was brauche ich, bevor ich beginne?** Keine Vorkenntnisse, nur ein Smartphone, Tablet oder Computer mit einem aktuellen Webbrowser, eine Internetverbindung für die Tests und ArchitectBot und die Fähigkeit, mühelos Deutsch zu lesen (die Videos sind auf Englisch gesprochen, mit deutschen Untertiteln).
- **Was behandelt der Kurs?** Dreizehn Kapitel: wie Software funktioniert; was Architektur ist; Qualitätsmerkmale; Designprinzipien; Architektur dokumentieren; monolithische Stile und Domain-Driven Design; verteilte Systeme; Datenarchitektur; Sicherheit, Datenschutz und Compliance; Performance, Resilienz und Betreibbarkeit; Cloud-native Infrastruktur; Bewertung und Governance; sowie KI-gestützte Systeme.
- **Wie ist der Kurs aufgebaut, und wie lange dauert er?** Jedes Kapitel hat eine vertonte Videoeinführung, einen Überblick und acht Abschnitte, jeder mit einer vertonten Videolektion, einer einfachen Erklärung, Kernpunkten, der vollständigen Darstellung mit Diagrammen und ausgearbeiteten Beispielen, Fragen zur Selbstkontrolle und Quellen. Etwa 40 Stunden Lesezeit und insgesamt etwa 60 Stunden mit den Tests und der Fallstudie, ganz im eigenen Tempo. Die 117 Videolektionen dauern zusammen etwa 10 Stunden.
- **Wie funktionieren die Kapiteltests?** Jeder Kapiteltest besteht aus 20 Multiple-Choice-Fragen aus einem Fragenpool von 64 und 2 schriftlichen Antworten, die von KI nach veröffentlichten Kriterien bewertet werden. Die Multiple-Choice-Fragen zählen 70 %, die schriftlichen Antworten 30 %. Die Bestehensgrenze liegt bei 80 % insgesamt und mindestens 2 von 5 Punkten bei jeder schriftlichen Antwort. Beliebig viele Wiederholungen nach 10 Minuten, mit anderen Fragen.
- **Was ist die Abschlussbewertung?** Nach Bestehen aller 13 Kapiteltests: eine Abschlussprüfung mit 60 Fragen (Bestehensgrenze 70 %) und eine schriftliche Architektur-Fallstudie von 1500 bis 4000 Wörtern, bewertet mit bis zu 50 Punkten nach veröffentlichten Bewertungskriterien in fünf Teilen (Bestehensgrenze 25).
- **Wie wird das Endergebnis ermittelt?** Gesamtergebnis = 40 % Durchschnitt der besten Kapiteltestergebnisse + 30 % Abschlussprüfung + 30 % Fallstudie. Mit Auszeichnung bestanden: 90+ insgesamt und mindestens 80 % in der Fallstudie. Gut bestanden: 80+. Bestanden: alle Teile bestanden.
- **Was zeigt das Zertifikat, und wie lässt es sich überprüfen?** Ein Be Wise Abschlusszertifikat mit Ihrem Namen, dem Datum, Ihrem Ergebnis (Bestanden, Gut bestanden oder Mit Auszeichnung bestanden) und einer eindeutigen Nummer, die jeder online prüfen kann.
- **Ist das Zertifikat eine akkreditierte Qualifikation?** Nein. Es bestätigt, dass Sie diesen Kurs abgeschlossen und seine Prüfungen bestanden haben. Es ist nicht akkreditiert, bringt keine akademischen Leistungspunkte und wird von keiner Universität, keinem Berufsverband und keinem Zertifizierungsprogramm ausgestellt oder anerkannt.
- **Was geschieht mit meinen Daten?** Ein Konto ist nicht nötig. Der Lesefortschritt bleibt in Ihrem Browser; Testergebnisse werden unter einem zufälligen Fortsetzungscode ohne persönliche Daten gespeichert; Ihr Name wird nur gespeichert, wenn Sie ein Zertifikat beantragen, damit es geprüft werden kann.
- **Was ist ArchitectBot?** Der KI-Lernassistent des Kurses. Er antwortet zuerst aus dem Kurs und sucht im Web nach neueren Informationen. Er kann Fehler machen und beantwortet keine Testfragen für Sie.
- **Wie wird der Inhalt richtig und aktuell gehalten?** Jedes Kapitel wird vor der Veröffentlichung anhand seiner zitierten Quellen geprüft, die Quellen sind in jedem Abschnitt aufgeführt, die Kapitel werden aktualisiert, wenn sich die Praxis ändert, und Fehler können gemeldet werden.
- **Welche Geräte kann ich nutzen, und ist der Kurs barrierefrei?** Smartphones, Tablets und Computer in jedem aktuellen Browser; als App installierbar; jedes Kapitel auch als Webseiten und als PDF; jedes Video ist auf Englisch gesprochen und hat deutsche und englische Untertitel, eine reine Audiofassung und ein Transkript; Diagramme haben Textbeschreibungen.
- **Was der Kurs nicht ist** Es handelt sich um Bildungsinformationen, nicht um fachliche Beratung; es ist keine akkreditierte Qualifikation und keine Prüfungsvorbereitung; es ist mit keiner Universität und keiner Zertifizierungsstelle verbunden; es ist kein Programmierkurs; und es gibt keinen Live-Unterricht, auch wenn jedes Kapitel und jeder Abschnitt eine vertonte Videolektion hat.
- **Was kostet der Kurs?** Derzeit ist der gesamte Kurs kostenlos: jedes Kapitel, die Kapiteltests, ArchitectBot, die Abschlussbewertung und das Zertifikat. Sollte sich das ändern, werden der Preis und genau, was er umfasst, auf dieser Seite angezeigt, bevor Sie etwas Kostenpflichtiges beginnen.
- Weitere Informationen: https://bewiseapps.com/de/software-architecture-wise/about-the-course

## Kapitel und Abschnitte

### [Kapitel 0: Einstieg: Wie Software funktioniert](https://bewiseapps.com/de/software-architecture-wise/foundations/)
Einsteiger. Die Grundlage für alles Weitere: was ein Programm ist, wie Daten und Code organisiert sind, wie Computer über Netzwerke kommunizieren, wo Daten gespeichert werden, was APIs, Server und die Cloud sind und wie Teams Software entwickeln. Vorkenntnisse sind nicht nötig.

- [0.1 Programme, Code und wie ein Computer sie ausführt](https://bewiseapps.com/de/software-architecture-wise/foundations/what-software-is): Was Hardware und Software sind, wie Quellcode zu Anweisungen wird, die ein Prozessor ausführen kann, was das Betriebssystem tut und was wirklich geschieht, Schritt für Schritt, wenn ein kleines Python-Programm läuft.
- [0.2 Daten, Datenstrukturen und Algorithmen und warum die Geschwindigkeit von ihnen abhängt](https://bewiseapps.com/de/software-architecture-wise/foundations/data-and-algorithms): Wie Computer Zahlen und Text darstellen, die alltäglichen Datenstrukturen (Listen, Dictionaries, Queues, Bäume, Graphen), was ein Algorithmus ist und wie die O-Notation erklärt, warum manche Systeme mit wachsender Datenmenge langsamer werden.
- [0.3 Funktionen, Module, Objekte, Schnittstellen, Bibliotheken und Frameworks](https://bewiseapps.com/de/software-architecture-wise/foundations/organising-code): Wie Programmierer Code in Funktionen, Module, Objekte und Schnittstellen aufteilen; der Unterschied zwischen einer Bibliothek und einem Framework; Nutzen und Risiken von Abhängigkeiten; und ein erster Blick auf Kopplung und Kohäsion.
- [0.4 Netzwerke, Internet und Web: IP, DNS, HTTP und das Client-Server-Modell](https://bewiseapps.com/de/software-architecture-wise/foundations/how-computers-talk): Wie Daten in Paketen durch das Internet gelangen, was IP-Adressen, Ports, TCP, UDP und DNS leisten, wie HTTP-Anfragen und HTTPS funktionieren, warum die Physik der Latenz eine Untergrenze setzt und was passiert, wenn Sie eine Webadresse eingeben.
- [0.5 Dateien und Datenbanken: relationale und nicht relationale Speicherung, Abfragen und Transaktionen](https://bewiseapps.com/de/software-architecture-wise/foundations/storing-data): Warum Systeme Datenbanken statt einfacher Dateien brauchen, wie relationale Tabellen, Schlüssel, SQL, Indizes und ACID-Transaktionen funktionieren, die wichtigsten NoSQL-Familien und warum Backups getestet werden müssen.
- [0.6 APIs, JSON und wie getrennte Systeme zusammenarbeiten](https://bewiseapps.com/de/software-architecture-wise/foundations/apis-and-integration): Was eine API ist und warum sie ein Vertrag ist, wie REST-APIs URLs, HTTP-Verben, Statuscodes und JSON nutzen und wie Schlüssel, Webhooks, Queues, Versionen und Rate Limits die Integration prägen.
- [0.7 Server, Betriebssysteme, virtuelle Maschinen, Container und Cloud-Dienste](https://bewiseapps.com/de/software-architecture-wise/foundations/servers-and-the-cloud): Was Server und Rechenzentren sind, wie virtuelle Maschinen und Container sich Hardware teilen, was IaaS, PaaS, SaaS und Serverless dem Anbieter überlassen und wie Regionen, Zonen, CDNs und Skalierung zusammenpassen.
- [0.8 Anforderungen, Versionskontrolle, Tests, Auslieferung und der Weg einer Anfrage](https://bewiseapps.com/de/software-architecture-wise/foundations/how-software-gets-built): Wie Teams Bedürfnisse in User Stories übersetzen, mit Git und Pull Requests zusammenarbeiten, auf mehreren Ebenen testen, über CI/CD und Umgebungen ausliefern und wie ein einziges Tippen in einer Essensliefer-App jeden Teil eines Systems durchläuft.

### [Kapitel 1: Was Softwarearchitektur ist](https://bewiseapps.com/de/software-architecture-wise/what-is-architecture/)
Einsteiger bis Mittelstufe. Die maßgeblichen Definitionen (ISO/IEC/IEEE 42010 und das SEI), wie sich Architektur von Design unterscheidet, warum sie über Kosten und Risiken entscheidet, was Architekten tatsächlich tun, Stakeholder, Abwägungen, technische Schulden und welchen Platz Architektur in der modernen Softwareauslieferung hat.

- [1.1 Was Softwarearchitektur ist: die Standarddefinitionen und ihre Gemeinsamkeiten](https://bewiseapps.com/de/software-architecture-wise/what-is-architecture/defining-architecture): Der internationale Standard, das SEI und führende Praktiker definieren Softwarearchitektur unterschiedlich. Lernen Sie die wichtigsten Definitionen kennen, ihre Gemeinsamkeiten und die drei Arten von Strukturen, die jedes System hat.
- [1.2 Architektur, Design und Code: Bedeutsamkeit, Reichweite und Ebenen](https://bewiseapps.com/de/software-architecture-wise/what-is-architecture/architecture-vs-design): Architektur und Design bilden ein Kontinuum von Entscheidungen. Lernen Sie, was eine Entscheidung architekturrelevant macht, wie sich strategische und taktische Entscheidungen unterscheiden und wie Unternehmens-, Lösungs- und Softwarearchitektur zusammenhängen.
- [1.3 Warum Architektur zählt: Änderungskosten, Qualität, Risiko und echte Ausfälle](https://bewiseapps.com/de/software-architecture-wise/what-is-architecture/why-architecture-matters): Architektur entscheidet über die Qualitäten eines Systems, über Kosten und Tempo jeder künftigen Änderung, über seine Risiken und darüber, wie Teams arbeiten können. Echte Fälle von Knight Capital, HealthCare.gov und Prime Video zeigen, warum.
- [1.4 Was ein Architekt tut: Verantwortlichkeiten, Fähigkeiten und Arten von Architekten](https://bewiseapps.com/de/software-architecture-wise/what-is-architecture/the-architect-role): Was Architekten im Arbeitsalltag tatsächlich tun, die acht Erwartungen nach Richards und Ford, die Arten von Architekten, Breite gegenüber Tiefe und ob Architekten noch selbst programmieren sollten.
- [1.5 Stakeholder, ihre Anliegen und wie Architektur ihnen dient](https://bewiseapps.com/de/software-architecture-wise/what-is-architecture/stakeholders-and-concerns): Wer ein Interesse an einem System hat, was ISO/IEC/IEEE 42010 unter einem Anliegen versteht, wie man Stakeholder erfasst und einbindet und wie widersprüchliche Anliegen zu expliziten Anforderungen, Entscheidungen und Sichten werden.
- [1.6 Architekturentscheidungen und Abwägungen: Umkehrbarkeit und Zeitpunkt](https://bewiseapps.com/de/software-architecture-wise/what-is-architecture/decisions-and-trade-offs): Warum jede Architekturentscheidung eine Abwägung ist, wie eine gut aufgebaute Entscheidung strukturiert ist, Einweg- und Zweiwegtüren, der Last Responsible Moment, Design für Umkehrbarkeit, kognitive Fallen und die gewichtete Entscheidungsmatrix.
- [1.7 Technische Schulden, Architekturerosion und Architekturdrift](https://bewiseapps.com/de/software-architecture-wise/what-is-architecture/technical-debt): Was Ward Cunninghams Schuldenmetapher wirklich meinte, Tilgung und Zinsen, Fowlers Schuldenquadrant, warum Architekturschulden am teuersten sind, Erosion und Drift und wie man Schulden erkennt, steuert und in geschäftlichen Begriffen erklärt.
- [1.8 Architektur über den Lebenszyklus: vorab geplante, emergente und kontinuierliche Architektur](https://bewiseapps.com/de/software-architecture-wise/what-is-architecture/architecture-in-the-lifecycle): Big Design Up Front gegenüber emergentem Design, was das Agile Manifest wirklich sagt, Fairbanks’ risikogetriebenes Modell, beabsichtigte Architektur und die Runway, kontinuierliche Architektur, Walking Skeletons, Spikes und Architektur in DevOps.

### [Kapitel 2: Qualitätsmerkmale und architekturrelevante Anforderungen](https://bewiseapps.com/de/software-architecture-wise/quality-attributes/)
Mittelstufe. Wie man vage Wünsche wie „schnell“ und „sicher“ in präzise, testbare Anforderungen verwandelt: ISO/IEC 25010, Qualitätsszenarien, Performance, Verfügbarkeit, Änderbarkeit, Sicherheit und Benutzbarkeit sowie wie man sie erhebt, priorisiert und gegeneinander abwägt.

- [2.1 Funktionale Anforderungen, Qualitätsmerkmale und Randbedingungen](https://bewiseapps.com/de/software-architecture-wise/quality-attributes/functional-vs-quality): Was ein System tun muss, wie gut es das tun muss und welche Entscheidungen bereits feststehen. Lernen Sie, die architekturrelevanten Anforderungen zu erkennen, die ein Design wirklich bestimmen.
- [2.2 Qualitätsmodelle: ISO/IEC 25010 und wie man es nutzt](https://bewiseapps.com/de/software-architecture-wise/quality-attributes/the-quality-models): Das Produktqualitätsmodell ISO/IEC 25010:2023 und seine neun Merkmale, was sich seit 2011 geändert hat, andere Listen wie FURPS+ und wie man ein Modell als Checkliste nutzt, ohne in Papierkram zu versinken.
- [2.3 Testbare Qualitätsszenarien schreiben](https://bewiseapps.com/de/software-architecture-wise/quality-attributes/quality-attribute-scenarios): Das sechsteilige Szenario, das „schnell“, „sicher“ und „leicht zu ändern“ in testbare Anforderungen verwandelt, mit Beispielen für sechs Qualitäten, typischen Fehlern und dem Weg vom Szenario zur Fitness Function.
- [2.4 Performance und Skalierbarkeit: Latenz, Durchsatz, Perzentile und Last](https://bewiseapps.com/de/software-architecture-wise/quality-attributes/performance-and-scalability): Latenz und Durchsatz, Perzentile und Tail-Latenz, Littles Gesetz, Warteschlangen und die Auslastungsklippe, Amdahlsches Gesetz und das Universal Scalability Law, mit durchgerechneten Beispielen und einem Überblick über Performance-Taktiken.
- [2.5 Verfügbarkeit und Zuverlässigkeit: Neunen, MTBF, MTTR und Fehlertoleranz](https://bewiseapps.com/de/software-architecture-wise/quality-attributes/availability-and-reliability): Was Verfügbarkeit, Zuverlässigkeit und Fehlertoleranz wirklich bedeuten, wie man Neunen, MTBF und MTTR berechnet, wie sich Komponenten in Reihe und parallel verbinden und mit welchen Taktiken, RTO und RPO man sie erreicht.
- [2.6 Änderbarkeit, Testbarkeit und Deploybarkeit: auf Veränderung auslegen](https://bewiseapps.com/de/software-architecture-wise/quality-attributes/modifiability-testability-deployability): Wie man Veränderung spezifiziert und darauf hin entwirft: was sich ändert, wer es ändert und wann, Taktiken gegen Folgeänderungen, Testbarkeit durch Steuerbarkeit und Beobachtbarkeit, Deploybarkeit und die DORA-Metriken für die Auslieferung.
- [2.7 Sicherheit, Benutzbarkeit, Interoperabilität, Kosten und Nachhaltigkeit als Qualitäten](https://bewiseapps.com/de/software-architecture-wise/quality-attributes/security-usability-and-more): Sicherheit als messbare Qualität, die Teilmerkmale und Taktiken der Sicherheit nach ISO/IEC 25010, Benutzbarkeit und Barrierefreiheit nach WCAG 2.2, Interoperabilität, Kosten pro Transaktion, Software Carbon Intensity, Betriebssicherheit, Observability und regulatorische Qualitäten.
- [2.8 Qualitätsmerkmale erheben, priorisieren und abwägen](https://bewiseapps.com/de/software-architecture-wise/quality-attributes/eliciting-and-prioritising): Woher Qualitätsanforderungen kommen, wie der Quality Attribute Workshop des SEI und der Utility Tree der ATAM sie aufdecken und gewichten, wie man mit Konflikten zwischen Qualitäten umgeht und wie Fitness Functions sie dauerhaft absichern.

### [Kapitel 3: Designprinzipien und Grundlagen](https://bewiseapps.com/de/software-architecture-wise/design-principles/)
Mittelstufe. Die Prinzipien hinter jeder guten Struktur: Modularität, Kopplung und Kohäsion, Information Hiding, Abhängigkeitsregeln, SOLID auf Komponentenebene, Connascence, Gesetz von Conway, Einfachheit und wie man Struktur misst.

- [3.1 Modularität: ein System in Teile zerlegen](https://bewiseapps.com/de/software-architecture-wise/design-principles/modularity): Was ein Modul auf jeder Ebene ist, warum wir Systeme in Module zerlegen, Parnas’ Regel, nach wahrscheinlichen Änderungen zu zerlegen, logische gegenüber Deployment-Modulen, Granularität und wie man Grenzen im Code durchsetzt.
- [3.2 Kopplung und Kohäsion](https://bewiseapps.com/de/software-architecture-wise/design-principles/coupling-and-cohesion): Die beiden ältesten Maße guter Struktur: die klassischen Stufen von Kopplung und Kohäsion, afferente und efferente Kopplung, die zusätzlichen Formen der Kopplung in verteilten Systemen und Taktiken, sie zu lockern, mit einem durchgearbeiteten Refactoring.
- [3.3 Information Hiding, Abstraktion und Schnittstellen](https://bewiseapps.com/de/software-architecture-wise/design-principles/information-hiding-and-abstraction): Warum Module Entscheidungen verbergen sollten, wie sich Information Hiding von Kapselung unterscheidet, Schnittstellen als Verträge und Design by Contract, Leaky Abstractions, tiefe Module, Hyrums Gesetz und wie man APIs zwischen Komponenten stabil hält.
- [3.4 Abhängigkeiten steuern: Richtung, Zyklen und Stabilität](https://bewiseapps.com/de/software-architecture-wise/design-principles/dependencies-and-layering): In welche Richtung Abhängigkeiten zeigen sollten und warum: Robert C. Martins Prinzipien der azyklischen Abhängigkeiten, der stabilen Abhängigkeiten und der stabilen Abstraktionen, die Metriken Instabilität, Abstraktheit und Distanz, Zyklen auflösen, Schichtenbildung und automatisierte Abhängigkeitsprüfungen.
- [3.5 Die SOLID-Prinzipien auf Komponenten angewandt](https://bewiseapps.com/de/software-architecture-wise/design-principles/solid-at-scale): Die fünf SOLID-Prinzipien präzise erklärt, jedes in Python und dann auf Komponenten- und Service-Ebene gezeigt, dazu die Kohäsionsprinzipien REP, CCP und CRP, ihr Spannungsdreieck und die berechtigte Kritik an SOLID.
- [3.6 Connascence: ein feineres Maß für Kopplung](https://bewiseapps.com/de/software-architecture-wise/design-principles/connascence): Meilir Page-Jones’ Connascence benennt die verborgenen Absprachen zwischen Teilen eines Systems, ordnet sie nach Stärke und beurteilt sie nach Lokalität und Grad, von Positionsparametern bis zum Timing zwischen Services.
- [3.7 Das Gesetz von Conway und die Gestalt von Organisationen](https://bewiseapps.com/de/software-architecture-wise/design-principles/conways-law): Melvin Conways Beobachtung von 1968, dass Systeme die Kommunikationsstruktur der Organisationen nachbilden, die sie entwerfen, die Belege aus der Forschung, die Arithmetik der Kommunikationspfade, das Inverse Conway Maneuver und die kognitive Last des Teams.
- [3.8 Einfachheit, Umkehrbarkeit und das Messen von Struktur](https://bewiseapps.com/de/software-architecture-wise/design-principles/simplicity-and-measurement): Essenzielle und akzidentelle Komplexität, KISS, YAGNI, DRY als Wissen statt als Text, Umkehrbarkeit als Option und wie man Struktur mit zyklomatischer Komplexität, LCOM, Change Coupling und Fitness Functions misst, ohne Goodharts Gesetz zum Opfer zu fallen.

### [Kapitel 4: Architektur dokumentieren und kommunizieren](https://bewiseapps.com/de/software-architecture-wise/documenting-architecture/)
Mittelstufe. Sichten und Blickwinkel, das C4-Modell, die UML, die noch zählt, Architecture Decision Records, arc42, Diagrams as Code und wie man Architektur technischem und nicht technischem Publikum präsentiert.

- [4.1 Warum und wie viel dokumentieren](https://bewiseapps.com/de/software-architecture-wise/documenting-architecture/why-document): Wer Architekturdokumentation liest und was jeder Leser braucht, was das Agile Manifest wirklich über Dokumente sagt, wie man entscheidet, was es wert ist, aufgeschrieben zu werden, und die Regeln, die Dokumentation nützlich halten.
- [4.2 Sichten und Blickwinkel: ISO/IEC/IEEE 42010, 4+1 und Rozanski und Woods](https://bewiseapps.com/de/software-architecture-wise/documenting-architecture/views-and-viewpoints): Warum ein Diagramm nie genügt: das Modell aus Stakeholdern, Anliegen, Blickwinkeln und Sichten nach ISO/IEC/IEEE 42010, Kruchtens 4+1, die Blickwinkel und Perspektiven von Rozanski und Woods und wie man die Sichten wählt, die ein System braucht.
- [4.3 Das C4-Modell: Kontext, Container, Komponenten und Code](https://bewiseapps.com/de/software-architecture-wise/documenting-architecture/the-c4-model): Simon Browns C4-Modell in der Praxis: die vier Zoomstufen, was ein Container wirklich ist, die Notationsregeln, die Diagramme selbsterklärend machen, und eine Essenslieferplattform, gezeichnet auf Kontext-, Container- und Komponentenebene.
- [4.4 Die UML-Diagramme, die Architekten noch verwenden](https://bewiseapps.com/de/software-architecture-wise/documenting-architecture/uml-essentials): Der heutige Stellenwert der UML, Fowlers Modi Skizze, Bauplan und Programmiersprache und die Notationsgrundlagen der sechs Diagramme, die Architekten noch verwenden, jeweils für die Essenslieferplattform gezeichnet.
- [4.5 Architecture Decision Records](https://bewiseapps.com/de/software-architecture-wise/documenting-architecture/architecture-decision-records): Wie man bedeutsame Entscheidungen so festhält, dass ihre Gründe erhalten bleiben: Nygards Format, MADR und Y-Statements, Status und Ablösung, wo man die Aufzeichnungen aufbewahrt, was eine verdient, Review und Anti-Patterns.
- [4.6 arc42 und andere Dokumentationsvorlagen](https://bewiseapps.com/de/software-architecture-wise/documenting-architecture/arc42-and-templates): Die zwölf Abschnitte von arc42, was in jeden gehört und wie viel man für kleine und große Systeme schreibt, ein einseitiges arc42-lite-Beispiel, die Vorlagen des SEI und nach IEEE 1016 und die Konformität mit ISO/IEC/IEEE 42010.
- [4.7 Diagrams as Code und aktuelle Dokumentation](https://bewiseapps.com/de/software-architecture-wise/documenting-architecture/diagrams-as-code): Diagramme als Text schreiben mit PlantUML, Mermaid, Structurizr DSL und D2, Zeichen- gegenüber Modellierungswerkzeugen, Dokumentation in der Pipeline bauen und die Gewohnheiten, die sie zutreffend halten.
- [4.8 Architektur für verschiedene Zielgruppen kommunizieren](https://bewiseapps.com/de/software-architecture-wise/documenting-architecture/communicating-architecture): Architektur auf Führungskräfte, Produktmanager, Entwickler, Betrieb, Sicherheit und Prüfer zuschneiden: Abwägungen erklären, einseitige Zusammenfassungen, einer Anfrage folgen, Designdokumente und RFCs, Reviews, Diagrammgestaltung und Konsensbildung.

### [Kapitel 5: Architekturstile I: Monolithen und modulare Designs](https://bewiseapps.com/de/software-architecture-wise/monolithic-styles/)
Mittelstufe. Stile für Systeme, die als eine Einheit deployt werden: Schichtenarchitektur, modularer Monolith, Pipes and Filters, Microkernel, hexagonale und Clean Architecture, Domain-Driven Design und wann ein Monolith die richtige Antwort ist.

- [5.1 Architekturstile, Muster und Taktiken](https://bewiseapps.com/de/software-architecture-wise/monolithic-styles/what-is-a-style): Das Vokabular für die nächsten beiden Kapitel: Stile, Muster, Taktiken und Referenzarchitekturen, technische gegenüber fachlicher Partitionierung, monolithisches gegenüber verteiltem Deployment und das Architekturquantum.
- [5.2 Schichtenarchitektur](https://bewiseapps.com/de/software-architecture-wise/monolithic-styles/layered-architecture): Der bekannteste Stil: Präsentations-, Geschäfts-, Persistenz- und Datenbankschicht. Geschlossene und offene Schichten, Isolationsschichten, das Sinkhole-Anti-Pattern, warum jedes Feature jede Schicht berührt und wie man die Regeln durchsetzt.
- [5.3 Der modulare Monolith](https://bewiseapps.com/de/software-architecture-wise/monolithic-styles/modular-monolith): Eine deploybare Anwendung, nach fachlicher Domäne in Module mit expliziten APIs und eigenen Daten aufgeteilt. Wie man die Grenzen durchsetzt, wie Module kommunizieren, was Shopify gelernt hat und wie er die Option erhält, später Services herauszulösen.
- [5.4 Pipes and Filters und Pipeline-Architekturen](https://bewiseapps.com/de/software-architecture-wise/monolithic-styles/pipes-and-filters): Daten, die durch eine Kette unabhängiger Schritte fließen: Producer, Transformer, Tester und Consumer, verbunden durch Pipes. Von Unix-Pipes über ETL und Compiler bis zur Stream-Verarbeitung, mit Durchsatz, Backpressure und Fehlerbehandlung.
- [5.5 Microkernel- und Plug-in-Architekturen](https://bewiseapps.com/de/software-architecture-wise/monolithic-styles/microkernel): Wie ein kleines Kernsystem plus unabhängige Plug-ins Erweiterbarkeit liefert: Registries, Verträge, Isolation und Versionierung, echte Beispiele aus IDEs und Browsern und ein durchgearbeiteter Plug-in-Vertrag für länderspezifische Steuerregeln.
- [5.6 Hexagonale, Onion- und Clean Architecture](https://bewiseapps.com/de/software-architecture-wise/monolithic-styles/hexagonal-and-clean): Ports and Adapters, Onion- und Clean Architecture: die Geschäftslogik im Zentrum, Abhängigkeiten zeigen nach innen, treibende und getriebene Ports, ein Python-Beispiel mit einem echten Adapter und einem Test Double sowie die Kosten.
- [5.7 Strategisches Domain-Driven Design: Bounded Contexts und Context Maps](https://bewiseapps.com/de/software-architecture-wise/monolithic-styles/domain-driven-design): Grenzen in der Fachdomäne finden: Ubiquitous Language, Core-, Supporting- und generische Subdomänen, Bounded Contexts, Beziehungen in der Context Map, Event Storming, Aggregate und eine Context Map der Essenslieferplattform.
- [5.8 Wann ein Monolith die richtige Antwort ist](https://bewiseapps.com/de/software-architecture-wise/monolithic-styles/choosing-a-monolith): MonolithFirst, die Microservice Premium und der Majestic Monolith; wann eine einzige Deployment-Einheit die richtige Wahl ist, wie weit ein Monolith skaliert, die Anzeichen, dass es Zeit für eine Aufteilung ist, und eine Entscheidungshilfe für die Stile aus Kapitel 5.

### [Kapitel 6: Architekturstile II: Verteilte Systeme](https://bewiseapps.com/de/software-architecture-wise/distributed-systems/)
Mittelstufe bis Fortgeschritten. Warum und wann man verteilt, die Fallacies of Distributed Computing, servicebasierte und Microservice-Architekturen, ereignisgesteuerte Systeme, synchrone und asynchrone Kommunikation, CAP und PACELC, Sagas, Serverless und Space-Based Designs.

- [6.1 Warum verteilen? Die Fallacies of Distributed Computing](https://bewiseapps.com/de/software-architecture-wise/distributed-systems/why-distribute): Die echten Gründe, ein System auf mehrere Rechner aufzuteilen, die acht Trugschlüsse, die Verteilung schwieriger machen, als sie aussieht, Teilausfälle, die Kosten und die Arithmetik synchroner Aufrufketten.
- [6.2 Servicebasierte Architektur und serviceorientierte Architektur](https://bewiseapps.com/de/software-architecture-wise/distributed-systems/service-based-and-soa): Grobgranulare Domain Services mit gemeinsamer Datenbank, die Ära des Enterprise Service Bus in der SOA und warum sie verblasste, wie sich Microservices unterscheiden und wann servicebasierte Architektur der pragmatische Mittelweg ist.
- [6.3 Microservices: Prinzipien, Nutzen und Kosten](https://bewiseapps.com/de/software-architecture-wise/distributed-systems/microservices): Was Microservices nach Lewis und Fowler sind, Bounded Contexts, unabhängige Deploybarkeit, Datenbank pro Service, Gateways und Meshes, wie man die Granularität festlegt, die klassischen Anti-Patterns und der organisatorische Preis.
- [6.4 Ereignisgesteuerte Architektur: Broker, Mediatoren und Event-Streams](https://bewiseapps.com/de/software-architecture-wise/distributed-systems/event-driven): Ereignisse, Commands und Nachrichten; Broker- und Mediator-Topologie; Fowlers vier Event-Muster; wie Partitionen, Offsets und Consumer Groups in Kafka funktionieren; Zustellgarantien, idempotente Consumer, Schemas und Dead Letter Queues.
- [6.5 Synchrone und asynchrone Kommunikation: REST, gRPC, GraphQL und Messaging](https://bewiseapps.com/de/software-architecture-wise/distributed-systems/communication-and-apis): Wie Services miteinander kommunizieren: die Kopplung durch synchrone und asynchrone Kommunikation, REST und HTTP-Semantik, gRPC, GraphQL und Messaging sowie die API-Designpraktiken, mit denen sich Schnittstellen weiterentwickeln, ohne Consumer zu brechen.
- [6.6 Konsistenzmodelle, CAP und PACELC](https://bewiseapps.com/de/software-architecture-wise/distributed-systems/consistency-cap-pacelc): Was Konsistenz für replizierte Daten bedeutet: die Modelle von linearisierbar bis Eventual Consistency, was das CAP-Theorem wirklich sagt und was nicht, die alltägliche Latenzabwägung in PACELC, Quorum-Arithmetik und die Wahl der Konsistenz je Anwendungsfall.
- [6.7 Verteilte Transaktionen, Sagas und das Outbox-Muster](https://bewiseapps.com/de/software-architecture-wise/distributed-systems/sagas-and-distributed-transactions): Wie man Daten konsistent hält, wenn eine Geschäftsaktion mehrere Services umfasst: Two-Phase Commit und warum man es meidet, Sagas mit Kompensationen, Choreografie und Orchestrierung, Gegenmaßnahmen zur Isolation, die Transactional Outbox und idempotente Empfänger.
- [6.8 Serverless und Space-Based Architecture](https://bewiseapps.com/de/software-architecture-wise/distributed-systems/serverless-and-space-based): Zwei gegensätzliche Antworten auf die Kapazitätsfrage: Serverless-Funktionen und verwaltete Backends, die auf null skalieren und nach Nutzung abrechnen, und Space-Based Architecture, die extreme Spitzen aus repliziertem Arbeitsspeicher bedient und die Datenbank aus dem heißen Pfad nimmt.

### [Kapitel 7: Datenarchitektur](https://bewiseapps.com/de/software-architecture-wise/data-architecture/)
Mittelstufe bis Fortgeschritten. Datenhoheit, die Wahl einer Datenbank, Transaktionen und Isolation, Replikation und Partitionierung, CQRS und Event-Sourcing, Caching, Schemaevolution sowie Analytics, Streaming und Data Mesh.

- [7.1 Datenhoheit und Datenbank pro Service](https://bewiseapps.com/de/software-architecture-wise/data-architecture/data-ownership): Wer welche Daten ändern darf, warum eine gemeinsame Datenbank Services koppelt, wie man gemeinsame Datenhoheit auflöst und wie man Daten liest, auswertet und vertraglich regelt, die einem nicht gehören.
- [7.2 Die Wahl einer Datenbank: relational, Dokument, Key-Value, Spalten, Graph und Zeitreihen](https://bewiseapps.com/de/software-architecture-wise/data-architecture/choosing-a-database): Wofür jede Datenbankfamilie gut und schlecht geeignet ist, von relational bis zu Vektordatenbanken und Distributed SQL, und wie man nach Datenform, Zugriffsmustern, Konsistenz, Skalierung, Betrieb und Fähigkeiten des Teams auswählt.
- [7.3 Transaktionen, ACID und Isolationsebenen](https://bewiseapps.com/de/software-architecture-wise/data-architecture/transactions-and-isolation): Was ACID wirklich garantiert, die Anomalien, die Isolationsebenen zulassen, wie MVCC und Snapshot Isolation funktionieren, warum die Namen der Ebenen irreführen und wann man Sperren, Versionsprüfungen oder serialisierbare Transaktionen verwendet.
- [7.4 Replikation, Partitionierung und Sharding](https://bewiseapps.com/de/software-architecture-wise/data-architecture/replication-and-partitioning): Wie Datenbanken Daten für Verfügbarkeit und Leseskalierung kopieren, was Replikationsverzögerung und Failover mit der Korrektheit machen und wie Partitionierung nach Bereich oder Hash, konsistentes Hashing und Sekundärindizes ein Sharding-Design prägen.
- [7.5 CQRS und Event-Sourcing](https://bewiseapps.com/de/software-architecture-wise/data-architecture/cqrs-and-event-sourcing): Das Modell, das Daten ändert, von den Modellen trennen, die sie lesen, Zustand als nur anfügbare Folge von Ereignissen speichern, und die echten Kosten: Eventual Consistency, Versionierung von Ereignissen und personenbezogene Daten.
- [7.6 Caching-Strategien und ihre Fallstricke](https://bewiseapps.com/de/software-architecture-wise/data-architecture/caching): Warum Caches Systeme beschleunigen und was sie kosten: Cache-Aside, Read-Through, Write-Through, Write-Behind und Refresh-Ahead, TTLs und Invalidierung, Stampedes, Caching-Ebenen, HTTP-Header und Verdrängung.
- [7.7 Schemaevolution, Migrationen und Kompatibilität](https://bewiseapps.com/de/software-architecture-wise/data-architecture/schema-evolution): Datenbank-, API- und Event-Schemas ändern, während das System weiterläuft: Abwärts-, Aufwärts- und Vollkompatibilität, Expand and Contract, Migrationswerkzeuge, große Backfills und Schema Registries für Avro und Protocol Buffers.
- [7.8 Analytics, Streaming, Data Warehouses, Data Lakes und Data Mesh](https://bewiseapps.com/de/software-architecture-wise/data-architecture/analytics-and-streaming): Wie analytische Daten architektonisch aufgebaut werden: OLTP und OLAP im Vergleich, Data Warehouses und Sternschemata, ETL und ELT, Data Lakes und Lakehouses, Stream Processing mit Ereigniszeit und Watermarks, Lambda und Kappa sowie Data Mesh.

### [Kapitel 8: Sicherheit, Datenschutz und Compliance by Design](https://bewiseapps.com/de/software-architecture-wise/security-by-design/)
Mittelstufe bis Fortgeschritten. Sicherheitsprinzipien, Bedrohungsmodellierung mit STRIDE, Identität und Zugriff (OAuth 2.0 und OpenID Connect), Verschlüsselung und Secrets, Zero Trust, Sicherheit der Software-Lieferkette, Privacy by Design nach der DSGVO und Sicherheit im Betrieb.

- [8.1 Sicherheitsprinzipien für Architekten](https://bewiseapps.com/de/software-architecture-wise/security-by-design/security-principles): Die CIA-Triade, die Designprinzipien von Saltzer und Schroeder, Defense in Depth, Secure by Default, Angriffsfläche und Vertrauensgrenzen, die OWASP Top 10 und ein sicherer Entwicklungslebenszyklus, samt der Frage, wer wofür zuständig ist.
- [8.2 Bedrohungsmodellierung: STRIDE, Angriffsbäume und Datenflussdiagramme](https://bewiseapps.com/de/software-architecture-wise/security-by-design/threat-modelling): Shostacks vier Fragen, Datenflussdiagramme mit Vertrauensgrenzen, STRIDE und Angriffsbäume, Risikobewertung ohne Scheingenauigkeit und ein ausgearbeitetes Bedrohungsmodell für den Checkout einer Essenslieferplattform.
- [8.3 Identität und Zugriff: Authentifizierung, Autorisierung, OAuth 2.0 und OpenID Connect](https://bewiseapps.com/de/software-architecture-wise/security-by-design/identity-and-access): Authentifizierung und Autorisierung im Vergleich, die aktuellen Passwortregeln des NIST, MFA und Passkeys, Sessions und JWTs, OAuth 2.0 mit PKCE, OpenID Connect, RBAC, ABAC, beziehungsbasierte Zugriffskontrolle und Workload Identity.
- [8.4 Verschlüsselung, Schlüsselverwaltung und Secrets](https://bewiseapps.com/de/software-architecture-wise/security-by-design/protecting-data): Verschlüsselung bei der Übertragung und im Ruhezustand und was jede Schicht wirklich schützt, symmetrische und asymmetrische Kryptografie, Passwort-Hashing, KMS und Envelope Encryption, Secrets, Tokenisierung für PCI DSS und Datenklassifizierung.
- [8.5 Sichere Kommunikation und Zero Trust](https://bewiseapps.com/de/software-architecture-wise/security-by-design/zero-trust): Warum das vertrauenswürdige interne Netzwerk gescheitert ist, was NIST SP 800-207 und BeyondCorp unter Zero Trust verstehen und wie mTLS, Workload Identity, Service Meshes, Zertifikate und Gateways es in die Praxis umsetzen.
- [8.6 Sicherheit der Software-Lieferkette](https://bewiseapps.com/de/software-architecture-wise/security-by-design/supply-chain-security): Warum Abhängigkeiten und Build-Pipelines eine Angriffsfläche sind, was event-stream, SolarWinds, Log4Shell und xz utils lehren und wie SBOMs, SLSA, Sigstore, Pinning und die EU-Cyberresilienz-Verordnung darauf antworten.
- [8.7 Privacy by Design und die DSGVO](https://bewiseapps.com/de/software-architecture-wise/security-by-design/privacy-by-design): Wie DSGVO und UK GDPR die Architektur prägen: die Grundsätze aus Artikel 5, Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen, Rechte, die Systeme unterstützen müssen, DSFAs, Übermittlungen, Pseudonymisierung sowie Aufbewahrung und Löschung über jede Kopie hinweg.
- [8.8 Sicherheit im Betrieb: Logging, Erkennung und Reaktion](https://bewiseapps.com/de/software-architecture-wise/security-by-design/security-in-operation): Ein System sicher betreiben: was protokolliert werden sollte und was nie, Audit-Trails, Erkennung mit einem SIEM, Schwachstellenmanagement mit CVSS, EPSS und KEV, Incident Response nach NIST, ransomwaresichere Backups und Meldefristen bei Datenschutzverletzungen.

### [Kapitel 9: Performance, Skalierbarkeit, Resilienz und Betreibbarkeit](https://bewiseapps.com/de/software-architecture-wise/resilience-and-operability/)
Mittelstufe bis Fortgeschritten. Skalierungsstrategien, Load Balancing und Zustandslosigkeit, Queues und Backpressure, Timeouts, Wiederholungen, Circuit Breaker und Bulkheads, SLIs, SLOs und Error Budgets, Observability, Kapazitätsplanung und Chaos Engineering.

- [9.1 Skalierungsstrategien: vertikal, horizontal und der Scale Cube](https://bewiseapps.com/de/software-architecture-wise/resilience-and-operability/scaling-strategies): Scale-up und Scale-out und ihre Grenzen, der Scale Cube von Abbott und Fisher, Zustandslosigkeit, reaktives, zeitgesteuertes und prädiktives Autoscaling, die Wahl eines Skalierungssignals, die Vermeidung von Flapping und die Dimensionierung einer Flotte für eine Lastspitze.
- [9.2 Load Balancing, Zustandslosigkeit und Sessions](https://bewiseapps.com/de/software-architecture-wise/resilience-and-operability/load-balancing-and-statelessness): Load Balancer auf Layer 4 und Layer 7, die wichtigsten Algorithmen einschließlich der Power of Two Random Choices, Liveness- und Readiness-Checks, Connection Draining, die Probleme mit Sticky Sessions, ausgelagerter Session-Zustand und globales Load Balancing.
- [9.3 Asynchronität, Queues und Backpressure](https://bewiseapps.com/de/software-architecture-wise/resilience-and-operability/queues-and-back-pressure): Wie Queues Lastspitzen in Rückstände verwandeln, Competing Consumers, die Dimensionierung von Queues mit Littles Gesetz, Backpressure, Load Shedding und Priorisierung, Token Bucket und andere Rate Limiter, HTTP 429 mit Retry-After und Dead Letter Queues.
- [9.4 Timeouts, Wiederholungen, Circuit Breaker, Bulkheads und Graceful Degradation](https://bewiseapps.com/de/software-architecture-wise/resilience-and-operability/resilience-patterns): Die Stabilitätsmuster, die verhindern, dass eine einzige langsame Abhängigkeit ein ganzes System lahmlegt: Timeouts und Deadlines, Wiederholungen mit Backoff, Jitter und Budgets, Circuit Breaker, Bulkheads, Fallbacks, Idempotenz und Hedged Requests.
- [9.5 SLIs, SLOs, SLAs und Error Budgets](https://bewiseapps.com/de/software-architecture-wise/resilience-and-operability/slos-and-error-budgets): Wie Sie Zuverlässigkeit aus Sicht der Nutzer mit SLIs messen, SLO-Ziele festlegen, daraus Error Budgets und Richtlinien ableiten, nach Burn Rate alarmieren und SLAs mit sicherem Abstand lockerer halten als die internen Ziele.
- [9.6 Observability: Logs, Metriken und Traces](https://bewiseapps.com/de/software-architecture-wise/resilience-and-operability/observability): Wie Sie in ein laufendes verteiltes System hineinsehen: strukturierte Logs, Metriktypen und Histogramme, RED, USE und die Four Golden Signals, verteiltes Tracing mit W3C Trace Context und OpenTelemetry, Kardinalität und symptombasiertes Alerting.
- [9.7 Kapazitätsplanung und Performancetests](https://bewiseapps.com/de/software-architecture-wise/resilience-and-operability/capacity-and-performance-testing): Wie Sie Kapazität planen, bevor die Nachfrage kommt, und testen, ob sie wirklich vorhanden ist: Prognosen, Reserven und Vorlaufzeiten, Last-, Stress-, Soak-, Spike- und Breakpoint-Tests, offene und geschlossene Lastmodelle, Coordinated Omission und Performancebudgets.
- [9.8 Chaos Engineering, Incidents und schuldfreies Lernen](https://bewiseapps.com/de/software-architecture-wise/resilience-and-operability/chaos-and-incidents): Wie Sie Schwachstellen finden, bevor Nutzer es tun, und aus Ausfällen lernen, die trotzdem passieren: Chaos-Experimente und Game Days, Incident Command, Schweregrade und Statusseiten, schuldfreie Reviews, die Grenzen der MTTR und Maßnahmen, die das System verändern.

### [Kapitel 10: Cloud-native Architektur und Infrastrukturarchitektur](https://bewiseapps.com/de/software-architecture-wise/cloud-native/)
Mittelstufe bis Fortgeschritten. Cloud-Servicemodelle, Container und Kubernetes, die Twelve-Factor App, Infrastructure as Code, CI/CD und Deployment-Strategien, Multi-Region und Edge, Platform Engineering, FinOps und Lock-in als Abwägung.

- [10.1 Cloud-Service- und Bereitstellungsmodelle](https://bewiseapps.com/de/software-architecture-wise/cloud-native/cloud-models): IaaS, CaaS, PaaS, FaaS und SaaS, Public, Private, Hybrid und Multi-Cloud, geteilte Verantwortung, Zonen und Managed Services, was cloud-native bedeutet und wann Mieten nicht billiger ist.
- [10.2 Container und Orchestrierung mit Kubernetes](https://bewiseapps.com/de/software-architecture-wise/cloud-native/containers-and-orchestration): Images, Layer, Registries und die OCI-Standards; warum Orchestrierung nötig ist; Control Plane, Nodes, zentrale Objekte und Reconciliation Loops von Kubernetes; Requests, Limits, Probes und wann Kubernetes überdimensioniert ist.
- [10.3 Die Twelve-Factor App und cloud-native Prinzipien](https://bewiseapps.com/de/software-architecture-wise/cloud-native/twelve-factor): Alle zwölf Faktoren mit ihrer Bedeutung, ihrem Nutzen und den Stellen, an denen sie veraltet sind; die Prinzipien darüber hinaus (Disposability, Unveränderlichkeit, Observability, Sicherheit); und ein ausgearbeitetes Audit eines bestehenden Service mit priorisierten Korrekturen.
- [10.4 Infrastructure as Code und Immutable Infrastructure](https://bewiseapps.com/de/software-architecture-wise/cloud-native/infrastructure-as-code): Deklarativer und imperativer Infrastrukturcode; Terraform, OpenTofu, CloudFormation, Bicep und Pulumi; State, Locking, Drift, Module und Umgebungen; Immutable Infrastructure; GitOps; Policy as Code; und wie man all das testet.
- [10.5 CI/CD-Pipelines und Deployment-Strategien](https://bewiseapps.com/de/software-architecture-wise/cloud-native/ci-cd-and-deployment): Wie eine Änderung vom Commit in die Produktion gelangt: Pipeline-Stufen, Build once, deploy many, Trunk-Based Development, Rolling-, Blue-Green-, Canary- und Shadow-Deployments, Feature-Flags, Migrationen und Rollback.
- [10.6 Multi-Region, Disaster Recovery und Edge Computing](https://bewiseapps.com/de/software-architecture-wise/cloud-native/multi-region-and-edge): Wann und wie Sie über mehrere Regionen hinweg betreiben: Latenz, Disaster Recovery und Datenresidenz, die vier DR-Strategien mit RTO, RPO und Kosten, regionsübergreifende Daten, Failover, Zellen zur Begrenzung des Blast Radius, CDNs und Edge Functions.
- [10.7 Platform Engineering und Internal Developer Platforms](https://bewiseapps.com/de/software-architecture-wise/cloud-native/platform-engineering): Warum Organisationen Internal Developer Platforms aufbauen, Golden Paths und Backstage, die Plattform als Produkt mit Self-Service und Guardrails betreiben, kognitive Last reduzieren, Erfolg mit DORA und SPACE messen und die üblichen Fallen vermeiden.
- [10.8 FinOps, Kostenarchitektur und Anbieter-Lock-in](https://bewiseapps.com/de/software-architecture-wise/cloud-native/finops-and-lock-in): Kosten als architektonisches Qualitätsmerkmal behandeln: FinOps-Phasen, Unit Economics wie Kosten pro Bestellung, häufige Kostentreiber, Nutzungszusagen und Spot, Tagging, Showback und Chargeback sowie Lock-in als bewusste Abwägung mit Exit-Strategie.

### [Kapitel 11: Bewertung, Entscheidungsfindung und Governance](https://bewiseapps.com/de/software-architecture-wise/evaluation-and-governance/)
Fortgeschritten. Wie Architekturen bewertet und gesteuert werden: ATAM und leichtgewichtige Reviews, Fitness Functions und evolutionäre Architektur, Governance in agilen Organisationen, Team Topologies, Modernisierung von Altsystemen, Führung, Ethik und der Business Case.

- [11.1 Architekturbewertung und ATAM](https://bewiseapps.com/de/software-architecture-wise/evaluation-and-governance/architecture-evaluation): Warum und wann eine Architektur bewertet werden sollte, wie die ATAM des SEI Schritt für Schritt funktioniert, was Risiken, Sensitivitätspunkte und Trade-off-Punkte sind und wie CBAM Kosten und Nutzen ergänzt.
- [11.2 Leichtgewichtige Reviews und Risk-Storming](https://bewiseapps.com/de/software-architecture-wise/evaluation-and-governance/lightweight-reviews): Warum Review-Gremien oft scheitern und welche leichtgewichtigen Alternativen funktionieren: Risk-Storming, Pre-Mortems, Architektur-Katas, TARA, RFC-Reviews und Checklisten, mit einem Format für ein 90-minütiges Review.
- [11.3 Fitness Functions und evolutionäre Architektur](https://bewiseapps.com/de/software-architecture-wise/evaluation-and-governance/fitness-functions): Wie Sie Architekturmerkmale mit automatisierten Prüfungen schützen: was Fitness Functions sind, ihre Kategorien, Beispiele für Struktur, Performance, Sicherheit, Resilienz und Daten sowie evolutionäre Architektur.
- [11.4 Architektur-Governance in agilen Organisationen](https://bewiseapps.com/de/software-architecture-wise/evaluation-and-governance/governance-in-agile): Wozu Architektur-Governance dient und wie sie ohne langsame Gates gelingt: Prinzipien, Standards, Guardrails, der Advice Process, beratende Foren, Technologieradare, Policy as Code und Unternehmensarchitektur.
- [11.5 Team Topologies und soziotechnisches Design](https://bewiseapps.com/de/software-architecture-wise/evaluation-and-governance/team-topologies): Wie Sie Teams und Software gemeinsam gestalten: die vier Teamtypen, drei Interaktionsmodi, kognitive Last, Team-APIs und Bruchlinien, mit einer ausgearbeiteten Neuordnung der Teams der Essenslieferplattform.
- [11.6 Altsysteme modernisieren: Strangler Fig und schrittweise Migration](https://bewiseapps.com/de/software-architecture-wise/evaluation-and-governance/legacy-modernisation): Warum große Neuentwicklungen scheitern und wie Sie stattdessen sicher modernisieren: die sieben Rs, das Strangler-Fig-Muster, Branch by Abstraction, Parallelbetrieb, Change Data Capture, Anti-Corruption Layer und eine sorgfältige Datenmigration.
- [11.7 Führung, Einfluss und Entscheidungsfindung](https://bewiseapps.com/de/software-architecture-wise/evaluation-and-governance/leadership-and-influence): Wie Architekten ohne formale Autorität führen: Vertrauen aufbauen, Entscheidungen per Konsent oder Konsens moderieren, mit Konflikten und Politik umgehen, mit der Geschäftsleitung sprechen, den Architect Elevator nutzen und andere Architekten fördern.
- [11.8 Ethik, Nachhaltigkeit und der Business Case](https://bewiseapps.com/de/software-architecture-wise/evaluation-and-governance/ethics-and-business-cases): Wie Sie Architekturarbeit in Geld, Zeit und Risiko begründen, mit durchgerechnetem Kapitalwert und Amortisationszeit; und wie Berufsethik, vorhersehbare Schäden und Green-Software-Praxis verantwortungsvolles Design prägen.

### [Kapitel 12: Architektur KI-gestützter Systeme](https://bewiseapps.com/de/software-architecture-wise/ai-enabled-systems/)
Fortgeschritten. Maschinelles Lernen und große Sprachmodelle aus Sicht der Architektur: wo Modelle ihren Platz haben, Retrieval-Augmented Generation, Agenten und Tool-Nutzung, Evaluierung, Guardrails, Kosten und Latenz, LLMOps und verantwortungsvolle KI nach der KI-Verordnung der EU.

- [12.1 Maschinelles Lernen und große Sprachmodelle für Architekten](https://bewiseapps.com/de/software-architecture-wise/ai-enabled-systems/ml-and-llm-basics): Was maschinelles Lernen und große Sprachmodelle tatsächlich tun, vom Training und der Evaluierung bis zu Tokens, Kontextfenstern, Sampling und Embeddings, und was eine probabilistische Komponente für das System um sie herum bedeutet.
- [12.2 Wo Modelle in eine Architektur gehören](https://bewiseapps.com/de/software-architecture-wise/ai-enabled-systems/where-models-fit): Gehostete, selbst gehostete oder geräteinterne Modelle; Online- und Batch-Inferenz; AI-Gateways, Routing, Kaskaden und Fallback-Kaskaden; Human in the Loop; die Wahl eines Modells; und eine Referenzarchitektur für einen Support-Assistenten.
- [12.3 Retrieval-Augmented Generation und Vektorsuche](https://bewiseapps.com/de/software-architecture-wise/ai-enabled-systems/retrieval-augmented-generation): Wie Sie Modellantworten in Ihren eigenen Daten verankern: Ingestion und Chunking, Embeddings und Vektorindizes, hybride Suche und Re-Ranking, Quellenangaben, Zugriffskontrolle, Aktualität, Evaluierung und Fehlerbilder.
- [12.4 Agenten, Tool-Nutzung und Orchestrierung](https://bewiseapps.com/de/software-architecture-wise/ai-enabled-systems/agents-and-tool-use): Wie Modelle Tools aufrufen, wie die Agentenschleife funktioniert, wann ein Workflow einen autonomen Agenten schlägt, was das Model Context Protocol standardisiert und wie Agenten mit Limits, Idempotenz, Checkpoints und Freigaben verlässlich werden.
- [12.5 KI-gestützte Systeme evaluieren und testen](https://bewiseapps.com/de/software-architecture-wise/ai-enabled-systems/evaluating-ai-systems): Wie Sie Komponenten testen, deren Ausgaben variieren: Golden Sets, Bewertungsmethoden, LLM-as-a-Judge und seine Verzerrungen, Offline- und Online-Evaluierung, Regressions-Evals in der CI, Monitoring in Produktion, Red Teaming und Vertrauen in die Zahlen.
- [12.6 Guardrails, Sicherheit und Prompt-Injection](https://bewiseapps.com/de/software-architecture-wise/ai-enabled-systems/guardrails-and-safety): Warum ein Sprachmodell eine nicht vertrauenswürdige Komponente ist: direkte und indirekte Prompt-Injection, Jailbreaks, die OWASP Top 10 for LLM Applications, die Lethal Trifecta und mehrschichtige Abwehrmaßnahmen, die auch dann halten, wenn das Modell manipuliert wird.
- [12.7 Kosten, Latenz und LLMOps](https://bewiseapps.com/de/software-architecture-wise/ai-enabled-systems/cost-latency-and-llmops): Wirtschaftlichkeit und Betrieb von Modellaufrufen: Eingabe- und Ausgabe-Tokens, Time to First Token und Streaming, Prompt-Caching und semantisches Caching, Batching, Kaskaden, Rate Limits und Fallback-Kaskaden, Versionierung, Tracing und Kostenmonitoring.
- [12.8 Data Governance, verantwortungsvolle KI und die KI-Verordnung der EU](https://bewiseapps.com/de/software-architecture-wise/ai-enabled-systems/responsible-ai): Prinzipien verantwortungsvoller KI in Architektur umsetzen: Datenherkunft und personenbezogene Daten in Prompts und Logs, Bias und Fairness, Transparenz und Model Cards, menschliche Aufsicht, die KI-Verordnung der EU in der Fassung von 2026, das NIST AI RMF und ISO/IEC 42001.

## Weitere Seiten

- [Glossar](https://bewiseapps.com/de/software-architecture-wise/glossary)
- [Wie Kurs, Tests und Zertifikat funktionieren](https://bewiseapps.com/de/software-architecture-wise/how-it-works)
- [Der Einsteigerpfad](https://bewiseapps.com/de/software-architecture-wise/beginners-path): ein empfohlener Weg durch den Kurs in sechs Etappen für alle, denen Software neu ist, mit einer Methode für die schwierigeren Abschnitte
- [Der Weg für Erfahrene](https://bewiseapps.com/de/software-architecture-wise/experienced-route): die Kapitel in derselben Reihenfolge, 0 bis 12, für alle, die bereits mit Software arbeiten, mit Hinweisen, was sie überfliegen können; für das Zertifikat muss trotzdem jeder Kapiteltest bestanden werden
- [Ein Zertifikat prüfen](https://bewiseapps.com/de/software-architecture-wise/verify)