今晚我想來點...客製雲端SaaS應用

文：吳冠輝 2020-10-13

發布時間： 2020-10-13 11:16:00

了解企業應用方案的人都知道，企業應用的特色在於針對不同行業、企業給予「客製化」修改。然而，雲端應用市場強調的又是「標準化」的快速應用服務。於是，企業雲端應用方案就會遇到「標準化」與「客製化」取捨的難題。本文分析企業雲端應用SaaS服務客製範圍、程度及多租戶的數據結構設計方式。

針對企業管理應用的雲端方案，和一般我們熟悉的手機應用商店有些不同。主要不同點在於企業管理應用雲端方案主要是針對企業痛點提供快速而有效的SaaS雲端應用。但是...熟知企業應用特性的人都知道，用戶使用一陣子後，多半會說：「你們這軟體真的不錯啦！只是我們家跟別人流程不太一樣，我們家是.....(以下省略一萬字)。」最後回到主題：「你們這個真的是很好用的！不過......可不可以為我們家做”一點點”調整....，哪邊改一下，流程多一步...(以下再省略一萬字)。」

於是，各式各樣的修改調整申請來到了應用開發部門。很不幸...目前廠商回覆在大部分的情況下都是：雲應用不支持客製。那麼究竟是什麼原因讓大部分的廠商都不支持客製，或者說還是有客製空間，但是會遇到很多問題？以下，就讓我們來探詢。

SaaS應用客制分級

對於企業管理軟體尤其是套裝軟體而言，幾乎都需要針對客戶個別情況做些調改，俗稱「客製化」。客製這件事情可大可小，小的可能只涉及換個首頁LOGO、換個介面的風格什麼的，大的可能要幾乎重新改造流程。當軟體是佈署在客戶自有環境下，這種修改都是可以容易達成的；只是一旦上到雲端上，SaaS應用不再是買斷模式而是租用模式。因此，客製這件事情就變得相對複雜不少。最直觀的體現就在於數據結構：例如租戶A和租戶B都需要針對訂單多一個欄位以記錄更多資訊，但SaaS應用就這一份訂單結構表，要如何才能同時符合租戶A和租戶B呢？一般又可能說分開兩個租戶用兩個不同資料表來處理，但是這樣不斷分割資料表的結果，對於軟體維護工作與系統運維更新造成額外負擔，最後在雪崩效應下，系統將不堪負荷。

依據上面例子，似乎是說SaaS應用不能夠進行客製。事實上，並非完全不能客製，而是SaaS客製能力與客製範疇、技術層次有絕對的相關聯，我們必須分層、分等級來理解這件事情。下表是針對不同程度的能力等級整理結果。

■ 階段一：門面工程中，應用能夠修改的部分主要是介面上的修改，且不涉及資料結構和資料處理邏輯，可以根據不同租戶甚至式用戶認為自己喜歡的風格。當然，LOGO也是可以修改的範疇，下圖是Salesforce.com的介面客製舉例。

圖、企業雲端應用介面修改(資料來源: Salesforce.com)

■ 階段二：提供大量配置可供用戶選擇。但本質上資料處理流程仍是一樣，且不允許個別企業租戶修改數據結構。

■ 階段三：有了根本性的改變。階段三A和階段三B並不是先後問題，而是不同的技術實現路徑。階段三都允許用戶改變和定義自有的數據結構，但是在做法上有很大不同。

(1) 階段三A：是真正意義上的多租戶數據結構。

(2) 階段三B：提供一個不同租戶完整自有環境進行客製，其實在某種程度上已經脫離SaaS應用商品範疇。就像是Google特別作了一個你的公司地圖專門給你用這樣，事實上已經可以算另一個商品了。

多租戶數據結構設計

我們先理解一點，雲端SaaS應用都是使用同一個站台，是採用多租戶結構運作的。租戶(或說企業)運作所產生的數據基本上在同一個資料庫甚至同一個表內，並不是我們所熟悉的客戶擁有自己的環境結構。因此，你可以想像一下，一個客戶基本資料若是只能有一份結構，基本上不可能為了某一租戶的需求額外加一個欄位。即便是我們想要用所謂的”保留欄位”也是難以實現。

那這個技術台階究竟如何踏上？簡單來說，「多租戶數據結構」最重要的特性就是動態欄位技術。如同技術名稱所述：就是某個表的資料結構必須是非固定的。這樣的實現方法有不少做法，最好理解的是表格結構的轉置，簡述如下：

圖、基本動態欄位技術

上圖是最基本的動態欄位技術結構，可以看到資料庫內不配置欄位結構，而是用資料來表達資料結構，這樣便有機會發展多租戶共用一個資料且還擁有不同資料結構。

事實上，這種技術在某些應用商品已經有使用。但這並不是做不到的問題，只是數據轉置並不夠的，還要提供整套的「多租戶數據結構」，包含了metadata設計和管理結構的方案。此外，還有查詢資料、撈取資料、過濾資料、查詢效率...等各種問題，更有甚者，還需要搭配前端的配置結構，整套達成才能說我們達成了「多租戶數據結構」。這絕非一朝一夕或甚至一季半年之功，以下是目前支持這種做法的Salesforce.com的範例：

圖、多租戶結構技術(資料來源：Salesforce.com)

小結

儘管目前大部分雲應用供應商對於客製能力還有很長的發展路程，不過筆者認為不用太執著此方向。一來在市場上使用者本來就會依據本身的需要來選擇租用雲端應用，對於真正需要客製的部分也會討論私有雲和在地端發展的作法。真正單純要把所有資料放在公有雲上的反而是少數。二來在靈活運用的「大中台，小前台」戰略下，每個應用應該不是朝向大而全的發展，而是小而精的應用。客製其實並不是這裡的重點，有效重複使用已有的元件與業務流程，可能才是雲端SaaS小而精的重點所在。過分追求一套適用全部的情況是否又是回到老的僵固思維呢？值得我們討論。