Cloud Information Model

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

Key Takeaways

• CIM er en åben, applikations-agnostisk datamodel — et fælles vokabular af forretningskoncepter (kunder, ordrer, produkter og så videre), der gør det muligt for forskellige cloud- og on-premises-systemer at udveksle data uden skræddersyet punkt-til-punkt-kortlægning.
• Den eksisterer for at løse et specifikt, dyrt problem: hver applikation leveres med sin egen datamodel, så integrationsteams ender med at skrive og vedligeholde tilpasset oversættelseskode, der er skrøbelig og sinker innovation.
• Den styres som en åben standard, produceret af et konsortium og open sourced under Joint Development Foundation, en del af Linux Foundation — så alle kan bidrage, gennemgå og adoptere den.
• Indholdet er organiseret i emneområder (domæner), der hver repræsenterer et stort forretningskoncept, med designs udgivet i flere formater, inklusive eksempeldiagrammer.
• CIM er en model, ikke et produkt. Den definerer betydning og struktur; du vælger stadig selv, hvordan du kortlægger, lagrer og flytter data i dine egne systemer.

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-premises-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.

Hvorfor applikationsspecifikke datamodeller bryder sammen

Kerneproblemet, som CIM adresserer, er ikke, at en enkelt applikation har en dårlig datamodel. De fleste er helt rimelige inden for deres egne grænser. Problemet er den kombinatoriske eksplosion, der sker, når man forbinder mange af dem.

Overvej en typisk virksomhedsstabel: et CRM, et ERP, en marketingautomatiseringsplatform, en supportdesk, et datavarehus og en håndfuld line-of-business SaaS-værktøjer. Hvis hvert system har sin egen forestilling om “kunde”, “konto”, “ordre” og “produkt”, så kræver hvert par af systemer, der skal dele data, sin egen kortlægning. Antallet af integrationer vokser nogenlunde med kvadratet af antallet af systemer, og hver kortlægning er et lille, udokumenteret og uejet stykke logik, som nogen skal vedligeholde for evigt.

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

Symptomerne er velkendte for alle, der har drevet en integrationspraksis:

• Semantisk drift. “Kunde” i CRM-systemet betyder en faktureringsenhed; i supportdesken betyder det en person, der opretter tickets. Det samme ord, to betydninger, stille forenet af en kortlægning, som ingen husker at have skrevet.
• Skrøbelige pipelines. En leverandør omdøber et felt eller ændrer en enum, og et ETL-job fejler kl. 02.00, fordi kortlægningen var hårdkodet efter den gamle struktur.
• Duplikeret indsats. To teams bygger uafhængigt næsten identiske oversættelser mellem de samme to systemer, fordi der ikke er nogen fælles reference at pege på.
• Vendor lock-in via data. At migrere væk fra en platform er dyrt, ikke på grund af softwaren, men på grund af den akkumulerede oversættelseslogik, der er knyttet til dens skema.

En delt, applikations-agnostisk model angriber hovedårsagen: I stedet for N-til-N-kortlægninger kortlægger hvert system én gang til en fælles model, og den fælles model bærer betydningen.

Hvad “Application-Agnostic” faktisk betyder

Det er værd at være præcis omkring designfilosofien, fordi “agnostisk” ofte bruges løst.

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

En applikations-agnostisk model er ikke ejet af, eller optimeret til, en enkelt leverandørs produkt. Den beskriver forretningskoncepter i termer, der ville være genkendelige for en domæneekspert — en kunde, en ordre, et produkt, en lokation — snarere end i termer, der afspejler én applikations interne tabeller. Denne neutralitet er det, der gør den til et nyttigt hub: ingen deltager behøver at adoptere en konkurrents verdensbillede for at kunne interoperere.

Dette er det samme arkitektoniske instinkt bag andre neutrale udvekslingsstandarder. Ligesom Resource Description Framework (RDF) og schema.org giver nettet et fælles vokabular til at beskrive ting, og ligesom EDI og senere UBL (Universal Business Language, en OASIS-standard) gav forsyningskæder et fælles format for transaktioner, sigter CIM mod at give virksomhedsapplikationer et fælles vokabular for deres kerneforretningsenheder. Forskellen er omfang og modernitet: CIM retter sig mod den forbundne, API-drevne cloud- og on-premises-verden frem for batch-filudveksling.

En nyttig mental model er mønsteret med en kanonisk datamodel fra virksomhedsintegration, populariseret i Gregor Hohpe og Bobby Woolfs Enterprise Integration Patterns. CIM er i virkeligheden en samarbejdsdrevet kanonisk model — “hubben” i en hub-and-spoke integrationstopologi — men en, der er åben, versioneret og delt på tværs af organisationer i stedet for at være opfundet privat i én virksomhed.

Hvordan CIM er organiseret: Emneområder og domæner

Samarbejdsdefineret 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.

I praksis betyder det, at du bør tænke på CIM som et bibliotek af relaterede modeller snarere end et enkelt monolitisk skema. Typiske emneområder klynger sig omkring genkendelige forretningsbehov – for eksempel parter og konti, produkter og kataloger, ordrer og transaktioner, samt de relationer, der binder dem sammen. Fordi hvert område udgives med diagrammer og maskinlæsbare definitioner, kan forskellige teams adoptere forskellige områder på forskellige tidspunkter uden at vente på, at hele modellen er færdig.

Et par praktiske implikationer følger af denne struktur:

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

• Adopter trinvist. Du behøver ikke at kortlægge hele din virksomhed til CIM på dag ét. Start med det emneområde, der gør mest ondt – normalt kunde- eller ordredomænet – og udvid derfra.
• Udvid i stedet for at forgrene (fork). Når CIM mangler et koncept, du har brug for, er den åbne model designet til at blive udvidet. At bidrage med en udvidelse tilbage er at foretrække frem for at vedligeholde en privat fork, fordi en fork driver væk og mister interoperabilitetsfordelen.
• Behandl diagrammer som dokumentation, ikke som kilden til sandhed (source of truth). Eksempeldiagrammerne er til mennesker; de maskinlæsbare definitioner er det, dit værktøj skal forbruge.

CIM i integrationslandskabet: Sådan beslutter du

CIM er én mulighed blandt flere til at tæmme integrationskompleksitet. At vælge rigtigt kræver, at værktøjet matches til problemet. Tabellen nedenfor kontrasterer de vigtigste tilgange, som en virksomhedsdataarkitekt typisk overvejer.

Tilgang	Hvad er det	Bedst når	Hovedafvejning
Punkt-til-punkt-kortlægning	Brugerdefineret kode, der oversætter direkte mellem to systemer	Kun to systemer, stabile skemaer, kort tidshorisont	Skalerer ikke; N-til-N eksplosion; skrøbelig
Kanonisk model (f.eks. CIM)	En delt, neutral model, som hvert system kortlægges til én gang	Mange systemer, på tværs af leverandører, langvarig integration	Forudgående modelleringsindsats; governance nødvendig
Vendor iPaaS-connectorer	Forudbyggede connectorer fra en integrationsplatform	Almindelige SaaS-par, hastighed over kontrol	Connector-specifik semantik; potentiel lock-in
Industri-udvekslingsstandarder (EDI, UBL, HL7 osv.)	Domænespecifikke meddelelsesformater	Regulerede eller veletablerede vertikaler	Snævert anvendelsesområde; ofte batch-orienteret
Datavirtualisering / føderation	Forespørg på tværs af kilder uden centralisering	Analytics, primært læseadgang	Løser ikke semantiske konflikter i sig selv

Beslutningsheuristikken er ligetil: hvis du har mere end en håndfuld systemer, der skal være enige om betydningen af delte enheder, og disse systemer kommer fra forskellige leverandører, betaler en kanonisk model sig selv. Hvis du har to systemer og ingen planer om at tilføje flere, er punkt-til-punkt fint. Hvis dit behov er rent analytisk og skrivebeskyttet, kan føderation være tilstrækkeligt – men bemærk, at føderation flytter det semantiske problem snarere end at løse det.

CIM er komplementær til, ikke en erstatning for, værktøjerne omkring det. En ETL- eller ELT-pipeline (bygget med noget som Apache Airflow, dbt eller en kommerciel platform) står stadig for flytningen; CIM definerer, hvad dataene betyder, når de ankommer. En message broker som Apache Kafka står stadig for transporten; CIM definerer begivenhedernes form. Modellen er kontrakten; værktøjerne er VVS-installationen.

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

Governance, licensering og hvorfor fonden betyder noget

CIM er open source som en del af Joint Development Foundation, som opererer under Linux Foundation. Dette er ikke en triviel detalje – det er centralt for, hvorfor en virksomhed trygt kan bygge på CIM.

Linux Foundation er et veletableret neutralt hjem for kollaborative open source-projekter, og Joint Development Foundation giver en letvægts juridisk struktur til at udvikle standarder og specifikationer i samarbejde. At hoste CIM der betyder:

• Neutral forvaltning. Ingen enkelt leverandør kontrollerer modellen, så at adoptere den betyder ikke, at man adopterer en konkurrents roadmap.
• Åbne bidrag. Alle – leverandører, virksomheder, individuelle bidragydere – kan foreslå ændringer, og processen er gennemsigtig.
• Forudsigelig licensering. Foundation-hostede specifikationer bærer typisk vilkår, der er designet til bred, royalty-venlig adoption, hvilket betyder enormt meget for juridiske teams og indkøbsafdelinger, der evaluerer en standard.

For en arkitekt, der skal argumentere for det internt, er denne governance-historie ofte lige så vigtig som det tekniske indhold. “Det er en åben standard under Linux Foundation” besvarer de spørgsmål, der dræber adoptionen af standarder: Hvem kontrollerer det? Hvad sker der, hvis en leverandør udtræder? Kan vi bidrage med vores egne udvidelser?

Kom godt i gang: En praktisk adoptionsvej

At adoptere en fælles model er lige så meget en organisatorisk øvelse, som det er en teknisk. En pragmatisk sekvens ser således ud:

1. Kortlæg dine delte enheder. Identificer de forretningskoncepter, der optræder i mere end ét system – normalt kunde, produkt, ordre og lokation. Disse er dine kandidater.
2. Vælg ét emneområde og én integration. Vælg den integration, der giver mest smerte, men har den mindste “blast radius”, for at bevise modellen. En enkelt rapporteringspipeline eller onboarding af én ny applikation er ideelt.
3. Kortlæg hvert system til CIM én gang. Byg oversættelsen fra hvert kildesystem til CIM-repræsentationen, og fra CIM til hvert mål. Modstå trangen til at kortlægge system-til-system direkte.
4. Dokumenter dine udvidelser. Hvor CIM ikke dækker et koncept, skal udvidelsen registreres eksplicit, og du bør overveje at bidrage med den tilbage.
5. Etabler ejerskab. En kanonisk model uden en steward forfalder. Tildel et team eller en rolle ansvaret for kortlægningerne og for at spore upstream-ændringer.
6. Versionering og test. Behandl modellen og dens kortlægninger som versionerede artefakter med tests, præcis som du ville gøre med applikationskode.

Den mest almindelige fejltilstand er at behandle CIM som en engangsmodelleringsøvelse snarere end en levende kontrakt. De organisationer, der lykkes, behandler modellen, som de behandler en API: versioneret, testet, ejet og udviklet bevidst.

Partnere, der bidrager til CIM

CIM er en konsortiumindsats, og dens værdi vokser med deltagelse. Partnere bidrager med indhold til emneområder, gennemgår forslag og hjælper med at forme modellens retning. Fordi arbejdet er åbent, er bidrag ikke begrænset til store leverandører – virksomheder med reelle integrationsproblemer og individuelle praktikere med domæneekspertise er lige så velkomne.

Tag kontakt

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

Ofte stillede spørgsmål

Hvad er Cloud Information Model (CIM)?

CIM er en applikations-agnostisk open source-datamodel, der giver et fælles, standardbaseret ordforråd til de forretningskoncepter, virksomheder skal udveksle på tværs af cloud- og on-premises applikationer. Den er produceret af et åbent konsortium og hostet under Joint Development Foundation, en del af Linux Foundation. Dens formål er at reducere den brugerdefinerede kortlægningskode, som skrøbelige punkt-til-punkt integrationer kræver.

Er CIM et produkt eller en specifikation?

CIM er en specifikation – en model og et sæt definitioner – ikke et eksekverbart produkt. Den definerer betydningen og strukturen af delte enheder; du vælger stadig dine egne ETL/ELT-værktøjer, message brokers og lagring. Tænk på det som den kontrakt, som din integrations-infrastruktur implementerer, snarere end selve infrastrukturen.

Hvordan adskiller CIM sig fra en leverandørs integrationsplatform?

En integrationsplatform (en iPaaS eller et connector-bibliotek) flytter data og leverer ofte præfabrikerede connectors, men disse connectors koder for leverandørspecifik semantik. CIM er neutral og leverandøruafhængig, så den låser dig ikke fast i én platforms verdensbillede. De to er komplementære: du kan bruge CIM som den kanoniske model inde i enhver integrationsplatform.

Hvad er emneområder i CIM?

Emneområder (også kaldet domæner) er de organiserende enheder i modellen, hvor hver repræsenterer et større forretningskoncept såsom kunder, produkter eller ordrer. Designs udgives i flere formater, inklusive eksempeldiagrammer, og sættet af emneområder forventes at vokse i takt med, at konsortiet og community’et bidrager med mere indhold.

Kan vi udvide CIM, hvis det ikke dækker vores koncepter?

Ja. CIM er designet til at kunne udvides, og fordi det er open source under en neutral foundation, kan du foreslå tilføjelser gennem bidragsprocessen. At udvide den delte model og bidrage tilbage er stærkt at foretrække frem for at vedligeholde en privat fork, som over tid driver væk og mister den interoperabilitetsfordel, der motiverede adoptionen af CIM i første omgang.

Hvem bør adoptere CIM?

Det er mest værdifuldt for organisationer, der kører mange applikationer fra forskellige leverandører, som skal være enige om betydningen af delte enheder – den klassiske situation for enterprise-dataarkitekter og integrationsingeniører. Applikations- og platformsleverandører drager også fordel af at tilpasse deres skemaer til en neutral model, hvilket gør deres produkter lettere for kunderne at integrere. Hvis du kun har to stabile systemer, kan en enklere punkt-til-punkt kortlægning være tilstrækkelig.

Yderligere læsning

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