Cloud Information Model

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

Viktiga slutsatser

• CIM är en delad, öppen datamodell, inte en produkt. Den definierar gemensamma affärskoncept och deras relationer så att olika applikationer kan utbyta data utan skräddarsydda engångsmappningar.
• Den styrs som en öppen standard. CIM är öppen källkod under Joint Development Foundation, en del av Linux Foundation, och välkomnar bidragsgivare från leverantörer, företag och det bredare communityt.
• Innehållet är organiserat i ämnesområden (domäner). Varje domän representerar ett centralt affärskoncept och publiceras i flera format, inklusive diagram, så att arkitekter och ingenjörer kan implementera det stegvis.
• Kärnvärdet är att minska integrationens skörhet. En kanonisk modell ersätter punkt-till-punkt-översättningskod med ett stabilt mål som många system kan mappa till och från.
• Adoption är ett designbeslut, inte en omställning. Du väljer vilka domäner som ska användas, hur du mappar dina källsystem och hur du styr utökningar över tid.

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 i alla kanaler använder många företag flera molnbaserade 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.

Problemet som CIM adresserar är strukturellt, inte tillfälligt. När varje system talar sin egen dialekt – ett kallar en kund för en “Kontakt”, ett annat för en “Party”, ett tredje för ett “Konto” – slutar integrationsteamen med att underhålla ett växande nät av parvisa mappningar.

Varje ny applikation multiplicerar antalet översättningar som krävs, och varje schemaändring i ett system kan få ringar på vattnet och bryta nedströms pipelines. En kanonisk modell ändrar formen på det problemet: istället för att N system mappar till varandra, mappar varje system en gång till ett delat ordförråd.

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

Varför punkt-till-punkt-integration fallerar

Det hjälper att vara konkret kring de fellägen som motiverar en delad modell.

• Kombinatorisk tillväxt. Med punkt-till-punkt-mappningar växer antalet översättningsvägar ungefär med kvadraten på antalet system. Att lägga till en tionde applikation är betydligt dyrare än att lägga till den andra.
• Semantisk drift. Två team kan båda “mappa kunden” och ändå vara oense om huruvida en kund är en person, en organisation eller en faktureringsrelation. Data flödar, men innebörden divergerar.
• Skör ändringshantering. En namnändring av ett fält eller ett nytt obligatoriskt attribut i ett källsystem tvingar fram ändringar hos varje konsument som berör det.
• Duplicerad logik. Regler för validering, deduplicering och identitetsupplösning implementeras på nytt i varje integration istället för att definieras en gång.
• Tryck mot leverantörsinlåsning. När integrationslogiken är sammanflätad med en specifik leverantörs schema blir byte av eller tillägg av leverantörer ett omplattformningsprojekt.

En kanonisk modell som CIM eliminerar inte mappningsarbete – varje källsystem behöver fortfarande en mappning till modellen. Vad den eliminerar är multiplikationen av det arbetet. Du bygger en mappning per system till den delade modellen, och modellen i sig utgör det stabila kontraktet mellan dem.

Hur CIM är organiserat: Ämnesområden

Samarbetsdefinierat innehåll är organiserat i domäner, eller ämnesområden. Varje ämnesområde representerar ett centralt affärskoncept. CIM-designerna är 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.

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

Denna domänorienterade struktur är viktig för adoption. Du behöver sällan hela modellen på en gång. Ett typiskt företag börjar med de domäner som berör dess mest problematiska integration, bevisar tillvägagångssättet och expanderar sedan. Vanliga utgångspunkter tenderar att vara de koncept som förekommer i nästan alla system:

• Party / Kund — personerna och organisationerna du gör affärer med, och de roller de har.
• Produkt — vad du säljer, erbjuder eller hanterar, inklusive kataloger och klassificeringar.
• Konto och relation — hur parter förhåller sig till produkter, kontrakt och varandra.
• Interaktion och aktivitet — händelserna, transaktionerna och engagemangen som kopplar samman ovanstående.

Eftersom varje ämnesområde publiceras med diagram och i flera representationsformat kan arkitekter granska den konceptuella modellen, ingenjörer kan använda en maskinläsbar form och affärsintressenter kan validera att koncepten matchar verkligheten. Denna multiformatsmetod är ett medvetet designval: en modell som bara ingenjörer kan läsa tenderar att glida bort från den affärsmässiga innebörden.

Hur CIM jämförs med andra tillvägagångssätt

CIM är ett av flera alternativ för att uppnå interoperabilitet. Att göra ett bra val innebär att förstå avvägningarna.

Tillvägagångssätt	Vad det är	Styrkor	Avvägningar
Punkt-till-punkt-mappning	Direkta översättningar mellan varje systempar	Enkelt för två system; ingen delad styrning behövs	Växer kombinatoriskt; sprött; duplicerad logik
Kanonisk modell (CIM-stil)	Ett delat, applikationsagnostiskt ordförråd som varje system mappar till	Linjär mappningsinsats; stabilt kontrakt; återanvändbart över projekt	Kräver styrning och överenskommelse; mappning behövs fortfarande per system
Industrins datastandarder	Vertikala standarder för en specifik sektor (t.ex. hälso- och sjukvård, finans)	Djup domäntäckning; regulatorisk anpassning	Smal omfattning; täcker kanske inte branschövergripande företagskoncept
Leverantörsdatamodeller	En plattforms inbyggda schema exponerat som integrationshubb	Tät verktygsintegration; snabbt inom en leverantörs ekosystem	Inlåsningsrisk; andra leverantörer måste anpassa sig till en parts modell
API-först / schema-on-read	Kontrakt definierade per API; betydelse fastställs vid konsumtionstillfället	Flexibelt; snabbt att starta	Semantisk konsekvens beror på disciplin; svårare att styra i stor skala

Den praktiska vägledningen: använd en kanonisk modell när du har många system, koncept över flera domäner och ett långlivat integrationslandskap. Använd punkt-till-punkt när omfattningen genuint rör två system och är kortlivad. Branschstandarder och CIM kompletterar varandra – en vertikal standard kan informera en domän, medan CIM tillhandahåller det tvärgående företagsordförrådet.

Hur man inför CIM i praktiken

Införandet är en sekvens av medvetna beslut snarare än en enda migration. Ett fungerande mönster ser ut så här:

1. Välj en smärtsam, välavgränsad integration. Välj en domän där mappningssmärtan är verklig och omfattningen är tillräckligt liten för att snabbt bevisa värdet.
2. Inventera källsystemen och deras scheman. Dokumentera vad varje system kallar begreppen i ditt valda ämnesområde, och var de skiljer sig åt.
3. Mappa varje system till CIM-domänen. Bygg en mappning per system till den delade modellen. Behandla dessa mappningar som versionerade artefakter, inte engångsskript.
4. Definiera din utvidgningspolicy i förväg. Bestäm hur du ska hantera koncept som CIM ännu inte täcker – utvidgningar bör dokumenteras, namnges konsekvent och föreslås tillbaka till konsortiet där de är allmänt användbara.
5. Etablera styrning. Tilldela ägarskap för mappningarna, en granskningsprocess för ändringar och en takt för synkronisering med uppströms CIM-uppdateringar.
6. Utöka domän för domän. Återanvänd mappningsmönstren och styrningen från den första domänen för att sänka kostnaden för nästa.

Två varningar är värda att uttrycka tydligt. För det första lägger en kanonisk modell till ett lager – det är inte gratis, och vinsten kommer från återanvändning över många integrationer, inte från en enda. För det andra är mappningen där det verkliga arbetet ligger; modellen ger dig ett stabilt mål, men någon måste fortfarande bestämma hur varje källfält motsvarar det, och det beslutet drar nytta av affärsmässig input, inte bara teknisk.

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

Styrning, licensiering och bidrag

CIM är öppen källkod som en del av Joint Development Foundation, som verkar under Linux Foundation. Den strukturen är viktig för företag som utvärderar den: Linux Foundation är ett väletablerat hem för samarbetande, leverantörsneutrala projekt med öppen källkod, och Joint Development Foundation tillhandahåller ett juridiskt ramverk specifikt utformat för att utveckla och driva standarder och specifikationsprojekt.

För en företagsdataarkitekt är de praktiska konsekvenserna av denna styrmodell:

• Leverantörsneutralitet. Ingen enskild leverantör kontrollerar specifikationen, vilket minskar risken att modellen är utformad för att gynna en viss plattform.
• Öppna bidrag. Vem som helst kan föreslå ändringar, vilket innebär att modellen kan utvecklas för att återspegla verkliga integrationsbehov snarare än en enskild färdplan.
• Specifikationsorienterad process. Joint Development Foundation-modellen är uppbyggd kring att ta fram och underhålla specifikationer, vilket överensstämmer med hur standarder antas och refereras till i upphandlingar och arkitekturgranskningar.

Att bidra uppmuntras och är öppet för alla. Bidrag tar vanligtvis formen av nya eller förfinade ämnesområden, korrigeringar och förtydliganden, exempeldiagram och feedback från verkliga integrationsprojekt. De mest värdefulla bidragen kommer ofta från utövare som har stött på ett specifikt mappningsproblem och kan beskriva det koncept som löser det.

Vårt val: Workato — Automationsledd iPaaS som affärsteam faktiskt kan bygga på.

Engagera dig

Är du intresserad av att gå med i CIM-initiativet? Vad roligt! Kontakta oss gärna via e-post för mer information.

Utöver e-post är de naturliga sätten att engagera sig att granska de publicerade ämnesområdena för din intressedomän, prova att mappa ett av dina system till en domän och återföra de luckor du hittar till communityn. Eftersom antalet och omfattningen av ämnesområden växer med konsortiet och bidragen, förbättras modellen i proportion till hur många verkliga integrationsproblem dess användare lyfter fram.

Vanliga frågor

Vad är Cloud Information Model egentligen?

CIM är en applikationsagnostisk, öppen datamodell som definierar gemensamma affärskoncept och deras relationer så att olika applikationer kan utbyta data genom ett delat ordförråd. Den produceras av ett öppet konsortium och publiceras som en öppen specifikation. Istället för att vara en produkt du installerar, är det en modell som du mappar dina system mot.

Vem är CIM till för?

Den riktar sig till företagsdataarkitekter, integrations- och ETL-ingenjörer, applikations- och plattformsleverantörer samt bidragsgivare inom öppen källkod. Alla som måste ansluta flera molnsystem och lokala system med olika scheman är potentiella användare. Leverantörer gynnas eftersom en delad modell minskar det anpassningsarbete som krävs för att integrera med deras produkter.

Hur styrs och licensieras CIM?

CIM är öppen källkod som en del av Joint Development Foundation, som verkar under Linux Foundation. Detta ger ett leverantörsneutralt, specifikationsorienterat ramverk för styrning. Den strukturen är avsedd att hålla modellen öppen för bidrag och oberoende av någon enskild leverantörs kontroll.

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

En leverantörs inbyggda modell är optimerad för den leverantörens produkt och ekosystem; att använda den som din integrationshub tenderar att skapa inlåsning. CIM är designat för att vara applikationsagnostiskt, så ingen enskild plattform definierar vokabulären. Avvägningen är att CIM kräver styrning och överensstämmelse mellan team, medan en leverantörsmodell är redo att användas inom den leverantörens verktyg.

Behöver jag fortfarande skriva mappningar om jag använder CIM?

Ja. Varje källsystem behöver fortfarande en mappning till den delade modellen. Fördelen är att du skriver en mappning per system till CIM istället för en separat översättning för varje systempar. Detta förvandlar en kombinatorisk mappningsinsats till en ungefär linjär insats och ger dig ett stabilt kontrakt som överlever förändringar i enskilda system.

Hur börjar jag använda CIM?

Börja med en enda högsmärtsam, välavgränsad integration i ett ämnesområde. Inventera källscheman, mappa varje system till CIM-domänen, definiera en extensions- och styrningspolicy och behandla mappningarna som versionerade artefakter. När den första domänen bevisar sitt värde, expandera domän för domän genom att återanvända mönstren och styrningen du etablerade.

Ytterligare läsning

• Linux Foundation — Wikipedia
• Linux Foundation — Wikipedia