企業の合併・買収などに伴う Lotus Notes/Domino IBM Software Group 2005
by user
Comments
Transcript
企業の合併・買収などに伴う Lotus Notes/Domino IBM Software Group 2005
® IBM Software Group 企業の合併・買収などに伴う Lotus Notes/Domino システム統合の基本的な考え方 2005年7月作成、2006年3月改訂 日本アイ・ビー・エム株式会社 ソフトウェア事業 Lotusテクニカル・セールス © 2006 IBM Corporation IBM Software Group | Lotus software 特記事項 本資料の記載内容は、正式な IBM のテストやレビューを受けておりません。内容について、 できる限り正確を期すよう努めてはおりますが、いかなる明示または暗黙の保証も責任も 負いかねます。本資料の情報は、使用先の責任において使用されるべきものであることを、 あらかじめご了承ください。 掲載情報は不定期に変更されることもあります。他のメディア等に無断で転載する事はご 遠慮ください。 本資料の著作権は日本アイ・ビー・エムにあります。非営利目的の個人利用の場合におい て、自由に使用してもかまいませんが、営利目的の使用は禁止させていただきます。 IBM は IBM Corporation の商標。 Lotus は IBM-Lotus の商標。 その他、記載された社名および製品名は、それぞれ各社の商標または登録商標です。 参考文献 本資料の記載内容は、基本的に以下の文献に基づいて作成されています。 本資料の公開を快く承諾してくれた著者に感謝いたします。 日本アイ・ビー・エム システムズ・エンジニアリング株式会社 香川 浩子著 IBM Professional 論文 2002年度 準入選論文 「企業合併によるノーツドミノ統合の在り方」 * 当論文は非公開資料です。 2 IBM Software Group | Lotus software Agenda 1. はじめに ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 04 2. ドメインと組織 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 06 3. Lotus Notes/Domino システムの基本的な統合パターン ・・・・・・ 10 4. Lotus Notes/Domino システムの統合における作業内容と システムに及ぼす影響 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 17 1. ドメイン名の変更作業 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 18 2. 組織名の変更作業 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 19 3. メールへの影響 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 21 4. Lotus Notesアプリケーションへの影響 ・・・・・・・・・・・・・・・・・・・・・・・・ 24 5. その他の考慮点、影響範囲 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 28 5. システムの統合パターンの決定要因 ・・・・・・・・・・・・・・・・・・・・・・・・ 29 6. 統合パターンごとの特徴 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 33 3 ® IBM Software Group 1. はじめに © 2006 IBM Corporation IBM Software Group | Lotus software 1. はじめに 企業や地方自治体などにおける合併や吸収・買収に伴い、既存の複数 の Lotus Notes/Domino システムを統合するケースが増えています A社システム C社システム 合併・買収 B社システム 新統合システム z Notes/Domino システムの統合を考える上で、重要な２つの概念 ¾ ドメイン ¾ 組織 z ドメインと組織の組合せによって、いくつかの統合パターンが存在 z ドメインと組織は、Notes/Domino システムにおける 情報共有 （含． メール配信）および セキュリティ の範囲や強さに影響する要因です 5 ® IBM Software Group 2. ドメインと組織 © 2006 IBM Corporation IBM Software Group | Lotus software 2. ドメインと組織 2-1. まずは、エンドユーザーから見てドメインと組織とは？ Notesメールの宛先アドレスの例 Taro Yamada/Acme@Acme ドメイン ＝ @ の後の Acme 組織 ＝ / の後の Acme 通常、組織名には会社名を設定 （組織とドメインは別物ではあるが、） セットアップ時、ドメイン名は組織名と同じに設定することが多い ∴ 一般的に、 組織名とドメイン名 ＝ 会社名 となるケースが多い つまり、企業の合併・買収など Î 会社名が変わる Î Lotus Notes/Domino のシステム統合にあたり、ドメイン名や組 織名をどうするかという検討が必要となります 7 IBM Software Group | Lotus software 2. ドメインと組織 2-2. Lotus Domino ドメインとは？ Domino ドメイン ＝ 同じ Domino ディレクトリーを共有する Domino サーバーのグループ １つのドメイン内では、同じDominoディレクトリー（公開アドレス帳）を使用する １つのドメイン内のサーバーは、同じDominoディレクトリーを格納し、複製する サーバーやユーザー，グループなどを管理する単位 メールの配信、サーバー接続などシステムの運用・制御に関する様々な定義 情報もドメイン単位で管理・格納される 名前の認証管理に用いられる 組織 （後述）とは異なる ※自分が属するドメインとは異なるドメインへ Notesメールを送信するには、あらかじめ サーバー側やクライアント側で所定の設定などをしておかないと、エラーになってしまう Lotus Domino ドメインとは、 システムの運用・管理の単位 メール配信の仕組みと密接に関係 8 IBM Software Group | Lotus software 2. ドメインと組織 2-3. 組織とは？ 組織 ＝ サーバーやユーザーの証明・認証に使用されるもの 同じ組織に属するサーバーやユーザーは、同じ認証局（認証者）から発行された 認証（電子的なスタンプ）を持っている 組織は、ツリー状に階層構造にすることもできる ツリーの一番上を 『組織』 と呼び、通常は会社名にする 下位の組織は 『組織単位』 と呼び、一般に、地理的な配置や部門構成などで定義する 組織の階層構造を含むユーザー名を 『階層名』 という （例：Taro Yamada/Sales/East/Acme） 階層名はNotesメールの配送宛先として利用される 組織や階層名は、セキュリティの定義・確認などに利用される ログイン時のユーザー認証、 ACL（アクセス制御リスト）、メールや文書の暗号化・電子署名など 組織名は、 Domino ディレクトリーの各種文書（ユーザー文書, サーバー文書, 接続文書な ど）、ACL、読者名フィールド、ノーツの ID ファイル、エージェントの実行サーバー名等々、 非常に広範囲・多岐に渡り使用・格納される 組織とは、 セキュリティの基盤となるもの 9 ® IBM Software Group 3. Lotus Notes/Domino システムの 基本的な統合パターン © 2006 IBM Corporation IBM Software Group | Lotus software 3. Lotus Notes/Domino システムの基本的な統合パターン 全く新規に Lotus Notes/Domino システムを構築するのであれば、 ¾ ドメイン名と組織名を会社名にし、 ¾ １つのドメイン、かつ、１つの組織 という構成にしている企業が一般に多い なぜならば、 １ドメイン１組織 という構成は、 − 全社的に管理された強固なセキュリティのもと、 − メールのスムーズな送受信や全社的な情報共有を実現し、 − 全社的なシステムの一括管理も行なえる から。 では、既に構築され運用されている複数の Lotus Notes/Domino システムを統合する場合は、どのように考えればよいのでしょうか？ 11 IBM Software Group | Lotus software 3. Lotus Notes/Domino システムの基本的な統合パターン 既存の Lotus Notes/Domino システムの統合については、 ドメインと組織の組合せにより、４つの基本パターンが考えられます 統合パターン① ： 完全統合 ドメイン ドメイン ABC XYZ 組織 組織 ABC XYZ ドメイン ALPHA 組織 ALPHA 注： ２つの企業、ABC社 と XYZ社 が合併し、 新会社 ALPHA社 になるものとする ドメイン名と組織名の両方を、 新会社用に統一するケース Domino ディレクトリーは１つに統合さ れる 全ユーザーのノーツアドレスが xxx/ALPHA@ALPHA となる 12 IBM Software Group | Lotus software 3. Lotus Notes/Domino システムの基本的な統合パターン 統合パターン② ： ドメインのみ統合 ドメイン ドメイン ABC XYZ 組織 組織 ABC XYZ ドメイン名だけを新会社 用に統一し、組織名は 旧会社のまま維持する ケース Domino ディレクトリーは１つ に統合される ドメイン ALPHA 組織 組織 ABC XYZ 旧ABC社ユーザーの階層名 は xxx/ABC のまま、旧XYZ 社ユーザーの階層名は △△△/XYZ のまま 13 IBM Software Group | Lotus software 3. Lotus Notes/Domino システムの基本的な統合パターン 統合パターン③ ： 組織のみ統合 ドメイン ドメイン ABC XYZ 組織 組織 ABC XYZ 組織名だけを新会社 用に統一し、ドメイン名 は旧会社のまま維持 するケース 全てのユーザー、サーバー が同じ組織（xxx/ALPHA）と なる 組織 ALPHA ドメイン ドメイン ABC XYZ ドメインは各ユーザーによっ て異なり、メール送受信時 のノーツアドレスには、旧 ABC社ユーザーの場合 @ABC、旧XYZ社ユーザー の場合 @XYZ と表示される 14 IBM Software Group | Lotus software 3. Lotus Notes/Domino システムの基本的な統合パターン 統合パターン④ ： ドメイン・組織未変更統合 ドメイン ドメイン ABC XYZ 組織 組織 ABC XYZ ドメイン名も組織名も旧会社のまま、 メールのインターネット・ドメインの み新会社用に変更するケース Domino ディレクトリー、ユーザーの属す る組織、Notesアドレスなどは旧会社のま ま変更なし Lotus Notes/Domino だけ使用している 分には、新会社名 ALPHA はどこにも表 示されない @alpha.co.jp ドメイン ドメイン ABC XYZ 組織 組織 ABC XYZ インターネット・ドメイン名を新会社用に 変更することで、外部とのメール送受信 で使用するインターネット・アドレスが新 会社のアドレス（[email protected]）に変わ るので、対外的には統合されたように見 える （注 ： 統合パターン①∼③においても、イン ターネットドメイン名は同様に変更します） 15 IBM Software Group | Lotus software 3. Lotus Notes/Domino システムの基本的な統合パターン （まとめ） 統合パターン ① 完全統合 インターネット・ド メイン名の変更 Domino ドメイン 名の変更 組織名の変更 ○ ○ ○ ② ドメインのみ 統合 ○ ○ × ③ 組織のみ 統合 ○ × ○ ④ ドメイン・組織 未変更統合 ○ × × ○ ・・・ 変更する、 × ・・・ 変更しない 16 ® IBM Software Group 4. Lotus Notes/Domino システムの統合における 作業内容とシステムに及ぼす影響 © 2006 IBM Corporation IBM Software Group | Lotus software 4-1. ドメイン名の変更作業 ドメイン名の変更は、単純に、文書中の文字列の変更で可能 ドメインが定義されている場所 Domino ディレクトリー内のサーバー文書、ユーザー文書、接続文書など クライアント上の個人アドレス帳内のロケーション文書など ドメイン名変更手順の概要 1. 作業用の Domino ディレクトリーを用意する 2. 統合元の Domino ディレクトリーにあるすべての文書をコピーし、作業用の Domino ディレクト リーにペーストする 3. エージェントなどで、すべての文書のドメイン名を新しいドメイン名に変更する 4. Domino サーバーに、新ドメインの Domino ディレクトリーを配置する 5. 各ユーザーの個人アドレス帳の内容を新ドメイン名に変更する （考えられる方法としては、各ユーザーが手作業で実施、自動で変更する処理を埋め込んだボタン付きの メールを管理者が送付、ひな形となる個人アドレス帳をファイルサーバーなどから自動配布、など） 【参考情報】：「Merging Domino domains into one」（ドメイン名変更手順の詳細） http://www-128.ibm.com/developerworks/lotus/library/ls-Merging_Domino_domains/ 18 IBM Software Group | Lotus software 4-2. 組織名の変更作業 組織 ＝ 認証 であり、電子的なスタンプを伴っています よって組織名の変更は、単なる文字列の更新だけで済むものではありません 組織名変更手順の概要 新しい名前の組織を作成する（＝新しい名前の認証者 ID の新規作成） 旧組織に属するサーバー／ユーザーなどを新組織で再認証（＝階層名および認証 情報の更新） クライアントが Lotus Notes ユーザーの場合は、Notes ID ファイルに新組織の情報 を反映させる（＝Notes IDファイル内の、ユーザーの階層名および認証情報の更新） 旧組織名が設定されている個所を全て変更 Domino ディレクトリー内の各種文書（ユーザー文書、グループ文書、サーバー文書、サー バー設定文書、接続文書、メール受信データベース文書など） 各データベースのACLの設定や、エージェントの実行サーバー名など 各文書の読者／作成者フィールドなど その他（空き時間情報データベースのユーザー名、システム管理サーバー名、設計のコー ディングの内容、個人アドレス帳のユーザー／グループ／接続／ロケーション文書など） （続く） 19 IBM Software Group | Lotus software 4-2. 組織名の変更作業 （続き） 前ページで述べたように、 組織名の変更には認証の変更というシステム的な変更が伴い、 また組織名が設定されている個所は非常に多岐にわたるため、 ドメイン名の変更に比べてより大掛かりな作業になる場合が多いです 組織を統合する手順について、一般に公開されている汎用的な情報は存在しませ ん ユーザーについては、システム管理プロセスによって自動的に処理可能 【参考情報】：「Lotus Domino Administrator 6.x ヘルプ」より「名前階層でユーザー名を移動する」 Lotus Domino R5 以降のサーバーであれば、ドメイン間でのシステム管理要求の処理がサ ポートされているので、企業の吸収・合併に伴う組織の統合にも応用可能 しかし Lotus Domino R4 サーバーではシステム管理プロセスは同一ドメイン内でしか動作し ないので、企業の吸収・合併に伴う組織の統合の場合は手動で処理する必要がある サーバーについては、Domino のバージョンに関わらず、システム管理プロセスでの変更は サポートされていない よって、旧サーバー名が設定されている個所の変更（*）は全て手動で処理する必要がある * サーバー ID の再認証や、サーバー文書／接続文書／メール受信データベース文書、 各データベースのACL、エージェントの実行サーバー名、読者／作成者フィールドなどの変更 20 IBM Software Group | Lotus software 4-3. メールへの影響 システム統合前に受信したメールへの返信 システム統合前に受信したメールには、古いノーツアドレスが格納されている したがって、組織名の変更を伴う統合の場合は、システム統合前に受信したメー ルへの返信はできない （統合後の新しいアドレスをユーザーが明示的に設定し なおす必要がある） 受信メールへの返信作成時には、宛先にドメイン名は含まれない（F9キー押下 などによりName Lookupが実行されるとドメイン名がセットされる）ので、ドメイン 名の変更は影響しない システム統合前に受信した暗号化メールについて 旧組織に属するユーザーIDを新組織で再認証する場合は、システム統合前に受 信した暗号化メールを統合後も読むことが可能 （参考） 「IDを再認証するとIDの公開キーが変わるのはなぜですか」 http://www.ibm.com/jp/domino04/lotus/support/faqs/faqs.nsf/all/710688 再認証ではなく全く新規にユーザーIDを発行すると（システム統合前後でユーザーIDを切り替える場 合）、システム統合前に受信した暗号化メールを新ユーザーIDで読むことはできないので注意 ドメイン名はメールの暗号化とは無関係なので、ドメイン名の変更は影響しない 21 IBM Software Group | Lotus software 4-3. メールへの影響 （続き） 代理アクセスの設定 メールやカレンダー，スケジュールに対して代理アクセスを設定している場合で、組 織名の変更を伴う統合の場合は、新しい階層名で設定をしなおす必要がある 代理アクセスの設定にドメイン名は含まれないので、ドメイン名の変更は影響しない 漢字アドレス帳，漢字メールへの影響 Lotus Notes/Domino R5 以降、DJX （ドミノディレクトリ日本語拡張機能）という標準 の漢字アドレス帳，漢字メールの仕組みが提供されたが、R4 まではサードベンダー によるパッケージ製品など複数の仕組みが存在していた 統合元の各社が異なる漢字メールの仕組みを利用していた場合は、統一するか否 かの検討が必要 統合元の各社が共に DJX を利用していた場合でも、DJX管理データベースの統合 や部署マスター／役職マスターの更新などを検討し実行する必要がある 複数ドメインの場合の、宛先選択への影響 ドメイン名を統一しない場合、他ドメインのユーザーへのメール送信（宛先選択）を容 易にするために、システム管理者はディレクトリアシスタントやディレクトリカタログの 利用を検討する必要がある 22 IBM Software Group | Lotus software 4-3. メールへの影響 （まとめ） 統合パターン ノーツアドレス の変更箇所 統合前受信メー ルへの返信 代理アクセスの 設定 ディレクトリアシ スタント等の検討 ① 完全統合 組織名、 ドメイン名 返信できない 変更が必要 不要 ② ドメインのみ 統合 ドメイン名 返信できる 変更不要 不要 ③ 組織のみ 統合 組織名 返信できない 変更が必要 必要 ④ ドメイン・組織 未変更統合 なし 返信できる 変更不要 必要 23 IBM Software Group | Lotus software 4-4. Lotus Notesアプリケーションへの影響 既存のノーツアプリケーションDBへの影響について ノーツアプリケーション ＝ 掲示板DB，ディスカッションDB，ワークフロー DBなど システム統合により、影響を受ける可能性のある個所 アクセス制御リスト（ACL） 読者名フィールド、作成者名フィールド システム管理サーバー名 スケジュールエージェントの実行サーバー名 複製の設定における複製相手サーバー名 ドメイン名や組織名で処理を行なうようなボタン式やアクション、エージェントなど その他、ノーツアドレスを表示するフィールドなど 通常アプリケーションで使用されるのは、ほとんどの場合ドメイン名を除い た組織名までのNotesアドレスである。よって特殊な場合を除き、ドメイン名 の変更は、Lotus Notesアプリケーションには影響しないと考えてよい。 24 IBM Software Group | Lotus software 4-4. Lotus Notesアプリケーションへの影響 （続き） 組織名の変更を伴うシステム統合の場合（統合パターン ①、③）について ACLや読者名／作成者名フィールドに含まれる個別ユーザー名については、シス テム管理プロセスによって自動的に変更可能 サーバー名の変更については、手動で変更する必要がある ACL、読者名／作成者名フィールド、システム管理サーバー名、スケジュールエージェン トの実行サーバー名、複製相手サーバー名など その他、ボタン式やアクション，エージェントなどのコード、ノーツアドレスを表示す るフィールドなどについては、適宜手動で変更する必要がある 組織名の変更を伴う場合、一般的に、システム統合のための作業量は多い しかし統合後は、全社的に一元管理された強固なセキュリティを実現できる またACLの設定／更新やアプリケーションの新規開発といった運用も、組織が統 合されない場合に比べてシンプルである 25 IBM Software Group | Lotus software 4-4. Lotus Notesアプリケーションへの影響 （続き） 組織名を変更しないシステム統合の場合（統合パターン ②、④）について アプリケーションの要件にもよるが、一般的に、既存文書の読者名／作成者名 フィールドや、システム管理サーバー名、スケジュール・エージェントの実行サー バー名、複製相手サーバー名、Notesアドレスを表示するフィールドなどの変更が 必要ないケースが多い ACLについては適宜、統合相手の組織に属するユーザーの設定を追加するなどの 対応が必要 例 ：*/ABC で使用していたアプリケーションのACLに、*/XYZ への権限を追加 する 注） ドミノディレクトリに、*/ABC および */XYZ を含むグループ文書を追加し、ACLの設定ではそのグ ループに対し権限を設定する、といった方法でも対応可能 ボタン式やアクション，エージェントなどのコードについては、必要に応じて適宜変 更する 一般に、システム統合のための作業量は少なくて済む しかし統合後の運用を長い目で考えると、新規のユーザーやサーバーをどちらの 組織に登録するのか、すでに存在しない会社名（ABC，XYZ）をいつまで使い続け るのかなどの考慮事項が発生し、必ずしもシンプルな運用とは言えない 26 IBM Software Group | Lotus software 4-4. Lotus Notesアプリケーションへの影響 （まとめ） エージェント実行 サーバー名、複 製相手サーバー ボタン式やアク ション、エージェ ントなどのコード 移行時の 作業量 統合後の運用 統合パターン ACL 読者名／作成者 名フィールド ① 完全統合 変更あり （AdminPにより 一部自動化） 更新必要 （AdminPによ り一部自動化） 更新必要 （手動） 必要に応じ適 宜変更必要 多い シンプル ② ドメインのみ 統合 変更あり （統合相手を 追加） 通常不要 通常不要 必要に応じ適 宜変更必要 少ない 考慮事項あり 変更あり （AdminPにより 一部自動化） 更新必要 （AdminPによ り一部自動化） 更新必要 （手動） 必要に応じ適 宜変更必要 多い １つのドメイン内 ではシンプルだ が、複数ドメイン 間の運用・連携 などの考慮必要 変更あり （統合相手を 追加） 通常不要 通常不要 必要に応じ適 宜変更必要 少ない 考慮事項あり ③ 組織のみ 統合 ④ ドメイン・組織 未変更統合 27 IBM Software Group | Lotus software 4-5. その他の考慮点、影響範囲 * システム統合に伴い、以下の検討が必要となる場合があります サーバーについて サーバーの統廃合やサーバースペックの再見積もり メールルーティングや複製のトポロジーの変更 サーバー・プラットフォームやサーバーのバージョンの統一 サーバーのネーミング・ルールの統一、など ユーザーについて Lotus Notesユーザーのネーミングルールの統一、同姓同名の扱いについての検討 Internet メール・アドレス形式の統一 パスワード・クオリティ・レベルの統一 クライアントのプラットフォームやLotus Notesバージョンの統一、など その他 システム管理者の変更 データのバックアップの運用方法の変更、など 28 ® IBM Software Group 5. システムの統合パターンの決定要因 © 2006 IBM Corporation IBM Software Group | Lotus software 5. システムの統合パターンの決定要因 * どのパターンでシステムを統合するかを決定するには、以下の観点から総合的に検討します コストとスケジュール 統合パターンにより、また、ユーザー数やアプリケーションの設計内容な どにより作業量が異なるため、移行にかかるコストや作業スケジュールも 異なる 今まで述べてきたように、組織名の変更の場合は作業量が多く、ドメイン 名の変更の場合は作業は比較的少なくて済む 作業スケジュールを計画するにあたっては、作業用環境で事前に処理で きる作業（ドメイン統合に伴う作業用ドミノディレクトリーの更新作業、組織 変更に伴うアプリケーションの設計変更など）と、本番環境で実施する必 要のある作業（インターネット・ドメイン設定の切り替え、組織変更に伴う ユーザーIDの再認証など）とを考慮する 一度に全作業を完了するだけでなく、平行期間を設ける、段階的に統合 を実施する（最初はパターン④で統合し後にパターン①に移行、など）、と いった選択肢を取るケースもある （続く） 30 IBM Software Group | Lotus software 5. システムの統合パターンの決定要因 （続き） 統合後の運用について ドメインや組織を変更せずに複数存在させたまま残す統合（パターン②，③，④） では、統合後、新規のユーザーやサーバーをどのドメイン／組織に登録するか、 既存ユーザーのドメイン／組織をまたがる異動時の対応など、運用ルールが複 雑になる可能性が高い パターン①以外は、合併・買収によって消滅した旧会社名が、いつまでもシステム 上に残ることになる システム統合後もシステムの管理・運用やセキュリティ管理を分けたい場合（ABC 社がXYZ社を関連子会社として吸収する、など）は、意図的にドメインや組織を分 けておく場合もある 逆に、システム統合後はシステムやセキュリティを全社的に一元管理・運用した い、元の所属会社に関わらずどのユーザーも同じようにメール交換したり情報や アプリケーションにアクセスできるようにしたい、といった場合は、完全統合（パ ターン①）が最も適している Î システム的／技術的な観点だけではなく、経営的観点や企業文化／ 情報共有の方針などからも「あるべき姿」を検討することが望ましい （続く） 31 IBM Software Group | Lotus software 5. システムの統合パターンの決定要因 （続き） その他の要因 当資料で述べた統合パターンはあくまで基本パターンであり、これ以外に変則的な統合 形態を取るようなケースもある 例 – 全社での一元管理・運用と、旧会社単位での個別管理・運用とを共に実現するために、組織を 新会社で統合し、新たに別々の組織単位を作成する（*/ABC/ALPHA と */XYZ/ALPHA に移 行する） – 社外向けの Lotus Domino Webシステムは新会社に移行するが、メールや社内のアプリケー ションについてはパターン④での統合とする 多国籍企業の場合で、複数言語環境で Language Pack では対応しきれない場合や、国 ごとにユーザー登録などのシステム管理を行ないたい場合などは、意図的にドメインを 分けておく場合もある 例 （この場合も変則的な統合を取るケースもある） – */ABC@ABC と */XYZ@XYZ とを */Japan/Alpha@JP と */US/Alpha@US に移行する、など この他にも、統合元システムの現状／運用ルールやアプリケーションの要件／設 計内容、統合までのスケジュール／予算、どういった要因に重きを置くか、統合後 のシステムで目指すもの、など様々な要素により、取るべき統合パターンや検討 項目、作業内容などが変わってくる 必要に応じて、経験豊富なコンサルタント会社にコンサルティングを依頼するのも一考 32 ® IBM Software Group 6. 統合パターンごとの特徴 © 2006 IBM Corporation IBM Software Group | Lotus software 6. 統合パターンごとの特徴 * 基本の統合パターンについて、具体的にどのような場合に適しているかを例示します 統合パターン ① 完全統合 ② ③ ④ ドメインのみ 統合 統合企業の環境、状況、要望 • システム上に表示される企業名はすべて新会社名に統一したい • 統合後は、ユーザーやアプリケーションが統合前どの会社に属していたかに関係な く、全社で一元的にシステムやセキュリティを管理・運用したり、情報の共有をはか りたい • スケジュールや予算の面では問題がない • Dominoディレクトリーは１つに統合して、システムやユーザー／グループなどを一括 管理したい • データベース数や文書数が非常に多く、データの更新作業を行ないたくない • コストを抑えたい • Lotus Notesでは主にメールを利用している 組織のみ 統合 • Dominoディレクトリーの管理は、旧会社ごとにそれぞれ別に行ないたい • データベース数や文書数が少なく、組織変更に伴う更新作業が比較的少なくて済 む • 多国籍企業／複数言語環境である ドメイン・組織 未変更統合 • • • • 統合日までの期間が短く、スケジュールに余裕がない 最小限のコストで統合を行ないたい データベース数や文書数が非常に多いため、データの更新作業を行ないたくない 企業外部から統合しているように見えればよい。内部の統合については気にしない 34