每一個程式設計師都有一個架構夢。
上面其實本質上是一句富有事實哲理的廢話，要不然也不會有這麼多人關注你的公眾號。這些年隨著“企業數字化”轉型的口號，一大批企業奔跑在轉型的路上，希望領先一步對手將企業IT部門從單純的成本中心轉變為業務驅動者，而這個過程中，企業的架構師起著舉足輕重的作用。架構師的工作在很多擼碼的開發者眼中是很一項很神聖的工作，而且富有挑戰性。
但是事物都有兩面性，很多管理者和技術人員都認為架構師的薪酬不符合實際，有很多架構師確實只會用PPT和大幅海報來應付了事，而且會依仗著在公司地位把自己的一些想法強加給公司其他同事，有的架構師甚至會追求一些無關緊要的概念，在高層和底層灌輸一些錯誤的思想，從而導致做出一些不可逆轉的糟糕決策，使公司陷入危險逆境。
很多時候，公司給予架構師這個角色太多的責任，管理者希望他們能在突發效能問題時能快速解決問題，還能推動企業快速轉型，甚至能幫助企業文化的快速建立，作為一個架構師是不是要抗下這些職責呢？
我不是專案經理
架構師的日常工作經常會面臨並行處理多個不同維度的問題，這些問題可能是不同的主題，甚至在做決策的時候也需要考慮人員的分配，專案時間表的排期，需要用的核心技術以及元件等。有很多高層領導喜歡直接在架構師這裡獲取專案的詳細資訊以及技術方案，雖然架構師角色涉及這些資訊並且很瞭解這些資訊，但是這並不是架構師的職責所在，甚至很多情況下令架構師處於專案經理的尷尬角色。
我不是開發人員
我想很多人看過那篇文章：作為架構師該不該寫程式碼？很多架構師是出身於開發人員，這也難怪會出現這樣的疑問。但是，架構師其實和資深開發是兩條不同的職業路線，我認為兩者沒有高低之分。出色的開發人員需要很深的開發功力，需要最終交付出可執行的軟體。而架構師則需要更廣闊的知識面，更好的組織戰略思想，更好的溝通能力。在一個產品的開發流水線上，架構師可能會負責一部分核心程式碼的編寫，但是最主要的工作還是保證這條流水線的正常運轉。
我不是救火員
由於架構師這個角色在公司的地位，很多管理者認為架構師要隨時隨地的能分析並解決任何突發的問題，不瞞各位，這種現象在很多大廠依然存在，包括我司（雖然只是一個四線小廠）。如果一個架構師每天都忙著“救火”這種工作，根本沒有時間去做真正的架構工作，真正的架構設計需要思考，是不可能在短短時間內完成的。但是架構師必須接受出現的產品問題，因為這些問題的產生有可能和架構有著直接關係，在很大程度上能反應架構的缺陷或者問題。
寫在最後
架構師作為企業中很重要的一環，在很多重大技術問題中都作為決策者而存在。很難用程式碼的多少或者質量來衡量一個架構師的好壞，如果一個系統在正常執行5年後依然能良好執行並且可以承受一定的變更能力，說明這個系統的架構師的工作是很出色的。如果非要給架構師定義一個KPI標準的話，以下這些工作也許能成為一個參考
-
定義IT戰略。小到一個系統的元件列表可行性的確定，大到公司技術的發展方向，乃至未來10年公司技術的預測與大膽嘗試。這些技術戰略都需要架構師根據自身經驗來制定。
-
落實對IT藍圖的管控，以實現協調一致，降低複雜度，保證公司所有系統有條不紊的正常工作，架構師的工作之一就是要把複雜度降低，化繁為簡，這需要架構師很強的抽象能力。
-
關注專案的實際落地情況，並根據專案實施中反饋的問題進行戰略的適當調整。一個合格的架構師從來不會忽略來自實際專案中的問題反饋。
架構師一定要避免和消除那些系統設計中不可逆轉的錯誤決策
來源參考：架構師應該知道的37件事