はじめに
サービスは、出荷サービスのような物理的なものであっても、ソフトウェアエージェントによって実装されていても、可能な限り多くの消費者が再利用できるように常に設計され、洗練されています。 これがサービス指向アーキテクチャの本質であり、多くの場合、設計時に未知の状況で再利用できるようにIT資産をファクタリングして実装することに このようなSOAガバナンスは、情報モデルを設計したり、特定のプロジェクトの境界を超えて再利用できる技術を選択することを目的とするデータやIT すべての予見可能な消費者は、サービス所有者が割り当てられ、資金調達モデルが定義されている間に、その後に優先順位が付けられ、段階的に設定された要件を表現することができなければなりません。
以前の記事では、STEFAN TilkovはSOAガバナンスにおける役割をより具体的に見ました(1)。 ここでの私の目標は、人、プロセス、技術の面でサービスガバナンス組織を確立するのを助けることです。
サービスガバナンス憲章
サービスガバナンスの主な目的は、再利用可能なエンタープライズクラスのサービスの作成を促進することにより、サービス指向 機能横断的な組織として、サービスガバナンスは、共有要件が定義されているときに行われる必要なトレードオフのために、問題や競合のタイムリーな解
特に、サービスガバナンス組織は、明確なサービス所有権の境界を定義し、公正な資金調達モデルを指定するためにチャーターされています。
サービスガバナンスは、組織全体のサービスの展開と再利用を監視します。 高度なサービスの再利用、エンタープライズクラスのサービス展開の安定した流れ、トラブルフリーのサービスの退職は、ガバナンスの成功の指標です。
サービスガバナンスは、従来のITガバナンスやエンタープライズアーキテクチャと重複すべきではありません; 彼らは、SOA技術の標準とSOA成熟度の向上をリードするロードマップを定義し、サービスガバナンス組織はサービスランドスケープの進化を任務としています。
一般に、サービスガバナンスの役割は受動的であり、特定のプロジェクトまたはビジネスユニットレベルで特定されたサービス候補を処理します。 サービスガバナンスがエンタープライズサービスの体系的なトップダウン識別を開始し、プロジェクトとは無関係にその実現を憲章するのは、組織が高
いずれにしても、ガバナンス組織は、最初にサービス候補を消費するプロジェクトの予算とリソースの制限とは無関係に、エンタープライズサービスを構築 その理由は、再利用性は通常、より高い値札に変換されるより大きな範囲が付属しているためです。
ガバナンス組織は、企業資産として管理されることが期待されるサービス定義のスチュワードです。 また、ビジネスプロセスモデルや参照データモデルなどの他の企業資産とのトレーサビリティとコンプライアンスを維持する責任もあります。 ドキュメントの最後のセクションでは、参照モデルまたはエンタープライズデータモデルとの関係に戻ります。
People
前述の記事では、サービス実装の観点からサービスガバナンス活動に関与するroles1について説明しました。 組織がサービス指向アーキテクチャを開始しているとき、これらの役割は、特にSOA Center of Excellenceに属している場合、エンタープライズクラスのサービスの提供を保証す
| ロール | 説明 |
| ビジネスサービスの所有者 |
|
| 技術サービスの所有者 |
|
| SOAプラットフォームアーキテクト |
|
| サービス 開発者 |
|
組織が成熟し、サービス候補者の数が増えるにつれて、ガバナンス活動が適切に実行され、問題がタイムリーに解決されるように、プロセスとリソースを所有 彼は、機能横断的なガバナンス評議会とサービス司書によって支援されるべきである。
| ロール | 説明 |
| ガバナンスリード |
|
| ガバナンス・カウンシル |
|
| サービス司書 |
|
サービスガバナンス組織に関しては、成熟度の三つの主要なレベルが見られます。
| 成熟度レベル | 組織 |
| 設立 |
|
|
|
| 最適化された |
|
図1は、サービスガバナンスに関係するロール間の相互作用の一部を表しています。
図1. 異なるガバナンス構成要素間の相互作用
成功したサービスガバナンス組織を構築する上での鍵は、アジャイルであり、ニーズを満たすのに十分なリソー サービス候補者の合理的なパイプラインのない大規模なサービスガバナンス組織は、すぐに蒸気を失い、いくつかのサービス候補者に適切なフィードバッ
あなたは、サービスの再利用を促進する組織を構築したいと思っています。
プロセス
プロセスと活動
SOAガバナンス組織によって実行される活動には、五つのタイプがあります:
- サービス候補管理
- サービス変更管理
- サービス消費者管理
- サービスロードマップ管理
- SOAガバナンスポリシーの変更
図2は、サービス候補管理プロセ プロジェクトチームは、サービスを識別し、サービス提案を作成することができます。 この提案は、このサービス候補が企業の他の部分によって潜在的に再利用可能ではない場合に、承認されるか、変更で承認されるか、または拒否されます（
サービス候補が受け入れられると、所有権と資金調達モデルが定義され、サービス所有者と潜在的な消費者の助けを借りてSlaとOlaが指定されます。
サービスが実現されると、そのメタデータがレジストリとリポジトリに公開されます。 大規模な組織では、同時のサービス提案を避けるために、建設中のサービスを追跡することをお勧めします。
変更管理アクティビティは、多くの場合、サービス候補レビュー中に実行されるアクティビティと同じです。 サービスの所有権、資金調達モデル、Sla/OLAs仕様などのアクティビティは任意である場合があります。
変更管理の重要な側面の1つは、転送互換性のあるサービスの効果的な管理です(2)。
サービス消費者管理アクティビティは、この新しい消費者がサービスを利用できるようにするために必要な変更がない限り、ほとんどの場合、サービス 司書は、サービス消費者が対象サービスを識別し、そのメタデータのコピーを取得するのを助けることができる。
サービスロードマップ管理活動は、サービスガバナンスが特定のプロジェクト要求なしにサービスを識別するために積極的に行動する場合に提供されます。 その時点で、サービスガバナンスは、それらを消費するプロジェクトに先んじて、これらのサービスの開発を委託する予算を持つ必要があります。 再利用可能なサービスの設計と実装は、特定のプロジェクトの範囲、手段、スケジュールをはるかに超えている可能性があるため、これはガバナンスの重要な成功要因です。 ガバナンス活動自体には時間がかかり、サービス候補者に長時間のアップグレードを推奨するかもしれません。 このため、ガバナンス組織がスケジュールを管理し、消費者固有の要件を適時に段階化し、ソリューションの配信スケジュールの影響を最小限に抑えることが非常に重要です。
図2。 サービス候補管理活動
最後に、ガバナンス組織は、itガバナンスに従事して、運用ポリシーを定義または変更することができます。
サービスメタデータ
サービス候補提案には、サービスインターフェイスの説明(必ずしも機械可読形式ではありません)と、SlaおよびOlaを定義するために使用されるサービスに関連するすべての機能要件および非機能要件が含まれています。 CBDI Forum Service Architecture&Engineering meta model for SOA(3)は、ライフサイクルの初期段階でキャプチャされ、時間の経過とともに洗練されたサービスに関連する情報を良好に表示します。
CBDI Forum SAETMメタモデルには、提案された運用、ポリシー、および関連サービス、およびサービス分類を含むサービス定義が含まれています。 CBDIフォーラムでは、ビジネスプロセス、ビジネス能力、ビジネスルールを関連させるビジネスレベルのサービス定義を含めることも推奨されています。.. サービス定義に。
このすべての情報は、消費者が特定のサービスを検索しているときに潜在的に使用される可能性があります。 このため、WSDLなどの機械可読記述標準がこのタイプの情報を（まだ）サポートしていない場合でも、構造化された方法でキャプチャすることが重要です。
CBDI Forum SAE™メタモデルは、サービス仕様のための別のセクションを提供します。 メタモデルのこの部分の興味深い点は、操作引数としてサービスに関与する情報タイプを追跡することです。 たとえば、操作呼び出しの一部として交換されるビジネスタイプの表現のみを定義し、ビジネスタイプ自体を定義しないWSDLでは、この機能は十分にサポー
情報型のトレーサビリティは、操作固有のセマンティクスの導入を妨げるため、重要です。 メッセージタイプは、常に参照データモデルと密接に関連して定義する必要があります。 実際、SOAガバナンスプロセスは、参照データモデルと比較して、メッセージ型に追加のセマンティクスが定義されていないことを確認する必要があります。
CBDI Forum 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のwebサービスアーキテクチャ(5)では仲介は明示的ではありませんが、SOAの実務家は、より高いレベルの疎結合を達成し、消費者とプロバイダの間の自律的な進化を可能にするために、それを体系的に使用してきました。 これらの変換は避けられず、この機能はSOAインフラストラクチャに組み込まれる必要があります。 ちなみに、調停には「共通情報モデル」は必要ありません。 このような”共通情報モデル”をプロバイダーとコンシューマーインターフェイスとは無関係に使用し、疎結合を実現したい場合は、メッセージ形式をプロバイダーとコンシューマーの実装によって消耗可能なデータセットに変換する必要があることはもちろんのこと、二つの変換のコストが発生することになります。
より管理しやすい変換に向けた最初のステップは、参照データモデルからコンシューマーインタフェースとプロバイダインタフェースを導出するこ 参照データモデルでは、データ構造はセマンティクスの正規化よりも重要ではありません。 これらのセマンティクスは、データガバナンスによって非常に高精度に管理されます。 通常、参照データ-モデルは、データベース-スキーマやCOBOLコピー-ブックなどの物理的な成果物へのトレーサビリティを確立します。 このトレーサビリティは、サービスの実装中に非常に便利であることが証明されますが、正規化されたセマンティクスを使用すると、消費者とプロバイダ
結論
サービスガバナンスは、成功したサービス指向アーキテクチャの不可欠な側面です。 その設立は、SOAイニシアチブの初期段階の早い段階で計画され、テストされなければなりません。 しかし、厳格なプロセスによって推進される本格的なガバナンス組織は、サービスパイプラインがチームのやる気と知識を維持するのに十分な大きさ ガバナンス活動が時間内にあまりにも遠い場合、チームはその活動を適切に実行するための関心と重要な知識を失う可能性があります。 レジストリ&リポジトリは、”サービスレコード”を管理するためのガバナンスを成功させるための重要な要素です。 サービスガバナンスの究極の目標は、再利用可能なIT資産の仕様、実現、運用を可能にすることです。 残業サービスガバナンスは、ミッションクリティカルなサービスの実装を委託する際に、より積極的になるように進化することが期待されています。