アプリケーションを1つのUIに統一することは可能か？
様々なデスクトップ・アプリケーションを１つの方式（例えばWebベース）に統一することはできるのでしょうか？
前述の通り、各種ユーザー・インターフェースの実装技術には得意・不得意があります。もちろん、要件が1つの技術で満たせるのであればそれは1つの解です。しかしながら、最適な1つの手法に絞り込めるとは限りません。たとえそのような検討結果となったとしても、異なる方式を採用しているすべての現行システムを統一すべく刷新することは多大な費用と時間を要しますし、段階的に更改するのではいつまでたっても同じ土俵に上がれないシステムが出てきます。ユーザー・インターフェースの統一のためだけに稼動中のシステムに手を入れることに対して抵抗を感じる方も少なくないはずです。
何よりも技術を統一しただけでは、肝心の課題解決には到達できないのです。今後も実装技術の混在状態がなくなるとは難えにくいと考えるべきでしょう。コストをかけて統一するよりは、現在利用されている様々な実装を受け入れられる器としてのフレームワークが必要といえるのではないでしょうか。
もう1点、視野に入れておくべき傾向があります。それはイントラネットだけではなく、インターネットがエンド・ユーザーに必要な機能や情報を提供する場として以前よりも大きな存在感を持ってきているという点です。特にここ数年のWeb2.0の流れに後押しされ、インターネット上で利用できるサービスはいまだ加速的に増え続けています。エンド・ユーザーが利用するアプリケーションが増えたときに、そのすべてとユーザー自身とが直接対話していたのでは活用できる数に限りがあります。
理想的にはエンド・ユーザーは最小公倍数的な必要情報の提供と、人による判断が必要な事項への回答のみ行えば済むはずです。アプリケーション過多の時代では例え最終的に利用するバックエンドシステムの数が増えたとしても、必要なユーザー・インタラクションを軽減する仕組み・フレームワークが必要となると考えられます（図2）。
コンポジット・アプリケーション
コンポジット・アプリケーションとは
これら課題に対する1つの解が「コンポジット・アプリケーション」というモデルです。“コンポジット”は“複合”と訳される単語であり、コンポジット・アプリケーションとは“複数のアプリケーションを組み合わせて作られた複合的なアプリケーション”という意味合いとなります（図3）。IBMでは、この“コンポジット・アプリケーション”のモデルを実現するフレームワークを様々なデスクトップ・アプリケーション基盤に取り入れています。
以下、コンポジット・アプリケーションの主要な特徴を述べます。前半はコンポジット・アプリケーションといえるための必須機能といえます。後半はIBMが企業利用に適用するために拡張している特長です。
コンポジット・アプリケーションの主な特徴
集約
１つの業務に必要な複数のシステム、そのそれぞれとのインターフェースとなるアプリケーションを1画面に集約することで、エンド・ユーザーは効率的に必要機能・情報にアクセスすることができます。組み合わせられる個々の部品は既存のデスクトップ・アプリケーションにあたり、以降これを“コンポーネント”と呼びます。
コンポーネントの実装方式としてより多くのアプリケーション・モデルをサポートすることで新規開発をせずとも既存資産を活用できるようになります。複数の機能を融合して新しい価値を生み出す手法を一般的にマッシュアップと呼ぶことが多くなりました。この集約の特徴から、コンポジット・アプリケーションはアプリケーション画面のマッシュアップとも言えるでしょう。
連携
コンポーネント間は必要に応じて連携させることができます。これにより、バックエンドでシステム間が直接つながっていなくとも、エンド・ユーザーは必要最小限のステップ数で連続的・効率的に業務をこなすことが可能となります。以降、コンポーネント間連携の設定を“ワイヤ”、ワイヤの設定することを“ワイヤリング”と呼びます。
このモデルはシステム・インテグレーション（統合）の視点からは“フロント・エンド・インテグレーション”とも呼ばれます。データ統合やプロセス統合など、システム・インテグレーションにはどのレイヤーでそれを実現するのか、いくつもの選択肢があります。“フロント・エンド”とはクライアント、つまりデスクトップ・アプリケーションをさします。クライアント同士の連携によりシステム間を繋ぐインテグレーション手法といえます。
コンポーネント開発と画面レイアウト作成・ワイヤリングの分離
コンポーネントは既存の資産かもしれませんし、新規開発、あるいは外部ベンダーから購入したものかもしれません。こうしたコンポーネント間が連携するために、それぞれが互いを意識しなくともよい（依存しない）モデルを提供します。
互いに依存しないことはワイヤリングをコンポーネント開発と独立して行えることを意味します。管理者やエンド・ユーザーが目的や状況に応じて必要なコンポーネントを画面に配置して、ワイヤリングできるわけです。コンポーネントの再利用性や流通を考えたときにもこの特徴は非常に重要です。
ロール・ベースのカスタマイズ
企業の中では部門、役職、担当顧客・地域、保有スキルなどエンド・ユーザーを様々な切り口で区分することがあります。その区分によって業務に必要あるいはアクセスが許可されるべきコンポーネントやデータが異なるはずです。このようにエンド・ユーザーの何かしらの属性に応じた画面のカスタマイズやアクセス制御を行うことができます。エンド・ユーザーにもその権限を与えて自分なりのカスタマイズを許容する場合もあります。こうしたエンドユーザーに応じた画面やデータの変更をロール・ベースのカスタマイズあるいはパーソナライズと呼ぶこともあります。
サーバー管理型
企業システムで採用する場合、どのユーザーがどのようなアプリケーションのどのバージョンを使用しているのか、きちんと現状を管理できる必要もありますし、時には能動的に更新をかけられなければなりません。
