انٹرپرائز کے باہر بمقابلہ APIs

کسی انٹرپرائز میں اندرونی اور بیرونی آئی ٹی کی فعالیت کے درمیان حد ایک غلط فرق ہے۔ کوئی بھی پیش گوئی نہیں کرسکتا ہے کہ ڈیٹا کو کس طرح استعمال کیا جائے گا یا جہاں معلومات منتقل ہوں گی۔ یہاں تک کہ اگر آپ جانتے ہو کہ آج آپ کی کمپنی کی داخلہ / بیرونی لائنیں کہاں کھینچی گئی ہیں - مستقبل میں یہ لائنیں لگ بھگ یقینی نشانہ بناتی ہوں گی۔

پٹنی بوؤس ، ایک ایسی کمپنی کو لے لو جس میں نے گوگل میں اپیجی ٹیم میں اپنے کردار میں کام کیا ہے۔ اگرچہ اس کی قریب صدی کی تاریخ کا زیادہ تر حصہ ڈاک کے میٹر جیسے جسمانی میلنگ حل میں ہے ، لیکن کمپنی نے کئی سالوں میں ادائیگیوں اور ای کامرس کی صلاحیتوں کو بھی تیار کیا اور لاجسٹکس ، جہاز رانی اور جغرافیائی محل وقوع کے اعداد و شمار کو حاصل کیا۔ چونکہ پٹنی بوس آج کی دنیا سے منسلک تجارت کے مطابق خدمات کے ذریعہ تیار ہوا ، اس نے ان اثاثوں اور تنظیم کے اندر قابلیت سے قدر حاصل کی - لیکن اس نے اثاثوں اور صلاحیتوں کو کمپنی کے باہر بھی قابل قدر ثابت کیا جاسکتا ہے ، ان ڈویلپرز اور شراکت داروں کے لئے جو ان کا استعمال کرسکتے ہیں۔ نئی ایپس اور خدمات کی تعمیر کے ل.۔

اس موقع سے فائدہ اٹھانے کے ل P ، پٹنی بوؤس بادل کے ذریعے 160 سے زیادہ عوامی APIs کی پیش کش کرتی ہے ، لاکھوں ممکنہ نئی آمدنی کو کھولتی ہے اور کمپنی کی ڈیجیٹل تجارت کی کوششوں کو 1 بلین ڈالر سے زیادہ سالانہ کاروبار بننے میں مدد کرتی ہے۔ ڈیٹا اور فعالیت جو اب صرف داخلی تھی اب بیرونی بھی ہے۔

یہاں ایک سبق موجود ہے: "داخلی" اور "بیرونی" کے لحاظ سے یا "انٹیگریٹ سسٹم اے اور سسٹم بی" کے لحاظ سے کاروباری حل اور حکمت عملی کے بارے میں سوچنا پرانی ہے۔ مسئلہ یہ نہیں ہے کہ آپ اپنے داخلی نظاموں اور صارفین کو کس طرح جوڑ رہے ہیں۔ اس تعلق سے کئی طرح کے راستے بنائے جاسکتے ہیں۔ بلکہ ، مسئلہ یہ ہے کہ آپ کنکشن بن جانے کے بعد اس کے ساتھ کیا کر سکتے ہیں۔

مستحکم بمقابلہ متحرک - اس کا جواب کنکشن کی قسم پر منحصر ہے۔ مثال کے طور پر حل کی پرانی دنیا میں ، توجہ صرف مستحکم انضمام کی ہوتی تھی ، جس سے نظام A سے سسٹم بی تک معلومات حاصل کی جاتی ہیں۔ استعمال شدہ یک سنگی میکانزم اکثر آسانی سے ٹوٹنے والا اور پیچیدہ ہوتا تھا ، صرف موجودہ A → B پرکشش مرکز پر مرکوز تھا۔ C ، D یا E کے مستقبل کے راستوں کو کبھی راستہ نہیں بنایا جائے گا۔

لیکن یقینا. ایسا نہیں ہے۔ جیسا کہ پٹنی بوز مثال کے طور پر ظاہر کرتا ہے ، آج کے ڈیٹا راستے کل کی طرح کچھ بھی نظر نہیں آسکتے ہیں۔ طویل عرصے میں ، تمام روابط متحرک ہونے کی ضرورت ہیں ، ضرورت کے مطابق اوپر یا نیچے بنانے کے لئے تیار ہیں ، اور جس چیز کی ضرورت ہے اس کے ساتھ انٹرفیس کے لئے تیار ہیں۔ مسابقتی رہنے کے ل you ، آپ صرف ایک ہی ٹکنالوجی کا استعمال نہیں کرسکتے اور بولٹ لگاتے رہ سکتے ہیں ، اور آپ "اندر" اور "باہر" جیسے گرتے ہوئے فریم ورک پر بھروسہ نہیں کرسکتے ہیں۔

خاص طور پر ، کسی سسٹم تک داخلی رسائی کے ل here کم سے کم تقاضے یہ ہیں:

  • سیکیورٹی
  • حساب کتاب کا دور
  • مرئیت
  • رن ٹائم کارکردگی (اپ ٹائم ، دیر ،)
  • لاگت (قیمت سے بچنا ، لاگت کی بچت)

روایتی طور پر ، بہت سارے کاروبار یہاں رک چکے ہیں۔ لیکن اس کے علاوہ بھی کچھ اور نکات ہیں جن پر آج کی تیز چلتی دنیا میں غور کرنا چاہئے:

  • بصیرت / تجزیات
  • استعمال میں آسانی
  • توسیع
  • تعیناتی کے اختیارات (جیسے کنٹینر ، بادل ، پیمانے)
  • منیٹائزیشن
  • ٹھیک دانوں پر قابو رکھنا

جیسا کہ نئی تقاضے ظاہر کرتی ہیں ، اگر آپ اپنے سسٹم کو اس توقع کے ساتھ نہیں بناتے ہیں کہ انہیں ابھی تک ان ایجاد کردہ نظاموں کے ساتھ تعامل کرنا پڑے گا ، تو آپ خود کو لاک کرنے کا خطرہ مول لے رہے ہیں۔ بہت سارے لوگ اب بھی غلطی سے یہ سوچ رہے ہیں کہ چیلنج موٹے دانوں کی حفاظت کے ذریعہ موٹا موٹی ایپلی کیشنز کو بڑی تعداد میں ڈیٹا بند کرنا ہے۔

لیکن آگے جاتے ہوئے ، ایپلی کیشنز اور فن تعمیر کو ناقابل یقین حد تک دانے دار اور توسیع پذیر ہونے کی ضرورت ہوگی۔ وہاں جانے کے ل businesses ، کاروباری اداروں کو انضمام ذہنیت سے زیادہ جدید نقط to نظر کی طرف تیار ہونا چاہئے جو نظام کو بصیرت ، قابل اعتماد اور اسکیللی طور پر دستیاب بناتے ہیں جبکہ مرئیت ، بصیرت ، کنٹرول اور سیکیورٹی کی فراہمی کرتے ہیں۔ ان میں سے بیشتر جوہری ، فرتیلی فن تعمیر کی بنیاد تیار کردہ APIs کی ہوگی - یعنی ، ایسی APIs جو صرف اثاثوں کو بے نقاب کرنے کے لئے استعمال نہیں ہوتی ہیں بلکہ وہ ایسی مصنوعات کے طور پر ڈیزائن اور انتظام کی جاتی ہیں جو ڈویلپرز کو بااختیار بناتی ہیں ، چاہے داخلی یا خارجی ، نئی ایپس بنانے کے ل، ، برانڈ کی رسائ میں توسیع کریں ، اور آمدنی کے نئے امکانات کھولیں۔

یہ امتیاز اہم ہے: آج کل متعدد انضمام منظرناموں میں APIs کا استعمال کیا جاتا ہے ، لہذا نقطہ یہ نہیں ہے کہ APIs کی ضرورت ہے - اس میں یہ ہے کہ استعمال شدہ استعمال ، دوبارہ استعمال اور مستقل بہتری کے لئے API تیار کی ہو اور اس کا انتظام کیا جاسکے۔ ایک اور راستہ اختیار کریں ، انضمام ذہنیت کے ساتھ ، APIs قلیل مدتی مسائل کو حل کرسکتے ہیں - لیکن ایک بار جب یہ معلوم ہوجائے کہ داخلی / خارجی تقسیم ختم ہوگئی ہے اور انضمام کے استعمال کے معاملات اب کافی نہیں ہیں تو ، API کا انتظام ہی سب سے معقول حل بن جاتا ہے۔

[APIs کا انتظام کرنے اور ڈیجیٹل کاروبار چلانے کے لئے مزید نکات میں دلچسپی رکھتے ہیں؟ اپیجی کی نئی ای بک ، "API پروڈکٹ مائنڈسیٹ" دیکھیں۔]