Stiamo procedendo a modernizzare un'applicazione esistente esistente e, in quanto parte di questo, sostituiremo un prodotto proprietario di serie che è profondamente integrato con l'applicazione - con un nuovo prodotto disponibile immediatamente.
Ci sono due approcci che stiamo cercando per la coesistenza.
-
Aggiorna l'applicazione originale (ad esempio App1) per lavorare con entrambi i prodotti del fornitore (chiamandoli VP1 e VP2). Ciò significherebbe modificare la base di codice esistente e aggiornare tutti i punti di integrazione in modo che funzionino per entrambi i prodotti del fornitore. Stiamo pianificando di raggiungere questo obiettivo tramite un interruttore a livello di applicazione, quindi in base a una condizione, il flusso di processo utilizzerà l'implementazione per VP1 o VP2 per elaborare le richieste. Ciò significherebbe che una singola applicazione che ha entrambe le implementazioni (astratte tramite interfacce) può essere utilizzata per elaborare le richieste.
-
La seconda opzione è quella di avere due sistemi in esecuzione in parallelo durante il periodo di coesistenza. Il modo in cui viene proposto è creare una copia dell'applicazione esistente (App1), rimuovere tutte le implementazioni per il prodotto fornitore esistente VP1 e implementarle nuovamente con il nuovo prodotto fornitore VP2. Questa nuova copia dell'applicazione verrà quindi ospitata come istanza separata (chiamiamola NewApp1) e gli utenti dovranno passare dall'originale (App1 e NewApp1) per eseguire le funzioni aziendali durante la coesistenza. Questo è al fine di lasciare l'applicazione esistente così com'è e non di rompere la funzionalità corrente. Inoltre, è necessario ridurre al minimo lo sforzo necessario per riesaminare l'intera applicazione (App1) se viene modificata.
Quale dei due approcci è più adatto in caso di un'applicazione che sostanzialmente sostituisce il prodotto fornitore sottostante?
Modifica (30/01)
Aggiunta di un po 'più di contesto e logica a supporto dell'opzione n. 1 (almeno per il caso d'uso con cui ho a che fare). Questo va al di là di ciò che è già stato aggiunto nei commenti qui sotto.
-
È importante notare che l'applicazione in questione è un monolite, che è in produzione da molti anni. È giusto presumere che siano stati fatti più aggiornamenti all'applicazione come correzioni di bug, aggiornamenti minori che non sono documentati da nessuna parte ma nella base di codice.
-
Uno svantaggio di creare una copia e rimuovere l'implementazione relativa al prodotto del fornitore esistente e sostituirlo con un nuovo prodotto fornitore sarebbe stato che avremmo potuto perdere quelle regole commerciali tattiche.
-
Come è stato sottolineato nelle risposte di seguito, andare avanti con l'Opzione # 2 avrebbe comportato un costo associato alle attività di cambio di business a causa dell'introduzione di un processo manuale per selezionare quale applicazione utilizzare. Questo a sua volta avrebbe comportato la riqualificazione di più team.
-
Dal punto di vista dell'infrastruttura - c'era la possibilità di incompatibilità struttura / versione - quando si distribuiva la copia (dall'opzione # 2) al nostro più recente stack di infrastruttura standard. Se si procedesse con l'Opzione n. 1, si sarebbe trattato di ridistribuire lo stack esistente (sebbene non standard) anziché di rileggere l'intera applicazione allo stack standard (nel caso dell'opzione n. 2). Un'alternativa sarebbe stata quella di ruotare lo stack non standard per l'opzione n. 2, ma ciò avrebbe significato un sovraccarico di manutenzione.