在最近一段時間一直有幾個問題纏繞着我，架構師該做什麼？如何成爲一個名副其實的架構師？帶着這個問題我查閱了很多資料，請教了很多人，但依然沒有找到我需要的答案。
請教猛哥，他告訴我，就把你對質量的知識遷移到質量運營就好了，當時不得其解。後來一次和周老師討論這個問題，他說你就別管架構師這高深的名詞，就從你擅長的角度思考這個問題，作爲一個質量負責人，你需要關注產品的那些方面？我很快的告訴了他以下六個詞。
可用、可靠、易用、效率、可配置（可維護）、兼容（可移植）
然後他很認真的對我說，架構本身就是爲軟件質量服務的，你就從你剛纔理解的這六個詞重新思考下什麼是架構，然後你就明白該如何做了。
回到工位把那六個詞寫下來，並認真思考，在某個瞬間恍然大悟，這六個詞不就是ISO9126中關於質量模型的六大特性麼？有了這個啓發，我重新從質量的視角思考架構師的工作。
1.架構師分類
從質量模型的上圖從左往右前三個是對用戶來說可以感知的屬，後三個主要是質量內建相關的屬性，系統運維運營需要關注的點。這樣來看，功能性、可靠性和易用性，其實不就是應用架構師的職責麼；效率、維護性和可移植性不就是系統架構師職責麼？
應用架構師：負責構建一個以解決特定業務問題爲目標的軟件應用，一般以滿足各種功能性需求以及維護性需求爲設計考慮目標；從應用程序的維度，偏業務系統，從用戶的角度關注業務理解，負責某個應用的技術架構，梳理模型，設計模式，接口，數據交互等方面。
系統架構師：以企業的持續經營目標爲考慮要素來構建企業所需要的內在結構設計；提供運營支撐軟件應用的信息系統的結構設計。從系統的維度，負責整體系統的架構設計，主要是基礎服務和各系統間協調上，着眼全局不太注重某個應用本身架構，比如關注服務器負載，可靠性，伸縮，擴展，數據庫切分，緩存應用等方面的基礎架構設計。
當然，現實中的架構師往往會身兼數職，而不僅僅是構思架構本身。比如，大部分軟件架構師也會組織軟件團隊、進行一些相關研究，甚至擔負一些行政管理的工作，在此不再延伸贅述。
2.架構師應該關注點重點
1. 從功能的角度需要思考：
用戶真正想要什麼？這些是用戶想要的麼？是否準確的實現和解決了用戶的需求和痛點？系統的邊界在哪裏？確定系統幹什麼不幹什麼？流程是否合理？系統產品之間數據流轉過程合理？系統安全可靠，允許經過授權的用戶和系統能夠正常的訪問相應的數據和信息，禁止未授權的用戶訪問.......
2.從可靠性的角度需要思考：
系統是否成熟可靠，設計時是否考慮系統內部錯誤，導致軟件失效的各種異常流程和錯誤的兼容性處理；軟件出現故障，是否能夠快速修復，甚至自我修復；失效情況下的如何恢復並正常運行？
3.從易用性的角度需要思考：
設計的產品是否符合心理學和行爲學，是否能夠很方便快速的被操作者使用和理解，就像iPhone手機Home鍵設計，一兩歲的孩子只要探索一兩遍，便能夠很容易操作並使用，作爲架構師也需要從業務領域相關的背景知識中抽取和提練業務流程，並結合用戶的特點給產品設計提出指導性原則和積極的建議。
4.從效率性的角度需要思考：
需要關注用戶操作端到端的系統響應時間，實現這個目標，架構師從縱向分解和橫向分解，縱向分解是將整個系統分層，從而將整體系統分解成下一級的子系統與組件；橫向分解是在系統分解成不同的邏輯層或服務後，對邏輯層進行分塊，確定層與層之間的關係，從中選擇最優的一種方案。
並且關注系統前端到後臺、系統之間業務數據交互的時間及效率，如業務響應時間，吞吐率、TPS（每秒事務數）等業務指標；以及系統資源的利用率，CPU 內存 磁盤 IO 網絡帶寬、隊列、共享內存。
5.從軟件維護性的角度需要思考：
主要從運營的角度思考軟件架構如何設計，如何能夠快速分析定位問題；軟件產品出現的失效可以通過外部修改修復，同時又能防止意外修改導致程序失效，確保已修改軟件能被正確的運行的能力。
6.從軟件可移植性的角度需要思考：
軟件的可移植性就是需要考慮，軟件從一種環境遷移到另一種環境的能力，是否可以在不同的硬件服務器、操作系統或者中間件產品上不需要修改就能夠被部署和搭建；並且能夠很方便快速的被安裝的能力。
3.架構師能力要求
架構師到底有哪些能力要求呢？網上有張關於架構師能力要求調研報告，其中37%的人認爲架構師的設計能力最重要，技術實力重要度排在第二佔了24%，溝通能力則排在第三佔比14%，此次，我們詳細分析排在前三的能力。
1.設計能力－擅長整合分析
架構是過程，並非結果。架構是架構師洞察內在結構、原則、規律與邏輯的過程，架構師要做到清晰理解系統，以及簡潔描述，這是分析整合的能力。
一個架構師必須具備極強的分析能力，要做到根據產品宗旨和目標，分析清楚產品定位以及產品業務，再整合利用現有的技術領域，找出最佳方案，實現產品概念。
2.技術實力－實現產品規劃
能夠在業務需求清楚的前提下，能夠將一個完整的業務系統從功能模塊和系統架構的角度進行分解，從技術的角度給予技術選型提供建議，前端到底用瘦客戶端還是富客戶端呢？數據庫是用MySQL還是MSSQL又或是Oracle呢？等等，架構師還應該深入一線解決和攻克技術難點。
3.溝通能力－能夠橫向溝通
架構師參與項目開發全過程，包括確認需求、系統分解、架構設計、技術選型、制定技術規格說明、系統實現、集成測試和部署各階段，在這一系列過程中，架構師會與各部門溝通交流。
一個產品會有多部門合作，架構師在其中的溝通極爲重要，直接影響產品進度與質量。架構師不僅要與開發人員溝通，也要和項目經理、分析人員甚至用戶溝通，來實現產品的各種可能性。所以，對於架構師來講，不僅有技術方面的要求，還有能夠橫向溝通的要求。
從以上綜合來看，架構師是一個既需要掌控整體又需要洞悉局部瓶頸並依據具體的業務場景給出解決方案的團隊領導型人物。架構師不是一個人，他需要建立高效的體系，帶領團隊去攻城略地，在規定的時間內完成項目。
以上知識筆者希望從既往工作中，快速複製和遷移其能力的一些思考，並未經過真是檢驗。希望有相關經驗的同學一起思考並給予建議和指導。
特別說明：本文第三部分內容，部分內容來源於網絡