Unione di due applicazioni in una sola

Vedo qui due domande distinte:

1. La funzionalità combinata ha senso?
2. Il lavoro di conversione delle due applicazioni in una sola passa un'analisi costi / benefici?

La prima domanda dovrebbe essere puramente guidata dall'utente. Ha senso che gli utenti abbiano queste due serie di funzioni insieme? È probabile che alcuni di loro vogliano vedere una vista meno dettagliata e quindi passare alla visualizzazione più dettagliata? E così via.

La seconda domanda riguarda il reale lavoro di sviluppo in questione. Potrebbe essere un'enorme quantità di lavoro con poco beneficio. Oppure potrebbe persino salvare il lavoro in generale, se l'applicazione combinata è più semplice e più gestibile in futuro. Anche il lavoro di sviluppo per affrontare i problemi di sicurezza dovrebbe essere considerato parte di questo (è improbabile che ci siano problemi di sicurezza insormontabili, ma potrebbe essere molto lavoro rendere sicura l'applicazione combinata).

Non abbiamo le informazioni per rispondere a queste due domande, ma sarebbe utile per te considerarle separatamente nel decidere come rispondere al tuo capo.

Se non credi che il software combinato soddisfi il n. 1, la tua risposta sarebbe qualcosa come temo che questo non soddisfi le esigenze dei nostri utenti / clienti, per questi motivi: ... Non è un'obiezione sulla quantità di lavoro, ma sul fatto che il prodotto finale non è un obiettivo desiderabile.

Se vedi il vantaggio di combinare le applicazioni in astratto, ma pensi che sia troppo lavoro, a mio parere la migliore risposta è non dire "non dovremmo farlo" ma provare a presentare una stima di come molto impegno che il progetto prenderà. Spetta al tuo capo decidere il rapporto costi / benefici, in definitiva, ma puoi fornire informazioni per aiutarti (ed evidenziare le dimensioni dell'attività).

È importante anche perché il tuo capo vuole che tu faccia questo . Se non lo sai, dovresti cercare di saperne di più sui motivi. Forse c'è un buon fondamento logico di cui non sei a conoscenza. Oppure, forse le ragioni non sono molto buone, ma ti aiuteranno ad avere una risposta più informata.

La mia opinione è che questo dipenda dalla tua definizione di 'Applicazione'

Diciamo che hai la seguente struttura n-tier

• Database A
• Database B
• Servizio Web A
• Servizio Web B
• Applicazione C

Dove A è il tuo cliente di fronte a cose e B è il monitoraggio a basso livello.

Quindi siamo separati da tutti i livelli fino all'applicazione C che unisce i servizi A e B per creare uno strumento combinato. Penso che questo sia perfetto e il design 'corretto'. Abbiamo ancora una separazione completa delle preoccupazioni in termini di business logic ma presentiamo sia all'utente che tramite un singolo sito Web o applicazione o altro.

Ho notato che hai taggato la tua domanda 'design del database' questo mi porta a pensare che la tua struttura potrebbe essere più simile

• Database C
  • Tabelle A
  • Tabelle B
• Applicazione C

Penso che questo porti ad un problema, poiché non avrai una chiara separazione degli oggetti e della logica di business per i due gruppi di operazioni. Il pericolo è che questi si confondano e cambiano in una pausa o espongono problemi di sicurezza nell'altra.

Tuttavia, un utente non sviluppatore che utilizza l'Applicazione C conosce la differenza? o è solo un 'dettaglio di implementazione'?