コメント行: Kyle Brown、Rachel Reinitz: SOA に学ぶ Web 2.0 のための教訓

成功への道を順調に進むための 5 つの方法

この記事では 2 人の経験豊かな SOA アーキテクトが新しい Web 2.0 技術の世界を批判的な目で見つめ、SOA に Ajax や REST、その他の Web 2.0 技術を導入する上で、より確実に成功へと導く 5 つのベスト・プラクティスを紹介します。

Kyle Brown, Distinguished Engineer, WSO2 Inc

Kyle Brown's photoKyle Brown は IBM Software Services for WebSphere の Distinguished Engineer として、SOA および新興技術を専門としています。また、フォーチュン 500 社の顧客を対象に、SOA、オブジェクト指向関連、そして J2EE 技術に関するコンサルティングと教育指導も行っています。彼は『Java Programming with IBM WebSphere』、『Persistence in the Enterprise』の共著者であり、コンファレンスでも頻繁に SOA、Enterprise Java、OO デザイン、デザイン・パターンに関する講演を行っています。



Rachel Reinitz, Distinguished Engineer, WSO2 Inc

Rachel ReinitzRachel Reinitz は、IBM Software Services for WebSphere の IBM Distinguished Engineer であり、IBM Academy of Technology のメンバーでもあります。SOA、エンタープライズ・サービス・バス、そして Web サービスに関する IBM 内外の知的資本および教育のほとんどは、彼女が確立したものです。SOA および ESB のベスト・プラクティスの導入方法を専門とする彼女は、SOA と ESB を使用してビジネスおよび技術上の目標を達成する方法を顧客と ISV と協議しています。カンファレンスの司会者を務めることもよくあり、ESB と Web サービスについて多数の developerWorks の記事も書いています。Rachel が住んでいるのはカリフォルニア州のベイエリアで、ハイキングや、さまざまな人との社交、海外旅行などを楽しんでいます。



2009年 1月 28日

私たちはまた同じ状況に直面しています

前にもまったく同じことが言われていたように、新しい技術が登場すると、それ以前の技術で今まで行われてきた手法が突如として使われなくなり、そのうち消えてなくなります。一見すると、新しい Web 2.0 技術もこのパターンを辿っているようです。Web 2.0 技術の熱狂的支持者たちは、一切の SOAP サービスを捨て去る必要があると言うでしょう。SOAP と WSDL を使用してプロジェクトを構築するという手法は時間がかかるだけでなく、何のメリットももたらさないというのが彼らの理由です。しかしもちろん、事実はそれほど単純ではありません。

REST はある種のサービス (特に、インターネットや Ajax クライアントに向けたサービス) を容易に作成できるようにしますが、SOAP、WSDL、そして WS-* 仕様を適用することがメリットになるサービスはまだたくさんあります。さらに、SOAP サービスのタイプによっては、REST サービスに変換することによって Web 2.0 を取り込むことが可能になる場合もあります。その顕著な一例は、データ指向サービスです。この議論は別として、サービスに REST を導入すると決めたとしたら、エンタープライズ SOA システムの構築から学んだ教訓を思い返し、それが RESTful サービスを構築する場合にはどのように当てはまるのかを検討することが賢明です。読者の皆さんにとって幸いなことに、私たちはいくつかの主要な分野で手痛い教訓を学びました。この記事では、これらの教訓を皆さんと共有し、私たちと同じような困難を味わうことなく Web 2.0 成功の軌道に乗れるよう、お手伝いをしたいと思います。

1. 新しいビジネス・モデルを使用できるようにすること

CEO (したがって、CIO も然りです) の最優先事項は、市場を革新し、新しい市場に参入することです。SOA の重要なセールス・ポイントであるビルディング・ブロックとしてのサービスは、ビジネス・プロセスの柔軟性を高め、それによって新しいビジネス・モデルと革新を可能にしてきました。SOA がビジネスに最大の価値をもたらすのは、ビジネス・プロセス・マネージメント (BPM) と組み合わせられたときです。BPM でよく目標とされるのは、新たな市場あるいは領域に参入できるようにすること、そして新製品や新しいオファリングの導入を促進することです。それと同じく、Web 2.0 は顧客とビジネス・パートナーに対する働き掛け、彼らとのコミュニケーション、そして連携を、以前は不可能だった方法で可能にします。

Web 2.0 の概念を新しいビジネス・モデルの推進力にするには、いくつかの方法があります。Web 2.0 の概念によって、ビジネスではコミュニティーの形成、ユーザーによる重要データの生成、ユーザーを中心としたエコシステムの構築、ユーザーとの新しいコミュニケーション手段の発見、情報の「マッシュアップ」による新しいフォームやビューの作成が可能になります。eBay、Amazon.com、Flickr、Twitter などの会社は、ユーザーが生成したデータによって基本的価値、そしてビジネス・モデルが生まれているビジネスの実例です。もちろんこれは単純化した表現ですが、Web 2.0 をリッチな UI、Atom フィード、RESTful サービスに重点を置いた高度な技術としてしか捉えていない場合、どのようにすれば Web 2.0 を根本的なビジネスの転換に利用できるのか見逃してしまう可能性があります。

2. ビジネスに働き掛けること

SOA の成功で大きな要因となっているのは、SOA が 2 つのレベルで同時に功を奏したメッセージであるということです。つまり、SOA はビジネスに影響を及ぼすだけでなく、IT の共感も呼びます。上記で説明した Web 2.0 の価値をより高いレベルで実現するには、ビジネスは、Web 2.0 の果たし得るビジネス転換における役割と、それを実現するために必要な投資の両方を理解しなければなりません。一般に、IT が新しい技術の導入をビジネスに支持させるには、その技術をビジネス価値に結び付ける必要があります。SOA の場合、BPM と結び付けることによって、ビジネスと IT が連携することの重要性が際立ちます。大抵は、まず BPM のメリットを説明してから SOA をベースに BPM を実装することがいかに最適な方法であるかを説明することが、BPM に SOA を結び付ける最も簡単な方法となります。この流れで説明すれば、互いに補完し合う仕組みを明らかにできます。

また、SOA が成功した理由のひとつには、IBM が SOA のメリットをビジネスと IT の双方にとって理解しやすい表現で説明する手段を用意できたということもあります。おかげで私たちは、共通シナリオ (例えば、e-ビジネスのパターンに関する一連の Redbooks で説明している IBM SOA Foundation シナリオ) の助けを借りて、ビジネス側の人々がうなずける価値を実証することができました。

このことから学べる大事な教訓は、ビジネス価値に関してはできるだけ具体的に説明する必要があること、さらに Web 2.0 を導入することから予想される投資収益率 (ROI) を提示すると効果的だということです。現実を認めると、ビジネス・コミュニティーは必ずしも開発者と同じように新しい技術に活気づくわけではありません。したがって、Web 2.0 を軌道に乗せるためには、(おそらく開発者に対して既に行っているように) ビジネス・コミュニティーに対して彼らの言葉で働き掛ける必要があります。手始めとしてのシナリオの一例は、Web 2.0 を使用してビジネスまたは製品のコミュニティーを形成し、顧客サービスやブランド・ロイヤルティーの改善などといった価値を促進することです。このような価値を明確に表現する上で、私たち全員が成長するとともに (これについては、ますます多くの本が書かれるようになっているので参考になります。「参考文献」を参照してください)、使用されている技術の詳細に触れることなく Web 2.0 を説明できるようにならなければなりません。これは SOA ですでに成し遂げたことです。それと全く同じく、核心に入ることなく Web 2.0 を導入することによるビジネスのメリットを説明できることが重要となります。

3. 確固たる方法に基づいて導入を推進すること

SOA 成功のもう 1 つの重要な要因は、IBM SOA 方法論であるサービス指向モデリングとアーキテクチャー (SOMA and RUP-SOMA) の基礎を成すプラクティス、手順、ルール、そしてビジネス・モデリング手法とのその密接な関連です。IBM Business Consulting ではコンポーネント・ビジネス・モデリング (CBM) を開発し、これを SOMA への主要なインプットとして使用しています。CBM やその他のビジネス・モデリング手法は、ビジネス・ユーザーを関与させ、彼らがビジネスと IT の連携を理解できるようにします。SOMA が重点を置いているのは、詳細なサービス仕様からその実現に至るまでの全過程におけるビジネスとの連携です。SOMA と RUP-SOMA は、Web サービスが使われるようになった当時の IBM RUP (Rational® Unified Process) から完全な形で生まれたわけではありません。数年かけて開発および改良が重ねられ、今でも評価、修正が続けられています。

Web 2.0 が成功するためには、既存の SOA とオブジェクト指向のデザイン手法を進化させることになる確固たる方法の基礎を築かなければなりません。例えば、Web 2.0 アプリケーションのターゲットとするコミュニティーを識別する方法だけでなく、そのコミュニティーでのコミュニケーション・スタイルを識別する方法も必要です。前述のとおり、コミュニティーを利用することによってもたらされるビジネス価値を定義し、サービスの評価に役立てるための方法もなければなりません。同様に、アプリケーションの統合に適切なサービスと、リッチ・インターネット・アプリケーションのサポートに適切なサービスとの違いを見分けるために、SOMA サービスの識別メカニズムとサービスの識別テストを変更あるいは拡張する必要も出てくるはずです。

RESTful サービスについては考え方を変える必要があることを説明する一例として、エンタープライズ SOA サービスとは異なる、RESTful サービスならではの観点を考えてみてください。第一に、内部サービスを公開することが一般に普及させる方法として最善であるとは限りません。外部サービスが、企業独特の視点を表さなければならない可能性があるからです。例えば、エンタープライズ SOA を世界規模の運送会社の Web にまで拡大しているとします。この場合、サービスをどのように構築するかについては、2 つの異なる焦点があります。サービスの識別に SOMA 手法を適用する一環としてビジネス・プロセスのモデリングから始めるとすれば、このような企業のプロセスをモデル化する上での焦点 (内部焦点) は、採算性を最大限にするためのリソースの最適化に絞られるはずです。言い換えると、このようなモデル化を行う際には、以下のような検討事項が考えらます。

  • 飛行機とトラックの積載率はどれくらいか
  • どのようにして燃料費を最小限に抑えるか
  • X 個のパッケージを A 地点から B 地点まで輸送するのに最も安価な方法は何か

一方、この企業を Web サイトを使用しているユーザー (または、Web サイトで公開されている RESTful サービスをマッシュアップで使用したいと思っているユーザー) の視点で見ると、モデル化の際には別の焦点が必要です。つまり、外部の顧客を中心とした場合、検討事項は以下のように変わってきます。

  • パッケージはどこにあり、いつ到着するのか
  • 顧客の元からトレド (Toledo) までパッケージを送るには、送料がいくらかかるか

まずは前者の視点からモデリングを行い、モデリングが完成した後に、後者の視点から RESTful サービスを追加しようとしているとしたら、必要なモデリングの作業と設計の作業が増えることを自覚しなければなりません。しかし、ここにこそ、SOMA と RUP-SOMA のような手法が持つ長所の 1 つがあります。これらの手法は反復型なので、RESTful サービスに伴う変更が必要であると認識した場合には、不適切なものを無理やり型にはめようとするのではなく、その変更に適応することが可能です。

4. 構想を持ち、ロードマップを定めてプロジェクトを実行すること

図 1 は私たちが SOA を導入するには何が必要かを伝えるために使用したもので、とりわけ役に立った図の 1 つです。このグラフは、ビジネスと IT 全体における SOA 構想の必要性を表しています。私たちに必要なのは、現時点でどの段階にいるのかを判断し、そこから構想を実現するまでのロードマップを定め、そしてそのロードマップを漸進的に実行するプロジェクトを実装することです。この手法は、SOA の導入だけでなく、Web 2.0 の導入にも同じく適用されます。

図 1. SOA 構想
SOA 構想

必要不可欠なのは、1) 構想を設定し、2) プロジェクトを実行することです。Web 2.0 の構想とロードマップだけに集中して (これには、インフラストラクチャーとフレームワーク・プロジェクトの実装も含まれます)、「実際」のプロジェクト (生産に入ってビジネス価値をもたらすプロジェクト) が欠けていると、プロジェクトのニーズを満たしていないインフラストラクチャーと手順になる危険性が高くなり、それによってプロジェクト・チームがロードマップ/アーキテクチャー/フレームワークに従うことがますます難しくなります。一方、構想とロードマップもなければ、共通のインフラストラクチャーもないという状態で個々の Web 2.0 プロジェクトを独立して実行した場合には、価値を十分に実現することができなかったり、すでに学んだ教訓をもう一度学び直さなければならなくなったりする恐れがあります。また、プロジェクト間でコードが再利用されなかったり、共通のインフラストラクチャーと手順 (セキュリティーなど) が構築されなかったりする可能性もあります。初期プロジェクトは、価値を実現するような大掛かりなものにする必要はありませんが、新しい技術とビジネス・モデルを経験する好機となることは確実です。

5. ガバナンスを見落さないこと

顧客の SOA 導入を支援するプロセスのなかで、私たちが比較的遅い段階で気付いたことは、SOA ガバナンスの必要性が極めて大きいことです。IT ガバナンスは時に厄介な問題になります。IT ガバナンスは実践するものというより、説得するものだからです。一方、SOA ガバナンスは SOA が提供する特定のセマンティックとビジネス要素に対処するように IT ガバナンスを拡張するプロセスで、拡大、維持、拡張が可能な SOA を構築する鍵となります。さらに、SOA ガバナンスには IT ガバナンスの枠を超えて、ビジネス・リーダーも含める必要があります。

私たちが実感したのは、SOA の原則に従って構築されたアーキテクチャーが拡大し、成熟するにつれ、SOA インフラストラクチャー、そしてサービスの開発およびデプロイメント・プロセスの両方を管理および制御することが極めて重要になってくるという点です。IBM Rational Asset Manager、IBM WebSphere® Service Registry and Repository、IBM Tivoli® Policy Manager for SOA Security などのツールは、確固たるガバナンス・プロセスの導入に役立ちます。

一方、Web 2.0 の原則に従って構築された初期のアプリケーションから見て取れたことは、Web 2.0 導入の重要な側面はコミュニティーでの自由なコミュニケーションと連携、そして情報の共有であることから、Web 2.0 のガバナンスはなおさら困難だということです。RESTful サービスや Atom サービスを公開する際には、これらのサービスを制御しながらも、サービスの使用とユーザーによるアセットの開発を制限しない方法を考えなければなりません。あまりにも制約的なガバナンス・プロセスによって、コミュニティーを形成する際の社会学的側面が限られてしまっては、コミュニティーの成長は望めません。その一方、不十分なガバナンスや不適切なガバナンスによって弊害を受けているオンライン・コミュニティーを私たちは数多く目にしてきました。貴重なコンテンツが存在するにも関わらず、「ジャンク」に埋もれてしまっているために、そのコンテンツを強調できないとう事態は容易に起こり得ます。

例えて言うならば、Web 2.0 のガバナンスは公園を管理するようなものです。優秀なパーク・レンジャーのように、管理できる範囲以内で多様性を奨励する一方、決められた境界を越えないようにしなければなりません。いずれにしても、ガバナンスを計画し、RESTful サービスがガバナンス・プロセスによって確実に制御されるようにすることが、息の長い有益な RESTful サービスを確かにする上で大きな意味を持ちます。


まとめ

エンタープライズ SOA 開発で学んだ教訓はこれだけではありませんが、ここで説明した教訓がまさに、RESTful サービスを構築する際には先を見越して計画すること、ビジネス価値を重視すること、そして SOA 全体を大局的に見ることが重要であると明らかにしています。一歩離れて問題を徹底的に検討することが、Web 2.0 プロジェクトをさらに大きな成功へと導き、企業のその他の側面に一層結び付けやくするはずです。

参考文献

コメント

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=WebSphere, SOA and web services, Web development
ArticleID=372572
ArticleTitle=コメント行: Kyle Brown、Rachel Reinitz: SOA に学ぶ Web 2.0 のための教訓
publish-date=01282009