Salve a tutti e benvenuti in questa serie di articoli dedicati alle Architetture Software.

In questo primo articolo introdurremo il concetto di Architettura Software, vedremo di capire cosa si intende con questo termine e parleremo dell'importanza che ha questo argomento nell'ambito dello sviluppo software.

Dare una definizione di architettura software non è una cosa banale e, difatti, ci sono diverse formulazioni e scuole di pensiero in merito. In particolare, per comprendere la diverse definizioni disponibili è indispensabile avere una buona panoramica sull'argomento dato che, in mancanza di una sufficiente conoscenza di base, le formulazioni più gettonate risultano essere abbastanza complicate da capire e recepire poiché risultano essere ricche di significato ma, allo stesso tempo, per certi aspetti, limitate.

Una delle formulazioni più diffuse è quella che definisce l'architettura software come "Il concetto di più alto livello di un sistema nel suo ambiente. L’architettura di un sistema software è la sua organizzazione o strutturazione in componenti significativi che interagiscono tramite interfacce. Tali componenti possono essere composti a loro volta da componenti e interfacce più piccoli”.

Una definizione molto simile alla precedente ed altrettanto valida è che: “L'architettura software è la struttura di alto livello di un sistema software, che ne definisce i componenti, le relazioni e le interazioni. Funge da modello (blueprint) sia per lo sviluppo che per la manutenzione, guidando le decisioni tecniche e garantendo che il sistema soddisfi i requisiti di prestazioni, scalabilità e affidabilità”.

L'IEEE (Institute of Electrical and Electronics Engineers) definisce l'architettura software come “l'organizzazione fondamentale di un sistema, definita dai suoi componenti, dalle loro relazioni reciproche e con l'ambiente, e dai principi che ne governano la progettazione e l'evoluzione”. Questa definizione è contenuta nello standard IEEE 1471-2000, che è un punto di riferimento per le architetture software.

Gli elementi chiave di questa definizione dell’IEEE sono:

Organizzazione fondamentale: L'architettura software non riguarda solo i singoli componenti, ma anche come questi si organizzano e interagiscono tra loro per formare un sistema coerente.

Componenti: Questi sono le parti fondamentali che compongono il sistema, come moduli, servizi, classi o qualsiasi altro elemento strutturale.

Relazioni reciproche: Le interazioni tra i componenti, come chiamate di funzione, scambio di dati o eventi, sono parte integrante dell'architettura.

Relazioni con l'ambiente: Anche l'interazione del sistema con l'ambiente esterno, come l'interfaccia utente, la rete o altri sistemi, è importante per l'architettura.

Principi di progettazione e evoluzione: Questi sono le regole, i modelli o le linee guida che definiscono come i componenti sono organizzati e come il sistema si evolverà nel tempo.

Tuttavia, tutte le definizioni di architettura software di un sistema menzionano un processo di decomposizione di uno o più sistemi di alto livello in elementi o componenti significativi di basso livello e, come sostenuto anche da Martin Fowler e Ralph Johnson, non esiste un modo oggettivo per definire sistemi di “alto livello” e componenti “significativi” di basso livello.

Per questo motivo, non è corretto definire l'architettura software come qualcosa che riguardi solo decisioni e strutture di alto livello. I dettagli di basso livello, come le strutture di alto livello, fanno parte dello stesso sistema e definiscono, insieme, l’architettura. Ne discende che tutte le decisioni sull’architettura software, dal livello più alto al livello più basso, possono essere considerate fondanti del sistema.

Inoltre, l'aggettivo “Significativo”, applicato ad un componente o modulo, può essere alquanto opinabile e, di conseguenza, può variare in base allo specifico sistema che si sta considerando, analizzando e sviluppando. Più specificamente occorre tener presente che ciò che è significativo per un sistema potrebbe non esserlo per un altro e viceversa.  L'arduo compito di stabilire quali sono i componenti e come è composta l’architettura di un software spetta agli architetti.

Semplificando la definizione, possiamo dunque dire che:

L’Architettura Software è tutto ciò che consente il corretto funzionamento di un sistema software. Essa prevede la suddivisione del sistema in componenti e l’identificazione delle modalità con cui questi interagiscono. Essa regola i processi hardware e software di impianto e i processi che supportano gli sviluppatori nelle fasi di implementazione nel senso che definisce gli standard da utilizzare, la strutturazione dei progetti e le metodologie di sviluppo da adottare.

Esempi di componenti possono essere, ad esempio, i servizi, il database, le applicazioni interconnesse al sistema, ecc.

Se dovessimo progettare un'architettura software che rappresenti un generico individuo, potremmo, ad esempio, costruirla seguendo una struttura modulare, riflettendo i diversi aspetti del corpo e della mente umana. Ecco un esempio teorico di come potrebbe essere composta:

1. Livello Cognitivo (Intelligenza e Apprendimento)

a) Motore di Elaborazione (CPU): la capacità di ragionare ed eseguire operazioni logiche.

b) Memoria a Breve e Lungo Termine (RAM & Database): l’archiviazione di dati ed esperienze pregresse.

c) Moduli di Apprendimento (AI & Machine Learning): l’adattamento alle esperienze, migliorando le prestazioni nel tempo.

d) Sistema Decisionale (Algoritmi euristici): la logica che guida le scelte basate su informazioni disponibili.

2. Livello Sensoriale e Comunicativo

a) Sensori & Input (Fotocamere, Microfoni, Sensori tattili): la capacità di percepire l’ambiente.

b) Sistema di Elaborazione Sensoriale (Interfacce & API): l’interpretazione dei dati provenienti dai sensori.

c) Output & Attuatori (Display, Audio, Interfacce fisiche): l’interazione diretta con il mondo esterno.

d) Sistema Linguistico (Natural Language Processing): la capacità di comprendere e generare linguaggio umano.

3. Livello Motorio e Operativo

a) Moduli di Controllo del Movimento (Framework & Algoritmi di Attuazione): la gestione dell’interazione fisica con l’ambiente.

b) Sistema di Navigazione (Pathfinding & AI): la capacità di orientarsi e muoversi nello spazio.

c) Unità di Esecuzione (Robotic Actuators): la gestione degli output fisici, paragonabile agli arti di un individuo.

4. Livello Strutturale

a) Core Software & Architettura (Kernel & Framework): la base portante del sistema.

b) Sistema di Integrazione (Bus di Comunicazione & API): il flusso di dati tra moduli, equivalente al sistema nervoso.

c) Sicurezza e Protezione (Firewall, Crittografia & Monitoraggio): il sistema immunitario contro minacce esterne.

5. Livello Sociale ed Emotivo

a) Profilo Identitario (Gestione Dati Utente & Personalizzazione): la rappresentazione unica di ogni individuo.

b) Modulo di Interazione Sociale (AI Conversazionale & Empatia simulata): la capacità di stabilire relazioni interpersonali.

c) Adattabilità & Evoluzione (Sistemi di Feedback & Machine Learning): l'evoluzione delle risposte e il miglioramento della personalità del software.

Questa architettura simulerebbe un individuo bilanciando la logica computazionale con elementi sensoriali, motori e relazionali. Ovviamente, quello descritto nell’esempio è molto più di un classico sistema software ma la decomposizione mostrata rende bene l’idea di cosa significhi identificare componenti e moduli.

Tutto ciò, a grandi linee, rappresenta l'architettura software e ciò che prevede. Essa è il processo in cui definiamo la struttura del sistema atta a soddisfare tutti i requisiti tecnici e operativi, ottimizzando caratteristiche importanti come le prestazioni, la sicurezza, la scalabilità e la manutenibilità.

Ogni decisione presa può avere effetti molto importanti sulla qualità del software prodotto, al punto tale da poterne determinare il successo o il fallimento. In particolare, bisogna sempre considerare gli effetti a lungo termine delle scelte fatte e delle soluzioni adottate in modo da non esporre l'applicazione a rischi. Architetture scadenti possono produrre software scarsamente testabile, difficoltà nell'aggiungere nuove funzionalità e/o difficoltà in fase di rilascio (deploy).

Ora, supponiamo di aver progettato e scelto una certa architettura software per un prodotto di un nostro cliente. Un'osservazione che può farci capire "quanto è buona" la soluzione adottata può essere la seguente:

Se lo sforzo necessario per soddisfare le esigenze del cliente è basso e rimane basso per tutta la durata del sistema, allora il design scelto per l'applicazione è buono ma, se lo sforzo aumenta con ogni nuova versione, allora il design e le scelte adottate non sono ottimali e, quindi, bisogna intervenire apportando integrazioni, correzioni o modifiche, giungendo finanche a riprogettare l'intera architettura nei casi più gravi.

In effetti, col passare del tempo, ogni software viene stressato sempre di più in quanto le richieste dei clienti aumentano. Bisogna prestare molta attenzione allo “sforzo” necessario per rilasciare nuove features. Non possiamo pensare che basti aumentare il numero di risorse in azienda per sopperire a problemi architetturali. Accorgersi dell’esistenza di queste difficoltà non vuol dire che l’azienda e/o il software stiano “fallendo”. Per certi aspetti l’emergere di queste problematiche potrebbe essere un segnale positivo, in quanto potrebbe indicare che il software e la platea dei clienti sono in crescita e che la chiave del nostro successo potrebbe risiedere nell’adozione di una nuova e più moderna architettura software. In pratica, ciò potrebbe voler dire che le scelte fatte al momento della creazione di un sistema software potrebbero non essere più adatte dopo alcuni anni di sviluppo.

Un esempio tipico sono le applicazioni cosiddette monolitiche che, sovente, vengono trasformate in applicazioni a microservizi.

Ma cosa vuol dire l’etichetta “Applicazione Monolitica”?

Tipicamente un’applicazione monolitica è un “monolite software” ovvero un unico, enorme blocco software, identificabile come Applicazione o Sistema Software, al cui interno convivono tanti componenti che hanno diversa natura e scopo ma che condividono risorse hardware, risorse software e dati e, spesso, finiscono per essere fortemente accoppiati ed inter-dipendenti. Generalmente sono sistemi vetusti di 20/30+ anni che, proprio perché molto vecchi, nel corso del tempo sono diventati molto grandi ed ingombranti.

La loro particolarità è che, poiché integrano in un unico componente software (il monolite) centinaia di funzionalità diverse, sono molto veloci ma difficili da aggiornare, manutenere e scalare e, un problema nel rilascio di uno dei sistemi integrati, che di solito sono anche fortemente accoppiati con altri sottosistemi del monolite, inficia la funzionalità e la sicurezza dell’intera applicazione con tutte le conseguenze che questo comporta.

Con questa rapida definizione di applicazione monolitica si conclude questo primo articolo sulle architetture software.

Nel prossimo articolo proseguiremo la trattazione di questo argomento focalizzandoci maggiormente sul concetto di "valore qualitativo" (qualità) di un software, sulla figura del "Software Architect" e sui suoi compiti.

Di seguito un elenco non esaustivo di fonti bibliografiche e sitografiche molto utili sull'argomento.

IEEE 1471 - Wikipedia

ISO/IEC 42010 - Wikipedia

Making Architecture Matter - Martin Fowler Keynote

Architettura del Software

Software Architecture Guide

Patterns of Enterprise Application Architecture di Martin Fowler - Pearson Education