#1：soa并不是一个纯技术方法
面向对象架构(soa)并不是一个纯技术方法，理解这一点对soa是非常重要的，尤其要在实践中获得成功更要明白这一点。soa模式的精髓在于对商业流程进行建模，而建模的过程并不一定有技术模块的支持。当然，最终，服务是被技术模块实现的，但是商业流程本身要比支持它们的这些服务重要得多。
作为一种技术，soa是一个工具，虽然这种技术本身没有提供直接的价值，但是和EJB或者.NET组件比较起来，soa是一种更为廉价在代码上构建服务的方式。soa还能带来其它的利益，比如改进的和更广泛的重用性，更有效的商业流程重组以及对商业流程更好的协调。
#2：soa并不意味着必须使用Web服务
很多技术人员对soa存在这样一种误解，认为soa意味着必需使用Web服务。事实上，尽管Web服务可以作为soa策略的一部分，但是它并不是必需的，服务的定义可以通过其它的标准协议来实现，HTTP并不是唯一的选择。和具体的实现技术相比，关注商业流程和服务的需求是更加重要的，通常，服务的环境可以帮助确定技术上的实现。
例如，对于包含了关键商业事务的服务，使用Web服务是有害的，因为通过soaP/HTTP协议来保证交易属性是很困难的。而且，很多服务需要进行异步操作，在这种情况下，基于队列和通道的消息系统是实现服务载体的更好的候选方式。当然，负载的数据和界面依然可以使用XML来定义。
#3：soa可以使用现有架构进行构建
很多公司对于soa可以使用现行架构这一点非常惊讶，比如.NET和J2EE平台都提供了对开发Web服务、解析和生成XML的支持，还提供了通过MSMQ和JMS与消息系统通信的支持。
在soa中通常缺失的是流程管理层或流程自动化层，不过，很多公司已经在企业应用集成(enterprise application integration (EAI))工具上进行了投资，很多EAI工具提供了流程自动化和管理层的功能，它们可以在现有的软件或者.NET与J2EE平台之上对服务进行访问。
#4：soa是一种(从组件、对象等)进化而来的方法
面向对象架构并不是一种全新的解决方案，soa是技术与架构的进化。系统架构在不断进步，与商业的配合也越来越好，系统架构师与商业经营者在长期以来都深深地理解了技术与商业流程的协调的重要性，其中包括了对技术资源更好的使用与协调，以及对商业更好的支持。
soa也在一定程度上源于企业架构理论。企业架构对技术进行评估，但是更重要的是它关注整个企业和全部的商业流程并提供了做出技术决策的信息背景。soa工具则融合了互联网技术，比如HTTP和XML，以及综合技术，比如消息总线、转换技术和连接技术。
#5：流程自动化是soa的关键优势
很多企业和技术专家的误解在于他们将焦点关注在服务架构上服务的实现和传递，但不幸的是，他们没有抓住重点，soa的真正价值体现在它是一个商业自动化工具。最终，软件和系统将会创建商业或公司的效率，这可以被定义为企业实施的活动或者流程。对于soa，不应该将焦点关注在服务上，而应该放在流程上，以及如何改进这些流程。
当然，服务在支持流程方面是必需的，但是对于提高效率和改进流程的目标而言，它们是第二位的，服务本身的价值是有限的。
#6：soa架构可以是高度复杂的
从某一角度而言，soa架构可以是相当简单的，例如，开发一个商业流程并发现其中所需的服务，这种思路的逻辑是非常直接的。但是，要在数据和服务之间进行平衡，并实现有意义的目标则要复杂得多了。
让我们来思考这样一个场景：用户使用订单服务在系统中下订单。这是很简单的操作，但是如果您希望将订单上的数据和来自其它服务的数据关联起来呢？如果所有的服务共享同一个数据源，您可以跳过服务层，并生成报告。但是如果有些数据来自其它服务自有的数据源，有些数据来自古老的主机系统，而另外一些数据来自商业软件(比如SAP)，将这些数据集成在一起的工作将是非常非常复杂的。
#7：soa需要对商业数据的深入理解
因为soa关注于商业流程，因此理解这些与流程密切相关的数据是至关重要的。例如，一个订单流程会包含很多重要的数据信息，比如订单、客户、发货信息、发票、付款和收据；更重要的是能够以一种标准化的方式来描述这些数据信息，从而使流程中的每个服务都能按照相同的方式理解这些数据信息。
对于拥有信息架构的企业而言，这并不是一个大问题，但如果没有信息架构或者信息架构的支持有限的大企业中，这一问题会导致实施过程中的长时间中断。
因为大型企业通常拥有多种数据，所以通常建议他们采用进化的方式来定义信息架构，这是与“大爆炸”方式相反的方法。这意味着不必花费四年的时间来定义数据模型，而只需要在开发服务的过程中花费少量时间来定义与那些服务相关的数据。这样，在每个服务或者流程实现的时候，相关联的信息架构就可以同步展开并包含必需的数据信息。
#8：服务可以是简单体也可以是复合体
定义服务可能是一个艰巨的任务，在某些情况下，需要那些服务是清晰而简明的；很多时候，服务是相当简单的，例如一个查找客户的服务，可能需要使用一些标准来查找用户并为服务的使用者提供标准化的客户记录。
然而，服务是可以复合的，这意味着一个“超级服务”可以提供一个标准的接口，就像我们刚才查找客户的服务所提供的那样。但是这个在例子中，所有的客户信息都存储在同一个资料库中，这对于服务而言是很容易进行查找功能的。
但如果一些客户资料存放在大型主机中，一部分存放在SAP中，一部分存放在其他的应用软件中，而另外一部分存放在Oracle数据库中呢？让我们假定在每一种系统上已经构建了查找服务的接口，换句话说，我们拥有在大型主机、SAP、其他的应用软件和Oracle数据库上查找客户的服务。现在，我们新的查找客户的服务可以使用所有这些现有的服务来查找客户。
