Боюсь, что без какой-то целевой архитектуры, для которой решается проблема, эту задачу не решить. Поэтому я бы сформулировал так:
а) дана система деятельности (например, описанная в ISO 24744). Эта деятельность пользуется некими акторами, часть их которых живые, часть неживые (tools).
б) дан набор (хардверных, софтовых и т.д.) компонент (например, продаваемых дистрибуторами/дилерами "модулей" каких нибудь CAD или ERP -- и нужно сообразить, какие из всех возможных компонент каталога вендоров нужны для данной деятельности), которые обеспечивают потребные деятельностью возможности.
в) требуется создать промежуточное описание в независящих от реализации в компонентах терминах сервисов, в которой видно, как и когда система деятельности юзает эти самые сервисы, а сервисы понятно как раскладываются по компонентам. Если такое описание не получать, то тогда нужно пытаться относительно абстрактное (в отвязке от конкретных физлиц , "в ролях", и часто без явной привязки к оргструктуре) описание деятельности сразу приклеивать к "компонентам" -- т.е. про деятельность мы уже можем думать абстрактно, а про софт -- только в терминах поставки "модулей" теми или иными дилерами, или компьютеров их дилерами. Нужно иметь возможность думать про IT тоже в абстрактных терминах.
А пока kir_lis дал небольшой обзор самых разных подходов к SOA -- http://kir-lis.livejournal.com/551.html