Mani, menti e mercati tra tecnologia e cultura

La gestione dell’automazione (si inizia a chiamare “economia della macchina”) sollecita sempre più le culture e le strategie d’impresa a immergersi dentro le molte, nuove e diverse dimensioni tecnologiche contemporanee.

In particolare, l’automazione presente e prossima sta emergendo all’incrocio di tre stratificazioni ingegneristiche: macchine e automi (la forza fisica), Intelligenza Artificiale e algoritmi di apprendimento automatico (le capacità cognitive), architetture e protocolli di scambio (come le interazioni automatizzate dei contratti smart sulla Blockchain).

Con un’espressione sintetica e semplice la definisco l’automazione delle “3m” ovvero: mani, menti, mercati. Non credo, allora, che le imprese possano affrontare culturalmente il passaggio epocale in atto senza valutare insieme l’impatto specifico e quello combinato di questi tre fattori: gli automi, gli algoritmi, i protocolli.

Soprattutto non credo possano farlo senza la dotazione di un pensiero strategico avanzato rispetto alle tecnicalità di frontiera che sostanzieranno l’economia neo-automata. In questa prospettiva, propongo qui una prima, breve esplorazione su quattro orizzonti tecnologici (che sono anche culturali e manageriali) che diventeranno chiave in questa futura economia della macchina: Cloud nativity, Chaos engineering, Edge ecosystem, Architecture observability.

Cloud nativity: come sfruttare le potenzialità della nuvola

Le metafore metereologiche e geografiche della computazione si sono ampliate negli ultimi decenni. Per affrontare criticità come sicurezza, latenza, connessione ed efficienza, la capacità computazionale a disposizione delle imprese si è venuta stratificando nel tempo su livelli sovrapposti e connessi dai nomi evocativi.

Così Cloud computing, Fog computing, Edge computing mappano, oggi, figurativamente i luoghi della computazione: sulla nuvola (cloud), nella nebbia (fog) o al margine del mondo (vale a dire nei nodi o edge dell’Internet of Things). Ma c’è di più, oltre queste metafore geografiche.

Strategicamente, dobbiamo riconoscere che queste diverse ‘collocazioni’ della computazione sono anche e soprattutto ‘configurazioni’ della computazione. Dunque, il cloud non è tanto un luogo della computazione, ma è soprattutto un modo della computazione. Non è, allora, solo una questione di dove sono i server, ma è un cambio di cultura d’impresa su ‘come’ nativamente si possano immaginare e costruire servizi, applicazioni ed esperienze per consumatori e clienti.

Per questo, la nuvolo-natività (Cloud nativity) è altra cosa dal trasferimento sic et simpliciter di preesistenti applicazioni e servizi sulla nuvola. Non basta cioè spostare in cloud l’esistente (come molte imprese erroneamente oggi pensano), ma occorre ripensarlo alla luce delle potenzialità della nuvola. Per essere, per l’appunto, nuvolo-nativi.

Filosoficamente dunque questa nuova computazione spazializzata e sempre più automatizzata è più un nuovo modo d’essere del mondo che un luogo dello stare al mondo. Più una questione ontologica che topologica.

Chaos engineering, farsi attaccare per difendersi

Tecnicamente, il Chaos engineering istanzia l’idea e la pratica ingegneristica di attaccare intenzionalmente, preventivamente e sempre più automaticamente le proprie architetture informatiche (e di business) al fine di poterne conoscere e testare sicurezza, consistenza e resilienza.

Con questo scopo, si pianificano e si lanciano – con esperimenti automatizzati – attacchi caotici al proprio sistema di erogazione di servizi mentre è in effettiva produzione (non quindi in un ambiente sicuro di prova o di sviluppo) per esplorare e individuare preventivamente punti di debolezza, insospettabili criticità operative, interruzioni o fallimenti del servizio ai clienti.

Così fanno, per esempio, i Chaos engineer di Netflix e di molte grandi piattaforme digitali cercando deliberatamente di far fallire l’erogazione. Filosoficamente, il passaggio di paradigma per le imprese tradizionali è spaesante e paradossale. Questa nuova pratica ci dice che il fallimento dei propri sistemi non lo si può estromettere del tutto dal tempo né lo si può semplicemente allontanare nel tempo massimizzando la durata tra un fallimento e l’altro (il mean time between failure).

Nessun sistema è perfetto. Neppure si può solo cercare di recuperare il fallimento nel tempo più breve possibile minimizzando il momento della sua riparazione (il mean time to repair). Aggiustare il più velocemente possibile non basta più. Paradossalmente, l’unica via realistica è accelerare e sollecitare con auto-attacchi il tempo del manifestarsi dell’errore.

Lo stesso approccio accade oggi per le pratiche della cybersicurezza a ‘vasetto di miele’ (come dicono i tecnici, honeypot), che invece di essere semplicemente adattiva o responsiva è adescativa. Crea, cioè, le condizioni per l’intrusione malevola lasciando, per esempio, false porte informatiche aperte per adescare gli attaccanti. Per gestire strategicamente l’attacco, devo sollecitarlo. Così, volendo evitarlo, paradossalmente in realtà lo stimolo ad accadere.

Edge ecosystem, nuove relazioni macchina-uomo

Nell’era degli ecosistemi di business a piattaforma, la co-creazione di valore è un processo emergente ed esperienziale in cui attori economici diversi – umani e macchine – automaticamente e contestualmente integrano e scambiano servizi e risorse di varia natura, tangibili quanto intangibili.

Amazon, Alibaba e molti altri funzionano come ecosistemi di servizio. Sfruttando le economie di scala degli effetti di Rete (network effect), queste architetture di business a piattaforma orchestrano dinamicamente le interazioni economiche di clienti, fornitori, sviluppatori, parti terze e così via.

Pensiamo anche ad Airbnb. Una delle strategie competitive per ‘operazionalizzare’ in automatico questa apertura all’integrazione di risorse e allo scambio di servizi tra aziende è la gestione delle interfacce di programmazione applicativa (API management). Sono applicazioni che consentono di scambiare informazioni e funzionalità tra le imprese.

Per esempio, quando si vogliono usare le mappe di Google sul proprio sito, si accede a quei dati in virtù delle interfacce di scambio messe a disposizione dal motore di ricerca. Dall’interoperabilità tra sistemi alla monetizzabilità dei dati, questo paradigma di apertura dei confini delle imprese all’esterno ha visto storicamente vari approcci: dai programmi di chiamata di procedura remota alle architetture orientate al servizio o al modello risorse-centrico, fino alle più contemporanee e nuove interfacce di scambio come i contratti smart su Blockchain.

Così, sempre più i confini tradizionali delle imprese vengono disarticolati e resi porosi entro ecosistemi più vasti governati in modi nuovi. Per questo, è urgente un’esplorazione filosofica e strategica della nuova natura dell’impresa e del senso di queste risorse che scardinano i confini tradizionali (boundary resource). E non sono solo le interfacce, ma anche i programmi di sviluppo software (Skd) o le applicazioni decentralizzate su Blockchain (Dapp).

Importanti anche e sempre più nella prospettiva delle strategie paradossali di coopetizione che bilanciano collaborazione e competizione tra aziende al fine di allargare l’ampiezza del perimetro di business dei mercati da spartirsi poi.

Architecture observability per il tracciamento dei servizi distribuiti

Il tracciamento distribuito (distributed tracing) è, indubbiamente, un tema tecnologico chiave quando le aziende passano dal monitoraggio delle vecchie architetture informatiche monolitiche all’osservabilità delle contemporanee ecologie di microservizi distribuiti e automatizzati. Per esempio, poter osservare e misurare una transazione economica di un servizio di ecommerce per valutarne le performance operative.

Tuttavia, chiediamoci, se e quanto e come è osservabile un’attività di business che emerge e vive tra architetture, piattaforme e applicazioni sparse? L’osservabilità di un’architettura di rete distribuita è tecnicamente e materialmente sempre più difficoltosa. Di fatto, l’operazione di osservazione di cosa sta accadendo in un sistema di business distribuito esaminando le risultanze del sistema stesso (la sua observability) sta crescendo in complessità.

Per questo, per esempio, in Uber gli ingegneri hanno dovuto re-immaginare e riprogettare il sistema di tracciamento e di metriche dei loro 2.400 microservizi. Infatti, il semplice gesto di un cliente che clicca sulla loro App, attiva una ‘transazione distribuita’ che richiede l’azione congiunta di dozzine di microservizi differenti sparsi in Rete per poter essere soddisfatta. Se qualcuno di questi fallisce, non è facile capire dove e perché.

Occorre monitorare Reti sparse e addensate tanto quanto reti fisiche e virtualizzate (analisi multipercorso o multipathing) oppure monitorare i microservizi per i quali è sempre più sfuggente individuare il nodo finale di una comunicazione in rete (end-point).

Tutto questo non è solo difficile per questioni tecniche. Aggiungerei anche filosoficamente. Perché, a ben guardare, l’osservazione di un evento distribuito è, al contempo, un evento distribuito di osservazione. E dunque, fare business e operational intelligence dei servizi distribuiti richiede strategicamente nuove capacità di analisi e nuovi strumenti teorici. Perché non è solo un contesto più complesso dell’osservare, ma è proprio un modo nuovo dell’osservare i mercati.

In conclusione, allora, in un’economia automatizzata l’emergere di nuove tecnicalità e operatività di business richiede di necessità l’apertura della cultura d’impresa a nuove dimensioni del pensiero strategico. Per incrociare nuovamente e culturalmente tecnologia, business e management.