Η ερώτηση ακούγεται απλή: «Ποιοι ήταν οι μέτοχοι της εταιρείας στις 17:20 της 15ης Ιουνίου 2024;» Σε ένα πληροφοριακό σύστημα, όμως, αυτή η ερώτηση μπορεί να είναι πολύ δυσκολότερη από όσο φαίνεται. Αν κοιτάξουμε έναν συνηθισμένο πίνακα μιας βάσης δεδομένων, θα βρούμε ποιοι είναι οι μέτοχοι σήμερα. Θα βρούμε τον αριθμό των μετοχών τους, κάποια στοιχεία ταυτοποίησης και πιθανώς την κατηγορία των τίτλων που κατέχουν.
Αλλά αυτό δεν απαντά στην ερώτηση.
Η πραγματική απαίτηση είναι να μπορέσουμε να ανακατασκευάσουμε την κατάσταση του συστήματος σε μια συγκεκριμένη χρονική στιγμή του παρελθόντος.
Και εδώ αρχίζει το πραγματικό engineering.
Ας υποθέσουμε ότι ένας μέτοχος κατείχε 10.000 μετοχές το πρωί. Στις 14:30 πραγματοποιήθηκε μία μεταβολή και στις 16:59 μία δεύτερη. Ποια ήταν η θέση του στις 17:20; Αν το σύστημα αποθηκεύει μόνο την τρέχουσα κατάσταση, η απάντηση έχει ήδη χαθεί. Το ίδιο πρόβλημα εμφανίζεται όταν διορθωθεί εκ των υστέρων μία εγγραφή. Τι πρέπει να δείξει το σύστημα όταν μας ζητηθεί η εικόνα εκείνης της ημέρας; Την πληροφορία όπως τη γνωρίζουμε σήμερα ή την πληροφορία όπως ήταν καταγεγραμμένη τότε;
Αυτές οι δύο έννοιες δεν είναι πάντα ίδιες.
Στα συστήματα διαχείρισης μετόχων και γενικότερα στα πληροφοριακά συστήματα των κεφαλαιαγορών, ο χρόνος δεν είναι απλώς ένα ακόμη πεδίο στη βάση δεδομένων. Είναι μέρος του επιχειρηματικού μοντέλου. Υπάρχει η ημερομηνία που συνέβη κάτι. Υπάρχει όμως και η ημερομηνία που το σύστημα έμαθε ότι συνέβη. Ένα γεγονός μπορεί, για παράδειγμα, να έχει ισχύ από τις 10 Ιουνίου, αλλά να καταχωρηθεί στις 12 Ιουνίου. Αν στις 15 Ιουνίου μάθουμε ότι η αρχική πληροφορία ήταν λανθασμένη, μπορεί να χρειαστεί να τη διορθώσουμε χωρίς να χάσουμε το ιστορικό του τι γνωρίζαμε μέχρι τότε.
Αυτό είναι το σημείο όπου η απλή έννοια του «history table» αρχίζει να μην αρκεί. Η πραγματική απαίτηση είναι temporal thinking. Κάθε κρίσιμη μεταβολή πρέπει να μπορεί να απαντήσει τουλάχιστον σε δύο ερωτήσεις. Από πότε ισχύει και πότε καταγράφηκε.
Αυτό αποκτά ακόμη μεγαλύτερη σημασία όταν το σύστημα χρησιμοποιείται για εταιρικές πράξεις. Αν πρέπει να υπολογίσουμε ποιοι δικαιούνται ένα μέρισμα, να δημιουργήσουμε voting rights για μια Γενική Συνέλευση ή να αποδείξουμε ποια ήταν η μετοχική σύνθεση σε μια συγκεκριμένη ημερομηνία, δεν μπορούμε να βασιζόμαστε στην τρέχουσα εικόνα.
Χρειαζόμαστε τη σωστή εικόνα του σωστού χρόνου. Και αυτή πρέπει να μπορεί να αναπαραχθεί με τον ίδιο τρόπο ακόμη και χρόνια αργότερα. Εδώ βρίσκεται μία από τις μεγάλες διαφορές ανάμεσα σε ένα απλό business application και σε ένα πραγματικά mission-critical financial system.
Το πρώτο μπορεί να ενδιαφέρεται κυρίως για το «τι ισχύει τώρα». Το δεύτερο πρέπει να μπορεί να εξηγήσει με ακρίβεια και το «τι ίσχυε τότε». Μετά από πολλά χρόνια σχεδιασμού τέτοιων συστημάτων έχω καταλήξει ότι ένα από τα πιο επικίνδυνα λάθη είναι να αντιμετωπίζουμε το historical data ως δευτερεύουσα λειτουργία. Δεν είναι. Σε πολλές περιπτώσεις, είναι μέρος του ίδιου του προϊόντος. Γιατί η πραγματική αξία ενός συστήματος δεν είναι μόνο να γνωρίζει ποιος είναι μέτοχος σήμερα. Είναι να μπορεί να αποδείξει ποιος ήταν μέτοχος τότε, πόσες μετοχές είχε, με ποιο δικαίωμα και βάσει ποιας πληροφορίας.
Και να μπορεί να δώσει ακριβώς την ίδια απάντηση όταν κάποιος κάνει την ίδια ερώτηση πέντε χρόνια αργότερα. Αυτό είναι το πραγματικό πρόβλημα του “as-of”.
