Cloud Information Model

Välkommen till CIM, en applikationsagnostisk datamodell som förenklar integration och påskyndar innovation.

Viktiga slutsatser

• CIM är en öppen, applikationsagnostisk datamodell — ett delat vokabulär av affärskoncept (kunder, order, produkter och så vidare) som låter olika moln- och lokala system utbyta data utan skräddarsydd punkt-till-punkt-mappning.
• Den finns för att lösa ett specifikt, kostsamt problem: varje applikation levereras med sin egen datamodell, vilket gör att integrationsteam slutar med att skriva och underhålla anpassad översättningskod som är skör och saktar ner innovationen.
• Den styrs som en öppen standard, producerad av ett konsortium och publicerad som öppen källkod under Joint Development Foundation, en del av Linux Foundation — så vem som helst kan bidra, granska och anta den.
• Innehållet är organiserat i ämnesområden (domäner), där varje område representerar ett större affärskoncept, med designer publicerade i flera format inklusive exempeldiagram.
• CIM är en modell, inte en produkt. Den definierar betydelse och struktur; du väljer fortfarande hur du ska mappa, lagra och flytta data i dina egna system.

En ny standard för datainteroperabilitet

CIM produceras av ett öppet konsortium bildat för att leverera en standardbaserad lösning för att koppla samman företagsprodukter. Med CIM kan du skapa sömlösa och skräddarsydda personliga upplevelser över molnbaserade applikationer.

För att påskynda digital transformation och leverera personliga engagemang till kunder över alla kanaler, använder många företag flera moln- och lokala applikationer. Var och en kommer med sin egen datamodell, vilket tvingar utvecklare att bygga, testa och hantera anpassad kod som är nödvändig för att mappa och översätta data mellan olika system. Istället för att påskynda den digitala transformationen bromsar denna process innovationen och leder till sköra integrationer.

CIM är en modern, öppen specifikation som hjälper till att lindra smärtan med att integrera data. CIM tillhandahåller en definierad standard för att enkelt kommunicera mellan olika dataformat. Som öppen källkod inom ramen för Joint Development Foundation (under Linux Foundation), välkomnar vi alla bidragsgivare.

Varför applikationsspecifika datamodeller brister

Kärnproblemet som CIM adresserar är inte att någon enskild applikation har en dålig datamodell. De flesta är helt rimliga inom sina egna gränser. Problemet är den kombinatoriska explosionen som sker när man kopplar ihop många av dem.

Tänk på en typisk företagsstack: ett CRM, ett ERP, en plattform för marknadsföringsautomation, en supportdesk, ett datalager och ett antal SaaS-verktyg för specifika affärsområden. Om varje system har sin egen uppfattning om “kund”, “konto”, “order” och “produkt”, kräver varje systempar som behöver dela data sin egen mappning. Antalet integrationer växer ungefär med kvadraten på antalet system, och varje mappning är en liten, odokumenterad och oägd del av logik som någon måste underhålla för evigt.

Relaterat: Fivetran — Den fullt hanterade ELT-pipelinen som bara fortsätter att köras.

Symptomen är bekanta för alla som har drivit en integrationsverksamhet:

• Semantisk drift. “Kund” i CRM betyder en faktureringsenhet; i supportdesken betyder det en person som skapar ärenden. Samma ord, två betydelser, tyst förenade av en mappning som ingen kommer ihåg att ha skrivit.
• Sköra pipelines. En leverantör byter namn på ett fält eller ändrar en enum, och ett ETL-jobb misslyckas klockan 02.00 eftersom mappningen var hårdkodad mot den gamla strukturen.
• Duplicerat arbete. Två team bygger oberoende av varandra nästan identiska översättningar mellan samma två system eftersom det inte finns någon delad referens att peka på.
• Leverantörslåsning via data. Att migrera från en plattform är dyrt, inte på grund av programvaran utan på grund av den ackumulerade översättningslogiken som är knuten till dess schema.

En delad, applikationsagnostisk modell angriper grundorsaken: istället för N-till-N-mappningar mappas varje system en gång till en gemensam modell, och den gemensamma modellen bär betydelsen.

Vad “applikationsagnostisk” egentligen betyder

Det är värt att vara precis med designfilosofin, eftersom “agnostisk” ofta används löst.

Om du handlar: Boomi AtomSphere — Enterprise iPaaS för hybrid moln-till-på-prem-integration.

En applikationsagnostisk modell ägs inte av, och är inte optimerad för, någon enskild leverantörs produkt. Den beskriver affärskoncept i termer som skulle vara igenkännbara för en domänexpert — en kund, en order, en produkt, en plats — snarare än i termer som speglar en applikations interna tabeller. Den neutraliteten är det som gör den till ett användbart nav: ingen deltagare behöver anamma en konkurrents världsbild för att kunna samverka.

Detta är samma arkitektoniska instinkt bakom andra neutrala utbytesstandarder. Precis som Resource Description Framework (RDF) och schema.org ger webben ett delat vokabulär för att beskriva saker, och precis som EDI och senare UBL (Universal Business Language, en OASIS-standard) gav leveranskedjor ett delat format för transaktioner, syftar CIM till att ge företagsapplikationer ett delat vokabulär för deras kärnaffärsenheter. Skillnaden är omfattning och modernitet: CIM riktar sig mot den uppkopplade, API-drivna världen med både moln- och lokala lösningar snarare än batchfilutbyte.

En användbar mental modell är mönstret kanonisk datamodell från företagsintegration, populariserat i Gregor Hohpes och Bobby Woolfs Enterprise Integration Patterns. CIM är i praktiken en gemensamt underhållen kanonisk modell — “navet” i en hub-and-spoke-integrationstopologi — men en som är öppen, versionerad och delad mellan organisationer snarare än uppfunnen privat inom ett företag.

Hur CIM är organiserat: Ämnesområden och domäner

Samarbetsdefinierat innehåll är organiserat i domäner, eller ämnesområden. Varje ämnesområde representerar ett större affärskoncept. CIM-designerna finns tillgängliga i flera format för varje domän, inklusive exempeldiagram. Antalet och omfattningen av ämnesområdena kommer att växa i takt med konsortiet och bidragen.

I praktiken betyder detta att du bör tänka på CIM som ett bibliotek av relaterade modeller snarare än ett enda monolitiskt schema. Typiska ämnesområden samlas kring igenkännbara affärsbehov – till exempel parter och konton, produkter och kataloger, order och transaktioner, samt de relationer som knyter dem samman. Eftersom varje område publiceras med diagram och maskinläsbara definitioner kan olika team anta olika områden vid olika tidpunkter utan att vänta på att hela modellen ska vara komplett.

Några praktiska konsekvenser följer av denna struktur:

Relaterat: Matillion — Push-down ELT byggd för molndatalager.

• Adoptera stegvis. Du behöver inte mappa hela ditt företag till CIM från dag ett. Börja med det ämnesområde som orsakar mest problem – vanligtvis kund- eller orderdomänen – och expandera därifrån.
• Utöka snarare än att forka. När CIM saknar ett koncept du behöver, är den öppna modellen designad för att utökas. Att bidra med en utökning tillbaka är att föredra framför att underhålla en privat fork, eftersom en fork driver iväg och förlorar fördelen med interoperabilitet.
• Behandla diagram som dokumentation, inte som sanningens källa. Exempeldiagrammen är till för människor; de maskinläsbara definitionerna är vad dina verktyg ska konsumera.

CIM i integrationslandskapet: Hur man väljer

CIM är ett av flera alternativ för att tämja integrationskomplexitet. För att välja rätt krävs att verktyget matchas mot problemet. Tabellen nedan kontrasterar de huvudsakliga tillvägagångssätten som en företagsdataarkitekt vanligtvis väger mot varandra.

Tillvägagångssätt	Vad det är	Bäst när	Huvudsaklig avvägning
Punkt-till-punkt-mappning	Anpassad kod som översätter direkt mellan två system	Endast två system, stabila scheman, kort tidshorisont	Skalar inte; N-till-N-explosion; sprött
Kanonisk modell (t.ex. CIM)	En delad, neutral modell som varje system mappar till en gång	Många system, cross-vendor, långlivad integration	Modelleringinsats i förväg; styrning krävs
Leverantörens iPaaS-kontakter	Förbyggda kontakter från en integrationsplattform	Vanliga SaaS-par, snabbhet framför kontroll	Kontakt-specifik semantik; potentiell inlåsning
Industriutbytesstandarder (EDI, UBL, HL7, etc.)	Domänspecifika meddelandeformat	Reglerade eller väletablerade vertikaler	Smal omfattning; ofta batch-orienterad
Datavirtualisering / federation	Fråga över källor utan centralisering	Analys, främst läsåtkomst	Löser inte semantiska konflikter i sig själv

Beslutsheuristiken är enkel: om du har mer än en handfull system som måste vara överens om innebörden av delade entiteter, och dessa system kommer från olika leverantörer, betalar en kanonisk modell för sig själv. Om du har två system och inga planer på att lägga till fler, fungerar punkt-till-punkt bra. Om ditt behov är rent analytiskt och skrivskyddat kan federation räcka – men notera att federation flyttar det semantiska problemet snarare än att lösa det.

CIM är ett komplement till, inte en ersättning för, verktygen runt omkring. En ETL- eller ELT-pipeline (byggd med något som Apache Airflow, dbt eller en kommersiell plattform) sköter fortfarande flytten; CIM definierar vad datan betyder när den väl anländer. En meddelandemäklare som Apache Kafka sköter fortfarande transporten; CIM definierar händelsernas form. Modellen är kontraktet; verktygen är rördragningen.

Läsarens favorit: Airbyte — Öppen källkod ELT med ett hanterat molnalternativ.

Styrning, licensiering och varför stiftelsen är viktig

CIM är öppen källkod som en del av Joint Development Foundation, som verkar under Linux Foundation. Detta är inte en trivial detalj – det är centralt för varför ett företag säkert kan bygga på CIM.

Linux Foundation är ett väletablerat neutralt hem för samarbetsprojekt med öppen källkod, och Joint Development Foundation tillhandahåller en lättviktig juridisk struktur för att utveckla standarder och specifikationer i samarbete. Att CIM huseras där innebär:

• Neutralt förvaltarskap. Ingen enskild leverantör kontrollerar modellen, så att anta den innebär inte att man antar en konkurrents färdplan.
• Öppna bidrag. Vem som helst – leverantörer, företag, enskilda bidragsgivare – kan föreslå ändringar, och processen är transparent.
• Förutsägbar licensiering. Specifikationer som huseras av stiftelsen har vanligtvis villkor utformade för bred, royalty-vänlig adoption, vilket är av enorm betydelse för juridiska team och inköpsavdelningar som utvärderar en standard.

För en arkitekt som argumenterar för detta internt är denna styrningsberättelse ofta lika viktig som det tekniska innehållet. “Det är en öppen standard under Linux Foundation” besvarar de frågor som annars dödar införandet av standarder: Vem kontrollerar den? Vad händer om en leverantör lämnar? Kan vi bidra med våra utökningar?

Komma igång: En praktisk adoptionsväg

Att anta en gemensam modell är lika mycket en organisatorisk övning som en teknisk. En pragmatisk sekvens ser ut så här:

1. Inventera dina delade entiteter. Identifiera de affärskoncept som förekommer i mer än ett system – vanligtvis kund, produkt, order och plats. Dessa är dina kandidater.
2. Välj ett ämnesområde och en integration. Välj den integration som orsakar mest problem men har lägst riskradie för att bevisa modellen. En enda rapporteringspipeline eller onboarding av en ny applikation är idealiskt.
3. Mappa varje system till CIM en gång. Bygg översättningen från varje källsystem till CIM-representationen, och från CIM till varje mål. Motstå frestelsen att mappa system-till-system direkt.
4. Dokumentera dina utökningar. Där CIM inte täcker ett koncept, dokumentera utökningen explicit och överväg att bidra med den tillbaka.
5. Etablera ägande. En kanonisk modell utan en förvaltare förfaller. Utse ett team eller en roll som ansvarar för mappningarna och för att spåra uppströmsförändringar.
6. Versionera och testa. Behandla modellen och dess mappningar som versionerade artefakter med tester, exakt som du skulle göra med applikationskod.

Det vanligaste felläget är att behandla CIM som en engångsmodelleringsövning snarare än ett levande kontrakt. De organisationer som lyckas behandlar modellen på samma sätt som de behandlar ett API: versionerad, testad, ägd och utvecklad medvetet.

Partners som bidrar till CIM

CIM är ett konsortiearbete och dess värde växer med deltagandet. Partners bidrar med innehåll till ämnesområden, granskar förslag och hjälper till att forma modellens riktning. Eftersom arbetet är öppet är bidragen inte begränsade till stora leverantörer – företag med verkliga integrationsproblem och enskilda utövare med domänexpertis är lika välkomna.

Hör av dig

Är du intresserad av att gå med i CIM-initiativet? Vad bra! Maila oss gärna för mer information. Maila oss.

Vanliga frågor

Vad är Cloud Information Model (CIM)?

CIM är en applikationsagnostisk datamodell med öppen källkod som tillhandahåller ett delat, standardbaserat vokabulär för de affärskoncept som företag behöver utbyta mellan moln- och lokala applikationer. Den produceras av ett öppet konsortium och huseras under Joint Development Foundation, en del av Linux Foundation. Syftet är att minska den anpassade mappningskod som sköra punkt-till-punkt-integrationer kräver.

Är CIM en produkt eller en specifikation?

CIM är en specifikation – en modell och en uppsättning definitioner – inte en körbar produkt. Den definierar betydelsen och strukturen för delade entiteter; du väljer fortfarande dina egna ETL/ELT-verktyg, meddelandemäklare och lagring. Se det som kontraktet som din integrationsinfrastruktur implementerar, snarare än själva infrastrukturen.

Hur skiljer sig CIM från en leverantörs integrationsplattform?

En integrationsplattform (ett iPaaS eller ett bibliotek av anslutningar) flyttar data och levererar ofta förbyggda anslutningar, men dessa anslutningar kodar leverantörsspecifik semantik. CIM är neutralt och leverantörsoberoende, så det låser dig inte till en plattforms världsbild. De två kompletterar varandra: du kan använda CIM som den kanoniska modellen i vilken integrationsplattform som helst.

Vad är ämnesområden (Subject Areas) i CIM?

Ämnesområden (även kallade domäner) är modellens organiserande enheter, där varje område representerar ett viktigt affärskoncept såsom kunder, produkter eller order. Designerna publiceras i flera format, inklusive exempeldiagram, och uppsättningen av ämnesområden förväntas växa i takt med att konsortiet och communityn bidrar med mer innehåll.

Kan vi utöka CIM om det inte täcker våra koncept?

Ja. CIM är designat för att kunna utökas, och eftersom det är öppen källkod under en neutral stiftelse kan du föreslå tillägg genom bidragsprocessen. Att utöka den delade modellen och bidra tillbaka är starkt att föredra framför att underhålla en privat fork, vilket över tid leder till avvikelser och gör att man förlorar den interoperabilitetsfördel som motiverade införandet av CIM från början.

Vem bör använda CIM?

Det är mest värdefullt för organisationer som kör många applikationer från olika leverantörer som måste enas om betydelsen av delade entiteter – den klassiska situationen för företagsdataarkitekter och integrationsingenjörer. Applikations- och plattformsleverantörer drar också nytta av att anpassa sina scheman till en neutral modell, vilket gör deras produkter lättare för kunderna att integrera. Om du bara har två stabila system kan en enklare punkt-till-punkt-mappning vara tillräcklig.

Ytterligare läsning

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