In questa seconda parte della discussione sulle possibili strategie bancarie adottabili in ambito mobile, vogliamo approfondire un po’ alcuni aspetti organizzativi e implementativi, mettendo in evidenza le possibili implicazioni business nella scelta dello sviluppo nativo piuttosto che di quello ibrido, soluzione supportata dall’utilizzo di frame work come PhoneGap.
Introduzione: approccio nativo vs ibrido
Nell’articolo precedente ci siamo già soffermati su quali sono i pro e i contro dell’approccio nativo rispetto a quello ibrido, cioè supportato da un frame work. Alla luce di questi aspetti, vogliamo adesso valutare quali sono gli impatti aziendali che ci possono essere nel seguire uno dei due approcci alla programmazione di app per un particolare dispositivo, cioè o nativo o ibrido.
Si cercherà di rispondere alle domande relative alle modalità di sviluppo, di rilascio e di installazione previste nei due casi, a come variano i costi di implementazione, la complessità di sviluppo, la gestione del ciclo di vita delle applicazioni e la loro usabilità.
Figura 1 – Direzioni possibili: approccio nativo vs approccio ibrido.
Il confronto tra l’approccio nativo vs quello ibrido verrà fatto sui seguenti fattori:
- Know how / formazione
- Modalità e tempi di sviluppo, rilascio e distribuzione
- Manutenzione e costi
- Ciclo di vita delle applicazioni
Confronteremo adesso la scelta dei due approcci sui quattro fattori sopra citati, di modo da capire quali possono essere gli impatti business nel seguire una strada piuttosto che un’altra.
Know how / formazione
Con l’approccio nativo quello che principalmente si richiede è la competenza nei linguaggi nativi delle piattaforme attualmente presenti sul mercato.
Figura 2 – Linguaggi nativi per le piattaforme mobile attualmente più diffuse.
Ovviamente, se si decide di uscire solo su una, o alcune piattaforme, tipo iPhone, Android e BlackBerry, il set di questi linguaggi nativi si riduce.
Competenze di questo tipo possono essere richieste internamente all’azienda che intende farsi carico dello sviluppo e dunque, se il personale a disposizione non è a conoscenza di questi linguaggi, occorre prevedere dei periodi di formazione. Questo implicherebbe da una parte l’allungamento dei tempi di uscita sul mercato; ma, se gli obiettivi non sono la velocità di uscita, ma avere competenze interne allora è utile seguire questo approccio. Se l’obiettivo è quello di andare sul mercato il prima possibile, allora l’azienda interessata può sfruttare la possibilità di andare in outsourcing con delle aziende specializzate nel settore dello sviluppo mobile.
Se si adotta invece l’approccio ibrido, il numero di competenze richieste è notevolmente più basso dal momento che, grazie all’utilizzo di framework come PhoneGap [1], lo sviluppo di un’applicazione mobile si basa sull’utilizzo di HTML5, CSS e JavaScript. Tali competenze sono più facilmente rintracciabili all’interno delle proprie risorse, consentendo dunque un riuso dello skill interno e abbassando i costi che potrebbero essere quelli di andare in outsourcing.
Modalità e tempi di sviluppo, rilascio e distribuzione
Le modalità di sviluppo nativo devono prevedere una organizzazione non indifferente, tenendo in considerazione il numero di piattaforme sulle quali si vuole sviluppare. Teniamo presente che, oltre alla differenza tra un sistema operativo mobile e un altro, spesso, anche all’interno di una stessa piattaforma, occorre fare i conti con le differenze tra device, specie oggi che, accanto agli smartphone, si stanno diffondendo anche i tablet. Occorrono dunque gruppi di sviluppatori più o meno dedicati allo sviluppo di una determinata piattaforma, con relativo ambiente di sviluppo e test, dal momento che verrà creata un’applicazione per ciascuna piattaforma.
I tempi di sviluppo sono abbastanza elevati considerato il fatto che la stessa applicazione deve essere replicata per ciascuna piattaforma e anche se il processo può essere eseguito in parallelo grazie a più gruppi di sviluppo (ma questa è solo una ipotesi), a livello di effort risulta sicuramente più costosa di una soluzione che prevede lo sviluppo one-time dell’applicazione per più piattaforme.
Le modalità di rilascio prevedono che le applicazioni siano rese disponibili sugli store di riferimento dai quali è possibile effettuarne la ricerca e il download.
L’approccio ibrido sotto questo punto di vista ha dei vantaggi notevoli: i costi di sviluppo si riducono, dal momento che basterà allocare un solo team per lo sviluppo dell’applicazione che in questo caso sarà l’unica destinata alle varie piattaforme. Il processo di sviluppo però prevede che ci sia un ambiente dedicato ad ogni tipo di piattaforma sulla quale si intende distribuire, per i vincoli di compilazione e impacchettamento previsti dagli attuali framework per la soluzione ibrida.
Questa operazione non impatta fortemente sui tempi di realizzazione perche’ una volta preparati gli ambienti con le rispettive macchine, IDE di sviluppo ed emulatori, occorre seguire il processo di build e distribuzione dell’applicazione già sviluppata.
Il processo di distribuzione consiste anche qui nella distribuzione presso gli store di riferimento, e il vantaggio nell’utilizzo dei frame work come PhoneGap sta nel fatto che tale operazione di distribuzione può essere fatta senza avere sul proprio PC il software nativo dell’OS della piattaforma target. L’unico vincolo è quello di avere un ambiente con IDE apposito.
Manutenzione e costi
Se si è scelto di seguire l’approccio nativo, il risultato è stato quello di avere n applicazioni, una per ciascuna piattaforma: di conseguenza i costi di manutenzione si moltiplicheranno per n volte! Ogni volta che sarà necessario modificare o aggiornare l’applicazione, il processo andrà ripetuto (seppure in misura minore rispetto allo sviluppo da zero) per n volte.
Secondo l’approccio ibrido invece, il risultato è quello di avere un’unica applicazione che poi viene impacchettata opportunamente per le diverse piattaforme. In questo senso, i costi di manutenzione sono circoscritti alla stessa.
Ciclo di vita delle applicazioni
Proviamo adesso a fare il sunto della situazione, indicando gli step business e logistici che conducono ad un’applicazione mobile. Un interessante articolo [2] mette in luce le fasi che occorre seguire e che portano alla realizzazione di un’applicazione mobile.
Al di là che si scelga un approccio nativo o ibrido, come illustra la figura 3, è fondamentale individiduare la o le piattaforme per le quali si intende distribuire.
Figura 3 – Ciclo di vita di un’app mobile: selezione delle piattaforme.
La scelta non si basa esclusivamente sugli aspetti tecnici che coprono circa il 44% di margine, ma si basa soprattutto sulla percentuale di penetrazione sul mercato che la piattaforma scelta ha al momento e sul suo potenziale reddito. In questo caso, gli aspetti tecnologici sottostanno a quelli più propriamente di business.
Una volta individuata la piattaforma target, lo step successivo è quello dello sviluppo della/e applicazione/i: se l’approccio è quello nativo occorre fare i conti con le curve di apprendimento dei linguaggi nativi.
Figura 4 – Ciclo di vita di un’app mobile: sviluppo delle applicazioni.
Come illustra la figura 4, supponendo di avere un gruppo di sviluppo non competente, i tempi di apprendimento sono dell’ordine dei mesi e il linguaggio nativo più “veloce” da imparare è quello del sistema Android, per il quale sono previsti 5 mesi per essere del tutto indipendenti. I tempi si allungano per l’apprendimento delle altre piattaforme, con iPhone che tiene il secondo posto nella classifica delle difficoltà, per arrivare a Symbian che risulta il più difficoltoso e per il quale sono previsti anche 15 mesi per il completo apprendimento.
Android, Java ME e Apple hanno dei punti di forza per quanto riguarda la velocità con la quale si riesce a codificare per queste piattaforme. Presentano anche dei vantaggi nel supporto agli sviluppatori in quanto mettono a disposizione dei tool a basso costo.
Dal punto di vista degli IDE messi a disposizione, le piattaforme un po’ più “dolenti” risultano essere invece Windows Mobile (in particolare), BlackBerry e la Symbian. Anche dal punto di vista della lentezza degli emulatori, con queste piattaforme non siamo al massimo (e forse anche questo spiega almeno in piccola parte il successo attuale di Android e iPhone).
Lo step successivo è quello della distribuzione dell’applicazione prodotta:
Figura 5 – Ciclo di vita di un’app mobile: distribuzione sul mercato, verso l’utente finale.
I principali canali dedicati all’uscita sul mercato di un’applicazione sono fondamentalmente tre: gli store/market di riferimento, il download diretto dai siti web e le applicazioni commissionate.
Come illustra la figura 5, il canale principale di distribuzione, indipendentemente dalle piattaforme, risulta essere lo store di riferimento, che consente di avere un impatto sul time-to-market non indifferente; è possibile avere una riduzione del time-to-market dai 68 giorni che si hanno coi canali tradizionali contro i 22 che si hanno con gli store.
Conclusioni
In questo articolo si sono messi in luce gli impatti che si possono avere su quattro fattori indicati (“know how e formazione”, “modalità e tempi di sviluppo, rilascio e distribuzione”, “manutenzione e costi”, “ciclo di vita delle applicazioni”) a seconda della adozione di un approccio di svilupp nativo rispetto a quello ibrido.
Tenuti in considerazione questi step di processo, si può notare come il secondo, che è quello relativo allo sviluppo, possa avere degli impatti su tempi e costi a seconda che si tratti di un approccio nativo o ibrido. Scegliendo l’approccio ibrido si potrebbero evitare i costi relativi alla curva di apprendimento, che è possibile evitare con l’approccio nativo solo se si sceglie di andare in outsourcing presso un’azienda specializzata (con tutto quello che ciò comporta in termini di altri costi).
Come già più volte ribadito, la scelta dell’uno o dell’altro approccio dipende da fattori business e da scelte più o meno strategiche. Alla luce di queste considerazioni, non è possibile stabilire se un approccio sia giusto o un altro sia sbagliato, ma si può affermare solamente che può essere più o meno conservativo dell’altro.
Scegliere l’approccio nativo consente di “difendersi” da possibili problematiche nell’impacchettamento finale e permette di gestire in maniera più diretta i diversi sviluppi. La scelta dell’approccio ibrido, soprattutto in ambito bancario, dà la possibilità di andare sul mercato velocemente: ma occorre avere un totale controllo (e anche una certa fiducia) riguardo ai frame work attualmente a supporto di tale tipo di sviluppo.
Riferimenti
[1] Alberto Renzi – Mirco Casoni – Vittoria Caranna, “Applicazioni mobili negli scenari Enterprise. II parte: PhoneGap un framework per applicazioni ibride”, MokaByte 149, marzo 2010
https://www.mokabyte.it/cms/article.run?articleId=O5R-R6L-HN8-8R8_7f000001_18359738_2ff5bd55
[2] The Life Cycle of Mobile Application Development
http://www.onlinemarketing-trends.com/2011/01/life-cycle-of-mobile-application.html
[3] Divining the Future of Mobile Development