 |
||||||||||||||||
|
||||||||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||||||||
|
||||||||||||||||
| レガシーマイグレーションの手法について | ||||||||||||||||
|
表2にあげたレガシーマイグレーションの手法は、主にシステム面に注目した場合もので、それぞれの適用を区別すると図1のようになる。  図1：マイグレーションの形態と適用区分 個々の手法はどれがベストというものではなく、あくまでも自社のビジネスに合致したものを選択する必要がある。以降では、これらをより詳しく解説していく。 |
||||||||||||||||
| BPR（ビジネスプロセスリエンジアリング）方式 | ||||||||||||||||
|
BPR方式は、現行業務におけるビジネスプロセスを見直し、新システムに移行する際にビジネスの流れ自体も変更するものだ。業務仕様や論理システム構成、ソフトウェアの仕様を再設計し、それに基づいてアプリケーションプログラムを構築する。 この方式のメリットとしては、従来のビジネスプロセスにとらわれず、現状に即したシステムを再構築できる点だ。また全体的な見直しが行われていることから、今後の戦略を盛り込んだ設計が可能となる。 デメリットとしては、マイグレーションに必要な作業が膨大となり、移行までに相当な期間がかかることだ。また各部署での十分なヒヤリングのないまま作業を進めると、ビジネスプロセスの実行に齟齬が生じる可能性もある。 |
||||||||||||||||
| Rebuild（リビルド）方式 | ||||||||||||||||
|
Rebuild方式は、従来のビジネスプロセスを踏襲して論理システム構成やソフトウェア仕様を設計し、その上でアプリケーションプログラムを構築するものだ。構築先としてはオープンシステムをはじめとした現行の技術を採用することで、今後の機能強化についても行いやすくなる。 この方式のメリットとしてはビジネスプロセスそのものは変更されないため、移行はスムーズに行われる点だ。ただし、現状の業務フローがビジネスに合致していると確認できたうえで選択するべきだろう。そうでないと、プロセスを見直さないというメリットがデメリットとなってしまうからだ。 |
||||||||||||||||
| Rewrite（リライト）方式 | ||||||||||||||||
|
Rewrite方式では、ビジネスプロセスおよびソフトウェアの仕様はそのまま採用し、新たなシステム上でアプリケーションプログラムを開発するものだ。なおこの方式では、開発に使用する言語は基となるアプリケーションとは異なる。 メリットとしては、作業そのものはアプリケーションの新規開発に限られており、ほぼ同様の環境を実現できるところにある。デメリットはRebuild方式と同様で、ビジネスプロセスが現状に適しているかをチェックしてから構築する姿勢が求められる。 |
||||||||||||||||
| Rehost（リホスト）方式 | ||||||||||||||||
|
Rehost方式は、マイグレーション方法としてRewrite方式とほぼ同様となる。違う点は、アプリケーションの開発環境として、基アプリケーションと同じ言語を採用し、最小の手間で移行を行うという部分だ。 メリット／デメリットについてはRewrite方式と同様だが、旧システムの開発言語に対応できる技術者の確保という問題が発生する場合もある。 |
||||||||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
|
|
||||||||||||||||
|
||||||||||||||||
-
-
連載
