Ok il titolo del post è volutamente forte, ma è esattamente ciò che ho pensato leggendo il piccolo documento di 10 pagine redatto da Oracle per introdurre il concetto (e la certificazione...) DBA 2.0.
Va bene che ora 2.0 è di moda, ma che centra il 2.0 con un DBA? I vari tool di amministrazione saranno useranno Ajax? Gli utenti del DB potranno contribuire alla gestione dello stesso e farsi un proprio sistema personalizzato? 
Scherzi a parte la cosa - che mi ha segnalato Gianluca - mi ha reso curioso, complice anche il fatto che Oracle sta spingendo non poco la cosa, con tanto di eventi (http://www.oracle.com/dm/09q1field/17043_ev_oem_tampa_jul23.html) dedicati, e sono quindi andato a leggermi le suddette 10 pagine.
Riassumendo in breve, il DBA 2.0 non è più una figura che si occupa del database, ma deve anche tenere conto di tutti gli insiemi di "contorno" quali storage, sistema operativo, application server, virtualizzazione, networking e via dicendo.
In pratica, non deve più pensare al DB come un oggetto a se stante, ma come una parte dell'intero ecosistema informatico. Un parte importantissima, ma che non può prescidere dai sistemi altrettanto importanti sulla quale opera o dalla quale viene usata.
Detto ciò, direi che in questo Microsoft è sicuramente passi avanti, visto che è chiaro a tutti coloro che usano SQL Server che le competenze per poter sfruttare bene la piattaforma non possono essere limitate al database engine ed a T-SQL. Per svilupparci bene è necessario conoscere anche XML e .NET, per amministrarlo è vitale conoscere il funzionamento del sistema operativo, delle reti e dei sistemi di storage. E tutto questo se non pensiamo alla Business Intelligence (cosa impossibile oggi) in cui le conoscenze si spostano verso settori decisamente distanti da quelle del DBA classico, come Reporting Services, Integration Services, Analysis Services e via dicendo.
Credo che sia sotto gli occhi di tutti che in questo caso, Microsoft è "arrivata prima" ed Oracle (ma direi anche IBM) si è svegliata più tardi, inventandosi il concetto di DBA 2.0 per dare un pò più di sapore a questa nuova situazione ormai ben consolidata nelle realtà aziendali.
Orbene, ci si potrebbe chiedere il perchè di tale situazione. Semplice: non sono mai esistiti DBA per SQL Server (se non rarissime eccezioni) e quindi non c'è nessun concetto pregresso da aggiornare. Il DBA di SQL Server - che invece si sta formando ora, da quando SQL Server 2005 con tutta la sua potenza e complessità ha preso piede - nasce già DBA 2.0....o quanto meno dovrebbe essere tale. Dato che Oracle è diventato anch'esso auto-ottimizzante ed auto-gestito (ahahahaha, proprio vero che le pentole le vendono tutti!) è necessario che i DBA Oracle si evolvano verso nuovi approci più integrati.
Tutta strada in discesa per i DBA di SQL Server? No, non direi proprio. Se è vero che partono in vantaggio per ciò che riguarda l'interdisciplinarietà delle competenze, devono però tenere a mente che hanno un grossa lacuna - data dalla relativa gioventù di tale figura in ambito MS - dal punto di vista dell'amministrazione dell'engine, che è comunque il fulcro al quale tutto gira intorno, e devono capire ben presto che è necessario costruire delle solide basi formali per poter tenere in piedi tutta l'impalcatura che ci si sta costruendo sopra.
Quali sono queste basi? So di essere ripetitivo ma se le cose non cambiano io devo continuare a ripeterle : sono lo studio (anche non necessariamente approfondito e formale) del modello relazionale, dell'architettura dei database, della logica matematica e dei sui risvolti pratici nel linguaggio SQL.
Se queste basi sono solide, tutto ciò che ci viene dato in più (XML, .NET, Cluster, Virtualizzazione, ecc. ecc.) ci permetterà veramente di fare dei grossi balzi in avanti per quanto riguarda qualità e l'efficienza del nostro lavoro. Se no, avremo solamente tante pezze in più da mettere per tappare i buchi di architetture traballanti.