你可以這樣做 - 減少IT現代化阻力，讓數據流動真正帶動決策效率
- 列出3個以上部門常用資料格式並統一定義處理流程。
能跨部門協作，減少資料誤解與重工[1]。
- 設定基礎設施自動化部署，目標是每次申請新資源時≤24小時內完成。
降低人為失誤、加速應變速度，工程師更快回到核心任務[1]。
- 每季檢查數據流轉瓶頸環節，不超過5個重複發生點需優先改善。
持續排除障礙，資訊傳遞更順暢，有效支持決策即時性[2]。
- *導入日誌監控*並分析主要指標，每月產出一次異常警示報告。
主動發現隱藏風險、避免資料遺失或延遲影響判斷品質[2]。
荒謬的IT複雜性，現代化到底在怕什麼
「我們正面臨一個無邊際複雜度的未來，至於能否駕馭其帶來繁榮，還是最終滑向令人麻木的混亂，目前仍是未知之數」（Lucas等，2012）。讀到這句話，我突然想到前幾天在捷運上看到大家都低頭看手機——資訊爆炸真的好像快把人吞掉。嗯，不過還是回來講IT現代化吧。組織在想要管理日漸複雜的IT系統時，其實每一步都踩得很小心，然後又不斷遇到多元組件、協定還有那些詭異莫測的安全限制。真的很煩，有時候感覺只是換個API或多加一台伺服器，就會搞出莫名其妙的新錯誤，讓人懷疑是不是系統故意跟你作對。唉，好像離題了。
拉回來，「數據流動性」這個詞，其實它指的是數據能夠順利地從A點跑去B點，在不同情境下被用上的那種能力啦。有點像水流，但又不像水那麼單純。反正，它就被拿來當成一種統一標準，用來處理那些讓人頭大的非線性複雜度，也算是一條路徑吧，希望可以引導整體的IT現代化。如果之後內容沒顯示完整，大概也只能這樣抓重點。目前，這篇論文主要就是要推廣以數據流動性做核心的新評估法，並且把現代化重點擴大到整體系統效能。不知道這樣講會不會太抽象。
先前有篇文章叫〈演化型IT系統的複雜性〉（名字真的有夠拗口），裡面談到說IT系統之所以越來越難搞，是因為它們經常自己長出新東西，加上基礎設施本身一直主導著方向，所以只靠建設性的調整進行現代化根本困難重重。而且就算你硬著頭皮改了什麼，受惠於全體的人反而變少，很弔詭喔。我在寫這段時想到家裡那台老舊印表機，每次驅動程式更新後就壞給你看，一模一樣氣死人。
再回主題。所以現在IT現代化呈現出一種非線性的複雜狀態，小地方只要微調一下，就可能引發蝴蝶效應似的大問題，有時候甚至連專家都預料不到，所以進展超級緩慢，有些地方乾脆直接卡死不動。唉，不僅如此，資源浪費和效能衰退也跟著發生，那種感覺有點像搬家結果東西全打結了一團，你想解決卻越弄越亂。
講措施之前忍不住想抱怨一句：好像每隔幾年大家都喊一次要「現代化」但總覺得永遠缺乏共識。不過依照目前通用的說法，各組織自己訂目標多少還是不太相同。但大致而言，比較高層級與普遍認可的三個主要目標，包括可近性、安全性以及可持續性（Vial, 2019；Al-Ruithe等, 2018）。欸，我是不是又扯遠？反正就是有這三項啦，它們構成了一個明確框架，可以去思考到底「我們要達成什麼」。至於細節嘛，再細講可能又落入技術迷宮，只好暫時停一下呼吸…呃，好啦下一段再接續。
拉回來，「數據流動性」這個詞，其實它指的是數據能夠順利地從A點跑去B點，在不同情境下被用上的那種能力啦。有點像水流，但又不像水那麼單純。反正，它就被拿來當成一種統一標準，用來處理那些讓人頭大的非線性複雜度，也算是一條路徑吧，希望可以引導整體的IT現代化。如果之後內容沒顯示完整，大概也只能這樣抓重點。目前，這篇論文主要就是要推廣以數據流動性做核心的新評估法，並且把現代化重點擴大到整體系統效能。不知道這樣講會不會太抽象。
先前有篇文章叫〈演化型IT系統的複雜性〉（名字真的有夠拗口），裡面談到說IT系統之所以越來越難搞，是因為它們經常自己長出新東西，加上基礎設施本身一直主導著方向，所以只靠建設性的調整進行現代化根本困難重重。而且就算你硬著頭皮改了什麼，受惠於全體的人反而變少，很弔詭喔。我在寫這段時想到家裡那台老舊印表機，每次驅動程式更新後就壞給你看，一模一樣氣死人。
再回主題。所以現在IT現代化呈現出一種非線性的複雜狀態，小地方只要微調一下，就可能引發蝴蝶效應似的大問題，有時候甚至連專家都預料不到，所以進展超級緩慢，有些地方乾脆直接卡死不動。唉，不僅如此，資源浪費和效能衰退也跟著發生，那種感覺有點像搬家結果東西全打結了一團，你想解決卻越弄越亂。
講措施之前忍不住想抱怨一句：好像每隔幾年大家都喊一次要「現代化」但總覺得永遠缺乏共識。不過依照目前通用的說法，各組織自己訂目標多少還是不太相同。但大致而言，比較高層級與普遍認可的三個主要目標，包括可近性、安全性以及可持續性（Vial, 2019；Al-Ruithe等, 2018）。欸，我是不是又扯遠？反正就是有這三項啦，它們構成了一個明確框架，可以去思考到底「我們要達成什麼」。至於細節嘛，再細講可能又落入技術迷宮，只好暫時停一下呼吸…呃，好啦下一段再接續。
進退維谷：有明確目標卻舉步不前的現實
確保系統、工具還有資料能夠隨時取得，這點真的很難做到徹底無死角欸，但至少要讓大家用起來不會抓狂，感覺操作順手，然後什麼互通性、低延遲回應能力這些，也都算是基本盤。唔，有時候我明明只是想查個資料，結果系統卡住半天，也是挺煩的。理想狀態當然是可以直接一鍵存取所有提升生產力的工具啦，可惜現實總有點落差。
**安全性**：嗯，這部分就不能掉以輕心了，要強化機密性、完整性還有可用性才行，不然現在威脅一直在演化，包括什麼AI驅動攻擊甚至內部人員搞鬼都有可能。講真的，如果信任感崩了，整個IT環境也會變得超級脆弱。不過話說回來，我每次看到「韌性」這詞，就想到橡皮筋…好像有點岔題，拉回正事，其實就是希望系統能扛得住那些亂七八糟的攻擊啦。
**永續性**：對於永續嘛，設計上最好具備可擴充、易維護還有適應性的特質。唉，每次談到持續升級跟能源效率，都覺得腦袋快打結，但沒辦法啊——未來需求本來就很難預測，所以系統要能夠快速採納創新方案才跟得上變化。有時候又想偷懶省事，可一旦遇到大改版就欲哭無淚。
### 存在權衡
其實針對現代化決策，你常常會碰上一堆必須妥協的地方。例如——啊等下，好像突然餓了，不過先寫完：
**安全性**：嗯，這部分就不能掉以輕心了，要強化機密性、完整性還有可用性才行，不然現在威脅一直在演化，包括什麼AI驅動攻擊甚至內部人員搞鬼都有可能。講真的，如果信任感崩了，整個IT環境也會變得超級脆弱。不過話說回來，我每次看到「韌性」這詞，就想到橡皮筋…好像有點岔題，拉回正事，其實就是希望系統能扛得住那些亂七八糟的攻擊啦。
**永續性**：對於永續嘛，設計上最好具備可擴充、易維護還有適應性的特質。唉，每次談到持續升級跟能源效率，都覺得腦袋快打結，但沒辦法啊——未來需求本來就很難預測，所以系統要能夠快速採納創新方案才跟得上變化。有時候又想偷懶省事，可一旦遇到大改版就欲哭無淚。
### 存在權衡
其實針對現代化決策，你常常會碰上一堆必須妥協的地方。例如——啊等下，好像突然餓了，不過先寫完：
<pre><code class="language-yaml">- 高效能AI系統（可近用性、永續性）通常為了提升效能而集中運算，但這樣反而可能損害原本該有的安全層面。
- 工具如果過度簡化，比如說拿AI來輔助建構資料處理流程（可近用性），雖然表面上讓大家覺得方便，可是長遠看卻容易降低使用者對資料架構本身的理解與維護能力，就像某天突然發現自己根本不會修自己的腳踏車一樣，那適應彈性的空間也會縮水，同時增加長期成本（永續性）。
- 零信任資安模型（安全）為了防止資料外洩所以極度嚴格地限制存取權限，可是這又容易造成資料孤島問題（可近用性），而且你要整合大型系統時光是在那邊解權限就很累人，也提高整合所需成本（永續性）。
新瓶裝舊酒？資訊導向系統與技術熱潮浮沉
邊緣運算子系統靠著專屬頻寬——這種可及性，某方面來說反而會侷限它在緊急通訊裡的適應力，唉，其實永續性也是個麻煩的點。說真的，每次討論到這些東西總會讓人有點頭痛，畢竟權衡利弊沒那麼容易啊，大概也只能不斷尋找一個比較現代、能解釋得過去的方法吧？嗯，好像扯遠了。我是想說，如果要處理這問題，就得有願景、有設計原則，然後還要有一套合理的評估方式才行。好吧，現在拉回正題，我們可以看看其中一條路徑，它強調的是把資訊導向系統當成轉型核心。
### 有潛力的方法
資訊導向系統（Kraus et al, 2021）本身就是個很新穎、看起來挺有前景的方法啦，它主張「資訊」才該是整合時真正的管理單位。不過講白了，就是希望所有決策都以數據為根底，再加強連接能力、模組化還有互通性。嗯……想到這裡，不禁懷疑，到底現場真的有人完全做得到嗎？話雖如此，他們確實傾向於用標準化資料格式或推動模組架構來減少複雜度，也同時顧及整體對於資訊整合的需求。
其實技術發展速度快得讓人喘不過氣，有興趣的人可以翻翻 "State-Of-The-Art Report 2025"（我昨天才瞄了一下，好厚）。目前聲量大的，包括：資訊導向網路（ICN）、軟體定義網路（SDN）、那些和數據相關的新玩意兒例如 Data Fabric、Data Mesh 還有 Unified Data Architectures；再者像軟體定義運算（SDC）、分散式帳本技術（DLT）也都榜上有名。有時候腦袋會突然飄走——欸如果真把這些東西全塞進去，那是不是每種情境都能對症下藥？
> 隨便舉個例好了，比如你想像一家全球物流公司啦，他們採用 Data Mesh 技術，把數據所有權分散開來，然後讓每個領域團隊自己管自己的一堆「數據產品」。欸，我覺得這多少可以縮短整合時間，又支援即時貨件追蹤什麼的。至於分析工具，用起來大致也變簡單不少吧……雖然話是這樣說，但誰知道明天又冒出什麼新難題呢？
### 有潛力的方法
資訊導向系統（Kraus et al, 2021）本身就是個很新穎、看起來挺有前景的方法啦，它主張「資訊」才該是整合時真正的管理單位。不過講白了，就是希望所有決策都以數據為根底，再加強連接能力、模組化還有互通性。嗯……想到這裡，不禁懷疑，到底現場真的有人完全做得到嗎？話雖如此，他們確實傾向於用標準化資料格式或推動模組架構來減少複雜度，也同時顧及整體對於資訊整合的需求。
其實技術發展速度快得讓人喘不過氣，有興趣的人可以翻翻 "State-Of-The-Art Report 2025"（我昨天才瞄了一下，好厚）。目前聲量大的，包括：資訊導向網路（ICN）、軟體定義網路（SDN）、那些和數據相關的新玩意兒例如 Data Fabric、Data Mesh 還有 Unified Data Architectures；再者像軟體定義運算（SDC）、分散式帳本技術（DLT）也都榜上有名。有時候腦袋會突然飄走——欸如果真把這些東西全塞進去，那是不是每種情境都能對症下藥？
> 隨便舉個例好了，比如你想像一家全球物流公司啦，他們採用 Data Mesh 技術，把數據所有權分散開來，然後讓每個領域團隊自己管自己的一堆「數據產品」。欸，我覺得這多少可以縮短整合時間，又支援即時貨件追蹤什麼的。至於分析工具，用起來大致也變簡單不少吧……雖然話是這樣說，但誰知道明天又冒出什麼新難題呢？
各種評估方法都很聰明但沒啥用，陷阱在哪裡
不過，這也只是個例子啦，Data Mesh雖說被很多人看好，嗯，但實際上或許它只算是眾多解法中的一部分而已。你知道嗎，有些方法聽起來很有前途，可惜現在都還在初期階段（Qiao et al.，2019），搞不好根本還沒準備好要大規模應用。剛剛想喝水突然忘了自己講到哪……啊對，目前評估這些新技術的方法也都還不夠成熟，沒有什麼權威標準可以跟著走。特別是——怎麼說呢——現在其實缺乏那種能夠統一衡量整個系統效能的指標，所以啊，只能期待會有新的評估方式出現吧。
## 4. 仍然缺乏關鍵的評估方法
其實現行IT領域常用的那些評估手法，比如一些低層級指標（Aslanpour et al., 2020；Duan, 2017；Orogat & El-Roby, 2021；Talburt et al., 2019）或者分析建模（Azodolmolky et al., 2013；Duan, 2017），欸，它們大致上都只聚焦在範圍比較小的工作負載（Pedreira et al., 2023）、迷你型系統，頂多幫你推算一下效能上限而已。有時候我會懷疑，到底誰在意那些數字？反正很難完全適應像ICN或Data Mesh這種新潮技術裡面動態資料流帶來的狀況。
如果我們沒有稍微跳脫框架、去思考「到底該怎樣讓整體系統往好的方向走」，又或者「哪些取捨才算合理」這類問題，其實大家最後就只會採取一種邊做邊試看的策略。唉，但這樣下去風險真的不少，要嘛增加複雜度，不然就是某些技術太快定型反而把更有潛力的新東西給排擠掉了（Akhshabi & Dovrolis, 2013）。結果現在卡住最大的困難，其實是在分散式系統裡，你要怎麼有效地評估那些變來變去、又受到場景影響的資料流。我有時候覺得，大概連專家們也會頭痛吧……
## 4. 仍然缺乏關鍵的評估方法
其實現行IT領域常用的那些評估手法，比如一些低層級指標（Aslanpour et al., 2020；Duan, 2017；Orogat & El-Roby, 2021；Talburt et al., 2019）或者分析建模（Azodolmolky et al., 2013；Duan, 2017），欸，它們大致上都只聚焦在範圍比較小的工作負載（Pedreira et al., 2023）、迷你型系統，頂多幫你推算一下效能上限而已。有時候我會懷疑，到底誰在意那些數字？反正很難完全適應像ICN或Data Mesh這種新潮技術裡面動態資料流帶來的狀況。
如果我們沒有稍微跳脫框架、去思考「到底該怎樣讓整體系統往好的方向走」，又或者「哪些取捨才算合理」這類問題，其實大家最後就只會採取一種邊做邊試看的策略。唉，但這樣下去風險真的不少，要嘛增加複雜度，不然就是某些技術太快定型反而把更有潛力的新東西給排擠掉了（Akhshabi & Dovrolis, 2013）。結果現在卡住最大的困難，其實是在分散式系統裡，你要怎麼有效地評估那些變來變去、又受到場景影響的資料流。我有時候覺得，大概連專家們也會頭痛吧……
數據液態流轉，定義之間亂竄又咬著上下游
有時候我會想啊，所謂「資料流動性」（Data Liquidity），是不是可以當成一種大傘，把像資訊中心網路（ICN）或資料網格（Data Mesh）這些技術，全都用來解釋它們如何推進那種以情境為導向的資料流動？嗯，好像有點繞口。不過先擱著，反正這只是個統一指標的概念。
## 5. 新關注焦點：資料流動性
我常在腦袋裡打轉：「資料其實就像某種信號內容或意義的編碼，不就是應用程式賴以維生的『石油』嘛。」唉，想到這邊又飄神了。總之，如果要讓應用跑得順，至少在可存取即時資料這件事上，我覺得理想狀態大概是——欸，就是讓資料在需要時能剛好出現在該到的位置。聽起來很簡單，但做起來超難。
### 定義與對比
「資料流動性」講白了，是「數據能順利往它該去、被需要的情境裡流動」的能力。你可能會問，那和互通性是啥差別？或者和可存取性、速度那些指標咧？嗯……其實不太一樣啦。因為它強調的是有意義的數據，在特定情境驅動下怎麼無縫移動，而不是只管技術能不能通或速度快不快。有時候我突然想到前人那些定義，大多偏質化描述（Bosworth, 2009; Courtney, 2011; De Saulles, 2020; Penfield et al., 2009; Wixom & Piccoli, 2021; Piccoli et al., 2022），比如Wixom & Piccoli於2021年說什麼「數據資產重用與重新組合之容易程度」。可是此刻重點反而放在怎麼把有意義內容送給正確應用跟使用者，而且把資料看作是一種承載內容編碼的基本單位。唔，講完又覺得好像沒講清楚，再拉回來好了。
### 主張
我的主張其實也沒多新穎，只是比較煩躁地相信：如果IT現代化工程肯優先考慮提升上述那套對「資料流動性」的詮釋，再搭配資訊為中心的流程工程（Flow Engineering），而不是每次都只盯著基礎設施層面的網絡工程(Network Engineering)，興許才真的是比較優化的系統架構做法。嗯，有點長，但這句話我沒辦法斷開。原因也蠻簡單啦，你設定成這樣後，應用程式就能拿到經授權、適合自己情境、還正好需要的數據，所以整體運作自然更順手。不過我偶爾還是懷疑，真的有人全然達到嗎？但——暫且相信吧。
## 5. 新關注焦點：資料流動性
我常在腦袋裡打轉：「資料其實就像某種信號內容或意義的編碼，不就是應用程式賴以維生的『石油』嘛。」唉，想到這邊又飄神了。總之，如果要讓應用跑得順，至少在可存取即時資料這件事上，我覺得理想狀態大概是——欸，就是讓資料在需要時能剛好出現在該到的位置。聽起來很簡單，但做起來超難。
### 定義與對比
「資料流動性」講白了，是「數據能順利往它該去、被需要的情境裡流動」的能力。你可能會問，那和互通性是啥差別？或者和可存取性、速度那些指標咧？嗯……其實不太一樣啦。因為它強調的是有意義的數據，在特定情境驅動下怎麼無縫移動，而不是只管技術能不能通或速度快不快。有時候我突然想到前人那些定義，大多偏質化描述（Bosworth, 2009; Courtney, 2011; De Saulles, 2020; Penfield et al., 2009; Wixom & Piccoli, 2021; Piccoli et al., 2022），比如Wixom & Piccoli於2021年說什麼「數據資產重用與重新組合之容易程度」。可是此刻重點反而放在怎麼把有意義內容送給正確應用跟使用者，而且把資料看作是一種承載內容編碼的基本單位。唔，講完又覺得好像沒講清楚，再拉回來好了。
### 主張
我的主張其實也沒多新穎，只是比較煩躁地相信：如果IT現代化工程肯優先考慮提升上述那套對「資料流動性」的詮釋，再搭配資訊為中心的流程工程（Flow Engineering），而不是每次都只盯著基礎設施層面的網絡工程(Network Engineering)，興許才真的是比較優化的系統架構做法。嗯，有點長，但這句話我沒辦法斷開。原因也蠻簡單啦，你設定成這樣後，應用程式就能拿到經授權、適合自己情境、還正好需要的數據，所以整體運作自然更順手。不過我偶爾還是懷疑，真的有人全然達到嗎？但——暫且相信吧。
假如以Data Liquidity為中心來做事會發生什麼事
這個優化措施，其實講白了，就是把那些價值很高、已經授權過的內容，丟進分散式應用程式裡流動起來——包含路由、驗證、加密還有傳輸效率這些環節。欸，想到加密，忽然想問一句，你有沒有試過那種自己忘記金鑰的窘境？嗯，不重要，拉回正題。
## 6. 資料流動性的潛在影響
關於資料流動性對IT系統帶來的變化，其實蠻根本的。如果你也曾經煩惱現代化到底該怎麼搞，那這一點大概算是一種解答吧。資料流動性本身就像是面對複雜時的一條新出路，讓系統運作不但有效率，還更容易預測與擴展。不過說真的，有時候看著一堆架構圖腦袋會發脹，但也只能繼續硬著頭皮往下研究。
### 決策簡化
話說，把資料流動性當成統一指標來評量技術或方法，感覺有點像終於找到了一把尺，可以跨越不同系統層級比較誰好誰壞。有趣的是，它把「資料能多快多穩定地送到需要它們的地方」納入考慮範疇，所以衡量起來反而清楚許多。唉，我有時候反而會卡在太多指標不知道選哪個，不曉得你是不是也是。但扯遠了——強調這件事可以幫忙聚焦現代化工作方向。在IT現代化過程中，「非線性」問題一直都是讓人抓狂的所在，小小改個設定結果整個系統就爆炸（不是開玩笑）。現在如果用資料流動性作為重心，決策流程說不定真能省去不少迂迴跟自我懷疑。領導者據此去評估ICN（資訊中心網路）、Data Mesh等新技術，而這些方案也許吧，也只有「可能」會達到全局效能目標。
### 強化DevOps效率
其實把注意力放在資料流動性上，有助於區隔出核心架構那些老舊又難懂的複雜度，以及外層創新應用所面臨的新麻煩。講白一點，就是營運和創新的挑戰可以被拉直變得比較「線性」，不再全部糾纏一起。但話又說回來，要處理真的麻煩的大問題還是得靠複雜系統，只是策略上的切割讓部分麻煩移到比較容易快速修正的小圈子裡面。在這種短迴圈下，用戶提需求、工程師拼命搭數據驅動工具，而IT從業人員則忙著調校數據流程配合領導階層排序。一開始感覺亂七八糟，不過逐步推進後，就形成核心架構（針對資料流動性最佳化）與端側應用間持續漸進的小修正（Kurtz et al., 2003）。嗯，有時候做久了也挺懷疑人生，但反正事情總要有人處理嘛。
## 6. 資料流動性的潛在影響
關於資料流動性對IT系統帶來的變化，其實蠻根本的。如果你也曾經煩惱現代化到底該怎麼搞，那這一點大概算是一種解答吧。資料流動性本身就像是面對複雜時的一條新出路，讓系統運作不但有效率，還更容易預測與擴展。不過說真的，有時候看著一堆架構圖腦袋會發脹，但也只能繼續硬著頭皮往下研究。
### 決策簡化
話說，把資料流動性當成統一指標來評量技術或方法，感覺有點像終於找到了一把尺，可以跨越不同系統層級比較誰好誰壞。有趣的是，它把「資料能多快多穩定地送到需要它們的地方」納入考慮範疇，所以衡量起來反而清楚許多。唉，我有時候反而會卡在太多指標不知道選哪個，不曉得你是不是也是。但扯遠了——強調這件事可以幫忙聚焦現代化工作方向。在IT現代化過程中，「非線性」問題一直都是讓人抓狂的所在，小小改個設定結果整個系統就爆炸（不是開玩笑）。現在如果用資料流動性作為重心，決策流程說不定真能省去不少迂迴跟自我懷疑。領導者據此去評估ICN（資訊中心網路）、Data Mesh等新技術，而這些方案也許吧，也只有「可能」會達到全局效能目標。
### 強化DevOps效率
其實把注意力放在資料流動性上，有助於區隔出核心架構那些老舊又難懂的複雜度，以及外層創新應用所面臨的新麻煩。講白一點，就是營運和創新的挑戰可以被拉直變得比較「線性」，不再全部糾纏一起。但話又說回來，要處理真的麻煩的大問題還是得靠複雜系統，只是策略上的切割讓部分麻煩移到比較容易快速修正的小圈子裡面。在這種短迴圈下，用戶提需求、工程師拼命搭數據驅動工具，而IT從業人員則忙著調校數據流程配合領導階層排序。一開始感覺亂七八糟，不過逐步推進後，就形成核心架構（針對資料流動性最佳化）與端側應用間持續漸進的小修正（Kurtz et al., 2003）。嗯，有時候做久了也挺懷疑人生，但反正事情總要有人處理嘛。
決策混沌如何因這個指標變得意外單純（或更亂）
這種修正說穿了，老實講，其實還蠻容易就被發現的。週期短，反應出來的結果又有點像是——唉，不想講得太重，就是可預測性高啦。有好處嗎？有啊，至少比較不會白白耗掉一堆資源，也許系統回應起來也變快。可是這種效率提升，有時候我自己都會懷疑到底值不值得那麼在意。
### 時效性領域中的策略優勢
欸，說到分散式系統，就不得不提數據流動性（Data Liquidity）這玩意兒。其實很多人嘴上都說什麼物流、醫療、國防之類很需要即時反應，但你問他們細節，好像又都只會繞著AI打轉。我一直覺得，被Maslej et al., 2025寫進去也是因為大家開始發現重點根本不是「誰能造出最強AI」吧，而是誰能在頻寬卡卡的情況下拼湊出最適合即時資料整合的人機協作團隊。不過，我剛剛突然想到早餐吃什麼...啊，不重要，拉回來。
舉例好了，在物流業裡，如果貨物追蹤能靠去中心化帳本配合互通性的元協議，那整個流程真的可以順很多；然後醫療現場嘛，只要數據跑得夠順暢，病患監控跟反應時間就會縮短不少；國防？嗯，更不用說了，要是資訊傳遞優先排序做得好，那些關鍵任務訊息才能及時送到該到的人手上。總之就是——大環境風雲變幻莫測啦，有組織如果掌握這種能力，大概真的能比別人快幾拍。
### 範例情境說明
下面幾個場景，可以更直觀地感受到數據流動性帶來的那些可能好處：
### 時效性領域中的策略優勢
欸，說到分散式系統，就不得不提數據流動性（Data Liquidity）這玩意兒。其實很多人嘴上都說什麼物流、醫療、國防之類很需要即時反應，但你問他們細節，好像又都只會繞著AI打轉。我一直覺得，被Maslej et al., 2025寫進去也是因為大家開始發現重點根本不是「誰能造出最強AI」吧，而是誰能在頻寬卡卡的情況下拼湊出最適合即時資料整合的人機協作團隊。不過，我剛剛突然想到早餐吃什麼...啊，不重要，拉回來。
舉例好了，在物流業裡，如果貨物追蹤能靠去中心化帳本配合互通性的元協議，那整個流程真的可以順很多；然後醫療現場嘛，只要數據跑得夠順暢，病患監控跟反應時間就會縮短不少；國防？嗯，更不用說了，要是資訊傳遞優先排序做得好，那些關鍵任務訊息才能及時送到該到的人手上。總之就是——大環境風雲變幻莫測啦，有組織如果掌握這種能力，大概真的能比別人快幾拍。
### 範例情境說明
下面幾個場景，可以更直觀地感受到數據流動性帶來的那些可能好處：
- **緊急應變中的動態資料優先排序**：比如在偏遠地區進行搜救行動時，你想想看喔，團隊必須靠軟體定義無線電從戰略數據中心拿到最新地圖更新。我忽然想到我手機常沒訊號……唉，好吧，但他們顯然不能斷線。不然怎麼找人？解開DevOps死結：流動數據怎樣改寫日常工作
一個Data Liquid系統可以動態優先處理CAP定理裡的一致性（Brewer, 2000）。這是什麼意思呢？唉，就是說，當網路有狀況時，它會自動把一致性放在第一位。然後再透過軟體定義網路（SDN）對整個商業網絡進行重組。嗯，有點像下棋重新佈局，目的其實很單純，就是為了讓資料傳送又快又安全。但有時候我覺得這些技術名字聽起來都太炫，其實操作起來未必那麼神奇。不過等到緊急事件結束以後，系統反而不怎麼執著於一致性了，會把焦點轉去即時警示監控上——不知道你是不是也常覺得「一致性」三個字很抽象？總之它就是這樣切換重心，只為確保數據流通順暢，還能省掉人工干預的麻煩，好吧。
- **自駕車無縫資源共享**：在都市裡一堆車子爭道，有夠煩，而自駕車要做碰撞預測更是壓力山大。Data Liquid系統登場的時候嘛，資訊中心網絡（ICN）加上軟體定義運算（SDC），就讓每台車能從附近邊緣節點取得那些分散的運算資源。欸，我突然想到如果沒這些節點是不是大家都卡住？反正過程中只交換必要資料，例如感測器輸入、還有預測結果之類，不多不少。有趣的是，他們用了去中心化授權機制，把安全顧慮升級，好像築了一圈看不見的圍牆；所以數據就能夠既高效率，又有保障地在城市間流竄——嗯，是不是想像一下真的滿酷的？<pre><code class="language-yaml">- **簡化DevOps與整合流程**：DevOps團隊每天忙東忙西，在大型企業導AI驅動顧客分析工具真的好累人啊。但如果他們採用Data Mesh架構，再加上資料融合技術（Castanedo, 2013；Foo & Ng, 2013），情況就比較清楚了——因為他們可以直接取得標準化、有互通性的資料產品，而且那些資料是真的有意義，不是垃圾資訊。然後，我自己老是懷疑：所謂「具意義」到底誰說了算？無論如何啦，只要資料流動得起來，那些分析工具就能根據情境自動取得需要的數據，同時間還靠軟體定義運算幫忙隨選處理，包括高效計算等各種用途。有時候講到這邊我自己也會搞混，但大致就是這麼一回事啦。
臨場優勢、救災、車子撞人前一刻…全部卡在同一問題上嗎？
這個方法，其實某種程度上還蠻有趣的，可以把原本得花上好幾週才能搞定的整合作業，直接壓縮到只剩下幾天。省錢這件事大家都懂啦，不用多說，但能夠靠著即時又語意精確的數據來強化分析能力——嗯，這點我覺得真的很重要。唉，我剛剛突然想到前陣子有人跟我抱怨資訊永遠不及時，結果分析都只是馬後炮，好吧，拉回來，就是這一點，改善了。
說到實際執行，其實採用資料流動性（Data Liquidity）還是會碰上一堆棘手問題。有沒有那麼誇張？也許你會覺得只是口號，但建立那種「既健全又能量化」的資料流動性指標，需要耗費不少心力去琢磨怎麼衡量那些總是在變、而且常常因情境不同就沒辦法統一標準的資料流通狀況。嗯，我是不是岔題了？對了，要讓整套東西跑起來，有時候還得推翻舊有流程、調整組織文化……想像一下某些人死守慣例，也挺頭痛；技術層面當然也是麻煩事，你要確保大家都有能力玩轉新工具，然後合作治理這塊——啊，有點像在開無止境會議，不過最終目的就是讓資料流向能貼合組織優先級嘛。雖然聽起來很難，不過，如果你願意投入針對性的研究，又真心想解決，其實慢慢也可以克服啦。喔對，而且只要啟動之後，IT系統朝著更容易擴展、更有彈性的方向邁進，就不是夢。
再講一次吧，其實IT複雜度已經成了現代化最大的絆腳石之一，有時候根本不是沒人努力，而是資源老被浪費在處理那些無謂雜事上面。我自己也常卡住，大概很多團隊都差不多；即使現在各種新方案、新技術滿天飛，看似可以解決不少限制，可現階段你要找出一條有效評估現代IT系統整體效能的方法，好像……其實根本沒有。「資料流動性（Data Liquidity）」倒是給了一條看得到出口的小徑，你如果願意把焦點放在怎麼讓數據順利在特定場景中穿梭，那管理複雜度和推進建設性發展就比較不像撞牆，好比說把現代化過程中的「非線性」困難給軟化掉。我忽然想到，上次遇到一個案子，他們內部做法超級瑣碎，結果效率爛爆，可惜不能細講，只能嘆氣。
重點嘛，高度資料流動性的系統表現已經逼近那種「結構極限」，再搭配Flow Engineering以後，就能靠近使用者需求、站在更高抽象層級，用更線性的方式提升應用程式效益。不知道是不是太理想，但假如未來每間組織都把資料流動性視為核心策略考量，也許真的有機會跳脫那種反覆兜圈子的死循環，一步步走向規模可增、彈性十足的新型態IT系統吧。
說到實際執行，其實採用資料流動性（Data Liquidity）還是會碰上一堆棘手問題。有沒有那麼誇張？也許你會覺得只是口號，但建立那種「既健全又能量化」的資料流動性指標，需要耗費不少心力去琢磨怎麼衡量那些總是在變、而且常常因情境不同就沒辦法統一標準的資料流通狀況。嗯，我是不是岔題了？對了，要讓整套東西跑起來，有時候還得推翻舊有流程、調整組織文化……想像一下某些人死守慣例，也挺頭痛；技術層面當然也是麻煩事，你要確保大家都有能力玩轉新工具，然後合作治理這塊——啊，有點像在開無止境會議，不過最終目的就是讓資料流向能貼合組織優先級嘛。雖然聽起來很難，不過，如果你願意投入針對性的研究，又真心想解決，其實慢慢也可以克服啦。喔對，而且只要啟動之後，IT系統朝著更容易擴展、更有彈性的方向邁進，就不是夢。
再講一次吧，其實IT複雜度已經成了現代化最大的絆腳石之一，有時候根本不是沒人努力，而是資源老被浪費在處理那些無謂雜事上面。我自己也常卡住，大概很多團隊都差不多；即使現在各種新方案、新技術滿天飛，看似可以解決不少限制，可現階段你要找出一條有效評估現代IT系統整體效能的方法，好像……其實根本沒有。「資料流動性（Data Liquidity）」倒是給了一條看得到出口的小徑，你如果願意把焦點放在怎麼讓數據順利在特定場景中穿梭，那管理複雜度和推進建設性發展就比較不像撞牆，好比說把現代化過程中的「非線性」困難給軟化掉。我忽然想到，上次遇到一個案子，他們內部做法超級瑣碎，結果效率爛爆，可惜不能細講，只能嘆氣。
重點嘛，高度資料流動性的系統表現已經逼近那種「結構極限」，再搭配Flow Engineering以後，就能靠近使用者需求、站在更高抽象層級，用更線性的方式提升應用程式效益。不知道是不是太理想，但假如未來每間組織都把資料流動性視為核心策略考量，也許真的有機會跳脫那種反覆兜圈子的死循環，一步步走向規模可增、彈性十足的新型態IT系統吧。
理論很美好但度量難搞，未來可能光怪陸離
嗯，講真的，如果沒有這種指標來當作組織前進的導航，那很多時候大家就會陷在那種花錢又沒效率的現代化流程裡，搞半天一點進展也沒有。唉，其實我常常想，到底有多少公司是這樣白忙一場，然後還自以為在「轉型」？總之，這問題挺惱人的啦。
## 8. 那麼我們如何衡量與觀察資料流動性？
欸，關於要怎麼把資料流動性弄得可以量化，其實現在應該得依靠一些新的評估指標才行。說到底，每個情境下資料流動都會變來變去，不太好抓，但如果能有辦法找出合適的測量方式，也許能更精準看清楚資訊科技現代化的那些轉折點。嗯，有時候我會分心想：「難道沒有人已經做過嗎？」結果查了半天，好像還真沒什麼具體方案。
所以未來有興趣的人，大可從試點研究下手——在實際環境中用流程導向架構配上組織變革需求去驗證看看。我自己現在其實正在找一起合作的人，希望能提出個正式研究提案（感覺壓力很大啊），目標就是把資料流動性用某種方式數字化。不知道會不會失敗？但反正有人嘗試總比沒人碰好。在這段時間內，如果你有興趣，可以偶爾回頭看一下這邊，我陸續會討論相關範式、建構範例，也順便跟大家分享一些亂七八糟但或許重要的內容，例如：
## 參考文獻
## 8. 那麼我們如何衡量與觀察資料流動性？
欸，關於要怎麼把資料流動性弄得可以量化，其實現在應該得依靠一些新的評估指標才行。說到底，每個情境下資料流動都會變來變去，不太好抓，但如果能有辦法找出合適的測量方式，也許能更精準看清楚資訊科技現代化的那些轉折點。嗯，有時候我會分心想：「難道沒有人已經做過嗎？」結果查了半天，好像還真沒什麼具體方案。
所以未來有興趣的人，大可從試點研究下手——在實際環境中用流程導向架構配上組織變革需求去驗證看看。我自己現在其實正在找一起合作的人，希望能提出個正式研究提案（感覺壓力很大啊），目標就是把資料流動性用某種方式數字化。不知道會不會失敗？但反正有人嘗試總比沒人碰好。在這段時間內，如果你有興趣，可以偶爾回頭看一下這邊，我陸續會討論相關範式、建構範例，也順便跟大家分享一些亂七八糟但或許重要的內容，例如：
- 結合人工智慧代理與即時資料，例如：價格預測場景，嘗試在不限制代理潛力的前提下建立信任機制
- 應用分散式帳本技術，例如：全球庫存追蹤，在不完全互信條件下探索互操作性優勢
話說，有些名詞真的讓人頭痛，比如「分散式帳本」剛開始聽根本搞不懂是啥。但拉回主題啦，就是希望慢慢累積更多案例出來吧。## 參考文獻
<pre><code class="language-python">Akhshabi, S., & Dovrolis, C. (2013). The Evolution of Layered Protocol Stacks
Leads to an Hourglass-Shaped Architecture (pp. 55–88).
https://doi.org/10.1007/978-1-4614-6729-8_4
Al-Ruithe, M., Benkhelifa, E., & Hameed, K. (2018). Key Issues for Embracing
the Cloud Computing to Adopt a Digital Transformation: A study of Saudi
Public Sector. Procedia Computer Science, 130, 1037–1043.
https://doi.org/10.1016/j.procs.2018.04.145
Aslanpour, M. S., Gill, S. S., & Toosi, A. N. (2020). Performance evaluation
metrics for cloud, fog and edge computing: A review, taxonomy, benchmarks
and standards for future research. Internet of Things, 12, 100273.
https://doi.org/10.1016/J.IOT.2020.100273
Azodolmolky, S., Nejabati, R., Pazouki, M., Wieder, P., Yahyapour, R., & Simeonidou,
D. (2013). An analytical model for software defined networking: A network calculus-based
approach...（後略）
