架構的技術職責分為三大塊：
抽象設計；
非功能設計；
關鍵技術設計。
首先是抽象設計。架構師需要能自由地在不同的抽象層次和視角上分析需求，不同的架構層次/視角提供了不同的檢視，這些檢視互相驗證，又能構成整體的設計大圖。架構的抽象層次分成兩個維度：
垂直維度
從上到下，分成企業架構、解決方案架構、應用架構、系統架構等，這個分層的邏輯，是提供不同顆粒度的業務建模。cto關注企業架構，它提現了乙個企業整體的it技術建設的戰略選擇，典型的就是集中式和soa、大型機和雲計算的選擇等；產品經理和運維關注應用架構，這裡映**產品的業務流程和應用的整體部署依賴；外部客戶關注解決方案架構，它定義了如何通過產品的整合和協同，解決特定客戶的特定的技術方案需求；研發工程師關注系統架構，這裡定義了單個系統的領域建模和系統框架。
水平維度
具體到對某乙個業務的架構設計，又可以區分出業務架構、資料架構、技術架構、應用架構幾個不同的視角。業務架構是對業務領域和業務流程的分析抽象，需要提煉出業務的核心領域模型，業務的可變和不變部分，這是架構師和產品經理協同完成的；資料架構基於業務架構提煉的核心領域模型做資料模型和儲存模型的設計；技術架構基於業務的效能，可用性，安全等非功能性指標，確定語言、框架、中介軟體、部署等技術選型；應用架構基於業務抽象設計應用系統的層次結構、系統邊界等。
在這些架構劃分中，企業架構匹配商業模式，業務架構匹配業務模式，其他幾個架構的劃分，更多的是從技術的不同視角來看，他們提供了從不同的抽象層次，不同的切面對於功能需求的分析和建模。
同時需要說明的是，架構的抽象是匹配於業務的，就像橋梁設計師不能直接轉做摩天大樓設計，架構抽象也是區分領域的，每乙個業務領域都有自己的獨特性，因此在架構上也是千人千面的，好的架構設計也是對於業務抽象得最好的設計。
架構師的另乙個技術職責，是對非功能需求的分析。這也是「架構服務於功能，高於功能」的含義。這裡的非功能性需求包括了軟體系統的可靠性、擴充套件性、可測性、資料一致性、安全和效能等。考慮到成本和執行環境等限制，這些非功能性需求很多時候是不能同時滿足的。這個時候就需要「權衡」，空間換時間的演算法層面的權衡，效能和可測性、可靠性的權衡，一些權衡甚至上公升到了學術層面，變成無完美架構的理論根基（如cap理論）。
架構師的最後乙個技術職責是關鍵技術設計。建築師不只是做整體外觀設計的，建築師也需要考慮關鍵部分的細節設計——曾經在巴塞隆納聖家堂，我甚至看到高迪連教堂裡一把椅子都留下了詳細的設計圖紙。同理，架構師也需要對可能影響到軟體系統整體質量的關鍵部分，做更細節的詳細設計。
2.2、架構的組織職責
架構師是企業的一員，作為「邊界人」，承擔著在不同角色、團隊之間溝通協調的作用。
和業務、產品團隊的協作
軟體系統是解決現實世界的問題的，任何的軟體系統都是業務相關的，當乙個軟體系統的商業模式確定之後，架構師就開始和業務、產品團隊緊密合作，確定軟體系統的業務架構和領域模型。業務和領域模型抽象的好壞，決定了軟體產品是一次性的解決方案，還是可以持續支撐業務成長的真正的產品。
需要說明的是，業務、產品方和架構師是需求方和實施方的關係，所以，雙方之間既是合作的關係，有時候也是談判雙方的關係，特別是對於外包型的軟體產品而言，這個時候，架構師又承擔著在業務方和技術團隊之間找到訴求契合點的重任。
和技術團隊的協作
研發階段，有架構師參與的專案，往往牽涉多個不同方向，不同業務領域的研發團隊。架構在其中的作用，是整體大圖的傳導，以及應用和團隊研發邊界的劃分，對於影響到整體的非功能需求的關鍵技術點，架構師也要能親力親為完成設計。歸根結底，架構師為軟體系統的整體質量負責，也為研發團隊的研發分工負責。
部署階段，架構師需要和運維團隊一起評估滿足整體非功能需求的前提下，軟體系統部署的硬體成本和部署拓撲結構。例如對於網際網路應用，針對性能要求，是否需要cdn，頻寬需求；針對可靠性，是否需要多機房部署；針對安全，是否部署相關的安全軟體。最終的部署策略，仍然是基於成本和需求的乙個權衡。
技術團隊是架構師的大本營。根據不同公司的職能定位不同，有的架構師立足於技術團隊，有的游離於技術團隊。立足技術團隊使架構師能更深入了解團隊所負責的產品，因此能對業務做更合理的建模，也有利於架構師對關鍵技術方案做針對性設計，但是可能會限制了架構師擁有更加全域性的視角。游離於技術團隊的架構師能夠從全域性看待軟體設計而不受制於屁股，因此更能從客觀合理的角度規劃整體設計，但是由於對技術團隊沒有管理職能，對於方案的落地只能依靠個人的技術號召力，而且，游離意味著疏遠，如果架構師不能自覺地去跟進軟體產品的實際落地，可能慢慢就會架空，變成ppt架構師。
簡言之，架構師既不能完全負責某個技術團隊，也不能完全游離在技術團隊之外，這個，又是乙個職能定位的權衡了。
同時，架構師和技術團隊的協作，還有乙個很重要的組織職能。如前述，架構師既決定了整體的架構選型，也決定了關鍵的技術方案的設計，而什麼是需要架構師親力親為的關鍵技術方案，是架構師來確定的。因此，這就引申出架構師的另乙個重要的組織職能——團隊培養。如果架構師完成所有的技術方案設計，研發團隊只管寫**，架構師會累死，研發團隊也不會成長，這就要求架構師給予研發團隊足夠的成長空間和信任，並因此承擔一定的風險和責任，這是這個角色必須承擔的。
和其他角色的協作
除了產品和技術團隊，架構師需要協作的還有專案經理，外部客戶，甚至是公司財務……一句話，架構師作為技術方案的總負責人，對接所有對技術方案有關聯關係的合作方。
如何溝通
協作就需要溝通，架構需要掌握多門溝通語言，而最好的語言是圖表。對於產品來說，架構師溝通的工具是業務架構，用例和領域模型；對於研發團隊來說，架構師溝通的工具是應用架構，元件和時序圖；對於運維團隊來說，溝通的語言又成了部署架構。圖表的作用是維護共同的語言，同時也是讓設計文件化以便於傳承。
3、架構師的成長
上面講了架構師的職責，職責既是能力的要求。可以看到，架構師既是乙個全方位的技術專家，也是乙個溝通協作的專家。因此，總結一下，架構師的成長，也是兩條線：
技術上架構師的首要工作是抽象建模，而首要的首要是要了解自己所處的業務領域，只有對業務足夠了解，才能更好地抽象和建模，也更能沉澱通用的設計方**。幾年前，我曾經看過我司首席架構師的書單，其中有銀行卡組織的介紹的，有零售銀行的業務分析的，而那個時候，我司還只是金融業邊上的支付公司而已。
另一方面，架構師需要在業務領域所涉及到的技術領域中，都要了解甚至精通，譬如對於網際網路行業的架構師，小到語言、演算法、資料庫，大到網路協議，分布式系統，伺服器，中介軟體，idc等等都需要涉獵。一句話，架構師是技術團隊的對外介面人，也應該是外部團隊技術問題的終結者。廣度之外也要深度，對於關鍵的技術模組的設計，架構師需要有技術的權威性。
組織和個人成長上
架構師要作為業務和技術的橋梁，因此需要精通業務和技術的語言，要鍛鍊溝通能力，不只是口頭的溝通能力，也包括用標準化的圖表表達設計思路的能力。
架構師需要一種「中庸之道」。不管是技術的選型，團隊的協作、培養和分工，商業訴求和成本、產品需求和技術訴求的匹配，很多時候都是一種權衡。可以說，架構的工作主題就是權衡，這可能也是工程師成長為架構師最大的挑戰。工程師經常是完美主義的，程式也總是精準精確的，但是架構師要習慣於不完美和一定條件下的不精確。
4、補充說明
另外，架構師也不是技術人員唯一的方向，甚至不是大多數技術人員的職業方向。在技術上，架構師是廣度優先兼具深度，同時在技術之外附帶了許多的業務性和組織職能，而很多的技術人員會更傾向於在技術的深度上不斷挖掘，也不願意投入太多的精力在業務和溝通上，這樣的技術人員其實更適合的是技術專家的路線。技術專家研究的是純粹的技術，這裡面可能有演算法、有程式語言、有執行容器（虛擬機器、作業系統、應用伺服器、中介軟體）、有通訊機制，這些都有足夠的源源不斷的問題等著技術人員去解決，而他們解決的問題，也成為軟體技術不斷向上抽象，不斷模式化的基礎，所以，技術專家的路線也是同樣重要的。
支付寶架構師對話騰訊研發總監暢談架構
v2 y2 p 馮大輝 假設一家c2c db中某錶儲存買賣雙方交易的資料資訊，對於一條交易來說，買賣雙方資料具有一定程度的耦合性，比如賣家的狀態更新對應買家的狀態也會更新，對於乙個中大規模的電子商務 架構師在設計中如何考慮資料分片的問題 假定該錶隨著資料的膨脹必須拆分 王速瑜 對於乙個中大規模的電子...
架構師之路 架構師思維的培養
公司的cms 綜合賦碼管理系統 是winform的cs架構。這套系統的架構師換了3屆，到現在已經幾年沒有架構師了。本來入職時，崗位目標就是這個 自動化架構師 後來和領導達成共識先爭取成為儲備架構師，因為架構首先是為業務服務的，而工控行業有許多特別的地方，不是普通的軟體技術堆疊就能做出優秀的工控軟體的...
架構師之路 架構師思維的培養
公司的cms 綜合賦碼管理系統 是winform的cs架構。這套系統的架構師換了3屆，到現在已經幾年沒有架構師了。本來入職時，崗位目標就是這個 自動化架構師 後來和領導達成共識先爭取成為儲備架構師，因為架構首先是為業務服務的，而工控行業有許多特別的地方，不是普通的軟體技術堆疊就能做出優秀的工控軟體的...