Nel data management il solo approccio possibile è quello procedurale/imperativo? Non è meglio quello dichiarativo che usiamo nella vita di tutti i giorni?

Approccio imperativo, al ristorante

Approccio imperativo, al ristorante

Ogni giorno, in mille attività quotidiane, ci comportiamo e interagiamo con altri e con il contesto che ci circonda comunicando cosa ci occorre e ricevendo quanto richiesto.

Questo perché, è un dato di fatto, non siamo esperti di ogni cosa e sappiamo (in linea teorica) che si ottengono risultati migliori delegandone la realizzazione a chi ne ha tutte le competenze e se ne è già occupato più e più volte.

Chi, salendo su un aereo di linea, ha la pretesa di impartire in autonomia la sequenza dei comandi necessari al decollo?

Oppure, chi al ristorante detterebbe al cameriere la ricetta che lo chef deve seguire per preparare il piatto ordinato?

È nella vita reale che, in estrema sintesi, i comportamenti seguono un paradigma dichiarativo: si commissiona un risultato, non si specifica come ottenerlo.

Nel mondo informatico invece, e in particolare nel data management, l’approccio prevalente è stato fino ad ora quello procedurale: definire nei minimi dettagli tutti i particolari, anche quelli più tecnici, di funzionamento di un’applicazione.

  • In un progetto di realizzazione di una soluzione data intensive è veramente necessario descrivere il processo, scomponendolo in una serie di passi e sottopassi, per ciascuno dei quali dovranno essere precisati gli algoritmi e le strutture intermedie necessari per le operazioni di trasformazione, aggregazione, reporting?
  • È indispensabile poi descrivere in modo puntuale quando queste strutture informative intermedie dovranno essere create, popolate e, se non più necessarie, cancellate?
  • E ancora, è proprio necessario indicare in modo esplicito (magari anche attraverso un bell’editor grafico) in che sequenza queste operazioni elementari dovranno essere eseguite, prevedendo tutte le possibili casistiche di esecuzione, in base alle differenti condizioni che si possono verificare?

Ma è davvero la sola opzione possibile?

La risposta a queste domande è: no.

Anche nei processi data intensive il paradigma dichiarativo può semplificare, e di molto, la vita del team di sviluppo e produrre risultati più aderenti alle aspettative del committente.

Cominciamo dall’articolazione del processo di trattamento dei dati. Un modello dichiarativo non richiede di esplicitare i vari passi di esecuzione in fase di progettazione:

  • quali componenti funzionali creare e il loro ordine di esecuzione viene determinato run-time dal sistema sulla base di necessità, precedenze e dipendenze implicite;
  • cosa che un sistema opportunamente predisposto può fare bene, senza costringere il progettista a definire tutto in anticipo.

Questa caratteristica è presente nella piattaforma Irion EDM: si chiama DELT™ (Declarative ELT).

Passiamo ora alla gestione delle strutture informative intermedie, quelle necessarie per eseguire le attività di trasformazione e aggregazione. In un approccio dichiarativo vengono create e distrutte automaticamente in funzione delle necessità di tempo e spazio. I risultati intermedi, anche complessi, prodotti dalle componenti funzionali (così come dati in input), sono riesposti come tabelle virtuali, disponibili a altre componenti o esplorabili, attraverso query, anche per attività di test: in Irion EDM questa funzionalità è realizzata da una tecnologia proprietaria, EAsT™ (Everything As a Table).

I dati necessari alle esecuzioni sono resi disponibili automaticamente in uno spazio operativo isolato e dedicato, IsolData™. Si tratta di uno spazio di lavoro virtualmente illimitato, allocato e liberato dinamicamente dal sistema, segregato in termini di permessi di accesso e spazio dei nomi, volatile o persistente. Gli IsolData™ consentono n esecuzioni parallele, sugli stessi dati o su dati completamente differenti e/o con parametri, regole e logiche diverse, senza che debba essere predefinita o gestita alcuna struttura particolare; tutte le operazioni di supporto alla gestione infrastrutturale sono coordinate e gestite da Irion EDM in modo ottimizzato e trasparente all’utilizzatore.

Con un approccio dichiarativo la qualità dei dati può essere garantita a costi estremamente inferiori rispetto ad un approccio procedurale.

Ad esempio, in un modello dichiarativo tutti i controlli tecnici sui dati in ingresso alla soluzione possono essere generati automaticamente dal sistema all’atto della dichiarazione degli input (pervenimento del flusso, unicità, obbligatorietà dei valori, formato, numerosità attesa).

In Irion EDM anche questa caratteristica è disponibile: con gli RTG Add On, tutti i controlli “formali” sono generati automaticamente sulla base di caratteristiche attese dei dati dichiarate attraverso un’interfaccia intuitiva; l’esecuzione di questi controlli è disposta automaticamente dal sistema, in coerenza con la logica DELT™.

Per non dimenticare la gestione della documentazione: quando vengono richieste modifiche in corso d’opera al funzionamento della soluzione, l’allineamento della documentazione comporta un impegno comunque significativo. Ma in un ambiente di sviluppo dichiarativo, tutto il funzionamento della soluzione è guidato dai metadati; questa caratteristica è sfruttata dalla piattaforma Irion EDM, che sulla base di quei metadati è anche in grado di produrre in automatico la documentazione completa della soluzione, sempre allineata al reale stato di funzionamento.

E queste sono solo alcune delle aree di possibile efficientamento di una soluzione realizzata ispirandosi al paradigma dichiarativo.

Il risultato sono applicazioni metadata-driven, realizzate più velocemente, di maggiore qualità, più performanti, ben documentate e quindi più facilmente manutenibili. Ad esempio, i tempi di sviluppo di una soluzione data intensive realizzata con Irion EDM sfruttandone le caratteristiche “declarative” possono essere ridotti fino al 70% rispetto ai tradizionali sviluppi procedurali.

La gestione di un progetto di Enterprise Data Management trae significativi vantaggi dall’applicazione del paradigma Declarative. Con riferimento alle domande del Questionario, possiamo delineare questo finale:

  • il livello di complessità e i tempi di realizzazione si ridimensionano notevolmente. In particolare non è più necessario precisare, preliminarmente alla fase di implementazione, tutta una serie di dettagli tecnici, perché un ambiente di sviluppo declarative li gestisce autonomamente e in modo ottimizzato. Inoltre i controlli tecnici di qualità dei dati, la cui implementazione è solitamente onerosa, vengono generati automaticamente e le fasi di realizzazione e test di ogni singolo componente possono essere eseguite autonomamente e in parallelo da differenti team di lavoro. Ciò, come già detto, rende possibile un più frequente confronto con il committente riducendo i tempi complessivi di disponibilità della soluzione finale;
  • il progetto di realizzazione e il funzionamento in esercizio della soluzione sono gestiti in un’unica piattaforma integrata che comprende tutte le funzionalità necessarie;
  • l’ambiente declarative riduce, e in molto casi annulla, il coinvolgimento di competenze tecniche (DBA, web developer, esperto UX), poiché una buona parte dei task che sarebbero stati presi in carico da queste figure è gestita automaticamente;
  • cambiamenti in corso d’opera, anche rilevanti, dei requisiti comportano interventi sulle sole componenti funzionali direttamente impattate, mentre le altre si autoadattano ad eventuali variazioni delle strutture informative di transito, sfruttando le caratteristiche delle tecnologie DELT™ e IsolData™; l’impatto dei cambiamenti sui tempi di progetto è complessivamente inferiore rispetto ad un approccio procedurale;
  • la generazione automatica della documentazione agevola il confronto con gli utenti non business e la verifica dei requisiti funzionali, accelera i tempi di completamento e favorisce la manutenibilità della soluzione, anche in caso di variazioni in corso d’opera.