Konzeptkarte

SAP BusinessObjects Design Studio

Stand 2026-08-29

Redaktion: Cédric-Olivier Mâry, alleiniger Redakteur und verantwortlich für die Veröffentlichung — 27 Jahre im SAP-Ökosystem. Wie diese Seiten entstehen und wo Automatisierung eingesetzt wird.

Was ist SAP BusinessObjects Design Studio?

Worum es geht

Design Studio war SAPs Antwort auf eine bestimmte Frustration: Dashboards, die sich nicht programmieren ließen. Wo frühere Werkzeuge Konfiguration boten, bot Design Studio eine Skriptsprache, ein Ereignismodell und — entscheidend — ein SDK, über das Entwickler eigene Komponenten schreiben konnten. Das öffnete die Tür zu einem echten Ökosystem: kundeneigene Diagramme, Navigationsleisten, Eingabesteuerelemente und Integrationen, die keine Produkt-Roadmap vorausgesehen hatte, gebaut von Partnern und von Entwicklern der Kunden selbst.

Die Namensgeschichte zählt für alle, die alte Materialien lesen. Design Studio wurde in die Lumira-Marke eingegliedert und lief als Lumira Designer weiter; dieselben Artefakte, dasselbe SDK, ein anderer Produktname. Ein großer Teil der Community-Dokumentation sagt noch „Design Studio“, während die installierte Software „Lumira Designer“ sagt, und diese als zwei getrennte Migrationsthemen zu behandeln, ist ein häufiger und teurer Fehler.

Das SDK ist zugleich der Grund für die Einführung und der Grund, warum der Ausstieg schwerfällt. Eine Design-Studio-Anwendung, die nur Standardkomponenten nutzt, hat einen einigermaßen direkten Ausdruck als SAC Analytic Application: Das Paradigma einer skriptbasierten, ereignisgesteuerten Analyseanwendung wird übertragen. Eine auf kundeneigenen SDK-Komponenten aufgebaute Anwendung hat das nicht, weil diese Komponenten Code sind, geschrieben gegen eine Laufzeitumgebung, die das Ziel nicht bereitstellt. Sie werden neu gebaut — in SAC als Custom Widgets, wo die Anforderung weiterhin gilt, oder fallengelassen, wo sich herausstellt, dass die Anforderung ein Workaround für eine Lücke war, die das Ziel inzwischen geschlossen hat.

Wie man es scopet. Anwendungen inventarisieren, dann nach Komponentennutzung klassifizieren: nur Standard, Standard plus konfigurationslastiges Skripting, und kundeneigenes SDK. Dann fragen, wer die kundeneigenen Komponenten geschrieben hat, denn die Antwort ist häufig ein Partnerengagement, das vor Jahren endete und kein Quellcode-Repository hinterließ.

Für Berater sind Design-Studio- und Lumira-Designer-Bestände eine verlässliche Quelle von Migrationsarbeit, gerade weil der Rest Code ist — und Code, den niemand besitzt, ist der Teil, den ein Kunde ohne Hilfe nicht beurteilen kann.

Design-Studio- und Lumira-Designer-Anwendungen sitzen typischerweise auf BW- oder HANA-Datenquellen, was bedeutet, dass dieselbe Kopplung gilt: Eine BEx-Query-gestützte Anwendung erbt die Mainstream-Wartungsklippe von BW 7.5 am 31. Dezember 2027 (kostenpflichtige Verlängerung bis 2030; SAP, 23. April 2020), wenn die Quelle klassisches BW ist, oder das identische 2027-bis-2030-ECC-Fenster, wenn nicht. Die eigene End-of-Life-Uhr der Anwendungsschicht, was immer sie ist, ist selten die bindende Beschränkung — die Datenquelle darunter ist es.

Die Scoping-Frage, die den Aufwand tatsächlich vorhersagt, lautet nicht „wie viele Anwendungen“, sondern „wie viele unterschiedliche kundeneigene SDK-Komponenten, und wie viele Anwendungen nutzen jede davon“. Ein Betrieb mit fünfzig Anwendungen auf fünf gut dokumentierten gemeinsamen Komponenten migriert schneller als einer mit zehn Anwendungen, die jeweils ein eigenes maßgeschneidertes Widget tragen, weil die Komponente, nicht die Anwendung, die Einheit des Neuaufbaus ist. Das kundeneigene Komponenteninventar vor dem Anwendungsinventar budgetieren — diese Reihenfolge umzukehren ist der häufigste Grund, warum eine Design-Studio-Schätzung mitten im Programm nach oben korrigiert werden muss.

Die Entscheidung, die das erzwingt. Für jede Anwendung eine von drei Optionen: auf Standardkomponenten übertragen, als SAC Analytic Application mit kundeneigenen Widgets neu bauen, oder ablösen. Der Kompromiss konzentriert sich auf die mittlere Option, weil eine kundeneigene SDK-Komponente zu Entwicklerkosten neu gebaut wird — und die Frage, die es wert ist, vorher gestellt zu werden, lautet, was die Komponente eigentlich umging. Ein bedeutender Teil der SDK-Komponenten existiert, weil eine Standardkomponente in der Version von damals etwas nicht konnte; das Ziel mag es heute einfach können. Komponente für Komponente gegen den aktuellen Funktionsumfang des Ziels zu entscheiden, statt gegen die ursprünglich geschriebene Anforderung, ist das, was eine Neubau-Schätzung von einer nicht budgetierten Neu-Spezifizierungsübung unterscheidet.

Warum es zählt

Kundeneigene SDK-Komponenten sind Code, geschrieben gegen eine Laufzeitumgebung, die das Ziel nicht bereitstellt. Sie werden neu gebaut, und ihre Autoren sind häufig ein Partnerengagement, das vor Jahren endete.

Kernpunkte

Das Werkzeug für BI-Anwendungsdesign: Skriptsprache, Ereignismodell und ein SDK für kundeneigene Komponenten.
🔴 Design Studio und Lumira Designer sind dasselbe Thema unter zwei Namen — das schriftliche Material und die installierte Software stimmen nicht überein.
Anwendungen mit Standardkomponenten übertragen sich einigermaßen direkt auf SAC Analytic Applications.
Kundeneigene SDK-Komponenten tun das nicht: Sie werden als SAC Custom Widgets neu gebaut, oder fallengelassen, wenn die Anforderung ein Workaround war.
Nach Komponentennutzung scopen — Standard · skriptlastig · kundeneigenes SDK — und fragen, wer die kundeneigenen geschrieben hat.
Die Entscheidung ist pro Anwendung: auf Standardkomponenten übertragen, mit kundeneigenen Widgets neu bauen, oder ablösen.
Bevor eine SDK-Komponente bezahlt neu gebaut wird, klären, was sie umging — das Ziel deckt es heute vielleicht mit einer Standardfunktion ab.

Quellen

In der App öffnen →