識別交付策略（Identify a Delivery Strategy）協助團隊先說清楚解決方案的來源，讓架構探索、範圍估算、預算討論與治理判斷具備共同基礎。
交付方式不同，團隊要面對的技術債、整合風險、維運責任與驗證成本也會隨之改變。
團隊可以先比較五種交付策略，再依既有資產、團隊技能、支援責任、架構風險與探索成本縮小選擇範圍。不同策略會影響後續的驗證安排、部署準備與治理溝通方式，因此需要在早期先形成初步判斷。
策略選定後，團隊應將判斷寫入架構決策紀錄（Architecture Decision Record, ADR）與產品待辦清單（Product Backlog），並安排必要的架構技術試驗（Spike）、概念驗證（Proof of Concept, PoC）或整合驗證。
當新的證據出現時，團隊也需要重新檢查原本的選擇，確認交付策略仍符合目前的風險、成本與交付目標。
識別交付策略（Identify a Delivery Strategy）在架構策略中的位置
Disciplined Agile（DA）的識別架構策略
在 Disciplined Agile（DA）中，識別架構策略（Identify Architecture Strategy）關注的是團隊準備採用什麼架構方向產出解決方案。
這項目標要求團隊先做出足夠的前期判斷，並保留後續細節演進的空間，讓開發工作能朝合理方向推進。
專案剛開始時，利害關係人（Stakeholders）會同時關心功能清單與建置方式。他們需要知道團隊準備如何建置解決方案、需要多少預算、可能花多少時間，以及哪些技術風險需要先處理。
若這些問題留到建構階段才處理，團隊可能已經投入大量開發成本，後續調整空間也會受到限制。
DA 將架構策略放在早期討論，是為了讓團隊用輕量方式看見關鍵風險。例如先畫出主要系統邊界、盤點既有資產、確認重要整合點，或透過架構技術試驗（Spike）驗證尚未確定的技術選擇。
這些工作不需要把每個細節都準備完成，重點是讓團隊知道哪些假設需要驗證，哪些決定會影響後續交付。
交付策略先決定解決方案來源
交付策略和部署策略處理不同層次的問題。交付策略關注解決方案來源與建置方式。部署策略關注成果完成後如何發布到正式環境、如何回滾、如何監控，以及如何維持服務穩定。
識別交付策略（Identify a Delivery Strategy）處理的是更早期的判斷：團隊準備從哪裡取得解決方案。
因此，交付策略會先把可能路徑攤開，團隊需要判斷哪條路徑較適合當前情境：既有資產延伸、全新客製建置、業務端自建工具、套裝軟體設定，或套裝軟體客製化。
這些選項會直接改變架構工作的內容。
延伸既有系統時，團隊需要理解舊系統、技術債與整合限制。
從零建置時，團隊需要投入較多架構探索，因為技術與需求假設都需要驗證。設定商用套裝軟體時，工作重點會轉向流程適配、資料整合與供應商限制。
交付策略先被釐清後，後續的架構討論才會有明確方向。
交付策略影響估算、範圍與治理對話
交付策略也會影響估算、範圍與治理對話。
透過交付策略，團隊才能回答利害關係人關心的重要問題，包含解決方案準備如何建置、需要多少資金，以及大約需要多長時間。交付策略不同，這些問題得到的答案也會不同。
若團隊選擇延伸既有系統，估算需要納入既有程式碼理解、資料整合、回歸測試與技術債處理。
若團隊選擇從零建置，估算需要納入架構探索、概念驗證（Proof of Concept, PoC）、早期風險驗證與新技術學習成本。
若團隊選擇設定或擴充商用套裝軟體，討論重點會轉向授權費、供應商支援、升級路徑、客製化限制與後續維護責任。
這些資訊也會回頭影響範圍規劃，架構能提示需求討論中的限制，也能協助團隊提出較合適的選項。
例如某個需求必須大幅修改套裝軟體，團隊就需要重新評估客製化是否值得投入。某個新功能可以透過既有系統小幅延伸完成，團隊就能把建置計畫收斂在既有系統調整上。
識別交付策略的價值，在於讓團隊把「要做什麼」和「打算怎麼做出來」放在同一張桌上討論。
五種識別交付策略（Identify a Delivery Strategy）選項
延伸既有解決方案（Extend Existing Solution）
延伸既有解決方案是 Disciplined Agile（DA）推薦優先選擇的交付策略。當組織已經有可用系統，或有一批舊系統資產可以整合時，團隊可以選擇在既有基礎上延伸、調整或客製化。
這種做法適合需求與現有流程有清楚關聯的情境，例如在既有客服系統加入通知功能，或在內部簽核系統增加新的審核條件。
這個選項的好處，是團隊可以沿用既有系統基礎。若原本就有熟悉系統的人，需求理解、程式修改與部署流程都能承接既有經驗。
架構建模的投入也能降低，因為核心結構已經存在，團隊只需要確認新需求會接到哪個模組、資料如何流動，以及是否會影響既有功能。
延伸既有系統也會把舊限制一起帶進來。既有技術可能已經老舊，測試覆蓋不足，部署流程也可能依賴少數人。
若系統已經累積技術債，新功能看似只是小幅延伸，實際修改時可能牽動資料庫、權限、批次作業或外部系統。
選擇這條路之前，團隊需要先看清楚既有資產能否支撐新的交付目標。
IT 團隊從零建置（Build from Scratch, IT）
IT 團隊從零建置，是指由開發團隊為利害關係人打造客製化解決方案。
當需求非常特殊、既有系統無法支撐，或組織需要掌握完整技術控制權時，這個選項會具有吸引力。團隊可以依照產品目標設計資料模型、系統邊界、使用者流程與部署方式。
從零建置的彈性最高，也代表不確定性最高。需求是否已被理解、技術選型是否可行、整合方式是否穩定、效能與安全要求是否能達成，都需要在早期驗證。
這類選項需要投入較多架構探索，例如建模、群體編程、架構技術試驗（Spike）或概念驗證（Proof of Concept, PoC）。
這個選項適合具備足夠開發能力，也願意承擔探索成本的團隊。
團隊若忽略架構風險、測試策略、部署方式與維運責任，從零建置會讓風險集中到後期。
自己蓋一棟房子時，格局可以完全依照需求設計。但相對的，地基、管線、消防與日後維修也都要自行負責。
業務端自主開發（Build from scratch, Citizen Development）
業務端自主開發（Citizen Development）指的是由業務利害關係人使用低程式碼（Low-Code）、無程式碼（No-Code）或是 AI 氛圍開發（Vibe Coding）工具建立解決方案。
這個選項適合相對單純、獨立的需求，例如部門內部資料整理、表單流程、報表彙整或輕量自動化。
業務端自主開發可以減少 IT 工作佇列中的等待時間，讓 IT 團隊把精力留給較複雜的系統工作。對業務單位來說，由於最了解自己的工作流程，這種方式能更快試出自己實際需要什麼。
利害關係人可以先釐清需求並做出初版，再由 IT 團隊的架構角色一起判斷後續方向，例如業務端能否自行延續、是否需要 IT 支援，或是否該轉由 IT 接手。
自主開發的風險也很具體，業務端可能低估支援、營運與後續演進的工作量，也可能缺少測試與除錯能力。
若工具做出來後缺乏治理，後續系統就可能變成孤兒，資料散在不同地方，權限與備份也沒有人負責。
這類解決方案若牽涉正式營運、跨系統整合或敏感資料，IT 和架構角色需要及早介入。
設定商用套裝軟體（Configure a Commercial Package）
設定商用套裝軟體，是指採用既有商業產品，再透過參數、流程、權限或模組設定，讓它符合利害關係人的需求。
當組織缺少內部開發能力，或需求與市場上的成熟產品高度接近時，這個選項可以減少自行開發的工作量。
這個策略的風險較容易控制，因為團隊主要是在既有產品能力內進行設定，較少直接修改軟體內部。
通常產品供應商已經處理許多標準功能、權限、流程與維護工作，團隊可以把焦點放在需求對應、資料匯入、角色權限與使用者導入。
但套裝軟體也會帶來限制，例如產品功能可能超過團隊需要，操作流程可能與組織習慣有落差，也可能缺少某些關鍵功能。
當差距出現時，團隊需要判斷要調整內部流程、接受產品限制，還是進入客製化擴充。這個判斷需要利害關係人、架構角色與流程負責人一起討論，避免設定工作變成一連串零散要求。
擴充商用套裝軟體（Extend a Commercial Package）
擴充商用套裝軟體，代表團隊在既有商業產品上進行較深的客製化，例如外掛、客製模組、程式修改，或與內部系統進行深度整合。
這個選項可以讓團隊利用成熟產品的基礎能力，同時補上組織特定需求。
擴充和設定的差異在於風險位置。設定主要是在產品允許的範圍內調整，擴充則會碰到產品邊界、版本相容、升級路徑與供應商支援。
當套裝軟體被大幅修改後，要跟上產品原本的發布路徑就會變得困難。新版本推出時，團隊也可能需要重做部分客製化內容。
因此，擴充套裝軟體前需要安排架構技術試驗或概念驗證，先確認產品能否在組織環境中運作。團隊需要驗證權限整合、資料同步、部署方式、升級流程與測試策略。
若客製化後的維護成本沒有先確認，後續每一次版本升級都可能變成新的專案。
| 策略 | 適合情境 | 架構探索投入 | 主要風險 | 團隊先確認的事 |
|---|---|---|---|---|
| 延伸既有解決方案 | 已有可用系統，新需求能接到現有流程 | 較少，重點在理解舊系統與整合點 | 技術債、老舊技術、測試不足 | 既有系統是否能承受新需求，是否有熟悉系統的人 |
| IT 團隊從零建置 | 需求特殊，既有方案無法支撐，組織需要完整控制權 | 較高，需要建模、Spike、PoC 與早期風險驗證 | 技術不確定、需求理解不足、後期整合風險 | 團隊是否具備架構、開發、測試與維運能力 |
| 業務端自主開發 | 單純、獨立、整合壓力低的業務工具 | 中低，重點在資料、權限與支援邊界 | 測試不足、營運責任不清、形成孤兒應用 | 是否需要 IT 支援，是否牽涉敏感資料或正式營運 |
| 設定商用套裝軟體 | 市場上已有成熟產品，需求能接受產品流程 | 中低，重點在流程適配、資料匯入與權限設定 | 功能過多、流程彈性不足、需求需配合產品限制 | 組織流程能否配合套裝軟體，缺口是否可接受 |
| 擴充商用套裝軟體 | 套裝軟體能支撐大部分需求，仍需要客製化能力 | 中高，需要驗證外掛、整合、升級與部署方式 | 版本相容、升級困難、客製化維護成本 | 客製化是否會破壞升級路徑，供應商是否支援 |
選擇交付策略時需要看的條件
既有資產與技術債
選擇交付策略時，第一個條件是既有資產能否被延伸。
「延伸既有解決方案」排在前面的原因很直接：組織若已經有可用系統、舊系統資產，或熟悉系統的團隊，從既有基礎上擴充，可以減少重新建置所需的探索工作。
既有資產需要從兩個面向檢視。第一個面向是可重用價值，例如既有流程、資料模型、整合介面、部署經驗與熟悉系統的人。
第二個面向是技術債（Technical Debt），例如老舊技術、缺少自動化測試、部署步驟依賴人工，以及文件和系統現況不一致。技術債若沒有先被看見，新需求就可能被綁在難以修改的舊結構上。
延伸既有系統前，團隊可以先做一次小範圍盤點：新需求會接到哪些模組、資料會經過哪些系統、目前是否有人理解這段流程、修改後要如何測試與部署。
若這些問題都能回答，延伸既有解決方案就會有較清楚的基礎。若回答不出來，團隊需要先安排探索工作，再決定是否把新需求放進舊系統。
團隊技能與支援責任
第二個條件是團隊是否具備對應能力，以及誰要負責後續支援。
不同交付策略需要的技能差異很大。
IT 團隊從零建置需要架構設計、開發、測試、部署與維運能力。業務端自主開發需要利害關係人理解自己的流程，也需要 IT 在整合、安全與治理上提供協助。商用套裝軟體則需要設定能力、供應商協調與升級管理。
業務端自主開發在工具完成後仍有後續責任。業務利害關係人可以先用低程式碼或無程式碼工具做出初版，在與架構角色一起評估後續方向。若工具會進入正式營運，仍需要有專業人員負責測試、除錯、權限、備份與支援責任。
團隊可以用技能矩陣（Skills Matrix）把這件事具體化。
矩陣可以保持簡單，列出架構、開發、測試、套裝軟體設定、資料整合、供應商溝通與營運支援等能力，再標出誰能執行、誰需要協助，以及哪個能力缺口最大。
交付策略若超出團隊能力，後續的工作就會卡在少數人身上。
架構風險與探索成本
第三個條件是架構風險有多高，以及團隊需要投入多少探索成本。
Disciplined Agile（DA）在識別架構策略中強調輕量且足夠的架構探索，意思是團隊需要提早看見高風險假設，再用適當方法取得證據。
IT 團隊從零建置時，架構風險多半較高。需求還在成形，技術選型也需要驗證，團隊需要透過建模、群體編程、架構技術試驗（Spike）或概念驗證（Proof of Concept, PoC）確認方向。
擴充商用套裝軟體時，風險集中在產品邊界、整合方式與升級路徑，團隊也需要先驗證套裝軟體能否在自家環境中運作。
設定商用套裝軟體的程式層面風險較低，仍需要確認資料匯入、權限、流程適配與營運條件。
業務端自主開發看起來速度快，若牽涉跨系統資料或正式營運，也會產生架構與治理風險。
團隊可以先問一個具體問題：如果這個策略選錯，最早會在哪個地方爆發問題？答案若指向資料同步、權限控管、升級、部署或正式支援，就需要把探索工作排進產品待辦清單優先處理。
交付策略對架構工作的影響
輕量建模與足夠前期思考
交付策略一旦選定，架構工作的深度也會跟著改變。
Disciplined Agile（DA）在識別架構策略（Identify Architecture Strategy）中強調最小且足夠的前期思考，意思是團隊要先看見會影響方向的架構問題，細節則可以在後續開發中繼續演進。
若團隊選擇延伸既有系統，架構工作會集中在理解現有系統。團隊需要知道新需求會接到哪個模組、會碰到哪些資料、是否會影響既有部署流程，以及舊系統是否已經累積技術債。
這種情境下，架構圖可以先保持精簡，只要把系統邊界、主要整合點與資料流向說清楚，就能支撐後續討論。
若團隊選擇從零建置，架構工作會偏向方向判斷。團隊需要確認主要技術選型、系統拆分方式、關鍵品質需求與部署方式。這些判斷會影響時程與成本，也會影響後續需求拆分方式。
前期建模的目標，是讓團隊知道哪些部分已經有把握，哪些部分還需要再投資時間，透過程式碼或實驗取得證據。
架構技術試驗（Spike）、概念驗證（PoC）與方案比較
當交付策略牽涉較高不確定性，架構工作就需要從討論走向驗證。
團隊可以透過建模（Modeling）、群體編程與架構技術試驗（Spike）探索架構機會。在某些策略下，也需要安排概念驗證（Proof of Concept, PoC），確認方案能否在組織環境中運作。
IT 團隊從零建置時，技術試驗可以用來處理局部技術問題，例如某個框架能否支援權限模型，或某種資料處理方式能否承受預期流量。
概念驗證則適合處理較大的方向問題，例如是否採用某個平台、是否建立新的服務架構，和是否改用事件驅動架構。
採用商用套裝軟體時，技術試驗與概念驗證也很重要。團隊需要確認套裝軟體是否能接上既有身分驗證、是否能同步內部資料、是否支援必要的部署方式，以及客製化後是否仍能升級。
若存在多個可行方案，團隊可以用方案對比測試，把自建、設定套裝軟體與擴充套裝軟體放在相同條件下比較。
DevOps 與營運條件提早進入討論
識別架構策略也會影響 DevOps 與營運工作。
團隊在架構構想階段就需要和營運人員合作，確認解決方案是否能支持涵蓋了開發、部署、監控、備份、還原、版本控管與後續支援的完整生命週期。
不同交付策略會帶出不同營運問題。
延伸既有系統時，團隊需要確認新功能是否能沿用現有監控、備份與部署流程。從零建置時，部署腳本、環境設定、版本控管與監控機制都需要一起規劃。
自主開發若會進入正式營運，IT 也要確認資料備份、權限管理與支援窗口。套裝軟體則需要檢視供應商支援方式、升級節奏，以及客製化後的維護安排。
功能切換（Feature Toggle）、A/B 測試、監控儀表與回復流程，也可能在架構策略階段就需要納入。
若這些策略太晚才討論，團隊可能在開發完成後才發現系統無法順利上線、無法觀察正式環境狀態，或在發生問題時缺少可操作的回復方式。
角色協作與決策產出
利害關係人提供價值與限制條件
識別交付策略（Identify a Delivery Strategy）需要利害關係人先說清楚價值與限制條件。
利害關係人需要提供的資訊，包含業務目標、時間壓力、合規限制、既有流程、可接受的產品彈性，以及哪些功能對營運價值最關鍵。
部門內部流程若需要快速處理，自主開發或設定套裝軟體可以先納入評估。產品若需要高度客製化，便需要採用有討論空間的 IT 團隊從零建置或擴充既有系統方案。
這些資訊也會影響團隊如何看待取捨。利害關係人若只給出「快點做出來」這類方向，團隊很難判斷速度、品質、維護責任與長期演進之間該如何平衡。
較好的做法是把限制講具體，例如上線期限、資料來源、必須支援的流程、能接受的手動作業，以及後續誰會負責營運。
架構負責人與開發團隊整理技術證據
架構負責人（Architecture Owner）與開發團隊的任務，是把交付策略背後的技術證據整理出來。
團隊需要用最小且足夠的方式探索架構，提早看見關鍵技術風險。除了提出可行方案，也要說明每個方案需要驗證什麼。
在這個過程中，架構負責人比較像引導者（Facilitator），負責引導團隊看見風險、整理選項、設計驗證方式，並協助不同角色理解技術取捨。
交付策略會牽涉業務目標、預算、營運條件、技術債與團隊能力，單一角色很難掌握全部脈絡。架構負責人可以引導決策討論，決策責任則需要由團隊相關角色一起承擔。
若團隊考慮延伸既有系統，架構與開發角色要整理舊系統限制、技術債、測試能力、資料流向與部署條件。
若團隊考慮從零建置，則要說明主要技術選型、整合方式、品質需求與早期驗證工作。
若團隊考慮擴充商用套裝軟體，還要確認外掛方式、升級路徑、供應商支援與客製化後的維護成本。
技術證據可以來自簡單模型、架構技術試驗（Spike）、概念驗證（Proof of Concept, PoC）或方案對比測試（Solution Bake-off）。
當證據整理完成後，團隊可以用架構決策紀錄（Architecture Decision Record, ADR）記錄選擇理由、替代方案、已知風險與後續檢查點。這份紀錄能讓幾週後的討論仍然回到同一組決策依據。
治理角色確認投資與風險承擔
治理角色需要確認組織願意承擔哪一種投資與風險。架構策略是利害關係人判斷是否資助團隊的重要輸入，也會影響初始範圍與規劃。
換句話說，識別交付策略會把技術選擇轉成投資問題。
若團隊選擇從零建置，治理角色需要理解前期架構探索、概念驗證（Proof of Concept, PoC）、測試與部署準備都需要時間和成本。
若團隊選擇設定商用套裝軟體，治理角色需要檢視授權費、供應商支援、流程適配與使用者導入。
若團隊選擇擴充商用套裝軟體，治理角色還要理解版本升級、客製化重做與供應商依賴帶來的長期成本。
好的治理對話需要讓決策條件透明，例如預算上限、時間限制、風險門檻、需要先完成的技術驗證，以及哪些結果會觸發重新選擇策略。
當這些條件被說清楚，交付策略就能從會議討論變成團隊後續規劃、產品待辦清單與架構決策紀錄（Architecture Decision Record, ADR）都能追蹤的決策。
將交付策略落到團隊工作
先盤點可用選項與排除條件
交付策略要落到團隊工作，第一步是把可用選項列出來。
團隊可以先把五種策略放到同一張討論表，再補上每個選項的限制、風險與待驗證假設。這些選項先全部攤開，後續討論才會從個人徧好的熟悉做法，轉向目前情境需要的判斷。
接著要寫下排除條件。若既有系統缺少測試、技術債太高，延伸既有解決方案就需要先安排探索工作。
若需求牽涉正式營運、敏感資料或跨系統整合，業務端自主開發就需要 IT 與架構角色一起判斷。
若套裝軟體無法支援關鍵流程，團隊也要評估設定是否足夠，或是否會走向客製化擴充。
這個盤點可以放在一場短時間的會議中完成，並讓產出保持精簡。
只要團隊先整理可用選項、排除理由、待驗證假設與下一步行動，就能把討論從「偏好哪個方案」推進到「哪個方案符合目前條件」。
把策略選擇寫入架構決策紀錄（ADR）與產品待辦清單
交付策略選定後，需要留下可追蹤的決策紀錄。
架構決策紀錄（Architecture Decision Record, ADR）可以記錄團隊選了哪一種策略、排除了哪些策略、主要理由是什麼，以及還有哪些假設需要驗證。
這份紀錄能讓後續成員知道當初的判斷依據，只需要保持短小清楚即可。
產品待辦清單（Product Backlog）則要承接實際工作。
若團隊選擇從零建置，待辦清單裡可能需要放入架構技術試驗（Spike）、概念驗證（Proof of Concept, PoC）、關鍵整合流程驗證與部署方式確認。
若團隊選擇擴充商用套裝軟體，待辦清單就需要放入供應商開發規格測試、升級路徑確認、資料同步驗證與權限整合測試。
這樣做的好處是，交付策略會從會議結論變成可追蹤工作。
團隊可以在後續規劃時看見哪些工作屬於功能開發，哪些工作是為了降低架構風險。當架構技術試驗或概念驗證完成後，團隊也能依據證據調整估算、範圍與策略。
設定重新檢查的時機
交付策略在早期被選出來後，後續仍需要檢查驗證。
Disciplined Agile（DA）強調架構可以演進，前期工作做到最小且足夠即可。這也代表團隊要在合適時間確認原本的策略是否仍然成立。
重新檢查的時機可以和具體證據綁在一起。
例如概念驗證完成後，團隊要確認技術選型是否可行。架構技術試驗完成後，團隊要確認風險是否下降。套裝軟體試接後，團隊要確認升級、資料同步與權限整合是否能接受。
若檢查結果顯示選定的策略風險太高，團隊就需要回到識別交付策略重新選擇。這些調整越早發生，團隊越有空間重新安排範圍、預算與技術驗證工作。
結語：識別交付策略（Identify a Delivery Strategy）的下一步
回到解決方案來源的具體判斷
識別交付策略（Identify a Delivery Strategy）的重點，是讓團隊先說清楚解決方案從哪裡來。
這個來源可能是既有系統、全新客製開發、業務端工具，也可能是商用套裝軟體及其客製化能力。
這五種選項各自對應不同條件。
延伸既有系統會牽涉技術債與既有團隊知識。從零建置會帶來較高架構探索成本。自主開發需要確認支援與治理責任。設定套裝軟體需要接受產品限制。擴充套裝軟體則要檢視升級路徑與客製化維護成本。
選項不同，團隊後續要安排的架構技術試驗（Spike）、概念驗證（Proof of Concept, PoC）、測試、部署與營運工作也會不同。
Disciplined Agile（DA）把這個決策放在識別架構策略（Identify Architecture Strategy）底下的原因也在這裡。
交付策略會影響架構風險、初始範圍、預算估算、DevOps 條件與利害關係人的投資判斷。
只有團隊把「要做什麼」和「打算怎麼做出來」放在一起討論，後續規劃才能接近真實工作。
從最小足夠驗證開始行動
第一步可以從一個很小的動作開始：把目前可行的交付策略列出來，並替每個選項寫下一個最需要驗證的假設。
例如延伸既有系統時，要先確認舊系統能否支撐新需求。從零建置時，要先確認關鍵技術是否可行。自主開發時，要先確認資料安全與支援責任。擴充套裝軟體時，要先確認客製化是否會破壞升級路徑。
接著，把這些假設轉成產品待辦清單（Product Backlog）裡的具體工作。
這些工作可能是一個架構技術試驗（Spike）、一個概念驗證（Proof of Concept, PoC）、一次供應商開發規格測試、一張系統邊界圖。
工作範圍保持小而明確，目標是取得足夠證據，讓團隊知道選擇的交付策略是否可以成立。
識別交付策略最後要留下的是一組可追蹤的決策。團隊需要知道目前選擇哪條路、為什麼選它、哪些風險還沒驗證，以及什麼時候要重新檢查，讓後續開發有清楚的起點。
