Linguaggi, framework, database, servizi cloud, modelli di intelligenza artificiale: l’offerta di tecnologie cresce ogni anno e ogni scelta ha conseguenze che durano a lungo. Uno stack (l’insieme delle tecnologie con cui è costruita un’applicazione) scelto bene accompagna un prodotto per anni; uno scelto male si paga in manutenzione, sicurezza e costi.
Nei nostri progetti lavoriamo con oltre 60 tecnologie, ma non abbiamo uno stack buono per tutto. Decidiamo caso per caso, seguendo dieci criteri che rendiamo espliciti, così anche il cliente può vedere perché una strada è stata preferita a un’altra.
Partire dal problema
1. Requisiti del progetto
Il primo criterio è il più ovvio e anche il più trascurato: cosa deve fare il sistema, per quanti utenti, con quali vincoli di tempi di risposta, disponibilità e durata. Un gestionale che resterà in uso dieci anni ha esigenze diverse da un prototipo da mostrare tra un mese. Per questo, prima di parlare di tecnologie, mettiamo per iscritto carico atteso, integrazioni, vincoli di sicurezza e dove devono risiedere i dati.
2. Compatibilità e integrazione
Una tecnologia nuova deve convivere con ciò che c’è già: sistemi di accesso, database, infrastruttura, strumenti di reportistica. Nell’ERP Atac per Ernst & Young i microservizi sono rilasciati in container Docker su un sistema on-premise fornito dal cliente; nell’ERP Hera per Atos l’applicazione gira su Microsoft Azure, usa Azure Active Directory (oggi Microsoft Entra ID) per l’accesso e Power BI per i report.
Sicurezza e costi
3. Sicurezza
Guardiamo la storia delle vulnerabilità di un progetto, la rapidità con cui vengono corrette, gli aggiornamenti di sicurezza previsti per le versioni che useremo e il supporto a standard come OAuth2 e OpenID Connect. Una libreria abbandonata è un rischio, anche se oggi funziona. Per i dati sensibili valutiamo anche dove vengono conservati e quali garanzie offre il fornitore.
4. Costi
Il costo non è solo la licenza. Conta il costo totale: infrastruttura, ore di sviluppo, formazione e soprattutto manutenzione negli anni. Un servizio gestito costa di più a consumo, ma spesso costa meno di un sistema equivalente da far funzionare in proprio. E uno strumento gratuito ma poco diffuso può costare caro quando bisogna trovare o formare chi lo conosce.
Le persone: produttività, comunità, esperienza
5. Facilità d’uso e produttività
Documentazione chiara, strumenti di sviluppo maturi, test facili da scrivere: tutto ciò che fa lavorare il team più velocemente e con meno errori, oggi e quando qualcun altro dovrà mettere mano al codice.
6. Supporto e comunità
Una comunità ampia vuol dire risposte ai problemi, librerie pronte e professionisti disponibili sul mercato. Contano anche un calendario di rilasci pubblico, versioni con supporto a lungo termine e, dove serve, l’assistenza commerciale di un’azienda.
7. Esperienza del team
Una tecnologia che il team conosce bene riduce rischi e tempi. Non è un motivo per non imparare mai nulla di nuovo, ma va pesata: la curva di apprendimento ha un costo, e conviene metterlo in conto prima di iniziare.
Guardare avanti e verificare
8. Tendenze del settore
Seguiamo dove si muove il mercato per non puntare su una tecnologia in declino, ma non adottiamo una novità solo perché se ne parla. Una tecnologia molto recente può cambiare in fretta; in quei casi lo diciamo al cliente e prevediamo una via d’uscita. Nell’AI generativa, per esempio, modelli e strumenti cambiano nel giro di pochi mesi: per questo è prudente tenere il modello dietro un’interfaccia dell’applicazione, così si può sostituire senza riscriverla.
9. Test e proof of concept
Quando un dubbio è importante lo verifichiamo con una POC (proof of concept, un piccolo prototipo che dimostra che una soluzione funziona davvero): pochi giorni su un caso reale valgono più di molte discussioni. Misuriamo prestazioni, facilità di integrazione e qualità del risultato: due database o due modelli linguistici, per esempio, si confrontano sugli stessi dati e sulle stesse domande.
10. Strategia aziendale
Infine la tecnologia deve stare dentro la strategia del cliente: i fornitori cloud con cui ha già accordi, le competenze interne che vuole far crescere, la libertà di cambiare fornitore in futuro, i vincoli normativi sui dati.
I compromessi, in pratica
I dieci criteri raramente puntano tutti nella stessa direzione. Alcuni casi tipici:
- Sistemi enterprise di lunga durata: framework maturi come Spring Boot per il back end e Angular per il front end offrono struttura, convenzioni condivise e rilasci pianificati; chiedono più impostazione iniziale, che si ripaga negli anni di manutenzione.
- Progetti pilota da validare in fretta: strumenti più leggeri e servizi gestiti permettono di arrivare prima davanti agli utenti, accettando che alcune parti andranno riviste se il pilota funziona.
- Intelligenza artificiale: l’ecosistema Python, con librerie come PyTorch, scikit-learn, Hugging Face e LangChain, è oggi il riferimento, mentre l’integrazione con i sistemi aziendali può restare in Java o TypeScript.
- Costruire o usare un servizio: la pipeline video di Artika si basa su servizi gestiti di AWS, come Amazon Transcribe per i sottotitoli automatici e Amazon Rekognition per la moderazione dei video, invece che su componenti sviluppati e gestiti in proprio.
Se devi avviare un progetto o rinnovare un sistema esistente e vuoi capire quale stack fa al caso tuo, possiamo valutare insieme le opzioni con questi criteri, anche partendo da una POC. Contattaci e ne parliamo.
