| Peter Eeles, 高級 IT 架構師, IBM 2006 年 3 月 15 日 來(lái)自于 Rational Edge：在電影制作術(shù)語(yǔ)中，軟件項目經(jīng)理被稱(chēng)作制作人，因為他們決定需要做什么事情。而軟件構架師就是導演，他來(lái)決定所作的事情是否正確，并且他要保證產(chǎn)品符合投資人的要求。下面這篇文章就是描述軟件構架師的。  下面是電氣及電子工程師協(xié)會(huì )給“構架師”做的定義： [構架師是]負責系統構架的人，團隊或者組織。 1 作為項目的技術(shù)主管，構架師的技術(shù)需要非常的廣泛，這比技術(shù)深度更加重要（當然構架師在特定的領(lǐng)域需要一定的技術(shù)深度）。 首先，軟件構架師是技術(shù)主管，這意味著(zhù)除了他要有技術(shù)上的技能外，還要有很好的領(lǐng)導才能。構架師的領(lǐng)導能力在團隊中和項目質(zhì)量控制中起著(zhù)十分重要的作用。 在團隊中，構架師是項目的技術(shù)總管，他需要有豐富的知識背景，以便作出技術(shù)上的決定。相對于構架師來(lái)說(shuō)，項目經(jīng)理是來(lái)管理項目的資源，時(shí)間進(jìn)度和花費的。使用電影制作來(lái)做類(lèi)比的話(huà)，項目經(jīng)理就是制片人（他要確定工作被完成了），而構架師是導演（他需要確定工作被正確的完成）。由于他們在項目中所處的位置，構架師和項目經(jīng)理是公眾人物，在一個(gè)團隊中，他們是整個(gè)項目所涉及的所有人員的聯(lián)系樞紐。構架師應該為建立軟件構架爭取投資，并且要明確建立軟件構架能給組織帶來(lái)的價(jià)值。 構架師還要把團隊組織在構架周?chē)?，并且要積極地投入到計劃活動(dòng)上，因為要把構架轉化成為完成任務(wù)的先后順序，這樣才能及時(shí)地確定在什么位置需要什么技術(shù)。有一點(diǎn)需要注意，由于構架師能否成功與團隊的整體水平有很大關(guān)系，所以構架師應該參與團隊新成員錄用的面試。 根據構架師所擁有的能力，他可以同時(shí)參與其他團隊的工作。構架師需要根據具體的實(shí)例情況來(lái)做領(lǐng)導決定，并且在決定過(guò)程中要展現出足夠的自信。一個(gè)成功的構架師是以人為導向的，并且像一個(gè)教練一樣給他的團隊安排工作時(shí)間。這對于小組的成員來(lái)說(shuō)是有好處的，他們可以及時(shí)得到幫助。這是整個(gè)團隊的一個(gè)巨大財富。 構架師還要把精力放在切實(shí)工作的交付上，他是技術(shù)方面的推進(jìn)力量。構架師需要做決定（經(jīng)常需要在壓力下做決定），并且要保證這些決定是經(jīng)過(guò)成員之間的交流的，并且確保它能夠執行。 下面介紹一個(gè)人和一個(gè)角色的區別。一個(gè)人可以扮演很多角色（例如，Mary是一個(gè)開(kāi)發(fā)人員，同時(shí)也是一個(gè)測試人員），同時(shí)，一個(gè)角色可以有很多的人扮演（例如，Mary和John都是測試人員）。構架師的角色需要非常廣泛的技術(shù)，這就為什么構架師的角色經(jīng)常是很多人同時(shí)擔當。這樣可以使技術(shù)知識在小組中傳播開(kāi)來(lái)，每一個(gè)人都把他的或者她的經(jīng)驗帶到工作中。特別是當某種技術(shù)同時(shí)被商業(yè)部門(mén)和技術(shù)小組理解的時(shí)候，這項技術(shù)就會(huì )最大程度的傳播開(kāi)來(lái)。小組所作的結果，需要被"平衡。" 貫穿整個(gè)文章的術(shù)語(yǔ)"構架師"，是指的一個(gè)人或者整個(gè)小組的成員。 [一個(gè)小組]是一些擁有各種技術(shù)的人的集合，他們之間有共同需要完成的目標，并且之間相互負責任。 2 如果一個(gè)小組來(lái)?yè)敇嫾軒煹慕巧?，那么就需要有一個(gè)人作為這些構架師的領(lǐng)導，他要擁有整體的前景，并且需要調節構架師小組之間的問(wèn)題。如果沒(méi)有這種調節，構架師小組成員之間就會(huì )存在危險，他們可能不會(huì )建立出一個(gè)緊密地構架或者決策不會(huì )被成功的完成。 現在有一個(gè)新的概念在構架師小組中被提出：為了使成員之間達到共同的目的和目標，團隊為構架師小組建立并發(fā)布了一個(gè)章程。 3 好的構架師知道自己的強項和弱點(diǎn)在哪里。無(wú)論構架師的角色被一個(gè)人還是一個(gè)小組擔當，他們背后都有"值得信賴(lài)的顧問(wèn)"的支持。他們可以通過(guò)和其他構架師協(xié)同工作來(lái)彌補自身在某些技術(shù)方面的不足。最好的構架通常是被一個(gè)構架師小組建立的，而不是一個(gè)人。原因很簡(jiǎn)單，一個(gè)小組的力量總要比一個(gè)人的知識豐富的多。 構架師小組的概念有一個(gè)缺陷，他們有時(shí)被團隊中的其他人認為是在"象牙塔"里工作，因為他們的產(chǎn)品經(jīng)常是很有智慧的但卻沒(méi)有使用價(jià)值。這種誤解可以從開(kāi)始就把它減到最?。?)確保所有的涉眾都能積極地協(xié)商，2)不斷的交流構架和它的價(jià)值，3)在執行過(guò)程中要有組織策略的意識。 構架師應該對軟件開(kāi)發(fā)過(guò)程有正確的估計，因為這個(gè)過(guò)程確保小組中的所有成員使用同等的方式工作。一個(gè)好的過(guò)程需要定義各個(gè)角色的工作承擔責任， 產(chǎn)品的建立，不同角色之間的協(xié)同工作等等。由于構架師每天的工作都需要和很多小組成員打交道，所以對于他們來(lái)說(shuō)了解工作的職責是非常重要的。在每天的工作中，開(kāi)發(fā)小組經(jīng)常要找到構架師，了解該做什么工作以及怎么去做。這就是軟件構架師和項目經(jīng)理之間的細微差別。 盡管擁有了豐富的軟件開(kāi)發(fā)經(jīng)驗，但是我們還期望（或者是要求）構架師擁有一定商業(yè)領(lǐng)域的知識。 [一個(gè)領(lǐng)域]是在一個(gè)范圍內工作的從業(yè)人員使用一系列特定的概念和術(shù)語(yǔ)來(lái)表達這個(gè)領(lǐng)域內的知識。 4 這種知識將會(huì )使構架師更好的理解系統的需求，并把精力投身于其中，確保系統的需求是合適的——例如，從構架師領(lǐng)域的角度出發(fā)，需求是要被準確捕獲的。經(jīng)常會(huì )出現這樣的情況，一個(gè)特定系列的構架樣式可以被應用到與它相聯(lián)系的一個(gè)特定的領(lǐng)域中。如果構架師知道這種映射關(guān)系，那么對他的工作將是很大的幫助。 因此，一個(gè)好的構架師將會(huì )在軟件開(kāi)發(fā)和商業(yè)領(lǐng)域的知識上面做出權衡。如果一個(gè)構架師具有很好的軟件開(kāi)發(fā)經(jīng)驗但是不了解商業(yè)領(lǐng)域，那么他的解決方案可能不會(huì )解決實(shí)際的問(wèn)題，而僅僅只能反映出構架師是多么精通他的專(zhuān)業(yè)。 另外一個(gè)構架師需要精通商業(yè)領(lǐng)域知識的原因是，構架師要能夠預見(jiàn)軟件構架隨時(shí)可能出現的變化。由于軟件構架受它被配置的環(huán)境的影響非常大，所以對商業(yè)領(lǐng)域有正確理解的構架師，可以從軟件構架的角度，對不斷變化的情況做出更有遠見(jiàn)的決策。例如，如果構架師發(fā)覺(jué)哪種新的標準在未來(lái)很可能成為主流，那么他將會(huì )使自己的軟件構架在可用壽命內符合這種標準。 軟件構架的一個(gè)特定方面需要有一定的專(zhuān)業(yè)知識，因此一個(gè)構架師必須具備這個(gè)水平的知識才能夠勝任他的工作?？墒菢嫾軒煵槐爻蔀榧夹g(shù)專(zhuān)家，這體現了這篇文章第一部分的思想——構架師宏觀(guān)上的決策。因此，構架師只需要了解宏觀(guān)上的問(wèn)題，而不必關(guān)心細節化的事情。由于技術(shù)的變化過(guò)于頻繁，所以構架師要隨時(shí)與這些變化保持同步。 雖然軟件構架并不僅僅是設計，但是設計無(wú)疑是很重要的一個(gè)組成部分。構架師應該擁有很好的設計技巧，因為軟件的構架包含整個(gè)軟件的關(guān)鍵性設計決策。這種決定包括軟件主要結構的設計決策，特定部分的選擇以及指導的說(shuō)明文檔等等。為了確保系統構架的完整性，上面那些要素都要被特別的應用到設計中，這對整個(gè)系統的成功完成有很大的作用。因此這些要素需要有固定的擁有設計技巧的人來(lái)負責——這個(gè)人就是構架師。 開(kāi)發(fā)人員是整個(gè)項目開(kāi)發(fā)過(guò)程中最重要的一個(gè)小組之一，構架師要隨時(shí)和他們保持聯(lián)系。畢竟他們要確保軟件在最后交付使用的時(shí)候能夠成功的執行。如果構架師認為開(kāi)發(fā)人員的工作是十分有價(jià)值的，那么他們之間的交流將會(huì )很有效用。因此，軟件構架師需要擁有一定的程序設計技術(shù)，即使不需要他們編寫(xiě)程序。 大多數成功的構架師，在一些場(chǎng)合中都是核心程序員，這些場(chǎng)合通常是他們的職業(yè)方向。即使是技術(shù)發(fā)展了，有新的程序語(yǔ)言出現，一個(gè)好的構架師可以把以前學(xué)過(guò)的設計語(yǔ)言的概念和新的語(yǔ)言聯(lián)系起來(lái)，以達到對新語(yǔ)言更加深入的了解。沒(méi)有這種知識，軟件構架師就不能對需要執行的構架的重要元素做出完美的決策，例如執行的組織和程序標準的采用。這會(huì )使的軟件構架師和開(kāi)發(fā)人員之間產(chǎn)生溝通上的障礙。 和以上提到的幾種技術(shù)比起來(lái)，構架師的溝通能力是最重要的。構架師需要精通所有的溝通手段，特別是需要有一定的語(yǔ)言能力，包括說(shuō)，寫(xiě)和演講能力。交流是雙向的，所以構架師還需要是一個(gè)很好的聆聽(tīng)者與觀(guān)察者。 小組成員之間有效的溝通是項目成功的基本條件。為了更好的理解投資人的需求，與他們的溝通顯得尤為重要，同時(shí)還能夠讓所有的投資人在軟件構架上達成共識。與項目小組的溝通同時(shí)也很重要，因為構架師的職責不單單是把信息傳達給小組，同時(shí)還要激勵他們工作。構架師還要負責把系統的構想傳達給小組成員，使得它們讓全組人員了解，而不僅僅是構架師自己理解。 構架師不能在自己不了解的環(huán)境中做出決策，然而項目的開(kāi)發(fā)周期也沒(méi)有給他提供充足的時(shí)間去探索所有的環(huán)境，所以在很大的壓力下做的決策不太可能成功。這種環(huán)境是被期望的，成功的構架師非常滿(mǎn)意這種環(huán)境，而不愿去改變它。因此構架師需要是厚臉皮的，因為他們很可能在項目開(kāi)發(fā)過(guò)程中更正自己的決定，并且按原路返回查找問(wèn)題。正如Philippe Kruchten所說(shuō)的：“軟件構架師的一生是一個(gè)漫長(cháng)的，在黑暗中不斷摸索并不斷改進(jìn)自己的決定的過(guò)程”。 5 一個(gè)糟糕的決策很可能毀掉一個(gè)項目。項目小組中的其他成員會(huì )對構架師失去信心，這時(shí)項目經(jīng)理就要參與進(jìn)來(lái)，因為等待構架的完善不會(huì )讓項目有所進(jìn)展。最危險的情況是：如果構架師沒(méi)有把自己的決策文檔化，那么小組的其它成員可能會(huì )自己制定決策，而這種決定很可能是錯誤的。 一個(gè)成功的構架師不會(huì )只關(guān)心技術(shù)問(wèn)題，他們還會(huì )關(guān)心組織的權力動(dòng)向，時(shí)刻了解團隊的決定權在哪里。這可以保證他們正在和正確的人討論項目的決策問(wèn)題。忽略團隊的權力是天真的想法?，F實(shí)往往是這樣的：團隊經(jīng)常會(huì )強迫項目小組在規定時(shí)間交付系統，這需要構架師正確的評估到這個(gè)時(shí)間。 為了了解軟件構架的很多尺度問(wèn)題，構架師需要隨時(shí)和投資人溝通。這種溝通常常需要談判技巧。例如，構架師需要特別注意的一件事是：最小化項目中可能出現的風(fēng)險，因為這直接關(guān)系到系統構架的穩定性。由于風(fēng)險是和需求緊密相連的，所以可以通過(guò)移除或者減小這方面的需求來(lái)降低風(fēng)險。因此把這種需求取消，需要構架師和投資人達成共識的。這就需要構架師是一個(gè)有效的談判人員，來(lái)權衡這些問(wèn)題。 這篇文章介紹了軟件構架師的一些工作。這個(gè)系列中的下幾篇將介紹軟件構架過(guò)程的特性，以及把軟件構架作為IT資產(chǎn)的基礎處理的好處。 這篇文章來(lái)源于下面這本書(shū)，書(shū)名暫定為：“軟件構架構建的過(guò)程”；下面我要感謝為這篇文章中作注釋的人員：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 計算機協(xié)會(huì ), IEEE 推薦的軟件密集型系統架構描述的實(shí)踐：IEEE 標準 1471-2000。 2 Jon R. Katzenbach 和 Douglas K. Smith 合著(zhù)的Wisdom of Teams。 Harvard Business School 出版社1993. 3 Philippe Kruchten, "The Architects -- The Software Architecture Team," Proceedings of the First Working IFIP Conference on Software Architecture (WICSA1). Patrick Donohoe (editor). Kluwer Academic Publishing 1999. 4 Grady Booch, James Rumbaugh 和 Ivar Jacobson, The Unified Modeling Language User Guide. Addison Wesley 1999。 5 Philippe Kruchten, Op. cit. |
聯(lián)系客服
