關於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 絕對是在走對的一步。