技術架構來源于人員組織架構
過去兩年做了不少大型的中台項目，什麼是中台？這篇文章就不多說了，自行百度一下，總而言之最後我得出了一個結論——企業什麼樣的人員組織架構就會什麼樣的系統技術架構。我們先以下一幅圖：
-
第一階段：小型企業
這個階段就是企業的初創階段。公司就幾個員工，甚至就老闆一個員工，開發是他，銷售是他，人事是他，搬運也是他。這個時候需要配置系統就是典型的單機應用，特點：簡單快速、易于開發、易于部署；重點是---省錢！
-
第二階段：中型企業
這個階段就是老闆熬過了生存階段，開始有些小錢可以招聘員工，但這時沒算富裕，會在淘寶買些便宜的系統支援一下業務，自己的系統伺服器擴容一下，從2核買到了4核
-
第三階段：大型企業
這個階段老闆正式暴富了或者拿到融資了，公司人員越來越多，有了部門的概念了，每個部門也需要管理，業務也需要更多功能子產品來支援，這時候我們系統就需要叢集來支援更多的通路量和業務量了，如下圖：
-
第四階段：
這個階段我就不多說了，整個公司至少拿到B輪或者已經有三位數以上的員工了，也猜到我會說用微服務或者更高大上中台的架構。
前面說的都是些大概，我直接說我的案例吧，我在上一家公司（乙方）時候已經做了不少中台項目，自以為對這種架構已經有些了解了，直到遇到到了這家企業（甲方）實際做需求的時候才遇到這些坑。
真實案例
業務背景：
我們這企業主要做移動共享充電寶業務，和國内幾大x電不一樣，我們是做國際化，需求方在日本、中國台灣、泰國、中國香港地區，是以看起來簡單的租借邏輯變得異常複雜，因為僅僅是第三方支付公司就十幾家，支付方式積分、優惠卷也十幾種。而且這也是一個國際化團隊，因為日本的需求非常特殊，是以他們有自己的開發，由于上司層原因而我們的核心代碼又不能給日本開放，是以每次上線都要有專人去拿日本方的代碼合并到我們master分支裡面去。
犯下的錯誤：
- 為了做中台，直接把負責每個地區的核心開發抽取出來做中台
- 在沒有調理好開發的組織架構前，直接安排開發任務
就是這兩個錯誤，導緻我們的業務線在接下來一個月直接癱瘓，泰國、日本需求線全面告急；一個跟了我很長時間的開發兄弟直接跟我提離職；bug數量直線上升；産品總監跑來跟說，再這樣下去，産品團隊就不玩了。
但問題又來了，中台架構如果不這樣做，讓不熟悉業務的人去做重構我完全不放心，業務層給的壓力特别大，不然現有架構支援不了幾大需求方的并發。
後面我發現是我方法論錯誤了，我沒有太多甲方的經驗，那我應該怎麼做呢？後來，我把業務拆了出來進行了分析!
經過讨論和調研，每次新需求都離不開主要幾大的業務子產品開發：
- 支付對接業務 占比30%
- 機櫃業務 占比20%
- 營銷活動 占比20%
- 代理合作商 占比10%
-
日常報表 占比20%
于是我對組織架構做了微調
不知道有沒有發現我把組織架構從業務線拆出來以後，我的中台架構，自然就出來了，過程中我沒有重構過任何代碼，隻是慢慢把業務從業務線剝離出來，增加了一個接口層，而且幾乎沒有增加過多的代價和成本，這就是我的結論，改變技術架構首先解決組織架構。
歡迎大家掃碼進群領取物聯網最新資料以及擷取一手直播資訊