البنية التحتية والتقنيات
لا نكتب كل شيء بأنفسنا؛ وما نبني عليه أيضاً قرار
- الرئيسية
- /
- الشركة
- /
- البنية التحتية والتقنيات
يوجد أسفل أي نظام الكثير مما لم نكتبه نحن. الشبكة التي تُحلّ من خلالها أسماء النطاقات، وقاعدة البيانات التي تحتفظ بالبيانات، وخط الإنتاج الذي تُطبع عليه اللوحة، والخدمات التي يتواصل معها التطبيق. لا شيء من هذا تفصيل يُمكن التغاضي عنه كبند توريد؛ فهذه العناصر هي ما يحدد سلوك النظام فعلياً في الميدان.
لا نسمّي هذه الجهات شركاء حلول، لأنها ليست كذلك. فلا يوجد بيننا عقد شراكة؛ لكن طبقة حلّ الأسماء والوكيل والتخزين المؤقت التي تقف أمام أي موقع تأتي من الخارج، وإذا توقفت تلك الطبقة توقف الموقع. كما تخرج لوحاتنا الأولية من خط إنتاج ليس ملكاً لنا. والاسم الحقيقي لهذه العلاقة هو الاعتماد لا الشراكة، ويجب أن يكون هذا الاعتماد خياراً واعياً.
لذلك تُناقَش البنية التحتية المستخدمة ضمن قرارات المشروع نفسها، لا كخيار يُضاف لاحقاً. وفيما يلي بعض الطبقات التي نبني عملنا عليها اليوم؛ وتتغير القائمة بحسب المشروع، وتطول أو تقصر تبعاً للبنية القائمة لدى المؤسسة.
شركاؤنا التقنيون
- Cloudflare
- Microsoft SQL Server
- .NET
- Entity Framework Core
- Avalonia
- Roslyn
- SQLite
- OpenAPI
- JLCPCB
تتغير القائمة بحسب المشروع. ففي كل عمل، تُعاد صياغة البنية التحتية المستخدمة وفق البنية القائمة لدى المؤسسة ومتطلبات العمل.
معايير اختيارنا
إمكانية التوريد
المكوّن الذي يبدو مثالياً في ورقة البيانات ليس الخيار الصحيح إذا طال أمد توريده أو جاء من مصدر واحد. ونفضّل القطع التي لها بديل والمتوفرة على نطاق واسع.
الاستدامة
قد تصبح الأداة الأسرع اليوم أداة يتعذّر إيجاد من يصونها بعد ثلاث سنوات. ولهذا المعيار عندنا أولوية تسبق الأداء.
التوافق مع البنية القائمة
أي مكوّن لا يتواصل مع الأنظمة القائمة لدى المؤسسة يرفع التكلفة الإجمالية حتى لو كان متفوقاً تقنياً. وتُحتسب تكلفة التوافق في مرحلة الاختيار.
هامش الاستقلالية
لا تُتَّخذ القرارات التي تحصر المؤسسة بمورّد واحد دون مناقشة تكلفة الخروج منه. فأي اعتماد يُبنى دون معرفة تلك التكلفة يعمل لاحقاً ضدكم على طاولة التفاوض.
لنتحدث عن العمل معاً
إذا كان لديكم اقتراح أو سؤال حول هذا الموضوع، فلنبدأ بمحادثة قصيرة.