架構師的職責

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

 

1. 架構師的領導與決策能力
首先，架構師是一位技術領導，這意味着架構師除了擁有專門的技能外，還必須擁有領導能力，領導能力也要能體如今組織中的職位上。

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

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

有些時候，架構師會在決策時諮詢其餘人並營造其餘人共同參與決策的環境，可是進行適當的決策仍然是架構師的職責，即便有時候這些決策並不老是正確的（固然，是過後才發現這些決策不正確的）。所以，架構師必須是厚臉皮的，由於他們可能必須糾正他們的決策並原路返回。

沒有決策能力的架構師會使項目慢慢被破壞。項目團隊會對架構師失去信心，項目經理將會擔憂，由於這些等待架構師決策的事項沒有進展。更加危險的是：若是架構師沒有制定關於架構的決策並編寫成文檔，團隊成員會開始制定他們本身的（多是不正確的）決策。

2. 架構師的角色可能由一個團隊來履行
角色和人之間是存在差別的。一我的可能會履行不少個角色，一個角色也可能會由許多人來履行。因爲架構師須要很是普遍的技能，因此，架構師這個角色可能會由多我的來履行，這時，架構團隊中的每一個人均可以充分運用他本身的經驗來履行此角色。特別是在理解業務領域和各方面技術所必需的技能時，每每須要多人合做才能達到相關要求。有一點很重要，就是最終的團隊必須平衡。

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

對於一個不熟悉架構概念的團隊來講，爲了達成共同的目的，建議團隊應該建立並頒佈一個團隊規章。
優秀的架構師知道他們的優點和弱勢。最優秀的架構一般由一個團隊而不是我的建立的，這都是由於「衆人力量大」，人多則見識更廣和更深。

3. 架構師要理解軟件開發流程
大部分架構師曾經都作過開發人員（幾乎是絕大部分架構師都是從開發人員走過來的），同時，架構師應該瞭解軟件開發流程，由於這個流程能確保團隊的全部成員協調的工做。

這種協調性能夠經過定義涉及的角色、從事的任務、建立的工做產品、不一樣角色之間的移交點來得到。由於在平常工做中架構師會影響許多團隊成員，因此理解團隊成員的角色和職責，理解他們正在生產和使用的東西對於架構師來講很重要。實際上，團隊成員也很是但願架構師可以指導他們的工做。

 

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

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

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

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

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

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

 

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

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

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

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

 

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

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

與項目團隊溝通也是十分重要的，由於架構師不能只是簡單地把信息傳達給團隊，他還要激發團隊，好比他必需要傳達（並強調）系統的願景，讓你們都瞭解這個願景，而不是隻有他本身理解並相信。

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

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

7. 架構師瞭解組織政策
成功的架構師並不僅是關心技術，他們還要對政治足夠敏感，而且知道組織中的權力所在。他們可利用這些知識與恰當的人溝通，確保在項目的適當週期中得到相應的支持。

政策包括大量的不肯定性，這會使許多技術人員緊張，讓他們感受彷彿在「客場」比賽，他們正處於一個不利的位置，由於他們的技術不能發揮出多大的威力。

實際上，組織中起做用的許多強制約束位於項目交付的系統以外，而且這些約束是必須考慮的。爲了解決不一樣的意見，一個政策性流程是不可避免的。所以，與其譴責它，倒不如把政策理解成是處理不一樣意見的必然需求。