Vai al contenuto principale
FromNine
Menu

Ingegneria

Sviluppo di software aziendale su misura e prodotti SaaS, costruiti per durare

Progettiamo e sviluppiamo prodotti SaaS, portali per cittadini e dipendenti e applicazioni gestionali critiche: accessibili, sicuri per impostazione predefinita e manutenibili dai Suoi team anche molto tempo dopo il lancio.

Per imprese che vendono software e per enti che erogano servizi digitali a cittadini e clienti, con requisiti di accessibilità e sicurezza da dimostrare.

Parliamo del Suo progettoScopra il nostro approccio
Software aziendale e SaaS: lo stack delle competenzeQuattro livelli sovrapposti in profondità. Dall’alto verso il basso: l’interfaccia accessibile usata dalle persone, i moduli di dominio che contengono le regole, i servizi di piattaforma per multi-tenancy e identità e, alla base, la pipeline di rilascio sicura.01Interfacce accessibili02Moduli di dominio e regole03Tenancy, identità, dati04Pipeline di rilascio sicura
  1. 01Domain-driven design per attività ricche di regole, come la gestione delle pratiche
  2. 02Accessibilità secondo EN 301 549 e WCAG 2.2 AA fin dal primo sprint
  3. 03Documentazione e registri delle decisioni che i Suoi team possono prendere in carico

01 Problemi

Che cosa sentiamo prima di una riscrittura

  1. 01

    Ogni modifica richiede un trimestre

    L’applicazione funziona, ma nessuno osa toccarne il nucleo. Anche piccole modifiche richiedono ampi test di regressione e una finestra di rilascio.

  2. 02

    Il portale delude le persone a cui si rivolge

    Non funziona con uno screen reader, in un’altra lingua o da smartphone. I reclami arrivano prima dell’audit di accessibilità.

  3. 03

    La modifica per un cliente rompe quella di un altro

    Il prodotto SaaS è cresciuto con personalizzazioni cliente per cliente. Ora ogni rilascio è una trattativa e alcuni tenant sono fermi a versioni obsolete.

  4. 04

    Il know-how è uscito insieme al fornitore

    Le decisioni non sono mai state messe per iscritto. Il team che ha costruito il sistema è passato ad altro e il codice è l’unica documentazione.

  5. 05

    Clienti e autorità pongono domande sulla sicurezza

    Gli uffici acquisti chiedono una SBOM, un processo di gestione delle vulnerabilità ed evidenze per il Cyber Resilience Act. Nessuno le ha pronte.

02 Ambiti di intervento

Che cosa realizziamo

  1. 01 Ingegneria di prodotti SaaS

    Prodotti progettati per servire molti clienti da un’unica codebase: il modello di tenancy adeguato, configurazione al posto della personalizzazione e rilasci che raggiungono ogni tenant.

    Che cosa facciamo

    • Scelta del modello di tenancy: condiviso, a pool o isolato per tenant
    • Strategia di configurazione e di feature flag
    • Integrazione di misurazione dei consumi e fatturazione
    • Release train con distribuzione consapevole dei tenant

    Che cosa riceve

    • Progetto di tenancy e isolamento
    • Modello di configurazione con guardrail
    • Processo di rilascio con rollback per singolo tenant

  2. 02 Progettazione di dominio per regole complesse

    Domain-driven design dove le regole sono il prodotto: gestione delle pratiche, requisiti di ammissibilità, calcoli fortemente normati. Scegliamo con onestà tra monolite modulare e microservizi, e il più delle volte partiamo dal primo.

    Che cosa facciamo

    • Event storming con gli esperti di dominio
    • Bounded context e confini tra moduli
    • Regole rese esplicite e verificabili
    • Architecture decision record per le scelte principali

    Che cosa riceve

    • Modello di dominio e context map
    • Codebase modulare con confini verificati in automatico
    • Specifiche eseguibili per le regole chiave

  3. 03 Portali per cittadini e dipendenti

    Interfacce costruite su un design system, accessibili per impostazione predefinita e multilingue dal primo rilascio. In Belgio significa tre lingue ufficiali; altrove, le lingue che i Suoi utenti parlano davvero.

    Che cosa facciamo

    • Design system con componenti accessibili
    • Contenuti scritti in linguaggio chiaro
    • Test con tecnologie assistive e utenti reali
    • Flusso di localizzazione per ogni lingua

    Che cosa riceve

    • Portale su un design system riutilizzabile
    • Rapporto di conformità sull’accessibilità
    • Flusso di gestione di contenuti e traduzioni

  4. 04 Quality engineering e sviluppo sicuro

    Automazione dei test ai livelli giusti, contract test tra i servizi, test di prestazione prima del lancio e un ciclo di sviluppo sicuro basato su OWASP ASVS, SBOM e controlli sulla supply chain.

    Che cosa facciamo

    • Strategia e automazione dei test
    • Contract test e test di prestazione
    • Threat modelling e verifica ASVS
    • Generazione della SBOM e policy sulle dipendenze

    Che cosa riceve

    • Suite di test automatici nella pipeline
    • Rapporto di verifica della sicurezza
    • Processo di gestione delle vulnerabilità pronto per il Cyber Resilience Act

  5. 05 Modernizzazione incrementale

    Sostituire un’applicazione legacy una funzionalità alla volta, dietro una facciata di instradamento, mentre l’operatività continua. Si veda anche la modernizzazione dei sistemi legacy.

    Che cosa facciamo

    • Mappa delle funzionalità dell’applicazione esistente
    • Instradamento secondo il pattern strangler fig e incapsulamento tramite API
    • Migrazione dei dati con report di riconciliazione
    • Esercizio in parallelo per i calcoli critici

    Che cosa riceve

    • Sequenza di modernizzazione con milestone di business
    • Facciata e nuovi moduli in produzione
    • Dati riconciliati a ogni passaggio dal vecchio al nuovo sistema

  6. 06 Manutenibilità e passaggio di consegne

    Software di cui i Suoi team possono diventare titolari: codice leggibile, registri delle decisioni, runbook e un piano di passaggio di consegne concordato all’inizio, non scoperto alla fine.

    Che cosa facciamo

    • Pair programming con i Suoi sviluppatori durante lo sviluppo
    • Architecture decision record conservati insieme al codice
    • Runbook operativi e guide per la reperibilità
    • Milestone di trasferimento delle conoscenze

    Che cosa riceve

    • Piano di passaggio di consegne con criteri di accettazione
    • Documentazione nei Suoi repository
    • Team interno formato

03 Architettura

Un’architettura di riferimento illustrativa

Una forma tipica per un’applicazione gestionale che ne sostituisce una precedente: un front end accessibile, una facciata di instradamento che indirizza ogni funzionalità al sistema vecchio o a quello nuovo, un livello API con contratti chiari e un nucleo modulare organizzato attorno al dominio.

Tenancy e configurazione sono servizi di piattaforma espliciti, non condizioni sparse nel codice. Alla base, ogni build esegue test e controlli di sicurezza e produce una SBOM.

Livelli del diagramma

Persone
Cittadini, clienti e dipendenti, da qualsiasi dispositivo e con tecnologie assistive.
Modernizzazione
La facciata di instradamento, l’applicazione esistente e la migrazione dei dati con riconciliazione.
Piattaforma
Livello API, identità, nucleo modulare, tenancy e configurazione, dati operativi.
Rilascio sicuro
Contract test e test di prestazione, controlli ASVS e una SBOM a ogni build.
Esempio illustrativo

  1. Persone

    • Cittadini, clienti, dipendenti
    • Front end accessibile

  2. Modernizzazione incrementale

    • Facciata di instradamento
    • Applicazione esistente
    • Migrazione con riconciliazione

  3. Piattaforma

    • Livello API e contratti
    • Identità e ruoli
    • Nucleo modulare: ricezione, pratiche, fatturazione
    • Tenancy, configurazione, feature flag
    • Archivi di dati operativi

  4. Rilascio sicuro

    • Contract test e test di prestazione, controlli ASVS, SBOM a ogni build
Nucleo modulare dietro una facciata di instradamento

Architettura illustrativa, non un sistema di un cliente.

Leggere il diagramma in forma testuale

Il percorso principale va dalle persone a un front end accessibile, attraverso una facciata di instradamento e un livello API, fino a un nucleo modulare organizzato in bounded context.

La facciata instrada alcune funzionalità anche verso l’applicazione esistente, che viene dismessa per gradi. I suoi dati passano, tramite una migrazione con riconciliazione, negli archivi di dati operativi.

Il servizio di identità serve il livello API. I servizi di tenancy e configurazione si trovano sotto il nucleo. Una fascia di rilascio sicuro alla base comprende contract test, test di prestazione, verifica della sicurezza e SBOM.

04 Considerazioni e limiti

Scelte progettuali e limiti

  • Prima il monolite modulare

    Come lo affrontiamo

    Partiamo da moduli ben definiti in un’unica unità di rilascio e scorporiamo servizi solo dove lo richiedono scalabilità, cadenza dei rilasci o responsabilità dei team.

    Limiti e dipendenze

    I microservizi risolvono problemi organizzativi tanto quanto tecnici. Senza team che ne siano responsabili, aggiungono costi e nuove modalità di guasto.

  • L’accessibilità è lavoro di ingegneria

    Come lo affrontiamo

    Componenti accessibili, controlli automatici nella pipeline e test manuali con tecnologie assistive prima di ogni rilascio importante.

    Limiti e dipendenze

    Gli strumenti automatici individuano solo una parte dei problemi. La piena conformità richiede audit manuali e, idealmente, test con utenti con disabilità.

    Contenuti e documenti aggiunti dai redattori dopo il lancio devono rispettare lo stesso standard. Formiamo i redattori, ma non controlliamo ciò che pubblicano.

  • La modernizzazione dura quanto i dati

    Come lo affrontiamo

    La migrazione dei dati viene pianificata per funzionalità, provata e riconciliata, con l’approvazione del business a ogni passaggio dal vecchio al nuovo sistema.

    Limiti e dipendenze

    Spesso è la qualità dei dati legacy a dettare il ritmo. Bonificarli è un compito del business tanto quanto un compito tecnico.

  • Le regole per i prodotti software

    Come lo affrontiamo

    SBOM, gestione delle vulnerabilità e impostazioni predefinite sicure fanno parte della nostra pipeline standard, che prepara i prodotti al Cyber Resilience Act.

    Limiti e dipendenze

    Se e come il regolamento si applichi al Suo prodotto è una questione giuridica. Noi forniamo le evidenze tecniche; la valutazione spetta ai Suoi consulenti legali.

05 Come lavoriamo

Come lavoriamo

Cicli brevi, utenti reali fin da subito e il passaggio di consegne pianificato dalla prima settimana.

  1. 01

    Mappare il dominio

    Event storming con le persone che conoscono le regole e una mappa delle funzionalità esistenti.

    RisultatoContext map e primi registri delle decisioni

  2. 02

    Rilasciare una prima porzione

    Una funzionalità completa, dall’inizio alla fine, attraverso la facciata e in produzione con utenti reali.

    RisultatoPrima porzione funzionante in produzione

  3. 03

    Crescere per funzionalità

    Ogni rilascio sposta una funzionalità, i suoi dati e i suoi utenti, con riconciliazione e rollback pronti.

    RisultatoPiano dei rilasci per funzionalità

  4. 04

    Passare le consegne

    I Suoi sviluppatori lavorano in coppia con i nostri, assumono la reperibilità e prendono in mano la roadmap quando i criteri di passaggio sono soddisfatti.

    RisultatoPassaggio di consegne accettato

06 Controllo umano

Dove il controllo resta alle persone

Nel software gestionale, controllo significa sapere chi ha modificato che cosa, chi l’ha approvato e come annullarlo.

  • Il perimetro lo decide il product owner

    Il Suo product owner fissa le priorità e accetta ogni incremento. Noi consigliamo, il product owner decide.

  • La configurazione ha un responsabile

    Impostazioni dei tenant e feature flag si modificano con un processo tracciato, da parte dei ruoli che Lei assegna.

  • I passaggi al nuovo sistema vengono approvati

    Ogni passaggio dal vecchio al nuovo sistema è approvato dal business, con un rollback già provato.

  • Le decisioni vengono messe per iscritto

    Gli architecture decision record mostrano che cosa è stato scelto, da chi e perché, così i team futuri possono riesaminare le scelte con cognizione di causa.

07 Tecnologie

Tecnologie con cui lavoriamo

Back end
  • Java e Kotlin
  • .NET
  • TypeScript e Node.js
  • Python
Front end
  • React e Next.js
  • Angular
  • Design system con componenti accessibili
  • App mobile native e multipiattaforma
Dati
  • PostgreSQL
  • SQL Server e Oracle (sistemi esistenti)
  • Event streaming
  • Motori di ricerca
Qualità e sicurezza
  • Playwright e contract testing
  • Test di carico e di prestazione
  • SAST, DAST e analisi delle dipendenze
  • SBOM in CycloneDX o SPDX

La citazione di una tecnologia descrive la nostra esperienza di ingegneria. Non implica una partnership con il relativo fornitore né la sua approvazione.

08 Esempio

Un esempio illustrativo

Esempio illustrativo

Un portale clienti accessibile per una multiutility

01Situazione
Una multiutility ha tre aree clienti, per luce, gas e acqua, sviluppate da tre fornitori diversi: ognuna fallisce i controlli di accessibilità in modo diverso e ogni modifica va fatta tre volte.
02Che cosa realizzeremmo
Un unico portale su un design system condiviso, accesso con SPID e CIE, contenuti e integrazioni di ciascun servizio gestiti in configurazione e un solo ciclo di rilascio.
03Dove decidono le persone
I responsabili di ciascun servizio approvano contenuti e configurazione; il product owner decide sulle funzionalità comuni.
04Che cosa misureremmo
Problemi di accessibilità per rilascio, tempi di una modifica su tutti i servizi, quota di modifiche fatte una volta sola.

09 Settori

Nel Suo settore

  • Pubblica Amministrazione

    Gestione delle pratiche e portali per i cittadini conformi alle norme sull’accessibilità, disponibili in tutte le lingue ufficiali e collegati alle piattaforme nazionali di scambio dei dati.

  • Servizi finanziari

    Portali per i clienti e applicazioni di back office con audit trail solidi e processi di rilascio conformi alle regole di change management.

  • Manifattura e industria

    Configuratori, portali di assistenza e prodotti SaaS per i costruttori di macchinari, collegati all’ERP e al field service.

Italia

Accessibilità e sicurezza, secondo le regole italiane

In Italia l’accessibilità ha una lunga storia normativa: la Legge Stanca e le linee guida AgID per la PA, ora affiancate dall’Atto europeo sull’accessibilità, recepito in Italia, che dal 28 giugno 2025 estende gli obblighi a molti servizi privati. Il Cyber Resilience Act introduce per i prodotti con elementi digitali obblighi di segnalazione dal settembre 2026 e requisiti completi dal dicembre 2027.

Integriamo test di accessibilità e documentazione di sicurezza nella pipeline di rilascio, così le evidenze richieste da una gara o da un audit sono già pronte.

Domande su software aziendale e SaaS

Conviene sviluppare su misura o configurare una piattaforma?

Conviene configurare una piattaforma quando il processo è vicino allo standard, e sviluppare quando è proprio il processo a distinguerLa o quando nessuna piattaforma si adatta alle regole. Lavoriamo con Salesforce, SAP e Odoo oltre che con codice su misura, quindi non abbiamo interesse a orientare la scelta. Le nostre attività di architettura e consulenza rendono esplicita questa scelta.

Potete garantire che il nostro portale sia accessibile?

Sviluppiamo secondo EN 301 549 e WCAG 2.2 AA, eseguiamo test automatici e manuali e consegniamo un rapporto di conformità con gli eventuali problemi noti. Non promettiamo zero problemi; promettiamo di individuarli, segnalarli e correggere quelli che rientrano nel nostro perimetro.

Potete modernizzare senza una migrazione big bang?

Sì, ed è ciò che consigliamo. Una facciata di instradamento ci permette di spostare una funzionalità alla volta mentre l’applicazione esistente continua a funzionare, con i dati riconciliati a ogni passaggio.

Il nostro team interno può prendere in carico il software?

È il piano predefinito. I criteri di passaggio vengono concordati all’inizio, i Suoi sviluppatori lavorano in coppia con i nostri durante lo sviluppo e registri delle decisioni e runbook risiedono nei Suoi repository.

Che cosa comporta il Cyber Resilience Act per il nostro prodotto?

Se immette sul mercato dell’UE software che rientra tra i prodotti con elementi digitali, il regolamento può comportare obblighi di progettazione sicura, gestione delle vulnerabilità e documentazione. Noi costruiamo le evidenze tecniche: SBOM, un processo di gestione delle vulnerabilità e impostazioni predefinite sicure. La valutazione giuridica resta in capo ai Suoi consulenti legali.

Ci dica che cosa deve continuare a funzionare mentre cambia

Le proporremo la prima funzionalità da migrare e che cosa resterà al Suo team alla fine del percorso, partendo dai vincoli del Suo capitolato o della Sua roadmap.

Parliamo del Suo progettoScoprire il nostro approccio