W jaki sposób moja międzynarodowa firma może przejść z jednej platformy programistycznej na drugą?

Pracuję w dziale IT dużej międzynarodowej firmy. Tworzymy różne aplikacje intranetowe dla firmy (Reklamacje, Rabaty, Service Desk itp.). Teraz zdecydowaliśmy się na migrację z platformy PHP do .NET (integracja z MS CRM Dynamics, Exchange i MS Office jest jednym z wielu powodów). Ponieważ na obecnej platformie PHP jest około 20 różnych aplikacji, będziemy musieli wymyślić najlepszy sposób na przeniesienie ich wszystkich na nową platformę. Nie chcę wchodzić w szczegóły, jak przekonwertować kod itp., Ponieważ podczas migracji chcemy ulepszyć wszystkie te aplikacje.

Wymyśliliśmy 2 główne sposoby przenoszenia tych aplikacji:

1. Obsługuje tylko jedną platformę. Co by to znaczyło Utwórz stronę główną i dosłownie migruj wszystkie aplikacje w systemie .NET (bez ich ulepszania, gdy to robimy). Po uruchomieniu nowego intranetu zaczniemy odbudowywać migrowane aplikacje i ulepszać je. Oszczędziłoby to nam rozwoju intranetu w .NET przy jednoczesnym wspieraniu platformy PHP.

2. Obsługuj obie platformy przez pewien czas. Oznaczałoby to zbudowanie tylko strony głównej i 1 lub 2 nowych aplikacji (które nie istnieją na naszej platformie PHP). Udostępnianie ich użytkownikom, ale bez zdejmowania platformy PHP (dodalibyśmy menu i linki, aby ułatwić użytkownikom poruszanie się między aplikacjami na stronie PHP i nową). Następnie zaczniemy przepisywać aplikacje PHP, jednocześnie je ulepszając.

Teraz nie jestem pewien, co byłoby lepsze, z jednej strony (opcja 1) potencjalnie ułatwimy wszystkim użytkownikom, nie zmuszając ich do korzystania z dwóch różnych platform jednocześnie. Chociaż nie zobaczą żadnej poprawy w posiadaniu nowej platformy, oprócz wszystkiego ładniej wyglądającego, funkcjonalność aplikacji na nowej platformie będzie przez pewien czas taka sama. Myślę też, że dodalibyśmy (IT dep) więcej pracy, ponieważ zasadniczo pisalibyśmy każdą aplikację dwukrotnie.
Z drugiej strony w opcji dwóch (2) użytkowników miałoby gorsze doświadczenie, ponieważ dwie platformy wyglądają inaczej, ale zdają sobie sprawę z zalet nowej platformy, gdy nowe aplikacje są przenoszone.

Czy ktoś z was spotkał coś takiego? Co byś wybrał? A może jest jeszcze inny, lepszy sposób niż te, które przedstawiłem? Chciałbym wiedzieć, co myślisz i jak byś do tego podszedł.

Rozważmy oba scenariusze:

Migracja od razu

Podczas migracji bazy kodu klienci będą nadal korzystać z istniejących aplikacji. Ponieważ migracja zajmie mało czasu, oznacza to, że będziesz musiał mieć zespół konserwacyjny na starej bazie kodu, w celu naprawy błędów i rozwoju funkcji. Każda zmiana dokonana w starej bazie kodu musi nastąpić w nowej bazie kodu. Skończysz pisać każdy wiersz kodu dwa razy, dopóki migracja nie zostanie zakończona, co będzie tym droższe, im dłużej będzie trwała migracja. Wszystko sprowadza się zatem do: jaki będzie czas realizacji pełnej migracji? Twoje koszty rozwoju będą gwałtownie rosły tak długo, jak długo potrwa czas realizacji.

Migracja kawałek po kawałku

W tym scenariuszu będziesz mieć lepszą kontrolę nad podwójnym wysiłkiem, ale nadal będziesz mieć wiele dodatkowych kosztów. Wdrożenie będzie obejmować dwie oddzielne platformy, z podwójnymi problemami z wdrożeniem i wymaganymi dodatkowymi zasobami serwera. O ile nie masz bardzo modularnie zorganizowanej aplikacji, przekonasz się, że często fragment kodu znajduje się na innej platformie niż ta, na której go potrzebujesz, co powoduje dodatkowe wysiłki związane z przenoszeniem i konserwacją. Dopóki migracja się nie zakończy, koszty rozwoju będą wyższe. Jednocześnie presja funkcji spowoduje, że migracja zajmie Ci dużo czasu.

Wniosek

Z własnego doświadczenia mogę powiedzieć dwie rzeczy:

• Zmiana języków programowania rzadko się opłaca. Z analizy kosztów i korzyści wynika, że ​​bardzo mało prawdopodobne jest przejście na platformę .NET z PHP. Więc moja główna rada to: nie. Spróbuj rozwiązać problemy z istniejącą bazą kodów.
• Najlepsze jest podejście kawałek po kawałku, ale będziesz miał trudności z robieniem tego na poziomie modułów aplikacji. Przekonasz się, że będziesz musiał opracować i utrzymywać funkcje po obu stronach architektury, dopóki migracja nie zostanie w pełni wykonana. Dobrym pomysłem może być ustalenie priorytetów funkcji nie w oparciu o to, czego klienci najbardziej potrzebują, ale o to, co ograniczy ilość podwójnego wysiłku (tym samym obniżając koszty).

Ze względów finansowych większość firm, w których pracowałem, stosowała drugie podejście, słusznie mogę dodać. Osiągnięcie # 1 zajmuje dużo pieniędzy, czasu i ryzyka. Użytkownik w większości rozumie numer 2, pod warunkiem, że zobaczy Twoje postępy i interakcję z nimi. W tej oszczędnej i wrednej gospodarce wątpię, aby ktokolwiek zająłby pierwsze miejsce.

Podejścia związane z Wielkim Wybuchem rzadko są konstruktywne, jeśli chodzi o użytkowników końcowych. Odradzam to i szczerze mówiąc, nie mogę uwierzyć, że ktokolwiek poważnie uznałby to za opcję, biorąc pod uwagę liczbę rozpatrywanych wniosków.

Byłbym skłonny pójść z opcją drugą i zająć się ponownymi pracami w poszczególnych przypadkach. Wprawdzie może to potrwać dłużej niż podejście na papierze, ale w rzeczywistości narażasz się na znaczną część ryzyka biznesowego, wybierając podejście pierwsze i naprawdę nie chciałbym być w pobliżu w sprawie zgłoszeń do pomocy technicznej pierwszego dnia, jeśli nawet tylko jeden mały problem po stronie użytkownika.

Ponadto, jeśli przytłaczająca większość aplikacji opartych na usługach internetowych jest już napisana w php, w jaki sposób dostępna jest wiedza specjalistyczna .Net?

Myślę, że tak czy inaczej, użytkownicy będą musieli doświadczyć zmian, albo Big Bang (cue wiele zgłoszeń do pomocy technicznej), albo fragmentarycznie (zwiększenie znajomości). Jestem skłonny sądzić, że tak naprawdę nie oszacowałeś dokładnie, ile pracy trzeba będzie zrobić, aby przejść od bycia prawie całkowicie php do całkowicie .Net albo.

Po pierwsze, zgadzam się ze wszystkim, co mówi Joeri.

Pierwsza opcja jest naprawdę okropna. Jeśli to zrobisz i nie będziesz kontynuować wsparcia, jak opisuje Joeri, zamkniesz wsparcie na kilka lat, o ile klient to zobaczy. Po dwóch latach uzyskują efektywnie tę samą witrynę ze wszystkimi tymi samymi problemami, które znają i których nienawidzą przez ostatnie kilka lat. Plus ryzyko, że rynek zmienił się w międzyczasie i sprawił, że aplikacja stała się przestarzała i wymagała poważnej przebudowy. Ponadto, jeśli zamkniesz wsparcie na dwa lata, co według Ciebie stanie się z wszystkimi zleceniami serwisowymi? Nie odejdą. Przynajmniej niektórzy z twoich użytkowników „popadną w nieuczciwość” i opracują systemy o znaczeniu krytycznym w (prawdopodobnie) dostępie, aby uzupełnić luki w systemach, które przepisujesz - wtedy nadal będziesz obsługiwać dwie platformy ...

Opcja druga oznacza, że ​​będziesz obsługiwać obie technologie przez dłuższy czas. Ten okres czasu będzie dłuższy, niż myślisz, i możesz skończyć z trwale rozdrobnionym ekosystemem - tj. Znaczną ilością kodu PHP, który nie jest ekonomiczny do przepisania zmieszanego z nowszym kodem .NET.

Odepchnij się mocno od tego, kto to sugeruje. Znacznie taniej będzie napisać kod do zintegrowania aplikacji PHP z produktami, które sugerujesz, niż przepisać wszystko w .NET, a następnie zintegrować przepisany kod z produktami, nie zapomnij, integracja nie nastąpi magicznie, jeśli używasz .NET .

Jeszcze jedno, weź liczbę wierszy kodu PHP i umieść go w narzędziu COCOMO 2, aby dowiedzieć się, ile czasu i ilu programistów będziesz potrzebować, aby dokończyć przepisywanie.

Masz trzecią opcję: -

Przeprowadź migrację kodu php na serwer Windows i ISS (taki sam, jak planujesz uruchomić .NET na!)

Następnie możesz dodawać nowe aplikacje w .NET (i powoli konwertować niektóre starsze na .NET), jednocześnie prezentując użytkownikom coś, co wygląda jak pojedynczy system.