Architettura: sfatiamo i luoghi comuni…

Michele Aponte — Fri, 12 Jun 2009 17:42:12 GMT

Current revision posted to Articoli by Michele Aponte on 12/06/2009 19:42:12

Conscio della grande confusione che si fa sui termini "tecnici" utilizzati nel nostro campo, confusione che io stesso non ho timore ad ammettere, ho pensato che come primo articolo per DotNetCampania potesse essere utile fare un po' di chiarezza sul significato dei termini che utilizzeremo in questa serie di articoli sull'architettura e le applicazioni enterprise.

Cominciamo subito dalla definizione stessa di architettura, che meraviglia delle meraviglie, è standardizzata dalla norma ANSI/IEEE Std 1471-2000, la quale ci dice che l'architettura è

"The fundamental organization of a system embodied in

its components, their relationships to each other,

and to the environment, and the

principles guiding its design and evolution"[1]

Quindi possiamo dire che con il termine architettura intendiamo l'organizzazione di un sistema in componenti relazionati tra di loro, che interagiscono con l'ambiente circostante secondo dei principi, principi progettuali, principi che ne guidano la progettazione e l'evoluzione.

Chi è dunque l'architetto? Secondo IEEE è la persona, il team, l'azienda responsabile dell'architettura del sistema. Semplice? Si, ma quanto spesso confondiamo questo figura con l'analista o il project manager? D'accordo, possono essere la stessa persona, ma non svolgono assolutamente lo stesso ruolo. Quindi:

Architetto != Analista && Architetto != Project Manager

O per gli irriducibili di Visual Basic:

Architetto <> Analista AND Architetto <> Project Manager

L'analista è un esperto del dominio applicativo, delle regole che devono governare il sistema, che in linea di massima può non essere un tecnico, anzi, meglio! In questo modo è libero da pregiudizi implementativi che potrebbero influenzare il suo modo di percepire i requisiti del cliente, potendosi concentrare unicamente sul COSA e non sul COME.

Il Project Manager è tutto altro, e wikipedia è chiarissima sull'argomento:

"Il project manager è un ruolo di gestione operativa. Tale figura è il responsabile unico della valutazione, pianificazione, realizzazione e controllo di un progetto. [...] Il suo obiettivo essenziale è quello di assicurare il rispetto dei costi, dei tempi e della qualità concordati e soprattutto il raggiungimento della soddisfazione del committente.". [2]

Non sarei riuscito a dirlo meglio.

Un altro errore molto comune e confondere l'architettura con il design di un'applicazione, il design al limite è una parte dell'architettura ma non è l'architettura, cosa che si evince chiaramente dalla definizione data sopra:

Design Є Architettura

Cosa fa dunque un architetto? Potremmo riassumere il suo lavoro nei seguenti punti:

Prende i requisiti passatigli dall'analista.
Suddivide il sistema in sottosistemi assegnabili ad un singolo programmatore o a un gruppo di lavoro.
Verifica se è il caso di utilizzare componenti già esistenti per alcuni sottosistemi.
Crea le specifiche da passare ai programmatori per la realizzazione del sistema.

Analizziamo questi punti. Ok, l'analista ha finito il suo lavoro e ci consegna i requisiti da soddisfare, da questo momento in poi questo o questi documenti diventano il nostro vangelo, ma giusto per farci un'idea cerchiamo di capire che cosa ha fatto in assenza dello spirito santo per redigere il nostro testo sacro.

Per prima cosa è andato dal cliente e ha individuato gli stakeholder, cioè quei personaggi a cui deve letteralmente estorcere le informazioni che gli sono necessarie per stabilire quali sono i requisiti del sistema da realizzare.

Vi state domandando perché estorcere? Molto banalmente perché non è assolutamente detto che sappiano cosa vogliono veramente ed è qui che si vede la bravura di un analista: ridimensionare gli stakeholder su quello che un sistema software può fare e concordare insieme quello di cui veramente hanno bisogno per ottenere un vantaggio dall'utilizzo del sistema che ci si appresta a realizzare.

Se alla fine del processo gli stakeholder sono soddisfatti il progetto avrà successo, il che significa che probabilmente saremo pagati per il nostro lavoro, in caso contrario cominciate a chiamare l'avvocato. Finite le interviste e le riunioni con gli stakeholder l'analista definisce i requisiti funzionali e non funzionali (scalabilità, sicurezza, ecc.), di cui parleremo nel dettaglio nel prossimo articolo sull'architettura.

Ricevuti i requisiti e studiatili con attenzione l'architetto comincia a suddividere il sistema in sottosistemi sempre più piccoli in modo da rendere possibile la valutazione tempi e risorse. Lo scopo in questa fase e determinare il "costo del sistema" in modo da permettere a chi di dovere di verificare i margini del budget disponibile o a definire il costo preventivo con il quale fare l'offerta al cliente.

E' questo il momento in cui l'architetto decide se eventualmente è il caso di utilizzare componenti già pronte, commerciali o non, per alcuni sottosistemi cercando di tenere a bada la sua natura di programmatore che lo esorterebbe a mettere alla prova le sue capacità tecniche!

L'ultima fase del suo lavoro consiste nel creare le specifiche da fornire ai programmatori per la realizzazione del sistema, il cui livello di dettaglio varia a seconda della complessità del sistema e delle competenze delle risorse coinvolte: si va da una descrizione passo passo del lavoro da svolgere, con tanto di use-case, class e sequence diagram (in alcuni casi mi è anche capitato di dover scrivere le query SQL o Linq da utilizzare), alla semplice descrizione del caso d'uso lasciando piena autonomia allo sviluppatore.

Nei prossimi articoli analizzeremo questi passi in maniera più approfondita progettando insieme un ipotetico sistema di esempio, dandoci dei requisiti e realizzando la documentazione necessaria. Naturalmente i vostri feedback e le vostre idee saranno fondamentali per simulare un vero e proprio brain storming tra architetti al fine di fare le giuste scelte per il problema che ci porremo. Alla prossima puntata.

[1] http://www.iso-architecture.org/ieee-1471/

[2] http://it.wikipedia.org/wiki/Project_manager