Föderierte ML- & KI-Architektur
Stand 2026-09-03
Föderiertes ML/KI führt maschinelles Lernen dort aus, wo es relativ zu den Daten sinnvoll ist — Compute zu den Daten bewegen (oder live teilen), statt reflexartig alles an einen Ort zu kopieren. In der BDC-Ära (Zero-Copy-Sharing, M041; SAP↔Databricks, M034) ist Föderation oft die bessere Architektur. Kernfrage pro Anwendungsfall: Daten bewegen oder Compute bewegen? Föderation ist der Standard; kopiert wird nur aus konkreten Gründen (Feature-Wiederverwendung, Stichtags-Snapshots). Datenresidenz (DSGVO M082, Utilities/Banking M099/M097) macht Föderation zur Pflicht — für ML zu zentralisieren ist nicht compliant; trainieren/bewerten, wo die Daten rechtmäßig liegen, nur Modelle/Aggregate bewegen. Schichten: gesteuerte Produkte (M033) als Feature-Quelle → Feature Store → Training in Databricks → Inferenz zurück in SAP eingebettet. Governance muss über die Nahtstelle hinweg gelten (M077/M081/M034). Den Rückweg einbetten (Ergebnisse erreichen Entscheidungen), ML nicht im Labor stranden lassen. Ehrlicher Vorbehalt: Föderation erhöht die Entwurfskomplexität — die Trade-offs benennen. Cross-Stack-Architekten-Grenzkompetenz.
Was Sie lernen
- Die Kernkonzepte hinter föderierter ML- & KI-Architektur verstehen
- ML in einem typischen SAP-Analytics-Engagement anwenden
- Die 3-5 häufigsten Fehler erkennen und wissen, wie man sie vermeidet
- Diese Fähigkeit in Ihrer persönlichen Marke und im Tagessatzgespräch positionieren
Modulüberblick
Föderierte ML- und KI-Architektur ist die Disziplin, maschinelles Lernen dort auszuführen, wo es relativ zu den Daten sinnvoll ist — Compute zu den Daten zu bringen, oder Daten live zu teilen, statt reflexartig alles zuerst an einen Ort zu kopieren. In der BDC-Ära, mit SAP-Geschäftsdaten und Databricks-ML Seite an Seite unter Zero-Copy-Sharing, ist Föderation kein Kompromiss mehr — sie ist oft die bessere Architektur.
Die Kernfrage: die Daten bewegen oder die Compute bewegen? Das legacy ML-Muster extrahiert SAP-Daten in eine separate ML-Plattform — eine Kopie, mit all der Duplikation, dem Drift, der Latenz und dem Governance-Verlust, den das mit sich bringt. Das föderierte Muster nutzt Zero-Copy-Sharing (Begleitmodul M041, Delta Sharing), sodass ML gegen SAP-Daten an Ort und Stelle läuft, mit erhaltener Semantik (Begleitmodul M034). Die erfahrene Architekturentscheidung pro Anwendungsfall lautet: Braucht dies tatsächlich einen materialisierten Feature-Satz, oder kann das Modell live gegen geteilte Daten trainieren/bewerten? Standardmäßig Föderation; nur kopieren, wenn ein konkreter Grund besteht (Feature-Wiederverwendung, Stichtags-Snapshots).
Voraussetzungen
- Fortgeschrittene praktische Erfahrung mit SAP-Analytics-Projekten
- Zuerst die Kernkonzepte durchgehen: C008, C006, C004
Lernergebnisse
- Ein realistisches Szenario durcharbeiten: Ein Konzern mit EU- und Nicht-EU-Einheiten möchte Abwanderungs- und Nachfrage-ML, aber Kundendaten in mehreren Ländern dürfen ihre Region nicht verlassen; der Altplan lautete 'alles in einen ML-See kopieren'.
- Das Anti-Muster erkennen und vermeiden: Reflexartig 'alles in einen ML-See kopieren' — Duplikation, Drift, Latenz, Governance-Verlust — und stößt auf Residenz-Mauern.
- Die Kernentscheidung des Moduls anwenden: Daten oder Compute bewegen — standardmäßig föderieren (live, Zero-Copy M041), nicht reflexartig alle Daten in einen ML-See kopieren.
- Die Beherrschung mit der KPI verfolgen: Föderations-Übernahme (Ziel: Live/föderiert als Standard, Kopieren nur mit Grund; Warnsignal: Reflexartiges Alles-in-einen-See-Kopieren).
Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Codeblöcke · die Wissenskontrolle · die Schemata.