什麼叫做好的應用整合？如果整合需求永遠一樣，那就只會有一種整合風格。但如同任何複雜的技術工程，應用整合牽涉一連串考量與後果，每一次整合機會都該把它們納入評估。

第一個準則：需不需要整合#

第一個準則就是整合本身。如果你能開發出一個不需要與任何其他應用程式協作的獨立應用程式，就能完全避開整合問題。

但現實是，即使最單純的企業也有多套應用程式，而且它們必須協同運作，才能為員工、夥伴與客戶提供一致的體驗。

其餘的主要決策準則#

• 應用耦合（application coupling）——即使是被整合的應用程式，也該把彼此的相依性壓到最低，好讓各自都能演進而不拖累別人。緊密耦合的應用程式對其他應用程式的運作方式做了大量假設；一旦對方改變、假設破裂，整合就跟著壞掉。整合介面應該具體到足以實作有用的功能，又通用到允許實作依需要改變。
• 整合的簡單度（integration simplicity）——把應用程式整合進企業時，開發者應設法把「對應用程式本身的修改」與「所需的整合程式碼」都降到最低。然而，要提供好的整合功能，通常仍免不了修改與新程式碼；而且對應用程式衝擊最小的作法，未必是對企業整合最好的作法。
• 整合技術（integration technology）——不同整合技術所需的專用軟硬體份量不一。這些專用工具可能昂貴、可能造成廠商鎖定，也增加開發者「必須搞懂如何使用工具」的負擔。
• 資料格式（data format）——被整合的應用程式必須對交換的資料格式有共識，否則就得有中介的轉換器來統一堅持不同格式的雙方。相關的議題是格式的演化與可擴充性——格式將來會怎麼變、變了又會如何影響各應用程式。
• 資料時效（data timeliness）——整合應該把「一方決定分享資料」到「其他方拿到資料」之間的時間縮到最短。資料應該頻繁地小量交換，而不是攢一大批不相關的項目再一次送出；共享資料一準備好就該通知各方。
• 資料還是功能（data or functionality）——被整合的應用程式可能不只想共享資料，還想共享功能，讓彼此能互相呼叫。遠端呼叫功能不容易做好；即使它看起來和呼叫本地功能一樣，運作方式卻大不相同，並對整合品質造成重大影響。
• 非同步性（asynchronicity）——電腦處理通常是同步的：一個程序在子程序執行時等待，並理所當然地假設子程序在它想呼叫時是可用的。但程序未必想等——它可能想非同步地啟動子程序，讓它在背景執行。這在整合情境中特別成立：遠端應用程式可能沒在跑、網路可能不通，來源應用程式或許只想把共享資料放出去、或記下一筆子程序呼叫請求，然後放心地去做別的事，相信遠端應用程式稍後會處理。

資料共享的延遲必須納入整合設計的考量：共享花的時間愈久，資料變陳舊的機會愈大，整合也愈複雜。

挑選與設計整合途徑時，需要權衡的準則不只一項。接下來的問題就變成：哪種整合途徑最能滿足哪些準則？