2011年6月7日星期二

SOA架構在企業管理軟件上的“落地”

SOA架構在企業管理軟件上的“落地”

http://www.asiaworld-expo.com

編者按:SOA(面向服務的架構)理念起源于十幾年前,卻因技術成熟火于近兩年。當然不可否認,SOA大作“架構”層面的文章,本身無疑是一種撬動市場需求的由頭,但用戶們也切實在宣傳中看到了簡化IT、擺脫信息孤島的希望,更有先行者勇于“嘗鮮”,率先試水SOA并帶來了顯著的回報。

但畢竟,用戶從來沒有打算過將精力全部集中在一個IT項目上,企業的業務仍然占據著主導地位,是用戶關注的核心。所以SOA雖然能夠為企業帶來諸多便利,但真正用起來的時候,究竟是該直接引入SOA架構的應用、在需要調整的時候交給別人來做;還是自己搭建一個基于SOA架構的“應用組裝中心”,凡有需求一律自己動手?

在廠商不斷修補完善SOA標準和落地技術的時候,一項真正可用、好用,易于規模推廣的解決方案卻在用戶眼里顯得原來越重要——我們什么時候能把SOA用在手里,而不止充當旁觀叫好的角色呢?

  想來,“SOA”這個提法似乎是從2005年一下“冒”出來的,帶著“服務”、“架構”、“中間件”,甚或“企業服務總線”這樣聽上去必將大動干戈的一系列新詞匯席卷了用戶的視聽空間。

  然而,SOA反復出現在人們的關注焦點上并不意味著就能夠很快實用化,夢想的一道光照進了現實,現實在渴望夢想的同時,還要知道如何將它牽引過來,打造成形。

應用DIY——看上去也不簡單

  SOA,即“面向服務的架構”。顯然,它不是一個規范或標準,也不止是一種技術。在架構層面做文章,意味著將IT理念進行改朝換代式的躍遷。

  眼下,全球化經濟趨勢迫使企業不得不面對多變、且愈加激烈的市場競爭環境;中國GDP數值更是以每年兩位數的百分比增長,這樣的速度,任何一個企業都需要將“應變”二字作為自己的常態戰略——何況“應變”一詞稍顯被動,早有先行者將主動“創新”奉為座右銘。但畢竟想法上的創新相對容易,而接下來其他方面如何支撐和實現創新,才是真正的關鍵所在。

  為了讓企業用戶的IT系統靈活應對業務的變化,最好的辦法是改變傳統應用開發的方式:將完整業務功能“打碎”成為足夠細分的功能小塊,塊與塊之間可以彼此以松耦合的方式連接。這樣,任何業務的變化都可以用功能塊的新組合方式來應對,其重組過程比重新開發整套應用要迅速和容易,相應的成本也更低。能夠實現這一系列新開發方式的架構,被稱為SOA。

  實際上,人們對這樣的模塊化設計理念并不陌生,如果有一天,應用之間能像PC兼容組件那樣拼拼插插就得到一套個性化的解決方案,那無疑是開發部門的解放日,只是這個層面上的“DIY”顯然涉及到了業務架構這樣的核心問題,技術和用戶組織結構需要諸多配合才能順利實現。

  而CIO們都明白:凡事如果跳出了技術的圈子,涉及到人和管理,就沒那么簡單了。

分解SOA——五方面實現

  Gartner的預測數據指出,到2010年,基于SOA架構的核心應用將占到總體應用的80%。這一比例明白無疑地宣告了SOA架構是趨勢性的,將成為未來應用設計的“主流聲音”。

  既然這樣的應用有一天終將走進用戶的服務器,進而關系到每一個人,那么用戶就不得不關注SOA本身,特別是處于改革或迅速發展階段的機構或企業。

  北京地稅信息中心的楊濤主任結合金稅三期建設談技術關注點的時候表示,金稅三期在系統集中和整合過程中,為適應目前改革的目標以及稅務體制改革,就必然要關心SOA架構,在SOA架構下整合現有系統。江蘇地稅信息中心的楊旭主任同樣認為企業服務總線(ESB)和SOA是稅務信息化需要考慮的內容。這對于金稅三期之后,稅務部門向服務職能轉型,提升納稅人服務能力至關重要。

  中國移動業務支撐部規劃處副經理寧宇認為,一方面SOA是業界關注的技術問題,另一方面,對于用戶來說,其理念將更有幫助。一個靈活的架構帶來的效果是后續業務的輕松實現,這對于像中國移動這樣不斷推陳出新的企業來講至關重要。

  雖然大家一致關注著SOA,但實現SOA理念至少需要五個方面的調整,不妨將它們分為兩個層次來看待:

  組織架構層面包含三點:人、信息(或知識)與流程因素。梳理人的角色,納入適應SOA的架構;以流程串聯人、疏導信息。做到這些,是企業應變和讓組織跟上IT系統變化的關鍵,也是讓SOA發揮作用的必要條件,其中必然需要企業做好流程管理項目(BPM)。

  在應用層面之下,可以統稱為技術層面,包含實現應用復用和彼此聯通兩大內容。它們是SOA的特征和優勢所在。在這里,集中了從SOA規范和標準到諸多中間件產品等一系列技術因素。當技術和組織兩個層面可以順利契合的時候,SOA架構才算具備生命力。

用友UFIDA U9商業應用套件——業務模型層面上的“第一款”

  既然SOA是趨勢,必然早有IT廠商為搶灘頭陣地積極準備。縱觀當前倡導SOA理念的企業應用廠商,SAP早已具有NetWeaver開發平臺,這是一個支持所有SAP產品運行的開放性平臺,并在2005年底就已經號稱以此平臺完成了當時所有產品的開發;Oracle的Fusion架構多少帶了一些“集成”的味道,雖然如此,旗下各個收購品牌的產品也紛紛納入這一架構下,畢竟帶來了統一互通的優勢;國內方面,金蝶BOS平臺也于2003年誕生,正在積極向客戶和第三方推廣。

  然而,雖然各方動作多多,卻始終沒有一套完整成型的企業管理套件面世,企業用戶零散地開發或添加著“SOA架構產品”。本質上說來,既然SOA架構已經將整個業務功能化整為零,變成了一個一個的功能塊,那么用逐步添加塊的方式逐步重現業務需求在方法論上也未嘗不可,只是這樣的自下而上的過程沒有一份完整的業務架構視圖,缺少戰略指導、且做且看的辦法最容易導致的后果就是“得非所想”。

  這樣的局面被國內企業管理軟件廠商——用友首先打破了。就在上周五,用友在北京發布了它早已對外透露信息的一款“完全基于SOA架構”的企業管理軟件——U9 1.0版本。

  “U9稱為全球第一款完全基于SOA架構的ERP商業應用套件,是當之無愧的。”用友副總裁兼U9首席應用架構師的黃義璋對記者說道,“研發U9的工夫不在于SOA架構,而在于SOA架構怎樣在業務功能上落地實現。”

  作為U9研發本部總經理,黃濤在介紹U9的時候將SOA架構淡化為了一個視角:“U9的研發用了4年多,其中的重頭戲基本在于從SOA的角度審視和重新定義業務的問題。”

  黃濤談到,整個U9開發小組在2004年度里只做了一件事:和最終用戶們一起探討、提煉了超過300個業務模型,使之符合SOA架構。這意味著將業務模型分解,定義出顆粒度合適的獨立服務和動作模塊;進一步,將它們與其他業務的模塊進行比較分析,合并相同的服務或動作(實現“復用”);最終將新的服務模塊以合理的信息流程串聯起來(實現“聯通”),再次成為一項完整的業務,并根據不同行業特征,整合各項業務流程形成方案,打造出SOA基因的U9。

  無疑,相比目前基于開發平臺的許多零散SOA架構應用,U9的整體性更強。但比這更重要的是,U9在業務分析以及SOA架構下的模型構造方面進行了一次實踐——雖然這樣的實踐是否“最佳”,尚需U9用戶在自身的應變過程中考驗,但用友畢竟做了一件別人沒做過的事情——或者按照黃義璋更“謹慎”的說法:“至少沒人在中國、對中國企業的業務做過這樣的事情。”

  U9的把自己的優勢定義在對SOA的“完全發揮”,有了新的業務模型視圖,用戶對SOA的理解可以稍稍擺脫“管中窺豹”的境地了。

人、信息、流程——SOA留給用戶的“作業”

  用戶如何用上號稱“完全SOA架構”的U9?答案是:不需升級,透明使用。

  說到底,應用雖然戴上了SOA的帽子,卻在現階段不會影響硬件設施的布置(但基礎設施的跟進是遲早的事情);同時,如果用戶不打算自己培養團隊開發SOA應用,也沒必要過多考慮修改軟件層面的內容。

  IT系統仍然是為用戶解決問題的工具,不論是不是基于SOA架構。U9為已上ERP的用戶提供了“透明化”的升級方法:如果用戶愿意在新系統上使用以前ERP的數據,只需要用專門的軟件對以前的數據做一次“翻譯”,使之兼容U9即可;如果不需要這些數據,那么用戶部署U9的過程將更加容易。

  但既然是新的架構,必然包含了新的內容。黃義璋解釋,這樣的“新內容”將在企業需要應變創新的時候表現出來,同時這也是U9留給用戶的一道“選答題”:雖然用戶不做變動也可以使用U9,但開展流程管理、使之納入SOA架構,這些將為組織帶來迅速應對未來變化的能力。

  所謂技術推動文化、生產力影響生產關系,大概就是這樣的表現。

聯通、復用——遇事何必躬親

  一旦變革來臨,SOA架構的產品將如何應對?黃義璋建議用戶在這樣的時候將產品交給IT廠商或第三方來處理。

  “我們的目標是把用友打造為一個‘業務應用組裝工廠’,輸入需求,輸出應用產品給用戶。”黃義璋的看法是,處理技術層面之下的事情,用戶采用外包的方式會更好,專業的IT服務可以提升SOA架構的穩定性和安全性,解決應用復用可能帶來的問題,“不同服務組件之間的組合需要使用統一的技術平臺,在用友U9上,這一平臺被稱為UAP for U9。雖然這一平臺作為管理門戶也提供給用戶,但考慮到使用難度,其開發包卻是可選件,需要一定的培訓才能用好。且新組合得出的業務應用也通常需要測試才可以上線運營。”

柔——則難管

  雖然U9的發布將大型的SOA架構應用變為了現實,但SOA架構本身面臨的某些問題仍然需要用戶特別注意。

  柔性和可管理性一向是矛盾的兩極。在SOA求得柔性的同時,可管理性必然面臨著一定程度的下降——而這同樣是企業級用戶看重的問題。

  對于SOA架構而言,普遍的質疑之一是性能管理難度大。在這一架構中,由于程序以服務形式進行封裝并與其他模塊聯通,這種復用導致的復雜性讓程序性能的準確評測產生了困難;更進一步,性能指標污染現象也會讓運維過程中的故障排查和解決成為一個難題。在越來越強調“可用性”的今天,SOA架構是否適合某些關鍵應用就成了用戶不得不權衡的問題。

  當然,任何事物總有兩面性。如何針對業務環境智能地解決問題、開展應用服務管理,從而提升新架構的可管理性,保證業務的順利安全,或許這正是SOA呈現自身優勢的同時,對用戶和IT廠商的一個新的考驗。

記者手記:“基因”工程——成果不止ERP

  許多人說SOA是ERP的未來,U9的發布可能恰好證明了這一點。

  但從SOA架構的角度想想,SOA何止是ERP的未來!管理本屬組織行為學范疇,既然如今SOA打造的IT系統已經能將模塊顆粒度細化到“動作”層面,那么推想開來,無論任何組織行為都可以通過IT系統實現支撐——只要其中涉及了“人、信息、流程”。

  這樣的疑問得到了用友二位黃總的肯定答復——用友很可能基于UAP平臺和業務模型分析去開發新的管理產品。看來,SOA將不僅為企業用戶帶來收益,也是IT廠商自身的一次學習和變革過程。經過SOA的洗禮,IT應用的開發方和使用方兩者都將發生巨大的變化。

  然而話又說回來,如果SOA新品可以如此簡單地成形,那么如果明天或者明年,SOA架構的ERP產品滿街跑,或者SOA架構的CRM和SCM之類層出不窮,再或者連“叉叉OA架構”之類的科幻名詞兒也蹦出來了,用戶該如何應對?

  顯然不能被概念忽悠了!還是要看業務的東西。

  如果IT廠商在忽悠新思路的同時,也能深入體察一下用戶業務,將業務視圖畫得比用戶都精準到位,相信其產品也必然不差——能讓用戶用好的產品,就是好產品。在這樣的基礎上,至于通過SOA拿出來的是ERP、CRM或者其他什么,一律只是一種技術的排列組合。在應用層面,真功夫將是如何駕馭技術,實現核心目標——即用戶的業務需求。

  而U9的出現,說明用友已經在核心問題的探索上邁出了堅實的第一步;SOA,則是一種視角和方法論。




没有评论:

发表评论