Debito tecnico da scalare: evitare il fallimento

Il bivio è la stessa cosa inevitabile che ogni azienda di software di successo deve affrontare. Non si tratta di un MVP mediocre che ha superato il test di adeguatezza al mercato, ma è stato sviluppato un sistema multifunzionale che serve migliaia o milioni di utenti. Ma c'è qualcosa sotto la superficie. Le nuove versioni arrivano lentamente. Ci vogliono settimane per sviluppare semplici modifiche. Il ritmo con cui vengono corretti i bug è più alto di quello con cui vengono risolti i vecchi problemi. Il codice base fa sì che gli ingegneri passino più tempo a lottare che a creare nuove funzionalità. Questo scenario si verifica con una frequenza spaventosa nel mondo della tecnologia. Aziende che sembravano destinate a diventare giganti vengono soffocate dal loro stesso successo iniziale e devono scegliere se rimanere in uno stato di stagnazione indulgente o riprendere il loro sviluppo con costosi sforzi di reingegnerizzazione. I responsabili non sono certo gli sviluppatori o la mancanza di risorse. Piuttosto, le origini risiedono nelle scelte architetturali di base che sono state fatte durante quei fatidici mesi iniziali, quando la velocità di immissione sul mercato era più importante della manutenibilità a lungo termine. Capire come le decisioni tecniche reggono nel tempo è una delle cose più importanti che un leader di un'azienda tecnologica in crescita deve sapere. Le scelte che si fanno oggi possono accelerare la crescita futura o diventare un ostacolo per tutte le altre iniziative. La differenza tra le aziende che crescono e quelle che falliscono spesso sta nel saper usare la giusta architettura al momento giusto.

Ci sono scorciatoie tra il prototipo e il software pronto per la produzione che dovrebbero durare poco ma hanno tempi di recupero molto lunghi. Nelle fasi iniziali, lo sviluppo si concentrerà sulla prototipazione veloce e sulla funzionalità diretta piuttosto che su cose astratte come la modularità o l'estensibilità. Questo metodo è perfettamente logico quando l'obiettivo principale è confermare le ipotesi e cogliere le opportunità di mercato prima che arrivino i concorrenti. Ma queste vittorie tattiche possono creare dei punti deboli strategici. Le architetture monolitiche che sembravano perfette per piccoli gruppi diventano un problema quando le organizzazioni crescono. Gli schemi dei database che all'inizio funzionavano bene diventano difficili da cambiare per supportare nuove funzionalità. Centinaia di sistemi di autenticazione degli utenti crollano sotto il peso di migliaia di utenti. I modelli di integrazione che funzionavano bene con pochi servizi di terze parti diventano ingestibili a causa delle dimensioni dell'ecosistema.

Un'API che non funziona bene può gestire il traffico attuale senza problemi, ma crollerà quando il carico raddoppia. Un codice ben strutturato può aiutare a sviluppare le funzionalità velocemente all'inizio, ma lo sviluppo in parallelo può diventare più difficile quando il team cresce. Le aziende spesso tendono a interpretare male questi sintomi come difficoltà di crescita temporanee e non sistemiche che richiedono una correzione architettonica. La leadership potrebbe credere che un numero maggiore di ingegneri accelererà il processo di sviluppo, solo per rendersi conto che i costi di coordinamento e i conflitti di codice rallentano effettivamente lo sviluppo. I problemi che emergono con le prestazioni vengono affrontati aumentando la potenza dei server invece di migliorare l'efficienza di base. I problemi di sicurezza vengono risolti con una soluzione puntuale piuttosto che con un'analisi approfondita del sistema. Le conseguenze economiche e la portata vanno ben oltre la produttività nell'ingegneria. L'esperienza dei clienti ne risente perché i sistemi sono meno stabili e reattivi. Quando la piattaforma non riesce a soddisfare i potenziali clienti aziendali, si perdono opportunità di vendita. I vantaggi competitivi si riducono perché le funzionalità si sviluppano lentamente. Questo rende più difficile il processo di reclutamento perché gli ingegneri non vogliono lavorare in organizzazioni con problemi tecnici.

Costruire un'architettura modulare

Per sviluppare un'architettura efficace, devi conoscere i principi che aiutano a creare un buon design e i limiti pratici che devi considerare quando decidi se implementare o meno qualcosa. La base parte dalla modularità e dalla separazione dei compiti. I sistemi sviluppati strutturano le funzionalità in elementi distinti, interfacce e responsabilità definite. Questa strategia permette ai team di creare e apportare modifiche o sostituire singole parti senza compromettere l'intero sistema. Le architetture orientate ai servizi sono un buon esempio di questo concetto in generale. Invece di sviluppare applicazioni monolitiche con tutte le funzionalità che usano lo stesso codice base e vengono distribuite in modo simile, le organizzazioni possono suddividere i sistemi in servizi dedicati che interagiscono tramite API coerenti. I servizi sono indipendenti e possono essere sviluppati, testati e distribuiti da team diversi contemporaneamente senza interferire tra loro.

Il trucco sta nel definire contratti distinti tra le varie sezioni del sistema ed evitare un accoppiamento stretto che causi la propagazione dei cambiamenti in tutte le direzioni attraverso il codice.

Considerazioni sull'architettura dei dati

Bisogna stare molto attenti all'architettura dei dati, perché queste decisioni possono diventare le più costose da annullare nel caso dei database. Lo schema di ottimizzazione dei casi d'uso può essere un grosso ostacolo quando i requisiti cambiano. Le aziende che funzionano bene investono in modelli di dati abbastanza flessibili da supportare la crescita senza dover fare migrazioni complete. Potrebbe essere qualcosa del tipo:

• Scegli i database di documenti invece di quelli relazionali in base a quello che ti serve
• Usa una strategia di gestione delle versioni dei dati
• Creare API che nascondono le implementazioni di archiviazione sottostanti

Trovare un equilibrio tra le esigenze attuali e future

I requisiti di scalabilità dovrebbero trovare un equilibrio tra le esigenze attuali e le opportunità future. Quando si progettano soluzioni troppo complesse per problemi che potrebbero anche non presentarsi mai, si sprecano risorse e si complicano le cose più del necessario. Le soluzioni poco elaborate per far fronte alla crescita prevedibile causano un debito tecnico che cresce in modo esponenziale. La soluzione migliore è riconoscere i colli di bottiglia della scalabilità nelle fasi iniziali e implementare un'architettura in grado di scalare con grazia sotto carico.

Osservabilità e sicurezza

L'osservabilità è un altro fattore architettonico fondamentale che di solito non viene preso in considerazione nelle fasi iniziali dello sviluppo. Qualsiasi sistema che non abbia funzioni complete di registrazione, monitoraggio e debug diventa più difficile da mantenere man mano che diventa più complesso. È molto più economico integrare l'osservabilità nell'architettura fin dall'inizio piuttosto che in un secondo momento, ma le esperienze acquisite sono preziose per l'ottimizzazione e la risoluzione dei problemi. Lo stesso vale per l'architettura di sicurezza, che è anche un investimento iniziale. Usare i componenti di base per l'autenticazione, l'autorizzazione e la protezione dei dati ti permette di sviluppare rapidamente le funzionalità senza incorrere in debiti di sicurezza. D'altra parte, l'approccio alla sicurezza come ripensamento tende ad essere costoso da riprogettare nei casi in cui le esigenze di conformità o i modelli di minaccia vengono modificati.

Processo decisionale tecnico

Le aziende che vogliono evitare le trappole architettoniche dovrebbero mettere in atto modelli decisionali tecnici che diano lo stesso peso al ritmo a breve termine e alla resistenza a lungo termine. Questo include:

• Sviluppare procedure di revisione architettonica sulle principali scelte tecniche
• Documentare i compromessi
• Valuta spesso il debito tecnico rispetto alle priorità aziendali

Test e integrazione

Investire nei test automatizzati e nell'integrazione continua è utile perché ti permette di rifattorizzare con sicurezza e fare investimenti nell'architettura. Quando i team riescono a confermare velocemente le modifiche, è più facile che facciano aggiustamenti proattivi invece di rimandare all'infinito la manutenzione. Lo sviluppo parallelo è possibile anche grazie a suite di test complete che individuano i problemi di integrazione in una fase iniziale.

Revisione del codice e condivisione delle conoscenze

Quando si controllano i codici, bisogna vedere sia come influiscono sull'architettura sia se funzionano bene. Se ci si limita a controllare solo la funzionalità immediata, non si riesce a trovare e sistemare i problemi strutturali prima che diventino un problema serio. Per migliorare la qualità delle decisioni in tutta l'organizzazione, si possono formare gli ingegneri a capire e comunicare i compromessi dell'architettura.

Le frequenti presentazioni tecniche e le riunioni sull'architettura aiutano a mantenere una visione comune anche con l'espansione dei team di ingegneri.

Revisioni regolari dell'architettura

Le valutazioni architetturali regolari offrono l'opportunità di prendere le distanze dallo sviluppo quotidiano e analizzare lo stato di salute dei sistemi su scala più ampia. Tali revisioni dovrebbero determinare dove è stato indirizzato il debito tecnico, se le architetture attuali soddisfano le esigenze dell'azienda e cosa si può fare per migliorarle al fine di offrire il massimo rendimento sugli investimenti ingegneristici.

Il processo di crescita dopo l'avvio è destinato a essere un'evoluzione architettonica, ma non deve necessariamente comportare costose riscritture o addirittura un rallentamento dello sviluppo. Le aziende che prendono decisioni architettoniche prudenti fin dall'inizio sono in una posizione migliore per raggiungere la sostenibilità, mentre quelle che trascurano gli aspetti strutturali finiscono spesso per essere sopraffatte dai propri successi. La maggior parte delle aziende tecnologiche che vantano modelli di successo non considerano l'architettura come una decisione, ma come una disciplina continua. Sviluppano sistemi in grado di evolversi con eleganza, investono negli strumenti e nei processi necessari per renderli capaci di cambiamenti sicuri e hanno la conoscenza dell'architettura per fare buoni compromessi quando conta davvero. Il costo della disciplina architettonica è niente in confronto al costo del fallimento tecnico. Capendo che le decisioni prese all'inizio si moltiplicano nel tempo e usando sempre principi architettonici collaudati, le organizzazioni potranno sviluppare software che aumenterà il loro successo a lungo termine. La domanda non è se ci saranno problemi architettonici, ma se verranno notati e risolti prima che diventino problemi che sembrano impossibili da risolvere.