SOA和敏捷：是朋友?還是敵人?

SOA的目標是以服務作為構建企業應用的“積木塊”，使整個企業敏捷起來，而敏捷軟體開發則是通過引入一些最佳實踐來增加溝通與反饋，以達到同樣的目的。哪個是正確的？哪個更好？我們正在拿蘋果和桔子做比較吧？它們可以一起使用嗎？如果可以，那怎麼使用呢？很難用一篇文字來徹頭徹尾地評判SOA和敏捷，所以讓我們一同來關注它們吧。本文僅是關於這個討論主題中一系列文章之一，隨後將有更多的內容。

方法論和架構是互斥的嗎？

有人認為，軟體開發實踐與架構是不重迭的。在其它環境中這麼說也許是正確的，但在這個主題中卻不盡然。一方面，敏捷方法（例如XP）直接關注設計，不是特別同意預先做大量設計(BDUF)的觀點。另一方面，大多數SOA團隊主要是圍繞構建一系列服務而組成的功能性團隊。SOA本質上鼓勵有特性的團隊結構和團隊間的溝通方式，而這兩點又都屬於方法論的範疇。

敏捷與SOA是朋友

SOA是一種架構，強調業務必須能滿足市場要求，而且通過構建各種服務，可以消除重複，並達成“重用”這一很難捉摸的目標。團隊通過構建“服務”而非“應用”，來平衡企業內部和外部的工作。

敏捷是一種方法論，強調事物是變化的，軟體開發團隊必須擁抱變化，並對變化做出反應。通過引入技術性和非技術性實踐，團隊可以使業務敏捷起來。

架構和方法論是可以一同使用的，它們本質上是互補的。而且，SOA和敏捷的目標相同，它們都承認(1)變化是必然的(2)組織需要有效地應對變化。所以，我們期望在構建SOA時，能夠選擇敏捷方法論，反之亦然。對嗎？

敏捷和SOA是敵人

你可能認為既然目標相同，這兩種技術必定是一致的，沒有衝突的，也就意味著實踐與架構的重迭。但在這一點上，SOA社群和敏捷社群都有不同的聲音。為什麼會這樣呢？

主要原因之一就是，它們的出發點不同，最初的方向也不相同。儘管最近幾年敏捷快速發展，社群中獲得很多經驗並總結了“敏捷宣言”，並將其應用於大專案，但從發展史上看，敏捷還是“草根”，從小專案中走來。而SOA是新興的，具有自頂向下的本性，使用“分而治之”的方法來進行軟體開發。這種方法，尤其是其中的“分割法”,很容易會導致團隊間的溝通不暢，如文件、規範等等。

SOA和敏捷在以下三方面有衝突：

SOA鼓勵架構設計在前，而敏捷對這種稱為“BDUF”的方法持相反觀點。

SOA鼓勵按功能線索來劃分團隊，而敏捷傾向於以交叉功能式組建團隊。

SOA中，服務一旦建立起來，SOA就不再對服務的變化做出相關的反饋，而敏捷則強調及時反饋，無論是技術層面，還是人的層面。

當前現狀

現在，雖然很少有文章涉及這一主題，但我還是找到了幾篇文章：

Carl Ververs描述了使用一整套的敏捷實踐來構建一個SOA，並與開發人員共同完成了它（見Agile: The SOA Hangover Cure）。遺憾的是，這只是一個團隊構建了一套服務。在另一個InfoQ的訪談中，Geoff Henton和Tom Stiehm也討論了使用敏捷方法構建SOA。這篇檔案似乎說的是一個專案中的一套服務，它僅是一個敏捷嘗試，內部團隊的交流如何？當服務完成後，上百個客戶在使用這些服務，此時這些服務需要改變，如何維護呢？我建議：一是SOA團隊應通過測試而非文件進行溝通，二是Frank Grossman的觀點，但在異構環境中究竟該如何做呢？

此外,根據我對SOA團隊的個人觀察，從來沒有發現有在內部團隊方式上做任何敏捷實踐的。團隊被劃分開，實現各自的服務與應用，通過分散的會議、文件和WSDL進行溝通交流。SOA鼓勵BDUF，並很少為服務本身可能的變化做準備。

本文比較短，坦白地說，是因為我也不知道答案。這只是該主題上的第一個討論。我們將以開放的形式進行，總結過程中出現的重要問題並分別討論它們。歡迎並鼓勵任何評論。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-594434/，如需轉載，請註明出處，否則將追究法律責任。