Nella gestione delle informazioni ormai i processi di elaborazione sono tanti e tali che il problema della proprietà è una questione non banale per chi si occupa di definire le linee guida a supporto di sistemi e infrastrutture efficienti e sicuri.
Ci sono infatti diversi elementi concomitanti da prendere in considerazione:
- Privacy: il rinnovamento di leggi e regolamentazioni è continuo ed è sempre più difficile per un’azienda definire il perimetro della governance in considerazione anche del fatto che su diversi orizzonti geografici i cmabiamenti sono tali e tanti che è praticamente impossibile riuscire a trovare una soluzione definitiva e omnicomprensiva
- Storage: i volumi di informazioni da gestire stanno aumentando a dismisura e la maggior parte delle organizzazioni stanno potenziando di anno in anno le capacità dei loro sistemi di archiviazione (con costi che aumentano di anno in anno)
- Sicurezza: i dati sono a tutti gli effetti degli asset e, come tali, vanno protetti come una risorsa tra le più preziose
- Modernizzazione applicativa: ogni volta che i sistemi legacy vengono aggiornati o potenziati, automaticamente si scoprono scheletri negli armadi, ovvero dati ridondati che richiedono sincornizzazione o dati da validare che devono essere analizzati per capire se hanno un significato o meno all’interno dei processi e questo porta a formulare una domanda: a chi appartengono questi dati?
Le nuove sfide del Data Management nello sviluppo del software
Effettivamente nello sviluppo applicativo la gestione dei dati rappresenta una bella sfida per i responsabili dei sistemi informativi. Gli esperti consigliano di focalizzarsi bene sul concetto di proprietà per definire le linee guida della governance.
Sempre più spesso accade che tra i team di sviluppo e i team operativi ci sia conflitto su questo punto: nel momento in cui viene sviluppato un nuovo codice, ad esempio, iniziano ad essere creati degli archivi che contengono i dati. Dopodichè accade che i team operativi considerano questo dati come loro e i team di sviluppo a questo punto devono fare una richiesta formale a questi archivi per prelevarli e gestirli ma il processo in questo modo è rallentato da un collo di bottiglia più burocratico che funzionale. Perché, infatti, gli sviluppatori dovrebbero aspettare le operation per avere il supporto di dati che appartengono all’applicazione da loro sviluppata?
Per fortuna le strategie DevOps stanno risolvendo parte di queste vecchie abitudini organizzative, accelerando lo sviluppo e la collaborazione tra i team introducendo nuove logiche intervfunzionali.
Tutte le organizzazioni vogliono essere agilli e veloci, senza dover ogni volta creare nuovi archivi di dati associati allo sviluppo di ogni nuovo modulo applicativo, per altro andnado a replicare spesso dati già esistenti. Perché non utilizzare gli stessi dati una volta sola, evitando i problemi di sincronizzazione e di validità?
DevOps per sempre (ma assicuratevi che sia chiaro a tutti)
Il compito di chi gestisce vari team è quello di condividere le vision ed esprimere con molta chiarezza gli obiettivi: Questo significa analizzare i problemi e condividerli, per essere sicuri che tutti capiscano cosa sta succedendo e perché bisogna risolvere in fretta l’impasse. Uno dei sistemi migliori per accelerare il cambiamento è la stesura di un programma, finalizzato a spiegare come raggiungere i risultati nel migliore dei modi. In questo caso immaginare di progettare un manifesto per la governance dei dati può diventare uno strumento di supporto strategico. Grazie a questo documento condiviso, è possibile descrivere il nuovo paradigma della sicurezza che spiega nel dettaglio come i dati costituiscano una risorsa preziosa che deve essere messa a disposizione di tutti. A questo proposito, è consigliabile classificare i dati in due categorie:
Dati core: si tratta di dati universali, che devono essere gestiti a livello centrale. Possono essere dati di utenti, ordini, identità, consuamtori, ruoli, permessi, prodotti…. I team operativi forniscono e supportano questo tipo di dati.
Dati applicativi: si tratta di qualsiasi altro dato legato allo sviliuppo del codice e sono gestito localmente dai team di sviluppo.
Il processo si struttura in questo modo: gli utenti interagiscono con le applicazioni, le applicazioni richiedono servizi, i servizi rispettano i dati, nel senso che non devono corrompere o alterare i dati in alcun modo. In sintesi, solo gli addetti ai servizi applicativi possono toccare i database.
Di certo questo approccio è un po’ disruptive ma è quello che serve per essere agili e veloci, secondo i dittami di quel manifesto Agile che tanto ha fatto la differenza nel time to market dello sviluppo. Categorizzare fornisce un accoppiamento che supporta gli standard e la normalizzazione, permettendo maggiore flessibilità ai team di sviluppo. Se un’applicazione ha bisogno di dati di base, il team operativo fa in modo che i dati di base siano disponibili e coerenti. Certo la gestione dei dati è sempre un tema complicato in termini di moli crescenti e tipologie differenziate di informazioni, il che riporta in auge i discorsi associati alle problematiche di archiviazione e di sicurezza. Ma è questa la strada giusta per la governance.
