Software AGは、同社の幅広い層の顧客を対象に行った、SOAガバナンスのベストプラクティスを分析するためのユーザーアンケート調査の結果(リンク)を発表した。この調査から判明した重要な事柄の1つは、SOAは本物であり、企業内で大規模に進展しつつあるということである。連携システムは現実のものであり、価値を提供している。この調査では、回答者の91%が、ガバナンスはSOA戦略にとって「極めて重要」、あるいは「どちらかといえば重要」を選んでいることから次のことが明らかになった。
SOAガバナンスは、持続可能な全社規模の実装において重要な役割を果たしている。
回答者の意見は、次のツールがSOAガバナンスに必要だということにおいて驚くほど一致している。
- レジストリ
- リポジトリ
- セキュリティ
- ポリシー管理と実施
- サービスライフサイクル管理
- パフォーマンスモニタリング
- テスト
また、この調査では、SOAにとって重要な標準はどれかを質問した。WSDLとSOAPという回答がおよそ90%を占め、UDDI、WS-Security、BPEL 2.0、およびWS-Addressingがそれに続いた。REST、SCA、およびJBIという回答は、多くても10%程度という結果になった。
InfoQでは、Software AGのVP兼副CTOであるMiko Matsumura氏(リンク)調査の回答に対する意見を聞くため、いくつかの質問を行った。
InfoQ: 調査の導入部で「再利用（reuse）」という単語について言及していないのは、不注意からですか？ それとも意図的なものですか?
Matsumura氏: 私たちは、「再利用（reuse）」という単語を慎重に利用しています。なぜならこの単語は、人によって異なった意味を持つからです。開発者は、その単語に対して猜疑的でしょう。彼らは、オブジェクト指向のコードライブラリの「再利用性（reusability）」という文脈で、その単語をすでに耳にしています。もちろん、静的ライブラリを再利用するには、企業のライフサイクル対策、展開、品質保証、その他いろいろの面倒を伴うものであり、すでに展開されているサービスに接続するのとは大違いです。けれども、開発者は別の見方をします。ほぼ例外なく、新しいコードを書く方が何かを「再利用」するよりも簡単なのです。ビジネス部門の人間にとっては、心を躍らせる単語ではありません。彼らは開発のスピードと俊敏性を向上させることに、より大きな関心を向けます。そして、さまざまな機能をビジネスプロセスに加えられるという考えに、より敏感に反応します。ビジネス担当者と開発者に共通していることは、双方ともポリシーやプロセスにまつわるIT制約の複雑さと遅さに少々うんざりしているということです。どちらも特に「ガバナンス」という言葉には快い反応を示さないでしょう。
この単語に好意的に反応する唯一のグループが、財務部門です。彼らは、繰り返し発生するコスト（IT）を再利用可能な資産に変えるというコストモデルの概念から、これに大きな関心を示します。この概念は彼らにとって非常に魅力的であり、過去の嫌な経験もありません。単純に「これは間違いない。取り入れよう」と思うことでしょう...なるほど。
ですから、私は、人によって実に異なった意味を持つ単語を使用することに慎重になるのです。
InfoQ: ユーザーがSOAで直面してきた壁は何ですか?
Matsumura氏: 特に重要なものが4つか5つあります。中でも大きな課題となるのが資金調達と、初期および継続的な取り組みの両方を正当化できるようにすることです。これは、非常に興味深い課題です。ユーザーは、アーキテクチャの青写真にかなり熱心になる傾向にあります。誰もが常に現状のアーキテクチャについて何かしら気に入らないところがあり、多くの愚痴を抱えています。彼らは将来のアーキテクチャに強い関心があります。しかし、アーキテクチャは決してビジネス部門が関心を示すものではありません。ビジネス部門には、企業ITにとって敵となる「私にどんな得があるのか?」という考えがあります。これでは、調和を築くことが困難です。ROIを最初に構築する際には信用と協調が必要です。ITグループは利益や資金を生み出すことができないため、それを得るためにビジネス部門とパートナーを組む必要があります。
ここで、問題となるのはこの取り組みをどのように持続するかです。ROIを実証しても、他にさまざまなサービスの共有や所有権を確立する必要があります。ビジネス部門は必ずしもビジネスサービスを所有したいと思っているわけではありません。また、別のビジネス部門のために働くことなどはもってのほかです。 では、誰が変化の費用を払うのでしょうか? ビジネス部門はサービスを「所有」するのでしょうか? 彼らにとってサービスを共有することにどんな利益があるでしょうか?
これらはサービスを共有環境に移行するときの暗黙の課題であり、特にデータが関係する場合、彼らはデータの共有を望みません。また、困難を極めるあらゆるチャージバックメカニズムが存在します。無論、このほかに存在するデータスキーマレベルについて人々の合意を得ることの複雑さやコストについてはまだ触れてさえいません。
別のハードルは、ガバナンスの確立と採用です。これは、特に技術者にとっては非常に繊細な問題です。人々は統制されることを嫌い、「統制されること」への同意をはっきり主張しません。また、必ずしも統制の原理を共有しているわけではありません。従うべき原則は、「インフォームド・コンセント（情報に基づく同意）」を作り上げることです。彼らが統制されることに同意するのは、サービスが特定の方法で設計されている理由に関して深い理解があるためです。統制（ガバナンス）には通常嫌な思い出があるものですが、技術者は特にそうなのです。実際のところ、相互運用性やセキュリティなどの自動化されたポリシー強化の実施は、ITの短所を減速させるのではなく、加速させます。遵守が強制されるという事実に慣れるほかないのです。また、それは自動化されるか、または非常に遅くて手間のかかる手作業でのレビューになるでしょう。
再利用は挑戦であるともいえます。誰かが実施したことを学ぶには長い時間がかかります。変更の要求が必要な場合もあります。完全に新しいコードを記述するよりも、変更を加えることのほうが良いかどうかさえ不明です。しかし、人々はたいてい新しいコードにかかるコストを見逃します。バグ、信頼性、重複コードの増加するメンテナンス…. 皆、サービスが「定常状態」にあり、それは価値のあることだという事実を忘れがちです。たとえて言えば、自分の車を造るために設計図を「再利用」することと、友達の車を「再利用」することの違いです。実際の車は、より速く目標に到達させます。「とにかくコードを展開させてください」というのは非常に誘惑的なアイデアですが、私の経験上、たいていの企業ITではそれに伴うリスクを受け入れたがらないものです。そのため代わりに、私たちは既に存在しているものを使用することにより、超えなければならないハードルをかなり軽減しています。
InfoQ: ガバナンス（統制）において理想的な人員構成はありますか?
Matsumura氏: 理想的な構成は組織を代表するものでなければなりません。政府を見た場合、統制される国民の代表者がいます。2つ目の側面は、各部門の関心事について代弁を任せられる人物でなければならないということです。積極的に関心事について発表できると同時に、なぜ方針が合理的なのかを伝達できる人物を見つける必要があります。私は、「民主主義は最悪の政体であるが、今まで存在したいかなる政治制度よりはマシである」と言ったウィンストン・チャーチルがそれだと思います。これは、SOA「センター・オブ・エクセレンス」（CoE; 卓越した拠点）が代表機関であるべきであり、作成された方針の影響を受けるすべての人がそこで発言権を持つべきであるということを、示唆しています。
CoEの流れの中では、我を通すことはできず、衝突を解決するためのギブ&テイクのアプローチが常に存在し、積極的かつ探求的である必要があります。そのため、CoEの開発者代表は、あらゆることについて質問するようにしなければならない一方で、嫌われ者であってはなりません。結局のところ、これらの人と一緒に働くことになるからです。
InfoQ: B2Bではガバナンスはどのように機能しますか?
Matsumura氏: それには2つの視点があります。通常、多数の消費者と単一の供給者をベースとするモデルをサポートする、SOA原則および慣行が採用されています。これはサプライチェーンタイプのモデルであり、たとえば、大規模なOEM、あるいはWalMartやBoeingなどの例では、皆がこれらのインターフェースセットを通じて取り組みます。通常、多数の1対1の関係を築いています。このような状況におけるガバナンスは、ほぼすべて供給者側にあるため、それほど困難ではありません。状況がより高度化するのは、供給者と消費者のネットワーク全体にわたるビジネスプロセスです。
WebMethodsの観点から言えば、私たちは供給者のB2Bゲートウェイに多くの成功例を見出しました。私たちは、（オープンマーケット「eBay」モデルのような）多数の供給者と多数の消費者が存在するような状況を考慮していません。「仮想マーケット」（ドットコムブームの時には人気でした）はほとんど存在しません。一般的なパターンは単一の供給者対多数の消費者という構図に近いものです。
InfoQ: 成熟のレベルはどの程度ですか? SOAに関して企業では次に何が起こりますか?
Matsumura氏: この調査はかなり明確に認識の概念を示しています。次のステップは認識から行動に移行することです。私たちは技術的要件や組織的要件をより明確に確認します。次のステップは、実装とガバナンスの青写真を作成することです。人々には強い理解があり、それは必要なことなのですが、不十分でもあります。
InfoQ: SOAガバナンスとITガバナンスとの違いは何ですか? なぜ単なるITガバナンスの一部としないのですか? ?
Matsumura氏: 論理的には、SOAガバナンスはITガバナンスの一部であるべきです。実際、ITILのようなITガバナンス慣行を研究すると、システムの動作を最適化することに関する多くの手がかりが得られます。ITガバナンスは財務とITを連携させることに重点を置いています。特にコスト基盤には、コストを抑制するという非常に強力な方向性が存在します。また、プロバイダー指向も目立ちます。これは、ライフサイクル全体の資産を追跡するCMDBに重点を置くものです。「ヘルプデスク」を通じて多くの問題を目にし、CMDBでこれらの影響の根本原因まで追跡することによって、IT資産を最適化できます。ITガバナンスはよき前駆体であり（信頼性、TCOなどを重視する）、現在ITILはSOAの一部の側面を引き受け始めています。SOAガバナンスの特異的な部分は、ビジネスプロセスと俊敏性を重視することです。文化的に、SOAがもたらすものは、サービス消費者、事業体、または顧客といった主要な外部性です。現在は、サービス消費者のためにコストセンターに対し単に最適化を行うだけではありません。
ビジネスとITを連携させることにより、SOAガバナンスは文化を変える可能性があります。ご存知のとおり、ITILおよびITガバナンス内の「変更管理」の概念はヘルプデスクに集中しており、一般に新しい機能の開発や展開とは無関係です。ITガバナンスでは、「変更」とは何か悪いことが起きたことを意味し、「根本原因」を追跡し、責任者を特定する必要があります。SOAでは、変更とは新しい機能を意味し、再利用や複合や設定によって俊敏性が向上します。
InfoQ: SOAガバナンスは複雑な規律（レジストリ、リポジトリ、セキュリティ、ポリシー管理、論理データモデル、パフォーマンスモニタリング）へと進化しつつあるのでしょうか? それは、SOAを成功させることにつながりますか、それともSOAにとって負担ですか? SOAはそこまで複雑になっても大丈夫なのでしょうか?
Matsumura氏: 確かに多くの人がそれを不安に思っています。この点こそ、私たちがガバナンスの自動化が大きな役割を果たすと信じているところです。私たちが予期しているのは、ベストプラクティスの出現です。SOAで統一性を得る際には、相互運用性を礎にすることが望まれます。供給者と消費者の間に多くの依存関係がある場合は、SLAが適切に実施されることを確実にすることが望まれます。ふるまいの管理を助けるポリシーによって、システムをより管理しやすくすることができます。これらは、連携したシステムの運用に欠かせないものです。
ガバナンスは複雑なシステムです。人々への影響を最小限に抑えることが望まれます。自動化は、複雑な処理を扱いやすくします。追跡すべき事柄は多くあるため、頭の中ですべてを追跡することはできません。
SOAガバナンスの自動化を成功させるには、セキュリティ、相互運用性、保守性のトピックを繰り返し促進する必要があります…
InfoQ: バージョニングは、すべてのリモート技術において主要な難題であり続けています。バージョニングには皆どのように取り組むのですか? どのようなツールでバージョニングを単純化しますか?
Matsumura氏: 第一の原則は、進化の原理が重要な原則であるということです。ある意味、正しい答えというものは存在しません。完璧な粒度と再利用性を見つけたとしても、その後、それらでは実行できない新しいシナリオを発見するでしょう。他の落とし穴は、完全な再利用性と粒度および完全なスキーマを生み出すためにには、人生の多くの年月を費やすことです。決して出荷に達することはないでしょう! そのため代わりに、質は悪くともできる限りビジネスニーズに合うサービスを出荷し、可能であれば、将来的なあらゆる使用を想像しようとします。そのとき、バージョニングが必要になります。どのようにしてバージョン分裂を回避し、結果としてサービスを駄目にしてしまわないようにできるのでしょうか?
その鍵は、消費者と供給者間に一定の緩い結合を導入する結合ポリシーを確立することです。仲介を使用し、エンドポイントは仮想にしなければなりません。ある程度まで、バージョンを透過的に移行および緩和する手法を利用できます。ここでの大きな問題は、皆がエンドポイントにしっかりと結合されている場合、まず第一に誰がサービスに結び付けられているかを発見する必要があるということです。ある種のガバナンスシステムがなければ、誰が消費者なのかさえ把握できません。仲介がない場合は、新しいバージョンを反映するために消費者にコードを再コンパイルしてもらう必要があります。つまり基本的に、粗悪なものを使用して皆を追い詰めてから新しいバージョンを反映するためにコードを再コンパイルしてもらわなければなりません。そうも行かないので、匿名の消費者（気に掛ける必要がない者、サービスの拒否をされないように消費水準を制限する必要がある者も除く）が存在しない結合ポリシーを設定し、すべての消費者が「仮想化された」サービスエンドポイントに結合されるようにしてください。、そうすれば、仲介は望み通りの方向に消費者を向けることができます。
もう1つのメカニズムはランタイムディスカバリですが、大量のディスカバリは目にしません。AmberpointやActionalなどのエージェントベースのディスカバリがあり、それからManaged Methodsなどのネットワークベースのディスカバリがあります。
また、分類法、および役割ベースのアクセスコントロールを使用して、バージョニングの複雑さを一部隠すこともできます。これにより、異なるグループが、実際はいくつかのバージョンが存在しているにもかかわらず、同じサービスを見ているように感じられます。いくつかのバージョンを持つことは、避けられないかもしれません。
これらは、より移行型の対応です。私たちは問題の存在を否定することはできません。物事は、変異し、進化しなければならないでしょう。
ガバナンスの難所は3つあります。:
サービスを開発する開発者の場合、彼らは再利用性のチェックポイントを通過し、サービスが再利用可能かどうかや再利用すべきかどうか、新しいバージョンが必要かどうかを検証する必要があります。この場合も当然ポリシーが存在すべきであり、再利用できるサービスがあれば、どうぞ利用してください。2つ目の難所は、ランタイムガバナンスシステムです。新しいバージョンがある場合、透過的なリダイレクトや、ある程度のXSLT変換やスキーマの操作を通じて、そのバージョンを古いユーザーに透過的にすることができます。3つ目の難所は、ディスカバリ時に、新しいバージョンの発見を透過的かつ低侵襲的にすることです。多数のバージョンがある場合、少なくとも不適当なものを様々な消費者グループから隠すことができます。
InfoQ: SOAガバナンスの資金をどのように調達できますか?
Matsumura氏: 最初のパターンはトップダウンパターンです。アーキテクトやVPレベルのIT幹部からそのメリットに対する合意を得られると、高い信頼度があり、これが資金を得る方法となります。
2つ目のパターンは、極秘活動です。ビジネス部門は他の誰もが必要とするものに資金を供給しない傾向があります。明るい話をすれば、小規模なSOAが長い道のりを歩むためには、ビジネス部門が重要な資金提供者となります。BPMプロジェクトに結び付けられた小さなSOAは、最初から何千万ドルものROIを実現することができます。そのため、あまり大騒ぎせずともガバナンスや共有のインフラストラクチャコンポーネントを容易に組み込むことができます。これには、プロジェクトにガバナンスアクティブティを組み込むための、ある程度の努力が必要です。
また、原価計算メカニズムである種の共有インフラストラクチャを確立し、ある種のチャージバックメカニズムを導入することができますが、これには、かなり真剣な幹部の肩入れが必要です。
InfoQ: SOAガバナンスからどのようにROIを生み出すのですか?
Matsumura氏: SOAガバナンスとSOA導入は、SOA自体の利益に結ばれた実現戦略であり、新たな良い面の1つは、BAMの利益、ランタイムガバナンスを目にすることが増えており、それらの利用や再利用によって継続的なサービスの経済的利益を測定できることです。結果的に、サービスの再利用性が成長や価値を示すパターンに至ります。サービスの価値の向上が見られると、新しい消費者が同じ注意を再利用したり、サービスの数を増やしたりするのが見られるため、ビジネスにとって刺激となります。
要するに、サービス数を増やすユーザーの増加により、利用率の増加が見られる場合、「ホッケースティック」の成長曲線になります。あとは、その利用にどれほど価値がありROIを実現できるかを示すことです。
私たちは素晴らしい成功を目にしており、ユーザーは自身を正当化することができます。
InfoQ: SOAP/WSDL対RESTに関して業界では多くの議論が交わされています。調査は絶対的であるように思われますか?
Matsumura氏: 企業の人々は、かなり日和見的に標準を使用し、標準からベストプラクティスと相互運用性を取り入れます。そうした要因を見ると、標準が振り落とされる理由を理解できます。その一部はWS-I Basic Profileにあります。私たちは多くのSOAPベースのアクティビティを目にしています。メッセージングアプローチは一般に企業が行っていることを強化します。Webベースのアプローチがある場合は、拡張性に配慮を払い、RESTがよりふさわしいように思います。
すべてのシステムが対処する準備ができている最大公約数的な標準であることを理由に、SOAPの採用がかなりの割合を占めているようです。明らかにRESTの占める割合は少ないのですが、JBOWS（Just a Bunch of Web Services; たくさんのWebサービスの寄せ集め）になる場合があります（ここではWS-*「Webサービス」を意味しているのではありません。単に、Web上で利用できるRESTサービスを意味しています）。
SCAに関して、Software AGはその取り組みの最古参の一角です。まだ、顧客レベルではそれほど興味を得てはいませんが、システムを設計する方法の観点からすると、かなり便利です。ゆくゆくは、webMethodsおよびCentrasite製品ラインでSCA関連の機能を多数サポートする予定です。たとえば、SCAアセンブリパッケージでエレメントを動的に解析する機能や、Centrasite内でガバナンスの依存性を視覚化する機能などです。
InfoQ: 2008年、いまだに「スキル不足」が一番の問題です。今、それをどのように解決できますか? どのような前進の道がありますか?
Matsumura氏: 私たちはエンタープライズITはビジネスです。これまでのところSOAに人が群がり、他の人々はあちらこちらを観て歩いていますが十分な導入ではありません。長い年月を経て、最終的に導入するときが到来したのです。調査から明らかなことは、SOAが現実のものであるということです。スキル不足は自然に解決するでしょう。実際に資金が流入するようになり、ユーザーはトレーニングや就業の機会を得るようになるからです。
原文はこちらです：