[信息系統上“路”三部曲]之一
信息系統，用戶主導的時代來臨了！
沒有“銀彈”
沒有任何一種單純的技術或管理上的進步，能夠獨立地承諾在十年內大幅度地提高軟件的生產率、可靠性和簡潔性。
——弗雷德裏克.布魯克斯
這是布魯克斯在1986年發表的經典文章《沒有銀彈》中的斷言。該文一發表，在業界引起軒然大波，遭到許多軟件專家的討論與質疑。
在反對布魯克斯觀點的專家中，庫克斯和布魯克斯的論戰最引人矚目，庫克斯認爲“重用和交互的構件開發是解決軟件根本困難的一種方法”，但布魯克斯認爲庫克斯在兩點上誤解了他的本意。
首先，庫克斯斷定軟件困難來自“編程人員缺乏構建當今軟件的技術”。而布魯克斯則認爲根本困難是固有的概念複雜性，作爲本質上的困難，構思軟件概念性的結構本身就有複雜性、一致性、可變性及不可見性的特點。無論是任何時間，使用任何方法設計和實現軟件的功能，它都存在。
二十年以來，儘管軟件專家們努力研究新方法來解決軟件的困難，但是布魯克斯認爲這些方法，包括高階語言、OOP 、AI等皆捨本逐末，只解決了一些概念的表達技巧而已，無法解決根本性的概念結構問題。 由於沒辦法解決這種根本性的困難，使得原本單純可愛的軟件，逐漸演變爲進度落後、成本暴漲、錯誤叢生問題的集合體，像惡夢中的狼羣般蜂踊而至，於是哀號而希望有種“銀彈”能即刻平息它們。然而布魯克斯認爲:“不僅眼前找不到‘銀彈’，由於軟件的本質使然，未來也不太可能找得到。”
二十年來是否存在“銀彈”的爭論一直沒有結束過，各種觀點相繼出現，直到今天也沒有得出一個最終的結論。
面向構件開發是“銀彈”嗎?
面向構件開發是九十年代提出的一種軟件開發新範型，它是在一定構件模型的支持下，複用構件庫中的一個或多個軟件構件，通過組合手段高效率、高質量地構造應用軟件系統的過程。由於以分佈式對象爲基礎的構件實現技術日趨成熟，它已經成爲現今軟件複用實踐的研究熱點，被認爲是最具潛力的軟件工程發展方向之一，是解決軟件問題的“銀彈”。
面向構件開發概念的提出雖然有一段時間了，卻很難實現產業化。如果仔細思考一下，事情恐怕沒有想象的那麼樂觀。
首先，面向構件開發並不能解決軟件開發的根本困難：
1． 軟件系統的主要難度就在於概念和整體結構的合理性，先要有整體結構的設計，纔有構件，構件是由整體結構決定的，而不是反過來。構件絲毫沒有減少概念和整體設計的難度，反而可能會增加難度。
2． 由於企業的需求不斷變化，軟件的結構也需要跟着改變，由於變化的粒度有大有小，構件本身也很可能需要改變，一個構件的改變很可能導致其它與之相關的構件的改變，而構件的開發、組裝和調試都是需要時間的，所以很難跟上快速的變化。
3． 開發一個軟件系統時，在用戶需求與軟件實現（構件）之間存在着一個很大的鴻溝。用戶需求的準確表達和組織，以及如何正確地轉化成軟件的功能實現，都存在很大的困難。構件開發並不能解決這個問題。
4． 用戶希望複用的是業務，而不是構件，這一點構件化的方法做不到。
其次，關於構件的產業化，我們認爲，作爲信息時代的軟件生產，自有其自身的特點，把它與工業時代的大規模生產方式簡單類比，認爲軟件產業也會複製工業時代的生產方式是不切實際的，理由是：
1． 標準化問題，現在軟件產業的標準基本都是底層技術級別的標準，如通信、組件、數據庫訪問等，高級應用層的構件標準能否制定出來，由誰來制定，是個很大的問題。目前關於軟件構件的標準遠未出臺，如果各構件平臺廠商推出的構件互不兼容，不能夠實現複用，將又造成資源浪費。
2． 可靠性問題，機器（如汽車）的性能是由少數幾個主要零部件（如發動機）決定的，而軟件系統則要複雜得多，將很多符合“標準”的構件組裝起來，是否就能組成整體上滿足要求的軟件系統，實在是個問題。
3． 經濟問題，構件組裝的可靠性問題即使能找到解決辦法，其耗費的時間和成本必定是驚人的，很可能得不償失，完全有違當初構件產業化的初衷。
4． 應對變化的問題，一個構件的改變很可能導致其它與之相關的構件的改變，如果由於需求的變化而需要新的構件，是向構件的供應商求助，還是自己解決？時間來得及嗎？
5． 商業模式問題，對於構件的生產者來說，構件的開發成本基本是由第一個合格的版本決定的，後面的複製基本不需要成本，所以，最大的風險在於，花費巨大成本開發的構件能賣多少份拷貝？如果只能賣少數幾份拷貝，則肯定虧本，而這是事前很難預計的。對於構件的購買者來說，也面對類似的問題，即購買多少份同樣的構件？如果購買大量的拷貝，這比自己開發更合算嗎？所以，無論是構件的生產者，還是構件的消費者，都面臨很多不確定的問題，很難下決心走上這一條路。
在可以想象的將來，這些問題尚看不到解決的希望，構件的產業化不太可能成爲現實。
這種基於“標準化構件”開發軟件的思想，實際上是照般工業時代大規模工業化生產的思想，把軟件當作機器生產。然而一臺機器執行的是設計好的簡單任務，一旦出廠後不需要什麼變化，而現在企業管理軟件面對的是快速變化的環境，需要的是隨需應變。在當代企業面對高度不確定性的環境情況下，“標準化構件”開發已很難適用。
當前的信息系統架構
當今典型的信息系統架構如下圖：
圖1當前信息系統架構
我們看到，當前信息系統架構的特點是：
l 各個應用單獨開發，各自爲政，其數據庫也單獨設計，形成一個個信息孤島。
l 開發各個應用所採用的理念、方法、技術不一樣，沒有考慮應用間流程的集成和交互，沒有統一的接口。
l 每個應用都有自己的用戶管理和安全控制機制，沒有統一的門戶 。
l 缺少全面的管理控制功能。
l 應用的業務邏輯大都是硬編碼程序，應變能力差。
基於以上架構的信息系統必然存在以下缺陷：
l 每個應用各自爲政，形成一個個信息孤島，應用和業務流程的無縫集成很難實現。
l 系統結構和功能僵化，應變能力差，無法快速應對變化，需要不斷投入人力物力進行系統改造和升級，甚至推倒重來。
l 缺少幫助業務人員進行業務創新和管理創新的技術手段。
l 缺乏統一的系統門戶，業務人員疲於應付，工作效率低下。
l 隨着應用的增多，管理的複雜度增加，管理和安全存在失控的危險。
爲什麼會出現這麼多各自爲政的應用系統呢？這是歷史原因造成的，當初人們開發應用系統時，受到用戶需求、開發理念、方法和技術等方面的限制。
首先，需求方面，當初企業的信息化要求遠不如現在的高，企業一般只對少數關鍵的應用提出了信息化的要求。
其次，開發理念方面，因爲用戶的需求不高，所以軟件提供商實現每個應用時也只考慮其本身，而沒有考慮與別的應用的集成，更沒有思考整個企業的信息化如何實現。
最後，技術方面的限制，當時的應用系統業務邏輯都是用硬編碼實現的，這使我們不可能同時考慮和實現所有的業務應用，那太複雜了，只能一個一個的實現。
軟件技術發展到今天，已經經歷了半個多世紀。從程序語言和技術發展看，經歷了從彙編語言，到過程語言，到面嚮對象語言和動態語言，再到現在的面向構件的開發。從軟件架構的發展看，經歷了從主機終端架構，到客戶機服務器架構，到以中間件爲基礎的三層和多層架構，再到現在的面向服務的體系架構（SOA）。軟件的複雜度與日俱增，但在軟件開發的效率和滿足快速變化的需求方面卻還是顯得力不從心。
對現在的企業用戶來說，他們迫切需要用最好的方法，把這些不同的應用、技術、端點進行集成，從而爲企業的業務提供最高效的支持。
由於目前的應用系統是由不同的IT供應商在不同的時期、用不同的理念和技術開發的，編程語言可能採用C、RPG、COBOL、C++、VB、JAVA、C#等，服務器端可能採用Java EE、.NET、CORBA等，中間件還可能包括BEA的Tuxedo、IBM的WebSphere，甚至還要在大型機上安裝包括SAP、Oracle在內的套裝軟件解決方案。這樣複雜的IT系統分佈在企業IT系統的不同角落。這些應用就象人類社會早期分佈在各地的一個個不同的民族國家，語言不同，文化不同，價值觀不同，社會制度不同，法律不同，貨幣不同，度量衡也不同，它們之間的交往必定會遇到許許多多的障礙，交易成本會很高，而效率極低。顯然，要在這些應用之間實現無縫集成，不是一件容易的事情！
爲了解決軟件開發和應用集成的問題，軟件廠商逐漸推出了各種技術和平臺。下面簡要分析一下當今流行的幾類技術及其發展前景。
未來的軟件架構—SOA
面向服務的架構（Service-Oriented Architecture，SOA）是近年來提出的最新IT架構概念，它是基於標準的、鬆散耦合的面向服務的架構。
當今的企業處於快速變化的環境中，信息系統必須提供必要的技術來滿足企業發展、法規遵從等要求，並提供更廣泛的服務。但是，在目前的軟件架構下，IT團隊始終處於被動狀態，面臨的挑戰日益嚴峻，在滿足不斷變化的業務需求與不能實現隨需應變的IT系統之間，存在着越來越大的差距。
企業IT系統當前面臨的問題是，沒有針對它的一套架構方法，產品孤島之間的數據使用不一致，無法實現客戶的單一視圖。渠道集成或“客戶接觸點”集成可能引起包括高度的複雜性、高昂的成本，缺乏足夠的靈活性及可擴展性等諸多問題。
就IT而言，SOA是一種分佈式計算方法，它能夠將複雜、異構的IT系統抽象爲複合的、面向業務的服務。這種觀點認爲，業務應用的根本是“服務交付”，各種應用被描述爲細化的服務，以實現模塊化並重複利用，以降低IT成本並提高資源效率。
基於Web服務的SOA架構與過去不同的特點就在於它們是基於標準以及鬆散耦合的。廣泛接受的標準（如XML和SOAP）提供了在各不同廠商解決方案之間的交互性。而鬆散耦合將分佈計算中的參與者隔離開來，交互兩邊某一方的改動並不會影響到另一方。這兩者的結合意味着公司可以實現某些Web services而不用對使用這些Web services的客戶端的知識有任何瞭解。
SOA的強大和靈活性將給企業帶來巨大的好處。如果某組織將其IT架構抽象出來，將其功能以粗粒度的服務形式表示出來，每種服務都清晰地表示其業務價值，那麼，這些服務的顧客（可能在公司內部，也可能是公司的某個業務夥伴）就可以得到這些服務，而不必考慮其後臺實現的具體技術。更進一步，如果顧客能夠發現並綁定可用的服務，那麼在這些服務背後的IT系統能夠提供更大的靈活性。
SOA不僅僅侷限於技術，SOA的實現過程中還涉及到人員和流程等方面。事實上，SOA，或者更寬泛的概念，服務導向（Service-Oriented, SO），本身就不僅僅着眼於IT，而是針對整個企業。SOA包括人、流程和技術，它是一種通過把功能描述爲服務來管理上述所有企業資源的方法，其中企業用戶可以根據業務需求來構建流程。
SOA必將成爲未來流行的軟件架構。
Java EE，力不從心
“Java Enterprise Edition” （Java EE）是1990年代由Sun公司提出來的。Java EE是一套全然不同於傳統應用開發的技術架構，包含許多組件，主要可簡化且規範應用系統的開發與部署，進而提高可移植性、安全與再用價值。
Java EE核心是一組技術規範與指南，其中所包含的各類組件、服務架構及技術層次，均有共通的標準及規格，讓各種依循Java EE架構的不同平臺之間，存在良好的兼容性，解決過去企業後端使用的信息產品彼此之間無法兼容，導致企業內部或外部難以互通的窘境。
對於開發人員而言，只需要專注於各種應用系統的商業邏輯與架構設計，至於底層繁瑣的程序撰寫工作，可搭配不同的開發平臺，以讓應用系統的開發與部署效率大幅提升。
Java EE的核心規範是 Enterprise Java Beans（EJBs），它是Java EE的核心之一，主要用於服務器端的商業邏輯的實現。EJB規範定義了一個開發和部署分佈式商業邏輯的框架，以簡化企業級應用的開發，使其較容易地具備可伸縮性、可移植性、分佈式事務處理、多用戶和安全性等。
Java EE將組成一個完整企業級應用的不同部分納入不同的容器(Container)，每個容器中都包含若干組件(這些組件是需要部署在相應容器中的)，同時各種組件都能使用各種Java EE Service/API。Java EE容器還包括：Web容器，Applet容器，Application Client容器。
在Java EE提出後8年的演化中，Java EE發生的最大變化可能就在於它放棄了對“分佈式對象模型”的強調。EJB2.0引入的本地接口使得Web層與EJB層可以運行在同一個Java虛擬機中，從而使Web容器與EJB容器的物理分離部署變成一種昂貴的冗餘；Java EE 1.4以後版本支持的Web Services兼容性，使得客戶端可以通過粗粒度的Web接口調用遠程服務——這兩次變化事實上都是在論證“分佈式對象架構”的無用性。
值得注意的是，近年來，還有一股更強勁的離心潮流在深刻地影響着Java EE的演進，它肇始於上文提到的開源軟件運動。最初它只在Rickard Oberg的動態代理RMI設計與JBoss服務器的微內核架構中顯露過邪惡的一角，但是近兩三年來，經過多個項目、各種技術雜誌/論壇/Blog的折射和放大，它已經形成一個名爲“輕量級容器架構”的完整解決方案，並暴露出完全取代傳統EJB架構的野心。
按照這一運動信徒們的說法，Java EE的發展史上只出現過一個錯誤——不幸的是，這個錯誤名叫EJB。與EJB提供的重量級架構不同，藉助AOP和IoC機制，輕量級容器能夠最大程度地降低代碼對於專用接口的依賴性，以簡短、輕便、專注、可移植的方式實現業務對象。
從“輕量級容器架構”這個詞被髮明出來的那一刻起，人們對Java EE遠景的考慮就發生了根本性的分裂：Sun和大部分主流廠商更多地關注於“Web Services”和“快速開發工具”這些利潤增長點，而一部分離經叛道的獨立專家和開發者則認爲，如果不把輕量級容器納入規劃，Java EE的發展藍圖就註定無足稱道。
其實，雙方爭執的關鍵是傳統意義上的“應用服務器”的存亡——如果所有企業級服務都可以通過AOP機制提供給普通Java對象，如果管理業務對象生命週期的可以是一個最微不足道的“微內核”，那麼深盔重鎧的應用服務器還有什麼存在理由？
而如果失去了應用服務器的這個產品類型，那些靠這項銷售起家的廠商又將何以自處？正是在這裏，兩個陣營之間存在着最深刻的利益分歧；而這場爭執的結局當然也將決定Java EE（乃至Java企業開發）的最終走向。
07年7月初,SUN公司宣佈加入SCA/SDO國際構件標準組織，標誌着Java EE將在未來五年內逐漸退出‘解決客戶關鍵問題的主流技術’的地位。也隨着SUN加入SCA/SDO組織的這一刻，Java EE的客戶價值領導地位大勢已去，Java EE應用服務器將進入低價值和同質化的時代。SUN公司加入這一組織，正說明了兩點：一就是在激烈的思想鬥爭中，加入代表了承認領導地位的失去；二就是將逐步放棄自己的JBI。
由於Java EE在市場上的努力有了一段時間，在新一代(SCA/SDO/BPEL)技術還沒有成型前，他們還在扮演着‘解決客戶關鍵問題的主流技術’的角色，可是近幾年來越來越顯出力不從心。直接導致一大堆五花八門技術的出現來彌補其不足：Spring, Struts, Hibernate, AOP......。這些屬於2.5G的技術在一段時間內解決了一些問題，不過也在帶來更多的問題(彼此的集成，開源的問題等等)。將來Java EE也許會成爲一個企業運營需要的同質化的平臺，解決分佈式計算的問題，也是一個成熟的平臺，就像PC機、操作系統一樣，發展緩慢。
SCA，前景難料
雖然面向構件開發的概念提出很多年了，但進展緩慢。於是人們認爲，除了構件標準化的問題外，另一個主要原因是，缺乏一個高效、實用的構件平臺，即一個以構件爲核心的生態系統，包括了構件運行環境、開發環境、應用管理環境、基礎性的公共構件庫、以及面向構件的方法學和經驗論。
於是SCA（Service Component Architecture）被提出來了，SCA即服務組件框架。它是由BEA、IBM、Oracle等知名中間件廠商聯合制定的一套符合SOA思想的規範。SCA規範給出瞭如何創建組件和如何將這些組件裝配成一個完整的應用程序的定義。SCA的目的是使用戶在構建企業應用時有一個不再直接面對具體的技術細節的層次，而是通過服務組件的方式來構建應用。它使開發人員可以將注意力集中在業務邏輯的編寫上。
對於企業應用，SCA還提供了關鍵的一些基礎設施，象安全性、事務、可靠調用等，這對於企業應用的開發而言就變得很方便了。SCA是第一項承諾提供一個組合模型以啓用服務網絡並支持構建下一代面向服務應用程序的技術。
SCA的好處有：
l 使用組件和組合簡化SOA實現
l 使用鬆耦合的組件和參考來支持敏捷特性
l 通過一個綜合的調用模型支持事件驅動的行爲
l 將開發和集合分開，允許技術不可知的組合
雖然SCA聲稱它使開發人員可以將注意力集中在業務邏輯的編寫上，但SCA是基於組件的，它關注的是如何描述按照各種編程模型和協議編寫的組件所組成的程序集。然而，我們不要忘了，組件是屬於技術層面的東西，不能把組件等同於業務，用戶真正關心的是業務，而不是組件。另外，SCA對組件關係的建模也過於簡單，有的實現甚至讓組件自動尋找調用關係，這根本無法構建複雜的業務邏輯。在SCA這裏，業務與技術之間的鴻溝依然沒有被跨越，這顯然無法滿足用戶複雜多變的業務需求。
此外，不同廠商的SCA實現也會有很大的差異，不能直接實現互操作。
另外一個無法迴避的至關重要的問題是，如果面向構件開發的前景本身不甚明朗，SCA又能有多大作爲呢？
ESB，沒有解決主要問題
伴隨着應用集成的迫切要求和SOA架構的日益流行，ESB逐漸成爲人們談論的熱點。ESB是企業服務總線（Enterprise Service Bus）的簡稱，是傳統中間件技術與XML、Web服務等技術結合的產物。ESB採用了“總線”這樣一種模式來管理和簡化應用之間的集成拓撲結構，以廣爲接受的開放標準爲基礎來支持應用之間在消息、事件和服務的級別上動態的互連互通。
ESB定義：ESB是一種在鬆散耦合的服務和應用之間標準的集成方式。它可以作用於：
· 面向服務的架構 -分佈式的應用由可重用的服務組成
· 面向消息的架構 - 應用之間通過ESB發送和接受消息
· 事件驅動的架構 - 應用之間異步地產生和接收消息
用一句較通俗的話來描述它：ESB就是在SOA架構中實現服務間智能化集成與管理的中介。
ESB與SOA的關係：ESB是邏輯上與SOA 所遵循的基本原則保持一致的服務集成基礎架構，它提供了服務管理的方法和在分佈式異構環境中進行服務交互的功能。
目前，ESB被認爲是解決企業應用集成問題和實現SOA架構的最好方式。
在一些大的IT廠商對ESB的宣傳中，認爲現在很多大企業裏面各部門已經有了非常好的信息系統，但是由於缺乏這些系統之間的溝通，使得這個企業沒有辦法靈活應變。按照他們的說法，如果用了採ESB，就解決了部門應用的集成問題。
事實真是這樣的嗎？答案恐怕是否定的。
實際上，現有的應用功能的顆粒度對於處於這樣一個快速變化時代的企業來說還是太大了，不足以讓部門級應用跟上業務變化。事實上，當今企業中經常發生的信息系統推倒重建事件，很多就是由於應用系統本身不能滿足業務需求而導致的。
很顯然，各應用系統本身也需要隨需應變，也需要SOA化。它們之間的集成也需要更小的顆粒度。
另外，當企業採用ESB進行應用集成時，解決的是應用孤島的問題，而數據孤島的問題卻依然存在。
所以，ESB雖然在一定程度上解決了應用的集成問題，但沒有解決數據孤島和應用本身的問題。
WfMS，難當大任
在OA方面，由於信息技術的發展和日趨激烈的商業競爭，人們不再滿足於獨立、零散的辦公自動化和應用，而是需要綜合的、集成化的解決方案。工作流管理系統（WfMS）作爲一種對常規性事務進行管理、集成的技術出現了。
WfMS是一個軟件系統，它完成工作流的定義和管理，並按照在系統中預先定義好的工作流邏輯進行工作流實例的執行。
使用WfMS的目的之一是作爲企業應用系統集成（EAI）的平臺。在當前大部分企業級IT架構中，各種各樣的異構（heterogeneous）應用和數據庫運行在企業內網中。EAI就是通過使用多個專門應用滿足新需求的方法。有時，這只需要在兩個應用之間提供數據通訊的通道。專門應用將很多業務流程硬編碼在軟件中。而工作流管理系統是不必事先知道問題域的相關信息的。工作流系統將業務流程描述作爲輸入並管理流程實例的執行，這使得它比專門應用更靈活（當然你也要花精力編寫業務流程的規格化描述）。這就是爲什麼說工作流系統和專門系統是相互補充的。工作流系統可以用來管理全局的業務流程。
WfMS能夠發揮很大價值的第二個使用方式是：協助涉及多人相關任務工作流軟件的開發。爲了達到這個目的，大部分工作流系統都有一個方便的機制，來生成執行任務的表單。不用將過程用文字的形式寫在紙上，工作流系統使你通過流程定義建模實現過程的自動化（如使用基於Web的應用）。
工作流系統的第三種使用方式是：將工作流引擎嵌入到其他應用中。在這裏，工作流引擎只是作爲一個軟件組件，對於應用的最終用戶是不可見的。將工作流引擎嵌入到應用中的主要原因是爲了重用（不重複發明輪子）和應用軟件的可維護性。
與以往已經被採用的企業 IT 應用系統，例如 MRPII 或 ERP 相比，WfMS是一個相當重要的里程碑。
在傳統的軟件產品中，系統的設計通常是基於功能分割的，作業項目之間是分裂的。面嚮對象的技術並不能直接解決這個的問題。從操作上，典型地，我們必須不斷地在層次結構的功能表（比如下拉菜單）或對象之間“進進退退”，或者在“神出鬼沒”的對象以及相關菜單中捉迷藏。
工作流管理系統是一個真正的“人-機”系統，用戶是系統中的基本角色，是直接的任務分派對象，他或她可以直接看到電腦針對自己列出的“任務清單”，跟蹤每一項任務的狀態，或繼續一項任務，而不必從一個模塊退出，進入另一個模塊，搜索相應任務的線索。前者是面向功能或對象的，而後者是直接面向用戶的。這樣，用戶的任務分派和任務的完成狀態，可以被最大程度地電腦化和受到控制。
使用WfMS能帶來以下好處：
1．改進和優化業務流程，提高業務工作效率；
2．實現更好的業務過程控制，提高顧客服務質量；
3．提高業務流程的柔性等。
但目前的工作流管理系統還存在許多的不足：
1．規範還沒有成熟，沒有標準被大範圍採用。各個工作流廠家都聲稱自己的產品符合WfMC標準，但他們的實現幾乎沒有共通性。
2．雖然相對於傳統的應用軟件，工作流的業務建模技術有了很大的提高，但還無法實現複雜的業務流程，只能作爲應用系統的補充。
3．現在的業務建模還離不開技術，不懂軟件技術的一般用戶無法定義，因此項目的實施離不開技術人員，有時需要做大量的客戶化編程工作。
4．相對於SOA和WEB服務的發展和用戶對應用集成的迫切要求，工作流技術的發展相對緩慢，這直接導致了BPEL等補充技術的出現。
我們看到，目前工作流管理在企業中應用的地方還很有限，大多用在非關鍵業務（如OA）領域。這不應該是它應有的地位。
近年來提出的協同軟件和BPM(Business Process Management)工具，基本是工作流軟件的別稱或提升，談不上有本質的進步，也很難進入企業的主流應用。
因此，工作流管理系統如不迅速提升自己的能力，將一直在企業信息系統中擔當尷尬的配角。
笨重的IT架構
爲了迎合當今的SOA潮流，各軟件廠商各顯神通，包裝推出了各自的SOA平臺和產品。
下面是目前佔主流地位的面向SOA的IT架構，其它的實現也與之差不多：
圖2 當前面向SOA的IT架構
這有點象在建造高樓。
且不論這樣的“高樓”是否真能適應迅速變化的環境，光是建造和維護這樣的“高樓”，用戶的時間、人員和資金投入將是巨大的。
有幾個用戶能承受這樣的代價？
並且，我們看到，在維持各個應用各自爲政現狀下的應用集成，並沒有解決數據孤島的問題。同時，它還可能引發兩個新問題。其一是，IT管理者認爲系統最終是可以被整合的，從而無所顧忌地增加新系統。系統數量的增加，意味着整個系統管理複雜程度的提升。另一個問題則是，在增加新系統的過程中，企業在IT方面的投入增大了，而且這種增大是一種“動態”的增大。
所謂“動態”的增大就是指企業針對新系統的投入不是一次性地投入。只要系統存在，人員工資、機房房租、電力費用、軟件更新以及硬件維護費用就需要不斷地投入。這些成本再加上新建系統給整個系統帶來的管理複雜性，就會把企業拖入“IT黑洞”之中。
我們認爲，以上的IT架構只是一種治標的方法，SOA的目標是解決應用集成和數據孤島問題，而現在的做法卻是在原有的IT基礎上修修補補。對企業來講，表面上看，“修修補補”似乎保護了原有IT的投資、節約了建設成本，但深入分析，你會發現它可能是得不償失的做法，並且會將企業引進IT黑洞。因此，從系統思維上來講，除非因爲特殊原因必須保留原有系統，否則，採用這樣的方法對企業內部應用系統進行整合，很可能造成弊多利少的後果。
前面提到的SCA、ESB、WfMS、BPM、BPEL等技術和標準，很難說它們的提出是從整體上深思熟慮的結果，一些只是爲了應付新出現的問題而提出的，這些標準之間出現了不少混淆、重疊甚至相互競爭的地方。用戶要用好這些產品和技術實在是一個巨大的挑戰，是一件幾乎完成不了的任務。
事實上，SOA概念炒作的成分要大於實際推廣。與廠商們情緒高漲相對應，SOA的一些實施案例並沒有取得預期的效果，用戶對SOA的認可度並不是很高。
SOA確實是好東西，但我們在通往SOA的路上，是否選擇了錯誤的路徑？
信息系統建設現狀
當前，企業在信息系統的建設上，基本上是由軟件廠商在主導，這主要緣於市場供求間的嚴重不對稱。
首先是信息的不對稱，由於用戶不太瞭解最新IT技術的進展，基本是軟件廠商推什麼用戶就只能接受什麼。
其次是知識的不對稱，由於普通用戶不太懂IT方面的專業知識，軟件廠商說什麼用戶就只能信什麼。
還有就是語言的不對稱，本來企業管理有自己的話語系統，但軟件廠商使用的是另一套IT話語系統，聽得用戶雲裏霧裏，很難弄明白管理軟件、信息化究竟是什麼。
由此，當前企業管理軟件的開發和實施過程中存在以下一些通病：
1．百病一方
對一個行業的用戶都用一個方子吃藥，忽視客戶的個性化需求。業務流程的“標準化”被當成通行的“新”思路被廣泛接受。實際上，當代企業競爭強調差異化，儘管表面上看來是同一個行業的企業，內部業務管理流程卻可能相差很大，實際的核心競爭力會截然不同。企業在行業中的競爭力，可能就取決於那麼一點獨到的差異。如果管理軟件把“非正常”的因素給同化掉，勢必帶來同質化的企業。
2．削足適履
目前的管理軟件實際上太“硬”了，幾乎到了在實施中“削足適履”的地步。這可能是管理軟件公司熱衷於“流程再造”的根本原因。改造企業，使之適應已經編寫好的軟件，而不管是否符合實際。
3．模塊組合。
將管理軟件的各個組分“預製”成模塊，根據企業支付能力進行“組裝”，這實際上是將企業視爲積木的簡單堆砌。持這種觀點的人並不知道整體並不是部分的簡單相加，整體含有部分所沒有的特質。企業是各個部分有機聯繫的一個整體，如果抽掉其中的某些部分，其信息還能順暢流動嗎？其整體還能正常運作嗎？
並且，系統一旦建設起來，就很難改變，不能在活生生的企業經營管理活動中“學習”。
許多用戶雖然已經意識到了以上的問題，但正如某個賭徒所說：“這很可能是個騙局，但它是全城唯一的去處。”
這裏不是說，軟件廠商都存心要誤導用戶，他們也有難言的苦衷，因爲現今大部分軟件廠商開發的軟件產品是不能滿足客戶個性化需求的，要將它們推銷給不同的客戶，只能這樣做了。歸根結底，管理軟件之所以出現這些問題，還是軟件開發的指導思想上有問題。
這種基於“標準化”的管理軟件，其指導思想是立足於工業化早期的標準化思想，而實際上我們現在面對的是信息化的時代。時代和對象都不同了，試圖重複昨天的故事基本不可能。我們不要指望再做一次福特，不可能像生產T型車那樣去大批量、工業化地生產管理軟件。我們進入的是信息化時代，是知識經濟時代，怎麼可能用工業化早期的思路去作管理軟件呢？在當代企業面對高度不確定性的環境情況下，標準化已很難適用。
我們必須轉變管理軟件開發的指導思想。
迴歸本質
如無必要，勿增實體。
——奧卡姆
公元14世紀，英國的邏輯學家和教士奧卡姆提出：“切勿浪費較多東西去做用較少的東西同樣可以做好的事情。”這個原理也可表述爲“如無必要，勿增實體”，這就是有名的奧卡姆剃刀定律。
今天，這把閃亮的剃刀又向笨重的軟件架構發出了挑戰，指出許多東西是有害無益的，我們正在被這些自己製造的麻煩壓跨。事實上，我們的軟件系統正不斷膨脹，層次越來越複雜，技術和工具越來越多，但效率卻越來越低。這迫使我們拿起“奧卡姆剃刀”，化繁爲簡，將複雜的軟件系統變簡單。爲什麼要將複雜系統變簡單呢？因爲複雜容易使人迷失，只有簡單化後才利於人們理解和操作。
從根本上看，將複雜問題簡單化，就是一針見血地捕捉問題的本質。所謂當局者迷，旁觀者清。在繁忙的工作中，IT人員考慮問題容易就事論事，而無法跳出技術的視野看問題。因此，可能最終的問題都並不複雜，但由於沒有找到正確的切入點，到最後越搞越亂，誰也解決不了，找不到方向。
我們看到，在過去的時間裏，軟件方面的進步大都集中在技術層面，而在面向用戶的業務建模層面或業務與技術的結合方面卻沒有什麼大的進展。我們一直是在解決IT人自己的技術問題，而不是解決用戶的業務問題。
要真正解決用戶的業務問題，我們先要思考一下信息系統的本質。
那麼，信息系統的本質是什麼呢？我認爲重要的有以下幾點：
1． 信息系統存在目的是爲了支持企業的業務，而不是所謂的“標準化”企業的業務。
2． 信息系統的首要要求是要正確反映和記錄業務信息，保持信息流與業務流的同步。進一步，按照企業自身的需求，用信息系統來規範、控制和管理業務流程，提高管理效率，讓用戶專注於業務本身。通過信息系統保存的豐富業務信息，爲企業（組織）的決策、經營、管理提供依據。
3． 當環境變化時，信息系統應該能迅速改變以適應變化。
4． 信息系統的實現成本和維護管理成本應儘可能低。
我們不要忘記，信息系統是爲業務服務的，而不是反過來。無視和誇大信息系統作用的觀點都是不可取的。
人是負熵之源，而軟件不是。
老子說，“輔萬物之自然而弗敢爲”。管理活動是企業經營活動的“附生物”， 管理軟件是管理活動的“附生物”，管理軟件的附生性決定了其自身處於輔助、工具、平臺的地位，它就是處於這樣一個地位，不能反客爲主。所以，管理軟件不能過分的“有爲”。
我們要轉變心態，爲用戶做輔助性的工作，不要強爲、硬爲，不要老想着去再造企業，要做一個支持者，而不是主導者。
我們需要暫時把目光從軟件產品移開，投向用戶的業務。
企業信息系統的建設，應該從以技術和產品爲中心，轉變爲以業務爲中心。
以業務爲中心，首先要求我們轉變信息系統的業務建模語言，要用用戶能懂的語言，而不要用所謂的IT專業語言。
我們需要的是一個健壯的信息系統平臺，它是業務人員開始的地方。業務人員不需要實現程序和處理數據，他們需要的是開始組織業務流程。一個良好的信息系統平臺，就是要做到這些。擁有良好的業務平臺後，在對業務邏輯的實現上，業務人員就能有更大的自由來進行創造和革新。
道侖的“銀彈”——ROAD
一切都是任務。
——道侖軟件
我們知道，人類的各種行爲都由一系列的活動組成。比如，穿衣服可以分解爲拿衣服、把衣服套在身上、扣扣子等動作。製作一張桌子可以分解爲製作一個桌面、製作四個桌腿、組裝成桌子等活動。在企業中，一個定單的處理可以分解爲接收定單、作生產計劃、採購原材料、組織生產、入庫、出貨、收款等活動，其中某些活動還可以層層分解爲更小的活動。
那麼，這些活動有什麼共同點嗎？或者說，我們可以從這些活動抽象出哪些共同的特性？
首先，所有活動都帶有一定的目的和要求，都要有人負責，並有時間的限制，因此帶有相應的業務信息和控制信息。
其次，活動還可以分解爲更小的活動，或組成更大的活動。
最後，活動與活動之間有一定的關係。
這就是活動的全部屬性。
我們要做的，就是如何爲各種活動及它們之間的關係建模，然後編寫能理解和運行該模型的軟件系統。
我們把這種開發方法稱之爲面向業務開發（Business-Oriented Development，BOD）。
如果把BOD中的業務活動包裝成任務，那麼任務就是有目的的業務活動，是組成業務邏輯的基本單元。所以，面向業務開發也可以稱爲面向任務開發（TOD）。
那麼，面向業務開發（BOD）與基於構件的開發方法（Component-Based Development，簡稱CBD）相比有什麼優勢呢？優勢如下：
1． BOD直接反映和表達業務需求，一般用戶都可以理解和操作，不需要技術人員的參與，這就消除了業務需求與軟件實現之間的鴻溝，能更快更好地滿足用戶的需求。
2． BOM中的任務比CBD中的構件更“軟”和更“輕”。構件是物理上存在的程序代碼，需要軟件開發人員編程實現，而任務是用戶就可以定義的對象，因此更容易改變，改變花費的代價更小，更能適應業務的變化。
3． 業務層的可重用性強。定義好的任務可以很容易地放到別的任務中，就象搭積木一樣。
4． 由於BOM不需要沉重的應用服務器和中間件之類的基礎結構，因此無論在開發還是運行方面，BOD比CBD需要的環境都簡單得多，更容易維護，對用戶的要求更低。
5． 用戶基於BOD開發信息系統比基於CBD開發所需的成本和費用要小得多。
如果BOD能爲所有的業務及其相互關係建模，用戶通過BOD就能實現所有的業務邏輯，也就是說，用戶根本不需要通過編程來開發一個個獨立的應用系統了！
不需要編程就能實現所有的業務邏輯，這就是道侖的“銀彈”！
而且，由於各種業務都是基於相同的單元（任務）構建並在同一種平臺上運行，它們之間的“集成”將不會有任何障礙，業務流程的集成問題將成爲歷史。於是那些困擾用戶和軟件開發人員的所有軟件開發和集成問題便煙消雲散，不復存在了！
其實讓我們靜下心來想一想，跨“應用”的業務流程與“應用”內的業務流程有本質的區別嗎？沒有，只是涵蓋的業務範圍有所不同而已，而這又是人爲設定的！業務流程本來就是一體的，比如一個定單的處理，要經歷從接到定單，到作生產計劃，到採購原材料，到生產，到出貨，到收款，到售後服務等一系列複雜的過程，這些步驟本來應該是有機聯繫的一個整體，但現在它們被分佈到ERP、SCM、CRM、OA等衆多分離的應用系統中。而這些應用系統又是由不同的IT供應商在不同的時期、用不同的理念和技術開發的，由此產生了“集成”問題。
道侖公司開發的這種以業務爲中心的信息系統平臺取名爲ROAD。
以業務爲中心，這正是ROAD平臺的指導思想。
ROAD的設計理念
道法自然
我們人類本身是大自然的產物，讓我們先來考察一下大自然生命的奧祕。
生命的組成單元——細胞
細胞
在自然界中，所有生物體都是由細胞構成的，細胞是由膜包圍着含有細胞核(擬核)的原生質所組成，是生物體的結構和功能的基本單位，也是生命活動的基本單位。細胞還能夠進行分裂和繁殖，是遺傳的基本單位，並具有遺傳的全能性。各種執行不同功能的細胞匯聚成組織，組織與組織的結合產生器官，器官與器官的結合又產生了各種子系統，各種子系統相互協作，最終形成了有機統一的複雜生物體，再由各種複雜生物體組成了地球上豐富多彩的生命世界。
人腦
在所有生物中，最高級的是人。而人體中最高級的部分是具有高級智能的大腦及神經系統。
人腦是由腦細胞（神經元）構成的一種網絡組織，是通過腦細胞之間的信號傳導來發揮功能的。顯然，腦的基本結構單位非常單純而明確。
神經元的基本功能是通過接受、整合、傳導和輸出信息實現信息交換。神經元羣通過各個神經元的信息交換，實現腦的分析功能，進而實現樣本的交換產出。產出的樣本通過聯結路徑點亮丘覺產生意識。
腦細胞之間的聯繫
每個成熟的腦細胞有多達二萬餘條線路與其它的腦細胞有業務聯繫。這部分細胞爲處於工作狀態的精英，人類現有的略有難度的工作均由它們來完成。
腦細胞彼此間聯絡的線路絕大多數在人出生後，受到外界環境的刺激而逐步發展形成的。腦細胞聯絡線路越多，就越能發揮各細胞彼此之間的分工合作，人就越聰明，智商就越高。
腦細胞之間的如何交流信息
一般人認爲，腦細胞密密麻麻地排列着，如電路一般，微弱的電流流過這些腦細胞並傳達着大腦的命令。
事實上並非如此，細胞與細胞之間並不直接連結，中間均存在着小小的縫隙。
充當導線作用的是彌散在細胞與細胞之間的荷爾蒙，也叫激素，它們充當着腦內信息的傳遞者。這種激素分泌於大腦的各個地方，大腦通過它向全身傳遞指令，於是身體也分泌同樣的荷爾蒙，通過這種荷爾蒙接受信息的細胞根據命令採取行動。沒有荷爾蒙，人就不會思考、不能行動，人就不會有感覺。
也有人把腦細胞比作一個微小的生物電池，隨時準備放電。荷電的元素稱爲離子，它們在腦細胞內外的數量不等，從而在細胞膜兩側形成微小的電位差。人類腦細胞內部記錄到的電位要比外部低70毫伏（以-70mV表示），這種電位稱爲靜息電位，這種細胞膜“外正內負”狀態稱爲極化。
從另一個腦細胞傳來的信息改變了靜息電位，使其負值改變，到達一個稱爲閾的水平，引起放電。人類腦細胞的閾約爲 -55mV，當達到此值時，腦細胞就產生一種沿軸突傳播的電變化，稱爲動作電位或神經衝動。神經衝動引起遞質釋放的同時，還伴有電位變化。
腦是由腦細胞（神經元）構成的一種網絡組織，是通過腦細胞之間的信號傳導來發揮功能的。
生命的複雜性
我們的地球上存在着各種各樣的生命：植物、動物、微生物。每種生命都體現了相應的複雜性。
生命複雜性的第一個特徵是，生命是一種複合體，不可能由一個成分（一種基因或蛋白質）構成。
生命複雜性的第二個特徵——組分之間有着廣泛的相互作用。換言之，生命的本質是由組成元素之間的關係所決定，而非組成的物質本身。生命內的這些相互作用不是直線式的，而是交錯編織形成的網絡。
這種廣泛存在的相互作用網絡引出了生命複雜性的第三個特徵：次序和層次。由於生命中各組成成分有着穩定的相互作用，從而形成了有序的結構，也就是人們常提到的“自組織”。生命自誕生那天起，就是一個與外部環境相對獨立的系統，並且通過與外界交流物質和能量維持其有序性。隨着生命的逐漸演化，次序發展出了層次：各種生物大分子相互作用並形成了不同的功能區域（細胞器等），這些功能區域組合成細胞，各種執行不同功能的細胞又匯聚成組織，組織與組織的結合又產生器官，最終形成了多細胞的生物體。
生物體的每一個層次都擁有特定的行爲或性質。這類行爲或性質不存在於構成它的組成成分裏，而是由組成成分間的相互作用所形成。
因此，生命複雜性的第四個特徵是，整體比它的部分之和更大。研究複雜性系統的科學家把這種現象稱爲“涌現”（emergence）。生命系統的涌現是屬於非線性的，即不能通過簡單地疊加構成成分的行爲推導出系統的行爲。此外，系統組成部分的微小改變常常會被迅速放大並導致系統狀態的改變，即所謂的“蝴蝶效應”。這種“整體大於部分之和”和“涌現”性質，是生命誕生及其進化的主要動因，生命通過改變自身以適應變化着的外部環境。這種特性使得地球上形成如此繁多的生物物種，使得人類這樣高級的生命形態能夠從原始的細菌進化而成。在這個意義上，美國科學家霍蘭（J. H. Holland）提出，“適應性造就複雜性”。
因此，生命複雜性的第五個特徵是，系統具有開放性，可以在過程中不斷地演化。生命不是一種簡單的“自穩態”系統——通過負反饋的調節控制來穩定自身的狀態，從而適應外界的變化；而是一種遠離平衡狀態的開放系統——通過不斷地形成新性質或新功能來適應外界的挑戰或改變。
ROAD的組成單元——任務
ROAD以任務爲組成單元爲業務建模。任務是一個自包含的對象，既是業務邏輯的組成單元，自身又包含業務邏輯。
ROAD的類生物體特性
對比ROAD中的任務和構成生物體的細胞，我們驚喜地發現，它們有很多相似之處。首先，它們都帶有一定的信息，其次，它們都可以分解/分裂爲更小的單元，或組成更大的單元，最後，它們都可與其它單元形成一定的關係。
因此，從某種意義上說，ROAD具有與生物體類似的特性。構建在ROAD平臺之上的企業信息系統，也就可以象生物體一樣具備自組織和自適應能力，並且可以在過程中不斷地演化來適應環境的變化。
事實上，ROAD正是將企業看成是一個活的有機體，而這個有機體的組成單元，就是任務。
在ROAD系統中，每個人都可以產生任務。每個任務可以分解爲更小的任務，同時又可以是更大的任務的組成部分，任務之間有一定的關係。使用這種方式能夠構建非常複雜的信息系統，並能高效利用資源、對內部和外部的擾動保持高度的彈性、適應所處環境的變化。而且在這個系統中，每一個組成部分都有一定程度的自主性，都能夠在沒有上一層組織的協助下，在其所處的特定層次上掌握環境和處理問題。同時也能接受來自上層整體的指導，在某種意義上受上層整體的控制。自主性保證了部分（小的整體）是穩定的，能夠在干擾下生存，而對上層整體的服從又確保了更大的整體的有效運轉。
以人爲本
信息系統以人爲本。
企業是由各種各樣的人組成的，每家企業和每個知識工作者都有獨特的個性，企業的信息系統只有承認和保持這種獨特性，纔有可能提升而不是扼殺其核心能力，才有利於提升知識工作者的工作效率，讓知識工作者能夠更加快樂的工作而不是剝奪他們的尊嚴。其次，要認識到每個企業和企業中的每個部門、每個知識工作者都是整個產業社會的一部分，需要與其他人、其他部門、其他企業有效的聯繫和協同工作，而信息化系統應該是增強這種有機聯繫的重要載體。
然而，這兩個互補的因素都被標準化的套裝管理軟件所忽略了。當前的管理軟件，一方面抹殺了知識工作者的個性，限制了他們能力的自由發揮，另一方面，這些軟件始終只關注“標準化”的工作流程，沒有給知識工作者之間進行交流、碰撞提供有效的人性化的空間。這些軟件是冷冰冰的，利用這種軟件來工作讓人感到孤獨、缺乏友誼，不能讓人感覺到自己是其中的一部分。因此，用這種管理軟件不可能建造出讓知識工作者感覺舒適愜意、方便快捷、與他們的日常工作相匹配的信息化系統。知識工作者不得不使用這種名義上是“爲”他們建造的信息化系統，然而對於這個他們要每日每時要在此工作的系統卻不能進行任何最基本的、令人感到愉悅的設計和改進。
我們必須找到一種企業信息化建造機制，能夠照顧到管理活動的各種要素，只有滿足了這些要素，才能把每個企業的信息系統建設得“恰到好處”，使信息系統能夠準確地適應企業、部門、知識工作者的需要，同時能夠發揮自己的核心能力。
ROAD的出現，提供了一個平臺，讓我們可以在企業信息化中開始尊重每位知識工作者，讓知識工作者的創新思維有充分發揮的空間，並體現知識工作者的價值取向、工作習慣乃至感情因素，讓我們所建立的信息系統能充分體現管理和知識的真正價值，讓知識工作者爲在這種信息系統支持下工作而感到驕傲和幸福，讓企業信息系統中跳動着知識工作者的生命活力，讓他們感覺到的這就是他們“自己的”系統，是他們的有生命的大腦的一個有機組成部分，而不再是一個冷冰冰的體現着“異己力量”的系統。
基於ROAD建立的企業信息系統，將滿足知識工作者的各種需要，體現他們的真正價值，讓他們從重複、單調、低效和緊張的管理工作中解放出來，從事更富有創造性的工作，並享受全新的生活。
用戶主導的時代來臨了
ROAD平臺的提出，將給信息系統的建設帶來革命性的變化。
原來企業先開發或購買互相分離的各種應用系統，再企圖用各種中間件將它們的功能集成起來。用這種方式建立起來的信息系統必然難以實現應用間無縫的集成，不能滿足企業的各種業務和管理需求，更無法應對未來的變化。各個應用系統的維護和升級嚴重依賴開發商，隨着應用的不斷增多，系統的維護和升級也將變得越來越困難，有時甚至推倒重來，造成投資的極大浪費。
有了ROAD平臺後，企業先進行全局範圍內的業務規劃和設計（主要包括業務邏輯、數據庫和WEB服務），然後直接從業務出發來構建信息系統。
由於在ROAD系統中，採用普通用戶都可以明白的方式爲業務建模，不需要技術人員的參與，所有人都使用共同的建模單元——任務。每個人都可以爲自己負責的那部分業務建模，而且可以立即投入運行。每個人既是系統的使用者，同時又是系統的建設者。
這樣一來，信息系統的建設就完全由用戶自己掌控，實現用戶想要的任何業務邏輯。這樣建立的信息系統一定能夠滿足企業的需求，更能適應未來的變化，真正成爲隨需應變的信息系統。
如果再加上管理功能，這樣的信息系統就將成爲企業的數字神經系統！
欲知企業的數字神經系統如何建設，請看下一篇——《基於ROAD的數字神經系統建設》。
(版權所有，轉載必須經過允許）