企業整合非常棘手。現在，如果我們必須整合兩個（或多個）系統，我們知道：我們要麼使用API​​，要麼使用某些訊息佇列。不幸的是，世界上許多系統不支援API整合。正如我們所說的，還有許多沒有API的東西。因此，當您不可避免地需要與它們整合時，以下是與遺留系統（或以遺留方式構建的非遺留系統）整合的七個模式。

• FTP上的檔案：一個應用程式將檔案（XML，CSV等）上載到FTP（或其他共享資源），而另一個應用程式通過計劃的作業讀取它們，解析它們並有選擇地傳送響應-在同一FTP或通過電子郵件。在整合方面，共享這樣的檔案肯定不是理想的選擇–您無法獲得請求的實時狀態，而其他方面則很棘手–版本控制，高可用性，身份驗證，安全性，可追溯性（稽核線索）。
• 共享資料庫： 共享同一個資料庫的兩個應用程式聽起來像是災難的祕訣，但是在野外看到它並不罕見。如果幸運的話，一個應用程式將是隻讀的。但是，打破資料庫結構的更改和安全性問題是主要問題。您只能使用這種型別的整合，因為您將資料庫直接暴露給了通常不希望執行的其他應用程式。
• 每日完整轉儲 ：一些組織不是共享活動資料庫，而是每天或每週對資料進行完整轉儲，並提供給另一方進行匯入。隨之而來的是明顯的資料隱私問題，因為除了下面提到的所有內容（版本控制，身份驗證等）之外，要對資料進行完整的轉儲（在某些情況下是在DVD或行動式HDD上）是不明智的。
• 搜尋 ：當應用程式沒有API時，仍然可以通過使用者介面從應用程式中提取資料或將資料推送到其中。使用Web應用程式，因為它們“表達為” HTML和HTTP更容易。對於桌面應用程式，螢幕抓取已成為一種選擇。所謂的RPA軟體（機器人過程自動化）依賴於所有型別的抓取來整合遺留系統。它非常脆弱，需要複雜的（有時是昂貴的）工具才能正確使用。更不用說安全方面了，這要求以非雜湊形式將憑據儲存在某處，以使抓取工具能夠登入。
• 電子郵件 ：當傳送或接收系統不支援其他形式的整合時，電子郵件將是最後的選擇。如果您可以通過連線郵箱來觸發某些操作，或者在傳送系統中發生某些事件後生成電子郵件，則可能只需要整合它們即可。顯然，電子郵件是一種非常糟糕的整合方式–它是非結構化的，可能由於多種原因而失敗，而不僅僅是軟體整合。如果您想獲得更多創造力，則可以附加結構化資料，但是如果兩端都可以支援相同格式，則可以擴充套件它們以支援適當的API。
• 介面卡 ：您可以開發一個自定義模組，該模組可以訪問基礎資料庫，但可以公開適當的API。這是一個幾乎可以接受的解決方案，因為您可以擁有獨立於原始應用程式的正確編寫的（某種）微服務，而其他系統則不知道它們是否與舊版軟體整合在一起。但是，在某些情況下要正確設定它很棘手，因為您必須很好地瞭解資料庫的狀態空間。只讀很容易，寫起來更難甚至幾乎不可能。
• 紙：在某些情況下，一個組織列印一些資料，然後另一個組織（或部門）接收紙質文件（通過郵件或其他方式）並將其輸入到他們的系統中。那裡存在昂貴的專案，這些專案旨在刪除紙張元件並引入實際的整合，因為基於紙張的輸入容易出錯且執行緩慢。對於基於紙張的步驟，一些合法的情況是您需要額外的安全保護，而紙張痕跡再加上有效隔紙的事實可能會為您提供幫助。但是即使如此，它也不應該是唯一的傳輸層。

如果要構建系統，請始終提供API。某些其他系統遲早必須與它整合。建立緊密的系統並在需要時延遲整合問題是不可持續的。假設它總是需要的。

花式ESB可能能夠使用上述方法之一快速修補問題並整合“不可整合”，但是嚴重依賴ESB則表明存在過多的舊版或質量低下的系統。這應該作為某些系統需要更換的指示。這說起來容易做起來難，因為遷移通常令人頭疼，但是在替換某些系統的原因列表中（如果無法升級並且您有能力這樣做，請考慮一下缺少API） ）。

但是簡單地擁有一個API也不會削減它。如果您不支援版本控制和向後相容的API，那麼您將處於更加脆弱的狀態，因為您將在進行過程中破壞現有的整合。

企業整合非常棘手。但是，與軟體中的許多其他事情一樣，最好在我們構建的應用程式中進行處理。如果我們正確地構建它們，事情會容易得多。否則，組織必須恢復到上面提到的傳統方法，並引入複雜性，脆弱性，安全性和隱私風險以及必須由日益不高興的人們所支援的低質量感覺。