Glossar
Alphabetische Kurzdefinitionen der wichtigsten Begriffe – klar und verständlich.
ADR - Architecture Decision Record
Ein ADR dokumentiert eine Architektur-Entscheidung: Kontext, Optionen, Entscheidung und Begründung. So ist später nachvollziehbar, warum ein Weg gewählt wurde.
Weiterführend:
Audit Trail
Ein Audit Trail ist eine lückenlose, nachvollziehbare Aufzeichnung von Änderungen und Zugriffen. Er zeigt, wer was wann getan hat.
Weiterführend:
Approval Gate
Ein Approval Gate ist ein definierter Freigabepunkt in einer Pipeline oder einem Prozess. Ohne Freigabe geht es nicht weiter.
Weiterführend:
CAB - Change Advisory Board
Ein CAB ist ein Gremium, das größere Änderungen und Releases freigibt. Ziel ist, Risiken zu minimieren, Abhängigkeiten zu klären und wichtige Changes nachvollziehbar zu entscheiden.
Weiterführend:
Blue-Green Deployment
Blue-Green Deployment bedeutet, zwei Produktionsumgebungen parallel zu betreiben. Releases werden umgeschaltet, um Risiko und Downtime zu reduzieren.
Weiterführend:
Canary Deployment
Canary Deployment bedeutet, eine neue Version schrittweise für einen kleinen Teil der Nutzer auszurollen, bevor sie vollständig live geht.
Weiterführend:
C4-Modell
Das C4-Modell beschreibt Software-Architektur in vier Ebenen: Context, Container, Component und Code.
Weiterführend:
CI - Continuous Integration
Continuous Integration bedeutet, dass Code regelmäßig automatisch gebaut und getestet wird, damit Fehler früh erkannt werden.
Weiterführend:
CI/CD - Continuous Integration / Continuous Delivery
CI/CD beschreibt automatisierte Build-, Test- und Release-Pipelines. Ziel ist, häufig, zuverlässig und reproduzierbar ausliefern zu können.
Weiterführend:
Change Control
Change Control ist ein formaler Prozess, der Änderungen plant, prüft, genehmigt und nachverfolgt, bevor sie produktiv gehen.
Weiterführend:
Compliance
Compliance bedeutet, dass Regeln, Standards oder Gesetze eingehalten werden (z. B. Datenschutz, Sicherheitsstandards oder Branchenvorgaben).
Weiterführend:
DDD - Domain-Driven Design
DDD ist ein Ansatz, Software an fachlichen Domänen auszurichten, um komplexe Systeme verständlicher und wartbarer zu machen.
Weiterführend:
Dependency Scan - Abhängigkeitsprüfung
Ein Dependency Scan prüft Drittbibliotheken auf bekannte Sicherheitslücken.
Weiterführend:
Diff-Coverage
Diff-Coverage misst die Testabdeckung nur für geänderten Code. So kann man Qualität schrittweise verbessern, ohne sofort 100% zu verlangen.
Weiterführend:
Disaster Recovery (DR)
Disaster Recovery beschreibt Pläne und Tests, um ein System nach Ausfällen wiederherzustellen (z. B. Rechenzentrum down, Datenverlust).
Weiterführend:
DPIA - Data Protection Impact Assessment
Eine DPIA (Datenschutz-Folgenabschätzung) bewertet Risiken für personenbezogene Daten, bevor ein System oder Prozess live geht.
Weiterführend:
E2E - End-to-End
E2E-Tests prüfen einen kompletten Geschäftsprozess vom Eingang bis zum Ergebnis. Sie simulieren echte Nutzerabläufe und zeigen, ob das System als Ganzes funktioniert.
Weiterführend:
Error Tracking
Error Tracking sammelt und analysiert Fehler in laufenden Systemen, damit Probleme schnell gefunden und behoben werden können (z. B. Stacktraces, Alerts).
Weiterführend:
Evidence
Evidence bezeichnet Nachweise, z. B. Testprotokolle, Freigaben oder Audit-Dokumente, die belegen, dass Anforderungen erfüllt wurden.
Weiterführend:
Feature Flag
Ein Feature Flag schaltet Funktionen gezielt ein oder aus, ohne neuen Code zu deployen. Das senkt Risiko bei Releases und ermöglicht kontrollierte Rollouts.
Weiterführend:
Governance
Governance beschreibt die Regeln, Verantwortlichkeiten und Entscheidungswege, mit denen ein System gesteuert wird.
Weiterführend:
Incident
Ein Incident ist eine Störung im laufenden Betrieb (z. B. Ausfall, Sicherheitsvorfall). Er wird über definierte Prozesse erkannt, bearbeitet und dokumentiert.
Weiterführend:
ISMS - Information Security Management System
Ein ISMS ist ein Managementsystem für Informationssicherheit. Es beschreibt Prozesse, Rollen und Kontrollen, um Sicherheitsrisiken systematisch zu steuern.
Weiterführend:
MVP - Minimum Viable Product
Ein MVP ist die kleinste Version eines Produkts, die nutzbares Feedback ermöglicht. Ziel ist Lernen bei minimalem Aufwand.
Weiterführend:
On-Call
On-Call bedeutet Rufbereitschaft: Eine Person ist erreichbar, um bei Incidents schnell zu reagieren.
Weiterführend:
Observability
Observability beschreibt, wie gut man den internen Zustand eines Systems anhand von Logs, Metrics und Tracing verstehen kann.
Weiterführend:
PCI - Payment Card Information
PCI meint Zahlungs- und Kreditkarteninformationen wie Kartennummer, Ablaufdatum und Sicherheitscode. Diese Daten unterliegen strengen Sicherheitsregeln.
Weiterführend:
PHI - Protected Health Information
PHI sind personenbezogene Gesundheitsdaten, z. B. Diagnosen, Behandlungen oder Abrechnungen. Sie gelten als besonders schutzbedürftig und unterliegen strengen gesetzlichen Regeln.
Weiterführend:
PII - Personally Identifiable Information
PII sind Informationen, die eine Person direkt oder indirekt identifizierbar machen, z. B. Name, Adresse, Geburtsdatum, E-Mail-Adresse oder Versicherungsnummer.
Weiterführend:
POC - Proof of Concept
Ein Proof of Concept ist ein kurzer Machbarkeitsnachweis: Es wird geprüft, ob eine Idee oder Technologie grundsätzlich funktioniert.
Weiterführend:
Post-Mortem
Ein Post-Mortem ist eine strukturierte Nachbesprechung nach einem Incident. Ziel ist Lernen, nicht Schuldzuweisung.
Weiterführend:
Pen-Test - Penetration Test
Ein Penetrationstest versucht, Sicherheitslücken aktiv auszunutzen, um Schwachstellen zu finden, bevor Angreifer es tun.
Weiterführend:
Rollback
Rollback bedeutet, eine Änderung rückgängig zu machen und auf eine stabile Version zurückzukehren.
Weiterführend:
Runbook
Ein Runbook ist eine Schritt-für-Schritt-Anleitung für den Betrieb, z. B. für Deployments, Störungen oder Wiederherstellung.
Weiterführend:
SBOM - Software Bill of Materials
Eine SBOM ist eine Stückliste aller Software-Komponenten und Abhängigkeiten. Sie hilft, Sicherheitsrisiken und Lieferkettenprobleme zu erkennen.
Weiterführend:
SAST - Static Application Security Testing
SAST sind statische Code-Analysen, die Sicherheitsprobleme im Quellcode erkennen, ohne das Programm auszuführen.
Weiterführend:
Segregation of Duties
Segregation of Duties bedeutet, dass kritische Aufgaben auf mehrere Rollen verteilt sind, um Missbrauch und Fehler zu vermeiden.
Weiterführend:
SLA - Service Level Agreement
Ein SLA ist eine verbindliche Vereinbarung zwischen Dienstleister und Kunde, die festlegt, welche Leistungen in welcher Qualität erbracht werden. Typische Inhalte sind Verfügbarkeit, Reaktions- und Lösungszeiten, Supportzeiten sowie Konsequenzen bei Nichteinhaltung.
Weiterführend:
SLO - Service Level Objective
Ein SLO ist ein internes Ziel für Service-Qualität, z. B. "99,9% Verfügbarkeit". SLOs helfen, messbare Qualitätsziele zu definieren, ohne sofort vertragliche Verpflichtungen einzugehen.
Weiterführend:
Smoke-Test
Ein Smoke-Test ist ein schneller Test, der prüft, ob die wichtigsten Funktionen grundsätzlich laufen.
Weiterführend:
Staging
Staging ist eine Umgebung, die der Produktion möglichst ähnlich ist, um Releases vorab zu testen.
Weiterführend:
SCS - Self-Contained Systems
SCS ist ein Architekturansatz für modulare Systeme, bei denen jedes Modul weitgehend autonom funktioniert.
Weiterführend:
STRIDE - Threat Modeling
STRIDE ist eine Methode, um Sicherheitsbedrohungen systematisch zu identifizieren: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
Weiterführend:
Tech-Radar
Ein Tech-Radar dokumentiert, welche Technologien genutzt, evaluiert oder vermieden werden, um technische Entscheidungen transparent zu machen.
Weiterführend:
Testpyramide
Die Testpyramide beschreibt das Verhältnis von Unit-, Integrations- und E2E-Tests: viele Unit-Tests, weniger Integrationstests, wenige E2E-Tests.
Weiterführend:
Threat Model
Ein Threat Model beschreibt mögliche Angriffe und Risiken für ein System und leitet Schutzmaßnahmen ab.
Weiterführend:
Traceability - Nachverfolgbarkeit
Traceability bedeutet, dass Anforderungen, Code, Tests und Releases eindeutig verknüpft sind. So lässt sich nachvollziehen, warum eine Änderung gemacht wurde und wie sie getestet ist.
Weiterführend:
V&V - Verifikation und Validierung
Verifikation prüft, ob das System korrekt nach Spezifikation gebaut wurde. Validierung prüft, ob das System den Zweck erfüllt und für Nutzer tatsächlich passt.
Weiterführend: