本文最初發表在IEEE軟件雜志，現在由 InfoQ & IEEE 計算機協會為您呈現。
　　軟件架構師在設計時需要作出很多決策。作出正確的關鍵架構決策，其重要性不言自明。^1-3但是，要總結出什么是關鍵決策絕非易事，更不用說何時以及如何作這樣的決策。早先，架構決策作為設計決策的一部分已被定性為做起來很難⁴，改起來又費勁。⁵為了澄清這些問題，我們在下面給出的架構決策定義中增加了一些條件邏輯⁶：

　　架構決策要識別出關鍵設計難點和隱藏在所選方案中的原理。它們是慎重的設計決策，這些決策將軟件密集型系統視作一個整體或將該系統的一個或多個核心組件及組件間的關聯關系歸于任意既定的視圖。架構決策產生的結果影響系統的非功能性特征和軟件質量指標。

　　根據上述定義，無論是選擇一門編程語言、架構模式、應用容器技術或中間件資產都算作架構決策。比如，Broker這樣的集成模式描述了分布式系統會遇到的阻力，包括位置獨立性和網絡問題⁷ 。這些阻力適合作為決策的驅動力，所以是否將Broker模式添加到架構中來就是一種需要慎重判斷的架構決策。一些頂尖的軟件工程方法，比如IBM統一方法框架（Unified Method Framework），需要將架構決策記錄成文并且在統一的地方對這些關鍵決策進行論證⁸。

　　在把各個功能分散對應到各系統模塊時，記錄日志可以保證設計的完整性。通過確保架構的可擴展性，這些日志支持漸進式系統。它們也為新加入項目的人員提供了參考，以避免對已經確定了的問題重復考量。日志可以在事后捕獲架構決策。創建這種日志是一種短期受益很少但長期受益頗多的文檔活動⁹。如果我們對某個特定的項目放松文檔要求，并假設同一應用類型的多個項目遵照同樣的架構樣式——共享同樣的原則和模式——那么我們可以考慮將架構決策從文檔工件升級為設計指導。

　　這些設計指導可以幫助那些習慣了某一特殊類型的應用和架構風格的架構師們理解做決策的需求和可選方案，而這些方案往往基于成功應用于類似情況下的相同知識。這樣的話，重現的架構決策就成為可復用資產，就像方法和模式那樣。這會衍生出新的使用場景。比如，重現的問題可以用作審核檢查列表，幫助劃分設計和開發工作項的優先級，促進企業和項目架構師之間的溝通。

　　SOA決策——建模框架

　　在設計過程中將重現的架構決策提升到指導角色的高度，首先需要有效地捕獲和總結相關的項目經驗。這是知識工程的行為。面向服務架構（SOA）決策建模（SOAD）提供了支撐該行為的一種知識管理框架¹⁰ 。 當SOA風格應用于某一特定類型的應用，如企業應用，SOAD可提供一種技術以系統地識別這些應用中重現的那些決策。SOAD對已有的元模型和模板進行了增強^8,11 ，具體說來就是將決策需求從決策制定中區分出來。它建立了多層次的知識組織可以將平臺獨立的決策從平臺特定的決策中區分出來。在概念層次，設計備選參考架構模式，比如Martin Fowler定義的那些¹² 或其它的^7,13,14。

　　SOAD框架使得知識工程師以及軟件架構師能夠管理決策依賴，這樣他們可以檢查模型一致性并刪除不相干的決策。一個條理清晰的問題集可以指導決策過程。有了框架提供的支持，架構師能夠根據決策更新設計工件，而決策是通過將決策產出件注入模型轉換中而實現的⁶。

　　為了支持復用，SOAD元模型定義了兩種類型的模型：

• 指導模型用以識別必需的決策。
• 決策模型用以記錄決策制定。

　　圖1展現了這些模型之間的關系和內部結構。⁶

　　圖1. 面向服務架構（SOA）決策模型（SOAD）框架。SOAD元模型被實例化到一個指導模型內，該指導模型可識別某一特定架構風格（如SOA）所必需的決策。架構師對指導模型做裁剪以創建針對某一項目的決策模型雛形。

　　指導模型是一種可復用的資產，它包括在某類特定應用類型中使用某一架構風格時所必需的架構決策的知識。該模型基于已完成的、采用同一類架構風格的項目中獲得知識。如圖1所示，每個問題都提示架構師：這是一類特定的設計問題，需要作出架構決策。問題反映了決策驅動各種類型，比如質量指標、根據其優點和缺點確定的參考潛在備選方案以及在之前應用中的已知用法。知識工程師將這些問題和備選方案寫成文檔，編寫文檔時采用將來時態，其口吻就像技術導師在交談時所使用的口吻一樣。

　　通過裁剪不相干項、改進增強相關項、增加新問題項，指導模型可為具體項目提供指導。決策模型作為架構文檔工件不僅包含需要做的架構決策，還包含已做完的架構決策。其輸出件是項目中實際所做決策的日志記錄，并附帶決策依據。在SOAD中，產出件代表軟件架構師現在（或過去）在項目中獲取的設計研討紀要。一個決策模型可以重用一個/多個指導模型。它可以為已作出的決策提供信息使其在項目結束后通過資產總結活動（可能包括所有從以往經驗中得到的正式或非正式評論）將信息反饋給指導模型。在SOA設計中，比如，一個保險公司的業務流程模型可能描述了某個后臺系統必須實現和集成的三個不同的業務活動（客戶索賠、理賠審核和風險評估）以及相應的服務操作。

　　架構師必須要為項目選擇一種集成風格，比如由Gregor Hohpe和Bobby Woolf針對此問題識別出的四大可選模式之一：文件傳輸、共享數據庫、RPC或消息傳輸¹³。架構師也必須選擇一種集成技術，如HTTP和Java消息服務（JMS），以使不同業務活動之間相互交互。問題陳述（“在業務流程中的業務活動及服務操作和其他模塊——比如遺留系統——交互時，將會用哪種技術？”）以及決策驅動（“互操作性、可靠性和工具支持”）對所有三種服務操作同樣適用。

　　與具體項目相關的決策成果，比如備選方案及理由，取決于每個操作各自的需求。比如，“對于客戶索賠來說，我們選擇RPC和HTTP的理由是Java和C#模塊必須以一種簡單并可交互的方式來集成，所以我們看重可用Web services工具的支持。”可是，“對于風險評估來說，我們選擇消息傳輸和JMS的理由是需要集成的一些后臺系統可用性較差，我們一定要保證消息的可靠性。”

　　從一般性問題到SOA指導模型

　　我將使用保險公司的例子來做總結，然后擴展出兩個必需的決策——集成風格和集成技術的問題。首先需要把那些CS架構中出現的普遍問題加入到一張通用的模塊及連接器的圖中，如圖2所示，模塊和連接器都是服務消費者（客戶）和服務提供者（服務）在分層系統中的一種概括。

　　圖2. 通用的模塊及連接器架構中普遍存在的問題。每個模塊和連接器產生的問題是普遍問題的具體化。該層次可向下一實現層轉變，譬如從概念模型組件模型，到細化組件模型，再到實現組件模型。

　　舉例來說，層次n可能被實例化為表現層、業務邏輯層和持久層之類的面向服務的企業應用¹²。 從這樣的實例化來看，保險公司示例中的三個業務活動（客戶索賠，理賠審核和風險評估）和服務操作都屬于架構中業務邏輯這一層。在優化設計使之成為具體架構時，圖中每一小塊（比如，圖2，“接口簽名？”）都應該看作一個普遍問題，需要仔細研究。接下來需要將普遍問題和SOA模式結合起來。有些作者已經對該SOA模式進行了描述——比如Uwe Zdun和他的同事們¹⁴。 SOAD框架將使用如下SOA定義⁶：

　　從架構設計的視角來看，SOA引入了一個服務消費者（請求方），一個服務提供者和一份服務契約。這些模式促進了架構模塊化和平臺透明性原則。組合架構模式，如企業服務總線（ESB），管理服務消費者與服務提供方之間的交互和物理分布，以此來支持諸如協議透明性和消息格式透明之類的原則。服務組合模式將各種處理邏輯組合起來，參照邏輯分層原則和流程獨立性。而服務注冊模式定義了如何查找服務提供者等相關原則，如位置透明和服務虛擬。

　　圖3描述了將通用的CS組件實例化成功能架構概覽圖中，解釋了這些模式機器構建模塊在SOA中是怎么交互的⁶。

　　如圖3所示，SOA風格的本質是通過服務契約、ESB消息傳輸和服務注冊達到服務消費者和服務提供者之間的解耦。ESB模式由另外三種模式組成：中介器模式、路由器模式和適配器模式。為了將平臺特定設計從平臺獨立設計中區分開，SOA基于模式的特征淡化了Web Service等技術。將圖2中的普遍問題和圖3中的SOA模式結合起可以引出具體問題的重現。識別這些問題及備選方案可以使技術專家們從使用這些模式的項目經驗中獲得決策驅動因素、優點、缺點以及建議。

　　圖3.SOA模式及其協作和功能性分解。服務消費者和提供者通過ESB模式進行交互。服務注冊羅列出服務消費者可用的所有服務契約和服務提供者。

　　執行層決策

　　認定SOA為首選架構風格，這本身就是一種管理決策，因此選擇特定的SOA參考架構就是執行層的決策。這需要在名詞術語上達成一致，比如層次和模塊的名稱，相關模式語言的識別。架構原則也可能采用執行層決策的形式，比如，選擇開源資產還是某軟件廠商和服務器基礎設施？這對應到圖2中的通用問題就是“整體的層次間組織結構？（Overall layer organization）”

　　概念性的、平臺獨立的設計問題

　　服務設計者必須根據操作簽名中的請求和響應消息參數來決定服務契約的粒度。這些簽名指定了服務調用的語法和消息載體的結構。這一問題關心服務契約的設計。根據圖3所示的SOA模式，服務契約是SOA接口的實例化；因此，根據圖2，通用問題“接口簽名是什么？（Interface signature）” 適用于該設計上下文。詳細的ESB設計和配置又引起另一類問題。架構師們必須選擇消息交互模式，比如單向操作及請求——應答（異步與同步通訊）。他們也必須要詳述路由器、中介器和適配器模式的具體用法，描述如何將消息從服務消費者轉移到服務提供者（路由器）、如何當消息在ESB（中介器）中傳輸時進行消息內容的轉換、如何與非SOA的系統和模塊（適配器）進行集成¹³。

　　遵循SOA風格的架構師也必須細化服務組合設計（如果他們選擇了這種SOA模式）。選擇某個集中式流程管理器¹³，如工作流引擎（與之相對的是在各個應用或模塊中的分布式狀態管理），就業務邏輯層的內部結構而言，是一項重要的架構決策。至于服務注冊，設計時和運行時的注冊查詢是設計問題的一個例子。“組件的生命周期管理（Component life-cycle management）”是對應的通用問題（如圖2）。

　　平臺相關的設計問題

　　概要設計問題不會涉及到任何技術標準或其具體實現。然而，選擇一種或多種SOA模式的架構師也必須負責解決平臺相關的問題——比如說，選擇并勾畫諸如WS* Web Service作為集成技術的具體實現技術。一旦選擇了某種技術，架構師就必須選擇和配置實現平臺。許多SOA模式都有商用和開源中間件的實現。架構師必須決定是否需要購買該中間件以及，如果購買了，如何進行安裝和配置。

　　可復用的設計資產：SOA指導模型

　　根據前文摘要中的定義，我描述的所有SOA設計問題都適合作為架構決策。比如，服務操作的簽名將會對性能和互操作性等質量屬性產生影響。而且，這些問題會重復出現。只要一個項目應用了SOA模式，那它就必須一而再再而三的解決類似的問題。因此，我們期待知識的重復利用。

　　我在SOA指導模型中收集了500個經常重現的問題^6,10。

　　SOAD案例研究報告

　　實踐架構師已經在十多個項目中成功地應用了SOAD和SOA指導模型。這些項目包括為歐洲某國社會保障部開發的養老金計劃管理應用、為某電信公司開發的客戶和訂單管理方案以及為某多渠道零售商開發的B2B電子商務應用。這些案例研究確定了很多重現的問題。參與項目的架構師對SOA指導模型中知識的相關性和可行性方面做了評估。評估結果表明在設計活動方面速度和質量都有改進，并且SOAD視角和方法也廣受贊賞^6,9。

　　SOAD框架反饋

　　在案例研究項目過程中，我和幾百位架構師就SOAD的價值和可用性等方面進行了交流，聽取了他們的反饋意見。只有一位架構師公開不同意SOAD的基本假設 ——即當在同一類型的項目上使用相同的架構風格時，會出現相同的架構決策，而這一反對最終發現實際上是誤會一場。SOAD并沒有聲明某個決策始終會產生相同的成果；它只是表明那種對決策所需要的問題，會重現。

　　案例研究參與者們發現SOAD元模型是能夠被直觀理解的、包含有用且充分的信息，這些屬性都有助于做關鍵決策。他們還建議添加一些別的屬性。他們還建議采用不同的方式來構造指導模型——包括由企業架構框架定義的組織機構的維度。

　　參與者將決策的依賴管理視作決策模型的一項重要優勢，因為用文本形式的決策日志來管理這些決策的依賴是很困難的。他們還指出，當一種成熟的決策方法已經存在時，任何其他的方法都必須與其保持一致。他們將SOAD視作一種支撐資產——一項內置在通用目標方法中的決策制定技術——而不是一種孤立的方法。

　　SOA指導模型的反饋

　　案例研究的參與者都很認同指導模型的內容和各細節層次。他們認為它不夸張很合適、與SOA行業項目相關、而且歸檔清晰，總之是恰如其分。

　　他們對主動決策模型和回顧市決策模型有一些疑惑。有一個用戶通過決策日志簡單地從指導模型中拷貝問題的描述和建議屬性，由此生產決策依據。這在部門內部技術質量評估審核會上，這一做法引起了高級架構師的批判?？傊仨氁獙κ褂肧OAD的期望進行管理。SOAD的不鼓勵孤立地執行架構思考。

　　使用場景和討論

　　SOAD是以決策為中心的方法指導設計工作的。它的一大優勢是目標受眾、軟件架構師能從不同的使用場景中理解架構決策的核心概念——架構文檔。這使SOAD在其他場景中的的應用得以簡化：

• IT用戶可以通過要求提供方交付標準的、與其軟件方案或產品一致的決策日志來維護對他們應用的控制。用戶可以根據SOAD元模型使決策日志結構化，并從共享指導模型中生成這些日志。
• 那些開發多種軟件密集型產品（線）的公司可以要求其企業架構師創建一個公司范圍的指導模型。通過采用公司指定的SOAD元模型、方法和工具組能夠對指導模型活動提供支持。這種方法可以縮短產品近入市場的時間，還能使不同產品的架構保持一致。
• 指導模型中加注了最佳實踐建議，通過共享其中的技術知識，提供復雜商業套件的廠商可以減少培訓、客戶化定義和技術支持。
• 在專業服務中，實踐群體重視明晰的知識管理，可復用資產能夠創建指導模型用以支持基于勞動力的交付模型向基于資產的交付模型（戰略再利用）轉變。
• 培訓師可以將指導模型作為一種系統化的方法來教授模式和各種技術最佳實踐。
• 那些想要以一種可復用的、高效的方法來評估中間件和企業應用分析師和受眾可以把標準化的、領域相關的問卷建立在可復現的設計問題上。他們可以根據SOAD元模型來為這些問題建模。

　　SOAD 假設多數問題都會重復發生。如果不是這樣的話，那指導模型資產不能為其產出物帶來足夠的價值。如果多個項目采用相同的架構風格，那么問題發生的假設很有可能成立。然而，使用SOAD描述問題和備選方案還包括對知識工程的承諾。指導模型必須比具體項目的決策日志具有更高的編輯標準，所以創建這樣模型的決策必須支持知識管理策略。它需要一個基本的模型、一個審核、批準和維護流程。使用SOAD三年，我的經驗告訴我，平均來看，專業工程師完全可以在一個人天內完成對一個問題的建模。

　　架構師已經能夠從不完整的建模知識中獲益，比如以問題的形式清晰地描述的問題檢查清單。除此之外，工具能夠部分地自動化生成資產 ——比如，從項目工件中提取出架構知識的挖掘工具。從工具設計的角度來看，展示信息的多少、上下文相關的過濾和排序能力是成功的關鍵。架構師一般都會花時間和企業（組織）內外的干系人進行溝通，所以他們不一定愿意從頭到尾閱讀指導模型（雖然我一些同事已經這樣做了）。工具可以將指導模型裁剪到和某個給定設計上下文相關的問題和備選方案，要先裁剪然后才能在項目中全面施行。SOAD的元模型能偶這樣的工具開發，比如，為問題設定范圍屬性，指出問題一般應在那個項目解決得到解決。

　　結論

　　最初創建SOAD 的原因是支持企業應用和SOA設計，而指導模型的使用則是作為可重用資產也適用于其他應用系統和架構風格。它支持的應用場景包括教育、知識交換、設計方法和治理。下一步對它的擴展包括，將其擴展到其他的業務和技術領域以及目標受眾，如除軟件架構師之外的業務人員。其他解決指導模型所面臨的挑戰的計劃，比如知識可視化和維護性¹⁵ 。

　　指導模型編制了重復出現的問題和選項，通過這種方式來推進架構知識的重復使用，自此，SOAD使得架構師能夠在某個問題的求解上下文中分享最佳實踐。我們可能從錯誤中能夠得到最好的學習，誰規定了所有的錯誤都必須要自己犯過才行呢？

　　關于作者

　　Olaf Zimmermann是IBM蘇黎世研究院的一名研究專員。他的研究興趣關注于應用和集成架構、SOA設計、架構決策以及各種服務和知識管理的框架。Zimmerman擁有斯圖加特大學計算機科學專業博士學位。他也是開源組織的杰出IT架構師、IBM執行IT架構師并著有Web Services展望（Springer, 2003）一書。你可以通olz@zurich.ibm.com和他取得聯系。

　　參考文獻

　　1. L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, 2nd ed., Addison-Wesley, 2003.

　　2. N. Rozanski and E. Woods, Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, Addison- Wesley, 2005.

　　3. P. Eeles and P. Cripps, The Process of Soft- ware Architecting, Addison-Wesley, 2010.

　　4. M. Fowler, "Who Needs an Architect?" IEEE Software, vol. 20, no. 5, 2003, pp. 2-4.

　　5. G. Booch, internal conference presentation to IBM Academy of Technology, 27 Apr., 2009.

　　6. O. Zimmermann, "An Architectural Decision Modeling Framework for Service-Oriented Architecture Design," PhD thesis, Univ. of Stuttgart, 2009.

　　7. F. Buschmann, K. Henney, and D. Schmidt, Pattern-Oriented Software Architecture, Vol. 4 - A Pattern Language for Distributed Computing, Wiley, 2007.

　　8. IBM Unifi ed Method Framework, work product description (ARC 0513), IBM, 2009.

　　9. M. Ali Babar et al., eds., Software Architecture Knowledge Management: Theory and Practice, Springer, 2009.

　　10. O. Zimmermann et al., "Managing Architectural Decision Models with Dependency Relations, Integrity Constraints, and Production Rules," J. Systems and Software and Services, vol. 82, no. 8, 2009, pp. 1246-1267.

　　11. J. Tyree and A. Ackerman, "Architecture Decisions: Demystifying Architecture," IEEE Software, vol. 22, no. 2, 2005, pp. 19-27.

　　12. M. Fowler, Patterns of Enterprise Application Architecture, Addison-Wesley, 2003.

　　13. G. Hohpe and B. Woolf, Enterprise Integration Patterns, Addison-Wesley, 2004.

　　14. U. Zdun, C. Hentrich, and S. Dustdar, "Modeling Process-Driven and Service-Oriented Architectures Using Patterns and Pattern Primitives," ACM Trans. Web, vol. 1, no. 3, 2007, article no. 3; doi.10.1145/1281480.1281484.

　　15. M. Nowak, C. Pautasso, and O. Zimmermann, "Architectural Decision Modeling with Reuse: Challenges and Opportunities," Proc. 2010 ICSE Workshop Sharing and Reusing Architectural Knowledge (SHARK 10), ACM Press, 2010, pp. 13-20.

　　本文最初出現IEEE軟件雜志（雙月刊）2011年第一期，64頁到69頁。IEEE軟件雜志致力于為那些緊跟快速技術變更的軟件從業者提供創新性思想、專家分析和各種真知灼見。

　　查看英文原文： Architectural Decisions as Reusable Design Assets

it知識庫：架構決策作為可復用設計資產，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。