從澳門「電子消費卡」看電子貨幣

疫情之下，全球多地也推出紓緩經濟壓力的措施，除支援企業、支援就業之外，更有直接派錢增加消費撐經濟，不過各地的做法也很有不同。

以美國用支票派錢為例，可謂金融界中一個最「傳統」的方法，又要郵寄，市民收到又要再去銀行入 cheque，還要經過一大堆背後的cheque processing流程，在現有的金融基建底下，實在想不出為何還要用這種「傳統」方法。

另一個例子是澳門金融管理局發行的「電子消費卡」，卡上貨幣的面值跟澳門法定貨幣一樣，可以算是「電子貨幣」的一種。但「電子消費卡」不能兌換成現金，亦限定了使用期限及每日限額，市民首先要去領卡，也不是所有零售點也接受讀卡。不過如果從澳門的派錢目的來看，「電子消費卡」可以確保派的錢是花在本地經濟，不會立即就用了去買新iPhone 或去旅行，又未嘗不是一個好主意。

「電子貨幣」的概念，近年一直被廣泛討論，尤其在Facebook 提出發行Libra 之後。筆者一直提倡「去現金化」，早前的篇章亦提及不少使用現金的缺點。由央行發行電子貨幣，可以起到帶頭作用，也有助提供更穩定的流通貨幣。

現有我們在常用的例如PayMe，可以視作電子錢包，但背後仍然是實體貨幣，只不過是儲存在銀行體系內。更符合「電子貨幣」定義的應該是比特幣 Bitcoin，由發行到流通，完全是電子形式出現，但Bitcoin 一直為人詬病是其價格大上大落，屬炒賣成份多於平時流通使用的交易貨幣，這亦很大程度源於Bitcoin 背後沒有央行以貨幣政策維護其價值的穩定性。另一問題是Bitcoin 底層使用的區塊鏈技術，雖有助維護其交易紀錄的正確性，但付出代價是需要虛耗大量計算資源，長遠而言對地球資源是有害多於有利。

近年就有以央行名義發展的「電子貨幣」(DC/EP)，以科技發展趨勢而言，這也可說是必然出現的結果。「電子貨幣」減省的是實體貨幣帶來的印刷/印制、儲存、防偽、老舊回收的問題和成本，另一方面亦提升交易效率。借助央行發行的「電子貨幣」，可以有效支援外匯兌換，亦有助處理電子錢包之間不能互通的情況。當然，電子貨幣亦同樣要面對偽冒，盜竊等問題，但電子紀錄將能更有效的追踪偽冒的來源和盜竊的流向，可以視為能夠大大減低風險的方法。

澳門今次推行的「電子消費卡」，當然技術上很不同，使用亦有很多限制，但亦可以視作為「電子貨幣」的試點應用，讓社會各界更了解用戶的使用習慣，以及更進一步了解其優缺點。與此同時，澳門政府借此亦更能評估「電子貨幣」的最終流向，有助檢討派錢的實際經濟效用，如有需要的話更可採取導向式的「電子貨幣」，促進計劃經濟。

無論如何，去現金化或電子貨幣一定是科技發展的必然結果，大家更應著重的是技術發展的同時如何兼顧安全、私隱等問題，讓科技為社會帶來真正的益處。

相關篇章：
《關於「去現金化」的想法》
《疫情之下思考「去現金化」的發展》

「阿爾罕布拉宮的回憶」Memories of the Alhambra 的技術介紹

早前看了玄彬及孫藝珍主演的「愛的逼降」，對Netflix 上的韓劇深有印象，開始看玄彬主演的其它系列，也包括了本篇介紹的「阿爾罕布拉宮的回憶」。

不看還好，一開始看了確是深受吸引，著迷得停不下來。劇中牽涉的技術含量，包括XR，IoT，當中亦牽涉的AI、數據傳輸技術、充電等，相信也會吸引不少對資訊科技有興趣的人，本篇嘗試整合介紹。

請注意，以下內容含相當劇透，按閱讀更多前請慎重考慮。

首先介紹是XR (Extended Reality 延展實景)。故事以西班牙南部城市Granada 的阿爾罕布拉宮為題，玄彬劇中飾演的劉鎮宇是科技開發及投資公司的CEO，公司開發了獨有的隱形眼鏡，戴上後就可以支援XR。而另一年輕人鄭世周則開發了一個極度像真的XR遊戲，以Granada的市內場景為背景，玩家在市內遊走，特定的石像可以變成遊戲內的NPC和玩家對戰，而玩家亦可以在市內找尋道具，包括武器或防具，或者到特定實體商店購買。這種延展實景功能，以目前已有的產品去理解，可以用Pokemon Go的AR (Augmented Reality) 技術為基礎，並將手機畫面移值至隱形眼鏡上，並且合併了真實與虛擬物件，從而做到更加逼真。第1集中NPC首次出現的時候，感覺就真的像魔法城市一般。

其次的重要技術是IoT (Internet of Things 物聯網)。基於遊戲本身是即時在線的遊戲，亦可容許多人在遊戲中互動，換言之每個玩家的即時位置和各個反應亦需要即時記錄並傳回伺服器進行中央分析，這就牽涉到大量數據的收集和即時傳遞，以及遊戲玩家與伺服器的即時互動。除玩家本身之外，玩家視覺周圍的環境數據亦有被即時收集傳輸，當中就包括實景現場中的物件。第3集中鎮宇玩遊戲時被NPC 射箭攻擊，就成功地用路邊拾起的花盆擋了一箭。

這裏亦牽涉到數據即時傳輸的技術，例如目前我們已知最先進的5G網絡傳輸技術。劇中無論室外或室內，甚至乎在阿爾罕布拉宮的地底，都會出現NPC與玩家對戰，當中除了玩家自身反應的數據，還有周邊環境的大量圖像信息，都需要即時傳輸，所以對數據傳輸的要求特別高，速度要高，低延遲，也要高可靠，遊戲才能在流暢的效果。但例如在第3集中，鎮宇被NPC追殺，有一個位差不多要身中多箭，就因為遊戲的延時反而救了一命。

遊戲中NPC的行動當然亦牽涉到AI (Artificial Intelligence 人工智能)，每個NPC 對手持武器的使用，應對玩家的具體表現而作出反應，追殺玩家等。用現有遊戲技術去了解這個不難，例如GTA 系列就設計了很好的AI。不過有一點極為不同的是，GTA本身遊戲與現實環境畢竟是兩個世界，所以遊戲只需要應對和計算虛擬物件的介入，但劇中遊戲還包括了要處理真實環境的物件，可出現的物件就有無限可能，單是判斷一件全新物件的屬性例如重量或硬度，就不是一件容易做到的事。例如第2集時NPC跳上實體汽車時，汽車被壓凹的程度，就不是容易計算。這裏就一定也會牽涉到ML (Machine Learning 機器學習) 或Deep Learning 深度學習，大量的數據處理和分析也牽涉到Big Data 大數據的應用，Cloud Computing 提供運算平台也是必要的。

其它還有機件耗電和無線充電技術，以至機件發熱問題，也是需要處理的，畢竟隱形眼鏡是戴在眼睛的，可不是手提電話放下就可以。理論上隱形眼鏡應會集中處理現實數據的收集和展示AR，數據的運算和遠端傳輸則應放在近端相連的配件上處理，例如手提電話。不過在第14集中鎮宇即使丟失了手提電話仍可以繼續遊戲，唯有理解為劇中的科技發展已達致隱形眼鏡可以一體處理數據收集、展示和運算的能力，而且能有效處理電源和發熱問題。

但劇中也有另外一些設定是不合理的，例如劇中沒有考慮不同伺服器及開發環境的問題。世周的開發環境與鎮宇進入的遊戲場景是完全互通的，而J-One 也是在同一環境上繼續開發，新開發的道具又可以直接在場景中使用。遊戲有時有地域界限，例如韓國中就只限首爾，但有時又沒有，例如鎮宇就算去到美國也會被強制登入。

不止如此，劇中還有一些設定更是現有科技所不能解釋的。例如戴上隱形眼鏡後雖然可以見到NPC或虛擬物件，這可以理為解視覺上的擴展，但也只應限制在視覺上，而不應可以對玩家造成實則傷害。但第4集中鎮宇與死敵亨錫的PK對戰，竟然能造成亨錫疑似失血過多而死。而其後鎮宇就算除下隱形眼鏡都仍然可以見到亨錫的NPC版，甚至可以推鎮宇由6樓跌落地下，就不能用現有科技解釋。另一方面，世周和鎮宇在成為master 後能進入副本地圖，但身體竟然可以從真實世界中消失，不吃不喝一年後出現，這是更加無法解釋的，唯有一併看成是劇情所需的設定。

當然，在真實世界中科技發展的潮流，一個人可以開發出一整個遊戲，並且能處理以上提到的各種技術場景，基本上也是不可能的。現實中更有可能的是由不同的團隊在各個領域去並行發展，突破各自領域上的技術難點，以達致整體科技能力的提升。

面向未來，可以說資訊科技真的是有無限發展機會的行業，無論喜歡哪項技術，對哪項技術有興趣，都可以投身進去深入發展。很多人誤將資訊科技和寫code 劃上等號，這其實是錯誤的。科技發展除了需要有程式人員去實施，相當大的工作反而在於設計，深化需求，這是有邏輯思考能力就可以投身的工作。所以學習邏輯思維，了解前端之餘也了解後台運作，是維持競爭力的不二法門。

關於Biometrics Authentication 的想法

科技改變世界，沒有人會反對這句說話吧。在過去十數年，我們也親身經歷了一系列的改變，本篇先寫Biometrics Authentication。

Apple 是其中一個將Biometrics Authentication 帶入我們生活的中堅分子（也是牽頭分子吧）。自從iPhone 5S 開始使用 Finger Scan，又自從iPhone X 開始使用 Facial Recognition，成為了我們今日在用的Touch ID 和Face ID。

相較起傳統密碼，筆者認為 Biometrics Authentication 是相較安全的，尤其是在互聯網年代。今時今日，各行各業也推動線上化，線上化平台就少不了牽涉密碼登錄，要記著這許多密碼真的很有難度，不少人就唯有寫下來儲存在其它人接觸不到的地方，但這卻暴露了更多的風險，而且有時type-in 密碼的時候，還要小心旁邊有人偷看，Biometrics Authentication則把一切都簡化了。

現在大部份需要Login 的App 也基本上support biometrics authentication，牽涉金錢交易的銀行當然support，尤其是牽涉高風險交易更要重新驗證，有些中型企業也開始使用。事實上，Apple 的developer guideline 中特別提到authentication 一項，協助開發人員standardize 用戶體驗，現在不少的開發架構平台也使這方面的開發更加容易。

近年也留意到有機構把 biometrics authentication 與實體服務連結，例如銀行ATM 提款，可以經App進行 authentication 再經NFC / QR code 對接ATM，不用再用ATM card 加密碼提款，減少了因ATM卡被複製。另外，早前到新加坡旅行也能在酒店使用NFC unlock 房門，免除了實體房卡，也免除了因違失房卡而致的損失。

不過要留意的是Biometrics Authentication 跟Identification 不同，Biometrics Authentication 是在現有客戶上應用，但新客戶在系統上未有紀錄，不能用作辨識客戶。最近得知政府原有計劃今年推行免費數碼個人身份 (eID)，筆者未有時間詳細了解詳情，但也已十分期待，希望eID可以協助進行認證個人身份之用，免除大量不必要的面對面接觸，也可處理偽冒簽署的問題。

關於Robotics Process Automation (RPA) 的介紹和想法

傳統上，在機構內的系統要實現流程化或自動化，一般需要透過流程平台對接各個業務平台，而各業務平台亦需要提供API 接口供對接，實作做法在早前需求分析入門系列的「流程化」及「自動化」篇章亦有介紹過。

要比較有效地進行這種形式的系統對接，首先要考慮業務平台本身是否容易建立接口，這會影響項目的成本。一些系統本身設計如較合乎SOA原則，可復用的模塊較多，一般由說也較容易建API，相反另一些系統把 GUI 跟背後邏輯 closely coupled，則比較難建API，或者建立後的後續維護成本也高。

另一個考慮的因素則是系統本身是自家開發還是由外部廠商購置，這亦牽涉成本。鑑於接口可能只適合個別機構內部情況，廠商的產品一般也並不願意做太多非原廠的接口。

面對以上的情況，有些機構會改為考慮使用RPA 工具代替系統對接。RPA的原理是透過紀錄用戶在介面上的動作，然後在介面上直接重覆進行這些動作。基於GUI是業務系統本身已經提供，而且過程亦是直接紀錄用戶的動作，因此可用性不成問題，動作sequence 的可信性也高。如果小時候打機有用過「按鍵精靈」的話，對RPA 就應該不會陌生，一般來說就算不懂programming，只要有邏輯思維亦應能建起較簡單的應用。

當然，RPA的開發，包括紀錄動作、測試、除錯等，還是有一定的成本的。在機構的層面，我們並不會簡單紀錄一套動作然後只重播一套動作，更加會考慮在執行之中加入邏輯，從而能夠復用整套workflow sequence，處理多項同一類別而相類似的工序。

以目前RPA的發展，這些Robots 能夠做到的工作也是頗多的，基本上只要source data 本身是 standardize或者有既定format，RPA 能夠在當中抽取到需要的數據進行邏輯判斷，已經可以讓Robots去做這些工作。當然從成本角度，我們會先選擇重覆性高的工序改為自動化，但可以說在可見的將來，基本上不會再需要有人去處理重覆性或只需要簡單邏輯判斷的工序。

這裏也要提一下RPA 在scalability 方面的優勢，特別是在偶發性出現的大規模處理需求時，RPA 的orchestrator 有條件調用更多機械人同步處理不同的需求。基於工序流程化及重覆，即時調用的機械人按照pre-programmed 的邏輯即可完成工作，對比人工處理就有更大優勢了。

現時RPA 發展更趨向於加入學習模式，就是通常與RPA 合併在一起談論的Machine Learning、AI、Big Data 等，這當然會是科技發展的趨勢，機械人會更多的代替進行重覆性的工序，而我們則更加會轉移向需要更多精細思考，或者靈活隨機而變的工作。但正如早前在「自動化」篇章中提到，進行「自動化」除了考慮工作本身正常運作，更要考慮exceptional handling。

與此同時，在思維上也千萬別以為系統自動化後就與人無關，RPA還是需要有人負責維護管理，並且檢視成效的（正如團隊內有不同人工作，但主管也承擔著責任一般）。有這樣的思維RPA才可以持續發展，真正成為幫助人的工具而不是制造新問題的負累。

Blockchain 應用

上周寫了Blockchain 的介紹，本周試寫一下Blockchain 的應用。

在金融領域上，目前Blockchain 在發展的應用包括了國際匯款、信用証、當然也包括了虛擬貨幣，這些應用也圍繞著「跨境付款」。早前聽人說，今時今日不少的基礎金融產品如跨境匯票，是起源自十一世紀十字軍東征，筆者未有時間考究，唯我們常用的SWIFT payment network，則是差不多五十年前開始建立發展的。

說SWIFT network 壟斷了全球的financial transaction 並不為過。自SWIFT成立發展至今，SWIFT message已成為各類型financial transaction message format的標準，全球大部份的大額金融交易都通過SWIFT network 進行。與此同時，SWIFT 建立自家交易平台 SWIFTNet，成為金融機構之間 payment order 一個最可靠的傳輸渠道，並從中收取手續費。

以現今的科技看SWIFT，會感覺這雖然還是一個可靠的渠道，但卻是一個效率很低的系統，而且交易費用亦不便宜。金融交易從Originating Bank 到Beneficiary Bank，中間可能需要經過多間Intermediate Bank及Correspondent Bank，每經過一間就收一次手續費。與此同時，不是每一間銀行都能夠自動處理交易，這令到整筆交易的傳輸速度因為牽涉人工操作而延誤。更壞之處，是payment order 出去之後甚難trace 到當前狀態，或要發另一個swift message 出去trace，又產生另一筆交易手續費用。

這裏要特別一提的是，SWIFT financial transaction 本身並不牽涉 Fund Transfer，它處理的只是Payment Order，交易雙方本身需要在對方銀行也有清算戶口，而匯款交易只是系統上數額的調撥，但全球銀行就需要花不少人力物力在這個基建上。在數十年前這個模式可能是對的，基於金融市場內操作需要假設雙方互不可信任，但在今時今日，是否應該有更好的金融基建協助資金流動呢？

Blockchain 可以在這方面嘗試作出突破，透過全球金融機構的共建平台，可以省去中介平台，減低成本之餘，亦可快速完成交易。有人說Blockchain 的技術問題例如擴展性限制了其發展，這確是急需解決的問題。現時SWIFT 的每日交易量約三千萬，但較常用的Bitcoin交易目前亦只在大約每月一千萬，還差很遠。可能Blockchain 最終也不是完全取代SWIFT，而是作為另一渠道選項，例如專門處理區域內的交易，參與對手數量就可大大減低。

不過目前全球仍然在發展新技術當中，最終結果如何，哪個平台模式較受歡迎，甚至將來是否仍需要清算戶口也並不好說，但可以肯定是，不少市場參與者也明白現有基建的問題，正想辦法搭建更適合這一代的新平台，當中也有不少有央行參與的項目，務求在更有效率快速處理交易之上，維持現有的AML/CFT 標準。

SOA 應用

早前在寫Microservices時提到SOA，今次介紹一個最近留意到的SOA案例，又是與疫情有關。

在疫情之下，不少醫療用品缺貨，當中口罩是重點缺貨物品。對於網上開售口罩的網站，不少也承受不起突如其來的訪問需求，這在Cloud Computing 的篇章也提過。

對於全新的平台以cloud-native architecture來開發，整體在雲端上架設當然好，把大量的infrastructure 管理工作用雲解決。但現有平台有太多不能容易上雲的dependency，不能單單因為個別的問題而要整體改變。今次介紹的是一個來自丹麥，叫做"Queue-it"的service platform，某程度上可以處理這個問題。

據Queue-it 官方網站的介紹，它是一個one-product software technology company，做的就只是一個產品，就是virtual queueing room，能夠為網購平台或其它票務平台提供排隊的服務，當網站負荷超出上限就re-direct 到Queue-it 的排隊室。而對於網購平台，在搭建的時候可以按既定需求建立，但對於前端排隊的模塊，則使用外部提供的獨立服務處理，不需要整體改造或align用同一平台，這正是SOA 的理念，容許各個部份獨立開發及優化，大家透過互聯網互通。

Queue-it 透過SOA讓用戶在是否全面搬上雲端上取得了平衡，這裏其實也應用了Software-as-a-Service (SaaS)的理念，Queue-it 本身也是一整套的軟體平台，但對外部應用來說，它是把整套平台abstract 成為可調用的service，協助網購平台處理了硬件伺服器瓶頸的問題。與此同時，Queue-it 亦有助處理機械人搶購的問題。

筆者最先留意到Queue-it 是太太在口罩工廠Mask Factory 網站所見，後來發現原來較大的平台如百佳、屈臣氏及國泰也有使用。這種商業模式透過subscription 及用量計費，專門做一個service 可以做得更加精益求精。在互聯網世界，這種模式將會日益普及，我們的思維模式也會隨之而變得更加flexible。

關於Blockchain（區塊鏈）的介紹和想法

之前幾周分別寫了Cloud，Open API及Microservices，都是側重Tech 而不太industry-specific 的題目。今次試寫Blockchain，Finance 色彩會比較濃。

原則上Blockchain 並不一定與金錢交易有關，任何的紀錄也可以在Blockchain 上儲存及成長，不過如大家所認識，Blockchain 最初的普及出現是Bitcoin，到目前來說最普及的應用也都是在cryptocurrency 上，短期內頗多的應用場景還是跟金融有關。

有很多人說區塊鏈是互聯網時代最具顫覆性的創新技術，透過集體分散式演算，毋須任何一方作為中介機構進行主數據管理，處理了中介信任問題。同時區塊鏈上的數據完全開放，任何參與者也可以查閱，並共同維護數據，可以說是完全解決了信任和數據準確性的問題。

基於區塊鏈本質上是一個又一個的區塊的鏈接，原則上所有區塊鏈也可以追朔到區塊鏈的起頭，以及每一次更改（每一個區塊），所以亦有人視之如同Ledger 或歷史紀錄一般，亦有人用「Distributed Ledger」來形容。

區塊鏈有多個特點，其中最重要的特點是「去中心化」和「不可竄改」，所有互聯網上的參與者都負責共用維護數據的完整及準確，任何一個交易的進行，都需要得到超過一半的參與者認可方為作準，這種模式帶來了革命性的多種好處。

首先，「去中心化」或去中介化，免除了單一中介承擔數據管理和準確性的責任和風險，當中風險包括單一維護數據可能發生的人為錯誤，或數據遭入侵修改的可能，為數據本身帶來高度「安全」。而且，數據準確性是基於參與者共同遵守的規則（如演算法）而定，不需依賴任何單方進行校驗，在多方校驗下數據更能確保「準確」。與此同時，免除中介亦同時免除了中介的「費用」。

原則上，基於所有交易必須經超過一半參與者認可方作準，只要參與者數量足夠多的話，基本上很難竄改，而大部份參與者遭同時入侵的機會亦微乎其微。

不過區塊鏈目前大部份的應用場景仍然是在理論層面，多數的項目現時仍在實驗階段，而且基於「去中心化」的特性，與現有法例中的AML/CFT有不少抵觸，也影響了一些項目的推進，很多金融業內的區塊鏈項目也並非能真正做到「去中心」。

其中一個待處理的問題是區塊鏈雖然說數據公開透明，但公開指的是區塊及交易紀錄的出現，內裏的交易雙方資料卻是可以加密隱藏的，這讓一些交易可以匿名進行，完全違反了AML/CFT的監管需求。例如Bitcoin雖然目前已經達到自由流通的狀態，公開市場上亦有價有市，但為數不少的國家仍沒有視Bitcoin為合法貨幣。

另外，本身在技術層面，區塊鏈由出現一直產生的歷史紀錄，造成龐大數據容量需求，而且會不斷加大，亦需要參與多方同時維護，亦產生多線並行computing power的需求，長遠來說並不合乎效益，Bitcoin的掘礦模式就一直被人垢病浪費大量電力資源。因此區塊鏈要容許大量參與者廣泛應用，仍有技術難點需要突破。

但區塊鏈的潛力還是很大的，隨著更多資源投入研發，相信技術問題在可見將來亦有望解決，而區塊鏈亦已有不少潛在應用場景，下篇續寫。

關於Microservices（微服務）的介紹和想法

本週寫的題目是Microservices，跟上兩周寫的Cloud及Open API也很有關連。要了解Microservices，首先要先了解 Service-Oriented Architecture (SOA)。

傳統我們認識的系統，尤其是back-end 的平台，大多都以一個整體形式出現 (monolithic application)，所有無論是產品定義，業務邏輯，流程，審批，UI，static data，parameters，報表，統統都放在一個平台之上。以銀行作為例子，一般的核心系統，財資系統，理財產品平台等，都以這種形式出現。後來系統慢慢演變，為了更有效分工管理，同步開發，系統裏出現了modular-base的概念，基礎可以分成不同的module，由不同團隊營運，但原則上還是一整個系統。

SOA是互聯網世界的產物，原理是把原身為整體系統的各項功能，變為獨立個體，並且可分散到網絡上不同地方，以web services 形式在網絡上互通。

SOA 其中一個最大好處是將application layer 從platform 獨立出來，以往我們在整體系統上，無論怎麼應用modular concept，始終application 選定了某個平台，就要整體放在同一平台上。盡量選擇一個平台獲得最大好處，但也要容忍一些不是太好的地方，在SOA容許各項功能分為獨立個體，代表這些獨立個體可以各自建立在最適合的平台，實際各自實施方法並不太重要，只要大家符合同一套Architecture，並提供API互通即可，這提供了一個機會供各個個體獨立持續開發。

SOA另一好處是可以建立一些公用service，有好些服務是很多系統都需要，但以往的做法是各自做，浪費了很多資源。用一個很簡單的例子，比如一個服務就是查詢某一日是否公眾假期，在銀行的世界裏，可以說幾乎每一個後台系統也要儲 holiday table。另一個常見例子則是用戶職級權限，也是定義在各個系統上。SOA 原則上可以提供獨立統一接口供其它service 使用，減少重覆開發甚至參差不齊的情況。

SOA以Web Services 為基礎，可更容易與Open API或其它API management 平台對接，是本欄一直推崇的未來系統協作模式。

初步講了SOA後回到Microservices，Microservices 是SOA 其中較特殊的一種，在SOA 的要求之上，更加著重 lightweight，分工更加精細，之前提一中土弓Cloud 所著重的 Scalability，其中一個重要先決條件就是Service lightweight，容易Scale up/down，而Microservices 正符合這個要求。

不過要實施 Microservices 也還有不少問題要解決。其一是Service 分得太散，系統容易失去整體視圖，亦更難去解構service 之間的關連性，需要更有系統的辦法管理。另外不同service由不同團隊負責，也會出現像人員分配的問題，需要防止多人做同樣的工作，或有工作跌入灰色地帶。而且還有network latency 的問題，試想一個program，要做任何事也要找其它service 幫忙，技術上可行但恐怕等候時間太長。

原則上，目前並沒有一個統一的說法，究竟有多lightweight 才算是Microservices。一般來說，lightweight 的目標為容易scale up，但也要考慮以上的各點。不過在現階段，即使沒有真正或全面的Microservices，至少我們可以先向SOA過渡，例如先把公用service 分拆成獨立個體，減少資源浪費。

另外也可以考慮是把一些周邊module 分拆，好處是可先為現有系統功能減磅，而不影響核心業務。始終業務也需要持續營運，如果選擇big band 方案綑綁一次搬遷到SOA架構的方案，項目需時太長會很難支持新增業務，遷移風險也頗大。

Open API 應用

今日本來計劃寫如何deal with 難搞的項目stakeholders，不過有個topic 與Open API 有關，心想不如先寫一下。

衞生防護中心近日公佈了一份599C文件，全名為根據香港法例第599C章正在接受強制檢疫人士所居住的大廈名單，是一份193頁的PDF 形式文件，總數有接近六千橦大廈。

看見這份文件，正常人首先最關心當然是自己和親友所住大廈有沒有人隔離，這也容易搜尋，但如果想再看看所住區域附近大廈的情況，就真的有點繁複。幸好網上有人很快在原始資料上加入座標位置，用Google Map 把所有大廈資料import進去，立即一目了然。

類似以上的例子其實也不少，最近在網上就有不少有心人，做了很多數據整理及不同形式展示數據的模型，令大眾更容易知道疫情發展及各個個案的群組關連性，都是想告訴大家，疫情還未結束，勤洗手、戴口罩和減少社交活動的重要性。其實這種由政府或公營機構提供平台及數據，再由社會各界用以創新使用，正是外國正研究推廣的政府2.0理念的一部份。

最近在Amazon 買了一本書，名叫「未來地圖」，當中作者Tim O′Reilly 就很推崇政府2.0這個理念，亦參與其中。政府2.0 強調的是開放互動，通過信息技術改善政府服務，政府將從較為封閉的集中管理的行政機關，演變成作為平台和創新生態賦能者，並與市場及大眾協作以產生更多以用戶為重心的服務，更多介紹可以參看這裏。

當然在香港目前來看這還是比較遙遠的，就以上面599C文件為例子，衞生防護中心提供的是一份PDF 文件，從確保資料不容易被修改的角度，PDF當然是一個好選擇，但從使用角度，則大大不足，甚至可以說PDF 是直接讓本來已是數字化的數據變回不易取用的形式。如果可以用 Open API 取代，讓開發者調用接口使用這些數據，則可大大方便用來作front-end 各種數據分析及展示用途。

事實上政府本來就儲有大量數據，當中亦有不少已是公開數據，從差餉物業估價署，統計署，人口普查等都有不少可用資料，但要取得這些資料作進一步分析整理用途，則需要花大量時間抽取這些數據。有些用Excel 還好，辛苦點還可以用macro，PDF 就真的很麻煩。

如果要各個政府部門在各自domain 開發API，恐怕也是費時失事。首先是與私人機構相類似的情況，各個部門現有都是專門做各個業務/服務的人員，並不是每一個部門都有懂得做 Open API 的人員，當然也可以招聘，但我們也未必希望政府部門搶去太多市場上的人才。

個人認為較理想做法，反而是私營機構主動向政府提出開發Open API，甚至可考慮透過API management platform，正式把這些API 定義為產品而非只是提供渠道，務求善用這些數據資源，釋放更大潛能。事實上，政府內有不少數據對象為企業而非所有人，例如企業查冊、物業查冊等，Open API 可讓獲取這些數據的過程更為方便，即使API作為產品銷售，相信亦會有企業客戶願意購買使用，這對整體提升效率將會有大量幫助。

關於Open API的想法

近年各行各業也大推Open API，香港各大銀行在金管局牽頭下也陸續推出，提供更多service 供外部開發者使用。筆者很贊成Open API的想法，唯對目前的實施方法和成果並不太樂觀。

傳統銀行業的內部系統通常以業務作為單位，存款貸款理財投資各有獨立系統支持，本身就算內部各系統互通訊息都需要獨立建接口，Interface 也隨個別系統而定，少有統一制式，多數也只是做到多渠道共享同一接口，或用ESB將接口盡量統一。

以這樣的背景推進Open API，可以預期的是能夠開放的API將受限於產品平台現有能支援的接口，結果很大機會是在現有網銀及APP外新增多一個渠道。另外由於每個接口需要重新思考access control及authentication，又要照顧performance，初期只支持一些查詢功能，或提供static information，實際用途不大，成本效益就更低了。

筆者認為要推行Open API，機構內部亦需要很大程度提升現有各大平台的API 管理及服務範圍，甚至應更進一步推進升級為以Web Services形式提供服務，以更便於與外部開發者共享同一套API。

以Amazon 為例 (當然這是最好的例子)，今天我們都知道Amazon 內部系統通訊全部都經由Web Services進行，這全是基於Amazon 在很多年前開始推行的改變。無論任何一個業務組，其轄下功能和資料都必須提供Web Services共享，業務之間只能通過Web Services交流，不得經由其它途徑，不容許共享內存，更不容許後門程式。各業務組亦需要負責為功能寫documentation，目標就是日後能直接將服務公開，而服務亦終於在2006年以Amazon Web Services (AWS)為名推出市場，當中不少服務容許介面操作同時亦容許API調用，對開發人員極為方便。

回望今天銀行業以及很多的大型機構，內部系統按業務需要而採購，系統多以照顧業務本身運作流程而設，本身並不太考慮對外對接，因此業務需求亦多以滿足介面操作為先，只有在需要時考慮提供調用接口，要提供 Open API 就更為不便。

要像Amazon 般全面更換成Web Services的話，牽涉到可能要重寫大部份系統，成本基本上沒可能做得到合理，較為合理的方法反而是建立API management layer，以不大幅影響後台產品系統架構為前提，盡量開發更多接口，集中管理。以這種思路發展，API management 亦可自成獨立系統，除處理像ESB的功能，亦管理authentication，處理分流等。API management platform也可以有lifecycle management，容許backward compatible，在多渠道多產品的環境就更為適合了。

面向未來，在 Bank 4.0 的背景，銀行應更為走向發展作為基建，提供更方便的途徑供各行各業及個人使用，Open API 絕對是在走對的一步。

關於雲端運算 (Cloud Computing) 的想法

自小就聽「書到用時方恨少」一句說話，基建也是一樣，到真正有需要時，就會發現基建有多重要，也可看到現有基建有多不濟（巴菲特：水退就知誰在裸泳）。

就以口罩為例，自從疫情開始，世界各地也出現口罩搶購潮，香港也毫不例外，甚至出現更不理性的狀況。

最初的幾日，各大商店一宣佈口罩開賣，那怕是只有一千幾百個，也吸引大批市民排隊。群眾排隊買口罩，不但對防疫沒有幫助，更加劇群眾接觸互相傳染的機會。沒多久，不少網購平台也改善過來，開發提供網上訂購，即使老年人未能學會使用，至少後生一輩不用一齊去排隊，也有助減少市民聚集。

不過網上平台也遇到不少問題，其中最大一個就是短時間內流量太多導致server 負荷過重，即使較大的平台如HKTVMall 及屈臣氏也不能幸免，更莫說一些有心人仕自建平台銷售，其server 更是癱瘓得慘不忍睹，如何解決短時間流量大幅增加，個人認為「雲端運算」是其中最好的一個辦法。

以網購平台為例，一般網購平台在建立業務時，都會按平均或高峰時間所需用量，估算購置的硬件，最簡單是 CPU 及 storage，以配合業務需要。面對疫情最大的困難是，開賣口罩的數十分鐘內（幾分鐘？），會出現突然巨額膨脹的伺服器訪問需求，導致負荷過重不能處理。當然簡單一句話，添置硬件不就解決問題？但網購平台平日的生意一般也不到這個需要，總不成為了一個星期幾十分鐘的業務而大額添置硬件，「雲端運算」正是為解決這個問題而出現。

所謂「雲端運算」，簡單來說就是把大量計算機器放在一齊，由雲端運算服務公司提供基建，整合這些機器的computing power 及storage，目標達致資源共享，隨需提供。Amazon AWS 以"Elasticity" 一字來形容這個能力。其最大的作用，在於公司可以在業務有突如其來的需要時，立即配置足夠的資源支持業務，毋須添置硬件，提升時無縫交接。

用「雲」的概念，意義是公司不需要在開展業務估算需求而購置硬件，因為原則上是可以在實則有需要時加添，費用也是按實則用量而定，這對很多start-up 公司是一大優勢，因為start-up 一開始要估算業務量也有一定困難，而且用「雲」亦減省了一次性投資（也所謂入場最低消費）。

不過用「雲」也有它的缺點，首先是價錢方面。雖然「雲」的計費一般也比較 transparent, 也是按用量而定，但實際計算下來，平均CPU 及storage 也會比自家添置貴，尤其業務相對穩定易估算的情況下，現有方案應該會較平。而且「雲」雖然不是真的放在雲上，也跟網絡供應商有實際的距離，所以也要考慮應用地點和網速，選擇server zone 時也要考慮應用地點，如果有大部份用量是local 的話也真的要想清楚是否用「雲」。

不過整體來說「雲」的優點還是比缺點多，也是長遠來說比較環保的host server 方法。按現時不少公司使用實體硬件的做法，為免經常出現瓶頸，實際上大部份的計算資源也是閒置浪費的，如果都是要用同等分量的資源去製造這些硬件，選擇「雲」則可以把閒置資源調配給其它有需要的地方，達致economies of scale, 減少浪費，網上資源由雲服務公司提供就似乎更加合理。最近更得知Amazon 已經在歐洲試行將其infrastructure 100%改用再生能源，這更加是對環保一大好消息。另外「雲」本來就包含了HA的理念，也可以支援定時備份，對數據就更有保障。

目前除了Amazon 的AWS 有先發優勢，在2006 年已經開始「雲」業務，其它巨頭也開始投入大量資源搶佔板塊，例如Google, Microsoft, 連一向做開硬件的IBM 也投入，中國方面也有Alibaba, Huawei 等加入戰團，服務除了是最直接的web hosting，其它雲端運算還包括Data analytics, AI, Machine Learning, Robotics, IoT 等，Client side 也包括virtual PC等。

可以說「雲」會是未來一段頗長日子的一大趨勢，試想像如果現時IBM, HP或Dell 的辦公室硬件服務，都將由「雲 」提供取代，這是多麼大的一個機遇。

現時AWS 和Google Cloud都有提供網上課程，讓有興趣的IT 同行免費學習其平台功能，AWS還有一年免費使用基礎服務的計劃可以試玩，絕對值得花時間去深入鑽研。