IBM サービス・マネジメント・アーキテクチャー

多くの情報技術 (IT) 組織がコスト削減とサービス品質の向上を求められていますが、それと同時に複雑さ、変更、および準拠の要件もますます厳しくなっています。特定の管理ドメインの専門技術が組織内の「サイロ (縦割り構造)」になりがちな従来のシステム管理アプローチでは、もはやこれらの要求を満たすことはできません。

多くの調査によると、最高情報責任者 (CIO) の予算の 70% 近くが人件費であり、その内の半分を超える予算が運用に費やされています。従来の IT 運用の効率は低下しているようです。この非効率性の根本的な原因として最も考えられるのは複雑さです。ソフトウェアとハードウェアが継ぎ足された結果として、まるで複雑な配線図のように、エンタープライズ・アプリケーションの構成が無計画に相互接続されている場合がよくあります。企業では、異なるアプリケーション・アーキテクチャーをベースに何十というアプリケーションが使用されるのは決して珍しいことではありません。このような複雑なトポロジーが拡張されると、運用チームは高機能なリソース指向のツールの助けを借りて複雑さに対応しようとしますが、これにより専門知識の孤立化が引き起こされます。つまり、サーバー、アプリケーション、ストレージ、ネットワーク、セキュリティーなどの専門家に分断されるのです。このようなアプローチは、各ドメイン内では効率的に機能したとしても、複雑なアプリケーション環境を管理するのには効率的ではありません。

図 1. IBM サービス・マネジメント アーキテクチャー

拡大図

要約:

• 従来のシステム管理プロセスは、リソース・ドメイン (ネットワーク、ストレージ、サーバー、アプリケーション、データベースなど) ごとに断片化されており、これらのプロセスを統合するツールはわずかしかありません。
• IT プロセスの効率性は信頼できる構成データにかかっていますが、そのようなデータはまれです。結果として、IT 環境の状態と構成の包括的で正確な概観図を作成するのが難しくなっています。
• 種々のシステム管理製品が統合されていないので、非効率な手動タスクで対応しています。ユーザー・インターフェース (UI) およびデータ・モデルが統合されていないので、自動化の機会が制限され、IT ガバナンスのベスト・プラクティスの利用が阻害されています。

IBM サービス・マネジメント (ISM) は、ビジネス・サービスの管理の自動化と簡易化を目的としたアプローチです。本稿では、サービス指向アーキテクチャーである ISM アーキテクチャーについて説明します。ISM アーキテクチャーは、ビジネス・プロセスの導入と変革のツール、技法、およびアーキテクチャー、情報管理テクノロジー、そして幅広い業界の運用管理テクノロジーの上に構築されます。

図 1 に示す ISM アーキテクチャーは、4 つの主要なコンポーネントから構成されています。(1) ユーザーが対話操作とコラボレーションを行い、 UI のポータル・ベース統合を実現するユーザー・インターフェース (ポータル・ベース・ユーザー・インターフェースと呼ばれます)、(2) プロセス・ランタイムと呼ばれるエンティティー、およびサービス・マネジメント・ソリューションと呼ばれるエンティティーが含まれるプロセス層、(3) 構成管理データベース (CMDB) に相当する情報層、(4) 運用管理製品 (OMP) と呼ばれるエンティティーおよび隣接する統合モジュールに相当する運用管理テクノロジー・コンポーネントの 4 つです。

図 1 には、ツール群、つまりプロセス、UIおよびデータの作成/変更ツールの集合も示されています。ISM アーキテクチャーには、複数の側面に沿った現行の IT コンポーネントおよび管理機能が統合されます。ユーザーの対話操作はすべてポータルにおいて統合され、ユーザーのロールと責任は定義済みのプロセスと統合され、アクティビティー (サブプロセス) は情報層の構成データと統合されます。本アーキテクチャーでは、ポータル、ワークフロー、データ・フェデレーション (連合) に関してソフトウェア・ミドルウェアと業界標準を利用します。

ISM アーキテクチャーにより、ビジネス・プロセス・ワークフロー・ツール、情報統合テクノロジー、および運用管理テクノロジーに基づいたお客様の IT プロセスの変革が可能になります。お客様と我々のサービス・チームとの多くの契約を通じて判明したことは、ますます増大する IT の複雑さに対応するには、お客様が利用されている IT プロセスと手動タスクの自動化の両方に重点を置く必要があるということでした。このアーキテクチャーは、お客様が既存のプロセスを変革し、ベスト・プラクティスを取り込んで徐々にプロビジョニング、オーケストレーション、問題判別といったプロセスを自動化するための方法を提供します。また、これらの IT プロセスの効率は、一般に構成管理データと呼ばれる、IT リソースの許可された状態と検出された状態を記述する正確な情報へアクセスできるどうかによって決まることもわかりました。我々が開発したサービス・マネジメント・ソリューションは、IBM のベスト・プラクティス、および IT インフラストラクチャー・ライブラリー**(ITIL**)¹、²、Control Objectives for Information and related Technology (COBIT**)³、および Enhanced Telecom Operations Map** (eTOM**)⁴ といった業界のベスト・プラクティスをベースにしています。

プロセス層はサービス・マネジメント・プロセス (プロセス・マネージャーまたは PM とも呼ばれる) の概念に基づくソリューションを提供します。サービス・マネジメント・プロセスは、運用管理テクノロジーおよび CMDB と統合されます。サービス・マネジメント・プロセスと関連ツールにより、一連のベスト・プラクティスが取り込まれます。ベスト・プラクティスは、既存のプロセスに対応するようにモデル化およびカスタマイズが可能です。これらのプロセスの中から選択されたタスクを、運用管理ツールを使って徐々に自動化していくことができます。これにより、組織の責任との整合をとりながら IT 管理コストを直接的に削減できます。これらのタスクとシステム管理テクノロジーの統合 (OMP によって実装) は、SOA⁵ を利用することにより実現されます。

連合型の CMDB（フェデレーテッドCMDB） が含まれる情報層は、アプリケーションの自動的な発見、およびシステム、ソフトウェア、サービスのトポロジーの詳細ビューを提供します。オープン・インターフェースにより、プロセス、データ・ソース、および自動化テクノロジーとの統合が簡便になります。IT リソース、トポロジー、関係に関する情報が、管理ツールによって使用される運用レジストリー内に分散されているケースがよくあります。このような情報をフェデレーテッド・データベースに含めない限り、すべての IT リソースの論理ビュー、およびその個々の関係と依存性の情報が利用可能になりません。この論理ビューは、プロセスの効率と有効性を改善する上で重要です。たとえば、変更要求のインパクトを理解して、変更管理プロセスをスムーズに導入するには、リソースの現在の状態に関する情報、ビジネス・アプリケーションとの関係、サービス・レベル目標、準拠ポリシー、他のリソースへの依存関係など、すべての情報が重要な側面となります。サービス・マネジメント・プロセスおよび CMDB を運用管理テクノロジーと統合することによって ISM アーキテクチャーの中核部分が形成されます。

本稿の残りの構成は、以下のとおりです。次のセクションでは、標準的なシナリオに必要なプロセス (この場合はソフトウェア・アップグレードの展開) について説明して、本アーキテクチャーの要件セットを導き出します。その次のセクションでは ISM アーキテクチャーおよびアーキテクチャーによる要件への対応方法について説明します。その次の 4 つのセクションでは、ISM アーキテクチャーの主要な 4 つの側面に焦点を当てます。(1) CMDB、(2) OMP および OMP とサービス・マネジメント・プロセスとの統合、(3) サービスを要求するためのサービス・カタログの使用を含むサービス・マネジメント・プロセス、(4) サービス・マネジメント・プロセスの役割およびプロセス作成を導入する上での考慮事項の 4 つです。それ以降は ISM を導入した経験について説明します。最後のセクションでは、まとめと今後の研究に対する考えを述べます。

このセクションでは、ソフトウェア・アップグレードの要求が含まれるエンドツーエンドのシナリオから始め、ISM アーキテクチャーの上位要件について説明します。その後で、アーキテクチャーのコンポーネントおよびそのインターフェースに関連する要件を明らかにします。

図 2. ソフトウェア・アップグレードを展開するための変更管理およびリリース管理のアクティビティー

拡大図

エンド・ユーザーが組織 (企業内のさまざまな事業部門) 内にグループ化されている大企業に属する、集中化された IT 部門の場合を考えてみます。IT 部門はエンド・ユーザーに多様なサービスを提供し、エンド・ユーザーはこれらのサービスにサービス・カタログを介してアクセスします。サービス・カタログ内のサービスは、サービス要求プロセスによって開始されます。サービス要求プロセスには、組織 (事業部門) からの承認、リソースの調達、およびその他の必要なアクティビティーが含まれる場合があります。

IT 部門が提供するサービスの 1 つに、実稼働環境のアプリケーション・ソフトウェアのアップグレードがあります。実稼働環境は、主幹業務アプリケーションを稼働するサーバーを有し、通常は中断のリスクを最小化し、適切な権限を付与し、利害関係者に通知し、構成情報を正しくアップグレードすることを目的とする厳格な変更プロセスによって管理されています。

図 2 に実稼働環境でソフトウェア・アップグレードを展開するためのサービス要求、変更、リリース管理の各プロセスの手順を示します。エンド・ユーザーは、サービス・カタログを介してサービス要求を送信します。サービス要求プロセスは、サービス要求の処理方法を定義します。サービス要求プロセスは、事業部門の承認から始まります。ユーザーにそのサービスを利用する資格があるかどうかの検証、IT 部門が必要なパラメーター (アップグレードを完了する日付など) でサービスを提供できるかどうかの検証が続き、最後にサービス要求、つまりエンド・ユーザーが要求したアプリケーション・アップグレードによって指定されたインフラストラクチャーの変更が実装されます。さらに、アップグレードの実装に必要な関連するその他の変更がある場合もあります (展開する必要がある新規バージョンのモニター・エージェントなど)。

サービス要求によって指定されるインフラストラクチャーの変更は、通常 IT サービス・マネジメント (ITSM) プロセスによって管理されます。具体的には、ITSM 変更管理プロセスとリリース管理プロセスです。これらのプロセスのベスト・プラクティスは、ITIL によって上位で定義されています。まず、ソフトウェア・アップグレードを指定する変更要求 (RFC) がオープンされます。RFC の情報は、プロセスの成果物として CMDB に保管されます。たとえば、RFC はアップグレード対象のアプリケーション、ソフトウェアのリリース・レベルなどを指定します。RFC のカテゴリー化手順は、プログラムまたは人のいずれによっても実行できます。カテゴリー化は、エンド・ユーザーへのサービス保証レベルのみならずビジネス上の価値に基づいたアップグレードの重要度によって決まる可能性があります。変更が受け入れられると、変更のインパクトが評価されます。ソフトウェア・アップグレードでは、安定とパフォーマンスを確保するためにテストが必要です。インパクト評価では、リリース管理プロセスにおいてアップグレードのパッケージ化、アップグレードのテスト、影響を受ける他のシステムに対応する RFC のオープン (たとえばアプリケーション・モニター・システム) などの手順が必要です。アプリケーションの可用性の最大化など、インパクト評価にはその他の考慮事項が含まれる場合があります。インパクト評価の結果によっては、可用性管理やサービス継続性管理など、その他のサービス・マネジメント・プロセスによっても RFC を処理する必要がある場合があります。

インパクト評価に続いて、変更を検討します (変更のレビューと承認)。承認されると、展開のためにアプリケーション・アップグレード要求がスケジュールに入れられます。アップグレードの展開には、アプリケーションの実際のアップグレードを実行するだけでなく、ターゲット・システムを識別してステージングするために、リリース管理プロセスでの手順も含まれます。ソフトウェア・アップグレードの展開は、Tivoli* Provisioning Manager⁶ などの OMP を使用して実現することもできます。Tivoli* Provisioning Manager は、ソフトウェア・アップグレードの配布とインストールを自動化し、複数のシステムにまたがって一貫性のある方法で確実にアップグレードを実行します。展開の最後の手順では、変更の検証が必要です。その後 RFC がクローズされます。

このシナリオでは、(データおよびインターフェースも含め) 変更管理プロセス、リリース管理プロセスおよび OMP を統合する必要性について説明します。CMDB は、(1) タスクにリソース情報およびプロセス情報のリポジトリーを提供し、(2) プロセスをまたがって一貫性のあるデータ表現を提供し、(3) OMP と他のプロセスとの統合を可能にすることにより重要な役割を果たします。たとえば、CMDB によって保持されるリソース間の関係を使用して、ビジネス・サービスの特定のアプリケーション・コンポーネントに対するソフトウェア・アップグレードにより影響を受けるビジネス・サービスを評価できます。

図 2 に示す ITSM プロセスは、変更管理プロセスおよびリリース管理プロセスにおける上位アクティビティーを定義します。これらの各アクティビティー内で、IT スタッフ (ユーザー) は指定したアクティビティーを実行するタスクを実行します。ユーザーは、ロールおよびロールと関連付けられた権限に則ってこれらのタスクを実行します。たとえば、ソフトウェア・アップグレードのテストには、まず開発リポジトリーからのビルドをチェックするタスクが含まれ、その次にテスト・ケースを定義するタスク、テスト範囲を確認するための承認、テスト環境のプロビジョニング (以下同様) と続く可能性があります。

組織がベスト・プラクティス・プロセスの採用を進めるのに伴い、通常はプロセス・アクティビティーのレベルにおいて標準化が行われるようになります。ただし、多くの場合、各アクティビティーの基礎となる特定のタスクは組織に固有なものです。さらに、これらのタスクは、たとえばプロセスが管理する変更のタイプ (ソフトウェア・アップグレードかストレージの変更かなど)、地理的な考慮事項、テクノロジーの発展など、実装環境の考慮事項に基づいて非常に速いペースで変更されます。たとえば、仮想化されたインフラストラクチャーにおいてインパクト分析のために実行されるタスクは、専用サーバーの環境とは大幅に異なる可能性があります。ISM アーキテクチャーでは、組織で使用するためのプロセスの構成を行う IT スタッフのスキルに合わせたツールにより、タスク (および関連する UI とデータ) の定義と拡張を行えます。プロセス・アクティビティーとタスク間の関係を図 3 に示します。

図 3 では、変更プロセスが、RFC をオープンする、RFC をカテゴリー化、評価、承認、実装する、RFC をクローズするという標準的なアクティビティーによって表されています。実装アクティビティーの主要なタスクの一部も示されています。たとえば、変更の実装には、要員の割り当てと変更パッケージの作成 (タスク 1 と 2、通常は手作業) および変更の実際の実装 (タスク 3、通常は Tivoli Provisioning Manager for Software などの自動化ツールによって実装) が必要になります。アプリケーションは、デプロイメント・エラーを受けやすいため、デプロイメント前のテストを行うタスクを追加する必要があります。このようなタスク (図 3 のタスク 3) を簡単に追加できるのは、IBM サービス・マネジメント アーキテクチャーにとって重要な要件です。

図 3. 変更管理の選択されたアクティビティーとタスク

拡大図

前述のシナリオの分析から、以下のような ISM アーキテクチャーの上位要件を定義できます。

1. アクティビティーとタスクおよび関連ロールの定義を含むベスト・プラクティス・プロセスを提供する。
2. 異なるプロセスの統合に加え、プロセスの定義と実行のための一貫性のある統合運用環境 (ランタイム) を提供する。
3. セキュアなアクセス・コントロール (認証および権限) により、複数のロールにまたがってアクティビティーおよびタスクのコラボレーションと調整を行える機能を提供する。
4. リソース・データ、プロセスの成果物、およびそれらの関係を保管する CMDB を提供する。CMDB は、エンド・ユーザーと自動化タスクの両方がデータを一貫性のある方法で表示および使用できるようにするために、プロセス・ランタイムと密接に統合されている必要があります。
5. サービス・マネジメント・プロセスを OMP と統合して、管理操作の自動化をサポートする。
6. CMDB および OMP からの情報とビューを集約できる UI を提供する。
7. プロセス・タスクの作成および構成の容易性 (拡張可能な UI、ロジックおよびデータも含む)をサポートし、カスタマイズによって実装されたタスクに固有の可変性に対応する。さらに、アーキテクチャーは、IBM とサード・パーティーの OMP および他のビジネス・プロセスと IT プロセスとのプロセス統合をサポートする必要があります。

このセクションでは、上記のセクションで識別した上位要件を、アーキテクチャーの実装を実現するのに必要な最も重要な機能に重点を置きながらさらに詳しく説明していきます。

ISM アーキテクチャーにより、変更管理、リリース管理、インシデント管理、および問題管理といったサービス・マネジメントのさまざまなドメインのベスト・プラクティス・プロセス (ITIL、COBIT、および eTOM など) の導入が可能になります。これらのベスト・プラクティスは、IBM Tivoli Unified Process (ITUP)⁷ に取り込まれています。ITUP は、これらのベスト・プラクティスの文書化に加え、ベスト・プラクティスを計画して導入するためのツールも提供します。ITUP は、プロセス設計者が、ISM アーキテクチャーを利用してサービス・マネジメントのベスト・プラクティスを採用および導入するために使用できます。

ISM アーキテクチャーは、複数のロール内のユーザー間でタスクとコラボレーションの調整および自動化をサポートします。たとえば、変更要求者のロールにあるユーザーが RFC の作成を開始する一方で、変更レビューアーまたは変更マネージャーのロールにあるユーザーが RFC の受け入れと分類を実行します。さらに、特定のサービス・マネジメント・ドメインに対応するプロセスは、他のドメインのプロセス (およびロール) と対話する必要がある場合があります。

プロセス、アクティビティー、およびタスクは完全に手動にする (つまり、特定のプロセス・アクティビティーについてユーザーが UI を介してプロセスと対話し、必要なタスクを手動で実行する)、完全に自動化する (つまり、開始後は人が介入せずに各プロセス・アクティビティーによって定義されたタスクが実行される)、あるいは部分的に自動化する (つまり、特定のプロセス・アクティビティーまたはタスクを手動で実行し、その他を自動化する) ことが可能です。

ISM ランタイム・アーキテクチャーは、一貫性のある反復可能な上位プロセスを定義する機能を提供すると同時に、プロセス・アクティビティーの基礎となるタスクの可変性と構成の容易さに対応します。これは、IBM WebSphere* Business Integration の標準ミドルウェア・ランタイム機能および Web Services Business Process Execution Language (WS-BPEL) を使用して、正式なプロセス定義、ランタイム、タスクと作業管理機能によるそれらのモニターと統合、および関連ツールを活用することによって達成されます。

ISM 導入の主な特徴は、タスクを表示、要求、再割り当て、委任および実行するユーザー (IT スタッフ) のサポートです。さらに、ISM 導入では、標準化およびパラメーター化されたコミュニケーション・テンプレートによる統合された通知を可能にします。UI、アプリケーション、および統合セキュリティー・モデルにより、ユーザーは、特定のユーザーまたはプロセスでユーザーが実行するロールに割り当てられたタスクを表示および要求できます。さらに、セキュリティー・モデルは、タスクによって参照されるオブジェクトへの許可されたアクセスを提供することもできます。プロセス・タスクの状態に対してエスカレーションを定義できます。これにより、たとえば規定された時間内にタスクが完了しなかった場合にアクション (通知など) を実行できるようになります。将来の機能拡張としては、インスタント・メッセージングなどのコラボレーション機能とのより密接な統合があります。

主に ISM プロセスとタスクは、相互関連があるさまざまなリソースと管理ドメインにまたがるリソース管理を処理します。リソース、その構成、および他のリソースとの関係を発見する機能は、サービス・マネジメント・プロセスを導入する上でのコア機能です。モデル化、およびリソース構成情報と関係情報の保管により、リソースに対する構成変更を管理するプロセスを確立できます。これは、他のすべてサービス・サポート・プロセスおよびデリバリー・プロセスにとって重要です。CMDB は、リソースに関する構成情報と関係情報を保持するリポジトリーです。

ISM アーキテクチャーにおける CMDB の主な機能は、以下のとおりです。

1. 発見、アプリケーション・マッピング、および可視化—この機能によってリソースを発見し、ビジネス・アプリケーションおよびリソースに依存するサービスをリソースに関連付けます。発見は、IT インフラストラクチャー内のリソース、他の管理システムによって収集されたリソースに関する情報、またはエンド・ユーザーによって手動で保持されているデータ (たとえば、スプレッドシート) に対して直接ターゲットとなれます。さらに、リソースがサポートするビジネス・アプリケーションにリソースを関連付ける機能も提供されます。この対象範囲は、リソース構成情報に基づく自動化マッピングから手動で指定された関係にまで及びます。
2. フェデレーション—可能性のあるすべてのリソース構成情報と関係情報を CMDB に保持するのは、変更の整合性を維持するオーバーヘッドに加えてスケーラビリティーの問題が生じる可能性があります。フェデレーテッド・アプローチにより、リソースに関する詳細情報を持つ他の管理システムにアクセスすることでリソース構成に関する情報にアクセスできるようになります。フェデレーションは、リレーショナル・データベース、XML (Extensible Markup Language) 文書、スプレッドシート、および文書リポジトリーなどのさまざまなデータ・フォーマットやリポジトリーをサポートする必要があります。
3. リコンシリエーション (整合化)—リソースは複数の管理システムによって管理される場合があり、それぞれの管理システムが管理の特定の側面を担当している可能性があります (たとえば、IBM Tivoli Monitoring はリソースをモニターし、その一方で IBM Tivoli Provisioning Manager for Software はリソースへのソフトウェア配布を担当する場合があります)。CMDB 内にリソースの単一のインスタンスが存在するように、リソースが個々の管理システムによって識別されるさまざまな方式の整合をとる必要があります。これは、1 つ以上の命名規則を定義できるようにすることで達成されます。個々の管理システムが命名規則に必要な 1 つ以上の属性にアクセスできるようになっている場合には、優先順位付けされた命名規則により内部の複数の命名規則の整合化を認めることが可能になります。命名規則については、本号の IBM Tivoli Change and Configuration Management Database (CCMDB) に関する文書⁸で詳細に説明しています。
4. 構成属性の信頼できるソース—リソースの構成と関係の属性のさまざまな面を提供する複数の管理システムが存在する場合には、特定の属性について信頼できるプロバイダーを指定できる必要があります。
5. アクセス—CMDB は、CMDB 内のデータにアクセスし、データを CMDB にインポートするオープン・インターフェースを提供します。プロセスおよび他の OMP が CMDB データのアクセスと取り込みの両方を行える Java** および EJB** ベースの複数のインターフェースを介したデータ・アクセスが可能です。さらに、CMDB データ･モデルの標準 XML フォーマット (Identity Markup Language—IDML) からデータをロードできる組み込み機能も提供されます。

ISM プロセスの一部として実行されるタスクは、タスクの自動化に IBM の OMP とサード・パーティー製の製品を利用します。その結果、サービス・マネジメント全体の効率が向上します。広く導入されている OMP には、モニター、イベント・インフラストラクチャー、プロビジョニング、配布、可用性、ワークロード管理、レプリカ生成、バックアップ、セキュリティーをはじめとする多くの機能があります。たとえば、大規模なソフトウェア・アップデートの展開では、IBM Tivoli Provisioning Manager for Software を利用して、ソフトウェア・アップデートを多くのデスクトップにスケジュールに基づいて自動配布できます。ISM アーキテクチャーにより、論理管理操作 (LMO) を定義できます。LMO は、サービス・マネジメント・プロセスと運用を実行する OMP との間のインターフェースを提供します。Web サービスをベースとする SOA を使用してこれらのインターフェースが実装されます。これにより、プロセスと、機能を提供する OMP との間の疎結合が実現され、最善の OMP テクノロジーを利用した実装が可能になると同時にプロセスの整合性が維持されます。

この疎結合を実現するために、統合モジュールを使用して LMO インターフェースを実装します。統合モジュールは、以下の 2 つの主要な機能を実行します。

1. 1. コマンド行インターフェースまたはアプリケーション・プログラミング・インターフェース (API) を搭載する可能性のある OMP のネイティブ・インターフェースを使用することで、1 つ以上の OMP に対する 1 つ以上の呼び出しを実装します。
2. 2. 呼び出し引数 (プロセスによって指定され、CMDB リソース・モデルに基づく) を OMP が理解する引数にマップします。たとえばサーバーを識別するためにプロセスおよび CMDB が使用するグローバル固有 ID (GUID) を、同じサーバーを内部的に識別するためにIBM Tivoli Provisioning Manager for Software が使用するオブジェクト ID にマップする必要があるかもしれません。

プロセスの展開および自動化には、さらに LMO と実装が必要になります。ISM アーキテクチャーは、特定のプロセスおよびタスクと対話するために、これらの統合モジュールのインストールと構成をサポートします。

プロセスの有効性と効率を向上させるには、ユーザー間の効果的なコラボレーションを可能にする UI を提供して、ユーザーがタスクを効率的に実行できるようにするのが重要です。ISM アーキテクチャーでは UI の統合にポータルを使用します。ユーザーはポータルを使用して、自分に割り当てられたタスクを表示および要求し、アプリケーションを起動し、リソースのトポロジーとその関係を表示できます。たとえば RFC のインパクトを評価する場合には、他の RFC によってスケジュールに入れられているリソースへの変更を表示するだけでなく、ビジネス・アプリケーションとリソースの関係を表すトポロジーを可視化する必要があるかもしれません。ユーザーはポータルを使用して、これらの別々のビューを同じワークスペース上に作成できます。これにより、インパクト評価アクティビティーを実行するユーザーの効率が向上します。標準ベースのポータル (JSR-168)⁹ を使用することで、UI のカスタマイズが可能になります。

また UI を利用して、ユーザーが実行するタスクの自動化のための OMP の呼び出し、他のユーザーへの通知、プロセスの一部として作成した添付ファイルや文書の参照といったアクティビティーを可能にすることで、ユーザーの効率を高められます。

前述したとおり、プロセス、アクティビティー、タスクを作成および変更するツールを提供する必要があります。ISM アーキテクチャーでは、データベース構成、アクティビティーとタスク間の条件付きルーティング、および UI を処理するための広範囲のツール・サポートに加え、WebSphere ツールのサポート (WebSphere Business Modeler および WebSphere Integration Developer) を利用します。

データ、プロセス、UI コンポーネントの構成を簡易化するのに加え、1 つの環境から別の環境への移動 (たとえばテスト環境から実稼働環境) をサポートする方法で構成の変更を保持する必要があります。ISM アーキテクチャーにより、これらの構成の変更をメタデータ (XML) として保管できます。新しい環境へ移行する場合は、手動での製品の再構成を必要とせずに、このメタデータをインポートして構成の変更を取り込めます。

CMDB は、IT インフラストラクチャー・リソースに関する構成情報と関係情報を保持するリポジトリーです。CMDB に保管されているリソースは、構成アイテム (CI) と呼ばれます。CMDB は、アプリケーションの自動的な発見機能と、システム、ソフトウェア、サービスのトポロジーの詳細ビューを提供し、これらのリソースの許可された状態とその関係を保持できます。CMDB により、他の管理システムやデータ・ソースに保持されている詳細なリソース構成データへの統合されたアクセスが可能になります。CMDB へのオープン・インターフェースにより、プロセス、データ・ソース、および自動化テクノロジーと簡単に統合できます。

CMDB は、IT 構成の状態についての信頼できる情報を提供します。信頼できる情報であるためには、変更/構成管理プロセスによって変更を管理して、CMDB のデータの品質と正確さを維持する必要があります。CMDB は、以下のようなサービス・マネジメント・タスクをサポートします。

• 要求された変更のインパクトを評価する (変更管理)
• インシデントの影響を受けるビジネス・サービスを評価する (インシデント管理)
• 監査を行い CI およびその関係の許可された状態と実際の状態を比較する (構成管理)

図 4 に示すように、CMDB の目標は、(1) リソースおよび関係 (実際の状態) を発見する、(2) 実際の状態を許可された状態と比較する、(3) 実際の状態と許可された状態の間の差異に取り組むために明確な変更プロセスおよび構成プロセスを呼び出すことによって達成されます。さらに、CMDB にはプロセス成果物 (RFC など) へのリンクが保持されており、どのプロセスが 1 つ以上の CI を変更し、関連文書と成果物 (たとえば変更評価文書など) にアクセスするのかの決定を容易にします。

CMDB は、以下のようにアーキテクチャーの他のコンポーネントへ重要なインターフェースを提供してサービス・マネジメントを実現するので、ISM アーキテクチャーの中心的な存在です。

• IT インフラストラクチャーおよび既存の管理ツールへのインターフェースを提供して、既存のデータ・ソースの発見、リコンシリエーション、およびフェデレーションを可能にします。
• プロセス層へのインターフェースを提供して、プロセス・タスクを可能にします。
• UI 層へのインターフェースにより、CMDB データおよび関係を可視化します。
• 構成ツールへのインターフェースにより、CMDB スキーマおよび拡張性を管理します。

以降のセクションでこれらの側面のいくつかについて説明します。

図 4. 構成管理データベース (CMDB)

拡大図

CMDB は、リポジトリーにデータを取り込んで保持するために、次の手段をサポートします。

• データ・ディスカバリー—CI についての情報は、センサーによって IT インフラストラクチャーから直接発見できます。さらに、データ・インポート手段により、CI に関するすでに発見された情報が含まれている可能性がある他のソース (管理ツール、スプレッドシートなど) からデータを取り込みます。
• データ・フェデレーション—別のリポジトリーにある CI データへの論理アクセスを可能にします。
• データ・リコンシリエーション (整合化)—同じ CI に関する複数のデータ・ソース (差異モニター・ツールやプロビジョニング管理ツールなど) のデータの発見の結果が、CMDB 内の単一システムのレコードになるようにします。
• ユーザー入力およびアプリケーション・プログラミング・インターフェース—これらのインターフェースにより、CMDB 内のデータの作成、読み取り、更新、削除を行います。

CMDB の重要な機能の 1 つとして、別のソースから発見されたデータのルール・ベースのリコンシリエーション (整合化) があります。1 つのリソースに対して複数のリコンシリエーション・ルールを指定できます。たとえば、サーバーは、メーカー、モデル、およびシリアル番号、あるいは同様に MAC (メディア・アクセス・コントロール) アドレスまたはホスト名で識別できます。複数の命名規則が適用可能である場合は、CMDB によって別名が作成されます。これにより、CMDB は同じ CI の同じリソースについて追加情報ソースの整合をとることができます。

可能性のあるすべてのリソース構成データと関係データを CMDB へ保持すること、およびそれに伴うスケーラビリティーと整合性の問題を回避するために、CMDB はデータ・フェデレーション (連合) を実装しています。短時間で変更されるデータ (モニター・システムによって保持されるリソースのステータスなど) は既存の管理システムの管理下に置かれたままになりますが、論理的には CMDB の一部となります (つまり、CMDB 内の情報へリンクされます)。このデータへのアクセスは、Websphere Information Integrator¹⁰–¹⁴ などのミドルウェア製品のフェデレーション機能を使用して透過的に可能になります。

図 5. CMDB を使用したアプリケーション依存関係の可視化

拡大図

CMDB は、CI の許可された状態 (属性および関係) を維持する機能も提供します。許可された状態は、常に適切なインパクト分析および承認を伴う変更/構成管理プロセスによって変更されます。CI および関係に関する許可されたデータと実際の (発見された) データを持つことによって、監査や準拠性検査といった機能が可能になります。

CMDB 内のデータには、基礎となるデータベース構造に被せられた抽象化されたオブジェクト層を使用して、コンシューマー（UI、プロセス・タスク、および OMPを含む）がアクセスします。コンシューマーから見た抽象化は、一連の Java オブジェクトおよびそれらに対する操作（検索、作成、読み取り、更新、削除など）になります。オブジェクト層の抽象化により、データベース・テーブルのレイアウトおよびそのレベルにおいて利用可能な最適化がコンシューマーから隠蔽されます。CMDB については、本号の別の文書⁸ で詳細に説明します。

図 5 は、構成要素である IT インフラストラクチャー・コンポーネント (ソフトウェア・アプリケーション、サーバー、ストレージ、およびネットワーク) 上のビジネス・アプリケーション (図 5 で示されているのは発注管理アプリケーション) の依存関係を可視化するために CMDB を使用する例を示しています。ユーザー (IT スタッフ) は、この可視化により、反復的に特定のコンポーネントをドリル・ダウン (つまりデータをより詳細なレベルで表示) できます。たとえば、ユーザーは、ビジネス・サービスから基礎となるソフトウェア・コンポーネント、そしてソフトウェアがインストールされているサーバーへとドリル・ダウンできます。ユーザーは、ソフトウェアおよびサーバーの構成の詳細 (たとえば、WebSphere アプリケーション・サーバーにインストールされている EJB) を取得できます。

CMDB アーキテクチャーは、次のような固有の機能を提供します。

• オープン・スタンダードおよび現場での経験に基づく運用の拡張機能をサポートする包括的データ・モデル (CDM)。これは、お客様の CMDB の導入を大幅に加速します。
• 変更プロセスおよび構成プロセスと OMP が密接に統合されることにより、CMDB の整合性が実現されます。さらに、自動化された変更プロセスおよび構成プロセスをサポートできるので、管理製品に機能を委任できるようになり、サービス・マネジメントやリソースのオートノミック動作を管理システムと統合するアーキテクチャーが提供されます。
• オープン・インターフェースと標準的なデータ交換フォーマット。

ITIL または COBIT のようなベスト・プラクティス・プロセスと OMP を統合するのは、プロセス・アクティビティーおよびタスクの効率を改善する上で重要なイネーブラーとなります。モニター、イベント管理、プロビジョニング、および管理製品の使用許諾などを提供する OMP により、大規模なリソース・ドメインへサービス・マネジメント・プロセスを適用できると同時に、反復作業のコストとそれに付随するエラーを最小化できます。

ISM プラットフォームは、OMP とサービス・マネジメント・プロセスとを結びつける3種類の統合をサポートします。すなわち、UI 統合、データ統合、および機能統合の 3 種類です。

データ統合は、CMDB によって可能になります。データを OMP から移動して CMDB に保管するか （発見)、OMP に置いたままで CMDB に論理的にマップ (フェデレーション) できます。この統合については、「構成管理データベース」セクションの「データ収集 (発見)、リコンシリエーション、およびアクセス」サブセクションで説明します。

OMP を起動し、その UI で対話操作を行って、手動タスクを実行する場合が多くあります。以下のような例があります。

• サーバーで要求された変更を実装している間に (変更管理プロセスの一環として)、変更のデプロイヤーが Tivoli Provisioning Manager のデータ・センター・モデルに保持されているサーバーについての詳細情報を確認したい場合があります。
• 障害のあるコンポーネントを特定するために (インシデント管理プロセスの一環として)、サービス・デスク・アナリストが Tivoli Business Services Manager を起動しなければならない場合があります。

タスクが実行されている 1 つ以上の CI のコンテキストで OMP UI を起動して、OMP UI によるユーザーの対話操作を最適化できます (つまり重複した入力とナビゲートするパネル数を最小化できます)。OMP UI を起動すると、適切なコンテキスト・ビューが表示されるだけでなく、OMP が起動されている CI に関するコンテキスト情報も渡されます。

コンテキストでの起動は、ISM アーキテクチャーの一般的な手段として提供されます。コンテキストでの起動は、サービス・マネジメント・プロセスと OMP 間、OMP 間で直接的に、異なるプロセス間で、およびプロセスと CMDB 間で使用できます。図 6 は、ビジネス・インパクトを判別するインシデント管理プロセスでの障害分析タスクを示しています。障害分析タスクでは、障害のあるコンポーネント、影響を受けるサービスおよび影響を受けるサービスレベル･アグリーメント (SLA) を識別します。また、ユーザーは障害分析タスクの UI により、OMP (Tivoli Enterprise Portal、Tivoli Business Systems Manager、および Tivoli Service Level Advisor) を起動して、リソース、そのステータス、および確立されている SLA についての詳細を取得できます。

機能統合により、プロセス・タスクはプログラムで OMP を呼び出して特定のタスクを実行できます。OMP の呼び出しは、SOA アプローチに準じて、LMO を使用して実装されます。LMO は、OMP によって提供される特定の API と疎結合される抽象的な論理インターフェースです。前述したとおり、LMO は OMP のサービス抽象化、およびバージョン、インスタンス、ロケーションからの一定の透過性を提供します。このアーキテクチャーにより、LMO を実装する (つまり LMO を特定の OMP にバインドする) 統合モジュールを、プラットフォーム内で個別に開発、インストール、および構成できます。これにより、OMP ベンダーのエコシステムを構築して ISM プラットフォームと統合する機会が提供されます。統合モジュール・アーキテクチャーには、以下の重要な側面が含まれます。

図 6. コンテキストでの起動の運用管理製品との統合

拡大図

• 統合モジュールは、Web サービス記述言語 (WSDL) インターフェース定義を使用して Web サービスとして定義されます。
• 統合モジュールは、ターゲット OMP が提供するインターフェースに LMO の構文とセマンティクス間のバインディングおよび機能マッピングを提供して、1 つ以上の LMO を実装します。
• バインディングと機能マッピングを実現するには、OMP が理解できるように、統合モジュールが CI へのプロセス参照を 1 つ以上のリソースの対応する ID に変換します。これは、CMDB CI の ID とリソース管理が可能な各 OMP のリソース ID 間のマッピングを保持する CMDB との対話により達成されます。
• それぞれの統合モジュールは、OMP のロケーション、統合モジュールがサポートする LMO、および統合モジュールが LMO をサポートするための CI のセットまたは集合に関する適切な情報とともに CMDB に登録されます。

OMP 統合の実装に SOA を使用するところが、ISM アーキテクチャーの重要な差異化要因です。サービス・マネジメントの成熟度と自動化が進むにつれて、さまざまなサービス・マネジメント・プロセス・ドメインについて標準化された LMO の定義が促進されると考えています。

ほとんどのエンド・ユーザーが最初に使用する ISM のビューは、サービス・プロバイダーが提供するサービスの一覧が載ったサービス・カタログです。IT 組織にとっては、サービス・カタログがエンド・ユーザーとのインターフェースに相当します。エンド・ユーザーがカタログからサービスを選択すると、図 2 に示すように、サービス要求が作成されて適切な IT プロセスによって処理されます。

ISM アーキテクチャーにより、サービス定義ツールを使用してサービスを XML で定義し、サービス・データベースに保管できます。サービス・プロバイダーがサービスを提供する場合、これらのサービスに対する資格 (データの指定ビューへのアクセスなど) は、組織のメンバーシップやお客様の顧客情報などを基準にして付与されます。サービスのリストは、パスワード・リセットのように単純で完全に自動化されたエンド・ユーザー・サービスから、アプリケーション環境のプロビジョニングやアップグレードのようにより複雑なサービスまで多岐にわたります。またサービス定義には、関連する SLA の条項、等級や請求処理の条項、契約上の取り決めのテンプレートの設定などが含まれます。サービス定義だけでは新しいサービスを成立させるのに十分ではないことに注意してください。サービスを提供できるようにするには、その前にすべての適切なサービス遂行のワークフロー、および内部プロセスとシステムのほかに外部のサービス・プロバイダーとの統合を確立する必要があります。

定義済みのサービスはサービス・ポータルを介してアクセスできます。サービス・ポータルのビューは、ユーザー用にカスタマイズが可能です。ユーザーは、要求、サービス・グループの表示、および選択する資格があるサービスについて、サービス・カタログを表示できます。たとえば、ユーザー ID サービスのカタログを表示して、パスワード・リセット・サービスを選択できます。ユーザーは選択する時点で、サービスに関連付けられた属性の値を入力するように求められます。UI に加え、サービス・リストの追加/変更/照会などのプログラム・インターフェースも提供されます。

サービス・カタログには、サービスに関連するコスト情報も表示できます。これは、たとえば IT 組織が提供する特定のサービスに料金を設定している場合などに当てはまります。このようなケースでは、エンド・ユーザーはサービスの要求時にサービス・コストを考慮に入れられます。

サービス・カタログでは、ビジネス・ユーザーが、サービスを定義し、そのサービスに関連するビジネス・ルールを作成、変更するインターフェースも提供します。たとえば、ビジネス・ユーザーは、価格情報、利用可能な割引のレベル、特定のサービス要求を満たすために使用するリソースの種類などを指定できます。またビジネス・ユーザーは、レポート・ビューやダッシュボード・ビューの形式でサービス・パフォーマンスのデータおよび分析にアクセスできます。これにより、ビジネス・ユーザーには、サービスの実績 (たとえばどのサービスの注文が多いかなど) についてのメトリックが提供されます。

ユーザーがカタログからサービスを選択すると、IT 組織は内部の能力を駆使して、あるいは外部から提供される (外部委託される) 能力と内部の能力を結集して、サービスを遂行する必要があります。パスワード・リセットなどの単純なサービスは簡単に自動化できるのに対し、サーバー・プロビジョニングなどのより複雑なサービスでは、要求書、検討、評価、および承認といった人による介入が必要になる場合があります。サービスの遂行に必要な一連の作業は、サービス要求フローと呼ばれます。

サービス要求管理では、サービス要求の遂行を管理することに加え、サービス遂行の進捗についての定期的な状況レポートをサービス要求者に提供します。この情報は、可用性や使用効率などのパフォーマンス計測値のサービスをモニターするためにも使用できます。

プロセス・マネージャー (PM) は、OMP および CMDB と統合された実行可能なワークフローによってサービス・マネジメント・プロセス実装環境を提供するアプリケーションです。さらに、PM は実行メトリックを追跡する機能や、IT 組織がボトルネックを特定して組織の生産性を高められるダッシュボードとレポートを提供します。

サービス・マネジメント・プロセスは、作業要求を受け取ることによって開始されます。このような作業要求の一般的な例として RFC があります。IT 組織が処理する作業要求は非常に多様であるため、ISM アーキテクチャーは作業要求を分類するための柔軟で拡張可能な手段を提供します。たとえば、RFC には、ハードウェア変更、ソフトウェア変更、ネットワーク変更またはストレージ変更などが含まれる可能性があります。ソフトウェア変更は、さらに新規アプリケーションのデプロイメント、アプリケーションのアップグレードなどに分類できます。それぞれのタイプの作業要求には独自の拡張属性値のセットが必要であり、これによって作業要求の実行に必要なすべての情報が収集されます。

この作業要求の実際の遂行は、アクティビティー (サブプロセス) とタスクから構成されるプロセスによって処理されます。プロセス・フローは、アクティビティーとタスクを図式化したものです。本稿の目的では、タスクをスケジュールに入れて割り当て可能な作業単位と定義します。PM は、プロセス・オーナーが各タイプの要求に関連付けられたフロー・テンプレートを定義できる手段を提供します。これにより、各ユーザー組織は、組織のポリシーと指針を使用する一方でエンドツーエンドのサービス・フローの実行もサポートしながら、作業の実行方法をコントロールできるようになります。エンドツーエンドのサービス要求と遂行フローは、各 PM で管理され、特定の要求が各プロセス・ドメインを進むときに使用される一連のサービス要求フローとフロー・テンプレートを開始することで、実現されます。

ドメイン固有の要件に加えてサービスの幅広さと複雑さにより、エンドツーエンドのプロセス・ワークフローを事前定義することは困難です。アクティビティーが既知のものであっても、タスクが固有の要求と組織のポリシーによって多様になる場合が多くあります。固有のタスク、およびタスクの順序付けとスケジューリングは、要員の利用可能性と組織の責任に加え、ドメイン固有の要件など、数多くの動的な考慮事項によって決まる可能性があります。PM アーキテクチャーは、プロセス・フローの一部として組織のさまざまな人によって実行されるタスクを表す方法をいくつか提供します。最も基本的な表現は、作業明細構造（Work Breakdown Structure）の形式で表す方法です。この表現では、アクティビティーで実行されるタスクのリストおよびタスク間の依存関係を識別できるだけです。もう 1 つの表現では、タスクのより高度な順位付けのニーズ (条件付き分岐を含む) をサポートする明示的なワークフローを定義できます。

タスクは、個人またはチームのいずれへの割り当ても可能であり、通常はロールによって識別され、Lightweight Directory Access Protocol (LDAP) セキュリティー・グループとして実装されます。タスクがチームに割り当てられると、そのタスクが LDAP グループの全メンバーの受信ボックスに送信されます。プロセス・フローに参加するユーザー (IT スタッフ) は、ポータル UI にログインして各自の受信ボックスのタスクを表示して確認します。ユーザーはタスクを受け入れるか要求するかを選択でき、その時点で他のチーム・メンバーの作業キューからタスクが削除されます。ユーザーがタスクを要求すると、タスクを実行するための UI が起動されます。

プロセス・オーナーと業務マネージャーは、特定の作業要求の現在のステータスを PM コンソールに表示したり、完了したタスクとまだ完了していないタスクを表示したりできます。プロセスの実行は、主要業績評価指標 (KPI) の定義を使用してモニターできます。それによりボトルネックとなっている非能率的な部分がわかり、プロセスの改善につなげられます。

すべての PM が使用する情報の共通のリポジトリーが CMDB によって提供されます。たとえば、変更管理 PM と IBM Tivoli Release Management PM が CMDB の情報を使用して、特定の変更が必要なソフトウェア・パッケージとターゲットを判別できます。さらに、構成管理プロセスが、CMDB 内の許可された構成データの更新を担当します。これにより、プロセスをまたがりデータの整合性が確保されて統合が容易になります。たとえばサーバーに新しいソフトウェアが導入されると、IBM Tivoli Configuration PM が新しい複数の CI とそれらの関係についての情報を使って CMDB を更新します。その後、例えばそのサーバーで稼動しているサービスやアプリケーションに対してインシデント・チケットがオープンされた時には、インシデント管理 PM がその更新された情報を利用できるようになっているのです。

PM は、他のプロセスとの統合を簡易化するために Web サービス・インターフェースをサポートします。たとえば、変更管理 PM は、RFC の作成、RFC のステータスの照会、RFC の取り消しなどを行うために Web サービス・インターフェースをサポートします。同様に、IBM Tivoli Release Management PM は、リリースの作成、リリース詳細の照会、リリースの延期、および取り消しを行うためにインターフェースをサポートします。

我々の ISM アーキテクチャーの実装環境には、本稿で説明したほとんどすべての主要コンポーネントが含まれています。実装環境は WebSphere ミドルウェア上に構築され、インターフェース、ポータル、データ・モデル、およびプロセス・ワークフローの業界のオープン・スタンダードを使用しています。統合されたコアの IBM 運用管理機能には、Tivoli Monitoring、イベント管理、ビジネス・システム管理、プロビジョニングおよびソフトウェア配布、ストレージ管理、セキュリティー管理、およびネットワーク管理などがあります。IBM Tivoli Change and Configuration Management Database (CCMDB) は、CMDB および CMDB の整合性を維持するのに必要な変更管理および構成管理プロセスが含まれる統合オファリングです。CCMDB は、リソースおよびその関係に関する情報のフェデレーションまたは発見、データ間の依存関係の可視化、および構成の変更を管理するプロセスをサポートします。PM は、リリース管理、ストレージ・プロビジョニング管理、可用性管理、キャパシティー管理などの多様なドメイン用に実装されています。

ISM の実装環境は疎結合であるため、漸進的な採用と増分的な導入が可能です。これは、さまざまな実装環境における一般的な採用パターンです。IBM Tivoli OMP の導入およびこれらの製品間の統合は、お客様の多大な賛同を得てきました。ISM の導入により、OMP を CMDB および PM と統合することによって、サービス・マネジメントを採り入れる革新的な方針が提供されます。

CCMDB が提供するディスカバリー機能とトポロジーの可視化機能の価値が有効に採り入れられて実現されてきました。これは、ISM の構想とアーキテクチャーを採り入れる上で重要なステップとなっています。ディスカバリーおよびアプリケーションの依存関係のマッピングを導入すれば、IT プロセスの効率を改善するのに必要な重要な情報がユーザーに提供されます。CCMDB ディスカバリーの導入により、これまでも拡張されてきたサポート対象のリソースや管理システム以上に、ディスカバリーの範囲と奥行きを拡大する要求が生まれています。実際の実装環境から示された追加要件として、発見の範囲を制御可能にすること、およびディスカバリーの一部として収集された情報量を絞り込むために、発見されたデータをフィルター操作可能にすることがあります。これは、主にスケーラビリティーと多くのリソースを発見するのにかかる時間がその誘因となっています。その他の要件には、データ・モデルを拡張できること、既存のリソース・モデルに属性を追加できること、新しいタイプのリソースを追加できることなどがあります。また、CCMDB のフェデレーションと構成管理機能に対してもかなりの関心が寄せられています。データ・ソースのフェデレートは、お客様のデータベースとサード・パーティーのデータベースを CCMDB に取り込む上で重要です。これらの導入により、ますます高度で自動化されたリコンシリエーション・テクノロジーの必要性が強く求められています。

プロセス管理の観点からは、多くのお客様が自社の慣例や方針とより密接に整合させるようにプロセスのタスクを構成できる柔軟性を求めています。これによって、可視化のためにプロセスを構成し、CCMDB および UI のデータ・モデル拡張とプロセスを統合する高度なツールが必要になります。組織全体にわたって既存のプロセスと対話を理解するのは、プロセス管理の導入を成功させる上で重要な側面です。ベスト・プラクティスに向けた変革は、一般的には既存プロセスの変更を実装して、段階的に変更していくところから始まります。プロセス導入には、既存のプロセス、ツールおよびその制約を調整するだけでなく、多くの場合には組織の変革が含まれるので、通常かなりの時間と努力が必要になります。

我々の実装と導入の経験は、ISM アーキテクチャーの重要な設計の決定事項を裏づけるものでした。特に、SOA を使用して IBM の幅広い OMP の集合をフェデレーション・ベースの CMDB とプロセス管理テクノロジーに統合する方法の有効性が検証されました。我々が直面したそれぞれの導入要件については、アーキテクチャーと整合性の取れる方法で取り組みが行われています。

我々は、運用チームが業界のベスト・プラクティスとの整合性を取るためのプラットフォームを提供し、プロセスを情報管理/運用管理テクノロジーと統合する SOA ベースのアーキテクチャーを提供しました。ビジネス・プロセスの変革ツール、情報管理テクノロジー、および運用管理テクノロジーの上に構築された IBM サービス・マネジメント アーキテクチャーは、より高度なレベルのオートノミック・コンピューティングをサポートする基盤を確立します。CMDB に含まれる知識は、システムのオートノミック管理にとって重要なコンポーネントです。CMDB がサポートするサービス・トポロジー情報によってビジネス・コンテキストが提供され、オートノミック動作を管理するポリシーが確立されます。これらのポリシーには、パフォーマンスおよび可用性のサービス品質目標からセキュリティーおよび準拠の要件まで、さまざまなドメインを反映させることができます。IT プロセスの自動化を導くポリシーでさえ確立できます。これらのポリシーによって、オートノミック・コンピューティングの拡張機能を CMDB、PM、および運用管理ツールに追加できます。

その後でこれらのポリシーを閉ループ処理によってサポートできます。設計のポイントは、OMP を使用して、CMDB で定義されているとおりにビジネス・アプリケーションのコンテキストに基づいてポリシーを実施することです。この作業の重要な側面は、PM とのオートノミック機能の統合です。理想としては、アクティビティーおよびタスクのオートノミック実装により、手動タスクと整合した方法でガバナンスと KPI が提供されます。このアプローチにより、運用チームはより簡単にアクションとオートノミック・テクノロジーの結果をモニターできるようになります。このため、労働集約型のモデルからより自動化されたモデルへの移行が簡単になり、IT はビジネス・サービスのニーズと優先事項に対応できるようになります。

この作業のもう 1 つの重要な側面は、同じタスクの異なるレベルの実装 (手動、半自動化、自動化) を切り替える条件付き分岐を備える PM の設計です。これにより、お客様は組織の成熟度に合わせて、手動プロセスからより自動化が進んだプロセス、さらには完全に閉ループでコントロールされるプロセスにまで徐々に変更していくことも可能になります。

つまり、IBM サービス・マネジメントは業界の転換を主導し、管理システムの分野をテクノロジー中心のアプローチから、人、プロセス、情報、およびテクノロジーを包括するサービス重視のアプローチへと転換させる要因となっています。IBM サービス・マネジメント・アーキテクチャーは、サービスの開発、展開、管理を簡易化し、運用コストを削減し、サービス・レベルを上げることに重点を置いています。オートノミック・コンピューティングの技術的進歩は、サービス・マネジメントに不可欠な要素です。今後もアーキテクチャーと実装により、プロセス、ツール、統合を進展させ続け、自己管理が可能な目的指向のシステムを実現していきます。

*

*IBM Corporation の米国およびその他の国における商標または登録商標です。
**United Kingdom Office of Government Commerce、System Audit and Control Association、Telemanagement Forum Corporation、または Sun Microsystems, Inc. の米国およびその他の国における商標または登録商標です。

引用文献

1. 「Foundations of IT Service Management Based on ITIL」、ITSM Library、J. Van Bon、M. Pieper、および A. van der Verrn、編集者、Van Haren Publishing B.V.ｍ, Zaltbommel, The Netherlands、 2006 年 11 月
2. 「Introduction to ITIL」、The Stationery Office, Office of Government Commerce, United Kingdom (2005 年)
3. 「COBIT」、Information Systems Audit and Control Association (ISACA)
4. 「Recommendation M.3050: Enhanced Telecommunications Operations Map (eTOM)—Introduction」、国際電気通信連合
5. 「Service-Oriented Architecture」、IBM Systems Journal 44, No. 4 (2005 年)
6. 「IBM Tivoli Provisioning Manager: Product Overview」、IBM Corporation
7. 「IBM Tivoli Unified Process」、IBM Corporation
8. H. Madduri、S. S. B. Shi、R. Baker、N. Ayachitula、L. Shwartz、M. Surendra、C. Corley、M. Benantar、S. Patel 共著、「IBM サービス・マネジメントを支える構成管理データベース・アーキテクチャー」、IBM Systems Journal 46, No. 3, 441–457 (本号、2007 年)
9. 「JSRs: Java Specification Requests—JSR# 168」、The Java Community Process
10. 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
11. A. Betawadkar-Norwood、E. Lin、I. Ursu 共著、「Using Data Federation Technology in IBM WebSphere Information Integrator: Data Federation Design and Configuration」、developerWorks, IBM Corporation
12. L. Haas、E. Lin 共著、「IBM Federated Database Technology」、developerWorks, IBM Corporation
13. L. M. Haas、E. T. Lin、M. A. Roth 共著、「Data Integration through Database Federation」、IBM Systems Journal 41, No. 4, 578–596、2002 年
14. 「Data Federation with IBM DB2 Information Integrator」、IBM Redbook SG24-7052, IBM Corporation

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

David Lindquist
IBM Software Group, Tivoli, 3901 S Miami Blvd, Durham NC
27703-9135 IBM Fellow である Lindquist 氏は、IT 管理およびサービス・マネジメントのソリューションおよびテクノロジーのアーキテクチャーを担当する IBM Tivoli のチーフ・アーキテクトです。2002 年に IBM Tivoli に参加する以前は、Application and Integration Middleware 部門でネットワーク戦略とアーキテクチャーの WebSphere Edge を指揮していました。Dave は、大規模システムのアーキテクチャー、パフォーマンス、およびデータベース・システムを専門とする Server Group で、IBM でのキャリアのスタートを切りました。1990 年に IBM Software Group に入社し、そこでは Web インフラストラクチャー、コンテンツ配信ネットワーク、モバイルおよびワイヤレス・テクノロジー、インターネット製品を対象にしていました。Dave の研究は 48 件の特許に結びつき、IBM Master Inventor を受賞し、BM Academy of Technology に選出されています。

Hari Madduri
IBM Software Group, Tivoli, 11501 Burnet Rd, Austin TX 78758-3400。Madduri 博士は、S/370e アセンブラーのプログラマー/アナリストとしてそのキャリアのスタートを切り、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 件の 米国特許の発明者です。

Chakalamattam Jos (C. J.) Paul
IBM Software Group, Tivoli, 11501 Burnet Road, Austin TX 78758-3400。Paul 博士は、IBM Tivoli の Process Managers のリード・アーキテクトであり、IBM サービス・マネジメント ポートフォリオの一部である Process Managers のファミリーのアーキテクチャーと設計を指揮しています。重点分野には、プロセス自動化、システム管理、サービス・マネジメント、コンプライアンス、およびガバナンスなどがあります。現職の前は、IBM のオンデマンド自動化戦略とアーキテクチャー、オートノミック・コンピューティング・イニシアチブ、Tivoli のコア・テクノロジー、および WorkSpace on Demand 製品ラインを手がけていました。IBM Autonomic and Tivoli Architecture Board、IEEE、および ACM のメンバーであり、十数件を超える特許を取得しています。Paul 博士は 1993 年に IBM に入社し、当初はマイクロカーネル・オペレーティング・システムに取り組みました。ペンシルベニア州ピッツバーグのカーネギーメロン大学でコンピューター工学の博士号を取得し、チェンナイの Indian Institute of Technology でテクノロジー学士の学位を取得しています。

Bala Rajaraman
IBM Software Group, Tivoli, 3901 S Miami Blvd, Durham NC
27703-9135。Rajaraman 博士は 1992 年に IBM に入社し、現在、エンタープライズ・システム管理ソリューションのアーキテクチャーと設計を担当する Distinguished Engineer です。対象分野には、IT サービス・マネジメント、プロビジョニング、自動化のソリューションなどがあります。以前は、System zTM と WebSphere のパフォーマンスの側面に取り組んでいました。関心のある分野は、通信テクノロジー、システム・パフォーマンス、オートノミック・コンピューティング、システム管理、およびオンデマンド・コンピューティングです。Clemson University のコンピューター工学の博士号を取得しています。

目次へ戻る