認識智慧城市頂層設計的MCS模式
By 高煥堂
重要參考文章
內容
- 什麼是MCS模式(Pattern)
- 從SoS視角領悟MSC模式
- 以xMCS模式凸顯SoS的主角
- 應用於頂層設計<系統架構>上
- 銜接到中層設計的<EIT造形>
- 在敏捷迭代過程中的角色
前言
在高煥堂老師提出的<敏捷頂層設計方法>裏，其核心是<三一框架>，就是：
一個EIT軟件造形、一個MCS系統模式、加一層設計(中層設計)
依據此三一框架，您可以建立您自己的頂層設計模式，選擇您自己的開發工具，進而建立產出高質量的頂層架構設計。在本文裏，將要介紹其中的重要元素：MCS系統(架構)設計模式。
1. 什麼是MCS模式(Pattern)
在互聯網上，有許多雲服務的供應端(Cloud Provider)，簡稱雲端；也有衆多的雲服務消費端(Cloud Consumer)，簡稱終端。如下圖所示：
圖-1 典型的雲&端系統架構
在這種架構裏，只有兩項元素：雲端(C)和終端(T)。如下圖：
圖-2 雲&端架構的兩項元素
隨着智能終端(如手機和平板)和物聯網概念的流行，終端(T)又逐漸細分爲兩項：移動終端(Mobile)和感知終端(Sensor)。於是，總共含有三個元素：雲端、移動終端和感知終端。通稱爲MCS系統架構模式。如下圖所示：
圖-3 MCS系統模式的三項元素
其中，物聯網比較偏重於感知端的數據採集，透過網絡傳輸到雲端去處理。如下圖：
圖-4 物聯網的兩項主要元素
至於移動互聯網，則比較偏重於移動應用，透過網絡和雲端來建立移動終端(或個人)之間的連結等等。如下圖：
圖-5 移動互聯網的兩項主要元素
於是，Cloud、Mobile和Sensor成爲現今的<雲&端>系統架構裏的基本元素。如下圖：
圖-6 MCS系統模式的基本元素
有了這三項元素，再加上一些組合規律，就形成一個系統架構模式了。我們就稱之爲：MCS系統架構模式(System Architecture Pattern)；簡稱爲：MCS系統模式。
2. 從SoS視角領悟MCS模式
基於SoS(System of Systems)的概念而觀之，在當今的產業裏，無論是雲計算、物聯網、移動互聯網或車聯網等，都是一種SoS。例如，下圖-7所示的SoS系統就涵蓋了<數字家庭>和<醫療健康>等不同的業務區塊。
圖-7 跨越不同區塊的SoS系統
此圖是MCS模式的擴充型，從傳統的視頻播放功能來看，智能TV是屬於終端。如果從家庭的信息推送角度來看，它可以是一朵<家庭雲>(Family Cloud)，屬於雲端。所以是MCS系統模式的擴充型，我們可稱之爲：xMCS系統模式。這裏的”x”代表了這個智能電視新角色，含有亦云亦端的混合性角色。隨着城市智能化的發展，這些SoS會逐漸成長，整合更多的小系統，持續擴大其規模和服務功能。如下圖：
圖-8 SoS系統的成長：城市智慧化的擴大發展
不僅僅是範圍的持續擴大，無論是數字家庭或智慧城市，也會持續往深度發展。例如下圖：
圖-9 SoS系統的成長：城市智慧化的生根發展
從上述的圖-7、圖-8和圖-9裏，我特別偏重於<數字家庭區塊>。於圖-8裏，往外延伸到車聯網區塊，以及延伸到醫院的傳統HIS系統。於圖-9裏，則延伸到家庭內部的各項感知型家電設備。所以，我們稱上述從圖-7到圖-9是：基於<數字家庭區塊>視角的SoS系統架構圖。
3. 以xMCS模式凸顯SoS的主角
在上述的圖-7、圖-8和圖-9裏，除了偏重於<數字家庭區塊>之外，我還特別凸顯了智能TV是位於中心點，它扮演數字家庭區塊的SoS服務功能的主角地位；它是在SoS裏的小系統之間相互合作(Collaboration)過程中的領頭羊。例如下圖-10所示：
圖-10 凸顯TV是此SoS服務功能裏的主角地位
這建立了<雲端(C)、電視(T)、移動(M))>三層組合的新型SoS服務模式；讓股票分析師能在家裏的智能TV裏，執行他自己的應用軟件，從家外的股票雲平臺取得股票數據，在家裏分析之後，從智能電視將分析建議信息推送到手機的微信畫面上。這也是基於<xMCS模式>的SoS系統架構。於是，就將”xMCS”名稱裏的”x”，改爲”T”；就成爲：<TMCS系統模式>了。
圖-11 凸顯TV是主角的TMCS系統模式
這裏的TMCS模式是凸顯了智能TV爲主角，這是如何決定的呢? 其依據爲：
- 我現在正進行<數字家庭業務區塊>的頂層設計或實踐開發。例如，上圖-10裏，雖然是關於金融股票的分析業務，但仍歸於數字家庭業務區塊。
- 我想把主要的業務邏輯和App軟件安裝於<智能TV>裏。例如，上圖-10裏，股票分析師自己專業的知識，寫成了App軟件，安裝於自己家中的<智能TV>裏執行。雖然股票信息來自窗外的股票信息雲平臺，但是自己App我計算出來的專業股市分析情報，則擺在自己家裏的TV裏；在推送到客戶手機裏。也就是因爲分析師的活動是在於家庭內，所以將上圖-10的業務歸於<數字家庭業務區塊>。此外，App軟件的執行和專業數據儲存都是在智能TV之內，所以此業務幕後SoS的主角歸於<智能TV>。
以此類推，人人都可以依據自己所選擇的業務區塊，以及自己所選擇的<主角>來建立其系統架構模式，並給一個自己喜歡的(模式)名稱。例如下圖：
圖-12 人人都可以命名自己的模式名稱
茲以HMCS模式爲例，從名稱看來就知道，在業務架構層面，這是關於<醫院健康區塊>的業務；而在系統架構層面，則以<HIS系統>爲領頭羊(主角)。同理，從VMCS模式名稱來看，可知道在業務架構層面，這是關於<車聯網區塊>的業務；而在系統架構層面，則以<車載(Vehicle)系統>爲領頭羊(主角)。於是，我們將上圖-6的MCS模式的三個元素，增添了一個，成爲四個元素，如下圖所示：
圖-13 TMCS模式裏的4項元素
在智慧城市的任何一個業務區塊，在其業務架構(Operational View)層面，都有自己的商業模式、獲利策略、業務功能、以及產品或服務等。但是，在幕後的系統架構(System View)裏，任何系統幾乎都可以歸類到上圖裏的4項元素。值得留意的是，這項模式只明確規範了元素種類，並未明確規範這些元素之間的溝通(或通信)途徑。所以，在不同的應用情境裏，可能各有不同的通信途徑，如下圖所示：
圖-14 TMCS模式並沒有規範元素之間的組合規則
剛纔提到了，在這xMCS模式(如TMCS模式)裏，只規範了元素種類，並未規範元素之間組合結構；而是讓各區塊架構師依據不同應用情境而設計出其特定的組合結構，如下圖所示：
圖-15 由區塊架構師決定<M>與<C>之間是否要直接通信
這種模式只規範元素種類名稱，試圖成爲不同業務區塊的系統架構設計者心中的共同概念(Concept)或詞彙(Vocabulary)，以促進系統之間的互通性。也就是，透過共同術語來理解別人的系統架構設計，激發自己的創新設計。這種模式，並不能直接套用，而只是提供人們舉一反三、繼續創新的思考模版，這通稱爲思考性模式(Thinking Pattern)。反之，像本文檔也會提到的<EIT軟件造形>，它除了對元素種類做了規範之外，還明確規範了元素之間的組合規律；所以可以拿來套用，並直接落實爲代碼，就稱爲之靜態設計模式(Static
Design Pattern)。
除了上述的股票分析功能之外，還可以依循TMCS模式的引導，而設計出更多花樣的業務功能；如下圖-16所示。從”TMCS”名稱即可知道這個系統架構是以<智能TV>爲中心，由它扮演主角，帶領其它配角來完成這SoS系統的任務。從圖-16可以看到，這系統包含1個<T>元素、一個<C>元素、一個<M>元素和兩個<S>元素。
圖-16 基於一致的模式(即TMCS)而設計出更多業務功能
上述的圖-13和圖-14是TMCS系統模式的結構；而圖-15和圖-16則是依循TMCS模式而設計出來的<數字家庭區塊>的兩項增值業務的系統架構。接下來，我們來看個車聯網區塊的例子。首先，架構師想到基本的MCS系統模式，然後選擇車載(Vehicle)系統爲主角，得到了一個新的模式：VMCS系統模式。如下圖所示：
圖-17 VMCS系統模式的結構
基於這個VMCS系統模式，架構師就來設計出<車聯網區塊>的<汽車定位>增值業務的系統架構設計。如下圖所示：
圖-18 車聯網區塊的<VHMC模式>系統架構
在醫療區塊裏，也能建立PMCS模式，並設計一個系統架構，如下圖：
圖-19 醫療健康區塊的<PHMC模式>系統架構
此係統的功能是：醫院的病房裏有人體健康狀況檢測傳感器(Sensor)，檢測數據立即傳送到護士手裏的平板電腦屏幕上。平板電腦會與醫院信息系統(HIS, Hospital Information System)通信，取得必要的信息，例如隨時向取得有關醫生的手機的目前IP，然後發送最新信息到醫生的手機上。於是設計出上圖-19的系統架構，其中的平板和手機都是屬於移動<M>元素種類的，如下圖：
圖-20 上圖-19裏的系統組成元素
爲了更明確表達出：此架構是以護士手裏的平板(Pad)電腦爲中心，由它扮演主角，帶領其它配角來完成這SoS系統的任務。於是，將平板電腦提升到中心位置，如下圖：
圖-21 PMCS系統模式
於是，就稱上圖-19是依循<PMCS模式>而設計的系統架構。從圖-20改畫成爲圖-21的目的是：讓人們能一目瞭然看出來這是以平板電腦(Pad)爲主角的SoS系統。一旦整個智慧城市各系統都能採取像圖-21所示的表達方式，就能大幅促進各設計或開發團隊之間的溝通了。
4. 應用於頂層設計的<系統架構>上
前面提過了，在當今的產業裏，無論是雲計算、物聯網、移動互聯網或車聯網等，都是一種SoS系統。基於SoS概念來看待這些系統時，xMCS模式非常有助於建立頂層設計裏的系統架構。如下圖：
圖-22 xMCS模式應用於系統架構設計上
使用高煥堂老師設計的xMCS系統模式，定義了系統架構層級的共同概念(Concept)和詞彙，以秦代”書同文”途徑來創造頂層設計的<簡潔性>；進而提升團隊之間的共識(Shared Understanding)，建立出系統互聯互通的基礎。當我們以MCS模式去構思，系統架構層有了一致性的思維；則系統架構圖，就呈現出既簡單又能互相理解的架構文件了。這項簡化的設計動作，通稱爲減法設計。其簡化效果如下圖所示：
圖-23 xMCS模式促進書同文，建立互聯互通的基礎
基於此圖的MCS系統模式，就在EA框架裏，詳細說明圖中系統元素之間的信息交換協議、數據交換格式、數據量、傳輸速率等規格。於是，產出了EA的系統架構文件。
5. 銜接到中層設計的<EIT造形>
5.1 減法設計
頂層設計包含三個面向：業務架構、系統架構和通信架構。在上層的業務架構裏，各個業務區塊的術語或詞彙(如醫療區塊的MRI、DICOM等詞彙、以及博弈遊戲的Payback、ROR等術語)。往下一層就是系統架構，在這系統架構層裏，無論各個業務區塊的IT系統，都能歸類成三種元素：就是Cloud、Mobile和Sensor。
這種詞彙上的”減法設計”，不僅僅非常有助於系統層面的相互溝通，促進信息共享之外，還能提升系統建置過程中的系統模塊(Module)的複用性(Reusability)。如下圖-25所示。從上而下，經過兩個層級的減法設計，如下圖-25所示。
圖-24 xMCS模式和EIT造形接力進行減法設計
這兩層的減法設計就是：
- 從<業務架構層>到<系統架構層>的減法設計
此時採取<xMCS系統模式>來協助減法設計，讓業務架構層面的千變萬化面貌下，能取得系統設計層面”書同文”，基於共同的概念和術語(如<M>、<C>和<S>等元素種類名稱)，來減化複雜性，提升系統的互通性。
- 從<系統架構層>到<中層設計>的減法設計
此時採取<EIT軟件造形>來協助減法設計，讓系統架構裏的互通接口規範部分，能落實微軟件代碼，並取得軟件接口設計上的”詩同形”，就像唐詩三百首一樣，據有共同的造形(Form)，卻能包容無限意境的詩人心靈感觸。
爲什麼要透過兩層的減法設計來支撐頂層設計的目標(即互聯互通性)呢? 而不是去設計一個業務層面的共同平臺呢? 主要的理由是：智慧城市包含衆多不同的業務區塊，各區塊的系統大多已經發展一段時間了，並非重新興建，而且會持續成長與發展。所以，業務架構層面的百花齊放是城市蓬勃發展的必然性，其本質就是複雜的(Complex)。此外，城市會持續發展下去，頂層設計必須非常專注城市發展的未來性，由於未來環境變會的不可預期性，其本質就是多變的(Changeable)。
君不見，城市裏的建築物外觀也是百花齊放的，也是數千年來持續演化和發展的。人們不會尋求去統一這些建築物的外貌，因爲外貌的複雜性和多變性是本質性(Essential)的。因爲這個城市所處的外在環境(如自然環境、經濟市場環境等)也是複雜多變的。
然而，我們可以看到，無論是教堂、學校、倉庫、四合院、客棧等建築物，雖然外貌都不一樣，但其屋檐下的棟樑、磚塊、水泥、門窗、卡榫接口的設計概念和造形卻是極爲一致。這就是中層設計的來源，藉由中層設計的一致化簡單造形，來包容上層外貌的複雜性和多變性。因此，我們設計了xMCS系統模式和EIT軟件造形，其效益如下:
- 基於中間層造形的包容性，支撐上層業務的多樣性，促進城市發展的未來性。
- 基於中間層設計概念一致化，促進不同區塊、系統、及設計者之間的互通性。
- 基於中間層的模塊的複用性，促進不同區塊、不同系統、不同設計者採用更優質、更受檢驗的模塊，大幅提升城市建置的質量。
5.2 銜接到<EIT造形>
經過了xMCS模式的減法設計之後，在系統架構層裏面，人們獲得一致的概念和詞彙，有如秦朝時代，邁向”書同文”的境界；如上圖-23所示。
由於EIT造形的內容是軟件代碼了，已經到達很明確規範(電腦才能執行)地步了，包括元素本身的形式，以及元素之間的組合形式(就如同，一個H原子內部的質子、中子和電子的結構)；此外還包括EIT造形外部的組合形式(就如同，兩個H原子與一個O原子結合成爲一個水分子)，都明確定義了。它比上層的xMSC模式具有更明確的形式定義(不僅是規範)，就稱之爲”造形”。所以，xMSC模式比較抽象，只是給人看、引發人們去創造的思考性模式(Thinking Pattern)；而EIT則是具像到電腦可執行的軟件(代碼)造形(Software
Form)。
經過了EIT造形的減法設計之後，在中層設計裏面，人們獲得一致的概念和組合形式，有如唐朝時代，邁向”詩同形”的境界。如下圖所示：
圖-25 EIT造形促進詩同形，確保互聯互通的可實現性
這圖以EIT軟件造形來實現xMCS模式裏元素之間的互聯互通的關鍵部分：接口(Interface)。由於EIT是軟件造形，它能有效包裝實體的通信接口，透過軟件來轉換信息格式，再轉交由另一個實體層通信接口傳輸給對方。如下圖-28所示。如此，包容了新、舊的實體層通信協議和設備。換句話說，除了促進互聯互通的效益之外，又包容過去、現在和未來的通信協議，保護了過去的投資；還包容了標準的、不標準的通信協議和設備，提升了持續發展的未來性。於是，得出一個可既簡單又可執行的中層設計。
圖-26 以EIT造形包容新、舊的通信協議
於是，得出了從頂層設計銜接到中層設計的途徑。雖然增加了一項中層設計，但是這些都是<頂層設計階段>所涵蓋的範圍。如下圖所示：
圖-27 頂層設計階段各層級的設計內涵
也許你會問道，爲什麼要獨立出一項<中層設計>呢? 將它合併到頂層設計，是不是也可以呢? 理由很多，其中最主要的是：中層設計是位於頂層與實踐層之間，本來頂層只做設計，並不產出代碼；而實踐層的重要任務之一是以軟件來整合硬件和通信，產出軟件代碼是它的核心任務。雙方非常互補；但缺乏交集；而中層設計是雙方的交集部分。在時間軸上，它雖然屬於<頂層設計階段>的工作範圍；但其產出的軟件代碼，卻是要做爲實踐開發階段的基礎；也就是實踐階段進行敏捷迭代過程的單純起點，在敏捷開發概念裏，稱爲：簡單方案(Simple Solution)。
6. 在敏捷迭代過程中的角色
在頂層設計階段，依循敏捷途徑，以測試驅動(TDD, Test-Driven Development)引導出持續地反饋(Feedback)與迭代(Iteration)的中層設計(即軟件接口開發)過程。如下圖-28所示。
圖-28 頂層設計階段的敏捷迭代過程(產出中層設計)
在圖-28裏，經由敏捷TDD機制來執行接口軟件，實際檢測信息交換的所需的軟硬整合設備，以及相關通信機制。產出電腦可執行的軟件接口控制代碼，就是中層設計的作品了。在這個迭代過程中，可使用高煥堂老師設計的xMCS系統模式，定義了系統架構層級的共同概念(Concept)和詞彙，以秦代”書同文”途徑來創造頂層設計的<簡潔性>；進而提升團隊之間的共識(Shared Understanding)，建立出系統互聯互通的基礎。基於xMCS模式所創造的簡潔性，就可針對各系統之間互聯互通的接口部分，以明確的軟件代碼來定義之；以唐代”詩同形”途徑來提升頂層設計(和中層設計)的<明確性>。纔能有效檢驗頂層設計的<可實現性>。◆
~ end ~
