銀行システムにおけるSOAの考え方

掲載月：2006年3月

金融機関システムのアーキテクチャーの特徴は、まず1980年代中頃から基幹系にてIMS™を中心としたデータ・システム環境(DSE：Data Systems Environment)を用いた第3次オンラインをスクラッチ・アンド・ビルドし、90年代後半からは変化への対応としてハブ・アンド・スポーク・アーキテクチャーを検討、実装してきたこと。そして分散環境を多数取り込んだ現在でもある程度一貫した設計思想が保たれていることです。
社会生活のインフラとして、長い年月にわたって堅牢性と、時代の変化への素早い対応を求められる、複雑にして大規模な金融機関の情報システムには、全社的、かつ長期的な視野でのガバナンスで全体最適を目指すEA(Enterprise Architecture)的なアーキテクチャーの考え方が求められます。
その一方で、昨今の激動する経営環境の中では、部分最適であっても即応性やROIの最大化を目指すオンデマンド化を同時に進めていかなければなりません。
アーキテクチャー視点で極端には混乱しているわけではない金融機関のシステム・アーキテクチャーは今後、どのように変化していけばよいのでしょうか。
そもそも、ビジネス変化の激しいオンデマンド時代にあって、90年代にほぼ確立したEAそのものを変化させないでもよいのでしょうか。

変化にオンデマンドに対応していくことが求められるいま、即応性、柔軟性をアーキテクチャー面で支える重要な要素はSOA(Service Oriented Architecture)であるといわれています。
いままで柔軟性実現の主役と考えられていたEAI(Enterprise Application Integration)のアーキテクチャーであるハブ・アンド・スポークは、主としてMQ(MessageQueuing)などのメッセージ伝送用APIによる独自の仮想化でした。
それに比べ、SOAはオープン技術で標準化されています。コンポーネント化された「サービス」という「業務機能の仮想化」と「それらを多段につなげるワークフロー」を含み、その徹底した再利用によりビジネスの優先度の変化に迅速に対応可能なプロセスとIT基盤の柔軟性を実現するアーキテクチャーであると位置付けることができます。

EAとSOAの共通点(活用可能なEAの機能)
SOAを推進するには全組織体のアーキテクチャーをガバナンスするEAと共通した下記のポイントが存在します。

• 全組織体のIT戦略を具現化する手段である
• EAもSOAも一気には達成できないため、長期のアーキテクチャー計画が必要である
• ITの方向性を決定するアーキテクチャー・ボード(会議体)などの組織が必要である
• 多くのステークホルダーの利害が関係するさまざまな組織の壁を越える必要がある
• 継続してアーキテクチャーやサービス部品を蓄積し、効果を測定し改善を継続する必要がある

従来のEA機能の適用で、シームレスにオンデマンドのアーキテクチャーとしてのSOAを取り込むことができますが、次章のように大きく異なる点も存在します。

EAとSOAの相違点(SOAの導入で新たに必要な視点)
オンデマンドのビジネス特性で見た相違は下記のとおりです。

即応性

• SOAは素早い変革を目的としており、部分最適、ROI重視の傾向があるため、全社最適とは限らない
• スクラッチ・アンド・ビルドでのサービス発見も重要だが、即応性を求める実践面では既存の膨大なIT資産から再利用可能なサービスを特定する新たな作業が必要

柔軟性

• 再利用されない機能のオンデマンド化やサービス化は意味がないため、SOAは全システムに強制的に適用すべきではない
• より広い組織間、ステークホルダー間でサービスを共同利用する必要があり、初期投資や利用コスト負担、機能要件と非機能要件(品質要件、SLA: Service Level Agreement)の利害関係の調整、再利用による効果の数値化がより大きな課題となり得る

集中化

• 集中化に伴うアウトソーシングや機能・サービスのダイナミックな調達先変更など、自組織のガバナンス・スコープ外である外部の企業や組織、顧客との柔軟な連携(B2B、B2C)も視野に入っている

回復性

• ひとつのサービスが複数のサービスの組み合わせ(ワークフローを含む)で多段階に構成され管理の視点が分散されるため、従来の3層構造などより複雑なアーキテクチャー管理、サービス・レベル管理、障害対策が必要

このように、SOAは従来の「穏やかな」EAではカバーしきれなかった面を持ち合わせていることがわかります。

図1 DSEとSOA
アーキテクチャーとしてのSOAの効用
SOAはいろいろな効果が喧伝されていますが、根本はサービスという業務的なインターフェースで抽象化された部品をビジネス・プロセスの視点から多段階に徹底再利用すること(複数サービスの組み合わせもまた1サービスとして扱えること)に、変化への柔軟性という本質的な価値があると考えられます。
そして今後特に焦点を当てるべきは「再利用されるサービスの特定」と考えられます。なぜなら金融機関システムでは再利用の主要な対象は基幹系である可能性が大きく、すぐにでも更改したいインターネット系のフロントエンド・システムがすでに複数存在している可能性が非常に高いからです。
すでにEAIとしてのハブが存在する場合は、そのアーキテクチャー体系や利用中のアプリケーションに影響を与えてまでSOA化をする必要はありません。
ハブ自身をサービスの提供者(プロバイダー)と見て、必要な機能を必要な都度サービス化するアーキテクチャーが構築できます［図1］。

図2 連携図
サービスはさまざまな粒度で定義可能ですが、ハブをすでに利用している多くの業務へのリスクとコストを配慮すべきです。
そしてハブ経由で提供できる機能をサービスに見立てるコンポーネントを経由しESB(Enterprise Service Bus)と連携させ、プロセス連携を戦略サービスと位置付けるべきでしょう［図2］。

適用例
サービスの抽出メソドロジーとしては、すでにIBMではSOMA(Service Oriented Model and Architecture)を世界中で活用しています。またベストプラクティス手法である「ユースケースを保ったままで、サービス化を仮に試みることで、サービス候補を抽出し、未来への価値を与えていく」ボトムアップ手法も試みられています。
銀行業務で抽出されたサービスの一例を示します。

• 業務サービス候補
  残高照会、取引明細照会、振込・振替、取引履歴照会、利用料明細照会、顧客属性照会 など
• 共通サービス候補
  共通認証、セッション制限、取引制限、統一エラーメッセージ、統一電文・コード変換、FTP機能、PDF文書作成機能、取引ログ出力 など

オンデマンド化推進に焦点を当て、今後のEAには「再利用されるサービスの特定」の対策が必要であることを述べましたが、他のEA要素である、ガバナンスやトランジション計画での検討も必要となります。EAの構造に沿ってオンデマンド時代の金融機関システムが新たに備えるべき10の提言を示します。

提言1
SOA導入のためのビジネス・ドライバーを明確にすべき
何を目的にオンデマンド化やSOA化するかを明確にし、その効果予測や測定のためのKPI(Key Performance Indicator)を明確にしておくこと。

提言2
ビジネス要素(コンポーネント)も1サービス要素となると意識すべき
ビジネス要素の外部委託や、少量多種サービスへの対応のため、既存のビジネス要素を組み合わせる考え方がいままで以上に重要。

提言3
既存のハブ以下の既存業務を可能な限り再利用すべき
サービス化は再利用時の複雑性を極力取り除く手段と考える。

提言4
実現可能なテクノロジーをサーベイし続けるべき
SOAはアーキテクチャーであり、製品や実装と混同すべきでないし、論理的なコンポーネントと物理的な配置を混同すべきでない。論理的疎結合、物理的集約を目指すべき。

提言5
サービスのレイヤー、タイプ、粒度、サービス間の関係のルールを明確化すべき
細かな粒度にすると再利用性は高まるが、定義、導入、保守のコストだけでなく多階層のための処理コスト、障害のための対策コストが増大。

提言6
トランザクション・オーナー、ビジネス・ロジック・オーナーの指針を明確化すべき
ビジネス・ロジックの分散による複雑さの増大、トランザクション失敗時の補償取引の考え方、チューニングや障害分析の困難さなどを十分考慮したデザイン・ガイドを示す必要がある。

提言7
サービス・レジストリーを構築し公開すべき
再利用が最も重要な戦略であり、再利用するためにはサービスを公開する必要がある。再利用の成果(再利用回数、省コストや品質向上への貢献度)も収集し公開する必要がある。

提言8
サービス・アーキテクチャー委員会の設立とSOA要員育成を行うべき
SOA化の大きな課題となりつつある初期段階の基盤の投資負担分担ルール、オンデマンド視点での組織間の利害調整、サービス定義間の機能やバージョン調整、サービス再利用の効果把握、新たなガバナンス対象の発見と制御などのために、アーキテクチャー委員会設立が重要。

提言9
異なる組織体のEA同士の関係を調整すべき
同じ組織内でも、本社と複数の海外支社など、現場の法制度や技術調達環境に即したEAガバナンス(EAフェデレーション)を必要とするケースがある。
サービスを外部に提供し、また外部サービスをダイナミックに使用するオンデマンドでは、自組織のガバナンスではアーキテクチャーやSLAなどの細部を統制できないケースも多くなる。
どこまでを全体で統制し、どこからは自治に任せるのか、について自治権を持つアーキテクチャー委員会同士で調整し合うことが必要である。

提言10
金融機関システムのハブ構築と同様に、ビジネスにとって重要な意味のあるプロジェクトから手掛けるべき
まずは、パイロット業務から手掛け、徐々にナレッジとサービスを蓄積していく必要がある。しかし、機能範囲が小さく限定された非基幹系のシステムを連携しても再利用の検証の意味は少ない。ビジネス価値を主張できるプロジェクトから手掛けるべきである。