幾乎每一個資料平台最終都會被推倒重建。原因很少是技術選錯了——通常是因為第一版把某個後來不再成立的假設寫死了進去：單一來源系統、只做報表的工作負載、一個通曉全局的團隊。當假設崩解時，平台也隨之崩解。
一個耐久平台的目標不是預測未來，而是打造乾淨的接縫，好讓未來到來時，能透過擴充平台來吸納它，而不是替換它。
從問題出發，而非從工具出發
過度建置最快的途徑，就是先選定技術堆疊，再回過頭來替它找用途。正確的做法是從業務需要做出的決策，以及這些決策背後的問題出發。由此回推，找出你真正需要的資料，以及這些問題真正要求的延遲。
順帶一提，對需求也要誠實。多數所謂的「即時」需求，用每小時更新一次的資料就能從容滿足；許多號稱的「大資料」，最後不過幾百 GB 而已。在這個階段做好合理的規模拿捏，比日後任何工具決策都更能省下開銷與複雜度。
能夠擴展的分層
一個能長久使用的平台會做到關注點分離，使每一部分都能在不強迫其他各處隨之更動的前提下發生變化：
- 擷取——與資料來源解耦，如此新增或變更某個來源時不會向下游層層波及。
- 儲存——採用開放的 Lakehouse 格式（物件儲存之上的開放表格式），讓你的資料不被鎖死在某一個引擎裡。
- 轉換——版本化、經過測試、可重現，讓邏輯可稽核、可安全變更。
- 供應——資料倉儲、BI 與 API 都從同一個受治理的層讀取，而非各自的私有副本。
- 治理——編目、血緣、品質與存取控管從一開始就內建其中，而非事後加裝。
價值在於這些層之間的接縫，而非層內的工具。當儲存採用開放格式時，你可以更換查詢引擎而無須遷移資料。當轉換經過版本化與測試時，你可以更改業務邏輯而不必提心吊膽。當每個使用方都從同一個受治理的供應層讀取時，你就能避免那種私有、互相衝突的副本四處蔓生的局面——正是這種蔓生，最終讓人覺得推倒重建是唯一的出路。
雲端與地端並非二擇一
許多組織都有充分理由把部分資料保留在地端——法規、資料落地、延遲，或是那些仍能正常運轉的系統上已投入的沉沒成本。一個開放的儲存層加上可攜的轉換邏輯，能讓你在兩地執行同一套模式，並在合適時機遷移個別工作負載，而不必在第一天就把一切押注在某一個位置上。
及早治理，且要輕量
事後補上的治理是一個遷移專案；從一開始就設計好的治理不過是一種習慣。你無須一套重量級的專案就能獲得其益處——你需要的是血緣，好讓人們信任這些數字；一份目錄，好讓他們能找到既有的資產；會大聲報錯而非默默失靈的品質檢查；以及與你所負義務相符的存取控管。
這一點比聽起來要重要得多。平台唯有被使用才有價值，而人們只會使用自己信任的資料。治理正是贏得這份信任的關鍵——而讓平台在整個組織範圍內被採用的，是信任，而非工具。
避免打掉重寫
你不會把每個決策都做對，也不該強求如此。打造好接縫，把資料保存為開放格式，替邏輯做好版本管理，並從一開始就做好治理。這樣，當業務發生變化時——它一定會變——你只需擴充手上現有的平台，而無須從頭再來。這就是全部要義：不是那個今天功能最多的平台，而是那個你兩年後不必扔掉的平台。