كيف تصمم بنية تطبيق جوال مؤسسي متعدد المنصات قابل للتوسّع: لماذا تقل أهمية إطار العمل أمام الخدمة الخلفية، وكيف تهيكل الكود المشترك، وما الذي يجب التخطيط له في السياق المؤسسي القطري.
بالنسبة للمؤسسة، نادراً ما يكون تطبيق الجوال منتجاً قائماً بذاته. إنه سطح واحد يطل على أنظمة موجودة أصلاً — نظام ERP، ومحرك رواتب، وقاعدة بيانات عملاء، ونظام تتبع أسطول — وعليه عادةً أن يعمل على نظامي iOS و Android معاً، للموظفين والعملاء، دون مضاعفة فريق الهندسة. هذه هي الحالة التي وُجد من أجلها التطوير متعدد المنصات. لكن اختيار إطار عمل متعدد المنصات هو القرار السهل؛ أما بناء البنية الصحيحة فهو حيث تُكسب التطبيقات المؤسسية أو تُخسر. يتناول هذا المقال تلك البنية.
تميل الفرق إلى افتتاح النقاش بجدال حول أطر العمل — إطار متعدد المنصات حديث مقابل آخر، أو متعدد المنصات مقابل الأصلي. بالنسبة للغالبية العظمى من التطبيقات المؤسسية، سيُنتج أي من أطر العمل الناضجة متعددة المنصات تطبيقاً لا يستطيع المستخدم تمييزه عن الأصلي، من شفرة واحدة، وبنحو نصف تكلفة صيانة شفرتين. إطار العمل قرار حقيقي، لكنه قرار قابل للعكس ومحدود الأثر. أما القرارات التي يكلّف الخطأ فيها كثيراً فتقع في مكان آخر.
القرارات المكلفة تتعلق بالحدود: أين يعيش منطق الأعمال، وكيف يتحدث التطبيق مع أنظمتك القائمة، وكيف تتعامل مع المصادقة والصلاحيات عبر المؤسسة، وكيف تشحن التحديثات إلى قوة عاملة دون أن تعطّل يومها. التطبيق الجميل المبني على حدود ضعيفة يصبح غير قابل للصيانة خلال عام. والتطبيق البسيط المبني على حدود قوية يواصل تحقيق العائد لسنوات.
التطبيق المؤسسي عميلٌ رفيع فوق واجهة برمجية (API). الخيار المعماري الأهم هو كيفية تصميم تلك الواجهة، لأن التطبيق يرث كل قوة وضعف في الأنظمة التي خلفها.
الخطأ الذي نراه غالباً هو ترك التطبيق يتحدث مباشرةً مع عشرات الأنظمة الداخلية — نظام ERP هنا، وقاعدة بيانات الرواتب هناك، وخدمة طرف ثالث في مكان آخر — لكلٍّ منها خصائصه ونموذج مصادقته وأنماط أعطاله. كل واحد من هذه الارتباطات موضعٌ قد ينكسر فيه التطبيق، وكل تغيير في نظام داخلي يتردد صداه مباشرةً في التطبيق. البديل المنضبط هو طبقة واجهة برمجية مخصصة (Backend-for-Frontend) تجلس بين التطبيق وأنظمتك. يتحدث التطبيق مع واجهة واحدة محددة جيداً، وتتولى تلك الطبقة فوضى التكامل مع كل ما خلفها، ويمكنها أن تتطور باستقلالية. وعند استبدال نظام ERP، لا يلاحظ التطبيق ذلك.
هذا هو الانضباط نفسه الذي يجعل نظام الرواتب يُنتج ملفاً يقبله البنك، أو نظام ERP يتوافق مع القواعد المحاسبية القطرية: القيمة في نمذجة المجال بشكل صحيح عند الحدود، لا في الشاشات. صمّم الواجهة البرمجية أولاً وأحسِن تصميمها، وسيصبح التطبيق عميلاً مباشراً لها — مع لوحة تحكم ويب أو تكامل مع شريك كعملاء إضافيين للواجهة نفسها، يُضافون لاحقاً دون إعادة كتابة.
الكود متعدد المنصات ليس بالضرورة كوداً جيد الهيكلة. الشفرة الواحدة لنظامي iOS و Android وسيلة لمشاركة الكود، لكن مشاركة كل شيء دون تمييز تُنتج تشابكاً. البنية التي تصمد تفصل ثلاثة اهتمامات بوضوح:
فصل هذه الطبقات يعني أن تغييراً في شاشة لا يمكن أن يكسر قاعدة عمل بصمت، وأن القاعدة يمكن اختبارها دون تشغيل التطبيق أصلاً.
بالنسبة للتطبيق المؤسسي، يستحق السلوك دون اتصال (Offline) عنايةً خاصة. يفقد الموظفون الميدانيون الاتصال — في قبو، أو مستودع، أو موقع نائٍ. التطبيق الذي يفترض اتصالاً حياً غير قابل للاستخدام في اللحظات التي يُحتاج فيها بالضبط. تصميم طبقة البيانات لتعمل بمبدأ "دون اتصال أولاً" (offline-first)، مع وضع الإجراءات في طابور ومزامنتها عند عودة الاتصال، قرار معماري يجب اتخاذه مبكراً؛ فتعديله لاحقاً صعب جداً.
لتطبيقات المستهلكين نوع واحد من المستخدمين. أما التطبيقات المؤسسية فلها أدوار — الفني يرى مهام اليوم، والمدير يرى الفريق بأكمله، والمالية ترى الأرقام، والمسؤول يهيّئ النظام. الوصول إلى هذا بشكل صحيح يعني تصميم الصلاحيات كجزء أساسي من البنية، لا كمجموعة من شروط if المبعثرة في الشاشات.
تريد معظم المؤسسات أيضاً أن يسجّل الموظفون الدخول بالهوية التي يملكونها أصلاً — الدليل المؤسسي، والدخول الموحّد (SSO) — بدلاً من كلمة مرور منفصلة للتطبيق تُنسى وتُعاد. التخطيط للدخول الموحّد والهوية المركزية منذ البداية يتجنب هجرة مؤلمة لاحقاً، وهو ما تتوقع مراجعة الأمان رؤيته. ويجب فرض قواعد الصلاحيات على الخادم، لا في التطبيق فقط: فالتطبيق يمكن فحصه وتعديله، والخادم هو المكان الوحيد الذي يمكن فيه فرض الصلاحية فعلاً.
للتطبيق المؤسسي المبني لقطر متطلبات لن يتوقعها قالب عام، وهي متطلبات معمارية لا تجميلية.
يجب بناء التصميم "العربي أولاً" وثنائي اللغة فعلاً في طبقة العرض منذ البداية — تخطيط من اليمين إلى اليسار، ومحتوى مختلط عربي-إنجليزي في العرض نفسه، ومعالجة صحيحة للأرقام والتواريخ — لا إلحاقه كترجمة متأخرة. وتشكّل إقامة البيانات وقانون حماية البيانات الشخصية (PDPPL) مكان وجود الخدمة الخلفية وبياناتها وكيفية التعامل مع البيانات الشخصية، وهو قرار حول البنية التحتية والمعمار يُتخذ مسبقاً، لا إجراء ورقي يُؤجل إلى الإطلاق. والتكاملات المهمة غالباً ما تكون المحلية — بنك قطري، ملف رواتب WPS، بوابة حكومية — وهذا بالضبط سبب استحقاق طبقة الواجهة البرمجية المخصصة لمكانها: فهي حيث تُمتَص تلك التعقيدات المحلية ليبقى التطبيق نظيفاً.
الاهتمام المعماري الأخير هو التسليم. التطبيق المؤسسي يُستخدم يومياً، لذا فإن تحديثاً يكسر شيئاً ليس إزعاجاً — بل يوقف العمل. يجب أن تدعم البنية شحن التغييرات بأمان: القدرة على دفع الإصلاحات دون انتظار أيام لمراجعة متجر التطبيقات حيثما أمكن، وطرح التغيير تدريجياً بدلاً من طرحه للجميع دفعةً واحدة، وإطفاء ميزة بسرعة إذا أساءت التصرف. هذه القدرات تُصمَّم في البنية، لا تُضاف بعد أول إصدار سيئ.
وبالمثل، خطط لتغيّر المنصات تحتك. يتغير نظاما iOS و Android كل عام، والتطبيق المؤسسي غير المُصان بنشاط يتوقف عن العمل تدريجياً. الفريق الذي يبني التطبيق يجب أن يكون هو الفريق — أو أن يسلّم بنظافة إلى فريق — الذي يبقيه محدّثاً. التطبيق المؤسسي بلا مالك للصيانة هو التزام يعمل عليه عدّاد تنازلي.
نبني تطبيقات مؤسسية متعددة المنصات بمبدأ "الواجهة البرمجية أولاً": طبقة خلفية جيدة النمذجة (Backend-for-Frontend) تمتص تعقيد أنظمتك القائمة، وكود مشترك مفصول بوضوح مع معالجة بيانات "دون اتصال أولاً"، وصلاحيات مفروضة على الخادم مصممة لأدوار مؤسسية حقيقية، وتجربة "عربية أولاً" ثنائية اللغة مهندسة وفق توقعات PDPPL وإقامة البيانات من اليوم الأول. اختيار إطار العمل يتبع البنية، لا العكس.
تبدأ معظم التعاملات بـ مرحلة اكتشاف تحدد الأنظمة التي يجب أن يتكامل معها التطبيق، والأدوار التي عليه خدمتها، وأين تكمن المخاطرة الحقيقية — وتُنتج خطة مرحلية بجداول زمنية صادقة. إذا كنت تحدد نطاق تطبيق مؤسسي، أو تحاول إنقاذ تطبيق أصبح يصعب تغييره، يسعدنا أن ننظر في البنية معك قبل الالتزام بالبناء. وقد يفيدك دليلنا حول تطوير تطبيقات الجوال المخصصة في الدوحة كمرافق لهذا المقال.