使用Rational Method Composer賦予ITIL可執行性（1）

Corby James, Chief Technologist and Principal, Noblestar

2006 年 3 月 15 日

本文來自于 Rational Edge：這篇文章探討了信息技術基礎結構庫(ITIL)，可執行過程，以及IBM Rational Method Composer可以怎樣被組合起來以從健壯，加強的過程中獲得最大的價值。

如果本文的標題引起了你的注意，那么可能是因為你對以下：ITIL，可執行過程，以及新的IBM Rational Method Composer三者中的一或多個感興趣。所有這些都是值得進一步研究的重大主題。在本文中，我將就這些主題給出足夠信息，使你在下次用戶會議上可以與人交流，但是當然，這對使你在任意一個領域中掌握豐富的技術是不夠的。我想要說明的是，這些概念可以怎樣進行組合，使得你能從它們中獲得價值。

什么是ITIL？

對Rational Edge的長期讀者來說，你可能習慣于見到關于Rational Unified Process (RUP)，eXtreme Programming (XP)以及項目管理知識體(PMBOK)的文章。但是ITIL究竟是什么呢？

ITIL表示信息技術基礎結構庫，它被認為是IT服務管理(ITSM)最佳實踐的全球標準。雖然像RUP，XP等開發方式是針對軟件開發領域的，ITIL卻是面向整個IT操作領域的。它于二十世紀八十年代中期在英國建立，建立者是政府商業辦公室(OGC)，目的是作為一種向應用程序和基礎結構管理引入一些嚴格性和統一性的方式。

ITIL是以一套7冊的書的形式發布的，這些書介紹了：

服務支持
服務提供
計劃實現服務管理
ICT基礎結構管理
應用程序管理
安全性管理
商業前景
盡管每一本書都提供了寶貴的見解，大多數沒有接觸過ITIL的公司卻更傾向于學習服務發布和服務支持。服務發布可分解為以下領域：

可用性管理描述了如何定義應用程序和基礎結構的最大失效時間和平均失效時間。它主要研究服務能力，恢復能力，可靠性等等概念。
能力管理描述了如何確定基于定義的服務水平有足夠和適當的資源。
連續性管理涉及的是管理錯誤恢復和掉電的實踐。
金融管理包括了如何計算基礎結構成本和最優化成本的實踐。
服務水平管理既考慮了面向用戶的確定時間上限的實踐，也考慮到了幫助用戶理解支持成本與服務水平之間的平衡的實踐。
服務支持包含如下方面：

配置管理在這一上下文中指的是，明確和控制基礎結構類型的資產或配置項(CIs)。因此在軟件配置管理處理控制代碼，模型元素，等等的地方，ITIL CIs可以充當硬件，中間件，終端用戶應用程序，等等。
變更管理描述了配置項的變化應如何發生。其描述的活動與標準軟件變更管理的活動有很多重疊。
意外管理細化了非正常操作過程的元素應如何被處理。它包括對意外的分類，這樣就可以通過設置優先級順序來決定如何對意外做出應對。
問題管理與意外管理是相關的，因為意外經常是由問題，錯誤，缺陷，等等造成的。問題管理描述了這些類型的事件是怎樣通過Requests For Change (RFC)獲得處理和解決的。
發布管理描述了將軟件項引入到操作環境中的實踐。它描述了活動的實現和發布。
服務臺描述了通過集中式能力管理意外和問題的實踐。它主要處理像服務類別和意外解決的知識基礎這樣的關鍵項目。
ITIL的商業案例

如果一個組織認識到三個商業相關的需要，則ITIL的采用通常是更為有效的。

首先，很多組織在尋找導致基礎結構成本容量的操作效率。如果現在我們退后一步評估典型的IT預算，我們經常發現它是由一些離散和非離散的塊組成的。離散的支出是那些用于開發新功能以提高競爭優勢的支出。非離散預算則覆蓋了維持現有水平的支出。Gartner的一項調查顯示，中等IT企業大約將其75%到80%的預算放在非離散支出上。經驗表明，如果組織采用的操作包含嚴格的服務管理過程，非離散支出的將近10%到20%可被重定位為離散資金。

其次，上述的實體尋找ITIL實踐來降低商業持續性風險。一個近期的客戶將從一個供應商處獲得的大規模應用程序重新加工。通過這種方式，他們采用RUP和Rational工具來輔助對應用程序開發的復雜度管理。當他們開始過渡活動時，由于操作支持不足，他們很快遇到了重大風險，幾乎導致所有的努力失敗。從那時起，他們就開始把ITIL作為在未來減輕這些風險的一種方式。

第三，在一些我曾經工作過的公司中，由于IT部門無法實現基本服務水平，終端用戶驅動了ITIL的采用。讓我們面對這個事實，在一段時間里IT業在很多商業用戶中反響很糟糕。我們無法發布，我們花了太長時間或太多錢，而當我們完全發布了應用程序，對性能或支持的期望卻沒有被實現。我們的一些客戶的商業團體轉向ITIL以求解決這些問題，因為它提供了一組一致的實踐并觸及了一些操作組織從未考慮過的領域。

ITIL的采用

十年前ITIL就在歐洲被廣泛采用，但是直到最近才在美國開始被采用。盡管ITIL的優勢不斷顯現出來，在很多美國IT專家眼里它仍處于“需要檢測和考驗”的狀態。Gartner 2004年的一項調查顯示，58%的被調查人員（CIO，IT操作領導，以及數據中心管理員）對ITIL幾乎一無所知。在與一個大金融服務客戶的合作中，我第一次真正接觸到了ITIL。作為一個負責過程采納的團隊領導，我被要求協助RUP過渡活動，使其順利完成，以及ITIL 發布管理。那時我意識到了ITIL的成功采用的一個基本障礙。

為了幫助IT領導者從市場上的各種過程中獲得價值，我開發了一個商業過程分類策略，該策略是基于企業可應用，且企業采用其的復雜度可以接受的商業過程的。圖1顯示了這一分析的示例。

接下來，我為過程定義了一個分類策略，把它們分為四類：

最佳實踐。對具體任務或明智選擇的陳述，如果你是某的特定領域的從業人員。ITIL，PMBOK和CMMI屬于這類。
評估，度量，和審核。這些過程通常為某個領域內的組織評估提供成熟度模型。它們在這一度量下陳述最佳實踐。CMMI同樣符合這一類，來自項目管理 研究院(PMI)的組織項目管理成熟度模型(OPM3)也符合該類。
過程改進。這些集合的活動幫助你分析過程并找到優化它們的效率的方法。這一類的例子包括Six Sigma和Lean。
可執行過程。這一過程不僅就公司應該采取何種類型的實踐提供了完整的陳述，還描述了哪些人應該參與實踐，他們應該生產什么，工作流和工作流依賴性，以及時間線目標的具體生存周期。RUP是可執行過程的最好例子。
區分這四種過程類型是很關鍵的，因為在本文中我們的重點是可執行過程，對比其它三種類型的過程它更容易實現并為組織提供了更大價值。

另一個區別是項目相關的過程與操作性過程間的不同。根據PMI，項目是基于目標的，并有清楚的起點和終點（盡管我曾參與的一些項目看起來永遠不會結束，但是本文不討論這點）。操作性過程是那些不斷進行，并且在本質上就是持續性的過程。RUP是一個項目相關過程的例子；而ITIL是一個操作性過程的例子。我們將看到，這是一個重要區別，因為這意味著我們必須建立與現有的生存周期模型，比如，RUP生存周期模型，不同的生存周期概念。

當一個組織引進了一組最佳實踐，如ITIL，并提供了一個采用要求，它將面對若干挑戰，這些挑戰至少是與可執行過程相關的。我們必須解釋一下非可執行過程。例如，在工作流還沒有被定義時，采用者必須從實踐集里導出工作流。這需要對實踐的廣泛分析來確定組織或角色依賴性，工件所有權，管理方法，等等。就內容和模板及報告的格式發生大規模辯論也不足為奇。我曾見過這種分析持續幾個星期，甚至幾個月，但仍然得不出令人滿意的輸出。最后，過程采用意味著組織變化。成功的一個關鍵因素是能夠清楚地為受到新過程影響的人定義：

它們起到什么作用。
它們被希望擁有哪些技能和競爭力。
對某個作用來說，任務是什么。
它們需要對哪些工件負責，為什么。
它們如何作為一個整體與其它整體協作。
它們如何知道它們是否成功。
可執行過程需要很長時間來解答這些問題。RUP提供了一個關鍵元素：過程調整指導。過程被原封不動地采用，沒有提供任何針對不同的項目復雜性或團隊技術水平的靈活性；這種現象太常見了。

可執行ITIL

怎樣才能使一個過程是可執行的呢？首先，它需要包含關鍵元素，如圖2所示。

圖2：RUP組件

圖2顯示了RUP中隱含的過程元模型。這一方法是基于對象管理組(OMG)的，稱為軟件過程工程元模型(SPEM)。它提供了對使用統一建模語言(UML)的過程的各個方面的完整覆蓋。要使ITIL成為可執行的，這些元素必須被明確和記錄為文檔。此外，相互關系和依賴性也必須被確定，這樣，最終，一個工作分解結構(WBS)可以被產生。

完成這一工作的步驟是相當直接明顯的，盡管如此，工作量卻不小。我們用來建立ITIL文檔的工作流如下：

定義過程的最高級分解。這有助于組織工作和管理依賴性。這些過程“桶”被轉化為規范。
明確角色和角色群如果你熟悉RUP，你就會知道一個角色群，比如分析員，包括了系統分析和需求細化兩個功能。
確定工件或工作產品。這是過程執行的確實的輸入/輸出，可以是從文檔到一個工具中的配置設置中的任何東西。
明確任務。我們遵從一種與用例分析相似的方法，在該方法中我們按照作用尋找任務，然后作為精化步驟，評估任務的通用性。記住，任務（RUP活動）分解為步驟，而作為常規指導，我們試圖使所有活動的步驟保持在大約10個以下。
定義已導出元素間的關系。我們把角色作為基本單元，并在初始時把所有關系與它們進行關聯。接著，我們將在領域內評估元素間的關系（比如，角色與其他角色的關系，工件與其它工件的關系，等等）。
創造工作流。工作流是任務的匯合，它定義順序和同步（哪些任務可以并行進行，哪些不行），以及依賴性。在某些情況下，這一步驟可以在步驟4前完成，但是正如我們在Rational新的為過程建模的方法中可以看到的，現在的順序要相對好一些。
收集指導，清單，工具指南，等等。這些元素將為過程采用，使用，和管理提供便利。
結果具體分析。在過去，我們使用Rational Process Workbench (RPW)來產生對RUP的修改?，F在我們用Rational Method Composer取而代之。下面我們將介紹這一工具。
IBM Rational Method Composer

如果你已經使用了Rational過程空間一段時間并曾嘗試定制化RUP，你可能會熟悉Rational Process Workbench (RPW)。它是一個基于Rational Extended Development Environment (XDE)的過程管理工具。盡管它是一個強大的工具，很多人覺得它很難使用。那么試試Rational Method Composer (RMC)，它與RPW是完全不同的。

首先，RMC的規模比RUP大。在包含了RUP內容庫的同時，用戶還可以使用RMC創造或定制化任何過程。其次，和IBM Rational的許多新產品一樣，它是基于Eclipse的，這意味著它擁有工業標準的外觀和感覺。最后，對沒有建模背景的用戶來說，RMC更容易使用。你還是需要掌握分析技術，最好也有項目管理背景，但是你不需要是UML專家來使用這個工具。

方法：RMC基礎

對RMC的完整介紹超出了本文的范圍，但是在這里我們可以建立一些基本概念。[編者注：如果需要關于RMC的詳細介紹，參見文章“IBM Rational Method Composer：關鍵概念和情境“，也在2006年1月刊中。]

RMC通過方法進行交換。方法是對能夠完成的工作以及工作的完成順序的定義。為了創造一個方法，你必須定義方法內容（何人，何事，何種方法）和過程（何時），但是這些是分離的元素，如圖3所示。這里的關鍵概念是，當你研究過程的現實實現時，對不同項目和公司來說，同性的東西是工件和角色。非共性的是，角色如何共同工作，或者他們應該使用哪些工件。RMC試圖通過這一定義最優化可使用性并降低定制化的難度。當我們使用RMC來使ITIL可執行時，我們將從定義方法內容開始，然后定義過程元素。

圖3：IBM Rational Method Composer使你能夠通過定義方法內容及其過程創造方法

RMC提供了支持方法擴展和定制化的機制。在RPW一般不能用以在組織級上對RUP進行修改的情況下，RMC能夠支持項目級的變化，并且實際上還提升了過程管理的水平。對項目經理和管理人員來說，這是不可多得的！這意味著你的工作分解結構和過程定義通過工具取得了同步，并可以通過方法庫控制。

組合

到目前為止，你對ITIL，可執行過程，以及RMC有了一個基本的了解。你還應該向你的詞匯表中加入了至少十個三字母縮寫詞(TLA)——這些縮寫詞對豐富你的履歷表是很重要的?，F在讓我們來看看Noblestar是如何使用RMC來使ITIL可執行的。

我們的任務是幫助一個客戶使他們的軟件工程和IT操作領域變得嚴格。在這一任務中過程工程起到了重要作用，并基本形成了本文的基礎。

按照我們的工作流，我們的第一步是如何分解ITIL以使任務不那么龐大驚人。明顯的選擇是按照“ITIL是什么？”一節中討論的ITIL規范進行分解。正如有分析和設計，實現，測試，等等的RUP規范，ITIL規范同樣包括可用性管理, 服務水平管理，等等。這些成為我們的RMC中的ITIL方法內容的建立基礎。

我們采用一種迭代的方法來開發內容，并且，基于客戶需要，我們從變更管理開始。一個提醒：在建立了一個孤立的ITIL變更管理版本后，團隊感到我們實際上可以更多地利用RUP配置和變更管理，而且現在團隊已經開始建立組合二者的插件。我們已經準備好開始用角色，工作產品和任務建立包。

原文轉自：http://www.anti-gravitydesign.com