Agile Architecture
La definizione di un’Architettura Software è oggi una delle sfide più interessanti e complesse che un professionista del settore IT possa affrontare.
Tipicamente, nell’approccio classico, la definizione dell’Architettura è un processo che dovrebbe avvenire nelle fasi iniziali di valutazione e definizione di un progetto. In pratica l’Architettura permette di identificare quelli che sono i 3 pilastri di un sistema informatico:
Stile Architetturale, ovvero la tipologia di sistema che si sta realizzando (Client-Server, Web Application, Layered, ecc.);
I Componenti, gli elementi in cui è suddiviso il sistema;
I Middleware di Comunicazione, che mettono in comunicazione tra loro i vari componenti.
L’individuazione di tali componenti porta, successivamente, alla definizione del Design del Sistema, che definisce più in dettaglio le scelte tecnologiche afferenti.
Spesso si utilizza impropriamente la dicitura “Design Architetturale”, ma ciò è profondamente sbagliato. Infatti l’Architettura è a un livello di astrazione più alto del Design e dallo stesso Blue Print Architetturale possono scaturire più design: si pensi, con molta semplificazione, che a due Design che differiscono per i framework di sviluppo utilizzati.
Si intuisce, quindi, che l’Architettura influenza in modo forte le scelte che accompagneranno il Sistema e che una sua eventuale modifica durante la fase di sviluppo può essere decisamente traumatica e costosa. Si pensi, ad esempio, a cosa succederebbe se durante la fase finale di sviluppo ci si accorge della necessità di un ESB per l’integrazione con i sistemi legacy. Se l’Architettura va in una direzione completamente diversa e non contempla tale middleware di comunicazione, probabilmente, sarà molto oneroso (tempi e costi) aggiungerlo.
Ma se l’Architettura deve essere definita in modo meticoloso prima delle altre attività di progetto, come può sposare i concetti alla base delle metodologie Agile che, invece, prediligono adattamenti continui?
Ebbene bisogna spostare il focus dall’Architettura a quella che Dean Leffingwell definisce Intentional Architecture, ovvero l’Architettura verso cui puntare. L’Intentional Architecture “insegue” quattro obiettivi primari:
1. Semplificazione: quanto più si riesce a semplificare il Blue Print Architetturale, tanto più semplice sarà far evolvere l’Architettura durante lo sviluppo del Sistema;
2. Minimalità: ridurre gli elementi contemplanti dall’Architettura al minio necessario per garantire gli SLA qualitativi previsti. Evitare sempre la tentazione di far diventare l’Architettura un calderone dove finiscono anche le scelte tecnologiche;
3. Modularità: suddividere l’Architettura in componenti fortemente disaccoppiati tra loro, utilizzando pattern architetturali che favoriscono tale obiettivo;
4. Punti di Estendibilità (HotPoint): definire sempre dei punti di estendibilità a cui ricorrere per aggiungere funzionalità inattese o non del tutto chiare.
In sostanza l’Intentional Architecture deve essere inizialmente pronta ad accogliere i cambiamenti (flessibile), mentre diventa sempre più rigida man mano che il Sistema viene completato.
E’ chiaro che le funzione Core, ovvero quelle che soddisfano l’obiettivo di minimalità, non possono essere oggetto di grandi modifiche perché metterebbero a rischio il progetto stesso. Proprio in questo ambito il ruolo del Software Architect è essenziale, perché deve immaginare il sistema ancor prima di aver avuto tutti i relativi dettagli, guidando il resto del Team nella sua realizzazione e apprendendo da esso nuovi dettagli per affinare e stabilizzare le scelte iniziali.
