L’espansione di Broadcom VCF riunisce AI, sicurezza e ripristino in un’unica piattaforma

Broadcom ha annunciato la sua più recente espansione del portafoglio il 4 novembre, combinando infrastruttura AI privata, sicurezza e modifiche al ripristino con un’offerta di virtualizzazione più contenuta. L’espansione di Broadcom VCF trasferisce più responsabilità aziendali all’interno di VMware Cloud Foundation, la sua piattaforma software per cloud privato. Tuttavia, l’annuncio comprende capacità esistenti, rilasci futuri e servizi avanzati separati. Queste distinzioni sono importanti per i clienti che decidono cosa possono implementare e cosa devono ancora acquistare.

Il compromesso centrale riguarda il consolidamento operativo. La condivisione dell’infrastruttura può ridurre l’amministrazione duplicata, ma concentra anche le decisioni su accesso, manutenzione e ripristino. Gli acquirenti aziendali devono valutare se una piattaforma più ampia semplifica il loro ambiente operativo effettivo. Un elenco più lungo di funzionalità non può rispondere da solo a questa domanda.

Nutanix offre un utile riferimento competitivo perché combina anch’essa l’infrastruttura con la gestione dell’AI aziendale. L’annuncio di Broadcom rientra quindi in una competizione più ampia su come le aziende gestiscono l’AI insieme alle applicazioni consolidate. Per i responsabili dell’infrastruttura, la decisione immediata riguarda quanta responsabilità consolidare all’interno di una piattaforma condivisa.

Cosa cambia realmente con l’espansione di Broadcom VCF

L’annuncio combina distribuzione del prodotto, sviluppo futuro e packaging del portafoglio, che richiedono decisioni di implementazione differenti.

Gli aggiornamenti del cloud privato di Broadcom distinguono le funzionalità già distribuite dalle aggiunte pianificate per il primo trimestre dell’anno fiscale 2027. La condivisione dei modelli multi-tenant è arrivata con VCF 9.1.1, mentre il confidential computing è apparso in VCF 9.1. Il confidential computing protegge i dati durante l’elaborazione tramite hardware supportato.

Le aggiunte pianificate includono AI Infrastructure Quickstart, object storage nativo compatibile con S3, gestione della conformità dell’infrastruttura, connettività basata su policy e disaster recovery nativo. Quickstart è pensato per automatizzare la configurazione iniziale dell’infrastruttura AI. La compatibilità S3 descrive un’interfaccia per archiviare e recuperare oggetti, come file e artefatti dei modelli.

Broadcom identifica inoltre HyperArmor, Live Recovery e la gestione della conformità dei workload all’interno del proprio portafoglio di servizi avanzati. Queste offerte hanno finalità diverse rispetto alle funzionalità native dell’infrastruttura. La loro collocazione è importante perché gli acquirenti devono stabilire quali capacità siano effettivamente incluse nei loro accordi.

La conseguenza pratica è una valutazione del rilascio più complessa di quanto suggerisca il titolo. Un responsabile dell’infrastruttura non può trattare ogni capacità annunciata come immediatamente disponibile. Né un team di sicurezza dovrebbe presumere che un servizio avanzato diventi automaticamente parte della propria implementazione.

Una valutazione utile separa lo stato di distribuzione dalla rilevanza architetturale. Una funzionalità può essere pertinente alle esigenze di un’azienda pur restando inadatta al suo attuale calendario di implementazione. Al contrario, una funzionalità disponibile può comunque richiedere modifiche hardware, preparazione del personale o ulteriore validazione.

Questa distinzione diventa particolarmente importante quando i team organizzano i progetti attorno alle scadenze di approvvigionamento. Un annuncio stabilisce la direzione di un fornitore. La documentazione di rilascio stabilisce cosa gli amministratori possono installare, mentre il linguaggio contrattuale stabilisce cosa l’organizzazione può utilizzare.

L’espansione di Broadcom VCF combina inoltre l’automazione dell’infrastruttura con controlli destinati a governare tale infrastruttura. Sono investimenti collegati, ma risolvono problemi diversi. Una distribuzione più rapida aiuta i team a creare un ambiente; la governance determina cosa possono fare in sicurezza una volta che esiste.

Per esempio, automatizzare la configurazione di un cluster non decide quale reparto possa accedere a documenti riservati. Fornire storage non stabilisce una policy di conservazione. Aggiungere l’orchestrazione del ripristino non determina quale applicazione debba tornare operativa per prima dopo un incidente.

Si tratta di distinzioni analitiche, non di carenze dimostrate dall’annuncio. Le aggiunte di Broadcom possono supportare tali decisioni senza prenderle al posto del cliente. L’azienda necessita comunque di un modello operativo che colleghi le funzionalità tecniche ai requisiti di business.

Quel modello operativo offre il quadro appropriato per valutare l’aggiornamento. La domanda è se le aggiunte eliminino attività specifiche, migliorino controlli applicabili o colmino una lacuna documentata nel ripristino. Senza questo collegamento, l’espansione del portafoglio resta difficile da tradurre in valore operativo.

L’infrastruttura AI condivisa mette sotto pressione i team di piattaforma

Centralizzare i modelli AI sposta la responsabilità verso i team che gestiscono accesso, capacità e continuità del servizio.

Broadcom afferma che l’infrastruttura di modelli condivisa può servire più unità interne mantenendo confini di sicurezza separati e contesto privato. Il vantaggio proposto è una minore duplicazione tra i reparti. Si tratta di un’affermazione del fornitore sui vantaggi dell’architettura, piuttosto che di una prova indipendente di risparmi in uno specifico ambiente cliente.

Il meccanismo sottostante è comprensibile. Reparti separati talvolta desiderano accedere a capacità di modello simili lavorando però con informazioni diverse. Un servizio centrale offre un modo per condividere l’implementazione del modello senza condividere deliberatamente i dati di ogni reparto.

Tuttavia, la condivisione rende il team della piattaforma responsabile di più della sola disponibilità. Deve definire chi riceve l’accesso, come le richieste concorrenti ricevono risorse e quali modifiche richiedono approvazione. Queste responsabilità persistono anche quando il provisioning diventa più semplice.

Si consideri un’organizzazione ipotetica con assistenti per gli affari legali, l’ingegneria e il supporto clienti. Ogni assistente utilizza un servizio di modelli condiviso, ma recupera informazioni da repository differenti. L’infrastruttura può essere comune mentre documenti, utenti e azioni autorizzati restano diversi.

Questa configurazione crea una sfida concreta di governance. Il diritto di un dipendente a usare il modello non implica il permesso di recuperare ogni documento connesso. Analogamente, il permesso di leggere un documento non implica l’autorità di modificare un altro sistema aziendale.

È qui che VMware private AI diventa una decisione organizzativa. Amministratori dell’infrastruttura, proprietari delle applicazioni e team di sicurezza necessitano di definizioni compatibili dell’accesso. Altrimenti, ogni gruppo può credere che un altro gruppo possieda un controllo che nessuno ha implementato.

La gestione della capacità introduce un’altra pressione. Un servizio condiviso deve accogliere priorità aziendali diverse senza consentire a un workload di consumare ogni risorsa disponibile. La policy appropriata dipende dalle esigenze aziendali, non dalle impostazioni predefinite della piattaforma.

Un esperimento di sviluppo e un’applicazione rivolta ai clienti possono avere tolleranze molto diverse per i ritardi. Condividere la loro infrastruttura sottostante non elimina tale differenza. I proprietari della piattaforma necessitano di un modo per preservare queste priorità durante contese e manutenzione.

Lo stesso problema si applica alle modifiche. L’aggiornamento di un modello distribuito centralmente può influenzare più applicazioni che dipendono da esso. I team applicativi necessitano quindi di un processo per valutare il comportamento modificato prima che un aggiornamento condiviso raggiunga la produzione.

Questa analisi non stabilisce che la condivisione dei modelli di Broadcom crei un rischio inaccettabile. Identifica le responsabilità che accompagnano il consolidamento. Il confronto rilevante è tra lo sforzo dipartimentale duplicato e la disciplina necessaria per gestire un servizio comune.

Una distinzione correlata si applica alla conoscenza aziendale. I controlli dell’infrastruttura stabiliscono l’ambiente in cui opera un assistente, mentre i controlli delle informazioni determinano cosa può recuperare. La distinzione tra basi di conoscenza aiuta a spiegare perché la sola posizione di implementazione non possa risolvere la policy di accesso.

La pressione ricade più direttamente sui responsabili dell’infrastruttura cui viene chiesto di supportare l’AI senza creare un altro ambiente operativo isolato. Devono dimostrare che la centralizzazione migliora l’erogazione del servizio. Ciò richiede prove sul comportamento dei workload, sullo sforzo amministrativo e sull’applicazione delle autorizzazioni.

Per gli sviluppatori, il beneficio dipende da ciò che la piattaforma condivisa rende prevedibile. Un processo di richiesta coerente, restrizioni documentate e una chiara titolarità possono essere importanti quanto la velocità di implementazione iniziale. Queste sono le condizioni che trasformano l’infrastruttura disponibile in un servizio interno utilizzabile.

L’integrazione compete con la scelta operativa

La strategia di consolidamento di Broadcom compete con modi alternativi di assemblare e governare l’infrastruttura AI aziendale.

I controlli AI aziendali di Nutanix offrono un confronto pertinente. La sua release Enterprise AI 2.8 descrive autorizzazioni granulari, condivisione controllata dei modelli e opzioni di implementazione per ambienti disconnessi. La release distingue inoltre le capacità generalmente disponibili dalle anteprime, una distinzione che gli acquirenti dovrebbero mantenere nel confronto tra fornitori.

Il confronto stabilisce priorità sovrapposte piuttosto che un vincitore assoluto. Entrambi gli approcci affrontano l’accesso alle risorse AI all’interno dell’infrastruttura aziendale. L’inventario delle funzionalità di nessuno dei due fornitori, da solo, stabilisce quale piattaforma sia adatta a una particolare organizzazione.

I clienti Broadcom possono apprezzare l’estensione di un ambiente che i loro amministratori già conoscono. Procedure familiari possono ridurre parte del lavoro di transizione, a condizione che le nuove capacità si adattino alle responsabilità esistenti. Questo vantaggio dipende dal punto di partenza del cliente e non dovrebbe essere presunto universalmente.

Altre organizzazioni possono privilegiare la possibilità di sostituire indipendentemente infrastruttura, servizi di modelli e strumenti di sicurezza. Questo approccio può preservare la scelta, ma richiede ai team di mantenere le connessioni tra i componenti. La flessibilità crea propri obblighi operativi.

La tensione principale riguarda quindi l’operatività integrata rispetto al controllo indipendente. Una piattaforma consolidata può rendere alcuni workflow più facili da coordinare. Un ambiente assemblato può offrire maggiore libertà nel modificare i componenti, richiedendo però più lavoro di integrazione.

Si tratta di compromessi architetturali, non di ragioni per presumere che una delle due strade sia intrinsecamente superiore. La scelta appropriata dipende dalle competenze del personale, dalle dipendenze applicative, dai requisiti hardware e dalla tolleranza dell’organizzazione al cambiamento. Gli acquirenti devono verificare direttamente tali condizioni.

Un confronto equo utilizzerebbe lo stesso workload rappresentativo nei diversi ambienti candidati. Esaminerebbe implementazione, restrizioni di accesso, manutenzione e ripristino. Confrontare soltanto la configurazione iniziale favorirebbe il prodotto che rende più semplice la dimostrazione iniziale.

Il workload dovrebbe inoltre assomigliare sufficientemente alla produzione da rivelare le dipendenze. Un assistente collegato a documenti interni approvati è più informativo di una dimostrazione di chatbot isolato. Il suo comportamento dipende congiuntamente da autorizzazioni, recupero, disponibilità del modello e configurazione dell’applicazione.

La documentazione merita attenzione durante questa valutazione. I team devono comprendere dove risiedono le policy e come gli amministratori possano ispezionarle. Un controllo esistente dal punto di vista tecnico può comunque risultare difficile da gestire se il suo comportamento resta poco chiaro.

La risoluzione dei problemi offre un altro confronto utile. Quando un'applicazione non funziona, gli amministratori devono identificare se il problema riguarda l'infrastruttura, l'identità, lo storage o il comportamento dell'applicazione. Il consolidamento genera valore quando aiuta a risolvere tale incertezza con un minore coordinamento.

L'ecosistema di servizi di Broadcom riflette anch'esso l'importanza dell'implementazione. L'alleanza per il cloud privato di Kyndryl descrive consulenza, modernizzazione e investimenti nelle competenze attorno a VCF. In qualità di partner commerciale, Kyndryl offre una prospettiva favorevole, anziché una valutazione indipendente dei risultati.

Il suo coinvolgimento evidenzia comunque un aspetto pratico: le capacità software richiedono architettura e preparazione operativa. I clienti devono ancora tradurre il portafoglio di un fornitore in policy, responsabilità e procedure funzionanti. Questo lavoro dovrebbe figurare nella valutazione accanto allo sforzo di implementazione.

L'espansione di Broadcom VCF rafforza la sua argomentazione a favore del consolidamento di maggiori responsabilità nell'infrastruttura VMware. L'accettazione di questa tesi da parte dei clienti dipenderà da riduzioni dimostrate dell'attrito operativo. I prodotti concorrenti restano rilevanti perché gli acquirenti possono confrontare diversi modi per soddisfare gli stessi requisiti aziendali.

La protezione dell'hypervisor non risolve la sicurezza delle applicazioni

Proteggere il livello di virtualizzazione affronta un rischio importante, lasciando però i controlli sulle applicazioni e sulle informazioni come responsabilità distinte.

L'annuncio di Broadcom sulla protezione dell'hypervisor descrive HyperArmor come una difesa preventiva per ESX, il livello software che esegue le macchine virtuali. L'azienda afferma che combina patching virtuale a livello host, controlli sui comportamenti consentiti e autenticazione aggiuntiva nel percorso di accesso amministrativo.

Il patching virtuale mira a bloccare lo sfruttamento di vulnerabilità senza sostituire prima il software vulnerabile. Broadcom presenta questo approccio come protezione durante le finestre di esposizione. I clienti dovrebbero distinguere questa affermazione da una garanzia contro ogni vulnerabilità o vettore di attacco.

L'annuncio include una valutazione favorevole dell'analista IDC Stephen Elliot sui controlli preventivi a livello hypervisor. La sua prospettiva sostiene l'importanza architetturale di quel livello. Non costituisce una convalida indipendente di ogni capacità di HyperArmor.

Per gli acquirenti, la domanda scettica riguarda l'ambito. Una difesa dell'infrastruttura può contrastare gli attacchi all'host senza stabilire se un'applicazione AI gestisca in modo appropriato le informazioni riservate. Questi controlli operano a livelli diversi del sistema.

Si immagini un dipendente autorizzato che chieda a un assistente interno di riassumere documenti che non dovrebbe ricevere. L'host potrebbe restare non compromesso per tutta l'interazione. Il problema riguarderebbe l'accesso alle informazioni o il comportamento dell'applicazione, anziché un attacco riuscito al software di virtualizzazione.

Analogamente, un modello collegato a uno strumento aziendale necessita di regole che disciplinino le azioni consentite. Impedire comandi host non autorizzati non determina automaticamente se un assistente possa inviare un messaggio o modificare un record. I proprietari delle applicazioni devono definire tali confini.

Questa distinzione è importante perché il linguaggio sulla sicurezza spesso diventa più ampio nel corso delle discussioni di approvvigionamento. Un prodotto progettato per un livello può diventare una scorciatoia per indicare la protezione dell'intero ambiente. Gli acquirenti dovrebbero mantenere l'ambito originario quando traducono le affermazioni tecniche in documenti di approvazione.

Il confidential computing richiede analoga attenzione. Proteggere i dati durante l'elaborazione affronta una specifica categoria di esposizione. Non stabilisce che ogni richiesta utente sia appropriata, che ogni documento recuperato sia autorizzato o che ogni risposta generata sia accurata.

La conclusione appropriata è quella della responsabilità a livelli. I controlli dell'infrastruttura, le policy di identità, le restrizioni delle applicazioni e la governance delle informazioni devono sostenersi reciprocamente. Rafforzare un livello non giustifica la rimozione di controlli altrove senza una ragione documentata.

Anche le procedure amministrative devono essere valutate. I team dovrebbero comprendere come funzioni l'accesso di emergenza autorizzato e come proceda il ripristino quando una dipendenza dall'identità non funziona. L'autenticazione aggiuntiva aiuta solo quando gli amministratori possono utilizzarla in modo affidabile nelle condizioni previste.

Nessuna di queste domande richiede di liquidare la direzione di Broadcom in materia di sicurezza. Prevenire la compromissione dell'host e limitare l'uso improprio dell'accesso privilegiato sono obiettivi significativi. La cautela riguarda l'estensione di tali obiettivi a affermazioni che le prove disponibili non supportano.

Una valutazione in produzione dovrebbe quindi testare comportamenti specifici anziché ampie etichette di sicurezza. L'amministratore previsto può eseguire un'attività approvata? Il sistema blocca un'azione vietata e il team riesce a spiegarne il risultato?

La stessa disciplina dovrebbe governare le affermazioni relative alle minacce AI. Gli acquirenti non devono accettare una narrativa generalizzata sugli aggressori per valutare un controllo. Devono identificare la minaccia affrontata, la protezione offerta e l'esposizione residua.

Il ripristino deve riportare un servizio affidabile

Le capacità di ripristino VMware meritano una valutazione a livello applicativo, oltre il semplice riavvio riuscito dell'infrastruttura.

I dettagli sulla disponibilità del portafoglio distinguono il disaster recovery nativo dal più ampio portafoglio di servizi avanzati. Network World riferisce che vSphere Express è disponibile immediatamente per ambienti più piccoli, fino a 128 core. Diverse aggiunte a VCF, comprese le capacità di ripristino e connettività, sono previste per il primo trimestre fiscale di Broadcom del 2027.

La distinzione è importante perché il disaster recovery e il cyber recovery rispondono a domande diverse. Il disaster recovery riguarda il ripristino delle operazioni dopo un'interruzione. Il cyber recovery richiede inoltre la certezza che l'ambiente ripristinato sia idoneo alla riconnessione dopo un attacco.

Per un'applicazione AI, ripristinare la capacità di calcolo è solo una parte del lavoro. Il servizio può dipendere da file del modello, documenti, autorizzazioni, impostazioni dell'applicazione e connessioni ad altri sistemi. La pianificazione del ripristino deve considerare congiuntamente tali dipendenze.

Si consideri un ipotetico assistente interno per l'ingegneria, ripristinato dopo un incidente di sicurezza. Le sue macchine virtuali si avviano correttamente e la sua interfaccia accetta richieste. Tuttavia, il suo indice documentale riflette autorizzazioni obsolete, mentre la configurazione dell'applicazione punta a un modello modificato.

Il ripristino dell'infrastruttura può riuscire mentre il servizio resta inadatto al normale utilizzo. Questo esempio illustra perché la convalida del ripristino necessita della titolarità dell'applicazione. Gli amministratori possono confermare che l'infrastruttura sia in esecuzione, ma i responsabili aziendali devono contribuire a stabilire che il servizio si comporti in modo accettabile.

Le capacità di ripristino VMware dovrebbero quindi essere valutate rispetto a un obiettivo di ripristino definito. L'obiettivo potrebbe riguardare il ripristino di un'applicazione approvata con regole di accesso aggiornate e materiale sorgente verificato. L'organizzazione deve specificare tale risultato prima di valutare le funzionalità di orchestrazione.

Una clean room, un ambiente isolato per esaminare i sistemi ripristinati, può sostenere questo processo. L'isolamento offre ai team spazio per indagare prima di riconnettere le dipendenze di produzione. Non stabilisce automaticamente che ogni artefatto o configurazione ripristinati siano affidabili.

La valutazione dovrebbe anche considerare come le decisioni di ripristino ricevano l'approvazione. Il personale di sicurezza, gli amministratori dell'infrastruttura e i proprietari delle applicazioni possono avere requisiti probatori diversi. Un processo documentato aiuta a evitare di scoprire tali differenze durante un incidente.

L'ordine di ripristino crea un'altra dipendenza pratica. Un'applicazione potrebbe richiedere servizi di identità, storage o connettività di rete prima di diventare utilizzabile. L'orchestrazione è importante quando riflette tale sequenza e aiuta i team a verificare ogni dipendenza.

Ciò è particolarmente rilevante per l'infrastruttura AI condivisa. La centralizzazione può rendere un servizio comune prezioso per più reparti, aumentando le conseguenze di un'interruzione prolungata. La pianificazione del ripristino dovrebbe riflettere l'importanza di tali applicazioni dipendenti.

Gli acquirenti dovrebbero inoltre distinguere una dimostrazione di funzionalità da un'esercitazione di ripristino. Una dimostrazione stabilisce che un flusso di lavoro possa operare in condizioni selezionate. Un'esercitazione esamina se le persone, le dipendenze e le procedure del cliente possano conseguire il risultato richiesto.

Le prove più solide collegherebbero l'automazione del ripristino alla convalida documentata dell'applicazione. I team dovrebbero sapere che cosa è tornato operativo, quali controlli sono stati superati e chi ha autorizzato la riconnessione. Ciò offre una base di fiducia più chiara rispetto a un solo indicatore di stato dell'infrastruttura.

Per le implementazioni VMware private AI, la domanda operativa è semplice: l'organizzazione può ripristinare un servizio di cui è disposta a fidarsi? La risposta dipende dalle funzionalità software e dalla preparazione che le circonda.

Cosa dovrebbero monitorare gli acquirenti fino alla prossima release

Le prossime prove dovrebbero dimostrare la consegna, i vantaggi pratici del consolidamento e il comportamento del ripristino in condizioni rappresentative.

Il primo segnale è la consegna della release rispetto all'ambito annunciato. I clienti dovrebbero monitorare la documentazione finale relativa alle aggiunte pianificate per infrastruttura, storage, connettività, conformità e ripristino. Il riferimento di Broadcom al trimestre fiscale dovrebbe restare distinto da una presunta scadenza di calendario.

Le prove rilevanti includono configurazioni supportate, limitazioni note e il rapporto tra funzionalità native e servizi avanzati. Questi dettagli determinano se una capacità annunciata si adatti a un ambiente esistente. Stabiliscono inoltre quale preparazione sia necessaria ai clienti prima dell'adozione.

Una consegna che corrisponda ai requisiti documentati dei clienti rafforzerebbe l'argomento di Broadcom a favore del consolidamento. Funzionalità mancanti, supporto limitato o disponibilità modificata lo indebolirebbero per le implementazioni interessate. La valutazione dovrebbe seguire i requisiti effettivi anziché l'ampiezza complessiva dell'annuncio.

Il secondo segnale è costituito dalle prove provenienti da implementazioni rappresentative di modelli condivisi. Gli acquirenti dovrebbero cercare risultati che spieghino le caratteristiche dei carichi di lavoro, i confini di accesso, il comportamento del servizio e lo sforzo amministrativo. Un titolo sull'efficienza delle risorse è difficile da valutare senza queste condizioni.

Prove utili mostrerebbero se i reparti possano condividere l'infrastruttura mantenendo un controllo appropriato sulle proprie informazioni e sui carichi di lavoro. Spiegherebbero inoltre che cosa il personale della piattaforma debba fare durante aggiornamenti, contese e risoluzione dei problemi. Ciò rivela se il consolidamento elimini lavoro o lo redistribuisca.

Le testimonianze indipendenti dei clienti sarebbero particolarmente preziose, poiché le dimostrazioni dei fornitori selezionano naturalmente condizioni favorevoli. Anche resoconti dettagliati possono essere utili quando descrivono onestamente le limitazioni. Gli acquirenti dovrebbero preferire un risultato spiegabile a un'affermazione di miglioramento non spiegata.

Il terzo segnale è la convalida del ripristino che coinvolga applicazioni complete. I clienti dovrebbero monitorare esercitazioni che colleghino l'infrastruttura ripristinata alle autorizzazioni, alle informazioni di origine e al comportamento dell'applicazione. Tali prove renderebbero più concrete le affermazioni sulla resilienza operativa.

Un esercizio riuscito rafforzerebbe l’argomentazione a favore di un ripristino integrato quando riduce il coordinamento mantenendo i controlli richiesti. Un esercizio che metta in luce dipendenze irrisolte identificherebbe il lavoro ancora necessario. Entrambi gli esiti sono più informativi che presumere che l’integrazione garantisca la disponibilità operativa.

Nel loro insieme, questi segnali offrono un metodo mirato per valutare l’espansione Broadcom VCF. La disponibilità definisce ciò che esiste. Le evidenze di implementazione definiscono come opera, mentre la convalida del ripristino stabilisce se l’organizzazione può farvi affidamento durante un’interruzione.

Per un’imminente revisione dell’architettura, scegliete un’applicazione rappresentativa e documentatene i requisiti di accesso, le dipendenze, il processo di manutenzione e i criteri di ripristino. Chiedete al team della piattaforma di associare ogni requisito a una funzionalità disponibile, a un’aggiunta pianificata o a una procedura operativa. In questa valutazione, mantenete distinti le funzionalità native e i servizi avanzati. Confrontate la stessa applicazione con un’alternativa credibile, usando condizioni e criteri di accettazione equivalenti. Per l’espansione Broadcom VCF, date priorità a evidenze che dimostrino minori attività amministrative, confini informativi applicabili e un servizio che si ripristini in modo accettabile. Prima di affidare un carico di lavoro di produzione, richiedete un’esercitazione di implementazione e ripristino che il responsabile dell’applicazione possa valutare. Quali responsabilità consoliderà il vostro team e quali evidenze stabiliranno che il servizio risultante soddisfa le sue esigenze?