0,001 ανά μετοχή: όταν τα δεκαδικά γίνονται επιχειρησιακό πρόβλημα

Σε ένα πληροφοριακό σύστημα είναι εύκολο να θεωρήσουμε ότι οι αριθμοί είναι απλώς αριθμοί. Αν κάποιος έχει 1.000 μετοχές, αποθηκεύουμε 1.000. Και αν μετά από μια εταιρική πράξη δικαιούται 1.125,375, αποθηκεύουμε 1.125,375;

Και κάπου εκεί αρχίζουν τα πραγματικά προβλήματα. Στις κεφαλαιαγορές, το ερώτημα δεν είναι μόνο «πόσο βγαίνει ο υπολογισμός;». Είναι «τι σημαίνει επιχειρησιακά το δεκαδικό αποτέλεσμα». Ας υποθέσουμε ότι μια εταιρεία πραγματοποιεί μια εταιρική πράξη με αναλογία 3 νέες μετοχές για κάθε 8 παλαιές. Και έστω ένας μέτοχος που κατέχει 101 μετοχές. Ο μαθηματικός υπολογισμός είναι απλός: ((101 × 3) / 8) = 37,875. Ο μέτοχος όμως τελικά τι θα πάρει; 37 μετοχές; 38 μετοχες; 37 μετοχές και χρηματικό αντίτιμο για το 0,875; Θα συγκεντρωθούν τα κλασματικά υπόλοιπα όλων των μετόχων και θα πωληθούν; Επιτρέπεται η κατοχή fractional shares στο συγκεκριμένο περιβάλλον; Και σε ποιο ακριβώς στάδιο του υπολογισμού γίνεται η στρογγυλοποίηση;

Αυτές δεν είναι ερωτήσεις μαθηματικών. Είναι business rules. Και εδώ βρίσκεται μία από τις μεγαλύτερες παγίδες στον σχεδιασμό financial software: ο developer βλέπει έναν decimal αριθμό. Το business βλέπει δικαιώματα, χρήματα και υποχρεώσεις.

Το ίδιο πρόβλημα εμφανίζεται στα μερίσματα. Αν ένας μέτοχος δικαιούται μικτό μέρισμα €0,1375 ανά μετοχή και κατέχει 1.003 μετοχές, το αποτέλεσμα είναι €137,9125. Τι πληρώνουμε; €137,91 ή €137,92; Και ακόμη σημαντικότερο: πότε γίνεται η στρογγυλοποίηση; Ανά μέτοχο; Ανά λογαριασμό; Ανά θέση; Ανά transaction; Στο μικτό ποσό; Μετά τον φόρο; Στο τελικό πληρωτέο ποσό; Η διαφορά μπορεί να είναι ένα λεπτό. Κια ένα λεπτό δεν ακούγεται σημαντικό. Πολλαπλασίασέ το όμως επί εκατοντάδες χιλιάδες εγγραφές και ξαφνικά το «ασήμαντο» rounding difference μετατρέπεται σε reconciliation difference που κάποιος πρέπει να εξηγήσει.

Και εκεί εμφανίζεται ένα ακόμη δύσκολο ερώτημα: Ποιος πρέπει να κερδίσει από τη στρογγυλοποίηση; Ο μέτοχος; Η εταιρεία; Ο ενδιάμεσος φορέας; Κανείς; Η σωστή απάντηση δεν πρέπει να βρίσκεται κρυμμένη σε μια γραμμή κώδικα τύπου Round(value, 2). Πρέπει να αποτελεί ρητό, τεκμηριωμένο και ελεγχόμενο επιχειρηματικό κανόνα.

Έχω μάθει να αντιμετωπίζω με ιδιαίτερη καχυποψία λέξεις όπως η λέξη «απλώς» όταν χρησιμοποιούνται σε financial systems. Όπως λόγου χαρη «Απλώς κάνε μια στρογγυλοποίηση.» «Απλώς κόψε τα δεκαδικά.» «Απλώς μοίρασε το συνολικό ποσό στους μετόχους.» Συνήθως πίσω από αυτό το «απλώς» κρύβεται η πραγματική πολυπλοκότητα του συστήματος. Υπάρχει μάλιστα και μία δεύτερη διάσταση. Το συνολικό αποτέλεσμα πρέπει συχνά να συμφωνεί με το άθροισμα των επιμέρους αποτελεσμάτων. Αν διαθέτεις δηλαδή ένα €1.000.000 προς διανομή και οι υπολογισμοί ανά δικαιούχο, μετά τις στρογγυλοποιήσεις, αθροίζουν σε €999.997,63, τα €2,37 δεν μπορούν να εξαφανιστούν επειδή «έτσι προέκυψε από τον αλγόριθμο!». Το σύστημα πρέπει να ξέρει τι θα τα κάνει.

Αυτό είναι το σημείο όπου ένα απλό calculation engine μετατρέπεται σε πραγματικό corporate actions system. Χρειάζεται precision policy, rounding rules, residual handling, reconciliation, auditability και δυνατότητα να εξηγήσει εκ των υστέρων γιατί ένας συγκεκριμένος επενδυτής έλαβε ακριβώς το ποσό που έλαβε.

Και αυτό το τελευταίο είναι ίσως το σημαντικότερο. Σε ένα κρίσιμο χρηματοοικονομικό σύστημα δεν αρκεί να παράγεις το σωστό αποτέλεσμα. Πρέπει να μπορείς να αποδείξεις πώς το παρήγαγες. Γι' αυτό πολλές φορές η πραγματική πολυπλοκότητα των Capital Markets δεν βρίσκεται στα εκατομμύρια. Βρίσκεται στο 0,001.

 



Το Record Date δεν είναι απλώς μια ημερομηνία. Είναι κατάσταση του συστήματος

Στις εταιρικές πράξεις, υπάρχουν ημερομηνίες που φαίνονται απλές μέχρι τη στιγμή που πρέπει να τις μετατρέψεις σε λογική συστήματος. Το Record Date είναι μία από αυτές.

Σε ένα οικονομικό ημερολόγιο εμφανίζεται ως μία ακόμη ημερομηνία: ex-date, record date, payment date. Στην πραγματικότητα όμως το Record Date δεν είναι απλώς ένα σημείο στο ημερολόγιο. Είναι η στιγμή κατά την οποία το σύστημα πρέπει να μπορεί να απαντήσει με ακρίβεια σε μία κρίσιμη ερώτηση: ποιοι είναι οι δικαιούχοι;

Αυτό ακούγεται εύκολο. Δεν είναι.

Ας υποθέσουμε ότι μια εισηγμένη εταιρεία διανέμει μέρισμα. Την ημέρα του Record Date πρέπει να προσδιοριστεί ποιοι μέτοχοι δικαιούνται το ποσό που αντιστοιχεί στη συμμετοχή τους. Για να γίνει αυτό σωστά, δεν αρκεί να έχουμε μια λίστα με τα σημερινά υπόλοιπα. Πρέπει να γνωρίζουμε ποια ήταν η πραγματική κατάσταση της μετοχικής βάσης στη συγκεκριμένη χρονική στιγμή, με βάση τους κανόνες της αγοράς και τα δεδομένα που έχουν οριστικοποιηθεί.

Εδώ ακριβώς αρχίζει η διαφορά ανάμεσα σε μια απλή εφαρμογή και σε ένα σύστημα κεφαλαιαγοράς.

Ένα σωστά σχεδιασμένο shareholder system δεν πρέπει να γνωρίζει μόνο «ποιος έχει πόσες μετοχές». Πρέπει να γνωρίζει πότε αποκτήθηκε ή χάθηκε ένα δικαίωμα, ποια κίνηση είχε ήδη καταστεί αποτελεσματική, ποια βρισκόταν ακόμη σε εκκρεμότητα, ποιο υπόλοιπο θεωρείται έγκυρο για τη συγκεκριμένη εταιρική πράξη και ποια έκδοση της πληροφορίας ήταν γνωστή τη δεδομένη στιγμή.

Με άλλα λόγια, το Record Date μετατρέπει τον χρόνο σε επιχειρισιακό κανόνα.

Και αυτό έχει αρχιτεκτονικές συνέπειες. Αν ένα σύστημα κρατά μόνο την τρέχουσα κατάσταση και ενημερώνει συνεχώς τις εγγραφές του, χάνει ουσιαστικά τη δυνατότητα να ανακατασκευάσει με βεβαιότητα το παρελθόν. Αν όμως το παρελθόν καθορίζει οικονομικά δικαιώματα, τότε η ιστορικότητα δεν είναι “nice to have”. Είναι μέρος της ορθότητας του συστήματος.

Το ίδιο ισχύει και για τις διορθώσεις. Τι γίνεται αν μετά το Record Date εντοπιστεί λάθος σε μια θέση; Αλλάζουμε απλώς το σημερινό υπόλοιπο; Δημιουργούμε διορθωτική κίνηση; Επανυπολογίζουμε τα entitlements; Ποια στοιχεία πρέπει να παραμείνουν αμετάβλητα για λόγους audit; Ποιος εγκρίνει την αλλαγή;

Σε ένα απλό πληροφοριακό σύστημα, μια διόρθωση δεδομένων μπορεί να είναι ένα UPDATE στη βάση. Σε ένα σύστημα που διαχειρίζεται δικαιώματα μετόχων, το ίδιο UPDATE μπορεί να αλλάξει ποιος δικαιούται χρήματα και αξίες.

Γι’ αυτό θεωρώ ότι η έννοια του Record Date είναι ένα πολύ καλό παράδειγμα του πόσο παραπλανητική μπορεί να είναι η φαινομενική απλότητα στο enterprise software.

Ο χρήστης βλέπει μια ημερομηνία.

Ο analyst βλέπει έναν επιχειρηματικό κανόνα.

Ο developer βλέπει ένα πεδίο.

Ο architect όμως πρέπει να βλέπει μια χρονική τομή της πραγματικότητας που πρέπει να μπορεί να αναπαραχθεί, να αποδειχθεί και να ελεγχθεί.

Και ίσως αυτό είναι ένα από τα σημαντικότερα μαθήματα που μου έχουν δώσει τα συστήματα κεφαλαιαγοράς όλα αυτά τα χρόνια: στα mission-critical συστήματα, ο χρόνος δεν είναι metadata. Είναι δεδομένο. Είναι κανόνας. Και μερικές φορές είναι το ίδιο το δικαίωμα.

 



Ποιος πραγματικά δικαιούται το μέρισμα; Η λογική πίσω από ένα Entitlement Engine

Η πληρωμή ενός μερίσματος φαίνεται, εκ πρώτης όψεως, μια απλή διαδικασία. Μια εταιρεία αποφασίζει να διανείμει ένα ποσό, γνωρίζουμε πόσες μετοχές έχει κάθε μέτοχος, πολλαπλασιάζουμε και πληρώνουμε. Αν τα πράγματα ήταν πράγματι τόσο απλά, δεν θα χρειαζόμασταν εξειδικευμένα συστήματα Corporate Actions.

Το πραγματικό ερώτημα δεν είναι «πόσες μετοχές έχει ένας επενδυτής;». Είναι: πόσες επιλέξιμες μετοχές είχε, σε ποια χρονική στιγμή, με ποια δικαιώματα και σύμφωνα με ποιους κανόνες;

Ας υποθέσουμε ότι μια εταιρεία αποφασίζει μέρισμα €0,50 ανά μετοχή. Ένας επενδυτής εμφανίζεται σήμερα να κατέχει 10.000 μετοχές. Δικαιούται €5.000;

Ίσως.

Αν όμως απέκτησε τις μετοχές μετά το κρίσιμο χρονικό σημείο; Αν μέρος των μετοχών δεν συμμετέχει στη συγκεκριμένη διανομή; Αν υπάρχει διαφορετική κατηγορία τίτλων; Αν έχουν προηγηθεί εταιρικές πράξεις που μεταβάλλουν τον αριθμό ή τα δικαιώματα των τίτλων; Αν πρέπει να εφαρμοστεί παρακράτηση φόρου διαφορετική ανά περίπτωση;

Ξαφνικά, ο απλός πολλαπλασιασμός παύει να είναι τόσο απλός!

Και εδώ εμφανίζεται η πραγματική αξία ενός Entitlement Engine.

Ένα τέτοιο σύστημα δεν πρέπει απλώς να υπολογίζει ποσά. Πρέπει να μεταφράζει τους επιχειρηματικούς και κανονιστικούς κανόνες μιας εταιρικής πράξης σε ένα απολύτως επαναλήψιμο και ελέγξιμο αποτέλεσμα.

Στην ουσία απαντά σε τέσσερις ερωτήσεις:

Ποιος; Τι κατέχει; Πότε το κατέχει; Τι δικαιούται;

Και κυρίως πρέπει να μπορεί, ακόμη και μήνες ή χρόνια αργότερα, να εξηγήσει γιατί έδωσε αυτή την απάντηση. Αυτό είναι ένα σημείο στο οποίο τα χρηματοοικονομικά συστήματα διαφέρουν σημαντικά από πολλές συνηθισμένες business εφαρμογές. Δεν αρκεί το αποτέλεσμα να είναι σωστό σήμερα. Πρέπει να μπορούμε να αναπαράγουμε το αποτέλεσμα του χθες. Αν κάποιος ρωτήσει μετά από δύο χρόνια γιατί ένας συγκεκριμένος μέτοχος έλαβε €4.873,42, το σύστημα δεν μπορεί να απαντήσει απλώς: «με βάση τα σημερινά δεδομένα». Πρέπει να γνωρίζει ποια δεδομένα ίσχυαν τότε, ποιοι κανόνες εφαρμόστηκαν, ποια έκδοση αυτών των κανόνων χρησιμοποιήθηκε και πώς προέκυψε το τελικό ποσό. Ακόμη και το rounding, κάτι που στον προγραμματισμό συχνά αντιμετωπίζεται σαν τεχνική λεπτομέρεια, μπορεί εδώ να έχει επιχειρηματική σημασία. Τι συμβαίνει όταν ένα αποτέλεσμα έχει περισσότερα δεκαδικά ψηφία από όσα επιτρέπει το νόμισμα; Στρογγυλοποιούμε ανά μέτοχο ή στο συνολικό ποσό; Τι γίνεται με τα fractions; Πού καταλήγει η διαφορά; Σε ένα εκατομμύριο υπολογισμούς, μια «ασήμαντη» διαφορά ενός λεπτού παύει να είναι ασήμαντη. Το ίδιο ισχύει για φόρους, εξαιρέσεις, blocked positions, ειδικές κατηγορίες δικαιούχων ή διορθώσεις που πραγματοποιούνται αφού έχει ήδη ξεκινήσει η διαδικασία.

Για αυτό θεωρώ ότι ένα Entitlement Engine δεν πρέπει να αντιμετωπίζεται ως μία ακόμη διαδικασία μέσα σε ένα πληροφοριακό σύστημα. Είναι ουσιαστικά μια μηχανή εφαρμογής επιχειρηματικών κανόνων πάνω σε μία συγκεκριμένη κατάσταση της αγοράς και του μητρώου σε συγκεκριμένο χρόνο.

Και εδώ βρίσκεται μια ευρύτερη αρχή που συχνά ξεχνάμε όταν σχεδιάζουμε enterprise software. Η πολυπλοκότητα ενός συστήματος δεν βρίσκεται απαραίτητα στον αριθμό των οθονών του. Μπορεί μια εφαρμογή να έχει πέντε οθόνες και να ενσωματώνει εκατοντάδες κανόνες που έχουν δημιουργηθεί μέσα από χρόνια λειτουργίας, νομοθεσίας, εξαιρέσεων και πραγματικών περιστατικών.

Ο χρήστης βλέπει στο τέλος μία γραμμή: Dividend payable: €4.873,42

Πίσω από αυτή τη γραμμή όμως μπορεί να βρίσκεται ένα ολόκληρο σύστημα αποφάσεων. Και αυτό είναι ίσως ένα από τα πιο ενδιαφέροντα χαρακτηριστικά των συστημάτων που υποστηρίζουν τις κεφαλαιαγορές. Όταν λειτουργούν σωστά, κανείς δεν τα προσέχει. Όταν όμως ένας μόνο κανόνας εφαρμοστεί λάθος, τότε όλοι καταλαβαίνουν πόσο σημαντικά ήταν.

 



Ποιοί ήταν οι μέτοχοι στις 17:00 της 15ης Ιουνίου 2024; Το δύσκολο πρόβλημα του "as-of"

Η ερώτηση ακούγεται απλή: «Ποιοι ήταν οι μέτοχοι της εταιρείας στις 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”.

 



Legacy Systems: Το πρόβλημα δεν είναι ότι είναι παλιά. Είναι ότι κανείς δεν θυμάται γιατί είναι έτσι

Όταν ακούμε τη λέξη legacy, σχεδόν αυτόματα σκεφτόμαστε παλιά τεχνολογία. COBOL, παλιές βάσεις δεδομένων, monolithic εφαρμογές, interfaces άλλης εποχής. Και κάπου εκεί γεννιέται η εύκολη απάντηση. «Πρέπει να το αντικαταστήσουμε». Το πρόβλημα όμως των legacy systems σπάνια είναι μόνο η ηλικία τους. Το πραγματικό πρόβλημα αρχίζει όταν κανείς πλέον δεν θυμάται γιατί λειτουργούν όπως λειτουργούν.

Ένα σύστημα που βρίσκεται είκοσι ή τριάντα χρόνια σε παραγωγή δεν περιέχει μόνο κώδικα. Περιέχει αποφάσεις. Εξαιρέσεις. Συμβιβασμούς. Κανονιστικές απαιτήσεις. Προβλήματα που παρουσιάστηκαν κάποτε και λύθηκαν με έναν συγκεκριμένο τρόπο. Επιχειρησιακούς κανόνες που μπορεί να μην υπάρχουν σε κανένα manual. Κάπου μέσα σε μια συνθήκη if μπορεί να κρύβεται ένα περιστατικό του 2004. Σε ένα database field που «δεν χρησιμοποιείται ποτέ» μπορεί να βασίζεται μια διαδικασία που εκτελείται μία φορά τον χρόνο. Σε ένα batch job που όλοι θεωρούν παράξενο μπορεί να βρίσκεται η λύση ενός reconciliation problem που είχε προκαλέσει σοβαρό operational incident πριν από δεκαπέντε χρόνια.

Το βλέπουμε συχνά στα χρηματοοικονομικά συστήματα. Ένα σύστημα διαχείρισης μετόχων, για παράδειγμα, μπορεί να περιλαμβάνει ειδικούς κανόνες για εταιρικές πράξεις, ιστορικές μεταβολές, φορολογικές εξαιρέσεις ή διαφορετικούς τρόπους υπολογισμού δικαιωμάτων. Ο νέος developer βλέπει complexity. Ο άνθρωπος που σχεδίασε τον κανόνα πριν από είκοσι χρόνια έβλεπε business requirement.

Και εκεί βρίσκεται ο κίνδυνος.

Όταν χαθεί η αιτιολόγηση μιας σχεδιαστικής επιλογής, η πολυπλοκότητα μοιάζει με λάθος. Έτσι, σε ένα modernization project, κάποιος αποφασίζει να «καθαρίσει» τον κώδικα. Η εφαρμογή γίνεται πιο όμορφη, πιο σύγχρονη, πιο cloud-native, και ξαφνικά μια διαδικασία που λειτουργούσε αξιόπιστα για χρόνια σταματά να λειτουργεί σε μια σπάνια αλλά κρίσιμη περίπτωση.

Η παλαιότητα από μόνη της δεν κάνει ένα σύστημα κακό. Υπάρχουν συστήματα δεκαετιών που εκτελούν καθημερινά εκατομμύρια κρίσιμες συναλλαγές με αξιοπιστία που πολλές νεότερες εφαρμογές θα ζήλευαν. Αυτό που τα κάνει επικίνδυνα είναι η απώλεια της οργανωσιακής μνήμης. Ο Parnas είχε ήδη από τη δεκαετία του 1990 περιγράψει το φαινόμενο του software aging. Το software δεν «γερνά» όπως ένα μηχάνημα. Γερνά επειδή αλλάζει ο κόσμος γύρω του και επειδή οι αλλεπάλληλες αλλαγές κάνουν σταδιακά δυσκολότερη την κατανόηση της αρχικής του δομής. Γι' αυτό και η αντικατάσταση ενός legacy system δεν πρέπει να ξεκινά με την ερώτηση «σε ποια νέα τεχνολογία θα το γράψουμε;». Πρέπει να ξεκινά με μια πολύ πιο δύσκολη ερώτηση!

Τι γνωρίζει αυτό το σύστημα που εμείς έχουμε πλέον ξεχάσει;

Πριν από κάθε migration χρειάζεται αρχαιολογία. Κώδικας, δεδομένα, interfaces, logs, documentation, tickets και κυρίως οι άνθρωποι που το έζησαν πρέπει να αντιμετωπιστούν ως πηγές επιχειρησιακής γνώσης. Γιατί πολλές φορές το σημαντικότερο asset ενός legacy system δεν είναι το software. Είναι η ιστορία που έχει αποθηκευτεί μέσα του.

Βιβλιογραφία

  • Bennett, K.H. and Rajlich, V.T. (2000) ‘Software maintenance and evolution: a roadmap’, Proceedings of the Conference on The Future of Software Engineering, pp. 73–87.
  • Cunningham, W. (1992) ‘The WyCash Portfolio Management System’, Proceedings of OOPSLA ’92, New York: ACM, pp. 29–30.
  • Lehman, M.M. (1980) ‘Programs, life cycles, and laws of software evolution’, Proceedings of the IEEE, 68(9), pp. 1060–1076.
  • Parnas, D.L. (1994) ‘Software aging’, Proceedings of the 16th International Conference on Software Engineering, pp. 279–287.
  • Seaman, C. and Guo, Y. (2011) ‘Measuring and monitoring technical debt’, Advances in Computers, 82, pp. 25–46.

 



Το μεγαλύτερο τεχνολογικό χρέος δεν βρίσκεται στον κώδικα. Βρίσκεται στις αποφάσεις που αναβάλαμαι.

Όταν μιλάμε για technical debt, η πρώτη εικόνα που έρχεται συνήθως στο μυαλό είναι παλιός κώδικας, ξεπερασμένες βιβλιοθήκες, πρόχειρα patches και αρχιτεκτονικές που χρειάζονται refactoring. Είναι μια σωστή εικόνα, αλλά όχι ολόκληρη. Γιατί πολλές φορές το μεγαλύτερο τεχνολογικό χρέος μιας επιχείρησης δεν δημιουργήθηκε από έναν developer που έγραψε κακό κώδικα. Δημιουργήθηκε σε μια αίθουσα συσκέψεων, όταν κάποιος είπε «ας το αφήσουμε για αργότερα».

Ο Cunningham (1992), όταν εισήγαγε τη μεταφορά του technical debt, περιέγραψε ουσιαστικά έναν συμβιβασμό. Αποδεχόμαστε σήμερα μια λιγότερο ιδανική λύση για να κερδίσουμε ταχύτητα, γνωρίζοντας ότι κάποια στιγμή θα πρέπει να πληρώσουμε το κόστος. Το πρόβλημα αρχίζει όταν το προσωρινό γίνεται μόνιμο. Και ακόμη περισσότερο όταν κανείς δεν θυμάται πλέον ότι υπήρξε ποτέ απόφαση να διορθωθεί.

Μια επιχείρηση, για παράδειγμα, αποφασίζει να μην αντικαταστήσει ένα παλιό interface μεταξύ δύο κρίσιμων συστημάτων επειδή «λειτουργεί ακόμη». Πέντε χρόνια αργότερα, δέκα νέες εφαρμογές εξαρτώνται από αυτό. Η αντικατάστασή του δεν είναι πλέον ένα μικρό τεχνικό έργο αλλά επιχειρησιακός κίνδυνος. Το χρέος δεν δημιουργήθηκε επειδή το interface ήταν κακό. Δημιουργήθηκε επειδή η απόφαση για τον εκσυγχρονισμό του αναβαλλόταν συστηματικά.

Το ίδιο συμβαίνει με databases που κανείς δεν τολμά να αλλάξει, APIs που σχεδιάστηκαν ως προσωρινά αλλά έγιναν εταιρικό standard, manual διαδικασίες που παρέμειναν επειδή η αυτοματοποίησή τους «δεν είχε αρκετό ROI», ή συστήματα στα οποία μόνο δύο άνθρωποι γνωρίζουν πραγματικά πώς λειτουργούν. Η βιβλιογραφία έχει πλέον διευρύνει σημαντικά την αρχική έννοια του technical debt, αναγνωρίζοντας χρέος στην αρχιτεκτονική, στον σχεδιασμό, στα requirements, στις δοκιμές και στην τεκμηρίωση (Tom, Aurum and Vidgen, 2013· Li, Avgeriou and Liang, 2015).

Υπάρχει όμως και κάτι βαθύτερο. Το decision debt. Κάθε φορά που μια αναγκαία απόφαση μετατίθεται χωρίς συγκεκριμένο σχέδιο επανεξέτασης, δεν αγοράζουμε απλώς χρόνο. Δανειζόμαστε από το μέλλον. Και το μέλλον χρεώνει τόκο.

Αυτός ο τόκος εμφανίζεται ως μεγαλύτερο κόστος αλλαγής, περισσότερο integration complexity, αυξημένος operational risk και μικρότερη δυνατότητα καινοτομίας. Ένα legacy σύστημα μπορεί να λειτουργεί άψογα και παρ' όλα αυτά να αποτελεί στρατηγικό περιορισμό, επειδή ολόκληρος ο οργανισμός έχει προσαρμοστεί γύρω από τους περιορισμούς του. Το technical debt τότε παύει να είναι θέμα της IT Διεύθυνσης. Γίνεται θέμα διοίκησης.

Το ίδιο γίνεται σήμερα ιδιαίτερα εμφανές με το AI. Πολλές επιχειρήσεις ανακαλύπτουν ότι το εμπόδιο για την αξιοποίησή της δεν είναι η έλλειψη ενός καλύτερου μοντέλου. Είναι δεδομένα κλειδωμένα σε παλιά συστήματα, μη τεκμηριωμένα APIs, ασυνεπείς διαδικασίες και αρχιτεκτονικές που σχεδιάστηκαν για έναν κόσμο πολύ διαφορετικό από τον σημερινό.

Το κρίσιμο ερώτημα λοιπόν δεν είναι «πόσο technical debt έχουμε;». Είναι, ποιες αποφάσεις γνωρίζουμε ότι πρέπει να πάρουμε σήμερα και εξακολουθούμε να τις μεταφέρουμε στο αύριο;

Γιατί κάποτε το αύριο φτάνει. Και τότε ο λογαριασμός δεν πληρώνεται μόνο σε γραμμές κώδικα. Πληρώνεται σε χρόνο, ευελιξία, χαμένες ευκαιρίες και στρατηγικές επιλογές που πλέον δεν μπορούμε να κάνουμε.

Βιβλιογραφία

  • Brown, N., Cai, Y., Guo, Y., Kazman, R., Kim, M., Kruchten, P., Lim, E., MacCormack, A., Nord, R., Ozkaya, I., Sangwan, R., Seaman, C., Sullivan, K. and Zazworka, N. (2010) ‘Managing Technical Debt in Software-Reliant Systems’, Proceedings of the FSE/SDP Workshop on Future of Software Engineering Research, pp. 47–52.
  • Cunningham, W. (1992) ‘The WyCash Portfolio Management System’, Proceedings of OOPSLA ’92. New York: ACM, pp. 29–30.
  • Kruchten, P., Nord, R.L. and Ozkaya, I. (2012) ‘Technical Debt: From Metaphor to Theory and Practice’, IEEE Software, 29(6), pp. 18–21.
  • Li, Z., Avgeriou, P. and Liang, P. (2015) ‘A systematic mapping study on technical debt and its management’, Journal of Systems and Software, 101, pp. 193–220.
  • Tom, E., Aurum, A. and Vidgen, R. (2013) ‘An exploration of technical debt’, Journal of Systems and Software, 86(6), pp. 1498–1516.