始めに

サービスは、それが船便のような物理的なサービスであるか、あるいはソフトウェアによって実装されたものなのかによらず、いつでもできるだけ多くのコンシューマに再利用されるように設計され、洗練されるものです。これは、サービス指向アーキテクチャの本質です。つまり、設計時点では分からないことがしばしばありますが、今まで利用してきたITの資産を分解して実装するすることで、ソリューションを構築することに伴う、経費やリスクを低減します。 SOAガバナンス自体は、情報モデルを設計したり、所定のプロジェクトを超えて再利用可能なテクノロジーを選ぶことを目的としたデータやITガバナンスと少しも違いがありません。サービスは、再使用できるようになるために統制されなければなりません。何故なら、予測可能なコンシューマは全てサービスのオーナーや資金調達モデルが決まっているので、引き続き優先的に行うものなのか段階的に行うものなのかといった要求を明らかにすることができるからです。

以前の記事で、Stefan Tilkov氏はSOAガバナンスの役割について特に注目していました(参考記事1)。私は、人、プロセス、技術という観点からサービスのガバナンス組織を構築するために役にたつことをゴールに定めます。

サービスガバナンスが行うこと

サービスガバナンスの主要な目的は、エンタープライズレベルのサービスなど再利用できるものの作成を促進することによって、サービス指向アーキテクチャの利益を獲得することにあります。組織の枠を超えて、サービスガバナンスは共有する要求があるときに必要なもののトレードオフが行われるので、問題と紛争のタイムリーな解決を確かなものとします。

特に、サービスのガバナンス組織は、サービスオーナーシップの範囲を明確に定めて、しっかりとした資金モデルを決めるために活用されます。

サービスガバナンスは、組織を跨いだサービスの再利用とデプロイメントを監視します。高度なサービスの再利用、エンタープライズレベルの安定したサービス提供までの流れ、トラブル無くサービスを廃止するといったことは、ガバナンス成功の指標となります。

サービスガバナンスは、既存のITガバナンスやエンタープライズアーキテクチャと重複すべきではありません。それらは、SOA技術の標準やSOAの完成度のレベルを高いものへと導くためのロードマップを定めていますが、一方でサービスのガバナンス組織は、サービスの形を発展させているからです。

一般に、サービスガバナンスの役割は受動的であり、プロセスサービスの候補が特定のプロジェクトやビジネスレベルの単位で決められます。サービスガバナンスがエンタープライズサービスにおける組織的なトップダウンの特定を開始し、すべてのプロジェクトが独立した形での実現を許可するかもしれないのは、組織が高水準な完成度に到達したときだけです。

ともかく、ガバナンス組織は、エンタープライズサービスの独立した予算やサービスの候補を始めに扱うプロジェクトに関するリソース制限を、組み立てるための権限を与えられるべきです。何故なら、通常、再利用性はより大きなスコープの中にあるもので、より高い値札がつけられるものだからです。

ガバナンス組織は企業価値として管理されることが求められるサービスを決める管理人なのです。加えて、ビジネスプロセスや参照データモデルといった、他のエンタープライズの資産と共にトレーサビリティやコンプライアンスを保持する責任もあります。最後の節で、参照データモデルやエンタープライズデータモデルの関係について振り返ってみようと思います。

人々

以下では、以前に書かれた役割に関する記事(参考資料1)に、サービス実現の観点からサービスガバナンスの取り組みを含めています。組織がサービス指向アーキテクチャを開始する時、以下の役割はエンタープライズレベルのサービスを提供することを保証するのに十分なものとなりえます。特に、彼らがSOAの中枢組織に属しているのならばなおさらです。

しっかりとした組織と多くのサービス候補の増加につれて、ガバナンスの活動が適切に実行されることを確かなものとするために、プロセスとリソースを所有するガバナンスリーダーを紹介することは有益なことです。ガバナンスリーダーは職制上の枠を超えたガバナンス協議会やサービスライブラリアンによってアシストされなければなりません。

サービスのガバナンス組織に関する3つの主要な成熟レベルを見てみます。

図1では、サービスガバナンスの役割における相互関係を表しています

図1. 異なるガバナンスの構成要素の相互関係

サービスのガバナンス組織を成功に導くための鍵は、ニーズを満たすために十分なリソース、プロセス、テクノロジーを、俊敏に組み立てることにあります。サービス候補に対する適切なパイプラインのない大きなサービスのガバナンス組織では、すぐに力を失いサービス候補に対する十分なフィードバックを与える機会を逸してしまうでしょう。

サービスの再利用性を促進する組織をつくりたい、ただそれだけのことなのですが。

プロセス

プロセスとアクティビティ

SOAのガバナンス組織によって実行される5つのアクティビティは以下のとおりです。

• サービス候補の管理
• サービス変更の管理
• サービスコンシューマの管理
• サービスロードマップの管理
• SOAガバナンスのポリシーの変更

図2では、サービス候補の管理プロセスの間に実行できるアクティビティを示しています。プロジェクトチームはサービスを特定し、提案します。そして、その提案は承認(修正を行った上での承認を含む)されるか、エンタープライズの他の部門で再利用可能となる可能性がないサービス候補ということで、(エンタープライズサービスとして)却下されます。一度サービスの候補が受け入れられると、サービスオーナーや潜在的なコンシューマの手を借りて、オーナーシップ、資金モデル、SLA、OLAといったものが規定されます。そして、サービスが実現すると、そのメタデータがレジストリやリポジトリに公開されます。大きな組織においては、平行したサービスの提案を避けるために構築中のサービスの経過を追跡することを勧めています。

アクティビティの管理の変更は、サービス候補のレビューの間に実行されたアクティビティと同一のものであることがよくあります。サービスオーナシップ、資金モデル、SLA/OLAの規定といったアクティビティは、任意のものかもしれません。

変更管理の重要な側面の一つとして、互換性のあるサービスに対する効果的な管理があります(参考資料2)

新たなコンシューマがサービスを利用する必要性が生じない限り、サービスコンシューマのアクティビティ管理はほとんどがサービスライブラリアンによって行われます。サービスコンシューマが対象となるサービスを特定し、そのメタデータのコピーを取得する手助けをライブラリアンがおこなうこともあります。

サービスロードマップのアクティビティ管理は、サービスガバナンスが特定のプロジェクトのリクエストによらずにサービスを特定することを積極的に行なうという条件の下で提供されます。その時点で、サービスガバナンスはプロジェクトで利用するよりも前のサービスの開発を行うための予算を立てるべきです。これは、サービスの再利用に関する設計や実装が、特定のプロジェクトの思考領域、実装方法、スケジュールを超えてうまくいく可能性をもつので、ガバナンスの重要な成功要素といえます。ガバナンスのアクティビティは、それ自体が時間をかけ、長い間改善することが推奨されると思います。以上の理由から、ガバナンス組織がスケジュールを管理して、タイムリーにコンシューマの指定した要求を段階的に実行し、配布の期間の影響を最小限にすることはとても重要なことです。

図2. サービス候補のアクティビティ管理

最後に、ガバナンス組織はオペレーションポリシーを定義・変更するためにITガバナンスを行います。

サービスメタデータ

サービス候補の提案には、SLAやOLAを定義するための例として利用するサービスに関連する全ての機能/非機能要件だけでなく、サービスインターフェース(機械が読めるフォーマットでなくても良いです)の記述も含まれています。CBDIフォーラムのサービスアーキテクチャとSOAに関するエンジニアリングメタモデル(参考資料3)では、ライフサイクルの早い段階で獲得し、時間とともに洗練されたサービスに関する素晴らしい情報を提供しています。

CBDIフォーラムのSAE™メタモデルは、サービスの分類だけでなく、サービスの定義、提案されたオペレーション、ポリシー、関連するサービスが含まれています。CBDIフォーラムは、ビジネスプロセス、ビジネスの可用性、ビジネスルールなどに関連するビジネスレベルのサービス定義を含めることを推奨しています。

これらの情報全ては、コンシューマが特定のサービスを検索する際に利用される可能性を秘めています。故に、たとえWSDLがこの種の情報を(今は)サポートしていないといったような機械が判別可能な標準の記述であったとしても、それを構造化された方法で獲得するのは重要なことです。

CBDIフォーラムのSAE™ メタモデルは、サービスの仕様に対し分割した部分を提供します。メタモデルの一部の興味深いところは、それがオペレーションの引数としてサービスの中に含まれている情報の追跡ができるようになっているということです。この機能はWSDLでも十分にサポートされていないものです。例をあげると、ビジネスタイプそれ自身ではなく、オペレーションの呼び出しの一部として変換されたビジネスタイプの表現を定義しているだけなのです。

情報タイプのトレーサビリティは、それが特定のオペレーションセマンティクスの導入を防止するため重要なものとなります。メッセージタイプは、常に参照データモデルと深い関係の中で定義される必要があります。実際のところ、SOAのガバナンスプロセスにおいて、参照データモデルと比較して、追加的なセマンティクスがメッセージタイプの中に定義されることがないようにしなければなりません。

CBDIフォーラムのSAE™メタモデルは、サービス実装で利用されるビジネスコンポーネントの追跡もできるようになっています。

サービスの再利用性の要素

再利用性のあるサービス仕様の促進に役立てる際に、考えるべき3つの重要な要素があります。まず第一に、サービスのインターフェースが現在のコンシューマと潜在的なコンシューマに留意して作られたものであるべきです。
そして、よい測定基準となる道のりは、上位互換性のあるものとそうでないものの両方に対し新しいコンシューマが加わるにつれてインターフェースの数や実装が変化することです。

第二に、私たちは適切なサービスレベルアグリーメントとオペレーショナルレベルアグリーメント(SLAとOLA)を熟考すべきです。あるSLAは一人のコンシューマのとって完全に機能し、他の人にとって致命的な問題となるかもしれないかれです。SLAとOLAは、達成するのも難しいものです。SOAのガバナンス組織は、効果的なSLAとOLAになるためのサービス実装の変更点だけでなく、これらの出来事から生じるSLAとOLAの変更点を監視し、その経過を追い続けるべきなのです。

最後に、サービスのガバナンス組織は、サービス候補となる全ての潜在的なコンシューマを特定して、彼らをサービスインターフェースの提案を承認するプロセスに含めようとすべきです。よい判断基準となるものとして、サービスが設計された後に見つかる予期していなかったコンシューマの数です。この判断基準は、慎重に解釈されなければなりません。何故なら、それがサービスがしっかりと設計され多くのコンシューマを魅了したものであることもあるし、或いは、後に続く多くの変更により適切なコンシューマを特定する時間が足りなかったということもあるからです。

テクノロジー

サービスガバナンスの活動と役割は、大抵の場合、サービスレジストリとサービスレポジトリなどで構築されるガバナンスソリューションによってサポートされます。言うまでもないような当たり前のことだとしても、作ることと同じくらい再利用することが資産となり得るということを、常に心にとどめておくことは重要なことです。レジストリは、SOAのサービスにおける「システムの記録」として動作するカタログ若しくはインデックスなのです(参考資料4)。

SOAレジストリとリポジトリは、一般的に以下の機能をサポートします。

• ディスクリプション(メッセージフォーマットやオペレーション)、バインディング(通信プロトコル)、エンドポイント(サービスを実装するネットワークアクセスのリソース)といった、サービスのメタデータを格納する
• サービスの分類、体系化を支援するための区分のメカニズムを提供する
• ユーザーが、(特定、実体化、デプロイをした)新しいサービスをレジストリにパブリッシュし、既存若しくは予定されたサービスをブラウズ、検索できるようにする
• サービスコンシューマに計画されている変更を通知する
• 利用の統計だけでなく、SLA、OLAのレポートを管理する
• 安全なガバナンスのプロセスと成果物を管理する
• 変更の痕跡を追跡するための監査の機能や、資産の記述に応じた承認の機能を提供する

ガバナンスプロセスは、実際には地理的に分散しており協調するものです。これらのプロセスの管理は、サービス定義と実現におけるコンセンサスに必要な異なる関係者をつれてくるのに重要です。

レジストリとリポジトリは、設計時と実行時の両方のサービス情報を記録するためのシステムであるので、「サービスレコード」関連のセキュリティは、インスタンスのエンドポイントの全ての置き換えを避けるための重要なものとなります。

その他のガバナンスアクティビティとの関係

サービスガバナンスは、エンタープライズアーキテクチャグループによって導かれるより広範なITガバナンスアクティビティの一部としての新しいタイプのガバナンスです。ITガバナンスはSOAプラットフォームガバナンス自体をコントロールし続けなければなりません。何故なら、サービスガバナンスが、エンタープライズ、サービスリアライゼーション、ソリューションデリバリーのレベルで再利用するためのサービスの設計に関するアクティビティにフォーカスしなければならないからです(図3)。エンタープライズレベルにおいては、サービスガバナンスは、ITガバナンスと密に作業しなければなりません。何故なら、トップダウン分析に基づくサービス候補の特定を支援するための企業のビジネスプロセスを取り入れ、これらのサービスのデプロイメントに対するロードマップを確立するためです。先にプロセスの節で見たように、サービスレベルはSOAガバナンスが行うアクティビティが大部分です。これらのアクティビティの全てが、レジストリとリポジトリによってサポートされています。

ソリューションレベルにおいては、サービスのガバナンス組織は、SOAのインフラストラクチャとサービスガイドラインに関係するコンプライアンスレベルを、評価・指示しなければなりません。　

サービスガバナンスは、エンタープライズリファレンスデータモデルの利用を通して、データガバナンスとの強い関係を持っています。サービスのガバナンスチームは、オペレーションメッセージタイプの設計のために、リファレンスデータモデルのセマンティクスを利用しなければなりません。

ここでのゴールは、「標準的な情報モデル」をつくることではありません。サービス指向アーキテクチャにおいて、コンシューマが常にプロバイダーの考えを採用する立場にいるだろう、若しくは、プロバイダーとコンシューマが常に同じ考えを採用するだろうという考えは、単純であるように思われます。たとえこれが今日真実だったとしても、時間が経てばコンシューマとプロバイダはより新しいバージョンのインターフェース(前方互換、若しくは後方互換)により、同時に進展する立場にいないかもしれません。

図3. SOAガバナンスとその他のガバナンスアクティビティの関係

この互いに異なる進展は、大抵はメディエータを使用して取り扱われ、メッセージの変換に利用されます。たとえメディエーションがW3Cのウェブサービスアーキテクチャ(参考資料5)で明確になってないとしても、SOAを実践する人たちは、高レベルな疎結合をし、コンシューマとプロバイダ間の自律的な発展を可能にするために、随分昔に体系的にそれを使用しました。これらの変換は必然のものであり、SOAインフラストラクチャに組み込まれなければならないものです。ついでに言えば、メディエーションは「共通の情報モデル」を必要としません。もし、プロバイダやコンシューマのインターフェースから独立した「共通の情報モデル」を利用し、なおかつ疎結合にしたいのであれば、2つの変換によるコストを被ることになるでしょう。言うまでも無いことですが、プロバイダとコンシューマの実装において、メッセージフォーマットをコンシューマ用のデータセットに変換する必要があります。

管理可能な変換に関して、まず第一に参照データモデルからコンシューマとプロバイダのインターフェースを抽出します。リファレンスデータモデルにおいては、データ構造はセマンティクスの正規化よりは重要ではありません。これらのセマンティクスは、データガバナンスによりしっかりとした精度で管理されます。通常、参照データモデルにより、データベーススキーマやCOBOLが本をコピーするように、物理的なアーティファクトのトレーサビリティを確立します。このトレーサビリティは、サービスを実装している間、非常に便利なものであることが分かります。何故なら、正規化されたセマンティクスの利用でコンシューマとプロバイダ間の変換マップの開発がシンプルなものとなるからです。

結論

サービスガバナンスは、成功するサービス指向アーキテクチャにおける重要な側面を持っています。その設立は予め計画され、SOAの初期段階の早い時期に試験されるべきものです。一方で、厳格なプロセスによって駆動するフルスケールのガバナンス組織は、サービスパイプラインがチームのモチベーションを保つのに十分の大きさで、それに精通しているときだけ稼動するべきなのです。もし、ガバナンスのアクティビティがあまりに距離をおかれているならば、そのチームはアクティビティを適切に実行するために必要となる重要な知識や興味を失うかもしれません。レジストリとリポジトリは、「サービスレコード」を管理しガバナンスを成功に導くための重要な鍵となります。サービスガバナンスの究極のゴールは、仕様、実装、オペレーションにおいてIT資産の再利用を可能にすることです。将来的には、ミッションクリティカルなサービスの実行を積極的に試みるようになることを期待します。

参考資料

1. S. Tilkov "Roles in SOA Governance"
2. J.J. Dubray "W3C Published an Update to Guide to Versioning XML Schema 1.1",
3. J. Dodd et al "CBDI-SAETM META MODEL FOR SOA VERSION 2.0", (メンバー登録が必要になります), Everware-CBDI Inc.
4. webMethods, "SOA Governance, Enabling Sustainable Success with SOA", White Paper, October 2006
5. D. Booth et al "Web Services Architecture", W3C,

原文はこちらです：http://www.infoq.com/articles/soa-governance-organization