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

サンプル・リサーチ

デジタル・ビジネスのアプリケーション向け
ソフトウェア・デファインド・アーキテクチャ

アプリケーション (APP) /APP-14-126
Research Note
Y. Natis, R. Altman
掲載日:2015年2月17日/発行日:2014年12月5日

本リサーチ分析レポートのテーマに関心をお持ちの方は、2015年3月9日(月)・10日(火)に開催する 「エンタプライズ・アプリケーション & アーキテクチャ サミット 2015」のページを是非ご覧ください。(イベント終了後も開催実績としてご覧いただけます)


「ソフトウェア・デファインド・アーキテクチャ(ソフトウェアによって定義されたアーキテクチャ)」とは、IT部門がデジタル・ビジネスに向けてWebスケールのアプリケーション・サービスを提供する上で必要となる、画期的で戦略的なアーキテクチャである。


要約


影響

  • ビジネス・ソフトウェア・アーキテクトへの影響:Webスケールのデジタル・ビジネス・ソリューションを支援する上で、アダプティブかつオープンで管理しやすいアプリケーション・アーキテクチャの採用レベルは、「望ましい」から「必須」になる。
  • CIOへの影響:デジタル・ビジネスにおけるソフトウェア・ソリューションの流動的な性質を反映して、硬直的で階層構造のIT部門は、俊敏でソーシャルな組織へと進化しなければならない。
  • ITテクノロジ・プランナーへの影響:サービス仮想化ゲートウェイ・テクノロジは、デジタル・ビジネスのアプリケーション・ソフトウェアにとっての主要なアプリケーション・インフラストラクチャ・コンポーネントとして台頭しており、ITインフラストラクチャのユーザーやベンダーの戦略を変えることになる。

推奨事項

  • デジタル・ビジネス向けソフトウェアに対して管理された俊敏性をもたらすために、サービス指向アーキテクチャ (SOA) とソフトウェア・デファインド・アーキテクチャ (SDA) を採用 する。
  • 各種ソフトウェア設計スキル間の相互依存の拡大を反映するために、統合、SOA、および関連する他のセンター・オブ・エクセレンスを、一体的なデジタル・ビジネス・センター・オブ・エクセレンスへと集約する。
  • 「即席のレガシー」ソフトウェアの作成を中止するために、IT部門全体でアプリケーション・アーキテクチャのスキル、知識、コミュニケーションに投資する。
  • デジタル・ビジネス向けソフトウェア・エンジニアリングの流動的な手法や成果を反映した組織モデルへとIT部門を編成する。オープンソース団体は良い手本となる可能性がある。
  • ビジネスにおける共通の使命と情報資源を伝達するために、IT部門と事業部門のソフトウェア施策全体で、オープン性やソーシャル・コラボレーションを促進する。
  • 多機能なサービス仮想化ゲートウェイの需要をロードマップに反映しているアプリケーション・インフラストラクチャ・ベンダーを優先する。
  • 利用可能なテクノロジ (APIマネージャ、エンタプライズ・サービス・バス[ESB]、サービスとしての統合プラットフォーム[iPaaS]など)を活用してソフトウェア・デファインド・アプリケーション・サービス(SDAS)の実装に着手する一方で、SDASが発展途上であることや、次第に強力で拡張的なサービス仮想化ゲートウェイ・テクノロジが求められることの影響によって整理統合やその他の変化が起こることも想定しておく。



分析

どのような新しいビジネス・アプリケーションも、SOAの設計原則を抜きに設計されるべきではない。一方、浮上するデジタル・ビジネスのニーズや課題を満たす上で、基本的なSOAのサポート(文書化され、カプセル化されたサービス)は不可欠であるが、それだけでは不十分である。ビジネス・アプリケーション・アーキテクトは、サービス設計において俊敏性と制御のバランスを模索しなくてはならない。サービスのネットワークは、無秩序で誰もが自由に利用できても、厳格に制約されていても、Webスケールのサービス品質、俊敏性、説明責任を実現するものではない。インタラクションを行うアプリケーションやサービス(つまりサービス・グラフ)の無制約なネットワークは制御に欠け、一定の複雑性に達すると崩壊し始める。一方、厳格に制御されたサービスのライブラリは、継続的で迅速な革新のための対応力に欠ける。こうした緊張状態を解消するために、高度なSOAパターンが登場しつつある。


旧式のアーキテクチャ・モデルは不十分または時代遅れである

SOAが定着し、クラウド、モバイル、ソーシャル、インフォメーション、モノのインターネット(IoT)向けの施策によってサービスへの需要が高まったために、企業は新たな課題に直面している。現在の実稼働アプリケーションの大半は、新たなビジネスの需要を満たす上で適していない。従来のアプリケーションの多くは、以下のような問題を抱えている。

  • モノリシックな設計
  • リソースの過剰供給と蓄積
  • ステートフルな設計
  • 並列コンピューティングやインメモリ・コンピューティングへのサポートの欠如
  • 密結合
  • 機会追求的なモジュール性とプログラムによるアクセス
  • 1日24時間/週7日の利用向けに設計されていない
  • 非連続的なバージョニング
  • 水平的な拡張性の不備
  • ガバナンス向けの計装の不在
  • 単一チャネルのフロントエンド
  • 足かせとなる複雑性
  • 高コスト
  • プラットフォームやベンダーへのロックイン
  • リアルタイムのトランザクション分析に不向き

上記の課題のいくつかは基本的なSOAによって対処できるが、次第にそれでは不十分になりつつある。デジタル・ビジネスのシナリオで求められる一定レベルの拡張性、信頼性、リアルタイムの即応力、生産性、効率性、迅速な革新のサポート、データ整合性、事業部門によるサービスの管理を確立するためには、アーキテクチャの革新や制約をさらに取り入れる必要がある。


ソフトウェア・デファインド・アーキテクチャ

ソフトウェア・デファインド・アーキテクチャ(SDA)という概念の起源は、あるハードウェア機能に対するソフトウェアのビューを、ハードウェアに結合されたカスタム・インタフェースから切り離そうとするアプローチである。こうしたモデルの第1号は、2008年に紹介されたソフトウェア・デファインド・ネットワーク(SDN)(根拠1参照)であり、続いて2012年にソフトウェア・デファインド・データセンター(SDDC)(根拠2参照)が、さらに2013年にはソフトウェア・デファインド・ストレージ(SDS)(根拠3参照)が登場した。比較的最近では、ソフトウェア・デファインド・セキュリティ・パラメータ(根拠4参照)や、ソフトウェア・デファインド広域ネットワーク(根拠5参照)の導入が見られた。このモデルは、これまでにさまざまな具現化と多くの実稼働展開を通じて十分に実証されており、そのほとんどはハードウェアの仮想化に使用されている。

こうしたSDAの施策に共通するテーマは、物理的に結び付けられたAPIを、ハードウェアから切り離された仮想APIに置き換えることにより、任意のリソース(データセンター、ストレージなど)の物理的な実装を仮想化することである(図1参照)。仮想APIを公開し、それをハードウェアAPIに変換する中間のソフトウェア・レイヤを設ける。このアプローチからすぐに得られる利点は、ハードウェア・サービスを利用するアプリケーションが、ハードウェアの保守周期、場所、さらには内部設計にさえ依存しなくなることである。これは出発点として有益であるが、得られる利点はそれだけではない。ひとたびこの中間層を設ければ、その後は時間とともにセキュリティ、管理、モニタリング、アナリティクス、コンテキストの組み込み、各種の最適化などの付加価値を加えて、充実させることができる。




図1  ソフトウェア・デファインド・アーキテクチャ



出典:ガートナー (2014年8月)
*図をクリックすると拡大表示します。



SDAモデルをさらに進めて、機能とその利用者の間に中間仮想化レイヤを置き、それによって制御ならびに最適化と充実化の機会をもたらすことができれば、問題の機能がハードウェアに結び付けられず、それ自体がソフトウェア内に定義されているときのように便利である。

デジタル・ビジネスの需要をサポートするために拡大しつつも、一貫した制御を欠く大規模なSOA環境は、非生産的なレベルの複雑さに達する危険がある。SDAモデルは、SOAベースのアプリケーション環境に制御と最適化を組み込むことができる一方で、ビジネス・オペレーションや基盤となるソフトウェア自体に及ぼす混乱は最小限で済む。


アプリケーション・サービス向けSDA

アプリケーション・サービスにSDAモデルを適用すると、アプリケーション・サービスのインタフェースが仮想化される。これにより、内部のアプリケーション・サービスと外部の仮想サービス表現の間に仲介のレベルが導入される (図2参照)。




図2  ソフトウェア・デファインド・アプリケーション・サービス向けSDA



出典:ガートナー (2014年8月)
*図をクリックすると拡大表示します。



ソフトウェア・デファインド・アプリケーション・サービス(SDAS)モデルを使用することで、アプリケーション・アーキテクトは、SOA環境を以下のような複数のレイヤに分割できる。

  • 内部サービスは、内部利用向けに設計され、あるアプリケーションの内的ライフサイクル向けに最適化されている。(仮想外部サービスとは対照的に)これらのサービスは「外部世界」から直接アクセスされることを意図していない。
  • 外部向け仮想サービスは、ユーザー向けのモバイル・アプリや他のアプリケーション、IoTにおける「モノ」、外部サービスといった「外部世界」に対して可視化されている。これらは、アプリケーション・サービスの外部ユーザーの要件に対処するように設計されている。サービスの外部ユースケースの数が増えるにつれて、新しい、または改良された仮想APIの需要が拡大するが、SDASでは、アプリケーションの内部アーキテクチャが境界の外側における継続的な革新によって極度の破壊的な影響を受けないようになっている。全サービスが潜在的に対内的であり、かつ対外的でもある基本的なSOAとは、この点が対照的である。

    内部と外部の両方からのアクセスを対象としたサービスは、仮想クローンを、つまりゲートウェイに管理される別のAPIを持つことになる。したがって、別々に管理される2つのAPI(1つは内部向け、もう1つは外部アクセス向け) が実際に存在する。
  • 企業は、外部世界からのアクセス・トラフィックのみを制御したいか、内部サービスのインタラクションも制御したいかを判断する必要がある。制御範囲にアプリケーションの内部サービスAPIが含まれる場合、内部サービスのインタラクションはすべて仮想ゲートウェイを経由しなくてはならない。制御範囲が外部とのインタラクションのみである場合、内部アプリケーション・サービスはお互いを直接呼び出すことができる。これによって若干のオーバーヘッドと制約が排除されるが、企業には内部アプリケーション・サービスのインタラクションを統制するメリットが得られない。場合によっては、内部インタラクションと外部アクセスが、異なるゲートウェイ・テクノロジで統制されることもある。
  • 中間のサービス仮想化ゲートウェイ・ソフトウェアは、仮想外部APIを内部向けのサービス呼び出しに変換し、外部呼び出しのトラフィックを管理する。ソフトウェア・デファインド・サービス向けのサービス仮想化ゲートウェイの役割を果たすテクノロジは、このプロセスに以下のような多様な付加価値を提供しなければならない。
    • 粒度の細かいセキュリティの実施
    • コンプライアンスまたは不正検出のための分析機能を持つモニタリング
    • コンテキスト認識
    • (利用状況の) 追跡と請求
    • 各種パフォーマンスおよび効率性の最適化(キャッシングやアダプティブなロード・バランシング)
    • 経路指定
    • スケジューリング
    • コンポジション
    • オーケストレーション
    • 統合
    • 管理された仮想APIのアドホック開発

サービス利用者が独自の仮想APIを設計できることは、サービス仮想化ゲートウェイにおける特に強力な潜在的特性である。こうした機能の一部は、概して限定的ではあるものの、今日のAPIマネージャ、ESB、ビジネス・プロセス管理スイート (BPMS) ツールに認めることができる。

ソフトウェア・デファインド・サービスは、既存のSOA環境に導入しても目立たないであろう。なぜなら、内部サービスは変わる必要がなく、影響を受けることもない。また新しい外部サービス(仮想API)は、外部の呼び出し側も変化して影響を受けなくてもよいように、当初は内部サービスを単に模造する。ただし、そこにはゲートウェイ・レイヤが存在し、サービス呼び出しトラフィックの (従来はまばらに行われていた) 制御と最適化を行う (図3参照)。




図3  SDAS向けのサービス仮想化ゲートウェイ



出典:ガートナー (2014年8月)



SDASでは、これまでと何が同じで、何が違うか

仮想サービスの基本的な概念や、付加価値のための中間層の活用は新しいことではなく、これまでにも以下のような例がある。

  • 1990年代に、SOA化を目指すレガシー・システムでの採用やアプリケーションの統合促進のために使用されていた疑似サービスやラッパーは、カスタム製で固定的な内部ソフトウェアに対する仮想の標準化インタフェースといえる。
  • ESBスイート (およびiPaaS) は、統合が必要なアプリケーション間の中間層として機能する。ESBは、中間層(ESB)経由でアクセスされる他のサービスに実装されている機能の仮想表現で あるAPIを公開する。
  • BPMS (およびサービスとしてのビジネス・プロセス管理プラットフォーム[bpmPaaS])は、中間層(この場合はBPMS)によって解釈され、複数のアプリケーション・サービスを一続きの呼び出しシーケンスに変換されたAPIを公開する。
  • SOAガバナンスおよびAPI管理ツールは通常、サービス呼び出しを監視するランタイム・コンポーネントを搭載することで、SOA呼び出しのトラフィックを追跡し、一定のポリシーを適用させ、モバイルや他のアプリケーションとバックエンド・ソフトウェアAPI間のインタラクションを促進する。

上記や他の定番のソフトウェア・パターンおよびツールはいずれも、何らかのサービス仮想化(SDAやSDASの中核)を実装しているが、十分に定義された狭い範囲の対象のみをターゲットとしており、アプリケーション・サービスの仲介や仮想化を、アーキテクチャの一般的なモデルとして捉えてはいない。サービス仮想化は、ESBではアプリケーション統合の必要がある場合に適用され、BPMSではプロセス・モデリングの必要がある場合に適用される。またAPIマネージャは、主として、モバイルや他のユーザー向けアプリケーションがサービスを発見しやすくすることを目的としている。

最も重要なこととして、ESB、iPaaS、BPMS、APIマネージャでは、これらの中間層からアクセスされるサービスが、他の外部呼び出しからも直接アクセスされることを排除していない。したがって、サービスの完全なセットを提供しようとはしていない。対照的に、サービス仮想化ゲートウェイは、サービスへの外部からのアクセスを実現する排他的な手段となる(ただしそれは、現実的には個々のIT環境でSDASを実装する際の原則による)。

こうしたツールのいくつかを組み合わせて拡張し、多機能サービス仮想化ゲートウェイとして、より汎用的に機能させることができる。実際にIBM、Dell Boomi、MuleSoft、Tibco、WSO2、Red HatといったさまざまなESBやiPaaSベンダーが最近、API管理機能によってポートフォリオを拡大している。

それでも、ソフトウェア・デファインド・モデルが中心的な設計モデルとして企業に導入されなければ、どのツールも、どれほど有能でもSDASの広範なメリットをもたらすことはできない。これまでも常にそうであったように、アーキテクチャはツールから始まるものではない。管理された形でSOA環境をWebスケールへ拡大できるようにするという一般的な目的のために、アプリケーションやアプリケーション・サービスを仮想化しようとする原則は、利用可能なツールの能力にかかわりなく、多くのIT部門にとって文化的かつ技術的な課題である。




図4  ソフトウェア・デファインド・アプリケーション・サービスの影響と主要推奨事項



出典:ガートナー (2014年8月)
*表をクリックすると拡大表示します。



影響と推奨事項

ビジネス・ソフトウェア・アーキテクトへの影響:Webスケールのデジタル・ビジネス・ソリューションを支援する上で、アダプティブかつオープンで管理しやすいアプリケーション・アーキテクチャの採用レベルは、「望ましい」から「必須」になる

デジタル・ビジネスは、リアルタイムの状況認識、継続的で迅速な革新、運用規模の拡大、ITソリューションへの容易なアクセスを要することから、弾力的かつアダプティブで俊敏なソフトウェアを必要とする。(数十年前から先進的なIT部門の特徴とされている)オープンでアダプティブなアプリケーション・アーキテクチャは、ビジネスの成長にとって不可欠になりつつあり、IT部門がビジネス革新の実現因子としての役割を果たす上で確かに不可欠である。しかし、オープン性と俊敏性は制御の喪失につながりかねない。デジタル・ビジネス向けのアプリケーション・アーキテクチャに秀でるには、革新と規範のバランスが求められる。

デジタル・ビジネスの需要の急激な台頭やクラウド・サービスに対する事業部門の熱意の高まりに直面して、採用や革新の遅いIT部門は、自社のビジネスにおける役割や影響力が危機的に後退することになる。


推奨事項:
  • デジタル・ビジネス向けソフトウェアに対して管理された俊敏性をもたらすために、SOAとSDAを採用する。
  • 各種ソフトウェア設計スキル間の相互依存の拡大を反映するために、統合、SOA、および関連する他のセンター・オブ・エクセレンスを、一体的なデジタル・ビジネス・センター・オブ・エクセレンスへと集約する。
  • 「即席のレガシー」ソフトウェアの作成を中止するために、IT部門全体でアプリケーション・アーキテクチャのスキル、知識、コミュニケーションに投資する。

CIOへの影響:デジタル・ビジネスにおけるソフトウェア・ソリューションの流動的な性質を反映して、硬直的で階層構造のIT部門は、俊敏でソーシャルな組織へと進化しなければならない

硬直的な組織は、硬直的なソフトウェアを生む。俊敏なIT部門だけが、俊敏なソフトウェアを一貫して開発することができる。単にSDASツールに投資したり、ソフトウェア開発者向けのアーキテクチャ・ガイドラインを策定したりするだけでは、持続的な即応性を備え、継続的に革新するソフトウェア環境を構築することはできない。文化的な変革は重要であり、組織の文化は、そのポリシーや進め方に、また組織自体の構造に反映される。

IT部門の硬直的な階層構造は、革新を遅らせるか、場合によっては妨げかねない。分断されたチームが張り合い、協力を避け、「自前主義症候群」を実践することで独立性を模索するからである。硬直的な階層的組織は、デジタル・ビジネスというコンテキストから生じるニーズや機会の流動的な変化に応えられるよう設計されていないため、まとまりのない、矛盾をはらんだソリューションを生む恐れがある。階層的な組織では、チーム間を調整し、前述のような望ましくない結果を避けるために多くの労力が投入されるが、硬直的な階層構造に固有の性質が完全に排除されることはない。ソーシャルで開放的な構造の新しいIT部門(おそらくオープンソース・プロジェクトのベスト・プラクティスを模範とする)は、この課題への戦略的な答えとなり得る。

従来のアプリケーション環境において、サービスはアプリケーションに属する(またはアプリケーション間のコンポジションである)。しかし、SDASの仮想サービスによって、アプリケーションの境界は消滅する(図3参照)。硬直的な階層構造のIT部門は、こうしたオープンなアーキテクチャにあまり適さないため、デジタル・ビジネスで求められ、SDAが実現するオープン性、即応性、俊敏性のレベルを有機的に採用する際には障壁となる。


推奨事項:
  • デジタル・ビジネス向けソフトウェア・エンジニアリングの俊敏でアダプティブな手法や成果を反映した組織モデルへとIT部門を編成する。オープンソース団体は良い手本となる可能性がある。
  • ビジネスにおける共通の使命と情報資源を伝達するために、IT部門と事業部門のソフトウェア施策全体で、オープン性やソーシャル・コラボレーションを促進する。

ITテクノロジ・プランナーへの影響:サービス仮想化ゲートウェイ・テクノロジは、デジタル・ビジネスのアプリケーション・ソフトウェアにとっての主要なアプリケーション・インフラストラクチャ・コンポーネ ントとして台頭しており、ITインフラストラクチャのユーザーやベンダーの戦略を変えることになる

あらゆるビジネスは次第にデジタル・ビジネスになり、したがって、あらゆるビジネスにおいてWebスケールのITオペレーションが必要になる。つまり、効率的な拡張性、俊敏性、即応性、継続的な革新へのサポートが求められ、さらにそれらのすべてについて、確固たるセキュリティ、データ・プライバシー、トランザクションの整合性、サービスの高度な技術的品質が求められる。SDA仮想化モデルは、こうした環境にとって基盤の青写真となるが、社内開発だけでこうした目標を達成できる企業はほとんど存在せず、またそうすべきでもない。

IT部門は、SDASオペレーションを促進するための支援をアプリケーション・インフラストラクチャ・プロバイダーに頼る。やがて、それは戦略的なサービス仮想化ゲートウェイへの投資を求めることになる。既に今日、複数のプラットフォーム・テクノロジがこうしたゲートウェイの役割を部分的に果たしている。統合、ビジネス・プロセス管理、API/SOA管理製品はすべて、仮想APIを公開しており、仮想の対外的なアプリケーション・サービス・インタフェースと、内部的に実装されたアプリケーション・サービス・インタフェースとの間でマッピングを促進するために変換やその他のロジックを適用する。今日、これらのプラットフォーム製品は、それぞれの特殊性に制約を受けており、サービス仮想化ゲートウェイのアーキテクチャが担う広範な役割を意図して設計されてはいない。SDASの概念が定着するに従って、ベンダーは、サービス仮想化ゲートウェイのSDAS対応市場で競合するために、(買収、パートナーシップ、社内開発を通じて)自社オファリングを拡張すると考えられる。

サービス仮想化ゲートウェイは論理的な構造であり、現実世界においては、複数の製品で構築されるか、複数ゲートウェイの連携であるか、あるいは分散された多層の統合的オファリングである。それは、ソフトウェア、クラウド・サービス、またはハイブリッドの形態で提供される。Webスケールの展開では、このゲートウェイにWebスケールの機能と内部アーキテクチャを必要とする。

ユーザーは、API管理、SOAガバナンス、サービス・レベルのセキュリティ、サービス・アドミニストレーションの機能や、プロセス最適化、オーケストレーション、コンポジション、統合のサポートを提供する統合ソリューションを求めている。先進的なユーザーは、アナリティクス、コンテキストの組み込み、アドホックなAPI設計、アダプティブなロード・バランシング、統制された請求処理の機会も模索している。すべての機能を単一プラットフォームにまとめようとするベンダーもあれば、階層化されたゲートウェイを組み込むことで専用プラットフォームの独立性を維持し、統一的な制御レイヤを追加しようとするベンダーもある。サービス仮想化ゲートウェイ構築のベスト・プラクティスは、いまだ確立されていない。

ベンダーにとってのチャンスは大きいものであり、それはデジタル・ビジネスの需要に合った、Webスケールの企業運営に向けた次世代の戦略的プラットフォームの確立である。一方で、課題も同様に大きい。既存のベンダーのすべてが成功することはなく、多くの専門ベンダーが整理統合されて、アプリケーション・インフラストラクチャ市場に変革 (ならびにリスク) の時期をもたらすことになる。


推奨事項:
  • 多機能なサービス仮想化ゲートウェイへの需要をロードマップに反映しているアプリケーション・インフラストラクチャ・ベンダーを優先する。
  • 利用可能なテクノロジ (APIマネージャ、ESB、iPaaSなど) を活用してSDASの実装に着手する一方で、SDASが発展途上であることや、次第に強力で拡張的なサービス仮想化ゲートウェイ・テクノロジが求められることの影響によって整理統合やその他の変化が起こることも想 定しておく。

執筆協力:Anne Thomas、Massimo Pezzini、Gary Olliffe



推奨リサーチ

  • 「Support the Nexus of Forces and Digital Business With Application Architecture Innovations」
  • 「Stepping Up to the Nexus of Forces With Nexus-Enabled Application Architecture」
  • 「力の結節の影響:既存のアーキテクチャ・モデルをいかに変えるか」
    (APP-13-21、2013年2月5日付)
  • 「Transform Your Business With the Nexus of Forces」
  • 「Service-Oriented Architecture」
  • 「'Service Oriented' Architectures, Part 1」
  • 「'Service Oriented' Architectures, Part 2」

根拠
  1. http://en.wikipedia.org/wiki/Software-defined_networking
  2. http://en.wikipedia.org/wiki/Software-defined_data_center
  3. http://en.wikipedia.org/wiki/Software-defined_storage 、
    およびS. Robinson著『Software-defined storage: The reality beneath the hype 』
    ( http://www.computerweekly.com/opinion/Software-defined-storage-Thereality- beneath-the-hype )
    (ComputerWeekly.com、2013年3月12日付)
  4. http://en.wikipedia.org/wiki/Software_Defined_Perimeter
  5. 『Software-Defined Wide Area Network (SD-WAN)』
    ( http://opennetworkingusergroup.com/onug-spring- 2014-use-cases/software-defined-wide-area-network-sd-wan/ )


(監訳:飯島 公彦)



APP: APP-14-126 (G00264171)
※本レポートの無断転載を禁じます。


←INDEXに戻る

 

gartner.com
TOP OF PAGE
Copyright