Όταν ακούμε τη λέξη 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.
