Comment ma multinationale peut-elle passer d'une plateforme de développement à une autre?

10

Je travaille dans le département informatique d'une grande entreprise internationale. Nous développons différentes applications Intranet pour l'entreprise (réclamations, remises, Service Desk, etc.). Nous avons maintenant décidé de migrer de la plate-forme PHP vers .NET (l'intégration avec MS CRM Dynamics, Exchange et MS Office est parmi de nombreuses raisons). Comme l'entreprise utilise environ 20 applications différentes sur la plate-forme PHP actuelle, nous devrons trouver le meilleur moyen de les déplacer toutes vers la nouvelle plate-forme. Je ne veux pas entrer dans les détails sur la façon de convertir le code, etc., car pendant que nous migrons, nous voulons améliorer toutes ces applications.

Nous avons donc trouvé 2 façons principales de déplacer ces applications:

  1. Prend en charge une seule plateforme. Qu'est-ce que cela signifierait? Créez la page d'accueil et migrez littéralement toutes les applications telles qu'elles sont vers .NET (sans les améliorer pendant que nous le faisons). Après l'exécution de New intranet, nous commencerions à reconstruire les applications migrées et à les améliorer. Cela nous éviterait de développer un intranet en .NET tout en prenant en charge la plate-forme PHP.

  2. Prend en charge les deux plates-formes pendant un certain temps. Cela signifierait construire juste une page d'accueil et 1 ou 2 nouvelles applications (qui n'existent pas sur notre plateforme PHP). Les mettre à la disposition des utilisateurs mais ne pas retirer la plate-forme PHP (nous incorporerions des menus et des liens pour faciliter le passage des applications entre la page PHP et la nouvelle). Ensuite, nous commencerions à réécrire les applications PHP tout en les améliorant.

Maintenant, je ne sais pas ce qui serait mieux, d'une part (option 1), nous allons potentiellement tout faciliter pour les utilisateurs en ne les obligeant pas à utiliser deux plates-formes différentes en même temps. Bien qu'ils ne verront aucune amélioration de la nouvelle plate-forme, à part tout ce qui est plus joli, la fonctionnalité des applications sur la nouvelle plate-forme sera la même pendant un certain temps. De plus, je pense que nous nous ajouterions (IT Dep) plus de travail car nous écririons essentiellement chaque application deux fois.
D'un autre côté, dans l'option deux (2), les utilisateurs auraient une expérience pire que deux plates-formes différentes, mais ils se rendraient compte des avantages de la nouvelle plate-forme à mesure que de nouvelles applications sont déplacées.

L'un d'entre vous a-t-il rencontré quelque chose comme ça? Que choisiriez-vous? Ou peut-être existe-t-il une manière encore meilleure et différente de celles que j'ai présentées? J'aimerais savoir ce que vous pensez et comment aborderiez-vous cela.

Daniel Gruszczyk
la source
1
N ° 2 n'est-il pas une étape vers n ° 1?
Tae-Sung Shin
Non, ce sont 2 choses différentes. Dans 1, nous migrions l'intégralité de l'intranet avant de permettre aux utilisateurs de l'utiliser, puis nous travaillions sur l'amélioration des applications. Dans 2, nous migrerions la partie essentielle de l'intranet, permettrions aux utilisateurs de l'utiliser, puis commencerions à migrer d'autres applications et à les améliorer pendant que nous migrons ...
@greengit: lisez le sujet, l'intégration avec d'autres applications critiques pour l'entreprise est l'une des raisons. Cependant, ma question ne traite pas de «Pourquoi migrer», mais «Comment migrer».
Daniel Gruszczyk
J'ai lu le sujet et posé la même question. Je doute beaucoup que le projet puisse jamais être justifié par les coûts. Pouvez-vous nous donner le nom de l'entreprise afin que nous puissions la vendre à découvert? ;)
mcottle
haha, je ne me soucie pas des coûts pour être honnête car je suis juste un étudiant en informatique sur un stage avec l'entreprise. Je demande juste mes propres connaissances ... Apparemment mon manager a justifié les coûts suffisamment pour avoir le feu vert du PDG ...
Daniel Gruszczyk

Réponses:

5

Prenons les deux scénarios:

Migration tout à la fois

Pendant que vous migrez votre base de code, vos clients continueront à utiliser vos applications existantes. Étant donné que la migration prendra un temps non négligeable, cela signifie que vous devrez disposer d'une équipe de maintenance sur l'ancienne base de code, pour la correction des bogues et le développement des fonctionnalités. Chaque modification que vous apportez dans l'ancienne base de code doit se produire dans la nouvelle base de code. Vous finirez par écrire chaque ligne de code deux fois aussi longtemps que la migration ne sera pas effectuée, ce qui la rendra plus chère plus la migration prendra de temps. Donc, tout se résume à: quel sera le délai d'exécution pour la migration complète? Vos coûts de développement monteront en flèche aussi longtemps que durera le délai d'exécution.

Migration pièce par pièce

Dans ce scénario, vous aurez un meilleur contrôle sur le double effort, mais vous aurez toujours beaucoup de coûts supplémentaires. Votre déploiement impliquera deux plates-formes distinctes, avec deux fois plus de problèmes de déploiement et des ressources serveur supplémentaires requises. À moins que vous ne disposiez d'une application très modulaire, vous constaterez que souvent un morceau de code est présent dans l'autre plate-forme que celle sur laquelle vous en avez besoin, ce qui entraîne des efforts de portage et de maintenance supplémentaires. Tant que la migration ne sera pas effectuée, vos coûts de développement seront plus élevés. En même temps, la pression des fonctionnalités signifie que cela va vous prendre beaucoup de temps pour terminer la migration.

Conclusion

Par expérience personnelle, je peux vous dire deux choses:

  • Changer de langage de programmation est rarement payant. D'après une analyse coûts-avantages, il est très peu probable qu'il soit rentable de passer de PHP à .NET. Donc, mon principal conseil est: ne le faites pas. Essayez de résoudre vos problèmes avec votre base de code existante.
  • Morceau par morceau est la meilleure approche, mais vous aurez du mal à le faire au niveau des modules d'application. Vous constaterez que vous devrez développer et maintenir des fonctionnalités des deux côtés de l'architecture tant que la migration n'est pas entièrement effectuée. Il peut être judicieux de hiérarchiser les fonctionnalités non pas en fonction de ce dont les clients ont le plus besoin, mais en fonction de ce qui limitera la quantité d'effort double (réduisant ainsi les coûts).
Joeri Sebrechts
la source
Vous avez fait des remarques très intéressantes. Bien que ce ne soit pas à moi de changer de plate-forme ou non, et je ne travaillerai pour l'entreprise que jusqu'à fin septembre (je suis avec eux en stage uni). Passer de PHP à .NET pourrait être une bonne idée, cependant, puisque l'ancien framework PHP que nous avons aurait besoin de travaux MAJEURS, de bases de données également, le système que la société utilise actuellement est VIEUX et créé par des personnes qui n'avaient pas de grandes compétences en développement. ..
Daniel Gruszczyk
Ma question serait également la suivante: le gel des modifications sur l'ancienne plate-forme est-il une bonne idée? Ce que je veux dire par là, c'est que toutes les modifications apportées aux systèmes existants sur la plate-forme PHP, autres que les corrections de bogues, sont gelées jusqu'à ce que nous commencions à déplacer une application donnée vers .NET. C'est la partie de mon manager dans le plan de migration ...
Daniel Gruszczyk
S'il s'agit d'un système non trivial, il est très peu probable qu'un gel des modifications fonctionne en pratique. Si quelqu'un a vraiment besoin d'une fonctionnalité, il l'escaladera à un niveau supérieur à celui de votre responsable et vous serez obligé de faire des changements. De plus, les corrections de bogues peuvent prendre à elles seules une quantité considérable de ressources d'équipe. Et gardez toujours à l'esprit que les anciens systèmes ont subi de nombreux ajustements et que les nouvelles conceptions risquent d'oublier toutes ces petites corrections sur une seule ligne, qui devront se reproduire pour que les utilisateurs acceptent le produit repensé.
Joeri Sebrechts
Encore un point: si le système va être reconstruit, quels sont les garde-fous en place pour assurer une meilleure qualité de code cette fois-ci? J'ai vu une application qui a été réécrite 4 fois en raison de problèmes de plate-forme et de qualité du code.
Joeri Sebrechts
2

Pour des raisons financières, la plupart des entreprises dans lesquelles j'ai travaillé ont opté pour la deuxième approche, pourrais-je ajouter à juste titre. Il leur faut beaucoup d'argent, de temps et de risques pour atteindre la première place. La plupart des utilisateurs comprendraient # 2 tant qu'ils voient vos progrès et votre interaction avec eux. Dans cette économie maigre et moyenne, je doute que quiconque adopte l'approche n ° 1.

Tae-Sung Shin
la source
C'était exactement ma pensée. Mon manager veut aller de l'avant avec le n ° 1, que je trouve difficile à comprendre.
2

Les approches Big Bang sont rarement constructives en ce qui concerne les utilisateurs finaux. Je le déconseille et pour être honnête, je ne peux pas croire que quiconque l'envisagerait sérieusement comme une option compte tenu du nombre de demandes concernées.

Je serais enclin à opter pour l'option deux et à gérer les retouches au cas par cas. Certes, cela peut prendre plus de temps que l'approche sur papier, mais en réalité, vous ouvrez une quantité importante de risques commerciaux en adoptant l'approche 1 et je ne voudrais vraiment pas être là pour les appels de support le premier jour s'il y a même juste un petit problème au niveau de l'utilisateur.

De plus, si la grande majorité de vos applications basées sur les services Web sont déjà écrites en php, comment est l'expertise .Net disponible?

Je pense que dans un cas comme dans l'autre, vos utilisateurs vont devoir faire face à des changements, que ce soit le big bang (cue beaucoup d'appels d'assistance) ou au coup par coup (familiarisation croissante). Je suis enclin à penser que vous n'avez pas vraiment évalué exactement combien de travail devra être fait pour passer d'une quasi-totalité de php à complètement .Net non plus.

temptar
la source
Je suppose que c'est plus compliqué que de simplement supporter deux plates-formes séparées ou non. De toute façon, ce n'est pas vraiment une bonne approche ... Merci pour votre temps!
Daniel Gruszczyk
1

Premièrement, je suis d'accord avec tout ce que dit Joeri.

La première option est vraiment horrible. Si vous faites cela et ne poursuivez pas l'assistance comme décrit par Joeri, vous interrompez l'assistance pendant potentiellement quelques années pour autant que votre client le voit. Après deux ans, ils obtiennent effectivement le même site avec tous les mêmes problèmes qu'ils connaissent et détestent depuis quelques années. Plus le risque que le marché ait changé entre-temps et rende l'application obsolète et nécessite une refonte majeure. De plus, si vous fermez le support pendant deux ans, que va-t-il arriver à toutes les demandes de service? Ils ne partiront pas. Au moins certains de vos utilisateurs "deviendront des voyous" et développeront des systèmes critiques dans Access (probablement) pour combler les lacunes dans les systèmes que vous réécrivez - alors vous finirez toujours par prendre en charge deux plates-formes ...

L'option deux signifie que vous soutiendrez les deux technologies pendant une période prolongée. Cette période sera plus longue que vous ne le pensez et vous pourriez vous retrouver avec un écosystème fragmenté en permanence - c'est-à-dire une quantité importante de code PHP qui n'est pas économique à réécrire mélangé avec du code .NET plus récent.

Repousser fort contre celui qui suggère cela. Il sera beaucoup moins cher d'écrire du code pour intégrer les applications PHP avec les produits que vous proposez que de tout réécrire dans .NET puis d'intégrer le code réécrit avec les produits, n'oubliez pas, l'intégration ne se fera pas comme par magie si vous utilisez .NET .

Encore une chose, prenez le nombre de lignes de code PHP et mettez-le dans un outil COCOMO 2 pour avoir une idée du temps et du nombre de développeurs dont vous aurez besoin pour terminer la réécriture.

mcottle
la source
Bon point. Que feriez-vous alors, si ce n'était pas à vous de migrer le système ou non. Quelle approche choisiriez-vous? Ou monbe y a-t-il une autre approche que j'ai énumérée? Si votre manager n'est pas d'accord avec vous, tenteriez-vous de prouver que votre approche est meilleure?
Daniel Gruszczyk
Écrivez les applications PHP d'une manière plus "orientée service". Utilisez un bus de services d'entreprise pour tamponner l'interface entre PHP et Microsoft Land. L'essentiel est de faire l'estimation COCOMO, qui devrait effrayer les réécritures vivantes de votre manager.
mcottle
1

Vous avez une troisième option: -

Migrez le code php vers votre serveur Windows et ISS (le même que celui sur lequel vous prévoyez d'exécuter .NET!)

Vous pouvez ensuite ajouter de nouvelles applications dans .NET (et convertir lentement certaines anciennes en .NET) tout en présentant à vos utilisateurs ce qui ressemble à un seul système.

James Anderson
la source
PHP fonctionne en effet sous IIS
Bart