Es gibt eine Frage, die in jedem Workshop früher oder später kommt: „Brauchen wir diese Komplexität wirklich?" Gemeint ist die bitemporale Historisierung – zwei Zeitlinien statt einer, ein paar Spalten mehr, mehr Logik beim Laden. Die Frage ist berechtigt.
In Projekten und Trainings haben sich acht typische Gründe herauskristallisiert, an denen sich die Antwort entscheidet. Drei davon klingen technisch (Late Arrivals, Korrekturen, Zeitreisen), zwei geschäftlich (Realität jenseits der Gegenwart, rückwirkende Operationen), drei strategisch (Entscheidungsanalyse, Regulatorik, Audit). Welche davon dich treffen, hängt von deiner Architektur ab – und davon, wer in deinem Unternehmen mit den Daten arbeitet.
Dieser Artikel ist der Einstieg in eine vierteilige Serie, die jeden der acht Gründe vertieft. Beispiele kommen wie immer aus dem FastChangeCo-Universum, mit dem ich reale Herausforderungen aus Projekten und Coachings greifbar mache.
Teil 1: Late Arrivals und Korrekturen
Gründe 1 + 3
Wenn die Korrektur vor dem Original ankommt – und die falsche Adresse gewinnt. Warum eine Zeitlinie nicht reicht.
Teil 2: Zeitreisen im Data Warehouse
Grund 4
Allen Relationship und Closed-Open-Intervalle – die Mechanik, die Bitemporalität trägt.
Teil 3: Vergangenheit, Gegenwart, Zukunft
Gründe 2 + 5
Black-Friday-Pricing, rückwirkende Buchungen, HR-Korrekturen: Daten jenseits der Gegenwart.
Erscheint am 10. Juni
Teil 4: Vertrauen, Audits und Nachvollziehbarkeit
Gründe 6 + 7 + 8
Wenn die BaFin morgen fragt: Bitemporal als Governance-Grundlage.
Erscheint am 24. Juni
Aus Erfahrung lohnt sich eine Vorbemerkung: Selbst wenn temporale Daten in einer Datenlösung existieren, wissen viele nicht, warum und wofür man sie nutzen sollte – das gilt für technische wie für kaufmännische Rollen gleichermaßen. Und ein nicht kleiner Teil derer, die täglich mit Daten arbeiten, weiß gar nicht, dass es bitemporale Historisierung überhaupt gibt und was damit möglich wird.
Die Anforderungen, Daten historisiert zu speichern, sind vielfältig. Ein häufig genannter Grund lautet: „Weil wir das jetzt brauchen…!" – und damit ist genau gar nichts gesagt. Die folgenden acht Gründe sind die konkreteren Antworten.
Der erste der acht Gründe macht das Problem direkt greifbar:
Daten kommen gelegentlich außerhalb der Zeitreihe
Grund Nr. 1: Wie kann es passieren, dass Daten nicht in der richtigen zeitlichen Reihenfolge an die Datenlösung geliefert werden?
Vereinfacht ausgedrückt liegt es daran, dass z.B. eine Datenlieferung aus irgendwelchen Gründen ausgefallen ist oder eine verwendete Streaming-Technologie sich nicht primär um die zeitliche Reihenfolge der Datenpakete kümmert. Daher muss das in der Datenlösung – einer temporalen Datenbank – behandelt werden, damit am Ende alle Daten in der richtigen zeitlichen Reihenfolge vorliegen.
→ Vertieft in Teil 1: Wenn Daten nicht sauber ankommen – Late Arrivals und Korrekturen. Dort am durchgehenden E-Mail-Korrektur-Beispiel und am Wechselkurs-Zahlendreher.
Die Realität für Vergangenheit, Gegenwart und Zukunft speichern
Grund Nr. 2: FastChangeCo möchte seine ‚Realität' für die Vergangenheit, die Gegenwart und die Zukunft speichern.
Das ist bei FastChangeCo z.B. dann der Fall, wenn eine Abteilung, die Produkte verkauft, Preise anlegen möchte, die erst ab einem bestimmten Zeitpunkt in der Zukunft gültig sein sollen. Oder wenn eine Information die Vergangenheit ‚aktualisieren' soll – etwa eine rückwirkende Gehaltsänderung.
→ Vertieft in Teil 3: Vergangenheit, Gegenwart, Zukunft – Daten jenseits der Gegenwart (erscheint am 10. Juni). Mit Black-Friday-Pricing und rückwirkenden Gehaltsänderungen.
Korrekturen der Vergangenheit
Grund Nr. 3: FastChangeCo möchte Korrekturen in der Vergangenheit vornehmen.
Das ist bei FastChangeCo z.B. dann der Fall, wenn eine Abteilung von externen Dienstleistern falsche Daten und Werte geliefert bekommen hat. Eine spätere Korrekturlieferung enthält die richtigen Werte. Mit einer bitemporalen Historisierung kann die Vergangenheit dann zeitlich korrekt abgebildet werden – ohne dass man Reports von damals nachträglich umschreibt.
→ Ebenfalls Thema von Teil 1, am Wechselkurs-Zahlendreher: warum nachträgliche Korrekturen die historischen Reports nicht verfälschen dürfen.
Zeitreisen – Fähigkeit zur Abfrage über die Zeit hinweg
Grund Nr. 4: Fachexperten möchten Faktendaten aus unterschiedlichen Zeitperspektiven (As-Is, As-Was, As-Of, …) betrachten.
Bitemporale Historisierung trennt dafür zwei Fragen in zwei Zeitlinien – die Assertion Timeline (technisch: wann wussten wir von einem Wert) und die State Timeline (fachlich: wann war ein Wert in der Realität gültig). Diese Trennung ist die Voraussetzung dafür, dass man überhaupt durch die Zeit reisen kann, ohne dass die Sichten miteinander in Konflikt geraten.
Bei FastChangeCo werden häufig strukturelle Änderungen vorgenommen. In der Planung kann ein Fachexperte z.B. die Umsatz- oder Gewinnverteilung in der Vergangenheit, in der Gegenwart oder auch in einer zukünftigen Organisationsstruktur betrachten. Oder nachvollziehen, wie sich ein Kunde durch die verschiedenen Kundengruppen bewegt hat: Neukunde, VIP-Kunde, Bestandskunde, VIP-Kunde, kein Kunde.
→ Vertieft in Teil 2: Zeitreisen im Data Warehouse – mit Allen Relationship, Closed-Open-Intervallen und der Mechanik, wie sich Zeitperioden zueinander verhalten.
Rückwirkende Operationen
Grund Nr. 5: Die Rechnung muss noch im Vormonat gebucht werden.
Diese Situation tritt bei FastChangeCo auf, wenn z.B. am 4. eines Monats eine Rechnung eintrifft, die ein Rechnungsdatum aus dem Vormonat hat und daher auch in den Vormonat gebucht werden muss. Mit einer bitemporalen Datenhaltung ist das ohne manuellen Aufwand möglich.
→ Ebenfalls Thema von Teil 3 (erscheint am 10. Juni), an rückwirkenden Buchungen und HR-Korrekturen.
Entscheidungsanalyse
Grund Nr. 6: Nachvollziehbarkeit, ob eine Entscheidung in der Vergangenheit ‚richtig' oder ‚falsch' war.
In einigen Bereichen von FastChangeCo ist die Entscheidungsanalyse sehr wichtig. Beispiel: Vor einem Jahr wurde eine Entscheidung getroffen, nun ist ein Jahr vergangen – und niemand weiß mehr, warum diese Entscheidung damals getroffen wurde, weil die Daten, die zu ihr geführt haben, nicht mehr vorhanden sind. Mit den Daten von heute wäre die Entscheidung vielleicht anders ausgefallen.
Mit bitemporalen Daten kann man in die Zeit zurückreisen, um zu überprüfen, ob die Entscheidung zum damaligen Zeitpunkt – mit dem damaligen Wissensstand – richtig war.
→ Vertieft in Teil 4: Vertrauen, Audits und Nachvollziehbarkeit (erscheint am 24. Juni). Mit BaFin-Perspektive und der C-Level-Argumentation für die Investition.
Gesetzliche Regelungen
Grund Nr. 7: Externe Einflüsse wie Gesetze und Vorschriften.
Bei der Entscheidung, ob eine bitemporale Historisierung notwendig ist, spielen Gesetze und Regularien eine wichtige Rolle. Gerade in der Finanz- und Versicherungsbranche gibt es viele Anforderungen an eine unveränderbare, unlöschbare Speicherung von Daten.
→ Ebenfalls Thema von Teil 4 (erscheint am 24. Juni), mit Blick auf Finanz- und Versicherungs-Regulatorik.
Überprüfung und Audit
Grund Nr. 8: Interne und externe Überprüfungen / Audits.
Datenteams müssen sich auf ihre Daten verlassen können. Durch bitemporale Historisierung lässt sich sicherstellen, dass bei jeder Überprüfung die korrekten Daten zur Verfügung stehen. Das gilt für externe Audits genauso wie für interne Beschwerden – z.B. wenn jemand reklamiert, dass sich Daten geändert haben. Das Team kann jederzeit nachweisen und erklären, wie, wann und warum sich Daten im Laufe der Zeit verändert haben.
→ Ebenfalls Thema von Teil 4 (erscheint am 24. Juni), als Kern-Argument für C-Level.
Aus den „nächsten Artikeln" – mit denen der Ursprungs-Artikel endete – ist inzwischen eine vierteilige Serie geworden, die jeden der acht Gründe vertieft. Die Cluster-Kacheln oben führen dich direkt hinein: linear vom Engineering-Schmerz bis zur strategischen Entscheidung, oder gezielt zum Grund, der dich gerade betrifft.
Sicherlich gibt es weitere Gründe für bitemporale Daten als die hier genannten. Wie immer hängt es vom konkreten Projekt, vom Unternehmen oder von gesetzlichen Vorgaben ab, ob noch welche dazukommen.
So long,
Dirk
Über diese Serie: „Bitemporale Daten in der Praxis" führt in vier Teilen vom konkreten Engineering-Schmerz bis zur strategischen Entscheidung. Teil 1 nimmt sich Late Arrivals und Korrekturen vor, Teil 2 die Mechanik der Zeitreisen, Teil 3 (10. Juni) den Geschäftswert jenseits der Gegenwart, Teil 4 (24. Juni) die Governance-Argumentation für C-Level.
Bitemporal in deinem Team verankern
Was diese Serie an Verständnis vermittelt, vertieft und festigt das Temporal Data Training. Der Modul-Aufbau orientiert sich an genau den vier Clustern, die du oben siehst. Das Training wird gerade neu aufgezeichnet.
→ In die Warteliste eintragen (mit Early-Bird-Vorteil als Serien-Leser)