Modelo de Informação em Nuvem

Bem-vindo ao CIM, um modelo de dados independente de aplicação que simplifica a integração e acelera a inovação.

Principais conclusões

• O CIM é um modelo de dados aberto e compartilhado, não um produto. Ele define conceitos de negócios comuns e seus relacionamentos para que diferentes aplicações possam trocar dados sem mapeamentos personalizados e pontuais.
• É governado como um padrão aberto. O CIM é de código aberto sob a Joint Development Foundation, parte da Linux Foundation, e recebe colaboradores de fornecedores, empresas e da comunidade em geral.
• O conteúdo é organizado em Áreas Temáticas (domínios). Cada domínio representa um conceito de negócio importante e é publicado em vários formatos, incluindo diagramas, para que arquitetos e engenheiros possam adotá-lo de forma incremental.
• O valor central é reduzir a fragilidade da integração. Um modelo canônico substitui o código de tradução ponto a ponto por um destino estável para o qual muitos sistemas podem mapear (de e para).
• A adoção é uma decisão de design, não um interruptor. Você escolhe quais domínios adotar, como mapear seus sistemas de origem e como governar as extensões ao longo do tempo.

Um Novo Padrão para Interoperabilidade de Dados

O CIM é produzido por um consórcio aberto formado para fornecer uma solução baseada em padrões para conectar produtos empresariais. Com o CIM, você pode criar experiências pessoais integradas e personalizadas em aplicações nativas da nuvem.

Para acelerar a transformação digital e oferecer engajamentos personalizados aos clientes em todos os canais, muitas empresas adotam múltiplas aplicações em nuvem e on-premise. Cada uma vem com seu próprio modelo de dados, o que força os desenvolvedores a criar, testar e gerenciar código personalizado necessário para mapear e traduzir dados entre diferentes sistemas. Em vez de acelerar a transformação digital, esse processo retarda a inovação e leva a integrações frágeis.

O CIM é uma especificação moderna e aberta para ajudar a aliviar a dor da integração de dados. O CIM fornece um padrão definido para comunicar-se facilmente entre diferentes formatos de dados. Sendo de código aberto como parte da Joint Development Foundation (sob a Linux Foundation), damos as boas-vindas a todo e qualquer contribuidor.

O problema que o CIM aborda é estrutural, não incidental. Quando cada sistema fala seu próprio dialeto — um chama um cliente de “Contato”, outro de “Parte”, um terceiro de “Conta” — as equipes de integração acabam mantendo uma rede crescente de mapeamentos bilaterais.

Cada nova aplicação multiplica o número de traduções necessárias, e cada alteração de esquema em qualquer sistema pode repercutir e quebrar os pipelines downstream. Um modelo canônico muda a forma desse problema: em vez de N sistemas mapearem entre si, cada sistema mapeia uma única vez para um vocabulário compartilhado.

Related: Fivetran — O pipeline ELT totalmente gerenciado que continua funcionando.

Por que a Integração Ponto a Ponto Falha

É útil ser concreto sobre os modos de falha que motivam um modelo compartilhado.

• Crescimento combinatório. Com mapeamentos ponto a ponto, o número de caminhos de tradução cresce aproximadamente com o quadrado do número de sistemas. Adicionar uma décima aplicação é muito mais caro do que adicionar a segunda.
• Desvio semântico. Duas equipes podem “mapear o cliente” e ainda assim discordar sobre se um cliente é uma pessoa, uma organização ou um relacionamento de faturamento. Os dados fluem, mas o significado diverge.
• Gerenciamento de alterações frágil. Uma renomeação de campo ou um novo atributo obrigatório em um sistema de origem força edições em todos os consumidores que o utilizam.
• Lógica duplicada. Regras de validação, desduplicação e resolução de identidade são reimplementadas em cada integração, em vez de serem definidas uma única vez.
• Pressão de lock-in de fornecedor. Quando a lógica de integração está emaranhada com o esquema de um fornecedor específico, trocar ou adicionar fornecedores torna-se um projeto de reformulação de plataforma.

Um modelo canônico como o CIM não elimina o trabalho de mapeamento — todo sistema de origem ainda precisa de um mapeamento para o modelo. O que ele elimina é a multiplicação desse trabalho. Você cria um mapeamento por sistema para o modelo compartilhado, e o próprio modelo fornece o contrato estável entre eles.

Como o CIM Está Organizado: Áreas Temáticas

O conteúdo definido colaborativamente é organizado em domínios, ou Áreas Temáticas. Cada Área Temática representa um conceito de negócio importante. Os designs do CIM estão disponíveis em vários formatos para cada domínio, incluindo diagramas de exemplo. O número e o escopo das Áreas Temáticas crescerão com o consórcio e as contribuições.

Se você estiver comprando: Boomi AtomSphere — Enterprise iPaaS para integração híbrida de nuvem local.

Essa estrutura orientada a domínios é fundamental para a adoção. Raramente você precisará do modelo inteiro de uma vez. Uma empresa típica começa com os domínios que afetam sua integração mais dolorosa, prova a abordagem e se expande. Os pontos de partida comuns tendem a ser os conceitos que aparecem em quase todos os sistemas:

• Parte / Cliente — as pessoas e organizações com as quais você faz negócios e as funções que elas desempenham.
• Produto — o que você vende, oferece ou gerencia, incluindo catálogos e classificações.
• Conta e relacionamento — como as partes se relacionam com produtos, contratos e entre si.
• Interação e atividade — os eventos, transações e engajamentos que conectam os itens acima.

Como cada Área Temática é publicada com diagramas e múltiplos formatos de representação, os arquitetos podem revisar o modelo conceitual, os engenheiros podem consumir uma forma legível por máquina e as partes interessadas do negócio podem validar se os conceitos correspondem à realidade. Essa abordagem multiformato é uma escolha deliberada de design: um modelo que apenas engenheiros conseguem ler tende a se desviar do significado de negócio.

Como o CIM se Compara a Outras Abordagens

O CIM é uma opção entre várias para alcançar a interoperabilidade. Escolher bem significa compreender as compensações (trade-offs).

Abordagem	O que é	Pontos fortes	Trade-offs
Mapeamento ponto a ponto	Traduções diretas entre cada par de sistemas	Simples para dois sistemas; não requer governança compartilhada	Cresce combinatoriamente; frágil; lógica duplicada
Modelo canônico (estilo CIM)	Um vocabulário compartilhado e independente de aplicação para o qual cada sistema mapeia	Esforço de mapeamento linear; contrato estável; reutilizável entre projetos	Requer governança e acordo; mapeamento ainda é necessário por sistema
Padrões de dados do setor	Padrões verticais para um setor específico (ex: saúde, finanças)	Cobertura profunda de domínio; alinhamento regulatório	Escopo estreito; pode não cobrir conceitos empresariais intersetoriais
Modelos de dados de fornecedores	O esquema nativo de uma plataforma exposto como o hub de integração	Integração estreita de ferramentas; rápido dentro do ecossistema de um único fornecedor	Risco de lock-in; outros fornecedores devem se conformar ao modelo de uma parte
API-first / schema-on-read	Contratos definidos por API; significado resolvido no momento do consumo	Flexível; rápido para iniciar	A consistência semântica depende de disciplina; mais difícil de governar em escala

A orientação prática: use um modelo canônico quando tiver muitos sistemas, conceitos cross-domain e um cenário de integração de longa duração. Use ponto a ponto quando o escopo for genuinamente de dois sistemas e de curta duração. Padrões da indústria e CIM são complementares — um padrão vertical pode informar um domínio, enquanto o CIM fornece o vocabulário empresarial transversal.

Como Adotar o CIM na Prática

A adoção é uma sequência de decisões deliberadas, e não uma migração única. Um padrão viável é este:

1. Escolha uma integração de alta dor e bem delimitada. Escolha um domínio onde a dor do mapeamento seja real e o escopo seja pequeno o suficiente para provar valor rapidamente.
2. Inventarie os sistemas de origem e seus esquemas. Documente como cada sistema chama os conceitos na Área de Assunto escolhida e onde eles divergem.
3. Mapeie cada sistema para o domínio CIM. Crie um mapeamento por sistema para o modelo compartilhado. Trate esses mapeamentos como artefatos versionados, não como scripts descartáveis.
4. Defina sua política de extensão antecipadamente. Decida como lidará com conceitos que o CIM ainda não cobre — as extensões devem ser documentadas, nomeadas consistentemente e propostas de volta ao consórcio quando forem amplamente úteis.
5. Estabeleça a governança. Atribua a responsabilidade pelos mapeamentos, um processo de revisão para alterações e uma cadência para sincronização com atualizações upstream do CIM.
6. Expanda domínio por domínio. Reutilize os padrões de mapeamento e a governança do primeiro domínio para reduzir o custo do próximo.

Duas ressalvas valem a pena ser declaradas abertamente. Primeiro, um modelo canônico adiciona uma camada — não é gratuito, e o retorno vem da reutilização em muitas integrações, não de uma única. Segundo, o mapeamento é onde reside o trabalho real; o modelo fornece um alvo estável, mas alguém ainda precisa decidir como cada campo de origem corresponde a ele, e essa decisão se beneficia de insumos de negócio, não apenas de engenharia.

Related: Matillion — ELT push-down desenvolvido para data warehouses em nuvem.

Governança, Licenciamento e Contribuição

O CIM é de código aberto como parte da Joint Development Foundation, que opera sob a Linux Foundation. Essa estrutura é importante para empresas que o avaliam: a Linux Foundation é um lar bem estabelecido para projetos de código aberto colaborativos e neutros em relação a fornecedores, e a Joint Development Foundation fornece um framework legal projetado especificamente para desenvolver e operar projetos de padrões e especificações.

Para um arquiteto de dados corporativos, as implicações práticas deste modelo de governança são:

• Neutralidade de fornecedor. Nenhum fornecedor controla a especificação, o que reduz o risco de o modelo ser moldado para favorecer uma plataforma.
• Contribuição aberta. Qualquer pessoa pode propor alterações, o que significa que o modelo pode evoluir para refletir necessidades de integração do mundo real, em vez de um único roadmap.
• Processo orientado a especificações. O modelo da Joint Development Foundation é construído em torno da produção e manutenção de especificações, o que se alinha à forma como os padrões são adotados e referenciados em revisões de arquitetura e compras.

Contribuições são incentivadas e abertas a todos. As contribuições geralmente assumem a forma de Áreas de Assunto novas ou refinadas, correções e esclarecimentos, diagramas de exemplo e feedback de projetos de integração reais. As contribuições mais valiosas geralmente vêm de profissionais que enfrentaram um problema específico de mapeamento e conseguem descrever o conceito que o resolve.

Favorito do leitor: Airbyte — ELT de código aberto com opção de nuvem gerenciada.

Como se Envolver

Você tem interesse em se juntar à iniciativa CIM? Ótimo! Sinta-se à vontade para nos enviar um e-mail para mais informações.

Além do e-mail, as formas naturais de engajamento são revisar as Áreas de Assunto publicadas para o seu domínio de interesse, tentar mapear um de seus sistemas para um domínio e trazer as lacunas encontradas de volta para a comunidade. Como o número e o escopo das Áreas de Assunto crescem com o consórcio e as contribuições, o modelo melhora proporcionalmente à quantidade de problemas reais de integração que seus usuários trazem para ele.

Perguntas Frequentes

O que exatamente é o Cloud Information Model?

O CIM é um modelo de dados aberto e independente de aplicação que define conceitos de negócio comuns e seus relacionamentos para que diferentes aplicações possam trocar dados por meio de um vocabulário compartilhado. É produzido por um consórcio aberto e publicado como uma especificação aberta. Em vez de ser um produto que você instala, é um modelo para o qual você mapeia seus sistemas.

Para quem é o CIM?

É voltado para arquitetos de dados corporativos, engenheiros de integração e ETL, fornecedores de aplicações e plataformas, e contribuidores de código aberto. Qualquer pessoa que precise conectar múltiplos sistemas em nuvem e on-premise com esquemas diferentes é um usuário potencial. Fornecedores se beneficiam porque um modelo compartilhado reduz o trabalho customizado necessário para integrar com seus produtos.

Como o CIM é governado e licenciado?

O CIM é de código aberto como parte da Joint Development Foundation, que opera sob a Linux Foundation. Isso fornece uma estrutura de governança neutra em relação ao fornecedor e orientada a especificações. Essa estrutura visa manter o modelo aberto a contribuições e independente do controle de qualquer fornecedor único.

Como o CIM difere do modelo de dados nativo de um fornecedor?

O modelo nativo de um fornecedor é otimizado para o produto e ecossistema desse fornecedor; adotá-lo como seu hub de integração tende a criar lock-in. O CIM foi projetado para ser agnóstico a aplicações, portanto, nenhuma plataforma única define o vocabulário. A contrapartida é que o CIM exige governança e acordo entre as equipes, enquanto um modelo de fornecedor está pronto para uso dentro das ferramentas desse fornecedor.

Ainda preciso escrever mapeamentos se usar o CIM?

Sim. Todo sistema de origem ainda precisa de um mapeamento para o modelo compartilhado. A vantagem é que você escreve um mapeamento por sistema para o CIM, em vez de uma tradução separada para cada par de sistemas. Isso transforma o esforço de mapeamento combinatório em um esforço aproximadamente linear e fornece um contrato estável que sobrevive a mudanças em sistemas individuais.

Como começo a adotar o CIM?

Comece com uma única integração de alta dor e bem delimitada em uma Área de Assunto (Subject Area). Faça o inventário dos esquemas de origem, mapeie cada sistema para o domínio CIM, defina uma política de extensão e governança e trate os mapeamentos como artefatos versionados. Assim que o primeiro domínio provar seu valor, expanda domínio por domínio, reutilizando os padrões e a governança que você estabeleceu.

Leitura adicional

• Linux Foundation — Wikipedia
• Linux Foundation — Wikipedia