1.1.2?? 架構師的職責<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

既然已經了解架構的含義，那我們再來看看負責創建架構的責任人：架構師。

架構師這個角色在任何軟件開發項目中都是最有挑戰性的。 ?

1. 架構師的領導與決策能力

??? 首先，架構師是一位技術領導，這意味著架構師除了擁有專門的技能外，還必須擁有領導能力，領導能力也要能體現在組織中的職位上。

? ??? 從職位上來講，架構師是項目中的技術領導，應該擁有進行技術決策的權威。不過，很多時候架構師和項目經理的職責很容易讓人混淆，下面用電影行業的職位來打一個比方，幫助大家了解他們的不同：項目經理是制片人（確保事情完成），而架構師是導演（確保事情正確地完成）。架構師和項目經理代表了這個項目的公共角色，對于項目外的關注人員來說，他們是主要的聯系點。架構師尤其應該是創建一個架構及給組織帶來價值的投資倡導者。

? ??? 在決策方面，架構師要綜合考慮，果斷下決定。例如，在某些情況不清楚或沒有充足的時間探究所有的可能性及有交付壓力的情況下，如果架構師不能進行決策，那是不行的。而且這樣的環境會很常見，架構師要接受這個現實而不是設法改變它。

? ??? 有些時候，架構師會在決策時咨詢其他人并營造其他人共同參與決策的環境，但是進行適當的決策仍然是架構師的職責，即使有時候這些決策并不總是正確的（當然，是事后才發現這些決策不正確的）。因此，架構師必須是厚臉皮的，因為他們可能必須糾正他們的決策并原路返回。

? ??? 沒有決策能力的架構師會使項目慢慢被破壞。項目團隊會對架構師失去信心，項目經理將會擔心，因為這些等待架構師決策的事項沒有進展。更加危險的是：如果架構師沒有制定關于架構的決策并編寫成文檔，團隊成員會開始制定他們自己的（可能是不正確的）決策。

2. 架構師的角色可能由一個團隊來履行

? ??? 角色和人之間是存在差異的。一個人可能會履行很多個角色，一個角色也可能會由許多人來履行。由于架構師需要非常廣泛的技能，所以，架構師這個角色可能會由多個人來履行，這時，架構團隊中的每個人都可以充分運用他自己的經驗來履行此角色。特別是在理解業務領域和各方面技術所必需的技能時，往往需要多人合作才能達到相關要求。有一點很重要，就是最終的團隊必須平衡。

? ??? 如果架構師角色由一個團隊來履行，擁有一個首席架構師就非常重要了，他是架構團隊的協調人，經常會有先見之明。沒有這個協調人，要讓架構團隊的成員創造出內聚的架構，或做出決策是很困難的。

? ??? 對于一個不熟悉架構概念的團隊來說，為了達成共同的目的，建議團隊應該創建并頒布一個團隊規章。

優秀的架構師知道他們的優勢和弱勢。最優秀的架構通常由一個團隊而不是個人創建的，這都是因為“眾人力量大”，人多則見識更廣和更深。

3. 架構師要理解軟件開發流程

? ??? 大部分架構師曾經都做過開發人員（幾乎是絕大部分架構師都是從開發人員走過來的），同時，架構師應該了解軟件開發流程，因為這個流程能確保團隊的所有成員協調的工作。

? ??? 這種協調性可以通過定義涉及的角色、從事的任務、創建的工作產品、不同角色之間的移交點來獲得。因為在日常工作中架構師會影響許多團隊成員，所以理解團隊成員的角色和職責，理解他們正在生產和使用的東西對于架構師來說很重要。實際上，團隊成員也非常希望架構師能夠指導他們的工作。

?

4. 架構師掌握技術與設計知識

? ??? 架構設計會涉及技術知識，所以，一個架構師應該擁有一定程度的技術技能。不過，架構師不必是一個技術專家，他要關注的是技術相關重要因素，而不是細節（其實很多時候，架構師也是技術專家，而且對細節理解得非常深入）。架構師需要理解像Java EE或.NET這樣的平臺上可用的關鍵框架，但是不必理解這些平臺程序編程接口（API）的細節。

? ??? 架構師必須與項目中的開發人員打交道，只有當架構師承認開發人員的工作價值時，在架構師和開發人員之間的溝通才是有效的。這也說明了，架構師應該具有一定的編程技能，即使他們在項目中不必編寫代碼，也必須跟上技術更新的腳步。

? ??? 架構師應該有組織地參與開發，并且盡可能地參與代碼的編寫。如果架構師參與實現，開發團隊會從架構師那兒獲得見識。架構師還可以通過查看他們決策和設計的第一手結果來進行學習，從而對開發流程給出反饋。

? ??? 大部分成功的軟件架構師都曾經是核心的編程人員。某種程度上來說，他們就是通過這段經歷了解到業務的某些情況的。如果沒有這些知識，要實架構上的重要元素（如源代碼的組織、采用的編程標準）時，架構師將無法進行決策，架構師和開發人員之間將會存在溝通障礙。

? ??? 另外，設計是架構設計的核心。架構使關鍵設計決策具體化，因此，架構師應該擁有很強的設計技能。關鍵設計決策指的是關鍵結構的設計決策、特定模型的選擇、指導規格說明書等。

? ??? 一個人不可能在短時間內獲得設計能力，這是多年經驗累積的結果。某些設計專家在回顧他們早期的工作時都會驚訝他們原來的設計是如此的不好。在學習一項新技能時，想要對此精通則必須進行設計實踐。

?

5. 架構師要掌握業務領域的知識

? ??? 架構師除了掌握軟件開發技術之外，還要理解業務領域相關知識（可以說是必須理解），以便擔任利益相關者、用戶（他們理解業務）及開發團隊成員（他們更熟悉技術）之間的中間人。

? ??? 業務領域的知識除了使架構師更好地理解系統的需求之外，還能夠確保他們及時捕獲恰當的需求。另外，一個特定領域通常與應用到這個解決方案中的特定架構模型組（和其他資源）相關，知道這個對照關系可以極大地幫助架構師。

? ??? 因此，一個優秀的架構師通常會平衡掌握軟件開發知識和業務領域知識。當架構師理解軟件開發但不理解業務模型時，可能會開發出只反映出他所熟悉內容但無法滿足需求的解決方案。

? ??? 熟悉業務領域使架構師能夠預見到架構中可能發生的改變。既然架構受其部署的環境（包括業務領域）影響很大，對業務領域的正確認識會使架構師在可能改變的區域和穩定性方面做出更全面的決策。舉例來說，如果架構師認識到在將來的某點必須符合新的調整標準，他會在架構中考慮這個需求。

?

6. 架構師是優秀的溝通人員

? ??? 在架構師相關的所有軟技能中，溝通最重要。有效溝通所涉及的各個方面架構師必須全部精通。架構師尤其要擁有較強的口頭、書面表達能力同時，溝通是雙向的，架構師應該既是優秀的聆聽者，也是優秀的觀察者。

? ??? 有許多理由說明有效溝通是項目成功的基礎。很明顯，與利益相關者的溝通對于理解他們的需求，以及就架構相關問題與他們達成（并保持）一致來說非常重要。

? ??? 與項目團隊溝通也是十分重要的，因為架構師不能只是簡單地把信息傳達給團隊，他還要激發團隊，比如他必須要傳達（并強調）系統的愿景，讓大家都了解這個愿景，而不是只有他自己理解并相信。

? ??? 同時，架構師也必須是一位比較好的談判專家。對于架構設計的許多方面，架構師需要與眾多利益相關者進行交流，其中的一些交流則需要談判技巧。

? ??? 另外，架構師應特別關注如何在項目中盡可能早地把風險降到最小，因為這會對穩定架構所花的時間有直接影響。風險與需求（及需求中的變化）有關，消除風險的一個途徑是精煉需求，以便這種風險不再出現，那么這就需要回退需求并和利益相關者達成一致意見了。在這種情形下，如果架構師是一位談判高手，能夠清晰明白地表明不同折中的后果，相信一定會事半功倍。

7. 架構師了解組織政策

??? 成功的架構師并不只是關心技術，他們還要對政治足夠敏感，并且知道組織中的權力所在。他們可利用這些知識與恰當的人溝通，確保在項目的適當周期中獲得相應的支持。

? ??? 政策包括大量的不確定性，這會使許多技術人員緊張，讓他們感覺仿佛在“客場”比賽，他們正處于一個不利的位置，因為他們的技術不能發揮出多大的威力。

? ??? 實際上，組織中起作用的許多強制約束位于項目交付的系統之外，并且這些約束是必須考慮的。為了解決不同的意見，一個政策性流程是不可避免的。因此，與其譴責它，倒不如把政策理解成是處理不同意見的必然需求。 ? 當當網：http://product.dangdang.com/product.aspx?product_id=22574513 京東地址：http://book.360buy.com/10893935.html 卓越地址：http://www.amazon.cn/mn/dp/B006NS2N0S

轉載于:https://blog.51cto.com/yanyangtian/746208

總結

以上是生活随笔為你收集整理的《.NET应用架构设计：原则、模式与实践》新书博客--试读-1.1.2 架构师的职责的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。