从基础设施，技巧和组织变动上来看，面向服务架构的足迹令人生畏。值得注意的是，REST社区正试图通过最大限度地减少成本和最大化利用表现层组合能力来解决这个问题。
一项在Web上的快速搜索表明，极少有与资助SOA相关的话题。这个话题几乎像个禁忌一样很少有人提到。
Todd报道说，SOA Consortium资助调查的初步结果表明：
启动SOA项目的方式多种多样。其中一些利用一个SOA程序，还有一些希望服务开发能脱离现有项目。
以[他]的经验，[他]从未遇到过一个以SOA为唯一目的的资助项目。 [他]经常致力于一些商业项目和程序，它们希望能够把服务作为他们成果的一部分。
Todd评论说，虽然有可能解决初期的资金问题，但是进行中的SOA的资金仍然经常是一个问题。
该小组随后讨论了度量指标：
没有[度量指标] ，我们怎么能说明我们已经完成了一些事情了呢?为了展示我们更敏捷，[以及我们更具生产力的的开发解决方案] ，我们需要指标来衡量事情目前如何，未来会如何。
目前也有关联服务消费的度量指标：消费者数量，消费者使用率，最小/平均/最大响应时间等等。以我自己的经验，仅仅使这些度量指标可用，并使之达到一个比Web应用的入口点更精细的粒度水平就已经是非常有益了。
小组的第三个话题是服务的所有权。Todd评论到：
听到其他人说基于项目的IT文化会阻碍SOA的成功是很棒的事情。
如果你没有一个独立于客户的服务拥有者，那么每个客户都会尽可能的把事情推向对他们的项目有最大利益的方向，但却没有人会拥有自己的服务。这种内耗对SOA非常有害。
最后一个话题是服务组合管理（SPM）Todd比较了服务组合管理和应用组合管理，并建议尽早把重点放在服务组合管理，以避免因应用组合管理的不足造成混乱。在他的观点里：
如果有人说，他们暂时还不需要注册/仓库是因为他们还没有达到“临界规模”，这实在是犯了一个潜在的大错。
总体上讲，这方面的讨论说明，无论您选择了什么技术，与传统解决方案（打包或者定制）相比，服务的“形式因素”在SOA中的变化至少有三个层面：
项目管理：一个服务实施项目比一个典型的解决方案要小，然而它需要有严格的项目管理能力，这会在服务实现的顶层增加开销
一致性程度：企业层次的服务一致性程度远远高于一个典型的解决方案。一个成功的服务实施需要许多业务的代表理清他们的需求的主次以及路线图。
资金和所有权：这往往被划到项目领域之外。按照既定的进度安排、路线图和资金可能会造成交叉业务单元的冲突。
理解如何最有效地应对这一新的IT领域的形式因素很可能是值得的。因为有些人，如Dave Frankel，SAP实验室标准体系架构的负责人，认为SOA范式为支持新世纪正在兴起的主导性业务做了很好的调整。
