API Inside در مقابل Enterprise

مرز بین عملکرد فناوری اطلاعات داخلی و خارجی در یک شرکت تمایز کاذب است. هیچ کس نمی تواند پیش بینی کند که چگونه داده ها استفاده می شوند یا اطلاعات از کجا جریان می یابد. حتی اگر می دانید خطوط داخلی و خارجی شرکت شما امروز به کجا کشیده شده است - این خطوط در آینده تقریباً حرکتی خواهند داشت.

Pitney Bowes را بگیرید ، شرکتی که من با آنها در نقش من در تیم Apigee در Google کار کردم. در حالی که بسیاری از تاریخ نزدیک به قرن خود ریشه در راه حل های پستی فیزیکی مانند کنتورهای حمل و نقل داشته است ، این شرکت همچنین طی سالها توسعه قابلیت پرداخت و تجارت الکترونیکی را ایجاد کرده و مقادیر زیادی از داده های لجستیکی ، حمل و نقل و جغرافیایی را بدست آورده است. از آنجا که پیتنی بووز از خدمات آنالوگ به دنیای تجارت متصل امروزی تکامل یافته است ، از این دارایی ها و شایستگی های موجود در سازمان به دست می آید - اما این واقعیت را تشخیص داد که دارایی ها و شایستگی ها می توانند در خارج از شرکت و برای توسعه دهندگان و شرکایی که می توانند از آنها استفاده کنند نیز با ارزش باشند. برای ساخت برنامه ها و خدمات جدید

برای به دست آوردن این فرصت ، پیتنی بوز بیش از 160 API عمومی را از طریق ابر ارائه می دهد ، میلیون ها درآمد جدید بالقوه جدید را باز می کند و به تلاش های تجارت دیجیتال این شرکت کمک می کند تا به یک تجارت سالانه یک میلیارد دلار تبدیل شود. داده ها و کارایی که زمانی فقط داخلی بوده است اکنون نیز خارجی است.

در اینجا یک درس وجود دارد: فکر کردن به راه حل ها و استراتژی های تجاری از نظر "داخلی" و "خارجی" یا به معنای "یکپارچه سازی سیستم A و سیستم B" قدیمی است. مسئله این نیست که شما چگونه می خواهید سیستم های داخلی و کاربران خود را به هم وصل کنید - این ارتباط می تواند به چندین روش انجام شود. بلکه مسئله این است که پس از برقراری ارتباط ، چه کاری می توانید انجام دهید.

پاسخ به نوع اتصال بستگی دارد - استاتیک در مقابل پویا. به عنوان مثال ، در دنیای قدیمی راه حل های نقطه ، تمرکز فقط یکپارچه سازی استاتیک ، گرفتن اطلاعات از سیستم A به سیستم B. مکانیسم های یکپارچه به کار رفته اغلب شکننده و پیچیده بودند و فقط روی مسیر فعلی A-B تمرکز می کردند ، گویی. مسیرهای آینده به C ، D یا E هرگز رونق نخواهد گرفت.

اما البته این طور نیست. همانطور که از نمونه پیتنی بوز نشان می دهد ، مسیرهای داده امروز ممکن است چیزی شبیه به فردا نباشد. در دراز مدت ، همه اتصالات باید پویا ، آماده باشند تا در صورت لزوم به پایین یا پایین بیایند و آماده باشند تا با هر آنچه لازم است رابط شوند. برای رقابتی ماندن ، شما فقط نمی توانید از همان فن آوری ها استفاده کرده و به شکاف خود ادامه دهید ، و نمی توانید به چارچوب های فرو ریختنی مانند "داخل" و "خارج" اعتماد کنید.

به طور خاص ، در اینجا حداقل شرایط لازم برای دسترسی داخلی به یک سیستم ذکر شده است:

  • امنیت
  • دنباله حسابرسی
  • دید
  • عملکرد زمان اجرا (زمان بروز ، تاخیر)
  • هزینه (اجتناب از هزینه ، پس انداز هزینه)

به طور سنتی ، بسیاری از مشاغل در اینجا متوقف شده اند. اما نکات دیگری وجود دارد که باید در دنیای پر سرعت امروز مورد توجه قرار گیرد:

  • بینش / تجزیه و تحلیل
  • راحتی در استفاده
  • قابلیت توسعه
  • گزینه های استقرار (به عنوان مثال ، ظروف ، ابر ، مقیاس)
  • کسب درآمد
  • کنترل ریز دانه

همانطور که الزامات جدید نشان می دهد ، اگر سیستم های خود را با این انتظار که آنها مجبور به تعامل با سیستم هایی شوند که هنوز اختراع نشده اند ، برقرار کنید ، می توانید خود را به خطر بیاندازید. هنوز هم بسیاری از افراد به اشتباه فکر می کنند که این چالش شلیک بخش های زیادی از داده ها از طریق امنیت درشت دانه به برنامه های ضخیم مشتری است.

اما پیش می رویم ، برنامه ها و معماری ها باید بسیار گرانول و مقیاس پذیر باشند. برای رسیدن به آنجا ، مشاغل باید از ذهنیت یکپارچه سازی به رویکردهای مدرن تری که سیستم ها را بطور انبوه ، قابل اطمینان و مقیاس پذیر در عین تهیه دید ، بینش ، کنترل و امنیت در دسترس قرار می دهند ، تحول پیدا کنند. پایه و اساس اکثر این معماری های سریع و هسته ای API تولید خواهد شد - یعنی API هایی که فقط برای افشای دارایی ها استفاده نمی شوند بلکه به عنوان محصولاتی طراحی شده و مدیریت می شوند که به توسعه دهندگان چه داخلی و چه خارجی می توانند برنامه های جدیدی را ایجاد کنند ، دسترسی به برند را گسترش داده و فرصت های جدید درآمد را باز کنید.

این تمایز مهم است: API ها امروزه در بسیاری از سناریو های ادغام استفاده می شوند ، بنابراین نیازی به داشتن API نیست - لازم است API ها برای مصرف ، استفاده مجدد و بهبود مداوم طراحی و مدیریت شوند. به عبارت دیگر ، با یک طرز تفکر ادغام ، API ها می توانند مشکلات کوتاه مدت را حل کنند - اما وقتی فرد می بیند که بخش داخلی / خارجی به هم ریخته است و موارد استفاده از ادغام دیگر کافی نیستند ، مدیریت API منطقی ترین راه حل است.

[به راهنمایی های بیشتری درباره مدیریت API ها و رانندگی در تجارت دیجیتال علاقه دارید؟ به کتاب جدید Apigee ، "ذهنیت محصول API" مراجعه کنید.]