EAM für Finance (Enterprise Architecture Management)

1) Executive Summary

Viele Finanzorganisationen sind heute daten‑ und regelgetrieben, aber architektonisch fragmentiert. Unterschiedliche ERP‑Instanzen, BI‑Silos, Excel‑Schattenberichte und unklare Governance lassen IFRS‑Kennzahlen (z. B. Operating Profit nach IFRS 18), Management‑KPIs (MPMs) und wertschaffende Größen (NOPAT, ROIC, WACC, Economic Profit) auseinanderlaufen. Enterprise Architecture Management (EAM) ist der fehlende Orchestrator:

Es verbindet Prozesse, Daten, Anwendungen und Technologie zu einem prüfbaren, skalierbaren, KI‑fähigen Finanzbetriebssystem – und zwar mit klaren Verantwortungen, Data Products, Versionierung und Auditrails. Damit wird aus Compliance ein Performance‑Hebel. [iasplus.com], [assets.kpmg.com]

Kernaussagen:

• IFRS‑18/MPMs machen das „Wie“ der KPI‑Herleitung sichtbar. EAM sorgt dafür, dass Subtotals, Kategorien und MPM‑Notes systemweit konsistent sind – von ERP bis Bericht. [ifrs.org], [assets.kpmg.com]

• Finance‑Wertlogik (NOPAT → ROIC vs. WACC → Economic Profit) braucht einheitliche Definitionen, Data Contracts und Rechenservices – sonst zerfällt die Steuerung. [learn.microsoft.com]

• Data Mesh & Lakehouse verlagern Verantwortung in Domänen und lösen sich von monolithischen Pipelines; Microsoft Fabric (OneLake, Real‑Time Intelligence, IQ/Ontology) bündelt Workloads, Governance und semantische Bedeutung in einem SaaS‑Erlebnis. EAM ist der Rahmen, der entscheidet, wo und wie diese Bausteine zusammenspielen. [docs.databricks.com], [blog.fabri...rosoft.com],

• Purview als Governance‑Schicht ermöglicht Katalog, Lineage, Policies über Multi‑Cloud und M365 – essenziell für KI‑Einsatz und IFRS‑Offenlegung. [learn.microsoft.com], [docs.azure.cn]

• DORA (EU) erhöht Resilienz‑ und Drittparteirisiken‑Anforderungen; EAM stellt die Architektur‑Fähigkeiten bereit (TLPT‑Readiness, Supplier‑Controls, Incident‑Flows). [eiopa.europa.eu]

2) Ausgangslage: Warum EAM gerade jetzt?

2.1 IFRS‑18 & MPMs erzwingen „Rechen‑Transparenz“

Mit IFRS 18 (wirksam für Berichtsperioden ab 1. Jan 2027) werden strukturierte Kategorien, Pflicht‑Subtotals und MPM‑Offenlegung eingeführt. Dadurch wandert viel implizite Managementlogik (z. B. „Adjusted Operating Profit“) aus Folien in auditiert prüfbare Notes. Ohne EAM entstehen „ein Subtotal pro System“. EAM standardisiert Definitionen, ordnet Datenflüsse, dokumentiert Abweichungen und schafft maschinenlesbare Herleitungen über Domänen hinweg. [iasplus.com], [assets.kpmg.com], [aaro.com]

2.2 Wertschöpfung braucht Datenkohärenz

NOPAT/ROIC/WACC/Economic Profit sind nur dann steuerbar, wenn Bereinigungen, operative Steuersätze, Leasings (IFRS 16), Invested‑Capital‑Definitionen und Kapitalkosten kohärent sind. EAM sorgt dafür, dass KPI‑Rechenkerne als wiederverwendbare Services bereitstehen (z. B. „WACC‑Service“, „ROIC‑Service“), versioniert werden und gleich gerechnet werden – in Planung, BI und externem Reporting. [learn.microsoft.com]

2.3 Der Tech‑Shift: Vom Data Lake zum Intelligence‑Betriebssystem

Data Lakehouse (z. B. Delta Lake) vereint ACID‑Transaktionen, Open‑Formate und Streaming – ideal für Finance‑Pipelines. Data Mesh verlagert Verantwortung in Domänen („Data as a Product“). Microsoft Fabric konsolidiert Engineering, Warehouse, RTI und BI in OneLake; mit Fabric IQ/Ontology wird die Bedeutung (Semantik) maschinenlesbar – ein Boost für Agentic AI und Copiloten. EAM definiert, wo Domänen beginnen/enden, welche Daten produktisiert werden und wie Semantik & Governance durchgängig bleiben. [learn.microsoft.com]

3) Begriff & Anspruch: Was EAM im Finance‑Kontext bedeutet

Definition (praxisnah):

EAM ist der strategische Management‑ und Transformationsprozess, der Geschäftsprozesse, Daten, Anwendungen, Technologien und Governance so modelliert, plant und überwacht, dass Regel‑ und Datenlogiken (IFRS, Werttreiber, Risiko, ESG) einheitlich, auditierbar und skalierbar umgesetzt werden – über Organisation, Domänen und Lebenszyklen hinweg. Kurz: Die Landkarte und der Leitstand der Finanz‑IT‑Landschaft.

TOGAF im modernen EAM: Einordnung eines klassischen Frameworks

TOGAF zählt seit vielen Jahren zu den weltweit etablierten Frameworks für den strukturierten Aufbau von Unternehmens‑ und IT‑Architekturen. Es definiert klare Ebenen (Business, Data, Application, Technology), ein methodisches Vorgehensmodell (ADM) sowie wiederverwendbare Artefakte für Architekturplanung und Governance. Im modernen Enterprise Architecture Management (EAM) erfüllt TOGAF jedoch vor allem die Rolle eines stabilen Architekturfundaments, das Ordnung, Begriffe und Struktur schafft. Gerade in regulierten Branchen oder großen Organisationen bietet TOGAF weiterhin wertvolle Orientierung bei der Dokumentation, Harmonisierung und langfristigen Zielarchitekturplanung.

Gleichzeitig wird deutlich: TOGAF ist in seiner ursprünglichen Form nicht ausreichend, um heutige daten- und KI‑getriebene Architekturen vollständig abzudecken. Daher nutzen moderne EAM‑Ansätze TOGAF eher als Basis, die durch datenorientierte, cloudbasierte und domänengetriebene Architekturmodelle ergänzt wird.

Kurz: TOGAF ist nicht veraltet – aber heute nur noch ein Teil eines umfassenderen Architekturverständnisses.

4) Vom Monolithen zur Composable Finance Architecture

Viele Unternehmen stecken in „Monolith‑Plus‑Excel“. Ergebnis: lange Durchlaufzeiten, Intransparenz, kein Re‑Use von Rechenlogiken und erhöhte Fehlerrisiken.

EAM‑Zielbild (vereinfachtes Narrativ):

1. Domänen definieren (z. B. „Revenue & IFRS‑15“, „Leasing & IFRS‑16“, „Capital & WACC“, „ESG‑KPIs“).

2. Je Domäne Data Products (mit Data Contracts) schaffen und Microservices für Kernlogiken bereitstellen (z. B. MPM‑Builder).

3. Lakehouse als Speicher‑/Compute‑Backbone (Delta/Parquet), Fabric als SaaS‑Plattform (OneLake, RTI, Warehouse, BI, IQ/Ontology), Purview für Katalog/Lineage/Policies.

4. CI/CD für Daten & Modelle, Observability & Quality Gates, Versionierung aller Artefakte; Audit‑Trails by design. [docs.databricks.com], [learn.microsoft.com], [blog.fabri...rosoft.com], [learn.microsoft.com]

Warum das funktioniert:

• Lakehouse bringt ACID & Zeitreisen in den Data Lake → reproduzierbare Berichte/Forecasts. [docs.databricks.com], [databricks.com]

• Data Mesh verankert Verantwortung; EAM verhindert, dass daraus Inseln entstehen, indem gemeinsame Semantik und federierte Governance etabliert werden.

• Fabric eliminiert Tool‑Sprawl (ein Speicher, mehrere Workloads) und hebt mit IQ die Bedeutungsschicht an – KPI‑Definitionen werden first‑class. [blog.fabri...rosoft.com]

• Purview liefert Einblick & Policy‑Durchsetzung über Clouds/M365 hinweg – wichtig für MPM‑Begründungen und AI‑Governance. [learn.microsoft.com]

5) Praxisbeispiele

Beispiel A – IFRS‑18‑Umstellung: „Drei Operating Profits sind zwei zu viel“

Ausgangslage:

Ein Industrie‑Konzern weist in ERP, Konsolidierung und BI drei unterschiedliche Operating‑Profit‑Subtotals aus. MPMs (z. B. „Adjusted Operating Profit“) sind nur in Investor‑Präsentationen definiert.

EAM‑Intervention:

• Domänen: „P&L‑Struktur (IFRS‑18)“, „MPMs“, „Leasing (IFRS‑16)“.

• Services: „Operating‑Classifier“ (Kategorisierung in operating/investing/financing), „MPM‑Builder“.

• Daten: Lakehouse‑Tabellen mit Versionierung/Time Travel (Rebuild historischer Comparatives). [assets.kpmg.com], [docs.databricks.com]

• Governance: Purview‑Katalog + Lineage, Data Contracts für Subtotals. [learn.microsoft.com]

Effekt (12 Monate):

• 100 % Kohärenz der Operating‑Subtotals in allen Berichten.

• MPM‑Note befüllt sich automatisch aus dem MPM‑Builder mit Quellen‑Lineage; Audit‑Feststellungen sinken drastisch. [ifrs.org], [aaro.com]

Beispiel B – ROIC vs. WACC: „Wertsteuerung ohne Rechen‑Wildwuchs“

Ausgangslage:

Business Units berichten ROIC mit unterschiedlicher Invested‑Capital‑Definition; Treasury pflegt WACC separat. CAPEX‑Gatekeeping basiert auf „Einzelfall‑Excel“.

EAM‑Intervention:

• WACC‑Service (Kapitalkostenmethodik als Code), ROIC‑Service (IC‑Definition inkl. IFRS‑16‑Leases), Economic‑Profit‑Service (Spread × IC). [learn.microsoft.com]

• CI/CD: Tests mit Regelsets (IFRS‑16 Konsistenz Zähler/Nenner).

• Decision‑API ins CAPEX‑Workflow‑Tool (Gate „Value‑Spread > 0“).

Effekt (2 Planungszyklen):

• Vergleichbarkeit steigt, „Excel‑Schattenrechnungen“ verschwinden.

• CAPEX‑Durchlaufzeit –15 %; ROIC‑Spread als einheitliche Steuerungsgröße. [learn.microsoft.com]

Beispiel C – DORA‑Readiness: „Resilienz statt Checkboxen“

Ausgangslage:

Bank mit starken Cloud‑Abhängigkeiten. Regulator fordert Incident‑Meldefähigkeit, TLPT und Supplier‑Kontrollen.

EAM‑Intervention:

• Domänen: „ICT‑Risiko/Resilienz“, „Incident & Reporting“, „Third‑Party‑Risk“.

• Capabilities: Events in Real‑Time Intelligence, Purview‑Lineage bis zu kritischen Prozessen, Katalog für Verträge/KPIs (RTO/RPO). [blog.fabri...rosoft.com], [learn.microsoft.com]

• Outcome: TLPT‑Vorbereitung, zentrale Resilienz‑Landkarte, Supplier‑Concentration‑Monitoring.

6) Kritische Hinterfragung: Wo EAM scheitert – und wie man es vermeidet

1. Schönwetter‑EAM: Visio‑Bilder ohne Durchgriff auf Delivery. Gegenmittel: Roadmaps mit verbindlichen Architekturschutzräumen (z. B. nur noch genehmigte KPI‑Services in BI).

2. Central‑Overreach: Alles zentralisieren, Domänen entmündigen. Gegenmittel: Föderierte Governance (Policies zentral, Ownership & Budgets dezentral).

3. Tool‑Fixierung: Lakehouse oder Fabric oder Mesh – statt sowohl‑als‑auch unter EAM‑Leitplanken. Gegenmittel: Capability‑First denken (Katalog, Lineage, Semantik, Quality, Re‑Use). [bix-tech.com], [docs.databricks.com]

4. Governance ohne KI: Klassische IKS‑Denke reicht nicht – AI‑IKS (Datenherkunft, Prompt‑Logging, Policy‑Durchsetzung) muss hinein. Gegenmittel: Purview‑Policies & Ontology in Fabric IQ als Pflichtgleis. [learn.microsoft.com], [blog.fabri...rosoft.com]

Warum Data Mesh, Lakehouse und Microsoft Fabric das EAM weiterentwickelt haben

Die Anforderungen an moderne Unternehmensarchitekturen haben sich fundamental geändert – besonders im Finanzbereich, wo Regulatorik (z. B. IFRS 18, DORA, ISO 27001:2022), datengetriebene Wertsteuerung (WACC, ROIC, MPMs) und Echtzeit‑Insights zentrale Rollen spielen. Frameworks wie Data Mesh, Lakehouse‑Architekturen und Plattformen wie Microsoft Fabric mit OneLake, Real‑Time Intelligence und der Fabric‑Ontology (Semantic Model/AI‑Semantik) haben EAM auf ein neues Niveau gehoben.

Moderne EAM‑Methoden verlagern den Fokus:

• von zentralisierten Architektur‑Blueprints → hin zu produktorientierten, domänenbasierten Data‑ und KPI‑Services

• von einmaligen Zielarchitekturen → hin zu laufender Evolution, CI/CD, Lineage und Data Contracts

• von Applikationssicht → hin zu Daten‑, Governance‑ und Semantik‑Centric EAM

• von Dokumentation → hin zu automatisierter, maschinenlesbarer Steuerung (Purview Policies, Fabric IQ/Ontology)

Diese modernen Architekturkonzepte ergänzen klassische EAM‑Frameworks wie TOGAF um entscheidende Fähigkeiten:

Skalierbarkeit, Datenqualität, KI‑Tauglichkeit und regulatorisch prüfbare Transparenz.

Damit entsteht ein EAM, das nicht nur ordnet, sondern aktiv Wert schafft – durch klare Domänen, vertrauenswürdige KPIs, beschleunigte Finance‑Prozesse und intelligente, nachvollziehbare KI‑Anwendungen.

7) Technologien & Muster: Was heute reif ist – und was als Nächstes kommt

7.1 Data Lakehouse (Delta) – „Ein Speicher, mehrere Engines“

Warum relevant: ACID, Schema‑Einhaltung, Time Travel → Revisionssichere Finance‑Pipelines, reproduzierbare Reports.

7.2 Data Mesh – „Data as a Product“ mit föderierter Governance

Warum relevant: Skaliert Verantwortung; EAM definiert Bounded Contexts, gemeinsame Normen und Schnittstellenverträge.

7.3 Microsoft Fabric – „Vom unify‑Data‑ zum Intelligence‑Platform“

OneLake als zentraler Speicher, Workloads (Engineering, Warehouse, RTI, BI) in einem SaaS; Fabric IQ/Ontology macht Semantik maschinenlesbar (entscheidend für KI‑Agenten).

7.4 Microsoft Purview – „Governance, die von selbst mitläuft“

Unified Catalog, Data Map, Lineage, Policies über Multi‑Cloud & M365; „Federated Governance“ als „Mesh‑fähige“ Kontrollarchitektur.

7.5 ISO 27001:2022 – „Controls modernisieren, KI & Cloud im Griff“

Annex A restrukturiert (93 Controls, 11 neu: z. B. Threat Intelligence, Cloud‑Use). EAM stellt sicher, dass Security‑Patterns und Architekturen mitziehen.

7.6 DORA (ab 17. Jan 2025) – „Resilienz als Designprinzip“

Fünf Säulen (ICT‑Risiko, Tests inkl. TLPT, Incident‑Reporting, Third‑Party‑Risk, Info‑Sharing). EAM mappt Anforderungen auf Domänen & Services, Lineage und KPIs (RTO/RPO/TTR).

8) Architektur‑Musterdialog: Mesh und Fabric und Lakehouse?

Kurzantwort: Ja – unter EAM‑Leitplanken.

• Lakehouse liefert Transaktionssicherheit & offene Formate. [docs.databricks.com]

• Mesh sorgt für Domänen‑Ownership und Data‑as‑a‑Product.

• Fabric integriert Workloads und hebt mit IQ die Geschäftssemantik an. [blog.fabri...rosoft.com]

• Purview schließt Governance‑Lücken über Plattformen hinweg. [learn.microsoft.com]

EAM definiert die Spielregeln (z. B. „jedes KPI muss als Semantic‑Model veröffentlicht werden“, „keine BI‑Kennzahl ohne Lineage & MPM‑Note“) und schützt so vor Wildwuchs.

9) ACCA, CIMA & HF – Prüfungskontext, der wirklich zählt

• ACCA SBR: IFRS 18‑Kategorien, Operating‑Subtotal, MPM‑Note – EAM ermöglicht konsistente Datenpfade für Prüfungsfälle und Praxis. [accaglobal.com]

• ACCA FM/AFM: Wertlogik (ROIC, WACC, DCF) → EAM stellt Rechenkerne als Services bereit. [learn.microsoft.com]

• CIMA P3/E3/F3: Governance, Risiko, Strategie & Finanzarchitektur – EAM als Brücke zwischen Risiko‑Frameworks (COSO ERM) und strategischer Execution. [aicpa-cima.com], [acowtancy.com]

• COSO ERM 2017: „Integrating with Strategy & Performance“ – EAM ist die technisch‑organisatorische Umsetzungsebene. [coso.org], [alacommunity.org]

10) Roadmap: 180 Tage zur „auditierbaren Wertlogik“

Phase 0 (2–3 Wochen):

• Kartenaufnahme: Prozess‑/System‑/KPI‑Inventar (IFRS‑18‑relevant), Risiken, Shadow‑Pipelines.

• „Zwei Wahrheiten“ identifizieren: Wo unterscheiden sich Zahlen (Operating Profit, ROIC, Net Debt)?

Phase 1 (8–10 Wochen):

• EAM‑Leitplanken (Domänen, Data Product‑Standards, Namensräume, Versionsschema).

• Zwillings‑KPI auswählen (z. B. Operating Profit, ROIC) → Referenz‑Service bauen.

Phase 2 (8–10 Wochen):

• Fabric‑Arbeitsräume & OneLake‑Zonen (raw/refined/curated), Purview‑Katalog/Lineage, Quality Gates. [bix-tech.com], [learn.microsoft.com]

• MPM‑Builder implementieren (IFRS 18: MPM‑Note generiert sich inkl. Reconciliation). [assets.kpmg.com]

Phase 3 (8–10 Wochen):

• WACC/ROIC/Economic‑Profit als Services, CAPEX‑Gatekeeping via API.

• DORA‑Quick‑Wins (Incident‑Flows, Third‑Party‑Register, TLPT‑Pfad) in die Landkarte integrieren. [eiopa.europa.eu]

Deliverables: EAM‑Zielbild, Domänenkatalog, Data Contracts, KPI‑Services (v1), Purview‑Katalog + Lineage, IFRS‑18‑MPM‑Note‑Generator, DORA‑Heatmap.

11) Zukunft: Von „Zahlen“ zu Bedeutung – Ontology, Agentic AI, Digital‑Twin‑Finance

• Fabric IQ/Ontology: Geschäftskonzepte (Kunde, Auftrag, Lieferung, Operating Profit) formalisiert und maschinenlesbar → KI‑Agenten können prüfbar rechnen & erklären.

• Digital‑Twin‑Finance: Simulierte P&L/CF/BS‑Welten mit Real‑Time Intelligence; Maßnahmen wirken in Sandboxen auf Spread, CCC, Covenants. [blog.fabri...rosoft.com]

• AI‑IKS: Policies & Protokolle (Prompt‑Logging, Zugriffspfad‑Kontrolle) in Purview verankern – „Kein KI‑Output ohne Lineage“. [learn.microsoft.com]