在競爭日益激烈的經(jīng)濟中，每個行業(yè)的組織都必須創(chuàng)新才能生存。麥肯錫 2020 年的一項調(diào)查發(fā)現(xiàn)，COVID-19 的影響大大加快了數(shù)字技術的采用。那些認為自己成功應對疫情的公司報告了其他公司沒有的技術能力——包括使用更先進的技術，以及更快的實驗和創(chuàng)新。

企業(yè)背負著維護成本高昂的陳舊技術（如企業(yè)服務總線 （ESB））時，轉型就很困難。

十五年前，ESB平臺承諾為企業(yè)提供一種革命性的方式，將應用程序相互連接并在軟件中編碼業(yè)務邏輯。企業(yè)將聘請高級開發(fā)人員編寫自定義代碼，通常使用簡單對象訪問協(xié)議 （SOAP） 將應用程序連接到跨越組織的共享通信總線，理論上可以到達每個業(yè)務關鍵型應用程序和資源。業(yè)務邏輯已編碼到這些連接中。

編碼很困難，但總線應該為應用程序和業(yè)務部門所依賴的數(shù)據(jù)提供安全、全面的通道。

如果出現(xiàn)了新的業(yè)務機會，出現(xiàn)了新的競爭對手，或者更改了管理法規(guī)，并且業(yè)務部門突然需要修改其業(yè)務邏輯作為響應，則 IT 組織將需要找到時間和預算來為 ESB 編寫、測試和部署新軟件。

隨著商業(yè)步伐從本世紀的第一個十年到第二個十年開始急劇加快，這種方法的不切實際性變得非常明顯。早在 2008 年，領先的 IT 分析公司 451 Group 就注意到 ESB 的鼎盛時期可能已經(jīng)過去。

今天，ESB 仍然存在。許多企業(yè)仍在使用它們?，F(xiàn)在的問題是，企業(yè)是否應該繼續(xù)甚至加深對這種舊的、復雜的集成方法的承諾，或者他們是否應該采用更快、更靈活的集成方法——這種方法更適合快速的開發(fā)周期、云架構和市場壓力，迫使幾乎每個企業(yè)探索和集成人工智能（AI）等新技術。

ESB 和上一代中間件如何拖慢企業(yè)速度

許多企業(yè)現(xiàn)在花費多達 70% 的 IT 預算來維護舊的、脆弱的、手工編碼的 ESB 集成和過時的應用程序，而不是采用可以改變其業(yè)務的新技術。

ESB 和其他 SOA 時代的中間件集成產(chǎn)品給企業(yè)帶來了以下問題：

使 ESB 保持最新

即使是最流行的 ESB 也不是集成平臺。相反，它們是全面數(shù)字現(xiàn)代化所需內(nèi)容的一小部分。一旦從單個供應商收集了構成 ESB 產(chǎn)品的所有產(chǎn)品的所有發(fā)行說明，此現(xiàn)代化組件的復雜性就變得顯而易見。印刷版發(fā)行說明，更不用說 API 指南和編程教程，需要花費大量時間閱讀 - 這是假設您知道您知道要使用的每個子產(chǎn)品的哪個版本。一家長期的 ESB 供應商目前提供了其旗艦產(chǎn)品的六個不同版本，并且必須對集成進行重大修改才能從一個版本移動到另一個版本。

IT 勞動力稀缺

正如某知名集成咨詢公司董事總經(jīng)理所說：“傳統(tǒng)集成中間件需要一小群開發(fā)人員、架構師和管理員的支持。這些人越來越難找到，因此隨著供應減少，成本也會上升。相比之下，具有現(xiàn)代集成平臺即服務 （iPaaS） 的集成項目通常只需要一兩個員工即可實施，而這些集成開發(fā)人員不需要專業(yè)技能。他們只需要了解他們的業(yè)務需求和工作流程。作為天然的副產(chǎn)品，iPaaS開發(fā)人員人才庫正在迅速增長。

前兩個挑戰(zhàn) - 過時的軟件版本和對高級人員的要求 - 相結合，使IT勞動力更加難以找到。您是否正在尋找熟悉 SOAP 協(xié)議和 2014 年末版本的 ESB 的高級 Java 程序員？祝你好運 – 投資 ESB 的組織越來越少，這使得 ESB 程序員更加稀有和昂貴。一家成功的集成咨詢公司報告稱，在過去幾年中，只有一個客戶選擇了 ESB 解決方案，而數(shù)十個客戶選擇投資基于 SaaS 的現(xiàn)代替代方案 iPaaS。

架構不兼容和手動流程

ESB 通常需要業(yè)務在與 ESB 的集成中嵌入業(yè)務邏輯。在復雜代碼中嵌入業(yè)務邏輯會使更改業(yè)務邏輯成為一項昂貴、耗時且晦澀難懂的任務。最好將業(yè)務邏輯保持在邊緣附近，以及邏輯影響其工作流的人員。

ESB 旨在支持面向服務的體系結構 （SOA） 服務的松散耦合，但為了權宜之計，許多集成工程師只是簡單地創(chuàng)建了緊密耦合的解決方案，即服務之間的硬編碼連接。（松散耦合可以輕松地以臨時方式將一個服務連接到另一個服務。緊密耦合可在應用程序之間創(chuàng)建定制的單一用途連接。維護和更新這些連接的難度在于，其中許多解決方案依賴于SOAP，而不是REST或JSON，這是當今SaaS產(chǎn)品所青睞的協(xié)議。

許多企業(yè)發(fā)現(xiàn)自己正在努力將依賴 REST 或 JSON 的新 SaaS 解決方案連接到其 ESB 上高度定制的 SOAP 服務。他們想知道是否有更簡單的方法將 SaaS 應用程序與遺留資源集成。

數(shù)環(huán)通iPaaS的優(yōu)勢

與ESB和其他上一代中間件產(chǎn)品相比，數(shù)環(huán)通是一個持續(xù)更新的，基于云的集成平臺，允許企業(yè)集成應用程序和服務，提高數(shù)據(jù)質量，并在需要的地方交付數(shù)據(jù)以支持數(shù)字化轉型。

與后來成為產(chǎn)品套件的ESB產(chǎn)品不同，數(shù)環(huán)通iPaaS是真正集成的：它是一個綜合平臺，包括多種互補功能，包括集成，主數(shù)據(jù)管理，API生命周期管理，EDI管理，數(shù)據(jù)編目和準備以及低代碼工作流自動化。

與ESB和其他舊的中間件集成產(chǎn)品相比，數(shù)環(huán)通iPaaS平臺具有重要的優(yōu)勢。這些優(yōu)勢包括：

可訪問的低代碼開發(fā)工具

數(shù)環(huán)通為構建應用程序提供了一個圖形化的拖放界面。它甚至在產(chǎn)品中提供機器學習指導的眾包建議，以簡化流行應用程序之間集成的構建。數(shù)環(huán)通使每個人都能實現(xiàn)集成。面向開發(fā)人員的開發(fā)人員集成和用于快速公民集成商集成的簡單拖放集成。

快速集成開發(fā)

得益于其低代碼界面和大量即用型連接器庫，數(shù)環(huán)通幫助IT組織構建集成的速度比ESB和其他集成技術快5倍。

創(chuàng)建集成、在需要時對其進行修改以及根據(jù)需要擴展集成都很容易。數(shù)環(huán)通是一種基于云的解決方案，允許集成和工作流程在需要的任何地方運行：在云中，在內(nèi)部數(shù)據(jù)中心或邊緣 - 即使在支持物聯(lián)網(wǎng)設備的邊緣網(wǎng)關中也是如此。

穩(wěn)健的邏輯架構

數(shù)環(huán)通不會強迫企業(yè)將業(yè)務邏輯嵌入到一個中心位置。相反，邏輯可以內(nèi)置到業(yè)務部門自己使用的邊緣集成和工作流中。如果出現(xiàn)商機并且業(yè)務邏輯需要更改，可以使用低代碼界面快速實現(xiàn)這些更改。

降低成本

數(shù)環(huán)通比傳統(tǒng)的中間件便宜。無需購買和維護硬件，自動和計劃更新使集成商能夠專注于集成，而不是修補本地更新。

降低風險

沒有了多個單獨發(fā)布的產(chǎn)品和晦澀難懂的界面的復雜性，數(shù)環(huán)通降低了構建集成，管理API和自動化工作流程的復雜性。降低這些風險意味著可以更快地部署業(yè)務創(chuàng)新。企業(yè)可以大膽行動，嘗試新產(chǎn)品和服務，確信他們的集成平臺支持修改、改進和規(guī)模的巨大變化，只要業(yè)務需要它。

從 ESB 負擔到無限可能

企業(yè)不必在ESB和其他舊技術上進行昂貴的投資作為技術債務，可以使用數(shù)環(huán)通iPaaS來追求他們最大膽，最具創(chuàng)新性的數(shù)字化轉型理念。