演化：這五年裡，我們對架構師職責的思考與定位
最近兩年，隨著網際網路紅利的消失，對於人才需求似乎已失去往年那種脣槍舌劍的感覺，但我卻發現，無論在社交平臺，還是技術大會，又有人對 “架構師是用來幹嘛的？” 這樣的偽命題開始津津樂道，緣由也許是無事生非？還是抒發感情？又有誰在乎呢。
相信任何一家含有技術屬性的企業，或多或少都會有一名（或者多名）扮演架構師身份的人存在，在許多人眼裡他們是站在技術金字塔最頂端的神祕人物，具有快速切入，舉一反三，一句頂一萬句的特殊技能，而且邏輯思維能力很強，思路清晰，有洞察力，善於抓重點，但也有人說他們的強項只是打醬油、和稀泥、背黑鍋、拉仇恨……
很顯然，評價之所以產生如此大的差異，拋去調侃的成分，我覺得還是由於每家企業對架構師職責的定位不同，而且這種不同，會隨著技術發展與業務規模的變化，甚至組織結構的調整產生變化。
在進入正題之前，我們先來看看維基百科是如何對 “架構師” 進行分類的：
-
軟體架構師
-
資訊架構師
-
網站架構師
-
業務架構師
-
中介軟體架構師
-
基礎架構師
與 “官方分類” 相比，好買技術團隊中的架構師崗位，不但起源較晚（沒記錯的話應該是2013年），而且剛開始定位模糊、職責不清，如把這五年的演進進行梳理的話，可簡要分為三個階段：
| 第一階段：技術救火員
2013年，技術團隊剛從十餘人擴充套件到幾十號人，應用系統也隨著業務功能的迭代而增加到三個。
在從 0 到 1 的技術創業階段，無論開發狗還是業務貓，似乎都更關注功能性需求，往往一個簡單粗暴的 MVC 專案就可以搞定一切，但隨業務量逐漸增大，使用者需求逐漸多樣化，非功能性突發情況變得越來越多，而此時也有越來越多的人開始意識到，在技術上遇到難以攻克的問題，如果招倆牛X的架構師在身旁，似乎解決系統的疑難雜症都是小菜一碟。
這一階段的架構師，無需具備多偉大的巨集觀設計能力，只要開發小夥伴遭遇技術難題之時，能像美國隊長一樣挺身而出，施展拳腳，攻克技術細節便可。
| 第二階段：專案技術評審
2015年，技術團隊又從幾十號人發展到上百號人，應用系統伴隨著 “持續汙染” 擴充套件到了近百個。
眾所周知，應用越多，人也就越多，然後功能需求的延期現象越來越嚴重，直到無法再承受的那天一拍腦門做出決定。
A君提出：“咱們成立PMO（專案管理部）吧，按瀑布迭代的方式推進，這樣對專案的控制力會強一些”。
B君質疑：“好是好，但當前引起延期的主要原因都集中在應用架構與技術選型上，使用PM形態應該也無法解決吧？”
A君解答：“那就讓架構師參與到每個專案中，對每個專案進行技術評審，並逐漸將技術公共服務抽象，這樣一來，短期/長期的問題、隱患不都迎刃而解了嗎？”
B君同意：“的確是個好方法，開幹吧！”
看似完美無缺的套路，可實施起來又如何呢？
由於第一階段的發酵，架構師自身並沒有深入參與應用系統的業務環節（當時這個環節是由各應用系統研發Leader管轄的），在業務上的沉澱不足，導致對於軟體工程的理解、目標沒有清晰的認識。
在做架構設計與技術選型時，非常容易泛泛而談，甚至與應用系統研發Leader產生衝突，衝突的原因也無非是覺得太過高屋建瓴，缺乏對具體實現的理解和把握。許多架構設計方案，僅僅停留在PPT上，具體的落實完全依靠一線開發人員。
通過一年的磨合，雖說演化出類似快取系統、排程中心及統一配置服務等多項中介軟體雛形，但最終由於組織結構的變更，從2017年起，架構師不再參與專案技術評審，此項工作由應用系統研發Leader全權負責。
| 第三階段：中介軟體產品化
2017年，技術團隊到達了200人的規模，組織結構也被拆分成了網際網路化的FeatureTeam，應用系統也打著 “拆” 字的旗號發展到了成百上千的程度。
隨著業務支撐場景的複雜度加大，外加FeatureTeam形成後需避免重複性建設，在推動一些全域性橫向技術工作時，需要有人與應用研發一起突破架構上的各項難題，通過前兩階段的磨練後，架構師是最為合適的人選。
截止到這個階段，也有一部分架構師轉型成為了FeatureTeam團隊的Leader，還有一部分架構師則專職負責中介軟體平臺的建設，而每個中介軟體服務則被劃分為不同的產品線，再挑選出幾位不但精於技術領域，還能有跨團隊、部門溝通，推進事情能力的架構師擔當負責人，對技術落地的進度、風險進行把控。
其實，這樣對架構師的職業發展路線也不是壞事，只不過從原先的 ‘身兼數職’ 變為 ‘垂直一職’，對於 "本身酷愛技術" 的他們來說也是一種對於能力的鍛鍊。
- 感慨 -
演化，有時候就是選了一些完全出人意表的道路，有時只有當回望的那一剎那，你才能分辨好與壞，才能感受到這其中的酸甜苦辣……
你家架構師的演進歷程是什麼樣的？快到評論區分享下吧。