モデル駆動型トランスフォーメーション・アプローチとサービス指向アーキテクチャーを利用したサービス・デリバリー管理

標準のツール・セットに移行すれば、効率的で効果的なサービス・デリバリーが可能になると思い込んでいる IT (情報技術) サービス・プロバイダーが数多くいます。この思い込みは、サービス・プロバイダーが顧客環境のスコープとアーキテクチャーを完全に制御できている場合にのみ当てはまります。しかし、トレンドは、選択的アウトソーシング、IT ソリューションのアーキテクチャー上での顧客制御、およびレガシー・ツールの保存の方向に向かっています。ターゲット環境の異機種化が進んだことで、それらを制御するサービス・プロバイダーの能力が低下しています。その結果、IT サービス・ワークフローの自動化に対する新しいアプローチと、異機種性およびコラボレーションをサポートする新世代のサービス・デリバリー管理システムが求められています。本稿では、複雑で多様なワークフローを自動化するための新しいアプローチを紹介して、このアプローチを IT サービス・デリバリー管理 (SDM) に適用し、このアプローチに基づく SDM アーキテクチャーを提示して、このアーキテクチャーによって促進される SDM 実装について説明します。我々の実装アーキテクチャーは、サービス指向アーキテクチャー (SOA) の原則を利用して、疎結合されたサービス・コンポーネントとそれらを動的に統合するサービス遂行パターンを定義します。ここでは、サービス・デリバリーのパフォーマンス・メトリックのモデリングを取り上げ、主要業績評価指標 (KPI) のモニターと管理が我々の SDM プラットフォームの不可欠な部分としてどのようにサポートされるかについて説明します。

企業をアウトソース・サービスに向かわせる主な要因は、中核となる能力に集中したいという思惑です。サービス・プロバイダーの課題は、企業が同じサービスを品質を落とさずに安いコストで利用することを期待するということです。サービス・プロバイダーが顧客からビジネスと IT プロセスを継承している場合が多いという事実によって問題が複雑になっています。準拠や規制に関する多くの手順をプロセス内に含める必要があります。サービス・プロバイダー側の過失や怠慢による違反が、企業のイメージや財務状況に深刻な影響を及ぼす場合があります。そのため、サービス・プロバイダーが、サービス・デリバリーのプロセスをモニターおよび管理するためのツールやテクノロジーを所有することが重要になります。

サービス・デリバリー管理 (SDM) における基本的な課題は、機能的専門知識のカテゴリーに基づいて編成および最適化されるサービス・プロバイダーの特性に起因します。プロセス、メトリック、実行、およびビジネス・ケースは、これらのカテゴリーと一致する傾向があります。また、最適化では、機能的専門知識に基づいてコンピテンシー・センター (COC) が設立され、スキルと財務状況が最も有望な場所に設置されます。これらの機能と場所をカバーするソリューションとサービスの構築は、ますます複雑化しています。プロバイダーにとっての経営課題は、このカテゴリー (「縦割り」として知られる) 間の複雑さを管理し、採算がとれるサービス・オファリングを提供することです。

本稿で提案するソリューション・アプローチは、IBM Research で開発されたモデル駆動型ビジネス・トランスフォーメーション (MDBT) と呼ばれるビジネスからテクノロジーまでのフル・ライフ・サイクル方式をベースにしています。MDBT は、ビジネスの変革方法と、ワークフロー・ツールおよび人的アクティビティーを統制することによってビジネス戦略を実現可能にする一連の革新的テクノロジーを兼ね備えています¹。

MDBT の心臓部は、ビジネス・ドメインと IT ドメインにわたる多層モデリング・フレームワークです。このフレームワークは、ビジネス戦略、ビジネス・オペレーション、ソリューション構成、および IT 実装の 4 つの層で構成されます。層ごとに、異なる抽象化レベルが設定され、明確に定義された機能が実行され、対象者が区別されます。戦略層では、ビジネス・システムの目標と目的が定義されます。オペレーション層では、ビジネス・システムで目標を達成するために実施されるオペレーションが記述されます。構成層では、ビジネス・オペレーションの実行に必要な計算要素の抽象化が行われます。実装層では、特定の IT プラットフォームへの計算要素の実装方法が指定されます。本稿では、このフレームワークがどのように SDM (サービス・デリバリー管理) の課題の効果的な解決を支援するかについて説明します。

以降のセクションでは、MDBT アプローチと基礎となるフレームワークについて説明します。また、SDM を定義し、サービス・デリバリー・オペレーションをサポートする SDM プラットフォームを提案します。さらに、MDBT アプローチによって SDM プラットフォームがどのように実現されるかについて解説し、SDM プラットフォームを実際のサービス・デリバリーに採用した経験を紹介します。最後に、この領域に関する研究と本稿で紹介した革新技術の分析について説明します。

モデル駆動型ビジネス・トランスフォーメーション

MDBT は、ビジネス・コンポーネントの構造と動作を明示的に定義するために正式なモデルを使用し、そのパフォーマンスをモニター、分析、および改善するためにこれらのモデルを採用し、その IT システムの構築でそれらのモデルを利用します。本稿の説明に登場するビジネス・コンポーネントは、IT アウトソーシング・サービスをクライアントに提供するアウトソーシング組織 (以下アウトソーサー) を意味します。アウトソーサーが、さらに、作業の一部を専門のサービス・プロバイダー組織に外注する場合があります。

MDBT アプローチのトランスフォーメーション・プロセスは、ビジネス・コンポーネントの戦略的な目標と目的の設定で始まります。そして、これらの目標をサポートする一連のイニシアチブにつながります。これらのイニシアチブが、戦略的目標を達成できるように組織のビジネス・オペレーションの定義、分析、最適化、および実施を決定します。この手順の出力は、事業主が戦略的目標の達成過程をモニターできるようにする「バランス・スコアカード」の定義です。サービス・デリバリー・ドメインでは、この手順の出力がアウトソーサーのバランス・スコアカードです。

ビジネス・オペレーションと使用可能な KPI (主要業績評価指標) の正式な定義がトランスフォーメーション・プロセスの次の手順です。これをビジネス・オペレーション・モデルと呼びます。サービス・デリバリー・ドメインでは、このモデルによって、サービスの定義および管理方法、サービスの作成およびプロビジョニング方法、変更管理、リリース管理、および構成管理とサービス・プロビジョニングの相互作用方法が形式的に記述されます。

ビジネス・オペレーション・モデルは、よく知られているワークフロー・モデルとは異なります。根本的な違いは、ワークフロー・モデルでは、ビジネス・プロセス内のアクティビティーの順序付けとこれらのアクティビティーを通したデータ・フローが定義されます。したがって、ワークフロー・モデルは、制御フロー・グラフとデータ・フロー・グラフで構成されます。一方、ビジネス・オペレーション・モデルでは、主要なビジネス成果物とこれらの成果物に対して実施されるオペレーションが定義されます²。サービス・デリバリー・ドメインにおけるビジネス成果物の例はサービス注文書です。コンピューター・プログラミングのオブジェクト指向パラダイムと手続き的パラダイムが異なるのと同様に、ビジネス・プロセスの点で、オペレーション・モデリングとワークフロー・モデリングは異なります。

ビジネス成果物に対するオペレーションのモデリングに加えて、ビジネス・オペレーション・モデルにはビジネス・パフォーマンスを管理するための要素も含まれます。これは、成果物に関連した KPI を指定することによって実現されます。KPI は、事前に合意された定量化可能な尺度で、ビジネスの成功に不可欠な要素が反映されています。一般的に、組織は、KPI を使用してビジネス目標までの過程を評価することによってビジネス・パフォーマンスを管理します。KPI の定義に加えて、ビジネス・パフォーマンス・モデルには、KPI 間の関係、KPI を計算するためのアルゴリズムとデータ、KPI によってトリガーされるビジネス状況、および必要な場合の是正措置が含まれます。

KPI は、それに関連したビジネス成果物に基づいて編成されます。各 KPI は、1 つ以上のディメンションによって修飾されます。ディメンションは、KPI を表示するために使用されるグループ化基準です。たとえば、サービス注文量 KPI は、時間間隔、サービス・デリバリー組織、アカウント、クライアントなどに基づいて表示することができます。

サービス・デリバリー用の形式的なオペレーション・モデルを作成する理由がいくつかあります。ワークフロー・モデルは、プロセス内の手順を改善することによってローカルな最適化をもたらしますが、オペレーション・モデルは、ビジネスの運営方法を根本的に変更することによってグローバルな最適化をもたらします。よく知られている例として、サプライ・チェーン管理への革新技術の導入によって可能になるビジネス・モデルを使用してパーソナル・コンピューター・ビジネスで有名企業に成長した Dell, Inc. が挙げられます³。

ビジネス・オペレーション・モデルは、明示的なモデリングや開発を行わなくても、実行時にオンデマンドでワークフローを作成するために使用することができるため、戦略的アウトソーシング (SO) ビジネスに不可欠な柔軟性が提供されます。たとえば、サービス要求のプロビジョニングに必要なワークフローは、サービスを要求した顧客、要求されたサービスの種類、そのサービス要求のインスタンスに含まれる情報、サービス・プロバイダーの現状、サービス・プロビジョニング環境などのさまざまな要素に依存します。このようなワークフローのすべてのインスタンスを定義することは現実的ではありません。むしろ、明確に定義されたビジネス・オペレーション・モデルは、このようなワークフローをオンデマンドで動的に作成するために使用することができます¹。

作業項目の流れに重点が置かれていた従来のワークフローと違って、ビジネス・オペレーション・モデルでは、ビジネス・プロセス内の情報の流れに重点が置かれるため、ビジネスを通して情報がどのように定義、作成、使用、および操作されるかが明確に定義されます。情報に重点を置くことによって、アプリケーションとツールのより良い統合がもたらされ、ビジネス・インテリジェンスの活用機会が提供されます。これは、参考文献 4 で説明されている研究などのビジネス・インテリジェンスへのアクティビティー・ベースのアプローチとは異なります。アクティビティーとは対照的に成果物に重点を置くメリットについては、参考文献 5 で詳しく解説されています。

MDBT の次の手順は、ビジネス・オペレーションの実行をサポートするテクノロジーの適切な使用です。これには、プラットフォームに依存しないソリューション構成モデルの生成と、特定のソフトウェア・プラットフォーム上でのこのモデルの実現が含まれます。ソフトウェア・プラットフォームは、一連のミドルウェア製品またはアプリケーションを意味します。WebSphere* Process Server⁶ は、サービス・デリバリー用のソフトウェア・プラットフォームの例です。

プラットフォームに依存しないソリューション構成モデルの採用にはいくつかのメリットがあります。特定のソフトウェア・プラットフォーム上でこのソリューションを実現するために、モデル駆動型コード生成を利用することができるため、多くの貴重な時間が節約されます。複数のコード生成プラグインを使用すれば、複数のプラットフォーム上で同じモデルを使用して IT ソリューションを実現することができます。この機能によって、ソフトウェア・プラットフォーム内の変更のサポートが非常に容易になります。ビジネスに不可欠な IT ソリューションの要素がビジネス・オペレーション・モデルから自動的に生成されるため、ビジネスと IT 間のギャップが効率的に埋められます。こうして生成されたモデルは、成熟したソリューションの構築にとって重要な IT レベルの詳細を使用して充実させることができます。

プラットフォームに依存しないソリューション構成モデルは、ビジネス・オペレーション・モデルに必要な機能を実装するコンピューター・プログラムの形式的記述です。つまり、ソリューション構成モデルがソリューション設計を形式化するのに対して、ビジネス・オペレーション・モデルはビジネス要件を形式化します。このモデルの主要素は、適応型ビジネス・オブジェクト⁷ (ABO) と呼ばれるサービス・コレオグラフィー・コンポーネントです。ABO の計算モデルは、作成からアーカイブまでのビジネス成果物のライフ・サイクルを処理する通信有限状態マシン (FSM) です。オペレーション層から実装層への変換の結果、FSM が自動生成されます。FSM に加えて、ABO モデルには、クライアント・インターフェースと、ビジネス成果物のデータ・モデル全体が含まれます。

FSM が生成されたら、ソリューション構成モデルで FSM 内の状態遷移に関連するアクションを指定することができます。アクションは、コマンド・デザイン・パターン⁸を実装し、サービス指向アーキテクチャー (SOA) に基づいて 1 つ以上のサービスの実行に結び付けることができます。FSM と状態遷移に関連付けられたアクションを使用することによって、ソリューション構成モデルで 1 つ以上の SOA ベースのサービスのオーケストレーションを定義することができます。このように、ソリューション構成モデルは、サービス指向アーキテクチャー (SOA) の原則を利用して、ビジネス・オペレーション・モデルに必要な新しい機能を実現する複合アプリケーションを作成するための再利用可能なステートレス・サービスを構成します。これによって、モジュール式の、コンポーネント・ベースで、分散型の、スケーラブルなソリューション・アーキテクチャーがもたらされます。

ABO に加えて、ソリューション構成モデルには、ビジネス・パフォーマンス管理 (BPM) の要素も含まれています。BPM には、実行時のビジネス・プロセスのパフォーマンスをモニターするためのモニタリング・モデル、「ダッシュボード」表示 (多画面表示など) を可能にする可視性モデル、および結果の詳細分析機能が含まれています。これらのモデルは、ビジネス・オペレーション・レベルで KPI モデルから手動で作成されます。

次の手順は、特定の IT プラットフォーム上での IT ソリューションの実装です。現時点で、プラットフォームに依存しないソリューション構成モデルから、IBM WebSphere プラットフォームと DB2* データベース用のコードが生成されています。ソリューションがデプロイされれば、事業主は、KPI を使用してビジネス・パフォーマンスをモニターおよび分析し、そのパフォーマンス分析に基づいて、ビジネス・レベルと IT レベルの両方で、モデルを継続的に改良することができます。BPM ダッシュボードは、KPI をモニターおよび分析し、利害関係者にリアルタイムのアラートを通知するために使用されます。BPM ダッシュボードでは、オンライン分析処理 (OLAP) コンポーネントを利用して IT ソリューション成果物からリアルタイム・データが抽出されます。これによって、従業員は、情報に基づいて決定を下したり、ビジネス・チャンスや脅威に迅速かつ積極的に対応することができます。

図 1 に、懸案事項の分類、モデルの層間の接続、および BPM コンポーネントを使用して実現される閉ループ・アーキテクチャーを含む MDBT フレームワークを示します。たとえば、ビジネス・オペレーション層は、事業主によるビジネスの理解に関連付けられます。この層では、上位層で定義されたビジネス・サービスと戦略的 KPI をサポートするためのビジネス・オペレーション・モデルと監視モデルが定義されます。この層における BPM コンポーネントの期待は、ビジネス上のコミットメントが満たされるかどうかを判断することです。この判断は、組織のビジネス状況への対応に基づいて下されます。この層で蓄積された情報は、ビジネス・オペレーションを最適化するために使用することができます。
MDBT アプローチの使用によって実現される SDM プラットフォームの詳細を説明する前に、以降のセクションでは、IT サービス・デリバリー管理を定義し、サービス・デリバリー・プロセスの管理での SDM プラットフォームの利用を提案します。

サービス・デリバリー管理

IT サービス・デリバリー管理では、サービスが社内の IT チームによって提供されるか、アウトソーシングされるかに関係なく、主に、IT サービス・デリバリー・ビジネスの実行に重点が置かれます。IT サービス・デリバリーには、インシデント管理、問題管理、変更管理、構成管理、可用性、サービス要求管理、サービス・サポートなどの多くの運用プロセスが含まれます。すべてのビジネスと同様に、サービス・デリバリー組織は、だれが顧客であるか、顧客に必要なサービス、およびサービスの提供に必要なデリバリー機能に重点を置く必要があります。したがって、サービス・カタログの作成だけでなく、これらのサービスとデリバリー機能の関連付けが重要です。これによって、サービス・デリバリー組織は、サービスの粒度を高め、既存のデリバリー機能からより付加価値の高いサービスを開発することができます。

拡大図

IT デリバリー・ビジネスは、地域、コンピテンシー、または両者の組み合わせで編成することができます。デリバリー・チームは、ローカル (地元の顧客へのサービス提供) または グローバル (任意の顧客へのサービス提供) にすることができます。また、チームは、ジェネラリスト (サービスを遂行するためのエンドツーエンド・タスクを実行する 1 人の人物を含む) またはスペシャリスト (明確に定義されたタスクを実行する高度に専門的なチーム・メンバーを含む) で構成することができます。サービス・デリバリー組織には、組織のさまざまな部署のデリバリー・チームが使用するツールやテクノロジーに関係なく、このような組織モデルのすべてをサポートしてサービスの遂行を調整および管理できるサービス・デリバリー・プラットフォームが必要です。以降のセクションでは、MDBT アプローチを使用して設計および実装される SDM プラットフォームの詳細について説明します。

サービス・デリバリー・ビジネスと経営目標

企業は、KPI を使用して、事前に定義された組織目標までの過程を評価することができます。サービス・プロバイダーは、KPI を使用して、競合他社と差別化するためのサービス・デリバリー目標に重点を置くこともできます。

サービス・デリバリーのプロフィット・センターとコスト・センターの両方のビジネス・モデルに適用される汎用的なビジネス目標には、顧客が価値があると評価するサービスの提供、交渉価格での必要な価値の提供に対する低コストの実現、価値レベルに応じた最高品質の実現、および高いお客様満足度の実現が含まれます。

すべてのサービス・デリバリー・ビジネスの本質は、契約交渉段階で合意された最低価格と価値レベルでの契約サービスの提供と、不要なコスト増につながる交渉外の価値の回避との微妙なバランスを取るための葛藤です。そのため、SDM システムは、継続的に、さまざまな価値レベルで提供されるサービスの真のコストを把握して、マーケティング担当者や営業担当者がサービス契約の交渉の場でこのコストが使用できるようにする必要があります。また、SDM システムは、デリバリーまでの期間、サービスの品質、新しい要求を満たす柔軟性などのお客様の体験に影響を与える非コスト・データを把握する必要があります。

ライフ・サイクルのフェーズごとにビジネス目標を設定したサービス・デリバリー組織は、各フェーズの日常業務に SDM プラクティスを適用する必要があります。これによって、経営目標の定式化が実現し、ビジネス・オペレーション全体を設計するためのガイダンスが提供されます。後述するように、このオペレーションは、特定のビジネス成果物、具体的には、サービス要求、サービス注文、およびサービス・タスクの処理で構成されます。

拡大図

図 3. 成果物インスタンスの例

拡大図

上に戻る

MDBT の基本的な抽象化は、ビジネス・タスクによって処理され、リポジトリーに保存されるビジネス成果物です。SDM には、以下のような 5 種類のビジネス成果物があります。図 2 に、成果物の種類とそれらの関係を示します。図 3 に、成果物インスタンスの例を示します。

1. アトミック・サービス - 特定の機能を反映した再利用可能なサービス要素です。これは、境界が明確に定義され、サービス・プロバイダーが実行可能な作業単位を表します。サービス・デリバリー・ビジネスでは、このサービス要素をさらに分解してもあまり意味がありません。アトミック・サービスの例として、ソフトウェア・パッチの作成、オペレーティング・システムのインストール、アプリケーションの構成などが挙げられます。アトミック・サービス成果物には、サービスの定義が含まれます。この定義には、サービスの実行に必要な入力データとサービスの実行後に生成される出力データの仕様が含まれます。アトミック・サービス成果物の属性やタスク構造などの詳細については、参考文献 9 を参照してください。
   
   
2. 提供サービス - 一連のアトミック・サービスを 1 つの提供 (または複合) サービスにまとめることができます。提供サービスの例として、「サーバー・ビルド」(サーバーの構成やプロビジョニングなど)、パッチ管理、アプリケーション・プロビジョニングなどが挙げられます。提供サービス成果物には、提供サービスの定義が含まれます。この定義には、サービスの実行に必要な入力データ、サービスの実行後に生成される出力データ、提供サービスの実行に必要なアトミック・サービス、およびアトミック・サービスに関する順序付けの制約の仕様が含まれます。提供サービス成果物の属性やタスク構造などの詳細については、参考文献 9 を参照してください。
   
   
3. サービス注文 - アトミック・サービスと提供サービスの成果物は SDM システムの構成に使用されますが、サービス注文、サービス計画、およびサービス・タスクはサービスの遂行に使用されます。サービス注文とは、クライアントからのサービスに対する要求を意味します。クライアントが、サービス・カタログを使用してサービス注文書を作成します。サービス・カタログは、クライアント・ドメイン向けの提供サービスのサブセットの見積もりです。たとえば、クライアントがサービス・ビルドを要求した場合は、サービスの注文が生じます。サービス注文では、サービス要求の一般的な属性と提供サービス固有の属性の両方が取得されます。一般的な属性には、注文 ID、説明、優先順位、予定時刻、予定と実際の開始時刻と終了時刻、ステータス、およびサービスレベル・アグリーメント (SLA) が含まれます。サービス固有の属性は、標準として発行および承認された正規のデータ要素スキーマに従います。サービス注文のタスク構造は、アカウントまたはサービス・タイプの特定のニーズを満たす柔軟性を維持しながら、アカウントとサービス・タイプ全体の標準化を可能にする細分度でモデル化されます
   
   図 4. サービス注文ビジネス成果物のライフ・サイクル
   
   
   

   拡大図

   図 4 に、サービス注文成果物のライフ・サイクルを示します。成果物に対して実施される必須のビジネス・タスクを以下に示します。

   1. サービス注文の作成 - このタスクは、SDM のユーザー・インターフェースを通して手動で実行することも、プログラムでサービス注文成果物のサービス要求ゲートウェイに要求を送信することによって実行することもできます。
      
      
   2. サービス注文の承認 - アカウント・マネージャーが、サービス要求に対する資格チェックを実施してからその要求を承認します。
      
      
   3. サービス注文の計画 - このタスクでは、サービス注文の実行に必要な計画が策定されます。
      
      
   4. 変更の管理 - サービス注文に対する変更承認が必要な場合に、変更要求が作成されます。このタスクは、変更承認が得られた段階で完了します。
      
      
   5. サービス注文の実行 - このタスクの始まりは、サービス注文の実行に必要な作業が開始されたときで、終わりは、この作業が完了したときです。
4. サービス計画 - サービス注文に対応するサービス構成の提供サービス定義を使用してサービス計画成果物が作成されます。提供サービス定義におけるアトミック・サービスの構成は抽象的な計画と見なすことができるのに対して、サービス計画はこの抽象的な計画から生成されますが、サービス注文の特定のインスタンス用にカスタマイズされた具体的な計画です。たとえば、特定のサービス注文を遂行するためにサービス計画が作成される場合があります。サービス計画では、実行時に、提供サービスに関連付けられたさまざまな計画をオーバーライドすることができるため、一般的な一連の提供サービス定義が大幅に削減されます。図 5 に、サービス計画成果物のライフ・サイクルを示します。サービス計画成果物に対して実施されるビジネス・タスクを以下に示します。
   1. サービス計画の作成 - 計画サービスが、対応する提供サービスに関連付けられたサービス計画テンプレートに基づいてこのタスクを実行します。計画サービスは、抽象的な計画に対するコンテキスト・ベースのオーバーライドを実施するためのルールとポリシーを適用します。その後で、自動プロバイダー割り当てを実施するためにプロバイダー割り当てポリシー (コスト、時間、デフォルトのプロバイダー・リンケージ、およびワークロード管理の重み付けされた機能) を適用します。
      
      
   2. サービス計画の変更 - このタスクは、計画の実行中の予期せぬイベントに対応するために必要に応じて実行されます。
      
      
   3. サービス・プロバイダーの割り当て - 計画サービスによるデフォルトの割り当ては、後から手動で変更することができます。
      
      
   4. サービス計画の承認 - すべての利害関係者が計画を承認してから計画を実行に移す必要があります。
      
      
   5. 計画実行の開始 - このタスクは、計画に含まれるアトミック・サービスの実行を開始します。
      
      
   6. 計画実行の管理 - このタスクは、アトミック・サービスが完了するたびにトリガーされます。必要に応じて、計画状況が更新され、次のアトミック・サービス・セットの実行がトリガーされます。
   
   
   図 5. サービス計画ビジネス成果物のライフ・サイクル
   
   
   

   拡大図

5. サービス・タスク - サービス計画に基づいて 1 つ以上のサービス・タスク成果物が作成されます。このようなサービス・タスク成果物のそれぞれが、アトミック・サービス定義 (ASD) に対応します。サービス・タスク成果物には、対応するアトミック・サービスの実行に必要なインスタンス・データが含まれています。サービス・タスクは、ASD 内にカプセル化された作業を実施するためにサービス・プロバイダーに送信されます。たとえば、特定のサービス計画に含まれるサービス注文を遂行する一環としてオペレーティング・システムをインストールするためのサービス・タスクが作成される場合があります。図 6 に、サービス・タスク成果物のライフ・サイクルを示します。

次に、SDM のビジネス・パフォーマンス・モデルについて説明します。表 1 と表 2 に、サービス注文とサービス・タスクの成果物に関する KPI と関連するディメンションを示します。「状態」という概念を使用して管理ポリシーが定義されます。状態は、1 つ以上の KPI に状態ルールを適用することによって検出されます。管理ポリシーでは、状態が起きた場合に実施するアクションを定義します。たとえば、管理ポリシーで、サービス注文の経過時間は、SLA レベルまたは個別のサービス注文レベルで定義された特定のしきい値を超えてはならないと指定することができます。この場合は、状態名を「経過時間がしきい値を超えた場合」に、KPI をサービス注文経過時間に、評価頻度を継続的に指定することによって、ポリシーが定義されます。状態ルールは「経過時間が予定時間の 90% を超えてもサービス注文が完了しなかった場合に状態をトリガーする」となり、アクションは利害関係者への状態の通知になります。

拡大図

ビジネス成果物は、ビジネス・オペレーション・スペースを、柔軟で疎結合されたソリューション構成に適した直交するサブスペースに論理的に分割します。各サブスペースには、成果物のタスク構造が含まれています¹⁰。タスク構造は、各成果物に対して実施されるオペレーション、各オペレーションを実施するビジネス・ロール、各成果物で使用されるリポジトリー、およびそれらの依存関係を表します。SDM のオペレーション・モデルは、これらのタスク構造を合体したものです。成果物間の相互作用によって、サブスペースの境界が定義されます。相互作用は、一連の設計ルールとして取り込まれます¹⁰。その後で、相互作用を制御する設計ルールに従っていれば、サブスペースに対して独立処理およびツール革新を適用することができます。

プラットフォームに依存しないソリューション構成モデル

ソリューション構成モデルの中核要素は、ビジネス・オペレーション・モデルからプログラムによって生成されます。その後で、手動でモデルを拡張することができます。ソリューション構成モデルの中核要素は、IT レベルでのビジネス成果物を表す ABO、ABO のクライアント側の表示方法を記述した情報表示モデル、ユーザーが ABO に対するオペレーションを呼び出してどのようにビジネス・タスクを実行するかを記述したユース・ケース実現モデル、レガシー・サービスがビジネス・タスクの実行の一部として ABO によってどのように消費されるかを記述したサービス統合モデル、および BPM モデルです。これらの要素の詳細について、以降のサブセクションで説明します。ビジネス・オペレーション・モデルをソリューション構成モデルに変換するためのアルゴリズムの詳細については、参考文献 11 を参照してください。

ABO
ソリューション構成モデルには、ビジネス・オペレーション・モデル内の 5 つのビジネス成果物 (アトミック・サービス、提供サービス、サービス計画、サービス注文、およびサービス・タスク) に対応する 5 つの ABO があります。ABO モデルには、ABO のデータ構造と他の ABO やビジネス・オブジェクトとの関連を記述した構造特性、クライアントが ABO と通信するためのインターフェース (イベントを非同期に ABO に渡すために使用可能なコール・トリガーを含む) を記述したオペレーション、およびライフ・サイクル・モデルが含まれます。ライフ・サイクル・モデルには、基礎となるビジネス成果物のライフ・サイクル・ステージに対応した ABO の状態、ABO の状態変化を判断する状態イベント、ライフ・サイクル内のある状態から別の状態への移行動作を表す遷移、および遷移の一部として呼び出されるアクションが含まれます。これらのアクションには、ABO データを操作するデータ・アクション、レガシー・サービスの呼び出し、および他の ABO に対するイベントの発行が含まれます。

ABO モデルは、ビジネス・オペレーション・モデルのトランスフォーメーションを通して自動的に作成されます。図 7 に、サービス注文 ABO の表示の一部を示します。

情報表示モデル
リスト・ビューと状態ビューが情報表示モデルの中核要素です。これらの要素によって、ABO からクライアントに提示される情報へのアクセス制約が定義されます。これらのビューは、ロールと成果物タイプの有効な組み合わせごとに定義されます。リスト・ビューに関しては、次の 3 つの制約があります。検索制約によって、特定のビジネス・ロールを担っているユーザーが検索可能な成果物に関するビジネス・コンテキストが定義されます。状態制約によって、特定のビジネス・ロールを担っているユーザーが表示可能な成果物に関する状態が定義されます。要約データ制約によって、特定のビジネス・ロールを担っているユーザーが成果物の要約を表示可能な一連の属性が定義されます。

リスト・ビューは、成果物インスタンスのリストとそれらに関する要約データを作成するために使用されます。ユーザーは、このリストから、ビジネス・タスクを実行する成果物インスタンスを選択することができます。こうして、ユーザーにタスクの実行を可能にする成果物表示が作成されます。

状態ビューは、成果物表示をモデル化するために使用されます。状態ビューに関しては、次の 2 つの制約があります。実行制約によって、特定の状態にある成果物タイプに対して特定のロールを担っているユーザーが実行可能なオペレーションが指定されます。書き込み制約によって、特定の状態にある成果物タイプに関して書き込み可能な成果物データ・モデルのサブセットが指定されます。

ビジネス・オペレーション・モデルのトランスフォーメーションを通して、リスト・ビューと状態ビューのデフォルト・セットが自動的に作成されます。必要に応じて、追加のビューを手動で定義することができます。

ユース・ケース実現モデル
ソリューション構成では、2 種類のユース・ケース実現モデルが使用されます。1 つ目のモデルは、ビジネス・オペレーション・モデル内のビジネス・タスクごとに作成されます。このようなモデルごとに、一連のビジネス・ロール、一連のリスト・ビューと状態ビュー、および一連の ABO がビジネス・タスクを実行する目的でリンクされます。たとえば、「SO コーディネーター」がサービス計画成果物の特定のビューを通してサービス・プロバイダー割り当てタスクを実行するように指定するためのユース・ケース実現モデルがあります。別のユース・ケース実現モデルでは、アカウント・マネージャーがサービス注文成果物の対応する情報ビューを通してアカウント・マネージャー承認タスクを実行するように指定されます。

2 つ目のユース・ケース実現モデルでは、ビジネス・ロールごとのナビゲーション・シナリオが定義されます。たとえば、アカウント・マネージャー・ロールを担っているユーザーが、サービス注文成果物とサービス・タスク成果物のリスト・ビューを通して関連するサービス注文とサービス・タスクをどのようにナビゲートするかを指定するユース・ケース実現モデルがあります。

ビジネス・オペレーション・モデルのトランスフォーメーションを通して、ユース・ケース実現モデルのデフォルト・セットが自動的に作成されます。必要に応じて、追加のモデルを手動で定義することができます。

サービス統合モデル
このモデルは、ABO の状態遷移の一部として呼び出されるサービスのバインディングを定義するために使用されます。SDM プラットフォームの場合は、計画サービス、スケジューリング・サービス、計画調整サービス、計画実行サービスなどのサービスが含まれます。たとえば、計画実行サービスは、サービス計画 ABO の特定の状態遷移にバインドされます。サービス統合モデルは、手動でソリューション構成モデルに追加することができます。

拡大図

BPM モデル
BPM モデルは、ビジネス・オペレーション・レベルでの KPI、状態、および処置指定に基づいて手動でソリューション構成モデルに追加することができます。このモデルには、実行時のビジネス・プロセス・パフォーマンスをモニターするための要素、ダッシュボード表示用の可視性モデル、結果の詳細分析機能が含まれています。

上に戻る

特定のプラットフォーム上の SDM 実装は、モデル駆動型コード生成を通してプラットフォームに依存しないソリューション構成モデルから生成することができます。我々は、このアプローチを使用して、(1) J2EE** プラットフォームの WebSphere Business Integration Server Foundation¹² と (2) SCA (サービス・コンポーネント・アーキテクチャー) プラットフォームの WebSphere Process Server の 2 つの IBM プラットフォーム上に SDM ソリューションを実装しました。 ⁶

WebSphere Process Server 上の実装は、ビジネス・プロセス・コレオグラフィー用の SCA コンポーネント、ユーザー・インターフェース・コンポーネント、および BPM コンポーネントで構成されます。これらのコンポーネントについて、次のセクションで詳しく説明します。

SCA コンポーネント

SCA ベースのコンポーネント・アセンブリーの主要素は、成果物サービス、ビジネス状態マシン、サービス・コンポーネント、およびサービス・データ・オブジェクト (SDO) です。

成果物サービスは、ABO のサービス・インターフェースです。このインターフェースを通して、成果物データにアクセスして変更したり、成果物に対して同期オペレーションを実行したり、成果物のライフ・サイクルの観点からすれば膨大な外部イベントに関する情報を受信することができます。成果物サービスは、ステートレス・セッション・ビーンとして実装されます。ビジネス状態マシンは、成果物のライフ・サイクルを管理するために使用されます。

サービス・コンポーネントは、状態遷移の一部として ABO から呼び出されるサービスを表します。主なサービス・コンポーネントには、計画サービス (サービス注文の実行に関する具体的なサービス計画を作成するために使用される)、変更要求作成サービス (サービス注文に対して変更要求を作成する必要があるかどうかを決定する)、およびサービス計画を使用してサービス・タスク間の依存関係を決定し、それぞれのサービス・プロバイダーに連絡してそれらのタスクの実行をプログラムで開始する計画実行サービスがあります。計画実行サービスは、サービス計画で指定されたようにすべてのサービス・タスクが実行されることを保証することによって、サービス注文の実行全体を調整します。

サービス・データ・オブジェクト¹³は、SCA ベースの実装によって提供される基本的なクライアント・プログラミング・モデルを表します。クライアントは、成果物サービスを呼び出して成果物データを受信するときに SDO を受信します。同様に、クライアントは、SDM プラットフォームに SDO を戻して成果物データに対する変更処理を送ります。

ユーザー・インターフェース
SDM プラットフォームのユーザー・インターフェースは、MDBT 方式を使用して生成および拡張されます。モデル・トランスフォーメーションを通して、最初に、単純なユーザー・インターフェースがユーザーとの対話に関する隠れマルコフ・モデルに基づいて自動的に生成されます¹⁴。この対話では、ユーザーがシステム認証を通過します。ユーザー・アクションが保留になっている成果物インスタンスのリストが表示されます。ユーザーが特定の成果物インスタンスを選択します。選択された成果物インスタンスの詳細が関連成果物の詳細、関連営業種目、および適用可能な処理オプションとともに表示されます。ユーザーが処理オプションを選択して、必要に応じてデータを追加または変更し、そのフォームを処理するために送信します。サーバーでその要求が処理され、そのステータスがクライアントに返されます。

生成されたユーザー・インターフェースは、手動で「外観」をカスタマイズすることができます。

BPM
BPM のプラットフォームに依存しないモデルが、ビジネス・パフォーマンスをモニターおよび管理するランタイム・コードを生成するために変換されます。これには、イベントの相関と集約、KPI 評価、状態検出、ダッシュボード・レンダリング、およびデータウェアハウス・スキーマに関するコードが含まれます。また、OLAP コンポーネントで使用されるデータを抽出するための ETL (抽出、変換、およびロード) ソフトウェアも含まれます。我々の SDM 実装では、IBM Alphablox*¹⁵ によってOLAP 機能が提供されます。

我々の SDM ソリューションでの標準の使用

このセクションでは、我々の SDM ソリューションの設計、開発、および実行での標準の使用について簡単に説明します。UML2¹⁶ (統一モデリング言語** ²) が、ビジネス・オペレーション・モデリングとプラットフォームに依存しないソリューション構成モデリングのモデリング言語として使用されます。我々のソリューション実装では、J2EE¹⁷ テクノロジーが活用されます。

この SDM プラットフォームでは、Web サービス・ベースのインターフェースのセットを使用してレガシー・アプリケーションが統合されます。これらのインターフェースは、WSDL (Web サービス記述言語) 標準を使用して定義されます¹⁸。SDO は、さまざまな SDM コンポーネント間の通信に使用されます¹³。WSDL は、アトミック・サービス呼び出し用のサービス・リクエスター・インターフェースを定義するために使用されます。サービス・プロバイダーがこのインターフェースを実装します。実行時に、SDM コンポーネントが、このインターフェースを呼び出して作業の実施に必要な情報をサービス・プロバイダーに渡します。

WS-BPEL¹⁹ (Web サービス・ビジネス・プロセス実行言語) を使用して提供サービス成果物とサービス計画成果物内のアトミック・サービスの構成を定義します。実行時には、これらの BPEL 定義によって、同時並行通信状態マシンを使用して動的ワークフローと連合ワークフローが実行されます。

デプロイメントの経験

このセクションでは、現実的な設定で IT サービス・デリバリー用の SDM プラットフォームを使用した経験について説明します。サーバー・ビルド要求のプロビジョニングとソフトウェア・パッチの管理に SDM プラットフォームを使用しました。これらの機能のエンドツーエンド・プロセス・モデルにはかなりの隔たりがあるように思われますが、上述した 5 つの SDM 成果物を使用することによって、これらのプロセスの両方を均一に SDM アーキテクチャーにマップすることができました。提供サービスは、「サーバー・ビルド」と「パッチ管理」です。サーバー・ビルド・プロセスには、「サーバー・スペースの割り当て」、「IP アドレスの割り当て」、「サーバーのビルド」、「ネットワークへの接続」、「ハードウェアの注文」、「サーバー構成データの準備」、「稼働前構成」、および「出荷」のアトミック・サービスが含まれています。パッチ管理プロセスには、「パッチ分析」、「APAR (プログラム診断依頼書) サーバー・マッピング」、および「パッチ適用」のアトミック・サービスが含まれています。

SDM ソリューションを使用することによって、サービス・デリバリーの効率が大幅に向上しました。この結果は、(1) 合理化されたビジネス・プロセス (一部のレガシー・アプリケーションと「非付加価値」手順の排除)、(2) ワークフローの自動化、(3) カタログ・ベースのサービス要求作成、(4) 単一の SDM ポータルによるサービス注文のエンドツーエンドのライフ・サイクルの管理、(5) レガシー・アプリケーションとのプログラム統合、(6) カタログ内の複合サービス計画に基づく自動計画作成、および (7) アトミック・サービス・プロパティーに基づく自動サービス・プロバイダー割り当ての SDM 機能によるものです。

サービス注文とサービス・タスクを管理するための SDM プロセスがオファリング全体で再利用された結果、資産の再利用が促進されました。アトミック・サービスの選択最適化を通して、サービス・デリバリーの効率性が継続的に改善されました。ユーザーは、サービス・プロバイダーのパフォーマンスをモニターすることができるようになりました。特定のアトミック・サービスの実行で問題が生じた場合は、タスクを別のプロバイダーに転送することができるため、回復力が向上しました。

上に戻る

ビジネス・プロセスを IT に関連付けるための従来の作業のほとんどが、ワークフロー・モデリングに関係しています²⁰。ワークフロー管理システムが、コストを削減し、プロセス制御を保証し、プロセス実行とワークフロー成果物の両方の品質を向上させます²¹。ワークフローが、多種多様なビジネス・プロセスをサポートします。ワークフロー管理システムは、同期化された順序で人またはテクノロジーに作業を割り振りながら、プロセス・アクティビティーと情報フローの両方を整理しなければならない複雑なアプリケーションです。関連する複雑さと、可能性のあるすべてのワークフロー・シナリオを解決するために必要な価格要素のために、ワークフロー管理システムは、ある特定の種類のワークフロー管理に重点が置かれる傾向があります。

これまで、IT アウトソーサーは、IT 環境内の特定の問題を解決するためにワークフロー管理システムを適用するか、顧客の以前の IT サービス・プロバイダーからワークフロー管理システムを引き継ぐだけでした。これによって、多くの場合、購入したものと社内開発したものでワークフロー管理システムの混乱状態が生じました。このような異種システムを単一のエンタープライズ・システムで置き換えるいくつかの試みがなされてきましたが、単一のワークフロー・エンジンでは、相反する要件のすべてを解決することはできません。

MDBT アプローチと従来のワークフロー管理システムの設計には根本的な違いがあります。このソリューションでは、ワークフローのプロセスに重点が置かれるのではなく、ビジネス成果物のライフ・サイクルにおける状態変化に重点が置かれます。状態変化によって特定のアクションを起動することができます。このアクションでは、プロシージャーまたは自動的にプロシージャーを実行するプログラムを起動することができます。これらのアクションは、従来のワークフロー管理システムと同様に、実行対象のビジネス・タスクと見なすことができます。ビジネス・タスクの細分度によって、関連するビジネス成果物に変化がもたらされます。関連するビジネス・タスク全体が、ワークフロー・プロセスを構成します。

MDBT 方式と SOA の原則を適用することによって、多くの矛盾を解決するユニークなソリューションが誕生します。その結果のオブジェクト・ベースのアプリケーションが、それ自体による、またはワークフロー連合を形成する任意の数の外部ワークフロー・エンジンによるタスクの実行を調整します。

サービス・デリバリーにおけるビジネス目標は、集中管理の薄い層を維持し、タスクのパフォーマンスで最大限の柔軟性を可能にすることです。我々のソリューションは、日々のきめ細かな IT サービス業務の担当者の専門知識を取り入れ、彼らがビジネスに最適な方法でジョブが実行できるようにします。これは、サービス・タスクの ABO を、アトミック・サービスの形式でのサービスの抽象化の実施に制限することによって実現されます。アトミック・サービスの内部オペレーションは、記述または命令されるのではなく、サービス実行者の判断に委ねられます。企業は、複数のサービス・プロバイダーを使用して、独自のベスト・プラクティスまたは運営団体のベスト・プラクティスに従って、アトミック・サービスを実行することができます。

ASD の要件が満たされていれば、各サービス・プロバイダーが、その作業を支援する最良のツールを決定することもできます。このように、手動または外部のワークフロー管理自動化エンジンが、適切なビジネス制御を満たしている限り、アトミック・サービスを実行することができます。または、企業が、特定のワークフロー管理自動化エンジンを使用するように命令することができます。サービス注文とサービス・タスクは特定のツールまたは手動手順の使用に依存しないため、パフォーマンス・タスクが管理タスクから分離され、ASD の基本仕様が満たされていれば、誰でも、どこでも、どんな方法でもサービス・タスクが実行できるようになります。

影響力の大きい IBM System Journal 誌²²で、Zachman が、エンタープライズ・アーキテクチャー用のフレームワークを「企業の記述表現に関する 2 次元分類体系」として提案しました。本稿で説明するフレームワークと Zachman の研究には類似点がありますが、基本的な違いがいくつかあります。最も重要なことは、我々のフレームワークが分類体系ではなく、企業エンティティーの動作と構造の形式モデルであるという点です。したがって、我々にとっては層間の接続が極めて重要です。Zachman の研究に関する分類体系の各列には抽象化を表す互いに素なセルが含まれているのに対して、我々は多層モデルを使用しています。それぞれの層 (パースペクティブなど) には、パースペクティブのコア構造と動作を定義する基本モデルと、より多くの情報を追加し、互いに直交する拡張機能が含まれています。

オブジェクト管理グループ (OMG**) は、そのモデル駆動型アーキテクチャー** (MDA**) イニシアチブ²³を通して、ソフトウェア資産の作成、統合、および保守への包括的な新しいアプローチの促進に必要な標準を作成するために研究を続けています。MDA モデルは縦方向の 3 つの層で編成されます。上から順に Computation-Independent Model (CIM)、Platform-Independent Model (PIM)、Platform-Specific Model (PSM) です。CIM は、ソリューションの要件を取得するドメイン・モデルです。PIM と PSM は、別々の抽象化レベルでソリューション構造を記述します。

我々のフレームワークは、MDA アプローチと完全に調和しています。戦略層とオペレーション層は、MDA の CIM 層に対応します。計算層と実装層は、PIM 層と PSM 層に対応します。MDA アプローチを適用して、各層と層間の双方向リンク内でのモデル要素の明確な定義を通してモデル駆動型エンタープライズを構築します (層間のアルゴリズムの変換を含む)。モデル駆動型アーキテクチャーの良し悪しは、モデル自体に依存します。最大の課題は、我々の研究の中心である正しい抽象化 (モデル) の特定です。

SOA は、ソフトウェア資産を作成するための基本的なビルディング・ブロックとしてサービスを使用します²⁴。我々のフレームワーク内の計算層は、SOA ベースのビジネス統合および管理ソリューションの構築に必要なサービス・コレオグラフィー・コンポーネントとサービス・ブローカリング・コンポーネントをモデル化します。我々のフレームワークは、ビジネス・プロセスを組織化原理として使用して適応型エンタープライズ・システムを構築するために MDA と SOA を結び付けます。

Wu 他²⁵ は、Web サービス構成での BPEL 使用における課題を論じ、手続き型プロセス仕様言語で同期制約を指定するために DSCL (DAG [directed acyclic graph] Synchronization Constraint Language) と呼ばれる同期表現言語を提案しています。このアプローチは、プロセス・デザイナーの開発工数を効果的に削減することができます。この研究は、我々のアプローチを補完するものであり、提供サービス成果物に含まれるサービス構成の定義に DSCL を使用することができます。

Sauve 他 ²⁶ は、この分野の導入概要と調査において、3 層構造の基本的なビジネス駆動型 IT 管理 (BDIM) モデルを紹介しています。彼らのビジネス層は、我々の戦略層に対応し、彼らのビジネス・プロセス層は我々のオペレーション層に対応します。彼らは、モデル内の IT サービス層の内容をサブレイヤーの集合としてよりきれいな構造に編成できると提案しています。これは、プラットフォームに依存しない計算層とプラットフォーム固有の実装層の構築時に我々が行ったことです。加えて、我々は、フレームワークの内容定義でビジネス成果物の抽象化を主要な組織要素として使用し、層を定義するための形式モデルを開発し、層間のモデル駆動型トランスフォーメーションを提供します。

Tosic ²⁷ は、BDIM の 5 つの課題とそれらに対応するための 5 つのアプローチを説明しています。そのすべてが我々のフレームワークで処理されます。Brenner²⁸ は、構造と組織複雑性のディメンションに基づく ITIL** (Information Technology Infrastructure Library**) プロセスの分類法を紹介し、構造化が不十分なサポート・プロセスでのワークフロー・ツールの限定使用を論じています。計算レベル、厳密には、通信状態マシン・モデルで我々が導入した革新によって、高度に構造化されていないプロセスに対するツール・サポートの提供が容易になります。

Danciu 29 は、ビジネス・プロセス表現用に設計された形式化を分析し、IT 管理プロセス定義を表現するための適合性を評価し、IT 管理要件に従って調査対象の形式化を分類しています。我々が採用した形式化は、この研究で論じられている形式化とは基本的に別のものであり、我々の方が確実に IT 管理要件を満たす能力が優れています。Mayerl 他 30は、管理アプリケーションに関する要件を特定するためのサービス・レベル管理プロセスを分析し、Web サービスを使用したアプリケーションの統合を提案しています。

上に戻る

本稿で説明した研究は、サービス・デリバリーにおける最先端技術の発展に大きな功績を残してきました。最も重要なのは、ドメイン知識に基づく受信運用モデルとビジネス・パフォーマンス・モデルからなるサービス要求処理システム、このドメイン知識に基づいて開発されたソリューション・モデル、およびサービス要求処理を実行するために実装されたサービス・デリバリー・プラットフォームを編成するための新しいアプローチの設計と実装です。

このアプローチには、今日のサービス・デリバリー管理システムにはないいくつかのメリットがあります。このアプローチでは、サービス・デリバリー・プラットフォームとサービス・オファリングが明確に区別されるため、新しいオファリングに対する動的なサポートが可能になります。また、ロケーション・ベースの変数を計画プロセスに組み込む計画コンポーネントとスケジューリング・コンポーネントを使用したグローバル・デリバリー・モデル・ベースのプロセスの自動化が可能になり、パラメーター化されたルール・ベースのサービス計画を使用して最適化されたサービス・オファリングのセットが提供され、スケーラブルなコンピテンシー・ベースのアプローチがサービス・デリバリーに付加され、要求モデルに基づいてデリバリー機能と最適なコンピテンシーが編成され、KPI によってモニターされたサービス・デリバリー・パフォーマンス管理プラットフォームが SLA の違反通知に関するサポートとともに提供されます。

本稿で提供したモデリング・フレームワークによって、IT サービス管理ドメインのユニークな要件を解決するためにワークフロー・テクノロジーが改良および拡張されます。この拡張は、主に、ライフ・サイクル管理、動的プロセス実行、および連合ワークフローの 3 つの領域で行われます。

成果物の概念によって、エンド・ユーザーは、SDM のユーザー・インターフェースを通して、ワークフロー定義をその他のデータとして管理することができます。したがって、ワークフローのライフ・サイクルの管理に関しては、「実行時」と「ビルド時」の区別がありません。

サービス注文、サービス計画、およびサービス・タスクの各成果物の定義によって (およびそれらのコラボレーションを通して)、このシステムは、高度な動的プロセス実行シナリオをサポートします。たとえば、途中で計画を変更したり、必要に応じて新しいサービス・タスクを作成したり、既存のサービス・タスクをキャンセルしたりすることができます。

サービス・プロバイダー組織は一体構造のワークフロー・ツールを使用していることが多いため、エンドツーエンド・サービス・デリバリー管理に単一のワークフロー・エンジンを使用することは、あまり現実的ではありません。サービス計画成果物とサービス・タスク成果物の定義によって (およびそれらのコラボレーションを通して)、サービス・プロバイダーによって実施される作業の定義が、Web サービス経由でパッケージ化されて出荷されます。サービス・プロバイダーは、独自のワークフロー・ツールと作業構成明細を使用してこの作業を実施し、結果をサービス・コーディネーターに送り返します。

MDBT の機能を展開すれば、サービス・デリバリー管理の効率性のレベルが向上します。スキル、コスト、サービス期間などの MDBT に対応したメトリックだけでなく、さまざまな場所と実行者の KPI を採用したプロバイダーは、サービスでグローバルな効率性を利用したり、グローバルな状態に迅速に対応できるような計画を作成することによって、より高いレベルの回復力を手に入れることができます。

さらに、MDBT の利用はベースラインの領域で期待されています。最初のアカウントに関するメトリックと KPI の収集によって、サービスの実行をそのサービスの MDBT 運用モデルと比較するためのベースラインが設定されます。このベースラインを使用すれば、サービス・デリバリー担当者は、サービスの運用モデルから逸脱したカスタマイズの影響をより明確に評価することができます。

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

上に戻る

引用文献

1. S. Kumaran 著、「Model Driven Enterprise」、Proceedings of Global Enterprise Application Integration Summit. Banf, Canada (2004 年)、pp. 166-180
2. A. Nigam、N. S. Caswell 共著、「Business Artifacts: An Approach to Operational Specificatio」、IBM Systems Journal 42, No. 3, 428-445 (2003 年)
3. M. Hammer 著、「Deep Change: How Operational Innovation Can Transform Your Company」、Harvard Business Review (2004 年 4 月)
4. M. Castellanos、F. Casati、M.-C. Shan、U. Dayal 共著、「iBOM: A Platform for Intelligent Business Operation Management」、Proceedings of 21st International Conference on Data Engineering, Tokyo, Japan (2005 年)
5. S. Kapoor、K. Bhattacharya、S. Buckley、P. Chowdhary、M. Ettl、K. Katircioglu、E. Mauch、L. Phillips 共著、「A Technical Framework for Sense-and-Respond Business Management」、IBM Systems Journal 44, No. 1, 5-24 (2005 年)
6. 「WebSphere Process Server」、IBM Corporation、http://www.ibm.com/software/integration/wps/
7. S. Kumaran、P. Nandi 共著、「Adaptive Business Objects- A New Component Model for Business Integration」、Proceedings of Seventh International Conference on Enterprise Information Systems, (ICEIS 2005), Miami, Florida (2005 年)
8. E. Gamma、R. Helm、R. Johnson、J. Vlissides 共著、「Design Patterns-Elements of Reusable Object Oriented Software」、Addison-Wesley Publishing Company, NY (1995 年)
9. H. Ludwig、J. Hogan、R. Jaluka、D. Lowenstern、S. Kumaran、A. Gilbert、A. Roy、T. R. Nellutla、M. Surendra 共著、「カタログ・ベースのサービス要求管理」、IBM Systems Journal 46, No. 3, 531-548 (2007 年、本号)
10. C. Y. Baldwin、K. B. Clark 著、「Design Rules, Volume 1: The Power of Modularity」、The MIT Press, Cambridge, MA (2000 年)
11. J. Koehler、G. Tirenni、S. Kumaran 共著、「From Business Process Model to Consistent Implementation: A Case for Formal Verification Methods」、Proceedings of Sixth International Enterprise Distributed Object Computing Conference (2002 年)、pp. 96-106
12. 「WebSphere Business Integration Server Foundation」、IBM Corporation、http://www.ibm.com/software/integration/wbisf/features/
13. B. Portier、F. Budinsky 共著、「Introduction to Service Data Objects」、IBM Corporation (2004 年)、http://www.ibm.com/developerworks/java/library/j-sdo/
14. L. R. Rabiner 著、「A Tutorial on Hidden Markov Models and Selected Applications in Speech Recognition」、Proceedings of the IEEE 77, No. 2, 257-286 (1989 年 2 月)
15. 「DB2 Alphablox」、IBM Corporation、http://www.ibm.com/db2/alphablox
16. 「Unified Modeling Language」、Object Management Group (2007 年)、http://www.uml.org/
17. 「Java 2 Platform、Enterprise Edition、Version 1.4 Documentation」、Sun Microsystems (2005 年)、http://java.sun.com/j2ee/1.4/docs/
18. 「Web Services Description Language 1.1 (WSDL 1.1)」、Worldwide Web Consortium (2001 年)、http://www.w3.org/TR/wsdl
19. 「Business Process Execution Language for Web Services Version 1.1 (2002 年)」、http://www.ibm.com/developerworks/library/specification/ws-bpel/
20. F. Leymann、D. Roller 共著、「Production Workflow: Concepts and Techniques」、Prentice Hall PTR, Upper Saddle River, New Jersey (2000 年)
21. 「Workflow Management Coalition: Terminology & Glossary」、Workflow Management Coalition (1999 年)、http://www.wfmc.org/standards/docs/TC-1011_term_glossary_v3.pdf
22. J. A. Zachman 著、「A Framework for Information Systems Architecture」、IBM Systems Journal 26, No. 3, 276-292 (1987 年)
23. 「OMG Model Driven Architecture」、Object Management Group (2003 年)、http://www.omg.org/mda
24. K. Gottschalk、S. Graham、H. Kreger、J. Snell 共著、「Introduction to Web Services Architecture」、IBM Systems Journal 41, No. 2, 170-177 (2002 年)
25. Q. Wu、C. Pu、A. Sahai、R. Barga、G. Jung 共著、「DSCWeaver: Synchronization-Constraint Aspect Extension to Procedural Process Specification Languages」、Proceedings of International Conference on Web Services (ICWS ’06) (2006 年)、pp. 320-330
26. J. Sauve、A. Moura、M. Sampaio、J. Jornada、E. Radziuk 共著、「An Introductory Overview and Survey of Business-Driven IT Management」、Proceedings of First IEEE/IFIP International Workshop on Business-Driven IT Management (BDIM ’06) (2006 年)、pp. 1-10
27. V. Tosic 著、「The 5 C Challenges of Business-Driven IT Management and the 5 A Approaches to Addressing Them」、Proceedings of First IEEE/IFIP International Workshop on Business-Driven IT Management (BDIM’06)、(2006 年)、pp. 11-18
28. M. Brenner 著、「Classifying ITIL Processes; A Taxonomy under Tool Support Aspects」、Proceedings of First IEEE/IFIP International Workshop on Business-Driven IT Management (BDIM ’06) (2006 年)、pp. 19-28
29. V. A. Danciu 著、「Formalisms for IT Management Process Representation」、Proceedings of First IEEE/IFIP Inter- national Workshop on Business-Driven IT Management(BDIM ’06) (2006 年)、pp. 45-54
30. C. Mayerl、F. Troscher、S. Abeck 共著、「Process-Oriented Integration of Applications for a Service-Oriented IT Management; Integrated IT Management Architecture」、Proceedings of First IEEE/IFIP International Workshop on Business-Driven IT Management (BDIM ’06) (2006 年)、pp. 29-36

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

Santhosh Kumaran
IBM Research Division, Thomas J. Watson Research Center, 1101 Kitchawan Road, Yorktown Heights, NY 10598.Kumaran 博士は、モデル駆動型ビジネス統合分野の研究者チームを率いています。彼の研究対象は、形式モデルを使用したエンタープライズの構造および動作の明示的な定義と、形式モデルを使用したエンタープライズのパフォーマンスの統合、モニター、分析、および改善です。

Pete Bishop
IBM Integrated Technology Division, 11502 Burnet Road, Austin, TX 78758.Bishop 氏は、Integrated Technology Delivery organization の Technology and Integration Management competency の Information Services department に所属しているシニア・プロセス・アーキテクトです。主に、IT システム管理分野と IT サービス・デリバリー管理分野で 13 年以上、戦略的プロセスの研究に携わっています。

Tian Chao
IBM Research Division, Thomas J. Watson Research Center, 1101 Kitchawan Road, Yorktown Heights, NY 10598.Chao 氏は、Watson Research Center にある Business Informatics department のシニア・ソフトウェア・エンジニアです。National Taiwan University で学士号を、Virginia Polytechnic Institute でコンピューター・サイエンスの修士号を取得しています。彼女の研究対象には、モデル駆動型アプローチとビジネス・プロセス・セキュリティーを使用したビジネス・パフォーマンスのモニターおよび管理におけるサービス指向コンピューティング・テクノロジーが含まれます。また、複数の特許を保有しています。発明とプロジェクト関連の両方で賞を受けたり、多くの雑誌や会議論文に出稿したりしています。

Pankaj Dhoolia
IBM Research Division, India Research Lab, 4 Block-C Institutional Area, Vasant Kunj, New Delhi, India 110070.Dhoolia 氏は、IBM India Research Laboratory でビジネス情報科学分野に従事しています。彼の研究対象は、形式モデルを使用した適応型ビジネスの詳細な構造の記述および実装です。

Prashant Jain
IBM Research Division, India Research Lab, 4 Block-C, Institutional Area, Vasant Kunj, New Delhi, India 110070.Jain 氏は、India Research Lab の Business Development and Solutions department のマネージャーです。Washington University でコンピューター科学の修士号と学士号、また The College of Wooster で物理学の学士号を取得しています。ソフトウェア研究、プロジェクト管理、ビジネス・コンサルティング、およびソフトウェア製品の設計および開発に 11 年以上の経験があります。主な興味分野は、デザイン・パターンとモデル駆動型ビジネス・プロセス統合で、特に、モデル駆動型ビジネス・トランスフォーメーションを促進するツールおよびテクノロジーに重点を置いています。デザイン・パターンに関する書物の著者でもあります。

Rajesh Jaluka
IBM Integrated Technology Division, 2455 South Road, Poughkeepsie, NY 12601.Jaluka 氏は、IBM Technology and Integration Management competency のシニア IT アーキテクトです。サービス・デリバリー管理プロジェクトのリード・アーキテクトとして、IT サービスのデリバリーの合理化、サービス・カタログの内容とワークフローの構築、および SDM ツールの展開に関する方法を研究しています。製造、金融、通信、およびサービスの各業界向けの IT ソリューションの開発および展開に 18 年の経験があります。

Heiko Ludwig
IBM Research Division, Thomas J. Watson Research Center, 19 Skyline Drive, Hawthorne, NY 10532。Ludwig 博士は、Watson Research Center の研究員です。サービス・デリバリー管理部門のメンバーとして、サービス・コンポーネント化、サービス・デリバリー管理プラットフォーム (大規模疎結合分散システムの側面を含む)、連合ワークフロー管理、およびプロセスと構成の変動性管理を研究しています。SLA およびポリシー管理にも関与しています。IBM Zurich Research Laboratory で勤務していたころは、組織間プロセス管理を研究していました。ドイツのバンベルグにある Otto-Friedrich University で情報システム (Wirtschaftsinformatik) の修士号 (Diplom) および博士号を取得しています。Ludwig 博士の詳細については、http://www.research.ibm.com/people/h/hludwig/ を参照してください。

Ann Moyer
IBM Global Technology and Integration Management, 24 Niles Drive, Woodstock, NY 12498。Moyer 氏は、IT サービス業界に 26 年以上携わっている著名なエンジニアです。彼女の専門分野は、e-business およびオンデマンド・テクニカル・ソリューションの開発、システム管理、システム統合、IT サービス・カタログ、コール・センター・テクノロジー、およびシステム・サポートです。

Anil Nigam
IBM Research Division, Thomas J. Watson Research Center, P.O. Box 218, Yorktown Heights, New York 10598。Nigam 博士は、University of Rochester でコンピューター科学の博士号を取得した直後の 1981 年に IBM Research Division に入社した Business Informatics department の研究員です。IBM での彼の研究は、VLSI 設計システム、並列処理アーキテクチャーおよびデータベース・マシン、ロジック・プログラミングおよびデータベース、知識表現、定性推論、運用ビジネス・モデリング、ビジネス設計など多岐に渡っています。Research Division Awards、Research Commercialization Award、IBM Consulting Group Engagement Excellence Award、Technical Group Award などの数多くの賞を受けています。また、幅広い著書があり、多くの特許を保有しています。

目次へ戻る

上に戻る