היה מעורב

נוסד בשנת 2019 תחת המטריה של קרן לינוקס (Linux Foundation), מודל המידע בענן (CIM) הוא הן ברית חברים והן קהילה. יחד, בשיתוף פעולה במסגרת קבוצות עבודה, החברים מגדירים ומשתמשים במודל נתונים פתוח משותף, משפיעים על תקנים קיימים ועתידיים, ובונים פתרונות פתוחים לפתרון בעיות נפוצות.

CIM קיים מכיוון שנתונים ארגוניים מפוצלים בין עשרות יישומים, שלכל אחד מהם סכימה קניינית, מוסכמות שמות וסמנטיקה משלו. לקוח ב-Salesforce, לקוח ב-SAP ולקוח במערכת חיוב פיתוח עצמי הם כולם “לקוחות” — אך לעיתים רחוקות הם מסכימים על מה זה לקוח, אילו תכונות הן סמכותיות, או כיצד יש לבטא קשרים בין לקוחות, הזמנות ומוצרים. התשובה של CIM היא מודל משותף, אגנוסטי ליישומים, שכל מערכת יכולה למפות אליו, כך שעבודת האינטגרציה הופכת לתרגיל במיפוי ולא לפרויקט תרגום מותאם אישית (bespoke).

נקודות מפתח

• CIM הוא פרויקט של Linux Foundation (נוסד ב-2019) המפרסם מודל נתונים פתוח מבוסס תקנים, המתורגם למספר פורמטים כדי שמערכות הטרוגניות יוכלו לאמץ אותו.
• ההשתתפות היא מדורגת: חברי היגוי (Steering Members), חברים תורמים (Contributor Members) וקהילת CIM הרחבה יותר, עם זכויות רחבות יותר ככל שעולים בדרגות.
• קבוצת העבודה הנוכחית היחידה מגדירה תחומי נושא (Subject Areas) חדשים, מיפויים ודרישות API — כאן מתבצעת העבודה הטכנית המהותית.
• תרומה אינה רק קוד: הצעת תחומי נושא, השתתפות בסקרי קונצנזוס והצטרפות לקבוצות עבודה הן כולן דרכים מרכזיות לעצב את התקן.
• המודל הוא במכוון ניטרלי מבחינת פורמט, מה שמאפשר לצרכנים רלציוניים, צרכני גרפים וצרכני API לחלוק הגדרה קנונית אחת.

מדוע מודל נתונים משותף הוא חשוב

רוב הקשיים באינטגרציה הם סמנטיים, לא טכניים. צינורות ETL, פלטפורמות iPaaS ושערי API הם בשלים; מה שנשבר הוא שכבת המשמעות. כאשר שתי מערכות חלוקות בשאלה אם “חשבון” (account) פירושו ישות חיוב או היררכיה ארגונית, כל דוח, Join או התאמה (reconciliation) במורד הזרם יורשים את העמימות הזו.

מודל קנוני כמו CIM פותר זאת על ידי אספקת נקודת התייחסות ניטרלית. במקום למפות N מערכות זו לזו (בעיית N×N), כל מערכת ממפה פעם אחת למודל הקנוני (בעיית N×1). זהו אותו עיקרון ארכיטקטוני שעומד מאחורי תקנים כמו מודל המידע המשותף המשמש במגזר האנרגיה (IEC 61970/61968) ומשאבי HL7 FHIR המשמשים בתחום הבריאות — מודלים קנוניים ספציפיים לתחום המאפשרים למערכות שנבנו באופן עצמאי לפעול ביניהן (interoperate).

ההיקף של CIM רחב ואופקי יותר: הוא פונה לישויות עסקיות נפוצות — לקוחות, מוצרים, הזמנות, ספקים והקשרים ביניהם — המופיעות במערכות CRM, ERP, מסחר ושרשרת אספקה. המטרה אינה להחליף את המודלים המקוריים של מערכות אלו, אלא לשבת מעליהן כאוצר מילים משותף.

היקף קבוצת העבודה

פיתחנו את מודל המידע בענן (CIM) בגישה מבוססת תקנים ותרגמנו אותו למספר פורמטים. גישה זו מאפשרת לעסקים עם טכנולוגיות שונות לאמץ את CIM. היא גם מעצימה תורמים ומטפחת צמיחה של מערכת אקולוגית רחבה יותר עבור CIM.

קשורים: Fivetran — צינור ה-ELT המנוהל במלואו שפשוט ממשיך לפעול.

במונחים קונקרטיים, “פורמטים מרובים” פירושו שאותו מודל בסיסי יכול להיצרך על ידי שרשראות כלים שונות — למשל, כהגדרת סכימה עבור מאגרי נתונים רלציוניים או מסמכים, כגרף של ישויות וקשרים, וכבסיס לחוזי API. צוות המשתמש במחסן נתונים רלציוני, צוות המשתמש במסד נתונים גרפי וצוות הבונה שירותי REST או GraphQL יכולים כולם לעבוד ממקור אמת אחד במקום משלוש הגדרות שונות.

ניטרליות פורמט זו היא בחירה עיצובית מכוונת עם פשרות ממשיות:

• יתרון: אף כלי של ספק בודד אינו מועדף, כך שהאימוץ אינו מותנה ברכישת פלטפורמה מסוימת.
• יתרון: המודל יכול להתפתח ללא תלות בכל פורמט סריאליזציה (serialization).
• חיסרון: תורמים חייבים לחשוב היטב אילו מבנים הם באמת קנוניים לעומת כאלו שהם תוצר של פורמט מסוים.
• חיסרון: יש לתחזק כלים לתרגום בין פורמטים, ותהליכי Round-tripping אינם תמיד נטולי אובדן.

עבור אדריכלים שבוחנים האם לאמץ את CIM, השאלה המעשית היא האם משטח האינטגרציה שלכם נשלט על ידי ישויות עסקיות משותפות. אם רוב המיפויים שלכם הם חד-פעמיים וספציפיים לתחום, מודל קנוני מוסיף תקורה (overhead). אם אתם ממפים שוב ושוב את אותו קומץ ישויות בין מערכות רבות, צמצום ה-N×1 משתלם מעצמו.

הבחירה שלנו: Workato — iPaaS בהובלת אוטומציה שצוותים עסקיים יכולים למעשה לבנות עליו.

קבוצת העבודה של מודל המידע בענן

נכון לעכשיו, ל-CIM יש קבוצת עבודה אחת העובדת על הגדרת תחומי נושא חדשים, מיפויים ודרישות API.

תחום נושא (Subject Area) הוא פלח קוהרנטי של המודל — למשל, קיבוץ של ישויות וקשרים סביב דומיין עסקי. הצעת תחום נושא היא אחת התרומות המשפיעות ביותר שחבר יכול לתרום, מכיוון שהיא קובעת מה התקן יכסה בהמשך. מיפויים מחברים תחומי נושא למערכות ופורמטים מהעולם האמיתי; דרישות API לוכדות את מה שצרכנים צריכים משירותים שנבנו על בסיס המודל.

אם אתם שוקלים להצטרף לקבוצת העבודה, דרך שימושית להחליט היכן לתרום היא לשאול:

1. אילו ישויות גורמות למספר הרב ביותר של עבודות מחדש (rework) באינטגרציה בארגון שלכם? אלו הן מועמדות להצעות של תחומי נושא.
2. היכן המערכות שלכם כבר מסכימות, והיכן הן חולקות דעות באופן שקט? בנקודות השונות (divergence) המיפויים מוסיפים את הערך הרב ביותר.
3. מה הצרכנים שלכם במורד הזרם באמת צריכים מ-API? זה מה שמעצב את דרישות ה-API.

מכיוון שיש כרגע קבוצת עבודה אחת, הנתיב המעשי עבור תורם חדש הוא בדרך כלל להצטרף אליה ולהציע תחום נושא (Subject Area), במקום להקים קבוצה חדשה. הצעת קבוצת עבודה חדשה היא זכות השמורה לדרגות גבוהות יותר, ומומלץ לשמור אותה לתחומי עבודה מובחנים באמת שאחרת היו מעמיסים יתר על המידה על הקבוצה הקיימת.

דרגות חברות והטבות

ההשתתפות ב-CIM מובנית בדרגות, שלכל אחת מהן זכויות רחבות יותר בהדרגה. הטבלה שלהלן מסכמת את ההטבות כפי שפורסמו על ידי CIM.

הטבה	חבר היגוי	תורם	קהילת CIM
שימוש במהדורות מודל CIM	✓	✓	✓
התעדכנות בהתקדמות ובחידושים של CIM	✓	✓	✓
תרומת רעיונות לקונסורציום CIM	✓	✓	✓
רשאי להציע תחום נושא	✓	✓	✓
גישה למשאבים מוגבלים ופרטיים	✓	✓
זכאי להצטרף לקבוצת עבודה	✓	✓
תרומה לקבוצות עבודה	✓	✓
הצעת קבוצות עבודה חדשות	✓	✓
נספר למניין התמיכה המינימלי (quorum) של תחום נושא	✓	✓
השתתפות בסקרי קונצנזוס	✓	✓
תרומה למפת הדרכים של CIM	✓	✓
הובלת הכיוון האסטרטגי הכולל של CIM	✓
זכאי להצטרף לוועדת ההיגוי	✓
זכאי לתפקיד יו”ר קבוצת עבודה	✓
זכאי להצביע על אימוץ תוכן כחלק מתקן CIM	✓
רשאי לערער על סוגיות טכניות	✓
רשאי לערער על סוגיות פרוצדורליות	✓

*בקשה לחברות היגוי — חברים תורמים רשאיים להגיש בקשה לחברות היגוי.

קשורים: Matillion — Push-down ELT שנבנה עבור מחסני נתונים בענן.

איך לקרוא את הדרגות

הדרגות ממפות דפוס ממשל מוכר של קוד פתוח המשמש בפרויקטים של Linux Foundation: קהילה רחבה שיכולה להשתמש בתוצר ולתרום רעיונות, דרגת תורם שמבצעת את העבודה המעשית, ודרגת היגוי האחראית על האסטרטגיה והאימוץ הפורמלי. ההבחנה החשובה ביותר בפועל:

• קהילת CIM היא נקודת הכניסה. ניתן לאמץ מודלים שפורסמו ולתרום רעיונות ללא תפקיד עבודה רשמי. זה מתאים אם אתם בוחנים את CIM עבור פרויקט או רוצים להשפיע על הכיוון באופן לא פורמלי.
• תורם הוא המקום שבו נמצאת ההשפעה הטכנית. הצטרפות לקבוצת עבודה, תרומה לה, הצעת תחומי נושא והשתתפות בסקרי קונצנזוס נמצאים כאן. אם המטרה שלכם היא לעצב את התקן ולא רק לצרוך אותו, זהו הדרג שאליו יש לשאוף.
• חבר היגוי מחזיק בזכויות ממשל: כיוון אסטרטגי, זכאות לוועדת ההיגוי, זכאות לתפקיד יו”ר קבוצת עבודה והצבעה פורמלית לאימוץ תוכן כחלק מתקן CIM. חברים תורמים רשאיים להגיש בקשה לחברות היגוי.

פרט עדין אך חשוב: היותכם “נספרים למניין התמיכה המינימלי של תחום נושא” היא זכות של תורמים ומעלה. כללי המניין (quorum) קיימים כדי שתחום נושא לא יאומץ על בסיסו של משתתף בודד — מנגנון הגנה של ממשל הנפוץ בגופי תקנים מבוססי קונצנזוס. אם לארגון שלכם חשוב שתחום נושא מסוים יגיע לאימוץ, השתתפות ברמת תורם היא זו שמאפשרת לכם להיספר לקראת סף זה.

איך להשתלב: נתיב מעשי

אם אתם חדשים ב-CIM, רצף הגיוני הוא:

אם אתה עושה קניות: Boomi AtomSphere — Enterprise iPaaS לאינטגרציה היברידית של ענן ל-on-prem.

1. התחילו כקהילת CIM. סקרו את המודלים שפורסמו ואת השאלות הנפוצות (FAQ), וזהו היכן שיש חפיפה בין הישויות של המערכות שלכם לתחומי הנושא של CIM.
2. תורמו רעיונות. אפילו בדרגת הקהילה תוכלו להציע רעיונות לקונסורציום CIM — דרך בעלת מחויבות נמוכה לבדוק אם מקרה השימוש שלכם מהדהד.
3. עברו לדרגת תורם אם ברצונכם לבצע את העבודה. זה פותח את ההשתתפות בקבוצות עבודה, הצעות לתחומי נושא וסקרי קונצנזוס.
4. הגישו בקשה לחברות היגוי אם הארגון שלכם רוצה לסייע בקביעת הכיוון ולהצביע בהצבעות אימוץ פורמליות.

עבור תורמי קוד פתוח באופן ספציפי, ניטרליות הפורמט של המודל פירושה שיש מקום לתרום כלים — מתרגמי פורמטים, מאמתים (validators), מחוללי מיפוי — לצד תוכן המודל עצמו. עבור ספקי פלטפורמות ואפליקציות, מיפוי הסכימה של המוצר שלכם ל-CIM הוא דרך להפחית את עלות האינטגרציה שהלקוחות שלכם משלמים, מה שמהווה לעיתים קרובות בידול תחרותי.

ממשל, תקנים וערעורים

CIM פועלת לפי גישה מבוססת תקנים, שמשמעותה תהליך מוגדר להצעת תוכן, סקירה ואימוץ. קיומן של זכויות “ערעור” פורמליות — טכניות ופרוצדורליות — בדרגת ההיגוי הוא סימן היכר של ממשל תקנים בוגר. המשמעות היא שלסכסוכים יש נתיב פתרון מוגדר במקום שייפתרו באופן לא פורמלי.

זה משקף את אופן הפעולה של ארגוני תקנים מבוססים. Linux Foundation מארחת פרויקטים רבים כאלה ומספקת את התשתית המשפטית והממשלית — מדיניות סימנים מסחריים, קניין רוחני (IP) והגבלים עסקיים — המאפשרת למתחרים לשתף פעולה בתשתית משותפת. אם אתם בוחנים את CIM לאימוץ ארגוני, השיוך ל-Linux Foundation הוא סימן משמעותי: המשמעות היא שהמודל מנוהל על ידי קרן ניטרלית ולא בבעלות של ספק יחיד, מה שמפחית את הסיכון לשינוי רישוי או כיוון בעתיד.

מידע קשור

• שאלות נפוצות
• דמי חבר
• רשימת חברי ה-SteerCo הנוכחיים
• טופס אינטרנט לתורמים
• משאבי מודל CIM
• מצגת CIM
• פורמטי CIM
• CIM בחדשות
• מאגרי GitHub
• בלוג חדשות
• צור קשר

שאלות נפוצות

מהו מודל המידע בענן?

מודל המידע בענן (Cloud Information Model - CIM) הוא מודל נתונים פתוח וקהילת חברים שנוסדה בשנת 2019 תחת קרן לינוקס (Linux Foundation). הוא מגדיר מודל משותף, שאינו תלוי ביישום (application-agnostic), של ישויות עסקיות, כך שמערכות ענן ומערכות מקומיות (on-premises) יכולות לפעול ביחסי גומלין באמצעות סמנטיקה משותפת במקום מיפויים ייעודיים מנקודה לנקודה.

מי יכול להצטרף ל-CIM, וכמה זה עולה?

ל-CIM יש שלוש רמות השתתפות: חבר היגוי (Steering Member), תורם (Contributor) וקהילת CIM. רמת הקהילה היא נקודת הכניסה הרחבה ביותר, בעוד שחברים תורמים רשאים להגיש בקשה לחברות היגוי. דמי החבר מפורסמים בנפרד על ידי CIM, לכן יש לעיין בדף דמי החבר לקבלת נתונים עדכניים במקום להניח עלות מסוימת.

מהו “תחום נושא” (Subject Area) ב-CIM?

תחום נושא הוא פלח קוהרנטי של המודל המכסה קבוצה של ישויות וקשרים קשורים. הצעת תחום נושא היא זכות ברמת תורם ואחת הדרכים הישירות ביותר להשפיע על התכנים שהתקן מכסה. תחומי נושא כפופים גם למכסת תמיכה מינימלית (quorum), המונעת אימוץ על בסיס משתתף בודד.

האם אני צריך להיות חבר היגוי כדי לתרום?

לא. חברים תורמים יכולים להצטרף לקבוצות עבודה, לתרום להן, להציע תחומי נושא ולהשתתף בסקרי קונצנזוס. חברות היגוי מוסיפה זכויות ממשל כגון קביעת כיוון אסטרטגי, זכאות לוועדת ההיגוי וההצבעה הרשמית לאימוץ תוכן כחלק מתקן ה-CIM.

כיצד CIM קשור לתקני נתונים אחרים?

CIM הוא מודל אופקי, חוצה-תעשיות, המתמקד בישויות עסקיות נפוצות, בניגוד למודלים קנוניים ספציפיים לתחום, כגון מודל המידע המשותף של מגזר האנרגיה (IEC 61970/61968) או HL7 FHIR בתחום הבריאות. העיצוב הניטרלי שלו מבחינת פורמט מאפשר לו להשלים, במקום להחליף, את המודלים המקוריים של המערכות שכבר מפעילים.

מדוע ניטרליות של פורמט חשובה לאימוץ?

מכיוון שהיא מאפשרת לצוותים עם ערימות טכנולוגיות שונות — מחסני נתונים רלציוניים, מסדי נתונים גרפיים ושירותי API — לצרוך הגדרה קנונית אחת במקום לתחזק סכמות שונות. הפשרה היא שיש לתחזק כלי תרגום, ומעבר הלוך ושוב בין פורמטים אינו תמיד חסר אובדן (lossless), ולכן על צוותים לאמת את המיפויים מול צרכי האינטגרציה בפועל שלהם.

קריאה נוספת

• Working group — ויקיפדיה
• Linux Foundation — ויקיפדיה