Στα περισσότερα πληροφοριακά συστήματα, η ώρα είναι απλώς ένα ακόμη πεδίο. Στα συστήματα των κεφαλαιαγορών, όμως, μπορεί να είναι επιχειρηματικός κανόνας. Μια εντολή στις 16:59 μπορεί να θεωρείται έγκυρη. Η ίδια ακριβώς εντολή στις 17:01 μπορεί να ανήκει σε διαφορετική επιχειρησιακή ημέρα, να μην συμμετέχει σε μία εταιρική πράξη ή να απαιτεί διαφορετική διαδικασία επεξεργασίας. Η διαφορά είναι μόλις δύο λεπτά!
Η επιχειρηματική συνέπεια μπορεί να είναι πολύ μεγαλύτερη. Αυτό είναι το πραγματικό νόημα ενός cut-off time. Δεν πρόκειται απλώς για μία ώρα που εμφανίζεται σε ένα requirement document. Είναι το χρονικό όριο στο οποίο αλλάζει η κατάσταση μιας διαδικασίας. Ένα χαρακτηριστικό παράδειγμα είναι μια εταιρική πράξη. Μπορεί να υπάρχει συγκεκριμένη ημερομηνία και ώρα μέχρι την οποία γίνονται δεκτές επιλογές από μετόχους ή συμμετέχοντες. Μέχρι εκείνη τη στιγμή, το σύστημα πρέπει να επιτρέπει καταχώριση ή τροποποίηση. Ένα δευτερόλεπτο αργότερα, η ίδια ενέργεια ενδεχομένως πρέπει να απαγορεύεται.
Φαίνεται απλό. Δεν είναι. Ποια ώρα χρησιμοποιούμε; Την ώρα του server; Την τοπική ώρα της αγοράς; Την ώρα του χρήστη; Την ώρα του κεντρικού αποθετηρίου; UTC; Τι συμβαίνει όταν αλλάζει η θερινή ώρα; Τι γίνεται αν ο χρήστης ξεκινήσει τη συναλλαγή πριν από το cut-off αλλά πατήσει submit μετά; Τι συμβαίνει όταν ένα μήνυμα φτάσει στο σύστημα στις 17:00:02 αλλά έχει δημιουργηθεί στις 16:59:58; Και ποια χρονική στιγμή θεωρείται τελικά η επίσημη; Όσο περισσότερο μπαίνει κάποιος στις λεπτομέρειες, τόσο περισσότερο αντιλαμβάνεται ότι το «μέχρι τις 17:00» δεν είναι requirement. Είναι μόνο η αρχή του requirement.
Σε ένα καλά σχεδιασμένο financial system, ο χρόνος πρέπει να αντιμετωπίζεται ως domain concept. Δεν αρκεί ένας έλεγχος της μορφής: “αν current time > 17:00, reject”. Χρειάζεται σαφής ορισμός του business timezone, της operational date, των εξαιρέσεων, της συμπεριφοράς σε αργίες και μη εργάσιμες ημέρες, αλλά και του timestamp που αποτελεί την αποδεκτή απόδειξη ότι μια ενέργεια πραγματοποιήθηκε εγκαίρως.
Και υπάρχει ακόμη μία σημαντικότερη διάσταση: το auditability. Όταν ένας πελάτης, ένας μέτοχος, ένας θεματοφύλακας ή ένας ελεγκτής ρωτήσει μετά από έξι μήνες γιατί μια εντολή έγινε δεκτή και μία άλλη απορρίφθηκε, το σύστημα πρέπει να μπορεί να δώσει απάντηση. Όχι απλώς να εμφανίσει ένα timestamp. Να μπορεί να αναπαραγάγει τον επιχειρηματικό κανόνα που ίσχυε εκείνη τη στιγμή.
Εδώ ακριβώς συναντιούνται το software engineering και το domain knowledge. Ο developer βλέπει ένα DateTime. Ο business analyst βλέπει μία προθεσμία. Ο άνθρωπος που σχεδιάζει όμως ένα mission-critical σύστημα πρέπει να βλέπει κάτι περισσότερο! 'Ενα χρονικό boundary που αλλάζει τη νομική ή επιχειρησιακή κατάσταση μιας συναλλαγής.
Έχω δει πολλές φορές πολύπλοκα συστήματα να δίνουν τεράστια προσοχή στα μεγάλα χαρακτηριστικά τους και πολύ μικρότερη σε τέτοιες λεπτομέρειες. Όμως συχνά οι λεπτομέρειες είναι αυτές που καθορίζουν αν το σύστημα είναι πραγματικά αξιόπιστο. Γιατί στις χρηματοοικονομικές υποδομές δεν αρκεί να γνωρίζουμε τι συνέβη. Πρέπει να γνωρίζουμε και πότε συνέβη. Και μερικές φορές, ακόμη και ένα δευτερόλεπτο μπορεί να αλλάξει την απάντηση.
Δεν υπάρχουν σχόλια:
Δημοσίευση σχολίου