上一篇先談了為什麼 ERP 還能運作，周邊卻需要新的整合方式。接下來，我想繼續整理一個很實際的問題：事情這麼多，到底要先做哪一件？

我的想法是，先把現況與做法放在同一張表裡。每個方案要改善什麼、會多出哪些工作，以及最後怎麼確認結果，都一起寫清楚，再來安排資源。

本篇名詞小筆記

• Gateway：API 閘道，集中處理系統入口的路由、認證、限流與追蹤。
• Adapter：轉接層，用來隔離新平台與舊 ERP 之間的協定、欄位及錯誤格式差異。
• RBAC：角色型存取控制（Role-Based Access Control），依使用者角色決定可以執行的功能。
• DLQ：死信佇列（Dead Letter Queue），用來暫時存放無法順利傳遞或處理的訊息。
• SLO：服務等級目標（Service Level Objective），用可量測數字定義服務預期達到的可靠度或效能。

今天要解決的問題

討論架構時，我會希望大家先對三件事有共識：為什麼現在要做、做到哪裡算完成，以及出了問題由誰處理。策略矩陣，就是把這些問題放在一起，讓業務、工程團隊與主管能夠一起看、一起討論。

下面用舊 ERP 串接周邊系統的情境來整理。這是一份示例，真正使用時，還是要換成自己專案盤點出來的現況與指標。

下面這張圖，把現況一路連到做法與指標，箭頭也標上主要風險。可以一列一列看，確認每個選擇都有對應的問題，後面也取得到驗證資料。

圖 Day 02-1：現況問題到驗證指標的對照。指標欄各留一個結果指標與一個健康指標，箭頭標籤為該策略的主要風險。

架構師視角：矩陣要能被核准者與使用單位讀懂

要安排資源的主管、要確認責任的架構師，以及之後接手維運的人，都需要用到這張表。所以我希望它不只工程師看得懂，像 P95、DLQ 這些名詞，也要補上它們和日常作業有什麼關係。

只看漂亮的數字，不夠踏實。所以指標一開始可以少一點：我會先放一個結果指標，看看事情有沒有改善；再放一個健康指標，看看改善的過程有沒有增加別人的負擔，兩邊一起看。

有一件事，我自己會特別提醒：討論很容易變成一份越列越長的工具清單。所以每個工具，都要找得到它要處理的問題；先把現況寫清楚，再選做法。

選好 Gateway 與 Adapter 之後，還要想移轉的順序。哪些介面先走新平台、哪些暫時保留，以及什麼情況需要退回去，都要寫進策略裡，時程才排得下去。

後面的人接手，要找得到當初的理由，以及資料是從哪裡來的。所以討論出來的結論與指標定義，再留到 ADR 或指標規格裡。

工程師視角：管理說法要對得上可量測的資料

表上的說法可以簡單，但背後的計算要清楚。我會把給主管看的描述，和工程上真正要量的資料對在一起：

表中的 3 秒是示例門檻，實際值要與使用單位確認，並記錄適用流程與量測範圍。確定門檻後，再以逾時請求比例與 P95 等數字檢視。同一份指標必須使用一致的樣本與統計方式，才有辦法比較。

少數請求可能因連線池耗盡，或 Adapter 等待 ERP 回應而明顯變慢，平均值卻未必反映出來。所以延遲不能只看平均值。指標變差時要能確認是哪一段需要處理，量測時也要分開記錄 Gateway、Adapter 與 ERP 的耗時。

寫指標之前，我還會多確認一步：資料從哪裡來？留多久？之後查不查得到？如果這些都還沒準備好，就先把資料收集列成工作，這個數字才有機會真的算出來。

之後每月或每個里程碑，再更新一次基準值、目前值、證據連結與剩下的風險。拿其中一個面向展開，可以這樣記錄：

• 面向：ERP 整合
• 基準值：YYYY-MM 盤點，直連 ERP 資料庫的系統 N 個、SOAP 介面 M 支
• 目前值：直連系統 N' 個（本期收斂 X 個）
• 證據連結：API inventory、Gateway 路由表、架構決策紀錄（ADR）編號
• 未結風險：A 系統的報表查詢尚未改走 Gateway，預計 YYYY-MM 前處理

若目前拿不到基準值，就先把盤點清單、API inventory 與 Log 集中收集列為交付項目，指派負責人與完成期限。量測準備可以在平台建置前開始。

策略取捨與限制

矩陣本身也是需要維護的產出，採用前應先確認以下取捨：

指標也會影響大家做事的方式。假如只要求結果達標，背後卻多了很多人工補救，這份改善就需要再想一想。這也是我想保留健康指標的原因。

目標可以隨業務條件調整，只是調整的原因、影響與確認人也要留下來。這樣再回頭比較，就知道中間發生過什麼變化。

驗證方式與衡量指標

要確認狀態是否真的改變，矩陣的每一列都要能連到可查閱的證據：

若既有品質流程已保留相關紀錄，可以直接建立對應關係，減少重複整理。初期不必補齊全部項目，但每一列都應標明目前狀態、負責人與預計完成時間。

今天先整理到這裡

整理完這張矩陣，我希望每個方案都能說得清楚：為什麼做、要承擔什麼，以及怎麼知道做得有沒有效。下一篇，再一起把量測方式與成功指標整理得更具體。

參考資料

1. Microsoft Azure Architecture Center, Strangler Fig pattern，查閱日期：2026-09-15。
2. Google, Site Reliability Engineering, Service Level Objectives，查閱日期：2026-09-15。