組織はビジネスと IT の両方にとって重要な判断を下すための指針として、ポリシーを使用します。多くの場合、ポリシーは何らかのマイナスの事態が発生した結果として後から作成されます。SOA Policy Reference Architecture には、実務者が先を見越してポリシーを作成して管理する方法が、ポリシーの管理機能や自動化機能を含めて示されています。この記事およびその詳細な添付資料では、ポリシーを定義するためのフレームワークを提供します。最初にビジネスの目標と目的を定義することから始め、組織を適切に統制するために必要なビジネス・ポリシー、アーキテクチャー・ポリシー、オペレーション・ポリシーにビジネスの目標と目的を落とし込む方法について説明します。そして読者が詳細を理解できるように、SOA Policy Reference Architecture を使用してポリシーを分解する方法の例を取り上げます。

Robert Laird, Executive Architect, IBM  

Robert LairdBob は、IBM SOA Advanced Technology グループのエグゼクティブ・アーキテクトです。2006年以来、SOA ガバナンスおよび SOA アーキテクチャーの分野で世界各国の IBM のお客様のためにコンサルタントを行っています。彼は、IBM SGMM (SOA Governance & Management Method) の作成者の一人であり、TOGAF (The Open Group Architecture Framework) SOA Governance ワーキング・グループのメンバーでもあります。SOA に関する著書には『SOA Governance, Achieving and Sustaining Business and IT Agility』と『Executing SOA, A Practical Guide for the Service Oriented Architect』の 2 冊があり、SOA ガバナンス分野で 2 つの特許を申請中です。彼は MCI と Verizon Business で 20 年間、電気通信業界での経験を積みました。MCI では主任アーキテクトとして、エンタープライズ・アーキテクチャー・グループを先導し、アプリケーション・スイートの全注文に携わりました。また、複数のネットワークおよびアプリケーションのサイロを単純化する、SOA ベースの単一スタック戦略の開発も先導しました。彼は、コンタクト・センター、IP/VPN、VOIP、IMS、および管理対象サービスの分野で、MCI の製品開発の戦略、計画、実行を推進しました。OSS では、ネットワーク・プロビジョニング、ネットワーク・リストア、ネットワーク管理を自動化するための実装を成功に導きました。MCI に入社する以前は、AMS (American Management Systems (AMS) および Ideation, Inc. のコンサルタントを務めていました。彼は、パデュー大学でコンピューター・サイエンスの MS および BS の学位を取得し、テレフォニーの分野で 2 つの特許を持っています。さまざまな業界フォーラムで講演を行っている他、The SOA Magazine に書いた彼の著述は、CIO Insight, Telecommunications、Infoworld、Computerworld で引用されました。



John Falkl, Distinguished Engineer and Chief Architect, SOA Governance, IBM  

FalklJohn Falkl は、IBM Distinguished Engineer の肩書きを持ち、IBM Software Group 内で SOA ガバナンスの主任アーキテクトを務めています。彼の職務には、SOA ガバナンス機能に必要な全体的技術戦略および製品要件を推し進めること、そして IBM の組織全体で SOA ガバナンス・アクティビティーを調整することも含まれます。彼は、IBM Software Group CTO のガバナンス・インキュベーション・プロジェクトのリーダーとして、主要な SOA ガバナンス・プロセスを確立し、ソフトウェア製品戦略をベースラインのユース・ケースに対応させました。IBM に務める 28 年間のうち、12 年間は IBM Global Services に所属し、大きな影響力を与えた数々のプロジェクトを先導しました。最近では、IBM Global Business Services 組織の SOA 管理サービス・オファリングを定義し、開発するプロジェクトのリーダーを務めました。IT 技術において 3 つの業界認定を受けた彼は、エンタープライズ・アーキテクチャーおよび開発で (9 年間の管理経験を含め) かなりの経歴を持っています。IBM 内で、数々の高度な技術研究のリーダーも務めました。



Stephen Cocks, Senior Software Engineer, IBM

Stephen Cocks headshotStephen Cocks は英国 Hursley にある IBM 開発研究所のシニア・ソフトウェア・エンジニアであり、現在は製品チームと共に SOA ポリシー・ベースの機能の定義、構築、実現などを担当しています。彼は 1989年に IBM に入社以来、IBM Business Process Manager、IBM WebSphere Enterprise Service Bus、IBM WebSphere Application Server など、IBM の重要な WebSphere 製品の多くで多様な業務を担当してきました。



Arnaud Le Hors, Software Standards Architect, Linked Data Standards Lead, IBM

Arnaud Le HorsIBM ソフトウェア・スタンダード・グループに所属する Arnaud Le Hors は、IBM が行ういくつかの標準化活動を戦略的かつ技術的観点から調整する業務を行っています。彼は X Consortium と W3C のスタッフ・メンバーとして、また IBM の代表として、オープン・スタンダードに 15 年間携わってきました。そして、標準開発組織の内部および外部から、IBM などの企業に対して、技術的、戦略的、政治的、法的な側面を含め、標準開発プロセスのあらゆる側面に関係してきました。彼は HTML や XML などの標準の開発に参加し、また Apache Software Foundation によって開発された XML パーサー、Xerces の中心的アーキテクトの 1 人でもあります。現在は IBM の Linked Data Standards のリーダーを務めています。



Duncan Clark, IT Architect, IBM

Duncan ClarkDuncan Clark はアーキテクトであり、現在は IBM Operational Decision Management 製品を他の IBM 製品やソリューションと統合するための要件管理を行っています。彼は IBM の Hursley 研究所に所属し、この 1 年間は IBM の ODM、BPM、Tivoli などの製品のデモと統合を担当してきました。そして ILOG 組み込みルールの BPM 7.5 への統合やサポート・パック LA71 の開発を行い、ODM を Business Process Manager と組み合わせて使用するための統合ツールと開発パターンを提供してきました。それ以前は WebSphere Service Registry and Repository チームのアーキテクトとして、WSRR の SOA ガバナンスとポリシー管理の部分を担当していました。



Andy Ritchie, Senior Software Engineer and Architect, IBM

Andy Ritchie は IBM のシニア・ソフトウェア・エンジニア兼アーキテクトであり、BPM と Decision Management の業務に従事しています。彼は主に、さまざまな IBM 製品を使用した共同ソリューションを担当し、IBM のサービス・チームや技術セールス・チームと日常的に協力しながら顧客のソリューションや手法と取り組んでいます。IBM 在籍 27 年を超える彼は、幅広く多様な経験を積んでおり、銀行、小売、通信ソリューションに対する適格性、コンプライアンス、価格決定の判断とルールのための Decision Management に関して、ビジネス・ポリシーとルールを主に担当してきました。また彼は、多様な業界のためのソリューション、IBM SOA ミドルウェアを構築しました。この場合にもポリシーによる SOA サービスのガバナンスが重要です。それ以前は IBM 開発部門に 18 年間在籍し、ISDN、X.25 通信、音声認識製品や音声合成製品に従事していました。



2012年 9月 13日

このドキュメントの使用方法

このドキュメントは SOA Policy Reference Architecture を理解して使用するための簡単なチュートリアルです。詳細な例を含めて SOA Policy Reference Architecture を十分理解するには、「参照資料」セクションに挙げた完全なドキュメントを参照してください。

SOA ポリシーを作成、編集、監督、管理、施行する人々にとってポリシーが果たす典型的な役割を理解するために、以下の図について考えてみてください。

図 1. SOA Policy Reference Architecture を使用する上でのポリシーの役割
SOA ポリシーの役割

SOA Policy Reference Architecture の説明

以下の図に示すように、SOA Policy Reference Architecture とは、ポリシーを使用してサービスを管理する場合のリファレンス・アーキテクチャーです。

図 2. SOA Policy Reference Architecture
ビジネス・ポリシー、アーキテクチャー・ポリシー、オペレーション・ポリシー

SOA Policy Reference Architecture ではポリシーの表現を階層化することで、既存の SOA におけるポリシーおよび人々の役割を表しています。

  • ビジネス層は、ビジネスのニーズを詳細に記述できるビジネス・アナリスト、またはビジネスの代表者が主導する必要があります。
  • アーキテクチャー層は、SOA の完全性に責任を持つアーキテクトが主導する必要があります。
  • オペレーション層は、オペレーション・ポリシーのパターンを実装するランタイム・ポリシーの仕様が反映されます。

ビジネス・ポリシー層

最上位レベルでの抽象化では、ポリシーは特定のビジネス・ニーズを記述したものにすぎません。このレベルでは、ポリシーは通常、自然言語で表現され (例えば英語やフランス語など)、ビジネス・アナリストと IT 専門家との間でのビジネス要件に関するコミュニケーションを行うために使用されます。両者が協力作業を開始すると、このビジネス・ポリシーは組織全体でビジネス要件をどう実装し、どう施行するかの詳細を定義する一連の目的、戦略、戦術に分解されます。

これらのビジネス・ポリシーは、ポリシーの適用対象となるビジネス・ソリューションのコンテキストで定義する必要があります。サービスによって提供されるビジネス機能は、追跡できるようにするのが通常なので、ビジネス・ポリシーを適用する必要があるサービスに対しては大抵、即座にビジネス・ポリシーを関連付けることができます。

ビジネス要件が分解され、一連のサービスに適用可能なポリシーになった段階で、アーキテクチャー・ポリシー層を使用して、これらのポリシーの施行に使用できる共通のパターンを定義します。

アーキテクチャー・ポリシー層

アーキテクチャー・ポリシー層は、企業が採用するアーキテクチャーにポリシーを統合するためのパターンを提供します。ポリシーは (例えば、ビジネス・ルールの中で定義されたポリシーによって価格決定サービスが制御される場合など) サービスの振る舞いに対して適用される場合や、あるサービスを別のサービスが利用する場合に適用されることもあります。

オペレーション・ポリシー層

オペレーション・ポリシー層はデプロイされた製品とソフトウェア・インフラストラクチャーを提供します。このソフトウェア・インフラストラクチャーによってビジネス・ソリューションが実現され、そのソリューションの中でポリシーを使用できるようになります。SOA Policy Reference Architecture は、実際に運用される SOA ソリューションでポリシーをどのように実現するかを記述するコンポーネントをいくつも定義します。

ポリシー・ソリューションの例

以下の図はサービス・レベル管理要件の非常に単純な例を示しています。

図 3. SLA ポリシーをトップ・ダウン方式で分析する場合のポリシー・ツリーの例
ビジネス・ポリシー、アーキテクチャー・ポリシー、オペレーション・ポリシー

ビジネス・ポリシー層のソリューション

ポリシー・ツリー分析は、上位レベルでのビジネス・ポリシー要件 (例えばビジネス・ユーザーやビジネス・アナリストからの要件など) を簡単に記述するところから開始します。次にこの記述を同じくビジネス・レベルで細部まで改善し、ビジネス・ポリシーの要件の意味や、確実にポリシーに準拠するために何を測定する必要があるかなどについて詳細に規定します。

ビジネス・ユーザーとの話し合いを基に、比較的容易にビジネスの趣旨や目標を上位レベルで定義することができます。例えば、「応答時間は顧客のニーズを満たす必要がある」、「顧客の信用リスクが妥当な場合にのみ保険商品を販売する」、「高コストのトランザクションは CFO が承認する必要がある」などが考えられます。

しかしそうすると、さらに詳細な質問が浮かんできます。知識の豊富なアナリストであれば、以下のような質問を開始するかもしれません。

  1. 応答時間の要件は一部の顧客と他の顧客とで異なるのか?
  2. 適切な応答時間はどの程度か?
  3. このポリシーはどのようなソリューション・コンテキストで適用されるのか?
  4. どのようにして信用リスクが妥当であるかどうかを測定するのか?
  5. 保険商品の種類が異なるとリスク・レベルも異なるのか?
  6. コストが高いトランザクションは何か?
  7. コストが高いトランザクションは何であるかには、リスク・レベルが影響するのか?

これらの結果を以下の図のように分解します。

図 4. ビジネス層でポリシーを分解する例
ビジネス・ポリシー層

では、ビジネス層のポリシーを分解し、説明します。

表 1. ビジネスの目標からポリシーを分解する
アクティビティー説明
ビジネスの目標を明らかにするビジネスの目標はビジネスの観点から趣旨を記述したものであり、何をする必要があるかを定義します。応答時間に関する顧客の期待を満たす必要がある。
ポリシー・ディレクティブを導き出すポリシー・ディレクティブはビジネスの目標の趣旨を定義するものであり、ビジネス目標をさらに分解する方法についての指針を提供します。ポリシー・ディレクティブはソリューション・コンテキストのステージや、ポリシー・ドメイン、ソリューション・ポリシー、ガバナンス・ポリシーのステージでもさらに改善されます。顧客にとってのエンド・ツー・エンドの応答時間 (Enter キーを押してから応答を受信するまで) は 3 秒未満でなければならない。
ビジネスの目的を定量化するビジネスの目的は、目標の達成度を追跡するために何を詳細に測定する必要があるかを KPI の形で定義します。KPI 1: 顧客サービスの最大応答時間を測定し、規定時間を超過した場合には運用上非常に重要な警告を発する。
ソリューション・コンテキストのスコープを規定するソリューション・コンテキストは、ビジネスのどこでビジネス・ディレクティブを適用するのかを定義します。ソリューション・コンテキストのスコープは小規模なビジネス機能の範囲内というローカルな場合や、幅広くビジネス全体が対象となる場合があります。フェーズ 1: 銀行 ATM サービスのみ
ポリシー・ドメインを選択する各ドメインでは、一貫性を持ったポリシー定義のために使用すべき共通の語彙を特定します。ビジネス・ポリシーのサブドメインとして、以下のようなドメインを考慮する必要があります。
  1. 状況認識ポリシー (特定の期間にわたって複数のイベント・パターンを検出する、など)
  2. 特定のアクティビティー・ステップでプロセスの動作に影響するビジネス・プロセス・ポリシー
  3. 業界標準やコンプライアンス規制の実装につながる業界特有のポリシー
  4. サービス・レベル管理ポリシー
サービス・レベル管理ポリシー・ドメインを使用する。
ソリューション・ポリシーに分解する対象コンテキストに関する詳細情報が得られたら、ポリシー・ディレクティブをさらに改善する必要があります。すべての銀行 ATM サービスでの利用者の操作に対する応答時間は 3 秒未満でなければならない。
ガバナンス・ポリシーを適用する将来アジャイルな変更を実現できるようにポリシー・ディレクティブを管理する必要があります。これは、どこで SOA ポリシーのライフサイクルを実装するのかに関連しています。マーケティングに分類されたビジネス・ポリシーの作成、更新、削除については、すべてマーケティングに権限がある。

ビジネス層で分解された主な出力のうち、アーキテクチャー層で使用されるものは以下のとおりです。

  • ソリューション・ポリシー: ポリシー・ディレクティブから分解され、ソリューション・コンテキストの影響を受けます。
  • ソリューションの KPI: ポリシー・ディレクティブとビジネスの目的から分解され、ソリューション・コンテキストの影響を受けます。
  • ポリシー・ドメイン: 上記の顧客対応の例で選択されたサービス・レベル管理。

アーキテクチャー・ポリシー層のソリューション

適切なレベルのビジネス・ポリシーが規定されると、それらのポリシーを分解し、ビジネス・ポリシーの実装に必要なアーキテクチャー・ポリシー層のポリシーにすることができます。アーキテクチャー・ポリシーは必要に応じてビジネス・ポリシーを改善することによって高品質設計のソリューションを保証し、また必要な場合には、どのポリシー・パターンを使用してビジネス・ニーズを満たすのかを指定します。

アーキテクチャー層では主に 3 つの概念について考慮する必要があります。これらの概念を以下の図と表で説明します。

図 5. アーキテクチャー層でポリシーを分解する例
アーキテクチャー・ポリシー層

SOA ポリシーのライフサイクルのこの段階については、ビジネス・ポリシーを編集してサービスの呼び出しごとに関連付けられる一連のオペレーション・ポリシーに変換する手段を示してあります。

表 2. アーキテクチャー層で分解する
アクティビティー説明
ソリューション・ポリシーを分解するこのアクティビティーではアーキテクチャー層を使用して、ビジネス層で提供されたソリューション・ポリシーを状況に応じてそのソリューションの SOA リソースに適用可能なポリシーに分解する方法を定義します。このアクティビティーには、影響を受けるリソース (サービス、情報、またはプロセス) を特定することが含まれます。すべての銀行サービスは 2 秒以内に応答しなければならない。すべての情報サービスは 1 秒以内に応答しなければならない。
ドメイン・パターンを選択する既存の SOA インフラストラクチャーによって提供されるドメイン・パターンを使用すると、特定の実装パターンの使用を強制することができます。既存のパターンを選択することで、新しいソリューションの開発が必要なくなり、既存のコンポーネントを再利用できるため、価値実現までの時間や開発期間を短縮することができます。要求されるサービス・レベルを実現するために、サービスの遅延を監視し、その遅延に応じて適切なサービスにルーティングするという、SLA パターンを使用する。
オペレーション・ポリシー・セットを作成するソリューション・ポリシーを、ドメイン・パターンのオペレーション上の実装を使用して実行可能なポリシー・セットの形にします。これらのポリシーを管理するためにデプロイされた機能や製品を使用して、ポリシー管理ライフサイクルのすべてが提供されます。特定のサービス・ポリシー・セットにはルーティング・ポリシーと監視ポリシーが含まれる。

オペレーション・ポリシー層のソリューション

最後に、オペレーション・ポリシー層では、ビジネス・ポリシーとアーキテクチャー・ポリシーをさらに、ポリシーの施行や監視に必要で実行可能な一連のオペレーション・ポリシーに分解し、元々のビジネス・ニーズを確実に満たすようにします。

ビジネス・ポリシーは、アーキテクチャー層で提供される手段によって、プロセスやサービスによって解釈される機能ポリシーと、オペレーション・ソリューションでのアーキテクチャー・パターンの構成方法を制御する非機能ポリシー・セットへとマッピングされます。SOA Policy Reference Architecture では、オペレーション層で実装される重要な非機能ポリシーの領域を 4 つ指定しています。これらのオペレーション・ポリシーの領域では、最後のセクションで説明するアーキテクチャー・パターンに使用される非機能ビルディング・ブロックを提供します。

ポリシー・ツリーを例にとると、オペレーション層には考慮する必要がある主要概念が 3 つ存在しています。これらの概念について以下の図と表で説明し、詳細についてはその後のセクションで説明します。

図 6. オペレーション層でポリシーを分解する例
オペレーション・ポリシー層
表 3. オペレーション層で分解する
アクティビティー説明
指定されたすべてのやりとりに関するポリシーに対し、ポリシー・セットとの照合を行う特定のポリシー・ディレクティブから生成されたポリシー・セットを、特定のサービスとのやりとりに対して既に提供されている他のポリシーとマージする必要があります。銀行サービスとのやりとりをするための SLA ポリシーを、顧客の口座データを保護する既存のセキュリティー・ポリシーとマージする必要がある。
ポリシー・セットを PDP/PEP 構成にマッピングするポリシーの解釈と施行のために使用される PDP と PEP は多くの場合、ポリシーを施行するために他の動的情報と併せてポリシー・セットを使用します。新しい条項をポリシーに導入するためには、更新されたポリシーをサポートするために、PEP の構成、メディエーション、その他の関連レジストリーを変更する必要があるかもしれません。SLA メディエーションでは、要求される SLA を実現可能なエンドポイントを判断するために、プロバイダーのポリシーに規定された遅延時間の統計を利用します。
監視ポリシー・セットを KPI のダッシュボードとアラートにマッピングするアーキテクチャー層のポリシー・セットにより、それぞれのやりとりで何を記録する必要があるかを定義することができます。しかしポリシーの KPI をダッシュボードに表示する手段や、重要な例外基準やアラートへの応答手段には、やはり構成が必要です。遅延時間がサービス・レベル管理ポリシーに規定される値より大きい場合や、サービス利用率が 90% を超える場合には、アラートを発生させる。

まとめ

SOA ポリシーは、SOA ソリューションにビジネスのアジリティー (俊敏性) と応答性を実現するための手段ですが、これらのポリシーを管理するにはシステマチックな手法が必要です。この記事では、さまざまなポリシー技術によって提供される SOA ポリシーのビルディング・ブロックやパターンを利用可能なソリューションを実現するために、採用するとよい推奨のプラクティスとライフサイクルについてまとめました。

IBM SOA Policy Reference Architecture には、さまざまなポリシーをシステマチックに作成、デプロイ、施行、監視する方法が 1 つのソリューションの一部として記述されています。また、ソリューション・サービス、プロセス、アプリケーションの開発に使用される SOA 開発ライフサイクルとポリシー・ライフサイクルとがどのように相互作用するかについても記述されています。そして最後に SOA ポリシーでは、組織が採用するガバナンス・プロセス全体に対してどのように整合を取ってサポートするのかが記述されています。

参照資料

ファイル名説明
SOA_Policy_Reference_Architecture_Full_Article.pdfSOA Policy Reference Architecture の資料全体をダウンロードしてください。

参考文献

  • IBM 製品や IT 業界のトピックに焦点を絞った developerWorks の Technical events and webcasts で最新情報を入手してください。
  • Twitter で developerWorks をフォローしてください。
  • 皆さんに最適な方法で IBM 製品を評価してください。製品の試用版をダウンロードする方法、オンラインで製品を試す方法、クラウド環境で製品を使う方法、あるいは SOA Sandbox で数時間を費やし、サービス指向アーキテクチャーの効率的な実装方法を学ぶ方法などがあります。

コメント

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=SOA and web services
ArticleID=834263
ArticleTitle=SOA ポリシー
publish-date=09132012