中台的靈魂拷問（一）

業務中台

什麼是業務中台？

●【業務中台】為了避免相同能力(業務功能)重複建設，将通用業務能力進行“抽離”與“沉澱”，形成多個“标準、統一”的能力中心，對前台應用提供服務能力，同時打破了傳統的業務支撐模式與組織架構。

●【舉例】将原各業務系統“會員”相關的功能進行統一形成“會員中心”，統一實作如會員管理、成長值管理、積分管理等功能，提供給前台各應用使用，直接一方面将打通前台不同類型應用的會員體系，提升使用者體驗感覺；另一方面統一對會員資料管理，保證會員資料一緻性與完整性，為會員标簽體系（資料變現）提供更加完整的資料支援。

業務中台到底能給企業帶來什麼好處？（為什麼要用業務中台？）

●【去重】：能力複用與資料統一，通用能力沉澱将打破部門壁壘，避免重複建設（降本）

●【做強】：降低試錯成本與加速業務創新，賦能前台業務發展（增效）

業務中台和既有的業務應用系統是什麼關系？

●【橫向替代】：替代原有支撐類業務應用。通過将多個支撐類業務應用的公共能力進行“抽離”與“沉澱”，形成業務中台能力中心，由于部分能力将由能力中心進行統一提供，此時業務中台能力與原有業務應用形成橫向替代關系。

●【縱向支撐】：支撐前台業務應用。通過建立業務能力中心，完成中心化業務資料、業務能力的建構（遷移）後，前台業務應用将直接調用業務中台能力中心，完成業務實作。

業務中台和服務化應用的差別是什麼？關系是什麼？

●【服務化】服務化應用是指某個應用使用“服務”的形式進行建構，并對外提供接入方式，允許其他業務應用調用。服務化并不是中台化，因為并沒有對企業的相同服務能力進行沉澱，也沒有形成"标準“和”統一“的能力；另外業務中台同時也是一種架構，而服務化則是建構應用的一種手段。

●【關系】服務化應用與業務中台的關系是：業務中台的能力中心也是以服務化的形式進行建構的，是以業務中台的能力中心應用一定是服務化的應用。

業務中台和微服務的關系是什麼？

●【微服務】建構複雜應用的一種架構風格，解決的是應用的擴充性、靈活性、故障隔離性等問題。

●【關系】業務中台一般比較龐大且複雜，考慮能力中心将支撐多個前台應用，對性能、擴充性、靈活性等要求，是以業務中台多采用微服務架構去建設各個能力中心，是以能力中心的服務注冊、治理也符合微服務架構對服務的管理特性。

如何選擇業務中台的第一個試點項目？

●【痛點驅動】選擇存在業務痛點、內建關系相對簡單（依賴較少）的能力中心作為第一個試點項目。

●【重要性】第一個試點項目直接決定業務中台的未來走向，必須成功，否則将喪失業務中台建設信心，同時第一個試點項目必須符合企業的業務痛點，否則無法做出成績，即使成功，業務效果不明顯，依然容易遭到質疑。

業務中台的業務效果如何展現與量化？

●【量化名額】業務中台首先需要選擇業務痛點進行建構，量化名額可對比中台能力中心上線前後的幾個方面：1.業務成功率、2.響應時間、3.并發承載量、4.基礎資源投入量、5.橫向擴充成本、6.功能疊代效率

●【分析對比】收集上線前的資料，對比業務中台能力中心上線後的資料，定期形成營運分析報告，并持續營運。

領域驅動到底能幫我們解決什麼問題？

●【模組化方法】領域驅動是一種軟體設計的模組化方法，通過統一的業務語言，打破不同IT工程師的交流壁壘，通過一套行之有效的方法論去“識别”與“建構”服務能力。

●領域驅動的模組化方法，是建構業務中台能力中心的一種較好手段。因為領域驅動天然的會将業務進行領域劃分與解耦，形成類似能力中心的服務模型，将對能力中心在服務拆分提供較好的指導建議。

沒有領域驅動之前是怎麼設計系統？

●【資料驅動】自下而上，先畫出資料模型，再根據表間關系形成服務，适用于業務複雜度低的系統。

●【領域驅動】自上而下，先根據統一語言畫出業務場景，識别業務領域子產品與确定互動流程，技術人員更加容易了解業務方向，避免偏離業務目标，适用于業務複雜度高的系統

怎麼解決業務中台通用性與前端業務定制化（個性化）的訴求？

●【接口開放】業務中台的能力中心一定是滿足通用性的服務能力，同時提供足夠的接口，允許前端業務根據額外的接口進行定制自己的業務。

●【自管理】定制化的能力，不可以沉澱在業務中台，定制化産生的資料與服務全部由業務定制方進行自管理存儲與對外釋出

業務中台的開始研發之前的規範包括哪些？(API、異常、命名？)怎麼管理起來？

●【規範】建立一套适用于業務中台的規範，包括研發團隊的協同管理、服務的命名規範、代碼規範等

●【元件】使用一套适用于業務中台的元件，包括異常捕獲元件、日志輸出元件、消息元件、緩存元件等

業務中台的建設，必須先通過咨詢才能完成建設嗎？

●【建議】先尋找有中台建設經驗的咨詢團隊為中台的頂層設計提供支援和經驗，可以少走彎路，提升中台項目的成功率。

●【捷徑】企業自有研發團隊或ISV的，雖然擁有架構和代碼能力，但是對業務中台的認識往往不足，容易将中台項目做成傳統封閉的單體應用，咨詢将把控建設過程，是中台項目成功的捷徑。

業務中台建設，到底要投入多少才能看到成效？

●【評估】需要根據企業的IT現狀、目标願景、市場環境、業務訴求等多個方面，綜合分析後，才能初步評估投入，一般情況下能力中心越多，成本越高。

●【持續】業務中台建設是個持續的過程，一般建議有限選擇業務痛點進行首個中台能力建設，更加容易出成效，之後再進行持續增加新的能力中心，形成業務中台。

個人觀點，僅供參考。