在第一篇中有簡單的提到，有些顧問公司會提到透過導入SOA來進行業務革新，來收取為數不小的顧問費，這跟導入SOA有什麼關係? 在經由上面服務與ESB的介紹，各位應該也有一點簡單的概念，為什麼這兩者會被人拿出來共同討論了，在這裡，我不會從業務方向來討論該如何導入SOA，這不是我善長的領域，而是採取反向的方式來討論，如果企業對於業務及業務革新沒有明確的定義，在導入SOA時可能造成的問題。
首先，就是各單位業務的重疊與需求的不一致，這在個人的系統建置經驗(不一定是SOA，只要跟企業流程有關，就容易發生)中，發生多次，例如: A，B單位對於相同業務的描述有不同的要求與作業方式，或是，對於業務歸屬何單位有很大的分歧，這會造成系統的建置規劃很大的風險。如果今天我們所建造的是如ERP或SOA這類大型骨幹型專案，此類的問題就會被整個放大，例如一個業務上的定義不清，就有可能造成漣漪的效果，嚴重的話，也可能造成分析上的癱瘓，原因在於無法定義出清晰的服務內容或企業流程，要不就是事後反反覆覆的修改，最嚴重，有可能造成整個系統整合的失敗，而損失金額將高達數千萬至數億之譜，而這類問題的討論很多，我就不重覆討論了，不過，歸納到最後不外乎就是，高階主管的不支持，或是缺乏政治上具有協調能力的決策者，去折衝各單位間利益的不一致問題，這如果要單純資訊單位或外部廠商(非顧問公司)來處理，似乎又太沉重了。
除此之外，縱使專案件成功上線了，如果沒有後續妥善的控管，也可能會在未來造成SOA的架構崩潰，例如使用者不斷的提出需求，但這些需求很可能是業務單位的片面需求，並沒有針對整體企業流程進行檢討，在這樣的情況下，不斷的修改服務，就會破壞原先欲提供的服務架構與作業流程，甚至造成如漣漪般的擴散效果，行之多年之後，最有可能的結果就是不再有服務的觀念，只是一個龐大的系統API連接而已，不過，相較於一開始就失敗的專案，這樣的情況還算好的，至少基礎建設仍存在，只要再將服務與流程加以整理，或許還可以恢復應有的光輝。
行筆至此，整個SOA簡介也差不多介紹完了，其實就我個人的經驗，SOA的建置可能被許多大廠推銷到似乎是大而昂貴的軟體專案，其實只要不是導入到顧問服務(不代表這不重要，但應該依企業需求來評量)，SOA可以比一般人想像的便宜很多，許多相關的軟體，如ESB，甚至有免費軟體可以用，市場的評價也不低，而SOA不同於ERP系統的地方，在於它可以像個有機體一樣隨時間成長的，如下圖所示，逐步將服務納入系統的基礎建設中
透過小規模小規模的成功，加強企業對SOA的信心，並逐步擴大應用範圍， 更重要的是，透過這樣的過程，最終，還可以磨練企業對IT與服務管理的能力與文化的改變，這才是導入SOA的目地，讓IT策略能與商業策略更進一步的結合，而非單純買一套軟體或服務而已。
<<全文完>>
留言列表
