كيف نجحنا في حل مشكلة ثلاثة متجانسات

في استراتيجيات معظم الشركات ، يتم ذكر الرقمنة بشكل متزايد: تحاول بعض الشركات إدخال التقنيات الحديثة (على سبيل المثال ، Big Data و IoT و AI و blockchain) ، في حين تعمل شركات أخرى في كل مكان على أتمتة عملياتها الداخلية. على الرغم من الجهود المتزايدة والاستثمارات في تنفيذ الأنظمة ، يرى الكثيرون النتائج على أنها متواضعة. من الناحية المثالية ، يجب أن تكون المؤسسات الحديثة قادرة على إنشاء منتجات رقمية جديدة بسرعة أو الاندماج مع خدمات الجهات الخارجية الشهيرة ؛ اتخاذ عمليات تتجاوز تنظيمهم ؛ تكون قادرة على التفاعل بشكل فعال مع الشركاء ، مع الحفاظ على عزل عملياتهم. يجب أن تكون قادرًا أيضًا على ليس فقط جمع البيانات ، ولكن أيضًا الوصول إليها وإدارتها بسرعة. ومع ذلك ، حتى الشركات الناضجة تواجه تحديات تحويل وإدارة البيانات ،مع التنافس المستمر لأولويات العمل. ما الذي يمنعهم من تحقيق الكمال؟ 

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

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


تطبيق Monolith


واحدة من المشاكل المعمارية الثلاثة عند إنشاء حلول المؤسسة هي مجموعة متجانسة من التطبيقات ، والتي تظهر مع إضافة المزيد والمزيد من الوظائف إلى تطبيق موجود. على مر السنين ، يتحول التطبيق إلى "وحش" ​​مع الكثير من الوظائف المتشابكة والمكونات المعتمدة على بعضها البعض ، مما يستتبع النقاط السلبية التالية:

  • وجود نقطة فشل واحدة (في حالة حدوث فشل في إحدى وحدات التطبيق ، يفشل التطبيق بالكامل ويتوقف جميع الموظفين الذين يعملون مع هذا التطبيق عن العمل) ؛
  • صعوبة في ضمان الجودة المطلوبة للمنتج المطور ، والحاجة إلى اختبار الانحدار الحجمي ؛
  • فريق متآلف واحد ، وهو غير عملي للتوسع ، لأن هذا لن يسرع عملية التطوير ويسهلها ؛
  • , ; , ; 
  • ( -). , , « ». ;
  • .

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


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

على الرغم من وجود فكرة الوحدات النمطية لسنوات عديدة ، فإن بنية الخدمات الصغيرة توفر مرونة أكبر بكثير ، مما يسمح للمؤسسات بالاستجابة بسرعة أكبر لظروف السوق المتغيرة.

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

تكامل مترابط


ترتبط المشكلة المعمارية الثانية ، متراصة التكامل ، باستخدام ناقل الشركة للتكامل ( Enterprise Service Bus ، ESB). هذا هو نمط معماري مع طبقة تفاعل واحدة على مستوى المؤسسة توفر رسائل مركزية وموحدة موجهة نحو الحدث. 


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

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

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

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

متآلف البيانات


المشكلة المعمارية الثالثة ، ولكن ليست أقل أهمية ، هي مشكلة ترابط البيانات ، المرتبطة باستخدام مستودع بيانات مؤسسي مركزي ( Enterprise Data Warehouse، EDW). حلول EDW باهظة الثمن ، فهي تحتوي على بيانات بتنسيق أساسي ، والتي ، نظرًا لمعرفة محددة ، يتم دعمها وفهمها من قبل فريق واحد فقط من المتخصصين ، والذي يخدم الجميع. البيانات في EDW تأتي من مصادر مختلفة. يتحقق فريق EDW منهم ويحولهم إلى تنسيق أساسي ، والذي يجب أن يلبي احتياجات مجموعات المستهلكين المختلفة داخل المؤسسة ، ويتم تحميل الفريق. بالإضافة إلى ذلك ، لا يمكن أن تكون البيانات المحولة إلى تنسيق أساسي معين مناسبة للجميع ودائمًا. الخلاصة - يستغرق العمل مع البيانات وقتًا طويلاً. وفقًا لذلك ، لا يمكن إطلاق منتج رقمي جديد في السوق بسرعة.


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

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

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

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

النهج الموزعة


للتلخيص ، فإن حل مشاكل جميع المتآلفات المدرجة هو:

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

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

والآن حول ما نحن فيه بالضبطهل نستخدم DTG كحل "لمشكلة monoliths" عند تحسين العمليات الرقمية لعملائنا ودمجهم في النظام البيئي للشركاء؟ إجابتنا هي فئة منصة تكنولوجيا الأعمال الرقمية (انظر تصنيف تحليلات غارتنر). اتصلنا بـ GRANUMوبناءً على التقاليد ، تم بناؤها على مزيج من التقنيات مفتوحة المصدر ، والتي تتيح لنا إنشاء أنظمة موزعة معقدة بسرعة وسهولة في بيئة الشركة. سنتطرق إلى التقنيات بمزيد من التفاصيل أدناه. ما أصبح أسهل وأسرع؟ باستخدام النظام الأساسي ، قمنا بتسريع عملية تكامل الأنظمة الأساسية لتكنولوجيا المعلومات للعملاء وأنظمة تفاعل العملاء وإدارة البيانات وإنترنت الأشياء والتحليلات ، وسرعان ما تمكنوا من دمج أنظمة العملاء بسرعة مع شركاء النظام البيئي للتعامل مع أحداث الأعمال واتخاذ قرارات مشتركة لخلق قيمة مشتركة. كما ساعدنا استخدام التقنيات مفتوحة المصدر على الاستجابة لطلبات العملاء المتعلقة بتجنب البرامج المرخصة. 

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


يمكن تقسيم المنصة إلى ثلاث طبقات منطقية. 

  1. الطبقة السفلية هي البنية التحتية. مصممة لتقديم الخدمات الأساسية. يشمل ذلك الأمان ، ومراقبة وتحليل السجلات ، وإدارة الحاويات ، وتوجيه الشبكة (موازنة التحميل) ، وأجهزة التطوير. 
  2. طبقة التكامل - تدعم البنية الموزعة (نهج DataMesh ، الخدمات الدقيقة ومعالجة البيانات المتدفقة).
  3. — . (track&trace), , . . 

دعنا نتحدث بشكل أكثر تحديدًا حول تقنيات المصادر المفتوحة التي اخترناها. أي منهم يستخدم في أفضل ممارساتهم من قبل شركات الإنترنت الرائدة مثل Netflix و LinkedIn و Spotify. يتم اختيار تقنيات Kubernetes ، و Jenkins ، و Keycloak ، و Spring Boot ، و Fluentd ، و Grafana ، و Prometheus لمكافحة مجموعة التطبيقات المتراصة ، وبناء والعمل مع بنية الخدمات الصغيرة ، وكذلك في السعي إلى المرونة وسرعة التغييرات. للابتعاد عن بنية متجانسة ، يستخدم نهج Agile Integration عادة Apache Camel و NiFi و WSO2 API Manager. وأخيرًا ، فإن Kafka و Flink و Salase Event Portal مفيدة لحل مشكلة ترابط البيانات وتقسيمها والانتقال إلى تحليل البيانات في الوقت الفعلي باستخدام نهج شبكة البيانات.

يمثل الرسم التوضيحي أدناه مجموعة من التقنيات التي ، نتيجة للتجارب ، اعتبرنا في DTG مثالياً لحل مشكلة ثلاث وحدات متجانسة.


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

مفتوحة دائمًا في مجموعة شركاتنا . في انتظارك!

All Articles