none
Opiniões sobre possível arquitetura para migrar sistema legado. RRS feed

  • Discussão Geral

  • Somos uma empresa pequena mas com uma cartela de clientes bem grande e que aborda de micro a grandes empresas.
    Podemos citar, logo de início, um banco, duas mineradoras, sindicatos, federações e alguns pontos de comércio, bem como escritórios de advocacia, de contabilidade e representações comerciais.

    Nossos sistemas ainda são, em sua maioria, Clipper (DOS). Alguns foram migrados para Win32 com Clarion mas ainda utilizando arquivo de dados (funcionaria como se fossem aplicações Delphi usando Paradox ou Access).

    Estamos passando por uma mudança e reestruturação inteira da empresa e, dentre ela, da nossa cartela de produtos.
    Deixando o blá-blá-blá de lado, basicamente vamos ter que "atualizar" nossos sistemas.

    O primeiro pensamento foi o mais óbvio: reescrever uma interface e manter um sistema estável e confiável. No entanto isso não funcionará para nossas necessidades, inclusive porque os sistemas hoje se tornaram obsoletos, repletos de código complexo e difícil de manter e não possuem mais características que os destaquem no cenário competitivo.

    Alguns dos requisitos dos sistemas:

    • Relatórios grandes, tanto de texto (analíticos) quanto outras impressões gerais (boletos bancários). E quando eu me refiro a grande aqui, é na faixa de 80, 100, 120 mil páginas (no caso de boletos, as páginas são repletas de imagens, tornando o relatório imenso).
    • Integração com outros sistemas (TOTVS é um exemplo que precisamos estudar porque já temos uma "demanda" para isso, de um dos clientes).
    • Integração com hardware no computador (leitores de cartão de assinatura digital, balanças em porta serial e em porta paralela e impressoras matriciais, leitores de cartão de crédito e outros).
    • Permitir acesso do usuário de ponta (cliente do meu cliente). O cliente lá na ponta precisa ter acesso aos seus dados pessoais, pendências financeiras e tudo mais.
    • Performance. O sistema não pode, em momento algum, sobrecarregar a rede do cliente ou o servidor. Claro que neste aspecto entra também o planejamento de infra, mas entendam que eu não posso me dar ao luxo por exemplo de desenvolver web usando milhares de pugins enormes javascript porque isso vai reduzir a banda, além de aumentar o peso nos clientes. O sistema precisa ser (web ou desktop) extremamente leve e rápido.
    • Usabilidade. Eu sei que isso está presente em ambos mas vale citar aqui que por ser uma empresa pequena não temos condição de, em um primeiro momento, contratar um profissional de design somente para cuidar de usabilidade. Então precisamos de algo que possa "fluir" bem com a equipe de desenvolvimento, mas que também possa ser melhorado posteriormente por um designer.
    • Manutenibilidade. Nossos sistemas estão nos clientes há mais de 20 anos e até hoje somente pequenas alterações foram realizadas. Com isso temos uma estrutura enxuta capaz de atender às demandas. Precisamos manter uma estrutura enxuta e extremamente eficiente.

    Temos uma idéia de arquitetura híbrida, na qual podemos criar toda a interface desktop para acesso local (usando, por exemplo, WPF) e construindo uma segunda interface, para os módulos que requerem ou se beneficiam de acesso web (usando, por exemplo, ASP.NET MVC3).

    Pensamos inicialmente em uma solução inteiramente Desktop e, embora ela atenda à uma necessidade inicial (migrar do DOS) ela não resolve o problema do acesso feito pelo cliente final.

    No entanto não temos cultura de desenvolvimento web e temos a sensação de melhor usabilidade e desenvolvimento mais rápido com WPF desktop do que puro ASP (não poderíamos usar, por exemplo, Silverlight, por questões de compatibilidade).

    Gostaria de opiniões e pontos de vista diferentes sobre o assunto e gostaria de saber o mercado anda praticando no assunto.

    Já andei rodando o fórum e outros fóruns, em perguntas novas e mais antigas, mas queria outros comentários, novas perspectivas (ainda mais com as "novas" tecnologias presentes desde o .NET 4).

    Obrigado.

    sexta-feira, 4 de março de 2011 16:14

Todas as Respostas

  • Poxa...

    Só isso?

    Em primeiro lugar, acho importante pensar em processos. Aparentemente o sistema é grande e com diversas particularidades/integração. Acho praticamente impossível começar com algo do zero tendo todas essas features inicialmente, então é importante pensar numa infra-estrutura a longo prazo. Integração contínua, issue tracker, controle de versão, política de gestão de versões e outros. Não vai ser do dia pra noite que vocês vão migrar tudo isso.

    Sobre as características:

    - Relatórios: Não conheço uma boa suite de relatórios para algo desse tamanho. A primeira coisa a se considerar é se hoje os relatórios são em formato "texto" (80 e 120 colunas) ou em formato gráfico mesmo. Isso pode fazer toda diferença na hora de optar por um gerador de relatórios. Algumas aplicações como impressão de NF's mesmo, no método clássico, funcionam bem em matricial. Matricial em modo gráfico é impraticável. Hoje em dia existe NF-E, nota fiscal impressa e não sei se vale a pena pensar nesse tipo de funcionalidade legada, mas vale a pena o questionamento.

    - Integração com outros sistemas. É sempre interessante pensar numa estrutura "isolada" para esse tipo de integração, alguma arquitetura baseado em plugins para separar código específico de cliente de código "core" da aplicação. Isso simplifica muito manutenção a longo prazo.

    - Integração com hardware. Esse ponto praticamente "inviabiliza" qualquer ambiente web. Visto que a aplicação precisa ter acesso a hardware na máquina cliente, o que é um processo um pouco complexo pensnado em Web.

    - "Acesso de Ponta": Aqui vale a pena um módulo específico em Web pra isso, para simplificar o deploy. ASP.NET MVC é uma boa pedida.

    - Performance. Aqui o investimento é em arquitetura mesmo. Geralmente aplicações com características de ERP tem gargalo mais em tráfego de rede do que em CPU.

    - Usabilidade. Vale a pena além do designer, pensar numa boa suíte de componentes. Recomendo: http://www.syncfusion.com/

    - Manutenebilidade: As decisões arquiteturais é que vão fazer o sistema com uma boa manutenção ou ruim. Vale a pena investir nisso.

     

    Sobre o WPF, ele é mais pesado do que Windows Forms puro. Deve-se avaliar se os custos aqui são maiores que os benefícios.

    Sobre arquitetura híbrida: Client/Server pro que exigir produtividade do operador, baseado em Windows Forms. Dependendo, vale a pena pensar num cliente rico em Windows Forms acessando um servidor via Remoting/HTTP ou outros, por questões de segurança e consumo de banda. Web para a parte que precisar de melhor acessibilidade e menos produtividade por parte do operador.

    Para Web, sem dúvida ASP.Net MVC, por questões da performance em run-time.

     

    Abraço,

    Eric

    sexta-feira, 4 de março de 2011 19:18