Alcune settimane fa, a proposito di come gestire i progetti innovativi in ambito software, ho scritto di come sia necessario adottare un approccio agile, e di come questo rappresenti un vantaggio per le probabilità di successo dell’iniziativa.

È necessario, ma non sufficiente: ad un management agile del progetto bisogna abbinare l’uso di tecnologie che siano basate sugli stessi principi, in modo che queste non siano solo uno strumento per l’implementazione del prodotto/servizio ma anche un fattore abilitante a supporto della gestione del progetto stesso.

Nella progettazione di un nuovo sistema un elemento chiave è spesso il database: la scelta fino a non molto tempo fa concedeva poche alternative, più che altro basate sul vendor a cui affidarsi. Per il resto, era scontato utilizzare un database relazionale, i cosiddetti RDBMS.

Un database relazionale richiede grande attenzione nella progettazione della struttura dei dati e delle relazioni tra questi: è necessario avere una visione completa e dettagliata degli obiettivi di business del progetto per poter progettare la struttura dei dati. Una svista, un errore o, più semplicemente, una pur piccola variazione nell’esigenza di business che si verifica in corso d’opera si traduce spesso in interventi rilevanti, sia sulla struttura del database che sul codice applicativo già scritto, con le ovvie conseguenze sul progetto in termini di tempi e costi aggiuntivi.

Tutto ciò è poco in sintonia con l’impiego di metodologie agili, per tale ragione assistiamo oggi ad una vera e propria rivoluzione nel settore: dopo aver dominato per diversi decenni, la supremazia dei RDBMS viene messa in discussione dai cosiddetti database NoSQL, che si sono affermati sul mercato in virtù delle loro caratteristiche di flessibilità senza per questo aver nulla da temere sul piano delle performance, della sicurezza e della scalabilità.

Ci sono diversi tipi di database NoSQL, ognuno pensato per una specifica esigenza: document, graph, key-value, ecc. Tra i più diffusi troviamo quelli di tipo document, i cui criteri progettuali sono radicalmente diversi da quelli dei database relazionali, vediamone alcuni:

• il concetto di record, cioè un insieme fisso e predeterminato di campi, viene sostituito da quello di document: una struttura dati la cui complessità è definibile a piacere, che viene memorizzata associandola ad una chiave univoca
• il concetto di tabella, cioè un insieme di record omogenei, viene sostituito da quello di collection: un insieme di document non necessariamente omogenei tra loro
• il concetto di relazione, cioè un link fisso e prestabilito tra due tabelle, viene esteso da quello di sub-document, per cui un document può essere contenuto in un altro in modalità gerarchica

La disponibilità di una tecnologia basata su document e collection permette di progettare lo schema dei dati in modo dinamico, consentendo modifiche alla struttura dei dati durante le varie fasi del progetto senza che questo abbia ripercussioni né sui dati esistenti né sul codice già scritto: un vantaggio significativo per il budget di un progetto.

Il concetto di document poi trova un corrispondente ideale nel concetto di oggetto che è alla base della programmazione object-oriented oggi utilizzata in qualsiasi linguaggio: questo facilita le operazioni di mapping O-R a tutto vantaggio della semplicità, manutenibilità e delle performance del sistema.

Questi solo su alcuni degli aspetti peculiari che rendono vantaggioso l’utilizzo di un database NoSQL. Ce ne sono molti altri, come ad esempio la scalabilità orizzontale, cioè la capacità di distribuire il carico di lavoro tra più server in modo nativo e con un effort minimo in termini di configurazione e gestione (chi ha almeno una volta nella vita dovuto configurare un cluster RDBMS sa quanto delicato e oneroso sia questo aspetto).

Adottare metodologie agili per i progetti di sviluppo software non è dunque solo un tema organizzativo ma anche tecnologico: bisogna individuare e selezionare le tecnologie adatte, altrimenti queste si riveleranno un ostacolo formidabile che può seriamente minare le chance di riuscita del progetto. In questo senso, oltre al Project Manager, una figura chiave è quella del Software Architect, a cui fa capo la responsabilità delle scelte tecniche e che, sempre di più, deve avere tra i suoi skill la capacità di valutare le opzioni non soltanto per il loro valore tecnico intrinseco ma anche per i risvolti sugli altri aspetti del progetto.