編輯導語：做產品之前必不可少的步驟就是架設產品的系統架構，產品在運行過程中也會持續有不同程度的需求更新，所以前期搭建好架構是非常必要的；本文作者分享了關於產品系統架構的搭建，我們一起來了解一下。
架構，簡單來理解，就是架設產品的結構。
架構，離不開4個關鍵字：效率、適用性、穩定性、可擴展性。
- 效率：好的架構提升迭代效率；
- 適用性：好的架構可以在小修小補之下適用各個業務需求；
- 穩定性：系統是高可用的；
- 可擴展性：無需改動底層；
B 端產品需要解決企業不斷髮展過程中遇到的各種問題，所以隨着新的商業環境、新的業態、新的模式，必然伴隨着催生出新的需求。
每家企業發展的方向不同、策略不同、組織不同，都會導致需求有很多變種，在這種情況下，如何能夠通過一款產品滿足各種數以萬計的企業，就變得異常有挑戰性。
沒有一個好的產品架構，是無法做到這件事的。
產品架構不好，帶來的很多問題，這裏不再贅述，主要包括：一碰到新需求就要改底層；改動牽一髮而動全身；一碰到新需求就要大改。
我們往往會看到那種結構圖，分層分區塊，不同層做不同的事，不同塊承擔不同的角色和職能。
我們要明白所有的架構，最終都為了提效，沒能提效的都不是好的架構。
01 產品架構思維這裏引入 2 個思維：
階段一：線性化思維
就是説比如一個用户進入一個電商網站，他找到一個商品，然後下單，支付，然後商家發貨，用户確認收貨，交易完成。
如果我們把這些環節都做到一個線性流裏，是不是發現這個產品是單層的，所有功能都有序的雜糅其中。
這樣一個產品、一套代碼，一旦涉及其中一個環節的改動，就會動整個產品、整套代碼。
所以開始有了模塊的拆分，以及前後端分離。
模塊的拆分，能夠很好的劃分邊界，即把相同目標的一些場景功能集成在一起，把不同定位的場景功能排除在外。
那麼後面假如只針對A模塊進行業務迭代，毫無疑問降低了對整個產品的影響，且更加容易和高效。
模塊作為業務層橫向的拆分，將線性化的產品變成了離散型。
毫無疑問，線性一定比離散型更快，更高效，但是隨着業務的訴求日益增長，任何的快都要建立在滿足需求的前提下，否則效率無從談起。
階段二：模塊化思維
模塊化到底是怎麼做的呢？
舉個例子，從產品角度通俗易懂的講，比如商品，那麼商品中所有的底層數據、商品相關的各種能力（比如創建商品、商品類目管理、商品上下架管理等等）都會被囊括在商品模塊（中心）中。模塊對外就是提供各種商品相關的接口能力。
模塊化還有個好處，就是降低了產品開發的邊際成本，同樣的商品創建，按照線性開發我肯定還要再做一遍；但是如果集成到一個模塊中，我只需要讓商品模塊可以支撐起他業務的商品創建，做一些輕度擴展，即可滿足。
模塊化按照顆粒度還可以進行拆分，比如商品模塊裏面，還可以拆分商品基礎信息模塊、商品銷售信息模塊、商品活動信息模塊等等。
這些都視業務發展的訴求而定，比如需要針對不同類型的活動，制定不同的商品信息策略，而且這類的業務需求又多又高頻，那麼是有必要抽出這個模塊進行單獨迭代的。
模塊化有一點比較負責的就是定邊界，哪些該放在業務側，哪些該放在模塊服務側。
我的原則是：高度關聯且具備一定通用性的放在模塊服務側，低關聯且個性化的功能放在業務開發側。
02 什麼時候需要建立中台上面講的是單個業務線的模塊化，但是隨着企業發展，多條業務線並行其實是很正常的，這個時候，每個業務線都需要用到商品，比如一家公司既要發展電商業務，也要發展農產品業務，都會涉及到商品能力的搭建。
理論上來説，如果能用一套商品模塊支持 2 個業務線的商品需求，是不是能讓降低至少一半的開發成本？
那麼問題來了，假如用一套商品模塊來支持2個業務的商品需求，會帶來什麼樣的問題呢？
比如電商商品是按照「件」來計算數量的，農產品商品是按照 kg/g 等重量來計算數量的，也就是説商品模塊需要支持 kg、g、件等各種計量單位，這還不夠，涉及到退貨、出入庫管理、物流配送費等，都需要做額外的方案兼容。
最後整個商品模塊會變得很重，任何不同業務的商品需求都會被迭代到這個商品模塊中，成了一個商品中心。
如果同時有 4，5 條線在跑，且他們對商品的需求又各有差異，那麼商品中心就會變的很重，這種【重】甚至會反過來影響各個業務線的商品功能，使其變得很難用。
隨着越來越【重】，任何一條業務線的商品需求的變更、新增，都會帶來成幾倍的開發難度和工作量，因為任何一次變更、新增都要基於之前【厚重】的商品模塊的產品邏輯來考慮。
這個時候中台的概念應運而生，中台某種意義上來講，和開放平台非常相似，就是對外提供底層能力。
我們換個思路，假如，每個業務都能自己建立自己的商品中心，不用受其他業務線的商品功能的影響，是不是會更加舒服呢？
但是像前面説的，從 0 到 1 自己再建個商品中心太麻煩了，那能不能複用一些已有的能力呢？但是又可以拋棄掉一些不需要的功能。
這個時候我們就抽離出技術中台這一層概念。
03 中台要做什麼？技術中台就是對各個商品中心進行能力的抽象，為各業務線提供底層的商品能力。
而各業務線就是基於這些基礎能力，去搭建自己的商品中心，做更上層的商品相關的產品功能。
這樣每個業務的商品中心都只服務於自己，更加完美的契合業務需求，使用也更高效，同時基於中台能力的商品中心搭建起來也更加便捷和迅速。
所以對於中台來説，如何避免弱抽象，又不過度抽象，就變得非常有難度了。
弱抽象，就意味着有很多業務的東西夾雜其中，每次迭代都可能涉及到中台能力和接口的改動。
過度抽象，就會導致中台體現不出價值，業務開發工作依然繁重，甚至因為新增對接中台而加大工作量。
中台進階：
那麼是否這樣就是一個最終形態了？並不是。
假如中台對外提供的是最基礎的能力，那麼對業務來説，他需要花費很多時間通過這些基礎能力接口去做上層的業務拼裝，並引入基礎能力之外的業務邏輯，而這些業務邏輯可以由中台提供，也可以由業務自己來實現。
那麼考慮到讓業務效率最大化，最好的方式是什麼呢？提供基礎能力，其實是相對簡單的，工作量的大頭其實是業務。
那麼假如中台能夠以一種通用性的方式，幫助業務完成一部分業務需求，何樂而不為呢？
很多書中都在告訴大家，中台就只做抽象，只提供基礎能力，雖然前提是對的，但是忽略了很重要的一點，中台的第一目的就是幫助業務減負，最大化業務效率。
如果做不到這點，中台再強調抽象，再強調低耦合，都對企業的發展沒有太大幫助。
所以換個思路來講，比如業務中，做營銷活動的時候，不同類型的營銷活動對用户參與門檻都有不同的限制，類似這樣的限制規則其實非常多，10 個活動都要用到這樣的限制規則，且這些規則離不開類似（是否新用户、是否用户等級大於 XX、是否活躍用户等等），既然如此，為何不為業務去提供一套整合的規則池，並提供一套門檻校驗能力，進一步幫助業務減負？
這樣的例子有很多。可以説這樣的規則池也是一種抽象，但其實更像是枚舉，因為每一個規則都可能完全不同，需要一個個建立起來。
04 技術中台的坑中台化的能力，幫助業務減負的基礎上，進一步收攏了數據，和模塊化的統一管理，從邏輯上來講，一定能夠幫助企業大幅提升效率。
但是真正執行中，往往效果沒有達到預期，一般主要由以下幾個原因導致：
1）業務理解深度不夠
沒有對業務進行深度調研，導致設計的中台，業務不可用，或者難用，滿足不了需求，這必然導致中台能力應用的推進難度增加，有些業務甚至脱離中台自建底層能力。
2）技術對接溝通不充分
在對接過程中，沒有做好充分的技術對接溝通，導致業務開發覺得中台提供的少，中台覺得業務開發不懂中台，沒有形成合作共識。
3）中台能力過於散裝
上游業務組裝依然複雜、需要耗費大量精力，體現不出效率的提升。
未完，實戰內容待續。
#專欄作家#司馬特小分隊，公眾號：司馬特小分隊，人人都是產品經理專欄作家。8年+互聯網資深產品經驗，多年B端產品管理經驗。具有多個從0到1的大型B端產品的孵化、重構、迭代經驗；主要教授產業互聯網產品相關的硬核知識點。
本文原創發佈於人人都是產品經理，未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議。