这就是人们产生困惑的根源：POA实际上只是一种观点。有些时候人们把SOA看做是单一的一种观点，但是ZapThink却认为SOA是一种更为宽泛，包含多重理念的事物。如果你仅仅从狭义上将SOA定义为一个叫做POA的自下而上的方法。但是ZapThink的定义更为宽泛，包含了POA部分。对于我们来说，SOA是以流程为中心的，也是自上而下或者自下而上解决架构问题的最好方法。但是，仅靠其中一种方法是远远不够的——你必须同时兼有SOA 和POA。

　　参考架构的作用

　　幸运的是，致力于帮助大家扫除疑惑的公司并非只有ZapThink一家，像SOA Blueprints、 OASIS SOA 参考模型技术委员会也在潜心研究参考架构和参考标准——尤其是那些设计师开始处理结构问题所使用的其它工具。但是，我们到底是需要一个包含所有观点的参考模型还是需要包含多种观点的多个模型？这始终是个悬而未决的问题。那么你是不是需要一个包含所有观点（或者至少能够协调观点）的拱形的参考模型呢？广义的参考模型可能从本质上来说就是服务定向？

　　ZapThink认为广义的服务定向原则会导致一个以服务为导向，流程定位，事件驱动的包含参考模型的诞生。现在问题的关键是为什么要称之为包含参考模型。是把SOA限定为狭义的技术模型还是将SOA延伸为更为广义的模型。你称其为Fred——我们所关心的是这个术语不要阻碍我们在架构和实施方面获得成功。有时人们把大部分精力都浪费在了对这个术语的争论上，而忽略了实践。

　　还有一个问题，狭义的SOA,EDA和POA是否应该被区分为不同的模型——这种区分是否能够真正解决问题，还是将原有的问题复杂化了？如果SOA应该以事件为驱动，以流程为导向，EDA和POA是否应该是以服务为导向的——现在你应该明白——将三者区分为不同的模型是否真的有用呢？问题的答案是取决于模型所要展示的是什么。如果这些狭义的模型真的在更为广义协调模型的背景下代表了不同的观点，那么这些模型就能充分发挥作用。最后我们要做的是将架构的实践部分分散成几个TLA筒仓。

　　ZapThink采取的措施

　　多年来，ZapThink一直在讨论结构观点，但是结构观点不是由我们最先提出的。实际上，Philippe Kruchten早在1995年的文章"架构 4+1视图模型 ."就描述过这个观点。ZapThink借鉴了Kruchten原有的架构 4+1视图模型，并且针对SOA把该观点进行了修改。Kruchten的模型和我们的模型的最大的不同之处就是这个额外的"+1"视图是用例视图，但是在SOA中架构并不解决单个的用例视图，而是用于回应模糊的业务需求。因此，用例视图更为重要，就像以服务为定向的设计师必须协调各种观点以保证能够灵活的从架构中受益。

　　很显然，我们这里谈到的SOA，指的是广义上涵盖所有个别观点的SOA。但是我们谈到的SOA更多的是指这个概念的实践而非其形成过程。如果你认为SOA的形成是一层不变的，你就无法将灵活性注入架构。因此在面临无法预测的业务变化时，SOA必须提供灵活性。所以，解释SOA的最好方法不是试图解释它到底是什么，而是真正的付诸实践。