Quali considerazioni dovrebbero essere date a favore e contro i siti "super"?

La mia azienda sta valutando di consolidare tutte le applicazioni e i siti di livello 1 (ovvero produzione di fascia alta) in un'unica base di codice onnicomprensiva.

La teoria è che le loro autorizzazioni, il design e la funzionalità generale possono essere omogeneizzati e gestiti centralmente.

Non ho fine alle preoccupazioni su questo approccio poiché le strutture di dati su cui si basa ogni applicazione sono molto diverse, le regole di business sono complesse e uniche per ogni applicazione e le basi di codice generali per le applicazioni esistenti sono estremamente disparate e molto trascurate.

MODIFICA :

L'ambiente attuale è costituito da tre siti ASP.Net 1.1 che hanno visto a malapena un vero amore da quando sono stati scritti (principalmente a causa dell'assenza di sviluppatori esperti nell'azienda) e un'applicazione MVC2 che era anche un sito ASP.Net 1.1 prima di essere aggiornato l'anno scorso. Scriviamo esclusivamente in C #.

La società è piuttosto piccola, con circa 50 dipendenti; tre dei quali sono veri sviluppatori. La gestione (anche la gestione IT) non ha alcun background o esperienza IT diversi dalla gestione dei progetti di progetti IT (e quindi una conoscenza approfondita della terminologia e degli impatti aziendali).

Le applicazioni sono principalmente servizi online a supporto dei prodotti venduti dall'azienda. La società non vende direttamente alcun software.

Quindi, per esprimere l'intera situazione in una domanda ragionevolmente specifica e rispondente: quali sono alcuni motivi convincenti a favore e contro il tentativo di riunire tutti i sistemi in un'unica soluzione over-arching date le condizioni attuali (ovvero vecchia base di codice, sistemi aziendali complessi e regole )?

Cattiva idea

Questa reazione si basa sui seguenti presupposti:

1. Ci sono molte applicazioni abbastanza disparate che sono omogeneizzate
2. Ci sono molti team che lavorano su diverse applicazioni
3. Non esiste un architetto software autorevole e rispettato che gestisca attivamente le applicazioni

Cosa succederà se vai avanti

Molto probabilmente ci sarà uno sforzo iniziale consolidato per riunire tutto sotto un unico approccio progettuale. Ciò mostrerà l'enorme sforzo richiesto per far funzionare tutto allo stesso modo e potrebbe essere considerato insostenibile.

Se si preme, sarà richiesto un tipo di repository centralizzato contenente dati di configurazione (ad es. Accesso di sicurezza, livelli di registrazione ecc.) A quel punto qualcuno indicherà l'ovvio e dirà

"Ehi, perché non adattiamo questo approccio di configurazione esternalizzato alle vecchie applicazioni, sarà molto più veloce?"

e un attimo dopo qualcun altro lo farà

"E, dal momento che stiamo eseguendo il refactoring, perché non applichiamo semplicemente uno standard di progettazione per ciascuno dei domini dell'applicazione: l'elaborazione del Web è simile a questa, l'elaborazione delle regole di business come questa e l'accesso al database come, ecc."

fino a quando finalmente

"Oh, e c'è un sacco di codice comune qui perché non mettere insieme alcune librerie facilmente condivise. Probabilmente avremo bisogno di una sorta di build di integrazione eseguita ad intervalli regolari, diciamo, ogni notte."

A quel punto ognuno emette un sospiro di sollievo che non fu costruito un enorme monolito.

Ci abbiamo lavorato sulla mia azienda. Penso che sia possibile e ci siano ovvi benefici (li hai citati), tuttavia, questo sarà probabilmente un progetto da 5 a 7 anni al minimo assoluto, e richiede praticamente tutto per essere riscritto. Se riesci a ottenere la firma su qualcosa del genere, allora direi di provarlo. Altrimenti, preparati per una marcia della morte da incubo.

Google lo fa, quindi sicuramente è possibile .

Quel link BTW è un'interessante presentazione di un googler su come gestiscono la loro base di codice, l'integrazione continua, i test ecc.

Senza un impegno altrettanto forte nei confronti degli strumenti, tuttavia, come ha fatto Google, è probabile che tu sia ferito in un mondo.

La domanda chiave qui è perché ? Perché il senior management vuole farlo? Quali risparmi, leva finanziaria o altri vantaggi sperano di ottenere?

Se riesci ad affrontare abbastanza di questi problemi in modo tale da raggiungere i loro obiettivi, puoi evitare la singola base di codice che ti riguarda, pur fornendo loro lo stesso risultato efficace.

Abbiamo attraversato un processo simile. Avevamo un prodotto che esisteva da un po '. L'anno scorso abbiamo introdotto un altro prodotto che è il 95% uguale al primo, con il 5% di differenze talvolta sottili ma significative, con quelle differenze che devono essere sviluppate e mantenute da un team separato.

Quando abbiamo iniziato a lavorare sul nuovo prodotto, il vecchio team ha continuato ad apportare modifiche che ci hanno influenzato negativamente in quel 5%, perché non capivano il nuovo prodotto. Quindi abbiamo completamente eliminato quel 5% di codice, che ci ha permesso di terminare la prima versione in tempo.

Quindi sono iniziati altri lavori di manutenzione e abbiamo scoperto che spesso facevamo modifiche quasi identiche in un codice quasi identico. Il vecchio team ora ha anche una comprensione molto migliore del nuovo prodotto, quindi stiamo gradualmente reintegrando ciò che abbiamo creato e trovando modi architettonici più efficienti per esprimere le differenze.

Quindi, quando dici che le strutture di dati sono diverse e le basi di codice complessive sono disparate, la domanda che vorrei porre è se devono essere così o è proprio come si sono evoluti a causa della convenienza del momento. Ovviamente devi tenere conto delle diverse regole e requisiti aziendali, ma la chiave è isolare quelle differenze nel più piccolo modulo possibile. Se ti capita spesso di implementare la stessa identica funzione per più clienti in modi leggermente diversi per basi di codice diverse, allora il consolidamento può davvero aiutare, e sospetto che sia il caso o il management probabilmente non lo proporrebbe.

Molto probabilmente non sarai in grado di consolidare numerose applicazioni nella stessa base di codice perché ciò richiederà un certo sforzo e per i vecchi programmi trascurati questo potrebbe essere molto più lavoro di quanto inizialmente previsto.

Detto questo, non c'è nulla di sbagliato nell'avere tutte le applicazioni nello stesso repository di codice , in cui ogni applicazione ha un'area separata. Ciò consente, ad esempio, di avere tutta la documentazione online generata per l'intera base di codice in un'unica vista coerente, che in genere è una buona cosa in quanto si desidera la massima visibilità possibile.

Coloro che decidono questo, dovrebbero considerare fortemente PERCHÉ vogliono farlo, e considerare quanto lavoro vogliono spendere per arrivarci.

Se esiste un'unica cosa che rende lo sviluppo aziendale così inefficiente e costoso, è l'illusione che sia possibile creare un unico sistema che faccia tutto. Se tu avessi un unico proprietario del prodotto in grado di comprendere tutti i dettagli del sistema e di poter prendere tutte le decisioni senza aver bisogno di una settimana di riunioni, potrebbe funzionare, ma non l'ho mai visto accadere.

In generale, starai meglio se la consideri più simile allo sviluppo per Internet: costruisci la tua app, ammettendo che in pratica hai il controllo zero di qualsiasi cosa al di fuori del tuo codice. Puoi ottenere praticamente tutta la coerenza che potresti desiderare con OAuth e una semplice API per le impostazioni utente e un po 'di CSS condiviso.

Questo è abbastanza simile all'intento originale di SOA, ma se lo chiami finirai con un diverso tipo di sistema grande, a malapena funzionante che cerca di fare tutto.

Il mio primo pensiero è che questo sarebbe un PITA totale per le versioni.

Suddividere in blocchi gestibili di funzionalità è molto più sensato, se non altro per evitare tutti i livelli di gestione e approvazione.

Rompere elementi comuni in componenti / servizi e standardizzare in questo modo sarebbe molto più facile IMHO.

Puoi affrontarlo in modo diverso, utilizzando una tecnologia di integrazione come Deliverance per tema tutte le tue applicazioni web in modo simile. Fondamentalmente, ogni applicazione è ancora separata; Deliverance utilizza le regole XSLT per trasformare il loro output in un modello HTML statico progettato. Ciò consente di applicare un tema HTML / CSS statico relativamente semplice a un'intera suite di applicazioni con un minimo di guai.