Business Rules Come First

最近、同僚と私は大規模なクライアント組織のチーフソフトウェア開発者と、そこでの主要な再設計作業の進捗状況につい 私たちの懸念は、プロジェクトチームのメンバーが大規模なプロトタイプを提供するためのいくつかの九ヶ月の期限を満たすことがで 私たちは、包括的なビジネスモデルを開発するためにいくつかの集中的なヶ月を費やしていましたが、彼らはまだ完了するまでに数ヶ月のシステ

このチーフ開発者は非常に鋭い—軽く答えにコミットするものではありません。 長い間、彼は何も言わなかった、思考に失われた。 最後に、すべての周りの壁に漆喰詳細なビジネス図を見て、彼は言った、”我々はすでにコーディングを開始していた場合、私たちは全くチャンスがなかった しかし、我々はまだコーディングを開始していないので、私はチャンスがかなり良いと言うだろう。”

私は彼の意味を捉える前に、私の心の中でそれを何度も実行しなければなりませんでした。 “すでにコーディングを始めていたら、私たちはまったくチャンスがなかったと言うでしょう。”

私は彼がアプリケーションコーディング自体がかなり厳しいと思っていたことを知っていました。 これは、ルールエンジン、世界的な流通ネットワーク、グラフィカルユーザインタフェース、およびいくつかの重要なミドルウェアを使用することを含みます。

彼は、彼らがコーディング中にすべてのビジネス上の問題を解決しなければならなかった場合、彼らは時間内にそれをやってのけることはないだろうと言っていた—またはおそらくこれまで。 しかし、プロジェクトチームは厳しいビジネス上の問題（ビジネスルールの指定を含む）に先行して取り組んでいたため、目標日までにコードを完成させる可

大規模な尺度では、ビジネスルールのアプローチは、単に適切な人々の適切な質問をすることです。 正直に期限を満たすための唯一の方法があります—それは最初にビジネス上の問題を解決することです。

ビジネス主導型IT

ビジネスシステムを構築する初期の頃は、ビジネス側は本質的に後ろに座って、それらを実現させることができました。 自動化の利点は、あなたが事実上間違っていないことができるように説得力がありました。 今、すべての実用的な目的のために、ビジネスとITは不可分に動作します。 プロジェクトを実施するとき、論理的なステップは、シームレスなビジネス/ITプロジェクトチームをまとめ、要件を開発するためのビジネス指向のアプロー しかし、多くの企業は、今日それを行うにはどこにも近くありません。

あまりにも頻繁に、ビジネス側はまだあいまいで、悪い焦点を当てた”要件”を生成し、IT側はプログラミングの上に”要件”を続けています。 要件を開発する際のビジネス専門家とIT専門家の間のこのギャップをどのように排除できますか？

答えは比較的簡単です。 ビジネスには、ビジネスの専門家が要件の開発を推進できるようにする組織的なアプローチが必要です。 このアプローチは、適切なタイミングで適切なものについて適切な種類の質問をする方法を示すロードマップを提供する必要があります。 必要なのは、ビジネス主導のアプローチです。

従来の開発アプローチでは、通常、先行要件を実際の実行中のシステムに変換する際に多くが失われます。 しかし、一連の明確なビジネスルールを記述することで、ビジネス側とITの間のコミュニケーションが改善され、ビジネス分析とシステム設計の間の橋渡しを提供します。 ビジネスルールのアプローチは、ビジネス側とIT側の間の要件のギャップを埋めるのに役立ちます。

では、ビジネスルールとは何ですか？ ビジネスの観点からは、それは行動に影響を与えるか、または導くことを意図した指令です。 ビジネスルールは、文字通りあなたのビジネス慣行のエンコードされた知識です。 ITの観点から見ると、ビジネスルールは再利用可能なビジネスロジックのアトミックな部分です。

ある意味では、誰もがビジネスルールが何であるかを知っています—彼らはあなたのビジネスが日々の操作を実行する際にガイドするものです。 ビジネスルールがなければ、常にその場で意思決定を行い、ケースバイケースで代替案を選択する必要があります。 そのようにすることは非常に遅いでしょう。

ルールは、現実の生活の中で私たちのすべてに精通しています。 私たちはルールによってゲームをし、一連のルールに基づいた法制度の下で生き、子供たちのためにルールを設定します。 しかし、ビジネスシステムのルールの考え方は、ほとんどのIT専門家にとって皮肉なことに異質です。 “ルール”と言うと、多くのIT専門家はエキスパートシステムや人工知能を漠然と考えています。 ビジネスの基本的で日常的な業務にどのように中央ルールが実際にあるかについてはほとんど認識されていません。

偶然ではないが、多くのビジネス側の労働者や管理者は、ルールの観点から考えることが外国または抽象的に見えるかもしれない要件を開発するた ビジネスプロセスのリエンジニアリング、システム開発、ソフトウェア設計など、ほぼすべての方法論がこの点で有罪です。

これは2つの理由で残念です：

1。 ルールの面で組織化された活動について考えることは、実際には非常に自然です。 たとえば、ルールを説明せずにチェス、チェッカー、野球やサッカーのようなゲームを説明しようと想像してみてください。

2. ビジネスサイドの労働者や管理者は、良いルールを作成するために必要な知識を持っています。

サンプルルール

従うサンプルルールを見て、ビジネスシステムの運用管理のあらゆる側面をルールによってどのように対処できるかに注意してくださ

•ヒューリスティック: 優先ステータスを持つ顧客は、すぐに注文を入力する必要があります。

•計算:顧客の年間注文量は、会社の会計年度中に終了した総売上高として計算する必要があります。

•推論:顧客が$1,000を超える5つ以上の注文を行う場合、顧客は優先されるとみなされなければなりません。

•タイミング:顧客が36ヶ月連続して注文しない場合、顧客をアーカイブする必要があります。

•トリガー:注文が出荷されるときに、注文に対して”事前通知を送信”を実行する必要があります。

ルールは用語と事実に直接基づいて構築されます。 顧客、出荷、請求書などの用語は、ビジネスにおいて正確で明確な定義を持つ必要があります。 たとえば、「顧客」は、「過去2年間に少なくとも1つの有料注文を行った組織または個人」と定義されます。”

ファクトは、”Customer places order”のような動詞または動詞句と用語を接続する単純な宣言文によって与えられます。”

“ファクトモデル”とは、事業運営の結果を記述するファクトステートメントのセットです。 ファクトモデルは、データモデルの初期の青写真として機能する必要がありますが、その主な目的は、それを所有するビジネス側の労働者や管理者か

ルールは、基本的に、”credit1,000を超えるクレジット注文は、クレジットチェックなしで受け入れてはならない”のように、用語と事実にmustまたはmust notという言葉の意味を追加します。”

ルールは、明確な主題から始めて、明確で明確な、よく構造化されたビジネス英語で表現する必要があります。 規則に綿毛および行方不明の事実がないべきである。 “出荷額が$500を超える場合、出荷に保険をかける必要があります。”とルールは、のように、タイミング基準を含めることができます”学生は、登録の終わりまでに少なくとも二つのコースに登録する必要があります。”

ルールの独立性

ビジネスは人間の体に非常に似ています。 知識（用語と事実）の構造は骨格のようなものであり、プロセスは強力な筋肉であり、ルールは他の二つを制御する神経系です。 すべての三つは不可欠であり、相互に関連しています。 しかし、ビジネスルールは他の2つとは別のものにする必要があります。 このアプローチの基本原則は、ルールがプロセスと手順とは独立しているということです。 その”ルールの独立性”のフリンジの利点は、プロセスの巨大な簡素化です。

その結果、多くのITプロフェッショナルの長年の目標である”シンプロセス”が生まれました。 プロセスからルールを取り除くことで、比較的単純で、必要に応じて変更できるプロセスを生成することができます。

ナショナルフットボールリーグでは、チームのためにプレーが機能していない場合、それは数試合の中でそのプレイブックから消えてしまいます。 演劇は本質的に投げ捨てられています。 同様に、企業は自分の手続きを捨てるものとして見る必要があります—手続きがもはやうまく機能しなくなったときに容易に捨てて交換するのに十

使い捨ての手続きは、ビジネスが適応可能で競争力があるためには必須です。 この一見単純なアイデアは、ビジネスルールのアプローチによって可能になり、作業の行われ、システムの設計方法に革命をもたらす可能性があります。

Ronald G.Ross(Addison-Wesley,2003)によるPrinciples of The Business Rule Approachの許可を得て転載されています。 ロスはBusiness Rule Solutions LLCの共同創設者および校長であり、WebサイトのエグゼクティブエディターですBRCommunity.com.

ライブラリファクトモデル
この図は、ライブラリのグラフィカルファクトモデルを示しています。 ルールの文言は、基本的なビジネス概念-知識構造の図であるファクトモデルに直接基づいています。 ファクトモデルは、データが最終的にデータベース内でどのように編成されるかについての最初の設計図を提供することができます。 ルール: 図書館カードは、カードが許可されている図書館が所有している場合にのみ、本をチェックアウトするために使用することができます。