如何通过业务集成中心简化系统集成

如果你问一个小学生如何解决代数问题，他们会告诉你从化简开始。对于大多数数据集成问题，我们从一开始就让数据变得太过复杂——我们使用了基于标准的 XML 格式，这看起来似乎很奇怪。

来自Merge.dev、Codat.io、Stedi.com等公司的新一代集成工具与这种趋势背道而驰，我非常喜欢他们的解决方案。这些集成工具简化了大多数常见业务数据对象（供应商、客户、员工、票据等）的数据模型，并提供了从流行的软件包（或 EDI、电子数据交换、Stedi 的格式）中获取数据的连接器，并将其转换为简化的模型。

这将使你的集成工作变得更容易，因为你不需要了解每个系统的特性，可以专注于将数据从一种简化格式转换为另一种格式。

这种新型集成公司与之前的公司之间的关键区别在于，它们不仅仅是从一个系统到另一个系统的管道，而实际上是以一种简化的格式转换和存储你的数据。你可以不将其视为管道，而将其视为一个中心，它将数据从源系统同步到简化数据中心，再从简化数据中心同步到目标系统。

这种“枢纽”极大地改变了集成的经济模式。如果我们只是将其与中心辐式机场模型和点对点机场模型之间的效率效益差异作为类比，实际上低估了中心辐式集成方法的优势。

Merge 和 Codat 称自己为通用或统一的 API，而 Stedi 将自己视为构建通用 API 的工具，但为了强调他们的解决方案和这些解决方案所产生的效率之间的联系，我将在本文中称它们为业务集成中心。

本文研究了业务集成中心的出现、这种解决方案的好处和风险，并简要介绍了其中三个案例，并评估了这种解决方案的竞争和未来。

集成的四个阶段

我认为我们目前正处于集成工具发展的第四个阶段。

这四个阶段（彼此之间存在重叠）是：

• 直接集成；

• 定制的管道；

• API/连接器；

• 转换。在第一阶段（直接集成），直接通过编写针对数据库的 SQL 查询来连接内部系统，并使用 XML 或文本分隔标准（如 cXML、X12 EDI 和 OASIS）与客户和供应商系统集成。集成项目只适用于具有大量事务和大量持续手动工作的系统。

下一阶段（定制管道）见证了 Snaplogic、Jitterbit、Talend 等公司的崛起，这些公司通过编写定制的集成管道从遗留系统中推送和提取数据。

从这里开始，出现了两条平行的路径，它们都与 API 有关。一方面，企业开始使用 Mulesoft 等软件在托管系统上公开 API 端点。另一方面，Zapier、Tray.io 和 n8n.io 等公司开始将 API 端点放在 SaaS 软件上。

我们现在处于转换阶段。在这个阶段，参与前几个阶段集成的公司正在构建它们的转换能力，以加速集成。认证和连接器不再是集成系统中最耗时的部分——最耗时的部分是将数据从一个系统转换为适合放入另一个系统的格式。Tray.io 和 n8n.io 正在构建非常好的数据转换能力，使得连接两个系统的速度比以往任何时候都要快。

业务集成中心在这方面更进一步，对于许多集成任务，你不需要进行任何数据转换，即使不得不自己进行转换，也只需要从一个简化的数据格式开始，并将其转换为另一个简化的格式。

Stedi.com 可能是最好的例子。你可能已经猜到，Stedi 是一个 EDI 数据转换系统。他们构建了一个工具，可以将 EDI 数据转换成 JSON 文档，然后再转换回来。这是一个相当令人难以置信的壮举，因为 EDI 数据格式看起来非常枯燥，而且处理起来非常困难。因此，与其浪费时间学习每种 EDI 文档中的片段是怎么回事，还不如使用它们的工具或你喜欢的编程语言开始编写转换。

“在 Stedi，我们为开发人员提供了定义他们自己模式的工具，这些模式符合（有时也不符合）各种 EDI 标准。例如，Stedi Guides帮助开发人员定义他们自己对 X12 EDI 810（票据）的‘看法’，并基于该结构构建他们自己的集成。现在，用户可以构建系统，以相同的 EDI 标准与几乎任何贸易伙伴通信，而不管他们内部使用的是什么系统或 API。” ——David Kanter，Stedi.com客户运营

Merge.dev 和 Codat 正在解决问题的不同部分。他们为大多数通用财务文档定义了 JSON 模式，并建立了连接到不同源系统的工作流。完成这些工作后，他们现在正在构建自己的连接器，以覆盖尽可能多的系统。

好处

使用业务集成中心的最大好处是，一旦将事务系统连接到集成中心，与多个系统集成就变得很简单了。如果你将 Netsuite 作为财务套件，将 Salesforce 作为 CRM，将 BambooHR 作为人力资源系统，那么你可以将所有这些连接到你的集成中心，并轻松地在它们之间交换数据。当然，所有这些都可以通过像 Tray.io 或 n8n.io 这样的点对点集成工具来实现，但将所有数据存储成通用的简化模型会使这一切变得更加容易。

为了更好地理解这些好处，我们以中心辐式机场模型的经济效益作为类比。航空公司在很大程度上是按照中心枢纽的方式组织起来的。当你从田纳西州的纳什维尔飞往新墨西哥州的阿尔伯克基，你无法乘坐直飞航班，你必须经过达拉斯枢纽（美国航空公司）或丹佛枢纽（联合航空公司）。这是因为从纳什维尔到阿尔伯克基的客流量不足，无法使航空公司在经济方面无法直接建立和运营这条航线。但是，他们可以把所有从许多城市前往阿尔伯克基的乘客带到枢纽，然后就可以很容易地在枢纽和阿尔伯克基之间每天提供几次航班。系统集成的原理与之相同。在系统之间建立良好的管道是非常耗时的，使用中心枢纽总会带来经济优效益势。

如果说集成中心和机场中心枢纽之间的类比存在突破点，那应该表现在集成中心的优势方面。当你乘坐飞机时，你总是希望选择中途停留次数最少的航线。而在系统集成的世界里，这个并不重要。是直接将数据从源格式转换为目标格式，还是在两者之间使用简化表示，这通常是个个人喜好问题。作为一个做过大量集成的人，我发现将数据从源格式转换为更简单的格式，然后再从更简单的格式转换为目标格式比直接进行转换更容易。

集成两个系统最困难的部分是映射和转换数据。解决这个问题的关键是标准化，这就是为什么我们花费数年时间在一些最复杂的财务数据领域（会计和商业）改进我们的数据模型。这是我们的用户能够真正感知到我们所提供的价值和质量的地方。—— Dave Hoare，Codat 公司首席技术官兼联合创始人

风险

但这些好处也伴随着两个重大风险：

1. 你所有的数据现在都在一个地方，它们安全吗？

2. 你的数据存储成简化的模型，这些能够满足你的需要吗？如果大中型企业开始使用业务集成中心，它们需要确保数据治理和安全性。以下是 Merge.dev 对这个问题的看法：

“保持数据安全不是一件简单的事情。我们有义务向客户证明，我们不仅保护了他们的数据，而且遵守了世界各地的各种法规。Merge 对静止和传输中的数据进行加密，然后使用存储在外部服务中的密钥再次加密。我们还将欧盟和美国的数据存储在完全隔离的环境中，以确保我们的客户能够遵守 GDPR。”—— Gil Feig，Merge.dev联合创始人

竞争

集成中心解决方案很有意义，但这并不意味着早期玩家最终会成为赢家。他们将面临以下类型公司的竞争。

1. 现有集成公司，如 tray.io 和 n8n.io。

2. 微软 Azure、谷歌云平台、亚马逊云科技等云平台。

3. Snowflake 等数据湖公司；

4. RPA 公司，如 AutomationAnywhere 和 UIPath。

这是一个赢家通吃的类别吗

我们不认为集成中心（每个企业都必须成为集成中心的一部分）会是一个赢家通吃的类别。当然，在每个集成中心中都有网络效应在起作用，但它们很弱。例如，如果你的几个贸易伙伴使用特定的集成中心，并且你使用了相同的集成中心，那么与他们集成就会更容易。但集成中心的竞争对手之间也会有相通的路径，所以这可能不会有太大影响。

例如，我们可以很容易地想象未来美国的一家五金连锁店采用 Stedi 作为他们的 EDI 平台。如果供应商 1 使用 Codat 集成中心，他们可以将连接 Codat 到 Stedi。如果供应商 2 使用 Merge.dev 集成中心，他们也可以很容易地连接到 Stedi。而且，如果供应商 1 和供应商 2 想要一起做一些联合营销，他们将能够在 Codat 和 Merge.dev 之间同步他们的 CRM 数据。

来自现有集成供应商的竞争

现有的集成公司，如 Tray.io 和 n8n.io 将是集成中心要面对的第一批竞争对手（尽管集成中心处理的本质上只是 Tray 或 n8n.io 的一个子集）。这几乎是一个哲学问题，是在不同的系统之间进行点对点集成更好，还是将数据同步到集成中心并利用它们的现有连接更好？

云平台竞争对手

每一家 SaaS 公司都需要评估一下，如果大型云服务提供商（微软 Azure、谷歌云平台和亚马逊云科技）取得成功，它们会有何反应。

除了微软可能有点例外，我们不认为这三大云平台会在这个领域扮演重要角色。对于它们来说，这些位于技术栈的上层，所以它们服务不好，这一点可以通过 Azure 的 Dataverse 和亚马逊云科技的 Appflow 看出来。

微软 Dataverse 是一个位于 SQL Server 数据库之上的层，它定义了常用的表，如供应商、客户、票据和账单。当它第一次出现时，我非常兴奋，但实际上，它并不比实际编写 SQL 查询容易多少。

亚马逊云科技的 Appflow 是 AWS 集成服务的起点。看起来它将成为 SaaS 系统之间非常健壮的管道，但它没有将任何模式强加到集成上，而是将其留给了最终用户。这对于某些场景来说很好，但对于集成中心应用场景来说却不是。

GCP 的解决方案让我感到困惑（Trifacta、Cloud Composer、Workflow、AA 等），所以我把它留给读者来解释给我听:)

Snowflake

Snowflake 公司在打造真正的集成中心方面处于非常有利的位置。直到最近，Snowflake 公司还在专注于分析数据而不是运营数据，但他们最近发布的 Unistore 公告表明，他们正在向事务性存储解决方案迈进。Snowflake 最大的挑战是专注。在吮吸了多年大型企业的乳汁后，他们会考虑销售面向中小企业的产品吗？

RPA

RPA（机器人过程自动化）软件在过去的十年中发生了很大的变化。RPA 不仅仅是一种使用用户界面让数据出入遗留系统的方法，它现在也是一种完全成熟的集成工具。

为了成为一个可靠的业务集成中心，他们有一些有利的因素。首先，他们有大型的开发者社区，每天与标准的业务数据对象进行交互，如客户、供应商、票据、工单等。这个开发社区对数据从一种形式转换到另一种形式的过程有着深刻的理解。其次，RPA 公司的市场提供了一种方式来分发由社区开发的连接器，甚至是为社区构建连接器提供补偿。

但是，与 Snowflake 一样，销售和分发可能会是一个问题。对于 RPA 销售团队来说，与集成中心展开竞争可能需要迈出非常大的一步。

挑战

除了上面提到的风险之外，最大的挑战在于如何在易用性和处理大多数集成场景的复杂性之间游走。任何看过“Hello World”教程的人都知道，技术可能看起来很简单，但随着你不断深入，会很快变得非常难。我对集成中心的建议是——让简单的事情变简单，并为更专业的用户提供更多功能，让他们为你完成困难的事情。

一个很好的例子就是 Merge.dev 最近宣布的直通功能。如果你的会计数据位于 Merge.dev 中，并且需要连接到 Merge.dev 的财务系统，但你需要的端点尚未为 Merge.dev 做好配置，你仍然可以使用它们的身份验证功能，但要带上自己的连接器。

未来

作为一种集成模式，集成中心的未来看起来很光明。对于大多数集成任务（在某些情况下进行立即集成，在不可能进行立即集成时进行简化转换）来说，以简化的格式存储数据的好处是不可忽视的。渐渐地，集成工作将是在集成中心之间进行，而不是在软件系统之间。

时间会告诉我们当前这些集成中心最终是否会取得成功，但使用业务集成中心的经济效益肯定会显现出来。

作者简介：

Doug Hudgeon 是 Managed Functions 的首席执行官。这是一家集成公司，专门帮助 SaaS 公司扩展集成能力。Managed Functions 是解决方案无关的，它会根据客户的需求为每个作业选择最好的工具。他也是 Manning《商业机器学习》一书的合著者。

原文链接：

Business Systems Integration is About to Get a Whole Lot Easier

相关阅读：

InfoQ 2022 年趋势报告：DevOps 与云计算篇