در این مرحله به دنبال این هستیم که آیا پروژه نرم افزاری پیشنهاد شده، کاندیدای مناسبی برای یک سرویس خواهد بود! برای این کار می توان به دو روش پیش رفت:
رویکرد از بالا به پایین و رویکرد از پایین به بالا
اجرای سرویس، خود به هیچ پلت فرم خاصی اشاره ندارد. اگر بخواهیم قسمتی از یک نرم افزار به عنوان سرویس در نظر گرفته شود باید دارای معیارهای زیر باشد:
۱. آیا این عملکرد می تواند به گونه ای تعریف شود که مفهوم سرویس را به درستی بیان کند؟
۲. آیا این سرویس قابلیت استفاده در میان چندین پلت فرم را دارد؟ یا نیاز به تعامل دارد؟ و آیا شرکای کسب وکار برون سازمانی از این سرویس استفاده ای خواهند داشت؟ آیا به عبور از فایروال یا موانعی دیگر نیاز دارد؟ آیا می تواند از پروتکلی معروف مثل HTTP یا SMTP استفاده کند؟

۳. آیا اجرای این عملکرد بعنوان یک سرویس به تسهیل یکپارچگی کمک میکند؟
۴. آیا به یک یا چند فرایند کسب وکار بطور واضح اشاره دارد یا به سادگیِ یک برنامه است؟
۵. آیا عملکرد سرویس قلمرو کار را پوشش می دهد؟
۶. آیا کسی در قلمرو کسب وکار به دنبال گزارش خروجی این سرویس خواهد بود؟ آیا حوزه IT به چرخه حیات یا زمان اجرای سرویس اهمیتی خواهد داد؟
۷. آیا این سرویس ارزش های کسب وکار را ایجاب می کند؟ وآیا چنین سرویسی با این عملکرد از قبل در جایی موجود می باشد؟
۸. آیا سرویس پیشنهادی در مرحله درستی از پیمانه ای شدن قرار دارد؟
۹. آیا سرویسی کردن این عملکرد، آن را قابل ترکیب خواهد کرد؟
۱۰. آیا کاندیدای ما ایده ای از چرخه حیات مشخص را نشان خواهد داد؟
۱۱. آیا قابل یافت بودن نرم افزار بصورت پویا مفید خواهد بود؟
۱۲. آیا به هدف فراهم کردن "Single version of truth" خواهیم رسید؟
۱۳. آیا بکار بردن XMl برای نمایش داده سودمند خواهد بود؟
۱۴. آیا اجرای این عامل بعنوان سرویس به کاهش هزینه یکپارچه سازی در آینده منجر خواهد شد؟

موارد بالا را نمی توان جزو اصول ثابت و اصلی دانست، این موارد فقط پیشنهادهای مناسبی هستند که در سازمان های گوناگون متفاوت اند.
بنابراین ایده "تبدیل تمام کارها به سرویس" در سازمان ها ایده ای کارامد نیست و باید ابتدا بررسی کنیم که سرویسی کردن کار مورد نظر به صرفه هست یا خیر.بنابراین، این ایده که "هرچه تعداد سرویس بیشتر، شرکت موفق تر" کاملا بی اساس است.
دریک سازمان هرچیزی نمی تواند سرویس شود و نباید هر چیزی تبدیل به سرویس شود. مشکلات مهم و اساسی وجود دارد که SOA و سرویس ها راه حل های خوبی برای آنها ندارند، با این حال وقتی سرویسی فکر می کنید، تمایل دارید هر پروژه جدیدی در شرکت را سرویسی بنویسید، با این دید نه تنها تضمینی به بازگشت سرمایه وجود ندارد بلکه منجر به ساخت تعداد زیادی سرویس خواهد شد، که از آن بعنوان Anti-pattern یاد شده، در واقع با داشتن سرویس هایی برای ساخت و ساختار SOA قبل از شروع باید به بررسی اینکه " کدام یک را می توان بعنوان کاندیدای سرویس برگزید" پرداخت و قبل از ساخت کاتالوگ سرویس باید بطور دقیق بدانیم که چه چیز را باید و چه چیز را نباید سرویسی کرد.
در شروع کارجمع بندی سرویس برای تحلیل و تعیین کاندیدای سرویس دو رویکرد اصلی وجود دارد:
رویکرد از بالا به پایین یا از پایین به بالا
در رویکرد بالا به پایین با بررسی حوزه های کلان کسب وکار سازمان، فرایندها شناسایی و سپس شکسته می شوند تا سرویسهای ارکستراسیونی و پایه استخراج گردند و سپس سرویس های دانه خردتر شناسایی شوند. در سوی دیگر با رویکرد پایین به بالا نسبت به تحلیل امکانات و قابلیت های سیستم های موروثی سازمان اقدام می شود تا سرویس هایی اتمیک و نرم افزاری قابل استخراج از این سیستم ها شناسایی شوند.
رویکرد از بالا به پایین، برای کسب و کارهای تازه کار که سیستم های ناهماهنگ کمتری دارند و در کل بیشتر رو به آینده هستند سودمندتر خواهد بود. و رویکرد از پایین به بالا، برای کسب و کار هایی مناسب خواهد بود که دهها سال است که در این حیطه کاری درگیر هستند، یا سیستم هایی از قبل دارند، یا از پلت فرم های مختلفی استفاده می کند و یا ارتباطات نقطه به نقطه فراوانی دارند.