چرا ممکن است به یک مدیر ارشد API نیاز داشته باشید؟

APIها بخش زیادی از وب مدرن را هدایت می‌کنند. تقریباً هر تعامل، بزرگ و کوچک، در نهایت با یک API شروع و پایان می‌یابد. متأسفانه، این رابط‌ها اغلب در نوعی حوزهٔ سایه برای بسیاری از سازمان‌ها وجود دارند، بدون خط مالکیت مشخص یا ساختار فوقانی برای اعتماد، شفافیت و درک.

در ادامه، درباره اهمیت درک APIها و اینکه چرا رهبری سازمان باید به حاکمیت آن‌ها اهمیت دهد صحبت می‌کنیم. همچنین بررسی می‌کنیم که چرا این موضوع در سطح مدیران اجرایی اهمیت دارد و یک نقش جدید مدیر ارشد API (یا رابط) معرفی خواهیم کرد.

API چیست؟

رابط برنامه‌نویسی کاربردی (API) یک مؤلفه است که سیستم‌ها و برنامه‌های مختلف را از طریق یک مجموعهٔ مشترک از استانداردها، پروتکل‌ها و قوانین به هم متصل می‌کند. در اصل، این یک قرارداد بین دو سیستم دربارهٔ نحوهٔ ادغام آن‌ها است. در حالی که این رابط به‌عنوان یک کد با دستورالعمل‌های ترجمه وجود دارد، طراحی این رابط اغلب بازتاب‌دهندهٔ استانداردهای داده، کنترل‌ها، فرضیات، حالت‌های طراحی، و روح کلی تیم توسعه و پایگاه کاربری است.

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

ارز ارتباطات

اکنون ممکن است این سؤال پیش بیاید: چرا مهم است که همهٔ افراد سازمان از APIها آگاه باشند؟ به‌هرحال، آن‌ها ماهیت فنی دارند، پس فقط «فنی‌ها» باید آن‌ها را بشناسند. و مگر اینکه در فروش باشید، لازم نیست تمام جزئیات چیزی که سازمانتان می‌فروشد را بدانید. درست است؟

این نوع طرز فکر یک نکتهٔ بسیار مهم را نادیده می‌گیرد: در زمینهٔ توسعهٔ API و تجربهٔ کاربر نهایی، ارتباطات حیاتی است. ارتباطات مناسب می‌تواند در بلندمدت مزایای عظیمی را برای سازمان باز کند، و ارتباط ضعیف می‌تواند در بسیاری از موارد یک عامل شکست برای سلامت سازمانی باشد.

واقعیت این است که APIها بدون سه عنصر اصلی نمی‌توانند کار کنند: اعتماد، شفافیت، و درک. بدون اعتماد، نمی‌توانید کاربران را برای پذیرش محصول خود متقاعد کنید، و بدون کاربر، هیچ مدل کسب‌وکار پایداری وجود نخواهد داشت. بدون شفافیت، کاربران نمی‌توانند بفهمند محصول شما چگونه کار می‌کند. نهایتاً، بدون درک، توسعه‌دهندگان محصول را اشتباه استفاده خواهند کرد و در نهایت درک درستی از سناریوی استفاده نخواهند داشت.

آگاهی اجرایی پیرامون APIها

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

رابط‌های فنی ممکن است برای مدیران «بیش از حد تاکتیکی» به‌نظر برسند. بااین‌حال، نبود دید نسبت به مزایایی که APIها ارائه می‌دهند می‌تواند بسیار مخرب باشد. این موضوع همچنین پیچیده است، زیرا موفقیت API معمولاً در مقیاس سال‌ها سنجیده می‌شود، و نیازمند توانایی تاکتیکی فوری و تفکر استراتژیک بلندمدت است. بنابراین، داشتن یک نقش واحد که مالک موفقیت ابتکارهای API باشد و در عین حال این دو هدف را به هم پیوند دهد، به‌طور فزاینده‌ای مهم می‌شود. این را از دیوید بیساک، مدیر ارشد API در Apiture در نظر بگیرید:

«ما همه می‌دانیم که APIها چقدر برای استراتژی‌های سازمان‌های دیجیتال حیاتی شده‌اند. سپردن مسئولیت اجرای آن استراتژی و چشم‌انداز API به یک فرد می‌تواند به سازمان کمک کند تا تمرکز کرده و موفقیت را به‌دست آورد. از آنجا که APIها قراردادهای نرم‌افزاری رو‌به‌خارج هستند (هستهٔ مشارکت‌ها و یکپارچگی‌ها) و چرخه‌های عمرشان در مقیاس سال یا دهه اندازه‌گیری می‌شود، معماری و تکامل آن‌ها نیازمند رویکردی متفاوت نسبت به پیاده‌سازی‌های نرم‌افزاری سنتی است.»

چگونه رهبری می‌تواند تجربهٔ توسعه‌دهنده را هدایت کند

این موضوع در همین‌جا متوقف نمی‌شود. بسیاری از چشم‌اندازهای استراتژیک ممکن است به‌دلیل تمرکز تاکتیکی نادیده گرفته شوند. فرض کنید شما توسعه‌دهنده‌ای هستید که روی تجربهٔ خوش‌آمدگویی برای کاربران توسعه‌دهنده کار می‌کنید. ممکن است متقاعد شوید که نیاز دارید یک سیستم راهنمای جامع و دقیق با فرصت‌هایی برای بررسی عمیق هر موضوع در هر نقطه طراحی کنید.

بااین‌حال، رهبری ممکن است بداند که قیف خوش‌آمدگویی باید کاربران جدید را در اولویت قرار دهد، زیرا داده‌ها نشان می‌دهد این گروه بیشترین نیاز را دارد. در زمینهٔ اتخاذ تصمیمات مالی درست، این به‌معنای نیاز تجربهٔ توسعه‌دهنده به پشتیبانی است — اما به شکلی کاملاً متفاوت و استراتژیک‌تر نسبت به طرح تاکتیکی.

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

سازگاری، نه کنترل: تکامل کسب‌وکار

همان‌طور که از این مثال‌ها می‌بینید، مشکل واقعی به دو حوزه بازمی‌گردد: ناتوانی در سازگاری و نبود زمینه برای هدایت سازگاری. دنیای کسب‌وکار تغییر می‌کند، و اغلب به‌سرعت. کریستوف ون توم، هم‌بنیان‌گذار و مدیرعامل Pronovix، که دربارهٔ ضرورت مدیران ارشد رابط نوشته است، چنین گفته:

«در چشم‌انداز پویای کسب‌وکار امروز، جایی که تغییر تنها ثابت است، تجمل برنامه‌ریزی و کنترل کامل یک ندرت است. نبوغ طبیعت در اکوسیستم‌های سازگار آن نهفته است، جایی که سیستم‌های فرعی بی‌شمار از طریق مجموعهٔ کوچکی از رابط‌های کاملاً حفظ‌شده باهم تعامل می‌کنند. در قلمرو شتابان و پیچیدهٔ دنیای سازمانی، سازمان‌ها باید از کتاب بازی طبیعت الهام بگیرند تا رشد کنند. همان‌طور که سیستم‌های زنده به رابط‌های خوب طراحی‌شده متکی هستند، کسب‌وکارها نیز باید طراحی رابط را به‌عنوان یک اهرم حیاتی برای تضمین انسجام و موفقیت در اولویت قرار دهند.»

به بیان ساده، کسب‌وکارها باید به‌طور مداوم تکامل یابند تا جلوتر از منحنی بمانند و پیشنهادات پیشرفته ارائه دهند. تنها راه انجام این کار داشتن تفکر آینده‌نگر است، و این بدون سرمایه‌گذاری قابل توجه در درک وضعیت فعلی امکان‌پذیر نیست. سازمان‌ها باید درکی محکم از رابط‌هایی که مالک آن هستند و اداره می‌کنند داشته باشند — هم برای سلامت تاکتیکی فعلی و هم برای سرمایه‌گذاری استراتژیک بلندمدت.

استدلال برای مدیر ارشد API

البته، این کار آسان‌تر از گفتن آن نیست. حوزه‌های مالکیت در سطوح اجرایی اغلب فرصت‌هایی برای ایجاد سیلوها ایجاد می‌کنند که می‌تواند دود اجرایی در برابر تلاش‌های جاری باشد. پس چگونه موانع را می‌شکنیم؟

یک راه‌حل ایجاد نقشی جدید به‌عنوان مدیر ارشد API یا مدیر ارشد رابط است. این نقش عضوی از سطح C-سوت خواهد بود که یک مدافع و متخصص API در سازمان است. این شخص کمک می‌کند تا شکاف بین تاکتیک و استراتژی که پیش‌تر به آن اشاره کردیم پر شود. انسجام می‌تواند با ایجاد نقشی که می‌تواند مالکیت حوزهٔ اغلب میان‌رشته‌ای و خاکستری را برعهده گیرد، حاصل شود.

برای نقل قول دوباره از کریستوف ون توم:

«با وجود یک مدیر ارشد رابط در رأس سازمان، شرکت‌ها می‌توانند از قدرت طراحی استراتژیک رابط بهره ببرند تا به آن‌ها در پیمایش در میان بافت پیچیدهٔ چالش‌های کسب‌وکار مدرن کمک کند. […] یک مدیر ارشد رابط می‌تواند برای سازمان‌هایی که از یک استراتژی پلتفرم یا اکوسیستم استفاده می‌کنند مفید باشد، و برای سازمان‌های بزرگ‌تر که نیاز دارند این استراتژی‌ها را برای حفظ انسجام داخلی به‌کار برند، ضروری می‌شود.»

بااین‌حال، سطح مشخصی از اختیار و مالکیت باید برای اتخاذ نقش مدیر ارشد رابط ایجاد شود. این مدیران باید مالک رابط‌ها باشند و در سراسر سازمان به‌عنوان کارشناسان موضوعی عمل کنند. در حالی که لزوماً نیازی نیست که مالک تأیید یا رد هر چیزی مرتبط با رابط‌ها باشند، باید به‌طور جدی مورد مشورت قرار گیرند و توانایی «ترمز گرفتن» در مواقع لازم را داشته باشند.

یک استدلال دیگر می‌تواند مبتنی بر هزینه و پیچیدگی باشد. برای مثال، ممکن است نداشتن یک نقش واحد برای نظارت بر کل برنامهٔ API گران‌تر تمام شود. طبق گفتهٔ دیوید بیساک:

«همهٔ سازمان‌ها آن‌قدر بزرگ نیستند که بتوانند یک موقعیت اختصاصی را پرسنل‌دهی کنند. بااین‌حال، پراکندگی جنبه‌های متعدد یک برنامهٔ API میان چند نقش متفاوت می‌تواند به یک برنامهٔ API خردشده یا ناسازگار منجر شود. برای مثال، اگر امنیت API «متعلق» به مدیر ارشد امنیت اطلاعات (CISO) باشد، ممکن است اجرای یک سیاست واقعی شیفت-چپ دشوارتر شود: سیاستی که امنیت API را به یک ستون مرکزی در فرآیند طراحی API تبدیل می‌کند، جایی که بسیاری از آسیب‌پذیری‌ها می‌توانند قبل از پیاده‌سازی، آزمایش یا استقرار حذف شوند. همان‌طور که شرکت و برنامهٔ API آن رشد می‌کنند، پرسنل‌دهی یک موقعیت برای نظارت بر برنامهٔ API می‌تواند کمک کند تا هیچ جنبهٔ کلیدی از برنامهٔ API نادیده گرفته نشود، به‌ویژه در سال‌های شکل‌گیری حیاتی. یک برنامهٔ API روزبه‌روز به یک سرمایه‌گذاری ضروری تبدیل می‌شود، و عدم پشتیبانی کافی از آن، این برنامه و موفقیت شرکت را در معرض خطر قرار می‌دهد.»

نتیجه‌گیری

در نهایت، همانند هر نقش سطح C-سوت، اتخاذ یک مدیر ارشد API به‌شدت به ساختار، طراحی، و تمایل سازمان بستگی دارد. بااین‌حال، اگر این نقش در چارچوب سازمان کار کند، می‌تواند توانمندسازی و موفقیت استثنایی را در یک فرهنگ API-محور ارائه دهد و باید برای هر کسب‌وکار جدیدی که وارد این فضا می‌شود یک گزینهٔ جدی باشد.