Migração de dados numa Seguradora

Universidade de Trás-os-Montes e Alto Douro

Migração de Dados numa Seguradora

Relatório de Mestrado em Engenharia Informática

João Manuel Grácio Sequeira

Sob orientação do Professor Doutor António Manuel Trigueiros da Silva Cunha

e do Eng. Fernando Pedro Pinto

Universidade de Trás-os-Montes e Alto Douro

Migração de Dados numa Seguradora

Relatório de Mestrado em Engenharia Informática

João Manuel Grácio Sequeira

Sob orientação do Professor Doutor António Manuel Trigueiros da Silva Cunha

e do Eng. Fernando Pedro Pinto

Composição do Júri:

Professor Doutor Luis Filipe Leite Barbosa

Professor Doutor Ricardo Filipe Gonçalves Martinho

Professor Doutor António Manuel Trigueiros da Silva Cunha

Relatório de estágio apresentado por João Manuel Grácio Sequeira à Universidade de Trás-os-Montes e Alto Douro para cumprimento dos requisitos necessários à obtenção do grau de Mestre em Engenharia Informática, sob a orientação do Professor Doutor António Manuel Trigueiros da Silva Cunha do Departamento de Engenharias da Escola de Ciências e Tecnologia da Universidade de Trás-os-Montes e Alto Douro e do Engenheiro Fernando Pedro Pinto representante da empresa Deloitte.

I

Agradecimentos

Para que a realização deste trabalho fosse possível, considero que a ajuda e o apoio de algumas pessoas, foi imprescindível, como tal, sinto que devo fazer alguns agradecimentos.

Em primeiro lugar, o meu agradecimento aos meus orientadores, Professor Doutor António Cunha e o Engenheiro Fernando Pinto, pela disponibilidade, pela orientação e por todos os conselhos e ensinamentos técnicos e teóricos que me concederam ao longo deste ano que em tudo contribuíram para a concretização deste trabalho.

Ao meu Manager, Francisco Silva, e aos meus colegas, Vitor Soares, Paulo Freitas, Pedro Lacão e Sónia Costa, pela partilha de ideias / experiências, pelas críticas construtivas, pelos esclarecimentos, pelos bons conselhos e por todo o apoio prestado.

A empresa Deloitte, por me concederem a oportunidade de desenvolver o presente trabalho e porque me deram a oportunidade profissional de trabalhar num grande cliente. O que me proporcionou um grande crescimento profissional pois pude estar em contacto direto com o cliente.

À minha família por todo o apoio prestado, ressalvando um agradecimento especial aos meus pais pelo esforço que fizeram para me fazer chegar as melhores oportunidades e por me terem ajudado a enfrentar todos os obstáculos no meu percurso

Por fim, e não menos importante, deixo um agradecimento especial a todos os meus amigos e colegas, por me terem apoiado ao longo da realização deste trabalho.

III

Resumo

Cada vez é mais frequente ocorrer migrações de dados entre sistemas, pois com o avançar da tecnologia surge a necessidade de implementar sistemas mais atualizados tecnologicamente e mais “amigáveis” para o utilizador, desse modo, surgiu a necessidade de migrar os dados entre eles.

Cada processo de migração de dados é composto pelos seus próprios passos de implementação e execução e consequentemente pelas suas próprias particularidades, dependências e especificidades que irão depender do âmbito da migração. Assim sendo, o presente relatório de estágio tem com objetivo demostrar as várias etapas de uma migração de dados entre dois sistemas de gestão de seguros uma companhia de seguros.

Durante o presente relatório são demonstradas as várias estratégias possíveis para proceder ao processo de migração, que foram apresentadas à companhia de seguros e também a abordagem efetuada pela equipa responsável pela migração.

O processo técnico utilizado para a abordagem de migração foi o processo ETL, este processo baseia se em três fases, nomeadamente, na extração (E), na transformação (T) e no carregamento (L) de dados no sistema de destino. Além disso irá também ser apresentado o plano de testes desenvolvido, que se encontram divididos em dois tipos de testes, nomeadamente os que ocorrem durante a implementação e os testes de estabilização que são realizados no fim de cada interação de migração. Como no presente relatório nos encontrávamos numa fase de planeamento foi necessário definir também o plano de implementação, execução e as timelines de cada passo que foi definido à priori e irá ser mostrado neste relatório.

Por fim irá ser apresentado os aspetos positivos e tudo que correu bem na primeira fase da migração, bem como os maiores desafios enfrentados. Também serão apresentadas oportunidades de melhoria que teriam facilitado o planeamento do processo de migração, bem como toda a sua implementação e execução.

Palavras-chave: Dados, Migração, Sistema de Seguros, ETL, Mapeamentos, Relatório de

V

Abstract

Nowadays companies have an increasing need to update their core systems in order to improve customer experience and improve system efficiency, however in order to update the core system it is required to migrate the data from the legacy system to the new system.

Each data migration process has of its own implementation and execution steps. However, these steps have specificities and dependencies that depend on the scope of migration and the business needs. The aim of this report is to analyze the various steps of a data migration, applicable in the scope of an insurance company.

During this report, several possible measures to execute the application process are demonstrated, which were used by the insurance company and also addressed by the application team.

The technical process used for the ETL process approach, this process is based on three phases, including extraction (E), transformation (T) and no data loading (L) on the target system. In addition, the developed test plan will be shown, which can be divided into two types of tests, those that occur during implementation and the stabilization tests that are performed at the end of each execution activity. As this project was in the planning phase there was the need to define the execution plan and schedule of each step that are presented in this report.

Lastly, the main positive points of the first phase of migration, as well as the biggest challenges faced are also present. Additionally, some improvement opportunities are presented that could have facilitated the planning and implementation of future migration processes.

VII

Índice Geral

2 - Migração de um core na indústria seguradora ... 5

2.1 - Âmbito de entidades de dados a serem migradas ... 5

2.2 - At Renewal vs Mid-Term ... 6

2.3 - Big Bang vs Iterativo... 7

2.4 - Coexistência ... 8

2.5 - Migração automática vs manual ... 8

2.6 - Modelo comum de dados (CDM)... 9

2.7 - Premissas e dependências... 10

3 - Migração de dados - ETL ... 13

3.1 - Arquitetura de Ponta a Ponta ... 13

3.2 - Arquitetura Componente de Extração ... 16

3.3 - Arquitetura Componente de Transformação ... 18

3.3.1 - Cenários de migração ... 19

3.3.2 - Transformação para o CDM ... 20

3.3.3 - Transformação para o modelo de dados do sistema de destino ... 21

3.4 - Arquitetura Componente de Carregamento ... 22

3.4.1 - Arquitetura de carregamento ... 22

3.4.2 Lógica de carregamento ... 23

3.5 - Outras componentes ... 24

3.5.1- Logging ... 24

VIII

3.5.4 Reversão e cancelamento ... 27

4 - Modelação de Dados e Mapeamentos ... 29

4.1 - Modelos de dados de origem, destino e CDM ... 29

5 - Validação de Dados e Testes ... 35

5.1 - Abordagem de qualidade de dados ... 35

5.2 - Abordagem de Reconciliação de Dados ... 36

5.3 - Abordagem Testes Manuais ... 37

5.4 - Abordagem Testes de ciclo de vida ... 37

6 - Plano de Implementação e Execução ... 39

6.1 – Plano de Implementação ... 39

6.2 – Plano de Execução ... 39

7 – Conclusão ... 43

IX

Índice de figuras

Figura 1 - Comunicação entre sistemas sem o CDM ... 10

Figura 2 - Comunicação entre sistemas com o CDM ... 10

Figura 3- Arquitetura de alto nível do processo de migração de dados ... 13

Figura 4 - Componentes dos módulos da migração de Dados ... 14

Figura 5 - Processo de Extração ... 17

Figura 6 – Cenários de migração e processo de transformação para o CDM ... 19

Figura 7 – Processo de transformação para o modelo de dados do sistema de destino ... 21

Figura 8 – Arquitetura de carregamento ... 22

Figura 9 – Lógica de carregamento ... 24

Figura 10 - Fluxo de tratamento de erros ... 27

Figura 11 - Mapeamento dos conceitos de contrato ... 30

Figura 12 - Mapeamento dos conceitos de cliente e membro ... 31

Figura 13 – Mapeamento do conceito de mediadores ... 32

Figura 14 - Mapeamento dos conceitos de fornecedores de serviço ... 33

Figura 15 - Ciclo de execução da qualidade de dados ... 36

XI

Índice de tabelas

Tabela 1 - Descrição dos módulos de migração de dados ... 14 Tabela 2 - Suporte à figura 5 ... 17 Tabela 3 - Tipos de erros, Descrições e procedimentos de resolução ... 26

XIII

Acrónimos

Neste relatório de estágio são utilizadas algumas abreviaturas, desse modo são apresentadas as suas definições abaixo:

Acrónimo Definição

API Application Programming Interface

CDM Common data model

DQ Data quality

ETL Extaction, transformation and load

E2E End to End

SFTP Secured File transfer protocol

LZ Landing Zone

MD Modelo de dados

ODBC Open Database Connectivity

PII Personally Identifiable Information

1

1 - Introdução

A evolução da tecnologia dos sistemas informáticos, com o avançar dos tempos, trouxe novas soluções de interação com os utilizadores que, sendo mais amigáveis, permitem uma maior eficiência destes na execução das suas funções, e fazendo com que os sistemas antigos caíssem em desuso e seja necessário o desenvolvimento ou adquisição de novos sistemas por parte das empresas.

Perante este cenário é necessário fazer a migração dos dados dos sistemas antigos para os sistemas novos, de modo a estes conseguirem operar com todos os dados que estavam presente no sistema antigo, para operarem corretamente.

O processo de migração de dados engloba tudo o que envolve a migração, ou seja, é responsável pela pré, execução e pós migração. Além disso, segundo Ribeiro (2011 in Tavares, 2013) este processo pode ser composto por três fases distintas, nomeadamente a extração dos dados das bases de dados do sistema antigo, a limpeza e transformação dos dados, para o modelo de dados do sistema de destino e o carregamento dos dados transformados nas bases de dados do sistema de destino. A limpeza dos dados é opcional só é feita caso seja necessário.

Como, o presente relatório de estágio se desenvolveu no âmbito de uma companhia de seguros, a migração irá ser efetuada entre dois sistemas de gestão de seguros, o que consequentemente implica dependências e estratégias diferentes de outras migrações, pois cada migração tem que as suas próprias características. Segundo Neiva e Matos (2014) neste tipo de migrações entre sistemas de gestão de seguros existe uma dificuldade acrescida uma vez que estamos a lidar com dados que não podem sofrer qualquer tipo de alteração, pois pode influenciar o normal funcionamento da apólice e por a credibilidade da companhia de seguros em causa.

1.1- Motivação

O presente relatório de estágio foi desenvolvido no âmbito do Mestrado em Engenharia Informática, o qual teve a duração de nove meses. Este foi desenvolvido na empresa Deloitte, “a Deloitte é líder global na prestação de serviços de audit and assurance,

2

consulting, financial advisory, risk advisory, tax e serviços relacionados. A nossa rede de firmas membro compreende mais de 150 países e territórios e presta serviços a quatro em cada cinco entidades listadas na Fortune Global 500”.

A oportunidade de poder participar num projeto no âmbito de um Programa de Transformação de Negócio numa seguradora foi para mim uma forte motivação.

1.2 - Objetivos

O objetivo principal deste estágio é elaboração do plano de implementação da migração de dados entre os dois cores de seguros. Para isso, foram definidos pelo gestor de projeto, a realização dos seguintes entregáveis:

 Definição da estratégia de migração;

 Desenho funcional e técnico das regras de transformação e load dos vários domínios de informação a migrar;

 Especificação e definição de regras de análise de qualidade de dados;  Definição de testes automáticos de reconciliação de dados.

Para atingir objetivos definidos foram utilizadas as ferramentas SQL Server Integration Services (SSIS), IBM Information Analyzer, e Oracle. Foi executada uma ação de formação de introdução às tecnologias a utilizar, que decorreu durante o mês de setembro.

Os trabalhos deste estágio foram desenvolvidos durante a fase de planeamento do projeto. Deste modo, o presente relatório apresentada as várias hipóteses de migrações expostas ao cliente, a arquitetura técnica de como será realizada a migração, e ainda o plano de implementação e execução. Além disso, é aprofundado tudo o que foi realizado durante os nove meses de estágio.

1.3 - Organização

O presente relatório está dividido em cinco capítulos, nomeadamente, no primeiro capítulo apresenta-se uma breve explicação dos cenários e estratégias para a realização da migração, bem como da informação a migrar.

3

No segundo capítulo apresentamos a arquitetura técnica de migração bem como as tecnologias que foram utilizadas nesse processo.

No terceiro capítulo apresenta-se a modelação de dados necessária à migração dos dados entres os dois cores de seguros. De seguida, no quarto capítulo, são apresentados os processos de validação e testes de qualidade dos dados migrados.

Por fim, no quinto, é apresentado o plano de implementação e execução da migração de dados entre os dois cores de seguros.

5

2 - Migração de um core na indústria seguradora

Um processo de migração de dados é composto por vários passos dependendo do tipo de migração e do contexto onde está inserido.

Numa fase inicial é necessário definir a informação que irá ser migrada, para posteriormente se poder definir quais as possibilidades e as estratégias que melhor se adequam a esse cenário.

De seguida é preciso definir se será feita uma migração composta por várias interações ou uma migração em uma só interação.

Além disso é também necessário definir todas as dependências e todos os riscos que se poderão enfrentar.

Depois é necessário definir quais as tecnologias a usar e definir o desenho técnico do processo de migração.

Posteriormente é necessário proceder ao mapeamento dos modelos de dados dos sistemas e definir o plano de testes. Por fim é preciso definir o plano de implementação e execução.

2.1 - Âmbito de entidades de dados a serem migradas

 Cliente, é o tomador da apólice, é em que nome fica o contrato. Este serve apenas para agregar grupos.

 Grupo, um nível dentro de cliente onde os membros são associados. É também através do grupo que são definidas as datas de renovação destes mesmo contratos.  Subgrupo, é um nível dentro de grupo, de forma a organizar os membros por

cobertura.

 Contrato, é o contrato o entre o cliente e a seguradora, também é neste nível que se encontram as condições gerais e particulares do seguro contratado.

6

 Membro, é cada pessoa que é coberta pela apólice. São os membros da apólice. Membros podem formar famílias criando o conceito de principal e dependente, como por exemplo, o pai seria o principal e a esposa e os filhos os dependentes.  Mediador, são associados da seguradora, que tem como função angariar novos

clientes, são uma espécie de intermediários, pagos á comissão.

 Parceiro, é uma empresa parceira da seguradora principal, normalmente trabalhando num país sem operação base da empresa principal. Os parceiros podem vender contratos, gerir e transmitir sinistros nos seus países de operação.  Fornecedor de Serviço: São instituições medicas, onde o membro terá o seguro

ativo.

Toda a restante informação, como por exemplo a configuração de todos os produtos, irá ser configurada por outras equipas manualmente no sistema de destino. No caso dos sinistros irão ser tratados nos dois sistemas dependendo da vigência em que se encontram, pois pode existir a necessidade de alterar sinistros abertos em anuidades passadas.

2.2 - At Renewal vs Mid-Term

A análise At Renewal e a análise Mid-Term são focadas em apólices e tem um impacto significativo na estratégia geral de migração.

Na análise At Renewal a apólice e seus membros são migrados para o sistema de destino com uma data de início igual à data de renovação da apólice. O período de transição de apólices entre sistemas, começa quando o prémio é negociado fora do sistema e introduzido de volta manualmente e as alterações que ocorrem no processo de migração são replicadas nos dois sistemas, mas faturadas no sistema de origem.

Prós:

 Processo mais simples, mais limpo e com menor risco;

 Momento natural para comunicar a mudança de sistema (ou mesmo condições) com a seguradora, clientes e membros, aumentando a experiência do membro.

7

 Se uma apólice falhar na migração dentro desse slot de tempo, é provável que essa apólice seja migrada apenas um ano depois;

 As alterações ocorridas no período entre a migração técnica e a data real de início da apólice precisam de ser replicadas pela seguradora nos dois sistemas.

Na análise Mid-Term a apólice e os seus membros podem ser migrados em qualquer momento da anuidade. Parte restante do período para a apólice renovar será migrada e carregada no sistema de destino e é considerada ativa no novo sistema no mesmo dia. As taxas de prémio terão que ser migradas para o sistema de destino pois não é espectável para o cliente ter um novo valor de prémio a meio da anuidade. As novas mudanças à apólice são feitas no sistema de destino.

Prós:

 Método de migração mais rápido e flexível para o processo de migração.

Contras:

 As coberturas do produto, as taxas prémio, o método de cálculo, os métodos de ajuste de comissões e reclamações devem ser replicados no sistema de destino para manter a retro compatibilidade (dinâmica / utilizável) para não existir alteração de prémio e coberturas a meio da anuidade.

 Dívida e pagamentos pendentes e contas precisam de ser migrados, aumentando o esforço de análise e implementação da migração.

Por norma, uma iniciativa de Migração de Dados para Seguros vai sempre implementar o recurso At Renewal, enquanto o Mid-Term somente será implementado se necessário, com um risco e custo de entrega consideráveis. Com os dois recursos combinados, a flexibilidade máxima do calendário de migração pode ser alcançada.

2.3 - Big Bang vs Iterativo

No que concerne ao Big Bang, este é geralmente entendido como uma Migração de Dados de um momento só em que todos os dados necessários para dar suporte a qualquer

8

atividade diária de uma organização são movidos para um novo sistema de uma só vez sem a necessidade de usar o sistema legado novamente (Mendonça,2009).

Em uma migração de dados Interativa como o próprio nome indica com várias interações, ou seja, com vários momentos de migração divididos em subconjuntos de portfolio, este tipo de abordagem vai aumentar o período de tempo do processo de migração de dados (Mendonça, 2009).

Uma abordagem iterativa pode usar os métodos Mid Term e At Renewal, combinados ou individualmente.

No entanto, a abordagem de migração de dados necessita de ser avaliada em relação aos domínios de dados específicos, para caracterizá-la como Big Bang, Iterativa ou Big Bang Iterativa.

2.4 - Coexistência

Em uma abordagem que não se baseia em Big Bang a coexistência é um tema que tem de ser tido em consideração.

A coexistência surge da necessidade de manter e usar dois sistemas a funcionar em simultâneo (Catarino, 2011), contudo esta é uma consequência natural de qualquer estratégia de migração, que não se baseia na abordagem Big Bang. Além disso, para a companhia de seguros esta estratégia não é a mais adequada devido à complexidade da migração e à garantia total de compatibilidade retroativa do novo sistema com o antigo. No que concerne, à estratégia de migração de dados, é imprescindível identificar e mitigar os impactos da coexistência.

2.5 - Migração automática vs manual

Um processo automático são um conjunto de operações orquestradas que transformam e migram dados e são executadas sem intervenção manual. Os dados podem ser migrados em várias interações ou em uma única. No lado oposto, uma abordagem manual implica um processo manual e progressivo, e os dados são migrados campo a campo pelos ecrãs do sistema de destino.

9

A estratégia de migração deve definir o nível de automatismo que pode variar de totalmente automatizado a totalmente manual. Com base nos requisitos de TI e de negócio, diferentes estratégias podem ser aplicadas a conjuntos de portfólio ou domínios de dados distintos, resultando algumas vezes em um processo semi-automático. Os volumes de dados, a qualidade dos dados de origem, o conjunto de ferramentas disponíveis e / ou os custos de licença, a complexidade da transformação, o MVP (produto mínimo viável) necessário e o prazo para concluir a migração são os principais fatores que influenciam a decisão final.

2.6 - Modelo comum de dados (CDM)

Nas empresas atuais que tenham múltiplos sistemas cores ou múltiplos sistemas em concorrência, estas têm a necessidade de desenvolver um modelo de dados canónico, que permita desacoplar as interações entre os vários sistemas.

Desse modo, levou com que a companhia de seguros desenvolvesse um modelo de dados canónicos, ao qual designou de CDM (modelo comum de dados). Por sua vez, este foi implementado na camada de interação.

O CDM é um dicionário de dados, pois tem como função a tradução dos conceitos de negócio e faz essa tradução para os restantes sistemas. Para além disso, permite que os sistemas comuniquem entre si, o que faz com que não surja a necessidade de criar um relacionamento ponto-a-ponto específico para cada um dos sistemas, como é representado na figura 1 (Azevedo, Santoro & Baião, 2010).

Este modelo trás ainda vantagens caso a seguradora adquira um novo sistema, pois como o CDM é também responsável pela comunicação entre os sistemas, só surgirá a necessidade de mapear o novo sistema no CDM, uma vez que este fará com que os sistemas já existentes comuniquem com o novo sistema, tal como podemos verificar na figura 2. No entanto, se não existisse o CDM seria necessário criar novas interfaces de comunicação entre todos os sistemas, como podemos observar na figura 1. Esta situação também se verifica caso seja necessário alterar um sistema já existente (Azevedo, et al., 2010).

10

Figura 1 - Comunicação entre sistemas sem o CDM

Figura 2 - Comunicação entre sistemas com o CDM

2.7 - Premissas e dependências

11

 Todos os dados de referência, como por exemplo produto, devem ser configurados no sistema de destino antes da migração dos dados;

 Todos os conceitos de negócios do sistema de origem devem ser construídos no sistema de destino antes da migração dos dados;

 A estrutura do produto deve ser definida e configurada no sistema de destino antes da migração dos dados;

 As informações obrigatórias do sistema de destino podem não estar presentes no sistema origem e, portanto, precisam de ser recriadas por meio de regras de negócios ou retificadas no sistema de origem. Se as abordagens mencionadas não forem viáveis, uma solicitação de alteração no sistema de destino deve ser entregue para garantir os valores padrão de destino e permitir a conversão da entidade;  Campos não obrigatórios (campos que possam ser nulos) no sistema de destino,

mas que podem afetar o negócio da companhia de seguros são convertidos se os dados estiverem disponíveis no sistema legado. Se esses dados não estiverem disponíveis e não for possível recriá-los, esses campos serão preenchidos;

 Deve ser possível carregar todas as entidades migradas com rapidez suficiente para executar toda a execução da conversão durante o período definida pela companhia de seguros;

 Um utilizador de migração deve ser configurado no sistema de destino com nível de autoridade necessária, para que a execução do processo de migração não falhe devido à falta de liberação do perfil;

 Os utilizadores de migração, perfis e níveis de autoridade devem ser configurados no sistema de destino antes da migração dos dados;

13

3 - Migração de dados - ETL

3.1 - Arquitetura de Ponta a Ponta

O processo geral de migração de dados, entre o sistema de origem e o sistema de destino, foi implementado com base em um processo ETL configurável tal como definido, na figura abaixo.

Figura 3- Arquitetura de alto nível do processo de migração de dados

Este expressa-se através de módulos lógicos, em que cada um representa um conjunto específico de tarefas do processo geral de transformação de dados. Assim a figura 3, mostra a visão geral de alto nível do processo de migração de dados e a figura 4 mostra os componentes dos módulos de migração de dados.

14

Tabela 1 - Descrição dos módulos de migração de dados

Módulo Descrição

Extração do Sistema de origem

Extrair os dados reais do sistema de origem.

Mascarar dados Mascarar os dados altamente confidenciais ao passar os arquivos para todos ambientes.

Carregamento na

Staging Area

Carregar os dados na Stanging Area da migração de dados.

Controlo de Migração Processo responsável por selecionar as entidades necessárias para o processo de migração.

Regras de limpeza de dados

Aplicar regras para limpar dados (se necessário, considerando os resultados da análise do processo de qualidade de dados e criação de perfil de dados).

15

Módulo Descrição

Regras de filtragem Avaliar a compatibilidade com os requisitos de negócios, importar a informações de suporte produzida manualmente e confirmar a migração manual.

Transformação para CDM

Aplicar as regras de mapeamento para transformar os dados para o modelo do CDM.

Regras de limpeza de dados

Aplicar regras para limpar dados (se necessário, considerando os resultados da análise do processo de qualidade de dados, perfil de dados e regras de validação do sistema de destino).

Transformação para o modelo de dados do Sistema de destino

Aplicar as regras de mapeamento definidas pela empresa para transformar os dados no modelo de dados do sistema de destino.

Carregamento de dados para a landing

zone do sistema de

destino

Conexões diretas á base de dados a uma landing zone na solução Oracle Cloud será a abordagem preferencial ao transferir dados para o sistema de destino. No entanto, a transferência segura de ficheiros FTP pode ser usada nos casos em que conjuntos de dados de grande volume possam levar consideravelmente menos tempo do que através da conexão direta à base de dados.

Trigger e processo de

controlo do

carregamento

Foi usado um trigger para acionar e controlar o processo de carregamento.

Chamada dos serviços de carregamento do

Carregamento de dados usando a camada de integração das APIs do sistema de destino. As solicitações de API serão criadas usando dados da landing zone ou do SSIS

16

Módulo Descrição

sistema de destino no local. Essa abordagem pressupõe a entrega de APIs de carregamento em massa pelo sistema de destino.

A orquestração das solicitações é gerenciada pela camada lógica de carregamento da migração de dados.

Validar regras de reconciliação e reversão

Validar regras de reconciliação e entidades de reversão, se necessário.

Solicitar cancelamento no sistema de origem

Obter informação de sucesso da importação de dados do sistema de destino e solicitar o cancelamento da entidade no sistema de origem. Esta etapa é aplicável apenas a entidades com características de renovação, como apólices, ou a entidades que não possuem nenhuma dependência no sistema de origem após uma iteração de migração específica.

Confirmação do cancelamento no Sistema de origem

Obter confirmação de cancelamento da entidade.

Atualizar o modelo de estados de migração do cliente

Atualizar a flag no CDM com informação de que o cliente foi migrado para o sistema de destino.

3.2 - Arquitetura Componente de Extração

Segundo Ribeiro (2010) a primeira etapa do processo ETL, no que diz respeito à migração de dados define-se pela extração dos dados do sistema de origem para uma base de dados temporária do SQL Server. No nosso caso o sistema de origem é composto por cinco base

17

de dados diferentes . Desse modo, a figura a baixo demonstra os principais pontos do processo de extração.

Figura 5 - Processo de Extração

Tabela 2 - Suporte à figura 5

Processo Descrição

1 Extração de dados do sistema de origem.

2 Mascarar campos altamente sensíveis

3 Carregamento de dados na base de dados do SQL Server

4 Log Técnico

No processo de extração, os dados das bases de dados do sistema de origem são extraídos e carregados na base de dados intermedia (SA) do SQL Server, esta ação representa a primeira etapa do processo de migração de dados.

18

Como parte dos seus requisitos de informação, a companhia de seguros implementou um processo de extração dinâmica que executa as operações de extração do sistema de origem e procede ao seu carregamento numa base de dados do SQL Server. Devido à compatibilidade nos requisitos, esse processo é alavancado para definir a arquitetura de extração da migração de dados e reutilizado para trazer os dados do sistema de origem para os ambientes SQL e, portanto, isto é garantido pela companhia de seguros.

O processo usa uma conexão ODBC direta da fonte e nenhuma regra de manipulação de dados são aplicadas. Esse processo é controlado por um projeto SSIS que usa a base de dados SSIS_CONFIG como um mecanismo de suporte e configuração. Esse projeto do SSIS foi implementado pelo serviço de dados da companhia de seguros, que também forneceu uma equipa da equipe de Migração de Dados treinada para configurar e gerenciar a transferência para o SA.

Em ambientes que não sejam de produção as informações de identificação pessoal (PII) são mascaradas. Esta etapa inclui mover dados das principais bases de dados do sistema de origem, mascarar os campos de PII e entregar os dados ás bases de dados secundárias dentro do sistema de origem. As bases de dados secundárias são usadas como fontes para a extração.

O processo de carregamento dos dados do sistema de origem para a SA, está incluído no processo geral de extração desenvolvido pela equipa de serviços de dados da companhia de seguros e é usado no contexto do design da migração de dados.

O modelo de dados da SA é uma representação fiel do sistema de origem e os dados não estão sujeitos a nenhuma transformação antes do carregamento. A SA contém apenas informações relevantes para a migração e não é uma cópia abrangente do sistema de origem.

3.3 - Arquitetura Componente de Transformação

Depois do processo de extração, será necessário executar dois processos de transformação, sendo que uma destas transformações irá ser entre a base dados da SA e o CDM e a outra entre o CDM e o modelo de dados do sistema de destino. Face a isto, na figura 6

19

encontram-se representados os cenários de migração e as três principais etapas da transformação para o CDM.

Contudo, as etapas de transformação para o modelo de dados do CDM são apresentadas no subcapítulo 3.3.2.

Figura 6 – Cenários de migração e processo de transformação para o CDM

3.3.1 - Cenários de migração

Os cenários do processo de migração são considerados como os pontos de entrada para o processo de transformação. Assim, esta migração de dados é instanciada em dois cenários, nomeadamente a migração iterativa baseada na renovação de contrato dos clientes e a migração baseada em Big Bang, dependendo das entidades.

No caso da migração das apólices e de todos os dados relacionados com o contrato, serão migrados, segundo a metodologia at-renewal, ou seja, no mês da renovação do contrato entre o cliente e a seguradora. É esperado, caso não ocorra nenhum erro na migração dessas apólices, que sejam realizadas doze interações deste tipo, uma por cada mês do ano.

Em relação aos dados referentes às restantes entidades (membros, clientes, mediadores, fornecedores de serviço e parceiros) a migração será numa estratégia Big Bang e antecipadamente em relação à migração das apólices, uma vez que estes dados têm que estar presentes no sistema de destino aquando da migração das mesmas. Visto que é necessário que esses dados estejam presentes no sistema para que a apólice possa ficar ativa no novo sistema e funcione em conformidade, assim como estaria a funcionar no

20

sistema de origem. Durante esta fase os dados e entidades a serem migrados são selecionados tendo em conta o cenário que está sendo executado.

3.3.2 - Transformação para o CDM

A transformação para o CDM inicia-se com a aplicação de regras de limpeza de modo a solucionar possíveis problemas de dados identificados durante as atividades de qualidade e criação de perfil de dados (Ribeiro, 2010). Em seguida são aplicadas regras de filtragem para garantir que as entidades sigam os requisitos mínimos de negócios para serem migrados (Songini, 2010 in Ribeiro, 2010). Este componente implementa um conjunto de regras definidas pelos negócios. Algumas dessas regras podem filtrar:

 Negócio não suportado no sistema de destino, funcionalidades que não estão prontas para serem usadas no sistema de destino e só serão implementadas posteriormente;

 Entidades não prontas para migração;

 Entidades que o negócio decidiu excluir da migração de dados.

Por último, os dados extraídos do sistema de origem passam por várias Regras de Negócios e são transformados no formato do modelo de dados do CDM.

21

3.3.3 - Transformação para o modelo de dados do sistema de

destino

Figura 7 – Processo de transformação para o modelo de dados do sistema de destino

Nesse processo, regras de limpeza adicionais podem ser necessárias uma vez que estas têm como principal objetivo solucionar problemas específicos de dados relacionados com as diferenças do modelo de dados do CDM e do modelo de dados do sistema de destino (Ribeiro, 2010). Desse modo, um dos exemplos de problemas a serem resolvidos, nesta etapa, são a falta de dados para campos que sejam obrigatórios preencher no sistema de destino.

Por outro lado, os dados extraídos do CDM são passados através de várias regras de mapeamento, que serão definidas à posteriori, de modo a ficarem no formato final do modelo de dados do sistema de destino. Contudo as regras de mapeamento campo a campo são especificadas pela equipe de design de dados da companhia de seguros enquanto os mapeamentos de conceitos funcionais são feitos pela equipa de migração e serão apresentadas no capitulo 4.

22

3.4 - Arquitetura Componente de Carregamento

3.4.1 - Arquitetura de carregamento

No que diz respeito ao processo de carregamento dos dados, este foi implementado usando a camada de serviços da API do sistema de destino. Por sua vez, esta tem a capacidade de expor serviços REST com um payload JSON e a responsabilidade de todas as validações e regras de negócios do sistema de destino. Neste seguimento, a imagem seguinte apresenta vários cenários possíveis da arquitetura do processo de carregamento.

Figura 8 – Arquitetura de carregamento

Os dados foram transformados na infraestrutura dos servidores locais usando uma base de dados do SQL Server. Além disso, o processo de carregamento foi iniciado após a execução das principais regras de transformação de dados. Por conseguinte esta etapa foi implementada em uma infraestrutura Oracle Cloud usando uma base de dados Oracle e aplicações de integração Oracle. Essas aplicações de integração foram necessárias para

23

criar uma camada lógica e para ser responsável por todas as solicitações aos web services expostos do sistema de destino.

No que concerne ao nível da Oracle Cloud, nesta foi implementada um esquema chamado Landing Zone, onde os dados transformados foram carregados. Assim, os dados de migração foram transferidos para a clould usando dois cenários, nomeadamente:

 O carregamento de dados no esquema da Landing Zone usando uma conexão direta à base de dados, cenário demonstrado na figura 6 representado com a legenda “cenário 1A”. No entanto, é de realçar que esta foi a abordagem preferencial para transferir as informações.

 Extrair dados para ficheiros usando pacotes SSIS e transferir esses mesmos ficheiros para a Cloud através do SFTP, cenário demonstrado na figura 6 representado com a legenda “cenário 1B”

O cenário escolhido pela companhia de seguros foi o cenário 1A.

3.4.2 Lógica de carregamento

Conforme descrito anteriormente, todos os dados foram preparados e transformados em várias etapas para ter a estrutura e cumprir todas as regras de dados e regras de negócios necessárias para as chamadas da API.

Depois de se realizar o processo de transformação e transferência de dados no esquema da Landing Zone, a camada lógica de carregamento encontra-se pronta e a aguardar um trigger externo para iniciar a construção das solicitações à APIs.

A camada lógica de carregamento de migração de dados é responsável por recuperar dados e construir o payload JSON na solicitação REST desejada. Desse modo, essa solicitação será acionada nos web services correspondente e as informações serão carregadas no sistema de destino.

A montagem da solicitação é iniciada somente após um trigger ter sido recebido pelo processo local.

24

Figura 9 – Lógica de carregamento

No que concerne ao processo de carregamento, a imagem representa duas abordagens diferentes nomeadamente:

 Solicitações REST com payload JSON para a camada da API do sistema de destino, representado na imagem acima com a legenda “2A”;

 Envio direto de dados transformados no modelo de dados do sistema de destino representado na imagem acima com a legenda “2B”.

O cenário escolhido pela companhia de seguros foi o cenário 2A.

No caso de erros de carregamento, todas as mensagens de erro serão carregadas no log de erros. Este log estará disponível para consultar e identificar o estado atual da migração.

3.5 - Outras componentes

3.5.1- Logging

O processo de migração concebe dos tipos de logs que por sua vez alimentam dois esquemas de log, ou seja, o esquema de logs técnicos que contém toda a informação dos logs inseridos no processo ETL até os dados de carregamento na landing zone da infraestrutura da cloud e o esquema logs da landing zone contém as informações de log do carregamento de dados no sistema de destino usando as chamadas à API.

Além disso os erros de validação do sistema de destino são lançados apenas no último estágio do processo de migração, nas chamadas às APIs, estes são armazenados com

25

detalhe suficiente, para ser possível a sua a correção que muitas vezes pode ser aplicada a uma etapa anterior do processo, para evitar possível propagação de erros.

3.5.1.1 Logs Técnicos

O esquema de logs técnicos é preenchidos após o processamento de cada tarefa ou do processo de migração, independentemente do resultado, seja ele de sucesso ou de falha. Desse modo, este é composto principalmente por dois tipos de tabelas de log e de Erro.

Por conseguinte, existe uma tabela de erros para cada tabela de entidade SA que armazena a identificação da coluna, assim a linha de cada erro processa um link para a tabela log, que por sua vez os detalhes que são armazenados no contexto de cada execução do processo. Nesse sentido, para ambas as tabelas, existe um processo de limpeza de dados que pode ser usado para limpar dados antigos e não utilizados, no entanto, essas informações permanecem na ferramenta de relatório para o acesso e análise de históricos.

3.5.1.2 Logs da landing zone

No que concerne às tabelas de log do sistema de destino, estas foram preenchidas após o processamento de cada registo das tabelas da landing zone do sistema de destino, independentemente do resultado seja ele de sucesso ou de falha. Além disso, essas tabelas serão usadas no processo de reconciliação e nos relatórios de estado da migração. Nesta situação foi necessário criar um novo registo de log para cada entidade enviada em uma solicitação REST para a camada da API, independentemente de ser uma operação única ou em massa.

3.5.2- Tratamento de erros

Aquando do processo de migração, podem ser gerados alguns erros de diferentes tipos, estando eles tipificados na tabela abaixo, juntamente com o procedimento de investigação e solução sugerido.

26

Tabela 3 - Tipos de erros, Descrições e procedimentos de resolução

ID Tipos de erros Conteúdo Procedimento de

resolução

1 Erros genéricos Gerados pelas validações genéricas.

Verificar se a regra de transformação foi aplicada corretamente.

2 Erros de negócio Erros que infringem as regras de negocio. Verificar se os dados seguem as regras de negocio. 3 Chaves primárias e chaves estrangeiras Chaves duplicadas, chaves não identificadas ou chaves estrangeiras não encontradas.

Verificar se a tabela com a chave estrangeira existe ou se existem chaves duplicadas. 4 Erros do sistema de destino Erros apresentados no documento de especificação da API.

Depende do tipo de erro

5 Erros de

reconciliação

Ids externos de entidade criadas no processo de migração não coincidem com os ids do processo de migração

Os Ids criados são validados com base na lista de IDs existentes.

O fluxo de trabalho seguinte expões uma visão de alto nível da metodologia de tratamentos de erros que foi aplicada nesta situação.

27

Figura 10 - Fluxo de tratamento de erros

Quando ocorre um erro, o processo inicia-se com a classificação de erro e posteriormente apresenta-se a classificação descrita na tabela 3. Para além disso, consoante for a classificação apresentada, é aplicada a ação de resolução correspondente. Seguidamente, o processo é executado novamente para carregar os dados e salvar o resultado obtido dessa iteração nas tabelas de logs correspondentes. Se o erro for resolvido com as ações de resolução presentes na tabela 3, o processo de tratamento de erros será encerrado. Caso, o erro persista, o procedimento iniciará um ciclo de iteração até que uma ação personalizada corrija o erro ou seja ignorada.

3.5.4 Reversão e cancelamento

Em caso de falha ou corrupção de dados, o sistema de destino fornece um sistema de reversão, para que o sistema de destino possa excluir todas as informações migradas.

3.5.4.1 Validar regras de reconciliação e reversão

Neste ponto, foram criados relatórios com regras de reconciliação para verificar a consistência entre os dados do sistema de origem e os dados transformados no formato final do sistema de destino. Nesse sentido, as regras de reconciliação foram implementadas como consultas SQL de controle na SA e na base de dados do sistema de destino e os resultados foram assim comparados e relatados. Se durante este processo

28

fosse encontrada alguma inconsistência, teria sido necessário reverter todos os dados migrados.

3.5.4.2 Solicitar cancelamento no sistema de origem

Posteriormente às entidades terem sido carregadas com sucesso no sistema de destino e as regras de reconciliação validadas, deve ser enviada uma solicitação para cancelar essas entidades no sistema de origem.

Contudo esta etapa é aplicável apenas a entidades com características de renovação, como apólices, ou a entidades que não possuem nenhuma dependência no sistema de origem após a iteração de migração específica. Também não serão canceladas entidades que tenham mais que uma apólice a renovar em períodos do ano diferente, pois anular esse cliente iria invalidar as apólices que estariam em funcionamento no sistema de origem e que só estão no âmbito de migração em um período diferente.

3.5.4.3 Confirmar o cancelamento no sistema de origem

Depois de ser enviada a lista de entidades para o sistema de origem para se proceder ao cancelamento, o sistema aguarda uma resposta para aplicar uma marca de sucesso nos dados selecionados. Desse modo, essa resposta é gerada automaticamente pelo processo do sistema de origem. No entanto, se ocorrer um erro, o processo manual de cancelamento necessitará ser executado.

3.5.4.4 Atualizar modelo de estado da migração do cliente

Sendo uma abordagem orientada ao cliente, o que significa que é esperado que a principal unidade de migração seja um cliente. É importante manter as informações dos clientes migrados no CDM da empresa de seguros. Portanto, o último processo do ETL é atualizar uma flag no CDM para ajudar a acompanhar os clientes migrados.

29

4 - Modelação de Dados e Mapeamentos

Para ser possível fazer a migração entres os dois sistemas foi necessário fazer um mapeamento de conceitos dos dois sistemas e do CDM, pois cada sistema tem o seu próprio modelo de dados e os seus conceitos. No entanto, o modelo comum de dados que foi criado pela companhia de seguros apresenta-se como bastante semelhante ao modelo de dados do sistema de origem (Neto, Neto, Júnior & Oliveira, 2013).

Muitas das vezes estes mapeamentos podem ser diretos como por vezes pode ter que se agrupar vários conceitos em um para ser possível realizar esse mapeamento entre os vários conceitos dos sistemas, ou até mesmo não utilizar conceitos do sistema de destino pois a companhia de seguros não os usa no sistema de origem e não fará sentido utilizar no sistema de destino e vice-versa (Neto et al., 2013).

No que concerne aos mapeamentos, estes foram realizados para conceitos que não iram ser migrados, visto que foram carregados à priori no sistema de destino. No entanto, mesmo para os conceitos de dados que não irão ser migrados, como por exemplo: tudo aquilo que diga respeito ao produto, uma vez que são configurados no sistema de destino. Foi necessário realizar esses mapeamentos pois muitos dos dados que iram ser migrados tiveram que ser associados a esses dados e foi necessário saber a que conceitos irão ser associados no sistema de destino.

O CDM encontra se sempre a meio dos mapeamentos dos dois sistemas pois como foi referido anteriormente os dados inicialmente foram transformados do modelo de dados do sistema de origem para o CDM e só numa segunda fase é que transformação se realizou do modelo de dados do sistema de referência para o sistema de destino.

4.1 - Modelos de dados de origem, destino e CDM

Mapeamentos de contrato:

Na figura abaixo pode se ver o mapeamento entre os vários sistemas e também entre o CDM, referente aos conceitos de contrato.

30

Figura 11 - Mapeamento dos conceitos de contrato

Mapeamento de Clientes e Membros:

Na figura abaixo pode se ver o mapeamento entre os vários sistemas e também entre o CDM, referente aos conceitos de cliente e membro.

31

Figura 12 - Mapeamento dos conceitos de cliente e membro

Mapeamento de Mediadores:

Na figura abaixo pode se ver o mapeamento entre os vários sistemas e também entre o CDM, referente aos conceitos de mediadores.

32

Figura 13 – Mapeamento do conceito de mediadores

Mapeamento de fornecedores de serviços:

Na figura abaixo pode se ver o mapeamento entre os vários sistemas e também entre o CDM, referente aos conceitos de fornecedores de serviços.

33

35

5 - Validação de Dados e Testes

A migração de dados pode ter vários tipos de testes, conforme a fase em que os mesmos são executados e o tipo de migração. Daí entende-se que a validação de dados são testes puros de migração de dados, que incluem validação manual, qualidade dos dados e atividades de reconciliação, enquanto em ambientes que não sejam de produção, os testes são um subconjunto dos mesmos testes e pela mesma razão são executados para atividades de configuração da aplicação, tendo em conta os dados migrados.

Os testes de validação de dados podem ser divididos em duas fases sendo que a primeira é executada durante a fase de integração contínua e execução iterativa e a segunda fase é executada paralelamente às fases finais de teste de estabilização, tendo como foco volumes completos de dados de origem. Além disso, tem de ser realizadas validações de performance para a migração, estas são focadas na confirmação dos tempos de execução em relação aos tempos esperados do plano de execução.

5.1 - Abordagem de qualidade de dados

O objetivo da verificação da qualidade de dados é identificar quias os dados do sistema de origem que estão em foco para ser migrados, que não atendem aos padrões de qualidade de dados definidos pelas seguintes referências:

 A definição do formato de dados do modelo de dados de destino, completude de dados ou integridade / relacionamento de dados;

 Formatos de dados predefinidos pela companhia de seguros ou condições que devem ser respeitadas de acordo com o CDM.

Design de qualidade de dados

 O teste de qualidade de dados é aplicado apenas em campos de dados relevantes no âmbito de migração;

 As regras de qualidade de dados são definidas ou configuradas conforme as regras de mapeamento.

36

Depois de definidas as regras de verificação, as atividades de qualidade de dados seguirão uma abordagem iterativa caracterizada pelas etapas listadas:

 Execução - As atividades de verificação da qualidade dos dados são executadas para identificar os problemas de dados;

 Feedback - Os problemas identificados são apresentados ao negócio, a fim de identificar os riscos e medidas associados para lidar com eles;

 Correção - Dependendo dos problemas identificados, existem três abordagens diferentes:

o O risco transacional / operacional no qual o problema pode resultar é aceite pelo negocio(cliente) e nenhuma correção é aplicada

o O negócio corrige o problema manualmente

o O problema é corrigido automaticamente no processo ETL pela equipa de migração de dados ou no sistema de origem de dados pela companhia de seguros

5.2 - Abordagem de Reconciliação de Dados

Os testes de reconciliação de dados têm como principal objetivo comparar os dados de destino com os dados do sistema de origem, a fim de garantir que o processo de migração

Execução

Feedback Correção

Figura 15 - Ciclo de execução da qualidade de dados

37

de dados tenha ocorrido corretamente. Estes testes baseiam-se na contagem de registos para observar se o número esperado de registos foi migrado e também da validação campo a campo, se exigido pela empresa (Murari & Cunha, 2014).

Este tem como principal objetivo evitar problemas como:

 Registos ausentes;

 Valores ausentes ou valores incorretos;  Registos duplicados;

 Relações quebradas entre tabelas

5.3 - Abordagem Testes Manuais

No que diz respeito aos testes de validação manual, estes serão focados na verificação do fluxo de informação migrado, do sistema principal de origem, para o sistema de destino. Além disso, o processo define-se da seguinte maneira:

 Os especialistas de negócio serão solicitados para a identificar os critérios de teste, a fim de extrair todos os campos do sistema de origem para posteriormente serem validados, tendo em conta o novo sistema.

 Após a identificação dos critérios de teste, os especialistas de negócio compararão as informações nos dois sistemas através da comparação de ecrãs, levando em consideração as regras de mapeamento definidas no design funcional.

5.4 - Abordagem Testes de ciclo de vida

Considera-se que o teste de aceitação de utilizadores é a última fase do processo de teste de software. Desse modo, durante os testes de aceitação de utilizadores, os utilizadores comerciais da companhia de seguros testam o software para garantir que o mesmo atende a todos os requisitos dos cenários do mundo real. Assim, considerando o âmbito da migração de dados, esses testes devem incluir atividades de gerenciamento de apólices nas políticas de migração de modo a avaliar o comportamento do sistema de destino com o

38

portfólio migrado (por exemplo, testes de eventos de adição, cancelamento ou renovação de membros).

39

6 - Plano de Implementação e Execução

6.1 – Plano de Implementação

Plano inicial onde é definida toda a estratégia de migração, todos os requisitos funcionais e técnicos, todas as premissas e dependências do processo de migração, esta fase a composta por os seguintes processos:

 Definição da estratégia de migração  Levantamento de regras de negócio

 Mapeamentos dos modelos de dados entres os vários sistemas  Implementação do processo de migração para:

o Clientes o Membros o Apólices o Mediadores

o Fornecedores de serviços  Testes durante a implementação

 Teste de estabilização, este processo é divido por definição, desenho e implementação de todos os testes de estabilização seguintes:

o Abordagem de qualidade de dados o Abordagem de reconciliação de dados o Abordagem testes manuais

o Abordagem testes de ciclo de vida

6.2 – Plano de Execução

Processo repetitivo de migração que envolve atividades técnicas de migração e de negócios que pode ter a duração de 4 a 6 meses por cada ciclo de execução, até à

40

efetivação de cada apólice do grupo de renovação no sistema de destino. O que vai causar simultaneidade de processos durante o ciclo de vida do processo de migração.

Este processo é dividido em três fases distintas:

Pré-migração:

O processo de pré-migração envolve a preparação dos dados para a migração do sistema de origem para o sistema de destino.

 180 dias: Reunir todos os dados do grupo de apólices do sistema de origem que iram ser migrados;

 180 dias: Validar a lista de regras de negocio apurada no plano de implementação;  180 a 120 dias: Cliente - consenso do produto a utilizar para comunicação do

grupo de apólices;

 90 dias: Pós-validação do produto a partir das regras de negocio.

Migração:

A migração envolve a movimentação real dos dados da origem para os sistemas de destino.

41

 60 dias: Executar o carregamento do grupo de apólices no sistema de destino;  60 a 35 dias: Executar a validação de grupos no sistema de destino;

 30 dias: Avaliar as consequências da migração;

 0 dias: Efetivação de apólices e membros no sistema de destino;  0 dias: Cancelamento de membros no sistema de origem.

Pós-migração:

O processo de pós-migração envolve auditoria e validação de dados migrados para o sistema de destino.

 30 dias: Verificação da percentagem de sucesso da migração no sistema de destino;

 25 dias: Geração de cartões de identificação no sistema de destino;  28 dias: Queda de faturas no sistema de destino.

43

7 – Conclusão

Neste contexto de estágio importa começar por referir que a empresa, Deloitte, onde o mesmo se desenvolveu, “a Deloitte é líder global na prestação de serviços de audit and assurance, consulting, financial advisory, risk advisory, tax e serviços relacionados. A nossa rede de firmas membro compreende mais de 150 países e territórios e presta serviços a quatro em cada cinco entidades listadas na Fortune Global 500”. Assim sendo, o presente estágio foi inserido num contexto empresarial do qual só foi possível concluir a primeira etapa do projeto, sendo que as restantes se encontram ainda em desenvolvimento.

Apesar da primeira etapa dos projetos estar concluída com sucesso, consideramos que existem alguns aspetos e funcionalidades que poderíamos ter melhorado e implementado, no entanto o feedback da empresa e do cliente relativamente ao nosso desempenho foi bastante satisfatório, visto que foi tudo terminado dentro dos prazos estimados no planeamento da migração e tudo entregue como era esperado por parte do cliente. Na fase de criação do desenho técnico foram feitas ligeiras adaptações ao plano inicial de modo a cumprir os requisitos do sistema de destino, mas a equipa de migração trabalhou de modo a esses requisitos afetaram de maneira mínima, ou nada o planeamento de migração feito por parte do cliente. Isso levou a uma maior satisfação e reconhecimento pois o cliente estava ciente dos desafios enfrentados para a entrega do planeado.

A nível individual enquanto executor do projeto considero que esta experiencia foi muito boa, muito enriquecedora e bastante gratificante, uma vez que tive a oportunidade de integrar uma equipa que estava envolvida num projeto de grandes dimensões. O que consequentemente levou a que, a nível profissional, adquirisse e desenvolvesse inúmeras competências e capacidades tanto técnicas como funcionais que até então não detinha.

Na minha opinião o envolvimento das pessoas de negócios durante o desenvolvimento da estratégia de migração permitiu identificar lacunas funcionais do sistema destino, como por exemplo a definição de que a migração iria ser feita em várias iterações aquando da renovação da apólice. Assim permitiu uma menor complexidade e um menor risco no processo de migração, uma vez que houve certos dados, como por exemplo as taxas prémio e o método de cálculo que foram ajustados ao máximo por outras equipas para

44

serem o mais semelhante possível ao método de calculo do sistema de origem, visto que o sistema de destino tem o seu próprio método de calculo.

Essa situação permitiu ainda à seguradora simplificar a comunicação com os clientes finais que tiveram a oportunidade de manter a apólice depois da renovação, em condições semelhantes ou em condições ligeiramente diferentes. Além disso, permitiu ainda que as mesmas fossem canceladas caso os clientes não gostassem dos novos termos do contrato. O que por sua vez permitiu à empresa migrar, em alguns casos, clientes para condições mais vantajosas e deixar sair clientes menos rentáveis. Pois, tal como refere Ramalho, Ferreira e Castro (2012) “Um projeto de migração representa também uma oportunidade para se limpar e arrumar a casa” (p.4).

Na nossa opinião o maior desafio, durante este processo, foi o sistema destino ter apresentado algumas dificuldades na configuração de planos ou nas funcionalidades compatíveis com os planos do sistema de origem o que exigiu muita customização no sistema de destino, o que levou a uma maior complexidade das regras de mapeamento.

Como oportunidade de melhoria consideramos que teria sido vantajoso implementar uma fase piloto focada no carregamento dos dados para mitigar riscos relacionados com a possível inexistência de interfaces que carregam os dados a migrar, além disso esta fase piloto também iria facilitar a visualização por parte das pessoas de negocio de algumas regras de transformação numa fase muito inicial, o que iria ajuda-los a definir as regras de transformação restantes.

45

Referências Bibliográficas

Azevedo, L.G., Santoro, F. & Baião, F. (2010). XML-Schema e Modelo de Dados em SOA.

Disponível em:

http://www.seer.unirio.br/index.php/monografiasppgi/article/view/970/741

Catarino, R.M.G.P. (2011). Concepção de um repositório de Master Data de Entidades numa Seguradora. Dissertação de Mestrado, Instituto Superior de Economia e Gestão da Universidade Técnica de Lisboa.

Mendonça, M.H.R. (2009). Metodologia de Migração de Dados em um contexto de Migração de Sistemas Legados. Pós-Graduação, Universidade Federal de Pernambuco.

Murari, M.A. & Cunha, G.B. (2014). Desenvolvimento de um software para migração de um banco de dados relacional Firebird para o não relacional MongoDB. Disponível em: https://repositorio.ufsm.br/bitstream/handle/1/12904/TCCG_SIFW_2014_MURARI_ MAURO.pdf?sequence=1&isAllowed=y.

Neiva, D.F.S. & Matos, E.S. (2014). Uma Estratégia para a Substituição de Sistemas Legados. Disponível em: http://ecivaldo.com/arquivos/10.3-anais-de-eventos-completo/10.3.24.pdf

Neto, P.A.S., Neto, J. R., Júnior, F.C.R. & Oliveira, P.A. (2013). Requisitos para ferramentas de migração de dados. In Anais do IX Simpósio Brasileiro de Sistemas de Informação (pp. 887-898). SBC.

Ramalho, J. C., Ferreira, M., Faria, L. & Castro, R. (2012). Boas práticas na migração de repositórios: lições aprendidas com o CALM e o ARQBASE. In 11º Congresso Nacional de Bibliotecários, Arquivistas e Documentalistas:“Integração, Acesso e Valor Social “. Braga: Associação Portuguesa de Bibliotecários, Arquivistas e Documentalistas (APBAD).

Ribeiro, A.L. (2010). Processos de Implementação e Migração de Dados com utilização de ETL para um ERP Comercial. Universidade Luterana do Brasil (Ulbra), 1-20.

Tavares, E. J.O. (2013). O Processo ETL – O Caso da Unitel T+ Telecomunicações. Dissertação de Mestrado, Universidade Jean Piaget de Cabo Verde.