Glossario IT: i termini che usiamo nei progetti software

1. Architettura e sviluppo software

I termini che descrivono come è costruito un applicativo e perché quella scelta strutturale determina i costi di integrazione e di evoluzione degli anni successivi.

API-first

Definizione.Approccio di progettazione in cui l’interfaccia di scambio dati (API) viene definita e concordata prima di scrivere il codice dell’applicazione, diventando il contratto su cui si allineano tutti i sistemi coinvolti. In un modello API-first il contratto – tipicamente descritto in formato OpenAPI – precede l’implementazione. Frontend, backend e sistemi terzi lavorano in parallelo sulla stessa specifica, con mock e test automatici disponibili fin dai primi sprint. Il vantaggio è concreto e misurabile sul budget: l’integrazione con ERP, gestionali o software legacy smette di essere l’ultimo passaggio critico del progetto – quello in cui saltano tempi e costi – e diventa un requisito verificabile dal primo giorno. È anche la condizione che rende un applicativo riutilizzabile: la stessa logica di business può servire a un portale web, a un’app mobile e a un flusso automatico verso un sistema terzo senza duplicazioni.

API REST

Definizione. Interfaccia che permette a due sistemi di scambiarsi dati via HTTP seguendo un insieme di convenzioni standard su risorse, verbi e formati di risposta. REST non è una tecnologia ma uno stile architetturale: ogni entità (un ordine, un cliente, una misura di un sensore) è una risorsa raggiungibile a un indirizzo stabile, e le operazioni si esprimono con i verbi HTTP standard. Le risposte viaggiano quasi sempre in JSON. La diffusione di REST è ciò che rende oggi realistico far dialogare software di fornitori diversi senza sviluppi ad hoc su misura per ogni coppia di sistemi. Nei progetti dove servono flussi in tempo reale o strutture dati molto variabili valutiamo alternative come GraphQL o protocolli a messaggi, ma REST resta la scelta di riferimento per la maggior parte delle .

Microservizi

Definizione. Architettura in cui un’applicazione è composta da servizi autonomi e comunicanti, ciascuno responsabile di una singola capacità di business e rilasciabile in modo indipendente dagli altri. Il beneficio principale non è tecnologico ma organizzativo: team diversi possono rilasciare in momenti diversi, e un componente critico può essere scalato o riscritto senza fermare il resto del sistema. In caso di guasto, l’impatto resta circoscritto al servizio coinvolto. Va detto anche il rovescio: i microservizi spostano complessità dal codice all’infrastruttura. Servono orchestrazione, monitoraggio distribuito, gestione delle versioni delle API e una disciplina di rilascio matura. Per un applicativo con un perimetro funzionale stabile e un solo team a bordo, un monolite ben modularizzato è spesso la scelta più sostenibile: la decisione va presa sulla base di precisa analisi e dei numeri del progetto, non sulla moda del momento.

Monolite (architettura monolitica)

Definizione. Applicazione costruita, rilasciata e messa in esercizio come un unico blocco, in cui tutte le funzionalità condividono lo stesso codice base e lo stesso ciclo di deploy. Monolitico non è sinonimo di obsoleto. Un monolite ordinato, con moduli ben separati e test automatici, è più semplice da sviluppare, da capire e da mantenere di una costellazione di servizi mal governata, e per molti applicativi aziendali resta la risposta corretta. I problemi arrivano quando il blocco cresce senza confini interni: ogni modifica richiede il rilascio dell’intero sistema, i tempi di test si allungano e il rischio di regressione aumenta a ogni intervento. In quel caso la strada che percorriamo non è la riscrittura totale – costosa e ad alto rischio – ma l’estrazione progressiva dei moduli più critici verso servizi separati, mantenendo l’operatività sempre attiva.

Middleware

Definizione. Strato software che mette in comunicazione applicazioni nate per non parlarsi, traducendo formati, protocolli e regole di business tra un sistema e l’altro. In un’azienda con ERP, MES, e-commerce, CRM e macchinari di reparto, il middleware è il livello che evita di costruire un collegamento dedicato per ogni coppia di sistemi: le integrazioni passano da un punto unico, dove sono documentate, monitorate e tracciate. Il valore emerge nel momento in cui un sistema viene sostituito. Con un middleware ben progettato si riscrive un solo adattatore; senza, si rimettono mano a tutte le connessioni esistenti. È uno dei componenti che riducono in modo più diretto il costo dei cambiamenti futuri.

Container e orchestrazione

Definizione. Un container è un pacchetto che racchiude l’applicazione e tutte le sue dipendenze in modo che si comporti allo stesso modo su qualunque ambiente; l’orchestratore è il sistema che ne governa distribuzione, scaling e ripristino. La containerizzazione (Docker come standard di fatto) elimina la classe di problemi legata alle differenze tra ambiente di sviluppo, collaudo e produzione. L’orchestratore – tipicamente Kubernetes, o i servizi gestiti equivalenti su – decide dove eseguire i container, quanti replicarne e come sostituirli quando falliscono. È l’infrastruttura che rende praticabile un rilascio senza fermo servizio e uno scaling automatico sui picchi di carico. Va dimensionata con criterio: per applicativi con carichi prevedibili l’adozione di un orchestratore completo può introdurre più costi di gestione di quanti ne risparmi.

Scalabilità orizzontale e verticale

Definizione. La scalabilità verticale aumenta le risorse della macchina su cui gira il sistema; quella orizzontale aggiunge istanze che lavorano in parallelo distribuendosi il carico. La scalabilità verticale è immediata da attuare ma ha un tetto fisico e un costo che cresce più che proporzionalmente. Quella orizzontale non ha un tetto pratico, ma richiede che l’applicazione sia stata progettata per funzionare in più copie contemporanee: sessioni condivise, dati centralizzati, nessuno stato appoggiato al singolo server. È una scelta che va fatta in fase di progettazione, non dopo. Un applicativo che non nasce scalabile orizzontalmente non lo diventa spostandolo in cloud: si limita a spendere di più per la stessa capacità.

2. Ciclo di vita e manutenzione del software

Che cosa succede a un applicativo dopo il rilascio. È la fase più lunga della vita di un software e quella in cui si concentra la maggior parte del costo totale di proprietà.

Manutenzione evolutiva

Definizione. Attività continuativa che estende, adatta e migliora un software già in produzione con nuove funzionalità, senza riscriverlo da zero. È la manutenzione che risponde ai cambiamenti del business, non ai difetti: un nuovo flusso autorizzativo, un’integrazione aggiuntiva, un’interfaccia da ripensare perché è cambiato il modo di lavorare. Si pianifica su una roadmap concordata e si eroga a cicli regolari, con un budget ricorrente e prevedibile. È anche il momento in cui il debito tecnico si riduce o si accumula: se ogni evoluzione viene innestata sul codice esistente senza interventi di consolidamento, il costo di ogni modifica successiva cresce. La gestiamo con team stabili nel tempo – la consulenza sui servizi applicativi del Politecnico di Milano è attiva con questa impostazione dal 2009 – perché la conoscenza del sistema è il fattore che tiene bassi i tempi di intervento.

Manutenzione correttiva

Definizione. Intervento di rimozione dei difetti che impediscono o degradano il funzionamento previsto di un software in esercizio. Si distingue dall’evolutiva per la natura del lavoro: qui non si aggiunge nulla, si riporta il sistema al comportamento atteso in seno a un presidi previsto sui sistemi. Viene regolata da SLA che definiscono tempo di presa in carico e tempo di ripristino in funzione della gravità dell’anomalia. Un dato utile per valutare la salute di un applicativo è il rapporto tra ore correttive e ore evolutive: quando la correttiva assorbe stabilmente la quota maggiore del monte ore, il problema non è nei singoli bug ma nella qualità strutturale del codice o nella copertura dei test.

Manutenzione adeguativa

Definizione. Adeguamento di un software a cambiamenti esterni – normativi, infrastrutturali o di versione delle tecnologie usate – senza modificarne le funzionalità. Rientrano qui l’aggiornamento di librerie e framework arrivati a fine supporto, la migrazione a una nuova versione del database, l’adeguamento a una modifica di tracciato di un ente o di un fornitore. È la voce che le aziende rimandano più facilmente, perché a valle non produce nessuna funzionalità visibile. Rimandarla ha però un effetto composto: dopo qualche anno di aggiornamenti saltati, l’intervento non è più un adeguamento ma una migrazione, con un ordine di grandezza di costo diverso e un rischio di sicurezza accumulato nel frattempo.

Debito tecnico

Definizione. Costo futuro che si accumula ogni volta che si sceglie una soluzione rapida invece di quella corretta, e che si paga sotto forma di maggiore lentezza in tutti gli sviluppi successivi. Il debito tecnico non è di per sé un errore: contrarlo consapevolmente per arrivare prima a una scadenza è una decisione legittima. Diventa un problema quando non viene registrato, quindi nessuno sa quanto se ne è accumulato né quando andrà restituito. Si manifesta con segnali riconoscibili: stime che crescono a parità di richiesta, rilasci sempre più prudenti, aree del codice che nessuno vuole toccare. La contromisura non è una riscrittura periodica, ma la riserva di una quota fissa di ogni ciclo evolutivo – indicativamente tra il 10% e il 20% – dedicata al consolidamento.

CI/CD (integrazione e rilascio continui)

Definizione. Catena automatizzata che a ogni modifica del codice esegue build, test e – quando previsto ,- il rilascio in ambiente, senza passaggi manuali. La Continuous Integration verifica in automatico che ogni modifica si integri con il resto del sistema e superi i test; la Continuous Delivery porta la versione validata negli ambienti fino alla produzione. L’effetto pratico è che il rilascio smette di essere un evento rischioso da programmare fuori orario e diventa un’operazione ordinaria e ripetibile. È anche il presupposto tecnico per erogare manutenzione evolutiva a cicli brevi: senza automazione, ogni consegna consuma in attività manuali le ore che dovrebbero andare allo sviluppo.

DevOps

Definizione. Modello di lavoro che unisce sviluppo ed esercizio in un unico flusso di responsabilità, con l’obiettivo di rilasciare più spesso mantenendo stabile il sistema in produzione. DevOps non è un ruolo isolato né un insieme di strumenti: è l’eliminazione del passaggio di consegne tra chi scrive il software e chi lo tiene in esercizio. Si concretizza in automazione dei rilasci, infrastruttura descritta come codice, monitoraggio e log accessibili a tutto il team. Nei nostri micro-team la figura DevOps lavora fianco a fianco con analisti e sviluppatori dall’inizio del progetto, perché le scelte di deploy e osservabilità prese in fase di progettazione costano una frazione di quelle recuperate dopo il go-live.

3. Dati e integrazione

Il livello dove i sistemi si incontrano. È qui che si decide se i dati aziendali diventano una base affidabile per decisioni e automazioni, o restano isole scollegate.

DataOps

Definizione. Applicazione delle pratiche DevOps ai flussi di dati: versionamento, test automatici, monitoraggio e responsabilità chiare sulle pipeline che alimentano report, dashboard e modelli. In un’organizzazione senza DataOps le pipeline dati sono spesso script non versionati, eseguiti su una macchina che conosce una persona sola, senza controlli sulla qualità di ciò che producono. Il risultato è che un errore a monte si scopre a valle, in una riunione, davanti a un numero sbagliato. DataOps introduce sui dati gli stessi controlli che si applicano al codice: test sulla qualità e sulla completezza a ogni esecuzione, tracciabilità dell’origine di ogni dato, allarmi automatici quando una pipeline si interrompe o produce risultati anomali. È il prerequisito di qualunque progetto di analisi avanzata o di intelligenza artificiale: un modello addestrato su dati non governati produce risposte plausibili e sbagliate.

ETL / ELT

Definizione. Processi che spostano i dati da un sistema all’altro trasformandoli prima del caricamento (ETL) oppure caricandoli grezzi e trasformandoli a destinazione (ELT). L’ETL classico trasforma i dati in transito ed è la scelta storica quando la destinazione ha capacità di calcolo limitata o vincoli stringenti sul formato in ingresso. L’ELT sfrutta invece la potenza dei data warehouse moderni per trasformare i dati una volta arrivati, mantenendo disponibile anche il dato originale. La differenza pesa sulla capacità di correggere gli errori: con l’ELT una regola di trasformazione sbagliata si riscrive e si riesegue sui dati grezzi conservati, con l’ETL spesso occorre rifare l’estrazione dalla fonte.

Interoperabilità

Definizione. Capacità di due o più sistemi di scambiarsi dati e di interpretarli correttamente, arrivando allo stesso significato senza interventi manuali. Lo scambio tecnico è solo metà del problema: due sistemi possono comunicare perfettamente e restare non interoperabili se chiamano “cliente” due entità diverse o gestiscono le date con convenzioni incompatibili. Serve un accordo esplicito sui significati, oltre che sui formati. Nei contesti dove i vincoli sono forti – infrastrutture di rete instabili, regole locali, standard di settore obbligatori – l’interoperabilità diventa il requisito dominante del progetto. È stato il caso del sistema di scambio dati clinici che abbiamo sviluppato per Emergency, dove ospedali in territori critici devono allinearsi pur lavorando con connessioni intermittenti.

Single source of truth

Definizione. Principio per cui ogni informazione ha un solo sistema di riferimento riconosciuto come autoritativo, mentre tutti gli altri la leggono da lì. L’alternativa è la situazione che quasi tutte le aziende conoscono: l’anagrafica cliente esiste nel gestionale, nel CRM e in un foglio di calcolo, le tre versioni divergono e nessuno sa quale sia quella giusta. Applicare il principio richiede una decisione organizzativa prima che tecnica – stabilire chi è proprietario di quale dato – e poi un’architettura che la renda vincolante: scrittura consentita solo sul sistema sorgente, propagazione automatica verso gli altri, nessun aggiornamento manuale parallelo.

API gateway

Definizione. Punto di ingresso unico che riceve tutte le chiamate verso i servizi di un sistema e si occupa di autenticazione, instradamento, limiti di traffico e registrazione degli accessi. Concentrare questi controlli in un solo punto evita di replicare la logica di sicurezza dentro ogni servizio, con il rischio di implementazioni disallineate. Il gateway espone verso l’esterno un’interfaccia stabile anche quando l’organizzazione interna dei servizi cambia. È il componente che rende gestibile l’apertura di un sistema verso partner e clienti: senza un gateway, ogni integrazione esterna diventa un’eccezione da presidiare singolarmente.

4. Sistemi gestionali e industriali

Gli acronimi che ricorrono nei progetti di digitalizzazione dei processi produttivi e logistici, e il livello aziendale che ciascuno di essi governa.

ERP (Enterprise Resource Planning)

Definizione. Sistema gestionale che centralizza in un’unica base dati i processi amministrativi e operativi dell’azienda: contabilità, acquisti, vendite, magazzino, pianificazione. L’ERP è il livello che risponde alla domanda “che cosa è stato pianificato e che cosa è stato registrato”. Non è invece costruito per governare l’esecuzione in tempo reale sul campo, dove intervengono MES e WMS. Nei progetti custom l’ERP è quasi sempre un sistema esistente e non negoziabile: il lavoro consiste nel farlo dialogare integrandolo con altri applicativie servizi attraverso interfacce documentate, evitando sia la duplicazione dei dati sia la modifica invasiva del gestionale.

MES (Manufacturing Execution System)

Definizione. Sistema che governa e traccia l’esecuzione della produzione in reparto, collocandosi tra il livello gestionale dell’ERP e le macchine di fabbrica. Il MES prende gli ordini di produzione pianificati dall’ERP e li trasforma in attività eseguibili: assegnazione alle risorse, avanzamento delle fasi, dichiarazione dei tempi, registrazione di scarti e fermi. Raccoglie i dati direttamente dalle macchine e dagli operatori, restituendo indicatori come l’OEE e la tracciabilità completa dei lotti eventualmente anche in integrazione con sistemi di tipo IoT/IIoT. È il livello dove si misura la distanza tra la produzione pianificata e quella reale. Quando manca, quella distanza viene ricostruita a posteriori con fogli di calcolo e dichiarazioni manuali, con un ritardo che rende impossibile intervenire mentre il problema è ancora in corso.

WMS (Warehouse Management System)

Definizione. Sistema che gestisce le operazioni fisiche di magazzino – ubicazioni, missioni di prelievo, versamenti, inventari – guidando gli operatori nelle attività quotidiane. La differenza rispetto alla gestione magazzino di un ERP è la granularità: l’ERP sa quanti pezzi ci sono, il WMS sa in quale ubicazione, in quale unità di carico e con quale lotto, e sa calcolare il percorso di prelievo più efficiente. L’adozione di un WMS ha effetti immediati e misurabili su tempi di evasione, accuratezza dell’inventario ed errori di spedizione. Richiede però una mappatura preliminare del magazzino per un’integrazione capillare e una fase di affiancamento agli operatori che va messa a budget fin dall’inizio.

SCADA

Definizione. Sistema di supervisione e acquisizione dati che monitora e comanda in tempo reale impianti e macchinari distribuiti sul campo. In ambiti IoT , Lo SCADA opera al livello più vicino alla macchina: legge i segnali da PLC e sensori, li presenta agli operatori su sinottici e permette di intervenire sui parametri di funzionamento. Il suo orizzonte temporale è l’istante, non il turno o la commessa. Nei progetti di digitalizzazione industriale rappresenta la fonte dati primaria da cui alimentare i livelli superiori – MES ed ERP – a condizione di disporre di un’integrazione che normalizzi i segnali senza sovraccaricare la rete di impianto.

IIoT (Industrial Internet of Things)

Definizione. Applicazione delle tecnologie IoT agli ambienti industriali, con macchinari e impianti connessi che trasmettono dati di funzionamento verso sistemi di analisi e controllo. Rispetto all’IoT di consumo, l’IIoT lavora con vincoli più severi: continuità di servizio, ambienti elettricamente rumorosi, protocolli industriali specifici, apparati con cicli di vita di decenni e segregazione tra rete di fabbrica e rete aziendale. Il valore non sta nel collegare i macchinari ma in ciò che si fa dopo: manutenzione predittiva basata sui dati reali di esercizio, monitoraggio dei consumi energetici per linea, allarmi su soglie che anticipano il fermo. Senza un caso d’uso misurabile a monte, un progetto IIoT produce dati che nessuno consulta.

Digital twin (gemello digitale)

Definizione. Replica digitale di un asset, di un impianto o di un processo, tenuta allineata alla realtà dai dati raccolti sul campo e utilizzabile per simulare scenari. Un gemello digitale non è un modello 3D né una dashboard: la caratteristica distintiva è l’aggiornamento continuo dai dati di esercizio, che permette di confrontare il comportamento atteso con quello reale e di provare una modifica prima di applicarla all’impianto. È un investimento che ha senso quando esistono già una raccolta dati affidabile e un modello di funzionamento validato. Costruirlo prima di aver messo in ordine i dati di campo significa simulare su basi che non rappresentano l’impianto.

5. Modelli di collaborazione e gestione del team

Come si struttura contrattualmente e operativamente il rapporto tra chi commissiona un progetto IT e chi lo realizza. È la parte che determina la flessibilità reale su tempi e costi.

Scale up / scale down del team

Definizione. Possibilità di aumentare o ridurre le persone allocate su un progetto seguendo i picchi effettivi di lavoro, senza rinegoziare l’intero contratto a ogni variazione. Un progetto reale non ha un fabbisogno costante: la fase di analisi impegna poche figure, lo sviluppo di un modulo critico ne richiede molte per alcune settimane, il periodo successivo al rilascio torna a un presidio ridotto. Un team dimensionato sul picco spreca budget per la maggior parte del tempo; uno dimensionato sulla media manca le scadenze. Perché lo scaling funzioni davvero servono precondizioni operative, non solo una clausola contrattuale: documentazione aggiornata, ambienti di sviluppo replicabili, standard di codice condivisi e un nucleo stabile di persone che garantisce la continuità della conoscenza quando la squadra si allarga o si restringe. Senza queste condizioni, ogni nuovo ingresso costa più tempo di quanto ne faccia risparmiare.

Team dedicato

Definizione. Gruppo di lavoro stabile e assegnato in via esclusiva a un cliente per un periodo prolungato, che accumula conoscenza del dominio e del sistema. La differenza rispetto all’assegnazione a progetto sta nel valore della continuità: dopo alcuni mesi il team non ha più bisogno di spiegazioni sul contesto, riconosce l’impatto di una richiesta prima di stimarla e interviene su un’anomalia sapendo dove guardare. È il modello adatto ai sistemi che evolvono in modo continuativo per anni, dove il costo di ricostruire ogni volta il contesto supererebbe quello della dedizione esclusiva. Nei nostri progetti di lungo corso il team dedicato è coordinato da un Project Manager che resta il riferimento costante verso il cliente.

Staff augmentation

Definizione. Modello in cui figure specialistiche esterne si inseriscono nel team interno del cliente, lavorando sotto il suo coordinamento e sui suoi processi. Si distingue dall’affidamento di un progetto perché la responsabilità del risultato resta in capo al cliente: quello che viene fornito è capacità di lavoro qualificata, non un deliverable chiuso. È la scelta corretta quando esiste già una direzione tecnica interna e manca una competenza puntuale o della capacità produttiva per un periodo definito. Quando invece serve anche la responsabilità sul risultato – analisi, scelte architetturali, garanzia sui tempi – il modello appropriato è l’affidamento a un team con proprio coordinamento.

Time & material e fixed price

Definizione. Due modelli contrattuali: nel time & material si paga il tempo effettivamente impiegato, nel fixed price si concorda in anticipo un prezzo per un perimetro definito. Il fixed price sposta il rischio sul fornitore e dà al cliente un costo certo, ma funziona solo se i requisiti sono stabili e dettagliati: ogni variazione passa da una richiesta di modifica e relativa analisi e il preventivo include necessariamente un margine di copertura del rischio. Il time & material dà flessibilità di ripianificare a ogni ciclo in base a ciò che emerge, a condizione di una governance seria: stime per iterazione, consuntivi trasparenti e un tetto di spesa concordato. In pratica molti progetti adottano un modello misto – perimetro chiuso e a prezzo fisso per la parte già chiara, time & material per le evoluzioni successive.

SLA (Service Level Agreement)

Definizione. Accordo che definisce in modo misurabile i livelli di servizio garantiti: orari di copertura, tempi di presa in carico e di ripristino per ciascuna classe di gravità. Uno SLA utile stabilisce prima di tutto una classificazione condivisa delle anomalie e nella richiesta di supporto e assistenza– blocco totale, funzione critica degradata, difetto non bloccante – perché è da quella che discendono i tempi. Senza classificazione, ogni segnalazione diventa un’urgenza e nessuna lo è davvero. Vanno lette con attenzione due distinzioni: tra tempo di presa in carico e tempo di risoluzione, e tra orario lavorativo e copertura estesa. Sono le due variabili che spostano di più il costo del servizio, ed è corretto dimensionarle sull’impatto reale di un fermo, non per prudenza generica.

Come usare questo glossario

Le definizioni di questa pagina sono il linguaggio con cui lavoriamo: le stesse parole che trovi nei documenti di analisi, nei preventivi e nei report di avanzamento dei nostri progetti. Se stai valutando un intervento e vuoi capire quali di questi elementi riguardano davvero la tua situazione, la prima cosa che facciamo insieme è uno studio di fattibilità: nessun impegno, un quadro chiaro di costi e alternative.