Gestão e Governança de Dados: Promovendo dados como ativo de valor nas empresas [1 ed.] 9788574526294

Citation preview

Copyright© 2013 por Brasport Livros e Multimídia Ltda. Todos os direitos reservados. Nenhuma parte deste livro poderá ser reproduzida, sob qualquer meio, especialmente em fotocópia (xerox), sem a permissão, por escrito, da Editora. Editor: Sergio Martins de Oliveira Diretora Editorial: Rosa Maria Oliveira de Queiroz Assistente de Produção: Marina dos Anjos Martins de Oliveira Revisão de Texto: Maria Inês Galvão Editoração Eletrônica: SBNigri Artes e Textos Ltda. Capa: Trama Criações Produçao de e-pub: SBNigri Artes e Textos Ltda.

Técnica e muita atenção foram empregadas na produção deste livro. Porém, erros de digitação e/ou impressão podem ocorrer. Qualquer dúvida, inclusive de conceito, solicitamos enviar mensagem para [email protected], para que nossa equipe, juntamente com o autor, possa esclarecer. A Brasport e o(s) autor(es) não assumem qualquer responsabilidade por eventuais danos ou perdas a pessoas ou bens, originados do uso deste livro.

ISBN Digital: 978-85-7452-629-4

BRASPORT Livros e Multimídia Ltda. Rua Pardal Mallet, 23 – Tijuca 20270-280 Rio de Janeiro-RJ Tels. Fax: (21) 2568.1415/2568.1507 e-mails: [email protected] [email protected] [email protected]

site: www.brasport.com.br Filial Av. Paulista, 807 – conj. 915 01311-100 – São Paulo-SP Tel. Fax (11): 3287.1752 e-mail: [email protected]

Ao meu filho Breno, meu orgulho, melhor amigo e pessoa mais importante da minha vida. A minha esposa Emanuella, pelo apoio e incentivo sempre presente. Aos meus pais, Manoel e Joana D’arc, por me passarem os valores éticos e de respeito ao próximo.

Agradecimentos Este trabalho não seria possível sem a participação de vários pro ssionais que direta ou indiretamente in uenciaram na construção dos textos deste livro, dentre os quais agradeço:

À equipe da editora Brasport, que acreditou na importância deste trabalho para as comunidades de Gestão de Dados e Gestão de Negócios no Brasil. À DAMA® – Data Management International, pelo apoio e pelas permissões dadas a este projeto. Aos atuais dirigentes do capítulo DAMA® Brasil: Hermann Dagys, Eduardo Godoy, Osvaldo Alvarenga e Evandro Lima, por disseminarem a Gestão e Governança de Dados em âmbito nacional e internacional, e, em especial, a Rossano Tavares, atual presidente deste capítulo. À IAIDQ (International Association for Information and Data Quality), por disseminar a Qualidade de Dados nas organizações e, em especial, a Rogério Carosi, principal voluntário da IAIDQ na América Latina, pelas informações sobre esta instituição.

À associação QIBRAS® (Qualidade da Informação Brasil), por disseminar a Qualidade de Dados nas organizações brasileiras e também pelas informações sobre a instituição, mencionada no capítulo 13 deste livro. Ao Aurélio Vinícius Roscoe Vieira, por ter me dado a oportunidade de começar a atuar na área de Administração de Dados há vinte anos no Arsenal de Marinha do Rio de Janeiro – AMRJ. Sem esta oportunidade, certamente este livro não existiria. Aos colegas do time de trabalho atual e demais colegas que já atuaram diretamente comigo. As lições aprendidas, experiências e convívio foram fundamentais para construção deste livro. A todos os alunos que já frequentaram os meus treinamentos de Gestão de Dados. Suas experiências, dúvidas e questionamentos também foram fundamentais para estabelecer o conteúdo deste livro. A toda a comunidade de Gestão de Dados, por fazer as coisas acontecerem e também por fazer a diferença em nossa sociedade. Por m, aos críticos do meu trabalho – a nal, as críticas, sejam elas construtivas ou não, são fundamentais para o desenvolvimento do ser humano como pessoa e pro ssional.

Sobre o Autor Bergson Lopes Rêgo é o principal idealizador e multiplicador da loso a da “Gestão de Dados Moderna” no Brasil e presta regularmente treinamentos e palestras sobre o tema. Conduziu e participou de projetos para implantação de áreas de Administração e Gestão de Dados em empresas de grande porte nos segmentos: Energia, Óleo & Gás, Governo, Financeiro, Seguros, Construção Civil e Indústria. Possui experiência de vinte anos na área de Tecnologia da Informação. No decorrer da carreira já ocupou várias funções, entre elas: Desenvolvedor, Analista de Sistemas, Administrador de Dados, Gerente de Projetos, Líder de Equipe e Consultor. Nos últimos treze anos tem atuado diretamente em atividades relacionadas à Gestão e Governança de Dados. Em 2001, fundou a Blensson & Blonsson Consultoria, empresa voltada à prestação de serviços de consultoria e treinamentos ligados à área de Gestão de Dados. Já treinou pro ssionais das mais diversas áreas e segmentos de atuação no Brasil. Desde 2011, é um voluntário ativo junto ao chapter Brasil da DAMA® – Data Management Association International, exercendo a função de Diretor de Estudos Técnicos, sendo um dos responsáveis pela revisão técnica da tradução do guia DAMA-DMBOK® para a língua portuguesa.

Nos últimos anos também tem se dedicado à publicação de artigos técnicos e conteúdo sobre Gestão e Governança de Dados. Bergson já publicou dezenas de artigos distribuídos nos canais: TI Inside e DevMedia. É certi cado PMP (Project Management Professional) pelo PMI (Project Management Institute), principal organização mundial responsável pelo desenvolvimento de práticas e pro ssionais em Gerenciamento de Projetos. Graduado em Informática pela FACHA, possui MBA em Gerência Estratégica da Informação e também em Gerência de Projetos (Master in Project Management), ambos pela Universidade Federal do Rio de Janeiro (UFRJ). Para entrar em contato com o autor, utilize os seguintes endereços: Website: www.bergsonlopes.com.br Email: [email protected] Skype: bergson.lopes Twitter: BergsonL LinkedIn: http://www.linkedin.com/in/bergsonlopes

Nota do Autor Escrever um livro que tem por objetivo introduzir uma disciplina que ainda se encontra em estágios iniciais de adoção no Brasil não é uma tarefa fácil. Os países mais maduros no uso da disciplina de Gestão de Dados possuem dezenas de publicações especializadas sobre o assunto. Já aqui no Brasil, a carência de publicações nacionais dedicadas exclusivamente ao assunto é notória. Certamente, esta é umas das principais razões que contribuem para o atraso no desenvolvimento desta disciplina no nosso país. A constatação deste atraso foi a principal razão que me convenceu da necessidade de escrever este livro. O conteúdo deste livro é introdutório e tem como principal propósito levar aos leitores os principais conceitos e propostas da Gestão de Dados que podem ser aplicados de forma imediata nas empresas brasileiras. A Gestão de Dados se propõe a fornecer subsídios para que as empresas realmente utilizem os dados e as informações como ativos de valor estratégico. Boa parte do conteúdo deste livro fará referência ao guia DAMADMBOK®1 publicado pela DAMA®2 (Data Management International). Entretanto, o livro não aprofundará o conteúdo de todas as funções vigentes no guia e também não pretende ser uma simples cópia de conteúdo.

Recomendo a leitura do livro de forma sequencial desde a sua introdução, onde é passado um breve histórico da utilização da Gestão de Dados no Brasil. Logo após, os capítulos iniciais do livro levam ao leitor conceitos básicos sobre a Gestão de Dados, suas principais características, conceitos, de nições, papéis e uma visão geral do principal documento de referência em Gestão de Dados – o guia DAMA-DMBOK®. A parte intermediária do livro é dedicada aos estudos das principais funções em Gestão de Dados, entre elas: Modelagem de Dados, Governança de Dados, Arquitetura de Dados, Gestão de Dados Mestres e Dados de Referência e Qualidade de Dados. Após o detalhamento das principais funções de Gestão de Dados, os leitores também terão a oportunidade de conhecer a loso a da Gestão de Dados Moderna nos capítulos nais do livro. Esta loso a é focada na conduta comportamental dos pro ssionais que atuam na área e prega o entendimento de que os principais ativos da empresa são três: Pessoas, Dados e Recursos Financeiros. Por m, o livro é encerrado em um capítulo dedicado à carreira do Gestor de Dados. Neste capítulo, o leitor terá acesso às principais informações deste mercado de trabalho, organizações que atuam na área de Gestão e Governança de Dados, bem como informações úteis sobre as certi cações pro ssionais desta área. Boa leitura a todos! Bergson Lopes Rego, PMP

Prefácio Gestão de Dados e Governança de Dados são assuntos novos e ainda pouco explorados. Entretanto, gradativamente as organizações têm percebido que a adoção das melhores práticas em Gestão e Governança de Dados, além de proporcionar redução de custos, aumento da segurança da informação, tomada de decisões com informações assertivas, gera também diferencial competitivo. Todos nós sabemos que as organizações são criadas para a eternidade, esta é a vontade de seus criadores, porém muitas não conseguem passar do primeiro ano de vida. Nos dias de hoje, qualquer empresa que queira ser eterna necessita colocar na sua agenda a Gestão e a Governança de Dados. Assim como o sangue é essencial para o corpo humano, dados são fundamentais para as organizações. Dados são os uidos que lubri cam todas as relações e ações executadas nas organizações e estão presentes nas atividades executadas pelas áreas, em processos e também nos projetos. Sendo assim, dados merecem ser respeitados e tratados como ativos-chave para a manutenção operacional e estratégica das organizações. Como bem disse Tom Peters, “As organizações que não entenderem a enorme importância da Gestão de Dados e informações como ativos tangíveis na nova economia não vão sobreviver”. Entretanto, não basta entender, as organizações precisam ser proativas e adotar um conjunto de melhores práticas que possibilitem aos stakeholders (partes interessadas) ter a segurança necessária quando o assunto for dados.

Também é conhecimento geral de que dado é a base para a informação e que informação, por sua vez, é a base para o conhecimento. Isso exige também que as organizações adotem práticas associadas à gestão do conhecimento. O trabalho da Gestão e Governança de Dados pode ser árduo e complexo, mas os ganhos proporcionados são inestimáveis. Para que as organizações e os seus pro ssionais possam mudar os seus valores e passem a considerar os dados como ativos, é necessário que muitas publicações sejam disponibilizadas para os formadores de opinião, mas com um conteúdo direcionado para os decisores, pois estes, em última instância, acabam tomando decisões com grande probabilidade de erros e também com grande margem de riscos. Portanto, as publicações precisam ter apelo su ciente para que decisores e in uenciadores sejam motivados a colocar em prática a Gestão e Governança de Dados. O livro publicado pelo Bergson Lopes é inédito no Brasil e certamente é uma publicação que vai ser fundamental neste momento tão importante para as organizações. O livro agora disponível, resultado de um árduo trabalho empreendido pelo autor, passa a ser, igualmente ao DAMADMBOK®, uma referência para todos os pro ssionais de todos os tipos de organizações. Desejo uma ótima leitura! Rossano Soares Tavares Presidente do capítulo brasileiro da Data Management Association – DAMA® Brasil

Sumário Capa Créditos Dedicatória Agradecimentos Sobre o Autor Nota do Autor Prefácio Introdução Parte 1 1. Conceitos Básicos 1.1. Dado, informação, conhecimento e sabedoria 1.2. Ciclo de vida dos dados 1.3. Características de qualidade desejadas para os dados e metadados 1.4. Big Data 1.4.1. Como caracterizar o Big Data? 1.4.2. Volume

1.4.3. Velocidade 1.4.4. Variedade 1.4.5. Veracidade 1.4.6. Valor 1.5. Considerações nais sobre Big Data 2. Gestão de Dados 2.1. Gestão de Dados – De nições 2.2. Princípios que orientam a Gestão de Dados 2.3. Principais funções que compõem a disciplina Gestão de Dados 2.4. Principais ganhos na adoção da Gestão de Dados 2.5. Gestão de Dados ou Administração de Dados – Qual o termo correto? 2.6. Mitos sobre a Gestão de Dados 3. Papéis Envolvidos na Gestão de Dados 3.1. Tipos de papéis envolvidos 3.2. Papéis ligados ao negócio 3.2.1. Gestor de Dados de Negócio 3.2.1.1. Principais características para atuar neste papel 3.2.2. Coordenadores e gerentes das equipes de Gestão de Dados de Negócio 3.2.2.1. Principais características para atuar neste papel 3.2.3. Gestor da Informação 3.2.3.1. Principais características para atuar neste papel 3.3. Papéis estratégicos 3.3.1. Executivo de Gestão de Dados 3.3.1.1. Principais características para atuar neste papel 3.3.2. Gestor Estratégico de Dados 3.3.2.1. Principais características para atuar neste papel 3.4. Papéis técnicos

3.4.1. Coordenadores e gerentes das equipes de Gestão Técnica de Dados 3.4.1.1. Principais características para atuar neste papel 3.4.2. Gestor Técnico de Dados 3.4.2.1. Principais características para atuar neste papel 3.4.3. Administrador dos Repositórios de Metadados 3.4.3.1. Principais características para atuar neste papel 3.4.4. Projetista de Dados 3.4.4.1. Principais características para atuar neste papel 3.4.5. Administrador de Banco de Dados (DBA) 3.4.5.1. DBA de Aplicação 3.4.5.1.1. Principais características para atuar como DBA de Aplicação 3.4.5.2. DBA de Infraestrutura 3.4.5.2.1. Principais características para atuar como DBA de Infraestrutura 3.4.6. Arquiteto de Integração de Dados 3.4.6.1. Principais características para atuar neste papel 4. Estabelecendo a Gestão de Dados nas Empresas 4.1. Contextualização 4.2. Equipes de Gestão de Dados 4.3. Onde estabelecer a Gestão de Dados? 4.4. Cenários de distribuição das equipes de Gestão de Dados 4.4.1. Cenário 1 – Equipe centralizada 4.4.2. Cenário 2 – Gestão de Dados distribuída em duas equipes (Negócio e TI) 4.4.2.1. Estruturação das duas equipes em um organograma 4.4.2.2. Vantagens e desvantagens de trabalhar com duas equipes

4.4.3. Cenário 3 – Gestão de Dados distribuída em várias equipes de negócio e uma única equipe de TI 4.4.4. Cenário 4 – Gestão de Dados distribuída em uma equipe de Gestão de Dados de Negócio e várias equipes de Gestão Técnica de Dados especializadas 4.4.5. Cenário 5 – Gestão de Dados distribuída em várias equipes técnicas e equipes de negócio 4.5. Qual o melhor cenário para adotar a Gestão de Dados em minha empresa? 5. Visão Geral do Guia DAMA-DMBOK® 5.1. O que é o Guia DAMA-DMBOK®? 5.2. Framework 5.2.1. Funções de Gestão de Dados 5.2.2. Elementos ambientais 5.3. Junção das funções de Gestão de Dados com os elementos ambientais Parte 2 6. Governança de Dados 6.1. Governança de Dados – Conceitos 6.2. Razões para implantar a Governança de Dados 6.3. Princípios da Governança de Dados 6.4. Componentes da Governança de Dados 6.4.1. Pessoas 6.4.2. Processos 6.4.3. Tecnologia 6.5. Documentos da Governança de Dados 6.5.1. Estratégia de Dados 6.5.2. Política de Dados 6.5.3. Normas e padrões 6.5.4. Procedimentos

6.6. Estruturas formais de apoio à Gestão de Dados 6.6.1. Escritório de Gestão de Dados 6.6.2. Comitês de Gestão de Dados 6.6.3. Conselho de Governança de Dados 6.7. Dicas para implantar um programa de Governança de Dados 6.8. Atividades necessárias para manter um programa de Governança de Dados segundo o DAMA-DMBOK® 7. Modelagem de Dados 7.1. Modelagem de Dados – Principais conceitos 7.2. Modelo Conceitual de Dados 7.2.1. Entidades 7.2.2. Relacionamentos 7.2.2.1. Grau dos relacionamentos 7.2.2.2. Cardinalidade 7.2.2.3. Tipos de relacionamentos 7.2.3. Atributos 7.2.4. Mecanismos avançados de abstração em um Modelo Conceitual de Dados 7.2.4.1. Repetição 7.2.4.2. Autorrelacionamento 7.2.4.3. Generalização e especialização 7.2.4.4. Agregação 7.3. Modelo Lógico de Dados 7.3.1. Conceitos básicos em Modelagem Lógica de Dados 7.3.1.1. Entidade independente 7.3.1.2. Entidade dependente 7.3.1.3. Relacionamento identi cado 7.3.1.4. Relacionamento não identi cado 7.3.1.5. Chave primária 7.3.1.6. Chave candidata

7.3.1.7. Chave alternativa 7.3.1.8. Chave estrangeira 7.3.1.9. Restrições de integridade 7.3.2. Normalização 7.3.2.1. As formas normais 7.3.2.2. Primeira forma normal (1FN) 7.3.2.3. Segunda forma normal (2FN) 7.3.2.4. Terceira forma normal (3FN) 7.4. Modelo Físico de Dados 7.4.1. O Modelo Físico de Dados e as desnormalizações 7.4.2. Elementos estruturais de um Modelo Físico de Dados 7.5. Documentação de um modelo de dados 7.5.1. Boas práticas para dar nomes aos elementos 7.5.2. Boas práticas para conceituar (de nir) elementos 7.5.2.1. O que evitar na de nição de entidades e atributos? 7.5.2.2. Exemplos de boas de nições 7.6. Qualidade dos modelos de dados 7.6.1. Processos de qualidade para modelos de dados 7.6.2. Critérios de qualidade aplicados em modelos de dados 7.6.2.1. Completeza ou completude 7.6.2.2. Conceituação 7.6.2.3.Integridade 7.6.2.4. Flexibilidade 7.6.2.5. Integração 7.6.2.6. Legibilidade 7.6.2.7. Padronização 7.6.2.8. Aspectos físicos e de performance 7.7. Considerações nais sobre Modelagem de Dados 8. Arquitetura de Dados

8.1. O que é uma Arquitetura de Dados? 8.2. Atividades necessárias para criar e manter uma Arquitetura de Dados 8.3. Arquitetura de Dados não é apenas uma coleção de modelos de dados e bancos de dados 8.3.1. Cadeia de Valor e macroprocessos 8.3.2. Glossário de termos corporativos 8.4. Modelos de dados e Arquitetura de Dados 8.5. Modelos de dados compartilhados 8.6. Modelos de dados corporativos 8.6.1. Como diferenciar modelos corporativos dos modelos compartilhados 8.6.2. Abordagens para construção de modelos corporativos 8.6.2.1. Abordagem Top Down 8.6.2.2. Abordagem Bottom Up 8.6.2.3. Abordagem Híbrida 8.7. Tipos de modelos de dados corporativos segundo o DAMADMBOK® 8.7.1. Modelo de Área de Interesse 8.7.2. Modelos conceituais de dados 8.7.3. Modelos lógicos de dados 8.8. Integração dos dados corporativos 8.8.1. Integração via troca de arquivos 8.8.2. Integração via ETL 8.8.3. Integração via Database Links ou Linked Servers 8.8.4. Replicação de dados e Oracle Golden Gate 8.8.5. Integração via serviços 9. Gestão de Dados Mestres e Referência 9.1. Contextualização 9.2. Dados mestres

9.3. Dados de referência 9.4. Dados transacionais 9.5. Gerenciamento de dados mestres e referência 9.6. Estilos de arquiteturas de dados mestres 9.6.1. Pré-MDM 9.6.2. Consolidação 9.6.3. Registro 9.6.4. Coexistência 9.6.5. Coexistência só de leitura 9.6.6. Transacional 9.7. Passos para implantar o MDM 10. Qualidade de Dados 10.1. O que é Qualidade de Dados? 10.2. Dados de baixa qualidade – Dados sujos 10.3. Processo de Qualidade de Dados (conteúdo) 10.3.1. Promover a Qualidade dos Dados 10.3.2. De nir requisitos e questões da qualidade 10.3.3. Per lar dados – Data pro ling 10.3.4. Analisar dados 10.3.5. Limpar e corrigir dados – Data cleansing 10.3.6. Garantia da Qualidade dos Dados e Metadados 10.4. Considerações nais sobre a Qualidade de Dados Parte 3 11. Gestão de Dados Moderna 11.1. Visão geral da Gestão de Dados Moderna 11.2. Estrutura da Gestão de Dados 11.2.1. Corpo Técnico 11.2.2. Ferramentas 11.2.3. Metodologia

11.2.4. Qualidade 11.2.5. Alinhamento estratégico 11.2.6. Governança de Dados 11.3. Conduta 11.3.1. Adaptação 11.3.2. Agilidade 11.3.3. Bom senso 11.3.4. Comprometimento 11.3.5. Didática 11.3.6. Objetividade 11.3.7. Proatividade 11.3.8. Racionalidade 11.4. Pilares das organizações 11.4.1. Dados e metadados 11.4.2. Pessoas 11.4.3. Recursos nanceiros 12. Boas Práticas da Gestão de Dados Moderna 12.1. As quatorze boas práticas de Gestão de Dados Moderna 12.2. Manter um time de destaque 12.3. Atuar no início dos projetos 12.4. Ser ágil nos atendimentos 12.5. Utilizar princípios e ferramentas da qualidade 12.5.1. Ciclo PDCA aplicado na Gestão de Dados Moderna 12.5.2. Diagrama de Pareto 12.5.3. Diagrama de causa e efeito 12.5.4. Grá cos de controle 12.5.5. Listas de veri cações (checklists) 12.6. Trabalhar com indicadores de gestão 12.7. Repassar os custos aos clientes

12.8. Nunca acomodar 12.9. Utilizar metodologia adequada 12.9.1. Diretrizes básicas para a construção de uma Metodologia de Gestão de Dados 12.9.2. Características consideradas na criação de uma Metodologia de Gestão de Dados 12.10. Utilizar ferramentas de apoio 12.11. Utilizar modelos de dados 12.12. Investir na capacitação dos clientes 12.13. Entender que o sucesso depende de todos 12.14. Divulgar a área de Gestão de Dados 12.15. Ter bom senso 13. Desenvolvimento Pro ssional 13.1. O mercado de trabalho em Gestão de Dados 13.2. Organizações que atuam na área de Gestão de Dados 13.2.1. DAMA® – Data Management International 13.2.2. IAIDQ – International Association for Information and Data Quality 13.2.3. DGI – Data Governance Institute 13.2.4. QIBRAS® 13.2.5. TDWI – The Data Warehouse Institute 13.3. Certi cações: luxo ou necessidade? 13.4. Benefícios de uma certi cação 13.5. Principais certi cações do mercado para a área de Gestão de Dados 13.5.1. DAMA-CDMP® 13.5.1.1. Requisitos para a certi cação 13.5.1.2. Processo de certi cação 13.5.2. IAIDQ-IQCP 13.5.2.1. Requisitos para a certi cação

13.5.2.2. Processo de certi cação Anexos I. Governança de Dados II. Gestão da Arquitetura de Dados III. Desenvolvimento dos Dados IV. Gestão de Operações e Database V. Gestão da Segurança de Dados VI. Gestão de Dados Mestres e Referência VII. Gestão de Data Warehousing e Business Intelligence VIII. Gestão de Documentação e Conteúdo IX. Gestão de Metadados X. Gestão da Qualidade de Dados Notas

Introdução “Pensar consiste, ordinariamente, em ir dos conceitos às coisas, e não das coisas aos conceitos.” Henry Bergson (em Introdução à Metafísica)

“Os dados são o ativo mais importante das empresas”. Quando comecei a trabalhar como Administrador de Dados, esta já era uma das frases mais ditas pelos pro ssionais das áreas de dados. Já se passaram mais de vinte anos e, atualmente, ainda escuto quase que diariamente a mesma frase, às vezes dita de forma diferente, mas com o mesmo propósito de valorizar os dados como importantes ativos nas empresas. Sem dúvida alguma, o jargão é nobre e adequado. Atualmente, há um consenso geral nas empresas de que nenhuma organização é e caz sem o apoio de dados e informações de qualidade. Grandes gurus internacionais das áreas de administração e negócios costumam mencionar em seus artigos a importância de ter dados con áveis e a necessidade de gerenciá-los de forma e caz para as empresas obterem vantagens em relação aos seus concorrentes. Apesar da importância reconhecida em possuir dados e informações de qualidade, a situação dos dados nas empresas brasileiras não evoluiu muito nesse tempo. Aliás, tenho a ligeira impressão de que a qualidade dos dados piorou nos últimos anos, principalmente nas empresas que não possuem

pro ssionais dedicados a zelar pela gestão e qualidade dos dados de forma integral. Mas a nal, se há mais de vinte anos o dado já era considerado um ativo importante pelos pro ssionais que atuam nas áreas de dados, e várias organizações reconhecem a sua importância, por que, na minha percepção, a qualidade dos dados diminuiu? Nada foi feito para melhorar esse cenário? Nada de novo surgiu com o propósito de melhorar a gestão e qualidade dos dados? Na verdade, durante esse tempo, várias ferramentas e soluções surgiram no mercado com o propósito de apoiar as áreas de tecnologia da informação em gerir melhor os dados que ela custodia. De início, algumas soluções conseguiram atingir os seus propósitos, porém, atualmente, por mais que as áreas de tecnologia da informação tenham evoluído com a adoção dessas novas ferramentas e soluções, deparamo-nos com um ambiente de negócios dinâmico e multidisciplinar, que evoluiu muitas vezes mais, ou seja, as áreas de tecnologia da informação estão muito mais bem preparadas do que no passado, porém esse aumento da capacidade tecnológica é cada vez menor se comparado com a evolução e dinamicidade dos ambientes de negócios nas empresas. Então o que podemos fazer? Temos de nos acomodar? Claro que não. Na verdade, precisamos de mecanismos de gestão que reduzam essa diferença entre a tecnologia e a agitação do ambiente de negócios. Em relação ao uso dos dados e das informações, a área de Administração de Dados tentou atuar no passado para reduzir essas diferenças, porém vimos que muitas empresas não obtiveram o sucesso esperado, principalmente em conseguir tratar e disseminar os dados efetivamente como ativos em todas as organizações. Mas, a nal, por que a área de Administração de Dados do passado não conseguiu ser tão e ciente quanto o esperado?

Se observarmos com atenção o histórico da adoção e uso das áreas de Administração e Gestão de Dados nas empresas brasileiras nas últimas décadas, conseguiremos alcançar algumas respostas para as perguntas elencadas nos primeiros parágrafos desta introdução. No decorrer de cada década, os cenários de atuação das áreas de Administração e Gestão de Dados mudaram radicalmente. Durante esse tempo, erros dos mais diversos tipos foram cometidos. Um dos propósitos deste livro é elencar esses erros e oferecer aos leitores alternativas para não repeti-los em implantações futuras. A gura a seguir ilustra algumas particularidades, além do resumo da atuação das áreas de Administração e Gestão de Dados em cada década, desde o início da utilização do conceito “Administração de Dados” até os dias atuais, onde o termo “Gestão de Dados” ganha mais força. A década de 2010 é tratada como uma época de redescoberta, onde a área de Gestão de Dados reconhece os erros passados e, através da compreensão deles, busca ressurgir nas empresas de forma mais ampla, simples e aderente às necessidades e evoluções do negócio.

Figura 1 – Histórico da Gestão de Dados no Brasil – Visão do autor

Se olharmos com atenção a gura anterior, iremos observar que as mudanças dos cenários e de tecnologia foram bastante amplas. Os comentários da linha do tempo a seguir detalharão o que ocorreu de importante em cada uma das décadas. Primeiro estágio – Boom! O conceito AD surge no mercado (anos 80) – Os bancos de dados relacionais começaram a ser adotados nas empresas ainda na plataforma alta (mainframes), em substituição aos sistemas de arquivos e bancos de dados em rede e bancos de dados hierárquicos. Para suportar as atividades decorrentes do uso dos SGBDRs1, consolidou-se no mercado brasileiro o papel do DBA (Administrador de Banco de Dados). Em um primeiro instante, o DBA geralmente acumulava as atividades de administração do banco de dados e também, quando existentes, as atividades de apoio e Modelagem de Dados. O volume de utilização e o grau de complexidade das soluções que envolviam o uso de SGBDRs nessa época não eram muito grandes, pois muitas aplicações e sistemas ainda eram desenvolvidos e/ou mantidos com as tecnologias anteriores aos SGBDRs. Em pouco tempo, veri cou-se no mercado que o per l DBA não era su ciente para suportar todas as tarefas relativas ao uso dos bancos de dados nas organizações. Faltava um per l mais genérico, ligado ao entendimento dos requisitos de negócio e técnicas de análise. Surgia então o papel do AD – Administrador de Dados. Apesar de estarem diretamente ligados à mesma matéria-prima, o dado, DBAs e ADs são per s totalmente diferentes. O primeiro é mais focado em questões físicas, ligadas ao armazenamento e desempenho das consultas com os dados, preocupações necessárias para gerir toda a infraestrutura e assegurar boa disponibilidade e desempenho dos dados. Já o segundo é um per l mais genérico, não tão técnico, ideal para traduzir requisitos de informação e regras de negócio em modelos de dados.

No m da década de 80, algumas grandes empresas saíram na frente e criaram suas sessões/departamentos de Administração de Dados, todas dentro da área de Informática. A função AD era nova e, consequentemente, na época, não havia pro ssionais prontos no mercado. De forma geral, os pro ssionais eram selecionados e treinados dentro das próprias empresas. Na montagem das equipes de Administração de Dados, geralmente eram escolhidos os voluntários com grande experiência em análise de sistemas (pro ssionais sêniores) e conhecimento genérico das áreas de negócios da empresa. Segundo estágio – Administração de Dados consolidada (anos 90) – A adoção dos SGBDRs aumentou consideravelmente nas empresas devido ao movimento de downsizing adotado por elas. O downsizing tinha o propósito de migrar os sistemas e as aplicações da plataforma alta (mainframes) para a plataforma baixa (micros). Nessa década, o discurso dos dados como ativos importantes das organizações já soava como algo inovador e poderoso, no sentido de obter apoio nas altas esferas dos departamentos de Informática/TI. O termo “Administração de Dados” de nitivamente tinha entrado na moda. Várias empresas criaram áreas de Administração de Dados baseadas no modelo de trabalho de organizações que foram pioneiras no uso da AD no m da década de 80. O surgimento das primeiras ferramentas de modelagem no mercado, aliado à consolidação de sistemas gerenciadores de bancos de dados para plataforma baixa, facilitou a implantação da área de Administração de Dados. O modelo de trabalho da Administração de Dados, nessa época, era formado principalmente pela tríade dos grupos de atividades: Modelagem de Dados, Administração de Banco de Dados e Gestão de Modelos de Dados. A quase totalidade das áreas de AD implantadas era subordinada aos

departamentos de Informática/TI. Além disso, em muitas empresas, a função não era considerada estratégica, mas sim tática. Por outro lado, a partir dessa época, começamos a vivenciar com rapidez a evolução das tecnologias. Na própria década de 90 foram adotadas mudanças radicais em relação à forma de desenvolver soware. Sistemas eram projetados/especi cados segundo os paradigmas da análise estruturada, logo depois, a análise essencial e, já no nal desta década, a orientação a objetos (UML2) começou a ser adotada com maior ênfase. O modelo de Administração de Dados herdado da época anterior começava a não conseguir acompanhar o ritmo que era imposto pela evolução tecnológica. Terceiro estágio – Declínio da AD (anos 2000) – Esta época foi marcada pelo declínio da Administração de Dados nas empresas. O ritmo da evolução tecnológica, que já era forte na década passada, aumentou ainda mais nesta década, porém o ritmo de capacitação dos Administradores de Dados não era o mesmo. Era bastante comum, na época, encontrar pro ssionais de Administração de Dados que não sabiam, por exemplo, conceitos de orientação a objeto e formas de consumo dos dados além das tradicionais consultas de dados via SQL. Na expectativa de reduzir seus custos sem perder e ciência operacional, as empresas começaram a intensi car o movimento de terceirização de pessoal, já iniciado na década passada, das suas gerências e departamentos de TI. Vários departamentos foram extintos, dando lugar a contratos de prestação de serviços especí cos ou simples contratos de alocação de mão de obra, onde, na prática, vários pro ssionais eram demitidos e voltavam às suas empresas de origem como consultores externos. Ao contrário do que era imaginado na época, este movimento resultou em um expressivo aumento dos postos de trabalho. Em muitos casos, a gestão do pessoal cava por conta das consultorias, que, apesar de estarem preocupadas com a e ciência

da prestação de seus serviços, também estavam preocupadas com o seu próprio faturamento. En m, a quantidade de Administradores de Dados formados e quali cados no mercado era insu ciente para suprir todas as demandas e vagas necessárias. Com isso, as consultorias começaram a contratar pro ssionais fora do per l ideal de um Administrador de Dados. Logicamente, esse movimento não surtiu um bom resultado, pois, além de contratar mal, a rotatividade e a perda de conhecimento eram muito grandes. Em um curto espaço de tempo, a função começou a ser desprestigiada no mercado. A segunda metade desta década cou marcada pelo êxodo de pro ssionais quali cados na função de Administrador de Dados. Alguns se aposentaram, outros abandonaram a função e foram tentar a vida em outras funções mais prestigiadas na época. Com poucos pro ssionais disponíveis, algumas empresas tentavam fundir novamente as atividades do AD (Administrador de Dados) com as atividades do DBA (Administrador de Banco de Dados), piorando ainda mais o cenário e ocasionando, mais uma vez, o problema de identidade da função, aparentemente já resolvido na década passada. Além disso, as pressões por entregas de soware cada vez mais curtas e a um custo menor também colaboravam para desenvolver várias fontes de informações não íntegras e redundantes. Geralmente sem fôlego, as equipes de Administração de Dados já não conseguiam administrar toda essa desordem. Os esforços dos quadros da Administração de Dados nas empresas não eram mais su cientes para acompanhar o ritmo das solicitações e integrar de forma planejada as informações que eram demandadas. No meio de todo esse caos, os sistemas ERPs3 começaram a ser implantados nas empresas com a promessa de integrar todos os dados e processos. A princípio, os ERPs solucionariam todos os problemas de

informações redundantes e de quebra ainda diminuiriam o número de aplicações desenvolvidas e utilizadas pelas áreas de negócio das empresas. Junto com os ERPs, soluções de CRM4 também eram adotadas com o propósito de melhorar o gerenciamento das informações de clientes e as soluções de Business Intelligence para apoiar a tomada de decisões estratégicas. De forma geral, por estarem sobrecarregadas ou até mesmo buscando a própria sobrevivência, as equipes de Administração de Dados não se envolviam com esses tipos de soluções. En m, o cenário para o m da Administração de Dados já estava montado. Quarto estágio – A Redescoberta da Gestão de Dados (a partir de 2010) – O tempo passou e as empresas começaram a observar que as promessas de integração dos dados propostas pelos pacotes ERP das grandes empresas de TI não foram completamente atingidas. Além disso, vários projetos de Business Intelligence fracassaram não por falta de recursos, patrocínio ou questões de capacidade técnica dos times de projeto, mas pela má qualidade dos dados que eram manipulados no ambiente produtivo. Ao contrário do que era imaginado na década anterior, em muitas empresas a adoção dos ERPs não extinguiu o problema de armazenar os mesmos dados em diversos lugares diferentes – na verdade, a redundância dos dados ainda persiste em muitas empresas que adotaram esta estratégia. Na grande maioria das vezes, essas redundâncias não são conhecidas e também não são controladas. Nesses casos, a única certeza existente sobre os dados é que há o problema de redundância, porém as formas de resolução ainda não são totalmente conhecidas. Com o crescimento desorganizado das empresas motivado por fusões, aquisições e reestruturações, cada vez mais as áreas de TI cam distantes das áreas de negócio nas empresas. Em muitos casos, o conhecimento do negócio está na cabeça dos analistas funcionais das soluções ERP. Vale

ressaltar que esses pro ssionais são especializados em processos e não em dados. En m, agora, além de ter dados redundantes e não con áveis, as empresas convivem com o problema de não conhecer o acervo de dados existentes. Este fato ocasiona inúmeros problemas; um dos principais é o fato de a empresa não ter os dados necessários para uma melhor gestão dos seus próprios negócios. A falta de alinhamento entre a TI e o negócio está evidente. Além disso, o volume de dados processados atualmente é muito maior do que nas décadas passadas. Grandes players do mercado começam a trabalhar com o conceito de “Big Data”, onde algumas dezenas de petabytes de dados são processadas a cada dia. O movimento contínuo de redução de custos das empresas, alinhado à necessidade de tomadas de decisões cada vez mais rápidas e consistentes, trouxe desta vez, de forma mais contundente, a importância do reconhecimento dos dados como ativo estratégico de qualquer organização. Contudo, o modelo de trabalho das áreas de Administração de Dados do passado já não é mais su ciente para conseguir resolver todos esses problemas. Na verdade, o problema agora é muito maior: além dos problemas já apontados, os dados também não são conhecidos e também não são governados. Neste cenário, surge a Gestão de Dados com o propósito de ser uma função mais abrangente que a antiga Administração de Dados, pois esta última não se limita a atuar na administração/gestão dos metadados dentro do ciclo de desenvolvimento dos sistemas, e sim em todo o ciclo de vida dos dados, garantindo uma melhor gestão dos dados e metadados que circulam nas empresas.

Um dos grandes diferenciais, tido como uma premissa fundamental da Gestão de Dados, é o reconhecimento de que a responsabilidade pela gestão dos recursos de dados e informações deve ser compartilhada entre a área de TI e as demais áreas de negócio das empresas. A falta deste alinhamento pode ser considerada uma das principais causas para o insucesso. A gura a seguir representa o compartilhamento dessa responsabilidade. Esta premissa será mencionada várias vezes no livro. Seu entendimento e sua aceitação são fundamentais para o sucesso da adoção da Gestão de Dados nas empresas.

Figura 2 – Responsabilidade Compartilhada pela Gestão de Dados

A adoção da Gestão de Dados no Brasil ainda é bastante recente, porém a função já é adotada há mais de uma década nos Estados Unidos e no Canadá. Algumas empresas no Brasil já começaram com iniciativas para adotar esta disciplina e os resultados têm sido bastante satisfatórios. A Gestão de Dados propicia às empresas a possibilidade de realmente utilizarem informações íntegras, de qualidade e de fácil acesso, formando um alicerce para que tomem decisões baseadas em dados reais e con áveis. Pessoas mal informadas podem correr o risco de ver a Gestão de Dados como mais um modismo proposto pelos gurus da administração, porém elas

estão enganadas, pois no fundo a Gestão de Dados não propõe nada revolucionário e novo. Sua proposta é estabelecer uma gestão com responsabilidades compartilhadas como forma de quebrar paradigmas nas empresas que estavam acostumadas a destinar pouco tempo para planejar e sempre ter recursos su cientes para refazer ou consertar as aplicações que armazenam e consomem os seus dados.

Parte 1 Conceitos Básicos sobre Gestão de Dados

1. Conceitos Básicos “O olho vê somente o que a mente está preparada para compreender.” Henri Bergson

1.1. Dado, informação, conhecimento e sabedoria Dado, informação, conhecimento e sabedoria constituem a cadeia de evolução de dados e informações. Quando falamos sobre “dados”, na verdade estamos nos referindo à base da matériaprima necessária para conseguir o que todas as empresas desejam: utilizar o conhecimento das informações para tomar decisões ágeis e corretas. O amadurecimento de dados e informações é representado através de sua cadeia de evolução. Esta cadeia estabelece um conceito de maturidade de uso dividido em quatro estágios, sequenciais, necessários à conquista deste propósito. Como em qualquer estágio, os esforços para alcançar o amadurecimento devem ser feitos primeiramente nos níveis iniciais e somente depois nos próximos níveis. Neste caso especí co, os dados devem ser tratados e reconhecidos primeiro – por esta razão o nome da disciplina é Gestão de Dados, e não Gestão das Informações ou Gestão do Conhecimento. A cadeia de evolução de dados e informações representa a transformação gradual e progressiva sobre o uso de dados e informações no ambiente empresarial. Também serve como modelo para descobrir em que nível dessa cadeia as informações de mais alto valor estratégico são utilizadas, possibilitando, desta forma, estabelecer ações para melhorar o nível da maturidade de dados e informações da empresa. Os dados são a base de todo o processo para geração da sabedoria empresarial e o primeiro nível de estágio a ser atingido. Eles representam fatos através de um conjunto de caracteres primitivos e isolados, geralmente representados através de textos, números, imagens, sons ou vídeos. Os dados não possuem qualquer signi cado relevante dentro de um contexto de negócio (dado sem contexto). Os metadados representam os signi cados dos dados. Estes signi cados correspondem tanto ao conteúdo técnico do dado, obtido através das informações sobre estrutura, formato, tamanho e restrições (metadados técnicos), como a informações sobre de nições, conceitos, relevância e regras de negócio dos dados envolvidos (metadados de negócio).

Outra de nição bastante comum e mais simples encontrada na literatura sobre metadados é o famoso clichê: “dados sobre os dados”. De forma geral, os metadados ainda são criados e mantidos pela área de TI. O gerenciamento dos metadados contribui diretamente para a melhoria da qualidade das informações e para o amadurecimento da cadeia de evolução dos dados. As informações correspondem aos dados processados com algum signi cado e são geradas e obtidas nos sistemas de processamento de transação e sistemas de apoio à decisão, reduzindo a incerteza sobre alguma coisa, estado ou evento. Quando os metadados são utilizados para leitura e interpretação dos dados, a cadeia de evolução do dado já mudou de estágio, ou seja, já está no nível da informação. O conhecimento corresponde ao processamento das informações com signi cados, premissas, padrões de comportamento, tendências e valores agregados através de conjuntos de regras de manipulação e características dessas informações. São o subsídio para soluções de problemas e tomadas de decisão. Atualmente, é impossível imaginar a evolução para este estágio da cadeia sem os sistemas de apoio à decisão e as aplicações de inteligência analítica. A sabedoria é a utilização do conhecimento com e cácia e e ciência. Do que adianta possuir o “conhecimento” se não utilizamos este ativo corretamente? Apesar das aplicações de inteligência analítica já serem uma realidade dentro do mercado, fornecendo condições para a empresa atingir o estágio anterior, muitas organizações que possuem estes subsídios desejam a “sabedoria”, mas não a conseguem. Parte deste fracasso está na con abilidade dos dados, que não foram bem geridos no decorrer da evolução da cadeia. Outra parte está na falta de habilidade dos pro ssionais em extrair as informações e utilizá-las de forma vantajosa. Algumas referências sobre Gestão de Dados, incluindo o guia DAMA-DMBOK®, não descrevem e também não reconhecem a sabedoria como o último estágio desta cadeia, justamente pelo fato dela depender em grande parte da competência humana para atingir este estágio. Por outro lado, empresas inovadoras, já adaptadas às novas realidades e tendências do mercado como o “Big Data” e o papel do “Cientista de Dados”, já reconhecem e buscam atuar neste último nível da cadeia de evolução dos dados. A gura a seguir mostra a cadeia de evolução do dado e um exemplo didático de sua utilização.

Figura 1.1 – Cadeia de Evolução dos Dados e Informações

Tomemos como base uma aplicação nanceira onde uma instituição deseja manter informações sobre a saúde nanceira de seus clientes. Ao acompanharmos a evolução demonstrada na gura anterior, veremos que: 1. O dado (–15000) é um número qualquer sem signi cado algum. 2. Ao consultar seu metadado, descobrimos que esta informação corresponde a um saldo negativo de R$ 15.000,00. Apesar de o exemplo mencionar algo com grau de di culdade bastante simples, grande parte das empresas ainda está situada neste estágio da cadeia de evolução do dado. 3. De acordo com os critérios de crédito da instituição (histórico, renda, comprometimento, garantias, reservas nanceiras, produtos adquiridos, etc.), chegamos à conclusão de que o cliente está endividado. Qualquer descuido ou acontecimento negativo na vida do cliente proporcionará uma possível inadimplência. Esse tipo de conhecimento é obtido através de aplicações com inteligência incorporada nas soluções. O conhecimento interfere diretamente na política de crédito adotada por esta e outras instituições. 4. Para eliminar as dívidas e, consequentemente, manter o cliente consumindo mais produtos nanceiros da instituição, a empresa deve utilizar a sabedoria para não apenas propor soluções que ajudem ao cliente, mas que também agreguem valor às suas vendas e a mantenham em posição de destaque no mercado. Para isso é fundamental conhecimento não só sobre os dados do cliente, mas também informações gerais sobre o conjunto de demais clientes acerca de: comportamento e renda, tendências de consumo, análises criteriosas dos riscos, cenário econômico nacional e mundial, entre outras informações que servirão de subsídios para que pessoas, sistemas especialistas, ferramentas estatísticas, ou ambos, utilizem o conhecimento dessas informações para tomar decisões cada vez mais ágeis e corretas. Vale ressaltar, que o nível “sabedoria” é desejado pela maioria das empresas, porém poucas se encontram nesse estágio de maturidade e uso. Conforme mencionado anteriormente, um per l emergente no mercado, o “Cientista de Dados”, tem como principal responsabilidade analisar grandes volumes de dados com o propósito de descobrir novas tendências e novos conjuntos de informações e combinações que agreguem valor às empresas. Com o apoio de novas ferramentas e algoritmos, novas informações são descobertas pelos Cientistas de Dados. O conjunto destas novas informações e tendências forma uma enorme vantagem competitiva da empresa em relação aos seus demais concorrentes, pois a inovação é incluída como algo permanente em suas ações, tornando a organização reconhecida no mercado pela originalidade e rapidez na tomada de decisões.

1.2. Ciclo de vida dos dados

Todo e qualquer ativo possui um ciclo de vida. Se tomarmos como exemplo as pessoas, um dos ativos mais importantes das organizações, nós poderemos observar o seguinte ciclo de vida dentro de uma empresa: pessoas tomam conhecimento das vagas disponíveis, se candidatam a essas vagas, são selecionadas, admitidas, treinadas, desenvolvem competências, podem ser promovidas, cedidas, transferidas, afastadas, licenciadas, colocadas em disponibilidade e, por m, encerram o seu ciclo pedindo desligamento, sendo demitidas ou então aposentadas. Com os dados não é diferente: tal como as pessoas e os demais ativos, possuem um ciclo de vida que precisa ser gerenciado. Segundo o guia DAMA-DMBOK®, no curso da sua vida o dado pode ser: extraído, exportado, importado, migrado, validado, editado, atualizado, limpo, transformado, convertido, integrado, segregado, agregado, referenciado, revisado, relatado, analisado, garimpado, salvo, recuperado, arquivado e restaurado antes de eventualmente ser eliminado. Na verdade, o ciclo de vida do dado possui uma relação muito forte com o ciclo de vida do desenvolvimento de sistemas, pois, geralmente, são iniciados no mesmo momento. Atualmente grande parte dos pro ssionais de TI ainda tem uma visão equivocada de que o ciclo de vida dos dados é igual ao ciclo de vida do desenvolvimento de sistemas. Ou seja, após as entregas das aplicações, o dado seria incluído pelo usuário nas aplicações entregues e a partir daí o ciclo seria encerrado, porém o ciclo de vida dos dados não termina aqui. Esta visão é equivocada, pois, depois de entregues, os dados começam a mudar de status e passam a ser efetivamente utilizados. Somente a partir daí começam a agregar valor ao negócio. En m, o ciclo de vida do dado é mais mutável e duradouro, sendo mantido após o encerramento do ciclo de desenvolvimento de sistemas. Vale ressaltar que sistemas e aplicações são alterados e às vezes desativados, porém os dados geralmente não sofrem desgastes. A falta de integração entre a TI e o negócio corroborou para manter esta visão equivocada dos dois ciclos. De forma geral, o ciclo de vida do desenvolvimento de sistemas descreve as etapas de um projeto de construção ou manutenção de um sistema/aplicação que irá fornecer subsídios para operar/utilizar os dados, enquanto o ciclo de vida dos dados descreve os processos executados para gerenciar os ativos de dados.

A

gura

a

seguir

descreve

a

relação

entre

os

dois

ciclos:

Figura 1.2 – Ciclo de vida do dado x ciclo de vida do desenvolvimento de aplicações Todos os estágios dos dois ciclos de vida possuem custos e riscos associados. Entretanto, o retorno sobre o investimento da criação do dado só é obtido após a sua real utilização no ambiente produtivo.

A gestão dos ativos de dados, através de seu ciclo de vida, não é algo exclusivo dos dados estruturados, geralmente armazenados em bancos de dados ou arquivos planos. Ela também ocorre com os dados não estruturados, armazenados em planilhas, imagens, sons e áudio. Estima-se que 80% dos dados das organizações estejam armazenados em formas não estruturadas. Muitos desses dados são volumosos e requerem atenção especial na sua gestão.

1.3. Características de qualidade desejadas para os dados e metadados O simples fato de gerir e governar dados não é su ciente para garantir o sucesso e o retorno nanceiro. Informações que geram resultado são obtidas através de dados de qualidade. As publicações que tratam da função “Qualidade de Dados” são muitas, porém não há um consenso entre os vários autores sobre quais são as dimensões de qualidade desejadas para os dados. Alguns autores preferem citar um número reduzido de dimensões que na verdade agrupam um conjunto de dimensões menores; já outros preferem citar várias dimensões especializadas divididas em tipos. O guia DAMA-DMBOK® prevê onze dimensões de Qualidade de Dados que devem ser atingidas para considerar um dado de qualidade. As dimensões recomendadas pelo guia são: acuracidade, completude, consistência, valor corrente, precisão, privacidade, razoabilidade, integridade referencial, em tempo adequado, unicidade e validade. Vale ressaltar que, através de suas dimensões, todas as publicações e guias criam conceitos macro de qualidade dos dados que são muito semelhantes entre si. Neste livro iremos adotar uma abordagem mais simples, com poucas dimensões, porém não só orientada aos dados, mas também aos metadados, visto que a qualidade dos dados começa a partir

do seu planejamento e especi cação, fases onde os metadados são criados e implementados. Seguem as dimensões de qualidade dos dados e metadados adotados neste livro: Aderência ao negócio: indica que o dado ou metadado está aderente em sua totalidade (por completo) aos requisitos de informação e regras de negócio da empresa. Unicidade: indica que o dado ou metadado é único e exclusivo dentro da empresa. Não há repetição de conteúdo e conceitos. Ou seja, não existem outros dados ou metadados iguais dentro da empresa. Quando esta dimensão é violada, ocorre a redundância. Integridade: indica que o dado atende a todas as restrições de integridade necessárias para que possa ser considerado um dado con ável. As restrições de integridade permitem a representação das regras de negócio, que, se não forem respeitadas, irão prejudicar a con abilidade dos dados. As restrições de integridade são de nidas nos metadados. Con abilidade: indica que o dado é atual, correto (sem erros) e pode ser utilizado sem afetar negativamente qualquer tipo de uso. Não existem erros de transformação, disponibilização e até mesmo de digitação. Manutenibilidade: indica baixo esforço na manutenção dos dados e metadados quando há uma solicitação de mudança que irá afetá-los. Metadados especi cados em modelos de dados de forma exível costumam ter baixo custo de manutenção – em alguns casos, dependendo da mudança, o esforço é feito somente nas aplicações, sem necessidade de alteração no modelo de dados ou dados das aplicações. Performance: indica que o tempo de resposta e acesso aos dados é satisfatório para os requisitos de uso. Legibilidade: fácil entendimento, compreensão e utilização dos dados e metadados. Modelos de dados com nomes adequados acarretam em metadados legíveis, facilitando a construção das aplicações que irão gerar as informações e, consequentemente, gerando dados de qualidade. Disponibilidade: indica que o dado ou metadado é conhecido e está disponível, no momento necessário, para quem tem o devido acesso. Envolve conceitos de governança e segurança dos dados e informações.

1.4. Big Data Nos últimos anos, grandes fabricantes de soluções de TI têm debatido com uma frequência muito alta a respeito do termo “Big Data”. Vários artigos e reportagens têm sido publicados ultimamente. Muitos desses artigos foram patrocinados por grandes empresas de soluções de TI. A grande maioria delas já possui produtos e soluções de consultoria à disposição em seus portfólios. As de nições sobre “Big Data” têm sido aprimoradas com o tempo e, no decorrer do tempo, alguns mitos são extintos e outros novos são criados.

Um dos primeiros mitos que ainda persiste no mercado é o fato de que “Big Data” só se aplica a dados não estruturados. Outro mito, ou percepção geral, é de que a maioria das empresas ainda não está preparada ou não possui necessidades de trabalhar com este conceito. Mas a nal o que é “Big Data”? De forma geral, quando falamos de “Big Data” estamos nos referindo ao crescimento exponencial dos dados, à utilização e ao armazenamento de dados em grandes volumes que desa am os métodos convencionais de análise e gestão dos dados. Ou seja, é um volume enorme de dados que, por vezes, dependendo das características dos dados e das empresas, devem ser armazenados e processados por mecanismos diferentes do que estávamos habituados. Vale destacar que os dados podem estar armazenados em formas estruturadas ou não. Atualmente nossa sociedade gera dezenas de petabytes de informações por dia dos mais variados tipos, entre elas: Informações comuns, como cadastros de clientes, fornecedores, funcionários, produtos, marketing e vendas. Informações sobre dados manipulados nos sistemas das empresas, tais como movimentações bancárias, transações de venda e compra de conteúdo, produtos e serviços. Dados das mídias sociais como Facebook, LinkedIn e Instagram. Dados de sensores e monitoramentos temporais. Dados oriundos de satélites e aplicações geoespaciais. Dados em formato multimídia, como imagens, sons e vídeos. Um único arquivo de vídeo ou imagem é in nitamente maior em bytes do que uma página simples de texto. Capturar, manusear e analisar este imenso volume de dados é um grande desa o. Adicione a isso o uxo constante de novos dados em mudança e os desa os se tornam maiores. Entretanto, com esses desa os vêm grandes recompensas para as empresas que são capazes de explorar os dados de forma mais e caz do que seus concorrentes. Agora as empresas não se contentam apenas em saber apenas o que foi vendido, consumido, comprado. A concorrência e a dinâmica dos negócios trazem cada vez mais a necessidade de entender o comportamento, as tendências, as previsões e as incertezas acerca dos dados dos clientes, fornecedores, parceiros e demais envolvidos em suas cadeias. Um dos exemplos clássicos e mais ilustrativos do uso do “Big Data” é o da empresa americana Target, que investiu no rastreamento das intenções de consumo de seus clientes. Certa vez, o pai de uma adolescente entrou furioso em uma loja da rede nos Estados Unidos, reclamou com o gerente que sua lha adolescente tinha recebido pelos correios cupons promocionais de produtos para gestantes e que a empresa estava estimulando a sua lha a pensar em engravidar. Imediatamente o gerente da loja pediu desculpas, porém, ao retornar ao cliente uma semana depois, o gerente da loja

foi comunicado pelo próprio pai da adolescente que a Target estava correta e sua lha adolescente já estava grávida. Ele apenas não sabia ainda da novidade naquela ocasião. Outras histórias como essa são comuns quando falamos sobre “Big Data”, porém sempre me lembro das seguintes questões: a privacidade da cliente foi respeitada? Mesmo com a informação correta, a empresa poderia sofrer alguma sanção legal? Em alguns casos, o excesso de informação não pode ser uma “desvantagem” competitiva em vez de ser uma vantagem? Muitas das respostas para essas questões ainda não são unânimes. Para tanto, o mercado tem investido na formação de pro ssionais dedicados a terem essas respostas. Matemáticos, estatísticos e advogados têm atuado em conjunto para proporcionarem as respostas mais unânimes possíveis. As tecnologias que sustentam “Big Data” podem ser analisadas sob duas visões: a primeira envolvida com as análises de dados de negócio, geralmente em ambientes de dados analíticos; a segunda com as tecnologias de infraestrutura, que armazenam e processam os petabytes1 de dados. Neste aspecto, destacam-se os bancos de dados NoSQL2. “Big Data” é a comprovação prática de que o enorme volume de dados gerados diariamente excede a capacidade das tecnologias atuais, geralmente baseadas em bancos de dados relacionais. Devemos ter em mente que “Big Data” envolve uma grande mudança na forma de trabalho das empresas e não somente uma pequena mudança na adoção de novas ferramentas ou tecnologias. As mudanças são amplas e envolvem aspectos legais, de privacidade e principalmente de Governança de Dados. Neste ponto, a adoção da Gestão de Dados é um importante instrumento para preparar as empresas para o fenômeno “Big Data”. 1.4.1. Como caracterizar o Big Data? Atualmente, os desa os do “Big Data” podem ser resumidos em cinco palavras ou dimensões, todas com as mesmas iniciais, mais conhecidas como as cinco dimensões “V” do “Big Data”. São elas: volume, velocidade, variedade, veracidade e valor. Vale ressaltar que as de nições sobre “Big Data” vêm sendo aprimoradas com o decorrer do tempo. Quando iniciei o desenvolvimento do projeto deste livro, o mercado entendia como desa os apenas três dimensões (volume, velocidade e variedade). Atualmente já são cinco. Portanto, não se assuste se, ao ler este livro, outros autores estiverem falando de uma ou duas dimensões a mais na de nição deste conceito. A imagem a seguir demonstra todas as cinco dimensões atuais do “Big Data”.

Figura 1.3 – Dimensões atuais do “Big Data”

1.4.2. Volume O volume é o primeiro desa o que as organizações enfrentam ao lidar com o “Big Data”. Corresponde à quantidade de dados armazenados, representados através do tamanho e da quantidade de registros/informações que um banco de dados possui. Quanto maior o volume, maiores os esforços na gestão dos dados. 1.4.3. Velocidade A velocidade é o desa o de lidar com o tempo rápido de resposta com que os novos dados são criados e os dados existentes, modi cados. Esses dados devem estar disponíveis imediatamente para operações de pesquisa e análise dos dados. São os dados em ação. 1.4.4. Variedade A variedade consiste nas implementações de dados que requerem tratamento de vários formatos e tipos, incluindo dados estruturados e não estruturados. Os bancos de dados devem ser capazes de analisar todos estes tipos de dados e fundi-los para produzir resultados de pesquisa e análise que não poderiam ser alcançados anteriormente. São os dados em múltiplas formas e representações. 1.4.5. Veracidade A veracidade consiste no grau de incerteza e inconsistência dos dados devido às ambiguidades, à baixa qualidade e à completeza dos dados. Representa a con abilidade dos dados. 1.4.6. Valor O valor corresponde ao retorno, nanceiro ou não, que um determinado conjunto de dados fornece à empresa. Atualmente, boa parte dos dados considerados “Big Data” são redundantes, incompletos ou simplesmente não agregam valor ao negócio da empresa. Se a empresa consegue

valorar os seus conjuntos de dados, ela consegue focar os esforços na gestão dos dados que dão maior retorno a ela. “Big Data” só faz sentido se o valor da análise dos dados compensar o custo de sua coleta, armazenamento e processamento.

1.5. Considerações finais sobre Big Data “Big Data” promete ser uma realidade nas empresas brasileiras. Seu potencial ainda não é totalmente reconhecido, porém já vemos sinais claros desta importância quando lemos diversos artigos de empresas e organizações internacionais sobre a adoção do “Big Data”. No Brasil, muito tem se falado sobre o assunto, principalmente os vendedores de soluções, porém os casos reais de utilização ainda são poucos. Estima-se que esta onda de crescimento chegue rapidamente no Brasil, porém tanto as empresas quanto os pro ssionais ainda não estão totalmente preparados para utilizar o melhor da tecnologia. A promessa de crescimento da tecnologia do “Big Data” e a falta de preparo dos pro ssionais não são exclusividade do Brasil. O Gartner prevê que, até 2015, a procura por recursos humanos relacionados com o assunto “Big Data” levará à criação de 4,4 milhões de empregos em todo o mundo, porém apenas um terço dos postos de trabalho será preenchido.

2. Gestão de Dados “Um ser inteligente traz consigo os meios necessários para superar-se a si mesmo.” Henri Bergson

2.1. Gestão de Dados – Definições A Gestão de Dados (Data Management) é também conhecida no mercado por diversos termos: Gestão da Informação (Information Management – IM). Gestão da Informação Empresarial (Enterprise Information Management – EIM). Gestão dos Dados Empresariais (Enterprise Data Management – EDM). Como os termos são diversos, as de nições também variam. Particularmente, pre ro utilizar as duas de nições a seguir: “Gestão de Dados é a disciplina responsável por de nir, planejar, implantar e executar estratégias, procedimentos e práticas necessárias para gerenciar de forma efetiva os recursos de dados e informações das organizações, incluindo planos para sua de nição, padronização, organização, proteção e utilização.”3 “Gestão de Dados é a função na organização que cuida do planejamento, controle e entrega dos ativos de dados e de informação. Esta função inclui: as disciplinas do desenvolvimento, execução e supervisão de planos, políticas, programas, projetos, processos, práticas e procedimentos que controlam, protegem, distribuem e aperfeiçoam o valor dos ativos de dados e informações.”4

Em suma, a disciplina Gestão de Dados é responsável por zelar da melhor forma possível, através de seus pro ssionais de tecnologia e também de negócios, os dados e metadados das organizações, fazendo com que sejam aderentes às necessidades do negócio, únicos, íntegros, con áveis, manuteníveis, conhecidos, performáticos, legíveis e disponíveis a quem realmente precisa ter o acesso. Os dados uem através da infraestrutura da TI e seus sistemas de gerenciamento e processamento de informações. Os pro ssionais da área de negócios consomem, alimentam e identi cam novas necessidades de informações. Portanto, nada mais apropriado que a responsabilidade por essa gestão ser compartilhada entre a TI e o negócio.

Apoiada por organizações internacionais voltadas para o desenvolvimento dos assuntos ligados à Gestão de Dados, tais como o Data Governance Institute e a DAMA® – Data Management International, aos poucos a Gestão de Dados vem surgindo no mercado brasileiro de forma muito mais abrangente, englobando funções anteriormente esquecidas ou mal gerenciadas pelas organizações. O escopo de atuação da disciplina “Gestão de Dados” e a escala de sua implementação nas empresas variam amplamente de acordo com o tamanho, os meios e a experiência das organizações. Por outro lado, a principal intenção da adoção da Gestão de Dados nas empresas geralmente é a mesma: fornecer mecanismos para utilizar o conhecimento das informações para tomar decisões ágeis e corretas. A Gestão de Dados é importante para as organizações independentemente do seu tamanho, área de atuação e nalidade.

2.2. Princípios que orientam a Gestão de Dados O guia DAMA-DMBOK® estabelece cinco princípios básicos que orientam a adoção da Gestão de Dados nas organizações. O conjunto desses princípios estabelece uma loso a de trabalho que deve sempre ser levada em consideração pelos pro ssionais que atuam nesta área. Os princípios estabelecidos pelo guia DAMA-DMBOK® são os seguintes: Dados e informações são ativos valiosos das organizações. Como todo ativo, os dados devem ser gerenciados, assegurando qualidade adequada, segurança, integridade, proteção, disponibilidade, compreensão e uso efetivo. A responsabilidade da Gestão de Dados é compartilhada entre os Gestores de Dados de Negócio e os pro ssionais de Gestão de Dados de Tecnologia. Gestão de Dados é uma disciplina de negócios e um conjunto de funções relacionadas. Gestão de Dados é uma pro ssão emergente e em amadurecimento.

2.3. Principais funções que compõem a disciplina Gestão de Dados As funções de Gestão de Dados são especialidades de trabalho especí cas ligadas de forma integrada com o propósito de efetivar por completo o gerenciamento de dados e informações. A versão atual do guia DAMA-DMBOK® estabelece dez funções primárias: Governança de Dados: função que representa o exercício da autoridade e o controle de estratégias, políticas, regras, procedimentos, papéis e atividades envolvidos com os ativos de

dados. A Governança de Dados é considerada a função central do framework e in uencia todas as demais funções do guia DAMA-DMBOK®. Gestão da Arquitetura de Dados: função responsável por de nir as necessidades de dados (geralmente corporativos) da empresa. A função também é responsável por criar e manter a Arquitetura Corporativa de Dados de acordo com os objetivos estratégicos da empresa. Gestão do Desenvolvimento dos Dados: função que representa as atividades de dados dentro do ciclo de desenvolvimento de sistemas, tais como: Modelagem de Dados (incluindo as avaliações em modelos de dados), análise de requisitos de dados, projeto de banco de dados, implantação e manutenção dos bancos de dados. Gestão de Operação de Dados: função responsável por manter armazenados os dados ao longo do seu ciclo de vida após a criação das estruturas para este propósito. O ciclo se inicia na criação e/ou aquisição dos dados e vai até o arquivamento nal ou a sua eliminação. Gestão da Segurança dos Dados: função responsável por de nir e manter as políticas de segurança e procedimentos a m de prover a adequada autenticação, utilização, acesso e auditoria de dados. Gestão de Dados Mestres e Dados de Referência: função responsável por de nir e controlar atividades para garantir a consistência e disponibilização de visões únicas dos dados mestres e de referência da empresa. Gestão de Data Warehousing e Business Intelligence: função responsável por de nir e controlar processos para prover dados de suporte à decisão, geralmente disponibilizados em aplicações analíticas. Gestão da Documentação e Conteúdo: função dedicada a planejar, implementar e controlar atividades para armazenar, proteger e acessar os dados não estruturados da empresa. Gestão de Metadados: função responsável por gerir e armazenar os metadados da empresa, além de viabilizar formas de acesso. Gestão da Qualidade dos Dados: função dedicada à gestão das atividades para aplicação de técnicas de Qualidade de Dados com o propósito de medir, avaliar, melhorar e garantir a qualidade dos dados da empresa. A próxima versão do guia DAMA-DMBOK® já prevê a inclusão de mais uma função em seu framework. Trata-se da função de Integração de Dados. Além disso, outras funções serão renomeadas para manter um melhor alinhamento com as atividades e os conceitos adotados pelo mercado, como o caso da função “Gestão do Desenvolvimento dos Dados”, que será renomeada para “Modelagem de Dados e Projeto”, e também a função “Gestão de Operação de Dados”, que será renomeada para “Armazenamento de Dados”. A gura a seguir demonstra as novas funções da próxima versão do guia DAMA-DMBOK®. Segundo a DAMA International, a previsão da divulgação completa da nova versão do guia é o

segundo quadrimestre de 20135.

Figura 2.1 – Novas funções do Guia DAMA-DMBOK® – Versão 2

A função Integração dos Dados é nova, por esta razão está representada na gura com fundos claros. Já as funções Modelagem de Dados e Projeto e Armazenamento dos Dados terão seus nomes e escopo alterados. Além das funções do DAMA-DMBOK® mencionadas na gura, também considero importantes outros conceitos que serão considerados como função de Gestão de Dados neste livro: Qualidade do Processo da Gestão de Dados: por trás de todo o esforço envolvendo a Gestão e a Governança de Dados existem processos de trabalho para suportar tais atividades. O monitoramento desses processos, com o intuito de ter uma melhoria contínua na Gestão dos Dados, é fundamental para garantir a existência da disciplina na empresa, identi car e resolver possíveis problemas, elevar a maturidade e reconhecer a área como um importante instrumento de apoio à estratégia da empresa. Comunicação: a comunicação está entre os principais motivos de sucesso ou fracasso nas iniciativas. Ela não serve apenas para divulgarmos e coletarmos informações. Serve também para veri carmos se algo cou claro e foi entendido pelo receptor da informação. Para isso, existem técnicas e boas práticas que, em conjunto, ajudam a melhorar a comunicação na empresa, tornando-se um fator de sucesso nas iniciativas de Gestão de Dados. Desenvolvimento Pro ssional: a disciplina propõe novos per s que, até então, eram desconhecidos no mercado de trabalho brasileiro. A capacitação contínua, através de conhecimentos adquiridos em artigos, eventos, congressos, cursos, certi cações e a ns, é fundamental para amadurecer a pro ssão do Gestor de Dados no Brasil. Todos esses conceitos estão inclusos no guia DAMA-DMBOK®, porém, para ns didáticos, serão tratados como funções neste livro. A gura a seguir mostra o conjunto de funções que serão mencionadas no conteúdo deste livro.

Figura 2.2 – Funções de Gestão de Dados na visão do autor

Esta gura representa uma casa onde a base é um alicerce dedicado à função de Arquitetura de Dados. Uma boa Arquitetura de Dados é a base necessária para o sustento de qualquer iniciativa de Gestão de Dados, pois aqui estarão representadas as principais entidades que serão compartilhadas entre as áreas de negócio. Tudo isto alinhado à estratégia, à Cadeia de Valor e aos macroprocessos adotados pela empresa. Já o telhado desta casa é representado pela Governança de Dados. Esta função estabelece as “regras do jogo” e dá a proteção e o reconhecimento necessários ao funcionamento das demais funções. As funções coloridas em caixas mais claras são cobertas pela versão atual do guia DAMADMBOK®. Já as funções coloridas com as caixas mais escuras são abordadas nas boas práticas da Gestão de Dados Moderna. Conforme mencionado anteriormente, a função “Integração de Dados” (não colorida) será incluída na nova versão do guia DAMA-DMBOK®. Todas essas funções serão discutidas mais adiante, sendo que algumas terão capítulos especí cos e outras não. As funções Governança de Dados, Arquitetura de Dados, Modelagem de Dados, Gestão de Dados Mestres e Qualidade de Dados estão contidas no guia DAMA-DMBOK® e serão mais bem detalhadas em capítulos especí cos. As funções Qualidade do Processo e Comunicação serão detalhadas dentro do conteúdo dos capítulos sobre a Gestão de Dados Moderna. Já o Desenvolvimento Pro ssional será tratado no último capítulo.

2.4. Principais ganhos na adoção da Gestão de Dados Os ganhos são muitos, alguns intangíveis, variam a cada empresa e, provavelmente, se mencionasse todos os ganhos possíveis, eles renderiam o espaço de vários capítulos deste livro. O levantamento desses ganhos de acordo com a realidade de cada empresa e a sua transformação em valores monetários é importante, pois a partir desta análise as atividades podem ser iniciadas ou

não. De forma geral, os executivos seniores das empresas não costumam patrocinar iniciativas de Gestão de Dados sem uma previsão detalhada do valor que será investido e também do retorno nanceiro sobre este investimento. Levar adiante tais iniciativas sem esses números, ou então com o retorno nanceiro menor do que o gasto previsto, signi ca que serão prontamente descartadas. Na visão dos executivos, se o mentor não sabe estimar e nem calcular o retorno da iniciativa, ele também não merece crédito e con ança para levá-la adiante. Portanto, evite se basear apenas em valores intangíveis, sem um ROI estimado. Contudo, chegar a este número mágico sobre o ROI não é uma tarefa simples. O levantamento do custo dos problemas ocorridos com a má gestão e a qualidade dos dados (multas e sanções recebidas ultimamente, por exemplo) é um bom início para se chegar a este valor, porém cuidado com a venda da iniciativa, pois a implantação da Gestão de Dados não resolverá instantaneamente todos esses problemas. Também deve ser levado em conta se a empresa precisa fornecer dados e informações para agências reguladoras ou se é auditada para veri cação de conformidades em relação a controles internos e governança (Basileia, Sarbanes-Oxley, etc.). Nesses casos, a aderência a esses requisitos é mandatória, devendo ser calculado o impacto (em custo) da não aderência a tais requisitos e critérios. Alinhadas a esses custos e características, as informações dos cases aplicados em empresas similares no mercado também costumam sensibilizar os executivos. Somente após a veri cação dos valores tangíveis é que devemos mencionar e, até de certa forma, se possível, estimar os valores intangíveis. Somados os valores, deve-se submeter a iniciativa para aprovação. Atualmente, os recursos tanto nanceiros como de pessoas nas empresas estão cada vez mais escassos – em muitos casos, iniciativas com bons retornos são colocadas na la de espera por falta de recursos ou então por razões de alinhamento com a estratégia empresarial vigente. Portanto, atenção com as características a seguir: Ter um planejamento onde o custo da iniciativa é menor que o retorno também não signi ca que esta será aprovada. Igualdade de custo: caso a empresa perca cem milhões de reais em dez anos devido à má gestão e à qualidade dos dados manipulados, porém gaste os mesmos cem milhões ou mais no decorrer dos dez anos seguintes para reverter esse cenário, não haverá retorno nanceiro algum nessa iniciativa. Ou seja, provavelmente a iniciativa não será levada adiante.

Além disso, vale ressaltar que os benefícios não são atingidos em sua totalidade logo após a implantação da Gestão de Dados nas empresas, e sua curva (planejada) deve ser considerada na avaliação do investimento. A gura a seguir mostra um exemplo de custos do projeto e custos operacionais da implantação da Gestão de Dados em uma empresa. Apesar dos benefícios começarem a aparecer durante a implantação do projeto, eles só foram atingidos totalmente depois de alguns anos após a sua conclusão.

Figura 2.3 – Exemplo de custos do projeto x custos operacionais e benefícios obtidos com a Gestão de Dados

Apesar de a maioria dos benefícios ser diferente em cada empresa, alguns poucos ainda são comuns à maioria. Seguem os principais ganhos que normalmente são obtidos em todas as organizações que começam a adotar a Gestão de Dados em seu cotidiano. Muitos deles são intangíveis. Mudança de cultura. Dados e informações passam a ser reconhecidos como um importante ativo estratégico nas empresas. Melhor alinhamento entre as áreas de TI e de negócio. Este alinhamento é uma premissa fundamental para o bom funcionamento da Gestão de Dados. Com isso, outras áreas como, por exemplo, de mapeamento de processos e de desenvolvimento de sistemas podem se bene ciar de um alinhamento já iniciado. A gestão das operações de captura, armazenamento, proteção, planejamento, controle e garantia da qualidade dos ativos de dados são centralizadas em uma única disciplina: a Gestão de Dados. Com a centralização das operações, os custos tendem a cair, pois os recursos são mais bem aproveitados e a ocorrência de retrabalho diminui. Criação da cultura do uso de indicadores de processo, qualidade e desempenho de dados e informações. Esta cultura é importante para manter a Gestão de Dados alinhada à estratégia da empresa. Conhecimento de dados e informações utilizados através da adoção de um vocabulário único sobre as de nições dos dados que circulam na empresa. Dessa forma, há uma melhor disseminação do conhecimento entre as pessoas – passagem do capital intelectual para o capital estrutural.

Entendimento das principais necessidades de dados e informações da empresa, fornecendo um importante subsídio para estabelecer o planejamento para absorção, criação e/ou transformação de novos dados e informações para a empresa. Dessa forma, a empresa tem condições de de nir o que realmente é importante em relação à utilização de dados e informações e estabelecer prioridades em relação às futuras implementações e mudanças. Redução no tempo e no custo de desenvolvimento de novos sistemas e aplicações. Esta redução é obtida devido à adoção de arquiteturas de dados mais estáveis e processos que envolvem a criação e alteração de modelos de dados. Redução dos riscos e falhas no desenvolvimento dos sistemas e aplicações. Eliminação ou redução drástica na quantidade de informações redundantes, contribuindo para reduzir os esforços em manter íntegras as informações que antes eram redundantes. Estabelecimento de mecanismos formais de segurança, acesso e disponibilização de dados e informações a quem realmente necessita. Tudo isso de forma rápida e segura. Reutilização de dados corporativos e/ou compartilhados, através do gerenciamento dos dados mestres e dados de referência, contribuindo dessa forma para a melhoria da qualidade dos dados e também reduzindo os esforços, tempos e custos das aplicações. Melhoria na qualidade e con abilidade dos dados e informações através do uso de dados cada vez mais claros, precisos, íntegros, integrados, pertinentes e oportunos. Os dados manipulados nas empresas passam a ser realmente governados. Ou seja, o exercício de autoridade e controle (planejamento, monitoramento e execução) sobre a gestão de ativos de dados é real. Isso é fundamental para a empresa se adaptar a regulamentações externas como a lei Sarbanes-Oxley e Basileia. Aumento da produtividade das pessoas que utilizam os dados e as informações.

2.5. Gestão de Dados ou Administração de Dados – Qual o termo correto? Quando a disciplina Administração de Dados começou a ser adotada no Brasil, e durante muito tempo após sua implementação, uma dúvida comum entre as pessoas era a diferenciação entre os papéis do AD (Administrador de Dados) e do DBA (Administrador de Banco de Dados). Com a evolução da maturidade e a adoção da Administração de Dados nas empresas essa dúvida começou a deixar de existir. Mesmo assim, algumas empresas ainda insistem em adotar um papel único para a atuação dos dois per s, mesmo sendo totalmente diferentes. A principal dúvida na área de dados se refere atualmente à utilização de dois conceitos: Administração de Dados e Gestão de Dados. A nal, qual o termo correto? Gestão de Dados é um conceito mais recente e também mais amplo do que Administração de Dados. Apesar de a matéria-prima ser a mesma, o dado, e ambas estarem ligadas à qualidade de

dados e informações, na prática a Gestão de Dados difere da Administração de Dados principalmente porque a Gestão de Dados tem uma proposta de atuação mais abrangente, incorporando atividades que antes não eram previstas pelas áreas de Administração de Dados. De forma geral, a Administração de Dados foca especi camente no controle, na qualidade e no gerenciamento das estruturas dos metadados da organização. Geralmente esses metadados estão representados em modelos de dados. Basicamente, os processos de Administração de Dados podem ser resumidos em: Manter modelos de dados armazenados em repositórios, disponibilizando-os aos interessados quando necessário. Modelar ou apoiar a construção e/ou alteração dos modelos de dados. Homologar os modelos de dados produzidos por analistas e/ou outros Administradores de Dados. Implementar as estruturas de dados nos bancos de dados após a homologação dos modelos de dados produzidos. Disseminar conceitos existentes nos modelos de dados mantidos pela equipe. Processos internos para a própria equipe de Administração de Dados, como criar mnemônicos e auditar repositório de modelos de dados. Infelizmente, o modelo de trabalho de Administração de Dados adotado por muitas empresas brasileiras ainda é baseado em uma única “receita de bolo” implantada com o apoio de poucas consultorias no mercado, geralmente com seus processos ligados a uma ferramenta de Modelagem de Dados especí ca. Outras empresas possuem seus modelos de trabalho baseados nas publicações americanas da década de 90, tais como “Data Administration Standards & Techniques” e “Manual For Data Administration”. Com raras exceções, onde a área de Administração de Dados está localizada dentro da área de negócio da empresa, geralmente a área de TI é a responsável por executar as funções de Administração de Dados. Nesses casos, nem sempre a interação entre a TI, representada pela área de Administração de Dados, e a área de negócios da empresa é feita ou pelo menos incentivada. A pouca exibilização em seus processos e o distanciamento das novas tecnologias e da área de negócio corroboraram para o declínio da Administração de Dados nas organizações. Apesar de extremamente importante e fundamental para manter uma organização mínima sobre o acervo dos dados e metadados, o escopo de atuação da Administração de Dados não vem dando mais o retorno desejado pelas organizações. En m, já passou da hora da Administração de Dados se reinventar. O termo “Administração de Dados” está em desuso e atualmente seu nome pode gerar inclusive ojeriza em algumas empresas. Esta frase pode parecer um pouco forte, mas, se zermos

uma análise criteriosa do problema, fatalmente chegaremos à mesma conclusão: a Administração de Dados gere os metadados e não os dados das organizações. Já a Gestão de Dados se propõe a gerir não somente os metadados (e seus modelos de dados) da organização, como também fazer a gestão completa dos dados, incluindo todo o seu ciclo de vida e funções antes ignoradas ou não tão bem atendidas pela Administração de Dados, tais como governança dos dados, armazenamento, integração, gestão dos dados mestres e de referência, segurança, qualidade dos dados e Gestão de Dados não estruturados. Em suma, a Gestão de Dados chegou para administrar os metadados e também os dados das empresas. Outra diferença trivial é a responsabilidade pela gestão dos recursos de dados. A Gestão de Dados é compartilhada entre pro ssionais de Gestão de Dados da TI e os Gestores de Dados de Negócio, que representam os interesses coletivos dos produtores de dados e dos consumidores de informação. O gerenciamento dessas funções é apoiado pelo guia DAMA-DMBOK®, guia de boas práticas coordenadas com funções integradas para o gerenciamento de dados, metadados e ativos de informação nas organizações. Conforme já mencionado neste livro, a versão atual do guia DAMA-DMBOK® abrange o gerenciamento de dez funções integradas: Governança de Dados, Arquitetura de Dados, desenvolvimento dos dados, operações de banco de dados, segurança de dados, dados mestres e de referência, data warehousing e business intelligence, documentação e conteúdo, metadados e Qualidade de Dados. Algumas das funções relacionadas nunca entraram no escopo da Administração de Dados. Aliado a isso, novas loso as de trabalho como a Gestão de Dados Moderna, caracterizada por uma forma de trabalho mais ágil e proativa focada na conduta comportamental dos pro ssionais envolvidos nas funções de Gestão de Dados, ajudam a ter uma visão mais abrangente da empresa, não focada somente em bancos de dados e tecnologia. Todos esses instrumentos ajudam a apagar a imagem desgastada da Administração de Dados do passado e reconhecer a Gestão de Dados como importante meio para gerenciar os ativos de dados e informações das organizações.

2.6. Mitos sobre a Gestão de Dados Com o passar do tempo, as áreas e os pro ssionais de Administração de Dados serão extintos?

Não. A tendência natural é evoluir para trabalhar com escopos de atuação mais abrangentes e alinhados às estratégias das áreas de negócio das empresas. Este processo de evolução já ocorreu nos países mais desenvolvidos na área de dados e já está acontecendo em algumas empresas brasileiras. É a migração da Administração de Dados para a Gestão de Dados.

Já os pro ssionais de Administração de Dados devem estar atentos a esta mudança. A Gestão de Dados trouxe à tona a necessidade de novos per s, ligados à área de negócio das empresas. O pro ssional de Gestão de Dados deverá ser versátil, capaz de assimilar rapidamente a adoção de novos conceitos e tecnologias. Se o Administrador de Dados car limitado à antiga forma de trabalho, focada somente nas atividades de modelagem e avaliações de modelos de dados, certamente ele encontrará di culdades de alocação em um futuro bem próximo. A Gestão de Dados deve obrigatoriamente ser adotada em toda a empresa? Todas as áreas devem ser contempladas?

A melhor prática recomendada é a adoção da Gestão de Dados em toda a empresa. Entretanto, ela pode ser adotada em contextos locais (áreas do negócio ou de projetos especí cos), sem uma aplicação na organização como um todo. Vale ressaltar que, neste caso, o benefício para o negócio da empresa será menor, pois uma das principais vantagens da Gestão de Dados é estabelecer um tratamento único e corporativo sobre os dados manipulados na empresa. Quando implantamos a Gestão de Dados na empresa devemos implantar todas as funções recomendadas pelo guia DAMA-DMBOK®?

Não. O guia é uma coletânea de boas práticas. Dependendo das características das empresas, algumas práticas podem não ser necessárias, outras podem ser adotadas parcialmente, adaptadas ou adotadas integralmente. Além disso, pode-se estabelecer uma cadeia de prioridades onde as funções e atividades mais prioritárias são adotadas de forma incremental. Implementar a Gestão de Dados em toda a empresa de uma única vez não é uma prática recomendada. A experiência me mostrou que as iniciativas implantadas em partes e testadas através de adoções “piloto” foram as iniciativas com maiores índices de sucesso. Portanto, mesmo que a empresa adote a Gestão de Dados como um todo, durante um bom tempo a adoção da disciplina não será total e sim parcial, devido a uma estratégia de implantação mais coerente com a realidade das empresas. Gestão de Dados e Administração de Dados podem conviver juntas?

Sim. Inclusive algumas empresas têm usado este formato em fases iniciais de adoção da Gestão de Dados, porém deve-se ter em mente que a Administração de Dados é um subconjunto da Gestão de Dados e, como tal, deve seguir as mesmas diretrizes e estar alinhada com os mesmos objetivos da Gestão de Dados. Relembrando: a Administração de Dados geralmente está ligada às atividades de modelagem, homologação e guarda dos modelos de dados.

3. Papéis Envolvidos na Gestão de Dados “O único lugar onde o sucesso vem antes do trabalho é no dicionário.” Albert Einstein

3.1. Tipos de papéis envolvidos Até pouco tempo atrás, “Administrador de Dados – AD” e “Administrador de Banco de Dados – DBA” eram os principais e mais conhecidos papéis ligados às atividades de gerenciamento dos dados nas organizações. Embora importante, o papel do AD não era mais su ciente para fazer o alinhamento entre a tecnologia e as necessidades dos negócios nas empresas. Com o ressurgimento da Gestão de Dados nas organizações, onde o dado é considerado um dos principais ativos empresariais, novos papéis surgiram no mercado com o propósito de fazer um melhor alinhamento entre a TI, responsável por custodiar os dados das empresas, e a área de negócio, real proprietária dos dados que circulam nas empresas. Atualmente podemos classi car esses novos papéis em três grupos distintos: Papéis ligados ao negócio. Papéis estratégicos. Papéis técnicos ou de tecnologia. Este livro abordará os principais papéis que, de forma geral, são adotados nas organizações brasileiras. Vale ressaltar que, dependendo das características de cada empresa, não haverá espaço para adoção de alguns papéis, ou até mesmo os papéis relacionados não serão totalmente su cientes. O próprio guia DAMA-DMBOK® estabelece uma gama de mais de vinte papéis de atuação em Gestão de Dados. Além disso, dependendo das características das pessoas e das empresas, uma mesma pessoa pode atuar em mais de um papel, se necessário. A gura a seguir relaciona os tipos e papéis de Gestão de Dados que serão descritos neste livro.

Figura 3.1 – Papéis da Gestão de Dados abordados no livro

3.2. Papéis ligados ao negócio Todos os papéis deste grupo possuem uma forte atuação dentro da área de negócio nas empresas. À exceção do Gestor da Informação, todos os demais papéis são relativamente novos e buscam suprir duas carências que foram fundamentais no passado para levar algumas áreas de Administração de Dados ao desuso: A falta de interação com a área de negócio. A de nição dos responsáveis diretos pelos dados levando em consideração as reais necessidades do negócio. Como a maioria dos papéis é relativamente nova nas empresas, o número de pro ssionais quali cados para exercer as funções disponíveis no mercado ainda é pequeno. Com isso, as empresas têm buscado formar os pro ssionais dentro de seus próprios quadros. Mesmo assim ainda existem algumas dúvidas sobre quais são os requisitos básicos necessários para selecionar e/ou treinar pro ssionais para atuarem nesses papéis. De forma geral, devem atender aos seguintes requisitos: Formação superior, preferencialmente em áreas ligadas ao negócio da empresa em que o pro ssional de Gestão de Dados irá atuar. Experiência (vivência) anterior nas áreas de negócio onde irá atuar. Fortes conhecimentos em Gestão Estratégica e Governança de Dados.

Possuir forte visão estratégica. Conhecimentos avançados em Qualidade. Conhecimentos de ferramentas de gestão. Habilidade na comunicação verbal e escrita. Negociação e gestão de con itos. Além dos requisitos básicos, outros são necessários de acordo com os papéis que serão desempenhados. A relação dos demais requisitos será mencionada adiante, logo após o detalhamento das principais atividades executadas por cada papel. 3.2.1. Gestor de Dados de Negócio Também conhecido como Data Steward, o Gestor de Dados de Negócio é o pro ssional ligado à área de negócio da empresa. Trabalha e atua como o principal curador dos dados, representando os interesses da área de negócio em que atua. O per l desejado é de uma pessoa especialista na área de negócio onde atua. O pro ssional também deve ter conhecimentos avançados em Gestão e Governança de Dados para poder interagir com os pro ssionais desta disciplina e com os Gestores da Informação e demais pro ssionais de negócio. Além disso, deve ter pleno domínio sobre a captura de requisitos de informação, regras de negócio e modelagem conceitual de dados. Entre suas principais tarefas podemos destacar: Participar dos comitês de Gestão e Governança de Dados que envolvem sua área. Identi car e de nir necessidades de informações locais e corporativas representando os interesses dos produtores e consumidores de dados da área de negócios. Propor modelos conceituais de dados respeitando as regras e os padrões da Arquitetura Corporativa de Dados da empresa. Garantir a validade e a relevância dos modelos conceituais de dados sob sua responsabilidade. Ajudar executivos a identi car e apontar os Gestores das Informações. Manter valores e signi cados dos dados de referência. Identi car e atuar na resolução de problemas com os dados. De nir critérios de qualidade dos dados. Certi car-se de que os recursos de dados estão de acordo com as necessidades do negócio, garantindo a qualidade dos dados e metadados. Atuar como ponto focal (referência) de negócio perante os demais pro ssionais de Gestão de Dados.

3.2.1.1. Principais características para atuar neste papel Além das características gerais dos papéis de negócio, também são requisitos importantes para atuar como Gestor de Dados de Negócio: Conhecimento aprofundado das áreas onde irá atuar. Conhecimentos avançados em Gestão de Dados. As Certi cações em Gestão de Dados ajudam a atestar esses conhecimentos. Persistência. Domínio em modelagem conceitual. Conhecimento de Gerenciamento de Projetos. Conhecimento de Segurança da Informação. 3.2.2. Coordenadores e gerentes das equipes de Gestão de Dados de Negócio De forma geral, são pro ssionais seniores, com conhecimento avançado no ramo de negócio onde atuam. No passado já atuaram como Administradores de Dados (AD) ou especialistas. Além de serem os gestores das pessoas, também trabalham como facilitadores para que as suas equipes consigam cumprir os objetivos estabelecidos. Entre suas principais tarefas podemos destacar: Participar de um ou mais comitês de Gestão e Governança de Dados. Planejar, alocar, distribuir e controlar as tarefas dos membros da equipe. Administrar os recursos humanos da equipe. Remover empecilhos que afetem a qualidade e/ou produtividade da equipe. Liderar projetos sob a responsabilidade da equipe. 3.2.2.1. Principais características para atuar neste papel Além das características gerais dos papéis de negócio, também são requisitos importantes para atuar como Coordenador ou Gerente das equipes de Gestão de Dados de Negócio: Experiência em gestão de equipes multidisciplinares. Conhecimentos avançados de Gestão de Dados. Conhecimentos avançados de Gerenciamento de Projetos. Conhecimentos gerais de Tecnologia. Visão estratégica.

3.2.3. Gestor da Informação Pro ssional de negócio que representa a área proprietária da informação. Na prática, é o “dono” dos dados. Este pro ssional está ligado a uma ou mais áreas da empresa. Não costuma possuir per l técnico e suas atividades em relação aos dados são apoiadas pelo Gestor de Dados de Negócio. Apesar de já ser um papel conhecido, de forma geral o Gestor da Informação não era um papel formalizado antes da adoção da Gestão de Dados nas empresas. Mapeava-se e de nia-se um gestor para cada informação e pronto. Não havia uma preocupação em de nir dentro de uma metodologia o seu papel, a sua importância, abrangência de atuação e responsabilidades. Entre suas principais tarefas podemos destacar: Autorizar o acesso e compartilhamento dos dados e metadados sob sua responsabilidade. Tomar decisão em relação à correção das inconsistências dos dados sob sua responsabilidade. Com o apoio do Gestor de Dados de Negócio, de nir prioridades em relação à aquisição e utilização de novos dados. Envolver o Gestor de Dados de Negócio nas atividades que envolvam algum tipo de decisão acerca do uso dos dados que estão sob sua responsabilidade. 3.2.3.1. Principais características para atuar neste papel Além das características gerais dos papéis de negócio, também são requisitos importantes para atuar como Gestor da Informação: Conhecimento aprofundado da área onde atua. Conhecimentos de Segurança da Informação. Comprometimento. Responsabilidade. Ser reconhecido de fato como pro ssional de fácil acesso e disponibilidade.

3.3. Papéis estratégicos Os papéis deste grupo são novos e aos poucos vêm sendo adotados pelas organizações que estão em processo de implementação da disciplina Gestão de Dados. Seus principais objetivos são promover a intermediação entre TI e o negócio e resolver con itos entre estas áreas nos patamares táticos e estratégicos. Como os papéis são novos nas empresas, ainda existem algumas dúvidas sobre quais são os requisitos básicos necessários para selecionar e/ou treinar pro ssionais para atuarem nestes papéis. De forma geral, os pro ssionais que atuam nestes papéis devem atender aos seguintes requisitos:

Formação superior, preferencialmente em áreas ligadas ao negócio da empresa ou tecnologia. Experiência (vivência) anterior em pelo menos umas das áreas onde atuará como mediador. Fortes conhecimentos em Gestão Estratégica e Governança de Dados. Possuir forte visão estratégica. Conhecimentos de ferramentas de gestão. Habilidade na comunicação verbal e escrita. Negociação e gestão de con itos. Outros requisitos são necessários de acordo com os papéis que serão desempenhados. A relação dos demais requisitos será mencionada à frente, logo após o detalhamento das principais atividades executadas por cada papel. 3.3.1. Executivo de Gestão de Dados O executivo de Gestão de Dados, também conhecido como CDO (Chief Data Officer), atua nos níveis de direção das organizações e geralmente se reporta ao Presidente ou Vice-Presidente das organizações. É o responsável direto por gerenciar todas as funções de gestão e Governança de Dados nas empresas. Além de atuar nos níveis mais altos da empresa, este papel também tem forte atuação política. Um bom CDO deve estar familiarizado com este tipo de atuação, para que, com sua in uência, consiga quebrar paradigmas e possíveis resistências que as equipes de dados possam enfrentar dentro da empresa. O CDO é o principal responsável por, entre outras coisas, fornecer apoio constante às equipes de Gestão de Dados, de nir as prioridades estratégicas para a empresa no que tange à utilização dos dados e informações, identi car novas oportunidades de negócios relativos aos dados e aperfeiçoar a geração de receita por meio da utilização dos dados. Além disso, é o principal responsável pela representação e promoção dos dados como um ativo estratégico de negócios na esfera executiva da empresa. Entre suas principais tarefas podemos destacar: Participar como membro ativo do conselho de Gestão e Governança de Dados, sendo um dos principais facilitadores deste grupo. De nir e acompanhar o andamento da estratégia de Gestão e Governança de Dados adotada na empresa. Homologar e aprovar, apoiado por pro ssionais da área, a metodologia de Gestão e Governança de Dados da empresa.

Homologar e aprovar, apoiado por pro ssionais da área, a Arquitetura de Dados adotada pela empresa. Representar as equipes de Gestão e Governança de Dados na empresa. Representar a empresa perante as agências reguladoras e demais entidades externas em assuntos referentes a dados e informações da empresa. Patrocinar os projetos de melhoria sob a responsabilidade das equipes de Gestão e Governança de Dados. 3.3.1.1. Principais características para atuar neste papel Além das características gerais dos papéis estratégicos, também são requisitos importantes para atuar como Executivo de Gestão de Dados: Experiência em gestão de equipes multidisciplinares. Noções de contabilidade gerencial e custos. Domínio dos conceitos de arquitetura empresarial. 3.3.2. Gestor Estratégico de Dados Pro ssional sênior com profundos conhecimentos de Gestão de Dados e também da área de negócio da empresa. É a principal referência em Gestão de Dados na organização. É uma espécie de “Super Data Steward”. Este per l é fundamental quando a empresa possui áreas de negócio diferentes e os Gestores de Dados de Negócio não possuem o conhecimento comum de todos os negócios. Nesses casos, o Gestor Estratégico de Dados também atua como um centralizador de conhecimento. O Gestor Estratégico de Dados pode ser alocado tanto no lado da TI quanto no lado do negócio, porém, não deverá esquecer que sua principal missão, onde estiver situado, é promover o correto alinhamento das áreas de TI e negócio sob a ótica dos dados utilizados pela empresa. Além disso, é o principal responsável por propor soluções corporativas, orientar e treinar os demais pro ssionais de Gestão de Dados (técnicos e de negócio). Também atua como consultor apoiando as ações dos Coordenadores/Gerentes e o CDO da empresa. Entre suas principais tarefas podemos destacar: Elaborar e, quando necessário, propor mudanças na metodologia de Gestão e Governança de Dados adotada pela empresa. Manter a Arquitetura de Dados corporativa da empresa e propor mudanças quando necessário. Prover de nições padrões para o vocabulário de Gestão e Governança de Dados, papéis e outras terminologias adotadas na empresa.

De nir, analisar e monitorar os indicadores de qualidade das estruturas de dados da organização. Propor ações em função dos indicadores analisados. Participar dos Comitês de Gestão de Dados. Construir consenso na visão geral sobre a aplicação da Gestão de Dados e disseminar pela organização os benefícios da Gestão e Governança de Dados. 3.3.2.1. Principais características para atuar neste papel Além das características gerais dos papéis estratégicos, também são requisitos importantes para atuar como Gestor Estratégico de Dados: Conhecimento aprofundado das áreas onde irá atuar. Conhecimentos avançados de Gestão de Dados. As certi cações em Gestão de Dados ajudam a atestar esses conhecimentos. Sólida experiência em Gestão de Dados. Não há sentido algum em haver Gestores Estratégicos de Dados juniores nas empresas. Experiência no uso de ferramentas de qualidade. Conhecimento avançado de Gerenciamento de Projetos. Domínio de Modelagem de Dados. Persistência. Boa didática.

3.4. Papéis técnicos De forma geral, grande parte das atividades descritas nos papéis a seguir já era efetuada pelos papéis AD (Administrador de Dados) e DBA (Administrador de Banco de Dados) na antiga área de Administração de Dados, ou seja, não há novidade alguma. Para manter um melhor alinhamento da proposta de atuação e evolução da área de Gestão de Dados, o papel AD passou a ser denominado “Gestor Técnico de Dados”. Já a adoção do per l “Arquiteto de Integração” tornou-se mais evidente após a chegada do paradigma SOA6 pelas empresas. Vale ressaltar que, mesmo distantes do negócio, os papéis técnicos da Gestão de Dados são fundamentais para manter os objetivos desta disciplina nas empresas. Os papéis técnicos estão situados em geral dentro de TI, mais próximos das pessoas que desenvolvem as soluções de tecnologia na empresa.

Os papéis técnicos requerem especializações especí cas dentro de cada área de atuação, porém, dependendo da forma de atuação da Gestão de Dados na empresa e de similaridades entre alguns papéis, uma mesma pessoa pode desempenhar mais de um papel dentro de uma equipe de Gestão Técnica de Dados. Ao contrário dos papéis estratégicos e de negócio, os papéis técnicos não são tão novos assim. Contudo, as empresas devem estar atentas aos requisitos básicos para os pro ssionais atuarem nesses papéis. Entre eles podemos destacar: Formação superior, preferencialmente ligada às áreas de TI. Noções de Modelagem de Dados. O modelo de dados ainda é o principal artefato ligado à gestão técnica de dados. Não há sentido contratar pro ssionais para atuar nesta área que não conheçam as técnicas e os propósitos da Modelagem de Dados. Experiência anterior em outros papéis ligados à TI. Fortes conhecimentos de Gestão e Governança de Dados. Outros requisitos são necessários de acordo com o papel que será desempenhado. A relação dos outros requisitos será mencionada à frente, logo após o detalhamento das principais atividades executadas por cada papel. 3.4.1. Coordenadores e gerentes das equipes de Gestão Técnica de Dados De forma geral, são pro ssionais seniores com conhecimento técnico em Gestão de Dados. No passado já atuaram como Administradores de Dados (AD) ou Administradores de Banco de Dados (DBA). Além de serem os gestores das pessoas, também trabalham como facilitadores para que as suas equipes consigam cumprir os objetivos estabelecidos. Entre suas principais tarefas podemos destacar: Participar em um ou mais comitês de Gestão de Dados. Planejar, alocar, distribuir e controlar as tarefas dos membros da equipe. Administrar os recursos humanos da equipe. Remover empecilhos que afetem a qualidade e/ou produtividade da equipe. Liderar projetos sob a responsabilidade da equipe. 3.4.1.1. Principais características para atuar neste papel Além das características gerais dos papéis técnicos, também são requisitos importantes para atuar como Coordenador ou Gerente das equipes de Gestão Técnica de Dados:

Experiência em gestão de equipes multidisciplinares. Conhecimentos avançados de Gestão de Dados. Conhecimentos avançados de Gerenciamento de Projetos. Conhecimentos gerais de Tecnologia. Visão estratégica. 3.4.2. Gestor Técnico de Dados Este per l vem a ser uma evolução do antigo “Administrador de Dados – AD”. É o principal responsável pela qualidade das estruturas dos metadados da organização. Possui conhecimento avançado de técnicas de Modelagem de Dados, utilização de ferramentas de modelagem, repositório de metadados e demais funções de Gestão de Dados, entre elas: Governança de Dados, Qualidade de Dados, Gestão de Dados mestres e referência, integração de dados e segurança da informação. Entre suas principais tarefas podemos destacar: Acompanhar e orientar as equipes de desenvolvimento durante a Modelagem de Dados (conceitual lógica e física). Avaliar os modelos de dados produzidos pelas equipes de desenvolvimento. Apoiar na busca e utilização de informações corporativas e compartilhadas. Disseminar os conceitos das entidades representadas nos modelos de dados. Manter atualizado os repositórios de modelos de dados e metadados. Propor mudanças na Arquitetura de Dados da empresa. Realizar estudos sobre a análise de impacto das alterações propostas nos modelos de dados compartilhados. Emitir relatórios técnicos e pareceres sobre o uso dos metadados nos âmbitos conceitual e lógico. Apoiar os demais pro ssionais da empresa nas atividades referentes à Qualidade de Dados e Gestão de Dados mestres e de referência. Promover no âmbito técnico a importância da Gestão de Dados. Envolver os demais pro ssionais (DBA, Arquiteto de Dados) quando necessário. Apoiar os Gestores Estratégicos de Dados na elaboração e alteração de: Vocabulário e Glossário Corporativo da empresa. Metodologia de Gestão e Governança de Dados. Demais documentos relativos à Gestão de Dados.

3.4.2.1. Principais características para atuar neste papel

Além das características gerais dos papéis técnicos, também são requisitos importantes para atuar como Gestor Técnico de Dados: Conhecimentos avançados em Gestão de Dados. Habilidade no levantamento e na compreensão de requisitos. Conhecimentos de mapeamento de processos. Conhecimentos avançados de técnicas de análise e Modelagem de Dados. Conhecimento intermediário de banco de dados (teoria e uso dos principais objetos). Habilidades avançadas no uso de ferramentas de Gestão de Dados (ferramentas de modelagem, repositório de metadados e ativos de TI, ferramentas de Qualidade de Dados, ferramentas MDM7). Conhecimento de técnicas de integração de dados. Habilidades avançadas em comunicação e negociação. Boa comunicação escrita. Persistência. Boa didática. 3.4.3. Administrador dos Repositórios de Metadados Pro ssional de TI especialista em repositórios de modelos de dados e metadados. É responsável direto pela custódia dos metadados e modelos de dados armazenados nessas ferramentas. Entre suas principais tarefas podemos destacar: Incluir, excluir e alterar os metadados técnicos e de negócio nos repositórios de metadados utilizados na organização. Disponibilizar os metadados armazenados nos repositórios. Conceder ou excluir acesso aos metadados armazenados nos repositórios. Orientar os demais pro ssionais de Gestão de Dados na utilização dos repositórios de metadados da empresa. Ser o ponto focal entre a área de Gestão de Dados e os fabricantes de soluções para armazenamento de modelos de dados e metadados. 3.4.3.1. Principais características para atuar neste papel Além das características gerais dos papéis técnicos, também são requisitos importantes para atuar como Administrador de Repositório de Metadados:

Conhecimentos avançados na utilização e administração de repositórios de metadados. Conhecimento intermediário em banco de dados (teoria e uso dos principais objetos). Domínio da linguagem SQL. 3.4.4. Projetista de Dados Pro ssional especialista em Modelagem de Dados, sendo o principal responsável por construir, ajustar e re nar o modelo de dados conforme a técnica de desenvolvimento adotada. Além disso, trabalha em parceria com o Arquiteto de Integração de Dados para de nir e representar os mecanismos de integração que serão utilizados no projeto. Entre suas principais tarefas podemos destacar: Criação e alteração dos modelos lógico e físico de dados. Armazenar modelos de dados propostos nos repositórios. Encaminhar os modelos de dados criados e/ou alterados para avaliação dos Gestores Técnicos de Dados. Envolver os Gestores de Dados (técnicos e de negócio) na construção e validação dos modelos de dados e mecanismos de consumo de dados especi cados. Fazer engenharias reversas para criação de modelos de dados de sistemas legados. 3.4.4.1. Principais características para atuar neste papel Além das características gerais dos papéis técnicos, também são requisitos importantes para atuar como Projetista de Dados: Habilidade no levantamento e na compreensão de requisitos. Conhecimentos avançados de técnicas de análise e Modelagem de Dados. Conhecimento intermediário de banco de dados (teoria e uso dos principais objetos). Conhecimento de tecnologia de integração de dados. Habilidade na utilização de ferramentas CASE8 e/ou ferramentas de Modelagem de Dados. Conhecimento de técnicas de integração de dados. Habilidades avançadas em comunicação e negociação. 3.4.5. Administrador de Banco de Dados (DBA) Pro ssional de TI com per l bastante técnico. Especialista em sowares de gerenciamento de bancos de dados.

Geralmente este per l é dividido em dois: DBA de aplicação e DBA de infraestrutura, também conhecido como DBA de produção. O primeiro é responsável por elaborar e/ou validar o projeto físico das aplicações e apoiar os analistas e desenvolvedores nas manipulações dos dados mantidos nos SGBDs. Já o segundo é responsável por manter e administrar o projeto físico de nido e monitorar os ambientes de dados mantidos pela empresa. Segue relação das principais atividades dos dois papéis. 3.4.5.1. DBA de Aplicação Elaborar o projeto físico de dados. Apoiar os analistas e desenvolvedores nas manipulações de dados mantidos nos SGBDs. Suporte na construção e otimização de código (SQL). Suporte na utilização e manipulação dos SGBDs. Criação de estruturas nos SGBDs. Tuning de aplicações nos ambientes de desenvolvimento e testes. 3.4.5.1.1. Principais características para atuar como DBA de Aplicação Além das características gerais dos papéis técnicos, também são requisitos importantes para atuar como DBA de Aplicação: Conhecimentos avançados de administração de banco de dados. Conhecimentos avançados em banco de dados (teoria, conceitos, arquitetura de SGBD e utilização dos objetos). Conhecimentos avançados em SQL e tuning de queries e stored procedures. Conhecimentos de Modelagem de Dados. Habilidade no uso de ferramentas de Modelagem de Dados. Didática. 3.4.5.2. DBA de Infraestrutura Criação de usuários e permissões de acesso no SGBD. Administração e monitoração de servidores de banco de dados. Manter a organização física do SGBD. Backup e recovery de dados. Instalação, con guração, manutenção e suporte ao uso do SGBD. Tuning de aplicações nos ambientes de homologação e produção.

3.4.5.2.1. Principais características para atuar como DBA de Infraestrutura Além das características gerais dos papéis técnicos, também são requisitos importantes para atuar como DBA de Infraestrutura: Conhecimentos avançados de Administração de Banco de Dados. Conhecimentos avançados de performance tuning. Vivência em ambientes de pressão extrema. 3.4.6. Arquiteto de Integração de Dados Pro ssional sênior responsável por projetar os mecanismos para integração dos dados. Possui conhecimentos avançados de SOA, ferramentas ETL9 e mecanismos de integração por meio de SGBDs. Entre suas principais tarefas podemos destacar: Emissão de pareceres indicando a melhor forma de integração dos dados. Manter atualizado o catálogo de serviços de integração de dados. Apoio na especi cação de mecanismos de integração tais como: serviços, especi cações ETL, database links e demais mecanismos de integração via SGBD. Apoiar os desenvolvedores de serviço na construção dos dispositivos de integração de dados. 3.4.6.1. Principais características para atuar neste papel Além das características gerais dos papéis técnicos, também são requisitos importantes para atuar como Arquiteto de Integração de Dados: Conhecimentos avançados de mecanismos de integração de dados. Conhecimentos avançados de utilização de repositórios de ativos de informação. Boa comunicação escrita.

4. Estabelecendo a Gestão de Dados nas Empresas “O novo sempre despertou perplexidade e resistência.” Sigmund Freud

4.1. Contextualização Vimos no capítulo anterior que os papéis e per s atuantes na Gestão de Dados são muitos. Porém, como devemos estruturar e organizar esses papéis? As formas de estruturar a Gestão de Dados variam muito em cada empresa. O objetivo deste capítulo é apresentar as formas mais usuais que são adotadas no mercado para estruturar uma ou várias equipes de Gestão de Dados nas empresas.

4.2. Equipes de Gestão de Dados As equipes de Gestão de Dados são formadas por um grupo de pro ssionais da área que atuam em um ou mais papéis e estão subordinados a uma estrutura organizacional dentro de uma empresa. Possuem como principal responsabilidade trabalhar em conjunto com outras pessoas e demais equipes a m de atingir os objetivos táticos e estratégicos de nidos para a disciplina de Gestão de Dados nas empresas. Também executam as tarefas estabelecidas na metodologia de Gestão de Dados vigente, alimentam os indicadores de desempenho adotados e atuam de forma proativa com o propósito de elevar a maturidade e a utilização da Gestão de Dados na empresa.

4.3. Onde estabelecer a Gestão de Dados? De forma geral, a maioria das organizações ainda estabelece suas equipes de Gestão de Dados dentro da própria área de TI. Já outras pessoas defendem que as equipes de Gestão de Dados deveriam estar localizadas fora da TI, preferencialmente no patamar estratégico da empresa, de modo que todos os funcionários

chamassem as mesmas coisas pelos mesmos nomes, relacionando todos os conceitos aos seus nomes corretos. Qual das duas abordagens é a ideal? A princípio, na minha visão, nenhuma das duas. Equipes de Gestão de Dados subordinadas ao departamento de TI têm sua atuação muito limitada às necessidades de tecnologia das empresas, sem, muitas das vezes, considerar as reais necessidades do negócio. Nesses casos, as soluções não são tão abrangentes, pois a área não possui uma visão global de todo o negócio da empresa, e sim uma visão de requisições de clientes para atender dentro do seu portfólio. Além disso, é bastante comum haver con itos técnicos entre Gestores de Dados e pro ssionais ligados ao desenvolvimento/manutenção de sistemas devido às soluções não tão completas e/ou corretas que estão sendo apresentadas por causa das pressões decorrentes dos prazos e custos das entregas. En m, muito possivelmente, em um curto período de tempo, caso não adotassem posturas de atendimento ágeis e proativas, as equipes de Gestão de Dados perderiam muito prestígio e seriam encaradas por muitos como mais um “overhead” corporativo. Equipes de Gestão de Dados estabelecidas fora do departamento de TI, preferencialmente nos níveis mais altos dentro da hierarquia da empresa, possuem uma visão de negócio muito mais abrangente e também aderente às reais necessidades das empresas, porém, de forma geral, faltam condições e conhecimento técnico para acompanhar as implementações tecnológicas, geralmente conduzidas pela área de TI. Inicialmente, a área teria um bom prestígio, porém, no decorrer do tempo, quando as iniciativas começarem a ser implementadas de forma diferente do planejado, inevitavelmente a área também perderá muito prestígio e terá a sua existência questionada. Uma terceira abordagem, mais aderente às necessidades atuais do mercado e alinhadas com os princípios da Gestão de Dados, sugere a adoção de um modelo de atuação híbrido no qual a função Gestão de Dados seria compartilhada entre as áreas de negócio e TI. Para isso, a TI contaria com um quadro quali cado de Gestores Técnicos de Dados e demais pro ssionais de tecnologia, e as áreas de negócio contariam com a gura dos Gestores de Dados de Negócio, também conhecidos como Data Stewards. Este modelo pode ainda ser complementado com estruturas formais de apoio à Gestão de Dados, tais como: Conselho de Governança de Dados, Comitês de Gestão de Dados e Escritórios de Gestão de Dados. Essas estruturas cariam responsáveis por fornecer subsídios e ajustar o alinhamento constante entre as áreas de TI e negócio.

4.4. Cenários de distribuição das equipes de Gestão de Dados

Dependendo do porte e das características de cada empresa, a responsabilidade pela execução das atividades da Gestão de Dados pode ser distribuída em várias equipes ou centralizada em uma única equipe. Os cenários a seguir mostram as formas mais usuais de distribuição das responsabilidades pelas atividades entre as equipes, suas vantagens e desvantagens. Equipes distribuídas geogra camente, porém subordinadas a uma mesma estrutura organizacional e atuando de forma uniforme, serão consideradas neste livro como uma equipe única. Ou seja, a distância física entre as equipes não impede uma possível centralização. Vale ressaltar que, independentemente da forma como estão estruturadas, é fundamental promover o alinhamento entre o segmento técnico (Gestão Técnica de Dados) e o segmento de negócio (Gestão de Dados de Negócio). Sem isto, fatalmente, os resultados da Gestão de Dados serão comprometidos. 4.4.1. Cenário 1 – Equipe centralizada Este é o cenário mais comum encontrado na maioria das empresas, principalmente nas que já possuíam uma área de Administração de Dados estabelecida e resolveram ampliar o escopo de atuação sem grandes mudanças. Neste caso, geralmente a equipe é única e está situada dentro da área de TI. Todos os pro ssionais que atuam na Gestão de Dados continuam a ser alocados dentro de uma única equipe. A gestão desses pro ssionais é executada por um gerente ou um coordenador que também pode atuar no papel de Gestor Estratégico de Dados. De forma geral, os pro ssionais que atuam neste papel são divididos em frentes especí cas para atenderem a diferentes áreas de negócios da empresa. É extremamente recomendado que esses pro ssionais passem boa parte do expediente dentro das áreas de negócio, próximos aos clientes, a m de entender o “modus operandi” e representar as necessidades e os interesses das áreas de negócio por eles atendidas. Além disso, com o propósito de disseminar o conhecimento global a respeito das áreas de negócio da empresa, também é recomendada a adoção de um rodízio entre as áreas atendidas por cada Gestor de Dados de Negócio, para que, com o tempo, todos os pro ssionais deste per l amadureçam uma visão de negócios completa de todos os segmentos da empresa. Alguns papéis podem estar dentro de uma equipe de Gestão de Dados ou não. Os projetistas de dados, em algumas empresas, são considerados membros de uma equipe de Gestão de Dados; já em outras empresas isso não acontece. O mesmo ocorre com os DBAs. É comum haver separações entre DBAs de aplicação, geralmente alocados em equipes de Gestão de Dados, e DBAs de Infra, geralmente alocados em equipes de Suporte e Infraestrutura. A gura a seguir mostra um exemplo de uma equipe de Gestão de Dados estabelecida de forma centralizada.

Figura 4.1 – Cenário típico de uma estrutura centralizada de Gestão de Dados

Neste cenário, as estruturas de apoio à equipe são opcionais. Quando existentes, são representadas na pirâmide da gura anterior, através do Conselho de Gestão de Dados. Essas estruturas são responsáveis pelo relacionamento estratégico com a área de negócios. Vale ressaltar que, conforme dito anteriormente, em alguns casos essas estruturas de apoio não são adotadas, pois, além deste cenário ser uma forma inicial de estruturação, todos os pro ssionais de Gestão de Dados estão alocados em um único lugar. Neste caso todo o relacionamento com as áreas de negócio (estratégico, tático e operacional) pode ser feito via equipe de Gestão de Dados. Os cenários tratados neste livro possuirão vantagens e desvantagens. Em particular, as principais vantagens do cenário de uma equipe de Gestão de Dados centralizada são: Melhor gerenciamento e aproveitamento dos recursos humanos. Custo reduzido, pois os gastos estarão concentrados em apenas uma equipe. Mudança de cultura mais gradual, pois grande parte das empresas que resolvem adotar este cenário já possuía uma área de Administração de Dados estabelecida. Implantação da Gestão de Dados facilitada, pois as adoções em áreas de negócio podem ser feitas de forma gradual, através de projetos piloto. Garantia de processos de trabalho executados de forma única e centralizada. Entre as desvantagens podemos citar: O peso das decisões estará concentrado em um único lugar. Se a área de Gestão de Dados estiver localizada dentro da TI, as decisões tenderão a levar em conta as pressões por prazos, custos, entregas e disponibilidades de recursos da TI, deixando de lado algumas necessidades prioritárias das áreas de negócio. Se a área estiver localizada fora da TI, algumas decisões poderão ser tomadas sem levar em conta a capacidade de atendimento e a carteira de entregas da área de TI.

A área de negócio pode não dar o apoio necessário à adoção da Gestão de Dados, tornando difícil o alinhamento entre a TI e o negócio. 4.4.2. Cenário 2 – Gestão de Dados distribuída em duas equipes (Negócio e TI) Este cenário pode ser considerado uma evolução do cenário anterior e é caracterizado pela divisão de responsabilidades em duas equipes. A equipe de Gestão Técnica de Dados está subordinada à área de TI e a equipe de Gestão de Dados de Negócio está subordinada a uma área de negócio da empresa, preferencialmente ligada à estratégia/alta administração. Os Comitês de Gestão e Governança de Dados e o Conselho de Gestão e Governança de Dados, opcionais no cenário anterior, passam a ser fundamentais para promover alinhamento e harmonia entre as duas equipes. A forma de trabalho dos papéis não sofre nenhuma mudança radical em relação à forma de atuação centralizada, porém é importante frisar que uma simples divisão de responsabilidades entre duas áreas (equipes) impulsiona um melhor alinhamento entre a TI e o negócio, pois cada equipe passa a concentrar seus esforços naquilo em que realmente é especialista. Neste cenário, surge a possibilidade de existir um pro ssional dedicado a promover a Gestão de Dados nos escalões mais altos da empresa, o Executivo de Gestão de Dados (CDO). Este pro ssional atua nos níveis mais altos da empresa fornecendo a chancela e o apoio necessários para reconhecer a Gestão de Dados como uma importante disciplina estratégica na empresa. Em relação aos dados, o CDO junto com o Conselho de Governança de Dados será responsável pelo relacionamento estratégico com as áreas de negócio da empresa. A equipe de Gestão de Dados de Negócio será responsável por manter um relacionamento tático com as áreas de negócio. Já a equipe de Gestão Técnica de Dados continuará a manter relacionamentos nos níveis tático e operacional. A gura a seguir mostra um exemplo da Gestão de Dados dividida em duas equipes: uma ligada à tecnologia e outra ligada ao negócio.

Figura 4.2 – Cenário típico de estrutura dividida em duas equipes: técnica e de negócio

Apesar de estar alocado na equipe de Gestão de Dados de Negócio na gura anterior, o Gestor Estratégico de Dados também pode estar alocado na equipe de Gestão Técnica de Dados ou então fora das duas equipes, como uma espécie de consultor externo, inclusive apoiando o CDO da empresa. A atuação do Gestor Estratégico de Dados é fundamental quando a Gestão de Dados é compartilhada, pois este pro ssional será o principal responsável por propor ações de cunho corporativo para a Gestão de Dados na empresa. 4.4.2.1. Estruturação das duas equipes em um organograma Dependendo da estruturação do organograma, as equipes podem ser subordinadas diretamente ao CDO ou então serem gerenciadas em forma de matriz, onde o CDO de niria as principais diretrizes e as equipes atenderiam, ou seja, neste caso, o CDO atuaria como o principal cliente das duas equipes. As guras que virão a seguir demonstrarão dois casos comuns de estruturação da Gestão de Dados em um organograma onde a atuação da Gestão de Dados é compartilhada. Vale ressaltar que os exemplos a seguir são meramente didáticos e não representam a estrutura organizacional de uma empresa real. Exemplo 1: Gestão de Dados estabelecida em dois departamentos diferentes, com gerência indireta do CDO em cada equipe.

Figura 4.3 – Exemplo de organograma com gerência indireta do CDO nas equipes

Neste exemplo, cada área possui um gerente (ou coordenador) funcional responsável pela gestão dos recursos humanos formados pelos pools de gestores de dados (técnicos ou de negócios). Este gerente é subordinado à outra estrutura dentro do organograma e deve atender aos objetivos de nidos pela sua estrutura superior, porém o CDO exerce forte in uência na gestão dessas equipes. Na prática, esses pro ssionais possuem dois chefes.

Exemplo 2: Gestão de Dados estabelecida em uma única estrutura, com gerência direta do CDO nas equipes.

Figura 4.4 – Exemplo de estrutura com gerenciamento direto do CDO nas equipes de Gestão de Dados

Neste exemplo, a gestão dos recursos é facilitada, pois a estrutura de trabalho segue uma hierarquia única. Vale destacar que, neste caso, apesar de ter uma estrutura para Gestão Técnica de Dados especí ca, esta não é subordinada à TI. Resumo da ópera: nesta forma de estruturação, a equipe de Gestão Técnica de Dados não sofre as pressões costumeiras das áreas de desenvolvimento de sistemas, dando aos pro ssionais da área mais liberdade para emissão de laudos ou pareceres. Além disso, a aproximação com a equipe de Gestão de Dados de Negócio traz diversos benefícios, entre eles: melhor agilidade em resolver problemas que envolvem o negócio, comunicação direta e alinhamento constante entre a TI e o negócio. Para muitos este é o principal ganho dessa forma de estruturação. 4.4.2.2. Vantagens e desvantagens de trabalhar com duas equipes Voltando ao cenário da distribuição da Gestão de Dados em duas equipes, quais são suas vantagens e desvantagens? Entre as principais vantagens de adotar a Gestão de Dados compartilhada entre duas equipes podemos citar: Melhor alinhamento entre a TI e o negócio. Melhoria no nível de maturidade do gerenciamento de dados e informações devido à utilização de estruturas de apoio como Comitês de Gestão de Dados e Conselho de Governança de Dados. A Gestão de Dados reconhecida nos escalões mais altos da empresa devido à atuação do Executivo de Gestão de Dados (CDO). As principais desvantagens são:

O custo de implantação da Gestão de Dados será um pouco maior do que uma iniciativa centralizada. Necessidade de estruturas de apoio para promover a perfeita harmonia entre as duas equipes. A metodologia e a forma de trabalho devem estar bem de nidas e alinhadas, sob o risco de haver sobreposição em algumas atividades. 4.4.3. Cenário 3 – Gestão de Dados distribuída em várias equipes de negócio e uma única equipe de TI Menos usual que os cenários anteriores, a responsabilidade pela execução das atividades da Gestão de Dados é compartilhada entre várias equipes de Gestão de Dados de Negócio, com o apoio de uma equipe de Gestão Técnica de Dados centralizada. Neste cenário, as questões con itantes entre as equipes de Gestão de Dados de Negócio nem sempre são decididas pelos Comitês de Gestão de Dados. É comum escalar as decisões para o Conselho de Governança de Dados. Nem todas as áreas de Negócio possuem equipes de Gestão de Dados de Negócio dedicadas. Nesses casos, essas áreas são atendidas por uma equipe genérica de Gestores de Dados de Negócio mantida sob a área de TI ou então pela equipe de Gestão Técnica de Dados. Em relação ao organograma, as equipes de Gestão de Dados de Negócio podem estar espalhadas em várias áreas dentro da empresa. Este fator pode ser preocupante, pois a forma de atuação de cada uma dessas equipes poderá não ser uniforme. A gura a seguir mostra um exemplo de como a Gestão de Dados pode ser adotada através de várias equipes de Gestão de Dados de Negócio e uma equipe de Gestão Técnica de Dados.

Figura 4.5 – Gestão de Dados distribuída por várias equipes de negócio e uma equipe técnica

As principais vantagens de adotar este cenário de distribuição de equipes são as seguintes: Melhor entendimento das áreas de negócio, pois os Gestores de Dados de Negócio atuarão diretamente nessas áreas.

Facilidade na adoção do papel do Gestor de Dados de Negócio. Entre as principais desvantagens podemos citar: Apesar de haver um melhor entendimento especí co das áreas de negócio, a visão corporativa do negócio da empresa cará comprometida, pois provavelmente não haverá mais o revezamento entre as áreas de atuação dos Gestores de Dados de Negócio em algumas áreas. Comunicação custosa. Toda e qualquer comunicação sobre o assunto Gestão de Dados Corporativa deverá ser levada a vários canais. Riscos das equipes não atuarem de forma constante. Sobrecarga no trabalho da equipe de Gestão Técnica de Dados, pois em algumas situações esta equipe também poderá atuar no atendimento de outras áreas executando atividades de Gestão de Dados de Negócio. Além disso, provavelmente os planejamentos das equipes de Gestão de Dados de Negócio não ocorrerão no mesmo tempo, deixando a equipe técnica vulnerável às mudanças repentinas e não planejadas. O custo de implantação da Gestão de Dados será um pouco maior do que uma iniciativa centralizada. 4.4.4. Cenário 4 – Gestão de Dados distribuída em uma equipe de Gestão de Dados de Negócio e várias equipes de Gestão Técnica de Dados especializadas Neste cenário a responsabilidade pelas atividades da Gestão de Dados é compartilhada entre uma equipe única de Gestão de Dados de Negócio e várias equipes de Gestão Técnica de Dados. As equipes técnicas são divididas por especialidades e estão subordinadas a uma ou mais estruturas organizacionais dentro da área de TI da empresa. Apesar de concentrar recursos especialistas em cada equipe técnica, este cenário requer preocupações adicionais: A primeira preocupação consiste em não permitir o crescimento desorganizado dessas equipes. Veremos mais à frente um exemplo de como um crescimento desorganizado de equipes pode prejudicar a atuação da Gestão de Dados. Outra preocupação que se deve ter em mente é uma possível demora no atendimento das tarefas pelas equipes de Gestão Técnica de Dados, pois, de forma geral, várias equipes poderão estar envolvidas em processos comuns. Portanto, é imprescindível de nir SLAs10 curtos e promover um alinhamento constante entre as equipes. Se este trabalho for realizado com proeza, esta abordagem poderá mudar a tendência de demora e se transformar em uma das formas mais rápidas de atendimento.

Pelo fato das equipes técnicas estarem divididas, o Gestor Estratégico de Dados geralmente é alocado na equipe de negócio ou então atua como um consultor independente, sem estar ligado diretamente a uma equipe. Em relação ao organograma, geralmente as equipes de Gestão Técnica de Dados estão subordinadas à estrutura organizacional da TI. A gura a seguir mostra um exemplo de como a Gestão de Dados pode ser adotada através de uma equipe única de Gestão de Dados de Negócio e várias equipes técnicas de Gestão de Dados.

Figura 4.6 – Gestão de Dados centralizada em uma equipe de Gestão de Dados de Negócio e várias equipes técnicas de Gestão de Dados

As principais vantagens de adotar este cenário de distribuição de equipes são as seguintes: O alinhamento entre a TI e o negócio continua, porém com maiores interações entre as equipes técnicas. Não há sobrecarga nos papéis. Atividades da Gestão Técnica de Dados executadas por pro ssionais especialistas. As principais desvantagens são: Comunicação custosa. Toda e qualquer comunicação sobre o assunto Gestão de Dados, no âmbito técnico, deverá ser levada a vários canais. Necessidade de estruturas de apoio para promover a perfeita harmonia entre as duas equipes. Maior número de recursos técnicos para conduzir as atividades de Gestão Técnica de Dados. O custo de implantação da Gestão de Dados será um pouco maior do que uma iniciativa centralizada. 4.4.5. Cenário 5 – Gestão de Dados distribuída em várias equipes técnicas e equipes de negócio

Apesar de não parecer usual, este cenário pode ser encontrado em algumas empresas, principalmente naquelas que possuem uma estrutura organizacional muito grande, onde equipes de Gestão de Dados foram criadas sem um planejamento corporativo, através de várias iniciativas isoladas entre diferentes áreas para gerir os dados. O esforço para manter organizadas as equipes de Gestão de Dados é muito maior do que nos outros cenários, pois o número de equipes e a forma de interação entre elas são muito maiores. Para funcionar bem, a Governança de Dados deve estar muito bem de nida e estruturada. A responsabilidade por manter esta governança deve ser dada a uma equipe estabelecida em um nível mais alto do que as demais no organograma, além de possuir uma boa visibilidade e patrocínio forte. Neste caso, o CDO pode ser o responsável por esta equipe. A gura a seguir demonstra um exemplo de interações entre as equipes da Gestão de Dados de

uma mesma empresa:

Figura 4.7 – Gestão de Dados distribuída entre várias equipes Técnicas e de Negócio

Ao estruturar este tipo de abordagem, deve-se tomar o cuidado de não criar equipes iguais, que executem as mesmas atividades e tenham o mesmo propósito. A nal, como mostra a imagem anterior, mesmo com equipes diferentes as interfaces são muitas e a comunicação e o alinhamento são muito custosos. Sem este cuidado, fatalmente as atividades da Gestão de Dados serão feitas por várias equipes, de forma repetida ou sobreposta. Sem uma forma de trabalho padrão, com atendimento lento e precário, algumas vezes com con itos e interesses políticos entre as equipes, levando cada vez mais adiante a possibilidade de criar mais equipes para executar os trabalhos que são feitos pelas equipes atuais de forma não integrada. É o fenômeno da multiplicação das equipes de Gestão de Dados. Apesar de não ser comum, isto pode ocorrer em empresas onde as iniciativas a respeito da Gestão de Dados não vieram de cima, mas de baixo, onde técnicos de diversas áreas inicializaram este trabalho sem um patrocínio formal da alta gerência da empresa. A gura a seguir mostra um exemplo deste fenômeno.

Figura 4.8 – Multiplicação das equipes de Gestão de Dados

Empresas com tais características devem rever a forma de atuação da Gestão de Dados e propor uma estratégia de reformulação compatível com os cenários apresentados neste capítulo. Vale ressaltar que qualquer descuido em relação ao cenário 5 acarretará neste tipo de fenômeno. Ainda sobre o cenário 5, a única vantagem desta abordagem é a execução das atividades da Gestão de Dados feitas por especialistas tanto da área técnica quanto da área de negócio. Já as desvantagens são várias. Podemos citar: Risco de crescimento desorganizado. Falta de identidade organizacional para a disciplina Gestão de Dados. Comunicação custosa. Mau dimensionamento e aproveitamento dos recursos humanos. Se existirem equipes com os mesmos objetivos, haverá sobreposição de tarefas. Falta de alinhamento entre TI e o negócio. Escopo de atuação limitado. Estabelecimento de feudos: “meus dados”, “minhas aplicações”, “meus pro ssionais”.

4.5. Qual o melhor cenário para adotar a Gestão de Dados em minha empresa? Eleger a melhor abordagem dentre as apresentadas anteriormente, sem levar em conta as características e particularidades de cada empresa, não parece ser uma atitude correta. Cada empresa possui uma realidade. Questões como a cultura da empresa, patrocínio, disponibilidade e verba disponível para implantar a Gestão de Dados in uenciam diretamente na escolha de uma abordagem. Convém, no entanto, ter atenção em certos fatores críticos que caracterizam uma área de Gestão de Dados bem-sucedida. São eles:

Constituir-se em unidade(s) autônoma(s) com recursos dedicados integralmente e centro de custo. Possuir autoridade institucional su ciente para agir com independência, segurança e e cácia na busca dos seus objetivos. Supervisionar a adoção, por todos os setores, incluindo a TI, de modelos, normas e regras de Gestão de Dados corporativos, decorrentes das estratégias organizacionais aprovadas. Ter o apoio sustentado e explícito da Alta Administração da empresa, no mínimo, até que atinja a fase de consolidação e maturação da área.

5. Visão Geral do Guia DAMA-DMBOK® “Os costumes são uma das fontes da moral.” Henri Bergson

5.1. O que é o Guia DAMA-DMBOK®? O Guia DAMA-DMBOK® é um conjunto de boas práticas de Gestão de Dados reunidas em um documento estruturado em forma de um framework. O conteúdo do guia foi elaborado com a contribuição de mais de 120 pro ssionais que atuam na área de Gestão de Dados no mundo. Por se tratar de um guia de boas práticas, o documento faz referência a diversas fontes de informação e conteúdo especializado em cada uma das dez funções de Gestão de Dados propostas no documento. As referências especializadas costumam ser citadas no m de cada capítulo. O guia já começou a ser adotado em algumas empresas brasileiras. No mercado internacional o documento já é uma referência consagrada, sendo adotado por milhares de organizações que faturam e/ou administram bilhões de dólares. Entre seus principais objetivos podemos citar: Transmitir aos leitores a importância da Gestão de Dados. Construir consenso para uma visão generalista aplicada no mercado para as dez funções de Gestão de Dados previstas no guia atual. Fornecer de nições padrão para os termos da Gestão de Dados, conceitos, entregáveis, papéis e responsabilidades dos envolvidos na adoção da disciplina Gestão de Dados. De nir as premissas que orientam a adoção da Gestão de Dados nas empresas. Apresentar um visão independente de fornecedores, com técnicas e métodos que podem ser amplamente adotados oferecendo alternativas de abordagem, promovendo assim a real discussão nas aquisições e implementações da Gestão de Dados.

Servir como instrumento orientador a respeito do escopo e fronteiras de atuação da Gestão de Dados. Fornecer base para avaliar a e cácia e maturidade da adoção da Gestão de Dados nas empresas. Atuar como referência aos leitores com os recursos adicionais para aprimorar o uso da disciplina de Gestão de Dados. Apoiar os pro ssionais de Gestão de Dados na preparação para os exames de certi cação em Gestão de Dados. Vale ressaltar que o guia DAMA-DMBOK® é um documento genérico que pode ser adotado por qualquer empresa, independentemente de área de atuação, porte e cultura. Quando adotado, devemos ter em mente as seguintes considerações: O conteúdo do guia é bastante amplo. Não é um livro didático e muito menos se propõe a ser um livro técnico especí co sobre Administração de Dados ou Qualidade de Dados. O conteúdo do guia está em constante evolução, e toda a comunidade mundial de pro ssionais de Gestão de Dados pode contribuir para o seu enriquecimento. A edição em português do guia DAMA-DMBOK® é uma tradução da versão original em inglês. Como toda empresa possui as suas particularidades, nem todas as boas práticas precisam ser adotadas em sua totalidade. Portanto, quando utilizado, o guia deve ser analisado e adaptado à realidade de cada organização. Não há uma ordem preestabelecida de execução das funções de Gestão de Dados previstas no guia. Por esta razão as funções são representadas por uma espécie de “roda” no framework do DAMA-DMBOK®. A adoção do guia pode ser feita em partes, geralmente divididas por funções. Entretanto, vale a pena levar em consideração a analogia feita no capítulo 2 deste livro, onde a função “Arquitetura de Dados” é considerada o alicerce da casa, base necessária para o sustento de qualquer iniciativa de Gestão de Dados, e a função “Governança de Dados” é considerada o telhado da casa, dando a proteção e o reconhecimento necessários ao funcionamento das demais funções. Por m, tudo isso nos leva a concluir que o guia DAMA-DMBOK® é uma excelente referência técnica e não uma receita de bolo.

5.2. Framework A leitura e entendimento do guia através de seu framework são bastante simples. O framework está estruturado em duas visões principais, sendo elas:

Funções da Gestão de Dados. Elementos ambientais da Gestão de Dados. 5.2.1. Funções de Gestão de Dados As funções de Gestão de Dados representam os principais segmentos de atuação da disciplina agrupados por atividades comuns e/ou próprias de cada agrupamento. Além de facilitar o entendimento e a distribuição das atividades em comum, a divisão da disciplina “Gestão de Dados” em funções é importante, pois algumas das funções propostas requerem pro ssionais e/ou equipes com per s especí cos. Vale ressaltar que algumas das funções já eram atendidas, mesmo que parcialmente, pelas antigas equipes de Administração de Dados nas empresas brasileiras. A gura a seguir mostra as dez funções de Gestão de Dados previstas na versão atual do guia DAMA-DMBOK®. A função Governança de Dados está localizada no centro da gura para demonstrar que exerce importante in uência em todas as demais funções.

Figura 5.1 – Funções da Gestão de Dados segundo o guia DAMA-DMBOK®

Podemos caracterizar as funções de Gestão de Dados da seguinte forma: Governança de Dados: o guia DAMA-DMBOK® de ne esta função como “o exercício de autoridade e controle (planejamento, monitoramento e engajamento) sobre o gerenciamento de ativos de dados”. Esta função é responsável por promover o reconhecimento da disciplina Gestão de Dados na empresa e também por controlar a gestão dos ativos de dados em alto nível em toda a organização. A Governança de Dados é considerada uma função estratégica e se relaciona diretamente com todas as demais funções de Gestão de Dados do guia DAMADMBOK®, por isso está representada no centro do framework. Gestão da Arquitetura de Dados: o guia DAMA-DMBOK de ne esta função como “de nição dos dados necessários da organização e o desenho do diagrama mestre para atingir essas necessidades”. Esta função é responsável por de nir em âmbito corporativo os dados

necessários para a empresa e também por manter o controle dos modelos corporativos e demais artefatos da Arquitetura de Dados corporativa alinhados à arquitetura empresarial da organização. Desenvolvimento de Dados: o guia DAMA-DMBOK® de ne esta função como “projetar, implementar e manter soluções para atender às necessidades de dados da organização”. Esta função é responsável por gerir todo o ciclo de vida de criação das estruturas de dados que serão utilizadas nas aplicações. Engloba as atividades de levantamento dos dados, modelagem dos dados, ajustes, avaliação dos modelos de dados, implementação física e manutenção das bases de dados relacionadas com os componentes das soluções adotadas. O termo “Desenvolvimento de Dados” soa um pouco estranho aqui no Brasil. Segundo o dra da nova versão do DAMADMBOK® disponibilizado pela DAMA International em seu website, esta função será renomeada na próxima versão do guia para “Modelagem de Dados e Projeto”. Gestão de Operações e Dados: o guia DAMA-DMBOK® de ne esta função como “planejar, controlar e suportar ativos de dados estruturados atravessando o ciclo de vida dos dados, desde a criação e aquisição até o arquivamento e a eliminação”. Esta função é responsável por gerir os dados (conteúdo) estruturados, geralmente armazenados em sistemas gerenciadores de banco de dados, em todo o ciclo de vida do dado, respeitando as diretrizes estabelecidas nas outras funções de Gestão de Dados. Ou seja, é o controle do ativo do dado armazenado desde o seu planejamento e criação no ciclo de desenvolvimento de sistemas até a aquisição, o arquivamento e o expurgo no ciclo de vida dos dados. Gestão da Segurança de Dados: o guia DAMA-DMBOK® de ne esta função como “planejar, desenvolver e executar procedimentos e políticas de segurança para prover autenticação, autorização, acesso e auditoria dos dados e informações”. Gestão de Dados Mestres e Referência: o guia DAMA-DMBOK® de ne esta função como responsável por planejar, de nir arquitetura, implementar e controlar o uso dos dados mestres e de referência da empresa, mantendo a sua consistência e exatidão. Esta função trouxe à comunidade de Gestão de Dados o conceito de “registros dourados”, tradução do termo “golden records”, que são os dados mais precisos e completos possíveis para o uso compartilhado e consistente entre as aplicações. Gestão de Data Warehousing e Business Intelligence: o guia DAMA-DMBOK® de ne esta função como responsável por “planejar, implementar e controlar processos para prover dados de suporte para decisão e suportar trabalhadores do conhecimento engajados em análises, queries e reporte”. Gestão da Documentação e Conteúdo: o guia DAMA-DMBOK® de ne esta função como “planejar, implementar e controlar atividades para armazenar, proteger e permitir o acesso aos dados dentro de arquivos eletrônicos e registros físicos (incluindo texto, grá cos, imagens, áudio e vídeo).” Esta função é responsável por gerir os dados (conteúdo) não estruturados, geralmente armazenados em arquivos diversos. Por se tratar de dados não estruturados, ou

seja, não armazenados em bancos de dados tradicionais, aparentemente os per s mais técnicos atuantes em Gestão de Dados não consideram relevante a preocupação em gerir esses dados, porém devemos ter em mente que atualmente a maioria dos dados das empresas é armazenada em formas não estruturadas, e cada vez mais as soluções de ECM (Enterprise Content Manager) estão sendo adotadas para armazenar esses tipos de dados. Gestão de Metadados: o guia DAMA-DMBOK® de ne esta função como “planejar, implementar e controlar atividades para permitir o fácil acesso a metadados integrados de alta qualidade”. Esta função permite o gerenciamento dos metadados representados em modelos de dados, bancos de dados, repositórios e demais ferramentas de gestão de metadados. Além disso, provê, quando necessário, o devido acesso aos metadados da empresa aos envolvidos. Gestão da Qualidade de Dados: o guia DAMA-DMBOK® de ne esta função como “planejamento e implementação das atividades que aplicam técnicas de gestão de Qualidade de Dados para medir, avaliar, otimizar e garantir dados adequados para o uso”. Podemos considerar as funções do DAMA-DMBOK® como o principal conceito do framework. Algumas dessas funções possuem atividades que já eram executadas parcialmente ou integralmente pelas antigas equipes de Administração de Dados nas empresas, principalmente a função “Desenvolvimento de Dados”. 5.2.2. Elementos ambientais Os elementos ambientais representam as variáveis que geram grande in uência na seleção, no escopo e na forma de adoção da disciplina Gestão de Dados em cada empresa. Os elementos ambientais podem ser divididos em duas classes: elementos básicos, caracterizados por ocorrências de elementos em todas as funções de Gestão de Dados, e elementos de apoio, caracterizados por ocorrências que nem sempre são encontradas em todas as funções de Gestão de Dados. A gura a seguir mostra os elementos ambientais previstos na versão atual do guia DAMADMBOK®.

Figura 5.2 – Elementos ambientais do DAMA-DMBOK®. Fonte: Guia DAMA-DMBOK®

Os elementos ambientais previstos na versão atual do guia DAMA-DMBOK® são: Elementos básicos: Metas e Princípios: fornecem foco, objetivos e propósitos de cada função de Gestão de Dados, além de de nirem os princípios básicos de cada função de Gestão de Dados. Representam o propósito de cada função seguindo seus princípios básicos. Atividades: conjunto de ações necessárias para atingir as metas de cada função de Gestão de Dados. Em algumas funções as atividades podem ser agrupadas. Vale ressaltar que o guia não de ne os processos e nem o detalhamento dos uxogramas de cada atividade. Elas representam os passos necessários que devem ser feitos em cada função de Gestão de Dados. As atividades são executadas em fases especí cas: Planejamento, Controle, Desenvolvimento e Operação. Além disso, as atividades podem ser decompostas em tarefas menores e etapas. As relações de todas as atividades do guia DAMA-DMBOK®, bem como suas fases de execução, estão disponíveis no Anexo deste livro. Entregas Primárias: são os entregáveis gerados a partir da execução das atividades previstas em cada função de Gestão de Dados. Representam o que é gerado a partir do trabalho executado nas atividades. Papéis e Responsabilidades: papéis envolvidos na produção dos entregáveis de cada função de Gestão de Dados. Representam quem é responsável por cada atividade e entrega de artefatos previstos em cada função de Gestão de Dados. Elementos de apoio: Tecnologia: são ferramentas, padrões, protocolos e critérios de seleção de produtos adotados. Vale ressaltar que o guia não menciona vendedores ou produtos em seu conteúdo. Práticas e Técnicas: são métodos e procedimentos comuns utilizados para executar as atividades e produzir os entregáveis. Organização e Cultura: são as particularidades de cada ramo de atuação de negócio e/ou empresa. Entre essas questões, o guia prevê os seguintes itens: Métricas. Fatores críticos do sucesso. Relatórios de estruturas. Estratégias. Questões nanceiras. Trabalho em equipe e dinâmica de grupo. Filoso a da empresa. Valores e crenças, etc.

5.3. Junção das funções de Gestão de Dados com os elementos ambientais A junção das funções de Gestão de Dados com os elementos ambientais gera uma matriz de duas dimensões. Esta matriz é importante, pois mostra uma visão estática de como cada elemento ambiental é tratado em cada função de Gestão de Dados. O preenchimento da tabela é bastante útil para de nir o escopo e a estratégia de implementação e/ou adoção do guia DAMA-DMBOK® nas empresas. Conforme mencionado anteriormente, o guia não é uma receita de bolo – portanto, a tabela é um importante instrumento a ser utilizado em um trabalho de implantação do guia DAMA-DMBOK®. A tabela a seguir mostra este quadro. Práticas Funções de Metas e Entregas Papéis e Organização Atividades Tecnologia e Gestão de Dados Princípios Primárias Responsabilidades e Cultura Técnicas Governança de Dados Gestão da Arquitetura de Dados Desenvolvimento dos Dados Gestão das Operações de Dados Gestão da Segurança dos Dados Gestão de Dados Mestres e de Referência Gestão de Data Warehousing e Business Intelligence Gestão da Documentação e Conteúdo Gestão dos Metadados Gestão da Qualidade dos Dados Tabela 5.1 – Visão do framework DAMA-DMBOK®

Parte 2 Funções da Gestão de Dados

6. Governança de Dados “A necessidade é a mãe da inovação.” Platão

6.1. Governança de Dados – Conceitos Tal como a disciplina Gestão de Dados, existem várias de nições para a função “Governança de Dados”. Particularmente, pre ro adotar as seguintes: “Governança de Dados é o exercício de autoridade e controle (planejamento, monitoramento e engajamento) sobre o gerenciamento de ativos de dados. A função de Governança de Dados guia como todas as outras funções da Gestão de Dados são realizadas. Governança de Dados é de alto nível, ou seja, é gestão estratégica de dados na esfera executiva.”1 “Governança de Dados é o exercício de tomada de decisão e autoridade para as questões relacionadas a dados.”2.

Em suma, a função Governança de Dados é responsável por gerir os princípios de organização e controle de dados e informações. Esta gestão envolve interface com diversas outras funções e estabelece políticas e diretrizes corporativas para governar os dados, além de atribuir papéis e responsabilidades. Atualmente, o escopo de atuação da Governança de Dados é muito amplo. Engana-se quem acha que a Governança de Dados atua somente no patamar

das normas e dos padrões ou ainda através de controles e permissões de acesso a dados e informações. A Governança de Dados também atua com uma visão mais apurada sobre os dados estratégicos da empresa, de nindoos e analisando os processos que produzem e se abastecem desses dados. A Governança de Dados é responsável por alinhar tecnologia, processos e pessoas para de nir os papéis, as responsabilidades e os processos necessários para gerir os dados estratégicos da empresa. A gura a seguir demonstra esse alinhamento.

Figura 6.1 – Alinhamento entre pessoas, processos e tecnologia

Questões como: “Quais são os dados existentes? Quais são os dados estratégicos? Quais dados são necessários? Quem possui acesso aos seguintes dados? Quem é o Gestor de um determinado dado? O que signi ca este conceito? Quando este dado foi criado? Quando poderá ser descartado? Onde está este dado? Onde é utilizado este dado? Como é criado este dado? Como consigo acessar este dado? Quanto custa a gestão deste dado?” são facilmente respondidas quando a empresa possui um programa de Governança de Dados estabelecido. Não é por acaso que a função está centralizada na gura central do guia DAMA-DMBOK®, fazendo interface com todas as demais funções,

in uenciando direta ou indiretamente as atividades e os papéis envolvidos na Gestão dos Dados. Dentro da função “Governança de Dados” encontramos alguns papéis já de nidos. A gura a seguir demonstra uma visão de papéis clássicos dentro de qualquer iniciativa em Governança de Dados.

Figura 6.2 – Papéis clássicos em Governança de Dados

Os Gestores das Informações são as pessoas que representam as áreas proprietárias das informações. Entende-se como área proprietária a estrutura organizacional que origina ou adquire as informações. Somente os gestores das informações podem de nir questões sobre o uso dos dados, tais como: classi cação da segurança das informações, de nição das permissões e acessos às informações e opções de descarte. Os Mantenedores, também conhecidos como custodiantes, são as organizações responsáveis pela guarda e disponibilização das informações conforme diretrizes estabelecidas pelos Gestores das Informações. Os custodiantes não devem de nir ou tomar decisões em relação às questões sobre o uso dos dados que são de responsabilidade dos Gestores das Informações. Entre os mantenedores conhecidos, podemos destacar a área

de TI ou empresas especializadas em guarda de informações, sejam elas armazenadas na nuvem (cloud) ou não. Os Criadores de Dados e Informações registram as informações dentro das aplicações que armazenam os dados. Algumas aplicações também atuam como criadores dos dados, onde, através de interfaces especí cas, incluem ou alteram os dados armazenados. Geralmente possuem acessos de criação, edição e consulta às informações. Os Consumidores dos Dados e informações são pessoas ou aplicações que utilizam os dados armazenados para execução de algum propósito. Os consumidores dos dados podem ser diretos, com acesso direto às informações solicitadas (ex.: consulta online a uma aplicação) ou então indiretos, onde o acesso à informação é obtido através de outras pessoas ou aplicações. O Staff da Gestão de Dados, formado por Gestores Técnicos de Dados, Gestores Estratégicos de Dados e Gestores de Dados de Negócio, é responsável por de nir, orientar, executar, acompanhar e avaliar os mecanismos de controle estabelecidos nos processos de Governança de Dados. Governança de Dados é considerada uma das mais importantes funções de Gestão de Dados. Atualmente existem diversas fontes com frameworks e modelos de maturidade disponíveis no mercado. Entre as principais fontes podemos destacar o guia DAMA-DMBOK®, os frameworks do Data Governance Institute e da IBM, além do modelo de maturidade proposto por Tony Fisher, da Data ux.

6.2. Razões para implantar a Governança de Dados

As razões são muitas. Dependendo das particularidades de cada empresa, cada razão pode ter um peso especí co. Entre as razões mais comuns podemos citar: Ter subsídios para obter informações corretas, de fácil acesso e ágeis para tomadas de decisões e inovações. Este é o desejo de todo executivo de alto escalão. Estabelecer a imagem de uma empresa sólida e con ável. A nal, na mente do público, se a empresa é sólida, certamente os dados são sadios e con áveis. Ter conhecimento completo dos dados do negócio da empresa e disseminar todo este conhecimento para o restante da empresa conforme política vigente. Evitar prejuízos decorrentes da baixa qualidade dos dados. Dado de baixa qualidade no mínimo gera retrabalho, aumentando os custos e desperdiçando o tempo. Em casos mais graves, as empresas podem perder grandes somas de dinheiro devido a decisões baseadas em dados incorretos, ações na justiça ou multas e penalidades aplicadas pelo setor público. Redução nos custos de operações com os dados. Dados governados requerem processos de criação, disponibilização e utilização de nidos. Em qualquer disciplina, quando temos as regras do jogo de nidas e aplicadas, a tendência natural é redução dos custos e ganho na produtividade. A Governança de Dados é a função responsável por de nir essas regras. Tornar a empresa apta para seguir novas regulamentações. Dependendo do ramo de atuação, é comum haver exigências a respeito dos controles internos da empresa. A lei Sarbanes-Oxley e o acordo de Basileia são exemplos de regulamentações aplicadas em setores

especí cos para garantir uma melhor governança, não só dos dados, mas de toda a empresa. Diminuir os custos do desenvolvimento das aplicações através da diminuição do retrabalho, da eliminação de silos redundantes e da disseminação dos processos de Gestão de Dados vigentes. Evitar fraudes devido à ausência de processos formais de controle ou existência de processos de Gestão de Dados mal de nidos ou executados.

6.3. Princípios da Governança de Dados Quando falamos em Governança de Dados, devemos ter em mente alguns princípios básicos que regulamentam essa função e devem ser adotados em qualquer iniciativa de implantação ou uso desta função. Os princípios são: Governança de Dados é Gestão de Dados Estratégica. Governança de Dados é Gestão de Dados de nida e aplicada nos altos níveis da empresa pelos executivos. Em suma, Governança de Dados é a tomada de decisões a respeito de Gestão de Dados pela alta administração. Tentar emplacar alguma iniciativa de Governança de Dados sem prever esta premissa é assinar a sentença de morte do programa. Iniciativas de Governança de Dados não devem começar nem ser somente aplicadas nos níveis táticos e operacionais das empresas. Governança de Dados requer patrocínio. Este patrocínio deve ser constante em todo o programa. Claro que nas fases iniciais o patrocínio se torna mais evidente por questões de estratégia de implantação e divulgação do programa, porém sempre deverá existir no decorrer do programa, sob pena das novas iniciativas não serem totalmente adotadas devido a diversos fatores, desde os culturais (como resistência a mudanças) até os nanceiros, cuja falta impacta o andamento e a

conclusão das iniciativas. Vale ressaltar também que no decorrer do programa os patrocínios podem mudar. Como veremos mais adiante, as iniciativas de um programa serão gerenciadas por Comitês de Governança e priorizadas pelo Conselho de Governança de Dados. Cada uma das iniciativas poderá ter um ou mais patrocinadores especí cos. Governança de Dados é um governo. A Governança de Dados funciona de forma semelhante a um governo. Se zermos uma analogia, poderemos entender que: A Governança de Dados Legislativa pode ser entendida como a de nição de normas, políticas, procedimentos e padrões que devem ser adotados pela Gestão de Dados Executiva. A Governança de Dados Executiva administra as políticas, a arquitetura e os serviços de nidos. Já a Governança de Dados Judiciária é responsável por gerir as questões de con ito ora existentes em todos os níveis onde a Governança de Dados é adotada.

Governança de Dados é um programa. A Governança de Dados não pode simplesmente ser adotada através de um projeto. Segundo a de nição, um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. Os projetos são exclusivos (únicos), possuem tempo e orçamentos limitados. Mesmo após um projeto inicial de implantação, para adotar a Governança de Dados de forma efetiva, vários projetos serão necessários no decorrer do tempo. As necessidades desses projetos serão de nidas nas reuniões periódicas do Conselho de Governança de Dados. Vale destacar que um dos objetivos da Gestão de Dados Estratégica é a melhoria contínua da qualidade dos dados e também dos processos de gestão adotados para esses propósitos. Portanto, enquanto houver uma Governança de Dados efetiva,

haverá também projetos de melhoria, voltados à obtenção da excelência no uso dos dados da empresa.

6.4. Componentes da Governança de Dados Pessoas, processos e tecnologia são os três componentes comuns em todos os programas de Governança de Dados. Esses componentes devem atuar de forma integrada com o propósito de efetivar a política e a estratégia de dados de nidas para o programa de Governança de Dados. A gura a seguir demonstra os componentes da Governança de Dados.

Figura 6.3 – Componentes da Governança de Dados

6.4.1. Pessoas As pessoas são os recursos humanos envolvidos direta ou indiretamente nas atividades de Governança de Dados. São elas que executam ou são responsáveis pelas ações da Governança de Dados. São representadas pelos pro ssionais de negócio (Executivos, pro ssionais de Gestão de Dados ligados ao Negócio, gestores e usuários das informações) e também pelos pro ssionais de tecnologia (gerentes, gestores de dados ligados à TI e demais técnicos).

O Programa de Governança de Dados deve prever, de forma constante, a conscientização e a capacitação das pessoas nos objetivos do programa, nos processos executados e também nas ferramentas utilizadas nas atividades. 6.4.2. Processos Os processos de nem a forma de trabalho e as “regras do jogo” da Governança de Dados na empresa. Um processo de ne quem está fazendo o quê, quando e como, a m de atingir certo objetivo. Em Governança de Dados, os processos são divididos em duas grandes frentes. A primeira representa os processos da área de negócios, que são aplicados quando os dados entram ou mudam de status no seu ciclo de vida. Aqui a existência de uma Arquitetura de Dados que contemple a execução desses processos é fundamental para o sucesso de qualquer programa de governança. A segunda frente representa os processos da própria área de Gestão de Dados, que são adotados de forma comum em todas as atividades necessárias para garantir a governança dos dados, independentemente das áreas onde os dados são (ou serão) utilizados. Esses processos devem compor a metodologia de Gestão de Dados vigente. A existência de processos mapeados e homologados em ambas as frentes é um requisito obrigatório para a adoção da Governança de Dados nas empresas. 6.4.3. Tecnologia Já a tecnologia é formada pelo hardware, com servidores e demais mecanismos de infraestrutura hospedando as soluções de soware e demais ferramentas que apoiam a execução dos processos mapeados e executados pelas pessoas. Entre os principais sowares e ferramentas podemos citar:

SGBDs, ferramentas de Modelagem de Dados, repositórios de modelos de dados, repositórios de metadados, ferramentas de MDM3, ferramentas de Qualidade de Dados e ferramentas customizadas para apoiar as atividades.

6.5. Documentos da Governança de Dados Os documentos da Governança de Dados fazem parte da metodologia de Gestão de Dados das empresas. De forma geral, eles são elaborados pelo staff de pro ssionais da Gestão de Dados e validados e aprovados pelos executivos seniores das empresas. Os documentos circulam em vários níveis da empresa. Os documentos de alto nível estabelecem os objetivos e as diretrizes no patamar da estratégia de dados. Já os procedimentos e roteiros orientam as atividades rotineiras de controle da Governança de Dados. 6.5.1. Estratégia de Dados Quando estabelecemos um programa de Governança de Dados, devemos ter em mente quais são os objetivos, as principais premissas e as direções que devem ser seguidas para traçar planos de ação de alto nível que permitam atingir as metas estratégicas acerca dos dados. Vale ressaltar que as metas estratégicas devem estar aderentes às estratégias do negócio. Essas informações são geralmente de nidas em um documento de alto nível que representa a Estratégia de Dados da empresa. A Estratégia de Dados é o principal documento que formaliza e reconhece as atividades de Gestão e Governança de Dados na empresa. Através dela conseguimos dar reconhecimento formal às atividades e também institucionalizar áreas e organizações de apoio que irão atuar na Gestão dos Dados da empresa. Também é importante destacar no documento o reconhecimento do dado como um importante ativo da empresa.

A criação e guarda deste documento é feita pelo Conselho de Governança de Dados. Sua divulgação deve ser ampla. A Estratégia de Dados é um documento que deve circular em todos os níveis da empresa, desde a presidência e os conselhos até o chão de fábrica. De forma geral, os componentes comuns de uma estratégia de dados são os seguintes: Missão e visão para a Gestão de Dados na empresa. Contribuição da Gestão de Dados à estratégia da empresa. Princípios orientadores, valores e crenças referentes à Gestão de Dados. Institucionalização, objetivos e metas do programa de Governança de Dados. Descrição das organizações de apoio à Gestão e Governança de Dados, bem como suas responsabilidades. Descrição dos papéis atuantes na Gestão de Dados, bem como suas responsabilidades. Outros componentes podem ser incluídos na Estratégia de Dados: caso de negócios, medidas de sucesso, indicadores de desempenho estratégico, iniciativas de Gestão de Dados, etc. Conforme dito antes, não existe uma receita de bolo especí ca em Gestão e Governança de Dados. Cabe a cada empresa avaliar e implementar o que achar de melhor em sua Estratégia de Dados. 6.5.2. Política de Dados As políticas de dados são regras gerais e fundamentais que devem ser adotadas pelos pro ssionais envolvidos com os dados, desde o seu projeto, criação, utilização, até o descarte.

As políticas de dados são elaboradas por pro ssionais de Gestão de Dados, tanto da área técnica quanto de negócio. Ao contrário da estratégia de dados, que é escrita em um documento único, as políticas de dados podem ser escritas em vários documentos, geralmente divididas nas funções de Gestão de Dados adotadas pela empresa. Exemplos: Política para Arquitetura de Dados. Política para Modelagem de Dados. Política para Integração de Dados. Ao contrário da Estratégia de Dados, a Política de Dados é escrita por pro ssionais de Gestão de Dados. Seu conteúdo é resultante do trabalho de algum Comitê de Gestão de Dados. É extremamente recomendável que as políticas sejam validadas pelo Conselho de Gestão e Governança de Dados. Quanto à visibilidade dos documentos, ao contrário da Estratégia de Dados, as políticas de dados não precisam ser conhecidas por todos os integrantes de uma empresa. Geralmente a divulgação e o acesso aos per s que estarão envolvidos nas atividades de Gestão de Dados são su cientes. 6.5.3. Normas e padrões Normas e padrões são documentos que regulamentam a criação de artefatos resultantes das atividades previstas dentro dos processos de Gestão de Dados. Esses documentos têm caráter normativo, ou seja, o cumprimento do que está escrito no documento deve ser respeitado. Como características principais, normas e padrões descrevem o que fazer e o que não fazer. São diferentes dos procedimentos e roteiros que descrevem como fazer. Entre exemplos de Normas e Padrões comuns podemos destacar:

Padrão de nomenclatura de objetos de banco de dados. Padrão de nomenclatura para Modelagem de Dados. Padrão para solicitação de acesso a dados corporativos. Norma para segurança da informação. Algumas pessoas costumam perguntar quando se usa uma norma e quando se usa um padrão – além disso, qual a diferença entre eles? Em Gestão de Dados, não existe uma de nição padrão para cada tipo de documento. De forma geral, costumo adotar o seguinte critério: se o conteúdo é comum no mercado e existe algum documento de referência escrito por alguma entidade o cial técnica ou regulamentar (exemplo: ISO, ABNT, etc.); e se boa parte do conteúdo do documento será utilizada, classi co o documento como norma. Se o documento é interno, adaptado às características da empresa, classi co o documento como padrão. Algumas pessoas costumam discordar do critério citado e alegar que norma é algo obrigatório e o padrão não, pois este representaria uma prática recomendada e de ampla aceitação no mercado, mas não tornada obrigatória. Eu discordo deste argumento, pois a justi cativa dada para um padrão é mais bem de nida para outro tipo de documento: a boa prática. No meu ponto de vista, um padrão também é obrigatório, pois estabelece um formato, gabarito ou forma que algo deve seguir. Sem esta obrigatoriedade o padrão cai em desuso. 6.5.4. Procedimentos

Ao contrário de normas e padrões que são documentos normativos, os procedimentos ou roteiros têm como principal característica orientar as pessoas na execução de algo para atingir algum propósito, seja ele uma simples requisição, produção de um artefato ou operação de manipulação dos dados. Na prática, os procedimentos são uma espécie de “receita de bolo”. Entre exemplos de procedimentos e roteiros podemos citar: Roteiro para solicitar tarefas à equipe de Gestão de Dados. Roteiro para carregar metadados no repositório de metadados. Procedimento para efetuar engenharia reversa em bancos de dados. Procedimento para solicitar acesso a bases de dados.

6.6. Estruturas formais de apoio à Gestão de Dados As estruturas formais são grupos de apoio formados por pro ssionais que atuam ou têm alguma interação com a disciplina de Gestão de Dados. De forma geral, fornecem suporte às demais equipes de Gestão de Dados e atuam em processos decisórios, como é o caso dos integrantes do Conselho de Governança de Dados. Sua atuação abrange desde o nível operacional e tático até a passagem pelo nível estratégico, onde o Conselho de Governança de Dados de ne as principais diretrizes de gestão e governança que serão adotadas por toda a empresa. As estruturas são formalmente constituídas e geralmente possuem lideranças que respondem pelos passos e pelas decisões das estruturas. Dependendo da maturidade da empresa, elas podem ser adotadas em conjunto, como no caso das empresas mais maduras em Gestão de Dados, ou então isoladas, onde apenas uma ou duas estruturas são adotadas na empresa.

Vale ressaltar que, ao adotar pelo menos uma das estruturas formais de apoio, a empresa já possui um nível razoável de maturidade. A gura a seguir mostra como as estruturas formais de apoio à Gestão de Dados podem ser adotadas nas empresas.

Figura 6.4 – Estruturas de apoio à Governança de Dados

6.6.1. Escritório de Gestão de Dados Dependendo do tamanho da empresa e do volume de solicitações aos pro ssionais de Gestão de Dados, pode se tornar necessária a criação de um Escritório de Gestão de Dados. Este escritório pode ser composto por Gestores Técnicos de Dados e Gestores Estratégicos de Dados, que atuam como facilitadores e prestam suporte às atividades e à tomada de decisão dos gestores de dados de negócio em todos os níveis. Um dos objetivos principais deste escritório é oferecer suporte em tempo integral para os gestores de dados de negócio, gestores técnicos de dados e também, quando necessário, aos gestores das informações.

Este suporte pode ser dado tanto no nível operacional, oferecendo mão de obra especializada para execução das tarefas que costumam ser “braçais” e “repetitivas”, como no nível tático, onde os Gestores Estratégicos de Dados e Gestores de Dados Seniores (técnicos e de negócios) oferecem suporte tático na utilização da disciplina. Todas as atividades executadas pelo escritório, sejam elas operacionais e/ou táticas, são importantes subsídios para alimentar os indicadores dos processos e fontes de informação precisas para tomada de ações em um nível maior. A tabela a seguir demonstra alguns exemplos de atividades executadas por Escritórios de Gestão e Governança de Dados. Atividade

Tipo

Alimentar indicadores de utilização e qualidade dos dados e estruturas de dados

Operacional

Avaliar modelos de dados

Operacional

Disponibilizar conceitos de entidades

Operacional

Efetuar treinamento em Gestão de Dados

Operacional

Implementar modelos homologados em ambientes de banco de dados

Operacional

Prestar suporte na utilização da metodologia de Gestão de Dados vigente

Operacional

Disponibilizar relatórios sobre o uso de entidades corporativas

Operacional

Prestar suporte em atividades de consultas a banco de dados

Operacional

Solicitar permissão de acesso aos Gestores de Informação

Operacional

Disponibilizar modelos de dados

Operacional

Efetuar análise de impacto dos dados em relação às mudanças

Operacional

Apoiar a de nição de conceitos corporativos

Tática

Avaliar indicadores de utilização e qualidade dos dados e estruturas de dados

Tática

Avaliar metodologia de Gestão de Dados vigente

Tática

Identi car e planejar necessidades de capacitação em Gestão de Dados

Tática

Identi car fontes de informações redundantes

Tática

De nir/Reavaliar o processo de Governança de Dados

Tática

Monitorar as atividades executadas pelo escritório

Tática

Identi car e propor Gestores de Informação

Tática

Tabela 6.1 – Relação das atividades que podem ser prestadas por um Escritório de Gestão e Governança de Dados

Em alguns casos, as empresas optam por ter dois escritórios: um voltado às tarefas operacionais e outro de mais alto nível, atuando no nível tático. A de nição do escopo das tarefas atendidas pelo Escritório de Gestão de Dados varia a cada empresa. Por exemplo, um Gestor Técnico de Dados pode atuar de forma mais ampla dentro de uma equipe de Gestão de Dados, orientando a Modelagem de Dados e apoiando os analistas na busca de informações compartilhadas, enquanto outro Gestor Técnico de Dados atua exclusivamente dentro do Escritório de Gestão e Governança de Dados avaliando os modelos de dados produzidos com o apoio do primeiro Gestor Técnico de Dados. Enquanto isso, o Gestor Estratégico de Dados propõe ações de melhoria em cima dos resultados coletados neste tipo de tarefa. O Escritório de Governança de Dados geralmente se reporta ao Executivo de Gestão de Dados (CDO). 6.6.2. Comitês de Gestão de Dados Os Comitês de Gestão de Dados atuam no nível tático da empresa e são responsáveis por tratar novas iniciativas ou ações de melhoria propostas pelo Conselho de Gestão e Governança de Dados. Os comitês podem ser vários e tratam de assuntos especí cos ligados à disciplina de Gestão de Dados. Esses assuntos podem estar ligados ao uso de tecnologia, ao negócio ou a ambos; portanto, não há uma fórmula mágica para estabelecer quem são as pessoas indicadas a participar de cada comitê.

A participação do Gestor Estratégico de Dados é requerida na maioria dos comitês, porém isto não é uma regra. Os comitês funcionam como uma estrutura de projetos, ou seja, são temporários, se destinam a atingir objetivos claros e de nidos e são conduzidos por pessoas dentro de parâmetros prede nidos de tempo, custo e recursos envolvidos. A periodicidade dos encontros dos comitês é mais frequente, sendo geralmente semanais ou quinzenais. Ao m de cada encontro o cronograma das ações do comitê é revisto e podem ser de nidas novas tarefas, que deverão ser atendidas pelos membros dos comitês. Os resultados são acompanhados pelo Conselho de Gestão e Governança de Dados. Se o Gerente do Comitê de Gestão de Dados identi car que o assunto tratado no âmbito do comitê é repetitivo e contínuo, ele deve imediatamente sugerir a sua dissolução e encaminhar o trabalho para uma equipe de atendimento dedicada ou uma comissão gestora. A tabela a seguir mostra alguns exemplos de Comitês de Gestão de Dados. Nome do comitê Dados Mestres de RH

Objetivos/Duração estimada

Participantes

Objetivo: implantar a função de Gerenciamento de Dados Mestres na área de RH da empresa. O escopo do trabalho envolve: a) Adoção da metodologia de MDM vigente. b) De nição dos Dados Mestres de RH. c) Adequação dos Dados Mestres de RH à arquitetura de MDM existente. d) Utilização dos dados de referência existentes. e) Adoção do processo de governança.

Gestor de Dados de Negócio (RH) Gestor Estratégico de Dados Representante da equipe de Gestão Técnica de Dados Gestor de Dados de Negócio (Financeiro) Representante da Infraestrutura Representante do Cliente (RH)

Gerente do comitê Gestor de Dados de Negócio (RH)

f ) Criação e acompanhamento de indicadores de qualidade e utilização. Duração estimada do comitê: doze meses. Objetivo: elevar o grau de qualidade dos modelos de Qualidade dados produzidos pelos na Gestores de Dados de Negócio e Modelagem Projetistas de Dados. de Dados Duração estimada do comitê: seis meses.

Gestor Estratégico de Dados Gestores de Dados Gestor de Negócio Gestores Estratégico Técnicos de Dados de Dados Projetista de Dados

Objetivos: integrar os dados da empresa XPTO, recém-adquirida, com os demais dados mestres e de referência da holding. O escopo da integração envolve: a) Utilização dos Dados Mestres e de referência das áreas de RH e nanceiro, utilizados na holding pela empresa XPTO. b) Estudo do impacto para Integração adoção. da empresa c) Adoção de metodologia de XPTO Gestão e Governança de Dados vigente pela empresa XPTO. d) Criação de uma Arquitetura de Dados aderente à arquitetura utilizada na holding. Obs.: o trabalho do comitê acarretará na alteração dos sistemas em desenvolvimento. Duração estimada do comitê: dezoito meses

Executivo da Gestão de Dados Gerente da equipe de Gestão Técnica de Dados Gestores de Dados de Negócio Gestores Técnicos de Dados Gestor Estratégico de Dados

Gerente da equipe de Gestão Técnica de Dados

Tabela 6.2 – Exemplos de relações de Comitês de Gestão de Dados vigentes em uma empresa

6.6.3. Conselho de Governança de Dados Este conselho é a maior autoridade em Gestão e Governança de Dados na empresa. É formado pelo Executivo de Gestão de Dados (CDO) e também

por executivos da alta administração da empresa (gerentes seniores e diretores). O objetivo deste conselho é chancelar as decisões, estratégias e diretrizes de Gestão e Governança de Dados dentro do âmbito estratégico da empresa. Os assuntos tratados neste conselho estabelecem todas as diretrizes que devem ser adotadas em relação à Gestão e Governança de Dados em toda a empresa. É recomendado que o comitê seja presidido por um executivo com alto prestígio e poder na empresa, preferencialmente o Presidente ou VicePresidente. Cabe ao Executivo de Gestão de Dados (CDO) atuar como um importante facilitador neste conselho, assessorando a direção do Comitê. Uma das cadeiras deste comitê também deve ser reservada para um integrante da área de TI. As demais cadeiras deste comitê são destinadas aos executivos das áreas de negócio da empresa. Em alguns casos, a direção do conselho pode ser feita pelo CDO ou então pelo representante da área de TI, porém deve-se ter em mente que este tipo de abordagem irá requerer um esforço adicional para manter as áreas de negócio alinhadas aos propósitos da gestão estratégica de dados. O termo “Governança” deve compor obrigatoriamente o nome do comitê. A Governança de Dados é considerada uma função estratégica, de alto nível, tratada na esfera executiva das empresas; portanto, nada mais adequado do que utilizar este termo na nomenclatura do comitê. Um Conselho de Governança de Dados atua em forma de encontros periódicos. Recomenda-se uma periodicidade mínima de dois meses entre cada encontro. Além dos integrantes xos do conselho, as reuniões podem contar com convidados especiais que fornecem subsídios para tomadas de decisões que são discutidas em cada encontro.

O resumo de cada encontro, as decisões e as ações propostas são divulgados para todos os envolvidos. Em casos especiais, o Conselho de Governança de Dados também pode delegar responsabilidades para um ou mais Comitês de Gestão de Dados em caso de sobrecarga nos assuntos que são tratados. A gura a seguir mostra um exemplo da composição das cadeiras (membros ativos) de um conselho de Gestão e Governança de Dados.

Figura 6.5 – Membros atuantes em uma reunião do Conselho de Governança de Dados

6.7. Dicas para implantar um programa de Governança de Dados Seguem algumas dicas úteis na implantação de um programa de Governança de Dados. Entenda todas as referências sobre Governança de Dados e utilize o que há de melhor nelas.

Sem dúvida alguma, o guia DAMA-DMBOK® possui um dos mais completos frameworks sobre o assunto Governança de Dados, entretanto,

outras referências devem ser levadas em consideração na hora de desenhar o modelo de governança que será adotado no programa. O framework do Data Governance Institute utiliza uma abordagem não tão completa, mas possui um visual simples do que deve ser feito em um programa de Governança de Dados. O processo uni cado de Governança de Dados da IBM fornece um passo a passo simples para implantação inicial de um programa de Governança de Dados. En m, nenhuma referência deve ser adotada como uma única receita de bolo. Cabe a cada empresa avaliar as características de cada escola/referência e adotar o que mais se adequa à realidade da empresa. Obtenha um patrocinador forte

Esta dica é fundamental para implantação de qualquer atividade estratégica dentro de uma empresa. O CDO terá um papel importante na adoção de um programa de Governança de Dados, porém, sozinho, atuando como patrocinador único, fatalmente não conseguirá o apoio das demais áreas executivas. O patrocinador ideal para uma iniciativa como esta deveria vir da própria direção da empresa (presidente ou vice) ou então do conselho administrativo. Patrocinadores com peso político e de poder inferior ao CDO devem ser descartados. Entender que a Governança de Dados é um programa e não um mero projeto

A adoção da Governança de Dados nas empresas tem as características de continuidade e evolução ininterrupta. O andamento dos processos deve ser constantemente analisado e melhorado através de projetos visando à melhoria contínua da governança. Se encararmos a governança como um simples projeto perderemos essa visão, tornando o uso da Governança de Dados limitada a características e

requisitos do seu projeto de implantação, sem evoluir durante o tempo. Utilize a Arquitetura de Dados como um dos principais instrumentos de apoio às atividades de Governança de Dados

Não existe um programa de Governança de Dados e caz sem uma Arquitetura de Dados Corporativos já de nidos. Os modelos de dados representados na Arquitetura de Dados são úteis à Governança de Dados para: Identi car os principais metadados corporativos. Identi car os Gestores das Informações. Identi car os dados críticos da empresa. Identi car os níveis de segurança dos dados corporativos. Delimitar fronteiras. Servir de base para de nição dos escopos dos projetos de Governança de Dados. Fornecer uma visão única sobre o acervo dos dados. Estabeleça no mínimo um Conselho de Governança de Dados e um Comitê de Gestão de Dados

Os integrantes do Conselho de Governança de Dados atuam nos mais altos níveis estratégicos da empresa. Decisões a respeito dos dados estratégicos devem ser tomadas aqui, neste canal. Um dado corporativo e estratégico ui dentro de várias áreas da empresa. Estando todos os representantes dessas áreas reunidos em um comitê, a decisão é tomada de forma consensual e rápida. Sem o Conselho, a decisão seria demorada, nem sempre consensual e, além disso, corre-se o risco do processo decisório car perdido dentro da burocracia da empresa.

Já um Comitê de Gestão de Dados tem como principal objetivo tratar de iniciativas especí cas sobre a Gestão de Dados, geralmente implementadas através de projetos. Se um programa de Governança de Dados é contínuo, com iniciativas sendo implantadas no decorrer do tempo, não há sentido em não haver no mínimo um Comitê de Gestão de Dados vigente. Implemente a Governança de Dados através de passos sequenciais e em etapas

A implementação deve ser feita de forma gradual. A abordagem de implantação em projetos-piloto, divididos por áreas de negócio, costuma ser uma boa estratégia. Quanto aos passos para implantação, não existe uma fórmula especí ca. A IBM, através do seu Data Governance Framework, criado por Sunil Soares, estabelece quatorze passos sequenciais que podem ser adotados para implantar um programa de Governança de Dados: 1. De nir os problemas do negócio. 2. Obter patrocinador executivo. 3. Realizar avaliação da maturidade. 4. Desenvolver roteiros. 5. Estabelecer modelo de dados da organização. 6. Desenvolver Dicionário de Dados. 7. Entender os dados. 8. Criar repositórios de metadados. 9. De nir métricas. 10. Gerir dados mestres incluindo: governar dados mestres, gerenciar qualidade dos dados e implementar MDM. 11. Governar dados analíticos. 12. Gerenciar segurança e privacidade.

13. Gerenciar ciclo de vida da informação. 14. Medir resultados. Vale ressaltar que os passos 10, 11, 12 e 13 são opcionais.

6.8. Atividades necessárias para manter um programa de Governança de Dados segundo o DAMA-DMBOK® Já vimos neste capítulo que um programa de Governança de Dados é contínuo e envolve vários papéis e atividades. O Guia DAMA-DMBOK® estabelece uma série de atividades divididas em dois grupos: Planejamento da Gestão de Dados e Controle da Gestão de Dados. As de nições e os conceitos passados durante esse capítulo são fundamentais para o entendimento das tarefas indicadas pelo guia. Entre as tarefas do Planejamento da Gestão de Dados, o guia indica: Entender as necessidades estratégicas de dados da organização: ou seja, para onde a empresa caminha e quais dados são necessários para prosseguir nessa jornada. Desenvolver e manter a estratégia de dados: criar documento de alto nível alinhado à estratégia da empresa para institucionalizar a Governança de Dados na empresa. Estabelecer os papéis dos pro ssionais e das organizações de dados: é a formalização dos papéis dos Gestores de Dados, do Executivo de Dados, dos Gestores da Informação e das estruturas que fornecem apoio às atividades de Governança de Dados, como as equipes de Gestão de Dados, Conselho e Comitês de Gestão de Dados.

Identi car e apontar os gestores dos dados: signi ca selecionar os Gestores de Dados de Negócio que atuarão em cada segmento. Estabelecer organizações de Gestão e Governança de Dados (áreas de apoio): é a implementação das estruturas de apoio e dos papéis estabelecidos anteriormente. Aqui novos papéis e estruturas começam a atuar efetivamente. Desenvolver e aprovar políticas, padrões e procedimentos de dados (documentos da Governança de Dados): é o desenvolvimento de toda a metodologia que suportará os processos de Gestão e Governança de Dados. Rever e aprovar a Arquitetura de Dados: é a análise da Arquitetura de Dados atual e, se necessário, a criação de planos de ação para estabelecer uma Arquitetura de Dados alinhada à estratégia da empresa. Planejar e patrocinar projetos e serviços de Gestão de Dados: é a identi cação, de nição, priorização e o planejamento dos projetos necessários à implantação de uma Governança de Dados efetiva. Estimar o valor dos ativos de dados e custos associados: é a valoração dos custos positivos (ligados ao reuso, à mudança de cultura, etc.) e negativos (ligados aos riscos da imagem e reputação) dos dados estratégicos da empresa. Já entre as tarefas do Controle da Gestão de Dados, o guia indica: Supervisionar equipes e organizações pro ssionais de dados: através da atuação do Executivo de Gestão de Dados, pessoas (gerentes e coordenadores de dados) e estruturas que apoiam a Gerência Estratégica de Dados.

Coordenar atividades de Governança de Dados: através dos pro ssionais que atuam em posição de liderança em suas funções. Gerenciar e resolver questões relacionadas aos dados: geralmente através das reuniões do Conselho de Governança de Dados ou Comitês de Gestão e Governança de Dados. Monitorar e forçar o cumprimento dos regulatórios: através de veri cações pontuais. Monitorar e forçar a conformidade com as políticas, os padrões e as arquiteturas de dados: através de veri cações rotineiras executadas pelos pro ssionais de Gestão de Dados. Supervisionar projetos e serviços de Gestão de Dados: através dos pro ssionais de Gestão de Dados, com o apoio da metodologia de Gestão e Governança de Dados vigente. Comunicar e promover o valor dos ativos de dados: através dos pro ssionais de Gestão de Dados em workshops, canais de divulgação e no contato diário em suas atividades.

7. Modelagem de Dados “A obediência ao dever é uma resistência a si mesmo.” Henri Bergson

7.1. Modelagem de Dados – Principais conceitos Podemos de nir Modelagem de Dados como um processo onde, através do levantamento dos requisitos de informação e regras de negócio, aplicando técnicas e mecanismos de abstração, construímos artefatos (modelos de dados) com uma visão estática das aplicações nas quais os dados serão armazenados. Os modelos de dados são artefatos que representam de forma estática a captura dos requisitos de informação e as regras de negócio através das entidades (ou classes), atributos, relacionamentos e demais regras representadas em formas grá cas e textuais. Atualmente a Modelagem de Dados não é encarada como uma função especí ca dentro da versão atual do guia DAMA-DMBOK®. No guia, a Modelagem de Dados está inclusa na função “Desenvolvimento dos Dados”, junto com outras atividades focadas em dados dentro do ciclo de vida do desenvolvimento de aplicações, tais como: levantamento e análise dos requisitos, implementação dos modelos de dados nos SGBDs e disponibilização de dados armazenados nos SGBDs.

Entretanto, segundo os dras da próxima versão do DMBOK®, a função “Desenvolvimento de Dados” será extinta e será criada uma nova função denominada Modelagem e Projeto de Banco de Dados. Ou seja, em um futuro próximo haverá uma função especí ca para Modelagem e Projeto de Banco de Dados no guia DAMA-DMBOK®. Além disso, as funções de implementação dos modelos estarão na nova função “Armazenamento dos Dados”, e as formas de consumo dos dados armazenados serão detalhadas na função “Integração de Dados”. Esta mudança será muito positiva. A nal, este artefato é tido como um dos principais da Gestão de Dados. Atualmente, considero a Modelagem de Dados uma das principais funções, mesmo que ainda não o cializada, da Gestão de Dados. Os modelos de dados são utilizados em várias funções da Gestão de Dados. Como exemplo, podemos citar as funções: Arquitetura de Dados: onde os modelos de dados corporativos são representados, fornecendo informações das principais entidades de negócio corporativas da empresa. Governança de Dados: os modelos de dados exercem um importante papel nesta função. Através deles podemos identi car quais gestores das informações, pessoas ou aplicações têm acesso aos dados representados em cada modelo. Modelagem de Dados: função especí ca para análise, especi cação e implementação dos modelos de dados. É nesta função que os modelos de dados são criados. Integração das informações: os mecanismos de integração de informação podem ser representados nos modelos de dados. Várias ferramentas para Modelagem de Dados fornecem recursos para criação

de propriedades especí cas, onde as informações sobre os mecanismos de integração utilizados podem ser representadas facilmente. Gestão de Metadados: boa parte dos metadados das empresas é representada através dos modelos de dados das aplicações. A gestão de todos esses modelos, incluindo a sua guarda e disponibilidade, é feita através da função Gestão de Metadados. As técnicas de construção e representações acerca dos modelos de dados são muitas. Este livro irá trabalhar com as formas mais tradicionais de modelagem relacional adotadas pelo mercado. Os modelos de dados são criados e ajustados dentro de várias fases do ciclo de vida do sistema. Para cada fase são recomendados modelos com diferentes graus de abstração, representação e detalhamento. Esta abordagem resulta em uma divisão onde três tipos de modelos são adotados. São eles: Modelo Conceitual de Dados. Modelo Lógico de Dados. Modelo Físico de Dados. Os próximos itens detalharão as técnicas e os conceitos básicos para a construção desses modelos.

7.2. Modelo Conceitual de Dados Um Modelo Conceitual de Dados é de alto nível. Sua principal nalidade é capturar os requisitos de informação e regras de negócio sob o ponto de vista do negócio. Ou seja, é um modelo que não sofre interferência de fatores tecnológicos e de projeto em sua construção. É um modelo não tecnológico e não implementável.

É o primeiro modelo que deve ser desenvolvido, já na fase de levantamento de requisitos, preferencialmente pelo Gestor de Dados de Negócio ou outro pro ssional acompanhado de sua supervisão/orientação. Entre os componentes de um modelo conceitual, podemos relacionar: Entidades. Atributos. Relacionamentos. Regras de Negócio. As formas de representação dos componentes mudam nas diversas notações utilizadas no mercado (Peter Chen, James Martin, IDEF1X, Merise, etc.). Este livro adotará uma adaptação da notação do Peter Chen na representação dos modelos conceituais de dados. Também vale a pena destacar o crescimento de modelos conceituais desenvolvidos seguindo a representação da UML4. Neste caso, é utilizado o diagrama de classes com a representação das classes de negócio. 7.2.1. Entidades Formam um conjunto de coisas com conceitos comuns onde desejamos armazenar os dados. Entidades podem ser pessoas, lugares, organizações e objetos físicos e tangíveis. As entidades são representadas através de um retângulo com o seu nome escrito em seu centro. Conforme gura a seguir, as entidades são classi cadas em dois tipos: forte e fraca.

Figura 7.1 – Notação de entidade forte x entidade fraca

As entidades fortes possuem um alto grau de independência de existência de identi cação. Outras entidades podem depender dela para serem identi cadas. Podemos tomar como exemplo a entidade “BANCO”, cuja existência não depende de nenhuma outra entidade para ser identi cada. As entidades fracas possuem dependência de existência e/ou identi cação. São sempre ligadas a outras tabelas através de relacionamentos. Podemos tomar como exemplo a entidade “AGÊNCIA”, cuja existência e identi cação estão vinculadas a outra entidade forte – no caso, o “BANCO”. 7.2.2. Relacionamentos Relacionamentos são associações entre entidades com um signi cado especí co dentro do mundo real. Os objetos do mundo real não ocorrem de forma isolada; eles se associam ou se vinculam. Um relacionamento é representado através de um losango e, tal como as entidades, é classi cado em forte ou fraco. Tal como as entidades, os relacionamentos também possuem nome e devem expressar o real signi cado dentro do contexto modelado. A gura a seguir mostra como os relacionamentos são representados em um Modelo Conceitual de Dados.

Figura 7.2 – Notação de relacionamento forte e relacionamento fraco

Na gura anterior, “DEPENDENTE” é uma entidade fraca em relação ao “EMPREGADO”. Sempre que esta relação existir de forma fraca, o relacionamento também será fraco; por esta razão o losango desta relação está representado com uma linha dupla. Já na relação entre “EMPREGADO” e “CARGO” não há dependência de existência ou identi cação, pois um “CARGO” não depende de um “EMPREGADO” para existir e ser identi cado, e vice-versa. Quando tratamos de relacionamentos, devemos ter em mente três conceitos importantes que in uenciam diretamente na modelagem e no entendimento de um modelo conceitual. Os conceitos são o grau, a cardinalidade e o tipo do relacionamento. 7.2.2.1. Grau dos relacionamentos O grau de um relacionamento corresponde ao número de entidades envolvidas na mesma relação. O grau de um relacionamento pode ser: Binário: onde duas entidades participam de um relacionamento. Este é o grau utilizado na maioria dos relacionamentos. Ternário: onde três entidades participam de um relacionamento.

N-ário: Onde quatro ou mais entidades participam de um relacionamento. Muito se discute sobre o uso e a aplicabilidade de relacionamentos com grau maior que dois (ternários e “n-ários”) em modelos de dados. Alguns autores sugerem inclusive que esses relacionamentos não sejam adotados. A gura a seguir mostra exemplos comuns de graus de relacionamentos.

Figura 7.3 – Grau dos relacionamentos em modelos conceituais

7.2.2.2. Cardinalidade Cardinalidade representa a quantidade de vezes que um elemento de um conjunto de entidades pode, em um determinado instante, estar associado, em um dado relacionamento, a outros elementos de outras entidades. A cardinalidade de uma relação é de nida em cada um dos sentidos do relacionamento por um conjunto (x,y) onde x representa a cardinalidade mínima e y representa a cardinalidade máxima. A cardinalidade mínima é responsável por orientar a obrigatoriedade (opcionalidade) do relacionamento. Já a cardinalidade máxima é responsável por de nir a quantidade máxima de vezes que um elemento pode estar associado no relacionamento. Até agora, por ns didáticos, a cardinalidade não estava sendo representada nos exemplos deste livro, mas vale a pena destacar que seu uso

é obrigatório, pois as cardinalidades re etem regras que obrigatoriamente devem ser representadas em um Modelo Conceitual de Dados. A gura a seguir mostra um exemplo de uso das cardinalidades em um relacionamento dentro de um Modelo Conceitual de Dados.

Figura 7.4 – Exemplo do uso de cardinalidade nos relacionamentos

No exemplo acima, um “EMPREGADO” trabalha em uma e somente uma “EMPRESA” e em uma “EMPRESA” trabalham nenhum ou vários “EMPREGADOS”. Ou seja, dentro do contexto que foi modelado, é impossível existir um “EMPREGADO” sem uma “EMPRESA” associada, porém é totalmente viável criar uma “EMPRESA” e não associar inicialmente algum “EMPREGADO”. 7.2.2.3. Tipos de relacionamentos O simples fato de associar duas entidades através de um relacionamento com suas cardinalidades às vezes não é su ciente para representar todas as regras de negócio existentes dentro dessas relações. Para isso podemos usar mecanismos de representação um pouco mais detalhados. Sob esta ótica, podemos ainda classi car os relacionamentos em três tipos: Relacionamentos independentes. Relacionamentos contingentes. Relacionamentos mutuamente exclusivos. Relacionamentos independentes

Tipo de relacionamento presente na maioria das relações. Não há necessidade de interpretação simultânea de outro relacionamento. Ou seja, não depende de ninguém para existir ou in uenciar o seu comportamento. Relacionamentos contingentes Estabelecem associações simultâneas entre os elementos envolvidos. Ou seja, mais de um relacionamento deve ocorrer em um mesmo instante. Sua representação é recomendada, pois envolve regras de negócio especí cas que, se não mapeadas neste momento, fatalmente serão esquecidas mais adiante no decorrer do projeto. A gura a seguir mostra um exemplo de relacionamento contingente.

Figura 7.5 – Exemplo de relacionamento contingente

No exemplo anterior é impossível alocar empregados em um projeto sem um gerente de nido e também não é possível de nir um gerente para um projeto sem existir empregados alocados no projeto. Ou seja, os dois relacionamentos devem ocorrer no mesmo instante. Relacionamentos mutuamente exclusivos Neste caso, se um relacionamento ocorre, os outros não deverão ocorrer em relação a um determinado objeto. Sua representação é recomendada, pois envolve regras de negócio especí cas que, se não mapeadas neste momento, fatalmente serão

esquecidas mais adiante no decorrer do projeto. A gura a seguir mostra um exemplo de relacionamento mutuamente exclusivo.

Figura 7.6 – Exemplo de relacionamento mutuamente exclusivo

O exemplo anterior re ete uma obra gerida por uma “EMPRESA PRIVADA” ou por uma “UNIDADE FEDERATIVA” ou por um “MUNICÍPIO”. Ou seja, três tipos de entidades podem gerir uma obra, porém somente uma é a entidade gestora. 7.2.3. Atributos Os atributos são informações que caracterizam as entidades e os relacionamentos. Um atributo pode identi car, descrever, quali car, quanti car ou registrar o estado/situação/ocorrência de uma entidade. No modelo conceitual são representados através de um “pirulito” colocado junto às entidades. Os atributos podem ser classi cados em quatro tipos: Atributo identi cador: representado através de uma bola cheia na extremidade do atributo. Atributos identi cadores compõem a identi cação única de uma ocorrência em uma entidade. Vale ressaltar

que uma entidade e/ou relacionamento pode possuir mais de um atributo identi cador, desde que, em conjunto, componham a identi cação única. Atributo não identi cador: representado através de uma bola vazia na extremidade do atributo. Corresponde à maioria das ocorrências de uma entidade. Além disso, atributos não identi cados podem ser opcionais, ou seja, em algumas instâncias de entidade, alguns atributos poderão conter valores nulos. Atributos multivalorados: representados através de uma or ou asterisco na extremidade do atributo. Atributos multivalorados são utilizados para representar mais de uma ocorrência de valor de um atributo dentro de uma mesma instância de uma entidade. Exemplo: geralmente uma pessoa possui mais de um número de telefone. Como o objetivo do modelo conceitual é capturar a essência do negócio sem levar em conta aspectos de implementação, este tipo de abordagem é utilizado para representar todas essas instâncias em um único atributo, porém deve-se ter em mente que este tipo de abordagem não deve ser utilizado a partir da modelagem lógica de dados, onde entrarão em cena os conceitos de normalização. Atributos compostos: representados através de uma oval com vários nós na extremidade do atributo. Atributos compostos são utilizados para representar mais de um tipo de informação (quali cação) em um atributo. Tal como o atributo multivalorado, seu uso é recomendado somente no Modelo Conceitual de Dados. A gura a seguir mostra os tipos de atributos utilizados em um Modelo Conceitual de Dados.

Figura 7.7 – Notações utilizadas em atributos

O exemplo anterior representa atributos comuns aos alunos de qualquer instituição: o número da matrícula é um atributo identi cador e o nome do aluno é um atributo não identi cador. Já o atributo telefones é multivalorado, pois representa os diversos telefones que um aluno possui. Endereço é considerado um atributo composto, pois é formado pela composição de UF, Cidade e Logradouro. 7.2.4. Mecanismos avançados de abstração em um Modelo Conceitual de Dados Os mecanismos avançados de abstração são excelentes recursos para melhorar o entendimento e a representação dos modelos de dados. Alguns mecanismos como o autorrelacionamento já são bastante utilizados pelos técnicos que produzem os modelos de dados; outros recursos, nem tanto (como a repetição), e por vezes geram problemas no futuro por falta de uma

representação adequada. Os tópicos a seguir irão detalhar e mostrar exemplos de como esses mecanismos são utilizados. 7.2.4.1. Repetição Existem situações em que uma mesma instância de uma entidade pode selecionar outra mesma instância de outra entidade várias vezes. A repetição permite representar as regras de negócio que expressam a quantidade de instâncias que pode ser estabelecida entre os mesmos elementos das entidades participantes de um relacionamento. Quando trabalhamos com o mecanismo de repetição, é obrigatória a existência de um atributo identi cador no relacionamento onde ocorre a repetição. A repetição é representada no modelo através de um número que indica quantas vezes uma mesma instância de uma entidade pode se relacionar com outra instância mais de uma vez em outra entidade. Se o número de vezes for inde nido utiliza-se a letra “N”. A gura a seguir mostra um exemplo de uso do mecanismo da repetição.

Figura 7.8 – Exemplo do uso da repetição em um Modelo Conceitual de Dados

No exemplo anterior temos a representação de um relacionamento onde são registrados os cartões (amarelo ou vermelho) recebidos pelos jogadores de futebol em uma partida. Conforme regra vigente, um jogador não pode receber dois cartões amarelos em uma mesma partida. Se isto acontecer, o

segundo cartão amarelo é convertido em vermelho e ele é automaticamente expulso da partida. O número 2 colocado em cima do relacionamento “punição” representa esta regra. 7.2.4.2. Autorrelacionamento O autorrelacionamento, também conhecido como relacionamento recursivo, representa a associação entre elementos pertencentes à mesma entidade. Em um autorrelacionamento temos sempre dois papéis formados pelos elementos de uma entidade. A representação desses papéis é obrigatória e fundamental para o entendimento do modelo. Pre ro utilizar um substantivo para nomear o relacionamento e verbos ou expressões verbais para nomear os papéis. Utilizamos um autorrelacionamento quando: Desejamos representar estruturas hierárquicas dentro da mesma entidade. Este tipo de representação sempre utilizará uma cardinalidade (0,1) x (0,N). A gura a seguir mostra um exemplo de utilização de um autorrelacionamento com essas características.

Figura 7.9 – Exemplo do uso de um autorrelacionamento para representar uma hierarquia

Conforme exemplo da gura anterior, conseguimos montar uma estrutura de rede hierárquica de empregados dentro de uma empresa.

Desejamos representar estruturas similares a composições com a mesma entidade. Este tipo de representação sempre utilizará uma cardinalidade (0,N) x (0,N). A gura a seguir mostra um exemplo de utilização de um autorrelacionamento com essas características.

Figura 7.10 – Exemplo de um autorrelacionamento para representar uma composição

Conforme exemplo da gura anterior, conseguimos montar uma estrutura que forma uma composição de materiais. O relacionamento “composição” será responsável por armazenar essas informações. Para ilustrar esta relação com exemplos reais, podemos imaginar que a entidade “MATERIAL” armazena todos os itens materiais de um carro. O relacionamento “composição” será responsável por montar a composição desses materiais. No caso de um carro, existirão várias instâncias de materiais dentro da entidade “MATERIAL”, inclusive o material “motor”. O “motor”, por sua vez, é formado por vários materiais de menor porte e diversas quantidades. Por esta razão foi colocado o atributo “Quantidade” dentro do relacionamento. 7.2.4.3. Generalização e especialização Existem situações onde precisamos representar entidades comuns com um maior ou menor grau de propriedades em cada uma, sempre mantendo uma visão hierárquica entre essas entidades. Dependendo da situação, podemos utilizar a generalização ou a especialização.

A generalização consiste em criar um conceito superior para as entidades existentes mantendo uma relação de hierarquia de entidade entre a nova entidade (entidade pai) e as entidades já existentes (entidades lhas). A gura a seguir demonstra um exemplo de uso do mecanismo de generalização.

Figura 7.11 – Uso da generalização em um Modelo Conceitual de Dados

Já a especialização consiste em criar novos conceitos (entidades lhas) para uma entidade já existente, mantendo uma relação de hierarquia das novas entidades com a entidade pai (já existente). A gura a seguir demonstra um exemplo de uso do mecanismo de especialização.

Figura 7.12 – Uso da especialização em um Modelo Conceitual de Dados

Quando trabalhamos com mecanismos de generalização/especialização utilizamos regras de negócio que representam condições envolvendo especialização. A essas condições damos o nome de cobertura. A cobertura é representada do lado da seta que indica a especialização/generalização por um par de valores (X,Y) onde X representa

o conteúdo e Y representa a cobertura. O valor de conteúdo pode ser representado pelas letras T e P, onde: T = Conteúdo Total (toda instância de um elemento “E” deve pertencer também a uma instância em uma entidade lha especializada). P = Conteúdo Parcial (pode existir uma instância do elemento “E” que não pertença às entidades especializadas). O valor de cobertura pode ser representado pelas letras E e S, onde: E = Cobertura Exclusiva (toda instância do elemento “E” pode existir no máximo em uma instância nas entidades especializadas). S = Cobertura Sobreposição (toda instância do elemento “E” pode existir em várias instâncias das entidades especializadas). 7.2.4.4. Agregação A agregação é um mecanismo de abstração onde criamos um novo conceito a partir dos componentes de uma relação. Usamos a agregação quando sentimos a necessidade de associar um relacionamento ao outro. A gura a seguir mostra um exemplo de uso de uma agregação.

Figura 7. 13 – Exemplo do uso da agregação em um Modelo Conceitual de Dados

No exemplo anterior, foi necessário criar um conceito mais abrangente para poder representar o consumo de um cliente hospedado em um quarto.

Vale ressaltar que, quando utilizamos a agregação, as relações são dependentes. Ou seja, a associação da entidade agregada com a outra entidade só ocorre após a existência do fato (relação) da entidade agregada. No caso, o cliente só poderá consumir serviços após estar hospedado em um quarto.

7.3. Modelo Lógico de Dados Um Modelo Lógico de Dados (MLD) é considerado um modelo de dados implementável. Tal como o Modelo Conceitual de Dados, o modelo lógico utiliza elementos estruturais: entidades, relacionamentos e atributos; porém com um grau maior de complexidade devido às restrições de integridade e regras de normalização. Ao contrário do modelo conceitual que tem como principal objetivo representar o contexto do negócio, o Modelo Lógico de Dados já procura estabelecer soluções de implementação em bancos de dados – claro que respeitando os requisitos de informação e as regras de negócio representadas no modelo conceitual. Recomenda-se que o Modelo Lógico de Dados seja criado a partir do mapeamento do Modelo Conceitual de Dados. A partir daí começa-se um trabalho de re namento para projetar o melhor modelo implementável. Um Modelo Lógico de Dados também pode ser construído a partir do zero, porém toda a questão da participação do cliente no início da modelagem e a captura do ambiente de negócios poderão ser comprometidas. Existem situações, principalmente nos projetos de soware que utilizam o paradigma da orientação a objeto (OO), onde o Modelo Lógico de Dados não é utilizado. A justi cativa para esse “esquecimento” é o fato dos projetos OO não trabalharem com os conceitos de bancos de dados relacionais. Na verdade, em OO modelam-se classes e não entidades.

Além disso, em OO não existe o conceito de normalização. Nesses casos, recomenda-se que o modelo conceitual, representado com as classes de negócio, evolua em seu grau de detalhamento no decorrer do projeto. Esse diagrama de classes, um pouco mais detalhado, poderia suprir parcialmente a necessidade do modelo lógico. Mais adiante, quando for feito o mapeamento do modelo OO para o modelo físico (relacional) de dados, as técnicas utilizadas em um modelo lógico deverão ser aplicadas neste modelo físico, obtido e re nado através do mapeamento objeto x relacional. O per l recomendado para construir modelos lógicos é técnico. O papel do projetista de dados é o mais adequado para efetuar a construção do modelo lógico. O gestor técnico de dados também deve estar envolvido no processo de construção apoiando (dando suporte) a modelagem e validando os modelos produzidos pelos projetistas. Tal como o modelo conceitual, o Modelo Lógico de Dados possui diversas notações utilizadas no mercado. Neste livro utilizaremos a notação da Engenharia da Informação, também conhecida como notação do James Martin ou “pés de galinha”. 7.3.1. Conceitos básicos em Modelagem Lógica de Dados A gura a seguir demonstra um exemplo onde podemos visualizar entidades dependentes e independentes, relacionamentos identi cados e não identi cados, além de chaves primárias, chaves candidatas e chaves estrangeiras. As seções a seguir falarão sobre os principais conceitos e elementos básicos de um Modelo Lógico de Dados.

Figura 7. 14 – Exemplo da notação de um Modelo Lógico de Dados

7.3.1.1. Entidade independente Conceito similar à entidade forte do Modelo Conceitual de Dados. No Modelo Lógico de Dados a entidade independente é representada por um retângulo com os seus cantos retos (90°). Diferentemente do Modelo Conceitual de Dados, o nome da entidade é representado do lado de fora, no canto superior esquerdo. 7.3.1.2. Entidade dependente Conceito similar à entidade fraca do Modelo Conceitual de Dados. No Modelo Lógico de Dados a entidade dependente é representada por um retângulo com os seus cantos arredondados. Diferentementemente do Modelo Conceitual de Dados, o nome da entidade é representado do lado de fora, no canto superior esquerdo. 7.3.1.3. Relacionamento identi cado Relacionamento formado por uma entidade dependente. Ou seja, a chave primária da entidade pai (independente) ajuda a compor a chave primária da entidade lha (dependente). O relacionamento é feito através de uma linha uniforme sem cortes e/ou interrupções.

7.3.1.4. Relacionamento não identi cado Relacionamento onde a chave primária da entidade origem não faz parte da composição da chave primária da entidade destino. O relacionamento é expresso através de uma linha tracejada entre as duas entidades. Um relacionamento não identi cado poderá ser também um relacionamento opcional. Nos relacionamentos opcionais o conteúdo (valor) do atributo da entidade origem não é carregado na entidade destino. 7.3.1.5. Chave primária Uma chave primária é um atributo ou conjunto de atributos cujos valores distinguem e/ou identi cam uma ocorrência dentro de uma entidade. Uma entidade possui apenas uma chave primária. A chave primária também é conhecida como “primary key” ou simplesmente “PK”. 7.3.1.6. Chave candidata Uma chave candidata é um atributo ou conjunto de atributos que são possíveis chaves primárias dentro de uma entidade. Toda chave primária é uma chave candidata, porém nem toda chave candidata é uma chave primária. Uma chave candidata gera uma chave primária ou uma chave alternativa. 7.3.1.7. Chave alternativa A chave alternativa é uma chave candidata que não foi escolhida como chave primária. A chave alternativa também é conhecida como “alternate key” ou simplesmente “AK”. 7.3.1.8. Chave estrangeira Uma chave estrangeira representa um atributo, ou combinações de atributos, cujos valores aparecem necessariamente na chave primária de outra entidade que se relaciona com esta, onde encontramos a chave estrangeira. A chave estrangeira serve, portanto, para implementar

relacionamentos entre entidades dentro de um ambiente relacional. A chave estrangeira também é conhecida como “foreign key” ou simplesmente “FK”. 7.3.1.9. Restrições de integridade Restrições de integridade são mecanismos usados para garantir a exatidão e a consistência dos dados em um banco de dados relacional. Entre os mecanismos mais comuns encontramos: Restrições de chave: onde cada entidade do Modelo Lógico de Dados deve conter uma chave primária ou um de seus atributos de formação; não podem conter valores nulos. Restrições de integridade referencial: onde a chave estrangeira tem que apontar para um registro existente, ou então deve ter um valor nulo caso o relacionamento possua uma cardinalidade mínima igual a zero. Restrições de conteúdo: onde um determinado atributo deve obrigatoriamente possuir um valor ou não. É o que de nimos de atributo nulo ou não nulo. Restrições de domínio: onde o valor de cada atributo deve ser um valor atômico, dentro de um domínio especi cado para aquele atributo. É o que utilizamos mais à frente no modelo físico com as check constraints e check tables. Restrições de integridade semântica: estão ligadas a regras de negócio especí cas. Mais à frente podem ser implementadas via triggers, stored procedures ou mecanismos programados na aplicação. 7.3.2. Normalização A normalização de dados são vários passos seguidos no projeto de um banco de dados, que permitem um armazenamento consistente e um

e ciente acesso aos dados em bancos de dados relacionais. Esses passos reduzem a redundância de dados e as chances dos dados se tornarem inconsistentes. A normalização deve ser feita e/ou aplicada no Modelo Lógico de Dados, porém, caso não seja viável construir um Modelo Lógico de Dados, como por exemplo em um projeto OO, deve-se aplicar esta técnica na transição do projeto OO para o modelo relacional. A técnica de normalização prevê a existência de seis regras, chamadas de formas normais, sendo elas: a primeira (1FN), segunda (2FN), terceira (3FN), quarta (4FN), quinta (5FN) e forma normal Boyce Codd. Quando falamos em normalização, podemos a rmar que uma relação está normalizada se ela está na terceira forma normal (3FN). Por esta razão o livro detalhará apenas as três primeiras formas normais. 7.3.2.1. As formas normais Para aplicar a normalização de dados é necessário considerar a sequência das formas normais, isto é, para aplicar a segunda forma normal, por exemplo, é necessário que seja aplicada a primeira forma normal. Assim, para aplicar a terceira forma normal é necessário que já tenha sido feita a normalização na segunda forma normal. 7.3.2.2. Primeira forma normal (1FN) A de nição clássica da primeira forma normal menciona que uma entidade está na 1FN se, e somente se, possuir uma chave primária e não possuir atributos compostos ou multivalorados. Mas, a nal, o que é isso? Vejamos o exemplo a seguir com as instâncias de dados de uma entidade CLIENTE. Entidade CLIENTE: COD-CLIENTE

NOME-CLIENTE

TELEFONE

123

João das Couves

(21) 8888-8888, (21) 2222-2222

Fulano de Tal

(11)1234-5678, (11) 99999-0000

126

Sicrano da Silva

127

Beltrano

(21) 3333-3333

128

Bergson Lopes

(21)1111-1111

Tabela 7. 1 – Instâncias de dados de uma entidade desnormalizada

Como podemos observar, a entidade não possui uma chave primária de nida. O ideal seria a de nição do atributo COD-CLIENTE como PK5, porém existem ocorrências nulas para este atributo. Além disso, a entidade também possui um atributo multivalorado (telefone) que suporta mais de uma ocorrência de valor. Da forma como está apresentada, não podemos relacionar esta entidade a nenhuma outra, pois não há uma simples PK para fazer essa ligação e também não podemos fazer um trabalho de pesquisa mais apurado em cima das informações do telefone. Para resolver esses problemas devemos normalizar esta entidade. A gura e a tabela a seguir mostram a modelagem e as instâncias de dados do modelo já respeitando as regras da primeira forma normal (1FN).

Figura 7.15 – Exemplo de uma relação na 1FN CODNOMECLIENTE (PK) CLIENTE

COD-CLIENTE (PK e FK)

NR-SEQTELEFONE (PK)

NRDDD

NRTELEFONE

1

João das Couves

1

1

21

8888-8888

2

Fulano de

1

2

21

2222-2222

Tal

2

1

11

1234-5678

3

Sicrano da Silva

2

2

11

999990000

4

Beltrano

4

1

21

3333-3333

5

Bergson Lopes

5

1

21

1111-1111

Tabela 7.2 – Instâncias de dados em uma relação na 1FN

Para normalizar a entidade, foi necessário de nir uma chave primária para a entidade CLIENTE e criar uma nova entidade TELEFONE para armazenar os atributos que eram compostos e multivalorados na solução inicial. 7.3.2.3. Segunda forma normal (2FN) A de nição clássica da segunda forma normal menciona que uma relação está na 2FN se, e somente se, estiver na 1FN e cada atributo não chave for dependente da chave primária inteira, isto é, cada atributo não chave não poderá ser dependente de apenas parte da chave. As anomalias da segunda forma normal ocorrem somente em entidades com chaves primárias compostas com dois ou mais atributos, pois não há dependência parcial em entidades com uma chave primária formada apenas por um atributo. Vejamos o exemplo a seguir com as instâncias de dados de uma entidade APLICACAO_FUNDO. COD-CLIENTE (PK e FK)

COD-FUNDO (PK)

QT-COTAS-APLICADAS

NOME-FUNDO

1

F1

3000

Fundo Especial

2

F1

2340

Fundo Especial

3

F2

17

Fundo Popular

Tabela 7.3 – Instâncias de dados em uma entidade desnormalizada

Como podemos observar, a entidade possui uma chave composta formada pelas colunas do código do cliente e código do fundo. Ao analisar os atributos não chave (quantidade de cotas aplicadas e nome do fundo), podemos perceber que o atributo da quantidade de cotas depende da totalidade da chave, a nal o objetivo desta entidade é armazenar a quantidade de cotas aplicadas em um fundo por determinados clientes. Já o atributo do nome do fundo não depende da totalidade da chave primária, mas apenas do atributo do código do fundo (parte da PK), ou seja, a relação está desnormalizada e este atributo não deve estar aqui. Para resolver o problema devemos normalizar esta entidade. A gura a seguir mostra a modelagem adequada, visando remover a anomalia da 2FN mencionada.

Figura 7.16 – Exemplo de uma relação respeitando as regras da 2FN

7.3.2.4. Terceira forma normal (3FN) A de nição clássica da terceira forma normal menciona que uma relação está na 3FN se estiver na 2FN e se cada atributo não chave não possuir dependência transitiva em relação aos demais atributos da entidade. A dependência transitiva ocorre em casos onde um atributo não é dependente da chave primária, mas de outro atributo da entidade. Quando isto ocorre, dizemos que a entidade (ou relação) não está na terceira forma normal. A gura a seguir mostra um exemplo de violação da 3FN.

Figura 7.17 – Exemplo de violação da 3FN

Podemos observar na gura anterior que a coluna do nome do cargo não depende do atributo da chave primária da entidade, mas do atributo do código do cargo. Ou seja, ocorreu uma dependência transitiva, ocasionando a violação da 3FN. Para resolver este problema devemos normalizar esta entidade. A gura a seguir mostra a modelagem adequada, visando remover a anomalia da 3FN mencionada.

Figura 7.18 – Exemplo de relação respeitando as regras da 3FN

A simples criação da entidade CARGO e a transferência de seus atributos para a nova entidade foi su ciente para normalizar esta relação. Após a aplicação das regras de normalização, algumas entidades acabam sendo divididas em duas ou mais entidades, o que no nal gera um número maior de entidades do que existia originalmente. Este processo resulta na simpli cação dos atributos de uma entidade, além de colaborar signi cativamente para a estabilidade do modelo de dados, reduzindo consideravelmente as necessidades de manutenção.

7.4. Modelo Físico de Dados Um Modelo Físico de Dados (MFD) é considerado um modelo de dados implementado (ou em vias de ser implementado). As características do projeto deste modelo estão ligadas diretamente ao SGBD (Sistema Gerenciador de Banco de Dados) que será utilizado para implementar as estruturas de dados deste modelo. Os três principais bancos relacionais do mercado possuem tipos de dados e alguns mecanismos diferentes entre si. Essas diferenças in uenciam a construção do Modelo Físico de Dados. Tal como os demais modelos, o Modelo Físico de Dados utiliza elementos estruturais. Os principais elementos estruturais do modelo físico são: tabelas, colunas e constraints. Esses elementos são objetos físicos que existem nos bancos de dados. De forma geral, recomenda-se que o Modelo Físico de Dados seja criado a partir do mapeamento do Modelo Lógico de Dados ou então através do mapeamento do modelo OO (classes) para o modelo relacional, aplicando as regras de normalização descritas no modelo lógico. O per l recomendado para construir modelos físicos é técnico. O papel do projetista de dados é o mais adequado para efetuar a construção do modelo físico, junto com o apoio do DBA. O gestor técnico de dados também pode estar envolvido no processo de construção apoiando (dando suporte) a modelagem e validando os modelos produzidos pelos projetistas. Vale ressaltar que o modelo físico também é um artefato e, como tal, deve ser projetado e avaliado antes de ser implementado nos ambientes de banco de dados. A gura a seguir demonstra um exemplo de Modelo Físico de Dados. Repare que o modelo é praticamente o mesmo das soluções dadas nas seções de normalização. A diferença aqui está nos tipos de dados que foram incluídos no modelo.

Figura 7.19 – Exemplo de um Modelo Físico de Dados

7.4.1. O Modelo Físico de Dados e as desnormalizações No caso da imagem anterior, não foi necessária nenhuma alteração muito signi cante no modelo, ou seja, o modelo permaneceu normalizado – entretanto, dependendo da situação, algum tipo de desnormalização pode ser necessário. As desnormalizações devem ser utilizadas com cautela em projetos de bancos de dados relacionais. Durante minha experiência cheguei à conclusão de que as pessoas procuram desnormalizar as relações em um modelo de dados para: Facilitar o trabalho da lógica da programação. Resolver problemas de desempenho. A primeira opção é uma justi cativa totalmente inválida e, infelizmente, ainda é muito utilizada por analistas que não querem perder tempo escrevendo soluções de código mais trabalhadas, principalmente na montagem de queries (SQL). Cabe ao Gestor Técnico de Dados identi car que uma possível desnormalização está sendo proposta somente por essa razão e não permitir o seu uso. Já a segunda opção (performance) pode ser válida, porém, nem sempre um analista ou um Gestor Técnico de Dados

possui conhecimentos para tomar esse tipo de decisão. De forma geral, cabe ao DBA avaliar se a desnormalização é necessária ou não. O DBA é o pro ssional mais indicado para tomar esse tipo de decisão. 7.4.2. Elementos estruturais de um Modelo Físico de Dados Os itens a seguir demonstram os principais elementos estruturais básicos de um Modelo Físico de Dados: Tabelas: são estruturas para o armazenamento de dados, formadas por um conjunto de dados dispostos em um número nito de colunas e ilimitado de linhas. A tabela é um dos principais elementos de um Modelo Físico de Dados. Uma tabela é similar a uma entidade do modelo lógico. Colunas: são unidades básicas de armazenamento de dados em um registro dentro de uma tabela. Uma coluna é similar a um atributo do modelo lógico. Sequences: são objetos que geram números sequenciais dentro do SGBD Oracle. São excelentes em termos de performance, já que armazenam um range de números no cache e também porque tiram do desenvolvedor a responsabilidade de gerenciar a geração de números sequenciais em casos de múltiplos acessos. Sinônimos: são utilizados para fornecer um nome alternativo para uma tabela ou visão presente no mesmo ou em outro esquema. Índices: recurso físico que visa otimizar a recuperação de uma informação, via um método de acesso. Seu objetivo principal está relacionado com a performance da aplicação. Constraints: as restrições de integridade ou constraints são mecanismos utilizados para garantir a integridade dos dados nos bancos de dados

relacionais. São elas: check, not null, unique, primary key e foreign key. Views: são visões parciais de tabelas. Permitem dar uma visão personalizada aos usuários. Além disso, oferecem melhor segurança na disponibilização dos dados. Stored procedures: são “programas” com conjuntos de comandos SQL. Geralmente permitem manipulação procedural dos dados recuperados pelos comandos SQL. As stored procedures são compiladas e mantidas no próprio banco de dados. Triggers: são gatilhos, pequenos códigos dentro do banco de dados, disparados automaticamente por eventos de atualização de bancos de dados. Geralmente são utilizados para obrigar o cumprimento de regras de integridade e de negócio que não são atendidas com os mecanismos mais simples.

7.5. Documentação de um modelo de dados Até o momento, neste capítulo, já debatemos os principais tipos de modelos de dados. Iniciamos com o modelo conceitual, passamos pelo modelo lógico e terminamos com o modelo físico. Em todos os casos, foram passados os seus conceitos especí cos de modelagem e as suas principais características. Entretanto, a assimilação desses conceitos é su ciente para entender profundamente qualquer modelo de dados que venhamos a olhar daqui para frente? Acredito que não. A representação grá ca e a denominação dos elementos que compõem um modelo de dados, de forma geral, não são su cientes para traduzir todos os conceitos envolvidos e que são necessários para caracterizá-los, interpretálos, de ni-los e compreendê-los de forma evidente, tanto para o responsável por sua criação quanto para qualquer leigo em relação ao ambiente modelado que se interesse em conhecê-lo.

Para alcançar tal propósito, faz-se necessário tomar medidas que evitem ambiguidade nas interpretações desses elementos e permitam esclarecê-los por completo. A dicionarização dos elementos dos modelos é um instrumento essencial que possibilita dotá-los de informações que atendam a tais requisitos. A dicionarização dos elementos é considerada parte fundamental do processo de modelagem, já que, por seu intermédio, além dos benefícios citados em relação à leitura do modelo, abrem-se possibilidades de disseminação do conhecimento relativo aos negócios corporativos representados pelos diagramas de negócio e modelos de dados. Além disso, tal prática permite que se realizem levantamentos de similaridades entre objetos de modelos diversos, possibilitando a sua reutilização. As seções seguintes demonstrarão as melhores práticas para a documentação dos modelos de dados. 7.5.1. Boas práticas para dar nomes aos elementos As seguintes práticas podem ser adotadas na nomeação de entidades, atributos e relacionamentos para facilitar o entendimento de um modelo de dados. Todo e qualquer objeto (entidade ou atributo) deve ser nomeado através de uma identi cação unívoca. Seguem dicas de como nomear esses objetos: O nome do objeto deve representar o negócio de forma a não haver dúvidas quanto a sua especi cação. O objeto deve ser nomeado com o seu real signi cado dentro da organização, com uma visão corporativa, não somente dentro do cenário do sistema no qual está sendo modelado.

O nome do objeto deve ser quali cado para que o seu signi cado seja claro e absoluto. Devemos evitar a utilização de nomes muito genéricos para a denominação de um objeto. Exemplo: uma entidade denominada como “ESPECIALIDADE” possui signi cados diferentes dependendo da sua área de aplicação. Se utilizarmos nomes mais quali cados como “ESPECIALIDADE_MEDICA” e “ESPECIALIDADE_FORNECEDOR” não teríamos duas entidades com o mesmo nome, porém com signi cados diferentes. Todo objeto deve ser nomeado quanto ao número no singular, tendo em vista que o signi cado de seu nome quali ca uma única ocorrência de objeto conceitual por vez. Sempre que possível opte por um gênero default (masculino ou feminino) para ns de padronização. Nomes ou siglas departamentais de uma organização devem ser evitados sempre que possível, à exceção de siglas ou abreviaturas já consagradas no meio corporativo. Evite o uso de preposições, artigos e conjunções irrelevantes para o signi cado do objeto. Exemplo: “TIPO_DE_CLIENTE” (não usual) – “TIPO_CLIENTE” (usual). Evite utilizar algarismos na nomeação do objeto. Exemplo: “DT_2_CHAMADA” (não usual) – “DT_SEGUNDA_CHAMADA” (usual). Regras para nomeação de relacionamentos: A estrutura de identi cação nominal para relacionamentos deve ser composta de um verbo ou locução verbal que de na a relação existente entre os objetos, preferencialmente conjugada na terceira pessoa do singular do presente do indicativo.

Havendo necessidade de nomear o relacionamento nos dois sentidos, utilize a voz passiva do verbo que de ne a ação para um dos sentidos, ou outro verbo que seja equivalente, conjugado na terceira pessoa do singular do presente do indicativo. Dê preferência a verbos de ligação (ser, estar, permanecer, etc.), evitando verbos como existir, ter e possuir. Esteja sempre atento ao sentido e à semântica do relacionamento, para que expresse corretamente a regra de negócio. Os autorrelacionamentos devem ser nomeados obrigatoriamente nos dois sentidos. Geralmente, relacionamentos do tipo “um para muitos” possuem a nalidade de representar estruturas do tipo “hierarquia” (pai x lho, por exemplo). Já os autorrelacionamentos do tipo “muitos para muitos” geralmente possuem um sentido de “composição”, “constituição”. 7.5.2. Boas práticas para conceituar (definir) elementos Todo e qualquer objeto deve ser conceituado através de uma de nição unívoca ou declaração de propósitos que esteja em conformidade com um conjunto de regras prede nidas. Seguem dicas de como conceituar esses objetos: A de nição deve explanar o que o objeto é (conceito) em sua essência e com relação ao escopo em análise. Não se deve simplesmente copiar o que está no dicionário ou qualquer outro texto descritivo que referencie o conceito fora do contexto do negócio. A de nição do objeto deve ser clara, completa e objetiva, propiciando a compreensão consistente do objeto e do seu valor para o negócio. Em outras palavras, o que o objeto está fazendo no modelo do negócio?

Deve ser escrita em linguagem não técnica e usando preferencialmente a língua portuguesa. Quando inevitável, termos e expressões em idioma estrangeiro devem ser acompanhados das respectivas traduções. A de nição do objeto deve ser elaborada com base na terminologia do negócio, mas sempre buscando ser compreensível para o leitor leigo ou não especializado. A de nição deve considerar o objeto e seus possíveis papéis no negócio. Cada papel deve ser descrito obedecendo aos requisitos estabelecidos anteriormente. Mesmo sendo o objeto referenciado a múltiplas funções, processos, áreas da organização e visões particulares dos sistemas, ainda assim deverá possuir o seu conceito sempre estável. Caso haja de nições particulares, que restrinjam ou ampliem o conceito de nido, devem estar explicitadas em especializações ou generalizações que descrevam cada uma dessas visões, deixando claro a qual delas pertence. Todo objeto com características de classi cação ou agrupamento (tipo, classi cação, grupo, etc.) opera segundo (em função de) uma ou mais propriedades do objeto que está sendo classi cado/agrupado. Sua de nição, portanto, deve explicitar a(s) propriedade(s) em que se baseia a classi cação. Para atributos, sua de nição deve de nir que característica(s) confere à entidade. A de nição do atributo deve deixar claro o papel (ou papéis) que representa como quali cador da entidade. A de nição do atributo deve conter exemplos para clari cação do conceito. Quando aplicável, especialmente no caso de indicadores, a de nição deve explicitar o domínio discreto que o atributo pode conter.

Exemplo: para o atributo IN_TIPO_PESSOA, poderíamos ter as ocorrências “F” para Pessoa Física e “J” para Pessoa Jurídica. 7.5.2.1. O que evitar na de nição de entidades e atributos? De nição tautológica. Uma de nição não deve conter o nome do objeto antes que este tenha sido previamente de nido. Por exemplo, se, ao de nir a entidade “Cliente”, a descrevermos como sendo: “todo cliente que...”, estamos dizendo o que um cliente faz e não o que um cliente é (seu conceito). Melhor seria algo como: “pessoa física ou jurídica que adquiriu...”. De nição com termos desnecessários. Por exemplo, a expressão “trata-se do conjunto de informações sobre toda e qualquer...” aplica-se à de nição de toda e qualquer entidade e não apenas à entidade especí ca. Por não acrescentar signi cado relevante, torna-se desnecessária, já que, por de nição, todo elemento de um conjunto de objetos compartilha todas as propriedades do conjunto. Da mesma forma, deve-se evitar o uso de expressões como “Esta entidade tem a nalidade de...” ou “Esta entidade foi criada devido........”. Frases muito longas. Em benefício da facilidade de compreensão, uma de nição não deve usar períodos de texto muito longos. Um parágrafo composto de frases curtas, mas objetivas, pode aumentar signi cativamente a clareza da de nição. Formas de utilização e acesso. Descrição de onde, quando, como e por quem o objeto é utilizado. Isto se aplica mais a matrizes de processos x dados. De nições com o caráter exclusivamente físico. Referenciar o objeto como um meio de armazenamento, como por exemplo: tabela, repositório, etc.

7.5.2.2. Exemplos de boas de nições BOLETO_COBRANCA: guia de pagamento representativo de um valor a receber emitido a um sacado para a quitação de um bem ou serviço. O boleto de cobrança deve ser quitado na rede bancária. Atributos da entidade: NR_COBRANCA: identi cador numérico automaticamente atribuído à correspondência eletrônica dirigida a uma empresa, informando-a do evento de cobrança. DT_VENCIMENTO: dia, mês e ano limites para que o pagamento do valor cobrado seja efetivado pelo devedor. VL_COBRANCA: importância cobrada mensalmente à organização a título de prestação de serviços. Este valor é reajustado semestralmente. DT_PAGAMENTO: dia, mês e ano em que foi efetuada a quitação de uma cobrança. VL_MULTA_ATRASO: importância cobrada uma única vez ao devedor inadimplente, a título punitivo, pela quebra de expectativa de receita por parte do credor. Esta importância é xada contratualmente, podendo ser um percentual do valor originalmente cobrado ou uma quantia xa.

CONTRATO_CONCESSAO: documento que o cializa um acordo entre duas ou mais partes (pessoas) que se sujeitam a cumprir as obrigações estabelecidas em um contrato judicial devido à utilização de bens públicos, ou de exploração de recursos naturais (jazidas, energia hidráulica) pertencentes à União. ESPECIALIDADE_MEDICA: classi cação dada pela OMS (Organização Mundial de Saúde) para distinguir ramos e especializações em que um referenciado possa ter condições de atuar. Em casos especí cos, uma especialidade pode ser dividida em várias subespecialidades. Exemplos: Cardiologia, Cardiologia Pediátrica, Cirurgia Cardiovascular, Clínica Geral, Ortopedia, Pediatria, etc.

7.6. Qualidade dos modelos de dados

Os modelos de dados podem ser considerados os principais metadados de uma organização e devem ser criados antes dos dados entrarem efetivamente no ambiente produtivo, portanto nada mais adequado do que estabelecer processos para a veri cação da qualidade deste importante artefato. A nal, sem metadados de qualidade não teremos dados de qualidade! A qualidade dos modelos de dados é atingida através de processos que visam planejar, estabelecer, atender e monitorar os critérios de qualidade estabelecidos para esses modelos. 7.6.1. Processos de qualidade para modelos de dados Um conjunto de processos para qualidade dos modelos de dados pode ser visualizado na gura a seguir.

Figura 7.20 – Processos para qualidade da Modelagem de Dados

Uma boa prática é estabelecer esses processos levando em conta o ciclo PDCA de qualidade, onde:

O planejamento (P) da modelagem estabelece a identi cação das entidades corporativas, mapeadas na Arquitetura de Dados da organização, e também das demais necessidades de informação que serão contempladas na modelagem. Essas informações são capturadas e discutidas nas reuniões prévias de planejamento da modelagem. A construção (D) do modelo de dados é feita com o apoio da equipe de Gestão de Dados (ou pela própria equipe). O analista responsável pelo projeto constrói e altera o modelo de acordo com as diretrizes passadas pelos gestores de dados em reuniões prévias do planejamento. A checagem ou avaliação (C) do modelo de dados é executada pelo Gestor de Dados de acordo com os critérios de qualidade prede nidos na metodologia e registra os dados da avaliação em uma base de registro de dados das avaliações. As ações corretivas (A) visam estabelecer a melhoria contínua e podem ser tomadas tanto para o produto (modelo) quanto para o processo (modelagem). Exemplo: se o modelo (produto) for reprovado, o analista corrige os erros apontados no laudo de avaliação (ação para correção do produto). Com o apoio das ferramentas de qualidade, o Gestor Estratégico de Dados sugere ações após análise dos registros das avaliações efetuadas em todos os modelos de dados em um determinado período (ação para melhoria do processo). De forma geral, esses processos estão ligados às funções de Modelagem de Dados e também à gestão dos metadados da empresa e devem ser de nidos levando em conta as características do uso dessas funções na empresa. Vale ressaltar que a veri cação da qualidade dos modelos de dados deve ser executada através de um processo de avaliação formal dedicado a confrontar o cumprimento dos requisitos de qualidade dos modelos estabelecidos na metodologia de Gestão de Dados da empresa. Ao

estabelecer este processo, devemos levar em consideração alguns fatores, entre eles: Sozinha, a avaliação de modelo de dados não garante a qualidade do artefato. Ela apenas identi ca anomalias encontradas no processo de construção do modelo. Para ter uma qualidade completa é necessária a adoção de processos dedicados à garantia da qualidade desses modelos. Se a própria área de Gestão de Dados é responsável pela criação do modelo de dados, devem ser estabelecidas formas de incluir uma avaliação feita por uma pessoa diferente da que construiu o modelo. A avaliação de modelos de dados deve ser uma atividade formal. Portanto, deve ser prevista a elaboração de laudos técnicos que irão registrar observações, ressalvas e possíveis erros encontrados durante a veri cação da modelagem. Este processo não pode ser subjetivo, portanto os critérios de qualidade dos dados devem ser bem estabelecidos e divulgados para todos os envolvidos. Crie uma lista de veri cação para orientar os gestores de dados na veri cação da qualidade dos modelos. É simples e o conhecimento é disseminado para todos. 7.6.2. Critérios de qualidade aplicados em modelos de dados Os critérios de qualidade dos modelos de dados estabelecem parâmetros para veri cação formal dos modelos e servem como uma espécie de guia para a obtenção da qualidade dos modelos. Entre os critérios mais comuns adotados no mercado, podemos destacar os seguintes. 7.6.2.1. Completeza ou completude

Critério dedicado ao atendimento aos requisitos de informação e regras de negócio dispostos nas especi cações dos sistemas e documentação de apoio. Todas as funcionalidades especi cadas nos requisitos de informação e regras de negócio devem estar contidas no modelo de dados e corretas em relação ao negócio. Caso o modelo de dados esteja sendo construído de acordo com processos de desenvolvimento iterativos, a regra é aplicada no conjunto de requisitos e regras dispostos até a iteração presente. Este critério pode ser veri cado nos três níveis de abstração da Modelagem de Dados (conceitual, lógico e físico). Entre os erros mais comuns encontrados na veri cação deste critério estão: estruturas de dados modeladas incoerentes com as especi cações funcionais e requisitos de informação não contemplados no modelo de dados. 7.6.2.2. Conceituação Critério dedicado a veri car se as descrições dos objetos do modelo de dados estão claras, objetivas, sem ambiguidades e de acordo com os requisitos funcionais da aplicação. As de nições devem estar disponibilizadas nos principais componentes dos modelos de dados, como entidades, atributos e relacionamentos. Este critério pode ser veri cado nos três níveis de abstração da Modelagem de Dados (conceitual, lógico e físico). Vale ressaltar que as de nições dos diferentes níveis de abstração dos modelos não precisam ser iguais, porém devem estar coerentes entre si. Entre os erros mais comuns encontrados na veri cação deste critério estão: objetos sem de nição, ausência de clareza nas de nições e de nições tautológicas de objetos. 7.6.2.3.Integridade Critério dedicado a veri car se o modelo de dados está aderente à técnica de modelagem adotada no projeto e não possui problemas estruturais que

levem a gerar dados inconsistentes. Para aplicações que utilizam modelos de dados relacionais, as relações devem estar no mínimo na terceira forma normal e não possuir elementos redundantes. Este critério pode ser veri cado tanto no modelo lógico quanto no modelo físico. A veri cação no modelo conceitual não é indicada, pois o propósito deste modelo é capturar a realidade sob o ponto de vista do negócio, sem o auxílio de mecanismos de tecnologia. Entre os erros mais comuns encontrados na veri cação deste critério estão: redundância de dados, violação das formas normais e desrespeito às boas práticas de Modelagem de Dados. 7.6.2.4. Flexibilidade O modelo de dados deve ser projetado com uma exibilidade adequada para suportar mudanças na realidade do negócio sem alterações expressivas na estrutura do modelo atual. A exibilização do modelo de dados deve ser ajustada a cada caso. De forma geral, modelos muito exíveis necessitam de mecanismos adicionais para o controle da integridade das informações na construção das aplicações. Por outro lado, modelos pouco exíveis aparentemente requerem menor trabalho nas implementações, porém costumam exigir maiores esforços nas manutenções, sejam elas evolutivas ou corretivas. Este critério pode ser veri cado tanto no modelo lógico quanto no modelo físico. Entre os erros mais comuns encontrados na veri cação deste critério estão: utilização de domínios não estáveis como colunas, utilização desnecessária de metamodelos e chaves primárias associadas a colunas onde a empresa não tem o controle da regra de formação dos dados – por exemplo, número do CPF (atributo mantido pela Receita Federal e não pela empresa).

7.6.2.5. Integração Quando necessário, o modelo de dados deve suportar o uso de dados corporativos, armazenados nas bases de dados integradas da empresa. De forma geral, toda informação já existente no ambiente corporativo de uma empresa deve ser reutilizada seguindo as diretrizes de acesso aos dados corporativos previstos na Arquitetura de Dados da empresa. A nal, se um dado já existe, por que criá-lo de forma repetitiva e consumir mais esforços de armazenamento e controle de redundância? Este critério pode ser veri cado tanto no modelo lógico quanto no Modelo Físico de Dados. Geralmente o modelo lógico indica qual a origem do dado que será reutilizado, enquanto o modelo físico indica como o dado será consumido (serviços, acessos nativos, etc.). O erro comum na veri cação deste requisito é ter objetos redundantes criados nos modelos de dados. 7.6.2.6. Legibilidade Critério que veri ca se o modelo de dados possui um fácil entendimento, está legível, limpo e não poluído. Todas as informações necessárias à compreensão do modelo devem estar disponíveis de forma clara no seu desenho e/ou dicionário de dados. Quando necessário, o modelo deverá ser dividido em áreas especí cas de interesse, também conhecidas como subject areas. Este critério pode ser veri cado nos três níveis de abstração da Modelagem de Dados (conceitual, lógico e físico). Entre os erros mais comuns encontrados na veri cação deste critério podemos destacar: modelos extensos sem uso de “subject areas”, relacionamentos mal dispostos gra camente, informações de domínios não informadas ou incompletas nas de nições dos atributos.

7.6.2.7. Padronização Modelos de dados requerem a criação de padrões de nomenclatura. Sem eles, cada pessoa construirá um modelo de dados ao seu bem entender. Este critério estabelece que o modelo de dados deve respeitar a nomenclatura estabelecida no padrão vigente na empresa; além da utilização correta dos demais padrões, processos e ferramentas adotados na empresa. Este critério pode ser veri cado nos três níveis de abstração da Modelagem de Dados (conceitual, lógico e físico). 7.6.2.8. Aspectos físicos e de performance Os elementos estruturais representados no Modelo Físico de Dados devem ser utilizados de maneira correta e retratar exatamente o conteúdo da estrutura do ambiente que o modelo se propõe a representar (modelo sincronizado com a base de dados). Os elementos do Modelo Físico de Dados não devem prejudicar a performance do sistema e nem devem contribuir para um eventual desperdício do espaço de armazenamento em disco no SGBD. Este critério é veri cado somente no Modelo Físico de Dados. Entre os erros mais comuns encontrados na veri cação deste critério podemos destacar: índices criados de forma desorganizada, informações do volume de registros das tabelas não informadas na ferramenta CASE e desnormalizações desnecessárias.

7.7. Considerações finais sobre Modelagem de Dados A Modelagem de Dados continua sendo uma das mais importantes funções da Gestão de Dados. Seu principal artefato, o modelo de dados, é

utilizado em várias funções da Gestão de Dados e também serve como principal entrada e saída de vários processos dentro da Gestão de Dados. Um bom trabalho de modelagem não envolve apenas o levantamento de informações e a diagramação de um modelo feita por um analista ou projetista de dados para atender às necessidades pontuais de um determinado projeto. Um bom trabalho de modelagem envolve a participação de vários pro ssionais em diversas fases dentro do ciclo de vida de desenvolvimento de sistemas. Um modelo de dados não deve ser visto apenas como um instrumento para registrar a documentação das estruturas de dados de uma aplicação, mas o resultado de um trabalho de levantamento e análise, levando em conta uma visão mais ampla, corporativa, sobre o uso das estruturas de dados projetadas, a m de sempre buscar a reutilização de conceitos já mapeados e conhecidos na empresa. Quanto ao processo de modelagem, algumas dicas são fundamentais para manter este bom trabalho: Estabeleça um processo padrão para levantamento de requisitos e Modelagem de Dados. Estabeleça pontos de controle para validação/homologação formal dos modelos de dados produzidos. De preferência, utilize laudos para registrar as observações pertinentes. Sempre inicie o trabalho com um modelo conceitual. Consulte a Arquitetura de Dados existente na empresa durante a construção do modelo conceitual. Valide o modelo conceitual com as pessoas das áreas de negócio. O acesso aos modelos conceituais deve ser disponibilizado para todos que possuem algum envolvimento com os dados. A nal, os modelos

conceituais são importantes meios de divulgação do conhecimento do negócio da empresa. Já a disponibilização dos modelos físicos deve ser evitada devido a problemas de segurança de dados no desenvolvimento de sistemas. Derive o modelo conceitual para o modelo lógico e/ou modelo físico. Mantenha uma rastreabilidade entre esses modelos. Armazene os modelos em repositórios. Estabeleça reuniões para discutir as regras ou transformações feitas durante as construções dos modelos. Entenda que as aplicações e os processos podem ser modi cados com certa frequência nas empresas, já os dados não. Portanto, tente criar soluções de modelagem exíveis.

8. Arquitetura de Dados “Sempre somos capazes de dar algo mais; mesmo nas pedras germinam as flores.” Henri Bergson

8.1. O que é uma Arquitetura de Dados? Podemos de nir a Arquitetura de Dados como o conjunto de componentes de dados e suas relações dentro de uma empresa. Os componentes desta arquitetura são muitos e possuem diferentes níveis de abstração – desde o conceitual, onde são representados os modelos conceituais de dados, até o armazenamento físico, onde são representados os servidores de banco de dados. A Arquitetura de Dados descreve como os dados são processados, armazenados e utilizados pelas aplicações que criam, consultam e manipulam os dados. A Arquitetura de Dados fornece os critérios para as operações com os dados, possibilitando que sejam projetados e também controlados os uxos de dados das aplicações. Quando esta arquitetura é formada por elementos que são utilizados em várias áreas de negócio ou várias aplicações distintas, chamamos este conjunto de Arquitetura Corporativa de Dados.

A Arquitetura Corporativa de Dados é um componente da Arquitetura Empresarial de uma empresa. Serve como um importante subsídio para alinhar os dados e processos de negócios com a estratégia da empresa. A Arquitetura Corporativa de Dados inclui cinco grandes categorias de visualização: Estratégia empresarial: representada pelas informações do âmbito estratégico da empresa, tais como: visão, missão, objetivos estratégicos, Cadeia de Valor e macroprocessos. Essas informações não são criadas pela Gestão de Dados, porém toda Arquitetura Corporativa de Dados deve estar alinhada com essas informações. Glossário corporativo: disponibiliza informações dos termos corporativos do negócio e dos termos comuns em Gestão de Dados. Modelos corporativos: representação dos modelos corporativos em camadas. Arquitetura de integração: relação dos mecanismos homologados de integração, padrões para consumos dos dados corporativos e catálogo de ativos de integração. Arquitetura de infraestrutura: relação da política de uso dos ambientes de banco de dados, servidores e esquemas onde estão armazenados os dados corporativos. A gura a seguir demonstra essas cinco grandes categorias e suas proximidades em relação ao negócio e à tecnologia.

Figura 8.1 – Categorias de visualização de uma Arquitetura de Dados

Quando completa, uma Arquitetura de Dados traz vários benefícios para uma empresa. Melhor compreensão da estratégia da empresa e alinhamento das soluções de dados com a estratégia atual. Identi cação clara dos requisitos de dados estratégicos. Fornecer um vocabulário padrão de termos comuns ao negócio. Melhor entendimento dos dados corporativos e suas relações, obtidas através da leitura dos modelos de dados corporativos. De nir projetos integrados para atender aos requisitos estratégicos. Reutilização de dados já existentes para consumo das demais aplicações. Estabelecimento de formas padrão para consumo dos dados corporativos. Inventário dos dados corporativos.

As estratégias de construção e diagramação de uma arquitetura são várias. Cabe a cada empresa, através de seus pro ssionais de Gestão de Dados, escolher a melhor estratégia. Entre elas: Uma arquitetura única de modelo corporativo com as visões conceituais ou lógicas em uma única representação. Geralmente este tipo de abordagem é adotado por empresas com um conjunto pequeno de ativos de dados corporativos. Não há preocupação em manter na arquitetura os componentes de dados não corporativos. Uma arquitetura de modelos corporativos divididos em camadas interligadas (conceitual, lógica e física), formadas por elementos de dados corporativos. Este é o tipo de abordagem mais usual nas empresas. A representação do mapeamento entre as camadas é obrigatória para manter a rastreabilidade entre os elementos. Tal como a abordagem anterior, não há uma preocupação em manter na arquitetura componentes de dados não corporativos. Uma arquitetura corporativa adotando uma das duas abordagens anteriores mais arquiteturas especí cas, de dados não corporativos, formadas por elementos de dados compartilhados ou dados especí cos de determinadas áreas ou aplicações. Este tipo de abordagem é o mais custoso, tanto para criar quanto para manter atualizadas as arquiteturas. Por estas razões é a abordagem menos adotada nas empresas. A gura a seguir demonstra um exemplo de como pode ser representada uma Arquitetura de Dados.

Figura 8.2 – Exemplo de uma Arquitetura Corporativa de Dados

O exemplo dado na gura anterior ilustra uma arquitetura única que engloba visões conceituais, lógicas e físicas. Os componentes adotados nesta arquitetura são: modelos de dados (conceitual, lógico e físico), Cadeia de Valor da empresa, processos, gestores dos dados e dos processos, aplicações que criam e/ou utilizam os dados, arquitetura de referência para consumo dos dados, detalhamento dos servidores e schemas e gerência de conteúdo dos dados não armazenados em bancos de dados. Dependendo das necessidades da empresa e da abordagem adotada na construção da arquitetura, outros componentes podem ser representados, como por exemplo: arquitetura de metadados, arquitetura para Data Warehousing e Business Intelligence. Vale ressaltar que a Arquitetura de Dados deve representar a evolução e/ou relação entre os seus componentes e responder questões comuns sobre os dados corporativos. Exemplo: dada uma entidade de um modelo conceitual corporativo, quais as respostas para:

O signi cado desta entidade dentro do contexto do negócio? Qual caminho foi tomado até a sua implementação? Onde estão persistidos os dados dessa entidade? Quais aplicações acessam os dados dessa entidade? Quais as formas de disponibilização desses dados? Quem é o gestor desses dados?

8.2. Atividades necessárias para criar e manter uma Arquitetura de Dados Manter uma Arquitetura de Dados não é algo trivial. Envolve a colaboração dos pro ssionais de Gestão de Dados de TI e também dos pro ssionais de dados da área de negócios. A gestão desta arquitetura envolve atividades que devem estar perfeitamente alinhadas entre esses pro ssionais. A de nição desses papéis e responsabilidades é obrigatória e geralmente é uma incumbência da função “Governança de Dados”. Segundo o guia DAMA-DMBOK®, as atividades necessárias para gerir uma Arquitetura de Dados são as seguintes: Entender as necessidades de informação da empresa. Desenvolver e manter o modelo corporativo de dados. Analisar e alinhar o Modelo Conceitual de Dados com outros modelos de negócios. De nir e manter uma arquitetura de tecnologia de dados. De nir e manter uma arquitetura de integração de dados. De nir e manter uma arquitetura de Data Warehousing e de Business Intelligence.

De nir e manter uma taxonomia e padrões de nomes (namespaces) de dados para a empresa. De nir e manter uma arquitetura de metadados. Além das atividades previstas no guia DAMA-DMBOK®, também considero importantes as seguintes atividades: Análise da Cadeia de Valor da empresa e processos de alto nível. Esta atividade é fundamental para compreender a visão estratégica dos processos de negócio da empresa. A partir deste ponto os gestores de dados têm melhores condições de entender as necessidades de informação. Os modelos conceituais de dados devem estar alinhados com a visão estratégica e a visão dos processos. Sem isso, corre-se o risco de criar uma arquitetura pouco exível e não aderente à estratégia da empresa. Projetar e manter o desenho da Arquitetura de Dados com as interligações de seus elementos. Este trabalho é fundamental para representar uma visão estática de todos os elementos de dados previstos na arquitetura. Auditar o conteúdo da Arquitetura de Dados vigente. Esta atividade visa checar se o que está representado na Arquitetura de Dados está atualizado e vem sendo cumprido.

8.3. Arquitetura de Dados não é apenas uma coleção de modelos de dados e bancos de dados A Arquitetura de Dados é muito mais do que apenas modelos de dados e bancos de dados. Ela é extremamente útil para manter o alinhamento dos dados com a estratégia da empresa através da análise da Cadeia de Valor e seus macroprocessos. Além disso, a Arquitetura de Dados ajuda a

estabelecer a semântica de uma empresa, utilizando um vocabulário comum de termos de negócio, minimizando as barreiras de entendimento dos negócios. As seções a seguir detalham esses dois importantes componentes de uma Arquitetura de Dados. 8.3.1. Cadeia de Valor e macroprocessos A Cadeia de Valor é o modelo que descreve a empresa como um conjunto de macroprocessos que são executados de forma integrada para agregar valor às partes interessadas. A Cadeia de Valor especi ca as principais funções que agregam valor à companhia, sem necessariamente explicitar todas as interfaces entre elas. A partir da Cadeia de Valor, as funções são desdobradas em macroprocessos. Idealmente, cada macroprocesso visa atingir um ou mais objetivos, que devem estar alinhados com o modelo de objetivos estratégicos da organização. A Cadeia de Valor pode ser aplicada em qualquer organização. Para efeitos didáticos, vamos aplicar o conceito de Cadeia de Valor em uma área de Administração de Dados de uma empresa, no exemplo que será dado na gura a seguir.

Figura 8.3 – Exemplo de Cadeia de Valor

A Cadeia de Valor do exemplo está dividida em três grandes conceitos. A parte superior, formada pelo macroprocesso Gerir Metodologia e Processos, pode ser considerada a parte estratégica da cadeia. A parte central é formada pelos macroprocessos ligados à Modelagem de Dados. Esta camada é considerada a parte central da Cadeia de Valor e representa os principais macroprocessos executados pela área. Já a parte inferior é formada pelos macroprocessos de apoio que são utilizados para prestar suporte aos macroprocessos centrais. Os macroprocessos são decompostos em processos menores; no caso do exemplo aplicado sobre a Cadeia de Valor do livro, podemos encontrar o seguinte desdobramento: Macroprocesso: “Gerir Metodologia e Processos” Processos: Revisar documento da metodologia. Alterar documento da metodologia. Acompanhar indicadores de processos de trabalho. Revisar processo de trabalho. Divulgar alteração em documento da metodologia. Capacitar envolvidos nos processos e metodologia. Macroprocesso: “Garantir Qualidade dos Modelos de Dados” Processos: Acompanhar levantamento de requisitos. Efetuar consultoria em modelagem. Efetuar reunião de acompanhamento sobre qualidade da modelagem.

Macroprocesso: “Elaborar Modelo de Dados” Processos: Consultar metadados existentes. Elaborar modelos de dados. Encaminhar modelos de dados para avaliação. Macroprocesso: “Controlar Qualidade dos Modelos de Dados” Processos: Avaliar modelos de dados. Alimentar indicadores de qualidade das avaliações. Macroprocesso: “Disponibilizar Informações Compartilhadas” Processos: Consultar metadados no repositório. De nir forma de compartilhamento. Compartilhar entidade corporativa em modelo de dados. Macroprocesso: “Gerir Modelos no Repositório” Processos: Disponibilizar modelo de dados. Gravar modelo de dados no repositório. Efetuar operação de complete x compare. Efetuar engenharia reversa. Administrar usuários do repositório.

Macroprocesso: “Implementar Modelo de Dados” Processos: Implementar modelo de dados. Versionar script. Todos os processos mencionados utilizam e/ou fazem referências a entidades de dados. As entidades corporativas são representadas em modelos de dados corporativos da Arquitetura de Dados da empresa. O trabalho de construção da Cadeia de Valor, bem como o desdobramento dos seus macroprocessos, geralmente não é feito pelo staff da Gestão de Dados, e sim por pro ssionais especialistas em mapeamento e desenho de processos. Contudo, esses artefatos devem obrigatoriamente ser representados na Arquitetura de Dados da empresa, pois representam uma visão de alto nível da organização. Na criação dos modelos de dados corporativos tanto a Cadeia de Valor quanto os objetivos estratégicos da empresa (missão, visão, objetivos, etc.) são levados em conta na especi cação das entidades corporativas que irão compor esses modelos. 8.3.2. Glossário de termos corporativos Os glossários corporativos podem ser divididos em dois artefatos distintos: o glossário de termos de Gestão de Dados e o glossário de termos de negócio. O primeiro estabelece um vocabulário sobre os termos comuns de Gestão de Dados que são utilizados na empresa. Apesar de simples, este documento é extremamente útil para nivelar o entendimento de conceitos que, a princípio, parecem ser de domínio de todos, porém, na prática, é comum encontrar pessoas, principalmente com pouca experiência em Gestão de Dados, utilizando conceitos errados com de nições erradas.

Neste glossário encontramos de nições que devem ser disseminadas para todo o público envolvido com Gestão de Dados na empresa. Aqui encontraremos as de nições para os principais termos de Gestão de Dados. A tabela a seguir demonstra exemplos de termos de Gestão de Dados que geralmente são incluídos em um glossário. Termo

De nição

AD

Sigla de Administrador de Dados.

Atributo

Informação que representa uma propriedade de uma entidade e/ou relacionamento. Os atributos são utilizados nos projetos conceitual e lógico de dados.

Base de Dados Base de dados que é acessada por mais de uma aplicação. Compartilhada Base de dados compartilhada formada por informações oriundas de dados de referência e dados mestres. Mantida por uma área Base de Dados corporativa, a base de dados é acessada por várias áreas da Corporativa organização, e suas informações possuem um alto grau de reutilização. Quantidade de ocorrências em que uma entidade ou tabela participa Cardinalidade de forma mínima (cardinalidade mínima) e forma máxima (cardinalidade máxima) de um relacionamento. Coluna

Unidade básica de armazenamento de dados em um registro dentro de uma tabela.

Dado Mestre

Dado processado por uma área de negócio ligada às atividades centrais da companhia e compartilhado para as demais áreas de negócio da organização. Um dado mestre está ligado diretamente ao negócio central da empresa. Exemplos de dados mestres: cliente, fornecedor, material, etc.

Dado de Referência

Dado processado por qualquer área de negócio ou importado de fontes externas à organização. Um dado de referência não faz parte do negócio central da empresa e é acessado por várias aplicações na companhia. Exemplos de dados de referência: unidade federativa, unidade de medida.

Entidade

Objetos que têm existência própria e podem ser identi cados distintamente quando consideramos o escopo de requisitos e regras de negócio a serem modelados. Uma entidade é descrita por seus atributos.

Tabela

Componente de armazenamento de dados, formado por um conjunto

de dados dispostos em número nito de colunas e número ilimitado de linhas. Tabela 8.1 – Exemplos de termos inclusos em um glossário de termos de Gestão de Dados

Já o glossário corporativo de termos de negócio fornece de nições padrão para os conceitos de negócio corporativos da empresa. Cada termo está ligado diretamente a uma entidade ou atributo(s) de uma entidade modelada nas camadas de modelos de dados da Arquitetura de Dados corporativa da empresa. É recomendado que a inclusão de cada termo no glossário e sua de nição sejam feitas após uma rigorosa análise do grupo responsável por manter o glossário. Geralmente este grupo é formado por uma comissão permanente de pro ssionais de negócio ou então, em casos iniciais de implantação do glossário, por um comitê de Gestão de Dados. Esta análise leva em conta a aderência do termo em relação ao negócio (de forma corporativa), além da coerência da de nição proposta à estrutura representada em um modelo da arquitetura corporativa. Todo termo incluso no glossário deve ser representado em um modelo existente, sob forma de atributo ou entidade, na arquitetura corporativa vigente. Por m, a divulgação deste glossário deve ser ampla e de fácil acesso a todos os colaboradores da empresa.

8.4. Modelos de dados e Arquitetura de Dados Modelos de dados representam uma visão única e estática dos dados, ou seja, na prática temos uma espécie de visão similar a uma planta baixa de um imóvel. Quando uma empresa decide implementar uma Arquitetura de Dados, precisamos ter em mente que não podemos começar com algo muito ambicioso, abrangendo todos os dados da empresa.

Uma boa prática é começar com a criação de uma Arquitetura Corporativa de Dados, onde somente os dados corporativos serão incluídos. A visualização de quem entra (é corporativo) ou não na arquitetura só é possível de ser feita através da leitura dos modelos de dados. Portanto, o modelo de dados é o principal elemento de uma arquitetura e sua representação é obrigatória. Os critérios para diferenciar um dado corporativo de um dado compartilhado e também de um dado de transação comum serão conhecidos mais adiante.

8.5. Modelos de dados compartilhados Modelos de dados formados por entidades que são reutilizadas na organização. Nem todo modelo compartilhado é um modelo corporativo, porém todo modelo corporativo é um modelo compartilhado.

8.6. Modelos de dados corporativos Uma de nição simples e comum que pode ser aplicada a modelos de dados corporativos é a seguinte: “modelo ou grupo de modelos formados pelos principais conceitos de negócio da empresa. Os modelos corporativos possuem vários níveis de abstração”. Vale lembrar que modelos de dados corporativos possuem características compartilhadas, porém nem sempre os modelos compartilhados são modelos corporativos. Modelos de dados corporativos são formados por entidades corporativas. Uma entidade corporativa é utilizada por várias áreas dentro de uma empresa. FUNCIONARIO e UNIDADE_FEDERATIVA são exemplos clássicos de entidades de dados corporativos. Os dados da primeira entidade são geralmente criados dentro dos departamentos de RH da empresa e

depois disponibilizados para aplicações de diversas áreas. Já os dados da segunda entidade geralmente são adquiridos de fontes externas (CEP, IBGE) e depois de adquiridos também são disponibilizados para várias áreas da empresa. Apesar dos dados não serem criados na empresa, a UNIDADE_FEDERATIVA pertence a um conceito de “LOCALIZAÇÃO” que in uencia diretamente em conceitos de negócio de diferentes áreas da empresa Já uma entidade compartilhada é utilizada por mais de uma aplicação, porém limitada a uma ou poucas áreas da empresa. A entidade FATURA é um exemplo clássico de uma entidade compartilhada. Geralmente os dados dessa entidade são criados dentro da área nanceira da empresa e depois são disponibilizados para algumas aplicações da própria área nanceira. Ou seja, o dado não circulou por várias áreas da empresa. Um modelo de dados corporativo requer investimentos signi cativos na de nição e documentação de um vocabulário comum, regras de negócios e conhecimento do negócio que atenda a toda a empresa. Sua criação, manutenção e enriquecimento exigem investimentos contínuos de tempo e esforço, mesmo quando se começa com a aquisição de um modelo de dados externo ou legado. 8.6.1. Como diferenciar modelos corporativos dos modelos compartilhados Uma das principais dúvidas em termos de Arquitetura de Dados corporativa é identi car o que é corporativo e o que é compartilhado. Os itens a seguir ajudam a esclarecer essas dúvidas. Modelos corporativos possuem alto nível de abstração (conceitual ou lógica).

Modelos corporativos possuem um escopo mais amplo, onde uma mesma entidade é utilizada por várias áreas de negócio. Modelos corporativos não fazem mapeamento direto para o SGBD. Eles são representados em uma Arquitetura de Dados corporativa. Modelos compartilhados possuem um nível mais próximo à implementação (modelos lógicos ou físicos). Modelos compartilhados possuem um escopo mais especí co. Geralmente as entidades são utilizadas em uma única área de negócio ou no máximo em duas. Modelos compartilhados podem fazer mapeamento direto para o SGBD. 8.6.2. Abordagens para construção de modelos corporativos Entre as abordagens de construção dos modelos corporativos, as mais comuns são: Top Down, Bottom Up e Híbrida. A gura a seguir demonstra as abordagens de construção deste modelo.

Figura 8.4 – Abordagens para construção de modelos de dados corporativos

8.6.2.1. Abordagem Top Down Entidades mapeadas e modeladas a partir de macroconceitos, Cadeia de Valor e processos da empresa. Geralmente a iniciativa conta com o apoio das altas gerências, tanto de negócio, quanto de TI. Sequência normal das atividades: mapeamento dos macroconceitos e processos, modelagem conceitual, modelagem lógica (se houver), modelagem física e implementação. A abordagem Top Down é considerada o ciclo de vida ideal para construção dos modelos de dados corporativos. 8.6.2.2. Abordagem Bottom Up Entidades mapeadas e modeladas a partir dos modelos físicos de dados existentes. Geralmente esta iniciativa é feita pelos técnicos da área de TI. O propósito do trabalho é tentar “arrumar a casa” com os objetos já existentes. Sequência normal das atividades: engenharia reversa das bases de dados, documentação do Modelo Físico de Dados, modelagem lógica (se houver) e modelagem conceitual (de acordo com os conceitos obtidos das bases físicas). 8.6.2.3. Abordagem Híbrida O trabalho geralmente é iniciado a partir das necessidades levantadas pela própria área de TI. A construção do modelo leva em conta tanto os objetos físicos existentes (obtidos através de engenharia reversa) como os modelos de processo (mapeados) e a Cadeia de Valor da empresa.

8.7. Tipos de modelos de dados corporativos segundo o DAMA-DMBOK® O guia DAMA-DMBOK® estabelece algumas diretrizes para tratar os modelos corporativos dentro de uma Arquitetura de Dados. A principal é

estabelecer uma cadeia no estilo Top Down de modelos corporativos, separados em camadas, a partir da visão de um modelo único, com uma visão bem genérica, sendo desmembrado depois em mais duas camadas: uma com modelos conceituais integrados e outra mais detalhada com modelos lógicos de dados. A gura a seguir mostra o exemplo dos tipos de modelos de dados sugeridos pelo guia DAMA-DMBOK® dentro de uma Arquitetura de Dados.

Figura 8.5-Camada de modelos corporativos segundo o DAMA-DMBOK®

8.7.1. Modelo de Área de Interesse O Modelo de Área de Interesse, também conhecido como modelo de Subject Area, representa a cadeia mais alta dentro dos modelos de dados corporativos da Arquitetura de Dados da empresa. O Modelo de Áreas de Interesse é único e representa a lista de grandes áreas temáticas que, coletivamente, expressam o escopo essencial de uma empresa. Geralmente o modelo é composto de doze a vinte conceitos corporativos. Não há uma notação especí ca para representar este tipo de modelo.

As guras a seguir demonstram dois exemplos de representação de um modelo de Subject Area. O primeiro agrupa conceitos maiores dentro de uma hierarquia. A segunda mostra os conceitos temáticos em uma espécie de mapa mental.

Figura 8.6 – Exemplo de Modelo de Área de Interesse

Figura 8.7 – Exemplo de Modelo de Área de Interesse (mapa mental)

A seleção e a nomeação das áreas de interesse essenciais da organização são criticamente importantes para o sucesso de todo o desenvolvimento dos demais modelos de dados corporativos, portanto, apesar de aparentar ser

simples, este modelo deve ser elaborado e revisado com bastante critério, pois, depois da cadeia de modelos ser estabelecida, as alterações neste nível desdobrarão diversas modi cações em cadeia. As áreas de interesse orientam as interações e organizam o escopo e a prioridade do desenvolvimento dos demais modelos. O Modelo de Área de Interesse é “correto” quando é aceito por todos os stakeholders da empresa. Além disso, é útil em um sentido prático na empresa para a construção de diversas iniciativas, como, por exemplo: Governança de Dados, gestão estratégica de dados e Modelagem de Dados corporativa. Geralmente os modelos de área de interesse são construídos pelos gestores estratégicos de dados, apoiados pelos gestores de dados de negócio. 8.7.2. Modelos conceituais de dados Segundo arquitetura proposta pela guia DAMA-DMBOK®, cada área de interesse deve ser mais bem detalhada por um ou mais modelos conceituais de dados, integrados na mesma área ou integrados a áreas diferentes. O guia recomenda que esta camada, formada por modelos conceituais, tenha um número estimado de 150 a trezentas entidades de negócio representadas em seus modelos conceituais. Nesta camada, os modelos conceituais não precisam ter um grau de detalhamento dos atributos e demais mecanismos de abstração muito aprofundados – o próprio guia DAMA-DMBOK® recomenda que, nesta camada, os modelos conceituais não possuam atributos. Esta diretriz é útil para não poluir a visão global da arquitetura. Entretanto, os atributos e demais mecanismos devem ser representados nos modelos conceituais das aplicações que originam esses dados. Vale ressaltar que ambos os modelos devem existir na empresa (modelos da arquitetura e modelos das aplicações).

A gura a seguir mostra um exemplo de dois modelos conceituais corporativos integrados.

Figura 8.8 – Exemplo de modelos conceituais integrados em uma arquitetura

Na gura anterior, podemos observar a existência de dois modelos conceituais integrados dentro de uma mesma área de interesse. Há uma integração do modelo de localização geográ ca com o modelo do endereçamento postal, pois uma localidade pode possuir um CEP exclusivo. Já o modelo de endereçamento postal necessita das informações do modelo de localização geográ ca, pois tanto a entidade BAIRRO quanto a entidade LOGRADOURO necessitam de informações provenientes do modelo de localização geográ ca. Vale ressaltar que, conforme sugerido pelo DAMA-DMBOK®, os atributos das entidades não estão disponíveis. Entretanto, vale ressaltar que as de nições das entidades devem estar disponíveis a todos os interessados. Essas de nições devem estar disponíveis no dicionário de dados de cada modelo e/ou em um glossário corporativo de conceitos.

Geralmente os modelos conceituais de dados corporativos são construídos em conjunto pelos gestores de dados de negócio e gestores de dados estratégicos. Os gestores de dados de negócio são especialistas nos assuntos, porém carecem de uma visão mais completa. Esta visão é passada pelo gestor estratégico de dados. Apesar de não participarem diretamente na construção desses modelos, os gestores técnicos de dados devem ter acesso a esses modelos para efetuar consultas e identi car possíveis situações de reuso. 8.7.3. Modelos lógicos de dados Os modelos lógicos de dados corporativos adicionam uma camada de detalhe mais abaixo da camada dos modelos conceituais. Os modelos lógicos continuam a re etir o negócio da empresa, tal como os modelos conceituais, e são neutros e independentes de qualquer necessidade especí ca de um projeto ou aplicação. Em relação ao grau de detalhamento, os modelos lógicos possuem atributos, porém nem todos são representados. Nesta camada são representados apenas os principais atributos que identi cam particularidades fundamentais e/ou corporativas das entidades dos modelos. Geralmente os modelos lógicos corporativos são construídos pelos gestores técnicos de dados a partir dos modelos conceituais corporativos existentes.

8.8. Integração dos dados corporativos A Arquitetura de Dados de uma empresa também deve relacionar as possíveis formas de consumo dos dados corporativos representados em sua arquitetura. De forma geral, as formas são muitas e é impossível a rmar qual o melhor mecanismo de uso para consumir os dados em qualquer situação e em qualquer empresa.

Variáveis como infraestrutura de hardware da empresa, conhecimento sobre uma determinada tecnologia, características externas do ambiente, complexidade das aplicações, custo das operações, tempo e pessoal disponível são alguns dos fatores que in uenciam diretamente na escolha de uma solução de integração. É importante frisar que nunca uma empresa deverá optar por uma única solução de integração. Quando trabalhamos com soluções de integração de dados vale o ditado de Nelson Rodrigues: “toda unanimidade é burra!”. As seções a seguir mostram as principais formas de integração dos dados. 8.8.1. Integração via troca de arquivos A troca de arquivos é a forma mais primitiva de compartilhar dados corporativos. Com a evolução da tecnologia, seu uso está praticamente em extinção, porém ainda é utilizada em alguns casos extremos onde há limitação para o consumo de informações devido à ausência de uma rede interna ou móvel. A gura a seguir demonstra um exemplo de consumo de dados através da troca de arquivos.

Figura 8.9 – Integração via troca de arquivos

A simplicidade de implementação desta solução é a sua principal vantagem. Entre as desvantagens podemos citar: Não é uma solução adequada para interfaces que dependam fortemente de dados atuais (processamento online).

A solução requer gastos adicionais com armazenamento dos dados. O dispositivo de armazenagem geralmente é uma área de disco da rede corporativa. Di culdade na monitoração da interface. Redundância dos dados, pois a mesma informação estará armazenada em mais de um lugar. Dependência de outros métodos ou ferramentas para agendar a geração dos arquivos. 8.8.2. Integração via ETL Atualmente, o consumo de dados corporativos via ETL é uma das formas mais usuais de consumo dos dados corporativos. ETL signi ca Extract, Transform and Load (extrair, transformar e ler). Ou seja, o dado é extraído de uma origem, logo após é transformado através de regras de transformação (ou não) e carregado em uma tabela destino, em local diferente de onde ele foi extraído. A integração via ETL é utilizada quando os dados corporativos estão armazenados em um servidor de banco de dados diferente do servidor onde a aplicação destino irá consumir os dados corporativos ou há necessidade de transformar os dados corporativos em outro formato diferente do que ele é armazenado. Quando o ETL é utilizado, temos uma replicação da informação corporativa, portanto, sempre que esta solução for adotada, devem ser previstos mecanismos de controle para garantir a integridade do dado compartilhado. A informação replicada no banco de dados de destino não permite privilégios de escrita na tabela onde foi feita a cópia. O acesso é dado somente para leitura. A gura a seguir demonstra um exemplo de consumo de dados através da troca de dados via ETL.

Figura 8.10 – Exemplo de integração de dados via ETL

No exemplo anterior os dados de CLIENTE estão armazenados em uma base de dados corporativa. Uma aplicação qualquer, armazenada em outro servidor, precisa consumir os dados referentes aos códigos e nomes dos clientes. Para transferir os dados de cliente para este outro servidor, optou-se por utilizar o ETL como estratégia de integração de dados. Foi criada uma tabela para receber os dados solicitados. Repare que nem todas as informações de CLIENTE foram levadas para a réplica, e sim somente as necessárias. O acesso da aplicação à tabela de réplica é feito somente para leitura, ou seja, não há risco de incluir na tabela de réplica algum dado de cliente em local diferente do estabelecido para este dado corporativo. En m, há uma redundância, mas ela é controlada. Entre as vantagens desta forma de integração podemos citar: Solução ideal para manipular grandes volumes de dados. Solução ideal para cargas de dados históricos. Já entre as desvantagens podemos citar:

O processo ETL geralmente roda durante a noite, quando não há muito processamento dos dados pelas aplicações. Com isso, existe um atraso de um dia em relação à atualização dos dados. Redundância. Processo de extração dos dados custoso. Gastos adicionais com armazenamento. Dependência de ferramentas e pessoal especializado. 8.8.3. Integração via Database Links ou Linked Servers Database Link (Oracle) ou Linked Server (SQL Server) são objetos criados em esquemas de bancos de dados que possibilitam o acesso a objetos em outros servidores de banco de dados, sejam eles do mesmo produto ou não. Esse tipo de sistema é conhecido como Sistema de Banco de Dados Distribuídos e pode ser considerado homogêneo (quando acessa outros bancos de dados do mesmo fornecedor) ou heterogêneo (quando acessa outros tipos de bancos de dados). A gura a seguir demonstra um exemplo de consumo de dados através do uso dessas ferramentas.

Figura 8.11 – Exemplo de uso de Database Link ou Linked Server No exemplo anterior a aplicação acessa os dados do esquema corporativo através do link estabelecido. Por questões de segurança, é recomendado que o link aponte para visões no servidor de origem, ao invés de apontar para tabelas.

Entre as vantagens podemos citar que esse tipo de solução é simples e já é adotada por algumas empresas há algum tempo no mercado. Além disso, é totalmente independente de outras soluções. Já as desvantagens estão ligadas a: Performance, principalmente se os esquemas corporativos possuírem muitas aplicações penduradas nesse tipo de solução. Administração custosa. Difícil governança. 8.8.4. Replicação de dados e Oracle Golden Gate Sob o ponto de vista das aplicações que consomem as informações corporativas, a replicação de dados sempre foi uma das formas mais desejadas de consumo de dados pelas equipes de desenvolvimento, mas

geralmente as tentativas esbarravam nas infraestruturas ou em Arquiteturas de Dados das empresas que não permitiam este tipo de solução, devido às questões de redundância e governança. Para manter as replicações sob controle eram necessários esforços hercúleos dessas equipes. Entretanto, recentemente a Oracle lançou um produto no mercado que promete acabar com todos esses esforços. O Oracle Golden Gate resolve um problema presente no dia a dia das empresas: integrar dados de bases heterogêneas em tempo real e a um custo efetivo. Essa solução possibilita a replicação online de dados em ambientes heterogêneos, o que, além de gerar maior agilidade para seu negócio, reduz o custo total de propriedade de TI, já que permite a manutenção do ambiente legado na sua base atual, eliminando custos e esforços de migração. O Golden Gate trabalha arquiteturas (replicação transmissão, consolidação e atender de forma efetiva e negócios. A gura a seguir Golden Gate.

com diversos ambientes e em inúmeras unidirecional, bidirecional, peer-to-peer, cascateamento de dados) e é exível para com alto desempenho às necessidades dos demonstra um exemplo da solução Oracle

Figura 8.12 – Exemplo de uso do Oracle Golden Gate

As principais vantagens desta solução são: Possibilidade de trabalhar com dados atualizados em tempo real. Excelente performance. Fácil governança. Já entre as desvantagens podemos citar: Solução limitada a uma tecnologia (Oracle). Dados replicados (apesar de ser uma redundância controlada). A solução ainda é nova no mercado. Poucas empresas a utilizam. 8.8.5. Integração via serviços O grande uso de serviços e de seus padrões de suporte à integração de negócios levou a grandes avanços na integração de dados e aplicações. O uso de serviços não é nenhuma novidade, porém seu uso voltou à tona devido ao novo paradigma de adoção da arquitetura SOA. A arquitetura orientada a serviços (SOA) apresenta-se mais exível e capaz de suportar serviços independentes de plataforma e protocolo em um ambiente. “Serviços”, do ponto de vista de SOA, são módulos de negócio ou funcionalidades das aplicações que possuem interfaces expostas e que são invocados via mensagens. Por exemplo, em um sistema de seguros teríamos os seguintes serviços: serviço de nomes e endereços, serviço de abertura de sinistro, serviço de consulta de apólices, etc. Um serviço deve possuir uma interface bem de nida e funcionar de forma independente do estado de outros serviços, exceto nos casos de serviços compostos (composite services).

A comunicação entre o sistema cliente e aquele que disponibiliza o serviço é normalmente realizada através de web services. Frequentemente esses serviços são conectados através de um “barramento de serviços”, que disponibiliza interfaces, ou contratos, acessíveis através de web services. A arquitetura SOA provê facilidades de integração com diferentes tecnologias, aumentando a produtividade de equipes de desenvolvimento e diminuindo o tempo de entrega das soluções que acessam os dados na empresa. Segundo o Gartner, SOA é uma abordagem arquitetural corporativa que permite a criação de serviços de negócio interoperáveis que podem facilmente ser reutilizados e compartilhados entre aplicações e empresas. A gura a seguir demonstra um exemplo de consumo de dados através de serviços.

Figura 8.13 – Exemplo de dados corporativos consumidos via serviços

A gura anterior representa dois esquemas corporativos que disponibilizam dados através de serviços. O primeiro esquema armazena dados corporativos de clientes. A gura ilustra três aplicações que consomem os dados dos clientes através de um serviço denominado “Busca Cliente”. Já o segundo esquema armazena dados corporativos de localidades.

As aplicações D, E e F consomem os dados corporativos de localidades através do serviço “Busca UF”. A disponibilização de dados via serviços possui várias vantagens: Modularidade. Interoperabilidade (independência de plataformas). Reutilização. Flexibilidade. Segregação de equipes (paralelismo nas ações). Ideal para processamento online (síncrono). Fraco acoplamento (nenhum código é fornecido para o aplicativo consumidor). Já entre as desvantagens podemos citar: Desempenho. Limitações na manutenção de interfaces. Não é adequado para grandes volumes de dados. Chamadas de serviços não devem ser colocadas dentro de loops. Na carona da implantação da arquitetura SOA nas empresas, o uso de serviços para consumir dados corporativos vem sendo adotado como principal diretriz para integração dos dados. Em alguns casos, há certo exagero em de nir o uso de serviços como a única forma de consumo desses dados. Conforme mencionado antes, não há uma forma única e ideal para consumir dados corporativos. Todas as soluções possuem vantagens e

desvantagens que devem ser levadas em conta conforme as necessidades de consumo dos dados.

9. Gestão de Dados Mestres e Referência “A vida é um caminho de sombras e luzes. O importante é que se saiba vitalizar as sombras e aproveitar a luz.” Henri Bergson

9.1. Contextualização Em qualquer empresa existem conceitos comumente reconhecidos que são o foco dos processos de negócio, tais como clientes, produtos, fornecedores, vendedores e funcionários. Os dados desses conceitos são considerados mestres e constituem os principais dados de uma empresa. De forma geral, esses dados são categorizados por outros dados, considerados dados de referência. Quando a empresa não possui uma gestão efetiva desses conceitos, representados sob a ótica dos dados, cada vez mais são criados silos de dados, gerando um número crescente de disparidades de conceitos e valores nas aplicações da empresa e apresentando duplicações e representações redundantes, muitas vezes diferentes, sobre os mesmos conceitos. A Gestão de Dados Mestres e Referência (MDM – Master Data Management) procura eliminar essas disparidades e fornecer mecanismos

para eliminar a cultura “feudal” sobre o uso dos dados. Um dos mais importantes princípios do MDM é que o dado não é de uso exclusivo de uma determinada área e sim de toda a empresa. A gura a seguir mostra um exemplo típico de uma empresa que não possui uma Gestão de Dados Mestres e Referência efetivamente implantada.

Figura 9.1-Exemplo típico de empresa que não possui MDM implantado

Conforme podemos observar, os mesmos problemas decorrentes da má gestão dos dados, vistos anteriormente nos capítulos iniciais do livro, ocorrem quando não existe uma gestão efetiva sobre os dados mestres e de referência de uma empresa. Olhando sob este ponto de vista, podemos concluir que a gestão dos dados mestres e de referência é um subconjunto da Gestão de Dados aplicado nos principais dados da empresa. Mas, a nal, o que são dados mestres e dados de referência?

9.2. Dados mestres Dados mestres são dados sobre as entidades de negócio que provêm um contexto para as transações de negócio. Entre exemplos de dados mestres podemos citar: clientes, fornecedores, funcionários, produtos, contratos, imóveis, contas, etc.

Os dados mestres são considerados dados críticos para o negócio, tendem a ser mais estáveis que os dados de transação e são utilizados por mais de uma área de negócio. Exemplo: um cliente pode estar envolvido em vários processos de negócio, tais como campanhas de marketing, sistemas de vendas, faturamento e cobrança. Os dados mestres são classi cados em três grandes grupos: pessoas, coisas e locais. A gura a seguir demonstra um exemplo de classi cação de dados mestres.

Figura 9.2 – Classi cação dos dados mestres

Diferentemente dos dados de referência, dados mestres usualmente não são limitados a valores de domínios prede nidos. Entretanto, regras de negócio podem in uenciar no formato e nos intervalos permitidos para os valores dos dados mestres. Os dados mestres são encontrados tanto no patamar operacional quanto no estratégico, apoiando os processos de tomada de decisão da empresa. Em sistemas transacionais, os dados mestres estão quase sempre envolvidos com dados de transações. Um cliente compra um produto. Um fornecedor vende um item e um parceiro entrega uma caixa de materiais em um local. Os dados mestres são os dados autorizáveis disponíveis mais precisos sobre as entidades chave do negócio. São utilizados para estabelecer um contexto para os dados das transações.

Esta relação entre dados mestres e dados transacionais pode ser considerada, de forma geral, como uma relação “verbo/substantivo”. Os dados transacionais capturam os verbos, como vender, entregar, comprar; já os dados mestres são os substantivos.

9.3. Dados de referência Dados de referência são utilizados para categorizar (agrupar ou classi car) outros dados, principalmente os dados mestres. Os dados de referência podem ser de origem externa ou interna à corporação. São armazenados em tabelas constituídas por códigos e suas descrições. Entre alguns exemplos podemos citar: cargos, unidades federativas, municípios, moedas, unidades de medida, etc. Os dados de referência não representam um papel primário nas transações que são processadas pelas aplicações da empresa. Entretanto, eles conectam os dados da empresa às informações mantidas por outras aplicações e até mesmo por outras empresas ou organizações. Como exemplo, as tabelas de municípios e Unidades da Federação mantidas pelo IBGE. Ainda está em dúvida sobre como identi car dados mestres e dados de referência? A tabela a seguir compara dados mestres e dados de referência sob alguns aspectos: Dados mestres

Dados de referência

Muitas linhas por tabela

Poucas linhas por tabela

Muitas colunas por tabela

Poucas colunas por tabela

Poucas tabelas na base de dados

Muitas tabelas na base de dados

Sofre alterações mais rapidamente Sofre alterações mais lentamente Altamente compartilhados dentro da empresa

Ainda mais compartilhados dentro da empresa e entre empresas

Tabela 9.1 – Características de Dados Mestres e Referência

9.4. Dados transacionais É a categoria que abrange os dados oriundos das atividades do negócio, tais como: informações sobre ordens de compra, faturas e demonstrações nanceiras. São informações registradas como fatos nos modelos multidimensionais ou transações nos modelos entidade-relacionamento. Os dados transacionais são aqueles que alimentam e impulsionam os indicadores de negócio da empresa. Dependem inteiramente dos dados mestres para serem contextualizados. O modelo de dados representado na gura a seguir demonstra exemplos de dados transacionais, além dos dados mestres e dados de referência.

Figura 9.3 – Exemplos de dados mestres, dados de referência e dados transacionais.

Os dados transacionais não são compartilhados e pertencem a uma ou poucas áreas. No exemplo dado na gura anterior, FATURA, ITEM FATURA e PARCELA FATURA são entidades típicas da área nanceira, tendo o escopo de atuação limitado a aplicações desta área.

9.5. Gerenciamento de dados mestres e referência Já vimos que dados mestres e dados de referência fornecem contexto para os dados transacionais de uma empresa. A gestão desses dados tem como objetivo manter estruturas destinadas a criar e manter uma autoridade con ável, sustentável, precisa e segura dos ambientes de dados que representam uma visão única, verdadeira e abrangente dos dados mestres e dados de referência. A esta visão damos o nome de “Registro Dourado” ou “Golden Record”. Para isso, torna-se necessária a criação de processos, onde as áreas de negócio e de TI colaboram para harmonizar, limpar, publicar e proteger os dados comuns que devem ser compartilhados por toda a empresa. A gestão de dados mestres e referência (MDM – Master Data Management) compreende um conjunto de processos, ferramentas e tecnologia que consistentemente de ne e gerencia os dados mestres e dados de referência em toda a organização, garantindo coerência, controle na manutenção e condições de utilização desses dados. Um programa de MDM busca apoiar as necessidades de negócios da organização ao fornecer acesso a visões consistentes dos dados mestres e dados de referência. Este programa governa métodos, ferramentas e serviços para: Avaliar a utilização de dados, coleções de valores de dados válidos e regras de negócios explícitas e implícitas comumente usadas nas aplicações da empresa. Identi car dados utilizados em diversas aplicações, cuja centralização é relevante para o sucesso dos negócios.

Instanciar um modelo padrão para integração e gerenciamento dos dados. Coletar dados de fontes candidatas, avaliar o quanto as diferentes instâncias de dados referem-se a uma mesma entidade do mundo real e criar uma visão única e consolidada de cada uma delas (registro dourado). Prover métodos para acesso transparente à visão uni cada dos dados para novas aplicações e também para aplicações legadas. Instituir a Gestão de Dados de Negócio, políticas de gerenciamento, procedimentos para a organização e linhas de negócio, assegurando uma alta qualidade dos dados mestres e dados de referência. O MDM (Master Data Management) ajuda a eliminar os esforços para manter os dados com qualidade, eliminando perguntas como: “Quais dados estão certos?” “Qual a origem correta dos dados?” “Quais aplicações utilizam esse dado?” “Que de nição de vendas será utilizada hoje?” A eliminação de dúvidas básicas sobre os dados e a geração e a disseminação de dados corretos e de qualidade corroboram para melhorar o processo decisório. Outros benefícios podem ser obtidos com a adoção do MDM: Conhecimento abrangente dos domínios relativos aos nomes dos dados. Relatórios com maior grau de qualidade.

Gerenciamento de riscos mais apurados devido à maior con ança nos ativos de dados. Melhoria nas operações de manipulação dos dados e redução de custos. Melhoria da análise e do planejamento de custos (orçamento). Aderência às exigências regulatórias. Visão integrada dos dados. Simpli cação do desenvolvimento de aplicações com a nova arquitetura de MDM. A produtividade e a qualidade dos dados dentro de um ambiente empresarial melhoram signi cativamente com a presença de uma Arquitetura de Dados efetivamente integrada. A con ança na utilização dos dados, resultante dos processos de MDM, deixa os trabalhos mais fáceis e produtivos. Quando as empresas têm dados mestres corporativos, a necessidade de “visões departamentais da verdade” se reduz à medida que as fontes corporativas amadurecem. Desta forma, as empresas podem começar a desfazer a rede de interfaces “spaghetti-ware”. Em assuntos referentes às funções de Gestão de Dados, costumo dizer que uma imagem vale mais do que mil palavras. A gura a seguir mostra dois cenários típicos: o primeiro, antes da implantação de um MDM, e o segundo, após a implantação do MDM, seguindo uma abordagem de implementação conhecida como consolidação.

Figura 9.4 – Exemplo de utilização “antes e depois” de um programa de MDM

Antes da implantação do MDM, podemos observar que os dados uem sem nenhuma organização através de silos de dados, possivelmente redundantes e não integrados. Após a implantação do MDM temos um visual mais limpo sobre a distribuição e o consumo desses dados. O barramento de serviços foi sinalizado como opcional, pois uma empresa pode ou não adotar uma estratégia de distribuição dos dados via serviços. Da forma como foi representada, a gura abrange as duas opções. Vale ressaltar que existem outras formas de arquiteturas de implementação para utilização do MDM além da consolidação, utilizada na gura anterior. Essas formas serão mais bem detalhadas agora.

9.6. Estilos de arquiteturas de dados mestres 9.6.1. Pré-MDM Embora pareça o contrário, Pré-MDM não é um estilo de arquitetura de MDM. Representa um estágio em que as aplicações não estão integradas do ponto de vista de uma gestão de dados mestres. Nele o grau de maturidade

em MDM é nulo e representa, de forma esquemática, o próprio problema que um sistema de MDM busca resolver. As aplicações do usuário têm como objetivo principal apoiar as atividades necessárias aos processos de negócio da empresa. Este apoio é materializado através da execução automatizada de transações. Do ponto de vista dos dados e da sua persistência, as transações são relacionamentos com atributos dos dados representados pelos dados mestres. Os dados que participam das transações pertencem ao escopo particular de uma aplicação e geralmente não são compartilhados (exceto quando são replicados). A gura a seguir demonstra um exemplo desse estágio.

Figura 9.5 – Estilo de implementação pré-MDM

A existência de um silo representa a falta da necessidade de compartilhamento das transações que são propriedades de uma aplicação. Mas para uma transação se realizar ela deve encontrar elementos prévios sob os quais atua: os dados mestres e dados de referência. Estes podem também ser propriedade de um determinado silo e não precisam se submeter a um compartilhamento. Entretanto, existem dados mestres e dados de referência que aparecem em aplicações de silos diversos com estrutura, semântica e conteúdo iguais ou similares. Esses dados, altamente compartilhados, estão associados a nomes e conceitos críticos do negócio e atravessam um grande número de aplicações.

Esse compartilhamento conceitual não é governado do ponto de vista físico do conteúdo de dados. Com isso, problemas típicos de qualidade dos dados, tais como inconsistências e duplicação, começam a aparecer tanto no ambiente de operações cotidianas do negócio como nas operações onde o dado tem um peso estratégico. Os silos de dados representam assim um atraso diante da necessidade de integrar uma corporação. 9.6.2. Consolidação A consolidação é formada por um repositório que armazena os dados mestres e de referência que são importados via batch das várias fontes de dados da empresa. Na consolidação, os dados são submetidos a processos de transformação e Qualidade de Dados, de forma a prover os registros dourados. O sucesso da consolidação dos dados depende muito do número de fontes de dados que alimenta o repositório de dados mestres e também da necessidade da visão única dos dados. Os critérios de sobrevivência e descarte dos dados duplicados, a padronização e o enriquecimento contribuem para os resultados mais dedignos nos ambientes de dados. Uma solução de arquitetura puramente de consolidação, embora dando uma maior qualidade aos dados mestres e dados de referência, não reverte totalmente em uma maior qualidade no ambiente das fontes dos dados. O saneamento dos geradores de erros reside nas aplicações e em seus silos de dados. A consolidação possui uma forte similaridade com os ODS (Operational Data Store), já que um ODS é também um ponto de agregação e área de staging para os sistemas de Data Warehousing. A distinção reside na

capacidade oferecida por um sistema de MDM que está além do armazenamento e do gerenciamento fornecidos por um ODS. Um ODS não oferece as facilidades de acesso, governança e serviços de Gestão de Dados de negócio para gerenciar os dados mestres e apoiar os gestores de dados de negócio na investigação e resolução de problemas potenciais de Qualidade de Dados. A principal vantagem da consolidação é que este estilo de arquitetura é uma fase “natural” para as fases iniciais de um programa de MDM. O foco desta arquitetura são tanto as aplicações analíticas como as aplicações operacionais. Entre as desvantagens, a principal é o fato das soluções não oferecerem os dados mais atuais, devido ao intervalo para transformação, sincronização e qualidade dos dados. Geralmente este intervalo é de um dia. Ou seja, os dados re etem a realidade do dia anterior. Outra desvantagem a ser considerada é o fato de que novas informações devem constar nos sistemas fontes. Se for necessária a criação de um novo atributo, por exemplo, o sistema fonte deverá ser alterado. A gura a seguir demonstra um exemplo do estilo de arquitetura da consolidação.

Figura 9.6 – Exemplo de arquitetura MDM – Consolidação

9.6.3. Registro Registro é um estilo de arquitetura útil para fornecer uma fonte única de leitura dos dados mestres, sem a necessidade de redundância de todos os atributos desses dados. Este estilo contém um mínimo de informações necessárias para identi car exclusivamente os registros dos dados mestres. Porém, fornece referências cruzadas para informações detalhadas, que são geridas dentro de outros sistemas e bancos de dados. O registro é capaz apenas de limpar e combinar informações de identi cação e assume que os sistemas de origem são capazes de gerenciar adequadamente a qualidade dos seus próprios dados. Esta arquitetura permite buscar dados de um mesmo conceito que são armazenados em fontes diferentes de dados. As consultas aos dados mestres são montadas de forma dinâmica. As referências cruzadas são úteis para indicar em que bases locais os demais atributos estão localizados. É feita, então, a recuperação dos demais atributos a partir das referências. As consultas podem ser feitas tanto na camada de banco de dados ou através de uma arquitetura de serviços. A gura a seguir demonstra um exemplo do estilo de arquitetura de registro.

Figura 9.7 – Exemplo de arquitetura – Registro

Esta arquitetura possui a vantagem de manter a maioria dos dados nos sistemas fontes e não há intervalo mínimo de tempo para a consulta dos dados. Ou seja, o dado consultado é real (atualizado). Este estilo é adequado para uma rápida implementação em razão dos dados continuarem nas bases locais e mantidos por elas. As aplicações locais também não precisam ser modi cadas para se tornarem sensíveis ao novo ambiente de dados mestres. No caso de aquisições e fusões, este estilo permite uma rápida integração dos dados sem que haja necessidade de muitos acordos sobre os metadados (que são necessários cada vez mais nos estilos seguintes). Alguns problemas ocorrem com este estilo de implementação. Um dos principais é que um tratamento mais poderoso da Qualidade de Dados não é possível devido aos atributos localizados nas bases locais. Neste caso, o máximo permitido é um trabalho nos atributos mínimos de identi cação que estão no repositório MDM.

Este estilo de implementação é mais sensível à disponibilidade e performance dos sistemas fontes. Requer também uma forte prática de governança distribuída, já que envolve consultas de outras aplicações e suas bases de dados. Qualquer modi cação nas fontes deve ser cuidadosamente coordenada para evitar erros nas consultas subsequentes. 9.6.4. Coexistência O estilo coexistência compõe-se de dados mestres que estão espalhados em várias bases de dados de sistemas fontes e replicados no hub MDM. Os dados mestres são consolidados e submetidos a processos de melhoria da qualidade dos dados no repositório central do hub MDM da mesma forma que no estilo consolidação. Os dados mestres, agora com qualidade, são alimentados de volta para as bases fontes através de processos de sincronização. Este estilo participa de um sistema distribuído e serve de fonte certi cada para outras aplicações e sistemas. Como os dados mestres residem também no repositório do hub MDM, a Qualidade de Dados pode ser tratada de forma completa. Um ciclo de sincronização atendendo às restrições do negócio resolve os con itos, parte de forma automática e parte de forma manual, através dos gestores de dados de negócio, enquanto mantém os dados dentro de uma janela de tempo para a realização da consolidação. Vale ressaltar que deve ser previsto um cuidado especial na sincronização dos dados mestres para evitar atualizações cíclicas. A coexistência proporciona um conjunto completo de dados mestres sem fazer grandes alterações no ambiente existente. Além disso, a vantagem de prover um conjunto completo de capacidades ao MDM favorece este estilo, embora o fato de haver vários pontos onde os dados podem ser alterados di culte a manutenção da consistência.

Outra di culdade encontrada é na implementação do sincronismo bidirecional, em função da complexidade em fazer mapeamentos e outras operações, inclusive com o uso de ferramentas de integração que lidam com várias fontes de dados. A gura a seguir demonstra um exemplo do estilo de arquitetura de coexistência.

Figura 9.8 – Exemplo de Arquitetura MDM – Coexistência

9.6.5. Coexistência só de leitura Este é um estilo de transição entre o modelo de coexistência e o transacional. Muitas das características, pontos positivos e negativos são similares ao estilo de coexistência. A retirada da capacidade das aplicações de modi carem os dados facilita a sincronização, que agora é unidirecional, em direção às fontes. Tanto as fontes de dados quanto o sistema de MDM podem sofrer leitura, porém a atualização só ocorre no repositório central. A principal vantagem desta arquitetura é que a implementação do sincronismo unidirecional é mais simples do que o sincronismo bidirecional.

A gura a seguir demonstra um exemplo do estilo de arquitetura de coexistência (somente leitura).

Figura 9.9 – Exemplo de Arquitetura MDM – Coexistência (somente leitura)

9.6.6. Transacional A arquitetura transacional é um estilo de implementação centralizada. Todas as operações de criação, atualização e exclusão dos dados são centralizadas exclusivamente no hub MDM. A arquitetura transacional tem seu nome derivado do fato de que nesta arquitetura o hub MDM se integra com a camada operacional de dados e esta depende fortemente do hub MDM para efetuar suas transações. Um requisito de robustez e disponibilidade, além dos de qualidade dos dados, emerge imediatamente desse fato. O estilo de implementação num hub MDM transacional centraliza um conjunto completo de dados mestres de vários domínios. A coleção completa de dados mestres de uma empresa ca armazenada em uma única fonte de dados (hub MDM), exceto os atributos não

compartilhados. Embora seja uma arquitetura aparentemente mais simples, seu uso é mais complexo e custoso; porém, de forma geral, traz benefícios pela maior facilidade de governança. A gura a seguir demonstra um exemplo do estilo de arquitetura transacional.

Figura 9.10 – Exemplo de Arquitetura MDM – Transacional

9.7. Passos para implantar o MDM Até o momento, já tomamos conhecimento dos principais conceitos sobre dados mestres, dados de referência, a gestão desses dados, além das abordagens de arquitetura que contemplam o MDM. Mas como é possível implantar um MDM nas empresas? Quais passos comuns são necessários? Os tópicos que se seguem fornecem uma visão geral de como pode ser feita a implantação da Gestão de Dados mestres e dados de referência em uma empresa. 1. Identi car as fontes de dados mestres: 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. Identi car os produtores e os consumidores dos dados mestres: Quais aplicativos utilizam os dados mestres? Dependendo da

abordagem utilizada na manutenção desses dados, 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 dos dados mestres: para todas as fontes identi cadas na primeira etapa, quais são as entidades e os atributos dos dados e o que eles signi cam? Geralmente incluem-se os nomes dos atributos, os tipos de dados, os valores aceitos, as restrições, os valores padrão, as dependências e os proprietários das de nições e manutenções 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 bastante signi cativo. 4. Indicar os gestores de dados de negócio: deverão ser pessoas com profundos conhecimentos sobre os dados atuais e também capazes de determinar como transformar as fontes para os formatos de dados mestres. Os gestores de dados de negócio deverão ser indicados pelos proprietários de cada fonte de dados mestres. 5. Implementar um programa de governança dos dados para os dados mestres: a governança dos dados é fundamental para manter e obter conhecimento e autoridade para tomar decisões sobre como os dados mestres devem ser mantidos, por quanto tempo serão gerenciados e como as alterações serão autorizadas e auditadas. 6. De nir a arquitetura de MDM: este passo deve ser dado antes da construção do modelo de dados mestres. Dependendo da arquitetura adotada, haverá in uência na construção dos modelos físicos do MDM.

7. Desenvolver o modelo de dados mestres: este passo de ne quais informações dos dados mestres serão incluídos, de que porte e tipo são os dados, quais valores são aceitos, quais os relacionamentos entre os dados mestres e dados de referência, etc. Esta etapa deve incluir também o mapeamento entre o modelo de dados mestres e as atuais fontes de dados. Normalmente esta é a etapa mais importante e a mais difícil do processo. 8. Escolher um conjunto de ferramentas: geralmente será preciso comprar ou construir ferramentas para gerir os dados mestres: limpando, transformando e mesclando os dados-fonte. Além disso, será preciso uma sólida infraestrutura para utilizar e manter esses dados. Pode ser utilizado um único conjunto de ferramentas, de um mesmo fornecedor, para todas essas funções, ou talvez adotar outra abordagem tipo: “melhor ferramenta para cada função”. 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. 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. 9. Projetar a infraestrutura: depois dos dados mestres estarem limpos e consistentes, será necessário colocá-los à disposição de seus aplicativos e providenciar processos para a sua administração e manutenção. 10. Gerar e testar os dados mestres: é nesta etapa que serão utilizadas as ferramentas desenvolvidas ou compradas para gerir os dados mestres. Em geral, este é um processo iterativo que exige explorar regras e con gurações para chegar a correspondências corretas. Este processo também exige grande volume de veri cações manuais para con rmar se os resultados estão corretos e também se atendem aos requisitos estabelecidos.

11. Modi car os sistemas de produção e de consumo: dependendo de como a implementação do MDM estiver projetada, provavelmente será preciso modi car os sistemas que produzem, mantêm ou consomem os dados mestres para trabalharem com as novas fontes de dados. 12. Implementar os processos de manutenção dos dados mestres: qualquer implementação de MDM deve incorporar ferramentas, processos e pessoas para manter a qualidade dos dados. Todos os dados mestres devem ter um gestor, que será responsável por garantir a sua qualidade. Em geral, o gestor de dados de negócio é uma pessoa que trabalha dentro do negócio, com conhecimento dos dados, que tem condições de reconhecer dados incorretos e tem conhecimento e autoridade para corrigir as falhas.

10. Qualidade de Dados “A qualidade é a quantidade de amanhã.” Henri Bergson

10.1. O que é Qualidade de Dados? Podemos a rmar que os dados possuem qualidade quando eles satisfazem os requerimentos para os quais foram criados. Isso implica que a Qualidade de Dados é sempre de nida sobre a visão de negócio da empresa. A conquista desta qualidade é realizada através dos processos de Qualidade de Dados que buscam garantir que os dados armazenados sejam corretos, precisos, consistentes, completos, integrados, aderentes às regras de negócio e aderentes aos domínios estabelecidos. Tal como a Governança de Dados, a Qualidade de Dados também envolve esforços integrados através de pessoas, processos e tecnologia com o propósito de gerar valor para a organização a partir dos dados armazenados. Conforme gura a seguir, a Qualidade de Dados pode ser dividida em três grandes grupos. São eles: Qualidade dos metadados. Qualidade do conteúdo dos dados.

Qualidade dos processos de Gestão de Dados.

Figura 10.1 – Grupos de Qualidade de Dados

A qualidade dos metadados é executada quando os gestores de dados (técnicos e de negócio) atuam nos processos onde os metadados são criados, veri cados e manipulados. Muitos desses processos ocorrem antes das estruturas de dados serem promovidas para o ambiente de dados em produção. Entre os processos mais comuns podemos destacar: processos ligados à Modelagem de Dados e avaliações da qualidade dos modelos de dados. Apesar de conceitualmente ser diferente, a qualidade dos metadados in uencia diretamente a qualidade dos dados (conteúdo). A qualidade do conteúdo é aplicada em cima dos dados que são utilizados já no ambiente de produção ou estão próximos a serem promovidos, através de técnicas especí cas que buscam identi car e corrigir os dados de baixa qualidade. A qualidade dos processos monitora todos os processos de Gestão de Dados, e não somente os processos de Qualidade de Dados, e busca a tomada de ações de melhoria contínua em cima das métricas e dos indicadores dos processos controlados.

De forma equivocada, a Qualidade de Dados por muitos ainda é considerada uma função não proativa, contemplada apenas pela qualidade do conteúdo dos dados e dedicada somente à identi cação dos dados sujos e suas correções. Entretanto, a Qualidade de Dados não se resume apenas à veri cação e à correção desses dados, mas também ao planejamento, à garantia e às ações de melhoria contínua que podem ser aplicadas em seus processos. Deming, um dos principais papas da qualidade, já dizia: “A qualidade é planejada e não inspecionada”. Para poder exempli car esta a rmação, também atuamos na Qualidade de Dados quando: Utilizamos uma Arquitetura de Dados e de nimos as prioridades das ações em cima das entidades de dados representadas nesta arquitetura. Esta ação permite um planejamento e caz não só da qualidade, mas de todas as demais necessidades desses dados. Atuamos de forma proativa na orientação e construção dos modelos de dados e demais metadados da empresa. Esta ação permite uma melhor garantia da qualidade na construção desses artefatos. Atuamos na veri cação dos modelos de dados e demais metadados produzidos na empresa. Esta ação permite um melhor controle sobre as estruturas de dados antes destas entrarem no ambiente produtivo. A nal, sem metadados de qualidade, o que poderemos esperar dos dados armazenados nessas estruturas? Promovemos campanhas direcionadas sobre Qualidade de Dados, tanto dentro do ambiente de TI quanto dentro do ambiente de negócio. A nal, não adianta uma empresa possuir estruturas de dados de excelência e processos de Qualidade de Dados bem estruturados se as pessoas que criam os dados nas aplicações não entendem a importância

de ter dados corretos e reais e incluem dados sujos dentro das bases de dados da empresa. O conteúdo deste capítulo é dedicado à qualidade do conteúdo dos dados, mas vale destacar que a qualidade dos metadados, representados pelos modelos de dados, foi abordada no capítulo de Modelagem de Dados.

10.2. Dados de baixa qualidade – Dados sujos As consequências do uso de dados de baixa qualidade podem ser observadas no nosso cotidiano, porém, muitas vezes, não temos o entendimento necessário para saber as reais causas. Por exemplo, o atraso ou a entrega em um endereço incorreto de uma correspondência de cobrança é muitas vezes atribuído ao serviço de entrega, mas outras causas podem ser a razão do problema: erros de digitação no cadastro, erros de sistema, erros na carga e/ou transformação dos dados, entre outros. Dados sujos geram uma série de problemas, desde pequenos inconvenientes até grandes perdas nanceiras, devido a cálculos de dados sem qualidade, gerando grandes prejuízos e também multas e processos judiciais decorrentes do uso de dados sem qualidade. De forma geral, as principais causas da qualidade ruim de dados dividemse em quatro grandes grupos: Grupo 1 – Aspectos técnicos: Erros cometidos em todas as etapas de um processo de armazenagem dos dados. Desde a concepção, passando pela implantação, até o seu efetivo uso. Falta de processos e ferramentas para aferir e tratar a qualidade dos dados. Grupo 2 – Aspectos humanos:

Erros não intencionais na entrada de dados. Falta de entendimento. Pouco treinamento. Entrada de dados incorreta feita de forma intencional ou maliciosa. Processos de análises, coleta de dados e resolução de problemas precariamente de nidos ou inexistentes. Entrada de dados em múltiplos níveis. Grupo 3 – Fatores Organizacionais: Integração de base de dados em fusões e aquisições de empresas. Desintegração de bases de dados. Dispersão de bases dados ao longo de diferentes departamentos ou empresas de um grupo. Falta de conscientização sobre a importância da qualidade dos dados. Base de dados legadas sem controle. Grupo 4 – Negligência Corporativa: Desconhecimento do valor em melhorar a Qualidade de Dados até que os problemas são descobertos. Não há percepção de que uma melhor Qualidade de Dados é necessária. Medo de demonstrar as fraquezas existentes em TI e expor a empresa. Falta de uma visão clara de quem é o responsável e quem se bene cia com a qualidade dos dados.

Falta de disseminação do conhecimento, de treinamento e participação do corpo técnico e gerencial no assunto.

10.3. Processo de Qualidade de Dados (conteúdo) Atualmente existem vários processos e soluções de Qualidade de Dados propostos por diversas empresas fabricantes de soluções de Data Quality e também propostos por autores de respeito. O macroprocesso abordado neste livro procura demonstrar uma forma simples de estabelecer a Qualidade de Dados com o foco no conteúdo dos dados, através de atividades comuns identi cadas na maioria dos processos existentes. Vale ressaltar que, dependendo das características organizacionais de uma empresa, o macroprocesso proposto a seguir pode ser incrementado com mais atividades e/ou processos. Entretanto, os seis processos mencionados no macroprocesso a seguir são considerados obrigatórios. Os processos podem ser renomeados ou até mesmo divididos em mais processos, porém a essência de suas atividades deve ser mantida, ou seja, não devem ser ignorados em nenhuma implantação de Qualidade de Dados nas empresas. O macroprocesso proposto neste livro é representado na gura a seguir.

Figura 10.2 – Processos de Qualidade de Dados

O macroprocesso se caracteriza pela sequência de cinco processos fundamentais: Promover a Qualidade dos Dados, De nir Requisitos e Questões da Qualidade, Per lar Dados, Analisar Dados e Limpar e Corrigir Dados. Todos os cinco processos são acompanhados através de um processo dedicado à Garantia da Qualidade dos Dados e Modelos de Dados. Os processos de qualidade dos modelos de dados também não devem ser esquecidos – por esta razão foram representados na gura. A qualidade dos modelos de dados já foi abordada em capítulos anteriores. Neste capítulo trataremos da qualidade do conteúdo dos dados. 10.3.1. Promover a Qualidade dos Dados São os processos dedicados a promover a importância da Qualidade de Dados nas empresas. Esta promoção geralmente é feita através da capacitação e conscientização dos envolvidos através de palestras, workshops e treinamentos focados em qualidade. Outra forma comum de efetivar a promoção é através da divulgação de exemplos de qualidade baixa de dados que podem gerar efeitos negativos para a empresa. Se possível, deve-se

evidenciar problemas reais que comprometam os negócios, questões de regulamentação e até mesmo a imagem da empresa. Esta fase é fundamental para angariar novos patrocinadores e aliados para a dura jornada que virá nos processos seguintes. Os envolvidos devem tomar ciência nesta fase de que nem sempre o problema da qualidade baixa de dados é proporcionado e/ou gerido pela própria TI da empresa. Os gestores de dados devem conscientizar os envolvidos em um dos principais princípios da Gestão de Dados, que é a responsabilidade compartilhada pelos dados. Muitos projetos de Qualidade de Dados não seguem adiante devido à di culdade em se levantar o retorno sobre o investimento da iniciativa. Este retorno só é possível mensurar com certa precisão se os dados de má qualidade (dados sujos) e os problemas decorrentes ao seu uso já são conhecidos. De qualquer forma, se não é possível obter os dados reais sobre a baixa qualidade dos dados, provavelmente a empresa ainda não adquiriu uma ferramenta para apoiar os processos de Qualidade de Dados. Uma boa alternativa neste caso é escolher e segregar um pequeno conjunto de dados, corporativos, aparentemente com baixa qualidade, e avaliá-los com o apoio de uma ferramenta em um processo de prova de conceitos (POC). É bastante comum os fornecedores oferecerem recursos temporários e limitados para testar suas ferramentas antes de uma possível compra. 10.3.2. Definir requisitos e questões da qualidade Processo que de ne os requisitos de Qualidade de Dados que irão possibilitar avaliações padrão e geração dos indicadores sobre a qualidade dos dados. Os requisitos de qualidade são determinados levando em conta as necessidades da empresa.

O DAMA-DMBOK® estabelece alguns requisitos comuns para a qualidade dos dados. São eles: Acurácia: determina se as entidades da vida real estão representadas corretamente nos dados. Completude: determina se os dados estão completos de acordo com as informações exigidas na execução dos processos de negócio. Consistência: determina se os dados estão íntegros e coerentes. A veri cação é feita através do cruzamento entre duas ou mais fontes de dados. Atualidade: determina o quanto os dados estão atualizados e representam verdadeiramente o estado atual das informações. Precisão: determina se os dados representam o grau de precisão necessário, como casas decimais, por exemplo. Privacidade: indica que o dado ou metadado é conhecido e está disponível, no momento necessário, para quem tem o devido acesso. Envolve conceitos de governança e segurança dos dados e informações. Razoabilidade: considera como relevante a consistência de expectativas dentro de um contexto operacional. Exemplo: número estimado de transações por dia dentro dos limites estabelecidos. Integridade referencial: indica que o dado atende a todas as restrições de integridade necessárias para que possa ser considerado um dado con ável. As restrições de integridade permitem a representação das regras de negócio, que, se não forem respeitadas, irão prejudicar a con abilidade dos dados. Unicidade: indica que o dado é único e exclusivo dentro da empresa. Não há repetição de conteúdo e conceitos. Ou seja, não existem outros dados iguais. Quando esta dimensão é violada, ocorre a redundância.

Validade: garante que todos os valores de dados estão em conformidade com os atributos associados aos elementos de dados: tipo, precisão, padrão de formato, valores prede nidos, entre outros. Os requisitos de qualidade podem possuir várias dimensões, que variam de acordo com fontes e autores. Outras dimensões bastante comuns e mencionadas por outros autores são: Aderência ao negócio: indica que o dado ou metadado está aderente em sua totalidade (por completo) aos requisitos de informação e regras de negócio da empresa. Con abilidade: indica que o dado é atual, correto (sem erros) e pode ser utilizado sem afetar negativamente qualquer tipo de uso. Não existem erros de transformação, disponibilização e até mesmo de digitação. Manutenibilidade: indica baixo esforço na manutenção dos dados quando há uma solicitação de mudança que irá afetar os dados. Metadados especi cados em modelos de dados de forma exível costumam ter baixo custo de manutenção – em alguns casos, dependendo da mudança, o esforço é feito somente nas aplicações, sem necessidade de alteração no modelo de dados ou dados das aplicações. Performance: indica que o tempo de resposta e acesso aos dados são satisfatórios para os requisitos de uso. Legibilidade: fácil entendimento, compreensão e utilização dos dados, gerando outros dados de qualidade. A seleção dos requisitos de qualidade são fundamentais para de nir as questões que serão aplicadas nos processos de Qualidade de Dados. As de nições das questões representam quais críticas deverão ser levantadas nos dados armazenados. De forma geral, é feita uma lista padrão

com as questões relacionadas que podem ser aplicadas tanto no conteúdo quanto na estrutura dos dados. Na de nição dessas questões, podemos atribuir pesos aos impactos que elas causam. Algumas questões são mais críticas que as outras, e por esta razão devemos estabelecer pesos e medir os impactos da má qualidade dos dados. Entre as críticas mais comuns, podemos encontrar: erros no formato, constantes, dados inconsistentes, inconsistência de tipo de dado, regras de nulos inconsistentes, chaves inválidas, valores inválidos, valores não preenchidos, lhos órfãos, valores fora da faixa, exceções de padrões, constantes potenciais, valores potenciais, duplicatas potenciais, inválidos potenciais, valores potenciais redundantes, campos não usados e regras para exceções. 10.3.3. Perfilar dados – Data profiling O processo de Per lar Dados, também conhecido como Data Profiling, faz uso de técnicas analíticas sobre os dados com o propósito de desenvolver o conhecimento sobre seu conteúdo, estrutura e qualidade. Em suma, esta per lagem é uma espécie de exame (diagnóstico) a respeito da qualidade dos dados existentes. Vale ressaltar que este é um processo dedicado a desenvolver informações sobre os dados, ao invés de informações a partir dos dados. Os exemplos a seguir ajudam a entender essas diferenças: Exemplos de informações SOBRE os dados (Data Profiling): 30% das entradas de dados na coluna CD_FORNECEDOR estão marcadas com o caractere “espaço”. A faixa de valores do campo PRECO_UNITARIO_SERVICO vai de 100,99 a 4599,99.

Existem 140 linhas contendo PEDIDOS sem linhas contendo os seus DETALHES. Exemplos de informações A PARTIR dos dados: (NÃO é Data Profiling): As lojas do Rio de Janeiro vendem mais itens congelados do que as lojas das demais regiões. O valor médio das vendas cresceu 6% este ano. 10% dos clientes que compraram produtos no ano passado não compraram produtos este ano. Durante o processo de Data Profiling, algumas etapas complementares são executadas, como: coleta da documentação a respeito dos dados, avaliação dos dados e. por m, a comparação dos dados com a documentação. Neste ponto é comum ocorrerem questões onde o gestor técnico de dados apontou a necessidade de cuidados adicionais para garantir a integridade dos dados, porém esses cuidados não foram feitos, apenas representados através de observações e/ou ressalvas nos modelos de dados. 10.3.4. Analisar dados Esta fase é concentrada na avaliação dos dados através das métricas e também das principais regras de negócio que podem acarretar em possíveis quebras de conformidade. As prioridades estabelecidas na etapa de de nição dos requisitos de dados podem ser revistas neste ponto, levando-se em conta o volume de dados incorretos encontrados durante a execução da per lagem dos dados. As métricas devem representar medidas de nidas com clareza, através de elementos quanti cáveis e associados aos objetivos do negócio, com determinações claras sobre como medir e analisar os dados, estabelecer as

faixas de valores aceitáveis, além de estabelecer planos de ação, quando aplicável. As regras de negócio devem ser observadas na sua qualidade para garantir sua aderência aos processos de negócio ou, até mesmo, em situações pouco comuns, para identi car novas regras, não previstas na aplicação, porém já contempladas nos dados. Dependendo do volume de dados de baixa qualidade, a análise dos dados também pode servir de instrumento para de nir prioridades na sua correção. 10.3.5. Limpar e corrigir dados – Data cleansing Também conhecido como Data Cleansing, este é um processo de atualização e correção dos dados, garantindo a consistência das informações. Através de ferramentas e aplicação de regras, os dados são corrigidos. O Data Cleansing caracteriza-se por estimar os problemas e aplicar as regras para sua correção. Limpar dados resolve problemas momentâneos, fazendo com que as informações errôneas sejam corrigidas, porém não evita a recorrência de novos problemas. Caberá à equipe de Qualidade de Dados o tratamento para que novas ocorrências para os mesmos problemas não voltem a surgir. Este fato reforça a tese de que a Qualidade de Dados deve fazer parte da cultura da empresa e ser tratada como um processo contínuo e não como um projeto sob o risco dos mesmos problemas voltarem novamente nas próximas rodadas do processo. A correção dos dados pode ser feita de forma manual ou de forma automática. A forma automática é feita com o apoio de ferramentas e utiliza

técnicas de limpeza e transformação dos dados. Entre as mais conhecidas estão a deduplicação e as regras de padronização de conteúdo. A deduplicação é a técnica que identi ca registros duplicados em uma base de dados. Esses registros podem ser eliminados ou apenas marcados para controle e futura eliminação. A deduplicação prevê a utilização de diversas variáveis que acabam compondo as chaves primárias ou secundárias para identi cação dos registros. Já as regras de padronização são formadas através da análise sintática e da análise de referência normalizando campos padronizáveis. Um bom exemplo é um padronizador de endereços que corrige os endereços de um grupo de dados. Vale ressaltar que ambientes com padrões bem de nidos aceitam regras e padrões de erros conhecidos com mais facilidade. Já a correção manual é indicada para pequenos volumes de dados e geralmente é feita pelos próprios gestores de dados de negócio, que inspecionam os registros inválidos e determinam os valores corretos para fazer as correções e aplicar a atualização dos registros. 10.3.6. Garantia da Qualidade dos Dados e Metadados A Garantia da Qualidade dos Dados e Metadados é executada através dos registros diários das atividades, onde os valores e métricas são transformados em indicadores e logo após são submetidos a avaliações periódicas a m de obter melhorias nos seus processos. Entre os indicadores mais comuns desses processos podemos destacar os indicadores referentes à qualidade dos modelos de dados, ao reuso dos dados e metadados, ao índice de chamados de correção de dados (via usuários das aplicações) e ao índice de identi cação e correção dos dados. Cabe aos gestores de dados (técnicos e de negócio) fazer a pré-avaliação desses indicadores, propondo ações que serão sugeridas nas reuniões de

análise crítica. Muitas dessas ações são obtidas através da aplicação das ferramentas comuns de qualidade do processo, tais como: diagramas de Pareto, diagramas de causa e efeito, histogramas, uxogramas, grá cos de controle, etc. As reuniões de análise crítica são periódicas, muitas vezes estabelecidas em um comitê ou comissão para tratar especi camente da qualidade dos dados e metadados. Ao m de cada reunião, são estabelecidas ações para a melhoria dos processos. Este é o conceito da melhoria contínua: monitorar a qualidade dos dados e tomar ações para aprimorar os processos de negócio, os processos de Gestão de Dados e a qualidade dos dados.

10.4. Considerações finais sobre a Qualidade de Dados Qualidade de Dados ainda é uma função pouco praticada nas empresas brasileiras. Muitas pessoas ainda confundem Qualidade de Dados com processos de veri cação e correção dos dados e metadados, entretanto, a Qualidade de Dados possui um conceito muito mais amplo, iniciando pelas atividades de planejamento e tendo todas as fases registradas e monitoradas com o propósito de estabelecer uma melhoria contínua tanto dos processos quanto da qualidade dos dados. Entre os principais conceitos e boas práticas que foram mencionados neste capítulo, podemos destacar: A qualidade dos dados engloba três grandes conceitos: a qualidade dos metadados, a qualidade dos dados e a qualidade dos processos de Gestão de Dados.

Qualidade de Dados não é somente inspeção; ela engloba outras fases, como o planejamento e a melhoria contínua. A Qualidade de Dados deve ser encarada como um processo constante dentro de uma empresa, e não como um simples projeto. Dados de má qualidade são considerados “dados sujos” e causam danos ao negócio e à reputação das empresas. Os requisitos de qualidade são muitos e variam a cada fonte/autor. Cabe a cada empresa de nir os seus requisitos levando em conta suas características e o retorno para o negócio. O mesmo vale para os processos de Qualidade de Dados. Devem ser estabelecidos de acordo com as características das empresas. De qualquer forma, existem processos comuns que são adotados em qualquer programa de Qualidade de Dados. São eles: Promover a Qualidade dos Dados, De nir Requisitos e Questões da Qualidade, Per lar Dados, Analisar Dados, Limpar e Corrigir dados e Garantia da Qualidade dos Dados e Metadados. As correções devem ser aplicadas nas fontes originais sempre que possível.

Parte 3 Gestão de Dados Moderna

11. Gestão de Dados Moderna “Pense como um homem de ação e atue como um homem de pensamento.” Henri Bergson

11.1. Visão geral da Gestão de Dados Moderna A Gestão de Dados Moderna não é um framework e nem uma metodologia. Ela é apenas uma loso a de trabalho mais proativa, focada na conduta comportamental dos pro ssionais que atuam na área. Tal como as premissas de responsabilidade compartilhada entre as áreas de TI e negócio, a Gestão de Dados Moderna também sugere a busca de uma visão mais abrangente das áreas de negócio das empresas pelos pro ssionais de Gestão de Dados. Essa visão não seria mais focada somente em bancos de dados e tecnologia da informação, e sim no alinhamento da tecnologia ao negócio. Seu surgimento se fez necessário principalmente para acompanhar as novas tendências tecnológicas que envolvem a manipulação e o uso dos dados e também novas características de trabalho, tais como: Distribuição do trabalho em várias frentes, onde algumas equipes estão distribuídas em diferentes localizações geográ cas. Em alguns casos,

até em países diferentes. Métodos de desenvolvimento ágil de aplicações, onde o tempo de resposta às solicitações deve ser muito rápido. O envolvimento e o comprometimento das equipes de Gestão de Dados com os objetivos e as metas das demais equipes envolvidas são fundamentais para ambas manterem uma boa harmonia e consequentemente atuarem juntas na busca de propósitos em comum, tais como: participação mais efetiva dos clientes nos projetos, desenvolvimento da equipe, agilidade nas respostas às solicitações/mudanças e melhoria contínua. Desta forma, as equipes de Gestão de Dados conseguem acompanhar a adoção de novos paradigmas e tecnologias que vêm surgindo ultimamente e também acompanhar as necessidades de mudanças nos requisitos e nas regras de negócios adotadas pelas empresas. Conforme gura a seguir, a Gestão de Dados Moderna é formada por um quadro com três grandes conceitos: Estrutura da Gestão de Dados, Pilares das Organizações e Conduta.

Figura 11.1 – Visão geral da Gestão de Dados Moderna

A Estrutura da Gestão de Dados é composta por conceitos bastante comuns nas organizações que possuem equipes de Gestão de Dados em atividade, inclusive as equipes de Administração de Dados tradicionais. Os conceitos são tão comuns que podem ser considerados pré-requisitos para a adoção de uma área de Gestão de Dados em qualquer empresa.

11.2. Estrutura da Gestão de Dados A estrutura central da Gestão de Dados Moderna é formada pela região dos retângulos centrais: o corpo técnico e as ferramentas. Áreas formadas somente por este conjunto de atuação são conhecidas como áreas de Administração de Dados ou Gestão de Dados Tradicional. Grande parte dos produtos gerados e/ou manipulados pelas equipes de Gestão de Dados está concentrada nesta região. A parte central deste conjunto demonstra que, em maior ou menor nível de maturidade, as áreas de Gestão de Dados têm seus principais focos voltados para a qualidade e a governança dos metadados, possuem metodologias de nidas, estão (ou pretendem estar) alinhadas com os objetivos estratégicos das organizações, além de terem iniciativas ou domínio completo da governança dos dados e metadados de suas organizações. A este conjunto de práticas, localizadas na parte central do quadro, chamamos de Estrutura Central da Gestão de Dados. As principais diferenças entre a antiga Administração de Dados e a Gestão de Dados Moderna são muitas, porém se baseiam apenas em mudanças de atitude e visão dos pro ssionais. Na verdade, o que difere a Gestão de Dados Moderna da Gestão de Dados Tradicional são os conceitos da Conduta e Pilares das Organizações. Os retângulos centrais (Metodologia, Alinhamento Estratégico, Qualidade e Governança de Dados) correspondem aos grupos de processos,

documentos e diretrizes que são seguidos pelo corpo técnico de pro ssionais, com o apoio de ferramentas. 11.2.1. Corpo Técnico O Corpo Técnico de pro ssionais corresponde às pessoas envolvidas nas atividades de Gestão de Dados. Incluem-se aqui as pessoas lotadas em equipes de Gestão de Dados, tais como: gestores de dados (técnicos e de negócio), gestores estratégicos de dados, administradores de repositórios de metadados e DBAs, responsáveis por planejar e executar as práticas estabelecidas na estrutura central do quadro, além de pessoas de outras equipes que possuem alguma relação (mesmo que indireta) com as atividades. Por exemplo: pro ssionais de infraestrutura, pro ssionais das equipes de desenvolvimento, gerentes, coordenadores, etc. Vale ressaltar que a capacitação e a experiência do Corpo Técnico são fundamentais para o sucesso desta loso a. 11.2.2. Ferramentas As ferramentas correspondem aos sowares e às soluções de hardware utilizados para apoiar todas as atividades executadas pela área de Gestão de Dados. Entre os grupos de ferramentas mais utilizados podemos destacar: sistemas gerenciadores de banco de dados, ferramentas de modelagem, repositórios de modelos de dados, repositórios de metadados, ferramentas de Qualidade de Dados, ferramentas para Gestão de Dados mestres e dados de referência, ferramentas para ETL, repositórios de ativos, além de ferramentas customizadas para apoiar os processos e indicadores utilizados pelas equipes de Gestão de Dados.

O trabalho de estruturação da Gestão de Dados nas empresas não deve ser feito exclusivamente em função das ferramentas adotadas. O ideal é estruturar a forma de trabalho e depois selecionar ferramentas que melhor se adequem à forma de trabalho de nida. 11.2.3. Metodologia Metodologia é um conjunto de documentos que orientam os pro ssionais envolvidos com as funções e atividades preconizadas pela disciplina de Gestão de Dados na empresa. A metodologia descreve as regras do jogo de nidas nas atividades de Governança de Dados. Além disso, recomenda-se que a metodologia tenha caráter normativo (o que fazer? O que entregar?) e também voltado à orientação dos envolvidos (como fazer? Como entregar?). Entre os documentos de uma metodologia, geralmente encontramos: documentação institucional, processos e seus detalhamentos, padrões, boas práticas, templates de laudos e relatórios, ferramentas de qualidade, documentação de apoio e ferramentas de comunicação. 11.2.4. Qualidade Qualidade corresponde à execução dos métodos de controle e garantia utilizados para manter as estruturas de dados e o conteúdo dos dados aderentes aos graus de qualidade preestabelecidos. Esses critérios são encontrados na metodologia de Gestão de Dados vigente. Este retângulo abrange tanto a qualidade dos metadados (estruturas de dados) quanto a qualidade dos dados (conteúdo) e, dependendo da maturidade da empresa, a qualidade do processo de Gestão de Dados (planejamento, ação, controle e melhoria contínua).

11.2.5. Alinhamento estratégico Corresponde à ligação entre planejamento estratégico de negócio e planejamento estratégico de TI. Corresponde ao grau no qual a missão, os objetivos e planos re etem e são suportados pela missão, pelos objetivos e pelos planos de negócio e vice-versa. Seria, no caso, a clássica relação entre as fases de elaboração e implementação da estratégia corporativa. A adoção do alinhamento estratégico entre a Gestão de Dados e as áreas de negócio e TI permite que cada integrante da força de trabalho da Gestão de Dados saiba exatamente qual é o seu papel dentro da empresa e em que direção cada uma de suas ações deve ser guiada, para que os objetivos individuais representem e ajudem na conquista dos objetivos organizacionais. 11.2.6. Governança de Dados Desde o passado, a Governança de Dados sempre foi um objetivo a ser plenamente alcançado. Já nos tempos da antiga Administração de Dados, de uma forma ou outra, já havia a preocupação em ter as respostas para as seguintes perguntas: Qual a política adotada pela empresa sobre o uso dos dados e informações? Quais são as responsabilidades e os papéis envolvidos no uso dos dados e informações? Quais os processos utilizados para gerir dados e informações? Quais os padrões e procedimentos utilizados? Quem são os gestores das informações? Quem são as pessoas que avaliaram e atestaram a qualidade dos dados e metadados?

Quem tem direito a consumir quais informações? Quem construiu os mecanismos de guarda? Existem projetos estruturantes para melhorar a gestão dos dados? Quando a empresa possui uma Gestão de Dados formalizada e atuante, grande parte das questões é respondida, mesmo que eventualmente de forma super cial. A clareza e o conteúdo das respostas re ete diretamente a maturidade em Gestão de Dados da empresa.

11.3. Conduta Conduta é a postura adotada por todos os integrantes da equipe de Gestão de Dados. Equipes de Gestão de Dados que funcionam nos moldes tradicionais costumam não dar tanta ênfase em todos os aspectos comportamentais tidos como fundamentais pela Gestão de Dados Moderna para conquistar e manter parceiros, adaptar-se às necessidades dos clientes, diminuir o retrabalho dos envolvidos e melhorar a qualidade dos dados e metadados da organização. A Gestão de Dados Moderna entende que uma conduta bem trabalhada/incentivada resulta em um quadro de pessoas mais produtivas que gostam do que fazem, trabalham efetivamente como equipes e estão focadas em objetivos. Portanto, não necessitam de gerenciamentos e controles agressivos. Na prática, são equipes que todo gestor quer. A Gestão de Dados Moderna prega oito aspectos ligados diretamente à conduta pessoal que devem ser adotados pelos pro ssionais. São eles: Adaptabilidade, Agilidade, Bom Senso, Comprometimento, Didática, Objetividade, Proatividade e Racionalidade. O livro abordará as características dos oito aspectos, mas não detalhará como atingir cada uma delas, e sim as de nições de cada um dos aspectos.

11.3.1. Adaptação Adaptação é uma característica comportamental do ser humano que expressa a facilidade de se adaptar às novas tecnologias, ao ambiente, à cultura e a demais mudanças que ocorrem nas empresas. Toda adaptação estabelece o equilíbrio entre o organismo e o ambiente. A noção de equilíbrio tem um signi cado fundamental, tanto do ponto de vista afetivo quanto do intelectual. Na adaptação, tal equilíbrio se dá entre dois polos: a assimilação (relativa ao organismo, que conserva sua forma) e a acomodação (relativa à situação exterior em função da qual o organismo se modi ca). Essas duas noções têm um signi cado tanto mental quanto biológico. Há sempre uma tensão entre assimilação e acomodação. Pro ssionais que se destacam nesta característica comportamental têm total domínio do equilíbrio. Na prática, pro ssionais de fácil adaptação são menos sensíveis a quebras de paradigmas, costumam perder pouco tempo nas adaptações e geralmente participam como facilitadores nos processos de mudança. Além disso, não contaminam a equipe reclamando de tudo e de todos. 11.3.2. Agilidade Agilidade é a capacidade de dar respostas rápidas às solicitações com atitude, foco na entrega, trabalho em equipe e melhoria contínua. Ser ágil não signi ca atender com uma resposta negativa e sim atender rápido, dentro dos processos vigentes, com o propósito de entregar algo que foi solicitado, dentro das direções e premissas das equipes, sempre visando melhorar o processo atual de trabalho. Atualmente esta habilidade é fundamental, principalmente quando as equipes de Gestão de Dados estão envolvidas em desenvolvimento ágil de aplicações.

Dentro das empresas não há mais espaço para demoras excessivas na conclusão de trabalhos simples ou até mesmo condutas negativas, como segurar a conclusão de algum trabalho para mostrar que está trabalhando. A conduta deve ser outra – terminar logo o trabalho para poder car livre para assumir outra atividade. Cabe aos coordenadores e/ou gerentes das equipes monitorar o andamento das solicitações atendidas pelas suas equipes e, quando necessário, ajustar os desvios que possam ocorrer no dia a dia. 11.3.3. Bom senso Bom senso é uma habilidade utilizada na argumentação que é estritamente ligada às noções de sabedoria e de razoabilidade. O bom senso de ne a capacidade média que uma pessoa possui, ou deveria possuir, de adequar regras e costumes a determinadas realidades e assim poder fazer bons julgamentos e escolhas. Pode, assim, ser de nido como a forma de “ losofar” espontânea do homem comum, também chamada de “ loso a de vida”, que supõe certa capacidade de organização e independência de quem analisa a experiência de vida cotidiana. O bom senso está muito ligado à ideia de sensatez, sendo uma capacidade intuitiva de distinguir a melhor conduta em situações especí cas que, muitas vezes, são difíceis de serem analisadas mais longamente. O bom senso é a característica de conduta mais difícil de conseguir em todos os casos, pois, geralmente, a linha entre um senso muito rígido e um senso sem rigor é muito tênue. 11.3.4. Comprometimento

Comprometimento pode parecer algo simples de se entender em um primeiro momento, mas será que nós entendemos realmente o que é estar comprometido? O comprometimento é o resultado de duas características pessoais: a motivação e o engajamento. A motivação é decorrente de fatores internos do ser humano, do seu estilo de vida, de seus valores e crenças, objetivos e necessidades – ou seja, é pessoal. O papel da empresa é fazer com que o colaborador desenvolva esta motivação em sua rotina de trabalho. O engajamento é o entusiasmo, a satisfação pelo trabalho. É fazer com que a pessoa se sinta envolvida com a organização. Ela deve perceber que seu trabalho interfere diretamente em toda a cadeia de negócio da organização, gerando frutos e retorno direto. Não é apenas fazer o próprio trabalho bem feito, mas contribuir para que o todo faça da melhor maneira possível. Comprometimento é a junção dessas duas características e pode ser classi cado em dois tipos: o curto e o longo. O comprometimento curto é essencialmente uma promessa pontual, como: “vou terminar esse modelo de dados até o nal do dia” ou “vou descobrir a origem dessa informação até amanhã”. Já o comprometimento longo é quando uma pessoa ou equipe está comprometida com algo de uma forma mais emocional ou ideológica, como: “estou comprometido com a loso a da área” ou “estou comprometido com a equipe”. Pessoas que não possuem nenhum dos dois comprometimentos são aquelas que apenas fazem o que deve ser feito para se verem livres da tarefa e irem embora. Geralmente são pessoas que não gostam do que fazem ou estão desmotivadas por algum motivo. 11.3.5. Didática

Didática signi ca “habilidade em ensinar”. Envolve métodos e técnicas na orientação da aprendizagem. É o modo pelo qual um docente coloca em prática a passagem de conhecimento de uma pessoa a outra. A metodologia de Gestão de Dados vigente, bem como outros aspectos mais técnicos que envolvam algum conhecimento técnico, pode não ser conhecida por todos os envolvidos. Por esta razão, a didática é um importante aspecto a ser trabalhado/conquistado pelas equipes de Gestão de Dados. De todos os aspectos de conduta elencados pela Gestão de Dados Moderna, a didática é o menos pessoal, ou seja, é o aspecto que menos depende de fatores motivacionais. De forma geral, com o tempo, as pessoas evoluem em suas habilidades de didática. Raros são os casos onde a pessoa tem sua capacidade didática diminuída. A didática está ligada diretamente à comunicação. Se bem trabalhada gera ganhos enormes, como a diminuição do retrabalho. A didática não envolve apenas o uso da fala. Também envolve o uso de recursos de apoio, como slides, guras, grá cos, etc. Pessoas com alguma de ciência em expressar seus conhecimentos através da fala devem utilizar recursos de apoio para facilitar a transmissão de conhecimento. 11.3.6. Objetividade Objetividade é uma característica bastante importante, pois envolve diretamente a compreensão das pessoas e também o tempo de resposta às ações dos membros de uma equipe de Gestão de Dados. Quanto mais objetiva e direta, mais clara e rápida é a resposta ou a resolução de um problema. Objetividade consiste em fazer algo ou expressar de maneira simples, sem metáforas, ambiguidades, ideias implícitas ou ações desnecessárias durante o

processo de execução. Em algumas situações, a falta de objetividade do pro ssional interfere no andamento das atividades dos gestores de dados. Pessoas assim costumam ser mais subjetivas (não transparentes) em suas ações, ocasionando por vezes con itos com os demais pro ssionais envolvidos. Pro ssionais com pouca experiência às vezes também têm di culdades para serem objetivos, principalmente quando precisam passar mensagens de algo que não está conforme. Demoram muito mais para explicar o cenário em volta do problema do que passar o próprio problema, as causas, consequências e também as formas de correção. 11.3.7. Proatividade A proatividade é uma característica que está ligada diretamente à antecipação de escolhas e ações frente às situações previstas. O pre xo “pro” signi ca antecipação, algo que acontece antes. Proatividade também pode ser de nida como um conjunto de comportamentos “extra papel”, em que a pessoa busca espontaneamente por mudanças no seu ambiente de trabalho, solucionando e antecipando-se aos problemas, visando metas de longo prazo que bene ciam a organização. Entre as principais características da proatividade podemos destacar: Busca ativa por oportunidades de mudanças. Planejamento e execução de ideias. Enfrentamento de obstáculos. Pessoas proativas estão sempre se antecipando aos acontecimentos, fazendo até mesmo alguma espécie de previsão para poderem atuar através de determinadas formas planejadas.

11.3.8. Racionalidade Racionalidade é tomar suas atitudes através de pensamentos baseados na razão. Razão é a capacidade da mente humana que permite chegar a conclusões a partir de suposições ou premissas. A razão permite identi car e operar conceitos em abstração, resolver problemas, encontrar coerência ou contradição entre eles e, assim, descartar ou formar novos conceitos, de uma forma ordenada e orientada para objetivos. Inclui raciocinar, apreender, compreender, ponderar e julgar. Por vezes, razão é usada como sinônimo de inteligência. A razão é uma característica extremamente oposta à cultura do “fazer sem pensar” que muitas vezes, infelizmente, é adotada por algumas equipes. A Gestão de Dados Moderna entende que o Gestor de Dados deve ser uma pessoa extremamente racional, não movida a pressões externas ou outros tipos de emoções que podem in uenciar negativamente as ações e decisões. A razão é uma importante característica pessoal que possibilita a construção de soluções simples e duradouras.

11.4. Pilares das organizações Os pilares das organizações representam os ativos mais importantes das empresas sob a ótica da Gestão de Dados Moderna: dados e metadados, pessoas e recursos materiais. Este conceito difere da Gestão de Dados tradicional, onde somente os dados constituem o ativo mais importante das organizações. 11.4.1. Dados e metadados Dados e metadados de qualidade são fundamentais para tomar decisões ágeis, precisas e corretas de forma rápida e com baixos custos, trazendo

vantagens competitivas para a empresa em relação aos seus concorrentes. Os dados e metadados também são fundamentais para estruturar empresas para novas fusões e aquisições, além de atender aos requisitos regulamentares que porventura uma empresa pode ser submetida, tais como adequações a Basileia, lei Sarbanes-Oxley, instruções normativas, leis sobre privacidade de informações, etc. Pensar que somente os dados constituem o ativo mais importante das organizações e que empresas existem somente para “gerir dados” é uma loso a ultrapassada. Um dos erros da antiga Administração de Dados foi pensar justamente que somente os dados eram os ativos mais importantes das empresas. Não levaram em conta os demais ativos que são tão importantes quanto. 11.4.2. Pessoas Pessoas são o ativo que fazem as coisas acontecerem dentro das empresas. Sem elas nada é pensado, nada é feito, nada é criado. Portanto, não existe empresa de sucesso sem uma gestão de pessoas e caz. Pessoas devem ser respeitadas, reconhecidas e motivadas tanto dentro das equipes de Gestão de Dados quanto fora. Conforme dito anteriormente, as pessoas são responsáveis por todos os trabalhos dentro de qualquer empresa, sejam eles os mais simples, operacionais, táticos ou estratégicos. Além disso, elas geram e mantêm a cultura da empresa. Portanto, quanto mais se sentirem valorizadas e entenderem as regras e os objetivos da empresa, melhor será o desempenho e a abertura para a quebra de paradigmas. 11.4.3. Recursos financeiros

Recursos nanceiros são utilizados para estabelecer limites, regras e prioridades sobre operações e investimentos das empresas. Empresas existem para algum propósito – na maioria das vezes, ligado a retornos nanceiros ou prestação de serviços à sociedade. Questões como retorno sobre o investimento das iniciativas, custos das operações, margens de lucro e caixa disponível in uenciam diretamente a utilização da Gestão de Dados nas empresas. Empresas similares com culturas e expectativas diferentes em relação ao ativo “recursos nanceiros” possuem equipes de Gestão de Dados totalmente diferentes em propósitos, porte, forma de atuação e maturidade. As equipes de Gestão de Dados devem estar conscientes de que elas existem para apoiar a empresa na obtenção de seus propósitos. Para tal, recursos nanceiros para fomentar os projetos de investimentos e pessoas são fundamentais. Contudo, algumas equipes de Gestão de Dados ainda confundem os seus próprios objetivos com os objetivos estratégicos da empresa para a qual a área presta apoio.

12. Boas Práticas da Gestão de Dados Moderna “O riso é a mecânica aplicada no ser vivo.” Henri Bergson

12.1. As quatorze boas práticas de Gestão de Dados Moderna Para que a Gestão de Dados Moderna consiga atingir seus objetivos, tornase necessária a adoção de um conjunto mínimo de boas práticas que norteiam a loso a da Gestão de Dados Moderna. As práticas são genéricas e estão ligadas a características pessoais, mencionadas no framework da Gestão de Dados Moderna, e a estilos de gerenciamento. Vale ressaltar que boa parte do conjunto de boas práticas também pode ser adotada em outras disciplinas. Quando comecei a escrever artigos sobre as boas práticas da Gestão de Dados Moderna, elas eram inicialmente dez. Agora, na terceira versão do framework da Gestão de Dados Moderna, já são quatorze. A gura a seguir, em formato de mapa mental, relaciona as quatorze boas práticas da Gestão de Dados Moderna. Cada prática será detalhada mais

adiante.

Figura 12.1 – Boas práticas da Gestão de Dados Moderna

Vale a pena destacar que as práticas devem ser adotadas em sua totalidade. O simples esquecimento de uma ou mais práticas pode comprometer a e cácia da Gestão de Dados Moderna. Além disso, é importante frisar que não existe uma ordem prede nida de aplicação das práticas, ou seja, podem ser aplicadas simultaneamente ou não.

12.2. Manter um time de destaque O sucesso ou fracasso de um time está diretamente ligado ao comprometimento, à competência e à experiência dos membros da equipe. Pro ssionais de destaque rendem três ou quatro vezes mais que pro ssionais medianos. Além disso, pro ssionais de destaque não expõem a credibilidade da equipe, pois estão comprometidos com os objetivos da área, já passaram por diversas situações críticas anteriores e estão tecnicamente capacitados para utilizar e orientar seus clientes nas melhores práticas da Gestão de Dados. Infelizmente algumas empresas não enxergam isso e ainda preferem

montar equipes com a base de sua pirâmide formada por pro ssionais com baixa quali cação e experiência. Esta abordagem funcionava muito bem no passado, onde se tinha a oportunidade de formar pro ssionais durante o andamento dos projetos, pois estes eram longos, seguiam o modelo cascata e o escopo da atuação da área de Gestão de Dados não era tão abrangente. Além disso, a interação entre as pessoas não era muito grande. Vale ressaltar que não sou contra a contratação de pro ssionais juniores, porém este tipo de per l não pode ser utilizado como base da pirâmide de uma equipe de Gestão de Dados. Mesmo assim, devemos ter em mente que uma simples passagem de informação equivocada, ou falta de rmeza no parecer de questões mais críticas, põe em dúvida a capacidade do pro ssional e também da área de Gestão de Dados junto aos seus stakeholders. De forma geral, as consequências desta prática são: aumento desnecessário de recursos na equipe, baixa produtividade, comunicação falha, baixo nivelamento de recursos e descrédito da equipe. A continuidade desta prática nos dias atuais é muito perigosa, pois os pro ssionais de Gestão de Dados interagem com várias pessoas e seus papéis não estão mais limitados às funções de DBA ou Administrador de Dados. Novos papéis, como Gestor de Dados de Negócio e Gestor Estratégico de Dados, começam a surgir nas organizações mais maduras. Independentemente dos papéis, a prática de ter equipes pouco quali cadas deve ser abolida, sob pena dos pro ssionais da área de Gestão de Dados terem suas capacidades técnicas e comportamentais questionadas.

Mas, a nal, o que é um pro ssional de Gestão de Dados de destaque? Conforme gura a seguir, um Gestor de Dados de destaque deve possuir habilidades que podem ser divididas em quatro grupos principais:

Figura 12.2 – Habilidades necessárias para um Gestor de Dados

Conhecimento do Negócio: ao conhecer em profundidade as áreas de negócio, o pro ssional de Gestão de Dados é capaz de identi car rapidamente as necessidades dos clientes, mesmo quando elas não são claramente articuladas. Além disso, o pro ssional de Gestão de Dados deve ser capaz de propor soluções que podem não ter ocorrido aos clientes e avaliar imediatamente os impactos daquilo que está sendo pedido em outros processos de negócio da organização. Habilidades Comportamentais: muitas dessas habilidades são utilizadas nos conceitos da Gestão de Dados Moderna. De forma geral, o pro ssional de Gestão de Dados precisa ser capaz de se relacionar bem com pessoas de diferentes formações, estilos e mentalidades, especialmente na medida em que é sua função estar envolvido em “fazer a ligação” entre as áreas de negócio e TI. Ou seja, precisa lidar com pessoas de estilos muito diferentes. Precisa saber ouvir, ser capaz de compreender a comunicação não verbal, distinguir necessidades de

desejos, negociar e assumir compromissos. Além disso, precisa ter pensamento sistêmico, de modo a prever as interações entre o que está sendo proposto e as demais necessidades da organização. Habilidades Técnicas: são habilidades ligadas ao conhecimento das tecnologias utilizadas nas atividades de Gestão de Dados, tais como: Modelagem de Dados, operações em banco de dados, análise e projeto de sistemas, lógica, tecnologia para integração de informações e utilização de ferramentas. Muitos pro ssionais tendem a focar somente neste tipo de habilidade e esquecem as demais. Para trabalhar com Gestão de Dados não basta apenas ser um bom técnico. Habilidades em Gestão de Dados: são habilidades ligadas ao conhecimento das funções de gerenciamento de dados. O gerenciamento destas funções é apoiado pelo DAMA-DMBOK®, framework coordenado de funções para o gerenciamento de dados, metadados e ativos de informação nas organizações. Algumas habilidades técnicas e as habilidades em Gestão de Dados podem ser mensuradas por certi cações internacionais. As certi cações sérias são um bom instrumento para avaliar os conhecimentos técnicos e as habilidades dos pro ssionais. Vale ressaltar que, apesar de ajudar, a certi cação por si só não assegura que o pro ssional possua o melhor per l para trabalhar em uma empresa. O conhecimento do negócio e as habilidades comportamentais também são fundamentais para formar um pro ssional de destaque. Montar um time de destaque não é uma tarefa fácil. É comum encontrar colegas que passam por di culdades na hora de contratar pessoas. O mercado de Gestão de Dados está ressurgindo de forma acelerada, porém a quantidade de pro ssionais quali cados não está acompanhando este crescimento. Portanto, depois de montado, não devemos medir esforços

para manter a harmonia e a evolução do time. A nal, relembrando as premissas da Gestão de Dados Moderna, as pessoas também são ativos importantes das organizações.

12.3. Atuar no início dos projetos Atuar no início dos projetos signi ca atuar de forma proativa, com o propósito de identi car e/ou mitigar os principais riscos e também eliminar as principais anomalias dos projetos. O grau de incerteza dos projetos nas fases iniciais é muito maior do que nas fases mais próximas do seu encerramento. Logo, quando o assunto é riscos, sabemos que quanto maiores forem os níveis de incerteza, maiores serão os riscos e suas probabilidades. Se a área de Gestão de Dados tiver uma atuação mais intensa nesta fase, antevendo problemas referentes ao uso dos dados e informações, certamente ajudará a reduzir a incidência de anomalias e a diminuir o custo do retrabalho. Vale ressaltar que a prática de atuar no início dos projetos não se resume apenas à atuação de Administradores de Dados ou Gestores Técnicos de Dados nas orientações sobre Modelagem de Dados e/ou avaliações de modelos de dados. A abrangência desta prática é bem mais ampla e pode ser aplicada em todas as funções previstas no guia DAMA-DMBOK®. Podemos citar como exemplos: Gerenciamento da Arquitetura de Dados: de nições preliminares da arquitetura empresarial e também da Arquitetura de Dados corporativa. Desenvolvimento de Dados: orientações e avaliações preliminares nos modelos de dados produzidos pelas equipes de desenvolvimento/projeto.

Gerência de Operações e Banco de Dados: de nição de rotinas mais proativas das operações de infraestrutura e administração de banco de dados. Gerenciamento de Dados Mestres e Dados de Referência: apoio na identi cação, reutilização e governança dos dados mestres e de referência das organizações. Gerenciamento da Qualidade de Dados: a Gestão de Dados Moderna prega que a qualidade não é controlada, e sim planejada. Além disso, Qualidade de Dados não é um projeto, mas um programa. A conscientização das pessoas é fundamental para o sucesso. Portanto, a participação da área de Gestão de Dados no planejamento da qualidade dos dados é fundamental. Um bom planejamento interfere diretamente na qualidade dos dados criados na organização, reduzindo a incidência de futuras limpezas e correções. A área de Gestão de Dados deve atuar em todas as fases do ciclo de vida de desenvolvimento de soware e também do ciclo de vida dos dados. Vale ressaltar que quanto maior o esforço nas fases iniciais destes ciclos, menor o esforço nas fases nais e de controle.

12.4. Ser ágil nos atendimentos Um dos principais fatores de resistência à implantação de áreas de Gestão de Dados nas empresas é o fator tempo. Partes envolvidas diretamente no processo, como as equipes de desenvolvimento/projetos, costumam alegar que os projetos podem atrasar devido ao tempo gasto nas atividades executadas pela equipe de Gestão de Dados, sem levar em conta a qualidade agregada ao produto nal que essas atividades podem gerar. Além disso, várias empresas estão adotando métodos de desenvolvimento ágil na construção de soware, como Scrum e Kanban, o que aumenta ainda

mais a necessidade de agilidade nos atendimentos, sob pena da equipe de Gestão de Dados não suportar o ritmo demandado das partes interessadas e não conseguir demonstrar o seu real valor. De nir um Acordo de Nível de Serviço, também conhecido como SLA (Service Level Agreement), curto e objetivo que abranja todas as atividades executadas pela área é fundamental para que a Gestão de Dados não seja encarada como algo extremamente burocrático e ine caz, ou seja, uma área que está dentro dos processos apenas para atrapalhar, sem agregar nenhum valor. Quanto menor o tempo de atendimento da tarefa, menor será a resistência, porém é importante destacar que o SLA deve ser cumprido, acompanhado e seus resultados divulgados periodicamente a todos os envolvidos. De nada adianta uma empresa utilizar um SLA muito curto se ela não tem capacidade de atender à maioria dos prazos estipulados. Mas como de nir as atividades e os tempos médios para o SLA? Não existe uma receita de bolo especí ca para estabelecer um SLA. A quantidade de pessoas, a experiência da equipe, a capacitação técnica dos envolvidos, o ferramental utilizado, as características do negócio e os aspectos culturais in uenciam diretamente no tempo médio de atendimento de cada atividade. Um SLA adotado em uma empresa nem sempre será o SLA ideal de outra empresa. Mesmo assim, algumas boas práticas podem ser utilizadas na de nição deste SLA: O SLA deve ser divulgado para todos os envolvidos. Divulgar o SLA apenas para a equipe de Gestão de Dados não faz nenhum sentido. O SLA deve ser aplicado dentro do horário de trabalho padrão da empresa. Exemplo: das 08:00h às 17:00h. Os tempos de atendimento devem ser dados em horas úteis.

As tarefas mais usuais devem ser classi cadas por tamanho/complexidade. Exemplo: quantidade de entidades/tabelas, modelo novo x alteração pontual em modelo, etc. As classi cações dos tempos de atendimento devem ser simples e facilmente compreendidas por todos. Fórmulas matemáticas que envolvem a contagem de vários tipos de objetos (entidades, atributos, relacionamentos, domínios, etc.) são mais precisas quando o produto está no m e o solicitante sabe exatamente o que ele quer (o que é raro), porém são extremamente complicadas para quem está solicitando o serviço. Durante o planejamento prazos calculados desta forma são inviáveis e até mesmo imprecisos. Para tarefas de difícil estimativa genérica, deve-se estabelecer um prazo para dar a estimativa nal. Exemplo: prazo de x dias para efetuar tuning em base de dados. O SLA deve possuir uma meta de cumprimento e também uma meta desa adora. Exemplo: meta de atendimento de 90% das solicitações dentro do prazo e meta desa adora de 95%. Os valores cumpridos também devem ser divulgados. A nal, se o SLA é curto e a equipe de Gestão de Dados atende à meta de atendimento estabelecida, não há razão para gargalos. A tabela a seguir mostra um exemplo de SLA que pode ser adotado como exemplo em uma equipe de Gestão de Dados. Atividade

Homologar novo modelo de dados Homologar alterações em modelos de

Grandeza

Tempo Esforço (em (em horas) horas)

Pequeno

8h

16h

Médio

12h

20h

Grande

16h

36h

Pequeno

4h

8h

dados

Médio

8h

16h

Grande

12h

20h

NA

4h

8h

Sem manipulação dos 4h dados

8h

Com manipulação dos 12h dados

16h

NA

2h

4h

Efetuar complete x compare entre modelo NA e ambientes de SGBD

2h

4h

Efetuar engenharia reversa

NA

2h

4h

Orçar estimativa de tuning

NA

8h

16h

Efetuar consultoria em Modelagem de Dados

NA

2h

16h

Identi car gestor de informação

NA

8h

24h

Realizar análise de impacto de conceitos

NA

4h

12h

Homologar termo corporativo

NA

8h

16h

Orçar estimativa de consultoria em Qualidade de Dados

NA

8h

24h

Corrigir dado mestre

NA

2h

16h

Carregar metadados no repositório

NA

2h

8h

Homologar alteração em arquitetura corporativa

NA

8h

24h

Implementar novo modelo de dados em SGBD (por ambiente)

Implementar alterações em modelos de dados no SGBD (por ambiente)

Disponibilizar modelos de dados

Tabela 12.1 – Exemplo de SLA ágil

12.5. Utilizar princípios e ferramentas da qualidade Muitas organizações que possuem equipe de Gestão de Dados constituída focam grande parte de seus esforços nas atividades de homologação de

modelos de dados. Porém, com o passar do tempo, a equipe começa a perceber que os esforços não são su cientes para obter uma melhora signi cativa nos modelos submetidos à avaliação e nos dados que são manipulados pela organização. Em alguns casos há a impressão de que a qualidade piorou. Mesmo com o trabalho de controle dos modelos de dados produzidos, por que a qualidade dos dados e das estruturas dos dados não evoluiu? As razões podem mudar de acordo com o cenário de cada empresa, mas vou listar a seguir os seis equívocos mais comuns cometidos pelas organizações: Acreditar que a atividade de avaliação de modelos de dados é su ciente para atingir um bom nível de qualidade, concentrando a maioria dos esforços da equipe neste tipo de atividade. Não compreender que a qualidade é compartilhada por todos, desde o analista que projeta o modelo de dados até as pessoas que fornecem as informações a serem incluídas nos bancos de dados. Não investir na conscientização da importância do “fazer correto” e “fazer de uma única vez” para todas as pessoas envolvidas nos processos, deixando de mostrar a importância dos dados íntegros e precisos para a organização. Dar um peso menor na qualidade em relação a outros critérios dos projetos, como, por exemplo, tempo e custo. Não utilizar o ciclo PDCA nos processos de Gestão de Dados. Não possuir uma base de registros históricos, contendo dados fundamentais sobre o andamento dos processos, qualidade das estruturas de dados, volumes de correções, etc. Os equívocos abordados anteriormente são comuns em áreas que não adotam a loso a da Gestão de Dados Moderna.

A Gestão de Dados Moderna sugere que os princípios e as ferramentas da qualidade são importantes instrumentos para elevar o grau de qualidade dos dados e metadados da empresa, além de elevar o nível de maturidade em Gestão de Dados por toda a empresa. Entre os principais princípios podemos destacar: O foco da qualidade é o cliente: no caso da Gestão de Dados, são todas as pessoas que criam, manipulam, utilizam ou são de alguma forma afetadas pelo conteúdo dos dados. A qualidade é planejada e não inspecionada: o foco da qualidade deve ser na prevenção e não na inspeção (controle). A inspeção deve ser utilizada para provar que o processo funciona (porque as boas práticas de qualidade vêm sendo utilizadas) e não simplesmente como um modo de rejeitar as falhas nos dados e metadados. Envolvimento das pessoas: quando as pessoas são envolvidas nos processos, elas compreendem sua importância e seu papel na empresa, aceitando que são responsáveis pelos problemas e pelas soluções. Elas são motivadas a identi car os obstáculos e a avaliá-los, a aperfeiçoar seu conhecimento e experiência e a compartilhá-los, discutindo os problemas abertamente. Melhoria contínua: é não se contentar e se acomodar com os níveis alcançados em processos otimizados. Conforme estabelecido nas normas da família ISO 9000, o objetivo da melhoria contínua da qualidade é aumentar a probabilidade de melhorar a satisfação dos clientes e das demais partes interessadas. 12.5.1. Ciclo PDCA aplicado na Gestão de Dados Moderna O PDCA é um ciclo de desenvolvimento que tem foco na melhoria contínua. Ele é aplicado para atingir resultados dentro dos processos e pode

ser utilizado em qualquer organização, independentemente da área de atuação. No caso especí co da Gestão de Dados, ele pode ser aplicado praticamente em todos os processos. Conforme gura a seguir, o ciclo começa pelo planejamento (P – Plan). Em seguida as ações planejadas são executadas (D – Do), checa-se se o que foi feito estava de acordo com o planejado, constantemente e repetidamente (C – Check), e toma-se uma ação para eliminar ou ao menos mitigar os problemas encontrados nos produtos ou na execução do processo (A – Act).

Figura 12.3 – Ciclo PDCA

Se aplicarmos o PDCA nos processos de construção e avaliação de modelos de dados, teremos o seguinte cenário. P (Plan): identi cação das entidades corporativas, mapeadas na Arquitetura de Dados da organização, e das demais necessidades de informação que serão contempladas na modelagem. Durante esta identi cação é obrigatória a participação de pessoas com visão corporativa dos dados da organização. Geralmente este papel é feito pelo Gestor Estratégico de Dados. D (Do): construção do modelo de dados com apoio da equipe de Gestão de Dados. O analista responsável pelo projeto constrói e altera o

modelo de acordo com as diretrizes passadas pelos gestores de dados em reuniões prévias. C (Check): avaliação do modelo de dados construído e registro dos dados da avaliação. O gestor de dados avalia o modelo de dados de acordo com os critérios prede nidos em sua metodologia e registra os dados da avaliação. A (Act): tomada de ações corretivas no produto ou no processo. Se o modelo for reprovado, o analista corrige os erros apontados no laudo de avaliação (ação para correção do produto). Com o apoio das ferramentas de qualidade, o gestor estratégico de dados sugere ações após análise dos registros das avaliações efetuadas em um determinado período (ação para os novos produtos e também melhoria do processo). Este exemplo deixa claro que a qualidade não é “controlada”, e sim “planejada”. Equipes que trabalham de forma mais reativa costumam dar ênfase somente nas fases de controle, esquecendo que a qualidade é obtida através de um ciclo completo de melhoria contínua. Vale ressaltar que o PDCA também pode ser aplicado em outros processos, como os de Data Quality. Infelizmente ainda é muito comum encontrar organizações que investem em programas de Data Quality voltados somente para atividades operacionais de correção dos dados, ignorando trabalhos mais simples e com maior retorno de resultado, como a conscientização dos envolvidos na criação e manipulação dos dados. 12.5.2. Diagrama de Pareto O diagrama de Pareto é um grá co de barras que ordena as frequências das ocorrências, da maior para a menor, permitindo a priorização dos problemas, procurando levar a cabo o princípio de Pareto (regra dos 80 –

20). Este princípio estabelece que 80% das consequências ou ocorrências totais advêm de 20% das causas. Sua maior utilidade é permitir uma fácil visualização e identi cação das causas ou problemas mais importantes, possibilitando a concentração de esforços sobre eles. Se tomarmos como exemplo os processos de construção e avaliação de modelos de dados e zermos um grá co agrupando os erros encontrados nas avaliações desses modelos agrupados por tipos de erros, teremos algo semelhante ao grá co a seguir.

Figura 12.4 – Exemplo de utilização de um diagrama de Pareto

Olhando a gura anterior, rapidamente chegamos à conclusão de que as maiores incidências de erros são encontradas nos critérios “Integridade” e “Integração”. De posse desta informação, cabe ao gestor estratégico de dados tomar ações que diminuam a incidência de erros nesses dois critérios. 12.5.3. Diagrama de causa e efeito O Diagrama de Ishikawa, também conhecido como diagrama “causa e efeito” ou “espinha de peixe”, é uma ferramenta grá ca utilizada para

estruturar hierarquicamente as causas potenciais de determinado problema, bem como seus efeitos sobre a qualidade dos produtos (no caso, os dados e/ou as estruturas de dados). A análise do diagrama é feita a partir de uma lista de nida de possíveis causas. As mais prováveis são identi cadas e selecionadas para uma melhor análise. Ao examinar cada causa, o usuário deve observar fatos que mudaram, como, por exemplo, desvios de norma ou de padrões. Deve-se lembrar também que o objetivo deste trabalho é mapear formas de eliminar as causas e não apenas mapear os sintomas dos problemas. A gura a seguir mostra um exemplo de aplicação do diagrama de causa e efeito. O problema ilustrado continua sendo a qualidade dos modelos de dados que são submetidos a avaliações pela equipe de Gestão de Dados.

Figura 12.5-Exemplo de um diagrama de causa e efeito

Segundo a gura anterior, a empresa mapeou seis grupos de causas principais: capacitação, metodologia, ferramentas, comunicação, cultura e projetos. A gura exempli cou o detalhamento dos dois primeiros grupos.

No grupo referente à capacitação, as causas identi cadas sugerem ações para promover treinamentos em Modelagem de Dados e levantamento de requisitos para os pro ssionais da empresa, divulgação dos padrões existentes (muito provavelmente através de ações junto ao grupo comunicação) e de nição dos melhores per s para trabalharem na produção dos modelos de dados. Este último tem uma relação muito forte com o grupo metodologia. Por m, o grupo metodologia nos mostrou causas que sugerem ações no sentido de revisar os padrões existentes e produzir roteiros ou guias de boas práticas para melhorar o embasamento técnico dos pro ssionais que produzem esses modelos. 12.5.4. Gráficos de controle Esses grá cos são importantes ferramentas de qualidade utilizadas no controle estatístico do processo. São utilizados para registrar as medidas das amostras em intervalos regulares. Os grá cos de controle tornam perceptíveis as variações anormais das medidas dentro de um processo e acompanham tendências e comportamentos. Sua simplicidade permite que, com uma rápida consulta, seja fácil perceber quando um processo está fugindo do controle. Com isso, as áreas de Gestão de Dados ganham agilidade nas ações para identi cação e resolução dos problemas. Para que o processo seja considerado sob controle, os dados registrados devem se enquadrar dentro de uma curva normal. A gura a seguir demonstra um exemplo de grá co de controle.

Figura 12.6 – Exemplo de um grá co de controle

A média estabelecida é representada por uma linha sólida entre os limites superior e inferior. No caso da gura anterior, o valor é 0,4. Os níveis de desvio aceitáveis, também conhecidos como limites admissíveis, em relação ao valor médio são representados por linhas tracejadas. No caso da gura anterior, varia de 0 a 0,8. O uso dos limites admissíveis é recomendado, pois se espera que todo o processo possua alguma variação. Caso exista algum registro fora dos limites superior e inferior, considera-se o processo fora de controle. No caso da gura anterior, o processo saiu de controle em três medições consecutivas. O exemplo deixa claro que, após constatar que o processo saiu de controle, ações de melhoria foram tomadas com sucesso, pois logo após o processo retornou aos limites estabelecidos. Muito provavelmente as ações foram de nidas através das análises do diagrama de Pareto e do diagrama de causa e efeito. 12.5.5. Listas de verificações (checklists)

As listas de veri cações, também conhecidas como checklists, são a base para o desenvolvimento do trabalho e a garantia de que ele será realizado seguindo os passos certos. Elas podem ser utilizadas como um roteiro sequencial para construção de um trabalho ou então como um passo a passo para avaliar algo que foi produzido, como, por exemplo, modelos de dados, cargas de dados, manipulações de dados, concessão de acesso a dados, etc. É importante lembrar que, por mais experiente que seja o pro ssional, ele pode esquecer coisas importantes, pois sua memória é limitada. Desta forma, as listas de veri cações ajudam as pessoas a lembrar o que deve ser feito e garantir que foi feito conforme previsto. Quanto mais simples, mais e cazes são as listas.

12.6. Trabalhar com indicadores de gestão Indicadores são medidas, geralmente estatísticas, utilizadas para traduzir quantitativamente um conceito e fornecer informações sobre determinados aspectos objetivando a formulação, o monitoramento e a avaliação dos processos existentes ou então apenas para ns de pesquisa. O registro das atividades executadas pelas equipes de Gestão de Dados e o acompanhamento através de seus indicadores são vitais para o monitoramento das atividades. Os indicadores devem ser adotados conforme as necessidades da empresa. Além disso, devem ser mensuráveis e obtidos de forma simples através dos registros das atividades. Em Gestão de Dados os indicadores podem ser divididos em quatro grandes grupos: Indicadores de qualidade. Indicadores de reuso. Indicadores de tempo.

Indicadores de custo. Os indicadores de qualidade podem re etir os valores ou índices de qualidade dos dados, metadados e também do processo. Entre os indicadores de qualidade mais usuais podemos destacar: Qualidade dos dados: Índices de correções (através de chamados). Erros em transformações de dados. Erros em validações automáticas (na entrada de dados). Erros encontrados a partir da aplicação de regras. Qualidade dos metadados: Erros encontrados nas avaliações de modelos de dados (por tipo de erro, por equipe, etc.). Índices de erros nas avaliações. Índices de retrabalho. Índices de consultorias prévias em modelagem. Qualidade do processo: Solicitações incorretas. Solicitações incompletas. Pesquisa de satisfação – Atendimento da equipe. A gura a seguir demonstra um exemplo de indicador de qualidade dos metadados.

Figura 12.7 – Exemplo de indicador aplicado em avaliações de modelos de dados

No exemplo anterior, podemos observar um indicador que representa a ocorrência de erros por tipo nas avaliações de modelos de dados. O grá co demonstra valores acumulados no ano. Este indicador é útil para entender como anda a qualidade das construções e alterações dos modelos de dados e, a partir daí, buscar soluções que levem a diminuir a incidência de erros encontrados. Os indicadores de reuso nos fornecem uma visão do quanto os dados são reaproveitados na empresa. A reutilização dos dados pode ser transformada em valor monetário, pois uma entidade de dados reutilizada representa economia no tempo e no custo do desenvolvimento de aplicações, além de diminuir o custo de armazenamento dos dados e o número de ativos de TI. Entre os indicadores de reuso mais comuns podemos destacar: Entidades de negócio compartilhadas. Entidades de negócio não compartilhadas. Técnicas de integração de dados utilizadas. As tabelas a seguir demonstram exemplos de indicadores de reuso:

Entidade

Quantidade de aplicações compartilhadas

Quantidade de aplicações da empresa

Percentual de reuso

LOCALIDADE

80

120

66%

UNIDADE_FEDERATIVA 87

120

73%

FUNCIONARIO

78

120

65%

DEPARTAMENTO

70

120

58%

CLIENTE

30

120

25%

FORNECEDOR

20

120

17%

PRODUTO

18

120

15%

Tabela 12.2 – Exemplo de indicador de reuso – Entidades Técnica de integração utilizada

Quantidade de aplicações que utilizam esta técnica

Quantidade de aplicações da empresa

Percentual de uso da técnica de integração

ETL (Replicação controlada)

34

120

28%

Oracle Golden Gate

30

120

25%

Database Link

6

120

5%

Web services

83

120

69%

Acesso direto (sinônimos)

36

120

30%

Outros

4

120

3%

Tabela 12. 3 – Exemplo de indicador de reuso – Forma de disponibilização dos dados

Os indicadores de tempo nos fornecem uma visão do tempo de atendimento das atividades das equipes de Gestão de Dados e comparam se os tempos atuais estão dentro do SLA previsto para cada atividade. Entre os indicadores de tempo mais comuns podemos destacar: Percentual de tarefas (ou tipos de tarefas) atendidas dentro do tempo do SLA.

Tempo médio de atendimento por tarefa (ou tipo de tarefa). Os indicadores de custo nos fornecem uma visão do quanto é gasto nos atendimentos das atividades das equipes de Gestão de Dados e comparam se o custo de cada atendimento está aderente ao custo (esforço) do SLA previsto para cada atividade. Entre os indicadores de tempo mais comuns podemos destacar: Percentual de tarefas (ou tipo de tarefas) atendidas dentro do custo do SLA. Custo de tarefas de retrabalho. HH1 lançado em projetos. Custo médio por tarefa (ou tipo de tarefas). Tanto os indicadores de tempo como os indicadores de custo são importantes instrumentos para acompanhar o andamento das equipes de Gestão de Dados. O tempo costuma ser um importante fator de resistência à adoção da Gestão de Dados nas empresas. Entretanto, se existe um SLA de nido por tipo de atividade e as tarefas vêm sendo atendidas dentro do prazo estabelecido, não haverá motivos para fomentar esta resistência. Já o custo pode gerar uma falsa impressão de que a atuação das equipes de Gestão de Dados gera despesa excessiva para a empresa. Porém, se a empresa possui parâmetros de custos de nidos para cada tipo de atividade e as tarefas atendidas pelas equipes de Gestão de Dados são cobradas dos projetos solicitantes, não haverá motivos para encarar as equipes de Gestão de Dados como overheads corporativos, pois a maioria dos custos das equipes será distribuída nos projetos onde as equipes interagiram. A próxima boa prática detalhará mais esta questão.

12.7. Repassar os custos aos clientes

Áreas consideradas de apoio ou ligadas à qualidade possuem centros de custos próprios. Todas as despesas são contabilizadas nesses centros de custos, sem repassar um centavo qualquer aos demais centros de custo das áreas para as quais a equipe de Gestão de Dados prestou algum tipo de trabalho. Esta regra é aplicada principalmente no custo da mão de obra dos pro ssionais das equipes e nas licenças dos sowares utilizados pelos membros das equipes de Gestão de Dados. Esta prática acaba por tornar a área um overhead corporativo muito caro, pois, dependendo das especializações, do grau de detalhamento das atividades e da grandeza das equipes, o custo pode assumir valores muito altos. Como o retorno das iniciativas de Gestão de Dados ainda é muito intangível, fatalmente a existência das equipes será questionada. Empresas não existem somente para gerir os seus dados. Gerir dados é uma forma de melhorar a con abilidade e a qualidade dos dados para que as empresas tenham subsídios na hora de tomar decisões. Esses dados não são exibidos de forma bruta, ou seja, os dados são visualizados e trabalhados a partir de aplicações e ferramentas especí cas (sowares ou sistemas) para cada área, e não diretamente nos bancos de dados onde estão armazenados. Portanto, todo o custo referente aos trabalhos operacionais da Gestão de Dados (necessários para manter esses dados com qualidade) deve ser repassado às áreas de negócio proprietárias dessas aplicações. A distribuição desses custos permitirá uma visão mais real sobre os gastos de cada área especí ca. Para os projetos de dados corporativos, onde um mesmo dado é utilizado por mais de uma área, recomenda-se o rateio dos custos pelas áreas que utilizam esses dados. Com o repasse dos custos “operacionais”, as equipes de Gestão de Dados cariam responsáveis pelos custos referentes às iniciativas de melhoria e investimento da área de Gestão de Dados. Apesar das melhorias re etirem

em um futuro próximo no trabalho operacional que é executado, o repasse desses custos, em um primeiro momento, é muito mais difícil, pois geralmente essas iniciativas vêm das equipes de Gestão de Dados e não das demais áreas.

12.8. Nunca acomodar Um dos principais erros cometidos é parar de buscar a evolução contínua da adoção da Gestão de Dados na empresa quando a curva de benefícios alcançados ultrapassa a curva de resistências. A gura a seguir mostra um grá co que acompanha o processo de implantação e evolução da adoção da Gestão de Dados em uma empresa.

Figura 12.8 – Exemplo de zona de acomodação na implantação da Gestão de Dados

Podemos observar que a Gestão de Dados foi considerada implantada quando a diferença de graus entre as curvas diminuiu. O grau dos benefícios se igualou ao grau de resistência. A partir deste ponto, a diferença entre as curvas volta a aumentar, porém o grau de benefícios é bem maior que o grau da resistência, tornando a Gestão de Dados muito mais madura na empresa.

A prática “não acomodar” indica justamente o que foi representado no grá co anterior: o aumento dos benefícios da Gestão de Dados e a diminuição das resistências através do conceito da busca pela melhoria contínua. Entre as ações mais comuns desta boa prática podemos citar: Análise e avaliação da situação existente para identi car áreas para melhoria. Estabelecimento dos objetivos para melhoria. Pesquisa de possíveis soluções para atingir os objetivos. Avaliação e seleção dessas soluções. Implementação da solução escolhida. Medição, veri cação, análise e avaliação dos resultados implementação para determinar se os objetivos foram atendidos.

da

Apesar de o grá co mostrar uma constatação simples, várias empresas optam por não evoluir mais a maturidade da Gestão de Dados assim que a área é considerada implantada, permanecendo na “zona de acomodação” por bastante tempo – até ter a sua existência questionada.

12.9. Utilizar metodologia adequada O termo “metodologia” não tem uma de nição bem estabelecida, mas ca claro o seu objetivo: dar instrumentos para obtenção de métodos e metas. Adotaremos a seguinte de nição para uma Metodologia de Gestão de Dados neste livro: conjunto de documentos que orientam os pro ssionais envolvidos com as funções e atividades preconizadas pela disciplina de Gestão de Dados nas organizações. Entre estes documentos encontramos: documentação institucional, processos e seus detalhamentos, padrões,

ferramentas de qualidade, documentação de apoio e ferramentas de comunicação.

Figura 12.9 – Componentes de uma Metodologia de Gestão de Dados

A gura anterior mostra uma visão mais abrangente dos documentos que podem ser utilizados em uma Metodologia de Gestão de Dados. 12.9.1. Diretrizes básicas para a construção de uma Metodologia de Gestão de Dados As dicas a seguir podem ser aplicadas em qualquer cenário. São consideradas por mim diretrizes básicas para a adoção de uma Metodologia de Gestão de Dados. São elas: A metodologia deve ser abrangente e com adaptações aos diversos tipos de sistemas da organização, ou seja, deverá prever o desenvolvimento de sistemas transacionais, sistemas de Business Intelligence e apoio à decisão, aquisição de dados externos, sistemas onde os dados não são armazenados em banco de dados, etc.

A metodologia deve ser regulamentadora – deve de nir o que precisa ser feito usando padrões e diretrizes. Os documentos da metodologia devem estar integrados entre si e aos demais processos de trabalho da organização. Os detalhamentos dos uxos de trabalho podem ser feitos através de procedimentos de trabalho. A metodologia deve ser orientadora – deve explicar como produzir mais e melhor, através de boas práticas, manuais e orientações em geral. O grau de rigidez e detalhamento da Metodologia de Gestão de Dados deve ser similar aos graus das outras metodologias adotadas na empresa. A metodologia deve ser conhecida por todos. De preferência, deverá ser mantida e divulgada através de um portal especí co e/ou soluções similares. Guias de corpo de conhecimento consagrados, como o DAMADMBOK® (representado na gura a seguir), são uma ótima referência para de nir e orientar o escopo e o conteúdo da metodologia. Vale ressaltar que os guias devem ser adotados e customizados de acordo com as características de cada empresa.

Figura 12.10 – Funções do DAMA-DMBOK®2

Mesmo adotando todas as dicas relacionadas, não saberemos se a Metodologia de Gestão de Dados estará adequada para a empresa ou se teremos problemas de percurso durante e após sua adoção. As dicas ajudam, porém não são su cientes para garantir o sucesso desta jornada. A compreensão das características particulares de cada empresa é considerada fundamental para o sucesso deste trabalho. Em resumo, o que é bom para uma empresa pode não ser bom para outra. Durante minha experiência pro ssional, tive a oportunidade de observar os cenários de várias empresas, de ambos os portes e de diversos segmentos. Em todas onde participei de alguma forma na de nição e/ou alteração da Metodologia de Gestão de Dados, pude constatar uma única resposta correta que pôde ser aplicada nos questionamentos mais genéricos, tais como: “que metodologia adotar?”, “como adotar?” e “quando adotar?”. A resposta correta, mas não tão esclarecedora para todos esses questionamentos, sempre foi uma só: “depende, cada caso é um caso”. Várias áreas de Gestão de Dados tiveram sua existência questionada simplesmente por adotar o modelo de metodologia igual ao de outras

empresas de sua área de atuação. Provavelmente essas empresas não levaram em consideração seus próprios cenários e expectativas e, consequentemente, escolheram uma alternativa de resposta incorreta. A nal, qual seria a metodologia adequada para a minha empresa? 12.9.2. Características consideradas na criação de uma Metodologia de Gestão de Dados Metodologia adequada não é aquela utilizada por empresa A ou B, muito menos um conjunto de processos empurrados “goela abaixo” por fornecedor X ou Y. Uma Metodologia de Gestão de Dados adequada leva sempre em conta a análise de cinco características particulares de cada empresa: aspectos organizacionais, cultura, corpo técnico, visão de futuro e recursos nanceiros. A gura a seguir mostra o encadeamento entre as

cinco características:

Figura 12.11 – Características que devem ser consideradas na elaboração de uma metodologia

Os aspectos organizacionais correspondem ao posicionamento e à forma de atuação da área de Gestão de Dados na organização. Para fazer uma análise deste aspecto, várias perguntas devem ser levadas em consideração: Qual é o segmento de atuação da organização? Qual é o seu porte? A organização é pública ou privada?

A área de Gestão de Dados existe (ou será prevista) no organograma da organização? Se sim, qual o posicionamento da área de Gestão de Dados no organograma? Quais seriam os seus clientes? Em que nível gerencial a Gestão de Dados está situada? A quem a área está subordinada? A maioria dos dados que trafegam na empresa é criada dentro da própria empresa ou é adquirida no mercado? As aplicações que criam e manipulam os dados que trafegam na empresa são desenvolvidas dentro ou fora da empresa? De forma geral, área de Gestão de Dados que não está ligada diretamente ao departamento de TI costuma ter mais autonomia para suas ações, porém ca distanciada de onde os dados são projetados (TI). Área de Gestão de Dados ligada diretamente ao departamento de TI costuma ter menos autonomia nas ações e sofre pressões elevadas para diminuir os parâmetros de qualidade, principalmente se estiver dentro do departamento de desenvolvimento – contudo, ca mais perto de onde os dados são projetados. A cultura é o conjunto de conhecimentos, crenças, padrões, costumes e todos os outros hábitos e aptidões adquiridos pelas pessoas dentro da organização. Trabalhar em empresas onde reina a cultura do valor para as soluções de nitivas com foco na qualidade é o sonho de qualquer pro ssional que trabalha com Gestão de Dados. Neste caso, o trabalho de criação e/ou alteração de uma metodologia é muito facilitado. O escopo do trabalho é muito abrangente e os primeiros resultados são obtidos com certa rapidez e facilidade.

Por outro lado, empresas que focam na entrega das soluções sem nenhum planejamento e qualidade costumam ser o pesadelo dos pro ssionais que trabalham na área de Gestão de Dados. Nessas situações, o trabalho de criação e/ou alteração de uma metodologia é bastante complexo, não pela abrangência do trabalho (que, neste caso, nunca deverá ser muito amplo), mas pelas di culdades culturais. O gestor estratégico de dados deve estar preparado para negociar muito, romper barreiras, quebrar paradigmas e, principalmente, deve estar ciente de que sempre receberá pressões de todos os lados, inclusive das pessoas que trabalham dentro da área de Gestão de Dados. Nesse tipo de situação, o escopo do trabalho é reduzido e os primeiros resultados são obtidos depois de muito tempo de atuação e com muitas di culdades. O corpo técnico corresponde aos membros que trabalham nas atividades onde a Gestão de Dados participa. Quanto maior o nível de quali cação das equipes, melhor a resposta na adoção da metodologia. Quanto maior a quantidade de pessoas dentro dos times, maior a necessidade de detalhamento da metodologia. O balanceamento das duas variáveis ajuda a de nir o nível de complexidade e o grau de detalhamento da metodologia. Conforme gura a seguir, entende-se como quali cação o conjunto da seguinte engrenagem: treinamento + experiência + aspectos comportamentais.

Figura 12.12 – Quali cação em Gestão de Dados – engrenagem ideal

A aplicação de treinamentos e workshops para o corpo técnico da empresa voltados aos conceitos, processos e procedimentos da metodologia costumam ser uma boa medida para melhorar o nível de quali cação das equipes. Este esforço geralmente é su ciente para dar um bom andamento na adoção de uma Metodologia de Gestão de Dados. Vale ressaltar que o corpo técnico da equipe de Gestão de Dados deverá estar quali cado antes do início do projeto de criação/alteração da metodologia. Entregar projetos na mão de equipes sem quali cação e vivência anterior em projetos do mesmo porte é um convite ao fracasso. A visão de futuro é, nada mais, nada menos, a resposta para a seguinte pergunta: como a área de Gestão de Dados deverá funcionar em ‘x’ anos? A visão de futuro abrange o curto, o médio e o longo prazos. A metodologia deve ser especi cada prevendo essas evoluções. A previsão sobre o uso de ferramentas no futuro também deve in uenciar na criação e/ou alteração da metodologia. Se uma empresa deseja implantar todas as funções previstas no guia DAMA-DMBOK®, mas em um primeiro momento não possui recursos nem tempo necessários, ela deve começar a de nir seus processos de trabalho de acordo com as funções consideradas prioritárias, porém sem esquecer que no futuro essas funções serão integradas às outras. Portanto, as especi cações desses processos devem ser exíveis o su ciente para uma integração no futuro. O mesmo vale para as ferramentas. É claro que elas não devem guiar os processos, porém suas características não devem ser ignoradas. Se, por exemplo, uma empresa pretende trabalhar no futuro com as funções de MDM e Data Quality, jamais deverá deixar de prever o uso dessas ferramentas nas especi cações dos primeiros processos da metodologia. A utilização de ferramentas de apoio é uma das quatorze boas práticas e será mais bem detalhada adiante, ainda neste capítulo.

Recursos nanceiros correspondem ao total de verbas disponíveis para o funcionamento da área de Gestão de Dados. Cabe ao responsável pela área de Gestão de Dados planejar as atividades de acordo com o orçamento disponível. O estudo do retorno sobre o investimento (ROI – Return of Investment) para o projeto de criação e/ou alteração de uma Metodologia de Gestão de Dados é fundamental para saber se o projeto é viável economicamente ou não. Se a área não possui verba su ciente para iniciar um novo projeto cujo retorno será dado somente após a conclusão, não há como seguir adiante. Apesar de fundamental, a regra descrita não é seguida por grande parte das organizações. Nem sempre as empresas iniciam seus projetos ligados à área de Gestão de Dados com o ROI de nido, prática esta que é muito perigosa. Se a empresa aplicar uma expectativa de custos muito rigorosa fatalmente terá projetos cancelados por excederem os custos planejados, mesmo com baixos percentuais de desvios dos orçamentos – sem levar em conta as consequências das perdas das verbas já consumidas e os retornos que as conclusões dos projetos dariam à empresa, mesmo com custos maiores. Por outro lado, também poderão ocorrer situações onde a expectativa com os custos não é considerada, nem mesmo há um controle sobre os custos dos projetos. Nesses casos, a empresa correrá o risco de consumir muito mais recursos nanceiros do que os retornos reais dos projetos se propõem a dar. Inevitavelmente, no futuro, a área de Gestão de Dados será considerada um overhead, tendo sua existência questionada pelo alto escalão da empresa.

12.10. Utilizar ferramentas de apoio Adotar a Gestão de Dados nas empresas sem o apoio de ferramentas é uma utopia. As ferramentas de apoio são úteis pra agilizar o trabalho, dar maior con abilidade às ações e melhorar a qualidade nal do trabalho. As

ferramentas podem ser especí cas para determinado tipo de trabalho ou genéricas, muitas das vezes customizadas por fornecedores especialistas ou até mesmo desenvolvidas pela própria TI da empresa. Entre as ferramentas especí cas podemos citar: Ferramentas de modelagem: voltadas para criação e manutenção de modelos de dados. Repositório de modelos: dedicado a armazenar os modelos de dados da empresa feitos nas ferramentas de modelagem. Repositório de metadados: dedicado a gerenciar os metadados da empresa, incluindo bancos de dados e modelos de dados. Ferramentas de MDM: dedicadas a gerenciar os dados mestres da empresa de acordo com a arquitetura de MDM estabelecida. Ferramentas de Data Quality: dedicadas a identi car, limpar e corrigir os dados incorretos. Geralmente as ferramentas especí cas são comercializadas por grandes fornecedores de tecnologia, possuem suporte especializado e costumam ter pouco grau de customização. As ferramentas customizadas são desenvolvidas pela própria empresa ou comercializadas por fornecedores especialistas. São personalizadas de acordo com a necessidade de cada empresa. Entre essas ferramentas podemos citar: Auditoria em modelos de dados. Base de dados de indicadores e métricas. Apoio ao processo de Gestão de Dados (workflow). Gestão de solicitações.

Ferramentas prontas e customizadas podem conviver em perfeita harmonia. A gura a seguir demonstra um exemplo de convivência entre ferramentas prontas, especí cas para um determinado propósito, e customizadas.

Figura 12.13 – Ferramentas de apoio à Gestão de Dados

Quando adquirimos e adotamos ferramentas de apoio às atividades, devemos levar em consideração três regras básicas: Regra 1: as ferramentas são instrumentos de apoio, portanto a essência dos processos de Gestão de Dados não deve mudar em função da utilização de determinadas ferramentas. Os processos da Gestão de Dados podem mencionar os seus usos e, em algumas situações, podem sugerir modi cações menores nos processos em função de características pontuais das ferramentas – que não devem in uenciar grandes modi cações nas especi cações dos processos da Gestão de Dados. Regra 2: ferramentas que funcionam em uma empresa não constituem necessariamente garantia de sucesso em outra empresa. Um dos erros mais comuns na adoção de ferramentas prontas é não levar em conta os processos, as demais ferramentas existentes e as características da

empresa que podem in uenciar de forma positiva ou negativa na adoção dessas ferramentas. Regra 3: a aquisição ou customização de ferramentas deve ser pensada de forma integrada, mesmo que nos primeiros momentos a integração não seja importante. Nas implantações da Gestão de Dados é comum estabelecer etapas para as entregas, muitas vezes baseadas em funções de Gestão de Dados. Exemplo: uma empresa pode começar a implantar a Gestão de Dados com as funções de Arquitetura de Dados e Modelagem de Dados, estabelecidas nos marcos iniciais da implantação. Outras funções, como Qualidade de Dados e Gestão de Dados Mestres, seriam implantadas nos marcos nais do projeto. As funções requerem o uso de ferramentas especí cas que devem ser pensadas já no início da iniciativa. Se isso não for feito, a escolha e a adoção das ferramentas dos marcos nais serão prejudicadas, correndo-se o risco inclusive de a empresa adotar ferramentas que não se integram ou soluções muito complexas.

12.11. Utilizar modelos de dados Desde a época da Administração de Dados o modelo de dados já era considerado o principal artefato de trabalho da disciplina. Atualmente, após a disseminação de outras funções, tais como Qualidade de Dados e Gestão dos Dados Mestres, o modelo de dados continua a ser o principal artefato da Gestão de Dados. O modelo de dados é utilizado como referência em várias funções da Gestão de Dados, como por exemplo: Governança de Dados: os modelos são utilizados como instrumento para registrar quem são os gestores e os custodiantes e demais informações sobre a governança dos dados.

Arquitetura de Dados: os modelos de dados corporativos nos níveis conceitual e lógico representam as entidades de dados e conceitos corporativos da empresa. Desenvolvimento dos dados: os modelos de dados são utilizados para representar as estruturas de dados das aplicações, e os modelos físicos de dados são utilizados pelos DBAs para implementar e/ou alterar essas estruturas nos ambientes de banco de dados. Gestão de Operações e Database: os modelos de dados são utilizados para representar as estruturas físicas dos ambientes de dados (tablespaces, datafiles, clusters e demais objetos da estrutura do banco de dados). Gestão dos Dados Mestres e Dados de Referência: os modelos de dados representam os dados mestres e dados de referência da empresa, de acordo com a arquitetura de nida. Gestão de Data Warehousing e Business Intelligence: os modelos de dados (relacionais e multidimensionais) são utilizados para representar as estruturas de dados das aplicações analíticas. Gestão de Metadados: os modelos de dados são importantes metadados da empresa. Portanto, são geridos de acordo com o estabelecido nesta função. Devem ser armazenados em repositórios de modelos de dados e referenciados nos repositórios de metadados (quando houver). Gestão da Qualidade de Dados: os modelos de dados são utilizados para representar as principais entidades de negócio que necessitam de um trabalho mais apurado de Qualidade de Dados. As utilizações dos modelos de dados re etem as entradas ou saídas dos processos ligados às funções de Gestão de Dados e, portanto, continuam sendo vitais. O seu uso proporciona a concentração de informações

resultantes das atividades de vários processos de Gestão de Dados em um único lugar. Por m, vale ressaltar que o modelo de dados é iniciado através do resultado de um processo de abstração e análise. O modelo de dados não deve ser encarado somente como uma documentação.

12.12. Investir na capacitação dos clientes A Gestão de Dados ainda é um assunto novo e pouco explorado nas empresas, principalmente para os pro ssionais que não atuam diretamente na área mas estão envolvidos no uso dos dados e informações das empresas. A capacitação dos clientes é fundamental para estabelecer um nivelamento mínimo de conhecimento acerca da importância da Gestão de Dados – além de seus objetivos, funções e formas de trabalho mais comuns. Este nivelamento acarreta em um maior comprometimento com a Gestão de Dados e fornece condições aos clientes de acompanhar de forma melhor as iniciativas da Gestão de Dados na empresa. Entre as formas de capacitação mais comuns podemos destacar workshops, treinamentos presenciais e treinamentos online. O conteúdo de cada capacitação deve ser aplicado de acordo com o público-alvo. Públicos táticos e estratégicos devem ser capacitados em noções de Gestão de Dados Estratégica e Governança de Dados. Já os públicos operacionais podem ser capacitados na utilização de ferramentas e processos de trabalho. Públicos mais próximos às equipes de Gestão de Dados costumam ser treinados também na metodologia vigente e em Modelagem de Dados.

12.13. Entender que o sucesso depende de todos O sucesso na adoção de uma área de Gestão de Dados não é responsabilidade única dos seus pro ssionais. Os demais pro ssionais

envolvidos também possuem responsabilidades diretas e indiretas. Dependendo das funções e das formas de atuação, as responsabilidades são as seguintes: A área de Gestão de Dados é responsável por manter objetivos e diretrizes de nidos em sua metodologia. As equipes de desenvolvimento são responsáveis por manter um nível aceitável de qualidade dos artefatos produzidos e também por envolver a Gestão de Dados nas fases iniciais dos projetos. As gerências e coordenações do mesmo nível são responsáveis por oferecer subsídios para que objetivos e diretrizes da área de Gestão de Dados sejam cumpridos. A alta gerência da empresa é responsável pelo patrocínio e reconhecimento formal da área de Gestão de Dados. Sem isso a atuação da Gestão de Dados é muito limitada. É ainda responsabilidade dos pro ssionais das equipes de Gestão de Dados não incentivar a cultura de “feudos” que algumas empresas ainda possuem por não entenderem que os dados são propriedade da empresa e não de uma ou duas áreas especí cas.

12.14. Divulgar a área de Gestão de Dados Existe um ditado popular que diz: “O pato põe ovos, anda, nada e voa. Já a galinha apenas põe ovos e anda. Porém, quando a galinha põe seus ovos ela berra para todos. Já o pato, não”. Muitas áreas de Gestão de Dados são extremamente maduras, porém fracassam por não saberem divulgar suas conquistas para as demais áreas da empresa. Ou seja, não sabem utilizar a comunicação como um importante meio de marketing.

A divulgação da área e de seus objetivos e resultados conquistados é fundamental para prover uma comunicação corporativa entre a área de Gestão de Dados e as demais envolvidas. A criação de um portal especí co para Gestão de Dados com uma identidade visual apropriada, também utilizada em newsletters e assinaturas de e-mails corporativos, traz para as pessoas em volta um conceito de organização e maturidade, ajudando a quebrar resistências e tornando a comunicação mais simples. A promoção de workshops sobre assuntos ligados à Gestão de Dados também é importante para disseminar o conhecimento sobre o tema e também a importância de manter uma gestão e caz dos dados. Pequenas notas educativas colocadas em relatórios, laudos e pareceres emitidos por membros da equipe também são importantes instrumentos para reforçar pontos que eventualmente estão sendo esquecidos. A adoção de boa parte dessas recomendações auxilia a manter uma comunicação e caz. Quanto ao conteúdo desses canais, costumo sugerir os seguintes itens: Retornos nanceiros da área. Indicadores da área (tempo, custo, qualidade, reuso, etc.). Indicadores de qualidade. Informações sobre os projetos da área, principais marcos obtidos. Convocação para workshops e treinamentos internos e externos. Análises sobre participações em eventos. Notícias sobre Gestão de Dados. Documentação referente à metodologia e aos processos da área de Gestão de Dados.

O conteúdo sugerido é apenas uma relação de tópicos mais comuns, porém outros tópicos podem ser adotados conforme as características e a cultura da empresa. O importante é manter a prática de sempre buscar uma comunicação e caz dentro e fora da área de Gestão de Dados.

12.15. Ter bom senso O bom senso é ligado diretamente à ideia de sensatez, sendo uma capacidade intuitiva de distinguir a melhor conduta em situações especí cas, que, muitas vezes, são difíceis de serem analisadas mais longamente. O bom senso é muitas vezes confundido com senso comum, que pode re etir muitas vezes uma opinião errônea e preconceituosa sobre determinado assunto. Quando bem utilizado, o bom senso diminui resistências e con itos, facilita as parcerias, reduz a burocracia e melhora o espírito de colaboração entre as equipes.

13. Desenvolvimento Pro ssional “O lucro do nosso estudo é tornarmo-nos melhores e mais sábios.” Michel de Montaigne

13.1. O mercado de trabalho em Gestão de Dados Atualmente o mercado de Gestão de Dados está em uma crescente evolução. Após duas décadas de estagnação, as empresas começaram a rever seus valores a respeito da importância dos dados como ativos estratégicos. Novas funções de dados como: Gestão de Dados Mestres, Arquitetura de Dados e Governança de Dados, junto com novos papéis e ferramentas necessários para manter uma gestão efetiva dos dados das empresas, trouxeram a necessidade de novos pro ssionais, mais quali cados. A escassez desses pro ssionais no Brasil é notória. No exterior, em países que já possuem uma maturidade mais avançada em Gestão de Dados, esta falta de pro ssionais também é comum. Entre os papéis mais procurados estão: cientistas de dados, gestores de dados de negócio (data stewards), gestores técnicos de dados e executivos de Gestão de Dados.

Os cientistas de dados são responsáveis por analisar grandes volumes de dados para encontrar informações que possam aumentar a lucratividade dos negócios. A pro ssão de cientista de dados se tornou promissora, sendo considerada por alguns como o emprego mais “sexy” do século XXI. Os gestores de dados de negócio (data stewards) são pro ssionais ligados à área de negócio da empresa. Possuem conhecimento profundo da área onde trabalham e atuam como os principais curadores dos dados em seus segmentos. Este per l também é novo no mercado – contudo, os pro ssionais de dados com per s mais generalistas, que já atuavam na área de TI, estão ocupando as primeiras posições disponíveis nas empresas. Já os gestores técnicos de dados são considerados uma evolução do papel do Administrador de Dados. Continuam a atuar dentro da área de TI, porém um novo per l é requisitado. Agora são necessários conhecimentos e práticas avançadas em Governança de Dados, Qualidade de Dados, gerenciamento de dados mestres e demais funções da Gestão de Dados. Administradores de Dados devem car atentos nesta mudança, para mais uma vez não deixar o bonde passar. Outro papel que ainda vai crescer muito no Brasil é o CDO (Chief Data Officer), também conhecido como Executivo de Gestão de Dados. Esse pro ssional atua no nível de direção e é responsável por trazer a Gestão de Dados para um patamar estratégico. Também gerencia todas as funções de Gestão e Governança de Dados. En m, o mercado está repleto de oportunidades e as tendências de crescimento para os próximos anos são exponenciais.

13.2. Organizações que atuam na área de Gestão de Dados

Várias associações e grupos que possuem relação com a disciplina Gestão de Dados têm atuado no mercado com o propósito de incentivar e melhorar a utilização dos recursos de dados e informações nas empresas. Essas organizações são sediadas no hemisfério norte (Estados Unidos, Canadá e Europa) e possuem branches locais em vários países do mundo. O Brasil já conta com algumas dessas organizações estabelecidas em seu território. Veremos a seguir as principais associações e grupos que atuam na área de Gestão de Dados. 13.2.1. DAMA® – Data Management International A Data Management Association (DAMA® International) é a primeira organização mundial dedicada aos pro ssionais de Gestão de Dados. Possui mais de 7.500 associados distribuídos em quarenta capítulos no mundo. Seu propósito é promover o entendimento, o desenvolvimento e a prática dos assuntos ligados à Gestão de Dados. Ao contrário das outras associações, que possuem focos especí cos para determinadas funções de Gestão de Dados, a DAMA® engloba todas as funções de Gestão de Dados descritas em seu corpo de conhecimento, o guia DAMA-DMBOK®. Atualmente o guia possui dez funções especí cas para a disciplina Gestão de Dados. A principal missão da DAMA® International é promover o desenvolvimento da carreira dos gestores de dados em direção à maturidade. A associação pretende amadurecer a pro ssão de gestor de dados de diversos modos. Alguns desses esforços incluem: Realização do evento Internacional “Enterprise Data World”, a maior conferência pro ssional sobre Gestão de Dados no mundo, em parceria com a Wilshire Conferences. Os workshops, tutoriais e sessões de

conferência no evento provêm educação continuada para os pro ssionais de Gestão de Dados. Este evento é realizado no hemisfério norte no mês de abril. Realização de evento anual na Europa nas mesmas proporções do “Enterprise Data World”. Promoção de um programa de certi cação pro ssional, em parceria com o ICCP (Institute for Certification of Computing Professionals), com o propósito de reconhecer as certi cações pro ssionais de Gestão de Dados. No momento, as certi cações promovidas pela DAMA® são as seguintes: CDMP® 3– Certified Data Management Professional. DGSP©4 – Data Governance & Stewardship Professional.

Desenvolvimento de corpo de conhecimento (DAMA-DMBOK®) para nortear a adoção da Gestão de Dados nas organizações. Desenvolvimento de um vocabulário comum em Gestão de Dados através do Dicionário de Gestão de Dados. Apoio na construção e publicação de demais conteúdos relativos à disciplina Gestão de Dados. A DAMA® possui um capítulo brasileiro, DAMA-Brasil®, com sede na cidade de São Paulo. O capítulo DAMA-Brasil® promove anualmente, no mês de agosto, o evento “DMC-Latam”, reunindo centenas de pro ssionais atuantes na área de Gestão de Dados. Além disso, o capítulo brasileiro da DAMA® é o responsável pela tradução técnica do guia DAMA-DMBOK® para o português. Maiores informações sobre a DAMA® e seu capítulo brasileiro podem ser encontradas nos websites: www.dama.org

www.dama.org.br 13.2.2. IAIDQ – International Association for Information and Data Quality A Associação Internacional de Informação e Qualidade de Dados (IAIDQ) é uma organização independente sem ns lucrativos voltada a apoiar os pro ssionais interessados em melhorar a e cácia do negócio através do uso de dados e informações de qualidade nas empresas. A IAIDQ é a principal associação internacional focada na pro ssão e disciplina de Qualidade de Dados e Informação. Os membros da IAIDQ são executivos de empresas e pro ssionais de gestão de informações, tipicamente ocupando posições de destaque em suas empresas, onde desenvolvem vários produtos e serviços sobre gestão de Qualidade de Dados. Podem atuar em vários segmentos: saúde, serviços, nanceiro, energia, varejo, manufatura, meio ambiente, acadêmico, governo, seguros, consultoria, etc. A IAIDQ colabora para avançar a qualidade da informação em todo o mundo através da construção de uma comunidade atuante, da disseminação de conhecimento e aprendizagem. A IAIDQ propõe a excelência da informação como forma de transformar as organizações e a sociedade, melhorando a qualidade de vida em todos os lugares. Entre os objetivos da IAIDQ podemos destacar: Construir e manter um corpo de conhecimento e programa de certi cação de Qualidade de Dados e informações. Desenvolver meios para praticantes de Qualidade de Dados e informações para se conectarem, aprenderem e obterem sucesso em suas iniciativas.

Elevar o per l e o reconhecimento dos pro ssionais que atuam na área de Qualidade de Dados. A IAIDQ promove um evento global por ano, além de eventos locais e regionais em parcerias com outras associações. A IAIDQ Conference está em seu sexto ano e será realizado na Universidade de Arkansas, em Little Rock, no estado de Arkansas, EUA, em novembro de 2013. Além disso, também promove conferências virtuais sobre o tema Qualidade de Dados onde diversos pro ssionais têm a oportunidade de aprender e compartilhar experiências sobre os temas abordados. Após uma pesquisa que levou anos e a colaboração de especialistas de todo o mundo, a IAIDQ criou o preeminente programa de certi cação pro ssional para praticantes de Qualidade de Dados. A credencial IQCP (Information Quality Certified Professional) é uma oportunidade para os pro ssionais de Qualidade de Dados e sua governança demonstrarem suas capacitações e obterem reconhecimento dentro das comunidades de Gestão de Dados e Qualidade de Dados. Maiores informações sobre a IAIDQ podem ser obtidas no website: www.iaidq.org. 13.2.3. DGI – Data Governance Institute O DGI é uma organização dedicada aos estudos da Gestão Estratégica de Dados e Governança de Dados. Em seu website, o DGI disponibiliza um farto conteúdo sobre os temas mencionados. Sua principal publicação é o Data Governance Framework, roteiro adotado por diversas organizações em todo o mundo para implantar e veri car a maturidade em Governança de Dados nas organizações. Além do Data Governance Framework, o DGI disponibiliza diversos tipos de conteúdos:

Terminologia de Gestão e Governança de Dados. Dicas para iniciar programas de Governança de Dados. Estudos de caso. Detalhamento de processos comuns em Governança de Dados. Artigos sobre o tema. O Data Governance Institute não possui capítulos distribuídos no mundo. Também não adota nenhum programa especí co de certi cação, mas mesmo assim é uma das principais referências na função Governança de Dados. Maiores informações sobre o Data Governance Institute podem ser obtidas no website: www.datagovernance.com. 13.2.4. QIBRAS® A QIBRAS®, Qualidade da Informação Brasil, é uma entidade civil sem ns lucrativos constituída por pessoas jurídicas ou físicas direta ou indiretamente interessadas na aplicação das estratégias, metodologias e técnicas da qualidade da informação e dos dados em suas atividades pro ssionais e acadêmicas. Foi a primeira organização do setor de Qualidade de Dados na América Latina. Suas principais formas de atuação são focadas em: Criar e manter as condições para o desenvolvimento do setor de qualidade da informação no Brasil. Promover o aperfeiçoamento técnico-pro ssional pela realização de eventos de caráter educativo, social e cultural. Representar e defender os interesses de seus associados.

Divulgar informações sobre a qualidade da informação. Fomentar as relações entre associados para estimular o intercâmbio de ideias, experiências e negócios por meio da organização de encontros. Relacionar-se ou associar-se a entidades semelhantes, nacionais ou internacionais, desde que isso contribua para atender a seus objetivos. Criar grupos de trabalho, comitês e conselhos setoriais para apoiar seus objetivos. A QIBRAS® pretende fornecer as habilidades fundamentais para o mercado entender e superar os desa os da qualidade dos dados e das informações, além de agregar os princípios da gestão da informação, proporcionar programas de certi cação para as empresas, marco regulatório e difusão da metodologia TDQM®5 (Total Data Quality Management) desenvolvida pelo MIT (Massachusetts Institute of Technology) no Brasil. Maiores informações sobre a QIBRAS® podem ser obtidas no website: www.qibras.org. 13.2.5. TDWI – The Data Warehouse Institute O TDWI é o principal provedor de ensino e pesquisa em inteligência de negócios da indústria de armazenamento de dados e promove uma comunidade de aprendizagem onde os pro ssionais de negócios e técnicos se reúnem para adquirir conhecimentos e habilidades com o propósito de avançar suas carreiras. Através de programas de ensino e pesquisa, TDWI permite que indivíduos, equipes e organizações aproveitem as informações para melhorar a tomada de decisões, otimizar o desempenho e alcançar os objetivos de negócios. Entre as principais ações do TDWI podemos destacar:

Promoção de conferências mundiais sobre inteligência de negócios e armazenamento de dados. Disponibilização de fóruns de discussão. Divulgação de cursos online e seminários na web. O TDWI promove um programa de certi cação pro ssional. A credencial CBIP (Certified Business Intelligence Professional) é uma oportunidade para o pro ssional de inteligência de negócio e armazenamento de dados demonstrar sua capacitação e reconhecimento dentro das comunidades de Business Intelligence e Data Warehousing. Maiores informações sobre o TDWI podem ser obtidas no website www.tdwi.org.

13.3. Certificações: luxo ou necessidade? Quando falamos em certi cação devemos ter em mente que elas afetam dois grupos distintos: pro ssionais e empresas. As necessidades de cada grupo são diferentes e algumas vezes extremamente opostas. Do lado dos pro ssionais, boa parte entende que a obtenção de uma certi cação ajuda em sua empregabilidade. Poucos reconhecem os demais ganhos obtidos através dos esforços para obter a certi cação. O pro ssional enxerga a certi cação como um instrumento de emprego e renda. Tal como qualquer produto ou serviço, todas as certi cações possuem um ciclo de vida no mercado. Nas fases iniciais, onde a certi cação ainda não é tão conhecida e o número de pro ssionais é pequeno em relação à demanda existente, podemos encarar a obtenção de uma certi cação como uma enorme vantagem competitiva em relação aos concorrentes. Este é o melhor momento para tirar uma certi cação, pois quem sai na frente costuma pegar

as melhores oportunidades e, de sobra, ainda aproveitará um bom tempo até que a certi cação seja considerada algo bastante comum. Se a certi cação for realmente relevante para a área em questão, após certo tempo ela será conhecida por todos os pro ssionais da área e o número de pro ssionais certi cados estará próximo da demanda existente. Neste ponto, os benefícios da certi cação em relação à empregabilidade não serão tão expressivos, mas ainda serão considerados um pequeno diferencial no mercado. O último estágio deste ciclo corresponde ao da saturação do mercado (o número de pro ssionais certi cados é igual ou maior que a demanda). Nessa fase a certi cação pode ser considerada praticamente obrigatória. Ou seja, a certi cação é tratada como um item eliminatório. Se dois pro ssionais com experiências e qualidades semelhantes concorrem a uma mesma vaga, fatalmente o que não possui a certi cação será sumariamente eliminado. Primeira conclusão: para os pro ssionais, quanto mais cedo obter a certi cação maiores serão as oportunidades e os ganhos.

Já as empresas enxergam a certi cação como um diferencial técnico. O objetivo é possuir um quadro de colaboradores que tiveram seus conhecimentos atestados por instituições internacionais. Aqui o ciclo de vida da certi cação funciona ao contrário do ciclo dos pro ssionais. Quanto menos pro ssionais certi cados, maiores os custos e o tempo despendido para capacitar ou contratar essas pessoas no mercado. Quando falamos em contratação, além de carecer de mão de obra quali cada, os custos envolvidos na obtenção desses pro ssionais são grandes, pois a demanda por pro ssionais certi cados é maior que a oferta disponível no mercado. Segunda conclusão: para as empresas, quanto maior o número de pro ssionais certi cados, melhor as vantagens e menores os custos.

13.4. Benefícios de uma certificação Os benefícios da certi cação são muitos e podem ser divididos em dois públicos-alvos: os pro ssionais e as empresas. Para os pro ssionais, podemos destacar como principais benefícios diretos: Ampliação de empregabilidade, aumentando o crescimento de trabalho e as oportunidades. Aceleração do crescimento pro ssional. Reconhecimento do grau de quali cação atestado internacionalmente. Incremento do valor e reconhecimento dentro da organização. Satisfação pessoal. Para as empresas, podemos destacar: Possuir pro ssionais certi cados demonstra alinhamento com metodologias normatizadas e aceitas internacionalmente. Qualidade e efetividade no uso dos conceitos de Gestão de Dados nas empresas. Agregação de credibilidade e valor aos prestadores de serviços. Motivação dos colaboradores para buscar crescimento pro ssional. Redução de custos decorrentes da melhor gestão dos dados das empresas.

13.5. Principais certificações do mercado para a área de Gestão de Dados 13.5.1. DAMA-CDMP®

A certi cação CDMP® (Certified Data Management Professional) é destinada à comprovação de conhecimento dos gestores de dados (técnicos, estratégicos e de negócio). A certi cação é reconhecida mundialmente e é promovida pela DAMA International em parceria com o ICCP (Institute for the Certification of Computing Professionals). A credencial CDMP® é uma ótima oportunidade para os pro ssionais da área comprovarem suas experiências em gestão e Governança de Dados. De acordo com a experiência pro ssional e os resultados obtidos nas provas, o pro ssional pode obter a credencial CDMP® Practitioner (praticante) ou CDMP® Master (mestre). A credencial CDMP® praticante é concedida para os pro ssionais que obtêm a pontuação de 50% ou acima em todos os três exames. Esses indivíduos podem contribuir como membros de time em tarefas a eles atribuídas de acordo com o conhecimento obtido pela experiência em conceitos, habilidades e técnicas em uma área de especialização com dados. A credencial CDMP® mestre é concedida para os pro ssionais que obtêm a pontuação de 70% ou acima em todos os três exames. Esses indivíduos têm capacidade para liderar e direcionar os trabalhos de um time de pro ssionais porque aprenderam e absorveram conceitos, habilidades e práticas em uma determinada área de especialização com dados. Exames podem ser refeitos visando alterar a credencial do nível de praticante para o nível mestre. O candidato poderá receber crédito para um exame de especialidade caso possua uma certi cação de empresas vendedoras de soluções ou entidades publicamente reconhecidas (conforme lista publicada pelo ICCP). Para obter a credencial CDMP®, o pro ssional deve comprovar diversos critérios para elegibilidade, como: educação, formação, experiência, além de

habilidades e conhecimentos especí cos que serão comprovados através de três exames (provas). Para o candidato conseguir a credencial CDMP® ele deve atender a três componentes: Comprovar experiência pro ssional e requisitos educacionais. Ser aprovado em três exames com 110 questões de múltipla escolha cada. Cada exame deve ser feito em um tempo máximo de noventa minutos. Assinar o Código de Ética e Conduta Pro ssional da DAMA®. 13.5.1.1. Requisitos para a certi cação Experiência pro ssional: Pelo menos 48 meses de experiência em Gestão de Dados (CDMP® Master). Pelo menos 24 meses de experiência em Gestão de Dados (CDMP® Practitioner). A conformidade com a experiência e os requisitos de formação será avaliada através da análise do formulário de inscrição encaminhado ao ICCP e de processos de auditoria. 13.5.1.2. Processo de certi cação Inscrição: para efetuar a inscrição o candidato deve preencher formulário disponibilizado no site do ICCP e encaminhá-lo preenchido para o endereço mencionado no formulário. Custo: cada prova possui um custo unitário de US$ 285,00. Para obter a certi cação CDMP® o candidato deverá se submeter a três provas.

Provas: para obter a certi cação, o candidato deverá se submeter a três provas, sendo duas obrigatórias e uma de livre escolha do candidato, de acordo com os exames disponibilizados pelo ICCP. As provas obrigatórias são: IS Core: principais conceitos de sistemas de informação. Data Management Core: principais conceitos de Gestão de Dados. A relação de exames disponíveis para a terceira prova é a seguinte: Data Development: relacionada ao conteúdo previsto na função “Desenvolvimento dos Dados” do DAMA-DMBOK®. Data Operations: relacionada às atividades de DBA e à função “Operações de Dados” do DAMA-DMBOK® Data Warehousing: relacionada às atividades de construção de grandes armazéns de dados. Business Intelligence and Analytics: relacionada às atividades de construção de aplicações analíticas e de inteligência dos negócios. Data and Information Quality: relacionada às atividades de qualidade dos dados. Zachman Enterprise Architecture Framework: relacionada às atividades de arquitetura empresarial e também de Arquitetura de Dados. Integrated IT Project Management: relacionada às atividades de gerenciamento de projetos de TI, aplicados em projetos de Gestão de Dados. Conteúdo baseado no PMBOK® do PMI® e também no RUP (Rational Unified Process).

O terceiro exame pode ser substituído pelo candidato, caso ele já possua alguma certi cação correlata aos exames. Por exemplo: se o candidato possui uma certi cação de Administrador de Banco de Dados como a Oracle OCP, esta substitui o terceiro exame, pois a certi cação Oracle OCP é aceita pelo ICCP como substituta do exame Data Operations. O mesmo ocorre como a certi cação PMP® do PMI® – o ICCP aceita a substituição pelo exame Integrated IT Project Management. A relação das certi cações que substituem o terceiro exame pode ser obtida no website do ICCP. Local das provas: as provas podem ser feitas de forma online no Brasil com o acompanhamento de um Proctor. O Proctor é uma pessoa que atuará como uma espécie de “ scal” do exame. A DAMA® Brasil mantém convênio com o ICCP para atuar como Proctor nos exames para a certi cação CDMP®. Material de apoio e autoestudo: a leitura do DAMA-DMBOK® é fundamental, principalmente para o segundo exame (Data Management Core) e o terceiro exame, dependendo da escolha do candidato. Além disso, o ICCP disponibiliza material de autoestudo em seu website. Entre os materiais disponíveis o candidato terá à disposição guias de estudos, simulados e cursos online. Renovação da certi cação: a credencial CDMP® deve ser renovada a cada ciclo de três anos. A credencial será mantida se o pro ssional comprovar 120 horas em educação (cursos, seminários, palestras) ou ainda em atividades voluntárias para promoção da Gestão de Dados. O processo de renovação também requer um pagamento de taxa de renovação e também o envio de formulário ao ICCP comprovando as 120 horas. 13.5.2. IAIDQ-IQCP

A certiticação IQCP (Information Quality Certified Professional) é voltada aos pro ssionais com responsabilidades sobre governaça de qualidade dos dados e informação. A certi cação é reconhecida internacionalmente. É promovida pela IAIDQ (e International Association for Information and Data Quality), principal organização mundial no assunto de Qualidade de Dados e informação. A credencial IQCP é uma ótima oportunidade para os pro ssionais da área de gestão e Qualidade de Dados comprovarem suas experiências e serem reconhecidos por isso. Para obter a credencial IQCP, o pro ssional deve comprovar diversos critérios para elegibilidade: educação, formação, experiência pro ssional e conhecimentos e habilidades especí cos que serão comprovados através de um exame (prova). Para o candidato conseguir a credencial IQCP ele deve atender a três componentes: Comprovar experiência pro ssional de três a cinco anos e requisitos educacionais. Ser aprovado em um exame com 150 questões de múltipla escolha em um tempo máximo de três horas. Assinar o Código de Ética e Conduta Pro ssional da IAIDQ. 13.5.2.1. Requisitos para a certi cação Educação e experiência pro ssional: Diploma Universitário (Licenciatura ou Bacharelado) e pelo menos três anos de experiência, comprovando 4.500 horas de atividades relativas à Qualidade de Dados. OU

Diploma de ensino médio (ou equivalente) e pelo menos cinco anos de experiência, comprovando 7.500 horas de atividades relativas à Qualidade de Dados. A conformidade com a experiência e os requisitos de formação serão analisados através da avaliação do formulário de inscrição e de processos de auditoria opcionais. Os três ou cinco anos de experiência requeridos não precisam ser contínuos, desde que tenham sido acumulados nos últimos dez anos consecutivos. 13.5.2.2. Processo de certi cação Sobre a inscrição: Para efetuar a inscrição o candidato deve preencher o formulário “IQCP Application form” (http://iaidq.org/iqcp/doc/iqcp-certi cationapplication.doc), pagar as taxas do exame e submeter o formulário preenchido via e-mail à IAIDQ. Agendamento do exame: realizados três vezes ao ano, os períodos de testes de certi cação ocorrem tipicamente nos meses de março, julho e novembro. As datas limite para o agendamento dos exames e as datas de aplicação variam de acordo com a tabela disponível no site www.IQCP.org e na página da IAIDQ na internet. Custo: membros da IAIDQ têm desconto no valor da taxa do exame. A tabela a seguir mostra os valores praticados em 2013. Valor para membros da Valor para não IAIDQ membros Valor da taxa de solicitação para prestar o exame

US$ 100

US$ 100

Valor da taxa do exame

US$ 340

US$ 480

Total antes do prazo de submissão

US$ 440

US$ 580

Taxa de atraso (marcação após janela) US$ 50

US$ 50

Total após o prazo de submissão

US$ 630

US$ 490

Tabela 13.1 – Custo da prova de certi cação IQCP

Os preços mostrados na tabela são praticados no primeiro exame. Caso o candidato não passe, o valor do segundo exame é um pouco mais barato. Valor para membros da IAIDQ

Valor para não membros

Valor total do segundo exame antes do prazo nal da janela de marcação

US$ 290

US$ 390

Valor total do segundo exame após o prazo nal da janela de marcação

US$ 340

US$ 440

Tabela 13.2 – Custo do reexame da prova de certi cação IQCP

Local: a prova é administrada pela Castle World Wilde, que viabiliza mais de 1.500 testes em setenta países. A prova é realizada em locais especí cos, indicados pela administradora, ou, em situações especí cas, também pode ser aplicada nos eventos da IAIDQ. No Brasil, a Castle World Wide possui centros especí cos para realização dos exames IQCP em São Paulo e Brasília. Nota para aprovação: a nota de aprovação ou pontuação de corte para o exame é de 500, em uma escala que varia de 300 a 600 pontos. Conteúdo: a prova possui 150 questões de múltipla escolha com quatro respostas possíveis para cada uma das questões. Elas estão agrupadas no exame em seis grandes domínios, determinados após um estudo sobre a pro ssão e con rmado por mais de 150 pro ssionais ao redor do mundo. A tabela a seguir mostra os domínios e o percentual de questões dentro de cada grupo que geralmente são aplicados no exame. Nome do domínio

Percentual de questões aplicadas no exame

Estratégia da Qualidade da Informação e

17%

Governança Ambiente e Cultura na Qualidade da Informação

13%

Valor da Qualidade da Informação e Impacto nos Negócios

18%

Arquitetura da Qualidade da Informação

11%

Medições e Melhorias da Qualidade da Informação

20%

Sustentação da Qualidade de Informação

21%

Tabela 13. 3 – Conteúdo aplicado na prova de certi cação IQCP

Material de apoio e autoestudo: O IQCP disponibiliza diversos materiais de apoio aos interessados na preparação para o exame IQCP: Apresentação sobre o processo e demais informações relevantes sobre a certi cação. Sessões de vídeos. Guia de estudo. Minicursos. Amostras de questões simuladas, etc. Maiores informações e material detalhado podem ser encontrados no link: http://iaidq.org/iqcp/exam-preparation.shtml Renovação da certi cação: A credencial IQCP deve ser renovada a cada ciclo de três anos. Existem duas formas para conseguir a renovação: Através do envio ao IAIDQ de um relatório de recerti cação que documenta um nível mínimo de desenvolvimento pro ssional contínuo.

Fazer novamente o exame.

Anexos Funções do Guia DAMA-DMBOK® I. Governança de Dados Nome da Função

Governança de Dados

De nição

O exercício da autoridade e controle (planejamento, monitoramento e engajamento) sobre o gerenciamento de ativos de dados

Atividade

Fase

Entender as necessidades estratégicas de dados da organização

Planejamento

Desenvolver e manter a estratégia de dados

Planejamento

Estabelecer papéis dos pro ssionais e das organizações de dados

Planejamento

Identi car e apontar os gestores de dados

Planejamento

Estabelecer organizações de Gestão e Governança de Dados

Planejamento

Desenvolver e aprovar políticas, padrões e procedimentos de dados Rever e aprovar Arquitetura de Dados

Planejamento

Planejamento

Planejar e patrocinar projetos Planejamento e serviços de Gestão de Dados Estimar o valor dos ativos de dados e custos associados

Planejamento

Supervisionar equipe e organizações pro ssionais de dados

Controle

Coordenar atividades de Governança de Dados

Controle

Gerenciar e resolver questões Controle relacionadas a dados Monitorar e forçar o cumprimento dos regulatórios

Controle

Monitorar e forçar a conformidade com políticas, padrões e arquiteturas

Controle

Tabela A1.1 – Governança de Dados – De nição e atividades segundo o guia DAMA-DMBOK®

II. Gestão da Arquitetura de Dados Nome da Função

Gestão da Arquitetura de Dados

De nição

De nição dos dados necessários da organização e o desenho do diagrama mestre para atingir essas necessidades

Atividade

Fase

Entender as necessidades de informação da organização

Planejamento

Desenvolver e manter o modelo de dados da organização

Planejamento

Analisar e alinhar-se com outros modelos de negócios

Planejamento

De nir e manter a arquitetura de Planejamento tecnologia de dados De nir e manter a arquitetura de Planejamento integração de dados De nir e manter a arquitetura de Data Warehousing e Business Planejamento Intelligence De nir e manter taxonomias e Planejamento domínios únicos da organização De nir e manter a arquitetura de Planejamento metadados Tabela A1.2 – Gestão da Arquitetura de Dados – De nição e atividades segundo o guia DAMA-DMBOK®

III. Desenvolvimento dos Dados Nome da Função

Desenvolvimento dos Dados

De nição

Projetar, implementar e manter soluções para atender às necessidades de dados da organização

Atividade

Fase

Analisar os requisitos de informação Desenvolvimento Desenvolver e manter modelos de dados conceituais

Desenvolvimento

Desenvolver e manter modelos de dados lógicos

Desenvolvimento

Desenvolver e manter modelos de dados físicos

Desenvolvimento

Projetar bancos de dados físicos

Desenvolvimento

Projetar produtos de informação

Desenvolvimento

Projetar serviços de acesso a dados

Desenvolvimento

Projetar serviços de integração de dados

Desenvolvimento

Desenvolver Modelagem de Dados e Planejamento padrões de projeto Revisar modelo de dados e qualidade do projeto de banco de

Controle

dados Gerenciar integrações e Controle versionamento do modelo de dados Implementar desenvolvimento/testes de alterações em bancos de dados

Desenvolvimento

Migrar e converter dados

Desenvolvimento

Criar e manter dados para teste

Desenvolvimento

Construir e testar produtos de informação

Desenvolvimento

Construir e testar serviços de acesso Desenvolvimento a dados Validar requisitos de informação

Desenvolvimento

Preparar para implantação de dados Desenvolvimento Tabela A1.3 – Desenvolvimento dos Dados – De nição e atividades segundo o guia DAMA-DMBOK®

IV. Gestão de Operações e Database Nome da Função

Gestão de Operações e Database

De nição

Planejar, controlar e suportar ativos de dados estruturados atravessando o ciclo de vida dos dados, desde a criação e aquisição até o arquivamento e a eliminação

Atividade

Fase

Implementar e controlar ambientes de bancos de Controle dados Obter dados de fontes externas

Operação

Planejar e recuperar dados

Planejamento

Salvar (backup) e recuperar dados

Operação

Con gurar níveis de serviços para Planejamento desempenho de bancos de dado

Monitorar e otimizar o desempenho de banco de dados Planejar a retenção de dados

Controle

Planejamento

Arquivar, reter e eliminar Operação dados Suportar banco de dados especializados

Operação

Entender os requisitos de tecnologia de dados

Planejamento

De nir a arquitetura de tecnologia de dados

Planejamento

Avaliar a tecnologia de dados

Planejamento

Instalar e administrar a tecnologia de dados

Controle

Inventário e acompanhamento das licenças de tecnologia de dados

Controle

Suportar questões e uso Operação da tecnologia de dados Tabela A1.4 – Gestão de Operações e Database – De nição e atividades segundo o guia DAMA-DMBOK®

V. Gestão da Segurança de Dados Nome da Função

Gestão da Segurança de Dados

De nição

Planejar, desenvolver e executar procedimentos e políticas de segurança para prover autenticação, autorização, acesso e auditoria de dados e informação

Atividade

Fase

Entender necessidades de segurança de dados e Planejamento requisitos regulatórios De nir política de segurança de dados

Planejamento

De nir padrões de segurança de dados

Planejamento

De nir controles e procedimentos de segurança de dados

Desenvolvimento

Gerenciar usuários, senhas Controle e grupos de usuários Gerenciar visões e permissões de acesso a dados

Controle

Monitorar a autenticação de usuários e o Controle comportamento de acesso Classi car o nível de con abilidade da informação

Controle

Auditar segurança de dados

Controle

Tabela A1.5 – Gestão da Segurança de Dados – De nição e atividades segundo o guia DAMA-DMBOK®

VI. Gestão de Dados Mestres e Referência Nome da Função

Gestão de Dados Mestres e Referência

De nição

Planejar, implementar e controlar atividades para garantir consistência com a “versão dourada” de valores de dados contextuais

Atividade

Fase

Entender as necessidades de dados mestres e de Planejamento referência Identi car fontes e contribuintes de dados mestres e de referência

Planejamento

De nir e manter a arquitetura de integração de Planejamento dados Implementar soluções de

Desenvolvimento

gestão dos dados mestres e de referência De nir e manter regras de Controle correspondência de registros Estabelecer registros “dourados”

Controle

De nir e manter hierarquias e a liações

Controle

Planejar e implementar integração de novas fontes de dados

Desenvolvimento

Replicar e distribuir dados mestre e de referência

Operação

Gerenciar mudanças em dados mestres e de referência

Operação

Tabela A1.6 –Gestão de Dados Mestres e Referência – De nição e atividades segundo o guia DAMA-DMBOK®

VII. Gestão de Data Warehousing e Business Intelligence Nome da Função

Gestão de Data Warehousing e Business Intelligence

De nição

Planejar, implementar e controlar processos para prover dados de suporte para decisão e suportar trabalhadores do conhecimento

Atividade

Fase

Entender as necessidades de informações de Business Intelligence

Planejamento

De nir e manter a arquitetura de Data Warehousing/Business Planejamento Intelligence Implementar Data Warehouses Desenvolvimento e Data marts Implementar ferramentas de Business Intelligence e

Desenvolvimento

interfaces para usuários Processar dados para Business Intelligence

Operação

Monitorar e otimizar processos Controle de Data Warehousing Monitorar e otimizar atividades de Business Intelligence e desempenho

Controle

Tabela A1.7 – Gestão de Data Warehousing e Business Intelligence – De nição e atividades segundo o guia DAMA-DMBOK®

VIII. Gestão de Documentação e Conteúdo Nome da Função

Gestão de Documentação e Conteúdo

De nição

Planejar, implementar e controlar atividades para armazenar, proteger e permitir o acesso a dados dentro de arquivos eletrônicos e registros físicos (incluindo textos, grá cos, imagens, áudio e vídeo)

Atividade

Fase

Plano para gestão de registros/documentos

Planejamento

Implementar sistema de gestão de registros/documentos para Operação e Controle aquisição, armazenamento, acesso e controles de segurança Backup e recuperação de registros/documentos

Operação

Retenção e eliminação de registros/documentos

Operação

Auditoria de documentos/gestão de registros

Controle

De nir e manter as taxonomias da organização

Planejamento

Documentar/indexar informação de conteúdo de metadados

Operação

Prover acesso e recuperação de

Controle

conteúdo Governar para conteúdo de qualidade

Controle

Tabela A1.8 – Gestão de Documentação e Conteúdo – De nição e atividades segundo o guia DAMA-DMBOK®

IX. Gestão de Metadados Nome da Função

Gestão de Metadados

De nição

Planejar, implementar e controlar atividades para permitir o fácil acesso a metadados integrados de alta qualidade

Atividade

Fase

Entender os requisitos de metadados

Planejamento

De nir a arquitetura de metadados

Planejamento

Desenvolver e manter padrões para metadados

Planejamento

Implementar um ambiente Desenvolvimento gerenciado de metadados Criar e manter metadados

Operação

Integrar metadados

Controle

Gerenciar repositórios de metadados

Controle

Distribuir e entregar metadados

Controle

Consultar, reportar e analisar metadados

Operação

Tabela A1.9 – Gestão de Metadados – De nição e atividades segundo o guia DAMA-DMBOK®

X. Gestão da Qualidade de Dados Nome da Função

Gestão da Qualidade de Dados

De nição

Planejamento e implementação de atividades que aplicam técnicas de gestão de Qualidade de Dados para medir, avaliar, otimizar e garantir dados adequados para uso.

Atividade

Fase

Desenvolver e promover a consciência em Qualidade de Dados

Operação

De nir os requisitos de Desenvolvimento Qualidade de Dados Avaliar, analisar e entender Qualidade de Desenvolvimento Dados De nir as métricas de Qualidade de Dados

Planejamento

De nir as regras de Qualidade de Dados para as regras de negócio

Planejamento

Testar e validar os requisitos de Qualidade de Dados

Planejamento

Preparar e evoluir com níveis de serviços de Qualidade de Dados

Planejamento

Medir e monitorar continuamente a Qualidade de Dados

Controle

Gerenciar questões de Qualidade de Dados

Controle

Limpar e corrigir defeitos de Qualidade de Dados

Operação

Tabela A1.10 – Gestão da Qualidade de Dados – De nição e atividades segundo o guia DAMA-DMBOK®

Notas Nota do Autor 1 DAMA-DMBOK® é marca registrada da Data Management International. 2 DAMA® é marca registrada da Data Management International.

Introdução 1 Sistema Gerenciador de Banco de Dados Relacional. 2 Unified Modeling Language. 3 Enterprise Resource Planning – Sistema de Gestão Empresarial, por exemplo: SAP, Oracle, JD Edwards. 4 Customer Relationship Management – Sistema Gerenciador de Relacionamento com Clientes.

Parte 1 1 1 Petabyte = 1.000.000.000.000.000 de bytes. 2 Termo genérico para banco de dados não relacional. 3 Adaptação da de nição de Administração de Dados dada por Barbieri nos anos 90. 4 Fonte: DAMA-DMBOK® Guide. 5 Fonte: website da DAMA International (www.dama.org). 6 SOA = Service Oriented Architecture 7 Master Data Management. 8 Ferramentas CASE (do inglês Computer-Aided Soware Engineering) é uma classi cação que abrange todas as ferramentas baseadas em computadores que auxiliam atividades de engenharia de soware, desde análise de requisitos e modelagem até programação e testes. Podem ser consideradas ferramentas automatizadas que têm como objetivo auxiliar o desenvolvedor de sistemas em uma ou várias etapas do ciclo de desenvolvimento de soware.

9 Abreviatura de Extraction, Transformation and Load. Corresponde às macroatividades de um processo básico de Data Warehousing. 10 Service Level Agreements – Acordos de Nível de Serviço.

Parte 2 1 Fonte: DAMA-DMBOK®. 2 Fonte: Data Governance Institute. 3 Master Data Management. 4 UML – Unified Modeling Language. 5 Primary Key – Chave Primária

Parte 3 1 Abreviatura de homem-hora. 2 Fonte: DAMA-DMBOK®. 3 CDMP é marca registrada da DAMA International. 4 DGSP é marca registrada da DAMA International. 5 TDQM® é marca registrada do MIT (Massachusetts Institute of Technology).