In questa serie di post esaminerò 6 ingredienti essenziali della piattaforma di integrazione come servizio(iPaaS), come indicato in questo post: Cosa cercare in una moderna piattaforma di integrazione. Ho spiegato perché è importante che l'iPaaS sia un servizio completamente funzionale basato su cloud(basato su un'architettura definita dal software) qui. In questo post tratterò il requisito di un'unica piattaforma per l'integrazione di dati, applicazioni e API.
Abbiamo scritto molto sul cosiddetto Dilemma dell'integratore che le organizzazioni IT aziendali devono affrontare, le cui applicazioni SaaS leggere sono appesantite da strumenti di integrazione di dati e applicazioni pesanti, costruiti ben prima dell'era dei big data, del social, del mobile e del cloud computing(SMAC). Un CIO con cui ho parlato di recente ha definito le sue tecnologie legacy per collegare le applicazioni SaaS e on-premise tra loro (e tutte le fonti di dati disparate della sua azienda) come "integrazione con l'ancora". La buona notizia è che l'innovazione è tornata nel mercato dell'integrazione e che, sicuro come la morte e le tasse, i diversi silos di integrazione convergeranno nel sito cloud sotto il più agile ombrello dell'iPaaS. Noi di SnapLogic parliamo ai clienti e ai potenziali clienti dei vantaggi di una piattaforma di integrazione definita dal software e costruita da zero per gestire requisiti batch e streaming. Certo, si tratta di casi d'uso molto diversi:
- L'integrazione dei dati in batch serve in genere a far entrare e uscire i dati da un'applicazione SaaS (carico iniziale o replica programmata) per esigenze analitiche. Il settore ha storicamente chiamato questa capacità: estrazione, trasformazione e caricamento (ETL), che si estende alla pulizia e alla qualità dei dati e alla gestione dei dati master (MDM). La rilevanza degli approcci ETL tradizionali è ora messa in discussione dall'aumento delle implementazioni di Hadoop e dagli strumenti legacy di questa categoria, costruiti per gestire righe e colonne e requisiti di integrazione di dati strutturati. Qualche mese fa abbiamo organizzato un famoso webinar con Dave Linthicum intitolato Beyond Batch: L'ETL è morto? Al recente Hadoop Summit, il rapporto tra data warehouse, SQL e Hadoop è stato uno degli argomenti più caldi. Date un'occhiata al flusso di tweet o a titoli come questo: I fornitori sono preoccupati perché Hadoop invade il lucroso business del data warehouse.
- L'integrazione dello streaming in tempo reale è in genere destinata a casi d'uso più operativi che analitici. I casi d'uso più comuni dell'integrazione di applicazioni SaaS sono il collegamento di applicazioni di front-office come Salesforce e Workday con sistemi finanziari di back-office come SAP, Oracle EBS e NetSuite. Tipicamente basata sugli eventi, l'integrazione delle applicazioni SaaS continua a richiedere funzionalità come la Guaranteed Delivery, ma la necessità di adattarsi rapidamente alle frequenti modifiche, agli aggiornamenti delle API e alla richiesta di self-service da parte degli utenti finali ha reso inadeguati gli approcci tradizionali. Gli strumenti di integrazione basati su XML e SOAP in questa categoria sono stati progettati solo per gestire dati di piccole dimensioni, ovvero messaggi ad alta frequenza e bassa latenza. Abbiamo scritto perché il pesante enterprise service bus (ESB) diventerà sempre meno rilevante per gli agili requisiti iPaaS di oggi in questo whitepaper - Thoughts on ESBs: Why Buses Don't Fly in the Cloud. Potete anche leggere i vantaggi tecnici di un iPaaS incentrato su JSON qui.
Quindi, mentre continuiamo a vedere la convergenza di categorie di integrazione storicamente distinte (dati, applicazioni, processi), sempre più spesso riteniamo che un'unica piattaforma sarà l'approccio giusto e come tale è uno dei requisiti principali per una moderna soluzione iPaaS. Nel prossimo post parlerò di Elastic Scale. Nel frattempo, potete dare un'occhiata a una dimostrazione di SnapLogic Elastic Integration Platform qui.
