アーキテクチャ・ジャーナル

コンポジット アプリケーション ― 新しいパラダイム

Chris Keyser
2009/02/16
Page1 Page2

本コーナーは、マイクロソフトが季刊で発行する無料の技術論文誌『アーキテクチャジャーナル』の中から主要な記事を Insider.NET 編集部が選び、マイクロソフトの許可を得て転載したものです。基本的に元の文章をそのまま転載していますが、レイアウト上の理由などで文章の記述を変更している部分(例:「上の図」など)や、図の位置などを本サイトのデザインに合わせている部分が若干ありますので、ご了承ください。『アーキテクチャ ジャーナル』の詳細は「目次情報ページ」もしくはマイクロソフトのサイトをご覧ください。

記事の著作権はマイクロソフトに帰属する。
©2008-2009 Microsoft Corporation. All rights reserved.

ご注意:本記事は、雑誌の内容を改変することなく、そのまま転載したものです。このため用字用語の統一ルールなどは@ITのそれとは一致しません。あらかじめご了承ください。
ご注意:本稿は米国で2007年1月に発行されたものであり、内容が若干古くなっています。

概要

 コンポジット アプリケーションは、権限を与えられた技術的なビジネス ユーザーが、コンポーネント化されたビジネス機能を相互接続できる、長い間求められてきたビジネスでの至福を実現します。コンポジット アプリケーションは、多くの点でビジネス ユーザーの Web 2.0 および「マッシュアップ」に相当します。コンポジットについては大ブームが巻き起こったこともありましたが、ベンダの多くは真の価値をもたらすことに積極的ではありませんでした。しかし、テクノロジの進化に伴って状況は変わりつつあり、複合化はビジネス ロジックの構築においてますます重要な一面となりつつあります。この記事では、今日のビジネス課題でコンポジット アプリケーションを使用することについての基本と利点について説明します。

ビジネスの積極性

 多くの企業は、急速に変化を遂げ続けるビジネス環境に迅速に対応し、競争上の優位を獲得できる権限をビジネス ユーザーに与えることを最優先しています。ビジネス ユーザーは、プロセスやロジックを作成するのに、長い間 IT の力を借りなければなりませんでした。しかし、コンポジット アプリケーションは、再利用に関する議論を技術的ドメインからビジネス ドメインへと移行させ、ストーブの煙突のようなホスト アプリケーションや開発者の制約から企業を解放し、プロセス フローやメタデータを通じてビジネスを最適化する動作を定義できるようにする可能性を持っています。

 消費者市場における昨今の Web 2.0 の現象は、根本的なシフトが起きていることを示しています。このことは、ユーザーの期待が高まっていることを示す先行指標とも言えます。自分自身の経験を自分で促進するユーザーが増えており、その結果、職場でも同じことが期待されるようになっています。Web 2.0 の使用経験を持つユーザーは、職場経験の制御を行使して、さらに参加したいという期待が強くなっています。これらのユーザーは、最適ではない経験を受け入れるのではなく、ビジネス アプリケーションを自分の使用形態に合わせて調整したいと望んでいます。こうした Web 2.0 の機能は、企業に進出するにつれて成熟して行くでしょう。つまり、Web 2.0 で重要なのはテクノロジではありません。重要なのはソーシャル ネットワークであり、ユーザーが自分の経験をコントロールできることです。エンド ユーザーによって作成された破棄可能なアプリケーションなどは、急激に変化する環境に対応できる究極の能力を表しています。企業がこの力をエンド ユーザーに移行する方法は、開発者だけでなくビジネス ユーザーも考慮に入れたコンポジット ソリューションを使用することです。

 複合化プラットフォームは、ハードワイヤ化された脆弱な依存性に頼ることなく、複数のテクノロジ ベンダがソリューションに参加できるメカニズムです。これまで以上に広範なアプリケーション ベンダからの価値を、今までよりもずっと簡単に実現できる複合化フレームワークは、他のコンポーネントの依存からコンポーネントを効果的に分離し、抽象化できる対話モデルを提供します。システムの複合化が進むにつれ、システムはますますメタデータ駆動型になって行きます。メタデータに移行することで、自己復旧やアプリケーションのバージョン復元などの新しい機能セットの可能性が広がります。このため、複合化モデルでは、サービス指向の多くの側面が環境全体にもたらされます。

複合化の段階的説明

 複合化が意味するものは、ユーザーによって異なります。現在、基幹業務(LOB) ベンダのシステムの大半では、潜在顧客から売り上げへと移行する個々のポイントを表した、よく知られた手順を管理しています。これは構造化プロセスと呼ばれることもしばしばです。

 ここ数年、ベンダは Microsoft Office などの使い慣れたアプリケーションをこのプロセスの上に配置して、既存のプロセスでの特定のポイントの対話におけるユーザー インターフェイスを改良するようになっています。こうした改良は、プロセスの生産性とユーザビリティを高め、アプリケーション ロジックに接することができるユーザーの範囲をさらに広げました。このような機能だけでも、ビジネスにとってはアプリケーションを採用する動機となるはずです。

 これらのアプリケーションは、ユーザー層を広げる点で主要な改良点と言えますが、通常は既存の機能をさらに使いやすく表面化しただけです。しかし、このようなアプリケーションであっても、従来の LOB アプリケーションがこの制御レベルを超えられない場合があります。次の事柄が阻害因子になっている場合があります。

  • レガシ システムの構築―多くの依存が暗黙に組み合わさったこれらの複雑なアプリケーションのパーティション作成やコンポーネント化は負担の大きいタスクであり、組み込まれているロジックを真に解きほぐすには長い時間がかかります。LOB ベンダは、最終的には、「複合化」スペースでさらに深いレベルの関与が可能になるサービス指向の概念に基づいて、緊密に連結したレガシ システムから結合のゆるい機能へと移行することを予定しています。

  • 制御の喪失―従来の LOB ベンダにとって、サービスや設定可能なユーザー インターフェイスを通じて機能を分離および表面化する過程において、データやプロセスの制御を一部手放さなければならないのは恐ろしいことです。

  • 水平な性質を持つコラボレーションの普及―顧客は 1 つのコラボレーション インフラストラクチャを求めています。LOB ベンダは、必要に応じてスケール アップやスケール ダウンを行ったり、広く普及する一般的な管理しやすい機能を提供したりするのに適していない可能性があります。

 既存のプロセスの前に新しいユーザー インターフェイスを重ねても、ビジネスに有意義な洞察力や制御が得られるわけではありません。アプリケーションが一見使いやすそうに見えても、従業員がタスクを達成する能力が高まる結果は得られません。たとえば、図 1 の簡素化されたプロセスは、カスタム設計された製品で潜在顧客を注文に結び付ける過程を示しています。潜在顧客を売り上げに結び付けるためには、最初に構造化されたプロセスで表される以外にも、要素間に多くの作業が必要となります。この作業は通常、共同作業的な性質を備えています。技術革新は、コラボレーションの組み合わせにおいて、想像力が優位に立ち、インフォメーション ワーカーの創造性が問われ、重大なビジネスの差別化が発生する、構造化プロセスの外側で起きることが多いのです。

図 1: カスタマ リレーションシップ マネジメント (CRM) での構造化プロセスの例

 Microsoft Office などの新しいインターフェイスを使用することによって、データの表示は改良されるかもしれませんが、そのこと自体はコラボレーションの問題解決にはつながりません。LOB システムをドキュメント中心のアプリケーションに統合すると、LOB プロセスにインフォメーション ワーカー指向のワークフロー拡張を作成する豊かな機会が生まれます。多くのポータル ソリューションがワークフロー テクノロジを統合している (Microsoft Office SharePoint と Microsoft Windows Workflow の統合など) 現在、ドキュメントの管理とビジネス プロセス管理の境界線が不明瞭になり、LOB アプリケーションの共同作業用ワークフロー ソリューションとしての特徴が強まるでしょう。図 2 の例は、顧客取引担当チームが Microsoft Word の企画書を集めて RFP に応答するまでの過程を示しています。これは、複合化を使用して、複数のユーザー操作チャネル (Microsoft Word、Microsoft Excel、Microsoft Outlook) にプロセスを拡張し、特別プロセス 1 つと構造化プロセス 1 つの協調プロセスを異なるシステムで実行することによって 1 つの論理的なビジネス タスクを達成する一例です。

図 2: Microsoft Office を使用した複合化

 コンポジットは、独立した LOB システムが実行されているプロセスをつなぐ役割も果たします。付加価値処理を投入しなければならない状況が、現在は統合ミドルウェアを通じて行われていることを考えると、コンポジット サービスは非常に道理にかなっています。ここでは、インフォメーション ワーカーが、顧客に電子メール送信された見積もりの確認応答を Microsoft Outlook で受け取り、CRM システムと ERP システムをつなぐコンポジット サービスを呼び出して CRM システムで販売注文を作成し、ERP システムで社内処理用の発注書を作成する例を紹介しています。


 INDEX
  [アーキテクチャ・ジャーナル]
  コンポジット アプリケーション ― 新しいパラダイム
  1.複合化の段階的説明
    2.新しいアプリケーション パラダイム

インデックス・ページヘ  「アーキテクチャ・ジャーナル」


Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Insider.NET 記事ランキング

本日 月間