Nel primo e nel secondo articolo di questa serie abbiamo stabilito che alla fine la mobilità sarà soltanto un'altra parte dell'architettura d'impresa. Allo stesso modo di quanto accade con i componenti per lo storage dei dati, per la sicurezza e per il networking, le applicazioni aziendali avranno diversi attributi mobili. E ci sarà un insieme comune di processi per il controllo e l'integrazione della mobilità.
Tuttavia, la sfida rimane quella di potersi spostare liberamente e questo richiede di fare quanto necessario per affrontare le doppie crisi generate dalla proliferazione delle più disparate architetture di mobility e dalla mancanza di precisi processi che la riguardano.
Il caos della mobility
Il Blackberry e gli smartphone si stanno diffondendo sempre più. Ma gli
It Manager devono porsi una serie di domande. Saranno queste architetture di
scala? Come le integreremo con i nostri ambienti di computing esistenti? Come
si potranno gestire tutti i modelli e i rispettivi ambienti operativi? Cosa
accadrà con l'iPhone? Cosa dire in merito al tempo che servirà affinché
un nuovo dispositivo "consumer" possa diventare un “must” per ogni
top manager?
In particolare due sono le aree che meritano particolare attenzione: l'architettura di sistema e le procedure di integrazione.
L'architettura di sistema
La semplicità di soluzioni come il Blackberry risiede nella sicurezza e nel
controllo che fornisce una piattaforma verticalmente integrata. Possiamo discutere
i gradi di integrazione, ma queste piattaforme sono state progettate per fornire
una mobilità standalone insieme con una piattaforma di email aziendale, come
Exchange, Notes o persino GroupWise. Da una prospettiva societaria, le piattaforme
di mobilità descritte in precedenza offrono una sufficiente sicurezza per un
vasto numero di deployment aziendali. Altre soluzioni di mobilità sono disponibili
e persino Microsoft propone un aggiornamento gratuito dell'email mobile a Exchange.
La maggior parte delle principali piattaforme di mobilità sono “middleware”. E il middleware mobile è necessario per gestire le caratteristiche critiche alle applicazioni mobili. Queste includono: la sincronizzazione, amministrazione dei dati, la maintenance dello stato dell'applicazione, i permessi degli utenti e la sicurezza. Tali piattaforme mobili spesso si basano sulle directory aziendali per ottenere i dati sugli utenti e generano informazioni locali supplementari sugli utenti e sulle directory. L'integrazione di queste ultime informazioni nuovamente all'interno delle directory centrali può essere davvero impegnativa.
Mentre le imprese migrano sempre più verso le architetture service oriented (SOA), le applicazioni e i Web service compositi, è poco chiaro il ruolo che l'attuale mobile middleware mobile gioca in queste strutture. La sfida architetturale sarà di migrare le caratteristiche mobili dalle piattaforme standalone di middleware mobile ai servizi mobili estesi a tutta l'impresa.
Uno degli ultimi aspetti architetturali inerenti il middleware mobile è quello della scalabilità. Malgrado il numero crescere di utenti che annoverano le piattaforme di mobilità, conosciamo poco sulla scalabilità di approcci come il Blackberry. Virtualmente, ogni tecnologia si trova di fronte a limiti di sviluppo e sappiamo che tali limiti esistono anche per il middleware mobile. Quello che non sappiamo è come tali vincoli si manifesteranno. La limitazione è nel software, nella rete, o nell'approccio bundle del software e dell'hardware?
Le procedure d'integrazione/adozione
L'attrattiva del Blackberry è che è facile da capire e da usare. Questo ha portato
a migliaia di deployment aziendali, milioni di abbonati e consistenti margini
sui dispositivi. Ci sono molti motivi alla base di tale successo, ma uno che
va evidenziato è il processo inerente la soluzione: ci sono poche variabili,
un numero limitato di dispositivi e moltissimo controllo. Desiderate l'email
mobile del Blackberry sul vostro account email aziendale? Allora dovrete passare
attraverso il dipartimento It.
In poche parole, soluzioni come Blackberry hanno messo il dipartimento It al centro del processo per il provisioning dei dispositivi, degli utenti e degli account. La procedura è collegata alla piattaforma ed alla soluzione, così al dipartimento It non sono necessari mesi (se non anni) per capire quale via seguire per l'acquisto del dispositivo, identificare l'utente, i servizi di provisioning e le policy da rispettare. Chiunque può comprare un Blackberry e usarlo per l'email mobile, ma occorre un altro step per coinvolgere il dipartimento It e per ottenere sul dispositivo l'account alla mail aziendale.
L'approccio Blackberry è semplice, limitato ed economico. E questo approccio è figlio di un'architettura che è stata progettata in un momento in cui i dispositivi mobili erano limitati in termini di potenza di computing, display, input del testo e durata della batteria. La generazione corrente degli smartphone può riprodurre musica, memorizzare file, trasmettere i messaggi di testo e l'email.
E siamo così giunti a un bivio. Le due possibili scelte sono: proseguire con le soluzioni che definiscono il processo per noi oppure accettare l'inevitabilità della mobilità e quindi cominciare a lavorare a un insieme di procedure molto più complesse per la definizione dei servizi che forniremo agli utenti e ai dispositivi mobili. In quest'ultimo metodo è implicito che la scelta di un dispositivo mobile è personale e che prevediamo spetterà all'utente.
Due mondi
C'è una crisi della mobilità? Dipende dai punti di vista. Molte organizzazioni
It sono sicure che potranno mantenere un controllo centralizzato sui dispositivi,
gli utenti e le applicazioni mobili. Per questi manager, le procedure sono semplici,
i dispositivi sono definiti e c'è un solo modo per fare le cose. In questo mondo,
non ci sono crisi.
D'altra parte, se gli utenti si accampano e fanno interminabili code nell'attesa di acquistare nuovi dispositivi come l'iPhone di Apple, è chiaro la mobilità genera moltissima aspettativa ed entusiasmo. A fronte di ciò, l'ampia diffusione di negozi di dispositivi mobili, compresi quelli destinate all'impresa, è diventata una conclusione scontata. E le aziende che accettano questa visione del mondo devono fronteggiare un certo numero di sfide nel definire le architetture e i processi per incorporare i dispositivi mobili di proprietà degli utente all'interno degli ambienti di computing dell'impresa.
