‘BRA(ビジネスルールアプローチ)’ カテゴリーのアーカイブ

ルールエンジンとシステム内製

2011年10月10日 月曜日

 先週紹介した日経コンピュータの記事には、クラウドとルールエンジンの組み合わせを使った開発でのメリットとして8つあげられていました。このうちの8番目「内製しやすい」というのが今日のテーマ。
 確かにビジネスロジックをルールエンジンを用いて実装すると、ロジックのシステム的な制御部分を隠蔽し、本質的な部分を浮き彫りにさせる効果があります。今回あがっている保険商品の整合性チェックとか保険料の試算などは、ロジック自身はそれほど複雑でないので、ビジネスロジックをたとえば表形式(デシジョンテーブル)でまとめれば、それがほぼそのまま実際に動きます。DroolsではDSL(ドメイン記述言語)もあるので、DSLをうまく設計すれば「日本語で仕様を書けばそれがそのまま動く」といった世界を実現することも夢ではないかもしれません。たとえば

 保険料は、基本料率 * ○○割増 * 保険金額である。
  ただし
 …の場合は○○割増は1.03
 …の場合は○○割増は1.05

とかいったような。こんな感じで書いた仕様がそのまま動くとなると、業務に携わる人が直接プログラムを保守するということも現実解として十分考えられるようになってきそうです。

 今のところ日本ではBRMS(ビジネスルール管理システム)を使って、現場で業務に携わる人が直接ルールを直すという事例はまだ聞いたことはありません。ただ、ごく一般的な日本の事務現場のExcelシート、マクロの開発力(!!)などを考えると、BRMSでの現場での修正開発も案外いけるのかもしれないなあと思っている今日この頃。
 というわけで、最近「システム内製を極める」という本を読みました。基本的に日経コンピュータの記事を集めた内容なので比較的さらっと読めるのですが、最後「おわりに」には、システム開発にたずさわるものとしては考えさせられることが書いてあります。それはまた次の機会に。



エンタープライズマッシュアップ

2011年10月2日 日曜日

 Web2.0やマッシュアップという言葉が流行っていたころ、一部で「エンタープライズマッシュアップ」という言葉が使われた時期がありました。まあ、読んで字のごとく、「企業におけるマッシュアップ」ということで、その心は社内外のWeb-APIを組み合わせて企業内のポータルなどを構築する方法論というようなイメージでしょうか。最近はあまり聞かれなくなりましたが、ことさら「マッシュアップ」という言葉を使わなくても、Web上での開発のひとつの方法論としてある程度定着したからなのでしょうか。

 さて、この言葉を思い出したのは、最近ある雑誌の記事を読んだからです。日経コンピュータの最新9月29日号の「システムを「作らず」に作った」という記事。今回作ったシステムは、ユーザインタフェース部分でひとつのクラウド、帳票生成サービス用のクラウド、ルールエンジン用のクラウド、3つのクラウドの間で通信しながら処理を行うというまさに 「クラウド間でSOAを実現しちゃいました」 的なちょっとおもしろいシステムです。そこそこのパフォーマンスも出ているようで一昔前なら夢物語だったような世界が手の届くところまで来たということですね。

 もちろんこのブログの趣旨からして強調したいのは、ルールエンジンでして・・・^^;。最近のルールエンジンのひとつの典型的な使い方として、今回の例のように、保険料の計算や整合性チェックなどのビジネスロジックの処理部分を、ルールエンジンを用いて独立したWebサービスとして提供するというのがあります。そして将来的には、このサービスをさまざまなアプリケーションで使いまわすということ…もっとも、日本国内で「さまざまなアプリケーションで使いまわす」というところまで行っているところはさすがにまだ聞いたことがないのですが…。

 今回、ルールエンジンがクラウドにのったということになると、上記のようなことがやりやすくなるだけでなく、(もちろんセキュリティの面など解決しなければならないことは多いですが)ルールエンジンを用いてビジネスロジックの処理をサービスとして提供するような可能性、幅がより拡がってくことになるでしょう。冒頭に述べた「マッシュアップ」は、ウィジェットを組み合わせてユーザインタフェース部分をひとつにまとめる感が強いですが、今回のケースは、もう少しビジネスのロジックに踏み込み、クラウドに散在するWebサービス間で物事を処理していく、いわばインターネットSOA、クラウドtoクラウドSOAが始まりつつあるということではないでしょうか。

 最初はルールエンジンの話を書こうと思っていたのですが、結局最後はSOAの話になってしまいましたね。長くなるのでルールの話はぜひ記事を…。

(2012年1月12日追記) この日経コンピュータの記事は、日経の電子版の12月28日つけ記事「システムを「作らず」に作った…得られた八つの利点」として読めるようになりました。

Agile Business Rule Development (ABRD)

2011年9月12日 月曜日

 ずいぶん久しぶりの投稿になってしまいました。というのも最近、ルール関連の案件が増えてきたおかげで、うれしい悲鳴というのでしょうか。多忙な日々をすごしておりました。

 ブログを書かない間、Droolsは5.2が出ているし・・・、「アイログ」と入れてググってみると、アイドルグループ育成ゲームが出てきたりするようになっていたり・・・。それはともかく、本日は本の話。前に Amazon で予約していた本なのですが超多忙な時期に出版・送付されてきたもので本棚に積み上げ状態になっておりました。その本は

Agile Business Rule Development: process, Architecture, and JRules Examples
  Jerome Boyer、 Hafedh Mili

 IBM(アイログ) の JRules を例にとってはいますが、方法論としてはツールに依存したものではなく、JRules以外でも使えます。その名のとおり一般的な Agile な開発方法論をベースにしており、ドキュメントよりも動くソフトウェアを重視する、利用者との密なコミュニケーションなどといったAgile方法論の原則に則った反復型の開発方法論。
 まだ読み始めたばかりのこの本ですが、久しぶりに出版されたビジネスルールによる実践的なシステム開発の本と言えましょう。ボリュームはありますが、その割りには読みやすいように思えます。JRulesを使わない方も目を通す価値があるのではないでしょうか。



オントロジー(2)

2010年3月22日 月曜日

そもそもビジネスルールは、その if 部分とワーキングメモリ(一時記憶)の中のファクトとが「パターンマッチ」されることで実行が進んでいくわけで、ファクトの「パターン(文字列)」はきちんと規定されている必要があります。さらにファクトの意味が同じファクト(パターン・・・文字列)に対してブレてしまうと、それぞれのビジネスルールの意味も変わってきてしまうので、ファクトの意味についても厳密に定義されていなければなりません。

ファクトのパターンとその意味が厳密に規定されたモデル・・・ファクトモデルは、このようにビジネスルールのシステムの基盤として非常に重要な存在です。さらにビジネスルールを用いたアプリケーションシステムが多数存在する、「企業」のレベルまで考えを拡げてみましょう。すると、これらビジネスルールの基盤となるファクトモデルは「企業」のレベルで共通のものになっていないとアプリケーションシステム間の相互運用性が保証されないことになってしまいます。

さて、(1)の項でファクトモデルがオントロジーにあたると書きました。すると「企業」のレベルで共通のものになっているファクトモデルとは、「企業」オントロジー・・・エンタープライズ・オントロジーということになります。

実はエンタープライズ・オントロジーというのは、オントロジー研究の中で昔から言われており、古くはエジンバラ大学の応用人工知能研究所研究トロント大学のエンタープライズインテグレーション研究所TOVEプロジェクトなどから、最近は成書も出ていたり、セマンティックWebの観点から注目されたりしてします。

ビジネスルールの世界は実践重視の世界なので敢えてオントロジーという言葉はあまり出てきませんでしたが(この辺の事情は、たとえばBusiness Rules in the Semantic Webなどを参照)、昨年あたりからEUのONTORULEプロジェクトなどというのが出てきたりしています。このプロジェクト、ONTOlogies meet business RULEs という名前が示すとおりオントロジーを基盤としてビジネスルールを用いたシステムを具体化していくプロジェクトです。いよいよオントロジーがビジネスルールの世界で俎上にのぼってきたということでしょうか。



オントロジー(1)

2010年3月15日 月曜日

元ジャストシステム社長の浮川さんが作った会社MetaMojiからOntoGearというオントロジー工学をベースにしたツールが公開されるとのこと。

元ジャストシステム浮川氏のMetaMoJi、初の製品となる「OntoGear」を5月に公開

久しぶりに「オントロジー」という言葉をプレスリリースなどで見て勉強しなければ・・・と思った次第。というのも、この「オントロジー(ontology)」、ビジネスルールアプローチやBRMSと非常に関連がありまして・・・(もっとも「OntoGear」というツールはBRMSやBRAというよりもむしろ応用人工知能的なツールです)。

「オントロジー」とはもともと「存在論」という意味の哲学用語ですが、コンピュータの世界で使われるときには物事・概念の間の関係性を記述したモデルとでも言うのでしょうか。イメージ的には、用語間の関係としてみたクラス図とか概念データモデルというと近いかもしれません(実際のオントロジーの実例としては「法造~オントロジー構築・利用の研究サイト~」などを見てもらえばよいかと)。

で、オントロジーをビジネスルール(BRA、BRMS)の世界に持ってくると、これが実はファクトのモデル(fact model)になるわけです。実際、ビジネスルールを書いていく上での基盤となるファクトモデルは、ビジネスルールが対象とするドメインのオントロジーといえます。たとえば企業活動というドメインを考えた場合、まず用語としては「顧客」「注文」「従業員」・・・などがあげられ、その関係性としてのファクトは、「顧客は注文を出す」、「従業員には性別がある」・・・などといったことになりましょう。

(この項続く)