تعتمد العديد من المؤسسات على تطبيقات لا تزال تؤدي وظيفتها الأساسية. يقوم النظام بمعالجة الطلبات، وإدارة العملاء، وتسجيل الفواتير، أو إدارة المخزون. من الناحية التقنية البحتة، يمكن القول إنه يعمل. مع ذلك، يستغرق كل تعديل شهورًا، وأي عملية دمج تُثير حالة من عدم اليقين، كما أن إطلاق تجربة رقمية جديدة يتطلب تعديل مكونات متعددة لا يرغب أحد في المساس بها.
ثم تبدأ الشركة بالعمل على إيجاد حلول بديلة لتقنيتها الخاصة. تقوم الفرق بتصدير البيانات إلى جداول بيانات، وإنشاء تطبيقات موازية، والاعتماد على عمليات يدوية لربط أنظمة لم تُصمم أصلًا للتعاون. يبقى البرنامج قيد التشغيل، لكنه يتحول تدريجيًا إلى عائق أمام العمل.
يُبرز ظهور الذكاء الاصطناعي هذه الصعوبة بشكلٍ أكبر. يحتاج النظام إلى الاستعلام عن البيانات، واستخدام الخدمات، وتنفيذ الإجراءات، والتواصل مع تطبيقات مختلفة. عندما تكون جميع منطق الأعمال محصورة داخل منصات متجانسة، أو عمليات تكامل مباشرة، أو أنظمة تفتقر إلى واجهات واضحة، فإن تطبيق الذكاء الاصطناعي يتطلب بناء طبقة جديدة من الحلول المؤقتة.
يقترح التصميم المعماري القابل للتحلل بديلاً: تحويل القدرات التجارية إلى وحدات نمطية يمكن دمجها وإعادة استخدامها وتطويرها دون استبدال النظام البيئي بأكمله في كل مرة تتغير فيها الحاجة.
تُعدّ البنية التركيبية منهجًا يُنظّم التطبيقات والقدرات التجارية كمكونات معيارية قابلة للتشغيل البيني والاستبدال. يؤدي كل جزء وظيفة محددة بوضوح ويتواصل مع الأجزاء الأخرى من خلال العقود أو واجهات برمجة التطبيقات أو الأحداث.
تصف غارتنر التطبيقات القابلة للتكوين بأنها مزيج من التطبيقات وواجهات برمجة التطبيقات والخدمات المصممة لتوفير مرونة وتكامل ونمطية أكبر. والهدف هو تمكين المؤسسات من تجميع القدرات وفقًا لاحتياجات العمل، بدلاً من الاعتماد حصريًا على منصات جامدة ومغلقة.
يمكن تشبيه هذه الفكرة بالبناء باستخدام المكعبات. قد تمتلك المؤسسة مكونات خاصة بالعملاء، والمدفوعات، والفواتير، والمخزون، والتحقق من الهوية، والإشعارات، والتحليلات. يستخدم منتج رقمي جديد بعضًا من هذه المكونات دون تكرارها أو إعادة بنائها.
عندما تحتاج إحدى القدرات إلى التطوير، يمكن تعديلها أو استبدالها بتأثير أكثر تحكمًا على بقية النظام. لم يعد تصميم النظام مقتصرًا على التطبيقات الكاملة، بل أصبح يتمحور حول قدرات الأعمال القابلة لإعادة الاستخدام.
من أكثر الأخطاء شيوعاً افتراض أن البنية القابلة للتكوين تعني بالضرورة تقسيم النظام إلى عشرات أو مئات من الخدمات المصغرة. مع أن الخدمات المصغرة قد تكون جزءاً من هذا النهج، إلا أنها ليست الهدف بحد ذاتها.
يُعرّف مارتن فاولر الخدمات المصغّرة بأنها خدمات صغيرة، مُنظّمة حول القدرات التجارية وقابلة للنشر بشكل مستقل. يُمكن لهذا النموذج تحسين الاستقلالية والسماح بإجراء تغييرات معزولة، ولكنه يُضيف أيضًا تكاليف مُرتبطة بالاتصال الموزّع، والمراقبة، والاختبار، والبنية التحتية، والتنسيق.
قد تمتلك المؤسسة العديد من الخدمات المصغرة ومع ذلك يصعب تغييرها. يحدث هذا عندما تكون الحدود غير واضحة، أو عندما تعتمد الخدمات بشكل مفرط على بعضها البعض، أو عندما يستخدم كل فريق تقنيات غير متوافقة دون وجود معايير مشتركة.
من الممكن أيضاً بناء بنية قابلة للتكوين باستخدام نظام متكامل معياري، وخدمات مُدارة، وواجهات برمجة تطبيقات مُصممة جيداً، وأحداث. ويعتمد القرار على مدى تعقيد العمل، وحجم الفرق، والحاجة الفعلية للاستقلالية.
لا تُقاس قابلية التركيب بكمية الخدمات، بل تُقاس بسهولة دمج الشركة لقدراتها وتغييرها وإعادة استخدامها دون التسبب في سلسلة من التفاعلات.
في كثير من النقاشات حول التحديث، يُصوَّر المبنى الضخم على أنه نمط معماري عفا عليه الزمن ويجب استبداله فوراً. قد تؤدي هذه النظرة إلى تحولات مكلفة وغير ضرورية.
قد يكون النظام المتكامل ذو البنية الجيدة مناسبًا للتطبيقات ذات النطاق المحدد، والفرق القليلة، واحتياجات النشر البسيطة نسبيًا. وقد أشار مارتن فاولر إلى أن معظم الأنظمة يمكن أن تبدأ كتطبيقات متكاملة، شريطة أن تحافظ على حدود معيارية واضحة، وأنه ينبغي النظر في استخدام الخدمات المصغرة عندما يتجاوز التعقيد ما يمكن إدارته بشكل معقول ضمن هذا النموذج.
لا تكمن المشكلة في نشر التطبيق بأكمله كوحدة واحدة، بل في تداخل المنطق، وافتقار الوحدات إلى حدود واضحة، وتأثير أي تعديل على مناطق تبدو مستقلة.
يمكن أن يكون النظام المتجانس المعياري قابلاً للتكوين داخليًا. يتم فصل القدرات من خلال العقود والملكية وقواعد التبعية، على الرغم من استمرارها في العمل ضمن نفس عملية النشر.
تتجنب البنية المعمارية الناضجة القرارات الأيديولوجية. فهي لا تختار الخدمات المصغرة لمجرد أنها تبدو حديثة، ولا تحافظ على بنية متجانسة لمجرد التسهيل. بل تُقيّم أي بنية تسمح بالتطور بأقل قدر من المخاطر والتعقيد.
تتيح واجهة برمجة التطبيقات (API) استخدام وظيفة معينة من قِبل تطبيقات مختلفة دون الكشف المباشر عن تفاصيل تنفيذها الداخلية. على سبيل المثال، قد يوفر نظام الفوترة عمليات لإنشاء الفواتير، والتحقق من الحالة، أو إلغاء المستندات. ويمكن لتطبيقات الويب، وتطبيقات الجوال، وبوابات العملاء، وأنظمة الذكاء الاصطناعي استخدام هذه العمليات من خلال واجهات موحدة.
تعتمد منهجية "واجهة برمجة التطبيقات أولاً" على تصميم العقد قبل بناء التنفيذ. يحدد الفريق ما يمكن أن تفعله هذه الخاصية، وما هي البيانات التي تتلقاها، وما هي النتائج التي تقدمها، وكيفية معالجتها للأخطاء، وكيف ستتطور دون التأثير على مستخدميها.
تشير مايكروسوفت إلى أن منصات إدارة واجهات برمجة التطبيقات تسمح لك بنشر الخدمات بشكل آمن، وفرض السياسات، والتحكم في الوصول، وإدارة دورة حياتها في بيئات السحابة الهجينة والمتعددة.
بدون استراتيجية لواجهات برمجة التطبيقات (API)، غالباً ما تتصل عمليات التكامل مباشرةً بقواعد البيانات أو تعتمد على سلوكيات داخلية غير موثقة. كل تغيير قد يُعطّل التطبيقات الخارجية، وتتراكم لدى الشركة تبعيات غير مرئية.
تُحوّل واجهة برمجة التطبيقات المصممة جيدًا وظيفةً داخليةً إلى قدرة تجارية قابلة لإعادة الاستخدام. مع ذلك، لا يكفي مجرد نشر نقاط النهاية. تحتاج المؤسسة إلى عقود واضحة، وأمان، وإصدارات، وتوثيق، وإمكانية مراقبة، وتحديد ملكية.
يمكن للشركة استبدال الاتصالات المباشرة بواجهات برمجة التطبيقات (APIs) ومع ذلك ستواجه المشكلة الهيكلية نفسها. فإذا كان كل تطبيق يستدعي العديد من التطبيقات الأخرى مباشرةً، فإن شبكة التبعيات ستنمو بسرعة. وقد يؤثر أي تغيير في نظام واحد على العديد من المستخدمين، مما يجعل تصور بنية النظام أمرًا صعبًا.
تساعد إدارة واجهات برمجة التطبيقات (API) على مركزة السياسات، والمصادقة، وحدود الاستهلاك، والمراقبة، والنشر. ويمكن لبوابة واجهة برمجة التطبيقات أن تعمل كنقطة تحكم للطلبات، وتفرض القواعد، وتجمع بيانات القياس عن بُعد دون الحاجة إلى أن تُنفذ كل خدمة جميع الآليات بشكل منفصل.
مع ذلك، لا ينبغي أن تتحول البوابة إلى نظام يُركّز جميع منطق الأعمال. فوظيفتها الأساسية هي إدارة حركة البيانات والسياسات والتعرض. وعندما تبدأ بتحويل العمليات المعقدة وتنسيق كل تفاعل بشكل مفرط، فإنها تُنشئ اختناقًا جديدًا.
يتطلب التصميم المعماري القابل للتركيب توازناً. تُسهّل واجهات برمجة التطبيقات التفاعلات المباشرة عندما يحتاج المستخدم إلى استجابة فورية. أما بالنسبة للعمليات التي تتطلب تفاعل أنظمة متعددة بشكل مستقل، فقد يكون التصميم المعماري القائم على الأحداث أكثر ملاءمة.
في التكامل المتزامن، يطلب أحد التطبيقات إجراءً من تطبيق آخر وينتظر الرد. يُعد هذا النمط مفيدًا عندما تكون النتيجة مطلوبة فورًا، ولكنه يُنشئ تبعية زمنية. فإذا كانت الخدمة المُستقبِلة غير متاحة أو بطيئة الاستجابة، فقد تتأثر العملية بأكملها.
في بنية تعتمد على الأحداث، يُعلن النظام عن وقوع حدث ما: إنشاء طلب، إصدار فاتورة، تحديث بيانات العميل، أو تأكيد عملية دفع. ويمكن للمكونات الأخرى الاستماع إلى هذا الحدث والتفاعل معه دون علم المُنتِج بجميع مُستهلِكه.
تُعرّف AWS بنية البرمجيات الموجهة بالأحداث بأنها نموذج يتألف من خدمات منفصلة تقوم بنشر الأحداث أو استهلاكها أو توجيهها. يتيح هذا النهج للمكونات المختلفة التفاعل مع تغييرات الحالة دون الحاجة إلى تكاملات صارمة بين كل منتج ومستهلك.
على سبيل المثال، عند تأكيد عملية الشراء، يمكن للمخزون حجز الوحدات، ويمكن لقسم الفواتير إصدار الفاتورة، ويمكن لقسم التسويق تحديث ملف تعريف العميل، ويمكن لقسم الخدمات اللوجستية تجهيز الشحنة. لا يحتاج نظام المبيعات إلى التنسيق المباشر بين كل نشاط.
يؤدي هذا الفصل إلى تحسين المرونة، ولكنه يتطلب أيضًا إدارة النسخ المكررة والترتيب والأخطاء وإمكانية التتبع والاتساق النهائي.
إن تقسيم بنية النظام إلى طبقات تقنية فقط قد ينتج عنه مكونات لا تعكس العمليات الفعلية للشركة. فخدمة قاعدة البيانات، وخدمة التحقق، وخدمة المرافق، لا تُشكل بالضرورة قدرات أعمال مستقلة.
عادةً ما تتوافق الحدود الأكثر استدامة مع مجالات مثل الطلبات، والعملاء، والمدفوعات، والمخزون، والعقود، أو الدعم. ويركز كل مكون على القواعد والبيانات المتعلقة بالمساءلة المتسقة.
يقلل هذا النهج من كمية المعلومات المتبادلة بين الفرق. يمكن لفريق المدفوعات تطوير عملياته دون الحاجة إلى فهم جميع تفاصيل المخزون، طالما أنه يلتزم بالعقود المبرمة.
تكمن الصعوبة في تحديد تلك الحدود بدقة. فالنطاق الواسع جدًا يُنشئ نظامًا داخليًا متجانسًا، بينما يُنشئ النطاق الضيق جدًا خدمات متعددة يجب أن تتعاون لإنجاز أي عملية.
يتطلب تصميم البنية القابلة للتركيب فهمًا للأعمال قبل تقسيم التكنولوجيا. يجب أن تعكس المخططات التقنية مسؤوليات العمل، وليس مجرد الأدوات أو قواعد البيانات.
عندما تكون للقدرات حدود واضحة، يمكن أن تصبح لبنات بناء قابلة لإعادة الاستخدام. أما عندما تكون الحدود اعتباطية، فإن النمطية لا توجد إلا في البنية التحتية.
قد يؤدي وعد إعادة الاستخدام إلى مكونات عامة للغاية. يحاول فريق ما بناء "خدمة عملاء شاملة" قادرة على تلبية جميع الاحتياجات الحالية والمستقبلية. والنتيجة غالبًا ما تكون حلًا معقدًا، بطيئًا في التطور، ومثقلًا بقواعد متناقضة.
تتحقق إعادة الاستخدام الفعّالة عندما تكون هناك سعة مستقرة ومحددة بوضوح يحتاجها العديد من المستخدمين. وغالبًا ما توفر عمليات المصادقة والإشعارات والمدفوعات والهوية وبعض البيانات الأساسية فرصًا جيدة لذلك.
يجب أن تظل الوظائف الأخرى قريبة من منتج أو مجال محدد. قد لا تكون قاعدة عمل معينة منطقية خارج التطبيق الذي يستخدمها.
لا يهدف مفهوم قابلية التركيب إلى إجبار كل شيء على أن يكون قابلاً لإعادة الاستخدام، بل يتعلق الأمر بفصل ما يمكن مشاركته عما يحتاج إلى التطور بشكل مستقل.
ينبغي أن يكون لكل مكون مسؤولية واضحة، ومستخدمون نهائيون محددون، وتكلفة صيانة مبررة بقيمته. إن إنشاء منصة داخلية للاستخدام لمرة واحدة قد يزيد التعقيد بدلاً من تبسيطه.
تتجنب البنية المعمارية الناضجة طرفين متطرفين: تكرار كل شيء أو محاولة مركزة كل شيء.
يستطيع وكيل الأعمال تفسير الطلب، والاستعلام عن المعلومات، واختيار الأدوات اللازمة لإنجاز الهدف. ومع ذلك، فإن قدراته تعتمد على الواجهات المتاحة.
عندما تُتيح الأنظمة واجهات برمجة التطبيقات (APIs) والأحداث والخدمات الموثقة بصلاحيات واضحة، يستطيع المستخدم استخدام وظائف محددة دون الحاجة إلى الوصول المباشر إلى البنية التحتية بأكملها. يمكنه التحقق من حالة طلب، أو إنشاء فرصة، أو إعداد فاتورة، أو جدولة نشاط باستخدام عقود مُدارة.
أشارت شركة غارتنر إلى أن بنى التطبيقات والبيانات القديمة تعيق إنشاء حلول ذكية، وأن الجمع بين البنية القابلة للتكوين والبيانات الجاهزة للذكاء الاصطناعي يسمح بربط الوكلاء بقدرات الأعمال بشكل أكثر فعالية.
أما البديل فهو بناء تكاملات فريدة لكل وكيل. قد تنجح هذه الاستراتيجية أثناء الاختبار، لكنها سرعان ما تُنشئ طبقة جديدة من التبعيات، وبيانات اعتماد مكررة، ومنطقًا جديدًا.
لا تقوم الشركة الجاهزة للعمل مع الوكلاء بتطوير أداة مختلفة لكل حالة. بل توفر إمكانيات قابلة لإعادة الاستخدام وخاضعة للرقابة يمكن استخدامها من قبل التطبيقات البشرية والأنظمة الذكية على حد سواء.
وبذلك يصبح الذكاء الاصطناعي مستهلكًا جديدًا لهندسة المؤسسات، وليس حلاً منفصلاً ومتوازيًا.
إن منح الموظف صلاحيات واسعة للوصول إلى نظام إدارة علاقات العملاء (CRM) أو نظام تخطيط موارد المؤسسات (ERP) أو قاعدة البيانات قد يُسرّع عملية تصميم النماذج الأولية، ولكنه يُعرّض النظام لمخاطر أمنية ومخاطر تتعلق بالتتبع والتحكم. فقد يتمكن الموظف من الوصول إلى معلومات غير ضرورية أو القيام بإجراءات خارج نطاق صلاحياته.
تتيح البنية القابلة للتكوين إمكانية عرض عمليات محددة. يمكن لموظف خدمة العملاء الاطلاع على الطلبات وإنشاء الحالات، لكنه لا يحتاج إلى تعديل الإعدادات المالية أو تنزيل قواعد البيانات بأكملها.
يمكن لواجهات برمجة التطبيقات والبوابات فرض المصادقة والتفويض والحدود والسياسات والتسجيل. كل أداة يستخدمها الوكيل لها عقد معروف وواجهة تحكم.
كما يُسهّل هذا الهيكل تغيير النظام الأساسي. ويستمر الوكيل في استخدام نفس الإمكانيات حتى لو استبدلت الشركة نظام إدارة علاقات العملاء أو نقلت جزءًا من بنيتها التحتية، طالما بقي العقد ساريًا.
لا تُحسّن البنية المعيارية المرونة فحسب، بل تُنشئ أيضًا حدودًا للأمان. فبدلاً من الاعتماد على النظام لتجنب الإجراءات الخاطئة، تُقيّد البنية تقنيًا ما يمكنه فعله.
قد يكون استبدال النظام الأساسي في مشروع واحد مكلفًا للغاية ومحفوفًا بالمخاطر. تحتاج الشركة إلى الحفاظ على سير العمليات مع تحويل التطبيقات والبيانات وعمليات التكامل التي تطورت على مر السنين.
قد تبدأ الاستراتيجية التدريجية بعرض وظائف النظام القديم عبر واجهات برمجة التطبيقات، وتسجيل الأحداث، وبناء قدرات جديدة حول محيطه. ثم يتم استبدال بعض الوحدات تدريجياً عندما يكون هناك سبب تجاري واضح.
النمط المعروف باسم تين الخانق يقترح مارتن فاولر استبدال أجزاء من التطبيق تدريجيًا، بتوجيه وظائف معينة إلى مكونات جديدة مع استمرار النظام الأصلي في العمل. كما يوصي بتقسيم الأنظمة وفقًا للقدرات التي يمكن أن توفر قيمة مستقلة، لتجنب عمليات النقل الضخمة دون نتائج وسيطة.
على سبيل المثال، يمكن للشركة الاحتفاظ بنظام تخطيط موارد المؤسسات (ERP) الأساسي الخاص بها، ولكن مع إنشاء بوابة عملاء جديدة ونظام طلبات متصل عبر واجهات برمجة التطبيقات (APIs). لاحقًا، يمكنها تحديث نظام إدارة المخزون أو الفواتير دون إيقاف البرنامج بالكامل.
تُحوّل الهندسة المعمارية القابلة للتحلل عملية التحديث إلى سلسلة من القرارات المتحكم بها، وليس إلى مقامرة واحدة.
عندما تمتلك الشركة تطبيقات متعددة، فإنها غالباً ما تُنشئ طبقة مركزية لربطها. يمكن لهذه الاستراتيجية تحسين الرؤية وتقليل عمليات التكامل المباشر. مع ذلك، قد تُؤدي أيضاً إلى تركيز الكثير من المنطق في مكان واحد.
إذا كانت كل عملية تحويل وقاعدة وإجراء موجودة ضمن منصة التكامل، فإن أي تغيير يعتمد على الفريق نفسه. وبذلك، تستبدل المؤسسة العديد من الروابط الصغيرة بعائق مركزي كبير.
ينبغي أن تسهل طبقة التكامل التواصل والتحول التقني والأمن والتنسيق، ولكن يجب أن تظل قواعد العمل الأساسية قريبة من المجال المسؤول.
تقدم مايكروسوفت بنى مؤسسية حيث تعمل إدارة واجهات برمجة التطبيقات والمراسلة والأتمتة معًا لربط التطبيقات، ولكن يجب اختيار هذه القدرات وفقًا لنمط التكامل ومتطلبات العملية.
لا توجد أداة واحدة مناسبة لكل تفاعل. تتطلب بعض الاحتياجات واجهات برمجة تطبيقات متزامنة، بينما تتطلب أخرى أحداثًا أو قوائم انتظار أو تنسيقًا أو مشاركة ملفات.
تعتمد البنية التركيبية على عدة أنماط بشكل متسق، ولا تحاول حل جميع المشاكل بنفس الآلية.
يجب أن تتوافق العديد من العمليات مع الضوابط الداخلية واللوائح والسياسات. قد تتطلب عملية الشراء موافقة بناءً على قيمتها. وقد تحتاج الحالات الحساسة إلى مراجعة خاصة. ولا ينبغي إتمام عملية الدفع دون التحقق من بعض المعلومات.
تتيح لك عملية تحليل العمليات مقارنة الأداء الفعلي بالنموذج المتوقع. ويمكن للمؤسسة تحديد الحالات التي تم فيها إغفال نشاط مطلوب، أو اتباع تسلسل غير صحيح، أو تجاوز الحد الزمني.
تُحدث هذه القدرة تحولاً جذرياً في الامتثال. فبدلاً من مراجعة عينات صغيرة بعد وقوع الأحداث، يمكن للشركة مراقبة الانحرافات بشكل مستمر وتحديد أولويات تلك التي تنطوي على أعلى المخاطر.
لا تشير جميع الانحرافات إلى الاحتيال أو عدم الامتثال. قد يكشف بعضها أن السياسة معقدة للغاية أو أن النظام يجبر المستخدمين على العمل خارج نطاق سير العمل الرسمي.
تُمكّننا الأدلة من التمييز بين السلوك الاستثنائي المشروع ونقاط الضعف في الرقابة. كما تُسهّل تصميم أنظمة الأتمتة التي تتضمن عمليات التحقق منذ البداية.
لم يعد الامتثال مجرد عملية تدقيق لاحقة، بل أصبح سمة قابلة للملاحظة في العملية.
عندما يُتاح لكل فريق حرية اختيار اللغات والموردين والبروتوكولات والأنماط، قد ينتهي الأمر بالمنظمة إلى بيئة عمل شديدة التنوع لدرجة تعيق عملها بفعالية. فالاستقلالية المطلقة تُؤدي إلى الازدواجية وزيادة التكاليف وصعوبات الدعم.
تحدد الحوكمة القابلة للتكوين الحد الأدنى من المعايير. فهي تحدد كيفية تصميم واجهات برمجة التطبيقات، وكيفية إصدار العقود، وآليات الهوية المستخدمة، وكيفية نشر الأحداث، وما يجب أن تتضمنه مراقبة المعلومات.
لا تستلزم هذه المعايير إلغاء جميع القرارات المحلية. يمكن للفرق الحفاظ على استقلاليتها ضمن مسارات التكنولوجيا المعتمدة. ويمكن للمنصة الداخلية أن توفر قوالب، وخطوط أنابيب، ومكونات أمنية، وخدمات قابلة لإعادة الاستخدام.
تُسهّل الحوكمة الفعّالة الخيار المُوصى به. فإذا تطلّب الامتثال للقواعد أسابيع من الأعمال الورقية، ستقوم الفرق بإنشاء عمليات تكامل موازية للمضي قدمًا.
تحتاج الوحدات النمطية إلى حرية التطور، ولكنها تحتاج أيضاً إلى اتفاقيات تسمح للمكونات بالتعاون. فبدون عقود مشتركة، تصبح قابلية التركيب مجرد مجموعة من الأجزاء غير المتناسقة.
يمكن بناء المكون بأي لغة أو منصة، لكن مستخدميه يعتمدون بشكل أساسي على عقده: العمليات المتاحة، والبيانات، والأخطاء، والتوافر، والسلوك.
عندما تُجري الفرق تغييرات على هذه العقود دون إدارة التوافق، يختفي الاستقلال المفترض. يتطلب كل تحديث تنسيقًا بين عدة مستخدمين، وتصبح عمليات النشر مترابطة مرة أخرى.
تحتاج واجهات برمجة التطبيقات إلى استراتيجيات للتحكم في الإصدارات. تتطلب الأحداث مخططات وقواعد تطوير. تحتاج البيانات المشتركة إلى تعريفات واضحة. تحتاج الفرق إلى معرفة التغييرات التي يمكنها إجراؤها دون التأثير على الآخرين.
تُدرج مايكروسوفت مسألة التحكم في الإصدارات والعلاقة بين واجهات برمجة التطبيقات والمجالات ضمن القرارات الأساسية لتصميم الخدمات المصغرة.
لا يعني العقد المستقر أنه لا يمكن تغييره أبداً، بل يعني أن التغييرات تُدار من خلال التوافق، والإصدارات الجديدة، وفترات الانتقال، والتواصل.
لا تعتمد البنية التركيبية على فصل التعليمات البرمجية فحسب، بل تعتمد على إنشاء اتفاقيات تقنية وتنظيمية قوية بما يكفي بحيث يمكن لكل جزء أن يتطور دون أن يفاجئ الأجزاء الأخرى.
في النظام المتجانس، يمكن تنفيذ عملية ما ضمن عملية واحدة. أما في البنية الموزعة، فيمكن للطلب أن يمر عبر واجهات برمجة التطبيقات، وقوائم الانتظار، والأحداث، والوظائف، والخدمات.
إذا قام كل مكون بتسجيل المعلومات بشكل منفصل، يصبح التحقيق في المشكلة معقدًا. يعلم الفريق أن جميع الخدمات متاحة، لكن العميل لا يزال لا يحصل على النتيجة المتوقعة.
تتطلب البنية القابلة للتركيب إمكانية التتبع من البداية إلى النهاية. تسمح معرّفات الارتباط والمقاييس والسجلات والتتبعات الموزعة بإعادة بناء مسار العملية.
تُعدّ هذه الشفافية ضرورية أيضاً لوكلاء الذكاء الاصطناعي. إذ تحتاج الشركة إلى معرفة الأدوات التي استخدمها الوكيل، والخدمات التي استجابت، ومكان حدوث القرار الخاطئ.
تُحوّل النمطية بعض التعقيد من الكود إلى التفاعل بين المكونات. وتُعدّ إمكانية المراقبة الآلية التي تسمح بإدارة هذا التعقيد.
لا يمكن اعتبار أي بنية قابلة للتركيب حقًا إذا لم يستطع أحد فهم كيفية عمل أجزائها معًا.
في البنية الموزعة، يؤدي كل واجهة برمجة تطبيقات أو حدث أو خدمة جديدة إلى توسيع نطاق التفاعل. وتؤدي إدارة الأمان بشكل مستقل لكل مكون إلى سياسات غير متسقة وتزيد من احتمالية حدوث الأخطاء.
تحتاج المنظمة إلى قدرات مشتركة للهوية، والمصادقة، والتفويض، وإدارة الأسرار، والتشفير، والتدقيق، وحماية واجهة برمجة التطبيقات (API).
تشير شركة غارتنر إلى أن البيئات غير المتجانسة تتطلب بنى تحكم وصول معيارية وممارسات محددة لهويات الآلات التي تستهلك واجهات برمجة التطبيقات.
يُعدّ هذا الأمر بالغ الأهمية بالنسبة للوكلاء والأنظمة الآلية. ينبغي أن يتمتع كل وكيل بهوية مميزة وصلاحيات تتناسب مع دوره. يجب أن تتحقق إمكانيات البنية من هوية مُقدّم الطلب، والعملية التي يحاول تنفيذها، والسياق الذي يعمل ضمنه.
لا ينبغي إضافة إجراءات الأمان بعد نشر المكونات، بل يجب أن تكون جزءًا من عقودك والمنصة التي تعرضها.
تتيح إمكانية التركيب الآمن إعادة استخدام الوظائف دون إعادة استخدام صلاحيات مفرطة.
لا تحتاج جميع المؤسسات إلى تحول جذري. ومع ذلك، هناك دلائل واضحة على جمود هيكلي.
ينبغي على الشركة مراجعة تصميمها عندما يتطلب إطلاق قناة جديدة تكرار المنطق، أو عندما يتطلب كل تكامل تعديل أنظمة متعددة، أو عندما يحتاج تحديث بسيط إلى تنسيق فرق عديدة. كما ينبغي عليها مراجعة تصميمها عندما لا يمكن الحصول على البيانات إلا من خلال الاستعلامات المباشرة، أو عندما تعتمد التطبيقات على عمليات يدوية، أو عندما لا تستطيع المؤسسة استبدال أداة ما دون التأثير على سير العمل بالكامل.
تظهر علامة تحذيرية أخرى عندما تحتاج كل مبادرة من مبادرات الذكاء الاصطناعي إلى بناء موصلاتها الخاصة للوصول إلى نفس إمكانيات المؤسسة. وهذا يدل على أن الشركة لديها تطبيقات، ولكن ليس لديها طبقة خدمة قابلة لإعادة الاستخدام.
لا ينبغي أن يكون الحل هو تجزئة النظام البيئي بأكمله على الفور. أولاً، يجب تحديد القدرات والتبعيات والأهداف الاستراتيجية.
يجب أن تحل البنية القابلة للتكوين مشاكل محددة: تسريع الإصدارات، وتسهيل عمليات التكامل، وتحديث النظام، وتمكين الوكلاء، أو تقليل تأثير التغييرات.
تُحقق الوحدات النمطية قيمة عندما تستجيب لحاجة حقيقية للتطور.
تتمثل الخطوة الأولى في إنشاء خريطة للنظام البيئي الحالي. يجب على الشركة تحديد التطبيقات والبيانات وعمليات التكامل والجهات المالكة والعمليات الحيوية. يكشف هذا التحليل عن التبعيات والمكونات الخفية التي تشكل أكبر المخاطر.
بعد ذلك، اختر إحدى وظائف العمل التي تتطلب تغييرًا كبيرًا. قد يشمل ذلك العملاء، أو الطلبات، أو المدفوعات، أو المصادقة، أو الإشعارات. يحدد الفريق نطاق عمله، ومستخدميه، وعقده.
يمكن البدء بالتحديث من خلال إتاحة واجهة برمجة التطبيقات (API)، أو نشر الأحداث، أو إنشاء وحدة نمطية منفصلة. لا حاجة لإعادة بناء النظام بأكمله. يجب أن تُظهر كل ميزة جديدة أنها تُقلل الوقت والمخاطر والتكرار.
يجب أيضاً وضع معايير للأمان، والمراقبة، والتوثيق، والتحكم في الإصدارات. فبدون هذه الأسس، ستتطور كل وحدة بطريقة غير متوافقة.
بإمكان الشركة مواصلة استخلاص القدرات وفقًا للأولوية. سيبقى بعضها ضمن النظام الحالي، وسيتم تحويل البعض الآخر إلى خدمات مستقلة، وقد يتم الحصول على بعضها من خلال منصات خارجية.
الهندسة المعمارية القابلة للتحلل ليست مشروعاً له تاريخ نهائي. إنها القدرة على التطور باستمرار دون فقدان السيطرة.
على مجموعة السحابة نحن نساعد المؤسسات على تحديث بنيتها، ودمج الأنظمة، وتحويل قدرات الأعمال إلى خدمات قابلة لإعادة الاستخدام جاهزة للتطبيقات والأتمتة ووكلاء الذكاء الاصطناعي.
يبدأ نهجنا بفهم العمليات والأنظمة والبيانات والترابطات القائمة. لا نوصي بالخدمات المصغرة أو واجهات برمجة التطبيقات أو المنصات السحابية كحلول جاهزة تناسب الجميع. نختار الأنماط المناسبة بناءً على مستوى التعقيد وأهداف الفريق والعمل.
نصمم بنى تحتية تعتمد على واجهات برمجة التطبيقات (API)، وعمليات التكامل، والفعاليات، والمنصات الداخلية، والبرمجيات المخصصة، واستراتيجيات التحديث التدريجي. كما ندمج الأمن، والمراقبة، والحوكمة، والتحكم في التكاليف منذ مرحلة التصميم.
لا يقتصر الهدف على استبدال التكنولوجيا القديمة فحسب، بل يهدف إلى بناء أساس يسمح بإطلاق تجارب جديدة، وربط الأدوات، وتكييف العمليات دون البدء من الصفر لكل مبادرة.
لأن العمارة الحديثة ليست بالضرورة تلك التي تستخدم أكبر قدر من التكنولوجيا.
وهذا ما يسمح للشركة بتغيير مسارها دون أن تصبح جميع برامجها عائقاً.
هو نهج ينظم تطبيقات الأعمال وقدراتها كمكونات معيارية قابلة للتشغيل البيني والاستبدال. ويمكن دمج هذه اللبنات الأساسية لإنشاء منتجات وعمليات دون الحاجة إلى إعادة بناء النظام البيئي بأكمله.
لا. يمكن أن تكون الخدمات المصغرة جزءًا من بنية قابلة للتكوين، لكنها ليست إلزامية. يمكن أيضًا استخدام بنية متجانسة معيارية، وواجهات برمجة التطبيقات، والأحداث، والخدمات المُدارة.
هذا يعني أولاً تصميم العقد الذي ستستهلك من خلاله الأنظمة الأخرى السعة. ثم يتم بناء التنفيذ، مع مراعاة العمليات والبيانات والأخطاء وقواعد التطوير المحددة مسبقاً.
هو نموذج تقوم فيه الأنظمة بنشر الأحداث عند حدوث تغيير، وتتفاعل المكونات الأخرى بطريقة منفصلة. على سبيل المثال، يمكن لحدث تأكيد الدفع أن يؤدي إلى إصدار الفواتير، وإدارة المخزون، وإرسال الإشعارات.
نعم. يسمح ذلك بالتحديث التدريجي من خلال واجهات برمجة التطبيقات والأحداث والاستخراج التدريجي للقدرات، مما يجنب استبدال النظام الأساسي بأكمله في مشروع واحد.
لا. قد تُضيف الخدمات المصغّرة تعقيدًا غير ضروري للأنظمة الصغيرة أو الفرق الصغيرة. قد يكون النظام المتكامل المعياري خيارًا أكثر كفاءة عندما يوفر حدودًا واضحة وسهولة في الصيانة.
يُتيح ذلك الوصول إلى إمكانيات الأعمال من خلال أدوات وعقود مُحكمة. ويمكن للوكلاء الاستعلام عن البيانات أو تنفيذ إجراءات مُحددة دون الوصول المباشر إلى الأنظمة بأكملها.
قد يؤدي ذلك إلى زيادة التعقيد التشغيلي، والاعتماد على الشبكة، والأعطال الجزئية، وصعوبة المراقبة. ولذلك، فهو يحتاج إلى الأتمتة، وإمكانية التتبع، والأمان، والمعايير، وتحديد واضح للمسؤولية.
باستخدام مؤشرات مثل الوقت اللازم لإطلاق الميزات، وسهولة التكامل، وتكرار النشر، وتقليل الازدواجية، وتأثير التغييرات، والقدرة على استبدال المكونات.
لسنوات، قامت العديد من الشركات بتطوير تطبيقات لتلبية احتياجات محددة. كان لكل نظام غرضه، ولكنه خلق أيضاً تبعيات جديدة. وبمرور الوقت، بدأ النظام البيئي يقاوم أي تعديل.
يقترح التصميم المعماري القابل للتطوير طريقة مختلفة للتطور. فبدلاً من إعادة بناء جميع البرامج عند ظهور حاجة جديدة، تستخدم الشركة إمكانيات معيارية وواجهات برمجة تطبيقات وأحداثًا يمكن دمجها بطرق متنوعة.
لا يتطلب هذا النهج تحويل كل تطبيق إلى خدمة مصغرة أو استبدال الأنظمة القديمة فوراً. بل يسمح بالتحديث التدريجي، بدءاً من المجالات التي يؤثر فيها الجمود التكنولوجي بشكل مباشر على العمل.
تُهيئ قابلية التركيب المؤسسة أيضاً للذكاء الاصطناعي. تحتاج الأنظمة الذكية إلى أدوات وبيانات وعمليات محددة بوضوح. تستطيع الشركة التي تمتلك قدرات قابلة لإعادة الاستخدام ربط هذه الأنظمة بشكل آمن ومُحكم. أما الشركة التي تعتمد أنظمة مغلقة، فسيتعين عليها بناء عمليات تكامل مخصصة لكل حالة جديدة.
لا ينبغي تصميم البنية التحتية لدعم العمليات الحالية فقط، بل يجب أن تمكّن المؤسسة من الاستجابة للتغيرات التي لا يمكنها التنبؤ بها بعد.
لأن التحول الرقمي لا يتعلق باستبدال منصة جامدة بأخرى تبدو أكثر حداثة.
ويتمثل ذلك في بناء شركة قادرة على التطور دون الحاجة إلى تفكيك نفسها في كل مرة يتغير فيها السوق.
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
