Per questo post prendo spunto da quello di Lorenzo. Volevo dare un feed, ma rischiavo di non starci dentro.
Purtroppo io non ho mai avuto (dico purtroppo e sono sicuro che non me ne pentirò, un giorno) la possibilità di collaborare alla progettazione di un'architettura enterprise. Enterprise nel senso più ampio che si possa definire, con sistemi eterogenei che devono interagire, dalle code ai sistemi di EAI. Non ho mai avuto l'opportunità di convocare qualche guru per offrirci la sua  consulenza, non per arroganza o supponenza: semplicemente non ce n'era il motivo. Al limite potremmo chiamare qualche "Evangelist" MS o qualche "esperto" IBM, a seconda dei sistemi.
E' anche vero, secondo me, che se ci si trova davanti a sistemi enterprise complessi, l'architetto non è solo uno, e non è solo una l'azienda che si occupa del lavoro grosso. Ci saranno architetti specializzati nell'EAI, altri in SOA, altri in tutto quello che volete. Nel mio primo post dicevo che gli architetti devono sapere fare tutto, ma è anche vero che non si può entrare in tutto al giusto livello di dettaglio che gli consentirebbe di fare davvero da fact totum (ammesso che l'azienda committente te lo faccia fare).
Però è ancora vero che un architetto deve anche sviluppare... per conoscere quello di cui sta parlando. Deve conoscere il singolo pattern (GOF/Fowler) o il singolo framework (per IOC: Spring? Castle?), deve sapere dei tool O/RM (ce ne son tanti e non li elenco), deve sapere di MSSQL o di Oracle, meglio un db relazionale o uno ad oggetti (che veniva visto come la panacea dei mali del relazionale fin dai miei esami di basi di dati, ma che ancora non ho visto messo in pratica).

Allora veniamo al dunque! Quante cose deve spaere fare l'architetto? Non si dice che chi più in alto va, meno lavora ;).
Se devo crescere professionalmente per fare 50 mestieri diversi... preferisco restare geometra! :)
Il vero dunque è questo: un architetto enterprise come fa a sapere tutte queste cose? Secondo me più si sale nella complessità e maggiore è il grado di astrazione che deve avere. E putroppo si perde il contatto con la parte "core" (il codice, la tecnologia, il framework, il singolo pattern).

A voi la palla.

PS: il sottotitolo del blog è "un architetto per domarli tutti"; mi rendo conto che potrebbe sembrare presuntuoso, da parte mia, ed infatti specifico anche che non sono io l'architetto in questione; ripensandoci bene, però, potrebbe avere senso una "gerarchia architetturale"? O si richierebbe di burocratizzare un processo (quello dell'ingnegneria del sw) che di certo non ha bisogno di ostacoli questo genere?

PPS (per adattarmi al modello "geniodelmale"): la security è solo uno degli aspetti architetturali, che potrebbe essere il più importante solo in particolari contesti; è male non parlarne, in ogni caso;il fatto che alcuni testi non ne parlino significa che gli autori non ne hanno mai avuto bisogno (improbabile) o che non l'abbiano mai applicata (forse) o che non abbiano mai lavorato su progetti concreti e complessi (potrebbero essere dei professori universitari, ad esempio, ma non possiamo fare di tutta l'erba un fascio); o semplicemente non si sappia da dove cominciare, per cui non se ne parla :)