一家企業通常有數百甚至數千套應用程式——有自製的、外購的、遺留系統，或三者的混合——跑在多層架構、多種作業系統平台上。一家企業同時有 30 個網站、三套 SAP 實例、以及數不清的部門級系統，是很常見的事。

我們很容易想問：企業怎麼會把自己搞成這副義大利麵的樣子？這種架構的 CIO 難道不該被開除嗎？但和多數情況一樣，事出有因。

為什麼會演變成這樣#

第一，寫商業應用程式本來就難。 要用單一一套大應用程式跑完整個企業，幾乎不可能。ERP 廠商在打造「史上最大商業應用」這件事上確實有些成績，但現實是：即使 SAP、Oracle、Peoplesoft 這些重量級玩家，也只覆蓋了典型企業所需商業功能的一小部分。

一個明顯的佐證是：ERP 系統本身就是今日企業中最熱門的整合接點之一。

第二，把商業功能分散到多套應用程式，換來的是選擇的彈性。 企業可以挑「最好的」會計套件、「最好的」客戶關係管理系統，或最貼合自身需求的訂單處理系統。企業應用的一站式採購通常不是 IT 組織想要的，考量到個別業務需求的數量，也做不到。

廠商也學會迎合這種偏好，圍繞特定核心功能推出聚焦型應用。然而「不斷替現有套件加新功能」的衝動，造成套裝應用之間的功能外溢：許多帳務系統開始納入客服與會計功能，客服軟體廠商也順手實作了爭議處理、調整這類簡單帳務功能。

在系統之間畫出清楚的功能邊界很難。舉個例子：客戶對帳單提出爭議，這算客服功能還是帳務功能？

使用者不在乎系統邊界#

客戶、商業夥伴與內部使用者在與企業互動時，通常不會想到系統邊界。他們執行的是商業功能，不管這功能橫跨幾套內部系統。

• 一位客戶打電話來改地址，順便問上一筆款項是否收到——在許多企業裡，這個簡單請求就橫跨客服與帳務兩套系統。
• 一位客戶下新訂單，可能需要多套系統協調：驗證客戶 ID、確認客戶信用狀況良好、檢查庫存、履行訂單、取得運費報價、計算銷售稅、寄出帳單……這個流程輕易就橫跨五、六套不同系統。

從客戶的角度看，那只是一筆交易。

要支援跨應用程式的共同商業流程與資料共享，這些應用程式就必須被整合起來——而應用整合必須提供高效、可靠且安全的資料交換。