Headless Commerce（無頭電商）與中台隨想
Headless Commerce（無頭電商）與中台隨想
歐陽辰 互聯居 今天
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）積極利用公有雲基礎架構，少造輪子，持續優化
參考連線：
https://paulnrogers.com/introduction-to-headless-ecommerce/
https://www. sparkred.com/blog/michael-kors-case-study-a-journey-to-headless-commerce/
https://www. ipraxa.com/blog/headless-ecommerce-guide/
https://jss.sitecore.com/features
https://www. bigcommerce.com/blog/headless-commerce/
https://www. degdigital.com/insights/headless-architecture-digital-experiences/
https://www. bigcommerce.com/blog/flexible-headless-commerce-solutions/
https://www. jianshu.com/p/a88b80d88284
作者介紹：
歐陽辰，品友互動，CTO，《Druid即時大數據分析》書作者，《構建高品質的軟體》譯者，超過17年的互聯網老兵。 曾任小米商業產品部 研發總監，實現從0到1的廣告和大數據平台建設;曾任微軟研發經理，負責微軟移動Contexual Ads廣告平臺，參與Bing搜尋引擎IndexServe的核心模組研發。 有空也會在個人微信公眾號"互聯居"中，分享一些互聯網技術心得，訂閱"互聯居"公眾號，與作者直接交流。
