Questo glossario raccoglie i 60+ termini che incontri nelle conversazioni con un partner di sviluppo software su misura, spiegati in linguaggio operativo per decisori PMI non tecnici (CFO, CEO, procurement, IT manager generalista). Per ogni termine: definizione plain, impatto pratico sulla decisione di acquisto, eventuale cross-link al catalogo o ai confronti SynSphere.
Aggiornato maggio 2026. Suggerisci nuovi termini scrivendo a info@synsphere.com — il glossario viene esteso periodicamente con i suggerimenti ricevuti.
Come usarlo: ogni voce ha un anchor link nell’URL (es.
#api-rest). Puoi linkare direttamente un termine dal tuo wiki aziendale o da una RFP per allineare i fornitori sulla terminologia condivisa.
Per un ordine di grandezza numerico sui costi vedi il configuratore software su misura. Per il framework ROI vedi ROI software su misura: TCO a 3 anni.
Indice
- Modelli architetturali e deployment
- Tipologie di applicazione
- Architettura software
- API e integrazione
- Dati e persistenza
- Sicurezza e identità
- DevOps e operations
- Performance e scalabilità
- Project management e processo
- Costi, licensing, proprietà
Modelli architetturali e deployment
Cloud pubblico
Infrastruttura informatica fornita da un provider esterno (Microsoft Azure, AWS, Google Cloud) e condivisa tra molti clienti, ma con isolamento logico. Vantaggi: paghi solo quello che usi, scalabilità immediata, zero gestione hardware. È la scelta default per PMI italiane oggi. Vedi confronto Azure vs AWS per software custom.
On-premise
Software ospitato sui server fisici del cliente, dentro la sua sede o un suo datacenter. Era lo standard prima del cloud, oggi è scelta minoritaria — ha senso per vincoli regolamentari estremi, dati ad altissima sensibilità o latenza ultra-bassa verso macchinari industriali.
Hybrid cloud
Combinazione di cloud pubblico + on-premise nello stesso sistema. Tipico esempio: dati sensibili on-premise, frontend e logica applicativa in cloud. Più complesso da gestire ma utile in scenari regolamentati o di transizione graduale.
SaaS (Software as a Service)
Modello commerciale in cui paghi un canone (utenti × mese) per accedere a un software già pronto, ospitato dal vendor. Esempi: Microsoft 365, Salesforce, ServiceNow. Differisce dal software custom in cui sei tu a possedere il software.
PaaS (Platform as a Service)
Modello cloud in cui il provider gestisce il runtime e l’infrastruttura, e tu gestisci solo il codice della tua applicazione. Esempi: Azure App Service, AWS Elastic Beanstalk. È la scelta di hosting più frequente per software custom PMI: meno operativo da gestire del IaaS, meno rigido del SaaS.
IaaS (Infrastructure as a Service)
Modello cloud in cui il provider fornisce VM/storage/network virtualizzati e tu gestisci tutto sopra (OS, middleware, applicazione). Esempi: Azure Virtual Machines, AWS EC2. Più flessibile del PaaS ma richiede più competenze operative interne.
Serverless
Modello di esecuzione in cui non gestisci alcun server — il codice viene eseguito su richiesta e pagato per millisecondo di esecuzione. Esempi: Azure Functions, AWS Lambda. Ottimo per carichi sporadici o eventi (webhook, batch notturno); meno adatto a carichi continui.
Edge computing
Esecuzione del codice il più vicino possibile all’utente finale (CDN nodes, dispositivi locali) per minimizzare la latenza. Per le PMI italiane è rilevante soprattutto per app B2C ad alta latenza-sensibilità (es. e-commerce con clienti europei distribuiti).
Tipologie di applicazione
Web application
Applicazione fruita interamente dal browser, senza installazione. Funziona su qualsiasi sistema operativo (Windows, Mac, Linux, ChromeOS) e su mobile responsive. È la scelta default per app B2B aziendali interne o portali clienti. Vedi pagina prodotto Web Application.
SPA (Single Page Application)
Tipo di web app in cui l’intera applicazione carica una sola volta in browser e poi naviga senza ricaricare pagine (es. Gmail, Trello, Figma). Esperienza utente più fluida di una web app multi-page. Tecnologie tipiche: React, Vue, Angular, Svelte.
PWA (Progressive Web App)
Web app che si comporta come app installata (icona sul desktop, funziona offline parzialmente, notifiche push). Compromesso fra web app e mobile app nativa: copertura cross-platform completa, performance buone ma non native, costo di sviluppo significativamente inferiore al nativo.
Mobile app nativa
Applicazione installata su smartphone/tablet, scritta nel linguaggio specifico della piattaforma (Swift per iOS, Kotlin per Android). Performance massima, accesso completo alle API del device, costo elevato perché richiede sviluppo separato per ogni piattaforma. Vedi Mobile Application.
Mobile app cross-platform
Mobile app sviluppata in un singolo codebase che gira sia su iOS sia su Android. Tecnologie: React Native, Flutter, .NET MAUI. Risparmio del 30-50% sul costo di sviluppo rispetto al nativo doppio, performance leggermente inferiori per casi UI complessi.
Desktop application
Applicazione installata su PC Windows/macOS/Linux. Oggi è scelta minoritaria rispetto alla web app (che è cross-platform per definizione), ha senso per tool tecnici, app industriali che parlano con hardware locale, applicativi che devono funzionare offline al 100%. Vedi Desktop Application.
Headless application
Applicazione divisa in due strati separati: un back-end “headless” (solo API, niente UI) e un front-end indipendente (web, mobile, smart TV, qualsiasi cosa). Architettura sempre più diffusa perché permette di sviluppare nuove interfacce senza toccare il back-end.
Architettura software
Monolite
Architettura tradizionale in cui l’intera applicazione è un singolo blocco di codice deployato come unica unità. Più semplice da sviluppare e mantenere fino a una certa complessità, ma meno scalabile e più rigido oltre quella soglia. Per il 90% dei progetti PMI italiani il monolite è la scelta giusta — i microservizi sono spesso over-engineering.
Microservizi
Architettura in cui l’applicazione è divisa in tanti piccoli servizi indipendenti che comunicano via API. Vantaggi: scalabilità granulare, team che lavorano in parallelo, fault isolation. Svantaggi: complessità operativa, latency network, debug più difficile. Per PMI italiane raramente giustificato sotto i 100k utenti attivi.
Multi-tenant
Architettura in cui una sola istanza del software serve molti clienti diversi (tenant), con dati isolati. Tipico nei SaaS. Se stai costruendo un software che vuoi vendere a più clienti come SaaS, il multi-tenant è obbligatorio. Aumenta il costo di sviluppo del 30-50% rispetto a single-tenant.
Multi-tenant single-tenant
Per disambiguazione: “single-tenant” significa che ogni cliente ha una sua istanza dedicata del software. È più semplice da sviluppare ma più costoso da operare se hai molti clienti.
Stateless vs stateful
- Stateless: il servizio non mantiene memoria fra richieste consecutive — ogni richiesta è autonoma. Più semplice da scalare orizzontalmente.
- Stateful: il servizio mantiene stato (sessione utente, transazione in corso). Più complesso da scalare ma necessario per certi tipi di applicazione.
Event-driven
Architettura in cui i componenti comunicano tramite eventi pubblicati su un canale (message bus), invece che chiamate dirette. Disaccoppia i componenti, abilita scenari di integrazione complessi. Tecnologie: Azure Service Bus, AWS SNS/SQS, Kafka.
Domain-Driven Design (DDD)
Approccio metodologico al design del software che parte dal dominio di business invece che dalla tecnologia. Utile per progetti con logica di business complessa (es. assicurazioni, banking, supply chain). Per software CRUD semplice è over-engineering.
API e integrazione
API (Application Programming Interface)
Interfaccia con cui un software espone le sue funzionalità a essere chiamate da altri software. Tutto ciò che è “integrazione” passa per API. Le API moderne sono in genere REST o GraphQL.
REST API
Stile architetturale di API basato su HTTP e operazioni CRUD (GET/POST/PUT/DELETE). È lo standard de-facto del web moderno. Semplice, ampiamente supportato, ottimo per integrazioni client-server. Vedi pagina Backend e API.
GraphQL
Linguaggio di query alternativa a REST in cui il client specifica esattamente quali dati vuole. Vantaggio: meno over-fetching (non scarichi dati che non ti servono). Svantaggio: complessità lato server. Usato spesso per app mobili con bandwidth limitato.
SOAP
Vecchio protocollo enterprise basato su XML. Ancora presente in integrazioni con sistemi legacy (banche, PA, sanità, alcuni ERP). Più verboso di REST ma con primitive di sicurezza e transazionalità built-in.
Webhook
“API al contrario”: invece che essere il tuo software a chiedere dati a un altro, è l’altro che ti notifica quando succede qualcosa (es. Stripe ti chiama quando un pagamento si conclude). Pattern fondamentale per integrazioni real-time.
OpenAPI / Swagger
Standard per descrivere un’API in modo machine-readable. Permette di generare automaticamente documentazione, SDK client, test. Una API custom deve avere un OpenAPI spec — è il requisito minimo di professionalità.
Rate limiting
Limite sul numero di chiamate API che un client può fare in un certo intervallo (es. 100/minuto, 1000/ora). Protegge l’API da abusi e garantisce equità. Una qualsiasi API esposta a internet deve avere rate limiting attivo.
API gateway
Componente che si mette davanti alle API per gestire centralmente autenticazione, rate limiting, caching, logging, routing. Esempi: Azure API Management, AWS API Gateway. Utile quando esponi più API.
Dati e persistenza
Database relazionale (SQL)
Database basato su tabelle con righe e colonne, con relazioni esplicite (chiavi esterne) e linguaggio SQL. Forte coerenza, transazioni ACID, perfetto per dati strutturati. Esempi: SQL Server, PostgreSQL, MySQL. Per il 90% dei software custom PMI il database relazionale è la scelta giusta.
NoSQL
Famiglia di database non-relazionali, ottimizzati per casi specifici. Tipologie principali:
- Document store (MongoDB, Azure Cosmos DB, DocumentDB): documenti JSON flessibili
- Key-value (Redis): coppie chiave-valore in RAM, velocissimo
- Column-family (Cassandra): tabelle grandi, scrittura intensiva
- Graph (Neo4j): relazioni many-to-many complesse
ACID
Quattro proprietà che garantiscono che le transazioni di un database siano “sicure”:
- Atomicity: tutto o niente
- Consistency: il database rimane in stato valido
- Isolation: transazioni concorrenti non si interferiscono
- Durability: una transazione confermata non si perde
I database relazionali sono ACID. Alcuni NoSQL lo sono in parte (es. MongoDB su singolo documento), altri preferiscono eventual consistency.
Eventual consistency
Modello in cui il database accetta scritture immediate ma garantisce solo “alla fine” che tutte le copie/repliche siano coerenti. Trade-off rispetto a ACID: meno garanzie ma più scalabilità. Adatto per scenari come notifiche, contatori, log.
ORM (Object-Relational Mapping)
Libreria che mappa automaticamente tabelle del database in oggetti del linguaggio di programmazione. Riduce il codice da scrivere ma può nascondere problemi di performance. Esempi: Entity Framework (.NET), Hibernate (Java), Prisma (Node), SQLAlchemy (Python).
Backup e disaster recovery
- Backup: copia periodica dei dati (es. giornaliera) che può essere ripristinata in caso di problemi.
- Disaster recovery (DR): capacità di ripristinare il servizio in tempi definiti dopo un disastro. Si misura con RPO (Recovery Point Objective — quanti dati massimi puoi perdere) e RTO (Recovery Time Objective — quanto tempo massimo di downtime accetti).
Migrazione dati
Trasferimento dati da un sistema esistente al nuovo software. Voce di costo spesso sottovalutata: per un progetto custom PMI tipico la migrazione dati pesa il 10-20% del totale. La qualità dei dati di partenza è il driver principale: dati puliti = migrazione veloce, dati sporchi = bonifica preliminare costosa.
Sicurezza e identità
Authentication vs Authorization
Due cose diverse spesso confuse:
- Authentication (autenticazione): chi sei? (login + password, OTP, biometria)
- Authorization (autorizzazione): cosa puoi fare? (ruoli, permessi)
Sono due strati separati. Un software custom serio implementa entrambi correttamente.
OAuth 2.0
Protocollo standard per delegare l’autenticazione a un identity provider (es. login con Google, Microsoft, Facebook). Non è autenticazione in senso stretto, è delega di accesso. Spesso confuso con OIDC.
OIDC (OpenID Connect)
Layer di identità costruito sopra OAuth 2.0. Aggiunge la nozione di “chi è l’utente” oltre a “cosa può accedere”. Il login “con Google” o “con Microsoft Entra ID” è OIDC sopra OAuth 2.0.
JWT (JSON Web Token)
Formato di token firmato digitalmente che contiene le credenziali utente (identità, ruoli, scadenza). Standard de-facto per API moderne. Vantaggio: stateless (il server non deve memorizzare le sessioni). Svantaggio: difficile da revocare prima della scadenza.
SSO (Single Sign-On)
Capacità di accedere a più applicazioni con un solo login. Implementato tipicamente via OIDC o SAML. Per PMI italiane che usano Microsoft 365, integrare un software custom con Entra ID per SSO è oggi lo standard atteso.
MFA (Multi-Factor Authentication)
Autenticazione con due o più fattori: qualcosa che sai (password), qualcosa che hai (token mobile, smartcard), qualcosa che sei (biometria). NIS2 lo richiede esplicitamente per soggetti in scope.
RBAC (Role-Based Access Control)
Modello di autorizzazione basato sui ruoli. Definisci ruoli (“admin”, “manager”, “user”), assegni utenti ai ruoli, ogni ruolo ha permessi specifici. Più semplice da gestire del permission-per-utente individuale.
Encryption at rest / in transit
- Encryption at rest: i dati sono cifrati quando memorizzati (file su disco, righe di DB).
- Encryption in transit: i dati sono cifrati quando viaggiano sulla rete (TLS/HTTPS).
Un software custom serio fa entrambe by default. È un requisito di GDPR e NIS2.
Zero Trust
Modello di sicurezza in cui nessun utente o dispositivo è “fidato” automaticamente, neanche se interno alla rete aziendale. Ogni richiesta viene verificata. Pattern dominante della cyber security 2025+.
Vulnerability scanning
Scansione automatica del codice e delle dipendenze per identificare vulnerabilità note (CVE). Un software custom mantenuto deve avere vulnerability scanning continuo. Tecnologie: Dependabot, Snyk, GitHub Advanced Security.
DevOps e operations
DevOps
Cultura e set di pratiche che integrano sviluppo (Dev) e operations (Ops) per accelerare la consegna di software in modo affidabile. Tradurre il concetto in PMI italiane: non aspettare 6 mesi fra un’update e l’altra, ma deploy continui con automazione.
CI/CD (Continuous Integration / Continuous Deployment)
Pipeline automatizzata che, ogni volta che il codice cambia, esegue test e deploy automatici. Tre livelli:
- CI: ogni commit fa partire test automatici
- CD continuous delivery: build automatici pronti a deploy manuale
- CD continuous deployment: deploy automatico in produzione
Avere CI/CD attivo è il segno di un partner di sviluppo professionale.
IaC (Infrastructure as Code)
Definire l’infrastruttura (server, network, database, regole firewall) come codice versionato in Git, invece che cliccare su una dashboard. Vantaggi: ripetibilità, audit, disaster recovery rapido. Tecnologie: Terraform, Bicep (Azure), Pulumi.
Container
Pacchetto leggero che contiene un’applicazione e tutte le sue dipendenze, eseguibile in qualsiasi ambiente in modo identico. Tecnologia dominante: Docker. Vantaggio: “funziona sulla mia macchina = funziona ovunque”.
Kubernetes (K8s)
Orchestratore di container per applicazioni distribuite a larga scala. Gestisce deploy, scaling, ricostruzione automatica. Per PMI italiane con app singola e poche centinaia di utenti è spesso over-engineering — basta App Service o un container service managed.
Monitoring vs Observability
- Monitoring: misurare metriche note (CPU, memoria, latenza, error rate) con alert su soglie predefinite.
- Observability: capacità di rispondere a domande nuove sul comportamento del sistema, anche non pre-pianificate, grazie a log, metriche e tracing strutturati.
Un software custom in produzione deve avere almeno monitoring. Observability è il next level.
Logging strutturato
Log scritti in formato machine-readable (JSON) anziché testo libero. Permettono ricerche, aggregazioni, dashboard automatiche. Tecnologie: Application Insights (Azure), CloudWatch (AWS), Loki, Datadog.
Blue/Green deployment
Tecnica di deploy senza downtime in cui mantieni due ambienti identici (blu e verde): l’attuale produzione è “blu”, deploy il nuovo codice in “verde”, quando funziona switch del traffico. Permette rollback istantanei in caso di problemi.
Feature flag
Tecnica per attivare/disattivare funzionalità a runtime senza nuovi deploy. Utile per A/B test, gradual rollout, kill-switch in emergenza.
Performance e scalabilità
Latency vs throughput
- Latency: tempo che impiega una singola richiesta a essere processata (es. 200 ms).
- Throughput: numero di richieste processate per unità di tempo (es. 1000 req/sec).
Sono metriche indipendenti. Un’API può avere bassa latency ma basso throughput, o viceversa.
Caching
Memorizzare temporaneamente dati richiesti spesso per evitare ricalcoli o query ripetute. Livelli: cache in memoria (Redis), cache HTTP (CDN), cache lato browser. È la singola ottimizzazione più efficace per migliorare le performance.
CDN (Content Delivery Network)
Rete globale di server che distribuiscono contenuti statici (immagini, JS, CSS) dal nodo più vicino all’utente. Migliora latency percepita, riduce carico sul server origine. Esempi: Cloudflare, Azure CDN, AWS CloudFront.
Load balancing
Distribuzione delle richieste in arrivo su più istanze del software per non sovraccaricare una sola. Tipologie: layer 4 (transport-level), layer 7 (application-level, può fare routing basato su URL/header).
Autoscaling
Capacità del sistema di aggiungere/rimuovere automaticamente istanze del software in base al carico. Vantaggi: paghi solo quello che usi, gestisci picchi senza intervento manuale. Funziona bene su stateless workloads.
Bottleneck
Punto del sistema che limita la performance totale. Tipici bottleneck: database (query non ottimizzate), rete (banda limitata), CPU (calcoli pesanti). Identificare il bottleneck è il primo passo dell’ottimizzazione.
Project management e processo
Agile
Famiglia di metodologie di sviluppo basate su cicli brevi (sprint), feedback continuo, adattamento al cambiamento invece che pianificazione rigida. Pilastro: meglio rilasciare presto qualcosa di parziale che aspettare il “prodotto perfetto”.
Scrum
Framework agile specifico con ruoli definiti (Product Owner, Scrum Master, Team), eventi regolari (Sprint Planning, Daily Standup, Review, Retrospective) e artefatti (Product Backlog, Sprint Backlog). È la metodologia agile più diffusa.
Sprint
Iterazione di sviluppo a durata fissa (tipicamente 2 settimane). Al termine di ogni sprint c’è un incremento di software potenzialmente rilasciabile. La cadenza degli sprint è il battito cardiaco di un progetto agile.
Kanban
Approccio alternativo a Scrum, basato su flusso continuo invece che iterazioni. Le attività si muovono su una board (To Do → In Progress → Done) con limiti sulla quantità di lavoro in parallelo (WIP limit).
MVP (Minimum Viable Product)
Versione minima del software che permette di validare l’ipotesi di business con utenti reali. Filosofia: meglio rilasciare presto qualcosa di incompleto e imparare, che spendere mesi a sviluppare in segreto e scoprire poi che gli utenti volevano qualcosa di diverso.
Backlog
Lista priorizzata di tutte le funzionalità, miglioramenti e bug del prodotto. Il Product Owner mantiene il backlog. Le funzionalità in cima sono dettagliate e pronte allo sviluppo; quelle in basso sono ancora idee abbozzate.
User story
Descrizione concisa di una funzionalità dal punto di vista dell’utente. Formato classico: “Come [tipo di utente] voglio [azione] per [beneficio]”. È l’unità atomica di lavoro in Scrum.
Estimation (story points)
Tecnica di stima dello sforzo relativo invece che del tempo assoluto. I “punti” rappresentano complessità + sforzo + incertezza relativa fra story. Vantaggio: smette di trasformare le stime in deadline cementate.
Retrospettiva
Riunione di fine sprint in cui il team riflette su cosa ha funzionato, cosa no, cosa migliorare. Pratica fondamentale per il continuous improvement.
Definition of Done (DoD)
Criteri condivisi che definiscono quando una user story è “fatta”. Tipicamente include: codice scritto, test scritti e verdi, code review, deploy in staging, documentazione aggiornata. Avere una DoD esplicita evita malintesi.
Costi, licensing, proprietà
CapEx vs OpEx
- CapEx (Capital Expenditure): investimento iniziale ammortizzabile (es. acquisto di un software custom).
- OpEx (Operating Expenditure): costo operativo ricorrente (es. canone SaaS, hosting).
Per le PMI italiane la differenza è fiscale e di cassa: CapEx pesa sul bilancio iniziale ma si ammortizza in più anni; OpEx pesa equamente ogni anno.
TCO (Total Cost of Ownership)
Costo totale di possesso del software su un orizzonte (tipicamente 3 anni), comprensivo di sviluppo iniziale, hosting, manutenzione, operations. Vedi pillar dedicato: ROI software su misura: TCO a 3 anni.
ROI (Return on Investment)
Ritorno dell’investimento espresso come percentuale: (Valore generato − Costo totale) / Costo totale × 100. ROI a 3 anni >50% è un buon investimento per un software custom.
Payback period
Tempo necessario al software per ripagare l’investimento iniziale tramite il valore generato annuo. Per progetti software custom PMI ben calibrati il payback è tipicamente 6-18 mesi.
Licenza software custom
Quando compri sviluppo software su misura, di norma il codice sorgente è di tua proprietà (clausola da verificare nel contratto). Differisce dal SaaS, dove paghi solo per usare il software ma non lo possiedi.
Vendor lock-in
Situazione in cui cambiare fornitore (SaaS o tecnologia) costa così tanto che resti con il fornitore anche se non è più la scelta migliore. Costo invisibile dei SaaS. Il software custom mitiga il vendor lock-in proprietario, ma può creare lock-in verso il partner di sviluppo se non gestito.
Open source
Software il cui codice sorgente è pubblicamente disponibile e modificabile, distribuito con licenze permissive (MIT, Apache 2.0) o copyleft (GPL). La maggior parte dei software custom moderni è costruita sopra librerie open source — chiedi al partner quale licenze usa.
SLA (Service Level Agreement)
Contratto che definisce il livello di servizio garantito (es. uptime 99,9%, tempo di risposta supporto 4 ore). Per un software custom in produzione mission-critical, definire un SLA esplicito è essenziale.
Escrow del codice sorgente
Pratica contrattuale in cui il codice sorgente del software custom viene depositato presso una terza parte neutra (notaio, servizio escrow). In caso di fallimento del partner di sviluppo, il cliente può accedere al codice e proseguire con un altro partner. Raccomandato per progetti business-critical.
CTA
Hai trovato il termine che cercavi? Tre passi pratici:
- Stima costo: usa il configuratore software su misura per un range indicativo sul tuo caso specifico.
- Decisione strategica: leggi il confronto Software su misura vs SaaS verticale per orientarti sulla scelta build vs buy.
- Business case: leggi il pillar ROI software su misura: TCO a 3 anni per costruire il calcolo finanziario interno.
Per termini non coperti o aggiornamenti, scrivi a info@synsphere.com — il glossario viene esteso periodicamente.