Von der Datenstrategie über Architektur, Data Engineering und Use Cases bis in den Betrieb. Wir bauen die Plattform, die Ihr Team danach selbst weiterentwickelt.
In den meisten Unternehmen ist die Datenlandschaft über Jahre gewachsen. Für jede neue Anforderung kam eine weitere Datenpipeline dazu, häufig mit eigenem Werkzeug und eigener Berechnung derselben Kennzahl. Langfristig skaliert dieser Ansatz nicht. Zahlen aus mehreren Systemen müssen in Abstimmungsrunden abgeglichen werden, und oft bleibt unklar, welche Kennzahl die richtige ist. Mit jedem weiteren Use Case für Analytics, Automatisierung, Apps und KI wächst dieser Abstimmungsaufwand, und die gewachsene Datenlandschaft stößt an ihre Grenzen.
Auf einer Data- & AI-Plattform laufen die Daten aller relevanten Quellsysteme an einer Stelle zusammen und werden dort einmal bereinigt, historisiert und zu einer gemeinsamen Sicht zusammengeführt. Analytics, Automatisierung, Apps und KI greifen anschließend auf dieselbe Basis zu. Wir bauen solche Plattformen auf Azure Databricks, von der ersten Architekturskizze bis in den produktiven Betrieb.
Damit die Plattform trägt, müssen Datenarchitektur und Datenmodell zu Ihren Quellsystemen passen.
Azure Databricks
Sechs Bausteine bilden das Fundament, darauf entstehen Ihre Use Cases.
SAP, Microsoft Dynamics 365, Salesforce, MES- und Logistiksysteme, Dateien, APIs und weitere Quellen. Wir wählen je Quelle das passende Verfahren, von Batch über Change Data Capture bis Streaming, und legen die Rohdaten unverändert ab, damit jede spätere Auswertung gegen den Ursprung prüfbar bleibt.
Die Architektur legt fest, wie die Daten von Bronze über Silver bis Gold aufbereitet werden und wie Kataloge, Umgebungen und Compute in Azure Databricks zugeschnitten sind. Beim Datenmodell entscheidet die Wahl zwischen Kimball, Hybrid und Data Vault 2.0, wie gut die Plattform mit neuen Quellen und Anforderungen mitwächst. Wir treffen sie anhand Ihrer Quellsysteme, Ihrer Historisierungspflichten, der späteren Nutzung und der Erfahrung in Ihrem Team und legen die Abwägung offen.
Datenpipelines mit dbt oder Lakeflow, versioniert in Git und automatisiert ausgerollt über Entwicklung, Test und Produktion, mit Tests auf Schlüssel, Beziehungen und fachliche Plausibilität. Orchestrierung, Fehlerbehandlung und Wiederanlauf sind von Anfang an Teil davon.
Zugriffsrechte bis auf Zeilen- und Spaltenebene und nachvollziehbare Herkunft jeder Kennzahl, auf Azure Databricks über Unity Catalog. Dazu Monitoring der Datenpipelines, Kostenkontrolle und eine abgesicherte Azure-Umgebung mit Netzwerk- und Identitätskonzept. Wie sich das bis in die Auswertung fortsetzt, steht auf Analytics & Self-Service BI.
Ihr Team arbeitet vom ersten Sprint an mit, nicht erst bei der Übergabe. Konventionen werden dokumentiert, Entscheidungen begründet festgehalten, und die Verantwortung wandert schrittweise ins Haus.
Meist bestehen bereits ein Data Warehouse, Ladeprozesse oder Berichte, die weiterlaufen müssen. Ein reiner Umzug geht schnell, übernimmt aber auch deren bekannte Schwächen. Wir nehmen die vorhandene Landschaft deshalb zuerst auf und entscheiden je Ladeprozess: unverändert übernehmen, überarbeiten oder im Zielmodell neu aufbauen. Was neu entsteht, legen wir auf kurze Laufzeiten und niedrige Betriebskosten aus. Umgestellt wird Geschäftsobjekt für Geschäftsobjekt, Alt und Neu laufen eine Zeit lang parallel und werden verglichen, bevor der alte Ladeprozess abgeschaltet wird.
Auf dem Fundament laufen Berichte und Self-Service BI, Automatisierungen wiederkehrender Abläufe, Apps für Fachbereiche und KI-Anwendungen. Berichte entstehen in Power BI direkt auf den Daten in Azure Databricks, Fragen in natürlicher Sprache beantwortet Genie. Jeder neue Use Case nutzt die Daten und Regeln der bestehenden mit. Mehr dazu unter Analytics & Self-Service BI und KI-Anwendungen & Automatisierung.
Der zweite Baustein oben, die Wahl zwischen Kimball, Hybrid und Data Vault 2.0, ist die Entscheidung mit der längsten Wirkung. Unser Kompass stellt Ihnen dazu 15 bis 18 Fragen und liefert in fünf bis zehn Minuten eine begründete Ersteinschätzung samt Beispielobjekten und Abwägungen.
Vier Phasen. Die erste liefert eine Entscheidungsgrundlage, ab der zweiten entsteht etwas Produktives.
Die Datenstrategie legt fest, welche Use Cases zuerst kommen und welche Architektur und welches Datenmodell sie brauchen.
Datenstrategie bieten wir nicht als eigenes Vorhaben mit Abschlussbericht an. Bei uns ist sie der erste Schritt, Use Cases und Roadmap, und beantwortet die Fragen, aus denen die Zielarchitektur folgt:
Am Ende dieser Phase stehen eine Zielarchitektur, eine begründete Modellierungsentscheidung, eine priorisierte Reihenfolge der Use Cases und eine realistische Aufwandseinschätzung für die erste Ausbaustufe. Auf dieser Grundlage entscheiden Sie über den nächsten Schritt.
Was uns unterscheidet:
Wir arbeiten mit einer Plattform und kennen sie in der Tiefe, auch die neuen Funktionen. Sie profitieren von Erfahrung aus Projekten, die bereits im Betrieb sind.
Sie arbeiten durchgehend mit erfahrenen Architekten, die Konzeption und Implementierung selbst verantworten. Große Projektteams und lange Abstimmungswege fallen weg.
Aus unseren Projekten bringen wir Architektur-Blueprints, Vorlagen und Code-Pakete mit. Ihr Projekt startet nicht bei null, und Use Cases gehen damit in Wochen statt Monaten live.
Wir befähigen Ihre Teams, die Plattform eigenständig weiterzuentwickeln.
Zum Aufbau gehören sechs Bausteine für das Fundament:
Darauf entstehen die Use Cases. Was dafür gebaut wird, hängt von der Art des Use Case ab:
Am häufigsten unterschätzt werden Governance und Betrieb. Beim ersten Use Case fallen sie kaum ins Gewicht, mit mehreren Use Cases, mehr Nutzern und wachsender Komplexität entscheiden sie darüber, ob die Plattform stabil und wirtschaftlich bleibt.
Die erste Phase mit Use Cases und Roadmap dauert zwei bis vier Wochen. Danach geht der erste Use Case in der Regel nach vier bis acht Wochen in Betrieb, zusammen mit dem Fundament der Plattform aus Datenmodell, Governance und den ersten Datenpipelines. Anschließend wächst die Plattform in Stufen, je Stufe ein Fachbereich oder Use Case, der für sich produktiv geht. Am meisten Zeit kosten erfahrungsgemäß Zugänge und Abstimmungen, etwa die Netzwerkfreigaben für die Azure-Umgebung oder die Einigung auf eine Kennzahl über mehrere Bereiche. Beides klären wir deshalb schon in der ersten Phase. Wird ein bestehendes Data Warehouse abgelöst, laufen Alt und Neu zusätzlich eine Zeit lang parallel.
Die Kosten bestehen aus dem Projekt und dem laufenden Betrieb der Plattform. Im Projekt kostet die erste Phase mit Use Cases und Roadmap ab 4.750 € zzgl. MwSt. Für den ersten Use Case erhalten Sie danach ein Angebot, weitere Use Cases rechnen wir nach Aufwand ab. Die Plattform selbst rechnet Microsoft nach Verbrauch über Ihr Azure-Konto ab: Azure Databricks in Databricks Units (DBU) für die genutzte Rechenleistung, bei klassischem Compute zusätzlich die virtuellen Maschinen, dazu Speicher und Netzwerk. Die Höhe hängt vor allem von Datenmenge, Ladefrequenz und Zahl der Abfragen ab, eine Schätzung ist Teil der ersten Phase. Wir richten die Plattform so ein, dass sich ungenutzte Rechenleistung automatisch abschaltet und der Verbrauch je Use Case sichtbar ist. Bei gleichmäßiger Last senkt ein Vorabkauf von Databricks Commit Units für ein oder drei Jahre den Preis je DBU.
Beides kommt vor. Bei einem Neuaufbau lassen sich Architektur und Datenmodell am leichtesten festlegen, weil noch nichts umgebaut werden muss. Läuft bereits eine Plattform produktiv, ist ein Komplettumbau selten sinnvoll. Dann bauen wir auf dem Bestehenden auf und ersetzen einzelne Teile schrittweise, während der Betrieb weiterläuft.
Für die Ablösung kommen drei Ansätze in Frage:
Welcher Ansatz passt, hängt vor allem davon ab, wie viel Zeit bis zum Ende von Lizenzen oder Support des Altsystems bleibt, in welchem Zustand die bestehende Logik ist und welche Use Cases die Plattform künftig tragen soll. Oft fällt die Wahl je Bereich unterschiedlich aus. Wir beraten Sie dazu auf Grundlage der Bestandsaufnahme und legen die Abwägung offen.
Unabhängig vom Ansatz lösen wir schrittweise ab, während das bestehende System weiterläuft:
Historie, die in den Quellsystemen nicht mehr vorliegt, übernehmen wir einmalig aus dem alten Data Warehouse. Vorhandene SQL-Logik lässt sich teilweise automatisch übersetzen, etwa mit Lakebridge von Databricks. Auch diese Ergebnisse laufen durch den Abgleich.
Die Datenstrategie ist bei uns die erste Phase des Aufbaus. Sie klärt, welche Fragen die Plattform beantworten, welche Probleme sie lösen und welche Entscheidungen sie stützen soll, welche Quellen dafür nötig sind, welche Anforderungen an Historisierung und Nachweisbarkeit bestehen und in welcher Reihenfolge Use Cases kommen. Daraus folgt die Zielarchitektur.
Vor allem Zugänge und die richtigen Ansprechpartner. Aus der IT brauchen wir Zugriff auf die Quellsysteme und die Azure-Umgebung, Freigaben für Netzwerk und Sicherheit und je Quellsystem eine Ansprechperson für Fragen zu Feldern und Sonderfällen. Aus den Fachbereichen brauchen wir Personen, die die Prozesse kennen und fachlich entscheiden dürfen, etwa wie eine Kennzahl berechnet wird oder wann ein Vorgang als abgeschlossen gilt. Außerdem sollte auf Ihrer Seite eine verantwortliche Person Prioritäten setzen und Entscheidungen herbeiführen. Bei personenbezogenen Daten binden wir Datenschutz und, wo nötig, den Betriebsrat früh ein. In der ersten Phase sind das einzelne Termine, während des Aufbaus ein regelmäßiger kurzer Austausch. Soll Ihr Team die Plattform später selbst weiterentwickeln, planen Sie zusätzlich Zeit für die Mitarbeit ein, denn daraus entsteht die Eigenständigkeit.
Nicht zwingend. Wir können Aufbau und Betrieb übernehmen und die Plattform später mit Dokumentation und Einarbeitung an Ihr Team übergeben. Wann und in welchem Umfang, stimmen wir mit Ihnen ab.
Unser Ziel ist der Eigenbetrieb durch Ihr Team. Deshalb gehört Enablement von Anfang an in den Plan: dokumentierte Konventionen, gemeinsames Arbeiten am realen Code statt Frontalschulung, und eine schrittweise Übergabe der Verantwortung. Danach begleiten wir auf Abruf, etwa bei der Anbindung weiterer Quellsysteme, bei Architekturfragen oder bei der nächsten Ausbaustufe.
Ja, die Bausteine sind dieselben: Anbindung, Datenmodell, Datenverarbeitung, Governance und Betrieb. Wir bauen auf Azure Databricks, weil es bei Data Engineering und KI mehr Möglichkeiten bietet. Microsoft Fabric nimmt als SaaS mehr Betrieb ab und macht die Kosten über die gebuchte Kapazität planbar. Wann Fabric die bessere Wahl sein kann, steht in unserem Vergleich „Microsoft Fabric oder Azure Databricks?“.
Schichtenmodell, Datenmodell und Datenqualität einer Plattform, ausführlich erklärt in unserem Blog.
„Sanalytics hat uns bei der Modernisierung unserer Datenplattform und unseres Reportings begleitet. Zudem unterstützten sie uns bei der Evaluierung von KI-Lösungen sowie bei der Entwicklung von Prototypen. Dank ihrer Unterstützung gelang der reibungslose Übergang zu einer skalierbaren Datenplattform für Group Finance mit höherer Datenqualität, besserer Performance und verbesserter Wartbarkeit.“
David Sanadze
Gründer & Solutions Architect – Data & AI
Die ersten Entscheidungen wirken am längsten nach, ob Sie neu anfangen oder Legacy-Systeme ablösen.
In 30 Minuten klären wir:
