架構(gòu)師的兩種類型
第一種是可以將業(yè)務(wù)實現(xiàn)的人，他可能需要整合公司不同部門的資源盲再、解決不同技術(shù)模塊整合西设、解決不同版本之間的兼容性、解決各個模塊的技術(shù)選型等答朋，解決任務(wù)的分解及分配贷揽，解決進度上出現(xiàn)的問題。當上面所有這些問題都完成后绿映，架構(gòu)師順利幫助公司完成了項目目標。
第二種是在第一種的基礎(chǔ)上，利用技術(shù)的力量叉弦，改進了一個領(lǐng)域的效率或提升了生產(chǎn)力丐一。比如一個在現(xiàn)有技術(shù)基礎(chǔ)上提升20%效率的視頻解碼模塊、或者類似美劇硅谷中的淹冰，研發(fā)出一套壓縮比很大且保持高質(zhì)量信息的壓縮算法库车。目前的大部分互聯(lián)網(wǎng)創(chuàng)新在某種程度也是利用技術(shù)變革的力量，比如電子商務(wù)及在線教育等行業(yè)樱拴。
很多人所說的架構(gòu)師的設(shè)計能力柠衍，大多也可以歸納到第一種情況。很多所謂的架構(gòu)設(shè)計晶乔，就是拿著多年一成不變的分層模式往業(yè)務(wù)上套珍坊，把業(yè)務(wù)按照功能規(guī)劃成軟件模塊填寫到架構(gòu)圖，并且把上下游的調(diào)用串起來正罢。這種設(shè)計的大多時候是起給客戶或者領(lǐng)導(dǎo)展示的作用阵漏。程序員代碼的整體構(gòu)思，大多可以通過白板上或者白紙以及程序員直接的溝通很敏捷的完成翻具，大多不需要一個專職畫圖紙的架構(gòu)師來指導(dǎo)履怯。
第一種架構(gòu)師是可以不寫代碼的，因為他大部分所做的事情是跟人打交道裆泳、分配任務(wù)以及解決開發(fā)過程中各種進度問題叹洲。因此很多技術(shù)負責(zé)人面試時候看重協(xié)調(diào)能力等非真正的技術(shù)能力。而那些服務(wù)甲方項目型的公司工禾，更是特別看重人際關(guān)系运提、溝通能力、展示能力等跟客戶打交道的能力帜篇。另外一些軟件版本歷史包袱重的企業(yè)糙捺，則看重架構(gòu)師的打補丁能力。由于功能型及偏執(zhí)型型的團隊偏多笙隙，因此在很大程度上造成了架構(gòu)師的能力標準的偏離洪灯，在一些討論的場合，過份看重項目執(zhí)行中的個別技巧型能力竟痰，比如項目管理签钩、人際關(guān)系等能力常常還占據(jù)了主流的聲音。
但這類架構(gòu)師只能勉強稱為“技術(shù)架構(gòu)師”坏快，因為大部分時候铅檩，他做的事情是填格子，而無法做到利用技術(shù)的力量莽鸿，把一個格子放大到10個格子及更多昧旨。在另外一方面拾给，這些不寫代碼進而慢慢喪失代碼能力的“架構(gòu)師”，也不太可能利用技術(shù)的力量去做發(fā)揮技術(shù)杠桿的事情兔沃。當然技術(shù)架構(gòu)師也可以驅(qū)動工程師去完成一個技術(shù)型的大項目蒋得，大型的項目也需要合理的組織，但并不意味不寫代碼的人就比寫代碼的人做得更好乒疏。而那些對技術(shù)體系有深入了解及一線體驗的架構(gòu)師额衙，比那些只跟人員管理打交道的人，更有機會利用技術(shù)的力量促進變革怕吴。
因此如果希望一個架構(gòu)師有令人滿意的技術(shù)驅(qū)動能力窍侧，他應(yīng)該具備代碼能力，對技術(shù)有直接的了解及體驗转绷，進而能夠精通如何利用技術(shù)來改變未來生產(chǎn)力伟件。
