Sul piano puramente teorico, l’idea di Composable Enterprise è diventata patrimonio comune di tutte le imprese che vogliono far leva sull’integrazione degli strumenti e dei processi digitali per portare innovazione.
Il problema è che passare dalla teoria alla pratica risulta ancora tutt’altro che immediato. Non solo: molte organizzazioni credono di aver intrapreso in modo corretto il percorso che le porterà a trasformarsi in organizzazioni moderne, ma la verità è che in molti casi si tende a confondere la stratificazione applicativa, gestita in modo più o meno creativo, con una realizzazione compiuta del concetto di Composable Enterprise.
Il peggio è che il divario tra i due approcci non risulta evidente fino a quando i processi aziendali non devono affrontare situazioni realmente complesse sul piano dell’integrazione, come la trasformazione dei modelli di business (per esempio con l’avvio di nuove attività in mercati ancora inesplorati) o nel momento in cui si verificano acquisizioni o fusioni con altre società che implicano la convergenza, su una piattaforma comune, di task e flussi di lavoro a volte estremamente eterogenei.
Senza Composable Enterprise, l’IT management è più complesso
“È in queste circostanze che vengono fuori i limiti dovuti all’adozione di modelli non corretti, che spesso si manifestano con integrazioni poco efficaci. L’esatto contrario di ciò che dovrebbe garantire il paradigma della Composable Enterprise” spiega Davide Capozzi, Innovation Director di WIIT.
Capozzi sottolinea che si tratta di una difficoltà sperimentata da molte più imprese di quanto si possa immaginare. “Vale per tanti aspetti del process management, ma in particolare sul fronte dell’integrazione il fenomeno riflette le iniziative che le imprese stanno mettendo in campo per affrontare il percorso di digitalizzazione, inteso non solo come sforzo per favorire la modernizzazione e l’efficienza operativa, ma proprio come leva di trasformazione dei modelli di business”.
Basti pensare all’evoluzione dalla vendita fisica alle piattaforme di e-commerce, o alla fornitura di servizi puramente digitali, strategie utilizzate anche dalle PMI come grimaldello per entrare in nuovi settori e per accelerare la crescita dei ricavi. “E all’interno di ciascuna azienda i responsabili di business premono per avere soluzioni (analytics, componenti di process automation, piattaforme di artificial intelligence) in grado di abilitare o potenziare i nuovi servizi digitali. Naturalmente queste richieste ricadono sulla divisione IT, che il più delle volte è sottodimensionata e non dispone delle competenze necessarie a indirizzare il problema con una visione moderna”.
Tra gli IT manager che accettano la sfida, infatti, non sono pochi quelli che ricorrono a pesanti customizzazioni dei sistemi, di fatto replicando le logiche di integrazione utilizzate per gestire i progetti pregressi. “Quest’approccio poteva andare bene fino a qualche tempo fa: oggi più che vantaggi porta in dote un gran mal di testa”, dice Capozzi. “La spaghetti architecture, che per avvicinare i dati alle applicazioni prevede la connessione diretta dei sistemi da punto a punto, non è funzionale allo scenario applicativo che si delinea all’orizzonte. E più il mondo andrà avanti, più questa complessità aumenterà, specialmente se si opera in landscape di livello enterprise ampi e verticalizzati, dove non mancano software legacy e tecnologie eterogenee”.
L’importanza di omogeneizzare i dati
Dall’ERP al CRM, passando per il warehouse management system e gli applicativi a supporto della supply chain, sono in effetti molteplici gli ambienti in cui si producono i dati che dovrebbero alimentare le nuove applicazioni digitali. “Se le strutture dati non vengono omogeneizzate, aggregate e distribuite in modo corretto, inevitabilmente crescerà lo stress dei sistemi e la complessità per produrre gli output richiesti, a discapito dell’efficienza dei processi”, avverte Capozzi, che continua: “Per implementare un’integrazione agile ed efficace bisogna invece dare vita a quella che una volta si chiamava “service-oriented architecture”, ovvero adottare un metodo di sviluppo che si concentra su servizi discreti invece che su una progettazione monolitica”.
In base a questa filosofia, ciascun servizio fornisce una funzionalità aziendale e i vari servizi possono comunicare tra loro attraverso piattaforme e linguaggi condivisi, all’interno di un layer unico, astratto, che permette di elaborare i dati e di dialogare con gli applicativi sottostanti senza dover interagire direttamente con i sistemi.
“La Composable Enterprise si innesta su questo modello architetturale, e consente di integrare tool e funzionalità come se fossero veri e propri blocchi da attaccare, staccare e riutilizzare lungo i vari processi”.
Costruire la Composable Enterprise sull’iPaas: vantaggi e avvertenze
Questa è la teoria, ma nella pratica come si sviluppa un layer del genere? “Il modo più semplice è ricorrere a una Integration-Platform-as-a-Service (iPaaS)” spiega Capozzi. “Sostanzialmente si espande la mappa applicativa con una componente che sfrutta logiche no code o low code per mettere in comunicazione tutti gli elementi utili a gestire la catena del valore. Attenzione però: per quanto l’IpaaS semplifichi notevolmente il tema dell’integrazione, parliamo di uno strumento che non può essere adottato senza le dovute accortezze”.
Si tratta pur sempre di uno strumento che in qualche modo diventa il sistema nervoso dell’IT aziendale. E, proprio per la rilevanza che assume, richiede competenze e strumenti di sicurezza ad hoc. Se per esempio l’Integration Platform sperimenta un disservizio – a causa di un errore di programmazione o per un attacco esterno – il danno si riflette su tutte le applicazioni aziendali a essa connesse e l’intera organizzazione rischia di essere paralizzata.
“Chi implementa una soluzione IpaaS deve essere consapevole che introduce inazienda un potenziale single point of failure rispetto agli attacchi informatici: chi vuole danneggiare l’impresa ha tutto l’interesse a puntare a quel layer, che va per questo protetto con sistemi di cybersecurity all’avanguardia. C’è poi il tema della scalabilità: nel momento in cui il business cresce e aumentano le richieste di capacità di elaborazione, la piattaforma deve espandersi in modo coerente”.
Infine, non si può sottovalutare la questione delle competenze. “Questo strumento, per quanto sia ergonomico e relativamente semplice da usare grazie a interfacce low code, richiede comunque skill specifiche: se è vero che ci sono blocchi da assemblare tramite connettori ad hoc, nella costruzione dei servizi l’utente ha di fronte a sé una tavolozza bianca. Il modo in cui si mette insieme un flusso è dunque del tutto arbitrario: in assenza di un know how adeguato si torna al punto di partenza, e il rischio di ritrovarsi con un’architettura Frankenstein è di nuovo dietro l’angolo. E non solo: nel momento in cui i flussi vanno in esercizio, partono le attività di maintenance e gestione dei processi di incident, change e problem che pongono le aziende ancora di fronte al dilemma delle competenze e della capacity necessaria per gestire le richieste”.
Il cloud può rispondere efficacemente alle sfide di sicurezza e scalabilità, ma per quanto riguarda le skill sarà dunque necessario avviare programmi di formazione continua per le risorse interne. “L’alternativa è rivolgersi a un partner che conosca approfonditamente questa tecnologia e che, disponendo di tutti gli strumenti per implementarlo, funga da interlocutore unico per quello che dovrebbe essere considerato un servizio onnicomprensivo”, dice Capozzi, che chiosa: “per questo motivo abbiamo stretto una partnership che ci permette di coprire anche gli aspetti legati al design dei flussi e alla maintenance degli stessi, in modo tale da offrire ai nostri clienti una soluzione unica sul mercato che coniuga tutti gli aspetti relativi a un iPaaS”.
