Peter Eeles, 高級 IT 架構師, IBM
2006 年 7 月 14 日
本文來自於 Rational Edge：這是這個系列教程的第四篇並且是最後一篇文章，Peter Eeles的這篇文章涵蓋了許多商業和IT組織可以從一個健全的軟件體系架構獲得的益處。
我在這個系列文章中的第一篇文章中講述了什麼是軟件架構，在第二篇文章中定義了軟件構架師的角色特徵，在第三篇文章中涉及到了在軟件架構設計過程下的主題或者特徵。第四篇也就是最後一篇文章將會講述一個商業和IT組織得自於一個健全的軟件體系架構的益處。
一般來說，軟件架構設計是降低成本，改進質量，按時交付產品和按需交付產品的關鍵因素。在這篇文章中，我將會把討論的焦點放在實現這些目標所能帶來的好處上面。作爲一個構架師，證明我們的存在是沒有任何意義的。這個部分將會提供一些方法，這些方法對於把處理架構設計作爲一個軟件開發過程的關鍵部分是很有用處的。
系統的功能性是軟件構架師通過組成體系架構的多種元素之間的交互作用來支持的。然而，架構設計的一個關鍵特性是，系統的品質是通過某些手段來實現的。軟件的品質，例如性能，安全性和可維護性等，它們在缺少統一的架構設計視圖時是無法實現的，因爲這些品質並不是被限制在一個單一的架構設計元素中，而是滲透在整個架構設計體系中的。例如，爲了滿足性能要求，可能需要考慮體系架構中的每一個組件的實現時間，同時還要考慮各組件之間通訊所花費的時間。同樣地，爲了滿足安全性要求，可能需要考慮兩個組件之間自然的通訊，並且要在需要的特定的地方引入安全性提示組件。所有的這些關係都屬於體系架構，在上面的例子中，這些關係包括組件自身的和組件之間的。
一個和架構設計相關的好處是，我們可以儘早的評估項目開發週期中的這些品質。架構設計模型的建立，通常是爲了明確的確定我們已經滿足了這些品質的要求。這是非常重要的，因爲不論寫在紙上的體系架構多麼的完美，實現的軟件纔是評價體系架構是否達到這些品質的要求的唯一標準。
架構設計的過程使得不同的涉衆達成一致的目標，因爲架構設計提供了一個辯論系統解決方案的媒體。爲了支持這種辯論，體系架構的過程需要確保架構設計被清楚地傳達與理解。一個被有效傳達的體系架構使得涉衆們可以辯論決議和權衡，反覆討論，最終達成共識。相反，如果一個體系架構沒有被有效的傳達，那麼這種辯論將不會發生。沒有了有效的傳達，體系架構所帶來的結果可能會是低品質的。
在一條相關的說明中，體系架構可能會使構架師之間或者新成員與老成員之間的辯論達成一致（以及他們之間的視圖）。我們需要再次強調，只有體系架構被有效傳達，它所帶來的這個好處才能體現出來。清楚地瞭解他們正在做什麼的開發小組更可能按照需求完成產品的開發。
爲此，我再次強調恰當的文檔化體系架構是非常重要的，這是軟件構架師的主要職責。同樣的，一個架構設計的概念證明是一個證明體系架構是否滿足最初的需求的極好的方法。
架構設計的過程支持一些步驟。很明顯，它支持設計和實現活動，因爲體系架構是直接使用到這些活動中的。然而，在架構設計過程所帶來的好處中，我們可以證明其中最主要的好處通常是那些和支持相關的，被提供給項目計劃和項目管理的活動，例如：細節化分，日程安排，工作分配，成本分析，風險管理和技能開發等。架構設計的過程可以支持所有這些相關內容，這也正是軟件構架師和項目經理應該擁有一種很密切關係的一個主要原因。這個支持的大部分來自於體系架構確定的系統中重要的組件和它們之間關係的行爲。請看圖1中的UML組件圖，它已經爲我們的討論作了簡化。這個圖顯示了這四個組件之間的依賴性。
圖1：UML組件圖顯示了架構設計中的重要元素
在日程安排方面，它們之間的依賴性暗示了每一個元素被考慮的順序。從一個實施透視圖來看，例如，依賴性告訴我們Error Log組件必須最先實現，因爲其餘的所有組件都要使用它。Customer Management和Fulfillment組件可以同時實現，因爲它們之間不存在依賴關係。最後，一旦這兩個組件也被實現完了，那麼Account Management組件就可以被實現了。通過這個信息，我們可以畫出甘特圖（項目經理的一個主要計劃編制工具），如圖2所示。圖中顯示的每一個任務在實現時間時都需要一些思考，但是它們中的一部分可以來源於每一個架構設計元素的複雜性。
圖2：基於架構設計中重要元素之間依賴性的甘特圖
很明顯這是一個很多原因的總的簡化。例如，所有這些元素都不可能作爲一個單一的組件被實現，但是這對於一個用例來說太過複雜了。同樣，我們可以建立"存根的"或者部分的實現，使得每一個元素的實現都能夠平行實現。我使用這個例子來簡單的證明這個原理。
在工作分配中，體系架構能夠再次幫助我們鑑別需要特定技能的區域，使得我們可以把工作分配給特定的資源（例如：人）。
構架師還能協助估算項目成本。一個項目的成本來自多個方面。很明顯，任務的持續時間和分配給每一部分的資源將會決定勞動力的成本。體系架構同樣會幫助我們決定使用在交付的系統中的第三方組件的成本，以及支持開發成果的所有工具的成本，因爲構架師參與的活動是一個經過挑選的恰當的開發環境，它允許設計人員，實現人員和其他小組成員使用同一個有效的方式一起工作。
構架師的另外一個焦點是鑑別和管理項目的技術風險。技術風險的管理包括制定每一個風險的優先次序，以及確定一個恰當的風險緩解策略。優先權和風險緩解策略作爲輸入部分提供給項目經理。
最後，體系架構確定離散組件的解決方案，它可以爲項目提供所需的技術輸入。如果項目或者組織中沒有足夠可用的資源，那麼它會明確的辨別出哪裏需要技術支持。這可以通過現存的職員，或者外包，或者通過僱傭新職員來實現。
  |
|
架構設計過程的一個主要目標就是確保體系架構能夠爲設計人員和實現人員所承擔的工作提供可靠的構架。很明顯，這比簡單的傳送一個體系架構視圖要複雜的多。爲了確保最終體系架構的完整性，構架師必須明確的定義體系架構，因爲它確定了體系架構的重要元素，例如系統的組件，組件之間的接口以及組件之間的通信。
構架師同時還必須定義恰當的慣例，標準和指導方針，它們將會引導設計人員和實現人員的工作。架構設計的另外一個目標是去除部分設計人員和實現人員不必要的創意，這是通過對他們所做的事情增加必要的限制，以及讓他們清楚地知道如果不遵循這些限制將可能會導致體系架構的破壞來實現的。出於這個原因，對活動採取恰當的回顧和評估，能夠確保體系架構的完整性。這些活動的一個焦點是考慮設計人員和實現人員的工作，以及確定體系架構的標準和指導方針的到位程度。
如今的系統越來越複雜，這種複雜性需要我們去管理。自從一個體系架構只把焦點集中在這些元素上以來，它就提供了一個抽象的系統，因而提供了一個複雜的管理方法。同樣，架構設計過程考慮組件的遞歸分解。這是處理一個大的問題的很好的一個方法，它可以把這個大問題分解成很多的小問題，再逐個的解決。
抽象的體系架構之間的通信技術使得管理更加複雜。採取業界標準可以表達這種抽象性，例如UML，因此在現今的產業中文檔化軟件系統是非常平常的事情。
架構設計過程可以同時支持使用和建立複用資源。複用資源對於一個組織來說是有益的，因爲它可以降低一個系統的成本，並且可以改進系統的質量，這些好處已經被證明過了（自從它被使用以來）。
一個體系架構的建立，能夠支持資源複用的機會。例如，體系架構的重要組件和它們之間的接口和質量，能夠支持現貨供應的組件，存在的系統和封裝的應用程序等等的選擇，從而可以用來實現這些組件。體系架構自身也可以被用來當作今後開發的系統的一個複用參考資源。甚至體系架構內部的組件也可以被認爲是潛在的複用資源。
雖然架構設計過程能夠鑑別現今項目中存在的資源複用的機會，但是跨項目和企業的資源複用會導致產生很大的衝突。
任何關於複用的討論都要和謹慎聯繫在一起。由於各方面的原因，只有很少一部分複用程序能夠使用到現在。從技術的角度看，一個複用的程序需要確保標準，過程和工具都在恰當的位置。幸運的是一些基本元素正在被滿足。一個好的例子就是標準化組織：Object Management Group's Reusable Asset Specification (RAS)， 1它定義了描述複用資源，封裝複用資源和連接到RAS資源庫服務的接口的標準
從非技術的角度看，當你實現一個複用策略時，需要始終牢記組織的考慮。例如，確定誰是建立複用資源的人員？一旦複用資源被建立，誰是負責維護它的人（建立它的小組已經解散）？使用和建立複用資源的動力是什麼？建立一個複用資源的成本是多少，這通常比建立一個不恰當的複用資源要花費更多。
架構設計過程可以在很多方面幫助我們降低維護費用。首先最重要的是架構設計過程要確保系統的維護人員是一個主要的涉衆，並且他們的需求被作爲首要的任務滿足。一個被恰當文檔化的體系架構不應該僅僅爲了減輕系統的可維護性；構架師還應該確保結合了恰當的系統維護機制，並且在建立體系架構的時候還要考慮系統的適應性和可擴充性。
構架師還應該考慮那些需要改變的區域，並把它們隔離開。這樣可以保證當單個組件或者一小部分組件發生變化時，整個系統不會受很大的影響。但是我們應該承認，有一些變化，例如關係到系統質量，如實現性和可靠性，是不能用這個方法隔離的。這就是構架師必須確保它的原因，當架構設計現在的系統時，他們需要考慮將來可能的需求，因爲這個系統要從幾十人的用戶推廣到上千人的用戶羣，例如，體系架構沒有使用基礎的方法改變是不正常的。
架構設計的一個重要的好處是它可以允許我們在採取改變之前推斷它所產生的影響。一個軟件構架確定了主要的組件和它們之間的交互作用，兩個組件之間的依賴性以及這些組件對於需求的可追溯性。
有了這個信息，例如需求的改變等可以通過組件的影響來分析。同樣的，改變一個組件的影響可以在依靠它的其它組件上分析出來。
這種分析可以協助我們確定一個改變所產生的成本，改變對於系統的影響以及改變所帶來的風險。這個信息在我們確定改變的優先級以及研究這些改變時是絕對必要的。
這篇文章的內容來源於一本即將出版的圖書，我暫時把這本書命名爲"軟件架構設計過程。" 很多的人爲這篇文章作了評論，我在這裏要謝謝他們，他們是：Grady Booch，Dave Braines，Alan Brown，Mark Dickson，Luan Doan-Minh，Holger Heuss，Kelli Houston，Philippe Kruchten，Nick Rozanski，Dave Williams，and Eoin Woods。
- 您可以參閱本文在 developerWorks 全球站點上的 英文原文 。
- 您可以參閱 Rational Edge 電子月刊中文版 的其他文章。
- 註釋 "Reusable Asset Specification"， 對象管理組織(Object Management Group Inc.)，文檔號 04-06-06: June 2004。