MDM : Como construir e extrair valor do hub de dados

Iniciativas de MDM (Master Data Management) estão reconhecidamente entre as mais valiosas implementações de soluções de inteligência analítica da atualidade. Apresentam alto valor agregado e demonstram grandes taxas de retorno no investimento. Seu potencial estratégico tem sido comparado às já maduras iniciativas de Business Intelligence.

Além de viabilizar uma visão 360 graus, pré-requisito para o sucesso de outras soluções como CRM ou ERP, a captura e gestão de dados mestres pode potencializar o uso de outros sistemas de inteligência empresarial, promovendo uma fundação de regras autoritativas que contém dados de alta qualidade e relevantes ao negócio. Tudo isto agrega-se como referência para decisões corporativas de grande confiabilidade.

No entanto, temos visto com frequência, em diversas atuações enfrentadas pelo nosso time de consultoria, em vários pontos do Brasil, que a criação desta base de dados – conhecida como ‘hub’- é apenas o começo do desafio.

Temos notado que o consumo destas informações impõe sérias dificuldades para as equipes. Isto vale para praticamente todos os grupos de decisão, sem deixar de fora aqueles profissionais ‘experts’ em qualidade de dados, que normalmente constituem comitês, formados ao final do projeto, contando com representantes de vários pontos focais, com diferentes perfis, e representando os mais diversos níveis hierárquicos da organização.

No inicio destes projetos, a preocupação dos clientes é obvia em relação a funcionalidades básicas dos sistemas de MDM. Eles adotam, como pré-requisitos, recursos de integração e qualidade de dados, além de robusta habilidade na resolução de identidade.

Identificamos, também, que os principais empecilhos residem na publicação e consumo das informações do ‘hub’. Estas dificuldades, normalmente, estão relacionadas a questões de arquitetura da solução e da falta de conhecimento do cliente a respeito de como navegar nestas bases, ou como referenciar estas informações, a partir de outros sistemas do parque tecnológico, além de questões relacionadas ao ferramental empregado para este fim.

Cientes desta dificuldade, temos adotado, com sucesso, nos projetos em que atuamos, um conjunto de melhores práticas que facilita a vida do cliente nesta etapa final. Em primeiro lugar, as definições de arquitetura devem seguir algumas premissas funcionais. Entre elas está a de promover a rastreabilidade dos registros, de ponta a ponta, para que a solução possa sempre entregar informações enriquecidas, que sejam sustentáveis em relação à sua origem.

Igualmente importante é a necessidade de se fazer uma estruturada camada intermediária, para a consolidação de dados corporativos, onde toda informação a ser trabalhada será integrada, contextualizando seu metadado, antes que seja devidamente unificada. Por fim, a carga da base unificada – e qualificada – entra em cena para a criação definitiva do HUB.

Uma vez que o hub é adequadamente composto, a navegação nesta base demanda, fundamentalmente, dois recursos básicos: publicação de serviços e dashboard administrativo. Tendo como base um ambiente ESB, onde a plataforma SOA concentra os serviços de consumo, estes serão orquestrados e controlados para atender aos mais diversos processos de negócio, seguindo uma arquitetura moderna e madura já reconhecida e praticada no mercado. Assim, o primeiro ponto fica atendido.

Mas é importante que o cliente entenda as limitações que o aplicativo atenderá em relação aos fins administrativos, sendo necessário definir as alternativas de software que se fazem recomendadas neste ponto. A este propósito, criar uma aplicação em Java, PHP (ou qualquer outra solução voltada à tradicional arquitetura cliente/servidor), não tem se mostrado uma boa alternativa. Isso se deve ao fato de que, por trás dos bastidores, qualquer um destes caminhos tem, na linguagem SQL, a estruturação básica para o desenvolvimento deste tipo de solução.

Apesar de ser historicamente reconhecida e praticada para atender aos mais diversos cenários, esta linguagem tem uma limitação crucial, que inviabiliza seu uso efetivo neste contexto: o fato de que cada consulta SQL é elaborada para se recuperar informações em um conjunto finito de tabelas deste complexo modelo de dados.

São cláusulas que “varrem” as camadas desta arquitetura, em uma espécie de sequência de snapshots, deixando uma lacuna entre os relacionamentos existentes entre cada uma destas consultas. A mesma limitação existe quando tenta se endereçar o que tem com o uso de ferramentas de BI, exatamente pelo mesmo motivo.

Em vez disso, temos aplicado, com sucesso, para estes casos, o uso de ferramentas de análise in-memory. Estes softwares possuem uma característica fundamental, que os torna únicos neste tipo de abordagem: o emprego do modelo e dados associativo em seu núcleo de funcionamento. Estas soluções adotam uma estratégia diferente, carregando todos os dados do HUB em memória e criando uma rede associativa entre todos os registros. Desta forma, consegue apontar relacionamentos entre informações desta nuvem, mesmo que não estejam diretamente vinculados à consulta original feita pelo usuário.

De maneira imediata, esta abordagem traz três grandes vantagens:

1 – Não utiliza SQL: portanto, não está sujeita às restrições inerentes a esta linguagem;

2 – Utiliza análise in-memory: torna-se muito mais performática em seu tempo de resposta, principalmente para ambientes volumosos;

3 – Capacidade Associativa: exibe registros associados à determinada pesquisa, mesmo que não estejam diretamente compreendidos no resultado da consulta.

Na prática, o emprego deste tipo de ferramental viabiliza que um simples clique em um determinado registro do sistema legado desvende toda a estruturada a ele relacionada. Ou seja, praticamente de forma imediata o cliente passa a visualizar a versão unificada associada a este registro, bem como suas diversas outras cópias e informações de qualificação deste registro Golden.

Tudo isso com praticamente um único clique. De maneira análoga, o caminho inverso também é possível. Ao selecionar uma cópia mestre de um registro o usuário tem de forma imediata todos seus relacionamentos e cada uma de suas cópias, a cada versão existente nas origens.

Desta forma, a vida do usuário final fica extremamente facilitada, pois, normalmente, os clientes destes sistemas são experts do negócio, sem tanto conhecimento técnico. Além disso, a navegação é plenamente feita pela interface gráfica, e nenhuma query SQL é disparada. Assim, esta abordagem permite que as análises nos dados do HUB tome um aspecto bem mais dinâmico e interativo, com respostas imediatas às suas interações. Portanto o consumo destas informações toma um aspecto muito mais efetivo e estratégico, fornecendo ao usuário maior tempo para análises e menor esforço possível na elaboração de consultas.

(*) Max Rabello Madsen é Diretor Técnico da MD2 Consultoria e Negócios