Não Migramos mais Sistemas e sim Reconstruimos em outra Tecnologia

Não entendi esse parágrafo. Poderia explicar melhor?

victorwss:

Marcio Duran:

Então desenvolvimento começa pela total negação que é adversa a tudo que é hoje especificado, a migração precisa ser total de algoritmo até a modelagem, então pergunto como fazer tal avaliação de sistema não seria mesmo o caso de fazer outro do zero, ou estamos fazendo reuso maquiando algo que estamos na verdade reconstruindo.

Não entendi esse parágrafo. Poderia explicar melhor?

Todo o legado de uma aplicação é ligado ao que já tem injetado algoritmos e modelagem que está entrelaçado com sua arquitetura e limitação tecnologica, que na certa qualquer se seja a migração vai ser de uma incompatibilidade descomunal, não seria o caso de refazer o sistema do zero, com as novas tecnologias que temos hoje não seria mais rápido e limpo de problemas.

Pra que complicar ?
Acho que você faz o mesmo sistema em menos tempo refazendo-o do zero, do que tentar uma migração de uma geração tecnologia que não atende a mesma especificação atual, pior ainda os modelos de padrões de projeto já estão a anos luz sobre a otica de desenvolvimento com outras adoções, por exemplos discutimos aqui, TDD, DSL, DDD, entre outros estilos de desenvolvimento avançado entretanto isso não é compativel pois visam uma forma de desenvolvimento que não é o que temos hoje, e pior ainda não é visivel por muitas corporações,é mais sim algo futuro a se adotar.

Pra mim podem lançar todo e qlqr tipo de api. No meu caso, não tem muita importância, já que trabalho desenvolvendo aplicações para hardware. Se tiver necessidade de api, eu mesmo me viro aqui fazendo uma.

Se você trabalha com computação embarcada isso é outro mercado, não é disso que estou falando mas sim de projetos que envolvem aplicações cujo o processo é algo que envolva um numero maior de responsabilidade com pessoas e seus departamentos em um sistema de aplicação distribuida seja ambito financeiro, comercial.

“SISTEMA LEGADO !!!”, MIX DE CONFUSÃO CVS, DESCONTROLADOS !!! A MIGRAÇÃO QUE NÃO DEU CERTO ???

“PÓS-LEGADO”, NOVAS ADOÇÕES AMBIENTE ÁGIL REQUISITOS ALINHADOS

…

Então se eu possuir um sistema desenvolvido em Java 1.3 devo criar outro sistema e não migra-lo para a versao atual?

Concordo que muitas vezes nao vale a pena a migracao, porem nao me atrevo a generalizar desta forma.

Nem tudo é tudo.

aleck:

Então se eu possuir um sistema desenvolvido em Java 1.3 devo criar outro sistema e não migra-lo para a versao atual?

Concordo que muitas vezes nao vale a pena a migracao, porem nao me atrevo a generalizar desta forma.

Nem tudo é tudo.

é…concordo…

pra tudo tem um meio termo, não da pra fica re-escrevendo aplicação toda hora que surgir uma nova linguagem da moda, por outro lado certas coisas devem ser re-escritas do zero resolvendo varios problemas por que isso pode ser mais vantajoso, facil, do que fica dando manutenção na antiga…

isso é uma das coisas que mais me desencoraja a aprender linguagens criadas por certa empresa cujo não quero citar o nome, surje uma nova linguagem, algo de diferente, então o que se tinha antes é simplesmente abandonado… e com isso as pessoas que utilizavam essa linguagem e perderam suporte…

talvez essa seja uma visão meio leiga, tem mto mais detalhes ai no meio, mais de um modo geral, é assim que a coisa parece acaabr funcionando na pratica… tendo que re-escrever tudo do zero por causa de incompatibilidade.

Construir do zero envolve mais riscos que “evoluir” um sistema, mesmo que a base desse sistema esteja podre.

Fora que evoluir é mais rápido que reconstruir. Gerentes sempre querem tudo pronto para ontem.

infelizmente nem sempre… tem mta pog por ai que da mó trabalho simplesmente fazer funcionar porcamente, e logo vai da mais problema… ai se perde mto tempo com isso…

Não se refaz um sistema do zero, nunca!. Por mais cômodo que a reconstrução possa parecer, ela traz riscos enormes como: reavivar bugs já sanados no sistema antigo; ficar muito tempo com poucas features; e pior, acabar com um novo sistema tão ruim que precisa de uma “nova reconstrução”.

Mesmo sendo chato, crie maneiras do legado se comunicar com novos sistemas. Só que existem jeitos corretos de se fazer isso, que usam web services e ESB, e existem jeitos que levam a falhas, que normalmente são integrações ad-hoc e pouquíssimo planejada. O que não dá é achar que integração sempre é ruim, e que ficar reinventando software a toda hora é bom.

[quote=maior_abandonado]

aleck:

…
isso é uma das coisas que mais me desencoraja a aprender linguagens criadas por certa empresa cujo não quero citar o nome, surje uma nova linguagem, algo de diferente, então o que se tinha antes é simplesmente abandonado… e com isso as pessoas que utilizavam essa linguagem e perderam suporte…

Concordo com você.
Não faz muito sentido reescrever rotinas da contabilidade que nunca mudam, simplesmente por falta de compatibilidade entre versões da linguagem.
Lí um texto uma vez, e concordei, que dizia que o setor de TI, não é mais algo que dá vantagem. O autor dizia que o TI(não estou generalizando) apenas fornece dados desprovidos de informação. Então, o tempo que passaríamos reescrevendo algo, poderíamos ter evoluído o que já funciona.

maior_abandonado:

…
isso é uma das coisas que mais me desencoraja a aprender linguagens criadas por certa empresa cujo não quero citar o nome, surje uma nova linguagem, algo de diferente, então o que se tinha antes é simplesmente abandonado… e com isso as pessoas que utilizavam essa linguagem e perderam suporte…

Concordo com você.
Não faz muito sentido reescrever rotinas da contabilidade que nunca mudam, simplesmente por falta de compatibilidade entre versões da linguagem.
Lí um texto uma vez, e concordei, que dizia que o setor de TI, não é mais algo que dá vantagem. O autor dizia que o TI(não estou generalizando) apenas fornece dados desprovidos de informação. Então, o tempo que passaríamos reescrevendo algo, poderíamos ter evoluído o que já funciona

Leonardo3001:

Não se refaz um sistema do zero, nunca!. Por mais cômodo que a reconstrução possa parecer, ela traz riscos enormes como: reavivar bugs já sanados no sistema antigo; ficar muito tempo com poucas features; e pior, acabar com um novo sistema tão ruim que precisa de uma “nova reconstrução”.

Mesmo sendo chato, crie maneiras do legado se comunicar com novos sistemas. Só que existem jeitos corretos de se fazer isso, que usam web services e ESB, e existem jeitos que levam a falhas, que normalmente são integrações ad-hoc e pouquíssimo planejada. O que não dá é achar que integração sempre é ruim, e que ficar reinventando software a toda hora é bom.

Novamente generalização.

Como disse anteriormente, existem casos e casos. Muitas vezes a evolução cria riscos maiores que a criação de novos sistemas. A tecnologia que os sistemas antigos foram construidos muitas vezes não atendem a necessidade do cliente, cabe ao desenvolvedor saber quando optar pela construção de novos sistemas, ou pelo menos opinar junto aos seus gestores.

aleck:

Leonardo3001:

Não se refaz um sistema do zero, nunca!. Por mais cômodo que a reconstrução possa parecer, ela traz riscos enormes como: reavivar bugs já sanados no sistema antigo; ficar muito tempo com poucas features; e pior, acabar com um novo sistema tão ruim que precisa de uma “nova reconstrução”.

Mesmo sendo chato, crie maneiras do legado se comunicar com novos sistemas. Só que existem jeitos corretos de se fazer isso, que usam web services e ESB, e existem jeitos que levam a falhas, que normalmente são integrações ad-hoc e pouquíssimo planejada. O que não dá é achar que integração sempre é ruim, e que ficar reinventando software a toda hora é bom.

Novamente generalização.

Como disse anteriormente, existem casos e casos. Muitas vezes a evolução cria riscos maiores que a criação de novos sistemas. A tecnologia que os sistemas antigos foram construidos muitas vezes não atendem a necessidade do cliente, cabe ao desenvolvedor saber quando optar pela construção de novos sistemas, ou pelo menos opinar junto aos seus gestores.

Vamos ter foco. Se o sistema antigo não atende a necessidade do cliente, é um sistema diferente e não apenas uma migração. Agora, quando se faz reescrita de sistemas novos apenas pelo desejo de migrar para uma nova tecnologia, os malefícios superam os benefícios, na maioria dos casos.

Evolução cria riscos, reescrita também. Vai por mim, já participei de dois projetos de reescrita e o resultado final não foi satisfatório em ambos, simplesmente porque o novo sistema não era tão confiável quanto o sistema antigo.

Foi uma generalização que eu disse? Foi! O melhor termo é dizer: considere a reescrita como última opção, e pense primeiro em maneiras de continuar a usar o legado (talvez isolando-o em um façade para novos sistemas, sei lá).

[quote=Leonardo3001]

aleck:

Vamos ter foco. Se o sistema antigo não atende a necessidade do cliente, é um sistema diferente e não apenas uma migração. Agora, quando se faz reescrita de sistemas novos apenas pelo desejo de migrar para uma nova tecnologia, os malefícios superam os benefícios, na maioria dos casos.

Evolução cria riscos, reescrita também. Vai por mim, já participei de dois projetos de reescrita e o resultado final não foi satisfatório em ambos, simplesmente porque o novo sistema não era tão confiável quanto o sistema antigo.

Foi uma generalização que eu disse? Foi! O melhor termo é dizer: considere a reescrita como última opção, e pense primeiro em maneiras de continuar a usar o legado (talvez isolando-o em um façade para novos sistemas, sei lá).

Se for por experiência pessoal eu posso te garantir que já passei por “muitas” reescritas e nunca tive problemas, no pior dos casos o sistema não tinha nada de mais em relação ao antigo, porém não ficava mais na mão de um unico programador que sabia uma linguagem especifica.

Quantas pessoas você conhece que ainda procuram emprego relacionado a clipper? Visual Basic? Delphi?

O mercado muda, e se as empresas não acompanharem ficam escravas dos poucos que ainda se sujeitam a trabalhar com tecnologias ultrapassadas.

[quote=aleck]

Leonardo3001:

aleck:

Vamos ter foco. Se o sistema antigo não atende a necessidade do cliente, é um sistema diferente e não apenas uma migração. Agora, quando se faz reescrita de sistemas novos apenas pelo desejo de migrar para uma nova tecnologia, os malefícios superam os benefícios, na maioria dos casos.

Evolução cria riscos, reescrita também. Vai por mim, já participei de dois projetos de reescrita e o resultado final não foi satisfatório em ambos, simplesmente porque o novo sistema não era tão confiável quanto o sistema antigo.

Foi uma generalização que eu disse? Foi! O melhor termo é dizer: considere a reescrita como última opção, e pense primeiro em maneiras de continuar a usar o legado (talvez isolando-o em um façade para novos sistemas, sei lá).

Se for por experiência pessoal eu posso te garantir que já passei por “muitas” reescritas e nunca tive problemas, no pior dos casos o sistema não tinha nada de mais em relação ao antigo, porém não ficava mais na mão de um unico programador que sabia uma linguagem especifica.

Quantas pessoas você conhece que ainda procuram emprego relacionado a clipper? Visual Basic? Delphi?

O mercado muda, e se as empresas não acompanharem ficam escravas dos poucos que ainda se sujeitam a trabalhar com tecnologias ultrapassadas.

clipper ta praticamento morto… porem vb, delphi e principalmente cobol reinam e ainda reinarão por muito tempo… pelo menos em quanto o legado existir…

Bruno Laturner:

Construir do zero envolve mais riscos que “evoluir” um sistema, mesmo que a base desse sistema esteja podre.

Fora que evoluir é mais rápido que reconstruir. Gerentes sempre querem tudo pronto para ontem.

O sistema legado já traz uma enorme vantagem de coleta de requisitos para o novo sistema. é como ele fosse uma documentação ou podemos dizer que ele passou a ser o prototipo que vai ser redesenhado para atender as novas adoções.

Você não evolui um sistema, você reconstroe isso sim, não tem como você evoluir o sistema é a mesma coisa que você me disser que o motor do Fusca foi a base para o motor de uma Ferrari, a forma e a metodologia aplicada ao recurso é totalmente diferente, porque a dimânica é outra.

É o que esta acontecendo a nossa dinâmica é outra, justamente pela necessidade de projetar soluções em menos tempo e com mais serviço possivel, e isso requer MODULARIDADE, você deve atendar a um novo consorcio “vamos colocar assim”, de entidades que vão trabalhar de forma totalmente nova para interfacear o que hoje é a WEB 2.O.

A frase “Não Migramos mais Sistemas e sim Reconstruimos em outra Tecnologia” é uma tautologia.
Quando vc migra o sistema , vc está implicitamente dizendo que está mudando de tecnologia.

Acho que o que vc queria dizer - e é o que está sendo discutido - é “Não Evoluimos mais Sistemas e sim Reconstruimos em outra Tecnologia”

Isso é meia verdade.

Hoje em dia é verdade que não evoluimos sistemas. A principal razão para isso é que eles não foram pensados para evoluir.
Pegue um projeto feito de forma agil. Vc tem o sistema pronto em 3 meses, mas a forma agil é baseada em cooperação de pessoas e comunicação entre pessoas sem usar nenhum artefato. Isso significa que quando as pessoas vão embora, ou esquecem do sistema, ele morre. Claro que vc pode escrever um documento de 1000 páginas descrevendo o sistema, o resultado será o mesmo.

O conhecimento de um software é conhecer o que eles faz pelo cliente, mas tb como ele faz isso. Caso contrário vc irá reinventar componentes do sistema simplesmente vc desconhece que eles existem. normalmente isso é mais verdade quando mais opções o sistema tem. Algumas não usadas já fazem o que se pretende, mas como ninguem as conhece, ninguem sabe que elas existem.

Então , todos os sistemas acabam sendo legado. E legado aqui não significa um sistema dos anos 80. significa um sistema que ninguem mais sabe reprogramar. Então o que temos é criação de outros sistemas que se alimentam desse. Normalmente via o banco de dados. Isso é muito,muito,muito ruim. Sem um ponto de controle dentro de um AS é um pesadelo fazer a integração.

Se vc conseguir modificar o legado ele não é tão legado assim. significa que pelo menos ha 1 pessoa que sabe alterá-lo. normalmente para lhe fornecer uma capacidade de webservice e dessa forma integrá-lo em um nivel “mais a cima” que o banco de dados.

Por outro lado existe evolução tecnologia. Hoje em dia usar algo que não seja Java ou .NET é caro. Primeiro porque as tecnologias elas proprias não estão evoluindo, segundo porque ha cada vez menos interessados nelas e/ou que as saibam usar. Não é por acaso que ABAP está micrando para uma JVM assim como todas as tecnologias usadas pelos grandes (IBM, Oracle, etc…)

Então é normal que alguem reinvente o sistema com uma nova tecnologia.
O erro é fazer isso sem evoluir o sistema. Ou seja deixar o sistema novo ter o mesmo processo obsuleto que o antigo. E isso sim é um desperdicio de recursos.

Infelizmente ninguem faz sistemas para durarem. Isso sem OO era complicado. Mas agora com OO, o problema é que poucos sabem usar OO direito para chegar nesse nivel. Outro problema é que sendo o sistema completamente aberto para extensão a documentação disso é extremamente complexa.
As metodologias ageis tb não ajudam ja´que elas se focam no presente ( no que o cliente quer ) e não no futuro ( no que o cliente precisa)

sergiotaborda:

A frase “Não Migramos mais Sistemas e sim Reconstruímos em outra Tecnologia” é uma tautologia.
Quando vc migra o sistema , vc está implicitamente dizendo que está mudando de tecnologia.

sergiotaborda:

Acho que o que vc queria dizer - e é o que está sendo discutido - é “Não Evoluímos mais Sistemas e sim Reconstruímos em outra Tecnologia”
Isso é meia verdade.

sergiotaborda:

Hoje em dia é verdade que não evoluímos sistemas. A principal razão para isso é que eles não foram pensados para evoluir.
Pegue um projeto feito de forma agil. Vc tem o sistema pronto em 3 meses, mas a forma ágil é baseada em cooperação de pessoas e comunicação entre pessoas sem usar nenhum artefato. Isso significa que quando as pessoas vão embora, ou esquecem do sistema, ele morre. Claro que vc pode escrever um documento de 1000 páginas descrevendo o sistema, o resultado será o mesmo.

sergiotaborda:

O conhecimento de um software é conhecer o que eles faz pelo cliente, mas tb como ele faz isso. Caso contrário vc irá reinventar componentes do sistema simplesmente vc desconhece que eles existem. normalmente isso é mais verdade quando mais opções o sistema tem. Algumas não usadas já fazem o que se pretende, mas como ninguém as conhece, ninguém sabe que elas existem.

sergiotaborda:

Então , todos os sistemas acabam sendo legado. E legado aqui não significa um sistema dos anos 80. significa um sistema que ninguém mais sabe reprogramar. Então o que temos é criação de outros sistemas que se alimentam desse. Normalmente via o banco de dados. Isso é muito,muito,muito ruim. Sem um ponto de controle dentro de um AS é um pesadelo fazer a integração.

sergiotaborda:

Se vc conseguir modificar o legado ele não é tão legado assim. significa que pelo menos ha 1 pessoa que sabe alterá-lo. normalmente para lhe fornecer uma capacidade de webservice e dessa forma integrá-lo em um nível “mais a cima” que o banco de dados.

sergiotaborda:

Por outro lado existe evolução tecnologia. Hoje em dia usar algo que não seja Java ou .NET é caro. Primeiro porque as tecnologias elas próprias não estão evoluindo, segundo porque ha cada vez menos interessados nelas e/ou que as saibam usar. Não é por acaso que ABAP está migrando para uma JVM assim como todas as tecnologias usadas pelos grandes (IBM, Oracle, etc…)

sergiotaborda:

Então é normal que alguém reinvente o sistema com uma nova tecnologia.
O erro é fazer isso sem evoluir o sistema. Ou seja deixar o sistema novo ter o mesmo processo obsoletos que o antigo. E isso sim é um desperdício de recursos.

sergiotaborda:

Infelizmente ninguém faz sistemas para durarem. Isso sem OO era complicado. Mas agora com OO, o problema é que poucos sabem usar OO direito para chegar nesse nível. Outro problema é que sendo o sistema completamente aberto para extensão a documentação disso é extremamente complexa.
As metodologias ágeis tb não ajudam ja´que elas se focam no presente ( no que o cliente quer ) e não no futuro ( no que o cliente precisa)

aleck:

Então se eu possuir um sistema desenvolvido em Java 1.3 devo criar outro sistema e não migra-lo para a versao atual?

Concordo que muitas vezes nao vale a pena a migracao, porem nao me atrevo a generalizar desta forma.

Nem tudo é tudo.

maior_abandonado:

talvez essa seja uma visão meio leiga, tem mto mais detalhes ai no meio, mais de um modo geral, é assim que a coisa parece acaabr funcionando na pratica… tendo que re-escrever tudo do zero por causa de incompatibilidade.

aleck:

Novamente generalização.

Como disse anteriormente, existem casos e casos. Muitas vezes a evolução cria riscos maiores que a criação de novos sistemas. A tecnologia que os sistemas antigos foram construidos muitas vezes não atendem a necessidade do cliente, cabe ao desenvolvedor saber quando optar pela construção de novos sistemas, ou pelo menos opinar junto aos seus gestores.

Leonardo3001:

Não se refaz um sistema do zero, nunca!. Por mais cômodo que a reconstrução possa parecer, ela traz riscos enormes como: reavivar bugs já sanados no sistema antigo; ficar muito tempo com poucas features; e pior, acabar com um novo sistema tão ruim que precisa de uma “nova reconstrução”.

maior_abandonado:

talvez essa seja uma visão meio leiga, tem mto mais detalhes ai no meio, mais de um modo geral, é assim que a coisa parece acaabr funcionando na pratica… tendo que re-escrever tudo do zero por causa de incompatibilidade.