A Thoughtworks vem implementando Data Mesh desde que foi introduzida pela primeira vez por Zhamak Dehghani, uma Thoughtworker na época, em 2019. Desde então, implementamos o data mesh em nossas clientes globalmente.
As 10 recomendações a seguir são baseadas em insights que obtivemos com nossas experiências. Para cada recomendação, comentaremos sobre antipadrões observados, a abordagem que recomendamos como alternativa e o porquê. Essas recomendações são listadas do topo para baixo por camadas de uma organização.
Recomendação #1: Abordagens bottom-up isoladas não funcionam - é preciso obter adesão da liderança desde o início.
Ganhar a adesão da gestão e da liderança executiva para o data mesh pode ser desafiador. Isso frequentemente leva evangelistas de data mesh a tentarem implementar data mesh de baixo para cima, construindo produtos de dados dentro de um domínio de data mesh que especificamente deseja o Data Mesh.
No entanto, vimos que esses domínios e produtos de dados encontram uma barreira intransponível ao tentar expandir o data mesh para outros departamentos, que são céticos sobre toda a abordagem. É muito difícil cruzar limites departamentais e implementar mudanças que alteram prioridades, financiamento, funções e responsabilidades de uma maneira ascendente. Às vezes, pode causar momentos um pouco constrangedores quando alguém pergunta: "Quem é você e por que está me dizendo o que fazer?"
Às vezes, as equipes de plataforma enfrentam o mesmo problema. Elas devem ser as facilitadores e mentoras sobre as melhores práticas: sem o suporte de cima para baixo, eles não podem alterar as formas de trabalho das equipes de produtos de dados, as configurações das equipes ou mesmo implementar um conjunto unificado de políticas de governança de dados. Equipes de produtos de dados enfrentam uma barreira similar quando tentam persuadir equipes que não utilizam o data mesh a fornecer acesso aos dados ou a ajudar na interpretação dos dados. Escalar o data mesh requer um mandato de cima para baixo para criar acordo e alinhamento entre as partes com diferentes agendas e interesses.
É necessária a adesão de cima para baixo e de baixo para cima: equipes entusiasmadas que estão dispostas a mudar sua maneira de trabalhar de baixo para cima e a liderança de cima que apoia essa mudança.
Recomendação #2: Comece com o modelo operacional
Embora o data mesh exija mudanças no modelo operacional e na tecnologia, o modelo operacional é frequentemente deixado de lado por ser muito difícil de alterar. Como resultado, as organizações frequentemente tentam uma abordagem de data mesh priorizando a tecnologia. Essa abordagem que prioriza a tecnologia, embora melhore as práticas tecnológicas, geralmente resulta em falhas no primeiro ano. Isso ocorre porque as estruturas necessárias para suportar a escalabilidade do data mesh não foram adequadamente alteradas para acomodar novas formas de trabalho.
Embora seja verdade que mudar o modelo operacional pode ser difícil, também é fundamental. Isso deve ser feito no primeiro dia de uma iniciativa de data mesh.
O data mesh não é um projeto; é um programa empresarial. É necessário o apoio de outras áreas da organização porque o data mesh afeta a forma como as equipes colaboram entre si. Isso significa que é necessário patrocínio e adesão de alto nível para garantir o alinhamento em toda a organização. Também requer um certo nível de gestão da mudança, como a criação de diversos órgãos de governança, a redefinição de papéis e responsabilidades e a capacitação da organização. Um escritório de transformação pode ajudar aqui; reunindo pessoas com conhecimento e experiência com o modelo operacional e a tecnologia, ele pode garantir o alinhamento organizacional.
Em resumo, lidar com uma mudança de modelo operacional pode ser desafiador, mas é um aspecto essencial da implementação bem-sucedida do data mesh dentro de uma organização. Quanto antes, melhor.
Recomendação #3: Defina domínios de forma que representem objetos de domínio organizacional e otimize a eficiência e a comunicação.
A propriedade de domínio é um princípio-chave no data mesh. É importante porque garante que cada produto de dados no data mesh seja de propriedade de alguém com expertise naquela área específica da organização. O benefício é que torna os produtos de dados mais úteis para aqueles que desejam utilizá-los - elimina a confusão potencial sobre o significado de determinados termos em determinados campos de dados e ajuda a mitigar inconsistências. Em outras palavras, se algo não fizer sentido, o proprietário do domínio está melhor posicionado para alterar ou fornecer o contexto necessário.
Claro que isso não acontece sem desafios; definir os limites dos domínios organizacionais - e quem é dono do quê - é difícil. Isso geralmente é causado por orçamentos predefinidos e linhas de reportes ou possivelmente por influências políticas subjacentes. Por isso, no início, pode ser mais fácil definir domínios ao longo dos limites das funções existentes. Você pode então subdividir ainda mais os limites de domínio que se tornarem complexos demais ou reatribuí-los conforme o projeto avança e novas informações são descobertas. Melhor ainda, comece com um domínio e depois explore para fora à medida que o tempo passa como um processo iterativo. As organizações que já trabalham com um design orientado por domínio em seu modelo operacional têm mais facilidade para fazer essa mudança operacional.
No final das contas, existem várias maneiras de definir um domínio. O importante é que esses domínios façam sentido no contexto da organização, sejam documentados e tornem a comunicação e os processos mais rápidos e eficientes. Alguns exemplos podem ser:
Ao longo das unidades de negócios ou funções existentes
Ao longo dos resultados de negócios (metas como “aumentar os lucros”, “aumentar a satisfação do cliente”)
Ao longo de fluxos de valor (iniciativas que entregam valor ou resultados aos clientes)
Use a Manobra Inversa do Conway (é aqui que as equipes são estruturadas de acordo com a arquitetura desejada, em vez de deixar que os caminhos e estruturas de comunicação existentes a formem)
Usar design orientado por domínio
Em resumo, as definições de domínio permitem que as organizações identifiquem proprietários e especialistas em dados e otimizem para linhas eficientes de comunicação e colaboração. É exclusivo para cada organização e, embora a primeira definição de domínio possa ser difícil, comece com um método que seria mais fácil de adotar em sua organização e, em seguida, evolua-o quando a familiaridade com as formas de trabalhar e as responsabilidades forem alcançadas.
Recomendação n.o 4: Desenvolver o modelo operacional, a governança de dados e a plataforma juntos
A plataforma dá vida às funções, responsabilidades e formas de trabalho definidas pelo modelo operacional e pelas políticas definidas pela governança de dados.
Um antipadrão que muitas vezes vemos é que o modelo operacional e a governança de dados são projetos separados e isolados, cada um dos quais define uma coleção de documentação que é jogada sobre a parede para um departamento de TI implementar. Nesse caso, pode ser útil pensar em "data mesh" como um produto, em que o modelo operacional, a governança de dados e a plataforma têm os mesmos objetivos, hipóteses, iniciativas e pendências subjacentes. Com essa abordagem unificada, a implementação do modelo operacional e os conceitos de governança de dados são testados e melhorados iterativamente por meio de produtos de dados, que são habilitados pela plataforma.
Recomendamos que os primeiros casos de uso escolhidos definam o modelo operacional e as políticas de governança de dados como parte dos requisitos. Um exemplo de requisito:
“Quando uma equipe de Produto de Dados cria um Produto de Dados, ele é automaticamente registrado no catálogo de dados juntamente com uma descrição de suas portas de entrada, portas de saída, esquemas, SLOs, domínio e proprietários de domínio para aumentar a transparência do Produto de Dados dentro da organização.”
A plataforma pode então implementar tal requisito, após o qual o modelo operacional relevante e os escritórios de governança de dados podem monitorar o impacto e o desempenho de tal política no ecossistema de data mesh (e se seu desempenho corresponde às suas medidas definidas de sucesso).
Recomendação n.o 5: Estabelecer uma boa plataforma logo no início
Com a abordagem de data mesh, a equipe de plataforma não é mais responsável por manter e transformar dados para os analistas consumirem, mas sim por moldar e construir ofertas de produtos de dados (pacotes implantáveis autônomos) que as equipes de produtos de dados podem solicitar e usar para manter seus dados.
Essas ofertas de produtos de dados são o que é chamado de “quantum arquitetônico” (conforme definido em Arquiteturas Evolutivas). Eles contêm tudo o que uma equipe de produtos de dados precisa para construir seu produto de dados, como recursos de base em torno da ingestão de dados, armazenamento, computação distribuída para transformação de dados, pontos de integração com a ferramenta de catálogo de dados, monitores na ferramenta de qualidade de dados e políticas de governança. Às vezes, há várias ofertas para diferentes tipos de produtos de dados. Essas proteções e modelos facilitam ao máximo para as equipes entregarem produtos de dados.
Como as plataformas de dados de autoatendimento são o principal facilitador de data mesh, elas precisam ser estabelecidas inicialmente. Um erro comum é que as organizações iniciem equipes de produtos de dados sem uma plataforma básica. Essas equipes iniciais de produtos de dados ficam presas por meses de cada vez, esperando que a plataforma desenvolva recursos de linha de base, o que coloca uma pressão sobre as iniciativas em andamento. Na outra extremidade do espectro, algumas organizações passam anos tentando construir a plataforma perfeita, que leva muito tempo para entregar valor e é muito difícil de manter e operar.
A resposta certa está em algum lugar no meio: uma “boa plataforma” é aquela construída sobre requisitos que foram determinados pela pesquisa do que as equipes de produtos de dados realmente precisam. Uma plataforma de autoatendimento bem pesquisada desempenha um papel significativo na redução do atrito que pode ocorrer ao criar produtos de dados.
Para evitar gastar muito tempo construindo a plataforma perfeita, recomendamos começar definindo um conjunto de recursos centrais de MVP para ser “só bom o suficiente” para fazer com que as equipes de produtos de dados se movam rapidamente para agregar valor à organização e continuar a construir e dimensionar iterativamente com os aprendizados de novas equipes e domínios de produtos de dados.
Recomendação n.o 6: Reutilize suas tecnologias existentes na nova plataforma de data mesh
Muitos clientes no estágio inicial de data mesh são desmoralizados pelo grande número de tecnologias e ferramentas necessárias para ativá-la. A verdade é que, embora existam algumas ferramentas que possam atender melhor aos requisitos de data mesh do que outras, é melhor aproveitar seu stack, licenças e experiência existentes onde isso faz sentido. Você pode adicionar camadas personalizadas para melhorar a experiência do desenvolvedor e usar novas ferramentas para preencher quaisquer lacunas de capacidade restantes.
Observe que “reutilizar tecnologias existentes” não significa “reutilizar uma plataforma existente ou mais antiga”. Plataformas existentes ou mais antigas podem não ser compatíveis com a abordagem de data mesh porque a malha de dados requer uma mudança de paradigma crítica na forma como a plataforma é construída. Além disso, a reutilização de plataformas mais antigas que não estão em conformidade com a abordagem de malha de dados pode levar a complexidade adicional, aumentando custos e retardando você.
Sugerimos fazer um inventário das tecnologias existentes e compará-las com os recursos necessários de uma plataforma de dados de autoatendimento de malha de dados e seus requisitos de produto de dados. Reutilize as ferramentas que atendem a esses requisitos e são maduras para serem usadas por meio de autoatendimento (por exemplo, APIs estão disponíveis ou a definição declarativa de recursos é possível para fins de Infraestrutura como Código ).
Recomendação n.o 7: Mova-se lentamente e comece pequeno com Casos de Uso
A principal razão pela qual os projetos de malha de dados falham é porque eles estão tentando escalar muito rápido. Em vez disso, dê à sua organização tempo para aprender e se ajustar à mudança. Essa paciência inicial realmente valerá a pena no longo prazo.
Recomendamos começar com um caso de uso que tenha de dois a três produtos de dados que se estenda por três dimensões — modelo operacional, produto e tecnologia — ao longo de seis meses.
Compreensivelmente, algumas organizações acreditam que essa abordagem é “muito conservadora”. Eles podem querer adotar uma abordagem mais agressiva para integrar vários casos de uso de uma só vez no início. Descobrimos que normalmente leva seis meses para inicializar os primeiros produtos de dados nas três dimensões acima. Quando esse período estiver concluído, os proprietários de produtos de dados precisam ser treinados e uma equipe de plataforma precisa ser montada para começar a desenvolver novos recursos para a plataforma com base nos aprendizados. Novos modelos e formas de trabalhar também são necessários para mudar a organização de um modelo centralizado para descentralizado. Um conselho de governança de data mesh também precisará ser estabelecido com um roteiro para integrar domínios adicionais.
Resumindo: Não corra antes de caminhar. Haverá muitos aprendizados para aprender na jornada. Não os perca.
Recomendação n.o 8: Seja deliberado sobre seus primeiros casos de uso
Escolher seu primeiro conjunto de casos de uso pode ser assustador, mas é importante lembrar que não há uma única resposta certa. Cada organização é diferente. As decisões que você toma dependerão do que você quer otimizar e do apetite de risco da sua organização.
Por exemplo, alguns clientes escolhem casos de uso altamente urgentes e complexos. Muitas vezes, eles estão ansiosos para abordar a ineficiência e a política interna que estão causando dor na organização. Outros seguiram a rota mais conservadora escolhendo um caso de uso simples e isolado para testar o apetite organizacional por malha de dados.
Enquanto isso, outros clientes optam por otimizar a criação de um conjunto diversificado de recursos de plataforma. Uma plataforma madura de dados de data mesh fornece recursos para processamento de dados em lote, [quase] processamento de dados em tempo real, análise, IA/aprendizado de máquina (ML) e governança de dados. Escolher casos de uso que abordem cada uma dessas capacidades define o precedente (ou prioridade) para construir a base para todas as capacidades da plataforma em paralelo.
Outro benefício dessa abordagem é que casos de uso que exigem mais de uma capacidade (como recursos de ML e lote, uma dependência comum) se tornam candidatos para os primeiros casos de uso. Essa abordagem, no entanto, requer uma equipe de plataforma grande e forte que possa lidar com o pensamento do produto e a complexidade de integrar recursos de uma maneira compatível e interoperável.
Embora haja muitas abordagens e maneiras de otimizar, nossa recomendação é que o primeiro caso de uso escolhido seja:
Gerenciável considerando as capacidades existentes da organização
Vinculado às metas de negócios com métricas claras de sucesso
Atingível
É fácil ser consumido pela escolha de casos de uso devido à política interna e otimização excessiva, mas muitas vezes não há um caso de uso perfeito. Uma armadilha comum a evitar é a paralisia por análise: marque o tempo do exercício e comece com “bom o suficiente”.
Recomendação n.o 9: Produtos de dados integrados na plataforma E estruturas de governança do modelo operacional
Um antipadrão que vemos nas organizações orientadas por TI é que a integração das equipes de produtos de dados para na integração da equipe em uma plataforma. Na realidade, também é fundamental integrá-los aos processos organizacionais estabelecidos pelo modelo operacional.
A integração adequada ao modelo operacional permite que as equipes de produtos de dados sejam representadas em vários fóruns para influenciar atividades importantes, como priorização de recursos. A integração também envolve adicioná-los aos canais de comunicação certos para que eles não percam informações importantes sobre novos recursos, lançamentos e oportunidades de aprendizagem.
No longo prazo, as equipes que não estão integradas ao modelo operacional podem não estar alinhadas com os princípios do ecossistema de data mesh mais amplo. Isso pode levar a descontentamento e frustração de todos os lados.
Recomendação n.o 10: Seja comprometido
As implementações de malha de dados dentro de uma organização às vezes exigem grandes mudanças ao longo do tempo que afetam muitas pessoas, departamentos existentes e processos de tomada de decisão. Isso pode ser difícil quando algumas partes de uma organização são resistentes à mudança.
Pode-se argumentar que os problemas associados a organizações que mudam rapidamente, como ampliações de escala, onde o experimento é valorizado e há uma atitude mais relaxada em relação às políticas de acesso a dados, e organizações empresariais mais estabelecidas e maduras, com maior centralização e silos legados mais teimosos, são diferentes e, portanto, devem ser tratados de forma diferente. Embora haja um elemento de verdade para isso, a realidade é que, de qualquer forma, se a organização quiser ser bem-sucedida, ela precisa estar disposta a se comprometer com a mudança em termos de implementação e recursos.
Nossos usuários de data mesh mais bem-sucedidos fizeram o seguinte:
Obteve patrocínio de alto nível dedicado desde o início
A adoção do data mesh faz parte da identidade da organização, onde todos estavam dispostos a participar da adoção das práticas e mentalidade de data mesh por meio de uma iniciativa em toda a empresa que priorizava os dados
As pessoas estavam dispostas a dedicar tempo para aprender a nova abordagem e mudar seus processos
As pessoas certas foram rapidamente transferidas para os lugares certos e os investimentos foram rapidamente feitos onde havia lacunas
A organização estava disposta a aceitar e implementar um modelo descentralizado
A organização estava pronta para estar alinhada com os domínios (se ainda não estivessem)
As organizações que decidiram apostar, alcançam o valor extraído do data mesh mais rapidamente (e mais barato). É por isso que um compromisso total com data mesh é necessário para eficiência e sucesso na mudança.
Resumo
Uma iniciativa de data mesh pode trazer inovação e impacto positivo para sua organização, mas exige dedicação e compromisso para implementar adequadamente. A mudança pode ser desafiadora, mas com a abordagem certa e o processo certo, é possível superar as dificuldades crescentes para ter sucesso com o data mesh.
Você quer saber mais sobre como trazer o data mesh para sua organização ou fazer uma avaliação? Entre em contato conosco .
