حاکمیت API چارچوبی از سیاستها، فرایندها و رویهها است که سازمانها برای اطمینان از اینکه APIهای آنها بهصورت سازگار، امن و کارآمد و همسو با اهداف کسبوکار و معماری کسبوکار طراحی، توسعه و مدیریت میشوند، پیادهسازی میکنند.
حاکمیت API سه تأثیر مثبت دارد:
- این کار به سازمانها کمک میکند ارزشهای خود و اینکه این ارزشها چگونه بر اکوسیستمها و افرادی که به آنها خدمت میکنند تأثیر میگذارند را تعریف کنند.
- این یک تقویتکننده نیرو است، بهطوریکه کار تیم ارائهدهنده API تأثیر مثبتی بر مصرفکنندگان API دارد – بر سازمانهایی که از API استفاده میکنند، توسعهدهندگان فردی که از آن استفاده میکنند، مدیران محصولی که از آن بهره میبرند و موارد دیگر.
- این کار فرصتهایی برای مربیگری ایجاد میکند که منجر به رشد شغلی فردی میشود، زیرا حاکمیت به افراد کمک میکند درک عمیقتری از APIها و پویایی آنها به دست آورند.
پنج توصیه برای دستیابی به یک پلتفرم API تحولآفرین
وقتی شیوهها را اختیاری میکنید، در را به روی ناهماهنگی باز میکنید. شما خطر ارائه چیز اشتباه به روش اشتباه در زمان اشتباه را میپذیرید. تنوع قطعاً خوب است، اما شما به یک رویه یا استاندارد اصلی نیاز دارید. سپس میتوانید رویههای ثانویه را برای تطبیق با موقعیتهای رایج پیادهسازی کنید، همراه با راهنمایی شفاف که از افتادن تیمها در دام فلج تحلیلی جلوگیری کند.
از نظر راهنمایی استاندارد، پنج توصیه زیر میتوانند شما را در دستیابی به یک پلتفرم API تحولآفرین پشتیبانی کنند:
- همراستا شدن با معماری کسبوکار
- ایجاد مدلهای تعامل متعدد
- مقیاسدادن تلاشها با مربیان API فدرهشده
- همکاری با سایر حوزههای عملی
- ایجاد ستونهای API
- بیایید هر یک از این موارد را کمی باز کنیم.
همراستا شدن با معماری کسبوکار
سیاستها و شیوههای حاکمیتی میتوانند واقعاً اثربخشی کسبوکار را هدایت کنند، بنابراین همراستا کردن تلاشهای حاکمیتی با اهداف و معماری کسبوکار حیاتی است.
APIها دروازههای دیجیتال به درون سازمان شما هستند، چه این دروازهها خارجی باشند و چه دروازههای داخلی به یک حوزه دامنه خاص یا یک خط کسبوکار. این بدان معناست که پلتفرم API شما باید قابلیتهای فناوری اطلاعات شما را با قابلیتهای کسبوکار بازارمحور شما ترکیب کند.
اینجا زمان آن است که به مصرفکنندگان API خود فکر کنید. مصرفکنندگان شما اهمیتی نمیدهند که آیا شما از Kafka استفاده میکنید یا نه، یا از چه نوع پایگاه دادهای استفاده میکنید، یا مدل داده شما چگونه است. آنچه آنها میخواهند این است که بتوانند با پلتفرم API شما تعامل داشته باشند و بهصورت دیجیتال تحویل دهند، چه به شکل خودکار و چه به شکل هدایتشده. آنها تجربههایی میخواهند که قابلیتهای کسبوکار شما را به قابلیتهای پلتفرمی تبدیل کند.
حاکمیت شما میتواند این را هدایت کند. برای اینکه چنین شود، باید به پلتفرم API خود نگاه کنید و فکر کنید چگونه میتوانید کسبوکار خود را بهصورت APIها بیان کنید – بهعنوان یک توپولوژی از قابلیتهای مختلف.
میتوانید از حاکمیت خود برای تعریف این ساختار استفاده کنید، با نگاشت یک ردهبندی دامنه به مسیرها در دروازه API خود و گروهبندی موارد با یکدیگر. برای استفاده از یک مثال بسیار ساده، اگر شما یک کسبوکار بیمه داشتید، میتوانستید حداقل یک API برای خرید و قیمتگذاری، یکی برای مدیریت بیمهنامه، یکی برای مدیریت حساب مشتری و غیره ایجاد کنید. سپس این APIها خدماتی در پشت خود خواهند داشت که پیچیدگی را تجزیه میکنند، گردشهای کاری را هماهنگ میکنند و غیره.
فکر کردن به توپولوژی – معماری کسبوکار – همچنین مستلزم فکر کردن به این است که باید از کدام اکوسیستمهای دیجیتال، شرکا، مشتریان، اعضای نیروی کار داخلی، خودکارسازیهای داخلی و غیره پشتیبانی کنید. شما باید در نظر بگیرید که همه آنها چگونه در استفاده از آن APIها مشارکت میکنند، چه از طریق یک برنامه وب، برنامه موبایل یا روشهای دیگر. اگر شما یک کسبوکار تحت مقررات هستید، برای مثال در بخش بانکی، همچنین باید به قابلیت همکاری مصرفکننده و قابلیت انتقال داده فکر کنید، همراه با شرکا، اکوسیستمهای نیروی کار و شاید حتی اکوسیستمهای ارائهدهندگان خدمات. حاکمیت شما باید همه این موارد را در نظر بگیرد.
در اصل، شما باید قابلیتهای دیجیتالی که نیاز به ارائه آنها دارید را درک کنید، آنها را به مراحل تقسیم کنید و سپس یک چرخه عمر API ایجاد کنید که طراحی میکند، تحویل میدهد، اصلاح میکند، بازخورد میگیرد و آن را در طول زمان رشد میدهد. این درباره همراستا کردن معماری کسبوکار و اکوسیستمهای دیجیتال شما و سپس نهادینهکردن آن در حاکمیت شما است.
ایجاد مدلهای تعامل متعدد
راههای مختلفی وجود دارد که میتوانید از طریق آنها با تیمها پیرامون حاکمیت API تعامل داشته باشید، با استفاده از راهحلهای متفاوت برای رسیدگی به پرسشها و بازخوردها با سطوح مختلف پیچیدگی. برای مثال، Microsoft Teams یا Slack ممکن است برای پرسشهای سریع حاکمیتی مناسب باشند، در حالی که زمانهای مشخص برای جلسات گفتوگو ممکن است برای پرسشهای پیچیدهتر بهتر عمل کنند. با عمیقتر شدن سرمایهگذاری شما، ممکن است به جلسات مربیگری یا حتی یک رویکرد «دستکش سفید» نیاز داشته باشید، مانند یک مجموعه تسهیلشده از جلسات طراحی که به تیمها کمک میکند این چرخه عمر را طی کنند و فرایندها و استانداردهای حاکمیتی را بهطور مناسب اعمال کنند.
مقیاسدادن تلاشها با مربیان API فدرهشده
مقیاسدادن این موضوع به ایده یک برنامه مربی API فدرهشده منجر میشود. این با مدیریت API فدرهشده همراستا است؛ شما میتوانید حاکمیت و توانمندسازی را بهطور همزمان فدره کنید. این شما را از وضعیتی که همه پرسشها به یک تیم یا منبع هدایت میشود، به وضعیتی منتقل میکند که یک گروه متمرکز وجود دارد که میتواند تصمیمهایی بگیرد که بازتابدهنده کل کسبوکار است: یک مدل فدراسیونی.
فدراسیونسازی در اینجا ضروری است، زیرا یک مدل تیم توزیعشده در سطح سازمانی کار نخواهد کرد. شما در نهایت با تیمهای حاکمیتی توزیعشدهای روبهرو میشوید که هر کدام رویکردهای خود را دارند و این منجر به نبود سازگاری میشود. برای مثال، تیمهای مختلف بهطور متفاوتی به مجوزدهی نزدیک خواهند شد.
فدراسیونسازی به این معناست که میتوانید مربیانی داشته باشید که نماینده یا رابط با نهاد مرکزی حاکمیت شما باشند – مرکز تعالی API (COE) در نمودار بالا. شما میتوانید مربیان را در دامنههای مختلف کسبوکار مستقر کنید، با هر نسبتی که متناسب با اندازه کسبوکار و سطح تجربه تیمهای شما باشد. این رویکرد برنامه 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 خود باید به آنها فکر کنید. آنها به شما کمک میکنند ستونها و سیاستهای خود را بهگونهای تعریف کنید که انتظارات را مشخص کرده و یک چارچوب تصمیمگیری فراهم کند. بنابراین زمانی که تیمهای تحویل شما تلاش میکنند تشخیص دهند چه چیزی با اهداف کسبوکار شما همراستا است، این ستونها و سیاستها آن تصمیمها را هدایت خواهند کرد. آنها به تیمهای شما امکان میدهند همزمان با مقیاسگرفتن کسبوکار، راه رفتن، دویدن و پرواز کردن را تجربه کنند.
