1.你不能出售SOA。SOA可以使公司更靈活。SOA可以使公司更機敏。是的，如果沒有適應性和機敏性是不能建立業務解決案例或形成正當成本，你只能以解決業務問題為基礎來構建SOA。在應當的環境中SOA可以使業務方案解決業務問題:這就足夠了。
2.就算你可以出售SOA你也不能這么做，因為你不能向商人描述SOA到底是什么。事實上也沒有SOA的確切定義。即使作為一個概念SOA也是脆弱的，不同的軟件提供商和分析師會給出不同的(大量的)SOA定義。所以就連IT行業都沒有統一的定義，你怎么能夠期望商家可以理解這一概念?最好就是說SOA是代表一系列有效的技術。
3.業務流程管理(Business Process Management ，BPM)不是SOA。兩者并非必須共存的，當然，雖然沒有BPM的SOA可能會很靈活。
4.業務流程管理(Business Process Management ，BPM)處理引擎將成為SOA的潛在瓶頸。如果每一件事都是圍繞BPM套件布署，那么服務就不得不回到BPM處理引擎來接收指令，這樣一來BPM處理引擎就變成了SOA的瓶頸。所以，你可能需要有多個這樣的引擎以及一個“協調引擎的引擎”，就好比一個管弦樂隊。更好的方法就是擁有智能、恰當的服務，可以明白自己的路由，保存狀態信息:因此減少了對引擎的調用。
5.總之，僅有業務流程管理(Business Process Management ，BPM)是不夠的。BPM可以處理相對簡單的流程，但是當環境非常復雜時，尤其是業務不可掌控時，BPM則不能發揮作用。這就需要復雜事件處理((complex) event processing ,CEP)來協調。
6.在SOA領域，大多數軟件提供商都承認事件處理的潛在角色，但是大家都不理解這一角色的具體含義。例如，我曾見過在SOA中將復雜事件處理(complex event processing ,CEP)與BI型事件處理混淆不清的現象。當然，SOA中應有相應的CEP區塊(例如，生產監控而不是業務活動監控(BAM-Business Activity Monitoring)的實例監控――盡管應該將兩者結合起來)。Oracle公司明白事件處理，它將復雜事件處理CEP分配在SOA成熟模型的第五層:這樣很好，除非復雜事件處理CEP可以完全獨立與SOA單獨實施。
7.你不需要使用簡單對象訪問協議(simple object access protocol ，SOAP)。有趣的是該協議并不像大家期望的那樣簡單――有其他更為簡單的協議。
8.SOA面向服務體系結構的一個最大優勢就是能夠幫助企業重組應用程序，再利用服務。但是怎么再利用呢?我們不能對對象進行再利用，同時我們也不能對組件進行再利用，所以為什么我們認為我們可以對服務進行再利用呢?這是因為我們可以建立SOA管治、執行IT策略與標準，可是這樣就意味著開發人員將會嚴格執行策略嗎?什么時候有這樣的壓力?什么時候規定這項工作必須在明天之前完成?
9.討論一下管治，怎樣進行管治?――SOA與數據管治(data governance)之間的關系是怎樣的，舉例說明?如果管治的目的之一是為了對進程和數據建立所有權，那么就會出現一個問題，因為所有權就意味著責任，如果有一點點機會，人們就會逃避責任。為管治打造的理論模型都非常優秀，不過如果這些理論模型不能被應用于實際(至少有時可以應用于實際)，那么我們就需要一組更注重實效的“我們可以實際作到”的方案，而不是總是以理想狀態為目標。
10.大多數討論SOA的軟件提供商都忽略了數據這一塊(這里，IBM是一個例外)，許多公司的應用程序架構就像一團糾結在一起的面條，可是如果說SOA的作用就是解開、理清過去糾結在一起的面條，那么復雜的數據環境不也一樣嗎?
文章來源于領測軟件測試網 http://www.kjueaiud.com/
