企业集成非常棘手。现在，如果我们必须集成两个（或多个）系统，我们知道：我们要么使用API，要么使用某些消息队列。不幸的是，世界上许多系统不支持API集成。正如我们所说的，还有许多没有API的东西。因此，当您不可避免地需要与它们集成时，以下是与遗留系统（或以遗留方式构建的非遗留系统）集成的七个模式。
- FTP上的文件：一个应用程序将文件（XML，CSV等）上载到FTP（或其他共享资源），而另一个应用程序通过计划的作业读取它们，解析它们并有选择地发送响应-在同一FTP或通过电子邮件。在集成方面，共享这样的文件肯定不是理想的选择–您无法获得请求的实时状态，而其他方面则很棘手–版本控制，高可用性，身份验证，安全性，可追溯性（审核线索）。
- 共享数据库： 共享同一个数据库的两个应用程序听起来像是灾难的秘诀，但是在野外看到它并不罕见。如果幸运的话，一个应用程序将是只读的。但是，打破数据库结构的更改和安全性问题是主要问题。您只能使用这种类型的集成，因为您将数据库直接暴露给了通常不希望执行的其他应用程序。
- 每日完整转储 ：一些组织不是共享活动数据库，而是每天或每周对数据进行完整转储，并提供给另一方进行导入。随之而来的是明显的数据隐私问题，因为除了下面提到的所有内容（版本控制，身份验证等）之外，要对数据进行完整的转储（在某些情况下是在DVD或便携式HDD上）是不明智的。
- 搜寻 ：当应用程序没有API时，仍然可以通过用户界面从应用程序中提取数据或将数据推送到其中。使用Web应用程序，因为它们“表达为” HTML和HTTP更容易。对于桌面应用程序，屏幕抓取已成为一种选择。所谓的RPA软件（机器人过程自动化）依赖于所有类型的抓取来集成遗留系统。它非常脆弱，需要复杂的（有时是昂贵的）工具才能正确使用。更不用说安全方面了，这要求以非哈希形式将凭据存储在某处，以使抓取工具能够登录。
- 电子邮件 ：当发送或接收系统不支持其他形式的集成时，电子邮件将是最后的选择。如果您可以通过连接邮箱来触发某些操作，或者在发送系统中发生某些事件后生成电子邮件，则可能只需要集成它们即可。显然，电子邮件是一种非常糟糕的集成方式–它是非结构化的，可能由于多种原因而失败，而不仅仅是软件集成。如果您想获得更多创造力，则可以附加结构化数据，但是如果两端都可以支持相同格式，则可以扩展它们以支持适当的API。
- 适配器 ：您可以开发一个自定义模块，该模块可以访问基础数据库，但可以公开适当的API。这是一个几乎可以接受的解决方案，因为您可以拥有独立于原始应用程序的正确编写的（某种）微服务，而其他系统则不知道它们是否与旧版软件集成在一起。但是，在某些情况下要正确设置它很棘手，因为您必须很好地了解数据库的状态空间。只读很容易，写起来更难甚至几乎不可能。
- 纸：在某些情况下，一个组织打印一些数据，然后另一个组织（或部门）接收纸质文档（通过邮件或其他方式）并将其输入到他们的系统中。那里存在昂贵的项目，这些项目旨在删除纸张组件并引入实际的集成，因为基于纸张的输入容易出错且运行缓慢。对于基于纸张的步骤，一些合法的情况是您需要额外的安全保护，而纸张痕迹再加上有效隔纸的事实可能会为您提供帮助。但是即使如此，它也不应该是唯一的传输层。
如果要构建系统，请始终提供API。某些其他系统迟早必须与它集成。建立紧密的系统并在需要时延迟集成问题是不可持续的。假设它总是需要的。
花式ESB可能能够使用上述方法之一快速修补问题并集成“不可集成”，但是严重依赖ESB则表明存在过多的旧版或质量低下的系统。这应该作为某些系统需要更换的指示。这说起来容易做起来难，因为迁移通常令人头疼，但是在替换某些系统的原因列表中（如果无法升级并且您有能力这样做，请考虑一下缺少API） ）。
但是简单地拥有一个API也不会削减它。如果您不支持版本控制和向后兼容的API，那么您将处于更加脆弱的状态，因为您将在进行过程中破坏现有的集成。
企业集成非常棘手。但是，与软件中的许多其他事情一样，最好在我们构建的应用程序中进行处理。如果我们正确地构建它们，事情会容易得多。否则，组织必须恢复到上面提到的传统方法，并引入复杂性，脆弱性，安全性和隐私风险以及必须由日益不高兴的人们所支持的低质量感觉。