Design di architetture software: da dove iniziare

Creare un’architettura software da zero può sembrare un task improbo, e certamente non va sottovalutato

Proviamo a rendere questa attività strategica più gestibile condividendo una serie di best practice

Con l’attività di design di architetture software si intendono le attività strategiche e operative propedeutiche alla fase di sviluppo dell’applicativo tecnologico.

Sebbene specialmente nelle fasi iniziali del progetto l’architettura software sia un canvas mutevole e in costante aggiornamento, essa diventa a tendere un documento progettuale di importanza rilevante. Costantemente aggiornato e consultato da sviluppatori, tecnici, stakeholder, consulenti e fornitori, per integrare e permettere l’evoluzione dell’intero applicativo.

Design di architetture software: di cosa si tratta

Il contesto

Dal punto di vista gerarchico, l’architettura software può essere vista come uno dei livelli che costituiscono il macro contenitore definito come Enterprise Architecture (EA). Questo contenitore racchiude l’insieme di best practice e metodi consolidati per condurre attività di analisi, pianificazione e implementazione all’interno dell’azienda, non necessariamente limitata a elementi tecnologici.

Una Enterprise Architecture efficace fornisce artefatti pragmatici come i requisiti, le specifiche, i principi guida e i modelli concettuali che descrivono la prossima fase evolutiva di un’organizzazione aziendale.

La Enterprise Architecture utilizza principi e pratiche per guidare le organizzazioni attraverso i cambiamenti di business, di informazione, di processo, di tecnologia, necessari per l’esecuzione della loro strategia[1].

L’architettura del software, in inglese definita Software Architecture (SA), si inserisce nel dominio delle Enterprise Architecture (EA), di cui fanno parte anche:

Data Architecture (DA): le architetture dati utilizzate da un’azienda e di conseguenza dai suoi applicativi.
Applications Architecture (AA): le strutture e gli applicativi utilizzati da un’azienda, con specifico riferimento al modo in cui essi interagiscono tra loro, e con l’esterno del perimetro aziendale (clienti, sorgenti dati esterne, data center, ecc.).
Infrastructure Architecture (IA): la struttura delle componenti tecnologiche aziendali viste nel loro complesso strutturale, quindi con riferimento a server, entità, nodi, protocolli e servizi di rete e network.

Tale novero di architetture è spesso declinato con un diverso grado di dettaglio o di focus (talvolta sulla parte tecnologica, talvolta su quella di prodotto e processi), e sovente oggetto di revisioni e integrazioni.

The Open Group Architecture Framework

Per restare aggiornati su uno scenario mutevole e di complessità crescente, un buon punto di partenza è dato dal framework TOGAF (The Open Group Architecture Framework).

TOGAF è il framework creato da The Open Group a partire dal 1995 e oggi riconosciuto come il framework più usato al mondo per la creazione di architetture aziendali. TOGAF è infatti utilizzato dall’80% delle aziende Global 50 e dal 60% delle società Fortune 500.

Design di architetture software: gli obiettivi

Gli applicativi informatici sono sistemi complessi e dinamici. Essi necessitano di essere progettati nei minimi dettagli e di essere poi gestiti sia nello specifico (classi, funzioni, oggetti, attributi) che a livello ambientale (memoria fisica e computazionale, risorse allocate, connessioni, sicurezza, governance).

I casi d’uso sono mutevoli nel tempo e applicazioni potenzialmente non previste al momento della progettazione possono emergere una volta che l’applicativo viene diffuso sul mercato e presso la sua base di utilizzatori.

Gli sviluppatori dovranno creare con certezza ogni singola funzionalità, sapendo di star rispondendo a requisiti business funzionali e di avvicinarsi per iterazioni successive al prodotto finito a loro richiesto.

É fondamentale quindi essere in grado di pianificare nel dettaglio la costruzione degli applicativi software.

Questo può significare raccogliere requisiti in modo esaustivo, raccogliere i contributi degli stakeholder, e rappresentare il software nelle sue componenti individuali.

In questo contesto si inserisce il design di architetture software, che possiamo definire come:

L’attività di progettazione della struttura fondamentale di un software, dell’ambiente nel quale opera, delle sue funzionalità, dei suoi elementi, delle loro proprietà e delle modalità di interazione tra classi, funzioni e oggetti che lo compongono.

Il design di architetture software può essere contestualizzato a diversi livelli del percorso di sviluppo di un applicativo, con diversi livelli di dettaglio e in parte diversi scopi:

Visione di alto livello delle sue funzionalità e scopi – “cosa fa cosa”.
Enumerazione delle funzionalità in base alla loro rilevanza, ad esempio requisito primario non negoziabile, requisito secondario, requisito accessorio.
Analisi delle funzionalità critiche che non potranno essere poi agilmente modificate in seguito.

Sebbene l’esatto perimetro inerente l’architettura del software sia oggetto di dibattito, si è concordi sul fatto che lo scopo del design architetturale sia preservare una visione d’insieme del progetto, senza addentrarsi nella redazione atomica dei singoli elementi dell’applicativo[2].

Design di architetture software: i vantaggi

L’architettura del software è considerabile un’astrazione ad un apprezzabile livello di dettaglio di un sistema complesso, a beneficio di sviluppatori, analisti, e in generale gli stakeholder che gravitano attorno all’applicativo.

I vantaggi che possiamo attribuire a un corretto processo di design di architetture software sono:

Rispondenza dei requisiti: la SA fornisce una base per l’analisi del comportamento dei sistemi software prima che il sistema sia stato costruito. La capacità di verificare che un futuro sistema software soddisfi le esigenze degli stakeholder senza doverlo effettivamente costruire rappresenta un sostanziale risparmio di costi e una riduzione dei rischi.

Creazione di un sistema modulare: la SA fornisce una base per il riutilizzo di elementi e decisioni. Un’architettura software può essere riutilizzata in più sistemi le cui parti interessate richiedono attributi di qualità o funzionalità simili, risparmiando sui costi di progettazione e riducendo il rischio di errori di progettazione.

Facilitare il decision making: la SA supporta le decisioni di progettazione che hanno un impatto sulla vita di sviluppo, implementazione e manutenzione di un sistema. Tali decisioni sono tipicamente le più onerose e le meno modificabili nelle fasi successive del progetto.

Facilita la comunicazione: la SA facilita la comunicazione con gli stakeholder progettuali, contribuendo a un sistema che soddisfa meglio le loro esigenze. Consente un adeguato processo di raccolta requisiti e verifica degli stessi. Consente di comunicare le decisioni progettuali prima che il sistema venga implementato, quando è ancora relativamente facile adattarle.

Facilitare le evolutive: la SA permette di intervenire con maggiore consapevolezza sul software, permettendo di gestirne sviluppi futuri in modo efficace.

Risk Management: l’architettura del software aiuta a ridurre i rischi e le possibilità di fallimento del progetto di sviluppo.

Cost Controlling: l’architettura del software è un mezzo per gestire i rischi e i costi nei progetti informatici complessi.

Design di architetture software in pratica

Sebbene non sia possibile presentare linee guida universali o regole che valgano a copertura di tutti i possibili casi d’uso, si è concordi nella necessità di rispettare un novero di best practice fondamentali necessari per disegnare una corretta architettura del software.

Comprensione dei requisiti di business

Lo step primario e principe di una buona architettura software è senza dubbio la comprensione dei requisiti di business. Senza una chiara visione dell’attività che l’applicativo andrà ad eseguire, sarà difficile comprendere se il prodotto realizzato sia rispondente o meno alle necessità aziendali.

I requisiti tipicamente si classificano in:

Requisiti funzionali: sono requisiti specifici che possono essere traslati in funzionalità dell’applicativo, ad esempio “poter modificare le dimensioni di un’immagine prima di caricarla” o “poter inserire il nome utente”.
Requisiti non funzionali: sono requisiti generici che non è possibile calare puntualmente all’interno dell’applicativo, ma che possono essere desunti. Ad esempio “l’applicativo deve essere scalabile, performante, sicuro”.

In questa fase è opportuno raccogliere anche a livello di brainstorming l’elenco non ordinato dei requisiti e funzionalità e analizzarli poi nel loro insieme. Un primo sketch dell’architettura può aiutare nel confronto visuale tra gli attori coinvolti e permettere anche di evidenziare i flussi principali dell’applicativo.

Analisi dei singoli requisiti

Una volta raccolto in modo ragionevolmente certo tutti i requisiti, è necessario passare alla loro analisi con maggior granularità. In questa fase verranno classificate le funzioni primarie dell’applicativo. Si noteranno inoltre eventuali funzionalità in contrasto tra loro, o palesemente impossibili dal punto di vista tecnico.

L’architettura potrà evolvere da una semplice bozza a un design più strutturato e ricco di dettagli. Gli oggetti macro saranno tracciabili e chiaramente identificabili.

Durante questo stadio di progettazione è bene evitare di scendere in un dettaglio troppo puntuale, ragionando ancora ad un livello teorico ideale.

Design dei layer architetturali

In questa fase saranno tracciati i macro aggregati di componenti che definiranno il software. Rispettando le best practice della filosofia Agile, è opportuno focalizzarsi su un raggruppamento verticale, ossia che racchiuda in un medesimo cluster tutti gli elementi che permettono ad una data funzionalità di essere realizzata.

Ad esempio, un layer verticale per un applicativo potrebbe essere “funzione di login” oppure “funzione di pagamento”.

In questa fase, le connessioni tra i diversi layer architetturali si fanno più netti. Inizia ad essere evidente quali componenti del software interagiscano tra loro, quali siano deputate a un output verso l’utente e quali invece ne dovranno gestire l’input.

Creazione di un primo prototipo visuale

Per quanto in senso stretto la prototipazione non afferisca al design dell’architettura del software, creare un prototipo visuale ad alto livello permette di apprezzarne con immediatezza le funzionalità principali, nonché eventuali mancanze e dimenticanze macroscopiche (ad esempio, il flusso di autenticazione manchevole della funzione di logout).

Il prototipo visuale sarà da considerarsi estremamente mutabile, e dovrà essere costantemente allineato al diagramma dell’architettura software fin qui tracciato, così da preservare il “punto singolo di verità assoluta” o SSOT (“Single Source of Truth”).

Valutazione dell’architettura del software

Si analizza la rispondenza dell’architettura realizzata con i requisiti espressi all’avvio della fase di design. In questa fase di valutazione possiamo rifarci a modelli di valutazione ben codificati in letteratura, tra i quali citiamo forse il più noto, ATAM (Architecture Tradeoff Analysis Method).

Questa fase è anche un potenziale indicatore della fase di completezza dell’architettura del software.

Gestione dell’evolutiva

Poiché la software architecture fornisce la struttura fondamentale di un sistema software, la sua evoluzione e la sua manutenzione hanno necessariamente un impatto sulla sua struttura fondamentale. La gestione dell’evolutiva riguarda l’aggiunta di nuove funzionalità e il mantenimento di quelle esistenti e del comportamento del sistema nel tempo.

Documentazione

Siccome il design di architetture software è un processo che richiede attività di decision making, di valutazione di bivi tattici e strategici, di scelte strutturali, è bene tenere traccia di ogni singolo elemento che ha costituito il processo nella sua interezza.

Questo sia a beneficio degli stakeholder attuali, ma anche, e forse a maggior ragione, degli stakeholder futuri. Team di sviluppo, management, consulenti, analisti, che si troveranno a interagire con l’applicativo privi della conoscenza alla fonte che lo ha generato e prodotto.

Esempi di attività di documentazione possono essere la scrittura di una specifica, la registrazione di un modello di progettazione, la documentazione di una logica o di una funzione, il tracciamento del dettaglio di un confronto che ha portato alla scelta di un determinato modello.

Suggerimenti di carattere generale

Iterazione: i singoli step suggeriti sono inseriti in un percorso ciclico iterativo. Potrebbero presentarsi diversi cicli tra loro paralleli, ad esempio laddove fosse necessario gestire un’evolutiva di un progetto software esistente, così come potrebbero essere esplosi in livelli di dettaglio ulteriore.

Visualizzazione: il design architetturale è per definizione un sistema visuale. Diagrammi e strutture visive sono ottimi elementi per realizzare, affinare, presentare, discutere, un’architettura del software.

Pattern: sebbene i design pattern siano elementi fondanti dal punto di vista della progettazione, il ricorso a pattern consolidati nelle fasi embrionali del progetto potrebbe causare un effetto distorsivo: il software viene progettato per aderire al design pattern e non per rispondere ai reali requisiti di business. In una fase successiva, di fine tuning e cleaning, sarà possibile poi far aderire le funzioni e processi a design pattern e best practice del settore.

MVA: l’architettura è funzionale al prodotto, non si sostituisce al prodotto. Minimum Viable Architecture o JEA (“Just Enough Architecture”) è l’architettura che è sufficiente per il rilascio del prodotto e che deve essere continuamente migliorata durante la vita del software.

Scopo finale: nonostante la rispondenza completa a best-practice e metodologie, occorre ricordare che il software nasce per rispondere a una funzione specifica e che senza tale rispondenza, esso non ha senso di esistere.

Design di architetture software: gli strumenti

Il design di architetture software può essere reso più agevole se coadiuvato dagli strumenti giusti.

Softwarearchitecture.tools: un portale che raccoglie moltissimi strumenti gratuiti e a pagamento per gestire diversi step del design dell’architettura del software. Dalla creazione di modelli a diagrammi, automazioni, code base. Repository di fondamentale utilità.
Microsoft Visio: lo strumento classico per la creazione visuale di relazioni tra oggetti.
Cloudcraft: la soluzione di progettazione specifica per il mondo AWS, dal design accattivante.
Figma: il tool di progettazione visuale più usato al mondo (e recentemente acquistato da Adobe).
Miro: la piattaforma di design collaborativo permette di creare diagrammi, sketch e casi d’uso semplici ma efficaci.
Lucidchart: lo strumento di progettazione visuale dedicato specificatamente al mondo dell’ingegneria del software.
Google Cloud Diagram: lo strumento di Google per la creazione di diagrammi e flussi di lavoro online.

Alcuni esempi

Il modo migliore per comprendere a fondo il flusso di creazione di un’architettura del software è osservarne il processo nella sua interezza.

Questi video spiegano passo passo come approcciare l’argomento.

Inoltre, cogliamo con piacere lo spunto offertoci da uno dei nostri lettori, Marco Cello, che raccomanda la lettura della pietra miliare di Martin Fowler, “Patterns of Enterprise Application Architecture“. Da adepti del buon Martin, cogliamo lo spunto con molto piacere!