HubSpot平台生态系统负责人: 与SaaS平台的4层应用API集成

我们生活在所谓的API经济中。几乎所有SaaS产品都有API,几乎所有主要的营销平台都有“应用程序市场”,客户可以从众多经过认证的技术合作伙伴中选择应用程序。

阿里云变革工厂:以前1台机器1.8个人管,现在1人管8台机器
《推进综合交通运输大数据发展行动纲要(2020—2025年)》印发
企业价值链调整:亚马逊做好Whole Foods和谷歌做好云计算的共同挑战
HubSpot平台生态系统负责人: 与SaaS平台的4层应用API集成插图

根据市场研究公司Ascend2最近的一项研究,“整合不同系统”是52%营销人员通过营销技术取得成功的最大障碍。

HubSpot平台生态系统负责人: 与SaaS平台的4层应用API集成插图(1)

但为什么?

毕竟,我们生活在所谓的API经济中。几乎所有SaaS产品都有API,几乎所有主要的营销平台都有“应用程序市场”,客户可以从众多经过认证的技术合作伙伴中选择应用程序。

甚至还有一整类产品 – 集成平台即服务(iPaaS)工具 – 仅用于将不同的系统连接在一起。有些人让非技术人员很容易做到这一点,Gartner称他们的用户为“公民集成商”。其中一个比较受欢迎的人,Zapier,互相集成了1300多个不同的应用程序。

对于几乎所有流行的基于云的产品,都有一些现成的连接方式。那么为什么整合成为障碍呢?我们现在没有检查过那个盒子吗?

并非所有集成都是平等的

“X是否与Y集成?”是一个看似过于简单的是/否问题。在云端,答案几乎总是“是”。这有点像打电话给餐馆,询问他们是否将成分结合在一起。当然可以。但这顿饭有多美味?这项服务多么贴心?价格有多合理?

如果X与Y集成,后续问题应该准确地揭示整合的深度:

  • 这些产品一起工作的用例是什么?
  • 他们之间共享了哪些数据?它是双向的吗?
  • 它们之间的流程和用户体验是什么?
  • 管理它们的管理员有什么样的体验?

理想情况下,我们应该保持整合的标准是:什么使应用程序更好地结合在一起?

当您开始深入研究这些细节时,您会意识到集成的功能和用户体验可能会有很大差异。随着每个企业SaaS订阅的平均数量持续增长,由于深度集成不足而产生的“堆栈债务”可能会增加,从而拖累我们在我们组装的数字工具箱中的效率和效率。

那么我们如何在可能的整合范围内定量比较应用?

应用集成框架的四层

我想提出一个评估应用程序和云平台之间集成深度的框架,如下所示:

HubSpot平台生态系统负责人: 与SaaS平台的4层应用API集成插图(2)

该模型考虑了四个级别的集成,从底部开始,集成数据并逐步管理集成的应用程序集合:

  1. 数据:在系统之间传递字段,记录或其他信息包。这是云服务之间最常见的集成。每个系统如何与数据交互通常在此级别未定义。
  2. 工作流程:标准化或自动化人员和系统之间的数据和活动流。最常见的模式是在一个系统中触发一系列预定动作的事件。
  3. UI / UX:在平台的用户界面/用户体验中嵌入集成应用程序的元素 – 或整个应用程序本身。这为平台用户提供了对集成应用程序的可视性和交互能力,而无需在不同系统和界面之间不断切换。(参见“一个窗口测试”。)
  4. 治理:在平台生态系统中的所有已批准应用程序中建立和实施规则和标准。这使得用户更容易,更安全地采用和管理由不同供应商构建的应用程序,具有更高的一致性和控制力。

当我们沿着上图的y轴向上移动时,我们在整合中进入更高的认知水平。交换数据是一个相对死记硬的机械过程。工作流程包含动态行为。用户体验是我们理解组合产品并与之交互的方式。治理是我们集成的应用程序集合的管理方式。

综合系统作为数字语言的思考

HubSpot平台生态系统负责人: 与SaaS平台的4层应用API集成插图(3)

这是一个非技术性的比喻,用于区分这些不同层面的情况:

  • 数据 – >名词
  • 工作流程 – >动词
  • UI / UX – >语言
  • 治理 – >语法

数据是名词,我们使用的基本对象,工作流程是动词,我们采取的行动或与这些对象一起采取的行动。

UI / UX是与这些名词和动词进行通信的通用语言。集成的应用程序是否使用相同的语言,例如两个合作者都用英语交谈?或者它就像一座巴别塔,不同的系统以不同的方式展示事物 – 即使他们谈论的是相同的潜在对象和行为?

治理是语言的语法。任何人都可以用一种语言将单词串在一起,但是它们是否合并成一个有意义的正确句子?良好的语法保证了我们一定程度的连贯性,以避免gobbledygook。在平台上对应用程序的良好治理也是如此。

不同平台如何实现这四层,具有广泛的深度和优雅。浅层整合为您提供苏斯博士。深度整合为您提供莎士比亚。

积分的范围在每一层都会显着变化

让我们来看看应用程序在每个级别上的集成程度。

例如,考虑应用程序在数据层中的集成程度。轻量级数据集成可以简单地将数据从一个应用程序平台放到一个方向,而不用担心它在线下发生了什么。

数据是否覆盖现有记录或与现有记录冲突?它的格式是否正确?它是否与其他数据字段保持关系完整性?如果平台上的其他应用程序稍后更新相同的数据怎么办?原始应用会收到有关更改的通知吗?如果出现问题会怎样?它会忽略,提醒还是重试?

轻量级数据集成巧妙地回答:不知道,不关心。

另一方面,更丰富的数据集成可以双向同步数据,智能地解决冲突和冲突,强制执行数据质量和完整性,规范化身份等关键字段,在数据发生变化时通知相关应用,在出现问题时优雅地恢复等等。

丰富的数据集成对如何建模和维护信息发表了意见。

类似地,轻工作流集成可以通过响应于明确定义的事件自动触发简单动作来操作。访问者在目标网页上填写表单,然后将其注册到营销自动化平台的列表中。它很有用,但仅限于相对基本的if-This-then-that序列。

更丰富的工作流集成支持条件逻辑,根据事件的详细信息或事件发生的上下文触发不同的操作。更高级的工作流程可以结合自动和手动步骤,以处理需要人工审核或批准的请求。更复杂的工作流程可以包含自定义算法,甚至是AI功能,以动态路由和响应事件。

UI / UX级别的集成具有更大的差异。轻量级UI集成可能只在平台界面中具有只读位置,其中应用程序可能会显示有关其自身数据或活动的有限信息。它可能会提供一个返回应用程序的链接,但点击它只会打开一个新窗口,将用户放在一个完全不同的界面中,几乎没有上下文。

相比之下,更丰富的UI集成可以在平台界面中保留更多 – 甚至全部 – 用户体验。应用程序可以直接嵌入到平台中,因此用户无需跳转到不同的窗口即可与其进行交互。一个通用,灵活的UI“画布”允许第三方开发人员构建外观和感觉他们是平台原生的应用程序。

丰富的UI / UX集成的连续性可以使用户更容易采用应用程序,因为他们不必为每个应用程序学习新的界面。他们已经有了自己的方向,可以迅速将注意力集中在应用程序为他们提供的新功能上。

整合的治理层也有广泛的可能性。轻量级治理可能只会要求应用程序在列入平台的app目录之前进行简要审查。应用程序的销售和支持方式完全取决于每个应用程序开发人员。这是对生态系统的自由放任的方法。

更丰富的治理模型对要认证的应用程序提出了更严格的要求。应用程序可以通过平台的市场进行销售,从而简化了安装和计费。集中式订阅管理系统使用户可以更好地控制平台上的整个应用程序堆栈。该平台可以监控并强制遵守数据隐私法规,性能SLA和安全实践。它可以验证真实用户的应用评级和评论,以防止天体冲浪。

平台在其生态系统中管理应用程序所承担的责任越多,用户采用它们的风险就越小。由于信任可以说是任何平台生态系统中最有价值的资产,良好治理可以为所有利益相关者创造重要价值。

比较不同的平台集成

“X是否与Y结合?”显然应该比是/否答案更好。

使用刚刚描述的框架,我们现在可以比较这四个级别中每个级别的不同集成的范围。例如,考虑将网络研讨会应用程序与CRM平台连接的三个假设选项:

HubSpot平台生态系统负责人: 与SaaS平台的4层应用API集成插图(4)

选项A代表简单的iPaaS风格集成。在网络研讨会应用程序的注册页面上填写的表单会触发在CRM中创建的新联系人记录。如果联系人具有与现有记录相同的电子邮件地址,则CRM只会使用传入的新数据覆盖其他字段。它们之间没有UI / UX集成,也没有治理。如果在他们之间存在实际的iPaaS,CRM平台公司可能完全没有意识到网络研讨会应用程序供应商。警告集成商。

选项B说明了网络研讨会应用程序和CRM之间更直接的集成。数据经过双向交换,将注册人添加到CRM中,并增加了网络研讨会应用程序的与会者资料,以提供更加个性化的体验。用户可以在更新数据字段时确定网络研讨会应用程序或CRM是否先于。当注册人参加网络研讨会时,会在联系人的时间表中添加一条带有详细信息的注释 – 例如,观看的持续时间,提出的问题 – 以及指向录制的网络研讨会的链接。该网络研讨会应用程序已经过CRM平台公司的审核和认证,但仍然是独立购买的。

选项C描述了网络研讨会应用程序和CRM之间的深度集成。选项B更进一步。设置网络研讨会并推广它的整个过程在CRM平台的界面中完成,通过结构化的工作流程管理贡献和批准。在网络研讨会期间,微观事件可以自动触发序列,例如,参加者在中途停留,提交问题或在结束时对内容进行评级。根据其他用户的经过验证的评论,该网络研讨会应用程序是在平台市场上购买的,用于认证应用程序。该平台持续监控应用程序的性能以及对GDPR规则和请求的遵从性。

这三个选项提供了非常不同的集成体验。

如果您需要将两个独立的云服务连接在一起,那么选项A方法总比没有好,但是在用户的肩上留下了大部分工作和责任,以弄清楚如何管理集成。选项C方法减轻了用户的负担,提供了质量更平稳,更安全的集成。

选项A有点像胶带。选项C更像是乐高积木拼凑在一起。

Martech集成可以更好地发展

可以肯定的是,构建一个彼此深度集成的平台和应用程序需要双方开发人员进行更多的设计工作。但是,这种投资可以减少用户连接这些产品并让它们更好地协同工作所需的努力。当它在数千或数百万用户以及数百或数千个应用程序中成倍增加时,其价值呈指数级增长。

由于可以为营销人员 – 最终是他们的客户 – 提供真正的价值,我相信,在未来几年中,martech行业将看到应用程序和平台之间集成深度的重大改进。

整合不是黑白命题。但浅层集成与深层集成可以是夜晚和日常体验。

0

COMMENTS

WORDPRESS: 0
DISQUS: 0