Come documentare una strategia per l'aggiornamento del software commerciale?

Non abbiamo aggiornato il nostro RDBMS o sistema operativo server per quasi un decennio. Un altro pacchetto software mission-critical si avvicina a due decenni fa e non è stato supportato dal suo fornitore per gran parte di quel tempo. Alcuni tra i nostri dirigenti sembrano pensare che questa sia una buona cosa: abbiamo risparmiato tonnellate di denaro non acquistando gli aggiornamenti! Ora un software critico ha bisogno di un aggiornamento, ma la nuova versione non supporterà roba vecchia di decenni. Ora una manciata di noi sta perdendo i capelli cercando di capire come aggiornare tutto in una volta con tempi di inattività minimi.

Nel tentativo di evitarlo in futuro, alcuni di noi stanno prendendo in considerazione la creazione di un documento di piano strategico IT (che si adatterà al piano di strat dell'organizzazione, completando gli elementi nel documento più ampio relativo all'IT ... forse che rende tattico il documento ITpiano?) nella speranza di poterlo adottare come parte del piano strategico globale dell'agenzia. Mi sono offerto volontario di provare ad assemblare la sezione "Gestione del ciclo di vita del software" (o qualcosa del genere) per affrontare il problema sopra menzionato (con i chiodini d'ottone probabilmente in un documento separato dal piano strategico). Quasi tutti i fornitori di software pubblicano cicli di vita e piani di ammortamento per i loro prodotti, ed è abbastanza facile determinare un "punto debole" per ogni pezzo di software considerando tali informazioni insieme alle esigenze della nostra organizzazione. La parte difficile (per me comunque) sta mettendo insieme il piano per ogni pezzo in qualcosa di più coerente.

Come posso documentare che i client desktop A, B, C ... dipendono dal desktop OS X e RDBMS Y, che a loro volta dipendono dal server OS Z, e quindi ecco come li conserviamo tutti nei loro "punti deboli"? Devono esserci dei libri là fuori, ma tutto ciò che ho cercato su google mi ha portato solo ad approfondire le tattiche di aggiornamento di un singolo software piuttosto che la strategia per determinare quando implementare quelle tattiche.

Sembra che tu stia cercando di risolvere molti problemi contemporaneamente (e non sembra una buona idea).

Da quello che ho letto:

• SO e applicazioni obsoleti
• nessuna strategia a lungo termine
• problemi nel documentare la tua infrastruttura
• urgente necessità di aggiornare un'infrastruttura critica

Aggiornamento di "software critico"

La tua infrastruttura non è aggiornata a causa della decisione di qualcuno è facile da capire. Probabilmente sembrava una buona idea qualche tempo fa. Questo si riduce a ciò che Michael Hampton ha scritto nei commenti: per il management, stai parlando di pro e contro (rischi). Quindi, se la direzione è disposta a correre un rischio, allora ok (qualunque cosa tu ne pensi personalmente), ed è la sua responsabilità da ora in poi. Ma qualcuno dei ragazzi IT deve dire loro quali sono i rischi.

Quindi la prima cosa che vorrei cercare è: i manager erano a conoscenza dei rischi di software obsoleto? Lo hanno detto?

Onestamente, penso che probabilmente non troverai nulla di utile al riguardo, quindi non ci passerei troppo tempo. È solo qualcosa che ti può aiutare sulla falsariga di "te lo dicevamo da cinque anni".

Farei semplicemente un'analisi di cosa significhi davvero eseguire questo aggiornamento. Prepara un semplice foglio di calcolo con le attività e il tempo che impiegheranno (se non lo sai, ti indovina meglio e sottolinea esplicitamente che non lo sai per certo). Ma ricorda che questa "attività di aggiornamento" non è ben specificata, è impossibile farlo come tempo fisso / prezzo fisso.

Fare tali elenchi ti aiuterà anche a risolvere l'intero problema. La prossima cosa è creare un registro dei rischi e un elenco delle risorse necessarie.

Alla fine, dovresti avere un elenco di attività, un elenco di rischi, un elenco di materiale / persone di cui hai bisogno. In una parola, non gestire l'aggiornamento come un problema quotidiano, fallo come PROGETTO. Ciò ti consentirà di avere almeno un certo controllo sull'acuta necessità della tua azienda.

Se hai problemi con l'analisi delle attività da svolgere, puoi provare qualche mappa mentale (il mio sw preferito è xMind) e poi convertirlo in un documento più formale.

Si noti che quando si dispone di alcune opzioni su come eseguire l'aggiornamento, è necessario fornire ai propri manager un riepilogo delle possibili soluzioni (se ve ne sono altre), riepilogate in poche frasi, inclusi costi, risultati e rischi; menzionando idealmente l'opzione che consigli e perché. Perché la scelta finale è loro da fare - dopo tutto sono manager.

Forse in questo caso particolare: ricorda che l'aggiornamento potrebbe non essere affatto possibile.

Nessuna strategia a lungo termine

La creazione di un piano strategico non ti aiuterà ora. Non ti aiuterà affatto se si tratta di un documento elaborato all'interno del tuo reparto IT. Il piano strategico è qualcosa che deve essere legato alle esigenze aziendali.

Esempio di necessità aziendale: tra due anni apriremo nuovi uffici in Cina e Australia.

Attività IT derivate: preparatevi a far peggiorare i nuovi dipendenti, creare infrastrutture in uffici stranieri, fornire formazione ai nuovi dipendenti (possibilmente utilizzando la loro lingua madre), fornire connettività sicura da quegli uffici alla centrale, ...

Se le cose vanno bene, puoi avere una strategia forse ... tra qualche mese? Quindi circa un anno e mezzo fino a quando tutto non sarà concordato?

Manutenzione e documentazione della propria infrastruttura

Questa è un'eredità del passato e ora devi cambiare le cose. Dare priorità. Fai un elenco di cose che vuoi / devi fare ora per aggiornare la maggior parte delle cose. Scegli quale può attendere, crea una roadmap grezza. (Questa tabella di marcia dovrebbe essere parte della tua strategia IT quando ne hai una.)

Se stai aggiornando qualcosa che è andato bene, gestiscilo come attività quotidiana. Se stai gestendo qualcosa che può andare male (è "grande" in termini di tempo trascorso, persone allocate, ecc.), Gestiscilo come un progetto.

Esistono strumenti che possono aiutarti con la documentazione e le dipendenze del servizio - CMDB (ad esempio iTop). Ma farlo funzionare può richiedere del tempo e hai ancora bisogno di alcuni strumenti di documentazione. L'idea migliore è quella di impostare un wiki per la documentazione in cui tutti possano iniziare a documentare / prendere appunti da ora in poi. Puoi configurare una wiki in mezz'ora, quindi è un modo molto efficace per iniziare.

Nota personale: l'aggiornamento del vecchio sistema operativo sarebbe un enorme PITA, senza menzionare la documentazione (probabilmente errata / mancante). Non è più semplice installare nuovamente i server, migrare le app e documentare tutto dall'inizio?