對銀行IT而言,需要一個整體性的架構,不僅是概念,產品,而且還要指導如何實踐,以達成藉由IT的彈性而滿足業務的彈性.然後事實真有那麼簡單?理想舊究竟要花多少的金錢與多長的時間去達成才算完成?還是這是一場沒有終點的旅程,不必太強調結果,只要重視過程就好?.....
前言
SOA對大規模系統是一個相當好的架構.既有分散處理的優點(系統彈性)又有系統間整合的規範(業務彈性),是IT應用的大同世界.事實上要達到這種境界並不簡單,所幸幾個主要廠商IBM,SAP,TIBCO,ORACLE,MICROSOFT,BEA大都遵循J2EE,.NET作為應用系統架構的標準.短期內雖然看不到成熟的應用,但假以時日必可見到完整而成熟的產品線,從設計模型,開發工具到必要功能產品一體化等等滿足使用者快速部署(deployment)應用系統的境界.只不過筆者有一點要提醒諸位,SOA的架構下即使各產品的整合性已經趨近成熟,但是運用這些產品部署應用系統的還是需要依賴人,改善一個流程,從規劃設計到實際推動,牽動的是一群人(業務分析師,系統架構師,技術專家,業務人員等等)這群人彼此各有主觀立場,背景互異,觀念水準參差不齊,如何讓人"標準化"才是一個大問題.
建構
從建構系統的角度看SOA,當然是以TOP-DOWN的方式較一氣呵成,擺脫現況的包袱,似乎較為有效,但是現實可能不是如此.SOA不可能僅是拿來作作小系統,而是大規模系統才看得到效益,而且是漸進的效益,因此BOTTOM-UP的方式可能是唯一可行的方式.從現有的系統架構下去建構新架構,是並存而非疊床架屋,是逐漸去除而非保護就舊系統架構,在這樣的情況下,SOA概念下的流程,服務,元件才有可能發展出其一直強調的特質-彈性,而這種彈性不僅是新技術下的應用系統,更應包括傳統技術下的應用系統,而這一部份的資產仍然佔整個系統的絕大部份,而這一部份的問題要如何解決才是大學問.
應用
銀行業系統,是由多個不同的業務系統構成,個別的應用系統從技術觀點都是在處理'交易',從業務觀點則是在處理'商品邏輯',這兩者以現有的IT技術仍然被綁在一起,商品設計者只能告訴系統設計者他要的'東西'其餘就是技術人員的問題,在這種情況之下如果使用者要的就是'商品'而已,通常的情況下設計者是可以了解使用者要的是甚麼,而且可以開發出可靠的成品-系統.然而使用者真的是要一個商品而已嗎?事實不然,他們其實是要一個'流程'或稱'服務',過去"要",就硬'幹",反正鐵杵也能磨成繡花針,結果就是大雜燴系統,可用?但不好用,要改?也不好改.如今所謂'複雜的商品'其實正確的說法是'由多個簡易的商品+流程=服務'已經是普遍的需求,如果還用過去的觀念方法,那麼註定要失敗.解決之道只有期望SOA的產品和"真正的專家"趕快成熟了.
結語
SOA不僅是概念,它還是產品,最重要的是去實踐,然而大部份的推動者迄今仍然僅從事概念的宣導,怎麼去往下進行,不是精神或方法不懂--從SOA的精神(Business flexibility & System flexibility)談到系統共同技術標準(Industrial standard),再到應用系統架構標準(J2EE/EJB),往下談到產品的規格判定適用(Product availability analysis),提出建議產業別方案籃圖(Solution map),最後建議從那理下手,逐項逐階段解決現狀包袱(Project proposal),而是實際推動者無法專精於某一產業的運用-譬如說金融IT,所以無法針對該產業的問題對症下藥 ,如果真是如此的話,短期間是無法解決客戶過度的期望,5-10年或許是一個合理的時程吧?至少對銀行IT而言.