SaaS (Software as a Service): dal Web 2.0 a SOA

Il termine web 2.0 proviene da una definizione di Tim O’Reilly e descrive il web come piattaforma; gli utenti (anche a più mani) creano e manipolano contenuti, i gestori offrono l’infrastruttura necessaria per farlo, innescando un processo che si autoalimenta: i contenuti esistenti, fruibili in più modi oltre l’interfaccia classica, manipolati da utenti differenti dai loro creatori, sono offerti arricchiti su piattaforme diverse da quella iniziale.

Il web 2.0 trasforma i webmaster del “web 1.0″ in gestori della piattaforma e gli utenti in autori di contenuti (anche derivati). Il rapporto tra queste due figure continua ad essere regolato da termini d’uso.

Le piattaforme non si concentrano unicamente sulla creazione, manipolazione ed esposizione dei contenuti, iniziano ad occuparsi ed offrire altro: genericamente software on-demand. Il software, ossia, come commodity: ciò che serve, quando serve, come serve, con la qualità pattuita, senza preoccuparsi, disporre o gestire hardware, licenze, personale e ciclo di vita. Ciò prende il nome di SaaS (Software as a Service).

SaaS trasforma i gestori della piattaforma in produttori di servizi e gli utenti in consumatori. Il rapporto tra queste due figure è regolato dallo SLA (Service Level Agreement).

Ciò che si viene a creare è inquadrabile nel paradigma di SOA (Service Oriented Architecture). Più precisamente SaaS può essere, in taluni casi, paragonata ad una SOA oltre i confini aziendali: servizi accedibili mediante interfacce standard, con valore diretto o indiretto per il business, regolati da SLA ed offerti remotamente da terzi. Addirittura possono essere offerti come servizi remoti gli stessi componenti di un’infrastruttura SOA: mediatori, orchestratori, ecc.

SaaS è un’opportunità, sia per i produttori che per i consumatori. I primi possono, ad esempio, contare su un mercato prima impensabile, gestire il ciclo di vita del software in autonomia, avere totale controllo delle installazioni e così via. Gli altri (specie se si parla di PMI – Piccole e Medie Imprese) possono disporre di servizi cui, per l’alto costo o per la complessità dell’infrastruttura, non avevano avuto accesso sinora, ottenendoli il giorno stesso, con la qualità desiderata, senza preoccuparsi di hardware, licenze, personale per installazioni, manutenzione, aggiornamenti, ecc. SaaS, inoltre, permette allo staff IT di concentrarsi sull’allineamento al business, senza distrazioni.

Per giungere alla situazione che descrivo ci sono problemi da superare, ne elenco alcuni.

Il primo e più evidente riguarda i dati: tutti noi ci avvaliamo giornalmente di applicazioni remote come webmail (Google Mail, Hotmail, …), storage on-line (Box.net, Xdrive, …) e condivisione di documenti (Google Docs, Zimbra, …), il punto è che qui si parla di affidare ad estranei dati di notevole valore per l’azienda, riguardanti i dipendenti, i partner, i clienti. I produttori devono offrire garanzie, i consumatori devono superare la diffidenza. E’ pur vero che alcuni servizi di business, ancora non etichettati come SaaS, che “veicolano” dati di valore, sono già di largo uso (mi riferisco, ad esempio, ai servizi di pagamento con carta di credito largamente sfruttati dai siti di e-commerce).

Il secondo problema riguarda la ragguardevole infrastruttura in cui i produttori dovrebbero investire per essere in grado di fornire un servizio che ad oggi consegnano su supporto ottico. E’ vero, si potrebbero stringere alleanze con società specializzate in hosting: i rischi per i clienti aumenterebbero, si perderebbero alcuni benefici del paradigma e si dovrebbe garantire per terzi (oltre che per se stessi).

Il terzo riguarda la perdita, da parte dei consumatori, del controllo di parte dell’architettura. Questo, se la documentazione è carente, se non è prevista una modalità “sand-box”, se l’assistenza non è efficiente, se non c’è un sistema valido di logging, ecc. crea non pochi problemi. Oltretutto il produttore potrebbe non essere in grado di procedere con particolari personalizzazioni (non desiderare, non considerare conveniente, …).

Infine c’è da considerare il problema della latenza dovuta alla rete. I servizi sono remoti, tra il consumatore ed il produttore c’è ciò che sulle raffigurazioni è solitamente rappresentato come una nuvola e questo comporta complessità maggiori rispetto all’uso di servizi posti all’interno della rete aziendale.

Al fine di superare i problemi appena descritti, SaaS si concretizza sempre più spesso in macchine virtuali (immagini software) o reali (appliance hardware) preconfezionate, installabili presso il cliente con poche operazioni ed eventualmente configurabili anche da remoto.

Un’altra forma di SaaS è l’offerta, sul web, di applicazioni complete (CRM, HR, …) a beneficio, sopratutto, di PMI o di quelle imprese caratterizzate da un alto numero di filiali e da un’insufficiente presenza di personale IT. Solitamente su queste applicazioni i produttori tendono ad ideare framework per permettere ai consumatori di sviluppare servizi di business o processi da utilizzare nelle loro composizioni interne (un esempio), ponendo le basi per una SOA oltre i firewall.

—-><—-

Post di altri autori sullo stesso argomento:

• Service-oriented Architecture – SaaS opens Up SOA beyond the firewall
• SaaS Blogs – Enterprise SaaS != Web 2.0: A quick hosting perspective
• Dana Gardner’s BriefingsDirect – SOA and SaaS convergence points to new market demand for ‘integration-as-a-service’
• Software-as-service – Can the appliance put SaaS on-premise
• CRM Systems – Gartner: SaaS Market To Hit $19.3 Billion by 2011

—-><—-

Hai trovato questo post interessante? Sottoscrivi il feed completo e partecipa alla discussione