L'evoluzione del WWW sta portando rapidamente lo sviluppo e il deployment delle applicazioni a cambiare: si va sempre di piu' verso una condizione di Software As A Service (SAAS). L'idea e' quella di non installare piu' presso il cliente lo stack software, di qualunque natura sia, ma di permettere al cliente di accedere remotamente ad una installazione software disponibile (in esclusiva) presso il fornitore. Per rendere piu' chiaro il concetto, la differenza e' fra installare un server di posta aziendale internamente all'azienda oppure registrare l'azienda presso un fornitore esterno di servizi di posta elettronica. E la stessa cosa puo' essere fatta per software gestionali, documentali, di backup, fino alla virtualizzazione di storage e server interi.
Eppure questa variazione, sicuramente vantaggiosa in molti casi, produce qualche piccola contro-indicazione sui fornitori.
Anzitutto il cliente si aspetta che il "servizio" (non il software) sia sempre disponibile, sempre on-line, sempre aggiornato, sempre presidiato. Non si e' piu' disposti ad attendere downtime o periodi di inattivita' per consentire gli upgrade di versione. Non avendo lo stack software in casa, il cliente non sente suo il software, e di conseguenza non percepisce il problema relativo agli aggiornamenti. Ad accentuare cio' il fatto che il fornitore non e' piu' fornitore di prodotti e servizi, ma solo di servizi. Se si vende un prodotto (es. automobile) ad un cliente, questo comprende l'importanza e la necessita' della manutenzione sul prodotto stesso. Ma se al cliente si vende un servizio (es. trasporto in autobus), questo non accettera' mai di avere dei blocchi a causa di mancata manutenzione da parte del fornitore. Seppur semplici, queste considerazioni spostano il carico di lavoro e la necessita' di investimenti per le infrastrutture sulle spalle del fornitore stesso.
Ma c'e' anche un'altra problematica, questa volta da parte degli sviluppatori. Il fatto di avere lo stack software in casa, disponibile, "vicino" e soprattutto il fatto di non avere piu' il veto del cliente, consente agli sviluppatori di fare deployment continui. Se da un lato questo rappresenta una occasione di aggiornamento continuo, dall'altro spinge gli sviluppatori a programmare con meno cura, poiche' sanno che potranno sempre correggere velocemente il problema. Inoltre le modifiche allo stack saranno spesso visibili a tutti i clienti, e spesso non saranno nemmeno necessarie al cliente stesso, che pero' si vedra' addebitati i canoni di manutenzione e aggiornamento.
Con tutto questo non voglio dire che il modello SAAS sia sbagliato, ma invito a riflettere chiunque intenda intraprendere questa strada a testa bassa.
Eppure questa variazione, sicuramente vantaggiosa in molti casi, produce qualche piccola contro-indicazione sui fornitori.
Anzitutto il cliente si aspetta che il "servizio" (non il software) sia sempre disponibile, sempre on-line, sempre aggiornato, sempre presidiato. Non si e' piu' disposti ad attendere downtime o periodi di inattivita' per consentire gli upgrade di versione. Non avendo lo stack software in casa, il cliente non sente suo il software, e di conseguenza non percepisce il problema relativo agli aggiornamenti. Ad accentuare cio' il fatto che il fornitore non e' piu' fornitore di prodotti e servizi, ma solo di servizi. Se si vende un prodotto (es. automobile) ad un cliente, questo comprende l'importanza e la necessita' della manutenzione sul prodotto stesso. Ma se al cliente si vende un servizio (es. trasporto in autobus), questo non accettera' mai di avere dei blocchi a causa di mancata manutenzione da parte del fornitore. Seppur semplici, queste considerazioni spostano il carico di lavoro e la necessita' di investimenti per le infrastrutture sulle spalle del fornitore stesso.
Ma c'e' anche un'altra problematica, questa volta da parte degli sviluppatori. Il fatto di avere lo stack software in casa, disponibile, "vicino" e soprattutto il fatto di non avere piu' il veto del cliente, consente agli sviluppatori di fare deployment continui. Se da un lato questo rappresenta una occasione di aggiornamento continuo, dall'altro spinge gli sviluppatori a programmare con meno cura, poiche' sanno che potranno sempre correggere velocemente il problema. Inoltre le modifiche allo stack saranno spesso visibili a tutti i clienti, e spesso non saranno nemmeno necessarie al cliente stesso, che pero' si vedra' addebitati i canoni di manutenzione e aggiornamento.
Con tutto questo non voglio dire che il modello SAAS sia sbagliato, ma invito a riflettere chiunque intenda intraprendere questa strada a testa bassa.
Nessun commento:
Posta un commento