Nel post Agile Architecture [p1] abbiamo dato una definizione all’Intentional Architecture e definite i suoi quattro obiettivi portanti, mentre in Enterprise Agile Principles e Agile Software Architect [p2], che abbracciando i valori del Manifesto Agile, abbiamo definito 8 principi per lo sviluppo di soluzioni Agile Enterprise e il ruolo dell’Agile Software Architect.
Come evidenziato, l’Intentional Architecture assume un ruolo che funge da guida all’evoluzione del Sistema, un po’ come le rotaie guidano il percorso del treno. Ciò porta a definire un quinto obiettivo fondamentale, che va ad unirsi ai quattro esplicitati in [p1]:
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) Estendibilità: definire sempre dei punti di estendibilità a cui ricorrere per aggiungere funzionalità inattese o non del tutto chiare;
5) Solidità: lo skeleton Architetturale deve essere robusto al fine di valutare adeguatamente le implicazioni tecnologiche del progetto e supportare adeguatamente il Planning Agile del progetto.
Tali obiettivi, implicitamente, impattano sui due aspetti fondamentali nel processo di definizione dell’Intentional Architecture:
*) Aspetto Temporale [Temporal Aspect], che definisce “quando” le scelte vanno effettuate al fine di ritardare quanto più possibile l’inserimento di vincoli che inficiano l’evoluzione dell’Architettura stessa. Questo aspetto evidenzia la sostanziale differenza con l’approccio classico (non Agile) alla definizione dell’Architettura che presuppone la definizione preventiva di tutti gli elementi dell’architettura stessa, tanto da rendere difficile e costoso effettuare modifiche successivamente. Nel caso dell’Intentional Architecture (Agile), il compito dell’architetto è quello di avere un approccio lazy, ovvero rendere l’architettura sufficientemente flessibile, ritardando scelte che scaturiranno dalla successive fase di design e di sviluppo, tipicamente intrecciate tra loro. Questo, giustifica inoltre, l’inserimento nel Team di Sviluppo dell’Agile Software Architect, con una funzione da “consulente” per le scelte che impattano sul completamento e sulla review degli elementi architetturali;
*) Aspetto Strutturale [Structural Aspect], che definisce “come” definire le componenti primarie dell’Architettura, in modo da tracciare una linea guida per la realizzazione del progetto. Questo Aspetto implica la scelta dello specifico stile architetturale, che si concretizza nella scelta di tre stili portanti:
1) module styles, ovvero il set di moduli e le relative regole di combinazione afferenti;
2) component-and-connector (C&C) styles, ovvero il set di componenti, connettori e le relative regole di comunicazione tra loro;
3) allocation styles, ovvero come il sistema viene messo in esercizio.
La definizione di un’Intentional Architecture passa attraverso una strutturazione quanto più possibile chiara e basata su pattern affidabili che garantiscano una basso accoppiamento dei moduli e dei componenti, in modo da limitare gli impatti sulle eventuali modifiche richieste.
Chiaramente l’Aspetto Temporale e l’Aspetto Strutturale sono agli antipodi tra loro. Infatti più si ritardano le scelte (aspetto temporale), al fine di aumentare la possibilità di refactoring dell’architettura, minore è l’enfasi strutturale che è possibile dare all’Intentional Architecture. Dualmente è valido anche il contrario: più ci si concentra sull’aspetto strutturale, effettuando quindi scelte in merito al “come” l’architettura è fatta, minore è la possibilità di ritardare scelte vincolanti.
Questa relazione diretta può essere riassunta in quella che andremo a definire Agile Architect Uncertainty Principle [Principio di Indeterminazione delle Architetture Agile]:
“Più si affina un aspetto, tanto più l’altro perde di consistenza” [F.P]
Proprio per affrontare la sfida dell’ Agile Architect Uncertainty Principle, è indispensabile che il processo di definizione dell’Intentional Architecture sia realizzato da un Software Architect che sappia cogliere le esigenze proprie del progetto e individuare il giusto mix tra Aspetto Temporale e Aspetto Strutturale.
[p1] Architetture Agili: una scelta possibile
[p2] Enterprise Agile Principles e Agile Software Architect
[F.P] Felice Pescatore
