Siamo tutti consapevoli che un servizio software non è un prodotto isolato dal contesto, ma anzi è un oggetto profondamente collegato da un lato al business aziendale e dall’altro ad un ecosistema tecnologico di più ampio respiro.
Sembrerebbe una constatazione piuttosto banale, ma in realtà ha ripercussioni piuttosto importanti nella fase progettuale. Definire lo stack tecnologico di un servizio senza prenderla in considerazione può far sì che esso perda molto rapidamente la sua capacità di supportare il business.
Stack tecnologico, cos’è e come influisce nel tempo sul valore di un software?
Vi siete mai chiesti cosa c’è “dietro” un prodotto digitale? Be’, lo stack tecnologico (o “tech stack”, per brevità) è la risposta: è l’insieme di tutte le tecnologie utilizzate per creare e far funzionare un singolo servizio. Un tech stack comprende dunque i linguaggi di programmazione, i framework e gli strumenti di cui uno sviluppatore fa uso per creare lo specifico servizio digitale.
Qualsiasi linguaggio di programmazione, tool e framework applicativo ha i suoi pro e contro. Può essere un discorso di prestazioni, presenza di una community di riferimento attiva, supporto di livello enterprise da parte del vendor, la particolare idoneità a specifici casi d’uso, o altro ancora. Scegliere lo strumento giusto per risolvere il problema giusto è il primo passo per garantire la validità ai fini di business e la longevità del servizio digitale.
Ma questo non è il solo motivo per cui scegliere un tech stack in ottica di garantirne la validità futura è tutt’altro che semplice. Bisogna tenere in considerazione anche questioni estrinseche, legate al business, all’evoluzione tecnologica e alla disponibilità di competenze.
Ti piace leggere?
A noi piace scrivere, dai un’occhiata alle nostre guide e approfondimenti
Library di Innovazione Digitale.--. .---. .---|__| .-. |~~~| .--|===|--|_ |_| |~~~|--. | |===| |'\ .---!~| .--| |--| |%%| | |.'\ |===| |--|%%| | | |%%| | |\.'\ | | |__| | | | | | | | \ \ |===| |==| | | | | | |__| \.'\ | |_|__| |~~~|__| | |===|--| \.'\|===|~|--|%%|~~~|--| ^--^---'--^ `-'`---^-^--^--^---'--'
Assicurare la giusta scalabilità
Creare un servizio “su misura” del business: quante volte abbiamo sentito questa definizione? Ma poi, pensandoci bene: QUALE misura? Quella di oggi, di domani o di quando?
Il software è a tutti gli effetti come un macchinario che viene dimensionato per una certa capacità produttiva. La sua capacità di scalare sul numero di utenti dipende da come è stato progettato. Se questa non è sufficiente, l’applicazione potrebbe presto non essere più in grado di rispondere alle esigenze di business per cui è nata. In che modo? Non riuscendo a supportare un’importante variazione nella dimensione del business, oppure richiedendo un investimento in termini di risorse tale da diventare insostenibile – in casi limite, l’evoluzione potrebbe causare costi ben superiori a quelli di un rifacimento dell’intero servizi ed novo. In tutti questi casi, lo scenario più probabile è che si renda necessaria una nuova ingegnerizzazione dei pezzi di software per renderlo più scalabile.
Spingere subito al massimo le feature tecniche può essere la soluzione? In realtà no. Anzi, è altrettanto – se non più – pericoloso. Sviluppare da subito il software per fornire la massima scalabilità senza prendere in considerazione i feedback dei clienti sulle effettive richieste del mercato potrebbe infatti portare a over-ingegnerizzare il software. In questi casi il rischio è quello di spendere molto più tempo del necessario per renderlo generico, estendibile e potente senza invece dotarlo di quella singola feature che avrebbe permesso di incrementare in modo significativo le vendite. Il risultato è qualcosa di molto performante ma non adeguato agli interessi del mercato e, dunque, difficile da vendere.
Interoperabilità, integrazione e fragilità dell’ecosistema
Con quanti sistemi esterni “parla” il software? Anche questo è un elemento da considerare nella scelta del tech stack. Oggi nessun software è un’isola a sé. Qualsiasi servizio – il più complesso così come il più semplice – ha la necessità di parlare con i componenti esterni del mondo in cui si integra. Proprio nell’integrazione il software esprime il maggior valore: quando il suo operato si innesta alla perfezione con con quello di altri sistemi e strumenti digitali, gli aspetti tecnici scompaiono ed il software diventa realmente qualcosa al nostro servizio.
Un esempio? Un software che gestisce le attività in una fabbrica di produzione dovrà interfacciarsi con il sistema che coordina i robot che movimentano i pezzi nella linea di produzione, con il gestionale del magazzino, con il sistema della logistica e non solo. Ma anche in una semplice App è frequente l’integrazione di un meccanismo di pagamento, un calendario, un sistema di login tramite account (ad esempio di Google, Facebook, ..) o un sistema di gestione delle spedizioni.
Questo cosa significa? Significa che il servizio software deve essere in grado di evolvere parallelamente all’evoluzione dei sistemi terzi con cui si integra. Anche un software perfetto, funzionante senza problemi potrebbe veder minata la sua funzionalità dall’evoluzione di uno dei prodotti con cui si integra. Se pensiamo al numero di integrazioni che caratterizzano ogni prodotto digitale, capiamo quanto tutto questo rendal’ecosistema software molto più fragile, moltiplicando il numero di revisioni necessarie e accelerando la potenziale usura. Ecco perché il tech stack deve essere calibrato con l’ecosistema in cui si inserisce.
E se l’integrazione è interna al servizio digitale? Accade sempre più spesso che nell’applicazione vengano integrati framework e tool sviluppati e manutenuti da produttori terzi o da community Open Source . Si tratta di una pratica con notevoli vantaggi, come la possibilità di rendere lo sviluppo è più veloce ricorrendo a pezzi già esistenti per implementare qualche funzionalità del mio prodotto, senza doverli creare ex novo, ma presenta anche qualche zona d’ombra. In questi casi, infatti, la complessità nel mantenimento è accresciuta dal fatto di non avere il completo controllo su una parte di servizio.
Skill shortage
Un ultimo tema importante è quello della reperibilità delle competenze tecniche. La domanda di sviluppatori sul mercato supera l’offerta, e questo mette l’azienda in competizione con molte altre per acquisire i talenti di cui ha bisogno; è fondamentale avere talenti per poter sviluppare ed operare un software affidabile, cruciale nel business; la scelta di uno stack non lungimirante rischia di limitare ulteriormente la capacità di trovare quei talenti oggi come in futuro.
Rinunciare agli elementi “di nicchia” anche se particolarmente performanti non è certo la soluzione ideale in proposito. Ovviamente in fase di sviluppo del Tech Stack bisogna tenere presente la necessità di garantire l’opportuna diffusione e rotazione delle competenze, così da garantire la manutenibilità futura del sistema. In questo senso, ricorrere ad una software house che si impegna a garantire una costanza nella disponibilità di tali skill libera l’azienda da notevoli costi e semplifica la gestione anche dal punto di vista HR.
,---------------------------------------.---------. | | | | ,-----------------------------. | . | | | | | | | | | ,-------------------. | | | | | | | | | | | | | | `---- ,---- | | | | | | | | @ | | | | | | | ,---------"---------: | `----' | | | | | | | | `----: ,---------. | `---------. | | | | | | | | | . | | . | | ---------' | | | | | | | | | :----' | | | | | ,--------------: | | | | | | | | | . | `----' | | | ----. | | | | | | | | | | `----"--------- | | `---------' | | | | | `------------------------' `-------------------'