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

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

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

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

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

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

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

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

集成的四个阶段

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

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

• 直接集成；

• 定制的管道；

• API/连接器；

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

下一阶段（定制管道ÿ