Bill Higgins, Architect, Systems Engineering and Architecture, IBM Global Services

2005 年 10 月 19 日

來自于 Rational Edge：復雜的業(yè)務流程集成（BPI）項目是非常具有挑戰(zhàn)性的，這是因為不同的部門可能會遵循不同的開發(fā)過程，并使用不同的開發(fā)技術和工具。本文建議管理這種項目的技術應該按照三個方面來進行：組織過程和工具，組織結構，以及需求和變更管理過程。

現(xiàn)代企業(yè)的一個核心目標就是整合跨公司和關鍵合作伙伴、供應商以及顧客。 ¹ 將他們的業(yè)務過程端到端地集成在一起。企業(yè)級IT組織通過將支持業(yè)務流程集成（BPI）項目的軟件應用程序過程集成起來，來完成此目標。這樣的項目是非常具有挑戰(zhàn)性的，這是因為不同的部門可能遵循不同的開發(fā)過程，并且使用不同的開發(fā)技術和工具。那些找到優(yōu)化其BPI項目方法的企業(yè)會在市場上獲得巨大的優(yōu)勢：他們可以更快速和更有效地響應正在浮現(xiàn)的市場機會和競爭威脅。本文主要討論你的開發(fā)組織可以使用的一些基本原則和技術，應用這些原則和技術將會有助于更有效地執(zhí)行BPI項目。

首先，我們來分析一下一個BPI項目的特點。然后，我們將從如下三個方面來描述基本規(guī)則和技術：

• 組織過程和工具
  
  
• 組織結構
  
  
• 需求和變更管理過程

我們將在后面分別加以討論。

術語： 在整篇文章中，我將會使用很多術語，這些術語同它們在文學作品中的意思相去甚遠。下面的定義解釋了在上下文中它們的具體含義。如果在統(tǒng)一建模語言（UML）中有類似的術語，我已經(jīng)將其在圓括號中標注出來。 2 業(yè)務流程集成項目――一個業(yè)務轉換項目，涉及到多個業(yè)務流程領域，多個獨立團隊，以及許多個應用軟件。 超系統(tǒng)――在一個業(yè)務流程集成項目的開發(fā)和測試中所涉及到的所有應用軟件的一整套系統(tǒng)。（UML2：系統(tǒng)） 子系統(tǒng)：――在超系統(tǒng)中被視作一個單元的相關業(yè)務應用軟件集。一個子系統(tǒng)是一個開發(fā)部分，它應該在超系統(tǒng)范圍定義、架構以及變更管理活動中進行描述。（UML2：子系統(tǒng)） 應用軟件：――一個不同的開發(fā)團隊的軟件功能的一個單元。在一個集成信息技術環(huán)境中，一個用戶可能并沒有意識到某個特定的事務或工作流程中所涉及到的彼此獨立的應用軟件（因為點擊一下超鏈接，用戶便可能無縫地跨過不同應用軟件之間的邊界）。（UML2：子系統(tǒng)）

BPI項目的特點：

在大型企業(yè)中，業(yè)務流程重構工作是一項非常復雜的項目，可能要花費數(shù)年，并涉及到眾多的人力和信息技術系統(tǒng)。典型的BPI項目包括連接、簡化和組織一個大規(guī)模的業(yè)務流程及其支持應用軟件。

要想理解以下所描述的能夠提高這種項目成功可能性的技術，重要的是要首先理解BPI項目和更典型的應用軟件開發(fā)項目之間存在的差異。

不論是BPI還是應用軟件開發(fā)項目，都是在交付新的軟件組件或已有軟件組件的新版本，它們都會用于更好地支持一個企業(yè)的業(yè)務流程。一個軟件開發(fā)團隊――由項目經(jīng)理、分析師、開發(fā)人員、測試人員以及部署人員組成――共同工作，以推動完成一個可配置的和可靠的系統(tǒng)來支持一組商業(yè)目標的實現(xiàn)。

圖1：一個通常的開發(fā)項目：一個團隊，一個系統(tǒng)

然而，BPI項目同應用軟件開發(fā)項目最根本的不同就在于組織上和設計上的復雜性。一個典型的應用軟件開發(fā)項目也許只需要二十到五十人共同工作，整個系統(tǒng)也只有50,000至100,000行代碼。與此形成鮮明對照的是，BPI項目則可能涉及二十到一百個應用軟件，而每一個應用軟件都有自己的開發(fā)團隊和相當規(guī)模的代碼量。如此大量的應用軟件并不是困難的原因，真正首要的原因在于由不同應用軟件之間相互依賴所引起的復雜性。

不同應用軟件間越來越多的互相依賴導致整個項目難以管理。如果一個應用軟件依賴于另一個，那么這兩個應用軟件的開發(fā)團隊就必須在開發(fā)計劃，測試計劃和變更管理方面進行協(xié)調。把這個擴大到五十至一百個應用軟件之間，你最終會在相互依賴的應用軟件和團隊所編織成的脆弱網(wǎng)絡中以失敗告終。

圖2：BPI項目：多個團隊，多個系統(tǒng)，以及一個集成團隊

BPI的另外一個挑戰(zhàn)是應用軟件的開發(fā)團隊們來自于完全各異的組織機構，所以他們往往遵循不同的開發(fā)過程，使用不同的術語和開發(fā)工具。盡管使用有細微差別的工具或者將關鍵術語賦予略有不同的含義看起來是微不足道的問題，但是如果將這些通過多種渠道傳來的花費數(shù)月工作量的不協(xié)調累計起來，就會在不同團隊間產生大量的不必要的矛盾。所以，下一小節(jié)我們將會討論BPI項目取得成功的第一條基本原則：使用規(guī)范的開發(fā)過程和工具集。

使組織過程和工具規(guī)范化：

在討論如何規(guī)范開發(fā)過程和工具之前，讓我們先來看一看為什么要這么做。

首先，我們應當在這里區(qū)分采用任意一個特定的方法學同采用一個規(guī)范化的 方法學的差別。一個特定的團隊可能會認識到只要采用任一種開發(fā)過程而不是什么臨時方案就可以獲得生產力。但是，如果不同的團隊開始在一項大規(guī)模的業(yè)務流程集成項目中共同工作時，開發(fā)過程的差異就會導致不必要的矛盾和生產力的損失。

一個組織機構可以通過降低復雜度將某個單一過程的規(guī)范化推而廣之到更大型的項目中，從而消除大量的無用功。最終的結果是縮短了產品進入市場的時間，獲得了更高的質量，以及壓縮了成本。節(jié)省下來的這些開銷將會被繼續(xù)投入到進一步增強產品功能之中，或者用于企業(yè)的其他投資項目，或者回報給股東。

各不相同的開發(fā)過程和工具在許多方面導致了復雜性的增加和不必要的浪費。當不同的團隊遵循不同的開發(fā)過程時，有合作關系的團隊間就必須不斷地處理由于彼此間不同的術語、工件和圖表結構以及一般性任務的處理方法所造成的問題。舉個例子，一個團隊可能使用用例圖傳達功能需求，然而另外那個團隊卻可能使用傳統(tǒng)的“應該……”這種表述方式。這些團隊于是就會在系統(tǒng)邊界處的功能表述問題上產生問題。

當項目中使用不統(tǒng)一的開發(fā)工具時，想在不同團隊間共享數(shù)據(jù)，或者在抽象的更高層次中收集和分析項目的數(shù)據(jù)，即使并非不可能，也一定是非常困難的事情。在BPI項目中，經(jīng)常會出現(xiàn)一個團隊需要使用另一個團隊的某個需求來證明相關聯(lián)性。如果這些團隊使用的是不同的需求管理工具，那么他們就需要在多個系統(tǒng)中輸入相同的需求，進行并行的修改，并建立多個追蹤鏈接以確保一致性。

不幸地是，建立一個規(guī)范化的開發(fā)過程和工具集是一件非常困難的事情。為什么呢？

• 開發(fā)團隊通常很不情愿使用規(guī)范化的開發(fā)過程和工具集，除非自身的開發(fā)過程和工具集就是規(guī)范的，
  
  
• 短期的商業(yè)需要和沖突經(jīng)常延緩長期的開發(fā)過程和工具集的標準化工作的進程；
  
  
• 團隊成員需要經(jīng)過培訓后才能有效地使用規(guī)范化的開發(fā)過程和工具集。

轉換到規(guī)范化的開發(fā)過程和工具集需要強有力的管理層支持，經(jīng)過慎重考慮后確定的路標，以及持久的執(zhí)行。與其使用武斷的方法來試圖轉變整個企業(yè)，我更建議各組織機構根據(jù)BPI項目的內容使用新的開發(fā)過程和工具集。這些項目包括許多不同團隊各不相同的過程領域的集成，他們還需要內部團隊的有效協(xié)調來取得成功。在這樣的環(huán)境中，團隊成員們就會很容易的看到規(guī)范化的開發(fā)過程和工具集所帶來的巨大好處，并且深刻意識到這才是獲得成功的必備條件。

關注那些關鍵的團隊成果以及相關的活動：

組織機構通常都會犯這樣一個錯誤，那就是試圖一下子就去規(guī)范化所有東西。這就不可避免的導致了失敗。以此引入過多的變化必將導致巨大的混亂，團隊成員們就會退回到以前那種陳舊的，支離破碎的開發(fā)過程中。

一個開發(fā)過程從本質上來說就是角色、工件和工作流程的集成體。因而我建議組織應該通過在BPI項目中關注那些關鍵協(xié)同完成的工件來實現(xiàn)規(guī)范化。

• 需求；
  
  
• 變更請求；
  
  
• 集成項目計劃；
  
  
• 技術接口規(guī)格。

需求和變更請求決定系統(tǒng)的最終范圍。集成項目計劃則確保團隊之間的相互依賴在可管理的范圍內，項目能夠按日程表的進度進行以及不超出預算。技術接口規(guī)格定義了開發(fā)應用軟件的不同團隊間的通訊協(xié)議。

在BPI的開發(fā)過程中沒有白紙一樣的東西，我們總是要在現(xiàn)有的系統(tǒng)上工作。 ³ 在某種意義上，BPI項目中的每一項需求都可以看作是一個變更請求。所以，在本文中我們區(qū)分需求和變更請求的標準就是看它們何時被納入到項目范圍中。一個需求是在對迭代范圍基線化之前你所接受的范圍的一個單元，而一個變更請求則是在你對迭代范圍基線化之后對原有范疇的一個增量（增加、刪除或者修改）。

在迭代方式中采用新工具：

出于一些原因，正常而明智的信息技術專業(yè)人員經(jīng)常不相信“軟件物理學法則”適用于新的軟件開發(fā)工具的部署。即使懂得迭代地開發(fā)商業(yè)應用軟件是一種明智的行為，但是他們仍抱有這樣一種錯誤的想法，那就是它們可以一次性地成功部署出一個完整的新工具集。

一個較好的原則是每次只采用一個大型的開發(fā)工具。規(guī)范化這樣一個工具是一項長期的投資，在團隊使用新的開發(fā)工具提高技術含量時需要先期的投資，包括培訓、數(shù)據(jù)遷移以及生產力受到影響。

BPI項目應該將關注點放在它所能產生的新的商業(yè)能力上，而不是放在采用新的開發(fā)工具上。一次就引入多于一種主要的開發(fā)工具只能給項目的成功系數(shù)帶來消極的影響。

在部署新工具前對團隊成員進行再培訓：

正如我們前面所提到的，工具應該服務于開發(fā)過程，而不是限制它。即使為戰(zhàn)略性的開發(fā)過程定制一個配套的開發(fā)工具，它仍將會促使產生出某種“世界觀”，并不可避免地影響到原先制定的開發(fā)過程。

試圖部署新的開發(fā)工具而不對團隊成員進行再培訓將會導致下面這些負面結果：

• 團隊成員抵制使用這種新工具，因為他們并不理解它所支持的這種開發(fā)過程；
  
  
• 團隊成員試圖將他們原來舊的開發(fā)過程強塞進這種新工具中。

對團隊成員進行再培訓是一項非常值得的投資，首先是要教授那套不久即將成為標準的開發(fā)過程，然后是教授如何使用相應的開發(fā)工具。這種培訓可以使非正式的，但必須要通過某種形式來開展。

在開發(fā)周期的間歇部署新的開發(fā)工具：

如果想要過渡到使用新的開發(fā)工具，就應該選擇一個團隊成員們時間安排較為靈活的時間段。例如，如果要引入IBM公司的? Rational RequisitePro? 軟件來管理需求，臨近開發(fā)成果的結束階段是一個較為合理的引入時間，因為那時整個開發(fā)過程已經(jīng)趨于穩(wěn)定，并且系統(tǒng)分析員也擁有更多的時間來接受培訓。另外一個對團隊進行培訓的適宜時間是兩個項目之間的間隙，這是因為開發(fā)者們此時完成了一項項目的最后一段工作，并且已經(jīng)準備轉換到另一項項目的起步階段。

如果你已經(jīng)決定在開發(fā)間歇采用新工具，那么請意識到項目經(jīng)理們可能并不會對這種必要的培訓提供支持，因為他們本打算將這些人力派往其它的項目中去，因而培訓這些人力就意味著喪失項目的收益。為了避免這種情況，最好是由工會人力資源組織所提供的職業(yè)發(fā)展預算來提供培訓支持，而不是由項目預算來提供。

以上我們分析了開發(fā)工具和過程，下面我們來看看組織結構對于BPI項目的順利實施發(fā)揮何種影響。

建立一個一致的組織結構：

正如我們前面所討論過的，BPI項目是多方面相關的復合體。它們有若干業(yè)務流程領域，若干功能規(guī)范，各不相同的開發(fā)過程、術語學和文檔格式。你可以通過建立清晰的領導層以及將多種應用歸類為模式化的單元來減輕系統(tǒng)的復雜性。在下面兩個小節(jié)中，我們將會探求這些技術手段。

為每一個關鍵的項目角色設置一個領導者：

對于一個小規(guī)模的團隊，在關鍵角色中設置領導相對容易一些，比如項目經(jīng)理、架構師、系統(tǒng)分析師以及變更經(jīng)理。然而，在大型的BPI項目中往往產生領導層的問題。問題并不在于在項目層面上沒有關鍵人物的領導層，更不在于某個人試圖領導每一個角色，而是在于能夠真正掌控項目的人似乎并不是那么明確。

第一種情形出現(xiàn)的原因很容易理解。要想在大型的BPI層面上領導管理，需要具備不同過程組織結構所涉及到的廣博的知識面，而且還要具備協(xié)調遵循不同過程工作的各個團隊的能力。

第二種情形，即兩個或者更多的人爭當關鍵位置的領導者，這種情況通常在當兩個大型的組織機構需要合作開發(fā)某個大規(guī)模的集成項目時發(fā)生。來自不同組織的領導者們將會爭奪BPI層面上的領導權。即便你設法通過協(xié)商來設立一個共同的領導層，這也將導致決策速度的延緩。

為了獲得及時和權威的決定，項目中需要在如下的關鍵任務中明確一個單一的領導者：

• 項目經(jīng)理領導者；
  
  
• 架構師領導者；
  
  
• 系統(tǒng)分析師領導者；
  
  
• 測試經(jīng)理領導者。

這些領導者應當從其它團隊成員出收集信息，但是，最終它們必須作出對整個項目最有力的權威的決定。

一個出色的BPI項目領導者究竟都需要具備什么素質呢？理論上說，關鍵人物的領導者應當最少具備在該組織結構目前的應用投資組合中三年以上的相應能力的工作經(jīng)驗。這些人熟悉大部分在應用投資組合中有知識有影響的人員，所以他們能夠很快的收集至關重要的信息，解決潛在的問題，以及委派小規(guī)模的工作任務。

將應用軟件分解為更小的、半獨立的單元：

我曾經(jīng)在一個具有上千個應用的大型的內部IBM項目中工作過，我們將其分解為15個功能領域，用粗粒度的業(yè)務流程加以組織，例如“市場和銷售”和“完成訂制”。盡管每一個這樣的領域都包含30-400個應用軟件，但是在那些熟悉每一個領域里的相應應用的高級項目經(jīng)理和架構師的協(xié)助工作下，我們能夠實現(xiàn)僅僅處理15個子系統(tǒng)而不是上千個應用軟件。

很顯然，期望某個人理解一個或者兩個以上復雜應用的具體細節(jié)是不現(xiàn)實的。一個大型的BPI項目可能涉及到數(shù)十個甚至數(shù)百個應用。在這種情況下，應該考慮通過將所有應用按照業(yè)務流程領域分組來使項目結構實現(xiàn)模塊化。舉例來說，你可以將所有有關財務的應用或者所有網(wǎng)上貿易的應用歸并在一起。

圖3：應用軟件的非模塊視圖與模塊視圖的對比

在任何應用領域，任命一個項目經(jīng)理和一個構架師都代表著該領域在項目上的水平。這要求技術管理者從一個相對來說粗粒度的水平去考慮一個復雜的龐大項目系統(tǒng)。

為每個重要的功能部分建立相應具有代表性的委員會

當我在另一個大型的BPI項目中擔任一個業(yè)務流程或集成架構師的工作時，我負責一個每周例行的架構方面的相互協(xié)調會議。盡管我們在這套超級系統(tǒng)中擁有大約10個大型的子系統(tǒng)，但只有7個子系統(tǒng)對于每周的構架檢查點具有代表性。

這些需求本身坦白來說一般都不太令人滿意；大多數(shù)典型代表都是非常難以修改的，并且常伴有讓人難以忍受的自我沖突和技術主張。然而，那些沒有注意這些早期構架需求的項目，最終變得更加令人失望。當我們完成了我們的第一個開發(fā)階段的迭代并且開始進行集成測試，這些在需求上不具典型性的子系統(tǒng)會發(fā)現(xiàn)非常大的集成問題。

早期的會議可能太簡單，令人不滿意，因為你是在事先解決問題而不是在事后。那些略過會議和爭論的團隊也無法讓問題隨之溜走，他們只是簡單的把問題拖延到了以后。

預先降低項目風險最有效的途徑是讓每一個重要功能規(guī)程的小組（項目管理、需求、構架、測試、變更管理和部署）能夠與他們的子系統(tǒng)領導頻繁地協(xié)調溝通。另外，子系統(tǒng)領導應該建立一個“變更委員會”以此來應對跨過子系統(tǒng)邊界的有規(guī)律的對任何改動的評論和通過。

圖4：職能領導和協(xié)調

既然我們已經(jīng)討論過如何成功地組織一個項目，現(xiàn)在讓我們來討論一些更為具體和重要的開發(fā)過程：需求和管理變更。

優(yōu)化需求和變更管理過程

正如我們先前討論的，需求和變更請求，各自都是BPI項目中最為重要的工件。下面是優(yōu)化這些項目元素的具體技術。

使用迭代化方法交付功能

我強烈推薦在您的項目中遵循一種迭代的部署過程，這使得您能在大約幾周內了解從概念到系統(tǒng)的運行，而不需要幾個月甚至幾年。這對于BPI特別重要，因為新的功能性被討論的時候通常停留在一個抽象的高水平上，需要來自不同的涉眾的廣泛的、不同的進一步闡釋。早期傳遞大多數(shù)新功能的時候，通過一系列的迭代，使涉眾能夠看到、接觸到并且對新功能給予反應，這樣一來，如果有需要的話，您可以快速的明確和重新定義需求，并且在問題比較容易解決的時候發(fā)現(xiàn)和解決問題。

使用迭代方法的另一個原因是，在BPI項目中用來集成的子系統(tǒng)實際上是大型應用軟件或大型應用軟件的集成。傳統(tǒng)的瀑布方法使得子系統(tǒng)集成滯后到生命周期的最后階段，這時您可能會發(fā)現(xiàn)高錯誤率并且發(fā)現(xiàn)自己有大量的工作要重做。

如果您使用迭代化方法，比較理想的，您的測試環(huán)境應該能后映射您的成果環(huán)境；最起碼，能夠模擬該環(huán)境。由于它包含了許多應用軟件和潛在的上百臺的服務器，這項操作的花費可能看起來被BPI所禁止。但是如果您去考慮在項目上的大量的重復工作的開銷與預先在大型測試環(huán)境上的投資做一個對比，我相信您會選擇后者。

警告：迭代化開發(fā)使得您能很容易的向現(xiàn)有架構中簡單的添加功能，但是同時也使得您想要改變主要架構變得更加困難。如果您想要在大型的超級系統(tǒng)中做一個基本架構的修改，例如，用一個SAP部署來代替自產的ERP系統(tǒng)，您將會被引誘到一個給您帶來沉重打擊的道路上。但是，您可以使用另一種更加明智的迭代化方法,即便您想要對主要架構做一些修改。再來看SAP的例子，您可以通過一系列的版本從自定義的應用軟件向SAP發(fā)展改變其功能性，通常利用開啟越來越多地SAP自帶功能來實現(xiàn)。

每個涉眾組只允許一個代表去提交需求和更改需求。

在大型的項目中，成百上千的工人會直接或間接地參與到項目的執(zhí)行中。如果任何與項目有關的人都能夠提交新的需求和/或變更需求，那項目會很快地陷入一片混亂并失去控制。相反，最好的辦法是讓每個涉眾組正確地任命一個代表，代表全組來負責提交需求和更改需求。

一個涉眾工作組是有什么人組成的呢？理想狀態(tài)下，小組應該包含與你在概念階段建立項目視圖時所定義的機制相同。

對于一個大型的BPI項目來說，擁有多個涉眾是很平常的。在一個典型的供應鏈集成項目中，例如，行銷，出售，實行，以及財務都屬于涉眾。每個組都需要一個明確的代表來提交和改變需求。

未來的用戶包含通過系統(tǒng)（例如通過網(wǎng)絡或是電話接口）與您的公司有直接交互的顧客和商業(yè)合作者和那些利用系統(tǒng)來完成工作的雇員。這些用戶是典型的公司代理（比如顧客維護組織），因為管理與成百的或是上千的實際用戶、商業(yè)伙伴和雇員交互是不可能的。

BPI項目的開發(fā)團隊實際上是一個擁有很多團隊的團隊，每個團隊負責超級系統(tǒng)中的一個大型的子系統(tǒng)。由于一個大型的BPI項目可能包含十幾個甚至上百的應用軟件，這如我們前面所討論的，這些子系統(tǒng)實際成為一個對商業(yè)過程領域軟件的收集者。接下來，每個子系統(tǒng)的開發(fā)團隊的代表可以向申明獨立性和計劃變更需求的變更委員會去提交系統(tǒng)需求，并在以后的開發(fā)過程中修改這些需求。

區(qū)分各種需求變更

巧妙的響應一個變更需求，您需要首先了解變更的原因。盡管這些原因可能無窮無盡，但是，只有一小部分正當理由能夠證明系統(tǒng)需要變更。

• 在外部商業(yè)環(huán)境中的變更
  
  
• 商業(yè)問題的錯誤理解
  
  
• 方案中的技術性瑕疵

商業(yè)外部環(huán)境的變更。這種變化會帶來一系列廣泛的影響，從指示一些瑣碎細節(jié)的變更到更新整個陳舊的項目。例如，在2004年，IBM有許多項目想要去提升PC生意。公司宣布完全停止這些項目并將其賣給聯(lián)想，同時把商業(yè)焦點轉移到整頓上的工作上。

總體來說，那些特許的和投資的商業(yè)涉眾應該向項目團隊來宣布在外部商業(yè)環(huán)境中的變更。最終，他們將是改變項目范圍的決策者，他們同架構領導者和項目管理者一同決定如何去響應這個改變。假設這個項目還存在，BPI級別的項目管理者同各自子系統(tǒng)的管理者一起去指定隨后的計劃并構思設計適合于商業(yè)改變的相應改動。

商業(yè)問題的錯誤理解。團隊在一開始對商業(yè)問題有一個不太正確的理解幾乎是個不可避免的問題。然而，隨著項目從概念進展到原型再到運行系統(tǒng)，業(yè)務和開發(fā)團隊對業(yè)務問題的理解應當會逐漸從模糊走向具體。熟練的開發(fā)團隊使用技術去盡早的獲得清楚地認識，其中包括原型和更少的反復過程。當他們發(fā)現(xiàn)錯誤理解商業(yè)問題所帶來的問題時，架構領導者將會同商業(yè)涉眾更新設計方案，這些改變將會影響到一個或多個子系統(tǒng)。

方案中的技術性瑕疵。技術上的瑕疵與其他合法的可變驅動是不同的，因為它與商業(yè)領域毫無關系；典型的，它是由開發(fā)團隊提出的而非商業(yè)團隊。技術上的瑕疵在子系統(tǒng)的邊緣更為盛行，問題更多。一個團隊可能意識到它的子系統(tǒng)需要一個來自上層子系統(tǒng)的額外的數(shù)據(jù)元素，這樣它才能夠運行正確。這些變更應該在變更委員會之前被子系統(tǒng)的代表提出來。唯一的例外是如果設計上的瑕疵完全在一個子系統(tǒng)中，那么子系統(tǒng)的團隊可以獨自控制該變更。我們將會在下面仔細討論這個問題。

在子系統(tǒng)團隊內處理局部變更

一個集中式的、高水準的BPI項目領導團隊的底線是當你在項目的精心制作和建造過程中進入到細節(jié)的工作時，能夠比較容易的形成一個瓶頸。如果每個需求和需求變更，不論它多小，都必須通過變更委員會，那么，進步不是很慢就是緩緩前進，要不就是在創(chuàng)新的道路上迂回不前。與控制每個細節(jié)（需求和設計）方面相比，領導組把具體的活動放到稍低的層次顯得更加合理。

由外部商業(yè)環(huán)境（參見前面的章節(jié)）所引起的改變應該通過變更委員會，因為架構領導者必須要決定如何在超級系統(tǒng)中實現(xiàn)變更。然而，設計上的瑕疵帶來的變更則不需要再通過變更委員會。

需要變更兩個或多個子系統(tǒng)的修改應該需要通過變更委員會來確定每個部分都達成一致意見。然而，如果需求或是變更需要在一個子系統(tǒng)的局部，該子系統(tǒng)可以獨立操作變更。他們在這個領域是無可厚非的專家，能夠精確并快速地處理變更；請示變更委員會并沒有帶來更多的優(yōu)勢反而降低了解決問題的效率。只有在變更會嚴重影響子系統(tǒng)進度，進一步影響超級系統(tǒng)進度的時候才有必要在局部工作中使用變更委員會。

避免暫時的、手動的工作區(qū)

BPI項目團隊在緊張的工作安排中可能會感到他們需要求助于手動工作區(qū)來避免復雜的軟件設計問題。手動工作區(qū)有兩種類型：一次性的變更和正在進行的程序步驟。

我的工作成功地實現(xiàn)一個一次性的工作區(qū)。該項目的一個主要需求是將一個顧客的CRM應用軟件改為一個賣家的CRM包。這包括定制一個與現(xiàn)有性能和移植后的客戶數(shù)據(jù)庫相匹配的CRM應用軟件包。在構建階段的過程中，開發(fā)人員們發(fā)現(xiàn)他們忽略了移植一個包含一些對整個商業(yè)數(shù)據(jù)非常重要的小型客戶數(shù)據(jù)庫的需要。他們認識到通過寫腳本來移植會破壞工作表。這一發(fā)現(xiàn)帶來了恐慌。然而，最后大家提出，由于數(shù)據(jù)庫比較小，可以雇傭一組臨時工作者利用一周的時間手工向新系統(tǒng)中輸入數(shù)據(jù)來代替書寫復雜的腳本。這個解決方法實行了，數(shù)據(jù)移植的開銷相對降低了，并且沒有打亂項目的工作安排和預算。

類似這樣的一次性的工作區(qū)可能更傾向于開發(fā)只使用一次的軟件（除非軟件在一個龐大的數(shù)據(jù)集上操作）。

暫時性手工工作區(qū)的吸引力更小，它將成為日常操作的一部分。執(zhí)行這樣的一個工作區(qū)開銷通常很大（必須雇用人去執(zhí)行這個工作），如果它被完全替換，它將需要很長時間轉化成永久的IT解決辦法。作為一個商業(yè)業(yè)主，當你被建議使用一個暫時性的手工工作區(qū)時，一定要確定在一個將來的版本中您能獲得一個永久的IT解決辦法，并且相應的風險比較小。

總結

在這篇文章中，我們討論了一些關于BPI項目的獨特特點和問題。接著，我描述了一些解決此類問題的基本規(guī)則和技術。進一步，我們希望能夠看到越來越多的大型集成項目，因此學習如何正面的面對這些問題并有效地解決它們變得非常重要。能完成這項工作的團隊會創(chuàng)造出更加實用的系統(tǒng)，并使得他們的組織在市場中更有競爭力。

感謝

感謝以下每一個人，他們給與我在本文中提到的很多思想：Carolyn Maher, Grady Booch, Jay Strosnider, John Hartley, James Jamison, Kurt Bittner, Ralph Nelson, Russ Taylor, and Simon Johnston.

同時謝謝 Marlene Ellin 在編輯過程中的耐心指導和 Kurt Bittner， Michael Hanford 在本文初期迭代階段提供反饋。

詳細閱讀和參考資料

Kurt Bittner and Ian Spence, Use Case Modeling. Addison-Wesley Professional, 2002.

Frederick P. Brooks, The Mythical Man-Month: Essays on Software Engineering, 20^th Anniversary Edition. Addison-Wesley Professional, 1995.

Robert Galen, Software Endgames: Eliminating Defects, Controlling Change, and the Countdown to On-time Delivery. Dorset House, 2004.

"IBM‘s Sam Palmisano‘s Definition of On Demand Business" at http://www.ibm.com/e-business/za/about_ondemand/def.html

James Rumbaugh, Ivar Jacobson, and Grady Booch, Unified Modeling Language Reference Manual， 第二版， Addison-Wesley， 2004.

注釋

¹查看IBM的Sam Palmisano關于商業(yè)需求的定義http://www-5.ibm.com/e-business/za/about_ondemand/def.html

²文中提到UML部分的完整定義見 James Rumbaugh, Ivar Jacobson,和 Grady Booch 的 Unified Modeling Language Reference Manual，第二版， Addison-Wesley Professional, 2004。

³即使一個新應用軟件也不可能將完全嶄新的功能引入到超級系統(tǒng)中來。

⁴ Kurt Bittner 和 Ian Spence， Use Case Modeling。Addison-Wesley Professional， 2002。

參考資料

• 您可以參閱本文在 developerWorks 全球站點上的 英文原文。

關于作者

		Bill Higgins 是IBM公司全球服務部的一名架構師，他所從事的工作是與IBM公司的 On Demand Workplace 和 Rational 組織相關的協(xié)作開發(fā)技術。當前，他正在研究一種門戶網(wǎng)站的解決方法來幫助軟件開發(fā)團隊。他在技術方面關心的內容包括：IBM? Rational Team Unifying Platform,? IBM Lotus Workplace,? IBM WebSphere Portal Server,?將業(yè)務過程映射到IT，以及在他的IBM developerWorks blog中記錄他的活動及觀點。另外，Higgins 還擁有賓夕法尼亞大學計算機科學學士學位。