Manifesto

agileIoT logo

L'AgileIoT Manifesto è la sintesi del lavoro di analisi fatto fin ora nei domini afferenti l’Internet of Things, andando ad evidenziare gli aspetti fondamentali inerenti la governance, i rischi e la sostenibilità dell’iniziativa.

 

FILOSOFIA

La filosofia di AgileIoT è quella della bottega rinascimentale, ovvero la cellula in cui veniva fatto tutto quanto necessario alla realizzazione di una nuova opera: dalla progettazione alla commercializzazione, passando per la formazione e la produzione.

I membri del team sono spinti a comportarsi come gli artigiani rinascimentali che con estrema abilità utilizzavano materiali, tecniche e strumenti diversi per soddisfare il cliente che aveva commissionato l’opera.

AgileIoT mette al centro il bisogno del cliente, armonizzando competenze, approcci e tecnologie differenti, grazie alla definizione di un main-set comune di strumenti che rendono economicamente sostenibile la creazione di una soluzione Internet of Things.

 

PRINCIPI

Non si tratta di software, hardware o servizi: è l’insieme che va realizzato bene!

Non si tratta di completare un progetto software o hardware, bensì di realizzare una soluzione intelligente che sfrutta entrambi per risolvere un’esigenza in modo efficiente ed efficace.

 

Pensare meno e agire prima!

Ridurre all’essenziale il tempo dedicato alla fase di analisi in favore di un rapido avvio delle attività di sviluppo della soluzione.

 

Semplice è meglio!

Più semplice è la soluzione che si realizza, maggiori saranno le possibilità di farla evolvere in funzione delle esigenze degli stakeholder.

 

Se non puoi ricordarlo, non puoi migliorarlo!

Utilizzare strumenti di visual management per monitorare lo stato di sviluppo della soluzione.

 

PRATICHE

Fast Prototyping

Il Fast Prototyping ha lo scopo di validare la sostenibilità generale della soluzione. La sostenibilità passa attraverso 8 bobble- aspects, rappresentanti i principali aspetti annessi ad una soluzione IoT: Energy, Hardware, Code, Data Flow, Cloud, Security, Delivery e Legal:

  • Energy: incentrato sulla verifica delle ipotesi relative agli aspetti energetici in funzione delle esigenze di continuità operativa degli smart device;
  • Hardware: incentrato sulla validazione delle ipotesi hardware tramite uno o più Evaluation Kit (EVK). La selezione dell’EVK più idoneo passa, in primis, dalla scelta della CPU/MCU, dopodiché si inizia a “costruire” il prototipo lavorando sugli altri componenti (es: RAM, USB, ecc.);
  • Code: incentrato sulla prototipazione del firmware dei dispositivi e su quella dei servizi a supporto per l’acquisizione dei dati/eventi portanti della soluzione. In questa fase l’utilizzo di framework e di IDE di codifica veloce è fondamentale per abbattere i tempi relativi;
  • Data Flow: incentrato sugli aspetti legati alla raccolta, alla pulitura ed alla gestione dei Raw Data provenienti dai device, implementando gli aspetti di trasmissione e serializzazione degli stessi, con la scelta degli opportuni protocolli e dei formati più adeguati. In particolare, è fondamentale dedicare particolare attenzione alla stima dei volumi dei dati ed alle relative metodologie di analisi, in modo da approcciare alla gestione delle informazioni in chiave Polyglot Persistence, fondamentale per garantire la possibilità di elaborare velocemente grandi moli di informazioni;
  • Cloud: incentrato sugli aspetti Cloud della soluzione, intesa come piattaforma di gestione dei dati, degli eventi e delle action portanti;
  • Security: incentrato sulla verifica delle ipotesi relative agli aspetti di security che caratterizzano l’intera soluzione e che ne influenzano in modo diretto lo sviluppo. L’azione trova le proprie fondamenta nel Threat Modeling, che punta a rendere la sicurezza parte integrante della soluzione e del processo di sviluppo;
  • Legal: incentrato sull’analisi delle normative, nazionali ed internazionali, a cui la Soluzione deve essere conforme per la sua commercializzazione, per funzionare rispettando gli standard previsti dalle discipline di settore e per trattare in modo lecito i dati raccolti. Si tratta di profili che condizionano notevolmente sia la scelta degli elementi hardware e software da utilizzare, ma anche il modello di business previsto, che devono essere quindi adeguati agli standard tecnologici in vigore e alle differenti normative che regolamentano il servizio offerto dalla Soluzione;
  • Delivery: incentrato sull’analisi delle modalità di dispiegamento dei vari elementi della soluzione, da quelli fisici afferenti l’hardware a quelli relativi ai servizi. Si tratta, in pratica, di avere prontezza delle possibili difficoltà annesse al deployment e verificare che non vadano a minare la sostenibilità della soluzione.

Tutte le bobble-aspects concorrono esplicitamente alla valutazione dei costi/benefici della soluzione che si intende realizzare.

 

Make-Measure-Learn

Il ciclo Make-Measure-Learn (MML) consente di sperimentare rapidamente le diverse ipotesi e le diverse assunzioni:

  • Make: creo un prototipo per testare le ipotesi annesse alla Vision e per iniziare a consolidare il team di riferimento;
  • Measure: analizzo il prototipo in funzione dei Goal e delle relative metriche. Inoltre verifico se l’organizzazione aziendale ed il team sono a proprio agio per la realizzazione della soluzione;
  • Learn: attuo le opportune modifiche in funzione dei risultati.

 

Flashback

Il flashback porta il team a confrontarsi sull’avanzamento dello sviluppo, creando un’azione di allineamento rapido specifica per il mondo dell’IoT in cui è l’osservatore ad andare direttamente al desk su viene presentato l’attuale manufatto in lavorazione e ponendo un numero limitato di domande temporalmente vincolate.

Dal flashback può emergere la necessità di approfondire alcuni aspetti, cosa che porta ad una Technical Review Blitz in cui dirimere ogni dubbio.

 

Continuous Improvement

La Continuous Improvement suggerisce di ridurre al minimo gli interventi sugli aspetti hardware della soluzione, azione estremamente costosa e lunga. L’approccio è quello di intervenire sul firmware, sui servizi e sul cloud in modo da poter costantemente migliorare la soluzione complessiva e intervenire con workaround in caso di problemi dei dispositivi fisici.

 

Continuous Integration

La Continuous Integration spinge a integrare costantemente ed il prima possibile tutte le differenti anime della soluzione, in modo da rilevare quanto prima i difetti ed i problemi esistenti ed intervenire rapidamente per risolverli. Si tratta di un’azione fondamentale per ridurre i costi associati a mal funzionamenti o riposte inattese dal sistema.

 


Tutti gli elementi descritti nella guida sono frutto dell’esperienza sul campo e di molte discussioni con esperti, arrivando ad estrarre l’essenza della complessità che una nuova iniziativa IoT porta con sé, sia da un punto di vista tecnico che da un punto di vista organizzativo.

La guida è un “pretotype”, a rappresentare una costante e continua evoluzione in funzione della sua sperimentazione sul campo e delle nuove applicazioni dell’IoT. In tal senso l’invito è quello di utilizzarla come riferimento da contestualizzare nella propria realtà in funzione della propria Cultura aziendale.