Metodologia de migração de dados em um contexto de migração de sistemas legados

Texto

(1)Universidade Federal de Pernambuco CENTRO DE INFORMÁTICA PÓS- GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO. Manoel Heleno Ramos de Mendonça. Metodologia de Migração de Dados em um contexto de Migração de Sistemas Legados". Este trabalho foi apresentado à Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre Profissional em Ciência da Computação.. ORIENTADOR(A): Prof. Dr. Fernando da Fonseca de Souza. RECIFE,ABRIL/2009.

(2) METODOLOGIA DE MIGRAÇÃO DE DADOS EM UM CONTEXTO DE MIGRAÇÃO DE SISTEMAS LEGADOS por. MANOEL HELENO RAMOS DE MENDONÇA Dissertação de Mestrado Profissional. Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao. RECIFE, ABRIL / 2009.

(3) MANOEL HELENO RAMOS DE MENDONÇA. METODOLOGIA DE MIGRAÇÃO DE DADOS EM UM CONTEXTO DE MIGRAÇÃO DE SISTEMAS LEGADOS Orientador: Prof. Dr. Fernando da Fonseca de Souza. Dissertação apresentada à Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial à obtenção do grau de Mestre Profissional em Ciência da Computação.. RECIFE, ABRIL / 2009.

(4) Mendonça, Manoel Heleno Ramos de. Metodologia de migração de dados em um contexto de migração de sistemas legados. / Manoel Heleno Ramos de Mendonça - Recife : O autor, 2009. vi, 119, xiii folhas : il., fig., quadro. Dissertação (mestrado) - Universidade Federal de Pernambuco. CIN. Ciência da Computação, 2009. Inclui bibliografia, apêndice e glossário. 1. Banco de dados. 2. Migração de dados. 3. Migração de sistemas legados. 4. Gerência de projetos. I. Título.. 005.74. CDD (22.ed.). MEI-2009-092.

(5)

(6) DEDICATÓRIAS. Dedico este trabalho à minha esposa, Sandra, e aos meus filhos, Ítalo e Raíssa, pela solidariedade, estímulo e carinho que recebi durante toda a sua realização e pelo tempo, irrecuperável, que não pude estar com eles nem lhes dar atenção..

(7) AGRADECIMENTOS. Agradeço a minha esposa, Sandra, pelo companheirismo, dedicação, renúncia e compreensão durante todo o tempo em que me dediquei a este trabalho. Aos meus filhos, Ítalo e Raíssa, fontes de inspiração, estímulo e alívio do cansaço. Aos meus pais, Heleno e Iolanda, pela formação e apoio incondicional que me acompanham até hoje. Ao meu orientador, Prof. Dr. Fernando Fonseca, pela orientação segura, conhecimento, disponibilidade, paciência e sugestões acertadas que tão bem me conduziram para alcançar este objetivo. Agradeço, também, a Superintendência de Tecnologia da Informação da Secretaria da Fazenda do Estado de Pernambuco, nas pessoas de Nevton Borba e Ana Paula Serrano, por acreditarem neste trabalho e viabilizarem sua conclusão. Por fim, agradeço a todos os professores e funcionários do CIN e aos meus colegas de turma que proporcionaram a possibilidade desta nova experiência de vida..

(8) METODOLOGIA DE MIGRAÇÃO DE DADOS EM UM CONTEXTO DE MIGRAÇÃO DE SISTEMAS LEGADOS. RESUMO A presente dissertação visa à definição de uma metodologia para migração de dados em um contexto de migração de sistemas legados, desenvolvida utilizando os conceitos e práticas já estabelecidas das várias metodologias para migração de sistemas legados, das estratégias para migração de dados e das técnicas de gerência de projetos. Existem diversos trabalhos que abordam a necessidade da definição e organização de atividades essenciais para que esforços de migração de dados legados alcancem seus objetivos, existem até mesmo estratégias de migração de dados definidas. Porém, não se encontrou na literatura consultada trabalho que analise as três áreas essenciais para tal empreitada migração de sistemas legados, migração de dados e gerência de projetos e proponha uma metodologia tão abrangente quanto o apresentado neste trabalho. Somado a isto, encontra-se a necessidade de gerentes de projeto e projetistas de soluções de utilizar metodologias definidas e testadas que os orientem e ajudem em tarefa tão fundamental e crítica para o sucesso de um projeto de migração de sistema legado como é a migração dos dados legados. Fez-se uma análise dos trabalhos relacionados e bibliografia disponível e foram definidos os pontos de interseção das três áreas estudadas. Baseando-se nestes pontos convergentes e relacionados, foram especificadas cinqüenta e duas atividades, divididas em seis etapas, que cobrem os passos necessários para o planejamento, execução e controle de uma migração de dados legados. Para validar as atividades propostas, a metodologia foi aplicada em um estudo de caso real onde foram migrados cento e vinte e nove milhões de registros legados para cento e quarenta e cinco novas tabelas. O estudo de caso durou dezoito meses. Os resultados obtidos foram promissores se comparados com médias históricas da organização e com outros projetos que foram desenvolvidos na mesma época sem o uso da metodologia proposta.. Palavras-chave: Banco de dados, Migração de dados, Migração de sistemas legados, Gerência de projetos..

(9) A METHODOLOGY TO DATA MIGRATION IN A LEGACY SYSTEM MIGRATION CONTEXT. ABSTRACT This dissertation is aimed at defining a methodology to data migration in a legacy system migration context. It has been developed using the concepts and practices settled down by various methodologies for legacy systems migration, strategies for data migration as well as techniques from project management. There are several works that focus on the definition and organization of essential activities to aid legacy data migration to succeed. There are also defined strategies for data migration in general. However, none of the ones found in the literature analyses the three areas essentials for such a task legacy systems migration, data migration and project management - nor proposes a deep process such as the one presented in this work. Added to that, there is also the need to project managers and designers for solutions that use defined and sound processes that may guide them and help with a critical and fundamental task for a legacy system migration such as the legacy data migration. An analysis of related works has been carried out, and the intersection of the three studied areas has been determined. Based on such points of intersection it has been specified fifty two activities divided into six stages that cover all the needed steps for planning, executing and controlling a legacy data migration. To validate the proposed activities, the methodology has been applied to a real case study where a hundred and twenty millions of legacy records have been migrated to a hundred and forty five tables. The case study has taken eighteen months. The found results shown to be promising as compared to historical averages obtained by the organization and to other projects that have been developed at the same time but without using the proposed methodology.. Keywords: Data Base, Data Migration, Legacy System Migration, Project Management.. i.

(10) Sumário. Capítulo 1: Introdução ...................................................................................................... 1 1.1 Contexto.................................................................................................................. 1 1.2 Motivação ............................................................................................................... 2 1.3. Objetivos ................................................................................................................ 2 1.4. Estrutura da dissertação ......................................................................................... 3 Capítulo 2: Conceitos Básicos .......................................................................................... 4 2.1. Sistemas Legados................................................................................................... 4 2.2. Migração de Sistemas Legados.............................................................................. 5 2.2.1. Metodologias de Migração de Sistemas Legados........................................... 5 2.3. Migração de Dados ................................................................................................ 7 2.3.1. Estratégias de Migração de Dados.................................................................. 8 2.3.2. Passos de uma migração de dados .................................................................. 9 2.3.3. Desafios de uma migração de dados............................................................. 12 2.3.4. Fatores de Sucesso de uma migração de dados ............................................ 13 2.3.5. Arquitetura de migração de dados ................................................................ 15 2.3.6. Riscos de uma migração de dados ................................................................ 18 2.4. Gerência de Projetos ............................................................................................ 19 2.4.1. Ciclo de vida do projeto................................................................................ 21 2.4.2. Processos de gerenciamento de projetos....................................................... 22 2.4.3. Áreas de conhecimento em gerenciamento de projetos................................ 39 2.5. Conclusões do capítulo ........................................................................................ 42 Capítulo 3: Metodologia proposta .................................................................................. 44 3.1. Planejamento........................................................................................................ 45 3.1.1. Desenvolver o Plano de Migração ................................................................ 47 3.1.2. Definição do escopo da migração ................................................................. 48 3.1.3. Identificação dos ambientes atual e futuro.................................................... 53 3.1.4. Definição da arquitetura da migração ........................................................... 53 3.1.5. Definição das atividades da migração .......................................................... 54 3.1.6. Seqüenciamento das atividades da migração................................................ 54 3.1.7. Estimativa de recursos da atividade.............................................................. 55 3.1.8. Desenvolvimento do cronograma ................................................................. 55 3.1.9. Estimativa de custos...................................................................................... 56 3.1.10. Planejamento da qualidade ......................................................................... 57 3.1.11. Definição das comunicações....................................................................... 57 3.1.12. Identificação de riscos ................................................................................ 57 3.1.13. Análise qualitativa dos riscos ..................................................................... 58 3.1.14. Definir necessidade de compras e aquisições ............................................. 59 3.1.15. Definir necessidades de recursos humanos................................................. 59 3.1.16. Plano de testes e validação.......................................................................... 60 3.1.17. Plano de implantação .................................................................................. 60 3.1.18. Plano de contingência ................................................................................. 60 3.2. Monitoramento e Controle................................................................................... 61 3.2.1. Controle de mudanças................................................................................... 61 3.2.2. Verificação do escopo................................................................................... 62 3.2.3. Controle do cronograma ............................................................................... 62. i.

(11) 3.2.4. Controle de custos......................................................................................... 62 3.2.5. Realizar o controle da qualidade................................................................... 62 3.2.6. Gerenciar a equipe do projeto ....................................................................... 62 3.2.7. Monitoramento e controle de riscos.............................................................. 63 3.3. Profiling e Auditorias........................................................................................... 63 3.3.1. Construir ou atualizar o modelo de dados do sistema fonte ......................... 64 3.3.2. Construir ou atualizar o dicionário de dados do sistema fonte ..................... 64 3.3.3. Construir o modelo de dados do sistema alvo .............................................. 65 3.3.4. Construir o dicionário de dados do sistema alvo .......................................... 65 3.3.5. Definir o profiling......................................................................................... 65 3.3.6. Verificar a possibilidade de aquisição de ferramenta de profiling ............... 66 3.3.7. Construir os programas de auditoria ............................................................. 66 3.3.8. Realizar o profiling nos dados fonte ............................................................. 66 3.3.9. Análise dos resultados do profiling e auditoria ............................................ 67 3.4. Construção e design ............................................................................................. 67 3.4.1. Definição das regras de limpeza dos dados .................................................. 68 3.4.2. Construção do mapa de dados ...................................................................... 68 3.4.3. Especificação dos programas de migração ................................................... 69 3.4.4. Especificação dos programas de sincronismo .............................................. 70 3.4.5. Codificação dos programas........................................................................... 70 3.4.6. Testes dos programas.................................................................................... 71 3.4.7. Construção dos jobs para execução das rotinas ............................................ 71 3.4.8. Testes dos jobs .............................................................................................. 71 3.4.9. Teste da migração dos dados ........................................................................ 71 3.5. Execução .............................................................................................................. 72 3.5.1. Extração dos dados ....................................................................................... 72 3.5.2. Transformação dos dados ............................................................................. 72 3.5.3. Carga dos dados ............................................................................................ 73 3.5.4. Tratamento das rejeições de dados ............................................................... 73 3.6. Testes e Validação dos dados .............................................................................. 74 3.6.1. Testes unitários ............................................................................................. 74 3.6.2. Testes de carga.............................................................................................. 75 3.6.3. Testes de sistema .......................................................................................... 75 3.6.4. Análise dos testes.......................................................................................... 75 3.6.5. Homologação da migração dos dados .......................................................... 75 3.7 Conclusões do capítulo ......................................................................................... 76 Capítulo 4: Validação da metodologia............................................................................ 81 4.1. Cenário do estudo de caso ................................................................................... 81 4.2. Aplicação da metodologia ................................................................................... 82 4.2.1. Planejamento................................................................................................. 82 4.2.2. Monitoramento e Controle.......................................................................... 100 4.2.3. Profiling e Auditorias ................................................................................. 102 4.2.4. Construção e Design ................................................................................... 107 4.2.5. Execução ..................................................................................................... 110 4.2.6. Testes e Validação dos dados ..................................................................... 112 Capítulo 5: Conclusões ................................................................................................. 118 5.1. Principais contribuições ..................................................................................... 118 5.2. Limitações.......................................................................................................... 118 5.3. Sugestões de trabalhos futuros........................................................................... 119 5.4. Considerações finais .......................................................................................... 119. ii.

(12) LISTA DE FIGURAS. Figura 1 Passos para identificação e mapeamento de dados........................................ 10 Figura 2 Arquitetura de migração de dados Point-to-Point. ........................................ 16 Figura 3 Arquitetura de migração de dados Hub-Spoke.............................................. 17 Figura 4 - Visão geral das áreas de conhecimento em gerenciamento de projetos e os processos de gerenciamento de projetos................................................................. 20 Figura 5 - Áreas de especialização necessárias à equipe de gerenciamento de projetos.21 Figura 6 - Resumo de alto nível das interações entre os grupos de processos................ 23 Figura 7 - Entradas e saídas: Desenvolver o plano de gerenciamento do projeto. ......... 24 Figura 8 - Entradas e saídas: Definição do Escopo. ....................................................... 25 Figura 9 - Entradas e saídas: Definição da atividade...................................................... 25 Figura 10 - Entradas e saídas: Seqüenciamento de atividades........................................ 26 Figura 11 - Entradas e saídas: Estimativa de recursos da atividade. .............................. 26 Figura 12 - Entradas e saídas: Estimativa de duração da atividade. ............................... 27 Figura 13 - Entradas e saídas: Desenvolvimento do cronograma................................... 27 Figura 14 - Entradas e saídas: Estimativa de custos. ...................................................... 28 Figura 15 - Entradas e saídas: Planejamento da qualidade. ............................................ 28 Figura 16 - Entradas e saídas: Planejamento de recursos humanos................................ 29 Figura 17 - Entradas e saídas: Planejamento das comunicações. ................................... 29 Figura 18 - Entradas e saídas: Identificação dos riscos. ................................................. 30 Figura 19 - Entradas e saídas: Análise qualitativa de riscos........................................... 30 Figura 20 - Entradas e saídas: Planejar compras e aquisições. ....................................... 31 Figura 21 - Entradas e saídas: Orientar e gerenciar a execução do projeto. ................... 32 Figura 22 - Entradas e saídas: Realizar a garantia da qualidade..................................... 32 Figura 23 - Entradas e saídas: Contratar ou mobilizar a equipe do projeto.................... 33 Figura 24 - Entradas e saídas: Distribuição das informações. ........................................ 33 Figura 25 - Entradas e saídas: Monitorar e controlar o trabalho do projeto. .................. 34 Figura 26 - Entradas e saídas: Monitorar e controlar o trabalho do projeto.Entradas e saídas: Controle integrado de mudanças................................................................. 35 Figura 27 - Entradas e saídas: Verificação do escopo. ................................................... 35 Figura 28 - Entradas e saídas: Controle do escopo. ........................................................ 36 Figura 29 - Entradas e saídas: Controle do cronograma. ................................................ 36 Figura 30 - Entradas e saídas: Controle de custos. ......................................................... 37 Figura 31 - Entradas e saídas: Realizar controle da qualidade. .................................... 37 Figura 32 - Entradas e saídas: Gerenciar a equipe do projeto......................................... 38 Figura 33 - Entradas e saídas: Monitoramento e controle dos riscos. ............................ 38 Figura 34 - Mapeamento entre os processos de gerenciamento de projetos e as áreas de conhecimento. ......................................................................................................... 41 Figura 35 - Interseção entre as áreas estudadas .............................................................. 43 Figura 36 - Interações entre as etapas da metodologia proposta .................................... 45 Figura 37 - Cronograma do projeto exemplos gráficos. .............................................. 56 Figura 38 - Ciclo de migração de dados da etapa de Execução...................................... 74. iii.

(13) Figura 39 - Ambientes utilizados na migração de dados ................................................ 90 Figura 40 - Lista das atividades contidas no cronograma............................................... 91 Figura 41 - Seqüenciamento das atividades realizado no cronograma. .......................... 92 Figura 42 - Relatório de recursos utilizados no projeto.................................................. 93 Figura 43 - Cronograma do projeto. ............................................................................... 94 Figura 44 - Estimativa de custos do projeto. .................................................................. 95 Figura 45 - Planilha inicial de riscos do projeto. ............................................................ 97 Figura 46 - Plano de testes. ............................................................................................. 98 Figura 47 - Plano de implantação. .................................................................................. 99 Figura 48 - Modelo de dados do sistema legado .......................................................... 103 Figura 49 - Modelo de dados do sistema alvo .............................................................. 104 Figura 50 - Documento base para o Profiling............................................................... 105 Figura 51 - Resultado do Profiling ............................................................................... 106 Figura 52 - Mapa de dados do projeto. ......................................................................... 108 Figura 53 - Log de uma iteração de carga de dados ..................................................... 111 Figura 54 - Tela do sistema Fronteiras ......................................................................... 113 Figura 55 - Tela do sistema CMT ................................................................................. 114 Figura 56 - Gráfico comparativo da migração dos dados ............................................. 116. iv.

(14) LISTA DE QUADROS. Quadro 1 - Quadro comparativo entre as metodologias Chicken Little e Butterfly ......... 7 Quadro 2 - Quadro comparativo entre as estratégias Big Bang e Trickle ........................ 9 Quadro 3 - Quadro comparativo entre as estratégias Point-to-Point e Hub-Spoke ........ 18 Quadro 4 Atividades da etapa de Planejamento .......................................................... 47 Quadro 5 Exemplo de uma atividade da Lista de Atividades...................................... 54 Quadro 6 - Exemplo de Estimativa de recursos de uma atividade ................................. 55 Quadro 7 Exemplo de Lista de riscos identificados .................................................... 58 Quadro 8 Exemplo de Lista de riscos identificados com a análise qualitativa............ 59 Quadro 9 Atividades da etapa de Monitoramento e Controle...................................... 61 Quadro 10 Atividades da etapa de Profiling e Auditorias. .......................................... 64 Quadro 11 - Atividades da etapa de Construção e Design.............................................. 67 Quadro 12 Exemplo de mapa de dados ....................................................................... 69 Quadro 13 - Atividades da etapa de Execução. .............................................................. 72 Quadro 14 Atividades da etapa de Testes e Validação dos dados ............................... 74 Quadro 15 Atividades relativas ao planejamento e controle das atividades e ao conhecimento e qualidade dos dados fonte e alvo.................................................. 77 Quadro 16 Atividades da metodologia proposta divididas por etapa .......................... 79 Quadro 17 Características do ambiente atual .............................................................. 88 Quadro 18 Características do ambiente futuro ............................................................ 88. v.

(15) PRINCIPAIS ABREVIATURAS. ROI. Return Of Investment. SGBD. Sistema de Gerenciamento de Banco de Dados. SQL. Structured Query Language. TIC. Tecnologia da Informação e Comunicação. XML. eXtensible Markup Language. XMI. XML Metadata Interchange. vi.

(16) Capítulo 1: Introdução Segundo Larousse [Gra99], migrar é mudar ou passar para outra região ou para outro país. A Vida, no seu laboratório de 3,8 bilhões de anos, consolidou as migrações como estratégia de sobrevivência. No ecossistema de Tecnologia da Informação e Comunicação (TIC) aplica-se o conceito com a mesma semântica: mudança. Porém, com atores e locais diferentes. É usual falar-se, entre outras migrações, em migração de ambiente computacional, migração de plataforma, migração de arquitetura, migração de dados. O que essas migrações têm em comum com a definição anterior é que, geralmente, elas buscam vantagens em novos ambientes. Outra constatação é que não é fácil migrar, pois exige preparação e esforço, além de nem sempre se conseguir alcançar bons resultados. Neste capítulo introdutório, mostra-se o contexto onde este trabalho se insere, a motivação, os objetivos do trabalho e a estrutura da dissertação.. 1.1 Contexto Migração de dados é um tema bastante abrangente, sendo uma necessidade nos negócios de qualquer empresa. Estima-se que as empresas americanas investem entre 5 e 10 bilhões de dólares anuais em projetos de migração de dados [How08]. Empresas migram dados por diversos motivos. Os principais são: atualização de hardware, mudança de sistema de gerenciamento de banco de dados (SGBD) e mudança de sistemas aplicativos. Todos estes tipos de migração envolvem riscos. Maiores ou menores, mas sempre presentes. O foco deste trabalho está relacionado com o terceiro motivo apresentado: a migração de dados na mudança de sistemas aplicativos. As empresas gastam muito dinheiro em sistemas de software, e para que elas obtenham um retorno desse investimento o software deve ser utilizado por vários anos. O tempo de duração de sistemas de software é muito variável e muitos sistemas de grande porte permanecem em uso por mais de 10 anos. Muitos desses antigos sistemas ainda são fundamentais para as empresas, isto é, as empresas dependem dos serviços fornecidos pelo software, e qualquer falha desses serviços teria um sério efeito em seu dia-a-dia. A esses antigos sistemas foi dado o nome de sistemas legados [Som03]. Os sistemas legados não são os sistemas que foram originalmente fornecidos. Fatores internos e externos geram requisitos de software novos ou modificados; assim, todos os sistemas de software úteis inevitavelmente são modificados quando as empresas passam por mudanças. Portanto, os sistemas legados incorporam um grande número de alterações, que foram feitas durante muitos anos por muitas pessoas. É incomum que qualquer pessoa tenha uma compreensão completa do sistema [Som03]. Devido ao grande número de modificações, que geralmente não estão documentadas, e ao número elevado de pessoas que programaram estas modificações, a complexidade do software aumenta e com ela o custo de mantê-lo. Empresas tendem a querer migrar seus sistemas legados para novos ambientes, que permitem ao sistema de informação uma manutenção mais simples. Porém, a decisão não é fácil, pois envolve muitos riscos. Os benefícios da migração para novos ambientes são enormes em longo prazo: ela oferece mais flexibilidade, um melhor entendimento do sistema, fácil manutenção e custos reduzidos [Wu+99].. 1.

(17) Porém, a migração de dados é uma tarefa tipicamente complexa e trabalhosa nos ambientes computacionais atuais, dada a miríade de servidores de aplicação, sistemas operacionais, sistemas de arquivos, equipamentos físicos e redes [IBM07]. Vários são os desafios impostos pela migração, como o tempo no qual o sistema original ficará inoperante, a necessidade de adicionar software de migração de dados em servidores, a possibilidade de perda e corrupção de dados. Ainda o surgimento de erros advindos da complexidade de ambientes heterogêneos, a possibilidade de atraso no cronograma ou estouro do orçamento definido para o projeto [IBM07]. As empresas vêm gastando milhões de dólares migrando dados entre aplicações que lidam com informação em massa e, ainda com todo esse investimento, novos sistemas falham em satisfazer as expectativas [Wu+97b]. Várias pesquisas vêm sendo conduzidas na tentativa de desenvolver uma maneira segura e barata de guiar a migração de um sistema legado como um todo [Ben95, BrS93, Dat07, IBM07, NaG92, Til96, Wu+97a, Wu+97b, Wu+05, Wu+99, Wu+97c].. 1.2 Motivação Tradicionalmente recebendo a menor das atenções nos projetos de TIC, habitualmente colocada no fim do planejamento do projeto, migração de dados pode ser a diferença entre uma realização bem sucedida e uma oportunidade perdida. Migração de Dados não é somente mover dados de um lugar para outro [Mor08]. Tem-se observado que, geralmente, no ciclo de vida de um novo projeto de sistema de software, pouca atenção, prioridade e planejamento são dispensados aos dados que porventura necessitem ser migrados [How08, Moh04, Mor08, She99]. Migrar dados exige olhar para o passado legado quando, na maioria dos casos, a demanda pressiona para que o futuro chegue mais depressa. No atual estado da arte de TIC, é incomum construir-se um novo software aplicativo sem a necessidade de migrar dados. Esta crescente necessidade torna a atividade cada vez mais importante para o sucesso do projeto.. 1.3. Objetivos O objetivo desta dissertação é integrar algumas das principais estratégias de migração de dados existentes na literatura com práticas de gerência de projetos para definir uma metodologia genérica de migração de dados num contexto de migração de sistemas legados, validando esta metodologia em um caso real de grande porte. Para tal, propõe-se estudar e avaliar as estratégias disponíveis de migração de dados, os passos envolvidos, os desafios e os fatores de sucesso de um projeto de migração de dados. Será também verificada a aderência destas estratégias às boas práticas de gerência de projetos. O estudo de caso escolhido para validar a metodologia proposta envolve um grande sistema legado corporativo, com a migração de cento e vinte e nove milhões de registros, realizado no Projeto E - Fisco da Secretaria da Fazenda do Estado de Pernambuco [Sec08]. Os resultados obtidos serão analisados para a identificação dos pontos fortes e fracos, erros cometidos e sugestões de melhoria. Neste trabalho, para maior clareza, será chamado de sistema fonte o sistema legado e de sistema alvo o novo sistema a ser implantado, os quais serão usados como exemplo para o estudo de caso.. 2.

(18) 1.4. Estrutura da dissertação Este trabalho é composto de cinco capítulos, incluindo este. No Capítulo 2, serão abordadas metodologias de migração de sistemas legados, o processo de migração de dados, estratégias de migração de dados, os passos envolvidos no processo, além dos principais desafios e fatores que levam um projeto de migração de dados ao sucesso. Serão feitas algumas considerações em relação a tais estratégias de migração de dados. Também serão abordadas as atividades de Gerência de Projetos. No Capítulo 3, baseando-se nos conceitos mostrados no Capítulo 2, será apresentada a metodologia de migração de dados proposta. No Capítulo 4, a metodologia definida no Capítulo 3 será aplicada ao estudo de caso. Serão mostrados os resultados obtidos. No Capítulo 5 estão as considerações finais deste trabalho, contendo uma avaliação da metodologia desenvolvida, destacando-se o que funcionou, o que poderia ter sido melhor e são apresentadas sugestões de trabalhos futuros.. 3.

(19) Capítulo 2: Conceitos Básicos Neste capítulo é feita uma revisão dos principais conceitos relativos a sistemas legados e migração desses sistemas, bem como tópicos relevantes da gerência de projetos. Assim, são levantadas as características das principais metodologias de migração de sistemas legados, das principais estratégias de migração de dados, além de tópicos importantes da gerência de projetos aplicáveis a esse contexto. Todos estes assuntos são fundamentais como referenciais conceituais para a construção de uma metodologia de migração de dados em um contexto de migração de sistema legado, que é objetivo desta dissertação. Os termos origem, legado e fonte serão usados como sinônimos quando se referirem ao ambiente ou sistema legado.. 2.1. Sistemas Legados Atualmente os sistemas de informação legados são um problema dominante em várias organizações e grandes indústrias. Os maiores problemas enfrentados são a manutenção dos sistemas para que eles possam continuar atendendo às necessidades dos negócios e a dificuldade em deixá-los operacionais, devido principalmente à defasagem tecnológica. Apesar destas características, a tecnologia não deve ser o fator que leva qualquer organização a reestruturar o seu negócio. Os requisitos dos negócios é que devem levar a uma mudança na tecnologia e nos sistemas de informação. Segundo Brodie et al. [BrS95], um sistema de informação legado é qualquer sistema de informação que resiste a mudanças e evoluções em grande parte devido às dificuldades em manutenção. Desta forma, não somente sistemas com milhares ou milhões de linhas de código, escritos em COBOL [Ste99], mas também sistemas mais modernos, escritos em C [Ke+88] ou C++ [Str00], podem ser exemplos de sistemas legados. Outra característica dos sistemas legados é que eles costumam consumir grande parte dos recursos financeiros do total aplicado em sistemas de informação de uma organização, impedindo, muitas vezes, a sua migração para que possam atender às necessidades dos negócios. O desenvolvimento de sistemas centralizados, baseados em mainframes, modelos de desenvolvimento totalmente dependente do hardware e software utilizados, interfaces de usuário baseadas em terminais não gráficos e processamento batch, predominante nas últimas décadas, levou várias empresas a uma verdadeira crise, pois suas aplicações não conseguem evoluir com a mesma rapidez que os negócios exigem. Além disso, elas são totalmente dependentes deste tipo de sistemas, o que os tornam sistemas imprescindíveis [PrM02] para estas empresas. As características dos sistemas legados são [BrS95]: São grandes, com milhões de linhas de código; São velhos, mais de dez anos, e passaram por várias reestruturações; Usam linguagens legadas como COBOL [Ste99]; Foram construídos sobre um sistema de banco de dados legado, por exemplo, IMS [Me+05] ou sobre estruturas de arquivos como: ISAM [Gro90] e VSAM [Low86]; São autônomos, isto é, não têm interface com nenhuma outra aplicação; Apresentam baixo desempenho; e Possuem pouca ou nenhuma documentação e geralmente estão desatualizadas. 4.

(20) Os sistemas de informações legados tradicionais são aqueles baseados em mainframe, porém, o paradigma de sistemas legados pode ser aplicado a qualquer plataforma. Características como aumento dos custos de manutenção e aumento do intervalo de tempo em incorporar novas funcionalidades podem representar um sistema de informação legado em formação.. 2.2. Migração de Sistemas Legados Apesar de este tópico estar sendo pesquisado há anos e ser um assunto muito discutido e exposto, além de existirem várias ferramentas que se propõem a traduzir estes sistemas, pouco tem sido feito neste sentido pelas grandes organizações. Quando existe este esforço, o sistema é totalmente refeito, como exemplificado no estudo de caso desta dissertação. Para que o processo de migração dos sistemas legados para uma nova tecnologia tenha sucesso, é necessário ter um plano ou estratégia para esta migração, uma vez que os sistemas legados não podem parar, isto é, continuam em evolução, enquanto a migração está acontecendo.. 2.2.1. Metodologias de Migração de Sistemas Legados O sucesso de um projeto de migração de sistemas legados depende do desenvolvimento de uma metodologia que seja detalhada e bem definida, já que este tipo de projeto é de enorme escala, complexidade e muito suscetível a falhas [Dat07]. Atualmente, duas metodologias são mais aceitas pela comunidade: Chicken Little e Butterfly. 2.2.1.1. Chicken Little Na metodologia Chicken Little, Brodie e Stonebraker [BrS93, BrS95] propõem uma estratégia de migração composta de onze etapas genéricas que utilizam complexos gateways. Um gateway pode ser definido como qualquer módulo de software introduzido entre componentes de software com o objetivo de mediá-los [Wu+97a]. Esta metodologia deixa a cargo da equipe escolher qual método de migração utilizar: o método Forward ou Database First ou o método Reverse ou Database Last. O método de migração Forward ou Database First envolve a migração inicial dos dados legados para uma nova base e, em seguida, a aplicação e as interfaces são migradas incrementalmente [Wu+97a]. Um forward gateway é utilizado para que a aplicação original acesse os dados na plataforma destino. O método de migração Reverse ou Database Last faz com que a aplicação seja migrada gradualmente para a plataforma destino, enquanto que a base de dados permanece na plataforma original [Wu+97a]. A migração dos dados é a última etapa deste processo. Um reverse gateway é utilizado para que a aplicação destino acesse os dados da plataforma original. Nesses dois métodos, os sistemas de origem e destino operam paralelamente durante o processo da migração, o que adiciona complexidade [Dat07]. Os próprios autores reconhecem que manter a consistência dos dados entre sistemas de informação heterogêneos representa um problema técnico complexo e que ainda não foi proposta uma solução geral [Wu+97a]. Os onze passos que compõem a metodologia Chicken Little são: 5.

(21) 1. Analisar o sistema legado; 2. Decompor a estrutura do sistema legado; 3. Projetar a interface destino; 4. Projetar a aplicação destino; 5. Projetar a base de dados destino; 6. Instalar o ambiente destino; 7. Criar e instalar os gateways necessários; 8. Migrar as bases legadas; 9. Migrar as aplicações legadas; 10. Migrar as interfaces legadas; e 11. Mudar para o sistema destino. Note-se que o presente trabalho envolve principalmente as fases 5 e 8. Um dos aspectos destacados é que estas fases devem ser tratadas como um subprojeto independente e o fato de não sê-lo, é uma fonte de falhas, atrasos e insucesso [How08, Moh04, Mor08, She99]. 2.2.1.2. Butterfly Ao contrário da metodologia Chicken Little, a metodologia Butterfly questiona a necessidade de interoperabilidade entre as aplicações [Wu+97b]. Ela leva em consideração o fato de que o sistema legado não estará em produção enquanto o processo de migração ocorre [Wu+97b]. A metodologia propõe o desenvolvimento de um motor de migração de dados, a fim de que o sistema legado fique fora do ar o mínimo possível. Ela difere dos métodos Forward e Reverse Migration na medida em que o sistema legado deve ficar fora do ar por um tempo considerável para facilitar a migração dos dados antes do sistema destino entrar em funcionamento. Este é uma abordagem mais simples, porém mais arriscada, pois todo o fluxo de informação da aplicação passará a ser executado em um sistema não confiável [Wu+97b]. Segundo Bing Wu et al. [Wu+97b], os passos que compõem a metodologia são: 1. Planejar a migração; 2. Entender a semântica do sistema legado e desenvolver o esquema de dados destino; 3. Migrar todos os componentes, exceto os dados, do sistema legado para a arquitetura destino; 4. Gradualmente migrar os dados legados para o sistema destino e treinar os usuários a usar a aplicação destino; e 5. Passar a utilizar a aplicação destino. Na fase 2, quando se destaca a importância de entender a semântica do sistema legado, geralmente faz-se com base no negócio atual da empresa. É incomum, e na maioria dos casos faltam fontes de informação, levantar requisitos históricos, ou seja, procurar saber como o sistema legado funcionava em suas diversas versões e em como ele usava e atualizava os dados da empresa naqueles momentos. Esta perda de memória institucional é, também, uma fonte de problemas quando se precisa definir as necessárias transformações sobre os dados legados para migrá-los para o novo sistema, principalmente quando se precisa migrar dados históricos [Mor08]. O Quadro 1 apresenta uma comparação entre as metodologias Chicken Little e Butterfly.. 6.

(22) Quadro 1 - Quadro comparativo entre as metodologias Chicken Little e Butterfly. Características Necessidade de gateways Complexidade Sistema legado fora do ar Dados migram primeiro Porte da migração Interoperabilidade entre as aplicações. Chicken Little (Forward) Sim. Chicken Little (Reverse) Sim. Butterfly Não. Alta Não. Alta Não. Média Sim. Sim. Não. Sim. Médio / Grande Sim. Médio / Grande Sim. Pequeno Não. 2.3. Migração de Dados Freqüentemente, os dados que uma nova aplicação 1 necessita vêm de outras aplicações existentes [YoK92]. Caso estes dados estejam disponíveis em sistemas existentes e seu volume seja muito grande, eles devem ser migrados das aplicações existentes para a nova aplicação, em vez de recriados. O processo de transferir dados de um sistema para outro é chamado de migração de dados. Projetos de migração de dados são complexos e o foco deve ser a migração da menor quantidade de dados possível para que a aplicação destino possa entrar em funcionamento [Dat07]. Nem sempre todos os dados de origem serão necessários, logo é importante filtrar os dados relevantes. Esta análise de relevância dos dados deve ser realizada em conjunto com os usuários que serão impactados diretamente pela migração. Porém, em alguns casos, por força de lei ou imposição do negócio, todos os dados devem ser migrados e estes cenários de migração são os que requerem mais planejamento e esforço. A migração de dados tipicamente envolve o planejamento do projeto, a definição do escopo, a extração, a transformação (para o formato adequado), a transferência e a verificação dos dados [YoK92]. É geralmente desenvolvida em duas etapas: a extração e a carga dos dados. A extração de dados é o processo de extrair dados de um sistema existente e armazená-lo em um arquivo. Se o volume dos dados for relativamente pequeno, estes podem ser extraídos para um arquivo que será referenciado diretamente pela aplicação destino. No entanto, se o volume dos dados for grande e os sistemas utilizam diferentes ambientes computacionais, estes devem ser armazenados em alguma mídia, e então, carregados na aplicação destino [YoK92]. A carga de dados é o processo de transferir o conteúdo do arquivo gerado na etapa de extração para a base de dados da aplicação destino. Se os domínios dos dois sistemas possuem uma interpretação comum entre valores e os relacionamentos entre os dados são bem definidos, então o processo de mapeamento é relativamente direto. Caso os domínios sejam diferentes ou os relacionamentos não estejam bem definidos, é necessário passar por um processo de transformação dos dados, que pode ocorrer na etapa de extração ou de carga [YoK92].. 1. Neste caso, nova aplicação entende-se como todo sistema computacional em sua versão inicial ou resultante da atualização de um sistema pré-existente.. 7.

(23) 2.3.1. Estratégias de Migração de Dados Migração de enormes volumes de dados não ocorrem rotineiramente na maioria das empresas. Geralmente, a área de TIC da empresa não possui vasta experiência neste tipo de operação. Para realizar um projeto de migração de dados, é necessário que uma estratégia de migração seja adotada no início do projeto, já que seu planejamento e as ações necessárias dependem dessa estratégia. Há dois tipos principais de estratégias de migração de dados: Big Bang e Trickle. 2.3.1.1. Big Bang As migrações que adotam a estratégia Big Bang são realizadas de uma só vez. Neste caso, o sistema original deve ficar fora do ar enquanto os dados são extraídos, transformados e carregados na aplicação destino [NaG92]. Segundo Datanomic Ltd. [Dat07], esta estratégia tem a vantagem da migração ser finalizada no menor tempo possível. Porém, ela apresenta riscos: algumas organizações não podem ter o seu sistema fora do ar por muito tempo, o que aumenta a grande carga de pressão sobre a execução da migração e a realização de seus testes. Datanomic Ltd. [Dat07] ainda afirma que as empresas que adotam esta estratégia deveriam realizar uma migração de testes antes da migração real, mas poucas o fazem, o que compromete a qualidade dos dados. Normalmente, quando esta estratégia é adotada, o processo de execução da migração ocorre durante um fim de semana ou feriado. 2.3.1.2. Trickle As migrações que adotam a estratégia Trickle são realizadas de forma incremental. Os dois sistemas executam em paralelo e os dados são migrados em fases. Segundo Datanomic Ltd. [Dat07], isto pode ser desenvolvido utilizando processos em tempo real para transferir os dados da base de origem para a base destino e para manter os dados da base destino atualizados. Adotar esta estratégia adiciona complexidade ao projeto e há duas possíveis maneiras de desenvolvê-lo: na primeira, os dois sistemas executam paralelamente e os usuários devem chavear entre as aplicações, dependendo de onde está a informação que precisam no momento. Na segunda, os usuários utilizam o sistema antigo até que a migração termine, porém quaisquer mudanças nos dados da aplicação fonte exigem que os novos registros sejam migrados, de modo que a base destino permaneça atualizada. O Quadro 2 apresenta uma comparação entre as estratégias Big Bang e Trickle.. 8.

(24) Quadro 2 - Quadro comparativo entre as estratégias Big Bang e Trickle. Características Necessidade de sincronismo Complexidade Sistema legado fora do ar Dados migram primeiro Porte da migração Interoperabilidade entre as aplicações Compatibilidade com as metodologias de migração de sistemas legados. Big Bang Não. Trickle Sim. Média Sim. Alta Não. Sim. Não. Pequeno Não. Médio / Grande Sim. Butterfly. Chicken Little. 2.3.2. Passos de uma migração de dados Migrações de dados são realizadas freqüentemente, porém nem todas obtêm êxito. Através de migrações de sucesso, boas práticas foram compiladas, de modo que é possível enumerar uma seqüência de passos que ajudam a aumentar a probabilidade de sucesso do projeto [Wu+97b]. Os passos necessários são destacados nas subseções 2.3.2.1 a 2.3.2.5. 2.3.2.1. Passo 1. Planejamento. O processo de planejamento envolve descrever em detalhes o escopo do projeto, determinar os requisitos da migração, identificar os ambientes atual e futuro, criar e documentar o plano de migração e definir um cronograma a ser seguido. Os requisitos e projeto incluem a arquitetura de migração, os requisitos de hardware e software, o procedimento de migração e os planos de teste e implantação [BrS93, GaB95, Wu+97b]. O plano de migração deve determinar se a migração será realizada em fases, incluindo quantas fases serão necessárias e que tipos de dados serão migrados em cada fase. Deve também determinar o responsável por cada tarefa e seus prazos, além de descrever o impacto da migração no negócio em termos de necessidade de treinamento de pessoal, custos envolvidos e o tempo de parada do sistema. Deve ainda estabelecer um plano de contingência, especificando como lidar com processos de negócio críticos em termos de tempo, como pagamentos, em caso de atraso no cronograma [BrS93]. Quanto maior a importância dos dados para as operações da empresa e maior a complexidade do ambiente, mais crítico é o planejamento da migração [GaB95]. O cronograma e o orçamento devem levar em consideração todo o material e tempo necessários para auditar os dados, desenvolver as especificações de mapeamento, escrever o código de migração, construir as regras de transformações e limpeza dos dados, carregar e testar a migração. O cronograma também deve incluir quando o dado estará pronto para análise e teste, quando o sistema de origem ficará fora do ar (dependendo da metodologia adotada) e quando o novo sistema estará pronto para os. 9.

(25) usuários [BrS93]. Um projeto de migração típico tem uma duração média de seis meses a dois anos com uma equipe de cinco desenvolvedores em tempo integral [Wu+97b]. 2.3.2.2. Passo 2 - Profiling e Auditorias Quando dados são migrados para um novo sistema, pode ficar aparente que eles contêm redundâncias e imprecisões. Enquanto estes dados são perfeitamente adequados para o funcionamento do sistema original, eles podem não ser adequados em termos de estrutura e conteúdo para a nova aplicação [Wu+97b]. Sem o entendimento suficiente de ambos os sistemas, a transferência de dados de um para o outro pode ampliar o impacto negativo de qualquer dado incorreto ou irrelevante [Wu+97b]. Para desenvolver um projeto de migração de dados eficaz, é importante entender por completo as fontes de dados antes de especificar o código de migração. Isto é mais bem alcançado através da realização de uma auditoria completa dos dados que fazem parte do escopo da migração, nos estágios iniciais do projeto. Através do uso de ferramentas de profiling e auditoria, é possível analisar o conteúdo dos dados e identificar quais valem a pena ser migrados, já que uma migração requer tempo, dinheiro e esforço [BrS93, Wu+97b]. O principal resultado alcançado com a análise dos dados é o refinamento do escopo e a definição do que será migrado automaticamente, anualmente e o que não será migrado [BrS93]. Segundo Datanomic Ltd. [Dat07], os benefícios trazidos por esta prática são: 1. Com uma visibilidade completa de todos os dados de origem, a equipe pode identificar potenciais problemas que permaneceriam escondidos até um estágio mais avançado do projeto; 2. As regras para planejamento, mapeamento, execução e teste da migração são baseadas na análise de todos os dados de origem em vez de uma pequena amostra; 3. As decisões podem ser realizadas baseadas em fatos em vez de suposições; e 4. Uma auditoria completa dos dados pode reduzir o custo de reparos no código na etapa de testes em até 80%. A seguir, será considerada uma estratégia de profiling e mapeamento [She99]. A Figura 1 mostra os passos para identificação e mapeamento de dados.. Figura 1. Passos para identificação e mapeamento de dados. Fonte: DM Review Magazine, Junho 1999. 10.

(26) Nessa estratégia são adotados seis passos: 1. Identificação de coluna Esta fase procura analisar os valores em cada coluna ou campo da fonte de dados, inferindo características como tipo do dado, tamanho, domínio, freqüência, distribuição, cardinalidade, nulidade e unicidade; 2. Identificação de dependência Esta fase procura identificar dependências entre colunas de diferentes fontes de dados. Geralmente, não é realizada manualmente; 3. Identificação de redundância Esta fase compara dados entre tabelas das mesmas fontes de dados ou diferentes, determinando que colunas contenham sobreposição ou conjuntos idênticos de valores. Ela procura padrões de repetição. Esta fase procura identificar atributos que contêm a mesma informação, mas com nomes diferentes (sinônimos) e atributos que têm o mesmo nome, mas informações diferentes (homônimos). Também ajuda a determinar que colunas sejam redundantes e podem ser eliminadas. Este processo não pode ser realizado manualmente; 4. Normalização Procede a normalização dos dados baseada no modelo relacional; 5. Alteração do Modelo Faz a adequação do modelo frente a novas necessidades de informação detectadas; e 6. Mapeamento dos atributos Define regras de transformação entre atributos fonte e atributos alvo. 2.3.2.3. Passo 3 - Construção e Design Nesta etapa são desenvolvidas as especificações de mapeamento. Projetos de migração são mais eficientes quando segmentados, pois os dados podem ser auditados, mapeados, testados e transferidos em fases, facilitando o seguimento do cronograma, orçamento e possibilitando a realização de revisões de progresso [Wu+97b]. Segundo Datanomic Ltd. [Dat07], uma vez que as especificações de mapeamento forem convertidas em código de migração, elas devem ser verificadas individualmente, a fim de identificar possíveis erros. 2.3.2.4. Passo 4. Execução. Neste passo, os dados são extraídos da fonte, transformados e carregados na aplicação destino utilizando regras de migração carregadas em uma ferramenta de migração escolhida durante a etapa de planejamento [GaB95, Wu+97b]. 2.3.2.5. Passo 5 - Testes e Validação dos Dados Apesar de os dados terem sido validados ao longo do processo de migração, testes unitários, de sistema e de carga devem ser feitos para garantir que todos os dados. 11.

(27) foram migrados e que o novo sistema se comporta como esperado [BrS93]. Caso os passos dois e três não tenham sido realizados de maneira eficaz, a chance da ocorrência de erros aumenta, acarretando em repetição de trabalho, o que leva a um aumento no custo do projeto e um possível atraso no cronograma [Wu+97b].. 2.3.3. Desafios de uma migração de dados De acordo com IBM [IBM07], Manek [Man03] e Youn [YoK92], os principais desafios impostos por um projeto de migração de dados são: A necessidade de minimização do tempo em que o sistema ficará fora do ar, pois normalmente a organização congela a entrada de dados enquanto realiza a migração dos dados; A necessidade de aquisição e instalação de software de migração de dados em servidores; A ocorrência de inconsistência de valores. Isto acontece quando múltiplos sistemas de origem possuem o mesmo conceito (entidade), mas as representações (valores) variam (e.g. em um sistema o campo que armazena números de telefone utiliza o formato XXXXXXXX, já em outro sistema, o mesmo campo utiliza o formato (XX) XXXX-XXXX); A necessidade de preservação da integridade referencial entre as entidades e relacionamentos da aplicação destino durante o processo de carga; A sincronização dos dados. Apesar de estes serem migrados do sistema original para o sistema destino, o sistema original pode continuar em operação. Para preservar a integridade dos dados, quando estes forem adicionados e/ou modificados no sistema original, também devem ser adicionados e/ou alterados no sistema destino; Necessidade de escrita das especificações e códigos de mapeamento orientada a conteúdo, em vez de orientada a metadados. Para o propósito de migração de dados, a informação que descreve a origem (e.g. o nome da base de dados, o nome da tabela, o nome da coluna) e as características de cada coluna (e.g. o tipo, o tamanho, a escala, a precisão) é considerada metadados. Conteúdo é o que está contido em cada registro da coluna. Uma migração de dados orientada a metadados assume que o conteúdo reflete a sua descrição, o que nem sempre acontece. Somente a realização de profiling e auditorias pode confirmar de fato o conteúdo do registro; Possibilidade de perda e corrupção de dados durante o processo; Alocação insuficiente de tempo para a realização de testes; e Cronograma imprevisível. Mesmo com um planejamento meticuloso, situações inesperadas podem surgir durante a migração, ocasionando problemas que impactam no cronograma.. 12.

(28) 2.3.4. Fatores de Sucesso de uma migração de dados Apesar dos desafios presentes em um projeto de migração de dados, existem algumas boas práticas que diminuem a probabilidade de falha do projeto. Segundo Datanomic Ltd. [Dat07] e Manek [Man03], estas boas práticas são as que se seguem: A migração de dados deve ser vista como um projeto completo. Portanto, faz-se necessário alocar recursos, definir claramente o escopo do projeto, definir um plano de projeto com um cronograma que leva em consideração a possibilidade de ocorrência de problemas inesperados e angariar fundos necessários para a execução do projeto; Levar em consideração o tempo necessário para testar o resultado da migração e resolver eventuais problemas ao definir o cronograma do projeto; Utilizar ferramentas de profiling e auditoria para analisar completamente os dados, refinar o escopo do projeto e escrever as especificações de mapeamento com mais segurança. Entender que informação é importante e como deve ser usada é crítico para o sucesso da empreitada; Minimizar a quantidade de dados a serem migrados, quando possível; Testar o resultado da migração o quanto antes; e Enquanto que muitas tarefas podem ser automatizadas, outras devem ser realizadas manualmente. Realizar estas tarefas com atenção ajuda a manter a consistência dos dados. Segundo Mohanty [Moh04], o maior desafio de um projeto de migração de dados é fazer com que o sistema alvo entenda o que o sistema fonte quer dizer. Abaixo estão algumas boas práticas e problemas que devem ser evitados em um bom projeto de migração de dados: Mapeamento consistente Todos os campos de dados que serão migrados do sistema fonte para o sistema alvo devem ser definidos e examinados para assegurar consistência com o tamanho dos campos, tipos dos dados, valores de domínio permitidos, regras de sistema, verificações de integridade e qualquer outro problema possível. Um mapa de dados detalhado é crítico para entender para onde a informação está indo; da mesma forma, se existem obstáculos conhecidos ou evitáveis no caminho para o sistema alvo. Um bom mapa de dados irá detalhar em profundidade a relação entre os campos do sistema fonte com o sistema alvo. Preferencialmente, deve incluir: Nomes significativos dos campos origem e destino; Tamanhos e tipos destes campos; e Qualquer lógica envolvida no mapeamento como tratamento de strings ou validações contra regras de negócio. Validação da extração É sabido que dados nos sistemas fonte geralmente contêm problemas ou escondem erros causados pelas mais variadas razões, desde falhas humanas até regras e validações mal testadas ou definidas em sistemas pouco 13.

(29) sofisticados. Regras de validação devem ser utilizadas como primeiro passo para tentar identificar e corrigir estes problemas, estendendo o processo em tantas iterações quantas forem necessárias. É comum que alguns tipos de erros não apareçam até que outros tipos sejam detectados e corrigidos. Mesmo que o sistema fonte tenha ignorado discrepâncias como, por exemplo, o mesmo cliente possuir endereços de cobrança diferentes armazenados em diferentes arquivos ou tabelas, o sistema alvo potencialmente deve ter regras de negócio que defina qual endereço será considerado como o que irá ser carregado, eliminando esta inconsistência. Validação e limpeza de dados são essenciais e componentes chave para um bom plano de migração de dados. Qualidade da transformação Dados extraídos do sistema fonte precisam ser transformados ou traduzidos num formato que o sistema alvo possa importar e entender. Estas transformações não serão definidas somente no mapeamento dos dados, mas serão executadas sob funções de lógica de negócio que serão essenciais para carregarem estruturas de dados mais complexas. Existem ferramentas de ETL (acrônimo em inglês para Extração, Transformação e Carga) no mercado que podem ajudar bastante neste estágio. Até agora foram discutidos aspectos técnicos da migração de dados. Entretanto, como acontece nos projetos de TIC, o como é tão importante como o quê, onde e quando. Quando se trata com os aspectos gerenciais dos projetos de migração de dados, as seguintes preocupações devem ser consideradas: Abordagem Big Bang ou Trickle Quando se decide migrar dados de um sistema para outro, faz mais sentido fazê-lo de uma só vez ou mover dados em fases controladas com múltiplas iterações? Naturalmente existirão prós e contras em ambas as opções. Considerar qual abordagem será a mais adequada para determinada organização requer avaliar uma variedade de fatores. Alguns exemplos destes fatores são: Qual a quantidade de dados que vai ser migrada? Quanto tempo será necessário, levando em consideração as condições normais de processamento em produção da organização? Quanto tempo a organização suporta parar os sistemas para a migração? A organização tem condições de simular um big bang antes da migração definitiva? E É possível estimar o ROI (acrônimo em inglês de Retorno do Investimento) de ambas as abordagens? As respostas destas questões devem ser encaminhadas antes de um simples objeto ser extraído ou uma simples transformação ser definida. Um projeto de migração de dados não pode prosseguir se estiver pobremente definido em seu escopo, agenda, estimativa de esforço, custos e recursos requeridos. Rollback Quando se carrega dados no sistema alvo, o que acontece se a migração de dados falhar? A equipe está preparada para utilizar alguma funcionalidade de transação de rollback existente ou tem-se capacidade de desenhar e construir uma, caso não exista? 14.

(30) Como serão administradas as expectativas dos clientes caso isto aconteça? Há um plano de mitigação destas questões construído? E Esta possibilidade, de retornar, foi discutida com os usuários? As respostas destas questões proporcionam uma camada adicional de segurança e contribuem muito em termos de concluir o projeto no prazo, sem alongar o orçamento e gerenciando as expectativas do usuário. Escalabilidade Naturalmente, quando alguém começa a falar de migração de dados, com dados críticos indo e vindo, e como isto pode incrementar o negócio da empresa, o assunto escalabilidade vem à tona. Como gerente, somente estando seguro de que se tem infra-estrutura para suportar a sobrecarga de processamento provocada pela migração e um eventual crescimento não previsto deste, é que se deve começar o projeto. Replicação A questão é a seguinte: o que acontece em caso de um desastre ou uma falha irrecuperável do sistema? Comumente esta preocupação aparecerá em um projeto de migração de dados. Tipicamente nasce da pressão colocada sobre o gerente de fazer uma migração correta e não colocar em risco 100% da produção. Migrar dados para um sistema espelho ao mesmo tempo em que se migra para o sistema alvo deve ser seriamente considerado para adicionar uma camada a mais de segurança e assegurar que um plano de recuperação de desastre existe. Ainda segundo Mohanty [Moh04], migração de dados é um importante aspecto do esforço da maioria dos desenvolvimentos de software, mesmo que esta importância seja freqüentemente subestimada ou inadvertidamente minimizada. Parece que, no extraordinário esforço de desenvolver software, realmente, a eventual medida de sucesso, de alguma forma, não depende de uma migração de dados precisa. A razão disto é bastante simples optar por um novo sistema é uma decisão de negócio tendo sua própria prioridade. Entretanto, migrar dados históricos para fazer o novo sistema funcionar parece não ser a prioridade principal. Ao contrário, colocar o novo sistema em produção para suportar os processos críticos da empresa é a prioridade principal. Uma falsa impressão do sucesso de um projeto de migração de dados é quando se busca um simples movimento de dados sem remendos, permanecendo, assim, à sombra da implantação do novo sistema.. 2.3.5. Arquitetura de migração de dados Para desenvolver uma arquitetura de migração de dados, a equipe de migração de dados deve levar em consideração os seguintes tópicos [Moh04]: Volume de dados a ser migrado; Poder de processamento dos sistemas fonte e alvo; e Complexidade das regras de mapeamento e das regras de negócio. Baseados nestas questões, duas estratégias de arquitetura de migração de dados são destacadas nas subseções 2.3.5.1 e 2.3.5.2:. 15.

(31) 2.3.5.1. Point-to-Point Nesta estratégia, os dados são extraídos do sistema fonte e carregados em uma área intermediária local no sistema alvo. Depois da transferência dos dados, estes são tratados e transformados localmente nesta área intermediária para depois serem carregados na base definitiva do sistema alvo. Características: Redução do tráfego de rede; e Aumento de processamento no sistema alvo. A Figura 2 mostra a arquitetura Point-to-Point.. Figura 2. Arquitetura de migração de dados Point-to-Point.. Fonte: DM Review Special Report, maio 2004. 16.