目標

どのアーキテクチャーでもその最終目標は、ビジネスに対し、規定されたビジネス・ターゲット、ビジネス・ゴール (ビジネスの定性目標)、ビジネス・オブジェクティブ (ビジネスの定量目標) を達成する方法に関する指示を与えることです。ビジネス主導でのアジリティーの必要性が認められれば、あとはベスト・プラクティスを使用して、ビジネス要件を満たすように特定の製品を調整することも、完全に自動化されたインテリジェントなソリューションをアーキテクトが構築することもできます。ポリシー (方針) およびルール (規則) の適用と管理にさまざまな方法があることは、計り知れないアジリティーをビジネス・サービスにもたらすチャンスとして見なすべきですが、それと同時にビジネスは、ビジネス・ルールとビジネス・ポリシーを最優先のビジネス資産として管理するための独自のガバナンス原則を確立することも必要です。

この第 1 回で主な目標とするのは、ポリシーとルールという用語の定義について提案し、ポリシーとルールの相互関係、そしてビジネス・アナリスト、アーキテクト、IT スタッフの相互関係を評価するためのコンテキストを提供することです。まずはビジネス・ポリシーとビジネス・ルールの間にある関係を概説し、ポリシーとルールを個別に、あるいは組み合わせて使用してビジネス戦略と戦術、そして業界の法規制を実装/実施する方法を評価する際のコンテキストを確立できるようにします。ここで目的とするのは、ビジネスと IT が、定義されている特定のビジネス・ゴールおよびビジネス・オブジェクティブを達成するのを、アーキテクトはどのように支援できるかを説明することです。この目的を達成するため、記事の最初のセクションではポリシーとルールという用語の定義を提案し、この 2 つの用語の使い方と互いの関係に関する私たちの主張を提示します。記事のこの部分は、用語の関係および本質的に動的なビジネス・アジリティーの目標の表現に重点を置いているという点で、やや抽象的な内容となっています。

上に戻る

概要

第 1 回の「用語の定義」のセクションは、この連載を通して使用する用語を確定することを目的としています。ポリシーとは何であるか、そしてルールとは何であるかについて (読者の皆さんが完全に同意するかどうかには関わらず) 一般的な定義を設けることによって、ポリシーのタイプとルールのタイプとの間にある関係を調べたり、どのようなときにそれぞれのタイプを使用するのが適切なのかを検討したりできるからです。

「動機」のセクションでは、この記事で定義した用語が適用される業界の、一般的な背景について説明します (OMG の資料を参考にしています)。このセクションには、参考文献から引用してこの記事のために解釈した主張も記載します。この業界の作業には広範な適用性があるため、記事ではその作業の一部に焦点を絞ります。

「抽象化レベル」のセクションは、私たちの主張の適用戦略を一連の技術問題に反映させます。ビジネス・ロジックのアーキテクチャーは誕生したばかりではなく、アジリティーに関する新しい要件の多くは、これまでの試行でまだ達成されていないオブジェクティブに関連します。ソフトウェア開発は進化するものです。

「トップダウン方式による取り組み – ビジネス層」のセクションを読むと、アジリティーの重要な 1 つの側面は要素間の関係であることがわかってくるはずです。アジャイルであるということは、あることが別のことの振る舞いに影響を及ぼすようにすることです。指針のないアジリティーは、信頼性の欠如につながります。パフォーマンスを向上させるためにビジネス・アジリティーを実現するということは、ビジネス層、アーキテクチャー層、そして運用層が同じ一連の目標を達成するために協調することを意味します。目標となるビジネス・ディレクティブ (ビジネスの指針) およびビジネス・ゴールは、ビジネス・アナリストが定義します。

目標を設定することと目標を達成することは、別のタスクです。「アーキテクチャー層」のセクションでは、ビジネス・アナリストとアーキテクトとの間にある重要な関係にスポットライトを当て、ビジネス・ゴールを解釈してアジャイルなアーキテクチャーを作り上げるという課題について探ります。

第 1 回の最後のセクション、「運用層」ではもう 1 つの重要な関係について説明します。ビジネスの成功は常に分業にかかっています。ビジネス・ディレクティブはアーキテクトによって解釈され、業務スタッフによって維持されます。アジリティーがビジネスをサポートするためには、個々の業務をビジネス・コンテキストのなかで捉えることが重要となってきます。業務上の 1 つの出来事がビジネスに影響を及ぼす可能性もあるためです。

上に戻る

用語の定義

この記事では、用語を以下のように定義します。

• 「ポリシー」の一般定義は、目的または指針を規定したものです。コンピューター・システムでのポリシーとは、「特定の状態を踏まえて選択肢のなかから選択した行動方針」であることを明確にしておきます。
  • 一方、「ビジネス・ポリシー」はビジネス・ディレクティブの一種であり、特定のビジネス条件のなかで取られるべきであるとビジネスが考える行動方針を表明したものです。
• 「ルール」とは権限を使用し、統制することです。
  • 拡大解釈すると、ビジネス・ルールとは、ビジネスのガバナンス・モデルに従ってビジネスを直接統制することです。

ポリシーとルールとの関係を図に表すと、1 つのビジネス・ポリシーを実行するために複数のビジネス・ルールのいずれか 1 つを派生させることができるという関係になります。ビジネス・ディレクティブは、ビジネス・ポリシーとビジネス・ルールの組み合わせによって実行されます。例えば、特定のビジネス・ポリシーによってビジネス・プロセスを管理するというソリューションのコンテキストでは、ポリシーが適切なビジネス・ルールを行使することによってビジネス・プロセスが導かれます。

上に戻る

動機

どのビジネスでも、ビジネス・アプリケーションに実装できる特定のビジネス戦略、ビジネス戦術、ビジネス・ゴール、ビジネス・オブジェクティブがあり、ビジネス・アプリケーションには随時測定できる重要なビジネス評価基準があるものです。最近では、あるビジネスが同様の別のビジネスと統合することや、企業が合併あるいは国境を越えて移転することは珍しくありませんが、このことは 1 つの課題を提示しています。組織が新しい市場に進出するとなると、その組織独自の評価基準を持つことになったり、あるいはその組織のビジネスが業界の変化する規制や新しい規制に直面することになったりします。したがってビジネスの新しい課題は、現在のビジネス・ゴールを達成することだけでなく、ビジネスにおける短期的な変化にも、十分に計画された長期的な変化にも適応可能な戦略を設計することです。

このことは、提供するビジネス・サービスが、状況の変化に対応して存続し、同時に最適なビジネス・パフォーマンスを達成できるようにするためには、ビジネス・ソフトウェア開発者の多くは、柔軟性があることを目標にビジネス・アプリケーションを設計する必要があり、さらには堅牢性も持ちあわせていることを目標に加えなければならないことを意味します。あらゆるプロジェクトの最初のステップには、一般的なビジネス要件を収集して確定するという作業も含まれます。これらの要件のなかには、ビジネス・ポリシー・ディレクティブとして表明しなければならないものもあります。また、時間が経っても比較的変更のない要件と、(設計の初期段階で認識される) 頻繁に変更が必要となる要件を把握することも重要です。変更が見込まれる部分を早い段階で特定することで、プロジェクトの設計および実装を改善することができます。すると、将来的に変更を繰り返す可能性が少なくなり、その結果としてコストも節約されることになります。

たいていの管理機関は、特定のポリシーに従って日常の業務を行っています。民主主義を例に挙げると、人々は法律の制定を投票で決め、あらゆる市民政策はその法律 (つまりルール) の範囲内で執行されると信じます。政党や政治家には任期があり、政策を適用する特定の方法を選択する権限は任期の限られた政党にあるため、個々の市民政策は変わることがあります。けれども執行対象の法律は、ほとんどそのまま維持されます (ただし司法制度による支持も必要です)。ビジネス・アジリティーに必要となるのは、これと同じような関心事の分離と、規定されたビジネス・ポリシーの範囲内でシステムが正常に機能していることをチェックし、バランスを取るための一連の統制です。

まず、以下の点を主張します。

1. ビジネスは一連のビジネス・ガイドラインを確立し、ビジネス・ガバナンス・ライフサイクルに従ってリソースを管理します。そのようなビジネス環境で優れたガバナンスを確立するには、アジリティーを組み入れるポリシー一式とルール一式の両方を定義する必要があります。
2. ビジネス要件をポリシーとして表明することによってもたらされるアジリティーは、ビジネスの状態が変化しやすい場合に見えてきます。さまざまなビジネスの状態を反映してガイドライン一式を定義することは可能です。したがって、ビジネス・ポリシーを識別し、ビジネス状態の変化に併せて管理できれば、具体的なビジネス・ルールをよりアジャイルに実行し、ポリシーの範囲内で変更に適応させることができます。
3. ビジネス・ポリシーに独自の変更ライフサイクルを持たせ、ビジネス状態のわずかな変化に対してビジネス・プロセス機能をモニターし、それによって既存のビジネス・プロセスの許容範囲内でビジネスの振る舞いの幅を拡大あるいは変更することができます。技術の使用に関して組織がどれだけ成熟しているかによっては、ルールの評価および実行によってビジネスの運用プロセスを自動化 (別名「IT」) することで、ビジネス管理を強化できる余地もあります。
4. 相補的技術を組織全体で使用すると (つまり、ビジネス・アプリケーションと「IT プロセス」で相補的技術を使用すること)、運用プロセスでビジネス・ポリシーを実行することが可能になり、ビジネスと IT とで必須の振る舞いまたはポリシーに準拠した振る舞いをバランス良く実行できるようになります。
5. ビジネス・ルールおよびビジネス・ポリシーの包括的な戦略を管理する際には、広範にわたる柔軟なビジネス資産の (ポリシーとルールによる) 定義を考慮しなければなりません。これらのビジネス資産は、ビジネス状態の変更に併せて (適切な統制の下で) 変更することができます。アジャイルな統制には、それぞれ独立していながらも調整されたビジネス・ポリシーのガバナンス・ライフサイクルが必要です。ビジネスは適切に設計されたインフラストラクチャーの中にあってこそ、ビジネス連携の強化、価値を生み出すまでの時間の短縮、変更量と変更コストの削減、そしてビジネス・ユーザーに与える統制の拡大など、多くのビジネス利益をもたらすようになります。
6. 企業がビジネス・ルールとビジネス・ポリシーをインスタンス化する際に、ルールとポリシーの運用資産を、ビジネス資産を管理する場合と同じ効率性で管理および調整するためには、その企業独自の運用ポリシー (アクセス制御ポリシー) と運用ルール (サービス・レベル・アグリーメント) を標準化する必要に迫られます。

ビジネス資産とポリシーおよびルールの運用資産の管理に一貫したアプローチを取ることで、ビジネス層はビジネス資産を変更したときに、運用層でのその変更の実施に関する報告を受けることが可能になります。IT 側、あるいはビジネス側が取り組む詳細レベルは異なるため、指定されたビジネス制約と目標をサポートするには、それぞれに異なる技術が関与してきます。けれども最終的な目標は、指定されたプロジェクトのビジネス要件や、ビジネス戦略および戦術のビジネス要件に従って、運用資産の管理を調整することです。

上に戻る

ポリシーおよびルールの抽象化レベル

業務の自動化を目指すさまざまな顧客と数年間にわたり作業してきた結果、ビジネスを機能させている現実を詳細に分解して反映するパターンが浮かび上がってきました。どんなビジネスにも達成したい目標 (ゴールとオブジェクティブ) があります。そしてどんなビジネスでも、そのゴールとオブジェクティブを達成する上で、ビジネス資産の管理方法に関するポリシーを表明しなければなりません。ビジネスがゴールとオブジェクティブをどれだけ達成しているかを測定するには、さまざまな方法があります。例えば、管理ポリシー、ビジネス測定 (評価基準)、主要業績評価指標 (KPI: Key Performance Indicator) としてデータを収集することです。経営側の人間はコンピューターおたくではなく、経営に携わる要員でありたいと思うものです。また、そうである必要もあります。したがって私たちは、統制マトリクスにはもう 1 つの軸があることを認識しなければなりません。私たちが統制状況を把握して管理する一般レベルとして主張するのは、ビジネス層、アーキテクチャー層、そして運用層の 3 つです。

アーキテクトは、ビジネス・アーキテクチャー全体の整合性に責任を持ちます。そのアーキテクトの役割によく含まれるのが、ビジネス・ゴールを現行のハードウェア資産およびソフトウェア資産 (アーキテクチャー層) へとマッピングあるいは解釈しなおし、ビジネス・プロセスおよびビジネス・サービスにインスタンス化するというタスクです。アーキテクトはまた、さまざまな IT サブジェクト・マター・エキスパートと緊密に連携して、管理された環境 (運用層) の中でハードウェアおよびソフトウェアを効率的かつ効果的に実行させる方法を指定します。アーキテクチャーは、セキュリティー、アクセス制御、サービス・レベル・アグリーメントから、ビジネス・ワークフロー、イベント処理、そして情報管理とビジネス・ルールに至るまでの広範なディレクティブを網羅する必要があります。

顧客と連携するなかで私たちが気付いたことは、この 3 つのレベルの抽象化を使用することで、すべての関係者があらゆるソリューションには複数の観点からの異なる要件が含まれることを認識し、アジリティー問題に関する全般的な話し合いをより具体的なソリューションの議論へと絞り込めるようになるということです。ソリューションによってツールとレポート作成メカニズムは異なります。したがって、ある問題がビジネス層に関連すること (ビジネスの資産を保護するには、上位レベルの表現が必要であること) がわかれば、要件を指定して適切なソリューションのための資産を収集すること (つまり、コンピューター関連のすべての資産のバイナリー表現を作成するのではなく、ビジネス・ダッシュボードを開発すること) に専念することができます。このように、常にアジリティー問題のビジネス・ゴールおよびビジネス・オブジェクティブを念頭に置いておくことが重要です。

上に戻る

トップダウン方式による取り組み – ビジネス層

ビジネス・ディレクティブおよびビジネス・ゴール

企業がビジネス・プロセスを自動化すると決断した場合、最初のステップとなるのはビジネス・ディレクティ

ブ (ビジネスの指針) 一式としてのビジネス要件を把握することです。ビジネス・ディレクティブには、実現すべき一連の目標と、結果を目標に対して比較測定するための一連のビジネス評価基準が含まれます。ビジネス・ディレクティブを表現する方法にはさまざまなものがありますが、ビジネスがビジネス・ポリシー (ビジネスの方針) とビジネス・ルール (ビジネスの規則) のソリューションを検討する際に通常必要となる共通要素を分析するために、私たちは OMG で定義しているモデルと手法を解釈して適用しました。OMG Business Motivation Model についての詳細は、http://www.omg.org/spec/BMM/1.0/ から入手できる資料に記載されています (私たちは、ビジネス・ゴールおよびビジネス・オブジェクティブを収集して明示するには一般的な方法があることを、同サイトの資料を参照して説明しています)。

ビジネス・ディレクティブ、ビジネス・ポリシー、およびビジネス・ルール

概念レベルでは、OMG の「Business Motivation Model」(BMM) は、ビジネスがどのように編成されていて、どのように決定を行うかという、ひと回り大きな概念的枠組みのコンテキストでルールとポリシーとの関係を探る方法を提供します。BMM は以下のようにして、ガバナンスの原則の一部を反映します。

• BMM モデルでは、「ビジネスに関する野望 (ビジネスに関するビジョン)、ビジネスに関するアクション・プラン (ビジネスに関するミッション)、ビジョンを集約することによるゴールとオブジェクティブの作成、ビジネス・ゴールを達成するための戦略の明確化、ビジネス・オブジェクティブを達成するための戦術の明確化」について理解しようと試みます。

ビジネス・ディレクティブは、ビジネス・ポリシーとビジネス・ルールの組み合わせからなる場合もあります。OMG の資料では、ビジネス・ポリシーとビジネス・ルールを比較対照しており、その内容を要約すると以下のようになります。

• ビジネス・ポリシー
  • ビジネスの統制下で管理されます。
  • ビジネス・ポリシーはビジネス・プロセスを管理します。
  • ビジネス・ポリシーは自然言語で表現できるため、曖昧になることがあります。
  • 自然言語の曖昧さから、ビジネス・ポリシーを直接実行できないことはよくあります。その場合には、ポリシーを解釈する必要があります。
• ビジネス・ルール
  • ビジネスの統制下で管理されます。
  • ビジネス・ルールはビジネス・プロセスのアクションを実行します。
  • ビジネス・ルールは SBVR (Semantics of Business Vocabulary and Rules) の用語で曖昧さを残すことなく表現されます。
  • ビジネス・ルールは具体的な SBVR の用語で定義されており、具体的なビジネス・アクションと、定義およびアクションに対応する特定の資産が反映されているため、直接実行することができます。

ビジネス要素 (ルールおよびポリシー) のすべてを最初に明確化するのは、簡単ではありません。ほとんどのポリシーとルールは時間が経つにつれて変わることから、ポリシーとルールの実装は繰り返し試行することになる可能性が非常に高いはずです。優れた方法では、この事実に対処します。以下の図は、そのような方法のほぼ標準的な形です。この図からわかるように、特定の質問に対する答えによって以前に指定した要素が微調整される場合があります。そして重要な点として、定義されたルールとポリシーには、その成果を測定可能な評価基準が関連付けられていなければなりません。

このタスクに取り掛かるグループが、ある振る舞いをビジネス・ルールとして表現し、別の振る舞いをビジネス・ポリシーとして表現しようとするのは当然のことです。どちらから取り掛かるとしても、詳細が明らかになってくるにつれ、概念を再検討または微調整することは避けられません。ビジネス・ディレクティブを明確化する際には、ビジネス・アナリストとビジネス・アーキテクトが使用する資産を明確にすることが重要です。そのためにする質問としては、例えばビジネス・アナリストはポリシーをどのようにモニターするつもりなのか、ビジネス・アーキテクトはどのようにしてこのビジネス・アナリストがモニターするための機能を提供するつもりなのか、ビジネス・アナリストは独自のビジネス・ルールを作成しようとしているのか、などが挙げられます。ビジネス・アーキテクトは、ビジネス・アナリストの心積もり、そして自らの意図を理解することによって、ビジネスを最適にサポートするアプローチ (ビジネス・ポリシーまたはビジネス・ルール、あるいはその組み合わせ) を判断および選択することができます。

この手法を適用した単純な例としては、例えばマネー・ローンダリング防止 (AML: Anti Money Laundering) 法のような一般的ビジネス・ガイドラインが挙げられます。この法律が導入された頃、金融部門のビジネスは既に正常に機能していましたが、ビジネスにはこの新しい法律に合わせて戦略をまるごと更新するしか選択肢はありませんでした。その更新とは多くの場合、AML 法を施行するための新しいビジネス・プロセス、ビジネス・ポリシー、ビジネス・ルールを追加することでした。さらに、監査のための新しいビジネス・オブジェクティブおよび評価基準を追加するか、または現行の監査業務に再び焦点を当てて、ビジネス全体に適用されるようにしなければならないことも珍しくありませんでした。マネー・ローンダリング防止 (AML) に関する一般的なビジネス・ディレクティブでは、例えば金融機関は犯罪の罰金や処罰の対象となる可能性のある支払いを受け入れないといった一般的な事項を規定することができます。

この AML のディレクティブの例から、具体的なビジネス・ポリシーおよびビジネス・ルールのセットをどのように解析するかを考えると、初めから明らかなのは、ビジネス・ディレクティブを 1 つのビジネス・ポリシーあるいは 1 つのビジネス・ルールとして表現することもできるとは言え、一連のビジネス・ポリシーとして表現するのが最も自然であるということです。

このディレクティブをサポートするビジネス・ポリシーは、「金融機関のエージェントおよび従業員は、高額の支払いに充てられる顧客の資金源を必ず把握すること」といったポリシーになるでしょう。あるいは、「銀行は 10,000 ドル以上の小切手、郵便為替、銀行手形、およびトラベラーズ・チェックによる定期的支払いを受け入れないこと」というポリシーも考えられます。

別の例として、典型的な信用取引業務からビジネス・アナリストが考え付く一般的なビジネス・ディレクティブには、「企業は信用のない顧客には何も販売しないこと」のような一般的な規定 (ビジネス・ディレクティブ) が考えられます。

各事業部門 (LOB) は、上記の例をさらに具体的なポリシーに解釈するはずです。そして共通の信用格付けを提供する共通サービスがあるとすれば、ポリシーは例えば以下のリスト 1 のように改良されます。(リスト 1 の内容は次のとおりです。「ビジネス・ポリシー: XYZ は、低い信用格付けが与えられた口座を持つ顧客には、何も販売することはありません」)

Business Policy: XYZ will not sell anything to a customer whose account has been 
determined to have a bad credit rating

上記のいずれの例においても、ビジネス・ポリシーがどの程度効果的であるかは、そのポリシーがいかに詳細に書かれているかによることを認識することが重要です。したがって可能な限り、ビジネス語彙に従ってビジネス・ポリシーを表現する必要があります (というのも、ビジネス・アナリストは、特定のビジネスが管理する資産のサブセットを把握するものの、必ずしも個々のすべての項目について記載するとは限らないのです)。ビジネス統制の粒度はそのビジネス語彙に反映されます。ビジネス・ポリシーという指針が具体的なビジネス資産と相関していなければ、評価基準を収集してビジネス・ポリシーを実行することはできないためです。つまり、ビジネス・ポリシーによって、「販売しない」対象を「低い信用格付け」の「顧客」に規定したとしても、ビジネスが高い信用格付けの顧客からのリクエストと低い信用格付けの顧客からのリクエストとを区別できなければ、このポリシーは文面としては素晴らしくても、実際には効果がありません。

優れたビジネス語彙がある場合には、ビジネス・アナリストとアーキテクトはさらに具体的なディレクティブにしようとするかもしれません。そして、ビジネス・ポリシーの意味をビジネス・プロセスでそのディレクティブを解釈しなければならないような自然言語で表すのではなく (つまり、「低い信用格付けの顧客には販売しないこと」という表現)、ルールの表現を使ってディレクティブを形にしようとするかもしれません。以下のリストを見るとわかるように、ビジネス語彙が「低い信用格付け」という意味をクレジット・レポート (信用調査書) の計算で格付けが 500 を下回っていることと指定している場合、ポリシーの意味はルールによって表現することができます。したがって、上記のビジネス・ポリシーから派生するビジネス・ルールはリスト 2 のように表現できることになります。(リスト 2 の内容は次のとおりです。「クレジット・レポートのいずれかで格付けが 500 を下回っている場合、その借主をブラックリストに掲載します。顧客がブラックリストに掲載されている場合には、その顧客とのビジネスを拒否し、顧客に対してはその理由を説明するメッセージを通知します。」)

When one of the credit reports has a rating below 500, mark the borrower as blacklisted.

If a customer is black listed then refuse the business and warn  the customer with an
explanation message.

その一方で、ビジネス・アプリケーションでビジネス・ポリシーを解釈するまでの必要がない場合もあります。ビジネス・ポリシーにするか、ビジネス・ルールにするかは、アジリティーの目標とビジネスの能力に基づき、ビジネス価値に従って行うビジネス決定です。

特定のディレクティブが「実行可能」であるかどうかを基準にしたルールとポリシーとの区別 (OMG の定義から引用) は、ビジネス・レベルでのポリシーの概念とルールの概念との間の曖昧さがどこに、なぜ存在しているのかを説明するだけでなく、ビジネス・ディレクティブの収集が重要なアクティビティーである理由をも説明します。この 2 つの概念 (ポリシーとルール) がビジネス・レベルで対をなす概念であり、多くのビジネス・ソリューションにはこの両方が必要であるという私たちの主張を読者の皆さんが認めるとしたら、これから標準ビジネス語彙の存在と範囲を利用して、正しいアプローチを選択する作業に取り掛かることができます。ビジネス・アナリストから一連のビジネス・ディレクティブを受け取ったという前提で、次のステップでは、これらのディレクティブを反映してビジネス・ゴールを達成するソリューションを設計する方法を検討します。

上に戻る

ビジネス・ゴール、ビジネス・オブジェクティブ、そしてビジネスの結果

概念レベルでは、OMG 「Business Motivation Model」(BMM) はビジネス・ディレクティブに応じたビジネスの結果を収集および追跡するための構造も提供します。BMM では、ビジネス・ディレクティブが実装される場所には、ビジネスの結果を追跡するためのさまざまな戦略が考えられることを認識しています。

ビジネス・ポリシーがビジネス・ディレクティブの達成手段であるとしたら、ディレクティブが有効である上にビジネス・ゴールおよびオブジェクティブと連携していることを確実にする鍵となるのは、ビジネス・ポリシーの実行結果を確認することです。ポリシーの実行エンジンは、監査証跡を記録したり、ビジネスにポリシーの実行結果を通知するイベント・メカニズムを実装したりすることができます。ビジネス・ルールが BRMS によって実装されている場合は、監査証跡またはイベント・メカニズムがビジネスにルールの実行結果を通知することができます。

ビジネスの結果または評価基準は、以下のように定性的にあるいは定量的に定義することができます。

• ビジネス・ゴールは、ビジネス・ディレクティブが正常に実施されている場合に期待されるビジネスの状態または条件を表す規定として定義されます。これらのビジネス・ゴールは一般に定性的に定義され、定義されたような状態または条件への変化が起こるには長い期間を要します。
  • ビジネス・ゴール – 今後 1 年をかけて、全システムで新しい AML プロセスが使用されるようにすること
  • ビジネス・ゴール – 個人が特定されるような情報を確実に保護すること
• ビジネス・オブジェクティブは、ビジネス・ディレクティブを達成するための特定チェックポイントでの詳細なパフォーマンス測定として定義されます。通常は定量的であり、達成すべき時間枠に関しては非常に限定的です。これらのオブジェクティブは主要業績評価指標 (KPI: Key Performance Indicator) または重要成功要因 (CSF: Critical Success Factor) として定義できることもよくあります。
  • ビジネス・オブジェクティブ – 新しい AML プロセスの使用開始から 1 ヶ月の間に、10,000 件の AML チェックが行われること。この場合、毎月行われる AML チェック件数と、調査対象として特定された件数のパーセンテージを測定するための具体的な KPI を定義することができます。
  • PCI コンプライアンスの実施 – ログイン試行の失敗を追跡し、通常のログインの失敗の件数と攻撃を受けているシステムでのログインの失敗の構成を識別することによって、注意義務を確実に履行すること。

上に戻る

アーキテクチャー層

アーキテクチャー・レベルでアーキテクトが重点とするのは、「いかにして」という点です。既存のアーキテクチャーが有する統制機能を理解することが、収集したディレクティブをルール (実行可能な要素) として実装できるかどうか、そしてアーキテクチャーに関するポリシーとしてこれらのディレクティブをどこに表現できるかどうかを判断する上で重要になります。

上記の例を引き続き引用すると、アーキテクトは (AML の) ビジネス・ディレクティブを銀行の「窓口係」に適用するべきだと判断することが考えられます。その場合、銀行内には「窓口係」というビジネスでの役割があり、その役割を担うのは人間であるということが、ディレクティブには示されます。ビジネス・プロセスにアジリティーをもたらすということは、アーキテクチャーの中でどのタスクがヒューマン・タスクであり、どのタスクが自動タスクであるかを認識することでもあります。「窓口係」のタスクはアーキテクチャーの一部として定義されているかもしれませんが、新しいディレクティブでは、役割を変更しなければならない場合もあります。例えば、タスクをヒューマン・タスクから自動ワークフローに変更するなどです。アーキテクチャー・レベルでは、各ディレクティブを検討し、数々の基準を基にそのディレクティブをポリシーとして表現するかどうか、そしてポリシーとして表現する場合には実行可能なポリシーとしてどのように表現するかを決定することが重要です。アーキテクトは、ビジネスの観点から誰が「窓口係」であるかを識別するには、新たに関連付けられたビジネス・ポリシー (ビジネスにとって誰が窓口係であるかを識別する方法についてのポリシー) だけではなく、このビジネスでの役割の定義をユーザー・プロビジョニングの運用要素に組み込む必要もあると認識するかもしれません。ユーザー・プロビジョニングで、ユーザー管理コンポーネントが対応する運用アクセス統制ポリシー (窓口係は銀行取引にアクセスできること) を確立するためです。窓口係のポリシーと同じく、運用セキュリティー・ポリシーをセットアップするのも特異なことではありません。人間がビジネス資産上にあるどんなタイプのデータにアクセスする際にもさまざまな方法で識別されることを確実にするためには、ビジネス内に複数の異なるガバナンス・モデル (ビジネス・ポリシー) が必要になることもあります。

広い範囲をカバーするビジネス・ディレクティブを収集することは重要です。ソリューションを完全に実装するには、ビジネスがディレクティブを微調整する際にアーキテクトが支援して、ビジネス・プロセスのサブドメインだけではなく、運用プロセスのサブドメイン (アクセス制御、ユーザー識別、パスワード管理) でもルールとポリシーの組み合わせをアーキテクチャーがサポートすることを確実にする必要があります。

クレジット・スコア (訳注: 消費者個人に与えられる信用評価点のこと。米国で個人の信用度を評価する際に近年特に用いられている) を提供可能な新しい共通アーキテクチャー・サービスを定義することによって、別の融資引受業務のディレクティブをアーキテクチャー・レベルでサポートするという場合もあります。共通の実行可能要素を収集して再利用できるようにするためには、ビジネス・ルール管理システムの技術を使用することが欠かせません。ビジネス語彙の粒度によっては、ルールが具体的な計算となることも、融資を承認または却下する条件を表現することも、あるいは融資の契約条件を定義することも考えられます。その区別が、アーキテクトがビジネス・ゴールおよびオブジェクティブをより具体的にする際に行うタスクの 1 つです。忘れてならない点として、これらのアーキテクチャー上の選択を行うときでも、やはりその基準はビジネス・ディレクティブとビジネス・ポリシーにあります。アーキテクトは、どの評価基準が収集可能であり、これらの評価基準をどこに相関させられるかを定義して、運用要素が実行時にビジネス・コンシューマーに対応したビジネス・データを生成することを確実にします。

組織の成熟度 (ビジネス・プロセスを自動化および最適化するためにデジタル資産/リソースをどのように使用しているかに関する成熟度) は常に、特定のビジネス・ポリシーをどこまで伝達あるいは実行できるかに影響を与えます。ビジネス・ポリシーの実行に関連するビジネスのターゲットまたはアクターは、サービスが完全に自動化されているとしても重要であることには変わらないので、収集する必要があります。場合によっては、「ビジネス・ポリシー」を何らかの文書にする必要が残っている可能性もあります (Web ページでのプライバシーの免責条項など)。ビジネス・ポリシーの実行およびビジネス・ディレクティブに、同意が必要な場合には、それを実装する際の技術には選択肢があり、場合によってはアクションとしてエンコードしなければならないこともあります (ビジネス旅行アプリケーションのユーザーに、ビジネス旅行のポリシーに従うかどうかを尋ねるなど)。あるいは、組織全体での最適化および一貫性を実現するには、ポリシー実行をミドルウェアの自動処理部分とすることが要件になることも考えられます。その場合、実行方法はエンド・ユーザーにはわかりません。また、エンド・ユーザーにわかるようにする必要もありません (メッセージ暗号化をセキュリティー・ポリシーとしている場合、メッセージの暗号化はエンド・ユーザーが開始しなくても、ルールによってすべての送信メッセージで行われます)。

選択肢にこのような多様性がある理由は、アジリティーを実現するエコシステムの一部としてポリシーとルールを捉えることが重要だからです。アジリティーを目的としたエコシステムでは、ディレクティブを収集してビジネス・ポリシーの実行を追跡可能にすることが包括的なビジネス要件となります。ワークフローでヒューマン・タスクのオーケストレーションを行っていようとも (BPEL for People)、BPM スイートでビジネス・プロセスを自動化していようとも、ビジネス・ポリシー実行戦略を強化するのはルール・エンジンとポリシー管理です。ビジネス・ディレクティブが収集され、アジリティーのためのビジネス要件が収集された後は、アーキテクチャー・レベルが実装の選択肢を収集する責任を負います。万能のアプローチというものは存在しません。したがって、ビジネス・アナリスト、アーキテクト、そして IT スタッフがビジネスの価値とコストを基に協力して決定を行う必要があります。

以上の原則を説明する例として、前述の AML のビジネス・ディレクティブを、今度はアーキテクチャー層の観点から検討してみましょう。

An example of a directive around anti money laundering (AML) can state: 
the financial institution should not accept payments that expose it 
and its producers to possible criminal fines and penalties.

このビジネス・ディレクティブの目的は、ビジネスがそのビジネス・アプリケーションを実行する上で不正の罪に問われることのないように、ビジネス自体を保護することです。例えば「金融機関は犯罪の罰金を被る可能性のある支払いに応じないこと」というビジネス・ディレクティブを達成するために必要な上位レベルのビジネス要件は、何通りかの方法で明示することができます。

かつては、「金融機関」の「人間」によってポリシーを実行するのが一般的でした。つまり、金融機関のスタッフ・トレーニングの一環として、各事業部門に対し、第三者からの支払いに応じたり、第三者に支払いを行ったりする際の適切なビジネス行為に関する注意事項を伝えていました。今日のビジネスでも、スタッフ・トレーニングが防御の第一線であることに変わりはありません。けれども銀行員が 3 大陸に散らばっている場合、このようなポリシーが手作業で実行されることを前提にするのは非現実的です。例えば銀行員が取引のすべてをサポートしないように役割を区分していて、さらに他の銀行従業員 (口座取引の検閲を行う管理者) が口座の内容を確認できるようにしていても、取引を自動的に評価するシステム (電子取引やその他の銀行間取引など) がディレクティブに従っていなければなりません。

「ハイテクな」金融機関でより効率的に目標を達成する方法は、アーキテクトにビジネス要件を収集させ、スタッフの振る舞いを手引きして統制するための自動化したビジネスおよび技術サービスを設計させることです。その場合、アーキテクチャーが、記録および取引を自動的に分析することによって犯罪に関係する危険のある支払いを評価し、フラグを立てるためのルールを定義することになります。この新しいアーキテクチャーには、ビジネス管理ワークフローの一環として、動的に「危険」とマークされた取引でトリガーされる新しい管理承認アクションを組み込みます。

アーキテクトには難しいタスクがあります。それは、アーキテクチャーのどの構成要素がソリューション・アーキテクトを支援できるかを見極めることです。

アーキテクトは、ビジネス・ディレクティブの改良プロセスを開始する手段として、ビジネス・ルール・エコシステムに定義された分類のタイプおよびサブタイプを使用することができます。よく使用されるサブタイプには、構造タイプ、そして振る舞い/運用タイプの 2 つがあります。

まずは、構造ルールのタイプから取り掛かります。構造ルールは、ビジネス・データ・ドメイン内の特定の項目を反映するので、構造ルールには大体のビジネスの範囲が反映されるからです。構造ルールの例には、「新規口座を開設するには、顧客がその国に居住していること」、「レンタカーを借りる際にリクエストする自動車グループは 1 つに限定されること」、「1 つの銀行口座の所有者は 1 人の顧客に制限すること」などが挙げられます。このような構造ルールのタイプは、その後ビジネス・プロセスまたはビジネス・モデルで表現されるビジネス資産やビジネス成果物の作成に影響を及ぼします。

構造上の資産が決まると、次は振る舞いに関するビジネス・ルールのタイプが、実行可能なアクションを反映するのが通常です。振る舞いに関するビジネス・ルールは大抵の場合、ビジネス・プロセスまたはビジネス・モデルの特定の実装の特性に関連します。そのような振る舞いに関するルールに選択肢があるのは当然のことです。振る舞いに関するルール (運用ルールとも呼ばれます) は、プロセス実装の粒度に応じたさまざまな実装パターンをサポートするために、さらに細分化することができます。以下の図に、多種多様な顧客との実装経験に基づく振る舞いに関するルールの例を示します。

ルールを分解する場合には常に、パターンを探すことが重要です。振る舞いに関するビジネス・ルールには、共通して見られる 2 つのパターンがあります。1 つは制約を表すパターン、もう 1 つはガイドラインを表すパターンです。

制約とは、行わなければならない不可欠な事項のことです。制約は「必須」という言葉を明示的に用いるか、それよりも暗黙的に「であることが必要」(通常はそれに加え、「実施すること」) というように表現することができます。

ガイドラインは、望ましくない状況について警告します (警告メッセージに変換されることがよくあります)。

プロセス・フローとして分けられるサブタイプは一般に、フローのパラメーターまたはメタデータを表現するために使用されます。ルーティング・ルールは、ビジネス・プロセスが手順の実行およびアクティビティーの順序を規定する手段の一例です。環境によっては、プロセス・フローのルールをビジネス・ロジックのルール (プロセス・フローを管理するためのパラメーターの値を決定するルール) から区別すると有益なこともあります。

決定サブタイプでは、数学的方程式に基づき、既存のデータから新しい情報が作成されます。

イベント条件アクション (ECA: Event Condition Action) は、イベントの発生検出時に条件が評価されるという、ルールの特定パターンです。ほとんどの ECA ルールは時相演算子を使用して、作成または発生のタイムスタンプと関連するイベントを検索します。「過去 x 秒間に発生した指定の記号名のイベントをフィルタリングし、価格と数量を乗算して算出された値を合計する」といったルールの規定には、具体的なルール式が必要となります。ルール・エンジンが実行時にこのような式の実行をサポートするには、時間枠が変動するステートフルなメカニズムがなければなりません。経時的条件の意味を把握することは、ルール・アナリストが分析段階で行う非常に重要なタスクです。

アクション・イネーブラーというサブタイプは、システムで別のアクションを開始します。その一例は、ルール実行がビジネス・プロセスをトリガーし、そのビジネス・プロセスが非同期でサービスを呼び出す場合です。このタイプは、焦点がエスカレーション、監査、評価プロセスなどのビジネス・プロセスをトリガーするルールに置かれているという点で、ビジネス・ユーザーの視点を表しています。

推論というサブタイプは、高度なアジャイル方法を反映することがよくあります。推論サブタイプは、振る舞いに関するルールの内容によってルールを処理する評価が左右されることを前提に、データ要素を生成または更新します。すると、これらの新しい条件によってルールが再評価されることになります。

重要な点として、ECA ルールで説明した時相演算子は比較的一般的な概念であり、他のサブタイプのルール内での条件にも適用することができます。時間制約をサポートするルール・タイプはありません。そこで、例えばプロセス・フローではタイマー条件を定義して、このタイマーがトリガーされるとプロセス内の特定のタスクが実行されるようにするといった方法が可能です。「2 時間以内に同じガソリン・スタンドで同じカードを使ってカード取引が発行された場合、それは不正なカード取引の可能性がある」という条件文があるとすると、この条件は推論ルールに当てはめることができます。それは、この条件によって不正という結果が導かれるためです。あるいは、ある流れの一環としてこの取引イベントがある場合には、流れ処理の規定に適用することもできます。

このプラクティスのほとんどの部分は、単に優れたアーキテクチャーの設計であるにすぎません。ポリシーとルールが関わる部分が、統制を静的に行えるかどうか、特性の一部が時間と共に変わるかどうか、あるいは他の何らかのビジネス変数を左右します。例えば銀行業務での変動性において重要な点は、地理です。銀行業務には国際ルールだけでなく、それぞれの国によって異なるルールおよびポリシーが適用されるためです。

上に戻る

運用層

図 3 には、ビジネス層とアーキテクチャー層の間のライフサイクルだけでなく、アーキテクチャー層と運用層との間にもライフサイクルがあることが示されています。すべての関係者は、ビジネス・ディレクティブを運用範囲に絞り込むためには別の繰り返し作業が度々必要になることを認識していなければなりません。さらに私たちが主張するのは、IT は 1 つのビジネス機能であり、アーキテクチャーが適応すべきビジネス・ポリシー制約を、運用環境が独自に明示する場合も少なくないという点です。上記の例で収集した規定のビジネス・ディレクティブは、事業部門 (LOB) あるいは LOB 全体の見方を反映していると見なすことができますが、それとは別に、最高セキュリティー責任者や最高情報責任者が表明して統制しなければならないビジネス・ディレクティブもあります。

例えば、ソリューションを定義するアーキテクトが、運用ポリシー管理が提供する統制範囲と一致するソリューションを設計するためには、実行時または運用上のポリシー決定ポイント (PDP: Policy Decision Point) あるいはポリシー実行ポイント (PEP: Policy Enforcement Point) の存在と粒度を認識していなければなりません。アーキテクトが (ポリシー作成点で) 表現したポリシーを現行の運用環境で実行できないとしたら、アーキテクトは IT と協力してこの新しいディレクティブを運用できるようにする必要があります。組織は大抵の場合、LOB 間のポリシーが一貫性を持ち、最適化されるようにこれらのポリシーを運用可能にする場所と方法の選択を IT に委任します。その一般的な例は、メッセージ・セキュリティー・ポリシーです。メッセージ・セキュリティー・ポリシーは運用インフラストラクチャーの特定のポイント、つまり DMZ で一貫して実行されなければなりせん。運用ポリシーの制約は、ポリシーを実行するアプライアンスのタイプや、ネットワーク全体の保護ディレクティブによって影響を受けがちです。

IT に委任されたビジネス・ディレクティブに期待されるのは、DMZ 内で特定のポリシーが実行されることによって、ビジネス・ポリシーが元々表現しているビジネス・ディレクティブが実行されることです (ただし、この目標を達成するための手法には、ルールの使用を含め、さまざまな形があります)。そのため、図 3 のポリシーとルールを改良するプロセスには運用に関する測定の「ラウンド・トリップ」を組み込み、それによってビジネスに運用評価基準とビジネス評価基準の相関関係を与えているというわけです。ルールの技術は IT だけでなく LOB アプリケーションが使用することも可能であり、アーキテクチャーおよび再利用に関する適切な慣例が導入されていれば、アーキテクトは IT とビジネス両方の要件に対応する共通の構造を構築することができます。

ライフサイクル全体でポリシーおよびルールの実行を微調整することの重要性は、例えば抽象化の各レベルとビジネス・ディレクティブで従来から「運用セキュリティー」と見なされているアクセス制御に目を向けると明らかになってきます。最上位の概念レベルでは、すべてのビジネスに誰が何にアクセスできるかに関するポリシーが必要ですが、(従業員数が 10 人に満たない場合を除き) CEO が個々の従業員および各従業員がアクセスできるレコードに至るまでの詳細なポリシーを作成することはないはずです。ほとんどの LOB は、その LOB が所有するリソースへのアクセスに関する「ポリシー」を設けていますが、アクセス制御の管理を最適化するためには、IT 組織に 1 つ以上のポリシー実行ポイントが必要となる場合もあります。LOB 間の運用ポリシー実行メカニズムを構築する際には、IT インフラストラクチャーを担当するアーキテクトがポリシー実行戦略のなかでルール・エンジンを使用して LOB 内または LOB 間の特定の取引 (サービスのフェデレーション) に適用するポリシーを決定するように推奨することもあります。ルール・エンジンは、運用ランタイム環境にポリシーの「決定」を実装して実行するために使用されることがよくあります。

以下の図に、セキュリティー・ポリシーを管理するための運用ポリシーの実行アーキテクチャー・スタイルを示します。

もう 1 つの例は、複数のプロセスや、さらには複数のアプリケーションでビジネス・アプリケーションの決定を管理し、共有し、再利用できるように、ビジネスに共有アーキテクチャーのポリシー決定ポイントが必要であるとアーキテクトが判断する場合です。運用レベルでは、このポリシー決定ポイントに複数のビジネス・ルールを組み込むことができます。これらのビジネス・ルールは、ビジネス・ポリシー・ディレクティブを満たすために必要な決定を実装するために作成され、結合されます。

BMM 原則を拡大解釈すると、(上記の BMM による) ビジネス・ディレクティブの収集には、脅威と機会の収集、そして戦略と戦術の収集 (通常はアーキテクチャー関連) も含まれます。

アーキテクチャー戦略のさまざまな定義の範囲内で、それぞれのアーキテクチャー・スタイルにおけるポリシーとルールを改良し、各分野 (ビジネス・ポリシー、脅威と機会、戦略と戦術) に適用することもできます。バリエーションがあることがわかれば、あらゆる具体的な行動方針の定義を導き出す方法を導入するには、ビジネス、アーキテクト、業務スタッフの間で統制のとれたやり取り (ガバナンスとも呼ばれます) が行われることの重要性が浮き彫りになってきます。ビジネスの概念モデルから具体的なアーキテクチャーおよび運用に関する定義に移行する方法を含め、特定のビジネス問題に対する説明責任を果たすには、優れたガバナンスの実施が必要です。

この責任の対象をアーキテクトに絞る理由は、さまざまに異なるアーキテクチャー・スタイルのコンテキスト (SOA) で評価を行われなければならないこと、そして評価では、ルール実装 (例えばサービス設計、サービス選択、サービス・オーケストレーションでの実装) およびポリシー実行メカニズムを適用するためのベスト・プラクティスを考慮しなければならないためです。アーキテクチャー・スタイルにも、独自のベスト・プラクティスがあります。例えば、ビジネス・プロセスの効率性に関する問題に対処するためのベスト・プラクティスは、ビジネス・プロセス管理 (BPM: Business Process Management) スイートを利用することです (「誰が関与するか」、「いつ関与すべきか」、「何を行う必要があるか」を事前に識別します)。BPM スイートは人間のアクターと自動化されたアクターの両方をサポートすることができるため、BPM に実装するビジネス・ロジックは、人、タスク、そしてタスク内で処理するデータに瞬時に関連付けることができます。誰がどのタスクを実行できるかを決定する際に、ほとんどの組織では人を機能的な「役割」にグループ化するため、アーキテクトは役割定義のビジネス所有者とユーザー・プロビジョニング・タスクの運用所有者の両方と協力しなければなりません。大抵の場合、タスクを実行する担当者を決める基準はその個人が割り当てられている役割に関連します。大部分の組織は、個人への一時的な役割割り当て (休暇によるもの)、別の個人へのタスク割り当ての許可 (委任) を含め、これらの基準をビジネス・ポリシーとして表現します。BPM を補足するには、ビジネス・ルール管理システム (BRMS: Business Rules Management System) を使用することができます。BRMS は、ある特定の方法で振る舞う理由、決定を行う理由など、BPM のタスクに「理由」を追加します。アーキテクトはビジネス・アナリストに、BRMS を使ってルールの変動性をサポートするように促すことができます。事前定義された構造を使用してビジネス・アジリティーの要素を構造化形式 (if-then-else 文や意思決定表、ルール・フロー、意思決定ツリー、関数、ルール・テンプレート) で定義すれば、一連のビジネス・プロセス内で単純なデプロイメント・パターン、推論、またはパターン・マッチングを利用できるようになり、ルールの変動性をサポートしやすくなります。

上に戻る

まとめ

ビジネス・ゴールを達成およびモニターするために、ポリシーとルールを使用してビジネス戦略、ビジネス戦術を強化することで、コスト削減、そして短期的変更と長期的変更の両方に対応するアジリティーという点でビジネスを改善する上で、さまざまな利点がもたらされます。同じ予算でより多くのことを行い、ビジネス・ユーザーにより多くのことを行う権限を与えることは、IT とビジネスを協調させるための非常に前向きな一歩です。

重要なポイントを以下に記載します。

• ビジネス、アーキテクチャー、および運用ポリシーはいずれも重要であり、特に大規模なソリューションでは、この3 つすべてが一体となって機能しなければなりません。
• ビジネス・ポリシーとルールは対となって存在します。ビジネス・ポリシー・ディレクティブを実装するには、ビジネス・ポリシーとビジネス・ルールを導き出して併せて使用することができます。
• ビジネス・チームがビジネス・ゴール、そして具体的なビジネス・ディレクティブを使用してビジネス・ディレクティブに対するパフォーマンスを測定することで、予測されるビジネスの結果を定義することができます。
• トップダウン方式を採るプロジェクトでは、ポリシー・ディレクティブを詳細なポリシーとルールに細分化します。複数の異なる運用システムが一体となって機能しなればならない場合、ポリシーとルールを細分化することで、それぞれのポリシーとルールが上位レベルのビジネス・ディレクティブおよびゴールとどれだけ協調しているかを追跡しやすくなります。

参考文献

学ぶために

• ビジネス・オブジェクティブは、ビジネス・ディレクティブを達成するための特定チェックポイントでの詳細なパフォーマンス測定として定義されます。
  
  
• ビジネス・ゴールは、ビジネス・ディレクティブが正常に実施されている場合にビジネスに期待される状態または条件の規定として定義されます。
  
  
• ビジネス・ディレクティブについて詳しく学んでください。
  
  
• developerWorks の SOA and web services エリアにアクセスして、スキル上達に欠かせないリソースを入手してください。
  
  

製品や技術を入手するために

• IBM 製品の評価版をダウンロードするか、あるいは IBM SOA Sandbox のオンライン試用版で、DB2®、Lotus®、Rational®、Tivoli®、および WebSphere® などが提供するアプリケーション開発ツールやミドルウェア製品を試してみてください。
  
  

議論するために

• developerWorks blogs から developerWorks コミュニティーに加わってください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• 目標
• 概要
• 用語の定義
• 動機
• ポリシーおよびルールの抽象化レベル
• トップダウン方式による取り組み – ビジネス層
• ビジネス・ゴール、ビジネス・オブジェクティブ、そしてビジネスの結果
• アーキテクチャー層
• 運用層
• まとめ
• 参考文献
• 著者について
• コメント