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

ברוכים הבאים ל-CIM, מודל נתונים אגנוסטי ליישומים (application-agnostic) המפשט אינטגרציה ומאיץ חדשנות.

נקודות מפתח

• CIM הוא מודל נתונים פתוח ואגנוסטי ליישומים — אוצר מילים משותף של מושגים עסקיים (לקוחות, הזמנות, מוצרים וכן הלאה) המאפשר למערכות ענן שונות ולמערכות מקומיות (on-premises) להחליף נתונים ללא מיפוי נקודתי (point-to-point) מותאם אישית.
• הוא קיים כדי לפתור בעיה ספציפית ויקרה: כל אפליקציה מספקת מודל נתונים משלה, כך שצוותי האינטגרציה נאלצים לכתוב ולתחזק קוד תרגום מותאם אישית שהוא שביר ומאט את החדשנות.
• הוא מנוהל כתקן פתוח, מיוצר על ידי קונסורציום ומופץ כקוד פתוח תחת Joint Development Foundation, חלק מקרן לינוקס (Linux Foundation) — כך שכל אחד יכול לתרום, לסקור ולאמץ אותו.
• התוכן מאורגן בתחומי נושא (Subject Areas/domains), שכל אחד מהם מייצג מושג עסקי מרכזי, עם עיצובים שפורסמו במספר פורמטים, כולל דיאגרמות לדוגמה.
• CIM הוא מודל, לא מוצר. הוא מגדיר משמעות ומבנה; אתם עדיין בוחרים כיצד למפות, לאחסן ולהעביר נתונים במערכות שלכם.

תקן חדש ליכולת פעולה הדדית של נתונים (Data Interoperability)

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

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

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

מדוע מודלים ספציפיים ליישום קורסים

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

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

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

התסמינים מוכרים לכל מי שניהל פרקטיקת אינטגרציה:

• סחף סמנטי (Semantic drift). “לקוח” ב-CRM פירושו ישות חיוב; בדלפק התמיכה זהו אדם שפותח קריאות. אותה מילה, שתי משמעויות, המיושבות בשקט על ידי מיפוי שאיש לא זוכר שכתב.
• צינורות נתונים שבירים. ספק משנה שם של שדה או משנה ערך ב-enum, ותהליך ETL נכשל ב-2 לפנות בוקר כי המיפוי היה מקודד קשיח (hard-coded) מול המבנה הישן.
• כפילות במאמץ. שני צוותים בונים באופן עצמאי תרגומים כמעט זהים בין אותן שתי מערכות מכיוון שאין נקודת התייחסות משותפת.
• נעילת ספקים (Vendor lock-in) באמצעות נתונים. הגירה מפלטפורמה היא יקרה לא בגלל התוכנה, אלא בגלל לוגיקת התרגום המצטברת הקשורה לסכימה שלה.

מודל משותף ואגנוסטי ליישומים תוקף את סיבת השורש: במקום מיפויים של N-to-N, כל מערכת ממפה פעם אחת למודל משותף, והמודל המשותף נושא את המשמעות.

מה המשמעות של “אגנוסטי ליישומים” בפועל

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

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

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

זהו אותו אינסטינקט אדריכלי שמאחורי תקני חילוף ניטרליים אחרים. בדיוק כפי ש-Resource Description Framework (RDF) ו-schema.org מעניקים לאינטרנט אוצר מילים משותף לתיאור דברים, ובדיוק כפי ש-EDI ומאוחר יותר UBL (Universal Business Language, תקן OASIS) נתנו לשרשראות אספקה פורמט משותף לעסקאות, CIM שואף לתת ליישומים ארגוניים אוצר מילים משותף לישויות העסקיות המרכזיות שלהם. ההבדל הוא בהיקף ובמודרניות: CIM פונה לעולם המחובר, מונע API, בענן ובאתר המקומי, ולא להחלפת קבצי אצווה (batch).

מודל מנטלי שימושי הוא דפוס מודל הנתונים הקנוני (canonical data model) מאינטגרציה ארגונית, שהפך לפופולרי בספר Enterprise Integration Patterns של Gregor Hohpe ו-Bobby Woolf. CIM הוא, למעשה, מודל קנוני המתוחזק בשיתוף פעולה — ה”רכז” (hub) בטופולוגיית אינטגרציה של hub-and-spoke — אך כזה שהוא פתוח, מנוסח בגרסאות ומשותף בין ארגונים, במקום להיות המצאה פרטית בתוך חברה אחת.

כיצד מאורגן CIM: תחומי נושא ודומיינים

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

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

מספר השלכות מעשיות נובעות ממבנה זה:

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

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

CIM בנוף האינטגרציה: כיצד להחליט

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

גישה	מה זה	מומלץ כאשר	פשרה עיקרית
מיפוי מנקודה לנקודה (Point-to-point)	קוד מותאם אישית המתרגם ישירות בין שתי מערכות	רק שתי מערכות, סכמות יציבות, אופק זמן קצר	אינו ניתן להרחבה (scale); פיצוץ של N-to-N; שביר
מודל קנוני (למשל, CIM)	מודל משותף ונייטרלי שכל מערכת ממפה אליו פעם אחת	מערכות רבות, מספר ספקים, אינטגרציה ארוכת טווח	מאמץ מידול מוקדם; נדרש ממשל (governance)
מחברי iPaaS של ספקים	מחברים מובנים מראש מפלטפורמת אינטגרציה	צמדי SaaS נפוצים, מהירות על פני שליטה	סמנטיקה ספציפית למחבר; פוטנציאל לנעילה (lock-in)
תקני חילופי נתונים בתעשייה (EDI, UBL, HL7 וכו’)	פורמטים של הודעות ספציפיים לתחום	מגזרים מוסדרים או מבוססים היטב	היקף צר; לעיתים קרובות מבוסס אצוות (batch)
וירטואליזציה של נתונים / פדרציה	שאילתות על פני מקורות ללא ריכוז נתונים	אנליטיקה, גישה לקריאה בלבד בעיקר	אינו פותר קונפליקטים סמנטיים בעצמו

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

CIM הוא משלים, ולא תחליף, לכלים שסביבו. צינור ETL או ELT (שנבנה עם כלים כמו Apache Airflow, dbt או פלטפורמה מסחרית) עדיין מבצע את ההעברה; CIM מגדיר מה משמעות הנתונים ברגע שהם מגיעים. מתווך הודעות כמו Apache Kafka עדיין מבצע את ההובלה; CIM מגדיר את צורת האירועים. המודל הוא החוזה; הכלים הם הצנרת.

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

ממשל, רישוי ומדוע הקרן חשובה

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

ה-Linux Foundation היא בית ניטרלי ומבוסס לפרויקטים שיתופיים של קוד פתוח, וה-Joint Development Foundation מספקת מבנה משפטי קל משקל לפיתוח תקנים ומפרטים בשיתוף פעולה. אירוח CIM שם פירושו:

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

עבור ארכיטקט המציג את הטיעונים פנימית, סיפור הממשל הזה חשוב לעיתים קרובות כמו התוכן הטכני. המשפט “זהו תקן פתוח תחת ה-Linux Foundation” עונה על השאלות שחוסמות אימוץ של תקנים: מי שולט בו? מה קורה אם ספק יוצא מהמשחק? האם נוכל לתרום את ההרחבות שלנו?

תחילת העבודה: נתיב אימוץ מעשי

אימוץ מודל משותף הוא תרגיל ארגוני בדיוק כמו תרגיל טכני. רצף פרגמטי נראה כך:

1. בצעו מלאי של הישויות המשותפות שלכם. זהו את המושגים העסקיים המופיעים ביותר ממערכת אחת — בדרך כלל לקוח, מוצר, הזמנה ומיקום. אלו הם המועמדים שלכם.
2. בחרו תחום נושא אחד ואינטגרציה אחת. בחרו את האינטגרציה עם רמת הכאב הגבוהה ביותר ורדיוס ההשפעה (blast radius) הנמוך ביותר כדי להוכיח את המודל. צינור דיווח יחיד או קליטה של אפליקציה חדשה אחת הם אידיאליים.
3. מפו כל מערכת ל-CIM פעם אחת. בנו את התרגום מכל מערכת מקור לייצוג ה-CIM, ומ-CIM לכל יעד. התנגדו לדחף למפות מערכת למערכת באופן ישיר.
4. תעדו את ההרחבות שלכם. במקומות שבהם CIM אינו מכסה מושג, רשמו את ההרחבה במפורש ושקלו לתרום אותה חזרה.
5. הגדירו בעלות. מודל קנוני ללא מנהל (steward) דועך. הקצו צוות או תפקיד האחראי על המיפויים ועל מעקב אחר שינויים במעלה הזרם (upstream).
6. ניהול גרסאות ובדיקות. התייחסו למודל ולמיפויים שלו כאל תוצרים מנוסחים (versioned artifacts) עם בדיקות, בדיוק כפי שהייתם מתייחסים לקוד של אפליקציה.

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

שותפים התורמים ל-CIM

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

צור קשר

האם אתם מעוניינים להצטרף ליוזמת CIM? נהדר! אתם מוזמנים לשלוח לנו דוא”ל לקבלת מידע נוסף. שלחו לנו דוא”ל.

שאלות נפוצות

מהו מודל המידע בענן (CIM)?

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

האם CIM הוא מוצר או מפרט?

CIM הוא מפרט — מודל ומערכת של הגדרות — ולא מוצר בר-הפעלה. הוא מגדיר את המשמעות והמבנה של ישויות משותפות; אתם עדיין בוחרים את כלי ה-ETL/ELT, מתווכי ההודעות (message brokers) ואת האחסון שלכם. חשבו על זה כעל החוזה שצנרת האינטגרציה שלכם מיישמת, ולא על הצנרת עצמה.

במה שונה CIM מפלטפורמת אינטגרציה של ספק?

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

מהם תחומי נושא (Subject Areas) ב-CIM?

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

האם נוכל להרחיב את CIM אם הוא לא מכסה את המושגים שלנו?

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

מי צריך לאמץ את CIM?

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

קריאה נוספת

• Linux Foundation — ויקיפדיה
• Joint Development Foundation — ויקיפדיה
• Enterprise Integration Patterns — ויקיפדיה
• Resource Description Framework (RDF) — ויקיפדיה