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.
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) e adattabile (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.