Como minha transição multinacional de uma plataforma de desenvolvimento para outra?


10

Estou trabalhando no departamento de TI de uma grande empresa internacional. Estamos desenvolvendo diferentes aplicativos de Intranet para o negócio (Reclamações, Descontos, Service Desk etc.). Agora, decidimos migrar da plataforma PHP para o .NET (a integração com o MS CRM Dynamics, Exchange e MS Office é um dos motivos). Como existem cerca de 20 aplicativos diferentes que a empresa está usando na plataforma PHP atual, teremos que apresentar a melhor maneira de movê-los para a nova plataforma. Não quero entrar em detalhes sobre como converter o código, etc, pois enquanto migramos, queremos melhorar todos esses aplicativos.

Então, criamos duas maneiras principais de mover esses aplicativos:

  1. Suporte apenas uma plataforma. O que isso significaria? Crie a página inicial e migre literalmente todos os aplicativos para o .NET (sem aprimorá-los enquanto fazemos isso). Após a execução da Nova intranet, começaríamos a reconstruir os aplicativos migrados e melhorá-los. Isso nos pouparia a desenvolver intranet em .NET e, ao mesmo tempo, precisaria oferecer suporte à plataforma PHP.

  2. Suporte as duas plataformas por algum tempo. Isso significaria criar apenas uma página inicial e 1 ou 2 novos aplicativos (que não existem em nossa plataforma PHP). Tornando-os disponíveis para os usuários, mas não decolando da plataforma PHP (incorporaríamos menus e links para facilitar a movimentação dos usuários entre os aplicativos na página PHP e o novo). Em seguida, começaríamos a reescrever os aplicativos PHP enquanto os aprimoramos.

Agora não tenho certeza do que seria melhor, por um lado (opção 1) potencialmente facilitaremos tudo para os usuários, não forçando-os a usar duas plataformas diferentes ao mesmo tempo. Embora eles não vejam nenhuma melhoria em ter a nova plataforma, além de tudo parecer melhor, a funcionalidade dos aplicativos na nova plataforma será a mesma por algum tempo. Também acho que adicionaríamos a nós mesmos (departamento de TI) mais trabalho, pois basicamente escreveríamos todos os aplicativos duas vezes.
Por outro lado, na opção dois (2) usuários teriam pior experiência, pois duas plataformas parecem diferentes, mas perceberiam os benefícios da nova plataforma à medida que novas aplicações estão sendo movidas.

Algum de vocês se deparou com algo assim? O que você escolheria? Ou talvez haja uma maneira ainda melhor e diferente das que apresentei? Gostaria de saber o que você pensa e como você abordaria isso.


11
O nº 2 não é um passo para o nº 1?
Tae-Sung Shin

Não, estas são duas coisas diferentes. Em 1, migraríamos toda a intranet antes de permitir que os usuários a usassem e, em seguida, trabalharíamos para melhorar os aplicativos. Em 2 gostaríamos de migrar a parte essencial da intranet, permitir que os usuários de usá-lo, e, em seguida, iniciar a migração de outros aplicativos e melhorar a eles enquanto nós migrar ...

@ greengit: leia o tópico, a integração com outros aplicativos críticos de negócios é um dos motivos. Porém, minha pergunta não é sobre 'Por que migrar', mas 'Como migrar'.
Daniel Gruszczyk

Eu li o tópico e tive a mesma pergunta. Duvido muito que o projeto possa ter algum custo justificável. Você pode nos dizer o nome da empresa para que possamos vendê-lo a descoberto? ;)
mcottle 31/08

haha, eu não ligo para os custos para ser honesto, pois sou apenas um estudante de TI em um estágio na empresa. Estou apenas pedindo para ter meu próprio conhecimento ... Apperently meu gerente justificou os custos o suficiente para ter o sinal verde do CEO ...
Daniel Gruszczyk

Respostas:


5

Vamos considerar os dois cenários:

Migração tudo de uma vez

Enquanto você estiver migrando sua base de código, seus clientes continuarão usando seus aplicativos existentes. Como a migração levará um tempo não trivial, isso significa que você precisará de uma equipe de manutenção na antiga base de código, para correção de bugs e desenvolvimento de recursos. Todas as alterações feitas na antiga base de código precisam ocorrer na nova base de código. Você acabará escrevendo cada linha de código duas vezes, desde que a migração não seja concluída, tornando mais caro o tempo que leva para migrar. Então, tudo se resume a: qual será o tempo de resposta para a migração completa? Seus custos de desenvolvimento dispararão enquanto durar o tempo de resposta.

Migração peça por peça

Nesse cenário, você terá melhor controle sobre o esforço duplo, mas ainda terá muitos custos adicionais. Sua implantação envolverá duas plataformas separadas, com o dobro dos problemas de implantação e recursos adicionais do servidor necessários. A menos que você tenha um aplicativo organizado de maneira modular, muitas vezes você encontrará um código presente na outra plataforma que não seja a que você precisa, causando esforço adicional de portabilidade e manutenção. Enquanto a migração não for concluída, seu custo de desenvolvimento será maior. Ao mesmo tempo, a pressão do recurso significará que você levará muito tempo para concluir a migração.

Conclusão

Por experiência pessoal, posso lhe dizer duas coisas:

  • Alternar linguagens de programação raramente compensa. De uma análise de custo-benefício, é muito improvável que seja rentável mudar para .NET do PHP. Então, meu principal conselho é: não. Tente resolver seus problemas com sua base de código existente.
  • Peça por peça é a melhor abordagem, mas é difícil fazê-lo no nível dos módulos de aplicativos. Você descobrirá que precisará desenvolver e manter recursos nos dois lados da arquitetura enquanto a migração não for totalmente concluída. Pode ser uma boa idéia priorizar recursos não com base no que os clientes mais precisam, mas no que limitará a quantidade de esforço duplo (reduzindo o custo).

Você fez pontos muito interessantes. Embora não seja da minha conta mudarmos a plataforma ou não, e eu trabalharei para a empresa até o final de setembro (estou com eles em um posto de trabalho uni). Mudar do PHP para o .NET pode ser uma boa idéia, já que, como o antigo framework PHP necessário, precisamos de alguns trabalhos MAJOR, além de bancos de dados, o sistema que a empresa usa no momento é ANTIGO e criado por pessoas que não tinham grandes habilidades de desenvolvimento. ..
Daniel Gruszczyk

Também minha pergunta seria: 'congelar alterações' na plataforma antiga é uma boa idéia? O que quero dizer com isso é que quaisquer alterações nos sistemas existentes na plataforma PHP, exceto correções de bugs, são congeladas até começarmos a mover o aplicativo fornecido para o .NET. Isso faz parte do meu gerente do plano para a migração ...
Daniel Gruszczyk

Se este é um sistema não trivial, é altamente improvável que um congelamento de mudanças funcione na prática. Se alguém realmente precisar de um recurso, ele o escalará para um nível superior ao seu gerente, e você será forçado a fazer alterações. Além disso, as correções de erros podem consumir uma quantidade considerável de recursos da equipe. E lembre-se sempre de que os sistemas antigos sofreram muitos ajustes e os novos designs provavelmente esquecerão todas essas pequenas correções de uma linha, que precisarão acontecer novamente para que os usuários aceitem o produto reprojetado.
Joeri Sebrechts

Mais um ponto: se o sistema for reconstruído, que proteções existem para garantir uma melhor qualidade de código desta vez? Eu vi um aplicativo que foi reescrito 4 vezes devido a problemas de qualidade de plataforma e código.
Joeri Sebrechts

2

Por razões financeiras, a maioria das empresas em que trabalhei seguiu a segunda abordagem, com razão, devo acrescentar. É preciso muito dinheiro, tempo e riscos para eles alcançarem o primeiro lugar. O usuário entenderia principalmente o número 2 desde que visse seu progresso e interação com eles. Nesta economia enxuta e média, duvido que alguém adotaria a abordagem número 1.


Esse foi exatamente o meu pensamento. Meu gerente quer seguir em frente com o número 1, que acho difícil de entender.

2

As abordagens do big bang raramente são construtivas no que diz respeito aos usuários finais. Aconselho contra isso e, para ser sincero, não acredito que alguém possa considerá-lo seriamente como uma opção, dado o número de solicitações em questão.

Eu estaria inclinado a ir com a opção dois e lidar com re-trabalhos caso a caso. É certo que isso pode levar mais tempo do que abordar um no papel, mas, na realidade, você está abrindo uma quantidade significativa de riscos de negócios adotando a abordagem um e eu realmente não gostaria de estar presente para as chamadas de suporte no primeiro dia, se houver apenas um pequeno problema no final do usuário.

Além disso, se a grande maioria dos aplicativos baseados em serviços da Web já está escrita em php, como está o conhecimento .Net disponível?

Eu acho que de qualquer maneira seus usuários terão que sofrer mudanças, seja big bang (solicite muitas chamadas de suporte) ou fragmentados (aumentando a familiaridade). Estou inclinado a pensar que você realmente não avaliou exatamente quanto trabalho terá que ser feito para passar de quase todo o php para completamente o .Net.


Eu acho que é mais complicado do que apenas suportar duas plataformas separadas ou não. De qualquer maneira não é realmente uma boa abordagem ... Obrigado pelo seu tempo!
Daniel Gruszczyk

1

Em primeiro lugar, concordo com tudo o que Joeri diz.

A primeira opção é realmente horrível. Se você fizer isso e não continuar o suporte, como Joeri descreve, desligará o suporte por um par de anos, tanto quanto o cliente vê. Depois de dois anos, eles obtêm efetivamente o mesmo site com todos os mesmos problemas que aprenderam a odiar nos últimos anos. Além disso, o risco de que o mercado tenha mudado nesse meio tempo e tornado o aplicativo obsoleto e com necessidade de uma grande reformulação. Além disso, se você desligar o suporte por dois anos, o que você acha que acontecerá com todas as solicitações de serviço? Eles não vão embora. Pelo menos alguns de seus usuários "vão à falência" e desenvolvem sistemas de missão crítica (provavelmente) no acesso para preencher as lacunas nos sistemas que você está reescrevendo - então você ainda acaba suportando duas plataformas ...

A opção dois significa que você apoiará as duas tecnologias por um longo período de tempo. Esse período de tempo será mais longo do que você imagina e você pode acabar com um ecossistema permanentemente fragmentado - ou seja, uma quantidade significativa de código PHP que não é econômico para reescrever misturado com o código .NET mais recente.

Empurre com força contra quem está sugerindo isso. Será muito mais barato escrever código para integrar os aplicativos PHP aos produtos que você sugere do que reescrever tudo no .NET e integrar o código reescrito aos produtos, não se esqueça, a integração não acontecerá magicamente se você usar o .NET .

Mais uma coisa, pegue o número de linhas de código PHP e coloque-o em uma ferramenta COCOMO 2 para ter uma idéia de quanto tempo e quantos desenvolvedores serão necessários para concluir a reescrita.


Bom ponto. O que você faria então, se não dependesse de você, se você migrasse o sistema ou não. Qual abordagem você escolheria? Ou talvez haja outra abordagem para eles que eu listei? Se o seu gerente não concordar com você, você tentaria provar que sua abordagem é melhor?
Daniel Gruszczyk

Escreva os aplicativos PHP de uma maneira mais "orientada a serviços". Use um barramento de serviço corporativo para armazenar em buffer a interface entre PHP e Microsoft land. O importante é fazer a estimativa do COCOMO, que deve assustar a vida reescrita do seu gerente.
Mcottle

1

Você tem uma terceira opção: -

Migrar o código php para o servidor Windows e ISS (o mesmo que você planeja executar o .NET!)

Você pode adicionar novos aplicativos ao .NET (e converter lentamente alguns mais antigos ao .NET) enquanto apresenta aos usuários o que parece ser um único sistema.


O PHP realmente é executado no IIS
Bart
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.