首先我們來看看ebay的架構師randy shoup先生是如何總結架構師在專案中的職責的：
1. 產品團隊要做乙個新產品，架構師開工了。架構師要幫助產品團隊把可行性、技術需求以及權衡取捨等因素一一剖析清楚。
2. 技術需求出來了，架構師的主要工作開始了：設計整體的技術實現步驟。randy在後面補充說「大多數成功的架構師都喜歡與其他團隊成員一同完成架構和設計這一塊的工作」，而認為自己應獨自完成這個步驟則是新手架構師常見的誤區。
3. 與開發團隊一起，完成設計與實施的細節
4. 與開發團隊和運維團隊一起，完成部署的過程
5. 與運維團隊一起，進行部署之後的維護和故障排除
在這個過程中，乙個架構師至少有一半以上的工作是需要與開發團隊一起進行的。按照randy的描述，這是「乙個架構師不能將實施細節拋之腦後」的體現。而且與開發團隊一起工作，命令式的領導方式並不被推崇，乙個架構師必須通過自己的個人影響力來對開發團隊進行指導工作。而什麼是影響力？說的直白一些，就是通過自己寫**以及和其他成員一起寫**，來指導團隊成員實現每個架構細節的思路。
只要稍微思考一下，就會明白此舉的重要性。如果乙個架構師靠命令管理開發團隊，告訴他們「要實現這個模組」，「要實現那個功能」，而團隊也嘗試照辦。可是或許是架構師的要求太高了，或許是團隊的開發實力不夠，團隊成員便會向架構師求助：您看這個我們不知道如何實現，您能否指導一下？架構師可能知道怎麼處理，也可能沒有仔細思考過這個問題，但又覺得自己做大事者不拘泥於小節也，於是一皺眉頭扔下一句：這是你們的事，你們自己解決！
然後就是矛盾的開始了。架構師只覺得團隊技術不夠，而團隊則對架構師愈發不滿。專案黃了不說，開發團隊中也會傳出各種說法，比如說「此君其實是個一行**也不會寫的大忽悠！」
綜上所述，便映證了fred的那句斷言：「不程式設計的架構師的職業生涯是短暫的」。乙個架構師不僅要會寫**，還必須要能夠寫出自己設計的系統中最難實現的那段**。這樣他才能夠放心的把「落地」的這個重擔交給開發團隊來做。
讓我用fred的這句話做為本篇的總結：「乙個架構師的價值在於，他不僅能看到系統的美，而且能夠在建造系統的時候能夠把這些美創造出來。」
是的，每個好架構師都是一位出色的程式設計師。
架構師的職責
架構師的職責 每個公司對於架構師的職責定位不同,一般來說架構師的職責主要體現在以下幾方面 1.負責公司系統的架構設計 研發工作 2.承擔從業務向技術轉換的橋梁作用 3.協助專案經理制定專案計畫和控制專案進度 4.負責輔助並指導 sa 系統分析師 開展設計工作 5.負責組織技術研究和攻關工作 6.負責...
架構師的職責範圍
架構師的職責範圍很難界定。我想成為一名優秀的架構師，寫這篇文章是為了明確方向。1 設計框架。例如開發乙個struts spring框架。這種類別是最高端別，開發乙個通用的框架給所有應用使用，要求在需求分析 系統設計 程式開發等各個方面都具備豐富經驗。2 企業整合。例如實行統一的技術標準，安全標準，使...
軟體架構師的「不歸之路「 架構師的職責
軟體架構師的 不歸之路 架構師的職責 架構師負責設計系統整體架構，從需求到設計的每個細節都要考慮到，把握整個專案，使設計的專案盡量效率高，開發容易，維護方便，公升級簡單。架構師的主要責任是提供開發人員和專案經理之間的共用溝通 他們負責讓業務規則及需求與工程實踐及限制相適應，以確保成功。架構師的職責就...