面向服務架構使用的太多了，所以來自于產品公司的熱心銷售與組織內過分使用的SOA應用的結合給人們造成了一個錯誤的幻像，那就是SOA可以解決所有問題。SOA是企業服務，展示整個企業的功能，這些都很難處理。在那里SOA仍然適用，但必須在更好的水平使用，而且要放在架構和集成及服務的適當位置上。

　　組織將會對一項技術進行投資，然后使用這一技術解決所有問題，這很常見。因此，人們在那些并不適合的地方使用過或將要使用SOA。然后他們就會發現它并不適合，就會指責它，說SOA并不是一項好的技術，因為它不能解決這一問題。同樣，人們將會以不合適的方式使用企業服務總線。

　　SOA可以用于解決大型系統中艱難的集成問題，在你需要定義接口的地方，尤其是在那些不同的組織或組織上的不同部門之間要定義的接口；以及在組織的不同部分之間你需要明確責任和定義合同。

　　今天SOA還是可行的，因為它還有許多不同的方式。那些在SOA和企業服務總線保護傘之下的技術是如此的不同。

　　對于SOA技能，在我的工作中，我看到架構同師們在處理非功能性（如性能、擴展性、總體穩定性以及應用程序處理用戶負載的能力）問題上，技能有點弱。我的建議是，他們最好是根據用戶的數量和響應時間，了解一下業務的實際需求。

　　我認為在過去的5至10年中，SOA技能已經被束之高閣了，這是因為功能驅動的開發方法的流行度正日益增長。新焦點已經集中在了把功能集成于應用中、測試單一用戶的工作環境，然后是簽署完成。因為精力集中在這些焦點上，協作、實現和非功能性需求測試常常會失敗。

　　架構師們常常忽略的是因為可能會工作的很，以及對于小量數據和用戶功能已經很完備。然而，他們常常不會在大環境中測試這些。所以，當用戶在大環境中使用它時，他們就會發現這一應用根本就不工作，因為架構不合適或他們又做錯了一個決定。

　　像AJAX這樣的技術使用有點過度，對于頁面你可以做一些地的，快速的異步事情。如果你的網站有一些用戶那么就會更好了；但當你有了10，000個用戶，所有這些用戶都在一秒鐘內發送他們的請求，來更新屏幕上的MessageBox，那么后端服務器的處理對這一負載的處理就會很難。

　　在這種情況下，為了解決非功能性需求，并正確收集需求，而建立SOA技能是很重要的一件事。從功能的焦點上轉移。學習如此關注那些需要解決的業務問題。這是一種使架構更好的工作，更有價值的工作的一種方法。