JP2009199528A - 複数のサービスステップを含むサービスプロセスを管理するためのコンピュータ・システム、並びにその方法及びコンピュータ・プログラム - Google Patents

Abstract

【課題】サービスプロセスを自動的に管理する仕組みを提供する。
【解決手段】サービスステップの実行に必要であるリソースについてのデータを検出するディスカバリ部と、構成要素毎に、該構成要素の少なくとも１つの所定の属性及び他の構成要素との関係を示す１組のデータを保持するリポジトリであって、該１組のデータが、サービスプロセスを１つの構成要素として定義した第１の構成要素モデルを使用して作成されたデータ、及び１以上のサービスステップを１つの構成要素として定義した第２の構成要素モデルを使用して上記検出したデータから作成されたデータである、上記リポジトリとを含む。
【選択図】図４

Description

本発明は、複数のサービスステップを含むサービスプロセスを管理するためのコンピュータ・システム、並びにその方法及びコンピュータ・プログラムに関する。

ＩＴＩＬ（Information Technology Infrastructure Library）（英国政府の商標）とは、ＩＴサービスマネジメントを実現するためのベストプラクティス（最も良い事例）を集めたものである。ＩＴＩＬの中心は、サービスサポート及びサービスデリバリーである。サービスサポートの１つとして構成管理がある。構成管理とは、ＩＴサービスマネジメントの管理対象である構成要素（configuration item、構成アイテムともいう、以下ＣＩと略す場合がある）を認識し、構成要素についての情報を維持及び更新し、確認し、並びに監査を行うプロセスである。構成要素は、構成管理の対象となる資源（リソース）である。構成要素は、ハードウェア及びソフトウェアを含むシステム資源だけでなく、ＩＴサービスの提供に必要な設備、ＩＴサービスの運営に関する規程書、作業手順書及び構成図などのドキュメント類、保守情報などのサービス、プロセス、並びに人的資源なども含む。ＩＴＩＬのフレームワークでは、構成要素を管理するために、構成管理データベース（Configuration Management Database、以下ＣＭＤＢと略す場合がある）というデータベースを用いて一元的に管理することが推奨されている。ＣＭＤＢは、構成要素の少なくとも１つの所定の属性及び他の構成要素との関係を記録するデータベースである。ＣＭＤＢを実装することで備わる最も重要な能力は、構成要素についての情報を自動的に発見する能力（ディスカバリ、自動検出ともいう）及び自動的に更新する能力（トラッキングともいう）である。ＣＭＤＢでは、構成要素についての情報をＣＭＤＢに正確に反映させることが重要である。

インターナショナル・ビジネス・マシーンズ・コーポレーション（商標、以下ＩＢＭ）は、ＣＭＤＢの構築を支援し且つＣＭＤＢを基盤に運用プロセスを制御するソフトとして、「Tivoli Change and Configuration Management Database」（以下Tivoli CCMDB）を提供している。Tivoli CCMDBにおけるディスカバリ及びトラッキングの詳細は、IBM Redbooks Deployment Guide Series: IBM Tivoli Change and Configuration Management Database Configuration Discovery and Tracking v1.1、第41〜64頁、2006年11月（下記非特許文献１）を参照されたい。Tivoli CCMDBでは、運用管理ソフトが、ディスカバリ及びトラッキングを実行するように実装されている。

Tivoli CCMDBでは、分散ネットワーク環境上の構成要素であるサーバ、クライアント、オペレーティング・システム（ＯＳ）、ミドルウエア（Web/AP/DBMS/LDAPなど）、パッケージ・ソフト、管理ツール、ネットワーク機器及びストレージ機器など300種類を識別し、さらに各構成要素についての情報、例えばコンピュータの構成についての情報、各コンピュータ上で動作するアプリケーションについての情報、各コンピュータに接続されているネットワーク接続ストレージ（ＮＡＳ）などの構成情報、ネットワークに直接接続されているストレージエリアネットワーク（ＳＡＮ）などの構成情報を自動的に発見し及び更新することができる。各構成要素についての情報の収集方法は管理対象によっても異なるが、基本的にはＣＭＤＢを管理するコンピュータ・システムがＳＳＨ（Secure SHell）などを用いて管理用のリモート・インタフェースに定期的にアクセスし、ＯＳ上の設定ファイル又は構成情報を読み取ったり、或いはＣＭＤＢを管理するコンピュータ・システムが設定確認コマンドを実行したりする。そのため、管理対象である構成要素にエージェント・プログラムを導入する必要はない。上記の様式にて発見され且つ更新された情報は、ＩＢＭが提唱する構成管理データベース用のデータ・モデル「Common Data Model」（以下ＣＤＭ）に基づいて、31種類のセクション（Computer System、Database、Application、Processなどのカテゴリ）、636種類のクラス（データ・モデルの基本単位、１つ又は複数のセクションに属する）、2609種類の属性（データの属性情報、１つのクラスに属する）、7種類のインタフェース（使用頻度の高い属性のグループ、複数のセクションに属する）、57種類の関係（リレーションシップ）、および49種類のデータタイプ（データの種別）に整理される。ＣＤＭの詳細は、IBM REDPAPER (DRAFT version) IBM Tivoli Common Data Model: Guide to Best Practices（IBM Form Number REDP-4389-00）、第2〜7頁、2007年11月（下記非特許文献２）を参照されたい。各構成要素及び他の構成要素の関係についての情報は、ＧＵＩの表示ツール、例えばTivoli Application Dependency Discovery Manager（以下ＴＡＤＤＭ）コンソールに渡される。そして、各構成要素及び他の構成要素の関係が、個々のブロック及び該ブロック間のリンクを用いて視覚的に表示される。
IBM Redbooks Deployment Guide Series: IBM Tivoli Change and Configuration Management Database Configuration Discovery and Tracking v1.1、第41〜64頁、2006年11月 IBM RED PAPER (DRAFT version) IBM Tivoli Common Data Model: Guide to Best Practices（IBM Form Number REDP-4389-00）、第2〜7頁、2007年11月

近年、サービス管理、例えばＩＴサービス管理及びビジネスサービス管理が注目を集めている。とりわけ、ＩＴＩＬ準拠のサービス管理が注目を集めている。従来のサービス管理では、サービス要求（サービスリクエスト）を処理するためのサービスプロセスに、該サービスプロセスに関連付けられるリソース、例えばヒト、場所、物、又はサービスについてのデータを事前に割り当てている。また、従来のサービス管理では、サービス要求毎に上記割り当てを行う必要がある。しかし、サービスプロセスに含まれるサービスステップのシーケンス又はサービスステップを実行するために必要とされるリソースは、同じであるとは限らない。例えば、あるサービスステップの状況又は他のサービスプロセスの状況に応じて、次のサービスステップで必要とされるリソースが事前に割り当てられたものと異なりうるという状態がしばしば生じる。このような場合、サービスプロセスの管理者が、各サービスステップで必要とされるリソースの割り当てを再度行う必要があった。よって、従来のサービス管理では、上記状態において、サービスプロセスを自動的に管理することができなかった。

本発明は、複数のサービスステップを含むサービスプロセスを管理するためのコンピュータ・システムを提供する。
該コンピュータ・システムの第１の態様は、
上記サービスステップの実行に必要であるリソースについてのデータを検出するディスカバリ部と、
構成要素毎に、該構成要素の少なくとも１つの所定の属性及び他の構成要素との関係を示す１組のデータを保持するリポジトリであって、該１組のデータが、サービスプロセスを１つの構成要素として定義した第１の構成要素モデルを使用して作成されたデータ、及び１以上のサービスステップを１つの構成要素として定義した第２の構成要素モデルを使用して上記検出したデータから作成されたデータである、上記リポジトリと
を含む。
該コンピュータ・システムの第２の態様は、
上記サービスステップの実行に必要であるリソースについてのデータを検出するディスカバリ部と、
構成要素毎に、該構成要素の少なくとも１つの所定の属性及び他の構成要素との関係を示す１組のデータを保持するリポジトリと、
上記検出したデータから上記１組のデータを作成する際に使用されるモデルを格納した記録部であって、上記モデルが、サービスプロセスを１つの構成要素として定義した第１の構成要素モデルと、１以上のサービスステップを１つの構成要素として定義した第２の構成要素モデルとを含む、上記記録部と
を含む。
上記リポジトリは例えば、ＣＭＤＢである。構成要素、及び該構成要素と他の構成要素との関係は例えば、静的な（static）データのインスタンス又はＪａｖａ（サン・マイクロシステムズの商標）のクラスのインスタンスで実装されうる。

好ましくは、上記第１の構成要素モデルが、上記サービスプロセスについての少なくとも１つの所定の属性と１以上のサービスステップとの関係を示し、上記第２の構成要素モデルが、上記サービスステップについての少なくとも１つの所定の属性と該サービスステップの実行に必要であるリソースとの関係を示す。

好ましくは、上記第１の構成要素モデルが、上記サービスプロセスを開始した際に実行するサービスステップに関連付けられた第２の構成要素モデルを特定するための属性を含む。

好ましくは、上記第２の構成要素モデルが、該第２の構成要素モデルを使用して１組のデータを作成する条件の属性、及び該第２の構成要素モデルを使用して１組のデータを作成するタイミングの属性を含む。

好ましくは、上記第２の構成要素モデルが、同じリソースを利用する複数のサービスステップを１つの構成要素として定義する。

好ましくは、上記コンピュータ・システムは、上記第１の構成要素モデルを使用して１組のデータを作成し、及び上記第２の構成要素モデルを使用して上記検出したデータから１組のデータを作成するデータ作成部をさらに含む。

好ましくは、上記ディスカバリ部が上記サービスプロセスの実行に必要であるリソースについてのデータをさらに検出する。また、上記第１の構成要素モデルを使用して作成された１組のデータが、上記検出したデータから作成されたデータである。

好ましくは、上記コンピュータ・システムがさらに、上記検出したデータを使用して、上記１組のデータを更新するデータ更新部をさらに含む。

好ましくは、上記１組のデータが、上記リソースについての少なくとも１つの所定の属性及び他の構成要素との関係を示すデータである。

好ましくは、上記リソースが、ヒト、場所、物、又はサービスである。

本発明はまた、複数のサービスステップを含むサービスプロセスを管理する方法を提供する。該方法は、構成要素毎に、該構成要素の少なくとも１つの所定の属性及び他の構成要素との関係を示す１組のデータを保持するリポジトリを含むコンピュータ・システムにおいて行われる。
該方法の第１の態様は、上記コンピュータ・システムに下記ステップを実行させることを含む。
該ステップは、
上記サービスステップの実行に必要であるリソースについてのデータを検出するステップと、
サービスプロセスの開始に応じて、サービスプロセスを１つの構成要素として定義した第１の構成要素モデルを使用して１組のデータを作成するステップであって、上記第１の構成要素モデルを使用して作成された該１組のデータが上記リポジトリ内に格納される、上記作成するステップと、
１以上のサービスステップを１つの構成要素として定義した第２の構成要素モデルを使用して上記検出したデータから１組のデータを作成するステップであって、上記第２の構成要素モデルを使用して作成された該１組のデータが上記リポジトリ内に格納される、上記作成するステップと
を含む。
該方法の第２の態様は、上記コンピュータ・システムに下記ステップを実行させることを含む。
該ステップは、
サービスプロセスの開始に応じて、サービスプロセスを１つの構成要素として定義した第１の構成要素モデルを使用して１組のデータを作成するステップであって、該作成された１組のデータが上記リポジトリ内に格納される、上記作成するステップと、
１以上のサービスステップを１つの構成要素として定義した第２の構成要素モデルを使用して１組のデータを作成するステップであって、該作成するステップが、上記サービスステップの実行に必要であるリソースについてのデータを検出するステップと、該検出したデータから上記１組のデータを作成するステップと、該作成された１組のデータを上記リポジトリ内に格納するステップとを含む、上記作成するステップと
を含む。

好ましくは、上記データの検出が、上記リポジトリから又は上記コンピュータ・システムに接続されており且つリソースについてのデータを格納する記録部から行われる。

好ましくは、上記コンピュータ・システムに下記ステップをさらに実行させる。該ステップは、上記検出したデータから、上記リソースについての少なくとも１つの所定の属性及び他の構成要素との関係を示す１組のデータを作成するステップであって、該作成された該１組のデータが上記リポジトリ内に格納される、上記作成するステップをさらに含む。

好ましくは、上記コンピュータ・システムに下記ステップをさらに実行させる。
該ステップは、
上記検出したデータについての１組のデータが上記リポジトリ内に既に格納されているかどうかを判断するステップと、
該１組のデータが上記リポジトリ内に既に格納されているならば、該格納されている１組のデータの属性値及び関係値を上記検出したデータの属性値及び関係値で更新するステップと、
該１組のデータが上記リポジトリに格納されていないならば、上記検出したデータから上記１組のデータを作成するステップと
を含む。

好ましくは、上記第１の構成要素モデルが、上記サービスプロセスについての少なくとも１つの所定の属性と１以上のサービスステップとの関係を示し、上記第２の構成要素モデルが、上記サービスステップについての少なくとも１つの所定の属性と該サービスステップの実行に必要であるリソースとの関係を示す。

好ましくは、上記第１の構成要素モデルが、上記サービスプロセスを開始した際に実行するサービスステップに関連付けられた第２の構成要素モデルを特定するための属性を含む。
好ましくは、上記第２の構成要素モデルを使用して１組のデータを作成するステップが、上記第２の構成要素モデルを特定するための属性から、１組のデータを作成すべきサービスステップを特定するステップをさらに含む。

好ましくは、上記第２の構成要素モデルが、該第２の構成要素モデルを使用して１組のデータを作成する条件の属性を含む。
好ましくは、複数のサービスプロセスのうちの前段の第２の構成要素モデルにおける上記条件が、複数のサービスプロセスのうちの後段の第２の構成要素モデルを使用して１組のデータを作成する条件（以下、後段の条件）を含み、該後段の条件を上記前段のサービスステップが完了するまでに決定するステップをさらに含む。
好ましくは、上記後段の第２の構成要素モデルを使用して１組のデータを作成するステップが、上記後段の条件と該後段のための第２の構成要素モデルにおいて定義された１組のデータを作成する条件とを使用して該１組のデータを作成するステップを含む。

好ましくは、上記第２の構成要素モデルが、該第２の構成要素モデルを使用して１組のデータを作成するタイミングの属性を含む。
好ましくは、サービスステップが複数のサービスプロセスのうちの最初のサービスステップである場合、上記タイミングは、上記第１の構成要素モデルを使用して１組のデータが作成された後であり、
サービスステップが複数のサービスプロセスのうちの２回目以降のサービスステップである場合、上記タイミングは、前段のサービスステップについての１組のデータが作成された後であるか、又は前段のサービスステップが完了した後である。

本発明はまた、構成要素毎に、該構成要素の少なくとも１つの所定の属性及び他の構成要素との関係を示す１組のデータを保持するリポジトリを含むコンピュータ・システムにおいて、複数のサービスステップを含むサービスプロセスを管理するためのコンピュータ・プログラムを提供する。該コンピュータ・プログラムは、上記コンピュータ・システムに、上記に記載の各ステップを実行させる。

本発明はまた、構成要素毎に、該構成要素の少なくとも１つの所定の属性及び他の構成要素との関係を示す１組のデータを保持するリポジトリを含むコンピュータ・システムにおいて、複数のサービスステップを含むサービスプロセスを管理するためのコンピュータ・プログラムを記録したコンピュータ可読記録媒体を提供する。該コンピュータ・プログラムは、上記コンピュータ・システムに、上記に記載のステップを実行させる。

本発明の実施形態によれば、サービスプロセス及び該サービスプロセス内のサービスステップをリポジトリ、例えばＣＭＤＢ上の構成要素として管理するために、管理者はサービスプロセスについてのモデル及びサービスステッについてのモデルを夫々用意する。また、コンピュータ・システムは、サービスステップにおいて使用されるリソースについてのデータを検出し、該検出したデータから１組のデータを作成し、該作成した１組のデータをリポジトリ内に格納する。このことにより、サービスプロセス中のサービスステップのシーケンス又はサービスステップを実行するために必要とされるリソースが変更された場合であっても、コンピュータ・システムは、上記１組のデータを使用してサービスプロセスのＣＩモデルを自動的にインスタンス化することが可能になる。

本発明において、リポジトリは、構成要素毎に、該構成要素の少なくとも１つの所定の属性及び他の構成要素との関係を示す１組のデータを保持する。該リポジトリは、該１組のデータを保持するものであれば特に限定されないが、好ましい実施形態の１つはＣＭＤＢを記録するＣＭＤＢ記録部である。
以下、ＣＭＤＢに関する基本的な用語を下記に説明する。
・構成要素（ＣＩ）
ＣＩは、ＩＴサービスマネジメントにおける管理対象の基本単位である。ＣＩは例えば、ハードウェア及びソフトウェアを含むシステム資源、ＩＴサービスの提供に必要な設備、ＩＴサービスの運営に関する規程書、作業手順書及び構成図などのドキュメント類、保守情報などのサービス、プロセス、並びに人的資源などを含む。
・構成管理データベース（ＣＭＤＢ）
ＣＭＤＢは、各ＣＩの少なくとも１つの所定の属性及び他のＣＩとの関係を記録するデータベースである。ＣＭＤＢは、ＩＴＩＬフレームワークの構成管理の中核である。ＣＭＤＢは、概念的にはデータベースであるが、物理的にはデータベース・システム、表計算ソフトのスプレッドシートの形態を取りうる。ＣＭＤＢを利用することによって、管理者はＣＩ間の関係を理解することが容易になる。
・構成要素インスタンス（ＣＩインスタンス）
ＣＩインスタンスは、ＣＩに対応するデータである。各ＣＩインスタンスは、データ・モデルのインスタンスとしてＣＭＤＢ上で表現される。インスタンスの例は、静的なデータのインスタンス又はＪａｖａ（サン・マイクロシステムズの商標）のクラスのインスタンスである。実装されたＪａｖａのクラスのインスタンスは、例えばJava Data Objects（ＪＤＯ）と呼ばれる、Ｊａｖａのクラスのインスタンスを永続化してハードディスクに保存する仕組みにより、ＣＭＤＢ内に格納される。よって、コンピュータ・システムの電源を一旦切っても、作成されたＪａｖａのクラスのインスタンスが消失することはなく、次に電源を投入したときに、記憶装置、例えばハードディスクから読み出され、メイン・メモリ上に展開されて、Ｊａｖａのプログラムによって変更或いは削除可能なＪａｖａのクラスのインスタンスとなる。以下では、ＣＩがインスタンスとしてＣＭＤＢ内に実装されるとして、説明を進める場合がある。
・データ・モデル
データ・モデルは、ＣＩを定義するためのスキーマであり、管理されるＣＩとそれらＣＩ間の関係の一貫した定義を提供する情報モデルである。具体的には、データ・モデルは、ＣＩの所定の属性及び他のＣＩ（製造装置、プロセスなど）との関係を定義する。データ・モデルの例として、ＩＢＭが提唱する構成管理データベース用のデータ・モデル「ＣＤＭ」がある。ＣＤＭの実装は例えば、Unified Modeling Language（ＵＭＬ）に基づいて行われる。
・属性（Attributes）
属性は、ＣＩを管理するに際して、個々のＣＩを特定し、ＣＩを説明する。属性として、下記のものを挙げることができるがこれらに限定されない。ＣＩの名前（ＣＩの一般名称、例えばサーバ、クライアント、ファイアウォール）、製品番号（ＩＤ）（ＣＩのある特定の実体を個別に識別するための番号であり、製造番号、シリアル番号など）、カテゴリ（ＣＩの分類、例えばハードウェア、ソフトウェア、ドキュメント）、タイプ（カテゴリでの分類をさらに詳述したＣＩの説明）、型番（供給者の命名したＣＩのモデル番号）、保証期間（ＣＩの供給者による保証期間）、バージョン番号（ＣＩのバージョン番号）、ロケーション（ＣＩが存在する場所、例えばＰＣの設置場所、ソフトウェアの書庫、媒体の保管場所、サービスを提供しているサイト）、所有責任者（ＣＩの管理責任者の名前）、責任開始日（所有責任者が、該ＣＩの責任者となった日付）、供給者（ＣＩの開発元又は提供元）、ライセンス（ライセンス番号、ライセンス数など）、提供日（ＣＩが組織に提供された日付）、受入日（ＣＩが組織に受け入れられた日付）、使用開始日（ＣＩが使用開始された日付）、ＣＩのステータス（現在のステータス、例えば稼働中、テスト中、故障中、或いは将来のステータス、例えば予定されているＣＩのステータス）、ＣＩインスタンスのステータス（ＣＩインスタンスの有効又は無効）。今後もＩＴサービスマネジメントで必要となる属性が、引き続き定義されていく。
・関係（Relation）
関係は、ＣＩ間の関係を表す。関係は、ＣＩと同様にデータ・モデルで定義されうる。関係の例として、assigns、canConnect、canUse、connectAt、connects、controls、deployedOn、Located、Managed、Owned、provides、runAt、uses、usedByが挙げられる。今後もＩＴサービスマネジメントで必要となる関係が、引き続き定義されていく。

本発明の実施形態において、ＣＭＤＢ記録部は１組のデータを格納する。１組のデータは、構成要素毎に、該構成要素の少なくとも１つの所定の属性及び他の構成要素との関係を示す。

本発明の実施形態において、サービスプロセスは、複数のサービスステップを含む。
サービスプロセスは、例えばＣＭＤＢの構造を使用してモデル化される。本明細書では、サービスプロセスのモデルをサービスプロセスのＣＩモデル又は第１の構成要素モデルという。第１の構成要素モデルは、サービスプロセスを１つの構成要素として定義する。第１の構成要素モデルは、サービスプロセスの少なくとも１つの所定の属性、及び該サービスプロセスと１以上のサービスステップとの間の関係を示す。
同様に、１以上のサービスステップは、例えばＣＭＤＢの構造を使用してモデル化される。本明細書では、１以上のサービスステップのモデルをサービスステップのＣＩモデル又は第２の構成要素モデルという。第２の構成要素モデルは、１以上のサービスステップを１つの構成要素として定義する。第２の構成要素モデルは、サービスステップの少なくとも１つの所定の属性、及び該サービスステップとサービスステップの実行に必要であるリソースとの関係、又は該サービスステップと他のサービスステップとの関係を示す。

以下、図面に従って、本発明の実施形態を説明する。本実施形態は、本発明の好適な態様を説明するためのものであり、本発明の範囲をここで示すものに限定する意図はないことを理解されたい。また、以下の図を通して、特に断らない限り、同一符号は、同一の対象を指す。

図１は、ＣＩ（例えば、機器Ａ及び機器Ｂ）の管理のための、ＣＭＤＢを含むコンピュータ・システム（１００）の例を示す。
コンピュータ・システム（１００）は、ディスカバリ部（１０１）、ＣＩ同定部（１０２）、ＣＩインスタンス作成部（１０３）、属性及び関係更新部（１０４）及びＣＭＤＢ（１０５）を含む。ディスカバリ部、ＣＩ同定部、ＣＩインスタンス作成部、属性及び関係更新部及びＣＭＤＢは、単独のコンピュータ上に実装されていてもよく、或いは複数のコンピュータ上に分散して実装されていてもよい。コンピュータ・システム（１００）はさらに、ディスカバリ・テーブル（１０６）、モデル・テーブル（１０７）及び関係テーブル（１０８）を含む。これらテーブルは、単独のコンピュータ上に実装されていてもよく、或いは複数のコンピュータ上に分散して実装されていてもよい。
また、図１は、ＴＡＤＤＭコンソールの画面（１０９）の例を示す。該画面は、ＣＩ及びＣＩ間の接続関係を示す。なお、該画面に表示されているＣＩ及びＣＩ間の接続関係は一例であり、コンピュータ・システム（１００）の管理対象であるＣＩ及びＣＩ間の接続関係全てを表示しているものではない。
コンピュータ・システム（１００）は、それ自身の管理対象である構成要素のみを管理する。「それ自身の管理対象」とは、コンピュータ・システム（１００）がアクセスできる対象ないしはディスカバリできる対象である。

ディスカバリ部（１０１）は、ＣＭＤＢの管理対象であるＣＩについての情報の検出を実行する（ディスカバーともいう）。該ＣＩの一部が、ＴＡＤＤＭコンソールの画面（１０９）に表示されている。コンピュータ・システム（１００）は、複数のディスカバリ部（１０１）を有していてもよい。好ましくは、管理対象は、ネットワークを介して、コンピュータ・システムに接続されている。ネットワークは、有線接続であるか無線接続であるかを問わない。コンピュータ・システムの管理者は、検出の対象を任意に設定しうる。検出の範囲は例えば、ドメイン名、ＩＰアドレス、ＭＡＣアドレス、機器の識別子若しくはデータベース名又はこれらの組合せにより指定することができる。管理対象であるＣＩが例えば産業機器である場合、該産業機器についての情報が検出される。検出された情報は、新たなＣＩについての情報、又は既存のＣＩの更新された属性若しくは関係の値でありうる。新たなＣＩとは、ディスカバリ部（１０１）によって検出され、ＣＭＤＢ（１０５）内に登録されていないＣＩである。既存のＣＩとは、該ＣＩのインスタンスがＣＭＤＢ（１０５）内に既に登録されているＣＩである。ディスカバリ部（１０１）は、ＣＩについての情報を、ディスカバリ・テーブル（１０６）内に格納されたディスカバリ・データ（例えばＡ−Discovery）（図２Ｂ、２０２）に従い検出する。どのディスカバリ・データを使用するかは、データ・モデル（図２Ｂ、２０１）内のディスカバリ方法に指定されている。ディスカバリ部（１０１）は、検出した、ＣＩについての情報をＣＩ同定部（１０２）に渡す。

ＣＩ同定部（１０２）は、上記ＣＩについての情報をディスカバリ部（１０１）から受け取り、検出結果の処理を行う。ＣＩ同定部（１０２）は、上記ＣＩについての情報が、新しいＣＩについての情報か、又は既存のＣＩの更新された属性若しくは関係の値かどうかを、ＣＭＤＢ（１０５）を参照して判定する。該判定は例えば、ＣＭＤＢに格納されたＣＩのインスタンス名を、上記ＣＩについての情報と比較して行われうる。上記ＣＩについての情報が新しいＣＩに関するものであることに応じて、ＣＩ同定部（１０２）は、該情報をＣＩインスタンス作成部（１０３）に渡す。一方、上記ＣＩについての情報が既存のＣＩの更新された属性若しくは関係の値であることに応じて、ＣＩ同定部（１０２）は、該情報を属性及び関係更新部（１０４）に渡す。

ＣＩインスタンス作成部（１０３）は、モデル・テーブル（１０７）に格納されたデータ・モデル（図２Ｂ、２０１）、及び関係テーブル（１０８）に格納された関係モデル（図２Ｂ、２０４）に従い、ＣＩについての情報から、該ＣＩの所定の属性及び他のＣＩとの関係を示す１組のデータを作成する。該１組のデータは例えば、静的なデータのインスタンス又はＪａｖａ（サン・マイクロシステムズの商標）のクラスのインスタンスで実装されうる。該１組のデータの例が、ＣＩインスタンスである。ＣＩインスタンスの例を図２Ｂ（２０３）に示す。上記１組のデータは、ＣＭＤＢ（１０５）内に格納される。なお、１組のデータは、ＣＩインスタンス内に属性および関係を有していてもよく（２０３を参照）、或いはＣＩインスタンス内に属性を有し、それとは別に関係インスタンスとして別々にＣＭＤＢ（１０５）内に格納されていてもよい。後者の場合、ＣＩインスタンスは、関連する関係インスタンスを特定するためのリンク付けを有する。

属性及び関係更新部（１０４）は、ディスカバリ部（１０１）とともにトラッキングを実現する。属性及び関係更新部（１０４）は、ＣＩの更新された属性若しくは関係の値を、ＣＭＤＢ内に格納された該ＣＩのＣＩインスタンスに反映する。すなわち、該ＣＩのＣＩインスタンスの属性或いは関係の値を更新する。該更新は、該値をディスカバリ部（１０１）によって検出されたＣＩについての情報と置き換えることによって行われる。該置き換えは、ＣＩインスタンスの属性或いは関係の値のすべてをディスカバリ部（１０１）によって検出されたＣＩについての情報と置き換えてもよく、或いは異なる値のみを置き換えてもよい。

ＣＭＤＢ（１０５）は、ＣＩのＣＩインスタンス（図２Ｂ（２０３））を格納する。

ディスカバリ・テーブル（１０６）は、ディスカバリ・データ（図２Ｂ、２０２）を格納する。ディスカバリ・データは、ディスカバリ部（１０１）によってＣＩについての情報が検出される際に使用される。ディスカバリ・データ（図２Ｂ、２０２）は例えば、静的なデータのインスタンス又はＪａｖａ（サン・マイクロシステムズの商標）のクラスのインスタンスで実装されうる。ディスカバリ・データは、ディスカバリ・ポリシーとも呼ばれる。ディスカバリ・データ（図２Ｂ、２０２）は、ディスカバリ部（１０１）が検索する範囲、すなわちＣＩの検索範囲である収集対象（スコープ）、収集する属性、及び収集する関係を含む（図２Ｂ、２０２）。収集対象は例えば、サブネットＩＰアドレス、ＩＰアドレスの範囲、個々のＩＰアドレス、ＭＡＣアドレス、機器の識別子、ホストネーム若しくはデータベース名又はそれらの組合せを用いて指定されうる。別の態様として、収集対象を、コンピュータ・システム（１００）にネットワークを介して接続されたスケジュール管理データベース（図示せず）としてもよい。スケジュール管理データベースには例えば、機器を使用するプロセス管理に関するデータが格納されている。さらに別の態様として、収集対象を、バッチ処理定義ファイルを格納するデータベース（図示せず）としてもよい。収集対象がバッチ処理定義ファイルを格納するデータベースの場合、ディスカバリ部（１０１）は、バッチ処理定義ファイルの中身を読み込むことにより検出を行う。バッチ処理定義ファイルには、例えば機器をどの順に使用するかのデータが格納されている。

モデル・テーブル（１０７）は、データ・モデル（図２Ｂ、２０１）を格納する。データ・モデルは、ＣＩインスタンス作成部（１０３）によって該ＣＩの所定の属性及び他のＣＩとの関係を示す１組のデータが作成される際に使用される。

関係テーブル（１０８）は、関係モデル（図２Ｂ、２０４）を格納する。関係モデルは、ＣＩインスタンス作成部（１０３）によって該ＣＩの所定の属性及び他のＣＩとの関係を示す１組のデータが作成される際に使用される。

図１は、ディスカバリ部（１０１）が、コンピュータ・システム（１００）とネットワークを介して接続されたＣＩを検出し、機器Ａ、及び機器Ａを使用する機器Ｂ並びにそれら機器の関係についての情報を検出したことを示す。次に、ＣＩ同定部（１０２）がＣＩインスタンスを作成するかどうかを判断した後、ＣＩインスタンス作成部（１０３）が、機器ＡのＣＩインスタンス及び機器ＢのＣＩインスタンス並びにそれら機器の関係（usedBy）のインスタンスを作成する。ＣＩインスタンス作成部（１０３）は、該作成した各インスタンスは、ＣＭＤＢ（１０５）内に格納する。

図２Ａは、ＣＩ（例えば、機器Ａ及び機器Ｂ）のＣＩインスタンス、及びそれら機器の関係（usedBy）インスタンスの作成を示す。機器ＡのＣＩインスタンスは、ディスカバリ部（１０１）によって検出された機器Ａについての情報から、機器Ａのデータ・モデルを用いてＣＩインスタンス作成部（１０３）によって作成される。同様に、機器ＢのＣＩインスタンスは、ディスカバリ部（１０１）によって検出された機器Ｂについての情報から、機器Ｂのデータ・モデルを用いてＣＩインスタンス作成部（１０３）によって作成される。機器Ａ及び機器Ｂの各データ・モデルは、モデル・テーブル（図１、１０７）に格納されている。ＣＩ同士の関係、すなわち機器Ａと機器Ｂとの関係（usedBy）のインスタンスは、ディスカバリ部（１０１）によって検出された機器Ａについての情報から、関係モデルに従いＣＩインスタンス作成部（１０３）によって作成される。関係モデルは、関係テーブル（１０８）に格納されている。
上記した通り、図２Ａは、機器Ｂのデータ・モデルを用いて機器ＢのＣＩインスタンスが作成されることを示す。機器が例えば機器Ｂ１、Ｂ２、Ｂ３である場合、機器Ｂ１、Ｂ２、Ｂ３についての各情報が機器Ｂのデータ・モデルを使用してインスタンス化されて、機器Ｂ１のＣＩインスタンス、機器Ｂ２のＣＩインスタンス、機器Ｂ３のＣＩインスタンスが夫々作成される。機器Ｂ１、Ｂ２、Ｂ３の各ＣＩインスタンスもまた、ＣＭＤＢ（１０５）内に格納される。

図２Ｂは、モデル・テーブル（図１、１０７）内に格納されたデータ・モデル（２０１）、ディスカバリ・テーブル（図１、１０６）内に格納されたディスカバリ・インスタンス（２０２）、ＣＭＤＢ（図１、１０５）内に格納された（機器Ａの）ＣＩインスタンス（２０３）及び関係テーブル（図１、１０８）内に格納された関係モデル（２０４）を示す。

データ・モデル（２０１）は、ＣＩを定義するためのスキーマである。データ・モデル（２０１）は例えば、どのＣＩのモデルかを示す「モデル名」、モデル名に指定されたＣＩが有する属性を示す「モデル属性」、モデル名に指定されたＣＩと他のＣＩがとりうる「関係」、及びモデル名に指定されたＣＩを検出するためのディスカバリ・インスタンスを特定する「ディスカバリ方法」の各記述を含む。モデル属性は、例えばＩＢＭが提唱する構成管理データベース用のデータ・モデル「ＣＤＭ」に規定された属性に従い規定されるが、これらに限定されない。ＣＤＭでは、2609種類の属性が規定されている。ＣＭＤＢの管理者は、データ・モデル（２０１）における属性を任意に指定しうる。関係は、例えば上記ＣＤＭに規定された関係に従い規定されるが、これらに限定されない。ＣＤＭでは、57種類の関係が規定されている。ディスカバリ方法は、ディスカバリ・インスタンス名で特定されうる。図２Ｂの場合、A-Discoveryである。

ディスカバリ・インスタンス（２０２）は、データ・モデル（２０１）のディスカバリ方法によって特定されるディスカバリ・インスタンスの「名前」、ディスカバリ部（１０１）によって収集する管理対象（ＣＩ）の「収集対象（スコープ）」、ディスカバリ部（１０１）によって収集する管理対象（ＣＩ）の「収集する属性」及び「収集する関係」、並びに該ディスカバリ・インスタンスがアクティブであるか或いはインアクティブであるかを示す「ステータス」の各記述を含む。

ＣＩインスタンス（２０３）は、該インスタンスがどのＣＩのものであるかを特定するための「インスタンス名」、該インスタンスが、どのデータ・モデルを使用して作成されたかを示す「モデル名」、データ・モデルによって特定された各属性の「属性値」、データ・モデルによって特定された各「関係」の記述（値）、インスタンスがアクティブであるか或いはインアクティブであるかを示す「ステータス」、及び該ＣＩインスタンスが作成された「作成日時」の各記述を含む。ＣＩインスタンスは好ましくは、ＣＩインスタンスに特有のＣＩインスタンス識別子をさらに含む。ＣＩインスタンス識別子は、当該ＣＩインスタンスを他のＣＩインスタンスと区別できるものであれば特に限定されないが、例えばホストネーム、シリアルナンバー若しくは一定の値である他の属性の組み合わせを使用しうる。図２ＢのＣＩインスタンス（２０３）は、機器ＡのＣＩインスタンスであること；データ・モデルＡを使用してインスタンス化されたこと；属性としてＳ、Ｔ及びＵを含み、これらが夫々値を有すること；関係として、Ｍによって使用されること（usedBy:M）、Ｅに接続されること（connectAt:E）、及びＨで実行すること（runAt:H）；ＣＩインスタンスがアクティブであること、並びに該ＣＩインスタンスの作成日時のデータを示す。

関係モデル（２０４）は、データ・モデル（２０１）によって特定される関係を定義するためのスキーマである。関係モデル（２０４）は、usedByなどの「関係名」、該関係の対象となるデータ・モデルを特定するための「対象となるデータ・モデル」、該関係の「説明」の各記述を含む。

図３は、サービスＡについてのサービスプロセスの従来の処理を示す。
該サービスプロセスの処理では、管理者が、サービスリクエストを処理するためのサービスプロセス、及び該サービスプロセスに含まれるサービスステップを定義し、記憶装置に格納する。プロセス制御装置が、サービスＡへのサービスリクエストを受信する。該受信に応答して、プロセス制御装置が、サービスＡについてのサービスプロセスのＣＩモデルのインスタンス化を開始する。インスタンス化の際、プロセス制御装置は、上記管理者にサービスステップ毎に、該サービスステップの実行に必要であるリソース、例えばヒト、場所、機器などの物又はサービスの問い合わせを行なう。該問い合わせに対して、上記管理者は、サービスステップの進行状況又は他のサービスプロセスの進行状況を考慮して適切なリソースを検索し、そしてサービスステップ毎に該検索したリソースの割り当てを行う必要があった。

図４は、サービスプロセス及び各サービスプロセスを夫々モデル化する本発明の実施形態を示す。
サービスＡのためのサービスプロセスは、複数のサービスステップを含む（４０１）。
図４の４０１は、複数のサービスステップを特定の粒度で定義する概念を示す。該粒度は、サービスプロセスの管理者によって適宜に定義されうる。該粒度は例えば、同じリソースを利用する複数のサービスステップ、又は同じ時間帯に実行されるサービスステップを１つの粒度としうる。
図４の４０２は、サービスプロセスと各サービスプロセスとを夫々モデル化する概念を示す。
サービスプロセスは、例えばＣＭＤＢの構造を使用してモデル化される（４０２）。該モデルは、例えばサービスプロセスの管理者によって用意されうる。本明細書では、該モデルを、サービスプロセスのＣＩモデルという場合がある。サービスプロセスのＣＩモデルは、上記サービスプロセスを１つの構成要素として定義する。サービスプロセスのＣＩモデルは、サービスプロセスの少なくとも１つの所定の属性、及び該サービスプロセスと１以上のサービスステップとの間の関係を示す。所定の属性は例えば、サービスプロセスＣＩ＿ＩＤ、及びサービスプロセス状況である。該関係は例えば、containsである。
サービスステップは、例えばＣＭＤＢの構造を使用してモデル化される（４０３）。該モデルは、例えばサービスプロセスの管理者によって用意されうる。本明細書では、該モデルを、サービスステップのＣＩモデルという場合がある。サービスステップのＣＩモデルは、１以上のサービスステップを１つの構成要素として定義する。サービスステップのＣＩモデルは、サービスステップの少なくとも１つの所定の属性、及び該サービスステップと該サービスステップの実行に必要であるリソース（４０４）との関係を示す。所定の属性は例えば、「サービスステップ状況」、「自ＣＩインスタンス化条件」、「インスタンス化タイミング」及び「実サービスステップとの対応」（各実サービスステップＩＤの状況である）である。該関係は例えば、useである。サービスステップのＣＩモデルはさらに、他のサービスステップとの関係を示す。該関係の例は、nextstepである。上記関係は、サービスステップのＣＩモデルをインスタンス化する際に使用される。また、該関係は、他の構成要素、例えば他のサービスステップを見つける条件でもある。
上記リソースは例えば、ヒト、場所、物、サービスを含む（４０４を参照）。各リソースはまた、１つの構成要素である。よって、各リソースは、例えばＣＭＤＢの構造を使用してモデル化される。また、各リソースは、例えばＣＭＤＢ上で管理される。

図５Ａ〜図５Ｄは、サービスプロセス及び各サービスプロセスのＣＩモデルを夫々インスタンス化する本発明の実施形態を示す。
図５Ａは、サービスプロセスのＣＩモデル、及びサービスステップのＣＩモデルの本発明の実施形態を示す。
サービスプロセスのＣＩモデル（５０１）は、サービスプロセスＡのモデルであることを示す「サービスプロセス定義ＩＤ」を含む。図５Ａの場合、「サービスプロセス定義ＩＤ」は、Ａである。さらに、サービスプロセスのＣＩモデルは、属性「サービスプロセスＣＩ＿ＩＤ」及び「サービスプロセス状況」を含む。「サービスプロセスＣＩ＿ＩＤ」の属性データは例えば、Ａ００１である。「サービスプロセス状況」の属性データは例えば、開始中、実行中、完了である。サービスプロセスのＣＩモデル（５０１）と他のサービスステップのＣＩモデルとの関係は、containsである。
サービスステップの各ＣＩモデル（５０２〜５０５）は、どのサービスステップであるかを特定するための「サービスステップ定義ＩＤ」を含む（図示せず）。さらに、サービスステップのＣＩモデルは、属性「サービスステップ状況」、「自ＣＩインスタンス化条件」、「インスタンス化タイミング」及び「実サービスステップとの対応」を含む。
「サービスステップ状況」の属性データは例えば、待機中、開始中、完了である。
「自ＣＩインスタンス化条件」の属性データは例えば、該サービスステップを実行する際に必要とされるリソース、すなわちＣＩを検索し、特定するための条件の記述である。該条件は例えば、ＣＩの種類、数、時間、利用可能なＣＩ、目的とするＣＩが見つからない場合の代替リソースである。
「インスタンス化タイミング」の属性データは例えば、プロセスステップのＣＩモデルをいつインスタンス化するかの条件の記述である。「いつインスタンス化するか」とは例えば、該プロセスステップに自ＣＩインスタンス化条件で特定されたリソースの割り当てをいつ決定するかである。該条件は例えば、前段のサービスステップが完了（図５Ａの「前ステップＣＩ完了」）、又は前段のサービスステップのＣＩをインスタンス後（図５Ａの「前ステップＣＩ作成後」）である。
「実サービスステップとの対応」の属性データは例えば、各実サービスステップの状況を示す「実サービスステップＩＤの状況」である。実サービスステップＩＤは、図５ＡのサービスプロセスＡの定義における実サービスステップＩＤ１〜５に対応する。実サービスステップＩＤの状況」の属性データは例えば、待機中、開始中、実行中、完了である。サービスステップのＣＩモデル（５０２）は、サービスプロセスＡの定義における「実サービスステップＩＤ １の状況」を含む。同様に、サービスステップのＣＩモデル（５０３）は、「実サービスステップＩＤ ２の状況」及び「実サービスステップＩＤ ３の状況」を含む。同様に、サービスステップのＣＩモデル（５０４）は、「実サービスステップＩＤ ４の状況」を含む。同様に、サービスステップのＣＩモデル（５０５）は、「実サービスステップＩＤ ５の状況」を含む。
サービスステップのＣＩモデル（５０２）とサービスステップのＣＩモデル（５０３）との関係は、nextstepである。同様に、サービスステップのＣＩモデル（５０３）とサービスステップのＣＩモデル（５０４）との関係、及びサービスステップのＣＩモデル（５０３）とサービスステップのＣＩモデル（５０５）との関係は、いずれもnextstepである。

図５Ｂは、サービスプロセスのＣＩモデル（５０１）のインスタンス化及び最初のサービスステップのＣＩモデル（５０２）のインスタンス化の本発明の実施形態を示す。
サービスプロセス状況管理部（図示せず）は、サービスＡのサービス要求を確認する。該サービス要求に応じて、サービスプロセス状況管理部は、サービスプロセスのＣＩモデル（５０２）をインスタンス化することをＣＩインスタンス作成部（図示せず）に伝える。ＣＩインスタンス作成部は、サービスプロセスのＣＩモデル（５０２）をインスタンス化する。該インスタンス化において、ＣＩインスタンス作成部は、該サービスプロセスのＣＩモデル（５０１）とサービスステップの各ＣＩモデル（５０２、５０３、５０４、５０５）との定義された関係（contains）を見つける。
ＣＩインスタンス作成部は、サービスプロセスのＣＩモデル（５０１）がインスタンス化されることに応じて、最初のサービスステップのＣＩモデル（５０２）（以下、ＣＩモデル（５０２）という）をインスタンス化することを開始する。この時点で、次のサービスプロセスのＣＩモデル（５０３）（以下、ＣＩモデル（５０３）という）の「インスタンス化タイミング」は、「前ステップＣＩ作成後」であるので、ＣＩインスタンス作成部は、ＣＩモデル（５０３）のインスタンス化を開始しない。ＣＩインスタンス作成部は、ＣＩモデル（５０２）に定義された「自ＣＩインスタンス化条件」に従い、サービスプロセスの実行に必要なリソース、即ち必要な関連ＣＩがあるかどうかを判定する。必要な関連ＣＩがある場合、ＣＩインスタンス作成部は、該サービスプロセスの関連ＣＩを検出する要求を関連ＣＩディスカバリ部に送信する。関連ＣＩディスカバリ部は、関連ＣＩをＣＭＤＢ（５０６）又は関連ＣＩディスカバリ部の検出対象を検出して、関連ＣＩについてのデータを取得する。ＣＩインスタンス作成部は、該取得したデータに基づいて必要な関連ＣＩのＣＩモデルをインスタンス化し、そして関連ＣＩのＣＩインスタンスをＣＭＤＢ内に格納する。そして、ＣＩインスタンス作成部は、関連ＣＩのＣＩインスタンスを使用して、ＣＩモデル（５０２）のインスタンス化を完了する。
サービスプロセス状況管理部は、ＣＩモデル（５０３）をインスタンス化することが可能になるまで待機する。ＣＩモデル（５０３）をインスタンス化することが可能になることは、ＣＩモデル（５０３）の「インスタンス化タイミング」に定義されている。ＣＩモデル（５０３）の「インスタンス化タイミング」は「前ステップＣＩ作成後」であるので、ＣＩモデル（５０２）のインスタンス化が完了するまで、ＣＩモデル（５０３）のインスタンス化は開始されない。なお、ＣＩモデル（５０２）を「前段」のＣＩモデルとした場合、ＣＩモデル（５０３）を「後段」のＣＩモデルという。また、かかる場合、ＣＩモデル（５０２）のサービスステップは「前段」のサービスステップであり、ＣＩモデル（５０３）は「後段」のサービスステップである。

図５Ｃは、次のサービスステップのＣＩモデルのインスタンス化の本発明の実施形態を示す。
サービスプロセス状況管理部は、ＣＩモデル（５０２）のインスタンス化が完了したことを確認する。該確認は例えば、ＣＩインスタンス作成部が、サービスプロセス状況管理部にＣＩモデル（５０２）のインスタンス化が完了したことを通知することによって行われる。
サービスプロセス状況管理部は、ＣＩモデル（５０３）をインスタンス化することをＣＩインスタンス作成部に伝える。上記と同様に、ＣＩインスタンス作成部は、ＣＩモデル（５０３）のインスタンス化を開始する。この時点で、次のサービスプロセスのＣＩモデル（５０４）（以下、ＣＩモデル（５０４）という）及び次のサービスプロセスのＣＩモデル（５０５）（以下、ＣＩモデル（５０５）という）の「インスタンス化タイミング」は夫々、「前ステップ完了」であるので、ＣＩインスタンス作成部は、ＣＩモデル（５０３）のインスタンス化を開始しない。ＣＩインスタンス作成部は、ＣＩモデル（５０３）に定義された「自ＣＩインスタンス化条件」に従い、サービスプロセスの実行に必要なリソース、即ち必要な関連ＣＩを特定する。必要な関連ＣＩがある場合、ＣＩインスタンス作成部は、該サービスプロセスの関連ＣＩを検出する要求を関連ＣＩディスカバリ部に送信する。関連ＣＩディスカバリ部は、関連ＣＩをＣＭＤＢ（５０７）又は関連ＣＩディスカバリ部の検出対象をディスカバリして、必要なデータを取得する。ＣＩインスタンス作成部は、該取得したデータに基づいて必要な関連ＣＩのＣＩモデルをインスタンス化し、そしてＣＭＤＢ内に格納する。そして、ＣＩインスタンス作成部は、ＣＩモデル（５０３）のインスタンス化を完了する。なお、ＣＩモデル（５０３）を「前段」のＣＩモデルとした場合、ＣＩモデル（５０４）及び（５０５）夫々を「後段」のＣＩモデルという。また、かかる場合、ＣＩモデル（５０３）のサービスステップは「前段」のサービスステップであり、ＣＩモデル（５０４）及び（５０５）夫々は「後段」のサービスステップである。

図５Ｄは、次のサービスステップのＣＩモデルのインスタンス化の本発明の実施形態を示す。
サービスプロセス状況管理部は、ＣＩモデル（５０３）のサービスステップが完了したことを確認する。該確認は例えば、サービスプロセス状況管理部自身が、ＣＩモデル（５０３）のサービスステップが完了したことを確認することによって行われる。
サービスプロセス状況管理部は、ＣＩモデル（５０４）又はＣＩモデル（５０５）のいずれかをインスタンス化することをＣＩインスタンス作成部に伝える。いずれのＣＩモデルをインスタンス化するかは、サービスプロセス状況管理部が、サービスプロセスがどちらの分岐に進むかを判断して決定する（図５ＡのサービスプロセスＡの定義を参照）。図５Ｃでは、分岐がＣＩモデル（５０４）に関連付けられたサービスプロセスに進むことから、ＣＩインスタンス作成部は、ＣＩモデル（５０４）のインスタンス化を開始する。ＣＩインスタンス作成部は、ＣＩモデル（５０４）に定義された「自ＣＩインスタンス化条件」に従い、サービスプロセスの実行に必要なリソース、即ち必要な関連ＣＩを特定する。必要な関連ＣＩがある場合、ＣＩインスタンス作成部は、該サービスプロセスの関連ＣＩを検出する要求を関連ＣＩディスカバリ部に送信する。関連ＣＩディスカバリ部は、関連ＣＩをＣＭＤＢ（５０８）又は関連ＣＩディスカバリ部の検出対象をディスカバリして、必要なデータを取得する。ＣＩインスタンス作成部は、該取得したデータに基づいて必要な関連ＣＩのＣＩモデルをインスタンス化し、そしてＣＭＤＢ内に格納する。そして、ＣＩインスタンス作成部は、ＣＩモデル（５０４）のインスタンス化を完了する。

図６Ａ〜図６Ｃは、前段のプロセスステップの結果によって、後段のプロセスステップのインスタンス化条件が変化する場合を示す。
図６Ａは、後段のＣＩモデル（６０３）のインスタンス化条件（以下、後段のＣＩインスタンス化条件）が、前段のＣＩモデル（６０２）のサービスステップ（以下、前段のサービスステップという）の結果によって決定されることを示す。ＣＩインスタンス作成部は、後段のＣＩインスタンス化条件を、前段のＣＩモデル（６０２）のサービスステップ完了時までに決定する。ＣＩインスタンス作成部は、後段のＣＩインスタンス化条件をＣＩモデル（６０２）と同じモデル内に定義しうる。或いは、ＣＩインスタンス作成部は、後段のＣＩインスタンス化条件をＣＩモデル（６０２）と別のデーブル（６０４）内に定義しうる。前者の場合、後段のＣＩインスタンス化条件は、ＣＩモデル（６０２）の属性として定義される。後者の場合、後段のＣＩインスタンス化条件は、ＣＩモデル（６０２）が該テーブルとリンク付けされてもよい。

図６Ｂは、ＣＩインスタンス作成部が、モデル（６０３）をインスタンス化する際に、後段のＣＩインスタンス化条件を参照することを示す。
ＣＩインスタンス作成部は、モデル（６０３）のインスタンス化を、モデル（６０３）の「インスタンス化タイミング」に定義された「前ステップ完了後」に行う。ＣＩインスタンス作成部は、モデル（６０３）をインスタンス化する際に、後段のＣＩインスタンス化条件（例えば６０４）を参照する（required）。

図６Ｃは、ＣＩインスタンス作成部が、モデル（６０３）をインスタンス化することを示す。
ＣＩインスタンス作成部は、モデル（６０３）をインスタンス化する際に、モデル（６０３）の自インスタンス化条件と、上記参照した後段のＣＩインスタンス化条件に従い、モデル（６０３）のサービスステップ実行のためのリソース（６０６）を検出する。ＣＩインスタンス作成部は、該検出したリソースについてのデータを使用して、該モデル（６０３）のインスタンス化を行う。

図７Ａ〜図７Ｄは、本発明の実施形態のシステムの例を示す。
図７Ａは、該システムが、サービスプロセス制御部（７０３）、サービスプロセス定義リポジトリ（７０４）、サービスプロセス実行部（７０５）、ＣＭＤＢ（７０７）、モデル・テーブル（７０８）、サービスプロセス状況管理部（７０９）、関連ＣＩディスカバリ部（７１０）、ＣＩインスタンス作成部（７１１）及びディスカバリ部（７１２）を含むことを示す。
サービスプロセス作成者（７０１）は、サービスプロセス及び該サービスプロセスに含まれる複数のサービスステップを定義し、サービスプロセス定義（７０２）を作成する。サービスプロセス作成者（７０１）は、該サービスプロセス定義（７０２）をサービスプロセス制御部（７０３）内のサービスプロセス定義リポジトリ（７０４）に格納する。サービスプロセス定義リポジトリ（７０４）は、サービスプロセス制御部（７０３）にネットワークを介して接続されていてもよい。サービスプロセス制御部（７０３）は、サービスプロセスを実行するためのサービスプロセス実行部（７０５）を含む。
サービスプロセス作成者（７０１）はまた、サービスプロセスのＣＩモデル（７０６）及び該サービスプロセスに含まれる複数のサービスステップのＣＩモデル（７０６）を作成する。サービスプロセス作成者（７０１）は、該ＣＩモデルをモデル・テーブル（７０８）に格納する。

図７Ｂは、本発明の実施形態のサービスプロセス状況管理部（７０９）と他の要素との関係を示す。
サービスプロセス状況管理部（７０９）は、サービスプロセスの状況を取得し、ＣＭＤＢ（７０７）内に格納されたサービスプロセスＣＩインスタンス、及びサービスステップＣＩインスタンスの属性値及び関係値を更新する。該更新は、例えば実環境、又は進捗管理データベース（図示せず）をディスカバリして、サービスプロセスの状況を取得する方法、又はサービスプロセス実行部と同期する方法により実現される。サービスプロセス状況管理部（７０９）はまた、特定のサービスプロセスのＣＩモデルのインスタンス化の完了の後に、次のサービスステップのＣＩモデルのインスタンス化が可能かどうかを判断する。

図７Ｃは、本発明の実施形態の関連ＣＩディスカバリ部（７１０）と他の要素との関係を示す。
関連ＣＩディスカバリ部（７１０）は、サービスステップのＣＩモデルがインスタンス化された際に、サービスステップの実行に必要となるリソース、即ち必要な関連ＣＩを検出し、該検出したリソースとサービスステップとの関係を作成する。該検出は、ＣＭＤＢ（７０７）又は関連ＣＩディスカバリ部の管理対象である実機器などの管理対象（７１４）へディスカバリを実行することによって実現される。関連ＣＩディスカバリ部（７１０）はまた、該検出した関連ＣＩについての情報から、関連ＣＩのＣＩモデルをインスタンス化してもよい。或いは、関連ＣＩディスカバリ部（７１０）は、該検出した関連ＣＩについての情報から、関連ＣＩのＣＩモデルをインスタンス化することを、ＣＩインスタンス作成部（７１１）に要求してもよい。

図７Ｄは、本発明の実施形態のＣＩインスタンス作成部（７１１）と他の要素との関係を示す。
ＣＩインスタンス作成部（７１１）は、サービスプロセスが実行された時点で、サービスプロセスのＣＩモデルのインスタンス化を行う。ＣＩインスタンス作成部（７１１）はまた、サービスステップの状況に応じて、サービスステップのＣＩモデルのインスタンス化を行う。なお、サービスプロセス状況管理部によって、最初にサービスプロセスの実行が確認された場合、ＣＩインスタンス作成部（７１１）は、サービスプロセス及び最初のサービスステップの各ＣＩのＣＩモデルのインスタンス化を行う。

図８は、本発明の実施形態における、サービスプロセス及びサービスステップの各ＣＩのＣＩモデルをインスタンス化するフローチャートを示す。
サービスプロセス状況管理部（７０９）は、サービス要求を確認する（８０１）。該サービス要求に応じて、サービスプロセス状況管理部は、サービスプロセスのＣＩモデルをインスタンス化することをＣＩインスタンス作成部（７１１）に要求する。
ＣＩインスタンス作成部（７１１）は、サービスプロセスのＣＩモデルをインスタンス化する（８０２）。ＣＩインスタンス作成部（７１１）は、サービスプロセスのＣＩモデルがインスタンス化されることに応じて、最初のサービスステップのＣＩモデルをインスタンス化することを開始する（８０３）。ＣＩインスタンス作成部（７１１）は、該ＣＩモデルに定義された「自ＣＩインスタンス化条件」に従い、サービスプロセスの実行に必要なリソース、即ち必要な関連ＣＩがあるかどうかを判定する。必要な関連ＣＩがある場合、ＣＩインスタンス作成部（７１１）は、関連ＣＩディスカバリ部（７１０）に必要な関連ＣＩを検出することを要求する（８０５）。ＣＩインスタンス作成部（７１１）は、該検出した関連ＣＩについての情報から、関連ＣＩのＣＩモデルをインスタンス化する（８０６）。或いは、関連ＣＩディスカバリ部（７１０）は、該検出した関連ＣＩについての情報から、関連ＣＩのＣＩモデルをインスタンス化することを、ＣＩインスタンス作成部（７１１）に要求してもよい。該インスタンス化によって、関連ＣＩのＣＩインスタンスが作成される。必要な関連ＣＩが無い場合、次のステップ（８０７）に進む。
ＣＩインスタンス作成部（７１１）は、必要な関連ＣＩがある場合、関連ＣＩのＣＩインスタンスを使用してサービスステップのＣＩモデルのインスタンス化を終了する（８０７）。ＣＩインスタンス作成部（７１１）は、サービスステップのＣＩモデルのインスタンス化が終了したことをサービスプロセス状況管理部に伝える。
サービスプロセス状況管理部は、次のサービスプロセスのＣＩモデルの「インスタンス化タイミング」に定義された条件に従い、次のサービスプロセスをインスタンス化することを繰り返す（８０８）。

図９Ａ〜図９Ｆは、本発明の実施形態であるインシデント解決プロセスに含まれるサービスステップのＣＩモデルのインスタンス化を示す。
図９Ａは、インシデント解決プロセス（ＩＤ００１）及び該解決プロセス（ＩＤ００１）に含まれるサービスステップ（９０１〜９０７）を示す。
インシデント解決プロセス（ＩＤ００１）の識別子は、ＩＤ００１である。インシデント解決プロセス（ＩＤ００１）は、現在作業中のサービスプロセスである。
インシデント解決プロセス（ＩＤ００１）に含まれるサービスステップは、「インシデントが報告される」（９０１）、「サービスデスクが受け取る」（９０２）、「状況の調査を行う」（９０３）、「修理・修繕（Ｆｉｘ）の作成を行う」（９０４）、「Ｆｉｘの適用承認をとる」（９０５）、「Ｆｉｘを適用する」（９０６）、及び「インシデントをクローズする」（９０７）である。
サービスステップ９０２は、構成要素、サービス窓口担当者（９１５）と関係を有する。
サービスステップ９０３は、構成要素、対象機器（９１６）及びサポートエンジニア（９１７）と関係を有する。
サービスステップ９０４は、構成要素、開発者（９１８）、開発用機器（９１９）及び開発サービス（９２０）と関係を有する。
サービスステップ９０５は、構成要素、承認者（９２１）と関係を有する。
サービスステップ９０６は、構成要素、作業員（９２２）及び対象機器（９２３）と関係を有する。
図９Ａでは、ＣＩインスタンス作成部（７１１）が、インシデント解決プロセス（ＩＤ００１）ＣＩモデル及び該インシデント解決プロセス（ＩＤ００１）におけるサービスステップ（９０１〜９０３）のＣＩモデルをすでにインスタンス化している（実線）。また、インシデント解決プロセス（ＩＤ００１）では、ＣＩインスタンス作成部（７１１）が、サービスステップ「Ｆｉｘの作成を行う」（９０４）のＣＩモデルをインスタンス化している途中である。サービスステップ９０４は、開発者（９１８）及び開発用機器（９１９）と現在ｕｓｅ関係にある。ＣＩインスタンス作成部（７１１）は、インシデント解決プロセス（ＩＤ００１）のサービスステップ（９０５〜９０７）のＣＩモデルをまだインスタンス化していない（破線）。
図９Ａはさらに、インシデント解決プロセス（ＩＤ００２）及び該解決プロセス（ＩＤ００２）に含まれるサービスステップ（９０８〜９１４）を示す。
インシデント解決プロセス（ＩＤ００２）の識別子は、ＩＤ００２である。インシデント解決プロセス（ＩＤ００２）は、インシデント解決プロセス（ＩＤ００１）とは別個のインシデント解決プロセスであり、新規に開始されたサービスプロセスである。
インシデント解決プロセス（ＩＤ００２）に含まれるサービスステップは、「インシデントが報告される」（９０８）、「サービスデスクが受け取る」（９０９）、「状況の調査を行う」（９１０）、「修理・修繕（Ｆｉｘ）の作成を行う」（９１１）、「Ｆｉｘの適用承認をとる」（９１２）、「Ｆｉｘを適用する」（９１３）、及び「インシデントをクローズする」（９１４）である。
サービスステップ９０９は、構成要素、サービス窓口担当者（９１５）と関係を有する。
サービスステップ９１０は、構成要素、対象機器（９１６）及びサポートエンジニア（９１７）と関係を有する。
サービスステップ９１１は、構成要素、開発者（９１８）、開発用機器（９１９）及び開発サービス（９２０）と関係を有する。
サービスステップ９１２は、構成要素、承認者（９２１）と関係を有する。
サービスステップ９１３は、構成要素、作業員（９２２）及び対象機器（９２３）と関係を有する。
図９Ａでは、ＣＩインスタンス作成部（７１１）が、インシデント解決プロセス（ＩＤ００２）のＣＩモデル及び該インシデント解決プロセス（ＩＤ００２）におけるサービスステップ（９０８）のＣＩモデルをすでにインスタンス化している（実線）。また、インシデント解決プロセス（ＩＤ００２）では、ＣＩインスタンス作成部（７１１）が、サービスステップ「サービスデスクが受け取る」（９０９）のＣＩモデルをインスタンス化している途中である。サービスステップ９０９は、サービス窓口担当者（９１５）と現在ｕｓｅ関係にある。ＣＩインスタンス作成部（７１１）は、インシデント解決プロセス（ＩＤ００２）におけるサービスステップ（９１０〜９１４）のＣＩモデルをまだインスタンス化していない（破線）。

図９Ｂは、ＣＩインスタンス作成部（７１１）が、現在、インシデント解決プロセス（ＩＤ００２）におけるサービスプロセス（９０９）のＣＩモデルをインスタンス化していることを示す。ＣＩインスタンス作成部（７１１）は、前段のサービスステップ（９０８）のＣＩモデルのインスタンス化において、後段のサービスステップ（９０９）のＣＩモデルのＣＩインスタンス化条件を決定する。該ＣＩモデルの「自インスタンス化条件」は、対象機器（９１６）及び問題タイプを条件指定する。ＣＩインスタンス作成部（７１１）は、後段のＣＩインスタンス化条件をサービスステップ（９０８）のＣＩモデルと同じモデル内に定義しうる。或いは、ＣＩインスタンス作成部（７１１）は、後段のＣＩインスタンス化条件をサービスステップ（９０８）のＣＩモデルと別のデーブル内に定義しうる。

図９Ｃは、インシデント解決プロセス（ＩＤ００２）における後段のサービスステップ（９０９）のＣＩモデルをインスタンス化する際に、ＣＩインスタンス作成部（７１１）が、上記後段のＣＩインスタンス化条件を参照することを示す。ＣＩインスタンス作成部（７１１）は、後段のサービスステップのＣＩモデルの自インスタンス化条件と、上記参照した後段のＣＩインスタンス化条件に従い、後段のサービスステップ（９０９）のＣＩモデルをインスタンス化する。

図９Ｄは、インシデント解決プロセス（ＩＤ００１）におけるサービスステップ（９０４）のＣＩモデルのインスタンス化及びインシデント解決プロセス（ＩＤ００２）におけるサービスステップ（９１１）のＣＩモデルのインスタンス化において、必要な関連ＣＩが互いに衝突することを示す。
インシデント解決プロセス（ＩＤ００１）におけるサービスステップ（９０４）のＣＩモデルは、開発者（９１８）及び開発用機器（９１９）と関係を有する。同様に、インシデント解決プロセス（ＩＤ００２）におけるサービスステップ（９１１）のＣＩモデルは、開発者（９１８）及び開発用機器（９１９）と関係を有する。よって、新規に開始されたインシデント解決プロセス（ＩＤ００２）におけるサービスステップ（９１１）のＣＩモデルをインスタンス化する際に必要な関連ＣＩ、すなわち開発者（９１８）及び開発用機器（９１９）が、インシデント解決プロセス（ＩＤ００１）におけるサービスステップ（９０４）のＣＩモデルをインスタンス化する際に必要な関連ＣＩと衝突する。よって、ＣＩインスタンス作成部（７１１）は、インシデント解決プロセス（ＩＤ００２）におけるサービスステップ（９１１）のＣＩモデルをインスタンス化する際に、開発者（９１８）及び開発用機器（９１９）と同等のサービスを提供する他の構成要素、例えば他の開発者及び他の開発用機器を検出する。ＣＩインスタンス作成部（７１１）は、該検出した他の構成要素についての情報を使用してサービスステップ（９１１）のＣＩモデルをインスタンス化する。

図９Ｅは、ＣＩインスタンス作成部（７１１）が、現在、インシデント解決プロセス（ＩＤ００２）におけるサービスプロセス（９１２）及びサービスプロセス（９１３）のＣＩモデルをインスタンス化していることを示す。サービスプロセス（９１２）は、承認ステップである。ＣＩインスタンス作成部（７１１）は、サービスプロセス（９１２）のＣＩモデルをインスタンス化し、承認者（９２１）を決定して承認を進めると同時に、その後段のサービスプロセス（９１３）のＣＩモデルをインスタンス化する。後段のサービスプロセス（９１３）のＣＩモデルをインスタンス化する際に、関連ＣＩディスカバリ部は、作業員（９２２）及び対象機器（９１３）についての情報を検出する。ＣＩインスタンス作成部（７１１）は、該検出した作業員（９２２）及び対象機器（９２３）についての情報を使用して、サービスプロセス（９１３）のＣＩモデルをインスタンス化する。該インスタンス化によって、適切な作業員及び適切な対象機器が選択される。

図９Ｆは、ＣＩインスタンス作成部（７１１）が、現在、インシデント解決プロセス（ＩＤ００２）におけるサービスプロセス（９１４）のＣＩモデルをインスタンス化していることを示す。サービスプロセス（９１４）のＣＩモデルのインスタンス化が完了すると、インシデント解決プロセスのサービスステップのＣＩモデルのインスタンス化が終了する。

上記実施形態のコンピュータ・システムにおいて使用されるコンピュータは、ＣＰＵとメイン・メモリと含み、これらはバスに接続されている。ＣＰＵは好ましくは、３２ビットまたは６４ビットのアーキテクチャに基づくものであり、例えば、インテル社のＸｅｏｎ（商標）シリーズ、Ｃｏｒｅ（商標）シリーズ、Ｐｅｎｔｉｕｍ（商標）シリーズ、Ｃｅｌｅｒｏｎ（商標）シリーズ、ＡＭＤ社のＰｈｅｎｏｍ（商標）シリーズ、Ａｔｈｌｏｎ（商標）シリーズなどを使用することができる。バスには、ディスプレイ・コントローラを介して、ＬＣＤモニタなどのディスプレイが接続される。ディスプレイは、コンピュータ・システムの管理のために、通信回線を介してネットワークに接続されたコンピュータについての情報と、そのコンピュータ上で動作中のソフトウェアについての情報を、適当なグラフィック・インターフェースで表示するために使用される。バスにはまた、ＩＤＥ又はＳＡＴＡコントローラを介して、ハードディスク又はシリコン・ディスクと、ＣＤ−ＲＯＭ又はＤＶＤドライブが接続される。

ハードディスクには、オペレーティング・システム、Ｊ２ＥＥなどのＪａｖａ処理環境を提供するプログラム、ＣＭＤＢのための運用管理プログラム、その他のプログラム及びデータが、メイン・メモリにロード可能に記憶されている。運用管理プログラムは好ましくは、インターナショナル・ビジネス・マシーンズ・コーポレーションから提供されるＴＡＤＤＭ（Tivoli（商標）Application Dependency Discovery Manager）を含む。

ＣＤ−ＲＯＭ又はＤＶＤドライブは、必要に応じて、ＣＤ−ＲＯＭ又はＤＶＤからプログラムをハードディスクに追加導入するために使用される。バスには更に、キーボード・マウスコントローラを介して、キーボード及びマウスが接続されている。

通信インタフェースは、例えばイーサネットプロトコルに従うものであり、通信コントローラを介してバスに接続され、コンピュータ及び通信回線を物理的に接続する役割を担い、コンピュータのオペレーティング・システムの通信機能のＴＣＰ／ＩＰ通信プロトコルに対して、ネットワーク・インターフェース層を提供する。尚、通信回線は、有線ＬＡＮ環境、或いは例えばＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎなどの無線ＬＡＮ接続規格に基づく無線ＬＡＮ環境であってもよい。

なお、コンピュータ等のハードウェアを接続するためのネットワーク接続装置として使用できるものとして、上記のネットワーク・スイッチ以外に、これで尽きている訳ではないが、ルータ、ハードウェア管理コンソール等がある。要するに、ネットワーク運用管理用プログラムが導入されているコンピュータからの、所定のコマンドによる問合せに対して、それに接続されているコンピュータのＩＰアドレス、ＭＡＣアドレスなどの構成情報を返すことができる機能をもつものである。ネットワーク・スイッチ及びルータは、アドレス解決プロトコル（ＡＲＰ）のための、それに接続されているコンピュータのＩＰアドレス及び、それに対応するＭＡＣアドレスの対のリストを含むＡＲＰテーブルを含み、所定のコマンドによる問合せに対して、ＡＲＰテーブルの内容を返す機能をもつ。ハードウェア管理コンソールは、ＡＲＰテーブルよりも更に詳しい、コンピュータの構成情報を返すことができる。

コンピュータには、上述したハードウェア管理コンソールが接続されている。これは、コンピュータで、ＬＰＡＲ（仮想論理区画）により一台のコンピュータを複数の区画に論理分割し、その各々の区画で、ＶＭｗａｒｅにより、Ｗｉｎｄｏｗｓ（商標）、Ｌｉｎｕｘ（商標）などの異なるＯＳを走らせるようにする機能を有するものである。ハードウェア管理コンソールにシステム的に問い合わせすることにより、ＬＰＡＲ・ＶＭｗａｒｅで動作しているコンピュータの個々の論理区画での情報を、詳細に得ることができる。

以上、実施形態に基づき本発明を説明してきたが、本実施形態に記載されている内容は、本発明の一例であり、当業者なら、本発明の技術的範囲を逸脱することなく、さまざまな変形例に想到できることが、明らかであろう。例えば、ＣＭＤＢとそれに格納されたＣＩではなく、別の形式のデータベースとＣＩの形式を用いることもできる。また、Ｊａｖａ以外に、Ｃ＋＋、Ｃ＃など、ネットワーク管理機能をもつＡＰＩを呼び出すことのできる任意のコンピュータ開発環境を用いることができる。

ＣＭＤＢを含むコンピュータ・システムの例を示す。 機器Ａ及び機器Ｂの各ＣＩインスタンス、及びその関係インスタンスの作成を示す。 データ・モデル、ディスカバリ・インスタンス、ＣＩインスタンス、及び関係モデルを示す。 サービスＡについてのサービスプロセスの従来の処理を示す。 サービスプロセス及び各サービスプロセスを夫々モデル化する本発明の実施形態を示す。 サービスプロセス及び各サービスプロセスのＣＩモデルを夫々インスタンス化する本発明の実施形態を示す。 サービスプロセスのＣＩモデルのインスタンス化及び最初のサービスステップのＣＩモデルのインスタンス化の本発明の実施形態を示す。 次のサービスステップのＣＩモデルのインスタンス化の本発明の実施形態を示す。 次のサービスステップのＣＩモデルのインスタンス化の本発明の実施形態を示す。 前段のプロセスステップの結果によって、後段のプロセスステップのインスタンス化条件が変化する場合（１／３）を示す。 前段のプロセスステップの結果によって、後段のプロセスステップのインスタンス化条件が変化する場合（２／３）を示す。 前段のプロセスステップの結果によって、後段のプロセスステップのインスタンス化条件が変化する場合（３／３）を示す。 本発明の実施形態のシステムの例を示す。 本発明の実施形態のサービスプロセス状況管理部と他の要素との関係を示す。 本発明の実施形態の関連ＣＩディスカバリ部と他の要素との関係を示す。 本発明の実施形態のＣＩインスタンス作成部と他の要素との関係を示す。 本発明の実施形態における、サービスプロセス及びサービスステップの各ＣＩをインスタンス化するフローチャートを示す。 本発明の実施形態であるインシデント解決プロセスに含まれるサービスステップのＣＩモデルのインスタンス化（１／６）を示す。 本発明の実施形態であるインシデント解決プロセスに含まれるサービスステップのＣＩモデルのインスタンス化（２／６）を示す。 本発明の実施形態であるインシデント解決プロセスに含まれるサービスステップのＣＩモデルのインスタンス化（３／６）を示す。 本発明の実施形態であるインシデント解決プロセスに含まれるサービスステップのＣＩモデルのインスタンス化（４／６）を示す。 本発明の実施形態であるインシデント解決プロセスに含まれるサービスステップのＣＩモデルのインスタンス化（５／６）を示す。 本発明の実施形態であるインシデント解決プロセスに含まれるサービスステップのＣＩモデルのインスタンス化（６／６）を示す。

Claims (25)

1. 複数のサービスステップを含むサービスプロセスを管理するためのコンピュータ・システムであって、
   前記サービスステップの実行に必要であるリソースについてのデータを検出するディスカバリ部と、
   構成要素毎に、該構成要素の少なくとも１つの所定の属性及び他の構成要素との関係を示す１組のデータを保持するリポジトリであって、該１組のデータが、サービスプロセスを１つの構成要素として定義した第１の構成要素モデルを使用して作成されたデータ、及び１以上のサービスステップを１つの構成要素として定義した第２の構成要素モデルを使用して前記検出したデータから作成されたデータである、前記リポジトリと
   を含む、前記コンピュータ・システム。
2. 前記第１の構成要素モデルが、前記サービスプロセスについての少なくとも１つの所定の属性と１以上のサービスステップとの関係を示し、前記第２の構成要素モデルが、前記サービスステップについての少なくとも１つの所定の属性と該サービスステップの実行に必要であるリソースとの関係を示す、請求項１に記載のコンピュータ・システム。
3. 前記第１の構成要素モデルが、前記サービスプロセスを開始した際に実行するサービスステップに関連付けられた第２の構成要素モデルを特定するための属性を含む、請求項１に記載のコンピュータ・システム。
4. 前記第２の構成要素モデルが、該第２の構成要素モデルを使用して１組のデータを作成する条件の属性、及び該第２の構成要素モデルを使用して１組のデータを作成するタイミングの属性を含む、請求項１に記載の方法。
5. 前記第２の構成要素モデルが、同じリソースを利用する複数のサービスステップを１つの構成要素として定義する、請求項１に記載のコンピュータ・システム。
6. 前記第１の構成要素モデルを使用して１組のデータを作成し、及び前記第２の構成要素モデルを使用して前記検出したデータから１組のデータを作成するデータ作成部をさらに含む、請求項１に記載のコンピュータ・システム。
7. 前記ディスカバリ部が前記サービスプロセスの実行に必要であるリソースについてのデータをさらに検出し、及び前記第１の構成要素モデルを使用して作成された１組のデータが前記検出したデータから作成されたデータである、請求項１に記載のコンピュータ・システム。
8. 前記検出したデータを使用して、前記１組のデータを更新するデータ更新部をさらに含む、請求項１に記載のコンピュータ・システム。
9. 前記１組のデータが、前記リソースについての少なくとも１つの所定の属性及び他の構成要素との関係を示すデータである、請求項１に記載のコンピュータ・システム。
10. 前記リソースが、ヒト、場所、物、又はサービスである、請求項１に記載のコンピュータ・システム。
11. 構成要素毎に、該構成要素の少なくとも１つの所定の属性及び他の構成要素との関係を示す１組のデータを保持するリポジトリを含むコンピュータ・システムにおいて、複数のサービスステップを含むサービスプロセスを管理する方法であって、
    前記サービスステップの実行に必要であるリソースについてのデータを検出するステップと、
    サービスプロセスの開始に応じて、サービスプロセスを１つの構成要素として定義した第１の構成要素モデルを使用して１組のデータを作成するステップであって、前記第１の構成要素モデルを使用して作成された該１組のデータが前記リポジトリ内に格納される、前記作成するステップと、
    １以上のサービスステップを１つの構成要素として定義した第２の構成要素モデルを使用して前記検出したデータから１組のデータを作成するステップであって、前記第２の構成要素モデルを使用して作成された該１組のデータが前記リポジトリ内に格納される、前記作成するステップと
    を含む、前記方法。
12. 前記データの検出が、前記リポジトリから又は前記コンピュータ・システムに接続されており且つリソースについてのデータを格納する記録部から行われる、請求項１１に記載の方法。
13. 前記検出したデータから、前記リソースについての少なくとも１つの所定の属性及び他の構成要素との関係を示す１組のデータを作成するステップであって、該作成された該１組のデータが前記リポジトリ内に格納される、前記作成するステップをさらに含む、請求項１１に記載の方法。
14. 前記検出したデータについての１組のデータが前記リポジトリ内に既に格納されているかどうかを判断するステップと、
    該１組のデータが前記リポジトリ内に既に格納されているならば、該格納されている１組のデータの属性値及び関係値を前記検出したデータの属性値及び関係値で更新するステップと、
    該１組のデータが前記リポジトリに格納されていないならば、前記検出したデータから前記１組のデータを作成するステップと
    を含む、請求項１１に記載の方法。
15. 前記第１の構成要素モデルが、前記サービスプロセスについての少なくとも１つの所定の属性と１以上のサービスステップとの関係を示し、前記第２の構成要素モデルが、前記サービスステップについての少なくとも１つの所定の属性と該サービスステップの実行に必要であるリソースとの関係を示す、請求項１１に記載の方法。
16. 前記第１の構成要素モデルが、前記サービスプロセスを開始した際に実行するサービスステップに関連付けられた第２の構成要素モデルを特定するための属性を含む、請求項１１に記載の方法。
17. 前記第２の構成要素モデルを使用して１組のデータを作成するステップが、前記第２の構成要素モデルを特定するための属性から、１組のデータを作成すべきサービスステップを特定するステップをさらに含む、請求項１６に記載の方法。
18. 前記第２の構成要素モデルが、該第２の構成要素モデルを使用して１組のデータを作成する条件の属性を含む、請求項１１に記載の方法。
19. 複数のサービスプロセスのうちの前段の第２の構成要素モデルにおける前記条件が、複数のサービスプロセスのうちの後段の第２の構成要素モデルを使用して１組のデータを作成する条件（以下、後段の条件）を含み、該後段の条件を上記前段のサービスステップが完了するまでに決定するステップをさらに含む、請求項１８に記載の方法。
20. 前記後段の第２の構成要素モデルを使用して１組のデータを作成するステップが、前記後段の条件と該後段のための第２の構成要素モデルにおいて定義された１組のデータを作成する条件とを使用して該１組のデータを作成するステップを含む、請求項１９に記載の方法。
21. 前記第２の構成要素モデルが、該第２の構成要素モデルを使用して１組のデータを作成するタイミングの属性を含む、請求項１１に記載の方法。
22. サービスステップが複数のサービスプロセスのうちの最初のサービスステップである場合、前記タイミングは、前記第１の構成要素モデルを使用して１組のデータが作成された後であり、
    サービスステップが複数のサービスプロセスのうちの２回目以降のサービスステップである場合、前記タイミングは、前段のサービスステップについての１組のデータが作成された後であるか、又は前段のサービスステップが完了した後である、請求項２１に記載の方法。
23. 複数のサービスステップを含むサービスプロセスを管理するためのコンピュータ・システムであって、
    前記サービスステップの実行に必要であるリソースについてのデータを検出するディスカバリ部と、
    構成要素毎に、該構成要素の少なくとも１つの所定の属性及び他の構成要素との関係を示す１組のデータを保持するリポジトリと、
    前記検出したデータから前記１組のデータを作成する際に使用されるモデルを格納した記録部であって、前記モデルが、サービスプロセスを１つの構成要素として定義した第１の構成要素モデルと、１以上のサービスステップを１つの構成要素として定義した第２の構成要素モデルとを含む、前記記録部と
    を含む、前記コンピュータ・システム。
24. 構成要素毎に、該構成要素の少なくとも１つの所定の属性及び他の構成要素との関係を示す１組のデータを保持するリポジトリに接続されることができるコンピュータ・システムにおいて、複数のサービスステップを含むサービスプロセスを管理する方法であって、
    サービスプロセスの開始に応じて、サービスプロセスを１つの構成要素として定義した第１の構成要素モデルを使用して１組のデータを作成するステップであって、該作成された１組のデータが前記リポジトリ内に格納される、前記作成するステップと、
    １以上のサービスステップを１つの構成要素として定義した第２の構成要素モデルを使用して１組のデータを作成するステップであって、該作成するステップが、前記サービスステップの実行に必要であるリソースについてのデータを検出するステップと、該検出したデータから前記１組のデータを作成するステップと、該作成された１組のデータを前記リポジトリ内に格納するステップとを含む、前記作成するステップと
    を含む、前記方法。
25. 構成要素毎に、該構成要素の少なくとも１つの所定の属性及び他の構成要素との関係を示す１組のデータを保持するリポジトリを含むコンピュータ・システムにおいて、複数のサービスステップを含むサービスプロセスを管理するためのコンピュータ・プログラムであって、前記コンピュータ・システムに、請求項１１〜２２のいずれか一項に記載の各ステップを実行させるコンピュータ・プログラム。

Images