Το σύστημά σου λειτουργεί εξαιρετικά. Μέχρι να δουλεύει το άτομο που ξέρει το γιατί.
Φαντάσου μια εταιρεία που έχει ένα σύστημα το οποίο λειτουργεί εδώ και επτά χρόνια. Δημιουργήθηκε σταδιακά. Πρώτα το έφτιαξε ένα software house. Μετά ένα μέρος ανέλαβε ένας freelancer. Αργότερα μια άλλη ομάδα πρόσθεσε το module B2B. Μια επόμενη εταιρεία σύνδεσε το CRM. Κάποιος άλλος διασύνδεσε τις πληρωμές.
Το σύστημα λειτουργεί.
Η εταιρεία κερδίζει χρήματα χάρη σε αυτό.
Οι εργαζόμενοι το χρησιμοποιούν καθημερινά.
Οι πελάτες ούτε καν ξέρουν πόσες διαδικασίες συμβαίνουν στο παρασκήνιο.
Υπάρχει όμως ένα πρόβλημα.
Κανείς πια δεν ξέρει ακριβώς, πώς λειτουργεί όλο αυτό.
Η τεκμηρίωση είναι εν μέρει στο Confluence. Κάτι έμεινε στο Google Drive. Μερικές πληροφορίες βρίσκονται στα tickets. Μια ενσωμάτωση περιγράφηκε σε ένα email πριν από τέσσερα χρόνια.
Και το πιο σημαντικό πράγμα "μάλλον το θυμόταν ο Łukasz".
Μόνο που ο Łukasz έφυγε πριν από τρία χρόνια.
Και για τρία χρόνια δεν συνέβη τίποτα.
Μέχρι ένα πρωινό Τρίτης.
Το σύστημα λειτουργεί. Άρα όλα είναι εντάξει;
Αυτή είναι μία από τις πιο παραπλανητικές καταστάσεις στις οποίες μπορεί να βρεθεί ένα εταιρικό σύστημα.
Λειτουργεί.
Δεν υπάρχει βλάβη.
Οι χρήστες είναι ικανοποιημένοι.
Οι πωλήσεις χρησιμοποιούν την εφαρμογή.
Οι παραγγελίες περνούν.
Τα δεδομένα καταλήγουν στο CRM.
Οι αναφορές παράγονται.
Άρα η φυσική αντίδραση είναι: Μην το πειράζουμε. Γιατί να σκαλίζουμε κάτι που λειτουργεί;
Και πράγματι - δεν υπάρχει λόγος να αλλάξεις ένα σύστημα που λειτουργεί μόνο και μόνο επειδή μπορείς.
Το πρόβλημα είναι ότι ένα σύστημα μπορεί να είναι τεχνικά σταθερό και ταυτόχρονα πολύ ασταθές οργανωτικά.
Μπορεί να λειτουργεί σήμερα, αλλά κανείς δεν ξέρει τι θα συμβεί όταν χρειαστεί να αλλάξει ο server, ο πάροχος API, το domain, η βιβλιοθήκη, ο τρόπος αυθεντικοποίησης ή ένα κομμάτι της επιχειρησιακής διαδικασίας.
Μπορεί να είναι λειτουργικό, αλλά εξαρτημένο από ένα άτομο.
Μπορεί να είναι ασφαλές, αλλά κανείς να μην ξέρει πού βρίσκονται όλα τα access keys.
Μπορεί να εξελίσσεται, αλλά μόνο από τον άνθρωπο που γνωρίζει την ιστορία όλων των αποφάσεων.
Και εδώ ακριβώς εμφανίζεται η έννοια του bus factor.
Πόσα άτομα μπορούν να εξαφανιστούν πριν το project αρχίσει να έχει πρόβλημα;
Το bus factor είναι μια πολύ απλή, αν και σκληρή, έννοια.
Ρωτάμε: Πόσα άτομα πρέπει να πάψουν να είναι διαθέσιμα, ώστε το project να μην μπορεί πλέον να συντηρηθεί αποτελεσματικά;
Αν η απάντηση είναι: "Ένα", έχουμε πρόβλημα.
Αν η απάντηση είναι: "Δύο, αλλά και οι δύο δουλεύουν σε άλλη εταιρεία", έχουμε ακόμα μεγαλύτερο πρόβλημα.
Δεν μιλάμε φυσικά για κυριολεκτική "εξαφάνιση" ανθρώπων.
Ένας προγραμματιστής μπορεί να φύγει από την εταιρεία.
Ένας freelancer μπορεί να λήξει τη συνεργασία.
Ένα software house μπορεί να σταματήσει να εξυπηρετεί τον πελάτη.
Ένας διαχειριστής μπορεί να αλλάξει δουλειά.
Το άτομο που είναι υπεύθυνο για μια συγκεκριμένη ενσωμάτωση μπορεί να μετακινηθεί σε άλλο τμήμα.
Ο κάτοχος της γνώσης μπορεί απλώς να αρρωστήσει ή να είναι μη διαθέσιμος για μερικές εβδομάδες.
Αν μαζί του χάνεται η δυνατότητα κατανόησης του συστήματος, η εταιρεία δεν έχει πρόβλημα προσωπικού.
Έχει επιχειρηματικό πρόβλημα.
Ο κώδικας δεν λέει πάντα γιατί κάτι λειτουργεί
Θα μπορούσε κανείς να πει: "Μα έχουμε τον πηγαίο κώδικα. Αν χρειαστεί, ο νέος προγραμματιστής θα τον διαβάσει."
Θεωρητικά ναι.
Στην πράξη ο κώδικας απαντά κυρίως στο ερώτημα: πώς κάνει το σύστημα κάτι.
Δεν απαντά πάντα στο ερώτημα: γιατί το κάνει ακριβώς με αυτόν τον τρόπο.
Και αυτή είναι τεράστια διαφορά.
Στον κώδικα μπορεί να υπάρχει μια συνθήκη: "Αν ο πελάτης έχει συγκεκριμένο τύπο λογαριασμού, εκτέλεσε τη λειτουργία X."
Ο νέος developer μπορεί να τη βρει.
Αλλά πώς να ξέρει το γιατί;
Μπορεί να είναι επιχειρηματική απαίτηση.
Μπορεί να είναι κατάλοιπο από παλιά ενσωμάτωση.
Μπορεί να είναι προστασία από σφάλμα εξωτερικού API.
Μπορεί να είναι παράκαμψη ενός προβλήματος που υπήρχε πριν από πέντε χρόνια.
Μπορεί να είναι λύση σε μια ασυνήθιστη περίπτωση ενός από τους μεγαλύτερους πελάτες.
Μπορεί να υπάρχει για πολύ καλό λόγο.
Ή για κανέναν.
Χωρίς το πλαίσιο είναι δύσκολο να το κρίνεις.
Γι’ αυτό η τεκμηρίωση του συστήματος δεν πρέπει να περιορίζεται στις οδηγίες:
"κάνε κλικ εδώ, μετά εδώ".
Η πιο πολύτιμη τεκμηρίωση συχνά περιγράφει αποφάσεις και εξαρτήσεις, και όχι μόνο τη χρήση των λειτουργιών.
Η πιο επικίνδυνη γνώση είναι αυτή που υπάρχει μόνο στο κεφάλι κάποιου
Οι εταιρείες πολύ συχνά έχουν τεκμηρίωση. Μόνο που η τεκμηρίωση δεν είναι πάντα το ίδιο πράγμα με τη γνώση.
Μπορεί να έχουμε περιγραφή του API - αλλά να μην έχουμε πληροφορία γιατί χρησιμοποιούμε ακριβώς αυτό το API.
Μπορεί να έχουμε οδηγίες deployment - αλλά να μην έχουμε λίστα με όλα τα σημεία στα οποία πρέπει να αλλάξει η ρύθμιση.
Μπορεί να έχουμε περιγραφή ενσωμάτωσης - αλλά να μην ξέρουμε τι θα συμβεί αν ο εξωτερικός πάροχος αλλάξει τον τρόπο εξουσιοδότησης.
Μπορεί να έχουμε λίστα με servers - αλλά να μην ξέρουμε ποιος από αυτούς είναι κρίσιμος για μια συγκεκριμένη διαδικασία.
Μπορεί να έχουμε πρόσβαση στο repository - αλλά να μην έχουμε πρόσβαση στο account όπου βρίσκεται η παραγωγική υποδομή.
Αυτά είναι ακριβώς τα στοιχεία που μπορούν να μετατρέψουν μια φαινομενικά απλή αλλαγή σε πολυήμερη έρευνα.
Η ενσωμάτωση που λειτουργεί εδώ και πέντε χρόνια εξακολουθεί να είναι εξάρτηση
Ένας από τους πιο συχνά αγνοημένους τομείς είναι οι εξωτερικές υπηρεσίες;
- Πληρωμές.
- SMS.
- E-mail.
- CRM.
- ERP.
- Χάρτες.
- Συστήματα courier.
- Πλατφόρμες μάρκετινγκ.
- Λογιστικά συστήματα.
- Υπηρεσίες cloud.
- Εξωτερικά API.
- Βιβλιοθήκες ανοιχτού κώδικα.
Κάθε τέτοιο πράγμα είναι μέρος ενός μεγαλύτερου οικοσυστήματος.
Αν το σύστημα χρησιμοποιεί δέκα εξωτερικές υπηρεσίες, δεν έχουμε ένα σύστημα. Έχουμε ένα σύστημα συν δέκα εξαρτήσεις. Και καθεμία από αυτές μπορεί να αλλάξει.
Ο πάροχος μπορεί να αλλάξει το API.
Μπορεί να τερματίσει την υπηρεσία.
Μπορεί να αλλάξει το μοντέλο τιμολόγησης.
Μπορεί να αποσύρει την παλιά έκδοση.
Μπορεί να εισαγάγει νέες απαιτήσεις ασφάλειας.
Μπορεί να εξαγοραστεί από άλλη εταιρεία.
Γι’ αυτό παίζει όλο και μεγαλύτερο ρόλο και η γνώση για την προέλευση των συστατικών και τις εξαρτήσεις λογισμικού. Το NIST επισημαίνει μεταξύ άλλων τη σημασία του SBOM, δηλαδή του Software Bill of Materials - μιας επίσημης καταγραφής των συστατικών που χρησιμοποιήθηκαν για την κατασκευή του λογισμικού. Ένας τέτοιος κατάλογος βοηθά να καταλάβουμε από τι αποτελείται το σύστημα και να εκτιμήσουμε πιο γρήγορα τον αντίκτυπο ευπαθειών ή αλλαγών στην αλυσίδα εφοδιασμού.
Για την επιχείρηση αυτό μπορεί να συμπυκνωθεί σε μια πολύ απλή ερώτηση:
Ξέρεις από τι εξαρτάται το σύστημά σου;
Και τώρα φαντάσου μια αλλαγή software house
Αυτή είναι μία από τις στιγμές που όλα τα κενά βγαίνουν στο φως.
Η εταιρεία συνεργαζόταν επί χρόνια με έναν ανάδοχο. Ξαφνικά η συνεργασία τελειώνει. Οι λόγοι μπορεί να είναι πολλοί; Αλλαγή στρατηγικής. Αλλαγή προϋπολογισμού. Εξαγορά του agency. Οργανωτικά προβλήματα. Έλλειψη ικανοτήτων για περαιτέρω ανάπτυξη. Ή απλώς η εταιρεία θέλει να συνεργαστεί με άλλον συνεργάτη.
Το νέο software house ρωτά:
"Πού είναι το repository;" - Είναι εκεί.
"Πού είναι η υποδομή;" - Είναι εκεί.
"Πώς κάνουμε deployment στην παραγωγή;" - "Δεν ξέρουμε, το έκανε η προηγούμενη ομάδα."
"Πώς λειτουργεί η ενοποίηση με το ERP;" - "Μάλλον μέσω εκείνου του server."
"Ποια API keys έχουμε;" - "Πρέπει να είναι στο email."
"Ποια API είναι παραγωγικά;" - "Δεν ξέρουμε."
"Ποιες διαδικασίες είναι κρίσιμες;" - "Πρέπει να ρωτήσουμε τον Łukasz."
Ο Łukasz δεν εργάζεται πια εκεί...
Και ακριβώς γι' αυτό η μεταφορά του έργου δεν είναι μόνο μεταφορά κώδικα. Πρέπει να μεταφερθεί και η γνώση.
Η τεκμηρίωση δεν είναι κόστος. Είναι ασφάλεια
Σε πολλές εταιρείες η τεκμηρίωση αντιμετωπίζεται ως κάτι που γίνεται «όταν υπάρχει χρόνος».
Δηλαδή συνήθως ποτέ.
Ή στο τέλος του έργου.
Ή όταν το ζητήσει κάποιος.
Αυτό είναι λάθος.
Η τεκμηρίωση είναι ένας από τους μηχανισμούς που περιορίζουν τον επιχειρησιακό κίνδυνο. Δεν φέρνει άμεσα πωλήσεις. Δεν βελτιώνει τη μετατροπή. Δεν δείχνει εντυπωσιακή σε μια παρουσίαση.
Αλλά σε μια κρίσιμη κατάσταση μπορεί να κάνει τη διαφορά ανάμεσα σε: "θα το διορθώσουμε σήμερα"
και: "πρώτα πρέπει να βρούμε τον άνθρωπο που θυμάται πώς λειτουργούσε αυτό".
Στις νέες οδηγίες του NIST για σχέδια ασφάλειας, ιδιωτικότητας και διαχείρισης κινδύνου της αλυσίδας εφοδιασμού λογισμικού, η τεκμηρίωση του σκοπού του συστήματος, της κατάστασής του, των ελέγχων του καθώς και των αρμοδιοτήτων και της συμπεριφοράς των ανθρώπων που το διαχειρίζονται, αντιμετωπίζεται ως στοιχείο οργανωμένης διαχείρισης του συστήματος.
Αυτό δείχνει πολύ καλά την αλλαγή στον τρόπο σκέψης.
Η τεκμηρίωση δεν είναι μόνο εργαλείο για τον developer.
Είναι στοιχείο της επιχειρησιακής συνέχειας του οργανισμού.
Τι πρέπει να τεκμηριωθεί;
Δεν πρόκειται να δημιουργηθεί μια τεκμηρίωση 800 σελίδων που ποτέ κανείς δεν θα ανοίξει.
Η καλή τεκμηρίωση πρέπει πρωτίστως να απαντά στα ερωτήματα που θα προκύψουν όταν κάτι αλλάξει ή σταματήσει να λειτουργεί.
- Ποιος είναι ο ιδιοκτήτης του συστήματος;
- Πού βρίσκεται ο κώδικας;
- Πού βρίσκεται η παραγωγή;
- Πώς είναι η διαδικασία deployment;
- Ποια είναι τα περιβάλλοντα;
- Ποιες είναι οι κρίσιμες ενοποιήσεις;
- Ποιες εξωτερικές υπηρεσίες χρησιμοποιούμε;
- Ποιος είναι ο πάροχός τους;
- Ποια συμβόλαια και λογαριασμούς έχουμε;
- Πού βρίσκονται τα κλειδιά και τα στοιχεία πρόσβασης;
- Ποιος έχει δικαιώματα;
- Πώς γίνεται το backup;
- Πώς γίνεται η επαναφορά του συστήματος;
- Ποια open source components χρησιμοποιούνται;
- Ποιες βιβλιοθήκες είναι παρωχημένες;
- Ποιες είναι οι σημαντικότερες αρχιτεκτονικές αποφάσεις;
- Ποια στοιχεία είναι κρίσιμα για την επιχείρηση;
- Τι θα συμβεί αν μια συγκεκριμένη εξωτερική υπηρεσία σταματήσει να λειτουργεί;
Αυτό δεν είναι τεκμηρίωση «για προγραμματιστές».
Είναι χάρτης των εξαρτήσεων της επιχείρησης από την τεχνολογία.
Το «λειτουργεί, άρα μην το αγγίζουμε» μπορεί να είναι στρατηγική. Αλλά πρέπει να ξέρουμε το κόστος της
Δεν χρειάζεται κάθε εταιρεία ανακατασκευή του παλιού συστήματος.
Δεν είναι κάθε legacy σύστημα κακό.
Δεν χρειάζεται να ξαναγραφτεί κάθε παλιός κώδικας.
Αντίθετα - μερικές φορές ένα σταθερό, παλαιότερο σύστημα είναι πολύ καλύτερη λύση από μια ακριβή μετανάστευση χωρίς συγκεκριμένο λόγο.
Το πρόβλημα δεν είναι η ηλικία του συστήματος.
Το πρόβλημα είναι η έλλειψη γνώσης για την κατάστασή του.
Αν ξέρουμε πώς λειτουργεί το σύστημα, ποιες εξαρτήσεις έχει, πού βρίσκονται οι κίνδυνοι και ποιος μπορεί να το συντηρήσει, μπορούμε συνειδητά να αποφασίσουμε:
- το αφήνουμε,
- το εκσυγχρονίζουμε,
- ξαναγράφουμε ένα τμήμα,
- μεταναστεύουμε,
- ή δεν το αγγίζουμε καθόλου.
Αν δεν το ξέρουμε αυτό, η απόφαση «δεν το αγγίζουμε» δεν είναι στρατηγική.
Είναι στοίχημα.
Πώς μοιάζει ο έλεγχος ενός κληρονομημένου συστήματος;
Όταν σε ένα software house φτάνει ένα υπάρχον σύστημα, το πρώτο βήμα δεν πρέπει να είναι: "Ας το ξαναγράψουμε." - Πρώτα πρέπει να το καταλάβουμε.
Ένας καλός έλεγχος πρέπει να καλύπτει μεταξύ άλλων την αρχιτεκτονική της εφαρμογής, τον πηγαίο κώδικα, τη βάση δεδομένων, την υποδομή, τη διαδικασία deployment, τις εξαρτήσεις, τις ενοποιήσεις, την ασφάλεια, την πρόσβαση στις υπηρεσίες και την τεκμηρίωση.
Αλλά εξίσου σημαντική είναι η κατανόηση της επιχείρησης;
- Ποιες διαδικασίες είναι κρίσιμες;
- Ποιες λειτουργίες χρησιμοποιούνται καθημερινά;
- Ποια modules ευθύνονται για τα έσοδα;
- Ποια στοιχεία μπορούν να απενεργοποιηθούν χωρίς συνέπειες;
- Τι συμβαίνει όταν μια συγκεκριμένη ενοποίηση σταματήσει να λειτουργεί;
- Ποια στοιχεία είναι τα πιο ριψοκίνδυνα;
Μόνο αφού συνδυαστεί η τεχνική και η επιχειρησιακή οπτική μπορούμε να πούμε, τι πραγματικά χρειάζεται να αλλάξει.
Ο έλεγχος δεν χρειάζεται να καταλήγει σε επανάσταση
Μερικές φορές το αποτέλεσμα του ελέγχου είναι εκπληκτικά απλό.
Το σύστημα είναι εντάξει, χρειάζεται μόνο:
- Να συμπληρωθεί η τεκμηρίωση.
- Να τακτοποιηθούν οι προσβάσεις.
- Να ενημερωθούν λίγες βιβλιοθήκες.
- Να μεταφερθεί η ιδιοκτησία των λογαριασμών.
- Να περιγραφεί η διαδικασία deployment.
- Να προστεθεί monitoring.
- Να καθοριστεί backup.
- Να εισαχθεί δεύτερο άτομο στους τομείς που ήξερε μόνο ένας developer.
Και ξαφνικά ο bus factor αλλάζει από 1 σε 3.
Δεν χρειάζεται να ξαναγραφεί ολόκληρη η εφαρμογή.
Δεν χρειάζεται να πεταχτούν επτά χρόνια δουλειάς.
Δεν χρειάζεται να χτιστούν όλα από την αρχή.
Μερικές φορές το μεγαλύτερο πρόβλημα δεν είναι η τεχνολογία.
Είναι η έλλειψη χάρτη.
Το σύστημα πρέπει να επιβιώνει και χωρίς τους ανθρώπους που το δημιούργησαν
Αυτή είναι ίσως η πιο σημαντική αρχή: ένα καλό σύστημα πρέπει να μπορεί να αντέξει την αποχώρηση του developer.
Πρέπει να αντέξει την αλλαγή διαχειριστή.
Πρέπει να αντέξει την αλλαγή software house.
Πρέπει να αντέξει την αναδιοργάνωση της εταιρείας.
Πρέπει να αντέξει αρκετά χρόνια ανάπτυξης.
Αυτό δεν σημαίνει ότι κάθε προγραμματιστής πρέπει να καταλαβαίνει κάθε γραμμή κώδικα. Σημαίνει ότι η κρίσιμη για τη λειτουργία της επιχείρησης γνώση δεν μπορεί να υπάρχει μόνο στο μυαλό ενός ατόμου.
Γιατί ο εργαζόμενος μπορεί να φύγει.
Ο freelancer μπορεί να ολοκληρώσει τη συνεργασία.
Το agency μπορεί να εξαφανιστεί.
Ο προμηθευτής μπορεί να αλλάξει την υπηρεσία.
Και η εταιρεία πρέπει να συνεχίσει να λειτουργεί.
Η τεχνολογία πρέπει να ανήκει στον οργανισμό, όχι στη μνήμη ενός μόνο ατόμου
Αυτό είναι ιδιαίτερα σημαντικό στην περίπτωση συστημάτων που χτίζονται επί πολλά χρόνια.
Αν η εταιρεία πληρώνει για λογισμικό, πρέπει να ξέρει όχι μόνο πού βρίσκεται ο κώδικας.
Πρέπει να ξέρει:
- τι κατέχει,
- από τι εξαρτάται,
- ποιος έχει πρόσβαση,
- ποιος μπορεί να το αλλάξει,
- πώς μπορεί να γίνει deployment,
- πώς μπορεί να ανακτηθεί,
- πώς μπορεί να παραδοθεί σε άλλη ομάδα.
Το NIST στα τρέχοντα υλικά σχετικά με το due diligence των προμηθευτών εφιστά την προσοχή, μεταξύ άλλων, στην προέλευση, την ανθεκτικότητα, τις πρακτικές κυβερνοασφάλειας και τις εξαρτήσεις στην αλυσίδα εφοδιασμού. Αυτό δείχνει μια ευρύτερη κατεύθυνση: οι οργανισμοί πρέπει ολοένα και πιο συχνά να γνωρίζουν όχι μόνο ποιος παρέδωσε το σύστημα, αλλά και από τι αποτελείται το σύστημα και ποιοι κίνδυνοι συνδέονται με τη συντήρησή του.
Αυτό δεν είναι πλέον αποκλειστικά θέμα για το τμήμα IT.
Είναι θέμα διαχείρισης επιχειρηματικού κινδύνου.
Η χειρότερη στιγμή για να γνωρίσεις το σύστημά σου είναι μια βλάβη
Μπορεί κανείς να αφιερώσει λίγες ημέρες σε έναν έλεγχο.
Μπορεί κανείς να τακτοποιήσει την τεκμηρίωση.
Μπορεί κανείς να ελέγξει τις εξαρτήσεις.
Μπορεί κανείς να περιγράψει την αρχιτεκτονική.
Μπορεί κανείς να επαληθεύσει τις προσβάσεις.
Μπορεί κανείς να διαπιστώσει ποιος πραγματικά είναι υπεύθυνος για επιμέρους τομείς.
Μπορεί κανείς να μειώσει το bus factor.
Ή μπορεί κανείς να περιμένει.
Μέχρι τη στιγμή που το σύστημα θα πάψει να λειτουργεί.
Τότε τα ερωτήματα θα είναι ακριβώς τα ίδια.
Μόνο που η πίεση θα είναι μεγαλύτερη, οι χρήστες θα περιμένουν, οι πωλήσεις μπορεί να σταματήσουν και κάθε ώρα θα κοστίζει χρήματα.
Γι' αυτό αξίζει να θέσεις στον εαυτό σου ένα ερώτημα πριν εμφανιστεί το πρόβλημα: Αν αύριο εξαφανιζόταν το άτομο που γνωρίζει καλύτερα το σύστημά σου, θα ξέραμε ακόμα πώς να το συντηρήσουμε;
Αν η απάντηση είναι "όχι", αυτό δεν σημαίνει ακόμη ότι το σύστημα είναι κακό.
Σημαίνει ότι η εταιρεία έχει έναν κρυφό κίνδυνο, τον οποίο μέχρι τώρα δεν χρειάστηκε να ενεργοποιήσει.
Στη Web24 αναλαμβάνουμε όχι μόνο τον κώδικα
Η ανάληψη ενός υπάρχοντος έργου είναι εντελώς διαφορετική εργασία από την έναρξη ενός νέου συστήματος από το μηδέν.
Πρώτα πρέπει να κατανοηθεί τι ήδη υπάρχει.
Τι λειτουργεί.
Τι είναι κρίσιμο.
Τι αποτελεί εξάρτηση.
Τι είναι πρόβλημα.
Τι είναι απλώς απομεινάρι προηγούμενων αποφάσεων.
Και κυρίως - πού βρίσκεται η γνώση χωρίς την οποία το σύστημα δεν μπορεί να αναπτύσσεται με ασφάλεια.
Μόνο τότε μπορεί να σχεδιαστεί η συνέχεια.
Μερικές φορές θα είναι εκσυγχρονισμός.
Μερικές φορές ανάπτυξη.
Μερικές φορές τακτοποίηση της υποδομής.
Μερικές φορές ανάληψη της συντήρησης.
Και μερικές φορές απλώς η δημιουργία ενός σωστού χάρτη του συστήματος, τον οποίο για χρόνια κανείς δεν είχε χρόνο να προετοιμάσει.
Γιατί ένα υπεύθυνο software house δεν πρέπει να χτίζει τεχνολογία που λειτουργεί μόνο όταν δίπλα στον υπολογιστή κάθεται το σωστό άτομο.
Το σύστημα πρέπει να είναι μεγαλύτερο από τη μνήμη ενός ατόμου.
Και η επιχείρηση πρέπει να έχει τη βεβαιότητα ότι όταν κάποιος φύγει, η τεχνολογία δεν θα φύγει μαζί του.
