Chiamatelo come volete:
- Il nesso di forze ( Gartner)
- L'era del cliente (Forrester)
- La terza piattaforma (IDC)
Qualunque sia la vostra terminologia, è chiaro che siamo giunti alla fine di un ciclo tecnologico e siamo entrati in un nuovo ciclo di innovazione e trasformazione aziendale e informatica. Che si tratti di Social, Mobile, Analyticse Big Data, CloudComputing o Internet delle cose(SMACT), per non parlare del Bring Your Own Everything, questi sono tempi eccitanti e impegnativi per i leader IT delle aziende che cercano di trasformare le loro organizzazioni migliorando l'allineamento al business. I CIO sono diventati "agenti del cambiamento" .Sono diventati Chief Innovation Officer e persino Chief Integration Officer, in quanto uno dei primi punti in cui cercano di avviare questo cambiamento è il miglioramento delle connessioni tra i dati interni ed esterni, le applicazioni e le API, e l'eliminazione dei silos di dati disconnessi. Negli ultimi mesi abbiamo scritto molto sul dilemma dell'integratore, sulla "cloudificazione" delle aziende e sul conseguente spostamento della "gravità dei dati". Sempre più spesso, tuttavia, sento usare termini come "peso massimo ", "debito tecnico" e "onere informatico" per descrivere il middleware legacy acquistato e implementato ben oltre 10 anni fa. È stato costruito per un'epoca diversa e ora viene spesso visto come un blocco del cambiamento, non come un agente del cambiamento. D'altro canto, nelle conversazioni con gli analisti di settore, i clienti e i partner sento usare termini come "fabric", "agility layer" e "self-service" per descrivere il desiderio di un approccio più flessibile all'integrazione e alla gestione dei dati.
Vi suona familiare? 
Man mano che la piattaforma di integrazione come servizio(iPaaS) guadagna consapevolezza e accettazione sul mercato, diventa sempre più evidente che sta emergendo un nuovo "regno di mezzo" per affrontare i requisiti di integrazione dell'azienda moderna. Utilizzare il vecchio ETL o EAI per affrontare il volume, la varietà e la velocità dei requisiti di integrazione di dati, applicazioni e API di oggi (per non parlare dell'IoT) è un po' come guidare una Tesla Model S su una strada sterrata. (A parte i recenti risultati finanziari (esempi qui e qui), ho messo insieme un elenco di 10 motivi per cui i vecchi strumenti di estrazione, trasformazione e caricamento (ETL) e di integrazione delle applicazioni aziendali (EAI) (e i fornitori di soluzioni) continueranno a fare fatica nell'era SMACT:
- Cannibalizzazione del core business On-Premises: Questa è la più ovvia. Dilemma dell'innovatore. È difficile "pattinare dove sta andando il disco" senza fare grandi scommesse sul futuro ed essere disposti ad abbandonare linee di prodotti poco performanti. Si può fare(ecco un ottimo esempio), ma non ho visto questo livello di impegno da parte degli operatori storici nel mercato dell'integrazione di dati e applicazioni. Nel 2007, il mio amico Ken Rudin presentò "SaaS Cannibalization and the Civil War Within". È ancora attuale.
- Questioni di patrimonio nel Cloud: Sto generalizzando, ma chi proviene dal mondo EAI/ESB/SOA ha in genere una visione del mondo incentrata sulle applicazioni. Se si proviene dal mondo della business intelligence, del data warehousing e della gestione dei dati master, si ha naturalmente una visione incentrata sui dati. Ripensare, o per usare le parole di Mary Meeker - re-immaginare - l'integrazione richiede la visione di affrontare entrambe le cose allo stesso modo. Gli strumenti EAI orientati ai messaggi hanno difficoltà a gestire il movimento e le trasformazioni dei dati in massa o in blocco. Gli strumenti ETL basati su righe e colonne hanno difficoltà con i dati in tempo reale, non strutturati e gerarchici. Le moderne piattaforme RESTful, incentrate su JSON, sono chiaramente avvantaggiate nella nuova era, sia che si tratti di integrazione di dati basata su eventi, in tempo reale, in streaming o in batch programmati.
- EAI senza ESB: funzionalità come la consegna garantita, i trigger, il monitoraggio e l'orchestrazione sono importanti in cloud come lo erano in sede. Ma l'enterprise service bus (ESB) non è un'opzione che si può utilizzare in cloud. Ecco alcuni commenti di Stefan Ried di Forrester sull'argomento e il motivo per cui la SOA è fallita grazie all'ESB.
- Oltre l'ETL: funzionalità come il riutilizzo, l'aggregazione, le giunzioni, l'unione, la suddivisione, gli SCD e la pianificazione sono altrettanto importanti nel sito cloud quanto lo erano in azienda, quindi non intendo intervenire nel dibattito sull'ETL è morto, ma l'integrazione multiuso o multimodale è chiaramente il futuro. Questo webinar con Dave Linthicum e Gaurav Dhillon offre una buona prospettiva sull'argomento.
- Point to Point non coglie il punto: Per gli ISV legacy, tutte le strade portano al punto numero uno - la cannibalizzazione - ma la semplice introduzione di una versione leggera cloud (o cloud-washed) del vostro software on-premises non costituisce una strategia cloud . Se da un lato cresce la domanda di servizi di integrazione cloud più accessibili e facili da usare, dall'altro è necessario disporre di funzionalità avanzate (si vedano qui alcuni esempi di requisiti iPaaS), di un'ampia connettività e della capacità di andare oltre i semplici scenari di integrazione punto-punto. Altrimenti, l'unica cosa che diventerà ibrida sarà la vostra palla di capelli dell'integrazione.
- Franken-tegration: Parlando di ibrido, si tratta di un tema caldo nell'IT aziendale e cloud nell'informatica, ma quando si tratta di una soluzione iPaaS, ibrido non dovrebbe significare mezzo-sbavato. Un servizio di cloud integrazione deve essere in grado di gestire casi d'uso complessi di integrazione on-premises (dacloud a terra) e da cloud a cloud. Deve inoltre fornire più di un semplice monitoraggio, ma anche un sofisticato ambiente di progettazione e amministrazione dell'integrazione che non richieda strumenti on-premises. Maggiori informazioni su questo argomento nel post Fluidità nelle implementazioni ibride.
- L'integrazione dei Big Data non è fondamentale... o Cloud: Per i fornitori di EAI, l'integrazione dei big data non è un'opzione. Per i fornitori di ETL legacy, costruiti per scalare verso l'alto, non verso il basso, e progettati per gestire principalmente fonti e target strutturati e relazionali, i big data sono un grosso problema. E questo solo per la tecnologia on-premise. Cloud computing e i big data, per non parlare di mobile, social, API e IoT, stanno cambiando le regole e i requisiti dell'integrazione e per stare al passo sarà necessaria una piattaforma moderna ed elastica.
- Elastic Scale Out: ho scritto perché è importante in questo post, Requisiti iPaaS: Scala elastica. Il riutilizzo della tecnologia legacy per la progettazione dell'integrazione o l'elaborazione in tempo reale garantisce che la soluzione non sia stata costruita per cloud e sia elastica fino al midollo.
- Un passaggio a On-Prem: In parte ciò dipende dai piani di remunerazione delle vendite (pagando i rappresentanti solo sul valore del contratto annuale (ACV) del primo anno e non sugli accordi pluriennali, ad esempio), ma spesso gli strumenti di integrazione point-to-point di cloud dei fornitori legacy vengono utilizzati come un'arma a perdere per aprire le porte a nuovi clienti o per espandersi in divisioni di clienti. L'obiettivo a lungo termine è un'esca e uno scambio, il che mi porta all'ultimo punto.
- Concentrazione e DNA: Come ho detto, tutte le strade portano al punto numero uno e al dilemma dell'innovatore, ma esiste una soluzione per l'innovatore e tecniche comprovate per sfuggire alla velocità. Naturalmente, crediamo che esista anche una soluzione per gli integratori, ma per i fornitori indipendenti di software ETL ed EAI (ISV), la questione è se hanno i mezzi per adattarsi e abbracciare veramente il cambiamento che l'era SMACT richiederà. Non solo richiederà un completo riorientamento verso il futuro e la volontà di abbandonare il passato, cosa particolarmente difficile per le aziende pubbliche, ma richiederà anche il passaggio a prezzi di abbonamento, un nuovo approccio all'adozione e al rinnovo dei clienti e uno sviluppo agile. Sarà inoltre necessario un DNA di innovazione e una disponibilità al cambiamento. Quando si è all'interno, la paragono alla storia della rana nell'acqua bollente, ma credo che Aaron Levie, il visionario CEO di Box.com, l'abbia detta meglio quando ha twittato di recente:
Quando si cerca di cambiare un settore dall'interno, è facile capire perché non funzionerà. Quando si è fuori, non si può credere che non funzionerà. ? Aaron Levie (@levie) 8 agosto 2014
