碧居士>即時>正文

中台到底是個什麼鬼?

2019-08-09 20:20:24 産品中國 John 分享

說起中台,大家很容易想到阿裡在16年提出的“大中台小前台”戰略,其實John現在也在思考搭建數據中台的想法,所以現在結合自己的思考來寫寫這篇文章。

中台價值就是——一切以快速響應需求為依歸。

一、中台是怎樣誕生的呢?

其實中台是想象出來的概念。中台和産品經理職位一樣,中台并不是一開始就有的,而是基于“前台+後台”的架構發展演變的,先說下前台和後台。

前台:前台是系統的前端平台,是直接與終端用戶進行交互的應用層。拿電商平台來舉例,我們日常使用的app、H5端、pc端以及小程序都屬于電商的前台系統。

後台:後台是指系統的後端平台,終端用戶是感知不到他的存在的。後台的價值是存儲和計算企業的核心數據。例如供應鍊管理系統存儲商品及庫存數據、客戶管理系統存儲用戶信息。

産品經理都知道,用戶的需求是瞬息萬變的,用戶需求的變化決定了前台系統需要快速疊代響應用戶需求,而前端的變化需要後端的變化來支撐,因此這就對後台的快速應變産生了要求。而後台設立之初核心目的并不是服務于前台,而是提升後端數據的安全及系統的管理效率。

舉例來講:随着業務的擴大後端存儲大量的合同、商品、訂單及用戶等私密數據,因為安全性及緣故,這些數據無法供前台拿過來直接用,同樣也無法快速的改造系統來響應前台的變化。因此,出現了“前台為了用戶需求,期望系統不斷的快速疊代”與“後台為了數據安全與系統穩定,期望系統趨于穩定”的矛盾局面。

在這一矛盾的局面下,為了滿足前台的快速疊代需求和後台的穩定性需求,偉大的架構師們,創造性的提出了“中台”概念,核心是将後台的邏輯層拆出來,形成”前台(應用層)-中台(邏輯層)-後台(數據層)“的産品架構。在這一産品架構下,當前台需求來臨時,中台能快速的進行響應,從而提升了研發效率,降低了創新成本。

(圖片放大後再看哦)

傳統“前台+後台”系統架構

“前台+中台+後台”系統架構

中台并不是一開始就有的,而是系統為适應需求的快速疊代而産生的。具體來講,中台其實是将系統的通用化能力進行打包整合,通過接口的形式賦能到外部系統,從而達到快速支持業務發展的目的。比如:

業務中台,更多的是對業務的支持,比如客戶信息,組織信息、産品信息等,這些都來自某一個系統,且分别支持多個系統的業務。各個系統有相關需求時,需要重新開發。而業務中台的作用就是省去開發,直接從中台獲取相關功能。

數據中台,利用獲取的各類數據、對數據進行加工,獲取分析結果,然後提供給業務中台使用。數據中台的數據來自各業務系統或者數據湖,有源數據、關聯數據、加工好的數據(已經整理的主題數據、算法、模型),再提供給業務中台使用。以購物網站的推薦為例,數據中台根據數據提供算法,然後業務中台基于算法的結果,支撐關聯推薦。

從技術角度,中台是為了搭建一個靈活快速應對變化的架構,可以快速實現前端提的需求,避免重複建設,這也是複合敏捷開發理念。從業務角度,根據中台沉澱的能力,可以支持快速創新,業務更敏捷,以應對未來市場變化。相關業務闆塊已經做好,那麼底層隻要組合一下即可,更加靈活和快速。所以歸根到底,我們必須需要結合企業的實際情況,走出符合企業戰略目标的中台之路。不能盲目跟風,為了中台而中台。

二、怎麼做中台?

從産品層面,中台本質上是将後台的邏輯層抽象出來的一種系統模塊,其目的在于快速的支持業務發展,因此,個人認為,中台實際上是站在“快速響應需求疊代”角度的一種産品設計思維。

當系統足夠龐大時,産品、業務和用戶的每個需求都會涉及到多個系統關聯,尤其是針對多事業部的公司,這些系統都分布在不同的事業部,所以難免會有一些問題:

系統複雜,無法快速拿出産品方案

多重對接,溝通成本巨大

系統間耦合性較大,牽一發而動全身

基本上因為以上問題,新的業務需求無法快速滿足。當一個業務訴求牽涉到系統較多時,需要對應配合的人數太多。因此,從産品/系統角度,我們就需要考慮以中台化的思維去進行方案設計:

通用性

對于業務需求,要跳出需求看本質,理解業務方的真實需求是什麼;要跳出模塊看全局,理解這個需求的實現,除了對消費者、商家的價值,要看到它對平台的價值。

例如之前負責的訂單導出功能,其實用戶需求很簡單:快速導出數據,進行業務分析。但是站在平台角度,平台富有對用戶數據保護的義務,因此需要考慮從數據及用戶層面做權限控制;同時也考慮到商家不僅需要導出訂單,後續可能導庫存、商品及其他業務數據,因此需要考慮産品的通用性,以降低後續開發的成本。作為平台型産品經理,要通盤思考整體的結構,才能做到互不牽連。

結構化

在方案設計上,要做到通用性,需要将通用能力從解決方案中抽離出來,與業務場景進行解耦,從而實現“業務場景-通用能力”系統架構。

還是拿訂單導出舉例,剛開始設計訂單導出時,權限控制,導出任務創建,導出數據下載,訂單業務耦合,其他業務接入時費事費力,還有可能對現有業務産生影響。因此才将訂單導出的通用能力從業務場景中解耦出來。

标準化

将通用能力與業務場景解耦隻是第一步,我們要将通用能力進行打包,形成一套标準化模版,以接口化的形式賦能到外部的業務場景,供業務場景按照标準化的形式進行接入和開發,降低其他業務導出的開發成本。

聲明:本站部分資源來源于網絡,版權歸原作者或者來源機構所有,如作者或來源機構不同意本站轉載采用,請通知我們,我們将第一時間删除内容。本站刊載文章出于傳遞更多信息之目的,所刊文章觀點僅代表作者本人觀點,并不意味着本站贊同作者觀點或證實其描述,其原創性及對文章内容的真實性、完整性、及時性本站亦不作任何保證或承諾,請讀者僅作參考。
編輯: