会社でレガシーアプリケーションが実行されているメインフレームに基づいて構築されたインフラストラクチャをアップグレードする必要があり、会社の経営者がそのような近代化の必要性を疑う場合、次の議論は上司を説得するのに役立ちます。
多くの大企業は、数十年にわたってメインフレームを使用してレガシーシステム上のアプリケーションを提供してきました。 現在、ほとんどのエンタープライズレベルのシステムは依然としてメインフレームで実行されており、COBOL（メインメインフレームプログラミング言語）で記述されたアプリケーションが引き続き企業トランザクションの大部分を処理しています。 一部の垂直市場では、メインアプリケーションの50〜60％がまだメインフレームで実行されています。
ただし、これらの大型コンピューターは、企業が競争に耐えたり、脅威や新しい市場機会に迅速に対応したりできるように、何らかの方法で近代化する必要があります。
別の企業への移行は高コストまたは複雑な統合の問題に関連しているという事実のためにこのプラットフォームを保持している企業もあれば、合併や買収の結果、または投資の延期の結果として得られた古いシステムやアプリケーションをまだ使用している企業もありますIT
ITスペシャリストにとっては、古いインフラストラクチャを交換する必要があることは明らかですが、管理者は新しいプラットフォームを実装するためのさまざまなオプションに関する完全なレポートを提供せず、考えられるリスクを誤って評価するため、そのような移行の準備ができていません。
経営陣は、メインフレームITインフラストラクチャをアップグレードするかどうか、およびそのようなアップグレードを実行する方法について独自のアイデアを持っている可能性があります。そのため、あなたの観点を正当化するために、上司の異議を回避する準備をする必要があります。
「すべてが機能するため、何も変更する必要はありません」
通常、非動作状態は、レガシーシステムのアップグレード時を含む、あらゆる状況で最も簡単な方法です。 あなたのボスは、「何も壊れていないのに何かを修理するのはなぜか」と言うかもしれません。そして、システムが今新しい機能を必要としないなら、彼は正しいでしょう。
ただし、そのような異論に応えて、企業がレガシーシステムの近代化を遅らせるほど、特に競合他社がすでにアップグレードし、すでに最新のテクノロジーを使用している場合、徐々に陳腐化するため、リスクが大きくなることを強調することが重要です。
さらに、メインフレームには、企業が実装を計画しているビッグデータを使用した新しいビジネスインテリジェンスツールではアクセスが難しいビジネスに不可欠なデータが格納されます。 その結果、これらの新しいツールは不正確または誤解を招く結果をもたらします。つまり、買収への投資はビジネスに利益をもたらしません。
もう1つのリスクは、多くのユーザーにとってモバイルデバイスからのアクセスサポートを提供する必要があることです。また、古いシステムでは、原則として、新しいユーザーインターフェイスや表示される情報のより柔軟なフォーマットを導入することは困難です。
最後に、例として、すでにクラウドアーキテクチャの使用に切り替えている他の市場プレーヤーのリーダーを思い出させることができます。 比較的安価なx86サーバーテクノロジーと仮想化により、企業のデータセンターのアーキテクチャと価格構造が根本的に変わりました。 メインフレームに配置しながら、アプリケーションとそのデータを分離する価値はありますか？ はるかに安価な標準アーキテクチャサーバーを使用できる場合、クローズドアーキテクチャの古い機器に多額の費用を支払うのはなぜですか？ SQLベースの代替手段があるのに、なぜカスタムファイル指向のデータウェアハウスをサポートするのですか？
現状を維持することは行き止まりであると経営者に確信させるには、次の重要な点に注意を向けるようにしてください。
- 同社は、時代遅れのメインフレームの作業を維持するために多くのお金を費やしています。
- 現在メインフレームで動作するアプリケーションの多くは、前世紀に書かれたものであり、それらを開発した企業は長い間市場を去っています
- 調達、設置、冷却、電力、サポートのコストを含む、会社で使用されるメインフレームの総所有コスト（TCO）
- 既存のインフラストラクチャは、モバイルデバイスなどの新しい動的プラットフォームの操作をサポートできません
- 新しい最新のビジネスインテリジェンスアプリケーションではメインフレームデータを利用できない
- メインフレームを使用するには膨大な量のドキュメントが必要です
- メインフレームテクノロジーを熟知し、障害発生時に現在のインフラストラクチャを提供できるIT部門のスペシャリストはまもなくなくなります。
「メインフレームにパワーを追加したらどうなるでしょうか？」
レガシーシステムに十分な電力がない場合は、その機器の構成を拡張するか、より強力な新しいメインフレームに交換できます。 このようなアプローチは、システムのパフォーマンスと容量を増加させますが、同時にメンテナンスとライセンスのコストの増加につながります。
その結果、会社はメインフレームの主な問題、すなわち柔軟性の欠如、メンテナンスコストの増加、メインフレームサービスの専門家の不足などを排除できなくなります。
レガシーシステムのパワーを単純に増加させると、ライフサイクルが延長され、その結果、企業はコストを削減し、イノベーションを迅速に導入する新しいテクノロジーを活用できなくなります。
さらに、メインフレームアプリケーションは、最新のプライベートクラウドアーキテクチャの外部要素のままです。
これらのキーポイントに加えて、アイデアを示す番号に名前を付ける準備ができている必要があります。
- メインフレームの構成を展開した後にメインフレームにインストールする必要があるパッチ、修正、および更新の数について
- これらのパッチがシステムの動作に与える影響（システムの複雑さ、透明性の欠如）
- レガシーシステムのパッチおよび継続的なメンテナンスによる追加費用について
「ソースを書き換えることはできませんか？」
もちろん、それは可能であり、これは近代化の最も積極的なオプションになります。 アプリケーションのソースコードを書き換え、データベースアーキテクチャとアプリケーション層を再構築するだけです。
ただし、実際には、ソースコードの完全な書き換えには大きなリスクが伴います。 この近代化オプションにより、ビジネスプロセスのロジックが完全に処理され、エラーが発生する可能性が高くなるため、徹底的なテストが必要です。
さらに、データストアをSQL環境に転送する変換テーブルを作成し、このデータのストレージレベルからデータを操作する機能を分離する必要があります。
以下の点について議論する準備をしてください。
- メインフレームの主なコストは何だと思いますか-ソースコードが記述されているプログラミング言語、またはシステムのアーキテクチャです。 最大かつ最速の投資回収率を提供するものは何ですか？
- ビジネスプロセスロジックを変更するリスク
- ソースの書き換えを反映できる他のアプリケーションとデータストレージ
- 機能テスト、ユーザーテスト、同時操作など、プロジェクトにかかる時間
- 完全な書き換えプロジェクトに必要なリソース（スタッフを含む）
これら3つのディスカッションシナリオは、メインフレームのアップグレードの可能性に関する表面的なアイデアを回避するのに役立ちます。 しかし、見返りに何を提供しますか？
会社のITアーキテクチャをアップグレードする準備ができているが、リスク、時間、およびお金を慎重に制御したいITプロフェッショナルには、ソースコードの完全な書き換えよりも魅力的な別のオプション、すなわち、アプリケーションの新しいプラットフォームへの移行（リホスティング）があります。
移行の利点
移行する場合、古いメインフレームアプリケーションは、コードを変更せずに、たとえばSQLに基づいたマルチレベルx86環境やクラウドなどの最新のオープン環境に転送されます。 さらに、アプリケーション自体はCOBOL、PL / Iまたはその他の言語で記述でき、メインフレームはIBM、富士通またはその他のベンダーのものです。
多くの企業にとって、移行はメインフレームアーキテクチャをアップグレードするための非常に費用対効果の高いオプションです。 移行が正しく実行されると、ソースをコピーする場合よりもリスクとコストがはるかに少なくなります。
また、その後のソースコードの書き換えを簡素化し、それに伴うリスクを軽減します。 メインフレームは顧客を限定的で厳格なアーキテクチャにバインドしますが、疎結合のオープンシステムアーキテクチャは動的なスケーリング、負荷管理、および柔軟性を提供します。
セキュリティも向上します。古いメインフレーム保護メカニズムはすべて機能し続け、最新のSQLデータベースのセキュリティ機能を簡単かつ迅速に追加できます。
新しいプラットフォームへのスムーズな移行
適切に実行された移行は、標準OS、x86サーバー、SQLデータベース、クラウドインフラストラクチャを使用することでリスクを軽減します。 コストを削減しながら、統合とセキュリティを改善します。
しかし、経営陣に移行の利点を伝えるだけでは十分ではありません。他のオプションが会社に適さない理由を説明できる必要があります。 競争力、予算、ビジネスリスクなど、会社のリーダーが理解できる用語でこれを説明してください。 成功すれば、メインフレームから新しいプラットフォームにアプリケーションを移行する計画の承認を得られる可能性が高くなります。