作者：Vasile Buciuman-Coman, Michael Chervenic 譯:Infoq 胡鍵 2008-04-25
第一部分——即使擁有全部需求和最佳設計，你的架構仍然很可能失敗，原因在于……
目前的管理學(xué)校，教育培養的是公司經(jīng)營(yíng)者。設計公司幾乎沒(méi)有引起重視……幾乎從來(lái)沒(méi)有任何人為了取得計劃的增長(cháng)和穩定性，有意識和有思想地設計一個(gè)組織。
——Jay W. Forrester，設計未來(lái)（1998）
介紹
在一篇名為《動(dòng)態(tài)業(yè)務(wù)應用勢在必行（The Dynamic Business Applications Imperative）》的論文中，Forrester的高級分析師John R. Rymer指出了當今應用的一個(gè)致命缺陷：
當今應用迫使人們去尋找一種將孤立的信息和功能組映射到他們任務(wù)和過(guò)程的方法，它們強迫IT人員花高額預算來(lái)跟蹤不斷變化的市場(chǎng)、策略、規章制度和業(yè)務(wù)模型。
在下一個(gè)5年內，IT的主要目標應該是發(fā)明新一代企業(yè)軟件，適應業(yè)務(wù)和業(yè)務(wù)工作，同時(shí)能隨業(yè)務(wù)演變而演變。
Forrester稱(chēng)這個(gè)新生代為動(dòng)態(tài)業(yè)務(wù)應用，強調了和業(yè)務(wù)過(guò)程及工作（為人而設計）的緊密配合，對業(yè)務(wù)變化的自適應（為變化而構建）。在這個(gè)階段，動(dòng)態(tài)業(yè)務(wù)應用的需求比創(chuàng )建它們所需的設計實(shí)踐更清晰。工具都是現成的：面向服務(wù)架構（SOA）、業(yè)務(wù)過(guò)程管理（BPM）和業(yè)務(wù)規則領(lǐng)域中的先驅——包括獨立軟件開(kāi)發(fā)商（ISV）——已經(jīng)開(kāi)始向我們展示了這種方法?，F在就是開(kāi)始這段旅程的時(shí)候。
在這篇由兩部分組成的文章中，我們會(huì )從架構和方法論的角度，采用歷史的觀(guān)點(diǎn)來(lái)看待這些動(dòng)態(tài)業(yè)務(wù)應用（DBA）的發(fā)展。我們的目標是獲得一種能使應用容易適應業(yè)務(wù)變化和其他必要修改的構建方法。隨著(zhù)企業(yè)在21世紀關(guān)注靈活性，DBA是使業(yè)務(wù)和IT在未來(lái)幾十年內成功的關(guān)鍵。
動(dòng)態(tài)性對我們意味著(zhù)什么？
在軟件工程領(lǐng)域，許多框架或產(chǎn)品都聲稱(chēng)具有自適應性。在我們設法理解一個(gè)解決方案在適應變化方面究竟有多好之前，需要給系統是如何變化的——它們的動(dòng)態(tài)性——下一個(gè)可靠的定義。
早期的面向對象方法論認識到[1]：為了使系統分析中立，它必須基于兩類(lèi)現實(shí)世界的需求：
在這樣的背景下，對于每一個(gè)被分析的系統，我們總能識別一個(gè)或多個(gè)最重要的實(shí)體。每個(gè)實(shí)體都又包含3個(gè)關(guān)聯(lián)元素：事件、狀態(tài)和生命周期。每個(gè)事件代表狀態(tài)中的一個(gè)變化，所有普通實(shí)體狀態(tài)的有序和代表了一個(gè)生命周期。但是，那些觸發(fā)狀態(tài)變化且是正常流程一部分的事件與那些觸發(fā)狀態(tài)變化但不是正常流程一部分的事件之間有明顯的差異。例如，當一個(gè)產(chǎn)品訂單被提交之后，一組可能發(fā)生的事件包括付費處理和訂單交付。當一個(gè)用戶(hù)變更訂單或當企業(yè)改變價(jià)格時(shí)，我們不能認為這些動(dòng)作是正常流程的一部分，因此它們與實(shí)體（如訂單）的生命周期無(wú)關(guān)。核心實(shí)體實(shí)例的生命周期單獨定義了在正常操作中系統最有可能處理的東西。所有其他事件類(lèi)型，如變化或中間步驟，被區別對待。
這個(gè)場(chǎng)景對很多工程師都不陌生：一個(gè)系統模型包含一個(gè)核心實(shí)體結構，該實(shí)體具有一組事件，這些事件組成了實(shí)體的生命周期。這個(gè)系統模型對分析師和設計者都很清晰且易于理解。建模工具，如有限狀態(tài)機、實(shí)體關(guān)系圖、實(shí)體狀態(tài)轉換圖和數據流圖，為了幫助這種方法已經(jīng)經(jīng)過(guò)了快20年的完善。那些為復雜系統（如空客 380或F-22，后者是世界上最高級的戰斗機）服務(wù)、擁有數十億行代碼的軟件就是這樣被編寫(xiě)出來(lái)的。使用對象流圖（它是捕獲事件和狀態(tài)轉換的基礎模型）虛擬化實(shí)體生命周期是這個(gè)模型的關(guān)鍵。在這個(gè)情況下，架構可以被認為是靜態(tài)的，因為整個(gè)系統狀態(tài)在時(shí)間軸上的任意一點(diǎn)都是確定的。
普通事件、狀態(tài)、生命周期間的關(guān)系，以及從其他事件類(lèi)型中分出的普通事件是理解所建議的動(dòng)態(tài)操作框架的基礎。正如James Martin 和James Odell很久以前在《面向對象分析設計》中所寫(xiě)的，分析師、設計師和實(shí)現者都應該使用同一系統模型。分析師使用數據流圖思考，設計師使用結構圖思考，程序員使用Java和SQL思考。在數據流上下文中，分析師識別對象類(lèi)型，并思考改變對象狀態(tài)的事件。最終用戶(hù)也理解這個(gè)相同的認識。他們也應該按照對象類(lèi)型、事件、對象狀態(tài)的變化，以及觸發(fā)和控制事件的業(yè)務(wù)規則進(jìn)行思考。Martin和Odell強調了對象流圖對系統設計師的重要性：“事件模式適合按照事件、觸發(fā)器、條件和操作來(lái)描述過(guò)程。但是這種方式不適合描述大型復雜過(guò)程。一個(gè)系統領(lǐng)域常常太大或太復雜，無(wú)法表示成事件和觸發(fā)器。此外，可能只有一個(gè)高級別的認識才是必要的。這對戰略級別的規劃尤其正確。在這樣的情況下，一個(gè)對象流圖是有用的。對象流圖（OFD）與數據流圖（DFD）類(lèi)似，因為它們描述了活動(dòng)和其他活動(dòng)間的接口。在DFD中，這個(gè)接口傳遞數據。在對象技術(shù)中，我們不再限于數據傳遞。相反，圖應該表示從一個(gè)活動(dòng)傳遞到另一個(gè)活動(dòng)的任何類(lèi)型事物：不論它是報表、零部件、已完貨物、設計、服務(wù)、硬件、軟件——或數據。簡(jiǎn)而言之，OFD指的就是被產(chǎn)生的對象，以及產(chǎn)生和交換它們的活動(dòng)。”
為了捕獲與業(yè)務(wù)操作關(guān)聯(lián)的信息流，業(yè)務(wù)分析師用價(jià)值流程圖（Value Stream Mapping）對OO方法論進(jìn)行了補充。價(jià)值流程圖起源于豐田，與精益制造關(guān)系緊密。美國國家環(huán)境保護局將價(jià)值流程圖定義為“用來(lái)認識那些產(chǎn)生產(chǎn)品或交付服務(wù)的活動(dòng)序列與信息流程的精益過(guò)程映射方法。”此處的關(guān)鍵詞是“產(chǎn)品”和“服務(wù)”。它們顯現了合適的信息流程在整個(gè)企業(yè)中扮演的統一角色。
把過(guò)程流圖和價(jià)值流程圖兩個(gè)概念結合在一起后，它產(chǎn)生了一個(gè)完全代表整個(gè)企業(yè)經(jīng)營(yíng)范圍、可被方便翻譯成OO（圖2）概念的框架基礎。
但是，許多系統并不是靜態(tài)的，它們變化無(wú)常的行為無(wú)法被一組關(guān)系和事件捕獲。事實(shí)上，它們發(fā)生在不可知的[2]未來(lái)，傳統用來(lái)捕獲它們動(dòng)態(tài)特點(diǎn)的工具不起作用。所有的業(yè)務(wù)應用和絕大多數現實(shí)世界的系統都歸于此類(lèi)。這些系統，基于它們和其他外部系統的交互方式，處理3類(lèi)變化：
要對現實(shí)世界系統建模，就必須處理好這所有3種變化類(lèi)型。這種模型與靜態(tài)架構模型相比，在管理復雜性上有了極大的提高。從正常工作的觀(guān)點(diǎn)來(lái)看，內部和外部系統完全獨立于主信息流運行。內部和外部系統甚至有它們自己的操作——管理有其自身的決策周期，客戶(hù)有其自己的操作環(huán)境——由各自的信息流描述。就信息流而言，這3種系統分別運行在3個(gè)平行宇宙中。解決這3種非同步信息流的唯一辦法就是為每個(gè)信息流實(shí)現一個(gè)獨立全面的變更管理。這種復雜交互在圖3（動(dòng)態(tài)操作圖）中表示。
郵輪公司給客戶(hù)提供的服務(wù)可以作為解釋動(dòng)態(tài)操作的例子。在訂購時(shí)，一個(gè)客戶(hù)會(huì )決定在游覽期間他計劃參與的服務(wù)。但是，不僅客戶(hù)可能在游覽前和游覽中改變主意，而且郵輪公司也可能會(huì )為了利用新機會(huì )或應對未知事件改變服務(wù)。按照當前方法設計的系統，大部分變更都以極高的運營(yíng)成本人工處理。使用基于動(dòng)態(tài)業(yè)務(wù)應用架構原則設計出的系統，來(lái)自客戶(hù)和內部管理決策的變更由兩個(gè)與正常工作完全集成的變更管理子系統負責。這不僅能降低成本，而且還提高了服務(wù)質(zhì)量，甚至可以最優(yōu)化運營(yíng)來(lái)提高利潤。因為是完全通用的，它還可以重用標準組件。最終結果對于參與的每個(gè)人、業(yè)務(wù)、IT和客戶(hù)來(lái)說(shuō)是多贏(yíng)的。
圖3. 動(dòng)態(tài)操作有3個(gè)維度——正常事件、內部控制和外部反饋
動(dòng)態(tài)業(yè)務(wù)應用的目標之一就是使設計和軟件實(shí)現變得簡(jiǎn)單，以支持對所有業(yè)務(wù)來(lái)說(shuō)司空見(jiàn)慣的動(dòng)態(tài)系統。以我們的經(jīng)驗，與一個(gè)框架優(yōu)先的工程學(xué)相結合是構建一個(gè)DBA的最有效的技術(shù)方法。
設計企業(yè)系統要求框架先行
構建動(dòng)態(tài)業(yè)務(wù)應用說(shuō)起來(lái)簡(jiǎn)單，做起來(lái)難。工程，包括軟件工程，都采用了有百年歷史的框架優(yōu)先方法。設計一座橋梁、一架飛機或者甚至是一個(gè)軟件應用都使用相同的方法：一個(gè)設計團隊先收集需求，然后使用一組定義良好的框架步驟來(lái)設計和構建系統。在設計橋梁和其他工程系統時(shí)，現有框架已被證明非常成功。但在使用它來(lái)為業(yè)務(wù)系統開(kāi)發(fā)軟件時(shí)，卻碰了壁。這兩類(lèi)系統之間有一個(gè)根本區別。在設計橋梁和飛機時(shí)，最終結果總是一個(gè)擁有靜態(tài)架構的系統：當變更發(fā)生時(shí)，如增加橋梁負重或飛機速度，整個(gè)系統可能就要重頭重新設計。不幸的是，軟件也常常使用一個(gè)靜態(tài)架構進(jìn)行設計：每當一個(gè)非預期的變更被引入到運營(yíng)中時(shí)，很可能所有事情都停了下來(lái)，使用包含新增功能的系統替代現有系統。因為業(yè)務(wù)運營(yíng)在一個(gè)不斷變化的環(huán)境中，而且比以往更依賴(lài)IT系統，這種?！呤降慕鉀Q方案是不可接受的。持續升級和在企業(yè)基礎設施中集成系統的成本已經(jīng)達到了無(wú)法支撐的地步。
依賴(lài)業(yè)務(wù)涉眾作為我們全部需求的輸入首先就是個(gè)問(wèn)題?？紤]到需求，目前還沒(méi)有真正適合動(dòng)態(tài)操作的“框架優(yōu)先”軟件設計方法。甚至卡內基梅隆軟件工程學(xué)院也表示架構是由場(chǎng)景驅動(dòng)的，場(chǎng)景以涉眾輸入為基礎被創(chuàng )建出來(lái)：“誘導一個(gè)軟件密集型系統的業(yè)務(wù)目標是標準架構設計和分析方法的一個(gè)組成部分。業(yè)務(wù)目標是驅動(dòng)方法的引擎，通過(guò)將它們的實(shí)現作為場(chǎng)景……一個(gè)理想的設計方法或過(guò)程必須考慮眾多涉眾和眾多影響。”
作為工程師，當我們收集系統需求時(shí)，我們怎能知道我們得到了正確的場(chǎng)景或是否遇上了正確的涉眾？我們又如何能說(shuō)明業(yè)務(wù)未來(lái)的變化，而這些變化通常連參與的涉眾都不知道？
“企業(yè)經(jīng)營(yíng)者和企業(yè)設計師之間存在著(zhù)根本區別。為了說(shuō)明這點(diǎn)，考慮一下在一架飛機成功操作背后的兩種最重要的人。一個(gè)是飛機設計師，另一個(gè)是這架飛機的飛行員。設計師創(chuàng )造的飛機連平庸的飛行員都可成功駕駛。一般情況下，經(jīng)理更像是飛行員而非一個(gè)設計師。一個(gè)經(jīng)理管理一個(gè)組織，這和一個(gè)飛行員駕駛飛機沒(méi)什么兩樣。飛行員的成功依賴(lài)于那些創(chuàng )造了一架成功飛機的飛機設計師。另一方面，是誰(shuí)來(lái)設計一家由管理者管理的公司呢？幾乎從沒(méi)有任何人有意識和有思想的去設計一個(gè)組織，以取得有計劃的增長(cháng)和穩定性。在當前的管理學(xué)校中，教育培養的是企業(yè)的經(jīng)營(yíng)者，而如何設計企業(yè)幾乎不受重視。”
在幾年前完成的報告“設計未來(lái)”中，MIT的教授和系統動(dòng)態(tài)之父Jay Forrester，指出這個(gè)問(wèn)題是我們?yōu)槠髽I(yè)設計系統的基本限制：
Forrester的觀(guān)察進(jìn)一步使當前的企業(yè)架構方法失效。在我們需要設計一個(gè)企業(yè)系統架構時(shí)，作為知識主要來(lái)源的涉眾甚至是錯誤的分類(lèi)。他們是企業(yè)的 “用戶(hù)”，不是“設計師”。在設計飛機時(shí)，飛機設計師決不可能去詢(xún)問(wèn)飛行員或乘客關(guān)于飛機制造方面的事情。但是，在學(xué)校、工程或MBA課程中卻沒(méi)有企業(yè)設計這門(mén)課。
那么回到企業(yè)架構，其中有一個(gè)根本的斷檔。企業(yè)架構的“用戶(hù)”是企業(yè)涉眾，很可能是熟悉企業(yè)動(dòng)態(tài)性的企業(yè)畢業(yè)生，但是他們不熟悉工程方法。企業(yè)系統的設計者和構建者——軟件工程師——熟悉靜態(tài)框架，但是對動(dòng)態(tài)框架卻很陌生。事實(shí)上，還沒(méi)有說(shuō)明業(yè)務(wù)動(dòng)態(tài)的框架。根據企業(yè)架構框架，這是一個(gè)需要填補的缺口。這個(gè)框架只描述企業(yè)是如何“被設計的”，但是也會(huì )定義開(kāi)發(fā)路線(xiàn)圖和主要組件，使用它們來(lái)構建企業(yè)的支持系統。
我們建議根本改變我們架構和設計信息系統的方式，以一種不要求業(yè)務(wù)涉眾作為主要輸入的方式。我們推薦利用一個(gè)以業(yè)務(wù)實(shí)體生命周期和事件模型為中心的框架作為架構的主要輸入來(lái)源。業(yè)務(wù)場(chǎng)景只被用來(lái)微調一個(gè)已完架構，而不是作為主要驅動(dòng)力。
這種框架優(yōu)先方法從一開(kāi)始就說(shuō)明了業(yè)務(wù)動(dòng)態(tài)，而不是事后諸葛亮。它暗示被設計的企業(yè)應用是動(dòng)態(tài)適應的，而不是像由今天的方法論所實(shí)現的那樣是靜態(tài)適應的。這種方法成數量級的減小了開(kāi)發(fā)和維護軟件的成本，并砍掉了與改變和維護現有系統直接相關(guān)的超過(guò)70%的IT開(kāi)銷(xiāo)。
在我們建議的方法中，業(yè)務(wù)場(chǎng)景只被作為一個(gè)已完架構的微調，而不是主要驅動(dòng)力。我們將我們的直覺(jué)、經(jīng)驗和技巧輸入到設計過(guò)程中越晚，產(chǎn)生導致巨大損失的錯誤的可能性就越少。由涉眾輸入引起的需求變更會(huì )在已經(jīng)建好的現有解決方案框架中處理，減少了風(fēng)險和延遲。
一份Standish報告研究表明，超過(guò)1千萬(wàn)美元的項目，成功率只有3%。行業(yè)咨詢(xún)和哈佛商學(xué)院教授A(yíng)ndrew McAfee表示，部署如此高成本技術(shù)（如ERP、CRM、供應鏈管理、電子商務(wù)和其他企業(yè)應用）組織的成功率在25% ~ 70%之間。McAfee總結說(shuō)：“這些面臨的問(wèn)題并非是單獨的，它們都是同一事情的不同例子，基本上都是使用IT改變業(yè)務(wù)過(guò)程的結果。”。最近，這些百分比有所提高，但是對于復雜系統IT仍缺乏清晰的路線(xiàn)?？蚣軆?yōu)先的方法能使業(yè)務(wù)變化集成到IT實(shí)現中，并提供了業(yè)務(wù)和技術(shù)之間更清晰的轉換，可以將成功率提高接近100%。建構復雜系統的時(shí)間由幾個(gè)月或幾年縮短至幾天。
動(dòng)態(tài)操作的服務(wù)器架構——忘記SOA，迎接信息裝配線(xiàn)
90年代早期，事件幾乎是每本面向對象方法論書(shū)籍中的核心角色。隨著(zhù)象Windows這樣基于GUI操作系統的出現，GUI開(kāi)發(fā)平臺依靠復雜事件模型來(lái)設計和構建單個(gè)應用。但是，在客戶(hù)機-服務(wù)器環(huán)境中，服務(wù)器端的事件處理總是基于一個(gè)簡(jiǎn)單得多的模型。
當基于Web的技術(shù)（如J2EE和.NET）開(kāi)始替代傳統的客戶(hù)機-服務(wù)器應用，客戶(hù)機和服務(wù)器都經(jīng)歷了根本的轉變?？蛻?hù)端的富OS事件模型由Web瀏覽器和原始的腳本語(yǔ)言代替。在服務(wù)器端，事件處理由無(wú)狀態(tài)、扁平的、靜態(tài)架構所替代。其方式非常類(lèi)似將網(wǎng)頁(yè)傳給Web瀏覽器的方式。
為了模擬現實(shí)世界的需求，需要一個(gè)有狀態(tài)的、層次的、動(dòng)態(tài)的和分布式的架構，設計必須嚴重依賴(lài)數據庫來(lái)存儲范圍廣泛的各種動(dòng)態(tài)信息。但是根據其定義，關(guān)系數據庫非常適合存儲不常變化的數據間關(guān)系。保存動(dòng)態(tài)、分布式、層次的和有狀態(tài)信息要求一個(gè)不同的基礎設施，它不是以關(guān)系數據庫為中心的。
基于Web的技術(shù)為支持現實(shí)世界系統引入了其他挑戰。當J2EE應用服務(wù)器在一個(gè)分布式環(huán)境被使用時(shí)，使用Java作為編程語(yǔ)言的一個(gè)最大優(yōu)勢完全沒(méi)有了。Java虛擬機的垃圾回收從來(lái)沒(méi)有被設計成能自動(dòng)清除在多實(shí)例間交換的內存對象。在這種情況下，架構師和設計師必須編排整個(gè)對象生命周期，不考慮編程語(yǔ)言的能力。甚至在數據保存在數據庫中時(shí)，這種相同的數據清除問(wèn)題也變得非常困難。
正如我們已經(jīng)看到的，一旦我們能從正常工作中分離變化，架構就能只依賴(lài)事件和生命周期進(jìn)行設計和實(shí)現。圍繞生命周期進(jìn)行系統設計已經(jīng)經(jīng)歷了一個(gè)世紀——它被稱(chēng)為裝配線(xiàn)。
在裝配線(xiàn)于20世紀早期引入之前，制造業(yè)的工作方式多多少少和今天面向服務(wù)架構（SOA）處理信息的方式一樣。每個(gè)對于SOA服務(wù)的調用一般都被視為一個(gè)無(wú)狀態(tài)調用。為了說(shuō)明以前調用的歷史，每個(gè)服務(wù)必須完全實(shí)現如何處理系統內部狀態(tài)。一旦需求改變，幾乎所有服務(wù)也需要以成本極高的方式重新編碼來(lái)改變它們各自的實(shí)現。
圖6. 服務(wù)器架構是以事件模型為基礎的
我們建議使用以事件模型和生命周期為中心的信息架構作為業(yè)務(wù)需求和系統架構的雙向翻譯平臺。事件模型在下一級被擴展成四個(gè)基本模型：狀態(tài)、分布式、層次和動(dòng)態(tài)。所有這5個(gè)模型可被基礎需求和架構模型中的業(yè)務(wù)或技術(shù)人員方便地解釋?zhuān)?/p>
這5個(gè)模型不僅可以被用在初始設計，對貫穿整個(gè)系統生命周期的需求變更亦有裨益。它們一起形成了自適應系統設計所缺失的框架步驟。這5個(gè)模型排除了用例作為企業(yè)架構的主輸入的必要性。它們可以被翻譯成一個(gè)清晰和全面的工程問(wèn)題集合，與在橋梁或飛機設計中使用的方法類(lèi)似。
這5個(gè)模型定義了以信息變化和裝配線(xiàn)為中心的動(dòng)態(tài)業(yè)務(wù)應用通用架構。最重要的子系統是：靜態(tài)模型、變更管理、虛擬裝配對象和事件處理。在下一個(gè)細化層級，還有兩個(gè)子系統：系統命令和控制與持久化。
這個(gè)架構還解決了在尋求一個(gè)適用于事務(wù)型工作流隱喻的通用解決方案過(guò)程中長(cháng)期存在的問(wèn)題，它是由Jim Gray[3]在幾十年前提出的。因為整個(gè)設計以單個(gè)事件的執行為中心，不僅可以實(shí)現“移動(dòng)到下一個(gè)裝配步驟”，而且也可實(shí)現“移動(dòng)到前一個(gè)裝配步驟”。實(shí)現需要根據用戶(hù)的輸入決定前往哪個(gè)“方向”。通過(guò)將多個(gè)步驟“鏈接”在一起，可以使用相同的架構實(shí)現一個(gè)事務(wù)型工作流的“撤銷(xiāo)（Undo）”操作。
動(dòng)態(tài)業(yè)務(wù)應用的一個(gè)關(guān)鍵元素是事件處理。使用新的自適應系統信息理論，可以使用一個(gè)通用組件結構來(lái)“執行”每個(gè)事件。這個(gè)組件使用聲明性編程來(lái)內嵌業(yè)務(wù)邏輯、調用工作流引擎、調度器和業(yè)務(wù)規則引擎。這個(gè)實(shí)現不僅可以極大加速自適應系統開(kāi)發(fā)，而且可以使后期改變非常容易處理，也減少了維護復雜集成的需要。
我們建議圍繞事件（操作）和事件生命周期創(chuàng )建一個(gè)供給控制、運營(yíng)和環(huán)境的物理模型。生命周期控制器為離散事件管理裝配信息。變更管理功能指導標準事件模型和個(gè)體事件內外部變更的執行。
結論
我們已經(jīng)討論了扁平、無(wú)狀態(tài)、靜態(tài)、客戶(hù)端——服務(wù)器、基于Web的解決方案的演變方式所帶來(lái)的IT架構和層次、有狀態(tài)、動(dòng)態(tài)、分布式業(yè)務(wù)的現實(shí)世界之間的脫節。我們還討論了傳統工程方法為什么不能支撐能支持動(dòng)態(tài)業(yè)務(wù)的自適應系統的開(kāi)發(fā)。我們展示這兩個(gè)問(wèn)題的可能解決方案可以用一種新的模型驅動(dòng)架構方法來(lái)找到。
本文的第二部分將描述動(dòng)態(tài)業(yè)務(wù)應用的可能架構，并給出一個(gè)案例研究，介紹我們概念的實(shí)際實(shí)現。
參考文獻
[1] Yourdon Systems Method —— Model Driven Systems Development —— Yourdon Press, 1993
[2] Eric D. Beinhocker —— "The Origin of Wealth", HBS Press Book,2006 —— 在他的新書(shū)“The Origin of Wealth”中，麥肯錫公司高級顧問(wèn)Eric D. Beinhocker聲稱(chēng)，將經(jīng)濟視為一種靜態(tài)、平衡的系統的傳統觀(guān)點(diǎn)正在經(jīng)受一場(chǎng)徹底的反思，包括為數眾多的原則。新的中心是：“復雜經(jīng)濟學(xué)”，其中經(jīng)濟被視為一種高度動(dòng)態(tài)的、不斷演變、幾乎無(wú)法預測的系統。這個(gè)摘錄涉及在未來(lái)未知時(shí)公司如何來(lái)制定戰略。
[3] Mark Whitehorn ,The Register, Interview with Jim Gray —— http://www.regdeveloper.co.uk/2006/05/30/jim_gray/
聯(lián)系客服
