記錄 之前 寫下的 Service Catalog 的概念。

Service Catalog

之前與同事討論 Artifacts Management (AM)、 Config Management (CM)、還有 Provisioning 時，我帶出了 ITIL (IT Infrastructure Library) 裡的概念： Service Catalog (SC) 。SC 負責管理企業內產品服務的 生命週期管理、異動管理 (Change Management)。

依據 SC 定義出適合市場的需求，每個服務客群由不同服務組成，這個組成稱為 Service Portfolio (服務組合, SP) ，例如 SC 裡有十個產品線 (Product Line, PL)，依據市場需求，例如北美市場需要由 8PL 組成，這是北美市場的 服務組合 (SP1)；歐洲市場需要 10PL 組成，稱為 SP2。

另外 SC 規範要有 Versioning，換言之，每個 SP 裡的 PL 都有 Versioning 的指定。透過這樣的定義，可以讓 IT 團隊精準且可有效的利用自動化程序，搭配一開始提到的 CM 與 AM，以及 Cloud Native 相關技術，可以很快速的擴展業務市場的需求。

SC 市場上也有類似的產品，設計用來管理、維護產品線的生命週期。AWS 的 Service Catalog 就是其中之一，它包含 SC 的定義、SP 規範、然後整合了 CloudFormation 做 Provisioning … 不過這套概念不錯，但前提是都是使用 AWS 的產品，才有辦法完整的整合。

導入 Service Catalog ？

SC 通常需要組織到一定規模以上才需要，產品線、系統架構、組織規模不到，導入 SC 很容易變成一個高大上的想法，但是卻完全感覺不到好處以及意義。同時 SC 是個程序性很高的東西，換言之，定義、流程是他的主軸、核心概念。這些概念跟很多專案管理很類似，所以工具不會是重點，重點是如何定義釐清：什麼叫做一個 Product Line？這個 Product Line 的生命週期管理、異動管理。

SC 的重要目的在於多區域、是市場服務管理，本質就是『資訊管理』。透過這樣的制度，讓資訊傳遞在組織裡不會紊亂，透過這樣標準化的溝通與制度，讓各單位可以專心面對市場與業務需求。

SC 導入我個人認為的前提：

• Artifacts Management (AM)
• Config Management (CM)
• Provisioning

這三個都是最基本的，沒有到一定成熟度，是不適合的。成熟度指的不是技術或者實踐，而是組織內對於這些東西的概念，有標準的訓練，讓主要的人知道 AM / CM / Provisioning 是什麼。有了這些概念，談 SC 才有具體的東西可以前進。

延伸閱讀

站內延伸

• 軟體交付的四大支柱
• 聊聊軟體交付的濫觴 談產出物管理
• Artifacts Management

參考資料

• Service Catalog (wikipedia)
• AWS Service Catalog