Começar com uma equipe pequena
Documentos, uma planilha controlada e uma reunião de revisão podem estabelecer responsáveis, acordos e decisões.
Adequado a um primeiro caso delimitado; verifique manualmente acessos e evidências.
Modelo operacional
Torne explícito
o modelo operacional.
Ligue propósito, direitos de decisão, entrega e evidências. A metáfora da colmeia explica a cooperação entre as partes; os termos familiares do negócio aparecem primeiro.
O MODELO COMO UM TODO
Quatro perspectivas ligadas. Uma prática operacional.
01
Baseline comum
Responsável, acordo, classificação, acesso autorizado e auditabilidade.
02Cinco camadas operacionais
Ligue a política a responsabilidades, decisões, controles e evidências.
03Ciclo de quatro etapas
Cultivar → Governar → Compartilhar → Ativar. Revise o que cada etapa produz.
04Estrutura e direitos de decisão
Separe domínios, produtos e ambientes de execução; identifique quem decide.
O MODELO COMO UM TODO
Cinco camadas. Um fio rastreável.
Acompanhe uma decisão da intenção à evidência. Cada camada entrega algo concreto à seguinte.
| O MODELO OPERACIONAL | Cultivar | Governar | Compartilhar | Ativar |
|---|---|---|---|---|
| Princípios e políticas | Propósito | Classificação | Uso permitido | Revisão do propósito |
| Organização e papéis | Engenharia + dono | Steward + dono | Dono + custodiante | Consumidor + dono |
| Processos e decisões | Preparar | Acordar | Autorizar | Observar |
| Controles e meios | Linhagem | Testes de qualidade | Política de acesso | Monitoramento |
| Evidências e melhoria | Inventário | Contrato | Decisão | Resultado |
Cada produto compartilhado precisa de responsável, contrato, classificação, acesso por política e rastreabilidade. Cada ecossistema adapta nomes de papéis, fluxos de aprovação, limites e cadências em torno desse mínimo.
BIOINSPIRADO POR PRINCÍPIO
Papéis diferentes.
Um ecossistema comum.
As colmeias e a apicultura oferecem uma linguagem para cooperação, responsabilidade local e cuidado com o todo. É uma metáfora organizacional: pessoas, direitos de decisão e produtos de dados permanecem explícitos.
A metáfora ajuda a explicar o modelo. Não substitui os termos da organização nem atribui papéis humanos com base na biologia das abelhas.
EcossistemaPropósito comum
O limite da colaboração: objetivos, domínios participantes, políticas comuns e governança responsável. Comece por um caso de uso e um patrocinador identificado.
Evidências típicasPolítica, registro de decisões, indicador de valor
Domínio de negócioHive
Um domínio com dono responsável, significado e prioridades próprios. Coordena suas Cells e respeita as regras mínimas do ecossistema.
Evidências típicasCarta do domínio, dono, glossário
Subdomínio de negócioCell
Um subdomínio dentro de uma Hive. Stewardship e engenharia trabalham perto dos dados. Uma Cell pode ter vários produtos; a Cell não é o produto.
Evidências típicasSteward, regras de qualidade, inventário de produtos
Agrupamento de negócioComb · opcional
Agrupamento opcional de Cells da mesma Hive. Uma Cell pode pertencer a vários Combs. É um agrupamento de negócio e permissões, não outra camada de infraestrutura.
Evidências típicasCritérios de agrupamento, responsabilidades por escopo
Produto de dadosOferta com responsável
Uma oferta com propósito, dono identificado, contrato versionado, consumidores conhecidos, expectativas de qualidade e ciclo de vida. Tabelas, APIs e dashboards podem ser interfaces de entrega.
Evidências típicasContrato, testes, registro de acesso, utilização
Ambiente de execuçãoFarm
Onde os produtos são cultivados e operados: produção, teste ou desenvolvimento. A Farm delimita a execução e é distinta da responsabilidade de negócio.
Evidências típicasInventário, controles de acesso, evidência de recuperação
01 / Modelo operacional
Papéis definem responsabilidades.
Interfaces apoiam o trabalho.
Uma pessoa pode acumular papéis. Registre o papel exercido em cada decisão. Consumer, Producer, EcOps e PlatOps são perspectivas de interação com o produto e não substituem responsabilidades de negócio.
| Papel | Escopo | Responsabilidade | Interface de referência |
|---|---|---|---|
| Fórum de governança | Ecossistema | Define o baseline, revisa exceções entre domínios e resolve conflitos. | EcOps registra as decisões |
| Gestor do ecossistema | Ecossistema | Coordena a implantação, o escopo, as versões de políticas e a melhoria. | EcOps |
| Dono do domínio | Hive | Responde pelo domínio e pelas decisões de aprovação escaladas. | EcOps / Producer |
| Dono do subdomínio | Cell | Responde pelo subdomínio e pelsuas decisões de aprovação. | Producer |
| Dono do produto de dados | Produto | Responde pelo propósito, contrato, versões, publicação e relação com consumidores. | Producer |
| Steward operacional | Cell; opcionalmente Hive | Mantém significado, classificação e qualidade; revisa pedidos. | Producer / EcOps |
| Steward coordenador | Hive | Coordena o stewardship e resolve perguntas entre Cells. | EcOps |
| Engenharia de dados | Cell; opcionalmente Hive | Constrói e mantém preparação e entrega reproduzíveis. | Producer |
| Custodiante técnico | Farm | Opera ambientes e implementa controles autorizados. | PlatOps / EcOps |
| Consumidor | Produto | Usa dados nos termos acordados e dá retorno sobre a adequação ao propósito. | Consumer |
Sem dono de subdomínio, explicite a responsabilidade herdada pelo dono do domínio. Um Comb pode agrupar permissões sem criar outro papel. A segregação de funções depende do risco e do contexto.
DAMA-DMBOK 2 / DCAM / DATA MESH
Três referenciais, com limites claros.
| Referencial | O que o KDV operacionaliza | O que exige trabalho próprio |
|---|---|---|
| DAMA-DMBOK 2 · edição revisada | Práticas de responsabilidade, metadados, qualidade, segurança e ciclo de vida. | Arquitetura, modelagem, dados mestres, integração, armazenamento e outras disciplinas exigem projeto contextual e trabalho especializado. |
| DCAM · perspectiva v3 | Melhoria de capacidades apoiada em envolvimento, processos e evidências. | Uma contagem de eventos técnicos não avalia capacidades. Use a metodologia licenciada do editor quando o objetivo for uma avaliação. |
| Data Mesh · quatro princípios | Responsabilidade por domínio, dados como produto, autosserviço e governança federada. | É necessário desenhar limites organizacionais, capacidades da plataforma e financiamento viável dos produtos; a terminologia não cria um data mesh. |
Interpretação original KDV, revisada face às fontes dos editores em 21 de outubro de 2026. Sem alegar mapeamento oficial, endosso ou certificação; não reproduz materiais restritos.
Explorar práticas e fontes originaisESCOLHAS DE IMPLEMENTAÇÃO
Aplique o método com as ferramentas adequadas.
O modelo operacional permanece. As escolhas de automação e hospedagem dependem da escala, competências, risco e arquitetura existente.
Usar a plataforma existente
Ligue o método ao catálogo, fornecedor de identidade, plataforma de dados e gestão de serviços existentes.
Prefira interfaces interoperáveis, caminhos de saída explícitos e evidências recuperáveis.
Usar uma implementação de referência
Combine ferramentas open source selecionadas ou implementações KDV opcionais quando forem adequadas aos requisitos.
Verifique a versão, licença, suporte, disponibilidade e responsabilidades operacionais de cada componente.
ESCOLHAS DE IMPLEMENTAÇÃO
Uma arquitetura de referência, sem impor uma stack.
01
Consumidores
Aplicações · analytics · utilização autorizada em IA
02
Interfaces de produto
Contratos · catálogo · qualidade · decisões de acesso
03
Controles reutilizáveis
Identidade · aplicação de políticas · linhagem · auditoria
04
Execução de dados
Bases existentes · lakehouse · pipelines · recuperação
Os domínios de negócio organizam a responsabilidade. Os ambientes de execução organizam a operação. A soberania dos dados também envolve controle, autoridade, contratos, jurisdição e portabilidade.
Opções open source ilustrativas: OpenMetadata, Keycloak, Apache Ranger, OpenLineage, Airflow, dbt Core, Trino, Apache Iceberg e Superset. A escolha depende do contexto; estes nomes não descrevem uma distribuição integrada validada.
Ler o guia de implementaçãoAI / IA / LGPD / GDPR
Prepare os dados para IA com limites de utilização explícitos.
Uma entrada de catálogo ou um conector de IA não são suficientes. Aplique a governança à finalidade, aos dados de entrada, aos resultados e às decisões humanas.
Propósito e autoridade
Identifique a utilização pretendida e quem a pode autorizar; um novo uso em IA pode exigir uma nova decisão.
Minimização e acesso
Limite dados e privilégios ao necessário para essa finalidade, incluindo pesquisa e resultados derivados.
Origem e avaliação
Registre fontes, atualização e limitações; avalie a qualidade das respostas e acompanhe falhas prejudiciais.
Pessoas e direitos
Preveja revisão, contestação, tratamento de incidentes e exercício dos direitos aplicáveis.
Interpretação original da KDV
Consulte as fontes originais.
010203
DAMA-DMBOK 2
Referencial de conhecimento em gestão de dados que informa o vocabulário de governança.
DCAM
Framework de capacidades que informa a melhoria orientada por evidências. Consulte o editor sobre acesso e licenciamento.
Data Mesh
Quatro princípios que informam domínios, produtos de dados, autosserviço e federação.
A KDV acrescenta uma interpretação operacional original. Não redistribui conteúdos DAMA-DMBOK ou DCAM. A referência não implica endosso, afiliação, certificação ou mapeamento oficial.