リッチなユーザー・エクスペリエンスをサポートする SoE エコシステムの設計

SoE (Systems of Engagement: 人と関わりあうシステム): クラウドの新たな時代

コンシューマーのコンテキストとビジネスのコンテキストの両方において、Systems of Engagement (人と関わりあうシステム: SoE) が次第に重要な役割を果たすようになってきています。ユーザーは、十分な情報に基づいた意思決定およびそれに基づいた行動を迅速に行えるように、多種多様な構造化および非構造化データ・ソースから情報を収集して分析するというリッチなエクスペリエンスを求めています。SoE をサポートするプラットフォームとなるのは、クラウド運用環境です。この記事では、SoE エコシステムの設計手法を紹介します。

Fabio Castiglioni, Client Technical Advisor, IBM

Fabio Castiglioni photoFabio Castiglioni はイタリアの IBM Sales and Distribution の Executive IT Architect です。彼は開発研究所に 13 年間在籍し、国際的プロジェクトの技術職や管理職をしてきました。1995年、彼はオブジェクト指向技術の研究プロジェクトの Technical Director に指名されました。1998年、彼は大規模な政府プロジェクトに IGS Senior IT Architect として従事しました。彼は IBM アーキテクトのためのコンポーネント・モデリング・クラスの講師の 1 人であり、非機能要件に関する何本かの記事を発表しています。


developerWorks 貢献著者レベル

Michele Crudele, Software Engineer, IBM

Michele Crudele は、IBM Cloud & Smarter Infrastructure のソフトウェア・アーキテクトでローマに在住しています。彼は 22 年に及ぶ IT の経験の大半をシステム管理の製品およびソリューションの開発に注いできており、変更構成管理、監視及び可用性管理、IBM オートノミック・コンピューティング・テクノロジー、出版業界向けデジタル資産管理など、さまざまな分野に携わったことによる広範な技術の経験があります。現在は、次世代クラウド・コンピューティング・アーキテクチャーにフォーカスしています。



2013年 11月 21日

さまざまな構造化および非構造化データ・ソース、ソーシャル・チャネル、そして他の同様のコンシューマーから情報を入手して活用するという、リッチなエクスペリエンスを求めるオンライン・コンシューマーが増え続けています。これらの情報からすぐに価値を引き出すことで、個人の目的を満たすことも、十分な情報に基づいて選択することも可能になります。この類のエクスペリエンスは、コンシューマーの間ではすでに一般的なものとなっていますが、ビジネス・アプリケーションでも一般に期待されるようになってきています。Systems of Engagement (人と関わりあうシステム: SoE) では、このリッチなエクスペリエンスを実現するために、複数のチャネルから提供される情報から価値を引き出し、デジタル化された新しいビジネス・モデルを使用できるようにします。この SoE のワークロードをサポートするプラットフォームである CloudOE (Cloud Operating Environment: クラウド運用環境) では、SoE アプリケーションを開発、デプロイ、運用するエコシステムを提供することにより、SoE が必要とするアジリティーと速さを実現します。

SoE エコシステムを設計する作業は新しいタイプの取り組みであり、ユース・ケースなどの従来の分析手法では制限が多すぎて、SoE モデルの基礎となる意思決定を表現しきれません。この記事では、従来の分析手法の代わりとなる手法を紹介し、その手法によって設計プロセスがどのように変わるのかを説明します。そのなかで、観光業界の例を用いて、関連する設計概念と開発フローについて説明します。

人との関わりあいに基づくプロセスとシステム

人との関わりあいに基づくプロセスがすでに主流になっている業界はいくつかあります。その他の業界でも、次第にその重要性は高まってきています。以下に、いくつかの例を挙げます。

  • 旅行の計画: インターネットを利用した旅行の計画は、人との関わりあいに基づく最も成熟したオンライン市場です。価格比較エンジンにアクセスしたり、トリップ・アドバイザーなどの口コミ・システムを参考にしたりすることや、コンテキストに応じたデータ (Google マップの写真や Weather Channel の気象情報など) を表示したり、ソーシャル・ネットワークで専門家グループを見つけて情報を交換したりすることは、デジタル世代の旅行者にとって一般的な行動です。
  • 財務相談: 銀行が、単に金融業務を行うためのカウンターを設けるだけではなく、家計のカウンセラーとしてクライアントと継続的かつ安定した個人対個人の関係を持つようになってから、かなりの時間が経っています。このような関係には、常に最新の知識と、カウンセラーとクライアントとの間の信頼が必要です。
  • 新しい個人向けの福祉計画: 予算の削減、そして経済的圧力が増すなか、一部の政府では、助成金という手段で社会不安をなくすことから、市民を生産サイクルに再び参加させる個人向けプログラムで社会的成果を挙げることに焦点を移しています。この手法では、それぞれの個人の状況に応じて最も成功する可能性の高い福祉計画を明らかにするために、機関全体のコラボレーション、公的情報源と民間情報源からの市民に関するデータの統合、そして構造化データと非構造化データの相関が必要になります。
  • 不正行為の調査: 世界的規模の電子市場では、新しい形の不正行為が出現するようになり、その複雑さは新たな域に達しています。そのような不正行為を調査するためには、通常は明らかに相互関係のないさまざまなソースからの大量の構造化データと非構造化データを分析および比較しなければなりません。このシナリオを可能にする鍵は、時間に関するデータとそのデータの地理位置情報、そして組織間でのコラボレーションです。
  • 位置情報の認識に基づくコンテキスト・ベースのショッピング: 個人のモバイル端末の地理位置情報を利用した位置情報の認識は、新しい小売のシナリオを可能にします。そのシナリオとは、検索エンジンにおける利用者のナビゲーション履歴に基づく「コンテキストに応じた」広告という、インターネットですでに一般的となっているエクスペリエンスを拡張するものです。

SoE のサポートは、多くの業界に新しい可能性を開くことになります。このシステムでは、これまでは人間対人間のやり取りでしか実現できなかったリッチなエクスペリエンスをユーザーに提供することができます。実際のところ、人との関わりあいではもともと人間が中心となります。System of Records (基幹システム: SoR) では、レコードを中心としたプロセスにより、データ登録シーケンスを通じてユーザーの進捗状況を追跡しますが、それとは対照的に SoE が目指すのは、ユーザーにとって意味のある目的を実現することです。


SoE エコシステム

Systems of Engagement (人と関わりあうシステム: SoE) という言葉は、コンサルタントである Geoffrey Moore 氏が 2011年のホワイト・ペーパーで紹介したものです。この言葉が意味するのは、「コンシューマーの間で使われていたものを応用して作られた次世代の IT アプリケーションおよびインフラストラクチャーを使用して、ビジネスの境界、世界の時差、そして言語や文化の壁を超えたコミュニケーションおよびコラボレーションを行えるように、企業の中枢を後押しすること」を主眼とするシステムです。

基本的に、SoE はモバイル・サービス、ソーシャル・サービス、クラウドの公衆サービス、そして従来の IT システム (SoR) のデータに予測分析を適用することで、顧客、パートナー、従業員の日常生活のコンテキストで直接アプリケーションや洗練された製品を提供します。

図 1 に、SoE エコシステムを図解します。

図 1. SoE エコシステム
SoE エコシステムの図。SoE は、モバイル端末およびセンサー、ソーシャル・チャネル、公衆サービス、SoR から収集したデータを使用して予測分析を行い、ユーザーに推奨事項を提供します。

SoE には以下の特徴があります。

  • コラボレーションの実現: SoE は人間を対象にしたシステムであり、人間同士のコラボレーションを前提とします。それとは対照的に、SoR の主な関心事は、特定のプロセスに関するユーザー (人間) とシステム (マシン) との間のやり取りです。人との関わりあいにおいては、人間対人間のやり取りと人間対マシンのやり取りは対等であり、全体的なコラボレーションの一環です。
  • 複数のソースからの豊富なデータの活用: SoE は、ビッグ・データなしでは成り立ちません。各種のデータ・ソースを分析して有用かつ実用的な情報を抽出することが人間の論理的思考の中核であり、それが SoE の中核でもあります。
  • アイデンティティーおよび趣向への適応: IT 専門家としての役割を果たすときの行動と趣向は、学校で子供の親としての役割を果たすときとは異なります (ただし、いくつかの点では、この 2 つのアイデンティティーは互いに影響し合います)。それにも関わらず、一部の SoR では、すべての役割で共通する ID、アドレス、政府の ID 番号などが使用されています。SoE の場合、そういうわけには行きません。SoE では期待されるリッチなエクスペリエンスを提供するために、ユーザーの仕事、趣向、および履歴 (要するに、ユーザーのコンテキスト) を考慮する必要があります。実際的な観点からは、SoE ではオンザフライのデータ・アナリティクスを多用するか、ユーザーに関する複合情報を維持して絶えず拡充するマスター・データ管理 (MDM) システムを使用する必要があります。
  • 時間および位置情報の認識: リッチなユーザー・エクスペリエンスで考慮しなければならないのは、私たちは時間の流れのなかで生活していること、そして一定の場所にとどまってはいないことです。ユーザーが翌週の旅行で訪れるビーチの晴天の写真を受け取っても、その週のビーチは熱帯暴風雨になることが予想されているとしたら、そのユーザーとの関わりあいとしては望ましいサービスではありません (最新の予約 SoR で提供されるサービスのレベルは、この程度です)。ユーザーが関わりあいを持ったまま、あちこち移動しているときには、モバイル端末によってさらに充実したやり取りができる可能性が広がります。
  • 複数の方法でのやり取りのサポート: モバイル端末の場合、関わりあいのロジックにユーザーの位置情報を含めることができるため、最もリッチな顧客エクスペリエンスを実現する可能性があります。ただし、関わりあいのタイプによっては、位置情報を認識する必要がなく、普通の PC で利用したほうが効果的な場合もあります。これら以外のタイプの関わりあいでは、モバイル端末や PC 以外の機器 (キオスク、さらには ATM など) も活躍します。
  • 適切なセキュリティーおよびプラバシーの確保: SoE では、ユーザーに関する大量の情報を扱うため、これらの情報を保護しなければなりません。誰がどの情報を入手できるかを、ユーザーが制御できるようにする必要があります。ただし、公開されるデータが少なければ、その分ユーザーが受けるサービスも限られてきます。それは、ユーザーの個人的な関心に応じて情報とサービスをカスタマイズすることが、このシステムの主な機能であるためです (この点に関しては、SoR では振る舞いの違いをユーザー・クラスやユーザー・プロファイルへと落とし込めるため、SoE に比べると大幅に要件が軽減されます)。

クラウド運用環境: SoE を支えるテクノロジー

SoR とは異なり、SoE は、一定しないリソース要件と計画外の予測不可能なキャパシティーのニーズに対処できるように設計しなければなりません。その上、市場で SoE を差別化し、収益を増やすには、使用可能なデータからクライアントがより深い洞察を素早く得られるようにする必要があります。これらの理由から、SoE にはアプリケーションのデプロイメント、管理、スケーリングを容易にするプラットフォームが必要です。そのようなプラットフォームであれば、開発者は、アプリケーションをホストするために必要なインフラストラクチャーに専念するのではなく、アプリケーション自体の開発と運用に専念することができます。

IaaS (Infrastructure as a Service) クラウドは、事実上サイズに制限のないデータ・センターを開発者に提供します。IaaS を利用すれば、前もってハードウェアを購入する必要はなくなりますが、仮想マシンの構成、ミドルウェア・ソフトウェアのインストール、システム・コンポーネントの接続、システムの保守は、相変わらず開発者が行わなければなりません。こうした作業のどれもが、開発者からイノベーションという極めて重要な仕事に取り組むための時間を削ります。開発者が IaaS をベースに DevOps を実装したとしても、運用を構築して管理する作業に時間を費やすことになります。

DevOps

DevOps とは、ソフトウェア・デリバリー・プロセスの時間を短縮することを目標に、開発者チームと運用チームとのコミュニケーション、コラボレーション、一体化がより改善されたものとなることを目的としたソフトウェア方法論のことです。DevOps のプラクティスでは、繰り返し行われる構成と管理のタスクをテンプレート (「レシピ」または「クックブック」と呼ばれます) として記述し、これらのテンプレートを実行するシステムを (Chef などのツールを使用して) 構築して、インフラストラクチャーの管理と保守を自動化します。

クラウドの能力は、IaaS を提供することだけにとどまりません。CloudOE は仮想マシンのデプロイ、構成、接続に対処することができるため、開発者はアプリケーションに専念することができます。また CloudOE は、DevOps プロシージャーを自動化することもできます。これは開発者にとって、NoOps を意味します。CloudOE の成功の鍵は、CloudOE によって第一線に立つ開発者たちがいかに効果的に、いかに短時間でアプリケーションを構築できるようになるかにかかっています。

サービスのカテゴリー

事例研究には、CloudOE プラットフォームは以下の 4 つのカテゴリーのサービスをサポートしなければならないことが示されています。クラウド中心の (またはクラウド固有の) アプリケーション (SoE など) を構築し、運用するには、この 4 つすべてのカテゴリーのサービスが必要です。

  • 開発サービス
  • アプリケーション・サービス
  • インフラストラクチャー・サービス
  • 運用サービス

CloudOE プラットフォームでは、上記の各種サービスを提供するとともに、凝集されたシンプルなクライアント API によってこれらのサービスを容易に使用できるようにする必要があります。1 つのプログラミング言語と 1 つの Web コンテナーをサポートするだけでは不十分です。CloudOE は、さまざまな目的にかなった各種の Web 開発フレームワーク (Grails、Play Framework、Ruby on Rails、Django など)、プログラミング言語 (Java、Ruby、Python、Node.js など)、プログラミング・モデルに対応する必要があります。

コアとなるアプリケーション・サービスのうち、プラットフォームが提供しなければならない必要最小限のサービスは以下のとおりです。

  • リレーショナル・データベース・サービス
  • ドキュメント・ベースの (NoSQL) データベース・サービス (MongoDB など)
  • メッセージング・サービス
  • ストレージ・サービス (OpenStack Object Storage など)

図 2 に、CloudOE プラットフォームが SoE ワークロードをサポートするために提示する必要がある重要なサービスを要約します。

図 2. SoE ワークロードをサポートする重要なサービス
SoE アプリケーションおよび SoE ワークロードをサポートする重要なサービス (開発、アプリケーション、インフラストラクチャー、および運用) を示す図

最も重要なことは、これらのサービスがすべて以下の例のように、流れるような洗練された開発者エクスペリエンスを実現しつつ実行されるようにすることです。

  1. 開発者エクスペリエンスが始まります。
    • CloudOE ポータルから自分のアカウントを作成します。
    • アプリケーションとサービスを管理するためのコマンドライン・ツールをダウンロードします (開発者として、私はコマンドラインを愛用しています)。
    • 自分の好みのプログラミング言語の CloudOE クライアント API をダウンロードします。
    • 自分の好みの IDE 用の CloudOE プラグインもダウンロードすることができます。
  2. これで、私の次の SoE アプリケーションの開発を開始することができます。このアプリケーションに必要なのは、メタデータ用のリレーショナル・データベースと、管理対象とする BLOB オブジェクト (写真、グラフィック、記事など) を保存するためのオブジェクト・ストレージ・サービスです。さらに、使用する Web 開発フレームワークのランタイム・サポートも必要になります。
    • ドキュメントを調べると、CloudOE は必要なすべてのものを提供していることがわかりました。
    • コマンドラインまたは IDE プラグインを使用して、データベース・サービスとオブジェクト・ストレージ・サービスを要求します。これらのサービスは、CloudOE によって自動的にインフラストラクチャーにデプロイされます。
    • デプロイされたサービスとのインターフェースを (CloudOE クライアント API を使用して) 取るアプリケーションを作成します。
    • 作成したアプリケーションを (IDE プラグインまたはコマンドラインを使用して) デプロイします。CloudOE によって自動的に、アプリケーションのランタイム環境がプロビジョニングされ、アプリケーションに必要なサービスとの接続が作成されて、アプリケーションにアクセスするための URL が提供されます。
    • 最後にアプリケーションをテストします。

移植性

顧客は、1 つのクラウド・プロバイダーにロックインされたくないものです。したがって、顧客が簡単にワークロードを適応させて別の CloudOE で実行できるようにしなければなりません。理想的な CloudOE アプリケーションは、コードを変更せずに構成のみを変更することで、顧客が所有するハードウェアとミドルウェア・ソフトウェアにデプロイすることができるアプリケーションです。

このように、CloudOE を使用すれば、開発者は従来の環境だと何日もかかる作業を数時間で完了することができます。開発者は、アプリケーションをホストするための Web アプリケーション・サーバーをデプロイする必要も、データベースをデプロイしてストレージを確保する必要もありません。

CloudOE プラットフォームの価値は、そのインフラストラクチャー・サービスと運用サービスによって一層明白になります。これらのサービスが関わってくるのは、主にアプリケーションを開発環境から検証環境へ移すとき、そして最終的に本番環境に移すときです。CloudOE には、アプリケーションをホストするための、複数に分離した環境を構成する機能と、継続的デリバリーと継続的インテグレーションの作業を単純化するツールが備わっていなければなりません。

インフラストラクチャー・サービスの突出した機能は、アプリケーションの水平スケーリングです。つまり、需要が増大したときにはインスタンスを追加し、需要が減少したときにはインスタンスを解放します。運用サービスによって、アプリケーションの管理をサービスとして利用できるようになるため、社内に一連のアプリケーション管理用製品をデプロイして保守する必要がなくなります。理想的な場合には、運用チームは CloudOE ポータルでマウスを数回クリックするだけで、アプリケーション (およびそのアプリケーションのサービス) の定期バックアップを有効にすることができます。また開発者は、サービス・データのスナップショットを取れるため、問題が発生した場合には別の環境でサービス・データをリストアして問題を分析することができます。

実際の CloudOE

この記事で説明している CloudOE は、SF (サイエンス・フィクション) ではありません。CloudOE は急速な勢いで現実になってきています。一部の PaaS (Platform as a Service) クラウド・プロバイダーでは、CloudOE への流れを加速しています。具体的な例としては、Pivotal の Cloud Foundry をはじめとし、Heroku、そして Red Hat の OpenShift などが挙げられます。

IBM が発表した BlueMix は、IBM Open Cloud アーキテクチャーと Cloud Foundry オープンソース PaaS をベースとした次世代クラウド・プラットフォームです。今後 IBM BlueMix は時間とともに成長し、広範な IBM ソフトウェア・ポートフォリオに基づくサービスとランタイムを提供するようになるでしょう。IBM BlueMix では、開発者がモバイル端末の情報、ソーシャル・チャネル、一般公開されているデータを簡単に利用できるように、上位レベルのサービスへのアクセスを可能にする予定です。

Cloud Foundry オープンソース・コミュニティーへの最初の貢献である IBM WebSphere Liberty Buildpack は、BlueMix プロジェクトに参加する顧客がプレビュー用として入手できます。

プラガビリティーと外部システム

顧客が自分たちの SoR を CloudOE プラットフォームに接続し、自分たちの開発組織がサービスとしてその SoR を使用できるようにする、ということができなければ、顧客は (パブリックまたはプライベート) CloudOE を役に立たないものと判断するはずです。強力な CloudOE プラットフォームであるためには、新しいサービスを接続することも、外部システムをサービスとして利用することもできなければなりません。

例えば、Cloud Foundry では、プラットフォーム外部のサービス (既存の SoR など) を開発者に最も迅速に提供する手段として、ユーザーが提供するサービス・インスタンスを導入しました。この機能を使用すると、顧客はパブリック CloudOE を使用することができます。さらに、以下のことも可能になります。

  • クラウド・プロバイダーが提供する VPN サービスを介して、オンプレミス SoR (例えば、顧客レコード・データベース) を接続することができます。
  • ユーザーによって提供されるサービス・インスタンスが顧客レコード・データベース用に作成されます (SoR 所有者はこのフェーズで URL とユーザー・クレデンシャルを提供するとともに、アプリケーションで顧客レコード・データベースを操作するために必要な他のすべての属性を提供します)。
  • 開発者はアプリケーションを開発する際に、顧客レコード・データベース内の既存のクライアント・ライブラリーを使用することができます。データベースに接続するための URL とクレデンシャルは、アプリケーションの環境内で Cloud Foundry から提供されます。

SoE のアクターとアーキテクチャー

SoE は、拡張する目的で設計されるエコシステムであり、SoR とは異なり、「フェンスで囲まれた」完結したエンティティーではありません。SoR は、開始処理、一連のアクション、場合によっては明確に定義された意思決定ポイント、そして終了処理がある、1 つ以上のビジネス・プロセスそのものの実装です。一方、SoE はビジネス・アクター間のコラボレーションをサポートします。コラボレーションを定義するのは、ビジネス・プロセスを定義するより遥かに困難です。しかも、あらゆる人間のエクスペリエンスと同様に、コラボレーションも通常は時間とともに進化していきます。したがって、SoE は進化に対応できなければなりません。つまり、進化にも、複数のアクター間のコラボレーションのサポートにも対応するように設計されたビジネス・プラットフォームとして構築する必要があります。

ここで、IBM Academy of Technology の学長であり、IBM ディスティングイッシュト・エンジニアでもある Rashik Parmar 氏が「Introduction to Disruptive Businesses Platforms」というタイトルの非公開の社内文書で用いている専門用語を使用して、ビジネス・プラットフォームのアクターを定義します (専門用語を強調表示しました)。

このプラットフォームの中心となるのは、「プラットフォーム所有者」「プラットフォーム・プロバイダー」です。一人がこの二役を兼ねることもありますが、複数業界の (つまり業界間共通の) ビジネス・プラットフォームでは、その違いが重要となります。「協業者」は、ビジネス・プラットフォームに付加価値を与え、コンシューマーからの価値獲得に一役買うために存在します。「サプライヤー」は、サービスの強化やコンシューマーへのサービスの提供を直接行わないという点で、協業者とは異なります。サプライヤーは、プラットフォーム・プロバイダーがその責任を果たせるように、ツールや、テクノロジー、リソースをプラットフォーム・プロバイダーに提供します。コンシューマーは、多様性、サービス・レベル、またはコストの低さから、ビジネス・プラットフォームのサービスを購入したい気持ちにさせられます。ビジネス・プラットフォーム全体で今までにない使い方も促進されるため、例えばコンシューマー同士が取引を行うこともできます。

図 3 に、ビジネス・プラットフォームにおけるアクターとその相互関係を示します。

図 3. プラットフォーム・エコシステムのアクター
ビジネス・プラットフォーム・エコシステムで相互作用するアクターとして、エンド・ユーザー、プラットフォーム所有者、プラットフォーム・プロバイダー、協業者、およびサプライヤーを示した図

一例として Apple iPhone/iTunes プラットフォームを取り上げると、Apple は、プラットフォーム所有者兼プラットフォーム・プロバイダーです。iPhone の製造業者である FoxConn は、Apple のサプライヤーとして iPhone をコンシューマーに販売します。さまざまな協業者 (他の会社) がプラットフォーム上で音楽やアプリをコンシューマーに直接販売し、それによってプラットフォームの価値を高めます。

成功するビジネス・プラットフォームには共通して以下の特徴があります。

  • 協業者とプラットフォーム・プロバイダーのエコシステムで、幅広いコンシューマーに共通の問題を解決することができるため、収益を上げられるプラットフォームとなっています。
  • 協業者がプラットフォームを強化するために使用するインターフェースがオープンであり、標準に基づいていることが、エコシステムの信頼を生み出しています。
  • 容易に拡張できるプラットフォームであり、スムーズな進化が可能です。
  • 協業者とコンシューマーの両方により、イノベーションと今までにない使い方が促進されます。
  • 協業者はインターフェースを介して、付加価値を与えることも、価値を得ることもできます。
  • プラットフォームの中核で、他とは換え難いユニークなサービスが提供されます。
  • エコシステムが安定しています。

ビジネス・プラットフォームは本質的に、ビジネス・プラットフォーム・プロバイダーと、コンシューマーの市場にサービスを提供する上で互いにサポートし合う協業者のエコシステムとの組み合わせです。

アーキテクチャーの基本的性質

SoE プラットフォームのアーキテクチャーの基本的性質は、以下のように定義することができます。

  • SoE は、極めて高品質のサービスを必要とするリッチなエクスペリエンスを提供します。これは特に、スループット、スケーラビリティー、信頼性に関して言えることです。SoE では、そのベースにあるインフラストラクチャーを完全に制御できないにも関わらず、非機能要件を確実に満たさなければならないため、アプリケーション・アーキテクトにとって設計するのが非常に難しい環境です (ソフトウェア集約型の複雑なシステムのアーキテクチャー記述に、非機能要件を統合する方法について説明している書籍や記事については、「参考文献」を参照してください)。
  • SoE はビジネス・プラットフォームです。使用可能な機能はいずれも、API を公開し、拡張可能であるか、または別の競合する実装でシャドーイングできなければなりません。これらの実装および拡張は、オープンなカタログで公開する必要があります。協業者は、プラットフォームへのあらゆるレベルでの機能の追加に必要なすべてのツールにアクセス可能でなければなりません。
  • SoE を支える基本テクノロジーはクラウドですが、他にも SoE のベースに必要なテクノロジーとして以下のものがあります。
    • 極めてスケーラブルでハイパフォーマンスのメッセージング・サービス
    • メッセージング・サービスをベースに作成された、外部 SoR 用アダプター (SoR は常に、人との関わりあいによる結果のアクチュエーターとなり、重要な構造化データのソースにもなります)。このようなアダプターには、レガシー・システムとのコネクター、そして人との関わりあいにとって意味のある外部イベントや人との関わりあいのきっかけとなる可能性のある外部イベントのカタログとのコネクターが必要です。
  • SoE データの機密性を考えると、身元識別、承認、プライバシーなどに対処するために、クラウドで実施可能なセキュリティーが必要です。
  • プラットフォームには、ビッグ・データおよびアナリティクスに対処する機能が (おそらく複数の実装とともに) 存在していなければなりません (これには、主要業績評価指標 (KPI) などのプラットフォーム自体の運用に関するデータおよびアナリティクスも含まれます)。ビッグ・データは、相互運用可能にする必要がある複数のソースから提供されるため、何らかの公開メタデータとセマンティック・エンジンも存在していなければなりません。
  • モバイルは SoE の重要な側面です。いつでもどこからでもできるアクセスと、位置情報を認識することによって、人との関わりあいの価値を高めることができます。
  • 意思決定における個人の趣向から協業者のサービスに対する会計規則に至るまで、SoE はルールで溢れています。したがって、ランタイム・エンジン兼公開ルール・リポジトリーとしてのビジネス・ルール管理システムが必要です。
  • SoE は人間との関わりあいに関するシステムであるため、ユーザー・アクセス (ポータル) とソーシャル・ツール (一般向けのツール、またはプラットフォーム固有のツール) が、このソリューションの重要なビルディング・ブロックとなります。

その他の要件

さらに、SoE をサポートするテクノロジーには以下の要件が適用されます。

  • サービス指向ベース: デジタル・エコシステムおよびビジネス・プラットフォームとしての SoE の中心は、サービスです。これらのサービスは軽量であり、REST (Representational State Transfer) アーキテクチャーをベースとします。サービス指向アーキテクチャーをベースとしていない SoE は考えられません。
  • 業界標準ベース: SoE は拡張を前提に構築される、複数のアクターによるプラットフォームです。強力な共通の標準がなければ、成功は望めません。
  • オープンソース・テクノロジーの活用および拡張: 標準に真の相互運用性が備わるようになるまでには、長い学習期間を要します (SOAP を例に挙げると、WS-I プロファイルとの完全な相互運用性を実現するまでに数年かかりました)。そのため IT 業界では、オープンソース・テクノロジーを使用したほうが、堅牢かつ相互運用可能なソリューションをより迅速かつ容易に実現できるという意見で一致しています。
  • インターネット規模でのプロセス・インテグリティー: SoE を構築する際には、構想段階から明示的に強く主張しない限り、データ近接性、保証されたレスポンス、時間当たりのリクエスト数などがインターネットで実現可能なレベルより高いレベルとなることは想定できません。
  • エンタープライズ機能およびバックエンド・システムとの統合: SoR が定着している理由は、意図された目的 (プロセスを記録または実施すること) を確実に果たすためです。このことから、SoE は 1 つまたはもっと多くの (おそらく、もっと多くの) SoR、およびそれらの SoR がインターフェースを持つエンタープライズ機能と統合しなければならない可能性が大いに考えられます。
  • 成長を続けるエコシステム用のプラットフォームの提供: SoE にとって進化することは、SoE に与えられたミッションの本質です。SoE のアーキテクチャーは、互いに接続された特殊用途のコンポーネント間でのやりとりのみで構成されるのではなく、このアーキテクチャーには公開された汎用サブシステムの機能も含まれています。このような設計は、正確さと効率性のみならず、リッチかつオープンであることを目指しています。

SoE の設計

どのタイプのソリューションでも同じですが、SoE ソリューションを設計する際の最初のタスクは、このソリューションに望まれるユーザー・エクスペリエンスの要件を定義することです。ユーザーが SoE に期待するのは、このシステムがモバイル・アクセス、位置情報の認識、コラボレーション、そしてビッグ・データの活用をひとまとめにして利用することにより、人間というアクターが十分な情報に基づいて可能な選択肢を評価し、最良の意思決定を行えるように支援することです。

SoE の極めて重要な側面は、人間の意思決定を効果的にサポートするユーザー・エクスペリエンスの設計です。このエクスペリエンスは、規範的なものにすることも、一定のフローやプロセスを使用したものにすることもできません。単純な視覚的相関から複雑なアナリティクスに至るまで、異なる情報を相互に関連付けられるエクスペリエンスにしなければなりません。このエクスペリエンスにはモバイル端末の小さな画面という制約があるため、音声認識をはじめとするオーディオ・テクノロジーとビデオ・テクノロジーのサポートも必要です。

この記事では、エクスペリエンスの設計に関する詳しい説明はしませんので、SoE のアーキテクチャーに関する他の側面に話題を移します。

前述したように、標準的な SoE は、意思決定プロセスと意思決定自体のアクチュエーターである数々の SoR とインターフェースを取ります。SoR の典型的な要件全体を検討すると (ここでは、旅行支援システムという前提です)、図 4 の例に示すようなユース・ケース・モデルが出来上がります。

図 4. 旅行支援 SoR のユース・ケース・モデルの一例
旅行支援 SoR のユース・ケース図

図 4 のユース・ケース・モデルは、旅行支援 SoR のビジネス・プロセス全体を明確に表しています。そのプロセスとは、以下のとおりです。

  1. 自分の身元を証明します。
  2. チケットを入手するか、無料パスを使用します。
  3. 予約を取り、必要に応じて予約を変更します。

これらのユース・ケースは、最終的なソリューションの主要な機能を明らかにできるだけの細かい粒度にまで分解することができます。また、ユース・ケースを複数の集合にグループ化して、将来的なシステム・コンポーネントの姿を初めて表すこともできます。

今度は人との関わりあいの別の側面として、どの旅行にするのか、そしてその旅行をどのようにして編成するのかを、旅行者がどのように選択するのかを検討します。図 5 に、その意思決定に影響する可能性のある要因を示します。

図 5. 旅行に関する意思決定要因の例
どの旅行にするかの決定に影響することが考えられる、さまざまなタイプの基準を示す図

上記ユース・ケースには、この意思決定プロセスに関する手掛かりはありません。これは、何日も試行錯誤を繰り返す長いプロセスになることもあれば、「映画で見たどこそこの場所に行きたい」という瞬時の決定になることもあります。

この例では、このプロセスそのものよりも以下の事項のほうが、ソリューションの要件としての関連性が高くなります。

  • 検討対象とする情報 (データ・ソースとそれらの間の関係)
  • 意思決定の基準 (個人の趣向を含む)
  • 影響を与える人間および人間以外のもの
  • 時間と場所を含むコンテキスト
  • 関係者間のコラボレーション

要するに、ここで関連してくるのは、一部のモデリング・フレームワーク (TOGAF/ArchiMate など) が「動機付けモデル」と呼んでいる、人との関わりあいの背景となるモデルです。

動機付けの要件が明らかになった後は、以下の観点から人との関わりあいの形を確立することができます。

  • 意思決定に影響を与える情報オブジェクトに基づいて提供するビジネス機能
  • アクター間のコラボレーション
  • ソリューションの SoR の部分を記述するプロセス・エンティティー

図 6 に、SoE の TOGAF/ArchiMate メタモデルを示します。

図 6. SoE の TOGAF/ArchiMate メタモデル
SoE のエンタープライズ・アーキテクチャー・メタモデル

図 6 には以下のことが示されています。

  • SoE の技術インフラストラクチャーは、CloudOE と 1 つ以上の SoR です。
  • SoE ワークロードを実行するプラットフォームは、CloudOE です。
  • サービスはインターフェースによって物理的に実現され、アプリケーションはコンポーネントによって物理的に実現されます。
  • コンポーネントはビジネス・プロセス (またはビジネス・アクティビティー) を実装し、自身のインターフェースを介して他のコンポーネントを使用することも、技術的インターフェースを介して技術的機能を使用することもできます。技術的機能が提供するのは、ほとんどのところ、ミドルウェア製品 (例えば、NoSQL データベース) によって一般に提供される機能です。

例: 「渓谷観光旅行」SoE

これまでに概説した方法論の一例として、アルプスの渓谷の観光旅行を支援および振興するプラットフォームの例を取り上げます。利害関係者の動機付けモデルから、この SoE をサポートするために必要な CloudOE ミドルウェア・サービスの特定までのプロセス全体を、この例に従って説明します。

図 7 に、利害関係者の TOGAF/ArchiMate 動機付けモデルを示します。

図 7. 「渓谷観光旅行」の動機付け
利害関係者の動機付けのアーキテクチャー・モデル

クリックして大きなイメージを見る

図 7. 「渓谷観光旅行」の動機付け

利害関係者の動機付けのアーキテクチャー・モデル

上記のモデルには、主要な利害関係者 (旅行者) の観点と、このドメインのその他の利害関係者の目的が含まれています。その他の利害関係者とは、具体的にはホテル、レストラン、交通機関、イベントなどのサービス・プロバイダー (サプライヤー)、渓谷観光局 (プラットフォーム所有者)、付加価値アプリケーションのプロバイダーおよび外部の世論形成者 (協業者) です。

説明を簡単にするために、このモデルを旅行者が主導する部分と、その他の利害関係者が主導する部分の 2 つに分けます。また、KPI と測定 (非機能要件を含む) はそれ自体で 1 つの記事の主題となるため、この 2 つについての説明も省きます。

旅行者の意思決定は、旅行者自身の関心と趣向、天気予報、そして獲得されるメンバー・ポイントなどといった一連の要因に影響されます。

観光局は、旅行の目的地として渓谷を宣伝します。この観光局の活動は、顧客を渓谷のサービスに魅き付けられるような現地イベントの広告、奨励策、サポートを通して行われます。観光局の主な要件は、これらの活動の結果を知ること、そして (おそらく市場区分別の) 典型的な訪問パターン、自然のスポットの魅力などといった、渓谷ビジネス・システムをより高めるために必要な情報を収集することです。

サービス・プロバイダー (ホテル、レストランなど) は、そのサービスの質と価格を競合相手に引けを取らないレベルにする必要があります。さらに、サービスの提供内容を顧客のニーズと趣向に合わせる必要もあります。これは、付加価値アプリケーションのプロバイダーに共通する要件です (これに加え、自分たちの知的資産が無許可で使用されないように保護する必要もあります)。

モデルの断片

この例を説明するのに役立つように、ここからはこのモデルのなかで、サービスを選択して旅行の計画を立てる「部分」に焦点を絞ります。交通機関やサービスの予約 (従来の SoR との結び付きが強い部分) に関連するトピックのすべてを検討するのではなく、以下の要件をモデリングする過程を追跡します。

  • サービスの情報 (予約状況、価格、スケジュールなど)、現地のイベント、奨励策に関する案内、その他のタイプのプロモーションが含まれるサービス・カタログが必要です。
  • 複数の基準 (価格、評判、信用できる意見) に基づいてサービスを比較し、最適なサービスを選択する必要があります。
  • サービスが提供される場所、サービスが提供される場所から関心がある別の場所への近さ、サービスが提供される場所で行われる特定の 1 回限りのイベントにそのサービスを関連付けられること、などを基準にサービスを選択できるようにしなければなりません。
  • 天気をはじめとするコンテキスト情報を考慮する必要があります (交通もコンテキスト情報の一例です)。
  • 人との関わりあいにおいてユーザーの趣向 (旅行者マスター・データ) を管理する必要があります。

以上の要件が、図 8 のモデルに示されています。

図 8. 「渓谷観光旅行」に参加する旅行者の要件
渓谷観光旅行の例での旅行者の要件

クリックして大きなイメージを見る

図 8. 「渓谷観光旅行」に参加する旅行者の要件

渓谷観光旅行の例での旅行者の要件

これらの要件が、対応するビジネス機能に反映されます。

  • ビジネス・サービス・カタログの管理機能。プラットフォーム・プロバイダーとサービス・プロバイダーは、ホテル、レストラン、イベント、交通機関、その他のサービスに関する情報を最新の状態に維持します。少なくともサービス情報には、そのサービスが提供される時期、スケジュール、そして価格が含まれていなければなりません。サービス・プロバイダーが提供する情報の質が高ければ高いほど、サービスが顧客の好みと一致する可能性が高くなります (例えば、そのホテルが「子連れで泊まりやすい」ことを宣伝すると、小さい子供を連れて旅行する家族の興味を引く可能性が高くなります)。
  • 複数の基準による検索とランキング機能。この機能では、カタログに含まれる情報に加え、サービスの評判、ソーシャル・ネットワークでの評価、奨励プログラム、顧客が持っているポイントなど、サード・パーティーによる情報を使用します。顧客が外部の案内 (広告など) を見たことによって、サービスの比較をしようと決める場合もあります。
  • 顧客が興味のあるサービスおよび自然の見所をオンライン地図で表示できるようにする機能 (これにより、場所と距離を基に予定を決めることができます)、そして顧客が写真と併せて天気や交通などのコンテキスト情報も表示できる機能。
  • 顧客のニーズと関心で構成される複合レコードに情報を入力し、管理する機能 (個人マスター・データ・マネージャー)。このレコードには、過去の購入履歴と旅行履歴だけでなく、信用できる評価の情報源やその他の個人に関する詳細も含まれます (このような極めて機密性の高い情報は、顧客が把握して承認しなければ収集することができません。また、収集された情報は、その顧客だけが使用することになります)。この情報が旅行者にもたらすメリットは大きい上に、情報に匿名性を与えるメカニズムによって、その旅行者以外が全情報にアクセスすることはできないようにすることもできます。

図 9 に、渓谷観光旅行 SoE のビジネス・モデルのうち、旅行者の要件を満たす部分を示します。

図 9. 「渓谷観光旅行」の旅行者ビジネス・モデル
渓谷観光旅行の例での旅行者ビジネス・モデル

これらのビジネス機能は、SoE クラウド環境内の実際のサービスでサポートする必要があります。そして、これらのサービスは、プラットフォーム・プロバイダーまたは協業者が提供する実際のアプリケーション・コンポーネントによって実装される必要があります。例えば、協業者がプラットフォームのカタログ API をベースに「子供連れ用のオファリング」アプリを開発することも考えられます。

サービスとアプリケーションの連動

ここで、起こり得る 1 つのユーザー・エクスペリエンスを例に、サービスとアプリケーションがどのように連動するのかを説明します。渓谷観光旅行 SoE の視覚化マネージャー・アプリケーションは CloudOE 内にある Web アプリケーションであり、旅行者はこの Web アプリケーションをモバイル・アプリ・ストアからダウンロードすることができます。視覚化マネージャーは、他のアプリケーション・コンポーネントと相互作用することで、以下に示す完全な SoE エクスペリエンスを提供します。

  1. 休暇を取って旅行をすることにした私は、アルプスの渓谷を訪れることを考えています。
  2. アプリ・ストアを探してみると、ホテルの予約から交通機関、そして渓谷での過ごし方に関するアドバイスまで、旅行に関するエクスペリエンス全体の簡素化を約束するアプリを見つけたので、このアプリをインストールすることにします。
  3. けれども、このアプリには登録が必要です。さらに別のアカウントとパスワードを増やすなんてありえません!
  4. いや、ちょっと待ってください。「アルプスの渓谷」アプリには Facebook や Twitter からログインできるようになっています。私は Facebook のアカウントを持っているので、そこからログインすることにします。
    • このアプリは、ID およびアクセス・マネージャーに関する CloudOE サービスを使用して、Facebook に認証を任せ、ユーザー・トークンを取得します。
  5. 私は、自分の Facebook の認証情報を入力して、渓谷アプリにログインしました。
  6. このアプリは、地図サービスを使用して渓谷の眺望とともに関わりのある興味深い地点 (周辺の村や登山道などの写真と概要) を示してくれます。
  7. 渓谷に行くことに決めた私は、出発日と滞在期間を入力し、他の選択肢はアプリにお任せにします。
  8. このアプリは、旅行を企画するために以下のサービスを使用します。
    • 気象サービスを照会して、滞在中の気象情報を取得します。
    • 交通機関サービスを照会して、最適な電車とバスを見つけます。
    • ホテル・サービスを照会して、最適な (価格と質のバランスがよくとれた) ホテルを見つけます。
    • 渓谷イベント・サービスを照会して、滞在中のスケジュールを計画します。
  9. 3 つのお勧めプランが提示されました。そのうちの 1 つをそのまま選択することも、1 つの案を選んで多少変更することもできます。
  10. なんと、一番のお勧めプランは他よりも多少値段が高くなっているものの、滞在先のホテルで有名シェフによる料理教室があります。私の妻は料理が上達することには熱心なので (この情報は、SoE アナリティクスによって彼女の Facebook のプロフィールから検出されました)、大喜びするに違いありません。私はこのプランを選択することにして、支払い情報を入力しました。
  11. アプリは支払いサービスを使用して注文を確定させた後、BPM サービスを使用して予約ワークフローを開始します。予約ワークフローもホテル・サービス、交通機関サービス、渓谷イベント・サービスと相互作用して、予約を確定します。
  12. 私は、確認の e-メールを受け取りました。リクエストの状況を追跡するのにも、同じアプリを使用できます。
  13. アプリは MDM サービスを使用して、私が選択した内容を保存します。アプリは、私の (そして他の人の) エクスペリエンスを改善するために、この保存した情報を今後の人との関わりあいの中で活用することになります。例えば、上位 3 つのお勧めプランをより良いものにしたり、興味がありそうなイベントだけを通知したりするために使用されます。

図 10 に、アプリケーションのコンポーネントを示します。

図 10. 「渓谷観光旅行」SoE アプリケーション
SoE 視覚化マネージャー・アプリケーションのコンポーネントを示す図

このアプリケーションの一部のコンポーネントには、テクノロジー・サプライヤーが提供するミドルウェア・サービスが必要です。

図 11 に、この例のコア CloudOE の初期モデルを示します。

図 11. 「渓谷観光旅行」CloudOE
渓谷観光旅行の例での初期クラウド運用環境を示す図
  • サービス・カタログには、検索によって発見されるサービス、イベント、奨励策に関する情報が含まれます。このサービスが最終的にベースとするのは、CloudOE が提供するテキスト検索機能を備えた NoSQL データベースです。
  • サービスの検索、比較、およびコンテキスト分析機能は、大量の構造化および非構造化データの分析をベースとすることから、これらの機能では CloudOE のアナリティクス機能が使用されます。
  • ユーザーの趣向を保管する個人 MDM コンポーネントには、CloudOE 内に対応する MDM 機能が必要です。さらに、旅行者の活動の一般的な傾向と、特定の個人ごとの趣向を両方とも理解するために、販売追跡 SoR とのインターフェースと、旅行者のスマートフォンの GPS インターフェースを使用する位置追跡サービスとのインターフェースも必要になります。
  • ユーザーを認証して機密性の高いユーザー・データへのアクセスを保護するために、ID 管理、アクセス管理、シングル・サインオン (SSO) が使用されます。これは CloudOE の機能であり、この機能では個人 MDM を ID リポジトリーとして使用することができます。
  • アナリティクスのスマートな視覚化 (Google マップなどのアプリケーションを使用した地理的視覚化を含む) には、モバイル・プラットフォームと Web プラットフォームの両方でユーザーのリッチなエクスペリエンスをサポートするためにマルチデバイス対応アプリケーション・サーバーが必要です。
  • ビジネス・プロセス・マネージャー・エンジンは、ビジネス・トランザクションおよび補償マネージャーとして機能して、連動する交通機関予約 SoR および支払い SoR との調整を取る必要があります。
  • 多基準比較エンジンの中心となるのは、ビジネス・ルール管理機能です。ビジネス・ルールを使用することで柔軟性がもたらされ、それにより、リッチな顧客エクスペリエンスをサポートするために必要なコンテキスト・データと人との関わりあいのデータの分析における柔軟性が促進されます。
  • SoE 内部でのメッセージ・フローと、SoE と SoR との間のメッセージ・フローをサポートするには、Web およびモバイル端末を含むインターネット規模のメッセージングに対応可能なメッセージング・サーバーが必要です。

これらのサービスのいくつかは、スケーラビリティーとレジリエンシーに非常に優れたプラットフォームとミドルウェア・ソリューションを提供可能なテクノロジー・サプライヤーによって CloudOE のどこかに提供されます。それらのサービスには、それぞれのサービスの API からリモートでアクセスすることになります。また、CloudOE は外部 SoR (公開 SoR、インターネット上の SoR、または VPN 機能を使用してアクセスしなければならないプライベート・ネットワーク内にある SoR など) とのインターフェースにもなります。これらの 外部 SoR (交通機関エンジン・コンポーネントなど) は旅行に関するユーザーの意思決定を記録し、適切なビジネス・プロセス (課金など) を開始します。このアプリケーションは、サービス・カタログ内の情報と個人 MDM 内の情報を GPS の位置情報と組み合わせることができます。それにより、例えば食事どきに、ユーザーのスマートフォンにそのユーザーの好みの料理を出している近くのレストランのメニューを送信したりすることが可能になります。


まとめ

SoE という手段で、IT テクノロジーはデジタル・ベースのビジネスに対し、まったく新しいクラスの機能を開放しています。これらの機能が、現在私たちが使い慣れている IaaS サービスを超える CloudOE 実装レベルを実現するには、クラウド・インフラストラクチャー内にぴったりの場所が見つかりますが、それにはクラウドの概念が必要になります。

SoE および CloudOE の実装をモデリングするには、人との関わりあいの動機付けから開始し、最終的に SoE アプリケーションをサポートするために必要な PaaS インフラストラクチャーを明らかにするという、トップダウンのプロセスが必要です。

謝辞

この記事で使用したアイデアの多くを提供してくれた Michael Bradley 氏、Martin Gale 氏、Moti Nisenson 氏、Thalia Hooker 氏に感謝いたします。また、記事のレビューに貴重な時間を割いて意見を下さった IBM SmarterCloud Orchestrator の主任アーキテクトである Fabio Benedetti 氏、そして IBM Cloud and Smarter Infrastructure CTO の Donald Cronin 氏に感謝いたします。

参考文献

学ぶために

  • TOGAF 9.1: Open Group の標準であり、エンタープライズ・アーキテクチャーの手法およびフレームワークである TOGAF について詳しく調べてください。
  • ArchiMate 2.0 の仕様: エンタープライズ・アーキテクチャーを記述する図の統一表現を実現する Open Group の標準エンタープライズ・アーキテクチャー・モデリング言語 ArchiMate について詳しく学んでください。
  • Systems of Engagement and the Future of Enterprise IT: A Sea Change in Enterprise IT」(Geoffrey Moore 著、AIIM、2011年): 「Systems of Engagement (人と関わりあうシステム)」という言葉を紹介したホワイト・ペーパーを読んでください。
  • The Next Generation Enterprise: Thriving in an Increasingly Digital Ecosystem」(Peter Weill、Stephanie Woerner 共著、MIT Sloan Management CISR、2013年): この研究概要では、次世代エンタープライズ用の 4 つのビジネス・モデル ― サプライヤー、オムニチャネル・ビジネス、プラグアンドプレイ・モジュール・プロデューサー、エコシステム・ドライバー ― について説明しています。
  • Case Studies in Service Innovation」(Linda A. Macaulay、他による編集、Springer、2012年) に含まれる、Rashik Parmar 氏による「Information Technology-Enabled Business Platforms」: Parmar 氏によるケース・スタディーでは、候補となるビジネス・プラットフォームを特定するために、組織を評価する手法を紹介するとともに、IT を適用することで競争の激しい業界に混乱を引き起こす方法も紹介しています。
  • The VMware Community Has the Innovator's Dilemma」(James Staten によるブログ、Forrester、2013年2月): クラウド・インフラストラクチャーのプロバイダーは SoE を考慮する必要がある理由についての見解に対する、この著者の意見を読んでください。
  • Mobile Is The New Face Of Engagement」(Ted Schadler、他著、Forrester、2012年2月): モバイルが人と関わりあう新しいシステムへ大きくシフトする兆候がどのように現れているかを学んでください。
  • Cloud Architecture Patterns』(Bill Wilder 著、O'Reilly Media、2012年): この本では、クラウド・プラットフォーム・サービスを利用するアーキテクチャー・パターンを紹介しています。
  • Programming for PaaS』(Lucas Carlson 著、O'Reilly Media、2013年): この本では、開発者が技術的な処理の扱いに時間を費やすのではなく、革新的なアプリケーションの開発に専念できるよう、PaaS がどう支援するかを紹介しています。
  • Pivotal による Cloud Foundry: Cloud Foundry の Web サイトにアクセスし、ユーザーが提供するサービス・インスタンスについて詳しく学んでください。
  • Heroku: Heroku クラウド・アプリケーション・プラットフォームの Web サイトにアクセスしてください。
  • Red Hat による OpenShift: OpenShift プラットフォームについて詳しく学んでください。
  • IBM BlueMix: IBM BlueMix プロジェクトに関する最新情報を入手してください。
  • developerWorks の Cloud computing ゾーンを調べてください。ここでは、コミュニティーによる貴重なディスカッションを見つけることや、クラウドに関連する新しい技術リソースについて学習することができます。

議論するために

  • developerWorks コミュニティーに参加してください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者によるブログ、フォーラム、グループ、Wiki を調べることができます。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。プロフィールで選択した情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=953245
ArticleTitle=リッチなユーザー・エクスペリエンスをサポートする SoE エコシステムの設計
publish-date=11212013