Architetture 2.0

Architetture, pensieri.

Passato

In qualità di mentore/trainer/coach su vari progetti mi sono sempre rafforzato. Percepivo le architetture software come un "insieme di componenti, ognuno con un preciso scopo, al fine di risolvere un problema". La percezione era guidata principalmente dalle competenze tecniche, dalle scelte tecnologiche e poi dal problema da affrontare.
Tant'è che nella mia testa, quando si parlava di architetture, era naturale pensare alle infrastrutture JEE, che in qualche modo hanno tutti i componenti che servono per produrre il 90% dei software moderni. La presenza della tecnologia era così forte e preponderante, da poter (e riuscire a) giustificare l'adozione di componenti e tecniche anche se non indispensabili alla corretta soluzione del problema.

Dunque, le architetture le percepivo come la:
suddivisione logica, di componenti software,
hardware e di meccanismi di comunicazione,
al fine di ospitare la soluzione ad una richiesta.

Pensieri:
Ho sempre pensato che l'architetto software è diverso dall'ingegnere del software. La differenza ritengo stia nel fatto che:

• l'ingegnere giunge alla soluzione, applicando spesso e voltentieri un metodo o una regola, conosciuta, definita e consolidata: si basa e resta nel campo del conosciuto.
• l'architetto aggiunge alle regole, ai metodi, anche un po' di creatività.
  Ovvero cerca la soluzione utilizzando strumenti e tecniche anche che non gli appartengono, che non sono ancora imparati. La grossa differenza che percepisco è la "visione" per intraprendere una strada che è nuova, che porti alla soluzione e che porti innovazione.

Personalmente mi sono sempre sentito più architetto che ingegnere, sebbene non sia nessuno dei due. Ho sempre fatto fatica a spiegare le mie "soluzioni", perchè spesso derivavano da un modo non convenzionale e sopratutto hanno una parte "ignota" anche a me; cerco di trovare una via, nuova, stimolante e divertente.

Questa differenza mette in luce il fatto che l'architetto ha una visione più "aperta" della soluzione, con un margine ed un aggancio oltre il campo del conosciuto. Certo che la conoscenza cresce con l'esercizio e con il tempo, pertanto questo margine di ignoto, viene colmato dal tempo. E questo rafforza la mia visione di architetto, ovvero qualcuno in grado di dare "futuro" ad una soluzione. Una soluzione che avrà parti consolidate (e dunque vecchie dopodomani) e parti innovative (e dunque moderne dopodomani). Addirittura nelle proposte commerciali, definisco l'architetto un "Time Warp architect", in grado di estendere nel futuro e rendere moderna una soluzione di oggi, anche domani. Questo prevede sicuramente una grande flessibilità, visione, curiosità e sopratutto oggettività rispetto alla tecnologia.

Evoluzione, primo segnale:

Ora, con l'avvento del Social Web, il mio concetto di architettura, fortunatamente, sta di nuovo mutando.
Questa nuova percezione ed evoluzione non è ancora chiara e definita ed andrà a rafforzarsi e comporsi sempre di più con il passare del tempo.

Le architetture non sono solo un sistema di componenti con un ruolo ben preciso, ma sono anche un insieme di comunità, alle quali fornire, ed attingere idee e soluzioni.
La comunità diventa un componente, che estende il componente software, per promuoverlo ed estenderlo nel tempo.
Ora spesso penso, quando disegno una porzione di codice, di cercare supporto oltre che nello strumento anche in uno strumento con una comunità intorno, dalla quale attingere e fornire idee, soluzioni ed esperienze.
Probabilmente i prossimi diagrammi architetturali che produrrò, oltre che avere una suddivisione per componenti e ruoli, avranno anche un altro strato:

• una suddivisione per comunità dove ogni comunità potrà essere legata ad un solo componente, oppure potrà spaziare in più componenti.