IBM サービス・マネジメントを支える構成管理データベース・アーキテクチャー

本稿では、IBM Tivoli® Change and Configuration Management Database (CCMDB) のアーキテクチャーを紹介します。その主な機能として、豊富なデータ・モデル、構成アイテムの対象となるデータの自動発見、構成アイテムとアプリケーションの依存関係の可視化、およびマルチカスタマー・サポートが挙げられます。ここでは、関係管理、コンポジット (複合) 構成アイテム、データ・フェデレーション (連合化)、さまざまなソースからのデータのリコンシリエーション (整合化)、マルチカスタマー・サポートのためのセキュリティー・モデル、変更管理プロセスと構成管理プロセスの統合などの実装のトピックについて説明します。

Information Technology Infrastructure Library** (ITIL**) ^1,2 は、質の高い情報技術 (IT) サービスを提供するためのよく知られている一連のベスト・プラクティスのガイドラインです。構成管理、問題管理、インシデント管理、変更管理、サービス・ヘルプ・デスク、およびリリース管理が、ベスト・プラクティスのサービス・サポート・グループの基本的な手順を構成しています。

構成管理は、構成に関連するすべてのデータを構成管理データベースまたは CMDB（Configuration Management Database） として知られている単一のリポジトリー上に配置することを意味します。CMDB は統合データベースまたはフェデレーテッド・データベースのいずれかである、単一のユーザー・インターフェースを提供するデータベースの集合です。このデータベースには、構成アイテム (CI：configuration item) とその属性および構成アイテム間の関係についての詳細が含まれています。

CMDB の実装を成功させるには、以下の要件を満たす必要があります。

1. 豊富なデータ・モデル—データ・モデルは、すべての IT エンティティーとその関係をサポートする必要があります。これらの IT エンティティーには、コンピューターやデバイスなどの物理的なエンティティーと、ソフトウェア・アプリケーションやビジネス・プロセスなどの論理的なエンティティーがあります。
2. CI 情報の自動発見と変更が生じた場合の追跡—生産性を高めるには、手作業によりデータを入力しなければならないようにすることが重要です。大規模な企業は、通常、多くのツールとアプリケーションに依存しており、その構成データはさまざまなリポジトリーに保管されています。結果として、CMDB はさまざまなソースからのデータの整合化にも対応できなければなりません。
3. CI とアプリケーションの依存関係の可視化—今日の IT 環境の複雑さに対応するには、ビジネスをサポートする各アプリケーションが CI にどのように依存しているかをお客様が認識している必要があります。CMDB がそれらの依存関係を可視化し、表示できれば、その課題を克服することができます。我々は、このような特性を「アプリケーションの可視化」と呼んでいます。
4. マルチカスタマー環境のサポート—多くの実装環境では、たとえば、基幹業務が IT 組織によってサポートされている場合、IT 組織はサービス・プロバイダーの顧客や内部顧客などの複数の顧客をサポートしなければなりません。そのような環境では、顧客アカウント別にデータを分離する必要があるため、セキュリティーおよびプロセス制御に対する影響があります。

本稿では、IBM Tivoli* Change and Configuration Management Database (CCMDB) のアーキテクチャーおよび主な機能と、上記の要件を満たし、IBM サービス・マネジメントのイニシアチブをサポートする CMDB を紹介します。^3,4 IBM サービス・マネジメント (ISM) は、ビジネス・サービスの管理を自動化して簡素化することを目的とした方法です。⁵ ここでは、関係管理、コンポジット CI、データ・フェデレーション、データ・リコンシリエーション、マルチカスタマー・サポートのためのセキュリティー・モデル、変更管理プロセスと構成管理プロセスの統合などの実装のトピックについて説明します。これらのいくつかの機能に対応している多くの製品が、他のベンダーから提供されています。 ⁶–⁹

本稿の以降の部分は、次のように構成されています。次のセクションでは、CCMDB データ・モデルについて説明するとともに、関係がどのように管理されるかを説明します。続いて、さまざまなデータ・ソースからデータをデータベースに取り込み、取得したデータを整合化する CCMDB メカニズムについて説明します。次のセクションでは、CI とアプリケーションの依存関係を可視化するための CCMDB のアプローチについて説明します。続いて、CCMDB のマルチカスタマー・サポート機能について説明します。次のセクションから最後のセクションまでは、変更管理プロセスと構成管理プロセスを統合するための CCMDB のアプローチを説明します。最後のセクションは、結論が述べられています。

上に戻る

データベースのデータ・モデルは、データベースに保管されているデータの構造の概念的表現であると考えることができます。データ・モデルは、さまざまなリソース・タイプに加えて、以下のものにも対応できなければなりません。(1) リソースの正式な定義、これらによって、リソース・データを CMDB にインポートすることができます。(2) ハードウェアとソフトウェアの両方の可視化されたリソース。(3) 複雑なリソースとコンポーネント・パーツから構成されるその構造。(4) エンティティーのコンポジット・ユニットへの集約。

我々は、長年にわたるさまざまな業界のシステム管理での経験を生かして、Tivoli 管理製品からインポートされたデータを統合することを第一の目的とした CCMDB データ・モデルを開発しました。このデータ・モデルは、Unified Modeling Language** (UML**) 図を使用して定義されています。この図を使用することによって、大きなモデルをサブモデルに分割することができます。すべてのオブジェクト、クラス、および関係は、Java** の永続オブジェクトで実装されます。したがって、Java のプログラマーは、オブジェクトや関係を操作することができ、それらのオブジェクトや関係はそのモデルのサポートを目的としたデータベースに格納されます。以下のタイプの構成体は、CCMDB データ・モデルで定義されます。

1. モデル—属性、クラス、および関係は、モデルに属します。モデルはこれらのエンティティーの名前空間を定義し、バージョン管理の単位となります。モデルの例としては、Computer System があります。
2. クラス—クラスは、ITのエンティティーを表します。クラスは、属性を持つことができ、関係に参加する可能性があります。クラスの例としては、ComputerSystem と OperatingSystem が挙げられます。
3. 属性—属性はクラスとは別に定義されて、クラス定義に何回でも再使用できます。属性の例として、OSName (オペレーティング・システム名) が挙げられます。
4. 関係—関係はクラスとは別に定義され、厳格に区別されます。関係だけが参照を持つことができます。さらに、すべての関係は 2 項の関係です。関係の例としては、InstalledOn (クラス OperatingSystem と ComputerSystem の関係) が挙げられます。
5. データ・タイプ—これらは、プログラミング言語のデータ型と似ています。データ・タイプは、エンティティーと関連付けることができる値のセットを定義します。データ・タイプの例としては、String があります (属性 OSName のデータ・タイプは String)。

IBM Tivoli で作成されたデータ・モデルには、今日の IT インストール済み環境にあるほとんどの IT エンティティーの表現が含まれており、共通データ・モデル (CDM) と呼ばれています。CDM には、現在、約 1000 のクラス、サブクラス、および関係があります。CDM は、システム管理のためのこの業界の中で最も豊富なデータ・モデルの1つです。モデル Computer System はシステム管理製品のための基本的なモデルであり、ハードウェア (たとえば、マシン) とソフトウェア (たとえば、オペレーティング・システム) の組み合わせです。モデル Computer System では、ComputerSystem および OperatingSystem の 2 つのオブジェクトはともに関係するエンティティーの集合であるとみなされるため、両オブジェクトともクラス System から派生したものとなります。このモデルに含まれているのは、ホスティング環境 (ソフトウェアを実行できる場所) としての Operating System の表現です。後に、この概念は、Web アプリケーション・サーバーなどの他のホスティング環境 (アプリケーションのためのホスティング環境) にも適用されます。

関係管理

関係は、2 つのエンティティーの間の結合を指定するだけでなく、その結合の意味 (意味構造) を示します。CMDB においてデータ・オブジェクト間の関係が存在しない場合、そのデータ・ストアは発見された構成情報のリポジトリーにすぎず、IT 環境の全体像を示すものとはなりません。

関係の例としては、AccessedVia (AppServerCluster AccessedVia IpAddress)、Contains (ComputerSystem Contains FileSystem)、および RunsOn (OperatingSystem RunsOn ComputerSystem) が挙げられます。より詳細なリストは、参考文献 4 および 10 にあります。

関係は、明示的関係または暗黙的関係のいずれかで表すことができます。暗黙的関係は、集約オブジェクト・グループまたは複合オブジェクト・グループを構築します。暗黙的関係は、同じタイプのオブジェクトを結合し、そのような関係に基づいた照会は効率的です。明示的関係は、個別のオブジェクトであり、それらの集約のルート間で定義されます。明示的関係は、タイプの異なるオブジェクトを結合できます。CCMDB には、ユーザーがこのような関係を全探索するのを支援するための、アプリケーション・プログラミング・インターフェース (API) が用意されています。ほとんどの構成照会は 1 つのフィルター表現で表すことができます。明示的な関係は実行時に動的に処理することができ、ターゲット・オブジェクトのタイプが不明であるか、またはそのソースと異なるユース・ケースに対応することができます。

暗黙的な関係の照会

1 つのコンピューター･システムに、複数のオペレーティング・システムがインストールされている場合があります。表 1 では、ComputerSystem クラスに定義された関係を Javadoc** 形式で示しています。

InstalledOn 関係は、OSInstalled という名前が付けられたサイズが不明な動的な配列として定義されています。この動的配列の各メンバーが OperatingSystem オブジェクトです。この定義によって、CCMDB 永続オブジェクト・レイヤーは ComputerSystem オブジェクトと OperatingSystem オブジェクトの主要な属性を持つ中間的なテーブルを作成します。

API は、データを全探索および検索するために使用される 1 つのメソッド (find という名前が付けられた) から成ります。これは、SQL のような言語である Model Query Language (MQL) で表現されたフィルターと考えることができます。⁴ ほとんどの構成照会は、この 1 つのフィルター表現を使用して実行することができます。この下で、CCMDB はこのフィルターを SQL (Structured Query Language) ステートメントに変換します。SQL ステートメントは、データベース管理システムによって提供される照会最適化機能を最大限に活用します。

以下に、複雑さが異なる 3 つの MQL 照会を示します。

1. あまり複雑でない—マシン X にインストールされているオペレーティング・システムは何ですか。
   
   SELECT OperatingSystem.*
FROM OperatingSystem, ComputerSystem
WHERE OperatingSystem.parent.guid = =
ComputerSystem.guid
AND ComputerSystem.fqdn = = ‘X’

2. 複雑さが中程度—オペレーティング・システム Microsoft Windows** XP とデータベース製品 IBM DB2 Universal Database* 8.2 を備えたテスト環境をサポートしているコンピューター・システムはどれですか。
   
   SELECT *
FROM ComputerSystem
WHERE OSRunning.OSName = = ‘Windows XP’
AND exists(OSRunning.installedSoftware. productName = = ‘DB2 8.2’)

3. かなり複雑—IBM 製のハードウェアを使用し、Windows XP が稼働し、Norton Antivirus 1.6 がインストールされているコンピューター・システムはどれですか。
   
   SELECT *
FROM ComputerSystem
WHERE ComputerSystem.physicalPackage. manufacturer = = ‘IBM’
AND OSRunning.OSName = = ‘Windows XP’
AND exists(OSRunning.installedSoftware. productName = = ‘Norton Antivirus 1.6’)

明示的な関係の照会

すべての明示的関係には、以下の 2 つの固有の ID が含まれています。1 つはソース CI 用の ID であり、もう 1 つはターゲット CI 用の ID です。明示的関係を全探索するために、CCMDB ではメソッド FindRelationship( ) を提供しています。このメソッドは、特定の関係タイプの関係グラフを指定されたオブジェクトから開始して取得します。その結果は、それぞれがソース・オブジェクト、ターゲット・オブジェクト、および関係タイプで構成される Relationship オブジェクトの配列となります。関係グラフは、関係タイプ別に任意のソースから開始して前方あるいは後方に全探索することができ、ループすることなく任意の指定されたレベルで終了することができます。

明示的な関係は、ターゲット・オブジェクトのタイプが不明であるか、または複数のタイプが関係している場合に、特に役立ちます。たとえば、RFC (変更要求) によってどの CI が影響を受けるかを判断する場合に、暗黙的な関係を使用してその情報を取得することは困難です。CI のタイプが不明であるため、それぞれのタイプの CI を検索して Affects 関係のソースが RFC オブジェクトであるかどうかを判断する照会を使用する必要があります。この照会は、すべてのリンクが見つかるまで繰り返し検索を行うリソース集中型のタスクです。代わりにメソッド findRelationship() を使用すれば、このタスクは非常に簡単になります。

ここでは、rfcGuid は RFC オブジェクトの汎用一意識別子であり、関係の全探索は定義された方向 (前方) に従い、関係タイプは Affects であり、検索は間接の 2 次レベルで停止します。

上に戻る

現実の世界のエンタープライズ・システムでは、それぞれの関係が複雑な数千にも及ぶリソースがある可能性があり、それらのリソースを効率的にグループ化することなしに、その複雑さを管理するのが難しくなっています。幸いにも、物理的なマシン・クラスター、接続されたソフトウェア・システム、およびサービスの集合などのいくつかの自然の分類パターンが存在します。この複雑さの問題に取り組むために、CCMDB では密接に関係する CI のグラフをコンポジット CI (または単にコンポジット) として管理する方法を提供しています。¹¹,¹²

この複合物は、関係グラフ全体に作用して特定のサブグラフを作成するテンプレート・ベースのフィルターによって定義されます。このテンプレートのメカニズムによって、お客様は特定のビジネス・ニーズに基づいてコンポジットの定義を変更することができます。コンポジットは他の構成アイテムと同様に扱われ、CMDB データベース内で個別の要素として存在します。コンポジット・グラフは、テンプレートの定義に基づいて関係をナビゲートすることによって構成されます。たとえば、Server にはルート・オブジェクト ComputerSystem があり、このオブジェクトには関連するハードウェア、オペレーティング・システム、ソフトウェア、およびネットワーキング要素が含まれています。

コンポジットのアイデンティティーは、ルート要素のアイデンティティーによって決定されます。このことは、このアイデンティティーにはサブコンポーネントから派生した属性さえも含む必要なすべての属性が含まれていなければならないことを意味します。サブコンポーネントは、時間の経過とともに、追加、更新、または削除することができます。たとえば、Server を 1 つの ComputerSystem オブジェクトのみで作成し、後にオブジェクト OperatingSystem を追加することができます。

コンポジットを扱うためのルールは、たとえば、「コンポジットに他のコンポジットを含めることができる」または「コンポジットを部分的に定義できる (まだすべてのサブコンポーネント・パーツが含まれていない)」などの関係の意味構造に基づいて非常に複雑になる可能性があります。

図 1 は、Web- Sphere* Application Server のコンポジット・グラフを示しています。この図は、WebSphere Application Server コンポジットに Server コンポジットが含まれていることを示しています。3 つのコンポジットを扱うほうが多数のサブコンポーネントを扱うよりもはるかに簡単であるということを考えれば、コンポジットの概念の利点は明らかです。

コンポジット・インスタンスは、発見スキャンの後で自動的に作成することも、ユーザー・インターフェースから明示的に作成することもできます。コンポジットは、コンポジットのインスタンスを一意に識別するために、名前、属性のセット、および関連する命名規則で作成されます。ユーザー・インターフェースは、コンポジット包含ツリーをナビゲートすることでインスタンス化できる、有効なアトミック CI のタイプおよび関係のリストを提供します。

検索方法は、ルート要素の包含ツリーの深さ優先の全探索です。このアルゴリズムでは、v をルートとするサブツリー内の他のすべての CI ノードを探索してからアトミック CI v のノードを探索します。n ノードのツリーの全探索には、O(n) 時間がかかります (このアルゴリズムには、n 時間計算量の命令があります)。

コンポジットを削除する場合には、そのコンポジットをサポートしている要素のうちで、それとともに削除する要素と、その無効になったコンポジットから切り離して保存しておく要素を決定する必要があります。これは、個別に決定され、それぞれに伴う関係の意味構造によって異なります。

上に戻る

このセクションでは、CCMDB のロードおよび保守に関係する、自動化されたセンサー・ベースの発見、アプリケーション記述子およびコンポーネント・テンプレートによる発見、データ・フェデレーション、データ・インポート、およびリコンシリエーションのプロセスについて説明します。

自動的なデータおよび関係の発見

構成アイテムの継続的および自動的な発見は、データ入力のコストを回避するためだけでなく、データベースの現在の状態を検証するためにきわめて重要です。CCMDB は、資格情報のないネットワーク環境の「スニッフィング」であろうと (つまり、ハイレベルの構成情報の収集)、資格情報に基づく発見であろうと、センサー・ベースの発見を使用します。このセンサーは、導入コストを負うことなしにほぼローカル・エージェントの発見の深さを達成するエージェントなしの方法の新たなバリエーションです。基本的に、センサーはローカルで稼働しているユーザーをモニターされているホスト上でエージェントのようにエミュレートしますが、それは短時間だけです。このセンサーは、セキュア・ネットワーク接続、暗号化されたアクセスの資格情報、およびホスト固有のユーティリティーを使用することで機能します。

CCMDB ディスカバリー・エンジンは、さまざまなディスカバリー・センサーをスケジュール、配布、調整、および管理するためのフレームワークを提供します。発見が開始されると、センサーは以下の多段階プロセスを実行します。

• センサーは標準プロトコル (SNMP: Simple Network Management Protocol) を使用して、デバイスの IP (Internet Protocol) アドレスを決定します。
• 資格情報が提供されていない場合、センサーは浅い発見を実行して、オペレーティング・システムに関連する情報を抽出し、その環境にあるアクティブな資産の基本的な情報を提供します。
• オペレーティング・システムの資格情報が提供されている場合は、SSH (Secure Shell) などのセキュア・プロトコルを使用して、ホストへのセキュア接続が行われます。セッションが接続されている場合、センサーは空きポートと聴取中のプロセスをキャプチャーします。
• センサーは、ネイティブ・ユーティリティーを使用して、インストールされているソフトウェアおよびパッチ、ホストされているアプリケーション、実行されているプロセスを発見します。
• センサーは、収集された情報に基づいて、他のセンサーを呼び出して (アプリケーションの資格情報を使用して)、DB2* や WebSphere などのアプリケーション構成を発見します。
• センサーは、収集されたデータを発見サーバーに送信し、SSH セッションを終了し、接続を終了します。

大きな作業負荷を処理するために、このプロセスのいくつかのインスタンスを並行して実行することができます。収集されたデータがデータベースに保存されると、経験則に基づくバックグラウンド・プロセスが構成アイテム間の暗黙の関係を判断します。たとえば、特定のホスト/ポートを介して通信する WebSphere Application Server アプリケーションを、そのポートを聴取している DB2 サーバーとマッチングする可能性があります。これらの暗黙の関係を使用することによって、完全な依存関係のグラフが作成されて、カスタマー・ツールの現在の状態に比べて大幅な改善をもたらします。

拡大図

アプリケーション記述子は単純な XML (Extensible Markup Language) ファイルであり、パッケージ化されるときにアプリケーション・モジュールに追加されます。これらのアプリケーション記述子によって、ディスカバリー・エンジンはビジネス・サービスを自動的にグループ化し (より高いレベルの集約オブジェクトを形成するためのグループ化)、維持することができます。

また、ディスカバリー・エンジンは、コンポーネントのシグニチャーを識別して、マッチングするカスタマー・コンポーネントを特定のビジネス・サービスに「属する」と指定することによってビジネス・サービスを発見することもできます。コンポーネント・テンプレートは、分類のためにプログラム名、ポート、および環境変数などのアイテムの組み合わせを使用することによって、コンポーネントの固有のシグニチャーを指定します。

以下に、センサー・ベースの発見の主な機能を示します。

• センサーは、アプリケーションに関するデータを必要なだけ取得できます。
• センサーは、エージェントを単なるデータ・ソースとして使用して、既存のレガシー・エージェントと連動することができます。
• センサーは、リモート管理プロトコルを利用して、アプリケーションおよびプラットフォームに固有のデータを収集します。
• センサーは、資格情報の有無にかかわらず、簡単に配備し、管理することができます。
• センサーは、通常、アクティブな状態で CPU の処理の 1% 未満しか消費しないため、ターゲット・マシンにほとんど影響しません。
• センサーは、アプリケーションおよび構成とそれらの依存関係の柔軟なエンドツーエンドのビューを提供します。

データ・フェデレーション

データを単一の物理データ・ストアに統合する方法は、関連する情報への高速かつ可用性の高い統合されたアクセスを実現するために最も一般的に使用されている方法です。^13,14 多くの場合、統合は、パフォーマンスまたは 1 つのマスター・コピーで整合性を達成できることによって正当化されます。その一方で、フェデレーションは、場所、フォーマット、およびアクセス言語に関係なく、分散データを 1 つのソースであるかのように見せます。データ統合の方法とは異なり、フェデレーションは、データを物理的に中央リポジトリーに持ってくるわけではありません。CCMDB は、データ統合およびデータ・フェデレーションの両方の長所を兼ね備えています。基礎となるフェデレーション技術は、DB2 をフェデレーション・エンジンとして使用する IBM Information Integrator テクノロジーです。 ^13–16

外部のデータ・ソースは、構成されると、DB2 SQL により照会または処理することができます。これらの外部ソースは、DB2、Microsoft** SQL Server、Oracle Database 10g、Sybase Open Serverなどのリレーショナル・データ・ソースおよび、XML 文書、Excel** ファイル、Web サービス、IBM WebSphere MQ、VSAM* (Virtual Storage Access Method) データ・セット、IBM IMS* (Information Management System) データベースなどの非リレーショナル・データ・ソースなどです。

図 2 では、CCMDB データ統合アーキテクチャーを示しています。CI および関係の情報は、物理データ・ストアまたは論理データ・ストアのいずれかの、ストレージ内のそれぞれの場所から取得されます。我々は、データ・フェデレーションの場合、IBM Information Integrator テクノロジーを利用して、すべてのデータを中央にコピーすることを必要とせずに、異種のデータ・ソースからのデータを統合しています。CCMDB では、データを物理的にデータベースに移動するデータ統合サービスも提供します。データ統合サービスには、IDML のインポートおよびディスカバリー・センサーが含まれています。

IDML によるデータのインポート

実質的にどのソースからでも CCMDB へのデータ・インポートを可能にするために、IBM は Identity Markup Language、つまり IDML を開発しました。⁴ アダプター・プログラムが Tivoli Provisioning Manager (TPM) または Tivoli Configuration Manager (TCM) などのソース・アプリケーションからデータを抽出して、IDML ファイルを作成します。これらのファイルは、CCMDB に一括してロードされます。多くの場合、ソースは単純な XML 変換に使用できるエクスポート・フォーマットをすでに備えている可能性があります。

リコンシリエーション

CI 情報は複数のソースから出ている可能性があり、通常、異なるソースからの CI レコードは同質のものではないため、リコンシリエーション (整合化) のプロセスが必要になります。CI のための CCMDB のリコンシリエーションでは、最初に、CI を識別可能な属性のセットおよび各属性セットの優先順位を指定する命名規則を作成するための 1 回限りのタスクが必要となります。命名規則の主な部分は、以下のとおりです。

• Class—インスタンスに名前を付けるために使用されるクラス。たとえば、ComputerSystem。
• Superior class—特定のクラスよりも大きいクラス (存在する場合)。たとえば、OperatingSystem クラスは ComputerSystem クラスに従属するものとしての名前が付けられています。その名前には、その上位名が含まれます。
• Naming attribute—CI を識別可能な属性を表す文字ストリング。

拡大図

• Priority—CI を識別するために使用される各命名属性の優先順位を示す、負でない整数。

以下に、ComputerSystem クラスの命名規則を示します。

0=‘signature’
1=‘manufacturer,model,serialNumber’
2=‘systemBoardUUID’
3=‘primaryMACAddress’
4=‘hostSystem,VMID’
5=‘managedSystemName’

たとえば、2 番目の規則は、優先順位 1 とネーミング属性 ‘manufacturer,model,serialNumber’ に関連付けられています。

ComputerSystem クラスのインスタンスを作成する場合は、以下の手順が実行されます。

• その要求に 1 つ以上の命名属性が含まれているかをチェックします。与えられた属性の数が不足しているか、またはそのインスタンスの親オブジェクトが存在しない場合、その要求は拒否されます。
• 優先順位とその規則から生成された名前のストリングに従って、Type 3 GUID (IETF [Internet Engineering Task Force] RFC 4122 に基づく汎用一意識別子)¹⁷ を生成します。命名規則に親が指定されている場合は、その親からネーミング属性を取得します。
• いずれかの既存の CI インスタンスと同じ GUID または別名をマッチングします。

拡大図

• さらなる情報が提供されるまでは、1 つの CI の複数のコピーがマッチングされない可能性がまだあります。マッチングされた時点で、重複しているものはマージされ、別名が更新されます。

上に戻る

今日の IT サービスおよびアプリケーションの多くは、数千にも及ぶコンポーネントで構成されるインフラストラクチャー上に構築されます。IT サービス・マネジメント・イニシアチブを導入しようとしているほとんどのお客様は、この複雑さに対応するソリューションを求めています。お客様は、さまざまな CI にビジネスをサポートするアプリケーションがどのように依存しているかを把握していることを要求され、問題が発生した場合には迅速に対応できるようにすることを求められます。したがって、CCMDB では、そのようなアプリケーションの依存関係を可視化できるようにする必要があります。また、これらの可視化は、サービス指向アーキテクチャーやビジネス・システム・ダッシュボードの実装などの他のビジネス関連の変革と統合する必要があります。

図 3 では、CCMDB によるアプリケーションの依存関係の可視化を示しています。この図には、IBM WebSphere、Apache** HTTP Server、および BEA WebLogic Server** などのさまざまなアプリケーション・サーバー・プラットフォームで実行されているさまざまなソフトウェア・コンポーネントが示されています。発見されたすべての CI とその関係を、グラフで見ることができます。このグラフの各ノードは、エンタープライズ・サーバー環境におけるインフラストラクチャー・ソフトウェア・コンポーネント (ミドルウェア) を表しています。インフラストラクチャー・ソフトウェアには、アプリケーション・サーバー、Web サーバー、データベース、および Domain Name Service (DNS) や Lightweight Directory Access Protocol (LDAP) などのさまざまなシステム・サービスが含まれています。このグラフの端の部分 (接続線) は、コンポーネント間の関係を表しています。この例では、WebSphere Application Server に依存している 3 つの Sun ONE Web Server** があります。そして次に、WebSphere Application Server は、そのデータベース・サービスに関して Oracle データベースに依存しています。

拡大図

CCMDB は、各ビジネス・サービスとビジネス・アプリケーションの依存関係も可視化します (図 4)。たとえば、Order Entry は、Order Management、Inventory Management、および Billing の各ビジネス・アプリケーションからのアプリケーション・コンポーネントを統合することによって提供できるビジネス・サービスです。ユーザーは、個々のコンポーネントの大きなコレクションをグループ分けすることによって、インフラストラクチャーを簡素化するビジネス・サービスを作成することができます。

上に戻る

IT サービス・プロバイダーは、IT サービス・マネジメント・プロセスを支える主なコンポーネントとして CMDB に依存しています。これらのプロバイダーは、多くの場合、複数の世界規模のオペレーションを 1 つの物理的インフラストラクチャーに統合するという課題に直面しています。これを達成するためには、アプリケーションを一度実装するだけで多くの顧客間で共用できるように、データの分離とアクセス制御を実現する必要があります。1 つのアプリケーションが複数の顧客に対応するように構成されている場合、我々は、マルチカスタマー・サポートとマルチテナント・サポートに区別しています。

マルチカスター—マルチカスター機能を備えたサービス・マネジメント・アプリケーションは、顧客間の適切なデータの分離によってサービス・プロバイダーが複数の顧客のためにデータおよびサービスを管理できるようにするアプリケーションのことです。この機能を実装するアプリケーションでは、サービス・プロバイダーだけが管理対象のデータおよびサービスにアクセスし、制御することができ、サービス・プロバイダーに雇用されたもののみが管理対象のデータおよびサービスにアクセスすることができます。

マルチテナント—管理対象のデータおよびサービスへのフル・アクセスを提供するとともに、適切なデータの分離を行うことによって、複数の顧客がサービス・マネジメント・ソリューションの 1 つのインスタンスにアクセスし、管理対象外のデータやサービスにはアクセスすることのないようにします。この機能を実装するアプリケーションでも、依然としてサービス・プロバイダーが介在しますが、その役割は主に顧客間のサービス要求を仲介し、中核となるアプリケーション機能を維持することにあります。

構成可能性とセキュリティーがシングルテナント・ソリューションと同じレベルで保証されるのであれば、顧客はマルチテナント・ソリューションのほうを好みそうです。マルチカスタマー・サポートを提供するには、各顧客のビジネス・ニーズに合わせてソリューションを調整できるように構成機能が CMDB に組み込まれていなければなりません。適切に設計されたマルチカスタマー・サポートによって、サービス・プロバイダーは以下を行うことができます。

• 人的リソースの共通のプールを利用する。
• 共通のライブラリー (ソフトウェア・ポートフォリオなど) を利用する。
• 顧客データを分離してセキュリティーを向上する。
• グループまたはすべての顧客に関するデータを集約するレポートを生成する。
• 顧客のグループに関するデータを集約することによって主要業績評価指標が得られた時点で、管理者層にその主要業績評価指標をリアルタイムで提供する。

CCMDB のマルチカスタマー・アプローチでは、サプライヤーのコストおよび管理の負担を軽減し、その節約分を顧客に回すことができます。図 5 では、CCMDB マルチカスタマー・セキュリティー・モデルを示しています。¹⁸ このソリューションは、基礎となる ITIL CMDB セキュリティー・アーキテクチャーと追加のアクセス役割およびアクセス許可を作成するオプションに基づいて構築されています。役割と許可は、実行時に追加して、ユーザーに割り当てることができます。

役割と許可

マルチカスタマー環境にあるサービス・プロバイダーをサポートするために、我々は、サービス・プロバイダーの組織とその固有のプロセスに適応しなければなりません。これを言い換えると、Customer または Account ごとに定義された役割および許可のコレクションということになります。また、他のプロセスでは、構成管理における役割と許可を超越した役割と許可を持つことができます。構成マネージャーは、ITIL によって識別される役割の 1 つです。マルチカスタマー CMDB では、顧客の構成マネージャーの役割は、顧客の構成管理プロセスに責任を持ち、顧客のために他の役割、許可、および構成アイテム (CI) を管理する能力がある Customer の範囲に及んでいます。この顧客の構成ライブラリアンは、Account CI の所有者であり、その Account CI のすべてのマスター・コピーの管理者です。

構成管理におけるデータの分離では、グループまたは個々の CI の安全なコンテナーとなる AccessCollections という概念を使用しています。どのような管理単位 (顧客、組織、部門) でも、AccessCollection に関連付けることができます。AccessCollection にはその単位に関連する CI が含まれています。 管理単位への CI の割り当ては、この管理単位のための AccessCollection に CI の参照を追加することによって行われます。たとえば、アカウントのリソースの所有権の概念を表すために、関係タイプ Owns が作成されています。関係タイプ Uses は、CI が共用される可能性を表しています。

図 5 では、Customer, Account、ServiceProvider、Organization、workGroup、Person、Role、および AccessCollection はすべて管理単位です。これらの管理単位は、このサポートを提供するために事前に定義された関係のセットによって相互に関係しています。一般に、1 人の担当者が多くの役割を持ち、各役割が特定の AccessCollections (CI の) にアクセスする可能性がありますが、担当者によるコレクションへのアクセスをその担当者が特定の役割を果たす場合のみに限定しなければならない場合があります。これは、Person-In-Role オブジェクトによって行われます。CI のセットをサポートするための Person-in-Role の割り当ては、その CI をメンバーとして持つ AccessCollection に Person-in-Role を関連付けることによって行われます。

AccessCollections は、CCMDB において交換可能なコンポーネントであるSecurity Manager によって保護されています。AccessCollections のユーザーと役割のペアへの割り当てと、役割の許可への割り当ては、セキュリティー・ポリシーに保存されます。CMDB データベースとセキュリティー・ポリシーは、新しい役割、許可、ユーザー、およびアクセス・コレクションを含めるようにいつでも更新することができます。このアプローチは、集中型のセキュリティー管理と照会のパフォーマンスの結果のバランスをとるように設計されています。

限定的なマルチテナント・ソリューションを構成するには、Customer/Account を作成して CCMDB のセキュリティーを設定する許可を与えられたスーパー構成マネージャーの役割を作成する必要があります。この役割に割り当てられた担当者は、Customer/ Account を作成し、これらの単位に CI を割り当て、People を Customers、Accounts、および Organizations に割り当てる責任があります。

拡大図

上に戻る

CMDB から最大の利益を引き出すには、変更管理プロセスと構成管理プロセスを緊密に統合する必要があります。現在の IT 環境では、IT インフラストラクチャーと IT サービスへの変更を管理するための標準プロセスが不可欠です。構成をどのようにすべきか (我々は、許可された環境と呼んでいる) の正確なイメージを保ち続けなければ、変更の悪影響を管理する方法を想像するのは困難です。逆に、環境の変更を管理するプロセスなしに、許可された環境の正確なイメージをどのように保つことができるかを想像することも困難です。これが、ITIL で「理想としては、変更管理は、構成管理システムに不可欠な部分として見なす必要があります」と述べられている理由です。¹ 実際には、従来、一部の組織が変更管理をサポートする構成管理プロセスなしに変更管理を実施してきたという理由だけで、ITIL において構成管理と変更管理が分けられているにすぎません。しかし、ITIL では、これらの 2 つのプロセスを一緒に計画し、導入するよう推奨しています。1

これらのプロセスは、大規模なインフラストラクチャーとマルチカスタマー・サポートを含む大規模なマルチカスタマー環境の複雑さに対応できなければなりません。変更管理と構成管理は、IT 環境のための主要な制御プロセスを代表しています。変更管理は、許可された環境のビューに関する正確な情報を得るために構成管理に依存します。構成管理は、環境の正確なイメージを保つことができるように、その環境に対して計画されて完了した変更に関する情報を得るために、変更管理に依存します。ITIL によると、環境に対する標準サービス要求以外の変更はすべて、変更管理の制御下にある必要があるとのことです。CCMDB は、変更管理と構成管理を完全に統合したこの業界で初めての製品の 1 つです。

CCMDB の構成管理と変更管理の統合の主な特徴は次に示すとおりで、このセクションの残りの部分で説明します。

• 変更要求 (RFC) とそれによって影響を受ける各 CI 間の関係を管理する。
• カスタマイズ用のテンプレートを使用して CI とその保護されたライフ・サイクルの状態および変化を表す。
• 異なるバージョンの CI (許可された CI、実際の CI、ゴールド・スタンダード CI、ベースライン CI など) を作成し、維持する。
• Control CI サブプロセスによって CI の変更の制御を強制する (後述)。
• 実際の CI および許可された CI のレコードの差異を修正する。
• 変更が制御されている属性に関する CI の許可された変更を表示する。

変更管理の目的は、環境に対する変更の悪影響を最小限に抑えることにあります。変更は、サービスを提供する環境に対する追加、削除、または変更となるハードウェア、システム、およびアプリケーション・ソフトウェア、プロシージャー、および環境設備のインストールまたは変更として定義されます。変更要求は、管理者または自動化されたサービス・サポート・プロセスによって開始することができます。

変更管理プロセスは、各 RFC に関する CMDB 内にある情報をそのライフ・サイクルにわたり維持します。この情報には、変更とその影響を受ける CI 間の関係が含まれています。構成管理プロセスを使用して、この情報を更新することが不可欠です。

構成管理は、IT システムの IT コンポーネントおよびサービスに関する情報を識別し、定義し、維持するためのプロセスです。また、構成管理では、これらのコンポーネントが別のコンポーネントや変更レコードなどのサービス・サポート (ITIL の一環) プロセスの成果物とどのように関係しているかに関する情報も維持します。この環境の論理表現は、サービス・サポートおよびサービス・デリバリーにおける他の ITIL プロセスによって使用されます。このように、構成管理には、サブプロセスとしてCI の識別、CI の制御、CI の検証と監査、および CI の状態の報告などが含まれます。

ITIL によると、構成管理は、「適切な制御文書なしに」アイテムが変更、追加、または削除されないようにする必要があります。¹ RFC のライフ・サイクルの状態を ‘‘Closed’’ に更新する前に、変更プロセスはその環境および CMDB が適切に更新されていることを確認する必要があります。いくつかの低レベルの変更の場合、その変更が環境の中でどのような形で現れるかを知ることは困難または不可能となる可能性があります。

control-CI サブプロセスの一環として、すべての構成アイテムに、ライフ・サイクルの状態が関連付けられます。このライフ・サイクルの状態はプロセスをトラッキングするために使用され、計画策定、意思決定、変更の管理のために最新の状態に保ち、いつでも利用できる状態にしておく必要があります。ライフ・サイクルの状態の例としては、注文済み、受け取り済み、受け入れテスト中、稼働中、変更中、撤去済み、および廃棄済みがあります。アイテムが別の正当な状態のみへ変わるように、ライフ・サイクルの状態の遷移を管理する必要があります。また、これらの遷移の履歴は、検査のために保持され、いつでも利用できる状態にします。

状態遷移図から、CI のライフ・サイクルの一部分の保護を指定することが可能であり、CI を変更する方法をより厳密に管理できます。その指定は、この状態にある変更を変更レコードに関連付ける必要があることを示しています。

CCMDB 内にある CI 情報は、複数のバージョンを持つことができ、各バージョンが CI の異なる側面を表します。この機能は、この業界ではしばしば見過ごされています。CMDB の中の CI のバージョンには、認可済みバージョン、ベースライン・バージョン、実際の

(発見または監査された) バージョン、および計画済みバージョンがあります。

制御された CI の属性 (つまり、変更するために修正可能なもの) とそのライフ・サイクルの状態および遷移は、CMDB 内のデータ・モデル・エンティティーにマッピングされているテンプレートを使用して実装される必要があります。発見およびその他データ入力プロセスでは実際のデータが提供されますが、変更管理プロセスでは認可済みデータが提供されます。

構成ベースラインは、認可済み構成アイテムのセットの特定の瞬間のスナップショットです。この概念は、文書化、リカバリー、そして特に比較する場合に役立ちます。ベースラインには名前とタイム・スタンプが関連付けられており、お客様は必要に応じてベースラインを新規に作成することができます。

多くのサービス・プロバイダー環境で使用されている類似概念がゴールド・スタンダードです。ゴールド・スタンダードは、他の CI のセットを構成する方法に関してモデルまたはテンプレートとしての役割を果たすCI レコードのセットです。ゴールド・スタンダードと任意の数の CI のセットとの関係を作成して、それらのセットに対するゴールド・スタンダードの適用可能性を設定します。ゴールド・スタンダードは、設定されたポリシーへの準拠を評価するためにconfiguration-management verify-and-audit-CI プロセスによって使用されます。たとえば、組織が一般的な UNIX** サーバーの構成を表すためにゴールド・スタンダードを作成し、ネットワーク内の個々の UNIX サーバーとこのゴールド・スタンダード間の関係を作成する場合があります。それらの UNIX サーバーに対して verify-and-audit-CIs プロセスが実行されると、ゴールド・スタンダードと関連するサーバーの間の準拠の相違に関するレポートが生成されます。

ライフ・サイクルの状態の遷移は、CI がある状態から別の正当な状態にのみ変わるように管理しなければなりません。configuration-management プロセスの一環として、このライフ・サイクルの遷移には、属性レベルの意味構造の検証が組み込まれている必要があります。この検証機能は、他の状態よりも多くの制御が必要とされるライフ・サイクルの状態があることを認識します。CI レコードは、CI で行われたすべての変更を反映するものであるため、そのライフ・サイクルの状態の変更のリストを保持しています。ライフ・サイクルの状態の管理の詳細については、^{参考文献 19} を参照してください。

上に戻る

本稿では、IBM Tivoli® Change and Configuration Management Database (CCMDB) のアーキテクチャーと主な特徴について紹介しています。豊富なデータ・モデル、自動的な発見および保守、CI におけるアプリケーションの依存関係の可視化、マルチカスタマー・サポート、および変更管理プロセスと構成管理プロセスの統合などの、主な特徴について説明しています。また、関係管理、コンポジット・オブジェクト、センサー・ベースの発見、データ・フェデレーションのサポート、インライン・リコンシリエーション、およびマルチカスタマーのセキュリティー問題などの実装面についても説明しています。この設計は、CCMDB 製品リリース 1.1 (2006 年 6 月にリリース) に実装されました。

CMDB は、IT 組織にとって大きな価値があることは明らかです。また、CMDB は、他の IT プロセスや多くのビジネス・プロセスを構築するための基盤にもなります。ビジネスは、効率および有効性の向上につながるビジネス環境の分析に必要な情報を持つようになりました。CCMDB は、ビジネス・コンプライアンス、ビジネス・プロセス・インテリジェンス、証券市場のための報告、および財務管理を可能にするために必要な技術を提供します。

上に戻る

この研究を実施するにあたり、それぞれの要件を明確に示すとともに、より良いソリューションの設計のために寄与していただきました多くのお客様方に感謝申し上げます。また、CCMDB の設計および実装に貢献された Yan Or、Krishna Garimella、Johan Casier、Shashank Joshi、Anand Sankaran、Girard Chandler、Robert Nielsen、Ling Tai、Ben Jeffcoat、 Jogeswar Challapalli、および Jinfang Chen に感謝致します。多大なご支援を頂いたWilliam Kopkind、Vinu Sundaresan、Mike Mallo、Jim Stubley、および Craig Love の各管理者の皆様に感謝致します。データベース・フェデレーション技術の利用に当たりご支援いただいた Eileen Lin、Mei-Mei Fu、および IBM Information Integrator の開発および管理チームに感謝致します。

*IBM Corporation の米国およびその他の国における商標または登録商標です。
**United Kingdom Office of Government Commerce、Object Management Group, Inc.、Sun Microsystems, Inc.、Microsoft Corporation、Apache Software Foundation、BEA Systems, Inc.、または the Open Group の米国およびその他の国における商標または登録商標です。

上に戻る

引用文献

1. 「Introduction to ITIL」、The Stationery Office, Office of Government Commerce, United Kingdom (2005 年)
2. 「Foundations of IT Service Management Based on ITIL」、J. Van Bon, M. Pieper および A. van der Verrn、編集者、ITSM Library, Van Haren Publishing (2006 年 11 月)
3. 「IBM Tivoli Change and Configuration Management Database (CCMDB)」、IBM Corporation
4. 「IBM Tivoli CCMDB Developer Reference Guide」 (2006 年 9 月—著者から入手可能)
5. D. Lindquist、H. Madduri、C. J. Paul、B. Rajaraman 共著、「IBM サービス・マネジメント・アーキテクチャー」IBM Systems Journal 46, No. 3, 423–440 (2007 年、本号)
6. BMC Software, Inc.
7. Relicore Clarity, Symantec Corporation
8. 「Mercury Application Mapping」、Hewlett-Packard Development Company, L.P.
9. 「nLayers」、EMC Corporation
10. S. Patel、S. S. B. Shi 共著、「Managing Relationships with Tivoli Configuration Management Database (CMDB)」、IBM CMDB ホワイト・ペーパー (2006 年 10 月、著者から入手可能)
11. N. Ayachitula、L. Shwartz、K. Garimella、および Y. Or、「Methods and Apparatus for Composite Configuration Item Management in Configuration Management Database」、U.S. Patent No. 920,060,467 (出願中)
12. N. Ayachitula、L. Shwartz、M. Surendra、K. Garimella、および Y. Or、「Methods and Apparatus for Automatically Creating Composite Configuration Items in a Configuration Management Database」、U.S. Patent No. 920,060,469 (出願中)
13. A. Betawadkar-Norwood、E. Lin、I. Ursu 共著、「Using Data Federation Technology in IBM WebSphere Information Integrator: Data Federation Usage Examples and Perfor- mance Tuning」、developerWorks, IBM Corporation
14. L. M. Haas、E. T. Lin、M. A. Roth 共著、「Data Integration through Database Federation」、IBM Systems Journal 41, No. 4, 578–596 (2002 年)
15. A. Betawadkar-Norwood、E. Lin、I. Ursu 共著、「Using Data Federation Technology in IBM WebSphere Information Integrator: Data Federation Design and Configuration」、developerWorks, IBM Corporation
16. 「Data Federation with IBM DB2 Information Integrator」、IBM Redbook SG24-7052, IBM Corporation
17. 「A Universally Unique IDentifier (UUID) URN Namespace」、IETF Network Working Group RFC 4122
18. L. Shwartz、G. Aikens、N. Ayachitula、M. Benantar、K. Garimella、H. Madduri、M. Surendra、S. Weinberger、および Y. Or、「Method and System for Segmenting Data and Role Based Access Control for Multi-Account Infrastructure Management」、United States Patent No. 920,060,468 (出願中)
19. C. Ward、V. Aggarwal、M. Buco、E. Olsson、S. Weinberger 共著、「変更管理と構成管理の統合」、IBM Systems Journal 46, No. 3, 459–478 (本号、2007 年)

2007 年 3 月 15 日に発表許可
2007 年 7 月 12 日にオンライン公開

Hari Madduri
IBM Tivoli Software, 11501 Burnet Road, Austin, TX 78758。Madduri 博士は、System/370t アセンブラーのプログラマー/アナリストとしてそのキャリアのスタートを切り、1985 年に University of Wisconsin-Madison でコンピューター・サイエンスの博士号を取得しました。1990 年に IBM に入社して以来、オブジェクト指向システム (DSOM)、データ・マイニング (データ・マイニング製品のチーフ・アーキテクト)、 e-コマース・ハブ、電子データ交換、および IBM Global Services のサービス開発 (UMI など) においてさまざまな技術および管理上の主導的な役割を果たしています。 IBM Tivoli では、今日の ITSM 戦略にいたった初期の ITIL プロセスのプロトタイプに貢献しました。現在、CCMDB 製品のリード・アーキテクトです。Madduri 博士は、University of Wisconsin-Madison、St. Thomas University (ミネアポリス)、University of Hyderabad (インド) の大学および大学院のクラスでプログラミング言語、コンパイラー、およびオペレーティング・システムの教鞭をとっていました。20 件を超える論文を発表し、20 件の米国特許の発明者です。

Shepherd S. B. Shi
IBM Tivoli Software, 11501 Burnet Road, Austin, TX 78758。Shi 博士は、Senior Technical Staff Member です。National Taiwan University でコンピューター・サイエンスの理学士の学位を、Stanford University でコンピューター・サイエンスの理学修士の学位を取得し、University of Illinois at Urbana- Champaign でコンピューター・サイエンスの博士号を取得しています。1990 年に IBM に入社して以来、Shi 博士は、DB2 Connection Services、IBM LDAP ディレクトリー、DCE、DFSe WebSecure、および Tivoli Security Management 製品スイートなどの多数の主要なプロジェクトのアーキテクチャーおよび設計作業を主導しています。Shi 博士は、30 件を超える特許を取得し、2006 年度には Tivoli Master Inventor として認められています。

Ron Baker
IBM Tivoli Software, 1516 Westfall Circle, Sanford, NC 27330。Baker 氏は、航空宇宙産業でのエンジニアリング・グラフィックスおよびロボット工学アプリケーション用の数値プログラムの設計および記述からキャリアをスタートさせました。リレーショナル・データベースが出始めた頃には、Baker 氏は、Boeing 社の大規模な財務および構成管理アプリケーションの初期のユーザーの 1 人でした。数年後、Amoco の Computing Research Centerでのデータベースの並列処理および一貫性制約に関する研究に移行した後に、Northrop Grumman のエンジニアリング構成データベース・スペシャリストとして部品表の処理や構成間の調整などの推移的閉包の問題に取り組みました。エンジニアリングおよび製造システムにおける統計的工程管理についての経験を得たのも Northrop Grumman でした。Baker 氏は 1989 年に IBM に入社して、オブジェクト指向言語とリレーショナル・データベースとの統合について研究を行っており、この分野においていくつかの特許を取得しています。それ以降、構造化されていない文書、検索エンジン、およびインターネット・サービスを扱う管理製品に関する研究を行っています。Tivoli Software の CMDB のリード・アーキテクトであり、現在は、総合的なデータ統合イニシアチブおよび高度な分析レポートを担当する Senior Technical Staff Member を務めています。

Naga Ayachitula (Arun)
IBM Thomas J. Watson Research Center, 19 Skyline Drive, Hawthorne, NY 10532 (nagaaka us.ibm.com)。Naga Ayachitula は、現在、シニア・ソフトウェア・エンジニアとして、コンピューティング・サービスおよび IT サービス・マネジメントに従事しており、コンプライアンスの自動化、ネットワーク・アドミッション・コントロール、および IBM Integrated Security Solution for Cisco Networks の修復に対する革新的なアプローチを開発しています。15 件を超える論文を発表しており、特許出願中のものが 15 件あります。

Laura Shwartz
IBM Thomas J. Watson Research Center, 19 Skyline Drive, Hawthorne, NY 10532。Shwartz 氏は、数学、コンピューター・サイエンス、およびソフトウェアの設計および開発に関する研究の経験を持つ Advisory Software Engineer であり、研究対象には、サービス管理、オートノミック・コンピューティング、ワークロード管理およびプロビジョニング、データ・モデリング、および非可換確率が含まれます。現在、数学の博士号の取得を目指して研究を進めています。

Maheswaran Surendra
IBM Thomas J. Watson Research Center, 19 Skyline Drive, Hawthorne, NY 10532。Surendra 博士は、1991 年に University of California at Berkeley から博士号を取得し、同年から IBM Research に勤務しています。半導体の製造からソフトウェア・システムの管理に至る技術分野の研究を行っており、ごく最近では、IT サービスの提供に携わっています。現在、IBM Research の Services organization のシニア・マネージャーであり、サービス提供業務への IT サービス・マネジメント技術の応用に焦点を当てています。

Carole Corley
IBM Software Group, Tivoli Division, 11501 Burnet Road, Austin, Texas 78758。Carole Corley は、管理アプリケーション・セキュリティーを専門とする Advisory Software Engineer です。

University of Florida からエンジニアリング科学の理学士の学位と、航空宇宙制御システムの理学修士の学位を取得しています。

Messaoud Benantar
IBM Software Group, 11501 Burnet Road, Austin, TX 78758。Messaoud Benantar は、シニア・ソフトウェア・エンジニアで、WebSphere Application Server プラットフォームのセキュリティー・サービスに関する研究を行っています。興味の対象は、アプリケーション、システム、およびネットワーク・セキュリティーにあります。Benantar 博士は、アルジェリアのアルジェの University of Science and Technology から技師国家資格を取得し、ニューヨークのトロイにある Rensselaer Polytechnic Instituteから理学修士と博士号を取得しています。

Sushma Patel
IBM Tivoli Software, 11501 Burnet Road, Austin, TX 78758。Patel 氏は、ソフトウェア・エンジニアで、ITSM ポートフォリオの CCMDB の部分について研究を行っています。同氏の開発業務は API、つまり、コマンド・ライン、RMI、および SOAP インターフェースの提供や、ディスカバリー・センサーの開発、および関係に関する研究に集中しています。University of Texas at Austin からコンピューター・サイエンスの理学士と、科学技術の商用化の理学修士を取得しています。Sushma Patel 氏は、いくつかの特許を提出し、革新的なチーム構成およびコラボレーションに関わるさまざまなトピックに関する会議でプレゼンテーションを行っています。

目次へ戻る

上に戻る