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 框架)

  • 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


作者介绍:

(0)

相关推荐