ガートナー ジャパン
メインメニュー ホーム リサーチ コンサルティング ベンチマーク エグゼクティブ プログラム イベント 会社情報 メインメニュー
SAMPLE RESEARCH

サンプル・リサーチ

イメージ 3層アプリケーションの概念を脱する時が来た
アプリケーション (APP) /APP-13-20
Research Note
R. Altman
掲載日:2013年2月19日/発行日:2013年2月5日

本リサーチ分析レポートのテーマに関心をお持ちの方は、2013年2月28日(木)・3月1日(金)に開催する 「ガートナー エンタプライズ・アプリケーション & アーキテクチャ サミット 2013 | Nexus時代に備えたアプリケーション変革への一手」 のページを是非ご覧ください。
本サミットでは、今後のアプリケーションおよびその基盤の在り方に大きな影響をもたらす「クラウド、モバイル、ソーシャル、インフォメーションがもたらすインパクト」をテーマに、企業のIT部門が取り組むべき施策について提言します。
(イベント終了後も開催実績としてご覧いただけます)

 

3層アーキテクチャは、今日のアプリケーションを表現するには過度に単純化され、直線的である。今日のアプリケーションの異種混在性を考慮するならば、より適切なモデルとは、複数のデータ・ソースを活用しながら、さまざまなクライアント・プログラムとデバイスをサポートするサービスの形態になる。

要約

主要な所見

    ● 多くの最新アプリケーションは、さまざまなコンポーネントを活用し、各種のテクノロジとデータ・モデルを採用するコンポジションである。さらに重要なことに、最新アプリケーションは部分的に所有者が異なる場合があり、所有者は各自のリソースをそれぞれの優先順位、予算、スケジュールで管理している。

    ● 最新アプリケーションの特性がこのように多様であることを考慮すると、アプリケーション・アーキテクチャに対する見解を、すなわち、アプリケーション・アーキテクチャをどのように取り扱うか、アプリケーション・アーキテクチャとは何を意味するか、他のアーキテクチャとどのように関連付けられるか、開発のベスト・プラクティスにどのように影響するかなどの考えを、新たにすることは当然である。

    ● 3層アーキテクチャは、ユーザー・インタラクションを管理する層、データを管理する層、ビジネス・アプリケーション・ロジックにかかわる中間層から構成される。比較的単純なアプリケーションでコンポーネント間の関係性を表現する場合は、3層アーキテクチャで十分である。しかし、最近のコンポジット・アプリケーションやプロセス管理ソリューションの極端な異種混在性を考慮すると、今日のアプリケーションに使用されるサービス間の、多様で横断的な依存関係を認識するモデルがより適切であろう。
推奨事項
    ● ITリーダーは、アプリケーション実装の関連事項を大まかに (つまり、クライアント・プログラムとデバイス、アプリケーションとビジネス・ロジック、データ管理の層に) 分割して検討するために、3層アーキテクチャを引き続き使用する。

    ● ITリーダーは、最新アプリケーションの構成要素として使用されるさまざまなクライアント・プログラム、デバイス、ビジネス・サービス、データ管理サービス間の相互関係と依存性をさらに理解するために、多次元的なモデルを採用する。このモデルを通じて、自身はもちろん、配下のテクニカル・チームや事業部門のリーダーも、必要に応じてシステムの全体的な描写にドリルダウンし、ソリューションの各コンポーネント間の相互作用と依存関係を視覚的に検証できるようにする。

目次
    分析

     要旨

     要約

     力の結節とアプリケーション要件

    推奨リサーチ

図目次
    図1 3〜n層型アーキテクチャ
    図2 多様なクライアント・デバイスとプログラムをサポートするアプリケーション
    図3 各所で所有/管理される多様なデータ・ソースへのアクセスを管理するアプリケーション
    図4 ガートナーのICF
    図5 最新アプリケーションの多くはパッケージ、パートナーのアプリケーション、クラウド・アプリケーション内のビジネス・ロジックを統合したコンポジションである
    図6 各種のUI、サービス、データ、ネットワークが組み合わさった多数の事例に対応するアプリケーション・アーキテクチャ
    図7 どのようなデータ・ソース、サービス実装様式、ユーザー・エクスペリエンス・デバイス、ネットワークにも対応するアプリケーション・アーキテクチャ
    図8 デバイス、サービス、データ・ソースには、異なる優先順位やスケジュールを抱えるそれぞれの所有者がいる
    図9 複数の異種混在型リソースを統合し、それらのいずれも単独では提供できない機能をもたらす今日のアプリケーション
    図10 最新コンポジット・アプリケーションの理解と設計のための多次元モデル


分析

要旨
多くの最新アプリケーションは、コンポジションである。つまり、複数のコンポーネントで構成され、各コンポーネントには異なるアーキテクチャとデータ・モデルが採用されている。しかし、アプリケーションを構成するコンポーネント間において最も重要な相違とは、コンポジションの各部分において所有者が異なり、各所有者が関係者の要件に応えるために、各自のリソースをそれぞれの優先順位、予算、スケジュールで管理していることである。

こうした異種混在性の拡大は、アプリケーションの設計、開発、展開、保守/拡張から成る、アプリケーションの開発ライフサイクルに影響する。また、異種混在性は展開アーキテクチャと運用管理にも影響する。最新アプリケーションのこうした特性の多様化は、かつての業界の状況とかなり異なっており、アプリケーション・アーキテクチャに対する見解を、すなわち、アプリケーション・アーキテクチャをどのように取り扱うか、アプリケーション・アーキテクチャとは何を意味するか、他のアーキテクチャにどのように関連付けられるか、開発のベスト・プラクティスにどのように影響するかなどの考えを、新たにすることは当然である。

アーキテクチャに対するこの新たな見解は、サービス指向アーキテクチャ (SOA) に基づいているが、SOAに対する今日のわれわれの理解を超越する必要がある。SOAに関する今日の見解の大半では、クライアント・プログラムが何らかのビジネス・サービスを呼び出すと、次にそのビジネス・サービスがデータ管理サービスを呼び出す。この点において、3層アーキテクチャの概念が完璧に当てはまる。

しかし、3層アーキテクチャのトポロジは、現実世界の多くのアプリケーションを過度に単純化した捉え方である。このトポロジが提示する極めて直線的な形で考えると、アーキテクトは、各サービスが特定のクライアント専用として設計されるという概念に行き着く。最近のコンポジット・アプリケーションの極端な異種混在性を考慮するならば、より適切なモデルとして、(原子的 [アトミック] で複合的な) 多数のサービスが複数のクライアント・プログラムをサポートすることを明示するトポロジを検討すべきであろう。

要約
1980年代後半、IT部門は2層のクライアント/サーバ型アーキテクチャを採用していた。1層はPCベースのアプリケーションを表し、もう1層はサーバ・ベースの、当該アプリケーション向けのデータ管理層を示す。このモデルで経験を重ね、複数層間の統合を管理するランタイム・ミドルウェアを獲得したことで、2層は3層になり、やがてn層になった。そこでは1つの層がユーザーとのインタラクションを管理し、さらに1つの層が引き続きデータ管理層となり、そして中間層 (1つまたは複数) がアプリケーション・ロジックを格納する。しかし、このモデルを脱する時が来た。

アプリケーション・アーキテクチャを層として捉えることの問題点は、アプリケーションをただ一次元的に定義することである (図1参照)。すべての各種データ・ソースが最下層にあり、すべてのユーザー・インタフェース (UI) ロジックが最上層にある。そして、アプリケーションの残りのロジックが、それらの中間層にある。つまり、上から下へ、あるいは下から上へのように直線的であり、一次元的である。

図1 3〜n層型アーキテクチャ
図1
出典:ガートナー (2012年9月)

しかし、今日のアプリケーションはこのように作られてはいない。多くのアプリケーション (コンポジット・アプリケーション、ビジネス・プロセス管理 [BPM] ソリューション、複雑なアナリティック・ソリューションなど) は、もはや上から下へ、下から上へのような形でアプリケーション・フローを正確に描くことはできない。むしろ、特定の目的用に記述されたコードや各種のレガシー/パッケージ・アプリケーション間で生じるプログラムのインタラクションによって、データの要求と応答はさまざまな方向へ動いている。結果として、アプリケーション・アーキテクチャの図は、アプリケーション・ロジックとデータ・ソースが相互に連結された網のようになるはずである。これらは多様なアプリケーション向けに機能し、ひいてはさまざまなユーザーや、多様なクライアント・デバイスおよびプログラムをサポートしなければならない。

力の結節とアプリケーション要件
「テクノロジは急速に変化している」という表現はもう使い古されている。コンピュータの導入以来、テクノロジは常に急速に変化してきた。「今日の課題はこれまでとは異なる。なぜなら、今や最速のペースで変化が起きているからである」という意見には根本的な誤りがある。私たちは過去のテクノロジ世代に起きていた (つまり、ほかの誰かが経験した) 事柄に対し、現在経験している事柄を過大評価しがちである。しかし、この点の証明は容易ではないが、結局のところあまり問題ではない。すべては変化する。その点は誰もが同意できることであり、そこから出発すればよい。

一方、変化の速度よりも重要なことは、変化の質である。以下に示すように、これほど多くの領域で変化に対処しなければならなかったことは、これまでおそらくなかったであろう。
    ● 今日の開発者に与えられたクラウド展開という選択肢は、開発、テスト、セキュリティ、パフォーマンス最適化だけでなく、アプリケーションの運用、監視、管理に関しても課題を提示する (「The Nexus Effect: How Cloud Computing Alters Established Architecture Models」参照)。
    ● データ・ソースやデータ・タイプの拡散にかかわる情報管理上の課題によって、非構造化データや緩やかに構造化されたデータのビッグ・リポジトリの管理と分析や、イベント・データ・ストリームの継続的なアナリティクスが必要である。

    ● モバイルには調整が必要である。ユーザーは通常、数種のデバイスを所有しており、各デバイスが異なった機能セットを備え、またそれぞれが使用されるコンテキストには、さまざまな一群の主要なユーザー要件がある。デバイス上のセンサによってより多くのコンテキスト・データを活用できる機会が生まれることは、「歩きながら」という使い方と同じく、モバイル・アプリケーションに影響を与える。位置は、さらに問題となる。なぜなら、ユーザーが企業の施設内からシステムにアクセスすると想定することはもはやできないからである。またデスクトップPCやノートブックPCに比べて、メモリ・サイクルやCPUサイクルが短いほか、高度なモバイル・デバイスはネットワーク関連の問題も提起する。例えば、帯域幅の制約、不均一なスループット、ネットワーク・アクセスの散発的な切断である。また、バッテリ消費も新たな問題である。なぜなら、デバイス上の処理が増え、データ転送のためのネットワーク利用負荷が増したことで、バッテリ電力という限りある資源の消費が増えたからである。

    ● ソーシャルによって、データ・ソースとユーザーの間の直線的なモデルを安易に受け入れることは既にできなくなっている。反対に、さまざまなユーザーが、さまざまなソースからデータを入力し、使用している。結果として、「真実」の唯一の源という前提はもはや通用しなくなるため、情報モデルには、同一エンティティに関するデータの、連動し矛盾するバージョンが存在し得ることを受け入れる必要がある。

    ● 過去10〜20年間に、仮想エンタプライズへの移行が徐々に進行している。ソーシャル・コンピューティングは、企業のメンバーや関係性に関する決定論的モデルが崩壊する一因となった。さらに、企業の関係性は、デマンド/サプライチェーンの中で次第に動的なものになっている。なぜなら、アウトソーシングやオフショアリングのために、こうしたSCMの取り組みが複雑化しているからであり、それは協働計画/予測/補充 (CPFR)、顧客需要計画、総合的品質管理 (TQM) においても同様である。
こうした変化は、これらの新しいテクノロジの利用だけで実現するわけではなく、人々は新しい形でこうしたテクノロジと対話し、新たな用途やアーキテクチャのパターンを生み出し、高度化する抽象化と再結合を管理する必要もある。これらが破壊的なテクノロジになり得る条件は、ビジネスのプロセス、戦略、モデルを根本的に変えられることである (「Stepping Up to the Nexus of Forces With Nexus-Enabled Application Architecture」および「The Nexus Effect: How Mobile Computing Alters Established Architecture Models」参照)。複数の同時に進む革新があるため、こうした革新のさまざまな組み合わせに対処する必要がある。

こうした状況は、未曾有の不確実性と機会をもたらそうとしている。アプリケーション開発の目覚ましい革新と、「ペース・レイヤ」というアプリケーションに対する新たな考え方によって、サービスとアプリケーションの開発とデリバリは迅速化され得る。その成果は、柔軟で、タイムリーに提供され、短期的なビジネス・ニーズに応じて調整可能なITベースのソリューションである。

しかし、そこには難点がある。この次世代ソリューションの真の力を引き出すためには、企業がビジネスとITの幅広いエコシステム内において、すなわち、事業部門、提携先、IT部門、システム/サービス・インテグレーター、ベンダー、アウトソーシング事業者などと協働する必要がある。単独でそれを成し得る者はいない。協働できない企業、つまり、革新を奨励するパートナーシップを効果的に管理し、かつそうした革新を新たな戦略的機能とビジネス成長に向けられない企業は、極めて不利な立場に置かれることになる。数年にわたりCIOは、インテグレーター、ベンダー、アウトソーシング事業者などのソーシング・パートナーを、標準的なプロセスを低コストで実施する手段と見なしてきた。しかし、現在、こうしたパートナーは革新の源となり得る存在であり、複雑なソリューションを実現し、管理する唯一の手段であることが多い。

アーキテクチャの捉え方を変更しなければならないというプレッシャーをこれまで感じなかったわけではない。第一にこうした破壊的なテクノロジが登場していなかったのであり、そうしたテクノロジは (それぞれに多少の差はあるものの) 最近になって存在するようになった。このほか、アプリケーション・アーキテクチャに対する安定したアプローチを破壊する現象があった。例えばSOA、BPM、マッシュアップ、コンポジット・アプリケーション、イベント・プロセシングである。

かつて、開発者は通常、従来の3層アーキテクチャやクライアント/サーバ型アーキテクチャを使用して、アプリケーションを自身や他者に対して説明していた。しかし、開発者が構築すべきアプリケーション・タイプに合致した設計パターンは、もはや3層アーキテクチャで十分に表現することはできない。3層アーキテクチャは直線的すぎるため、アプリケーションを構成するコンポーネント間の関係が極めて単純であることが前提になる。特に、技術的にもセマンティクス的にも異種混在環境を想定しているが、今やアプリケーションは、社内の、あるいは他社さえも含む、多様な部分からさまざまなサービスやプログラムを連結して構成されており、そのような環境ではまったく非現実的である。

最新アプリケーションのクライアント側だけに着目してみよう。アプリケーションは一連の異なる「クライアント」デバイス上で動作する多様なUIをサポートしなければならない。例えばPC、ノートPC、タブレット端末、スマートフォン、キオスク端末、自動車のダッシュボード、GPS、メディア・プレーヤがあり、枚挙にいとまがない。同時に、これらのアプリケーションは、ソーシャル・コンピューティング・サイト、ビジネス・パートナーのアプリケーション、メディア企業サイト、事業部門内のITが提供するマッシュアップといった他システムからのアクセスに応じるよう頻繁に呼び出しを受ける (図2参照)。このようなコンテキストにおいて、単一のクライアント・プログラムがアプリケーションのビジネス・ロジックを呼び出すという概念は、明らかに古い。

図2 多様なクライアント・デバイスとプログラムをサポートするアプリケーション
図2
出典:ガートナー (2012年9月)

一般的なアプリケーションのバックエンドも変化している (図3参照)。最新アプリケーションは、複数のデータ・ソースをサポートする必要があり、それらのすべてが社内の、または他社さえも含めた、各所で制御されている場合がある。さらに、それらのすべてが、以下のように異なるセマンティクスや、データ・ストレージとデータ・アクセスの異なったメカニズムを示すことになる。
    ● リレーショナル・データベース

    ● XML文書とサービス

    ● NoSQLとビッグ・データ

    ● フィードやその他のイベント・ソース

    ● その他のアプリケーション
図3 各所で所有/管理される多様なデータ・ソースへのアクセスを管理するアプリケーション
図3
出典:ガートナー (2012年9月)

ガートナーのInformation Capabilities Framework (ICF) は、上述した要件に対処するために企業が提供すべき機能を示す概念モデルである (「Operationalizing the Information Capabilities Framework」参照)。通常の3層アーキテクチャ図に見られるような、アプリケーションのビジネス・ロジックとデータ管理機能の関係の単純な表現では、アプリケーションのデータ・アクセスの側面を説明できるだけの詳細を提供できないことは明らかである。代わりに、企業のICF実装に必要なさまざまな機能を的確に理解できる図が必要である (図4参照)。

図4 ガートナーのICF
図4(クリックすると拡大)
出典:ガートナー (2012年9月)

ここまでに、アプリケーションにはアプリケーション・アクセスとデータ管理の双方にさまざまな側面があることを見てきた。しかし、これで終わりではない。多くの新しいアプリケーションでは、ビジネス・ロジックが1つまたは複数のコンポジット・サービスで構成され、こうしたサービスは複数の下位サービスに依存してビジネス・ロジックを実行する。それらのさまざまなサービスは、社内で稼働している場合もあれば、パートナーやサプライヤーが提供するサービスにアクセスしなければならないケースや、クラウド内でホスティングされているケースもある (図5参照)。

図5 最新アプリケーションの多くはパッケージ、パートナーのアプリケーション、クラウド・アプリケーション内のビジネス・ロジックを統合したコンポジションである
図5
出典:ガートナー (2012年9月)

現実世界のアプリケーションの複雑性に関するこうした所見を考慮するならば、結論として言えることは、アプリケーション・アーキテクチャが十分な表現性を備えるためには、多様なクライアント・プログラムやクライアント・デバイスが、多くのビジネス・ロジック・サービスにアクセスし、さらにこうしたサービスが他のビジネス・ロジック・サービスや、さまざまなデータ・アクセス/データ管理サービスにアクセスすることを想定する必要がある (図6参照)。

図6 各種のUI、サービス、データ、ネットワークが組み合わさった多数の事例に対応するアプリケーション・アーキテクチャ
図6
出典:ガートナー (2012年9月)

さらに、これらのデバイス、プログラム、サービス、データ・ソースは、多様なテクノロジとデータ・モデルを使用して実装されている可能性がある (図7参照)。アプリケーション・アーキテクチャは、多数のデバイスやユーザーが多くのサービスにアクセスし、それらのサービスもまた多くのデータ・ソースにアクセスするという概念に明確に対応したものでなければならない。同時に、デバイス、サービス、データ・ソースのいずれも、ほかのものとは異なる場合があることを明確に示すべきである。また、こうしたアプリケーション・アーキテクチャは、デバイス、サービス、データ・ソースの各所有者が異なる場合にも対応できる必要がある (図8参照)。

図7 どのようなデータ・ソース、サービス実装様式、ユーザー・エクスペリエンス・デバイス、ネットワークにも対応するアプリケーション・アーキテクチャ
図7
出典:ガートナー (2012年9月)

図8 デバイス、サービス、データ・ソースには、異なる優先順位やスケジュールを抱えるそれぞれの所有者がいる
図8
出典:ガートナー (2012年9月)

アプリケーションのクライアント、データ・アクセス、ビジネス・ロジックという要素に関するこうした所見を考慮すると、「アプリケーション」という用語の定義を改める必要があることは明らかである。アプリケーションはもはや、ユーザーが望む機能を提供するコードの、結合力や密着力のある集合体として正確に表すことはできない。またアプリケーションが、1つの事業単位や業務部門を代表する単一の開発チームの統制下に完全に置かれていると考えることも、もはや不可能である。

むしろ、アプリケーションをUI、デバイス、プログラム、データ・ストレージとアクセス・メカニズム、ビジネス・ロジックという要素の集合体と捉え、これらのすべてが、社内の、あるいは他社まで含めた、各所の制御下にある可能性を考慮する方が、はるかに正確である。端的に言えば、アプリケーションとは以下のようなものである。
    ● コード、コンテンツ、データ、デバイス、その他の要素の組み合わせによって、ユーザーが必要とする機能的または非機能的な能力を提供するコンポジション

    ● 予定される機能を、予定される利用者に提供するためのインタフェース
アプリケーションに対するこうした見解は、一部のITリーダーにとって目新しいかもしれないが、ビジネス機能を構築し、提供する際のよく知られたパターンである。実際、今日の変換アプリケーションのほとんどは、何らかの種類のコンポジションである。つまり、単一のシームレスなプログラムのように機能を提供していても、多くの個別リソースが統合された、コンポジット・アプリケーション、マルチステップBPMソリューション、マッシュアップのいずれかである (「Going Forward, Most Transformational Applications Will Be Composite Applications」参照)。こうしたコンポジションは、実行系や分析系のエンタプライズ・システムへのアクセスを必要とし、場合によってはクラウド・サービスや、ビジネス・パートナーが提供するサービスにもアクセスできる必要がある (図9参照)。

ITリーダー、技術スタッフ、事業部門のリーダーが、自社のアプリケーションやそれらの構築形態を理解したいと考え、独力で臨んだ場合、ユーザーやクライアント・プログラム/デバイスの多様性、データとコンテンツの拡散、さまざまな中間層サービスの利用が理解の妨げになる。そして、過度に単純化された直線的な3層型のアプローチは、アプリケーションを表現し、理解する上で役に立たない。

図9 複数の異種混在型リソースを統合し、それらのいずれも単独では提供できない機能をもたらす今日のアプリケーション
図9
出典:ガートナー (2012年9月)

アプリケーションの多次元的な描写を通じて、最新アプリケーションを構成するアプリケーション・サービス、テクニカル・サービス、クライアント・プログラム、データ管理サービス間のさまざまな相互関係と依存関係をモデル化できることが、開発者には必要である (図10参照)。この多次元モデルにおいても、結局はコンポジット・アプリケーションのアーキテクチャが過度に単純化されるため、提示する際には、関心を示すマネージャーやスタッフが、図上の個々のノードについてドリルダウンできる設計環境が必要となる。そうすれば、アプリケーションの一部と相対するコンポジット・アプリケーションの一部の相互作用や依存関係について、それらの部分がどこに配置され、誰に制御されているかにかかわらず、検証することができる。

図10 最新コンポジット・アプリケーションの理解と設計のための多次元モデル
図10
出典:ガートナー (2012年9月)

本リサーチノートでは、現代における多くの重要なアプリケーションの完全な多次元性を認識し、説明する必要性、ならびにこうした多次元性の影響をより適切にモデル化し、理解する必要性を解説するにとどめる。今後のリサーチノートでは、こうした現象を示すアプリケーションの実現と発展にITリーダー、アーキテクト、開発者が適切に対処できるよう進化してきたベスト・プラクティスについて検証する予定である。

    推奨リサーチ
    ・ 「Operationalizing the Information Capabilities Framework」
    ・ 「Stepping Up to the Nexus of Forces With Nexus-Enabled Application Architecture」
    ・ 「The Nexus Effect: How Cloud Computing Alters Established Architecture Models」
    ・ 「Going Forward, Most Transformational Applications Will Be Composite Applications」

    (監訳:飯島 公彦)

APP: APP-13-20

※本レポートの無断転載を禁じます。

←INDEXに戻る

 

gartner.com
TOP OF PAGE
Copyright