Abbiamo già affrontato la questione inerente la necessità di avere, almeno in ambito Enterprise, una (Intentional) Architecture anche abbracciando la filosofia Agile. Da qui la necessità di avere un Agile Software Architect per la definizione dell’Intentional Architecture e la sua evoluzione.
A questo punto viene però da chiedersi: ma qual è il ruolo dell’Architetto nell’ecosistema di un Team Agile e come si può evitare che esso diventi un collo di bottiglia (bottleneck)?
Bottleneck
Una definizione che potremmo utilizzare è la seguente:
“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]
Estremizzando è chiaro che un Architetto, nel processo di sviluppo classico, può diventare un collo di bottiglia se l’Architettura non viene capita dal Team e se tutte le domande inerenti ad essa vengono poste all’Architetto che, difficilmente, potrà rispondere velocemente a tutto.
L’Agile Software Architect dovrebbe essere un “dispenser of architecture and technology guidance”, ovvero favorire la condivisione del know-how relativo all’Architettura e guidare il Team nelle scelte di Desing. In tal modo il bottleneck si riduce fortemente, fino al caso ideale di annullarsi completamente perché il Team è auto-sufficiente.
Cosa succede a questo punto al ruolo dell’Agile Architect se il Team è autonomo?
In realtà l’Architettura, oltre ad essere un manufatto tecnologico, è anche il Blue Print del sistema ed ha senso, sempre e comunque, contemplare il ruolo dell’Architetto che ha la mission di radicare l’Intentional Architecture nel DNA dell’azienda (non solo nel Team di Sviluppo), facilitandone le discussioni relative e abbracciando la sfida del miglioramento continuo.
