gipi的學習筆記-經營管理、數據思考、終身學習

整合，一直是資訊系統一項很大的重點，現在不管哪家軟體廠商提出的軟體架構，一定不會少掉整合這個issue，SharePoint跟Outlook、Dynamic CRM整合；SAP的ERP要跟BI、Salesforce的CRM整合；目的都在讓提高綜效，簡化流程、提高資訊的效益，然而，一直以來整合都沒有萬靈丹，一直沒有人敢說他擁有一套絕對可以確保整合成功的架構或者產品，這是為什麼？

前幾年有個很火紅的議題-SOA(Service Oriented Architecture)，當時有人認為這個概念真的是整合的救星，把系統的功能弄成一個一個的服務，讓服務運作在一個Service bus上，可做服務管理，讓它可再用，有明確的定義與宣告，簡單來說，它是希望建立一種標準的整合概念，然而多年過去，SOA這概念我們仍在談，相信依此概念出發，它也絕對可以解到一些問題，但這比較偏向技術觀點，實際上呢？整合的問題大多不在技術層面上。

整合，大多是跨了兩個以上的系統、兩個以上團隊、兩個以上技術架構、兩個以上的平台、兩個以上的應用領域，在談整合時，技術往往是我們最後討論的，而第一個被討論的會是什麼？是應用領域的問題。

應用領域整合
為什麼這兩個系統要整合？本來ERP系統的資料僅限於內部流程使用，目前希望跟下游經銷商共享部分資訊，所以要跟SCM整合起來。
要有那些整合的內容？要整合庫存、訂單等等資訊。
要做單純的資料交換、流程銜接或者是UI的整合？資料交換是一定要的(庫存、訂單的資訊)，流程銜接也要(下游經銷商看完庫存資訊後想立刻發起訂單)。
兩者整合後應以誰做為整合的發起點？由SCM作為發起點。

一般來說我們會去探討這些問題，這就像整合的需求收集，跟一般系統相同，這個部份如果錯了，整個整合的架構一定錯的一塌糊塗了，這邊最難的點在於，熟A系統的人，不見得熟悉B系統，反之亦然，當出現爭議時，由誰來裁決呢？看似簡單的問題，執行起來卻是困難重重的。

若應用領域的整合內容明確描述後，就會開始進入人員的整合了。

人員整合
來自不同團隊的成員，背景不同、擅長的技能不同、脾氣也不同，在整合時最麻煩的部分在於時程與做法的溝通上，因為不同的系統，有不同的發展與開發時程，當A系統的成員有空可以進行整合時，B系統的成員不見得有空，要協調出一個好的時程就已經很困難了，然後要讓彼此溝通，確認都已經了解了整合規格書上的內容，然後討論作法，這都不容易，過去我們在自己單位內討論自己做的系統，溝通上沒有太多障礙，但當跨越不同團隊與系統後，你說的A跟他想的A可能是兩回事了。

好了，如果人員的整合也都沒有問題，大家都了解該做些什麼了，那接下來才會進入技術架構的整合了。

技術架構整合
如果前兩部分沒有問題，原則上在這邊也不該有太多的問題才是，你會遭遇到的問題可能是我之前寫過的一篇文章：[Software architecture]系統整合的五大問題
原則上架構正確，技術上應該沒有問題才是。

這陣子在討論整合的議題，突然有感。

游舒帆 (gipi) 探索原力Co-founder，曾任TutorABC協理與鼎新電腦總監，並曾獲選兩屆微軟最有價值專家 ( MVP )，離開職場後創辦探索原力，致力於協助青少年培養面對未來的能力。認為教育與組織育才其實息息相關，都是在為未來儲備能量，2018年起成立為期一年的專題課程《職涯躍升的關鍵24堂課》，為培養台灣未來的領袖而努力。