供應商版塊由于歷史問題，產生了比較嚴峻的邊界問題（涉及采購、品控、倉配、銷退、商品中心、售后等6個B端版塊），不僅降低了整體的協作效率，也制約著供應商系統的發展。因此從2020年開始，供應商系統開始聯合其他版塊進行邊界治理，至今已完成90%+的邊界問題治理，總計遷移代碼量超15w，db表超70張；本文對供應商版塊歷史1年半的邊界治理實踐進行了總結，希望對大家“邊界治理的認知和落地”有一定的啟發。 1 邊界治理在做什么 簡單來說： 團隊層面，邊界治理是明確版塊定位并讓團隊的職責聚焦版塊定位。 從產品技術層面，邊界治理是規劃領域能力并內聚散落在其他版塊的領域能力。 2 為什么要做邊界治理?

2.1 歷史背景 2017-2020年初，因為歷史原因，供應商系統及關聯版塊業務架構如上。從目前的視角看來： 一方面，【供應商版塊】承擔了許多非供應商領域的職責，包括外倉相關，采購履約相關，售后相關等等。 另一方面，應歸屬到供應商版塊的“尋源”&“報價”散落在了【商品中心版塊】和【采購版塊】。 上述邊界狀態為供應商團隊和相關的其他團隊帶來了以下痛點：2.2 降低研發效能 邊界問題由于自身攜帶“領域能力分散”這個自然屬性，進而給研發團隊帶來了一系列強感知的研發效能痛點，包括： 評估難：邏輯分散帶來了“完整性”的挑戰，依賴其他團隊評估結果又要面臨“效率”問題。 排期難：跨團隊排期需要解決“優先級匹配”以及“研發節奏同步”。 改動難：核心難點在于煙囪式建設帶來的“領域邏輯一致性”的問題，特定情況下需要先解決“歷史邏輯不一致”的問題，才能開始后續工作。 測試難：測試往往需要進行跨系統造數，有一定的跨系統熟悉成本。?

2.3 缺少整體性規劃 嚴選的貨品一部分放置在內倉（嚴選負責的倉庫），一部分在外倉（供應商負責的倉庫）。在邊界治理前，內倉和外倉的產品化建設分別歸屬于【倉配版塊】和【供應商版塊】，這導致倉配域無法進行“整體性規劃”，曾產生的現象包括： 外倉相比于內倉，產品上缺少“庫存管理”功能。 外倉相比于內倉，技術上采用的“物流軌跡查詢”方案比較滯后，其的一些物流軌跡停滯問題。 …… 上述現象均產生了一定影響，包括： 外倉每年會因為線下手動管理庫存，導致外倉次品數量統計出錯。 外倉平均每月會有一些物流軌跡停滯問題。?

2.4 偏離團隊目標 在邊界治理前，【供應商版塊】未明確自身定位，導致在與版塊相關的核心領域方面的建設比較缺失。

3 如何做邊界治理 邊界問題的治理依次分三步，“表達邊界”、“識別邊界問題”、“解決邊界問題”。其中“表達邊界”旨在明確邊界的理想狀態，“識別邊界問題”指引我們現狀與理想邊界的不匹配點，而“解決邊界問題”即解決消除上述不匹配點。

3.1 表達邊界 表達邊界核心要解決3個問題： 表達語言：語言的粒度要能足夠支撐邊界描述的豐富性，同時理解成本低。 統一：邊界表達后是要用于溝通的，顯然語言要統一。 準出：一方面，所有版塊的邊界要獨立不重合，且整體要完整覆蓋超域。另一方面，要解決版塊間的職責沖突。因此需要有個“準出”環節要把控。 在供應商邊界治理的實踐過程中，通過嚴選業務架構解決“表達語言&統一”的問題，通過架構組準出環節來解決“準出”的問題。業務架構有5個元素，包括用戶、問題域、業務場景、產品、能力等。可以簡單理解“xx版塊，為誰解決什么問題，涉及哪些場景，用哪些功能，這些功能有哪些共性”。下述為供應商版塊的準出架構的簡要介紹（為了方便理解進行一些縮減）： 供應商版塊核心用戶：供應商、采購 供應商版塊核心問題域：供應商管理、供應商與嚴選線上協同的基礎能力建設 場景&產品&能力設計如下：

3.2 識別邊界問題 邊界問題可以簡單理解“組織、領域、系統的職責處于一種不合理的形態，與理想中的完美設計存在差距”。那么我們具體做的就是為不匹配的部分找到與之匹配的版塊。匹配過程可以根據“版塊面向的問題域”做自上而下的問題域契合度匹配，也可以如下述案例直接進行能力匹配。下圖為【供應商版塊】【采購版塊】的邊界問題識別過程，如圖所示【供應商版塊】中提到的“簽署”、“生產排期”、“入庫”等領域，存在于【采購版塊】的業務準出架構中，那么這幾部分便涉及了邊界問題。3.3 解決邊界問題 邊界問題解決的過程會面臨一些落地難點，包括“項目管理”和“技術方案的設計和實施”，前者關系到項目能否順利啟動，后者關系到治理前后的穩定性。后續會對難點進行簡單的分析以及提供一些實踐過的策略。3.3.1 三大特點 邊界問題解決的難點，來源三大特點： 偏產技驅動 跨版塊技術重構：能力遷移涉及代碼遷移以及相關的內外部依賴改造。 遷入方學習成本高：遷入方要學習業務、產品、技術等等系列細節，包括歷史業務產品規則和代碼本身，尤其在文檔缺失的情況下。 名詞約定：職責從A換成B，A為遷出方，B為遷入方3.3.2 三大難點 上述三大特點，主要產生了3個難點： 價值共識：偏產技驅動的需求，往往在與“業務”、“PMO”等角色就價值共識的達成商，會有一定的難點，因為他們無法直觀感受到痛點與收益。 研發資源空閑度匹配?：跨版塊的協同，需要保障“研發資源在時間上的空限度匹配”，尤其在”遷入方面臨高學習成本“時，加劇了對空閑研發資源的要求。 穩定性保障：能力遷移涉及代碼遷移以及相關的內外部依賴改造（包括DB、MPS等等基建依賴），改動范圍的完整性、改動正確性、生產環境依賴切換的平滑性等方面，均對系統穩定性有巨大影響。而且隨著工程量提升到一定程度，難度會指數級提高。例如【供應商版塊】【采購版塊】的能力遷移，單后端涉及10w+代碼，60+張表，150+接口，單純生產環境切換后的接口驗證，就需要耗費大量工作。?

3.3.3 三大策略 針對上述三個難點，分別對應有3個策略：業務導向 “價值共識”可以從與業務相關的研發效能收益上去對齊，進而不外乎“減少維護成本”、“減少擴展成本”、“提高穩定性”等幾個維度。在邊界治理中，上述維度可以因“能力分散邏輯割裂”直觀化為以下幾個易于業務理解的收益點： 提高需求分析效率：邏輯割裂會提高“分析完整性”的成本，進而導致“業務產品研發“等職能的分析低效性； 提高穩定性&減少運維成本：邏輯割裂會增加“分析改動點不完整”的概率，進而，一方面直接導致線上功能無法使用，另一方面，往往“業務”、“產品”、“技術”等職能要進行數據撈取&訂正&驗證，經歷過的都知道痛（“怎么又漏場景了！”）； 加快業務響應：只要涉及外部聯動，那么即使是半天的改動量，也會因為優先級不一致而導致交付周期延長xx周，經歷過的都知道痛（“要不是不懂，好想直接進依賴方的代碼庫敲代碼”）； 減少學習成本：能力分散的情況下，“概念重復”的問題會難以避免，進而引入重復學習的問題（尤其涉及指標時，重復學習的成本更高）。 上述是定性收益分析，如果還需要定量收益分析的話，可以通過“頻率*單次收益”來對未來的一段時間做預測，關于頻率和收益的相關建議如下： 頻率：可以通過“相關領域是否有重點業務項目”來進行簡單的推算，一方面重點業務項目本身蘊含著迭代和運維收益，另一方面，相關領域在“重點業務項目”之后會伴隨一定的高頻迭代。 收益：對相關類型問題耗時提前做好耗時的采集，進而后續支持分析和推算，這是比較容易被忽視的，同時也較難進行彌補的。 前瞻性&精細治理 提高研發資源空閑度匹配，一方面可以在進行年度/半年度規劃時對齊并預留資源，另一方面可以對治理過程進行拆解，進而減少研發資源的單次預留難度，例如： 可以讓遷入方先接手增量迭代運維任務，然后再接手歷史存在的功能。 可以先交接產品職責，再交接技術職責（包括擴展與維護）。 遷入方可以先在遷出方的代碼庫里進行代碼開發，再擇機進行能力遷移（包括代碼遷移和DB庫遷移）。 在【供應商版塊】【采購版塊】長達1年半的邊界治理中，就是按照上述方式進行。一方面，在2020年中，2021年初，2021年中等3個時間節點，與采購團隊對齊了治理節奏并預留了資源。另一方面： 采購團隊先負責新增需求，后熟悉存量需求。 采購團隊先進行產品交接，再進行技術交接。 采購團隊于2020.h2接手運維，2021 全年分兩次進行能力遷移。 復雜度降解 上述難點分析闡述了穩定性保障的復雜點來自于保障改動范圍的完整性、改動的正確性，生產環境依賴切換的平滑性等方面，那么可以通過以下幾個方式來減少相關復雜度： 確保改動完整性 可以基于數據流進行改動邏輯梳理盤點。在技術層面實操時，可以通過DAO層代碼從底下上梳理鏈路。 進行數據遷移時，不要忘了與數倉對齊相關數據源的改動。 遷出方刪除所有已遷移的代碼并進行回歸，進而進行完整性兜底。在進行【供應商版塊】【采購版塊】間的邊界治理時，靠此方式解決了多處“能力遷移遺漏點”。 后置非必要的改動 減少外部依賴改造：對于“遷出方”提供給外部的api，暫時由遷出方作為遷入方的反向代理，進而減少外部依賴的改造。后續擇機進行外部依賴的改造。 減少不必要的模型升級：很多時候會想借助能力遷移，對遷入的模型進行升級和整合，但這必然增加改造和驗證復雜度，如果不是必須項，可以后續擇機升級。 天下沒有免費的午餐，上述策略的代價是“額外的時間和研發資源”，實操時可根據容錯性進行選擇使用。例如在核心資損鏈路，穩定性是第一準則，那么就可以采用該方式。前置驗證“數據清洗邏輯” 進行數據遷移時，有時需要通過“數據清洗”來解決數據異構等等問題。而數據清洗邏輯的測試往往會因“測試數據封不夠豐富”、“測試數據量太少”、“線上臟數據”等因素導致測試不全面，該不確定性會增加線上實施的風險。針對此問題，可以提前基于生產環境數據來驗證清洗邏輯的正確性。除此之外，“如何應對發布及切換過程中的流量”、“回滾策略的設計與實施”等等也是難點，在此不深入探究。

4?成果 邊界治理部分成果如下： 研發效能提升：【供應商版塊】通過“供應商報價”邊界治理，促使了能力內聚和改動自治，整體達成了易評估、易改動、易排期、易測試的效果，在后續的產品迭代中，最快能單天優化與發布。 提高領域規劃完整性：通過【供應商版塊】【倉配版塊】的邊界治理，不僅解決了背景中提到的問題，【倉配版塊】還在后續繪制了外倉建設藍圖。 聚焦團隊目標：供應商團隊完成版塊定位，并且后續專注于版塊核心領域的建設。 5?小結 在主導供應商版塊持續一年半的邊界治理過程中，對邊界治理的理解也在逐步加深： 除了“能力遷移”本身外，邊界治理的核心和挑戰在于“認知版塊定位”，“表達版塊邊界”，“對齊版塊邊界”等事情。 邊界治理絕對不僅是技術的事，這個過程是需要產品與技術緊密協作，脫離產品的邊界治理會在實踐時更容易遇到“邊界劃分不合理”、“邊界腐化”等問題，最終使得邊界治理變成閉門造車或不具有可持續性。 邊界治理是個常態化的事情，隨著業務、技術、組織與人的認知的不斷變化，板塊的定義與邊界仍然需要不斷的演進才能適應業務的發展。 本文旨在對供應商系統邊界治理進行了體系化基礎性的總結，在細節上不會過于深究，包括業務架構產出和技術重構等等細節。