إضفاء الطابع الديمقراطي على البيانات باستخدام الاختراع الرقمي

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

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

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

طرق إضفاء الطابع الديمقراطي على البيانات

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

مشاركة بيانات

عند البناء مع تعاطف العملاء، توجه احتياجات العملاء الحل. إذا كانت الحاجة هي البيانات، فإن الحل يمكن العميل من استجواب البيانات وتحليلها والإبلاغ عنها مباشرة، دون دعم من موظفي تكنولوجيا المعلومات.

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

تتضمن الأدوات الأساسية لمشاركة البيانات مباشرة مع مستهلكي البيانات تقارير الخدمة الذاتية أو البيانات المضمنة في تجارب أخرى، باستخدام أدوات مثل Power BI.

ملاحظة

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

التحكم في البيانات

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

بعد التحقق من صحة فرضية من خلال مشاركة البيانات، تكون المرحلة التالية من التطوير عادة إدارة البيانات.

تعد إدارة البيانات موضوعا واسعا يمكن أن يتطلب إطار عمل مخصصا خاصا به، وهي مسألة خارج نطاق Cloud Adoption Framework.

هناك العديد من جوانب إدارة البيانات التي يجب مراعاتها بمجرد التحقق من صحة فرضية العميل. على سبيل المثال:

• هل البيانات المشتركة حساسة؟يجب تصنيف البيانات قبل مشاركتها علنا لحماية مصالح العملاء والشركة.
• إذا كانت البيانات حساسة، هل تم تأمينها؟ حماية البيانات الحساسة أمر لا بد من وجوده للبيانات الديمقراطية. يوفر مثال حمل العمل الذي تمت مناقشته في تأمين حلول البيانات بعض المراجع لتأمين البيانات.
• هل يتم فهرسة البيانات؟ تحديد طبيعة البيانات المشتركة التي تساعد في إدارة البيانات على المدى الطويل. تسهل أدوات توثيق البيانات، مثل Azure كتالوج البيانات، هذه العملية في السحابة. يمكن للإرشادات المتعلقة بالتعليق التوضيحي للبياناتوتوثيق مصادر البيانات تسريع العملية.

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

مركزية البيانات

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

تنبيه

تمثل مركزية البيانات نقطة خطر في أي عملية ابتكار. عندما تكون مركزية البيانات طفرة تقنية، وليست مصدرا لقيمة العميل، نقترح عليك تأخير المركزية حتى يتم التحقق من صحة فرضيات العميل.

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

يمكن أن تساعدك البنيات المرجعية لحلول OLAPوالبيانات الضخمة في اختيار حل المركزية الأنسب في Azure. إذا كان الحل المختلط مطلوبا، يمكن أن تساعد البنية المرجعية لتوسيع البيانات المحلية أيضا في تسريع تطوير الحلول.

هام

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

جمع البيانات

النموذجان الأساسيان لجمع البيانات هما التكاملوالاستيعاب.

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

حولت الأدوات المستندة إلى السحابة هذه التقنيات إلى أدوات الدفع لكل استخدام، ما يقلل من حاجز الدخول لجمع البيانات والمركزية. تعد أدوات مثل Azure Database Migration ServiceوAzure Data Factory مثالين. البنية المرجعية ل Data Factory مع مخزن بيانات OLAP هي مثال على أحد هذه الحلول.

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

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

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

يدعم كل من SQL Server 2017 ومستودع بيانات Azure SQL PolyBase، وهو نهج المحاكاة الظاهرية للبيانات الأكثر استخداما في Azure.

الخطوات التالية

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

تطوير التطبيقات للتطبيقات المبتكرة