Agile Life

novembre 2012 - Post

Intentional Architecture: three divergent paths

Nel post Enterprise Agile Principles e Agile Software Architect abbiamo descritto quelli che sono i 7 principi alla base dell’Intentional Architecture:

  • Principle #1: The Intentional Architecture are created by the Agile Software Architect;
  • Principle #2: Build the simplest Architecture that can possibly work;
  • Principle #3: The Teams that code the system Design the system;
  • Principle #4: When in doubt, code it out;
  • Principle #5: They build it, they test their own work;
  • Principle #6: The bigger the system, the longer the runway;
  • Principle #7: System architecture is a role collaboration;
  • Principle #8: There is no monopoly on innovation.

Un Agile Architect deve essere in grado di trovare il giusto equilibrio tra tali principi al fine di bilanciare, secondo le specifiche esigenze del progetto, i tre aspetti qualitativi fondamentali:

  • Change-Encouraging, agevolare e favorire il cambiamento;
  • Quality-Enforcing, spinge sulla qualità del prodotto;
  • Value-Producing, produrre valore per gli stakeholder afferenti;

3paths

 

Change-Encouraging

Questo aspetto favorisce il cambiamento. E’ importante sottolineare che l’esigenza di cambiamento può nascere da fattori fortemente eterogenei tra loro: da una richiesta funzionale a una modifica delle tecnologie utilizzate.

Una efficiente Intentional Architecture deve essere modificabile (modifiable), estendibile (extendable) eadattabile (refactorable). Se tali elementi vengono meno, ci si trova difronte, in extremis, ad una Architettura “classica”, rigida, che rende difficile sposare le richieste di cambiamento naturalmente prodotte durante lo sviluppo di un sistema.

Ciò avvalora la necessità di comprendere le differenze sottili, ma esistenti, tra Architettura e Design, in modo tale da creare una stratificazione delle scelte vincolanti: ad esempio, se decido di cambiare tipologia di ESB (Enterprise Service Bus), questo impatta fortemente sul Design ma decisamente meno sull’Architettura che, al livello di astrazione a cui si pone, contempla un Bus di Integrazione ma non ne specifica la tipologia.

La scelta è quanto mai sensata poiché il Design è strettamente legato alle attività di refactoring effettuate dall’intero Team, il tutto al fine di avere un sistema efficiente, snello e relativamente facile da manutenere.

 

Quality-Enforcing

La qualità è uno dei pilastri dell’Agile, fondato proprio sulla creazione, ad ogni iterazione, di codice funzionante di qualità. Si tratta di accompagnare lo sviluppo incentivando l’utilizzo di best-practice e pattern, coadiuvate dal testing al fine di comprovare l’aderenza alle specifiche.

L’Intentional Architecture è come un binario (rails) che guida lo sviluppo e le relative scelte, in modo da avere un obiettivo globale ben delineato.

 

Value-Producing

L’aspetto più importante della produzione del software è quello di creare valore per l’azienda e per gli stakeholder afferenti. In un mondo perfetto si vorrebbe avere il prodotto finito nel minor tempo possibile e con la massima qualità.

L’Intentional Architecture cattura “il valore” sotto forma di Temi e Requisiti non Funzionali, garantendo che quanto ci si sta approcciando a realizzare sintetizzi al meglio gli interessi dei vari Attori coinvolti.

Allo stesso modo tutta l’attività del Team deve essere orientata a produrre valore, spronato dall’Agile Architect e non orientato solo al cliente: si pensi ad un Team che acquisisce valore perché assorbe nuovo know-how tecnologico.

Il Team ha inoltre il compito di adeguare il Design e proporre all’Agile Architect le necessarie modifiche all’Intentional Architecture in modo tale che gli specifici artefatti siano aggiornati e possano essere utilizzati per trasferire il senso di tale “valore” ai vari stakeholder.

Il quadro del valore viene, da un punto di vista pratico/formale, avvalorato e convalidato dal Test di Accettazione (Acceptance Test).

 

Chiaramente bilanciare cambiamento-qualità-valore non è così banale come appare, anzi dalla loro giusta misura può dipendere il successo del progetto stesso. Ecco ancora una volta evidenziato perché l’Agile Architect è sempre e comunque una figura centrale e di rilievo nello sviluppo di soluzioni software, soprattutto di classe enterprise.

Agile Software Architect: abbattere la Torre d’Avorio

 

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:

 

architect ivory tower

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).

architect ivory tower decrease

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 laComprensione in modo da armonizzare tutte le attività afferenti soprattutto in sistema di Classe Enterprise (figura 3).

architect ivory tower dissolve

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.

 

Agile Software Architect: mentore nei Team Agile

 

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.