Attenzione... è un post lungo, provocatorio e scritto di getto... quindi per favore... non massacratemi! 
Rileggendo il post di Sam, mi è venuta voglia di parlare di quella che chiamo 'la diversità fra "architetti" e "Architetti"' ovvero, chi si crede "architetto" e non ha mai realizzato un sistema "enterprise" e chi fa l'"Architetto" e realizza effettivamente sistemi "enterprise", dove per enterprise intendo sistemi "grossi", con decine, centinaia o migliaia di sottosistemi distribuiti, e dove non si sta tanto a discutere di "persistance ignorance", di "IPOCO" o di "POCO", di contrapposizione tra NHibernate e LINQ/EF, di ASP.NET vs MonoRail, ma si va su problemi di "ordini di grandezza" più grandi.
Sistemi dove MSMQ, Biztalk, Enterprise Services, WCF, etc... ma anche MQ Series, WebSphere, WebLogic e famiglie sono presenti in dosi "difficilmente tollerabili" da noi sviluppatori "umani".
Attenzione! Non dico che P.I., IPOCO vs POCO etc... non siano importanti, anzi! Ma da li a ritenerli "fondamentali" per l'adozione o meno o per la riuscita o meno di una architettura "enterprise"... Beh lasciatemi dire che ce ne sono cose più importanti.
Quanti "architetti" mettono al PRIMO posto la SECURITY in tutto quello che progettano, partendo proprio dalle primissime fasi?
Ci sono sistemi realizzati in .NET che fanno funzionare servizi alla base dell'infrastruttura di uno stato moderno, come treni, poste, aerei, etc... e che sono stati progettati da "Architetti" che magari non frequentano i circoli con la puzza sotto il naso (per fortuna poco o per nulla diffusi da noi), che non sono MVP Solutions Architect (o di qualsiasi altra categoria, attenzione: non dico che gli MVP S.A. hanno la puzza sotto il naso o cosa... tutt'altro, o meglio forse qualcuno all'estero si è montato la testa...) e che poi "schifano" quello che fa Microsoft in quanto tale, e che magari quello che hanno progettato è stato realizzato "ancora" con .NET 1.1 e i DataSet, o con collezioni custom e un bel "plain old ADO.NET".
Ci sono sistemi "enterprise" che fanno girare l'e-commerce che sono ancora realizzati in Classic ASP/VB6, ma la cui architettura, progettata magari dieci anni fa, regge ancora e svolge degnamente il compito, pur con tutti i limiti del caso...
Ve le immaginate le implicazioni di SECURITY in questi sistemi? Eppure la bibbia degli "architetti" di security non ne parla...
Prendiamo un altro tema. In progetti con 50, 100 o più sviluppatori non si può pensare di adottare le "tecnologie alla moda" (ALT.NET o Microsoft poco importa) solo perchè sono meglio. Bisogna valutare una serie di fattori che spesso gli "architetti" non considerano. E' facile, per una persona, imparare NHibernate, ma siamo sicuri che senza gli strumenti appropriati siamo in grado di farlo scalare su sistemi realizzati da 50, 100 o più sviluppatori? Non parlo di far scalare NHibernate in quanto tale, ma di far scalare la sua "adozione", senza strumenti che ammorbidiscano la curva di apprendimento.
Non pensate che dall'altra parte si stia meglio, perchè anche se molti di noi "invidiano" Java, Ruby, etc... so di enormi "travagli" prima di arrivare dove sono adesso... la parola EJB ricorda qualcosa? C'è gente che ha ancora gli incubi per i "crolli" nei tempi di risposta e nella scalabilità quando gli EJB erano stati adottati dovunque e a sproposito.
E poi... non bastano i POJO, Hibernate, SCA, etc... a fare un buon sistema, ci sono sviluppatori Java che non sanno ancora cosa siano i parametri nelle query (o "bind variables" se ricordo bene come cavolo si chiamano in Oracle), figuriamoci se sono in grado di capire le "centinaia" di file di configurazione XML che servono a tenere in piedi un sistema "enterprise". Eppure spesso è con queste persone che bisogna realizzare i sistemi architetturalmente complessi.
Io AMMIRO chi realizza architetture complicate, in Java, .NET o qualsiasi altro ambiente, e magari lo fa "chiuso nel suo ufficio" senza fregiarsi di titoli complicati, senza "esternare" continuamente su quanto è bravo, quanto è "alternativo", etc...
Ritornando al post originale, queste frasi mi hanno fatto molto riflettere, e rispettano alla perfezione quello che penso:
The problem with this is that there are many things that Architects do that are far beyond this AND PRODUCE DIRECT BUSINESS VALUE. In a famous piece of hypocrisy, Jeremy says, "the definition of the role of an enterprise architect that I see at places like James McGovern's blog puts more focus on business process engineering and IT strategy in general and analysis than technology.
...CUT...
That's right Jeremy: us good Software Architects totally understand the business domain AND all the technology including code! I got a clue for you Jeremy: As Clemens Vasters took me to task, most (90%) of the world is Enterprises and not 10 person XP teams.
Ri-leggete il resto alla Fonte: Goodbye CodeBetter and ALT.NET
P.s. a scanso di equivoci, non ce l'ho con nessuno in Italia. Qui da noi purtroppo "lavorare su sistemi Enterprise" non è così comune, e spero, nel tempo, che si riesca a rendere più "evidente" lo sforzo di chi produce architetture molto complesse.
P.p.s. è giusto "criticare costruttivamente" le scelte di Microsoft o dei team di sviluppo di tecnologie particolari. Non c'è bisogno di una serie di "Yes man" ma nemmeno di una serie di "No man"!
P.p.p.s. spero che iniziative come GUISA, inclusi i webcast, i tour, etc... servano per "creare" nuovi "Architetti", a prescindere dai sistemi che effettivamente devono andare a realizzare. Io, nel mio piccolissimo, il mio impegno ce lo sto mettendo, anche se diluito tra tutte le cose che ho da fare... purtroppo però la maggior parte degli "Architetti" non ha tempo, non partecipa o semplicemente non conosce GUISA, e questo si traduce nella mancanza di confronto.
P.p.p.s. sempre a scanso di equivoci, io non mi metto ne tra gli "architetti", ne tantomento tra gli "Architetti". Al massimo mi considero un "esternatore" che ogni tanto mette il suo "zampino" in qualche sistema...
P.p.p.p.s. e adesso facciamo un sondaggio... lasciate un commento se siete arrivati a leggere fino a qui senza saltare neanche un pezzo... 