Progettare un nuovo sistema per sostituire legacy: inizieresti con un nuovo database e manterrai entrambi in modo indipendente fino allo switch? [chiuso]

Avrei entrambi i sistemi in esecuzione contemporaneamente. Migrare gradualmente utenti / clienti da quello vecchio a quello nuovo.

Il vantaggio di questo è che puoi testare il nuovo sistema con un sottoinsieme di clienti, evitando un cambio "big bang".

Lo svantaggio è che devi mantenere due sistemi piuttosto che uno. Tuttavia, se lo analizzi, probabilmente hai diversi "sistemi" nella tua azienda, quindi probabilmente sono più simili a 11 sistemi anziché 10. Che non suona così male, vero?

Ti costringe anche a guardare e automatizzare il processo di migrazione dei dati. come dovrai eseguirlo più volte. Ciò si traduce sicuramente in un prodotto migliore rispetto alla tentazione del manuale "lo faremo solo una volta" i passaggi dell'approccio del big bang

Temo che questo sia in gran parte basato sull'opinione.

Preferisco avere un unico sistema e fare in modo che l'aggiornamento faccia parte del ciclo di vita di quel sistema. Anche se le tue lingue o tecnologie cambiano, questo è ancora generalmente "migliore" per me.

Pro

• Gli utenti possono sapere che sta arrivando
• Gli utenti non sono in grado di dettare che il vecchio sistema era migliore, quindi devi tenerlo per sempre.
• Lo sviluppo continua su un percorso rettilineo (ish).
• Di solito le modifiche possono essere apportate in incrementi più piccoli. Perché devi ripetere la tabella degli utenti da zero, perché non puoi semplicemente creare una perdita di colonne da aggiungere, eliminare e modificare e farlo?
• Eviti di raddoppiare il lavoro. Puoi chiamare il sistema 1 "set di sole" e dire il tuo supporto per il tiro, ma alla fine continuerai a fare delle correzioni di manutenzione.
• eviti di raddoppiare il carico sul personale di supporto. Se hai "supporto tecnico" per il tuo prodotto ora devi solo addestrare nuovi assunti su un "sistema" non su due.

Cons.

• Può essere una sinfonia di informazioni più complicata per rendere gli utenti pronti per le modifiche, il supporto in atto, ecc. L'impossibilità di farlo causa un problema.
• Ci saranno regressioni. Non è qualcosa che puoi evitare, specialmente quando gli utenti sono quelli che riescono a nominare quali sono le regressioni.
• Se hai una schifezza, allora sei bloccato. Perdi la possibilità di eseguire alcune persone sulla versione 2 mentre i "grandi clienti" utilizzano la versione 1
• A seconda dei clienti, potrebbero sentirsi molto turbati nel dover riqualificare i propri dipendenti. Specialmente vero nelle configurazioni B2B.
• Probabilmente perderai i clienti. Specialmente se hai un numero elevato di clienti "inattivi ma a pagamento" e devi eseguire la procedura "aggiorna il pagamento".

Alla fine, però, si tratta dello strumento giusto per il lavoro. A volte devi solo eseguire due versioni, anche se di solito sono il primo a combattere per una sola versione.

Come si suol dire, chiunque può sviluppare un sistema migliore di quello attuale. Ciò che porta abilità è lo sviluppo del set di stampelle per passare dal vecchio sistema al nuovo sistema senza arrestare i processi aziendali.

Se avessi un numero di clienti paganti, andrei con due sistemi in esecuzione in parallelo e un passaggio graduale. (Se non ho un gruppo di clienti paganti, per chi riscrivo il sistema?)

Upsides:

• La tua attività continua a funzionare senza interruzioni importanti.
• I tuoi clienti non subiscono modifiche brusche e hanno tutto il tempo di migrare quando / dove necessario.
• Hai un buon sistema noto a cui tornare quando una particolare modifica nel nuovo sistema risulta causare problemi o addirittura un errore catastrofico.
• Hai la migliore suite di test possibile, il sistema live-running, come riferimento per il tuo nuovo sistema mentre viene costruito.
• Puoi migrare gradualmente i clienti o le funzioni e appianare eventuali nodi in un carico di produzione leggero ma reale, anziché con carico di prova.

Svantaggi:

• Devi progettare le tue funzionalità e i tuoi schemi di dati per lo stato di divisione durante il periodo di coesistenza di entrambi i sistemi, aggiungi ganci per aiutarli a comunicare, ecc.
• Devi progettare il nuovo sistema in modo che possa ragionevolmente funzionare quando implementato parzialmente, e piggy-back sul vecchio sistema per il resto delle funzionalità.
• Devi replicare i dati tra i sistemi.
• Devi essere tollerante ai ritardi causati dalla replica dei dati e / o possibili incongruenze nei dati a causa di ciò.
• Ci vorrà molto più tempo per riscrivere da zero e costerà di più.