InfoQに掲載した論文「Contract Versioning, Compatibility & Composability」（コントラクトのバージョニング、互換性＆コンポーザビリティ〔組み立て可能性〕）(参考記事)は、デザインタイム、ランタイムの設計ならびにガバナンスの両側面を含め、SOAの広範囲にわたる側面を取り扱っています。今回の論文では、バージョニングの論文で推奨されているコントラクトの設計ポリシーが、SOAの成熟度モデルにいかに関係しているかを示すことを目的としています。この関係により、InfoQの論文で説明しているコントラクトバージョニングおよびコンポーザビリティの完全な特徴集合を達成する方法を示したロードマップが明らかになります。ポリシーについてはここでは敢えて取り上げていません。
MicrosoftはSOA Maturity Model（SOAMM＝SOA成熟度モデル）(PDF)を用いて顧客のSOA導入状態を査定し、SOAが約束するビジネスアジリティを実現する位置へ到達するためのロードマップを提供します。SOAMMはCMMに基づいており、SOAMMには成熟度合いに応じて４つのレベルがあります。
- Basic（基本）
- Standardized（標準化）
- Advanced（上級）
- Dynamic（動的）
SOAMMは技術に依存しない36の能力で構成されており、何が可能で、サービス指向アプローチの価値を実現する上でITシステムに何が必要かを示す案内書的な役割を果たします。このモデルはMicrosoftのプロダクトチーム、専門家のエバンジェリスト、我が社の顧客の協力を得て開発されたものであり、我が社の世界的なベストプラクティスを基にしています。
能力は3つの観点からグループ分けされています。
Service Implementation（サービスの実装）
このモデルの観点は、サービスの構築・供給パターンにおいて効率的なベストプラクティスを実装する企業の能力を説明します。この能力を手に入れることにより、企業のビジネスサービスとシステムサービスの設計ならびに開発の強化と最適化につながります。
Service Consumption（サービスの消費）
このモデルの観点は、企業が効果的にサービスの利用を採用・実行し、促進する能力を説明します。この能力は、他の人々が企業のサービスを消費することに対して、サポートし、改良する基礎を提供します。
Service Administration （サービスの管理）
このモデルの観点は、サービスの企業間ガバナンスとオペレーションの側面を支援する企業の能力を説明します。
SOAイニシアティブの目標を、選択した能力のレベル3や4に定めることはできますが、関連する基礎部分のレベル1と2をすでに備えていない限り、基礎がもろいシステムを構築する危険があります — そして、推奨のプラクティスと提携するには、サービスアーキテクチャの大規模な再構築と書き直しがいつかは必要になるでしょう。
Basic Maturity Level（基本の成熟度）
調査によると、企業のおよそ82%がこのレベルのSOA成熟度にあることがわかっています。貴社が基本レベルの成熟度でもがっかりしないでください。SOAの取り組みを始めたばかりの場合や、サービスの数がわずかしかない場合は、このレベルにいてもまったく問題ありません。
Explicit Contracts（明確なコントラクト）：
この消費能力は伝統的な４つのSOA教義の1つ、「サービスは実装を共有するのではなく、スキーマとコントラクトを共有しなければならない」に基づいています。サービスとスキーマ（メッセージとデータ）のためのコントラクトは、SOAシステムによるサポートが意図されているビジネス能力ならびに関連するビジネス文書に基づいていなければなりません。コントラクトは決して、RPCベースのオブジェクトモデルを薄いラッパーで包んだだけのものであってはならず、それよりもむしろ、InfoQの論文で示されているような論理的データモデルを使ったサービスインターフェースに基づいた、サービス指向のメッセージングを使用する必要があります。
この基本能力はお勧めの出発点であり、標準化されたコントラクト設計ポリシーや共通の情報モデルの使用へと短時間で発展します（「Design Patterns」〔設計パターン〕、「Uniform Contracts」〔均一のコントラクト〕、「Common Entities」〔共通エンティティ〕、「Consumable Type System」〔消費可能の型システム〕をご覧ください）。
Service Identification（サービス識別）（サービスを促進する）：
このConsumption（消費）能力は、Standardized（標準化）成熟度に属する「Service Discoverability」（サービスを発見する）能力の基本的な変形であり、つまり、潜在的な消費者に対するサービスメタデータの典型的な手動配信のことです。
InfoQの論文で説明したように、サービス発見力はサービス組み立ての中核をなします。サービスメタデータは、機械で読み取り可能なメタデータと、サービス記述やSLAなどのその他の関連情報の両方で構成されます。バージョニングの論文で説明したように、両タイプのメタデータともバージョニングポリシーに従わなくてはなりません。
サービス指向のモデリング設計タスクservice identification（サービス識別）(リンク)が「Service Boundaries」（サービス境界）能力の一部であることにご留意ください。
Service Boundaries（サービス境界）：
このConsumption（消費）能力は、ビジネスプロセス・モデリングとドメイン駆動設計のモデリングテクニックを応用してビジネス能力をサービスへとグループ化することを通じて、発見力と再利用を可能にすることを真の目的としています。潜在消費者がコントラクトメタデータを通じて、ニーズを最もよく満たすのはどのサービスや能力かを見分けられるようにすることです。
識別されたサービス境界（ドメイン）をサービスモデルおよびデータモデルと組み合わせて、標準化されたサービスコントラクトへ発展させるべきです（「Enterprise Governance」〔企業ガバナンス〕、「Uniform Contracts」〔均一のコントラクト〕、「Common Entities」〔共通エンティティ〕、「Consumable Type System」〔消費可能の型システム〕をご覧ください）。
この能力はImplementation（実装）ではなくConsumption（消費）と分類されていますが、Thomas Erlの有名な著書「SOA Principles of Service Design」（サービス設計に関するSOAの原則）(リンク)の中でいう「サービスの疎結合」の原則を順守するためです。ベストプラクティスは、サービスインターフェースとスキーマが、基礎をなす実装と技術に緊密に結合しないようにすることです。コントラクトファーストの設計が好まれるという強い徴候でもあります。
Development Process Efficiency（開発プロセスの効率）：
この能力は推奨のコントラクト設計ポリシーにサポートされています（SOAMMの図では点線の楕円で表示）。
この能力は推奨のコントラクト設計ポリシーにサポートされています（SOAMMの図では点線の楕円で表示）。
サービスの設計、実装、発展のプロセスは、適用可能なツールのサポートを受けた、明確なソフトウェア開発ライフサイクル（SDLC＝software development lifecycle）に従わなくてはなりません。SDLCモデルはまったくの初期から用意されていなければなりませんが、成熟度の向上に応じて、他のSOA能力が定義するガイドラインやポリシーの恩恵を受けることになります（「Design Patterns」〔設計パターン〕をご覧ください）。
他の能力の発達により開発プロセスの効率が改善するのと並行して、この基本能力を再考してください。たとえば、必要とされているビジネス能力を提供することを目的とした、新しいサービス活動の設計、実装、デプロイに要する時間と取り組みは、標準化されたコントラクトの設計ガイドライン、共通の情報モデル、サービス抽象化と疎結合のポリシー、明確なテストならびにデプロイメントプロセスを用意することにより、恩恵を受けます。
Standadized Maturity Level（標準化された成熟度）
より多くのビジネス能力を提供するという要求を満たすためにサービスの数がますます増加するにつれて、貴社の SOAアーキテクチャおよび設計プラクティスに標準化された成熟度の能力を組み入れるよう強くお勧めします。
Enterprise Governance（企業ガバナンス）：
サービスモデルは、常に分類学に従ってサービスを分類すべきです。さらに、スキーマの根拠となっているドメインデータモデルを作成し、使用するよう強くお勧めします。このようなデータモデルはCommon Information Model (CIM)と呼ばれています。「Common Entities」（共通エンティティ）もご覧ください。
デザインタイムガバナンスの側面に加えて、サービスバージョニングに関連したランタイムガバナンスの側面を「Deployment Management」（デプロイメント管理）および「Advanced Monitoring」（上級モニタリング）能力の項で取り扱います。
Uniform Contracts（均一のコントラクト）：
このConsumption（消費）能力は「標準化されたサービスコントラクト」の原則と同じです。コントラクトアーチファクト向けに、基本能力の「Explicit Contracts」（明確なコントラクト）を標準化された均一の設計ポリシーを使って拡張します。標準化されたコントラクトの所有は、潜在消費者によるサービスの発見、識別、使用をたやすくする上で重要です。ちょうどThomas Erlが共通データモデルの使用を勧めているように、この能力はImplementation（実装）能力の「Common Entities」（共通エンティティ）と密接に関係しています。
Service Discoverability（サービス発見力）：
「Service Discoverability」（サービス発見力）はSOAの主な原則の1つです。InfoQの論文で説明したように、再使用可能性を目的に設計されているサービスやスキーマに組み立てが依存しているだけではなく、サービスやスキーマは潜在消費者が簡単に見つけられるようになっていなければなりません。サービスインベントリ管理システムとしてリポジトリを使うようお勧めします。リポジトリはSOAガバナンスツールとレジストリ発行メカニズムをもたらします。
Service Discoverability（サービス発見力）は、コントラクトの数とコントラクトのバージョンの数を低く抑えておくために重要であり、サービスの開発とオペレーションの両方に役立ちます。サービスやスキーマといったコントラクトのメタデータアーチファクトのバージョン管理とガバナンスを行うよう、強くお勧めします。InfoQの論文で一番お伝えしたい点はここです。
Loosely-Coupled Compositions（疎結合の組み立て）
このImplementation（実装）能力は、関連する「サービスの疎結合」の原則を「Service posability」（サービスposability）の原則と混ぜ合わせているので、多少、誤った呼び方のように思えます。疎結合は「サービスの抽象化」「サービスの再使用可能性」の原則と合わせて、組み立て可能なサービスを実現可能にする重要なものです。InfoQの論文のデータモデルの項で指摘しているように、スキーマ設計時には（そしてサービス設計時にも）、疎結合の達成に努力せねばならず、基礎をなしている論理やシステムの実装の詳細をコントラクトの中で公開してはなりません。
再使用可能性を目的とした設計や、バージョニングおよび互換性ポリシーの保有は、コンポーザビリティを達成する上で重要です。再使用と再使用可能性の区別にご留意ください。サービスを（再）使用するかもしれない、広範囲にわたる将来の潜在消費者向けに、不確かなコントラクトを設計してみるようなことはしないでください。それよりもむしろ、サービスが複合サービスや複合プロセスの模範的な構成要素になるように、サービスを設計してください — これが再使用可能性です。複数の消費者が供給されたサービスを共有できるなら、それはもちろん有益です。
Design Patterns（設計パターン）：
このImplementation（実装）能力は、基本能力の「Development Process Efficiency」（開発プロセスの効率）と密接な関係にあります。成熟度が発達して「Uniform Contracts」（均一のコントラクト）や「Common Entities」（共通エンティティ）、「Consumable Type System」（消費可能の型システム）といった原則を利用するようになると、それに伴って識別されたガイドラインやポリシーをSOAガバナンスの設計ポリシーの一環として定義し、実施しなくてはなりません。共通した設計パターンの利用は、SOAの原則「標準化されたサービスコントラクト」の順守を可能にする上で重要です。
Common Entities（共通エンティティ）：
このImplementation（実装）能力は、企業全域にわたってビジネスプロセスで使われるデータに共通のフォーマットを使うことを目的としています。こうした企業データモデルには様々な名称がありますが、最もよく知られた名称はCommon Information Model（CIM）のようです。gor HohpeとBobby Woolfが有名な著書「Enterprise Integration Patterns」(リンク)の中でEAIのCanonical Data Model（CDM）を定義していますが、CDMのサービス指向における兄弟がCIMというわけです。
CIMを採用するからといって、それが、全システムにわたって「1つの真のスキーマ」モデルの実施を試みよ、という推奨につながるとは解釈しないでください。それよりもむしろ、ドメイン駆動設計のアプローチに基づいたCIMの連合モデルを複数使用しましょう。
InfoQの論文で説明しているように、データモデルは、サービスプロセスやビジネスプロセスの始めから終わりまでを流れるスキーマを作成し、維持するための基礎です。メッセージスキーマとデータスキーマは両方とも、データモデルに基づいていなければなりません — メッセージスキーマは1つ以上のデータスキーマの予測です。データスキーマは再利用を目的に設計しなくてはなりませんが、その一方でメッセージスキーマは意図的にオペレーションに特異的になります。このモデリング概念は、Advanced（上級）成熟度の「Consumable Type System」（消費可能の型システム）能力の一部です。
Advanced Maturity Level（上級成熟度）
どのようなソフトウェアシステムでもわかりきっているのは、唯一普遍なのは変化、ということです。ビジネス要件が変われば、サービスは進化せざるを得ず、その結果、SOAアーキテクチャと設計プラクティスにサービスライフサイクル管理（SLM＝Service Lifecycle Management）能力を組み入れることになります。
Deployment Management（デプロイメント管理）：
サービスライフサイクル管理はSOAガバナンスの中枢部分です。SLMにはデザインタイムとランタイムの両側面があります。バージョニングと併せて、 SLMはAdministration（管理）における「Deployment Management」（デプロイメント管理）能力の中核です。SDLCプロセスには、既存サービスの廃止方法に加えて、新サービスならびにサービスの新バージョンのデプロイ方法を示す明確なモデルが必要です。
「Deployment Management」（デプロイメント管理）は「Enterprise Governance」（企業ガバナンス）能力と組み合わせて、SLMのソフト面においてサービスインベントリ・スチュワード（管理人）を支援しなくてはなりません。たとえば、影響を受ける消費者にサービスライフサイクルの変更を連絡する、などといったことです。
InfoQの論文では、サービス仮想化メカニズムの一部として選択したエンタープライズ・サービス・バスのパターンと組み合わせ、この能力の一環として「使用中のサービスバージョン」ポリシーを持つことを勧めています。サービス仮想化の詳細については、論文をご覧ください。
Advanced Monitoring（上級モニタリング）：
この能力は推奨のコントラクトライフサイクル・ポリシーをサポートします（SOAMMの図では点線の楕円で表示）。
サービスライフサイクル管理モデルの一部として、個々のサービスをすべてモニターし、サービスインベントリ・スチュワード（管理人）がサービスの使用法を把握できるようにするべきです。新バージョンの導入時、適切な消費者に「廃止予定、もしくは廃止されたサービスを使用しているので、アップグレードの必要がある」とスチュワードから連絡させることにより、スチュワードの仕事を援助することになります。
Consumable Type System（消費可能の型システム）：
このImplementation（実装）能力は、SOAエコシステムにおける全構成要素 — サービス、エンティティ、プロセス、ルール、実装、ポリシー、バインディング、その他のサービス構成要素 — について消費可能性の定義を保有することを目的としています。
「Common Entities」（共通エンティティ）のスキーマを定義する共通の情報モデルは、この型システムに不可欠な部分になるでしょう。サービスやプロセスで使われるメッセージスキーマとデータスキーマもまた、この型システムの一部でなければなりません。
これまでメタデータリポジトリを使わずに何とかやってきた場合でも、この能力がきっかけとなって、メタデータリポジトリを利用する必要性が出てくるでしょう。開発効率や発見力および再利用、バージョニング、インパクト解析、可視性といった構成要素の発展を促進していかに利用するかという点で、リポジトリが必要です。たとえば、共通エンティティがサービスやメッセージのどこで使われるかを確認できるようになります。
リポジトリは、共通エンティティをモデル化するにも、関連したメッセージスキーマやデータスキーマのモデル化においても、うってつけのソースとなるでしょう。単一のソースからコントラクトスキーマの全アーチファクトを生成すれば、スキーマの互換性とサービスコンポーザビリティに役立つでしょう。コントラクトスキーマ・アーチファクトのモデル化の詳細については、InfoQの論文をご覧ください。
Versioning Support（バージョニングサポート）：
コントラクトは進化してビジネスニーズの変化に順応する必要がありますが、これはサービスとスキーマの両方に影響を与えます。SOAシステムが発展、変化するにつれて、サービスインターフェースや、メッセージスキーマおよびデータスキーマ、ポリシーなどを含め、すべてのコントラクトアーチファクトにバージョニングが必要なことがおわかりになるでしょう。バージョニングポリシーにはデザインタイムとランタイムの両側面が含まれなくてはならず、SOAガバナンスを通じて実施されなければなりません。このAdvanced（上級）能力の実装方法の詳細については、InfoQ掲載の論文「Contract Versioning, Compatibility & Composability」(参考記事)をガイドラインとしてお読みになるようお勧めします。
SOAMMでは「Versioning Support」（バージョニングサポート）がAdvanced（上級）能力になっていても、Service Lifecycle Management（サービスライフサイクル管理）の実行と密接な関係にあるため、できるだけ早い時期に互換性を目指してコントラクトの設計を始めるよう、強くお勧めしていることにご留意ください。サービスとスキーマの互換性ポリシーを持っておくことは、本格的なバージョニングとSLM能力を実行することに依存しません。同一サービスの数（同一サービスの変形が単に複数存在すること）が原因で、消費者やオペレーション、プロバイダのメンテナンスに支障をきたすようになったら、バージョニングが必要です。長期的に見ると、使用中のサービスのバージョン数が増えるに従って、バージョニングとSLMガバナンスが存在しなければ、サービスインベントリは完全な混乱に陥るでしょう。
このコントラクト成熟度への移行を回避しようと、多数の人々がワイルドカードを大量に使用してバージョニングを回避します。これによってセマンティクスがあまり適切に表現されていない、曖昧なコントラクトがもたらされることになり、サービス発見力が無効になるので、絶対にお勧めできません。しかし、明確なワイルドカードを賢く利用すれば、スキーマ互換性が提供されるため、サービスバージョニングを最小にとどめるのに役立てることができます。
バージョニングにより、変更の効果を制御できます。互換性は、バージョニングの悪影響を多少軽減させるのに役立ちます。
Dynamic Maturity Level（動的成熟度）
最近では、SOAが約束する主な有用性がサービスの再利用からビジネスアジリティへと変わりました。動的成熟度は、ビジネス要件の変化に応じて、サービスインベントリから構築されたプロセスの迅速なモデル化、組み立て、変更を可能にすることを目的としています。
Progressive Composition（漸進的組み立て）：
この能力は、推奨のコントラクト設計ポリシーによってサポートされています（SOAMMの図では点線の楕円で表示）。
サービスインベントリのサービスは「サービスコンポーザビリティ」の原則に従って設計されなければならず、サービスモデルとデータモデルを有するという推奨を固守し、SOAガバナンスを通じて実施されるその他の推奨設計ガイドラインとポリシーを順守しなければなりません。
基礎的な能力が備わっているならば、ビジネスニーズに応じて、複合サービスとオーケストレーションを実装する準備ができているということです。互換性があり、かつ連合した情報モデルに基づいてバージョン管理したサービスとスキーマが用意できているということは、サービスを漸進的に組み立てられることである、と私は断言します。
推奨のコントラクト設計ポリシーに従って設計されていないサービスを組み立てようと試みても、難しいでしょう。 たとえば、プロセスの段階を登っていくときに、異なるフォーマット間でメッセージのデータを変換するという余分な労力が必要となります。サービスコンポーザビリティを目指して設計することで、エンタープライズ・サービス・バス（ESB）の複雑なパターンの使用や、本格的なESBプラットフォームへの投資の必要性を減じることができるでしょう。
このDynamic Implementation（動的な実装）能力は、ビジネスプロセスの組み立てと実行のためのプラットフォームを提供します。
Process Modeling Support（プロセスモデリング・サポート）
この能力は、推奨のコントラクト設計ポリシーによってサポートされています（SOAMMの図では点線の楕円で表示）。
このDynamic Implementation（動的な実装）能力は、インベントリからプロセスやワークフローへと、サービスのモデリングをサポートすることを目的としています。プロセスフロー向けの決定ルールのモデリングも含まれます。組織内で適切な職務にあるものが、自らが責任を負うビジネス能力やビジネスプロセスを定義し、管理できるようにするために必要なツールが、この能力により提供されます。たとえばBPMNのダイアグラムやUMLのアクティビティ・ダイアグラムを使用したモデリングプロセスは、組み立て可能なサービスと互換性のあるデータモデルを併せ持ったインベントリがあれば、容易になります。
ポリシーはモデル化されたプロセスにも適用できます。こうしたポリシーは、たとえば許可チェックや、機密性ならびに整合性の要件、ビジネスアクティビティ・モニタリング（BAM＝Business Activity Monitoring）のロギングのことであり、ビジネスプロセスのパフォーマンスを可視化するためのものです（KPIs）。規則駆動型の動的ポリシーのモデル化は、これとは別の能力であることにご留意ください
結論
この論文で示したように、コントラクトバージョニングとコンポーザビリティの側面はSOA成熟度の全能力に及びます。しかし、大改革のアプローチをとって、様々な全能力を一度に網羅しようと試みる必要はありません − Basic（基本）から小さく始めて、サービスの数が増加するにつれて、Standardized（標準化）へのステップアップを目指してください。これにはSOAガバナンスの必要性が同時発生しなければなりません。実際、標準化されたサービスの実施にはデザインタイムのガバナンスが必要です。
サービスが人気を博し、多数の消費者が共有するようになると、専門的なサービスライフサイクル管理を行うために、バージョニング管理やデプロイメント管理といった、Advanced（上級）成熟度の能力を実装する必要が出てくるしょう。
成熟度の進化に伴い、最終的にはDynamic（動的）成熟度に到達する可能性もあり、そうなれば約束されたサービスの再利用やビジネスアジリティをサポートできるようになり — SOAの名高い恩恵に手が届くようになるのです。
原文はこちらです：http://www.infoq.com/articles/soa-contract-maturity-model