基于技术范围
跨越多个技术平台的功能服务范围使得保持与每一个技术平台同步的内在挑战时时存在。出售方努力用一种方式揭示工业标准来支持他们的解决方案并使得企业依赖于他们的架构，硬件和软件。基于技术的服务范围规范允许特定技术能力的高效使用。
在这个例子中，服务范围可以按照UNIX，Linux与Windows平台分类。基础服务比如错误记录，事务监控与时间处理是这类服务很好的处理对象。他们依赖于运行平台，但独立于驱动这个功能服务范围的商业过程。
基于应用范围
作为一种帮助企业面对更新现有系统需求的方法，企业应用集成的概念应运而生。现在，企业拥有大量前台应用系统，因此需要集成这些类似的系统，通过不同的方式处理、打包并提出同样的数据。
基于应用服务范围允许一个特定系统提供分组服务。这种方法使得管理和维持服务更加容易，因为一个领域内的系统对所有的服务都是一样的。
在上面的例子中，SAP，Siebel，PeopleSoft，IBMDB2与Oracle都是很好的基于应用范围的客户。这些范围中的一些典型服务列在下面。
SAP
●账户支付—帐目核对
●财政计算
PeopleSoft
●增加雇员
●更新补偿
Oracle
●数据复制
●基于账户信息的角色说明
服务打包
挑战
在SOA中，一个企业系统必须功能以服务为主。方便集成的构造系统可以很容易的做到这一点。面向结构的系统有一些困难。是一些集成电路应用构造了这些系统，系统包括了所有的商业规则与过程逻辑。这些信息被分配给多个多个连接程序的集合。
一个SOA支持独立的服务—没有任何其它服务的相关知识。结构化程序与特定上下文紧密联系在一起。这些结构化程序如何被再次打包围独立的服务？
方法
我们可以使用一个共有三个步骤地方法来应对这个挑战。这个方法包括在架构方案中定义逻辑商业领域、为这些商业领域分配程序集、并使两个程序集之间松耦合关联。这些步骤在下面详细说明：
1.商业领域定义.在这个步骤中，我们建立商业功能的逻辑域。我们可以使用程序调用规划图和过程流图来定义这些商业领域。我们也可以通过调节架构系统的程序间的关系来定义商业领域。[架构系统的程序往往是与其它程序有关。在这种程序到程序的关系中，有一些通用的商业方法。]
2.程序分配.在标准的商业领域，我们分配独立的程序到一个特定的领域。我们非常需要再分配那些没有讲自己关联到对应商业领域的程序，使在特定商业领域内排列更有规则。在前面讨论过的服务范围概念的引导下，这样一组程序集可以排列的更好。
3.松耦合关联.在这一点上，甚至即使这些程序已经在标准商业领域内排列过了，她们海狮需要彼此间相互关联。在最后这一步骤中，我们将原来的轻度耦合关联替换为一个更加松散的耦合。为了这样做，我们重新定义架构程序界面，这样其它的应用可以调节自己；程序提供同样输出并且接受同样输入，就像它们开始做的那样。这个重定义过程提供了一个非常好的机会来确保这些程序就像一个整体来服务企业，而不是单个程序独立服务企业—就像它们开始被创建时那样。这个方法同时也使现有架构系统朝着面向服务方向靠近，配置他们使它们在内部是结构系统，外部对服务用户来说是面向服务的。
