Nel precedente post (Agile Software Architect: mentore nei Team Agile) abbiamo evidenziato come, in un contesto Agile, il ruolo dell’Agile Software Architect è da inquadrarsi come “mentore”:
“Agile Software Architect is an “unofficial leader” in the Team (is not the Scrum Master!), his work is to mentors and teaches people on the Team about architecture and high technology question” [FP]
“L’Agile Software Architect è un “leader ufficioso” nel Team (non è lo Scrum Mater!), il suo lavoro è quello di comportarsi da mentore ed istruire il Team sull’Architettura e su aspetti tecnologici di alto livello” [FP]
Riprendiamo tale concetto, evidenziando come questo ruolo sia fondamentale per un efficiente ed efficace organizzazione, sia delle attività che del Team stesso. Quella che dobbiamo idealmente abbattere è la Torre d’Avorio (Ivory Tower), ovvero il luogo figurativo nel quale ci si isola per perseguire i propri interessi e ideali senza tener conto di ciò che ci circonda.
Ma tale metafora è realmente attinente al ruolo dell’Agile Architect? Per rispondere a tale quesito partiamo dalla figura seguente:
Figura 1 - Ivory Tower
In essa si evidenzia come l’Agile Architect debba favorire la condivisione e la comprensione del sistema su cui si sta lavorando, coniugando al meglio la propria visione di insieme (Breadth) e la visione di dettaglio (Depth) tipica del Team di Sviluppo.
Le distanze tra tali visioni possono portare a:
Mancanza di Trasparenza (lack of transparency), ovvero la scarsa percezione delle motivazioni che hanno determinato le scelte Architetturali;
Mancanza di Comprensione (lack of understanding), ovvero la scarsa percezione del disegno complessivo del sistema.
E’ chiaro che quanto più l’Agile Architect è in grado di socializzare con il Team, trasferire quindi le motivazioni inerenti, le scelte effettuate e far proprie le osservazioni/suggerimenti del resto del Team, tanto più la Torre d’Avorio si abbassa, fino, idealmente, ad annullarsi (Dissolve).
Figura 2 - Dissolve
In questo frangente, un contributo fondamentale viene da un corretto approccio alla creazione dell’Intentional Architecture, enfatizzando e dettagliando le Viste Architetturali che sono di particolare rilevanza per il Team di Sviluppo.
Qui può essere utile aprire una parentesi:
non esiste un unico modo di descrivere un’Architettura, ma bisogna cambiarne la prospettiva in base allo stakeholder a cui si intende presentarla.
Facciamo un esempio: uno sviluppatore è sicuramente interessato a capire l’organizzazione dei moduli (Modules Views) e la comunicazione tra i componenti afferenti (Components and Connectors Views), probabilmente meno interessante risulta l’aspetto legato al deploy (Allocations View). Tale situazione si ribalta nel caso del sistemista, ovvero colui che è responsabile dell’operatività in produzione del sistema.
Nel caso del rapporto tra Agile Architect e Agile Team, combinando tra loro la Socializzazione e Specifiche Viste Architetturali, possiamo idealmente abbassare verso il basso la Ivory Tower, favorendo quindi la Trasparenza e la Comprensione in modo da armonizzare tutte le attività afferenti soprattutto in sistema di Classe Enterprise (figura 3).
Figura 3 - Socialize and Specific Architecture Views
In ultima analisi possiamo rispondere che la metafora della Torre d’Avorio ben si adatta a descrivere quello che non deve assolutamente fare l’Agile Architect, che anzi deve aprirsi al resto del Team e dell’Azienda.
