最近在想一件事… 為什麼公司的 IT 系統，越搞越複雜？
你知道的，每年都在喊「數位轉型」，買了一堆新工具、導入一堆新系統。結果呢，感覺像在一個本來就已經很亂的房間裡，不斷塞進新的家具。東西是變多了，但空間越來越擠，動線越來越卡，想找個東西，得先搬開三樣別的。
小小的改動，可能會引發整個系統的雪崩。想推個新功能，結果發現要動的資料卡在三個不同的舊系統裡，每個系統的 API 還都不一樣。最後，專案延遲，預算超支，大家累得半死，結果好像…也沒好到哪裡去。
這種感覺，其實有個專有名詞，叫「非線性複雜度」（non-linear complexity）。就是說，你投入一分的力氣，不見得有一分的效果，甚至可能帶來三分的災難。這真的很讓人頭痛。
重點一句話
我自己是覺得，要解決這個大麻煩，我們可能得換個角度看問題：與其追求單一技術或工具，不如專注提升一個核心指標，叫做「資料流動性」 [Data Liquidity]。
這跟常聽到的「Data Fabric」或「Data Mesh」有什麼不一樣？
我知道，一聽到新名詞，大家第一個反應就是「啊，又來一個？」 是不是跟 Data Fabric [資料結構] 或 Data Mesh [資料網格] 差不多的東西？
嗯… 不太一樣。說真的，這也是我覺得「資料流動性」這個概念有意思的地方。它不是另一個要你買單的「解決方案」或架構，它更像一把尺、一個溫度計。
Data Fabric 或 Data Mesh 這些，比較像是具體的「做法」或「架構藍圖」。一個說要把資料串接起來，弄個虛擬層讓你方便取用；另一個說要權力下放，讓各部門自己管好自己的「資料產品」。它們都想解決資料難用的問題，這點沒錯。
但「資料流動性」關注的，是更根本的問題：不論你用什麼方法，最終，資料有沒有辦法「順暢、即時、且有意義地」流到它「該去」的應用場景裡？
它是一個衡量「結果」的指標，而不是規定「過程」的教條。就像我們評估一輛車，可以看它的馬力、扭力，但我們最終在乎的可能是「從 A 點到 B 點要花多久」。資料流動性，就是那個「從 A 到 B 要花多久」的終極指標。
為了更好懂，我弄了個簡單的比較表，這是我自己的理解，可能不完全精確，但大概是這個感覺：
| 概念 | 我流解釋：它到底想幹嘛？ | 優點（理想上啦） | 限制或盲點 |
|---|---|---|---|
| 資料流動性 [Data Liquidity] | 一個「量尺」，用來衡量資料流動的效率。目標是讓對的資料在對的時間，自動流到對的地方。 | 它是一個統一的目標，不管你用什麼技術，都可以用它來評估「做得好不好」。很單純。 | 嗯… 這也是它的缺點。它只告訴你「目標」，沒教你「怎麼做」。而且要怎麼量化，說真的，學術界還在吵。 |
| 資料網格 [Data Mesh] | 比較像一種「組織哲學」。把資料當「產品」來做，讓各業務單位自己管自己的資料，別再全丟給中央 IT 團隊。 | 權責分明，誰的資料誰負責。開發速度可能會變快，因為不用一直等中央 IT。 | 如果每個團隊都亂搞，最後可能會變成一堆「各自為政」的資料孤島。對小公司來說，管理成本可能很高。 |
| 資料結構 [Data Fabric] | 技術導向多一點。它想做一個「虛擬整合層」，把底下亂七八糟的資料源都藏起來，讓你感覺像在用一個統一的資料庫。 | 使用者很開心，因為不用管底層多亂。存取資料變簡單了。 | 底下那層亂七八糟的東西還是在啊。治標不治本，而且這個「虛擬層」本身可能就超複雜、超貴。 |
| 互通性 [Interoperability] | 最單純的技術問題。就是讓系統 A 和系統 B 能不能「對話」，比如 API 格式對不對得上。 | 很具體，問題好定義，也好解決。 | 就算系統能對話，不代表裡面的「資料」有意義，也不代表它能「順暢流動」。只是解決了最基本的技術連接問題。 |
所以你看，Data Mesh 或 Data Fabric 可能是「提升」資料流動性的方法，但它們本身不是目標。目標，應該是那個暢通無阻的「流動」本身。
所以，「資料流動性」到底是什麼？
原文裡有個比喻，我覺得蠻好的。他說，資料就像是機器的「潤滑油」。應用程式要跑得順，就需要潤滑油。而且不是隨便什麼油都可以，要在對的時間，把對的潤滑油，送到對的齒輪上。
「資料流動性」的核心定義就是：資料流向其所需應用情境的能力。
這裡有幾個關鍵字，我覺得要拆開來看：
- 資料 [Data]：不只是 0 和 1，它得是有內容、有意義的資訊。一堆亂碼流來流去，流動性再高也沒用。
- 流向 [Flow]：這是一個動態的過程。不是把資料放在某個地方等著人用 (那是 Accessibility 存取性)，而是讓它主動、或者說被動地「被引導」到需要它的地方。
- 所需情境 [Needed Context]：這點最重要。同樣的資料，在 A 情境下是黃金，在 B 情境下可能就是垃圾。比如，急診室醫生「現在」需要的是病患的即時心率，而不是他三年前的體檢報告。流動性強調的就是這種「情境感知」能力。
這個概念最早其實不是最近才有的，MIT 的一些研究人員，像是 Barbara H. Wixom 和 Gabriele Piccoli，他們在研究機構 CISR (Center for Information Systems Research) 的報告裡就有提過，他們當時的定義比較偏向「資料資產被重複使用與重組的容易程度」。這個定義也很好，但比較從「資產管理」的角度出發。
而我們現在討論的，更強調「即時性」和「應用導向」。這也是為什麼它在今天這個 AI 滿天飛的時代，突然變得很重要。
把焦點放在「流動性」，到底能帶來什麼好處？
好，概念講了半天，這東西到底有什麼用？如果我們真的把「提升資料流動性」當成 IT 現代化的北極星，會發生什麼事？
1. 做決策會變簡單很多
這大概是最大的好處。前面提過，現在做 IT 決策超痛苦，因為你不知道改了 A，會不會弄壞 B 和 C。但如果大家有一個共同的目標：「這項投資，能不能提升整體資料流動性？」，事情就單純了。
想導入一個新的 AI 分析工具？那就評估它能不能更容易地、即時地拿到它需要的數據。想換掉一個舊的資料庫？那就看新的系統能不能讓資料更順暢地流出去給其他應用。
這個單一指標，可以幫助我們在各種技術選項之間做取捨，避免「為了技術而技術」的窘境。它把一個複雜的、非線性的問題，簡化成一個相對線性的優化問題。
2. DevOps 和開發團隊會輕鬆一點
當資料流動順暢時，應用開發的複雜度就跟底層架構的複雜度脫鉤了。
開發者不用再花 80% 的時間去想到底要去哪裡撈資料、怎麼清理資料、怎麼跟三個不同的 API 打架。他們可以專心做應用層的創新。這讓開發週期縮短，使用者也能更快得到他們想要的功能。需求進來、開發、修正… 這個循環會變得更快、更可預測。
3. 在分秒必爭的領域，這就是戰略優勢
物流、醫療、國防、金融交易… 這些領域，時間就是一切。誰能最快整合即時資訊，誰就能做出最好的決策。
文章裡舉了幾個例子，我覺得蠻有畫面的：
- 緊急救援：搜救隊在偏遠山區需要最新的地圖資料。一個高流動性的系統，可以動態調度商用網路資源，把加密的地圖資料用最高優先級傳過去。任務結束後，系統再自動切換回一般模式。這過程完全不用手動干預。
- 自動駕駛：一輛自駕車在市區需要做防撞預測。它不需要把所有感測器資料都傳到雲端，而是在「高流動性」的架構下，透過像「資訊中心網路 [ICN]」這種技術，直接跟路邊的邊緣運算節點要算力，交換最關鍵的幾 KB 數據，立刻得到結果。
- 醫療照護：說到這個，我就想到台灣的健保資料庫。我們的資料量非常驚人，這是個巨大的寶藏。但這些資料的「流動性」好嗎？一個病患在 A 醫院做的檢查，B 醫院的醫生能即時、無痛地看到嗎？如果可以，能省下多少重複檢查的成本和時間？這就是資料流動性的價值所在。這也是為什麼我對我們數位發展部未來的政策方向很有興趣，他們要怎麼處理這種跨部門、跨機構的資料整合，會是個大挑戰。
聽起來很美好，但挑戰呢？
當然，這不是仙丹。老實說，最大的挑戰就是… 「流動性」到底要怎麼「量化」？
速度 (velocity)、數量 (volume)、延遲 (latency) 這些都好量測，但「有意義的」、「在特定情境下的」流動效率，這就很難用一個簡單的數字來定義。這需要更多研究，甚至要針對不同行業去開發不同的衡量模型。
再來，這也不只是技術問題。它更需要文化上的轉變。公司裡的部門牆要被打破，大家要願意分享自己的「資料產品」，建立共同的治理標準。這往往比導入一套新技術還難。
不過呢，我覺得，即使現在還沒有完美的量尺，光是擁有這個「朝著提升資料流動性前進」的共同目標，本身就是一個巨大的進步了。
它讓我們從糾結於「該用哪個工具」，轉向思考「我們想達成什麼效果」。這至少能確保我們在迷霧中航行時，方向是對的。不然，我們只是在原地打轉，買了一堆昂貴的船槳，卻忘了自己要去哪裡。
換你聊聊：
在你的工作或生活中，你覺得資料是「流動的活水」還是「卡住的死水」？你遇過最讓你傻眼的資料孤島或資料斷層是什麼樣的狀況？在下面留言分享一下吧。
