在設計系統技術架構的時候，我會思考，這個技術架構能給企業或者市場帶來什麼價值，技術架構能像其他產品那樣賣錢嗎？我也經常會聽到類似於“這個架構很牛X”，“這個架構很先進”以及“這個架構能抗萬級併發”這樣的評價，再回到市場角度想想，這個“牛X”或者“先進”有哪個老闆真正願意買單？“能頂住千萬級併發”是不是每個企業的核心需求？多年的工作經驗告訴我：絕地有，且不在少數。
多年下來吧，找上門的客戶很多都是十萬火急地想找一個牛X、先進和穩定的技術架構，有一些並不是什麼網際網路公司或科技企業，但他們的資訊化建設問題已經嚴重影響了企業的核心業務，甚至這個問題已經上升到了他們企業最頂層的緊急事務。原因並不是他們沒有技術團隊做支撐，而是因為他們使用了所謂“牛X且先進”的技術架構，而被迫讓“技術架構”成為企業當前的“核心需求”。
“我聽說微服務架構很先進，你們公司正好有這樣一個研發框架，而且還有千萬級使用者和上萬級併發量支撐的案例驗證過了，能否賣給我們”。我很能理解他們的困境，但曹老闆說過：“做人要真誠和善良”。所以，我很誠懇地表達了簡單地買套程式碼是沒有什麼效果的，甚至還有可能變本加厲，最終用不好，砸壞的可是我自己的招牌。
這些領導或企業管理者對微服務架構的渴望無非就是對提高企業競爭力利益最大化的渴望。處於這樣一個資訊化時代，就算企業沒有“網際網路”或“科技”字眼，但他們始終都離不開資訊化建設這個基石，因為資訊資料化的優勢太大了。所以，從市場角度看，一個好的技術架構真正能給企業帶來的核心價值是“增效降本”。再結合前面的問題，“牛X”和“先進”是不是等同於“增效降本”？這個問題留給大家去踐行思考了。有的企業聲稱自己使用了大型網際網路公司級別的技術架構，但到頭來成本卻越來越高。據我對他們的瞭解，原因很多，但最為突出和迫切的，還是他們缺少一個與之匹配的技術組織架構，這是他們沒能真正“牛X”起來的直接原因。
作為一個“增效將本”的企業內部組織，首先，最基本要確保的是給企業所帶來的價值必須大於自身組織的投入成本，這也應該是技術員工最基本的價值觀念。但能真正遇到具備這種價值觀的技術人員不多，他們更多地是埋頭對“牛X技術”的追求，忘記了技術的本質。其實，這個現象跟目前的行業狀態有關，那些什麼“青春飯”、“35歲危機論”等迫使他們必須在短時間內賺取足夠的金錢，而IT行業最能賺錢的手段就是跳槽，而跳槽最容易漲身價的就是保持自己擁有“牛X”的技術。所以他們心裡不會想太多如何幫助自己當前所在的這個企業能賺多少錢，更多是藉助在這個企業的短暫時光練練自己牛X的技術技能。所以很多應聘者都會問“你們公司用的是什麼技術”而不是問“你們是如何通過技術手段去幫助公司增效降本”。以上所描述的技術人員不限於技術高管，所以企業很難有一個穩健且可持續發展的技術架構以及組織規範。
仗著網際網路趨勢，技術組織很多時候都自以為是“大爺”級別的，但技術組織本身是一種成本投資，技術組織存在價值的公式很簡單：技術價值=為企業整體利益的增效-自身技術組織的成本。技術能增效，主要還是根據企業價值鏈結合業務架構和技術架構的搭配去提高企業自身的市場競爭力，所以現在很多企業會有業務架構師一說。而技術組織的成本控制不在於自己使用了多牛X的技術，還是那句老話：要發展，先自知，沒有最好，只有最合適，做人做企業亦是如此。
以自己所在公司為例，從2011年5月我還沒正式畢業就進入公司接手技術管理以來，一切都是從零開始。隨著移動網際網路的發展趨勢，迫使我們必須進行架構改造，從2014年開始我們進入“服務化V1.0”模式，也就是我們現在微服務架構的前身。這些技術發展史都能從我以前的文字中找到，但對於我們自身組織的描述得不多，但技術架構本身不會獨立存在，跟組織架構還是有很密切相關，所以，我覺得還是有必要介紹一下。這僅僅只是一個經驗分享，並不代表我們就是成功的榜樣或標準。
● 技術員工
從上圖的技術與組織架構對比可以知道，組織技術員工好比技術的物理伺服器，都是架構的基建，一個員工的品質好比伺服器的質量，並不是說有了上層對基礎資源的統一管理，淡化了每一個獨立個體的重要性就不代表不需要好的員工或伺服器了。當然，好的東西都貴，但價效比高的還是值得不斷去追求的。
● 技術部門
技術部門好比LaaS，是對所有獨立個體的統一管理和協調，最對資源效能最大化的手段。部門有企業級別的實踐方針和指南，結合企業的目標定製了一套最適合自己的組織與技術管理辦法，這些規章制度並非一成不變，是站在企業的角度跟隨市場不斷去完善和修正的。所以，組織並非一成不變，既然技術與架構是相互的，那麼技術架構的穩健、靈活、易擴充套件等特性應該同樣要應用於組織架構。
● 研發小組
研發小組跟PaaS一樣，是技術組織效能的“加速器”，增加了上層的業務或應用的靈活性和增加快速適應市場的能力。我們研發小組的貢獻主要集中在兩個層面。一方面是不斷完善和提高自己組織的內部效能，主要體現在我們當前自主研發的“統一工作臺”，這個統一工作臺主要是結合我們各種職能流程和軟體工具（如SVN，Docker等）打造的一個統一規範工作流平臺。另一方面是不斷通過業務驅動積累我們研發的業務產品（如我們“微服務應用中臺”的服務沉澱），為企業增效，提高市場競爭力。
● 職能小組
我們部門的人員架構是一個“矩陣型”架構，橫向為技術職能小組，縱向為以專案經理帶領的專案小組（下面會介紹）。按職能維度，整個部門劃分為專案經理組、需求組、UIUE組、前端組、後端組，測試組、實施維護組等職能小組。有點類似於微服務架構裡面的服務一樣，分工合作，獨立部署獨立執行。職能小組內部會根據規模而進一步細分小小組。這些小小組會隨企業發展而又有可能歸類為事業線小小組或業務領域小小組。組員到組長一層層向上按自己領域範圍的技術規範和專案質量負責。
● 專案小組
專案小組是我們“矩陣型”架構的縱向劃分維度，由各職能小組成員組成，由專案經理以業務為統籌和主導。在縱向維度，職能會存在一個“專案職能負責人”，確保自己的職能價值在專案中最大化體現。哪怕專案再小，職能只需分配一個人或半個人，而那個人就預設充當了這個“專案職能負責人”的角色。就像微服務架構一樣，有了我們“微服務應用中臺”的支撐，頂層的應用場景可以更加靈活、高效、快速地實現。我們的專案小組在職能小組明確分工的基礎上，同樣也能靈活、高效、快速元件出打造頂層應用場景的專案團隊。
看到這裡，可能有人會有疑問，我們只是一個小企業，那有這麼多人。其實問這個問題的人，等同於問“微服務是否只能適用於大型系統”的問題一樣。我在《小型系統如何“微服務”開發》中也做過介紹，微服務是一種方法，適用於任何應用和專案，跟專案規模沒有關係，哪怕我目前只有一臺物理伺服器，或者我只有一個技術人員，都完全能按照我們以上的“技術與組織結構”方式去執行和操作。要明確一點的是：方法跟規模沒有關係。當今在技術圈比較流行的一個詞叫做“DEVOPS”，其實就是一種“降本”手段。我們的組織架構是跟人數沒有關係的，更多是我們的管理辦法，因為做事情需要頂層方法去引導我們更好地執行。就算我們技術組織只有我一個人，也不妨礙我屬於研發人員，同時又相容前端、後端、測試、實施、維護的職能，以及作為專案經理主導自己去開發專案。
方法還只是屬於“虛幻”層面的東西，具體還是要考自己的實踐去驗證和發展，就算我說得多牛X，如果不親自去體會、感受和總結，我們持續實踐了千萬級使用者數應用平臺近10年的時間，以及我們所開發的應用系統足足比別人降低數倍乃至數十倍的時間和金錢成本，都不關你們的事，這是我們每個同事通過汗水和努力所換來的成效。但我們的不足還很多，沒事，時間還很漫長，一步步主動去學習、改變和完善就是了。