BDC-Sizing & Kapazität
Stand 2026-09-03
BDC-Sizing = genug Kapazität für die Workload, ohne ungenutzten Spielraum zu bezahlen; in einem Verbrauchsmodell (M032) ist Fehldimensionierung in beide Richtungen teuer (zu klein = langsam/SLA-Verfehlung/Vertrauensverlust, zu groß = dauerhaft aufgeblähte Rechnung). Workload-getrieben, nicht sitzplatzgetrieben: drei Klassen skalieren auf unterschiedlichen Achsen — geplante Pipelines (batchfähig), interaktive Abfragen/Stories (Nebenläufigkeit/Latenz), Databricks-Engineering/ML (spitzenhaft, M034); eine einzige Zahl für alle drei ist der klassische Fehler. Erst T-Shirt-Schätzung, dann nach 4-6 Wochen anhand echter Telemetrie (M045) präzise dimensionieren — die anfängliche Schätzung nicht als endgültig behandeln. Auf Elastizität auslegen (zum Monatsabschluss hochskalieren, danach herunter), nicht auf dauerhafte Spitzenkapazität. Die Storage-Dimensionierung folgt der Historien-Stufung (M071) — Hot+Warm-Arbeitsmenge dimensionieren, nicht das 12-Jahres-Archiv. Ehrlich: Sizing ist eine Schätzung, die durch die Realität und einen Nachjustierungs-Checkpoint verfeinert wird, keine Scheinpräzision. Steuert Rechnung und Nutzererfahrung gleichzeitig.
Was Sie lernen
- Die drei Workload-Klassen von BDC trennen — geplante Pipelines, interaktive Abfragen, Databricks-ML — und jede auf ihrer eigenen Achse dimensionieren statt einer vermischten Gesamtzahl
- Einen konservativen T-Shirt-Sizing-Plan mit einem definierten Nachjustierungs-Checkpoint auf Basis echter Telemetrie (M045) erstellen
- Kapazität auf Elastizität rund um Spitzenfenster (Monats-/Quartalsabschluss) auslegen, statt ganzjährig für dauerhafte Spitzenkapazität zu bezahlen
- Das Storage-Sizing um die Hot+Warm-Arbeitsmenge (M071) herum ausrichten und eine Sizing-Empfehlung gegenüber einem Plattform-Owner ohne Scheinpräzision vertreten
Modulüberblick
Das Sizing einer BDC-Umgebung ist die Disziplin, genügend Kapazität für die Workload bereitzustellen, ohne für ungenutzten Spielraum zu bezahlen — und in einer verbrauchsbasierten Plattform (Begleitmodul M032) ist eine Fehleinschätzung in beide Richtungen teuer. Bei Unterdimensionierung kriechen Abfragen, Pipelines verfehlen SLAs, und Anwender verlieren Vertrauen; bei Überdimensionierung trägt die Rechnung dauerhaften Speck. Der Senior-Ansatz ist evidenzbasiertes Right-Sizing, das konservativ beginnt und sich anhand echter Telemetrie verfeinert, kein einmaliger Schätzwurf.
Workload-getrieben, nicht sitzplatzgetrieben. Die alte SAC/BW-Sizing-Frage lautete: „Wie viele Anwender?" Die BDC-Frage lautet: „Welche Workloads, bei welcher Nebenläufigkeit, bei welchem Datenvolumen?" Drei Workload-Klassen treiben die Kapazität: geplante Pipelines (vorhersehbar, batchfähig), interaktive Abfragen/Stories (nebenläufigkeitssensitiv, latenzgebunden) und Databricks-Engineering/ML (spitzenhaft, rechenintensiv — Begleitmodul M034). Jede skaliert auf einer anderen Achse; eine einzige Zahl für alle drei anzusetzen, ist der klassische Fehler.
Erst T-Shirt-Größe, dann Telemetrie. Ein vertretbarer Sizing-Prozess beginnt mit einer groben Schätzung (klein/mittel/groß) aus Workload-Klassen + Datenvolumen + Nebenläufigkeit und verfeinert sich dann anhand des beobachteten Verbrauchs, sobald echte Pipelines und Anwender auf der Plattform sind (Begleitmodul M045 Monitoring). Der Fehler besteht darin, die anfängliche Schätzung als endgültig zu behandeln; das richtige Muster ist, einen konservativen Startpunkt bereitzustellen — mit dem expliziten Plan, nach 4-6 Wochen Telemetrie nachzujustieren.
Voraussetzungen
- Fortgeschrittene praktische Erfahrung mit SAP-Analytics-Projekten
- Zuerst die Kernkonzepte durcharbeiten: C012, C015, C010
Lernergebnisse
- Die drei Workload-Klassen von BDC trennen und jede auf ihrer eigenen Skalierungsachse dimensionieren.
- Einen konservativen T-Shirt-Sizing-Plan mit einem expliziten Nachjustierungs-Checkpoint erstellen.
- Die Kernentscheidung des Moduls anwenden: Sizing-Grundlage — Dimensionierung nach Workload-Klasse + Volumen + Nebenläufigkeit wählen, nicht Sizing nach Anwender-/Sitzplatzzahl (die alte SAC/BW-Frage).
- Die Beherrschung mit dem KPI verfolgen: Sizing-Grundlage (Ziel: workload-klassengetrieben; Warnsignal: nach Sitzplatz-/Anwenderzahl dimensioniert).
Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Codeblöcke · die Wissenskontrolle · die Schemata.