Headless Commerce（无头电商）与中台随想
【转发按】我应该是最早向国内数字化圈介绍“无头电商”的概念的人。几个月前，国外同事请我帮助评估某欧洲零售企业进入中国，其”无头电商“平台的技术选型策略。我还是第一次听说这个名词，到百度上去搜，中文互联网里几乎没有这个名词相关的信息。
经过一阵子研究，我将对“无头电商”的观点在一个人气挺旺的国内MarTech微信大群里探讨，反响挺热烈。本文作者是MarTech群的群友，某知名MarTech公司CTO，供大家参考。
—— 陈 果
Headless Commerce是一个有趣的名字，它是近一年国外电商行业的时髦术语。国内还不怎么流行这种叫法，但与其对应类似的概念实际上在中国也是漫天飞舞，这就是“API化”和“中台”说法。想到中台的火热，我也随手记下这篇文章，聊聊无头电商和中台。
什么是无头电商？
Headleass Commerce可以翻译成无头电商，或断头电商，核心概念就是将前台展现和后台服务进行解耦的一种架构。后台以API的方式提供服务，前端展现层与后端分离。没有前端表现层（头），剩下的就是无头电商了，剩下的就是一堆API接口。
写过代码的程序员都很容易理解，这不就是前后端分离，或面向服务架构(SOA)么？为什么这么简单的事情，会成为电商行业的噱头呢？其实，这个事情后面有很多深层次的原因，有商业原因，有电商演进历史，有生态原因，有品牌主新需求等等。
为什么会发生这种变化？
有几个事情比较重要：
1. 品牌主建立自有电商的需求
国内外电商平台虽然都已经寡头化，美国有亚马逊，中国有京东淘宝，很多品牌主依旧努力建立自有电商渠道，不断突围。
品牌主建立自有平台可以加强自有数据的把控能力，直接与消费者进行互动，保证独有体验。
2. 电商体验的多样化
电商不在是一个简单Web端，电商行业出现很多新触点：语音购物，无人超市，场景购物等，前端变得更加丰富多样
底层的基础能力相对稳定，底层可以利用API确保稳定
很多互联网品牌通过创新的电商方式直接面对消费者，消除传统的中间环节（零售商，批发商等）
一些私域流量给DTC创造了很多创新机会，最后这些创新场景都需要落地电商平台上。
一体式的电商解决方案：从交易到内容，往往是一家巨型供应商提供，比如Oracle , SAP， WordPress等
内容和交易能力的一些分离，出现了CMS或DXP的独立功能区域
无头电商：以API为基础的构建方式，前后端分离，通过API支持更广泛的生态
3. 品牌直接面对消费者（Brand Direct To Consumer)
4. 电商平台的演化
这种无头商务平台脱离了通常模板化的系统前端，允许开发人员在任何类型的框架中为产品和服务创建各种接触点。这样，后端开发人员就可以灵活地创建和使用应用程序编程接口（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的核心模块研发。有空也会在个人微信公众号“互联居”中，分享一些互联网技术心得，订阅“互联居”公众号，与作者直接交流。
我的书：