Recomendações para projetos de migração e evolução de plataforma – Parte 1/2

Olá pessoal, tudo certo?

Atuando como consultor pela Microsoft Services, participei de diversos projetos na área financeira. Essa vertical envolve características muito próprias como questões de desempenho, mensageria assíncrona, sistemas de logging, disparo de processos, agendamento de processos, monitoração, tratamento de exceções, entre tantas outras.

Mas um dos tipos de projetos recorrentes era o de migração e atualização tecnológica. Imagine um sistema de grande importância desenvolvido numa tecnologias de 5 ou 10 anos atrás:

• como migrar?
• como realizar a atualização da plataforma?
• e o impacto para a área de infraestrutura?
• que novos servidores serão indicados?
• como será a capacitação do time?
• vamos manter o modelo de dados e mudar apenas os componentes de negócio?
• vamos mudar a interface do sistema?
• estamos planejando uma arquitetura de exceção ou vamos aproveitar o projeto para planejar a nova TI da empresa?

Perguntas como essas são críticas para o arquiteto de soluções e cada empresa possui um cenário próprio que deve direcionar essas decisões.

Recentemente, estive com um time da área financeira enfrentando esse tipo de projeto, envolvendo a atualização da plataforma diante de um sistema muito antigo e igualmente importante. Entre as tecnologias usadas tivemos VB4, VB5, VB6, COM+, páginas ASP 3 e componentes de acesso ADO e COMTI (lembra da COMAREA?)

Algumas recomendações que passei para o time vou compartilhar aqui com vocês vejam:

1. A primeira pergunta antes de começar o projeto é: por que você quer migrar? Procure identificar se temos uma demanda de performance, de usabilidade, de suporte, de interface, funcionalidades ou se é um desejo do usuário de negócio, pensando em novas oportunidades para seu sistema. A correta identifcação da demanda original para essa migração é crítica para orientar o sucesso do projeto.

2. Se o projeto é antigo, é muito provável que diversos usuários de negócio e desenvolvedores tenham passado pelo sistema. Isso deve ter provocado a adição de diversas funcionalidades não mais usadas, que apenas fazem parte da versão em produção. Procure identificar se esse é o caso e se antes do processo de migração, não seria viável a eliminação de funcionalidades, funções e interfaces obsoletas, economizando muitas horas de projeto.

3. Da mesma forma, um sistema legado pode ser composto de mais de um processo ou projeto de software. Em muitos casos, a consolidação de sistemas é possível e pode oferecer benefícios enormes para a administração e evolução futuras do projeto. Procure identificar se módulos e sistemas não podem ser consolidados, eliminando funcionalidades redundantes e otimizando os passos de navegação e interação dos usuários de negócio com seu novo sistema.

4. Projetos de grande porte possuem dezenas, centenas de telas de entrada de dados, assim como interfaces customizadas para diferentes perfis de usuários de negócio. Ao longo do tempo, o projeto original é perdido e em muitos casos, novas interfaces e perfis de usuários são adicionados ao projeto sem respeitar modelos ou padronizações de acesso, criando grandes problemas de manutenção. Procure identificar se esse é o caso. Se afirmativo, pense em uma abordagem atualizada para o controle de acesso, customização de interfaces dinâmicas e autenticação / autorização para seus usuários de negócio. Esse será um bom momento para incluir aspectos de segurança que tenham sido perdidos ao longo do tempo.

5. Se o projeto em estudo envolve uma arquitetura de duas camadas CLIENTE / SERVIDOR, é muito provável que regras de negócio estejam tanto na camada de interface do usuário como também em stored procedures colocadas no banco de dados. Em muitos casos, outros sistemas são consumidores dessas mesmas stored procedures, competindo pelos recursos do banco de dados. Em outros casos, VIEWS diversas foram criadas para a exportação de dados para sistemas adjacentes e sofrerão com qualquer manuteção ou mudanças de interfaces. Procure mapear quais projetos são usuários de seu sistema. A identificação desses pontos de contato pode nos dar indícios sobre a necessidade futura de serviços, hubs de integração ou web services para outros departamentos.

Sem dúvida, cada projeto é uma caixinha de surpresa, mas um projeto de migração/evolução tecnológica pode ser tornar um container inteiro e não é de Windows Azure!! :)

Por isso, faça uma boa análise sobre os reais requisitos e necessidades atualizadas do sistema, ao invés de apenas migrá-lo para uma nova plataforma: resista a essa tentação!!!

No próximo post, vamos continuar esse assunto com algumas outras recomendações também importantes, aguardem!

Por enquanto é só! Até o próximo post :)

Waldemir.