Recursos

A página de Recursos é o ponto de entrada para quem deseja compreender, adotar ou contribuir com o Cloud Information Model (CIM). O CIM é um modelo de dados de código aberto e independente de aplicativos — administrado pela Linux Foundation — que define um vocabulário compartilhado de entidades de negócios para que sistemas em nuvem e locais possam trocar dados sem que cada equipe de integração reinvente seu próprio esquema. Esta página reúne os artefatos necessários para avaliar o CIM, os formatos que ele suporta, os repositórios onde os modelos residem e os canais para se envolver.

Principais Conclusões

• O CIM é um modelo de dados compartilhado e neutro em relação ao fornecedor, não um produto ou banco de dados — ele descreve entidades, atributos e relacionamentos para os quais vários aplicativos podem mapear.
• Os principais ativos técnicos residem na organização do CIM no GitHub, onde as definições do modelo e as ferramentas são versionadas e licenciadas abertamente.
• O CIM é expresso em vários formatos padrão para que possa ser consumido por diferentes cadeias de ferramentas, em vez de prender você a uma única serialização.
• As páginas de apresentação, FAQ e notícias são a maneira mais rápida de construir um caso de negócio e responder às perguntas das partes interessadas antes de um mergulho técnico aprofundado.
• A contribuição acontece por meio dos repositórios do GitHub e do formulário web do contribuidor; o modelo evolui através da revisão da comunidade, e não do roteiro de um único fornecedor.

O que Realmente é o Cloud Information Model

O CIM é melhor compreendido como um modelo canônico: uma representação neutra e acordada de conceitos de negócios — clientes, contas, pedidos, produtos, contatos e os relacionamentos entre eles — que fica entre os sistemas que você já opera. Em vez de forçar cada aplicativo a falar o dialeto de todos os outros aplicativos, você mapeia cada sistema para o CIM uma única vez, e o CIM torna-se o ponto de intercâmbio.

Este é o mesmo padrão arquitetônico que apareceu repetidamente na integração empresarial: um esquema canônico hub-and-spoke em vez de uma malha de mapeamentos ponto a ponto. Está conceitualmente relacionado a esforços como o OASIS Universal Business Language (UBL) para documentos, o Open Applications Group Integration Specification (OAGIS) para mensagens de negócios e o schema.org para vocabulários em escala web. A ênfase distintiva do CIM é que ele é independente de aplicativos e projetado para a realidade de nuvem e local (cloud-plus-on-premises) em que a maioria das empresas realmente opera.

O ganho prático é a redução da proliferação de mapeamentos (mapping sprawl). Se você tiver n sistemas e cada um precisar falar com todos os outros, você enfrentará a ordem de n² mapeamentos. Introduza um modelo canônico e o trabalho cai para cerca de n mapeamentos — um por sistema para o modelo compartilhado. Essa redução é o principal argumento econômico para a adoção do CIM.

Apresentação do CIM

A Apresentação do CIM é o artefato inicial recomendado para qualquer pessoa que esteja construindo um caso internamente. Ela foi projetada para ser exibida a públicos mistos — arquitetos, líderes de governança de dados e patrocinadores de negócios — e aborda a motivação para um modelo compartilhado, o escopo do que o CIM define e como ele se encaixa em um cenário de integração existente.

Use-a da seguinte maneira:

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

• Para executivos e patrocinadores: comece com o problema da proliferação de mapeamentos e o argumento da neutralidade do fornecedor. A apresentação enquadra o CIM como redução de risco, não como uma substituição total (rip-and-replace).
• Para arquitetos e engenheiros: use-a para definir o contexto e, em seguida, mova-se imediatamente para os repositórios do GitHub para as definições reais do modelo.
• Para partes interessadas em governança e conformidade: use-a para abrir a conversa sobre propriedade, versionamento e como as alterações do modelo são revisadas.

Uma apresentação é um ponto de partida para conversa, não uma especificação. Trate-a como a rampa de acesso e trate os repositórios como a fonte da verdade.

Formatos do CIM

O CIM suporta deliberadamente vários padrões e formatos, em vez de uma única serialização proprietária. Isso é importante porque as cadeias de ferramentas corporativas são heterogêneas: sua ferramenta de modelagem, sua plataforma ETL, seu gateway de API e seu gerador de documentação podem preferir representações diferentes.

Famílias de formatos comumente relevantes neste espaço incluem:

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

• Notações conceituais e de entidade-relacionamento para revisão humana e workshops de design.
• Representações de esquema baseadas em JSON para consumo de APIs e aplicativos.
• Representações em estilo de ontologia e RDF para casos de uso de semântica e grafos de conhecimento.
• Mapeamentos relacionais e tabulares para pipelines de warehouse e ETL.

O princípio de design é a portabilidade: um modelo expresso em um formato aberto pode ser transformado, comparado (diffed), controlado por versão e validado por ferramentas padrão. Ao avaliar o CIM para sua organização, a pergunta a ser feita não é “qual formato ele usa?”, mas “posso fazer o round-trip do meu modelo através dos formatos que minhas ferramentas exigem sem perdas?”. Se uma conversão de formato eliminar silenciosamente a cardinalidade de um relacionamento ou restrições de atributos, isso é um risco real de integração que vale a pena testar antecipadamente.

Como decidir qual formato adotar

Use isto como um guia rápido de decisão:

Se o seu consumidor principal for…	Favoreça uma representação que…	Cuidado com…
Desenvolvedores de aplicativos/API	Esquemas estilo JSON	Perda de semântica de relacionamento em JSON plano
Equipes de Data Warehouse / ETL	Mapeamentos relacionais ou tabulares	Relacionamentos muitos-para-muitos que necessitam de tabelas ponte
Equipes de grafo de conhecimento / semântica	Representações RDF/ontologia	Maturidade de ferramentas e desempenho de consulta
Workshops de design e governança	Notação conceitual/ER	Desvio entre o diagrama e o modelo legível por máquina

A última linha é o modo de falha mais comum: as equipes mantêm um diagrama bonito que não corresponde mais ao modelo versionado. Mantenha o diagrama gerado a partir de, ou pelo menos reconciliado com, os artefatos do repositório.

CIM nas Notícias

A seção “CIM nas Notícias” agrega a cobertura externa — anúncios, comentários de analistas e artigos da comunidade — para que você possa ver como o CIM está sendo recebido fora do próprio projeto. Isso é útil por dois motivos.

Primeiro, ele fornece validação de terceiros. Quando você propõe a adoção de um modelo compartilhado, citar a cobertura independente é mais persuasivo do que citar o marketing do próprio projeto. Em segundo lugar, revela histórias de adoção e padrões de integração do mundo real que a documentação principal pode não cobrir.

Leia a cobertura noticiosa de forma crítica. Os anúncios geralmente descrevem a intenção e a parceria, em vez do uso em produção implantado. Distinga entre “a organização X juntou-se ao esforço” e “a organização X executa o CIM em produção para o sistema Y”. O primeiro é comum; o segundo é a evidência que importa para uma decisão de construir versus adotar.

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

Organização CIM no GitHub

A organização no GitHub é onde reside a substância. Para os leitores técnicos, este é o destino que mais importa. Espere encontrar:

• Definições de modelo — as entidades, atributos, relacionamentos e restrições que constituem o CIM.
• Ferramentas — scripts e utilitários para validar, transformar e gerar artefatos a partir do modelo.
• Versionamento e histórico — o histórico de commits que mostra como o modelo evoluiu e por quê.
• Issues e discussões — o registro de trabalho de propostas, perguntas e decisões.

Alguns hábitos práticos tornam os repositórios muito mais úteis:

• Fixar em um lançamento ou tag em vez de rastrear o branch padrão, para que seus mapeamentos não mudem no meio do projeto.
• Leia o histórico de commits das entidades de seu interesse antes de adotá-las. Um campo que mudou três vezes em um ano sinaliza uma área instável.
• Verifique a licença em cada repositório. Projetos de código aberto às vezes misturam licenças entre ferramentas e conteúdo do modelo.
• Abra issues para ambiguidades. Se a cardinalidade de um relacionamento não estiver clara, essa ambiguidade afetará todas as equipes a jusante; levantá-la antecipadamente melhora o modelo para todos.

Para organizações com requisitos rigorosos de cadeia de suprimentos ou proveniência, revise os repositórios da mesma forma que revisaria qualquer dependência de terceiros: licença, atividade de manutenção, diversidade de contribuidores e cadência de lançamento. Um modelo que depende de um único mantenedor apresenta um perfil de risco diferente de um com amplo apoio organizacional.

Nossa escolha: Workato — iPaaS baseado em automação que as equipes de negócios podem realmente desenvolver.

Perguntas Frequentes

O Cloud Information Model é um produto que posso comprar?

Não. O CIM é um modelo de dados de código aberto — um conjunto de definições e artefatos de suporte — administrado pela Linux Foundation. Você o adota mapeando seus sistemas para ele e usando as definições de modelo publicadas; não há taxa de licença para o modelo em si. Os fornecedores podem criar produtos que suportem ou incorporem o CIM, mas o modelo não é uma oferta comercial.

Preciso substituir meus sistemas existentes para usar o CIM?

Não, e esse é o ponto. O CIM foi projetado para situar-se entre sistemas como um modelo de intercâmbio canônico. Você mantém seus aplicativos, bancos de dados e warehouses, e cria mapeamentos de cada sistema para o CIM. Isso é incremental: você pode começar com uma única integração de alto valor e expandir a cobertura ao longo do tempo.

Qual formato devo usar para consumir o CIM?

Depende do seu consumidor. Equipes de API e de aplicativos geralmente preferem representações de esquema no estilo JSON; equipes de warehouse e ETL preferem mapeamentos relacionais ou tabulares; equipes de semântica e de grafos de conhecimento preferem representações RDF/ontologia. O teste principal é o round-tripping sem perdas — verifique se a conversão entre formatos preserva relacionamentos e restrições antes de confirmar.

Como o CIM se relaciona com outros padrões como UBL ou OAGIS?

Eles ocupam espaços de problemas adjacentes. UBL e OAGIS concentram-se fortemente em documentos e mensagens comerciais trocadas entre as partes, enquanto o CIM enfatiza um modelo de entidade compartilhado para o qual os aplicativos são mapeados. Na prática, eles podem ser complementares: um modelo de entidade canônico pode informar como você preenche os padrões de documentos. Avalie a sobreposição para seus casos de uso específicos, em vez de presumir que um substitui o outro.

Como posso contribuir para o CIM?

A contribuição flui principalmente por meio da organização CIM no GitHub — issues, pull requests e discussões — junto com o formulário web para contribuidores vinculado a este site. Como o modelo é governado pela comunidade, as propostas são revisadas abertamente. Comece aos poucos: esclareça uma definição ambígua ou adicione um atributo ausente com uma justificativa clara, e interaja com os mantenedores antes de propor grandes mudanças estruturais.

Por onde um stakeholder não técnico deve começar?

Comece com a Apresentação do CIM e o FAQ e, em seguida, dê uma olhada em “CIM nas Notícias” para obter contexto de terceiros. Eles fornecem a motivação e o vocabulário sem exigir que você leia as definições do modelo. Traga a equipe técnica assim que tiver uma integração candidata para pilotar, e deixe-os trabalhar a partir dos repositórios do GitHub.

Envolvendo-se e Leituras Adicionais

A adoção de um modelo compartilhado é tanto um esforço organizacional quanto técnico. As iniciativas de CIM mais bem-sucedidas tendem a começar com uma única integração bem delimitada — onde dois sistemas atualmente exigem um mapeamento personalizado frágil — provam a abordagem do modelo canônico e, então, expandem. A governança importa: decida antecipadamente quem é o proprietário dos seus mapeamentos CIM internos, como as atualizações de versão do modelo são tratadas e como os conflitos entre definições de negócios são resolvidos.

Para obter informações sobre o contexto de administração e governança aberta, consulte a Linux Foundation na Wikipédia. Para trabalhos de padrões relacionados, a OASIS Universal Business Language e o schema.org são pontos de referência úteis ao comparar abordagens de modelos canônicos. Para aprofundar-se na modelagem semântica, o World Wide Web Consortium (W3C) publica as especificações RDF e OWL que sustentam as representações no estilo ontologia.

Use a navegação neste site para acessar a apresentação, o FAQ, a documentação de formatos, o resumo de notícias e os repositórios do GitHub — e use o formulário web para contribuidores quando estiver pronto para participar da modelagem do modelo.