Modelo de Informação em Nuvem

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

Principais Conclusões

• CIM é um modelo de dados aberto e independente de aplicativos — um vocabulário compartilhado de conceitos de negócios (clientes, pedidos, produtos e assim por diante) que permite que diferentes sistemas em nuvem e locais troquem dados sem mapeamentos ponto a ponto personalizados.
• Ele existe para resolver um problema específico e caro: cada aplicativo vem com seu próprio modelo de dados, então as equipes de integração acabam escrevendo e mantendo códigos de tradução personalizados que são frágeis e retardam a inovação.
• É governado como um padrão aberto, produzido por um consórcio e disponibilizado como código aberto sob a Joint Development Foundation, parte da Linux Foundation — para que qualquer pessoa possa contribuir, revisar e adotá-lo.
• O conteúdo é organizado em Áreas Temáticas (domínios), cada uma representando um conceito de negócio importante, com designs publicados em vários formatos, incluindo diagramas de exemplo.
• CIM é um modelo, não um produto. Ele define significado e estrutura; você ainda escolhe como mapear, armazenar e mover dados em seus próprios sistemas.

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 aplicativos nativos da nuvem.

Para acelerar a transformação digital e oferecer engajamentos personalizados aos clientes em todos os canais, muitas empresas adotam vários aplicativos em nuvem e locais. Cada um 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. Disponibilizado como código aberto como parte da Joint Development Foundation (sob a Linux Foundation), damos as boas-vindas a todo e qualquer contribuidor.

Por que os Modelos de Dados Específicos de Aplicativos Falham

O problema central que o CIM aborda não é que qualquer aplicativo individual tenha um modelo de dados ruim. A maioria é perfeitamente razoável dentro de seus próprios limites. O problema é a explosão combinatória que acontece quando você conecta muitos deles.

Considere uma pilha corporativa típica: um CRM, um ERP, uma plataforma de automação de marketing, um suporte técnico, um data warehouse e algumas ferramentas SaaS de linha de negócio. Se cada sistema tiver sua própria noção de “cliente”, “conta”, “pedido” e “produto”, então cada par de sistemas que precise compartilhar dados exigirá seu próprio mapeamento. O número de integrações cresce aproximadamente com o quadrado do número de sistemas, e cada mapeamento é uma pequena peça de lógica, não documentada e sem dono, que alguém deve manter para sempre.

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

Os sintomas são familiares para qualquer pessoa que já gerenciou uma prática de integração:

• Desvio semântico. “Cliente” no CRM significa uma entidade de faturamento; no suporte técnico, significa uma pessoa que abre tickets. A mesma palavra, dois significados, silenciosamente reconciliados por um mapeamento que ninguém lembra de ter escrito.
• Pipelines frágeis. Um fornecedor renomeia um campo ou altera um enum, e um job de ETL falha às 2h da manhã porque o mapeamento foi codificado rigidamente com base na estrutura antiga.
• Esforço duplicado. Duas equipes constroem independentemente traduções quase idênticas entre os mesmos dois sistemas porque não há uma referência compartilhada para consultar.
• Vendor lock-in por dados. Migrar de uma plataforma é caro não por causa do software, mas por causa da lógica de tradução acumulada vinculada ao seu esquema.

Um modelo compartilhado e independente de aplicação ataca a causa raiz: em vez de mapeamentos N-para-N, cada sistema mapeia uma vez para um modelo comum, e o modelo comum carrega o significado.

O que Realmente Significa “Independente de Aplicativo”

Vale a pena ser preciso quanto à filosofia de design, porque “agnóstico” é frequentemente usado de forma imprecisa.

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

Um modelo independente de aplicativo não pertence nem é otimizado para o produto de nenhum fornecedor individual. Ele descreve conceitos de negócios em termos que seriam reconhecíveis para um especialista no domínio — um cliente, um pedido, um produto, um local — em vez de termos que espelhem as tabelas internas de um aplicativo. Essa neutralidade é o que o torna um hub útil: nenhum participante precisa adotar a visão de mundo de um concorrente para interoperar.

Este é o mesmo instinto arquitetônico por trás de outros padrões de intercâmbio neutros. Assim como o Resource Description Framework (RDF) e o schema.org fornecem à web um vocabulário compartilhado para descrever coisas, e assim como o EDI e, posteriormente, o UBL (Universal Business Language, um padrão OASIS) deram às cadeias de suprimentos um formato compartilhado para transações, o CIM visa fornecer aos aplicativos empresariais um vocabulário compartilhado para suas principais entidades de negócio. A diferença é o escopo e a modernidade: o CIM visa o mundo conectado, orientado por APIs, em nuvem e local, em vez da troca de arquivos em lote.

Um modelo mental útil é o padrão de modelo de dados canônico de integração empresarial, popularizado em Enterprise Integration Patterns de Gregor Hohpe e Bobby Woolf. O CIM é, na verdade, um modelo canônico mantido colaborativamente — o “hub” em uma topologia de integração hub-and-spoke — mas que é aberto, versionado e compartilhado entre organizações, em vez de inventado privadamente dentro de uma única empresa.

Como o CIM Está Organizado: Áreas Temáticas e Domínios

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.

Na prática, isso significa que você deve pensar no CIM como uma biblioteca de modelos relacionados em vez de um único esquema monolítico. As Áreas Temáticas típicas agrupam-se em torno de preocupações de negócio reconhecíveis — por exemplo, partes e contas, produtos e catálogos, pedidos e transações, e os relacionamentos que os unem. Como cada área é publicada com diagramas e definições legíveis por máquina, equipes diferentes podem adotar áreas diferentes em momentos diferentes, sem esperar que todo o modelo esteja completo.

Algumas implicações práticas decorrem desta estrutura:

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

• Adote de forma incremental. Você não precisa mapear toda a sua empresa para o CIM no primeiro dia. Comece com a Área Temática que causa mais problemas — geralmente o domínio do cliente ou do pedido — e expanda.
• Estenda em vez de bifurcar. Quando o CIM não possui um conceito de que você precisa, o modelo aberto é projetado para ser estendido. Contribuir com uma extensão de volta é preferível a manter um fork privado, porque um fork diverge e perde o benefício de interoperabilidade.
• Trate os diagramas como documentação, não como a fonte da verdade. Os diagramas de exemplo são para humanos; as definições legíveis por máquina são o que suas ferramentas devem consumir.

CIM no Cenário de Integração: Como Decidir

O CIM é uma opção entre várias para domar a complexidade da integração. Escolher bem requer combinar a ferramenta com o problema. A tabela abaixo contrasta as principais abordagens que um arquiteto de dados corporativos normalmente avalia.

Abordagem	O que é	Melhor quando	Principal trade-off
Mapeamento ponto a ponto	Código personalizado traduzindo diretamente entre dois sistemas	Apenas dois sistemas, esquemas estáveis, horizonte curto	Não escala; explosão N-para-N; frágil
Modelo canônico (ex: CIM)	Um modelo compartilhado e neutro para o qual cada sistema mapeia uma vez	Muitos sistemas, cross-vendor, integração de longa duração	Esforço inicial de modelagem; governança necessária
Conectores iPaaS de fornecedor	Conectores pré-construídos de uma plataforma de integração	Pares SaaS comuns, velocidade acima do controle	Semântica específica do conector; potencial lock-in
Padrões de intercâmbio da indústria (EDI, UBL, HL7, etc.)	Formatos de mensagens específicos de domínio	Verticais regulamentadas ou bem estabelecidas	Escopo estreito; frequentemente orientado a lote
Virtualização / federação de dados	Consulta entre fontes sem centralização	Analytics, acesso predominantemente de leitura	Não resolve conflitos semânticos por si só

A heurística de decisão é direta: se você tiver mais do que um punhado de sistemas que devem concordar sobre o significado de entidades compartilhadas, e esses sistemas vierem de fornecedores diferentes, um modelo canônico se paga. Se você tiver dois sistemas e não tiver planos de adicionar mais, o ponto a ponto é adequado. Se a sua necessidade for puramente analítica e somente leitura, a federação pode ser suficiente — mas observe que a federação desloca o problema semântico em vez de resolvê-lo.

O CIM é complementar, e não um substituto, das ferramentas ao seu redor. Um pipeline ETL ou ELT (construído com algo como Apache Airflow, dbt ou uma plataforma comercial) ainda faz a movimentação; o CIM define o que os dados significam assim que chegam. Um message broker como o Apache Kafka ainda faz o transporte; o CIM define a forma dos eventos. O modelo é o contrato; o ferramental é o encanamento.

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

Governança, Licenciamento e Por Que a Fundação Importa

O CIM é de código aberto como parte da Joint Development Foundation, que opera sob a Linux Foundation. Este não é um detalhe trivial — é fundamental para que uma empresa possa construir com segurança sobre o CIM.

A Linux Foundation é um lar neutro bem estabelecido para projetos colaborativos de código aberto, e a Joint Development Foundation fornece uma estrutura legal leve para o desenvolvimento colaborativo de padrões e especificações. Hospedar o CIM lá significa:

• Administração neutra. Nenhum fornecedor controla o modelo, portanto, adotá-lo não significa adotar o roadmap de um concorrente.
• Contribuição aberta. Qualquer pessoa — fornecedores, empresas, colaboradores individuais — pode propor alterações, e o processo é transparente.
• Licenciamento previsível. Especificações hospedadas por fundações geralmente trazem termos projetados para adoção ampla e favorável a royalties, o que é extremamente importante para as equipes jurídicas e de compras que avaliam um padrão.

Para um arquiteto que defende o caso internamente, esta história de governança é muitas vezes tão importante quanto o conteúdo técnico. “É um padrão aberto sob a Linux Foundation” responde às perguntas que matam a adoção de padrões: Quem o controla? O que acontece se um fornecedor sair? Podemos contribuir com nossas extensões?

Primeiros Passos: Um Caminho Prático de Adoção

Adotar um modelo compartilhado é tanto um exercício organizacional quanto técnico. Uma sequência pragmática seria a seguinte:

1. Inventarie suas entidades compartilhadas. Identifique os conceitos de negócio que aparecem em mais de um sistema — geralmente cliente, produto, pedido e local. Estes são seus candidatos.
2. Escolha uma Área Temática e uma integração. Escolha a integração de maior dor e menor raio de impacto para provar o modelo. Um único pipeline de relatórios ou a integração de um novo aplicativo é o ideal.
3. Mapeie cada sistema para o CIM uma vez. Construa a tradução de cada sistema de origem para a representação CIM, e do CIM para cada destino. Resista à tentação de mapear sistema-para-sistema diretamente.
4. Documente suas extensões. Onde o CIM não cobrir um conceito, registre a extensão explicitamente e considere contribuí-la de volta.
5. Estabeleça a propriedade. Um modelo canônico sem um administrador decai. Atribua uma equipe ou função responsável pelos mapeamentos e pelo rastreamento de alterações upstream.
6. Versione e teste. Trate o modelo e seus mapeamentos como artefatos versionados com testes, exatamente como faria com o código de um aplicativo.

O modo de falha mais comum é tratar o CIM como um exercício de modelagem único, em vez de um contrato vivo. As organizações que têm sucesso tratam o modelo da mesma forma que tratam uma API: versionada, testada, com dono definido e evoluída deliberadamente.

Parceiros que contribuem para o CIM

O CIM é um esforço de consórcio, e seu valor cresce com a participação. Os parceiros contribuem com conteúdo de Áreas Temáticas (Subject Areas), revisam propostas e ajudam a moldar a direção do modelo. Como o trabalho é aberto, as contribuições não se limitam a grandes fornecedores — empresas com dores reais de integração e profissionais individuais com expertise no domínio são igualmente bem-vindos.

Entre em contato

Você está interessado em aderir à iniciativa CIM? Ótimo! Sinta-se à vontade para nos enviar um e-mail para obter mais informações. Envie-nos um e-mail.

Perguntas frequentes

O que é o Cloud Information Model (CIM)?

O CIM é um modelo de dados de código aberto e agnóstico a aplicações que fornece um vocabulário compartilhado e baseado em padrões para os conceitos de negócio que as empresas precisam trocar entre aplicações em nuvem e on-premises. É produzido por um consórcio aberto e hospedado sob a Joint Development Foundation, parte da Linux Foundation. Seu objetivo é reduzir o código de mapeamento personalizado que as frágeis integrações ponto a ponto exigem.

O CIM é um produto ou uma especificação?

O CIM é uma especificação — um modelo e um conjunto de definições — não um produto executável. Ele define o significado e a estrutura de entidades compartilhadas; você ainda escolhe suas próprias ferramentas de ETL/ELT, message brokers e armazenamento. Pense nele como o contrato que a sua infraestrutura de integração implementa, e não como a infraestrutura em si.

Qual a diferença entre o CIM e a plataforma de integração de um fornecedor?

Uma plataforma de integração (um iPaaS ou biblioteca de conectores) move dados e geralmente fornece conectores pré-construídos, mas esses conectores codificam a semântica específica do fornecedor. O CIM é neutro e independente de fornecedor, portanto não prende você à visão de mundo de uma única plataforma. Os dois são complementares: você pode usar o CIM como o modelo canônico dentro de qualquer plataforma de integração.

O que são as Áreas Temáticas (Subject Areas) no CIM?

As Áreas Temáticas (também chamadas de domínios) são as unidades organizadoras do modelo, cada uma representando um conceito de negócio principal, como clientes, produtos ou pedidos. Os designs são publicados em múltiplos formatos, incluindo diagramas de exemplo, e espera-se que o conjunto de Áreas Temáticas cresça à medida que o consórcio e a comunidade contribuam com mais conteúdo.

Podemos estender o CIM se ele não cobrir nossos conceitos?

Sim. O CIM foi projetado para ser estendido e, por ser de código aberto sob uma fundação neutra, você pode propor adições por meio do processo de contribuição. Estender o modelo compartilhado e contribuir de volta é fortemente preferível a manter um fork privado, que diverge com o tempo e anula o benefício de interoperabilidade que motivou a adoção do CIM em primeiro lugar.

Quem deve adotar o CIM?

É mais valioso para organizações que operam muitas aplicações de diferentes fornecedores que devem concordar sobre o significado de entidades compartilhadas — a situação clássica para arquitetos de dados empresariais e engenheiros de integração. Fornecedores de aplicações e plataformas também se beneficiam ao alinhar seus esquemas a um modelo neutro, o que torna seus produtos mais fáceis de integrar para os clientes. Se você tiver apenas dois sistemas estáveis, um mapeamento ponto a ponto mais simples pode ser suficiente.

Leitura adicional

• Linux Foundation — Wikipedia
• Joint Development Foundation — Wikipedia
• Enterprise Integration Patterns — Wikipedia
• Resource Description Framework (RDF) — Wikipedia