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

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

נקודות מפתח

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

תקן חדש ליכולת פעולה הדדית של נתונים

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

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

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

הבעיה ש-CIM פותר היא מבנית, לא מקרית. כאשר כל מערכת מדברת בדיאלקט משלה — אחת מכנה לקוח “איש קשר” (Contact), אחרת “צד” (Party), ושלישית “חשבון” (Account) — צוותי האינטגרציה נאלצים לתחזק רשת הולכת וגדלה של מיפויים זוגיים. כל יישום חדש מכפיל את מספר התרגומים הנדרשים, וכל שינוי בסכימה במערכת אחת עלול להשפיע על שאר המערכות ולשבור צינורות נתונים (pipelines) במורד הזרם. מודל קנוני משנה את צורת הבעיה: במקום ש-N מערכות ימפו זו לזו, כל מערכת ממפה פעם אחת לאוצר מילים משותף.

מדוע אינטגרציה מנקודה לנקודה קורסת

כדי להבין זאת, כדאי להתמקד במקרי הכישלון שמניעים את הצורך במודל משותף.

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

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

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

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

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

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

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

• צד / לקוח (Party / Customer) — האנשים והארגונים שאתם עושים איתם עסקים, והתפקידים שהם ממלאים.
• מוצר (Product) — מה שאתם מוכרים, מציעים או מנהלים, כולל קטלוגים וסיווגים.
• חשבון ומערכת יחסים (Account and relationship) — כיצד הצדדים קשורים למוצרים, לחוזים וזה לזה.
• אינטראקציה ופעילות (Interaction and activity) — האירועים, העסקאות וההתקשרויות שמחברים את הרכיבים לעיל.

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

כיצד CIM משתווה לגישות אחרות

CIM הוא אפשרות אחת מבין כמה להשגת יכולת פעולה הדדית. בחירה נכונה פירושה הבנת הפשרות (trade-offs).

גישה	מה זה	חוזקות	פשרות
מיפוי מנקודה לנקודה (Point-to-point)	תרגומים ישירים בין כל זוג מערכות	פשוט עבור שתי מערכות; אין צורך בממשל משותף	גדל באופן קומבינטורי; שביר; לוגיקה משוכפלת
מודל קנוני (בסגנון CIM)	אוצר מילים משותף, אגנוסטי ליישומים, שכל מערכת ממפה אליו	מאמץ מיפוי ליניארי; חוזה יציב; ניתן לשימוש חוזר בין פרויקטים	דורש ממשל והסכמה; עדיין נדרש מיפוי לכל מערכת
תקני נתונים תעשייתיים	תקנים אנכיים למגזר ספציפי (למשל, בריאות, פיננסים)	כיסוי עמוק של התחום; התאמה רגולטורית	היקף צר; עשוי שלא לכסות מושגים ארגוניים חוצי-תעשיות
מודלי נתונים של ספקים	סכימה מקורית של פלטפורמה המוצגת כמרכז האינטגרציה	אינטגרציה הדוקה של כלי עבודה; מהיר בתוך המערכת האקולוגית של ספק אחד	סיכון של נעילה (Lock-in); ספקים אחרים חייבים להתאים למודל של צד אחד
API-first / schema-on-read	חוזים המוגדרים לכל API; המשמעות נפתרת בזמן הצריכה	גמיש; מהיר להתחלה	עקביות סמנטית תלויה במשמעת; קשה יותר לניהול בקנה מידה רחב

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

כיצד לאמץ את CIM בפועל

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

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

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

ממשל, רישוי ותרומה

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

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

עבור ארכיטקט נתונים ארגוני, ההשלכות המעשיות של מודל ממשל זה הן:

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

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

מעורבות

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

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

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

שאלות נפוצות

מהו בדיוק מודל המידע בענן (Cloud Information Model)?

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

למי מיועד CIM?

הוא מיועד לארכיטקטי נתונים ארגוניים, מהנדסי אינטגרציה ו-ETL, ספקי יישומים ופלטפורמות, ותורמי קוד פתוח. כל מי שצריך לחבר מספר מערכות ענן ומערכות on-premise עם סכמות שונות הוא משתמש פוטנציאלי. ספקים מרוויחים מכך שמודל משותף מפחית את העבודה המותאמת אישית הנדרשת כדי להשתלב עם המוצרים שלהם.

כיצד מנוהל ומורשה CIM?

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

במה CIM שונה ממודל הנתונים המקורי (native) של ספק?

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

האם אני עדיין צריך לכתוב מיפויים אם אני משתמש ב-CIM?

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

איך אני מתחיל לאמץ את CIM?

התחל עם אינטגרציה אחת, מוגדרת היטב ובבעיית-מפתח (high-pain), באזור נושא (Subject Area) אחד. בצע מלאי של סכימות המקור, מפה כל מערכת לתחום ה-CIM, הגדר מדיניות הרחבה וממשל, והתייחס למיפויים כאל תוצרים מנוסחים (versioned artifacts). לאחר שהתחום הראשון יוכיח ערך, הרחב תחום אחר תחום, תוך שימוש חוזר בדפוסים ובממשל שהקמת.

קריאה נוספת

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