Natività, liminalità, caoticità, osservabilità (Accoto 2020)

La gestione contemporanea dell’economia della macchina sempre più sollecita le culture d’impresa ad immergersi dentro le molte, nuove e diverse dimensioni dell’automazione. In particolare, l’automazione presente e prossima sta emergendo all’incrocio di tre stratificazioni ingegneristiche: è meccanica, è algoritmica, è protocologica. O -con altra e parallela qualificazione- è macchinale, è computazionale, è istituzionale. L’ho anche connotata, in un’espressione sintetica e semplice, come l’automazione delle 3 M ovvero: mani, menti, mercati. Dunque, in ragione dell’attivazione dell’operatività fisica e sensorimotoria degli automi, della capacità computazionale e di apprendimento degli algoritmi, della dinamicità degli scambi di servizi attraverso protocolli decentralizzanti, il mondo ex machina si arricchisce di tecnicalità di frontiera su cui va esercitato un pensiero strategico e manageriale sempre più sofisticato. In questa prospettiva, propongo qui una prima e breve esplorazione su quattro orizzonti: cloud nativity, edge ecosystem, chaos engineering, architecture observability.

La nuvola nativa (cloud nativity)

Le metafore metereologiche e geografiche della computazione si sono ampliate negli ultimi decenni. Per affrontare criticità architetturali come riservatezza, latenza, sicurezza, connessione ed efficienza, le risorse computazionali a disposizione delle imprese e del business si sono stratificate nel tempo e localizzate nello spazio. Operano su livelli sovrapposti e interconnessi dai nomi evocativi. Così, cloud computing, fog computing, edge computing mappano, oggi, figurativamente i dove della computazione, le sue locazioni: sulla nuvola (servizi e applicazioni in cloud), nella nebbia (sfruttando i fog gateway intermedi) o al margine del mondo (dentro i nodi dell’internet delle cose). C’è, dunque, una topologia e molte topologie per in-formare il mondo, una geografia e anzi più geografie del processare l’informazione, una e molteplici spazialità dove l’intelligenza dei mercati e delle imprese si incorpora. Queste metafore locative non devono però trarci in inganno. Perché queste diverse “collocazioni” (luoghi) della computazione sono anzitutto e soprattutto “configurazioni” (modi) della computazione. Non è, dunque, primariamente una questione di “dove” sono i server, ma del “come” possiamo progettare servizi e valore in modalità nuove per clienti, consumatori, colleghi e partner. Per questo, la nuvolo-natività (cloud nativity) è altra cosa dal trasferimento sic et simpliciter di preesistenti applicazioni e servizi sulla nuvola come erroneamente pensano ancora molte imprese. Non basta cioè semplicemente spostare in cloud il business esistente per beneficiare delle potenzialità della nuvola (negoziando ovviamente le sue vulnerabilità). Deve essere piuttosto l’occasione per immaginare e creare nuovo valore nativamente orientato. Un business migrante sulla nuvola è cosa diversa da un business nativo della nuvola. Lo stesso si può dire per la computazione al margine del mondo (edge computing) propria dell’internet delle cose. La computazione incarnata dai sensori e dagli attuatori dei nodi di edge e abilitata dai dispositivi di collegamento intermedio dei fog gateway non è semplicemente una diversa località dove processare l’informazione. Filosoficamente, questa computazione spazializzata e automatizzata è più un nuovo modo d’essere del mondo che un luogo da cui calcolare il mondo. Dunque, strategicamente e managerialmente, più una questione ontologica che topologica.

 L’impresa sconfinante (edge ecosystem) 

 Nell’era degli ecosistemi di servizio a piattaforma, la cocreazione di valore è un processo catallattico (di scambio) emergente ed esperienziale a forte interdipendenza. In questi ambienti, attori economici anche estremamente eterogenei – umani e non umani – automaticamente e contestualmente mobilitano e integrano risorse di varia natura (operanti e operande, tangibili quanto intangibili). Sfruttando le capacità di scala degli effetti di rete (network effects lato domanda e non solo lato offerta, same-side e cross-side), queste ecologie generative di business stimolano e orchestrano interazioni multilaterali. Lo fanno in virtù di regole di governance non esclusivamente contrattuali (come accade invece con reti, partner o catene di fornitura). Una delle strategie competitive per rendere operativa questa apertura ecotecnica delle imprese all’integrazione di risorse e allo scambio di servizi è la gestione delle interfacce di programmazione applicativa (API management). Amazon ne è un esempio emblematico. Il paradigma dello sconfinamento d’impresa ha visto storicamente vari approcci: dai programmi di chiamata di procedura remota alle architetture orientate al servizio al modello risorse-centrico e leggero. Fino alle più contemporanee e nuove interfacce di ‘contrattazione’ applicativa (o application contracting interfaces secondo Lauslahti e non più solo application programming interfaces) vale a dire gli smart contracts su architetture e piattaforme blockchain. Molti gli obiettivi dello sconfinamento: interoperabilità, produttività, monetizzabilità per citare i principali. A fronte di queste opportunità, un’esplorazione strategica della liminalità d’impresa è allora sempre più rilevante. In particolare, è rilevante l’analisi delle ‘risorse di confine’ (boundary resources): non solo per l’appunto le API, ma anche i SKD (software kit development), gli IDE (integrated development environment) e DAPP (decentralized application). Sono tutte modalità con cui l’impresa sconfina dal perimetro delle sue infostrutture per aprirsi allo scambio multilaterale e all’integrazione di risorse esterne. Pensiamo anche alle recenti direttive di PSD2 per le banche. Un orizzonte sempre più rilevante anche nella prospettiva dello sviluppo di strategie di “coopetizione” che hanno lo scopo di bilanciare dinamicamente collaborazione e competizione. In queste ecologie, le imprese hanno la possibilità inoltre di immaginare ‘esperimenti di business’ e di fare sperimentazione spinta di modelli e servizi.

 Il caos evocato (chaos engineering)

 Tecnicamente, con l’espressione chaos engineering si individua l’idea e la pratica ingegneristica di attaccare intenzionalmente, preventivamente e sempre più automaticamente le proprie architetture informatiche (e di business). La finalità è quella di poter conoscere e testare sicurezza, consistenza e resilienza delle proprie infrastrutture/infostrutture. Con questo obiettivo, si pianifica e si attua l’iniezione deliberata e arrischiata di caos entropico nei sistemi mentre sono in effettiva produzione, non in ambienti di prova o di sviluppo come avviene di solito. Così fanno, ad esempio, i chaos engineers di Netflix e di molte grandi piattaforme digitali cercando deliberatamente di far fallire l’erogazione. Questa esplorazione sperimentale stressante è in grado di individuare preventivamente punti di debolezza, insospettabili criticità operative, interruzioni o fallimenti del servizio ai clienti. Tuttavia, filosoficamente, il passaggio di paradigma per le imprese tradizionali è spaesante e paradossale quantomeno rispetto alla gestione più classica di rischi e vulnerabilità. Significa, infatti, che il fallimento 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 o MTBF nel linguaggio tecnico). 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 o MTTR per i tecnici). Paradossalmente, allora, l’unica via agibile per non farlo accadere è farlo accadere. Quanto prima. Sollecitando cioè strategicamente il tempo del suo manifestarsi. Questa prospettiva non riguarda solo la verifica della tenuta dei sistemi rispetto a fallibilità endogene e nascoste delle proprie architetture. Architetture divenute sempre più complesse, intricate e impossibili da conoscere nelle sole fasi di design, progettazione e realizzazione. Vale anche per vulnerabilità da fattori esterni a cui rispondere con strategie adeguate. Così come accade ad esempio anche per le pratiche della cybersicurezza a “vasetto di miele” (come dicono gli esperti, honeypot). Queste ultime invece di essere solo adattive o responsive sono adescative. La cybersicurezza per adescamento degli attacchi (non solo per intercettamento degli attacchi) crea, cioè, le condizioni per l’intrusione malevola lasciando, ad esempio, false porte informatiche aperte per attirare e invogliare gli attaccanti. Per gestire l’attacco, devo strategicamente sollecitarlo ed evocarlo.

 L’osservazione sparsa (architecture observability)

 Il tracciamento distribuito (distributed tracing) è, indubbiamente, un tema tecnologico chiave nel passare dal monitoraggio delle vecchie architetture informatiche monolitiche all’osservabilità delle contemporanee ecologie di microservizi distribuiti e automatizzati. Il passaggio dal monolite al microservizio è rilevante al fine di incrementare l’autonomia dei team di sviluppo, ridurre il time to market delle soluzioni, scalare nei costi e nelle risorse l’efficienza o aumentare robustezza e resilienza del sistema. Ma aumenta la complessità della business intelligence. Ad esempio, poter osservare e misurare una transazione economica di un servizio di mobilità on demand per valutarne le performance operative. Tuttavia, chiediamoci, se e quanto e come è osservabile un’attività di business che emerge tra architetture, piattaforme e applicazioni sparse in rete? L’osservabilità di un’architettura distribuita è tecnicamente e materialmente sempre più difficoltosa. Di fatto, l’operazione di osservazione di cosa sta accadendo in un sistema reticolare esaminando le risultanze del sistema stesso (la sua observability come la chiamano i tecnici) sta crescendo in complessità. Per questo, ad esempio, in Uber gli ingegneri hanno dovuto reimmaginare e riprogettare il sistema di tracciamento e di metriche dei loro 2400 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 (con 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). Ma tutto questo non è solo difficile per le questioni tecniche qui sintetizzate. 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à operative di analisi e nuovi strumenti teorici. Un servizio distribuito non è solo un contesto più complesso dell’osservare, ma è proprio un modo nuovo dell’osservare i mercati.

Mani, menti, mercati (Accoto 2019)

[libro] Felice di essere tra gli autori del volume “Il primato delle tecnologie” curato da Carlo Bordoni, sociologo di fama, collaboratore e coautore di Zygmunt Bauman. Il mio saggio “Mani, Menti, Mercati” è in apertura del volume pubblicato da Mimesis nella collana Il Caffè dei Filosofi e disponibile prossimamente. Un grazie al curatore per l’interesse nei confronti della mia esplorazione culturale e per l’invito a questo dialogo a più voci e visioni

3E Model (Exchange-Edge-Ecosystem, Accoto 2019 in progress)

[draft] mapping and collapsing a first set of current theoretical viewpoints and key strategic concepts toward a triple E perspective (“exchange-edge-ecosystem”, Accoto 2019 work in progress)

Una prima collezione concettuale a partire da tre rilevanti prospettive strategiche contemporanee (service-dominant logic, platform business thinking, coopetitive game theory). In un orizzonte strategico che possiamo caratterizzare con le tre E di “exchanges, edges, ecosystems”, il focus esplorativo di questa preliminare mappatura è sui processi di catallassi (dinamiche di scambio di servizi), sulle pratiche della liminalità (dinamiche di sconfinamento tra imprese) e sulle tensioni coopetitive (dinamiche di competizione-collaborazione dentro l’ecosistema). Dall’apertura sollecitata dalle direttive regolatorie alla decentralizzazione promossa dai criptosistemi, è un’esplorazione manageriale e di business sempre più urgente e rilevante (Accoto 2020 work in progress)