Στην παρούσα ενότητα, αρχικά, παραθέτονται οι γενικές απαιτήσεις σχεδιασμού που θα πρέπει να διέπουν την προσφερόμενη λύση. Στη συνέχεια, εξειδικεύονται οι επιμέρους απαιτήσεις του Έργου όσον αφορά τεχνικά και διαδικαστικά θέματα. Έπειτα, περιγράφεται η διαδικασία με την οποία θα πραγματοποιηθεί η αξιολόγηση των τεχνικών προσφορών που θα υποβληθούν. Η ενότητα ολοκληρώνεται με την παράθεση βασικών θεμάτων που άπτονται της εμπιστευτικότητας και ειδικότερα, τις βασικές αρχές που θα διέπουν τη σχέση του Αναδόχου και της Αναθέτουσας Αρχής μετά την υπογραφή της Σύμβασης.
1.5 Γενικές Αρχές Σχεδιασμού
Οι γενικές αρχές που θα πρέπει να διέπουν την υλοποίηση του Έργου, θα πρέπει να κινούνται στους άξονες της ασφάλειας δεδομένων, της διαθεσιμότητας των υπηρεσιών και της μείωσης του συνολικού κόστους λειτουργίας των παραπάνω, μέσω «πράσινων» τεχνολογιών και πρακτικών που βελτιώνουν την ευελιξία στην παροχή υπολογιστικής ισχύος.
Στο πλαίσιο αυτό η λύση θα πρέπει να έχει μικρό ενεργειακό ίχνος και σε συνδυασμό με τη βέλτιστη χρήση των διαθέσιμων πόρων να εξασφαλίζει γρήγορη απόδοση των επενδύσεων με χαμηλό λειτουργικό κόστος.
Οι βασικές αρχές που θα πρέπει να διέπουν το σύνολο του ‘Έργου (υλικό και λογισμικό) είναι οι εξής:
1. Ασφάλεια: Η προστασία του απορρήτου και της ακεραιότητας των δεδομένων.
2. Αρτιότητα: Όλα τα συστατικά της προτεινόμενης λύσης θα πρέπει να είναι πλήρως λειτουργικά και συμβατά με τις τεχνικές προδιαγραφές και τους στόχους που έχουν τεθεί.
3. Επεκτασιμότητα: Ο σχεδιασμός του Συστήματος θα πρέπει όπου είναι δυνατόν να είναι αρθρωτής (modular) αρχιτεκτονικής ή να υιοθετεί επαρκείς μηχανισμούς αφαιρετικότητας (abstraction) ώστε να επιτρέπει εύκολα μελλοντικές επεκτάσεις, αντικαταστάσεις, αναβαθμίσεις ή αλλαγές διακριτών τμημάτων λογισμικού ή υλικού (scale out και scale up).
4. Αξιοπιστία: Περιλαμβάνει την υψηλή διαθεσιμότητα (High Availability) και τη διασφάλιση της ακεραιότητας (Integrity) δεδομένων. Το Σύστημα θα πρέπει να είναι διαθέσιμο 24 ώρες την ημέρα/7 ημέρες την εβδομάδα. Το Σύστημα θα πρέπει να είναι σχεδιασμένο και δομημένο με τέτοιο τρόπο ώστε να διασφαλίζεται η ανθεκτικότητα και η αδιάλειπτη λειτουργία του σε περίπτωση που κάποιο τμήμα του πάψει να λειτουργεί σωστά (No Single Point of Failure).
Στο συγκεκριμένο θέμα θα ήθελα να αναφέρω τα παρακάτω :
Η υλοποίηση θα πρέπει να είναι n-tier Architecture με σκοπό την επεκτασιμότητα και την συντήρηση στο μέλλον. Για παράδειγμα θα πρέπει να υπάρχει μια υποδομή από database servers όπου θα είναι μόνο η βάσεις δεδομένων σαν το data layer και ένα επίπεδο όπου θα είναι το logic layer όπου εκεί θα είναι όλο το λογισμικό επεξεργασίας δεδομένων ή αναζήτησης ή υπολογιστικές ανάγκες κτλ κτλ. Και τέλος το presendation layer όπου οι υπάλληλοι της Αστυνομίας θα συνδέονται και θα χειρίζονται τις παραπάνω ενέργειες. Έτσι έχουμε 3-tier Architecture μπορεί να υπάρχει μια υποδομή από database servers μόνο, άλλη μια με application servers. Αυτή η αρχιτεκτονική θα αυξήσει την ταχύτητα και θα υπάρχει ανεξαρτησία των παραπάνω επιπέδων έτσι στο μέλλον αν θέλει κάποιος να αλλάξει το data logic πχ δεν θα πειράζει καθόλου τα υπόλοιπα επίπεδα. Επίσης σε κάθε layer επειδή μπορεί να είναι σε διαφορετικά δίκτυα θα μπορεί να εφαρμοστεί και διαφορετικό επίπεδο ασφαλείας. Για παράδειγμα θέλουμε ένα πιο ισχυρό σύστημα ασφαλείας στο δίκτυο όπου υπάρχουν οι database servers και ένα λιγότερο ισχυρό ενδεχομένως στα υπόλοιπα δίκτυα όπου είναι τα άλλα επίπεδα. Έτσι ο επιτιθέμενος έχει να σπάσει πολλαπλά κομμάτια ασφαλείας το οποίο και χρόνο απαιτεί και ιδιαίτερες τεχνικές γνώσεις αλλά και θα είναι σχεδόν αδύνατο μιας και θα εντοπιστεί εγκαίρως.
Όσον αφορά την τεχνολογία βάσης δεδομένων θεωρώ ότι βολεύει η ORACLE και παρέχει και κρυπτογράφηση και ισχυρή έκδοση για παράλληλη επεξεργασία δεδομένων. Τέλος παρέχει και εργαλεία BI για στατιστικά και εξόρυξη πληροφορίας…Μπορεί να κάτσει άνετα σε open source linux OS με χαμηλή κατανάλωση πόρων κτλ κτλ.
Σε εκείνο που δεν μου άρεσε και τόσο είναι το να βάλετε μέσα στην βάση blob αρχεία πχ Εικόνες, ηχητικά δεδομένα κτλ κτλ. Αυτό μακροπρόθεσμα έχει τα παρακάτω μειονεκτήματα :
1) Θα αυξήσει γρήγορα το μέγεθος της βάσης
2) Θα επηρεάσει την απόκριση , γενικά την ταχύτητα (δε μπορείς να εφαρμόσεις indexes σε blob files)
3) To backup / Restore θα διαρκεί αρκετό χρόνο μιας και η βάσεις θα είναι παραφουσκωμένες.
Τι θα έκανα : Όλου αυτού του είδους αρχεία θα τα αποθήκευα σε δικτυακούς δίσκους (όπου θα είχα και κρυπτογράφηση και ισχυρό σύστημα ασφαλείας) και στην βάση θα αποθήκευα μόνο την διαδρομή του εκάστοτε αρχείου. Έτσι η βάση θα ήταν πάντα μικρή και τα επίμαχα δεδομένα μου θα ήταν όχι στη βάση αλλά σε ένα σύστημα σκληρών δίσκων (τεχνολογίας ίσως και SSD για μεγαλύτερες ταχύτητες) και τα backup θα παιρνόνταν γρήγορα και γενικά η υγεία της βάσης μου θα ήταν καλύτερη.Αν δεν θέλουμε σε σκληρούς δίσκους ίσως να βοήθαγε μια NOSQL DB(αν και είμαι κατά).
Δε ξέρω αν η ORACLE η SQL Server έχει άλλη καλύτερη λύση, αλλά γενικά είναι κακή τεχνική να φορτώνουμε την database με πολλά blob αρχεία.