无头商务的肮脏秘密：一些供应商故意不说

无头商务解决方案的肮脏秘密：一些供应商（故意）不告诉您的内容可能会花费您大量时间。

无头商务——或者简单地说，“无头”——是目前 B2C 世界的宠儿。 根据 Google 趋势，自 2020 年初以来，无头商务的搜索请求呈​​指数增长。从电子商务的角度来看，原因很容易理解。

在大流行期间，消费者一直呆在家里，被束缚在他们的社交媒体上。 直接面向消费者的品牌可以利用 Instagram、TikTok 或 Facebook 等媒体，将产品直接面向目标受众。 无头商务解决方案是显而易见的。

无头架构提供了极大的灵活性。 由于前端和后端的解耦（以及 API 的可用性），对于希望在新渠道上部署商务的组织来说，使用支持无头的平台来实现这一目标要容易得多。

无头商务解决方案还提供了更大的敏捷性，因为前端和后端是分开部署的。 由于敏捷性已成为一项巨大的业务差异化因素，因此对无头技术的兴趣正在飙升。

无头商务解决方案：切入炒作

但究竟什么是无头商务？ 就像技术和营销领域经常出现的情况一样，人们倾向于抓住最新的流行语——回想几年前的大数据或人工智能/机器学习——并将其注入尽可能多的对话中.

然而，当人们无法真正定义事物是什么时，事物周围的水域往往会变得非常模糊。 这正是无头商务正在发生的事情。

我们不能对营销人员太苛刻； 他们不是唯一搅浑水的人。 许多供应商有意或无意地将无头、云、API 和微服务混为一谈。 他们有自己的议程，因此模糊这些事情之间的界限对他们有利。 需要明确的是，它们都不相同。

简单地说，无头商务意味着：

1. 前端/店面/玻璃与商业引擎（即后端）分离。
2. 由于它是解耦的，因此它通过 API 调用使用定价和促销等后端功能。
3. 因此，根据定义，对于能够支持无头部署的商务平台，它需要对商务后端功能进行 API 覆盖。

让我们深入了解一下 headless 到底是什么（以及它不是什么）、它来自哪里以及它的用途。

无头商务并不是什么新鲜事

虽然这个词本身可能只是在过去几年才开始流行起来，但无头的概念并不是什么新鲜事。 如上所述，这是一种 API 优先的方法，其中前端/表示层/玻璃与核心分离（使用 API）。

例如，在 SAP（以及以前的 Hybris），十多年来，我们一直在通过我们的 Restful API 层（Omni-Commerce 连接）启用商务功能。 在运行 SAP Commerce（本地和云端）的 3500 多家客户中，约有一半以无头方式使用第三方 CMS 或定制的解耦店面。

关键是，不要被嗡嗡声所迷惑； headless 并没有刚刚出现在现场。

纯粹的无头商务解决方案并不适合所有人

与其他一切一样，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 功能和个性化是必不可少的。

不要陷入将功能强大的功能与遗留架构混为一谈的陷阱，尽管有些供应商会这么说。