メインフレームモダナイゼーション

コードを書き換えずにメインフレームアプリを移行する“リホスト”のススメ

メインフレームの維持やオープンシステムへの移行に悩む企業は多い。だが、最も手間とコストがかかるアプリケーションコードの書き換えが必要ないとしたら？　この「リホスト」と呼ばれる手法を紹介する。

　本稿は、スイスに本拠地を置くITサービスプロバイダー、LzLabsの製品管理担当バイスプレジデント、ディディエ・デュラン氏が、同氏の専門分野について本誌Computer Weekly内ブログ「Developer Network」に寄稿したものだ。同社が提唱する「ソフトウェア定義メインフレーム」製品は、Linuxとクラウドインフラの両方で、メインフレームのトランザクションを1秒当たり数千件処理するという。ソフトウェア定義メインフレームは、主要なオンライン、バッチ、データベース環境を忠実に再作成する。

デュランド氏の論旨

　モダナイゼーションはつまるところ連続体だ。マシンは維持しなければならないし、事業は本質的にマシンの利用を前提として成り立っている。連続的なモダナイゼーションの実現が、事業の将来を保証するための鍵となる。基幹事業のプロセスをレガシーなシステムに任せているだけの人々は、将来登場する新しいプラットフォームやテクノロジーを利用できないというリスクを冒している。

メインフレームの歴史

　メインフレームは、大企業が保有するリソースを拡大し、機能を強化し、顧客のニーズに応えるための強力なコンピューティングプラットフォームとして実用化された。過去半世紀、メインフレームは実業界の屋台骨として確固たる存在だった。今なお、全世界の金融取引の70％超は、メインフレームで稼働するアプリケーションによって処理されている。

　そもそも、技術が大幅に進化し、競争の激しい昨今にあって、メインフレームは今なお実業界で存続させるべきプラットフォームなのかどうか。これについては、昔から熱い議論が交わされてきた。そこで本稿は、このように長い間多くの人を悩ませてきた謎を取り上げる。すなわち、メインフレームをそのまま「リホスト」するアプローチによる移行やモダナイゼーションなんて、話がうま過ぎてマユツバ物だと懐疑的になっている人々のために、私はこの記事を書いた。いずれにせよ、メインフレームアプリケーションをモダンなプラットフォームやプログラミング言語に移行させることを望む人々にとって、メインフレームは大きな苦痛（アプリケーションの完全な書き換え、移行後の結果の不一致など）と苦悩の原因となっている。

　人々が長年使用してきたアプリケーションのモダナイゼーションを望む理由はさまざまだが、そのモダナイゼーションを実現させるための方法もまた、数多く存在する。「リホスト」のアプローチは、システム移行という観点でいえば古典的な手法であり、実行方法も1つではない。

　そうした実行方法の中で、恐らく最も高速で信頼性の高いものは、アプリケーションのコードを変更しなくても移行できるという（かつては理にかなっていた）アイデアを中心に据える方法だ。新しいプラットフォームへアプリケーションを移行させる際のリスクは発生しないので、可能な限り速く実行できる。コードの変更（が必要になる場合）は、システム障害が原因となっていることが多い。以前のシステムと比較すると、（リリース前に）テストが実行されるシナリオの数が多くないからだ。

どうすれば成功するのか

　ここでいう「リホスト」は本質的に、以下の3段階に要約できる。

続きを読むには、［続きを読む］ボタンを押して
会員登録あるいはログインしてください。

Computer Weekly日本語版

この連載の記事をもっと見る

この記事の著者

関連記事

• 

  x86やクラウドよりもLinuxメインフレームを選ぶべき理由

• 

  モバイルアプリに注力するスターバックス、POS端末はDOSベースだった

• 

  モバイル向けメインフレーム!?　でまだまだ生きるメインフレーム

• 

  デジタルワークプレースに対応したPCの展開

新着ホワイトペーパー PR

• 製品資料
  SNS認証や多要素認証も数分で実装、IDaaS基盤でデジタルビジネスはどう変わる？
• 製品レビュー
  「電子帳簿保存法対応」実践術：タイムスタンプ付与などの要件の手軽な実現方法
• 事例
  「大企業のデジタル化」成功事例集【コクヨ、九州電力、ヨネックスなど21社】
• 製品資料
  “顧客管理の課題”を簡単に解決する方法とは？
• 製品資料
  契約管理の“あるある課題”をノーコード開発で解決するためのポイント