「ソフトウェア・コンポーネントに対しては、大変大きな期待が寄せられています。」Webベースでソフトウェア・コンポーネントの製品およびサービスを提供するFlashline.comのCEOである、Charles Stackはこう語ります。「金融機関は、目覚しいスピードで可能な限り多くのサービスをWebに移行しつつあり、そのためにソフトウェア・コンポーネントを使用しています。」 Stackは、大手の銀行や証券会社を含むFlashline.comの多くの顧客が、Web戦略の基礎としてIBMのWebSphereやBEAのWebLogicのアプリケーション・サーバーを採用し始めたとも言います。

マサチューセッツ州のボストンを本拠とする調査会社Giga Information Groupの副社長で調査リーダーでもあるMike Gilpinによると、「世界中のほとんどすべての銀行がWebSphereまたはWebLogicのライセンスを取得するか、あるいはそのための準備をしているようです。」

金融サービス市場向けのアプリケーション・サーバーを提供しているベンダーの数は40を超えますが、WebSphereとWebLogicが圧倒的な市場シェアを獲得しています。

「これら2つに共通する長所は、業界標準に準拠していることです。」 ノース・カロライナ州シャーロットを本拠地とするEontec, North AmericaのCEOであるColin Piperは言います。Eontecは、BankFrameというコンポーネント・ベースのEnterprise JavaBeans (EJB) ソリューションを販売しています。このソリューションは、事務処理の管理、貸付の処理、取引の送信、銀行会計の統合、企業の銀行取引、コール・センターのサポート、および支店の出納機能など、銀行業務の中核となるプロセスを大手金融機関に提供するものです。Piperは、世界中の銀行業界が2000年から2004年までの間にコンポーネント・ベースのソフトウェア製品に費やす金額が、77億ドルを超えると予想しています。

銀行が先導

これまでのところ、金融業界によるコンポーネント・テクノロジーの採用には、分野ごとに差があります。リテール・バンクが最も先行していて、その後に証券会社と保険会社が続いています。

リテール・バンクは、コンポーネント・テクノロジーの追求に最も積極的で、BankFrameによってサポートされるような中核業務処理に使用しています。オンライン・バンキングの人気が高まっていることも、コンポーネント・テクノロジーの採用に大いに貢献しました。

従来の仲介モデルでは、証券会社がコンポーネント・テクノロジーの採用を促されることはありませんでしたが、いくつかの仲介会社は、現在様子見中といったところです。「証券会社は、統合機能としてはメッセージ交換テクノロジーのほうに注目していました。彼らも、技術的に銀行と同程度に進歩的だったのですが、それはコンポーネントの分野以外でのことでした」とGilpinは語っています。しかし、オンラインによる株取引がマーケットの主要な部分となった今では、コンポーネント・テクノロジーは確固とした地位を得つつあります。

「保険会社には、銀行や証券会社が必要性を感じるほどには、コンポーネント・テクノロジーに興味を引かれるようなビジネス・ニーズが存在しないのです」とGilpinは言います。「生命保険会社は、顧客から電話が掛かってこないことを望んでいます。預かった金を自分のものにしておきたいからです。通常であればコンポーネント・テクノロジーにおけるWebの使用と投資を促進するはずの、顧客との対話にあまり注意が向けられません。」 彼は付け加えます。「コンポーネント・テクノロジーの主な推進力となっているのは、営業担当者と顧客との対話の最適化ですが、損害保険会社が重視しているのは、そのようなことではなく、支払い請求を効率良く処理することです。」

Gazebo Software Solutions Inc. の社長で、Object Management Group (OMG) の金融対策責任者でもあるRob Mickleyは、金融サービス業界はコンポーネント・テクノロジーの動向に対応する態勢が十分に整っていなかったと考えています。「インターネットは皆を驚かせました」と彼は言います。「インターネットは急速に広まりましたが、[金融業界]が急速に動いているようには思われていません。」 しかし、Mickleyはすぐに、コンポーネント・テクノロジーはインターネットの革命に先立つものであり、現在のように業界がアプリケーションをWebに移すことに力を入れるようになる前から 独自にかなり勢いを得ていたことを指摘します。Webを目指しコンポーネント・テクノロジーを推し進めている力は、コンポーネントの革命における最近の波を表しているのにすぎない、と彼は主張します。

さらに重要なこととして、Mickleyは、金融サービス向けのアプリケーション・サービス・プロバイダー (ASP) モデルが金融サービス業界の 商品開発への傾向を刺激するであろうと予測しています。「しかし、これがうまくいくには、標準となるようなコンポーネント・インターフェースがなければなりません」と彼は言います。「銀行 [およびその他の金融サービス提供者] は、この新しいモデルをサポートするために彼らのシステムを業界標準のインターフェースに開放するように、との要望に耳を傾けつつあります。すでに業界にはホーム・バンキング、株式仲介、代金支払いなどの例があります。これらは急速に標準化されつつあります。また、入札システムや、金融サービスへのワイヤレス・アクセスなどの新分野でも進展が見られます」と彼は観察しています。「現時点では、これらの標準ベースのインターフェースの中心になっているのは、顧客対応サービスです。しかし、業界によるテクノロジーの利用が成熟し、新しい企業間 (B2B) モデルが確立されると、従来は後方事務処理であった作業のためのコンポーネント・インターフェースが、脚光を浴びるようになるでしょう。」

上に戻る

なぜコンポーネントなのか?

再使用可能なソフトウェア・コンポーネントの魅力は、その自己完結的な性質だけにあるのではなく、「コンポーネント・テクノロジーとは無縁に設計した」既存のシステムに対しても「門戸を開放する」する能力にあると、Mickleyは言います。

コンポーネントは、自立型で、エンタープライズ・レベルの、分散された機能をサーバー上に用意し、また、開発者がシステム機能をさまざまなレベルの細かさで定義およびカプセル化する際にも役立ちます。コンポーネント・テクノロジーを採用することにより、古いシステムを使用して事業を行ってきた既存企業は、最新のコンポーネント・アーキテクチャーに従って設計されたシステムを手にして設立された新興企業に、立ち向かいやすくなります。

Piperは、ソフトウェア・コンポーネントは、従来のプログラムよりも保守、サポート、および将来の要件に応じた変更が用意であると付け加えます。「[金融業界で] サーバー中心の手法を取り入れることの利点は、ビジネス・プロセスを定義し、それを一連のソフトウェア・コンポーネントとして一度コーディングするだけで、複数のチャネルに届けることができることです。」

さらに、コンポーネント・テクノロジーの多くの利点を企業が認めるようになるにつれ、現在業界全体に広まっている大規模な金融サービス・ソフトウェア・スイートは、その魅力を失い始めているようです。「[単一の一体型プログラムではなく] 個別の自立型コンポーネントからなる金融システムを実現すると、柔軟性が高くなります」とMickleyは言います。「利用者は、コンポーネント・インターフェースを手に入れるだけでなく、分散コンポーネントも手に入れることになります。それにより、システムを各地に広げたり、特定の場所に機能を割り当てたりするような、システム・レベルでの決定を行えるようになります。」

Piperは、多くの銀行が単一ベンダーの一そろいのソフトウェアではなく、コンポーネントを使用してビジネス・プロセスを受け渡そうとしている、別の理由を挙げています。「彼らは、購入するのか自前でつくるのかということで悩まされるのに、嫌気がさしたのです」と彼は言います。「完全なパッケージを購入したとしても、かなり徹底したカスタマイズが必要な場合があり、初期ライセンス費用の3倍近くの費用がかかることもあります」と彼は見ています。「システムを最初から構築した場合にも問題はあります。そうしたシステムは私有のものになりますから、システムが存続する間、それを作成した会社が自分でサポートや保守をしなければなりません。」 Piperは、コンポーネント・モデルには両方の最も良い点が備わっていると主張します。事前に構築されたコンポーネントでは、バックエンドで必要となるカスタマイズは、既存のシステムとの通信に関するものだけであり、フロントエンドで必要となるカスタマイズは、特定のルック・アンド・フィールに合わせることだけです。

上に戻る

COMとEJB

業界ウォッチャーたちは、インターオペラビリティー・アーキテクチャーとソフトウェア開発フレームワークの出現が、金融サービス・アプリケーション用のコンポーネント・テクノロジーを採用しやすくするはずであることも強調します。特に、共通オブジェクト・リクエスト・ブローカー・アーキテクチャー (CORBA) は、オブジェクトが異なるプログラム言語で作成されていても相互に通信できるような方法を定義しています。さらに、MicrosoftのComponent Object Model (COM) やDistributed Component Model (DCOM)、およびSun Microsystemのクライアント・サイドJavaBeansやサーバー・サイドEJBなどの開発フレームワークが、コンポーネントへの関心に拍車をかけました。「このことが、多少の緊張を生みます。なぜなら、コンポーネント・マーケットの約80%はCOMコンポーネントが占めているからです」とGilpinは言います。

COMコンポーネントの方が普及しているかもしれませんが、専門家の意見は、金融分野のソフトウェア開発者の間ではEJBコンポーネントが最も人気を得ているということで一致しています。「多くの銀行がJavaを採用しようとしています」と彼は言います。「銀行がアプリケーションを相互に対話させようとした場合、EJBはそのための最善の道になります。」

既存の異質なハードウェアおよびソフトウェア・アーキテクチャーを使用している大手の金融サービス会社は、MicrosoftのCOMやDCOMよりもEJBやJava 2プラットフォーム・エンタープライズ版 (J2EE) にひかれている傾向がありますが、「1つのコンポーネント・モデルだけに頼り切ることはできません」とGilpinは警告します。「寄せ集めを使用することになることは、間違いありません。」 ただし彼は、いくつかの金融サービス会社が、特定の種類の開発向けに優先すべきコンポーネント・モデルをはっきりさせたことに注目しています。たとえば、ある銀行では、特定の部門についてはCOMまたはEJBのどちらのコンポーネントでも購入できるようにして、複数のアプリケーションを含むサーバーに置かれる新規コンポーネントについてはEJBベースとすることを規定する、ということが考えられます。「多くの銀行では、それに似た方法を採用しています」とGilpinは言います。

上に戻る

永続的な遺産

コンポーネントは、システムを開放化したり柔軟性を高めたりするだけでなく、金融機関が、既存のコードを修正したり置き換えたりしないでレガシー・リソースを活用できるようにします。金融サービス組織の中でも特に銀行は、メインフレーム・コンピューターに大量のレガシー・コードを抱えています。しかし、マーケットの勢いとして、競争力を保つために、新しい、メインフレーム・ベースによらないアプリケーションの開発を求める声が強まりつつあります。レガシー・コードを使用してWebサービスまたはワイヤレス・アプリケーションを開発することは可能ですが、構築済みの機能を含むEJBコンポーネントでレガシー・コードを覆うほうが、はるかに簡単です。たとえば、顧客の口座残高を提供するレガシー・メインフレーム・アプリケーションを使用している銀行は、携帯電話で顧客の口座残高を提供するEJBコンポーネントでそのアプリケーションを覆うことができます。「この種の分散アーキテクチャーは、これらの会社には大変魅力的です。バックエンドの機能を妨げずに済むからです」とStackは言います。

Mickleyは、レガシー・システムは、銀行にとって、コンポーネント・テクノロジーに移行するための良いきっかけになると考えています。「船がこれほど大きいと、舵を切るのが難しく、取り替え費用もかさみます」と彼は言います。「コンポーネント・インターフェースを使用してレガシー・システムの外観を構築することは、大規模な金融機関にとって時間の節約になり、古いシステムへの投資を活用することにもなります。」

参考文献

注目すべき標準は以下のとおりです。

• Simple Object Access Protocol (SOAP)
  
  
• Java 2プラットフォーム・エンタープライズ版 (J2EE)
  
  
• CORBA
  
  
• Interactive Financial Exchange (IFX)
  
  

この記事で触れた下記の会社は、ソフトウェア・コンポーネントの製品とサービス、および調査と助言のサービスを提供しています。

• Flashline
  
  
• Giga Information Group
  
  
• Eontec
  
  
• Gazebo Software Solutions Inc
  
  

その他の関連文献は以下のとおりです。

• Object Management GroupのFinance Domain Task Force から最新の動向を知ることができます。
  
  
• CORBA Webサイトで銀行および金融業界のサクセス・ストーリーを調べてください。
  
  
• IBM WebSphereチュートリアル・シリーズの一部であるEnterprise Java Seriesオンライン・バンク・デモを体験してください。これには、アーキテクチャー、設計、および実装が含まれています。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• 銀行が先導
• なぜコンポーネントなのか?
• COMとEJB
• 永続的な遺産
• 参考文献
• 著者について
• コメント