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

2005 年 10 月 19 日

來(lái)自于 Rational Edge：復(fù)雜的業(yè)務(wù)流程集成（BPI）項(xiàng)目是非常具有挑戰(zhàn)性的，這是因?yàn)椴煌牟块T可能會(huì)遵循不同的開發(fā)過(guò)程，并使用不同的開發(fā)技術(shù)和工具。本文建議管理這種項(xiàng)目的技術(shù)應(yīng)該按照三個(gè)方面來(lái)進(jìn)行：組織過(guò)程和工具，組織結(jié)構(gòu)，以及需求和變更管理過(guò)程。

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

首先，我們來(lái)分析一下一個(gè)BPI項(xiàng)目的特點(diǎn)。然后，我們將從如下三個(gè)方面來(lái)描述基本規(guī)則和技術(shù)：

• 組織過(guò)程和工具
  
  
• 組織結(jié)構(gòu)
  
  
• 需求和變更管理過(guò)程

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

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

BPI項(xiàng)目的特點(diǎn)：

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

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

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

圖1：一個(gè)通常的開發(fā)項(xiàng)目：一個(gè)團(tuán)隊(duì)，一個(gè)系統(tǒng)

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

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

圖2：BPI項(xiàng)目：多個(gè)團(tuán)隊(duì)，多個(gè)系統(tǒng)，以及一個(gè)集成團(tuán)隊(duì)

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

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

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

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

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

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

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

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

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

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

關(guān)注那些關(guān)鍵的團(tuán)隊(duì)成果以及相關(guān)的活動(dòng)：

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

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

• 需求；
  
  
• 變更請(qǐng)求；
  
  
• 集成項(xiàng)目計(jì)劃；
  
  
• 技術(shù)接口規(guī)格。

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

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

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

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

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

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

在部署新工具前對(duì)團(tuán)隊(duì)成員進(jìn)行再培訓(xùn)：

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

試圖部署新的開發(fā)工具而不對(duì)團(tuán)隊(duì)成員進(jìn)行再培訓(xùn)將會(huì)導(dǎo)致下面這些負(fù)面結(jié)果：

• 團(tuán)隊(duì)成員抵制使用這種新工具，因?yàn)樗麄儾⒉焕斫馑С值倪@種開發(fā)過(guò)程；
  
  
• 團(tuán)隊(duì)成員試圖將他們?cè)瓉?lái)舊的開發(fā)過(guò)程強(qiáng)塞進(jìn)這種新工具中。

對(duì)團(tuán)隊(duì)成員進(jìn)行再培訓(xùn)是一項(xiàng)非常值得的投資，首先是要教授那套不久即將成為標(biāo)準(zhǔn)的開發(fā)過(guò)程，然后是教授如何使用相應(yīng)的開發(fā)工具。這種培訓(xùn)可以使非正式的，但必須要通過(guò)某種形式來(lái)開展。

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

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

如果你已經(jīng)決定在開發(fā)間歇采用新工具，那么請(qǐng)意識(shí)到項(xiàng)目經(jīng)理們可能并不會(huì)對(duì)這種必要的培訓(xùn)提供支持，因?yàn)樗麄儽敬蛩銓⑦@些人力派往其它的項(xiàng)目中去，因而培訓(xùn)這些人力就意味著喪失項(xiàng)目的收益。為了避免這種情況，最好是由工會(huì)人力資源組織所提供的職業(yè)發(fā)展預(yù)算來(lái)提供培訓(xùn)支持，而不是由項(xiàng)目預(yù)算來(lái)提供。

以上我們分析了開發(fā)工具和過(guò)程，下面我們來(lái)看看組織結(jié)構(gòu)對(duì)于BPI項(xiàng)目的順利實(shí)施發(fā)揮何種影響。

建立一個(gè)一致的組織結(jié)構(gòu)：

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

為每一個(gè)關(guān)鍵的項(xiàng)目角色設(shè)置一個(gè)領(lǐng)導(dǎo)者：

對(duì)于一個(gè)小規(guī)模的團(tuán)隊(duì)，在關(guān)鍵角色中設(shè)置領(lǐng)導(dǎo)相對(duì)容易一些，比如項(xiàng)目經(jīng)理、架構(gòu)師、系統(tǒng)分析師以及變更經(jīng)理。然而，在大型的BPI項(xiàng)目中往往產(chǎn)生領(lǐng)導(dǎo)層的問(wèn)題。問(wèn)題并不在于在項(xiàng)目層面上沒(méi)有關(guān)鍵人物的領(lǐng)導(dǎo)層，更不在于某個(gè)人試圖領(lǐng)導(dǎo)每一個(gè)角色，而是在于能夠真正掌控項(xiàng)目的人似乎并不是那么明確。

第一種情形出現(xiàn)的原因很容易理解。要想在大型的BPI層面上領(lǐng)導(dǎo)管理，需要具備不同過(guò)程組織結(jié)構(gòu)所涉及到的廣博的知識(shí)面，而且還要具備協(xié)調(diào)遵循不同過(guò)程工作的各個(gè)團(tuán)隊(duì)的能力。

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

為了獲得及時(shí)和權(quán)威的決定，項(xiàng)目中需要在如下的關(guān)鍵任務(wù)中明確一個(gè)單一的領(lǐng)導(dǎo)者：

• 項(xiàng)目經(jīng)理領(lǐng)導(dǎo)者；
  
  
• 架構(gòu)師領(lǐng)導(dǎo)者；
  
  
• 系統(tǒng)分析師領(lǐng)導(dǎo)者；
  
  
• 測(cè)試經(jīng)理領(lǐng)導(dǎo)者。

這些領(lǐng)導(dǎo)者應(yīng)當(dāng)從其它團(tuán)隊(duì)成員出收集信息，但是，最終它們必須作出對(duì)整個(gè)項(xiàng)目最有力的權(quán)威的決定。

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

將應(yīng)用軟件分解為更小的、半獨(dú)立的單元：

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

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

圖3：應(yīng)用軟件的非模塊視圖與模塊視圖的對(duì)比

在任何應(yīng)用領(lǐng)域，任命一個(gè)項(xiàng)目經(jīng)理和一個(gè)構(gòu)架師都代表著該領(lǐng)域在項(xiàng)目上的水平。這要求技術(shù)管理者從一個(gè)相對(duì)來(lái)說(shuō)粗粒度的水平去考慮一個(gè)復(fù)雜的龐大項(xiàng)目系統(tǒng)。

為每個(gè)重要的功能部分建立相應(yīng)具有代表性的委員會(huì)

當(dāng)我在另一個(gè)大型的BPI項(xiàng)目中擔(dān)任一個(gè)業(yè)務(wù)流程或集成架構(gòu)師的工作時(shí)，我負(fù)責(zé)一個(gè)每周例行的架構(gòu)方面的相互協(xié)調(diào)會(huì)議。盡管我們?cè)谶@套超級(jí)系統(tǒng)中擁有大約10個(gè)大型的子系統(tǒng)，但只有7個(gè)子系統(tǒng)對(duì)于每周的構(gòu)架檢查點(diǎn)具有代表性。

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

早期的會(huì)議可能太簡(jiǎn)單，令人不滿意，因?yàn)槟闶窃谑孪冉鉀Q問(wèn)題而不是在事后。那些略過(guò)會(huì)議和爭(zhēng)論的團(tuán)隊(duì)也無(wú)法讓問(wèn)題隨之溜走，他們只是簡(jiǎn)單的把問(wèn)題拖延到了以后。

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

圖4：職能領(lǐng)導(dǎo)和協(xié)調(diào)

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

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

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

使用迭代化方法交付功能

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

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

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

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

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

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

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

對(duì)于一個(gè)大型的BPI項(xiàng)目來(lái)說(shuō)，擁有多個(gè)涉眾是很平常的。在一個(gè)典型的供應(yīng)鏈集成項(xiàng)目中，例如，行銷，出售，實(shí)行，以及財(cái)務(wù)都屬于涉眾。每個(gè)組都需要一個(gè)明確的代表來(lái)提交和改變需求。

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

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

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

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

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

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

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

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

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

在子系統(tǒng)團(tuán)隊(duì)內(nèi)處理局部變更

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

由外部商業(yè)環(huán)境（參見前面的章節(jié)）所引起的改變應(yīng)該通過(guò)變更委員會(huì)，因?yàn)榧軜?gòu)領(lǐng)導(dǎo)者必須要決定如何在超級(jí)系統(tǒng)中實(shí)現(xiàn)變更。然而，設(shè)計(jì)上的瑕疵帶來(lái)的變更則不需要再通過(guò)變更委員會(huì)。

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

避免暫時(shí)的、手動(dòng)的工作區(qū)

BPI項(xiàng)目團(tuán)隊(duì)在緊張的工作安排中可能會(huì)感到他們需要求助于手動(dòng)工作區(qū)來(lái)避免復(fù)雜的軟件設(shè)計(jì)問(wèn)題。手動(dòng)工作區(qū)有兩種類型：一次性的變更和正在進(jìn)行的程序步驟。

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

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

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

總結(jié)

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

感謝

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

同時(shí)謝謝 Marlene Ellin 在編輯過(guò)程中的耐心指導(dǎo)和 Kurt Bittner， Michael Hanford 在本文初期迭代階段提供反饋。

詳細(xì)閱讀和參考資料

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關(guān)于商業(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。

³即使一個(gè)新應(yīng)用軟件也不可能將完全嶄新的功能引入到超級(jí)系統(tǒng)中來(lái)。

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

參考資料

• 您可以參閱本文在 developerWorks 全球站點(diǎn)上的 英文原文。

關(guān)于作者

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