Nuove architetture informatiche per la Digital Enterprise

Il percorso di studio e di ricerca che ha delineato negli ultimi 15 anni la necessità di mantenere ben allineate la strategia d’impresa, con il modello operativo e infine con l’architettura del sistema informativo (SI) aziendale, è molto ricco di contributi, in special modo del CISR (Center for Information Systems Research) dell’MIT[1].

L’architettura di un SI aziendale (Figura 1) deriva dall’architettura dei processi aziendali ed è composta dalle relazioni logiche e fisiche tra le applicazioni software di ogni genere – di front o back office – con le basi dati operative e analitiche disponibili, con il software di integrazione delle applicazioni o dei dati – cosiddetto middleware – e con l’infrastruttura ICT – server, storage, reti locali e geografiche, device periferici di varia natura ecc. Queste componenti dell’architettura del SI sono indipendenti dalle scelte di internalizzazione o di esternalizzazione (make or buy) la cui varietà delle opzioni si è nel tempo ampliata notevolmente, dall’acquisto al noleggio di un bene, a varie forme di hosting e housing che mischiano la proprietà del bene con il suo posizionamento in gestione all’interno o all’esterno dell’azienda, alle varie forme di IT servitization che spaziano dal fleet management al più recente mondo del cloud delle infrastrutture (IaaS), delle piattaforme di sviluppo software (PaaS), dei dati (DaaS) , del software applicativo (SaaS). 

 Figura 1 Architettura di un SI aziendale

La terza era della digitalizzazione si contraddistingue per la spinta di nuove (e meno nuove) tecnologie digitali che riaprono le sfide della digital transformation, spesso ispirandosi alle practice delle grandi multinazionali del web o high tech (per esempio Google, Amazon, Facebook, Uber, Airbnb, Netflix, Apple) e alle loro piattaforme digitali globali prevalentemente customer-facing.

Le cinque possibili aree di impatto delle nuove tecnologie digitali derivate dalla pratica aziendale degli ultimi anni sono le seguenti:

1. processi di communication, collaboration, socializing e sharing tra il personale aziendale e con persone esterne;
2. processi operativi interni (con nuova intelligenza e interconnessione di «cose» e persone realizzate con l’impiego di smart infrastructures, tracking & tracing systems, 3D printing, intelligent automation, advanced robotics ecc.) ed esterni (per esempio, supply chain ecosystems);
3. processi analitici e decisionali (es. analytics, learning systems e new artificial intelligence);
4. customer experience and engagement (con multichannel management, nuovi touchpoints integrati, customer co-innovation ecc.)
5. digitalizzazione e innovazione di prodotti e servizi offerti al mercato (es. intelligent and connected products, data monetization) e possibili nuovi modelli di business.

È possibile osservare che queste aree di impatto condizionano in modo forte la progettazione delle nuove architetture IT e digitali dei SI a due livelli:

1. con l’integrazione tra i nuovi ambiti tecnologici digitali che generano quegli impatti (es. tra IoT e analytics, tra web/mobile app e vari customer touchpoint multicanale, tra i social data e le social analytics, tra la robotica avanzata e la nuova intelligenza artificiale ecc.);
2. con l’integrazione tra i nuovi ambiti tecnologici digitali e i sistemi amministrativo-gestionali e di core business (es. di core banking, di gestione polizze, di gioco a scommessa, di tracking & tracing dei carrier, di gestione del traffico telefonico ecc.) dell’impresa.

Le strategie di integrazione del digitale nelle imprese si stanno oggi rivelando molto diversificate in funzione delle scelte strategiche deliberate di IT governance, di IT sourcing (e clouding), di IT organization, di IT budgeting, oppure, più spesso, in funzione di scelte tattiche, dettate dall’opportunità del momento, dalla prudenza, dalla voglia di sperimentare, confrontandosi con ambienti tecnologici e risultati aziendali ancora spesso indefiniti e incerti.

Il grado di maturità della singola tecnologia digitale (es. i droni o la blockchain o il 3D printing) o del sistema digitale (che integra più tecnologie digitali di base, es. l’industrial IoT o il multichannel) come valutazione qualitativa e ovviamente molto dinamica, è rintracciabile in molteplici fonti di analisti del mercato (Gartner group, Altimeter, Ovum, Forrester, TechRadar ecc.) o di centri di ricerca (MIT, Devo Lab SDA Bocconi); il grado di integrazione della tecnologia/sistema digitale con i sistemi gestionali e core business dell’azienda dipende fortemente dal gap esistente tra l’architettura IT as is e quella to be emergente dal nuovo modello operativo «digitale»: se l’attuale architettura IT è già stata aggiornata, gestita e razionalizzata secondo i principi dell’Enterprise Architecture Management, se è già stata «pulita» da vecchi sistemi legacy e dotata di piattaforme di integrazione dei processi (cosiddetti BPM platform), di piattaforme di gestione degli eventi (cosiddetti event-processing platform) o di sistemi di integrazione dati (cosiddetti data integration platform) o di applicazioni/servizi (es. tramite API, application programming interface), sarà più agevole definire e implementare una architettura digitale to be[2].

Questo nuovo contesto digitale genera vari effetti e varie opzioni possibili per le architetture dei nuovi SI aziendali. Un’architettura definisce sia una serie di vincoli sia una serie benefici possibili, quindi ne consegue che nessuna architettura informatica è di per sé «giusta» o «sbagliata», ma lo è in funzione dei benefici che può fornire in determinati contesti aziendali guidati da obiettivi strategici di vario tipo, quindi anche digitali: di conseguenza il fine ultimo di un’architettura è identificare una serie di regole su come realizzare (sviluppando in casa, acquistando sul mercato o integrando ad hoc) soluzioni informatiche che rispondano in maniera mirata ed efficiente a determinati obiettivi aziendali. Naturalmente ne consegue che, in funzione degli obiettivi e dei requisiti di business, è possibile che esistano più risposte alla domanda «Qual è l’architettura del SIA più coerente», e di conseguenza nella scelta dovranno essere considerati anche fattori quali l’ambiente tecnologico pre-esistente e di partenza, le capacità e le competenze IT disponibili in azienda, la cultura aziendale e digitale stessa e altri fattori soft (es. l’orientamento all’innovazione e al cambiamento, la capacità di gestire e imparare dagli errori, la compatibilità organizzativa verso approcci «agili» di lavoro e di sviluppo del software ecc.) che possono agevolare o ostacolare la costruzione della nuova architettura. Infine in alcuni casi, in special modo in imprese di grandi dimensioni, multibusiness e globali, può ovviamente accadere che più opzioni architetturali possano (e spesso debbano) essere adottate e combinate per sostenere programmi di cambiamento importanti, complessi e incerti, come, per l’appunto, la trasformazione digitale.

Dall’osservazione della pratica aziendale degli ultimi due-tre anni sono stati identificati sette requisiti architetturali che possono essere considerati complementari e indispensabili (anche se non sufficienti per la necessaria presenza di altre condizioni e fattori come poco sopra ricordato) per il successo di piani e programmi di trasformazione digitale.

1.       Interoperabilità (o capacità di «propagazione» degli eventi rilevanti)

Il beneficio fondamentale della digitalizzazione è la possibilità di catturare eventi rilevanti per la vita aziendale (es. un significativo ordine cliente inaspettato, un apparato di produzione che non opera in modo efficiente, un evento naturale che ostacola la supply chain), trasformandoli in messaggi digitali che possono essere propagati all’interno dei processi aziendali costruendo alti livelli di automazione di processo e di analisi dei dati generati. Di conseguenza l’architettura IT deve far sì che i sistemi applicativi aziendali possano liberamente «interoperare» tra di loro, scambiandosi dati e cooperando allo scopo di automatizzare e integrare tra di loro i processi operativi e di rilevazione/scambio dei dati. Questi stessi dati poi debbono poter essere raccolti e sintetizzati in opportuni «depositi di dati» (data lake, data warehouse, data mart ecc.) allo scopo di essere analizzati per il supporto di decisioni operative (anche automatiche), tattiche e strategiche.

2.       Tempestività (o capacità di rilevazione immediata degli eventi imprevisti)

Particolari eventi di business (per esempio, un concorrente che improvvisamente abbassa i prezzi per un certo prodotto) può rappresentare una minaccia o un’opportunità (l’abbassamento dei prezzi potrebbe essere un sintomo di difficoltà commerciali). La capacità della azienda di reagire in tempo utile (business real-time), cioè nel minimo tempo necessario per massimizzare l’opportunità o minimizzare gli effetti della minaccia, è vitale per il successo dell’azienda. Le architetture IT pertanto devono consentire la rilevazione istantanea o nel minor tempo possibile di questi eventi, per dare al management aziendale la possibilità di analizzarne gli impatti (magari sfruttando anche l’«interoperabilità» sopra citata) e pertanto di attivare le opportune reazioni.

3.       Agilità (o capacità di esecuzione veloce delle decisioni e delle azioni aziendali)

La velocità con cui operano le aziende digitali è di ordini di grandezza superiore a quella con cui opera l’azienda tradizionale, sia per la maggiore digitalizzazione dei dati e dei processi operativi, sia per le maggiori capacità digitali sviluppate e applicate in azienda. Pertanto la rapidità nel lanciare nuovi prodotti e servizi, attivare nuove partnership, rimpiazzare fornitori inefficienti e riconfigurare i processi e i modelli operativi sono caratteristiche fondanti del loro modo di essere azienda e di mantenere i vantaggi competitivi. Di conseguenza l’architettura IT deve poter permettere di introdurre il cambiamento rapidamente e in modo «agile», cioè senza comportare un totale ridisegno dei processi e delle applicazioni a loro supporto (es. per integrare un’azienda acquisita o per gestire un nuovo canale di digitale di interazione con i clienti o per ideare, sviluppare e lanciare un nuovo prodotto o servizio).

4.       Scalabilità (o capacità di sostenere la crescita controllata)

La digitalizzazione – eliminando, o almeno riducendo, la necessità di prossimità fisica ai clienti o ai partner commerciali – potenzialmente espande enormemente, a livello globale, il mercato indirizzabile e le opportunità di partnership commerciali. Inoltre essa rende anche possibile lanciare rapidamente iniziative di natura sperimentale, che in molti casi vengono abbandonate ma che a volte possono risultare di enorme successo. L’architettura IT deve quindi essere in grado di adeguarsi a queste esigenze e capace di adattarsi per sostenere carichi di lavoro con picchi e andamenti non prevedibili, senza per questo comportare ridisegno delle applicazioni e dei processi.

5.       Consapevolezza della situazione (o capacità di monitorare e di misurare i fenomeni e i risultati aziendali in modo veloce ed ampio)

La velocità a cui si avviano ad operare le aziende che si digitalizzano può rendere difficile per i decisori aziendali capire se si sta effettivamente andando nella giusta direzione e con risultati accettabili. Se a livello strategico e tattico le decisioni possono ancora essere informate con il supporto dei tradizionali sistemi di business intelligence e analytics, le decisioni operative spesso avvengono ancora «al buio», cioè senza una piena consapevolezza di quale sia la reale situazione di alcuni fenomeni di business (situation awareness), per esempio in termini di giacenze in un magazzino di transito per il delivery al cliente finale, di conversione dei click di una promozione online, di sellout dei prodotti da punti di vendita indiretti, di «ultimo prezzo» in situazioni in cui si applica il dynamic pricing. L’architettura IT deve pertanto fornire sia ai decisori operativi sia al middle e top management le informazioni che diano loro consapevolezza della situazione storica e in tempo reale per consentire loro di prendere decisioni avendo un quadro il più possibile completo e aggiornato.

6.       Self-service (o capacità di creare il giusto mix di accentramento e decentramento IT)

Le esigenze di business real-time e agilità possono portare alla crisi di un’unica funzione IT centralizzata (in shared-services o meno) con responsabilità di progettare ed erogare servizi e soluzioni IT per tutta l’azienda: la possibile rigidità, selettività e complessità dei processi IT gestiti a livello centrale spesso porta inevitabilmente al proliferare di fenomeni di cosiddette shadow IT (sistemi e soluzioni IT progettate e gestite da singole funzioni di staff o di business aziendali) che possono confliggere con le esigenze di interoperabilità e di consapevolezza della situazione prima menzionate. Un’applicazione sviluppata o acquistata in autonomia da una singola funzione aziendale, può integrarsi a fatica e con costi imprevedibili con il resto del sistema informativo aziendale e certamente non fornirà dati sulla situazione aziendale ai decisori al di fuori dell’ambito dei suoi utenti di funzione o dipartimentali.

Peraltro, dato che la forma più estrema di agilità si ha quando è colui che ha l’esigenza che si sviluppa la propria soluzione, l’architettura IT deve favorire, e non combattere, un approccio «self-service», ancorché ben gestito e controllato. In altre parole, deve far sì che le soluzioni realizzate in autonomia da una funzione aziendale possano essere integrate in modo semplice con il resto del sistema informativo in modo che si possa innestare nei processi aziendali e possa rendere disponibile i suoi dati per favorire la consapevolezza della situazione a tutto il management aziendale. L’architettura IT può rendere possibile tutto ciò se le soluzioni IT self-service vengono sviluppate sulla base di standard e regole comuni che rendono possibile questa integrazione a costi ragionevoli e minimizzando i rischi a livello di compliance, sicurezza, privacy delle informazioni e di altri elementi di IT governance.

7.       Automazione

Il numero di fenomeni da tenere sotto controllo e i tempi di reazione richiesti dal digitale sono ovviamente incompatibili con processi aziendali dis-integrati, non reingegnerizzati e in larga parte manuali. Per esempio, non è sufficiente riuscire a identificare con tempestività un evento di business tramite le architetture che abilitano la consapevolezza della situazione, ma è anche necessario distinguere tra quelli di maggiore importanza o criticità per attivare tutte le azioni necessarie ad affrontare in tempo utile una o più situazioni. Si consideri, per esempio, un tentativo di frode su una carta di credito. Una volta scoperto il tentativo è necessario operare una serie di azioni per minimizzare il danno (avvisare il cliente, avvisare le autorità di polizia, bloccare la carta, inserirla nelle black list ecc.). è del tutto evidente che se questa sequenza di operazioni può essere eseguita in modo automatico e tempestivo, la loro efficacia (ed economicità) sarà superiore alla loro esecuzione in modo manuale. Oppure è evidente che se un sistema di monitoraggio della navigazione su un sito di e-commerce rileva l’interesse di un cliente verso diversi prodotti complementari di basso valore unitario e margine e contemporaneamente verso alcuni prodotti di maggior valore e redditività, potrebbe in automatico proporre un’offerta promozionale sui primi e, sempre in automatico, non fare azioni immediate verso il cliente, ma «allertare» un salesman o un contact center affinché si attivi di persona per un contatto o un servizio diretto verso il potenziale cliente. Pertanto l’architettura IT deve poter consentire di automatizzare questi processi col duplice scopo di aumentarne l’efficienza e l’efficacia dal punto di vista dei risultati e delle performance aziendali. E’ naturale immaginare che su siti di e-commerce, in customer experience omnicanale integrate, nell’IoT industriale, i fenomeni da tenere sotto controllo siano potenzialmente molto superiori alla capacità umana di «osservarli» e di decidere azioni conseguenti in modo efficiente, per cui l’automazione intelligente con architetture IT che consentano di realizzare automating analytics o sistemi di intelligenza artificiale che «decidono ed eseguono» in automatico azioni mirate, sarà sempre più rilevante nell’economia digitale.

Ovviamente altri requisiti architetturali consueti – si pensi alla sicurezza, alla compliance o a tutti gli aspetti di gestibilità e amministrazione dei sistemi IT e digitali – sono importanti, ma i sette evidenziati in precedenza sono tra quelli che meritano più attenzione, in quanto per certi versi inconsueti e molto specifici del mondo digitale.

A fronte di questi sette requisiti esistono dieci opzioni architetturali la cui combinazione disegna l’architettura complessiva del SI aziendale. Nessuna di queste opzioni architetturali è di per sé esaustiva, cioè in grado di rispondere a tutti i sette requisiti architetturali illustrati precedentemente. Il lavoro di comprensione e di razionalizzazione è solo all’inizio per cui senza alcuna pretesa di esaustività, la seguente Tabella 1 incrocia da un lato i requisiti architetturali presentati in precedenza con le possibili opzioni tecnico-architetturali.

Tabella 1 Requisiti e possibili opzioni tecniche

Legenda degli acronimi utilizzati:

IoT: Internet of Things

API: Application Programming Interface

HIP: Hybrid Integration Platform

EDA: Event Driven Analytics/Architecture

IMC: In-Memory Computing

HTAP: Hybrid Transaction/Analytical Processing

AI/ML: Artificial Intelligence/Machine Learning

La tabella puoi essere letta in due modi:

1) in orizzontale fornisce indicazioni su quali sono le architetture che possono aiutare il raggiungimento di determinati obiettivi della digitalizzazione. Per esempio, per migliorare l’agilità dell’azienda, le architetture di cloud computing, i microservizi, le APIs, le hybrid integration platform e le event driven analytics/architecture andrebbero considerate e valutate attentamente. Oppure per migliorare l’interoperabilità tra i processi aziendali, sono necessari investimenti in una qualche combinazione di mobile computing, Internet of Things, APIs e hybrid integration platform. Naturalmente non tutte le architetture associate a un certo requisito/obiettivo debbono necessariamente essere adottate da tutte le aziende. Per esempio, non è strettamente necessario adottare architetture di intelligenza artificiale per raggiungere alti livelli di automazione, anche se esse certamente possono dare un contributo fondamentale;

2) in verticale, per identificare i potenziali benefici di una determinata opzione tecnico-architetturale.

Infine osservando la Tabella 1 si può notare come alcune opzioni architetturali – mobile computing, hybrid integration platform (HIP), APIs ed event processing – indirizzino quasi tutti i requisiti architetturali identificati. Ne consegue che un investimento in queste opzioni sia di fatto una scelta che presenta elevate probabilità di coerenza rispetto al proprio programma di digital transformation. Come tale queste architetture rivestono un ruolo di «fondazione», cioè sono pressoché indispensabili per la trasformazione digitale. In altre parole è molto difficile avviare iniziative di trasformazione digitale senza prendere in considerazione tali architetture, che tra l’altro sono spesso tra loro complementari: per esempio, le applicazioni mobili sono tipicamente integrate con i processi aziendali via API ed event-driven (come avviene nel caso delle notifiche che arrivano sullo smartphone), i quali a loro volta richiedono una piattaforma di integrazione ibrida per interoperare con i sistemi applicativi gestionali aziendali.

Altre opzioni architetturali – cloud, IoT, microservices, in-memory computing, HTAP e artificial intelligence – invece sono più «di scopo», cioè sono certamente importanti, ma vanno prese in considerazione sulla base di valutazioni più puntuali legate alle singole iniziative o progetti digitali verticali (di funzione o processo aziendale), in considerazione anche della loro complessità dal punto di vista realizzativo, del loro costo e della difficoltà di reperire sul mercato professionalità ed esperienze.

In conclusione, il top management di un’azienda che intende avviare programmi di trasformazione digitale deve riflettere attentamente, insieme alla propria funzione IT, su come implementare ed eseguire la propria strategia digitale, su come si trasforma il proprio modello operativo, su come si viene a definire la nuova architettura aziendale e quindi su come l’architettura del SI aziendale si deve modellare per consentire di conseguire obiettivi e risultati attesi dalla trasformazione digitale; molte sono le opzioni tecnico-architetturali che si possono combinare tra di loro per costruire questa nuova architettura IT digitale: il ruolo di advisor digitale delle funzioni IT nel trovare la miglior combinazione possibile per raggiungere gli obiettivi della digital transformation in condizioni di economicità è un ruolo che è diventato rilevante alla luce anche delle prime esperienze e disillusioni sui facili benefici e risultati dalla nuova digitalizzazione.

(Paolo Pasini è Associate Professor of Practice in Information Systems, SDA Bocconi School of Management

Massimo Pezzini è Senior Distinguished Analyst in Gartner Group)