معماری سرویس گرا (بخش پنجم) – تاثیر سرویس گرایی بر سازمان

۱. سرویس گرایی و مفهوم "برنامه کاربردی" (Application):

در دنیای غیر سرویس گرایی، سازمانها دارای تعدادی برنامه کاربردی (Applications) هستند. به عنوان مثال سیستم مدیریت مشتری (CRM) سازمان، سیستم حقوق و دستمزد و وب سایت سازمان به عنوان برنامه های کاربردی مستقل از یکدیگر (و یا در بهترین حالت تحت یک سیستم بزرگ ERP) وجود دارند.

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

در سازمانهای سرویس گرا اما، این مفهوم به طور کلی دستخوش تغییر می شود. کلیه قابلیت های لازم (Capabilities) به شکل سرویس های قابل استفاده مجدد و مستقل از یکدیگر ایجاد و نصب می گردد (که در پستهای آینده شرح داده خواهد شد که حوزه یا Scope این سرویس ها می تواند بخشی از سازمان یا کل سازمان باشد که در حالت اول تشکل Domain Inventory و در حالت دوم تشکیل Enterprise Inventory را می دهد).

کلیه سرویس های طراحی و تولید شده در سازمان، در ظرفی به نام Inventory قرار داده می شوند. بدین ترتیب با ترکیب دو یا چند سرویس و مرتبط ساختن آنها با هم به قابلیت های جدید دست پیدا خواهیم کرد.

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

 

۲. سرویس گرایی و مفهوم "یکپارچه سازی" (Integration):

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

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

همانگونه که در بند پیشین بیان شد، سازمان سرویس گرا در حالت ایده آل، دارای Inventoryی مشتمل بر کلیه سرویس های سیستم مدیریت اطلاعات پرسنل داخلی و همچنین پیمانکاران است. در این شرایط، برای برآورده ساختن نیازمندی جدید (ایجاد گزارشی از هر دو سیستم)، تنها کار لازم ایجاد ترکیبی (Composition) از سرویس های موجود است. سرویس هایی که از پیش با فرض "قابلیت استفاده مجدد" (Reusability) طراحی شده اند و به دلیل رعایت استانداردهای تعریف شده، تا حد زیادی همگن بوده و به راحتی با یکدیگر ترکیب می شوند.

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

 

در پست های آتی، استاندارد سازی سرویس ها (Service Standardisation) و حتی مدل های داده ای سازمان (Data Schema) مورد توجه قرار خواهد گرفت.

<بخش قبل  بخش بعد>

دمی درنگ

An old Cherokee Indian was speaking to his grandson:

“A fight is going on inside me,” he said to the boy. “It is a terrible fight and it is between two wolves. One is evil – he is anger, envy, sorrow, regret, greet, arrogance, self-pity, guilt, resentment, inferiority, lies, false pride, superiority, and ego. The other is good – he is joy, peace, love, hope, serenity, humility, kindness, benevolence, empathy, generosity, truth, compassion, and faith.

This same fight is going on inside you, and inside every other person, too”

The grandson thought about it for a long minute, and then asked his grandfather, “Which wolf will win?”

The old Cherokee simply replied, “The one you feed.”

معماری سرویس گرا (بخش چهارم) – مزایای سرویس گرایی (ادامه)

(ادامه از پست پیشین)

 4. هم راستایی کسب و کار و فناوری (Increased Business and Technology Domain Alignment):

همواره عامل و توجیه تولید یک نرم افزار وجود مساله ای (مشکلی) در کسب و کار است.

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

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

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

در نتیجه در صورت تغییر صورت مساله تجاری، در بسیاری از اوقات می توان با تغییر پیکر بندی (Configuration) و ترکیب بندی (Combination) سرویس ها به صورت مساله جدید دست پیدا کرد (شکل زیر را ببینید).

ارزش برای شرکت کالایاب:

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

5. افزایش بازگشت سرمایه (Increased Return on Investment):

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

راه حل های نرم افزاری سنتی (Silo Based) معمولا برگشت سرمایه سریعتری نسبت به راه حل های سرویس گرا دارند. اما در بلند مدت، معماری سرویس گراست که برنده این میدان است.

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

ارزش برای شرکت کالایاب:

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

 

6. افزایش چابکی سازمان (Increased Organizational Agility)

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

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

ارزش برای شرکت کالایاب:

واضح است که این ویژگی برای شرکت کالایاب - مانند هر سازمان دیگری – مزیت بزرگی محسوب می شود.

 

7. کاهش حجم کاری و هزینه های فناوری اطلاعات سازمان (Reduced IT Burden)

به کار گیری مداوم سرویس گرایی در سازمان باعت کاهش افزونگی و اتلاف منابع، هزینه های عملیاتی و هزینه های بالاسری مربوط به راهبری و تکامل سیستم ها می شود.

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

ارزش برای شرکت کالایاب:

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

 

<بخش قبل  بخش بعد>