Glossar
Definitionen der wichtigsten Begriffe aus dem WAF++-Framework, Scoring-Modell, Governance und Tooling. Bei Unklarheiten ist dies die maßgebliche Quelle.
Der Static-Site-Generator, mit dem die WAF++-Dokumentation aus AsciiDoc-Quellen gebaut wird. Antora übernimmt Komponenten-Versionierung, Navigation und Publishing — die WAF++-Docs befinden sich unter /docs/ und werden aus dem framework-Repository gebaut.
Siehe auch: AsciiDoc
Die Auszeichnungssprache für die WAF++-Framework-Dokumentation. Ähnlich wie Markdown, aber mit reichhaltigerer Semantik für strukturierte Dokumentation. Alle Dateien in modules/ROOT/pages/ verwenden AsciiDoc (.adoc-Erweiterung).
Eine strukturierte Bewertung eines Cloud-Workloads anhand der WAF++-Controls über alle anwendbaren Säulen hinweg. Das Ergebnis eines Assessments ist eine Menge von Findings pro Control und ein PASS-Score pro Säule sowie aggregiert.
Siehe auch: Workload, PASS-Modell
Deutsch für Assessment. Strukturierte Überprüfung eines Workloads gegen die WAF++-Controls. Ergibt Findings pro Control und PASS-Scores pro Säule.
Siehe auch: Assessment
Ein kurzes Dokument, das Zweck, Scope, Deliverables, Leads und Kommunikationskanal einer Working Group definiert. Ein Charter ist Voraussetzung, bevor eine WG offiziell anerkannt werden kann.
Siehe auch: Working Group
Eine spezifische, testbare Anforderung innerhalb einer Säule. Jeder Control hat eine eindeutige ID, eine Beschreibung, eine Bewertungsfrage und eine Begründung. Controls sind die atomare Einheit des WAF++-Frameworks — ein Workload erfüllt einen Control oder nicht.
Siehe auch: Control-ID, Säule, Controls Library
Der eindeutige Bezeichner für einen WAF++-Control, nach dem Muster WAF-[SÄULE]-[NUMMER]. Beispiel: WAF-SOV-010 ist der erste Control des Sovereign-Pillars. Die Säulenabkürzung ist ein dreistelliger Code (z.B. SEC für Security, SOV für Sovereign). Control-IDs sind stabil — einmal veröffentlicht, werden sie nie geändert oder wiederverwendet.
Die vollständige Sammlung aller WAF++-Controls, gespeichert als strukturierte YAML-Dateien im framework-Repository unter modules/controls/. Jede Datei definiert einen Control mit ID, Säule, Titel, Beschreibung, Bewertungsfrage und Begründung.
WAF++ nutzt zwei Lizenzen: Apache License 2.0 für Code, Tooling und Schemas; Creative Commons Attribution 4.0 (CC BY 4.0) für Dokumentation und schriftliche Inhalte. Dies ermöglicht breite Wiederverwendung bei gleichzeitiger Namensnennung. Siehe Legal-Seite.
Das Ergebnis der Bewertung eines Controls gegen einen Workload. Ein Finding ist entweder erfüllt, nicht erfüllt oder nicht anwendbar. Findings sind der Rohoutput eines Assessments, der dann zu einem PASS-Score aggregiert wird.
Ein Qualitätsstandard für das WAF++-Governance-Modell, der anzeigt, dass Struktur, Richtlinien und Transparenz des Projekts den Anforderungen für eine Übergabe an eine Open-Source-Foundation (z.B. CNCF, Apache Software Foundation) genügen. Foundation-Readiness ist ein erklärtes Ziel für das WAF++ v1.0-Release.
Die Gesamtheit der Regeln, Prozesse und Rollen, die bestimmen, wie Entscheidungen im WAF++-Projekt getroffen werden. Die WAF++-Governance ist öffentlich dokumentiert und umfasst: RFC-Prozess, TSC-Zusammensetzung und Abstimmung, Maintainer-Bedingungen, Working-Group-Regeln und Durchsetzung des Verhaltenskodex.
Siehe auch: TSC, RFC, Governance & Community
Die Praxis, Cloud-Infrastruktur über maschinenlesbare Konfigurationsdateien statt manueller Prozesse zu verwalten und bereitzustellen. Relevant für mehrere WAF++-Säulen, insbesondere Operative Exzellenz und Sicherheit.
Im WAF++-Kontext wird der englische Begriff Control verwendet — auch in der deutschen Version. Deutsch für „Kontrolle" oder „Anforderung". Spezifische, testbare Anforderung innerhalb einer Säule mit eindeutiger Control-ID.
Siehe auch: Control
Ein leichtgewichtiger Entscheidungsmechanismus für nicht-breaking oder risikoärmere Änderungen. Ein Vorschlag wird öffentlich gepostet mit einem Mindest-Review-Fenster von 5 Werktagen. Wird kein substanziierter Einwand erhoben, gilt der Vorschlag als angenommen. Bei größeren Änderungen wird stattdessen eine TSC-Abstimmung genutzt.
Ein Beitragender mit Merge-Berechtigungen in einem oder mehreren WAF++-Repositories. Maintainer reviewen PRs, genehmigen oder lehnen RFCs ab und sind für Qualität und Richtung ihres Bereichs verantwortlich. Maintainer-Laufzeiten sind 12 Monate, verlängerbar. Inaktivität über 90+ Tage kann zu Emeritus-Status führen.
Siehe auch: Rollen & Mitglieder
Das WAF++-Scoring-Modell. PASS steht für die vier Leistungsstufen: Pioneer, Advanced, Solid, Starter. Jede Stufe entspricht einem Grad der Control-Erfüllung innerhalb einer Säule. Das PASS-Modell ist die normative Scoring-Spezifikation — Details auf der PASS-Seite.
Siehe auch: PASS-Score, Scoring-Tier
Das Ergebnis der Anwendung des PASS-Modells auf ein Assessment. Ein Workload erhält einen Score pro Säule und einen aggregierten Gesamtscore. Scores werden als Tiers ausgedrückt (Pioneer / Advanced / Solid / Starter), nicht als Prozentwerte, um qualitative Reife statt roher Bestehensquoten abzubilden.
Eine der sieben Bewertungsdimensionen von WAF++. Jede Säule gruppiert Controls, die ein spezifisches Qualitätsmerkmal von Cloud-Workloads adressieren. Die sieben Säulen: Sicherheit, Zuverlässigkeit, Performance-Effizienz, Kostenoptimierung, Operative Exzellenz, Nachhaltigkeit und Developer Experience (Sovereign ist die 7. Säule ab v1.0-Beta).
Siehe auch: Control, Die 7 Säulen
Ein öffentlicher Vorschlag für eine wesentliche Änderung am WAF++-Framework, der Governance, den Tools oder dem Scoring-Modell. RFCs werden als GitHub Discussions eröffnet, mindestens 5 Werktage von der Community geprüft und dann per TSC-Abstimmung oder Lazy Consensus entschieden. Jeder RFC erhält eine sequenzielle ID (RFC-NNNN) und wird im RFC Tracker verfolgt.
Eine der sieben Bewertungsdimensionen von WAF++. Im englischen Sprachgebrauch wird durchgängig „Pillar" verwendet; im Deutschen sind beide Begriffe üblich. Jede Säule enthält eine Gruppe thematisch verwandter Controls.
Eine der vier Stufen im PASS-Modell. In absteigender Reihenfolge: Pioneer (höchste), Advanced, Solid, Starter (Basis). Tiers spiegeln Breite und Tiefe der Control-Erfüllung wider, nicht nur die Anzahl bestandener Controls.
Siehe auch: PASS-Modell
Der 7. Pillar von WAF++, der Datensouveränität, regulatorische Compliance und jurisdiktionale Kontrolle abdeckt. In der v1.0-Beta-Phase mit 10 initialen Controls (WAF-SOV-010 bis WAF-SOV-100) eingeführt. Besonders relevant für regulierte Branchen und EU-basierte Workloads.
Das leitende Gremium des WAF++-Projekts. Der TSC ist für technische Ausrichtung, RFC-Entscheidungen und Maintainer-Ernennungen zuständig. Mitglieder dienen 12-monatige, verlängerbare Amtszeiten. Die TSC-Zusammensetzung folgt dem Prinzip „aktive Beitragende zuerst" und anbieterneutraler Balance. Alle TSC-Entscheidungen sind öffentlich dokumentiert.
Siehe auch: Governance & Community, Rollen & Mitglieder
Ein Kerndesignprinzip von WAF++: Säulen, Controls und Scoring-Modell gelten gleichermaßen für Workloads auf jedem Cloud-Anbieter (AWS, Azure, GCP und andere). Kein Control ist anbieterspezifisch, sofern nicht explizit gekennzeichnet. Dies ermöglicht konsistente anbieterübergreifende Assessments.
Well-Architected Framework Plus Plus. Ein Open-Source-, anbieterneutrales Framework zur Bewertung und Verbesserung der Qualität von Cloud-Workloads. WAF++ erweitert konventionelle Well-Architected-Reviews um ein transparentes, community-gesteuertes Scoring-Modell (PASS) und eine maschinenlesbare Controls Library über 7 Säulen.
Ein themenspezifisches Beitragenden-Team innerhalb von WAF++. Working Groups bauen spezifische Teile des Frameworks — eine Säule, eine Tooling-Komponente, eine Referenzarchitektur — und liefern Outputs als PRs und RFCs. Jeder Beitragende kann eine WG mit Charter, Lead und Maintainer-Sponsor vorschlagen.
Die Cloud-Anwendung, der Service oder das System, das mit WAF++ bewertet wird. Ein Workload hat einen definierten Scope (z.B. ein Microservice, eine Datenplattform, ein gesamtes Produkt) und wird gegen die anwendbaren WAF++-Controls bewertet. Der Scope wird vor einem Assessment festgelegt.
Siehe auch: Assessment
Begriff fehlt oder unklar?
Ein Content-Issue auf GitHub eröffnen oder eine Definition auf Slack vorschlagen.
Issue öffnen → Zur Dokumentation →