يتم توحيد واجهات برمجة التطبيقات (APIs). تتم مشاركة الدلالات. يتم محاذاة المشغلين. توجد صناديق حماية للمطورين. التطبيقات المرجعية مفتوحة.
لقد اعتقد مشغلو الاتصالات منذ فترة طويلة أن شبكاتهم تحتوي على قيمة أساسية للنظام الأساسي. تقوم شبكات الهاتف المحمول بمصادقة الأجهزة، وربط أرقام الهواتف بالبنية التحتية المادية، ومراقبة السلوك الذي لا تستطيع التطبيقات رؤيته مباشرة. وفي عصر الاحتيال والهجمات الآلية القائم على الذكاء الاصطناعي، تبدو هذه الإشارات ذات قيمة فريدة.
أنا لست محايدا بشأن هذه الفكرة. لقد كنت الداعم لها لفترة طويلة. منذ أكثر من عقد من الزمان، عندما كنت في شركة Ericsson، عملت على حل هذه المشكلة خلال عصر مجتمع التطبيقات بالجملة، جنبًا إلى جنب مع سام رامجي، الذي كان في ذلك الوقت يقود الإستراتيجية في Apigee حيث حاولت الصناعة جعل قدرات المشغل قابلة للاستهلاك من قبل مطوري التطبيقات.
ومن خلال البوابة المفتوحة GSMA وCAMARA، تمكنت الصناعة أخيرًا من معالجة الأعطال الفنية التي قوضت المحاولات السابقة. يتم توحيد واجهات برمجة التطبيقات (APIs). تتم مشاركة الدلالات. يتم محاذاة المشغلين. توجد صناديق حماية للمطورين. التطبيقات المرجعية مفتوحة.
ومع ذلك يظل الاستخدام هامشيا.
غالبًا ما يتم تأطير هذه الفجوة على أنها مشكلة “تجربة المطور”. هذا التشخيص غير مكتمل. أما القضية الأعمق فهي اقتصادية: ما هو نوع واجهات برمجة التطبيقات (API) الخاصة بشركات الاتصالات التي يمكن أن تكون واقعيًا، وما هو النوع الذي لا يمكن أن تكون عليه.
ما الذي يجعل أعمال API حقيقية
تصبح واجهة برمجة التطبيقات (API) عملاً تجاريًا عندما تستوفي ثلاثة شروط في نفس الوقت.
أولاً، يحل مشكلة يدفع العملاء بالفعل لحلها. نادراً ما تخترع واجهات برمجة التطبيقات الناجحة إنفاقًا جديدًا؛ فهي تحل محل الحلول غير الفعالة أو الهشة الموجودة بالفعل.
ثانيا، فإنه يخلق إسفين حاد. لا تعالج واجهات برمجة التطبيقات المبكرة الأسواق الواسعة. إنها تحل مشكلة مؤلمة واحدة بشكل واضح للغاية بحيث يبدو التبني واضحًا وليس مجرد تخمين.
ثالثاً، يؤسس لتبعية دائمة. يعتمد المطورون على واجهات برمجة التطبيقات عندما يكون التبديل لاحقًا مكلفًا أو محفوفًا بالمخاطر أو معطلاً من الناحية التشغيلية.
تشرح هذه الشروط سبب توسيع نطاق واجهات برمجة تطبيقات التخزين السحابي والمدفوعات والاتصالات. كما أنها تشرح سبب عدم عمل العديد من واجهات برمجة التطبيقات الصحيحة تقنيًا.
ما هي برامج API للاتصالات التي تم إصلاحها بشكل حقيقي
ومن المهم أن نكون دقيقين فيما يتعلق بالتقدم، لأنه بدونه ستكون بقية المناقشة نظرية.
لقد فعلت كامارا ما لم تفعله المبادرات السابقة. لقد حددت واجهات برمجة تطبيقات الشبكة ذات دلالات مشتركة في التعليمات البرمجية، مدعومة بتطبيقات مرجعية مفتوحة. وهذا يقلل من مخاطر التكامل وتكاليف الصيانة على المدى الطويل. بدون هذا، لا يمكن اعتماد جدي من قبل طرف ثالث.
قامت البوابة المفتوحة لـ GSMA بحل مشكلة مختلفة. لقد خلق توافقًا موثوقًا به بين المشغلين، مما قلل من الخوف من أن يتعطل أي تكامل داخل شبكة واحدة. بالنسبة لأي شخص يفكر في استثمار الجهد الهندسي، فإن هذه الإشارة مهمة.
اعتمد العديد من المشغلين أيضًا الموقف الصحيح تجاه المطورين. تقدم Vodafone وTelefónica الآن صناديق حماية مجانية بدون عقود. وهذا يعكس نموذج السحابة ويعكس حقيقة بسيطة: لا ينبغي لأي مطور عقلاني أن يدفع قبل أن يعرف ما إذا كانت واجهة برمجة التطبيقات تعمل أم لا.
يضيف دور Vonage عنصرًا مهمًا آخر. ومن خلال توزيع واجهات برمجة تطبيقات الشبكة جنبًا إلى جنب مع الاتصالات الأولية التي يستخدمها المطورون بالفعل، فإنه يقلل من احتكاك الاكتشاف ويعترف بأن التوزيع، وليس التعرض، هو المورد النادر.
هذه شروط ضرورية. يقومون بإزالة الحواجز التاريخية. لكنها لا تخلق الطلب في حد ذاتها.
الاحتيال كاختبار الضغط الصحيح
غالبًا ما يُشار إلى الاحتيال باعتباره أقوى حالة استخدام لواجهات برمجة تطبيقات شركات الاتصالات، وذلك لسبب وجيه. إن الاستيلاء على الحساب أمر حقيقي ومكلف ومتزايد. وتنفق البنوك، وشركات التكنولوجيا المالية، والأسواق، ومنصات المستهلكين بالفعل المليارات سنويا في محاولة لمنع ذلك. الميزانية موجودة.
لفهم المكان المناسب لإشارات شركات الاتصالات، من المفيد وصف مكدس الاحتيال الحديث بوضوح.
تنشر معظم المؤسسات الكبيرة بالفعل ما يلي:
- تنسيق الهوية منصات مثل Okta أو Auth0 أو Microsoft Entra
- ذكاء الجهاز خدمات مثل Fingerprint أو Kasada أو iovation
- القياسات الحيوية السلوكية من البائعين مثل BioCatch أو Feedzai
- ذكاء الشبكة والملكية الفكرية من Cloudflare أو Akamai أو موفري خدمات مماثلين
- محركات المخاطر التي تجمع بين هذه الإشارات لتقرر متى يجب تكثيف المصادقة
تسجل هذه الأنظمة بالفعل المخاطر، وتوازن بين خسارة الاحتيال واحتكاك المستخدم، وتتطور بشكل مستمر. فهي ليست عناصر نائبة تنتظر الاستبدال.
وعلى هذه الخلفية، تقدم شبكات الاتصالات إشارتين مميزتين:
- ما إذا كان الجهاز يمتلك بالفعل رقم الهاتف الذي يطالب به
- ما إذا كان رقم الهاتف هذا قد تعرض مؤخرًا لتغيير بطاقة SIM
ومن وجهة نظر هندسية، تعتبر هذه إشارات قيمة. ومن وجهة نظر السوق، فهي تدريجية وليست بديلة.
هذا التمييز يقود كل ما يلي.
لماذا يعتبر التضمين في سير العمل هو اختبار التبني الحقيقي
تعيش الإشارات الإضافية أو تموت بسبب مدى سهولة ملاءمتها لتدفقات القرارات الحالية.
لا تقوم فرق الاحتيال ببناء مسارات عمل جديدة لكل إشارة. وهي تعمل داخل أنظمة قائمة تبدو تقريبًا كما يلي:
الإشارات في ← درجة المخاطرة ← الإجراء (السماح، التصعيد، الحظر)
لكي يتم اعتمادها، يجب أن تظهر إشارة شركة الاتصالات كمدخل إضافي في رسم بياني موجود بالفعل، وليس كنظام فرعي جديد يتطلب مراجعة منفصلة للاستدلال والمشتريات والامتثال.
وهذا يعني بشكل ملموس:
- التضمين في تنسيق الهوية
تظهر إشارة شركة الاتصالات كشرط سياسة داخل Okta/Auth0/Entra، وليس كخدمة منفصلة يجب على مهندسي الخدمة التفكير فيها. - التضمين في محركات اتخاذ قرار الاحتيال
الناتج عبارة عن سمة خطر موحدة ذات دلالات واضحة (“تغيير بطاقة SIM الأخير خلال X ساعة”)، وليست بيانات تعريف اتصالات أولية. - التضمين في خطوط أنابيب المراقبة والتدقيق
تتدفق السجلات والتنبيهات والأدلة إلى نفس أنظمة SIEM/SOAR المستخدمة بالفعل في عمليات الاحتيال. - التضمين في المشتريات والامتثال
يتم وضع قواعد الموافقة ونسب البيانات والاحتفاظ بها مسبقًا، ولا يتم إعادة اكتشافها من قبل العميل.
هذا هو السبب في أن التضمين في سير العمل ليس مصدر قلق لتجربة المستخدم. إنها الآلية التي تتغلب بها الإشارات الإضافية على هامشيتها.
تعلمت Hyperscalers هذا في وقت مبكر. بدأت واجهات برمجة تطبيقات Telco للتو.
TAM واقتصاديات الوحدة
لفهم ما إذا كانت واجهات برمجة التطبيقات الخاصة بالاحتيال في شركات الاتصالات يمكنها دعم الأعمال التجارية على مستوى النظام الأساسي، نحتاج إلى تشغيل الأرقام بعناية.
ابدأ مع العملاء. هناك ما يقرب من 300000 مؤسسة متوسطة إلى كبيرة على مستوى العالم لديها حسابات عبر الإنترنت. نسبة قليلة فقط لديها تعرض للاحتيال بدرجة كافية لتبرير الإشارات المتقدمة. التقدير المعقول هو حوالي 10 بالمائة، أو 30 ألف مشترٍ جاد.
التالي المعاملات. لنفترض أن كل مؤسسة لديها 20 مليون حساب مستخدم، مع خمسة أحداث مصادقة لكل حساب سنويًا. وينتج عن ذلك 100 مليون حدث مصادقة سنويًا.
ولكن هناك مجموعة فرعية فقط من هذه الأحداث حساسة للاحتيال: استرداد الحساب، وتسجيل الدخول إلى جهاز جديد، وإعادة تعيين كلمة المرور، والإجراءات ذات القيمة العالية. ومن الناحية التجريبية، تبلغ هذه النسبة 5-15 بالمائة. يؤدي استخدام 10 بالمائة إلى إنتاج 10 ملايين حدث مرشح لكل مؤسسة سنويًا.
وفي ثلاثين ألف مؤسسة، يعني ذلك وقوع 300 مليار حدث عالي المخاطر سنويا. هذا هو الحد الأقصى النظري للسطح الذي يمكن أن تنطبق عليه إشارات الاتصالات.
الآن تطبيق الواقع.
لا تحدث كل هذه الأحداث على شبكات الهاتف المحمول. يحدث الكثير منها على أجهزة الكمبيوتر المكتبية أو شبكة Wi-Fi أو شبكات VPN. بشكل متحفظ، قد تصل نسبة قابلية تطبيق الهاتف المحمول إلى حوالي 30 بالمائة. وهذا يقلل السطح إلى 90 مليار حدث.
كما أن القيود التنظيمية وقيود الموافقة تحد من قابلية التطبيق. الشيكات الصامتة غير مسموح بها عالميًا. وإزالة 30 بالمائة أخرى يترك 63 مليار حدث.
لن تقوم فرق الاحتيال باستدعاء إشارات شركات الاتصالات في كل حدث متبقي. سوف يستخدمونها بشكل انتقائي حيث يبرر الرفع التكلفة. بافتراض أن الاستخدام على نصف التدفقات المطبقة ينتج عنه 31.5 مليار حدث.
التسعير هو القيد النهائي. غالبًا ما تكلف الإشارات المتنافسة مثل بصمة الجهاز وذكاء IP ما بين 0.0005 دولار و0.001 دولار لكل حدث ولا تتطلب أي اعتماد على شركة الاتصالات. لكي تكون قادرة على المنافسة، يجب أن يكون سعر إشارات شركات الاتصالات عند هذا النطاق أو أقل منه.
عند 0.001 دولار أمريكي لكل قرار ناجح، يبلغ حجم السوق السنوي الناتج حوالي 31 مليون دولار أمريكي.
حجم السوق السنوي (بالدولار الأمريكي)
| المصادقة لكل حساب في السنة | استندت شركة الاتصالات إلى 25% من التدفقات المؤهلة | استندت شركة الاتصالات إلى 50% من التدفقات المؤهلة | استندت شركة الاتصالات إلى 75% من التدفقات المؤهلة |
| 5 (محافظ جدا) | ~ 16 مليون دولار | ~ 31 مليون دولار | ~ 47 مليون دولار |
| 10 | ~ 31 مليون دولار | ~63 مليون دولار | ~ 94 مليون دولار |
| 20 | ~63 مليون دولار | ~ 126 مليون دولار | ~ 189 مليون دولار |
حتى في السيناريو المتفائل، يواجه السوق صعوبة في تجاوز 200 مليون دولار سنويًا بسعر 0.001 دولار لكل حدث.
للوصول إلى +1 مليار دولار، يجب أن يكون واحدًا على الأقل مما يلي صحيحًا:
- ارتفاع الأسعار ماديًا فوق الإشارات المنافسة (غير محتمل)،
- تحل إشارات شركات الاتصالات محل إشارات الاحتيال الموجودة بدلاً من استكمالها (غير محتمل)،
- أو تصبح واجهات برمجة تطبيقات الاتصالات إلزامية من خلال التنظيم أو التبعية الهيكلية (عمل مختلف تمامًا).
تبدو النتيجة واضحة: هذا ليس مقياسًا مفرطًا. إنه على مستوى البنية التحتية.
تعريف أكثر واقعية للنجاح
تشير هذه الملاحظات مجتمعة إلى نتيجة مختلفة عما تقترحه العديد من روايات الصناعة.
من غير المرجح أن تصبح واجهات برمجة تطبيقات Telco منصات مطورة على طراز Hyperscaler. ويتمثل دورها الطبيعي في كونها بنية تحتية موحدة ومنظمة يتم استهلاكها بشكل غير مباشر من خلال الأنظمة الأساسية التي تمتلك بالفعل علاقات مع المطورين.
في هذا النموذج:
- تركز شركات الاتصالات على الموثوقية والتغطية والامتثال
- يتم تسعير واجهات برمجة التطبيقات (APIs) باقتصاديات الجملة
- تتراكم القيمة من خلال الوجود في كل مكان، وليس من خلال الرؤية
- يتم قياس النجاح من خلال الاعتماد على الشريك، وليس من خلال مشاركة أفكار المطورين
إن تجربة الصين، حيث تبدو الإيرادات الكبيرة الشبيهة بواجهة برمجة التطبيقات (API) مرتبطة بمنصات متكاملة رأسياً بدلاً من الأنظمة البيئية المفتوحة للمطورين، تعزز هذا التفسير بدلاً من تعارضه.
وهذا لن يؤدي إلى فشل واجهات برمجة تطبيقات الاتصالات. من شأنه أن يجعلها قابلة للمقارنة بطبقات الإنترنت الهامة الأخرى ولكن غير المرئية.
القرار الذي يجب على الصناعة اتخاذه
السؤال الاستراتيجي الحقيقي ليس كيفية تحسين واجهات برمجة تطبيقات الاتصالات. يتعلق الأمر بما إذا كان المشغلون يحاولون بناء منصات أو بنية تحتية للمنصات.
إذا كان الهدف هو المنصات، فلابد من جعل حالة استخدام ضيقة واحدة أفضل وأرخص بشكل كبير من البدائل، ويجب على المنظمة أن تتقبل أن معظم التجارب ستفشل قبل أن تنجح أي منها.
وإذا كان الهدف هو البنية الأساسية، فلابد أن يقاس النجاح بالتبعية الهادئة، وليس الحماس العام.
لقد تم حل المشكلة الهندسية إلى حد كبير. ما تبقى هو خيار اقتصادي وتنظيمي حول نوع واجهات برمجة التطبيقات (APIs) الخاصة بشركات الاتصالات.
