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)

相关推荐