این نوشته بخش هفتم (مشاهده بخش ششم) از یک مجموعه هشت قسمتی تحت عنوان «سازمان دهی اَپی در مدل تجاری , مدل‌های سازمان دهی در بخش های عمومی و خصوصی» توسط دپارتمان امور سربازان بازنشسته» نگاشته شده است.
این پروژه به دنبال بررسی اجمالی در مورد سازمان دهی اَپی در مدل تجاری و سیاست گذاری اَپی (API) و کمک به درک بهتر برای تبیین بهترین راهکار های عملی بخش های عمومی و خصوصی می‌باشد.
همچنین بطور خاص جهت اولویت بندی ساخت اَپی‌ها، و استانداردهایی برای اینکه کدام اَپی‌ها ساخته شوند، و از طرفی در دسترس قرار دادن اَپی‌ها جهت استفاده کاربر نهایی خارج از سازمان تولید شده است.
سازمان دهی اَپی در مدل تجاری
.
این مقاله، تحقیقات انجام شده توسط آنالیز صنعتی API Evangelist ، در کنار مصاحبه‌های تلفنی انجام شده توسط Skylight Digital با متخصصین حوزه اَپی (API) سازمان‌ها و موسسات بزرگی که سازمان دهی اَپی در مدل تجاری و سیاست گذاری اَپی (API) را در بخش‌های عمومی و خصوصی بر عهده دارند، گردآوری شده است.
مدل‌های سازمان دهی برای اَپی در بخش های خصوصی و عمومی (بخش هفتم)
.
ما این گزارش را به منظور بازتاب مکالمات مصاحبه‌های انجام شده با رهبران حوزه جمع آوری کردیم، تا راهنمای قدم به قدمی در مورد انواع نقش‌ها و معماری‌های نرم افزاری بکارگرفته شده جهت سازماندهی در سازمان‌های بزرگ باشد. سپس به بررسی دقیق سازماندهی به عنوان عامل شناسایی اَپی‌های بالقوه، ایجاد استانداردهایی در رابطه با ساخت اَپی‌ها، چگونگی ساخت آنها توسط سازمان‌ها و همچنین چگونگی معرفی آنها به مشتریانشان، خواهیم پرداخت.
در انتها این مقاله را با جمع بندی جزئیات سازماندهی رسمی اَپی (API)، و همچنین اقرار به اینکه درحال حاضر بیشتر سیاست‌های ساخت اَپی‌ها اغلب از ابتدا به درستی طرح ریزی نشده اند، به پایان خواهیم برد. این جمع بندی شامل شرح کامل نحوه سازماندهی های اَپی (API) به همراه لیستی از عناصری که می‌توانند به سازمان دهی اَپی در مدل تجاری در شرکت های بزرگ کمک کنند، خواهد بود.
ایجاد سازمان دهی اَپی در مدل تجاری (API)
.
تا به حال فقط در مورد مسائلی صحبت کردیم که باید در رابطه با شکل کلی سازماندهی یک پلتفرم اَپی (API) درنظر گرفته شوند، درحالی که تمرکزشان فقط در زمینه ساخت اَپی بوده است. حال در این بخش به موضوعاتی می‌پردازیم که بطور خاص برای سازماندهی اَپی (API)، و کارهایی که تیم‌ها برای سازماندهی اَپی در میان تیم‌ها، پروژه‌ها، و چرخه حیات عملیاتشان انجام می‌دهند، مربوط هستند.
همچنین حوزه‌هایی را معرفی می‌کنیم که به گروه‌هایی مربوط می‌شوند که در حال تشکیل سازماندهی برای سازمانشان هستند.
ساختار
.
وجود ساختار و تیم مخصوص برای پیشبرد سازماندهی در یک شرکت، یکی از مؤلفه‌های اصلی سازماندهی اَپی (API) در سازمانهایی است که مدتها در حال سازماندهی بوده‌اند و سرمایه‌گذاری عظیمی در این موضوع انجام داده‌اند. اگرچه این ساختارهای سازمانی اغلب با نام‌های گوناگونی شناخته می‌شوند، بعضی از عناصر مشترک بین آنها قابل معرفی می‌باشند.
- سازمان – تأسیس یک سازمان رسمی داخل شرکت، مخصوص زیرساخت اَپی (API) و توسعه‌ی راهکاری عملیاتی برای سازماندهی و استراتژی مشترک بین تمامی تیم‌ها.
- تیم اصلی – شروع با تیم اصلی کوچکی که تمرکز آن بر روی استراتژی و سازماندهی اَپی (API) باشد، سپس گسترش و رشد آن تیم تا حد لازم و متناسب با اندازه سازمان.
- تیم فعالسازی – تشکیل یک تیم فعالسازی، بطوریکه اختیار این را داشته باشند که به سراغ تک تک تیم‌ها رفته و در بهبود سلامت چرخه حیات اَپی، و رسیدن به اهداف سازماندهی به آنها کمک کنند.
- هیئت مشاوره – توسعه یک هیئت مشاوره از افراد درون یا بیرون سازمانی، که بطور مداوم در مورد استراتژی اَپی (API) اعمال نظر کرده، و به پیشبرد مسائل مربوط به سازماندهی کمک کنند.
- خط مشی – شرکت دادن تیم خط مشی در استراتژی و سازماندهی اَپی (API)، برای حصول اطمینان از حفظ خط مشی کلی شرکت در مسیر پیشرفت قرار دارد.
انواع مختلفی از نحوه سازماندهی تیم‌های اَپی (API) توسط سازمان‌ها وجود دارد، برخی از آنها راهکارهای متمرکز و برخی دیگر راهکارهای غیرمتمرکز و البته سازمانی‌تر هستند، بعضی از آنها مستقیما توسط مدیر ارشد اطلاعاتی (CIO) و مدیر ارشد فنی (CTO) و بعضی دیگر بطور سازمان‌یافته تر، جهت نشان دادن شدت و لحن مباحثه در انواع مختلف سازمان‌ها شکل گرفته‌اند.
راهکار
.
همانطور که راهکارهایی که برای اجرا و ایجاد دید سازماندهی اپی (API) در میان شرکت‌های مختلف وجود دارند، راهکارها و راهنمایی‌های عملیاتی نیز برای نحوه پیاده سازی آنها وجود دارند، که بعضی از عناصر کلیدی لازم برای ایجاد استراتژی و به حرکت درآودن آن در سازمان‌ها را برای شرکت‌ها ارائه می‌کنند.
- ساده شروع کردن – ساده نگه داشتن مسائل در هنگام شروع تا حد ممکن. سنگ بزرگ برنداشتن و قول‌های غیرممکن ندادن. شروع با مسائل ساده و اساسی، دریافت قول و قرارها و مشارکت‌های لازم، سپس پیشبرد منطقی کارها.
- بی‌میل نبودن – اجتناب از بی‌میلی نسبت به ساز و کارهای سازماندهی و اجرای آنها. بطور مکرر اذعان شده است که انجام کارها با بی‌میلی، نتایج معکوس زیادی در پی داشته و ممکن است بطور قابل توجهی باعث عقب افتادن کارها شود.
- تعریف درون‌خطی – فراهم آوردن راهنمایی و آموزش‌های درون‌خطی. از افراد توقع نداشته باشید با خواندن راهنماهای سازماندهی، از همان ابتدا بطور کامل متوجه همه مسائل شوند. اطلاعات را در فواصل زمانی منظم و از طریق کانال‌های اطلاعاتی که در حال حاضر مورد استفاده هستند در اختیار آنها قرار دهید. مانند کانال‌های ارتباطی شرکت، محیط‌های توسعه مجتمع (IDE)، و دیگر ورودی‌های مورد استفاده.
- داشتن مجوز – در مورد داشتن مجوزی برای سازماندهی بخوبی تعمق کنید. برخی افراد معتقدند، با توجه به اثر منفی که یک مجوز ممکن است بر پذیرش و مشارکت داشته باشد، ارائه به‌عنوان ماموریت بهتر از مجوز است.
- انتخاب الزامات – در مورد چگونگی تاکید بر سازماندهی در انجام امور خلاقیت به خرج دهید. در مورد اینکه جایی که کاربران را مجبور به رعایت سازماندهی‌ها می‌کنید بسیار گزینشی عمل کنید، و راه‌های الهام بخش و انگیزشی برای الزام سازماندهی پیدا کرده، و بجای تنبیه کردن، بیشتر مشوق باشید.
- ایجاد انجمن – تلاش برای ایجاد انجمنی حول سازمان استراتژی و سازماندهی اَپی (API)، چراکه باعث ایجاد روابط بین تیم‌ها، جذب حامیان، و آموزش و تمرین مداوم می‌شود.
- ایجاد ارتباط – اختصاص وقت مناسب به تماس با ذینفعان داخل شرکت، شرکا، و همینطور در زمان مناسب عموم. و از همه مهم‌تر، ایجاد ارتباط با مدیریت و رهبران.
بدین شکل، از گروهی متشکل از اسم‌ها، به راهکاری ساخت‌یافته و جهت دار گذر می‌کنیم که برای اجرای سازماندهی اَپی (API) در یک سازمان بطور روزانه، هفتگی، ماهانه، فصلی، و سالیانه شکل گرفته است. و تلاش حساب‌شده ای در راستای سازماندهی اَپی شکل داده، اثر آن بر روی گروه‌ها را سنجیده، و در صورت لزوم آن را تغییر داده و تکامل می‌کنیم. همچنین در طول زمان راهکار قابل اندازه گیری و مطمئنی در راستای درک این موضوع که چه مسائلی بر چابکی و انعطاف سازماندهی اَپی (API) موثر هستند ارائه می‌دهیم.
فناوری
.
در ادامه‌ی صحبت‌هایی که در بخش‌های گذشته در مورد فناوری‌های مورد استفاده داشتیم، مجددا نگاهی به اینکه این فناوری‌ها به طور خاص چگونه در تعریف، اندازه گیری و گزارش‌ها اثر دارند، خواهیم داشت. همچنین راهکارهای بخصوص فناوری که شرکت ها برای درک و التزام سازماندهی‌هایشان استفاده می‌کنند را مورد بررسی قرار می‌دهیم.
- تعاریف – استفاده از OpenAPI، کالکشن‌های Postman، شماتیک JSON، و دیگر موارد قابل خواندن توسط ماشین که در طول مراحل چرخه حیات اَپی (API)، و برای تعیین کمیت، اندازه گیری و تهیه گزارشات در مورد اینکه سازماندهی با چه کیفیتی ایجاد شده است.
- سوییچ اَپی (API) – لایه سوییچ امکانات مناسبی برای اجرای سیاست‌ها، محدودیت‌ها، واقعه نگاری، و عملکرد هر اَپی، در اختیارمان قرار می‌دهد. همچنین این لایه نقطه‌ی ورودی تمامی سرویس‌ها محسوب شده و امکان تبدیل و ترجمه را برای آنها فراهم می‌سازد. از این لایه می‌توان برای درک رفتار مصرف‌کننده‌ها، و در عین حال رفتار ناشران، سرویس‌دهندگان و توسعه‌دهندگان استفاده شود. بعلاوه این لایه فرصت مناسبی برای اعمال سازماندهی و کیفیت سنجی اعمال آن در سازمان بوجود می‌آورد.
- واقعه نگاری – واقعه‌نگاری‌های متمرکز، مهمترین راه سنجش برای سازماندهی و تهیه گزارشات مربوط به نحوه انجام امور در پلتفرم سازمان خواهد بود. بدون یک ساز و کار واقعه نگاری متمرکز، اجرای سازماندهی بصورت کورکورانه بوده و قادر به اجرای صحیح برای سرویسی که برای آن در نظر گفته شده است نخواهد بود.
- نظارت – در نظر گرفتن نظارت به عنوان یک پیشفرض برای تمامی سرویس‌ها. ردگیری همه سرویس‌ها از نقاط مختلف و اطمینان از اینکه آنها تفاهم‌نامه‌های سطح کیفی خدمات را برآورده می‌کنند. که معیاری است برای دانستن اینکه آیا سازماندهی بطور موثری بر تمامی سرویس‌ها اعمال شده است یا خیر.
- تست – تمرکز بیشتر بر تک تک بر اَپی‌ها، و اطمینان از اینکه اَپی‌ها کاری که باید را انجام می‌دهند. اتخاذ اظهارات کاملا حرفه‌ای و قرار دادن آنها در برابر اپی‌ها توسط تست‌های تعریف شده توسط ماشین، بطور زمان بندی شده و با قابلیت انجام بلادرنگ.
- امنیت – گردآوری تمام داده‌های ممکن در مورد چگونگی اعمال امنیت و نتایج اسکن‌ها، نظارت‌ها، واقعه نگاری‌ها، و احراز هویت‌ها در checkpointهای امنیتی.
- گزارشات – دادن اجازه تولید گزارش به لایه‌های سوییچ، نظارت، تست و دیگر فناوری‌ها، در مورد اینکه معیارهای سازماندهی با چه کیفیتی برآورده شده اند. بدین صورت این امکان برای فناوری‌ها فراهم می‌شود که اندازه‌گیری‌های لازم را انجام داده و همچنین گزارشاتی را در مورد ارقام مختلف فراهم کنند که بتوان طبق آن مجموعه واحدی از گزارشات گردآوری کرد، تا درک درستی از اثرات تلاش برای سازماندهی ایجاد کند.
درهنگام اتخاذ هر تصمیم در مورد اینکه از چه فناوری برای ایجاد زیرساخت اَپی (API) استفاده کنیم، باید نقش آن در استراتژی سازماندهی در نظر گرفته شود. داشتن سرویس‌ها و ابزار درون‌خطی که قابلیت اجرا و گزارشگیری از سازماندهی را داشته باشند، جنبه‌ی مهمی از قابلیت پیشبرد سازماندهی برای شرکت خواهد بود.
احتمال اینکه یک سازماندهی درونی شده قابلیت اجرایی داشته باشد، بسیار بیشتر از یک ساز و کار فرمایشی ثبت و گزارش خواهد بود.
چالش‌ها
.
همه سازمان‌های مورد مصاحبه، دغدغه‌ها و مسائل مشترکی در مورد چالش‌های پیش رو داشتند. بسیاری از آنها در بخش بالا وجود داشتند، ولی در اینجا ما قصد داریم بر چالش‌ها در پیاده سازی واقعی سازماندهی تمرکز کنیم، و نگاهی داشته باشیم به راه‌حل‌هایی که گروه‌ها برای مقابله با این چالش‌ها و سدها پیدا کرده‌اند.
همکاری در ساخت
.
سازمانهایی که به تنهایی به سازماندهی اپی (API) پرداختند، در ادامه نیزتنها ماندند، و گروه‌هایی که در ایجاد استراتژی با دیگر تیم‌ها همکاری کردند، و در راستای به اشتراک‌گذاری مالکیت خود نسبت به استراتژی، اجرا، و نقشه راه کوشش به خرج دادند، در دستیابی به هدف خود بسیار موفق‌تر بودند.
پذیرش
.
جلب پذیرش از همه تیم‌ها، امری دشوار بوده، و بسیاری افراد سختی‌های مورد پذیرش قرار گرفتن راهکارهای سازماندهی متمرکز، و حتی سازماندهی‌های توزیع‌شده را عنوان کرده‌اند. مورد پذیرش قرار نگرفتن از سمت بعضی گروه‌ها یا مدیریت، باعث دشوار شدن پیشبرد سازماندهی می‌شود.
استانداردها
.
اگرچه بسیاری نظر مثبتی نسبت به داشتن استاندارد دارند، در عمل ثابت شده است که وادار کردن افراد به سازگاری، استفاده و تشخیص فواید رعایت استانداردها در تمام مراحل چرخه حیات اَپی (API)، امر آسانی نخواهد بود.
قطعات
.
عدم تفاهم در مورد اینکه قطعات تعیین کننده سازماندهی، مانند راهنماها، نمونه‌های اولیه، و دیگر راهکارهای معمول، واجب هستند. بعضی تیم‌ها این قطعات را بی‌اهمیت دانسته، زمان و انرژی مورد نیاز برای ایجاد آنها را زیر سوال می‌برند. درحالیکه دیگران بطور قاطع این قطعات را لازم و ضروری می‌دانستند.
دشواری فرایند
.
تیم‌های اَپی (API) بارها و بارها اذعان کردند که سازماندهی، و اعمال متداوم آن در طی چرخه حیات اَپی، فرایند دشواری است. البته برنامه‌ریزی برای این استراتژی امر آسانی به نظر می‌آید، ولی در عمل هرگز کارها آنطور که از قبل تصور شده ساده نخواهند بود.
فرایند پالایش
.
نیاز مداوم به پالایش، بهبود، حذف، تغییر و تبدیل راهکار استراتژی سازمان دهی، تا وقتی که راه‌حل مناسب برای جنبه‌های روزافزون ساخت اَپی (API) پیدا شود.
وقت‌گیر بودن
.
همه این امور، وقت گیر خواهند بود. باید صبور باشید، طولانی مدت فکر کنید، و بدانید که دیدن تغییری که از ابتدا تصور آن را دارید بیش از چیزی که فکر می‌کنید زمان خواهد برد.
در مورد سازمان دهی اَپی در مدل تجاری زیرساخت‌های وسیع و پیچیده اَپی (API)، همواره چالش‌های بیشتری بر سر راه قرار خواهد داشت. چالش‌ها، سدها و اصطکاک‌ها در تمامی مراحل استانداردسازی چگونگی ساخت اَپی‌ها در سازمان دیده می‌شوند. فائق آمدن بر شکست‌ها و تشخیص چالش‌ها و احتمال تبدیل شدن آنها به سد، امر بسیار مهمی در ایجاد هرگونه پیشرفتی خواهد بود.
منتظر قسمت نهایی با عنوان «مسیر سازمان دهی اَپی» باشید.