idea 39

L’ARCHITETTURA È LA STRATEGIA PER IL BUSINESS

Ottieni successi grazie alla tecnologia e all’architettura

L’architettura non è un business basato sull’ispirazione, è una procedura razionale per realizzare oggetti che hanno senso e, si spera, bellissimi. Tutto qui.

—Harry Seidler

La Winchester Mystery House, ubicata a San Jose, è stata costruita dalla vedova del fondatore di un’azienda che produce armi da fuoco, William Winchester. Sebbene abbia qualcosa come 160 stanze, le mancava qualcosa di fondamentale: una pianificazione. La casa è stata costruita senza l’ausilio di un architetto e la vedova Winchester si è limitata ad aggiungere parti a casaccio allo stabile. Il risultato è che ci sono parecchie stranezze, come porte e scale che non portano da nessuna parte, finestre che si affacciano su altre stanze e scale con gradini dalle misure bizzarre.¹ Non ti sembra l’architettura delle tue tecnologie e dei tuoi dati?

Ho lavorato per molte aziende occupandomi di come si incastrano la strategia di business e le strutture tecnologiche. La più grande sfida e frustrazione per la maggior parte dei CEO è che per fare piccole modifiche che portano valore al business “ci vuole troppo tempo e costa troppo”. La maggior parte del budget IT è usato per far funzionare i sistemi esistenti, non per realizzare nuove funzionalità. Spesso mi riferisco a queste infrastrutture IT indicandole come la “Winchester Mystery House”, cioè un mucchio di applicazioni e di interfacce e una totale assenza di una pianificazione o di un’architettura. Ti accorgerai velocemente di quanto sono rigide e inadeguate quando vorrai apportare rapidamente dei cambiamenti, aggiungere delle funzionalità o scalare.

Come si arriva a una soluzione? Prima di tutto, devi capire per quali tipi di utenza stai progettando la tua soluzione e quali problemi andrà a risolvere. Fai una lista dei “requisiti”, poi trova il modo più veloce per offrire questa soluzione: questa viene definita la “point solution”.

Si tratta di un espediente, potenzialmente una scelta miope per realizzare la tua tecnologia, ma con così tante necessità da soddisfare, la scelta di cercare la via più veloce è comprensibile. Le persone che lavorano in ambito tecnologico sono note per gli approcci veloci, alla buona, ma le architetture tecnologiche, come lo sviluppo di software, interfacce, API e infrastruttura di rete, sono una cosa differente. Se ti limiti alla point solution, stai solo costruendo un’altra stanza della Winchester Mystery House, senza pensare minimamente al design. Senza una visione, ci sono due aspetti per i quali non sarai preparato: le cose che vanno male e il domani.

OTTIENI LE “ITÀ” CON LA TUA ARCHITETTURA

Paul Tarmen, amico ed ex collega in Alverez and Marsal, è una delle migliori menti che conosco nel campo delle architetture tecnologiche. Mi disse che l’architettura tecnologica deve garantire delle “-ità”. Cosa? Il suffisso –ità implica che “denotano una qualità o una condizione”. Quali sono le qualità e le condizioni, le -ità, che idealmente devono essere tenute in considerazione quando si parla di dati e tecnologia?

•   Scalabil-ità: La possibilità di incrementare o diminuire velocemente la capacità massima del sistema.

•   Inviolabil-ità: Tieni fuori ciò che va tenuto fuori, tieni all’interno ciò che non vuoi che vada all’esterno. Non è forse questa la sicurezza, l’inviolabilità? Il concetto di sicurezza è stato affrontato nell’Idea 36.

•   Flessibili-ità: Flessibili e adattabili ai vari scenari di utilizzo, alle varie aree geografiche, capaci di soddisfare le esigenze anche con requisiti variabili.

•   Interoperabil-ità: Integrazione e interazione con altri tipi di tecnologia, in particolare con soluzioni di diversi produttori e con sistemi esterni. Le API sono uno dei modi per garantire l’interoperabilità dei dati e dei processi all’interno dell’azienda e con altre aziende.

•   Misurabil-ità: Gli strumenti per monitorare la capacità del tuo sistema, così da identificare, riportare e anche prevedere come stanno funzionando i processi e quando potrebbero verificarsi problemi o criticità. Questo può aiutare sia le operazioni del reparto IT, sia i processi di business che dipendono dalle misurazioni, come la fatturazione o i conti lavorazione.

•   Usabil-ità: La semplicità di utilizzo e l’intuitività delle interazioni fra gli utenti e i sistemi; praticamente, l’ergonomia e l’interfaccia utente. L’usabilità fa riferimento anche alla capacità della tecnologia di adattarsi alle condizioni ambientali e operative.

•   Traccabil-ità: La capacità di tracciare, verificare e spiegare come sono avvenute le transazioni, le decisioni e i processi. La “riconciliazione” non è sexy, ma a causa dello Sarbanes-Oxley e di altri requisiti legali, la capacità di mostrare i vari passaggi da un settore all’altro dell’impresa, spesso visti da una prospettiva cash-to-cash, con la capacità di dimostrare che tutte le transazioni sono avvenute come previsto, rappresenta l’essenza del “controllo”. Con l’aumentare dell’automazione e dell’utilizzo del machine learning, uno degli aspetti della tracciabil-ità è il garantire la trasparenza e dimostrare come sono state prese le decisioni.

•   Estensibil-ità: La capacità essenziale di essere in grado di garantire le future esigenze di business con costi, tempi e sforzi ridotti al minimo.

•   Riusabil-ità: Un aspetto dell’estensibilità, cioè la capacità di utilizzare la stessa tecnologia per differenti scopi. La modularità, lo sviluppo object-oriented e un adeguato livello di astrazione sono tutti esempi di approcci adeguati a garantire la riusabil-ità.

•   Integr-ità: Nelle architetture distribuite, quando i dati e la tecnologia sono gestiti da differenti data center, molteplici ambienti cloud e dislocati in varie zone geografiche, l’estensibil-ità garantisce consistenza e affidabilità, in particolare quando i dati devono essere precisi. Il classico esempio di una “transazione atomica”, nel quale se tutti gli aspetti di una transazione non sono correttamente registrati in un database distribuito questa viene cancellata, è stato migliorato con il concetto di “eventual consistency”, nel quale i valori di un dato sono correttamente riportati per ogni versione del dato stesso.

•   Modular-ità: Creare funzionalità ben definite e separate dalle altre all’interno di un software. Una soluzione solitamente è composta da numerosi moduli di servizio. Una delle strategie di Amazon è far sì che i servizi modulari siano “self-service”: significa che per utilizzare una funzione, non deve essere necessario parlare con qualcuno per comprenderla, progettarla, testarla, implementarla o gestirla. Questo aiuta a far scalare non solo la tecnologia, ma l’intera azienda.

•   Qual-ità: Quanto un sistema si comporta come ci si aspetta. Nell’ambito tecnologico, comprende la possibilità di testare, verificare e gestire con semplicità le varie versioni del software e di risolvere in maniera efficace i bug.

•   Stabil-ità: La capacità di adattarsi a nuovi requisiti e dinamiche senza influenzare l’architettura. La chiave per ottenere stabilità è una corretta astrazione. Quando si parla di computer, reti e data center, la stabil-ità si ottiene grazie alla ridondanza, al failover e alle strategie di disaster recovery.

•   Disponibil-ità: La capacità di reagire immediatamente. Come dicono spesso gli analisti dell’ESPN quando parlano di atleti e infortuni nel football, “la miglior competenza è la disponibilità”. Nel mondo del retail, se un prodotto non è disponibile, avrai perso un ordine, spesso addirittura un cliente. Nel mondo della tecnologia non è molto differente. I sistemi devono essere disponibili e garantire i tempi di risposta richiesti dagli utenti e dal business. I sistemi Near-real-time (NRT), nei quali la latenza è trascurabile, sono fondamentali per abilitare varie esperienze digitali e non sono né economici né semplici da usare.

AIUTAMI AD AIUTARTI

Chi può dimenticare quella scena di Jerry Maguire nella quale l’agente sportivo parla a cuore aperto negli spogliatoi con il suo giocatore, Rod Sterling, al termine dell’incontro? L’agente supplica il giocatore di fare qualcosa di diverso, in modo che il team possa rinnovargli il contratto. “Aiutami ad aiutarti”, prega Maguire. Quante volte gli imprenditori semplicemente si girano verso i tecnici dicendo: “È un problema vostro, nerd”? Se vuoi avere successo nell’era digitale, è fondamentale essere un valido business partner del tuo team di tecnici (e riferirsi a loro col termine “nerd” probabilmente non aiuta, nel caso li chiami così). Qual è il tuo ruolo in qualità di business partner del tuo team di tecnici? Prima di tutto, considera tutti questi elementi e lavora per stabilire quali sono le metriche necessarie e come misurarle dal punto di vista del business. Approfondisci lo scenario di utilizzo e specifica con precisione come deve funzionare. In secondo luogo, concentrati sul lungo termine. Devi voler avviare la realizzazione di queste funzionalità fondamentali. Terzo, ed è qui che la tua architettura diventa la tua strategia, vai all’attacco.

Comprendi come saranno concepite le -ità e valuta i compromessi, scopri come usare queste -ità come elementi da offrire ai tuoi clienti e per differenziarti dalla concorrenza. Se riesci a dimostrare al mercato che queste funzionalità ti rendono migliore dei tuoi concorrenti e a dimostrare perché è importante per i tuoi clienti, allora i fondi per le -ità possono essere spostati dalla colonna dei costi fissi a quella dei costi diretti. I costi diretti, chiamati anche “cost of good sold” (COGS), sono i costi direttamente associati alla produzione di ricavi. L’architettura sta diventando il business.

IL MANIFESTO DELLE API DI BEZOS

Lavoravo in Amazon durante una delle sue svolte. Nel 1999, Barron ha strillato in copertina l’articolo “Amazon.bomb”, nel quale si sosteneva che le azioni di Amazon avrebbero fatto la stessa fine di quelle di Pets.com e Drugstore.com.² Invece di finire in disastro, Amazon ha ottenuto la fiducia del mercato ed è cresciuta sino a diventare uno dei “Four Horsemen of Tech”.³ Non è passato molto tempo dall’articolo di Bannon prima che comprendessimo che Amazon incarnava due tipi di business.

Come prima cosa, eravamo un grande negozio di e-commerce multicategoria. Ai tempi, ero responsabile del Marketplace o, come lo chiamavano, del business “Merchant @”. M@ era di importanza critica nella creazione del “negozio di tutto”. Usando la piattaforma M@, ci siamo aperti a 14 categorie, come abbigliamento, accessori sportivi, strumenti musicali, gourmet e gioielleria.

Eppure, è stato durante questo periodo che Amazon ha iniziato a pensare a se stessa come a una piattaforma, un’azienda che offriva servizi ad altre imprese, oltre a fare il retailer. Decidemmo che tutti i sistemi dovevano essere interoperabili, sia internamente sia esternamente, attraverso delle API. Queste API dovevano essere interfacce robuste, cioè dovevano essere ben architettate, non dovevano venire modificate improvvisamente e dovevano essere compatibili con future evoluzioni del sistema. Le API dovevano avere degli SLA per poterle confrontare con gli standard di velocità e disponibilità e gli SLA dovevano essere fault tolerant, cioè dovevano tenere conto del fatto che altre dipendenze avrebbero potuto non funzionare o degradare. Nonostante questo, le API dovevano funzionare anche quando altre componenti del sistema mostravano problemi.

Come ogni grande cambiamento, la sfida tecnologica era ardua, ma la vera difficoltà era quella di coinvolgere le persone, farle andare tutte nella stessa direzione. Nel suo tipico stile, Bezos ha portato dalla montagna un memo con 10 comandamenti.

Steve Yegge, un ex ingegnere di Amazon, cita questo memo in un post sul suo blog:

La sua Grande Missione deve seguire questi principi:

1.   Tutti i team d’ora in poi condivideranno i loro dati e le loro funzionalità attraverso delle service interface.

2.   I team devono comunicare fra loro tramite queste interfacce.

3.   Non sarà permessa alcun’altra forma di comunicazione: no ai link diretti, non si accederà in maniera diretta ai dati degli altri team, non ci saranno modelli di memoria condivisa e non ci sarà alcun tipo di porta di servizio. L’unica forma di comunicazione ammessa passa per le service interface.

4.   Non importa quale tecnologia viene usata: http, Corba, Pubsub, protocolli proprietari, non conta. A Bezos non interessa.

5.   Tutte le service interface, senza alcuna eccezione, devono essere sviluppate per essere esternalizzate. Per capirci, i team devono sviluppare queste interfacce tenendo a mente che potranno essere aperte al mondo esterno. Senza alcuna eccezione.

6.   Chiunque non seguirà queste regole, verrà licenziato.

7.   Grazie, vi auguro una buona giornata!

Ecco! I 150 ex dipendenti di Amazon che mi stanno leggendo sicuramente avranno capito che il punto 7 è un piccolo scherzo, dato che a Bezos non interessa assolutamente nulla di come sarà la tua giornata.

Il punto numero 6, però, era reale e le persone si sono messe al lavoro. Bezos ha assegnato a un paio di Chief Bulldog il compito di supervisionare i lavori e garantire progressi, un team capitanato dall’Uber-Chief Bear Bulldog Rick Dalzell. Rick è un ex ranger dell’esercito, laureato alla West Point Academy, ex-boxer, ex-Capo Torturatore/CIO di Walmart, ed è un uomo grosso, geniale e spaventoso che pronuncia spesso la parola “hardened interface”. Rick stesso era una hardened interface su due gambe, quindi, inutile dirlo, tutti hanno fatto moltissimi progressi, assicurandosi che Rick ne fosse a conoscenza.⁴

Grazie alla sua architettura, Amazon è stata in grado di scalare sia l’organizzazione interna sia il modello di business. A oggi Amazon ha centinaia di API pubbliche, da quelle relative ai prodotti alle API di AWS, le API di Echo, le API dei centri di smistamento che gestiscono il servizio Fullfillment di Amazon.

INVESTI MAGGIORMENTE IN SOFTWARE CUSTOM

Il periodo che va dagli anni 80 ai primi 2000 è stato dominato dalla guerra degli ERP. Le aziende si affannavano per implementare SAP, Oracle, PeopleSoft e altri software che si rivelavano ottimi nello standardizzare pratiche di business come la produzione, la gestione degli ordini, le risorse umane, le finanze. Per quanto questi sistemi aiutassero a scalare e a migliorare i processi, nella maggior parte dei casi non erano in grado di cambiare l’essenza del modello di business.

Ora che la tecnologia e la digitalizzazione di prodotti, servizi ed esperienze diventa sempre più importante, realizzare software proprietario è una delle più importanti decisioni di business che si possono prendere. Non permettere al CIO di prendere decisioni, ma fai in modo che vi contribuisca. Il Wall Street Journal fa notare che “i dati suggeriscono che il segreto del successo dei vari Amazon, Google e Facebook, per non citare Walmart, CVS e UPS che sono arrivati prima di loro, è legato ai loro investimenti tecnologici… L’investimento IT per assumere sviluppatori e realizzare software usato esclusivamente dall’azienda rappresenta un grande vantaggio competitivo. Si differenzia dalle nostre conoscenze classiche di R&D per il fatto che questo software è usato unicamente dall’azienda e non fa parte dei prodotti sviluppati per i clienti”.⁵

La tua architettura si basa su numerose tecnologie, ma è il software che abilita le logiche di business e la customer experience, e richiede una serie di decisioni strategiche, soprattutto quando sono necessari ulteriori sviluppi.

ORA TOCCA A TE, DEDICACI TUTTO IL TEMPO POSSIBILE

Probabilmente non sei il technical architect, lo sviluppatore software o il CIO dell’azienda. In qualità di leader, con la responsabilità di portare avanti il business, devi essere curioso e comprendere gli aspetti fondamentali di queste tecnologie. Tutti devono migliorare le proprie competenze tecnologiche in una trasformazione digitale: discuti con il tuo team tecnico su cosa è importante per te, assicurati che siano abilitate metriche e SLA, così da verificare se stai raggiungendo le performance desiderate.

Se all’interno della tua azienda fai sì che le linee fra le “discussioni di business” e le “discussioni tecnologiche” siano sfumate, avrai segnato la strada verso la trasformazione digitale. Quando affronti una discussione, un ottimo modo di iniziare è dalle domande.