Sviluppo Software Enterprise: Che Cosa State Comprando

Lo sviluppo software enterprise, così come l’espressione viene usata sui siti della maggior parte delle agenzie, indica lo stesso lavoro con accanto un numero più grande. Il team è lo stesso, il processo è lo stesso, la presentazione guadagna un muro di loghi e il prezzo triplica. I compratori lo sanno, ed è per questo che gli uffici acquisti hanno imparato a ignorare la parola e a leggere gli allegati.

Sotto, però, una distinzione reale esiste, e non riguarda la dimensione dell’azienda. Un assicuratore da quaranta persone può condurre un programma davvero enterprise, e un retailer da dodicimila persone può commissionare qualcosa che in realtà è solo un sito web. A separarli sono gli obblighi che il sistema impone a chi lo costruisce: con quanti altri sistemi deve parlare, per quanto tempo può restare fermo, chi può bloccare un rilascio, quale autorità di vigilanza ha un interesse e che cosa succede se il fornitore se ne va.

Quel che segue definisce la categoria attraverso quegli obblighi, perché un compratore distingua un fornitore capace di sostenerli da uno che vende un progetto ordinario con una copertina enterprise.

Che cosa rende davvero enterprise un progetto software? Non la dimensione del compratore. Un progetto è enterprise quando porta vincoli che un progetto ordinario non ha: un’ampia superficie di integrazione, un obbligo contrattuale di disponibilità e ripristino, un’esposizione normativa, più gruppi di portatori di interesse che possono bloccare un rilascio, volumi di dati che rompono i progetti ingenui e la necessità di convivere con sistemi che oggi nessuno capisce. Sono quei vincoli, non l’elenco delle funzioni, a decidere l’architettura e gran parte del costo.

Che cosa rende enterprise un progetto

Il test utile è un elenco di vincoli, e un progetto si qualifica quando ne porta la maggior parte invece che uno solo. Applicato onestamente squalifica molto di ciò che viene venduto come enterprise, e qualifica lavori venduti come piccoli che poi falliscono proprio perché sono stati dimensionati così.

La superficie di integrazione

Contate i sistemi con cui il vostro nuovo software deve scambiare dati, poi contate quanti team o fornitori distinti possiedono quei sistemi. È il secondo numero a predire il costo. Tre integrazioni di proprietà di un solo team interno sono due settimane di lavoro. Tre integrazioni di proprietà di tre fornitori, ciascuno con la propria finestra di modifica, la propria disponibilità di sandbox e il proprio supporto, sono un trimestre.

Ogni proprietario porta un calendario che non controllate. Un fornitore la cui sandbox si aggiorna una volta al mese detta il vostro ritmo di test, e un gestore di pagamenti la cui certificazione richiede sei settimane fissa la vostra data di avvio. Con una dozzina di controparti il calendario delle integrazioni diventa il piano di progetto, e lo sviluppo si incastra negli spazi vuoti.

L’obbligo di disponibilità

Dal software ordinario ci si aspetta che funzioni. Il software enterprise ha un numero attaccato a quell’aspettativa, di solito in un contratto con dietro una penale. Il numero cambia prima di tutto l’architettura, perché un rilascio su una sola istanza non può rispettarlo, per quanto buono sia il codice.

Il passaggio da un obiettivo che tollera una finestra di manutenzione a uno che non la tollera è la voce più costosa nella maggior parte dei budget enterprise, e viene spesso concordato da persone che non ne hanno mai visto il prezzo. Il nostro pezzo sugli SLA di disponibilità che significano qualcosa spiega come si scrivono quei numeri e quanto spesso vengano scritti male.

Portatori di interesse con potere di veto

Un progetto ordinario ha un product owner. Un progetto enterprise ha un product owner, una funzione di sicurezza delle informazioni, un responsabile della protezione dei dati, un responsabile acquisti, un team di infrastruttura che possiede la rete, un service desk che erediterà il carico di supporto e spesso un revisore clinico, legale o di conformità.

Ciascuno di loro può fermare un rilascio, e nessuno risponde alla persona che paga il lavoro. Le decisioni richiedono quindi tempo di calendario slegato dalla loro difficoltà, e un fornitore che non lo ha messo nel piano sbaglia ogni data dal secondo mese in poi.

I sistemi che nessuno capisce più

Ogni parco applicativo enterprise contiene almeno un sistema il cui comportamento è documentato solo dal suo output. Chi lo ha scritto se n’è andato, e la specifica, se esiste, descrive una versione precedente. Funziona, è portante e modificarlo è considerato imprudente.

Il nuovo software deve convivere con esso, quindi qualcuno deve prima stabilire che cosa faccia davvero. Questa è archeologia, non sviluppo: leggere i dati di produzione, tracciare le chiamate, condurre esperimenti controllati su una copia e scrivere le regole che il codice implica. Su un parco grande sono settimane di lavoro, ed è la voce più spesso cancellata in trattativa perché non produce alcuna funzione visibile.

Cancellarla sposta il lavoro nei test di integrazione, dove viene scoperto sotto pressione da persone che stanno già correggendo difetti. Un fornitore che quota la discovery separatamente e la difende vi sta dicendo qualcosa di vero su come falliscono questi programmi. La nostra nota sulla modernizzazione del legacy e la scelta fra riscrittura e refactoring descrive che cosa trova quell’archeologia.

Gli acquisti sono metà del lavoro

La maggior parte dei tecnici sottovaluta questa parte di un fattore tre. In un incarico davvero enterprise il lavoro fra la prima conversazione e la prima riga di codice dura più del primo incremento di consegna, e consuma tempo dei vertici da entrambe le parti.

Dal 24 febbraio 2025 il settore pubblico britannico opera secondo il Procurement Act 2023, e i fornitori che partecipano a gare pubbliche devono essere registrati sulla piattaforma digitale centrale all’interno del servizio Find a Tender ampliato. Gli acquisti privati non hanno una porta d’ingresso unica equivalente, il che paradossalmente li rende più lenti, perché ogni compratore si è inventato la propria.

Il questionario di sicurezza

Vi manderanno un foglio di calcolo. Chiederà del vostro ciclo di sviluppo, dei vostri controlli di accesso, della vostra cadenza di patch, dei vostri subappaltatori, della residenza dei dati, dei vostri tempi di risposta agli incidenti e delle verifiche sui vostri dipendenti. I compratori più grandi mandano diverse centinaia di domande, e una banca o un ente del NHS ne manda di più.

Le domande non sono difficili, ma sono rispondibili solo se le risposte esistono già come policy. Un fornitore che le mette insieme per la prima volta durante una gara impiega da quattro a sei settimane e ne sbaglia parecchie. Chi lo ha già fatto risponde in pochi giorni attingendo a una libreria di risposte mantenuta, il che è una ragione legittima per preferirlo.

Accreditamento del fornitore, assicurazioni e verifiche finanziarie

L’accreditamento è separato dalla gara e spesso corre in parallelo. Aspettatevi di dover dimostrare una polizza di responsabilità civile professionale e una polizza cyber al livello indicato dal compratore, una copertura per la responsabilità verso i dipendenti e talvolta una responsabilità di prodotto. I compratori enterprise richiedono di norma massimali che una piccola società di consulenza non porta di default, e alzare la copertura a gara in corso richiede tempo.

Seguono le verifiche finanziarie. I compratori scaricano i bilanci depositati, chiedono un punteggio di credito e, sui contratti più grandi, situazioni contabili o una garanzia della capogruppo. Un fornitore il cui stato patrimoniale non regge il valore del contratto viene escluso a prescindere dal merito tecnico, ed è per questo che piccole aziende capaci perdono gare che erano giuste per loro.

Perché il ciclo di vendita dura più del primo incremento

Mettete le due linee temporali una accanto all’altra e la forma del problema diventa chiara. Qualifica, requisiti, revisione di sicurezza, negoziazione legale, prove assicurative e accreditamento occupano di norma da quattro a nove mesi su un contratto da diverse centinaia di migliaia di sterline. Il primo incremento utile di software, una volta partito il lavoro, può richiedere dieci settimane.

Le stime scritte all’inizio di quel ciclo sono superate alla firma, e un fornitore che tiene un prezzo fisso lungo tutto l’intervallo o sta caricando parecchio o conta di discutere il perimetro più avanti. Anche le ipotesi tecnologiche invecchiano, e una versione attuale in fase di offerta può essere fuori supporto all’avvio.

Datate ogni stima, dichiarate le sue ipotesi e concordate una ritaratura alla firma invece di far finta che il numero sia sopravvissuto. I compratori che pretendono che la cifra iniziale regga stanno comprando una coda di richieste di modifica. La nostra guida a scrivere un capitolato software che ottiene preventivi utili spiega che cosa deve stare nel documento.

I requisiti non funzionali sono la vera consegna

Gli elenchi di funzioni sono facili da scrivere e decidono poco. I requisiti non funzionali decidono l’architettura, la bolletta dell’infrastruttura, la dimensione del team e la durata del ciclo di test, e nella maggior parte dei programmi enterprise occupano due paragrafi in un documento la cui lista di funzioni arriva a quaranta pagine.

Quello squilibrio è il segnale più affidabile di uno sforamento. Un fornitore che dedica il primo workshop a disponibilità, ripristino, latenza, throughput, tracciabilità e conservazione non sta temporeggiando: quei sei numeri eliminano gran parte delle opzioni architetturali, e fissarli tardi significa ricostruire.

Scriveteli come affermazioni verificabili con un numero e una condizione. Il sistema deve essere ad alta disponibilità non è un requisito. Il servizio ordini deve sostenere una disponibilità mensile del 99,9 per cento misurata al bilanciatore di carico, esclusa una finestra di due ore annunciata cinque giorni lavorativi prima: questo lo è, perché un test può bocciarlo.

Punto di ripristino e tempo di ripristino in parole semplici

Due di quei numeri pesano sul costo più di qualsiasi funzione, e vengono citati di continuo da persone che ne hanno scambiato i significati. L’obiettivo di punto di ripristino è quanti dati siete disposti a perdere: un RPO di un’ora significa che accettate che dopo un disastro possa sparire fino a un’ora di transazioni, e il vostro schema di backup o replica non deve fare peggio. L’obiettivo di tempo di ripristino è per quanto siete disposti a restare fermi, quindi un RTO di quattro ore significa che il servizio torna a servire traffico entro quattro ore dall’inizio dell’incidente.

Entrambi i numeri si traducono direttamente in architettura. AWS espone quattro strategie generali nella sua guida al disaster recovery: backup e ripristino, pilot light, warm standby e multi-sito attivo/attivo. Vanno da economiche e lente a costose e quasi istantanee, e la scelta viene fatta al posto vostro non appena i due obiettivi sono concordati.

Evitate di concordare numeri aggressivi perché suonano responsabili. Un RPO pari a zero con un RTO di minuti significa replica continua e un secondo ambiente attivo, che raddoppia all’incirca la bolletta dell’infrastruttura. Il nostro approfondimento sul disaster recovery per piccoli team software mostra che cosa comprano i livelli meno costosi.

Aritmetica della disponibilità e che cosa compra davvero uno SLA

Le percentuali di disponibilità nascondono il loro significato dietro una virgola. Su un mese di 30 giorni, il 99,9 per cento consente circa 43 minuti di fermo, il 99,95 per cento circa 22 minuti e il 99,99 per cento circa 4 minuti. Quello è il budget dell’intero mese, inclusi i rilasci, i rinnovi dei certificati e il failover del database che ha richiesto più del previsto.

Quattro minuti al mese non sono raggiungibili da un team che rilascia in orario d’ufficio e sveglia un solo ingegnere. Servono ridondanza a ogni livello, failover automatico, rilasci che non interrompono il traffico e qualcuno sveglio alle tre di notte. Quest’ultima voce di solito costa più dell’infrastruttura e quasi mai è nel budget iniziale. Fissate nel contratto anche il punto di misura, perché la disponibilità letta al bilanciatore di carico e quella letta dalla telemetria reale degli utenti possono differire di un ordine di grandezza sullo stesso incidente.

Latenza, throughput e il carico che nessuno ha misurato

Gli obiettivi di latenza richiedono un percentile e un perimetro, perché le medie nascondono i fallimenti. Un obiettivo dichiarato di 200 millisecondi al 95esimo percentile per l’endpoint di pagamento sotto un carico di 400 richieste al secondo è verificabile. Un obiettivo di rapidità non lo è, e nemmeno una media, dato che una media di 200 millisecondi è compatibile con un utente su venti che aspetta quattro secondi.

Il throughput richiede un picco, non una media. I retailer dimensionano per il venerdì prima di Natale, i sistemi di paghe per l’ultimo giorno lavorativo del mese e i servizi pubblici per la scadenza scritta nella lettera spedita. Dimensionare sulla media annuale è il modo in cui un lancio fallisce nella sua prima ora di traffico. Prendete il picco dai log del sistema esistente, dove rapporti di dieci a uno sono comuni, perché quel rapporto decide se il progetto ha bisogno di una coda.

Tracciabilità e conservazione

I compratori regolamentati, e sempre più anche quelli non regolamentati, devono poter rispondere anni dopo a chi ha cambiato che cosa e quando. Questo è un requisito di progettazione, non una configurazione di logging: un sistema che sovrascrive le righe non può rispondere, e la risposta deve sopravvivere finché la politica di conservazione lo prevede.

Decidete tre cose presto. Quali eventi sono tracciabili, di norma i cambi di stato su record con rilievo legale o finanziario invece di ogni richiesta HTTP. Per quanto tempo viene conservata ciascuna classe di record, una questione legale con un vincolo di protezione dei dati attaccato, perché tenere dati personali più a lungo del necessario è già di per sé una violazione. E chi può leggere la traccia, perché un registro di audit che gli amministratori possono modificare non prova nulla. Conservazione e diritto alla cancellazione si scontrano qui, e la tensione si risolve nello schema più che nella policy.

Le certificazioni che un compratore chiederà

Tre ricorrono di continuo, vengono costantemente confuse e provano cose diverse. Un fornitore che non sa spiegare la differenza non le possiede.

Cyber Essentials e Cyber Essentials Plus

Cyber Essentials è la linea di base sostenuta dal governo britannico, sviluppata dal NCSC e erogata tramite IASME come partner ufficiale di attuazione. Copre cinque controlli tecnici: firewall, configurazione sicura, gestione degli aggiornamenti di sicurezza, controllo degli accessi utente e protezione dal malware. Il livello base è un questionario di autovalutazione riesaminato in modo indipendente, e il NCSC indica prezzi a partire da GBP 320 più IVA a seconda della dimensione dell’organizzazione.

Cyber Essentials Plus sono gli stessi cinque controlli verificati da un audit tecnico indipendente invece che dichiarati. Il valutatore esegue scansioni di vulnerabilità interne ed esterne e verifica un campione di dispositivi utente, gateway internet e server esposti su internet. L’audit Plus deve essere completato entro tre mesi dalla certificazione base, e i due certificati durano dodici mesi.

Lo schema conta sul piano commerciale quanto su quello tecnico. PPN 014, in vigore dal 24 febbraio 2025 nei dipartimenti del governo centrale, nelle loro agenzie, negli enti pubblici non ministeriali e negli enti del NHS, impone la certificazione quando i fornitori trattano dati personali dei cittadini, dati personali dei dipendenti pubblici o sistemi informatici che elaborano dati classificati OFFICIAL.

ISO/IEC 27001

ISO/IEC 27001 è la norma internazionale per un sistema di gestione della sicurezza delle informazioni, pubblicata da ISO e IEC. L’edizione in vigore è ISO/IEC 27001:2022, con l’emendamento 1 del 2024 che aggiunge alle clausole di contesto un testo sull’azione per il clima, in linea con una modifica applicata a tutte le norme ISO sui sistemi di gestione.

È una norma di sistema di gestione, ed è proprio questa la parte che i compratori leggono male. Non prescrive un insieme fisso di controlli che ogni organizzazione certificata avrebbe implementato. Richiede che l’organizzazione definisca il proprio perimetro, valuti i propri rischi, selezioni i controlli e conduca un ciclo documentato di riesame e miglioramento. La certificazione viene rilasciata da un organismo accreditato dopo un audit, non dall’ISO stessa.

La domanda utile quindi non è mai se un fornitore la possieda, ma che cosa copra la dichiarazione di perimetro riportata sul certificato. Un perimetro limitato a una funzione di sede non vi dice nulla sul team che tiene il vostro codice sorgente e le vostre credenziali di produzione. Chiedete il certificato e leggete il perimetro.

SOC 2

SOC 2 è americano e di natura diversa. L’AICPA lo definisce come una relazione sui controlli di un’organizzazione di servizi rilevanti per sicurezza, disponibilità, integrità dell’elaborazione, riservatezza o privacy, svolta secondo i suoi trust services criteria. È una relazione di attestazione prodotta da uno studio di revisione, non un certificato, e non esistono né una soglia di superamento né un logo da esporre.

La distinzione che conta è il tipo. Una relazione di tipo 1 descrive i controlli e valuta se siano progettati in modo adeguato in un dato momento. Una relazione di tipo 2 verifica se abbiano operato efficacemente lungo un periodo, di norma sei o dodici mesi. Il tipo 1 è una fotografia e il tipo 2 è un film, e i compratori che accettano un tipo 1 come equivalente stanno accettando molto meno di quanto credano.

Leggete la relazione, non la copertina. La sezione delle eccezioni, dove il revisore annota i controlli che non hanno operato come descritto, porta l’informazione, ed è la parte che i fornitori sperano che saltiate.

Che cosa nessuna di esse prova

Nessuna delle tre certifica che il vostro software sia sicuro. Cyber Essentials copre una linea di base di igiene dell’infrastruttura. ISO 27001 copre il fatto che l’organizzazione gestisca la sicurezza come processo. SOC 2 copre il fatto che i controlli dichiarati abbiano operato lungo un periodo. Tutte e tre riguardano il fornitore, non il prodotto.

La sicurezza applicativa è una disciplina distinta con prove distinte. Chiedete l’ultimo rapporto di penetration test e lo stato della relativa remediation invece del muro di certificati, e verificate chi lo ha eseguito e su quale perimetro. Questa è la sostanza dietro i nostri servizi di penetration test.

Esposizione normativa per settore

La normativa è il punto in cui i consigli generici sull’enterprise diventano pericolosi. Quel che segue nomina obblighi verificabili e si ferma prima della consulenza legale, che dovreste chiedere a un professionista qualificato.

UK GDPR, che riguarda quasi tutti

Se il sistema tocca dati personali, l’articolo 32 del UK GDPR si applica sia al titolare sia al responsabile del trattamento. Richiede misure tecniche e organizzative adeguate e ne nomina quattro: pseudonimizzazione e cifratura, riservatezza, integrità, disponibilità e resilienza permanenti dei sistemi di trattamento, la capacità di ripristinare tempestivamente la disponibilità dei dati personali e l’accesso agli stessi dopo un incidente, e una procedura per testare e valutare regolarmente l’efficacia di quelle misure.

Rileggete la terza, perché rende il disaster recovery un obbligo di protezione dei dati e non una preferenza operativa. La guida dell’ICO sulla sicurezza dei dati indica Cyber Essentials come linea di base utile, precisando però che si tratta solo di un insieme minimo di controlli e che non coprirà la situazione di ogni organizzazione né i rischi di ogni trattamento.

Servizi finanziari e sanità, in breve e con cautela

Nei servizi finanziari il regime di resilienza operativa della FCA impone alle imprese interessate di individuare i servizi aziendali importanti, fissare tolleranze di impatto per ciascuno e riuscire a restare entro quelle tolleranze durante un’interruzione grave ma plausibile. Il periodo transitorio si è chiuso il 31 marzo 2025, quindi l’obbligo è attivo e determina che cosa un fornitore di quelle imprese deve dimostrare.

Nella sanità e nell’assistenza, un sistema informatico sanitario ricade negli standard di gestione del rischio clinico di NHS England: DCB0129 per i produttori e DCB0160 per le organizzazioni che lo adottano. Entrambi sono in revisione nazionale, con una consultazione pubblica aperta dal 29 giugno 2026 all'11 settembre 2026, quindi verificate la posizione attuale prima di affidarvi a un riassunto, compreso questo.

Se il vostro settore non è nominato qui, trattate l’obbligo in modo generico: individuate l’autorità di vigilanza, leggete i requisiti che pubblica e chiedete al fornitore prove rispetto a quelli invece che una narrazione di garanzia generica.

L’architettura di integrazione è dove finiscono i soldi

Il costo enterprise si concentra nelle cuciture fra i sistemi, non al loro interno. Le funzioni sono di solito ben comprese. Far concordare sei sistemi con modelli di dati diversi e nozioni diverse di che cosa sia un cliente è il punto in cui se ne va il calendario.

Punto a punto oppure un broker

Il punto a punto è la scelta predefinita perché la prima integrazione è davvero più semplice così. Il costo è combinatorio: con n sistemi che si parlano direttamente si tende verso n al quadrato connessioni, ciascuna con la propria logica di ritentativo, le proprie credenziali e il proprio monitoraggio. Con quattro sistemi va bene. Con quindici non è più manutenibile.

Un broker o un bus di eventi inverte quella curva. Aggiunge un componente, un carico operativo e un punto singolo di guasto da progettare, e si ripaga intorno al sesto o all’ottavo partecipante. L’errore si commette in entrambe le direzioni: i parchi piccoli comprano una piattaforma di integrazione di cui non hanno bisogno, e quelli grandi la rimandano finché la maglia non si è calcificata.

Sincrono oppure guidato dagli eventi

Una chiamata sincrona è facile da ragionare e accoppia la disponibilità. Se il vostro servizio chiama quattro sistemi in linea e ciascuno è attivo il 99,9 per cento del tempo, il vostro tetto è di circa il 99,6 per cento prima ancora di aver scritto un difetto. Ogni dipendenza sincrona è una quota della vostra disponibilità consegnata al team operativo di qualcun altro.

I progetti guidati dagli eventi disaccoppiano tutto questo, al prezzo di una coerenza finale e di un debug molto più difficile. Tenete le chiamate sincrone per il percorso in cui l’utente sta aspettando e una risposta stantia è inaccettabile, e spostate tutto il resto sugli eventi. Decidete per singola interazione invece che come stile aziendale.

Idempotenza, riesecuzione e riconciliazione

I sistemi distribuiti consegnano i messaggi più di una volta e ogni tanto li perdono, quindi ogni percorso di scrittura che attraversa un confine deve poter essere ripetuto in sicurezza. Il modello consolidato è una chiave di idempotenza generata dal client. L’implementazione di Stripe salva il codice di stato e il corpo della prima richiesta per una data chiave, restituisce lo stesso risultato ai tentativi successivi, elimina le chiavi dopo almeno 24 ore e segnala un errore se la stessa chiave arriva con parametri diversi.

La riesecuzione è la metà operativa della stessa idea. Dopo che un sistema a valle è rimasto non disponibile per sei ore, qualcuno deve spingere i messaggi persi, il che è sicuro solo se i consumatori sono idempotenti e i messaggi sono stati conservati. Progettate la finestra di conservazione e il meccanismo di riesecuzione insieme al percorso felice, perché aggiungerli dopo significa modificare ogni consumatore.

La riconciliazione viene trattata come un ripensamento e non dovrebbe. È un job pianificato che confronta lo stato di due sistemi che dovrebbero coincidere, segnala le differenze e o le corregge o le porta a un essere umano. Senza di essa, una divergenza silenziosa da un sistema contabile viene trovata mesi dopo da un revisore. Mettetela a budget come consegna di prima classe, con un responsabile e un canale di allerta, non come uno script che qualcuno scrive alla fine.

Convivenza con il legacy e il fico strangolatore

La sostituzione integrale di un sistema che funziona è l’opzione più rischiosa disponibile e viene scelta molto più spesso di quanto dovrebbe. L’alternativa incrementale è documentata da Microsoft come modello del fico strangolatore: mettere una facciata davanti al sistema esistente, instradare le richieste attraverso di essa e spostare le funzioni un pezzo alla volta finché il vecchio sistema non ha più traffico e può essere spento.

Ogni incremento ha valore autonomo ed è reversibile in modo autonomo: se la terza fetta va male, la instradate indietro. Microsoft è esplicita su dove il modello non si applica, cioè quando le richieste al back end non possono essere intercettate, quando non potete modificare il sorgente esistente o quando il sistema è abbastanza piccolo da rendere più facile una sostituzione diretta.

Due dettagli decidono se funziona. La facciata non deve diventare un collo di bottiglia né un punto singolo di guasto, quindi richiede la stessa ingegneria di disponibilità dei servizi che stanno dietro. E le chiamate fra sistemi durante la transizione hanno bisogno di uno strato anticorruzione, perché la semantica del vecchio sistema non filtri nel nuovo progetto. I dati sono più difficili del traffico: portare fuori le tabelle di un dominio significa un caricamento iniziale, un flusso di cattura delle modifiche, un periodo di validazione in cui entrambi gli archivi vengono scritti e confrontati, e solo allora il passaggio, con rollback possibile finché gli oggetti vecchi non vengono eliminati.

Il collaudo su scala enterprise

Collaudare in un programma enterprise è un problema di logistica quanto di ingegneria, ed è il punto in cui muoiono i piani ottimistici.

Gli ambienti

Ve ne serviranno più di quanti ne avete messi a budget: sviluppo, un ambiente di integrazione collegato alle sandbox delle controparti, un ambiente di prestazioni abbastanza vicino alla produzione perché i suoi numeri significhino qualcosa, un ambiente di accettazione abbastanza stabile per persone non tecniche e occupate, e la produzione. Ognuno ha un costo di infrastruttura, un processo di aggiornamento e un responsabile. Quello che slitta sempre è quello di prestazioni, e saltarlo significa fare i test di carico in produzione.

I dati di test e il problema dei dati personali

I sistemi enterprise hanno bisogno di dati realistici su cui collaudare, e i dati realistici sono i dati di produzione, che contengono informazioni personali. Copiarli in un ambiente di test è un trattamento ai sensi del UK GDPR, e gli obblighi dell’articolo 32 li seguono fin lì, incluso il controllo degli accessi e la sicurezza dell’ambiente che li ospita.

Le risposte difendibili sono l’anonimizzazione, che deve essere irreversibile per portare i dati fuori dal regolamento, oppure la pseudonimizzazione, che riduce il rischio ma li tiene dentro. Entrambe richiedono lavoro di ingegneria per preservare la forma statistica che rende i dati utili, e un processo documentato. Ripristinare un database di produzione in un ambiente di test condiviso è comune, illecito in molte configurazioni ed esattamente ciò che una valutazione del fornitore è progettata per far emergere.

I test di prestazione

I test di prestazione rispondono alla domanda se il sistema raggiunga i numeri di throughput e latenza concordati prima, quindi possono esistere solo se quei numeri sono stati scritti. Collaudate il profilo di picco invece della media, e includete la forma del picco, perché una rampa su dieci minuti e un gradino in un secondo sollecitano modalità di guasto diverse.

Eseguiteli su volumi di dati di produzione. Una query istantanea su 10.000 righe e inutilizzabile su 40 milioni è il difetto di prestazione più comune nel software enterprise, ed è invisibile su un piccolo insieme di dati.

Il collaudo di accettazione con persone che hanno un altro lavoro

Il collaudo di accettazione viene pianificato su una finestra di due settimane ed è la fase che sfora più regolarmente, perché i collaudatori sono gli esperti di business e il business continua ad averne bisogno. Vi daranno qualche ora a settimana, e la loro disponibilità crolla a fine mese.

Nominate i collaudatori nel contratto, concordate le ore a settimana, scrivete gli scenari in anticipo invece di chiedere alle persone di esplorare, e conducete il triage dei difetti come sessione congiunta invece che come coda di ticket. Un fornitore che quota due settimane di accettazione senza partecipanti nominati non ne ha mai condotta una.

Modello di consegna e governance

La forma di team che funziona è piccola e stabile invece che grande e a rotazione: un responsabile tecnico che tiene l’architettura per l’intero programma, da tre a sei ingegneri, un responsabile di consegna che gestisce il calendario delle controparti e accesso condiviso a un ingegnere della qualità e a uno specialista di infrastruttura. Aggiungere persone in corsa rallenta in modo affidabile un programma, perché il vincolo è il contesto, non le braccia.

Mettete per iscritto la titolarità delle decisioni prima del primo sprint. Nominate una persona che possa approvare le variazioni di perimetro, una che possa approvare i compromessi architetturali e una che possa accettare un rilascio. Se sono tre nomi, le decisioni richiedono giorni. Se sono comitati, richiedono settimane e il piano è finzione.

La cadenza di governo tiene onesto un programma lungo: revisione di consegna ogni due settimane con il gruppo di lavoro, comitato mensile con il titolare del budget e i detentori del veto nella stessa stanza, e uno stato scritto rispetto alla baseline originale invece che a quella rivista del mese scorso. Un fornitore il cui stato è permanentemente verde non sta gestendo il rischio, lo sta nascondendo.

Modelli commerciali e chi porta il rischio

Quattro modelli coprono quasi tutto, e ciascuno mette il rischio in un punto diverso. La domanda non è quale sia il migliore ma quale parte sia messa meglio per portare l’incertezza che avete davanti.

Il tempo e materiali si adatta al lavoro davvero incerto: discovery, archeologia del legacy o un’integrazione contro una controparte mal documentata. Il compratore porta il rischio e ottiene piena flessibilità, il che richiede fiducia e un ritmo di consumo che qualcuno guardi davvero.

Il tempo e materiali con tetto aggiunge un massimale ed è il compromesso ragionevole di norma, ed è così che strutturiamo la maggior parte dei nostri servizi di sviluppo software. Il fornitore assorbe lo sforamento sopra il tetto, il compratore sotto paga solo quel che usa e le due parti tengono onesto il perimetro. Aspettatevi che il tetto porti dal quindici al venticinque per cento di contingenza, perché un fornitore che mette il tetto al costo atteso o si sbaglia o sta preparando una richiesta di modifica.

Il prezzo fisso funziona solo dove il perimetro è davvero fisso, cosa che in un programma enterprise vale per un incremento e non per l’insieme. Incrementi a prezzo fisso da sei a dieci settimane, ciascuno dimensionato dopo l’atterraggio del precedente, danno certezza di budget senza far finta che qualcuno possa specificare diciotto mesi in anticipo.

Il servizio gestito è la forma giusta una volta che il sistema è in esercizio: un canone mensile che copre supporto, patch, monitoraggio e un plafond di modifiche definito, valorizzato come percentuale annua del costo di costruzione invece che a teste. Fate in modo che la definizione del servizio nomini i tempi di risposta e il percorso di escalation.

Sviluppo software enterprise: che cosa spinge il costo

I fattori di costo in ordine di impatto

L’ordine sorprende, perché le funzioni vengono per ultime. La superficie di integrazione viene per prima, e in particolare il numero di proprietari esterni invece del numero di endpoint. Gli obiettivi non funzionali vengono secondi, perché il passo da un servizio che può prendersi una finestra di manutenzione a uno che non può cambia ogni strato del progetto.

Terzo viene il carico di assurance e di regolamentazione: tempo di offerta, produzione di prove, supporto agli audit e un processo di rilascio più lento per tutta la durata del contratto. Quarta viene la migrazione dei dati con la riconciliazione, sistematicamente sottostimata perché la difficoltà sta nella qualità dei dati vecchi più che nel volume. Quinto viene il numero di gruppi di portatori di interesse, che fissa la latenza decisionale. Sesto il numero di ambienti. Il perimetro funzionale è settimo, ed è di solito l’unica cosa presente nel budget iniziale.

Fasce di prezzo indicative nel Regno Unito

Le fasce qui sotto sono stime interne da incarichi britannici, espresse come costo del primo anno comprensivo di discovery, costruzione, collaudo e avvio, ma al netto del tempo del personale del compratore. Sono indicative e non preventivi, e gli intervalli sono ampi perché i fattori qui sopra li spostano.

Detto senza la tabella: un servizio singolo con due o tre integrazioni, utenti interni e un obiettivo del 99,5 per cento si colloca fra GBP 120.000 e GBP 250.000 nel primo anno. Un sistema dipartimentale rivolto al cliente con da cinque a otto integrazioni al 99,9 per cento va da GBP 300.000 a GBP 700.000. Una piattaforma centrale che sostituisce un sistema legacy, con da dieci a venti integrazioni e un obiettivo del 99,95 per cento, va da GBP 900.000 a GBP 2,5 milioni. Un programma regolamentato multi-entità al 99,99 per cento parte intorno a GBP 2,5 milioni e sale.

Il costo di esercizio che non è nel budget

Aggiungete sopra il costo annuo di esercizio, che si colloca fra il quindici e il venticinque per cento del costo di costruzione all’anno una volta inclusi supporto, hosting, patch, lavoro di sicurezza e un modesto plafond di modifiche. Un budget che finanzia la costruzione e non l’esercizio produce un sistema che si degrada visibilmente nel secondo anno, e la nostra analisi del costo di manutenzione software spiega dove va quel denaro.

Uscita e continuità

Un fornitore che non potete lasciare è un rischio appoggiato sul vostro bilancio, ed è la clausola più spesso rinviata alla fine della trattativa, quando nessuno sta più attento. Quattro cose rendono possibile un’uscita.

Il codice sorgente e la sua storia appartengono a un repository che il compratore possiede o può prendere in carico su preavviso, insieme alla pipeline di build e alle definizioni di infrastruttura. Il codice senza la pipeline che lo costruisce è un archivio, non un bene funzionante.

La documentazione deve consentire a un terzo competente di gestire il sistema: architettura, contratti di integrazione, runbook per i guasti realmente accaduti e l’inventario delle credenziali. Il nostro pezzo sulla documentazione tecnica che viene letta descrive che cosa sopravvive a un passaggio di consegne.

Il deposito fiduciario copre il fornitore che fallisce più che quello che se ne va, depositando il sorgente presso un terzo per il rilascio su eventi definiti. Vale la pena averlo dove il fornitore è piccolo rispetto al contratto, e vale la pena leggerlo con attenzione, perché un deposito non verificato rilascia codice che non si compila. Abbiamo visto quando si giustifica in deposito fiduciario del software, chi ne ha davvero bisogno.

Infine, valorizzate il passaggio di consegne nel contratto. Un numero definito di giornate di trasferimento di conoscenza a una tariffa concordata, attivato su preavviso, trasforma una lite in una fattura. La stessa disciplina vale per i fornitori dei vostri fornitori, trattata nella nostra nota sulla sicurezza della catena di fornitura software.

Giudicare la credibilità enterprise di un fornitore in un incontro

Cinque domande stabiliscono gran parte di tutto questo in un’ora, e l’esitazione vi dice quanto la risposta.

Chiedete rispetto a quali obiettivi di disponibilità e ripristino hanno consegnato, e come veniva misurata la disponibilità. Un fornitore che ha portato un obbligo del 99,95 per cento nomina il punto di misura e l’organizzazione della reperibilità senza che glielo si chieda. Chi non lo ha fatto parla di ridondanza in termini generali.

Chiedete di vedere la dichiarazione di perimetro sul loro certificato ISO 27001, oppure la sezione delle eccezioni del loro SOC 2 di tipo 2. Sono richieste ordinarie per un fornitore che li possiede e imbarazzanti per chi ha solo un logo. Poi chiedete come hanno gestito una rottura di riconciliazione in produzione, cosa che nessuno può rispondere partendo dalla teoria.

Chiedete di quanto hanno sforato i loro ultimi tre programmi e perché. Tutti sforano, e la parte informativa è se conoscono il numero. Poi chiedete come si presenta il loro processo di uscita, in giornate e consegne. Un fornitore che lo ha messo per iscritto si aspetta di essere giudicato su quello.

Che cosa resta al compratore

La parola enterprise dovrebbe descrivere obblighi, non una fascia di prezzo. Una volta messi per iscritto la superficie di integrazione, gli obiettivi di disponibilità e ripristino, l’esposizione normativa e le condizioni di uscita, la rosa dei candidati si ordina da sola, perché la maggior parte dei fornitori non riesce a portare prove su quei quattro punti.

Mecanik lavora su questa forma di incarico attraverso i nostri servizi di sviluppo software, e sul versante assurance attraverso i servizi di penetration test. Se state mettendo insieme il requisito invece della rosa, la checklist di due diligence tecnica è un punto di partenza ragionevole, e sui numeri non funzionali vale la pena discutere per primi.

Domande frequenti

Che cosa conta come sviluppo software enterprise? L’enterprise si definisce per vincoli e non per la dimensione del compratore. Un progetto si qualifica quando ha un’ampia superficie di integrazione posseduta da più parti, un obbligo contrattuale di disponibilità e ripristino, un’esposizione normativa, più gruppi di portatori di interesse che possono bloccare un rilascio, volumi di dati che rompono i progetti ingenui e la necessità di convivere con sistemi legacy che nessuno comprende del tutto. Una grande società può commissionare un progetto ordinario, e una piccola impresa regolamentata uno davvero enterprise.

Quanto costa un programma software enterprise nel Regno Unito? Come stime interne da incarichi britannici, un servizio singolo con due o tre integrazioni e un obiettivo di disponibilità del 99,5 per cento va da GBP 120.000 a GBP 250.000 nel primo anno. Un sistema dipartimentale rivolto al cliente al 99,9 per cento va da GBP 300.000 a GBP 700.000. Una piattaforma centrale che sostituisce un sistema legacy va da GBP 900.000 a GBP 2,5 milioni. Aggiungete dal quindici al venticinque per cento del costo di costruzione all’anno per esercizio e supporto.

Un fornitore enterprise ha bisogno di ISO 27001, Cyber Essentials o SOC 2? Provano cose diverse. Cyber Essentials è una linea di base sostenuta dal governo britannico fatta di cinque controlli tecnici, con un livello Plus verificato da un audit tecnico indipendente e richiesto da PPN 014 per molti contratti pubblici. ISO/IEC 27001:2022 certifica un sistema di gestione della sicurezza delle informazioni, quindi la dichiarazione di perimetro sul certificato conta più del certificato stesso. SOC 2 è una relazione di attestazione statunitense di uno studio di revisione, e solo un tipo 2 verifica se i controlli hanno operato lungo un periodo.

Che cosa sono gli obiettivi di punto di ripristino e di tempo di ripristino? L’obiettivo di punto di ripristino è quanti dati accettate di perdere dopo un disastro, quindi un RPO di un’ora significa che può sparire fino a un’ora di transazioni. L’obiettivo di tempo di ripristino è per quanto accettate di restare non disponibili, quindi un RTO di quattro ore significa che il servizio deve tornare a servire traffico entro quattro ore. Entrambi spingono architettura e costo più di qualsiasi funzione, perché scelgono fra backup e ripristino, pilot light, warm standby e multi-sito attivo/attivo.

Che cosa deve prevedere sull’uscita un contratto software enterprise? Quattro cose. La proprietà o un accesso trasferibile al repository del codice sorgente, alla pipeline di build e alle definizioni di infrastruttura. Documentazione sufficiente perché un terzo competente gestisca il sistema, compresi i runbook e l’inventario delle credenziali. Un deposito fiduciario del codice dove il fornitore è piccolo rispetto al valore del contratto, con depositi verificati invece che non verificati. E una clausola di passaggio di consegne valorizzata che nomini le giornate di trasferimento di conoscenza e la tariffa, così che andarsene sia una fattura e non una lite.