Die langjährigen Mitarbeitenden geben interessante Einblicke in ihre Projekte und ordnen den Architekturaspekt in den Kontext ihrer Projekte ein. Anhand der Interviews wird die hohe Methoden- und Umsetzungskompetenz der in-factory im Bereich Datenarchitekturen und Datenmodellierung von Data Warehouse-Systemen in der Projektpraxis verdeutlicht.
In den verschiedenen Projekten treffen wir auf unterschiedliche Situationen bezogen auf die Architektur („DataVault vs. Klassisches System“) und auf verschiedene Vorgehensmodelle („Agil vs. Wasserfall“) und Entwicklungsprozesse im Bereich des Data Warehousing. Aus den einzelnen Projekten berichten die Kollegen wie folgt.
Carsten Schlotmann – Projekt im Automobilsektor
Carsten Schlotmann – Senior-Consultant
Carsten, kannst Du etwas zu Deiner Person sagen?
Ich bin seit mehr als 12 Jahren bei der in-factory und befasse mich seit über 20 Jahren mit dem Thema Datenintegration und Business Intelligence im weiteren Sinne. Aktuell arbeite ich primär im Bereich der Daten- und Prozessarchitektur und bin – quasi in Personalunion – ein hoffentlich „umtriebiger“ SCRUM-Master in meinem Projekt.
Welches Projekt ist das und was ist Euer Use Case?
Wir befassen uns mit dem Aufbau einer zentralen Integrationsplattform für Kundendaten für einen großen deutschen Automobilkonzern, welche auf einer klassischen Data Warehouse Architektur basiert. Use Case ist die Entgegennahme, Integration und Distribution von Kundendaten zur Unterstützung des Vertriebsprozesses. Diese zentrale Integrationsplattform wird permanent erweitert und angepasst. Projekte mit klaren Rahmenbedingungen wie beispielsweise vorab definierter Aufgabenstellung, mit Start- und Endtermin bilden hierfür die Grundlage.
Letztlich haben wir – getrieben durch priorisierte Use Cases – ein Legacy-System zur Kampagnenunterstützung abgelöst und entwickeln die neue Lösung nun fort, um innovative Vertriebsprozesse (Lead Management) zeitrichtig unterstützen zu können. Das Legacy-System wird dabei parallel weiter betrieben.
Welchen Architekturansatz habt Ihr gewählt und warum?
Das Legacy System hatte Schwächen bezgl. der Skalierbarkeit. Dieses drückt sich primär in einer nicht linear ansteigenden Komplexität bei neuen Use Cases aus. Dem begegnet der Data Vault-Ansatz effektiv, neue Use Cases können in der Regel zügig implementiert werden ohne bestehende Logiken anpassen zu müssen. Zusätzlich bleibt das Modell erklärbar, ein wesentlicher Faktor bei der Qualitätssicherung im Requirement Engineering. Augenfällig ist, dass der Architekturansatz uns unverändert durch eine vollständige Um-Fokussierung des Projekts, von einem batchorientierten Kampagnen-Backend hin zu einer near/realtime Datendrehscheibe für die Leadbearbeitung getragen hat. Das spart sowohl Zeit als auch Geld.
Konkret, wie adaptiert Ihr Eure Datenarchitektur bei Integration neuer Use Cases?
Im einfachsten Fall handelt es sich um Attributergänzungen an bestehenden Satelliten. Das ist aber nicht immer so. In der Regel werden zusätzliche Satelliten an den Hubs und gelegentlich den Link-Tables notwendig. Bei uns ist das Thema Lineage wichtig, die Ergänzungen werden also in die Integrationsschicht und ins Staging gespiegelt, um Transformationsschritte reproduzierbar zu halten. Vorhandene ETL-Strecken bleiben in der Regel unverändert, neue ETL-Strecken können aus den bestehende abgeleitet werden. Prozesse sind nach Vault-Objektklassen organisiert und sind so einfach zu adaptieren.
Wie kann ich mir die Koexistenz von Legacy- und Neusystem vorstellen?
Das neue System wurde ursprünglich für Märkte implementiert, die nicht vom Altsystem abgedeckt waren. Dies hat sich verändert. Aktuell ist die Abgrenzung eher Use Case getrieben. Lead Management wird im Neusystem betrieben. Kampagnen werden größtenteils noch im Legacy System geführt, auch hier findet aber gerade, getrieben durch die Einführung eines neuen Kampagnentools, die Konversion statt.
Was ist das Besondere bei Euch?
Wir sind seit Beginn agil unterwegs und damit sehr erfolgreich. Der Data Vault-Ansatz unterstützt das agile Vorgehen optimal und verzeiht auch die ein oder andere Anpassung in den Requirements. Das stabile Momentum und die hohe Projekttransparenz, die wir aus der Kombination von SCRUM und Data Vault ziehen, stellen das Projekt immer wieder heraus.
