メインフレーム主導の金融サービス向けデジタル・トランスフォーメーションを基盤とする銀行

これは、メインフレームのモダナイゼーションに関する5部構成のシリーズの第3段です。

メインフレームのモダナイゼーションが金融業界だけのものではないことについて説明したところで、このトピックの核心に触れる必要があります。モダナイゼーションの世界最大の課題は銀行業界に集中しています。

インターネットやクラウド・コンピューティング、そしてスマートフォンやモバイル・アプリケーションが普及する前は、銀行は大規模な電子決済ゲートウェイを通じて決済を行い、メインフレームを記録システムとして運用していました。

金融サービス企業は、グローバル経済システムの中核を管理し、動かすため、機関とみなされます。そして、金融機関の心臓部にあるものが、IBMのメインフレームなのです。

銀行は、メインフレーム・アプリケーションとデータ資産をクラウドのような柔軟性、俊敏性、イノベーションの最新基準に引き上げて顧客の需要に応えることで、成功した場合には最大の利益を得られる一方で、失敗した場合には最大の損失を受けることになります。

記憶に新しいところでは、2008 年の「大きすぎて潰せない」危機から、一部の大手預金銀行の過剰エクスポージャーと破綻を引き起こしている現在のパンデミック後の高金利まで、私たちは世界的な経済の不確実性を経験してきました。

銀行の破綻は多くの場合、経営判断や方針の誤りの結果であるものの、モダナイゼーション施策や戦略の遅れにも一因があると考える十分な理由があります。経営幹部は、データ内のリスクを見つけるために、もっと良い分析を行えなかったのでしょうか？なぜ彼らは新しいモバイル・アプリケーションのリリースに失敗したのでしょうか？誰かがハッキングして顧客をロックアウトしたのでしょうか？

メインフレーム・アプリケーション・モダナイゼーションを延期すると機会コストが発生することは誰もが知っていますが、現在運用をサポートしているシステムを変更するのは危険であるという考えがあります。

地域銀行や地方銀行では技術的リソースが不足しがちである一方、大規模機関は圧倒的な技術的負債や重いデータ移行の課題、あるいはビジネスケースの構築に苦労するといった問題を抱えています。

大規模・小規模を問わず、銀行はモダナイゼーションや移行の取り組みで一度ならず失敗を経験している可能性が高いと言えます。そうした取り組みが頓挫するたびに、組織内のITリーダーたちは「分不相応なことに手を出してしまった」と感じてきたのです。

モダナイゼーションの取り組みの変革には、メインフレーム・コードの大規模な書き換えや、骨の折れる作業で費用もかかるリフト・アンド・シフト作業を行う必要はありません。代わりに、チームはビジネスの最も重要な優先事項に合致するものをモダナイズする必要があります。

ここでは、単にモダナイゼーションの取り組みを再開するだけでなく、分散型ソフトウェアアーキテクチャの高度化や、今日の高い顧客体験の期待に応えるという文脈の中で、メインフレームの価値を大幅に高めた銀行の優れたユースケースをいくつか紹介します。

多くの銀行は、分散型システムの登場前にCOBOLやその他の言語で書かれた可能性のある既存のメインフレーム・コード内の技術的負債に対処することを恐れています。多くの場合、元のシステムを設計したエンジニアはもはや存在せず、ビジネスを中断することは賢明な選択肢ではないため、ITの意思決定者は中間層をいじって場当たり的に対応し、変革を先送りにしてしまいます。

Atruvia AGは、世界有数のバンキング・サービス・テクノロジー・ベンダーの1つです。800を超える銀行が、4つのデータセンターで稼働する8台のIBM z15システムによって支えられ、年間約1,000億件の取引を処理する同社の革新的なサービスを利用しています。

彼らは、全面的な置き換えではなく、既存のメインフレーム上で稼働するCOBOLと並行して、JavaでRESTfulサービスを構築する形でリファクタリングを行うことにしました。コア・バンキング・トランザクションの85％を最新のJavaに段階的に置き換えることで、メインフレーム上のワークロードのパフォーマンスを3倍向上させながら、銀行顧客向けの新しい機能を構築することに成功しました。

ほとんどの銀行では、データセンターに本番メインフレームのプライマリ・コピーを置き、オフサイトにセカンダリ・バックアップを用意したり、仮想テープ・ソリューションで数カ月ごとに新しいバッチ・アップロードを行ったりなど、災害復旧（DR）のために何らかの形で冗長性を持たせたデータ保護計画を策定しています。

データ量が増大し、取引やアプリケーションのエンドポイントが増えるにつれて、旧式のバックアップ技術でデータをコピーするコストや時間が増大し、それを復元する作業も遅くなるため、ダウンタイムの発生による災害復旧（DR）のギャップが生じる可能性がある。ランサムウェアを含め、現代の銀行のコンピューティング環境をフェイルセーフにするためには、より迅速なバックアップとリカバリが不可欠です。

オーストラリアのトップ5銀行であるANZ社は、850万人を超える顧客に高い可用性を確保するために、よりタイムリーなメインフレームのバックアップ容量の増強と、災害復旧のパフォーマンスの高速化を目指しました。

サイト間のレジリエンシー機能を構築し、IBM zSystemsサーバーをミラーリングしてHyperSwap機能を活用することで、停止を伴わずに複数ターゲットへのストレージスワップを可能にしました。これにより、いずれかのサーバーがバックアップやリカバリ処理中でも、同一構成の別のサーバーが本番ワークロードを引き継ぐことができます。

ANZのIT部門のリーダーたちは、システム稼働率の向上により安心感を得ています。しかしそれ以上に、現在では、顧客への事業継続性を保証できる認証取得可能な最新の災害復旧体制を整えています。

銀行は、顧客満足度、財務業績、インフラストラクチャーへの投資、リスク管理に影響を与える重要なビジネス上の意思決定のほぼすべての側面について、高度な分析に依存しています。

メインフレーム上での大規模データセットに対する複雑な分析クエリは、コンピューティング予算を大幅に消費し、実行に何時間も、場合によっては何日もかかることがあります。クラウドのデータウェアハウス など、データを他の場所に移動すると、さらに大きな転送遅延が発生する可能性があり、古いデータに基づく判断や質の低い意思決定につながることがあります。

トルコで2番目に大きい銀行であるGaranti BBVAは、クエリワークロードを加速しつつメインフレームCPU消費を削減するIBM Db2 Analytics Accelerator for z/OSをデプロイしました。

分析ワークロードをメインフレームの運用環境の懸念事項やコストから分離することで、Garanti社は毎晩300件を超える分析バッチ・ジョブを実行できるようになり、以前は2日かかっていたコンプライアンス・レポートをわずか1分で実行できるようになりました。

銀行は革新的な新しいアプリケーションとサービスを顧客に提供する能力で競争するため、アジャイル開発テストチームは常にソフトウェアの機能を提供しています。これらは、スマートフォンアプリのフロントエンド改善や、クラウド・サービスとのAPI連携の統合として捉えられることが多いです。

しかし、これらの主要な機能のほとんどすべてが最終的にはメインフレームに関わることになりますDevOpsムーブメントの第一級の参加者として、メインフレーム・チームに参加してもらいましょう。

Danske Bank社は、 IBM Application Delivery Foundation for z/OS(ADFz) を機能開発、デバッグ、テスト、リリース管理のプラットフォームとして活用し、全社レベルのDevOps変革ムーブメントに約1,000人の社内メインフレーム開発者を巻き込むことを決定しました。

既存のCOBOLおよびPL/1コードも、CI/CD管理パイプラインに取り込み、開発者のIDE内で直感的に開いて編集できます。ここでは、グリーンスクリーンを使用する必要がなくなります。この銀行は、以前の半分の時間で新製品を市場に投入できるようになりました。

Danske Bankのお客様事例を読む https://www.ibm.com/jp-ja/case-studies/danske_bank_as

最新の「クラウド生まれ」のフィンテック企業であっても、自社のイノベーションが、取引先を含む絶えず変化するハイブリッド環境とどのように連携する必要があるかを考慮することが賢明です。

モバイル・アプリケーションでの取引も、最終的にはグローバルな決済ネットワークや規制機関、他の銀行に到達します。それぞれのリクエスト処理の背後には、独自のメインフレームの計算・ストレージリソースが存在しています。

ここにおいて一つの正解となる進め方は存在しません。なぜなら、銀行ごとに状況が異なり、メインフレーム・アプリケーション・モダナイゼーションの過程で実行可能な変革の方法も多岐にわたるからです。

ITリーダーはどこかの時点から始める必要があり、自社のビジネスニーズや、メインフレームが組み込まれる独自のアプリケーション環境のアーキテクチャに最も適したユースケースを選定することが重要です。

詳しくは、このシリーズの他の投稿をご参照ください。

• 第1部：「銀行業務を超えたメインフレーム・アプリケーション・モダナイゼーション」
• 第2部：「クラウドでメインフレーム・アプリケーションをクラウドでモダナイズするための、移行ではなく協働の活用」
• 第4部：「メインフレームとクラウド？オープンソースで簡単に実現」