Just enough, Just in time.

Con queste poche parole si può riassumere il cloud per quanto riguarda l’erogazione e la fruizione dei servizi. E’ da portare a coscienza che per ogni caratteristica del proprio servizio bisognerebbe saper identificare il come risponde al paradigma del Just enough e Just in time.

L’elasticità nel cloud dimostra come le risorse debbano essere rese disponibili su richiesta e ri-allocabili in poco tempo. Così anche i modelli di business legati alle soluzioni sono riferiti alla capacità di poter comprare il servizio che voglio rispetto al tempo che ne ho bisogno. Un servizio di posta elettronica, un programma di contabilità, delle macchine virtuali se erogati sul cloud dovrebbero poter essere acquisiti con un modello Just Enough (quanto basta), Just in Time (quando serve).

Quando progettiamo una architettura, oppure pensiamo di erogare un servizio As A Service come controlmycloud.com ci poniamo il dilemma di come poassa il servizio o la componente architetturale essere erogato o usufruito secondo i principi del Just Enough e nel modo Just In Time.

Quindi una architettura o una applicazione cloud, secondo il nostro approccio, deve essere regolata al minimo da questi due principi elementari.

Più in dettaglio, dal punto di vista business tale approccio prevede che il pricing e la modalità di usufruizione del servizio permetta a un utente di aderire a bisogno. La richiesta è quella di consumare a richiesta, è quindi necessario pensare di lavorare su diversi aspetti in quanto il servizio è erogato just enough e just in time e nessuno vuole più pagare licenze anticipatamente o dimensionare una infrastruttura per un limitato uso. Si pensi per esempio alla multi-tenancy, alla necessità di avere un CRM, un sistema di supporto, una piattaforma di charging, una piattaforma di billing. Queste sono solo delle caratteristiche che un servizio per essere erogato secondo il modello As A Service deve considerare.

Dal punto di vista tecnico invece, progettare applicazioni che possano essere utilizzate o allocate Just In Time richiede uno sforzo progettuale diverso dal modello standard. Innanzitutto è necessario pensare al modello di provisioning dell’applicazione stessa e del singolo servizio applicativo. Se deve essere allocata e instanziata al bisogno, è necessario dover implementare sin dal principio tutta la logica di provisioning e di configurazione della applicazione eseguibile da una macchina.

Diversi frameworks come Chef e Puppets stanno confermando oltre a un problema di razionalizzare le operations, l’esigenza di poter portare all’interno del software lifecycle anche la capacità di fare provisioning e deprovisioning di un servizio o di una applicazione. Un tempo questo approccio era un approccio che solo le grandi aziende si ponevano; oggi è diventata una esigenza comune, c’è bisogno di avere le configurazioni staccate dallo sviluppo e gli ambienti di esercizio visti come piattaforme abilitanti. Lavorare in questi termini vuole dire pensare a servizi che siano per lo più coesi e che non abbiano dipendenze “forti” con altri servizi. E’ necessario che le dipendenze siano scovate piuttosto che configurate. Ci sono forti segnali di una evoluzione in questo verso;  si può osservarlo anche da come stanno evolvendo i browser, in cui lo User Agents e più in generale l’applicazione cliente è in grado di adattarsi alle intenzioni che arrivano dai server. Le sfumature si possono cogliere attorno a tutto il fermento che sta spingendo il cloud.

E i metodi e le tecniche di sviluppo?
Di pari passo progettare servizi che sottostanno al principio del Just In Time e del Just Enough, richiede anche di lavorare con un processo che permetta di iniziare il rilascio di piccole componenti o servizi a valore per il business e che riescano ad essere implementati ed erogati nel più breve tempo possibile. In cicli di settimane è necessario passare da una idea di business a una erogazione di servizio secondo tutti i canoni di una architettura solida e pronta per essere messa sul cloud con il modello As A Service. L’Agile Software development è la testimonianza, è un abilitatore che risponde a questa esigenza di mercato che soddisfa i principi discussi fino ad ora.

L’Agile Software development è stata una grande anticipazione e secondo me, una esigenza, di chi ha voluto innestare un modello di delivery di servizi come concepiti dal paradigma della SOA: servizi a valore per il business, altamente coesi che dovevano essere implementati in poche settimane di lavoro.

Tutto ciò che risponde al principio del Just In… riporta in qualche modo a ciò che è rimarcabile come Cloud e tutto ciò che è marcato come Cloud dovrebbe saper rispondere a come si approccia con il Just in…

Il docente è Joseph Pelrine ed il corso sarà in lingua inglese.

Per informazioni e iscrizioni contattate lucia.longoni {at} mondora(.)com

Differenti Cloud Service Provider stanno valutando l’integrazione di Cloud Stack all’interno della loro infrastruttura. Tutto è più lineare, molto orientato al management nello stile Plesk e che permette di integrarsi a piattaforme di virtualizzazione diverse.

Il differenziale interessante tra le diverse feature di CloudStack c’è la compatibilità con le API di Amazon. E’ possibile riusare completamente lo skill e le applicazioni che lavorano con Amazon direttamente su CloudStack e andare quindi ad amministrare un set di piattaforme completamente da una api comune.

Questa opzione da manforte allo spirito di Amazon e consolida il fatto che un utente può tranquillamente iniziare a sviluppare le proprie applicazioni per amazon e poi migrarle con un effort basso di integrazione a CloudStack e quindi a una varietà di piattaforme.

L’approccio di CloudStack è assolutamente pragmatico e convalida il fatto che una buona esposizione di una API il più possibile aperta rende la soluzione vincente. Quindi ancora una volta un maggior valore al modo con il quale si espongono i servizi oltre che a che alla funzionalità stessa. Poi nella core logic l’integrazione di diversi service providers gioca il suo ruolo.

Ma quale è il futuro di uno stack senza client intelligenti e leggeri?

Lo strato di interfaccia è rimarcato essere il nodo centrale dell’integrazione e il cloud ne è proprio la conferma.

Sul cloud si sta già pensando anche ai client, ma nessuno sta mettendo in relazione l’alto proliferare di api restful con dei client o delle tecniche di interazione emergenti. Il 27 aprile 2012 è stato pubblicato un draft sui Web Intents, dove si specifica una delle evoluzioni delle funzionalità dei browser.

Così come le API sono passate da un modello pesante a un modello light con la loro versione restful, anche la tecnica di loro invocazione sta emergendo con dei paradigmi leggeri passando da un meccanismo AJAX like a un processo più nativo nel browser.

Web Intent è una specifica nata proprio per permettere ai browser di eseguire una service discovery e andare a fare delle invocazione ai servizi esposti dal server in maniera semplice e lineare direttamente dal codice HTML.

La logica deriva anche dalle esperienze fatte nello sviluppo per Android, le applicazioni fanno service discovery che si manifestano negli intenti e poi eseguono delle funzionalità.

La logica degli intenti è un paradigma leggero per scoprire i servizi, invocarli e scambiare informazioni tra uno User Agent – che può essere anche una mobile device – e il corrispondente servizio server.

Questa nuova specifica, contemporaneamente al fenomeno del cloud visto – per ora – come una soluzione utile per i server e il computing, apre la possibilità di collegare, attraverso le intenzioni, servizi sul cloud. Il paradigma quindi sta evolvendo e dobbiamo lavorare focalizzati a rilasciare una serie di intentions per i diversi Stack sul cloud.

Il Cloud diventa così più disponibile, le applicazioni si manifestano in modo diverso e hanno la capacità di offrire funzionalità in relazione alla quantità di servizi che il cloud stesso sta rendendo disponibili. I client, in qualche modo si staccano dalle componenti server e attraverso un solo client si potranno scoprire servizi su cloud differenti.

Attraverso la service discovery, in certi contesti sono intenzionalmente esposte alcune funzionalità mentre altre saranno nascoste. Le applicazioni si manifestano quindi come una serie di intenzioni che un utente può intraprendere e le intenzioni si collegano ai diversi provider che implementano la stessa API.

Lo vediamo anche in Italia; la necessità di aderire a framework come CloudStack e OpenStack sta emergendo velocemente e nei prossimi giorni lavoreremo nell’ottica di introdurre le cloud intentions in integrazione con Cloud Stack e promuovere così il completamento client del modo con il quale si erogano e si usano i servizi sul cloud.

Questo permetterà l’emergere di mashup e servizi client che saranno polimorfici rispetto ai servizi ai quali si attaccheranno.

Le promesse di SOA riguardo al voler costruire una soluzione tecnologica in grado di dare la massima flessibilità delle architetture software è stata disattesa. Grande flessibilità significa dinamicità del sistema e oggi quello che troviamo essere implementato risulta essere estremamente statico e talvolta poco estensibili. Dall’altra parte grazie a questo paradigma le componenti software sono partizionate, catalogate e possono essere usate da diversi dipartimenti.

La Service Oriented Architecture quindi si manifesta come una opportunità per affinare le architetture piuttosto che, invece, un sistema per dettare regole tecnologiche.

Lo esprimono molto i movimenti che si sono affermati nel corso degli ultimi 4 anni in cui, chi era scettico 4 anni fa e che sosteneva che la SOA era una buzzword dell’Information Technology.
Come afferma Jason Bloomberg, ci son due livelli sui quali si può vedere la SOA. Un livello percettivo e uno reale. Sul piano percettivo la SOA è troppo complessa, la tecnologia non è utile a supportare le promesse e quindi il Cloud è la milestone che semplifica e razionalizza il tutto.
Da un punto di vista pratico, andando sul piano reale invece, ci sono un sacco di iniziative che oggi derivano dalla SOA, ma per diverse questioni anche di marketing non si possono chiamare più SOA. Si parla di orchestrazione di servizi, integrazione tra applicazioni, razionalizzazione di procedure per dire e riportare alcuni concetti della SOA.

Cosa sta introducendo il Cloud?

Il cloud sta sfruttando la mentalità della SOA in cui ogni componente, o meglio servizio, deve essere invocabile e amministrabile. E’ necessario quindi un protocollo leggero REST, al posto che SOAP ed è necessaria la definizione di una API con la quale i servizi vengano invocati utilizzando il più elementare JSON piuttosto che il complesso e prolisso XML. Ma senza la mentalità di architettare spinta dalla SOA, non si sarebbe arrivati a questo processo di snellimento e quindi non ci sarebbe stata l’occasione di parlare di Cloud Computing.

Pertanto la SOA è per di più da considerarsi come un mindset piuttosto che un set di tecnologie e le tecnologie che stanno ora affermando il Cloud come evoluzione e snellimento di tutta la complessità che la sovra-ingegnerizzazione ha portato durante gli anni d’oro dei Web Services e della SOA “tecnologica”.

Effettivamente la SOA non è nata con l’obiettivo di fare comunicazione Business to Business, come negli ultimi anni abbiamo voluto fare. Il paradigma è nato con lo scopo di razionalizzare i processi interni di una applicazione; il suo scopo era quello di voler lavorare su una grande organizzazione e catalogare i servizi che erano censiti senza doverli reinventare di volta in volta. Questo anche per controllare la qualità di questi servizi che erano rilasciati ai propri utenti e misurare quindi gli SLA del caso.

Il cloud quindi nasce dalla mentalità che si è conformata grazie alla Service Oriented Architecture piuttosto che nascere dalle sue ceneri. La SOA è e rimane un modello mentale con il quale i moderni architetti devono pensare. Senza la SOA non è possibile pensare a una applicazione che possa girare sul Cloud. E’ importante riflettere e analizzare come il cloud è separato e vedere che tutto è esposto come servizi e che i servizi sono richiamati tramite delle API.

Un codice di condotta per il cloud è quindi una esigenza che server per dar maggior fiducia a chi vuole usufruire dei servizi sul cloud. Questo è quello che è per primo successo in Nuova Zelanda dove diverse aziende che operano sul cloud e che hanno identificato dei principi fondanti per riconoscere una soluzione sul cloud si sono trovati e prima di parlare di interoperabilità o altro, hanno siglato un codice di condotta.

Cloud Code è il nome del codice di condotta siglato dai neozelandesi ed è il fondamento per iniziare a parlare di Cloud Computing con rigore e professionalità.

L’atteggiamento di Cloud Code, a differenza di approcci più tradizionali, è quello di essere proattivo e non prescrittivo con una serie di ricette. E’ per questo che sono stati identificati un set di principi in grado contenere qualsiasi pensiero che sia in sintonia con il cloud.

Questo modo di compartecipazione è esattamente il fondamento che regola il Cloud; prima dello spirito associativistico di aziende che si marchiano Cloud Oriented si è pensato a identificare dei principi.

Prima di tutto la più vasta eterogeneità sia nell’uso delle tecnologie che nell’uso dei metodi, poi la dispersione geografica nel massimo rispetto delle regole locali ed infine un modello di business assolutamente flessibile.

Come facciamo a regolamentare uno standard o altro sul cloud?

Con questi requisiti non possono identificare una ricetta che descrive che cosa è il cloud e che abbraccia tutte le possibili soluzioni, offerte e anche richieste sul cloud.
Solo basandosi su dei principi si possono regolare il business di ogni azienda e definire questo paradigma che da hype commerciale sta passando a divenire qualcosa di concreto e produrre quindi basi per il cloud condivise e utili.

I principi base che hanno ratificato i neozelandesi sono:

1. Non reinventare la ruota
   Dove è possibile, il codice spinge a far leva su lavori già esisteni e di dar priorità allo stabilire relazioni con lavori già fatti piuttosto che creare sempre da zero
2. Consistenza con pratiche globali e standards
   Il lavoro svolto e l’approccio al nuovo lavoro deve indirizzare tutte le giurisdizioni possibili in modo da risultare consistente a livello internazionale;
3. Una ricerca basata su un approccio non arbitrario
   Le raccomandazioni e il codice che risulta sono sviluppate con criteri oggettivi
4. Facilitazione nella redazione con ampia consultazione
   Il team e la NZCS agiscono solo come facilitatori nello sviluppo di un codice di condotta consultandosi con un ampio range di stakeholder
5. Preferenza di un risultato basato sul consenso
   Il codice risultante sarà un prodotto derivante dal consenso tra tutti gli stakeholders
6. Netta separazione tra la governance del processo e lo sviluppo del codice
   Il comitato direttivo assicura che i principi siano aderenti e verifica che l’approccio sia oggettivo. Il gruppo non guiderà o influenzerà il risultato del Codice.
7. Valutazione e conformità
   Gli unici costi che cloud code si vuole addossare sono quelli per mantenere l’integrità per il codice di condotta

I principali obiettivi di Cloud Code sono quelli di:

• Migliorare gli standards sul cloud computing;
• Stabilire un modello di comunicazione standard per la Cloud Industry
• Stabilire delle relazioni imparziali tra clienti e fornitori a riguardo di privacy, sicurezza, riservatezza e livelli di servizio.
• Rafforzare l’integrità del cloud computing nel caso neo zelandese in Nuova Zelanda

Anche in Italia e in Europa è necessario, prima di muoversi a qualsiasi livello associativistico, siglare un accordo come quello di Cloud Code.

In certi casi c’è ancora del sangue che intorbidisce il candore di quel ghiaccio a testimonianza della situazione inanimata del pesce.
Ma si deve far percepire tutto il lavoro che c’è dietro; un lavoro oltre che di pesca di conservazione e di trasporto che riesce a farlo arrivare in breve tempo al consumatore.

Non riuscire a venderlo, prima di essere un problema di mercato potrebbe essere un problema di approccio al proprio lavoro. In certi casi si sente la poca passione e il basso entusiasmo nel lavoro di compravendita.

A Seattle al Pike Place Fish Market, si utilizza una tecnica di presentazione del pesce, dove il cliente è coinvolto durante l’attività di compravendita.

La tecnica di vendita è molto incentrata sul cliente:

1. il cliente decide cosa vuole acquistare;
2. il venditore lo aiuta nella decisione, istituendo un piccolo teatrino e ponendo il problema a tutti i propri colleghi
3. il cliente conferma la scelta
4. il venditore inizia a preparare il pesce cercando di dare il massimo di se stesso e sfruttando le proprie capacità.

Ogni membro del gruppo cerca di dare il massimo di se stesso, cercando di divertirsi e cercando di rendere l’acquisto come un evento piacevole; riuscendo così a stare di fianco alle scelte del cliente e riuscendo a raggiungere gli obiettivi sia del cliente che del proprio mercato.

Come questo paradigma sia correlabile allo sviluppo del software credo sia un criterio soggettivo; al mercato del pesce di Seattle sono riusciti a mettere in discussione i propri valori o punti negativi per riuscire a giocarci sopra e costruire un movimento dove sfruttando questi valori si riesce nei propri obiettivi gratifica.

In particolar modo, gratifica la possibilità di risolvere le proprie debolezze facendo affidamento su un gruppo di persone che condividono gli stessi obiettivi e permette di conoscere al meglio le caratteristiche del proprio gruppo.

Lavorare in gruppo significa dover fare dei sacrifici per raggiungere dei risultati, essere consapevoli della noia che il lavoro quotidiano pone e sapere mettersi in discussione cercando di ironizzare anche su degli elementi critici sdrammatizzandoli per poi affrontarli con lo spirito di gruppo e quindi imparare.

Il saper mettere la spezia giusta al proprio cliente, ogni qualvolta ce ne sia bisogno e quindi a ogni colloquio rende le relazioni più complici e attutisce la mancanze che è naturale ci siano. Il processo è un processo di continua retrospezione in cui il divertimento è considerato uno degli elementi da dover essere considerati. Ognuno trova il proprio spazio nella squadra, la partita è chiara.

Dando forza alle proprie attitudini, e riuscendo ad avere il coraggio di saper scherzare su se stessi si riesce a costruire un mercato del pesce diverso.

Questo vale anche nello sviluppo del software e l’identità di una azienda si caratterizza proprio da quel modo di imparare che ogni singolo gruppo sa far emergere ed entra a fattor comune con tutti gli altri comparti aziendali.

Ma come fare a capire quale è l’insieme minimo delle funzionalità che danno il massimo risultato?

Il Product Backlog non è sufficiente per soddisfare una richiesta del genere da solo: è uno strumento con il quale poter fare dei ragionamenti e sul quale poter fare pianificazione, ma non è sufficiente a mantenere in linea il processo di innovazione continua con il delivery minimo di valore richiesto iterazione dopo iterazione in maniera coerente con la vision. Al Product Backlog manca il concetto di vision.

E’ necessario, quindi, focalizzarsi all’idea di prodotto prima che di backlog ed è importante andare ad indirizzare il proprio intuito in una visione di prodotto che:

1. descriva un obiettivo di prodotto attraverso una frase o una serie di frasi (al massimo 2 o 3)
2. definisca un gruppo di target per questo prodotto
3. definisca un set di funzionalità cruciali (5 o 6 funzionalità) che rendono il prodotto unico
4. descriva quali sono i bisogni che il prodotto soddisfa (5 o 6 bisogni)
5. definisca il valore in termini di benefici e di penalità e ne definisca i canali di vendita partendo da un business model

L’obiettivo di prodotto
L’obiettivo di prodotto è rappresentato da una frase o da una serie di frasi (2 o 3 al massimo) che riescano ad esprimere in maniera coincisa quello che si vuole andare a implementare. Rappresenta qualcosa di importante e difficilmente muta nel breve periodo. Assieme all’obbiettivo di prodotto è di grande valore associare anche una metafora. La metafora aiuta a pensare in maniera parallela anche a tutte le funzionalità che dovranno poi andare ad essere implementate.
L’obiettivo  di prodotto è fondamentale per continuare a mantenere il focus: è da intenderlo come la prima pietra fondante che da la direzione e verso la quale dover volgere lo sguardo nel momento in cui si stia prendendo un abbaglio. Deve essere chiaramente definito e la sintesi non deve essere troppo generica da far perdere l’obiettivo stesso.

Il gruppo di target
Descrivendo il gruppo di target per il prodotto, si va ad incrementare la vision definendo una serie di potenziali utenti che vanno poi a utilizzare l’applicazione. Non è del tutto scontato pensare che questi utenti emergono in una seconda fase. Emergeranno ed è opportuno iniziare già dal primo momento a perfezionare un set di utenti verso le quali indirizzare i propri sforzi. Anche dal punto di vista motivazionale, ognuna delle persone che collabora nella realizzazione del progetto saprà che il proprio lavoro è indirizzato, alla fine, a quel gruppo di target che è stato definito.

I bisogni
Il valore del prodotto è direttamente proporzionale rispetto ai bisogni che saprà andare ad indirizzare.  E’ pertanto importante che le funzionalità cruciali del prodotto vadano a soddisfare dei bisogni specifici del prodotto stesso. Anche qui riuscire ad identificare alcuni bisogni (al massimo 5 o 6) e riuscire ad individuare le funzionalità critiche del prodotto che soddisfano tali bisogni riuscirà a pesare meglio che cosa si andrà a realizzare.

Il valore
Il soddisfare i bisogni significa lavorare direttamente sul valore dato al gruppo di target e poi farlo combaciare con gli elementi che derivano dal modello di business dell’applicazione stessa. Da qui emerge che rispetto al modello di business ci sono delle funzionalità che penalizzano molto e funzionalità che danno grande beneficio sia al business che al cliente. Anche in questo caso è importante stabilire quali sono le funzionalità che danno grande beneficio e le funzionalità che danno grande penealità elencandole e descrivendole con poche frasi.

Una volta chiariti questi punti e identificate un elenco di funzionalità, un target di utenti e l’adattamento al business model, è possibile pensare di andare a stilare un Product Backlog. Il Product Backlog sarà quindi un insieme di user stories che saranno non altro che il Drill Down delle singole macro funzionalità descritte in termine di vision. In questo modo le user stories, saranno catalogate per la loro tassonomia naturale.  I punti espressi sopra sono un ottimo template da riempire per riuscire a preparare una visione di prodotto consistente e andare poi a fare drill down su ogni singola storia utente.

Anche per la priorità da attribuire alla singola user stories, si fa riferimento alla definizione della vision di prodotto e si riuscirà ad attribuire i Benefici e le Penalità associate. Applicando l’approccio di Wieger è necessario andare a pesare ogni singola User Story con un indice di complessità (Complexity, Story Point) e andare a stimare quali sono le funzionalità che costano di meno, danno minor beneficio e penalizzano meno.

Tutto è guidato dalla Vision di Prodotto, che è più statica del product backlog e che mantiene il Product Owner sui binari del prodotto. Di fatto un prodotto non è solo un insieme di funzionalità rilasciate iterazione dopo iterazione, un prodotto è anche un insieme di improvements che hanno una componente tecnica. E’ necessario, assieme al product backlog, mantenere il riferimento al Technical Debt o debito tecnico dove entrano difetti, technical enhancement e più in generale tutto quanto è rilevanza dal punto di vista tecnici.

La roadmap di prodotto sarà quindi il confluire del Product Backlog e del Backlog contenente il debito tecnico (che potranno e dovranno confluire a loro volta in un unico backlog). La complessità riferita alle storie utente e la velocità di implementazione delle singole storie che si impara iterazione dopo iterazione, permetteranno al Product Owner di lavorare a identificare una Product Roadmap.

La vision è necessaria per far si che ad ogni iterazione si riesca a continuare a rilasciare sempre un set minimo di funzionalità potenzialmente esercibili e si riesca anche a consolidare il prodotto dal punto di vista tecnico.

Nel frattempo la complicazione tecnologica si sta intromettendo alle richieste di business in cui tutto deve essere semplice; ma gli attori che giocano la partita sono tanti e difficili da far dialogare tra di loro. Questo fa crescere un livello di frustrazione negli stakeholder che non sono in grado di ricevere ciò che vogliono e che spesso fanno fatica ad esprimere e crea disagio per l’incapacità di consegnare nei team impegnati.

Principalmente si ambisce a passare all’agile software development per aumentare la velocità di produzione, aumentare la qualità del delivery, diminuire la difettosità o più in generale riuscire a rilasciare per tempo. L’approccio è quindi quello di adottare una ricetta, incrociare le dita e di cucinare secondo i modi spiegati. Chi vuole iniziare a fare software development secondo le pratiche agili deve in prima battuta rendersi conto che si sta parlando di una disciplina nello sviluppo del software piuttosto invece che un insieme di task da dover realizzare per riuscire nei propri obiettivi.

E’ un cambio culturale che si deve fare quando si è maturi e quando, quindi, si è pronti: non è una moda e non è neanche la soluzione di tutti i mali. Pertanto piuttosto che di parlare di tecnica è meglio di parlare di metodologia propedeutica anche allo sviluppo del software.

Poi ci sono anche alcune tecniche, ma di fatto è un metodo o più in generale un approccio culturale legato allo sviluppo del software. In certi casi, ho visto, vuol dire anche cambiare radicalmente la cultura aziendale; passare a un modello collaborativo elimina, in qualche modo, molte gerarchie interne. Si facilita la comunicazione a diversi livelli e si riesce a far si che il tutto vada avanti con una certa linearità.

Una linearità che è assicurata solo se esiste la condivisione di ciò che si sta facendo e tutti ne condividono gli obiettivi e ne sono anche consapevoli dei rischi. E’ necessario identificare una pratica di condivisione sia del progetto che del metodo di lavoro tra tutti; è necessario, anche, trovare una pratica con la quale riuscire a rimanere sempre focalizzati rispetto alla vision e gli obiettivi micro.

Quando partiamo ad implementare un prodotto, la nostra prima preoccupazione è quella di capire quali sono i business driver di questo prodotto, quali sono gli asset sui quali questo prodotto baserà tutta la sua esistenza. Da lì, poi, con una tecnica di drill down andiamo ad estrapolare tutte le storie utente che, se realizzate, completeranno il prodotto stesso.

Dalla nostra esperienza dell’applicazione dell’agile software development, ci accorgiamo costantemente che questo metodo si può rifare a 7 principi che ne riflettono le caratteristiche:

1. Soddisfazione del cliente;
2. Accettare i cambiamenti in un processo di inspection e adaption;
3. Rilasciare frequentemente del software funzionante;
4. Team che si auto-organizzano
5. Comunicare efficacemente;
6. Attenzione ai dettagli e semplicità
7. Mantenere un ambiente sostenibile di fiducia reciproca

L’ottenere dei risultati che sia di valore per tutti è l’elemento motivazionale predominante; pertanto riuscire a raggiungere gli obiettivi del cliente è l’obiettivo principe con il quale adottare i metodi agili. E’ naturale che durante lo sviluppo i requirement possano cambiare e che il cliente per essere soddisfatto necessiti di fare dei cambiamenti. I cambiamenti possono anche avvenire all’interno del team che con un processo di ispezione e di adattamento continua a governarsi. L’auto-governo è condizione necessaria per riuscire a rilasciare iterazione dopo iterazione il prodotto. Il prodotto deve essere frazionato e semplificato di modo che si possa implementare solo il minimo indispensabile di valore per l’utente. E’ per questo che è importante che ci si focalizzi su poche funzionalità e si esegua un processo di semplificazione tale da riuscire a curare tutti i minimi dettagli di quel poco che fa rendere l’applicazione al massimo. Il tutto ovviamente deve essere svolto in un clima sereno in cui la fiducia reciproca ma smetti mai di esistere.

Questi sono i principi che ho visto predominare in tutte le situazioni in cui Scrum e più in generale l’agile software development hanno avuto successo.

Si affrontano anche temi legati di più alla tecnologia, come il modello di erogazione di applicazioni in maniera elastica a prescindere dallo stack applicativo in cui si voglia operare. Ce ne è per tutti, anche se c’è la confusione che il cloud sia una mera opportunità di mercato per differenti vendor che vogliano riconfezionare i loro prodotti in un ambito nuovo.

Volendo però affrontare il tema del cloud in un modo più analitico ci si pone di fronte al fatto che c’è l’esigenza di innovare anche dal punto di vista della domanda, e che questa richiesta è difficilmente espressa. Le cause di incapacità sono svariate e, sicuramente, una di queste può essere la troppa giovinezza di questo fenomeno oppure  l’incapacità di intravedere i prossimi passi da fare per razionalizzare i processi aziendali o per aprire nuove linee di business. La fattorizzazione del proprio sistema informativo e la capacità di erogazione dei servizi in maniera multi-tenant hanno spinto grandi aziende – come Amazon – a offrire servizi a corollario del proprio business come servizi a valore aggiunto. In un modo analogo è nato Amazon AWS che ad oggi si attesta come uno dei maggiori casi di successo nel cloud legato all’infrastructure as a service. Amazon era una società nota per la grande capacità logistica; partita dai libri, poi passata agli elettrodomestici e infine in certe regioni anche al grocery.

Nessuno avrebbe mai predetto che Amazon diventasse uno dei maggiori produttori di hardware al mondo e neanche che facesse metà del proprio fatturato nella rivendita di servizi online su un modello assolutamente nuovo come il pay per use.

Anche dal punto di vista tecnico ci sono due fattori che spingono la necessità di avere una applicazione in grado di crescere e decrescere a seconda delle richieste:

1. La necessità di business di esporre componenti come servizi a valore aggiunto della propria azienda;
2. Il proliferare di handhelds come ipad, iphone, androids che spingono l’applicazione ad essere riusata da molteplici applicazioni remote.

Un offering simile porta a dover pensare la propria architettura di modo che sia il più possibile scalabile e flessibile.

La richiesta di voler esporre dei servizi a valore aggiunto della propria architettura come elementi rilasciati sul mercato secondo il modello As A Service e la propria App di utilizzo, necessità che i componenti siano altamente coesi e siano in grado di poter sottostare ad un modello elastico di scaling in grado di garantire l’isolazione delle richieste e dei dati attraverso la multi-tenancy. Per il tipo di applicazioni, questi fattori sono dei fattori nuovi che riguardano, oltre al business model, la progettazione e il refactoring di applicazioni che il cloud richiede per poter erogare i servizi. La sicurezza, la multi-tenancy e l’aderenza a degli SLA specifici sono dei fatti nuovi che guidano l’offerta di una piattaforma o di un servizio sul cloud. La domanda non è in grado ancora di chiedere in quanto l’offerta sta lentamende arrivando ad esporre servizi e quindi le rispettive apps che consumano i servizi con il modello As You Go.

Da una parte lo sforzo delle piccole aziende sta nel focalizzarsi su singoli servizi a valore aggiunto in grado di offrire il massimo beneficio ai clienti: si pensi a loggify o controlmycloud.

Dall’altra parte, le medio-grandi aziende invece si stanno focalizzando nell’estrapolare servizi core e ad offrirli secondo il modello As A Service.

Un po’ come ha fatto Amazon per l’infrastruttura. Avevano in casa l’hypervisor opensource XEN e hanno poi sviluppato sopra XEN una versione proprietaria in grado di erogare l’hypervisor stesso come un servizio invocabile tramite una API pubblica.

Di concerto il modello di business e l’implementazione delle piattaforme a corollario come il billing o l’infrastruttura di metering. Da qui hanno innovato l’offerta con un modello nuovo di mercato, aggiungendo del valore a un servizio che avevano già in casa e attribuendogli un significato pubblico. Ora la domanda ha compreso che cosa è il Public Cloud riguardo all’Infrastructure As A Service e Amazon sta facendo metà delle sue revenues proprio in questo mercato.

Siamo agli albori di una nuova rivoluzione industriale; ne stiamo seguendo i primi segnali e la fattorizzazione dei servizi permette di costruire un offering che agevola la costruizione di applicazioni molto più complesse e che rispondano a problemi di mercato nuovi.