التفكير كمعماري
متاح أيضًا بـ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)
الوحدة 1 من 7 في فصل التفكير كمعماري بيانات، الفصل الأول من دورة Data Architect. كل وحدة قائمة بذاتها. السابق: نظرة عامة على الفصل · التالي: نموذج البيانات هو الهيكل العظمي
السؤال الذي تجيب عنه هذه الوحدة: ما الفرق بين البناء والتصميم المعماري، وما الذي يفعله المعماري فعلًا؟
طوال معظم مسيرتي المهنية، كنت بنّاءً.
بدأت مطوّرًا. عملت بلغة Java وبمنصة .NET قبل أن أنتقل إلى Salesforce، وقضيت سنوات في تصميم الأنظمة، وكتابة الشيفرة، وربط المنصات بعضها ببعض، وتعليم المعماريين، ومراجعة المعماريات.
لكن من أهم الدروس التي تعلمتها في الطريق أن البنّاء الممتاز والمعماري الممتاز ليسا دائمًا الشيء نفسه.
البنّاء يسأل:
كيف أبني هذا؟
أما المعماري فعليه أن يطرح مجموعة مختلفة من الأسئلة:
هل ينبغي أن نبني هذا؟
لماذا نبنيه بهذه الطريقة؟
ما البدائل؟
ماذا يحدث عندما يكبر هذا؟
ماذا يحدث عندما يفشل؟
وما القرار الذي نتخذه اليوم وسنتمنى بعد ثلاث سنوات لو أننا فكّرنا فيه بعمق أكبر؟
أتذكر أنني كنت في مشروع لنشاط تجاري في قطاع التجزئة يعتمد على المواعيد. سألت: كم موعدًا في اليوم لكل متجر؟ ثم: كم متجرًا لديكم؟ وكم يومًا في الأسبوع تفتحون؟ وسرعان ما أدركت أننا سنصل إلى ملايين المواعيد في السنة الأولى وحدها. هذه هي الأسئلة التي يطرحها المعماري في بداية المشروع.
هذا التحوّل في التفكير هو ما تدور حوله هذه الدورة حقًا.
الشخص الذي يحمل المخطط
Section titled “الشخص الذي يحمل المخطط ”استخدمت هذا التشبيه مرات كثيرة وأنا أعلّم المعماريين.
تخيّل موقع بناء. هناك من يصبّ الخرسانة، ومن يمدّ الكهرباء، ومن يركّب السباكة، ومن يقيم هياكل الجدران، ومن يؤدي عشرات الأعمال المتخصصة الأخرى. وعليهم أن يكونوا بارعين جدًا فيما يفعلونه.
لكن لا بد أيضًا من شخص يحمل المخطط.
هذا الشخص يحتاج إلى أن يفهم كيف تتكامل كل تلك القطع معًا. ويحتاج إلى أن يلاحظ متى يتسبب شيء يحدث في جزء من المشروع في مشكلة في مكان آخر.
هذه هي المعمارية.
في عالم التقنية، نخطئ أحيانًا فنظن أن المعماري هو ببساطة الشخص الذي يعرف أكثر من غيره. ليس هذا هو الأمر حقًا. معرفة المنصة مهمة، وتحتاج إلى عمق تقني. لكن المعمارية ليست مسابقة معلومات عامة.
مهمة المعماري هي أن يتخذ قرارات جيدة، أحيانًا بمعلومات ناقصة ومتطلبات متعارضة، وأن يفهم عواقب تلك القرارات.
وهذه مهارة مختلفة تمامًا.
لا تكتفِ بتلقّي المتطلب
Section titled “لا تكتفِ بتلقّي المتطلب ”من أولى العادات التي أريد أن يكتسبها المعماريون عادة بسيطة:
اسأل: لماذا؟
يقول لك أحدهم:
نحتاج إلى كائن آخر.
لماذا؟
نحتاج إلى نسخ هذا الحقل إلى الحساب (Account).
لماذا؟
نحتاج إلى تخزين كل هذه البيانات في Salesforce.
لماذا؟
هذا لا يعني أن تكون عسيرًا في التعامل. بل يعني أن تفهم متطلب العمل الحقيقي بدلًا من أن تنفّذ الحل المقترح على الفور.
كثيرًا ما يصل المتطلب متنكرًا في هيئة تصميم.
عبارة «نحتاج إلى كائن مخصص جديد» ليست بالضرورة متطلبًا. فقد يكون المتطلب في الحقيقة «نحتاج إلى تتبّع هذه المعلومات بشكل منفصل». وهذان ليسا الشيء نفسه.
بمجرد أن تفهم المتطلب الحقيقي، يمكنك أن تبدأ في استكشاف البدائل. ربما يكون الكائن الجديد هو الإجابة الصحيحة تمامًا. وربما تنتمي المعلومات إلى مكان موجود بالفعل. وربما لا ينبغي أن تملك Salesforce تلك البيانات أصلًا.
على المعماري أن يفصل بين ما يحتاجه العمل وطريقة واحدة مقترحة لتحقيقه.
كنا نعمل على تطبيق مبيعات، وكان لدى العميل موافقات متعددة، لكل منها معتمِد وتاريخ. كان طلبهم الأول إضافة Approver 2 وApprover 3، لكل منهما تاريخ، كحقول على الفرصة (Opportunity). وعندما تعمّقنا، أدركنا أن عددها قد يتجاوز اثنين أو ثلاثة. فنقلنا الموافقات إلى كائن فرعي. كان الطلب مزيدًا من الحقول؛ أما المتطلب فكان تتبّع كل موافقة، مهما بلغ عددها.
التفكير فيما وراء المتطلب
Section titled “التفكير فيما وراء المتطلب ”تنبثق عن سؤال «لماذا؟» عادتان، ولكل منهما وحدة خاصة بها لاحقًا في هذا الفصل.
عادةً ما يكون هناك أكثر من إجابة واحدة. تمنحنا Salesforce طرقًا كثيرة لحل مشكلة ما، وبعضها خاطئ تقريبًا منذ اللحظة الأولى. والاختيار بين الطرق التي تنجح هو فن المفاضلة (الوحدة 4).
والمتطلبات التي تُعطى لك ليست كل المتطلبات التي لديك. لا أحد يقول «تأكد من أن هذا يعمل عندما ينجح التحميل الليلي إلى النصف فقط»، لكنه يظل متطلبًا. أنظر إلى كل تصميم من خلال ثلاث عدسات: ابنِ لليوم، خطّط للغد، خطّط للفشل (الوحدة 5).
فكّر في شخص يستعين بمعماري لتصميم مبنى. لا يطلب جهاز إنذار للحريق ولا نظام رشّاشات، ولا أن يصمد المبنى أمام زلزال. إنه يتوقع ذلك جزءًا من العمل، دون أن يطلبه. وعالمنا يعمل بالطريقة نفسها. لا أحد يطلب معالجة أخطاء رشيقة، ولا سجلات (logs)، ولا وسيلة للتعافي عندما يفشل شيء ما. وعلى المعماري أن يعرف أيّ هذه الأنظمة ينتمي إلى التصميم، وأن يضعه فيه.
اجعل منطقك مرئيًا
Section titled “اجعل منطقك مرئيًا ”لا ينبغي للمعماري أن يدخل الغرفة ويعلن ببساطة: «هذا ما سنفعله».
مهمتك أيضًا أن تشرح السبب. أريد أن يفهم أصحاب المصلحة البدائل التي درسناها والمفاضلات التي ينطوي عليها الأمر. هذا لا يعني أن تقدّم للمدير التنفيذي وثيقة تصميم من 40 صفحة. بل يعني أن تكون قادرًا على شرح المعمارية نفسها للمطوّر، ولفريق الأعمال، وللمدير التنفيذي: أحاديث مختلفة عن القرار نفسه.
والطريقة لفعل ذلك هي المخططات والتعليمات الواضحة، مثل الشخص الذي يحمل المخطط في موقع البناء. وبالنسبة لمعماري البيانات، فإن من أهم تلك المخططات نموذج البيانات.
إذا لم يفهم أحد سبب اتخاذ قرار ما، فهناك احتمال كبير أن يأتي شخص ما في النهاية ويلغيه. وقد تكون لديه أسباب معقولة تمامًا لذلك، لأن أحدًا لم يشرح القرار الأصلي قط.
المعماري لا يحتاج إلى بناء كل شيء
Section titled “المعماري لا يحتاج إلى بناء كل شيء ”هناك انتقال آخر قد يكون صعبًا، خاصة على من يأتون إلى المعمارية من عالم التطوير.
لست مضطرًا إلى أن تبني كل شيء بنفسك.
ما زلت أحب أن أفهم كيف تعمل الأشياء على مستوى تقني عميق جدًا، وهذا الأساس مهم. لكنك بوصفك معماريًا تصبح مسؤوليتك أكبر من تنفيذك الشخصي. لست مضطرًا إلى بناء كل شيء؛ بل تحتاج إلى أن تعرف كيف تمنح من يبنونه التوجيه الصحيح والمعايير الصحيحة. وهذا يعني أن تفهم ما يكفي لتوجيه عملهم، وأن تلاحظ متى يخلق تنفيذٌ مقترح مشكلة معمارية، وأن تتنقّل بين التفاصيل والصورة الأكبر.
أحيانًا يعني ذلك التعمق في استعلام، أو واجهة برمجة تطبيقات (API)، أو نموذج بيانات.
وأحيانًا يعني التراجع خطوة إلى الوراء والتساؤل عمّا إذا كان ينبغي لنا أن نفعل أيًّا من ذلك أصلًا.
ويومًا بعد يوم، لم يعد من يبني هم البشر وحدهم. مع الذكاء الاصطناعي، قد يعمل المعماري مباشرة مع الأداة التي تُنشئ الكائنات والشيفرة والشاشات. وعندها يذهب التوجيه والمعايير والإرشادات إلى الذكاء الاصطناعي، ويصبح تقديمها بشكل جيد مسؤولية المعماري أكثر فأكثر. سنعود إلى هذا في الوحدة 7.
وهذا جزء من الرحلة من البنّاء إلى المعماري.
مهمتك أن تتخذ القرارات
Section titled “مهمتك أن تتخذ القرارات ”في النهاية، المعمارية تدور حول القرارات.
بعض القرارات سهلة التغيير. وبعضها ليس كذلك.
يمكن تغيير تخطيط الصفحة. ويمكن إعادة تسمية التسمية الظاهرة (label).
لكن اختر نموذج البيانات الأساسي الخاطئ، أو انشر معرّفات تبدأ عشرات الأنظمة في الاعتماد عليها، أو ضع النسخة الرئيسية من بيانات حرجة في المكان الخطأ، وسيصبح تغيير رأيك أكثر كلفة بكثير.
تلك هي القرارات المعمارية. وهي بالضبط نوع القرارات التي تركّز عليها هذه الدورة.
بوصفك معماري بيانات، ستتخذ قرارات حول كيفية هيكلة المعلومات، وأين تعيش، وكيف تنمو، وكيف تنتقل، ومن يستطيع الوصول إليها، وكيف تفهمها بقية المؤسسة.
التقنية مهمة.
لكن معرفة كل ميزة في Salesforce ليست الهدف.
الهدف هو تنمية الحكمة التي تجعلك تعرف أي أداة تستخدم، ومتى تستخدمها، وما الذي تتنازل عنه، وماذا يحدث بعد ذلك.
هذا هو التفكير كمعماري.
والآن يمكننا أن نبدأ التفكير كـمعماري بيانات.
ما الذي يقرره المعماري هنا
Section titled “ما الذي يقرره المعماري هنا ”- هل الطلب متطلب حقيقي، أم تصميم واحد مقترح لتلبيته.
- ما الأسئلة التي تُطرح قبل بناء أي شيء: هل ينبغي ذلك، ولماذا بهذه الطريقة، وما الذي يمكن فعله غير ذلك، وماذا يحدث عندما يكبر أو يفشل.
- أي القرارات يتخذها المعماري، وأيها يعود إلى من يبنون؛ وما التوجيه والمعايير التي تُعطى للبنّائين، بشرًا كانوا أم ذكاءً اصطناعيًا.
- كيف يُشرح القرار بحيث يفهمه كلٌّ من المطوّر وفريق الأعمال والمدير التنفيذي.