Die Kernidee lässt sich in einem Satz zusammenfassen: Cube definiert Kennzahlen genau einmal – und alle Werkzeuge rechnen anschließend mit derselben Definition. Ein BI-Tool, eine Tabellenkalkulation, ein KI-Assistent und eine selbst gebaute Web-Anwendung greifen nicht mehr jeweils direkt und mit eigener Logik auf das Warehouse zu, sondern fragen ihre Zahlen bei Cube ab. Cube kennt die eine, verbindliche Definition und liefert konsistente Ergebnisse aus. Damit endet der verbreitete Zustand, dass drei Abteilungen drei leicht abweichende Umsatzzahlen präsentieren, weil jede ihre eigene Berechnung mitbringt.
Der Begriff Headless BI ist bewusst gewählt. Klassische BI-Werkzeuge vereinen zwei Dinge in einem Produkt: die Definition der Kennzahlen und deren Darstellung als Diagramm oder Tabelle. Cube trennt diese beiden Dinge. Es übernimmt ausschließlich die Definition und Bereitstellung der Kennzahlen – den „Kopf“, also die sichtbare Oberfläche mit den Diagrammen, überlässt es anderen Werkzeugen. „Headless“ bedeutet also: Cube ist die Denkschicht ohne eigene Anzeigeoberfläche, an die sich beliebige Frontends anschließen lassen.
Drei Eigenschaften definieren Cube:
Um Cube richtig einzuordnen, hilft ein Blick auf den typischen Weg der Daten. Rohdaten werden zunächst aus Quellsystemen in ein zentrales Data Warehouse geladen und dort – idealerweise mit einer Transformationsschicht – zu sauberen Analysetabellen aufbereitet. Klassisch greifen die BI-Werkzeuge nun direkt auf diese Tabellen zu und definieren ihre Kennzahlen jeweils selbst. Genau hier setzt Cube an: Es schiebt sich als zusätzliche Schicht zwischen die aufbereiteten Daten und die Werkzeuge. Die Werkzeuge fragen ihre Kennzahlen nicht mehr direkt beim Warehouse ab, sondern bei Cube – und erhalten so garantiert konsistente Definitionen.
Diese Positionierung ist wichtig: Cube ersetzt weder das Data Warehouse noch die Transformationsschicht noch das BI-Tool. Es füllt eine oft unbesetzte Lücke – die Ebene der einheitlichen Kennzahldefinition –, die in vielen gewachsenen Datenlandschaften gar nicht existiert und deren Fehlen sich in widersprüchlichen Zahlen bemerkbar macht. Cube macht die Kennzahllogik zentral, konsistent und für viele Werkzeuge gleichzeitig nutzbar.
Der Begriff Universal Semantic Layer – „universelle semantische Schicht“ – beschreibt den Anspruch, nicht nur ein einzelnes BI-Werkzeug mit konsistenten Kennzahlen zu versorgen, sondern grundsätzlich alle Werkzeuge, die Zahlen brauchen. Das ist der entscheidende Unterschied zu semantischen Schichten, die fest in ein einzelnes BI-Produkt eingebaut sind und nur diesem dienen. Cube versteht sich als werkzeugübergreifende, offene Schicht. Ob das Management sein Dashboard, der Controller seine Tabelle oder ein KI-Assistent seine Antwort erhält – die zugrunde liegende Kennzahldefinition ist überall dieselbe.
Für den Mittelstand ist dieser Gedanke attraktiv, weil er Unabhängigkeit schafft. Wer seine Kennzahllogik nicht im einzelnen BI-Werkzeug einsperrt, sondern in einer neutralen Schicht davor ablegt, macht sich vom konkreten Frontend unabhängiger. Ein späterer Wechsel des BI-Tools wird deutlich leichter, weil die eigentliche Geschäftslogik nicht mit dem Werkzeug verschwindet, sondern in Cube erhalten bleibt.
Cube Core ist das quelloffene Herzstück und für viele der Einstieg in die Cube-Welt. Es enthält alles Wesentliche: die Sprache, in der man Kennzahlen und ihre Beziehungen beschreibt, den Motor, der Abfragen entgegennimmt und an das Warehouse weiterreicht, sowie die offenen Schnittstellen, über die Werkzeuge andocken. Der große Vorteil ist die Freiheit – Cube Core verursacht keine Lizenzgebühren und lässt sich in der eigenen Umgebung betreiben, vom eigenen Server bis in die eigene Cloud-Infrastruktur. Für Unternehmen mit hohen Anforderungen an Datenhoheit ist das ein zentrales Argument, weil die semantische Schicht vollständig in der eigenen, kontrollierten Umgebung bleibt.
Die Kehrseite ist die Eigenverantwortung. Mit Cube Core müssen Sie selbst dafür sorgen, dass der Dienst zuverlässig läuft, ausreichend skaliert und überwacht wird. Auch die Verwaltung der Zwischenspeicher, mit denen Cube seine Geschwindigkeit erreicht, und der Betrieb unter Last liegen in Ihrer Hand. Für Teams mit technischer Kompetenz im Betrieb von Diensten ist das gut beherrschbar; für Teams, die sich ganz auf die Kennzahlmodellierung konzentrieren wollen, kann dieser Betriebsaufwand spürbar ins Gewicht fallen.
Cube Cloud nimmt Ihnen genau diesen Betriebsaufwand ab. Es ist ein von Cube Dev betriebener Dienst rund um den Core, der eine ganze Reihe von Betriebs- und Komfortfunktionen mitbringt: den automatischen, skalierenden Betrieb der semantischen Schicht; eine komfortable Verwaltung und Aktualisierung der Zwischenspeicher; Überwachung und Fehleranalyse; sowie Funktionen für die Zusammenarbeit im Team und die Anbindung an Entwicklungsprozesse. Der Preis dafür ist ein Abonnement und die Auslagerung des Betriebs an einen externen, US-amerikanischen Anbieter.
Aus Beratungssicht ist die Wahl selten eine Frage von „richtig“ oder „falsch“, sondern eine Abwägung. Cube Cloud verkürzt den Weg zum produktiven, belastbaren Betrieb erheblich und entlastet kleine Teams von Infrastruktur-Arbeit – gerade das verlässliche Betreiben und Aktualisieren der Zwischenspeicher unter Last ist keine triviale Aufgabe. Cube Core gibt maximale Kontrolle und Kostenfreiheit bei der Lizenz, verlangt dafür aber eigenes technisches Können. Wichtig: Weil beide Varianten denselben Kern teilen, ist ein Wechsel später möglich – die eigentliche Modellierungsarbeit ist nicht verloren, wenn man sich umentscheidet.
In unseren Projekten hängt die Empfehlung von wenigen Faktoren ab. Verfügt ein Unternehmen über technisch versierte Mitarbeiter, die ohnehin Dienste betreiben und skalieren, und legt es besonderen Wert auf Kostenkontrolle und Datenhoheit, ist Cube Core oft der bevorzugte Weg. Fehlt diese Betriebs-Tiefe oder soll ein kleines Team schnell und ohne Infrastruktur-Aufbau eine belastbare semantische Schicht bereitstellen, spielt Cube Cloud seine Stärken aus – insbesondere beim verlässlichen Betrieb der performancekritischen Zwischenspeicher. Ein pragmatischer Mittelweg, den wir häufig sehen: mit Cube Core einen Prototyp aufbauen, um die Idee zu erproben, und für den produktiven Betrieb dann bewusst über Cube Cloud entscheiden, sobald Verfügbarkeit und Skalierung wichtig werden.
Das Herzstück von Cube ist das Datenmodell. Darin beschreibt man, aus welchen Tabellen die Daten stammen, wie diese Tabellen zusammenhängen und welche Kennzahlen sich daraus berechnen. Eine Metrikdefinition legt genau fest, wie eine Kennzahl entsteht: Welche Spalte wird summiert, welche Filter gelten, wie werden Zeiträume behandelt. Der entscheidende Punkt ist die Zentralität – diese Definition existiert nur ein einziges Mal und gilt für alle Werkzeuge, die darauf zugreifen.
Damit adressiert Cube das verbreitetste Problem gewachsener BI-Landschaften: die widersprüchlichen Kennzahlen. Wenn der Vertrieb den „Umsatz“ inklusive Rabatten rechnet, das Controlling ihn ohne Rabatte betrachtet und das Marketing eine dritte Variante nutzt, entstehen drei Wahrheiten. Wird die Definition dagegen einmal in Cube festgelegt, rechnen alle Werkzeuge zwangsläufig gleich. Änderungen an einer Kennzahl erfolgen an genau einer Stelle und wirken sofort überall konsistent. Genau das ist der Unterschied zwischen einer BI-Landschaft, der man traut, und einer, über deren Zahlen ständig gestritten wird.
Eine semantische Schicht ist nur dann praktisch nutzbar, wenn Abfragen schnell beantwortet werden. Dafür setzt Cube auf ein mehrstufiges Caching, also einen Zwischenspeicher für Abfrageergebnisse. Besonders wirkungsvoll ist dabei das Konzept der Pre-Aggregations: Häufig benötigte Verdichtungen – etwa Tagesumsätze oder monatliche Kennzahlen je Region – werden vorab berechnet und bereitgehalten. Fragt ein Werkzeug später eine solche Auswertung ab, muss Cube sie nicht jedes Mal neu aus den Rohdaten berechnen, sondern liefert die vorbereitete Verdichtung aus. Das beschleunigt Antworten erheblich.
Für den Mittelstand hat dieser Mechanismus einen doppelten Nutzen. Zum einen fühlen sich Dashboards und Berichte spürbar reaktionsschneller an, was die Akzeptanz erhöht. Zum anderen – und das wird oft übersehen – schützt Caching die Rechenkosten des Data Warehouse. Denn jede Abfrage, die aus dem Zwischenspeicher beantwortet wird, belastet nicht das verbrauchsbasiert abgerechnete Warehouse. Gerade bei vielen Nutzern und häufig aufgerufenen Standardberichten kann das die laufenden Plattformkosten deutlich dämpfen. Die konkrete Ausgestaltung und Grenzen dieser Funktionen sollte man für den eigenen Anwendungsfall beim Anbieter prüfen.
Der letzte Baustein ist die Anschlussfähigkeit über offene Schnittstellen. Cube stellt seine Kennzahlen über mehrere APIs bereit, jede mit ihrem typischen Einsatzgebiet. Die REST-Schnittstelle und die GraphQL-Schnittstelle richten sich vor allem an eigene Anwendungen und Entwicklerteams, die Zahlen in ihre Software einbauen möchten. Die SQL-kompatible Schnittstelle ist für den BI-Einsatz besonders wichtig: Sie lässt Cube nach außen wie eine klassische Datenbank wirken, sodass gängige BI-Werkzeuge wie Power BI, Tableau oder Superset sich anschließen können, als würden sie eine gewöhnliche Datenbank abfragen – tatsächlich aber erhalten sie die zentral definierten, konsistenten Kennzahlen von Cube.
Die Grundidee ist bestechend einfach. Wenn ein Anwender einen KI-Assistenten fragt „Wie hoch war unser Umsatz im letzten Quartal in Süddeutschland?“, muss dieser Assistent wissen, was genau „Umsatz“ bedeutet, wie „Quartal“ definiert ist und welche Region „Süddeutschland“ umfasst. Ohne eine verbindliche Definition muss die KI raten – und rät womöglich falsch. Genau hier kommt die semantische Schicht ins Spiel: Sie liefert der KI die verbindlichen Kennzahldefinitionen, sodass diese nicht mehr raten muss, sondern auf gesicherte Geschäftslogik zurückgreift.
Lässt man einen KI-Assistenten direkt und ungefiltert auf ein Data Warehouse los, entsteht ein grundlegendes Vertrauensproblem. Die KI muss selbst entscheiden, wie sie eine Kennzahl berechnet – und ihre Entscheidung kann von Anfrage zu Anfrage variieren oder schlicht falsch sein. Für harmlose Erkundungen mag das genügen; als Grundlage für Geschäftsentscheidungen ist es gefährlich, weil niemand die stillschweigenden Annahmen der KI kontrolliert.
Eine semantische Schicht dreht dieses Verhältnis um. Die KI fragt ihre Zahlen nicht mehr roh aus dem Warehouse ab, sondern über Cube – und erhält damit ausschließlich die Kennzahlen, die dort verbindlich definiert sind. Die KI übersetzt die Frage des Nutzers in eine wohldefinierte Abfrage gegen die semantische Schicht; die Berechnung selbst folgt der einen, geprüften Definition. Das reduziert das Risiko halluzinierter oder inkonsistenter Zahlen erheblich, weil die Geschäftslogik nicht mehr im Ermessen der KI liegt, sondern im festgelegten Modell.
Cube positioniert sich vor diesem Hintergrund ausdrücklich als Fundament für KI-gestützte Analytics. Die Idee: Ein KI-Assistent oder ein sprachbasiertes Analysewerkzeug greift über die Schnittstellen von Cube auf die definierten Metriken zu, statt eigenständig SQL gegen die Rohdaten zu erzeugen. Der Anwender stellt seine Frage in natürlicher Sprache, die KI wählt die passenden, definierten Kennzahlen und Filter, und Cube liefert das konsistente Ergebnis. Die semantische Schicht wird so zur Brücke zwischen menschlicher Sprache und verlässlichen Geschäftszahlen. Der konkrete Funktionsumfang solcher KI-Fähigkeiten entwickelt sich schnell weiter und sollte für den eigenen Anwendungsfall beim Anbieter geprüft werden.
Aus Beratungssicht ordnen wir das nüchtern ein: Die semantische Schicht ist ein sehr sinnvolles, oft sogar notwendiges Fundament, wenn man KI-gestützte Auswertungen ernsthaft und verlässlich einsetzen möchte. Sie ist aber kein Autopilot. Ob eine Kennzahl fachlich korrekt definiert ist, ob die richtige Metrik für eine Frage gewählt wurde und ob das Ergebnis plausibel ist – das bleibt Aufgabe fachkundiger Menschen. Wir empfehlen, die semantische Schicht als das Rückgrat vertrauenswürdiger KI-Analytics zu betrachten und nicht als Ersatz für Datenverständnis.
Der typische Aufbau in unseren Projekten folgt einer klaren Arbeitsteilung: Ein Warehouse hält die Daten, eine Transformationsschicht bereitet sie zu sauberen Tabellen auf, Cube legt die einheitliche Kennzahldefinition darüber, und die Frontends greifen über die Schnittstellen von Cube auf konsistente Zahlen zu. Weil Cube die eigentliche Rechenarbeit weitgehend an das Warehouse delegiert und nur um einen Zwischenspeicher ergänzt, bleibt es selbst schlank.
Cube braucht eine Datenquelle, aus der es seine Kennzahlen berechnet – in aller Regel ein Data Warehouse. Es unterstützt die führenden modernen Plattformen, darunter Snowflake, Google BigQuery, Databricks und Amazon Redshift, sowie weitere Datenbanken. Diese Wahl ist bewusst offen gehalten: Cube bindet sich nicht an einen einzelnen Anbieter, sondern spricht die jeweilige Plattform an. Das gibt Unternehmen Flexibilität und mindert die Bindung an eine bestimmte Cloud. Die Kennzahllogik im Cube-Modell bleibt weitgehend gleich, auch wenn man das darunterliegende Warehouse später wechseln würde.
Für den Mittelstand ist diese Offenheit ein starkes Argument. Wer heute etwa mit BigQuery startet und morgen zu Snowflake wechselt, muss seine mühsam gepflegte Kennzahllogik nicht neu aufbauen – sie liegt portabel in Cube. Die semantische Schicht wird so zu einem Sicherheitsnetz gegen strategische Fehlentscheidungen bei der Plattformwahl.
Ein besonders wichtiges Zusammenspiel besteht mit der Transformationsschicht, im modernen Data Stack meist durch dbt vertreten. Beide Werkzeuge arbeiten an unterschiedlichen Stellen: dbt verwandelt Rohdaten im Warehouse in saubere, getestete Analysetabellen – Cube legt darüber die einheitliche Kennzahldefinition und stellt sie den Werkzeugen bereit. Die eine Schicht bereitet die Daten auf, die andere macht die Geschäftslogik konsistent zugänglich. In der Praxis lässt sich Cube gut auf eine mit dbt modellierte Datenbasis aufsetzen; die aufbereiteten Tabellen von dbt sind die ideale Grundlage für die Kennzahlmodellierung in Cube.
Diese Arbeitsteilung ist kein Zufall, sondern gute Architektur. Man kann die Rollen klar trennen: dbt sorgt für saubere, verlässliche Daten, Cube für konsistente, universell abfragbare Kennzahlen. Wir gehen auf die Abgrenzung – insbesondere zum dbt Semantic Layer, der hier eine gewisse Überschneidung hat – in Kapitel 06 genauer ein.
Am sichtbaren Ende der Kette stehen die Werkzeuge, die die Kennzahlen für Menschen darstellen. Cube arbeitet grundsätzlich mit allen gängigen BI-Tools zusammen, weil sie über die SQL-kompatible Schnittstelle andocken können. Ob Microsoft Power BI – im deutschen Mittelstand am weitesten verbreitet –, Tableau oder das quelloffene Apache Superset: Sie alle können ihre Zahlen aus Cube beziehen, statt sie selbst und potenziell abweichend zu definieren. Darüber hinaus lassen sich über die REST- und GraphQL-Schnittstellen auch Tabellenkalkulationen, eigene Web-Anwendungen und KI-Assistenten anbinden – das ist der Kern des „universellen“ Anspruchs.
Genau hierin liegt ein oft übersehener Vorteil. Wenn die Kennzahllogik in Cube liegt, bleiben die BI-Berichte schlank und konsistent – sie visualisieren nur noch. Die verbreitete Unsitte, komplexe Berechnungen in undurchschaubaren Dashboard-Formeln zu verstecken, entfällt. Das macht die BI-Landschaft nicht nur konsistenter, sondern auch unabhängiger vom einzelnen Frontend: Ein Wechsel des BI-Werkzeugs wird deutlich einfacher, wenn die Logik nicht darin gefangen ist, sondern in der neutralen semantischen Schicht davor liegt.
Zunächst zum gemeinsamen Nenner: Alle betrachteten Ansätze versuchen, das Problem der widersprüchlichen Kennzahlen zu lösen, indem sie die Geschäftslogik an einer zentralen Stelle definieren. Der Unterschied liegt darin, wie universell und wie offen diese zentrale Stelle ist – ob sie also viele Werkzeuge gleichermaßen bedient oder vor allem einem bestimmten Ökosystem dient.
Die engste inhaltliche Nachbarschaft besteht zum dbt Semantic Layer. Auch dieser verfolgt das Ziel, Kennzahlen zentral zu definieren – allerdings eng an die Transformationsschicht dbt gekoppelt, in deren Ökosystem er beheimatet ist. Für Unternehmen, die ohnehin stark auf dbt setzen und ihre Kennzahlen möglichst nah an der Datenmodellierung halten möchten, ist das ein naheliegender Weg. Cube dagegen versteht sich als eigenständige, werkzeugübergreifende Schicht, die sich nicht an ein bestimmtes Transformationswerkzeug bindet und über ihre breiten Schnittstellen besonders viele Frontends – bis hin zu KI-Assistenten und eigenen Anwendungen – bedienen kann. Vereinfacht gesagt: Der dbt Semantic Layer denkt von der Datenmodellierung her, Cube denkt von der universellen Bereitstellung her. Beide Ansätze entwickeln sich; ihren jeweils aktuellen Reifegrad sollte man beim Anbieter prüfen.
LookML ist die Modellierungssprache der BI-Plattform Looker. Sie war einer der Wegbereiter der Idee, Geschäftslogik zentral zu beschreiben, statt sie in einzelnen Berichten zu verstecken. Der entscheidende Unterschied zu Cube: LookML ist eng mit dem Looker-Werkzeug verbunden – die zentrale Semantik dient in erster Linie der Looker-Oberfläche. Cube hingegen ist bewusst frontend-neutral und quelloffen im Kern. Für Unternehmen, die tief in der Looker-Welt zu Hause sind, ist LookML der natürliche Weg. Wer dagegen mehrere, wechselnde Werkzeuge bedienen und Anbieterbindung vermeiden möchte, findet in Cube den offeneren Ansatz.
AtScale ist ein weiterer etablierter Anbieter im Feld der semantischen Schichten, der traditionell eher im Umfeld größerer Organisationen und anspruchsvoller Leistungsanforderungen positioniert ist. Auch AtScale zielt darauf, Kennzahlen zentral bereitzustellen und Abfragen über Verdichtungen zu beschleunigen. Gegenüber Cube ist es ein rein kommerzielles Produkt ohne quelloffenen Kern. Für den Mittelstand ist die entscheidende Frage meist, wie viel Enterprise-Funktionsumfang tatsächlich gebraucht wird und wie wichtig ein quelloffener Einstieg mit geringer Anbieterbindung ist – Punkte, bei denen Cube mit seiner Core-Variante oft näher an den Bedürfnissen mittelständischer Teams liegt.
Die wichtigste Voraussetzung ist eine saubere, verlässliche Datenbasis im Warehouse. Cube legt die Kennzahldefinition über vorhandene Daten – sind diese Daten inkonsistent oder unaufbereitet, hilft auch die beste semantische Schicht wenig. Häufig wird Cube daher gemeinsam mit oder nach einer Transformationsschicht wie dbt geplant, die für saubere Analysetabellen sorgt. Steht die Datenbasis, folgt die zentrale Betriebsentscheidung: Cube Core im Selbstbetrieb oder Cube Cloud als verwalteter Dienst. Diese Wahl, in Kapitel 02 ausführlich behandelt, prägt den späteren Betriebsaufwand und die Datenhoheit maßgeblich und sollte früh und bewusst getroffen werden.
Für das Self-Hosting von Cube Core braucht es Kompetenz im Betrieb von Diensten: das Bereitstellen, Skalieren und Überwachen einer laufenden Anwendung sowie den verlässlichen Betrieb der performancekritischen Zwischenspeicher. Wer diese Kompetenz im Haus hat, gewinnt volle Kontrolle und Kostenfreiheit bei der Lizenz. Wer sie nicht hat oder nicht binden möchte, ist mit Cube Cloud oft schneller und ruhiger unterwegs – gegen Abogebühr und mit Blick auf den zu prüfenden Serverstandort.
Der zweite Erfolgsfaktor ist eine durchdachte Kennzahlmodellierung. In der Cube-Praxis lohnt es sich, die wichtigsten Kennzahlen des Unternehmens gemeinsam mit den Fachbereichen präzise zu definieren, bevor man sie in Cube abbildet. Genau diese fachliche Klärung – was genau ist „Umsatz“, wie zählen wir „aktive Kunden“ – ist oft die eigentliche Arbeit; die technische Umsetzung im Cube-Modell folgt danach. Eine von Anfang an saubere, benannte und dokumentierte Struktur verhindert, dass das Modell mit der Zeit unübersichtlich wird.
Wie bei jeder Datenplattform empfehlen wir einen fokussierten Start. Statt sofort alle Kennzahlen des Unternehmens modellieren zu wollen, beginnt man mit einem konkreten, schmerzhaften Anwendungsfall – etwa den zentralen Umsatzkennzahlen, über die im Unternehmen ständig gestritten wird – und baut das Modell darum herum auf. Das liefert schnell sichtbaren Wert, schafft Akzeptanz und hält den Aufwand überschaubar. Aus dem ersten Erfolg wächst die semantische Schicht dann organisch weiter.
Weil das Cube-Datenmodell im Kern Code ist, kommt automatisch eine gewisse Zusammenarbeits-Disziplin ins Spiel: Änderungen an Kennzahldefinitionen werden nachvollziehbar, überprüfbar und gemeinsam gepflegt. Gerade im Mittelstand, wo oft wenige Personen viele Rollen tragen, ist das ein Gewinn – es entsteht eine gemeinsame, dokumentierte Definition der Kennzahlen statt individueller Insellösungen. Zugleich empfiehlt sich ein klares Rechtekonzept, das festlegt, wer Kennzahldefinitionen ändern darf und wie Änderungen produktiv gehen. Cube macht die einheitliche Bereitstellung technisch handhabbar; die organisatorische Disziplin – Konventionen, Abstimmung mit den Fachbereichen, Verantwortlichkeiten – müssen Sie selbst mitbringen. Genau an dieser Schnittstelle zwischen Technik, Daten und Organisation setzt unsere Beratungsarbeit an.
Besonders naheliegend ist Cube für Unternehmen, die ihre Daten über mehrere Werkzeuge hinweg auswerten und dabei immer wieder auf widersprüchliche Zahlen stoßen. Ein klassisches Beispiel ist ein Unternehmen, in dem das Management Dashboards in Power BI betrachtet, das Controlling parallel mit Tabellenkalkulationen arbeitet und die Fachbereiche eigene Auswertungen pflegen. Solange jedes Werkzeug seine Kennzahlen selbst definiert, driften die Zahlen auseinander. Cube legt eine einheitliche Definition darüber – und plötzlich stimmen die Umsatzzahlen über alle Werkzeuge hinweg überein.
Ein zweites, zunehmend wichtiges Feld ist die Vorbereitung auf KI-gestützte Auswertungen: Wer einen KI-Assistenten verlässlich Geschäftsfragen beantworten lassen möchte, braucht die definierten Metriken, die Cube bereitstellt. Weitere typische Felder sind das Einbetten von Kennzahlen in eigene Anwendungen – etwa ein Kundenportal, das jedem Kunden seine eigenen Zahlen zeigt – sowie der Aufbau einer werkzeugunabhängigen Kennzahlbasis, die einen späteren Wechsel des BI-Tools erleichtert. In all diesen Fällen ist Cube nicht das sichtbare Ergebnis – das sind die Dashboards und Antworten –, aber der Grund dafür, dass man ihnen trauen kann.
Ein erster, klar umrissener Cube-Anwendungsfall – vom Aufsetzen der Schicht über die Modellierung der wichtigsten Kennzahlen bis zur Anbindung eines ersten Frontends – ist in vielen Mittelstands-Projekten in wenigen Wochen umsetzbar, sofern eine saubere Datenbasis bereits vorhanden ist. Ein erheblicher Teil des Aufwands liegt dabei nicht in der Technik, sondern in der fachlichen Klärung der Kennzahlen mit den Beteiligten – dieser Schritt wird regelmäßig unterschätzt. Der Ausbau zu einer breiten, unternehmensweiten Kennzahlbasis über viele Bereiche hinweg ist dagegen ein fortlaufendes Programm über mehrere Monate. Wichtig ist die ehrliche Einordnung: Cube ist ein Baustein, kein Rundum-sorglos-Paket, und entfaltet seinen Wert erst im Zusammenspiel mit Warehouse, Transformationsschicht und Frontends.
Die Kostenfrage bei Cube beantwortet sich zuerst über die Variante. Cube Core ist quelloffen und verursacht keine Lizenzgebühren – Sie „bezahlen“ hier vor allem mit dem eigenen Betriebsaufwand: der Zeit für Bereitstellung, Skalierung, Überwachung und die Verwaltung der Zwischenspeicher sowie den Kosten der Infrastruktur, auf der Sie Cube betreiben. Cube Cloud wird dagegen als Abonnement gebucht; der Anbieter stellt gestufte Pläne mit unterschiedlichem Funktions- und Nutzungsumfang bereit. Konkrete Eurobeträge nennen wir bewusst nicht – die Preise unterscheiden sich je nach Plan, Nutzung und Vertrag und ändern sich über die Zeit. Die verbindlichen Konditionen prüfen Sie bitte direkt beim Anbieter.
Ein oft übersehener Punkt: Die eigentlichen Rechenkosten entstehen nicht in Cube, sondern im Data Warehouse, aus dem die Kennzahlen berechnet werden. Hier wirkt das Caching sogar kostensenkend – jede Abfrage, die aus dem Zwischenspeicher beantwortet wird, belastet nicht das verbrauchsbasiert abgerechnete Warehouse. Gut eingerichtete Pre-Aggregations können die Warehouse-Rechnung spürbar senken. Wer die Gesamtkosten seiner Datenplattform betrachtet, muss Cube-Lizenz (oder Core-Betriebsaufwand), Warehouse-Rechenkosten und die übrigen Bausteine zusammendenken – Cube ist dabei häufig ein gut planbarer Posten, der an anderer Stelle Kosten spart.
Cube Dev ist ein US-amerikanisches Unternehmen. Für deutsche und europäische Unternehmen wirft das – wie bei allen US-Anbietern – berechtigte Fragen zu Datenschutz und Datenhoheit auf. Entscheidend ist hier eine Besonderheit von Cube: Als semantische Schicht verarbeitet Cube zwar Abfragen und liefert Kennzahlen aus, die eigentlichen Massendaten liegen aber im Data Warehouse. Je nach Betriebsmodell durchlaufen Ergebnisse und Zwischenspeicher jedoch die Cube-Schicht – wo diese läuft, ist deshalb eine zentrale Frage. Bei Self-Hosting bleibt alles in Ihrer Umgebung; bei Cube Cloud betreibt ein US-Anbieter die Schicht.
Für die Bewertung ist die Variante entscheidend. Cube Core im Self-Hosting ist aus Datenhoheits-Sicht die stärkste Option: Die semantische Schicht läuft vollständig in Ihrer eigenen, kontrollierten Umgebung, es fließen keine Daten zu Cube Dev, und Sie behalten die volle Kontrolle darüber, wo Abfragen verarbeitet und Zwischenspeicher gehalten werden. Für Unternehmen mit hohen Souveränitätsanforderungen ist Core deshalb oft der bevorzugte Weg. Bei Cube Cloud hingegen betreibt ein US-Anbieter den Dienst; hier sollten Sie den angebotenen Serverstandort prüfen – ob ein EU-Hosting angeboten wird und wie es ausgestaltet ist, erfragen Sie bitte direkt beim Anbieter – sowie die vertraglichen Instrumente wie einen Auftragsverarbeitungsvertrag und die etablierten Sicherheitszertifizierungen.
Bestehen bleibt – wie bei allen US-Anbietern – ein grundsätzliches Drittland-Thema, das seit den Schrems-Urteilen und der Diskussion um den US Cloud Act kontrovers bewertet wird. Weil die eigentlichen Massendaten im Warehouse liegen und Cube je nach Konfiguration vor allem definierte Kennzahlergebnisse verarbeitet, lässt sich das Risikoprofil durch bewusste Gestaltung beeinflussen – etwa indem Warehouse und, wo möglich, auch die Cube-Schicht in einer EU-Region betrieben werden. Für Unternehmen mit hohen Souveränitätsanforderungen ist Cube Core im Eigenbetrieb der klare Weg; wer den Komfort von Cube Cloud nutzen möchte, sollte Serverstandort, Auftragsverarbeitungsvertrag und Datenminimierung sorgfältig prüfen. Die endgültige Bewertung bleibt eine Frage des Einzelfalls.
