Oswald Regular
OpenSans Regular
Business Rules Environment

Ab Initioは幅広いユーザー層にサービスを提供しています。そのユーザー層の一端に位置するのが、専業のアプリケーション開発者です。アプリケーション開発者は複雑な環境で大量のデータを処理する高度なシステムを設計し構築する方法を理解しています。このような専門家達を対象に、Ab Initioは複雑なプロセスおよび業務ロジックをグラフィカルに構築するためのグラフィカル開発環境(GDE®)を用意しています。生成したアプリケーションは非常に堅牢でスケーラブルなCo>Operating System®で実行されます。

Ab Initioを利用するユーザー層のもう一方の端が業務ユーザーです。業務ユーザーにとって、1秒間にテラバイト単位のデータや数千件のメッセージを処理するメカニズムなどは専門外であり、関心がありません。ただし、これらのシステムが何を実現するかを理解し、データの詳細や業務を遂行する手順についてよく知っています。

長年にわたり、IT部門と業務部門との間で分業が進展してきました。IT部門は業務部門にサービスを提供する関係にありますが、それは時に反目し合う関係でもあります。業務ユーザーは自分たちが求めていることと、その業務上での意味を知っています。ITプロフェッショナルはそれを処理する方法を知っています。業務ユーザーはIT部門が必要とする仕様書を提供するために最善を尽くします。ところが、作成された仕様書に曖昧さや誤りは付き物です。仕様書をコードに変換するときのミスも避けることはできません。仕様書からコード、テスト、リリースと移行するプロセスが、皆が望むほど手際良く迅速に運ばれることは決してありません。段階ごとに、それを請け負った人が提供者の意図を解明する必要があります。これには時間がかかり、さらに悪いことに、間違いを引き起こす大きな要因でもあります。誤りを検出し、仕様書を修正し、コードを変更するには、さらに多くの時間がかかることは言うまでもありません。生産性にも悪影響を及ぼします。正確性を完全に保証することはできません。時には、この繰り返しは収束することなく、プロジェクトは失敗に終わります。

もし、業務ユーザーが、業務ロジックを実装するシステムの特定の部分を制御できたらどうでしょうか。業務ユーザーが、自分が理解できる方法で業務ロジックを表現することによって業務ルールを作成し、さらに、その業務ルールが大規模なシステム内で実行されるコードに自動的に変換されることができたらどうでしょうか。良い考えだと思いませんか?これがBusiness Rules Environmentの背景にある全体構想です。

Ab Initio® Business Rules Environment(BRE®)では、業務アナリストの使い慣れたグリッド形式のスプレッドシート方式で業務ルールを指定できます。BREでは技術専門用語ではなく業務用語でルールを指定するので、Microsoft Excelの使用経験があれば誰でも理解できます。そのため、ルールを迅速かつ正確に記述できるだけでなく、他の業務ユーザーでも簡単に理解できます。

さらに、BREを使うと、業務ユーザーが業務ルールの確認を行うことができます。業務ユーザーは、業務ルールをシステムに直接実装できるだけでなく、その適用結果をすぐに確認してデータをテストすることもできます。テストの結果が予想に反する場合は、その場でルールを変更できます。これにより時間を大幅に節約できます。

スタンドアロンツールではないAb Initio® Business Rules Environment

従来の“ルールエンジン”製品はスタンドアロンツールです。そのため、他の製品やその他のコンピューティングインフラストラクチャと協調稼働させるための作業を必要とします。また、従来のルールエンジンにはパフォーマンスおよびスケーラビリティの限界があり、簡単なデータ構造しか処理できません。そのスコープは処理する業務ルールに限られており、システム全体の系譜をたどることができません。

Ab Initio BREはAb InitioのCo>Operating Systemおよびメタデータテクノロジと緊密に連携しているので、このような問題や限界などがすべて解決されます。BREは、このような設計と実装を目的として始めから構築されており、典型的なソフトウェア会社のマーケティング戦略から生まれたものでも補足的製品でもありません。

  • BREルールは、再実装せずに、バッチ、コンティニュアス、Webサービス、およびリアルタイムのアプリケーションで実行できます。
  • BREルールの実行効率は非常によく、多数のCPUやサーバーにわたって実行することもできます。Ab Initioで構築されたシステムのスケーラビリティには制限がありません。
  • BREルールは複雑なレガシー階層データを処理できます。レガシー環境に存在するもの(EBCDIC、パック10進数、世界の多様な文字コードセット、XML、COBOLコピーブックなど)はすべて、BREがCo>Operating Systemと連動してネイティブに処理できます。
  • BREルールは、Co>Operating Systemでサポートされているすべてのプラットフォーム(Unix、Linux、Windows、z/OS、およびz/Linux)で同じように実行されます。
  • BREでは、エラー処理やチェックポイントなど、Co>Operating Systemの堅牢性を実現する機能のすべての利点が活用されています。

“業務ルール”とは

BREでは、決定ルール、検証ルール、マッピングルールという、スタイルが異なる3つの業務ルールがサポートされます。これらのルールは基本的に類似し、業務ユーザーはどのルールもこれら3つのカテゴリのいずれかに当てはまると考えています。

業務の特性に応じて、簡単で短いルールの場合も、極端に長く複雑なルールの場合もあります。いずれの場合も、BREであれば対応可能です。現在運用されている最大のBREルールセットには、5万以上のルールから構成されているものがあります。

次に、BREで記述された非常に簡単な決定ルールの例を示します。この例は米国の所得税計算です(フォーム1040)。

このルールには、「申告資格」と「課税対象額: ライン43」の2つの入力があり、「税額: ライン44」という名前の1つの出力を計算します。BREでは、列の間に暗黙的なAND演算子、行の間に暗黙的なELSE演算子があります。そのため、このルールの最初の数行は次のような意味になります。

「申告資格」が「独身申告」であり、かつ(AND)「課税対象額: ライン43」が100000以下である場合、「税額: ライン44」は「税額テーブル」内の「課税対象額: ライン43」をルックアップして「申告資格」ファイラの量を返すことと等しくなります。

それ以外の場合で(ELSE)、「申告資格」が「独身申告」であり、かつ(AND)「課税対象額: ライン43」が100000より大きく、171550以下である場合、「税額: ライン44」は「課税対象額: ライン43」に0.28を乗算して6280.00を減算した値に等しくなります。

それ以外の場合で(ELSE)、「申告資格」が「独身申告」であり、かつ(AND)「課税対象額: ライン43」が171550より大きい場合、…

… 以下、同様に続きます。

次に、検証ルールの例を示します。この検証ルールでは、複数の入力を同じルールで検証し、それぞれについて、複数の出力を書き出しています。

次に、ソースからターゲットへのマッピングルールの例を示します。このスタイルのルールの場合、BREはフィールド、変数、定数、計算値などの入力値を左側に表示します([入力]列)。中央はターゲットフィールドのリストです([出力名]列)。各ターゲットフィールドの右側は、[式/ルール]列です。この列には、[入力]列からの値をドラッグしたり、出力値を計算する式を作成したりします。([計算値]列については後で説明します)。

任意の複雑なロジックを含めることができるBRE®ルール

BREルール内のロジックは、前述の例のように簡単な場合もありますが、多くの場合、実際に業務ユーザーが示すルールは非常に複雑です。Ab Initio以外のテクノロジを使用する場合、業務ルール製品にこれらのルールを実装できません。代わりにC++やJavaなどのプログラミング言語でハンドコーディングすることになります。これは有用性や生産性に多大な悪影響を及ぼす可能性があり、仕様作成、解釈、コーディング、テスト、修正という循環が生じてプロジェクトを失敗へと導きます。

Ab Initio BREではこのようなことはありません。BREは、Co>Operating Systemのデータ処理機能を完全に継承します。つまり、BREでは、何百種類ものCo>Operating System関数のすべて、および複雑なロジック構造を使用できます。

結果として、ルール内の式のサイズや複雑性、ルール自体のサイズや複雑性、ルールセット内のルールの数に制限はありません。

業務ユーザーによる組み込みテストを使用したルールの検証

Ab Initio Business Rules Environmentを使用して業務ルールを開発する主な利点は、BREの組み込みテスト機能にあります。BRE内で開発したルールは、編集環境を離れることなくサンプルデータに対して実行できます。テスト中、BREはテストレコードごとに計算された出力とともに、すべての中間変数や計算の状態も報告します。BREユーザーは、出力レコードを調べ、計算された値をクリックすると、その値がなぜ、どのように計算されたかが示されます。

BREでは、テストレコードごとに、一致した条件は黄色で、比較に失敗したセルは暗く表示されます。また、それぞれのルールが一致した回数も計算されます(上図の[一致回数]を参照)。この情報を基に、欠落したテスト条件や構成が正しくないルール(条件が一致しない場合)を見つけることができます。

テストはルールの開発中いつでも実行できるので、多数のルールを作成する際にインクリメンタルアプローチが可能です。ルールをすべて入力するのを待たずに、いつでも動作の評価を行えます。

テスト実行の出力をベンチマークとして保存し、後で行うテスト実行と自動的に比較するように設定できます。ルールの開発中や変更の設計中にルールを変更した場合、変更後のルールの動作と保存したベンチマーク結果の違いをすべて確認できます。この機能は、提案された変更の影響を評価する場合に非常に役立ちます。Ab Initio BREがないと、業務ユーザーはルールの変更を“勘”で行うことになります。

さらに、ルールの実行の詳細も運用環境で実行中のルールセットから取得できます。ユーザーは、各入力レコードに対してどのルール条件(行)が一致するかという情報から、すべての入力、ルックアップ、中間、および最終値に至るまで、保存されるトラッキング情報の量を設定できます。これらの情報を基に、アナリストは長期間にわたるルールの動作を調査し、業務ロジックを調整することで結果が向上する場合もあります。また、これらの詳細は、ある決定が過去にどのように行われたかということを知るためにも不可欠です。

透明性 - 業務ロジックの可視化

大きく複雑な業務ルールシステムは、他のルールの上に実装された多数のルールから構成される場合があります。これらのルールがどのように相互に関連し、データがその間をどのように移動するのかを理解することは、業務ユーザーにとって重要です。残念ながら、一般的な業務ユーザーは自身のシステムがどのように機能するかをほとんど知ることができません。

BREを使用すると、業務ユーザーはシステムを完全に見通すことができます。これは、BREではルールの規模や複雑さに関係なく、相互に関連付けられたルールの中をデータがどのように移動しているかがチャートで表示されるためです。さらに、多数のルールセットで構成されるアプリケーションについてのグラフィカルな系譜を表示できます。これらのルールセットは1つのアプリケーションの全体に分散されている場合も複数のアプリケーションにわたって分散されている場合もあります。

次の図は、米国のUS 1040 EZフォームに基づいて所得税を計算する前述のルールセットの簡単な系譜の例を示しています。緑の楕円はルール(計算)を、角の丸い長方形は変数をそれぞれ表しています。テストモードでは、サンプルテスト値がすべての中間計算とともに各変数名の下に示されます。全体の系譜図の下には、控除の計算(ライン5)が最終的な還付や未払い金にどのような影響を与えるかを示す部分の拡大図があります。

BREの系譜機能を使用すると、業務ユーザーは、多数の複雑なルールがどのように機能するかを正しく理解できます。

不要な“RETEアルゴリズム”

RETEとは何でしょうか。心配する必要はありません。BREを使用すれば、これを理解する必要はありません。ただし、従来のルールエンジンでは“RETEアルゴリズム”と呼ばれるものによって決められた順序でルールが実行されます。これは、業務ユーザーがかなり複雑なコンピュータサイエンスおよび人工知能の概念を理解しなければならないことを意味します(詳しく知りたい場合は、http://ja.wikipedia.org/wiki/Reteアルゴリズムを参照してください)。

実際のところ、RETEアプローチがルールの変更の影響を理解することを難しくしています。これは、変更が仕様内の遠く離れた他のルールに影響を与える可能性があるためです。また、小さな変更が意図しない大きな影響をもたらす可能性があるので、パフォーマンスの調整も非常に難しくなります。

BREでは、ルールは指定した順序で実行されます。パフォーマンスが大幅に向上することは言うまでもなく、コンピュータ科学者となってルールの動作方法を解明する必要もなくなります。

BREとCo>Operating System®の連動

BREは、ユーザーが作成したルールから、Co>Operating Systemによって実行されるグラフのコンポーネントを生成します。詳細については、コンポーネント、グラフ、およびCo>Operating Systemを参照してください。

業務ルールはCo>Operating Systemで実行されるので、Co>Operating Systemの利点や長所がすべて継承されます。利点や長所とは、データソースまたはターゲットとの相互作用が可能で、あらゆる種類のデータを処理できること、膨大な量のデータを処理できること、バッチやリアルタイムで実行できること、異なるオペレーティングシステムを実行する複数のサーバーで分散して実行できることです。これらはすべて完全に堅牢な方法で行われます。Co>Operating Systemには堅牢な基幹アプリケーションの構築と実行に必要なすべてのものが含まれており、BREはこのすべてを継承します。

次に示すCo>Operating Systemグラフ(アプリケーション)の例では、主要なコンポーネントにBREで記述されたルールが含まれています。

完全なルールの管理と統合

すべてのルールは、バージョン管理を含め、完全なソースコード管理機能を持つAb Initio Enterprise Meta>Environment®(EME®)に保存されます。そのため、BREルールには、次に示す2つのデプロイ方法があります。

  • ルールを他のアプリケーション要素のように扱う方法。これは、開発、テスト、運用の順に移行する、標準のコードプロモーション段階をすべて通過する必要があることを意味します。この堅牢な方法はIT技術者にはよく知られた手法ですが、多数の段階を通過するには多くの時間を要します。しかし、BREの統合されたテストプロセスでは、プロセス全体が合理化され短縮されています。
  • ルールを運用データベースの参照コードデータに近いものとして扱う方法。多くの場合、業務ユーザーは参照コードを変更(追加、更新、削除)できます。そうすると、アプリケーションコードのプロモーションプロセス全体で変更を実行する必要がなく、業務のニーズにすばやく対応できます。

どちらの方法を採用するかは、お客様の要件に合わせてお選びください。

最後に、EMEの強力なバージョン管理機能のおかげで、ユーザーはルールを“2者選択”方式でデプロイできる環境を簡単に設定できます。これは、同じルールの2つのバージョンを並列で実行し、その出力を比較して対比するという考え方です。こうすることで、両者の相違点を調べ、必要な結果が得られるまでルールを改善することができます。

企業システムと統合テクノロジの一体化

統合された対話式のテストプロセスと、運用レベルの実行可能モジュールの自動生成機能を備えたBREを使用することで、業務ユーザーはITスタッフの専門知識を補足するような方法でアプリケーションの開発に直接参加できます。業務ユーザーが表現し理解できるように業務ロジックを示すことによって、 BREは新しいアプリケーションの開発やデプロイに伴う不確かさやリスクを大幅に低減できます。

BREのルールとそのルールによって駆動されるアプリケーションは、Co>Operating Systemによって実行されます。これは、ルールの複雑度を自由に変えることができ、それでも効率的に実行可能であり、完全なスケーラビリティがあることを意味します。さらに、ルールを再度コード記述することなく、バッチアプリケーションおよびWebサービスアプリケーションで実行できます。実際、Co>Operating Systemのすべての利点はBREを通して実現されます。なぜでしょうか?それは、BREがCo>Operating Systemと同じ統合テクノロジで構築されているためです。BREとCo>Operating Systemはシームレスに連携して企業システムを一体化します。

English
Français
Español
Deutsch
简体中文
言語:
日本語