تشتري أم تبني؟ قرار Build vs Buy بمعلومات ناقصة

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

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

وسوف نناقش في هذا المقال ما يلي:

• الفرق بين ما يميز شركتك Core وما تحتاجه فقط لتعمل Context، ولماذا يحدد هذا الفرق أغلب القرار.
• الخيارات الخمسة بين البناء والشراء، فالقرار ليس ثنائياً كما يبدو.
• تكلفة الملكية الكاملة TCO لثلاث سنوات، وكل بند فيها من التراخيص إلى تكلفة الخروج.
• القرار الذي يمكن الرجوع عنه والقرار الذي لا يمكن، كما وصفهما Jeff Bezos في رسائله لمساهمي Amazon.
• كيف تقرر بمعلومات ناقصة: سجل الافتراضات وتجربة محددة الوقت Spike وشروط الإيقاف Kill Criteria.
• الارتباط بمورد واحد Vendor Lock-in وسيادة البيانات Data Sovereignty.
• مثال كامل بالأرقام للدخول الموحد SSO، مع سكربت يحسب التكلفة ويختبر حساسية القرار لكل افتراض، ثم سجل القرار ADR.

ما الذي يميزك فعلاً؟ الأساسي Core والسياق Context

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

والجدول التالي يبين أمثلة، ولاحظ أن نفس النظام قد يكون أساسياً في شركة وسياقاً في أخرى:

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

ليست ثنائية: خمسة خيارات بين البناء والشراء

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

1. البناء الكامل Build: تكتب النظام بنفسك وتملكه بالكامل، وتتحمل كل شيء: الكود والأمن والتحديثات والمناوبة، وتكلفة الخروج منه عالية لأن كل التكاملات مكتوبة بطريقتك.
2. التوسيع Extend: تشتري منتجاً جاهزاً أو تستخدم منتجاً مفتوح المصدر، وتكتب فوقه الجزء الذي يخصك فقط، مثل إضافة Plugin أو تكامل عبر ال API أو سير عمل خاص، وهذا غالباً أفضل خيار عندما يكون 80% من حاجتك عاماً و20% خاصاً بك.
3. أداة مفتوحة المصدر على سيرفرك Self-hosted: مثل authentik للدخول الموحد أو Zammad لمكتب الدعم، فلا تدفع ترخيصاً، والبيانات عندك، ولكنك تدفع بالوقت: التثبيت والتحديث والنسخ الاحتياطي والمراقبة. وقد شرحنا متى يكون هذا الخيار استراتيجياً في الاستضافة الذاتية: متى تكون قراراً استراتيجياً؟.
4. مفتوح المصدر يديره المورد Managed Open Source: نفس الأداة المفتوحة، ولكن الشركة التي تطورها أو مزود آخر يشغلها لك مقابل اشتراك، فتحصل على راحة الخدمة السحابية مع طريق خروج واضح، لأنك تستطيع أن تأخذ بياناتك وتشغل نفس الأداة بنفسك لاحقاً.
5. الخدمة السحابية الجاهزة SaaS: تدفع لكل مستخدم أو لكل استخدام، والمورد يتحمل التشغيل والأمن والتحديث، ولكن البيانات عنده، والأسعار وشروط العقد بيده، والخروج يعتمد على ما يسمح لك بتصديره.

والجدول التالي يلخص الفرق بين الخيارات في الأسئلة التي تهم القرار:

تكلفة الملكية الكاملة TCO لثلاث سنوات

تكلفة الملكية الكاملة Total Cost of Ownership، واختصاراً TCO، هي كل ما تدفعه بسبب القرار طوال عمره، وليس سعر الترخيص فقط. ونحسبها عادة لثلاث سنوات، والسبب أن السنة الأولى تخدعك في الاتجاهين، فالبناء يبدو غالياً لأن كل التطوير فيها، والخدمة الجاهزة تبدو رخيصة لأن عدد المستخدمين ما زال صغيراً والخصم الأول ما زال سارياً. وفيما يلي البنود التي يجب أن تظهر في أي حساب، ولاحظ أن أغلبها وقت بشر وليس فواتير:

• التراخيص والاشتراكات Licences: السعر لكل مستخدم أو لكل سيرفر، مع الحد الأدنى للعقد، والزيادة مع نمو عدد الموظفين، والإضافات التي تحتاجها لاحقاً ولم تكن في الباقة الأولى.
• الإعداد Setup: ساعات التثبيت وربط التطبيقات ونقل البيانات وتدريب الموظفين، وهي موجودة حتى مع الخدمة الجاهزة، فربط خمسة عشر تطبيقاً بالدخول الموحد عمل حقيقي أياً كان المورد.
• الاستضافة Hosting: السيرفرات والتخزين والنسخ الاحتياطي ونقل البيانات، وقد شرحنا البنود التي تختفي عادة من الفاتورة الأولى في التكاليف الخفية في السحابة.
• التشغيل والتحديثات الأمنية Patching: كل إصدار جديد يحتاج قراءة ملاحظات الإصدار واختباراً وتطبيقاً، وكل ثغرة في النظام أو في مكتباته تحتاج استجابة في نفس الأسبوع، وهذا البند هو الذي ينساه من يقول «مفتوح المصدر مجاني».
• المناوبة On-call: إذا توقف الدخول الموحد توقفت كل التطبيقات خلفه، فمن يستيقظ في الثالثة فجراً؟ ومع الخدمة الجاهزة يستيقظ فريق المورد، ومع البناء أو الاستضافة الذاتية يستيقظ فريقك.
• المراجعة الأمنية Security Review: اختبار الاختراق ومراجعة الإعدادات والامتثال، وهي أعلى بكثير عندما تبني نظاماً أمنياً بنفسك.
• الترحيل Migration وتكلفة الخروج Exit Cost: كم يكلفك الخروج من هذا القرار بعد ثلاث سنوات؟ تصدير البيانات، وإعادة ربط التطبيقات، وتدريب الناس من جديد. وهذا البند هو الأهم في القرارات التي لا رجوع عنها، كما سوف نرى في القسم التالي.

وقد يتساءل البعض: لماذا نحسب ساعات فريقنا كتكلفة وهم يتقاضون رواتبهم في كل الأحوال؟ والإجابة أن ساعة المهندس التي تذهب إلى صيانة نظام الدخول لا تذهب إلى المنتج، فهي تكلفة حقيقية حتى لو لم تظهر في فاتورة، ولهذا نضرب الساعات في التكلفة الكاملة لساعة المهندس (الراتب والتأمين والمكتب والأدوات)، وليس في الراتب وحده.

القرار الذي يمكن الرجوع عنه Two-way Door والذي لا يمكن

في رسالته لمساهمي Amazon عن سنة 2015 قسم Jeff Bezos القرارات إلى نوعين: قرارات النوع الأول Type 1، وهي التي يصعب أو يستحيل الرجوع عنها، ووصفها بأنها أبواب في اتجاه واحد One-way Doors، فإذا عبرت منها ولم يعجبك ما رأيت فلن تستطيع العودة إلى حيث كنت، ولهذا يجب أن تتخذ ببطء وعناية وتشاور. وقرارات النوع الثاني Type 2، وهي أغلب القرارات، وتشبه بابين في الاتجاهين Two-way Doors، فإذا كان القرار غير مناسب تفتح الباب وتعود، ولهذا يجب أن تتخذ بسرعة من أشخاص يحسنون التقدير أو من مجموعات صغيرة. ولاحظ تحذيره في نفس الرسالة من أن المؤسسات عندما تكبر تميل إلى استخدام الطريقة الثقيلة للنوع الأول في أغلب القرارات، فتصبح بطيئة وتخاف من التجربة.

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

والأهم من التصنيف أنك تستطيع أن تغير نوع الباب بالتصميم. فالدخول الموحد الذي تربط به التطبيقات عبر بروتوكولات قياسية مثل OpenID Connect وSAML باب أقرب للاتجاهين، لأن التطبيقات لا تعرف من يصدر التوكن، فإذا غيرت المورد غيرت الإعدادات في كل تطبيق ولم تغير الكود. أما الدخول الذي تبنيه بجداول خاصة وجلسات تقرأها التطبيقات مباشرة من قاعدة بياناتك، فهو باب في اتجاه واحد مهما كان الكود جميلاً. وقد شرحنا البروتوكولات نفسها في شرح OAuth وOpenID Connect للمبتدئين. وبنفس الطريقة اسأل عن كل خيار: هل أستطيع تصدير البيانات بصيغة مفتوحة؟ هل العقد سنوي أم متعدد السنوات؟ هل التكاملات قياسية أم خاصة بالمورد؟

كيف تقرر ومعلوماتك ناقصة؟

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

سجل الافتراضات Assumptions Log

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

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

التجربة محددة الوقت Spike وTimebox

التجربة محددة الوقت Spike هي عمل قصير هدفه الوحيد أن يجيب عن سؤال، وليس أن ينتج نظاماً للإنتاج، ونحدد لها وقتاً لا يتجاوزه أحد Timebox، مثل خمسة أيام. وفي مثالنا تكون التجربة: تثبيت authentik على سيرفر اختبار كما في دليل تثبيت authentik، وربط ثلاثة تطبيقات مختلفة به، أحدها الأصعب في القائمة، ثم تحديثه إلى إصدار أحدث وقياس الوقت. وفي نهاية اليوم الخامس تكتب ما تعلمته في صفحة واحدة، حتى لو لم تنته، لأن «لم ننته في خمسة أيام» معلومة مهمة بحد ذاتها.

شروط الإيقاف Kill Criteria

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

• إذا تجاوز وقت التشغيل الشهري الفعلي 25 ساعة لثلاثة أشهر متتالية، ننتقل إلى الخدمة الجاهزة.
• إذا لم نستطع ربط تطبيقين من الخمسة الأهم في أسبوعين، نعيد التقييم.
• إذا رفع المورد سعره أكثر من 30% عند التجديد، نفعل خطة الخروج التي كتبناها مسبقاً.

الارتباط بمورد واحد Vendor Lock-in وسيادة البيانات

الارتباط بمورد واحد Vendor Lock-in ليس شيئاً واحداً، وإنما عدة أنواع، ولكل نوع سؤال تسأله قبل التوقيع:

• ارتباط البيانات: هل تستطيع تصدير كل بياناتك بصيغة مفتوحة، وهل يشمل ذلك السجلات Logs والإعدادات، أم المستخدمين فقط؟
• ارتباط البروتوكول: هل التطبيقات مربوطة بمعايير مثل OpenID Connect وSAML وSCIM، أم بمكتبة المورد الخاصة؟ وقد شرحنا SCIM في ما هو SCIM؟.
• ارتباط العقد: مدة الالتزام والحد الأدنى للعقد وشروط التجديد، فمثلاً تشترط Okta حداً أدنى للعقد السنوي، وتبيع Microsoft اشتراك Entra ID P1 بالتزام سنوي، كما سوف نرى في جدول الأسعار.
• ارتباط المهارات وسير العمل: بعد ثلاث سنوات يصبح فريقك خبيراً في أداة واحدة، وتبنى إجراءات الشركة حولها، وهذا ارتباط لا يظهر في أي عقد.

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

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

مثال كامل: الدخول الموحد SSO لشركة فيها 200 موظف

لنفرض أن لديك شركة فيها 200 موظف، وخمسة عشر تطبيقاً داخلياً، وتريد الدخول الموحد SSO مع التحقق متعدد العوامل MFA. والخيارات التي سوف نقارنها خمسة: خدمة Okta السحابية، واشتراك Microsoft Entra ID P1، وauthentik مفتوح المصدر على سيرفرك، ونسخة authentik Enterprise على سيرفرك، والبناء الداخلي. والبناء هنا موجود لأنه يطرح فعلاً في الاجتماعات، وليس لأنه خيار مناسب، فنظام الدخول من السياق في أغلب الشركات، وهو في نفس الوقت من أخطر الأنظمة أمنياً، فأي خطأ فيه يفتح كل التطبيقات خلفه.

الأسعار من صفحات الموردين

الأسعار التالية منقولة من الصفحات الرسمية بتاريخ 13 أكتوبر 2026، وهي أسعار القائمة قبل أي خصم، وسوف تتغير، فارجع إلى الصفحات قبل أن تعتمد عليها:

والرخصة مأخوذة من ملف الرخصة في مستودع authentik، حيث الكود تحت رخصة MIT ما عدا مجلد النسخة التجارية الذي له رخصته الخاصة.

الافتراضات التي لا تجدها في أي صفحة

الأسعار أعلاه حقائق منشورة، أما كل ما يلي فهو افتراضات وضعناها للمثال، وليست قياسات من شركة حقيقية، والفكرة أن تضع أرقامك أنت مكانها، ثم ترى هل يتغير القرار:

ومع ذلك افترضنا أن التكلفة الكاملة لساعة المهندس 60 دولاراً، وأن عدد المستخدمين يزيد 10% كل سنة، وأن الخيارات التي تشغلها بنفسك تحتاج 10 دولارات استضافة إضافية وساعة تشغيل إضافية في الشهر لكل 100 مستخدم فوق المئتين. ولاحظ أن ساعات الخروج من authentik أقل من الخدمة الجاهزة، والسبب أن البيانات والإعدادات عندك، وأن ساعات الخروج من البناء هي الأعلى، لأن التطبيقات غالباً ترتبط بطريقة خاصة بنظامك.

السكربت الذي يحسب التكلفة

بدلاً من جدول Excel تختفي فيه المعادلات، نكتب الحساب في سكربت Python قصير يقرأه أي شخص في الفريق ويعدل أرقامه، والملف التالي هو السكربت كاملاً:

"""Three-year total cost of ownership (TCO) for an SSO decision.
Prices: vendor pages checked 2026-10-13. Everything else is an ASSUMPTION: replace it with your own numbers."""
import sys

YEARS = 3
BASE = {
    "users": 200,          # employees who log in (internal users)
    "growth": 0.10,        # yearly growth in users
    "rate": 60,            # fully loaded cost of one engineer hour, USD (assumption)
}

# hours are engineer hours; money is USD
# scale=True: you run the servers, so hosting grows $10/month and operations 1 hour/month for every 100 users above 200
OPTIONS = {
    "Okta Starter (SaaS)": dict(
        price=6, min_year=1500, hosting_month=0, setup_h=80, ops_h_month=4,
        security_h_year=8, oncall_h_month=0, exit_h=120),
    "Entra ID P1 (SaaS)": dict(
        price=7, min_year=0, hosting_month=0, setup_h=80, ops_h_month=4,
        security_h_year=8, oncall_h_month=0, exit_h=120),
    "authentik open source (self-hosted)": dict(
        price=0, min_year=0, hosting_month=40, setup_h=160, ops_h_month=12,
        security_h_year=24, oncall_h_month=4, exit_h=60, scale=True),
    "authentik Enterprise (self-hosted)": dict(
        price=5, min_year=0, hosting_month=40, setup_h=140, ops_h_month=10,
        security_h_year=24, oncall_h_month=3, exit_h=60, scale=True),
    "Build in-house": dict(
        price=0, min_year=0, hosting_month=40, setup_h=960, ops_h_month=30,
        security_h_year=80, oncall_h_month=6, exit_h=200, scale=True),
}


def tco(o, users, growth, rate, ops_factor=1.0, entra_owned=False):
    lines = {"licences": 0.0, "hosting": 0.0, "setup": o["setup_h"] * rate,
             "operations": 0.0, "security": 0.0, "on-call": 0.0, "exit": o["exit_h"] * rate}
    for year in range(YEARS):
        n = users * (1 + growth) ** year
        extra = max(n - 200, 0) / 100 if o.get("scale") else 0
        price = 0 if (entra_owned and o["price"] == 7) else o["price"]
        lines["licences"] += max(price * n * 12, o["min_year"] if price else 0)
        lines["hosting"] += (o["hosting_month"] + 10 * extra) * 12
        lines["operations"] += (o["ops_h_month"] + extra) * 12 * rate * ops_factor
        lines["security"] += o["security_h_year"] * rate * ops_factor
        lines["on-call"] += o["oncall_h_month"] * 12 * rate * ops_factor
    lines["total"] = sum(lines.values())
    return lines


def table(users=BASE["users"], growth=BASE["growth"], rate=BASE["rate"], ops_factor=1.0, entra_owned=False):
    rows = {name: tco(o, users, growth, rate, ops_factor, entra_owned) for name, o in OPTIONS.items()}
    return dict(sorted(rows.items(), key=lambda kv: kv[1]["total"]))


def k(x):
    return f"{x / 1000:6.1f}k"


print(f"3-year TCO, users={BASE['users']} (+{BASE['growth']:.0%}/yr), engineer hour=${BASE['rate']}")
cols = ["licences", "hosting", "setup", "operations", "security", "on-call", "exit", "total"]
print(f"{'option':38}" + "".join(f"{c:>11}" for c in cols))
for name, r in table().items():
    print(f"{name:38}" + "".join(f"{k(r[c]):>11}" for c in cols))

print("\nSensitivity: cheapest option and its 3-year total when ONE assumption changes")
cases = [("users=50", dict(users=50)), ("users=1000", dict(users=1000)), ("users=3000", dict(users=3000)),
         ("engineer hour=$30", dict(rate=30)), ("engineer hour=$120", dict(rate=120)),
         ("ops hours x0.5", dict(ops_factor=0.5)), ("ops hours x2", dict(ops_factor=2.0)),
         ("Entra P1 already paid", dict(entra_owned=True))]
for label, kw in cases:
    t = table(**kw)
    (n1, r1), (n2, r2) = list(t.items())[:2]
    print(f"{label:22} 1st {n1:36} {k(r1['total'])}   2nd {n2:36} {k(r2['total'])}")

print("\nBreak-even: users at which self-hosted authentik open source becomes cheaper than Okta Starter")
for rate in (30, 60, 120):
    be = next((u for u in range(10, 20001, 10)
               if tco(OPTIONS["authentik open source (self-hosted)"], u, BASE["growth"], rate)["total"]
               < tco(OPTIONS["Okta Starter (SaaS)"], u, BASE["growth"], rate)["total"]), None)
    print(f"engineer hour=${rate:<4} break-even at about {be} users")

ونشغله داخل Container من Docker Image الرسمية لPython حتى لا نثبت شيئاً على الجهاز:

docker run --rm --name lab-skl-tco -v "$PWD:/w:ro" python:3.13.16-slim python /w/tco.py

والمخرج سوف يكون كما يلي:

3-year TCO, users=200 (+10%/yr), engineer hour=$60
option                                   licences    hosting      setup operations   security    on-call       exit      total
authentik open source (self-hosted)          0.0k       1.5k       9.6k      26.4k       4.3k       8.6k       3.6k      54.0k
Okta Starter (SaaS)                         47.7k       0.0k       4.8k       8.6k       1.4k       0.0k       7.2k      69.7k
Entra ID P1 (SaaS)                          55.6k       0.0k       4.8k       8.6k       1.4k       0.0k       7.2k      77.7k
authentik Enterprise (self-hosted)          39.7k       1.5k       8.4k      22.0k       4.3k       6.5k       3.6k      86.1k
Build in-house                               0.0k       1.5k      57.6k      65.2k      14.4k      13.0k      12.0k     163.7k

Sensitivity: cheapest option and its 3-year total when ONE assumption changes
users=50               1st Okta Starter (SaaS)                    34.0k   2nd Entra ID P1 (SaaS)                     36.0k
users=1000             1st authentik open source (self-hosted)    76.3k   2nd Build in-house                        186.0k
users=3000             1st authentik open source (self-hosted)   131.9k   2nd Build in-house                        241.6k
engineer hour=$30      1st authentik open source (self-hosted)    27.8k   2nd Okta Starter (SaaS)                    58.7k
engineer hour=$120     1st Okta Starter (SaaS)                    91.8k   2nd Entra ID P1 (SaaS)                     99.8k
ops hours x0.5         1st authentik open source (self-hosted)    34.4k   2nd Okta Starter (SaaS)                    64.7k
ops hours x2           1st Okta Starter (SaaS)                    79.8k   2nd Entra ID P1 (SaaS)                     87.8k
Entra P1 already paid  1st Entra ID P1 (SaaS)                     22.1k   2nd authentik open source (self-hosted)    54.0k

Break-even: users at which self-hosted authentik open source becomes cheaper than Okta Starter
engineer hour=$30   break-even at about 70 users
engineer hour=$60   break-even at about 140 users
engineer hour=$120  break-even at about 280 users

في المخرج أعلاه لاحظ التالي:

• في الحالة الأساسية يأتي authentik مفتوح المصدر أولاً بحوالي 54 ألف دولار لثلاث سنوات، ثم Okta بحوالي 70 ألفاً، ولكن انظر إلى تكوين كل رقم: 26 ألفاً من تكلفة authentik ساعات تشغيل، و48 ألفاً من تكلفة Okta تراخيص، أي أن المقارنة الحقيقية هي بين وقت فريقك وفاتورة المورد.
• نسخة authentik Enterprise جاءت أغلى من الخدمة الجاهزة في هذا النموذج، لأنك تدفع الترخيص وتتحمل التشغيل معاً، وهي منطقية فقط إذا احتجت ميزاتها أو الدعم الرسمي مع بقاء البيانات عندك.
• البناء الداخلي هو الأغلى بفارق كبير، وأكثر من ثلث تكلفته في السنة الأولى قبل أن يستفيد منه أحد.

اختبار الحساسية: أي افتراض يغير القرار؟

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

• القرار يتغير إذا كانت ساعة المهندس 120 دولاراً، أو إذا تضاعفت ساعات التشغيل، فيصبح Okta هو الأرخص، وهذا يعني أن أهم افتراض في الحساب كله ليس سعر الترخيص وإنما قدرة فريقك على التشغيل بكفاءة، ولهذا كانت تجربة Spike لقياس ساعات التشغيل أهم خطوة قبل القرار.
• مع 50 مستخدماً تفوز الخدمة الجاهزة بوضوح، ونقطة التعادل بين authentik وOkta حوالي 140 مستخدماً إذا كانت ساعة المهندس 60 دولاراً، وتتحرك إلى حوالي 280 مستخدماً إذا كانت 120 دولاراً، فالشركة الصغيرة ذات المهندسين مرتفعي التكلفة تشتري، والشركة الأكبر أو التي لديها فريق تشغيل تستضيف بنفسها.
• إذا كان Entra ID P1 مدفوعاً أصلاً ضمن اشتراك Microsoft 365 لديك، فهو الأرخص بفارق كبير، لأن تكلفته الإضافية صفر، وهذا افتراض يجب أن تتحقق منه في عقدك قبل أي حساب آخر.
• مع 1000 و3000 مستخدم يأتي البناء الداخلي في المرتبة الثانية، وهذه هي اللحظة التي يجب أن تتذكر فيها حدود النموذج، فالسكربت لا يحسب احتمال الاختراق ولا تكلفة الفرصة الضائعة ولا صعوبة توظيف من يصون نظام دخول مكتوب داخلياً، وكل هذه تجعل البناء خياراً غير مناسب حتى لو بدا رخيصاً في الجدول.

سجل القرار ADR: كيف تكتب ما قررته ولماذا

بعد القرار اكتبه في سجل القرار المعماري Architecture Decision Record، واختصاراً ADR، والسبب أن من سيأتي بعد سنة سوف يسأل «لماذا لم تشتروا Okta؟» أو «لماذا لم تستضيفوه بأنفسكم؟»، والإجابة يجب أن تكون مكتوبة مع الافتراضات التي كانت صحيحة وقتها. وقد شرحنا صيغ هذا السجل وأدواته في توثيق المعمارية: مخططات C4 وسجل القرار ADR، وفيما يلي سجل مثالنا كاملاً بصيغة قريبة من قالب MADR:

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

أخطاء شائعة في قرار الشراء أو البناء

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

قائمة تحقق قبل القرار

• هل هذا النظام من الأساسي Core أم من السياق Context في شركتنا؟
• هل كتبنا الخيارات الخمسة، وليس البناء والشراء فقط؟
• هل حسبنا التكلفة لثلاث سنوات بكل البنود، ومنها المناوبة والخروج؟
• هل غيرنا كل افتراض مهم ورأينا هل يتغير القرار؟
• هل القرار باب في اتجاه واحد أم في الاتجاهين؟ وهل نستطيع أن نجعله في الاتجاهين بالتصميم؟
• هل يوجد شرط لمكان البيانات أو للامتثال يحسم القرار قبل التكلفة؟
• هل اتفقنا على شروط الإيقاف قبل أن نبدأ؟
• هل كتبنا سجل القرار ADR مع تاريخ المراجعة؟

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

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

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

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

سجل التحديثات

• أكتوبر 2026: كتابة المقال، ونقل أسعار Okta وMicrosoft Entra وauthentik من صفحاتها الرسمية بتاريخ 13 أكتوبر 2026، وتشغيل سكربت التكلفة على Python 3.13.16.
• أكتوبر 2026: إضافة المصطلحات الإنجليزية إلى العنوان والعناوين الفرعية.