先定義要集中的是什麼
討論集中或分散時，團隊常把組織、技術與決策權混在一起。由中央平台團隊維護 API Gateway、訊息平台、身分驗證與監控，不代表所有介面都必須由中央團隊開發。相反地，讓各事業單位自行交付，也不等於可以任意選擇協定、建立重複的客戶主檔，或繞過資安要求。
真正需要回答的是四個問題：誰制定標準、誰提供共用能力、誰負責每一條整合流程，以及事故發生時誰必須恢復服務。集中治理適合處理跨企業且難以逆轉的決策；分散交付適合處理貼近領域、需要快速迭代的工作。如果這些責任沒有拆開，中央模式容易變成排隊中心，分散模式則容易累積無人治理的介面與資料流。
用耦合程度與風險判斷交付位置
不要只依公司規模選模式。每一類整合應根據資料敏感度、跨系統影響範圍、變更頻率、可逆性與所需領域知識決定由誰交付。付款、員工身分、客戶主檔與 ERP 核心交易通常需要較強的中央控制；行銷活動通知、部門工作流程或單一產品內部事件，則較適合由領域團隊自主處理。
實務上可以先把整合需求分成幾種治理等級，而不是要求所有專案走同一條流程：
- 企業核心整合：由中央團隊設計或共同交付，要求正式架構審查、資料契約、完整稽核與復原方案。
- 跨領域整合：由領域團隊開發，但必須採用共用平台、標準身分機制、版本規則與集中可觀測性。
- 領域內整合：允許團隊自助交付，只要符合安全基線、成本限制與平台支援範圍。
- 實驗性流程：可快速驗證，但需設定資料限制、有效期限，以及轉為正式服務前的審查條件。
聯邦模式必須建立可執行的平台契約
聯邦治理不是成立委員會後讓各團隊自行協調。中央平台團隊需要把規則做成容易採用的產品能力，例如核准的連接器、API 與事件範本、CI 檢查、密鑰管理、追蹤欄位、重試與死信處理，以及可直接複用的部署管線。若合規只能靠文件與人工提醒，交付壓力一高，標準就會被跳過。
平台契約也要界定支援責任。領域團隊應負責自身流程的商業邏輯、資料品質、相依系統協調與第一線故障判斷；平台團隊則負責共用執行環境、工具鏈、安全控制與平台級事件。每項整合都應有服務擁有者、原始碼位置、上下游清單、告警接收者及復原方式，避免正式上線後成為沒有主人的流程。
治理要放進交付路徑，而不是增加等待點
好的治理會讓低風險工作更快，而不是讓所有變更都等待架構會議。團隊可以用自動化規則檢查命名、契約相容性、敏感資料、權限範圍與部署設定；只有跨越風險門檻的變更才進入人工審查。審查也應聚焦於不可逆決策，例如新的主資料來源、跨境資料流、同步耦合或企業級技術選型，而不是逐行批准實作。
同時，中央團隊要管理平台的可用範圍。支援太多整合工具會增加監控、人才與災難復原負擔；限制過度又會迫使團隊建立影子方案。較穩健的做法是提供一條預設路徑、少數經核准的例外，以及清楚的例外期限。衡量治理成效時，應同時觀察交付等待時間、重複介面、失敗恢復、孤兒服務與標準採用情況，不能只看專案是否準時上線。
從可控邊界開始演進
企業不必一次決定永久的組織模型。可以先盤點現有 API、批次作業、檔案交換、訊息佇列與 SaaS 自動化，找出高風險共用能力和重複建設，再選擇一個跨領域流程試行。試行時要同時驗證自助交付、中央政策、自動化檢查、營運責任與事故處理，而不只是確認技術能否連通。
當領域團隊已具備穩定的工程與值班能力，可以逐步下放更多交付權；若契約管理、監控或責任歸屬仍不成熟，就應先保留較強的中央控制。最終目標不是追求純粹的集中或分散，而是讓決策落在最了解問題、也有能力承擔後果的團隊手上。