Wie man das
wirklich baut.

§ F.0 · VorbemerkungWas dieses Annex ist

Eine Referenzarchitektur ist kein Bauplan. Sie ist ein Entscheidungsraster: Welche Klasse von Komponenten gehört an welche Stelle? Welche Standards sind einzuhalten? Welche Wahl ist begründet, welche ist zufällig?

Dieses Annex beantwortet genau diese Fragen für das Digitale Amt Österreich. Es ist so geschrieben, dass es ein:e Architekt:in am Montagmorgen aufschlägt und am Freitag ein erstes Aufriss­papier für das Ministerium liefern kann. Keine Folienshow. Kein Marketing. Konkrete Namen, begründete Entscheidungen.

Die Architektur ist kein Neubau auf der grünen Wiese. Österreich hat Bausteine: ID Austria (eIDAS-1.0-konform, jetzt 2.0-ready), das ZMR, das ZPR, das URV, die FinanzOnline-Infrastruktur, Portale der Länder, AMA- und BRZ-Systeme. Das bleibt. Die Referenz beschreibt, wie diese Systeme über eine gemeinsame Plattform verknüpft, auditiert und dem Bürger einheitlich präsentiert werden.

Eine Referenzarchitektur muss überprüfbar sein. Jede Wahl trägt eine Begründung, eine Referenzimplementierung in einem anderen Land oder Projekt und einen Ausweg (was tun wir, wenn diese Komponente schlecht altert?). Keine Entscheidung ist alternativlos — aber jede ist expliziert.

§ F.1 · PrinzipienWas die Architektur einhält — und warum

Acht Architekturprinzipien, jedes abgeleitet aus den Axiomen in Annex B. Sie sind nicht beliebig, sondern zwingend. Wer eines davon aufgibt, muss das benannte Axiom aufgeben.

§ F.2 · Der StackNeun Schichten

Jede Schicht hat eine klare Verantwortung, eine referenzielle Komponenten­wahl und ein Interface zu den Nachbar­schichten. Unten physisch, oben menschlich.

Die Schichten sind lose gekoppelt. Eine Änderung auf L4 (neue Rules-as-Code-Version) erfordert keine Änderung auf L7. Ein Austausch auf L0 (anderer Hosting-Provider) lässt L4 unverändert. Das ist das Muster der „hexagonalen" Architektur, angewandt auf Staatlichkeit.

§ F.3 · QuerschnitteWas durch alle Schichten geht

Nicht alles lässt sich einer Schicht zuordnen. Drei Querschnitts-Funktionen durchdringen das Gesamt­system.

Security — Defense in Depth

Sicherheit ist kein Feature, sondern eine Haltung. Auf jeder Ebene wird sie verankert:

Observability — drei Säulen

Metriken, Logs, Traces: alles in einem einheitlichen Stack über OpenTelemetry. Kein Silo, keine proprietären Agenten.

Crypto-Agility — Post-Quanten-ready

Die NIST hat 2024 die ersten Post-Quanten-Standards finalisiert: ML-KEM (Kyber), ML-DSA (Dilithium), SLH-DSA (SPHINCS+). Das ist keine Zukunftsmusik, sondern 2026 angewandt. Die Architektur nutzt Hybrid-Signaturen, Austauschbarkeit, und vermeidet Abhängigkeit von einzelnen Primitiven.

// Hybrid-Signatur — klassisch + post-quanten
// für kritische Audit-Log-Einträge ab 2027

signature = {
  classical:   Ed25519(message, private_key_classical),
  postquantum: ML-DSA-65(message, private_key_pqc),
  algo_ids:    ["ed25519", "mldsa65"],
  version:     "2027.1"    // austauschbar
}

// Verifikation: BEIDE müssen gültig sein
verify = classical_ok AND pqc_ok

Die Hybrid-Konstruktion schützt doppelt: Fällt eine Primitive (klassisch durch Quantum, PQC durch kryptoanalytischen Bruch), bleibt die andere intakt. Erst wenn beide gebrochen sind, kippt die Signatur.

§ F.4 · Komponenten­wahlDas Warum hinter jeder Zeile

Die wichtigsten Komponenten der Architektur — mit Referenz­implementierung, Lizenz, Produktiv­erfahrung. Jede Wahl trägt eine Begründung, die überprüfbar ist.

Rules as Code — Catala

Warum Catala und nicht DMN für alles? DMN ist gut für Entscheidungs­tabellen, aber kommt mit der default-logic (Regel + Ausnahme + Sonderfall­ausnahme) von Gesetzes­texten nicht zurecht. Catala wurde explizit für diese Struktur entworfen. Der Code ist gleichzeitig lesbar für Jurist:innen (Literate Programming à la Knuth) und ausführbar.

Verworfen wurde ein Eigenbau einer Regel-Sprache. Wer das vorschlägt, hat nicht gesehen, wie viele AMTS-Projekte daran gescheitert sind. Catala ist peer-reviewed, ICFP-publiziert und gewinnt an institutioneller Rücken­deckung — wir beteiligen uns an Upstream-Development, statt zu fork-en.

Daten­austausch — X-Road

Österreich braucht genau das: einen standardisierten Austausch­layer zwischen den Hunderten existierender Behörden-Informations­systeme. Jede Behörde bekommt einen „Security Server", der Anfragen signiert, protokolliert, authentifiziert. Trust-Anchor ist die zentrale Aufsichts­stelle. Daten bleiben dezentral (jede Behörde besitzt weiter ihre eigenen), aber sie werden über X-Road gemeinsam nutzbar.

Bonus: EU-Förderation ist vorgesehen. Österreich kann sein X-Road mit Deutschland, Finnland oder Estland föderieren — EU-Interoperabilität ohne Brüsseler Zentralisierung.

Identität & Wallet — ID Austria + EUDI

Über Wallet: Verifiable Credentials (W3C VC 2.0) und Decentralized Identifiers (DID) sind die Bausteine. Für Zero-Knowledge-Proofs: BBS+ für Selective Disclosure, Groth16 oder Plonk für Range Proofs. Die EUDI-Referenz­architektur der EU spezifiziert das im Detail — Österreich übernimmt und trägt bei.

Kritisch: Zertifizierung der Wallet-Implementierungen. Die Plattform akzeptiert nur Wallets, die vom Bundes­amt für Sicherheit (oder EU-benannter Stelle) zertifiziert sind. Keine „Einbinde deine Google-Wallet-App mit AGB-Trick"-Konstruktion.

Workflow — Camunda 8 oder Temporal

Für die Verfahrens­engine zwei ernsthafte Optionen:

Die Empfehlung: beides ist zulässig. Die Plattform selbst kann beides orchestrieren. Einzelne Ressorts wählen, was für ihre Kultur und ihren Team­stack passt. Was nicht geht: proprietäre BPM-Suiten mit Vendor-Lock-in (Pega, IBM BPM, Oracle BPM).

Register-Backend — PostgreSQL (+ Apache AGE)

PostgreSQL ist die wahrscheinlich zuverlässigste Open-Source-Datenbank der Welt. Version 16 ist produktiv, Version 17 im Stable-Release. Das BSI, die EU-Kommission und viele Staaten weltweit setzen PostgreSQL in kritischer Infrastruktur ein.

Für Graph-Beziehungen (Personen ↔ Familie ↔ Firma ↔ Adresse ↔ …) nutzen wir Apache AGE — eine PostgreSQL-Extension, die Graph­abfragen in Cypher-Syntax auf dem gleichen Storage ermöglicht. Das vermeidet den Betrieb eines separaten Graph-DB-Clusters.

Verworfen: Oracle (Lizenz-Kosten, Lock-in), Microsoft SQL Server (CLOUD Act via Microsoft Corp.), MongoDB (SSPL-Lizenz-Probleme, schwach für relationale Integrität).

Audit-Log — Merkle-Chain + Shamir-Shared Keys

Ein unveränderlicher Audit-Log ist die zentrale Sicherung gegen Insider-Sabotage (Annex D A4). Die Konstruktion ist bewährte Kryptographie, nicht neue Erfindung:

// Jeder Audit-Eintrag wird Teil eines Merkle-Baums
// Die Wurzel wird periodisch signiert und extern gespeichert

entry = {
  timestamp:  "2026-05-14T10:23:17Z",
  actor_role: "sachbearbeitung.sozialamt.wien.40",
  action:     "query",
  subject:    pseudonym_hash("citizen_id"),
  purpose:    "Sozialhilfe-Verlängerungsprüfung",
  legal:      "Wiener SHG § 12 Abs. 2",
  hash:       sha3_256(previous_hash + entry_content)
}

// Alle 10 Minuten: Root-Hash signieren, verteilt
merkle_root = compute_root(all_entries_since_last_root)
signature   = shamir_combine(
  rechnungshof_share,
  dsb_share,
  volksanwaltschaft_share,
  parlament_share,
  threshold=3   // 3 von 4 müssen signieren
)

Zu den Shamir-Shares: Das Geheimnis (Signatur-Schlüssel) wird in vier Teile geteilt, drei davon sind notwendig, um zu signieren. Kein einzelner Akteur — auch kein böswilliger Insider in einer Institution — kann das Log manipulieren. Erst Kollusion von drei institutionell getrennten Stellen würde es ermöglichen, was eine sehr hohe Hürde ist.

§ F.5 · LiefermodellWie entwickelt wird, wie betrieben

Entwicklung

Zentraler Plattform-Code in einem Mono-Repo, Ressort-spezifische Fach­anwendungen in Poly-Repos. Grund: Die Plattform muss in sich konsistent sein (Mono), Ressorts müssen autonom entwickeln können (Poly).

Open-Source-Politik

Die Prinzipien sind „Public Money, Public Code" konform:

1. Reziproke Lizenzen. Eigen­entwicklungen werden unter EUPL v1.2 (für Back-End, EU-kompatibel) oder AGPLv3 (für Anwendungen mit Netzwerk-Nutzung) veröffentlicht.
2. Upstream-Kontribution. Verbesserungen an X-Road, Catala, OpenFisca, Keycloak u.a. fließen zurück in die Upstream-Projekte — keine „Government Forks" ohne Wartung.
3. Dokumentation als Artefakt. Code ist ohne Docs unvollständig. Dokumentation lebt im gleichen Repo wie der Code, wird mit-reviewed, mit-released.
4. Öffentliches Repository. Der Plattform-Code ist öffentlich zugänglich auf code.gv.at (Staats-Forge). Einsicht durch Bürger, Presse, Forschung.

Audit & Compliance

Zertifizierung ist Teil der Entwicklung, nicht nachgeschalteter Haken:

• ISO/IEC 27001 (Informations­sicherheit) + 27701 (Datenschutz­management) — zertifiziert
• BSI C5 (deutsche Cloud-Anforderungen) als Qualitäts­baseline, auch für nicht-Cloud-Komponenten
• ÖNORM A 7700 (AT-spezifische Anforderungen)
• EU-AI-Act Konformität für alle Systeme mit Score-Charakter
• DSGVO Art. 35 DSFA (Datenschutz-Folgenabschätzung) für jede neue Verarbeitung — öffentlich
• Jährlicher Sicherheits-Audit durch unabhängige Prüfstelle
• Laufender Red-Team-Betrieb (Annex D § D.6)

§ F.6 · VerworfenesWas nicht verwendet wird — und warum

Die stärkste Architektur­entscheidung ist oft das Nein. Wir benennen acht Technologien oder Muster, die naheliegend klingen, aber ausgeschlossen sind.

§ F.7 · MigrationVom Status Quo zur Referenz

Niemand baut das in einem Guss. Die Migration folgt dem Phasen­plan aus Annex E § E.6, aber übersetzt in technische Schritte. Das Ziel ist nicht „alles neu", sondern: bestehende Systeme schrittweise anbinden, ersetzen, entlasten.

Die Reihenfolge ist nicht zufällig: Wir starten mit niedrig-Risiko / hoch-Nutzen (Zone Grün), lernen, korrigieren, und arbeiten uns in die riskanten Zonen nur vor, wenn das Fundament trägt. Ein Digitalisierungs­skandal in Phase 2 ist verkraftbar; ein Toeslagen-Äquivalent in Phase 5 würde das gesamte Projekt zurückwerfen. Genau deshalb kommt Zone Rot zuletzt.

§ F.8 · GrenzenWas diese Referenz nicht ist

Ehrlichkeit am Schluss. Diese Referenzarchitektur hat vier benannte Grenzen.

Grenze 1 — Sie ist keine Implementierungs­vorgabe

Eine Referenz­architektur ist ein Entscheidungs­raster, keine Blaupause. Die konkrete Umsetzung pro Ressort erfordert eigene Architektur­arbeit, eigene Fach­analyse, eigene Tool­wahl innerhalb der hier definierten Klassen. Wer aus diesem Dokument eine Stück­liste lesen will, hat es missverstanden.

Grenze 2 — Technologie altert

Was heute state of the art ist, kann in fünf Jahren suboptimal sein. Die Architektur ist darauf ausgelegt (Crypto-Agility, Interop über offene Standards, modulare Austauschbarkeit) — aber das gilt nur, wenn die Revision tatsächlich passiert. Ein jährliches Architektur-Review durch die Aufsichts­stelle ist vorgesehen.

Grenze 3 — Die Wahl von Referenz­implementierungen kann falsch sein

Catala könnte sich nicht durchsetzen. X-Road könnte durch etwas Besseres abgelöst werden. EUDI-Wallet könnte gegen die Wand fahren (unwahrscheinlich, aber möglich). Für jede Komponente gibt es einen benannten Plan-B: ein alternatives Produkt oder eine andere Protokoll-Familie. Keine Komponente ist alternativlos.

Grenze 4 — Architektur allein garantiert nichts

Eine gute Architektur in den falschen Händen wird schlecht. Das wichtigste ist nicht der Tech-Stack, sondern: gute Teams, ehrliche Audits, ausreichendes Budget, politischer Rückhalt. Die Architektur ist die notwendige Bedingung, nicht die hinreichende. Ohne sie geht es nicht. Mit ihr allein auch nicht.

Diese Architektur ist nicht visionär — sie ist solide. Sie verwendet Bausteine, die sich woanders bewährt haben. Ein Staat, der das kopiert, begeht keinen Fehler. Er holt nach, was andere vor zehn Jahren gemacht haben.