Headless Commerce(無頭電商)與中台隨想

Headless Commerce(無頭電商)與中台隨想

Headless Commerce(無頭電商)與中台隨想

歐陽辰 互聯居 今天

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

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

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

為什麼會發生這種變化?
有幾個事情比較重要:
1. 品牌主建立自有電商的需求

    1. 國內外電商平臺雖然都已經寡頭化,美國有亞馬遜,台灣有京東淘寶,很多品牌主依舊努力建立自有電商渠道,不斷突圍。
    2. 品牌主建立自有平臺可以加強自有數據的把控能力,直接與消費者進行互動,保證獨有體驗。

2. 電商體驗的多樣化

    1. 電商不在是一個簡單Web端,電商行業出現很多新觸點:語音購物,無人超市,場景購物等,前端變得更加豐富多樣
    2. 底層的基礎能力相對穩定,底層可以利用API確保穩定

3. 品牌直接面對消費者(Brand Direct To Consumer)

    1. 很多互聯網品牌通過創新的電商方式直接面對消費者,消除傳統的中間環節(零售商,批發商等)
    2. 一些私域流量給DTC創造了很多創新機會,最後這些創新場景都需要落地電商平臺上。

4. 電商平臺的演化

    1. 一體式的電商解決方案:從交易到內容,往往是一家巨型供應商提供,比如Oracle , SAP, WordPress等
    2. 內容和交易能力的一些分離,出現了CMS或DXP的獨立功能區域
    3. 無頭電商:以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)積極利用公有雲基礎架構,少造輪子,持續優化

參考連線:
paulnrogers.com/introdu
sparkred.com/blog/micha
ipraxa.com/blog/headles
jss.sitecore.com/featur
bigcommerce.com/blog/he
degdigital.com/insights
bigcommerce.com/blog/fl
jianshu.com/p/a88b80d88

作者介紹:

歐陽辰,品友互動,CTO,《Druid即時大數據分析》書作者,《構建高品質的軟體》譯者,超過17年的互聯網老兵。 曾任小米商業產品部 研發總監,實現從0到1的廣告和大數據平台建設;曾任微軟研發經理,負責微軟移動Contexual Ads廣告平臺,參與Bing搜尋引擎IndexServe的核心模組研發。 有空也會在個人微信公眾號"互聯居"中,分享一些互聯網技術心得,訂閱"互聯居"公眾號,與作者直接交流。

您的網站設計如何説明改善領先一代?

為什麼新手一定要做Shopify!!! 聽說有人日出15000單Tik Tok流量這麼猛。