Nel mio ultimo post ho passato in rassegna i requisiti classici dell'integrazione e ho delineato quattro nuovi requisiti che stanno determinando la richiesta di piattaforme di integrazione come servizio(iPaaS) nelle aziende:
- Resilienza
- Fluidità nelle implementazioni ibride
- Gestione inesistente del ciclo di vita della piattaforma
- Protezione del futuro per il mondo di social, mobile, analytics, cloud e internet delle cose (SMACT)
In questo post analizzerò il requisito n. 2: la fluidità nelle implementazioni ibride.
Così come le modifiche alla struttura dei dati sono un evento comune (come discusso nel post sulla resilienza), l'introduzione o il pensionamento delle applicazioni è un problema che la maggior parte delle organizzazioni IT deve affrontare in azienda. Il software come servizio (SaaS) continua ad alimentare la crescita del software a livello mondiale e i fornitori di infrastrutture come servizio (IaaS) e di piattaforme come servizio (PaaS) come Amazon Web Services (AWS) offrono ai clienti la flessibilità di creare sistemi come i servizi di dati relazionali (RDS) o Redshift e di smantellarli in cicli brevi. I marketer digitali sono sempre alla ricerca di nuovi canali per espandere i loro mercati indirizzabili e di ulteriori fonti di dati per arricchire i loro profili di pubblico. Il cambiamento è l'unica costante dell'impresa agile. L'impatto di questi cambiamenti sul livello di integrazione è che deve passare senza soluzione di continuità dal collegamento di sistemi on-premise a sistemi cloud o viceversa, garantendo al contempo un alto grado di continuità aziendale.
Le tecnologie iPaaS realizzate nell'ultimo decennio non sono state costruite per la fluidità necessaria nell'architettura IT ibrida di oggi. Anche se molti fornitori di soluzioni di integrazione legacy offrono un doppio modello di implementazione, uno in sede e uno per il sito cloud , in genere non sono alla pari per quanto riguarda la gestione, il monitoraggio e la configurazione (per non parlare della funzionalità). Ecco alcuni problemi comuni che i clienti si trovano ad affrontare con quelle che io chiamo tecnologie di integrazione "francamente ibride":
-
L'implementazione nel sito cloud non è uguale all'implementazione del motore on-premise. Il provider potrebbe avere bisogno di una serie di requisiti preparatori e di configurazione diversi tra i due ambienti. Ad esempio, l'impostazione di configurazioni tipicamente locali, come il pooling delle connessioni o la fornitura di posizioni per i driver con i loro prodotti on-premise, deve essere eseguita localmente e manualmente per ogni installazione del runtime. Questo può essere un approccio molto manuale, macchinoso e soggetto a errori.
-
La presenza di due dashboard di gestione e monitoraggio, una per il motore di esecuzione on-premise e l'altra per il motore cloud , significa che l'amministratore deve tenere sotto controllo manualmente due ambienti. Questo richiede tempo ed è rischioso.
-
Il motore on-premise è stato costruito per collegare sistemi on-premise e spesso richiede l'apertura di molte porte di rete per le comunicazioni, al fine di ricevere istruzioni di elaborazione dei dati o inviare informazioni di monitoraggio al server. Se i server di monitoraggio e di metadati sono in esecuzione sul sito cloud, ai clienti viene spesso richiesto di aprire dei varchi nel firewall di rete per far funzionare tutte le funzionalità iPaaS.
Una soluzione iPaaS veramente moderna deve offrire quella che io chiamo "fluidità" in una distribuzione ibrida. In particolare, ci sono due aspetti da tenere d'occhio quando si decide di acquistare una soluzione iPaaS:
- cloud Quando si esaminano le soluzioni di integrazione cloud dei fornitori legacy, assicurarsi di guardare sotto il cofano per assicurarsi che non stiano semplicemente "lavando" il loro prodotto on-premise e ospitandolo in cloud. Anche se si tratta della stessa base di codice ospitata in cloud e all'interno del firewall, che può essere distribuita con un'opzione a discesa, ci si imbatterà in problemi di gestione, monitoraggio e configurazione. La gestione e il monitoraggio di questi due runtime necessitano di console separate, poiché non sono peer e non hanno la possibilità di comunicare con il server di monitoraggio attraverso il firewall. Inoltre, i runtime on-premise sono stati progettati per avere file di configurazione che non sono gestiti centralmente e sono locali all'installazione. La gestione e la configurazione di questi ambienti ibridi diventa un costo ricorrente ad ogni aggiornamento del software e può aumentare notevolmente.
- Allo stesso modo, non cadete nella trappola delle mappe "mappate una volta e funzionate ovunque". Non c'è un valore sufficiente quando le mappature create una volta possono essere eseguite ovunque, perché le mappature sono in genere molto specifiche per la sorgente e i target che si stanno integrando. Nella maggior parte dei casi, non sono trasferibili da on-premise a cloud , poiché i tipici endpoint on-premise (Oracle ERP, SAP, Teradata, ecc.) sono molto diversi da quelli di cloud (Salesforce, Workday, Redshift, ecc.). Questo rende la storia del "run everywhere" piuttosto inefficace. L'altro problema di questo approccio è che in realtà nasconde la realtà che "ovunque" implica una serie di prodotti diversi che si cerca di far apparire simili. Questo insieme di prodotti distinti comporta anche problemi di gestione e monitoraggio. Infine, le mappature sono un costo una tantum e quindi la riutilizzabilità non porta a molto. Sono comunque i costi di gestione e monitoraggio a incidere.
È a causa delle sfide sopra elencate che unapiattaforma di integrazione definita dal software come servizio è diventata un fattore chiave per la "cloudificazione aziendale". Un elevato grado di fluidità dell'integrazione si traduce in una maggiore agilità aziendale.
Rimanete sintonizzati per il prossimo post di questa serie iPaaS, che esaminerà l'importanza della gestione del ciclo di vita e il giusto approccio all'integrazione di cloud mentre vi preparate al passaggio aziendale a social, mobile, analytics, cloud e all'internet delle cose (SMACT).
