當我們談中台與微服務的差別時，更多談的是業務中台；當我們談中台與中間件的差別時，則更傾向于技術中台；當我們談中台與資料倉庫的差別時，更多談的則是資料中台。
是以這個問題更嚴謹的表達，應該是“業務中台與微服務”、“技術中台與中間件”、“資料中台與資料倉庫”到底有什麼差別？
微服務更多關注技術架構層面上的問題，而業務中台更多關注業務架構層面上企業級複用的問題。業務中台不一定是微服務架構的，采用了微服務架構的也不一定就是中台。
如果能通過中台這個概念為驅動力，促使企業的内部技術平台再向業務走出一步，無論是針對使用者體驗做優化，還是通過産品化，讓業務可以自助式（Self-Service）地使用企業技術元件的能力，如果能做到這些或是起到這樣的驅動力，我覺得技術中台這個概念才有價值。
最大的一個差別還是資料中台和傳統的資料系統出發點（視角）不一樣。
傳統的資料系統（數倉、大資料平台）更多是偏技術側，拿着資料和技術找場景；而資料中台更多的是偏業務側，拿着場景去找資料和技術。
我們可以用 SOR 來了解背景，對應到企業内，就是那些所謂的核心系統，常見的例如 ERP、DMS、銀行的核心賬務系統等。在實際的項目過程中，我們面對的問題也大多是這類系統無法滿足前台系統快速業務變化的需求，也就是我們專欄裡提到的齒輪比對的問題。
總結來說，阿裡的中台是由平台（例如交易平台）演進過來的，是對于平台治理演進的結果。而在阿裡，背景另有所指（與一般企業了解的背景核心系統不太一樣），通常指那些輔助企業運作的背景系統，例如人力系統等，與中台并沒有什麼關系。
首先還是要想清楚，中台建設的願景是什麼，想好中台自己的方向和産品定位，一個清晰的願景往往就代表了一個好的邊界，這個邊界能幫我們判斷哪些該做哪些不該做，先做什麼，後做什麼。
當然有了願景，肯定也還是會拿捏不好，這時候就得用演進式的視角和技術來幫我們解決這個沖突了。
如果再深入思考一下，可能中台與前台的邊界問題，不是技術的邊界問題，而是組織的邊界問題。就像我一直反複強調的，中台是企業級的問題，中台與前台的邊界劃分，其實本質上就是企業内橫向的平台類組織和縱向的業務類組織的邊界劃分，也就是組織責任與利益的邊界劃分。
從這幾個角度來思考中台與前台的邊界問題的，總結一下就是：想好願景，演進式思維，合理引導組織碰撞。
阿裡提出中台，肯定有其背景和上下文。那麼多企業都效仿，必然有其理由，可能隻是把這個概念“嫁接”到了自己的企業裡而已，甚至可能代表與阿裡或其他公司完全不同的意義。
新概念本身是沒錯的，因為新概念往往代表着新的邊界、新的限制，而新的邊界和限制也往往就是新價值的來源（例如 SOA 和微服務、虛拟化和雲）。
以使用者為中心，從戰略入手，願景為指引，用科學有效的方法，步步為營沉澱企業級能力，輔以必要的組織與系統架構調整，方得中台。
完整課程請掃碼學習哈！
本作品采用知識共享署名-非商業性使用-相同方式共享 4.0 國際許可協定進行許可。
歡迎轉載、使用、重新釋出，但務必保留文章署名 鄭子銘 （包含連結： http://www.cnblogs.com/MingsonZheng/ ），不得用于商業目的，基于本文修改後的作品務必以相同的許可釋出。
如有任何疑問，請與我聯系 ([email protected]) 。