اعرف أدواتك: الأسئلة التسعة
متاح أيضًا بـ28 لغة
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
الوحدة 6 من 7 في فصل التفكير كمعماري بيانات، الفصل الأول من دورة Data Architect. كل وحدة قائمة بذاتها. السابق: ابنِ لليوم. خطّط للغد. خطّط للفشل. · التالي: معماري البيانات في زمن الذكاء الاصطناعي
السؤال الذي تجيب عنه هذه الوحدة: كيف تقيّم أي أداة، بما فيها أداة لم ترها من قبل؟
يحتاج المعماريون إلى الحكمة. لكن الحكمة بلا معرفة ليست مفيدة كثيرًا. ما زال عليك أن تعرف أدواتك.
أعلّم المعماريين منذ سنوات، ومن الأطر التي أستخدمها مجموعة من الأسئلة ينبغي أن تستطيع الإجابة عنها حول كل أداة أو قدرة مهمة في معماريتك. في الأصل كنت أعلّم ثمانية أسئلة. ثم أضفت تاسعًا. التقنيات تتغير، وSalesforce تتغير، وتظهر منتجات جديدة وتتطور قدرات قديمة، والذكاء الاصطناعي يسرّع ذلك كله. وهذه الأسئلة تظل صالحة.
الأسئلة التسعة
Section titled “الأسئلة التسعة ”كلما كنت تتعلم تقنية أو تقيّمها، اسأل:
- ما هي؟
- أين تُستخدم؟
- كيف أستخدمها؟
- ما بدائلي؟
- ما نقاط قوتها؟
- ما نقاط ضعفها؟
- كيف أشرحها للمطوّرين ولفريق الأعمال وللمديرين التنفيذيين؟
- كيف تُصان على المدى الطويل؟
- كم تكلّف، وما التراخيص التي تتطلبها، وما حدودها؟
إذا استطعت الإجابة عن الأسئلة التسعة كلها، فأنت تبدأ في فهم الأداة كما يفهمها المعماري. لاحظ ما ليس في القائمة: «هل أستطيع إعدادها؟» هذا مهم، لكنه ليس إلا جزءًا من معرفة الأداة.
1. ما هي؟
Section titled “1. ما هي؟ ”ابدأ بالسؤال البديهي، لأن الناس يتخطونه بشكل يثير الدهشة. نسمع اسم منتج أو ميزة فنبدأ فورًا في مناقشة ما إذا كنا سنستخدمه. تمهّل. ما الذي يفعله فعلًا؟ ما المشكلة التي صُمم لحلها؟ أين يقع في المعمارية، وما الذي ليس هو؟ ينبغي أن يستطيع المعماري وصف تقنية دون أن يكرر الوصف التسويقي. إذا لم أستطع شرح شيء في بضع جمل، فالأرجح أنني لم أفهمه جيدًا بما يكفي بعد.
2. أين تُستخدم؟
Section titled “2. أين تُستخدم؟ ”معرفة ما يفعله الشيء ليست مثل معرفة متى ينتمي إلى المعمارية. في أي أنواع المشكلات يبرع؟ ما الظروف التي تجعله مناسبًا، وما الظروف التي ينبغي أن تجعلني أرتاب فيه؟ هذه هي الخطوة من «أعرف هذه الميزة» إلى «أتعرّف على المشكلة التي تحلها هذه الميزة»، وهي خطوة كبيرة. لا تريد أن تتجول باحثًا عن أماكن تستخدم فيها تقنيتك المفضلة. بل تريد أن تتعرّف على المشكلات وتعرف أي الأدوات تناسبها.
3. كيف أستخدمها؟
Section titled “3. كيف أستخدمها؟ ”نعم، ينبغي أن يفهم المعماريون التنفيذ. لست مضطرًا إلى بناء كل مكوّن، لكن ينبغي أن تفهم ما يكفي لتعرف ما الذي تطلب من الآخرين بناءه. اعرف كيف تُعَدّ، وكيف يعمل المطوّر معها، وكيف تدخل البيانات وتخرج، وكيف تُنشر وتُؤمَّن، وكيف تبدو أثناء التشغيل. لا أريد معماريًا يصمم حول تقنية لم يرها إلا في شريحة عرض لمنتج. شمّر عن ساعديك: ابنِ شيئًا، واكسر شيئًا، وانظر كيف تتصرف فعلًا. تتحسن المعمارية عندما تكون متجذرة في الواقع.
4. ما بدائلي؟
Section titled “4. ما بدائلي؟ ”قد يكون هذا أهم سؤال في القائمة. إذا كنت تعرف طريقة واحدة فقط لحل مشكلة، فليس لديك قرار معماري؛ بل لديك خيار افتراضي. كلما اقترح أحدهم تقنية، أريد أن أعرف ما الذي يمكننا فعله غير ذلك. قدرة أخرى في Salesforce؟ شيء تعريفي (declarative)، أم شيفرة؟ هل يمكن أن تعيش القدرة خارج Salesforce؟ هل يمكننا ترك البيانات في مكانها بدلًا من نسخها، أو استخدام حدث بدلًا من استدعاء API، أو تجنّب بناء أي شيء أصلًا؟ البدائل تخلق المفاضلات، والمفاضلات هي قلب المعمارية.
5. ما نقاط قوتها؟
Section titled “5. ما نقاط قوتها؟ ”كل أداة موجودة لسبب. افهم ما تبرع فيه حقًا: ما الذي تجعله سهلًا، وأين تتوسع جيدًا، وما التعقيد الذي تزيله، وما المشكلات التي تحلها بأناقة. استخدم التقنيات حيث تتوافق نقاط قوتها مع المشكلة. يبدو هذا بديهيًا، لكن من السهل جدًا أن نختار أداة لأننا نملكها بالفعل، أو لأن الفريق يعرفها، أو لأنها جديدة، أو لأن أحدهم شاهد عرضًا توضيحيًا. قد تكون هذه عوامل. لكنها ليست الشيء نفسه مثل الملاءمة المعمارية.
6. ما نقاط ضعفها؟
Section titled “6. ما نقاط ضعفها؟ ”هذا مهم بالقدر نفسه. لكل تقنية نقاط ضعف، كل تقنية بلا استثناء. إذا لم يستطع أحدهم أن يخبرك إلا بنقاط قوة تقنية ما، فأنتما لم تبدآ بعد نقاشًا معماريًا. ما الذي لا تجيده؟ أين يظهر التعقيد، وماذا يحدث على نطاق واسع؟ ما العبء التشغيلي والاعتماديات التي تجلبها؟ ما المتطلبات التي تدفعها خارج نطاقها الأمثل؟ نقطة الضعف لا تعني دائمًا أنه لا ينبغي استخدام التقنية. بل تعني أننا نحتاج إلى أن نعرف ما الذي نقبله. المفاضلة التي تفهمها يمكن أن تكون قرارًا معماريًا. والمفاضلة التي لا تفهمها قد تتحول إلى مفاجأة.
7. كيف أشرحها لجماهير مختلفة؟
Section titled “7. كيف أشرحها لجماهير مختلفة؟ ”هذا من الأسئلة التي تفصل المعرفة التقنية عن المهارة المعمارية. هل تستطيع شرح التقنية نفسها للمطوّر، ولفريق الأعمال، وللمدير التنفيذي؟ لا ينبغي أن يكون الشرح هو نفسه. المطوّر يحتاج إلى واجهات API، وسلوك المعاملات، والأمان، ومعالجة الفشل، وأنماط التنفيذ. فريق الأعمال يهتم بما تتيحه وكيف تتغير عمليته. والمدير التنفيذي يهتم بالكلفة، والمخاطر، والوقت، والأثر على المؤسسة، وأي الخيارات يُبقيها القرار مفتوحة أو يُغلقها. أنت لا تغيّر الحقيقة؛ بل تغيّر مستوى التجريد. إذا كانت الطريقة الوحيدة التي تستطيع بها شرح تقنية هي مفردات وثائقها، فواصل العمل على فهمك.
8. كيف تُصان على المدى الطويل؟
Section titled “8. كيف تُصان على المدى الطويل؟ ”المشاريع تنتهي. أما الأنظمة فلا، أو هذا على الأقل ما نأمله. لا بد أن يملك أحدٌ ما نبنيه بعد رحيل فريق المشروع. وهذا يعني أن تعرف كيف تُراقَب، وكيف تُرقّى، وكيف تُشخَّص أعطالها، ومن يحتاج إلى المهارات لدعمها، وكيف تُنشر التغييرات وتُختبر، وماذا يحدث عندما تتطور التقنية أو تغيّر Salesforce شيئًا تحتنا. تخيّلها بعد ثلاث سنوات من الآن. رأيت معماريات كانت ذكية جدًا يوم الإطلاق وبائسة في التشغيل بعده. هذا ليس نجاحًا. قابلية الصيانة جزء من المعمارية.
9. كم تكلّف، وما التراخيص التي تتطلبها، وما حدودها؟
Section titled “9. كم تكلّف، وما التراخيص التي تتطلبها، وما حدودها؟ ”هذا هو السؤال الذي أضفته إلى الأسئلة الثمانية الأصلية، وأعتقد اليوم أنه يستحيل إغفاله. قد تكون التقنية الحل التقني المثالي ومع ذلك تكون الحل المعماري الخاطئ إذا لم تنجح حساباتها الاقتصادية. هل هي مشمولة في التراخيص التي لدينا، أم إضافة مدفوعة؟ هل تُرخَّص حسب المستخدم، أو الاستخدام، أو الاستهلاك، أو التخزين، أو المعاملات؟ ماذا يحدث للكلفة مع توسعنا؟
ثم هناك الحدود، ولكل منصة حدودها: حدود API، والتخزين، والاستعلام، والمعاملات، والتزامن، والإنتاجية، والتراخيص. بعضها صارم وبعضها مرن؛ وبعضها يمكن رفعه وبعضها لا؛ وبعضها لا يهم على نطاقنا حتى نضيف صفرًا آخر. لست مضطرًا إلى حفظ كل حدود Salesforce، وفعل ذلك سيكون استخدامًا سيئًا جدًا لوقتك. ما تحتاج إليه هو أن تعرف أن الحدود موجودة، وأيها يهم معماريتك، ومتى تذهب للتحقق من الرقم الحالي. الأرقام ستتغير. أما السؤال المعماري فيبقى.
مثال تطبيقي: مشاركة Apex
Section titled “مثال تطبيقي: مشاركة Apex ”إليك أحد أكثر أمثلتي شيوعًا على الأسئلة وهي تعمل. يصلنا متطلب لمشاركة معقدة، مشاركة لا يمكن تحقيقها بأي من قواعد المشاركة القائمة على المالك أو القائمة على المعايير. هذا يقودنا إلى مشاركة Apex (Apex sharing): شيفرة تكتب سجلات المشاركة بنفسها. إذن نحتاج الآن إلى أن نعرف ما مشاركة Apex، وأين تُستخدم، وكيف تُستخدم، وبقية الأسئلة. إنها تصعيد: مشاركة Apex هي البديل (السؤال 4) عندما تتجاوز القواعد التي نحتاجها ما تستطيع المشاركة القائمة على المالك والمعايير التعبير عنه.
والآن نقاط ضعفها (السؤال 6). لنفترض أن لدينا مجتمع عملاء يضم 10 أو 20 مليون عضو، ونستخدم ترخيص Customer Community، لا Customer Community Plus. هؤلاء مستخدمون كبيرو الحجم (high-volume). ليست لديهم أدوار، ولا يستخدمون نموذج المشاركة إطلاقًا: يأتي وصولهم من مجموعات المشاركة (sharing sets) ومجموعات الحصص (share groups)، بالمطابقة عبر حسابهم وجهة اتصالهم. لا يوجد سجل مشاركة تكتبه Apex لهم، لذلك لا تعمل مشاركة Apex معهم. وسؤال الكلفة والتراخيص (السؤال 9) هو ما أوصلنا إلى هناك: اختيار الترخيص هو الذي حدد أي أدوات المشاركة موجودة أصلًا.
إذن كما كانت مشاركة Apex بديلًا عن القواعد القائمة على المالك والمعايير، قد تصادف حالة تحتاج فيها إلى بديل عن مشاركة Apex. ولا توجد في الحقيقة أي خيارات قائمة على الإعداد لقواعد المشاركة المعقدة عند تلك النقطة. فينتهي بك الأمر إلى جعل الكائن للقراءة فقط والتحكم في الوصول عبر Apex. لهذا تطرح الأسئلة التسعة كلها قبل أن تختار، لا بعده.
لا تحفظ المنصة
Section titled “لا تحفظ المنصة ”هذا أهم ما يكون عندما تتعلم معمارية Salesforce. لا تحاول حفظ Salesforce. لن تستطيع: المنصة أكبر من ذلك، وتتغير بسرعة كبيرة. أعمل مع Salesforce منذ وقت طويل، وما زلت أتعلم. وهذا طبيعي.
ما أريدك أن تبنيه هو إطار للتعلّم. عندما تُطلق Salesforce قدرة جديدة غدًا، لا أحتاج إلى أن أكون قد رأيتها من قبل. أعرف ما أسأل: ما هي، وأين تتلاءم، وكيف أستخدمها، وما الذي يمكنني استخدامه غيرها، وفيمَ تبرع، وأين تتعثر، وكيف أشرحها، وكيف أشغّلها، وكم تكلّف وأين حدودها؟ الآن أستطيع أن أبدأ تقييمها. وهذا أثمن بكثير من حفظ مصفوفة ميزات أخرى.
ما بعد الاختبار: الذكاء الاصطناعي يجعل الإجابة عن الأسئلة التسعة أسرع، والخطأ فيها أسهل. صادف تقنية لا تعرفها، ويمكنك أن تطلب من الذكاء الاصطناعي أن يشرحها، أو يقارن بين ثلاثة نُهج، أو يسرد حدودها وأنماط فشلها الشائعة، أو يجادل ضد استخدامها. هذا مساعد بحث رائع. لكنه قد يخطئ، أو يكون قديم المعلومات، أو يخلط بثقة بين منتجين أو إصدارين متشابهين في الاسم. لأي شيء يؤثر في قرار، تحقق منه: تتبّع المصدر وراجع الوثائق والحدود والتراخيص الحالية. ثق لكن تحقّق (الوحدة 7).
تعلّم الأسئلة، لا الإجابات فقط
Section titled “تعلّم الأسئلة، لا الإجابات فقط ”سنقابل تقنيات كثيرة في هذه الدورة. لا أريدك أن تجمع الإجابات؛ بل أريدك أن تتمرن على الأسئلة. عندما نتحدث عن big objects، أو البيانات الخارجية، أو Data 360، أو أنماط التكامل، أو قدرة ذكاء اصطناعي تُطلقها Salesforce بعد ستة أشهر من كتابة هذا الفصل، اطرح الأسئلة التسعة نفسها.
الإجابات ستتغير. الأسئلة باقية. وهذا ما يجعل هذا إطارًا معماريًا لا دليل دراسة.
اعرف أدواتك: فيمَ تبرع، وفيمَ تخفق، وما الذي يمكنك استخدامه غيرها، وكم تكلّف، وأين تنكسر. واعرف ما يكفي لتشرح القرار لمن سيعيشون معه. هكذا يتعلم المعماري التقنية.
ما الذي يقرره المعماري هنا
Section titled “ما الذي يقرره المعماري هنا ”- هل تناسب الأداة المشكلة، بالحكم عليها وفق الأسئلة التسعة كلها، لا وفق قابليتها للإعداد فقط.
- ما البدائل، وماذا تعني كلفة الأداة وتراخيصها وحدودها على نطاقك.
- من سيصونها، وكيف، بعد ثلاث سنوات من الآن.
- أي الحقائق عن الأداة يجب التحقق منها قبل الاعتماد عليها.
للاستزادة
Section titled “للاستزادة ”- About High-Volume Community or Site Users (opens in a new tab)، Salesforce Help (بالإنجليزية، تم التحقق في 2026-10-09؛ وأُعيد التحقق في 2026-10-12): المستخدمون كبيرو الحجم (تراخيص External Apps وCustomer Community وHigh Volume Customer Portal وAuthenticated Website) ليست لديهم أدوار؛ يأتي وصولهم من مجموعات المشاركة (sharing sets) ومجموعات الحصص (share groups)؛ ولا يمكن تضمينهم في قواعد المشاركة القائمة على المالك، ولا يمكن مشاركة السجلات التي يملكونها يدويًا.
- Platform Sharing Architecture (opens in a new tab)، Salesforce Architects (بالإنجليزية، تم التحقق في 2026-10-09؛ وأُعيد التحقق في 2026-10-12): المستخدمون كبيرو الحجم (Customer Community وHigh Volume Customer Portal وAuthenticated Website) لا يستخدمون نموذج المشاركة، لأن تراخيصهم لا تدعم الأدوار؛ يعمل الوصول بمطابقة المستخدم مع علاقتي البحث Account وContact، عبر مجموعات المشاركة أو مجموعات الحصص. وتسرد الصفحة نفسها متى تكون Apex managed sharing الأداة الصحيحة.
- Account Sharing Sets for High Volume Customer Portal Users (opens in a new tab)، سؤال في Trailblazer Community، نوفمبر 2024 (بالإنجليزية، تم التحقق في 2026-10-09؛ وأُعيد التحقق في 2026-10-12): يذكر أحد الممارسين أن إدراج سجلات المشاركة للمستخدمين كبيري الحجم فشل مع ظهور خطأ. تقرير ميداني، لا وثائق رسمية. (يصبح مجتمع Trailblazer Community على الإنترنت للقراءة فقط في 30 أكتوبر 2026؛ وقد يتغير الرابط.)
- Create a Sharing Set for Experience Cloud Site Users (opens in a new tab)، Salesforce Help (بالإنجليزية، تم التحقق في 2026-10-09): تمنح مجموعة المشاركة (sharing set) الوصول إلى السجلات المرتبطة بحساب المستخدم أو جهة اتصاله.