كيفية تنفيذ مشروع الخدمات المصغّرة الخاص بك (الجزء 3)
في هذه السلسلة المكونة من 6 أجزاء حول تطوير تطبيقات الخدمات المُصغّرة، نوفّر إطارًا لتحديد مشروع تجريبي قائم على السحابة يناسب الاحتياجات الحالية، ويُهيّئ المؤسسة لاتخاذ قرار اعتماد السحابة على المدى الطويل.
وفي الجزء الثالث، نستعرض طريقة لتنفيذ مشاريع الخدمات المُصغّرة الخاصة بك.
تطوير تطبيق قائم
نتعمّق هنا في كيفية رسم مسار لرحلات تطوير تطبيقات الخدمات المُصغّرة بمستويات مختلفة من التعقيد، مع النظر في التحوّل المحتمل من تغييرات صغيرة إلى تحولات أكبر للتطبيقات الحالية.
وبينما يمكن أن يكون إنشاء مشاريع خدمات مصغّرة دون وجود تطبيق مسبق أمرًا ممكنًا ومفيدًا، فإننا نتفق على تبنّي نهج "المتراصة أولًا" عند بناء الخدمات المُصغّرة. وباختصار، يعني ذلك بناء التطبيق بأي طريقة متاحة للتحقّق من صحة الفكرة أولًا. ثم نطبق المبادئ الواردة في هذه السلسلة لتوسيع نطاق التطبيق المتراص الأولي وتطويره إلى مشروع قائم على الخدمات المُصغّرة. لا قيمة لبناء خدمات مُصغّرة مثالية من الناحية التقنية إذا لم تُحقق قيمة فعلية للأعمال.
هناك ثلاثة مجالات أساسية يجب فهمها لتنفيذ مشروع خدمات مُصغّرة ناجح: فهم احتياجات الأعمال، وفهم الثقافة المؤسسية ومهارات الفريق، ثم فهم التقنية.
فهم احتياجات عملك وتحديدها
لماذا تفكّر في الانتقال إلى الخدمات المُصغّرة؟ بالنسبة للعديد من المؤسسات، يتطلب تحقيق قيمة أكبر للأعمال تبنّي ممارسات أكثر كفاءة في تطوير وتشغيل التطبيقات، بهدف تسريع تقديم الميزات وتحسين تجربة المستخدم.
وقبل تقييم تأثير مشروع الخدمات المُصغّرة على تطبيقاتك الحالية وبنيتك التحتية، يجب أن تحدد بوضوح الأجزاء في عملك التي تتحرك ببطء شديد بحيث لا تُحقّق النتائج المطلوبة. وفي كثير من الحالات، تكون أنظمة التفاعل (SOE) هي السبب الرئيسي لهذا البطء. تتوفر هذه الأنظمة من خلال العديد من القنوات - مثل الويب والتطبيقات المحمولة وواجهات برمجة التطبيقات وغيرها. ويُعد بطء التطوير وإطلاق الميزات هو الدافع الأساسي للانتقال إلى بنية قائمة على الخدمات المُصغّرة.
وقبل تبنّي هذا النهج، ينبغي لك وللأطراف المعنية في المؤسسة معرفة ما الذي لا يصل إلى السوق بالسرعة المطلوبة. ما الأجزاء من التطبيق التي تحتاج إلى تحسين أو إعادة تصميم لتصبح أسرع؟ والإجابة عن هذا السؤال توضّح أي أجزاء من التطبيق المتراص يجب تحليلها واستهدافها للتحويل إلى خدمات مُصغّرة.
استخدم مخططات تجربة المستخدم أو الرسومات المعمارية لمساعدة الفريق على تحديد أجزاء التطبيق المتراص التي يجب فصلها، وذلك عبر وضع تعليقات توضيحية بأسلوب الخرائط الحرارية. فعلى سبيل المثال، يمكن استخدام مقياس أحمر–أصفر–أخضر لتحديد أولوية مواطن الضعف داخل التطبيق.
وفي هذه المرحلة، ومن دون الحاجة لاختبار كل شيء منذ البداية، ومع تبنّي نهج تكراري، تتمثّل الأهداف الأساسية للتقييم في ما يلي:
حدد وظائف الأعمال المنفصلة التي يوفّرها لك التطبيق المترابط.
افهم مستوى السرعة والتعقيد المطلوبين لتعديل تلك الوظائف.
افهم رغبة صاحب العمل في الحصول على دورات تعليقات أسرع لهذه الوظائف تحديدًا.
افهم الثقافة المؤسسية ومجموعة المهارات
على الرغم من أن هذا الأمر ليس خاصًا بالبنى القائمة على الخدمات المُصغّرة، فإن الفهم العميق لفرق المؤسسة وثقافتها ومهاراتها يُعد عنصرًا حاسمًا لنجاح أي تحول رقمي.
وفي معظم المؤسسات التي تعتمد تطبيقات مترابطة، يجري العمل ضمن فرق معزولة، حيث يشارك كل فريق فقط عند الحاجة طوال دورة حياة تطوير البرمجيات. وغالبًا ما يؤدي هذا النمط إلى ظهور حدود واضحة جدًا، مع أدوار ومسؤوليات مقيدة داخل تلك الحدود.
ولا يمكن لبنية الخدمات المُصغّرة أن تنجح إلا عندما تمتلك الفرق القدرة على إدارة دورة حياة التطوير والتشغيل كاملة. ويُعد بناء فرق متعددة التخصّصات تشمل جميع الأدوار والمسؤوليات خطوة أساسية في تنفيذ البنى المبنية على الخدمات المُصغّرة. فالجميع—من التصميم، إلى التطوير، إلى التشغيل، إلى صاحب العمل—يعملون بشكل متقارب، وغالبًا ما يكونون في موقع واحد.
وحين يكون كل طرف معني ممثلًا داخل الفريق عبر التصميم والتطوير والعمليات، يمكن إنجاز العمل بسرعة أكبر، وكفاءة أعلى، مع تركيز واضح على تحسين تجربة المستخدم لتحقيق أهداف العمل.
تدعم الفرق متعددة التخصّصات نمو مهارات الأفراد بشكل سريع داخل الفريق. وعندما يمتلك الفريق كامل المسؤولية عن الخدمة المُصغّرة، من التصميم، إلى التشغيل، إلى بيانات وقت التشغيل، لا يكون أي عضو في الفريق محصورًا في مهمة واحدة فقط. ففي كثير من الأحيان، يكتسب مهندسو الواجهة الأمامية مهارات في إدارة قواعد البيانات، بينما يتعلم أعضاء الفريق الموجهون نحو العمليات المزيد عن اختلافات أطر واجهات المستخدم. ويساعد توسيع مجموعة المهارات بهذه الطريقة المؤسسة بأكملها على النجاح في تبنّي الخدمات المُصغّرة، إذ يصبح من الأسهل بكثير تشكيل فرق جديدة مكوّنة من أعضاء متعددي المهارات، بدلًا من البحث المتواصل عن متخصصين لأدوار شديدة التخصّص.
فهم التقنية
ما لم تُعالِج مشكلة العمل وثقافة فريقك ومجموعة مهاراته، فلن تتمكّن من تطبيق تقنية الخدمات المصغّرة بفعالية، وستظلّ تستخدم العمليات والهياكل نفسها المستخدمة بالفعل.
يختلف التحليل الدقيق لمكدّسات التقنية الحالية من مؤسسة إلى أخرى، لكن النهج المبسّط الذي نعرضه يساعد على ضمان نجاح مشاريع الخدمات المصغّرة على المدى القصير والطويل. إن البدء على نطاق صغير وتحديد نجاحات تدرّجية ومتتابعة يُعدّ نهجًا أكثر قابلية للتحقق وأكثر جدوى من نهج مبهر يحاول تحويل كل شيء دفعة واحدة.
تتمثّل المرحلة الأولى في فهم التقنية في تحديد الخدمات واسعة النطاق الموجودة داخل النظام الأحادي الحالي.يساعدك تحديد هذه الخدمات واسعة النطاق على فهم تعقيد هياكل البيانات، ومستوى الاقتران بين المكوّنات الحالية، والفرق المسؤولة عن كل خدمة جديدة واسعة النطاق، وغير ذلك. تمنحك المراجعة الفعّالة للخدمات واسعة النطاق فهمًا واضحًا لحدود البيانات داخل كل خدمة وعبر الخدمات الأخرى.
بعد تحديد الخدمات واسعة النطاق، تحتاج إلى وضع خطة لكيفية تطوير هذه الخدمات إلى خدمات مصغّرة دقيقة. يجب أن تعمل هذه الخدمات المصغّرة، استنادًا إلى العمل الذي أنجزته مسبقًا، على بيانات متقاربة، وأن تمتلك بياناتها الخاصة، وأن تعرف البيانات التي يجب قراءتها ومن أين، والبيانات التي يجب كتابتها إلى الخدمات الأخرى. ومن هنا، يمكنك تحديد وتنفيذ عناصر المرونة وقابلية التوسّع والمرونة في الخدمات المصغّرة الدقيقة الفردية.
تُعدّ واجهات برمجة التطبيقات والخدمات المصغّرة جزءين متكاملين من منظومة واحدة. وبمجرد أن تمتلك فهمًا أفضل لخدماتك المصغّرة الدقيقة، ستتمكن أيضًا من فهم واجهاتك بشكل أوضح: الواجهات الواقعة على المسار الحرج، والواجهات الاختيارية، وتلك التي لم تعد بحاجة إليها. إذا لم تتمكّن من ربط واجهة حالية أو واجهة برمجة تطبيقات بإحدى خدماتك واسعة النطاق أو الدقيقة النطاق، فالأغلب أنك تستطيع الاستغناء عنها.
تحديد حجم جهد الخدمات المصغّرة
إن الجهد الكبير المبذول في فهم العمل، وفهم هيكل الفريق، وفهم التقنية، يضمن أن تكون فرقك والمؤسسة ككل مستعدة لاستيعاب التطور الكامل لبنية الخدمات المصغّرة للنظام الأحادي — سواء كان ذلك ضمن نطاق إثبات المفهوم، أو نطاق تجريبي، أو نطاق تطوير واسع النطاق.
مع اكتمال جميع أعمال التحليل والتخطيط، تأتي الخطوة التالية المتمثّلة في تحديد الجداول الزمنية، وسرعات التسليم، والنتائج المتوقعة.
وفي المنشور التالي، سنتناول أنماط التطوير والعمليات التي يمكن تطبيقها عند تنفيذ التحول نحو بنية الخدمات المُصغّرة.
الخطوات التالية:
لتحديث وإعادة هيكلة تطبيق أحادي، اطّلع على مسار التقدّم المعماري التفصيلي.
تعاون Roland Barcia (مهندس متميز/CTO في IBM) وRick Osowski (عضو أول في الفريق التقني) مع Kyle في كتابة هذا المنشور.