I perché sulle architetture – Imola Informatica

Questo post nasce da uno spunto (un video) che mi fa ricordare i dibattiti a cui partecipo nelle aziende che frequento.

I dibattiti, le riunioni, le chiacchiere informali a cui mi riferisco riguardano la necessità, le motivazioni, i vantaggi di avere un Gruppo Architetture formalizzato e operante, cosa fa e come lo fa, che ruolo deve avere, che relazioni con gli altri gruppi deve avere, che potere deve avere e a chi deve fare capo, se si deve occupare solo di IT o anche d’altro, …. e tutto ciò che si può collegare a questo tema.

Le situazioni e il tenore degli argomenti varia moltissimo da azienda a azienda, e in alcune occasioni i ragionamenti sfociano in autentica gazzarra ideologica; dipende molto dai partecipanti e dalla cultura e mentalità dell’azienda e degli individui. Quasi mai se ne esce sereni e migliori, perché il dibattito ristagna quasi sempre su domande di questo tipo, in modo dipendente da situazione e maturità dell’azienda:

che cosa è e perché serve avere un gruppo architetture?

perché delle architetture non basta che se ne occupino i progetti (NDR come si è sempre fatto, cioè non occupandosene quasi mai se non a livello di tecnologie da scegliere)?

ma perché ci deve essere qualcuno a cui raccontare cosa fa un progetto “al suo interno”?

ma gli architetti si devono occupare solo della parte IT o anche della organizzazione (cioè del modo in cui si svolgono le attività – nell’IT e/o anche fuori-)?

il modello architetturale SOA è meglio di un modello a Silos e perché?

Tutte queste domande sono lecite e al tempo stesso le risposte, quali esse siano, sono indimostrabili matematicamente quindi insoddisfacenti per chi è prevenuto. Ed è la quasi totalità dei casi.

La constatazione pratica è che chi non vuole convincersi di un cambiamento per sue valide ragioni individuali ha tutte le possibilità di giustificare il suo atteggiamento, e nessun argomento, se non dimostrabile matematicamente, lo convincerà per il solo fatto che non vuole essere convinto.

Lo spunto che mi ha fatto decidere di scrivere è un video che ha scatenato un dibattito tra la tribù che sostiene che l’Enterprise Architecture è una disciplina a livello aziendale e quella che sostiene che è una disciplina IT e a quella parte deve rimanere limitata.

Questo video mi piace perché è efficace per tutti quelli che non hanno dimestichezza con la globalità di un IT e non hanno presente la “complessità emergente” che negli anni sta caratterizzano i Sistemi Informativi. Spesso questo connubio porta alla sottovalutazione dell’impatto di un singolo progetto sul tutto, visto che la prospettiva da cui il progetto guarda le cose è individuale, ma il video sottolinea bene l’importanza di collegare una decisione al tutto e non solo al singolo obiettivo.

Ci sono però altri aspetti che non condivido affatto:

il video ha un titolo errato, in quanto quella di cui si parla non è come il titolo farebbe pensare Enterprise Architecture bensì IT Architecture

viene trattato solo un aspetto, la riduzione o la non generazione di inutile complessità, che non è certo la sola ragione per cui l’architettura deve esistere: quindi rischia di essere riduttivo e deviante

Al di là di questi “difetti” lo considero uno strumento di consapevolezza probabilmente efficace in qualche caso, quindi meritevole di essere diffuso.

Eccolo.

http://www.youtube.com/watch?v=LpAhEKPc0FA&feature=player_embedded