این نوشته بخش دوم (مشاهده بخش اول) از یک مجموعه هشت قسمتی و در مورد پروژه میکرومشاوره‌ای تحت عنوان «مدل‌های سازمان دهی اَپی بخش عمومی و خصوصی» توسط دپارتمان امور سربازان بازنشسته» نگاشته شده است.
این پروژه به دنبال بررسی اجمالی در مورد سیاست گذاری اَپی (API) و جهت کمک به درک، برای تبیین بهترین راهکارهای عملی اَپی بخش عمومی و خصوصی ، و بطور خاص جهت اولویت بندی به ساخت اَپی‌ها، و استانداردهایی برای اینکه کدام اَپی‌ها ساخته شوند، و در دسترس قرار دادن اَپی‌ها جهت استفاده کاربر نهایی خارج از سازمان تولید شده است.
مدل‌های سازمان دهی برای اَپی بخش عمومی و خصوصی (بخش دوم)
در این مقاله، سالیان متمادی تحقیقات انجام شده توسط آنالیز صنعتی API Evangelist ، در کنار مصاحبه‌های تلفنی انجام شده توسط Skylight Digital با متخصصین حوزه اَپی (API) سازمان‌ها و موسسات بزرگی که سیاست گذاری اَپی بخش عمومی و خصوصی بر عهده دارند، گردآوری شده است.
ما این گزارش را به منظور بازتاب مکالمات مصاحبه‌های انجام شده با رهبران حوزه جمع آوری کردیم، تا راهنمای قدم به قدمی در مورد انواع نقش‌ها و معماری‌های نرم افزاری بکارگرفته شده جهت سازمان دهی در سازمانهای بزرگ باشد.
سازمان دهی اَپی
سپس به بررسی دقیق سازمان دهی اَپی بخش عمومی و خصوصی به عنوان عامل شناسایی اَپی‌های بالقوه، ایجاد استانداردهایی در رابطه با ساخت اَپی‌ها، چگونگی ساخت آنها توسط سازمان‌ها و همچنین چگونگی معرفی کردن آنها به مشتریانشان، خواهیم پرداخت.
در انتها این مقاله را با جمع بندی جزئیات سازمان دهی اَپی (API)، و همچنین اقرار به اینکه درحال حاضر بیشتر سیاست‌های ساخت اَپی‌ها اغلب از ابتدا به درستی طرح ریزی نشده اند، به پایان خواهیم برد.
این جمع بندی شامل شرح کامل نحوه سازمان دهی اَپی بخش عمومی و خصوصی به همراه لیستی از عناصری که میتوانند به سازمان دهی اَپی (API) در شرکت‌های بزرگ کمک کنند، خواهد بود.
طراحی معماری نرم افزار
سازمان دهی به طور کلی در مورد ساختن و شکل دادن مسیری برای طراحی و معماری نرمافزار، استفاده از وب و بطور خاص اَپی (API) برای قادر ساخت وب، موبایل، ابزار و برنامه‌های کاربردی تحت شبکه است.
در مسیر ما برای شکل دادن و تکامل معماری نرم‌افزارمان، و پذیرفتن مسائلی که بر اینکه نرمافزار ما چه هست، چه کاری میکند، و درنهایت به چه چیزی تبدیل خواهد اثر دارند، الگوهای سالم، و بعضاً نه چندان سالمی میتوانند در نظر گرفته شوند.
آگاهی از حوزه
معماری نرم افزار همیشه از محیط نشأت میگیرد، و تحت تاثیر فاکتورهایی که در هر حوزهای وجود دارد، قرار میگیرد.
فاکتورهایی وجود دارند که بر حجم و چگونگی سرمایه گذاری و تعریف معماری نرم افزار در سازمانهای بزرگ تاثیر میگذارند. در اینجا برخی حوزه‌های مهم در نظر گرفته شدهاند که راجع به این هستند که چگونه حوزه ی کاری شرکت بر معماری آن تاثیر میگذارد:
منابع:
انواع منابع دیجیتالی که سازمان در حال حاضر در اختیار دارد، معماری نرمافزاری را مدیریت خواهند کرد و تعریف میکنند که معماری چگونه کار خواهد کرد، چگونه رشد و توسعه خواهد یافت و چگونه دستخوش تغییر قرار خواهد گرفت.
شِما:
شِمای موجود تعریف میکند که داده چگونه ذخیره میشود و معمولا چگونه جمعآوری و جمع‌بندی میگردد؛ حتی اگر این موضوع از طریق دیگر سیستمها بصورت یک مفهوم انتزاعی درآید، همچنان بر تصمیمهای مربوط به معماری در تمام سطوح تاثیر خواهد گذاشت.
فرایند:
فرایندهای تجاری موجود، در حال حاضر مهمترین محرک برای معماری‌های فعلی هستند، و تغییرات سریع در آنها قطعاً در تصمیمات معماری آینده بازتاب خواهد داشت.
صنعت:
فاکتورهای خارجی صنعت همواره در حال ظهور هستند تا چگونگی ساخت معماری نرمافزار را تغییر دهند و طراحی، توسعه و فاکتورهایی عملیاتی را فراهم کنند که لازم است در زمان بازسازی معماری، در نظر گرفته شوند.
مقررات :
بغیر از تاثیرات طبیعی صنعت، قوانین و مقررات و دیگر ملاحظات دولتی نیز وجود دارند که نحوهی عملکرد معماری نرمافزار را تغییر خواهند داد.
تعاریف:
در دسترس بودن و همچنین دسترسی به تعاریف، شماتیک‌ها، فرایندها و دیگر المانهای ساختاری قابل خواندن توسط ماشین، که به عنوان راهنما میتوانند به عملکرد موثرتر معماری نرمافزار کمک کنند. در صورت نبودن استاندارسازی و قابلیت انتقال، میزان اثربخشی معماری کاهش مییابد.
ساختار، آگاهی و تخصص در حوزه، معماری نرمافزار و فرایند تصمیمگیری مربوط به آن را شکل خواهند داد. این امر این ضرورت را ایجاد میکند تا در هنگام شکل دادن چشمانداز معماری سازمان، علاوه بر استفادهی حداکثری از تخصص خارجی و فروشندگان، در ظرفیت داخلی سازمان نیز سرمایهگذاری انجام شود.
بدون وجود ظرفیت داخلی مناسب، دانش حوزه میتواند حداقل شود و در نتیجه معماری کلی مربوط به زیرساخت دیجیتال را برای سازمانی که نیاز به حرکت رو به جلو دارد، تضعیف کند.
ملاحظات مربوط به نسخه های قدیمی
در زمان تصمیم گیریها برای معماری نرم افزاری، ما هیچگاه نمیتوانیم گذشته و تصمیماتی که گرفتهایم را نادیده بگیریم. مهم است که نسخههای قدیمی را به عنوان موضوعی منفی نبینیم بلکه به آن به عنوان سازه‌ای تاریخی نگاه کنیم که باید رو به جلو حرکت کند.
شاید لازم نباشد که دقیقاً از همان کد قدیمی همواره در مسیر پیش رویمان استفاده کنیم، اما تجربه، دانش و درسهایی که از نسخههای قدیمی سازمان یاد گرفتهایم، باید به نمایش گذاشته شود.
در ادامه تعداد انگشت شماری از ملاحظات مربوط به نسخههای قدیمی را ارائه میدهیم که در طول این بحثها آنها را شناسایی کردهایم.
سیستمها:
سیستمهای فعلی در حال کار ، تاثیر قابل ملاحظهای بر تصمیمات فعلی و تصمیمات آینده برای معماری دارند و سبب میشوند تا در زمان تصمیمگیری و صحبت راجع به معماری نرمافزار، ملاحظات مربوط به سیستمهای قدیمی مهمترین نقش را داشته باشند.
افراد:
کارکنان ارشد که با سیستمهای قدیمی کار میکنند و از آنها نگهداری میکنند یا در هنگام توسعه آنها حضور داشتهاند، قدرت زیاد و تاثیر قابل توجهی بر هر معماری جدید برای سیستم و هر آنچه که در آن سرمایهگذاری شود یا نشود، دارند.
شرکا:
شرکای خارجی که تاریخچهی قابل توجهی در سازمان دارند، در زمان تصمیمگیری برای این که چه معماری نرمافزاری باید یا نباید انتخاب شود، قدرت زیادی برای رایدهی دارند.
آسیب:
آسیبهای قدیمی که از وقفههای[۵] قدیمی، نقضها[۶]و تصمیمات بد معماری ناشی شده اند، آینده را نیز تحت تاثیر قرار خواهند داد. مخصوصا زمانی که تیمهای قدیمی، همچنان بر پروژههای آینده تاثیرگذار بمانند.
سیستمها، افراد، شرکا و تصمیمات بدی که در گذشته اخذ شده، تحریک و تاثیر خود را ادامه خواهند داد و معمولا بارها بر هر موج از تغییرات معماری نرم افزار اثر خواهند گذاشت. این تاثیر غیرقابل چشم پوشی و غیر قابل رها کردن است .
نیاز است تا سرمایه گذاری در معماری نرم افزار برای نسل بعدی به اثراتی مثبت، تغییر شکل داده شود. تغییر اجتناب ناپذیر است و نیاز است تا به گذشته فرهنگی و فنی توجه شود، اما نه به هزینه ی تکرار اشتباهات گذشته.
ملاحظات امروزی
با وجود نگرانیهای مربوط به گذشته، همهی ما در واقعیت حال حاضر زندگی میکنیم و این واقعیت چیزی است که ادامه پیدا خواهد کرد و به چگونگی تعریف معماری توسط ما شکل خواهد داد.
از طریق بحثهایی که ما با کمپانیها، موسسات و سازمانهای دولتی، راجع به چالشهایی که با آن روبرو هستند و همچنین راجع به نیروهای فعلی که به تصمیمات آنها برای معماری نرمافزار شکل میدهند، داشتهایم متوجه شدیم که چندین مورد[۷] تکراری مربوط به ملاحظات امروزی وجود دارد که بیشترین تاثیرات را داشته اند:
استعدادهای موجود:
استعدادهای موجود برای طراحی، توسعه و استقرار زیرساخت اَپی (API)، تعیین میکند که در هر مرحله چه چیزی امکانپذیر است.
کارکنان از راه دور:
دورکاری، نوع حرکت سازماندهی را تغییر میدهد، و به فرایندهایی قوی و تمرکزی متفاوت در هنگام اجرا نیاز دارد.
آگاهی از مسیر اصلی:
نگهداشتن روشهای معماری نرمافزار، همراستا با مسیر اصلی، به شکلدهی به تصمیمات معماری نرم افزار کمک میکند و به آنها اجازه میدهد تا با سرعتی مناسب‌تر رو به جلو حرکت کنند.
ظرفیت داخلی:
چندین بار گفته شده که ایجاد اَپی‌ها در سرتاسر سازمان، بدون تکیه بر ظرفیت داخلی، بجای برونسپاری یا وابستگی به راه حلهای فروشندگان نرمافزاری، امکانپذیر نخواهد بود.
روشهای مدرن شکلدهی به نحوه ایجاد معماری نرمافزار، چگونگی کنترل تکامل زیرساخت و پیدا کردن منابع و استعدادها برای واقعیت دادن به آنها را مشخص خواهند کرد.
همراستا نگهداشتن روشهای معماری نرمافزار با راهکارهای امروزی، به ساده کردن نقشهراه و چگونگی کار کردن تیمها با شرکا کمک میکند، و میتواند به کار با موجودیتهای خارجی کمک کند یا کار را به آنها واگذار کند (برونسپاری)، تا امور به مؤثرترین حالت ممکن انجام شوند.
تعریف بر اساس فناوری
فناوری که انتخاب میکنیم، به تعریف چگونگی ارائه و تکامل معماری نرمافزار کمک میکند. روندهای تکاملی زیادی در معماری نرمافزار وجود دارد که این بحث را رو به جلو بردهاند و به تیمها اجازه داده اند که در انجام کار خود چابکتر، سازگارتر و موثرتر باشند.
با مطالعه راهکارهای معماری استفاده شده توسط ارائه دهندگان پیشروی اَپی (API)، و با بحث و تبادل نظر با بخری از آنها، دیدگاه‌هایی که از نظر فنی تعریف شده بودند پیدا کردیم، که راجع به نحوهی اثرگذاری معماری نرمافزار بر نسلها و اشکال آینده بودند.
فروشندگان:
فروشندگان، اصول راهنمای خاص خود را راجع به چگونگی تعریف، ساخت و سازماندهی معماری نرمافزار، دارند. که اغلب اوقات، برای تعیین آنچه که در ادامه چه اتفاقی میافتد، نقشی غیر متعارف به آنها داده میشود.
فریمورکها:
فریمورکهای نرمافزاری و زبان برنامهنویسی، الگوهای خاصی را تعیین میکنند، چگونگی ارائه نرمافزار را کنترل میکنند و بحث راجع به چگونگی توسعه را هدایت میکنند. فریمورکهای نرمافزاری میتوانند میزان قابل توجهی از عقاید را در اختیار داشته باشند که برای تکامل در آینده، اهمیت خاصی خواهند کرد.
پلتفرم های ابری:
آمازون، گوگل و مایکروسافت (آژور) راجع به چگونگی تعریف معماری نرمافزار در شرایط فعلی، اثر مهمی دارند، و برای ما سرویسها و ابزارهایی را برای سازماندهی چرخه حیات فراهم میکنند. این کنترل بر چگونگی تعریف زیرساخت، تنها با رشد بازار این ابزارها در حوزه دیجیتال، افزایش پیدا خواهد کرد.
توسعه و یا یکپارچه سازی مداوم:
سرویسهای و ابزارها CI/CD روشی جدید را برای تعریف معماری نرمافزار و ایجاد رویکرد خط لوله ایجاد کردهاند تا آن را به جلو حرکت دهند و توجه مورد نیاز را به خود جلب کنند تا بدین وسیله هر قدم از فرایند سازماندهی را کنترل کرده، چرخههای تغییرات سالانه را به چرخههای ماهانه، هفتگی و حتی روزانه کاهش دهند.
کنترل منبع:
Github، Gitlab و Bitbucket نحوه ارائه نرمافزار را تعریف میکنند، و وسیلهای را برای حرکت رو به جلوی کد، و hookهایی برای کنترل هر commit فراهم میکنند. عملکرد آنها مانند آن است که هر حرکت رو به جلو برای زیرساخت، نسخهگذاری شده و تکامل یافته است.
این حوزه‌ها به طور فزایندهای، نحوه طراحی، توسعه، پیاده‌سازی و مدیریت زیرساخت را سازماندهی میکنند،.
ارچوبی را که برای اتکای زیرساخت فناوری خود به آن نیاز داریم، برای ما فراهم کرده، و ابزاری را به ما میدهند تا بتوانیم هماهنگ سازی را به صورت مداوم انجام دهیم، و همچنین بتوانیم به طور مداوم زیرساخت نرمافزاری که بطور روزافزون در حال بزرگ شدن و پیچیده‌تر شدن است را بین تیمهای مختلف در جای جای دنیا، پیش ببریم.
اثر تصمیماتی که برای فناوری مورد استفاده خود می‌گیریم برای سالها با ما خواهند ماند، حتی بعد از از بین رفتن آن فناوری.
تعریف تجاری
در ارائه معماری نرمافزار، همه چیز بر اساس اجزای فنی سازماندهی نمی‌شوند، و بیشترِ آنچه که ارائه میشود و رو به جلو میرود، بر اساس طرف تجاری معادله تعریف میگردد.
میزان سرمایه گذاری توسط هر کسبوکار برای بخش IT خود و همچنین گروههایی پیشرفته‌تر، تعیین خواهند کرد که چه کارهایی انجام شود و چه کارهایی انجام نشود. المانهایی از کسب و کار که در ادامه آمده است، معماری نرمافزار را به کمک چند مورد مختلف سازماندهی میکنند:
بودجه:
چه مقدار پول به تیم برای توسعه، گسترش، مدیریت و تکرار در معماری نرمافزار اختصاص داده شده است.
سرمایه گذاران:
بسیاری از گروهها توسط سرمایه گذاران خارجی تحت تاثیر قرار گرفته، تحریک، و حتی محدود میشوند. آنها تعیین میکنند که چه معماری نرمافزاری در اولویت قرار گیرد، و حتی در تصمیماتی راجع به اینکه چه چیزی برای کار انتخاب شود، نقشی تعیین کننده دارند.
شرکا:
شرکای خارجی که تاثیری قوی بر تصمیمات تجاری دارند و زیرساخت نرمافزاری را مدیریت میکنند، نقش بزرگی در وجود یا عدم وجود سازماندهی دارند.
تصویر عمومی:
اغلب اوقات، تصمیماتی که بر معماری نرمافزار اعمال میشود و سازماندهی مربوط به چگونگی جلو رفتن آن، بر اساس تصویر عمومی شرکت و ذینفعان آن، اتخاذ میشود.
فرهنگ:
فرهنگ یک کسب و کار، در تصمیماتی که در زمان توسعه، مدیریت و سازماندهی معماری نرمافزار گرفته میشود اثرگذار بوده، و در بسیاری از حالات برای حرکت روبه جلو، میتواند چالش برانگیزتر از فناوری باشد.
سازماندهی معماری نرمافزار باید با اهداف تجاری سازمان همراستا باشد. بسیاری از گروهها، مسیر شروع سازمان دهی اَپی بخش عمومی و خصوصی خود را بر اساس گرایشها یا ترجیح یک گروه کوچک انتخاب میکنند، اما در زمانی که سعی میکنند تا با اهداف گستردهتر سازمان برای کسب و کار همراستا شوند، با اصطکاک قابل توجهی مواجه میشوند.
گروههایی که ملاحظات تجاری را زودتر در استراتژی خود در نظر بگیرند، در کاهش اختلاف و از بین بردن موانع در نقشه راه خود، بسیار بهتر عمل خواهند کرد.
قابل مشاهده بودن
تقریبا تمام بحثهایی که راجع به سازماندهی زیرساخت نرمافزار داشتهایم، اهمیت «قابلیت مشاهده بودن» در میان تکرارهای نسل بعدی را شامل میشده است. طراحی، ارائه و پشتیبانی نرمافزار در تاریکی یا انزوا، یا شکست میخورد، و یا به نسل جدیدی از ایرادات فنی در آینده تبدیل میشود.
حوزه‌هایی برای تاکید و تضمین این موضوع وجود دارد که زیرساخت مبتنی بر اَپی (API) باید جزئیات را از روز اول ببیند، و به نحوی به کار خود ادامه دهد که تمام افرادی که درگیر کار هستند نیز بتواند آنچه را که اتفاق میافتد مشاهده کنند.
خارجی و آزاد:
گروههایی که در خارج از سازمان و به صورت آزاد کار میکنند، همواره پیشرفت خود را با دیگر تیمها به اشتراک میگذارند، و در کارهای خود در زمینه معماری، مایل به وجود یک فرایند شفاف را برای رسیدن به سطوح بالایی از موفقیت، مقبولیت و تداوم، هستند.
همکاری در کشف:
اطمینان از اینکه قبل از شروع کار، تیمها با هم کار میکنند تا ایدههای جدید را کشف کنند، راهحلهای نرمافزاری دیگر را یاد بگیرند و با هم کار کنند تا به توافق برسند، و در نهایت تصمیمهایی راجع به این بگیرند که چه چیزهایی باید مورد استفاده قرار گیرد.
مبتنی بر همکاری:
با وجود این که این روش در بعضی اوقات کندتر از روشهای سنتی که در آن هر کس کار خود را جداگانه انجام میدهد، است، تیمهایی که همکاری متقابل در تیم را تشویق کردند، مشاهده نمودند که تصمیمات آنها برای معماری، قویتر و پایدارتر بوده و طول عمر بیشتری داشته است.
متنباز:
دنبال کردن روشهای متنباز برای توسعه نرمافزار و کار کردن با راهحلهای متنباز فعلی، کمک میکند که معماری نرمافزار سازمانی دارای عمر طولانیتری بوده، پشتیبانی بیشتری داشته باشد و استانداردهای رایج را نسبت به دیگر روشهای اختصاصیتر دنبال کند.
بطور عمومی:
گروهها معمولا بیان میکنند که عمومی بودن (هرگاه از دیدگاه حریم خصوصی و امنیت منطقی باشد) به صورت پیشفرض به تضمین این امر کمک میکند که تیمهای پروژه به صورتی متفاوت رفتار کنند، از پاسخگویی بیشتر لذت ببرند و معمولا استعداد خارجی، متخصص حوزه و نظر عمومی را در طول مسیر جذب کنند.
تشکیلات سازمانی که به صورت پیشفرض بر «قابلمشاهده بودن» اصرار دارند، متوجه شدند که تیمها تمایل دارند تا با یکدیگر بهتر کار کنند و نگرش بازتری داشته باشند. شخصیتهای درست و مناسب را جذب کرده، ارتباطات عادی را تشویق کنند و به صورت پیشفرض تفکر خارجی داشته باشند، اما نه به چیزی که خارج از مسیر رخ میدهد.
این موضوع، اگرچه ممکن است پیچیده و انتزاعی باشد و سبب شود تا چیزها مجبور شوند با گستره وسیعتری از مخاطبان (فراتر از توسعهدهنده و گروههای IT) صحبت کنند، به فرایند وضوح مورد نیاز و قابلیت مشاهده را اضافه میکند.
فرایند مشترک
وجود یک فرایند مشترک که بتواند فراتر از تیمهای فنی، بین تیمها ارتباط برقرار کند، بطوریکه که گروههای تجاری، شرکا، شخص ثالث و تمام دیگر ذینفعان بتوانند آن را دنبال کنند و در آن مشارکت کنند، بخشی عادی و رایج از چرخه های حیات جدیدتر برای تحویل نرمافزار مبتنی بر اَپی بخش عمومی و خصوصی است.
تعدادی عنصر اصلی دارد که میتوانند به تضمین فرایند تعریف، طراحی، ارائه و تکامل معماری نرمافزار کمک کند.
قرارداد:
ساخت، نگهداری و اعمال مداوم یک قراردادِ قابل خواندن برای ماشین، که به فرمت YAML در دسترس باشد، رویکردی رایج برای اطمینان از آن است که قراردادی وجود دارد که میتواند در میان تمام پروژههای معماری استفاده شود و هر راهحل را مانند یک سرویس مستقل تجاری تعریف کند.
خط لوله:
بسط دادن قراردادهای مربوط به سرویسی که برای ماشین قابل خواندن باشد به کمک تعاریف خط لوله توصیف شده توسط YAML، تضمین میکند که تمامی نرمافزار به صورتی سازگار و به روشی قابل بازتولید توسط بسیاری از تیمهای مختلف ساخته میشود.
نسخه بندی:
ایجاد یک رویکرد مشترک برای نسخه بندی کد، تعاریف و دیگر چیزهای ساخته شده یک رویکرد معنایی مشترک را فراهم میکند که نحوهی ارتقای نرمافزار را به صورت اشتراکی کنترل میکند، و به نحوی است که هر کس میتواند آن را دنبال کند.
بطور تاریخی، توسعه نرمافزار و چرخه حیات عملیاتی، توسط گروههای توسعه وIT انجام میگیرد. روشهای مدرن برای ارائه نرمافزار در سازمان، یک فرایند مشترک بوده، و شامل ذینفعان تجاری داخلی و فنی میشوند.
همچنین این فرایند با شرکای خارجی، توسعه دهندگان شخص ثالث و عموم نیز به اشتراک گذاشته میشود. در معرض عموم قرار دادن معماری نرمافزاری، و اعمال آن بر وب آزاد، جای آن را بیشتر در میان تمام ذینفعان باز میکند، اما این کار به طریقی انجام میشود که در طول مسیر به حریم خصوصی و امنیت، لطمه‌ای نخورد.