مطالعات حاکمیت API که به درستی انجام داده شده است (Case Studies of API Governance Done Right)
حاکمیت API در نهایت نبردی بین دو قطب مخالف است. از یک سو، کنترل غیرمتمرکز وجود دارد که انعطافپذیری و سهولت توسعه را برای تیمهای توسعهدهنده کوچک و بزرگ فراهم میکند. از سوی دیگر، دستورالعملها و سیاستهای استاندارد شده وجود دارند که توسعهای امن و منطبق با قوانین را تضمین میکنند. حاکمیت یک تعادل بین این دو حد است و اغلب پیروزی یک طرف بر دیگری منبع اصلی اصطکاک است.
با این حال، برخی سازمانها در زمینه حاکمیت API مسیرهای جدیدی ایجاد کردهاند. امروز به شش نمونه از سازمانهایی میپردازیم که حاکمیت API را اعمال کرده و موفق شدند!
Atlassian
Atlassian یک سازمان غولپیکر با پرتفوی بزرگی از محصولات است. به همین دلیل، مسئله تیمهای ایزوله به شدت بر فرآیند توسعه آنها تأثیر داشت. Atlassian اغلب شاهد بود که توسعه داخلی باعث خراب شدن APIها یا توسعه بدون استاندارد میشود، که در نهایت ناسازگاری و بدهی فنی را افزایش میداد.
برای حل این مشکل، Atlassian تصمیم گرفت حاکمیت API را با ایجاد چارچوبی ساختاریافته به نام استانداردهای توسعهپذیری (Extensibility Standards) دنبال کند. این مجموعه استانداردها دستورالعملهای شفاف و مستندسازی شدهای برای طراحی و توسعه API فراهم میکند که به راحتی قابل اشتراکگذاری و مراجعه است.
با قرار دادن سند استانداردها در Bitbucket، بررسیهای خودکار با استفاده از مجموعه ابزار Spectral اجرا میشوند تا انطباق سنجیده شود. سپس گزارشها به مکانهایی مانند Confluence منتقل میشوند تا تیمها از وضعیت انطباق و نواحی غیرمنطبق که نیاز به بررسی دارند، مطلع شوند.
این فرآیند بر رویکرد پذیرش از پایین به بالا تمرکز دارد، که در آن به توسعهدهندگان ابزارها و سیستمهایی داده میشود تا استانداردها را تکرار کنند. به جای اعمال سختگیرانه قوانین، گزارشدهی امکان ایجاد فرهنگ شفافیت و آگاهی را فراهم میکند که میتوان از آن برای همترازی استانداردها بهره برد. اگرچه هنوز در مراحل ابتدایی است، این تلاشها کاهش خطاها و APIهای خراب شده و همچنین ایجاد فرهنگ همکاری بین تیمها را به همراه داشته است.
Vodafone
Vodafone نمونه عالی از ترکیب استانداردها با چارچوبها برای تضمین حاکمیت موثر API است. به عنوان یک شرکت بزرگ مخابراتی، Vodafone نیاز به راهحلی داشت که با شیوههای تجاری و فناوری خود هماهنگ باشد، که برخی از آنها بسیار متفاوت با سایر شرکتهای فناوری است.
برای استانداردسازی حاکمیت و توسعه API، Vodafone از TMF Open Digital Architecture یا TMF ODA استفاده کرد. TMF ODA مجموعهای از APIهای استاندارد شده است که میتواند برای هماهنگی توسعه بیشتر API استفاده شود و از راهحلهای باز برای بخش عمدهای از فناوری خود بهره گیرد. طبق گفته Vodafone، ترکیب آنها شامل ۷۰٪ APIهای باز و ۳۰٪ APIهای توسعه سفارشی است.
با استفاده از APIهای باز، Vodafone میتواند معماری بسیار ماژولار و انعطافپذیری برای سیستمهای داخلی خود پیاده کند و در عین حال با بهترین شیوهها و استانداردها برای توسعه سفارشی خود هماهنگ باشد.
استانداردهای باز در هسته TMF ODA امکان تعاملیت بسیار بالاتر را فراهم میکنند و اطمینان میدهند که سیستمها به طور موثر با هم کار میکنند. هماهنگی مستمر کدهای آنها با استانداردهای TMF ODA اطمینان میدهد که هر API که داخلی مطابقت دارد، با APIهای شریک TMF ODA نیز مطابقت خواهد داشت. این امر منجر به همترازی گسترده صنعتی در سراسر استانداردها شده است، از جمله قابلیتهای شبکه ۵G و تحویل داراییها و خدمات دیجیتال.
روش Facebook جالب است، زیرا حاکمیت API را از طریق ایجاد استانداردها بر اساس ماهیت هر API اعمال میکند. به عبارت دیگر، هر API در محدوده و سیاستهای حاکمیتی خود ساختار یافته و با سایر APIها احترام متقابل دارد. این “توافق حاکمیتی” اجازه میدهد APIها با یکدیگر تعامل کنند و حاکمیت کل سیستم را رعایت کنند.
در مقالهای با عنوان “API Governance: The Case of Facebook’s Evolution” توسط Fernando N. van der Vlist و همکاران، این توافق حاکمیت Facebook را از طریق APIهایش تعریف میکند.
این حاکمیت در سه سطح اصلی اعمال میشود:
-
سطح معماری: با کنترل تغییرات APIهای اصلی Facebook، این APIها میتوانند اقدامات و ساختارها را در سایر APIها از طریق برجستگی و تأثیر خود اعمال کنند.
-
سطح شیء: در سطح شیء، کاربران با ارزشهای محدود تعریف میشوند که چه کسی کاربر است، چه دادههایی دارد و چگونه میتوان بر آنها اعمال کرد، که محدودیتهای بیشتری برای APIهای مرتبط ایجاد میکند.
-
سطح مجوز: کنترلهای دسترسی دقیق که بر APIها اعمال میشوند، نحوه تعامل هر API با عناصر کل سیستم را کنترل میکنند و حاکمیت تعاملات API در مقیاس را مستقیماً اعمال میکنند.
جمعبندی این تلاشها به ایجاد یک استاندارد حاکمیت واقعی (de facto) منجر شده است، نه صرفاً یک استاندارد اعلام شده، زیرا مجموعه APIهای اصلی Facebook تأثیرگذار هستند و تنها اجازه تعامل به شکلی سازگار با استانداردهای Facebook را میدهند.
اپراتور موبایل/ثابت با Tony Harris
Tony Harris شاید مستقیمترین استراتژی حاکمیت را در یک مطالعه موردی مستندسازی کرده است. این یک نمونه کلاسیک مدیریت از بالا به پایین با رویکرد تولید است.
در اصل، یک اپراتور بزرگ مخابراتی در بریتانیا تصمیم گرفت از APIها به عنوان روشی برای تعامل با شرکا و کسبوکارها استفاده کند. چون هنوز ارائههای اصلی خود را ایجاد نکرده بود، این مشتری در موقعیت خوبی برای برنامهریزی از بالا به پایین قرار داشت. بنابراین، بلافاصله تیم حاکمیت API با Tony Harris ایجاد شد تا دستورالعملها، استانداردها و نقشه راه توسعه API را تدوین کند.
با ایجاد چارچوب، تیم API Farm ایجاد شد تا APIها را با استفاده از چیزی که Tony Harris آن را “مدل کارخانهای” مینامد تولید کند. این تیم توانست APIها را سریع توسعه، تست و مستقر کند.
تیم API Factory در نهایت بیش از پنجاه API را در شش ماه ارائه داد، موفقیتی که باعث شد ساختار کلی حاکمیت و توسعه به عنوان یک استراتژی اصلی تحول دیجیتال گسترش یابد.
Microsoft
راهحل Microsoft برای مشکل حاکمیت API یک رویکرد یکپارچه به توسعه نرمافزار است که از یک API واحد برای اتصال به سرویسها و APIهای مختلف استفاده میکند. با تعریف یک API جهانی با حاکمیت قوی، این API میتواند APIهای مرتبط با آن را استاندارد کند.
در بخش دوم، این فرآیند بیشتر تمرکز بر حاکمیت دارد. برای تسریع فرآیند حاکمیت API، Microsoft به هوش مصنوعی — به ویژه تولید تقویتشده بازیابی (RAG) متکی شد. با ایجاد قواعد حاکمیت و آموزش داخلی AI RAG روی این قواعد، زمان بررسی حاکمیت و اطمینان از انطباق حداقل ۲۰٪ کاهش یافت.
با استفاده از ابزار RAG برای مستندسازی، ایجاد حاکمیت و قدرت نرم، Microsoft میتواند به سرعت APIها را داخلی تکرار کند بدون اینکه گلوگاه بزرگی در توسعه یا تأیید ایجاد شود.
Netflix
Netflix از راهحل نوآورانهای برای حاکمیت API استفاده میکند: یک پلتفرم GraphQL فدرال. مسئله ساده است — توسعهدهندگان نیاز به انعطافپذیری سرویسهای غیر استاندارد داشتند، اما توسعهدهندگان UI ترجیح میدادند یک API واحد و یکپارچه داشته باشند.
Netflix با استفاده از GraphQL به عنوان لایه فدرال اصلی، منابع را فدرال کرد. زمانی که یک فیلم به عنوان منبع استاندارد میشود، APIهای مرتبط با آن بر اساس ماهیت منبع حاکم میشوند. این رویکرد سه جزء اصلی دارد:
۱. خدمت Domain Graph (DGS):
سرویسی برای تعریف اسکیمای فدرال GraphQL برای توسعه API توسط توسعهدهندگان.
۲. رجیستری اسکیمها:
ثبت همه اسکیمها و تغییرات آنها برای هر DGS که APIهای CRUD را ارائه میدهد.
۳. گیتوی GraphQL:
نقطه ورود پرسوجو از مصرفکننده به مجموعه DGS.
این رویکرد اجازه میدهد توسعهدهندگان Netflix از توسعه غیرمتمرکز استفاده کنند و براساس نیاز سرویس تکرار کنند. همزمان، استانداردها از طریق لایه GraphQL مرکزی حفظ میشوند، که عملکرد غیرمتمرکز و استاندارد برای مصرفکننده نهایی را ترکیب میکند.
استراتژیهای حاکمیت API
اینها برخی از مؤثرترین و جالبترین روشهای انجام صحیح حاکمیت API در دنیای سازمانی هستند. با توجه به اینکه حاکمیت تمرکز اصلی بسیاری از مهندسین امنیت و توسعهدهندگان است، داشتن مجموعهای از راهحلها برای تعادل پیچیده توسعه غیرمتمرکز و کنترل متمرکز بسیار مهم است و همچنان منبع علاقه و نوآوری خواهد بود.
