Cloud Information Model

Velkommen til CIM, en applikations-agnostisk datamodel, der forenkler integration og accelererer innovation.

Key Takeaways

• CIM er en delt, åben datamodel, ikke et produkt. Den definerer fælles forretningskoncepter og deres relationer, så forskellige applikationer kan udveksle data uden skræddersyede engangskortlægninger.
• Den styres som en åben standard. CIM er open source under Joint Development Foundation, en del af Linux Foundation, og byder bidragydere velkommen fra leverandører, virksomheder og det bredere samfund.
• Indholdet er organiseret i emneområder (domæner). Hvert domæne repræsenterer et væsentligt forretningskoncept og udgives i flere formater, inklusive diagrammer, så arkitekter og ingeniører kan adoptere det trinvist.
• Kerneværdien er at reducere integrationens skrøbelighed. En kanonisk model erstatter punkt-til-punkt-oversættelseskode med et stabilt mål, som mange systemer kan kortlægge til og fra.
• Adoption er en designbeslutning, ikke en kontakt. Du vælger, hvilke domæner du vil adoptere, hvordan du kortlægger dine kildesystemer, og hvordan du styrer udvidelser over tid.

En ny standard for datainteroperabilitet

CIM er produceret af et åbent konsortium dannet for at levere en standardbaseret løsning til at forbinde virksomhedsprodukter. Med CIM kan du skabe sømløse og skræddersyede personlige oplevelser på tværs af cloud-native applikationer.

For at accelerere digital transformation og levere personlige engagementer til kunder på tværs af alle kanaler, anvender mange virksomheder flere cloud- og on-premise-applikationer. Hver kommer med sin egen datamodel, hvilket tvinger udviklere til at bygge, teste og administrere tilpasset kode, der er nødvendig for at kortlægge og oversætte data på tværs af forskellige systemer. I stedet for at accelerere den digitale transformation bremser denne proces innovation og fører til skrøbelige integrationer.

CIM er en moderne, åben specifikation, der hjælper med at lette smerten ved at integrere data. CIM giver en defineret standard til let at kommunikere mellem forskellige dataformater. Som open source-projekt under Joint Development Foundation (under Linux Foundation) byder vi alle bidragydere velkommen.

Problemet, som CIM adresserer, er strukturelt, ikke tilfældigt. Når hvert system taler sin egen dialekt – det ene kalder en kunde for en “Contact”, et andet for en “Party”, et tredje for en “Account” – ender integrationsteams med at vedligeholde et voksende net af parvise kortlægninger.

Hver ny applikation multiplicerer antallet af krævede oversættelser, og hver skemaændring i et hvilket som helst system kan forplante sig og bryde nedstrøms-pipelines. En kanonisk model ændrer formen på dette problem: I stedet for at N systemer kortlægger hinanden, kortlægges hvert system én gang til et fælles ordforråd.

Relateret: Fivetran — Den fuldt administrerede ELT-pipeline, der bare bliver ved med at køre.

Hvorfor punkt-til-punkt-integration bryder sammen

Det hjælper at være konkret omkring de fejltilstande, der motiverer en fælles model.

• Kombinatorisk vækst. Med punkt-til-punkt-kortlægninger vokser antallet af oversættelsesstier nogenlunde med kvadratet af antallet af systemer. Det er langt dyrere at tilføje en tiende applikation end at tilføje den anden.
• Semantisk drift. To teams kan begge “kortlægge kunden” og stadig være uenige om, hvorvidt en kunde er en person, en organisation eller et faktureringsforhold. Dataene flyder, men betydningen divergerer.
• Skrøbelig ændringsstyring. En omdøbning af et felt eller en ny påkrævet attribut i ét kildesystem tvinger redigeringer igennem hos enhver forbruger, der berører det.
• Duplikeret logik. Regler for validering, deduplikering og identitetsopløsning genimplementeres i hver integration i stedet for at blive defineret én gang.
• Pres fra leverandørlås (Vendor lock-in). Når integrationslogikken er sammenfiltret med en specifik leverandørs skema, bliver skift eller tilføjelse af leverandører til et re-platforming-projekt.

En kanonisk model som CIM eliminerer ikke kortlægningsarbejde – hvert kildesystem har stadig brug for en kortlægning til modellen. Hvad den eliminerer, er multiplikationen af dette arbejde. Du bygger én kortlægning pr. system til den delte model, og selve modellen udgør den stabile kontrakt imellem dem.

Hvordan CIM er organiseret: Emneområder

Kollaborativt defineret indhold er organiseret i domæner eller emneområder. Hvert emneområde repræsenterer et væsentligt forretningskoncept. CIM-designene er tilgængelige i flere formater for hvert domæne, inklusive eksempeldiagrammer. Antallet og omfanget af emneområderne vil vokse i takt med konsortiet og bidragene.

Hvis du handler: Boomi AtomSphere — Enterprise iPaaS til hybrid cloud-to-on-prem integration.

Denne domæneorienterede struktur er vigtig for adoptionen. Du har sjældent brug for hele modellen på én gang. En typisk virksomhed starter med de domæner, der berører dens mest problematiske integration, beviser tilgangen og udvider derefter. Almindelige udgangspunkter har tendens til at være de koncepter, der optræder i næsten alle systemer:

• Party / Kunde — de personer og organisationer, du handler med, og de roller, de spiller.
• Produkt — hvad du sælger, tilbyder eller administrerer, inklusive kataloger og klassifikationer.
• Konto og relation — hvordan parter forholder sig til produkter, kontrakter og hinanden.
• Interaktion og aktivitet — de begivenheder, transaktioner og engagementer, der forbinder ovenstående.

Fordi hvert emneområde udgives med diagrammer og flere repræsentationsformater, kan arkitekter gennemgå den konceptuelle model, ingeniører kan bruge en maskinlæsbar form, og forretningsinteressenter kan validere, at koncepterne stemmer overens med virkeligheden. Denne multi-format-tilgang er et bevidst designvalg: en model, som kun ingeniører kan læse, har en tendens til at afvige fra den forretningsmæssige betydning.

Hvordan CIM sammenligner med andre tilgange

CIM er én mulighed blandt flere for at opnå interoperabilitet. At vælge rigtigt betyder at forstå afvejningerne.

Tilgang	Hvad er det	Styrker	Afvejninger
Punkt-til-punkt-kortlægning	Direkte oversættelser mellem hvert par af systemer	Enkelt for to systemer; ingen delt styring nødvendig	Vokser kombinatorisk; skrøbelig; duplikeret logik
Kanonisk model (CIM-stil)	Et fælles, applikations-agnostisk ordforråd, som hvert system kortlægges til	Lineær kortlægningsindsats; stabil kontrakt; genbrugelig på tværs af projekter	Kræver styring og enighed; kortlægning er stadig nødvendig pr. system
Industridatastandarder	Vertikale standarder for en specifik sektor (f.eks. sundhedsvæsen, finans)	Dyb domænedækning; regulatorisk tilpasning	Snævert omfang; dækker muligvis ikke tværindustrielle virksomhedskoncepter
Leverandørdatamodeller	En platforms native skema eksponeret som integrationshub	Tæt værktøjsintegration; hurtig inden for én leverandørs økosystem	Risiko for lock-in; andre leverandører skal rette sig efter én parts model
API-først / schema-on-read	Kontrakter defineret pr. API; betydning afklares på forbrugstidspunktet	Fleksibel; hurtig at starte	Semantisk konsistens afhænger af disciplin; sværere at styre i stor skala

Den praktiske vejledning: Brug en kanonisk model, når du har mange systemer, koncepter på tværs af domæner og et langvarigt integrationslandskab. Brug punkt-til-punkt, når omfanget reelt er to systemer og er kortvarigt. Industristandarder og CIM er komplementære — en vertikal standard kan informere et domæne, mens CIM leverer det tværgående virksomhedsordforråd.

Sådan implementeres CIM i praksis

Implementering er en sekvens af bevidste beslutninger snarere end en enkelt migration. Et brugbart mønster ser således ud:

1. Vælg en smertefuld, velafgrænset integration. Vælg et domæne, hvor udfordringerne ved kortlægning er reelle, og omfanget er lille nok til hurtigt at bevise værdien.
2. Kortlæg kildesystemerne og deres skemaer. Dokumenter, hvad hvert system kalder begreberne i dit valgte emneområde, og hvor de er uenige.
3. Kortlæg hvert system til CIM-domænet. Byg én kortlægning pr. system til den fælles model. Behandl disse kortlægninger som versionerede artefakter, ikke som midlertidige scripts.
4. Definer din udvidelsespolitik på forhånd. Beslut, hvordan du vil håndtere begreber, som CIM endnu ikke dækker — udvidelser bør dokumenteres, navngives konsekvent og foreslås tilbage til konsortiet, hvis de er bredt nyttige.
5. Etabler styring. Tildel ejerskab til kortlægningerne, en gennemgangsproces for ændringer og en kadence for synkronisering med upstream CIM-opdateringer.
6. Udvid domæne for domæne. Genbrug kortlægningsmønstrene og styringen fra det første domæne for at sænke omkostningerne ved det næste.

To forbehold er værd at nævne klart. For det første tilføjer en kanonisk model et lag — det er ikke gratis, og udbyttet kommer fra genbrug på tværs af mange integrationer, ikke fra en enkelt. For det andet er kortlægningen der, hvor det egentlige arbejde ligger; modellen giver dig et stabilt mål, men nogen skal stadig beslutte, hvordan hvert kildefelt svarer til det, og den beslutning drager fordel af forretningsmæssigt input, ikke kun teknisk.

Relateret: Matillion — Push-down ELT bygget til cloud-datavarehuse.

Styring, licensering og bidrag

CIM er open source som en del af Joint Development Foundation, som opererer under Linux Foundation. Denne struktur er vigtig for virksomheder, der evaluerer den: Linux Foundation er et veletableret hjem for samarbejdende, leverandørneutrale open source-projekter, og Joint Development Foundation giver en juridisk ramme, der er specifikt designet til at udvikle og drive standarder og specifikationsprojekter.

For en virksomhedsdataarkitekt er de praktiske implikationer af denne styringsmodel:

• Leverandørneutralitet. Ingen enkelt leverandør kontrollerer specifikationen, hvilket reducerer risikoen for, at modellen er formet til at favorisere én platform.
• Åbent bidrag. Alle kan foreslå ændringer, hvilket betyder, at modellen kan udvikle sig til at afspejle virkelige integrationsbehov snarere end en enkelt køreplan.
• Specifikationsorienteret proces. Joint Development Foundation-modellen er bygget op omkring at producere og vedligeholde specifikationer, hvilket stemmer overens med, hvordan standarder vedtages og refereres til i indkøb og arkitekturgennemgange.

Bidrag opmuntres og er åbne for alle. Bidrag tager typisk form af nye eller raffinerede emneområder, rettelser og præciseringer, eksempeldiagrammer og feedback fra reelle integrationsprojekter. De mest værdifulde bidrag kommer ofte fra praktikere, der har ramt et specifikt kortlægningsproblem og kan beskrive det koncept, der løser det.

Læsernes favorit: Airbyte — Open source ELT med en administreret cloud-mulighed.

Bliv involveret

Er du interesseret i at deltage i CIM-initiativet? Fantastisk! Du er velkommen til at sende os en e-mail for mere information.

Ud over e-mail er de naturlige måder at engagere sig på at gennemgå de offentliggjorte emneområder for dit interesseområde, prøve at kortlægge et af dine systemer til et domæne og bringe de huller, du finder, tilbage til fællesskabet. Fordi antallet og omfanget af emneområder vokser med konsortiet og bidragene, forbedres modellen i takt med, hvor mange reelle integrationsproblemer dens brugere bringer til den.

Ofte stillede spørgsmål

Hvad er Cloud Information Model helt præcist?

CIM er en applikations-agnostisk, åben datamodel, der definerer fælles forretningskoncepter og deres relationer, så forskellige applikationer kan udveksle data gennem et fælles ordforråd. Den er produceret af et åbent konsortium og udgivet som en åben specifikation. I stedet for at være et produkt, du installerer, er det en model, du kortlægger dine systemer til.

Hvem er CIM for?

Den er rettet mod virksomhedsdataarkitekter, integrations- og ETL-ingeniører, applikations- og platformsleverandører og open source-bidragydere. Enhver, der skal forbinde flere cloud- og on-premise-systemer med forskellige skemaer, er en potentiel bruger. Leverandører drager fordel af det, fordi en delt model reducerer det specialarbejde, der kræves for at integrere med deres produkter.

Hvordan styres og licenseres CIM?

CIM er open source som en del af Joint Development Foundation, som opererer under Linux Foundation. Dette giver en leverandørneutral, specifikationsorienteret styringsramme. Denne struktur er beregnet til at holde modellen åben for bidrag og uafhængig af en enkelt leverandørs kontrol.

Hvordan adskiller CIM sig fra en leverandørs native datamodel?

En leverandørs native model er optimeret til den pågældende leverandørs produkt og økosystem; at adoptere den som din integrationshub har en tendens til at skabe lock-in. CIM er designet til at være applikations-agnostisk, så ingen enkelt platform definerer ordforrådet. Afvejningen er, at CIM kræver styring og enighed på tværs af teams, hvorimod en leverandørmodel er klar til brug inden for den pågældende leverandørs værktøjer.

Skal jeg stadig skrive mappings, hvis jeg bruger CIM?

Ja. Hvert kildesystem har stadig brug for en mapping til den delte model. Fordelen er, at du skriver én mapping pr. system til CIM i stedet for en separat oversættelse for hvert par af systemer. Dette gør den kombinatoriske mapping-indsats til en nogenlunde lineær indsats og giver dig en stabil kontrakt, der overlever ændringer i individuelle systemer.

Hvordan begynder jeg at adoptere CIM?

Start med en enkelt high-pain, velafgrænset integration i ét fagområde (Subject Area). Kortlæg kildeskemaerne, map hvert system til CIM-domænet, definer en udvidelses- og styringspolitik, og behandl mappings som versionerede artefakter. Når det første domæne beviser sin værdi, kan du udvide domæne for domæne ved at genbruge de mønstre og den styring, du har etableret.

Yderligere læsning

• Linux Foundation — Wikipedia
• Linux Foundation — Wikipedia