背景
週末參加topgeek組織的2016年度中國架構師大會，日程之一是圓桌會議：“如何成為頂級架構師”。有意思的是，四位嘉賓一致和不寫程式碼的“PPT架構師”撇清了關係，均表示至今還在擼程式碼。不出意外，臺下的架構師們報以經久不息的掌聲。
怎麼定位軟體架構師？
角色是無法自賦其意義的，就好比我偶爾喝高了，斗膽號稱一家之主，老婆大人一定會招呼我一個巴掌:-)。角色存在的價值必須從他和環境的相互關係中去尋找。我們試著看看一個典型的軟體開發組織中不同干係人對架構師的期望。
客戶
不要奇怪，客戶也會關心架構，比如兄弟所在的行業，你不把自己的技術方案和演進路線說清楚，客戶是不敢把他上億的資金還有他未來10數年的基礎設施演進押在你身上的。
產品經理
期望方案方案價廉物美，關鍵還要能頻繁修改，能迅速上線。
CTO
CTO是老闆在技術方面的代理人，他既關心公司的當前利益也關心長期利益。他的期望是架構師的方案既能滿足當前需求，也匹配公司的長期技術演進路線。傳說CTO還有一個變態的需求–你得在電梯開門之前把你的思路講清楚。
其他架構師
你的架構至少得通過其他架構師的評審。你得證明你的架構是“好”的。
專案經理
技術風險是否可控，架構是否能在期望的時間內被團隊落實，系統是否被有效分解為子系統以便安排團隊齊頭並進。
開發團隊
開發團隊最關心的是自己負責的子系統的職責是否被清晰定義。這樣他們可以安排資源，估算進度，安心擼程式碼。此外，不同的團隊領導可能會對開發任務在不同領域（團隊）的對映有不同想法，這個模組應該是隔壁領域的自留地？開發團隊中有一些能人，他們可能會對你的架構評頭論足；開發團隊中還有一些初級員工，無論你覺得你的架構闡述得多麼清晰，他們總是一臉茫然。
以上這些職責都假設架構師技術功底紮實，但真正的挑戰其實在於溝通技能。顯然，不要說擼程式碼，就算能整出一套漂亮的PPT也未必搞得定樓上各路諸侯：
架構是份新工作
從區域性到全域性
既然貴公司設定了架構師這個職位，說明貴老闆已經意識到系統的規模已經超過了單個能人能搞定的程度了。你現在的工作內容絕不會是以前的工作減去編碼。橫向看，你要搞清楚系統所涉及的不同方面，你以前可能是後臺的高手，現在可能要涉及到前端，以前可能是支付領域的高手，現在可能還要看看物流；縱向看，你得對這個系統接下來的發展有點想法，你的架構製品首先要滿足當前需求，這是沒錯的，但是人們期望它不要和可以看見的未來衝突……
你之前是個C#高手，或許你意識到用這個技術的兄弟公司越來越少了，少到HR都不好找人了，而且你聽說有個叫阿里的公司開放了很多用Java寫的中介軟體，似乎你們恰好也用得上，那下一步是不是要把平臺切換到java呢？對了，老大昨天很開心的告訴你，用java的競爭對手最近正在為核心員工被淘寶挖走發愁哪！看來這個決定似乎不是那麼好做了。
從程式碼到PPT(文件)
是的，我猜中了，你痛恨寫文件，而且你還知道有個什麼宣言支援你說凡是不是程式碼的東西都是浪費。如果我又沒猜錯的話，你在這家公司的成長路線是這樣的：
成長的煩惱
小兵變牛人
一開始，你默默無聞，埋頭coding，首先是公正的電腦上帝發現，你的程式從來不出錯，後來測試組妹妹也發現，bug都是其他人的（再後來，即便是你的bug她也不敢相信是你了），一直到這個時候，你的程式碼主要是被機器閱讀的，機器好啊，它老人家只管對錯不挑美醜，Enter鍵一敲，編譯，單元測試，部署，自動測試，OK，一把全過，多爽啊！你一定很回味這個感覺對不對？接下來，組長大哥也發現你是一個人才，開始分配一些體量大一點的工作給你了。
秀才遇到兵
為了控制程式碼質量，你們開始做程式碼評審了，有些同事（或許就是你）覺得程式碼能工作，跑得快還不夠，還要寫的好，媽蛋！什麼叫寫的好寫的壞啊，總之評審會是亂成一鍋粥，每個人都振振有詞，每個人都說服不了別人！是的，現在沒有電腦這個說一不二的裁判了，上帝已死！
你不得不思考程式碼好壞的客觀標準了，你腦補了一堆實現模式，設計模式，架構模式，還有什麼壞味道之類的，停一停，憑什麼這些傢伙講的就是對的？於是你進一步鑽到故紙堆裡，發現這些真理後面的真理在上個世紀70年代就整理好了，而且還要言不煩。於是你信心滿滿，下次程式碼評審會侃侃而談，不對！那些在你看來就像“兩點之間直線最短”這麼鐵的設計準則，為什麼寫漿糊程式碼的兄弟就是死活聽不進去！
這下你知道生活不容易了吧，自己搞懂是一回事，把真理傳播給別人是另一回事，否則的話，小學班上的王二小也不會老是數學考不及格了。沒錯，我相信你從此以後真的是把程式碼寫好了，但是你並沒有說服其他人。
架構編檔
現在你是架構師了，什麼，拿程式碼說話？把開發團隊撤了，就保留你一個人行嗎？一開始，你的文件整得太細了，首先你自己覺得這樣寫下去還不如直接上程式碼來得爽快，其次軟體團隊覺得你規定得太細了，有些地方和實際有出入，沒法照著你寫的做，再次，專案經理在催你了，因為還有其他幾個團隊的兄弟等著你的輸入好開張。慢慢的，專案進展到整合階段了，你發現模組之間的配合才是真正的問題，於是你漸漸不操心區域性模組的問題了。
工作中總是有一些讓人煩心的事，有時候，你躊躇於究竟該用圓角矩形還是直角矩形來表示一個模組；有時候，你把各種箭頭的形狀都嘗試完了，還是沒法把心中的那個關係痛快的表達出來；更要命的是，你絞盡腦汁做出來的PPT,有人覺得他就是看不懂，或者有個點子你明明畫在圖上了，可軟體團隊的兄弟跟你說他壓根就不知道你是這個意思，有時候你明明是這個意思，人家讀者非要感覺是那個意思。
是的，我沒猜錯，UML, 你又找到法寶了。可是問題還是不斷出現，首先是你自己也總是覺得這東西的表達能力好像也有那麼一點侷限，雖然不再為圓角矩形還是直角矩形糾結了，可是什麼關係都用一條線來表示是不是也太簡陋了，要知道之前你可以直接用大框套小框來表達包含、用上下關係來表達堆疊，多麼形象啊，現在都沒啦。
溝通為王
我知道聰明的你最終搞定了架構編檔，你能夠得心應手的表達自己的想法了，更加重要的是，別人也能透過文件看懂你的想法了。而且你還是個技術牛人，你的架構很美！
但是問題來了，你也知道，軟體的質量屬性有時候是互相沖突的，有時候為了效率你不得不破壞封裝，有時候為了可靠，你不得不引入冗餘，犧牲簡單性….., 問題來了，你覺得簡單性重要，他偏偏覺得效率更加重要，你覺得讓當前特性儘快上線迫在眉睫，他覺得把結構整理清楚刻不容緩。
架構組中有個把老頑固，他們死活就覺得你的設計不那麼美，雖然私下裡你覺得是他們知識結構老化導致的，可是領導說，沒獲得大家的一致同意，你的架構就是不能通過，領導還偷偷的告訴你，其實他也同意你的設計；還有，有時你覺得某個現成的中介軟體完全能滿足專案的需求，但是會導致某個正在造輪子的團隊關門……
好悲摧！好不容易把PPT擼順了，到頭來發現還要去擼心……
臺上的嘉賓，很可能是程式碼、PPT、別人的人心、自己的心都擼過一遍了，所以他們有閒暇去擼擼程式碼，臺下的你，極有可能剛剛把程式碼擼順，你應該知道有沒有功夫去享受這份奢侈。