نموذج المعلومات السحابي

مرحبًا بك في CIM، وهو نموذج بيانات حيادي للتطبيقات يعمل على تبسيط التكامل وتسريع الابتكار.

النقاط الرئيسية

• CIM هو نموذج بيانات مفتوح وحيادي للتطبيقات — عبارة عن مفردات مشتركة لمفاهيم الأعمال (العملاء والطلبات والمنتجات وما إلى ذلك) تسمح للأنظمة السحابية والمحلية المختلفة بتبادل البيانات دون الحاجة إلى تعيين مخصص من نقطة إلى نقطة (point-to-point mapping).
• لقد وُجد لحل مشكلة محددة ومكلفة: حيث يطرح كل تطبيق نموذج بيانات خاصًا به، مما يجعل فرق التكامل ينتهي بهم الأمر إلى كتابة وصيانة كود ترجمة مخصص يتسم بالهشاشة ويبطئ الابتكار.
• يتم إدارته كمعيار مفتوح، ينتجه اتحاد وهو مفتوح المصدر تحت مظلة مؤسسة التطوير المشتركة (Joint Development Foundation)، وهي جزء من مؤسسة Linux — لذا يمكن لأي شخص المساهمة فيه ومراجعته واعتماده.
• يتم تنظيم المحتوى في مجالات موضوعية (Subject Areas)، يمثل كل منها مفهومًا تجاريًا رئيسيًا، مع نشر التصميمات بتنسيقات متعددة بما في ذلك الرسوم التوضيحية.
• CIM هو نموذج وليس منتجًا. فهو يحدد المعنى والبنية؛ بينما تظل أنت من يختار كيفية تعيين البيانات وتخزينها ونقلها في أنظمتك الخاصة.

معيار جديد لقابلية التشغيل البيني للبيانات

يتم إنتاج CIM بواسطة اتحاد مفتوح تم تشكيله لتقديم حل قائم على المعايير لربط منتجات المؤسسات. وباستخدام CIM، يمكنك إنشاء تجارب شخصية سلسة ومصممة خصيصًا عبر التطبيقات السحابية الأصلية (cloud-native).

لتسريع التحول الرقمي وتقديم تفاعلات مخصصة للعملاء عبر كل قناة، تعتمد العديد من الشركات تطبيقات سحابية ومحلية متعددة. ويأتي كل تطبيق بنموذج بيانات خاص به، مما يجبر المطورين على بناء واختبار وإدارة كود مخصص ضروري لتعيين البيانات وترجمتها عبر الأنظمة المختلفة. وبدلاً من تسريع التحول الرقمي، تؤدي هذه العملية إلى إبطاء الابتكار وتؤدي إلى عمليات تكامل هشة.

CIM هو مواصفات حديثة ومفتوحة للمساعدة في تخفيف معاناة دمج البيانات. يوفر CIM معيارًا محددًا للتواصل بسهولة بين تنسيقات البيانات المختلفة. وبما أنه مفتوح المصدر كجزء من مؤسسة التطوير المشتركة (ضمن مؤسسة Linux)، فإننا نرحب بجميع المساهمين.

لماذا تنهار نماذج البيانات الخاصة بالتطبيقات

المشكلة الأساسية التي يعالجها CIM ليست أن أي تطبيق بمفرده يمتلك نموذج بيانات سيئًا؛ فمعظمها منطقية تمامًا داخل حدودها الخاصة. تكمن المشكلة في “الانفجار التوليفي” (combinatorial explosion) الذي يحدث عند توصيل العديد منها.

تأمل في حزمة مؤسسية نموذجية: نظام إدارة علاقات العملاء (CRM)، ونظام تخطيط موارد المؤسسات (ERP)، ومنصة أتمتة التسويق، ومكتب دعم، ومستودع بيانات، ومجموعة من أدوات SaaS لخطوط الأعمال. إذا كان لكل نظام مفهومه الخاص عن “العميل” و”الحساب” و”الطلب” و”المنتج”، فإن كل زوج من الأنظمة التي تحتاج إلى مشاركة البيانات يتطلب تعيينًا (mapping) خاصًا به. يزداد عدد عمليات التكامل تقريبًا مع مربع عدد الأنظمة، وكل تعيين هو جزء صغير وغير موثق وغير مملوك من المنطق يجب على شخص ما صيانته إلى الأبد.

ذات صلة: Boomi AtomSphere — Enterprise iPaaS للتكامل المختلط بين السحابة المحلية.

هذه الأعراض مألوفة لأي شخص أدار ممارسة تكامل:

• الانحراف الدلالي (Semantic drift). كلمة “عميل” في نظام CRM تعني كيانًا للفواتير؛ بينما في مكتب الدعم تعني الشخص الذي يفتح تذاكر الدعم. الكلمة نفسها بمعنيين مختلفين، يتم التوفيق بينهما بصمت عبر تعيين لا يتذكر أحد كتابته.
• خطوط أنابيب هشة. يقوم المورد بإعادة تسمية حقل أو تغيير قيمة تعداد (enum)، فتفشل مهمة ETL في الساعة 2 صباحًا لأن التعيين كان مبرمجًا بشكل ثابت (hard-coded) وفقًا للشكل القديم.
• تكرار الجهود. يقوم فريقان بشكل مستقل ببناء ترجمات شبه متطابقة بين نفس النظامين لعدم وجود مرجع مشترك للإشارة إليه.
• الارتهان للمورد بسبب البيانات (Vendor lock-in). يعد الانتقال من منصة ما أمرًا مكلفًا ليس بسبب البرنامج، بل بسبب منطق الترجمة المتراكم المرتبط بمخطط البيانات (schema) الخاص بها.

يهاجم النموذج المشترك الحيادي للتطبيقات السبب الجذري: فبدلاً من التعيينات من N إلى N، يقوم كل نظام بالتعيين مرة واحدة إلى نموذج مشترك، ويتولى النموذج المشترك حمل المعنى.

ماذا يعني “حيادي للتطبيقات” في الواقع

من المهم أن نكون دقيقين بشأن فلسفة التصميم، لأن مصطلح “حيادي” (agnostic) غالبًا ما يُستخدم بشكل فضفاض.

اختيارنا: Workato — iPaaS الذي يقوده التشغيل الآلي والذي يمكن لفرق العمل البناء عليه فعليًا.

النموذج الحيادي للتطبيقات ليس مملوكًا لأي مورد واحد ولا مُحسَّنًا لمنتج مورد معين. فهو يصف مفاهيم الأعمال بمصطلحات يمكن لخبير المجال التعرف عليها — مثل عميل، أو طلب، أو منتج، أو موقع — بدلاً من مصطلحات تعكس الجداول الداخلية لتطبيق واحد. هذا الحياد هو ما يجعله مركزًا (hub) مفيدًا: فلا يضطر أي مشارك إلى تبني وجهة نظر منافس للعالم من أجل تحقيق التشغيل البيني.

هذه هي نفس الغريزة المعمارية وراء معايير التبادل المحايدة الأخرى. تمامًا كما يمنح إطار وصف الموارد (RDF) وschema.org الويب مفردات مشتركة لوصف الأشياء، وكما منحت EDI ولاحقًا UBL (لغة الأعمال العالمية، وهي معيار OASIS) سلاسل التوريد تنسيقًا مشتركًا للمعاملات، يهدف CIM إلى منح تطبيقات المؤسسات مفردات مشتركة لكيانات أعمالها الأساسية. الفرق يكمن في النطاق والحداثة: يستهدف CIM العالم المتصل المعتمد على واجهات برمجة التطبيقات (API) والسحابي والمحلي، بدلاً من تبادل الملفات الدفعية (batch file exchange).

النموذج الذهني المفيد هنا هو نمط نموذج البيانات الأساسي (canonical data model) من تكامل المؤسسات، والذي اشتهر في كتاب Enterprise Integration Patterns لجريجور هوهبي وبوبي وولف. إن CIM، في الواقع، هو نموذج أساسي يتم صيانته بشكل تعاوني — وهو “المحور” في طوبولوجيا تكامل المحور والأطراف (hub-and-spoke) — ولكنه نموذج مفتوح، ومحدد الإصدارات، ومشترك بين المؤسسات بدلاً من أن يتم ابتكاره بشكل خاص داخل شركة واحدة.

كيف يتم تنظيم CIM: المجالات الموضوعية والنطاقات

يتم تنظيم المحتوى المحدد تعاونيًا في نطاقات، أو مجالات موضوعية (Subject Areas). يمثل كل مجال موضوعي مفهومًا تجاريًا رئيسيًا. تتوفر تصميمات CIM بتنسيقات متعددة لكل مجال، بما في ذلك الرسوم التوضيحية. وسوف ينمو عدد ونطاق المجالات الموضوعية مع نمو الاتحاد والمساهمات.

من الناحية العملية، هذا يعني أنه يجب عليك التفكير في CIM باعتباره مكتبة من النماذج ذات الصلة بدلاً من مخطط واحد متجانس. تتجمع مجالات الموضوعات (Subject Areas) النموذجية حول اهتمامات تجارية معروفة - على سبيل المثال، الأطراف والحسابات، والمنتجات والكتالوجات، والطلبات والمعاملات، والعلاقات التي تربطها معًا. ونظرًا لأنه يتم نشر كل مجال برسوم بيانية وتعريفات يمكن قراءتها آليًا، يمكن للفرق المختلفة اعتماد مجالات مختلفة في أوقات مختلفة دون انتظار اكتمال النموذج بأكمله.

ويترتب على هذا الهيكل بعض الآثار العملية:

ذات صلة: Matillion — تم تصميم ELT للأسفل لمستودعات البيانات السحابية.

• الاعتماد التدريجي. لا تحتاج إلى ربط مؤسستك بأكملها بـ CIM في اليوم الأول. ابدأ بمجال الموضوع الأكثر إلحاحاً - عادةً مجال العميل أو الطلب - ثم توسع.
• التوسيع بدلاً من التفرع (Fork). عندما يفتقر CIM إلى مفهوم تحتاجه، فإن النموذج المفتوح مصمم ليتم توسيعه. والمساهمة بامتداد (extension) مرة أخرى أفضل من الحفاظ على نسخة متفرعة خاصة، لأن النسخة المتفرعة تبتعد عن الأصل وتفقد ميزة التشغيل البيني.
• تعامل مع الرسوم البيانية كوثائق، وليس كمصدر للحقيقة. الرسوم البيانية الأمثلة مخصصة للبشر؛ أما التعريفات المقروءة آليًا فهي ما يجب أن تستهلكه أدواتك.

CIM في مشهد التكامل: كيفية اتخاذ القرار

يعد CIM أحد الخيارات المتاحة لترويض تعقيد التكامل. ويتطلب الاختيار الجيد مطابقة الأداة للمشكلة. يوضح الجدول أدناه مقارنة بين الأساليب الرئيسية التي يوازن بينها عادةً مهندس بيانات المؤسسة.

النهج	ماهيته	الأفضل عندما	المفاضلة الرئيسية
رسم الخرائط من نقطة إلى نقطة (Point-to-point)	كود مخصص يترجم مباشرة بين نظامين	نظامان فقط، مخططات مستقرة، أفق زمني قصير	لا يتوسع؛ انفجار في عدد الروابط (N-to-N)؛ هش
النموذج الأساسي (مثل CIM)	نموذج مشترك ومحايد يتم ربط كل نظام به مرة واحدة	أنظمة عديدة، بائعون متعددون، تكامل طويل الأمد	جهد نمذجة مسبق؛ الحاجة إلى حوكمة
موصلات iPaaS للموردين	موصلات معدة مسبقًا من منصة تكامل	أزواج SaaS شائعة، تفضيل السرعة على التحكم	دلالات خاصة بالموصل؛ احتمال الارتباط بمورد واحد (lock-in)
معايير التبادل الصناعي (EDI, UBL, HL7, إلخ)	تنسيقات رسائل خاصة بمجال معين	قطاعات منظمة أو راسخة	نطاق ضيق؛ غالبًا ما تكون موجهة نحو الدفعات (batch-oriented)
محاكاة البيانات الافتراضية / الاتحاد (Federation)	الاستعلام عبر المصادر دون مركزيتها	التحليلات، الوصول للقراءة في الغالب	لا يحل التعارضات الدلالية من تلقاء نفسه

قاعدة اتخاذ القرار بسيطة: إذا كان لديك أكثر من عدد قليل من الأنظمة التي يجب أن تتفق على معنى الكيانات المشتركة، وكانت هذه الأنظمة من بائعين مختلفين، فإن النموذج الأساسي يثبت جدواه اقتصادياً. أما إذا كان لديك نظامان ولا توجد خطط لإضافة المزيد، فإن الربط من نقطة إلى نقطة يكون كافياً. وإذا كانت حاجتك تحليلية بحتة وللقراءة فقط، فقد يكون الاتحاد كافياً - ولكن لاحظ أن الاتحاد ينقل المشكلة الدلالية بدلاً من حلها.

يعد CIM مكملاً للأدوات المحيطة به وليس بديلاً عنها. فلا يزال خط أنابيب ETL أو ELT (الذي يتم بناؤه باستخدام شيء مثل Apache Airflow أو dbt أو منصة تجارية) هو من يقوم بنقل البيانات؛ بينما يحدد CIM ما تعنيه البيانات بمجرد وصولها. ولا يزال وسيط الرسائل مثل Apache Kafka يقوم بالنقل؛ بينما يحدد CIM شكل الأحداث. النموذج هو العقد؛ والأدوات هي السباكة.

حيث سنبدأ: Fivetran — خط أنابيب ELT المُدار بالكامل والذي يستمر في العمل.

الحوكمة والترخيص وأهمية المؤسسة

CIM مفتوح المصدر كجزء من مؤسسة التطوير المشتركة (Joint Development Foundation)، التي تعمل تحت مظلة مؤسسة Linux (Linux Foundation). هذه ليست تفصيلة ثانوية - بل هي أساسية لسبب تمكن المؤسسات من الاعتماد على CIM بأمان.

تعد مؤسسة Linux موطناً محايداً وراسخاً للمشاريع التعاونية مفتوحة المصدر، وتوفر مؤسسة التطوير المشتركة هيكلاً قانونياً مرناً لتطوير المعايير والمواصفات بشكل تعاوني. واستضافة CIM هناك تعني:

• إشراف محايد. لا يوجد بائع واحد يتحكم في النموذج، لذا فإن اعتماده لا يعني اتباع خريطة طريق أحد المنافسين.
• مساهمة مفتوحة. يمكن لأي شخص - بائعين، مؤسسات، مساهمين أفراد - اقتراح تغييرات، والعملية تتسم بالشفافية.
• ترخيص متوقع. عادةً ما تحمل المواصفات التي تستضيفها المؤسسة شروطاً مصممة لاعتماد واسع وصديق لحقوق الملكية، وهو أمر بالغ الأهمية للفرق القانونية وفرق المشتريات التي تقيم المعيار.

بالنسبة للمهندس المعماري الذي يطرح القضية داخلياً، غالباً ما تكون قصة الحوكمة هذه بنفس أهمية المحتوى الفني. فعبارة “إنه معيار مفتوح تحت مظلة مؤسسة Linux” تجيب على الأسئلة التي تعيق اعتماد المعايير: من يتحكم فيه؟ ماذا يحدث إذا انسحب المورد؟ هل يمكننا المساهمة بامتداداتنا؟

البدء: مسار اعتماد عملي

إن تبني نموذج مشترك هو تمرين تنظيمي بقدر ما هو تمرين تقني. ويبدو التسلسل العملي كما يلي:

1. جرد كياناتك المشتركة. حدد مفاهيم الأعمال التي تظهر في أكثر من نظام واحد - عادةً العميل، والمنتج، والطلب، والموقع. هذه هي العناصر المرشحة.
2. اختر مجال موضوع واحد وتكاملاً واحداً. اختر التكامل الأكثر إلحاحاً والأقل تأثيراً في حال حدوث خطأ (lowest-blast-radius) لإثبات كفاءة النموذج. يعد مسار تقارير فردي أو إعداد تطبيق جديد أمراً مثالياً.
3. اربط كل نظام بـ CIM مرة واحدة. قم ببناء الترجمة من كل نظام مصدر إلى تمثيل CIM، ومن CIM إلى كل هدف. قاوم الرغبة في ربط الأنظمة ببعضها مباشرة.
4. وثق امتداداتك. في الحالات التي لا يغطي فيها CIM مفهوماً ما، قم بتسجيل الامتداد بشكل صريح وفكر في المساهمة به مجدداً.
5. تحديد الملكية. النموذج الأساسي بدون مشرف يتدهور. قم بتعيين فريق أو دور مسؤول عن عمليات الربط وتتبع التغييرات في الأنظمة المصدرية.
6. الإصدار والاختبار. تعامل مع النموذج وعمليات الربط الخاصة به كعناصر ذات إصدارات (versioned artifacts) مع اختبارات، تماماً كما تفعل مع كود التطبيق.

إن نمط الفشل الأكثر شيوعًا هو التعامل مع CIM كعملية نمذجة لمرة واحدة بدلاً من كونه عقدًا حيًا. فالمؤسسات التي تنجح تتعامل مع النموذج بنفس الطريقة التي تتعامل بها مع واجهة برمجة التطبيقات (API): بحيث يكون مُدار الإصدارات، ومُختبرًا، ومملوكًا، ومطورًا بشكل مدروس.

الشركاء المساهمون في CIM

CIM هو جهد تعاوني (consortium)، وتزداد قيمته مع زيادة المشاركة. يساهم الشركاء بمحتوى “مجالات الموضوع” (Subject Area)، ويراجعون المقترحات، ويساعدون في تشكيل اتجاه النموذج. ونظرًا لأن العمل مفتوح، فإن المساهمات لا تقتصر على كبار الموردين؛ فالمؤسسات التي تعاني من تحديات تكامل حقيقية والممارسون الأفراد ذوو الخبرة في المجال مرحب بهم على حد سواء.

تواصل معنا

هل أنت مهتم بالانضمام إلى مبادرة CIM؟ رائع! لا تتردد في مراسلتنا عبر البريد الإلكتروني لمزيد من المعلومات. راسلنا عبر البريد الإلكتروني.

الأسئلة الشائعة

ما هو نموذج المعلومات السحابية (CIM)؟

CIM هو نموذج بيانات مفتوح المصدر ومستقل عن التطبيقات (application-agnostic)، يوفر مفردات مشتركة قائمة على المعايير لمفاهيم الأعمال التي تحتاج المؤسسات إلى تبادلها عبر التطبيقات السحابية والمحلية (on-premises). يتم إنتاجه بواسطة اتحاد مفتوح ويتم استضافته تحت مظلة مؤسسة التطوير المشتركة (Joint Development Foundation)، وهي جزء من مؤسسة لينكس (Linux Foundation). والغرض منه هو تقليل كود التعيين (mapping code) المخصص الذي تتطلبه عمليات التكامل الهشة من نقطة إلى نقطة.

هل CIM منتج أم مواصفات؟

CIM هو عبارة عن مواصفات — نموذج ومجموعة من التعريفات — وليس منتجًا قابلاً للتشغيل. فهو يحدد معنى وبنية الكيانات المشتركة؛ بينما تظل أنت من يختار أدوات ETL/ELT، ووسطاء الرسائل، ووسائل التخزين الخاصة بك. فكر فيه كالعقد الذي تنفذه “توصيلات” التكامل لديك، وليس كالتوصيلات نفسها.

كيف يختلف CIM عن منصة تكامل المورد؟

تقوم منصة التكامل (سواء كانت iPaaS أو مكتبة موصلات) بنقل البيانات وغالبًا ما توفر موصلات معدة مسبقًا، ولكن هذه الموصلات تتبع دلالات خاصة بالمورد. أما CIM فهو محايد ومستقل عن الموردين، لذا فهو لا يحصرك في الرؤية العالمية لمنصة واحدة. والاثنان يكملان بعضهما البعض: حيث يمكنك استخدام CIM كنموذج أساسي (canonical model) داخل أي منصة تكامل.

ما هي مجالات الموضوع (Subject Areas) في CIM؟

مجالات الموضوع (وتسمى أيضًا النطاقات/domains) هي الوحدات التنظيمية للنموذج، ويمثل كل منها مفهومًا تجاريًا رئيسيًا مثل العملاء أو المنتجات أو الطلبات. تُنشر التصميمات بتنسيقات متعددة، بما في ذلك الرسوم التوضيحية، ومن المتوقع أن تنمو مجموعة مجالات الموضوع مع مساهمة الاتحاد والمجتمع بمزيد من المحتوى.

هل يمكننا توسيع CIM إذا كان لا يغطي مفاهيمنا؟

نعم. تم تصميم CIM ليكون قابلاً للتوسيع، ولأنه مفتوح المصدر تحت مظلة مؤسسة محايدة، يمكنك اقتراح إضافات من خلال عملية المساهمة. إن توسيع النموذج المشترك والمساهمة به مرة أخرى هو أمر مفضل بشدة على الاحتفاظ بنسخة خاصة (private fork)، والتي تنحرف بمرور الوقت وتفقد ميزة التشغيل البيني التي كانت الدافع لاعتماد CIM في المقام الأول.

من الذي يجب عليه اعتماد CIM؟

تكمن قيمته القصوى للمؤسسات التي تشغل العديد من التطبيقات من موردين مختلفين والتي يجب أن تتفق على معنى الكيانات المشتركة — وهو الوضع الكلاسيكي لمهندسي بيانات المؤسسات ومهندسي التكامل. كما يستفيد موردو التطبيقات والمنصات من خلال مواءمة مخططاتهم (schemas) مع نموذج محايد، مما يجعل تكامل منتجاتهم أسهل بالنسبة للعملاء. أما إذا كان لديك نظامان مستقران فقط، فقد يكون التعيين البسيط من نقطة إلى نقطة كافيًا.

مزيد من القراءة

• Linux Foundation — ويكيبيديا
• Joint Development Foundation — ويكيبيديا
• Enterprise Integration Patterns — ويكيبيديا
• Resource Description Framework (RDF) — ويكيبيديا