IT サービス・マネジメントを編成するための統合モデル

IT サービス・マネジメント (ITSM)¹ には、さまざまな目的に応じて作成された多くのモデルとフレームワークがあります。^2-9 このモデル、標準、フレームワークの豊富さにより、エンタープライズ・サービス提供組織の指揮をとるあらゆる人々の課題に対応できます。モデル、標準、およびフレームワークをシームレスなソリューションに統合するには、サービス指向のソリューションを規定する共通の用語とアプローチが必要です。これがなければ、別々のイニシアチブが相互にどのように関連し合うべきか、あるいはギャップやオーバーラップが存在するのかをほとんど理解できません。

本稿では、ITSM 製品とソリューションを設計、開発、デプロイするための統合モデルを提案します。目標は、それらの複雑なシステムの構築およびサポートに携わる多くの個人とロールとの間のコラボレーションを促進することです。このモデルの固有の価値は、ITSM 組織を率いるリーダーとマネージャーに ITSM領域全体に対応する包括的なモデルを提供することです。このモデルの重要な特性の 1 つは、製品とサービス双方のエンジニアリングも含め、ITSM ソリューションの仕様をエンドツーエンドでサポートすることです。

本稿で提案する ITSM 統合モデルでは、まず提供するサービスという点から見て ITSM を理解していることが前提となります(ITSM において、そして本稿全体を通して必要となるのは、「サービス」をソフトウェア配布やサーバー・サポートといった総合的な IT サービスとして理解することです。「サービス」という用語は、サービス指向アーキテクチャー [SOA] のコンテキストにおける Web サービスを指すものではありません)。開発、販売、デリバリーの各単位にわたって適応力と並列度を最も高めるためには、技術面でサービスが達成すべきこととその提供方法の違いを明確に区別する必要があります。サービスの提供方法について詳細に記述するには、組織、プロセス、ツール、およびテクノロジーを包括的に含める必要があります。本稿では、これらのすべての概念を ITSM 領域全体が体現されたモデルにいかに結び付けることができるかを説明します。

統合モデルは、ITSM 組織の運営という現実に根ざしており、現実世界のニーズを満たすために開発されました。そのため、統合モデルは正式なモデルではなく、実務者が ITSM ソリューションを文書化および伝達するときに使用する実践的なフレームワークとなっています。モデルには、サービスの販売およびマーケティングの側面など、特に商業ベースのサービス・プロバイダーに価値がある構成体が含まれています。統合モデルを最も有益に活用できるのは、エグゼクティブあるいは IT アーキテクトとしてエンタープライズ IT サービスの提供を指揮するリーダーです。

ITSM 統合モデルは、既存のモデルを置き換えることを意図していません。それどころか、多くのドメインのモデルを相互参照できるようにし、その関係を理解するための包括的なフレームワークを提供します。統合モデルは、IT ソリューション、特に構造化された設計方法と成果物を使用する ITSM ソリューションの開発方法と記述方法を示します。固有のソリューションやテクノロジーを規定するものではありません。プロセス・ドメインとサービス・ドメインは ITSM を確実に成功させるためには非常に重要であるので、モデルにおいてより詳細に定義されます。コンポーネント・モデルや運用モデルなどの抽象概念を定義するために、IBM グローバル・サービス・メソッドおよび IBM IT アーキテクチャー・プロフェッショナル標準を大いに活用しました。¹⁰

このモデルを開発するにあたり、我々の目標は明確でした。IBM グローバル・サービスの実務者たちは、多くの場合はアウトソーシング契約の一環としてインフラストラクチャー･サービス提供の日常業務に携わり、IBM⁶、^11–13 社内と業界全体^2–4 の両方から提供されるさまざまなフレームワークとアーキテクチャーに関わっています。これらのフレームワークとアーキテクチャーのそれぞれが ITSM 領域の一部に取り組んでいます。実務者たちは、分類法や用語の詳細にはほとんど興味がありませんが、業務において価値をもたらす資産がどれで、方法が何かを把握する必要があります。これに役立てるために統合モデルを作成しました。我々は、これらのすべてのイニシアチブを位置づけるために使える構造を必要としていました。そして、整合のとれた情報ソースを実務者に提供するリポジトリーという構造に変換することが最終目標でした。

この基本的なニーズが、やがてモデルに対するアプローチの背後にある根本的な主原則へと変わっていきました。

• 最も考慮しなければならないのは既存の慣例との整合性である—実務者は、モデルへの関連付けを実行でき、その個々の部分を認識できる必要があります。それゆえに、たとえば「プロセス-アクティビティー-タスク」という用語を使ってプロセス要素を記述しています。それは、実務者が IBM Process Reference Model for IT (PRM-IT)⁸、¹¹ などの構造からこの構成体を認識するためです。テクノロジーの側面について記述する場合は、実務者にとって身近な存在であるという主な理由から、IBM グローバル・サービス・メソッドの成果物の名前を使用しています。モデルにおいて何らかの不整合が生じたり、通常とは異なる構成体になったりする場合でも、この原則に従いました。
• モデルの形式より表現の明瞭さを優先させる—正式なモデリング表記でモデルを詳細に説明することは多くの対象読者にとって理解しにくいものであるため、それは止めました。モデルの正式バージョンは保持していますが、実務者には広く公表していません。
• 我々が取り上げる大半のニーズは机上の理論ではなく実践的なものである— 我々はメタモデル (モデルについてのモデル)、オントロジー、あるいは単なる分類法を作ったと言えます。モデルのクラス分けを試みるのではなく、ITSM を取り巻くイニシアチブと資産を統合する実践的なツールとして提供しています。

本稿では、モデルを形式張らないエンティティー・リレーションシップ・ダイアグラムとして表します (正式なエンティティー・リレーションシップ・ダイアグラム¹⁴ からの区別として型のないリレーションシップを使用します)。これらのエンティティーを成果物または資産、その関連付けを成果物同士の依存関係または入出力として考えることができます。最も端的な言い方をすると、このモデルでは、エンティティーとは IT インフラストラクチャー・サービスを提供するのに必要な資産です。資産の特性はあらゆるものが考えられます。アプリケーションおよび製品の領域におけるこのような成果物にはコード、ソフトウェア・モジュール、さらにはハードウェアがあり、サービスの領域では成果物として、要件ステートメント、設計図、サービス・フロー定義などの文書や仕様書があります。後に、モデルがリポジトリーに変換されるときに、エンティティーのすべてが文書によって表現されます。文書は、資産自体 (設計書または仕様書の場合)、あるいは資産および資産が見つかる場所についての記述 (ハードウェアとソフトウェアの場合) のいずれかです。

まず、IBM の実務者に提示するのと同じ方法でモデル全体を簡単な図 (エンティティーを示すボックスと関係を示す線で表される) で表現します。関係の基数については各ドメインの詳細説明でより詳しく示し、重要な関係の特性については付属テキストでより詳しく説明します。関係の基数は、資産タイプが相互にどのように関係しているのかを示します。

たとえば、テクニカル・コンポーネントとデプロイメント単位の間に多対多の関係がある場合、これは単に 1 つ以上のデプロイメント単位が 1 つのテクニカル・コンポーネントを実装できること、および 1 つのデプロイメント単位が 1 つ以上のテクニカル・コンポーネントを実装できることを示します。

モデルの開発では、他にもいくつかの重要な原則を採り入れました。簡潔性、推敲、そしてモデルの深さです。簡潔性の原則とは、できる限りエンティティーを除去して概念を組み合わせることに重点を置き、モデルをできる限り簡単なものにしたという意味です。我々は、コンポーネント・ビジネスのモデリングからプロセス設計の専門化、そして SOA ベースの技術ソリューションにいたるまで、さまざまなコンテキストの統合モデルやアイデアから出発しました。これにより、オーバーラップしたさまざまなアイデアが数多く集まりました。我々は、別々のエンティティーが存在する理由を是認するのではなく、概念をできるだけ 1 つのエンティティーにまとめる努力をしました。

これを示す 1 つの例がサービス要素 (SE) です。この中心的なエンティティーは、ITSM プロバイダーが顧客に販売したり代金を請求したりできるサービスの最小単位です。我々は当初 SE とアトミック・サービスという 2 つの別々の概念を持っていました (アトミック・サービスは、デリバリーの目的でプロバイダー組織に割り当て可能な作業の最小単位です)。そこで、インボリューション (SE が他の SE を呼び出せること) を可能にし、SE を内部または外部として識別することにより、SE とアトミック・サービスを単一のエンティティー SE に統一しました。このような決定はビジネス上重要であり、モデルを簡易化します。このような場合、アトミック・サービスの作成作業を行っているデリバリー・グループは、一貫したサービス・セットが指定されるようにするために、顧客向けのサービス・カタログの準備作業をしているグループと直接作業をしなければならなくなります。

2 番目の重要な原則は、推敲です。モデル内の主要なエンティティーのほとんどは、異なる推敲レベルで存在できます。たとえば、上位の運用モデルは、より詳細な運用モデルの集合から構成される場合があります。運用モデルもやはりデプロイメント単位に分解され、さらに物理ノードと接続に分解される場合があります。原則として、異なる推敲レベルについて別々のエンティティーを指定することはしていません。エンティティーとしての運用モデルは、概念レベルから指定レベル、そして物理レベルにいたるまでのあらゆるレベルの運用モデルを含んでいると考える必要があります。同様に、プロセス・フローにもプロセスの論理的な推敲と物理的な推敲の両方が含まれます。

ただし、いくつかのケースにおいては異なるレベルの推敲を指定しました。プロセスとアクティビティーはプロセス・モデル内では明らかに異なるレベルの推敲ですが、「プロセス-アクティビティー-タスク」の概念は PRM-IT などのプロセス参照モデルにしっかり組み込まれているので、別々の用語をそのまま維持しました。また情報モデルと論理データ・モデルは、データおよび情報ドメイン内の推敲として考えることができます。ただし、情報モデルには、論理データ・モデルにはない非構造化データが含まれます。

モデル内で推敲レベルを明示的に示すかどうかの決定は、硬直したモデリングルールや論理基準によって決めることはしませんでした。ITSM 領域を記述するのに便利なエンティティーはどれかという判断に基づき、既存の資産、慣例、用語、そして実務者の理解の容易さを考慮しました。

最後の原則であるモデルの深さは、我々はモデルを最も詳細度の低いレベルにすることは試みなかったという意味です。この原則が果たす最も重要な役割は、ITSM サービス・デリバリーで詳細を指定するその他の関連イニシアチブを理解して合理化する上で役立つということです。

ただし、形式にこだわらないという原則や理解の容易さという原則を守るために、時にはレベルの点で (額面上は) まったく異なるいくつかのエンティティーを含めることもありました。たとえば、プロセス階層の低いレベルに存在するタスクが、驚くべきことに同じダイアグラムでより高いレベルの構成体として示されることがあります。たとえば、コンポーネント・モデルやビジネス・コンポーネントなどです。しかしながら、プロセスの専門家にとって、モデルの他の部分に明確に関連する「プロセス-アクティビティー-タスク」の見慣れた表記を目にするのは説得力があると同時に便利ではあります。モデルの各ドメインにおいてレベルを選ぶ場合は、実務者が利用しやすいという点が最も優先される基準です。

このセクションを終わるにあたり、周辺にあるその他の関連モデルを確認してこの作業との関連をさぐってみます。このようなモデルには、たとえばオントロジー^15–18、統一モデリング言語^** (UML^**)¹⁹、²⁰、モデル駆動型アーキテクチャー^** (MDA^**)21、SOA^22–24 などがあります。これらのモデルの表現力は非常に奥行きが深いものであり、我々の統合モデルをある一面から推論したり、支援ツールを使って実現したりできる可能性を持っています。しかしながら、本稿の対象読者はこれらの構造を十分に理解していないことも考えられ、実際、これらの正式な構文規則が理解の妨げになる可能性もあります。それとは対照的に、統合モデルの主な価値提案は、単一の構造化フレームワークを提供することです (管理された環境内で主要な概念、用語、関係を示します)。これは、さまざまな実務者に幅広く理解されます。

統合モデルの中心となるのは、サービスの概念です。ITSM は、IT サービスの定義とデリバリー、そしてそのサービスを提供する組織の管理に関するものです。このモデルは、サービスとは何であるかを記述できる構造を提供し (サービス定義の側面)、サービス定義情報をサービスの提供方法にリンクします (サービス・デリバリーの側面)。これらの 2 つの側面は、図 1 の凡例に示した 6 つのドメインにさらに分けられます。

サービス定義の側面には、サービスとは何かを記述する 2 つのドメインが含まれます。サービス・オファリング・ドメインは、サービスのマーケティングと販売を目的とします。サービス提供ドメインは、サービスの基本セットを識別して階層構造にグループ化します。サービス・オファリング・ドメインには、顧客の要求をサポートして市場機会を活用するために、さまざまな方法でサービスを組み合わせることを容易にするエンティティーが含まれます。このドメインがサービス・プロバイダー企業にとって非常に重要であることは明らかですが、より大規模なエンタープライズに属する IT サービス提供部署にはあまり関係がないかもしれません。

サービス・デリバリーの側面には、サービスの提供方法を記述する 4 つのドメインが含まれます。プロセス・ドメインでは、サービス要求、イベント、およびトリガーに対応する場合に従うべきプロセスを記述します。組織ドメインでは、ロケーション、人材、ロール、および必要なスキルを指定します。ツールおよびテクノロジー・ドメインでは、サービスの提供に使用するアプリケーションとシステムを記述し、データおよび情報ドメインでは、サービスの提供において管理しなければならないデータと情報を記述します。

モデルは、形式張らないエンティティー・リレーションシップ・ダイアグラムとして表されます。図 1 ではモデルに提案されているすべてのエンティティーを明確にし、それらのエンティティーの相互関係を示します。この概要レベルでは基数が示されていませんが、後述のドメインの詳細説明で示します。

このモデル内には、中心となる 2 つのエンティティーがあります。SE と SD です。SE は、個々のサービスの内容を定義しますが、どのように提供されるかは定義しません。そしてサービス設計 (SD) は、人材、プロセス、ツール、およびテクノロジーの組み合わせを使用して、各サービスがどのように提供されるかを定義します。SE の完全なセットが表すものは、ITSM 領域内の完全な能力セットです。各 SE は 1 つ以上の SD を持っている必要があります。SD は、サービス提供の代替方法を表します。たとえば SE が、異なるプラットフォームごとに別の SD によってサポートされるパッチ管理であるとします （たとえば、パッチ管理—IBM zSeries^* とパッチ管理—Linux^** など)。

最終的には、モデルにより ITSM ドメイン全体のさまざまな観点が可能になります。プロセス・ドメインは、包括的なプロセス参照モデル (PRM-IT など) に対応しますが、個々のアクティビティーとタスクが特定の SE をサポートする方法が示されるリンクも持っています。ツールおよびテクノロジー・ドメインでは、包括的なコンポーネント・モデルによって、サービス・マネジメント用のすべてのツールとテクノロジーの組み合わせ方法が示され、個々の SD のリンクによって、個々のコンポーネントが特定の SE のデリバリーをサポートする方法が示されます。

図 1. 6 つのドメインが展開されてその他の詳細が示された ITSM 統合モデル

拡大図

サービス提供ドメインは、ITSM 組織が提供するサービスを記述する中心的なドメインです。このドメインのエンティティーとその関係を図 2 に示します。より詳細なモデリングのこの図では、0、1、または M (多) などの従来の方法で基数を示します。このように図 2 では、たとえば SE と SD の関係を次のように読み解くことができます。「SE は多数の SD に関連し、SD は 1 つのみの SE に関連する」より詳細な例として、SD 選択ポリシーを検討してください。各 SE は1 つまたはゼロ個の SD 選択ポリシーに関連できますが、各 SD 選択ポリシーは 1 つのみの SE に関連し、多数の SD には関連しません。

図 2. ITSM 統合モデルのサービス提供ドメイン

拡大図

あらゆる ITSM 組織の出発点は、提供するサービスを理解して分類することです。この点で重要なエンティティーは、サービス・ポートフォリオの作成に使用する基本ビルディング・ブロックである SE です。SE は、顧客の要件を満たすために定義された IT サービスの論理的な結合単位を表します。SE は、コストと価格の決定およびサービス・プロバイダーへの割り当てを目的とする最下位レベルのサービスを表します。

SE は、そのセットを管理するために 3 つの階層にグループ化されています。関連する SE の集合はサービス・セグメントに分類され、サービス・セグメントの集合はサービス・グループと呼ばれます。この階層構造には、ギャップまたは重複はありません。すべての SE は 1 つだけのサービス・セグメントに属し、各サービス・セグメントもやはり 1 つだけのサービス・グループに属します。3 つの階層が選ばれているのは実用性からであり、単に管理される SE の数にのみ基づいています。これまで ITSM 領域を構成する約 220 のSE を特定しました。これらを管理するために、14 個のサービス・グループ (たとえば、資産サービスとデータ・ネットワーク・サービス)、および 2 個から15 個の SE が含まれる 43 個のサービス・セグメント (たとえば、データ・ネットワーク計画と資産管理) を作成しました。

この構造は、ITSM 組織やプロセス構造に非常に近いものである可能性がありますが、定義済みのリンクはなく、階層は SE を分類して構造化するためだけに存在します。このように、この構造は、主に提供するサービスの完全なセットを理解する必要がある ITSM 組織を管理するユーザーが使用します。

SE は外部または内部として分類する必要があります。外部 SE とは、たとえばパスワード・リセット・サービスなど、ITSM 組織の顧客が表示および使用するものです。内部要素は、内部にのみ表示されます。例としてエンタープライズ・サービス・バスによって提供される通信サービスがあります。SE は、相互に使用し合って責任を遂行できます。つまり、SE 間には依存関係があります。ある SE がその責任を遂行するために、別の SE を使用できます。ただし、内部 SE を何らかの方法で使用するのは外部サービスでなければなりません。そうでない限り重複になります。

この SE レベルへの階層降下は、サービスの内容のみを記述します。各 SE の背後には 1 つ以上の SD が存在します。つまり、サービスを提供する方法を記述するサービスの内部ビューです。SD は、組織とサービス・フロー、およびテクニカル・コンポーネントと運用モデル内に含まれる詳細なデリバリー記述の概要と要約です。

SE ごとに 1 つ以上の SD が存在しなければならず、各 SD はそれ自身がサポートする SE のスコープ全体を実装している必要があります。複数の SD が存在する場合は、以下のいずれかの理由から SD は代替ソリューションを表します。

• 異なるプラットフォームには別のソリューションが必要である (たとえば、IBM zSeries サーバー用のソフトウェア配布と Microsoft Windows^** 用のソフトウェア配布)
• 異なるレベルのサービスに対応するには異なるソリューションが必要である (後述のサービス層を参照のこと)
• 顧客のニーズを満たすには異なるソリューションが必要である (たとえば、Microsoft Systems Management Server ベースのソフトウェア配布と IBM Tivoli^* ベースのソフトウェア配布)

SD には、実際には固有の情報は含まれません。SD は、別のドメインの設計で保持されている技術、プロセス、組織、およびデータの詳細なソリューションの要約であり、その目的は特定の SE を実際に提供する方法についての概要を示すことだけです。それでもなお SD はモデル全体のなかの重要なエンティティーです。全部をまとめた SD の完全なセットは、ITSM 組織の全体の能力の合計を表します。我々は SD をサービス提供ドメインに配置しましたが、SD はサービス内容とサービス提供方法をつなぐブリッジを形成しているため、すべてのドメインの外側に属すという言い方もできます。

統合モデルのその他のエンティティーは、SE と SD の構造をサポートします。サービス・カタログは、ITSM 組織が提供するすべてのサービスの要約リストです。サービス層は、異なるサービスレベルを持つ同一の基本機能サービスが必要になる一般的な要件を取り込みます。レベルについては、可用性の目標、応答時間、解決時間、その他のより高いまたは低いレベルになる可能性があります。単一の SE に複数の SD が存在する場合には、SD 選択ポリシーに SD の選択基準が含まれます。

サービスに関連付けられたコストは、SD レベルにおいてエンティティー・サービス設計会計モデルを使用して保持されます。同じ基本ソリューションに対して異なる国、拠点、、および組織が別々のコスト・モデルを持つ可能性があるため、ここでは 1 対多の関係が存在します。

このドメインにおけるエンティティーの最後のグループは、IBM Component Business Modeling (CBM)²⁵ フレームワークへのリンクを提供します。CBM は、ソフトウェアのコンポーネント・モデリングとは異なります。ビジネス・コンポーネントは、製品またはサービスを提供するエンタープライズの 1 つの側面として独立して機能するためにポテンシャルごとに定義されます。これはソフトウェア・コンポーネントとは対照的です。ソフトウェア・コンポーネントは、カプセル化やコンテキスト固有かどうかなどの技術的な特性の点から定義されます。そのためビジネス・コンポーネントは、概念的には SE に非常によく似ています。両方とも、人材、プロセス、ツール、およびテクノロジーの組み合わせによって提供可能な機能またはサービスを記述します。また、両方とも非オーバーラップであり、かつプロバイダー割り当て可能な機能 (SE が 1 つのビジネス・コンポーネントの一部にしかなれないことをモデルが提案しているので) の概念を取り込んでいます。ただし、粒度のレベルはまったく異なります。SE は価格設定が可能なサービスの中で最も低いレベルです。一方、ビジネス・コンポーネントは、主にビジネス分析および計画で使用されるより高いレベルの構成体です。統合モデルでは、これらの 2 つの概念の間のリンクを提案しています。ビジネス・コンポーネントは、関連付けられた SD を持つ SE の集合と同じでなければなりません。

図 3. ITSM 統合モデル:サービス・オファリング・ドメイン

拡大図

CBM では、コンポーネントはビジネス・コンピテンシーにグループ化されます。ビジネス・コンピテンシーは、特徴のあるスキルと能力を持つ大きなビジネス領域です。ビジネス・コンポーネントは、その説明責任レベルによってさらに分類されます。これは、アクティビティーのスコープと意図および意思決定を特徴づけます。CBM で使用される3 つのレベルは、指揮、管理、実行です。これらの用語と概念の詳細については、CBM 文書⁸ を参照してください。

サービス・オファリング・ドメインは、ITSM サービスおよびオファリングのマーケティングと販売を行う人にとって価値のあるエンティティー・セットを提供します (図 3)。したがって、おそらくは商業ベースの ITSM プロバイダーにとってより関連性が高いものになります。このドメインには、サービス・テーマ、サービス、サービス製品という 3 つのエンティティーがあり、モデリングエンティティー SE にリンクされます。これによってサービス提供ドメインへのブリッジが提供されます。サービス提供ドメインのサービス階層とは異なり、これらのエンティティーは SE のセットを構成したり編成したりしません。同じ基本 SE の上に作成されますが、変化する市場や顧客のニーズに合わせて動的に作成、変更、廃棄できます。以下のように定義されます。

• サービス・テーマ—ビジネスと IT 課題の最上位領域で顧客を支援するサービス・プロバイダーの能力に市場の関心を取り込めるように設計された幅広い、戦略的な市場向けのメッセージング構成体です。
• サービス—サービス製品または SE あるいはその両方から構成され、指定された市場セグメントで広範囲の顧客要件に対応します。
• サービス製品—顧客の IT サービス要件の一般的で反復可能なセットを一貫して実行しなければならない 1 つ以上の SE または他のサービス製品の構成およびパッケージ化された統合。

サービス・オファリング・ドメインとサービス提供ドメインの間には緊密な関係があります。それは、組織は提供方法が分かっているサービスのみを提供できるということです。

その結果として、その関係は、SD および関連するエンティティーによって「提供方法」に関連付けられたドメインとの間のスレッド化された複数のリンケージに変換されます。

ロケーションや必要なサービス品質 (QoS) などの要因に基づいてサービスを提供できる複数の方法があります。

コスト (およびその結果としての市場価格) は、このドメインにとって関心が高い重要なパラメーターです。しかしながら、モデルの重要な機能は、提供するサービスのコストに基づいてコストと価格を計算することです。そして、SD レベルでのみこれを正確に行うことができます。会計エンティティー (サービス設計会計モデル) が、ここではなくサービス提供ドメインにのみ存在するのはこのためです。もちろん、販売とマーケティングのプロフェッショナルは、自分たちの提案を構成する基本ビルディング・ブロック (SD と SE) を参照し直すことにより必要なコスト情報を取得します。

組織ドメインは、サービス指向 ITSM プロバイダーの構造とロールを記述する相互に関連する 6 つのエンティティーから構成されます (図 4)。以下の 3 つのエンティティーは、組織とロケーションの情報を記述します。

• 組織—1 つ以上の SD を提供する包括的なエンタープライズの一部分。このエンティティーに対するインボリューションにより、複数の組織レベルを記述できます。最上位レベルにおいて、組織は報告機構であり、かつサービス提供の責任がある事業単位間の関係です。IT 組織はエンタープライズのニーズと整合性を取り、異なる業務間で IT サービスを共有する効率性と、業務重視のサービス差異化によるビジネス成長の可能性との間でバランスを取る必要があります。
• ロケーション—サービスを提供する目的で人材とマシンが配置された特定の場所。複数の組織を1 つのロケーションに配置することも、1 つの組織が複数のロケーションにまたがることもできます。
• ロケーション・タイプ—ロケーションを分類するために使用します。ロケーション・タイプは、汎用タイプかロケーションのクラスです。たとえば、データ・センター、コール・センター、管理事務所などです。

残りのエンティティーは、個々のジョブを記述します。ロールは、定義された複数のタスクを個人が実行できるように、個人に与えられた責任の最も小さい集合です。ロールは 1 つ以上のスキルに依存し、特定の人のジョブ・ロールを作成するために組み合わせられます。たとえば、デリバリー・センターのサポート担当者のジョブならば、顧客サービス担当者 (サポート・コールの対応) およびサーバー管理者 (サーバー管理タスクの実行) という 2 つのロールを組み合わせられます。サーバー管理者ロールには、たとえば UNIX^** 管理者レベル 1 などの特定のスキルが必要になる場合があります。

組織ドメインは、プロセス・ドメインとサービス・ドメインとの直接のインターフェースを持ちます。IT 組織全体にわたるプロセスとサービスの開発およびデプロイメントの両方に、相応の意思決定権限とパフォーマンスの説明責任を持つ明確に定義されたロールが必要です。組織ドメインが、IT 組織構造内でこれらのロールを定義および調整します。

図 4. ITSM 統合モデル:組織ドメイン

拡大図

プロセス・ドメインは、ITSM 統合モデルにおいて重要です (図 5)。新しいサービス・マネジメント・ツールや自動化テクノロジーが十分に注目されないことやマネジメントの注意を引かないことはよくあることです。しかし、通常 ITSM の総予算の 50 ～ 70 % が人件費に費やされ、IT デリバリーをできる限り効率的にするにはプロセスの整合性および信頼性が重要となります。

3 つの基本的な概念がプロセス・ドメインを支えています。プロセス参照モデルは、必要なアクティビティーを階層構造にオーバーラップがないように分解することにより、ITSM に必要なプロセスの完全なセットを定義します。プロセス参照モデル内で、プロセスは問題管理やシステム管理などの規則に編成されます。プロセス参照モデルは、主に参照ポイントまたはチェックリストとして使用します。これにより IT マネージャーは、必要な全プロセスの規則を理解し、それらを適切に実装したかどうかを確認できるようになります。IT インフラストラクチャー・ライブラリー^** (ITIL^**) フレームワークは、おそらく最も一般的な業界標準のプロセス参照モデルであり、ITSM は ITIL の構造と用語に準拠しています (下記を参照)。

プロセス・フロー・モデルは参照モデルと同じ階層構造に従いますが、アクティビティーをアクティビティー・フローによってリンクされる個々のタスクに分解し、複数のアクティビティーをリンクするプロセス・フローを指定することにより、プロセスをより詳細に開発します。タスクは、ロールに割り当て可能な作業の最小単位として定義されます。つまり、実行のためにタスク全体をひとりの人に割り当てます。各タスクを、ユーザーにタスクの実行方法を手引きする作業指示書によってサポートできます。プロセスとアクティビティー・フローは、実際のプロセス設計の基礎として使用できます。

一連のサービス・フローによって、実際に実施されるプロセスを定義します。各サービス・フローは、たとえば「disk full」などのシステム条件やヘルプ・デスク・コールなどのユーザー・イベントといった特定のイベントやトリガーに対応して作成されます。サービス・フローは、イベントを処理するのに必要なすべてのアクティビティーに対応する必要があり、プロセス参照モデルの複数の規則にまたがる可能性があります。サービス・フローは、処理しなければならないイベントやトリガーを考慮するだけで設計できます。

図 5. ITSM 統合モデル:プロセス・ドメイン

拡大図

たとえば、イベントを処理するには、包括的なフローで同時にリンクされる、リリース管理プロセスのタスクと変更管理プロセスのアクティビティーが必要になる可能性があります。プロセス・フローのモデルは、個々のタスクをリンクして一貫性のある方法で実行するのに役立ちますが、イベント処理に必要な一連の完全な手順セットを示すのはサービス・フローだけです。プロセス・モデルの規則とは異なり、サービス・フローの完全なセットにはオーバーラップが含まれ、単一の階層構造に編成することはできません。

これらのさまざまなプロセスの成果物を効果的に使用する鍵は、管理しなければならないサービス・イベントまたはトリガーに重点を置くことです。プロセス設計は、イベントの完全なセットを理解し、それぞれのイベントを処理するために必要な実際の作業を見極めるためにシナリオ (サービス・フロー) を使用するところから始まります。プロセス定義が完成したら、プロセス参照モデルとサービス・フローを維持してアップデートしていく必要があります。IBM と業界の資産 (PRM-IT、IBM Tivoli Unified Process (ITUP)、および ITIL など) によって有用な開始ポイントが形成され、このタスクに役立つ多くの参照資料が提供されますが、すべての組織は各自の固有の環境に合わせてサービスとプロセス・フローを作り替える必要があります。

組織が、提供する IT サービスを決定し、サービス・ドメインで IT サービスを定義した後、プロセス・ドメインで IT サービスをフロー、プロセス、アクティビティー、タスクに分解したなら、適切なレベルの自動化を達成する技術ソリューションを文書化する必要があります。それが、ツールおよびテクノロジー・ドメインの目的です (図 6)。

ユース・ケース、テクニカル・コンポーネント、および運用モデルは、ツールおよびテクノロジー・ドメインでアーキテクチャーを記述するために使用する重要なエンティティーです。

図 6. ITSM 統合モデル:ツールおよびテクノロジー・ドメイン

拡大図

ユース・ケース・モデルでは、コンテキストまたはプロセス・フロー・リンケージ、および設計どおりにサービスと対話するユーザーのロールを割り当てます。そのため、ユース・ケースは特定の SD のサービス・フローに密接に関連します (またサービス・フローから派生する場合もあります)。機能とテスト・ケースは、これらのユース・ケースと一致するか対応するように設計されます。

テクニカル・コンポーネント・モデルには、ソリューションが実行すべきことの機能的な特性、つまりシステムの機能仕様が、設計者または IT アーキテクトによって取り込まれます。サービスの開発、テスト、およびデプロイメントを容易にするために、テクニカル・コンポーネント・モデルでは SD をモジュール形式にしてテクニカル・コンポーネントと呼ばれる管理が容易な部分に分解します。

運用モデルは、特定のテクノロジー (プラットフォームおよびネットワーク) によってサービスが提供される方法を取り込みます。運用モデルは、サービスによる実行方法、あるべき保護の程度、満たすべき可用性の基準などの運用要件 (非機能要件 [NFR] と呼ばれることもあります) に対応する必要があります。次に、テクニカル・コンポーネントをデプロイメントのゾーンにグループ化し、運用モデル内のデプロイメント単位に配置します。

どの会社、組織であってもアイランド (孤立) 状態になるわけにはいかないので、相互運用性の最適なレベルを促進できるように、他者と同様にこのドメインに含まれる資産に利用可能な標準が使用されるようにする必要があります。サービス・マネジメント・アーキテクトは、費用対効果の高い方法でこれを行うために、標準化された資産を使用する必要があります。これが可能になるのは、資産を選択すれば、検索、目的に適っているかどうかの検討、調整のための取得が実行できるように、資産が文書化および分類されている場合に限ります。統合モデルは、内容を分類してリンクするための理想的な枠組みを提供します。

ITSM ソリューションは、多くの対象者に対応できるようにさまざまな推敲の度合いで作成できるようになっています。ITSM 設計が概念フェーズから実装へと進むのに伴い、設計は概念レベルから論理および指定レベル、さらには製品によって異なる物理的な推敲レベルにまで練り上げられていきます。

図 7. ITSM 統合モデル:データおよび情報ドメイン

拡大図

製品、サービス、および顧客の観点は、これらの各環境で作業するアーキテクトによって作られます。一度統合モデルが構築されると、作成する必要がある個別の成果物に一定の形式を与え、統合を成功させるのに必要なリンク方法を決定することにより、この作業分解がサポートされます。たとえば、アプリケーション・アーキテクトは、コンポーネント・モデルと機能設計に集中し、インフラストラクチャー・アーキテクトは、多くの場合にサービス・マネジメントの規則が含まれることになる、運用モデルおよびそれに関連する側面に集中します。SD 文書は、これらのすべての部分をリンクします。これらの側面に対して同時に重点を置くことにより、大規模なプロジェクトがより迅速に進行します。

ビジネス・システム・アプリケーションの開発に携わったことのある人なら、このレベルのアーキテクチャーの厳格さには慣れていますが、ITSM 環境を規定するのはやりすぎなのではないかと感じる場合があるかもしれません。そのようなことはありません。忘れてはならないことは、現在この領域のほとんどの製品が、その管理およびサポート対象であるビジネス・アプリケーションと同様に、Web サーバー、アプリケーション・サーバー、データベースで構成される複数層のアプリケーションであるということです。さらに、問題管理、キャパシティー管理、およびサービスレベル管理などの ITIL に整合するほとんどのサービス・マネジメント・プロセスは、ネットワーキング、ストレージ、セキュリティーなどをはじめとする、これらすべての「テクノロジー・タワー」を必要としています。このレベルの厳格さを適用することにより、これらのプロセスをシームレスかつ複数のタワーをまたがって実装することができます。

データおよび情報ドメインは、包括的な ITSM ソリューションにおける管理対象のエンティティーを表す主要なデータ・モデル要素を記述します。また、この情報が主なサービス・マネジメント・エンティティーによってどのように使用されるのか、データおよび情報ドメインが他のドメインにどのように貢献するのかについても記述します。

統合モデルで表されるデータおよび情報は、図 7 に示す 5 つのエンティティーによって記述されます。

• 情報モデル—ITSM の単一の情報モデルは、ITSM 領域における管理対象情報の概要を示します。この情報モデルは、非構造化データと構造化データの両方を反映し、使用可能な情報の全体を表します。すべてのタイプのデータ (データベースに実装される構造化データやたとえば知識ベースなどの非構造化データ) に対応します。1 つだけの情報モデルが存在し、それが領域全体をカバーするのが理想です。
• 論理データ・モデル—単一の論理データ・モデルが、情報モデルと関連付けられます。論理データ・モデルは、ITSM 情報モデルで記述される主要な分野のそれぞれについて詳細に分解したモデルを提供します。ITSM 情報モデルが、非構造化 (知識ベースなど) の情報も含めてあらゆる情報を記述するのに対し、論理データ・モデルは、使用可能なすべてのデータ要素のエンティティーおよび関係についての情報を提供します。つまり、プログラム的な方法によってアクセスできる情報です。ITSM 領域全体に対して論理データ・モデルが 1 つだけ存在するのが理想です。
• 物理データベース設計—これは論理データ・モデルの一部を実装し、パフォーマンスの考慮事項、または標準モデルをサポートするために必要に応じて変更できます。実装の観点からは、論理データ・モデルは 1 つ以上の物理データベース設計にマップされます。
• 物理データ・リポジトリー—物理データ・リポジトリーは、1 つ以上の物理データベース設計を実装します。それぞれの物理データベース設計は、実装された設計を具体的に実現する物理データ・リポジトリーにマップされます。
• 正規マッピング—正規マッピングは、物理データベース設計のデータ設計を制約または規定する標準的なデータ設計またはスキーマです。論理データ・モデルのある一面を反映する設計は、標準のグループにおいて明確に表現されているものや、特定の機能のために使用されている市販製品のような、1 つ以上の正規マッピングに従って制約できます。

全体的なサービス・マネジメントの観点から、単一の情報モデルおよび関連付けられた論理データ・モデルを持つことが非常に望ましいことは明らかです。ただし、それにはガバナンス構造と維持のための設計権限が必要であり、包括的なデータ・モデルが個々のソリューションの物理データベース設計と一致しない可能性があります。これは、ITSM で構成、変更、問題、システム管理などの機能向けに使用されているシステムがカスタム・アプリケーションではなく、その大部分が市販パッケージであるからです。そのため、情報モデルと論理データ・モデルに、さまざまな物理データベース設計をマップして、ギャップとオーバーラップの識別をサポートする以上のことを求めるのは現実的ではありません。そうは言っても、ITSM 組織における複数のデータ・リポジトリーを可能な限り最善に制御し続けるには、このようなマッピングが重要になります。

データおよび情報ドメイン内のエンティティーをベースにした標準的な利用パターンを以下に示します。

• データおよび情報ドメインにおける有用なエンティティーは、管理対象エンティティー自体の論理データ・モデルです。この例として Tivoli Common Data Model (CDM)^26–28 があります。論理データ・モデルは、デプロイ環境で多くの ITSM コンポーネントがリソースと関係の情報を理解するために使用します。また、他のビジネス・コンポーネントが ITSM 領域に知見を提供するためにも使用できます。たとえば Tivoli CDM ¹² は、ビジネス・アプリケーションとビジネス・プロセスを取り入れて、それらが ITSM エンティティーとどのように関連するのかを示します。このモデルおよびモデルへのプログラム的なアクセスを SOA 対応環境²⁹ および自律型制御の実現に使用できます。 ^30,31
• この情報モデルは、ITSM 領域のすべての情報に関する概要を提供します。そのため、新しい IT アウトソーシングのお客様にとっての有用なリソースとなり、既存サービスのサービス・オファリングと運用管理が可能になります。
• 正規マッピング・エンティティーは、管理対象エンティティーの詳細の表記について、業界規模の (したがって相互運用が可能な) 観点を提供します。それによって別々の市販製品に存在するデータ・モデルを取得して比較できるようになります。このエンティティーは、管理対象エンティティーのサブドメイン間で共通するデータおよび情報ドメイン内の概念について簡潔に規定する機会も提供します。
• 物理データベース設計は、エンティティーとデータベースを設計および実装して新規および既存のサービスをサポートするのに必要な知見をサービス開発者に提供します。物理データベース設計は、同等なサービスを提供する製品を比較および対比するときに類似点とギャップを識別するのにも使用できます。
• 物理データベース・リポジトリーは、サービス・アプリケーションとサービス・マネジメント・アプリケーションが、その規定された機能を遂行するのに使用します。物理データベース・リポジトリーに関するメタデータは、サービス・サポート・チームが、リポジトリーを使用するアプリケーションとサービスを管理するのに使用します。
• 一部の組織、典型的な例として ITSM サービス・プロバイダーとは対照的にツールと製品を構築している組織では、製品を統合するためのデータ・モデリングと対話式の設計の基礎として論理データ・モデルを使用できます。

このセクションでは、ITSM 統合モデルの実際の適用について説明します。主に IBM 社内での経験を引用しますが、これらの原則はあらゆるエンタープライズ ITSM プロバイダーに適用されます。

IBM がモデルを作成した一番の動機付けは、関連する ITSM 資産とイニシアチブの統合を実施して、IT サービスのデリバリーにおいて IBM 実務者をサポートすることでした。モデルの完全な詳細について理解している、あるいは理解すべき実務者はほとんどいません。実務者を支援する主な手段は、ITSM 資産のリポジトリーによるものでした。

リポジトリーの主な機能は次のとおりです。リポジトリーは、IBM Lotus Notes^* テクノロジーをベースにしたコンテンツ・マネジメント・システムで、一連の文書と規定されたリンケージを指定する方法で統合モデルを実装します。ユーザーは、社内のイントラネットから利用可能なユーザー・ポータルのグラフィカル・ユーザー・インターフェース経由でこれらの文書にアクセスできます。そして、コンテンツのリポジトリーへのロード方法とコンテンツの使用方法を管理するガバナンス・システムが提供されます。

IBM の標準サービス・オファリングを定義する実務者は、リポジトリー内のコンテンツの作成者と想定されます。実務者は、サービスごとに、サービスの内容 (SE) と提供方法 (サービス・フロー、組織、コンポーネント・モデル、および運用モデルなどの SD および付属文書) を定義したリンク付きの一連の文書を提供するように求められます。ガバナンス・システムにより、これらの文書は必要な品質標準を確実に満たすようになり、公開前に同じ分野の実務者たちの評価を受けられるようになります。通常、IBM ではすべての文書タイプを完全に配置することを求めずに、提供する必要がある最小限のリンク付き文書セットをオプションの追加資料とともに規定します。他の Web サイトおよびデータ・ソースへのリンクも文書内でサポートされます。

コンテンツ・ユーザーは、IBM の標準サービスを理解して実施しなければならない ITSM デリバリーの実務者です。この中にはアーキテクト、特定のお客様と協力している技術およびプロセスの専門家、および IBM のサービス組織を理解しなければならないマネジメント・スタッフが含まれます。お客様向けに新しいアウトソーシング提案を準備するセールス・スタッフも含まれます。

ユーザー・ポータル画面は、大まかに言うと統合モデルのドメインに従っています (例外として、ユーザー・インターフェースを簡易化するためにツールおよびテクノロジー・ドメインとデータおよび情報ドメインをテクノロジー・フレームワーク・ビューに結合しました)。ユーザーは、トップレベル・ビューからサービス・フレームワーク・ビューとテクノロジー・フレームワーク・ビューにナビゲートできます。サービス・フレームワーク・ビューには、ユーザーが理解できる形式で IBM のサービス・カタログが表示されます。この画面から個々の SE にドリルダウンできます。SE 文書には、モデルによって、SE をサポートする SD へのリンクなどが含まれます。このアプローチを使うことにより、ユーザーはサービス・カタログの一連のリンクからサービスのあらゆる側面 (ツール、組織またはテクノロジー) を探索できるようになります。

テクノロジー・フレームワーク・ビューにより、すべてのテクニカル・コンポーネントの組み合わせ方法が示される代替ビューが提供されます。この概要は、すべての SD の技術的な側面を組み合わせる方法を理解しなければならないアーキテクトまたは技術専門家には特に興味深いものです。このビューから個々のテクニカル・コンポーネントにドリルダウンし、モデルのリンクを使って関連 SD やプロセス詳細などの領域を探索できます。プロセス・ドメインと組織ドメインにも同様なフレームワーク・ビューが提供されます。

ITSM リポジトリーの実装から数多くのメリットがもたらされました。

• 標準の明確な規範が実装されており、優先されるサービス、プロセス、およびテクノロジーを構造化された方法で設計できます。これは、我々のサービスおよびテクノロジー標準化の前提条件です。
• サービス定義を (サービス・ドメインによって) 扱い、サービス・デリバリーのすべての側面 (組織、プロセス、ツールおよびテクノロジー) を扱うことにより、特定のサービスをすべて完全に記述できます。
• サービスのデリバリーに携わるすべてのユーザーに参照のためのシングル・ポイントが提供されます。
• サービスのあらゆる側面を定義しなければならないユーザーに統合ポイントが提供されます。特に、ある特定のドメインで新規イニシアチブ (たとえばプロセス標準の改訂など) を開始したいと考えるグループは、リポジトリー・モデル内でそれをどのように実装するのか、他のドメイン (たとえばサービス・カタログなど) とどのように統合されるのかを示さなければなりません。
• また、より上位のフレームワーク・ビューは、IBM サービスのお客様とのディスカッションに有用であることが実証されています。お客様が特定のサービスについて別のツールやプロセスを指定してくることはよくあることですが、フレームワーク・ビューはお客様のアーキテクチャー全体へのこのような変更の影響を評価して管理する上で非常に役立ちます。

要約すれば、統合モデルに基づくリポジトリーを実装したことにより、我々はサービスの真の統合を管理できるようになりました。これは、我々のモデリング作業の主要な目標でした。

統合モデルの主要な目標は、組織内の別々のイニシアチブを相互に関連可能なものにして、合理化を実現することです。統合モデルが完成してまもなく、我々は ITSM サービス・デリバリー組織のさまざまなところから提案された多くのイニシアチブを検討するために実際に統合モデルを使用しました。例としてこれらのイニシアチブの中から 3 つだけを考察します。

1. 自動化されたサービス要求とサービス・デリバリーの管理ソリューションを実装するという提案
2. 販売部隊とマーケティング部隊をサポートするためにサービスの標準的なカタログを作成して公開するという提案
3. IBM Tivoli Unified Process の最新リリースで記述されているものとデリバリー・プロセスを1つにまとめるという提案

最初からこれらのイニシアチブ間にはいくつかのオーバーラップが存在することは明らかでした。何がオーバーラップなのかを評価するのが難しかったため、各イニシアチブに分類法と意味について基本的な質問、たとえば、「サービスあるいはプロセスは何を意味していますか？」というような質問ををすることで話し合いを始める必要がありました。統合モデルがなかったなら、オーバーラップ領域の合理化はもとより、オーバーラップ領域を理解して意見をまとめるだけでも錯綜した一連の話し合いが必要になったはずです。

統合モデルを使用したため、この問題をはるかに迅速に解決することができました。各モデルのイニシアチブに関する状況説明を行い、短時間の話し合い (各ケースで 1 時間から 2 時間以内) を持つだけで、イニシアチブをモデルにマップできました。図 8 にその結果を示します。

オーバーラップがある主な領域のいくつかが、すぐにどこにあるのかが非常に明確になりました。主に自動化テクノロジーに重点が置かれていたサービス・デリバリー管理イニシアチブでは、そのサービスおよびサービス要求をサービス・カタログ・プロジェクトによって文書化されている SE セットに基づかせる必要があるのは明白です。また、サービス・デリバリー管理イニシアチブは、バックエンド・デリバリー・プロセスを ITUP にリンクできるか、リンクする必要があるのは明白です (2 つを整合させる必要がある場合)。

これらの例は明白であるように見えますが、それを予期していたイニシアチブは 1 つもありませんでした。モデルの使用は、これらのイニシアチブをまとめるための推進力としてきわめて重要でした。実際、我々はこの調査を別々のグループの合計 7 つのイニシアチブにまで拡大しています。統合モデルは、用語についての説明と議論に錯綜した時間を費やすことなく平和的な方法で、ギャップとオーバーラップを迅速に識別するのに非常に効果があることが証明されました。結果として、プロジェクト間の統合を改善して合理化するための集中ワーキング・グループをいくつか起ち上げることができました。

これは、ITSM プロバイダー組織が実際にどのように統合モデルを使用できたかを示す例です。このような組織は、いずれも自らのデリバリー機能を運用に移管してアップデートするために常に多くのイニシアチブを実行しています。また、これらの組織は、その作業の技術的、プロセス、そして組織的な側面を統制および管理するのに役立てるために複数のフレームワークやアーキテクチャーを使用しています。ITSM 統合モデルは、イニシアチブとアーキテクチャーの管理を支援する管理ツールを提供します。

あらゆる ITSM 組織が、統合モデルを以下の 3 つの方法で使用できます。

1. 組織で採用が提案されている主要なイニシアチブ、アーキテクチャー、フレームワークのすべてについて、統合モデルにマップして次の点を問い直してみます。対象となっているエンティティーを理解しているだろうか。このイニシアチブまたはアーキテクチャーが他に対してどのように適合するかに関してこれが我々に示すものは何だろうか。除去すべきオーバーラップまたは不整合はあるだろうか。整合性を確保するために作成しなければならないインターフェースはあるだろうか。
2. アーキテクチャーとイニシアチブの完全なセットをマップしたら、オーバーラップの範囲について検討します。現在、我々が理解または管理していないデリバリー機能領域が示されているギャップはあるだろうか。重複した作業が見られ、無駄な出費や不整合が生じているオーバーラップはあるだろうか。
3. 何よりもまず、モデルの核心に目を向けてください。我々の組織は、提供しているサービス (SE) のすべての範囲とサービスを提供するための標準ソリューション (SD) を理解して記述しているだろうか。基本となるこれらの能力を明確に理解することが、整合のとれたアーキテクチャーおよびプログラムの包括的なセットを作成する上での重要な第一歩となります。

我々は、ITSM 統合モデルは ITSM 領域に関する整合のとれた包括的な分析を提供すると考えます。このモデルは、ITSM 組織の現実にしっかりと根ざしています。そのため、このモデルには理想的なモデリングの慣例に厳密には従っていない箇所が所々あります。それは、我々の基本理念が「ユーザーが関連付けられる、使われるモデルを作る」というものだからです。

図 8. 3 つのイニシアチブを統合モデルへマッピングした例

拡大図

統合モデルの価値を明確に示す例を 2 つご紹介しました。我々は標準のリポジトリーをモデルに基づかせました。これによって、組織内の複数の異なる規則の間で統合が促進されることになり、一貫性のある包括的な方法でサービスを記述せざるをえなくなりました。リポジトリーは、作業を統合する上で重要なツールです。また、ITSM 組織内のオーバーラップする変更イニシアチブを位置づけて合理化するために、どのようにモデルを使用できるかを示しました。すべての ITSM サービス・プロバイダー組織が、同様な方法で、変更および改善のプログラムを編成する有用な管理ツールとしてモデルを使用できると考えます。

*IBM Corporation の米国およびその他の国における商標または登録商標です。
**Object Management Group, Inc.、Linus Torvalds、Microsoft Corporation、The Open Group、または United Kingdom Office of Government Commerce の米国およびその他の国における商標または登録商標です。

引用文献

1. J. van Bon 著、「IT Service Management: An Introduction」、Van Haren Publishing, Zaltbommel, Netherlands (2005 年)
2. U. K. Office of Government Commerce, Service Support, ITIL Managing Services, Stationery Office, London, United Kingdom (2005 年)、http://www.tsoshop.co.uk/bookstore.asp?FO=1159966&Action=Book&ProductID=0113300158.
3. ISO/IEC 20000–1:2005、「Information Technology—Service Management Specification」、国際標準化機構および国際電気標準会議 (2005 年)
4. 「eServicesCapability Model (eSCM)」、IT Services Qualification Center, Carnegie Mellon University、http://itsqc.cmu.edu/
5. J. E. King, Jr. および J. R. Nilsen、「System for Ordering Items Using an Electronic Catalogue」、U.S. Patent No. 5,319,542 (1994 年 6 月 7 日)
6. 「IBM Tivoli IT Service Management」IBM Corporation、http://www-306.ibm.com/software/info/middleware/management/index.jsp
7. H. Ludwig、J. Hogan、R. Jaluka、D. Lowenstern、S. Kumaran、A. Gilbert、A. Roy、T. R. Nellutla、M. Surendra 共著、「Catalog-Based Service Request Management」、IBM Systems Journal 46, No. 3, 531–548 (2007 年、本号)
8. M. Ernest、J. M. Nisavic 共著、「コンポーネント・ビジネス・モデルを用いた IT 組織への価値の付加」、IBM Systems Journal 46, No. 3, 387–403 (2007 年、本号)
9. HP IT Service Management (ITSM)「Enhancing IT Service Management for Business Success」、Hewlett-Packard Development Company, L.P.、http://h20219.www2.hp.com/services/cache/78734-0-0-225-121.html
10. M. Galic、J. Adams、J. A. Bell、R. Disney、V.-M. Kanerva、S. Matulevich、K. Rebman、P. Spaas 共著、「Patterns: Applying Pattern Approaches, Patterns for e-Business Series」、IBM Redbook, IBM Corporation (2003 年 7 月 28日)、http://www.redbooks.ibm.com/abstracts/SG246805.html?Open
12. 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 年、本号)
13. 「IBM IT Operational Management Products」、IBM Corporation、http://www-306.ibm.com/software/tivoli/solutions/it-operational-management/
14. 「IBM Tivoli Unified Process」、IBM Service Management、http://www.ibm.com/software/tivoli/governance/servicemanagement/itup/tool.html
15. P. P.-S. Chen 著、「The Entity-Relationship Model—Toward a Unified View of Data」、ACM Transactions on Database Systems 1, No. 1, 9–36 (1976 年)
16. S. Bechhofer、F. van Harmelen、J. Hendler、I. Horrocks、D. L. McGuiness、P. F. Patel-Schneider、L. A. Stein 共著、「OWL Web Ontology Language Reference」、M. Dean および G. Schreiber、編集者、W3C Recommendation (2004 年 2 月 10 日)、http://www.w3.org/TR/owl-ref/
17. D. Fensel、I. Horrocks、F. van Harmelen、S. Decker、M. Erdmann、M. C. A. Klein 共著、「OIL in a Nutshell」、Proceedings of the 12th European Workshop on Knowledge Acquisition, Modeling and Management、Juan-les- Pins、France (2000 年)、pp1–16
18. 「The DARPA Agent Markup Language (DAML)」、DARPA: Defense Advanced Research Projects Agency、http://www.daml.org/
19. D. Martin、M. Burstein、J. Hobbs、O. Lassila、D. McDermott、S. McIlraith、S. Narayanan 他、「OWL-S:Semantic Markup for Web Services」、W3C Member Submission (2004 年 11 月 22日)、http://www.w3.org/Submission/OWL-S/
21. 「OMG Unified Modeling Language Specification, Version 1.4」、Object Management Group (2001 年)、http://www.omg.org/docs/formal/01-09-67.pdf
23. M. Fowler 著、「‘‘UML’’ 2003—The Unified Modeling Language—Modeling Languages and Applications」の中の「What is the Point of the UML?」、P. Stevens、J. Whittle、および G. Booch、編集者、Springer, Heidelberg, Germany (2003 年)、p. 325
24. 「Model Driven Architecture (MDA)」、J. Miller および J. Mukerji、編集者、Technical Report、OMG (Object Management Group)、Architecture Board ORMSC (2001 年)、http://www.omg.org/docs/ormsc/01-04-01.pdf
25. R. High, Jr.、S. Kinder、S. Graham 共著、「IBM’s SOA Foundation: An Architectural Introduction and Overview」、V 1.0、ホワイト・ペーパー、developerWorks, IBM Corporation (2005 年 12 月 8 日)、http://www.ibm.com/developerworks/webservices/library/ws-soa-whitepaper/
27. 「OASIS Reference Model for Service Oriented Architecture 1.0」、C. M. MacKenzie、K. Laskey、F. McCabe、P. F. Brown、および R. Metz、編集者、OASIS (Organization for the Advancement of Structured Information Standards), Committee Specification 1 (2006 年 8 月 2 日)、http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf
28. R. Heckel、M. Lohmann、S. Tho¨ne 共著、「Towards a UMP Profile for Service-Oriented Architectures」、Proceedings of the Workshop on Model Driven Architecture: Foundations and Applications, Enschede, The Netherlands (2003 年)、pp. 115–120
29. 「CBM—Component Business Modeling」、IBM Haifa Research Laboratory、http://www.haifa.ibm.com/projects/software/cbm/index.html
30. 「IBM Tivoli Application Dependency Discovery Manager」、IBM Corporation、http://www-306.ibm.com/software/tivoli/products/taddm
31. 「IBM Tivoli Change and Configuration Management Database (CCMDB)」、IBM Corporation、http://www-306.ibm.com/software/tivoli/products/ccmdb/
32. 「Common Information Model (CIM) Standards」、Distributed Management Task Force, Inc.、http://www.dmtf.org/standards/cim/
33. C. Draper 著、「Combine Autonomic Computing and SOA to Improve IT Management」、developerWorks, IBM Corporation、http://www.ibm.com/developerworks/webservices/library/ac-mgmtsoa/index.html
34. 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
35. A. G. Ganek、T. A. Corbi 共著、「The Dawning of the Autonomic Computing Era」、IBM Systems Journal 42, No. 1, 5–18 (2003 年)

2007 年 2 月 12 日発表許可
2007 年 7 月 13 日 オンライン公開

John Black
IBM Global Services Integrated Operations、IT Delivery、No 1 The Square, Bristol, BS1 6DG, United Kingdom。Black 博士は、Integrated Operations の IT Delivery 組織のアーキテクトです。IBM United Kingdom Object Technology Practice のトップを務めた後、IBM Banking Sector の e-business サービスの主席コンサルタントとなりました。2003 年にヨーロッパの IBM Service Delivery の設計権限リーダー兼チーフ・アーキテクトとして IT Service Delivery に移動しました。現在は、IBM Global IT Delivery 組織内の Global Solutions Architecture Repository のチーフ・アーキテクトです。Black 博士は、Open Group Master Certified Architect であり、IET (Institution of Engineering and Technology) の会員です。

Christine Draper
IBM Software Group、11501 Burnet Road, Austin, Texas 78727。Draper 氏は、IBM オートノミック・コンピューティング・アーキテクチャー・チームのシニア・テクニカル・スタッフ・メンバーであり、オートノミック・コンピューティングの概念を ITSM に適用するために IBM 社内の開発チームと協力しています。OASIS (Organization for the Advancement of Structured Information Standards) のアクティブ・メンバーであり、ソリューションのデプロイメント記述子の標準化作業に携わっています。イングランドのケンブリッジ大学の文学士の学位を持ちます。

Tom Lococo
IBM Global Services、11 Kalina Drive, Rhinebeck, New York。Lococo 氏は、IT Delivery 組織の Integrated Operations のシニア・テクニカル・スタッフ・メンバーです。金融サービス部門を中心に IT アウトソーシングのオファリングとソリューションに取り組んでいます。現在の活動の中心は IBM グローバル・デリバリー・センターの ITSM 参照アーキテクチャーの開発です。

Fouad Matar
IBM Global Services Integrated Operations、IT Delivery、800 No. Magnolia Avenue, Orlando, Florida 32803。Matar 氏は、IT Delivery 組織の Integrated Operations のシニア・テクニカル・スタッフ・メンバーです。Global Technology Services のサービス製品ラインの各組織との強力な連携を確立して推進することに注力しています。University of Central Florida の電気工学の理学修士号の学位を取得し、現在は数学の博士号の取得を目指しています。Matar 氏は、サーバーおよびストレージ分野のサービス・ソリューションを作成しています。

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 の上級メンバーでもあります。

目次へ戻る