Definire il piano di uscita quando si sceglie il software
Il codice aperto facilita le modifiche. Dati, account e servizi da trasferire dipendono dall’ambito scelto per l’uscita.
Un piano di uscita dovrebbe indicare già nella scelta di una soluzione software quale cambiamento dovrà essere possibile in futuro. Un nuovo team di sviluppo, un nuovo ambiente di hosting e la sostituzione completa dei servizi collegati sono progetti diversi. Definire presto questo confine permette di accettare consapevolmente le dipendenze e concordare le prove necessarie.
Il codice aperto non elimina le dipendenze esterne
Una licenza conforme all’Open Source Definition dell’OSI comprende l’accesso al codice sorgente e la possibilità di distribuire modifiche e opere derivate. Non trasferisce automaticamente un servizio di ricerca ospitato, un account aziendale o i documenti conservati al suo interno.
Nel portale fittizio P-18, il codice dell’applicazione ha una licenza open source. I documenti originali sono in un archivio di file separato, le assegnazioni delle persone ai progetti nell’applicazione e l’indice di ricerca presso un servizio gestito. Un nuovo sviluppatore può modificare il codice. Ritrovare gli stessi documenti con le stesse regole di accesso dopo un cambio di fornitore resta una questione distinta.
Distinguere l’ambito del cambio prima dell’acquisto
Nell’esempio sono possibili tre obiettivi. La tabella indica prove attese, non una migrazione già eseguita.
Obiettivo del cambio | Cosa può restare nell’esempio | Prova necessaria |
|---|---|---|
Hosting, archivio e servizio di ricerca | Il nuovo team lavora con i propri account autorizzati; responsabilità e documentazione necessaria sono state trasferite. | |
Nuovo ambiente di hosting per l’applicazione | Archivio e ricerca sotto il controllo dell’azienda | L’applicazione raggiunge i servizi dal nuovo ambiente e continua ad applicare le regole di accesso concordate. |
Sostituzione completa dei servizi collegati | Non è necessario mantenere i fornitori attuali | Documenti originali, metadati descrittivi e associazioni dei permessi sono trasferibili; ricerca e accessi vengono nuovamente verificati nella destinazione. |
Un indice di ricerca copiato non sostituisce automaticamente i documenti originali e le loro associazioni. Per ricostruirlo occorre sapere da dove arrivano testo, identificativi stabili dei documenti e permessi. Un formato di indice compreso soltanto dal vecchio servizio non è ancora una prova di consegna utilizzabile per un altro motore di ricerca.
Mantenere consapevolmente un vincolo può avere senso
Un servizio gestito può offrire un beneficio che giustifica l’impegno di un cambio futuro. La guida del governo britannico sulla dipendenza tecnica raccomanda di bilanciare l’impatto del cambio con il beneficio di restare. Tratta anche i formati aperti e la disponibilità di conoscenze nel team.
Per la seconda riga può essere ragionevole continuare a usare il servizio di ricerca. Deve allora essere chiaro chi gestisce l’account, può concedere accessi e seguirà il servizio dopo il cambio. Se anche questo servizio deve essere sostituibile, l’accesso ai dati e la prova di un’alternativa si aggiungono all’ambito. L’etichetta «open source» non risolve questa scelta.
Inserire l’ambito scelto nell’incarico
Un accordo concreto per l’esempio potrebbe dire: «L’applicazione deve poter passare a un altro ambiente di hosting. L’archivio documentale e la ricerca restano nei nostri account aziendali. Nel nuovo ambiente verifichiamo l’apertura di un documento consentito e il rifiuto dello stesso documento per un ruolo limitato».
Il vincolo mantenuto diventa così visibile e la verifica è collegata a un compito concreto. Se in seguito sarà necessario cambiare completamente prodotto, si potranno individuare dati, interfacce e conoscenze aggiuntive mancanti. Il piano di uscita deve essere aggiornato mentre il sistema cambia.
Fonti
Continuate a leggere
Tutti gli articoli
Sviluppo software con ASES
Software su misura, app web e mobile