中央治理委员会可以充当中立方，负责开发规范数据模型。作为应用程序调查和服务设计工作的一部分，还可以设计在服务调用中使用的公共数据格式。

　　服务监视

　　如果服务提供者停止工作，您如何知道呢?是否要等到使用这些服务的应用程序停止，使用这些应用程序的人开始抱怨，才会知道服务已停止了呢?

　　结合使用多个服务的组合应用程序的可靠性只与其依赖的服务的可靠性相当。由于多个组合应用程序可能共享一个服务，单个服务出现故障可能会影响很多应用程序。必须定义 SLA，以描述使用者可以依赖的可靠性和性能。必须监视服务提供者，以确保其达到了所定义的 SLA。

　　一个与此相关的方面是问题确定。当组合应用程序停止工作时，确定为什么会这样。这可能是由于应用程序用于与用户进行交互的 UI 停止了运行造成的。但也可能 UI 运行正常，但所使用的其他服务或这些服务使用的某些服务未正常运行。因此，务必注意，不仅要监视每个应用程序的运行状况，还要监视每个服务(提供者整体)和各个提供者的运行状况。单个业务事务中服务间的事件的相关性非常重要。

　　此类监视可以帮助在问题出现前检测和防止问题。可以检测不均衡和停机状况，能在这些情况造成重大影响前发出警告，甚至可以尝试自动纠正问题。可以对长时间的使用情况进行度量，以帮助预测使用率会变得更高的服务，以便为其提供更高的容量。

　　服务所有权

　　当多个组合服务使用一个服务时，谁负责此服务?是那个人或组织负责它们吗?如果是其中一个，是哪一个?其他人是否认为他们拥有这个服务的所有权?欢迎来到服务所有权的混沌世界。

　　无论是社区公园、可重用 Java 框架，还是服务提供者，任何共享资源都很难获得和得到相应的照顾。不过，所需的采用池化技术的资源可提供远远超过任何参与者成本的价值：公路系统就是这样。

　　企业通常围绕其业务操作组织员工报告结构和财务报告结构。SOA 采用相同的方式围绕相同的操作组织企业的 IT，负责特定操作的部门也可以负责这些操作的 IT 的开发和运行。该部门拥有这些服务。SOA 中的服务和组合应用程序经常并不遵循企业严格的层次报告和财务结构，从而在 IT 责任方面造成空白和重叠。

　　一个相关的问题就是用户角色。由于 SOA 的重点是保持 IT 和业务的一致，而另一个重点是企业重用，组织中很多不同的人员对什么将成为服务、这些服务如何工作以及将如何使用都有发言权。这些角色包括业务分析人员、企业架构师、软件架构师、软件开发人员和 IT 管理员。所有这些角色在确保服务正确为企业需求和工作服务方面都负有责任。

　　SOA 应该能反映其业务。这通常意味着要更改 SOA 来适应业务，但在这种情况下，可能有必要更改业务来与 SOA 匹配。如果不可能，则需要提高多个部门间的合作水平，以分担开发公共服务的任务。这样的合作可以通过跨组织的独立委员会来实现，此委员会实际上拥有服务，并对其进行管理。

　　服务测试

　　服务部署生命周期包括测试阶段，在此阶段，团队将在激活服务前确认服务能正确工作。如果测试了服务提供者，且表明其工作正常，使用者是否需要也对其进行重新测试?是否采用同样的严格要求对服务的所有提供者进行测试?如果服务更改，是否需要对其进行重新测试?

　　SOA 增加了以独立的方式测试功能的机会，并提高了对其按预期工作的期望值。不过，SOA 也为每个不一定信任服务的新使用者提供了重新测试相同功能的机会，以便确定服务一致地工作。同时，由于组合应用程序共享服务，单个存在错误的服务就可以对一系列看起来不相关的应用程序造成负面影响，从而扩大这些编程错误的后果。

　　为了利用 SOA 的重用好处，服务使用者和提供者需要就提供者合理的测试级别达成一致，并需要确保测试按照双方达成的协议执行。然后，服务使用者只需要测试自己的功能以及到服务的连接，并假定服务将按照预期的方式工作。