無頭商務的骯髒秘密:一些供應商故意不說
已發表: 2021-06-07無頭商務解決方案的骯髒秘密:一些供應商(故意)不告訴您的內容可能會花費您大量時間。
無頭商務——或者簡單地說,“無頭”——是目前 B2C 世界的寵兒。 根據 Google 趨勢,自 2020 年初以來,無頭商務的搜索請求呈指數增長。從電子商務的角度來看,原因很容易理解。
在大流行期間,消費者一直呆在家裡,被束縛在他們的社交媒體上。 直接面向消費者的品牌可以利用 Instagram、TikTok 或 Facebook 等媒體,將產品直接面向目標受眾。 無頭商務解決方案是顯而易見的。
無頭架構提供了極大的靈活性。 由於前端和後端的解耦(以及 API 的可用性),希望在新渠道上部署商務的組織使用支持無頭的平台更容易做到這一點。
無頭商務解決方案還提供了更大的敏捷性,因為前端和後端是分開部署的。 由於敏捷性已成為一項巨大的業務差異化因素,因此對無頭技術的興趣正在飆升。
什麼是無頭商務:定義、好處、示例
今天,我們比以往任何時候都擁有更多關於客戶想要什麼的信息。 通過行動、社交媒體更新和調查,客戶告訴我們他們想要什麼——我們有責任為他們提供他們想要的靈活性和自由。
無頭商務解決方案:切入炒作
但究竟什麼是無頭商務? 就像技術和營銷領域經常出現的情況一樣,人們傾向於抓住最新的流行語——回想幾年前的大數據或人工智能/機器學習——並將其註入盡可能多的對話中.
然而,當人們無法真正定義事物是什麼時,事物周圍的水域往往會變得非常模糊。 這正是無頭商務正在發生的事情。
我們不能對營銷人員太苛刻; 他們不是唯一攪渾水的人。 許多供應商有意或無意地將無頭、雲、API 和微服務混為一談。 他們有自己的議程,因此模糊這些事情之間的界限對他們有利。 需要明確的是,它們都不相同。
簡單地說,無頭商務意味著:
- 前端/店面/玻璃與商業引擎(即後端)分離。
- 由於它是解耦的,因此它通過 API 調用使用定價和促銷等後端功能。
- 因此,根據定義,對於能夠支持無頭部署的商務平台,它需要對商務後端功能進行 API 覆蓋。
讓我們深入了解一下 headless 到底是什麼(以及它不是什麼)、它來自哪里以及它的用途。
無頭商務並不是什麼新鮮事
雖然這個詞本身可能只是在過去幾年才開始流行起來,但無頭的概念並不是什麼新鮮事。 如上所述,這是一種 API 優先的方法,其中前端/表示層/玻璃與核心分離(使用 API)。
例如,在 SAP(以及以前的 Hybris),十多年來,我們一直在通過我們的 Restful API 層(Omni-Commerce 連接)啟用商務功能。 在運行 SAP Commerce(本地和雲端)的 3500 多家客戶中,約有一半以無頭方式使用第三方 CMS 或定制的解耦店面。
關鍵是,不要被嗡嗡聲所迷惑; headless 並沒有剛剛出現在現場。
構建 DTC 電子商務的未來,一次一個黑客……
創建完美的全渠道電子商務店面需要多少黑客? SAP Upscale Commerce 即將揭曉 - 加入我們!
純粹的無頭商務解決方案並不適合所有人
與其他一切一樣,Headless 並不適合所有人。 對於初學者來說,這很複雜。 開發人員必須具備跨多個代碼庫的技能深度和廣度。

但這還不是全部。 它們需要 IT 成熟度和開發能力,因為必須使用前端框架和庫(例如 Angular/React/Vue)或通過合作夥伴解決方案完全從頭開始構建定制的表示層/店面。 這些自定義前端通常不受供應商支持。
此外,定制前端通常會限制業務從業者在沒有 IT 幫助的情況下設計和更新前端的能力。 如果這對您的業務來說是一個重要的考慮因素,那麼無頭商務解決方案可能不適合您。
好消息:供應商提供具有 100% API 覆蓋率和解耦店面的“headless and head-on”功能,無需從頭開始構建。 這種方法加快了前端開發和整個項目交付時間表。
無頭不等於微服務
正如我們在開頭提到的那樣,一些供應商故意將無頭與微服務混為一談。 讓我們澄清事實。
不,微服務不等同於 API。 不(我將在這裡使用我的“外部”聲音),基於微服務的架構不是 HEADLESS 的先決條件(另一方面,API 是)。
根據 Martin Fowler 的說法,“微服務架構風格是一種將單個應用程序開發為一組小型服務的方法,每個服務都在自己的進程中運行並與輕量級機制進行通信,通常是 HTTP 資源 API。”
你沒看錯——微服務通過 API 公開它們的功能,因此是互補的,不可互換的概念。 將基於微服務的架構與整個應用程序由“一段”代碼組成的單體架構進行比較。 在現實世界中,很少有應用程序完全基於微服務或完全單體; 它們通常落在中間的某個地方。
雖然微服務可以做很多事情,但它們也很昂貴(大量開銷),而且絕不是敏捷的靈丹妙藥。 在不討論每種架構模式的優缺點的情況下,值得注意的是,基於微服務的架構的主要優勢是大型開發組織可以構建軟件的速度和敏捷性。 與在單體架構中開發代碼的時間相比,開銷很小。
點贊和購買:如何通過社交商務來淘金
社交平台為品牌提供了一個獨特的窗口,可以在他們最感興趣的地方與購物者會面。 了解品牌如何構建有利可圖的社交商務戰略。
因此,對於像亞馬遜這樣通常擁有數百名開發人員的商業平台供應商來說,它非常有價值。 然而,這種架構並不適合所有人。 對於沒有 IT 技術和相應的商務開發資源來從中受益的組織來說,它尤其不適合。
最好考慮一下 Gartner 所說的可組合業務架構。 這種可互換構建模塊的模型使企業能夠根據需要重新安排,具體取決於客戶價值觀的轉變或供應鍊或材料的突然變化等因素。 這些構建塊或模塊可以是微觀服務,也可以是宏觀服務。
根據 Gartner 的說法,這種架構提供了:通過發現提高速度、通過模塊化提高敏捷性、通過編排提高領導力以及通過自治實現彈性。 在大流行期間,這再重要不過了,當時組織不得不在幾天內徹底重新思考和調整其業務模式,否則就有破產的風險。
現在,如果您想知道為什麼有些供應商將無頭與微服務混為一談,答案與企業軟件市場本身一樣古老。 通過強調一種新的閃亮功能,它允許新興供應商將注意力從平台和功能穩健性等不足的功能上轉移。
雖然現代架構絕對是選擇商務平台時的重要考慮因素,但不能以犧牲功能豐富性或授權業務用戶的能力為代價。
Headless 將繼續存在
隨著接觸點數量的不斷增長,無頭商務將無處可去。 在選擇平台時,請考慮適用於您的業務的所有功能和非功能要求,不僅是今天,而且是明天。
選擇一個今天可能完成這項工作但不會支持您的發展的平台(例如,國際本地化)是短視的,只會導致眾所周知的問題。
最後,一些供應商希望您看到明亮、閃亮的物體這一事實並不意味著其他要求突然變得無關緊要。 產品信息管理、Web 內容管理、訂單管理、B2B 功能、B2C 功能和個性化是必不可少的。
不要陷入將功能強大的功能與遺留架構混為一談的陷阱,儘管有些供應商會這麼說。