كيف قامت شركة خدمات مالية بتحديث نظام موروث غير مستقر وغير قابل للتطوير

مُقدم من MongoDB

غالبًا ما تكون شركات الخدمات المالية وراء المنحنى عندما يتعلق الأمر بالابتكار الرقمي. أدت مجموعة من القيود التنظيمية وتعقيد الحلول القديمة الداخلية التي تعتمد عليها الأعمال إلى جعل صناع القرار في مجال تكنولوجيا المعلومات يترددون بشكل غير مفاجئ في اللجوء إلى البنية السحابية أو البنية التي لا تحتوي على خادم.

كانت شركة Midland Credit Management (MCM) ، إحدى أكبر شركات مشتري الديون وتحصيل الديون في الولايات المتحدة ، في وضع مماثل ، وغارقة في قواعد البيانات العلائقية وبنية متجانسة مخصصة للغاية. لقد واجهوا بيئة وحلول خلفية غير مستقرة وغير قابلة للتطوير بشكل متزايد ، وكانت الفرق في وضع مكافحة الحرائق المستمر.

يقول علي منتظر ، كبير موظفي التكنولوجيا في MCM: “نظرًا لمدى تعقيد البيئة ، إذا أردت إجراء أي تغييرات ، فمن المستحيل تقريبًا إجراؤها دون كسر أي شيء”.

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

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

عند معالجة مشروع الهجرة والتحديث الخاص بهم ، قام MCM بفحص الجوانب الأساسية الثلاثة للبنية الخلفية الصحية: التكنولوجيا والأشخاص والعمليات التي تدعمهم. لقد احتاجوا إلى تغيير مفاهيمهم المدرسية القديمة وإعادة التفكير تمامًا في كيفية تنظيم الفريق ، وكيف يعمل نموذج التشغيل الخاص بهم بالفعل ، وأخيرًا ، كيفية مواءمة الهيكل مع هذا التغيير التنظيمي.

الملكية والتنظيم والعمارة

بالرجوع إلى الوراء ، حددت MCM المشكلات المفقودة في نموذجها التنظيمي – ملكية المطور للميزات التي كانوا يبنونها ، وثقافة الاتصال والتعاون بين فريق التطوير الذي يتولى التنفيذ وفريق الدعم. كان يعني تعزيز الشعور بالمساءلة عن التعليمات البرمجية لدى مطوريها ، وغرس شعورهم بالسلطة على القرارات. كما كان يعني أيضًا الانتقال من كونه قائمًا على المشاريع بالكامل إلى تبني عقلية المنتج – عقلية يمكن للمطورين امتلاكها والاستمرار في تطويرها وتحسينها.

قاموا بتقسيم فريق تطوير المنتج إلى مهندسي حلول رفيعي المستوى ، جنبًا إلى جنب مع مجموعة هندسية تم تشكيلها كفرق DevOps / Scrum ، بقيادة مدير تطوير البرامج (SDM) ، ومدير المنتج التقني ، و Scrum Master ، والمطورين والمختبرين. تعمل فرق سكرم مثل الشركات الناشئة داخل المؤسسة ، المسؤولة والمسؤولة عن المنتجات التي يبنونها ، مع ملكية طوال دورة حياة تطوير البرامج بأكملها.

مع تسوية التغييرات التنظيمية ، وجهت MCM أعينها نحو التبسيط الجذري للهندسة المعمارية التي تدعم تطوير التطبيقات وإطلاقها ودعمها.

كان الهدف هو الانتقال من بيئة متجانسة محلية إلى نموذج تشغيل سحابي أصلي موزع قائم على الحدث. سيمكن نموذج الخدمات المصغرة الجديد المطورين من بناء تطبيقات تستخدم تكنولوجيا بدون خادم لكميات كبيرة من تدفق البيانات.

سيُنشئ المشروع الافتتاحي تطبيقًا أحادي العرض من شأنه توحيد مصادر البيانات المتباينة للحملات متعددة القنوات ، مثل التواصل التنظيمي مع العملاء حول ديونهم.

التحديث باستخدام MongoDB و AWS

كانت العديد من الأنظمة والخدمات المالية للشركة عبارة عن حلول داخلية لها متطلبات استضافة داخلية. لم يكن من الممكن إجراء ترحيل الرفع والتحويل إلى السحابة ، ولم يكن قابلاً للتطوير.

أتاحت AWS و MongoDB لـ MCM الاستمرار في استخدام قاعدة البيانات المحلية الخاصة بهم عن طريق دفع تعديلات قاعدة البيانات من خلال CDC (التقاط تغييرات البيانات) ودفقها باستخدام Amazon Kinesis إلى سحابة AWS. يتلقى MongoDB Atlas البيانات ويعمل كمجمع لضمان أن كل مجموعة من البيانات المرسلة والمستلمة في الحالة الصحيحة.

كل جزء بيانات له طابع زمني ؛ يضع MongoDB هؤلاء معًا في مستند ، وهو جاهز بعد ذلك للأحداث التي ينشئها MongoDB للخدمات المصغرة التي تعالج البيانات. بدلاً من وضع كل شيء في مستند واحد ، والذي يمكن أن يزداد تكلفة إذا استمر عدد حقول البيانات في التوسع ، يمكن تصميم العملية مثل استدعاء واجهة برمجة التطبيقات ، حيث يتم إرسال البيانات حسب الحاجة لإنشاء حدث.

النتيجة الواقعية لتطبيق MongoDB و AWS

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

قبل تنفيذ حلهم الجديد ، كان MCM قادرًا فقط على إنشاء 14000 حرف في جولة واحدة. سيستغرق الأمر ما يصل إلى خمسة أيام لمعالجة مليون رسالة و 450 عملية إعدام شهريًا لتلبية الحجم المطلوب.

مع وجود حل MongoDB و AWS بدون خادم ، ينتج عن كل تشغيل 720 ألف حرف – تحسن بمقدار 50 ضعفًا في قابلية التوسع بالإضافة إلى القدرة على إنهاء المهمة 5 مرات أسرع من ذي قبل.

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

قال مونتازر: “إن القدرة على الاستفادة من هذه الحلول الجديدة المبنية على MongoDB Atlas على AWS سمحت لفرق التطوير لدينا بأن تصبح أكثر إنتاجية وتستفيد من ممارسات تطوير البرامج الحديثة”. “في نهاية اليوم ، نحن قادرون على تقديم تجارب أفضل لمستخدمينا النهائيين من خلال الحلول البرمجية الجديدة التي قدمناها إلى السوق.”

تعرف على المزيد هنا حول MongoDB Atlas ، منصة بيانات المطور متعددة السحابة ، وجربها مجانًا إلى الأبد هنا.

المقالات الدعائية هي محتوى تنتجه شركة إما تدفع مقابل المنشور أو لديها علاقة عمل مع VentureBeat ، ويتم تمييزها دائمًا بوضوح. لمزيد من المعلومات ، اتصل بـ sales@venturebeat.com.