“忽如一夜春風來，千樹萬樹梨花開”，中臺的概念就如這句詩所描述得一樣一瞬間在IT圈里火了起來，好像不討論中臺就任何解決方案就黯然失色了。中臺(數據中臺、業務中臺、技術中臺、AI中臺……)的概念可謂漫天飛舞，我希望在下面的文章中結合真實的實踐案例，就大家最關心的問題從概念到實踐層面做一些解讀。

• 中臺是什么

在解讀中臺的概念之前我們先看一下“中臺”這個詞的來源。中臺很早的時候由美軍作戰體系演化而來。通過中后臺的強大炮火能力支持前線小團隊的快速判斷，引領整個進攻的完成。意味著讓聽得到炮火聲的人能及時呼喚到炮火。

[[268463]]

對于“中臺到底是什么”這個問題，不同的人不同的理解。有的人認為是增加部分業務功能，或者基于場景的業務微服務集聚中心，也叫API Center，如用戶中心、訂單中心、產品中心等，也稱之為“業務中臺”。有的人認為中臺就是各種技術組件的堆積，如Spring Boot，Devops, 微服務開發框架，Docker等，也稱之為“技術中臺”。

要搞清楚中臺到底是什么，必須追本溯源，回歸初心。得從各類“中臺”概念中抽出來，以更高的視野和視角來看，中臺到底能給企業帶來什么價值?

經過30年的信息化建設，制造業積累了無數的企業管理信息系統，如ERP, MES, PLM, SRM, CRM等。所有這些信息系統都是以流程驅動為核心，解決企業各類管理效率問題。經過多年的開發和建設，這些系統變得臃腫不堪，總結起來就是又慢又貴。就如下圖的大齒輪。

而隨著科學技術的發展，企業面臨的不確定性越來越高，產品復雜性逐步增加，生產過程復雜性逐步增強，客戶定制化需求逐步增多，供應鏈協同復雜性逐步增高。企業的競爭本質上演變為優化資源配置效率的競爭，或者理解為以數據服務業務化來響應瞬息萬變的市場變化。前臺應運而生，就如同下圖中的小齒輪，專注于小而美，快速創新迭代，快速響應用戶需求。內部用戶要訪問多個系統才能獲取諸如產品圖紙、 供應商信息、 庫存等數據，導致其無法快速變化和直接被使用，以支持前臺快速的創新需求。管理層也難以依據營銷、研發、制造、服務等各系統間大數據整合進行實時分析和決策洞察。

而這兩個不同速度齒輪的驅動就去需要一個耦合的齒輪：中臺。它可以快速聚合后臺的數據與能力，通過平臺的快速開發、分析、服務編排等能力，提供前臺更多的創新能力、試錯能力。

舉個例子：比如采購給供應商下發一張圖紙這個非常小場景。采購就得先學會PLM去搜索一張圖紙，同時要學會ERP去看看圖紙對應的原材料的庫存情況，甚至要學會使用SRM系統看一下供應商給的采購價格。簡單的一個場景，由于后臺系統的復雜性，以及部門的局限性導致數據無法形成及時性和協同性給終端用戶，也就是無法真正做到以用戶為中心。

如果一定要給一個定義，我愿意總結為：“中臺是一種思想，是一種體系”。這種思想主要是為了加速數據驅動價值的過程。

• 中臺與SOA/ESB的區別?

那中臺這個概念和我們以往企業在架構信息化系統過程中經常提到的SOA/ESB又有什么區別呢?

SOA更多的是一種軟件架構設計的模型和方法論，它的主要特性是面向服務的分布式計算，服務的重用，服務間松散耦合，支持服務的封裝，服務注冊和自動發現，以服務契約方式定義服務交互方式。

而ESB則更容易理解，它是中心化SOA的具體實現，主要是解決異構系統間整合的常見問題，比如服務連通、路由、消息豐富、服務的注冊/查找/發布等服務的管理、服務監控和質量保證等。

再回顧一下中臺，中臺是因前臺的敏捷性而生，是將后臺系統中需要被前臺調用業務能力、數據通過模型聚合的方式關聯到中臺，同時通過Service API的方式供前臺快速調用，以響應前臺的快速創新與變化，為前臺提供更強大的炮火支援。

SOA/ESB與中臺相比主要面向系統集成，項目實施平均成本高昂，牽涉大量的協同開發，無數據分析能力，面臨性能和擴展性的風險。無論從成本還是效率的角度，都體現了傳統項目建設方式帶來的業務迭代能力不足。

所以中臺不等于SOA更不等于ESB，雖然在理念上和SOA一脈相承，從技術角度來看，也可以作為SOA中開發集成模式的一種演化變形，但中臺顯然是從更高的戰略角度進行考慮的。

• PTC的實踐與案例

1) 使能平臺能力簡介：

PTC的ThingWorx平臺作為制造業企業最合適的中臺使能平臺，含有數據連接、模型聚合、服務注冊與編排、數據分析、前臺應用構建等端到端使能技術。下面一一簡單介紹。

•  數據連接

支持Connector方式將各個不同系統中的3D數據、圖紙、庫存、供應商等數據連接匯聚到ThingWorx平臺，自帶的Kepware組件可以將符合OPC協議的工廠設備、機器人、AGV等連接至平臺，同時支持SDK等多種方式將產品實時運營數據連接至平臺。

圖形化模型聚合

基于連接的數據，我們認為中臺最核心的思想是使用ThingModel的機制聚合模型項與模型項之間管理關系以構建一個完整的產品全量數據模型。如下圖我們構建一個A型號洗衣機全量數據模型(屬性、服務、時間、訂閱)的完整邏輯展示。

而這個過程完全可以通過ThingWorx的圖形化方式完成，不需要編寫代碼。

并且模型項之間的管理關系追溯性可以直接在平臺上查詢，下圖完整展示了ECN、Part以及需求之間的追溯性和關聯。

PTC全球資深副總裁兼大中華區總裁劉強先生表示：“基于ThingModel機制的圖形化方式產品全量數據模型構建是PTC ThingWorx平臺的核心，它使得我們可以使能用戶快速聚合后臺慢且貴的系統業務及數據，提高數據對前臺用戶的及時性、一致性、協同性，加速數據到價值的過程。”

服務編寫、注冊與編排

客戶IT或SI可以使用Java及JavaScript編寫復雜業務邏輯的聚合服務，利用ThingWorx快速開發與部署能力，對服務進行修改驗證，并注冊發布API Center，在API Center中的所有Service API，其它前臺應用、系統甚至微信小程序均可以訪問。

同時如下圖所示，支持已注冊服務傻瓜式、拖拽式編排。

數據分析

同時平臺自帶的分析組件，自帶線性回歸、邏輯回歸、決策樹等7種經典機器學習算法，可以幫助用戶快速構建機器學習算法模型，用以預測設備故障概率，提升工藝水平，找到產品故障模式等，使終端用戶可以真正地基于后臺系統數據進行快速決策。

前臺應用構建

ThingWorx平臺的拖拽式開發體驗可以使前臺開發速度提升10倍以上，通過開箱即用的控件以及積累多年的控件市場(MarketPlace)，所見即所得的布局，數據綁定式服務調用等開發出聚合不同數據及業務的混搭頁面(Mashup)。而這些頁面既可以嵌入原來的前臺頁面，也可以適合單獨的Web瀏覽器訪問甚至移動終端訪問。

同時，ThingWorx平臺的AR開發組件，可以結合聚合的3D數據、實時數據等給用戶不同的數據體驗方式。

2) 場景及案例：

下面通過一些常見的制造業場景及案例來看看PTC ThingWorx如何作為中臺來加速我們說的數據到價值的過程。

采購圖紙下發供應商：

PTC Navigate就是基于ThingWorx開發的應用程序框架，完全基于用戶角色的APP式體驗。APP與臃腫前臺界面或后臺系統的最大區別是， APP是不需要培訓的，是面向特定角色的解決特定場景“小程序”。

采購人員只需要選擇其中的View Drawing APP，輸入圖紙編號，圖紙即可展示在APP中，甚至圖紙對應的零件在ERP中的庫存及單位，在PLM中的狀態及版本都可以呈現在一個APP中，大大提升跨系統數據業務化的及時性和一致性。

數字化質量追溯：

眾所周知，質量在制造業企業是企業的生命線。但是質量的相關數據都被存儲在各個相關的后臺系統中。一般通過檢查的方式來提升。而我們歐洲的某個客戶就在所有相關后臺系統(System of Record)基礎上架構了一層ThingWorx，基于ThingWorx開發了一系列Connected Quality的Apps(System of Innovation)。

其最核心的思想也是通過ThingModel的機制建立需求、驗證、FMEA、變更、工藝路線、客戶反饋、NC及CAPA等所有質量數據的模型項以及模型項之間的關聯關系。從而使能前臺的質量規劃、關鍵控制參數、可預測的工藝質量等基于場景的活動。

結論

PTC全球資深副總裁兼大中華區總裁劉強先生認為：“隨著中臺的興起，的確為企業帶來新的數據服務化及支撐業務創新的方案，企業根據自身業務發展構建中臺從方向來說無疑是正確的，但要適合行業的最佳實踐，根據自身當前的業務成熟度、技術成熟度、理論成熟度來引入具有技術領先性、案例領先性、架構領先性、以及性能領先性的相關商用產品。”

從實施模式上，我們建議遵循Think Big，Start Small，Scale Fast的原則。 基于一定場景快速開始，逐步沉淀，快速復制，最終形成自己的中臺實力，以支撐企業的業務轉型和提升企業競爭力。