Le insidie nascoste nella scelta dello stack tecnologico: una guida per i CTO

Il tasso di fallimento dei progetti tecnologici aziendali è piuttosto sorprendente, dato che circa il 70% di essi non ha successo a causa di scelte sbagliate in termini di stack. I leader tecnologici sono solitamente attratti dalle nuove architetture e dagli strumenti all'avanguardia, ma tali decisioni spesso comportano un elevato debito tecnico e costose riscritture del sistema. Gli errori più comuni sono quelli che ci si aspetta: concentrarsi sulle tecnologie di moda invece che sull'allineamento aziendale, ignorare la necessità di manutenzione nel tempo e scegliere strumenti che non vanno bene per le competenze del team. Questi passi falsi portano a costose modifiche, rallentamenti nelle prestazioni e team di sviluppo demotivati. L'analisi mostra casi reali in cui i progetti sono andati a monte per decisioni sbagliate sulla tecnologia e spiega perché la tecnologia ha fallito. Usando casi pratici, offriamo dei modelli che possono aiutare i leader tecnologici a prendere decisioni informate che servono agli obiettivi dell'azienda, sfruttano i punti di forza del team e permettono una crescita sostenibile.

I dirigenti del settore tecnologico finiscono spesso in trappole che compromettono le loro scelte in materia di stack. Le nuove tecnologie sono un argomento di discussione che di solito offusca la visione degli impatti a lungo termine e le questioni relative all'implementazione pratica. Il debito tecnico è cumulativo, nel senso che non c'è alcun segnale che avverta che un'organizzazione si trova in una trappola finanziaria costituita da sistemi costosi e inefficienti che ostacolano invece di sostenere la crescita aziendale.

Il fascino delle tecnologie di tendenza

I CTO di solito scelgono tecnologie che vanno di moda nel settore e non quelle che servono davvero. Questo crea un bel divario tra quello che serve all'azienda e quello che è tecnicamente possibile. L'attrattiva delle nuove strutture spesso prende il posto di una valutazione pratica. La convalida sociale si rivela essere un sostituto dannoso del processo decisionale basato su prove concrete. Le organizzazioni seguono le ultime tecnologie a causa della pressione di apparire alla moda come tutti gli altri e perché tale iniziativa è ambiziosa e allettante. Il risultato di questa mentalità gregaria è l'introduzione di soluzioni complicate che richiedono un sacco di soluzioni alternative e manutenzione aggiuntiva.

Manutenzione non dichiarata Conclusione

Le aziende spesso non vedono il quadro completo degli investimenti tecnologici, nel senso che lo sviluppo iniziale non è la fine. L'analisi del software aziendale mostra che, nei codici di grandi dimensioni, la manutenzione richiede circa il 75% dello sforzo totale. Questo carico continuo comporta:

• Test
• Individuazione e correzione dei bug
• Ottimizzazione delle prestazioni
• Test di compatibilità
• Rifattorizzazione
• Servizio clienti
• Documentazione

Gli abbonamenti software possono portare a costi nascosti. Anche se all'inizio non sembrano costosi, alla lunga possono diventare un problema, soprattutto se il team cresce e servono più licenze. Le funzioni premium, l'assistenza e gli aggiornamenti dello spazio di archiviazione spesso hanno costi nascosti che non si notano subito.

Disallineamento delle capacità del team

L'allineamento delle competenze del team è uno degli aspetti importanti da tenere in considerazione quando si sceglie la tecnologia. Quando si sviluppano nuove strutture, le organizzazioni tendono a scegliere i framework senza valutare i loro sviluppatori per capire quanta esperienza hanno nel processo di implementazione e manutenzione. I team che sviluppano con tecnologie che non conoscono bene devono affrontare:

• Curve di apprendimento ripide
• Cicli di sviluppo più lenti
• Tassi di difetti più alti
• Implementazione di scarsa qualità

La leadership può essere un po' tecnica e tendere a pensare che le specifiche tecniche costino troppo, mentre sottovaluta quanto può costare la formazione, quanto può essere complicato l'inserimento e quanto si può perdere in termini di produttività. Gli strumenti che non vanno bene con le capacità del team portano a un'adozione scarsa e a un ritorno sull'investimento basso. Pensa alla scelta di Ruby on Rails: spesso viene scelto per la sua velocità di sviluppo, la sua semplicità e l'ampia varietà di librerie che aiutano nella prototipazione rapida. Questi vantaggi, però, si realizzano solo quando i team hanno già una conoscenza di Ruby. La curva di apprendimento deve essere in linea con le competenze degli sviluppatori, in modo che non ci siano rallentamenti nella produttività. Un aggiornamento forzato delle competenze a metà progetto può rovinare i risultati ottenuti.

Quando i progetti tecnologici falliscono, abbiamo analizzato casi di studio in diversi settori e aziende di varie dimensioni per capire i motivi. Entrambe le organizzazioni hanno avuto grossi problemi tecnici che possono essere collegati direttamente alle decisioni relative allo stack tecnologico. Le cause principali si sono rivelate sorprendentemente simili, tra architetture troppo complicate, problemi di prestazioni e problemi di scalabilità. In questa sezione vengono indicati tre casi esemplificativi in cui si verifica un disallineamento tra le decisioni relative allo stack e i requisiti del prodotto o le capacità del team.

La complessità dei microservizi nelle app semplici

Una startup SaaS ha avuto problemi perché ha iniziato a usare i microservizi troppo presto. In più di 18 mesi, l'azienda ha messo insieme un sacco di tecnologie diverse, il che ha portato a discussioni su un sistema frammentato in cui la responsabilità continuava a passare da un membro del team all'altro. All'inizio, questo sistema sembrava una buona idea, dividendo le app in app più piccole che in teoria potevano crescere. Ma, non avendo abbastanza persone esperte o interessate a gestire bene la piattaforma, il sistema è diventato un casino. L'errore principale è stato quello di introdurre un'architettura complicata prima ancora di capire cosa servisse al prodotto. I microservizi sono un modo per gestire la complessità, ma non sono una cosa da prendere alla leggera. Invece di aiutare la crescita, l'approccio dei microservizi si è rivelato un peso per un prodotto che aveva bisogno di iterazioni veloci invece che di sistemi distribuiti. A un certo punto, l'azienda non è riuscita ad aggiungere nuovi campi e usare alcuni trigger API a causa dei limiti della piattaforma, causando problemi alle funzioni principali. La soluzione complessa è stata completamente abbandonata perché i membri del team erano frustrati e hanno iniziato a usare fogli di calcolo invece dello stack troppo elaborato.

Limiti di prestazioni nelle app di gioco

Una società di videogiochi ha provato React Native per creare un gioco mobile ad alte prestazioni, ma questo ha causato problemi tecnici difficili da risolvere per le esperienze con grafica pesante. Anche se React Native ha dei vantaggi nello sviluppo multipiattaforma, in pratica non aveva le capacità per gestire i requisiti super complessi dei giochi. Il team di sviluppo ha scoperto che le prestazioni del thread JavaScript erano compromesse. Nonostante React Native affermi di essere in grado di fornire almeno 60 fotogrammi al secondo, l'app continuava a perdere fotogrammi quando si utilizzavano animazioni e interazioni complesse. La diagnosi delle prestazioni ha mostrato che ogni processo che richiedeva più di 100 ms causava un ritardo per l'utente. Queste limitazioni erano un vero problema per i giochi che avevano bisogno di una fisica o di un rendering più complessi. Il team ha cercato di ottimizzare i moduli nativi, ma la differenza di base tra lo strumento e le esigenze era ancora evidente. Anche se React Native permette di sviluppare su più piattaforme usando un solo set di codici, questo è diventato meno importante quando il prodotto finale non riusciva nemmeno a soddisfare gli standard minimi di performance.

Vulnerabilità di scalabilità dei database nelle app finanziarie

Un'applicazione fintech finanziaria è stata lanciata con un vecchio database SQL monolitico e all'inizio funzionava bene. Ma con l'aumento del volume delle transazioni, il sistema non riusciva più a funzionare e a scalare. La latenza e i ritardi nell'elaborazione in batch rendevano praticamente impossibile l'analisi in tempo reale. L'errore principale del CTO è stato quello di non prevedere le esigenze di scalabilità dell'elaborazione dei dati finanziari. Il database non è stato pensato per supportare:

• Ridimensionamento orizzontale
• Metodi di bilanciamento del carico
• Volumi di transazioni di picco

Le prestazioni sono diventate davvero scarse e il tempo di risposta alla query è aumentato fino a diversi minuti. Questo calo è stato un vero disastro per le app dove la velocità delle transazioni è super importante per l'utente e per le app finanziarie. Dopo aver fatto un sacco di valutazioni tecniche, l'azienda è passata a un database distribuito con architettura HTAP (Hybrid Transactional/Analytical Processing). Questo cambiamento ha permesso di gestire migliaia di transazioni al secondo con bassa latenza e allo stesso tempo fare analisi in tempo reale.

Nei casi di studio, abbiamo visto tre tipi di errori che causano problemi con la tecnologia. Tutti questi errori indicano che c'è qualcosa che non va nel modo in cui le aziende scelgono e usano la tecnologia.

Disallineamento della complessità tecnologico-aziendale

Uno degli errori più comuni nella scelta dello stack tecnologico è quando le aziende finiscono con un'architettura troppo complicata che non va bene per le loro esigenze. Molte aziende hanno diversi livelli e sottosistemi, ognuno dei quali dovrebbe essere il migliore del settore, ma il sistema nel suo insieme è lento, inaffidabile e costoso. Il risultato di questa pratica è:

• Le app vanno più lente a causa di un sacco di livelli
• La cosa si complica con più passaggi di consegne
• Non è affidabile perché ogni livello ha modi diversi di non funzionare

Nel caso delle aziende che lavorano con i clienti, una scelta sbagliata dello stack tecnologico ha un impatto diretto sull'esperienza del cliente, con tempi di caricamento lenti e interruzioni del servizio, che fanno salire il tasso di abbandono.

Debito tecnico e refactoring

Investire troppo presto in una tecnologia sbagliata crea un debito tecnico che diventa sempre più difficile da risolvere. Infatti, la maggior parte dei budget IT delle aziende va alla manutenzione e al supporto del software, e non all'innovazione. Quando le organizzazioni investono un sacco in stack problematici, il costo irrecuperabile può diventare un motivo per non cambiare le cose. Il refactoring deve essere utile e dovrebbe concentrarsi sulle esigenze reali, non sulle speculazioni. Le rifattorizzazioni su larga scala che non possono essere gestite nei normali processi di sviluppo rappresentano una sfida per molte organizzazioni. La ricostruzione degli elementi architetturali fondamentali comporta solitamente la rimozione e la ricreazione delle risorse, esponendo a rischi importanti dati aziendali.

Punti deboli nella documentazione e nell'onboarding

I fallimenti aziendali e le carenze nella documentazione comportano costi nascosti elevati, poiché il processo di inserimento dei nuovi assunti è più lungo del necessario quando le pratiche di documentazione sono carenti. Un sacco di reparti tecnici stanno rimanendo indietro nella creazione di documentazione interna di qualità, ma il costo dell'incoerenza è molto più alto rispetto a quello di integrare la documentazione nei processi. I nuovi membri del team perdono un sacco di tempo a cercare e riscoprire le risposte, oppure fanno errori che potrebbero essere evitati se le informazioni fossero documentate bene. Questo scenario porta a un calo di produttività, con alcuni sviluppatori che non riescono a lavorare bene per settimane o addirittura mesi.

Per evitare le trappole della selezione dello stack, è fondamentale andare oltre l'evitare le parole alla moda. Devi pensare attentamente a quello che stai costruendo, alla persona che lo sta costruendo e al modo in cui il tuo sistema crescerà e si svilupperà.

Definisci l'ambito del prodotto

Prima di confrontare gli strumenti, pensa a cosa vuoi fare e quanto dovrebbe durare il prodotto. È un MVP che si sviluppa in fretta e ha obiettivi a breve termine? O una piattaforma che dovrebbe crescere sempre di più nei prossimi cinque anni? Inoltre, pensa al futuro. Se pensi di integrare, analizzare o aggiungere ruoli utente, scegli uno stack che si adatti a questi scenari senza dover ricostruire tutto da capo.

• Per i prodotti a breve termine, i sistemi di sviluppo veloce (come MEAN o Firebase) ti daranno velocità e flessibilità
• Per i sistemi a lungo termine, concentrati su architetture modulari e facili da gestire che non richiedano grandi riscritture

Sulla carta, uno stack può sembrare perfetto, ma quando nessuno nel tuo team riesce a risolvere i bug in produzione o a ottimizzare lo stack per migliorarne le prestazioni, diventa un problema.

• Scegli tecnologie che i tuoi ingegneri già conoscono bene, nel caso ci sia fretta di consegnare il lavoro
• Pianifica in anticipo l'uso di uno stack compatibile con il futuro, ma dedica del tempo alla verifica del codice, all'onboarding e alla formazione

Considera i requisiti esterni

Le scelte di Stack non vengono fatte nel vuoto. Le esigenze di conformità, budget e integrazione, tra le altre, sono esigenze reali che dovrebbero riflettersi a tutti i livelli della tua architettura. Conformità e sicurezza: nel settore fintech o sanitario, assicurati che il tuo stack sia compatibile con i registri di audit, il controllo degli accessi basato sui ruoli e la crittografia sempre compatibile con le versioni successive. Budget: pensa alle licenze, all'infrastruttura, ai servizi gestiti e ad altri costi nascosti, come usare API di terze parti o anche blocchi. Integrazione: potresti avere problemi se il tuo stack non si integra con altri sistemi. Accumula il flusso di dati in entrata e in uscita.

Misurare la sostenibilità a lungo termine

Quello che oggi sembra sostenibile, domani potrebbe non esserlo più. Cerca:

• Aggiornamenti stabili: gli aggiornamenti instabili o la mancanza di supporto da parte della community possono diventare un problema
• Ecosistema ben documentato e consolidato: questo renderà più facile l'integrazione e ridurrà la dipendenza dalle competenze interne
• Semplicità operativa: quando il tuo stack ha bisogno di modifiche o manutenzione da parte dei devops, potrebbe non essere scalabile per un team piccolo

Prestazioni e complessità operativa

Scegliere uno stack vuol dire fare delle scelte:

• Modello di scalabilità: puoi scalare orizzontalmente aggiungendo più istanze o sei limitato alla scalabilità verticale con un monolite?
• Prestazioni sotto carico: alcuni stack sono più bravi a gestire transazioni in modo leggero e in parallelo (ad esempio Node.js), mentre altri sono più efficaci nell'eseguire transazioni con processori pesanti e transazionali (ad esempio Spring Boot)?
• Complessità operativa: il tuo team lavora in modo affidabile o stai mettendo in atto una soluzione improvvisata che funziona solo a malapena?

Prendi decisioni che aiutano a crescere e non creano problemi tecnici.

Non esiste uno stack a prova di futuro, ma ne esistono di più flessibili. La decisione giusta è quella che va di pari passo con la tua visione aziendale, la missione del prodotto, le competenze del team e le esigenze di scalabilità. Ti permette di crescere velocemente oggi senza diventare un peso in futuro. I CTO più bravi non si limitano a scegliere gli strumenti. Costruiscono sistemi che durano nel tempo.

Costruire lo stack tecnologico è una delle decisioni più importanti che i CTO prendono nella loro carriera. Se fatto bene, lo rende scalabile, performante e in grado di fornire risultati più rapidi. Se gestito male, causerà debiti tecnici, innovazione stagnante e frustrazione nei team di lavoro. Fai attenzione a non prendere decisioni all'inizio che potrebbero bloccarti in futuro. Pensa prima di agire, pianifica e investi in uno stack che si espanda insieme a te. Si tratta di trovare un compromesso tra:

• Esigenze a breve termine e prospettive a lungo termine
• Competenze del team ed esigenze dell'azienda
• Innovazione e sostenibilità

I leader tecnologici possono prendere decisioni strategiche che aiutano lo sviluppo dell'organizzazione invece di ostacolarlo, evitando le insidie e usando strutture strategiche.