[Software architecture]系統整合的五大問題
談到系統整合，常常會聽人家說，沒有技術問題，只有政治問題，這句話說得沒錯，本來這篇想談政治問題，但我想我還是先把技術問題給說一說吧，之前參與過一個大型的整合案，主要是要提供多項系統間有個統一個整合介面，而在提出解決方案前，我們還是要先了解一下過去在系統整合上遭遇了多少的問題，這些問題我大致上把它分為以下五類：
- 整合機制不一，佈署困難
由於我們是開發套裝軟體，在考量架構時一定是從產品的五大支柱中找尋相關問題，這部分可參考：[產品開發]軟體產品開發的五大支柱
對一般的系統來說，若是一次性的佈署，這壓根兒不是問題，但對套裝軟體來說，多種系統，多種佈署方式，為了整合又要多學幾種服務的安裝方法，裝好後還要測試是否正常運作，只要步驟太過複雜，一般人根本休想自己安裝了。
- 整合服務的版本管控困難
若我們是單向整合，則版更時只要版更一個服務即可，但若是雙向整合，兩個系統都有提供對應的服務，若兩個系統的整合服務版本對應不起來，就很容易出現錯誤，例如以下三種狀況：
- 修改一個參數
- 修改一個傳遞欄位
- 修改欄位對應
若撰寫實沒有討論好資料的交換格式，沒有預留好擴充性，到時候都是一場可怕的噩夢。
- 客製化困難
在A系統中，與B系統整合相關的程式有10支，若今天客製程式想要多傳一個參數、一個欄位、一組資料，我們可能會同時修改到這10知相關程式，但其實我們只是想要多一些些功能罷了，卻需要花費這麼多功夫。
- Log訊息落於各系統，追蹤困難
當整合上發生錯誤時，我們如何追蹤問題的來源是錯在A系統還是B系統，一來Log的格式不同；二來若這兩個系統是由不同的團隊開發的，該由誰來接手處理這個問題，最慘的狀況就是兩個單位互踢皮球，問題拖了許久才被解決，對客戶的影響性很大。
- 整合資料不一致
跨系統整合大多是跨越不同的資料庫，而若沒有良好的transaction控制，資料的不一致會時常發生，如下圖所示，整合過程最少會有以下六個動作，只要任何一個部分發生錯誤，則整個交易應該被rollback才是，否則就會有異常的資料出現。
講到整合的方案，過去若有10套系統，彼此之間的整合方式可能多達C10取2，共45種方法，也就是彼此之間資料的交換方式共有45種之多，這種整合環境大概任何看了都會想哭吧，如下簡圖：
而若要將系統間整合的接口單純化，最容易的方式就是星狀整合，所有的系統透過一個Service broker或者Adapter來進行溝通，如下簡圖，當環境愈複雜時，效益愈明顯。
中介的服務除了做為橋接外，還可以做為訊息管制的中心，實際上可以做的事情就很多了。
 |
游舒帆 (gipi) 探索原力Co-founder，曾任TutorABC協理與鼎新電腦總監，並曾獲選兩屆微軟最有價值專家 ( MVP )，離開職場後創辦探索原力，致力於協助青少年培養面對未來的能力。認為教育與組織育才其實息息相關，都是在為未來儲備能量，2018年起成立為期一年的專題課程《職涯躍升的關鍵24堂課》，為培養台灣未來的領袖而努力。 |
