Envolva-se

Fundado em 2019 sob a égide da Linux Foundation, o Cloud Information Model (CIM) é tanto uma aliança de membros quanto uma comunidade. Juntos, colaborando em Grupos de Trabalho, os membros definem e utilizam um modelo de dados aberto comum, influenciam padrões existentes e futuros e constroem soluções abertas para resolver problemas comuns.

O CIM existe porque os dados corporativos estão fragmentados em dezenas de aplicativos, cada um com seu próprio esquema proprietário, convenções de nomenclatura e semântica. Um cliente no Salesforce, um cliente no SAP e um cliente em um sistema de faturamento interno são todos “clientes” — mas raramente concordam sobre o que um cliente é, quais atributos são autoritativos ou como os relacionamentos entre clientes, pedidos e produtos devem ser expressos. A resposta do CIM é um modelo compartilhado e agnóstico à aplicação que qualquer sistema pode mapear, de modo que o trabalho de integração se torne um exercício de mapeamento em vez de um projeto de tradução personalizado.

Principais Conclusões

• O CIM é um projeto da Linux Foundation (fundado em 2019) que publica um modelo de dados aberto e baseado em padrões, traduzido para múltiplos formatos para que sistemas heterogêneos possam adotá-lo.
• A participação é escalonada: Membros de Direção (Steering Members), Membros Contribuidores e a comunidade CIM mais ampla, com direitos progressivamente mais amplos à medida que você sobe de nível.
• O único Grupo de Trabalho atual define novas Áreas Temáticas (Subject Areas), mapeamentos e requisitos de API — é aqui que acontece o trabalho técnico substantivo.
• A contribuição não é apenas código: propor Áreas Temáticas, participar de enquetes de consenso e ingressar em Grupos de Trabalho são todas formas primordiais de moldar o padrão.
• O modelo é deliberadamente neutro em relação ao formato, o que permite que consumidores relacionais, de grafos e orientados a API compartilhem uma única definição canônica.

Por que um Modelo de Dados Compartilhado é Importante

A maior parte da dor da integração é semântica, não técnica. Pipelines de ETL, plataformas iPaaS e gateways de API são maduros; o que falha é a camada de significado. Quando dois sistemas discordam sobre se “conta” significa uma entidade de faturamento ou uma hierarquia corporativa, cada relatório, junção e reconciliação a jusante herda essa ambiguidade.

Um modelo canônico como o CIM aborda isso fornecendo um ponto de referência neutro. Em vez de mapear N sistemas entre si (um problema N×N), cada sistema mapeia uma vez para o modelo canônico (um problema N×1). Este é o mesmo princípio arquitetônico por trás de padrões como o Common Information Model usado no setor de energia (IEC 61970/61968) e os recursos HL7 FHIR usados na saúde — modelos canônicos específicos de domínio que permitem a interoperabilidade de sistemas construídos de forma independente.

O escopo do CIM é mais amplo e horizontal: ele visa as entidades de negócio comuns — clientes, produtos, pedidos, fornecedores e os relacionamentos entre eles — que aparecem em sistemas de CRM, ERP, comércio e cadeia de suprimentos. O objetivo não é substituir os modelos nativos de qualquer um desses sistemas, mas situar-se acima deles como um vocabulário compartilhado.

Escopo do Grupo de Trabalho

Desenvolvemos o Cloud Information Model (CIM) com uma abordagem baseada em padrões e o traduzimos para múltiplos formatos. Essa abordagem permite que empresas com diversas tecnologias adotem o CIM. Também capacita os contribuidores e promove o crescimento de um ecossistema CIM maior.

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

Concretamente, “múltiplos formatos” significa que o mesmo modelo subjacente pode ser consumido por diferentes cadeias de ferramentas — por exemplo, como uma definição de esquema para armazenamentos relacionais ou de documentos, como um grafo de entidades e relacionamentos e como a base para contratos de API. Uma equipe que usa um warehouse relacional, uma equipe que usa um banco de dados de grafos e uma equipe que constrói serviços REST ou GraphQL podem todas trabalhar a partir de uma única fonte da verdade, em vez de três definições divergentes.

Esta neutralidade de formato é uma escolha deliberada de design com compensações reais:

• Pró: Nenhuma ferramenta de um único fornecedor é privilegiada, portanto a adoção não depende da compra de uma plataforma específica.
• Pró: O modelo pode evoluir independentemente de qualquer formato de serialização.
• Contra: Os contribuidores devem pensar cuidadosamente sobre quais construções são verdadeiramente canônicas versus artefatos de um formato específico.
• Contra: As ferramentas para traduzir entre formatos devem ser mantidas, e o processo de ida e volta (round-tripping) nem sempre é isento de perdas.

Para arquitetos que avaliam se devem adotar o CIM, a questão prática é se a sua superfície de integração é dominada por entidades de negócio compartilhadas. Se a maioria dos seus mapeamentos for pontual e específica de um domínio, um modelo canônico adiciona sobrecarga. Se você mapeia repetidamente o mesmo pequeno grupo de entidades em muitos sistemas, a redução N×1 se paga.

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

Cloud Information Model Working Group

Atualmente, o CIM possui um único Grupo de Trabalho que atua na definição de novas Áreas Temáticas, mapeamentos e requisitos de APIs.

Uma Área Temática (Subject Area) é uma fatia coerente do modelo — por exemplo, um agrupamento de entidades e relacionamentos em torno de um domínio de negócio. Propor uma Área Temática é uma das contribuições mais impactantes que um membro pode fazer, pois determina o que o padrão cobrirá a seguir. Mapeamentos conectam Áreas Temáticas a sistemas e formatos do mundo real; requisitos de API capturam o que os consumidores precisam de serviços construídos sobre o modelo.

Se você está considerando ingressar no Grupo de Trabalho, uma maneira útil de decidir onde contribuir é perguntar:

1. Quais entidades causam mais retrabalho de integração em sua organização? Essas são candidatas a propostas de Áreas Temáticas.
2. Onde seus sistemas já concordam e onde eles divergem silenciosamente? A divergência é onde os mapeamentos agregam mais valor.
3. O que seus consumidores a jusante realmente precisam de uma API? Isso molda os requisitos de API.

Como existe atualmente um Grupo de Trabalho, o caminho prático para um novo colaborador é geralmente juntar-se a ele e propor uma Área Temática, em vez de criar um novo grupo. Propor um novo Grupo de Trabalho é um direito reservado aos níveis superiores e deve ser reservado para áreas de trabalho genuinamente distintas que, de outra forma, sobrecarregariam o grupo existente.

Níveis e Benefícios de Associação

A participação no CIM está estruturada em níveis, cada um com direitos progressivamente mais amplos. A tabela abaixo resume os benefícios conforme publicados pelo CIM.

Benefício	Membro Diretor	Colaborador	Comunidade CIM
Usar Versões do Modelo CIM	✓	✓	✓
Manter-se atualizado sobre o progresso e as inovações do CIM	✓	✓	✓
Contribuir com ideias para o Consórcio CIM	✓	✓	✓
Pode propor uma Área Temática	✓	✓	✓
Acesso a recursos restritos e privados	✓	✓
Elegível para participar de um Grupo de Trabalho	✓	✓
Contribuir para Grupos de Trabalho	✓	✓
Propor novos Grupos de Trabalho	✓	✓
Contabilizado para o quórum mínimo de apoio de uma Área Temática	✓	✓
Participar de pesquisas de consenso	✓	✓
Contribui para o Roadmap do CIM	✓	✓
Direciona a direção estratégica geral do CIM	✓
Elegível para integrar o Comitê Diretor	✓
Elegível para um cargo de Presidente de Grupo de Trabalho	✓
Elegível para votar a adoção de conteúdo como parte do Padrão CIM	✓
Pode recorrer de questões técnicas	✓
Pode recorrer de questões processuais	✓

*Candidatura a Membro Diretor — Membros Colaboradores podem candidatar-se à Membro Diretor.

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

Como ler os níveis

Os níveis mapeiam um padrão familiar de governança de código aberto usado em projetos da Linux Foundation: uma comunidade ampla que pode usar os resultados e contribuir com ideias, um nível de colaborador que realiza o trabalho prático e um nível de direção que detém a estratégia e a adoção formal. A distinção que mais importa na prática:

• Comunidade CIM é o ponto de entrada. Você pode adotar modelos lançados e contribuir com ideias sem uma função formal de trabalho. Isso é apropriado se você estiver avaliando o CIM para um projeto ou quiser influenciar a direção informalmente.
• Colaborador é onde reside a influência técnica. Participar de um Grupo de Trabalho, contribuir para ele, propor Áreas Temáticas e participar de pesquisas de consenso, tudo isso está aqui. Se o seu objetivo é moldar o padrão em vez de apenas consumi-lo, este é o nível a ser visado.
• Membro Diretor detém direitos de governança: direção estratégica, elegibilidade para o Comitê Diretor, elegibilidade para Presidente de Grupo de Trabalho e o voto formal para adotar conteúdo como parte do Padrão CIM. Membros Colaboradores podem candidatar-se à Membro Diretor.

Um detalhe sutil, mas importante: ser “contabilizado para o quórum mínimo de apoio de uma Área Temática” é um direito de Colaborador ou superior. As regras de quórum existem para que uma Área Temática não seja adotada com base na força de um único participante — uma salvaguarda de governança comum a órgãos de normalização baseados em consenso. Se a sua organização se preocupa com a adoção de uma determinada Área Temática, ter a participação no nível de Colaborador é o que permite que você conte para esse limite.

Como se Envolver: Um Caminho Prático

Se você é novo no CIM, uma sequência sensata é:

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

1. Comece como Comunidade CIM. Revise os modelos lançados e o FAQ, e identifique onde as entidades dos seus sistemas se sobrepõem às Áreas Temáticas do CIM.
2. Contribua com ideias. Mesmo no nível de comunidade, você pode propor ideias ao Consórcio CIM — uma forma de baixo comprometimento para testar se o seu caso de uso repercute.
3. Mude para Colaborador se quiser realizar o trabalho. Isso desbloqueia a participação em Grupos de Trabalho, propostas de Áreas Temáticas e pesquisas de consenso.
4. Candidate-se a Membro Diretor se a sua organização quiser ajudar a definir a direção e realizar votos formais de adoção.

Especificamente para contribuidores de código aberto, a neutralidade de formato do modelo significa que há espaço para contribuir com ferramentas — tradutores de formato, validadores, geradores de mapeamento — juntamente com o próprio conteúdo do modelo. Para fornecedores de plataformas e aplicativos, mapear o esquema do seu produto para o CIM é uma forma de reduzir o custo de integração que seus clientes pagam, o que geralmente é um diferencial competitivo.

Governança, Padrões e Recursos

O CIM segue uma abordagem baseada em padrões, o que implica um processo definido para propor, revisar e adotar conteúdo. A presença de direitos formais de “recurso” — técnicos e processuais — no nível de Direção é uma marca registrada da governança de padrões maduros. Isso significa que as disputas têm um caminho de resolução definido, em vez de serem resolvidas informalmente.

Isso reflete como as organizações de padrões estabelecidas operam. A Linux Foundation hospeda muitos desses projetos e fornece a estrutura jurídica e de governança — marcas registradas, PI e políticas antitruste — que permite que concorrentes colaborem em infraestrutura compartilhada. Se você estiver avaliando o CIM para adoção empresarial, a afiliação à Linux Foundation é um sinal significativo: significa que o modelo é governado por uma fundação neutra, em vez de pertencer a um único fornecedor, o que reduz o risco de uma futura mudança de licenciamento ou de direção.

Informações Relacionadas

• Perguntas Frequentes
• Taxas de Adesão
• Lista de Membros Atuais da SteerCo
• Formulário Web do Colaborador
• Recursos do Modelo CIM
• Apresentação CIM
• Formatos CIM
• CIM nas Notícias
• Repositórios GitHub
• Blog de Notícias
• Contato

Perguntas Frequentes

O que é o Cloud Information Model?

O Cloud Information Model (CIM) é um modelo de dados aberto e uma comunidade de membros fundada em 2019 sob a Linux Foundation. Ele define um modelo comum e independente de aplicação de entidades de negócio para que sistemas em nuvem e on-premises possam interoperar por meio de semânticas compartilhadas, em vez de mapeamentos ponto a ponto personalizados.

Quem pode aderir ao CIM e quanto custa?

O CIM possui três níveis de participação: Membro do Comitê Diretor (Steering Member), Colaborador e Comunidade CIM. O nível de comunidade é o ponto de entrada mais amplo, enquanto os Membros Colaboradores podem solicitar a adesão como Membro do Comitê Diretor. As taxas de adesão são publicadas separadamente pelo CIM; portanto, consulte a página de Taxas de Adesão para obter os valores atuais em vez de presumir um custo.

O que é uma Subject Area no CIM?

Uma Subject Area (Área Temática) é uma fatia coerente do modelo que abrange um conjunto de entidades e relacionamentos relacionados. Propor uma Subject Area é um direito de nível de Colaborador e uma das formas mais diretas de influenciar o que o padrão abrange. As Subject Areas também estão sujeitas a um quórum mínimo de apoio, o que impede a adoção com base em um único participante.

Preciso ser um Membro do Comitê Diretor para contribuir?

Não. Membros Colaboradores podem ingressar em Grupos de Trabalho, contribuir com eles, propor Subject Areas e participar de enquetes de consenso. A adesão ao Comitê Diretor adiciona direitos de governança, como direção estratégica, elegibilidade para o Comitê Diretor e o voto formal para adotar conteúdo como parte do Padrão CIM.

Como o CIM se relaciona com outros padrões de dados?

O CIM é um modelo horizontal e intersetorial focado em entidades de negócio comuns, em contraste com modelos canônicos específicos de domínio, como o Common Information Model do setor de energia (IEC 61970/61968) ou o HL7 FHIR da saúde. Seu design neutro em relação ao formato permite que ele complemente, em vez de substituir, os modelos nativos dos sistemas que você já utiliza.

Por que a neutralidade de formato é importante para a adoção?

Porque permite que equipes com diferentes pilhas tecnológicas — data warehouses relacionais, bancos de dados de grafos e serviços de API — consumam uma única definição canônica em vez de manter esquemas divergentes. A contrapartida é que as ferramentas de tradução devem ser mantidas e a conversão de ida e volta (round-tripping) entre formatos nem sempre é isenta de perdas; portanto, as equipes devem validar os mapeamentos em relação às suas necessidades reais de integração.

Leitura adicional

• Working group — Wikipédia
• Linux Foundation — Wikipédia