Plano Geral de Governança de Dados

Esse documento visa definir um planejamento com o foco de atuação para a total efetividade das melhorias necessárias, visando amplamente a reestruturação adequada no STI­UFF, a partir do formato existente da área de dados (Banco de Dados Oracle, MySQL) assim como seu cenário futuro (Oracle, mysql, NoSQL, Big Data, etc). A figura 1 representa o Modelo de Governança que está sendo aplicado à área de dados do STI.

Figura 1. Representação da Estrutura de Governança de Dados.

Cada uma das áreas envolvidas na Figura 1, representa de forma específica uma área de concentração e suas competências relacionadas. Governança de Dados é responsável por instituir e aplicar as políticas de trabalho definidas, assim como implementar estratégias adequadas, sobretudo quanto à visão institucional das informações e dados. Serviços é a área de atuação referente ao trabalho administrativo e operacional das informações e dados, principalmente quanto aos servicos e sistemas de apoio à instituição. Inovação é a área que visa concentrar esforços de forma contínua à pesquisa, objetivando à melhoria, desde que estas sejam consideradas necessárias em nível de governança e serviços.Visando definir cada um dos pontos principais demostrados na Figura 1, cada um destes serão descritos nos itens a seguir.

1. Governança de Dados

Segundo o DAMA­DMBOK Functional Framework, Governança de dados (GD) tem a definição: “The exercise of authority, control and shared decision­making (planning, monitoring and enforcement) over the management of data assets.”. A partir desta definição, pode­se compreender que GD possui em essência uma abordagem de planejamento, partindo de um contexto em alto nível até o controle estabelecido e necessário quanto à gestão de dados. Adaptando esse conceito ao nosso cenário de trabalho, tem­se uma representação conforme a Figura 1.

Figura 1. Modelo de Governança de Dados.

Política de Governança de Dados ­ Essa área terá como objetivos a definição, aprovação e comunicação das decisões quanto às estratégias, políticas, padrões, métricas, arquitetura e procedimentos no que tange aos dados da instituição.

Manutenibilidade ­ Todo o cenário de dados em uso, deve ser condicionado de forma cíclica a manter­se íntegro, fidedigno e funcional, quanto ao Plano Geral de Governança de Dados e às políticas de uso, gestão e acesso de dados.

Integração (MDM) ­ Atualmente existe um modelo de dados, pertencente à aplicação do IDUFF que além de ser o modelo de dados da aplicação, também possui a finalidade de unidade informacional dos dados da instituição, onde vários serviços obtém informações institucionais a partir deste, representando de forma rudimentar um tipo de gerenciamento de dados mestres (MDM). Sobretudo, conforme houverem avanços na implantação do Plano Geral de Governança de Dados, esse cenário secundário de unidade informacional que o modelo de dados

do IDUFF também possui, deverá ser consolidado, e até mesmo transcrito ao formato MDM, visando principalmente coerência com o padrão definido conforme o DAMA­DMBOK.

Estratégia e Utilização ­ Deverão ser implementadas estratégias que atendam às necessidades da instituição e que forneçam um cenário adequado de utilização em tudo que refere­se ao parque de dados da instituição. O Plano Geral de Governança de Dados visa inteiramente atender o cenário do parque de dados.

Gestão dos Bancos de Dados e Repositórios ­ Os dirétórios que possuem informações e dados importantes, como por exemplo, um repositório onde estejam armazenadas todas as dissertações de mestrado e teses de doutorado da instituição é um exemplo fiel de diretório que necessite de uma gestão de repositório. Já na perspectiva purista de banco de dados, a gestão dos bancos de dados deve­se principalmente manter um elo funcional e estrutural quanto ao modelo de dados, estratégia de backup/restore e até mesmo acesso.

Situação atual ­ Existem aplicações que obtém dados de bancos de dados MySQL e Oracle, distribuídos em ambientes Ubuntu e RedHat, com versões diversas.

Conforme uma unidade organizacional, a Governança de dados tem o nível de tomada de decisões, visando trazer pontos até então isolados no contexto de dados à tona de forma geral, para que quando necessário, aplicação e uso dos dados sejam revistos e até repenssados da melhor maneira, levando em consideração competências envolvidas e necessidades a serem atendidas.

2. Serviços

O quê o setor/área de dados deve prover? A resposta dessa pergunta traz consigo a atuação de maior visibilidade da área de Governança de Dados: os serviços. Tudo que é provido pela área de dados, buscando atender ao cliente e àrea de Desenvolvimento de Sistemas, são essencialmente da natureza de serviços. A figura 2 representa claramente os pontos centrais dos serviços fornecidos.

Figura 3. Modelo de Serviços.

Usuários (Conceito LDAP) Remoção Criação Grupos Desativação Perfil (cotas de utilização e manuseio).

Acesso Liberação Remoção

BD (Gestão de repositório) Instância Esquema

ETL (Extraction Transformation Load); Suporte ao desenvolvimento

Arquitetura Tuning Modelagem Capacitação Design

Gestão de Operação Carga/JOBs

As áreas descritas, representando os pontos centrais de serviço, trazem puramente uma nomenclatura específica, quanto à competência. Mais detalhes serão trazidos aqui conforme às áreas de atuação forem sendo definidas.

3. Inovação

A condição de melhoria contínua e a busca pela excelência constante ná área de dados da instituição é o que movimentará positivamente o nosso “universo moderno de dados”: a inovação. A figura abaixo mostra o estado atual quanto à modernização que está sendo idealizado atualmente.

Figura 4. Modelo de Inovação

In Memory: Armazenamento eficiente e em larga escala (Ex.: MapReduce); NoSQL; Mensageria (AMQP); Data Lake (Pentaho, Hadoop, Kafka); Estrutura híbrida de BD (Relacional, Distribuído, NoSQL); GraphBD (Maria, Cassandra); MDM (Master Data Management); Cenário OLDAP.

Nessa área de inovação, à medida com que forem sendo trabalhadas as novas tecnologias em demanda, a relação estrutural já definida no Plano Geral de Governança de Dados e amparada sob as Políticas de Governança de Dados devem se manter para

que, mesmo na busca de inovação, o que foi essencialmente discutido e definido mantenha­se coerente tanto ao que já existe em legado como para o novo.

4. Plano de Geral de Governança de Dados

No que tange os pontos focais descritos acima e seus respectivos items, o plano geral deve atender as áreas mencionadas conforme as etapas a seguir, de forma cronológica, iniciado em agosto/2014 e estimado até dezembro/2016, com pontos de entrega a cada etapa concluída, da seguinte forma:

1. Inventário a. Levantamento físico (Todos os BDs fisicamente) b. Levantamento lógico (Todos os BDs logicamente) c. Automação do inventário d. Definição de criticidade dos ambientes e. Instalação dos BDs* f. Relatório final de inventário

2. Backup e Restore a. Levantamento da situação atual b. Melhoria da Política de backup e restore c. Definir as informações de controle d. Definir relatório das informações de controle e. Iniciar migração dos bancos críticos* f. Efetuar a migração completa de todos os bancos

3. Monitoração e Acompanhamento a. Definição de monitoramento b. Aplicação de monitoramento

4. Padronização a. Definir padrão b. Migração dos bancos críticos (+críticos) c. Migração dos bancos não­críticos (­críticos)

5. Segurança a. Definir política de segurança (LDAP em uso) b. Migração dos usuários

6. Alta disponibilidade a. Estudo das licensas (SW + HW) b. Aquisição das licensas (SW + HW) c. Implantação de replicação (STI ­ HUAP)

Apêndice A: Gerenciamento de Dados Mestre (MDM) Esse apêndice apresenta de forma detalhada as fases de atuação do gerenciamento de dados mestres. Dados mestre são dados que possuem grande valor (dados mais importantes e/ou principais dados utilizados pela maioria “ou todos” serviços) para a instituição. Com isso, o gerenciamento desses dados deve ser feito de maneira adequada, principalmente para evitar inconsistência dos mesmos. Casos comuns de inconsistências em dados mestres, tem haver basicamente com a replicação desses dados, destinados a atender vários serviços ou aplicativos. Com isso, promove­se a existência de um número de representações de fontes de dados mais específica ao serviço ou aplicativo e menos à fonte origem, deixando assim tais dados inconsistentes, onde de fato, tais informações deveriam referenciar uma única fonte de dados. Como parte da estratégia de MDM, os três pilares do gerenciamento de dados precisam ser investigados quanto a origem, ao gerenciamento e ao consumo dos dados. Não é possível ter uma estratégia MDM robusta, em nível de empresa, se quaisquer um desses aspectos for ignorado. No intuito de promover um direcionamento no tratamento adequado desses dados, segue abaixo uma listagem obtida em http://msdn.microsoft.com/pt­br/library/bb190163.aspx:

1. Identificar as fontes de dados mestre. Esta etapa é, usualmente, um exercício bastante revelador. Algumas empresas descobrem que possuem dúzias de bancos de dados, com dados de clientes, cuja existência o departamento de TI desconhecia.

2. Identificar os produtores e os consumidores dos dados mestre. Quais

aplicativos produzem os dados mestre identificados na primeira etapa e ­ em geral mais difícil de determinar ­ quais aplicativos usam os dados mestre. Dependendo da abordagem usada na manutenção dos dados mestre, esta etapa talvez não seja necessária. Por exemplo, se todas as alterações forem detectadas e tratadas no nível do banco de dados, provavelmente não terá importância saber de onde vêm essas alterações.

3. Coletar e analisar os metadados sobre os dados mestre. Para todas as fontes

identificadas na primeira etapa, quais são as entidades e os atributos dos dados e o que significam? Incluem­se o nome do atributo, o tipo de dados, os valores aceitos, as restrições, os valores padrão, as dependências e o proprietário da

definição e da manutenção dos dados. O proprietário é o mais importante e, quase sempre, o mais difícil de determinar. Se houver um repositório carregado, com todos os metadados, esta etapa será de fácil execução. Se, entretanto, for preciso começar com base nas tabelas do banco de dados e no código­fonte, esta etapa poderá representar um esforço significativo.

4. Indicar os administradores dos dados. Deverão ser indivíduos com

conhecimento dos atuais dados­fonte e capazes de determinar como transformar a fonte no formato de dados mestre. Em geral, os administradores deverão ser indicados pelos proprietários de cada fonte de dados mestre, arquitetos responsáveis pelos sistemas MDM e representantes dos usuários dos dados mestre no negócio.

5. Implementar um programa de governança dos dados e um conselho para a

governança dos dados. Este grupo deve ter o conhecimento e a autoridade para tomar decisões sobre como os dados mestre devem ser mantidos, o que contêm, por quanto tempo serão mantidos e como as alterações serão autorizadas e auditadas. Centenas de decisões devem ser tomadas no decorrer de um projeto de dados mestre e, se não houver um organismo e um processo para a tomada de decisões, bem definidos, o projeto poderá falhar porque a política impede uma tomada de decisão efetiva.

6. Desenvolver o modelo de dados mestre. Decidir qual a aparência dos registros

mestre: quais atributos estão incluídos, de que porte e tipo são os dados, quais valores são aceitos, etc. Esta etapa deve incluir, também, o mapeamento entre o modelo de dados mestre e as atuais fontes de dados. Normalmente, esta é a etapa mais importante e a mais difícil do processo. Se você tentar contentar a todos, incluindo todos os atributos­fonte na entidade mestre, acabará, quase sempre, com dados mestre muito complexos e complicados para serem úteis. Por exemplo, se não conseguir decidir se o peso deve ser apresentado em libras ou quilos, uma alternativa poderia ser incluir ambos (WeightLb e WeightKg). Ainda que esta alternativa satisfaça a todos, você estará desperdiçando megabytes de armazenamento com números que podem ser calculados em microssegundos e,

também, correndo o risco de criar dados inconsistentes (WeightLb = 5 e WeightKg = 5). Embora este seja um exemplo bastante trivial, uma questão maior seria manter vários números de itens para o mesmo produto. Como em qualquer esforço de comissão, haverá brigas e negociações que resultarão em decisões de qualidade inferior. É importante definir, antecipadamente, o processo de decisão, as prioridades e o tomador de decisão final, para garantir a execução do processo sem sobressaltos.

7. Escolher um conjunto de ferramentas. Será preciso comprar ou construir

ferramentas para criar as listas mestre limpando, transformando e mesclando os dados­fonte. Além disso, será preciso uma infra­estrutura para usar e manter a lista mestre. Mais adiante, neste artigo, estas funções são abordadas em detalhes. Você poderá usar um único conjunto de ferramentas, de um mesmo fornecedor, para todas essas funções, ou talvez queira adotar uma abordagem de best­of­breed (a melhor ferramenta para cada função). Em geral, as técnicas para limpar e mesclar dados são diferentes, para diferentes tipos de dados; assim, não há muitas ferramentas que atendam a todo espectro dos dados mestre. As duas principais categorias são as ferramentas que integram os dados do cliente (CDI) para criação do mestre de clientes e as ferramentas de gerenciamento de informações de produto (PIM) para criação do mestre de produtos. Algumas ferramentas executarão as duas tarefas mas, em geral, são melhores em uma das tarefas, apenas. O conjunto de ferramentas deve ter, ainda, suporte para localização e reparo de problemas com a qualidade dos dados e também manutenção de versões e hierarquias. O controle de versões é um recurso crítico, pois entender o histórico de um registro de dados mestre é vital para a manutenção de sua qualidade e precisão no decorrer do tempo. Por exemplo, se uma ferramenta para mesclagem combinar dois registros de John Smith em Boston e se você decidir que realmente existem duas pessoas diferentes com esse nome, nessa cidade, você precisará saber como eram os registros antes de serem mesclados, para conseguir desfazer essa ação.

8. Projetar a infra­estrutura. Depois de os dados mestre estarem limpos e

consistentes, você precisará colocá­los à disposição de seus aplicativos e

providenciar processos para a sua administração e manutenção. Esta etapa é uma questão bastante grande e, por isso, dedico uma seção inteira ao assunto, mais adiante neste documento. Depois que esta infra­estrutura estiver implementada, você terá vários aplicativos que dependerão de sua disponibilidade; assim, confiabilidade e escalabilidade são considerações importantes a serem incluídas no seu projeto. Na maioria dos casos, você mesmo terá de implementar partes significativas da infra­estrutura, porque ela será projetada para adequar­se à infra­estrutura, às plataformas e aos aplicativos atuais.

9. Gerar e testar os dados mestre. É nesta etapa que você usará as ferramentas

desenvolvidas ou compradas para mesclar os dados­fonte na lista de dados mestre. Em geral, este é um processo iterativo que exige explorar regras e configurações para chegar na correspondência correta. Este processo também exige grande volume de inspeção manual para confirmar se os resultados estão corretos e se atendem aos requisitos estabelecidos para o projeto. Nenhuma ferramenta conseguirá a correspondência correta, todas as vezes; assim, será preciso ponderar as conseqüências entre correspondências falsas vs correspondências perdidas, para determinar como configurar essas ferramentas. Correspondências falsas podem levar à insatisfação do cliente, se as faturas estiverem imprecisas ou se a pessoa errada for presa. Se houver grande volume de correspondências perdidas os dados mestre terão menor utilidade, e você não obterá os benefícios esperados do investimento em MDM.

10.Modificar os sistemas de produção e de consumo. Dependendo de como a

sua implementação MDM estiver projetada, talvez seja preciso modificar os sistemas que produzem, mantêm ou consomem dados mestre para trabalhar com a nova fonte de dados mestre. Se os dados mestre são usados em um sistema independente dos sistemas­fonte ­ um data warehouse, por exemplo ­ os sistemas­fonte talvez não tenham de ser modificados. Entretanto, se os sistemas­fonte forem usar os dados mestre, mudanças serão provavelmente necessárias. Os sistemas­fonte terão de acessar novos dados mestre ou estes terão de estar sincronizados com os sistemas­fonte, para que estes últimos

tenham uma cópia dos dados mestre limpos para uso. Se não for possível alterar um ou mais sistemas­fonte, este talvez não consiga usar os dados mestre ou estes últimos terão de estar integrados ao banco de dados do sistema­fonte por meio de processos externos, como gatilhos e comandos SQL. Os sistemas­fonte que geram novos registros devem ser modificados para procurar conjuntos de registros mestre existentes, antes de criar novos registros ou de atualizar os registros mestre existentes. Este procedimento confirma que a qualidade dos dados gerados na fonte é boa e, assim, o MDM poderá funcionar de modo mais eficiente e o próprio aplicativo gerenciará a qualidade dos dados. O MDM deve ser aproveitado não apenas como um sistema de registros, mas também como um aplicativo que possibilita a manipulação de dados, de modo mais eficiente e limpo, em todos os aplicativos da empresa. Como parte da estratégia de MDM, os três pilares do gerenciamento de dados precisam ser investigados quanto a origem, ao gerenciamento e ao consumo dos dados. Não é possível ter uma estratégia MDM robusta, em nível de empresa, se qualquer um desses aspectos for ignorado.

11. Implementar os processos de manutenção. Como declaramos anteriormente,

qualquer implementação de MDM deve incorporar ferramentas, processos e pessoas para manter a qualidade dos dados. Todos os dados devem ter um administrador, que será responsável por garantir a qualidade dos dados mestre. Em geral, o administrador dos dados será uma pessoa que trabalha no negócio, com conhecimento dos dados, que possa reconhecer dados incorretos e que tenha conhecimento e autoridade para corrigir as falhas. A infraestrutura do MDM deverá incluir ferramentas que ajudem o administrador dos dados no reconhecimento das falhas, simplificando as correções. Uma boa ferramenta para a administração dos dados deve indicar as correspondências questionáveis realizadas: clientes com nomes diferentes e números de cliente que têm o mesmo endereço, por exemplo. O administrador talvez também queira revisar os itens acrescentados como novos, porque os critérios de correspondência estavam próximos, mas abaixo do padrão. É importante que o administrador de dados consulte o histórico das alterações feitas nos dados pelos sistemas MDM para isolar a fonte de erros e para desfazer alterações incorretas. A manutenção

também inclui os processos para “arrastar” as mudanças e as adições para o sistema MDM, e para distribuir os dados limpos nos lugares certos.