Arquitetura de Dados Corporativos é a estrutura de princípios, domínios, modelos, interfaces e responsabilidades que organiza como uma empresa produz, compartilha, protege, mantém
Confira!
Arquitetura de Dados Corporativos é a estrutura de princípios, domínios, modelos, interfaces e responsabilidades que organiza como uma empresa produz, compartilha, protege, mantém e utiliza informações. Ela define onde os dados vivem, qual sistema é referência, como identidades e históricos são preservados e quais decisões condicionam a evolução tecnológica. Diferentemente da Engenharia de Dados, voltada à implementação e sustentação dos fluxos, a arquitetura estabelece limites, relações e critérios para que diferentes pipelines e aplicações formem um ambiente coerente. Não existe um modelo único: centralização, federação, nuvem e sistemas legados devem ser avaliados conforme objetivos, risco e maturidade.
O problema de arquitetura em ambientes corporativos
Sistemas isolados e definições conflitantes
Organizações acumulam ERP, CRM, CMMS, aplicações comerciais, plataformas de automação e sistemas especializados ao longo de anos. Cada sistema foi criado para uma finalidade e mantém sua estrutura de dados. O problema emerge quando unidades distintas precisam produzir resultados comuns e descobrem que não compartilham identidades, estados, calendários e regras de negócio. Uma integração que apenas copia tabelas pode transportar divergências para um novo repositório. A arquitetura começa ao identificar domínios de informação e definir quais diferenças são legítimas, quais precisam de harmonização e quais não podem ser eliminadas sem comprometer o significado original.
Um mesmo termo pode designar entidades diferentes. Cliente ativo na área comercial pode ser cliente com contrato vigente; para o financeiro, pode significar cliente com faturamento no período. Em manutenção, disponibilidade pode indicar estado físico do ativo, tempo com ordem encerrada ou atendimento a um SLA. A arquitetura não resolve isso renomeando colunas. Ela define modelos canônicos ou contratos de interoperabilidade com glossário, owners e usos autorizados. Quando uma divergência não é resolvida, deve permanecer visível até aprovação, evitando produzir aparente consistência sobre informações incompatíveis.
Arquitetura lógica, física e organizacional
A arquitetura lógica representa domínios, entidades, relacionamentos, fluxos, regras e permissões sem depender de um fabricante. A arquitetura física descreve componentes de armazenamento, redes, serviços, integrações, regiões e mecanismos de recuperação. O modelo organizacional define responsabilidades, instâncias de governança, gestão de mudanças e critérios de decisão. Esses níveis precisam ser consistentes, mas não se confundem. Dois produtos podem oferecer o mesmo modelo lógico sob infraestruturas diferentes; a avaliação de custo e disponibilidade pertence ao desenho físico.
Uma representação arquitetural útil deve responder de onde vem a informação, quais sistemas podem alterá-la, quem autoriza a publicação e como detectar a falha de uma dependência. Um desenho que apenas liga caixas por setas não constitui arquitetura se omite estados de erro, contratos de interfaces e decisões de ownership. A documentação também deve distinguir ambientes existentes de propostas futuras. O target architecture precisa ter etapas de transição factíveis para não pressupor substituição simultânea de sistemas críticos.
Arquitetura como instrumento de decisão
A principal função da arquitetura corporativa de dados é permitir escolhas consistentes. Uma iniciativa de BI pode precisar de Data Warehouse; uma integração operacional pode exigir API e eventos; uma aplicação especializada pode conservar seu banco transacional. A arquitetura define critérios para cada decisão, evitando que projetos independentes criem cópias de informação sem controle. A padronização deve concentrar-se nos contratos que exigem interoperabilidade, sem impor uniformidade artificial a processos que possuem necessidades distintas.
A governança precisa registrar decisões arquiteturais, alternativas consideradas, justificativas e condições de revisão. Quando uma plataforma é escolhida pela facilidade inicial de um fornecedor, a dependência futura pode não ser evidente. Uma decisão tecnicamente consistente avalia custos de migração, retenção, performance, suporte, acesso a metadados, portabilidade e continuidade. A expansão deve preservar a capacidade de explicar dados históricos e limites conhecidos, em vez de substituir todo o ambiente sempre que uma nova tecnologia é adotada.
Domínios, entidades e referência dos dados
Domínios de negócio e ownership
Domínios organizam conjuntos de informação relacionados a funções e processos, como vendas, contratos, ativos, manutenção e finanças. A divisão não precisa corresponder exatamente ao organograma; pode refletir a responsabilidade real pelo significado e pela qualidade. O Data Owner aprova definições, enquanto equipes técnicas mantêm sistemas e processos de publicação. Uma arquitetura federada pode permitir autonomia dos domínios, desde que padrões de identificação, catalogação, acesso e observabilidade sejam comuns quando a troca entre áreas o exige.
Uma arquitetura de dados só produz interoperabilidade quando os domínios compartilham contratos claros de identidade, significado e mudança. A integração precisa respeitar a função dos sistemas produtores e preservar o contexto para os consumidores.
A responsabilidade deve ser estabelecida por produto de dados e interface. Uma entidade compartilhada, como equipamento, pode possuir cadastro mestre em sistema de ativos e registros operacionais em SCADA ou CMMS. A arquitetura precisa distinguir o identificador estável do equipamento, os eventos que o afetam e suas classificações ao longo do tempo. Não é correto escolher um sistema autoritativo para todos os atributos de um objeto sem verificar quais propriedades cada fonte governa. A matriz deve tratar ownership por campo ou classe de informação quando necessário.
Master Data e identidade compartilhada
Master Data Management procura estabelecer coerência para dados de referência usados por múltiplos processos. A necessidade pode envolver identificadores de cliente, fornecedor, produto, ativo, unidade ou contrato. Entretanto, criar um cadastro central não elimina automaticamente duplicações e divergências. É necessário definir regras de correspondência, prioridade entre fontes, vigência, correção e tratamento de registros sem match. Uma chave aparente, como nome de loja ou descrição de ativo, pode mudar e produzir ligações incorretas.
A arquitetura deve distinguir identidade de negócio de identificadores técnicos de cada plataforma. Em uma incorporação de empresa, duas unidades podem usar códigos iguais para objetos diferentes. O processo de integração precisa conservar contexto de origem e evitar colisões. Alterações de classificação devem registrar quando passaram a valer; caso contrário, relatórios antigos são recalculados sob a estrutura atual, produzindo tendências artificiais. O aceite precisa incluir casos de fusão, separação, substituição e cancelamento de entidades relevantes.
Modelo canônico e contratos de dados
Um modelo canônico pode facilitar troca entre sistemas ao representar conceitos compartilhados, mas não deve eliminar informação específica dos domínios. Um evento de venda, uma fatura e um pagamento podem possuir relações legítimas sem serem entidades equivalentes. O contrato define estrutura, significado, unidade, código, horário, tratamento de nulos, atualização e compatibilidade. A padronização deve surgir das necessidades reais de interoperabilidade, não da intenção de uniformizar toda a empresa num único schema.
A adoção de contratos também exige gestão de versões. Uma propriedade adicionada pode quebrar consumidores rígidos, enquanto uma alteração no significado de status pode causar erro sem mudança sintática. O plano de evolução deve estabelecer aviso prévio, versões suportadas, testes regressivos e processo de aposentadoria. Um catálogo empresarial precisa registrar consumidores conhecidos, sobretudo quando alterações podem impactar obrigações contratuais ou indicadores executivos. Documentação declarada manualmente deve ser identificada como tal e revisada, não apresentada automaticamente como prova de execução.
Topologias de armazenamento e integração
Centralização, federação e compartilhamento
Uma topologia centralizada reúne capacidade comum de armazenamento e transformação, facilitando políticas uniformes e administração de ferramentas. Pode, porém, criar dependência operacional e fila de demandas quando todos os domínios precisam da mesma equipe. Uma arquitetura federada aproxima ownership e publicação das áreas, mas exige governança compartilhada para impedir incompatibilidades. Data Mesh é uma abordagem organizacional possível em certos contextos, não um produto que se instala nem uma justificativa automática para descentralização.
A escolha depende da maturidade dos domínios, da capacidade técnica, das obrigações de conformidade e do custo de sustentação. Uma organização menor pode alcançar governança adequada com uma plataforma central e processos bem definidos. Já uma empresa com sistemas e unidades muito distintos pode demandar domínios com responsabilidades próprias. A decisão deve considerar como consumidores descobrem os dados, como permissões são verificadas e quem responde por falhas entre produtores e consumidores.
Data Warehouse, Data Lake e Lakehouse
Data Warehouse é frequentemente usado para dados estruturados e análise governada; Data Lake pode receber diversos formatos e históricos, enquanto arquiteturas Lakehouse combinam características de ambos dependendo da tecnologia. A arquitetura corporativa deve comparar workloads, perfil das consultas, políticas de retenção, suporte a transações, capacidade de reprocessamento e custo. É inadequado inferir que uma solução é melhor apenas pelo rótulo; o projeto precisa demonstrar quais requisitos cada plataforma satisfaz.
Uma mesma organização pode manter armazenamento bruto controlado e modelos analíticos curados, ou operar num único ambiente com separação lógica de camadas. O ponto crítico é identificar datasets autoritativos e regras de passagem entre estágios. Replicar informação em múltiplos ambientes sem controles de mudança pode ampliar diferenças entre relatórios. A documentação deve esclarecer o que foi observado na origem, o que foi transformado e quais valores foram aprovados para consumo, preservando revisões históricas e rastreabilidade.
Interfaces síncronas, assíncronas e por lote
APIs de consulta, integrações batch, CDC e eventos são mecanismos possíveis para domínios compartilharem informações. Uma API síncrona cria dependência de disponibilidade e tempo de resposta do produtor; mensagens assíncronas exigem controle de entrega, repetição e ordem; um lote pode atender necessidades de consolidação com menor custo operacional. A arquitetura precisa escolher segundo criticidade, latência, volume e garantias reais das fontes, não conforme preferência tecnológica isolada.
A avaliação de uma interface inclui autenticação, autorização, rate limits, versionamento e semântica de atualização. Um consumidor que interpreta estado atual como histórico de eventos pode produzir indicadores falsos; um evento retransmitido não constitui nova transação. O contrato precisa estabelecer tratamento de exclusões, recuperação de perda de rede e limites de retenção. A integração corporativa deve preservar fronteiras de segurança e evitar consultas diretas que sobrecarreguem sistemas transacionais. Em ambiente industrial, dados de OT devem ser consumidos sem abrir comandos indevidos.
Segurança, capacidade e continuidade
Identidade, privacidade e classificação
Ao consolidar informações, uma plataforma pode revelar relações sensíveis que não eram visíveis em cada origem isolada. A classificação deve considerar os conjuntos combinados, o propósito de uso, minimização, retenção e perfis de acesso. Um gestor pode ter autorização sobre indicadores agregados de desempenho sem poder consultar dados pessoais de colaboradores. A arquitetura deve aplicar controles no armazenamento, no processamento e na publicação; filtros de visualização não substituem autorização em exports e APIs.
Decisões de centralização, acesso e armazenamento devem ser justificadas pelos requisitos e riscos reais da organização. A avaliação independente de alternativas pode reduzir dependências desnecessárias e esclarecer critérios de aceite.
O catálogo de dados também pode conter metadados sensíveis: nomes de campos financeiros, relações de fornecedores e detalhes sobre sistemas críticos. As permissões sobre linhagem e documentação devem ser proporcionais à finalidade. Quando houver dados pessoais, a governança deve considerar a legislação aplicável, como a LGPD, de acordo com os papéis e as bases de tratamento pertinentes. Nenhuma tecnologia assegura conformidade legal automaticamente. Logs e backups também precisam de proteção, pois podem conservar cópias de informações que já foram excluídas dos sistemas de consumo.
Dimensionamento e requisitos não funcionais
A arquitetura precisa ser dimensionada por volume, taxa de mudança, retenção, usuários simultâneos, padrão de consulta e crescimento. Uma plataforma capaz de armazenar grandes datasets pode apresentar consultas lentas quando o modelo é inadequado; uma interface com alta disponibilidade pode ficar inutilizável por excesso de chamadas. O projeto deve definir critérios de performance por etapa: ingestão, transformação, publicação e leitura. Freshness da informação deve ser medida separadamente do tempo de abertura do dashboard.
O dimensionamento deve incluir carga histórica inicial, recuperação de backlog e picos após indisponibilidade. Um cenário em que milhares de dispositivos reconectam ao mesmo tempo pode exigir buffers e políticas de recuperação. Comparar somente custo de armazenamento ignora processamento, tráfego, observabilidade e suporte. A arquitetura deve registrar trade-offs de redundância, custo, latência e consistência, com testes que representem condições reais e não apenas uma demonstração sem concorrência.
Falhas, recuperação e versão do dado
Falhas podem ocorrer na fonte, na autenticação, no transporte, na transformação, no modelo ou no consumidor. O desenho deve distinguir dados íntegros, provisórios e indisponíveis, informando impacto de cada condição. Um painel com último valor conhecido não deve parecer atualizado se o conector falhou. Para dados críticos, os responsáveis precisam definir se uma publicação será bloqueada, emitida com ressalva ou submetida a aprovação manual. O caminho de recuperação deve especificar até que ponto é possível reprocessar a informação.
Backups não bastam quando regras de transformação, credenciais e configurações não podem ser reconstruídas. A arquitetura precisa versionar essas dependências e identificar o resultado de cada execução relevante. Uma alteração retroativa pode mudar números de um relatório já utilizado; a governança decide se existe nova versão e como ela será comunicada. O plano de continuidade inclui testes de falha, restauração, reconciliação e operação assistida. Uma plataforma redundante ainda pode produzir o mesmo resultado incorreto em todos os nós se a regra for inadequada.
| Decisão de arquitetura | Critérios de escolha | Evidência de validação |
|---|---|---|
| Fonte autoritativa | Ownership, vigência e completude | Entidade reconciliada entre sistemas |
| Centralização ou federação | Maturidade, autonomia e governança | Responsabilidades e padrões documentados |
| Data Warehouse, Lake ou Lakehouse | Consultas, custo, retenção e formatos | Testes com workloads representativos |
| Padrão de integração | Latência, volume, consistência e falha | Contrato e recuperação comprovados |
| Segurança e continuidade | Criticidade, privacidade e operação | Perfis e simulações de incidente |
Roadmap, governança e validação arquitetural
Do inventário à arquitetura-alvo
O diagnóstico começa pelo mapeamento dos sistemas, integrações, domínios, responsáveis, decisões e riscos. A arquitetura de referência identifica princípios, padrões de interfaces, armazenamento, qualidade e segurança. O target architecture não precisa substituir imediatamente sistemas legados; pode orientar uma transição em etapas, com medidas de compatibilidade e redução de dependências. Cada fase deve registrar quais capacidades são entregues, quais sistemas continuam autoritativos e como será comprovado que os consumidores não perderam informação.
A priorização deve considerar valor da decisão e risco técnico. Pode ser mais vantajoso corrigir o cadastro de ativos e estabilizar a integração do CMMS do que migrar todos os datasets para uma nova plataforma. A governança estabelece critérios para aceitar exceções temporárias, como interfaces legadas sem mecanismo nativo de mudança. Essas exceções devem ter dono, prazo de revisão e monitoramento de risco, evitando que soluções provisórias se tornem dependências invisíveis e permanentes.
Documentação, padrões e governança de mudança
Um pacote arquitetural inclui mapa de domínios, sistemas de referência, fluxos de dados, catálogo de entidades, contratos de interface, matriz de acesso, padrões de modelagem, requisitos de observabilidade e procedimentos de alteração. Diagramas devem representar relações lógicas e implantação quando necessário; não devem ser tratados como provas de execução. Os registros de decisão precisam indicar alternativas rejeitadas, dependências de fornecedor, justificativas e condições que exigem revisão futura.
Mudanças de schema, alteração de classificação ou integração de nova unidade precisam passar por análise de impacto. A equipe verifica consumidores afetados, testes, migração, rollback e atualização de documentação. A publicação de uma nova versão não pode alterar silenciosamente a interpretação de séries históricas. Em contratos com múltiplos fornecedores, a matriz de responsabilidades evita que cada equipe atribua a outra os problemas de interface. Os critérios de aceite devem existir antes da contratação para permitir comparar soluções técnicas.
Homologação por cenários de decisão
Uma arquitetura corporativa só se demonstra adequada quando suporta casos de uso representativos. Em uma rede de unidades, pode ser necessário consolidar receita, estoque, disponibilidade de ativos e consumo, preservando diferentes calendários e granularidades. O teste seleciona registros conhecidos, alterações de organização e situações de dado ausente. Verifica se a estrutura permite reconciliar indicadores e restringir acesso por função. Uma visualização atraente que apresenta o número incorreto não constitui aceite da arquitetura.
O ensaio deve incluir falha de fonte, recuperação de carga, mudança de API e consulta concorrente. Também é necessário verificar os custos e a capacidade da solução durante uso realista, e não somente por estimativa do fabricante. A entrega precisa permitir que uma equipe diferente reconstrua as decisões arquiteturais, identifique a versão vigente e execute o plano de manutenção. O objetivo é manter dados utilizáveis e auditáveis ao longo da evolução organizacional, sem impedir inovação onde há benefício demonstrável.
A aplicação técnica das decisões é aprofundada nos artigos Engenharia de Dados, Modelagem Dimensional e Data Lake x Data Warehouse.
Conflitos de cadastro, ausência de ownership e diferenças de processo frequentemente antecedem as divergências entre relatórios. O diagnóstico permite identificar quais condições precisam ser corrigidas antes de ampliar a arquitetura de dados.
Homologação arquitetural e migração controlada entre domínios
Considere uma empresa que integra um ERP, dois sistemas de manutenção e uma plataforma de energia para gerir várias unidades. O primeiro desafio arquitetural é decidir onde residem as identidades de instalação, equipamento e contrato. Um cadastro técnico pode conter nome local, outro código de fornecedor e um terceiro uma classificação financeira. A equipe deve definir quais atributos são governados por cada domínio, como realizar a correspondência e quando uma relação é considerada confirmada. O ensaio utiliza ativos ativos e desativados, equipamentos substituídos e registros sem correspondência, evitando aceitar associação apenas pela similaridade textual. A arquitetura deve permitir que o histórico de uma substituição permaneça consultável e que indicadores não transfiram automaticamente a performance de um ativo para outro.
Na segunda etapa, uma unidade muda de região administrativa e outro contrato passa a ser gerido por fornecedor diferente. A arquitetura precisa declarar como relatórios históricos tratarão a vigência dessas estruturas. Um gestor pode precisar comparar a estrutura atual com o passado ou reconstruir a estrutura vigente em cada época; as duas leituras são possíveis, mas não devem compartilhar um rótulo ambíguo. O teste compara os resultados por período e confirma que a mudança de dimensão não alterou indevidamente fatos já registrados. O modelo canônico deve preservar informação de origem suficiente para reprocessar e auditar ambas as visões. A documentação registra decisão, aprovação, data de vigência e impacto sobre os consumidores.
Um terceiro cenário examina a indisponibilidade de um domínio produtor. O sistema de faturamento deixa de concluir uma carga, mas os sensores continuam transmitindo. A arquitetura deve distinguir dados de energia atuais dos números financeiros ainda provisórios. Um dashboard pode continuar disponível, mas precisa informar a idade e o estado de cada indicador, em vez de representar todo o conjunto como atualizado. O contrato de consumo deve definir se a publicação será bloqueada, liberada com ressalva ou aguardará fechamento. Quando os dados financeiros retornarem, a correção deve ser reconciliada e os registros de processamento precisam identificar a alteração. Esse ensaio demonstra que disponibilidade de infraestrutura e validade da informação são requisitos separados.
A migração de uma arquitetura existente para novos serviços deve ocorrer com marcos de aceitação, não como substituição completa baseada apenas em expectativa de desempenho. Pode ser necessário manter origem e destino em paralelo, selecionar janelas de referência e comparar chaves, populações e medidas. O piloto deve incluir taxas não aditivas, alterações retroativas e permissões de acesso, pois esses casos revelam falhas ocultas em modelos aparentemente equivalentes. A equipe deve determinar quando uma fonte deixa de ser autoritativa, quais consumidores foram migrados e qual procedimento de rollback permanece possível. Desativar o ambiente anterior antes de demonstrar integridade e rastreabilidade cria risco de perda histórica e dependência de fornecedor.
Os requisitos de segurança arquitetural incluem proteção de registros e de metadados. Um catálogo pode revelar topologia de sistemas, dados financeiros ou conexões entre fornecedores, mesmo sem conter os valores individuais. O teste deve verificar permissões para consultar dependências, alterar classificações e aprovar a publicação de um produto de dados. Quando existem aplicações legadas que não suportam mecanismos modernos, a arquitetura pode exigir mediação controlada, segregação e prazo de modernização. Não é aceitável ampliar indiscriminadamente o acesso apenas para facilitar um piloto. A transição precisa documentar exceções, controles compensatórios e responsáveis por revisar seu prazo de validade.
A documentação final deve reunir princípios de decisão, mapa de domínios, sistemas de referência por atributo, contratos entre produtores e consumidores, modelos de dados, requisitos não funcionais e plano de migração. A equipe deve conseguir explicar por que escolheu determinada topologia, quais alternativas foram consideradas e quais condições exigiriam revisá-la. A verificação inclui cenários de carga e falha, estimativas de capacidade fundamentadas e critérios de retenção. Em operação, o ownership precisa permanecer atualizado após mudanças organizacionais e contratuais. Uma boa arquitetura não é aquela que nunca muda, mas a que permite mudanças sem perder o significado de indicadores, a segurança e o histórico necessário à decisão.
Decisões de localização e soberania dos dados
A distribuição geográfica do processamento pode alterar custos, latência, requisitos legais e governança de acesso. A arquitetura precisa identificar onde os dados são armazenados, quais serviços os processam e como backups e logs transitam entre ambientes. Uma plataforma híbrida pode ser adequada quando sistemas críticos precisam permanecer próximos da operação, mas pode aumentar complexidade de identidade, rede e monitoramento. A decisão deve considerar a classificação dos datasets, a finalidade das transferências e obrigações aplicáveis, sem presumir que um provedor de nuvem automaticamente resolve soberania ou conformidade. Os contratos precisam permitir verificar regiões, acesso de fornecedores e procedimentos de exportação ou retirada de dados.
A escolha também deve examinar portabilidade dos modelos e dependência de recursos proprietários. Algumas funções de transformação e catálogo podem facilitar a implantação e dificultar uma migração futura. Não é necessário evitar toda dependência de fornecedor, mas os riscos devem ser reconhecidos e proporcionais ao benefício. Um ensaio de transição pode exportar uma amostra de dados, metadados e definições semânticas para confirmar que o conhecimento relevante não está oculto na interface de uma ferramenta. Esse teste deve ser proporcional ao porte e às condições de contratação.
Considerações finais
Arquitetura de Dados Corporativos organiza sistemas, domínios, responsabilidades, contratos e modelos para que a informação possa circular e ser utilizada com significado consistente. Ela não se confunde com a instalação de uma plataforma de armazenamento ou com a construção isolada de pipelines. A decisão entre centralização e federação, entre serviços síncronos e eventos, e entre diferentes camadas de armazenamento precisa considerar riscos, maturidade, desempenho e custo total. O objetivo é demonstrar interoperabilidade e governança, preservando diversidade legítima entre sistemas produtores.
O aceite de uma arquitetura requer cenários de decisão, reconciliação, segurança, resposta a falhas, documentação e capacidade de evolução. A transição deve respeitar sistemas existentes e responsabilidades dos proprietários de dados. Uma arquitetura útil permite incorporar novas fontes sem perder o histórico de decisões, deixa visíveis limitações e torna possível avaliar tecnicamente alternativas antes da contratação.
Referências técnicas
[1] MICROSOFT CORPORATION. Cloud Adoption Framework for Azure. Microsoft Learn. Disponível em: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/overview
[2] MICROSOFT CORPORATION. Understand star schema and the importance for Power BI. Microsoft Learn. Disponível em: https://learn.microsoft.com/en-us/power-bi/guidance/star-schema
[3] OPENAPI INITIATIVE. OpenAPI Specification. Publicações oficiais. Disponível em: https://spec.openapis.org/
[4] CLOUD NATIVE COMPUTING FOUNDATION. CloudEvents Specification. Disponível em: https://github.com/cloudevents/spec
Perguntas frequentes
É o desenho de domínios, modelos, sistemas, contratos, segurança e responsabilidades que organiza os dados em toda a empresa.
A arquitetura define princípios e decisões estruturais; a Engenharia de Dados constrói e mantém os fluxos e produtos que seguem esses critérios.
Não. A escolha depende de processos, domínio, maturidade, segurança, desempenho e sistemas existentes.
É o sistema ou domínio reconhecido para determinados atributos ou eventos, com responsabilidade e vigência definidos.
É uma representação compartilhada de conceitos que facilita interoperabilidade, preservando diferenças legítimas dos domínios.
Conjunto de dados de referência de entidades relevantes, como clientes, ativos, produtos e unidades, geridos para manter identidade coerente.
Não. É uma abordagem organizacional de propriedade distribuída dos dados com padrões e governança compartilhados.
Confrontando padrões de consulta, formatos, custos, retenção, segurança e requisitos de recuperação.
Não necessariamente. Pode melhorar autonomia, mas exige maturidade de domínio e mecanismos comuns de interoperabilidade.
Com contratos, vigência, histórico de alterações e testes para assegurar compatibilidade e rastreabilidade.
Porque catálogos e diagramas podem expor relações sensíveis, mesmo sem disponibilizar registros operacionais.
Por cenários de integração, reconciliação, carga, segurança, recuperação e continuidade que representem processos reais.
