fbpx

API、DevOps、マイクロサービスの世界におけるレガシーの近代化

要約

主な研究課題

  1. 現代のアーキテクチャはどのように見え、どのようにしてイノベーションを可能にしますか?
  2. この最新のアーキテクチャにおけるレガシーシステムとは何ですか?
  3. 新しいデジタル企業をゼロから構築することは、真に近代的な金融機関になる唯一の方法ですか?

金融サービスにおけるデジタルトランスフォーメーションの焦点の多くは、顧客に面した外部チャネルにあり、実際には、実質的なトランスフォーメーションの機会はフロント、ミドル、バックオフィスにまたがっています。変化の激しい期待に対応するため、金融機関は新しいレベルの俊敏性と自動化を実現する必要があります。

マイクロサービス、API、およびDevOpsの組み合わせにより、金融サービス会社はレガシーアーキテクチャを変換し、これらの重要なシステムの制限を分離できます。APIは、従来のバッチベースのオンプレミス統合アプローチと、オムニチャネル配信を支えるクラウド、モバイル、ソーシャルアプリケーションとのリアルタイムデジタル統合との間の橋渡しも作成します。

過去10〜20年の間に、サービス指向アーキテクチャー(SOA)とWebサービスを利用するシステム統合テクノロジーは大幅に改善されましたが、コアビジネスオペレーションアプリケーションとビジネスオペレーションプロセスはほとんど変わっていません。モノリシックレガシーシステムは、顧客に付加価値サービスを組み込むための金融機関の取り組みを妨げ続けており、俊敏性とイノベーションの面で課題を提起しています。

主要な銀行および保険組織は、マイクロサービス、DevOps、およびAPIの組み合わせを使用して、より柔軟で俊敏な開発および展開方法を使用する最新のデジタルアーキテクチャに移行しています。

デジタルシフトとイノベーション

テクノロジーの根本的な変化と、急速な消費者の採用、およびユーザビリティに関するスタッフの期待の高まりにより、金融サービスの提供と実装の方法が大幅に変化しました。

物理機関から仮想機関への移行

ほとんどは、デジタルの始まりをWebの台頭と関連づけています。しかし、Web の台頭は、初期のレンガとモルタルから電話への移行に続き、高価な支店と高い通りの存在感が、コールセンターを通じて運用コストを抑えて提供される金融サービスに取って代わりました。多くの重要なブランドがこの変化から1980年代に成長し、現在も営業している大規模な既存企業を形成しています。

Webの台頭とオンラインへの移行により、世界は24時間年中無休のモデルに移行し、セルフサービスとeコマースが王様となりました。多くのレガシーシステムとレガシービジネスモデルは、24時間年中無休ではなく12時間/週6日に近かったため、この移行により、24時間年中無休のサポートを売り込む新規参入者が増加しました。コンタクトセンター機関の新しいバッチでさえ、これらの新しい要件に対応するためにスクランブルをかけなければなりませんでした。

これに対応するために、多くの既存の金融機関は、既存のシステムの隣に隣接するアーキテクチャを構築しました。既存の製品と販売アプローチをサポートしていましたが、24時間365日ではなかったシステムです。

OMNICHANNELとEARLY APIの使用

Webの台頭、そして今やスマートフォンの登場後、Web専用または電話専用の施設というアイデアはニッチな遊びのために予約されました。大規模な金融機関やカスタマーサービスに誇りを持っている金融機関は、Webなどの1つのチャネルで着信要求をサポートする必要があるが、支店や電話でそれらを正常に完了する必要があることに気付きました。新しいチャネルごとに新しいテクノロジーのスタックを追加するというコンセプトは、コストが非常に高くなるだけでなく、顧客のニーズも満たしませんでした。

成熟が発生し、SOAは、さまざまなチャネルが消費できる既存のシステムからサービスを公開する手段と見なされました。ここでの目標は、複数のチャネルを正常にサポートし、それらのチャネル間で一貫性を持たせることでした。

初期のSOA APIはソースから直接生成されることが多いシステムを目的とする手段でした。

このパターンでは、エンゲージメントのシステムを可能にするために、SOAサービスが記録システムの前に構築されていることがわかります。この場合、統合レイヤーは、チャネルで可能な限り多くを有効にするために利用可能なものを十分に使用します。

金融機関はこれまで以上に複雑なチャネルを実現しています

新しいチャネルの種類と複雑さの増加に伴い、APIは費用対効果の高い導入に不可欠です。以下は日本のみずほ銀行の2つの例です。

みずほ銀行の絵文字の使用は珍しいですが、小売業界全体および金融サービスにおけるAIを利用したチャットボットの増加は並外れています。

API-FIRST

現在の変化は、APIレイヤーの品質が価値の主な推進力であると観察しています。現代の金融機関を構築することの副産物であるどころか、APIはイノベーションを可能にし、より広いエコシステムへの参加を可能にし、コストと配信のタイムスケールの両方を削減する資産です。APIファーストの設計哲学により、API自体に重点が置かれ、企業全体で共有される資産となります。

APIは単一のレイヤーとして表現されています。一部の企業では、パブリックAPIは単一のAPIゲートウェイを通じて単一のレイヤーとして提供されています。マイクロサービスアーキテクチャでは、このAPIは多くの個別のアプリケーションとして実装でき、集中型の実装を必要とせずにマイクロサービスメッシュとして動作する可能性があります。

それがどのように実装または実現されるかに関係なく、適切に設計されたAPIにより、内部システムとサードパーティ組織の両方が金融機関内からサービスを活用できます。さらに、金融機関はパートナーからの商品を提供し、その提供物を独自のチャネルに織り込むことができます。これにより可能になる機会については、次のセクションで詳しく説明します。

ここでは、Intesa San Paoloがパートナーをフロントエンドでアーキテクチャに組み込み、サードパーティがバックエンドでトランザクションサービスを提供しています。

イノベーションを可能にする

一部の人々はフィンテックスが最終的に銀行を陳腐化させると信じていますが、現在の現実は、銀行とフィンテック企業がイノベーションのための協力的パートナーシップに入り、銀行が革新的な製品、新技術、スタートアップ文化にアクセスできるようにし、フィンテック企業が資金調達、規制、専門知識と顧客へのリーチにアクセスできるようにしていることです。fintechsを有効にする銀行、およびfintechsを有効にする銀行のプレス発表は引き続き見られます。この傾向は、保険業界およびインシュアテック企業との関係においても広く見られます。

これらのAPIパートナーシップの多くは、レガシーテクノロジーに組み込まれた顧客データとサービスに依存しています。銀行とフィンテック企業、保険会社、保険会社は、API を連携させて活用することでそれぞれの強みを活用し、各エンティティが単独で行うよりもはるかに顧客体験を向上させます。

モジュラーファイナンシャルサービス

マイクロサービス、DevOps、Open APIを活用する場合、金融機関は、パラダイムシフトを実行して、デジタル金融サービス企業に変身する必要があります。マイクロサービス、DevOps、Open APIは、それ自体が目的ではなく、モジュール化の手段です。これらのテクノロジーと開発アプローチを活用することで、金融機関はパラダイムシフトを実行して、モノリシックな統合金融サービスではなく、モジュラー金融サービスのプロバイダーに変身することができます。

主な研究課題1

現代のアーキテクチャはどのように見え、どのようにしてイノベーションを可能にしますか?

ますます最新のアーキテクチャまたはデジタルアーキテクチャがAPIとマイクロサービスを備え、DevOpsに見られるような大幅な自動化を活用しています。

レガシーシステムの変革

レガシーチャレンジ

歴史的に、金融サービスの人々がレガシーについて話したとき、40年前のアプリケーションを実行しているメインフレームのイメージが思い浮かびました。実際、金融サービス会社のIT部門の古い警備員の多くは、コンピュータにプログラムを入れる手段としてパンチカードをまだ覚えています。

この新しいITレシピの構成要素と、従来のITアプローチと比較した相対的な利点を示しています。

この状況では、デジタルテクノロジーの新しい定義がはるかに高速であるため、レガシーシステムは俊敏性、市場投入までの速度、および製品の流通方法の柔軟性の点で金融機関を無効にするように認識されています。

つまり、レガシーシステムは遅くなりませんでした。代わりに、変更の速度、品質、コストの面で基準が引き上げられました。

セレントのレポート、2018年4月にコアバンキングトランスフォーメーションのモデルバンク賞を受賞:ザイオンズ銀行、2018年4月、ザイオンズ銀行は次のように課題を表明しました:

  • コスト:回避策の数が多いため、レガシーシステムを維持すると、最新のコアバンキングシステムを実行するよりもコストが高くなります。そのままにしておくように構築されたシステムを開くリスクはさらに多いため、統合作業はコストがかかります。
  • 柔軟性:大規模なメインフレームベースのレガシープラットフォームは、安定性と速度のために構築され、最終的には数百万のトランザクションをバッチで処理します。それらは変更されるように作られていませんでした。新規および変更の銀行機能には、継続的な開発が必要です。レガシーコアの上にモダンで柔軟なカスタマーエクスペリエンスを開発することは非常に困難であり、さらに難しくなるだけです。
  • 開発者の才能:これらのコアプラットフォームの一部に最初に取り組んだ開発者の多くは、キャリア(または人生)の終わりにいます。新しいITプロフェッショナルは、JavaやC#などの言語で記述されたより近代的なアーキテクチャに惹かれています。若い開発者は、銀行システムの相互接続性の広さを理解するのに苦労することが多く、その多くは十分に文書化されていません。これは、プロジェクトを実行する能力を妨げ、あるストリングを引っ張ると別のストリングを解く可能性があるため、大きなリスクをもたらします。(リアルタイムのアカウンティングとコンポーネント化されたアーキテクチャーを備えた)最新のコアに切り替えることは、今日オンストリームで登場するIT人材の仕事を豊かにするものと見なされています。
  • デジタル顧客に対応する能力:ハイテク企業は、デジタルで可能なことを先導しています。顧客は最新のデジタルエクスペリエンスを期待しており、レガシーコアシステムはそれを提供するために挑戦されてきました。リアルタイム、クラウドの準備、コンポーネント化、およびオープン性に関する機能が欠けているコアシステムは、今日の競争に追いつくのがより困難で費用がかかることに気づきます。そして、その課題はより困難になるだけです。

National Australia Bankの近代化から6か月後の結果は、実現可能な俊敏性と市場投入までの速度の向上の好例です。

Waterfall Vs. アジャイルと DevOps

歴史的に、IT変更プロジェクトとプログラムは、大規模なエンジニアリングの提供を連想させるウォーターフォールスタイルで頻繁に提供されていました。焦点は、要件を事前に定義してから、成果物全体の設計にありました。次に、これが構築され、徐々に強化されたテストフェーズを経て、構築されたものが要求されたものであることを証明します。

アジャイル手法と現在のDevOpsは、要求、テスト、および配信の間の時間を短縮し、複数のより短い配信で配信し、このプロセスを可能な限り自動化することを目指しています。継続的インテグレーションがビルドおよび統合テストアクティビティの自動化にどのように役立ち、次に継続的デリバリー、そしてデプロイメントが自動化の量をどのように増加させるかを示しています。

オンプレミスモノリスとクラウド内のマイクロサービス

DevOpsのOps側では、IT 変更の速度を向上させる可能性がさらに広がります。従来、ソリューションの展開では、マシンを注文し、オペレーティングシステムをセットアップし、パッチを適用し、セキュリティのために強化する必要がありましたが、それはアプリケーションを稼働させてビジネスを行う前でした。

インフラストラクチャのコミッショニングに非常にコストがかかる場合、それが高度に利用されていることを確認します。さらに、インフラストラクチャを不必要に委託しません。したがって、Web規模のアーキテクチャでさえ、限られた数のマシンで実行されました。

現在、マシンはクラウドから要求され、自動的に構成され、ネットワーク内の他のマシンに数か月ではなく数分でリンクできます。

DevOpsとAgileはIT業界にとって新しいものではありませんが、金融サービス業界の一部は、それらを取り上げるのに時間がかかりました。これらのアプローチから期待できるメリットについて実際の状況を説明するために、アーリーアダプターのHiscox がCelent Model Insurer 2015で報告した内容を以下に示します。

  • プロジェクトを予定どおりに予算内で提供します。これは、Hiscoxにとってこの規模のプロジェクトで初めてのことです。
  • このプラットフォームにより、Hiscoxは、通常の10週間のウォーターフォール配信モデルから2週間の反復サイクルに移行できるようになりました。
  • 最初の数週間(稼働後)の欠陥の数を最小限に抑えます。その数はHiscoxの予想をはるかに下回っていました。
  • 修正と製品構成の変更をより迅速に実稼働環境に提供します。DevOpsを通じて導入されたツールのおかげで、リリースは6分(平均)かかりますが、以前のテクノロジースタックでは3時間かかります。稼働前の1週間で、Hiscoxは47のリリースを実行しましたが、これは従来のデプロイメントツールでは不可能でした。
  • 発売以来、Hiscoxは9つの環境全体で週平均26回(平均)展開しています。各自動デプロイの平均コスト削減は、週あたり約7,000ポンドに相当します。これは、年間約37 万ポンドの節約に相当します。
  • 一貫性、時間の節約、手動エラーの調査、時間の節約による新しいスタッフのトレーニングの追加の利点により、コストを回避できました。ピーク時には、チームは1日に19回の展開を実行しました。

アプリケーションを独自のインフラストラクチャに数分でデプロイできる世界では、ソフトウェアアーキテクトは、コンポーネントのサイズと、インフラストラクチャの他のコンポーネントとは別にデプロイする方法を再考することができます。さらに、サーバーは使い捨てになります—サーバーが誤動作し始めたら、それを破棄して新しいサーバーを起動します。ハッキングされた、またはバグのあるサーバーを「救出」する必要はありません。

この環境では、APIは多くの独立したアプリケーションによって提供され、独自のサーバー上で実行され、自動的にテストされ、自動的に保守され、必要に応じて自動的にスケーリングされます。

マイクロサービスの作成とデプロイ

マイクロサービスは、レガシーシステムを最新化するための一般的な選択肢です。Microservicesのアーキテクチャは、小さな離散、そして個別に展開可能なサービス―いくつかのケースでは、各サービスはAPI、いくつかのロジックまたはを持つ独自のmicroapplicationあるアプリケーションコード、およびデータの提供に注力します。

したがって、この名前は多くの小さなサービスの集まりであることに由来しています。個別のサービスを使用すると、加速されたツールセットを使用する類似のマルチスキルチームが、APIを駆動する一連のマイクロサービスをサポートできます。セレントのレポート「Honey、I Shrunk the Services:Microservices in Insurance」(2017年12月)で詳しく説明されているように、APIの存在にはマイクロサービスアーキテクチャは必要ありません。ただし、一般的なマイクロサービスアーキテクチャは、より広範なAPIにまとめられたAPIの提供に重点を置いています。

エラスティックインフラストラクチャ内のマシンに迅速に展開できる小さなコンポーネントを使用すると、高度にスケーラブルで適応性のあるインフラストラクチャが可能になります。マイクロサービスは、「顧客名の取得」、「内部転送の作成」、「クレジットラインの増加のリクエスト」などのAPIを介してアクセスできる一般的なビジネス機能を提供します。マイクロサービス主導のアプローチにより、サービスの再利用が可能になり、統合コストと複雑さが軽減されます。

マイクロサービスの構造

マイクロサービスをさらに詳しく調べて、その複雑さを確認する場合、多くのマイクロサービスを構築することは、その複雑さのどれだけが自動化できるかを観察するまで、圧倒される可能性があります。

自動化とツールを一貫して使用してマイクロサービスを構築することにより、各サービスのセキュリティ保護、ロギングを使用した各サービスの監視と維持、およびパフォーマンス、フォールトトレランスに必要なキャッシングの使用、または脆弱なレガシーシステムの保護などのベストプラクティスを標準化して導入することが可能です。

マイクロサービスアーキテクチャは、マイクロサービスのビルド作業の大部分を自動化することによってのみ機能します。

レガシートレードオフ

レガシーモダナイゼーションに対する1つの答えは、すべてのレガシーシステムを取り除き、高度に自動化された高速なマイクロサービスで置き換えることです。これは賞賛に値する目標ですが、ほとんどのレガシーシステムは何万人もの労力を費やしており、複雑なルールを具体化し、複雑なデータが含まれていることがよくあります。それらを交換し、それらが提供するすべての機能を構築することは、重要な作業です。

ほとんどのレガシーシステムには、強力な機能がいくつかあります。

  • 機能する
    多くの場合、レガシーシステムは現在のビジネスとプロセスをサポートしています。
  • 安定している
    レガシーシステムは、多くのバグが修正されるほど十分に長く存在しています。年齢とともに安定します。
  • 安い
    多くの場合、レガシーシステムにはライセンス料がまったくないか、わずかです。さらに、彼らが実行するインフラストラクチャはよく理解され、最適化され、低コストで実行されます。

閉鎖するためにレガシーシステムを置き換えることは、ビジネスケースがないため、悪い投資になる可能性があります。

API指向のマイクロサービスアーキテクチャに移行することには大きなメリットがありますが、金融機関のほとんどのソフトウェアは古く、そのように構築されていないというのが単純な事実です。これらのシステムは、いくつかの点で制限がありますが、依然として価値があります。金融サービス業界は、テクノロジーを移動することには理にかなった実践的なアプローチを必要とし、そうでない場合にはレガシー資産を活用する必要があります。

以下では、金融機関および金融機関に対するソフトウェアベンダーがインフラストラクチャを最新化するために取っているいくつかのアプローチについて説明します。

主な研究課題2

この近代的なアーキテクチャのレガシーシステムとは何ですか?

レガシーは、COBOLやアセンブラーなどの特定のテクノロジー、またはシステムの時代(20 歳)であると認識されていました。今日、レガシーシステムの特徴は、変更するには遅すぎることです。

レガシーシステムとは、テクノロジーや年齢に関係なく、企業を無効にするシステムです。

新しいレガシーモダン化

目的に合った複数の記録システムがある場合は、それらを移行しないのが理にかなっています。上記のレガシー定義を採用した場合、製品システム1からNまでが無効になっていない場合、その前にAPIを構築できれば、引き続き使用するのが妥当です。ほとんどのレガシーシステムには、それらをサポートする、または回避策として機能するための周囲のシステムセットがあります。

これらの周囲のシステムは、実行と維持にコストがかかる可能性があり、レガシーシステムの影響が軽減されるため、効率を改善するための絶対的な目標となります。一方で、これらのシステムは、最初に段階的な移行アプローチを可能にするかもしれませんが、時間をかけてこれらの周囲のシステムはオフにすることができます。金融機関は、自動化ツールによってサポートされている場合、APIビルド時間を数週間から数分に短縮すると報告しています。

この技術的負債の運用コストを掘り下げるには、データがアーキテクチャを通過するときにデータが通過する変換の数を分析するだけです。レガシーSOA コンポーネント、そして最終的にはCOBOLプログラムを呼び出す異種のマイクロサービスセットを示しています。次の表は、暗号化と復号化の手順を含め、情報が変換されるたびに表示されます。

マイクロサービスの使用は当然、高度に通信可能なアーキテクチャに傾いていますが、多くの呼び出しを活用する不必要に深いアーキテクチャのコストに注意する必要があります。実用性だけでなく、もはや付加価値のないミドルウェアシステムに取り組む勇気も必要です。

デジタルへの実践的な道筋

大きな課題は、APIの実装を周囲のアプリケーションから隠すことです。これが実現できれば、レガシーシステムから新しいシステムへのモダナイゼーションが大幅に容易になります。

歴史的に、エンタープライズアプリケーション統合(EAI)スイートを使用した初期のSOA試行と、エンタープライズサービスバス(ESB)を使用した後期は、多くの場合、レガシーシステムへのコネクタの生成を許可していましたが、これらのプロトAPI は、基になるシステムの問題を直接APIに明らかにしました。APIファーストのコンセプトは、これに対する直接の反応であり、APIの設計を実装よりも上に配置します。

その後、最新のデジタルチームがAPIを設計し、必要なAPIを満たすためにマイクロサービスコードの大部分を生成する場合があります。APIを実現または実行するためにレガシーシステムへのアクセスが必要な場合でも、システム所有者は自動化ツールを使用してレガシーシステムへのアクセスを許可するコードを生成できます。場合によっては、これはマイクロサービスとして作成されることがあります。

その結果、内部APIと目的のAPIの間のマッピングが必要になる場合があります。複雑さに応じて、これが構成されたり、別のマイクロサービスとしてコード化されたりする場合があります。

多くのマイクロサービスとAPI管理プラットフォームは、新しいプログラミング言語、アプリケーション、およびユースケースに重点を置いています。これらのプラットフォームのいずれかを使用してレガシーシステムデータにアクセスするには、基盤となるデータ構造とプログラミング言語(多くの場合COBOL)を理解し、マイクロサービスと付随するAPI を手動でコーディングする必要があります。レガシーシステムへの統合の近代化の課題と重要性を認識し、いくつかのベンダーがメインフレーム接続の有効化ソリューションを提供しています。表1を参照してください。

レガシーシステムのマイクロサービスとAPIイネーブラーの成功は、自動化、標準化、テスト、およびレガシーシステムコネクタに対するベンダーのアプローチに大きく依存します。理想的には、ソリューションは基礎となるアプリケーションを自動的に分析して、開発者がWeb サービス、マイクロサービス、またはREST API に変換するために選択できる最新のコードを作成する必要があります。ビルド済みのコネクタとテンプレート(CICSやDB2など)は、開発者がこれらのWebサービス、マイクロサービス、APIを使用して新しいソリューションを構築したり、既存のソリューションを強化したりするのに役立ちます。

レガシーの緩和

レガシーは、テクノロジーの年齢や特定のタイプのテクノロジーによって定義されるのではなく、より単純で、より二元的な判断です。

このテクノロジーは、金融機関がその目標と目的を達成することを可能にしますか?

金融サービスの目標は、業界外の経験と変化によって書き換えられています。他の業界では、スピード、俊敏性、スタッフ、パートナー、顧客の人間的経験の面で、期待を根本的に高めています。目標の投稿は変化し、古いテクノロジー、古い方法、開発者によるハンドコーディングの使用—これらすべてが今では遅すぎ、レガシーにもなりすぎています。

しかし、上で見たように、金融機関は適応しており、新しい方法を採用しており、レガシー近代化への新しい道をすでに開いています。この先駆者は、新しい技術、テクノロジー、および機会を採用することにより、必要に応じて近代化するだけでなく、レガシーシステムの俊敏性と速度を再発見することもできました。

レガシーの影響を軽減および制限する実用的なアプローチにより、レガシーシステムを再び有効にすることができます。可能な場合、レガシーシステムが過負荷になり、十分に速くなり、新しい基準を達成できる場合、それらは組織がその目的を達成するのを支援する役割を果たすことができます。

マイクロサービスアーキテクチャへの参加者としてのレガシーシステム

近い将来、多くの既存の組織がアーキテクチャをターゲットにして、複数のレガシーシステムがマイクロサービスと共存して、複数のクライアントによって消費されるAPIを提供するようにします。

APIを実装の前のファサードとして活用することで、APIが主要な成果物となり、その下の実装をシフトできる世界に移動できます。表2は、マイクロサービスアプローチにより、新しいAPIやAPIの変更を従来のアプローチよりも簡単に提供できるシナリオを示しています。

進むべき道

レガシーは低速ではなく、デジタルアプローチほど高速ではありません。速度が遅くても、役に立たないというわけではありません。レガシーシステムは、多くの場合保存する価値があり、再実装にコストがかかるルール、データ、および製品を具体化します。

フィンテックなどの新興企業はデジタルビルドを全面的に支持していますが、これは多くの大規模金融機関が課すことのできない贅沢です。

このレポートでは、セレントはレガシーを活用してデジタル化し、大きくてゆっくりとした象のダンスを作る方法があることを示しました。実用的なアプローチが可能であり、マイクロサービス、API、およびDevOpsの使用から見た自動化と速度の恩恵を受けることができます。

主な研究課題3

新しいデジタル企業をゼロから構築することは、真に近代的なデジタル企業になる唯一の方法ですか?

重要な変更により、システムを高速化し、市場投入までの時間を短縮できます。

以前はレガシーと見なされていたシステムは、レガシーではなくなるように改善できます。

実用的なレガシー近代化戦略に着手する人のためのいくつかの最後のヒントを以下に示します。

  • レガシーは存続でき、自動化は交渉不可能です。
    最新のDevOpsプラクティスと高速自動化ツールを活用することが、俊敏性を実現する唯一の方法です。レガシーの方法とツールがレガシーシステムに残っていると、企業は引き続き無効になります。
  • 調整はスピードの敵です。
    統合テクノロジーの多くのレイヤーとそれらを管理するための複数のチームがあると、俊敏性が損なわれます。DevOpsは、設計、構築、展開、およびテストのアクティビティを自動化または合理化することを目指していました。これまで、すべてが別々のチームでした。同じことをする機会のためにあなたの遺産を周回するシステムを見てください。これらは自動化する必要があるか、完全に削除することを検討してください。
  • 最初にレガシーに取り組むことなく、新しい収益源を開くことができます。
    セレントは、レガシーシステムと共存しながら、新製品を提供し、古い製品を再パッケージし、新しいサービスに参入する組織の例を観察しています。

このレポートの短いバージョンは、「テクノロジーの変化が速くなっているため、ペースを維持するために迅速に移動する必要がある」と解釈されるかもしれません。ここでは、これらのテクノロジーを利用するためのいくつかのルートを提示しました。レガシーシステムの価値を失うことのないルートもあります。

もちろん、挑戦は始めることです。

このレポートは役に立ちましたか?今後の研究トピックに関するコメント、質問、提案はinfo@celent.comに送信してください。

セレントの専門知識の活用

このレポートに価値があると思われる場合は、カスタム分析と調査のためにセレントに依頼することを検討してください。このレポートの作成中に得た経験と知識により、戦略の作成、改善、または実行を効率化できます。

金融機関へのサポート

従来のモダナイゼーションに関連して私たちがサポートする典型的なプロジェクトには、次のものがあります。

ベンダーの短いリストと選択。私たちはあなたとあなたのビジネスに固有の発見を行い、あなたのユニークなニーズをよりよく理解します。次に、選択したベンダーにカスタムRFIを作成して管理し、迅速かつ正確なベンダー選択を支援します。

ビジネス慣行の評価。私たちは、特にレガシーの近代化、開発ツール、および方法論において、ビジネスプロセスの評価に時間を費やしています。市場に関する知識に基づいて、潜在的なプロセスまたはテクノロジーの制約を特定し、業界のベストプラクティスの実装に役立つ明確な洞察を提供します。

ITおよびビジネス戦略の作成。私たちはあなたの経営陣、あなたの第一線のビジネスとITスタッフ、そしてあなたの顧客からの視点を収集します。次に、現在の位置、制度的能力、およびテクノロジーを目標に対して分析します。必要に応じて、短期および長期のニーズに対応するためのテクノロジーおよびビジネス計画の再構築を支援します。

ベンダーへのサポート

私たちはあなたがあなたの製品とサービスの提供を洗練するのを助けるサービスを提供します。例は次のとおりです。

  • 製品およびサービス戦略の評価
    機能、テクノロジー、サービスの観点から、市場での地位を評価するお手伝いをします。私たちの戦略ワークショップは、適切な顧客をターゲットにし、彼らのニーズにあなたの提供物をマッピングするのに役立ちます。
  • 市場のメッセージと販促のレビュー
    潜在的なクライアントとの豊富な経験に基づいて、私たちはあなたのマーケティングおよび販売資料を評価します-あなたのウェブサイトとあらゆる担保を含みます。

SNSでもご購読できます。

コメントを残す

*