2026-09-03

Architecting Power Platform for Complex Enterprise Solutions with Ian Tweedie [MVP]

Microsoft Power Platform is often described as a low-code platform. But what happens when the applications you build become business-critical, highly integrated, and too complex for a simple maker-first approach?In this episode of M365 FM, Mirko Peters talks with Power Platform Solution Architect Ian Tweedie about what happens when Power Platform moves beyond simple low-code applications and becomes part of a serious enterprise architecture. LOW-CODE DOESN'T MEAN LOW ARCHITECTURE Power Platform can deliver a large percentage of business value quickly, but enterprise solutions almost always contain requirements that go beyond standard low-code capabilities.Ian explains why low-code should never be confused with no-code — and why traditional software architecture principles still matter when building with Power Apps, Power Automate, Dataverse, custom connectors, APIs, and Azure services. W

غالباً ما يُوصف Microsoft Power Platform بأنه منصة لتطوير التطبيقات بعدد قليل من الأكواد (Low-code). لكن ماذا يحدث عندما تصبح التطبيقات التي تبنيها حيوية للأعمال، ومتكاملة بشكل كبير، ومعقدة إلى حد يصعب معه الاكتفاء بنهج بسيط يعتمد على الصانع (Maker-first)؟
في هذه الحلقة من M365 FM، يتحدث Mirko Peters مع Ian Tweedie، مهندس الحلول في Power Platform، عمّا يحدث عندما تتجاوز Power Platform التطبيقات البسيطة قليلة الأكواد وتصبح جزءاً من بنية مؤسسية متكاملة.

منصات قليلة الأكواد لا تعني بنية بسيطة

يمكن لـ Power Platform أن تحقق نسبة كبيرة من قيمة الأعمال بسرعة، لكن الحلول المؤسسية تحتوي في الغالب على متطلبات تتجاوز قدرات الأكواد القليلة القياسية.
يوضح Ian لماذا لا ينبغي الخلط بين الأكواد القليلة والخالية من الأكواد (No-code)، ولماذا تظل مبادئ هندسة البرمجيات التقليدية مهمة عند البناء باستخدام Power Apps وPower Automate وDataverse والموصلات المخصصة وواجهات برمجة التطبيقات (APIs) وخدمات Azure.

عندما تصبح Power Platform برمجيات مؤسسية

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

الهروب من مشكلة "لعبة الخلد" في التطوير

تصلح خطأ في مكان، فيظهر خطأ آخر في مكان آخر.
تُعد هذه المشكلة المألوفة في التطوير علامة غالباً على بنية مترابطة بإحكام (Tightly coupled).
يناقش Ian كيف يمكن للتصميم المعياري (Modular design) أن يعزل الوظائف ويقلل التبعيات غير المقصودة. ومن خلال مثال إرسال البريد الإلكتروني، يوضح كيف أن فصل العمليات التجارية عن آليات التسليم يجعل التطبيقات أسهل في الاختبار والصيانة والاستبدال والتوسع.

الأكواد القليلة + البرمجة التقليدية = بنية هجينة

لا يحتاج Power Platform إلى منافسة تطوير البرمجيات التقليدية.
فقد تمثل واجهة Power Apps جزءاً صغيراً فقط من تطبيق أكبر بكثير يعتمد على Azure أو AWS أو GCP أو واجهات APIs أو خدمات مخصصة.
السؤال المعماري المهم ليس هل الحل "قليل الأكواد" أم "برمجي"، بل أي تقنية هي الأنسب لكل ميزة.

المطوّرون المواطنون والصنّاع والبنية المعمارية

يقدم المطوّرون المواطنون (Citizen developers) قيمة كبيرة للغاية، إذ يمتلكون معرفة عميقة بالعمليات التجارية التي يتعاملون معها يومياً.
لكن الخبرة في الأعمال لا تترجم تلقائياً إلى بنية تطبيقات جيدة.
يناقش Ian التوازن بين تمكين الصنّاع وإدخال قدر كافٍ من البنية المعمارية والحوكمة والتطبيع (Normalization) والمراجعة التقنية لمنع الحلول من أن تصبح صعبة الصيانة.

حوكمة دون قتل الابتكار

الحوكمة القليلة تخلق الفوضى.
والحوكمة المفرطة تخلق الاحتكاك، وقد تدفع الموظفين نحو حلول بديلة غير مدعومة مثل الجداول الإلكترونية وVBA وتقنية الظل (Shadow IT).
يكمن التحدي في إيجاد المستوى المناسب من الحوكمة استناداً إلى المخاطر التنظيمية وأهمية التطبيق والمستخدمين والأثر على الأعمال.

Power Platform وواجهات APIs وAzure

أين ينبغي أن تعيش منطق الأعمال؟
هل يجب تخزين الأسرار (Secrets) داخل Power Platform؟ ومتى ينبغي أن تصبح Azure Key Vault وAzure Functions وAPI Management جزءاً من البنية؟
يوضح Ian لماذا ينبغي أن تبدأ البنية دائماً بالمشكلة المراد حلها، لا بإضافة خدمات Azure لمجرد توفرها.

Git والتحكم في المصدر وCI/CD

مع تزايد طابع التعاون في تطوير Power Platform، تزداد أهمية ممارسات التطوير التقليدية.
تستكشف المحادثة Git والمستودعات وبيئات التطوير والخطوط (Pipelines) والتحكم في المصدر وعزل الميزات والتبعيات المتقاطعة وCI/CD.
قد لا يوجد دائماً نهج مثالي للتحكم في المصدر في Power Platform، وأحياناً يكون الهدف هو اختيار "الخيار الأقل سوءاً" للمشروع.

دليل Ian لبنية Power Platform

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

الجولة السريعة

يطرح Mirko على Ian سلسلة من الأسئلة السريعة:
هل ينبغي لكل تطبيق مؤسسي أن يستخدم Dataverse؟
هل يمكن لـ Power Platform بناء تطبيقات حيوية للمهام؟
هل يمكن لـ Power Automate أن يحل محل Logic Apps؟
هل تقلل الأكواد القليلة الدين التقني تلقائياً؟
هل يمكن لـ Power Platform أن يحل محل تطوير التطبيقات التقليدي؟
وربما الأهم: ماذا ينبغي أن تطلب عند زيارة Newcastle؟

الخلاصة الأساسية

الأكواد القليلة لا تعني بنية بسيطة.
فكلما أصبحت حلول Power Platform أكبر وأكثر ترابطاً وأهمية للأعمال، تظل أساسيات هندسة البرمجيات ذات صلة.
البنية مهمة. ونمذجة البيانات مهمة. والحوكمة مهمة. والأمن مهم. وتصميم واجهات APIs مهم. وDevOps مهم.
وينصب التطوير الناجح لـ Power Platform بشكل متزايد على فهم كيفية عمل الأكواد القليلة والبرمجة التقليدية وAzure وواجهات APIs والأتمتة وممارسات هندسة البرمجيات التقليدية معاً.

كن داعماً لهذا البودكاست: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.

Apple Podcasts · Spotify · YouTube · Deezer

Architecting Power Platform for Complex Enterprise Solutions with Ian Tweedie [MVP] (English)