آموزش وب سرویس – قسمت چهارم – تاثیر وب سرویس بر فرهنگ سازمانی

2,021

تاثیر وب سرویس بر فرهنگ سازمانی چگونه است؟ در قسمت چهارم از آموزش تصویری وب سرویس با بیانی ساده به اثرگذاری وب سرویس ها را روی فرهنگ سازمانی می پردازیم.

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

تاثیر وب سرویس بر فرهنگ سازمانی چگونه است؟

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

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

 

تفاوت میان اپلیکیشن‌های یکپارچه و اپلیکیشن‌های مبتنی بر وب سرویس ها در چیست؟

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

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

 

مزایای معماری سرویس گرا در سازمان

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

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

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

 

تاثیر وب سرویس

آمازون، برترین ارائه دهنده وب سرویس

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

 

چطور سازمان خود را به یک سازمان سرویس گرا مبدل کنیم

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

 

تاثیر وب سرویس و معماری میکروسرویس ها

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

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

 

فواید میکروسیستم‌ ها و معماری وب سرویس ها

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

قابلیت استفاده مجدد

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

 

مشکلات معماری وب سرویس ها

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

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

در سیستم‌هایی مانند فرایند تراکنش که سیستم در هر بخش نیاز به اطلاعات بخش پیشین دارند، ما با یک فرآیند سلسله وار روبرو هستیم. در این سیستم‌ها نیاز به بخش‌هایی داریم که دارای حافظه داخلی (کش) باشند. این کار عملا در api ها غیر ممکن است. پس در اینجا معماری دیگری باید جایگزین معماری وب سرویس ها شود.

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

 

تاثیر وب سرویس و شکل‌گیری اقتصاد api

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

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

 


مشاهده قسمت قبل : چرا باید روی API ها سرمایه گذاری کرد؟


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

همراه ما باشید…

ارسال یک پاسخ

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