IBM Operational Decision Manager v8.8 ルール・ガバナンス・ガイド 1/19 目次 目次 .............................................................................................................................................. 2 1. 2. 3. はじめに ................................................................................................................................ 3 1.1. ガイドの目的 ................................................................................................................. 3 1.2. ガイドの構成 ................................................................................................................. 3 アプリケーションのライフサイクルとガバナンス .............................................................. 4 2.1. 変更管理 ........................................................................................................................ 4 2.2. アクセス制御 ................................................................................................................. 4 変更管理 ................................................................................................................................ 5 3.1. 変更管理に関する Decision Center の機能 ................................................................. 5 ガバナンス・フレームワーク機能 .................................................................................... 5 3.2. 4. Decision Center がない場合の変更管理 ...................................................................... 6 アクセス制御 ........................................................................................................................ 7 4.1. アクセス制御の種類 ...................................................................................................... 7 4.2. ユーザー・セキュリティー ............................................................................................ 8 4.2.1. ユーザーの分割 ...................................................................................................... 8 4.2.2. 業務ユーザー/IT ユーザーの使用ツール ............................................................... 9 4.2.3. Business Console の GUI を利用したユーザーの登録 ....................................... 10 4.3. プロジェクト・セキュリティー ................................................................................... 14 4.3.1. プロジェクトの分割 ............................................................................................ 14 4.3.2. ODM におけるプロジェクト・セキュリティーの設定 ....................................... 15 5. おわりに .............................................................................................................................. 18 6. 参考資料 .............................................................................................................................. 19 2/19 1. はじめに 当資料では、ルール・アプリケーションのガバナンスについて、変更管理とアクセス制御の観点 から紹介します。機能に関する記述は IBM Operational Decision Manager (以下、ODM) v8.8.1 に即します。 1.1. ガイドの目的 ビジネス・ルール管理システムを利用する重要なメリットとして、ビジネスの変化に素早く対応 できるようになることが挙げられます。このメリットを最大化するには、初期開発は主に IT 部 門の担当者によって行われるとしても、それ以降のルール・アプリケーションの変更は業務部門 の担当者に委ねられ、業務担当者によって考えられたビジネス・ルールの変更が迅速に反映され ることが、望ましいと考えられます。 上記のようなルール・アプリケーションの継続的な変更を効率的に進めるには、その変更の目的、 対象のルール、時期、担当者などの情報が常に確認可能な形で保管され、その情報のとおりに変 更が進められる必要があります。この状態をガバナンスが利いている状態と呼びます。 アプリケーションのガバナンスを利かせることで、例えば、開発担当者が誤って別のチームのル ールを変更してしまったり、業務担当者がテスト中のルールを誤って別のサーバーにデプロイし てしまったり、といったことを予防することができます。 本ガイドでは、業務ユーザー主体のビジネス・ルール管理において必要となるガバナンスについ て指針を提示し、ODM におけるその実現方法について実際の手順を示します。 1.2. ガイドの構成 本ガイドでは、大きく変更管理とアクセス制御とに分けて、ODM での効率的な管理の実施方法 を解説します。 ２章では、アプリケーションのガバナンスの全体像について解説します。３章では変更管理につ いて、４章ではアクセス制御について、それぞれ ODM の機能を含めて解説します。 3/19 2. アプリケーションのライフサイクルとガバナンス アプリケーションには、開発～テスト～リリース～廃止のライフサイクルがあります。さらに稼 働と廃止の間に、変更開発とそのテストや稼働（リリース）といったイベントが発生することも ありえます。それらの確実かつ安全な実施のためには、 「いつ実施したのか」 「次に何を実施する のか」といった変更の管理と、 「何を誰が実施可能なのか」というアクセス制御が必要となりま す。そのようにアプリケーションのリソースや運用の変更管理・アクセス制御を行うことをアプ リケーションのガバナンスと呼びます。 リリース計画 ライフサイクル中のステップ ・変更理由 主な担当部門 ・変更箇所 ・担当者、承認者 開発 テスト 開発 リリース 変更開発 テスト 業務 業務 業務 開発 開発 開発 リリース … 運用 運用 廃止 運用 図 1 アプリケーション・ライフサイクルのステップと担当部門の例 上の図はアプリケーションのライフサイクルを簡略的に示したものです。初期開発時には IT 部 門を主体とした開発が行われますが、以降の変更開発では、業務部門主体による開発とテストが 行われることを想定しています。また、変更時にはリリース計画によって変更理由・変更箇所・ 担当者・承認者をあらかじめ計画し、これに沿って変更を進めることでガバナンスを利かせます。 2.1. 変更管理 変更管理では、アプリケーションの変更内容、変更箇所、変更理由などを保管し、遡って確認で きるようにします。また、変更開発の際には、リリース計画にもとづいて、誰がいつまでに何の 作業を行うのか、その進捗状況などを管理します。変更管理と ODM の機能については３章で詳 しく説明します。 2.2. アクセス制御 アクセス制御では、ある作成物を変更・参照できる権限を、必要な者のみに制限します。そのた めには、ユーザー／グループ管理とプロジェクト管理を適切に設定する必要があります。ODM V8.8.1 では、Business Console のユーザー管理機能が強化されました。 アクセス制御の詳細については、新しいユーザー管理画面も含め、４章にて詳しく説明します。 4/19 3. 変更管理 変更管理をするには、あるアプリケーションの変更内容、変更箇所、変更理由などを保管し、遡 って確認できるようにすることが基本です。その管理対象のレベルにより、ソースコード管理、 リリース管理、作業管理の３つの管理があります。 ソースコード（ODM の場合は、アクション・ルールや意思決定表の記述）の変更内容、変更箇 所、変更理由などを管理することを、ソースコード管理と呼びます。 さらに、実際の環境では、いくつかの変更を集積して新しいバージョンとしてリリースすること があります。何番の変更までがバージョン２に含まれて何番以降がバージョン３に含まれるのか を管理しておく必要があるでしょう。変更の何番から何番がどのリリースに含まれるものなのか を管理することを、リリース管理またはバージョン管理と呼びます。 作業管理のレベルでは、リリースの完了に向けての、開発、テスト、承認といった各作業が現在 どの段階を誰が実施中なのか、次のステップは誰がいつまでに行うのか、といった情報を管理し ます。 ODM では３つのレベルの変更管理をカバーする機能を提供しています。ODM における変更管 理の機能を表に整理すると以下のようになります。 Decision Center DC あり／フレー DC あり／フレー (DC) なし ムワークなし ムワークあり ソースコード管理 SVN などで可能 可能 可能 リリース管理 工夫により可能 不可能 可能 作業管理 不可能 不可能 可能 3.1. 変更管理に関する Decision Center の機能 Decision Center は変更管理リポジトリーの機能を提供しています。これにより、前節で説明し たソースコード管理を行うことができます。 参考： IBM Knowledge Center - ルールの同期化と格納 Decision Center がマスター・リポジトリーとなり、最初の１人の開発者は、ソースの全体をマ スターとしてリポジトリーに公開します。以降は、開発者はマスターのコピーを各自の Rule Designer で変更し、変更後のソースをマスターへ同期化して公開します。これにより、マスタ ーで、どの変更を誰がいつ公開したのかを管理することができます。 参考： IBM Knowledge Center - Rule Designer からの同期化 ガバナンス・フレームワーク機能 上記で説明したのはソースコード管理ですが、リリース管理の機能も Decision Center は提供し 5/19 ています。ガバナンス・フレームワークとよばれるこの機能を有効にすると、Decision Center の リポジトリーでブランチを作成することができます。例えば、次回のリリースのためにブランチ B を作成し、次リリース用の変更は全てブランチ B に対して同期化するようにします。フレー ムワーク内では、次リリース向けに予定されている変更は「変更アクティビティ」として予め登 録しておき、ソースの変更を公開するには必ず変更アクティビティとして作業しなくてはいけま せん。これは一見面倒ですが、リリースに含まれるべき変更、現在までで完了した変更、テスト の状況までも一元管理することができ、しかも作業ごとに実施者と承認者をあらかじめ指名して おける（作業管理） 、非常に強力なツールです。ただし、フレームワークの決められた段取りに 沿って進めていくことが可能なのかは、プロジェクトの事情によっても変わってきます。ガバナ ンス・フレームワーク機能の利用について詳しくは、以下の既存ガイドを参照し、検討してくだ さい。 参考： IBM Operational Decision Manager v8.6 ルール・ガバナンス・ガイド 3.2. Decision Center がない場合の変更管理 Decision Center がない場合も、一般的な変更管理ツール（SVN など）をルール・プロジェク トに適用することで、ソースコードの変更管理を行うことは可能です。SVN などのメジャーな 変更管理ツールにはクライアント機能を Eclipse に追加するためのプラグインがあり、Rule Designer でも使用可能です。このやり方には、クライアント Java アプリケーションと単一の リポジトリー上で変更管理を同期できるというメリットもありますが、ODM の製品提供の機能 ではなくサード・パーティーのプラグインの利用ですから、自己責任で試用／使用してください。 参考： Eclipse Subversive - Subversion (SVN) Team Provider 6/19 4. アクセス制御 4.1. アクセス制御の種類 前述したように、不要なアクセスを防ぐためにも適切なアクセスの制限を設けることは重要です。 ここからは、具体的にどのような観点で制御を行なうと良いのかについて記述していきます。 アクセス制御の付け方には大きく二つの観点があり、一つは”人”に対する制御、もう一つが”モ ノ”に対する制御です。人に対する制御では、業務の種類や内容に基づいてユーザーグループを 作り、そのグループ毎に権限をつけることで、不要なアクセスを防ぎます。モノに対する制御で は、ユーザーが使用するシステム自体を、利用用途により、アプリケーションやプロジェクト単 位であらかじめ分割することにより、アクセスの制限を行います。これらの両方を組み合わせる ことで、アクセスをより詳細に制限することが可能となるため、アプリケーションを設計する際 には、モジュールやプロジェクトの分割方法まで考慮に入れて設計する必要があります。 例として、本社と二つの地域に支店を持つ企業におけるアクセス制御の方法を以下に記します。 本社 関西 グループ 業務ユーザー 関東 全社統括業務ユーザーグループ 本社の業務 関東の支店の 関西の支店の ユーザーグループ 業務ユーザーグループ 業務ユーザーグループ ユーザー IT グループ 全社統括 IT ユーザーグループ 凡例： 大ユーザーグループ 小ユーザーグループ プロジェクトグループ 上図では、緑とグレー枠の四角がユーザーグループ、 青がプロジェクトのグループとしています。 図 2 本社と二つの支店を持つ企業におけるアクセス制御の例 業務ユーザーグループの中には更にグループが構成されており、この場合、全社統括業務ユーザ ーグループと全社統括 IT ユーザーグループのメンバーは、どちらも全社のシステムにアクセス できますが、行える作業が異なります。例えば、全社統括業務ユーザーグループのメンバーは、 業務ロジックに基づいたルールの変更はできますが、アプリケーションのデプロイは行うことが 出来ません。また、各従業員に対して、担当支店の属するエリアのみの情報の閲覧や編集権限を 与えたいのであれば、関東/関西の支店の業務ユーザーグループのようにグループを作成し、権 限設定を行なうことで実現が可能です。このように、必要な人に必要なだけの権限を与えるため に、人とモノの観点からグループを作成・管理するというのが有用です。次項以降は、ユーザー グループやプロジェクトグループの切り分けについてより具体的に説明をしていきます。 7/19 4.2. ユーザー・セキュリティー 4.2.1. ユーザーの分割 この章では、ユーザーグループの作り方について説明していきます。 アプリケーションのユーザーを分割するにはまず、業務ユーザーと IT ユーザーという二つの大 きなグループに振り分けることを検討する必要があります。全ての変更時対応を IT ユーザーに 任せるという場合を除いて、必ずこの二つのグループは発生するためです。あるユーザーをどち らのグループに所属させるかは、そのユーザーが、運用時にどのような作業を行なうかというこ とで決定することができます。 ODM を使用したアプリケーションの場合、以下のように作業切り分けを行なうことができます。 業務ユーザー IT ユーザー ルールの変更/追加/削除・テスト※1 意思決定表やアクション・ルール、ルール・フローの編集※2 Business Console を使用したテスト 業務ユーザーで対応できないルールの変更/追加・テスト※3 XOM,BOM の追加 ユーティリティーの追加 環境へのデプロイ テスト環境へのデプロイ 本番環境へのデプロイ ユーザーの変更/追加/削除 セキュリティー設定 業務ユーザー/ IT ユーザー WAS Console を使用したユーザーの追加・変更・削除 ユーザー/プロジェクトのセキュリティー設定 ルール・プロジェクトの削除 ユーザーの変更/追加/削除 Business Console を使用したユーザーの変更・追加・削除 ※1 ルール変更後のテストを IT ユーザーに移管する場合もあります。 ※2 構造が大きく変わるようなルール・フローの編集は IT ユーザーに委託する場合もあります。 ※3 プログラミングを行なう必要があるため、IT ユーザーが行なう必要があります。 先の例のように、業務ユーザー/IT ユーザーグループの中にさらにグループを作成する場合があ ります。その場合、権限を与える範囲が一致しやすいため、業務の種類や内容といった観点で分 割することが推奨されます。例えば、同じ業務ユーザーの中に、ルール変更の担当者と、変更内 容を確認して承認を行なうマネージャーがいた場合、マネージャーには直接ルールの変更ができ ないように設定し、ルール変更担当者には変更の承認ができないように設定する必要があります。 これを実現するために、このようにユーザーグループを詳細に分割することが有用です。 8/19 4.2.2. 業務ユーザー/IT ユーザーの使用ツール 業務ユーザーと IT ユーザーが行なう作業は、前項で記述したように大きく分類されています。 この項では、実際に変更を行なう際に、それぞれ ODM のどのツールを使用するのか説明します。 ODM では、運用時に使用するツールとして、大きく以下の 4 つのものが提供されています。 ① Rule Designer ② Business Console (Decision Center) ③ Enterprise Console (Decision Center) ④ WAS 管理コンソール これらをそれぞれ、誰がどのような作業時に使用すれば良いのかをまとめたものが以下の表です。 業務ユーザー IT ユーザー 使用するツール 作業内容 Business Console ルールの変更/追加/削除 ルールのテスト ユーザーの変更/追加/削除 XOM,BOM の追加 ユーティリティーの追加 テスト環境へのデプロイ 本番環境へのデプロイ テスト環境へのデプロイ 本番環境へのデプロイ ユーザー/プロジェクトのセキュリティー設定 ルール・プロジェクトの削除 ユーザーグループの変更/追加/削除 テストやデプロイに使用するサーバーの設定 ユーザーの変更/追加/削除 Rule Designer Business Console Enterprise Console WAS 管理コンソール 各作業の具体的な実施方法は、以下をご参照ください。 Operational Decision Manager V8.8.0 開発ガイド ～前編～ http://public.dhe.ibm.com/software/dw/jp/websphere/decman/odm88_developerguide/odm_ v880_part1.pdf IBM Operational Decision Manager v8.6 ルール・ガバナンス・ガイド https://www.ibm.com/developerworks/jp/websphere/library/decman/odm_rulegov/ ODM V8.5.1 アプリケーション・デザイン・ガイド https://www.ibm.com/developerworks/jp/websphere/library/decman/odm80_designguide/# download IBM Knowledge Center IBM Operational Decision Manager 8.8.1 http://www.ibm.com/support/knowledgecenter/ja/SSQP76_8.8.1/welcome/kc_welcome_odm V.html 9/19 4.2.3. Business Console の GUI を利用したユーザーの登録 ガバナンス・フレームワークを使用して ODM アプリケーションのユーザー・セキュリティーを 実施するためにはまず、Business Console にユーザーを登録する必要があります。登録する方 法としては大きく以下の二つがあります。 ① Ant タスクを実行する ② Business Console の GUI を利用する この項では、Business Console からユーザーの追加を行なう手順を説明します。 Ant タスク実行での登録方法は、IBM Operational Decision Manager v8.6 ルール・ガバナン ス・ガイドの「4.4. Business Console へのユーザー登録」を参照してください。 Business Console の GUI では、以下の二種類の登録方法を提供しています。 今回は、②の作成手順を説明します。 ① Decision Center リポジトリー内にユーザーを作成する ② LDAP ディレクトリーへ接続し、ユーザーをインポートする Business Console へのユーザー登録の前提 ユーザーがガバナンス・フレームワークを使用するためには、Business Console へのユ ーザー登録の前に、WAS でのユーザー/グループ登録ならびにロールとのマッピング作 業が完了している必要があります。 これらの設定が完了しているかの確認は、登録した ID とパスワードで Business Console にログイン可能かを確認することによって行なうことができます。(この段階 では、ユーザーへの作業割り当てがされていないため、ログイン後画面には、「作業可 能なプロジェクトがありません。」というメッセージが表示されます。) 今回は例として、IBM Operational Decision Manager v8.6 ルール・ガバナンス・ガイドの「4.4. Business Console へのユーザー登録」と同じ、以下の三人を登録することとします。 ユーザー名 グループ名 役割 作業内容 Paul Administrators rtsAdministrator リリースの所有者・承認者 rtsInstaller Bea Editors rtsUser ルール編集者 Abu Testers rtsUser テスト実施者 10/19 Business Console へのユーザー登録は以下のような手順で行なうことができます。 グループとユーザーは、どちらを先に作成しても構いませんが、今回は先にグループを作成し、 その後ユーザーの作成と割り当てを行なっていきます。 1. Business Console に管理者としてログインします。 2. 「管理」タブから「ユーザー」を選択し、画面上の「＋」ボタンをクリックします。 3. 開いたウィンドウ内で Administrators グループを以下のように設定し、設定が完了したら 「作成」をクリックします。 設定する「役割」と「アクセス権」については Knowledge Center を参照してください。 ・IBM Knowledge Center ユーザーのグループの有効化 http://www.ibm.com/support/knowledgecenter/ja/SSQP76_8.8.1/com.ibm.odm.dcenter. admin/topics/con_admin_users_bc_groups.html 11/19 4. 同様に、Editors グループと Testers グループを作成します。 5. 続いて、ユーザーを作成します。「ユーザー」を選択し、 「＋」ボタンをクリックします。 6. 開いたウィンドウで、ユーザーPaul を以下のように設定し、新規ユーザーの作成とグルー プへの割り当てを行ないます。設定が完了したら、 「作成」をクリックします。 12/19 7. 同様に、ユーザーBea と Abu を作成します。 8. 最後に、メンバーが割り当てやアクセス権の設定などが正しく反映されていることを確認 できれば、グループとユーザーの設定は完了です。 13/19 4.3. プロジェクト・セキュリティー 4.3.1. プロジェクトの分割 前項では、ユーザー・セキュリティーについて記述しましたが、プロジェクトグループによるア クセス制御(＝プロジェクト・セキュリティー)も同等に重要です。この項では、プロジェクト分 割方法を、ケースとして特に多い以下の二つの具体例を用いて紹介していきます。 ① 地域 一つ目は、4.1 節であげた例のように、エリアや国、大陸などの地域でプロジェクトを分け る方法です。一つのアプリケーションを広い地域で利用する場合に、地域ごとにプロジェ クトを分けることで、参照や編集の権限を区切ることができます。これにより、不要なユ ーザーからのアクセスを防ぐことができる他、変更時などのリリースタイミングを決定し やすいというメリットもあります。 ② 組織 別の方法としては、組織によってプロジェクトを分ける方法があります。例えば、企業の 給与管理アプリケーションにおいて、人事部と経理部で使用するプロジェクトを分けると いうのがあります。人事部の使用するプロジェクトでは、従業員の個人情報を管理し、経 理部の使用するプロジェクトでは、個人の給与や従業員全体の給与支払額を算出して企業 内収支計算を行なう、というように、利用方法でプロジェクトを分割することができます。 これらは利用目的が異なっており、アプリケーションを使用するユーザーや編集タイミン グもそれぞれ異なるため、分割することが可能です。プロジェクト・セキュリティーを有 効にすると、以下の図のように、ルール編集者グループの編集するプロジェクトを、人事 部と経理部で互いの干渉がないように分割することが可能になります。これは、デグレー ドを防ぐことなどにも繋がります。この場合、併せてユーザー・セキュリティーとして統 括マネージャーグループを作成することで、編集後の承認者として編集権限を持たず、参 照と承認のみが許可されたユーザーを登録することも可能となります。 人事部 経理部 業務ユーザー グループ 統括マネージャーグループ 人事部の 経理部の ルール編集者グループ ルール編集者グループ ユーザー IT グループ 統括 IT ユーザーグループ 凡例： 大ユーザーグループ 小ユーザーグループ 図 3 ２つの業務部門によるアクセス制御の例 14/19 プロジェクトグループ 4.3.2. ODM におけるプロジェクト・セキュリティーの設定 ODM では以前から、Decision Center を使ったユーザー単位でのアクセス制限機能を提供して いましたが、バージョン 8.8.1 から新たに、プロジェクト毎のセキュリティー設定も行えるよう になりました。ここからは、Business Console を使用した具体的な設定手順を説明いたします。 9. Business Console に管理者としてログインします。 10. プロジェクト・セキュリティーを設定するにはまず、ブランチ・セキュリティー設定を行 う必要があります。「管理」タブの「プロジェクト・セキュリティー」をクリックします。 11. 権限を設定したいブランチ名の右にある編集ボタンをクリックします。 15/19 12. 開いたウィンドウ内の「セキュリティー」の下の状況をクリックして、セキュリティーの 状態を「セキュリティーを実施する」に変更します。 13. Business Console で事前に設定しておいたユーザーグループの中から、アクセスを許可し たいグループのチェックボックスにチェックをいれ、 「終了」をクリックします。 このとき、管理者にはブランチに関するすべてのパーミッションがあるため、管理者特権 があるグループはリストで使用不可です。 16/19 6. ここまでで、ブランチに対するアクセス制御設定ができました。 各ブランチのプロジェクトに対するセキュリティー設定を行なうには、まず、プロジェク ト名の右の編集ボタンをクリックします。 7. 最後に、アクセスを許可するユーザーグループを指定していきます。プロジェクトの編集 アイコンをクリックし、アクセスを許可するグループを選択します。 8. グループの列が指定したグループのみになっているのを確認できれば、設定は完了です。 17/19 5. おわりに 次々に変化するビジネス状況に対応するには、ビジネス・ルールも頻繁に変更していく必要があ ります。ルール・アプリケーションのガバナンスの戦略を立て、実践を容易にする機能を活用す ることで、アプリケーションの変更を迅速に確実に実施することができます。 本ガイドでは、ルール・アプリケーションのガバナンスについて変更管理とアクセス制御の観点 から解説し、ODM における実践方法を紹介しました。Decision Center のリポジトリーによる ソースコード管理、ガバナンス・フレームワーク機能によるリリース計画遂行のサポート、新し く設定しやすくなった Decision Center Business Console によるアクセス制御を生かして、ぜ ひルール・アプリケーションのガバナンスを実践してみてください。 18/19 6. 参考資料 ・IBM Knowledge Center | IBM Operational Decision Manager 8.8.1 http://www.ibm.com/support/knowledgecenter/ja/SSQP76_8.8.1/welcome/kc_welcome_odmV. html ・IBM Operational Decision Manager v8.6 ルール・ガバナンス・ガイド http://www.ibm.com/developerworks/jp/websphere/library/decman/odm_rulegov/ 19/19
© Copyright 2024 ExpyDoc
