Το σύστημά σου λειτουργεί εξαιρετικά. Μέχρι να εργάζεται ο άνθρωπος που ξέρει το γιατί.
Η εταιρεία έχει ένα σύστημα που δημιουργούνταν επί επτά χρόνια. Λειτουργεί. Εξυπηρετεί πελάτες. Συνδέεται με άλλα συστήματα. Εκτελεί διαδικασίες χωρίς τις οποίες η εταιρεία ουσιαστικά δεν θα μπορούσε να λειτουργεί κανονικά.
Κατά τη διάρκεια αυτών των επτά ετών, στο έργο εργάστηκαν πέντε προγραμματιστές. Επιπλέον, δύο freelancers και ένα agency. Μέρος της τεκμηρίωσης βρίσκεται στο Confluence, μέρος στο Google Drive, μέρος στα tickets. Κάπου υπάρχει ακόμη ένα παλιό έγγραφο σχετικά με μία από τις ενσωματώσεις. Και όταν κάποιος ρωτά γιατί ένα συγκεκριμένο τμήμα του συστήματος λειτουργεί ακριβώς με αυτόν τον τρόπο, η απάντηση είναι: "Μάλλον το θυμόταν ο Μιχάλης."
Ο Μιχάλης έφυγε πριν από τρία χρόνια.
Και ακριβώς τότε αρχίζει το πραγματικό πρόβλημα.
Όχι επειδή το σύστημα είναι κακογραμμένο. Όχι επειδή ξαφνικά σταμάτησε να λειτουργεί. Το πρόβλημα είναι ότι η εταιρεία έπαψε να έχει πλήρη γνώση του ίδιου της του συστήματος.
Το σύστημα λειτουργεί, αλλά η εταιρεία μπορεί να μην το ελέγχει
Αυτή είναι μία από τις πιο υποτιμημένες μορφές τεχνολογικού χρέους.
Όταν μιλάμε για τεχνολογικό χρέος, συνήθως σκεφτόμαστε παλιό κώδικα, ξεπερασμένες βιβλιοθήκες, αρχιτεκτονικά λάθη, έλλειψη tests ή λύσεις που κάποτε ήταν γρήγορες, αλλά σήμερα δυσκολεύουν την εξέλιξη.
Ωστόσο, υπάρχει και ένας άλλος τύπος χρέους. Το χρέος γνώσης.
Δημιουργείται όταν ένα σύστημα εξαρτάται από πληροφορίες που δεν βρίσκονται στην τεκμηρίωση, στο αποθετήριο, στις διαδικασίες ή στον οργανισμό, αλλά μόνο στο μυαλό συγκεκριμένων ανθρώπων.
Και όσο αυτά τα άτομα είναι διαθέσιμα, όλα μπορεί να φαίνονται φυσιολογικά.
Το πρόβλημα εμφανίζεται με την αλλαγή ομάδας, την αποχώρηση ενός προγραμματιστή, τη λήξη της συνεργασίας με software house, τη βλάβη server, την αλλαγή διαχειριστή ή την ανάγκη για γρήγορη υλοποίηση μιας νέας λύσης.
Ξαφνικά αποδεικνύεται ότι η εταιρεία έχει κώδικα, αλλά δεν έχει γνώση.
Έχει server, αλλά δεν έχει βεβαιότητα ποιος έχει πρόσβαση.
Έχει ενσωμάτωση, αλλά δεν είναι γνωστό σε ποιον λογαριασμό δημιουργήθηκε.
Έχει τεκμηρίωση, αλλά δεν είναι γνωστό ποια έκδοσή της είναι η τρέχουσα.
Έχει διαδικασία, αλλά δεν είναι γνωστό γιατί σχεδιάστηκε ακριβώς έτσι.
Και τότε πολύ γρήγορα εμφανίζεται το ερώτημα: ποιος είναι τελικά ο ιδιοκτήτης αυτού του συστήματος;
Bus factor, δηλαδή τι θα συμβεί αν εξαφανιστεί ένα άτομο;
Στον κόσμο του IT υπάρχει η έννοια bus factor. Με απλά λόγια, σημαίνει τον αριθμό των ατόμων των οποίων η μη διαθεσιμότητα μπορεί να οδηγήσει στο να μην μπορεί πλέον η ομάδα να αναπτύσσει ή να συντηρεί αποτελεσματικά το έργο.
Δεν πρόκειται φυσικά για κυριολεκτικό γεγονός. Είναι ένας τρόπος σκέψης για τη συγκέντρωση της γνώσης.
Αν μόνο ένα άτομο ξέρει πώς λειτουργεί μια κρίσιμη ενσωμάτωση, το bus factor γι’ αυτή τη γνώση είναι ένα.
Αν μόνο ένας διαχειριστής έχει πρόσβαση στο production, το bus factor είναι ένα.
Αν μόνο ένας άνθρωπος ξέρει γιατί το σύστημα εκτελεί μια συγκεκριμένη διαδικασία κάθε νύχτα, το bus factor μπορεί να είναι ένα.
Αν η εταιρεία συνεργάζεται με εξωτερικό software house και από την πλευρά του πελάτη κανείς δεν κατανοεί την αρχιτεκτονική της λύσης, δημιουργείται ακόμη μεγαλύτερο πρόβλημα - η γνώση μπορεί να βρίσκεται εκτός του οργανισμού.
Αυτό δεν σημαίνει ότι κάθε εταιρεία πρέπει να έχει πέντε ειδικούς για κάθε τμήμα του συστήματος.
Πρόκειται για κάτι πολύ απλούστερο: η εταιρεία πρέπει να ξέρει πού βρίσκεται η κρίσιμη γνώση και αν μπορεί να την ανακτήσει χωρίς το συγκεκριμένο άτομο.
Ο κώδικας λέει το πώς. Όχι πάντα το γιατί.
Ένας προγραμματιστής μπορεί να διαβάσει τον κώδικα και να καταλάβει τι κάνει μια συνάρτηση.
Δεν θα ξέρει όμως πάντα, γιατί γράφτηκε ακριβώς με αυτόν τον τρόπο.
Αυτή είναι τεράστια διαφορά.
Μπορεί να βρεθεί το τμήμα που είναι υπεύθυνο για την αποστολή δεδομένων σε εξωτερικό σύστημα. Μπορεί να αναλυθεί το endpoint, οι παράμετροι, η εξουσιοδότηση και η διαχείριση σφαλμάτων.
Αλλά ο κώδικας δεν θα απαντήσει απαραίτητα στα ερωτήματα:
- Γιατί στέλνουμε τα δεδομένα στις 2:00 τη νύχτα;
- Γιατί παραλείπεται αυτό το συγκεκριμένο status;
- Γιατί μετά από σφάλμα το σύστημα επαναλαμβάνει την προσπάθεια ακριβώς τρεις φορές;
- Γιατί μία τιμή μετατρέπεται πριν από την αποστολή;
- Γιατί δεν μπορεί να αλλάξει η σειρά αυτών των λειτουργιών;
- Γιατί αυτή η ενσωμάτωση χρησιμοποιεί συγκεκριμένο λογαριασμό;
Η απάντηση μπορεί να βρίσκεται στο ιστορικό του έργου, σε ένα παλιό ticket, σε ένα email από πριν από έξι χρόνια ή - ακόμη χειρότερα - αποκλειστικά στη μνήμη του ανθρώπου που δεν εργάζεται πλέον στην εταιρεία.
Γι’ αυτό η καλή τεκμηρίωση δεν πρέπει να είναι μόνο οδηγίες για το "τι να πατήσεις".
Πρέπει να αποθηκεύει επίσης το πλαίσιο και τις αποφάσεις.
Το μεγαλύτερο πρόβλημα μπορεί να είναι μια ενσωμάτωση που κανείς πια δεν θυμάται
Ένα σύγχρονο σύστημα σχεδόν ποτέ δεν λειτουργεί εντελώς αυτόνομα.
Συνδέεται με σύστημα ERP. CRM. Πύλη πληρωμών. Πάροχο SMS. Σύστημα courier. API συνεργάτη. Υπηρεσία cloud. Πλατφόρμα analytics. Λογιστικό σύστημα. Μηχανισμό εξουσιοδότησης.
Κάθε τέτοια σύνδεση είναι μέρος μιας τεχνολογικής αλυσίδας.
Και κάθε μέρος αυτής της αλυσίδας μπορεί να έχει τον δικό του ιδιοκτήτη, λογαριασμό, κλειδί API, πιστοποιητικό, σύμβαση, όριο, έκδοση API και κύκλο ζωής.
Ύστερα από μερικά χρόνια, μπορεί κανείς να μην θυμάται ποιος δημιούργησε τον συγκεκριμένο λογαριασμό.
Και τότε αρκεί η λήξη του πιστοποιητικού ή μια αλλαγή στο API για να πάψει να λειτουργεί το σύστημα.
Ακόμη χειρότερα, αν η εταιρεία δεν ξέρει καν ότι υπάρχει αυτή η εξάρτηση.
Γι’ αυτό, σε μια ώριμη προσέγγιση στα συστήματα, αποκτά όλο και μεγαλύτερη σημασία η προέλευση του λογισμικού, η διαχείριση εξαρτήσεων και η διαφάνεια της αλυσίδας εφοδιασμού λογισμικού. Το NIST, στα τρέχοντα υλικά του για την ασφάλεια της αλυσίδας εφοδιασμού, επισημαίνει μεταξύ άλλων τη σημασία των πληροφοριών για τα components, την προέλευσή τους, τον κύκλο ζωής και τις εξαρτήσεις τους. Το SBOM, δηλαδή Software Bill of Materials, είναι ένα από τα εργαλεία που επιτρέπουν να οργανωθεί η γνώση για το από ποια components αποτελείται το λογισμικό.
Δεν είναι πλέον μόνο θέμα για την ομάδα security.
Είναι επίσης θέμα για τη διοίκηση.
Γιατί αν η εταιρεία δεν ξέρει από τι είναι φτιαγμένο το σύστημά της, δυσκολεύεται να εκτιμήσει τον κίνδυνο, το κόστος συντήρησης και τις συνέπειες των αλλαγών.
Η τεκμηρίωση δεν είναι κόστος. Είναι ασφάλεια.
Σε πολλές εταιρείες η τεκμηρίωση αντιμετωπίζεται ως κάτι που "θα γίνει αργότερα".
Πρώτα η λειτουργικότητα.
Μετά η υλοποίηση.
Μετά οι διορθώσεις.
Μετά το επόμενο έργο.
Και η τεκμηρίωση;
"Όταν θα υπάρχει χρόνος."
Το πρόβλημα είναι ότι ο χρόνος για τεκμηρίωση εμφανίζεται συνήθως όταν είναι ήδη πολύ αργά.
Η τεκμηρίωση θα έπρεπε να λειτουργεί σαν επιχειρηματική ασφάλιση. Όχι επειδή κάποιος θα τη διαβάζει καθημερινά. Αντίθετα - μακάρι να χρειάζεται όσο το δυνατόν σπανιότερα σε μια κατάσταση έκτακτης ανάγκης.
Αλλά όταν προκύψει πρόβλημα, η εταιρεία πρέπει να έχει τη δυνατότητα να απαντήσει σε βασικά ερωτήματα:
- Πώς λειτουργεί το σύστημα;
- Από τι αποτελείται;
- Πού βρίσκεται το περιβάλλον παραγωγής;
- Ποιος έχει πρόσβαση;
- Ποιες είναι οι κρίσιμες ενσωματώσεις;
- Ποιοι εξωτερικοί λογαριασμοί και υπηρεσίες χρησιμοποιούνται;
- Ποιες είναι οι εξαρτήσεις;
- Πώς γίνονται τα αντίγραφα ασφαλείας;
- Πώς μοιάζει η διαδικασία ανάπτυξης;
- Τι συμβαίνει κατά τη διάρκεια μιας βλάβης;
- Ποια στοιχεία είναι κρίσιμα για την επιχείρηση;
- Γιατί ελήφθησαν οι βασικές αρχιτεκτονικές αποφάσεις;
- Ποιος μπορεί να αναλάβει τη συντήρηση του συστήματος;
Αυτό δεν σημαίνει απαραίτητα εκατοντάδες σελίδες τεκμηρίωσης.
Η καλή τεκμηρίωση πρέπει πάνω απ’ όλα να είναι χρήσιμη, ενημερωμένη και διαθέσιμη στα σωστά άτομα.
Το «μην το πειράζουμε, γιατί δουλεύει» δεν είναι πάντα κακή απόφαση
Υπάρχει ακόμη ένα πολύ συχνό πρόβλημα.
Το σύστημα λειτουργεί εδώ και χρόνια, οπότε η εταιρεία υιοθετεί την αρχή: «Δεν το πειράζουμε. Δουλεύει.»
Και μερικές φορές αυτό είναι απολύτως λογικό.
Δεν χρειάζεται κάθε παλιά τεχνολογία άμεση αντικατάσταση. Δεν χρειάζεται κάθε παλιότερο κομμάτι κώδικα να ξαναγραφεί. Δεν σημαίνει κάθε βιβλιοθήκη καταστροφή. Δεν είναι κάθε αρχιτεκτονική πριν από μερικά χρόνια λανθασμένη.
Το πρόβλημα αρχίζει όταν το «μην το πειράζουμε» σημαίνει επίσης:
- «Ας μην αναλύσουμε.»
- «Ας μην τεκμηριώσουμε.»
- «Ας μην ελέγξουμε τις εξαρτήσεις.»
- «Ας μην ρωτήσουμε ποιος έχει πρόσβαση.»
- «Ας μην ελέγξουμε αν εξακολουθούμε να έχουμε όλους τους λογαριασμούς.»
- «Ας μην ορίσουμε τι θα συμβεί αν ο τωρινός συνεργάτης πάψει να είναι διαθέσιμος.»
Τότε η απουσία αλλαγών δεν είναι στρατηγική.
Είναι αναβολή του ρίσκου.
Μερικές φορές η καλύτερη τεχνική απόφαση είναι πράγματι να μην ξαναχτίσεις τίποτα.
Αλλά αυτή η απόφαση πρέπει να προκύπτει από γνώση του συστήματος, όχι από άγνοια του συστήματος.
Τι πρέπει να περιλαμβάνει ο έλεγχος ενός κληρονομημένου συστήματος;
Όταν μια εταιρεία αναλαμβάνει ένα σύστημα από άλλο software house, έναν freelancer ή μια εσωτερική ομάδα, το πρώτο βήμα δεν πρέπει να είναι η αυτόματη επανεγγραφή των πάντων.
Πρώτα πρέπει να γίνει κατανοητό τι ακριβώς έχει αναληφθεί.
Ο έλεγχος θα πρέπει να απαντά τουλάχιστον σε μερικούς βασικούς τομείς.
Αρχιτεκτονική. Πώς είναι δομημένο το σύστημα; Ποια είναι τα κύρια συστατικά του; Πού βρίσκονται τα δεδομένα; Πώς επικοινωνούν τα επιμέρους στοιχεία;
Κώδικας και αποθετήρια. Διαθέτει η εταιρεία τον πλήρη πηγαίο κώδικα; Είναι γνωστό ποιο branch και ποια έκδοση είναι σε παραγωγή; Μπορεί να αναπαραχθεί η διαδικασία build και deployment;
Υποδομή. Πού λειτουργεί η παραγωγή; Πώς μοιάζει το περιβάλλον δοκιμών; Ποιος έχει πρόσβαση; Πώς είναι η παρακολούθηση και το backup;
Ενσωματώσεις. Με τι επικοινωνεί το σύστημα; Ποια API χρησιμοποιεί; Ποιος είναι ο ιδιοκτήτης των επιμέρους λογαριασμών και κλειδιών;
Εξαρτήσεις. Ποιες βιβλιοθήκες, frameworks και εξωτερικά στοιχεία χρησιμοποιούνται; Ενημερώνονται; Έχουν γνωστά θέματα ασφάλειας; Πώς είναι ο κύκλος ζωής τους;
Διαδικασία ανάπτυξης. Μπορεί ένα νέο άτομο να προετοιμάσει, να δοκιμάσει και να αναπτύξει μια αλλαγή χωρίς να τηλεφωνήσει στον πρώην προγραμματιστή;
Γνώση. Τι υπάρχει στην τεκμηρίωση και τι εξακολουθεί να υπάρχει μόνο στα μυαλά των ανθρώπων;
Επιχειρηματικό ρίσκο. Τι θα συμβεί αν ένα συγκεκριμένο στοιχείο πάψει να λειτουργεί για μία ώρα, μια μέρα ή μια εβδομάδα;
Η σύγχρονη προσέγγιση στην ασφάλεια της αλυσίδας εφοδιασμού λογισμικού τονίζει όλο και περισσότερο ακριβώς αυτή την ανάγκη για γνώση των στοιχείων, των προμηθευτών, των εξαρτήσεων, της προέλευσής τους και του κύκλου ζωής τους. Το NIST επισημαίνει επίσης τη σημασία του due diligence απέναντι στους τεχνολογικούς προμηθευτές και της αξιολόγησης της ανθεκτικότητας και του κινδύνου που σχετίζεται με ολόκληρη την αλυσίδα εφοδιασμού.
Ο έλεγχος δεν σημαίνει «ας ξαναγράψουμε το σύστημα από την αρχή»
Αυτό είναι σημαντικό, επειδή ο τεχνικός έλεγχος συχνά συγχέεται λανθασμένα με την ανακατασκευή.
Στην πραγματικότητα, ο έλεγχος μπορεί να καταλήξει σε ένα πολύ απλό συμπέρασμα: «Το σύστημα είναι εντάξει. Χρειάζεται μόνο να οργανωθεί η γνώση και να απομακρυνθούν μερικά ρίσκα.»
Μπορεί επίσης να αποδειχθεί ότι το σύστημα χρειάζεται εκσυγχρονισμό μόνο σε έναν τομέα.
Ή ότι το μεγαλύτερο πρόβλημα δεν είναι ο κώδικας, αλλά η έλλειψη πρόσβασης στην υποδομή.
Ή ότι η εφαρμογή είναι καλά γραμμένη, αλλά κανείς δεν έχει ενημερωμένη γνώση για τη διαδικασία ανάπτυξης.
Ή ότι όλα λειτουργούν, αλλά η εταιρεία εξαρτάται από έναν μόνο εξωτερικό προμηθευτή.
Γι’ αυτό η καλή ανάλυση ενός κληρονομημένου έργου θα πρέπει να απαντά στο ερώτημα: «Τι πρέπει πραγματικά να αλλάξει και τι δεν χρειάζεται να αγγιχτεί;»
Μόνο τότε μπορούν να ληφθούν επενδυτικές αποφάσεις.
Και τι γίνεται αν αλλάζεις software house;
Αυτή είναι μία από τις στιγμές που το πρόβλημα του αόρατου χρέους γνώσης έρχεται στην επιφάνεια.
Η εταιρεία λήγει τη συνεργασία με τον ανάδοχο.
Ο νέος συνεργάτης παραλαμβάνει το repository.
Και αρχίζει να κάνει ερωτήσεις:
- «Πού είναι η παραγωγή;»
- «Πώς τρέχω το project τοπικά;»
- «Ποια έκδοση είναι η τρέχουσα;»
- «Σε τι χρησιμεύει αυτή η υπηρεσία;»
- «Ποιος έχει τον λογαριασμό για αυτό το API;»
- «Τι κάνει αυτό το cron;»
- «Γιατί ξεκινά αυτή η διαδικασία εκείνη την ώρα;»
- «Από πού παίρνουμε αυτή την παράμετρο;»
- «Τι θα συμβεί αν το απενεργοποιήσουμε;»
Αν η απάντηση στις περισσότερες ερωτήσεις είναι «δεν ξέρουμε», το νέο software house δεν αναλαμβάνει το έργο. Πρώτα πρέπει να το ανακαλύψει.
Και η ανακάλυψη του συστήματος κοστίζει χρόνο. Χρόνο που τελικά πληρώνει ο πελάτης.
Γι’ αυτό η παράδοση ενός έργου μεταξύ ομάδων πρέπει να είναι διαδικασία, όχι πέταγμα ενός ZIP με τον κώδικα και τους κωδικούς πρόσβασης σε έναν λογαριασμό.
Το σύστημα πρέπει να επιβιώνει των ανθρώπων
Αυτή είναι ίσως η πιο σημαντική αρχή.
Οι άνθρωποι αλλάζουν. Οι προγραμματιστές αλλάζουν δουλειά. Οι freelancers λήγουν τη συνεργασία τους. Τα software houses αλλάζουν πελάτες. Οι διαχειριστές μετακινούνται σε άλλες εταιρείες. Οι διοικήσεις αλλάζουν.
Το σύστημα παραμένει.
Γι’ αυτό το σύστημα πρέπει να είναι σχεδιασμένο έτσι ώστε η γνώση που χρειάζεται για τη συντήρησή του να μπορεί να ανακτηθεί.
Αυτό δεν σημαίνει ότι κάθε εργαζόμενος πρέπει να ξέρει τα πάντα.
Σημαίνει ότι ο οργανισμός πρέπει να διαθέτει μηχανισμό αποθήκευσης γνώσης:
- Αποθετήρια.
- Τεκμηρίωση.
- Μητρώο ενσωματώσεων.
- Πληροφορίες για την υποδομή.
- Προσβάσεις διαχειριζόμενες από την εταιρεία.
- Περιγραφή βασικών διαδικασιών.
- Ιστορικό σημαντικών αποφάσεων.
- Πληροφορίες για τις εξαρτήσεις.
- Διαδικασίες έκτακτης ανάγκης.
- Και πάνω απ’ όλα - ανθρώπους που μπορούν να αξιοποιήσουν αυτή την τεκμηρίωση.
Το NIST στις τρέχουσες οδηγίες του για τον σχεδιασμό ασφάλειας συστημάτων επισημαίνει επίσης τον επίσημο καθορισμό των ευθυνών, της λειτουργικής κατάστασης του συστήματος και των ρόλων των ατόμων που το διαχειρίζονται, το υποστηρίζουν ή έχουν πρόσβαση σε αυτό.
Αυτό δείχνει μια ευρύτερη αλλαγή στον τρόπο σκέψης για την τεχνολογία.
Το σύστημα δεν είναι μόνο κώδικας. Το σύστημα είναι επίσης οι άνθρωποι, οι διαδικασίες, η υποδομή, οι εξαρτήσεις, τα δεδομένα, η πρόσβαση και η ευθύνη.
Στη Web24 συχνά ξεκινάμε ακριβώς με το ερώτημα: «Τι έχουμε εδώ στην πραγματικότητα;»
Η ανάληψη ενός υπάρχοντος έργου δεν πρέπει να ξεκινά με την υπόσχεση ότι όλα θα ξαναγραφτούν από την αρχή.
Θα πρέπει να ξεκινήσει με την κατανόηση της κατάστασης:
- Τι λειτουργεί;
- Τι δεν λειτουργεί;
- Τι είναι κρίσιμο;
- Τι είναι ξεπερασμένο;
- Πού βρίσκονται οι μεγαλύτεροι κίνδυνοι;
- Τι λείπει από την τεκμηρίωση;
- Ποιες εξαρτήσεις είναι αόρατες;
- Μπορεί το υπάρχον σύστημα να αναπτυχθεί με ασφάλεια;
- Χρειάζεται εκσυγχρονισμός ή μόνο τακτοποίηση;
Μόνο τότε μπορεί κανείς να αποφασίσει αν το έργο πρέπει να αναπτυχθεί, να ανακατασκευαστεί, να ξαναγραφτεί εν μέρει ή απλώς να τεκμηριωθεί σωστά.
Αυτό είναι ιδιαίτερα σημαντικό σε έργα που για χρόνια αναπτύχθηκαν από διαφορετικούς ανθρώπους και διαφορετικές εταιρείες.
Γιατί ένας καλός τεχνολογικός συνεργάτης δεν θα πρέπει να είναι απαραίτητος επειδή μόνο εκείνος ξέρει πώς λειτουργεί το σύστημα.
Θα πρέπει να είναι απαραίτητος επειδή μπορεί να αναπτύξει αυτό το σύστημα, να το θωρακίσει και να μεταφέρει τη γνώση παρακάτω.
Το πιο επικίνδυνο λάθος μπορεί να είναι ο άνθρωπος που έχει ήδη φύγει
Δεν είναι πάντα το παλιό code το πρόβλημα.
Δεν είναι πάντα η ξεπερασμένη τεχνολογία το πρόβλημα.
Δεν είναι πάντα η έλλειψη του πιο πρόσφατου framework το πρόβλημα.
Μερικές φορές ο μεγαλύτερος κίνδυνος είναι η πληροφορία που κανείς δεν κατέγραψε.
Μία φράση.
Μία αρχιτεκτονική απόφαση.
Μία ενσωμάτωση.
Μία εξαίρεση στη διαδικασία.
Ένας άνθρωπος που για χρόνια ήξερε πώς λειτουργεί.
Και ύστερα έφυγε.
Γι' αυτό αξίζει να θέσετε σήμερα στον εαυτό σας μια πολύ απλή ερώτηση: Αν αύριο εξαφανιζόταν από την εταιρεία το άτομο που γνωρίζει καλύτερα το σύστημά σας, θα μπορούσατε ακόμη να το διαχειρίζεστε;
Αν η απάντηση είναι "ναι" - εξαιρετικά.
Αν είναι "δεν ξέρω" - αξίζει να το ελέγξετε.
Και αν είναι "σίγουρα όχι" - πιθανότατα μόλις εντοπίσατε έναν από τους σημαντικότερους τομείς τεχνολογικού κινδύνου στην εταιρεία σας.
Το σύστημα πρέπει να είναι μεγαλύτερο από τη μνήμη ενός ανθρώπου.
