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，并很少為服務本身可能的變化做準備。

原文轉自：http://www.kjueaiud.com