Inserire un formato JSON in un ESB tradizionale basato su XML è come fare una borsa di seta con un orecchio di scrofa.
- L'analogia di Loraine Lawson in riferimento all'articolo: Perché gli autobus non volano in Cloud: riflessioni sugli ESB
Recentemente ho scritto sul perché l'enterprise service bus (ESB) legacy non volerà in cloud. Loraine Lawson di IT BusinessEdge ha recensito l'articolo e ha posto la domanda: L'eredità delle integrazioni è importante in Cloud? In SnapLogic crediamo così tanto che l'eredità sia importante che abbiamo ricostruito la nostra piattaforma di integrazione elastica da zero per essere veloce, multi-punto e moderna. Ecco perché crediamo che il patrimonio dei prodotti di integrazione sia importante:
- Perché il dilemma dell'innovatore crea grossi ostacoli ai fornitori di integrazione legacy per avventurarsi completamente in questa nuova area di social, mobile, analytics, cloud e (Internet of) Things, che abbiamo chiamato SMACT.
- I tentativi di basarsi sui successi del passato si traducono in esperimenti e soluzioni a metà.
Sarete sorpresi dal fatto che molti product manager dell'integrazione on-premise nella Silicon Valley passino più tempo a preoccuparsi delle minacce agli utili per azione (EPS) che del futuro dell'ESB!
Vediamo quindi i due motivi per cui il patrimonio di integrazione è importante.
La sfida del dilemma degli innovatori
Le parole di Clayton Christensen riecheggiano oggi nelle sale riunioni della Silicon Valley, mentre ci troviamo di fronte a tante innovazioni tecnologiche e a tanti sconvolgimenti dei mercati tradizionali. È estremamente difficile rinunciare al modello di licenza perpetua per la manutenzione del software. Il passaggio a un modello di prezzi in abbonamento, per non parlare dei cambiamenti culturali richiesti dal software come servizio (SaaS), non è un'opzione semplice. Anche se i dirigenti dell'azienda sono disposti a fare questa transizione, sono gli azionisti che sarebbero molto scontenti di passare da margini operativi del 30-40% a una sola cifra. Se foste una mosca sul muro nella sala del consiglio di amministrazione di un'azienda con un patrimonio on-premise che cerca di entrare nel mercato cloud , la parola più ricorrente sarebbe "cannibalizzazione". E anche se il consiglio di amministrazione e i dirigenti lo capiscono, non è facile dire ai team dei prodotti legacy che la loro creatura non è più bella e ai team di vendita che state per introdurre un servizio cloud che non richiederà più l'etichetta del prezzo iniziale dell'ancora di salvataggio on-premise.
Soluzioni di integrazione "ibride" a metà
L'altro motivo per cui le aziende produttrici di software on-premise faticano a staccarsi dalla loro eredità è che la maggior parte delle innovazioni tecnologiche significative non possono essere applicate con la stessa facilità del proverbiale "rossetto sul maiale", a meno che la nuova offerta non venga completamente riprogettata e sviluppata da zero in base ai più recenti requisiti e specifiche del mercato. Non sono molte le aziende di successo che hanno voglia di riscrivere completamente l'offerta, per i motivi citati nella precedente sezione "Dilemma dell'innovatore". Per fare un'analogia, è come se un'azienda produttrice di auto con motore a combustione interna apportasse modifiche estetiche alla propria auto a combustione di gas e si aspettasse di competere con un'auto all'avanguardia come Tesla nel mercato delle auto elettriche. Nissan ha dovuto costruire la sua Leaf da zero per soddisfare il mercato delle auto elettriche, realizzando una trasmissione completamente nuova, un nuovo motore e una nuova alimentazione.
Tornando alle specificità del mercato dell'integrazione e al motivo per cui il patrimonio dei fornitori è importante, ecco alcune ragioni tecniche:
-
La resilienza, nel contesto dell'integrazione, è la capacità dei flussi di integrazione di gestire le modifiche e le variazioni delle strutture di dati senza interrompersi. La maggior parte dei prodotti di integrazione legacy sono fortemente tipizzati o strettamente accoppiati. In altre parole, ciò significa che la piattaforma deve conoscere le specifiche esatte dei dati che deve elaborare quando esegue i flussi. Purtroppo, il mondo SMACT non è così conforme come vorremmo. Le modifiche agli schemi e alle strutture di dati sono comuni. L'aggiunta di colonne alle tabelle del database o l'aggiunta accidentale da parte di un partner di ulteriori campi di dati in un documento che vi viene inviato non dovrebbero mettere in ginocchio le vostre integrazioni e quindi la vostra azienda. La resilienza o un paradigma a tipizzazione debole/accoppiamento lasco non è qualcosa che può essere introdotto in un prodotto come un ripensamento. L'introduzione della resilienza è un processo complesso come la sostituzione della trasmissione dell'auto, necessaria per passare da un motore a combustione interna a un'auto elettrica. La piattaforma deve essere progettata su questi principi moderni fin dalla fase di progettazione. Pertanto, il patrimonio di integrazione è importante.
-
I prodotti di integrazione legacy che provenivano dal settore dell'estrazione, trasformazione e caricamento (ETL) erano ottimizzati per i casi d'uso dei dati relazionali, come lo spostamento di grandi volumi di dati da fonti di dati relazionali a magazzini di dati relazionali. Questi prodotti sono stati costruiti per leggere righe e colonne, operare su di esse e scrivere righe e colonne. Oggi questi prodotti sono in difficoltà quando si tratta di gestire dati gerarchici. Allo stesso modo, gli strumenti di integrazione delle applicazioni aziendali (EAI) sono stati costruiti per integrazioni orientate ai messaggi, in grado di gestire dati gerarchici, ma ottimizzati per integrazioni in tempo reale per gestire un messaggio alla volta nel modo più efficiente possibile. Liberarsi di questa eredità per gestire casi d'uso più ampi non è un'impresa da poco. È come cambiare il motore dell'auto per alimentarlo a batteria. Chiunque abbia avuto problemi al motore sa che i meccanici consigliano di comprare un'auto nuova piuttosto che sostituirla!
-
Infine, i prodotti di integrazione con un'eredità on-premise sono costruiti con una mentalità on-premise. Le configurazioni e le librerie di prodotti sono disposte localmente su ogni server fisico. Queste risorse locali richiedono un'attenzione manuale quando si tratta di aggiornamenti del prodotto e correzioni di patch. La gestione di questi file locali, soprattutto in un ambiente altamente distribuito, diventa rapidamente un incubo. Questa è un'altra di quelle eredità che non possono essere eliminate senza una completa riprogettazione del prodotto. Pensate a questa gestione del ciclo di vita della piattaforma ereditata come a un cambio d'olio che dovete fare spesso con il vostro motore IC. Come la maggior parte delle persone, il proprietario di un'auto con motore a combustione interna ha bisogno di prendersi del tempo per portare l'auto in officina per i cambi d'olio minori e maggiori. Le Tesla non hanno bisogno di cambi d'olio e tutta la manutenzione del prodotto è definita dal software. Tutti gli aggiornamenti vengono scaricati automaticamente sull'auto tramite la rete mobile e i clienti non hanno tempi di inattività.
In sintesi, il patrimonio è più che altro uno svantaggio nella rapida evoluzione dell'innovazione tecnologica. I cambiamenti di paradigma tecnologico sono ancora di grande portata e spesso richiedono un nuovo approccio e una riprogettazione di prodotti e tecnologie. In questo articolo abbiamo tracciato un'analogia tra le piattaforme di integrazione con eredità e i motori a combustione interna, e tra le moderne piattaforme di integrazione e le auto elettriche come le Tesla. Naturalmente, si può sempre sostenere, a ragione, che alla fine della giornata entrambe le auto vi porteranno a destinazione. Ma, come si suol dire, non è la destinazione, ma la qualità del viaggio che rende la destinazione degna di nota. E con una moderna piattaforma di integrazione come servizio(iPaaS), il viaggio è più veloce, più economico e con meno tempi di inattività forzata, il che lo rende davvero piacevole.
Prossimi passi:
- Leggete i post di Greg Benson sull'architettura e sui servizi della piattaforma SnapLogic.
- Per saperne di più sull'integrazione di SnapLogic, consultare alcune delle nostre risorse Cloud.
