抽象
IBM i アプリケーションをモダナイズするか、未来のプラットフォームに移行することを強く推奨していますが、移行反対の感情を駆り立てる強い躊躇もあります。 これは私たちを質問に導きます。 スキルセットに投資する必要があるか
既存のプラットフォームかどうか？
概要
IBM i はレガシー システムであるため、さまざまな理由から多くの企業が移行の対象としています。 このブログでは、今日のシナリオで利用可能な移行オプション、採用の可能性、迅速な追跡ができない理由について説明します。
移行または終了、および開発労働力を向上させる必要性。
IBM i (広く AS/400 として知られている) は、銀行、金融サービス、保険 (BFSI) を含む多くの中規模から大規模企業にとって最も戦略的なシステムの 25 つです。 これらすべての企業で 30 年から XNUMX 年以上使用されています。 コアをホストします
ここで説明するように、IBM i は、IBM i、ハードウェア、オペレーティング システム、RPG などのプログラミング言語に付随するエコシステム全体です。
COBOL と CL、データベース DB2 for i、メッセージング用の IBM MQ、ジョブ管理、ユーザー アクセス、セキュリティなど。レガシーのモダナイゼーションは銀行内で何年も前から議論されており、IBM i も新しいテクノロジーによる置き換えの対象になっています。課題
IBM i プラットフォーム固有のスキルセット (RPG、COBOL)、俊敏性の問題につながるアプリケーションのモノリス アーキテクチャ、他のプラットフォームや DevOps ツールとの相互運用性、戦略的投資との整合性がない、クラウドの利点のほとんどを逃している (例:
同時に、移行が延期されている理由はいくつかあります。 その中には、新しいハードウェアのリリース、OS のリリース、サポート期間の延長、大規模なインフラストラクチャへの現在の投資、移行のリスクとコストなどがあります。
ここでは、中小企業への依存が予測されるように、その出口の早期の可能性を測定しようとします。
私たちの視点
その間、ビジネスは拡大し、ビジネス要件も拡大し、さまざまなリスクが拡大し、コンプライアンスと規制の要件が拡大しました。
企業。 そのため、すべての知識、ビジネス ルール、ビジネス プロセスが集中する高レベルの複雑性があります。 これに、マルチスレッド、メッセージング、ジョブ スケジューリング、ジョブ制御などのすべての技術的な実装が追加されました。
モノリス実装の一部でもあります。
クラウド、DevOps、アジャイル プラクティスの出現により、銀行や保険会社を含む業界や企業は、最新の機能とメリットを享受するために、IBM i アプリケーションの変革も求めています。 企業には複数の選択肢があります
彼らの前では。 このプラットフォームは、アジャイル プラクティスに従い、ARCAD ソリューションを使用して DevOps の世界に参加できます。 英国の大手銀行の XNUMX つは、IBM i での DevOps の採用に成功しました。 最近発売された IBM i Merlin Platform (Modernization Engine for Lifecycle
統合) は、統合された IDE、DevOps エクスペリエンスのための CI/CD Merlin ツール、および IBM i 仮想マシンのプロビジョニング、REST API 管理などでこれを支援し、将来の完全な DevOps エコシステムへの希望をもたらします。 最近の開発は敏捷性に役立ちます
IBM i 環境の再ホストとそのアプリケーションの再ホスト。 このプラットフォームのシステム管理は、インフラストラクチャーを直接 IBM Cloud、Skytap on Azure および IBM Cloud、または Connectria on AWS に移行することによってオフロードされるものとします。 Infinite i は、再ホストするためにレスキュー中です
Azure または AWS または Google Cloud 上のアプリケーション。 これらのオプションはすべて、インプレース モダナイゼーションまたは疑似モダナイゼーションのいずれかに分類され、IBM i スキルセットに依存します。
Fresche, Google (G4) のツール セットは、IBM i ネイティブ ソース コードの XNUMX 対 XNUMX の変換 (リファクタリング) を提供し、オープン システムおよびクラウド上にアプリケーションを展開するためのゲートウェイを開きます。 しかし、保守性を考慮すると、このオプションの好みは薄れつつあります
銀行などの大企業向けの未来的なビュー。 銀行、より具体的には保険会社は、ますます増加する規制やコンプライアンスの要求など、非常に動的なビジネス ニーズを抱えているため、保守性の高いコード ベースが必要になります。
インプレース モダナイゼーション (最後の手段) とリファクタリングを残して、他のオプションは大きく XNUMX つのオプション、つまり COTS の置き換えまたはアプリケーション全体の書き換えのいずれかにグループ化できます。 これらのオプションには、それぞれ長所と短所があります。 ほとんどの
中規模および大規模の銀行や、複数の国または複数の地域で事業を展開している銀行のコア アプリケーションは、その宝物、強み、およびその存在を可能にするものです。 そのため、COTS アプリケーションの正確な適合性により、COTS の採用率は制限されます。
カード処理、ロイヤルティ、報酬管理など、銀行の豊富な機能を評価します。
現在、銀行には書き換えという他のオプションが残されています。 誰もが知っているように、既存のアプリケーション (機能的には同等ですが、アーキテクチャ的には最新のもの) をターゲット ランドスケープに書き直すことは、新しいアプリケーションを構築することに似ています。 リバースエンジニアリング
Fresche および ARCAD のツールを使用すると、ルールの抽出を高速化できます。 アジャイル、DevOps、テスト自動化などを利用した新しい開発方法であり、書き直しはそれほど長くはかからないかもしれませんが、短くもありません。 一部の大手銀行は書き直しを試みた
と実験中。 多くの銀行は書き換えに関心を示していますが、費用対効果が高く、堅牢でリスクのない、またはリスクの低い移行を探していますが、それはまだ遠い先です.
書き直しの予想されるタイムラインとは別に、ターゲット ランドスケープ、ターゲット テクノロジ、ターゲット アーキテクチャ、規制とコンプライアンスの課題、変革活動を採用するための組織変更、
大規模なインフラストラクチャなどへの現在の投資は、ほとんどの銀行の全体的な IBM i 移行スケジュールに影響を与えます。
IBM はまた、Power サーバー (10 年に発売された Power2021 ベースのサーバー) および IBM i (7.5 年 2022 月にリリースされた XNUMX) に継続的に投資し、アップグレードしており、このプラットフォームを維持する勢いを維持するために、オープン テクノロジーのサポートも行っています。
サポート期間 (通常は 7 年 + 3 年 – 通常 + 延長) と、他の環境 (AIX) での Power サーバーの再利用可能性は、意思決定のための追加のスペースを提供する重要な要素の一部です (プラットフォームからの離脱を急ぐ必要はありません)。
まとめ
これらすべての要因により、IBM i アプリケーションを実行する必要性は、今後何年にもわたって高いままです。 つまり、企業が有効な代替手段を見つけるまで、これらのアプリケーションをサポート、維持、および強化する必要があります。 しかし、
同時に、従業員が IBM i のスキル セットに関与することはますます難しくなっています。 このプラットフォーム用の強化された IDE とツールを活用して、開発要員を向上させる時が来ました。
