اَپی بخش‌ عمومی و خصوصی

0 744

این نوشته بخش دوم (مشاهده بخش اول) از یک مجموعه هشت قسمتی و در مورد پروژه میکرومشاوره‌ای تحت عنوان «مدل‌های سازمان دهی اَپی بخش‌ عمومی و خصوصی» توسط دپارتمان امور سربازان بازنشسته» نگاشته شده است.

این پروژه به دنبال بررسی اجمالی در مورد سیاست گذاری اَپی (API) و جهت کمک به درک، برای تبیین بهترین راهکارهای عملی اَپی بخش‌ عمومی و خصوصی ، و بطور خاص جهت اولویت بندی به ساخت اَپی‌ها، و استانداردهایی برای اینکه کدام اَپی‌ها ساخته شوند، و در دسترس قرار دادن اَپی‌ها جهت استفاده کاربر نهایی خارج از سازمان تولید شده است.

مدل‌های سازمان دهی برای اَپی بخش‌ عمومی و خصوصی  (بخش دوم)

در این مقاله، سالیان متمادی تحقیقات انجام شده توسط آنالیز صنعتی API Evangelist ، در کنار مصاحبه‌های تلفنی انجام شده توسط Skylight Digital با متخصصین حوزه اَپی (API) سازمان‌ها و موسسات بزرگی که سیاست گذاری اَپی بخش‌ عمومی و خصوصی بر عهده دارند، گردآوری شده است.

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

 

سازمان دهی اَپی 

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

در انتها این مقاله را با جمع بندی جزئیات سازمان دهی اَپی (API)، و همچنین اقرار به اینکه درحال حاضر بیشتر سیاست‌های ساخت اَپی‌ها اغلب از ابتدا به درستی طرح ریزی نشده اند، به پایان خواهیم برد.

این جمع بندی شامل شرح کامل نحوه سازمان دهی‌ اَپی بخش‌ عمومی و خصوصی به همراه لیستی از عناصری که می‌توانند به سازمان دهی اَپی (API) در شرکت‌های بزرگ کمک کنند، خواهد بود.

 

اَپی بخش‌ عمومی و خصوصی
اَپی بخش‌ عمومی و خصوصی

 

 

 

 

طراحی معماری نرم ­افزار

سازمان دهی به طور کلی در مورد ساختن و شکل دادن مسیری برای طراحی و معماری نرم‌افزار، استفاده از وب و بطور خاص اَپی (API) برای قادر ساخت وب، موبایل، ابزار و برنامه‌های کاربردی تحت شبکه‌ است.

در مسیر ما برای شکل دادن و تکامل معماری نرم‌افزارمان، و پذیرفتن مسائلی که بر اینکه نرم‌افزار ما چه هست، چه کاری می‌کند، و درنهایت به چه چیزی تبدیل خواهد اثر دارند، الگوهای سالم، و بعضاً نه چندان سالمی می‌توانند در نظر گرفته شوند.

 

آگاهی از حوزه

معماری نرم ­افزار همیشه از محیط نشأت می‌گیرد، و تحت تاثیر فاکتورهایی که در هر حوزه­ای وجود دارد، قرار می­گیرد.

فاکتورهایی وجود دارند که بر حجم و چگونگی سرمایه­ گذاری و تعریف معماری نرم ­افزار در سازمان­های بزرگ تاثیر می­گذارند. در اینجا برخی حوزه‌های مهم در نظر گرفته شده­اند که راجع به این هستند که چگونه حوزه­ ی کاری شرکت بر معماری آن تاثیر می­گذارد:

 

منابع:

انواع منابع دیجیتالی که سازمان در حال حاضر در اختیار دارد، معماری نرم­افزاری را مدیریت خواهند کرد و تعریف می­کنند که معماری چگونه کار خواهد کرد، چگونه رشد و توسعه خواهد یافت و چگونه دستخوش تغییر قرار خواهد گرفت.

 

شِما:

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

 

فرایند:

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

 

صنعت:

فاکتورهای خارجی صنعت همواره در حال ظهور هستند تا چگونگی ساخت معماری نرم­افزار را تغییر دهند و طراحی، توسعه و فاکتورهایی عملیاتی را فراهم کنند که لازم است در زمان بازسازی معماری، در نظر گرفته شوند.

 

مقررات : 

بغیر از تاثیرات طبیعی صنعت، قوانین و مقررات و دیگر ملاحظات دولتی نیز وجود دارند که نحوه­ی عملکرد معماری نرم­افزار را  تغییر خواهند داد.

 

تعاریف:

در دسترس بودن و همچنین دسترسی به تعاریف، شماتیک‌ها، فرایندها و دیگر المان­های ساختاری قابل خواندن توسط ماشین، که به عنوان راهنما می­توانند به عملکرد موثرتر معماری نرم­افزار کمک کنند. در صورت نبودن استاندارسازی و قابلیت انتقال، میزان اثربخشی معماری کاهش می­یابد.

 

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

 

بدون وجود ظرفیت داخلی مناسب، دانش حوزه می­تواند حداقل شود و در نتیجه معماری کلی مربوط به زیرساخت دیجیتال را برای سازمانی که نیاز به حرکت رو به جلو دارد، تضعیف کند.

 

 

ملاحظات مربوط به نسخه­ های قدیمی

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

شاید لازم نباشد که دقیقاً از همان کد قدیمی همواره در مسیر پیش رویمان استفاده کنیم، اما تجربه، دانش و درس­هایی که از نسخه­های قدیمی سازمان یاد گرفته­ایم، باید به نمایش گذاشته شود.

در ادامه تعداد انگشت­ شماری از ملاحظات مربوط به نسخه­های قدیمی را ارائه می­دهیم که در طول این بحث­ها آنها را شناسایی کرده­ایم.

 

سیستم­ها:

سیستم­های فعلی در حال کار ، تاثیر قابل ملاحظه­ای بر تصمیمات فعلی و تصمیمات آینده برای معماری دارند و سبب می­شوند تا در زمان تصمیم­گیری و صحبت راجع به معماری نرم­افزار، ملاحظات مربوط به سیستم­های قدیمی مهم­ترین نقش را داشته باشند.

 

افراد:

کارکنان ارشد که با سیستم­های قدیمی کار می­کنند و از آنها نگهداری می­کنند یا در هنگام توسعه­ آن‌ها حضور داشته­اند، قدرت زیاد و تاثیر قابل توجهی بر هر معماری جدید برای سیستم و هر آنچه که در آن سرمایه­گذاری شود یا نشود، دارند.

 

شرکا:

شرکای خارجی که تاریخچه­ی قابل توجهی در سازمان دارند، در زمان تصمیم­گیری برای این که چه معماری نرم­افزاری باید یا نباید انتخاب شود، قدرت زیادی برای رای­دهی دارند.

 

آسیب:

آسیب­های قدیمی که از وقفه­های[۵] قدیمی، نقض­ها[۶]و تصمیمات بد معماری ناشی شده ­اند، آینده را نیز تحت تاثیر قرار خواهند داد. مخصوصا زمانی که تیم­های قدیمی، همچنان بر پروژه­های آینده تاثیرگذار بمانند.

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

نیاز است تا سرمایه­ گذاری در معماری نرم ­افزار برای نسل بعدی به اثراتی مثبت، تغییر شکل داده شود. تغییر اجتناب­ ناپذیر است و نیاز است تا به گذشته فرهنگی و فنی توجه شود، اما نه به هزینه­ ی تکرار اشتباهات گذشته.

 

اَپی بخش‌ عمومی و خصوصی
اَپی بخش‌ عمومی و خصوصی

 

 

 

 

ملاحظات امروزی

با وجود نگرانی­های مربوط به گذشته، همه­ی ما در واقعیت حال حاضر زندگی می­کنیم و این واقعیت چیزی است که ادامه پیدا خواهد کرد و به چگونگی تعریف معماری توسط ما شکل خواهد داد.

از طریق بحث­هایی که ما با کمپانی­ها، موسسات و سازمان­های دولتی، راجع به چالش­هایی که با آن روبرو هستند و همچنین راجع به نیروهای فعلی که به تصمیمات آنها برای معماری نرم­افزار شکل می­دهند، داشته­ایم متوجه شدیم که چندین مورد[۷] تکراری مربوط به ملاحظات امروزی وجود دارد که بیشترین تاثیرات را داشته­ اند:

 

استعدادهای موجود:

استعدادهای موجود برای طراحی، توسعه و استقرار زیرساخت اَپی (API)، تعیین می­کند که در هر مرحله چه چیزی امکان­پذیر است.

 

کارکنان از راه دور:

دورکاری، نوع حرکت سازماندهی را تغییر می­دهد، و به فرایندهایی قوی و تمرکزی متفاوت در هنگام اجرا نیاز دارد.

 

آگاهی از مسیر اصلی:

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

 

ظرفیت داخلی:

چندین بار گفته شده که ایجاد اَپی‌ها در سرتاسر سازمان، بدون تکیه بر ظرفیت داخلی، بجای برون­سپاری یا وابستگی به راه­ حل­های فروشندگان نرم‌افزاری، امکان­پذیر نخواهد بود.

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

هم­راستا نگه­داشتن روش­های معماری نرم­افزار با راهکارهای امروزی، به ساده کردن نقشه­راه و چگونگی کار کردن تیم­ها با شرکا کمک می­کند، و می­تواند به کار با موجودیت­های خارجی کمک کند یا کار را به آنها واگذار کند (برون­سپاری)، تا امور به مؤثرترین حالت ممکن انجام شوند.

 

 

تعریف بر اساس فناوری

فناوری که انتخاب می‌کنیم، به تعریف چگونگی ارائه و تکامل معماری نرم­افزار کمک می‌کند. روندهای تکاملی زیادی در معماری نرم­افزار وجود دارد که این بحث را رو به جلو برده­اند و به تیم­ها اجازه­ داده ­اند که در انجام کار خود چابک­تر، سازگارتر و موثرتر باشند.

با مطالعه راهکارهای معماری استفاده شده توسط ارائه ­دهندگان پیشروی اَپی (API)، و با بحث و تبادل نظر با بخری از آنها، دیدگاه‌هایی که از نظر فنی تعریف شده بودند پیدا کردیم، که راجع به نحوه­ی اثرگذاری معماری نرم­افزار بر نسل­ها و اشکال آینده بودند.

 

فروشندگان:

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

 

فریم­ورک­ها:

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

 

پلتفرم­ های ابری:

آمازون، گوگل و مایکروسافت (آژور) راجع به چگونگی تعریف معماری نرم­افزار در شرایط فعلی، اثر مهمی دارند، و برای ما سرویس­ها و ابزارهایی را برای سازماندهی چرخه حیات فراهم می­کنند. این کنترل بر چگونگی تعریف زیرساخت، تنها با رشد بازار این ابزارها در حوزه دیجیتال، افزایش پیدا خواهد کرد.

 

توسعه و یا یکپارچه­ سازی مداوم:

سرویس­های و ابزارها CI/CD روشی جدید را برای تعریف معماری نرم­افزار و ایجاد رویکرد خط لوله ایجاد کرده­اند تا آن را به جلو حرکت دهند و توجه مورد نیاز را به خود جلب کنند تا بدین وسیله هر قدم از فرایند سازماندهی را کنترل کرده، چرخه­های تغییرات سالانه را به چرخه­های ماهانه، هفتگی و حتی روزانه کاهش دهند.

 

کنترل منبع:

Github، Gitlab و Bitbucket نحوه ارائه نرم­افزار را تعریف می­کنند، و وسیله­ای را برای حرکت رو به جلوی کد، و hookهایی برای کنترل هر commit فراهم می­کنند. عملکرد آنها مانند آن است که هر حرکت رو به جلو برای زیرساخت، نسخه­گذاری شده و تکامل یافته است.

این حوزه‌ها به طور فزاینده­ای، نحوه طراحی، توسعه، پیاده‌سازی و مدیریت زیرساخت را سازماندهی می­کنند،.

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

اثر تصمیماتی که برای فناوری مورد استفاده خود می‌گیریم برای سال­ها با ما خواهند ماند، حتی بعد از از بین رفتن آن فناوری.

 

 

تعریف تجاری

در ارائه معماری نرم­افزار، همه چیز بر اساس اجزای فنی سازماندهی نمی‌شوند، و بیشترِ آنچه که ارائه می­شود و رو به جلو می­رود، بر اساس طرف تجاری معادله تعریف می­گردد.

میزان سرمایه ­گذاری توسط هر کسب­وکار برای بخش IT خود و همچنین گروه­هایی پیشرفته‌تر، تعیین خواهند کرد که چه کارهایی انجام شود و چه کارهایی انجام نشود. المان­هایی از کسب­ و کار که در ادامه آمده است، معماری نرم­افزار را به کمک چند مورد مختلف سازماندهی می­کنند:

 

بودجه­:

چه مقدار پول به تیم برای توسعه، گسترش، مدیریت و تکرار در معماری نرم­افزار اختصاص داده شده است.

 

سرمایه ­گذاران:

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

 

شرکا:

شرکای خارجی که تاثیری قوی بر تصمیمات تجاری دارند و زیرساخت نرم­افزاری را مدیریت می‌کنند، نقش بزرگی در وجود یا عدم وجود سازماندهی دارند.

 

تصویر عمومی:

اغلب اوقات، تصمیماتی که بر معماری نرم­افزار اعمال می­شود و سازماندهی مربوط به چگونگی جلو رفتن آن، بر اساس تصویر عمومی شرکت و ذی­نفعان آن، اتخاذ می­شود.

 

فرهنگ:

فرهنگ یک کسب­ و کار، در تصمیماتی که در زمان توسعه، مدیریت و سازماندهی معماری نرم­افزار گرفته می­شود اثرگذار بوده، و در بسیاری از حالات برای حرکت روبه جلو، می­تواند چالش برانگیزتر از فناوری باشد.

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

گروه­هایی که ملاحظات تجاری را زودتر در استراتژی خود در نظر بگیرند، در کاهش اختلاف و از بین بردن موانع در نقشه­ راه خود، بسیار بهتر عمل خواهند کرد.

 

اَپی بخش‌ عمومی و خصوصی
اَپی بخش‌ عمومی و خصوصی

 

 

 

 

 

قابل مشاهده بودن

تقریبا تمام بحث­هایی که راجع به سازماندهی زیرساخت نرم­افزار داشته­ایم، اهمیت «قابلیت مشاهده بودن» در میان تکرارهای نسل بعدی را شامل می­شده است. طراحی، ارائه و پشتیبانی نرم­افزار در تاریکی یا انزوا، یا شکست می­خورد، و یا به نسل جدیدی از ایرادات فنی در آینده تبدیل می­شود.

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

 

 

خارجی و آزاد:

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

 

همکاری در کشف:

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

 

مبتنی بر همکاری:

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

 

متن­باز:

دنبال کردن روش­های متن­باز برای توسعه نرم­افزار و کار کردن با راه­حل­های متن­باز فعلی، کمک می­کند که معماری نرم­افزار سازمانی دارای عمر طولانی­تری بوده، پشتیبانی بیشتری داشته باشد و استانداردهای رایج را نسبت به دیگر روش­های اختصاصی­تر دنبال ­کند.

 

بطور عمومی:

گروه­ها معمولا بیان می­کنند که عمومی بودن (هرگاه از دیدگاه حریم خصوصی و امنیت منطقی باشد) به صورت پیش­فرض به تضمین این امر کمک می­کند که تیم­های پروژه به صورتی متفاوت رفتار کنند، از پاسخگویی بیشتر لذت ببرند و معمولا استعداد خارجی، متخصص حوزه و نظر عمومی را در طول مسیر جذب کنند.

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

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

 

 

فرایند مشترک

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

تعدادی عنصر اصلی دارد که می‌توانند به تضمین فرایند تعریف، طراحی، ارائه و تکامل معماری نرم­افزار کمک کند.

 

 

قرارداد:

 ساخت، نگهداری و اعمال مداوم یک قراردادِ قابل خواندن برای ماشین، که به فرمت YAML در دسترس باشد، رویکردی رایج برای اطمینان از آن است که قراردادی وجود دارد که می­تواند در میان تمام پروژه­های معماری استفاده شود و هر راه­حل را مانند یک سرویس مستقل تجاری تعریف ­کند.

 

خط لوله:

بسط دادن قراردادهای مربوط به سرویسی که برای ماشین قابل خواندن باشد به کمک تعاریف خط لوله توصیف شده توسط YAML، تضمین می­کند که تمامی نرم­افزار به صورتی سازگار و به روشی قابل بازتولید توسط بسیاری از تیم­های مختلف ساخته می­شود.

 

نسخه ­بندی:

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

بطور تاریخی، توسعه نرم­افزار و چرخه حیات عملیاتی، توسط گروه­های توسعه وIT  انجام می‌گیرد. روش­های مدرن برای ارائه نرم­افزار در سازمان، یک فرایند مشترک بوده، و شامل ذی­نفعان تجاری داخلی و فنی می­شوند.

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

 

ارسال یک پاسخ

آدرس ایمیل شما منتشر نخواهد شد.