真正整合是你無法透過購買低程式碼工具實現的 - Byars

簡化介面的關鍵是接受更復雜的實現。
簡化整合的程式碼當然是一項崇高的努力，整合工具可以提供幫助，但還不能足以在功能上構建乾淨的介面。
重要的是，判斷一個介面是否容易使用的唯一有效判斷是它的實際使用者。
Google 本來可以要求我們提供更多資訊以使他們的搜尋實施更容易——例如，地理、新近度和流行度資訊——但他們只提供了一個文字框來輸入搜尋，並且必須學習如何將這些因素應用到他們的演算法。
同樣的問題也適用於 API 設計（我將其廣泛定義為包括同步呼叫和非同步事件）。
乾淨的介面隱藏了實現細節，整合上下文中的這些實現細節之一是程式語言的選擇。
我們需要轉變思維方式，從思考如何使用我們的工具解決整合問題，轉而思考如何構建正確的介面以最大限度地提高敏捷性。
 

使用通用程式語言來管理介面演變
像Java這樣通用程式語言的生態系統發展迅速：測試工具、IDE、可觀察性工具和更好的抽象的進步受益於此類語言所執行社群的龐大規模。而低程式碼平臺的生態系統要小得多，限制了以相同速度推進的能力，並且平臺約束將幾乎可以肯定，開發人員必須使用供應商提供的工具鏈來編寫和測試程式碼。這自然會對供應鏈和靜態分析掃描等安全問題產生影響。這種工具在 Java 開源庫等方面受到了很多關注，但在低程式碼世界的圍牆花園中卻很少受到關注。
低程式碼工具不足以處理通用程式語言可以處理的相同型別的複雜性：
我的一位同事描述了一個有爭議的環境，他正在處理使用 TIBCO BusinessWorks（一種著名的商業整合工具）的任務。他向 TIBCO 團隊發起挑戰：他會派他最好的 Java/Spring 開發人員建立與另一個 COTS 產品的 Web 服務（在 Apache Axis 中編碼的 SOAP 介面）的整合，並且他們可以讓他們最好的 TIBCO 開發人員做同樣的事情. Java 開發人員在午餐前完成了一個工作實現。TIBCO 團隊發現該工具不支援 COTS 產品使用的舊版本 Apache Axis，大型企業中常見的遺留複雜性型別。遵循授權意味著回到供應商那裡並更改他們的路線圖或新增通用程式語言的擴充套件。Fred Brooks 在他的著名著作中稱這種擴充套件為“偶然的複雜性”。
然而，比透過商業工具執行所有整合所需的偶然複雜性更令人擔憂的是，這樣的任務將重點放在實現而不是介面、系統而不是功能上。
 

整合工具在實施方面“思考”
由於跨 IT 系統範圍解鎖資料和功能的複雜性，整合工具被建立並在今天繼續蓬勃發展。例如，您的實際客戶主資料可能存在於 SAP 中，但客戶生命週期的早期部分存在於 Siebel CRM 中。IBM 大型機系統仍然為一些客戶處理核心計費；其他人的 Oracle ERP。現在，該企業希望用 Salesforce 取代 Siebel。引入新產品的業務團隊自然明白需要一些時間才能獲得正確的配置以使其適應他們的銷售流程，但他們最不想要的就是被告知冗長的 IT 時間表只是為了整理系統之間的粘合劑。
應用程式整合的早期是企業服務匯流排 (ESB)，它將系統連線作為可重用元件與編排和路由分離。您可以在簡化的檢視中看到這種分離 Mulesoft 的 ESB，之所以如此命名是因為它旨在消除整合的“驢工作”：
由於業界渴望在匯流排上擁有企業範圍的規範格式，因此在 ESB 世界中有一些自然的錯誤開始，但所有這些都共享介面卡的概念，用於匯流排的輸入和輸出 - 系統被整合。在愉快的路徑中，您可以使用像 BPEL 這樣​​的語言來描述您的整合，它可以提供圖形設計調色盤和源圖同構，就像它在 XML 中描述的過程一樣。
該行業在很大程度上已從 ESB 轉移，但您可以在現代 API 平臺中看到它們的傳統。例如，看一下 Mulesoft 的三層 API 架構。
Mulesoft 銷售 API 管理平臺和用於構建 API 的低程式碼執行時。您可以而且經常應該購買中介軟體基礎設施，完全有可能將 API 閘道器與執行時分離，代理到以通用程式語言構建的 API。如果你這樣做了，問題就出現了：如果你在 Mulesoft 執行時之外構建了所有的 API，你會使用 Mulesoft 的三層架構嗎？
我對 Mulesoft 模型的主要批評是對實現問題的強調：因為我認為這導致我們將整合視為一種戰術問題。（整合應該是戰略問題）