Come può la mia transizione multinazionale da una piattaforma di sviluppo a un'altra?

Sto lavorando nel dipartimento IT di una grande azienda internazionale. Stiamo sviluppando diverse applicazioni Intranet per l'azienda (Reclami, Rimborsi, Service Desk ecc.). Ora abbiamo deciso di migrare dalla piattaforma PHP a .NET (l'integrazione con MS CRM Dynamics, Exchange e MS Office è tra le molte ragioni). Dato che ci sono circa 20 diverse applicazioni che l'azienda sta utilizzando sulla piattaforma PHP attuale, dovremo trovare il modo migliore per spostarle tutte sulla nuova piattaforma. Non voglio entrare nei dettagli su come convertire il codice ecc., Poiché mentre eseguiamo la migrazione vogliamo migliorare tutte queste applicazioni.

Quindi abbiamo escogitato 2 modi principali per spostare queste app:

1. Supporta solo una piattaforma. Cosa significherebbe? Crea homepage e migra letteralmente tutte le app così come sono in .NET (senza migliorarle mentre lo facciamo). Dopo l'esecuzione della nuova intranet, inizieremo a ricostruire le applicazioni migrate e migliorarle. Ciò ci salverebbe sviluppando intranet in .NET pur dovendo supportare la piattaforma PHP.

2. Supporta entrambe le piattaforme per qualche tempo. Ciò significherebbe costruire solo una homepage e 1 o 2 nuove applicazioni (che non esistono sulla nostra piattaforma PHP). Rendendoli disponibili per gli utenti senza togliere la piattaforma PHP (incorporeremmo menu e collegamenti per rendere più semplice agli utenti il ​​passaggio tra le app sulla pagina PHP e quella nuova). Quindi inizieremmo a riscrivere le applicazioni PHP migliorandole.

Ora non sono sicuro di cosa sarebbe meglio, da un lato (opzione 1) potremmo potenzialmente rendere tutto più facile per gli utenti non costringendoli a usare due piattaforme diverse contemporaneamente. Sebbene non vedranno alcun miglioramento nell'avere la nuova piattaforma, a parte tutto ciò che sembra più bello, la funzionalità delle applicazioni sulla nuova piattaforma sarà la stessa per qualche tempo. Inoltre penso che ci aggiungeremmo (reparto IT) più lavoro, dal momento che essenzialmente scriveremmo ogni app due volte.
D'altra parte nell'opzione due (2) utenti avrebbero un'esperienza peggiore in quanto due piattaforme sembrano diverse, ma si renderebbero conto dei vantaggi della nuova piattaforma quando le nuove applicazioni vengono spostate.

Qualcuno di voi ha incontrato qualcosa del genere? Cosa sceglieresti? O forse c'è anche un modo diverso e migliore di quelli che ho presentato? Vorrei sapere cosa ne pensate e come vi approcciate.

Consideriamo entrambi gli scenari:

Migrazione immediata

Durante la migrazione della base di codice, i clienti continueranno a utilizzare le app esistenti. Poiché la migrazione richiederà un tempo non banale, ciò significa che sarà necessario disporre di un team di manutenzione sulla base di codice precedente, per la correzione di bug e lo sviluppo di funzionalità. Ogni modifica apportata alla vecchia base di codice deve avvenire nella nuova base di codice. Finirai per scrivere ogni riga di codice due volte finché la migrazione non viene eseguita, rendendola più costosa quanto più tempo ci vuole per migrare. Quindi, tutto si riduce a: quale sarà il tempo di consegna per la migrazione completa? I costi di sviluppo saliranno alle stelle per tutto il tempo necessario.

Migrazione pezzo per pezzo

In questo scenario avrai un miglior controllo sul doppio sforzo, ma avrai comunque molti costi aggiuntivi. La distribuzione coinvolgerà due piattaforme separate, con il doppio dei problemi di distribuzione e risorse aggiuntive del server richieste. A meno che tu non abbia un'app organizzata in modo molto modulare, scoprirai che spesso è presente un pezzo di codice nell'altra piattaforma rispetto a quello su cui hai bisogno, causando ulteriori operazioni di porting e manutenzione. Finché la migrazione non viene eseguita, i costi di sviluppo saranno più elevati. Allo stesso tempo, la pressione delle funzionalità significherà che ci vorrà molto tempo per terminare la migrazione.

Conclusione

Per esperienza personale posso dirti due cose:

• Il cambio dei linguaggi di programmazione paga raramente. Da un'analisi costi-benefici, è molto improbabile che sia vantaggioso passare a .NET da PHP. Quindi il mio consiglio principale è: no. Prova a risolvere i tuoi problemi con la tua base di codice esistente.
• L'approccio pezzo per pezzo è l'approccio migliore, ma avrai difficoltà a farlo a livello di moduli applicativi. Scoprirai che dovrai sviluppare e mantenere funzionalità su entrambi i lati dell'architettura fino a quando la migrazione non sarà completa. Può essere una buona idea dare la priorità alle funzionalità non in base a ciò di cui i clienti hanno più bisogno ma a ciò che limiterà la quantità di doppio sforzo (riducendo così i costi).

Per motivi finanziari, la maggior parte delle aziende con cui ho lavorato ha adottato il secondo approccio, giustamente potrei aggiungere. Ci vogliono un sacco di soldi, tempo e rischi per raggiungere il numero 1. Per lo più l'utente capirà il n. 2 fintanto che vedrà i tuoi progressi e l'interazione con loro. In questa economia magra e meschina, dubito che qualcuno avrebbe adottato l'approccio numero 1.

Gli approcci al big bang raramente sono costruttivi per quanto riguarda gli utenti finali. Vorrei sconsigliarlo e ad essere sincero, non posso credere che qualcuno lo considererebbe seriamente come un'opzione dato il numero di domande in questione.

Sarei propenso a scegliere l'opzione due e gestire le rielaborazioni caso per caso. Certo, ciò potrebbe richiedere più tempo dell'approccio su carta, ma in realtà, si sta aprendo una quantità significativa di rischio aziendale adottando l'approccio uno e non mi piacerebbe davvero essere in giro per le chiamate di supporto il primo giorno se c'è solo un piccolo problema alla fine dell'utente.

Inoltre, se la stragrande maggioranza delle applicazioni basate sui servizi Web sono già scritte in php, come è disponibile l'esperienza .Net?

Penso che in entrambi i casi i tuoi utenti dovranno sperimentare il cambiamento, o big bang (molte richieste di supporto) o frammentario (familiarità crescente). Sono propenso a pensare che non hai davvero dimensionato esattamente quanto lavoro dovrà essere fatto per passare dall'essere completamente completamente php a completamente .Net.

Innanzitutto, sono d'accordo con tutto ciò che dice Joeri.

L'opzione uno è davvero orribile. Se lo fai e non continui il supporto come descritto da Joeri, interrompi il supporto potenzialmente per un paio d'anni per quanto lo vede il tuo cliente. Dopo due anni ottengono effettivamente lo stesso sito con tutti gli stessi problemi che hanno imparato a conoscere e odiare negli ultimi anni. Inoltre il rischio che il mercato sia cambiato nel frattempo e ha reso l'applicazione obsoleta e ha bisogno di un rinnovamento importante. Inoltre, se interrompi il supporto per due anni, cosa pensi che accadrà a tutte le richieste di assistenza? Non andranno via. Almeno alcuni dei tuoi utenti "impazziranno" e svilupperanno sistemi mission-critical in (probabilmente) Accesso per colmare le lacune nei sistemi che stai riscrivendo - poi finirai per supportare due piattaforme ...

L'opzione due significa che supporterai entrambe le tecnologie per un lungo periodo di tempo. Questo periodo di tempo sarà più lungo di quanto si pensi e si potrebbe finire con un ecosistema permanentemente frammentato, ovvero una quantità significativa di codice PHP che non è economico da riscrivere insieme al nuovo codice .NET.

Spingi forte contro chi lo sta suggerendo. Scrivere codice per integrare le applicazioni PHP con i prodotti che suggerirai sarà molto più economico che riscrivere qualsiasi cosa in .NET, quindi integrare il codice riscritto con i prodotti, non dimenticare che l'integrazione non avverrà magicamente se usi .NET .

Ancora una cosa, prendi il numero di righe del codice PHP e inseriscilo in uno strumento COCOMO 2 per avere un'idea di quanto tempo e quanti sviluppatori avrai bisogno per completare la riscrittura.

Hai una terza opzione: -

Migra il codice php sul tuo server Windows e ISS (lo stesso su cui prevedi di eseguire .NET!)

È quindi possibile aggiungere nuove applicazioni in .NET (e convertire lentamente alcune più vecchie in .NET) mentre si presentano agli utenti quello che sembra un singolo sistema.