1、系統集成定義
既然要說系統集成那麼就應該給系統集成做個定義，這要做的好處很明顯，至少可以避免我們對集成的概念理解的不同而造成異議，對吧？
那麼什麼是系統集成呢？我給出的定義就是將兩個或兩個以上的由同一個公司或不同公司開發的兩款或兩款以上的軟件進行整合最終形成一套完整的具有被集成的所 有系統的大部分功能的系統的過程，所有被集成的系統被稱作集成子系統，集成後所得系統叫做集成系統；如果集成過程中以某個子系統爲主進行整合，那麼這個子 系統就被稱作主子系統。
概念明確了，以後文中論述的所有涉及到的子系統 、主子系統和集成系統的概念均已此處定義的爲準。
2、案例給出及方案論述
既然論述系統集成，那麼首先我們得至少有兩個系統作爲我們的集成子系統對吧？好，既然這樣那就請允許我虛構兩個系統（我們主要是講理論，那麼對於採用什麼樣的系統對於理論的講解來說影響是不大的）。
圖1 系統A架構
圖 2 系統B架構
首先我們給出系統A，它的系統架構如圖 1所示，其次我們給出系統B，它的架構如圖 2所示。
也許大家已經發現了，這兩圖有啥區別呢？這不長成雙胞胎了嗎？沒錯就是雙胞胎，雖然是雙胞胎但是他們還是有區別的，那麼區別在哪裏呢？很簡單一個是系統A一個是系統B，很明顯是兩個系統，既然是兩個系統那麼無論他們長的在怎麼相像也終歸是兩個系統，就像兩個雙胞胎兄弟，他們再像我們也不能說他們是一個人對吧？所以我完全有正當理有來以兩個架構類似或相同的系統進行理論的講述，毫無疑問這是合法的，哈哈。
話說的有點遠了，起始採用兩個結構類似的系統是有一定道理的，我們不防考慮一下，在我們接觸過的軟件中所採用的架構有哪些是我們沒見過的，無論它採用的是 多麼高深的設計模式歸根結底拆分到最後也都是些簡單的基礎的模型而已。比如我們熟悉的軟件架構，至今也就兩種大的模型而已 C/S 或B/S 再複雜點的會採用C/S 和B/S兩種結構相結合也不是不可能的，這完全取決與我們業務的需要，只要需要或者說只要能解決問題的方案都是好的解決方案。回過頭來我們繼續說我們的系統A 和系統B，他們是兩個完全不同的系統，但是採用系統架構是相同的，都是C/S的系統，他們都有各自的業務服務器和客戶端，業務服務器僅能爲各自的客戶端提供業務處理服務器，而且系統A 和系統B他們所實現的業務邏輯是不同的，至少他們的核心業務是不同的，說的通俗點就是他們處理業務的側重點不同。這兩個系統在各自的應用領域都工作的很好均能滿足各自領域的業務需求。但是好景不長，突然有一天系統A 或系統B有了新的需求，新的需求是什麼呢？新的需求是 系統A 需要具有處理系統B所能處理核心業務的能力，或者系統B具有處理系統A 的核心業務的能力。此時問題出現了？倘若系統A 和系統B恰好是同一家公司研發的，那麼這家公司有兩種選擇，要麼在系統A或系統B上實現B或A的核心業務，或者將兩個系獨立的系統整合用最少的時間做最少的修改來滿足用戶的最新需求。當然還有一種情況就是系統A 和系統B是由兩家獨立的公司研發的，此時解決方案和同一家公司研發的系統A 和 系統B 的解決方案是一樣的要麼在原有的系統上實現另一個系統的功能，或者兩家公司合作將系統進行集成，當然這是商業上的問題我們不做考慮，我再此僅研究如何儘快的滿足用戶的需求。
至此，兩個軟件已經介紹完了同時也提出了用戶的需求：在同一個系統上實現系統A和系統B的全部核心業務。當然用戶完全可以同時使用兩個獨立的系統，我們也完全可以這樣建議，但是本 着客戶是上帝原則我們要無條件的滿足客戶的合理的需求，那麼客戶提出的上述需求是否合理呢？當然合理，一沒有違法二沒有損害誰的利益，相反可能由於系統的 集成回事他們的工作效率提高減少不必要的成本也說不定（因爲很可能由於高度的合理的集成而使客戶的重複勞動減少，同時降低了出錯的概率），因爲我們要無條 件的滿足客戶的需求。
爲了滿足用戶提出的需求，我們前面已經提出了兩種解決方案，一是在系統A 或系統B上面實現另一個系統的核心業務，另一種解決方案是通過系統集成對系統A和系統B進行整合形成一套新的系統以滿足用戶的需求。那麼，很明顯後一種方案就是系統集成，我們最終也會採用系統集成的方案來解決，但是在此我想還是先對兩種方案進行一下簡單的比較。
首先，採用在系統A 或系統B上面重新設計實現另一系統也是一種很不錯的方案，因爲這種做法可以使最終得到的系統更像是一個完整的系統，而且我們還可以在實現的過程中採用新的算法以優化已有的業務處理流程提高系統工作效率，但是無法否認重新編碼會引入新的bug，因爲代碼畢竟是人寫的，人都是普通人誰也無法避免犯錯，既然無法避免犯錯那麼引入新的bug 就是在所難免的，不僅如此在重新編碼實現的是 我麼還要對數據庫進行兼容性設計，不僅要兼容原系統中已有的數據更要能滿足新的系統裏數據共享的問題，因爲原本一個系統數據庫中的數據由於業務的整合難免 不造成數據庫層面的變動，因此數據庫重構也是難免的，因爲我們都知道數據庫和應用程序是耦合度最高的，雖然我們已有很好的策略和技術如ORM 及 數據訪問層技術等，但是這在本質上並沒有將耦合度降低多少，試想當我們的表結構發生一點變動的時候我們同樣要對ORM做新的映射，因此導致的問題是系統中所有涉及到變動的地方都要重新實現，雖然很簡單但是量很大，量大就可能導致問題的出現，進而增加研發調試成本，延長軟件研發週期，因此重新開發我認爲在沒有新的或更合適的解決方案的時候更合適。
其次，是系統集成，系統集成是通過某種手段將已有的系統做最少的改動而達到整體一致統一的效果，在外觀或使用效果上是一致的。那麼集能帶來哪些好處呢？當然好處是大大的，因爲既然是集成那麼我們改動的地方那個就不會有開發時候造成的改動大，進而引入新的bug 的可能性也會降低，不僅如此更因爲我們實在已有的系統上面進行整合，那麼我們就有能裏保證用最少的時間最高的質量來滿足用戶的新的需求。這些好處所帶來的好處已經很可觀了，因爲引入的bug 少就可以保證系統的儘可能穩定，也就是說可以保證用戶使用的過程中系統會穩定高效的運行。以我的經驗來看系統的穩定有時候不高效率更重要，因爲對於數據敏感的行業是不容出現半點錯誤的。
（注：未完，請看下一篇 關於系統集成的設計方案（二））