La Data Strategy come motore dell’IT
Abstract
Questo è l’articolo conclusivo di una serie di blog post finalizzata a trasmettere i punti salienti della visione delle architetture IT enterprise e del Data Management che, come Quantyca, proponiamo ai nostri clienti.
Per chi non li avesse letti, consiglio di leggere gli articoli precedenti della serie, dai titoli:
- “I principi di un moderno Data Management”: descrive le sfide dell’IT nella nuova era di digitalizzazione e i driver che spingono verso la ricerca di un cambio di paradigma nella progettazione delle architetture dati
- “L’approccio data-centrico che cambia l’IT”: descrive i principi e i vantaggi di un orientamento di progettazione delle architetture IT che considera i dati come asset centrale e riusabile e le applicazioni come elementi effimeri che producono o consumano dati di interesse per l’intera azienda
- “L’esigenza di governo nella gestione dei dati”: descrive i principali aspetti di governance da considerare per abilitare architetture IT data centriche e distribuite e mantenere il controllo dei dati a riposo e in movimento
- “L’adattabilità della piattaforma di integrazione in un modello Data Fabric”: descrive un modello emergente di progettazione delle piattaforme dati basato sull’uso avanzato dei metadati per rendere la piattaforma più automatizzata, self-service e versatile alle diverse esigenze degli utilizzatori
- “Il Domain Driven Design applicato ai dati per una maggiore agilità nella progettazione”: descrive i principi basilari del modello di progettazione software Domain Driven Design, che ha introdotto l’idea della decentralizzazione delle responsabilità e ha avuto grande influenza sul Data Management
- “Il Data Mesh e la spinta verso una gestione dati distribuita”: descrive lo scenario di Data Management precedente al modello Data Mesh e le ragioni che hanno portato alla ricerca di decentralizzazione delle responsabilità sui dati in una prospettiva domain-oriented
- “Il Data Mesh e il consumo self service dei dati come prodotti”: descrive la visione dei dati come prodotti gestiti end-to-end da team vicini al dominio di appartenenza e condivisi con gli altri team mediante una piattaforma di integrazione fruibile da tutti e governata in modo federato.
I principi architetturali e il ruolo dell’Enterprise Architect
In Quantyca crediamo che, alla base di un’architettura enterprise, al di là dei componenti e delle tecnologie che la costituiscono, variabili in base alle esigenze specifiche del business del cliente, ci debbano essere tre principi fondamentali, che determinano la direzione verso cui l’architettura IT evolve nel tempo:
- centricità del dato
- governo
- adattabilità
Negli articoli che compongono la serie abbiamo iniziato il tour parlando della necessità di evolvere da un paradigma tradizionalmente application-centrico, ereditato dalla prima ondata di digitalizzazione dei processi di business, ad un paradigma data-centrico, più adatto alle necessità digitali presenti e future, che richiedono uno sfruttamento e un riuso importante del dato come asset aziendale per supportare funzionalità di analisi avanzate, apprendimento automatico e servizi data-driven su larga scala. Abbiamo discusso come un paradigma data-centrico ha il beneficio di razionalizzare i flussi di integrazione dati e ridurne i costi di progetto e maintenance. Sono le motivazioni alla base del principio della centricità del dato.
Abbiamo poi affrontato il tema della distinzione tra le caratteristiche dei Data On The Inside, per l’utilizzo interno dei dati nelle logiche di un’applicazione, e i principi con cui dovrebbero essere gestiti i Data On The Outside, ovvero i data asset condivisi con il resto dell’architettura enterprise, che possono essere riusati all’interno di altre applicazioni a supporto di altre finalità di business. Abbiamo evidenziato la necessità di garantire basso accoppiamento tra le applicazioni, interfacce di esposizione dei dati stabili e facilmente utilizzabili, basate su standard, per favorire l’interoperabilità tra applicazioni differenti. Questi aspetti sono i pilastri su cui si basa il secondo principio architetturale, quello del governo, che diventa sempre più rilevante in un’architettura distribuita, in cui diversi componenti devono interagire e nella quale uno stesso dato può essere replicato in molteplici sistemi, passando per pipeline di integrazione più o meno complesse. Abbiamo proseguito il discorso entrando nel cuore delle tematiche di Data Governance, insistendo sulla necessità di legare, tramite il processo di Data Classification, il significato semantico dei dati, riportato nel Business Glossary, alla loro rappresentazioni fisiche, censite nel Data Catalog. Abbiamo spiegato l’utilità di tracciare il Data Lineage, per facilitare analisi di impatto, e di implementare controlli strutturati di Data Quality per garantire la completezza, la consistenza e l’affidabilità dei data asset messi a disposizione degli stakeholder interessati.
Infine abbiamo trattato il terzo principio architetturale, quello dell’adattabilità, sotto due dimensioni, quella tecnologico-architetturale e quella organizzativa. Un’architettura è adattabile se è in grado di fornire opzioni, dando la possibilità di non vincolarsi fortemente ad una scelta tecnica fatta nel presente ma di essere in grado, se necessario, di modificare tale scelta in futuro in tempi rapidi, nel momento in cui dovessero cambiare le esigenze e il contesto di business: l’adattabilità è importante sotto l’aspetto dei pattern usati, del numero e della varietà di applicazioni coinvolte, degli stack tecnologici selezionati e delle finalità di utilizzo del dato ammesse.
Dal punto di vista tecnologico-architetturale, abbiamo visto come il modello Data Fabric mette a disposizione una piattaforma di integrazione data-centrica, poliglotta, scalabile e metadata-driven, in grado di automatizzare (e quindi velocizzare) diverse attività manuali ordinarie di Data Management, tramite componenti di intelligenza in grado di sfruttare al meglio la varietà di metadati raccolti da tutti gli attori e gli agenti che prendono parte all’architettura. Abbiamo visto inoltre come la componente di piattaforma sia centrale anche nel paradigma Data Mesh, in cui assume una connotazione sempre più di elemento condiviso e self-serve, che si pone l’obiettivo di massimizzare l’autonomia dei gruppi di lavoro per ridurre colli di bottiglia e passaggi di consegna poco agili.
Dal punto di vista organizzativo, abbiamo discusso l’influenza che il Domain Driven Design ha avuto di recente anche sul mondo del data management, portando all’affermazione del paradigma Data Mesh, che propone di gestire in modo decentralizzato, federato e domain-oriented il ciclo di vita dei Data Product afferenti ad un certo dominio di business. Di conseguenza, il Data Mesh cambia lo scenario organizzativo di suddivisione e composizione dei gruppi di lavoro, non più orientato ad una dimensione tecnica, in cui le persone venivano organizzate per team competenti su una particolare fase della pipeline di gestione del dato (es: team responsabile della gestione Big Data) o su un aspetto specifico di data management (es: team esperto di modelli data warehouse), ma ad una dimensione in linea con i domini funzionali e i contesti di business. In questa nuova prospettiva, non si delinea più un unico modello dati enterprise centralizzato e difficile da evolvere, sotto la responsabilità di un unico team, ma una mesh di modelli specifici dei diversi domini di business, che portano alla formazione di elementi riusabili e componibili tra di loro in modo pienamente flessibile, detti Data as a Product.
Come Quantyca ci capita spesso di fornire ai nostri clienti servizi di consulenza per il disegno o la revisione dell’architettura IT enterprise, che può essere spinta da driver differenti, in base al contesto specifico dell’azienda: alcuni dei più comuni sono la volontà di migliorare il supporto digitale e la qualità del servizio IT, abilitare nuovi use case richiesti dall’espansione del business, razionalizzare i costi delle infrastrutture IT, ridurre il debito tecnologico, adeguare l’architettura a mutamenti organizzativi di corporate. Il lavoro che svolgiamo come Enterprise Architect è quello di valutare le priorità in termini di valore atteso dal cliente e i vincoli a contorno e identificare l’evoluzione architetturale più adatta per lo scenario specifico del cliente.
Nel disegno dell’architettura enterprise target partiamo da uno schema di riferimento della piattaforma di integrazione che riteniamo ideale sulla carta, ma operiamo poi scelte spesso diverse per declinare il disegno teorico in una soluzione ottimale per le esigenze peculiari del cliente. Non esiste l’architettura perfetta per qualunque contesto: nel proporre la soluzione si fanno delle scelte considerando diversi tradeoff tra obiettivi a volte contrastanti tra di loro, ad esempio la scalabilità della piattaforma e il contenimento dei costi, l’agilità di lavoro e il mantenimento del controllo, l’ottimizzazione dell’accesso al dato e la razionalizzazione dei sistemi.
I tre principi architetturali di base che abbiamo descritto negli articoli di questa serie ci guidano nelle scelte e nel delineare il piano di evoluzione dell’architettura: infatti, nella maggior parte dei casi, l’implementazione di un’architettura target è un processo incrementale e diviso in step, in cui la gestione del transitorio è solitamente uno degli elementi più critici, essendo una fase in cui possono moltiplicarsi i costi infrastrutturali, i costi di licenza, i costi di integrazione e i costi delle operations. La sequenza degli step di transizione e le interdipendenze tra di essi e con altre attività progettuali in essere sono fattori chiave da considerare per delineare il piano di evoluzione complessivo di un’architettura, che deve bilanciare il raggiungimento degli obiettivi business e degli obiettivi IT.
La figura dell’Enterprise Architect assume la sua importanza in un simile scenario “in movimento”, che sta diventando sempre più la nuova normalità nell’informatica e, in particolare, nell’area del Data Management: l’obiettivo dell’Architect non è solo quello di disegnare l’architettura target e il piano di evoluzione, ma anche di contribuire a definire una vera e propria Data Strategy aziendale con obiettivi condivisi di medio periodo, che orienti le attività progettuali e gli investimenti IT nell’ambito del Data Management in linea con le aspettative dell’azienda e la direzione strategica stabilita.
