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