Battle-Tested APIs – Tech and Business Working Together
به عنوان امروز، ما همه از APIها استفاده میکنیم یا آنها را مصرف میکنیم. وقتی از تلفنهای هوشمند، لپتاپها، تبلتها و غیره استفاده میکنیم، ما در حال استفاده از APIها هستیم. اما ما نمیدانیم که با APIها کار میکنیم. فقط افراد فنی در شرکت از APIهایی که ساخته و مصرف میشوند آگاه هستند. بنابراین، API به عنوان یک محصول در خود دیده نمیشود؛ معمولاً بخشی از یک محصول کلی مانند یک برنامه کاربردی است.
یک API همیشه پشت مقداری پیچیدگی پنهان است
اما برای یک شرکت، این همچنین هستهی سیستم است. ممکن است یک API بدون یک برنامهی فرانتاند داشته باشید، اما ممکن است نتوانید یک برنامهی پیچیده بدون API داشته باشید. برای مثال، اگر همهی APIها را حذف کنیم، مثلاً از توییتر (یا X)، ممکن است یک رابط محتوایی عالی و برنامهی موبایل داشته باشیم، اما راهی برای پردازش مقادیر زیادی از داده یا ارسال پیامها و غیره نخواهیم داشت.
بیایید کار با داده را در نظر بگیریم
شما میتوانید از یک شیت گوگل یا یک شیت مایکروسافت اکسل برای جمعآوری و دستکاری داده استفاده کنید. اما اگر دادهها در تعداد زیاد باشند، ممکن است سخت شود. سادهتر خواهد بود که یک پایگاه داده را با استفاده از یک API کوئری کنید.
API باید به عنوان یک هدف برای شرکت شما دیده شود، نه فقط چیزی که بخشی از یک پروژه است.
ذهنیت API-اول
قبل از اینکه از APIها برای همه چیز استفاده کنیم، باید طرز فکر افرادی که در اطراف API کار میکنند را تغییر دهیم، چه مهندسین، چه کسبوکار، چه شرکتها و غیره. برای این، ما نیاز داریم ذهنیت API-اول را بسازیم. API-اول این ایدهی ساخت یک رویکرد API-اول را در بر میگیرد، که یعنی تلاش برای ساخت API شما به شکلی سازگار و قابل استفاده مجدد. شما باید یک قرارداد برای اینکه API چگونه باید رفتار کند برقرار کنید. این نیاز به بحث با افرادی دارد که در API دخیل هستند. اینکه APIها چگونه ساخته میشوند باید استانداردسازی شود.
API-اول شامل برنامهریزی و همکاری است در مقابل نوشتن مستقیم کد. شما باید برای مقیاس برنامهریزی کنید.
API به شرکت کمک میکند قابلیتها را تجزیه کند
API به یک شرکت اجازه میدهد قابلیتهای خدمات اصلی را به بسیاری از خدمات مستقل و خودمختار تقسیم کند. یک استراتژی API-اول به سازمانها اجازه میدهد APIهایی بسازند که به همهی برنامهها خدمت کنند، و برنامهها میتوانند به طور کارآمد برای همهی دستگاهها، پلتفرمها و سیستمعاملها توسعه و نگهداری شوند.
بنابراین، برای خلاصهسازی، مزایای یک رویکرد API-اول –
-
توسعه همزمان
-
کاهش هزینه
-
استانداردسازی
-
سرعت رسیدن به بازار
-
تجربه بهتر توسعهدهنده
-
محصولمحور
گروه حاکمیت
برای اعمال API-اول در سراسر سازمان، شما باید یک گروه حکمرانی بسازید. این گروه باید با اعضایی از مهندسی و همچنین کسبوکار ایجاد شود. این گروه در تضمین انطباق در سراسر موارد استفاده کمک خواهد کرد. گروه همچنین در اعتبارسنجی، نظارت و کشف APIها کمک خواهد کرد.
پر کردن فاصله بین کسبوکار و مهندسی
برای اینکه همهی اینها کار کند، ما باید فاصلهی بین کسبوکار و مهندسی را پر کنیم. هر دو بخش نقشهای متفاوتی برای بازی کردن دارند. بنابراین، ساخت یک API نباید ما را تقسیم کند بلکه باید ما را روی همان مفهوم اصلی برای شرکت گرد هم بیاورد. چون APIها یک محصول هستند، میتوانند ارزش مستقیم و غیرمستقیم برای کسبوکار بیاورند. این میتواند با باز کردن APIها برای مشتریان و بازارهای جدید انجام شود. شما میتوانید یک استراتژی کسب درآمد داشته باشید. برای دریافت مزایای بیشتر، شما به دادههای بیشتر از شرکتهای مشتری دیگر نیاز دارید. این به شما کمک خواهد کرد کسبوکارهای دیگر را قادر سازید از APIهای شما استفاده کنند.
طرف مهندسی باید دادههایی برای کسبوکار دربارهی APIها ارائه دهد. آنها باید نسبت به تحلیلها و مشاهدهپذیری فعال باشند. با ساخت یک صدا روی پروژهی ما درباره استفاده از API، میتوانیم یک جامعه بهتر در داخل شرکت بسازیم. در سمت مهندسی، مهم است که دربارهی موفقیت و شکست شفاف باشید. نباید پیچیدگیهای درگیر در ایجاد API را پنهان کنید.
کسبوکار باید بازخورد را برای بخش مهندسی در سریعترین زمان ممکن ارائه دهد. پیشنهادات و ایدههای جدید باید از همان ابتدا با تیم فنی (مهندسی) مورد بحث قرار گیرند تا روی امکانپذیری، پیچیدگی، تغییرات و غیره کار شود. تیم کسبوکار باید به طور فعال در تست شرکت کند و زمان برای یادگیری دربارهی APIها سرمایهگذاری کند.
قرارداد API به عنوان یک محصول
بنابراین، برای پر کردن فاصله بین مهندسی و کسبوکار، قرارداد API باید به عنوان یک محصول در نظر گرفته شود. قرارداد باید همراه با کسبوکار ساخته شود تا امکان اشتراکگذاری دانش وجود داشته باشد. هر دو تیم دربارهی مورد استفادهای که برای آن API ساخته میشود، واضح هستند. ویژگیهای جدید نیز میتوانند در این مرحله مورد بحث قرار گیرند. کسبوکار باید محصول نهایی را اعتبارسنجی کند، بنابراین کسبوکار باید از همان ابتدا در تست شرکت کند، از ایجاد موارد تست و کمک با دادههای تست.
