Il tema della replica automatica dei dati aziendali sembra essere di rilievo per molte aziende, ma le soluzioni ad hoc, specificamente progettate per affrontare questo problema di It management in azienda, sono conosciute? Si potrebbe dire ‘non tanto’. Questo almeno è quanto emerso nella web survey “Data Replication e opportunità di business”, condotta da ZeroUno in partnership con Sap, i cui dati sono stati commentati da Paolo Pasini, docente di Sda Bocconi e alla quale hanno partecipato 77 aziende. Infatti, il 10% del panel non le conosce, il 58% le conosce un po’ e solo il 31% dichiara un’elevata conoscenza. I motivi risiedono probabilmente in parte nelle modalità di comunicazione da parte dei software vendor, ma in parte nel fatto che spesso funzionalità di replica sono insite nativamente in applicazioni gestionali di altra natura o vengono risolte con la realizzazione di procedure custom o con altri strumenti ad hoc applicati in casi specifici (ad esempio con gli Etl – Extract, Transform, Load nel campo del datawarehousing a supporto della BI): ovviamente i risultati e le performance sono differenti però, per lo meno, in qualche modo si affronta il problema della replica.
Entrando più nel dettaglio, l’indagine ha permesso di analizzare i livelli di conoscenza delle modalità di replica dei dati e, anche in questo caso, i risultati non sono confortanti: il livello di conoscenza è medio per quasi la metà del campione e, nuovamente, solo circa un terzo delle imprese indica livelli di conoscenza elevati. In particolare, risultano essere leggermente più note tra le modalità di replica dei dati, la snapshot e il dump e reload. Tra le meno note, invece, si colloca il DB trigger con transazione.
Non si ritiene utile disquisire a livello tecnico sulle diverse modalità di replica e sui loro risultati di performance operativa, tuttavia le sei opzioni descritte nelle possibili risposte a questa domanda, aiutano ad avere un sentiment di quali potrebbero essere i fattori determinanti che supportano la scelta tra le varie modalità di replica: la possibilità di fare o meno aggiornamenti di dati su Wan e in remoto, l’inserimento dei comandi di replica dei dati direttamente all’interno di una transazione applicativa o meno, i tempi di esecuzione e i rischi di chiusura a buon fine della transazione o della copia dei dati, il fatto di condizionare la replica ad eventi, la copia di tutti i dati o solo di quelli modificati.
Tra driver e freni, un po’ di confusione
A conferma di quanto emerso dall’analisi circa i benefici dei sistemi di replica automatica dei dati, l’81% del campione definisce alta l’utilità di questi sistemi ai fini del disaster recovery e della business continuity, il 60% ai fini del reporting real-time e infine, sensibilmente meno, il 51% ai fini della sincronizzazione e consolidamento generale dei dati aziendali (vedi figure 17, 18 e 19). I valori intermedi delle risposte (utilità media dei sistemi di replica dei dati) aiutano a confermare la graduatoria nella quale emerge chiaramente che l’utilità maggiore è comunque assegnata nei casi di disaster recovery e business continuity, poi per il reporting o la BI realtime e infine per la generica sincronizzazione e consolidamento dei dati a vari fini operativi o di controllo direzionale.
Gli ambiti di utilità e il valore riconosciuto dei sistemi di data replicationFonte – ZeroUno – Web Survey Data Replication e opportunità di business – gennaio 2012 – campione 77 aziende
L’analisi dei fattori che frenano l’introduzione e lo sviluppo in azienda dei sistemi di replica automatica dei dati evidenzia come i più sentiti siano la mancanza di un’infrastruttura tecnica e di comunicazione adeguata (55%) e i costi di difficile previsione (47%): il primo è una precondizione infrastrutturale dipendente sia da scelte aziendali sia dal contesto territoriale (quindi in parte è un fattore esogeno). Il secondo menziona l’eterno problema dei costi It, oggi ancora più sentito quando si investe in sistemi It “trasparenti e non visibili” all’utente e al management aziendale.
Sembrano invece non essere un problema la necessità dei dati real time (solo in nicchie applicative), la mancanza di best practice e di benchmarking di settore o la complessità delle tecnologie impiegate che impensierisce solo il 10%, il 9% e l’8% rispettivamente delle aziende del panel.
Come progettare un data replication system
L’analisi dei fattori importanti nella progettazione del proprio specifico sistema di data replication posiziona decisamente al primo posto su una scala da 1 a 8 i volumi di dati in gioco (attuali e futuri). A seguire si trovano la necessità di un’elevata availability e la capacità di gestire tutto l’ambiente di replica a livello centrale e in modo facile: in altri termini, l’eventuale progetto di data replication in azienda dovrebbe prendere in esame prima di tutto i volumi di dati da trattare, il livello di availability desiderato e la possibilità di centralizzare l’amministrazione del sistema di replica.
Meno importanti, invece, sembrano ritenuti il grado di indipendenza tra di loro dei Db server in rete da aggiornare e la capacità di fare repliche selettive dei dati (più orientati quindi a fare repliche complessive dei dati). Gli altri fattori dell’eterogeneità delle fonti dati, della consistenza desiderata dei dati distribuiti, delle performance operative sembrano essere solo parzialmente incisivi e determinanti nell’impostazione e realizzazione del proprio sistema di replica.
