面向服务架构以及其周围的系统都是分布分散，SOA提倡对现有服务的重用，但是需要由不同的小组管理这些资产。这就为许多试图采用SOA的机构带来了新的挑战。每个服务都有其与众不同的生命周期，这就会引发从属性和同步性问题。在SOA顶层执行的业务流程和这些脆弱的组件一样。如果其中的一个从属性出现了问题或者该从属性无法满足SLA（服务层面协议）要求，不管系统的其它部分怎样坚固，流程都会因此而垮掉。

　　本文分为两个部分，意在解决SOA质量问题和多层系统问题。第一部分将从机构层面探讨质量问题，并按照小组形式将这些问题所带来的负面影响降到最低。本篇文章为信息共享和相互合作提供了一个框架，也为人们从质量方面提供了一个新的视角。

　　分布式开发：一个实例

　　我们以面向消费者的Web应用为例，你可能有一个为用户的产品和服务提供注册方式的应用，销售人员看到这些要求后，对这些要求做出评估，他们要么赞成，要么反对。这个客户要求/评估流程取决于后端服务，后端服务通过检索用户数据决定这些要求是否合格。在大多数情况下，负责网络前后端UI（关注HTML设计，工作流程页面等）的工作组和企业服务小组不同——该小组意在维护后端Web服务（关注WSDLs， SOAP以及XML）。

　　在当今的技术环境下，这样的分工无疑有着深刻的意义。技术领域专业知识的多样性造就了细致的分工和更为专业的服务。从此之外，还可以使用其它那些和用户网站不同的应用。但是，要想满足功能和非功能性需求，必须要确保那些关键的业务流程得以实施（例如一个用户在线要求一个产品，销售人员必须马上做出评估）。因此，我们必须用完整的方法解决这个问题，因为业务流程和系统中那些薄弱的环节一样重要。不管哪个方面出了纰漏，都会对客户造成影响。
　
　　描述机构作用

　　大多数机构依靠相同的质量小组解决这个问题，这些小组执行和QA相关的任务，例如：不同程序员组的要求，审定和测试。但是，这个方法尤其是在包含了所有测试活动的QA得到充分应用之后，在SOA环境下没有可行性，难点就在于审定不同小组的工作，需要不同的专业知识。其次，不同业务流程的重用将应用测试和效验的种类限定在面向用户的组件范围内。忽视了一些底层服务组件的关键技术质量细节例如标准一致性和互操作性。第三，像一个模型所需的周期时间可能会超过项目迭代——产生了许多费用和致使时间延误。因此，另一个方法就是将质量机构作用分为两个层面：

　　1）单个小组的技术层面，一个小组负责一个服务或者和质量相关任务的组件。这些小组是由许多了解技术领域的个人以及质量原则组成的，这些质量原则需要在这个层面上得到解决。在我们举的例子中，Web服务小组要执行那些和Web服务相关的质量原则，Web应用小组则负责执行与UI前后端相关的质量原则。

　　2)业务流程小组，这里的成员大多关注不同业务工作流下的终端用户经验。这个工作小组和业务分析师协同工作，以确保每一个业务流程都顺利实施，并被底层小组整合。