المعمارية هي فن المفاضلة

🌐 متاح أيضًا بـ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)

صورة مولّدة بالذكاء الاصطناعي

ترجمة بالذكاء الاصطناعي. لم يراجعها المجتمع بعد. اقرأ بالإنجليزية

الوحدة 4 من 7 في فصل التفكير كمعماري بيانات، الفصل الأول من دورة Data Architect. كل وحدة قائمة بذاتها. السابق: اختبار قابلية التراجع · التالي: ابنِ لليوم. خطّط للغد. خطّط للفشل.

السؤال الذي تجيب عنه هذه الوحدة: عندما يمكن أن تنجح عدة حلول، كيف يختار المعماري، وكيف يشرح اختياره؟

لو كانت المعمارية مجرد تحديد الإجابة الصحيحة، لكانت أسهل بكثير. تعلّم المنصة، وتعلّم الأنماط، وتعلّم الحدود، واختر الصحيح، وانتهى الأمر.

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

طرق كثيرة لحل المشكلة

استخدمت صيغة من هذا المثال مرات كثيرة وأنا أعلّم المعماريين.

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

ما يتبقى هو عدد صغير من الخيارات التي تستطيع تلبية احتياجاتك في المستقبل، وهنا يصبح الأمر مثيرًا. كل منها قد يعمل، ويتوسع، ويلبي المتطلبات. فأيها الصحيح؟ ربما كلها. ومهمة المعماري أن يفهم الفروق.

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

استخدم علاقة بحث (lookup) بدلًا منها، وستصبح واجهة المستخدم أعقد قليلًا. لكن القائمة يمكن أن تستمر في النمو بلا حد أعلى، ويمكن أن تصل قيم جديدة من عملية تكامل. هذه مفاضلة على حساب سهولة الاستخدام. هذا هو التوازن.

Click to enlarge

الأمثل لا يعني المثالي

أستخدم كلمة الأمثل بحذر. المعمارية المثلى ليست تلك التي يكون فيها كل قرار منفرد مثاليًا؛ فتلك المعمارية على الأرجح غير موجودة. بل هي التي يكون فيها الحل ككل متوازنًا.

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

ومهمتك بوصفك معماري بيانات أن توازن هذه القرارات. ستتخذ عشرات منها بنفسك، أو مع فريقك. اعرف أيها تلك، واعرف متى يكون للقرار أثر أكبر، على الكلفة أو الوقت أو الوظائف، ويحتاج إلى أن يُرفع إلى صنّاع القرار الرئيسيين.

قد يكون القرار دون الأمثل جزءًا من معمارية مثلى

هذه من أهم الأفكار في هذا الفصل. أحيانًا أتخذ عن وعي قرارًا دون الأمثل في جزء من المعمارية لأنه يجعل الحل كله أفضل.

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

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

اعرف ما الذي تتنازل عنه

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

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

المتطلبات ليست متساوية

المفاضلات تجبرنا أيضًا على أن نرى أن المتطلبات لا تحمل كلها الوزن نفسه.

يقول أحدهم: «يجب أن تكون البيانات متاحة فورًا.» حسنًا، ماذا تعني «فورًا»؟ ثانية واحدة، عشر ثوانٍ، دقيقة؟ ولماذا؟ ربما هو كشف الاحتيال، حيث تهم الثواني. وربما لا يحب أحدهم ببساطة انتظار التحميل الليلي. هذان متطلبان مختلفان تمامًا، ويظل المعماري يسأل حتى نعرف أيهما لدينا.

أحب المتطلبات التي تصمد أمام الأسئلة: كم الكمية، وكم العدد، وبأي سرعة، وكم مرة، ولمن، وماذا يحدث إن لم نفعل؟ «سريع» ليس متطلبًا معماريًا. أما «يجب أن تكون 95% من تحديثات العملاء متاحة لوكيل الخدمة خلال 30 ثانية» فأقرب إليه بكثير. الآن يمكننا تقييم المفاضلات.

القيود تغيّر الإجابة

أحيانًا لا تكون المعمارية مقيّدة بالتقنية أصلًا. بل بالمال، أو بالناس، أو بالوقت، أو بالتراخيص، أو بنضج المؤسسة.

المعمارية الممتازة تقنيًا التي تحتاج إلى فريق عمليات لا تملكه الشركة ليست معمارية جيدة. والقدرة التي تحل المشكلة بأناقة لكنها تحتاج إلى تراخيص لن يشتريها العميل ليست الحل أيضًا. والتحوّل المثالي على مدى ثلاث سنوات لا يساعد شركة عليها أن تُطلق خلال ثمانية أسابيع.

لا يعني أيٌّ من ذلك أن نتخلى عن المعمارية الجيدة بسبب موعد نهائي. بل يعني أن نفهم ما الذي نتنازل عنه، ولماذا، وما العواقب التي نقبلها، ويُفضَّل أن نعرف كيف سننتقل من حل اليوم الوسط إلى معمارية الغد.

يحتاج المعماري إلى صورة لـ«الأمثل»

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

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

ارسمه

من أفضل الطرق لفهم مفاضلة ما أن ترسمها. مخططات المعمارية ليست زينة لعرض تقديمي؛ بل هي أدوات تفكير. إذا كنا نختار بين نهجين، فارسم كليهما. أين تعيش البيانات، وإلى أين تنتقل؟ ما الذي يملكها؟ أين الحدود، وأين يُفرض الأمان؟ ماذا يحدث عندما يفشل شيء ما، وما الذي يتغير مع نمو الحجم؟

المخطط يُخرج الغموض إلى العلن، ويمنح الجميع الصورة نفسها ليشيروا إليها.

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

ولأن الأشخاص أنفسهم كانوا يجتمعون مرة بعد مرة، أصبح المخطط لغتنا المشتركة. بدأ الناس يستخدمون أسماءه. وتلاشت الأسئلة المتكررة، وأصبحت الاجتماعات أسهل بكثير. أسمّي ذلك تأريض الاجتماع: مخطط بسيط يُعرض في كل مرة كان يساوي أكثر بكثير مما كلّف صنعه.

الهدف ليس الكمال الفني. أحيانًا يكون مخططًا مفصّلًا للمهندسين، وأحيانًا خمسة مربعات وستة أسهم لمدير تنفيذي. الهدف هو الوضوح.

اشرح المفاضلة

المعماري الجيد يعرضها بالترتيب: هذه الخيارات التي درسناها، وهذا ما يمنحنا إياه كل منها، وهذا ما يكلّفنا إياه كل منها، وهذا الخيار الذي أوصي به، وهذا هو السبب.

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

Think Correct. Think Fast.

لن يكون لديك دائمًا ثلاثة أسابيع لتحليل كل خيار. أحيانًا سيكون لديك ثلاث دقائق. يتغير متطلب في اجتماع، أو يذكر أحدهم قيدًا لم تكن تعرفه، أو يسأل مدير تنفيذي: «ماذا لو احتجنا إلى هذا في أوروبا العام القادم؟»

استخدمت عبارة Think Correct. Think Fast. (فكّر بصواب. فكّر بسرعة.) السرعة لا تأتي من تخطي التفكير. بل تأتي من أنك فكّرت بما يكفي قبل أن تحين اللحظة: تعلّمت الأنماط، وتعرف المنصة، ورأيت حالات الفشل، وتعرف أي الأسئلة تطرح وأي القرارات يصعب التراجع عنها. لهذا نعمل على سيناريوهات طوال هذه الدورة. كلما حلّلت قرارات أكثر، أسرعت في التعرّف على شكل القرار التالي.

كان لدي عميل يحتاج إلى إدخال نماذج. لكن النماذج كانت كثيرة، والأسئلة قد تتغير مع الوقت. أدركت بسرعة الحاجة إلى نموذج بيانات للاستبيانات، وهو نمط سنعود إليه لاحقًا في الدورة. ولأنني تعرّفت على النمط والحل، استطعت أن أقدّم نموذج بيانات أكثر اكتمالًا، يتعامل مع المتطلبات التي لم تأتِ بعد، لا مع التي أمامنا فقط.

المعمارية تدور حول التوازن

كلما تعمقنا في معمارية البيانات، ستواجه خيارات أمتنع فيها عن إعطائك قاعدة بسيطة. التطبيع أم التسطيح؟ نسخ البيانات أم الوصول الموحّد إليها (federation)؟ متزامن أم غير متزامن؟ كائن قياسي أم مخصص؟ أرشفتها أم إبقاؤها متاحة على الإنترنت؟

هناك مبادئ وأنماط وحدود، وأحيانًا إجابات خاطئة بوضوح. لكن كثيرًا ما تكون مهمة المعماري أن يجد التوازن الصحيح لهذا النظام، ولهذا العمل، ولهذه اللحظة.

اعرف كيف يبدو الأمثل. افهم القيود. حدد الخيارات القابلة للتطبيق. اجعل المفاضلات مرئية. ثم اتخذ القرار.

هذا ليس ترددًا. هذه هي المعمارية.

ما الذي يقرره المعماري هنا

• أي الخيارات قابلة للتطبيق، وأيها خاطئ الآن أو سيفسد خلال سنة.
• ما يكسبه كل خيار قابل للتطبيق وما يتخلى عنه، مقيسًا بمتطلبات تصمد أمام الأسئلة.
• أي القيود حقيقية وأيها مجرد تفضيلات.
• أي خيار يُوصى به، بعد عرض المفاضلات، وكيف يُشرح.