軟體架構設計鮮思維－軟體主機板的架構設計

王克明／信仁軟體設計顧問中心軟體架構師，機械化師文書官、系統工程師、Oracle DBA、IT部門副理、講師、顧問

某一具規模的製造業廠商，採購某家 ERP 產品，並委請該 ERP 廠商作整體系統資源規劃，以整合該公司內部既有 CRM（Customer Relation Management） 與 HR（Human Resource） 系統，同時又外購了 Workflow 產品，打算利用整合的解決方案，並降低建置的成本，以提供公司內部客製化的 「供應鏈（Supply-Chain）」 製程服務。

有趣的是，該製造業資訊部門的 IT 主管，認為整合既有的系統，是採購 ERP 產品時應該 「附帶」 的服務，而且並不覺得資訊系統的整合，會有何技術上的障礙，當然，在採購該 ERP 系統的前期，也已經請 ERP 廠商做過測試，確實可以擷取各資訊系統資料庫內的資料，並 「餵入（Feed）」 至 ERP 的資料庫系統內。

災難開始發生了，上線初期，竟然連第一個企業流程（BP, Business Process）都無法正確執行，更糟糕的是，連問題出在哪裡也不知道，當初評估該 ERP 產品時，明明功能可以符合該專業領域的要求，並且在測試 ERP 系統的內部功能時，也沒有問題，但為什麼要整合其它系統時，就問題層出不窮，甚至到後來，根本就分不清楚問題是出在 ERP 系統，還是原有的系統內。IT 主管焦頭爛額，開始責怪負責系統整合的 ERP 廠商，沒有盡好整合的責任，並要求限期內解決問題；但廠商也有話說，認為客戶單位一直在變動需求、提供的數據不正確，又如何能做好系統整合？

結局可想而知，雙方各說各話，各據其理，客戶單位認為系統無法上線，拒絕交付尾款，但 ERP 廠商認為已經建置好 ERP 系統，沒有道理客戶不付款，因此雙方鬧得不可開交，甚至上法院打官司。而一打官司，我們也知道，這就已經造成了雙方 「雙輸」 的局面，除了曠時費力，當初 IT 主管不肯再額外負擔系統整合的建置預算，省下一些成本的結果，卻讓已投入的資源，包括人力與財務，都給耗費掉了。更重要的是，問題仍然無法解決！而這樣的戲碼，卻是在業界內，一而再地重覆上演著。

問題出在哪裡？
最大的問題，就是客戶單位與 ERP 廠商都只站在各自的角度與觀點來看待系統整合。ERP 常會以 「自我本位」 的角度，以 ERP 系統為中心，來整合其它的系統 （同樣地道理，若由 Workflow 廠商來負責系統整合，那勢必會以 Workflow 系統為整合的中心。）；客戶單位的問題是，系統整合是屬於整體性的架構設計範疇，不能單純到將系統的整合交給單一的廠商來負責，而是應該自己接手，也可能是委外專精於架構設計的系統整合廠商來負責。

筆者舉業界最常通用的「資料庫整合」的解決方案為例，來說明所謂「局部觀點」的架構設計下，所衍生出來的問題。

舊思維—草本植物的資料庫整合
從 ERP 廠商所提出的整合方案，係以 ERP 系統為中心，再由其連結呼叫其它的系統，參考圖1，從應用系統的角度來觀察時，廠商往往不會注重系統與系統之間相依性關係（Dependency）的設計，他們所想到的，只要能把資料串接起來，完成工作就好了。所以我們觀察圖1，會發現到應用系統之間往往會互為呼叫，也就造成了雙向的相依性關係，而這也正是系統的高耦合 （Coupling）性、彼此之間糾纏不清的元兇。

再來觀察實體系統的整合實做面，參考圖2，傳統軟體廠商的整合解決方案是將各系統的資料庫，想辦法整合為單一的資料庫（Universal Database），尤其，更會以 「自我本位」 的角度來整合其它系統，例如 ERP 廠商，一定是以自己的產品為中心，來整合其它系統，將資料庫匯聚成為單一的共用資料庫，此種架構設計讓我們建構出眾多的『草本植物』型的系統，像稻子一般許多葉子（以表單為主的應用程式）直接銜接到在泥土裡（即資料庫），當資料庫內表格結構一有變動時，各表單的應用程式都會受到影響。因此，整合資料庫時，會影響到許多既有的應用程式，成本極高。此種思維習慣和分工策略並不能充分發揮Web的巨大聯結（connection）潛能，而且未能包容既有系統，無法保護過去的投資。

當然，也有一些大型系統的整合，是採購 EAI（Enterprise Application Integration）產品來解決上述資料庫共用的問題，EAI 的實作方式，可能是透過「訊息匯流排（Message Bus）」，或是透過EAI產品所提供連結至各系統，如SAP、Oracle、Notes …等的配接器（Adapter）。但即使採取 EAI 的解決方案，衍生的問題是，當客戶單位採購某知名產品的 EAI 後，不只是採購成本非一般企業所能負荷外，同時也代表了，整合系統會被該產品給 「綁住」。

請記得啊，系統的整合，首重整體的架構設計，而架構設計，是需要由專精軟體架構設計思維的架構師 （Architect）衡量各種構面的考量，加上創新的思維，才能調和整體系統的架構。EAI不是不能用，但是，架構師懂得「用」了它卻不會讓系統給綁住，是有配套的措施與應用的場合與時機的。舉圖1為例，若系統整合者，根本沒有考量「相依性」分析的設計思維，那麼，用了再好的工具，應用系統之間，還不是「藕不斷，絲更是盤根錯連」，永遠也理不清了。

以客為尊—軟體主機板的整合架構設計
顯然，從自家產品的角度來看待整合時，都是以「自我」為中心，而各家軟體廠商均欲成為整合的「霸主」，彼此誰也不服誰，在各家紛爭不擾的情況下，系統整合如何能談得上「整體、和諧」呢？ 放棄「自我本位」的觀點，試著以「同理心」從客戶的角度來看待系統的整合，則整合的 Solution 卻是意外的簡單！

「從客戶的角度來看時，所有的子系統均是一視同仁的，客戶不希望因為其中一個子系統的抽換，而牽連到其它的子系統，減少其耦合度，以避免複雜無法維護而不可收拾的結果。」

在現今的潮流中，我們不再以資料庫整合為滿足，相反地，我們必須要找出一個企業中的共同應用程式架構，讓這個架構能夠滿足企業主對於資訊的需求，讓資訊武裝企業決策者的決策，強化企業的指揮體系。共同應用程式架構，是要能動態反應企業的決策需求，快速組裝企業流程的服務，才能創造出無與倫比的價值與魅力，而事實上，共同應用程式架構本就應該具備以下兩個特性：
●讓異質性軟體系統整合為一體；
●虛擬（virtual）與企業組織（physical）融合為一（converge ）

依照這兩個特性，我們必須要想辦法讓異質系統整合在一個遵循標準的架構之下。

這就如同美國國防部所提出的DoD AF（Department Of Defense Architecture Framework）標準架構般，在企業內部的整體架構，也必須要架構出類似C4ISR的指揮體系。這個共同應用程式，也就是本文的主題：軟體主機板（Motherboard-based Architecture）。
參考圖3，在這個架構當中我們使用一個虛擬的軟體主機板 （Motherboard） 來進行系統整合，這個虛擬的主機板均是採用最現代、最摩登、最契合現實的國際標準，包括了：
●標準介面技術：Web Service-Based （XML/SOAP）
●標準元件技術：Component-Based （ .Net/J2EE/Object-Oriented）
●標準架構技術：3-tier （N-tier）的架構
●標準文件規格：UML （Unified Modeling Language）
●標準開發程序：UP （Unified Process）/Agile
●標準整合效果：PnP （ Plug And Play ）

在這些標準中，我們可以看到由於Web Service的興起，使得大部分的系統，都可以使用這種標準的介面來進行溝通。

細心一點的讀者，應該可以發現，與圖2不一樣的地方是，所有子系統是不允許直接相互連結的，而是透過主機板的 「協調」 與轉派。這樣的設計效果，就在於系統彼此之間均看不到，這同時也是一種 「封裝 （Encapsulation）」 的設計思維，所以，任一系統的抽換，均不會影響到其它的子系統，而形成了所謂的 「PnP」 的抽換效果，這也就是為何將該整合體稱之為 「主機板」 的原因了。

整體系統的架構驗證—快速雛形（Prototype）開發
IT 技術人員最擔心整合架構是超出他們的技術想像之外，所以筆者常會遇到許多質疑的問題：「若是異質的系統，彼此之間該如何連結」、「若是利用 Web Service，該如何解決交易處理的問題」、「子系統的介面（Interface）無法標準化，又該如何決定溝通的介面呢？」

筆者永遠都是先確定架構目標後，再來決定該 「如何（How-to）」，當然，這個架構目標基本上，筆者在心中大約心中已有底，需要配合現實上的哪些平台技術來達成。不過，確認目標、找出手段後，仍就必須「執行」，這是最現實也最重要的。「不行不能知，惟行而後乃能知其知之真偽與是非也」。

「系統整合」的最佳驗證即在於「實踐」，架構師應以具體的行動展示而能讓客戶與團隊內部接受，消除疑慮，且提昇團隊內部的信心。 『雛形開發 （Prototyping）』是展示「系統整合」的最佳利器。

例如圖4，係利用使用案例模型 （Use Case Model）表達整體架構的系統整合，筆者一定要求，當利用使用案例模型建構出整合系統的 「框架」 後，馬上就要實作 2~3 個使用案例，在最快的時間內（一般不能超過一個星期），從需求、分析、設計至實作（含功能測試），產出 UML 設計圖與可執行的應用程式碼，不僅可以驗證架構，同時又在設計圖中，表達了系統基本的結構（Structure）設計，好處多多。

在此筆者以一個「客戶服務」主機板的架構設計為例，來說明該系統「拆機」的服務案例。

使用者可以透過Portal要求拆機，Portal則透過 客服主機板 請客戶管理子系統提供客戶合約，並且通知Billing子系統暫停計算客戶帳單，且利用Workflow子系統通知工務人員拆機。

而當工務人員拆機完成，則透過Workflow子系統作一個確認，再由Workflow子系統通知客服主機板 終止客戶合約，此時，客服主機板 也會協調客戶管理子系統終止客戶合約，並且請求Billing子系統結算客戶帳單。

這個拆機的服務，可以依據客服主機板的架構，透過標準的UML 使用案例圖表示如圖4。

基本結論
如同「第五項修練」一書所提及，侷限固守本職性的思考與缺乏整體思考的主動積極，是造成組織學習智障的主因。因為每一個被整合的系統，都是各司其職的 「局部」，若需要這些局部系統的動態合作，來完成整體性的服務需求，勢必要先能以 「整體」 的角度綜觀全局，再來決定這些局部系統各自的責任。而跳脫局部的思考，以大局觀為重，架構師 （Architect）要更能以大格局宏觀的角度，放棄本位主義（不以自家產品為整合的中心），如此，才有可能達成 「整體」、「和諧」、「創新」 的整合架構。

在 「Breaking Windows（中文譯名：比爾蓋茲教你透視微軟）」一書中提到：
e化的網路應用系統必須符合四大特性：「簡單、異質、彈性、寬鬆連結（loose coupling）」

站在以客戶角度所看待的系統整合，所架構的 「軟體主機板」，即有上述提及的四大特性。就如同有機體一樣，異質系統整合的大格局就會是：有機成長、無限繁榮！

與硬體產業較不同的是，硬體的週邊設備及組件均有標準的介面架構在以主機板為中心所組合而成的 PC 系統。而軟體應用系統的介面卻是相當的模糊，模組（Module）與模組之間，並不容易釐清標準的介面何在。有鑑於此，逐漸已有國際的組織如 OMG 在訂製所謂應用軟體標準的介面，例如有 Workflow 的 WfMC 標準，PDM 的 Enabler 規格等。但是否有標準應用程式的介面規範，還不是最重要的，重要的仍是，設計師是否真有用心於介面的設計。