我们假设SOA Worker是一个实体，用以对实际需要它的人交付结果或者实际世界的效果。我们是在谈论SOA服务吗？

　　不够准确。在A公司，我们有一个SOA生态系统，包括所有服务、所有服务消费者、所有服务提供者、所有策略或者现有服务的实施方式，像流程（操作和自动化）、信息资源、服务管理方法等等。

　　SOA服务试图为消费者交付所期望的结果。然而，并不是所有服务结果都是消费者最初需要完成的；一些服务致力于协助其他服务交付所需结果。这和业务手工流程以及为业务操作提供自动化和信息存储的IT系统相关。为了在SOA系统中交付最大化的效用，IT必须使用基于面向服务架构的系统。像这样基于SOA的系统就是SOA Worker吗？

　　我们已经接近答案，但还不是答案。

　　如果我有一个需求或者一个业务问题，首先我要考虑这个问题的解决方案。如果我操作一个SOA环境，我可能寻找一项基于SOA的解决方案。什么服务和有多少服务应该交付结果，具体的基于SOA的系统应该设计哪些对于我来说都很重要。因此，我正在操作的是整个系统的解决方案层面的东西。

　　我怀疑在实际生活中，并不是在IT中，任何人会说具体的RWE是同基于SOA的系统XYZ交付的，我们说针对你的问题，我们有一个基于SOA的解决方案。如果我们需要使用具体的系统或者业务专家团队，这就是我们内部的事情，我们自己交付解决方案。基于SOA的解决方案就是SOA Worker。

　　如果业务人员和技术架构师开始思考基于SOA的解决方案，我们同乡业务和IT敏捷性的“天堂”之路就已经走了一半了。举个例子，一个技术架构师正在从数个系统中收集确定的信息，并保持和相关复杂业务规则的一致性。她可以从这些系统中检索出信息，但是她需要一项服务执行规则引擎操作，来过滤业务规则需求所需的数据。不幸的是，并没有资金来获取和支持规则引擎。

　　如果架构师仅仅考虑技术任务决议，这就是个失败的案例（尽管规则引擎是开源产品，它仍需付费支持。）。然而，如果在解决方案内思考的话，就有多种可能性。例如，业务文员了解规则，他们可以在处理数据的时候使用这些规则。这意味着，架构师仅仅可视化回收数据和将这些数据描述为业务文员能够过滤的数据，“手动”显示在屏幕上，适用于其经验即可。这种过滤的结果可能被报告为解决方案结果。但这并不是一个纯粹的技术解决方案，也没有人说它是一个纯粹的技术不是吗？

　　功能的手工/技术组合就是服务，交付所需结果。在面向服务的阶梯中实现工作。这也是SOA环境中的结果。