Peter Eeles, 高級 IT 架構師, IBM
2006 年 3 月 15 日
來自於 Rational Edge：在電影製作術語中，軟件項目經理被稱作製作人，因爲他們決定需要做什麼事情。而軟件構架師就是導演，他來決定所作的事情是否正確，並且他要保證產品符合投資人的要求。下面這篇文章就是描述軟件構架師的。
這篇文章是關於軟件構架的系列文章（共四篇）中的第二篇。上個月，這個系列文章中的第一篇給構架作了一個定義。因此現在我們可以把注意力集中到創建構架的人員——構架師身上。軟件構架師被證明是軟件開發項目過程中最具挑戰性的角色。軟件構架師是項目的技術領袖，並且從技術角度來講，他承擔了項目成敗的責任。
下面是電氣及電子工程師協會給“構架師”做的定義：
[構架師是]負責系統構架的人，團隊或者組織。 1
作爲項目的技術主管，構架師的技術需要非常的廣泛，這比技術深度更加重要（當然構架師在特定的領域需要一定的技術深度）。
首先，軟件構架師是技術主管，這意味着除了他要有技術上的技能外，還要有很好的領導才能。構架師的領導能力在團隊中和項目質量控制中起着十分重要的作用。
在團隊中，構架師是項目的技術總管，他需要有豐富的知識背景，以便作出技術上的決定。相對於構架師來說，項目經理是來管理項目的資源，時間進度和花費的。使用電影製作來做類比的話，項目經理就是製片人（他要確定工作被完成了），而構架師是導演（他需要確定工作被正確的完成）。由於他們在項目中所處的位置，構架師和項目經理是公衆人物，在一個團隊中，他們是整個項目所涉及的所有人員的聯繫樞紐。構架師應該爲建立軟件構架爭取投資，並且要明確建立軟件構架能給組織帶來的價值。
構架師還要把團隊組織在構架周圍，並且要積極地投入到計劃活動上，因爲要把構架轉化成爲完成任務的先後順序，這樣才能及時地確定在什麼位置需要什麼技術。有一點需要注意，由於構架師能否成功與團隊的整體水平有很大關係，所以構架師應該參與團隊新成員錄用的面試。
根據構架師所擁有的能力，他可以同時參與其他團隊的工作。構架師需要根據具體的實例情況來做領導決定，並且在決定過程中要展現出足夠的自信。一個成功的構架師是以人爲導向的，並且像一個教練一樣給他的團隊安排工作時間。這對於小組的成員來說是有好處的，他們可以及時得到幫助。這是整個團隊的一個巨大財富。
構架師還要把精力放在切實工作的交付上，他是技術方面的推進力量。構架師需要做決定（經常需要在壓力下做決定），並且要保證這些決定是經過成員之間的交流的，並且確保它能夠執行。
下面介紹一個人和一個角色的區別。一個人可以扮演很多角色（例如，Mary是一個開發人員，同時也是一個測試人員），同時，一個角色可以有很多的人扮演（例如，Mary和John都是測試人員）。構架師的角色需要非常廣泛的技術，這就爲什麼構架師的角色經常是很多人同時擔當。這樣可以使技術知識在小組中傳播開來，每一個人都把他的或者她的經驗帶到工作中。特別是當某種技術同時被商業部門和技術小組理解的時候，這項技術就會最大程度的傳播開來。小組所作的結果，需要被"平衡。" 貫穿整個文章的術語"構架師"，是指的一個人或者整個小組的成員。
[一個小組]是一些擁有各種技術的人的集合，他們之間有共同需要完成的目標，並且之間相互負責任。 2
如果一個小組來擔當構架師的角色，那麼就需要有一個人作爲這些構架師的領導，他要擁有整體的前景，並且需要調節構架師小組之間的問題。如果沒有這種調節，構架師小組成員之間就會存在危險，他們可能不會建立出一個緊密地構架或者決策不會被成功的完成。
現在有一個新的概念在構架師小組中被提出：爲了使成員之間達到共同的目的和目標，團隊爲構架師小組建立併發布了一個章程。 3
好的構架師知道自己的強項和弱點在哪裏。無論構架師的角色被一個人還是一個小組擔當，他們背後都有"值得信賴的顧問"的支持。他們可以通過和其他構架師協同工作來彌補自身在某些技術方面的不足。最好的構架通常是被一個構架師小組建立的，而不是一個人。原因很簡單，一個小組的力量總要比一個人的知識豐富的多。
構架師小組的概念有一個缺陷，他們有時被團隊中的其他人認爲是在"象牙塔"裏工作，因爲他們的產品經常是很有智慧的但卻沒有使用價值。這種誤解可以從開始就把它減到最小：1)確保所有的涉衆都能積極地協商，2)不斷的交流構架和它的價值，3)在執行過程中要有組織策略的意識。
構架師應該對軟件開發過程有正確的估計，因爲這個過程確保小組中的所有成員使用同等的方式工作。一個好的過程需要定義各個角色的工作承擔責任， 產品的建立，不同角色之間的協同工作等等。由於構架師每天的工作都需要和很多小組成員打交道，所以對於他們來說了解工作的職責是非常重要的。在每天的工作中，開發小組經常要找到構架師，瞭解該做什麼工作以及怎麼去做。這就是軟件構架師和項目經理之間的細微差別。
儘管擁有了豐富的軟件開發經驗，但是我們還期望（或者是要求）構架師擁有一定商業領域的知識。
[一個領域]是在一個範圍內工作的從業人員使用一系列特定的概念和術語來表達這個領域內的知識。 4
這種知識將會使構架師更好的理解系統的需求，並把精力投身於其中，確保系統的需求是合適的——例如，從構架師領域的角度出發，需求是要被準確捕獲的。經常會出現這樣的情況，一個特定系列的構架樣式可以被應用到與它相聯繫的一個特定的領域中。如果構架師知道這種映射關係，那麼對他的工作將是很大的幫助。
因此，一個好的構架師將會在軟件開發和商業領域的知識上面做出權衡。如果一個構架師具有很好的軟件開發經驗但是不瞭解商業領域，那麼他的解決方案可能不會解決實際的問題，而僅僅只能反映出構架師是多麼精通他的專業。
另外一個構架師需要精通商業領域知識的原因是，構架師要能夠預見軟件構架隨時可能出現的變化。由於軟件構架受它被配置的環境的影響非常大，所以對商業領域有正確理解的構架師，可以從軟件構架的角度，對不斷變化的情況做出更有遠見的決策。例如，如果構架師發覺哪種新的標準在未來很可能成爲主流，那麼他將會使自己的軟件構架在可用壽命內符合這種標準。
軟件構架的一個特定方面需要有一定的專業知識，因此一個構架師必須具備這個水平的知識才能夠勝任他的工作。可是構架師不必成爲技術專家，這體現了這篇文章第一部分的思想——構架師宏觀上的決策。因此，構架師只需要瞭解宏觀上的問題，而不必關心細節化的事情。由於技術的變化過於頻繁，所以構架師要隨時與這些變化保持同步。
雖然軟件構架並不僅僅是設計，但是設計無疑是很重要的一個組成部分。構架師應該擁有很好的設計技巧，因爲軟件的構架包含整個軟件的關鍵性設計決策。這種決定包括軟件主要結構的設計決策，特定部分的選擇以及指導的說明文檔等等。爲了確保系統構架的完整性，上面那些要素都要被特別的應用到設計中，這對整個系統的成功完成有很大的作用。因此這些要素需要有固定的擁有設計技巧的人來負責——這個人就是構架師。
開發人員是整個項目開發過程中最重要的一個小組之一，構架師要隨時和他們保持聯繫。畢竟他們要確保軟件在最後交付使用的時候能夠成功的執行。如果構架師認爲開發人員的工作是十分有價值的，那麼他們之間的交流將會很有效用。因此，軟件構架師需要擁有一定的程序設計技術，即使不需要他們編寫程序。
大多數成功的構架師，在一些場合中都是核心程序員，這些場合通常是他們的職業方向。即使是技術發展了，有新的程序語言出現，一個好的構架師可以把以前學過的設計語言的概念和新的語言聯繫起來，以達到對新語言更加深入的瞭解。沒有這種知識，軟件構架師就不能對需要執行的構架的重要元素做出完美的決策，例如執行的組織和程序標準的採用。這會使的軟件構架師和開發人員之間產生溝通上的障礙。
和以上提到的幾種技術比起來，構架師的溝通能力是最重要的。構架師需要精通所有的溝通手段，特別是需要有一定的語言能力，包括說，寫和演講能力。交流是雙向的，所以構架師還需要是一個很好的聆聽者與觀察者。
小組成員之間有效的溝通是項目成功的基本條件。爲了更好的理解投資人的需求，與他們的溝通顯得尤爲重要，同時還能夠讓所有的投資人在軟件構架上達成共識。與項目小組的溝通同時也很重要，因爲構架師的職責不單單是把信息傳達給小組，同時還要激勵他們工作。構架師還要負責把系統的構想傳達給小組成員，使得它們讓全組人員瞭解，而不僅僅是構架師自己理解。
構架師不能在自己不瞭解的環境中做出決策，然而項目的開發週期也沒有給他提供充足的時間去探索所有的環境，所以在很大的壓力下做的決策不太可能成功。這種環境是被期望的，成功的構架師非常滿意這種環境，而不願去改變它。因此構架師需要是厚臉皮的，因爲他們很可能在項目開發過程中更正自己的決定，並且按原路返回查找問題。正如Philippe Kruchten所說的：“軟件構架師的一生是一個漫長的，在黑暗中不斷摸索並不斷改進自己的決定的過程”。 5
一個糟糕的決策很可能毀掉一個項目。項目小組中的其他成員會對構架師失去信心，這時項目經理就要參與進來，因爲等待構架的完善不會讓項目有所進展。最危險的情況是：如果構架師沒有把自己的決策文檔化，那麼小組的其它成員可能會自己制定決策，而這種決定很可能是錯誤的。
一個成功的構架師不會只關心技術問題，他們還會關心組織的權力動向，時刻了解團隊的決定權在哪裏。這可以保證他們正在和正確的人討論項目的決策問題。忽略團隊的權力是天真的想法。現實往往是這樣的：團隊經常會強迫項目小組在規定時間交付系統，這需要構架師正確的評估到這個時間。
爲了瞭解軟件構架的很多尺度問題，構架師需要隨時和投資人溝通。這種溝通常常需要談判技巧。例如，構架師需要特別注意的一件事是：最小化項目中可能出現的風險，因爲這直接關係到系統構架的穩定性。由於風險是和需求緊密相連的，所以可以通過移除或者減小這方面的需求來降低風險。因此把這種需求取消，需要構架師和投資人達成共識的。這就需要構架師是一個有效的談判人員，來權衡這些問題。
這篇文章介紹了軟件構架師的一些工作。這個系列中的下幾篇將介紹軟件構架過程的特性，以及把軟件構架作爲IT資產的基礎處理的好處。
這篇文章來源於下面這本書，書名暫定爲：“軟件構架構建的過程”；下面我要感謝爲這篇文章中作註釋的人員：Grady Booch，Dave Braines，Alan Brown，Mark Dickson，Luan Doan-Minh，Holger Heuss，Kelli Houston，Philippe Kruchten，Nick Rozanski，Dave Williams以及Eoin Woods。
1 IEEE 計算機協會, IEEE 推薦的軟件密集型系統架構描述的實踐：IEEE 標準 1471-2000。
2 Jon R. Katzenbach 和 Douglas K. Smith 合著的Wisdom of Teams。 Harvard Business School 出版社1993.
註釋