Mi è servito un sondaggio tra colleghi e clienti per decidere di scrivere con l’obiettivo di chiarire la differenza tra complicato e complesso, che nel linguaggio comune vengono utilizzati in modo pressoché intercambiabile.
Complicato o complesso ?
I perché sulle architetture
Questo post nasce da uno spunto (un video) che mi richiama i frequenti 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 utili in qualche caso, quindi meritevole di essere diffuso.
Eccolo.
links for 2011-09-22
-
Visualizza ontologie
-
Esplorazione grafica RDF