讓成本與風險驅動敏捷架構設計

本文最初發表在 IEEE 軟件 雜志上， IEEE 軟件 雜志致力于發表嚴謹的、經過互相審校的文章，專注于當今世界的戰略科技。 為了滿足運行可靠且靈活企業所面臨的挑戰， IT 經理和技術管理者依賴 IT Pro 獲取最先進的解決方案 。

關于敏捷開發與架構之間的關系的文章與各種討論已經足夠多了。大約4年前，IEEE軟件還專門發表了一份相關主題的期刊（《敏捷與架構：它們到底 能否共存？》，IEEE軟件雜志2010年第27期第2刊）。目前看起來這一爭論已經開始逐漸平息了：我們已經看到包含了架構過程的敏捷方法，例如大規模 敏捷框架的出現，我們也看到開放組織架構框架（TOGAF）這樣的架構框架也加入了各種敏捷元素。當一切塵埃落定之后，我們到底學到了些什么？在 CGI（一個全球的IT與業務流程服務提供商）內部，架構師們已經學會如何使用經濟方面的驅動因素，例如風險與成本等等增加工作的敏捷性。

有五個方面的建議可以幫助架構師們在敏捷的世界中表現出更高的效率，而無需實施新的方法或使用新的框架。這些建議對態度或行為方面的改變進行了描 述，而不是純粹的實踐或原理，因此這些建議非常易于消化和應用。這些思想是基于一個名為風險與成本驅動架構的解決方案架構方法所派生的。這一方法的核心是 通過風險與成本決定關注點的架構重要性。通過將架構保持輕量級，讓它只處理那些特別高風險或高成本的關注點，以此實現架構的敏捷性。一個由風險與成本驅動 的架構關注點的待辦事項列表能夠平衡通常由價值驅動的產品積壓工作列表，以實現“剛好足夠的期望”這種軟件方案的演變。

你的主要交付成果就是你的決策

敏捷社區對于架構的批評之一源自于他們的某種誤解，在他們的想法中，一個架構師的職責永遠是交付“一種架構”，這種架構總是被解讀為某種文檔。而根據敏捷宣言( http://agilemanifesto.org ) 中的聲明，文檔的價值低于能夠運行的軟件。這種說法是對真正的架構師每日工作的一種非常糟糕的解讀：架構師的工作是找出需要處理的架構上的關注點，找到能 夠應對這些關注點的各種選項，然后根據當前的上下文決定最佳的行動（圖1 中的三個圓）。這樣來看的話，架構師的主要交付成果就不是某種文檔，而是一個決策流 ¹ 。這種看待架構工作的方式能夠完全地相容于敏捷思維，無論這些決定是由早期的實現和重構演變而來，還是通過仔細的前期建模而來，或是通過兩者的結合而得 出。在敏捷項目中，決策通常是由一組擁有共享的所有權的流程演變而來的，但即使如此，也可以將架構師視為守衛著整個設計的概念完整性的人。那么，架構師的 角色就是要確保整個小組的決策在整個解決方案中是一致的，即使同一時間有多個團隊在此方案中工作。

維護一個包含架構關注點的待辦事項表

敏捷環境中的架構師們沒有一種已事先批準的、固定的規格說明集，能夠讓他們在設計時進行參照。甚至是在傳統的瀑布式背景中工作的架構師們也不能夠 依賴于整個環境能夠保持固定不變，因為他們需要能夠設計出一種支持未來需求的解決方案，它應該能夠經受住一定數量的變更的考驗。在敏捷世界中有一種擁抱變 化的工具，那就是產品待辦事項表（product backlog）：這是一個等待實現的、排序的需求列表。隨著時間的推進，可以對待辦事項表進行重新排序，以適應需求的變化，或所對應的價值的變化。比起 設計一種非常完整的計劃，這種方式更易于擁抱變化。如圖1所示，架構師的待辦事項表中包含了架構上有待解決的關注點，因為這些關注點決定了她的工作內容。 通過頻繁地重新評估待辦事項表上關注點的優先度，架構師在處理新的業務需求和新興的見解時就能夠表現得更靈活。

讓經濟影響力決定你的專注點

那么我們該如何排列待辦事項表上關注點的優先級呢？要先解決哪一點呢？十年之前，Martin Fowler曾經寫道“架構就是指重要的東西，無論它是什么。 ² ”

圖1 —— 架構師的每日工作：一個“架構微周期”。架構師要觀察需要解決的架構關注點，列舉出解決這些關注點的各種選項，并根據當前的上下文決定他們的最佳行動。

我們發現對經濟影響的思考能夠幫助我們決定重要的事。換句話說，我們發現對某個關注點可能會產生的經濟影響進行評估，對于我們評定它的架構重要性 起到了很好的指示作用。如果這些關注點的內容是應該創建些什么產品，那么它的商業價值就顯得非常重要了。但是，許多架構師將大部分的時間用于考慮如何創建 它，在這種情況下，風險與成本就是關鍵因素。如果你能夠運用風險與成本來決定應當專注于哪些方面，那么你不僅能夠確定項目的經濟影響力，并且你也能夠將你 的優先級排列結構以一種業務干系人可以理解的方式解釋給他們聽。以經濟影響作為架構重要性的一種指示作用，也消除了這一種謬論，即架構只應當關心高層次的 抽象上的關注點，也不是具體細節。很多時間，問題就出在細節中，一些細層次的設計決策可能會具有很高的風險。架構師要牢牢掌握它們，甚至是自己動手編碼實 現。

圖2 —— Scrum上下文：讓架構微周期與每日站會的日程保持一持，以促進集體式架構決策。

保持小型架構

即使在大型項目中，選擇最小架構方式也有著兩種非常合理的原因：

• 架構很難改變，架構越大就越難調整。如果架構決策過多，在條件發生變化時就會成為沉重的負擔，因而難以很快地做出回應。這些架構決策也可能會對在這個架構中進行工作的個別團隊的設計空間造成不必要的限制。
• 只有了解架構的全部，架構師才能夠守衛它的概念完整性。過多的細節會使架構師失去在這個復雜的解決方案中維護一致性所必需的大局觀。

在大多數由計劃驅動的項目中，你都能夠指出某個架構里程碑的存在，因為這就是往架構中簽入代碼的時刻：在這個里程碑完成之后，對關鍵架構決策的任何顛覆都 會產生巨大的成本與時間。在到達這個里程碑之前要完成多少“前期”架構設計才是最理想的呢？這就要仔細的考慮以下三個因素才能夠得到最好的結論：即規模、 重要性和易變性 ³ ，而不是一些教條式的口號，例如“You ain’t gonna need it.（你不需要它）”。規模更大、復雜度更高的解決方案的商業重要性也更高，因此需要更多的前期架構設計。而在更容易生產變化的環境中，選擇較少的前期 架構設計的方式更合理。但許多敏捷項目并沒有架構里程碑的存在，因此需要采取其它的方式以決定要將架構保持在多小的范圍內。

交付足夠的預期

敏捷項目中的架構師如何決定正確的架構規模？按照上文建議中的第一條來看，架構是一種架構決策流。這種流應當在解決方案開發之前進行，并交付足夠的預期。你可以選擇多種工具幫助你決定正確數量的預期，包括依賴分析、技術債控制以及對未來的經濟考慮等選項 ⁴ ：

• 使用依賴分析幫助你決定需要哪些架構組件以實現預期的用戶故事。
• 使用技術債控制避免在沒有時間進行重構解決方案的情況下，不會由于加入了過多的用戶特性而使方案產生退化。要及時地找出架構上的技術債并計劃 處理它。我們在這里所說的并不是可以通過代碼分析工具而檢測出的實現過程中的技術債，架構債是的是會影響到項目敏捷度的結構上的不完美以及技術鴻溝，如果 不處理掉這些債務，會使得整個方案逐漸僵化。
• 仔細地考慮經濟方面的因素以衡量你的選擇。像凈現值（Net Present Value）這樣的模型能夠讓你的客觀洞察力表現為在正確的時間實施架構決策。使用這些技術與滿心期盼的產品經理、憂心忡忡的運維人員以及其他項目干系人 去討論正確的項目預期。雖然商業預測有時不夠精確，但比起參考敏捷教條、通用的設計原則或本能的感受還是更有說服力一些。

大規模敏捷框架（ http://scaledagileframework.com ）中使用了這樣一個比喻，一條跑道可以在運轉中不斷地擴展，讓它永遠剛剛好能夠容納預期中會投入使用的新飛機（在這個比喻中的飛機就是即將到來的方案需 求）。只要在跑道進行擴展之后，才能夠讓新的大型飛機進行著陸：由依賴分析決定容納這些飛機需要對跑道進行多大規模的擴展。有時候你可以在擴展跑道時暫時 使用一些較次的材料，換取進展的加快：它代表了那些技術債，你必須在某一時刻償還（重新鋪砌跑道）這些債務，以免出現事故。所有的決策（何時擴展或重新鋪 砌跑道）都要基于合理的經濟原因。這就是敏捷架構的5條建議。決策是你主要的交付成果，這些決策將處理你放在待辦事項表中，并根據經濟影響，即風險與成本 進行優先級排列的關注點。這些決策將產生一個最小的架構，其中只包含足夠的預期。關于敏捷架構能夠發揮的內容還有許多，包括項目組織（架構師是否應當成為 開發團隊的一員）以及開發流程（如何獲取短反饋循環）等主題。這5點建議只是你在任何一個組織或流程中都能夠應用的內容。

這些建議可以應用在例如Scrum（見圖2）這樣的敏捷項目方法中，而圖1中的架構微周期用于將架構跑道的改進也放到產品待辦事項表中。這些架構 上的改進能夠補足用戶特性，在產品待辦事項表中創建一種平衡的預期。但即使是在由計劃驅動的項目中工作的架構師，這些建議也同樣適用，這些架構師也經常要 擠出大量的時間以應對變更和新產生的見解。無論使用哪種項目開發方法，架構師都必須確保他們已經處理了大多數重要的架構上關注點，而風險與成本已被證實是 一種指出架構重要性的良好方式。

參考

1. J. Tyree and A. Akerman, “架構決策：讓架構去神秘化”（“Architecture Decisions: Demystifying Architecture”），IEEE Software, vol. 22, no. 2, 2005, pp. 19–27.
2. M. Fowler, “誰需要架構師”（“Who Needs an Architect?”）， IEEE Software, vol. 20, no. 6, 2003, pp. 11–13.
3. B. Boehm, “架構：規模與時間？”“Architecting: How Much and When?,” “軟件之道：軟件開發爭議問題剖析”（Making Software: What Really Works, and Why We Believe It）, A. Oram and G Wilson, eds., O’Reilly Media, 2010, pp. 141–186.
4. N. Brown, R.L. Nord, and I. Ozkaya, “通過架構實現敏捷性”（“Enabling Agility Through Architecture”） CrossTalk, vol. 23, no. 6, 2010, pp. 12–17.

關于作者

Eltjo R. Poort 是一位來自于CGI的解決方案架構師。 可以通過eltjo.poort@gmail.com 聯系他。

本文最初發表在 IEEE 軟件 雜志上， IEEE 軟件 雜志致力于發表嚴謹的、經過互相審校的文章，專注于當今世界的戰略科技。 為了滿足運行可靠且靈活企業所面臨的挑戰， IT 經理和技術管理者依賴 IT Pro 獲取最先進的解決方案 。

查看英文原文： Driving Agile Architecting with Cost and Risk