本稿では、ITIL® に準拠する中核部分を表す変更管理プロセスおよび構成管理プロセスのベスト・プラクティスの概要を示すとともに、それらのプロセスがサービス・プロバイダー・ドメインにどのように拡張されるかを説明します。それらのカスタマイズ可能なプロセスは、実行プラットフォームおよび構成管理データベースと結合されて、IBM Tivoli® Change and Configuration Management Database (CCMDB) の根幹を形成します。CCMDB は、IT サービス・マネジメント (ITSM) のための IBM の戦略の中心となるものです。ここでは、ITSM のベスト・プラクティスの概要を示すとともに、CCMDB 製品用に IBM が開発したベスト・プラクティス・プロセスの詳細を示します。また、これらのプロセスの実装から得られた多くの知見について説明するとともに、サービス･プロバイダー環境でこれらのプロセスを実装するための鍵となる課題についても説明します。
情報技術 (IT) サービスは、ほとんどすべての企業にとって不可欠なものとなっています。さらに、競争の激しいビジネス環境が、効率的で費用対効果の良い IT サービスのデリバリーやサポートを決定づけています。IT 環境の複雑さ、多様性、分散型の性質が相まって、IT サービスを管理するための共通のベスト・プラクティス手順が不可欠であることは明らかです。IT Infrastructure Library** (ITIL**) 1 は、多くの業界リーダーからの情報提供により United Kingdom Office of Government Commerce が開発した IT サービス・マネジメント (ITSM) のフレームワークです。ITIL は、企業の IT を管理するための事実上の標準として認識されています。また、ITIL の規格への適合は、IT サービスを外部委託する顧客にとって重要となってきています。ITIL の価値は、サービス管理のための手引きと共通の専門用語を提供することにあります。しかし、ITIL は実装について規定するものではなく、特にサービス・プロバイダーの観点から (つまり、他の企業のために IT を管理することを事業にしている企業の観点から)、ITSM に対応しているわけでもありません。
IBM Server Systems Operations チームは、IBM Research と連携して、変更および構成管理サービス業務のための一連のベスト・プラクティス・プロセスを開発しました。続いて、IBM Server Systems Operations と IBM Research はこの研究の成果を利用して、IBM Tivoli* との連携により、IBM Tivoli Change and Configuration Management Database (CCMDB) に基づく構成管理および変更管理のためのプロセス・ソリューションを開発しました。
本稿は、大きく分けて以下の 5 つのセクションから構成されています。『業界のベスト・プラクティスと状況』のセクションでは、変更および構成管理の分野の ITSM のベスト・プラクティスの概要を示すとともに、これらのベスト・プラクティスをより幅広いエリアに適用しています。『変更管理プロセスと構成管理プロセスの統合』のセクションでは、IBM が開発した、CCMDB 製品に基づくベスト・プラクティス・ベースの変更および構成管理プロセスの詳細を示します。『構成管理の洞察』のセクションと『変更管理の洞察』のセクションでは、これらのプロセスを実行することによって得られた洞察について説明しています。最後に、『サービス・プロバイダーの観点』のセクションでは、変更管理プロセスおよび構成管理プロセスをサービス・プロバイダー環境で実現するための鍵となる課題に焦点を置いています。
ITIL は、もともと 1980 年代後半に英国政府が開発したもので、IT のサービスおよびシステム管理のためのプロセス・ベースのベスト・プラクティスの集合の概要を示す一連の出版物で構成され、その数は増加し続けています。ITIL の原則に基づく、英国規格協会からの「A Code of Practice for IT Service Management」2 では、資産および構成管理と変更管理を、その他すべての ITIL サービスのサポートとサービスのデリバリーに対応する中核的制御プロセスとして表しています。ITIL によると、サービス・デリバリー (サービス・レベル、財務、可用性、キャパシティー、および IT サービス継続性管理を含む) がビジネスのサポートに必要な IT サービスを提供し、サービス・サポート (インシデント、問題管理、変更管理、リリース管理、 およびサービス・デスクを含む) が顧客にそれらの IT サービスにアクセスできるよう保証します。ITIL の概念は、英国規格 BS 15000-2 (ISO 20000に移行) に基づく国際標準化機構 (ISO) の規格 ISO 20000 3 に貢献しています。英国規格協会と Central Computer and Telecommunications Agency of the United Kingdom Office of Government Commerce はともに、構成管理と変更管理を ITSM の要として認識しています。
ITIL 変更管理および構成管理のベスト・プラクティス
構成管理の目標は、IT 環境の包括的かつ正確な論理表現を維持することにあります。構成管理データベース (CMDB) として知られるこのオンライン表現には、IT 環境の各コンポーネント (ハードウェア、ソフトウェア、文書、サービス、ユーザーなど) が含まれます。これらのコンポーネントは、別々に管理する必要があるとともに、それぞれの関係を管理する必要があります。これらのコンポーネントは、構成アイテム (CI) として知られています。CMDB は、単なる構成情報のリポジトリーではありません。Gartner, Inc.4 によると、CMDB の特徴はリコンシリエーション (整合化)、フェデレーション (連合)、マッピング、可視化、および同期のための機能を備えていることです。
構成管理は資産管理に関係していますが、この 2 つの管理は同一のものではありません。資産と CI は相互に重なり合う部分がある集合ですが、いずれも、もう一方の真部分集合にはなっていません。さらに、資産管理は主に会計に対応したものであり、通常、構成管理のようにアイテム間の関係を考慮しません。多くの場合、組織は、構成管理を実装する前に、資産管理システムを実装することから始めます。
構成管理は、変更管理と連携して CMDB を維持します。IT 環境においては、変更が絶え間なく、ほとんどの変更はその環境の修復または改善を目的としたものですが、予期しない、コストのかかる、好ましくない影響を及ぼすことがよくあります。変更管理の目標は、変更要求 (RFC) を必要とし、変更を承認する前にその影響を評価することによって、このような悪影響を最小限に抑えることにあります。
ITIL とそれ以外のモデル
ITIL とそれに関連するさまざまな規格 (ISO/ IEC 20000 および BS 15000) は広範な支持を得ていますが、プロセス改善フレームワークを反映するモデルは他にもあります。特に注目すべきものとして、Component Business Model for the Business of IT (CBMBoIT) 5 があります。CBMBoIT は、最高情報責任者 (CIO) の観点から IT ビジネスを管理するためのモデルを提供します。CBMBoIT では、作成者がフレームワーク内の各コンポーネントに固有のアクティビティーを定義して、必要な場合にアクティビティー・レベルまでプロセスを分解できるようにしています。プロセス・アクティビティーは、IBM Process Reference Model for IT (PRM-IT) 5 という完全な参照モデルの表現に必要な拡張を行った、事実上の IT プロセス標準に従っています。大きな支持を得ているもう 1 つのプロセス改善フレームワークとして Capability Maturity Model Integration (CMMI) 6,7 があります。CMMI は、IT インフラストラクチャー内のすべての領域を対象とする CBMBoIT や ITIL の表現および開発とは対照的に、継続的な改善による完全なソフトウェア成熟度プロセスに重点を置いています。さらに、IT プロセスのモデリングのもう 1 つの考え方は、Information Systems Audit and Control Association (ISACA) が作成した Control Objectives for Information and Related Technology (COBIT**) 8,9 に基づく考え方です。COBIT は、IT 管理用に一般的に認められた一連の方法、指標、プロセス、およびベスト・プラクティスを提供します。これらの多様なプロセス改善フレームワークは、参考文献 12 に表されている ITIL 変革プロジェクトの 4 つの事例研究の経験をもとに比較批評 10,11 されています。
構成管理および変更管理の説明だけに絞り込むと、直接的に関係する多数の関連トピックがあります。構成管理においては、ソフトウェア開発のライフ・サイクルのためのソフトウェア構成を構成する要素と関係の管理に焦点を置いたソフトウェア構成管理 13、アーキテクチャー 14、CMDB のコンテンツの決定 15、CMDB 内のポリシー 17 および規則の指示、式、および表現を含むワークフロー・コレオグラフィー・インフラストラクチャー 16 があります。
変更管理のトピックには、動的変更管理に対応するよく認識されている課題 18 、計画およびスケジュール化による変更管理 (CHAMPS) 19 と同様に動的システム管理による統合、および変更管理を行うための契約の使用 20 があります。
他のプロセス・ドメインと同様に、構成管理プロセスおよび変更管理プロセスが Sarbanes-Oxley Act 21 などのさまざまな準拠および監査要件を遵守し、サポートすることが不可欠です。また、構成管理プロセスおよび変更管理プロセスのドメインは、たとえば、サービス指向アーキテクチャー (SOA) 22,23 を使用して他のプロセス・ドメインとやり取りする共通の方法を提供する必要があり、オートノミック・エレメント 24 を使用できるようにする必要があります。規格という観点からのこれらのプロセスの表現は、参考文献 25 に示されています。
変更管理と構成管理は、共存関係にあります。変更管理が要求された変更の影響を正しく評価するためには、CMDB 内の情報が構成管理によって維持される必要があります。構成管理は、CMDB を正しく更新できるようにするために、実施された変更に関する情報を変更管理から得ています。ITIL Service Support (図 1) で変更管理と構成管理は別々に記述されているのは、歴史的に、いくつかの組織が完全な構成管理プロセスをサポートすることなしに変更管理を実装していたからです。しかし、ITIL には、「理想としては、変更管理は、構成管理システムの不可欠な部分として考える必要があります」26 と記述されています。
IBM Tivoli Unified Process
IBM Tivoli Unified Process (ITUP) 27 は ITSM に対する規範的なアプローチであり、ITIL のベスト・プラクティスと整合が取れています。ITUP は ITSM を実現する方法の概要を示すとともに、変更および構成管理のプロセス内のトップレベルの変更管理アクティビティーと構成管理アクティビティーを公開する図を提供しています。ITIL に記述されている内容を超える新たな役割が取り入れられるようになっています。変更管理において、変更の受託者、変更の承認者、および変更の実装者は、変更マネージャーの下位の代理人です。同様に、構成管理において、構成の監査者は、構成マネージャーの下位の代行者です。また、ITUP では、それぞれのアクティビティーに適用可能な IBM Tivoli サービス管理プラットフォームおよび運用管理製品 (OMP) を表しています。
モデリングの方法
構成管理および変更管理の主なアクティビティーのためのプロセスは、以降のセクションで説明します。これらのプロセスは IBM WebSphere* Process Modeler Advanced Version 6.0 によってモデル化されたもので、図 2 ではそれらのモデルの凡例を示しています。もともと、これらのプロセスは、IBM WebSphere Integration Developer 6.0 を使用して、Web Services Business Process Execution Language (WS-BPEL) によって CCMDB で実現されたものです。
構成管理
構成管理には、CI の識別、CI の制御、CI の検証と監査などがあります。また、構成ステータスのレポート機能も含まれています。
CI の識別
CI の識別プロセスは、必要に応じてその環境内の CI を発見し、CMDB を更新するのに使用されます (図 3A)。(このプロセスのための ITIL Version 2 の焦点は、インフラストラクチャー内に CI タイプのクラスを確立することにあります。これは、最初に CMDB へデータを投入するときに、または CMDB に含める必要がある新しいタイプの CI が識別されたときに行われる可能性があります)。この発見は、手作業による検査または自動化されたスキャン・ツールによって行われます。収集されたデータは、フィルター処理され、マッピングされ、正規化されて、整合化されます。この時点になってようやく、データを CMDB の内容と比較して、修正できる状態になります。つまり、識別された差異を修正できるようになります (図 3B)。
図 1. サービス・サポート・プロセスと成果物
拡大図
CMDB と収集されたデータとの間で差異が生じる理由として、以下のようないくつかの理由が考えられます。環境に対して許可されていない変更 (承認された RFC に関連していない) が行われた場合、タイミング問題が発生した場合 (たとえば、環境に対して許可された変更が行われたが、CMDB がまだ更新されていなかった)、または許可された変更を実行中にエラーが発生した場合などがあります。この差異は、調査して、原因を突き止める必要があります。必要に応じて、さらに調査を進めるためにインシデントをオープンすることも、環境または CMDB を更新するための変更要求 (RFC) をオープンすることもできます。
CI の制御
CI の制御プロセスは、CMDB に対するすべての更新および追加を管理します (図 4A および図 4B)。このプロセスは、変更管理、リリース管理、または他の構成管理プロセスによって呼び出すことができます。ベスト・プラクティスの実施を保証するためには、このレベルの制御が必要となります。CI の制御プロセスは、組織が CI データに制限またはポリシーを適用するように決定した場合に使用することができます。たとえば、特定のタイプの CI について、このプロセスは属性値の妥当性をチェックすることも、いずれかの更新が行われる前に特定の CI のライフ・サイクルの状態に特定の属性が指定されるようにすることもできます。
CI の検証と監査
構成管理プロセスの主な役割は、CMDB がその環境を正確に表すようにするとともに、確立された IT の規格およびポリシーに従うようにすることにあります。これを行うためには、CMDB の内容と IT 環境およびさまざまな規格を定期的に照合する必要があります。これは、CI の検証および監査プロセスで対応します (図 5)。
図 2. 図 3-5 のプロセス・モデルの凡例
拡大図
CI の検証および監査プロセスでは、必要に応じて CI の識別プロセスを呼び出して、環境をスキャンし、発見した CI データと CMDB 内の CI データを照合します。監査プロセスでは、そのほかに、その環境で CMDB 内のどの CI が最近検出されていないかの確認 (「最近」の定義はポリシーによって決定される)、CI の命名規則に従っているかどうかの確認、CI と関連付けられたゴールド・スタンダードを照合して準拠を確認 (ゴールド・スタンダードとは、たとえば、サーバーのような CI のセットを構成する方法に関するモデルまたはテンプレートとしての役割を果たす CI レコードまたは規則のセットのことです)、最終的なハードウェア・ライブラリーおよび最終的なソフトウェア・ライブラリーの内容の正確さのチェック、が実施されます。差異の修正プロセス (図 3B を参照) を使用して、必要に応じてインシデントまたは RFC をオープンすることによって、すべての差異が調査され、解決されます。
構成ステータスのレポート
構成ステータスのレポート機能は、許可されたユーザーが CI 情報を利用できるようにします。この情報には、属性値、他の CI との関係、変更履歴、ライフ・サイクルの状態の履歴、および他のプロセス成果物との関係 (たとえば、RFC) を含めることができます。
変更管理
問題を修正するか環境を改善するかに関わらず、変更の管理は変更管理プロセスの領域です。変更要求 (RFC) は、顧客またはユーザーが変更管理で提供されているインターフェースを使用して作成することができます。また、他のサービス・サポート・プロセス (たとえば、構成管理) は、RFC を作成して、直接実行依頼することができます。実行依頼されると、RFC は、適切な担当者に転送されて、受け入れられ、分類されます。受け入れられると、分類された RFC は、カテゴリー、グループ、タイプ、および優先順位などの RFC の主要な属性に基づいてカスタマイズされたプロセスによって処理されます。
変更要求 (RFC) の処理
RFC 処理プロセスは、変更のライフ・サイクルを管理します。図 6 は、変更を処理するためのベスト・プラクティス・プロセスの例と、そのプロセスを構成する 5 つのステップを示しています。(1) 変更を評価し、(2) 変更を承認し、スケジューリングし、(3) 変更の実装を調整し、(4) 変更を準備、配布、実装し、(5) 変更をレビューして、クローズします。
図示されているプロセスは、急を要さない大きな変更の場合に適しています。急を要する小さな変更は、小さなタスクのサブセットによって効果的に処理することができます。RFC の属性は、その RFC をどのアクティビティーが処理する必要があるかに影響することがあります。たとえば、急を要さない RFC は、一般の RFC とは別に処理されます。どのアクティビティーを含めるかを決定するうえで、変更のその他の属性 (たとえば、顧客) を考慮に入れる場合もあります。たとえば、マルチカスタマー環境では、RFC 処理プロセスで行う必要がある規制要件などの固有のビジネス要件が顧客にある可能性があります。
図 3A. CI の識別プロセスのベスト・プラクティスの例
拡大図
たとえば、リリース管理から恩恵を受ける複雑な変更の場合、変更の実装を調整するアクティビティーと配布の準備と変更を実施するアクティビティーは、リリース管理プロセスを呼び出すことができます。変更全体の制御は、リリース管理を利用した場合でも、変更管理に留まります。
IBM Strategic Outsourcing Services 部門のサービス・オペレーションの側面からのベスト・プラクティスの開発と IBM Tivoli CCMDB 製品のための構成管理プロセスの開発の結果として、我々は、構成管理の分野において多くの洞察を得ました。
許可された表現と実際の表現
構成管理の第一の目的は、すべての ITSM プロセスに正確なデータを必要なときに必要な場所に提供することによって IT サービスのデリバリーを支えることにあります。構成管理プロセスでは、CMDB を利用しています。CMDB は、CI レコードをそのライフ・サイクルに渡り管理するためのデータベースです。CI レコードの変更は、さまざまなソース (たとえば、ディスカバリー・アダプター、ユーザー・インターフェースによる手動入力、アプリケーションからの一括ロード) から発生する可能性があり、そのような変更を制御する必要があります。構成の制御は、許可された識別可能な CI だけを受け取ったときから廃棄まで記録するようにさせることと関係しています。構成管理は、承認された変更要求などの適切な管理文書なしに CI が追加、変更、置換、削除されないようにします。28 CMDB に構成管理が取り入れられたことは、更新を CMDB に取り込む前にその更新のために必要な管理文書が作成されるようにするプロセスが必要であることを示しています。したがって、CMDB のレコードに反映された CI のデータが、ディスカバリー・アダプターなどのツールによって識別される CI の実際のデータと異なる場合があります。
図 3B. CI の識別プロセスの差異を修正するステップのベスト・プラクティスの例
拡大図
我々は、お客様が 2 つのデータのセットを必要としていることがわかりました。お客様は、その許可された環境と実際の環境に対する洞察を管理する必要があります。CMDB がリポジトリーとして、許可されたデータと実際のデータの両方に使用される場合、我々は以下のように定義しています。
- 許可された表現は、変更管理プロセスから呼び出された CI の制御プロセスによって更新されたCI 属性 (そのタイプの属性のサブセット) を表します。これらの属性は、変更管理プロセス内の変更の実装を調整するアクティビティーで反映された変更制御に従って承認されています。この許可された表現は、ITIL が CMDB と呼んでいるものです。
- 実際の表現は、最新のディスカバリー・アダプターのアップロードに基づいて CI 属性 (そのタイプの属性のサブセット) を表します。これらは同じ値を記録する場合も、実際の値が許可された表現と異なる場合もあります。
CMDB が CI の許可された表現と実際の表現の両方を維持している場合、セキュリティー上の配慮が必要になります。これら 2 つの表現とそれらの関係に関するユーザー定義のアクセス・ポリシーについて決定を行う必要があります。
構成ベースライン
顧客は、構成ベースラインを評価しています。構成ベースラインは、CI のセットとその相互関係の特定の瞬間を表すスナップショットです。その環境の一部のサブセットに関するこのような瞬間の記述は、文書化、リカバリー、比較のために役立ちます。ベースラインには名前とタイム・スタンプを付ける必要があり、編集できる状態になっていていけません。サービス・プロバイダーは、新しい顧客との関係が始まる際に、またその後、定期的に構成ベースラインを作成して、顧客の環境の最初の状態を文書化したり、重要なチェックポイントの状態 (たとえば、大きな変更の前) を文書化したり、災害発生時のリカバリーを容易にしたり、時間の経過とともに環境の変化を表示したりすることができます。ベースラインの作成のためのスケジュールは、顧客指定のポリシーで定義することができます。
ゴールド・スタンダード
お客様は、ゴールド・スタンダードに基づいたプロセスのサポートに高い価値を見いだしています。1 つのゴールド・スタンダードと任意の数の CI のセット間の関係を作成して、それらの CI のセットに対するゴールド・スタンダードの適用を可能にすることができます。これらのゴールド・スタンダードは、確立されたポリシーへの準拠を評価するために、構成管理の CI の検証および監査プロセスで使用されます。たとえば、組織は一般的な UNIX** サーバー構成を表す CI レコードのセットを作成して、そのセットをその組織内のその他すべての UNIX サーバーを構成する方法に関するゴールド・スタンダードとして指定する場合が考えられます。次に、この組織は、その環境内の UNIX サーバーの CI レコードとゴールド・スタンダードとの関係を作成することができます。それらの UNIX サーバーに対して CI の検証および監査プロセスが実行されると、ゴールド・スタンダードと関連する CI の間の準拠の相違に関するレポートが生成されます。また、ゴールド・スタンダードを、CI が照合される一連の規則またはポリシーと説明することもできます。
発見による CMDB へのデータの投入
正確な CMDB を維持するためには、発見を通じて実際の (つまり、収集した) データを CMDB 内に取り込む方法とツールが必要です。このアプローチでは、発見したデータを集約し、フィルター処理し、マッピングし、正規化し、整合化し、優先順位付けして、CMDB にロードするまでの体系的な方法を表現する必要があります。これらの手順に関する詳細は、ITSM を支える CMDB アーキテクチャーとの関連で説明されています。 14
修正の重要性
『CI の検証および監査』のセクションで述べたように、修正アクティビティーは、必要な管理文書に従ってCMDB に反映される CI が、設定されている規格と管理対象のリソースの構成を正しく反映するようにする責任があります。その中には、発見された環境と許可された環境の間の差異を認識して、確認された差異を修正することが含まれます。修正 (CI の検証および監査プロセスおよび CI の識別プロセスにおけるアクティビティー) には、識別した差異を訂正する方法を決定することが含まれます。たとえば、誤って構成されたリソースがディスカバリー・アダプターによって識別されると、そのリソースを再構成するための変更要求が生成される可能性があります。逆に、リソースが正しく構成されていても、許可値が誤っている場合は (たとえば、手動入力中のエラーによって)、適切な管理文書に結び付けられた CMDB 内の許可された CI が 変更される可能性があります。通常、CI の検証および監査プロセス内から呼び出された修正アクティビティー (図 3B) は、そのプロセス中に明らかになったエラーを訂正するための 1 つ以上のインシデントまたは変更要求をもたらす可能性があります。
CI のライフ・サイクルの状態の重要性
構成の制御の一環として、CMDB によって管理されるすべての CI にはそれぞれライフ・サイクルの状態が関連付けられます。このライフ・サイクルの状態はプロセスをトラッキングするために使用されるもので、計画策定、意思決定、変更の管理のために最新の状態に保ち、いつでも利用できる状態にしておく必要があります。CI の状態の例として、注文済み、受け取り済み、受け入れテスト中、稼働中、変更中、撤去済み、および廃棄済みがあります。図 7 は、CCMDB のデフォルト構成での正当なライフ・サイクルの状態を示しています。
ライフ・サイクルの状態の遷移は、CI がある状態から別の正当な状態に変わるだけとなるように管理されなければなりません (図 7)。また、ここでも、構成の制御の一環として、ライフ・サイクルの状態遷移時に属性レベルの意味構造の検証のベスト・プラクティスを実施するという考えがあります。ライフ・サイクルの意味構造の検証として以下の 3 つの検証が推奨されます。
図 4A. CI を制御するプロセスのベスト・プラクティスの例:ステップ 1、CI の制御
拡大図
- 特定の CI のタイプについて、特定の状態になるか、またはその状態が終了する前に、選択されたフィールドにデータが取り込まれるようにする必要があることを指定します。
- 保護された状態を変更しようとすると、変更要求 (RFC) が強制的にその状態に関連付けられるように、選択された状態を「保護された」状態として指定します (図 7 で示すように)。この検証機能は、次のセクションで説明するように、他の状態よりも制御を強化する必要があるライフ・サイクルの状態があることを認識します。
- ライフ・サイクルの状態が変更される可能性のある状況に対する制御を強化するために、状態の遷移を可能にする属性を他の属性の変更と分けます。この検証機能では、CI のライフ・サイクルの状態を変更するためにさまざまなアプリケーション・プログラミング・インターフェース (API) やユーザー体験にアクセスできるようにして、ベスト・プラクティスの趣旨に従って CI のライフ・サイクルの状態が変更されるようによりハイレベルの保証を与えます。
ライフ・サイクルの状態の履歴
CI のライフ・サイクルの状態の履歴は、定義された構成に対する計画策定、意思決定、および変更管理などのアクティビティーにとって重要です。
図 4B. CI を制御するプロセスのベスト・プラクティスの例:ステップ 2、CI の更新または追加の実施
拡大図
したがって、各 CI の検査で、ライフ・サイクルの状態の全履歴が使用できるようになっている必要があります。CI に対して許可されたすべての変更は変更履歴に記録されるため、正しく管理されている CMDB 内にある CI のライフ・サイクルの履歴は、その CI の変更履歴から取得することができます。便利なように、変更履歴を検索しなくても特定の CI についてそのライフ・サイクルの状態の履歴を即時にレビューできる必要があります。変更履歴が定期的に保存または削除される場合は、完全なライフ・サイクルの履歴を得るために、そのような変更履歴に頼ることは必ずしも適切ではありません。
保護された状態
状態遷移図を使用すると、一連の CI のライフ・サイクルの状態を保護された状態として指定することができ、CI が変更されないようにより制御を強化することができます。「保護された」状態を指定することは、この状態にある CI に関する CMDB への変更が、管理文書の役割を果たす変更レコード (RFC から生じる) に関連付けられる必要があることを示します。つまり、保護状態にある CI の場合、必ず管理文書が存在するということになります。(図 7 では、ライフ・サイクルの生成と終局が「保護された」状態として指定されています)。このように、保護された状態にある CI の場合、その CI の変更には、常に変更レコードとの関連付けが必要となります。これには、CI のライフ・サイクルの状態を保護されていない状態へ、またはその状態から遷移させる場合も含まれます。
ライフ・サイクルの状態属性だけが保護される、軽度の保護された状態を想像することができます。つまり、ライフ・サイクルの状態属性を保護された状態に変更する場合でも、保護されていない状態に変更する場合でも、それ以外の状態に変更する場合でも、変更レコードへの関連付けが必要となるということです。発見による他の属性の変更は、保護されません。つまり、関連付けられた RFC がなくても変更を行うことができます。この軽度の保護では部分的な構成の制御は行われますが (その状態では、CI に対する遷移とユーザー・インターフェースの更新だけが制御される)、すべての属性が保護される完全な構成制御と比較すれば望ましいものとは言えません。
図 5. CI の検証と監査を行うプロセスのベスト・プラクティスの例
拡大図
ライフ・サイクルの状態図のカスタマイズ
CI のライフ・サイクルの状態遷移グラフをカスタマイズできることは必ずしも必要ではありませんが、それは、構成の制御にかなりの利点をもたらし、以下の 2 通りの状況で発生します。第一に、CI のタイプごとに一連の有効な状態と、ライフ・サイクルの状態遷移グラフがそれぞれ異なる可能性があります。これによって CI のタイプに基づく豊富な意味構造の検証を行う機会が得られます (たとえば、サーバーのライフ・サイクルをビジネス・アプリケーションから直接表すことができます)。第二に、個々のお客様の観点から、有効な状態とライフ・サイクルの状態遷移グラフによって CI タイプごとのライフ・サイクルの状態遷移グラフも同様にカスタマイズすることができます (マルチカスタマー・カスタマイズと呼ぶことができる)。マルチカスタマーについての詳細は、後述の『サービス・プロバイダーの観点』を参照してください。
フィールドの制約とキー・フィールド
ライフ・サイクルの状態遷移に関する意味構造の検証の要素の 1 つに、指定したキー・フィールドに対するフィールド・レベルの制約があります。フィールドの制約は、遷移が行われる前に特定のフィールド (属性) またはフィールドのセットが指定された基準に準拠しているかどうかを検証する方法となります。ライフ・サイクルの状態遷移の場合、これは、キー・フィールドが指定された基準に準拠していないと CI のライフ・サイクルの状態を変更できないことを意味します (たとえば、ホスト名フィールドが取り込まれるまでは、サーバーを実稼働状態にすることはできません)。キー・フィールドの概念は、フィールドの制約に関係しています。キー・フィールドとは、あるアクティビティーにとって不可欠なフィールドのことです。この場合は、状態遷移のためのキー・フィールドです。
CI の所有権と管理責任の比較
リソースの所有権とそのリソースの管理責任は区別されます。個々のリソースの所有権および管理責任情報は、CI に記録される必要があります (以降に発生する変更も同様)。リソースの所有者は、そのリソースの所有について法的責任を持つ (すなわち、そのリソースを所有する) エンティティーです。リソースの管理責任は、そのリソースの管理を誰に任せるかを規定しています。具体的な例を示すと、外部委託契約に含まれるリソースは ABC Corp が所有しているが、XYZ Inc が ABC Corp のために管理しているということです。管理を目的として、XYZ は、ABC 社によって所有されているリソースをサポートするために、個別のアカウント・チームを指定している可能性があります。また、当然のことながら、1 つのエンティティーがリソースを所有するとともに、その管理責任を負うことも可能です。このトピックは、以降の『サービス・プロバイダーの観点』のセクションで述べているマルチカスタマー・サポートの分野につながります。
影響の評価:鍵となる CMDB サービス
影響の評価は、いくつかのサービス・サポート・プロセスにおいて鍵となるステップです。変更管理では、ビジネス・プロセス、IT インフラストラクチャー、ユーザー、およびリソースの可用性に対する変更の影響を評価します。問題管理では、問題の解決のために割り当てられる時間およびリソースに影響する優先度および重大度を決定するためにサービスレベル・アグリーメント (SLA) を基準にして、問題の緊急度と、ビジネスおよびユーザーに対するその影響を判断します。インシデント管理では、SLA を基準にして、インシデントの緊急度と、ビジネスおよびユーザーに対するその影響を判断して、インシデントを解決する順序に優先順位を付け、ビジネスおよびユーザーへの影響を最小限に抑えます。これら各プロセスの影響評価は、CI 間の関係に関する情報を提供するために高度な意味構造を備えた CMDB に依存します。
変更管理のプロセス・マネージャーの構築およびお客様とのやり取りを通じて、我々は以下に示す鍵となるいくつかの洞察を得ました。
疎結合された変更管理と構成管理
お客様の中には、変更管理システムを構成管理システムから完全に切り離して使用している組織があります。ここで中心となる考え方は、変更管理にソース・コード障害管理システムを使用することにあります。このアプローチでは、変更管理に正式な承認プロセスを提供するという目的を達成することができるとともに、変更要求 (RFC) に関して顧客特有の追加の属性をカスタマイズできます。
しかし、このアプローチはいくつかの点で十分なレベルに達していません。まず、RFC の対象となる CI を構造化されたデータとして指定することができません。CI のリストを RFC の記述に指定する必要があります。第二に、RFC が CMDB にリンクされていないため、RFC のインパクト分析が完全な手作業となり、エラーが発生しやすくなります。そして、最後に、変更が実施された後は、変更管理プロセスは CMDB 内にある CI を更新できなくなります。このステップは、手作業で行う必要があります。
したがって、我々は、変更管理と構成管理が統合されたシステムを使用することを強くお勧めします。
変更管理の採用
我々の経験からすると、お客様は構成管理と変更管理を並行して採用し始めています。構成管理でのお客様の初期の焦点は、ディスカバリー・ツールを構成し、必要なフィルターおよびマッピングを作成して IT 環境内にあるCI を識別し、階層化されたトポロジーを作成することにあります。またそれと並行して、お客様はその変更管理プロセスを定義することに重点的に取り組んでいます。Gartner Inc. によると、プロセスの実装において鍵となる問題の 1 つは、そのテクノロジーに組み込まれているプロセス定義がその目的を達成するという誤った想定であるということです。29
お客様ごとに、組織も制御手順も異なります。これらの要素が、お客様が使用するプロセス参照モデルに大きな影響を与えます。既製のプロセスでも良いスタートを切ることはできますが、すべてのお客様の要件を満たすことはめったにありません。我々のお客様の 1 つである大手の保険会社での経験が 1 つの例となります。このお客様は、変更管理およびリリース管理のための完全なプロセス参照モデルを保持していました。しかし、このお客様の要件を満たすためには、その既製のプロセス・モデルを現場において大幅にカスタマイズしなければなりませんでした。
図 6. 変更を処理するためのベスト・プラクティス・プロセスの例とそのプロセスを構成している 5 つのステップの概要 (ステップ 1-2)
変更を処理するためのベスト・プラクティス・プロセスの例とそのプロセスを構成している 5 つのステップの概要 (ステップ 3-5)
拡大図
図 7. ライフ・サイクルの状態
拡大図
お客様の中には、文書化され承認された変更管理プロセスが存在していない組織もあります。このようなお客様の場合、新規の参照モデルを作成して、IT スタッフの承認を得るまでに相当な時間がかかる可能性があります。
準拠および自動化
すべてのお客様は、そのデータ・センター内で変更を実施するために使用する運用管理製品 (OMP) のセットを保持しています。たとえば、ネットワーク管理 OMP、ストレージ管理 OMP、パッチ管理 OMP などがあります。通常、変更管理システムは変更を承認してスケジュールするために使用され、OMP は変更を実施するために使用されます。
通常、変更管理システムと OMP 間の統合は極めて限られています。変更の実装者は、変更管理システムによって割り当てられた作業を OMP の構成体に変換する必要があります。手操作による介入が必要な程度によっては、この変換はエラーが発生しやすくなり、非効率的になる可能性があります。また、OMP によって実行された変更が本当に変更管理プロセスによって承認されたプロセスであったかを確認するのは難しくなります。
我々の経験からすると、大手銀行は、変更間管理システムと OMP の統合を増すことに非常に興味を示しています。たとえば、大手銀行では、許可されたパッチが許可された CI のセットに配布されたことを証明できるように、変更管理プロセスにおけるパッチの配布ステップを自動化したいと考えています。
RFC データのカスタマイズ
通常、変更プロセス参照モデルでは、変更要求 (RFC) に固有の属性を追加する必要があります。たとえば、お客様の中には、「理由付け」や「RFC を実行しない影響」などの新たな属性を必要としているところもあります。変更管理ツールは、このタイプの属性のカスタマイズをサポートする効率的な方法を提供する必要があります。
もう 1 つの重要な要件は、これらのカスタム属性に基づいてレポートを生成できることです。たとえば、リスクを反映する新たな属性を追加しようとしているお客様は、特定の期間に請求処理アプリケーションに対して行われた高いリスクの変更に関してレポートを生成できるようにしたいと考える可能性があります。
修正の自動化
それぞれの IT 環境またはデータ・センターには複数のタイプのCI があり、それぞれのタイプのCI が特定のタイプの変更を必要とします。たとえば、CI サーバー・タイプの RFC タイプには、パッチの配布、ストレージの追加、ハードウェアの追加、アプリケーションのインストール、およびアプリケーションのアップグレードなどのタイプが含まれる可能性があります。データ・センター内の変更タイプの数は、非常に多くなる可能性があります。
各変更タイプは、RFC で固有の属性を必要とします。たとえば、パッチの配布の RFC ではパッチ番号属性を必要とする可能性があり、ストレージの追加の RFC ではストレージの容量の属性を必要とする可能性があります。RFC に含まれるこれら固有の属性は、変更の実施に続く CMDB の更新を自動化するために使用できます。たとえば、変更が実施された後で、ストレージの追加の RFC に含まれるストレージの容量の値を使用して、サーバーの CI の許可された表現を自動的に更新することができます。
しかし、OMP システムによって IT インフラストラクチャーに対して実施された実際の変更を変更管理が認識できない場合もあります。たとえば、新しいソフトウェア・パッケージのセットがサーバーにインストールされた場合、サーバーで新たにディスカバリー・スキャンを実行して、そのサーバーのハードウェアおよびソフトウェアに行われた変更を確認する必要があります。このような場合、変更管理プロセスは、行われた変更を発見し、CMDB を正しく更新するために、そのサーバーで CI の検証および監査を行う構成管理プロセスを明示的に開始させることができます。
自動的なタスクの割り当てと承認
組織内の変更要求 (RFC) の数は、多くなる可能性があります。たとえば、あるお客様は、毎月 2000 件の変更要求 (RFC) を報告しています。したがって、お客様は、変更管理プロセスによってもたらされる新たな非効率性に関しては非常に敏感です。
関心分野の 1 つは、手動による承認およびタスクの人への割り当てです。変更管理システムは、タスクの所有権を自動的に割り当てるための柔軟なメカニズムを提供する必要があります。1 つのパターンは、CMDB に保存されている情報を使用して、個人またはグループにタスクを割り当てることです。たとえば、お客様は、変更管理の役割を果たす個人またはグループ (変更マネージャーや変更承認者など) を事前に構成することができます。この役割は、各 ビジネス CI への変更に関連付けられます (請求処理アプリケーションは、ビジネス CI の一例です)。次に、変更が要求されて、変更の要求側がビジネス CI を指定すると、この変更のために変更プロセスをインスタンス化することができ、ビジネス CI で指定された個人またはグループにプロセス・タスクが割り当てられます。
変更のスケジューリング
変更のスケジューリングは、いくつかの情報が必要となる複雑なタスクです。影響を受ける CI、影響を受ける CI のサービスレベル・アグリーメント、それらの CI に対して以前にスケジュールされた変更、およびスキルのある人材が利用できるかどうかを把握しておく必要があります。
有効なタスク・スケジューリング・メカニズムを提供している変更管理システムはありますが、包括的なタスク・スケジューリング・メカニズムを提供している変更管理システムはほとんどありません。変更管理システムと構成管理システムの統合は、この目的を達成するための基本です。
ターゲット CI
RFC を多数のターゲット CI (すなわち、RFC によって影響を受ける CI) に関連付けることができます。たとえば、パッチの配布の RFC の対象となる複数のターゲット CI は、パッチのインストール先となるサーバーのリストです。
変更の要求側は、RFC の対象となる複数の CI を指定するために、CI の集合を選択できなければなりません。インパクト分析および変更の実装計画の段階では、変更マネージャーは CI の階層を構成するための方法が必要になります。たとえば、ロケーション別、ビジネス・アプリケーションの所有者別、または CI の所有者別に CI を編成することができます。このようなターゲット CI の編成は、そのプロセスが進むにつれて進化します。たとえば、RFC の作成時に指定された CI は、インパクト分析時に洗練される可能性があります。一部の変更プロセスの実装環境では、RFC が承認されると、ターゲット CI を凍結するようにしています。
SOA の活用
変更管理によって提供されるサービスと構成管理によって提供されるサービスが SOA で取り入れられている概念を最大限に活用することが不可欠です。22 具体的に言うと、お客様は、アクセス可能な変更管理のサービス対話ポイント (コマンドと状態の両方に関連) が SOA サービスとして利用できるようになることを期待しています。たとえば、グラフィカル・ユーザー・インターフェースや十分に立証された Web Servicesインターフェースを含む、CCMDB に対応するさまざまなエントリー・ポイントで RFC を受け取ることができるなどです。
ITSM のベスト・プラクティスは広く受け入れられています。その理由は、これらのベスト・プラクティスが、企業にとって品質およびコストに関するビジネス・ベースの目的に従って IT サービスのプロビジョニングを管理するのに役立っているからです。12 さらに、ITSM のベスト・プラクティスは、サービス・プロバイダーが自社のビジネスと顧客の IT を管理するのに重要です。5 同様に、外部委託を行っているお客様もそのサービス・プロバイダーから提供されるベスト・プラクティスの IT サービスにますます興味を示すようになっており、今日の競争の激しい市場においては、アウトソーシング業界は主要なビジネス機能のコストを削減する方法を見つけ出す必要性に迫られています。
最初にコストの削減を迫られたときには、サービス・プロバイダーは標準的なコスト抑制方法を使用しました。しかし、ビジネスの運営に使用されているハードウェアとソフトウェアを調べてその領域で効率性の向上およびコストの削減の可能性があるかを判断することなしにサービスの提供およびサービスの外部委託のための運用コストを削減することがますます難しくなっています。IBM eServer* p690 シリーズの AIX* サーバーまたは IBM xSeries* Blade サーバー・テクノロジーによって実証されているように、ハードウェアおよびオペレーティング・システムの管理の進歩によってハードウェアやリソースを共有できるようになり、デリバリーのオーバーヘッドをある程度削減するのに役立っています。これは、必要とされるときに必要とされる場所にアイドル状態のリソースを割り当てることによって、サービス・プロバイダーが既存のリソースの使用率を向上させるのに役立っています。しかし、アイドル状態を利用するこのタイプの原理は、ハードウェアの共用にしか対応しておらず、依然としてすべてのソフトウェアを実装する必要があります。また、サービス・デリバリー・チームが各インフラストラクチャー・インスタンスからの個々のサポート契約を維持する必要があり、わずかな節約にしかつながっていません。
ほとんどエンタープライズ・レベルのアプリケーションは、ハードウェア、ソフトウェア、およびサービスのコストを含む個々のインフラストラクチャーを必要とし、業務を委託してきた顧客ごとにそのようなインフラストラクチャーを作成し、維持する必要があります。
サービス・プロバイダーが必要としているのは、1 つのインスタンスで複数の顧客をサポートできるアプリケーションです。このことは、特に、サービス・プロバイダーが自らの IT 環境およびサービスだけでなく顧客に提供する IT 環境およびサービスを管理するために利用している ITSM アプリケーションに当てはまります。しかし、構成管理システムや変更管理システムなどの ITSM アプリケーションで複数の顧客に対応できるようになることによって、データの分離の絶対的な保証やセキュリティー上の考慮事項などの新たな課題が生じます。また、一元化されたデータの収集、保守、監査、および可用性を一貫して管理するために、繰り返し可能なプロセスを規定する必要性が生じます。サービス・プロバイダーが包括的なソリューションを顧客の多様な集合に提供する場合、包括的なデリバリー方法と包括的なプロセスを開発して管理することが必要となり、そのプロセスと方法は、文化、国、および規制に関する要素に対応しなければなりません。したがって、サービス・プロバイダーは、必要な場合または一元化されたガバナンスで許される場合にデータやプロセスをカスタマイズできる透過的なテクノロジーの層を提供するために、共通の柔軟性のある拡張可能なツールが必要となります。たとえば、変更管理および構成管理ソリューションは、顧客レベルで、あるいは顧客の組織のレベルでさえもカスタマイズ可能な、既定の変更管理および構成管理のベスト・プラクティスに基づくプロセスを提供する必要があります。
サービス・プロバイダーのニーズを満たす真のマルチテナント変更管理および構成管理ソリューションを実現するには、克服しなければならい課題が多数あります。これらの課題は、時間が経過するにつれて徐々に対応されるものと考えられます。プロセスをカスタマイズできることは重要ですが、柔軟なデータの分離およびアクセス制御を行えるようになることほどは重要ではないことは明らかです。サービス・プロバイダーによって必要とされる機能は、社内の各部門を別々に管理することを選択する企業にも利益をもたらします。
今日の競争の激しいビジネス環境、IT 環境の複雑さ、および企業の成功を納めるうえでの IT の重要性が、業界のベスト・プラクティス (つまり、組織、サービス・プロバイダー、または業務を外部委託している企業がコストおよび品質に関するビジネスの目標に従ってその IT環境を管理できるようにする慣行) の利用を決定づけています。ITIL は、多くの業界リーダーのコラボレーションにより United Kingdom Office of Government Commerce が開発したもので、CMDB の編成とCMDB をサポートする構成管理プロセスおよび変更管理プロセスに対する有益な洞察を提供します。それらの洞察を、プロセスがサービス・プロバイダー、つまり、他の企業の IT の管理を事業にする企業の観点から実際に実装される必要がある ITSM プラットフォームに適用する場合は、さらなる熟慮が必要となります。本稿では、ITIL に準拠した変更管理プロセスと構成管理プロセスについて紹介し、お客様から得た経験に基づいてさらなる洞察を提供し、これらのプロセスがどのように相互に関係しているかを説明し、このようなソリューションをサービス・プロバイダー環境に実装するために取り組む必要があるさらなる考慮事項を示しました。我々は、お客様への対応から得た経験によって、ITIL に準拠した CCMDB を保持することや、サービス・プロバイダーが管理するソリューションを活用することによって得られるコストおよび効率の改善がお客様に利益をもたらすことを学びました。また、これらの経験から、お客様がそのデータの分離およびカスタマイズの問題に取り組むために包括的なソリューションを必要としていることもわかりました。同様に、社内の各部門を別々に管理することを選択する企業も恩恵を受けることができます。
将来に目を向けると、CCMDB の機能が IBM サービス・マネジメントにとってますます重要になること予測できます。必然的かつ不可欠な SOA 内での CCMDB 機能の利用に加えて、一連の管理対象エレメント (たとえば、ポリシーや管理対象のサービス成果物) の拡張、これまで以上に洗練された関係およびゴールド・スタンダードの分析、およびこれらすべてのポリシー主導の制御、アクション、および警告との統合のニーズが高まると考えられます。以上を前提として、企業は最終的に IT インフラストラクチャーをコントロールできるようになる可能性があります。
*IBM Corporation の米国およびその他の国における商標または登録商標です。
**United Kingdom Office of Government Commerce、Information Systems Audit and Control Association、または The Open Group の米国およびその他の国における商標または登録商標です。
- 「Information Technology Infrastructure Library (ITIL)」、U.K. Office of Government Commerce
- U.K. Office of Government Commerce、「A Code of Practice for IT Service Management」、Service Support, ITIL Managing Services, Stationery Office, London, United Kingdom (2005 年)、Section 1.9
- ISO/IEC 20000-1:2005、「Information Technology—Service Management Specification」、International Organization for Standardization and the International Electrotechnical Commission (2005 年)
- R. J. Colville 著、「CMDB or Configuration Database: Know the Difference, RAS Core Research Note G00137125」、Gartner, Inc., Stamford, CT 06904 (2006 年 3 月)
- M. Ernest、J. M. Nisavic 共著、「コンポーネント・ビジネス・モデルを用いた IT 組織への価値の付加」、IBM Systems Journal 46, No. 3, 387–403 (2007 年、本号)
- M. B. Chrissis、M. Konrad、S. Shrum 共著、「Guidelines for Process Integration and Product Improvement」、Addison- Wesley Professional、Boston、MA (2003 年)
- Carnegie Mellon University Software Engineering Institute、「The Capability Maturity Model: Guidelines for Improving the Software Process」、M. C. Paulk、C. V. Weber、B. Curtis、および M. B. Chrissis、編集者、Addison-Wesley Professional, Boston, MA (1995 年)
- E. Guldentops 著、「Governing Information Technology Through COBIT」、Proceedings of the IFIP TC11/WG11.5 4th Working Conference on Integrity, Internal Control and Security in Information Systems:Connecting Governance and Technology, Brussels, Belgium (2001 年)、pp. 115–160
- 「Control Objectives for Information and Related Technology (COBIT)」、Information Systems Audit and Control Association
- F. Niessink、H. Van Vliet 共著、「Towards Mature IT Services」、 Software Process: Improvement and Practice 4, No. 2, 55–71 (1998 年)
- A. Cater-Steel、W. Tan、M. Toleman 共著、「Challenge of Adopting Multiple Process Improvement Frameworks」、Proceedings of the 14th European Conference on Information Systems, Go¨teborg, Sweden (2006 年)、pp. 12–14
- A. Hochstein, R. Zarnekow、 W. Brenner 共著、「ITIL as a Common Practice Reference Model for IT Service Management: Formal Assessment and Implications for Practice」、Proceedings of the IEEE International Conference on e-Technology, e-Commerce and e-Service, Hong Kong, China (2005 年)、pp. 704–710.
- R. Conradi、B. Westfechtel 共著、「Version Models for Software Configuration Management」、ACM Computing Surveys 30, No. 2, 232–282 (1998 年)
- D. Lindquist、H. Madduri、C. J. Paul、B. Rajaraman 共著、「IBM サービス・マネジメント・アーキテクチャー」IBM Systems Journal 46、No. 3、423–440 (2007 年、本号)
- H. Madduri、S. S. Shi、R. Baker、N. Ayachitula、L. Shwartz、M. Surendra、C. Corley、M. Benantar、S. Patel 共著、「IBM サービス・マネジメントを支える構成管理データベース・アーキテクチャー」、IBM Systems Journal 46、No. 3、441–457 (本号、2007 年)
- C. J. Paul 著、「プロセス・マネージャーの構築プロセス: アーキテクチャーとデザイン・パターン」、IBM Systems Journal 46, No. 3, 479–495 (本号、2007 年)
- V. A. Danciu、B. Kempter 共著、「From Processes to Policies—Concepts for Large Scale Policy Generation」、Proceedings of the IEEE/IFIP Network Operations and Management Symposium, Seoul, Korea (2004 年)、pp. 17–30
- J. Kramer、J. Magee 共著、「The Evolving Philosophers Problem: Dynamic Change Management」、IEEE Transactions on Software Engineering 16, No. 11, 1293–1306 (1990 年)
- A. Keller、J. L. Hellerstein、J. L. Wolf、K.-L. Wu、V. Krishnan 共著、「The CHAMPS System: Change Management with Planning and Scheduling」、Proceedings of the IEEE/ IFIP Network Operations and Management Symposium, Seoul, Korea (2004 年)、pp. 395–408
- A. Keller 著、「Automating the Change Management Process with Electronic Contracts」、Proceedings of the 7th IEEE International Conference on E-Commerce Technology Workshops, Munich, Germany (2005 年)、pp. 99–108
- 「Sarbanes-Oxley Act of 2002」、Public Law 107-204 (116 Statute 745), United States Senate and House of Representatives in Congress (2002 年)
- C. Mayerl、T. Vogel、S. Abeck 共著、「SOA-Based Integration of IT Service Management Applications」、Proceedings of the IEEE International Conference on Web Services, Orlando, FL, (2005 年)、pp 785–786
- N. Joshi、W. Riley、J. Schneider、Y.-S. Tan 共著、「IBM サービス・マネジメントにおけるドメイン固有の IT プロセスと IT ツールの統合」、IBM Systems Journal 46, No. 3, 497–511 (2007 年、本号)
- A. G. Ganek、T. A. Corbi 共著、「The Dawning of the Autonomic Computing Era」、IBM Systems Journal 42, No. 1, 5–18 (2003 年)
- M. W. Johnson、A. Hately、B. A. Miller、R. Orr 共著、「Evolving Standards for IT Service Management」、IBM Systems Journal 46, No. 3、583–597 (2007 年、本号)
- U.K. Office of Government Commerce、「A Code of Practice for IT Service Management」、Service Support, ITIL Managing Services, Stationery Office, London, United Kingdom (2005 年)、Section 7.8
- 「IBM Tivoli Unified Process」、IBM Corporation
- U.K. Office of Government Commerce、「A Code of Practice for IT Service Management」、Service Support, ITIL Managing Services, Stationery Office, London, United Kingdom (2005 年)、Section 7.2
- S. Mingay、S. Bittinger 共著、「Don’t Just Implement CMMI and ITIL: Improve Services」、Research Note G00136578, Gartner, Inc., Stamford, CT 06904 (2005 年 12 年)
2006 年 12 月 20 日に発表許可
2007 年 7 月 11 日にオンライン公開
Christopher Ward
IBM Research Division, Thomas J. Watson Research Center, 19 Skyline Drive, Hawthorne, New York 10532。Ward 博士は、Service Delivery 部門の研究員兼管理者です。University of Florida でコンピューター・サイエンスの博士号を取得しています。2000 年に IBM に入社し、ごく最近では、IBM Tivoli ITSM ベースの CCMDB 製品のための構成管理プロセスにおける革新的な機能を担当しています。Ward 博士は、さまざまなコンピューター・サイエンスの問題に取り組む 50 件以上の論文を発表するとともに、多数の特許の発明者または共同発明者であり、IEEE の上級メンバーでもあります。
Vijay Aggarwal
IBM Software Group, 11501 Burnet Road, Austin, Texas 78758。Aggarwal 氏は、シニア・ソフトウェア・エンジニアです。現在、一連の IT インフラストラクチャー・ライブラリー・プロセス・マネージャーの設計の主導者となっています。インドのカンプールの Indian Institute of Technology でコンピューター・サイエンスの理学修士の学位を取得しています。エンタープライズ・システム管理製品の構築に重点的に取り組んでいます。ネットワーク管理、ストレージ管理、プロビジョニングの自動化、保守容易性、およびプロセス管理の分野で技術面を主導しています。
Melissa Buco
IBM Research Division, Thomas J. Watson Research Center, 19 Skyline Drive, Hawthorne, New York 10532。Buco 氏は、Service Delivery 部門のシニア・ソフトウェア・エンジニアです。Northeastern University で数学の文学士の学位を、Columbia University でコンピューター・サイエンスの理学修士の学位を取得しています。最近の活動は、IT サービス管理の分野に重点を置いています。IBM Tivoli CCMDB のための構成管理プロセスに貢献しています。SLA 管理、ソフトウェア・エンジニアリング、危機管理、プロジェクト管理、およびワークフローの分野にも携わりました。IBM Outstanding Technical Achievement 賞や、いくつかの IBM Research Division および Invention Achievement の賞を受けています。
Emi Olsson
IBM Systems and Technology Group, 2455 South Road, Poughkeepsie, New York 12601。Olsson 氏は、サーバー・システムの運用に関するシニア・アーキテクトであるとともに、包括的な構成管理ソリューションのリード・アーキテクトでもあります。200 社以上の多様な顧客にサービスを提供しています。他の専門領域に高品質のデータを提供することを目標にして構成管理の分野で 6 年間研究を行っています。ごく最近では、IBM Tivoli CCMDB 製品に関して IBM Software Group, Research と Integrated Technology Delivery (ITD) の両組織を 1 つにまとめて提携させるのに貢献しました。アーキテクチャー面での Olsson 氏の指揮の下に、2006 年 8 月に ITD は Tivoli CCMDB をサービスとして提供し始めました。
Steve Weinberger
IBM Integrated Technology Delivery, 4499 Fisher Road, Columbus, Ohio 43228。Weinberger 氏は、IBM Global Services, Strategic Outsourcing Services 部門の構成管理の分野に重点的に取り組んでいる IT アーキテクトです。1997 年に IBM に入社し、ごく最近では、IBM Tivoli ITSM の一連の製品に基づく包括的な構成管理ソリューションのための技術アーキテクチャーを主導する責任を担っています。構成管理処理およびツールのグローバルな標準化が、Weinberger 氏のここ数年のキャリアの原動力となっています。この研究に関して、IBM Outstanding Technical Achievement Award により認められています。
目次へ戻る
| 
