案例分析

某一具規模的製造業廠商，採購某家 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)性、彼此糾纏不清的元兇。

圖1、以ERP為自我中心的整合

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

圖2、”草本植物” 型的資料庫整合

當然，也有一些大型系統的整合，是採購 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的興起，使得大部分的系統都可以使用這種標準的的介面來進行溝通。

圖3、”軟體主機板” 的架構設計

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

整體系統的架構驗證–快速雛形(Prototype)開發

IT 技術人員最擔心整合架構是超出他們的技術想像之外，所以筆者常會遇到許多質疑的問題：”若是異質的系統，彼此之間該如何連結”、”若是利用 Web Service，該如何解決交易處理的問題”、”子系統的介面(Interface)無法標準化，又該如何決定溝通的介面呢？＊＊註＊＊

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

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

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

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

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

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

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

圖4、客戶服務主機板的架構設計–利用使用案例圖

在找出了系統的服務後，我們就可以根據這些服務，讓子系統提供標準的Web Service，並且利用反覆不斷的循環，構建出e化企業中共通應用程式的標準介面，讓系統架構得以生生不息，永續成長。

依據UP (Unified Process)的精神，在實際進行設計上，我們採用漸增與漸進(I&I ,Iterative and Incremental) 的開發方式進行設計，並且以使用案例導向(Use case driven)的方式來進行3-tier的設計。例如當我們先挑選申請拆機的使用案例來進行設計，並據此找出每一個子系統(Sub-system) 來實現(Realize)該使用案例的控制物件 (Control Object)、負責與外部溝通的 Web-service 物件、參與該案例的企業本質性物件 (Entity Object) 等。由於規範了明確的介面、所以每一個子系統的實作可以同時外包 (Outsourcing) 給多個 Coding 團隊，子系統之間的溝通，僅要知道介面的規格，就可以各自表述，來完成系統內部之間的結構設計與實作。

（縮略圖，點擊圖片鏈接看原圖）圖5、各個子系統內部的結構分析與設計

讓軟體系統(virtual)與企業組織(physical)融合為一(converge )

在上述的例子中，我們主要是要介紹主機板的基本架構，也就是透過標準的介面讓子系統間進行整合。然而誠如前面我們所說，主機板之所以存在的目的，是為了武裝企業決策者的決策，讓公司所有的單位能夠提供給企業決策者最即時且最正確的資訊。
為了要能夠達成這樣的目的在實際進行主機板架構時，有必要以Top-Down(從上而下)的方式進行設計。

讓我們參照實際組織的狀況，我們可以輕易的發現，事實上，組織的結構自有其層級上的必然性需求；相同的道理，為何在軟體的架構設計上，我們不去以這樣的層級觀念去進行設計？

事實上，DoD AF中所說的作業觀點(OP View)、系統觀點(System View)以及技術觀點(Technical View)也是將所有的觀點都指向支援層級式架構。

因此，我們會將上述客戶服務主機板視作是公司整體架構中的其中一個子系統，並且以整體公司的觀點再進行架構的設計，如下圖所示：

圖6、軟體系統的主機板架構是與企業層級組織融合為一

在這個企業整體規劃的主機板架構下，我們可以規劃出一個e化企業的重大子系統，而在不同層級的主機板下，各自會提供給不同層級的使用者不同的服務。

以上圖而言，在最上層的e化企業主機板所提供的Portal，就可以匯集公司所有的資源，提供給企業決策者整體公司的決策資訊。只有像這樣的層級式架構，才能夠因應環境的變化而快速反應，展現資訊系統的真正價值！

請注意！在實際進行細部設計時，我們仍需要遵循前一節所說的標準進行設計。

基本結論

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

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

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