Episoden
27.10.2025
22 Minuten
Damals, vor der ersten Folge, haben wir drei, vielleicht vier
Wochen vorbereitet. Wir wollten es richtig machen. Nicht perfekt,
aber ehrlich. Und schon damals entstand dieses Gefühl: Wir müssen
liefern. Immer liefern. Das war unser Anspruch und irgendwann auch
der Punkt, an dem wir merkten, dass man darüber sprechen muss, was
das eigentlich bedeutet. Warum Pasadena? Pasadena steht für einen
Ort, an dem vieles beginnt. Die Idee, dass Daten Geschichten
erzählen können, wenn man ihnen zuhört. Damals die Entscheidung,
The DataBrothers nicht nur als Podcast, sondern als Lernreise zu
starten: von Self Service bis Fabric, von Technik bis
Verantwortung. Es ist ein Symbol, für den Start, für Reife, für
Neugier und Wandel. Und vielleicht auch für den Mut, loszulassen,
wenn ein Kapitel zu Ende erzählt ist. Warum wir aufhören und doch
weitermachen. Nach 100 Folgen ist klar: Wir haben geliefert. Immer.
Unser Leitsatz: The DataBrothers erleben Geschichten, die das
Businessleben für sie bereithält Erfahrungen im Business, die im
wirklichen Leben nicht viel anders sind. Wir haben gelacht,
gestritten, reflektiert. Und immer wieder festgestellt:
Datenprojekte sind keine technischen Projekte, sie sind menschliche
Projekte. Aber echte Weiterentwicklung braucht Pausen, neue Räume,
neue Perspektiven. Wir hören nicht auf, weil es nichts mehr zu
sagen gibt sondern, weil wir uns neuen Themen widmen wollen.
Vielleicht wird daraus kein nächstes The DataBrothers sondern etwas
anderes, ein neues Format, mit frischem Fokus, aus derselben
Leidenschaft geboren. Denn wer sich mit Daten beschäftigt, lernt
irgendwann, dass Veränderung das einzig Stabile ist. Pasadena steht
auch für diesen Moment: Innehalten, zurückschauen, dankbar sein.
Für jede Frage. Jedes Feedback. Jeden Austausch. Wir haben gelernt,
dass man mit Daten viel bewegen kann, aber mit Menschen noch mehr.
Danke für 100 Folgen. Danke fürs Zuhören, fürs Mitdenken, fürs
Mitwachsen. Vielleicht hören wir uns wieder, in einer neuen
Staffel, einem neuen Projekt, oder einfach auf einer Konferenz
irgendwo zwischen Fabric und Realität. Bis dahin gilt: Bleibt
neugierig. Bleibt klar. Und vergesst nicht, manchmal einfach
offline zu gehen. Marcus & Andreas - The DataBrothers. Over and
out.
Mehr
13.10.2025
37 Minuten
Von Translytical bis Self Service, von Modellüberarbeitung bis
Fehlerkultur. In unseren letzten Folgen drehte sich alles um
praktische BI-Herausforderungen und echte Projekterfahrungen. Wir
haben diskutiert, wann Power BI allein nicht mehr reicht, wie man
Fabric effizient nutzt und welche Learnings zehn Jahre Power BI
gebracht haben. Ein Highlight, die FabCon Vienna, mit spannenden
Impulsen zur Zukunft moderner Datenplattformen und natürlich auch
die Frage: Wo stehen wir beruflich und wohin wollen wir uns
entwickeln? Mit diesen Erkenntnissen starten wir in eine neue
Folge, mit dem Ziel, Verantwortung, Technik und Fokus in Einklang
zu bringen. Ist jetzt noch Zeit für ein neues Thema? Nach zehn
intensiven Folgen zu Power BI, Datenkultur und technologischen
Entwicklungen könnte man meinen, wir hätten alles besprochen. Doch
es gibt eine Frage, die über Technik hinausgeht und unser tägliches
Arbeiten direkt betrifft: Zwischen UDFs, dbt und OnPrem, was steht
auf unserer Bucket List? Nach Jahren technischer Entwicklung und
zahllosen BI-Projekten wird deutlich, Verantwortung hört nicht bei
Modellen und Pipelines auf. Ob User Defined Functions, dbt-Modelle
oder OnPrem-Systeme, überall geht es darum, Komplexität zu
beherrschen, ohne den Überblick zu verlieren. Und auch wenn oft von
Cloud-first die Rede ist, OnPremise ist nicht tot, es ist immer
noch intensiv, wichtig und Teil vieler produktiver Architekturen.
Die Cloud geht ihren Weg mit neuen Ideen und mutigen Schritten nach
vorn, aber nicht als Ersatz, sondern als Ergänzung. Auf Konferenzen
wie den SQL days spüren wir, wie sich die BI-Welt verändert: Neue
Tools, neue Rollen, neue Erwartungen. Doch mit jeder Innovation
wächst auch der Druck, Schritt zu halten – und gleichzeitig das
Bestehende zu pflegen. Deshalb geht es in dieser Folge um
Prioritäten, Fokus und das bewusste Setzen von Grenzen – beruflich
wie privat. Und natürlich werfen wir einen Blick auf unsere Bucket
List, die großen Ziele und die kleinen Momente. Beruflich geht es
um spannende Projekte, neue Technologien, vielleicht einen eigenen
Vortrag auf der nächsten SQL days oder den Plan, ein komplexes
Datenmodell endlich sauber in dbt zu überführen. Privat geht’s um
Erlebnisse, die Kraft geben: mal wieder ein Fußballspiel live im
Stadion erleben, mehr Zeit mit der Familie verbringen oder ein
Wochenende komplett offline bleiben, bevor das nächste große
Projekt ansteht. Denn manchmal braucht es genau diesen
Perspektivwechsel, raus aus der Datenwelt, rein ins Leben, um mit
neuer Energie und klarem Fokus zurückzukehren. Und wie sehen es
Andreas und Marcus? Was steht auf ihren Bucket Lists? Welche
Projekte wollen sie noch angehen und wo ist auch mal Zeit,
innezuhalten? Wie gelingt der Spagat zwischen beruflichem Anspruch,
technischer Neugier und persönlicher Balance? Wie immer bekommt ihr
drei, oder vier, praktische Takeaways, ehrlich und authentisch.
Reinhören lohnt sich für alle, die BI machen und dabei Mensch
bleiben wollen.
Mehr
29.09.2025
37 Minuten
In dieser Episode sprechen wir über die Fabcon Vienna. Welche
Features haben uns überrascht, welche Ankündigungen fanden wir
besonders spannend und welche kleinen, fast versteckten Dinge haben
das Potenzial, den Alltag von Entwickler:innen und Datenprofis
massiv zu verändern? Was haben wir mitgenommen? • Copilot überall:
Kaum eine Session ohne KI. Egal ob Entwicklung, Datenmodellierung
oder Administration. Copilot ist inzwischen tief in Fabric
integriert und verändert die Art, wie wir mit der Plattform
arbeiten. • User Defined Functions: Ein Feature, das in den großen
Ankündigungen fast unterging, aber enormes Potenzial bietet. Für
uns ein „Hidden Gem“. • REST-API mit Third-Party-Integration:
Spannend zu sehen, wie offen Fabric inzwischen geworden ist, von
der API bis hin zur Zusammenarbeit mit externen Tools. •
Projektfile-Struktur in Power BI: Endlich mehr Ordnung im
Entwicklungsprozess, die neue Struktur bringt Klarheit,
Nachvollziehbarkeit und erleichtert Teamarbeit enorm. • Visual
Studio Code Add-in: Für viele ein Gamechanger, um Power BI und
Fabric-Entwicklung nahtlos in den gewohnten Entwicklungs-Workflow
zu integrieren. • Featurefeuerwerk am ersten Tag: So viele
Neuheiten in so kurzer Zeit, man merkte, wie schnell Microsoft das
Tempo hochschraubt. Wie sehen es Andreas und Marcus? Für Andreas
war der KI-Schwerpunkt der große Aha-Moment: „Es ist kein Add-on
mehr, Copilot ist fester Bestandteil, das verändert die
Arbeitsweise fundamental.“ Marcus dagegen schwärmt von den kleinen
Dingen: „User Defined Functions klingen unscheinbar, aber wenn man
tiefer einsteigt, merkt man: Damit lassen sich Prozesse viel
schlanker bauen.“ Diskussionsfragen an euch • Welche Ankündigung
der Fabcon Vienna war euer Highlight? • Wo seht ihr den größten
Nutzen von Copilot im Alltag? • Nutzt ihr schon die neue
Projektfile-Struktur in Power BI und wie verändert sie eure
Arbeitsweise? • Habt ihr das Visual Studio Code Add-in getestet und
wie integriert ihr es in eure Prozesse? • Glaubt ihr, dass die
„Hidden Features“ am Ende wichtiger werden als die großen
Ankündigungen? Wir sind gespannt auf eure Eindrücke, teilt sie mit
uns und lasst uns wissen, was für euch das Highlight der Fabcon
war!
Mehr
15.09.2025
37 Minuten
Wir nehmen euch in dieser Episode mit zu genau dieser Frage: Wie
nutzt ihr Fabric effizient und spart CUs dabei? Kein Dogma, sondern
praktische Leitplanken: Woran erkennt man, dass es Zeit ist,
genauer hinzusehen, und welche Ansätze helfen? Zum Beispiel, wenn •
Funktionen im Hintergrund mehr CUs ziehen, als ihr dachtet, • eine
einzelne Abfrage oder ein Feature überproportional Kapazität
frisst, • neue Workloads plötzlich dieselbe Fabric-Instanz teilen
müssen, • ihr merkt, dass ihr CUs nicht gezielt „deckeln“ könnt,
sondern über Architektur und Nutzung steuert, • ihr euer Guthaben
für Leistung immer häufiger nachkaufen müsst. Eine bewusste Nutzung
von Fabric ist kein Selbstzweck. Sie wird dann wichtig, wenn ihr
CUs nicht nur im Tagesgeschäft „verheizt“, sondern gezielt
einsetzt, für die Workloads, die Mehrwert bringen, für geteilte
Instanzen, die sinnvoll organisiert sind, und für Features, die ihr
wirklich braucht. Wie sehen es Andreas und Marcus? Für Marcus ist
das Thema fällig, wenn verschiedene Teams auf derselben Instanz
arbeiten und der Verbrauch unkontrolliert steigt. Sein Punkt:
Nutzung transparent machen, Verbräuche zuordnen, Governance klären,
erst dann habt ihr die Basis, um effizient mit CUs umzugehen. „Ohne
Transparenz bleibt jede Optimierung Zufall.“ Andreas spürt den
Moment, wenn Features wie Streaming, ML-Experimente oder Dataflows
plötzlich die Kapazität dominieren. Für ihn heißt Einsparen:
Workloads konsolidieren, Standardpfade nutzen, Instanzen teilen und
nur dort eigene Ressourcen aufbauen, wo sie wirklich gebraucht
werden. „Fabric belohnt Klarheit: Wer weiß, was läuft, spart.“ Oder
sagen Beide eher: Fachlichkeit und Technik müssen auch hier
zusammenspielen, nur so gelingt es, CUs als gemeinsame Ressource
fair und effizient einzusetzen. Unsere drei Learnings 1. Verbrauch
sichtbar machen. Erst verstehen, welche Komponenten wie viele CUs
benötigen, dann optimieren. 2. Instanzen teilen & Regeln
setzen. Ein Fabric-Service, viele Workloads, klare Governance
verhindert Überlast, Wildwuchs und verteilt die Kosten fair. 3.
Bewusste Nutzung statt Vollgas. Nicht jedes Feature sofort
aktivieren, überdenkt, ob sie echten Mehrwert liefert.
Diskussionsfragen an euch • Wann habt ihr gemerkt, unser
CU-Guthaben schmilzt zu schnell und was war der Auslöser? • Welche
Strategien nutzt ihr, um Verbrauch transparent zu machen? • Teilt
ihr Fabric-Instanzen zwischen Teams und wie regelt ihr dabei
Verantwortung? • Welche Features sind für euch „Must-have“, welche
eher Luxus? • Wie sorgt ihr dafür, dass der Betrieb stabil bleibt,
auch wenn die Kapazität knapp wird? Teilt eure Erfahrungen, von
ersten Monitoring-Ansätzen bis hin zu Regeln für die gemeinsame
Nutzung von Fabric und bringt eure Tipps ein, wie man Leistung
bewusst steuert, statt CUs zu verschwenden. Wir sind gespannt und
freuen uns auf eure Beiträge!
Mehr
01.09.2025
37 Minuten
Wir nehmen euch in dieser Episode mit auf genau diese Schwelle.
Kein Dogma, sondern praktische Leitplanken: Woran erkennt man, dass
es Zeit ist, vom Tool zur Plattform zu denken? Zum Beispiel, wenn •
dieselbe Kennzahl in drei Workspaces drei Bedeutungen hat, •
Refresh-Fenster den Morgen dominieren und jede Änderung Zittern
auslöst, • neue Quellen (API, Stream, Files, ERP) euch zwingen,
Logik mehrmals zu erfinden, • Kunstgriffe oder Workarounds in Power
BI nötig sind, die eine Plattform eleganter lösen könnte, • Audits,
Datenschutz oder Datenfreigaben an Grenzen stoßen, • Verantwortung
und Betrieb auf wenige Personen verteilt sind und Urlaub plötzlich
zur Herausforderung wird, • ihr euch nach Versionierung,
automatischen Tests, Lineage-Transparenz und einem zentralen
Metrik-Katalog sehnt. Eine Datenplattform ist kein Selbstzweck. Sie
wird dann sinnvoll, wenn sie das liefert, was Power BI allein nur
begrenzt abbildet: ein gemeinsames Regelwerk, wiederverwendbare
Logik, kontrollierte Releases, offene Formate, klare Ownership und
die Fähigkeit, mit dem Geschäft zu wachsen, nicht nur mitzuhalten.
Wie sehen es Andreas und Marcus? Bei Marcus ist der
Plattform-Schritt fällig, wenn Definitionen und Zuständigkeiten
wichtiger werden als das nächste visuelle Feature. Sein Punkt:
Business-Regeln, Datenverantwortung, Datenkatalog und
Freigabeprozesse zuerst klarziehen, dann Technik auswählen. „Eine
Plattform ist am Ende ein Versprechen: gleiche Wahrheit, egal wo du
schaust.“ Andreas spürt den Moment, wenn CI/CD, offene Formate (z.
B. Parquet/Delta), Orchestrierung, Dev/Test/Prod und reproducible
Deployments den Unterschied machen. Für ihn ist die Plattform die
Chance, Logik aus Berichten ins Fundament zu ziehen, Abhängigkeiten
sichtbar zu machen und Skalierung ohne Drama zu ermöglichen. Beide
wollen, dass Fachlichkeit und Technik wieder an einem Ort
zusammenfinden, der Code unterstützt das Regelwerk und ersetzt es
nicht. Ob ihr bei Power BI bleibt oder eine Plattform baut,
entscheidet letztlich die Frage, wie ihr dauerhaft konsistente,
nachvollziehbare und skalierbare Antworten liefert. Unsere drei
Learnings 1. Zielbild vor Werkzeug: Erst klären, welche Regeln,
Datenprodukte und Verantwortlichkeiten ihr braucht, dann die
Plattform bauen. 2. Plattform = Betriebsmodell: Nicht „ein
Projekt“, sondern Standards, Automatisierung und Ownership, die
jeden Tag wirken und Lasten verteilen. 3. Wachstum in kleinen
Schritten: Von bestehenden Berichten aus iterativ migrieren:
Katalog, Lineage, Git, Tests – Stück für Stück, aber konsequent.
Diskussionsfragen an euch • Wann habt ihr gemerkt: Power BI only
reicht nicht mehr und was war der Auslöser? • Weiter veredeln oder
Plattform-Schritt? Nach welchen Kriterien entscheidet ihr
(Governance, Skalierung, Performance, Compliance, Teamgröße)? • Wie
sorgt ihr dafür, dass bestehende Berichte während des Umbaus stabil
bleiben? • Welche Methoden/Tools (z. B. Git-Integration,
Autoscaling, Copilot, Lineage-Viewer) helfen euch, Definitionen zu
harmonisieren, Transparenz zu schaffen und Releases zu
automatisieren? • Setzt ihr eher auf offene, austauschbare
Komponenten oder auf vorkonfigurierten Content und warum? • Wie
verteilt ihr Betrieb und Verantwortung im Team und wie verhindert
ihr, dass Urlaub oder Krankheit zum Risiko wird? Teilt eure
Erfahrungen, von der ersten Git-Verzweigung bis hin zum zentralen
Datenprodukt-Katalog und bringt eure Tipps und Perspektiven rund um
Modellpflege, Weiterentwicklung und nachhaltige BI-Lösungen ein.
Wir sind gespannt und freuen uns auf eure Beiträge!
Mehr
Über diesen Podcast
Ein Daten Roadtrip durch das Thema Business Intelligence
Kommentare (0)