Zentrale Datenplattform SAP/Power BI/Qlik

💡 Begründung: Die Plattform erfüllt alle Kriterien der Höchstnote: offene, vollständig dokumentierte REST-APIs (Fabric REST API), XMLA für BI-Tools, OData für Semantic Models, Out-of-the-box-Konnektoren (200+) in Data Factory, native Azure API Management-Integration sowie EDI/EAI-Unterstützung via Logic Apps und Service Bus. Sämtliche Frontend-Funktionalitäten (Reports, Datasets, Workspaces) sind per API steuerbar.

💡 Begründung: Die Plattform bietet solide Betriebsdiagnostik über Fabric Capacity Metrics, Azure Monitor, Log Analytics und den Monitoring Hub für Pipelines – damit ist operatives Interface-Monitoring gut abgedeckt. Ein vollständig integriertes, natives Interface-Monitoring-Dashboard speziell für Schnittstellenverfügbarkeit/-performance existiert nicht out-of-the-box, sondern erfordert teilweise Konfiguration über Azure Monitor, was Score 5 verhindert.

💡 Begründung: Die Lösung bietet starke, flexible RBAC-Mechanismen mit RLS/CLS auf Datenebene und Workspace-Isolation, jedoch sind Rollen auf Repository-/Workspace-Ebene vordefiniert ohne vollständige path-level Policy-Kontrolle im Sinne von ABAC. Score 4 ist angemessen: Flexible RBAC mit granularer Datenzugriffssteuerung, aber keine vollständige Policy-Engine auf Pfad-Ebene.

💡 Begründung: Microsoft Entra ID bietet vollständiges SCIM 2.0-basiertes Provisioning und De-Provisioning von Benutzern und Gruppen in Echtzeit. Dies entspricht exakt der Beschreibung von Score 5: Complete, event-driven automation via SCIM.

💡 Begründung: Als Microsoft-eigenes Produkt ist die Entra ID SSO-Integration nativ und self-service konfigurierbar für sowohl OIDC als auch SAML. Kunden verwalten den gesamten SSO-Lifecycle eigenständig im Azure Portal ohne Vendor-Intervention – entspricht Score 5.

💡 Begründung: Fabric bietet starke Permission-basierte Datentrennung via Workspaces, jedoch ist die User-Verwaltung global über Entra ID. Eine vollständige Top-Level-Isolation wie dedizierte Organisationen mit eigenem User-Namespace ist nicht gegeben. Score 4 ist passend: Granular Permission-Based Separation mit globalem User-Management.

💡 Begründung: Als SaaS-Dienst abstrahiert Fabric die gesamte Datenbankinfrastruktur. Kunden können weder eine externe noch eine alternative Datenbank konfigurieren. Die Datenspeicherung erfolgt in Microsofts verwalteten Systemen. Dies entspricht eher Score 2 (Embedded DB Only / keine Konfigurationsmöglichkeit), da keine externe DB-Wahl möglich ist.

💡 Begründung: Native Azure Blob/ADLS-Integration ist hervorragend, S3 und GCS werden über OneLake Shortcuts eingebunden (nicht vollständig nativ gleichwertig). Score 4 ist angemessen: S3-Compatible Gateway/Shortcut-Support vorhanden, primär aber Azure-zentriert ohne vollständig gleichwertige native Multi-Cloud-Integration.

💡 Begründung: Fabric ermöglicht grundlegende Cleanup-Aufgaben über Azure Storage Lifecycle Policies und Delta Vacuum, jedoch fehlt eine vollständige integrierte Policy-Engine für automatisches Archivieren/Löschen von BI-Artefakten. Dies entspricht Score 3: Basic Scheduled Cleanup ohne vollständigen Policy-Engine-Umfang.

💡 Begründung: Fabric ist nahezu ausschließlich als Azure-SaaS konzipiert. Power BI Report Server deckt nur einen kleinen Teil der Funktionalität ab. Kein echtes On-Premise-Deployment des vollen Fabric-Stacks, kein Kubernetes/Container-Deployment, keine Unterstützung für AWS/GCP als Hosting-Plattform. Score 2 ist passend: On-Premise ist nur sehr eingeschränkt möglich, kein PaaS-Deployment auf alternativen Plattformen.

💡 Begründung: Als vollständig verwalteter SaaS-Dienst entfallen Hardware-Anforderungen auf Kundenseite vollständig. Kein Footprint auf eigener Infrastruktur erforderlich. Score 5 (sehr geringer Footprint) ist korrekt für einen reinen SaaS-Ansatz.

💡 Begründung: Die Aktivierung eines Fabric-Tenants erfordert nur wenige Klicks im Admin Center ohne manuelle Installationsschritte. Vollständige Automatisierung über APIs und PowerShell ist möglich. Entspricht Score 5: Fully Automated via Wizard ohne komplexe manuelle Schritte.

💡 Begründung: Fabric bietet Azure-native Georedundanz und Multi-Region-Deployments innerhalb von Azure, aber kein klassisches Multi-Location-Federation-Modell mit lokalen Caches für Remote-Standorte außerhalb von Azure. Das Modell ist eher Proxy/Centralized. Score 3 ist angemessen.

💡 Begründung: Die Architektur mit DirectLake, autoskalierendem Spark und Azure-Infrastruktur liefert starke Performance für die meisten Enterprise-Szenarien. Gelegentliches Kapazitäts-Tuning (F-SKU-Sizing) kann bei Spitzenlast nötig sein. Score 4 ist angemessen: Good performance profile for most enterprise scenarios with minor tuning needs.

💡 Begründung: Das kapazitätsbasierte Modell ermöglicht skalierbares Hochfahren, und Power BI Premium bietet robustes Queuing. Allerdings können bei extremen Parallellasten manuelle Tuning-Maßnahmen notwendig sein, was einen Score von 5 verhindert. Score 4 entspricht 'Good concurrency support with practical scaling options for most enterprise loads'.

💡 Begründung: Es gibt grundlegende Mitigation durch Azure-Regionen und Power BI Import-Mode-Caching, aber keine explizit dokumentierten Edge-Proxy- oder Replikationsstrategien für Remote-Standorte. Dies entspricht Score 3: 'Basic mitigation options with moderate effectiveness'.

💡 Begründung: Die meisten operativen Konfigurationen (Rollen, Policies, Retention, Kapazitäten) sind über UI/Admin-Portal zugänglich. Einige fortgeschrittene Szenarien (z.B. komplexe Purview-Policies, automatisierte Deployment-Workflows) erfordern noch Scripting. Score 4 entspricht 'Strong no-code customization for most operational needs'.

💡 Begründung: Starke API-Unterstützung, dokumentierte Erweiterungspunkte und klare Deployment-Guidance sind vorhanden. Native Plugin-Mechanismen für tiefgreifende Produktverhaltensänderungen sind jedoch begrenzt, daher Score 4 statt 5: 'Strong API and scripting/extensibility support with minor limits in extension model'.

💡 Begründung: Entra ID B2B-Kollaboration ist ausgereift und gut dokumentiert. Governance über Purview und Workspace-RBAC ist solide. Kleinere operative Komplexitäten bei der Einrichtung von Gastbenutzern in großen Tenant-Umgebungen verhindern Score 5. Score 4: 'Strong enterprise RBAC and external identity integration; offshore collaboration is well-supported operationally'.

💡 Begründung: Die Plattform bietet API-basierte Integration und Event-Hooks via Power Automate, aber kein natives Plugin/Extension-Framework für echte Side-by-Side-Erweiterungen im Produkt-Core. Dies entspricht Score 3: 'Mostly API-based integration and automation, but limited native extension points for deep behavior changes'.

💡 Begründung: Zentralisierte Controls über Admin Portal und Purview sind stark; API-Automatisierung für konsistentes Management über Teams hinweg ist gut unterstützt. Bei sehr komplexen Multi-Workspace-Szenarien kann die Konsistenz manuellen Aufwand erfordern. Score 4: 'Strong centralized controls with good maintainability'.

💡 Begründung: Als proprietäre Microsoft-Plattform gibt es keine Möglichkeit für Kunden, den Produktcode einzusehen oder zu modifizieren. Score 1: 'No source code availability for customer review/change'. Delta/Parquet sind open, aber das Produkt selbst ist geschlossen.

💡 Begründung: Als SaaS-Dienst übernimmt Microsoft Updates automatisch mit transparenter Kommunikation via Release Notes und Message Center. Kunden müssen jedoch bei Feature-Updates Regressionstests für Reports und Semantic Models einplanen. Score 4: 'Good regular release model and update guidance; moderate regression effort expected'.

💡 Begründung: Starke HA durch Azure-Infrastruktur und geo-redundante Speicherung. Allerdings sind einige Recovery-Szenarien (z.B. versehentliches Löschen von Semantic Models) noch eingeschränkt, und dedizierte Backup/Restore für alle Fabric-Artefakte ist nicht vollständig ausgebaut. Score 4: 'Strong recovery mechanisms and practical HA options'.

💡 Begründung: Als SaaS-Plattform sind Zero-Downtime-Updates der Standard-Betriebsmodus. Kunden haben keine Kontrolle über Updates, profitieren aber von nahtlosem Rolling-Update-Modell ohne Downtime. Score 5: 'No or near-zero downtime upgrades are standard in supported production patterns'.

💡 Begründung: Microsoft publiziert klare SLAs für Azure/Fabric-Dienste (typisch 99,9%). Dies ist ein starkes, dokumentiertes Commitment, allerdings nicht auf dem Niveau von 99,99%+ High-Availability-Garantien mancher Spezialanbieter. Score 4: 'Good published availability commitment for managed offering(s)'.

💡 Begründung: Die Plattform deckt ein sehr breites Spektrum ab, was die Einfachheit naturgemäß einschränkt. Für reine Power-BI-Konsumenten ist die UX gut, für Fabric-Gesamtworkflows (Lakehouse, Spark, KQL) ist Training erforderlich – das entspricht Skala 3: 'some training/documentation needed for daily tasks'.

💡 Begründung: Die Oberfläche ist grundsätzlich einheitlich im Fabric-Portal, aber die unterschiedlichen historischen Ursprünge der Workloads (Synapse, Power BI, Azure Data Factory) sind noch spürbar. Anpassungsoptionen sind moderat – Skala 3 ist angemessen.

💡 Begründung: Für die meisten wichtigen Workflows (Pipeline-Setup, Report-Erstellung, Workspace-Konfiguration) gibt es Assistenten und kontextuelle Hilfe. Copilot ergänzt dies durch KI-gestützte Guidance. Das entspricht Skala 4: 'Good guidance for most important workflows'.

💡 Begründung: Admin-Aufgaben (Kapazitätsverwaltung, Governance) sind in separate Portale (Admin Portal, Purview) ausgelagert. Für Developer-Workflows ist der Fit gut, für Business-Endnutzer und Admins gibt es erkennbare Lücken – Skala 3: 'Adequate fit with some friction in common tasks'.

💡 Begründung: Keyboard-Shortcuts sind in Power BI (Desktop) gut implementiert, im Fabric-Webportal aber weniger ausgeprägt. Such- und Filterfunktionen über große Workspaces sind vorhanden, aber nicht herausragend. Skala 3: 'Basic productivity functions available' ist zutreffend.

💡 Begründung: Report-Lesezeichen und persönliche Ansichten sind eine Stärke, aber tiefgreifende Benutzer- oder Gruppenanpassungen der Plattform-UX sind nicht vorgesehen. Das entspricht Skala 3: 'Moderate personalization options'.

💡 Begründung: Power BI und Fabric sind in über 40 Sprachen lokalisiert, Gebietsschema-Einstellungen für Datums-/Uhrzeitformate sind auf Nutzerebene konfigurierbar. Für internationale Teams gut geeignet, kleinere Lücken in neueren Workload-Bereichen möglich – Skala 4 ist angemessen.

💡 Begründung: Microsoft hat als großer Enterprise-Anbieter eine starke Verpflichtung zu Accessibility und veröffentlicht Accessibility Conformance Reports. Kleinere Lücken in neueren oder komplexeren Fabric-Workloads sind möglich, aber die Basis ist solide – Skala 4: 'Strong accessibility support in most workflows'.

💡 Begründung: OneLake als zentraler, mandantenfähiger Lake verhindert strukturell Datenreplikation und unterstützt API-basierte Quellanbindung – Kernanforderungen sind erfüllt. Kleinere Lücken bestehen darin, dass technische Mechanismen allein keine organisatorische Durchsetzung garantieren (Score 4 gemäß Skala: Kernanforderungen erfüllt, kleinere Nachweise offen).

💡 Begründung: Azure ist der in der Beschreibung genannte bevorzugte Hyperscaler, bietet dedizierte deutsche Regionen (Frankfurt, Berlin) sowie breite EU-Abdeckung und ist damit optimal auf die Anforderung ausgerichtet – maximaler Score gemäß Skala (Broad regional choice including EU and preferred hyperscaler support).

💡 Begründung: Verschlüsselung ist per Default aktiviert, end-to-end abgedeckt und durch CMK-Optionen auf Enterprise-Niveau erweiterbar – dies entspricht dem vollen Score 5 der Skala (Strong encryption at rest and in transit by default with enterprise controls).

💡 Begründung: Grundlegende GDPR/BDSG-Konformität ist dokumentiert und Microsoft listet Subprozessoren transparent; Löschkonzepte und Datenkategorisierung via Purview sind vorhanden, aber Feinsteuerung (z.B. automatische Lösch-Routinen für personenbezogene Daten) erfordert zusätzliches Setup – Score 4 gemäß Skala (Good compliance posture with minor limitations or extra setup needs).

💡 Begründung: ISO 27001 ist klar vorhanden und wird durch eine umfangreiche Zusatzzertifizierungslandschaft ergänzt – dies entspricht dem vollen Score 5 der Skala (ISO 27001 plus additional major certifications clearly available).

💡 Begründung: Sowohl API-basierter als auch manueller Export/Import sind vollständig abgedeckt; das offene Speicherformat (Delta Parquet) und XMLA-Schnittstellen gewährleisten maximale Interoperabilität – Score 5 gemäß Skala (Full export/import via APIs and operational tooling).

💡 Begründung: Zwar ist das Speicherformat (Delta/Parquet) offen und portabel, aber die Gesamtlösung schafft starke Abhängigkeiten: DAX-Measures, Power BI-Artefakte, Purview-Integration, Entra ID-Governance und die gesamte Workload-Architektur sind Microsoft-proprietär. Laut Skala entspricht dies einer starken Plattformabhängigkeit (Score 2).

💡 Begründung: Der Markt für Microsoft-Fabric-Fachkräfte ist groß und gut ausgebildet (Power BI, Azure Synapse, Data Engineering). Fluktuation ist durch breite Verfügbarkeit kompensierbar. Laut Skala: starke Team-Kontinuität und bewährte Lieferfähigkeit (Score 4).

💡 Begründung: SaaS-Deployment, vorhandene Microsoft-Tenant-Integration und breite Partnerverfügbarkeit ermöglichen schnellen Rollout. Einschränkungen durch Governance-Einrichtung und Medallion-Architektur-Design verhindern einen Score von 5. Laut Skala: schneller Rollout mit begrenztem Setup-Aufwand (Score 4).

💡 Begründung: Das Microsoft-Partnernetzwerk ist eines der größten der Welt mit dedizierten Data & AI Practices für Großkunden. Alle vier Dimensionen (Consulting/Concept/Implementation/Deployment) sind durch zertifizierte Partner abgedeckt. Laut Skala: sehr starke Lieferantenkompetenz und Large-Enterprise-Fit (Score 5).

💡 Begründung: Microsoft ist der paradigmatische Fall eines maximalen Supplier-Size-Scores: marktkapitalisierungsstärkstes oder zweitstärkstes Unternehmen der Welt, kein Insolvenzrisiko erkennbar. Laut Skala: sehr großer und risikoarmer Lieferant (Score 5).

💡 Begründung: Azure/Fabric ist in über 60 Regionen verfügbar, Microsoft hat lokale Niederlassungen in nahezu allen relevanten Märkten und ein dicht gewebtes globales Partnernetzwerk. Laut Skala: starke weltweite Rollout- und Support-Kapazität (Score 5).

💡 Begründung: Als Microsoft-natives Ökosystem erzeugt Fabric positive Synergien mit nahezu allen strategischen IT-Programmen (M365, Azure, SAP via Konnektoren, Copilot). Negative Abhängigkeiten sind kaum erkennbar. Laut Skala: starke positive Ausrichtung zu strategischen Programmen (Score 5).

💡 Begründung: Git-Integration, CI/CD-Pipelines, Workspace-basierte Umgebungstrennung und kurze Iterationszyklen machen Fabric ideal für agile Teams. Microsoft selbst liefert Fabric in kurzen Sprints. Laut Skala: sehr starke Agile/Product-Delivery-Eignung (Score 5).

💡 Begründung: Trotz nativer Microsoft-Integration ist der initiale Setup-Aufwand durch die Komplexität der Plattform (OneLake-Design, Capacity-SKU-Planung, Governance-Konzept mit Purview, Sicherheitsmodell mit Entra ID) hoch. Dies entspricht gemäß Skala einem Score von 2 (High setup cost). Ein Score von 1 wäre nur bei noch komplexeren Plattformen angemessen.

💡 Begründung: Microsoft Fabric bietet durch Low-Code-Ansätze und native Integrationen Vorteile, ist aber keine Out-of-the-Box-Lösung. Customizing (Semantic Models, Pipelines, Security-Konfiguration, Notebook-Entwicklung) erfordert spezialisierte Expertise. Gemäß Skala entspricht dies einem moderaten Implementierungsaufwand (Score 3).

💡 Begründung: Microsoft Fabric reduziert Infrastruktur-Ops deutlich (SaaS), aber Day-2-Operations wie Capacity-Monitoring, Kostenkontrolle der F-SKUs, Semantic-Model-Updates und Governance-Administration sind nicht trivial. Gemäß Skala ist dies als moderater Betriebsaufwand einzustufen (Score 3).

💡 Begründung: Das Fabric-Lizenzmodell hat Vorteile (keine Pro-User-Lizenz für Viewer bei F64+), aber die Gesamtkosten setzen sich aus F-SKU-Kapazität, ggf. Power BI Pro-Lizenzen, Microsoft 365, Purview- und Copilot-Add-ons zusammen. Variable Komponenten und Komplexität der SKU-Auswahl entsprechen gemäß Skala einem durchschnittlichen Score (3) mit einigen variablen Posten.

💡 Begründung: Die Konsolidierung mehrerer Workloads (ETL, Data Lake, BI, ML) auf einer Plattform, Wegfall redundanter Lizenzen und Infrastruktur sowie KI-gestützte Automatisierung (Copilot für DAX/Pipelines) bieten starke Effizienzgewinne. Dies entspricht gemäß Skala einem starken Effizienznutzen (Score 4). Score 5 wird nicht erreicht, da der Realisierungshorizont und die initiale Komplexität den Nutzen verzögern.

💡 Begründung: Mit Microsoft Unified Support (ehemals Premier Support) gibt es klar definierte 1st-Level-Kanäle inkl. Telefon, Portal und Chat. Eine vollständige Delegation an den Kundensupport-Team als eigenständiger Support-Tier ist möglich, aber die Flexibilität ist etwas eingeschränkter als bei manchen spezialisierten Anbietern. Score 4 ist gerechtfertigt – stark, aber nicht 'very strong' da eigene Kundenintegration nur über Unified Support-Verträge möglich ist.

💡 Begründung: Microsoft bietet mit Unified Support eine gut strukturierte 2nd-Level-Kollaboration mit Produktspezialisten. TAMs und dedizierte Engineering-Eskalationspfade sind vorhanden. Es ist kein 'sehr starkes' Modell im Sinne von vollständig anpassbarer Integration, aber es entspricht einem guten 2nd-Level-Vendor-Collaboration-Modell (Score 4).

💡 Begründung: Microsoft hat gut dokumentierte Eskalationspfade bis hin zu Engineering-Teams, besonders für Sev A/B-Fälle im Unified Support. Bugfixes werden über reguläre Release-Zyklen (monatliche Updates) oder Hotfixes eingespielt. Der Prozess ist strukturiert, aber nicht immer transparent bzgl. Timelines, daher Score 4 statt 5.

💡 Begründung: Das Microsoft-Supportkonzept ist für Enterprise-Kunden sehr gut ausgebaut. Eine Ticket-Bridge-Integration ist über die Service Management-APIs des Support-Portals möglich, aber nicht out-of-the-box für alle ITSM-Tools verfügbar. Weltweiter Support und viele Sprachen inkl. Deutsch sind verfügbar. Score 4 da Ticket-Bridge-Integration etwas Eigenaufwand erfordert.

💡 Begründung: Die Reaktionszeit-SLAs sind klar dokumentiert und vertraglich bindend im Unified Support. Absolute Lösungszeit-Garantien gibt es jedoch nicht, was für Enterprise-Kunden eine gewisse Unsicherheit bedeutet. Dies entspricht einem 'Good SLA offering' (Score 4), da starke Reaktions-SLAs vorhanden, aber keine garantierten Resolution-Times.

💡 Begründung: 24/7-Coverage ist für kritische Fälle (Sev A) explizit vorhanden und global. Für Sev B/C greift Business-Hours-Support je nach Region. Dies ist eine starke, aber nicht vollständig homogene globale Abdeckung über alle Schweregrade, daher Score 4 statt 5.

💡 Begründung: Das Trainings- und Dokumentationsangebot von Microsoft für Fabric/Power BI ist marktführend. Rollenspezifische Lernpfade (Endnutzer, Admin, Developer, Data Engineer), kostenlose Lernplattform, Zertifizierungen, Community, Partnernetzwerk und exzellente Dokumentation rechtfertigen klar Score 5 ('Extensive training and documentation').

💡 Begründung: Fabric bietet zwar SAP-Konnektoren über Data Factory (SAP Table, SAP BW, SAP HANA), aber diese unterstützen primär Full-Load oder Timestamp-basierte Extraktion, kein natives SLT/ODP-CDC mit transaktionaler Konsistenz. SAP-zertifizierte CDC-Mechanismen sind nicht out-of-the-box vorhanden, weshalb Drittanbieter-Tools zwingend notwendig sind – entspricht Skala 2.

💡 Begründung: Data Factory enthält einen SAP BW-Konnektor der ODP und Open Hub unterstützt, womit Parallelbetrieb technisch möglich ist. Spezifische semantische Mappings von BW-Objekten (InfoObjects, DSOs, CompositeProviders) auf Fabric-Strukturen sowie ein automatisierter Migrationspfad fehlen jedoch. Dies entspricht Skala 3, da Parallelbetrieb über generische SAP-Schnittstellen möglich ist, aber kein spezifischer BW-Migrationsleitfaden vorhanden ist.

💡 Begründung: Der XMLA-Endpunkt in Power BI Premium/Fabric ist produktionsreif und unterstützt MDX-Abfragen über tabellarische Modelle. Qlik kann ihn als OLEDB/XMLA-Datenquelle einbinden, was in der Community und durch Partner dokumentiert ist. Es gibt jedoch keine offizielle gemeinsame Zertifizierung von Microsoft und Qlik, und einzelne MDX-Funktionen können Einschränkungen zeigen – Score 4 ist angemessen.

💡 Begründung: Fabric/Synapse bietet ODBC/JDBC-Zugriff auf die SQL Analytics Endpoints der Gold-Schicht mit AAD-Auth und TLS. Für den semantischen Layer (Semantic Model) ist XMLA der vorgesehene Weg, nicht ODBC/JDBC. Qlik kann über ODBC auf die SQL-Schicht zugreifen, aber eine spezifisch für Qlik optimierte, getestete und dokumentierte ODBC-Integration mit Referenzdokumentation fehlt. Score 3 ist konservativ angemessen.

💡 Begründung: Qlik bietet DirectQuery-ähnliche Modi (Direct Query) primär über ODBC-Verbindungen. Über den SQL Analytics Endpoint ist Pushdown für Filter und einfache Aggregationen möglich, jedoch ohne vollständige Optimierung. Gegen den XMLA-Endpunkt wird typischerweise importiert. Kein vollständiger Qlik-DirectQuery-Pushdown auf die Fabric-Plattform ist dokumentiert, was Score 3 (technisch möglich, aber kein vollständiger Pushdown) entspricht.

💡 Begründung: OneLake basiert auf Delta Parquet als offenem Format, und Daten sind direkt mit Spark, DuckDB und Trino lesbar ohne Platformzugang zum Lesen zu benötigen. V-Order ist eine proprietäre Schreiboptimierung, die Lesbarkeit mit Standard-Delta-Tools nicht bricht, aber minimal von reinem Open-Source-Delta abweicht. Dies entspricht Score 4: native Delta Lake Unterstützung mit geringen proprietären Erweiterungen, Kerndaten bleiben portabel.

💡 Begründung: Microsoft positioniert Medallion-Architektur als First-Class-Konzept in der Fabric-Dokumentation mit Templates, Workspace-Strukturen und Lineage-Tracking über Purview. DQ-Gates müssen über Data Factory Pipelines oder Notebook-Validierungen manuell implementiert werden – kein vollautomatisches DQ-Gate-System. Dies entspricht Score 4: gut unterstützt mit manuell konfigurierbaren DQ-Gates.

💡 Begründung: Das Semantic Model in Fabric ist via XMLA für Qlik, Excel Analysis Services und Tableau Third-Party-Verbindungen zugänglich. Power BI Metrics und DAX-Measures sind zentral definiert und werden über alle XMLA-Clients automatisch bereitgestellt. Neue Tool-Anbindungen erfordern leichte manuelle Konfiguration. Dies entspricht Score 4.

💡 Begründung: Fabric hat keine SAP-Content-Bibliothek mit vorgefertigten Modellen für SAP-Module. Es gibt Microsoft-Partner-Lösungen und Acceleratoren (z.B. von SI-Partnern), aber diese sind nicht Teil des Fabric-Produkts selbst. Die Plattform versteht keine SAP-Semantik nativ – vollständige Eigenmodellierung ist erforderlich. Score 2 ist angemessen, da zumindest generische Modellierungswerkzeuge vorhanden sind, aber kein SAP-spezifischer Content.

💡 Begründung: DirectLake ist exklusiv für Microsoft Fabric und ermöglicht In-Memory-ähnliche Performance ohne Datenimport, indem Parquet-Dateien direkt geladen werden. Microsoft dokumentiert und demonstriert Sub-3s Performance auf großen Datasets. Automatisches Framing und Query-Optimierung ohne manuelle Eingriffe sind integriert. Dies entspricht vollständig Score 5.

💡 Begründung: Das Power BI Zertifizierungskonzept (Promoted/Certified) ist nativ in Fabric integriert mit Audit-Logs über Purview und konfigurierbaren Admin-Berechtigungen. Ein vollautomatischer DQ-Gate-Prozess als Vorbedingung für Zertifizierung ist nicht out-of-the-box vorhanden – manuelle DQ-Prüfungen sind der Standard. Score 4 entspricht: Zertifizierung mit manuellen DQ-Checks und Audit-Trail vorhanden.

💡 Begründung: Fabric-Kapazitäten ermöglichen Workspace-basierte Ressourcentrennung und Priorisierung über Admin-Einstellungen. Dedizierte Query-Governor-Mechanismen mit expliziten SLA-Garantien für externe XMLA-Clients (Qlik) gegenüber nativen Power BI-Workloads sind nicht dokumentiert. Bei Extremlasten sind gegenseitige Beeinflussungen möglich. Score 3: grundlegendes Workload-Management, aber keine vollständige Performance-Isolation garantiert.

💡 Begründung: Es gibt keine offiziellen, von Microsoft bereitgestellten automatisierten Migrationswerkzeuge für QlikScript-zu-DAX/M. Microsoft bietet allgemeine Migrationsleitfäden und Partner wie Avanade oder Capgemini haben Migrationserfahrung, aber keine dokumentierten >100 Qlik-App-Referenzprojekte sind öffentlich nachgewiesen. Dies entspricht Score 3: Best-Practice-Dokumentation vorhanden, kein automatisiertes Tool, Erfahrung im Partnerökosystem.

💡 Begründung: Fabric's native Lineage-Feature (in Verbindung mit Purview) deckt automatisch Tabellen- und Spaltenebene ab, Impact-Analyse ist vorhanden. Vollautomatische, feldgranulare Lineage von SAP-Quelle bis zum exakten Report-Feld sowie BCBS-239-konformer Export sind noch nicht vollständig out-of-the-box, was Score 5 ausschließt. Score 4 passt: automatische Lineage über Schichten, Impact-Analyse manuell auslösbar, Business-Darstellung über Purview als separates Modul.

💡 Begründung: RLS ist in Power BI/Fabric gut etabliert, CLS ist ebenfalls unterstützt. Eine direkte SAP-Rollenintegration (z.B. automatische Synchronisation von S_TABU_DIS oder Kostenstellenverantwortlichkeiten) ist nicht nativ vorhanden – dies erfordert benutzerdefinierte Integrationen oder Middleware. Score 3 trifft zu: RLS und CLS technisch unterstützt, keine direkte SAP-Rollenintegration, manuelle Berechtigungspflege nötig.

💡 Begründung: Der Microsoft Fabric Terraform Provider existiert und ermöglicht IaC für Workspaces, Kapazitäten und viele Artefakte. CI/CD via Azure DevOps und GitHub Actions ist dokumentiert und nativ unterstützt. Nicht alle Konfigurationsaspekte (z.B. feingranuläre Purview-Einstellungen) sind vollständig per Terraform abbildbar, was Score 5 verhindert. Score 4 ist angemessen: IaC für Kernkonfigurationen verfügbar, CI/CD-Integration möglich, Umgebungspromotion weitgehend automatisierbar.

💡 Begründung: Fabric hat kein natives, dediziertes DQ-Framework wie z.B. Great Expectations oder Soda nativ integriert. DQ-Prüfungen sind über Spark Notebooks, Delta Live Tables-ähnliche Konzepte und Pipeline-Aktivitäten realisierbar, aber SAP-spezifische Regeln erfordern Eigenentwicklung. Alerting via Teams/E-Mail ist möglich. Dies entspricht Score 3: Grundlegendes DQ-Monitoring möglich, SAP-spezifische Regeln nur über Custom-Code.

💡 Begründung: Delta Lake auf Fabric/OneLake ist technisch für sehr große Datenmengen ausgelegt; Z-Ordering, Partitionierung und OPTIMIZE/VACUUM sind unterstützt. Vollautomatische Partitionierung ohne manuelle Konfiguration und nachgewiesene Sub-5s-Garantien über 10+ Jahre SAP-Finanzdaten sind nicht out-of-the-box dokumentiert, was Score 5 verhindert. Score 4 trifft zu: performante Historisierung >1 Mrd. Datensätze, manuelle Partitionierungskonfiguration, halbautomatische Optimize-Prozesse.

💡 Begründung: Das F-SKU-Modell ist kapazitätsbasiert und vermeidet unkontrollierte Query-Kosten. Azure Cost Management bietet Budgetalarme. Es gibt transparente verbrauchsbasierte Elemente (z.B. Smoothing bei Burst-Nutzung), und ein offizieller TCO-Rechner für Qlik/Power BI-Parallelszenarien ist nicht explizit dokumentiert, was Score 5 verhindert. Score 4 ist angemessen: überwiegend kapazitätsbasiert, Budgetalarme verfügbar, akzeptables User-Modell für große Nutzerzahlen.

💡 Begründung: Fabric unterstützt ein layered Access-Modell: Workspaces können so konfiguriert werden, dass Fachbereiche nur auf freigegebene Semantic Models und Gold-Layer-Berichte zugreifen. Sensitivity Labels und Purview-DLP ermöglichen Datenspreizungskontrolle. Ein explizit als 'Self-Service-Korridor' bezeichnetes Konzept mit vollständig konfigurierbaren Leitplanken ohne manuelle Einrichtungsschritte fehlt, was Score 5 verhindert. Score 4 ist passend.

💡 Begründung: Fabric/Azure Data Factory hat SAP BW Open Hub und SAP BW-Konnektoren, aber diese sind reine Datenextraktions-Konnektoren ohne Metadaten-Mapping oder automatisierte Strukturüberführung. BW-spezifische Migrationsautomatisierung ist nicht Teil von Fabric. Score 2 trifft zu: generische ETL-Konnektoren ohne BW-spezifisches Mapping, vollständig manueller Migrationsprozess für die Strukturüberführung.

💡 Begründung: Der XMLA-Endpunkt ermöglicht Qlik den Zugriff auf das zentrale Semantic Model, was Metadaten-Drift für einfache Measure-Änderungen reduziert. Jedoch ist keine automatische Synchronisations-Pipeline mit Alerting für Breaking Changes implementiert, und Qlik-seitige Konfigurationsänderungen müssen manuell ausgelöst werden. Score 3: zentrale Metadatenverwaltung vorhanden, manuelle Auslösung der Synchronisation für Qlik-seitige Anbindung nötig.

💡 Begründung: Fabric unterstützt technisch parallele Ingestion aus mehreren Quellen gleichzeitig (multiple Pipelines), aber spezifische Konfliktauflösung, Source-Priorisierung und automatisches Merging für parallele SAP-Systeme sind keine nativen Features. Dies erfordert eigene Logik in Spark-Notebooks. Score 3 ist angemessen: Dual-Source-Ingestion möglich, eigene Deduplizierungslogik in Transformations-Skripten erforderlich.

💡 Begründung: Power BI/Fabric hat keine native Out-of-the-box-Unterstützung für zeitabhängige SAP-Hierarchien mit SCD Typ 2/4 im semantischen Layer. Delta-Tables können SCD2-Muster speichern, aber die Exposition im Semantic Layer für transparente historische Hierarchieabfragen erfordert manuelle DAX-Modellierung und Transformationslogik. Score 3 trifft zu: Historisierung möglich, kundenspezifische Implementierung erforderlich, semantischer Layer gibt nur aktuelle Hierarchie nativ aus.

💡 Begründung: Fabric selbst bietet feingranulare RLS über Entra ID-Gruppen, aber keine native Integration mit SAP-Autorisierungsobjekten. Die Synchronisation erfordert eigene Skript-Entwicklung (z. B. über SAP Cloud Identity Services + SCIM-Provisioning in Entra ID + RLS-Konfiguration in Fabric), was Skala 3 entspricht.

💡 Begründung: Power BI Composite Models und DirectQuery ermöglichen technisch die Kombination von Lakehouse und SAP HANA-Daten in einer Abfrage, jedoch ohne optimierten Cross-Source-Pushdown. Dies entspricht Skala 3: Federation über Plattform-internen Query-Processor möglich, aber ohne vollständigen Pushdown und mit höherer Latenz.

💡 Begründung: Es gibt kein natives, in Fabric integriertes Qlik-Scanning- oder Migrationstool. Microsoft bietet allgemeine Migrationsdokumentation und Partnerlösungen an, aber keine automatisierte Abhängigkeitsanalyse für Qlik-Apps. Skala 2 ist angemessen: nur generische Dokumentationsvorlagen, keine Automatisierung oder spezifisches Tool-Support durch Fabric selbst.

💡 Begründung: Fabric Capacity Metrics App und Audit Logs ermöglichen Monitoring auf Workspace- und Nutzerebene. Eine granulare Tool-Unterscheidung (Power BI vs. Qlik via XMLA) ist aus den Logs extrahierbar, erfordert aber manuelle Analyse oder eigene Dashboard-Entwicklung. Kein integriertes Chargeback-Modul vorhanden. Dies entspricht Skala 3.

💡 Begründung: Azure Data Factory/Fabric-Pipelines erlauben Fehlerrouting, Skip-Logik und Dead-Letter-Muster, aber keine automatische Erkennung, Klassifikation und annotierte Quarantäne von SAP-Poison-Records ohne eigene Entwicklung. Dies entspricht Skala 3: Fehler-Handling konfigurierbar, Quarantäne als Muster umsetzbar, aber nicht out-of-the-box.

💡 Begründung: Delta Lake Time-Travel ist nativ in Fabric OneLake vorhanden und über SQL abfragbar. Power BI kann parametrisiert darauf zugreifen. Für >2 Jahre Retention müssen Vacuum-Einstellungen explizit konfiguriert werden, was out-of-the-box nicht standardmäßig aktiv ist. Qlik-Integration über XMLA für Time-Travel ist eingeschränkt. Skala 4 ist angemessen.

💡 Begründung: Fabric ist als Microsoft-natives Produkt vollständig auf Entra ID ausgerichtet. SAP Cloud Identity Services unterstützt SCIM-Provisioning nach Entra ID, womit SAP-Gruppen automatisch synchronisiert werden können. MFA und Conditional Access sind vollständig unterstützt. Dies entspricht Skala 5.

💡 Begründung: OneLake nutzt offenes Delta/Parquet-Format ohne proprietäres Lock-in auf Storage-Ebene. Der Export ist technisch via Azure Storage APIs oder AzCopy möglich. Vertragliche Exit-SLA-Garantien sind in Microsoft-Standardverträgen nicht explizit enthalten. Skala 4 ist korrekt: technischer Export ohne Konvertierung möglich, kein vollständiger Exit-SLA.

💡 Begründung: Power BI Endorsement (Promoted/Certified) mit Workspace-Zugriffssteuerung deckt wesentliche Anforderungen ab. Ein vollständiger automatisierter Workflow mit technischer Verhinderung der Nutzung nicht-zertifizierter Objekte auf Plattformlogik-Ebene (nicht nur Berechtigungen) ist begrenzt. Audit-Trail über Fabric-Aktivitätslogs vorhanden. Skala 4 ist angemessen.

💡 Begründung: Delta Lake MERGE und Fabric Data Factory ermöglichen selektives, idempotentes Reprocessing von Partitionen. Automatische Duplikat-Erkennung und UI-gestütztes selektives Reprocessing einzelner Zeitfenster ohne Entwicklungsaufwand sind begrenzt. Skala 4 ist angemessen: selektives Reprocessing durch konfigurierbares Design möglich, manuelle Auslösung über Plattform-Werkzeuge.

💡 Begründung: Fabric ist primär eine Analyse- und Datenplattform ohne nativen Writeback-Workflow nach SAP. Über ADF SAP-Konnektoren (RFC/BAPI, OData) ist Writeback technisch integrierbar und dokumentiert, aber Governance-Mechanismen (Vier-Augen-Freigabe, Audit-Trail für Writeback) müssen selbst implementiert werden. Skala 3 ist angemessen.

💡 Begründung: Fabric stellt keine spezifischen Werkzeuge für SAP BW-zu-S/4HANA Masterdaten-Harmonisierung bereit. Die generische ETL-Infrastruktur (Notebooks, Pipelines, Delta MERGE) ermöglicht die Umsetzung, aber vollständig als Eigenimplementierung ohne vorgefertigte Konflikterkennungs- oder Mapping-Frameworks. Skala 3 entspricht dem realistischen Leistungsumfang.

💡 Begründung: Fabric deckt Basis-Versionierung (Git), Deployment Pipelines und teilweise Impact-Analyse via Lineage ab. Für strukturierte Genehmigungsprozesse mit fachlichen Reviewern ist jedoch Azure DevOps oder ein externes Workflow-Tool erforderlich. Dies entspricht Score 3 der Skala: Basis-Versionierung vorhanden, Genehmigungsprozesse über externes Tool abzubilden, keine native vollständige Impact-Analyse auf alle BI-Artefakte.

💡 Begründung: Fabric verfügt über Kapazitäts-Management und gewisse Throttling-Mechanismen, aber keine tool-spezifische Differenzierung zwischen XMLA-Clients (Qlik) und nativen Power BI-Zugriffen mit automatischer Drosselung bei SLA-Risiken. Die Workload-Isolierung ist auf globaler Kapazitätsebene möglich, jedoch nicht mit tool-basierter Granularität. Dies entspricht Score 3: grundlegendes Query-Throttling ohne tool-spezifische Differenzierung.

💡 Begründung: Fabric bietet keine dedizierten Testframework-Funktionen für den Vergleich zweier BI-Tool-Ausgaben auf Kennzahlenebene. Zwar sind dbt-Integrationen oder Notebook-basierte Validierungen technisch möglich, aber es existiert kein natives, in den Migrationsprozess eingebettetes Vergleichs- und Abnahme-Workflow-Tool. Die Validierung bleibt im Wesentlichen auf manuelle Stichproben durch Fachbereiche angewiesen, was Score 2 entspricht.

💡 Begründung: Delta Tables in OneLake bieten native Schema Evolution für additive Änderungen. Purview ermöglicht Metadatenkatalogisierung und manuelle Impact-Analyse. Automatische Erkennung von SAP CDS-View-Schemaänderungen und automatische Propagation über Bronze/Silver/Gold mit Pipeline-Owner-Benachrichtigung ist nicht out-of-the-box verfügbar und erfordert eigene Implementierung (z.B. via Data Factory Schema Drift Detection). Dies entspricht Score 3: Schema-Versionierung in Katalog erfassbar, Impact-Analyse manuell durchführbar, einfache additive Änderungen durch Delta Evolution unterstützt.

💡 Begründung: OneLake ist explizit als 'One Lake for the entire organization' konzipiert, unterstützt alle Datentypen, bietet native Mandantenfähigkeit und zentralen Zugriff – dies entspricht der Best-in-Class-Definition der Skala.

💡 Begründung: Die Medallion-Architektur ist ein zentrales, dokumentiertes Designmuster in Fabric, das durch native Lakehouse-Konzepte, Pipelines und Notebooks vollständig und ausgereift umgesetzt wird – Score 5 ist gerechtfertigt.

💡 Begründung: Delta Lake als primäres Format mit vollständigen ACID-Garantien ist stark; Iceberg-Support wurde hinzugefügt, aber Hudi-Support ist begrenzt. Kein vollständiges Multi-Format-Support auf Augenhöhe mit Databricks, daher Score 4 statt 5.

💡 Begründung: Fabric Data Factory (ADF-Nachfolger) mit Power Query, Dataflows Gen2 und 200+ Konnektoren ist Best-in-Class für Low-Code-ETL – Score 5 ist durch die breite Konnektorbibliothek und ausgereifte visuelle Designer gerechtfertigt.

💡 Begründung: CDC ist über einzelne Konnektoren (z.B. SQL Server CDC) und inkrementelle Refresh-Mechanismen verfügbar, aber kein durchgängiges, nativ integriertes CDC-Framework für alle Quellen vorhanden. Dies entspricht dem Minimum (Score 3) im Vergleich zu spezialisierten CDC-Lösungen.

💡 Begründung: OneLake Shortcuts ermöglichen virtuellen Zugriff auf S3 und GCS, was die Grundanforderung erfüllt. Jedoch ist die Cross-Cloud-Integration weniger ausgereift als dedizierte Datenföderationslösungen, und einige Szenarien erfordern dennoch Datenkopien – Score 3 ist angemessen.

💡 Begründung: Fabric's Real-Time Intelligence ist eine ausgereifte Streaming-Lösung mit Eventstream, KQL-Datenbank und direkter BI-Integration. Sie übertrifft die Mindestanforderung klar, erreicht aber nicht ganz die Flexibilität von Spark Structured Streaming in Databricks – Score 4.

💡 Begründung: Multi-Language-Support (Python, SQL, Scala, R) und Kollaborationsfunktionen sind vorhanden und gut integriert. Echtzeit-Co-Authoring ist eingeschränkter als bei Konkurrenzprodukten (z.B. Databricks Notebooks), daher Score 4 statt 5.

💡 Begründung: Purview-Integration für Governance ist stark und gut dokumentiert, jedoch sind einige Features noch nicht vollständig ausgreift (z.B. automatische Klassifizierung aller Fabric-Workloads). Score 4 ist konservativ und realistisch für den aktuellen Reifegrad.

💡 Begründung: Fabric's integrierte Lineage-Ansicht (Workspace-Lineage) ist gut für Asset-Ebene; Spalten-Level-Lineage erfordert Purview und ist nicht für alle Workloads vollständig automatisch verfügbar. Dies entspricht Score 4 – gut, übertrifft Minimum, aber kein vollständig ausgereifter Spaltenlineage.

💡 Begründung: Delta Lake Time Travel ist eine ausgereifte, gut dokumentierte Funktion in Fabric/OneLake mit VERSION AS OF und TIMESTAMP AS OF Syntax. Die Konfigurationsoptionen sind vorhanden, aber die UI-seitige Unterstützung für nicht-technische Nutzer ist begrenzt – Score 4.

💡 Begründung: Das Unified Audit Log mit Purview ist robust und gut in Microsoft Compliance-Frameworks integriert. Kleinere Lücken bestehen bei der vollständigen Abdeckung aller Fabric-Workloads im Audit Log und bei der nativen Manipulationssicherheit ohne zusätzliche Konfiguration – Score 4.

💡 Begründung: RLS und CLS sind vollständig und ausgereift in Power BI Semantic Models implementiert, unterstützen dynamische Regeln via DAX und sind tief in Entra ID integriert. Dies entspricht Best-in-Class gemäß Skala (Score 5), da keine erheblichen Lücken erkennbar sind.

💡 Begründung: Die Kombination aus Purview-Integration und MIP-Sensitivity-Labels, die sich automatisch auf nachgelagerte Artefakte vererben und Datenschutzrichtlinien durchsetzen, entspricht einer Best-in-Class-Implementierung (Score 5). Dies ist ein klar differenzierendes Merkmal im Microsoft-Ökosystem.

💡 Begründung: MLflow-basiertes Experiment-Tracking und eine Model-Registry sind in Fabric integriert, jedoch ist die ML-Plattform-Funktionalität im Vergleich zu Azure ML oder Databricks weniger umfangreich. Deployment-Pipelines für ML-Modelle in Produktion sind begrenzt. Score 3 (erfüllt das Minimum) ist angemessen, da wesentliche Funktionen vorhanden, aber nicht Best-in-Class sind.

💡 Begründung: Copilot für Fabric ist ein umfassendes KI-Assistenzsystem mit NLQ, Code-Generierung und Report-Automatisierung. Allerdings sind die Funktionen noch relativ neu, teilweise in der Reifung und erfordern für optimale Ergebnisse oft noch technisches Feintuning. Score 4 (gut, übertrifft Mindestanforderung) ist konservativ aber gerechtfertigt.

💡 Begründung: Power BI ist seit Jahren die Benchmark für Self-Service-BI (Gartner Leader) mit intuitiven Drag-and-Drop-Funktionen, umfangreicher Visualisierungsbibliothek und nativer Fabric-Integration. Dies entspricht eindeutig Best-in-Class (Score 5).

💡 Begründung: Die native Git-Integration ist gut implementiert für Azure DevOps und GitHub, deckt jedoch nicht alle gängigen Git-Plattformen (z.B. GitLab, Bitbucket) ab. Zudem ist die Abdeckung aller Artefakttypen noch nicht vollständig ausgereift. Score 4 (gut, übertrifft Mindestanforderung) ist angemessen.

💡 Begründung: Deployment Pipelines sind nativ vorhanden und decken BI-Artefakte gut ab. Für Data Engineering-Artefakte (Pipelines, Notebooks) ist die CI/CD-Reife über Git-Integration und REST APIs gegeben, aber weniger nahtlos als bei dedizierten DataOps-Plattformen. Score 4 ist angemessen da die Lösung gut ist, aber in einigen Bereichen noch reift.

💡 Begründung: Die Monitoring-Funktionen sind gut ausgebaut mit der Capacity Metrics App und Admin-Portal, jedoch erfordern detaillierte Kostenanalysen und workloadübergreifendes Monitoring oft zusätzliche Konfiguration oder Azure Monitor-Integration. Score 4 (gut, übertrifft Mindestanforderung) ist passend, da nicht alle Aspekte nahtlos Out-of-the-Box verfügbar sind.

💡 Begründung: Snowflake erfüllt alle Kriterien der Höchstbewertung: offene, dokumentierte REST- und SQL-APIs, Out-of-the-box-Konnektoren (Power BI, Qlik, Fivetran, SAP CDC), ODBC/JDBC-Standardschnittstellen sowie Unterstützung für Middleware-Integration. Dies entspricht exakt der Beschreibung von Score 5.

💡 Begründung: Snowflake bietet Logs, Query-History und Account-Usage-Metriken, was Basis-Monitoring über SQL-Abfragen ermöglicht. Ein proaktives, alertbasiertes Interface-Monitoring ist nicht nativ integriert und erfordert externe Lösungen – dies entspricht Score 3 der Skala ('Basic monitoring via logs, APIs, or health endpoints').

💡 Begründung: Snowflake erfüllt alle Kriterien der Stufe 5: vollständig anpassbare Rollen, feingranulare Berechtigungen auf Pfad-/Objektebene, Policy-basierte Zugriffskontrolle (Row/Column Policies entsprechen ABAC), sowie vordefinierte Rollen-Templates. Dies entspricht 'Granular RBAC + Path/Policy Control'.

💡 Begründung: SCIM 2.0 Support ist nativ vorhanden und ermöglicht event-gesteuerte, vollautomatische Provisionierung/De-Provisionierung von Usern und Gruppen – dies entspricht exakt der Beschreibung von Score 5.

💡 Begründung: Sowohl SAML 2.0 als auch OIDC werden unterstützt, Self-Service-Konfiguration ist möglich, und der gesamte SSO-Lifecycle (Setup, Zertifikate) kann kundenseitig verwaltet werden. Dies entspricht Score 5 ('Self-Service for OIDC & SAML').

💡 Begründung: Snowflake ermöglicht starke Datentrennung über separate Accounts innerhalb einer Organisation sowie granulare Permission-Policies. Vollständige logische Multi-Tenancy mit komplett isolierten Nutzerverzeichnissen pro Einheit ist möglich, aber die User-Verwaltung erfolgt primär auf Account-Ebene, was eher Score 4 entspricht als vollständiger projektisolierter Multi-Tenancy.

💡 Begründung: Als SaaS-Plattform abstrahiert Snowflake die gesamte Metadatenspeicherung intern – Kunden können keine externe Datenbank für Metadaten wählen oder konfigurieren. Dies entspricht keiner der enterprise-orientierten externen DB-Optionen; am ehesten trifft 'Embedded DB Only' (Score 2) zu, da es kein Embedded DB im klassischen Sinne, aber auch keine Konfigurierbarkeit gibt.

💡 Begründung: Vollständige native Integration mit S3, Azure Blob und GCS ist gegeben. Zusätzlich ermöglichen External Tables und Iceberg Tables die Nutzung von Daten direkt im Cloud-Objektspeicher. Dies entspricht eindeutig Score 5 ('Full Native Cloud Storage').

💡 Begründung: Snowflake bietet policy-basierte Cleanup-Funktionen (Data Retention, automatische Bereinigung alter Snapshots/Time-Travel-Daten), aber kein natives Verschieben zu einem günstigeren 'Archive'-Tier wie S3 Glacier. Dies entspricht Score 4 ('Policy-Based Cleanup Only').

💡 Begründung: Snowflake bietet kein On-Premise-Deployment und keine selbst gehostete PaaS-Option. Gemäß der Skala entspricht 'SaaS Only ohne On-Premise/Self-Hosted PaaS' Score 1 ('PaaS or SaaS Only'). Dies ist eine fundamentale Einschränkung für Kunden mit On-Premise-Anforderungen.

💡 Begründung: Der minimale Client-Footprint (nur Browser oder leichtgewichtige Treiber) und der vollständig serverlose Charakter aus Kundenperspektive entsprechen dem maximal geringen Ressourcenbedarf. Score 5 ('sehr geringer Footprint, containerisiert lauffähig') ist angemessen, wobei Containerisierung serverseitig durch Snowflake verwaltet wird.

💡 Begründung: Als SaaS-Dienst ist die 'Installation' ein vollautomatisierter, wizard-geführter Onboarding-Prozess ohne manuelle Schritte. Dies entspricht Score 5 ('Fully Automated / Single Command/Wizard').

💡 Begründung: Snowflake bietet natives Multi-Region-Replication mit Metadaten-Synchronisation, Failover-Gruppen und zentraler Verwaltung. Dies entspricht Score 5 ('Full Federation with Central Repository') mit synchronisierten Metadaten und robustem Multi-Location-Design.

💡 Begründung: Die entkoppelte Compute-/Storage-Architektur, automatisches Result-Caching, Micro-Partitioning und adaptive Query-Optimierung ermöglichen konsistent niedrige Latenz auch bei großen Datenmengen und vielen gleichzeitigen Nutzern. Dies entspricht Score 5 ('Excellent performance profile with strong architecture for low-latency operations at enterprise scale').

💡 Begründung: Snowflakes Multi-Cluster-Warehouses und automatisches Scaling (Auto-Suspend/Auto-Resume) sind industrieweit als Referenz für starke Concurrency bekannt. Query Queuing, Result-Caching und Workload-Isolierung durch separate Virtual Warehouses erfüllen alle Kriterien der Score-5-Beschreibung.

💡 Begründung: Snowflake bietet gute Mechanismen wie regionales Deployment, Result-Cache und Database Replication, die Latenz für verteilte Teams praktisch reduzieren. Ein nativer Edge/CDN-Layer fehlt jedoch, weshalb Score 5 nicht vergeben wird; Score 4 ist angemessen.

💡 Begründung: Snowsight ermöglicht grundlegende No-Code-Konfiguration, aber zentrale Governance-Objekte (Row Access Policies, Column Masking, komplexe RBAC-Hierarchien) werden primär über SQL DDL verwaltet. Das entspricht Score 3: Basis-No-Code für Standardeinstellungen, fortgeschrittene Konfiguration erfordert Scripting.

💡 Begründung: Snowpark, REST API, UDFs/Stored Procedures und das Native Application Framework decken eine breite Entwicklungs-Extensibility ab. Kleinere Einschränkungen im Core-Behavior (kein direkter Plugin-Eingriff in interne Prozesse) verhindern Score 5; Score 4 ist gut begründet.

💡 Begründung: Enterprise RBAC, SSO/SCIM-Integration und feingranulare Zugriffskontrollen sind für Offshore-Kollaboration gut geeignet. Explizite 'Guest-User'-Konzepte wie in dedizierten DevOps-Plattformen fehlen, aber die operationale Unterstützung ist stark, was Score 4 rechtfertigt.

💡 Begründung: Snowflake ist stark in API-basierter Integration und Code-in-Plattform (Snowpark), aber native Event-Webhooks für reaktive Erweiterungen sind limitiert (Streams/Tasks ersetzen dies teilweise). Keine tiefen Plugin-Extension-Points ins Core-Verhalten, daher Score 3 gemäß Skala.

💡 Begründung: Terraform-Provider, REST API, zentrale Policy-Objekte und INFORMATION_SCHEMA ermöglichen starke Automatisierung der Kontrollstrukturen. Snowsight ist kein vollwertiges Governance-Dashboard für alle Objekte, was Score 5 verhindert; Score 4 ist angemessen.

💡 Begründung: Snowflake ist vollständig proprietär und Closed Source. Es gibt keinerlei Quellcode-Zugang für Kunden. Dies entspricht eindeutig Score 1 der Bewertungsskala.

💡 Begründung: Als vollständig verwalteter SaaS-Dienst übernimmt Snowflake alle Upgrades transparent im Hintergrund. Behavior Change Policies geben Kunden Vorlaufzeit für Breaking Changes. Regressionsrisiko für Kunden ist minimal. Das entspricht Score 5 der Skala.

💡 Begründung: Time Travel, Fail-Safe, Database Replication/Failover und die SaaS-verwaltete Infrastruktur-HA erfüllen alle Kriterien für Score 5: Umfassendes HA- und Recovery-Modell mit dokumentierten Mechanismen.

💡 Begründung: Snowflake SaaS garantiert im Standard keine vom Kunden zu planenden Wartungsfenster; Updates erfolgen rolling im Hintergrund. Dies entspricht Score 5: No/near-zero downtime upgrades als Standard-Produktionsmuster.

💡 Begründung: Snowflake bietet publizierte Verfügbarkeits-SLAs für Enterprise-Kunden, was Score 4 rechtfertigt. Score 5 wäre bei noch stärker differenzierten und vertraglich garantierten Enterprise-SLAs mit höheren Uptime-Werten (z.B. 99,99%) möglich; die Standardkommunikation ist gut aber nicht außergewöhnlich.

💡 Begründung: Snowsight hat die Usability gegenüber dem klassischen UI deutlich verbessert, richtet sich aber primär an technische Nutzer (Entwickler, Analysten). Typische Business-User ohne SQL-Kenntnisse benötigen erhebliche Einarbeitung; daher passt Score 3 ('some training/documentation needed').

💡 Begründung: Das UI ist intern konsistent, aber es gibt kaum Enterprise-Theming oder Markenanpassung. Damit entspricht es Score 3 ('Generally consistent but with limited adaptation options').

💡 Begründung: Die Dokumentation ist sehr gut, aber In-Product-Guidance (kontextuelle Hilfe, schrittweise Assistenten) ist begrenzt. Score 3 passt: 'Basic documentation-driven guidance, limited in-product assistance'.

💡 Begründung: Für Entwickler und Dateningenieure ist der Task-Fit gut, für Business-User und Admins gibt es jedoch Reibungspunkte. Score 3 ('Adequate fit with some friction in common tasks') ist angemessen.

💡 Begründung: Es gibt eine funktionale SQL-Umgebung mit Autocomplete und Shortcuts, aber ein umfassendes Keyboard-First-Erlebnis oder erweiterte Power-User-Funktionen sind nicht prominent. Score 3 ('Basic productivity functions available') ist passend.

💡 Begründung: Snowflake ist eine Datenplattform, kein UX-zentriertes Tool – individuelle Anpassungen (Theme, Layout, Verhalten) sind minimal. Score 2 ('Limited personalization options') trifft zu.

💡 Begründung: Snowflake bietet keine breite mehrsprachige UI-Unterstützung; die Oberfläche ist de facto englischsprachig mit grundlegenden Locale-Einstellungen. Score 2 ('Limited language/localization support') ist konservativ aber zutreffend.

💡 Begründung: Es gibt keine prominent dokumentierte Accessibility-Strategie oder WCAG-Konformitätserklärung für Snowsight. Für eine Enterprise-Datenplattform ist das ein bekanntes Defizit. Score 2 ('Limited support for inclusive interaction') ist angemessen.

💡 Begründung: Snowflake bietet technische Bausteine (Zero-Copy Sharing, API-Konnektivität), um Replikation zu minimieren, ist aber keine dedizierte MDM/Reference-Data-Lösung. Die Anforderung 'usage of data from leading source systems by APIs' ist teilweise erfüllbar, erfordert aber Zusatzkonfiguration und ggf. Partner-Tools. Daher Score 3 (teilweise konform, Anpassungen nötig).

💡 Begründung: Snowflake unterstützt explizit EU-Regionen auf Azure (Germany North/West Central) und AWS (Frankfurt), was DSGVO-konforme EU-Datenhaltung ermöglicht. Beide bevorzugten Hyperscaler (Azure, AWS) werden unterstützt. Kleiner Abzug, da die Wahl des Deployment-Standorts vollständige Konfigurationssorgfalt erfordert und nicht alle Regionen Feature-Parität haben. Score 4.

💡 Begründung: Snowflake bietet standardmäßig starke Verschlüsselung für alle Datenklassen at rest und in transit, enterprise-grade Key-Management-Optionen (BYOK/Tri-Secret Secure) sowie Unterstützung für hohe Vertraulichkeitsanforderungen (SC3). Dies entspricht vollständig dem Score-5-Kriterium 'strong encryption at rest and in transit by default with enterprise controls'.

💡 Begründung: Snowflake veröffentlicht eine Subprozessor-Liste, bietet DPAs, unterstützt Right-to-Erasure durch SQL-basierte Löschung und Dynamic Data Masking. BDSG-spezifische Compliance ist indirekt über DSGVO-Konformität und EU-Rechenzentren erreichbar. Es besteht jedoch eine gewisse Abhängigkeit von Kundenkonfiguration (z.B. Löschkonzepte, Benutzerprofilstruktur), was einen vollständigen Score-5 verhindert. Score 4.

💡 Begründung: Snowflake verfügt über ISO 27001 plus ein breites Portfolio weiterer relevanter Zertifizierungen (SOC 2 Type II, PCI DSS, HIPAA, CSA STAR). Dies erfüllt klar das Score-5-Kriterium 'ISO 27001 plus additional major certifications clearly available'.

💡 Begründung: Snowflake bietet vollständige Export/Import-Funktionalität: COPY INTO für Bulk-Export/Import, Snowpipe für Streaming, native Parquet/Iceberg-Unterstützung, REST/ODBC/JDBC-APIs sowie Unterstützung für manuelle Up-/Downloads via UI und externes Staging (S3, Azure Blob, GCS). Dies erfüllt das Score-5-Kriterium 'Full export/import via APIs and operational tooling' vollständig.

💡 Begründung: Die Unterstützung von Iceberg Tables und Parquet-Export sowie Standardschnittstellen (ODBC/JDBC) ermöglicht gute Portabilität und entspricht Stufe 4. Nicht ganz Stufe 5, da proprietäre Features wie Snowpark, Time Travel oder das Native Application Framework bei einem Wechsel migriert werden müssen.

💡 Begründung: Snowflake-Skills sind auf dem Markt weit verbreitet, jedoch ist die Stabilität des konkreten Projektteams nicht durch das Produkt selbst gesichert. Abhängig vom gewählten Systemintegrator bestehen moderate Kontinuitätsrisiken, was Stufe 3 rechtfertigt.

💡 Begründung: Die reine Plattformbereitstellung ist sehr schnell (SaaS), doch für produktive Nutzung in Unternehmensszenarien mit SAP-Integration, Sicherheitskonfiguration und Datenmigration ist moderater bis guter Aufwand einzuplanen. Stufe 4 ist angemessen.

💡 Begründung: Das Ökosystem aus zertifizierten Elite-Partnern mit Großkundenerfahrung ist stark ausgeprägt. Snowflake selbst bietet Professional Services an. Stufe 5 wird nicht erreicht, da die Tiefe der Erfahrung je nach Partner und Region variieren kann; Stufe 4 ist gerechtfertigt.

💡 Begründung: Snowflake erfüllt alle Kriterien für Stufe 5: großes, finanzstarkes, börsennotiertes Unternehmen mit globaler Präsenz und hoher Kundenbasis (über 9.000 Unternehmenskunden), das aktiv in R&D und Wachstum investiert.

💡 Begründung: Multi-Cloud- und Multi-Region-Deployment ist ein Kernangebot von Snowflake. Mit Niederlassungen und Partnernetzwerken in EMEA, APAC und Amerika sowie regionalem Datenspeicher zur Compliance-Erfüllung wird Stufe 5 erreicht.

💡 Begründung: Die SAP-CDC-Integration und DirectQuery-Unterstützung für Power BI schaffen positive Synergien mit typischen Unternehmens-IT-Programmen. Keine signifikanten negativen Abhängigkeiten erkennbar, leichte Unsicherheiten bezüglich Timing-Abstimmung mit parallelen S/4HANA-Projekten verhindern Stufe 5.

💡 Begründung: Die SaaS-Natur und das Ökosystem (dbt, Terraform, CI/CD-Tooling) ermöglichen gute agile Delivery-Praktiken. Stufe 5 wird nicht erreicht, da Datenprojekte strukturell oft Elemente von Wasserfall-Planung (Datenmodellierung, Governance) erfordern, was die Methodik leicht einschränkt.

💡 Begründung: SaaS reduziert Infrastruktur-Setup erheblich (kein Hardware/OS-Management), jedoch sind Organisations- und Konzeptionsarbeiten für Enterprise-Deployments (Datenarchitektur, Security-Konzept, SAP-Anbindung) nicht trivial. Dies entspricht eher einem moderaten Setup-Aufwand (Score 3), nicht dem sehr niedrigen Level (Score 5/4), das nur bei minimal-konfigurationsarmen Tools erreicht wird.

💡 Begründung: Snowflake bietet viele native Features (Auto-Optimization, native Konnektoren), die Customizing reduzieren. Allerdings ist für ein vollständiges Enterprise-Szenario mit SAP-Quellen, Medallion-Architektur und feingranularer Security erheblicher Implementierungsaufwand zu erwarten. Partnertools (Fivetran, Qlik) sind zusätzlich zu lizenzieren und zu konfigurieren. Score 3 (moderat) ist daher angemessen.

💡 Begründung: Snowflake ist serverlos aus Infrastruktur-Sicht, aber der operative Aufwand für Query-Performance-Optimierung, Kostenüberwachung (Credit-Verbrauch), Benutzerverwaltung und Connector-Betrieb ist nicht vernachlässigbar. Im Vergleich zu On-Premise niedrig, aber nicht 'sehr niedrig' – Score 3 ist realistisch und konservativ.

💡 Begründung: Das Credit-basierte Modell hat variable Kostenkomponenten (Compute, Storage, Data Transfer, Cloud Services), die bei skalierender Nutzung schnell anwachsen können. Zusätzlich anfallende Kosten für Partner-Tools (Fivetran, Qlik Replicate) erhöhen die Gesamtkosten. Die Transparenz ist vorhanden, aber die Kalkulierbarkeit und das Kostenniveau im Enterprise-Bereich entsprechen eher Score 2 (teuer, variable Posten, Drittanbieter-Add-ons erforderlich).

💡 Begründung: Die Plattform eliminiert Silos, reduziert ETL-Komplexität durch native Features (Zero-Copy Sharing, Time Travel, Snowpark) und ermöglicht Self-Service-Analytics. Dies führt zu starken Effizienzgewinnen in Betrieb und Datennutzung (Score 4). Ein Score 5 wird nicht vergeben, da die hohen Lizenz- und Add-on-Kosten den Netto-Kostenvorteil teilweise kompensieren können.

💡 Begründung: Snowflake ermöglicht Partner-gestützten 1st-Level-Support über sein Partner-Ökosystem, bietet aber keine nativ integrierte Hotline-Lösung für Kundenseite. Das Modell ist für Enterprise-Kunden ausreichend, jedoch nicht herausragend – daher Score 3 (Adequate support model).

💡 Begründung: Die Verfügbarkeit von TAMs und erfahrenen Support Engineers für Eskalationen entspricht einem guten Second-Level-Modell. Business Critical- und Enterprise-Tier ermöglichen engere Vendor-Zusammenarbeit, was Score 4 rechtfertigt.

💡 Begründung: Der Eskalationspfad zu Engineering ist für höhere Support-Tiers dokumentiert und praxiserprobt. Es gibt keine öffentlich garantierte Bugfix-Timeline, aber das Modell ist deutlich besser als Best-Effort – Score 4 (Good engineering escalation path).

💡 Begründung: Das Support-Konzept ist enterprise-tauglich mit globaler Abdeckung, mehrsprachigen Optionen und ITSM-Integrationsmöglichkeiten. Die Ticket-Bridge ist nicht nativ out-of-the-box, aber über APIs realisierbar. Score 4 (Strong support concept) ist angemessen.

💡 Begründung: Die SLA-Struktur ist klar dokumentiert und nach Priorität gestuft. Business Critical-Tier bietet starke Response-SLAs, Standard-Tier ist weniger robust. Insgesamt ein gutes SLA-Angebot – Score 4 (Good SLA offering).

💡 Begründung: 24/7-Abdeckung ist vorhanden, jedoch nur für höhere Tiers. Regionale Hubs sorgen für globale Erreichbarkeit ohne signifikante Lücken. Score 4 (Good regional coverage) ist angemessen; Score 5 würde volle 24/7 für alle Tiers erfordern.

💡 Begründung: Das Trainingsökosystem ist sehr breit aufgestellt: role-basierte Zertifizierungen, Webinare, Hands-on Labs, umfangreiche Dokumentation und Community-Ressourcen decken Endnutzer, IT-Administratoren und Entwickler ab. Score 5 (Extensive training and documentation) ist gerechtfertigt.

💡 Begründung: Die Anforderung beschreibt, dass SAP-zertifizierte Partner vorhanden sind, aber keine native Plattform-eigene CDC-Implementierung. Laut Skala entspricht das eher Score 2 (CDC über Drittanbieter) bis 3 (CDC-Mechanismen mit SAP-Kompatibilität). Da die Partner-Konnektoren (Fivetran, Qlik Replicate) dokumentiert SAP-native Mechanismen nutzen und transaktionale Konsistenz bieten, aber separat lizenziert werden müssen, ist Score 3 angemessen – knapp über Score 2, weil die SAP-Zertifizierung der Partner-Tools einen echten Mehrwert bietet.

💡 Begründung: Laut Skala entspricht Score 4 einem Parallelbetrieb mit ODP-Extraktion und vorhandenem Migrationsleitfaden. Score 3 ist zutreffend, da der Parallelbetrieb technisch möglich ist über generische SAP-Schnittstellen und Partner-Tools, aber kein spezifischer Snowflake-eigener BW-Migrationsleitfaden dokumentiert ist. Referenzprojekte existieren in der Community.

💡 Begründung: Snowflake ist kein OLAP-System und implementiert keinen XMLA/MDX-Endpunkt. Diese Anforderung kann mit Snowflake als alleinigem Produkt nicht erfüllt werden. Laut Skala ist Score 1 korrekt: kein XMLA-Endpunkt vorhanden, Qlik-Integration über diesen Weg nicht möglich.

💡 Begründung: Snowflake ist für seine erstklassigen ODBC/JDBC-Treiber bekannt, die standardmäßig TLS-Verschlüsselung und OAuth/SSO-Authentifizierung (inkl. AAD) unterstützen. Die Qlik-Kompatibilität ist dokumentiert und durch Referenzkunden belegt. Dies entspricht vollständig Score 5 der Skala.

💡 Begründung: Qlik Sense hat keinen nativen DirectQuery-Connector zu Snowflake wie Power BI ihn bietet. Der Zugriff erfolgt über ODBC/JDBC, wobei Pushdown-Fähigkeiten begrenzt sind und teilweise clientseitige Verarbeitung stattfindet. Laut Skala entspricht das Score 2: DirectQuery nur über ODBC-Brücke ohne vollständigen Pushdown, erhebliche Performance-Einbußen möglich. Konservative Bewertung, da 'Qlik DirectQuery-Modus' nicht dasselbe ist wie der Power BI DirectQuery.

💡 Begründung: Die Anforderung spezifiziert explizit Apache Delta Lake mit Delta-Log-Kompatibilität. Snowflake nutzt Iceberg als offenes Format, nicht Delta Lake. Parquet-Unterstützung ist vorhanden, aber das Delta-Log-Protokoll (transaction log, ACID-Properties im Delta-Format) wird nicht nativ unterstützt. Score 2 ist angemessen: Parquet vorhanden, aber kein Delta Log-kompatibles Format; manuelle Konvertierung wäre nötig.

💡 Begründung: Snowflake ermöglicht eine saubere Medallion-Implementierung mit nativer Schema-Trennung, RBAC pro Schicht und Lineage-Unterstützung über Partner-Tools. Vollautomatische DQ-Gates sind kein natives Plattformkonzept, was Score 5 ausschließt. Score 4 ist korrekt: gute Unterstützung mit separaten Workspaces und Lineage, DQ-Gates manuell konfigurierbar.

💡 Begründung: Snowflake ist eine Datenspeicher- und Verarbeitungsplattform ohne eingebetteten semantischen Layer im Sinne von Metrik-Definitionen mit automatischer Propagation. Für Power BI gibt es DirectQuery, für Qlik ODBC, aber keine zentrale Metrik-Engine. Score 2 ist angemessen: der 'semantische Layer' ist nur für bestimmte Tools optimiert, andere benötigen erhebliche Konfiguration und separate Definitionen. Score 3 wäre möglich wenn man die Gold-Schicht als semantischen Layer interpretiert, aber ohne XMLA und zentrale Metrik-Verwaltung bleibt Score 2 konservativer und passender.

💡 Begründung: Snowflake ist ein generisches Data Warehouse ohne SAP-spezifischen Content. Es gibt keine vordefinierten Modelle für FI/CO/MM/SD/HR, keine automatische SAP-Tabellenbeziehungserkennung und keine native SAP-Buchungslogik. Score 2 ist korrekt: keine SAP-spezifische Unterstützung, vollständige Eigenmodellierung erforderlich. Score 1 wird vermieden, da komplexe SAP-Hierarchien technisch abbildbar sind, nur ohne Automatisierung.

💡 Begründung: Snowflake bietet dokumentierten DirectQuery-Support für Power BI mit Query-Pushdown-Optimierung. DirectLake ist nicht möglich (kein Microsoft Fabric). Performance-Ziele bei TB-Datenmengen sind mit manuellen Aggregations-Tabellen und Snowflake's Result-Caching erreichbar. Score 4 entspricht der Skala: DirectQuery mit Pushdown, Performance erreichbar mit manuell konfigurierten Optimierungen.

💡 Begründung: Power BI Dataset-Zertifizierung ist ein Power BI-seitiges Feature, das für beliebige Datenquellen nutzbar ist. Snowflake kann als Datenquelle zertifizierter Datasets dienen, aber eine automatisierte Integration zwischen Snowflake's DQ-Framework und dem Power BI-Zertifizierungsprozess existiert nicht. Score 3 ist angemessen: technisch nutzbar, aber keine Integration mit DQ-Framework, manueller Prozess.

💡 Begründung: Snowflake's Virtual Warehouse-Architektur ist eine der stärksten Eigenschaften der Plattform: separate Compute-Cluster pro Workload-Typ ohne geteilte Ressourcen sind das Kerndesignprinzip. Qlik- und Power BI-Workloads können auf vollständig isolierten Virtual Warehouses mit konfigurierbaren Größen und Auto-Scaling betrieben werden. Dies entspricht Score 5 der Skala: vollständige Workload-Isolation mit dedizierten Ressourcepools, kein noisy-neighbor-Effekt.

💡 Begründung: Snowflake ist eine Datenspeicher- und Verarbeitungsplattform, keine BI-Migrationslösung. Es gibt keine dokumentierten Qlik-spezifischen Migrationswerkzeuge oder -methodiken im Snowflake-Ökosystem. Allenfalls generische Best Practices zur Datenmodellierung existieren. Score 2 gemäß Skala: nur generische Leitlinien ohne Qlik-Spezifik, kein Tool-Support.

💡 Begründung: Snowflake hat native Access History und einige Lineage-Metadaten, aber keine automatische feldgranulare Lineage über Medallion-Schichten hinweg bis zum BI-Report. SAP-zu-Snowflake-Lineage ist nicht automatisch. Impact-Analyse ist nicht nativ vorhanden. Score 2 gemäß Skala: partielle Lineage innerhalb der Plattform, SAP-zu-Plattform nicht automatisch.

💡 Begründung: RLS und CLS sind stark und nativ in Snowflake implementiert. Die SAP-Rollenintegration fehlt jedoch als native Funktion; es gibt keinen automatischen Sync-Mechanismus mit SAP-Autorisierungsobjekten. Manuelle oder skriptgestützte Abbildung ist notwendig. Score 3 gemäß Skala: RLS und CLS technisch unterstützt, keine direkte SAP-Rollenintegration.

💡 Begründung: Der offizielle Terraform-Provider ist vorhanden und weit verbreitet. Einige komplexe Konfigurationen (z.B. Snowpark-Prozeduren, bestimmte Netzwerkkonfigurationen) erfordern noch ergänzende Scripting-Ansätze. Dev/Test/Prod-Promotion ist weitgehend automatisierbar. Score 4 gemäß Skala: IaC für Kernkonfigurationen verfügbar, CI/CD-Integration mit überschaubarem Aufwand möglich.

💡 Begründung: Snowflake hat keine eingebaute DQ-Engine mit konfigurierbaren Regeln, Dashboards oder Eskalationsmechanismen. SAP-spezifische Abstimmlogiken sind vollständig über Custom-Code zu implementieren. Alerting ist nur rudimentär via Snowflake Alerts möglich. Score 2 gemäß Skala: DQ-Prüfungen nur über externe Tools oder Eigenentwicklung realisierbar.

💡 Begründung: Snowflake ist nachweislich für Multi-Milliarden-Datensatz-Szenarien geeignet. Automatic Clustering reduziert manuellen Aufwand erheblich. Z-Order wie in Delta Lake ist nicht identisch vorhanden, aber Clustering Keys erfüllen ähnliche Zwecke. Time Travel bis 90 Tage unterstützt historische Analysen. Score 4: performante Historisierung mit halbautomatischer Konfiguration.

💡 Begründung: Das Snowflake-Modell ist stark verbrauchsbasiert (Credits). Resource Monitors können Warnungen und Suspendierungen auslösen, sind aber keine echten Cost-Caps ohne Betriebsunterbrechung. Bei vielen parallelen BI-Nutzern sind Kosten schwer vorhersehbar ohne sorgfältiges Warehouse-Design. Score 2 gemäß Skala: stark verbrauchsbasiert, Kosten bei intensiver Parallelnutzung schwer vorhersehbar.

💡 Begründung: Snowflake bietet technisch die Bausteine (RBAC, RLS, CLS) für Governed Self-Service, aber kein vorgefertigtes Self-Service-Framework mit expliziten Leitplanken. Datenspreizungskontrolle (z.B. Verhindern unkontrollierter Exporte) ist nur über manuelle Richtlinien und Berechtigungen realisierbar. Score 3: grundlegende Berechtigungssteuerung, kein explizites Leitplanken-Konzept.

💡 Begründung: Snowflake ist eine Zielplattform ohne SAP-BW-spezifische Migrationswerkzeuge. Es gibt keine Metadaten-Überführung von BW-Objekten, keine Templates für BW-Historisierungsmuster und keine GUI-gestützten Mapping-Tools für BW-zu-Snowflake. Selbst mit Partner-Konnektoren bleibt die strukturelle Migration weitgehend manuell. Score 1 gemäß Skala.

💡 Begründung: Snowflake hat keine eigene semantische Layer-Funktionalität mit Metadaten-Propagation. Ohne zusätzliche Drittanbieter-Tools (AtScale, Cube.dev) müssen Metadaten für Power BI und Qlik separat gepflegt werden. Score 2 gemäß Skala: separate Pflege erforderlich, kein automatischer Abgleich nativ.

💡 Begründung: Snowflake unterstützt technisch Multi-Source-Ingestion ohne Einschränkung auf eine primäre Quelle. Jedoch gibt es keine native Deduplizierungs- oder Konfliktauflösungslogik; diese muss vollständig in der Transformationsschicht eigens entwickelt werden. Score 3 gemäß Skala: Dual-Source möglich, aber eigene Deduplizierungslogik in Transformations-Skripten erforderlich.

💡 Begründung: Snowflake bietet keine nativen semantischen Layer-Funktionen für zeitabhängige Hierarchien. SCD2-Muster sind in SQL/Snowpark implementierbar, erfordern aber kundenspezifische Entwicklung. Der semantische Layer ist Aufgabe der BI-Tools, nicht Snowflakes. Score 3 gemäß Skala: Historisierung möglich mit kundenspezifischer Implementierung, semantischer Layer gibt nur aktuelle Hierarchie aus ohne zusätzliche Arbeit.

💡 Begründung: Snowflake unterstützt SCIM für User-Provisioning (z.B. via Entra ID) und feingranulares RLS, aber es gibt keine native SAP-Rollen-Synchronisations-Engine. Das Mapping von SAP-Autorisierungsobjekten (Buchungskreise, Werke) auf Snowflake Row Access Policies erfordert vollständig eigene Entwicklung und manuelle Auslösung. Dies entspricht Skala-Stufe 2: vollständig manuell, keine Integration mit SAP-Rollenmanagement.

💡 Begründung: Snowflake ist primär ein Data Warehouse und kein Query-Federation-Tool. Es gibt keine native Connector-Implementierung für SAP HANA-Live-Abfragen mit Pushdown. Lösungen erfordern manuelle Virtualisierungsschichten, was Stufe 2 der Skala entspricht. Stufe 3 oder höher würde einen plattformintegrierten Query-Processor ohne Datenkopie voraussetzen, was Snowflake nicht out-of-the-box bietet.

💡 Begründung: Die Anforderung bezieht sich auf Qlik-seitige Migrations-Analyse-Werkzeuge, nicht auf Snowflake-Features. Snowflake liefert keinen Beitrag zur Qlik-App-Inventarisierung, Komplexitätsbewertung oder Formel-Mapping. Kein Snowflake-Feature adressiert diese Anforderung, daher Stufe 1.

💡 Begründung: Snowflake's ACCOUNT_USAGE.QUERY_HISTORY liefert granulare Daten zu Scan-Volumen, Compute-Zeit, Nutzer und Warehouse. Über Query Tags können BI-Tools unterschieden werden. Ein vollintegriertes Chargeback-Modul fehlt, aber der API-Export für manuelle Verrechnung ist vorhanden. Das entspricht gut Stufe 4 der Skala.

💡 Begründung: Snowflake selbst hat keine vorkonfigurierte Poison-Record-Erkennung oder Quarantäne-Engine. Mit Snowflake Streams, Tasks und dedizierten Fehler-Tabellen lässt sich das Muster technisch realisieren, ist aber nicht out-of-the-box verfügbar und erfordert signifikante Eigenentwicklung. Dies entspricht Stufe 3 der Skala.

💡 Begründung: Snowflake Time Travel funktioniert über proprietäre AT/BEFORE-SQL-Syntax, nicht über das Delta Lake Time-Travel-Protokoll (Anforderung nennt explizit Delta Lake Standard). Die Retention ist auf 90 Tage begrenzt (nicht >2 Jahre). Die direkte BI-Tool-Integration ohne Zwischenschicht ist eingeschränkt. Stufe 3 ist angemessen: technisches Feature vorhanden, aber BI-Integration erfordert Zwischenschicht und Retention ist begrenzt.

💡 Begründung: Snowflake hat dokumentierte und produktionsreife Entra ID-Integration mit SCIM-User-Provisioning und SAML-SSO inklusive MFA und Conditional Access-Unterstützung. Gruppen-Claims sind für Row Access Policies nutzbar. Die SAP-Gruppen-Synchronisation nach Entra ID ist jedoch kein Snowflake-Feature, sondern erfordert externe Konfiguration. Das entspricht gut Stufe 4, da die Entra ID-Integration zertifiziert und RLS via Gruppen-Claims funktioniert.

💡 Begründung: Snowflake Iceberg Tables speichern Daten nativ in Parquet auf externem Storage, was einen Lock-in-freien Zugriff ermöglicht. Der Export via COPY INTO PARQUET ist API-gestützt und automatisierbar. Ein vollständiger vertraglicher Exitprozess mit SLA fehlt im Standard-Angebot. Dies entspricht Stufe 4: technischer Export ohne proprietäre Konvertierung möglich, API-gestützt, aber kein vollständiger vertraglicher Exit-SLA.

💡 Begründung: Snowflake ist eine Datenplattform ohne eingebautes Data-Governance-Workflow-System für Zertifizierungsprozesse. Solche Features sind eher in Governance-Overlay-Lösungen wie Alation, Collibra oder Microsoft Purview angesiedelt. Snowflake kann über RBAC Zugriffssteuerung implementieren, aber keinen Zertifizierungs-Workflow mit Rollentrennung Creator/Steward/Consumer. Das entspricht Stufe 2.

💡 Begründung: Snowflake Streams ermöglichen CDC-basiertes inkrementelles Laden; MERGE-Operationen sichern Idempotenz. Partitioniertes Reprocessing ist über Clustering und Zeitfenster-Filter umsetzbar. Eine vollständige native Checkpoint-UI oder automatische Duplikat-Erkennung out-of-the-box fehlt, aber das Pipeline-Design mit MERGE/UPSERT entspricht gut Stufe 4: selektives Reprocessing durch konfigurierbares Pipeline-Design möglich, Idempotenz sichergestellt.

💡 Begründung: Snowflake ist primär ein analytisches Datensystem ohne native SAP-Writeback-Funktionalität. Die Plattform kann exportierte Daten in definiertem Format bereitstellen, und Dritttools können die SAP-Anbindung übernehmen. Snowpark könnte Transformationslogik vor dem Writeback ausführen. Kein nativer Vier-Augen-Workflow oder Audit-Trail für Writeback. Das entspricht Stufe 3: Drittsystem-Integration unterstützt, SAP-Anbindung ist Eigenverantwortung.

💡 Begründung: Snowflake hat keine nativen MDM- oder Konfliktharmonisierungs-Features für parallele SAP-Quellen. Über Snowpark und SQL-Transformationen kann die Harmonisierungslogik implementiert werden, aber es gibt kein dediziertes Framework, kein Konflikt-Dashboard und keine automatisierte Versionierung für BW-InfoObjects vs. S/4HANA-CDS-Views. Das entspricht Stufe 3: generische ETL-Logik nutzbar, aber vollständig manuell implementiert ohne dediziertes Framework.

💡 Begründung: Snowflake verfügt über keine nativen Change-Management-Workflows mit konfigurierbaren Reviewer-Rollen (technisch/fachlich) oder automatischer Impact-Analyse auf konsumierende BI-Artefakte (Power BI, Qlik). Time Travel ermöglicht manuelle Rollbacks, aber keinen auditierten Genehmigungsprozess. Dies entspricht Skala 2: manuelle Versionskontrolle via Code-Repository (Git-Integration vorhanden), kein nativer Workflow, keine automatische Impact-Analyse.

💡 Begründung: Snowflake's Virtual Warehouse-Konzept erlaubt es, separate Warehouses pro Tool (Power BI vs. Qlik) zu konfigurieren, was einer Ressourcenpool-Isolierung auf Verbindungsebene entspricht. Resource Monitors bieten Monitoring und Limits. Die Konfiguration auf Verbindungsebene über Warehouse-Zuweisung ist möglich. Vollautomatische Drosselung bei interaktiven SLA-Risiken mit Echtzeit-Eskalation ist nicht nativ vorhanden. Dies entspricht Skala 4: Workload-Isolierung über Ressourcenpools, Konfiguration auf Verbindungsebene möglich, Monitoring vorhanden, Automatisierung der Drosselung begrenzt.

💡 Begründung: Snowflake selbst bietet keine native Funktion für den Äquivalenzvergleich zwischen zwei BI-Tools. Über Snowpark und SQL-basierte Tests sowie dbt-Integration sind grundlegende Datenqualitätstests möglich. Der Qlik-zu-Power-BI-Vergleich erfordert jedoch eigene Skripte und manuelle Prozesse ohne nativen Abnahme-Workflow. Dies entspricht Skala 3: Grundlegende Datenqualitätstests verfügbar, kein natives Abnahme-Workflow, manueller Prozess erforderlich.

💡 Begründung: Snowflake bietet Schema Evolution für Iceberg Tables (additive Änderungen automatisch), jedoch keine native automatische Erkennung von Upstream-Schemaänderungen (SAP CDS Views) oder automatische Impact-Analyse über Bronze/Silver/Gold-Layer. Partner-Tools (Fivetran) können Schemaänderungen erkennen, aber die Propagation ist nicht vollständig automatisiert. Komplexe breaking changes erfordern Pipeline-Neuaufbau. Metadaten-Katalog (via Snowflake Catalog/Partner-Tools) ermöglicht manuelle Impact-Analyse. Dies entspricht Skala 3: Schema-Versionierung erfassbar, Impact-Analyse manuell, einfache additive Änderungen unterstützt, komplexe Änderungen erfordern manuellen Eingriff.

💡 Begründung: Snowflake ist Best-in-Class für strukturierte und semi-strukturierte Daten, jedoch ist die Unterstützung für vollständig unstrukturierte Daten (z. B. Bilder, Videos) noch nicht auf dem Niveau dedizierter Data-Lake-Lösungen. Daher Score 4 statt 5.

💡 Begründung: Die Medallion-Architektur ist ein natives, vollständig unterstütztes Konzept in Snowflake mit umfangreicher Dokumentation, Best Practices und integrierten Werkzeugen (Streams, Tasks, Dynamic Tables). Score 5 gerechtfertigt.

💡 Begründung: ACID-Transaktionen sind vollständig vorhanden und Iceberg-Support ist ausgereift. Da jedoch Delta Lake und Hudi nicht nativ unterstützt werden (nur Iceberg), wird Score 4 statt 5 vergeben, da die Anforderung explizit mehrere Formate nennt.

💡 Begründung: Die Anforderung zielt auf eine integrierte Low-Code-Oberfläche mit breiter Konnektorbibliothek. Snowflake ist hier auf externe Partner angewiesen und bietet selbst keine solche Oberfläche, was zu erheblichen Lücken führt. Score 2 ist angemessen.

💡 Begründung: Native Snowflake Streams decken interne CDC-Szenarien ab, aber für Quell-CDC sind externe Tools notwendig. Die Anforderung beschreibt native Mechanismen für Quell-CDC, die nur teilweise durch Partner erfüllt werden. Score 3 als Minimum erfüllt.

💡 Begründung: External Tables, External Stages und Secure Data Sharing decken die Kernanforderung gut ab. Zugriff auf externe relationale Datenbanken ohne Datenkopie ist jedoch eingeschränkter als bei spezialisierten Query-Federation-Lösungen. Score 4 ist angemessen.

💡 Begründung: Snowpipe und Snowpipe Streaming ermöglichen Near-Real-Time-Ingestion, aber echte Sub-Sekunden-Streaming-Verarbeitung ist nicht nativ vorhanden. Die Anforderung nach Echtzeit-Verarbeitung mit niedrigen Latenzen wird nur teilweise erfüllt. Score 3 als Minimum.

💡 Begründung: Snowflake Notebooks sind eine relativ neue Funktion mit wachsenden Fähigkeiten, unterstützen Python und SQL nativ, aber fehlen bei R und haben eingeschränktere Echtzeit-Kollaboration. Score 3 als ausreichend, da grundlegende Anforderungen erfüllt sind, aber Lücken bestehen.

💡 Begründung: Das native Governance-Framework ist stark und deckt Zugriffskontrolle, Masking und Tagging ab. Ein vollständig integrierter, feature-reicher Datenkatalog (z. B. mit Business Glossary) ist weniger ausgeprägt als bei spezialisierten Lösungen. Score 4 gerechtfertigt.

💡 Begründung: Grundlegende Lineage-Informationen sind über Access History verfügbar, aber eine automatische, spaltenbasierte End-to-End-Lineage bis zum BI-Report ist nativ nicht vorhanden. Dies stellt eine erhebliche Lücke gegenüber der Anforderung dar, Score 3 als Minimum erfüllt.

💡 Begründung: Time Travel ist eine der Kernstärken von Snowflake mit bis zu 90 Tagen Historienzugriff, SQL-basierter Abfrage historischer Daten und Wiederherstellungsmöglichkeiten. Dies ist Best-in-Class in der Branche. Score 5 vollständig gerechtfertigt.

💡 Begründung: Das Audit-Logging ist umfassend und abfragebereit, was die meisten Compliance-Anforderungen abdeckt. Da die Logs intern in Snowflake gespeichert sind und keine externe, kryptografisch gesicherte Unveränderlichkeit garantiert wird, wird Score 4 statt 5 vergeben.

💡 Begründung: Die Anforderung wird vollständig und Best-in-Class erfüllt: RLS via Row Access Policies, CLS via Column Masking, feingranular, produktionsreif und ohne Datenkopien – entspricht Score 5 laut Skala.

💡 Begründung: Snowflake bietet Tag-basiertes Klassifizierungssystem und automatisierte Policy-Durchsetzung, aber kein vollständig integriertes Sensitivity-Label-Framework mit automatischer Datenerkennung. Das erfüllt das Minimum (Score 3), übertrifft es aber nicht wesentlich.

💡 Begründung: Die Snowflake ML Model Registry und Snowpark ML decken wesentliche Anforderungen ab, jedoch ist das Experiment-Tracking und die MLOps-Reife noch nicht Best-in-Class. Score 3 ist angemessen – Mindestanforderung erfüllt, aber mit erkennbaren Lücken gegenüber spezialisierten Plattformen.

💡 Begründung: Cortex Analyst und ähnliche Features adressieren die Anforderung, sind aber noch nicht vollständig ausgereift oder breit verfügbar. Score 3 als ausreichend ist konservativ und angemessen – die Grundfunktion ist vorhanden, Best-in-Class noch nicht erreicht.

💡 Begründung: Snowsight erlaubt einfache Diagramme und Dashboards, jedoch fehlen typische Self-Service-BI-Funktionen wie umfangreiche Drag-and-Drop-Berichterstellung, komplexe Visualisierungsoptionen oder vollständige Fachanwender-Unabhängigkeit. Das entspricht Score 2 – rudimentär mit erheblichen Lücken.

💡 Begründung: Die native Git-Integration für Snowflake-Artefakte wie SQL, Notebooks und Snowpark-Code ist gut umgesetzt und geht über das Minimum hinaus. Jedoch sind nicht alle Artefakttypen (z.B. Pipelines, Data Sharing-Objekte) vollständig abgedeckt, daher Score 4 statt 5.

💡 Begründung: CI/CD ist über externe Toolchain-Integration gut möglich, aber nicht nativ in die Plattform eingebettet. Dies erfüllt das Minimum durch gute Integrierbarkeit (Score 3), übertrifft es aber nicht, da keine eigenständige integrierte CI/CD-Funktionalität vorhanden ist.

💡 Begründung: Die Ressourcen-, Kosten- und Query-Performance-Überwachung ist ausgereift und detailliert – übertrifft das Minimum klar. BI-spezifische Nutzungsmetriken (z.B. Report-Aufrufe) sind nicht nativ verfügbar, daher Score 4 statt 5.

💡 Begründung: Databricks erfüllt die meisten Anforderungen: vollständige REST-API-Dokumentation, JDBC/ODBC, XMLA, Partner-Konnektoren (SAP, Kafka etc.). Ein Score von 5 würde erfordern, dass wirklich ALLE Frontend-Funktionalitäten als API konsumierbar sind und Out-of-the-box-Konnektoren für alle gängigen Middleware-Systeme vorhanden sind – hier gibt es noch kleinere Lücken (z.B. SAP-Konnektoren nur über Partner). Score 4 ist daher angemessen.

💡 Begründung: Laut Skala entspricht Score 3 'Basic monitoring via logs, APIs, or health endpoints'. Databricks bietet genau das: Log-basiertes Monitoring, Health-Endpunkte und System Tables für Observability, aber kein starkes, spezialisiertes Interface-Monitoring-Tool (Score 4-5 würde klare operative Diagnosefunktionen für verbundene Schnittstellen erfordern). Konservativer Score 3 ist angemessen.

💡 Begründung: Databricks Unity Catalog erfüllt alle Kriterien der Stufe 5: granulares RBAC mit Path-/Policy-Control, Column- und Row-Level Security, vollständig anpassbare Rollen auf mehreren Hierarchieebenen sowie vordefinierte Rollen als Templates.

💡 Begründung: SCIM 2.0 ist nativ unterstützt und ermöglicht ereignisgesteuerte, vollautomatische Verwaltung von Benutzern und Gruppen – dies entspricht exakt der Stufe 5 der Bewertungsskala.

💡 Begründung: Sowohl OIDC als auch SAML werden mit Self-Service-UI und vollständiger Kundenkontrolle unterstützt – dies entspricht Stufe 5. Die Dokumentation ist umfassend und der gesamte SSO-Lifecycle ist kundenseitig verwaltbar.

💡 Begründung: Die Plattform bietet sehr starke, berechtigungsbasierte Datentrennung, die einer logischen Multi-Tenancy nahekommt. Da die Benutzerverwaltung jedoch auf Metastore-Ebene global ist und keine vollständig isolierten 'Organizations' existieren, passt Stufe 4 besser als Stufe 5.

💡 Begründung: Da Databricks als Managed Service die Metadatenspeicherung vollständig intern verwaltet und Kunden keine Kontrolle über die zugrundeliegende Datenbankwahl haben, entspricht dies eher einer Non-Standard/Embedded-Lösung. Stufe 1 wird vergeben, da keine flexible externe DB-Wahl möglich ist und die Anforderung auf Enterprise-Kontrolle über Backup/HA der Metadatenbank abzielt.

💡 Begründung: Vollständige, native Integration mit S3, Azure Blob/ADLS und GCS entspricht exakt Stufe 5. Kein Workaround oder Gateway erforderlich; alle großen Cloud-Object-Storage-Provider werden erstklassig unterstützt.

💡 Begründung: VACUUM und Time Travel bieten planbare, einfache Bereinigungsoperationen, aber keine reichhaltige Policy-Engine mit Multi-Kriterien oder dediziertem Archiv-Tiering (z.B. Glacier). Dies entspricht Stufe 3 (Basic Scheduled Cleanup mit einfachen, konfigurierbaren Regeln).

💡 Begründung: SaaS auf allen großen Hyperscalern inkl. AWS und Azure ist sehr stark, jedoch fehlt ein echtes, vollständiges On-Premise-Deployment auf Bare-Metal ohne Cloud-Infrastruktur. Stufe 4 (Strong PaaS) ist angemessen, da SaaS verfügbar ist, aber kein echtes On-Premise-Deployment ohne Cloud.

💡 Begründung: Da Databricks primär als verwalteter Cloud-Service betrieben wird, ist der Footprint für den Kunden moderat und Standard-Cloud-Hardware ausreichend. Stufe 4 ist angemessen, da kein unverhältnismäßig hoher Hardware-Bedarf besteht, aber ein vollständig minimaler containerisierter Selbstbetrieb nicht im klassischen Sinne möglich ist.

💡 Begründung: Die Provisionierung eines Databricks Workspace ist ein vollautomatisierter Prozess (Single-Command via Terraform oder Wizard im Portal), was Stufe 5 entspricht. Alle Komponenten werden automatisch konfiguriert.

💡 Begründung: Die Kombination aus Unity Catalog als zentralem Metastore und Delta Sharing für regionsübergreifende Datenzugriffe entspricht weitgehend Stufe 4 (asynchrone Replikation mit zentralem Repository). Ein vollständiges Active-Active-Federation-Modell wie in Stufe 5 beschrieben ist nicht nativ verfügbar.

💡 Begründung: Photon Engine, Serverless Compute, Delta Cache und optimierte Parquet-Layouts (Z-Ordering, Liquid Clustering) bilden eine exzellente Performance-Architektur für Enterprise-Scale. Dies entspricht klar Stufe 5 mit niedrigen Latenzprofilen und hervorragender Skalierbarkeit.

💡 Begründung: Serverless Compute mit automatischem Scale-out, Photon Engine für hohen Durchsatz, Query-Queueing in SQL Warehouses und Multi-Cluster-Warehousing entsprechen dem Profil von Score 5: proven strong concurrency model with robust scaling and queue/task handling for heavy parallel usage.

💡 Begründung: Es gibt Result-Caching und die Möglichkeit, Multi-Cloud-Regionen zu wählen, aber keine nativen Edge-Replication- oder Low-Bandwidth-Optimierungsmechanismen wie bei spezialisierten Distributed-DB-Lösungen. Das entspricht Score 3: basic mitigation options with moderate effectiveness.

💡 Begründung: Standard-Konfigurationen (Rollen, Grants, Catalog-Strukturen) sind über UI abbildbar, aber viele operative Anpassungen (z.B. automatisierte Policy-Rollouts, komplexe Row-Filter) erfordern SQL oder API/Terraform. Das entspricht Score 3: basic no-code customization for standard settings; advanced needs require coding.

💡 Begründung: Umfangreiche, gut dokumentierte REST API, offizielle SDKs, Databricks CLI, Terraform Provider, Plugin-Framework für Custom-Connectors und klare Deployment-Guidance entsprechen Score 5: full customer development model with documented APIs plus official extension/plugin mechanisms and clear deployment/support guidance.

💡 Begründung: Enterprise RBAC, externe Identity-Integration und Row/Column-Level Security für unterschiedliche Nutzergruppen sind gut ausgebaut. Explizite 'Guest'-Kollaborations-Features wie in reinen Kollaborationsplattformen fehlen, was Score 5 verhindert. Score 4: strong enterprise RBAC and external identity integration; offshore collaboration is well-supported operationally.

💡 Begründung: Starke API/Event-basierte Erweiterbarkeit (REST API, Webhooks, Partner Connect, Delta Sharing), aber kein natives Plugin-Framework für tiefe Core-Verhaltensänderungen. Das entspricht Score 4: strong extension capability via scripting/API/event hooks, with some limits in depth.

💡 Begründung: Zentrales hierarchisches Metadatenmodell, API-Automatisierung und UI-Support für Governance-Strukturen entsprechen Score 4: strong centralized controls with good maintainability. Vollautomatische Drift-Detection oder integriertes Policy-as-Code-Framework fehlen für Score 5.

💡 Begründung: Open-Core-Modell: Wichtige Kernkomponenten (Delta Lake, MLflow, Apache Spark) sind Open Source, aber die proprietäre Plattformschicht ist closed. Das entspricht Score 3: partial source availability (limited edition/components), constrained for full product modification.

💡 Begründung: Regelmäßiger Release-Zyklus (typisch alle ~4-6 Wochen neue DBR-Versionen), Long-Term-Support-Runtimes und klare Dokumentation sind vorhanden. Kunden müssen Runtime-Upgrades für ihre Cluster testen. Score 4: good regular release model and update guidance; moderate regression effort expected.

💡 Begründung: Starke Recovery-Mechanismen durch Cloud-native HA, Delta Lake Time Travel/Rollback und managed Control Plane. Vollständige HA-Konfiguration ist jedoch von Cloud-Provider-Architektur abhängig, kein eigenes Databricks-natives DR-Framework. Score 4: strong recovery mechanisms and practical HA options.

💡 Begründung: SaaS-Deployment-Modell mit transparenten, nicht-disruptiven Plattform-Updates entspricht Score 5: no or near-zero downtime upgrades are standard in supported production patterns. Kunden kontrollieren nur Cluster-Runtime-Upgrades eigenständig.

💡 Begründung: Publizierte Uptime-Commitments (~99,9%) in offiziellen Service Level Agreements sind vorhanden, aber Detailgrad und Enforcement-Mechanismen sind cloud-provider-abhängig und nicht so umfassend wie bei reinen Enterprise-SLAs mit Penalties. Score 4: good published availability commitment for managed offering(s).

💡 Begründung: Die Plattform erfordert für viele Kernaufgaben SQL- oder Python-Kenntnisse sowie Verständnis von Workspace-Konzepten (Catalogs, Schemas, Clusters). Zwar gibt es verbesserte UI-Elemente wie den Catalog Explorer, doch ist die Lernkurve für durchschnittliche Business-User erheblich – entsprechend Score 2 auf der Skala.

💡 Begründung: Die Plattform zeigt eine generell konsistente visuelle Sprache nach dem UI-Redesign, doch Theming-Optionen (z.B. eigenes Branding, Layout-Anpassung) sind minimal. Einige Bereiche (Notebooks vs. SQL Editor vs. AI/BI) wirken noch unterschiedlich. Das entspricht Score 3 – generell konsistent, aber mit limitierten Anpassungsoptionen.

💡 Begründung: Es gibt kontextuelle Hilfe und Links zur Dokumentation, aber für komplexe Workflows wie Unity Catalog Einrichtung oder CDC-Konfiguration fehlen echte Assistenten oder geführte Wizards im Produkt. Die Guidance ist primär dokumentationsgetrieben, was Score 3 rechtfertigt.

💡 Begründung: Kernworkflows für technische Nutzer (SQL-Entwicklung, Notebook-basierte Analyse, Pipeline-Monitoring) sind gut abgebildet. Admin-Tasks wie feingranulare Berechtigungen oder Lineage-Konfiguration erfordern jedoch tiefes Plattformwissen. Für reine Business-User gibt es erhebliche Reibung. Score 3 ist angemessen.

💡 Begründung: Es gibt Keyboard-Shortcuts in Notebooks und im SQL Editor (Code-Completion, Run-Shortcuts), aber eine durchgängige Keyboard-first-Navigation oder fortgeschrittene Filteroptionen für große Datensätze im UI sind nicht als Stärke bekannt. Score 3 für grundlegende Produktivitätsfunktionen.

💡 Begründung: Databricks fokussiert auf technische Funktionalität statt auf UI-Personalisierung. Endnutzer können kaum individuelle Präferenzen (Layout, Verhalten, Themes) konfigurieren. Es gibt keinen bekannten Mechanismus für gruppenspezifische UX-Anpassung. Das entspricht Score 2 – begrenzte Personalisierungsoptionen.

💡 Begründung: Databricks ist bekannt als englischsprachige Plattform ohne starke Multi-Language-UI-Unterstützung. Während manche Cloud-Provider-Integrationen (Azure) gewisse Lokalisierung mitbringen, bietet die Databricks-Plattform selbst keine robuste mehrsprachige UI oder umfassende Locale-Einstellungen. Score 2 ist konservativ aber realistisch.

💡 Begründung: Es gibt keine publizierten VPAT-Dokumente oder starken Accessibility-Commitments für Databricks UI. Grundlegende Keyboard-Funktionalität existiert in Notebooks, aber für Admin-UIs und komplexe Workflows ist inclusive Interaction-Support begrenzt. Score 2 für limitierte Unterstützung inklusiver Interaktion.

💡 Begründung: Unity Catalog und Lakehouse Federation adressieren das SSOT-Prinzip stark, da Daten direkt aus Quellsystemen abgefragt werden können ohne Kopien anzulegen. Da SAP- und MDS-Integrationen jedoch Partner-abhängig sind und kein nativer out-of-the-box API-Connector für alle führenden Quellsysteme existiert, sind kleinere Nachweise offen – Score 4.

💡 Begründung: Breite regionale Abdeckung inkl. EU-Regionen auf Azure und AWS ist klar gegeben. Azure als bevorzugter Hyperscaler wird nativ unterstützt. Damit werden alle Kriterien der höchsten Skala-Stufe erfüllt – Score 5.

💡 Begründung: Verschlüsselung at rest und in transit ist per Default aktiv, enterprise-grade Schlüsselkontrolle (CMK) ist verfügbar, und alle relevanten Datenkategorien sind abgedeckt. Dies entspricht der höchsten Skala-Stufe – Score 5.

💡 Begründung: Gute GDPR/BDSG-Grundlage mit DPA, SCCs und technischen Löschmechanismen ist nachgewiesen. Da die BDSG-Konformität und das vollständige Löschkonzept (inkl. Backups und Time-Travel-Versionen) kundenseitige Konfiguration erfordern und Subunternehmer-Transparenz vorhanden, aber Abhängigkeiten bestehen, ist Score 4 angemessen.

💡 Begründung: ISO 27001 ist klar vorhanden, ergänzt durch mehrere weitere major Certifications (SOC 2, CSA STAR). Dies entspricht der höchsten Skala-Stufe – Score 5.

💡 Begründung: Das offene Parquet/Delta-Format, umfangreiche API-Unterstützung, direkte Cloud-Storage-Anbindung und UI-basierte Import/Export-Funktionen erfüllen alle Kriterien der höchsten Skala-Stufe vollständig – Score 5.

💡 Begründung: Delta Lake ist zwar ein offener Standard und Daten liegen in Parquet vor, jedoch sind zentrale Governance- und Pipeline-Features (Unity Catalog, DLT, Photon) proprietär. Ein Wechsel erfordert signifikante Re-Implementierungsaufwände. Moderate Lock-in-Situation entspricht Score 3.

💡 Begründung: Das Databricks-Ökosystem wächst stark, aber spezialisierte Senior-Experten (Unity Catalog, DLT) sind am Markt begrenzt verfügbar. Teamkontinuität hängt stark vom jeweiligen Implementierungspartner ab. Score 3 reflektiert eine adäquate, aber risikobehaftete Situation.

💡 Begründung: SaaS-Deployment und gut dokumentierte Onboarding-Prozesse ermöglichen schnellen Start. Ein vollständiges Enterprise-Setup mit Governance, Sicherheit und Integration dauert länger, aber der initiale Time-to-Value ist hoch. Score 4 ist angemessen.

💡 Begründung: Databricks Professional Services und ein breites Partner-Ökosystem (Accenture, Deloitte, etc.) bieten starke Fähigkeiten für Großkunden. Erfahrung in großen Enterprise-Projekten ist gut dokumentiert. Score 4 reflektiert starke, aber nicht vollständig risikofreie Capability.

💡 Begründung: Databricks ist ein etabliertes Unicorn-Unternehmen mit starker Finanzierung und globalem Wachstum. Das Risiko einer Insolvenz ist minimal. Score 4 (statt 5) da das Unternehmen noch nicht börsennotiert ist und somit ein gewisses Restrisiko bleibt.

💡 Begründung: Databricks hat Büros und Support-Kapazitäten in allen wichtigen Regionen und ein großes Partner-Netzwerk für lokalen Support. Multi-Region-Rollout ist etabliert und dokumentiert. Score 4 reflektiert gute, aber nicht lückenlose globale Abdeckung in allen Nischen.

💡 Begründung: Es gibt keine starken negativen Abhängigkeiten, aber auch keine besonders starke positive Alignment-Story zu typischen ERP-Transformationen. Die SAP-Integration ist Partner-abhängig. Neutrale Bewertung mit Score 3 ist konservativ und angemessen.

💡 Begründung: Die Plattform ist von Grund auf für iterative, agile Datenenwicklung konzipiert. CI/CD-Integration, versionierte Notebooks, deklarative Pipelines und eine starke Community unterstützen moderne Delivery-Methoden optimal. Score 5 ist gerechtfertigt.

💡 Begründung: Die Plattform bietet zwar viele verwaltete Services und Serverless-Optionen, jedoch ist der initiale Setup-Aufwand durch die Vielzahl an Konfigurationsoptionen (Unity Catalog, Workspace, IAM, Netzwerk) und die notwendige Architekturkonzeption (Medallion, Governance-Modell) als hoch einzustufen. Gemäß Skala entspricht das Score 2 (High setup cost).

💡 Begründung: Databricks bietet zwar deklarative ETL über DLT und zahlreiche Integrationen, jedoch erfordern Partnerintegrationen (SAP, CDC), feingranulare Security-Konfiguration und die Entwicklung von Datenpipelines erheblichen Implementierungsaufwand. Score 2 gemäß Skala (High implementation effort).

💡 Begründung: Serverless und verwaltete Infrastruktur reduzieren den Betriebsaufwand deutlich, jedoch bleiben Plattformadministration, Benutzerverwaltung, Cost Governance und Pipeline-Monitoring relevante Aufwandspositionen. Dies entspricht einem moderaten Betriebsaufwand, Score 3 gemäß Skala.

💡 Begründung: Das DBU-Modell ist zwar transparent dokumentiert, jedoch durch viele Variablen (Workload-Typ, Instanzgröße, Serverless vs. Classic, Add-ons wie DLT-Premium) schwer kalkulierbar. Kombiniert mit separaten Cloud-Kosten ergibt sich ein tendenziell teures und in der Praxis intransparentes Gesamtbild. Score 2 gemäß Skala (teuer oder intransparent).

💡 Begründung: Databricks' Photon Engine, Serverless-Modell und die Konsolidierung von Data Engineering, ML und BI auf einer Plattform bieten starkes Effizienzpotenzial (Reduktion von Tool-Silos, schnellere Pipelines, weniger manuelle Eingriffe). Dies entspricht einem starken Effizienznutzen, Score 4 gemäß Skala.

💡 Begründung: Databricks unterstützt kein klassisches Hotline-basiertes 1st-Level-Modell, sondern primär Ticket-basierte Systeme. Partnerfirmen können als 1st-Level-Puffer fungieren, aber ein standardisiertes kollaboratives Modell ist nicht prominent dokumentiert – daher Mitte der Skala (3=Adequate).

💡 Begründung: Der Vendor stellt via Premium-Support technisch versierte Support Engineers bereit, die über Ticketsystem erreichbar sind und Probleme tiefer analysieren können. Dies entspricht einem guten 2nd-Level-Modell (4=Good second-level vendor collaboration), auch wenn ein vollständig formalisiertes kollaboratives Modell mit Kunden-internen Teams nicht standardisiert beschrieben ist.

💡 Begründung: Databricks hat als aktives Open-Source-Unternehmen (Apache Spark, Delta Lake) und als kommerzieller Anbieter klare Eskalationswege zu Engineering-Teams. Bug-Reports können eskaliert und nachverfolgt werden. Jedoch fehlt ein vollständig transparentes, SLA-gebundenes Engineering-Eskalationsmodell, daher Score 4 (Good engineering escalation path).

💡 Begründung: Databricks unterstützt globalen Support mit mehreren Tiers, Technical Account Managers für Enterprise-Kunden und grundlegend verfügbaren Integrationsmöglichkeiten. Ein standardisiertes Ticketbridge-Modell ist nicht prominent beschrieben, was eine volle 5 verhindert. Der Gesamtansatz ist jedoch stark (Score 4=Strong support concept).

💡 Begründung: Es existieren dokumentierte SLA-Strukturen mit Reaktionszeiten nach Prioritätsstufen, was einem guten Enterprise-SLA-Angebot entspricht (Score 4=Good SLA offering). Eine vollständige Garantie auf Lösungszeiten (nicht nur Reaktionszeiten) ist typischerweise nicht enthalten, was Score 5 verhindert.

💡 Begründung: 24/7-Abdeckung ist für kritische Severity-Level in Premium-Plänen verfügbar, mit globalen Support-Standorten. Jedoch sind regionale Unterschiede in der Qualität und Verfügbarkeit möglich, und nicht alle Pläne bieten vollständige 24/7-Abdeckung. Score 4 (Good regional coverage) ist angemessen.

💡 Begründung: Databricks Academy bietet eine der umfangreichsten Trainingslandschaften im Data-Platform-Bereich mit rollenspezifischen Lernpfaden, Zertifizierungen, Videos, Live-Trainings und einer sehr guten Dokumentation auf docs.databricks.com. Dies entspricht klar Score 5 (Extensive training and documentation).

💡 Begründung: Databricks selbst besitzt keinen SAP-zertifizierten CDC-Konnektor mit SLT/ODP-Unterstützung. Die Plattform bietet zwar native CDC-Fähigkeiten (APPLY CHANGES INTO in DLT) für die Datenverarbeitung, aber die eigentliche SAP-Extraktion erfordert externe ETL-Middleware. Dies entspricht Skala 2: Full-Load oder CDC nur über separat lizenzierte Drittanbieter realisierbar.

💡 Begründung: Databricks bietet keine native BW-Integration und keinen dokumentierten, Databricks-spezifischen BW-Migrationspfad. Die Extraktion ist über generische SAP-Schnittstellen mit erheblichem Eigenentwicklungsaufwand möglich. Dies entspricht Skala 2, da kein dedizierter BW-Konnektor vorhanden ist und die Parallelintegration erhebliche Eigenentwicklung erfordert.

💡 Begründung: Der XMLA-Endpunkt von Databricks SQL Warehouses ist auf Power BI (Analysis Services-Protokoll) ausgerichtet. Qlik Sense hat begrenzte XMLA-Unterstützung und eine offizielle Zertifizierung oder dokumentierte Kundenreferenz für Databricks XMLA + Qlik fehlt. Dies entspricht Skala 2: XMLA vorhanden, aber Qlik-Integration mit signifikanten Einschränkungen und ohne offizielle Unterstützung.

💡 Begründung: Databricks stellt offiziell gepflegte JDBC- und ODBC-Treiber bereit, die AAD/OAuth-Authentifizierung und TLS unterstützen. Qlik-Kompatibilität über JDBC ist dokumentiert und in der Community bekannt. Leichte manuelle Konfigurationsschritte sind erforderlich. Dies entspricht Skala 4.

💡 Begründung: Qlik Sense unterstützt einen SQL-basierten Direct Query-Modus über JDBC-Verbindungen, wobei grundlegende Operationen (Filter, einfache Aggregationen) pushdown-fähig sind. Ein vollständiger, dokumentierter Pushdown mit Qlik-Optimierung für Databricks ist nicht offiziell zertifiziert, und bei komplexen Abfragen ist teilweise client-seitige Verarbeitung zu erwarten. Dies entspricht Skala 3.

💡 Begründung: Databricks hat Delta Lake als Open-Source-Projekt initiiert und ist dessen Hauptcontributor. Das Delta-Protokoll ist öffentlich spezifiziert, und Daten bleiben als Parquet-Dateien mit Delta-Log vollständig portabel. Proprietäre Optimierungen (z.B. Deletion Vectors, Liquid Clustering) sind optional und beeinträchtigen die Grundkompatibilität nicht wesentlich. Dies entspricht klar Skala 5.

💡 Begründung: Medallion-Architektur ist ein zentrales Designprinzip bei Databricks mit offizieller Dokumentation, DLT-Support für automatisierte Pipelines, Expectations als DQ-Gates und Unity Catalog Lineage. Vollautomatische vorgefertigte Templates für alle Schichten fehlen teilweise, daher Skala 4 statt 5. Die Implementierung erfordert noch manuelle Konfiguration der DQ-Gates.

💡 Begründung: Databricks hat mit dem Metrics Layer (über Unity Catalog und AI/BI) Ansätze für einen zentralen Semantischen Layer, aber die Produktreife für eine vollständige Multi-Tool-Propagation (Power BI nativ, Qlik über XMLA eingeschränkt, andere Tools via ODBC) ist nicht auf dem Niveau von Skala 4. Teilweise redundante Definitionen können nötig sein. Skala 3 ist angemessen.

💡 Begründung: Databricks hat keine SAP-Content-Bibliothek und kein inhärentes Verständnis von SAP-Datenmodellen. Partner-Ökosystem (z.B. Accenture, Capgemini) bietet Acceleratoren an, aber diese sind keine Databricks-nativen Features. Vollständige Eigenmodellierung ist erforderlich. Dies entspricht Skala 2.

💡 Begründung: Databricks ist keine Microsoft Fabric-Plattform, daher ist DirectLake nicht verfügbar. DirectQuery mit Power BI über XMLA/JDBC ist gut dokumentiert und funktioniert mit Pushdown. Performance-Ziele bei >1TB sind mit Photon und manuellen Aggregationen erreichbar, aber nicht out-of-the-box garantiert. Dies entspricht Skala 4.

💡 Begründung: Die Power BI Endorsed/Certified Dataset-Funktionalität ist ein Power BI Service-Feature, das unabhängig von der Datenquelle funktioniert. Databricks bietet keinen nativen Workflow, der DQ-Checks als Vorbedingung für Power BI-Zertifizierung automatisiert. Der Prozess ist manuell und nicht in Databricks integriert. Dies entspricht Skala 3.

💡 Begründung: Databricks ermöglicht die Erstellung separater SQL Warehouses für Power BI und Qlik mit unabhängigen Ressourcenpools und Auto-Scaling. SLA-Garantien können über Cluster-Sizing und Priorisierungseinstellungen konfiguriert werden. Bei extremen Lastspitzen auf gemeinsamer Cloud-Infrastruktur kann es zu begrenzten Interaktionen kommen. Dies entspricht Skala 4.

💡 Begründung: Es existieren keine dokumentierten QlikScript-zu-DAX/M-Konvertierungstools oder Qlik-spezifische Migrationsmethodiken im Databricks-Ökosystem. Die Plattform ist ein Daten-Layer, nicht ein BI-Migrations-Tool. Gemäß Skala entspricht dies Score 2: nur generische BI-Migrationsleitlinien ohne Qlik-Spezifik, Eigenentwicklung des Migrationsprozesses notwendig.

💡 Begründung: Databricks Unity Catalog liefert starke automatische Lineage auf Tabellen- und Spaltenebene innerhalb der Plattform (Bronze/Silver/Gold). Die Lücken liegen bei der SAP-Quellelineage (abhängig vom Konnektor) und der End-to-End-Propagation bis zum konkreten Report-Feld in Power BI/Qlik. Impact-Analyse ist technisch möglich, aber nicht vollautomatisch. Score 3 gemäß Skala: Lineage auf Tabellenebene erfasst, feldgranular nur für definierte Pfade, keine vollautomatische Impact-Analyse bis zum Report-Feld.

💡 Begründung: RLS und CLS sind in Unity Catalog gut implementiert und gelten über alle Schichten. Die fehlende native SAP-Rollenintegration (S_TABU_DIS etc.) und die Notwendigkeit manueller Berechtigungspflege pro Schicht ohne automatisierte SAP-Synchronisation entsprechen Score 3 gemäß Skala.

💡 Begründung: Databricks erfüllt alle Kriterien für Score 5: offizieller Terraform-Provider (registry.terraform.io/providers/databricks/databricks), Databricks Asset Bundles für IaC-basierte Pipeline/Workspace-Konfiguration, native CI/CD-Dokumentation für GitHub Actions und Azure DevOps, und automatisierte Umgebungspromotion ohne manuelle Export/Import-Zyklen.

💡 Begründung: DLT Expectations ermöglichen konfigurierbare Validierungsregeln an Pipeline-Übergängen mit automatischem Quarantäne-Mechanismus. Alerting via E-Mail/Webhooks ist verfügbar. SAP-spezifische Abstimmregeln müssen manuell definiert werden, sind aber vollständig konfigurierbar. Ein natives DQ-Dashboard existiert im DLT-Monitoring. Dies entspricht Score 4: DQ-Framework vorhanden, SAP-Regeln manuell definierbar, Alerting und Dashboard vorhanden.

💡 Begründung: Delta Lake auf Databricks ist explizit für Milliarden-Datensatz-Szenarien ausgelegt. Automatisches Optimize (Auto-Optimize), Predictive Optimization, Z-Order-Clustering, Photon Query Engine und Time Travel für >10 Jahre entsprechen allen Score-5-Kriterien. Dies ist eine der Kernstärken der Plattform.

💡 Begründung: Das DBU-Modell ist verbrauchsbasiert und kann bei Enterprise-BI mit vielen Concurrent-Usern erhebliche und schwer planbare Kosten verursachen. Serverless SQL Warehouses erhöhen die Skalierbarkeit, aber auch die Kostenvariabilität. Budgetalarme existieren, echte Cost-Caps sind begrenzt. Gemäß Skala entspricht dies Score 2: stark verbrauchsbasiert, Kosten bei intensiver Parallelnutzung schwer vorhersehbar, Budgetalarm rudimentär.

💡 Begründung: Unity Catalog bietet die technischen Grundlagen für einen Governed Self-Service Korridor: Schichtenbasierte Zugriffssteuerung, vollständiges Audit-Logging, RLS/CLS-Durchsetzung. Ein explizites, dokumentiertes 'Leitplanken-Konzept' als vorkonfiguriertes Framework fehlt jedoch, weshalb Score 4 (nicht 5) vergeben wird: Self-Service auf Gold-Schicht möglich, Datenkopien kontrollierbar, Audit-Log vorhanden.

💡 Begründung: Es existieren keine Databricks-nativen Tools für BW-Metadaten-Mapping oder automatisierte Strukturüberführung. Partner-Tools wie SNP Glue oder bestimmte SIs bieten hier Unterstützung, aber dies ist nicht Bestandteil der Databricks-Plattform selbst. Gemäß Skala: Score 2 - nur generische ETL-Konnektoren ohne BW-spezifisches Mapping, vollständig manueller Migrationsprozess.

💡 Begründung: Databricks Unity Catalog ist ein Daten-Governance-Layer, kein BI-Metadaten-Synchronisationswerkzeug. Power BI kann über XMLA/DirectLake angebunden werden, Qlik über JDBC/ODBC, aber Metadaten (Measures, Dimensionen, RLS) müssen für jedes Tool separat gepflegt werden. Dies entspricht Score 2 gemäß Skala: Metadaten für Power BI und Qlik separat pflegbar, kein automatischer Abgleich.

💡 Begründung: Multi-Source-Ingestion ist mit Databricks technisch möglich, da Pipelines aus beliebig vielen Quellen lesen können. Native Konfliktauflösungs-Mechanismen oder vorkonfigurierte Dual-Write-Muster für SAP-Szenarien existieren nicht. Eigene Deduplizierungslogik in Transformations-Skripten ist erforderlich. Score 3 gemäß Skala: Dual-Source-Ingestion möglich, erfordert eigene Deduplizierungslogik.

💡 Begründung: Delta Lake Time Travel und APPLY CHANGES INTO ermöglichen SCD2-Muster für Stammdaten und Hierarchien. Der semantische Layer (Unity Catalog / SQL-Views) gibt jedoch standardmäßig nur aktuelle Hierarchiezustände aus; historische Hierarchieabfragen aus BI-Tools erfordern Custom-SQL oder View-Konstruktionen. Score 3 gemäß Skala: Historisierung möglich mit kundenspezifischer Implementierung, semantischer Layer gibt nur aktuelle Hierarchie ohne Zusatzaufwand aus.

💡 Begründung: Es gibt keine out-of-the-box SAP-Rollen-zu-RLS-Synchronisation in Databricks. Zwar können Gruppen aus Entra ID für RLS genutzt werden, aber die spezifische Übersetzung von SAP-Autorisierungsobjekten (Buchungskreise, Werke) in RLS-Policies ist nicht vorgefertigt. Dies entspricht Score 2: vollständig manuelle Pflege auf der Plattform, keine Integration mit SAP-Rollenmanagement.

💡 Begründung: Lakehouse Federation unterstützt externe Datenquellen über JDBC-Konnektoren, SAP HANA ist prinzipiell erreichbar, aber ein produktionsreifer nativer Pushdown für SAP HANA ist nicht dokumentiert. Die Latenz und Optimierung entspricht eher Score 3: Federation ohne Pushdown, höhere Latenz, nicht für zeitkritische Echtzeit-Abfragen optimiert.

💡 Begründung: Databricks ist eine Lakehouse-Plattform und bietet keinerlei Funktionen zum Scannen von Qlik-Applikationen, Analysieren von Qlik-Formeln oder Erstellen von Migrationsabhängigkeitsmatrizen. Score 1 ist korrekt: keine Unterstützung für Qlik-Inventarisierung seitens der Plattform.

💡 Begründung: Databricks SQL Warehouses liefern detaillierte Query-Logs mit Nutzer, Warehouse, Dauer und Scan-Volumen. Attribution auf Tool-Ebene erfordert etwas manuelle Konfiguration (z.B. custom_tags oder User-Agent-Analyse). API-Export ist verfügbar. Score 4 passt: Attribution auf Tool- und Nutzerebene möglich, kein vollintegriertes Chargeback-Modul, aber ausreichend für manuelle Verrechnung.

💡 Begründung: DLT Expectations ermöglichen das Definieren von Fehlerregeln mit Aktionen (drop, fail, warn) und das Routing in Quarantäne-Tabellen als etabliertes Pattern. Alerting und Wiedereinspielung sind konfigurierbar aber nicht out-of-the-box als fertiger Workflow. Score 3 trifft zu: Dead-Letter-Queue als Muster umsetzbar, aber nicht nativ fertig.

💡 Begründung: Delta Lake Time-Travel über SQL ist ein Kernfeature von Databricks und funktioniert ohne proprietäre API. Retentionsdauer ist über DELTA.logRetentionDuration konfigurierbar und kann über 2 Jahre eingestellt werden. Die direkte Nutzung aus Power BI/Qlik erfordert Parameterübergabe in SQL-Abfragen, was geringe Konfigurationsarbeit bedeutet. Score 4 ist angemessen.

💡 Begründung: Databricks hat zertifizierte Entra ID-Integration mit SCIM-Provisioning für automatische Benutzer-/Gruppen-Synchronisation. Unity Catalog nutzt Entra ID-Gruppen für RLS. Vollautomatische SAP-Gruppen-Synchronisation direkt aus SAP-Systemen erfordert jedoch eine zwischengeschaltete Konfiguration (z.B. SAP IAS → Entra ID → Databricks). Score 4: IdP zertifiziert, Gruppen-Claims für RLS nutzbar, SAP-Sync über konfigurierbaren Mechanismus möglich.

💡 Begründung: Das fundamentale Designprinzip von Databricks ist die Trennung von Storage und Compute, wobei der Storage vollständig im Kunden-eigenen Cloud-Account liegt. Alle Daten sind nativ als Parquet/Delta verfügbar ohne Konvertierung. Dies entspricht Score 5 faktisch in technischer Hinsicht; vertragliche Lock-in-Garantien im formellen SLA-Sinne sind marktüblich nicht explizit dokumentiert, was eine Abwertung auf 4 rechtfertigen könnte, jedoch ist die technische Realität eindeutig vendor-lock-in-frei.

💡 Begründung: Unity Catalog unterstützt manuelle Tagging und Kommentare für Datenobjekte sowie Berechtigungssteuerung. Ein dedizierter Zertifizierungs-Workflow mit automatischen Genehmigungsschritten, visuellem Kennzeichnungssystem und technischer Durchsetzung in produktiven Workspaces ist nicht out-of-the-box vorhanden. Score 3: Tagging manuell möglich, kein vollständiger Workflow-Support.

💡 Begründung: DLT bietet Checkpoints und State-Management; Delta MERGE ermöglicht idempotente Upserts. Selektives Reprocessing von Partitionen ist technisch durch konfigurierbares Pipeline-Design realisierbar. Automatische Duplikat-Erkennung via APPLY CHANGES INTO ist für CDC-Szenarien vorhanden. Score 4: konfigurierbar, Idempotenz durch MERGE sichergestellt, manuelle Auslösung über Plattform-Werkzeuge.

💡 Begründung: Databricks bietet keine native Writeback-Lösung für SAP-Systeme. Über JDBC-Konnektoren oder externe APIs ist ein technischer Schreibzugriff möglich, aber Validierungslogik, Freigabe-Workflows und SAP-spezifische Protokolle (RFC, BAPI, OData) sind nicht integriert und erfordern vollständige Eigenentwicklung. Score 2 ist angemessen.

💡 Begründung: Die Plattform bietet generische ETL-Fähigkeiten für Multi-Source-Ingestion und Konfliktauflösung über MERGE-Logik, aber kein dediziertes Harmonisierungs-Framework speziell für SAP BW/S/4HANA-Semantikobjekte. Die Implementierung erfordert manuelle Transformations-Logik. Score 3: generische ETL-Unterstützung vorhanden, aber vollständig manuell zu implementieren, kein dediziertes Framework.

💡 Begründung: Die Plattform bietet manuelle Versionskontrolle via Delta Lake Time Travel und Git-Integration (Databricks Repos), aber keinen integrierten Approval-Workflow mit technischen/fachlichen Reviewer-Rollen oder automatischer Impact-Analyse auf Power BI/Qlik-Artefakte. Dies entspricht Skala-Stufe 2: manuelle Versionskontrolle via Code-Repository, kein nativer Workflow, Rollback nur durch Deployments/Time Travel.

💡 Begründung: Databricks bietet Workload Management Groups in SQL Warehouses, Priority-Queues und die Möglichkeit, separate Warehouses je Verbindungstyp zu konfigurieren. Monitoring ist vorhanden, aber die automatische Echtzeit-Drosselung basierend auf Client-Typ-SLAs ist nicht vollständig nativ. Dies entspricht Stufe 4 der Skala.

💡 Begründung: Die Plattform bietet grundlegende Datenqualitätstests (DLT Expectations, kompatibel mit dbt), aber kein dediziertes Framework für den toolübergreifenden Ergebnisvergleich Qlik vs. Power BI auf Kennzahlenebene mit Abnahmeprotokoll. Eigene Skripte und ein manueller Prozess sind erforderlich, was Stufe 3 der Skala entspricht.

💡 Begründung: Delta Lake Schema Evolution (additive Änderungen automatisch via mergeSchema) und Unity Catalog Lineage ermöglichen eine manuelle Impact-Analyse, aber es fehlt ein automatisches Schema-Change-Detection-Mechanismus für externe SAP-Quellen sowie eine automatisierte End-to-End-Propagation. SAP-CDC-Konnektoren sind Partner-abhängig ohne native Schema-Registry-Integration. Dies entspricht Stufe 3 der Skala: Schema-Versionierung in Metadaten-Katalog, manuelle Impact-Analyse, einfache Fälle unterstützt, komplexe Änderungen erfordern manuellen Eingriff.

💡 Begründung: Die Kombination aus Delta Lake als offenem, universellen Speicherformat, Unity Catalog für Multi-Tenancy und organisationsweite Zugriffskontrolle sowie der Unterstützung aller Datentypen erfüllt diese Anforderung auf Best-in-Class-Niveau. Databricks gilt als Begründer des Lakehouse-Konzepts.

💡 Begründung: Die native Unterstützung der Medallion-Architektur ist ein explizit genanntes Feature; DLT ist speziell für dieses Schichtenmodell konzipiert. Dies geht über die bloße Unterstützung hinaus und ist ein zentrales Alleinstellungsmerkmal der Plattform – Best-in-Class.

💡 Begründung: Databricks ist der Schöpfer von Delta Lake, dem führenden Open Table Format. Mit UniForm wird zusätzlich Iceberg- und Hudi-Kompatibilität geboten. Dies ist ein Kernkompetenzbereich – eindeutig Best-in-Class.

💡 Begründung: Im Vergleich zu dedizierten Low-Code-ETL-Tools (Azure Data Factory, Talend, Informatica) fehlt Databricks eine grafische Pipeline-Oberfläche für Nicht-Entwickler erheblich. DLT reduziert Komplexität, ist aber kein Low-Code-Tool. Score 2 ist angemessen – rudimentäre Ansätze vorhanden, aber erhebliche Lücken für die Zielgruppe Nicht-Entwickler.

💡 Begründung: Die native APPLY CHANGES INTO-Funktion in DLT ist ein starkes CDC-Feature für die Zielseite. Für die Quellseite (Datenbanklog-Lesen) sind externe Konnektoren/Partner nötig, was eine leichte Einschränkung darstellt. Score 4 ist gerechtfertigt – übertrifft Mindestanforderung, aber nicht vollständig end-to-end nativ.

💡 Begründung: Lakehouse Federation ist ein ausgereiftes Feature für federierten Zugriff, und externe Storage-Integrationen sind gut entwickelt. Einschränkungen bestehen bei der Breite der unterstützten externen Quellen im Vergleich zu dedizierten Data-Virtualization-Tools, daher Score 4 statt 5.

💡 Begründung: Spark Structured Streaming ist eine ausgereifte und bewährte Streaming-Technologie, die gut in die Plattform integriert ist. Für Ultra-Low-Latency-Anforderungen (<1s) gibt es Einschränkungen gegenüber spezialisierten Systemen wie Apache Flink. Score 4 ist angemessen.

💡 Begründung: Kollaborative Multi-Language-Notebooks sind ein Kernkompetenzbereich von Databricks mit jahrelanger Entwicklung. Die Funktionalität (gleichzeitige Bearbeitung, Multi-Language, Git-Integration, Versionierung) ist Best-in-Class und übertrifft viele Konkurrenten.

💡 Begründung: Unity Catalog ist ein dediziertes, ausgereiftes Produkt für Data Governance mit umfangreichen Funktionen für Metadaten, Zugriffskontrolle, Audit, Lineage und Katalogisierung. Als zentrales Differenzierungsmerkmal von Databricks eindeutig Best-in-Class.

💡 Begründung: Automatische Column-Level Lineage ist ein explizit genanntes und gut dokumentiertes Feature von Unity Catalog. Die Kombination aus Automatisierung, Spaltenebene und plattformweiter Abdeckung rechtfertigt Score 5 – Best-in-Class.

💡 Begründung: Time Travel ist ein fundamentales Delta-Lake-Feature, das seit den frühen Versionen verfügbar ist und als Industriestandard gilt. Volle Unterstützung für Abfrage, Vergleich und Wiederherstellung historischer Versionen – eindeutig Best-in-Class.

💡 Begründung: Audit Logging ist gut ausgebaut und über System Tables direkt abfragbar. Eine leichte Einschränkung besteht bei der nativen, manipulationssicheren Speicherung der Logs (abhängig von Cloud-Provider-Kontrollen) und beim vorgefertigten Compliance-Reporting für spezifische Regularien. Score 4 ist konservativ angemessen.

💡 Begründung: Die Kombination aus Column Masking, Row Filters und Dynamic Views im Unity Catalog entspricht Best-in-Class-Niveau: zentral verwaltet, ohne Datenduplikate, mit automatischer Durchsetzung auf Query-Ebene – volle 5 Punkte gerechtfertigt.

💡 Begründung: Grundlegende Tagging-Funktionalität ist vorhanden (Anforderungsminimum erfüllt), jedoch fehlen automatisierte Klassifizierungs-Workflows, native Integration von Regulatorik-Frameworks und automatische Policy-Durchsetzung auf Basis von Sensitivity Labels. Score 3 (ausreichend, erfüllt das Minimum).

💡 Begründung: Die Plattform deckt den gesamten ML-Lifecycle ab – Experiment-Tracking, Model Registry, Serving, Feature Store und AutoML – und gilt als Best-in-Class. Score 5 ist eindeutig gerechtfertigt.

💡 Begründung: NL-Querying und KI-Code-Assistenz sind vorhanden und funktional (übertreffen das Minimum), aber die Reife für echte Self-Service-Nutzung ohne technisches Wissen ist noch nicht Best-in-Class im Vergleich zu spezialisierten BI-Tools. Score 4 angemessen.

💡 Begründung: Native BI-Funktionalität ist vorhanden und deckt das Minimum ab, ist aber primär als Ergänzung und nicht als vollständiger Ersatz für BI-Tooling gedacht. Fachbenutzer ohne technischen Hintergrund werden erhebliche Einschränkungen erfahren. Score 3 (ausreichend, erfüllt das Minimum).

💡 Begründung: Native Git-Integration ist tief in die Plattform eingebettet, unterstützt alle gängigen Git-Provider und deckt Notebooks, Pipelines und Konfigurationen ab. Dies entspricht Best-in-Class im Bereich Datentechnologie. Score 5.

💡 Begründung: Die CI/CD-Integration ist stark und gut durchdacht über DABs und REST API, erfordert aber externe CI/CD-Systeme für vollständige Pipelines. Dies übertrifft das Minimum deutlich, ist aber nicht vollständig self-contained. Score 4.

💡 Begründung: System Tables und integrierte Monitoring-Funktionen decken Ressourcen, Kosten und Nutzung gut ab und übertreffen das Minimum. Jedoch erfordert ein vollständiges Monitoring-Setup oft eigene Dashboards auf Basis der System Tables, was etwas Eigenleistung erfordert. Score 4.

💡 Begründung: Die Plattform unterstützt REST-APIs, OData, ODBC/JDBC und native SAP-Integrationen mit guter Dokumentation auf dem SAP Help Portal. Middleware-Unterstützung über SAP Integration Suite (CPI/API-Management) ist möglich. Allerdings sind nicht alle Frontend-Funktionalitäten vollständig als API konsumierbar, und einige Integrationen erfordern noch Konfigurationsaufwand, was einen Score von 4 statt 5 rechtfertigt.

💡 Begründung: Die Plattform bietet Task-Monitoring und Logs für Datenpipelines und Remote-Table-Verbindungen, jedoch kein dediziertes, umfassendes Interface-Monitoring mit Alerting und Diagnostics out-of-the-box. Für vollständiges Monitoring wird typischerweise SAP Cloud ALM oder externe Observability-Tools benötigt, was dem Niveau 'Basic monitoring via logs' entspricht und einen Score von 3 rechtfertigt.

💡 Begründung: Datasphere unterstützt benutzerdefinierte Rollenzuweisungen innerhalb von Spaces sowie vordefinierte Standardrollen und Datenzugriffskontrollen (Data Access Controls). Granulare Pfad-/Policy-Kontrolle im ABAC-Sinne ist nicht vollständig ausgeprägt, daher Score 4 statt 5.

💡 Begründung: SAP BTP IPS bietet vollständige SCIM 2.0-Unterstützung für ereignisgesteuerte User- und Gruppen-Lifecycle-Management, was exakt dem 5-Punkte-Kriterium entspricht. Die Integration mit Azure AD/EntraID via SCIM ist dokumentiert und produktiv verfügbar.

💡 Begründung: Die Selbstkonfiguration beider Protokolle (OIDC und SAML 2.0) ist über das SAP BTP IAS Self-Service-Portal möglich und gut dokumentiert, was dem 5-Punkte-Kriterium 'Self-Service for OIDC & SAML' vollständig entspricht.

💡 Begründung: Das Space-Konzept von Datasphere entspricht dem 5-Punkte-Kriterium 'Full Logical Multi-Tenancy' mit dedizierten isolierten Einheiten, eigenen Benutzern, Gruppen und Berechtigungen. Cross-Space-Zugriff ist kontrolliert und konfigurierbar.

💡 Begründung: Als SaaS-Lösung mit fest eingebautem SAP HANA Cloud-Backend entspricht Datasphere dem 2-Punkte-Kriterium 'Embedded DB Only' aus Kundenperspektive – keine Wahlmöglichkeit bei der Metadaten-Datenbank, obwohl HANA Cloud selbst ein robustes System ist.

💡 Begründung: Das Produkt bietet keine native Flexibilität bei der Wahl des Storage-Backends für Kerndatenobjekte. S3/Azure Blob sind nicht als alternatives primäres Backend wählbar. Externe Quellen können angebunden werden, aber das entspricht nicht dem Kriterium 'Storage Backend Flexibility', daher Score 2.

💡 Begründung: Es gibt keine dokumentierten, umfassenden automatisierten Policy-Engines für Archivierung oder regelbasierte Bereinigung im Sinne der Skala. Einfache Datenverwaltung ist möglich, aber der Automatisierungsgrad ist eingeschränkt, was Score 2 'Manual Cleanup via API/Scripts' am nächsten kommt.

💡 Begründung: Gemäß Bewertungsskala entspricht 'PaaS oder SaaS Only ohne On-Premise-Option' dem Score 1. SAP Datasphere bietet keine On-Premise-Variante und kein vollständig selbst verwaltetes PaaS-Deployment außerhalb von SAP BTP.

💡 Begründung: Für ein SaaS-Produkt entfallen Hardware-Anforderungen beim Kunden komplett – minimaler Footprint aus Kundenperspektive. Score 5 ist gerechtfertigt, da kein lokaler Footprint benötigt wird, obwohl Containerisierung für den Kunden nicht konfigurierbar ist.

💡 Begründung: SaaS-Onboarding über das SAP BTP Cockpit entspricht dem 5-Punkte-Kriterium 'Fully Automated (Single Command/Wizard)' – der Kunde muss keine manuelle Installation durchführen, alles wird automatisch durch SAP provisioniert.

💡 Begründung: Es gibt keinen nativen Replikations- oder Föderationsmechanismus zwischen SAP Datasphere-Instanzen in verschiedenen Regionen. Der Secure Data Sharing-Mechanismus ist kein echter Multi-Location-Deployment-Ansatz. Score 3 als Proxy-basierte/eingeschränkte Lösung erscheint angemessen.

💡 Begründung: HANA Cloud In-Memory-Backend ist eine der leistungsstärksten OLAP-Engines auf dem Markt, was einen hohen Score rechtfertigt. Score 4 statt 5, da SaaS-bedingte Ressourcenlimits und mögliche Tuning-Anforderungen bei sehr großen Workloads existieren.

💡 Begründung: HANA Cloud bietet starke Concurrency-Mechanismen und elastische Skalierbarkeit im SaaS-Betrieb. Es gibt keine vollständig selbstgesteuerte Auto-Scaling-Option für Kunden, was einen Abzug gegenüber Score 5 rechtfertigt. Für die meisten Enterprise-Lasten ist die Leistung gut, daher Score 4.

💡 Begründung: Replication Flows und lokale Datenmaterialisierung helfen bei verteilten Szenarien, aber spezifische Low-Latency- oder Edge-Caching-Funktionen für entfernte Standorte sind begrenzt. Das entspricht einer moderaten Wirksamkeit gemäß Skala, daher Score 3.

💡 Begründung: Die Plattform deckt den Großteil der administrativen und operativen Konfiguration per UI ab (Spaces, Rollen, Flows). Für tief gehende Transformationen ist SQL erforderlich. Dies entspricht Score 4 gemäß der Skala.

💡 Begründung: Gute API-basierte Integration ist möglich, aber native Erweiterungspunkte für Kernproduktverhalten sind eingeschränkt. Das entspricht Score 3 der Skala ('Good API-based integration possible, but limited native extension points').

💡 Begründung: Starkes RBAC mit externer Identitätsintegration und Space-basierter Governance erfüllt die Anforderungen an Offshore-Kollaboration gut. Explizite 'Guest'-Benutzer-Konzepte sind weniger prominent, daher Score 4 statt 5.

💡 Begründung: Die Erweiterbarkeit ist hauptsächlich API-basiert und durch BTP-Integration möglich, aber ohne tiefes natives Extension-Framework. Das entspricht Score 3 ('Mostly API-based integration and automation, but limited native extension points').

💡 Begründung: Zentralisierte Kontrollstrukturen und API-Automatisierungsmöglichkeiten entsprechen Score 4. Einige komplexe Cross-Tenant-Szenarien können noch manuelle Aufwände erfordern, was eine Bewertung auf 5 verhindert.

💡 Begründung: Als vollständig proprietäres SaaS-Produkt ohne Open-Source-Komponenten auf Produktkern-Ebene entspricht dies klar Score 1 der Skala ('No source code availability for customer review/change').

💡 Begründung: Gutes, transparentes Release-Modell mit SAP-geführten Updates und Release Notes entspricht Score 4. Kunden müssen dennoch eigene Anpassungen und Datenmodelle nach Updates validieren, was Score 5 verhindert.

💡 Begründung: Starke Recovery-Mechanismen durch HANA Cloud HA und SAP BTP-Infrastruktur. Kunden haben jedoch begrenzte direkte Kontrolle über HA-Konfigurationen im SaaS-Modell, was Score 4 statt 5 rechtfertigt.

💡 Begründung: Low-Downtime-Upgrades sind im SaaS-Modell der Regelfall, da SAP als Betreiber Rolling-Updates durchführt. Gelegentliche kurze Wartungsfenster können dennoch auftreten, was Score 5 verhindert; Score 4 ist angemessen.

💡 Begründung: Publizierte, formale SLAs für den SaaS-Betrieb entsprechen Score 4 ('Good published availability commitment for managed offering(s)'). Die genauen SLA-Werte können je nach Vertrag variieren, was eine Bewertung auf 5 verhindert.

💡 Begründung: Die Plattform ist nicht so intuitiv wie reine Self-Service-Tools; typische Nutzer benötigen Schulung für tägliche Aufgaben, was Skala-Wert 3 entspricht ('some training/documentation needed for daily tasks').

💡 Begründung: Fiori sorgt für eine einheitliche UX-Sprache, was Wert 4 rechtfertigt ('Consistent UX with useful customization options'); tiefgreifendes Enterprise-Rebranding ist eingeschränkt, daher kein Score 5.

💡 Begründung: Es gibt grundlegende In-Produkt-Hilfe, aber für komplexe Aufgaben wird primär auf externe Dokumentation verwiesen, was Skala-Wert 3 entspricht ('Basic documentation-driven guidance, limited in-product assistance').

💡 Begründung: Es gibt eine gute Passung für technische Rollen, aber für Business-Endanwender entstehen Reibungspunkte, was eher Wert 3 ('Adequate fit with some friction in common tasks') als 4 entspricht.

💡 Begründung: Basisproduktivitätsfunktionen sind vorhanden, aber umfassende Keyboard-Navigation oder tiefgreifende Power-User-Unterstützung ist begrenzt, was Skala-Wert 3 entspricht ('Basic productivity functions available').

💡 Begründung: Die Anpassungsmöglichkeiten sind auf den SAP-Fiori-Basisrahmen beschränkt und gehen über wenige Theme-Optionen nicht wesentlich hinaus, was Skala-Wert 2 ('Limited personalization options') entspricht.

💡 Begründung: Als Enterprise-SAP-Produkt ist breite Mehrsprachigkeit und Lokalisierung ein Kernmerkmal; praktische Locale/Zeit-Einstellungen sind vorhanden, was Wert 4 rechtfertigt ('Good localization support with user locale/time preferences').

💡 Begründung: Fiori bringt eine solide Accessibility-Basis mit, aber bei komplexen visuellen Designern (z. B. Datenfluss-Editor) bestehen bekannte Lücken, was Skala-Wert 3 ('Moderate support with some gaps') rechtfertigt.

💡 Begründung: Das Produkt bietet native Remote-Table-Technologie für virtuellen Zugriff ohne Datenkopie sowie API-basierte Integration zu führenden Quellsystemen. Kleinere Einschränkungen bestehen, da Replikation für Performance-Szenarien oft dennoch empfohlen wird und die vollständige Durchsetzung als SSOT von der Implementierung abhängt – daher Score 4 statt 5.

💡 Begründung: EU-Rechenzentren inklusive Deutschland sind verfügbar, und die bevorzugten Hyperscaler Azure und AWS werden unterstützt. Leichte Einschränkungen bestehen hinsichtlich der Wahlfreiheit zwischen Hyperscalern je nach BTP-Service-Verfügbarkeit in spezifischen Regionen, weshalb Score 4 (gute regionale Abdeckung mit kleineren Einschränkungen) angemessen ist.

💡 Begründung: Die Verschlüsselung ist nach allgemeinem Produktwissen Standard und deckt beide Dimensionen (at rest, in transit) ab. Da das Produkt als Managed SaaS/BTP-Service betrieben wird, sind einige infrastrukturelle Aspekte hyperscaler-abhängig und die Konfiguration von Customer-Managed Keys ist teilweise zusätzlich einzurichten – Score 4 ist daher konservativ angemessen.

💡 Begründung: SAP ist als globaler Enterprise-Anbieter gut für DSGVO/BDSG aufgestellt, stellt Subprozessorlisten bereit und bietet Löschmechanismen. Da spezifische BDSG-Nachweise und Details zu Nutzerprofil-Datenstrukturen nicht vollständig öffentlich dokumentiert sind und ggf. kundenspezifische Konfiguration erfordern, ist Score 4 (gute Compliance-Postur mit kleineren Einschränkungen) angemessen.

💡 Begründung: SAP weist für seine Cloud-Plattform BTP nachweislich ISO 27001 sowie zahlreiche weitere Sicherheits- und Datenschutzzertifizierungen auf, die im SAP Trust Center öffentlich einsehbar sind. Dies entspricht klar der Score-5-Definition (ISO 27001 plus zusätzliche relevante Zertifizierungen).

💡 Begründung: Die Plattform unterstützt API-basierten Datenaustausch sowie manuelle Funktionen, jedoch sind einige fortgeschrittene Massenänderungs- oder Excel-Upload-Szenarien im Vergleich zu spezialisierten Tools eingeschränkt. Score 4 (starke Export-/Import-Unterstützung mit kleinen Einschränkungen) ist daher angemessen.

💡 Begründung: Das Produkt basiert auf proprietären SAP-Technologien (HANA In-Memory, BW-Objekte, SAP-spezifischer semantischer Layer) und ist eng mit SAP BTP und SAP Analytics Cloud verknüpft. Obwohl ODBC/JDBC/OData-Schnittstellen existieren, überwiegt der Vendor-Lock-in deutlich. Laut Skala entspricht das Score 2 ('Strong platform or vendor dependency').

💡 Begründung: Die Verfügbarkeit von qualifizierten SAP-Datasphere-Spezialisten ist durch die kurze Produktlaufzeit noch eingeschränkt, allerdings können erfahrene SAP BW/HANA-Experten zügig eingearbeitet werden. Dies entspricht Score 3 ('Adequate capability with some continuity risk').

💡 Begründung: Die SaaS-Bereitstellung reduziert Infrastruktur-Vorlaufzeiten, jedoch ist der fachliche Aufbau (Datenmodellierung, Governance, SAP-Konnektivität) komplex. Dies entspricht Score 3 ('Moderate lead time') – schnell provisioniert, aber nicht sofort voll produktiv.

💡 Begründung: SAP und sein Partnernetzwerk (Deloitte, Accenture, Capgemini etc.) haben nachgewiesene Erfahrung mit Enterprise-Kunden. Datasphere-spezifische Tiefenexpertise ist noch limitiert, aber das breite SAP-Skill-Portfolio gleicht dies aus. Score 4 ('Strong supplier capability') ist gerechtfertigt.

💡 Begründung: SAP ist ein DAX-Konzern mit globaler Marktpräsenz und Datasphere ist das strategische Herzstück der SAP-Datenstrategie. Dies entspricht klar Score 5 ('Very large and low-risk supplier base').

💡 Begründung: SAP hat eine der breitesten globalen Präsenzen unter Enterprise-Software-Anbietern mit regionalen Support-Teams, lokalem Partnernetzwerk und mehrsprachigem Support. Dies entspricht Score 5 ('Strong worldwide rollout and support capability').

💡 Begründung: Die enge Integration mit S/4HANA und die BW-Bridge machen Datasphere zum idealen Begleiter einer S/4HANA-Transformation. Positive Abhängigkeiten überwiegen klar, was Score 5 ('Strong positive alignment to strategic programs') rechtfertigt.

💡 Begründung: SAP BTP und Datasphere folgen einem kontinuierlichen Delivery-Modell mit regelmäßigen Updates, was agile Implementierungsprojekte begünstigt. Die Plattform-Reife und Dokumentation erlauben gute agile Projektstrukturierung. Score 4 ('Good modern delivery fit') ist angemessen.

💡 Begründung: Die Plattform ist zwar SaaS-basiert, aber die konzeptionelle Komplexität (Spaces, Semantic Layer, BW-Migration, Berechtigungskonzepte) treibt den Setup-Aufwand nach oben. Laut Skala entspricht das hohen Setup-Kosten → Score 2.

💡 Begründung: Trotz Low-Code-Designer ist die Implementierung aufgrund der SAP-spezifischen Paradigmen (Analytic Models, Business Layer, SQL Script) komplex und erfordert teure SAP-Spezialisten. Skala ordnet dies als hohen Implementierungsaufwand ein → Score 2.

💡 Begründung: SaaS reduziert den operativen Aufwand merklich gegenüber On-Premise, jedoch ist der Day-2-Betrieb (Administration, User-Management, Performance-Tuning auf HANA Cloud) nicht trivial. Das entspricht einem moderaten Betriebsaufwand → Score 3.

💡 Begründung: Das verbrauchsbasierte Capacity-Unit-Modell kombiniert mit Add-on-Kosten (BW Bridge, SAC, BTP) macht die Gesamtkostenplanung schwierig und intransparent. Laut Skala entspricht das einem teuren oder intransparenten Modell → Score 2.

💡 Begründung: Insbesondere in SAP-zentrierten Landschaften sind die Folgejahrseinsparungen durch Konsolidierung, Live-Access und Wegfall von ETL-Redundanzen erheblich. Das entspricht einem starken Effizienznutzen laut Skala → Score 4.

💡 Begründung: SAP ermöglicht es, First-Level-Support durch autorisierte Partner (Value Added Resellers, SAP-Partner) zu organisieren, die als erste Anlaufstelle fungieren. Dies ist ein starkes Modell, jedoch ist die Flexibilität bei der Hotline-Integration mit eigenen Systemen nicht vollständig dokumentiert, daher Score 4 statt 5.

💡 Begründung: SAP bietet gut strukturierte Second-Level-Support-Pfade über Partner und direkt über SAP-Support an. Die Incident-Weiterleitung an SAP-Experten ist klar definiert. Score 4, da die Zusammenarbeit solide ist, aber individuelle SLA-Anpassungen auf dieser Ebene limitiert sein können.

💡 Begründung: SAP hat als großes Softwareunternehmen einen etablierten Third-Level-Prozess mit direktem Zugang zu Engineering-Teams, definierten Patch- und Note-Prozessen (SAP Notes, KBAs) und klaren Eskalationspfaden für kritische Bugs. Dies entspricht einem starken Engineering-backed 3rd-Level-Prozess (Score 5).

💡 Begründung: SAP bietet ein sehr ausgereiftes Enterprise-Support-Konzept mit globaler Abdeckung, Mehrsprachigkeit, definierten Supportpaketen und der Möglichkeit zur Ticket-Bridge-Integration via APIs. Score 4 statt 5, da einige fortgeschrittene Integrationsszenarien (z.B. vollautomatische Ticket-Bridge) konfigurationsaufwändig sein können.

💡 Begründung: SAP dokumentiert Response-Zeiten klar für verschiedene Prioritätsstufen im Rahmen von Enterprise Support. Die Lösungszeiten (nicht nur Reaktionszeiten) sind weniger starr definiert und hängen von der Komplexität ab. Score 4, da Response-SLAs stark sind, aber Lösungszeit-SLAs weniger verbindlich.

💡 Begründung: SAP hat ein starkes globales Support-Netzwerk mit 24/7-Abdeckung für kritische Prioritäten. Regionale Unterschiede existieren bei niedrigeren Prioritäten. Score 4, da 24/7 nur für hohe Prioritäten garantiert ist und nicht durchgängig für alle Ticketkategorien gilt.

💡 Begründung: SAP verfügt über eines der umfangreichsten Enterprise-Trainingsökosysteme: kostenlose Online-Kurse (openSAP), kostenpflichtige Zertifizierungen, rollenspezifische Lernpfade, Hands-on-Tutorials in SAP Learning Hub, Community-Ressourcen und eine ausführliche Produktdokumentation auf help.sap.com. Dies entspricht 'Extensive training and documentation' (Score 5).

💡 Begründung: Als SAP-eigene Plattform bietet Datasphere die tiefste native SAP-Integration über alle gängigen SAP CDC-Mechanismen (SLT, ODP, HANA SDI/SDA, CDS Views). Die Replication Flows unterstützen Delta-Replikation out-of-the-box. Dies entspricht vollständig der Skalendefinition für Score 5.

💡 Begründung: Die SAP BW Bridge ist ein explizit genanntes Kernfeature von Datasphere, das genau für diesen Koexistenz- und Migrationspfad entwickelt wurde. Semantische Mappings, paralleler Betrieb und ein strukturierter Migrationspfad sind dokumentiert – entspricht Score 5 der Skala.

💡 Begründung: Datasphere setzt auf ODBC/JDBC und OData als Konnektivitätsmechanismen, nicht auf XMLA/MDX. Ein XMLA-Endpunkt ist nicht als Standardfeature bekannt. Da XMLA als harte Pflichtanforderung definiert ist und Datasphere diese nicht nativ bietet, ist Score 2 (nur über Drittanbieter-Umwege oder nicht verfügbar) angemessen; konservative Bewertung mangels gegenteiliger Dokumentation.

💡 Begründung: ODBC/JDBC-Konnektivität ist explizit als bekanntes Feature für Dritttools wie Qlik dokumentiert. AAD-Integration ist über SAP BTP Identity-Mechanismen möglich, aber möglicherweise manuell konfigurierbar. Eine spezifische Qlik-Zertifizierungsdokumentation ist nicht im gleichen Maß wie bei SAP Analytics Cloud vorhanden, daher Score 4 statt 5.

💡 Begründung: Der ODBC/JDBC-Zugang ermöglicht technisch einen direkten Datenbankzugriff mit Pushdown-Potenzial durch HANA Cloud, jedoch ohne vollständigen, offiziell dokumentierten Qlik-DirectQuery-Pushdown-Support. Teilweise Client-seitige Verarbeitung in Qlik ist bei komplexen Operationen zu erwarten. Score 3 ist konservativ und korrekt.

💡 Begründung: Das Backend von Datasphere ist SAP HANA Cloud, ein proprietäres In-Memory-Spaltenspeichersystem. Delta Lake als Open-Source-Protokoll wird nicht nativ unterstützt. Dies entspricht eindeutig Score 1 der Skala – proprietäres Speicherformat ohne offenes Delta-Lake-Protokoll.

💡 Begründung: Datasphere bietet Spaces zur logischen Trennung, Lineage-Tracking und Data Quality Management als Einzelfeatures, jedoch kein dediziertes Medallion-Architektur-Template mit automatischen Bronze/Silver/Gold-DQ-Gates. Die Implementierung erfordert signifikanten manuellen Konfigurationsaufwand, was Score 3 entspricht.

💡 Begründung: Der semantische Layer ist primär für SAP Analytics Cloud optimiert (Score wäre 5 dort). Für Power BI und Qlik existieren Konnektoren, aber nicht alle Tools können gleichwertig darauf zugreifen ohne redundante Definitionen. XMLA fehlt (wichtig für volle Multi-Tool-Fähigkeit). Score 3 ist angemessen.

💡 Begründung: Als strategische Datenplattform von SAP mit tiefster nativer SAP-Integration, Currency & Unit Conversion, Hierarchy Management und BW-Bridge entspricht Datasphere vollständig dem Score 5. SAP-spezifische Semantik (Buchungskreise, CO-Objekte, FI-Strukturen) ist Kernkompetenz der Plattform.

💡 Begründung: Datasphere ist kein Microsoft Fabric-Produkt, daher kein DirectLake. DirectQuery ist technisch möglich über HANA-Konnektoren, aber vollständiger Pushdown und Sub-3s-Performance bei >1TB erfordern manuelle Aggregations-Layer-Konfiguration. Score 3 entspricht der Skalenbeschreibung für dieses Szenario.

💡 Begründung: Power BI Endorsed/Certified Content ist ein Feature das im Power BI Service verwaltet wird, nicht in Datasphere. Während Datasphere eigene Governance-Features hat, fehlt eine direkte Integration des Power BI Zertifizierungsprozesses mit DQ-Gates aus Datasphere. Manual Endorsed-Prozesse sind möglich, aber keine Certified-Integration. Score 2 ist konservativ korrekt.

💡 Begründung: HANA Cloud bietet Workload-Management-Mechanismen, aber dedizierte per-Workload-Typ-Isolation mit garantierten SLAs speziell für Qlik vs. Power BI ist nicht als offiziell dokumentiertes Feature bekannt. Grundlegende Priorisierung ist konfigurierbar, vollständige Isolation nicht garantiert. Score 3 ist angemessen.

💡 Begründung: Gemäß Skala entspricht Score 2 'nur generische BI-Migrationsleitlinien ohne Qlik-Spezifik; kein Tool-Support'. SAP Datasphere adressiert die Datenschicht und unterstützt beide Tools als Konsumenten, bietet aber keine Qlik-zu-Power-BI-Migrationsmethodik oder spezifische Konvertierungstools. Eine Eigenentwicklung des Migrationsprozesses wäre weitgehend notwendig.

💡 Begründung: Score 3 passt: Lineage auf Tabellenebene ist vorhanden, der Data Catalog erfasst Metadaten automatisch über die Datasphere-Schichten. Feldgranulare Lineage bis zum BI-Report-Feld sowie automatische Impact-Analyse bei Schema-Änderungen sind nicht als native Kernfunktionalität dokumentiert. BCBS 239-konformer Export ist nicht explizit ausgewiesen.

💡 Begründung: Score 4 ist angemessen: Datasphere bietet starke Data Space-basierte Isolation, Data Access Controls für RLS und CLS auf Consumption-Ebene sowie SAP BTP-Integration für Rollenmanagement. Eine vollautomatische Synchronisation aus SAP-Autorisierungsobjekten (z.B. S_TABU_DIS) ohne manuelle Konfiguration ist nicht dokumentiert, daher kein Score 5.

💡 Begründung: Score 3 trifft zu: REST-API und DWC CLI ermöglichen Automation, jedoch ohne offiziellen Terraform- oder Bicep-Provider. Die Umgebungspromotion Dev/Test/Prod ist über APIs und Skripte realisierbar, erfordert aber erheblichen Eigenaufwand. Einige Konfigurationsaspekte bleiben UI-gebunden.

💡 Begründung: Score 3 ist korrekt: Grundlegendes DQ-Monitoring ist vorhanden (Null-Checks, Profiling, Validierung). Für SAP-spezifische Regeln wie FI-CO-Saldenabstimmung ist Custom-Code notwendig. Ein dediziertes DQ-Dashboard mit Trend-Analyse und automatischer Eskalationsfunktion gemäß Score 4/5 ist nicht als Standardfeature dokumentiert.

💡 Begründung: Score 3: Historisierung großer Datenmengen ist über HANA Cloud möglich, und HANA unterstützt Partitionierung. Jedoch fehlen native Delta-Table-Konzepte, Z-Order-Clustering und automatisches Vacuuming wie bei Databricks. Bei sehr großen Transaktionsdatenmengen (>1 Mrd. Datensätze) können manuelle Optimierungsmaßnahmen erforderlich werden.

💡 Begründung: Score 4 trifft zu: Das Modell ist überwiegend kapazitätsbasiert mit transparenten Elementen, Budgetalarme sind über BTP verfügbar, und es gibt Differenzierungen nach Nutzertypen. Ein detaillierter TCO-Rechner speziell für Qlik/Power BI Parallelnutzungsszenarien ist nicht öffentlich dokumentiert, daher kein Score 5.

💡 Begründung: Score 4 passt: Das Space-Konzept mit rollenbasierten Zugriffskontrollen, Business Layer-Exposition und Data Access Controls ermöglicht governed Self-Service auf der Consumption-Ebene. Ein explizit dokumentiertes 'Self-Service-Korridor-Konzept' mit Datenspreizungskontrolle auf Score-5-Niveau ist nicht vollständig ausgewiesen, aber die Grundmechanismen sind stark.

💡 Begründung: Score 4 ist angemessen: Die BW Bridge ist ein speziell entwickeltes Feature für die BW-Migration, das Metadaten und Objekte übernimmt und Templates bereitstellt. Eine vollautomatische GUI-gesteuerte Überführung aller BW-Objekte in native Delta-Table-Strukturen (Score 5) ist nicht gegeben; manuelle Nacharbeit bleibt für komplexere Transformationslogiken bestehen.

💡 Begründung: Score 3 trifft zu: Der zentrale semantische Layer existiert und beide Tools können ihn konsumieren. Automatische Drift-Detection oder bidirektionale Metadaten-Propagation bei Änderungen ist nicht als native Funktion dokumentiert. Bei Breaking Changes (z.B. geänderte Measures) müssen beide Tool-Verbindungen manuell validiert werden.

💡 Begründung: Score 3 ist korrekt: Dual-Source-Ingestion ist technisch über Remote Tables und Replication Flows aus mehreren Quellen möglich. Die Harmonisierungs- und Deduplizierungslogik bei parallelen SAP-Quellsystemen muss jedoch in eigenen Transformationsschichten (Data Flows/SQL Views) implementiert werden, ohne native Konfliktauflösungskonfiguration.

💡 Begründung: Score 4 passt: Native zeitabhängige Hierarchien sind explizit als Feature dokumentiert, und der semantische Layer (Analytic Model) unterstützt Hierarchien aus SAP-Systemen. Für vollständige SCD Typ 2/Typ 4 Mechanismen mit transparenter historischer Hierarchieabfrage ohne Zusatzkonfiguration (Score 5) fehlen öffentlich belegte Details; die Implementierung erfordert typischerweise noch minimale Konfiguration.

💡 Begründung: Datasphere bietet native SAP-Authentifizierung und Berechtigungsintegration über BTP, aber die spezifische automatische Synchronisation von SAP-Rollen (z.B. Buchungskreis-Berechtigungen) in Row-Level-Security-Richtlinien ist nicht vollautomatisch. Es sind Eigenentwicklungen oder Konfigurationsarbeiten notwendig, was Skala 3 entspricht.

💡 Begründung: Die Remote-Table-Technologie und der Data Federation-Ansatz von Datasphere erlauben echte Query Federation mit HANA-Pushdown. Für einfache Dashboard-Szenarien ist die Latenz akzeptabel. Bekannte Einschränkungen bei komplexen Cross-Source-Joins sind dokumentiert, was Skala 4 entspricht.

💡 Begründung: Als SAP-Datenplattform hat Datasphere keinen Fokus auf Qlik-Migration. Es gibt kein bekanntes Tool, keine Dokumentation und keine API zur automatisierten Qlik-App-Analyse. Dies entspricht klar Skala 1.

💡 Begründung: Das Monitoring in Datasphere erfasst Abfragen mit Nutzerinformation, aber eine automatische Differenzierung nach verbindendem BI-Tool und automatisiertes Chargeback-Reporting sind nicht nativ vorhanden. Manuelle Log-Analyse und eigene Dashboards wären erforderlich, was Skala 3 entspricht.

💡 Begründung: Das Fehler-Handling in Datenpipelines ist konfigurierbar und erlaubt die Ableitung eines Quarantäne-Musters, aber es gibt keine native Quarantäne-Engine mit automatischer Klassifizierung und komfortablem Wiedereinspielungs-Workflow. Dies entspricht Skala 3.

💡 Begründung: Das Delta Lake Time-Travel-Protokoll ist explizit nicht die Basis von Datasphere (HANA Cloud statt Delta Lake). Historische Auswertungen sind nur über proprietäre HANA-Mechanismen oder manuelle Snapshots möglich, ohne offenen Standard und ohne direkte BI-Tool-Integration per Parameter. Dies entspricht Skala 2.

💡 Begründung: Die Integration von Entra ID als IdP ist dokumentiert und zertifiziert. SAP Cloud Identity Services ermöglicht die Synchronisation von SAP-Gruppen mit Entra ID. Die RLS-Ableitung aus Gruppen-Claims ist möglich, erfordert aber Konfigurationsaufwand. Vollautomatische SCIM-Synchronisation ohne manuelle Pflege ist möglich, aber die SAP-Gruppen-Abbildung braucht initiale Konfiguration. Skala 4 ist angemessen.

💡 Begründung: Da das Backend SAP HANA Cloud (kein Delta Lake) ist, gibt es keinen nativen Parquet/Delta-Export ohne Konvertierung. Technisch ist ein Export möglich, aber er erfordert Konvertierungsschritte. Ein vertraglicher Exit-SLA oder dokumentierter Exitprozess mit offenem Standard ist nicht bekannt. Dies entspricht Skala 2.

💡 Begründung: Datasphere hat explizite Governance-Features mit Rollentrennung, Freigabe-Mechanismen und visueller Kennzeichnung von Objekten. Technische Einschränkungen für nicht-freigegebene Inhalte in produktiven Spaces sind über das Berechtigungskonzept konfigurierbar. Ein vollständiger Workflow mit Audit-Trail auf Niveau 5 ist nicht vollständig nachgewiesen, Skala 4 ist angemessen.

💡 Begründung: Die Plattform unterstützt Delta-Laden und UPSERT-Logik, was partielle Wiederverarbeitung ermöglicht. Native Checkpoint-Mechanismen mit automatischer Partitions-Erkennung und UI-gestütztem Reprocessing sind jedoch nicht dokumentiert. Eigenimplementierung der Idempotenz-Logik ist notwendig, was Skala 3 entspricht.

💡 Begründung: Die enge Integration mit SAP Analytics Cloud (native Live Connection) ermöglicht Planungs-Writebacks über SAP-Standard-Schnittstellen. Über BTP-Integration und OData können auch direkte S/4HANA-Anbindungen konfiguriert werden. Eine native Writeback-UI in Datasphere selbst ist nicht primär vorhanden, aber die Integration ist vollständig dokumentiert, was Skala 4 entspricht.

💡 Begründung: Die BW Bridge ist ein Kerndifferenziator von Datasphere und explizit für diesen Übergangs-Use-Case entwickelt. Die parallele Einspielung aus BW und S/4HANA mit semantischer Harmonisierung ist dokumentiert und produktionsreif. Für automatisierte Konfliktlösung in Randfällen sind manuelle Eingriffe notwendig, was Skala 4 entspricht.

💡 Begründung: Die Skala stuft Stufe 2 als 'nur manuelle Versionskontrolle via Code-Repository; kein nativer Workflow, keine automatische Impact-Analyse, Rollback nur durch Deployments' ein. SAP Datasphere hat Git-Integration (CSN/JSON-Export) und grundlegende Änderungsprotokolle, aber keinen nativen strukturierten Freigabe-Workflow mit konfigurierbaren Reviewer-Rollen. Impact-Analyse auf Power BI- und Qlik-Artefakte ist nicht automatisiert. Das entspricht klar Stufe 2; Stufe 3 würde zumindest Basis-Versionierung mit externem Tool für Genehmigungen voraussetzen, was technisch möglich ist, aber nicht nativ bereitgestellt wird.

💡 Begründung: HANA Cloud bietet Workload-Klassen und grundlegendes Ressourcenmanagement, aber keine automatische toolbasierte Differenzierung zwischen Power-BI-Direktverbindungen und Qlik-ODBC/JDBC-Verbindungen mit konfigurierbaren Priority-Queues. Die Skalierung des HANA Cloud Service bietet gewisse Elastizität, aber kein echtes Workload-Isolation-Feature auf Client-Typ-Ebene. Stufe 3 ('grundlegendes Query-Throttling, keine tool-spezifische Differenzierung, manuelle Konfiguration') trifft am besten zu.

💡 Begründung: Die Plattform bietet Data Quality Management und Lineage, aber kein dediziertes Test-Framework für den Vergleich von BI-Tool-Ausgaben (Qlik vs. Power BI). Stufe 3 würde grundlegende Datenqualitätstests voraussetzen, die als Basis für eigene Vergleichsskripte dienen – dies ist eingeschränkt möglich, aber der Qlik-zu-Power-BI-Vergleich auf Kennzahlenebene erfordert vollständig externe Implementierung. Stufe 2 ('kein dedizierter Vergleichsmechanismus, Validierung durch manuelle Stichproben') ist der realistischere Score, da kein strukturierter Prozess nativ unterstützt wird.

💡 Begründung: Der Data Catalog mit Lineage und die Remote-Table-Technologie ermöglichen eine gewisse Schema-Versionierung und manuelle Impact-Analyse. SAP Datasphere unterstützt additive Schema-Änderungen (neue Felder) in Remote Tables teilweise automatisch, aber komplexe Schemaänderungen (umbenannte Felder, geänderte Schlüssel) erfordern manuelle Anpassungen der nachgelagerten Views und Pipelines. Dies entspricht Stufe 3 ('Schema-Versionierung in Metadaten-Katalog erfasst, Impact-Analyse manuell durchführbar, komplexe Änderungen erfordern Pipeline-Neuaufbau'). Stufe 4 wäre nur erreichbar, wenn automatische Impact-Analyse und klare Tooling-Unterstützung für breaking changes vorhanden wären, was über den bekannten Funktionsumfang hinausgeht.

💡 Begründung: Die Plattform ist primär auf strukturierte/relationale Daten ausgerichtet (HANA-In-Memory-Engine). Unstrukturierte Daten werden nicht nativ verwaltet; es fehlen typische Data-Lake-Features wie Object-Store-Integration auf Basis von S3/ADLS als primäres Speicherziel. Das Minimum (zentraler Speicher, Mandantenfähigkeit via Spaces) ist erfüllt, aber kein vollständiges Unified-Data-Lake-Konzept.

💡 Begründung: Das Schichtendenken ist in Datasphere vorhanden (Remote/Replication Layer, Transformation, Consumption/Analytic Model) und kann als Bronze/Silver/Gold interpretiert werden. Eine explizite, native Medallion-Architektur-Vorlage fehlt jedoch; die Umsetzung erfordert manuelle Konfiguration. Daher erfüllt die Plattform das Minimum, übertrifft es aber nicht wesentlich.

💡 Begründung: HANA Cloud liefert zwar ACID auf relationales Datenbankebene, aber Open Table Formats (Delta Lake, Iceberg, Hudi) als eigenständige File-Based-ACID-Schicht werden nicht nativ unterstützt. Dies ist eine erhebliche Lücke gegenüber modernen Lakehouse-Plattformen. Der Score liegt bei 2: rudimentär, da nur der proprietäre HANA-ACID-Aspekt erfüllt ist.

💡 Begründung: Der integrierte visuelle Designer ist ausgereift und ermöglicht Nicht-Entwicklern die Erstellung von Datenpipelines. Die Konnektorbibliothek deckt SAP-Quellen exzellent ab, ist aber bei Nicht-SAP-Quellen (z.B. SaaS-APIs) eingeschränkter als Best-in-Class-Anbieter wie Fivetran/Matillion. Daher Score 4: gut, übertrifft die Mindestanforderung.

💡 Begründung: Für SAP-Quellen (S/4HANA via SLT, ABAP-basiertes CDC) ist die inkrementelle Replikation stark. Für generische Nicht-SAP-Datenbanken (PostgreSQL, MySQL, Oracle) sind native CDC-Fähigkeiten begrenzt und oft auf externe Tools angewiesen. Das Minimum ist erfüllt, aber kein vollständiges universelles CDC-Framework vorhanden.

💡 Begründung: Die Remote-Table-Technologie und SDI/SDQ ermöglichen föderierte Abfragen auf diverse externe Systeme. Cloud-Speicher (S3, ADLS) sind als Quelle zugänglich. Die Breite der unterstützten Föderationsziele ist gut, aber nicht so universell wie spezialisierte Föderationsplattformen. Score 4 ist gerechtfertigt, da es solide über das Minimum hinausgeht.

💡 Begründung: Echtes Event-Streaming und Stream-Processing sind in Datasphere nicht nativ vorhanden. Zwar gibt es Replication Flows für Near-Real-Time-Replikation aus SAP-Quellen, aber kein natives Streaming-Processing-Framework. Für Streaming muss auf externe Tools (z.B. SAP Event Mesh, Kafka) zurückgegriffen werden. Dies ist eine erhebliche Lücke.

💡 Begründung: Kollaborative Notebooks (Jupyter-Style, PySpark, etc.) sind kein Bestandteil von SAP Datasphere. Die Plattform fokussiert auf SQL-basierte Transformationen und Low-Code-Designer. Für Notebook-Funktionalität wäre SAP Analytics Cloud oder externe Tools (Databricks, JupyterHub) notwendig. Score 1: nicht vorhanden.

💡 Begründung: Datenkatalog, Lineage, Space-basierte Berechtigungen und der semantische Layer bilden ein solides Governance-Framework. Die Integration mit SAP-Enterprise-Berechtigungskonzepten ist stark. Einschränkungen bestehen bei der plattformübergreifenden Governance externer Assets (non-SAP) und bei fortgeschrittenen Data-Quality-Policies. Score 4 ist angemessen.

💡 Begründung: Die integrierte Lineage erfasst Metadaten und Abhängigkeiten zwischen Flows, Views und Modellen automatisch. Eine tiefgehende Spaltenebenen-Lineage (column-level lineage) ist in SAP Datasphere jedoch nicht vollständig ausgebaut im Vergleich zu spezialisierten Governance-Tools wie Collibra oder Alation. Das Minimum ist erfüllt, Score 3.

💡 Begründung: Time Travel als automatische, transparente Funktion (wie in Delta Lake, Snowflake oder Databricks) ist in SAP Datasphere nicht nativ vorhanden. HANA Cloud bietet begrenzte Audit-Table-Mechanismen, aber kein echtes Time-Travel-Feature für beliebige Zeitpunktabfragen. Dies ist eine erhebliche Lücke. Score 2: rudimentär.

💡 Begründung: Der SAP Audit Log Service auf BTP-Ebene protokolliert relevante Aktivitäten und unterstützt DSGVO/SOX-Anforderungen grundlegend. Allerdings fehlt ein integriertes, anwendungsfreundliches Compliance-Reporting-Dashboard direkt in Datasphere; Reporting muss extern aufgebaut werden. Das Minimum ist erfüllt, aber kein Best-in-Class-Niveau. Score 3.

💡 Begründung: Die Plattform bietet ausgereifte Mechanismen für Row-Level Security (Data Access Controls mit Filterbedingungen) und Column-Level Security (Spaltenberechtigungen auf Objektebene) auf Enterprise-Niveau. Die Integration in den semantischen Layer ist stark. Für ein Best-in-Class-Rating (5) fehlt etwas im Vergleich zu spezialisierten Security-Plattformen wie Privacera oder Immuta, da dynamische Datenmaskierung und attribute-basierte Zugriffskontrolle (ABAC) weniger ausgeprägt sind.

💡 Begründung: Der Data Catalog erlaubt das manuelle Klassifizieren und Taggen von Assets, jedoch fehlen native, automatisierte Sensitivity Labels wie in Microsoft Purview oder ähnlichen Governance-Plattformen. Eine automatische Richtliniendurchsetzung basierend auf Klassifizierungen ist nicht dokumentiert. Dies stellt erhebliche Lücken für strenge Compliance-Anforderungen dar, weshalb Score 2 angemessen ist.

💡 Begründung: Es gibt keine native Model-Registry, kein Experiment-Tracking und kein ML-Training direkt in Datasphere. Über SAP BTP und SAP AI Core können ML-Workloads orchestriert werden, aber dies ist eine externe Integration, nicht eine native Funktion der Plattform. Damit sind die Anforderungen nur rudimentär über die SAP-Ökosystem-Integration erfüllbar, was Score 2 rechtfertigt.

💡 Begründung: SAP Joule bietet generative KI-Unterstützung und natural language Interaktion im SAP-Ökosystem. Direkt in Datasphere sind AI-Features wie intelligente Metadaten-Vorschläge und Joule-Integration vorhanden, aber vollständiges NL-Querying und automatische Analyse-Generierung sind eher über SAC als separates Tool verfügbar. Dies erfüllt das Minimum, übertrifft es jedoch nicht deutlich – Score 3 ist angemessen.

💡 Begründung: Datasphere enthält keinen integrierten BI-Report-Designer oder Dashboard-Tool für Endnutzer. Die Stärke liegt in der Datenbereitstellung; die Visualisierungsschicht ist bewusst ausgelagert (SAP Analytics Cloud, Power BI, Qlik). Dies bedeutet erhebliche Lücken für die Anforderung 'integrierte Self-Service-BI', weshalb Score 2 gerechtfertigt ist.

💡 Begründung: SAP Datasphere bietet Transport-Mechanismen und eine zunehmende Git-Integration über BTP-Tooling. Die Git-Unterstützung für alle Artefakttypen (Pipelines, Views, Modelle) ist jedoch nicht so nahtlos und umfassend wie bei spezialisierten DataOps-Plattformen. Das Minimum wird erfüllt, aber mit Einschränkungen – Score 3 ist konservativ und angemessen.

💡 Begründung: Datasphere unterstützt keine out-of-the-box CI/CD-Pipelines mit automatisiertem Dev/Test/Prod-Deployment. Die Transport Management-Funktionen (Content Network, BTP Transport) ermöglichen manuelle und halbautomatische Deployments, aber vollständige Pipeline-Automatisierung erfordert externe Tooling-Integration. Dies stellt erhebliche Lücken gegenüber der Anforderung dar – Score 2 ist gerechtfertigt.

💡 Begründung: Die Plattform stellt Space-Monitor, Database-Explorer-Statistiken und HANA-Cloud-Monitoring bereit. Kostenoptimierungs-Dashboards und detaillierte Nutzungsmetriken auf Berichts- oder Nutzerebene sind weniger ausgeprägt als bei spezialisierten FinOps- oder Observability-Tools. Das Minimum wird erfüllt, aber nicht deutlich übertroffen – Score 3 ist angemessen.

💡 Begründung: Looker erfüllt die Anforderungen sehr gut: offene REST-API, JDBC/ODBC, Git-Integration und Marketplace-Konnektoren sind vorhanden und dokumentiert. Der Score 5 würde eine noch breitere Out-of-the-box-Konnektivität (z.B. nativer EDI-Support oder fertige EAI-Konnektoren) erfordern; hier ist punktuell Eigenaufwand nötig, was Score 4 rechtfertigt.

💡 Begründung: Es existieren Log-basierte Monitoring-Möglichkeiten und Health-Endpunkte über Google Cloud Operations, was Basis-Monitoring ermöglicht. Ein starkes, integriertes Interface-Monitoring mit klaren operativen Diagnosen speziell für Schnittstellenverfügbarkeit und -performance (Score 4–5) ist nicht out-of-the-box vorhanden, daher Score 3.

💡 Begründung: Looker unterstützt benutzerdefinierte Rollen mit granularen Berechtigungen auf Modell- und Feldebene sowie Row/Column-Level Security. Allerdings ist echtes ABAC/Policy-basiertes Path-Level-Control wie in Score 5 beschrieben nicht vollständig vorhanden; die Berechtigungen sind eher repository-/modell-basiert. Score 4 (Flexible RBAC) trifft am besten zu.

💡 Begründung: Looker (insbesondere in der Enterprise-/SaaS-Variante) bietet native SCIM-Unterstützung für automatisches Provisioning und De-Provisioning von Nutzern und Gruppen, was Score 5 entspricht. Dies ist für Google Workspace und Drittanbieter-IdPs dokumentiert.

💡 Begründung: Looker bietet dokumentierte Self-Service-Konfiguration für SAML und OIDC, inklusive Azure AD-Integration. Der gesamte SSO-Lebenszyklus kann kundenseitig verwaltet werden, was Score 5 entspricht.

💡 Begründung: Looker ermöglicht Datentrennung über Projekte und Berechtigungen, aber echte Top-Level-Isolation (dedizierte Organisationen mit eigenem User-Management) ist in der SaaS-Variante eingeschränkt. Multi-Instanz-Setups sind möglich, aber komplex. Score 3 (Basic Repository-Level Separation) passt am besten.

💡 Begründung: Looker (SaaS) abstrahiert die Metadaten-Datenbank vollständig vom Kunden. Bei selbst-gehostetem Looker (Looker-hosted oder customer-hosted) wird MySQL als Backend verwendet – eine andere Datenbankwahl ist nicht möglich. Dies entspricht Score 4 nur im Self-Hosted-Fall, aber da das primäre Deployment SaaS ist und keine Flexibilität besteht, wird konservativ Score 2 vergeben.

💡 Begründung: BigQuery Omni mit nativer Unterstützung für S3, Azure Blob und GCS sowie Apache Iceberg erfüllt Score 5 vollständig: Full Native Cloud Storage über alle major Cloud Object Storage Provider.

💡 Begründung: BigQuery bietet Table- und Partition-Expiration als einfache zeitbasierte Cleanup-Mechanismen, was einem Basic Scheduled Cleanup entspricht. Komplexe policy-basierte Archivierung mit mehreren Kriterien oder dediziertem Archive-Tier ist nicht nativ verfügbar. Score 3 passt.

💡 Begründung: Looker ist ein SaaS-Produkt von Google; eine On-Premise- oder echte PaaS-Deployment-Option auf Hyperscalern nach Kundenwahl (AWS/Azure) existiert nicht. BigQuery Omni ermöglicht zwar Multi-Cloud-Datenzugriff, aber das Hosting bleibt bei Google. Score 1 wäre für rein SaaS, aber da es zumindest Hybrid-Optionen via Omni gibt, Score 2 – allerdings im Sinne der Skala bleibt es bei Score 1-2; konservativ Score 2 vergeben.

💡 Begründung: SaaS-Produkte erfordern keinen kundenseitigen Hardware-Footprint, was dem Kriterium 'sehr geringer Footprint' entspricht. Score 5 ist angemessen, da kein on-premise-Hardware-Management erforderlich ist.

💡 Begründung: SaaS-Produkte entsprechen dem Kriterium 'Fully Automated (Single Command/Wizard)' am besten, da keine Installation erforderlich ist und das Setup über einen einfachen Wizard in der Cloud Console erfolgt. Score 5.

💡 Begründung: BigQuery bietet Multi-Region-Datasets und Omni für Cross-Cloud-Abfragen, aber keine klassische Federation mit Edge-Caching für verteilte Unternehmensstandorte. Dies entspricht eher einem Proxy/Cache-Modell über Googles globale Infrastruktur. Score 3 ist angemessen.

💡 Begründung: BigQuery ist für analytische Hochlast bekannt und performant; Looker hat jedoch bei sehr komplexen Explore-Abfragen oder großen Concurrent-User-Zahlen bekannte Tuning-Anforderungen (PDTs, Caching-Konfiguration). Score 4 (Good performance with minor tuning needs) trifft zu.

💡 Begründung: BigQuery's Slot-basiertes Modell mit automatischem Scaling, reservierten Slots und Flex-Slots adressiert Heavy-Concurrency-Workloads nativ. Looker SaaS wird von Google verwaltet und skaliert horizontal. Beides entspricht dem Kriterium 'proven strong concurrency model with robust scaling' → Score 5.

💡 Begründung: Google's globale Netzwerkinfrastruktur und Result Caching reduzieren Latenzauswirkungen erheblich, jedoch gibt es keine spezifischen Offline- oder Proxy-Edge-Patterns für sehr bandbreitenbeschränkte Umgebungen. Dies entspricht 'good mitigation mechanisms for most distributed usage scenarios' → Score 4.

💡 Begründung: Standard-Administrationsaufgaben (Rollen, Permissions, Schedules, Alerts) sind No-Code möglich, aber die eigentliche Stärke von Looker liegt in LookML, einem Code-basierten Ansatz. Das entspricht 'basic no-code customization for standard settings; advanced needs require coding' → Score 3.

💡 Begründung: Die API-Abdeckung ist sehr gut, das Extension Framework ermöglicht Custom Apps innerhalb Looker, und LookML ist vollständig dokumentiert. Leichte Einschränkungen bestehen beim tiefen Eingriff in Core-Produktverhalten. Entspricht 'strong API and scripting/extensibility support with minor limits' → Score 4.

💡 Begründung: Enterprise IAM-Integration und feingranulare Rollen- und Projektberechtigungen sind vorhanden. Explizite 'Guest/External User'-Konzepte wie bei einigen anderen Plattformen sind weniger ausgeprägt, aber die RBAC-Reife ist hoch. Entspricht 'strong enterprise RBAC; offshore collaboration well-supported operationally' → Score 4.

💡 Begründung: Das Extensions Framework und die offene API ermöglichen tiefe Side-by-Side-Erweiterungen. Es fehlen jedoch native Plugin-Mechanismen wie bei manchen anderen Plattformen für wirklich tiefe Verhaltensänderungen. Entspricht 'strong extension capability via API/event hooks with some limits' → Score 4.

💡 Begründung: Git-basierte Versionierung von LookML und zentrale GCP IAM/BigQuery-Konsole bieten starke Konsistenz. Für vollständige Automatisierung aller Kontrollen (z.B. komplexe Retention-Policies) ist zusätzlicher Aufwand nötig. Entspricht 'strong centralized controls with good maintainability' → Score 4.

💡 Begründung: Looker ist ein vollständig proprietäres SaaS-Produkt, BigQuery ebenfalls. Es gibt keinen Quellcode-Zugang, keine Source-Available-Lizenz und keine Möglichkeit zur internen Review oder Modifikation des Core-Produkts. Entspricht klar Score 1.

💡 Begründung: Automatische Managed-Updates reduzieren den Kundenseitigen Regressionsaufwand erheblich. Die Release-Kadenz ist transparent und regelmäßig. Gelegentliche Breaking Changes in LookML APIs erfordern jedoch moderate Validierungsarbeit. Entspricht 'good regular release model; moderate regression effort expected' → Score 4.

💡 Begründung: Google Cloud's globale Infrastruktur mit automatischer Geo-Redundanz und definierten Recovery-Mechanismen ist stark. Kundenseitige Kontrolle über spezifische HA-Konfigurationen ist bei SaaS begrenzt. Entspricht 'strong recovery mechanisms and practical HA options' → Score 4.

💡 Begründung: SaaS-Modell mit transparentem Betrieb durch Google bedeutet standardmäßig near-zero Downtime für Kunden. Kein geplantes Maintenance-Window erforderlich. Entspricht klar 'no or near-zero downtime upgrades are standard in supported production patterns' → Score 5.

💡 Begründung: Publizierte, vertraglich bindbare SLAs für beide Produkte sind vorhanden und entsprechen Enterprise-Standards. BigQuery 99,99% ist stark, Looker 99,9% ist solide. Entspricht 'good published availability commitment for managed offerings' → Score 4.

💡 Begründung: Endanwender-Workflows (Explores, Dashboards) sind akzeptabel zugänglich, aber LookML als Code-first-Ansatz erhöht die Lernkurve für alle, die über reine Konsumption hinausgehen. Dies entspricht Score 3: 'Acceptable; some training/documentation needed for daily tasks'.

💡 Begründung: Innerhalb von Looker selbst ist die UX weitgehend konsistent, aber über das gesamte Produkt-Ökosystem (BigQuery, Dataplex, Looker Studio) gibt es spürbare Unterschiede. Anpassungsoptionen für Enterprise-Branding sind vorhanden, aber nicht extensiv – Score 3 ist angemessen.

💡 Begründung: Die Guidance ist überwiegend dokumentationsgetrieben ohne starke In-Product-Assistenten für kritische Workflows. Dies entspricht Score 3: 'Basic documentation-driven guidance, limited in-product assistance'.

💡 Begründung: Für Analysten und Data-Consumer ist der Workflow gut gestaltet, für Admins und Entwickler entstehen Brüche durch LookML/Git-Abhängigkeit. Score 3: 'Adequate fit with some friction in common tasks' trifft zu.

💡 Begründung: Die Plattform bietet funktionale Navigation und Suche, aber ein reichhaltiges Keyboard-Shortcut-System oder High-Productivity-Features für Power-User sind nicht prominent dokumentiert. Score 3: 'Basic productivity functions available' ist konservativ aber treffend.

💡 Begründung: Die Plattform ist stärker auf zentral administrierte Konsistenz als auf individuelle Endnutzer-Anpassung ausgelegt. Persönliche Theme- oder Verhaltenskontrollen für Nutzer sind minimal, was Score 2: 'Limited personalization options' entspricht.

💡 Begründung: Grundlegende Lokalisierung ist vorhanden (Sprachoptionen, Locale-Settings), aber die Tiefe und Vollständigkeit der Internationalisierung ist moderat. Score 3: 'Basic localization support' ist angemessen.

💡 Begründung: Es gibt dokumentierte Accessibility-Bemühungen und WCAG-Ausrichtung, aber Lücken in komplexen Interaktionen (z.B. Drag-and-Drop in Dashboards) sind bekannt. Score 3: 'Moderate support with some gaps' trifft die Realität.

💡 Begründung: Der LookML-Ansatz unterstützt die Idee einer zentralen Metrik-Definition, aber BigQuery erfordert typischerweise Dateningestion (Replikation) ins Warehouse. Direkter API-Zugriff auf Quellsysteme wie REF-MDS ohne Datenbewegung ist nicht der Standard-Use-Case; BigQuery Omni deckt nur S3/Azure Blob ab, nicht beliebige Quellsysteme. Daher Score 3.

💡 Begründung: EU-Hosting ist vorhanden (Frankfurt, europe-west), was regulatorische Anforderungen grundsätzlich erfüllt. Da der Kunde jedoch Azure als bevorzugten Hyperscaler nennt und Google Cloud nicht Azure ist, besteht eine strukturelle Einschränkung. BigQuery Omni als Brücke zu Azure ist kein vollwertiger Ersatz. Score 3 wegen eingeschränkter Hyperscaler-Präferenzerfüllung.

💡 Begründung: Google Cloud bietet Verschlüsselung at rest und in transit als Default ohne zusätzliche Konfiguration. CMEK und EKM ermöglichen volle Schlüsselkontrolle durch den Kunden. Dies entspricht dem Maximum der Skala: starke Verschlüsselung by default mit Enterprise-Controls. Score 5.

💡 Begründung: Google Cloud ist grundsätzlich GDPR-compliant mit DPA, EU-Regionen und Löschmechanismen. Allerdings ist Google als US-amerikanisches Unternehmen mit komplexer Subunternehmer-Kette (viele Google-Töchter und Partner) ein kritischer Punkt für BDSG und Behörden. Schrems-II-Risiken, US-CLOUD-Act-Exposition und limitierte spezifische BDSG-Nachweise rechtfertigen Score 3 statt höher.

💡 Begründung: Google Cloud besitzt ISO 27001 sowie ein umfangreiches Portfolio weiterer relevanter Zertifizierungen inklusive des deutschen BSI C5-Testat, das speziell für deutsche Behörden/Unternehmen relevant ist. Dies entspricht dem Maximum der Skala: ISO 27001 plus zusätzliche major certifications. Score 5.

💡 Begründung: Die Export/Import-Funktionalität ist stark und deckt sowohl API-basierte als auch operative Tooling-Ansätze ab. Einschränkungen bestehen bei sehr großen Massen-Uploads direkt über UI (Excel-Upload nicht nativ) und beim Import aus proprietären Quellen ohne ETL-Tool. Score 4, da die Kernfunktionalität sehr gut ist, aber nicht alle operativen Anforderungen (z.B. Excel-Massenupload direkt in BigQuery) nahtlos out-of-the-box erfüllt werden.

💡 Begründung: Obwohl Iceberg und offene APIs vorhanden sind, bleibt LookML proprietär und schwer migrierbar. Eine Ablösung erfordert vollständigen Rewrite des Semantic Layers. BigQuery selbst ist stark an GCP gebunden. Das entspricht laut Skala 'Strong platform or vendor dependency' = Score 2.

💡 Begründung: Es gibt ein solides, aber nicht breites Partnerökosystem für Looker/BigQuery. Die Spezialisierung auf LookML (proprietär) erhöht das Kontinuitätsrisiko bei Teamwechseln. Skala: 'Adequate capability with some continuity risk' = Score 3.

💡 Begründung: SaaS-Deployment ist schnell, aber LookML-Entwicklung, Git-Integration und BI-Tool-Anbindung (z.B. Qlik, Power BI) benötigen mehrere Wochen bis Monate. Im Microsoft-dominierten Umfeld des Kunden erhöht sich der Integrationsaufwand zusätzlich. Skala: 'Moderate lead time' = Score 3.

💡 Begründung: Google PSO und Partner wie Accenture, Deloitte bieten GCP-Expertise, jedoch ist tiefe LookML/Looker-Consulting-Kompetenz im DACH-Markt seltener. Großkundenerfahrung ist vorhanden, aber nicht so breit verankert wie bei Microsoft-Partnern. Skala: 'Adequate capability' = Score 3.

💡 Begründung: Alphabet hat eine Marktkapitalisierung von über 2 Billionen USD. Google Cloud wächst stark und investiert massiv in Looker und BigQuery. Kein relevantes Insolvenzrisiko. Skala: 'Very large and low-risk supplier base' = Score 5.

💡 Begründung: Google Cloud ist in allen relevanten Regionen präsent mit 37+ Regionen weltweit und einem starken Partner-Ökosystem. Einzige Einschränkung: In bestimmten regulierten Märkten oder Regionen ohne GCP-Footprint kann die Abdeckung limitiert sein. Skala: 'Good multi-region capability' = Score 4.

💡 Begründung: Der Kunde operiert in einer Microsoft-dominierten Landschaft. Google Looker/BigQuery als Alternativplattform schafft strategische Spannung mit Azure/Fabric-Initiativen, erhöht die Komplexität und erfordert Parallelinfrastruktur. Das entspricht 'Some strategic friction or dependency risk' = Score 2.

💡 Begründung: Git-native Versionskontrolle, Branch-basierte Entwicklung in Looker und SaaS-Delivery-Modell passen sehr gut zu agilen Methoden. CI/CD-Integration ist möglich. Kleine Abzüge, da LookML-Entwicklung dennoch spezialisierte Skills erfordert und Testkomplexität erhöht. Skala: 'Good modern delivery fit' = Score 4.

💡 Begründung: Der Aufbau eines code-definierten semantischen Layers (LookML) sowie die Integration in eine bestehende Microsoft-Infrastruktur erfordert spezialisiertes Know-how und umfangreiche Konzeptionsarbeit. Das entspricht laut Skala 'High setup cost' (Score 2), da weder Low-Code-Onboarding noch ein einfacher Einstieg ohne LookML-Expertise möglich sind.

💡 Begründung: LookML ist eine proprietäre Modellierungssprache mit Lernkurve. Die Integration in ein Microsoft-dominiertes Umfeld (Power BI, Qlik) über API/JDBC erfordert Custom-Entwicklung. Dies entspricht laut Skala 'High implementation effort' (Score 2). Spezialisierte LookML-Entwickler sind am Markt rar und kostspielig.

💡 Begründung: Die SaaS-Natur reduziert Infrastrukturaufwand, aber LookML-Modellpflege, BigQuery-Kostensteuerung (on-demand vs. Flat-Rate Slots) und die Administration eines dualen Systems (Looker + BigQuery) erfordern laufenden Aufwand. Das entspricht 'Moderate operating effort' (Score 3) – besser als On-Premise, aber nicht so wartungsarm wie vollintegrierte Single-Vendor-Lösungen.

💡 Begründung: Looker gilt als eines der teuersten BI-Tools im Markt (Creator-Seats oft >$100/Monat). Kombiniert mit BigQuery-Verbrauchskosten und optionalen Omni-Aufschlägen entsteht ein intransparentes, variables Kostenmodell. Laut Skala entspricht dies 'Teuer oder intransparent (versteckte Traffic-/Add-on-Kosten)' (Score 2).

💡 Begründung: Der Semantic Layer reduziert redundante Modellierung und fördert Self-Service, BigQuery ML eliminiert Daten-Exporte für ML-Use-Cases. Allerdings entstehen im Microsoft-Umfeld Parallelstrukturen, die Effizienzgewinne teilweise aufheben. Dies entspricht 'Moderate benefit' (Score 3) – reale Vorteile, aber kein starker Hebel im beschriebenen Kundenszenario.

💡 Begründung: Google Cloud bietet tiered Support-Modelle, aber echte Hotline-basierte 1st-Level-Partnermodelle sind begrenzt dokumentiert. Standard- und Enhanced-Tiers bieten telefonischen Zugang, aber die Co-Support-Modellierung mit dem Kunden ist nicht so flexibel wie bei manchen Enterprise-Anbietern. Score 3 (Adequate) ist konservativ angemessen.

💡 Begründung: Google Cloud Premium Support mit Technical Account Manager (TAM) und spezialisierten Support-Ingenieuren bietet eine solide 2nd-Level-Basis. Die Einbindung von zertifizierten Google Cloud Partnern als Zwischenschicht ist etabliert. Score 4 ist gerechtfertigt.

💡 Begründung: Google Cloud Premium Support bietet nachweislich Zugang zu Engineering-Eskalation für P1/P2-Probleme. Bug-Reports können über die interne Struktur an Produktteams weitergegeben werden. Jedoch sind Transparenz über Bugfix-Timelines und SLAs auf Engineering-Ebene begrenzt, daher Score 4 statt 5.

💡 Begründung: Google Cloud Support ist global ausgerichtet, unterstützt mehrere Sprachen (Englisch, Japanisch, Mandarin, Koreanisch u.a. – Deutsch ist nicht immer vollständig abgedeckt), und bietet eine API für Ticket-Management. Premium-Tier deckt Enterprise-Anforderungen weitgehend ab. Nicht ganz Score 5 wegen eingeschränkter Deutschsprachigkeit und begrenzter Ticket-Bridge-Dokumentation.

💡 Begründung: Dokumentierte Reaktionszeit-SLAs sind vorhanden und für Enterprise-Kunden im Premium-Tier stark. Jedoch beziehen sich SLAs primär auf Response-Time, nicht auf Resolution-Time. Dies ist branchenüblich, aber ein Einschränkungspunkt. Score 4 ist angemessen.

💡 Begründung: 24/7-Abdeckung ist für P1-Incidents im Premium-Tier gegeben und global durch verteilte Support-Zentren unterstützt. Für niedrigere Prioritäten gelten Einschränkungen. Leichte regionale Unterschiede in Sprachunterstützung (Deutsch nicht immer 24/7 verfügbar) begründen Score 4 statt 5.

💡 Begründung: Looker und BigQuery verfügen über sehr umfangreiche Dokumentation, separate Lernpfade für unterschiedliche Rollen (Entwickler, Administratoren, Endanwender), offizielle Zertifizierungen und sowohl selbstgesteuerte als auch betreute Trainingsformate. Dies entspricht der Score-5-Definition 'Extensive training and documentation'.

💡 Begründung: BigQuery/Looker hat keinen eigenen SAP-zertifizierten CDC-Konnektor. Google Cloud Datastream unterstützt Datenbanken wie Oracle, MySQL, PostgreSQL, aber nicht nativ SAP S/4HANA mit ODP/SLT. Damit entspricht dies Stufe 2 der Skala: Full-Load oder CDC nur über separat lizenzierte Drittanbieter realisierbar.

💡 Begründung: Es existiert kein dokumentierter Migrationspfad von SAP BW zu BigQuery/Looker, keine Unterstützung für BW Open Hub oder ODP im nativen Google-Produktstack, und keine Referenzarchitekturen für BW-Koexistenz. Dies entspricht Stufe 1 der Skala.

💡 Begründung: Looker exponiert seinen semantischen Layer explizit nicht über XMLA/MDX. Der Ansatz ist REST/API-first und SQL-basiert. Da XMLA ein hartes Kriterium ist und Looker es nicht unterstützt, ist Stufe 1 die korrekte Bewertung.

💡 Begründung: BigQuery stellt offizielle, gut dokumentierte JDBC/ODBC-Treiber bereit. Die Authentifizierung über Google-Identity ist möglich, AAD-nativ ist jedoch eingeschränkt. Qlik-Kompatibilität über BigQuery ODBC ist bekannt und in der Community dokumentiert, allerdings ohne offizielle Qlik-Zertifizierung auf dem Semantic-Layer-Level. Stufe 4 ist angemessen.

💡 Begründung: BigQuery unterstützt als verteilte SQL-Engine grundsätzlich Pushdown-Abfragen von Qlik. Jedoch gibt es keine offizielle Dokumentation eines vollständigen DirectQuery-Pushdown-Zertifizierungsstatus für Qlik auf Looker/BigQuery. Partielle Client-seitige Verarbeitung ist möglich. Stufe 3 ist konservativ angemessen.

💡 Begründung: Die Anforderung spezifiziert explizit Delta Lake/Delta Table-Kompatibilität. BigQuery unterstützt Iceberg (nicht Delta Lake nativ) und hat ein proprietäres Speicherformat. Daten können exportiert werden (Parquet), aber das Delta-Log-Protokoll ist nicht nativ. BigQuery Omni und Iceberg-Support retten einen mittleren Score, aber Delta-spezifische Anforderungen sind nicht vollständig erfüllt. Stufe 3 erscheint angemessen.

💡 Begründung: BigQuery bietet mit Dataplex, Dataform und separaten Datasets die Bausteine für Medallion-Architektur, aber kein out-of-the-box Template-basiertes Konzept mit automatischen DQ-Gates zwischen Schichten. Die Implementierung ist signifikant manuell. Stufe 3 entspricht 'technisch umsetzbar durch manuelle Konfiguration'.

💡 Begründung: Looker's semantischer Layer ist genuiner API-first und unterstützt Multi-Tool-Konnektivität über JDBC/ODBC und REST. Metrikänderungen in LookML sind sofort für alle Clients wirksam. Der fehlende XMLA-Endpunkt schränkt die Qlik-Integration ein, weshalb 'leichte manuelle Schritte' anfallen. Stufe 4 ist vertretbar, da die Kernfunktionalität stark ist.

💡 Begründung: Der Looker Marketplace enthält keine dokumentierten SAP-spezifischen Blocks für S/4HANA FI/CO. Es gibt vereinzelte Community-Beiträge, aber keine offiziell unterstützten SAP-Content-Acceleratoren. Vollständige Eigenmodellierung aller SAP-Strukturen ist erforderlich. Stufe 2 ('keine SAP-spezifische Unterstützung') ist korrekt.

💡 Begründung: BigQuery unterstützt DirectQuery von Power BI, und BigQuery BI Engine kann Abfragen beschleunigen. Vollständiger Pushdown und Sub-3s bei >1TB sind jedoch nicht automatisch garantiert und erfordern manuelle Konfiguration. DirectLake ist nicht verfügbar. Stufe 3 ('manuell erforderliche Aggregation-Tables, Performance-Ziele für kleinere Datasets') ist passend.

💡 Begründung: Power BI Zertifizierung ist ein Microsoft-seitiges Feature im Power BI Service. BigQuery/Looker kann als Datenquelle dienen, integriert sich aber nicht in den Power BI Zertifizierungs-Workflow mit automatisierten DQ-Gates oder Audit-Trails. Manuelle Prozesse ohne plattformseitige Unterstützung entsprechen Stufe 2.

💡 Begründung: BigQuery's Slot-Reservierungssystem ermöglicht echte Workload-Isolation zwischen verschiedenen Projekte/Nutzergruppen. Dies entspricht gut Stufe 4: 'konfigurierbare Ressourcepools, SLA-Einstellungen möglich, gelegentliche gegenseitige Beeinflussung bei Extremlasten'. Vollständige Garantien für SLA-Einhaltung erfordern manuell konfigurierte Reservierungen.

💡 Begründung: Da Looker selbst eine konkurrierende BI-Plattform ist und keine Power-BI-Migration anstrebt, gibt es keinerlei QlikScript-zu-DAX/M-Konvertierungstools. Das Partnerökosystem bietet allenfalls generische Migrationsberatung ohne Qlik-Spezifik. Score 2 ist angemessen, da kein Tool-Support und keine Qlik-spezifische Methodik existiert, aber zumindest allgemeine BI-Migrationserfahrung im Ökosystem vorhanden ist.

💡 Begründung: Dataplex liefert automatische technische Lineage auf Tabellen- und Spaltenebene innerhalb von BigQuery, aber die Integration über SAP-Konnektoren bis zum finalen BI-Report-Feld ist nicht nahtlos feldgranular. Business-verständliche Visualisierung und BCBS-239-konformer Export sind nicht als native Out-of-the-Box-Features verfügbar. Score 3 entspricht der Tabellen-Ebenen-Lineage ohne vollständige Impact-Analyse-Automatisierung.

💡 Begründung: Looker bietet technisch solide RLS und CLS-Funktionen im Semantischen Layer, was einen Score über 2 rechtfertigt. Die SAP-Rollenintegration (S_TABU_DIS etc.) ist jedoch nicht nativ automatisiert – es wäre eine manuelle Abbildung über LDAP/SAML-Attribute nötig. Separate Berechtigungspflege pro Schicht auf BigQuery-Ebene ist erforderlich. Score 3 trifft am besten zu.

💡 Begründung: Google Cloud hat einen etablierten Terraform-Provider, und LookML-Modelle sind nativ Git-versioniert, was IaC für Datenmodelle ermöglicht. Looker bietet auch einen eigenen Terraform-Provider für Content- und Konfigurationsmanagement. Nicht alle Aspekte (z.B. Schedule-Konfigurationen, bestimmte Admin-Einstellungen) sind vollständig als Code abbildbar. Score 4 ist angemessen für weitgehende IaC-Unterstützung mit kleinen verbleibenden UI-Anteilen.

💡 Begründung: Dataplex bietet Data Quality-Features (Dataplex Data Quality), die regelbasierte Prüfungen ermöglichen, jedoch ist dies kein vollintegriertes Framework mit SAP-spezifischen Validierungen, zentralem DQ-Dashboard mit Trend-Analyse und automatischer Eskalation. Die SAP-Abstimmlogik (FI vs. CO) muss komplett custom entwickelt werden. Score 2 ist konservativ korrekt – DQ ist nur über externe Tools oder Eigenentwicklung realisierbar ohne natives Framework.

💡 Begründung: BigQuery ist nachweislich für Milliarden-Datensatz-Szenarien geeignet und bietet Partitionierung und Clustering als Standard-Features. Zeitreihenabfragen über sehr große FI-Datensätze (BKPF/BSEG) sind in akzeptabler Zeit möglich. Delta-Table-spezifische Z-Order-Clustering-Optimierungen sind nicht nativ in BigQuery (das ist eher Databricks-spezifisch), aber BigQuery-Clustering erfüllt ähnliche Zwecke. Score 4 ist angemessen – manuelle Konfiguration nötig, aber grundsätzlich performant.

💡 Begründung: BigQuery Editions (Standard/Enterprise/Enterprise Plus) bieten kapazitätsbasierte Optionen, aber das klassische Modell ist stark verbrauchsbasiert. Budgetalarme sind vorhanden aber kein echter Cost-Cap. Looker-Lizenzen sind zusätzlich user-basiert und erheblich. Für ein Szenario mit vielen Qlik- und Power-BI-Nutzern, die über die Semantic Layer API zugreifen, ist die TCO-Planbarkeit begrenzt. Score 2 ist angemessen.

💡 Begründung: Looker ist konzeptionell für Governed Self-Service ausgelegt: LookML-Modelle definieren den erlaubten Analyse-Korridor, Access Grants steuern Datenzugriff granular, und System Activity protokolliert alle Queries. Datenkopien können über Download-Berechtigungen kontrolliert werden. Der Ansatz erfüllt weitgehend Score-4-Kriterien, ohne ein explizit dokumentiertes 'Self-Service-Korridor'-Konzept mit vollständiger Datenspreizungskontrolle zu bieten.

💡 Begründung: Google/Looker hat keine bekannten SAP-BW-spezifischen Migrationswerkzeuge für die Überführung von BW-Metadaten in BigQuery-Strukturen. Es gibt generische SAP-Konnektoren (z.B. BigQuery Data Transfer für SAP), aber keine BW-InfoProvider-spezifische Mapping-Automatisierung. Score 1 entspricht dem vollständigen Fehlen spezifischer BW-Migrationsunterstützung.

💡 Begründung: LookML bietet eine zentrale Quelle der Wahrheit für Metriken und Dimensionen, die von beiden Tools via API konsumiert werden können. Das ist konzeptionell stärker als separate Tool-Metadaten. Allerdings gibt es keine automatische Drift-Detection zwischen Looker-Definitionen und den jeweiligen Tool-Implementierungen, und die Qlik-Anbindung über JDBC erfordert manuelle Konfigurationsschritte. Score 3 ist angemessen.

💡 Begründung: BigQuery ist grundsätzlich in der Lage, multiple Quellströme parallel aufzunehmen (über Pub/Sub, Dataflow etc.), aber die Konfliktauflösung für Geschäftsobjekte aus parallelen SAP-Systemen muss als custom Transformationslogik in SQL/Dataform implementiert werden. Kein natives Dual-Write-Konzept mit automatischer Konfliktresolution. Score 3 trifft zu: möglich aber mit eigenem Implementierungsaufwand.

💡 Begründung: BigQuery bietet keine native SAP-Hierarchie-Unterstützung oder SCD-Mechanismen out-of-the-box. SCD2 muss über SQL/Dataform custom implementiert werden. LookML kann zeitabhängige Dimensionen modellieren, wenn die Datenstruktur entsprechend aufgebaut ist, aber transparente historische Hierarchieabfragen ohne Zusatzaufwand sind nicht gegeben. Score 3 entspricht der Situation: möglich mit kundenspezifischer Implementierung.

💡 Begründung: Looker unterstützt Entra ID / SAML-basierte Gruppen für RLS, aber eine automatisierte Übernahme von SAP-Rollen (Buchungskreise, Werke, Vertriebsorganisationen) existiert nicht nativ. Skript-Entwicklung und manuelle Pflege wären notwendig, was Skala-Stufe 2 entspricht.

💡 Begründung: BigQuery bietet keine produktionsreife, native SAP HANA Federation mit Query-Pushdown. Eine Föderierung wäre allenfalls über externe Konnektoren oder manuelle Virtualisierungs-Views realisierbar, was Stufe 2 der Skala entspricht.

💡 Begründung: Weder Looker noch BigQuery adressieren die Analyse von Qlik-App-Inventaren, Abhängigkeitsmatrizen oder Formel-Mappings. Dies entspricht Stufe 1 der Skala, da keinerlei plattformseitige Unterstützung vorhanden ist.

💡 Begründung: Lookers System Activity kombiniert mit BigQuery INFORMATION_SCHEMA ermöglicht Attribution auf Tool- und Nutzerebene. Labels können genutzt werden, um Power BI vs. Qlik zu unterscheiden. Kein out-of-the-box Chargeback-Modul, daher Stufe 4.

💡 Begründung: Das Muster einer Quarantäne-Schicht ist in BigQuery/Dataflow umsetzbar, erfordert aber eigene Implementierung. Es gibt kein natives Framework mit Dashboard und Wiedereinspielung, was Stufe 3 der Skala entspricht.

💡 Begründung: Time-Travel ist als technisches Feature vorhanden (Iceberg, BigQuery Snapshots), aber die direkte BI-Tool-Integration ohne Zwischenschicht ist eingeschränkt. Delta Lake spezifisch ist nicht nativ in BigQuery; Iceberg ist der Ersatz. Stufe 3 ist angemessen.

💡 Begründung: Entra ID als IdP ist bei Looker möglich und Gruppen-Claims für RLS nutzbar. Die SAP-Gruppen-Synchronisation ist kein nativer Bestandteil und erfordert externe Lösungen, was Stufe 3 der Skala entspricht.

💡 Begründung: Technisch ist der Export in Parquet/Iceberg gut unterstützt und API-gestützt möglich. Ein formeller vertraglicher Exitprozess mit SLA fehlt in den Standard-Googl-Cloud-Bedingungen, was Stufe 4 (kein vollständiger Exit-SLA, aber dokumentierter Prozess) entspricht.

💡 Begründung: Looker erlaubt Rollentrennung (Developer vs. Viewer) und Git-PR-Prozesse als Governance-Mechanismus, bietet aber keinen dedizierten Zertifizierungs-Workflow mit Audit-Trail und visueller governed/ungoverned-Kennzeichnung. Stufe 3 ist konservativ angemessen.

💡 Begründung: Selektives Reprocessing ist auf Partitionsebene möglich, erfordert aber eigene Implementierung der Idempotenz-Logik und manuelle Orchestrierung. Keine nativen Plattform-Werkzeuge out-of-the-box, was Stufe 3 entspricht.

💡 Begründung: Es existiert kein natives Writeback-Konzept in Looker/BigQuery für SAP. Technisch könnte man über externe Skripte SAP OData ansprechen, aber ohne Plattform-Governance oder Audit-Trail. Dies entspricht Stufe 2 der Skala.

💡 Begründung: Es gibt kein natives Framework für SAP BW-zu-S/4HANA-Konfliktharmonisierung. Die Umsetzung wäre nur durch externe Middleware oder vollständige Eigenentwicklung möglich, was Stufe 2 entspricht. Stufe 1 wird vermieden, da BigQuery generisch Multi-Source-ETL unterstützt.

💡 Begründung: LookML unterstützt Versionskontrolle via Git und ermöglicht manuelles Rollback durch Code-Revert, aber ein nativer Approval-Workflow mit technischen und fachlichen Reviewern, automatischer Abhängigkeitsanalyse auf Power BI/Qlik-Artefakte und One-Click-Rollback existiert nicht. Dies entspricht Skala-Stufe 2: manuelle Versionskontrolle via Code-Repository, kein nativer Workflow, keine automatische Impact-Analyse.

💡 Begründung: BigQuery Editions/Reservations erlauben feingranulare Slot-Zuweisung pro Workload-Gruppe und Projekt, was tool-basierter Priorisierung nahekommt. Monitoring ist vorhanden, aber vollautomatische Drosselung bei interaktiven SLA-Risiken und Echtzeit-Eskalations-Alerts auf Client-Typ-Ebene sind nicht nativ out-of-the-box, was Stufe 4 statt 5 rechtfertigt.

💡 Begründung: Es gibt keine integrierten Werkzeuge in Looker oder BigQuery, die spezifisch auf den Vergleich von Qlik- und Power-BI-Ausgaben ausgerichtet sind. Validierung wäre nur durch manuelle Stichproben oder eigene Skripte möglich, was eher Stufe 2 entspricht. Stufe 3 würde grundlegende Datenqualitätstests mit eigenen Skripten voraussetzen – da zumindest BigQuery-native Datenvergleiche via SQL möglich sind, aber kein strukturierter Prozess existiert, ist Stufe 2 angemessen.

💡 Begründung: BigQuery unterstützt zwar Schema Evolution für additive Änderungen (neue Felder) in nativen Tabellen und Iceberg, aber eine automatische Erkennung von SAP CDS-View-Änderungen, Impact-Analyse über alle Layer und kontrollierte Propagation ist nicht nativ vorhanden. Dataplex bietet Metadata-Management, aber keine automatische SAP-Quell-Monitoring-Funktion. Dies entspricht Stufe 2: manuelle Inspektion und Anpassung erforderlich, hohes Fehlerrisiko.

💡 Begründung: BigQuery ist ein exzellentes Warehouse für strukturierte und semi-strukturierte Daten mit Mandantenfähigkeit über Projekte/Datasets. Unstrukturierte Daten (Bilder, Videos etc.) liegen in GCS extern, was eine Lücke zum echten Unified Data Lake (wie Databricks Unity Catalog) darstellt. Score 4 ist angemessen – gut, übertrifft Mindestanforderung, aber nicht Best-in-Class für alle Datentypen.

💡 Begründung: Die Implementierung der Medallion-Architektur ist in BigQuery gut möglich und praxiserprobt, wird jedoch nicht durch eine dedizierte, integrierte UI-Oberfläche für Schichtenmanagement unterstützt – es ist eher konventionsbasiert. Score 4 ist passend: übertrifft das Minimum, ist aber nicht so nativ-integriert wie bei Databricks Lakehouse.

💡 Begründung: BigQuery hat seit 2023/2024 starken Iceberg-Support inkl. ACID-Transaktionen eingeführt. Delta Lake wird nicht nativ unterstützt, Hudi ebenfalls nicht direkt. Die Anforderung fordert mehrere Formate (Delta, Iceberg, Hudi) – Iceberg wird gut erfüllt, aber kein Delta Lake. Score 4 erscheint angemessen, da Iceberg-Support stark ist, aber nicht alle genannten Formate unterstützt werden.

💡 Begründung: Looker selbst hat keine Low-Code-Pipeline-Erstellung. BigQuery hat Dataform für SQL-Transformationen (Code-basiert) und Cloud Data Fusion für Low-Code-ETL, aber letzteres ist ein separates Produkt. Im Kontext der bewerteten Plattform (Looker + BigQuery) besteht hier eine erhebliche Lücke gegenüber integrierten Lösungen wie Microsoft Fabric oder Databricks. Score 2 ist gerechtfertigt.

💡 Begründung: Google Datastream bietet CDC-Funktionalität für BigQuery, ist aber ein eigenständiges, separat lizenziertes Produkt. Im Kontext der bewerteten Lösung (Looker + BigQuery) ist CDC nicht nativ integriert, was eine erhebliche Lücke darstellt. Score 2 ist angemessen – rudimentäre Fähigkeiten vorhanden, aber durch externe Abhängigkeit nicht als Kernfeature wertbar.

💡 Begründung: BigQuery Omni ist ein Best-in-Class Feature für Cross-Cloud-Datenintegration ohne Datenbewegung – explizit als bekannte Stärke des Produkts gelistet. Die Unterstützung von AWS und Azure sowie GCS, kombiniert mit externen Tabellen und Dataplex-Integration, erfüllt die Anforderung vollständig und ausgereift. Score 5 ist gerechtfertigt.

💡 Begründung: BigQuery kann Streaming-Daten über Storage Write API und Pub/Sub empfangen und nahezu in Echtzeit abfragen. Für komplexe Streaming-Transformationen (Fensteroperationen, Event-Joins) ist jedoch Dataflow (Apache Beam) als separates Produkt erforderlich. Im Vergleich zu dedizierten Streaming-Plattformen (Azure Event Hubs + Stream Analytics, Databricks Structured Streaming) ist dies Mittelfeld. Score 3 ist passend.

💡 Begründung: Im Kern-Stack Looker + BigQuery gibt es keine nativen kollaborativen Multi-Language-Notebooks. Google Colab Enterprise oder Vertex AI Workbench wären die entsprechenden Google-Produkte, sind aber nicht Teil der bewerteten Lösung. BigQuery Studio bietet einfache SQL/Python-Notebooks, aber ohne die Kollaborationstiefe von Databricks oder Fabric. Score 2 ist konservativ aber gerechtfertigt.

💡 Begründung: Dataplex als zentraler Governance-Layer kombiniert mit IAM, Data Catalog und Looker-seitiger Zugriffskontrolle ergibt ein gut ausgebautes Framework. Es ist jedoch nicht so nahtlos in eine einzige UI integriert wie Microsoft Purview in Fabric. Score 4 ist angemessen – gut, übertrifft das Minimum, aber leichte Fragmentierung über mehrere Services.

💡 Begründung: Dataplex Lineage deckt BigQuery-interne Transformationen gut ab, aber die Spaltenebenen-Lineage (Column-Level Lineage) ist begrenzt und die Integration von der Quelle über Pipelines bis zum Looker-Dashboard als vollständige End-to-End-Lineage ist nicht Best-in-Class. Anforderung nennt explizit Spaltenebene. Score 3 ist angemessen – Mindestanforderung erfüllt, aber erhebliche Lücken bei Column-Level und End-to-End-Vollständigkeit.

💡 Begründung: BigQuery Time Travel ist eine ausgereifte, nativ integrierte Funktion mit bis zu 7-tägigem Fenster. Dies ist gut für operative Anforderungen, aber kürzer als z.B. Databricks Delta Lake (bis zu 30 Tage konfigurierbar). Für regulatorische Langzeit-Versionierung sind externe Mechanismen nötig. Score 4 ist passend – übertrifft das Minimum, aber nicht ganz Best-in-Class aufgrund des begrenzten Zeitfensters.

💡 Begründung: Google Cloud Audit Logs sind produktionsreif, manipulationssicher und bieten detaillierte Protokollierung von Datenzugriffen und Admin-Aktivitäten. Looker System Activity ergänzt mit BI-seitigen Nutzungsdaten. Die Kombination ist gut für regulatorische Anforderungen geeignet. Score 4 ist angemessen – gut ausgebaut, aber zentralisiertes Compliance-Reporting-Dashboard (wie in Microsoft Purview Compliance Portal) fehlt als integriertes Feature.

💡 Begründung: Die Kombination aus Looker Semantic Layer (zentrale Durchsetzung für alle konsumierenden Tools) und BigQuery nativer RLS/CLS deckt die Anforderung vollständig und ausgereift ab – kein separater Datenkopie-Ansatz erforderlich, Best-in-Class entsprechend Score 5.

💡 Begründung: Die Funktionalität ist vorhanden (Dataplex Data Catalog, Policy Tags), aber nicht so nahtlos integriert und ausgereift wie dedizierte Datenschutz-Klassifizierungsplattformen; erfüllt das Minimum, daher Score 3.

💡 Begründung: BigQuery ML ist für einfache In-Database-Modelle geeignet, deckt aber Experiment-Tracking, Model-Registry und Deployment-Automatisierung nur rudimentär ab; eine vollständige ML-Plattform erfordert zusätzlich Vertex AI, was erhebliche Lücken im Kern-Produktumfang bedeutet, daher Score 2.

💡 Begründung: Gemini-Integration bietet solide NLQ- und Code-Generierungsfunktionen, übertrifft die Mindestanforderung deutlich; im Vergleich zu Best-in-Class fehlt noch breitere Enterprise-Reife und Nachweislage in der Praxis, daher Score 4.

💡 Begründung: Looker bietet Self-Service-BI, ist aber stärker auf vordefinierte Explores angewiesen und weniger drag-and-drop-freundlich als führende BI-Tools; erfüllt das Minimum, übertrifft es aber nicht wesentlich, daher Score 3.

💡 Begründung: Native Git-Integration für den Kern-Artefakt (LookML) ist gut umgesetzt und unterstützt gängige Git-Plattformen; jedoch keine einheitliche Git-Integration über alle Plattform-Artefakte (z. B. Notebooks, Pipelines), daher Score 4 statt 5.

💡 Begründung: CI/CD ist möglich und wird in der Community praktiziert (Looker CI via GitHub Actions, Dataform-Workflows), aber nicht als native, vollständig integrierte Lösung für alle Artefakttypen; erfüllt das Minimum, daher Score 3.

💡 Begründung: Die Kombination aus Looker System Activity und BigQuery-nativen Monitoring-Tools deckt Nutzungsanalyse, Performance und Kostenkontrolle gut ab und übertrifft die Mindestanforderung; nicht ganz Best-in-Class, da ein einheitliches, integriertes Monitoring-Dashboard über beide Produkte hinweg fehlt, daher Score 4.