营销世界的 5 大剧变之 ② 微服务和 API
  文科生 ·  2017-08-30

编者按:本文经作者 Scott Brinker 授权 宏原科技创始人 @文科生 翻译,所译中文版本授权独家首发于 SocialBeta 。未经许可,不得转载。(微信在 SocialBeta 首发前,不允许其他公众号先行转载。)

译者前言:这是 Scott Brinker 在 2016 年 12 月发布的题为《营销的五个剧变》中的第二篇,主题是微服务 & API。与第一篇更偏向 Marketing 的讨论相比,本篇的讨论更多偏向于 Technology。对于我这就是一个快速熟悉 MarTech 技术端解决方案的过程,让我更加全面地了解了 MarTech 技术的趋势、思路和解决方案,也了解了更多不同类型的 MarTech 公司。有一点我个人感受很深刻,未来的公司都至少在一定程度上是一个软件公司,未来和营销相关的软件应用都会建立在微服务架构上,他们没有外设,软件之间交互是通过 API 进行。

与此同时,我一边读一边思考,相比而言,国外的 MarTech 生态貌似远远比中国市场繁荣。真实的情况是这样的吗?为什么会有这样的情况?是因为巨头的开放程度,还是因为企业对于 MarTech 积极拥抱的程度?还是因为管理或者文化方面的原因?

这也是我特别想跟 Scott 以及国内的同仁们请教的问题。

                                              注:上图来自 MuleSoft 的演讲。应用网络:Netflix 的微服务

这篇文章是《营销的五个剧变》系列的第二篇文章:

回顾一下,营销的五个剧变是:

1.  数字化转型将超越营销部门的职能范畴,重新定义 「营销」。

2.  微服务 & API(以及开源) 构成了营销基础设施的架构。

3.  纵向竞争展现出比横向竞争更大的战略性威胁。

4.  增强现实 (AR)、混合现实 (MR)、虚拟现实(VR)、物联网(IoT)、可穿戴设备、对话式界面等等,给人们带来了数字化的一切。

5.  人工智能 (AI) 让营销和商业运作的复杂性倍增。

数字化转型对于技术的需求——前台及后台系统需要保证客户在数字世界中的体验无缝衔接——将我们带到了下一个剧变:作为现代营销和商业基础设施中的首选架构,微服务(microservices)正在崛起。

虽然大量的软件和应用都有为人们设计的 UI 界面,但更多的公司将会需要以程序化的方式,通过 API 来协调和增强这些应用的功能——同时,也在这些服务的后台上创建自己的定制化软件。这些定制化软件回答的问题是:「作为一个数字化的企业,我们要解决什么问题?」

这是对「一套规则决定一切」(one suite to rule them all)的营销技术世界观的颠覆。至少在一定程度上,是对一个公司依赖单一供应商为其提供在数字世界所需的所有功能的颠覆。

来看看那些实现了数字化转型或者本身就是数字原住民公司的必须条件:

1.   必须通过数字化的方式灵活地连接所有部门。

2.   必须将「营销」嵌入数字产品当中 (Growth hacking)。

3.   必须创造性地区分产品、营销和运营。

4.   必须快速响应新的机会和威胁。

5.   必须能和其他公司建立动态的数字化伙伴关系。

很难想象一套大规模、封闭式系统的软件应用能够为所有人提供好服务。即使它可以被创建出来(项目名:Project Babel *),它的内部复杂性一定很吓人——维护这个软件将是一场噩梦。在今天技术创新不断加速的环境中,快速实验、拥抱变化和适应的能力对于生存至关重要(参阅 MarTech 法则)。

* 注 Project Babel 是一套在众多方面进行创新的开放源代码网络社区软件

当然,微服务架构也有自己的挑战。如果把大规模应用的内部复杂性替换成了集成简单组件的复杂性——虽然获得了选用组件的灵活性,但每个组件都需要根据具体的目的设计和优化。

幸运的是,集成的复杂性已经能被 MarTech 供应商逐步解决,其中也包括一些新生代的、以云端为基础的中间软件解决方案 iPaaS (integration-platform-as-a-service)。iPaaS 涵盖的范围包括为企业开发者提供的技术平台,例如 MuleSoft;还有为不同规模企业的高级用户开发的轻量级工具,例如:IFTTTZapier

值得注意的是,几大主要的营销云供应商依然在微服务架构中扮演巨大的作用,或者作为客户数据平台(CDP),或者作为营销决策引擎和渠道来运行「服务」。但现在,这个领域更像是一项「团队运动」。

一个公司的营销基础设施有 80% 是由那些主要营销服务商提供的——剩下的 20% 是为了特定的业务独立组装或创建出来的,但这 20% 对于每个公司的数字化差异性来说至关重要。

许多主要的营销服务商已经朝着这个方向前进,他们在平台开放方面做出了重大的努力,以便在 API 主导的环境中出色发挥。

  • 长期以来,Salesforce 都是在此领域的领导者,有数千个 ISV 集成其中,以及一个庞大而成熟的定制应用生态系统。大家可以去 devlopers.salesforce.com 查看,尤其可以关注一下 Heroku

  • Adobe 为不同套件中的 API 文档和服务推出了 Adobe I/O 枢纽,以及能够促进技术合作伙伴生态不断发展的 Adobe Marketing Cloud Exchange

  • SAP 新的 Hybris-as-a-Platform(YaaS*) 功能,明确为数字化商业提供以云端为基础的微服务生态系统,重点是为开发者提供了广泛的 API 所带来的灵活性。

    (* YaaS 是一个微服务生态,以帮助公司快速增加和构建新的和高度灵活的解决方案。Hybris 是一个德国 SAP 旗下的软件,提供多渠道的电商和互动解决方案)

  • 在中小企业细分市场,Hubspot 新推出了增长栈(Growth Stack),试图在数字化世界将营销和销售连接起来——顺便说一下,我喜欢这个名字——其特征是在平台内部深度嵌入一组可扩展的 API 以及不断增长的 ISV 开发者生态。

  • Marketo 曾经是最早拥抱开放平台战略的先锋之一,拥有庞大的 * LaunchPoint ISV 生态系统和升级版的开发者枢纽。值得注意的是,他们的新 CEO Steve Lucas 具有在 Salesforce 和 SAP 这样领先平台的工作背景。

    (*Marketo LaunchPoint 拥有最全的营销解决方案生态)

以上都是行业内最有影响力的领先者对于 API 战略的重要布局,表明他们相信这就是营销未来的方向。

而且这还只是冰山的一角。Oracle、Sitecore、Intercom、MailChimp、Act-on IBM、Acquia 等大平台都为自己的数据和服务提供了强大的 API。「无外设 CMS」(headless CMS)运动,iPaaS 平台在电商领域(B2B 的电商世界)的流行程度超越了 SaaS 平台, 由「公民开发者和整合者」(citizen developers and integrators)推动的「破解流程」(Process Hacking)的出现,以上趋势进一步佐证了可被程序化控制的营销技术的增长势头。

短期内,最佳营销栈就能在这些 API 和 iPaaS 解决方案的推动下产生——B2B 技术公关公司 WalerSands 最近的研究指出,这也是时下运用营销技术最流行的方式。

现在的很多营销栈可以被定义为「微服务架构」——大量的半封闭应用工具,之间有较小规模的数据交换。IDC 研究总监 Gerry Murray 在有关客户体验操作系统 (CX-OS) 的报告中生动描述了以下愿景:被广泛应用于整个业务流程的营销栈,进化成更加灵活的微服务架构。

重点要强调的是,这些微服务架构不仅仅适用于后台运作。他们能让一个公司搭建出面向客户的数字化产品——有些具有人机交互界面,例如移动 App 或聊天机器人;有些为其他公司提供 API,使之能够以程序化的方式调用服务。

随着数字化转型的发展,我们来看看今天的数字原住民公司。这类公司的产品和营销系统大多就是围绕微服务架构组织起来的。因为在这类公司中,产品和营销天生就密不可分。

在分享微服务经验方面,Netflix 非常慷慨,你可以在 Netflix 技术博客中读到很多有关他们架构的内容。你还可以从曾是 Netflix 广告技术总监的 Tony Ralph 那里看到关于 MarTech 的精彩演讲:他们如何用 API 导向的方式,用营销技术支持「构建和购买」(build and buy)的策略。

作为祖父辈的数字原住民公司,Amazon 采用微服务架构已经超过 14 年了。业务中的每件事都需要通过数字服务界面进行交互——这些界面的设计必须可外化。以便当机会来临时,可以产品化或者提供给合作伙伴。这其实就是 Jeff Bezos 提出的著名的「大指令」(Big Mandate) 。

1)     所有团队从此以后要通过服务界面展现数据和功能。

2)     团队必须通过这些服务界面彼此沟通。

3)     不允许使用通过网络服务界面之外的其他沟通方式。

4)     具体使用什么技术不重要。

5)     所有的服务界面设计必须可以被外化。

6)     任何不遵循指令的人将会被解雇。

数字原住民公司的成功预示着未来越来越多的公司也会这么做。

从中可以得到的一个启示是,不同的公司在「营销」中需要更多有意识的软件管理和开发。即使 MarTech 厂商和 iPaaS 解决方案产生了很多可互联互通的功能,公司总还会有一些需要定制化的功能。这就是在该系列的首篇文章——《数字化转型》描述的现象所引发的效应。

那么,谁来承担这类软件开发工作?

一种做法就是打造内部的独立软件开发团队,无论是 IT、营销内部的工程团队还是数字产品团队(或者以上全部),让他们负责构建和发展公司的数字化能力。考虑到软件已经无处不在,唯一符合逻辑的就是所有公司都应该是一个软件公司,至少在一定程度上是个软件公司。

但是那些能够按需定制软件的服务商仍然会有巨大的机会。我们看到埃森哲、德勤、IBM 和 Sapient (已被阳狮集团收购)正在推进他们的「数字化转型」业务,而且以惊人的规模增长。然而,我相信这也是成千上万小公司的未来。

无论是哪条路,会有更多软件开发者积极投身于创造卓越的客户体验,并在这些体验中直接融入「营销」元素。

软件开发和「营销」之间更大程度上融合的结果之一,就是会有更多开源软件进入营销领域。开发者一定会利用现存的开源项目——例如,类似 Hadoop 这样的后端大数据技术以及众多前端 web 和物联网的框架。不过,他们也会为新的营销模式打造一系列新的开源软件。

我们会看到后面谈到的三个剧变也会支持以微服务方式建立的营销基础设施,并且从中获益。

预告:本系列的下一篇文章是第三部:纵向竞争

-----

首发于 SocialBeta APP ,更多营销干货,扫描下方二维码。

    4
为你推荐