| Bill Higgins, Architect, Systems Engineering and Architecture, IBM Global Services 2005 年 10 月 19 日 來(lái)自于 Rational Edge：復雜的業(yè)務(wù)流程集成（BPI）項目是非常具有挑戰性的，這是因為不同的部門(mén)可能會(huì )遵循不同的開(kāi)發(fā)過(guò)程，并使用不同的開(kāi)發(fā)技術(shù)和工具。本文建議管理這種項目的技術(shù)應該按照三個(gè)方面來(lái)進(jìn)行：組織過(guò)程和工具，組織結構，以及需求和變更管理過(guò)程。  首先，我們來(lái)分析一下一個(gè)BPI項目的特點(diǎn)。然后，我們將從如下三個(gè)方面來(lái)描述基本規則和技術(shù)：
我們將在后面分別加以討論。
在大型企業(yè)中，業(yè)務(wù)流程重構工作是一項非常復雜的項目，可能要花費數年，并涉及到眾多的人力和信息技術(shù)系統。典型的BPI項目包括連接、簡(jiǎn)化和組織一個(gè)大規模的業(yè)務(wù)流程及其支持應用軟件。 要想理解以下所描述的能夠提高這種項目成功可能性的技術(shù)，重要的是要首先理解BPI項目和更典型的應用軟件開(kāi)發(fā)項目之間存在的差異。 不論是BPI還是應用軟件開(kāi)發(fā)項目，都是在交付新的軟件組件或已有軟件組件的新版本，它們都會(huì )用于更好地支持一個(gè)企業(yè)的業(yè)務(wù)流程。一個(gè)軟件開(kāi)發(fā)團隊――由項目經(jīng)理、分析師、開(kāi)發(fā)人員、測試人員以及部署人員組成――共同工作，以推動(dòng)完成一個(gè)可配置的和可靠的系統來(lái)支持一組商業(yè)目標的實(shí)現。  圖1：一個(gè)通常的開(kāi)發(fā)項目：一個(gè)團隊，一個(gè)系統 然而，BPI項目同應用軟件開(kāi)發(fā)項目最根本的不同就在于組織上和設計上的復雜性。一個(gè)典型的應用軟件開(kāi)發(fā)項目也許只需要二十到五十人共同工作，整個(gè)系統也只有50,000至100,000行代碼。與此形成鮮明對照的是，BPI項目則可能涉及二十到一百個(gè)應用軟件，而每一個(gè)應用軟件都有自己的開(kāi)發(fā)團隊和相當規模的代碼量。如此大量的應用軟件并不是困難的原因，真正首要的原因在于由不同應用軟件之間相互依賴(lài)所引起的復雜性。 不同應用軟件間越來(lái)越多的互相依賴(lài)導致整個(gè)項目難以管理。如果一個(gè)應用軟件依賴(lài)于另一個(gè)，那么這兩個(gè)應用軟件的開(kāi)發(fā)團隊就必須在開(kāi)發(fā)計劃，測試計劃和變更管理方面進(jìn)行協(xié)調。把這個(gè)擴大到五十至一百個(gè)應用軟件之間，你最終會(huì )在相互依賴(lài)的應用軟件和團隊所編織成的脆弱網(wǎng)絡(luò )中以失敗告終。  圖2：BPI項目：多個(gè)團隊，多個(gè)系統，以及一個(gè)集成團隊 BPI的另外一個(gè)挑戰是應用軟件的開(kāi)發(fā)團隊們來(lái)自于完全各異的組織機構，所以他們往往遵循不同的開(kāi)發(fā)過(guò)程，使用不同的術(shù)語(yǔ)和開(kāi)發(fā)工具。盡管使用有細微差別的工具或者將關(guān)鍵術(shù)語(yǔ)賦予略有不同的含義看起來(lái)是微不足道的問(wèn)題，但是如果將這些通過(guò)多種渠道傳來(lái)的花費數月工作量的不協(xié)調累計起來(lái)，就會(huì )在不同團隊間產(chǎn)生大量的不必要的矛盾。所以，下一小節我們將會(huì )討論BPI項目取得成功的第一條基本原則：使用規范的開(kāi)發(fā)過(guò)程和工具集。
在討論如何規范開(kāi)發(fā)過(guò)程和工具之前，讓我們先來(lái)看一看為什么要這么做。 首先，我們應當在這里區分采用任意一個(gè)特定的方法學(xué)同采用一個(gè)規范化的 方法學(xué)的差別。一個(gè)特定的團隊可能會(huì )認識到只要采用任一種開(kāi)發(fā)過(guò)程而不是什么臨時(shí)方案就可以獲得生產(chǎn)力。但是，如果不同的團隊開(kāi)始在一項大規模的業(yè)務(wù)流程集成項目中共同工作時(shí)，開(kāi)發(fā)過(guò)程的差異就會(huì )導致不必要的矛盾和生產(chǎn)力的損失。 一個(gè)組織機構可以通過(guò)降低復雜度將某個(gè)單一過(guò)程的規范化推而廣之到更大型的項目中，從而消除大量的無(wú)用功。最終的結果是縮短了產(chǎn)品進(jìn)入市場(chǎng)的時(shí)間，獲得了更高的質(zhì)量，以及壓縮了成本。節省下來(lái)的這些開(kāi)銷(xiāo)將會(huì )被繼續投入到進(jìn)一步增強產(chǎn)品功能之中，或者用于企業(yè)的其他投資項目，或者回報給股東。 各不相同的開(kāi)發(fā)過(guò)程和工具在許多方面導致了復雜性的增加和不必要的浪費。當不同的團隊遵循不同的開(kāi)發(fā)過(guò)程時(shí)，有合作關(guān)系的團隊間就必須不斷地處理由于彼此間不同的術(shù)語(yǔ)、工件和圖表結構以及一般性任務(wù)的處理方法所造成的問(wèn)題。舉個(gè)例子，一個(gè)團隊可能使用用例圖傳達功能需求，然而另外那個(gè)團隊卻可能使用傳統的“應該……”這種表述方式。這些團隊于是就會(huì )在系統邊界處的功能表述問(wèn)題上產(chǎn)生問(wèn)題。 當項目中使用不統一的開(kāi)發(fā)工具時(shí)，想在不同團隊間共享數據，或者在抽象的更高層次中收集和分析項目的數據，即使并非不可能，也一定是非常困難的事情。在BPI項目中，經(jīng)常會(huì )出現一個(gè)團隊需要使用另一個(gè)團隊的某個(gè)需求來(lái)證明相關(guān)聯(lián)性。如果這些團隊使用的是不同的需求管理工具，那么他們就需要在多個(gè)系統中輸入相同的需求，進(jìn)行并行的修改，并建立多個(gè)追蹤鏈接以確保一致性。 不幸地是，建立一個(gè)規范化的開(kāi)發(fā)過(guò)程和工具集是一件非常困難的事情。為什么呢？
轉換到規范化的開(kāi)發(fā)過(guò)程和工具集需要強有力的管理層支持，經(jīng)過(guò)慎重考慮后確定的路標，以及持久的執行。與其使用武斷的方法來(lái)試圖轉變整個(gè)企業(yè)，我更建議各組織機構根據BPI項目的內容使用新的開(kāi)發(fā)過(guò)程和工具集。這些項目包括許多不同團隊各不相同的過(guò)程領(lǐng)域的集成，他們還需要內部團隊的有效協(xié)調來(lái)取得成功。在這樣的環(huán)境中，團隊成員們就會(huì )很容易的看到規范化的開(kāi)發(fā)過(guò)程和工具集所帶來(lái)的巨大好處，并且深刻意識到這才是獲得成功的必備條件。 關(guān)注那些關(guān)鍵的團隊成果以及相關(guān)的活動(dòng)： 組織機構通常都會(huì )犯這樣一個(gè)錯誤，那就是試圖一下子就去規范化所有東西。這就不可避免的導致了失敗。以此引入過(guò)多的變化必將導致巨大的混亂，團隊成員們就會(huì )退回到以前那種陳舊的，支離破碎的開(kāi)發(fā)過(guò)程中。 一個(gè)開(kāi)發(fā)過(guò)程從本質(zhì)上來(lái)說(shuō)就是角色、工件和工作流程的集成體。因而我建議組織應該通過(guò)在BPI項目中關(guān)注那些關(guān)鍵協(xié)同完成的工件來(lái)實(shí)現規范化。
需求和變更請求決定系統的最終范圍。集成項目計劃則確保團隊之間的相互依賴(lài)在可管理的范圍內，項目能夠按日程表的進(jìn)度進(jìn)行以及不超出預算。技術(shù)接口規格定義了開(kāi)發(fā)應用軟件的不同團隊間的通訊協(xié)議。 在BPI的開(kāi)發(fā)過(guò)程中沒(méi)有白紙一樣的東西，我們總是要在現有的系統上工作。 3 在某種意義上，BPI項目中的每一項需求都可以看作是一個(gè)變更請求。所以，在本文中我們區分需求和變更請求的標準就是看它們何時(shí)被納入到項目范圍中。一個(gè)需求是在對迭代范圍基線(xiàn)化之前你所接受的范圍的一個(gè)單元，而一個(gè)變更請求則是在你對迭代范圍基線(xiàn)化之后對原有范疇的一個(gè)增量（增加、刪除或者修改）。 出于一些原因，正常而明智的信息技術(shù)專(zhuān)業(yè)人員經(jīng)常不相信“軟件物理學(xué)法則”適用于新的軟件開(kāi)發(fā)工具的部署。即使懂得迭代地開(kāi)發(fā)商業(yè)應用軟件是一種明智的行為，但是他們仍抱有這樣一種錯誤的想法，那就是它們可以一次性地成功部署出一個(gè)完整的新工具集。 一個(gè)較好的原則是每次只采用一個(gè)大型的開(kāi)發(fā)工具。規范化這樣一個(gè)工具是一項長(cháng)期的投資，在團隊使用新的開(kāi)發(fā)工具提高技術(shù)含量時(shí)需要先期的投資，包括培訓、數據遷移以及生產(chǎn)力受到影響。 BPI項目應該將關(guān)注點(diǎn)放在它所能產(chǎn)生的新的商業(yè)能力上，而不是放在采用新的開(kāi)發(fā)工具上。一次就引入多于一種主要的開(kāi)發(fā)工具只能給項目的成功系數帶來(lái)消極的影響。 正如我們前面所提到的，工具應該服務(wù)于開(kāi)發(fā)過(guò)程，而不是限制它。即使為戰略性的開(kāi)發(fā)過(guò)程定制一個(gè)配套的開(kāi)發(fā)工具，它仍將會(huì )促使產(chǎn)生出某種“世界觀(guān)”，并不可避免地影響到原先制定的開(kāi)發(fā)過(guò)程。 試圖部署新的開(kāi)發(fā)工具而不對團隊成員進(jìn)行再培訓將會(huì )導致下面這些負面結果：
對團隊成員進(jìn)行再培訓是一項非常值得的投資，首先是要教授那套不久即將成為標準的開(kāi)發(fā)過(guò)程，然后是教授如何使用相應的開(kāi)發(fā)工具。這種培訓可以使非正式的，但必須要通過(guò)某種形式來(lái)開(kāi)展。 在開(kāi)發(fā)周期的間歇部署新的開(kāi)發(fā)工具： 如果想要過(guò)渡到使用新的開(kāi)發(fā)工具，就應該選擇一個(gè)團隊成員們時(shí)間安排較為靈活的時(shí)間段。例如，如果要引入IBM公司的? Rational RequisitePro? 軟件來(lái)管理需求，臨近開(kāi)發(fā)成果的結束階段是一個(gè)較為合理的引入時(shí)間，因為那時(shí)整個(gè)開(kāi)發(fā)過(guò)程已經(jīng)趨于穩定，并且系統分析員也擁有更多的時(shí)間來(lái)接受培訓。另外一個(gè)對團隊進(jìn)行培訓的適宜時(shí)間是兩個(gè)項目之間的間隙，這是因為開(kāi)發(fā)者們此時(shí)完成了一項項目的最后一段工作，并且已經(jīng)準備轉換到另一項項目的起步階段。 如果你已經(jīng)決定在開(kāi)發(fā)間歇采用新工具，那么請意識到項目經(jīng)理們可能并不會(huì )對這種必要的培訓提供支持，因為他們本打算將這些人力派往其它的項目中去，因而培訓這些人力就意味著(zhù)喪失項目的收益。為了避免這種情況，最好是由工會(huì )人力資源組織所提供的職業(yè)發(fā)展預算來(lái)提供培訓支持，而不是由項目預算來(lái)提供。 以上我們分析了開(kāi)發(fā)工具和過(guò)程，下面我們來(lái)看看組織結構對于BPI項目的順利實(shí)施發(fā)揮何種影響。
正如我們前面所討論過(guò)的，BPI項目是多方面相關(guān)的復合體。它們有若干業(yè)務(wù)流程領(lǐng)域，若干功能規范，各不相同的開(kāi)發(fā)過(guò)程、術(shù)語(yǔ)學(xué)和文檔格式。你可以通過(guò)建立清晰的領(lǐng)導層以及將多種應用歸類(lèi)為模式化的單元來(lái)減輕系統的復雜性。在下面兩個(gè)小節中，我們將會(huì )探求這些技術(shù)手段。 為每一個(gè)關(guān)鍵的項目角色設置一個(gè)領(lǐng)導者： 對于一個(gè)小規模的團隊，在關(guān)鍵角色中設置領(lǐng)導相對容易一些，比如項目經(jīng)理、架構師、系統分析師以及變更經(jīng)理。然而，在大型的BPI項目中往往產(chǎn)生領(lǐng)導層的問(wèn)題。問(wèn)題并不在于在項目層面上沒(méi)有關(guān)鍵人物的領(lǐng)導層，更不在于某個(gè)人試圖領(lǐng)導每一個(gè)角色，而是在于能夠真正掌控項目的人似乎并不是那么明確。 第一種情形出現的原因很容易理解。要想在大型的BPI層面上領(lǐng)導管理，需要具備不同過(guò)程組織結構所涉及到的廣博的知識面，而且還要具備協(xié)調遵循不同過(guò)程工作的各個(gè)團隊的能力。 第二種情形，即兩個(gè)或者更多的人爭當關(guān)鍵位置的領(lǐng)導者，這種情況通常在當兩個(gè)大型的組織機構需要合作開(kāi)發(fā)某個(gè)大規模的集成項目時(shí)發(fā)生。來(lái)自不同組織的領(lǐng)導者們將會(huì )爭奪BPI層面上的領(lǐng)導權。即便你設法通過(guò)協(xié)商來(lái)設立一個(gè)共同的領(lǐng)導層，這也將導致決策速度的延緩。 為了獲得及時(shí)和權威的決定，項目中需要在如下的關(guān)鍵任務(wù)中明確一個(gè)單一的領(lǐng)導者：
這些領(lǐng)導者應當從其它團隊成員出收集信息，但是，最終它們必須作出對整個(gè)項目最有力的權威的決定。 一個(gè)出色的BPI項目領(lǐng)導者究竟都需要具備什么素質(zhì)呢？理論上說(shuō)，關(guān)鍵人物的領(lǐng)導者應當最少具備在該組織結構目前的應用投資組合中三年以上的相應能力的工作經(jīng)驗。這些人熟悉大部分在應用投資組合中有知識有影響的人員，所以他們能夠很快的收集至關(guān)重要的信息，解決潛在的問(wèn)題，以及委派小規模的工作任務(wù)。 我曾經(jīng)在一個(gè)具有上千個(gè)應用的大型的內部IBM項目中工作過(guò)，我們將其分解為15個(gè)功能領(lǐng)域，用粗粒度的業(yè)務(wù)流程加以組織，例如“市場(chǎng)和銷(xiāo)售”和“完成訂制”。盡管每一個(gè)這樣的領(lǐng)域都包含30-400個(gè)應用軟件，但是在那些熟悉每一個(gè)領(lǐng)域里的相應應用的高級項目經(jīng)理和架構師的協(xié)助工作下，我們能夠實(shí)現僅僅處理15個(gè)子系統而不是上千個(gè)應用軟件。 很顯然，期望某個(gè)人理解一個(gè)或者兩個(gè)以上復雜應用的具體細節是不現實(shí)的。一個(gè)大型的BPI項目可能涉及到數十個(gè)甚至數百個(gè)應用。在這種情況下，應該考慮通過(guò)將所有應用按照業(yè)務(wù)流程領(lǐng)域分組來(lái)使項目結構實(shí)現模塊化。舉例來(lái)說(shuō)，你可以將所有有關(guān)財務(wù)的應用或者所有網(wǎng)上貿易的應用歸并在一起。  圖3：應用軟件的非模塊視圖與模塊視圖的對比 在任何應用領(lǐng)域，任命一個(gè)項目經(jīng)理和一個(gè)構架師都代表著(zhù)該領(lǐng)域在項目上的水平。這要求技術(shù)管理者從一個(gè)相對來(lái)說(shuō)粗粒度的水平去考慮一個(gè)復雜的龐大項目系統。 為每個(gè)重要的功能部分建立相應具有代表性的委員會(huì ) 當我在另一個(gè)大型的BPI項目中擔任一個(gè)業(yè)務(wù)流程或集成架構師的工作時(shí)，我負責一個(gè)每周例行的架構方面的相互協(xié)調會(huì )議。盡管我們在這套超級系統中擁有大約10個(gè)大型的子系統，但只有7個(gè)子系統對于每周的構架檢查點(diǎn)具有代表性。 這些需求本身坦白來(lái)說(shuō)一般都不太令人滿(mǎn)意；大多數典型代表都是非常難以修改的，并且常伴有讓人難以忍受的自我沖突和技術(shù)主張。然而，那些沒(méi)有注意這些早期構架需求的項目，最終變得更加令人失望。當我們完成了我們的第一個(gè)開(kāi)發(fā)階段的迭代并且開(kāi)始進(jìn)行集成測試，這些在需求上不具典型性的子系統會(huì )發(fā)現非常大的集成問(wèn)題。 早期的會(huì )議可能太簡(jiǎn)單，令人不滿(mǎn)意，因為你是在事先解決問(wèn)題而不是在事后。那些略過(guò)會(huì )議和爭論的團隊也無(wú)法讓問(wèn)題隨之溜走，他們只是簡(jiǎn)單的把問(wèn)題拖延到了以后。 預先降低項目風(fēng)險最有效的途徑是讓每一個(gè)重要功能規程的小組（項目管理、需求、構架、測試、變更管理和部署）能夠與他們的子系統領(lǐng)導頻繁地協(xié)調溝通。另外，子系統領(lǐng)導應該建立一個(gè)“變更委員會(huì )”以此來(lái)應對跨過(guò)子系統邊界的有規律的對任何改動(dòng)的評論和通過(guò)。 圖4：職能領(lǐng)導和協(xié)調 既然我們已經(jīng)討論過(guò)如何成功地組織一個(gè)項目，現在讓我們來(lái)討論一些更為具體和重要的開(kāi)發(fā)過(guò)程：需求和管理變更。
正如我們先前討論的，需求和變更請求，各自都是BPI項目中最為重要的工件。下面是優(yōu)化這些項目元素的具體技術(shù)。 我強烈推薦在您的項目中遵循一種迭代的部署過(guò)程，這使得您能在大約幾周內了解從概念到系統的運行，而不需要幾個(gè)月甚至幾年。這對于BPI特別重要，因為新的功能性被討論的時(shí)候通常停留在一個(gè)抽象的高水平上，需要來(lái)自不同的涉眾的廣泛的、不同的進(jìn)一步闡釋。早期傳遞大多數新功能的時(shí)候，通過(guò)一系列的迭代，使涉眾能夠看到、接觸到并且對新功能給予反應，這樣一來(lái)，如果有需要的話(huà)，您可以快速的明確和重新定義需求，并且在問(wèn)題比較容易解決的時(shí)候發(fā)現和解決問(wèn)題。 使用迭代方法的另一個(gè)原因是，在BPI項目中用來(lái)集成的子系統實(shí)際上是大型應用軟件或大型應用軟件的集成。傳統的瀑布方法使得子系統集成滯后到生命周期的最后階段，這時(shí)您可能會(huì )發(fā)現高錯誤率并且發(fā)現自己有大量的工作要重做。 如果您使用迭代化方法，比較理想的，您的測試環(huán)境應該能后映射您的成果環(huán)境；最起碼，能夠模擬該環(huán)境。由于它包含了許多應用軟件和潛在的上百臺的服務(wù)器，這項操作的花費可能看起來(lái)被BPI所禁止。但是如果您去考慮在項目上的大量的重復工作的開(kāi)銷(xiāo)與預先在大型測試環(huán)境上的投資做一個(gè)對比，我相信您會(huì )選擇后者。 警告：迭代化開(kāi)發(fā)使得您能很容易的向現有架構中簡(jiǎn)單的添加功能，但是同時(shí)也使得您想要改變主要架構變得更加困難。如果您想要在大型的超級系統中做一個(gè)基本架構的修改，例如，用一個(gè)SAP部署來(lái)代替自產(chǎn)的ERP系統，您將會(huì )被引誘到一個(gè)給您帶來(lái)沉重打擊的道路上。但是，您可以使用另一種更加明智的迭代化方法,即便您想要對主要架構做一些修改。再來(lái)看SAP的例子，您可以通過(guò)一系列的版本從自定義的應用軟件向SAP發(fā)展改變其功能性，通常利用開(kāi)啟越來(lái)越多地SAP自帶功能來(lái)實(shí)現。 每個(gè)涉眾組只允許一個(gè)代表去提交需求和更改需求。 在大型的項目中，成百上千的工人會(huì )直接或間接地參與到項目的執行中。如果任何與項目有關(guān)的人都能夠提交新的需求和/或變更需求，那項目會(huì )很快地陷入一片混亂并失去控制。相反，最好的辦法是讓每個(gè)涉眾組正確地任命一個(gè)代表，代表全組來(lái)負責提交需求和更改需求。 一個(gè)涉眾工作組是有什么人組成的呢？理想狀態(tài)下，小組應該包含與你在概念階段建立項目視圖時(shí)所定義的機制相同。 對于一個(gè)大型的BPI項目來(lái)說(shuō)，擁有多個(gè)涉眾是很平常的。在一個(gè)典型的供應鏈集成項目中，例如，行銷(xiāo)，出售，實(shí)行，以及財務(wù)都屬于涉眾。每個(gè)組都需要一個(gè)明確的代表來(lái)提交和改變需求。 未來(lái)的用戶(hù)包含通過(guò)系統（例如通過(guò)網(wǎng)絡(luò )或是電話(huà)接口）與您的公司有直接交互的顧客和商業(yè)合作者和那些利用系統來(lái)完成工作的雇員。這些用戶(hù)是典型的公司代理（比如顧客維護組織），因為管理與成百的或是上千的實(shí)際用戶(hù)、商業(yè)伙伴和雇員交互是不可能的。 BPI項目的開(kāi)發(fā)團隊實(shí)際上是一個(gè)擁有很多團隊的團隊，每個(gè)團隊負責超級系統中的一個(gè)大型的子系統。由于一個(gè)大型的BPI項目可能包含十幾個(gè)甚至上百的應用軟件，這如我們前面所討論的，這些子系統實(shí)際成為一個(gè)對商業(yè)過(guò)程領(lǐng)域軟件的收集者。接下來(lái)，每個(gè)子系統的開(kāi)發(fā)團隊的代表可以向申明獨立性和計劃變更需求的變更委員會(huì )去提交系統需求，并在以后的開(kāi)發(fā)過(guò)程中修改這些需求。 巧妙的響應一個(gè)變更需求，您需要首先了解變更的原因。盡管這些原因可能無(wú)窮無(wú)盡，但是，只有一小部分正當理由能夠證明系統需要變更。
商業(yè)外部環(huán)境的變更。這種變化會(huì )帶來(lái)一系列廣泛的影響，從指示一些瑣碎細節的變更到更新整個(gè)陳舊的項目。例如，在2004年，IBM有許多項目想要去提升PC生意。公司宣布完全停止這些項目并將其賣(mài)給聯(lián)想，同時(shí)把商業(yè)焦點(diǎn)轉移到整頓上的工作上。 總體來(lái)說(shuō)，那些特許的和投資的商業(yè)涉眾應該向項目團隊來(lái)宣布在外部商業(yè)環(huán)境中的變更。最終，他們將是改變項目范圍的決策者，他們同架構領(lǐng)導者和項目管理者一同決定如何去響應這個(gè)改變。假設這個(gè)項目還存在，BPI級別的項目管理者同各自子系統的管理者一起去指定隨后的計劃并構思設計適合于商業(yè)改變的相應改動(dòng)。 商業(yè)問(wèn)題的錯誤理解。團隊在一開(kāi)始對商業(yè)問(wèn)題有一個(gè)不太正確的理解幾乎是個(gè)不可避免的問(wèn)題。然而，隨著(zhù)項目從概念進(jìn)展到原型再到運行系統，業(yè)務(wù)和開(kāi)發(fā)團隊對業(yè)務(wù)問(wèn)題的理解應當會(huì )逐漸從模糊走向具體。熟練的開(kāi)發(fā)團隊使用技術(shù)去盡早的獲得清楚地認識，其中包括原型和更少的反復過(guò)程。當他們發(fā)現錯誤理解商業(yè)問(wèn)題所帶來(lái)的問(wèn)題時(shí)，架構領(lǐng)導者將會(huì )同商業(yè)涉眾更新設計方案，這些改變將會(huì )影響到一個(gè)或多個(gè)子系統。 方案中的技術(shù)性瑕疵。技術(shù)上的瑕疵與其他合法的可變驅動(dòng)是不同的，因為它與商業(yè)領(lǐng)域毫無(wú)關(guān)系；典型的，它是由開(kāi)發(fā)團隊提出的而非商業(yè)團隊。技術(shù)上的瑕疵在子系統的邊緣更為盛行，問(wèn)題更多。一個(gè)團隊可能意識到它的子系統需要一個(gè)來(lái)自上層子系統的額外的數據元素，這樣它才能夠運行正確。這些變更應該在變更委員會(huì )之前被子系統的代表提出來(lái)。唯一的例外是如果設計上的瑕疵完全在一個(gè)子系統中，那么子系統的團隊可以獨自控制該變更。我們將會(huì )在下面仔細討論這個(gè)問(wèn)題。 一個(gè)集中式的、高水準的BPI項目領(lǐng)導團隊的底線(xiàn)是當你在項目的精心制作和建造過(guò)程中進(jìn)入到細節的工作時(shí)，能夠比較容易的形成一個(gè)瓶頸。如果每個(gè)需求和需求變更，不論它多小，都必須通過(guò)變更委員會(huì )，那么，進(jìn)步不是很慢就是緩緩前進(jìn)，要不就是在創(chuàng )新的道路上迂回不前。與控制每個(gè)細節（需求和設計）方面相比，領(lǐng)導組把具體的活動(dòng)放到稍低的層次顯得更加合理。 由外部商業(yè)環(huán)境（參見(jiàn)前面的章節）所引起的改變應該通過(guò)變更委員會(huì )，因為架構領(lǐng)導者必須要決定如何在超級系統中實(shí)現變更。然而，設計上的瑕疵帶來(lái)的變更則不需要再通過(guò)變更委員會(huì )。 需要變更兩個(gè)或多個(gè)子系統的修改應該需要通過(guò)變更委員會(huì )來(lái)確定每個(gè)部分都達成一致意見(jiàn)。然而，如果需求或是變更需要在一個(gè)子系統的局部，該子系統可以獨立操作變更。他們在這個(gè)領(lǐng)域是無(wú)可厚非的專(zhuān)家，能夠精確并快速地處理變更；請示變更委員會(huì )并沒(méi)有帶來(lái)更多的優(yōu)勢反而降低了解決問(wèn)題的效率。只有在變更會(huì )嚴重影響子系統進(jìn)度，進(jìn)一步影響超級系統進(jìn)度的時(shí)候才有必要在局部工作中使用變更委員會(huì )。 BPI項目團隊在緊張的工作安排中可能會(huì )感到他們需要求助于手動(dòng)工作區來(lái)避免復雜的軟件設計問(wèn)題。手動(dòng)工作區有兩種類(lèi)型：一次性的變更和正在進(jìn)行的程序步驟。 我的工作成功地實(shí)現一個(gè)一次性的工作區。該項目的一個(gè)主要需求是將一個(gè)顧客的CRM應用軟件改為一個(gè)賣(mài)家的CRM包。這包括定制一個(gè)與現有性能和移植后的客戶(hù)數據庫相匹配的CRM應用軟件包。在構建階段的過(guò)程中，開(kāi)發(fā)人員們發(fā)現他們忽略了移植一個(gè)包含一些對整個(gè)商業(yè)數據非常重要的小型客戶(hù)數據庫的需要。他們認識到通過(guò)寫(xiě)腳本來(lái)移植會(huì )破壞工作表。這一發(fā)現帶來(lái)了恐慌。然而，最后大家提出，由于數據庫比較小，可以雇傭一組臨時(shí)工作者利用一周的時(shí)間手工向新系統中輸入數據來(lái)代替書(shū)寫(xiě)復雜的腳本。這個(gè)解決方法實(shí)行了，數據移植的開(kāi)銷(xiāo)相對降低了，并且沒(méi)有打亂項目的工作安排和預算。 類(lèi)似這樣的一次性的工作區可能更傾向于開(kāi)發(fā)只使用一次的軟件（除非軟件在一個(gè)龐大的數據集上操作）。 暫時(shí)性手工工作區的吸引力更小，它將成為日常操作的一部分。執行這樣的一個(gè)工作區開(kāi)銷(xiāo)通常很大（必須雇用人去執行這個(gè)工作），如果它被完全替換，它將需要很長(cháng)時(shí)間轉化成永久的IT解決辦法。作為一個(gè)商業(yè)業(yè)主，當你被建議使用一個(gè)暫時(shí)性的手工工作區時(shí)，一定要確定在一個(gè)將來(lái)的版本中您能獲得一個(gè)永久的IT解決辦法，并且相應的風(fēng)險比較小。
在這篇文章中，我們討論了一些關(guān)于BPI項目的獨特特點(diǎn)和問(wèn)題。接著(zhù)，我描述了一些解決此類(lèi)問(wèn)題的基本規則和技術(shù)。進(jìn)一步，我們希望能夠看到越來(lái)越多的大型集成項目，因此學(xué)習如何正面的面對這些問(wèn)題并有效地解決它們變得非常重要。能完成這項工作的團隊會(huì )創(chuàng )造出更加實(shí)用的系統，并使得他們的組織在市場(chǎ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ò)程中的耐心指導和 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, 20th 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.
1查看IBM的Sam Palmisano關(guān)于商業(yè)需求的定義http://www-5.ibm.com/e-business/za/about_ondemand/def.html 2文中提到UML部分的完整定義見(jiàn) James Rumbaugh, Ivar Jacobson,和 Grady Booch 的 Unified Modeling Language Reference Manual，第二版， Addison-Wesley Professional, 2004。 3即使一個(gè)新應用軟件也不可能將完全嶄新的功能引入到超級系統中來(lái)。 4 Kurt Bittner 和 Ian Spence， Use Case Modeling。Addison-Wesley Professional， 2002。
| |||||||||||||||||||||||
聯(lián)系客服
