Riprendo l'interessante questione sollevata in questi giorni da Andrea e Dino circa il ruolo dell'architetto nell'ambito di un team di sviluppo.

Voglio subito sottolineare che rimango della ferma convinzione che il ruolo dell'architetto sia di natura prettamente tecnica, il che è totalmente in antitesi con il ruolo del project manager, più orientato alla gestione delle risorse.

Il "fraintendimento" tra i due ruoli deriva dal fatto che sia l'architetto che il project manager svolgono attività per certi versi simili, entrambi sono chiamati a prendere decisioni importanti nell'economia del progetto, ma queste decisioni sono di natura decisamente diversa. Se da un lato il PM deve prendere decisioni circa le tempistiche, i costi, le assegnazioni di risorse e gli approvvigionamenti e deve gestire la comunicazione con gli stakeholder (in primis il committente finale), l'architetto ha invece una forte focalizzazione sul prodotto e sulle scelte che lo riguardano, fa parte del team di sviluppo e con esso condivide gioie e dolori.

Sia il PM che l'architetto devono gestire criticità, ma, se il primo si pone spesso nell'ottica del cliente, il secondo è inevitabilmente portato a ragionare in modo tecnico e focalizzato sulla tecnologia. Il PM gestisce le criticità che riguardano il progetto in termini di schedulazione, assegnazione dei compiti e ripartizione del budget, l'architetto gestisce le criticità progettuali di natura tecnica, che nulla hanno a che vedere col diagramma di Gantt o il diagramma di carico. In molti casi questi due tipi di criticità sono in contrasto tra loro!

L'interlocutore del PM è per lo più il committente, quello dell'architetto è da una parte l'analista e dall'altra il team di sviluppo. Dalla capacità di prendere decisioni tecniche consapevoli dipende in gran parte la riuscita del progetto. Dalla capacità di condividere le scelte col team, anche tramite un coinvolgimento diretto nelle attività progettuali, dipende l'individuazione delle soluzioni migliori. L'uso di strumenti e metodologie come UML o affini deve essere orientata a fornire elementi per condividere le idee e per prendere le decisioni giuste, non sempre così scontate, perchè i fattori di rischio nelle scelte tecniche sono sempre elevati quando si sviluppano applicazioni non banali e complesse. Fare diagrammi solo per il gusto di farlo, solamente come esercizio di stile o perchè "fa figo", non serve a niente ed è un inutile spreco di tempo e risorse.

L'architetto scrive codice? Assolutamente si! L'architetto conosce la tecnologia che usa? Assolutamente si! Per dire come la penso, credo che non ci sia nulla di meglio che riportare uno stralcio dell'intervista a Scott Guthrie presente sul numero di gennaio di The Architecture Journal. Lo stesso editor-in-chief Simon Guest (l'unico che è autorizzato ad accedere in Microsoft come Guest... :) ...) in un suo post di qualche tempo fa sottolinea la bontà della risposta di Scott... Riporto il testo originale.

Ron Jacobs: I find that there are very few people who are purely architects in that they just design stuff and never write code. Most people are a mix: they spend some time developing, some time architecting. What advice do you give to people, somebody who has been doing development but wants to do more architectural thinking?

Scott Guthrie: Writing code I think is valuable for an architect. Not necessarily production code you check in, but constantly be trying new technologies out, new approaches out and feeling how the system works. I don't frankly write a lot of production code these days, really any. But I spend an hour or two every day writing code. Whether its samples, whether its prototypes I pass on to people, or whether it's some fun personal project - trying things out, thinking of ways to structure things. Being that hands-on is very valuable in a code architect perspective...omissis...

Per concludere, dico che se un architetto o presunto tale si trova a dover prendere decisioni sull'assegnazione delle risorse o sulla ripartizione dei costi, probabilmente non sta facendo l'architetto, ma un altro mestiere. La visione che l'architetto ha del progetto è di natura tecnica ed è importante che rimanga tale senza disturbi che possano invalidare la bontà delle sue scelte.

L'architetto scrive codice (magari non con la velocità di uno sviluppatore), perchè da questa attività trae la consapevolezza delle sue scelte (per esempio, durante la fase di prototipazione). L'architetto scrive codice, perchè dalla bontà delle sue decisioni (prese con cognizione di causa) deriva anche il rispetto e la considerazione del team. Un architetto "posto fuori dal contesto" non solo non serve a nulla, ma rischia di fare parecchi danni.