اکنون که برای شروع SOA آماده اید نیاز به انتخاب یک پروژه آزمایشی دارید. اما نمی دانید که چگونه این پروژه را انتخاب کنید.
معیارهای زیر را برای اینکه یک پروژه به عنوان پروژه آزمایشی حساب شود، استفاده کنید:
۱- آیا این پروژه ارزش های کسب و کار را برآورده می کند؟
۲- آیا این پروژه حوزه فعالیت محدود دارد؟
۳- آیا این پروژه یک سرویس را خوب می سازد؟
۴- آیا اعضای تیم درک درستی از مسائلی که پروژه به آنها اشاره دارد، دارند؟
۵- آیا پروژه سودمند است ولی نه برای ماموریت های بحرانی؟
توجه کردن به معیارهای گفته شده به شما در انتخاب پروژه مناسب برای شروع کمک می کند.

آیا این پروژه ارزش های کسب و کار را برآورده می کند؟
SOA ،IT را با کسب و کار به روش های زیادی همراستا می کند به همین دلیل است که خطوط ارتیاطی مبهمی بین این دو وجود دارد. آنگونه که SOA پدیدار می شود بسیار وابسته به سازمان شما و فرهنگ آن می باشد. به هر حال SOA نیازمند پشتیبانی قابل توجهی است. این موضوع روش های جدیدی برای تفکر راجع به سیستم را ارائه می دهد و API های زیادی برای یادگرفتن وجود دارد. با وجود ابزار های رایگان و منبع باز برای استفاده سرورها، گذرگاههای سرویس های مهم، اجرای فرآیندهای کسب و کار و بیشتر، برخی شرکت ها نرم افزارهای گران قیمتی را خریداری می کنند که زمان و ورودی زیادی از کسب و کار را نیازمندند. سرمایه گذاری که کسب و کار برای آموزش تیم و گسترش گروه IT می کند به معنای هزینه و زمان واقعی است. که در ابتدا برای گرفتن چیز جدیدی داده نمی شود. اغلب این سرمایه گذاری به عنوان یک هزینه زیربنایی برای زیرساخت به چشم می آید که کسب و کار انتظار دارد در مدت طولانی پرداخت کند.
به این دلایل، برد کسب و کار مهم است وگرنه سرمایه گذاری وابسته به تیم SOA ممکن است از بین برود. راه موفقیت کسب و کار ارائه پول می باشد. پروژه ای را انتخاب کنید که به سرعت بازگشت سرمایه داشته باشد که کسب و کار پشتیبان بماند. به وضوح روشن است که بازگشت واقعی سرمایه از راه SOA بعد از چندین سال تحقق می یابد، و بستگی به پاسخگویی و آمادگی IT برای دستیابی به تغییرات نیازهای کسب و کار دارد.
آیا یک پروژه حوزه فعالیت محدودی دارد؟
بهتر است یک پروژه حوزه فعالیت محدودی داشته باشد و کاربردی را که نسبت به سیستم هایی که شناخته شده نیستند را آشکارا نشان دهد. این یعنی بهتر است پروژه شما سیستم های چندگانه را در بر گیرد. این مسئله نمی تواند صرفاً دلیلی بر مفهوم وب سرویس باشد اما باید پروژه کامل و واقعی باشد.
معرفی کردن SOA می تواند توسع دهندگان نرم افزار را به API های جدید، نرم افزارهای سرور جدید، زبانهای جدید و زیر ساخت های جدید هدایت کند. همچنین طرز فکر جدیدی راجع به توسعه نرم افزار ارائه می دهد. برای سرویس ها فکر کردن با فکر کردن برای شئ ها تفاوت دارد. تغییر جهت دادن از برنامه نویسی تابعی و رویه ای به شئ گرا زمان بر و شامل تغییرات چشمگیری برای توسعه دهندگان نرم افزار می باشد. برای مثال کلاسهای زبان جاوا بالغ بر 15000 خط برنامه با یک متد واحد 700، 800 خطی دارند. فقط بخاطر اینکه شما به زبان جاوا برنامه نوشته اید و برنامه شئ گرا نمی باشد و نمی توان توقع داشت به خوبی عمل کند. تفاوت هایی را که سرویس ها برای برنامه نویسان شئ گرا می توانند بیان کنند را نباید دست کم گرفت. شما برای آموزش تیم نیاز به زمان دارید (اگرچه به طور همزمان نیازی نباشد.) که زمان برنامه نویسان را از بین می برد. اگر پروژه حوزه فعالیت وسیعی داشته باشد، وقتی که شما توجه به مسائل جانبی دارید، امکان دارد هیچوقت به پایان نرسد.
شما می خواهید قادر به مجزا کردن مجهولات باشید که بتوانید به آسانی مسئله را در جریان توسعه و مرحله تضمین کیفیت پروژه تشخیص دهید. توجه کنید که محصولی را انتخاب کنید که محصولات جدید را استفاده می کند. تیم از پیش باید بتواند توانایی داشته باشد تا بتواند با زیرساختها و API های جدید کار کند. همچنین مشاور می تواند در اینجا کمک کننده باشد.
به اهداف مصرف کننده ها در سرویس نخستین توجه کنید. با انتجاب کردن موارد داخلی در کسب و کار ریسک خود را نسبت به برخورد با مشتری، کاهش دهید. این به شما زمان می دهد تا قبل از اینکه دنیای خارج درگیر شود و موضوعات جدید و غیرقابل پیشبینی را معرفی کند کمی زیرساخت را بسازید. طبعاً سرویس های استفاده شده به شما کمک می کند روی اجرای سرویس های جدید خود به خوبی متمرکز شوید و شما را برای مدتی از موضوعات سخت و پیچیده مانند امنیت متحد شده دور نگهدارد. همچنین سرویس های داخلی فرصت اندازه گیری حجم ترافیک با اطمینان بیشتری را به شما می دهد.
آیا پروژه یک سرویس خوب می سازد؟
دقت کنید نیروهای خارجی شما را مجبور به انتخاب پروژه آزمایشی نکند حتی اگر پروژه پیشنهادی یک سرویس خوب را نسازد. تیم SOA شکل می گیرد و سپس مسئول پروژه اصرار بر این می کند که هر چیزی در پروژه لیست شده باید آزمایشی باشد، صرف نظر از اینکه این سرویس کاندید سودمند است یا نه. نوشتن سرویس ها در ابتدا پیچیدگی و هزینه زیادی را به پروژه متحمل می کند. به امید اینکه سود بدست آمده بعداً ارزشمندتر است. اگر سرویس هیچگاه دوباره استفاده نشود و یا از پایگاه دیگری احضار نشود، شما سرویس مناسبی در دست ندارید. این بدان معناست که شما ROI را خیلی تحقق نبخشیدید.
آیا اعضای تیم درک درستی از مسائلی که پروژه به آنها اشاره دارد، دارند؟
اگر شما موضوع قابل بحث ویژه ای برای حوزه مسئله موجود داشته باشید می توانید ریسک را به اندازه قابل ملاحظه ای کاهش دهید. مطرح کردن سیستم های جدید، نرم افزار جدید، فرآیندهای جدید و حوزه مسائل جدید در یک زمان که سرویس ها و SOA را معرفی می کند ترکیب خطرناکی را خلق می کند. اگر با فروشنده ها یا مشاورها کار می کنید اطمینان حاصل کنید که آنها یک پیش زمینه ذهنی از آنچه شما در قله کسب و کارتان تعریف کردید، دارند.
آیا پروژه سودمند است ولی نه برای ماموریت های بحرانی؟
در حالی که درک ارزش کسب و کار در برقرار کردن SOA مهم است، مولظب باشید در مرحله اول چیز زیادی از دست ندهید. پروژه آزمایشی SOA اغلب از دنبال کردن پایان کار باز می مانند، نیازمندیهای مسلم را از دست می دهد، یا روی هم رفته با شکست مواجه می شود. پروژه ای را انتخاب که برای کارهای اضافی در جهت رشد و اجرای سرویس ها کسب و کار شما را تحلیل نبرد.
این مسئله از نقاط ضعف موجود در سرویس یک پروژه آزمایشی توانمند می سازد. کمی بر روی قالب معماری، روش شناسی، و الگوی طرح تحقیق کنید و آن را برگزینید که شما را در یک محیط بهتر پشتیبانی می کند.

دومین پروژه
وقتی به پایان پروژه اول می رسید، دومین پروژه، که احتمالاً آزمایشی در نظر گرفته می شود بسیار مهم می شود. هدف اصلی ایجاد پایه و اساس SOA، درک مفاهیم فنی، ایجاد چیزی از ارزش های استفاده محدودیت های جدید و استراتژی های جدید است.
دومین پروژه فرصتی کلیدی برای ساخت برخی از رابط های سازمانی و برش افقی که با SOA آسان می شود را فراهم می کند. به همین دلیل دومین پروژه نیز نیازمند محدودیت حوزه کسب و کار مانند اولین پروژه می باشد. نیازی به نوشتن زیر ساختهای جدید برای دومین پروژه نیست. شما نیازمند زمان برای یادگیری الگوهای رفتاری جدید ابزارهای جدیدتان و آموزش واقعیت روزانه از اجرای محیط سرویس های تولید برای شروع کردن، هستید.
همچنین شما می توانید از با استفاده از دومین پروژه معماری ابتدایی خود را بسازید. شما می توانید سرویس های هدایت کننده و کاربردی مانند سرویس های قوانین و سرویس های امنیتی را به پروژه خود اضافه کنید. در این مرحله ممکن است شما ابزارهای BAM را معرفی کنید یا به طور کلی با WS-policy و یا رابط های امنیتی بیشتر وارد کار شوید. شما ممکن است چگونگی برخوردتان با نسخه بندی سرویس ها که در پروژه آزمایشی کانون توجه نمی باشد را شفاف سازی کنید. ممکن است برخی از خصوصیات خوب ارکستراسیون برای شما سودمند باشد، نسبت به اینکه امکان دارد زمان نداشته باشید و نیاز به اکتشاف اولیه داشته باشید.
این چیزها باید در مسیر SOA مرتب شوند. مسیر SOA تغییر می کند اما باید آن را به روز نگهداشت، و به یاد داشت که SOA یک سرمایه گذاری دراز مدت است. بزرگ فکر کنید اما خرد عمل کنید.