本文探討了各種方法，例如 Scrum、極限編程（Extreme Programming，XP）、Crystal、動態(tài)系統(tǒng)開發(fā)方法（Dynamic Systems Development Method，DSDM）等等，它們專注于精益軟件開發(fā)（Lean Software Development，LSD）的概念。在這個(gè)由兩部分組成的關(guān)于敏捷軟件開發(fā)的系列中，作者詳細(xì)地評估了它們對于開發(fā)面向服務(wù)的體系結(jié)構(gòu)（Service-Oriented Architecture，SOA）的適宜性。

引言

正如我們在本系列的第 1 部分中所闡釋的，面向服務(wù)的體系結(jié)構(gòu) (SOA) 和敏捷開發(fā)兩個(gè)概念都旨在用于可適應(yīng)的企業(yè) IT 系統(tǒng)。然而，在關(guān)于 SOA 開發(fā)和敏捷方法的主題的 CBDI 說明中提到，敏捷開發(fā)和 SOA，就如同油和水一樣，不能溶合在一起。所以，如果頭腦中已經(jīng)有了這樣的想法，您還真的可以像 SOA 那樣來將敏捷開發(fā)原則擴(kuò)展到多應(yīng)用程序環(huán)境中嗎？在本系列的這一部分中，我們提供了證據(jù)來證明答案是“肯定的”。

SOA 和精益軟件開發(fā)：Fit-Gap 分析

通過依次介紹每個(gè)精益軟件開發(fā)原則，我們研究如何使用它們來使 SOA 的開發(fā)從中受益。除此之外，我們還討論了它們在使用敏捷方法的環(huán)境中的好處。下表給出了 LSD 原則與其在敏捷方法的環(huán)境中帶給 SOA 開發(fā)和交付的基本好處之間的初始高級映射。

表 1. LSD 與 SOA 原則的初始映射

LSD 原則	SOA 的好處
1. 消除浪費(fèi)	寬度優(yōu)先的服務(wù)模型開發(fā)有助于識別正確的服務(wù)候選者和重用能力。 值流映射 (Value stream mapping)，一種用于系統(tǒng)地檢測沒有價(jià)值的處理步驟的技術(shù)，使您能夠識別有價(jià)值的服務(wù)。
2. 加強(qiáng)學(xué)習(xí)	反饋有助于定義重用的服務(wù)。 同步在服務(wù)的實(shí)現(xiàn)階段特別有用。
3. 盡可能晚地決定	不確定服務(wù)接口的細(xì)節(jié)使得有可能通過實(shí)踐來學(xué)習(xí)。
4. 盡可能快地交付	使用服務(wù)的情節(jié)串連圖板 (Storyboard) 和“SRC 卡片”（服務(wù) (Service)、責(zé)任 (Responsibility)、協(xié)作 (Collaboration)）來創(chuàng)建更小的工作單元和更高的吞吐量。 創(chuàng)建約定的一個(gè)簡單的經(jīng)濟(jì)模型，可以用于驅(qū)動開發(fā)決策。
5. 向團(tuán)隊(duì)授權(quán)	通過授權(quán)和委托微觀設(shè)計(jì)決策給負(fù)責(zé)交付 SOA 中的服務(wù)的專業(yè)人員，您增加了交付服務(wù)的能力，該服務(wù)滿足當(dāng)前的業(yè)務(wù)需求，而不是先前預(yù)測的或者規(guī)定的業(yè)務(wù)需求。
6. 構(gòu)建完整性	通過簡化端到端的通信流程，確保業(yè)務(wù)流程和交付的 IT 服務(wù)之間具有更強(qiáng)的耦合性以及期望的服務(wù)質(zhì)量（Quality of Service，QoS）。這種方法使開發(fā)人員能夠確保交付的服務(wù)具有所需的完整性。 通過解構(gòu)代碼和體系結(jié)構(gòu)，確保開發(fā)和部署的服務(wù)能夠交付所期望的 QoS，同時(shí)支持業(yè)務(wù)環(huán)境的持續(xù)改變。使用這種服務(wù)模型使受控解構(gòu)成為可能。
7. 眼觀全局	就其真實(shí)的本質(zhì)來說，SOA 專注于業(yè)務(wù)流程聯(lián)合，重點(diǎn)在于企業(yè)。通過確保工作團(tuán)隊(duì)堅(jiān)持把工作重心放在全局性的問題上（眼觀全局），您實(shí)現(xiàn)了用于確保服務(wù)驗(yàn)證和編排與核心業(yè)務(wù)流程緊密配合的最佳實(shí)踐。

讓我們進(jìn)一步詳細(xì)地討論上面的表 1 中定義的映射：

原則 1：消除浪費(fèi)

寬度優(yōu)先服務(wù)模型開發(fā)

為了理解什么是重要的以及什么是多余的，使用寬度優(yōu)先 (breadth-first) 取代深度優(yōu)先 (depth-first) 是明智的，先取得總體認(rèn)識，然后再深入細(xì)節(jié)。當(dāng)開發(fā)企業(yè)級 SOA 時(shí)，您應(yīng)該避免以遺漏關(guān)鍵部分為代價(jià)來預(yù)先構(gòu)建系統(tǒng)無關(guān)緊要的部分的詳細(xì)分析文檔目錄。當(dāng)然，很難預(yù)知未來和靈活性的需求；因此，快速反饋是必要的。

一些來自面向服務(wù)的建模和體系結(jié)構(gòu)方法（Service-Oriented Modeling and Architecture Method，SOMA）的技術(shù)很好地支持“寬度優(yōu)先”方法，即：自頂向下 (top-down) 域分解、自底向上 (bottom-up) 現(xiàn)有系統(tǒng)分析以及目標(biāo)-服務(wù)建模（請參閱文章“Service-oriented modeling and architecture”）。在經(jīng)過總體觀察以后，決定在服務(wù)組合 (Service Portfolio) 中包含哪些服務(wù)。只有到這個(gè)時(shí)候，您才能詳細(xì)地定義服務(wù)。

值流映射

映射值流是開始發(fā)現(xiàn)流程中的浪費(fèi)的一種好方法。它把重點(diǎn)放在用戶的產(chǎn)品及其價(jià)值上，而不是組織、資產(chǎn)、技術(shù)、流程和人員上。利用值流映射的結(jié)果，您可以將精力投入到給組織帶來最多價(jià)值的流程和服務(wù)上。挑選最大的機(jī)會去增加流動和增值時(shí)間 (value-added time)。您可以利用這項(xiàng)技術(shù)來分析業(yè)務(wù)流程（將由 SOA 支持）或者軟件開發(fā)流程（用于開發(fā) SOA）。

原則 2：加強(qiáng)學(xué)習(xí)

反饋

服務(wù)的“用戶”是應(yīng)用程序。預(yù)先設(shè)計(jì)一個(gè)用于所有應(yīng)用程序的最佳重用的服務(wù)接口是不可能的。實(shí)際上，您是從初始的接口和演示程序開始，然后部署服務(wù)，最后從使用的應(yīng)用程序獲得反饋。一個(gè)小先遣隊(duì)開發(fā)了一個(gè)簡單跨系統(tǒng)的試驗(yàn)應(yīng)用程序：

• 采用一個(gè)業(yè)務(wù)流程
• 分析和設(shè)計(jì)它的服務(wù)
• 原型化用戶接口
• 與后端集成
• 跨整個(gè)流程

如果可能，試驗(yàn)應(yīng)用程序應(yīng)該變成產(chǎn)品。當(dāng)這種跨系統(tǒng)的應(yīng)用程序在生產(chǎn)中得到證實(shí)時(shí)，您就知道了您有了可工作的應(yīng)用程序。到了那時(shí)，多個(gè)小組就可以使用一樣的方法并且每次進(jìn)行多項(xiàng)工作。

與采用瀑布方式開發(fā)整個(gè) SOA 相比，依賴于快速交付和頻繁反饋甚至更為重要，這是因?yàn)槟豢赡艿谝淮尉妥龀稣_的設(shè)計(jì)。敏捷方法推動了快速反饋和熱點(diǎn) (Hot Spot) 的出現(xiàn)，這里需要靈活性。工程實(shí)踐（例如測試優(yōu)先開發(fā)和持續(xù)集成）減少了開發(fā)人員獲得反饋的時(shí)間。增量功能的頻繁交付支持來自客戶或用戶的直接反饋。

同步

敏捷方法至少使項(xiàng)目間的依賴關(guān)系可見，并且還有一些處理它們的工具（請參閱本系列第 1 部分中的 Scrum 部分）。項(xiàng)目間頻繁同步的想法在服務(wù)的實(shí)現(xiàn)階段特別有用，這里可能發(fā)生服務(wù)范圍內(nèi)的改變，因?yàn)檎窃谶@一階段詳細(xì)地分析服務(wù)。

原則 3：盡可能晚地決定

不確定服務(wù)接口的細(xì)節(jié)

在像 SOA 這樣企業(yè)級的約定中，似乎最好是在非常詳細(xì)的層次上設(shè)計(jì)服務(wù)接口，讓不同的項(xiàng)目來實(shí)現(xiàn)它們。這種方法的優(yōu)點(diǎn)好像是服務(wù)應(yīng)用程序可以獨(dú)自工作，而不需要長期地與其他項(xiàng)目同步。遺憾的是，這并不能正常工作，因?yàn)槟鸁o法預(yù)先確定所有的細(xì)節(jié)。面對不確定性，這樣做的結(jié)果就是導(dǎo)致浪費(fèi)（以錯(cuò)誤的細(xì)節(jié)的方式）。長期進(jìn)行來實(shí)現(xiàn)錯(cuò)誤細(xì)節(jié)的項(xiàng)目將難以使它們的代碼解構(gòu)變得簡單。這會產(chǎn)生一個(gè)未達(dá)到最佳狀態(tài)、卻又固定的服務(wù)模型。

盡可能晚地決定意味著，在有證據(jù)可以清楚地判斷服務(wù)應(yīng)該是什么樣子之前，不確定服務(wù)接口的細(xì)節(jié)，而不是假裝無所不知。這就促使開發(fā)小組與公司的其他部門經(jīng)常性地保持步調(diào)一致，而且它還產(chǎn)生更好的服務(wù)模型。

原則 4：盡可能快地交付

拉系統(tǒng)

敏捷開發(fā)中的拉系統(tǒng) (Pull System) 借助于信息發(fā)射源 (Information Radiator) 使人們能夠自己確定去做什么（例如，走廊上可能有一個(gè)白板，所有相關(guān)的用戶素材都寫在上面的卡片上；分配工作意味著將素材卡片 (Story Card) 從白板的“to-do”區(qū)移到“checked-out”區(qū)）。

在 SOA 環(huán)境中，您可以在卡片上編寫用戶素材和服務(wù)。通過添加服務(wù)，工作單元甚至變得更小，因?yàn)檎绫鞠盗械?a >第 1 部分的 SOA Application 部分中所述，功能性是在用戶界面應(yīng)用程序、服務(wù)編排以及服務(wù)應(yīng)用程序之間分配的。排隊(duì)論指出，更小的工作包產(chǎn)生更高的吞吐量，例如功能的更快交付。

眾所周知的用于面向?qū)ο?(OO) 設(shè)計(jì)的 CRC 卡片（類 (Class)、責(zé)任 (Responsibility)、協(xié)作 (Collaboration)）技術(shù)（請參閱 A Laboratory for Teaching Object-Oriented Thinking 以獲得背景信息）可以修改成 SOA 設(shè)計(jì)中的 SRC 卡片。“面向服務(wù)的分析與設(shè)計(jì)原理”包括這種技術(shù)的初始示例。

約定的經(jīng)濟(jì)模型

傳統(tǒng)上，軟件開發(fā)有時(shí)被看作是產(chǎn)生成本。近來，軟件開發(fā)被看作是產(chǎn)生收入，可以幫助利用經(jīng)濟(jì)期權(quán)。基于期權(quán)的軟件經(jīng)濟(jì)從金融市場提取出相似之處：交付運(yùn)行的軟件的短期迭代被看作是實(shí)物期權(quán) (Real Option)。就像金融期權(quán) (Financial Option) 一樣，實(shí)物期權(quán)通過現(xiàn)在非常少量的投資，來向您提供可能從未知的將來獲得收益的機(jī)會。

但是并不需要走那么遠(yuǎn)：如果您創(chuàng)建約定的簡單經(jīng)濟(jì)模型并使用它來驅(qū)動開發(fā)決策，甚至 SOA 約定也將從中受益。有了這個(gè)經(jīng)濟(jì)模型，就可以向團(tuán)隊(duì)成員授權(quán)，讓他們自己明確什么對于業(yè)務(wù)是重要的：他們可以都從相同的假定開始工作。如果您考慮減少一些特性，銷售部門可能推測出，沒有這些特性，他們將少銷售百分之“X”單位的產(chǎn)品。

原則 5：向團(tuán)隊(duì)授權(quán)

對于任何軟件開發(fā)，最有資格作決定的人就是在第一線工作的人。在解決方案體系結(jié)構(gòu)層次上仍然需要嚴(yán)格的控制，而基礎(chǔ)服務(wù)開發(fā)應(yīng)該盡可能地靈活。通過授權(quán)給最接近實(shí)現(xiàn)的專業(yè)人員去做微觀決策，您可以確保服務(wù)的最終代碼滿足所需要的功能性。在企業(yè) SOA 中，您可以從授權(quán)和委托設(shè)計(jì)決策給服務(wù)的開發(fā)人員（在定義的范圍內(nèi)）中受益。

無論何時(shí)沿著層次結(jié)構(gòu)向下委派決策權(quán)，您都必須確保所有的決策者都理解了統(tǒng)帥全局的愿景。通常，決策應(yīng)該始終的是大家共同參與的活動，而不是孤立的活動。跨功能團(tuán)隊(duì)的環(huán)境（出現(xiàn)在敏捷項(xiàng)目中）促進(jìn)了決策協(xié)作。

原則 6：構(gòu)建完整性

構(gòu)建在概念上具有高度完整性的 SOA 的方法是從客戶到開發(fā)團(tuán)隊(duì)、以及開發(fā)團(tuán)隊(duì)的上游流程和下游流程之間都有良好的信息流。從我們的角度來看，我們認(rèn)為這一原則在服務(wù)開發(fā)層次以及服務(wù)編排中具有很高的價(jià)值。通過維持業(yè)務(wù)和 IT 專業(yè)人員之間良好的通信水平，可以確信您所交付的 IT 解決方案滿足當(dāng)前以及未來的業(yè)務(wù)流程和需求。隨著結(jié)構(gòu)良好的 SOA 中的業(yè)務(wù)和 IT 之間的聯(lián)系越來越緊密，逐漸要求所交付的服務(wù)能夠滿足和緊密配合超出目標(biāo)的業(yè)務(wù)流程。如果沒有這種高層次的完整性，那么交付的服務(wù)不滿足必要的業(yè)務(wù)要求或 QoS 的風(fēng)險(xiǎn)將會增加。

解構(gòu)

現(xiàn)在，在 IT 產(chǎn)業(yè)中解構(gòu)開發(fā)代碼的實(shí)踐得到認(rèn)可已經(jīng)有一段時(shí)間了。在 SOA 的環(huán)境中，這種實(shí)踐同樣重要。由于與業(yè)務(wù)的配合越來越緊密，以及需要確保所交付的服務(wù)可以支持不斷變化且敏捷的業(yè)務(wù)環(huán)境，因此需要從本質(zhì)上確保持續(xù)地評審和解構(gòu)基礎(chǔ)服務(wù)的設(shè)計(jì)。如果不能做到這一點(diǎn)，就將導(dǎo)致服務(wù)僵硬、不靈活，這對支持不斷變化的業(yè)務(wù)環(huán)境沒有益處。正如本系列的第 1 部分中的 Agile architecture 部分所述，該服務(wù)模型是控制持續(xù)解構(gòu)的出色工具。

原則 7：眼觀全局

SOA 的一項(xiàng)基本原則就是企業(yè)層次上的業(yè)務(wù)聯(lián)合。對于任何企業(yè)體系結(jié)構(gòu) (Enterprise Architecture) 約定，都存在一個(gè)內(nèi)在的需求，即確保始終維護(hù)統(tǒng)帥全局的“城市規(guī)劃 (city planning)”視圖，并專注于將在 SOA 中部署的單個(gè)服務(wù)的詳細(xì)設(shè)計(jì)。如果陷入以犧牲整體為代價(jià)來換取最佳的單個(gè)部分（或者服務(wù)）的誘惑中，您將承受交付不靈活的 SOA 的風(fēng)險(xiǎn)，它與企業(yè)中的關(guān)鍵業(yè)務(wù)流程是不相配的。

結(jié)束語和展望

正如我們在本系列中展示的，SOA 可以從敏捷軟件實(shí)踐和 LSD 的已證明有效的原則中獲得極大的好處。敏捷和 SOA 這兩種實(shí)踐的匹配基于一個(gè)共性——兩者都極力設(shè)法處理變化。服務(wù)接口應(yīng)該當(dāng)作實(shí)現(xiàn)可能將改變的應(yīng)用程序的必要條件。敏捷項(xiàng)目為要求它們實(shí)現(xiàn)的服務(wù)接口的改變做好了準(zhǔn)備。

SOA 的“持續(xù)的”解構(gòu)意味著經(jīng)常更改服務(wù)接口和服務(wù)組合。SOA 中的這種敏捷需要實(shí)現(xiàn)項(xiàng)目中的敏捷。基于本文中所強(qiáng)調(diào)的要點(diǎn)，我們要說，當(dāng)實(shí)現(xiàn)項(xiàng)目采用敏捷方法并接受改變時(shí)，SOA 中真正的敏捷將起作用。

通常油和水并不能溶合在一起。不可否認(rèn)，極限編程的想法和以可控的方式建立企業(yè)級服務(wù)體系結(jié)構(gòu)之間存在著文化差異。但這僅僅是初步估計(jì)，在寫完本文之后，我們可以聲明存在一種乳化劑，即 LSD 的原則。

所以，最后我們將聲明，在 SOA 和 LSD 原則的上下文中，“油和水確實(shí)可以溶合”！