Recomendações para projetos de migração e evolução de plataforma – Parte 2/2
Olá pessoal, tudo certo?
No post anterior, falamos sobre alguns desafios em projetos de migração e evolução de plataforma que temos hoje em dia. Na verdade, muitas dessas questões são independentes de plataforma, seja para Microsoft, Java, Sun, Oracle, SQL, etc.
Vamos continuar o assunto com algumas recomendações mais que gostaria de compartilhar com vocês, a seguir:
Um projeto de migração normalmente começa focado na interface ou em suas regras de negócio, aquelas que não estão no banco de dados. Isso é um erro, pois muitas vezes, o impacto maior de desempenho e otimização está diretamente no modelo de dados do projeto. Antes de determinar qualquer tecnologia alvo para sua migração, procure avaliar o estado de seu modelo de dados, sua administração, estatísticas de uso, principais estruturas e stored procedures em uso, tabelas ou instâncias que estejam obsoletas. Em muitos projetos de evolução que buscavam melhorias de desempenho, a evolução tecnológica poderia focar apenas o banco de dados com excelentes resultados, devido a pequena participação dos componentes de software fora do banco ao longo da transação. Pense nisso: migrar de VB4 para .NET 4.0 pode até piorar a performance final do projeto, se o modelo de base de dados e suas integrações com outros sistemas não forem avaliadas. Pense no banco com carinho!
Para enfatizar, considere o envolvimento de um profissional de banco de dados para tarefas de otimização e modelagem para a nova arquitetura, durante seu projeto de migração/evolução de tecnologia. Não ignore as otimizações no modelo de dados ao longo do projeto, por mais complexo que seja o modelo.
Muitos projetos construídos na década de 90 ainda estão em operação, oferecendo funcionalidades no modelo CLIENTE / SERVIDOR. Ao longo do tempo, alguns web services e uma camada de serviços mal-acabada foi adicionada ao sistema, atendendo demandas entre departamentos. Pensando em evoluir seu projeto C/S, faça uma análise sobre a nova arquitetura proposta, prevendo uma organização em múltiplas camadas, com interface, processos, serviços e acesso a dados. Identificar corretamente uma camada de funcionalidades expostas como serviços pode eliminar diversos problemas de integração com outros sistemas. Aproveite essa oportunidade e pense em serviços com WCF e WF!
Outra questão interessante é sobre a nova abordagem do projeto: a migração deve manter o modelo desktop? será usado um modelo Web? vamos criar um modelo auto-configurável como SAAS, usando MVC? teremos novas interfaces alvo como dispositivos móveis? Procure separar os aspectos de migração das novas demandas de projeto e aspirações dos usuários de negócio. Evite trabalhar 3 ou 4 projetos mascarados num único projeto de migração tecnológica. Mas acima de tudo, defina com um bom embasamento se seu sistema será Web, Desktop ou SmartClient.
Um projeto de migração não envolve apenas questões técnicas e decisões sobre arquitetura: também envolve uma estratégia de evolução e entrega dos novos módulos do projeto. Existem diversas abordagens possíveis nesse processo: podemos congelar a versão atual do projeto original e construir um núcleo na nova plataforma, que será a indicada para as novas funcionalidades. Ao mesmo tempo, as funcionalidades migradas vão sendo desligadas do velho sistema e disponibilizadas apenas no novo. Outra abordagem é a construção em paralelo, onde o projeto original continua sendo mantindo, enquanto que um projeto novo é construído, migrando funcionalidades. Em um certo momento, um conjunto completo de funcionalidades é liberado na nova plataforma. Seja através de uma abordagem ágil e emergente de construção ou através de um modelo radical de “virar a chave” para o novo sistema, separe um bom tempo para pensar na estratégia de migração e evolução de seu projeto.
Para terminar, a nova plataforma deve envolver novas capacidades nos times de desenvolvimento e infraestrutura. Procure identificar qual será o impacto para sua operação e manutenção na nova plataforma, pensando no plano de capacitação e atualização tecnológica dos times envolvidos. Outro aspecto importante é sincronizar ao longo do tempo seu projeto com a infraestrutura da empresa. A nova arquitetura exige componentes de um novo sistema operacional? Ele já está homologado? Algum impedimento para o uso de .NET 3.5 ou .NET 4.0? Algum processo formal para a liberação do Windows Server 2008 R2? Temos SharePoint no licenciamento da empresa? Manter o arquiteto de infraestrutura ou responsável envolvido no projeto é obrigatório para se evitar surpresas no momento mais importante, o deployment!
Para terminar, continua valendo a dica: faça um belo estudo sobre as necessidades de negócio atuais de seu projeto e aproveito o momento para consolidar funcionalidades ou mesmo eliminar aquelas que não estão mais sendo utilizadas.
Por enquanto é só! Até o próximo post :)
Waldemir.