Architecture Reference (Enterprise Architect / Design Authority)
Für regulierte EU-/französische Kontexte (Banken, Gesundheitswesen, Verteidigung). Regulatorische Details entwickeln sich weiter: Alles, was mit „überprüfen" gekennzeichnet ist, muss vor der Verwendung in einem Arbeitsergebnis mit dem aktuellen amtlichen Text abgeglichen werden.
Referenzindex
references/togaf-archimate.md— Lesen bei der Strukturierung eines Architekturvorhabens (ADM-Phasen, Arbeitsergebnisse, Governance, Compliance-Prüfungen) oder der Modellierung mit ArchiMate (Ebenen, Elemente, Beziehungen, Sichten). Vollständiger Pfad${CLAUDE_PLUGIN_ROOT}/skills/architecture-reference/references/togaf-archimate.mdreferences/urbanisation.md— Lesen bei der Erstellung oder Nutzung französischer IS-Karten (Zonen/Quartiere/Inseln, Kartografien), eines Schéma Directeur, der Bewertung von Anwendungsportfolios (TIME) oder der Erstellung eines Rationalisierungs-/Stilllegungsplans. Vollständiger Pfad${CLAUDE_PLUGIN_ROOT}/skills/architecture-reference/references/urbanisation.mdreferences/adr.md— Lesen beim Verfassen oder Überprüfen eines Architecture Decision Record oder einer Entscheidungsmatrix (Nygard, MADR, Y-Aussagen, gewichtete Kriterien, fiktive Beispiele). Vollständiger Pfad${CLAUDE_PLUGIN_ROOT}/skills/architecture-reference/references/adr.md
Zugehörige Vorlagen für Arbeitsergebnisse: ${CLAUDE_PLUGIN_ROOT}/skills/deliverables/templates/dat.md, interface-contract.md, flow-matrix.md.
Regulatorische Details (DSGVO, DORA, NIS2, HDS, II 901, IGI 1300…) befinden sich in der Fähigkeit sector-compliance und ihren Branchenreferenzen (${CLAUDE_PLUGIN_ROOT}/skills/sector-compliance/references/); diese Fähigkeit behandelt nur die Auswirkungen auf die Architektur.
1. Rolle: Design Authority
Besitzt: Architekturprinzipien und -standards; Zielarchitektur und Roadmap; strukturelle Entscheidungen (ADRs); Kohärenz über Domänen und Experten hinweg; Ausnahmegenehmigungen (Dérogations) mit Verfallsdatum; Architektur-Compliance-Prüfungen; Register für technische Schulden auf Architekturebene. Besitzt nicht: Akzeptanz von Sicherheitsrisiken (Business Risk Owner / Homologationsbehörde, beraten durch RSSI); Entscheidungen über personenbezogene Daten (Verantwortlicher, beraten durch DSB); Budget-/Terminentscheidungen (COPIL); Produktionsänderungen (CAB).
Prüfungs-Gates
| Gate | Zeitpunkt | Prüfungen |
|---|---|---|
| G0 Scoping | Note de cadrage | Übereinstimmung mit Zielarchitektur/Roadmap, identifizierte Optionen, regulatorisches Umfeld, Souveränitätsklasse der Daten |
| G1 Design | DAT-/Schnittstellenvertragsentwürfe | Einhaltung der Prinzipien, quantifizierte NFRs, Integrationsmuster, Datenverantwortung, Sicherheitsarchitektur, Reversibilität |
| G2 Pre-build | Design eingefroren | ADRs akzeptiert, Ausnahmegenehmigungen unterzeichnet, Flow-Matrix vollständig, Betriebs-/Notfallwiederherstellungs-Design |
| G3 Pre-go-live | Vor Go/No-Go | As-built vs. DAT, angefallene Schulden erfasst, Notfallwiederherstellung getestet, DORA-Register / Abhängigkeitskarte aktualisiert |
Ergebnis einer Prüfung: konform / konform mit Auflagen (Maßnahmen + Termine) / Ausnahmegenehmigung (Risikoeigner + Verfallsdatum) / nicht konform (blockierend).
2. Architekturprinzipien
Format (TOGAF-Stil): Name — Aussage — Begründung — Auswirkungen. Behalten Sie 10-15 bei, jedes in einer Prüfung testbar. Standardsatz für regulierte Integrationskontexte:
| # | Prinzip | Testbare Auswirkung |
|---|---|---|
| P1 | Geschäftskontinuität durch Design | Jede kritische Funktion hat festgelegte RTO/RPO, die durch Design erfüllt und getestet werden |
| P2 | Sicherheit und Datenschutz durch Design und durch Voreinstellung (DSGVO Art. 25) | Daten vor dem Design klassifiziert (DICT); Least Privilege; Verschlüsselung während der Übertragung und im Ruhezustand |
| P3 | Single Source of Truth pro Datendomäne | Jede Dateneinheit hat ein Mastersystem und einen benannten Eigentümer; andere halten kontrollierte Kopien |
| P4 | Lose Kopplung durch verwaltete Schnittstellen | Kein direkter Zugriff auf die Datenbank einer anderen Anwendung; alle Austausche über vertraglich festgelegte APIs, Nachrichten oder Dateien |
| P5 | Wiederverwendung vor Kauf vor Bau | Bestehende Shared Platforms (MFT, API-Gateway, IAM, Scheduler) werden verwendet, sofern ein ADR nichts anderes besagt |
| P6 | Standards und offene Formate | Offene Protokolle/Formate bevorzugt; proprietäre nur mit Reversibilitätsplan |
| P7 | Reversibilität und Ausstieg | Jeder externe Dienst hat einen Ausstiegsplan; Daten in dokumentierten Formaten exportierbar |
| P8 | Betriebsfähigkeit als Anforderung | Überwachung, Protokolle, Planung, Neustart und DEX werden mit der Lösung entworfen |
| P9 | Rückverfolgbarkeit und Prüfbarkeit | End-to-End-Korrelations-IDs; Prüfpfade gemäß gesetzlicher Anforderungen aufbewahrt |
| P10 | Datenresidenz und -souveränität nach Klassifizierung | Hosting-Wahl abgeleitet aus Datenklasse (siehe §6) |
| P11 | Einfachheit und Rationalisierung | Neue Komponente nur, wenn keine vorhandene passt; Stilllegung bei jedem Austausch geplant |
| P12 | Lieferkette automatisieren | Infrastruktur und Bereitstellungen als Code, reproduzierbare Umgebungen |
3. Ziel- vs. Übergangsarchitekturen
- Baseline (Ist-Zustand), Target (Soll-Zustand zum Horizont, typischerweise 3-5 Jahre), Übergangsarchitekturen (Plateaus: stabile, betriebsfähige Zwischenzustände, die Wert liefern), Gap-Analyse (was hinzugefügt, entfernt, geändert wird), Roadmap (Arbeitspakete, Abhängigkeiten, Stilllegungstermine).
- Jeder Übergang muss für sich allein betriebsfähig sein (unterstützt, überwacht, notfallwiederherstellungsfähig, dokumentiert) — das Projekt kann dort enden.
- Koexistenzbrücken (temporäre Synchronisation, Vermeidung von Dual-Writes, Anti-Korruptionsschichten) sind erstklassige Komponenten: Eigentümer, Kosten, Enddatum, Schuldeneintrag.
- „Vorübergehend" ohne Enddatum wird dauerhaft: lehnen Sie es bei G1 ab.
- Bevorzugen Sie eine inkrementelle Migration (Strangler Fig: Funktionen schrittweise hinter einer Fassade an das neue System weiterleiten) gegenüber einem Big-Bang-Austausch, wenn das Altsystem groß und schlecht dokumentiert ist.
4. Integrationsarchitektur (Makroebene)
Detailliertes Design gehört zum Integrationsexperten; der Architekt legt das Muster und die Regeln fest.
| Muster | Geeignet für | Vermeiden bei | Fallstricke |
|---|---|---|---|
| Punkt-zu-Punkt | ≤ wenige stabile Abläufe, taktisch | Viele Konsumenten, häufige Änderungen | Spaghetti (n² Verbindungen), keine zentrale Überwachung |
| Hub & Spoke / EAI / ESB | Viele heterogene Systeme, Transformationen, zentrale Governance | Hub wird zum Engpass/Monolithen der Geschäftslogik | Geschäftslogik aus dem Bus heraushalten |
| Dateiübertragung via MFT | Batch, große Mengen, Partneraustausche, Altsysteme (sehr verbreitet im Bankwesen/IBM i) | Echtzeitbedarf | Integritätsprüfungen, Benennung, Cut-Off-Zeiten, erneutes Senden, Verschlüsselung, Nichtabstreitbarkeit |
| API-led (System-/Prozess-/Erfahrungsebenen) | Wiederverwendbare Dienste, digitale Kanäle, Partner-APIs | Massendatenbewegung | API-Management, Versionierung, Kontingente, OAuth2/mTLS |
| Ereignisgesteuert (Pub/Sub, Event Streaming, CDC) | Entkoppelte Reaktionen, Echtzeitweiterleitung, viele Konsumenten | Starke transaktionale Konsistenz über Systeme hinweg erforderlich | Reihenfolge, Idempotenz, Schemaentwicklung, Wiederholung, Ereigniseigentum |
| Datenplattform (DWH, Lake, Lakehouse, Data Mesh) | Analysen, regulatorische Berichterstattung, ML | Operative transaktionale Integration | Herkunft, Qualität, Aufbewahrung, Trennung sensibler Daten |
| MDM / Referentials | Gemeinsame Stammdaten (Kunde, Produkt, Organisation, Patientenidentität) | Daten mit einem einzigen natürlichen Eigentümer | Governance- und Stewardship-Aufwand sind die tatsächlichen Kosten |
Faustregeln: synchrone Aufrufe nur, wenn der Aufrufer die Antwort wirklich jetzt braucht; asynchron als Standard zwischen Domänen; jeden Ablauf auf Fehler auslegen (Wiederholung mit Backoff, Dead Letter, Wiederholung, idempotente Konsumenten); das Outbox-Muster statt Dual Writes verwenden; kanonische Datenmodelle nur innerhalb eines begrenzten Bereichs (unternehmensweite kanonische Datenmodelle überleben selten); jeden Vertrag versionieren; eine Korrelations-ID durchgängig.
5. Nicht-funktionale Anforderungen
Quantifizieren Sie jede NFR; „hochverfügbar" ist keine Anforderung.
| Kategorie | Metriken / Fragen | Fallstricke |
|---|---|---|
| Verfügbarkeit | % über einen Zeitraum, Servicezeiten, erlaubte geplante Ausfallzeit | Ignorieren der Abhängigkeitskette; Messen der Infrastruktur, nicht des Dienstes |
| Kontinuität | RTO / RPO (DMIA / PDMA) pro Geschäftsfunktion, MTPD | RPO 0 mit asynchroner Replikation versprochen; Batch-Neustart ignoriert |
| Leistung | Durchsatz, p95/p99-Latenz, Batch-Fenster, Spitzenfaktor, Wachstum | Testen von Durchschnitt, nicht Spitze; Monatsendspitzen vergessen |
| Skalierbarkeit | Volumen zum Horizont, Elastizität | Lizenzmodelle, die Kosten nichtlinear skalieren |
| Sicherheit | DICT-Einstufung, IAM, Verschlüsselung, Protokollierung, Trennung | Sicherheit nach dem Design aufgesetzt |
| Betriebsfähigkeit | Überwachung, Alarmierung, Protokolle, Neustart, Planung, Automatisierung | DEX nach dem Go-Live geschrieben |
| Beobachtbarkeit | Traces, Metriken, Protokolle, Korrelation, Geschäfts-KPIs | Keine End-to-End-Sicht über die Middleware hinweg |
| Reversibilität | Ausstiegsplan, Exportformate, Zeit und Kosten für den Ausstieg | Nur vertraglich, nie getestet |
| Interoperabilität | Standards (z. B. ISO 20022 im Zahlungsverkehr, HL7 FHIR im Gesundheitswesen – überprüfen Sie Branchenvorgaben) | Lokale Dialekte von Standards |
| Compliance / Residenz | Datenstandort, Aufbewahrung, rechtliche Aufbewahrungspflichten, Prüfung | Backups und Protokolle außerhalb der vereinbarten Zone gespeichert |
| Wartbarkeit | Upgrade-Rhythmus, Hersteller-Support-Daten | Ende des Supports mitten im Projekt |
| Nachhaltigkeit | Ressourceneffizienz (RGESN-Okodesign-Richtlinien in Frankreich – Status überprüfen) | Überdimensionierte Nicht-Produktionsumgebungen |
Verfügbarkeits-Spickzettel (pro Jahr): 99 % ≈ 3,65 Tage; 99,5 % ≈ 1,83 Tage; 99,9 % ≈ 8,76 h; 99,95 % ≈ 4,38 h; 99,99 % ≈ 52,6 Min.; 99,999 % ≈ 5,3 Min. Serielle Kette: A = A1 × A2 × … ; Redundantes Paar: A = 1 − (1 − A1)(1 − A2) (geht von unabhängigen Fehlern aus – selten vollständig zutreffend). RPO/RTO-Kohärenz: RPO ist durch den Replikationsmodus und die Sicherungshäufigkeit begrenzt; RTO umfasst Erkennung, Entscheidung, Failover, Datenreparatur, Batch-Aufholung und Partner-Re-Synchronisation – nicht nur die technische Umschaltzeit.
6. Cloud-Strategie & Souveränität
Erst klassifizieren, dann hosten: Die Datenklasse bestimmt die Hosting-Option.
| Daten-/Systemklasse | Typische Hosting-Optionen (gegen aktuelle Regeln prüfen) |
|---|---|
| Öffentlich / intern, nicht sensibel | Public Cloud mit Standardkontrollen akzeptabel |
| Personenbezogene Daten (DSGVO) | EU-Hosting bevorzugt; Übermittlungen außerhalb des EWR benötigen eine Grundlage nach Kapitel V und eine Transfer-Folgenabschätzung |
| Gesundheitspersonenbezogene Daten (Frankreich) | HDS-zertifizierter Hosting-Anbieter erforderlich (Code de la santé publique, Art. L.1111-8); das aktuelle HDS-Referenzial fügt Datenstandortanforderungen im EWR hinzu – aktuelle Version und Übergangstermine überprüfen |
| Daten von besonderer Sensibilität (Données d'une sensibilité particulière) von Staatsdiensten, Staatsbetreibern und gelisteten GIP | SecNumCloud-qualifiziertes Angebot oder eine EU-/EWR-Zertifizierung, die ANSSI als gleichwertig anerkennt: SREN-Gesetz Art. 31 (2024), Dekret Nr. 2026-272 (14. April 2026), Erlass vom 12. August 2026; die „Cloud au centre"-Doktrin (2021, aktualisiert 2023) erweitert die Erwartung auf andere staatliche IS – Ausnahmeregelung in diesen Texten |
| Diffusion Restreinte (DR) | Systeme gemäß II 901 akkreditiert; spezifische Hosting-Einschränkungen – überprüfen |
| Einstufung (Secret / Très Secret, IGI 1300) | Dedizierte akkreditierte Infrastruktur; Public Cloud im Allgemeinen ausgeschlossen |
| Kritische oder wichtige Bankfunktionen | Zulässig mit DORA-Anforderungen an Dritte, Auslagerungsregeln (EBA-Leitlinien) und ggf. Benachrichtigung der Aufsichtsbehörde – überprüfen |
SecNumCloud: ANSSI-Qualifikation von Cloud-Dienstanbietern gemäß dem Referenzial der Anforderungen v3.2 (8. März 2022; die durch den Erlass vom 12. August 2026 genehmigte Version). Über technische Sicherheitsanforderungen hinausgehend, schützt §19.6 vor außereuropäischem extraterritorialem Recht: Anbieter mit Sitz in der EU, Anteilseigner außerhalb der EU auf 24 % einzeln und 39 % insgesamt begrenzt, Daten in der EU gespeichert und Dienst aus der EU verwaltet und überwacht. „Souveräne" Marketing-Labels sind keine Qualifikation: Fragen Sie nach dem Qualifikationszertifikat und seinem genauen Dienstumfang. Extraterritoriale Gefährdung: Bewerten Sie das Risiko des rechtlichen Zugriffs außerhalb der EU (z. B. US CLOUD Act, FISA s.702) in Bezug auf die Datenklasse; Verschlüsselung mit kundeneigenen Schlüsseln (HSM/BYOK/HYOK) reduziert, beseitigt es jedoch nicht immer. Reversibilitätsklauseln (Vertrag + Architektur): Ausstiegsplan und Unterstützungszeitraum; Export von Daten und Metadaten in dokumentierten offenen Formaten zu nicht prohibitiven Kosten; Löschzertifikat; Export von Dokumentation und Konfiguration; Kontinuität des Dienstes während des Ausstiegs; Kündigungsfristen; Liste der Unterauftragsverarbeiter; Prüfrechte. EU Data Act (Verordnung (EU) 2023/2854, Kapitel VI) gilt seit 12. September 2025: Anbieter müssen den Wechsel unterstützen und dürfen bis 12. Januar 2027 nur ihre tatsächlichen Wechsel-/Egress-Kosten in Rechnung stellen, danach keine mehr. Architektur-Enablement: portable Workloads (Container, IaC), Standarddatenbanken oder dokumentierte Migrationspfade, tiefe Kopplung an proprietäres PaaS für Kernfunktionen vermeiden, es sei denn, ein ADR akzeptiert es, periodischer Ausstiegstest (mindestens Export + Wiederherstellung anderswo). Cloud-Migrationsoptionen (6R/7R): Stilllegen, Beibehalten, Rehosten, Verlagern, Replatformen, Refaktorisieren, Rückkaufen – entscheiden Sie pro Anwendung aus der Portfolio-Bewertung (siehe Urbanisations-Referenz).
7. Management technischer Schulden
- Typen: Architektur (falsches Muster, Kopplung), Veralterung (End-of-Support-Versionen), Code, Daten (Qualität, Dubletten), Betrieb (manuelle Schritte), Dokumentation, Sicherheit (verschobene Korrekturen).
- Register: Posten, Typ, Ort, Ursache (bewusst via ADR / unbeabsichtigt), Zins (Kosten oder Risiko pro Periode), Kapital (Kosten zur Behebung), Eigentümer, Frist, Link zu ADR/Ausnahmegenehmigung.
- Veralterungskalender: Hersteller-End-of-Support-Daten für OS, DB, Middleware, Laufzeiten, ERP-Versionen, IBM i-Releases; alles kennzeichnen, das innerhalb von 24 Monaten endet.
- Finanzierung: explizite Kapazität vorhalten (häufig genannte 15-20 % der Lieferkapazität – organisationsspezifisch); Schulden aus einer Ausnahmegenehmigung eines Projekts werden in diesem Projekt veranschlagt.
- Schulden, die kritische Funktionen betreffen, sind ein ICT-Risiko: melden Sie es im Risikorahmen, nicht nur in IT-Backlogs.
8. DORA ICT-Risiko aus Architektursicht
Verordnung (EU) 2022/2554, anwendbar seit 17. Januar 2025, ergänzt durch RTS/ITS. Die nachstehenden Artikelnummern sind Richtwerte: Bestätigen Sie sie auf EUR-Lex, bevor Sie sie in einem Arbeitsergebnis zitieren.
| DORA-Thema | Architekturbeitrag |
|---|---|
| ICT-Risikomanagementrahmen (Art. 6) | Architekturprinzipien, -standards und Zielarchitektur als dokumentierte Kontrollen |
| Identifizierung (Art. 8) | Bestandsverzeichnis der ICT-Vermögenswerte und Informationsvermögenswerte; Kartierung der Geschäftsprozesse, Anwendungen, Daten und Infrastruktur |
| Schutz & Prävention (Art. 9) | Integrierte Sicherheits- und Datenschutzprinzipien (P2); Sicherheitsarchitektur in der Zielarchitektur |
| Erkennung (Art. 10) | Überwachung und Beobachtbarkeit als nicht-funktionale Anforderungen; Protokollierung und Korrelations-IDs |
| Reaktion & Wiederherstellung (Art. 11) | Notfallwiederherstellungsarchitektur, RTO/RPO, Ausweichstandort, Failover-Tests als Design-Artefakte |
| Lernziele (Art. 13) | Ursachenanalyse von definierten Ausfällen; ADRs und Schuldenregister als Eingaben |
| Kommunikation (Art. 14) | Abhängigkeitskarte für Benachrichtigungen an Gegenparteien und Aufsichtsbehörden |
| Management von ICT-Drittanbieterrisiken (Art. 28-44) | Register vertraglich vereinbarter Dienste und Subunternehmer; Exit-Plan in der Zielarchitektur |
Architekturbeitrag zu DORA-Tests (Art. 25): TLPT (Threat-Led Penetration Testing) erfordert eine aktuelle Architekturübersicht der getesteten kritischen Funktionen, einschließlich aller Abhängigkeiten (intern und extern). Die Design Authority überprüft den Umfang des Tests und stellt sicher, dass die Architekturübersicht die tatsächliche Produktionsumgebung widerspiegelt.
9. Vorschriften zur Informationssicherheit
Warnung: Diese Zusammenfassung ist ein Ausgangspunkt. Die tatsächlichen Klassifizierungs- und Sicherheitsanforderungen variieren je nach Sektor und aktueller Version der offiziellen Texte; überprüfen Sie immer die aktuellste Version.
| Kennung | Geltungsbereich | Typische Architekturauswirkungen |
|---|---|---|
| DSGVO (Verordnung (EU) 2016/679) | Personenbezogene Daten von betroffenen Personen im EWR | Privacy by Design (P2), Datenminimierung, Verarbeitungsverzeichnis, DPIAs, Data Protection Impact Assessment |
| DORA (Verordnung (EU) 2022/2554) | Kritische und wichtige Funktionen des Finanzsektors | Siehe §8 oben; ICT-Risikomanagement, Digital Operational Resilience Testing |
| NIS2 (Richtlinie (EU) 2022/2555) | Wesentliche und wichtige Einrichtungen in kritischen Sektoren | Meldepflichten, Lieferkettensicherheit, Sicherheit der Netzwerk- und Informationssysteme |
| HDS (Frankreich, Code de la santé publique) | Gesundheitsdaten, die von Hosting-Anbietern gehostet werden | HDS-zertifiziertes Hosting; Datenstandortbeschränkungen; Vertragsanforderungen |
| II 901 (Frankreich, ANSSI) | Diffusion Restreinte (DR)-Systeme | Physische und logische Trennung, akkreditierte Umgebungen, spezifische IAM- und Überwachungsanforderungen |
| IGI 1300 (Frankreich, ANSSI) | Einstufung (Secret / Très Secret) | Dedizierte akkreditierte Infrastruktur; von Public Cloud ausgeschlossen; spezifische Anforderungen |
| SREN-Gesetz (Frankreich, 2024) | Staatliche und sensible Daten | SecNumCloud oder gleichwertig für bestimmte Datenklassen; Datenresidenz |
| EU Data Act (Verordnung (EU) 2023/2854) | Cloud-Dienste | Reversibilitätsanforderungen, Anbieterwechsel, Datenportabilität |
- Haftungsausschluss: Dieser Abschnitt enthält Zusammenfassungen; die tatsächliche Einhaltung erfordert eine gründliche rechtliche und regulatorische Analyse.*
10. Checkliste für domänenübergreifende Kohärenz
Vor einer Designentscheidung oder Freigabe:
Ist die Entscheidung …
- Final (abgeschlossen) oder explorativ (erfordert eine zweite Auswahlrunde)? Begründen Sie, warum eine grobe Entscheidung jetzt ausreicht.
- Strukturell (ändert das Architekturmuster, die Kopplung, die Datenverantwortung) oder lokal (innerhalb des gegebenen Rahmens)? Strukturelle Entscheidungen gehen zu G1/G2 und erhalten eine ADR-Nummer.
- Neu oder eine Vorentscheidung, die wiederholt werden muss? Vergleichen Sie mit dem ADR-Index und dem Schuldenregister.
- Reversibel (kann die Entscheidung rückgängig gemacht werden, ohne die Infrastruktur neu zu schreiben?) – wenn nicht, fordern Sie mehr Analyse-/Prototyping-Zeit an, bevor Sie sich festlegen.
- Kostenbedacht (entspricht die Entscheidung den zugewiesenen Kapazitäten, oder erzeugt sie Schulden? Wenn Schulden, wie hoch sind Kapital und Zinsen? Wer hat die Ausnahmegenehmigung unterschrieben?)
- Abhängig aufgelöst (haben alle Domänen zugestimmt? Wenn die Entscheidung eine andere Domäne blockiert, gibt es eine Ausweichlösung? Ist sie im Flow-Matrix verfolgt?)
- Regulatorisch kohärent (arbeitet der Lösungsvorschlag innerhalb der Zulassung, SLA, Datenklasse der beteiligten Systeme? Wenn Ausnahmen, sind sie als ICT-Risiko erfasst?)
- Überwachbar (was ist der erwartete Betriebsmodus, und wie wird ein Fehler erkannt, protokolliert, alarmiert, eskaliert?)
- Dokumentiert (ADR mindestens im Status „Entwurf“, Ausnahmegenehmigung unterschrieben, Flow-Matrix aktualisiert, Schuldeneintrag erstellt?)