Headless Commerce是一個有趣的名字，它是近一年國外電商行業的時髦術語。 國內還不怎麼流行這種叫法，但與其對應類似的概念實際上在台灣也是漫天飛舞，這就是"API化"和"中台"說法。 想到中台的火熱，我也隨手記下這篇文章，聊聊無頭電商和中臺。

什麼是無頭電商？

Headleass Commerce可以翻譯成無頭電商，或斷頭電商，核心概念就是將前台展現和後台服務進行解耦的一種架構。 後台以API的方式提供服務，前端展現層與後端分離。 沒有前端表現層（頭），剩下的就是無頭電商了，剩下的就是一堆API介面。

寫過代碼的程式師都很容易理解，這不就是前後端分離，或面向服務架構（SOA）么？ 為什麼這麼簡單的事情，會成為電商行業的噱頭呢？ 其實，這個事情後面有很多深層次的原因，有商業原因，有電商演進歷史，有生態原因，有品牌主新需求等等。

為什麼會發生這種變化？

有幾個事情比較重要：

1. 品牌主建立自有電商的需求

國內外電商平臺雖然都已經寡頭化，美國有亞馬遜，台灣有京東淘寶，很多品牌主依舊努力建立自有電商渠道，不斷突圍。

品牌主建立自有平臺可以加強自有數據的把控能力，直接與消費者進行互動，保證獨有體驗。

2. 電商體驗的多樣化

電商不在是一個簡單Web端，電商行業出現很多新觸點：語音購物，無人超市，場景購物等，前端變得更加豐富多樣

底層的基礎能力相對穩定，底層可以利用API確保穩定

3. 品牌直接面對消費者（Brand Direct To Consumer）

很多互聯網品牌通過創新的電商方式直接面對消費者，消除傳統的中間環節（零售商，批發商等）

一些私域流量給DTC創造了很多創新機會，最後這些創新場景都需要落地電商平臺上。

4. 電商平臺的演化

一體式的電商解決方案：從交易到內容，往往是一家巨型供應商提供，比如Oracle ， SAP， WordPress等

內容和交易能力的一些分離，出現了CMS或DXP的獨立功能區域

無頭電商：以API為基礎的構建方式，前後端分離，通過API支援更廣泛的生態

這種無頭商務平臺脫離了通常範本化的系統前端，允許開發人員在任何類型的框架中為產品和服務創建各種接觸點。 這樣，後端開發人員就可以靈活地創建和使用應用程式程式設計介面（API），以便交付給任何類型的設備，而不僅僅是標準螢幕。

無頭商務與傳統商業有什麼區別？

傳統平台為客戶和業務提供了範本化的體驗，缺少自由風格的發揮空間，通過無頭商務，可以更好地控制商務平臺、客戶業務和用戶體驗。

無頭電商的好處本質上都來源於前後端的解耦，面向服務和API的架構。 後端可以聚焦在沉澱，前後端可以利用API進行交互，以實現更多的應用場景。

1） 無頭商務是迎接物聯網時代（IoT）而創建的對應一些新零售場景，特別是沒有任何螢幕的場景，如何通過語音，視頻，手勢等方式與消費者完成商業互動，其中也包括在戶外，汽車等不同場地。

2） API 是數據流動的管道

無頭電商也是未來數據收集，分析，管理的技術架構的基礎。 傳統的單體電商產品，往往不能實現數據的靈活對流。

3）快速發佈

各模組的解耦使得各個模組可以獨立升級和發佈，各個模組可以採用微服務技術獨立發佈，只需要保持介面的穩定和相容。 新的功能可以通過增加新的介面，新的場景可以驅動這些新介面的集成。 例如，我們需要更換支付服務商，我們只需調用一個新的介面實現者就行，原則上不需要大更改，所有上層應用都不受影響。

4）個性化無頭電商是模組化和靈活的，各個模組API可以進行靈活的組合，封裝，二次開發等。 很多個人化的策略可以靈活應用在無頭電商的各個環節當中。 例如，消費者畫像也可以作為標準模組，提供給各個模組使用，最大程度複用沉澱的洞察。

5）擴展性和穩定性

穩定性，可擴展性和性能對電子商務系統非常重要，因為它們可以直接影響客戶的購買行為。 如果出現意外的後端故障，如果後端和前端斷開連接，後者仍然可用。 後端和前端可以獨立地進行水準擴展和垂直擴展。

無頭電商和中臺

說到這裡，無頭電商和台灣熱火朝天討論的中台（Platform）的理念非常類似：大中台，小前臺;

大中台：本質上是沉澱能力，利用API提高複用性;小前台：本質上是快速反覆運算和試錯。 這個邏輯其實是和Gartner2015提出的Pace-Layerd 應用戰略是一致的，當時Garnter根據系統的變化速度分為 "創新型" ，"差異型"，"穩定型"幾種。

數據中台其實就是保持介面穩定的一個系統，支援快速創新的業務層

中台的一些困惑和隨想

在台灣，中台已經流行幾年了，仔細想想，中台本質也是一種無頭。 無頭電商是中台概念在一個具體行業的應用。 沉澱和複用是很多公司的不同階段都會碰到的，中台戰略是解決這個問題的某種形式。 很多大大小小公司開始組建中台攻堅團隊，我與很多朋友都聊過中體的經歷，大大小小都會碰到一下一些困惑。 例如，一個公司在推進中台戰略中，單點登錄是唯一成功的案例，其它中台能力的推廣都是很難，每個業務線都有自己研發，不喜歡別人輪子。

1） 中台和前臺的界限無法界定清楚。 中台實現兩個能力，一個是沉澱，另外是複用; 二者相輔相成。 前臺更加面向客戶，他們更加容易最快速度創造客戶價值和商業價值。

如何衡量這種花費是否合理？ 一種衡量的方法是：對每個新業務，評估一下中台支援的粒度和程度，如果對於中台的範疇，大家都沒有太大歧義，這麼這種解耦可能是合理的。 如果對於每個新業務，大家都要對範圍界定進行激烈討論，那麼大家還是需要一個更加清晰的中台定位。

2） 中台的成功無法衡量和量化

那麼如何衡量中台的成績和成功呢？ 很多時候這個成績是沒有辦法衡量的，但是無法量化的東西，是無法改進的。 因此，很多中台的戰略都是至上而下的組織形態優化。

具體量化的時候，我們常常有兩個思路：1 中台能力被使用了的範圍和深度 ，例如API調用次數，業務使用量，依賴強度等 2. 中台説明那些業務提升了效率和效益，提升比例等。 量化這些指標常常是短期的行為，中台建設也包括一些創新的投資，以及中長期的數據能力沉澱。

3） 產品經理在中台戰略的新挑戰

大多產品經理喜歡參與2C的產品設計，小一部分產品經理深入2B的產品設計。 中台涉及很多技術邏輯，涉及到業務底層實現，涉及到公司多個部門的協同共贏，能夠勝任這種角色的產品經理，少之又少，大部分都是由研發主管兼任，或者是項目經理類似角色擔當。

中台產品經理比較靠近2B/2D的產品經理，但是更加面向內部多種業務，面向綜合效率提升，面向技術架構，也需要很強的商業化的思考。

4） 數據中台越來越重要

大部分公司都有獨立的數據平台團隊，但各業務線對數據都有自己的解讀。 在每一個時刻，數據中台需要有自己清楚的定位，這個定位需要讓所有業務都清楚瞭解。 如果定位有任何變化，這種變化需要提前通知到各個業務線。

現實中，各個業務線都會發展自己的數據應用能力，數據分析能力，這些分析需要定期的沉澱到數據中台。

5） 中台需要面向開發者，與理解數據邏輯的業務人員的。

中台不是華麗的界面和裝修，而是底層的脊樑和磚頭。 中台的能力，必須由業務團隊使用（邏輯上理解），程式師使用（利用API調用）。

如果中台直接面向業務的運營，很可能是不成功的。 因為，運營很多時候具有快節奏的變化，缺少穩定性，運營平臺更像是一種中台的上層應用。 另外，運營在使用中台時候，缺少工程師對於API的一些理解，也不利於中台的介面完善和發展。

前台團隊中有程式師，才能最大程度發揮中台的作用。

6） 中台是需要運營的，面向中台服務的技術運營，

運營可以成為中台和前臺的潤滑劑，保證前臺和中台之間的順暢。 在一些大型的公司，中台能力甚至需要一些主動的推廣，確保整個組織能夠真正從中台中收益，並且為中台也做貢獻。

無頭電商的技術方案

說了這麼多中台，看起來有些跑題了，回到無頭電商的一些技術，其中有些技術很多技術中台都可以採用。

1）CMS支援無頭電商的產品：

Contentful （非常流行， 基於 API 的內容管理系統 ）

Adobe Experience Manager （企業等級體驗管理平臺）

Amplience （企業級別體驗管理平台，支援無頭電商）

Acquia （企業等級體驗管理平台，支援無頭電商）

Kentico （中型內容管理平臺）

Sitecore （企業層級內容管理平臺）

Prismic （面向API的CMS）

Gatsby （基於react的PWA 框架）

Vuestorefront （基於vue.js的PWA 框架）

Deity （基於react.js的 PWA 框架）

2）持無頭電商的系統

CommerceTools

ElasticPath（用途比較廣的電商平臺，支持豐富API）

Moltin（主打API模式的電商平臺）

Magento （2018年5被Adobe收購，整合在Adobe Commerce Cloud中，支援與Adobe其它軟體整合）

BigCommerce（主打無頭電商）

SAP CX Commerce Cloud （優勢在後端 如CRM/ERP等，支援透過API模式與不同的前端整合）

OroCommerce （B2B的電商平臺）

Spryker

3） 無頭電商的 API 標準：

OCAPI (Open Commerce API)：

這個標準是Salesforce提供的電商API，漸漸成為電商行業的開放標準，Magento，SiteCore等系統能比較好支援這個協定。 Salesforce在對接標準和開放程度上走在行業領先地位，這也是大家看好它的重要原因。

JSS(Javascript Services)

SiteCore利用Javascript提供的API能力，SiteCore也越來越開放

4） 延伸性的前端技術：

JAMStack：

這是一個非常有趣的架構，企圖顛覆傳統三層架構：靜態 元素放在CDN上，動態數據利用Service/API進行交互。 JAMstack將複雜問題分解為動態和靜態部分。

PWA（Progressive Web Apps)

把網頁開發成像本地應用一樣的技術，可以媲美原生用戶體驗，包括離線可用，後台推送等功能。 類似微信的小程式技術，只不過PWA是瀏覽器裡的小程式。 PWA夢想很美好，現實很殘酷。 PWA的技術也在被各種平台內的技術所代替。

GraphQL:

一種面向API的理想主義查詢語言;傳統API需要嚴格規定參數和格式，GraphQL提供了一些API的查詢和歸一化能力，使得API開發更加方便和具有擴充性。 它比REST更加靈活。 一些都是介面，一切都是可描述的。

無頭電商的缺點/缺點

1） 複雜性的增加

單體模式依舊是最簡單模式，無頭電商將失去這種簡單，進入一個複雜的技術世界。 幸運的是，現在的軟體技術和雲技術都可以更好的處理這些複雜度，當然這也涉及到技術思維的升級。。

2）成本的增加

無頭電商的推廣和實施往往需要時間和耐心。 從經驗來看，無頭電子商務實施通常會產生成本開銷（由於需要更多開發）;集成也會更加複雜 ，其中會涉及到更多的第三方供應商。

那麼，如何管理這種複雜度和有效管理成本？ 有幾點可能會有説明：

1）加強數據團隊和雲技術人才，增強管理技術複雜度的能力

2）業務驅動的演化路徑，一步步的演化系統架構，更好的系統架構要更加快速嘗試更多的業務場景

3）積極利用公有雲基礎架構，少造輪子，持續優化

（本文為CSDN博主「互聯居」的原創文章）

知識星球