dbt-Governance-Framework von Kaizen Gaming verkürzt die Einrichtung neuer Projekte um 70 Prozent

Sechs Teams, sechs Arbeitsweisen

Kaizen Gaming steht hinter der Sportwetten- und Casino-Marke Bettano. Laut dbt Labs ist das Unternehmen in 25 Märkten auf vier Kontinenten aktiv, hat mehr als 15 Millionen aktive Nutzer und wächst um 40 Prozent im Jahresvergleich.

Mit dem Wachstum der Organisation führte jedes der sechs Analytics-Engineering-Domänenteams dbt in eigenem Tempo und nach eigenen Regeln ein. Im Vortrag von Principal Analytics Engineers Thomas Antonakis und Stefanos Nikolaou sowie Senior Analytics Engineer Akis Zervas wurden drei kostspielige Muster beschrieben, die daraus entstanden:

• Dieselben Quelldaten wurden bis zu sechsmal unabhängig voneinander aufbereitet, ohne eine einzige verbindliche Definition, auf die man verweisen konnte.
• Gemeinsam genutzte Infrastruktur wurde per Copy-and-paste vervielfältigt, statt sie wiederzuverwenden.
• Die Führungsebene hatte keinen Einblick in die Testabdeckung oder den Nutzen der Investitionen, und wer neu ins Team kam, musste Konventionen lernen, die nur in den Köpfen einzelner Personen existierten.

Drei Ebenen zentral, der Rest bleibt bei den Domänenteams

Statt ein vollwertiges Plattformteam aufzubauen, wählten die beiden Principals genau drei Ebenen für die Zentralisierung aus.

Grundlegende Modelle. Ein Projekt, das die Vortragenden Core nennen, enthält die unternehmensweiten Basismodelle als schlanke Views ohne Orchestrierungsaufwand. Jedes nachgelagerte Projekt greift darauf zu.

Internes Utilities-Paket. Gemeinsame Makros, Tests und Konfigurationen werden über eine Subscription-Mapping-Datei automatisch an die abonnierenden Repos verteilt. Ein einziger Merge ersetzt heute, was früher 15 manuell eröffnete Pull Requests erforderte.

Infrastruktur und KI-Tooling als Code. Die Konfiguration von dbt-Projekten und -Umgebungen wurde aus der Oberfläche in Terraform verlagert, mithilfe des Terraform-Providers von dbt Labs. Die CI läuft nur für betroffene Projekte, Merge- und Apply-Rechte sind als Code Owner auf die beiden Principals beschränkt, und vor jeder Anwendung auf die Produktion ist ein separater manueller Freigabeschritt nötig.

Auf der KI-Seite baute das Team ein zentrales Enablement-Repository mit rund 16 auf Analytics Engineering zugeschnittenen Skills auf. Diese sind sowohl an das Data Warehouse als auch an den MCP-Server von dbt angebunden, sodass der KI-Agent jedes Engineers unabhängig vom verwendeten Tool mit demselben Kontext startet.

Berichtete Ergebnisse und eine Faustregel für die Zentralisierung

Die Vortragenden nannten folgende Ergebnisse:

• Die Vorlaufzeit für neue Projekte sank um 70 Prozent.
• Durch die Projektvorlagen entsteht eine annualisierte Ersparnis von 10.000 US-Dollar.
• Korrekturen an der gemeinsamen Konfiguration profitieren über das Utilities-Paket von einem Zeithebel von etwa 15.
• Das KI-Onboarding neuer Mitarbeitender schrumpfte von einem mehrtägigen, unstrukturierten Prozess auf rund 30 Minuten.

Als Beleg dafür, dass das Framework ein aktives System und kein Dokument ist, das niemand öffnet, verwiesen sie auf fünfzehn Merge Requests an den gemeinsamen Repos in den 30 Tagen vor dem Vortrag.

Außerdem lieferten die Vortragenden eine Entscheidungsregel. Etwas gehört in die gemeinsame Ebene, wenn keine einzelne Domäne es wirklich besitzt, wenn jedes Team das Problem sonst unabhängig lösen würde oder wenn die Inkonsistenz auf Organisationsebene teuer ist und keine echte Geschäftslogik darstellt. Bei den Domänenteams bleibt es, wenn es tatsächliche fachliche Urteile abbildet oder wenn ein Fehler nur ein einzelnes Team betrifft.

Zugriffskontrolle für KI-Agenten und was das bedeutet

Auf die Frage nach der Zugriffskontrolle für KI-Agenten sagten die Vortragenden, dass derzeit alle ihre Analytics Engineers dieselbe Zugriffsstufe haben. Die Authentifizierung von Agenten, die sich über MCP-Server von GitLab, Atlassian oder Databricks verbinden, übernimmt zentral das Plattformteam per SSO.

Für andere Datenteams, die vor demselben Auseinanderdriften der Domänengruppen stehen, bietet der Vortrag eine konkrete Vorlage: die zentrale Kontrolle auf wenige klar begründete Ebenen beschränken und die Geschäftslogik bei den Teams belassen, denen sie gehört. Einer der Vortragenden fasste den Ansatz so zusammen: „Governance und Autonomie müssen sich nicht widersprechen.“ Die Zahlen stammen aus der eigenen Darstellung der Vortragenden, wie sie dbt Labs veröffentlicht hat, und wurden nicht unabhängig überprüft.