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。

生產力軟件介紹 - Airtable

今次介紹另一個筆者很喜愛的軟件，叫做Airtable。

按其名稱可以初步想像，Airtable 的基礎是Database 中的Table，Air則代表可以自由網上存取，不過千萬不要以為是Access Database 的線上版，它的功能可絕不止此。

最初認識 Airtable，主要是它的資料管理非常方便好用，可以協助管理各類型資料，加入相關attribute，尤其適合整理資料做分析。而且Airtable 的基礎雖然是Database，但它的Table就做到可以簡單地以spreadsheet形式展示，做得極為 user-interactive。

Airtable 本身是為沒有coding 背景的人而設，簡單的SQL也並不需要，Database的操作介面本身就已極為方便，例如Table 本身的擴展，Format 改變，基本上只是在UI上改就可以，同時它又可以提供一些spreadsheet 的功能，例如excel formula，vlookup 等，所以就算沒有Database concept，只要懂得用Excel，也可以很容易上手。而Airtable 支援的format極之多樣化，當中例如可以加attachment，dropdown field 可以選擇多項，比較有趣的還可以input barcode （mobile version 可以scan barcode來輸入）。

對有基礎Relational Database 認識的人來說，就可以更深入地理解Airtable的用法，例如使用Airtable 來建立Database，一個Database 上有多個table，互相建立關連，更大範圍的管理數據。跟Database 一樣，Table 上的每個attribute 都需要設定format，比較特別是有些常用的資料類型例如Email，URL，一般Database 未必會有特定format，需要在輸入時加validation，還有對資料管理很有用的如創建日期，最後修改日期等，Airtable也提供作為選項，直接把這些功能abstract了。

但以上的都只是Airtable 的基礎功能，其實際功能絕不止此，很多人喜愛用Airtable，更在於它的數據展示功能。

先以免費版的來介紹，Airtable 本身開發就支援多平台操作，包括Web、Mobile、也有Mac version。另外Airtable 上支持多種顯示模式，除了本身default 的Grid view（即spreadsheet 模式），如果有photo attachment 可以用Gallery view，有Date field 的可以用Calendar view。與此同時，table owner 可以制作簡單網頁版的e-Form，Airtable 就會提供form 的URL，就可開放讓其它人透過Form去提供資料。就這幾個功能，已經可以做出很多應用案例了。

而對使用Airtable 作team collaboration 來看，Airtable亦提供Kanban view，那大家可以想像更多功能了。無論是team 的task management，或者使用作Test case management，或者defect management，基本上都完全沒有難度。平台還有一個用法是用API調用Database，為識寫code 的人提供automation的選擇。

而如果用戶對Airtable 甚有興趣，甚至希望在公司層面應用，Pro 版的功能就更加強大，當中數據可以用於Generate Gantt Chart，或者 Generate Flowchart、Org Chart，也可以integrate Google Map visualize 地址等，還有很多周邊功能例如SMS / Email notification。筆者由2015年開始使用到現在，看著Airtable 不時也會發展一些新功能，每每出現驚喜，這是筆者另一個喜愛Airtable的原因。從這些新功能可以看出團隊中的product team 有很多新點子，團隊的執行能力很強，平台基礎建設也很好很方便擴展。

現時Airtable 已經是一間估值達美元 1.1B 的公司了，更加可以看到互聯網公司的威力。還是那句，互聯網世界會獎勵真正持續努力的人，由起初發展提供個人服務進而吸引使用者推介為公司提供服務，可能也是一種有效的營商手法。

「信息化」系列 -「線上購物」

疫情之下，大家減少外出，多了留家休養，零售商戶的業務大受打擊，沒想到這帶來了一次變革的機會。

今次疫情讓很多人初次使用線上購物，尤其是連零售店鋪也買不到的物品，例如口罩、消毒液等，唯有上網到外國網站買。而隨著疫情的延續，為了避免不必要的外出和接觸，一些生活上其它的用品也直接透過網上買。

從基礎層面，網上購物對買家和賣家也有很多好處，對買家來說，線上平台較容易搜索物品，也容易貨比多家，送貨方便差不多等於直接搬貨回家。與此同時，網上購物沒有時間限制，也沒有地域限制，這對於賣家面向消費者來說也是好處。而對於網購平台，沒有零售點的場地空間限制，亦可提供更多貨品供買家選擇。對比實體零售與網購平台，不難發現實體零售中有不少流程是冗餘的，包括分發貨物到零售點、貨物上架、收銀，還包括貨品到期的下架回收等，這些在網購平台都可以節省。

而網上購物更進一步的好處其實是所有交易數據的即時錄入，以及提供更多細化的數據可進行分析。基於減省了中間零售點的關係，產品的售賣和受歡迎情況能夠即時在數據上反映，免除了零售點報數的延誤。另外，網上購物的優勢還在於能獲取更多客戶數據，包括客戶本身資料，喜好，以至客戶在挑選過程中的「腳印」都可在網上平台上紀錄，因此無論是產品本身銷售、客群，以至客戶的停留和比較都可進行分析，商戶可以更了解產品的優勢，配合宣傳策略，達至更精準的營銷。而又因為減省了零售點，數據可更實時反映庫存狀況，達致更高效率的資源配置。

以往正常情況，不少人已開始使用網上平台購物，但更多的還是習慣使用實體商店，以致「線上化」的過程亦甚為緩慢。筆者也是傾向實體商店的用家之一，一來是在購買時見到實物較有信心，二來亦希望有問題時售貨員能解答。其實再細心一想，如果物品本身亦不能拆封或試用，實物與否其實並不重要，口碑反而可作參考，網購平台提供的評分及留言系統有這裏會更有用。而對於後者，不少網購平台已有安排客服，可處理客戶查詢，這類型的客服長遠甚至能比實體商店內做得更到位。

可以想像的是，「線上化」對於現職員工會有很大程度的影響，也需要一定的轉變。例如沒有了負責中轉搬貨上架的職位，需要轉型成直接送到客戶終端。文職例如收銀是完全取消，取而代之是線上客服及處理投訴的人員。

在今次疫情中所推動的「線上化」轉型，相信在疫情過後仍會持續下去，這也是時代的趨勢，追求更大效率及以數據做決策。現時筆者對跨國零售還是有一定保留，擔心點對點銷售會帶來大量重覆性的跨國物流需求，影響效率而且浪費大量資源，但對本地零售的線上化則大為支持。尤其是在香港地少人多的環境，對零售店鋪的需求造成租金大幅上漲，我們的消費當中亦有不少部份是為支付鋪租，長此下去只會侵蝕整體生產力。當然，網上平台不代表就沒有收費，分別只是互聯網世界會獎勵真正持續努力的人，而並非靠祖輩優先購買地皮的人。

讀者如對筆者的文章有興趣，歡迎到訪其它「信息化」系列的文章：
《「簡化」篇》
《「流程化」篇》
《「無紙化」篇》

關於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的掘礦模式就一直被人垢病浪費大量電力資源。因此區塊鏈要容許大量參與者廣泛應用，仍有技術難點需要突破。

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

辦公室軟件介紹 - 筆記工具

繼續生產力工具系列，今次介紹的是辦公室筆記工具。

筆者在成長過程中，不同時段也使用不同的工具作筆記。最初的時候是用筆記簿，好處是把所有筆記紀錄在一起，壞處是難於搜尋，試過做目錄，算是初步解決，但也不很方便。

後來感覺用紙筆的方式還是有所不妥，正式改為使用電腦去記。用紙筆記的統統也都轉用電子紀錄，當中有用過word、excel，簡單連notepad也有，搜尋算是方便了。但這時候發現筆記還是太多，用key word搜尋會找到很多紀錄。而且同一件事情，用不同角度看可以有不同的歸類，尤其是隨時間變動，這種情況出現更易發生，導致經常要花時間重新整理，效率不太好。

至於現在，自從發現了Microsoft OneNote後，基本上能滿足筆者的所有需求，暫時亦未有發現其它可取代的方案，簡直算得上是如獲至寶，本篇也就分享一下OneNote的好用之處。

首先是「分頁功能」，OneNote 入面的分頁基礎可分三層，最高層是筆記本，第二層是章節 (Section)，最低層是分頁 (Page)，用家可以按使用筆記範圍決定如何編配分類。比如說筆者現時所跟進的項目來自幾個不同部門，每個部門有若干項目條線並行，各個項目條線有定期會議，筆者就會用最高的筆記本層分開部門，章節分項目條線，每個Page則是每次會議的紀錄，或是一些自己整理的notes。而無論怎樣擺放，也很容易就透過搜尋功能找回筆記，這對筆者來說尤其重要。

另外一個好用的是 Input Format 的多樣性及自由度。開啟OneNote基本上是先見到一張白紙，上面可以Type Free Text，可以繪圖插圖，Word 的Text Format 基本上也是有的，也可以加Table 作簡單列表當Excel 用。最重要的是每一個這些element 也是可以在同一頁上隨意移動，沒有Word或Excel的分行限制，換言之take notes 時可以任意寫，最後整理時把有關的搬到一齊就可以，這個很符合mind map 的思維模式（事實上筆者也經常用OneNote來做Mind Map）。

還有就是OneNote 超可靠的同步機制。鑑於Word, Excel以至PPT 都是為群組share 而設，本身在sharing方面就有一定的限制（例如要save 才會commit change）。OneNote是主要以用家個人使用而設，online sync 基本上是real time自動的，這樣在不同電腦上延續工作就變得相當簡便。尤其是如果公司有使用Microsoft 365，在不同電腦以至Web Access 都可以同步，工作就更加不受platform 所限。

還有一些就是能夠連接其它Microsoft Office 工具的附加功能吧，例如待辦事項，連接Outlook 上的工作，複本note image製成電子郵件，紀錄audio 等，不過這些筆者也不多用，不作詳細介紹。

當然也要說一下，以上所說的OneNote起碼是2010 打後的版本，如果機構還停留在2007 甚或更前，那最好還是先提升一下，跟一跟上時代的步伐吧。

淺談「信息化」(「簡化」篇）

上兩週分別介紹了「無紙化」及「流程化」，兩者都是「信息化」的手段方法，本週繼續寫的是「簡化」。

無論是「無紙化」及「流程化」的項目，背後其實都需要有一個很重要的思維，就是我們並不是簡單的複製現有表格及流程到系統上，亦需要在項目過程中進行「簡化」。

在「需求分析入門 - 電子表格」的篇章中提到，很多時候紙質表格經過多年沒有整合或Review/修整，當中很可能有大量重覆的欄位，另一可能則是有些欄位已不再需要。所以在「無紙化」項目中，我們要切記不可直接複製，更要看的是合理性及可用性。在現今世代，更加應該考慮的是用戶體驗的流暢。

例如一張現有客戶申請附加服務的表格，紙張表格很多時要客戶重覆填寫個人資料，這個對電子表格來說是完全不需要的，既然已經是現有客戶，所有這些資料都應該已經儲存在系統內，根本沒有需要再問客戶。而即使客戶資料真的有所更改，亦應該透過申請更改資料的流程進行，切勿把表格設計成更改資料和申請附加服務bundle 在一起。

另外，我們要理性地分辨現有表格上需要填寫不同資料的背後原因。紙張表格最初設計很可能是為減少不同樣板，才把多個用途的申請放在同一張表格上，但在「信息化」的世界，我們更應該考慮的是把功能服務合理切割，並按實則需求而調用適當的服務，需要客戶提供的資料，應按實則背後原因而定，這些都可以透過定義系統邏輯來實現。

「流程化」也是類似的道理，在現有流程中，按服務實則需要檢視有哪些部驟是必須的，哪些為不必的。亦需要把不同服務的流程合理切割，把可重用的流程變為獨立service，切勿把沒有必然關係的工作bundle 在同一個流程上。

另外，也要考慮流程中的交接點，即由一個party 轉交到另一個party 的節點，原則上是愈少愈好，同一部門應盡可能一次過完成所有工作，避免多點接觸同一個case。流程在設計上更要切忌製造可能出現loop 的情況，避免部門之間互相射波。切記流程並不是對話框，有問題有escalate的出口，而不是無止境射給別個部門。

當然以上種種考慮，在僵化的制度或不肯接受改變的機構內是頗難執行的。我們需要的是開放，能夠接受新事物的態度。在筆者的朋友圈，相信有不少已晉升至初級或中級管理層，希望進來看這個Blog 的朋友也努力在自己的岡位上牽動改變，實行「小改變 大改善」。

關於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架構的方案，項目需時太長會很難支持新增業務，遷移風險也頗大。