Modernizzazione legacy - Parallel systems vs Extending Original application?

3

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.

  1. 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.

  2. 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.

  1. È 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.

  2. 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.

  3. 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.

  4. 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.

posta nesh_s 29.01.2018 - 17:30
fonte

2 risposte

3

Suppongo che tu abbia una piccola squadra e un budget limitato, quindi la mia risposta presuppone che quanto segue sia vero:

  • Il mantenimento di 2 applicazioni separate rappresenterebbe un grosso problema per il team
  • Il lavoro per integrare il nuovo prodotto non è banale
  • Il vecchio prodotto è prossimo alla fine della vita o è obsoleto dal nuovo prodotto che fa lo stesso lavoro meglio

A questo punto devi fare un bilancio di ciò che hai e dove avvengono i punti di integrazione. Nei commenti hai menzionato che la tua app fornisce visibilità sui dati manipolati dal tuo strumento. Quindi inizierei escludendo le possibilità.

  • Se dovessi eseguire entrambi i prodotti sugli stessi dati nello stesso momento, hai risultati coerenti? (in caso contrario, ciò esclude l'opzione n. 2 all'inizio)
  • Quanto impatto costringerebbe gli utenti a fare una scelta ogni volta che elaborano qualcosa. Una o due volte al giorno potrebbe non essere un grande impatto, ma quando deve accadere tutto il giorno l'impatto può avere un impatto significativo sulla quantità di lavoro che gli utenti possono svolgere.
  • Scopri come ciascun programma comunica i suoi risultati e quali sono le opportunità di integrazione.

Supponendo che entrambe le opzioni siano ancora sul tavolo, dovrai eseguire una serie di riscritture mirate . Per fare ciò in modo efficace, avrai bisogno del software di controllo della versione se non lo usi già. Ecco come andrà giù:

  • Scegli un obiettivo e un time-box. Dovrebbe essere qualcosa che pensi di poter ottenere in quel momento.
  • Annota i compiti che ritieni necessari per raggiungere l'obiettivo
  • Se sembra che tu stia scendendo in una tana di coniglio e le modifiche siano più estese di quanto pensassi inizialmente: annota la barriera un gradino sopra l'attività su cui stavi lavorando e ripristina le modifiche!
  • Se hai trovato una barriera per il tuo primo compito, diventa il tuo nuovo compito. Ripeti fino a raggiungere l'obiettivo.

Il tuo time-box è importante. Questo è fondamentalmente la quantità di tempo che puoi permetterti di sbagliare. Se batti il tempo, fantastico. Ma se il tempo è scaduto e sei solo una parte del percorso, o sei mal giudicato o ci sono altri passaggi che devono essere presi prima. Il time box ti aiuta ad essere onesto sul fatto che tu sia in una tana del coniglio o no.

Come primo obiettivo, potresti dare un'occhiata all'interfaccia di cui hai bisogno dal punto di vista della tua applicazione agli strumenti di terze parti. Quindi separa la logica in modo che l'applicazione invochi i giusti metodi nell'interfaccia e le chiamate di implementazione invochino le giuste chiamate al tuo attuale strumento di terze parti. Implementare una seconda implementazione dovrebbe essere più semplice una volta acquisito da quel processo.

    
risposta data 30.01.2018 - 15:29
fonte
0

A meno che il test automatico end-to-end sia facile, opterei per l'opzione 1.

@BerinLoritsch ha buoni punti, il mio ordine di passaggi sarebbe:

  1. Riduci le dipendenze: riassegna tutte le comunicazioni alle interfacce (per tutto controlla se ciò è possibile con App2)
  2. verifica se il codice funziona ancora su App1
  3. Facoltativo: prova a scrivere quanti più test di unità possibili su test delle interfacce, ma su App1 (quindi con dati specifici che funzionano per questo test e vengono ripristinati correttamente)
  4. Crea implementazione con App2
  5. Prova la nuova implementazione con gli stessi test di unità, poiché è costruita contro l'interfaccia, dovrebbe essere facile e un guadagno rapido

D'altra parte. entrambe le app non possono seguire / implementare la stessa interfaccia. l'opzione 2 è l'unico modo per andare. Assicurati di ricercare correttamente il codice prima di iniziare.

quindi il passo 0 dovrebbe essere: mappa (crea uno schema di) tutte le comunicazioni correnti tra la tua app e App1 controlla se è possibile essere sostituiti con App2.

    
risposta data 30.01.2018 - 15:49
fonte

Leggi altre domande sui tag