【解説】
SOAのメリットを最大限に引き出す「5つの方法」

United Airlines、Comcastなど先進ユーザーに学ぶ

（2008年03月18日）

CASE STUDY 4
Thomson Financial　http://www.thomsonfinancial.com/
コンプライアンス評価の自動化で大幅な業務効率化を実現

　多くの企業でSOAのコンセプトが好まれるのは、開発の迅速化が期待できるからだ。しかし一部のSOA開発者は、サービス・ガバナンスの重要な部分が開発を遅延させることに気づいている。金融情報サービスのThomson Financialは、SOA開発の初めの段階からこうした好ましからざる事態に直面していた。

　同社のコアサービス製品管理担当バイスプレジデント、ウラジミール・ミテフスキー（Vladimir Mitevski）氏は、「エンタープライズ・レベルの資産であるなら、サービスは一定の方法論とポリシーに準拠していなければならない」と指摘する。

　そうした方法論やポリシーは厳格なものが多い。例えば、XMLエレメントのネーミングは省略形ではなく正しい単語を用いなければならない、あるいはユーザー名やパスワードなど一部のアイテムはハードコード化してはならない、などだ。サービスの数が少ないときは、エンタープライズ・アーキテクチャ（EA）の評価担当チームも問題を把握し、正しくチェックすることができるだろう。しかし、すぐに評価ポイントでボトルネックが生じ、作業負荷が高まって、さまざまな問題が見過ごされることになる。

　Thomson Financialは、洗練されたものから荒削りのものまで、膨大な数のサービスを少人数のアーキテクチャ担当スタッフでカバーしている。そのため問題はすぐに浮上した。「洗練度とは無関係に、あらゆるサービスが評価プロセスを経る。サービス・レジストリに登録されるのはその後だ。変更されたサービスも新バージョンとして登録、利用される前に、コンプライアンス評価を受けなければならない。しかしアーキテクチャ担当チームの処理能力には限界があり、そこがボトルネックになった」とMitevski氏。

　シングル・サインオン・サービスや、金融マーケット情報をアナリスト、トレーダーに提供するWebサービス、Microsoft OfficeからアクセスできるWebベースの金融分析、チャート・サービスなど、アプリケーションの重要性を考えれば、コンプライアンスの要求を緩和することはできない。

　コンプライアンスの負荷に対するThomson Financialのソリューションは、WebLayersのポリシー評価ツール「WebLayers Policy Manager」を用いた自動化だった。「このツールは効率的で、違反を決して見逃さない」とMitevski氏は高く評価する。ツールがコンプライアンス違反の判断に必要とするポリシーの作成には多少時間がかかったものの、開発者がポリシーを理解していないと思われるような点はないか、あるいはアーキテクチャそのものにあいまいな部分はないかを評価チームがチェックするにあたって、このツールの分析機能はなくてはならないものとなった。「Policy Managerは何をどうすればよくなるのか、ポリシーのどの部分を修正すればよいかも示してくれる」（Mitevski氏）

　このツールで明らかになったことは、ほとんどの違反が開発者の手抜きに起因するものだったことだ。そこでThomson Financialのアーキテクチャ・チームは、（ほとんどないことだが）開発者にコンプライアンス違反の例外を許容するときは、レジストリにその旨を提示し、他のユーザーに周知することにしている。

　Thomson Financialにとって、サービスのコンプライアンス評価を自動化した効果は劇的だった。「それまで、サービスを評価するプロセスのためには、さまざまなグループにまたがる高度に組織化された20人ほどのスタッフが必要だった。ツール導入後は、たった1人のスタッフですべてまかなえるようになった」とMitevski氏は語る。

CASE STUDY 5
Jabil Circuit　http://www.jabil.com/
SOAアプローチで顧客統合機能の簡素化に成功

　製造サービスに特化した会社であれば、請求業務システムや需要予測システム、顧客側のシステムに柔軟に対応できる受注システムなど、幅広い顧客統合機能を提供するシステムを構築する必要がある。しかし顧客ベースが拡大し、自社システムが肥大化するに従い、それらのポイント・ツー・ポイント・コミュニケーションを効率的に管理することは非常に難しくなる。多くのメーカーがサードパーティ・プロバイダーのVAN（Value-Added Networks：付加価値ネットワーク）に移行する理由はそこにある。サプライヤーと顧客はそれぞれVANにアクセスするための1本の接続があればよいからだ。

画面3：電子機器受託メーカーJabil CircuitのWebサイト。同社はSOAのアプローチを用いて、複雑な対応が求められる一部パートナーとのカスタム接続を再利用が可能なサーバ・ベースの接続にリプレースし、コスト削減を図っている

　だがこのアプローチは、顧客をサポートするための固有のプロセスにVAN側が対応できないときは成立しない。そこで、電子機器受託メーカーのJabil Circuitは、このジレンマに対処すべく、すべてのカスタム・アプリケーションとインタフェースをマニュアルで保守していた。Jabilは5,000社を超えるパートナーを抱えているが、大多数はVANによってカバーできる。しかし、そのうちの50社は、Sterling Commerceが提供するVANサービスの特殊な通信メカニズムを必要とした。Jabilのeコマース担当マネジャー、ローウェル・ギルビン（Lowel Gilvin）氏によると、こうしたカスタム接続は顧客によっていくつか用意する必要があり、複雑な対応が要求されたという。そうした状況から脱却するため、JabilはSOAのアプローチを用いて、カスタム接続のほとんどを再利用が可能なサーバ・ベースの接続にリプレースした。

　最初のステップは、通信プロセスから受注管理、需要予測、在庫受託などのビジネス・プロセスを分離することだった。Jabilは現在、AS1（Applicability Statement 1）、AS2（Applicability Statement 2）、FTPなど、現行のほとんどの通信メカニズム用に標準サービスを提供しており、XML、フラットファイル、Excel、SAP iDocsの各フォーマットをサポートする個別のデータ処理サービスも用意している。

　また、Jabilでは、顧客ごとに適切な通信サービス、データ処理サービス、ビジネス・サービスを組み合わせて提供しているが、それらの組み合わせはほとんどの場合、テーブルとメタデータを使って自動的に行われる。顧客側で部門ごとに異なる通信メカニズムを利用している場合もあるが、Gilvin氏によると、テーブルは複数のメカニズムにも対応できるようになっているという。

　SOAコンセプトのアブストラクション、モジュール方式、サービス構築は、通常問題なく機能する。ときには特殊な要求に対応できないこともあるが、そのようなケースでは個別にサービスを組み合わせている。しかし、そのようなケースでも、Jabilは統合化の一部にSOAアプローチを用いることが多いという。例えば、XMLやSSLの認証は標準サービスでは処理できないが、Jabilでは適切な通信とビジネス・サービスをハードワイヤード方式のデータ処理サービスと組み合わせて対処しているという。

　「そうした統合プロセスの一部において、SOAの再利用性や一貫性といった利点を活用している」とGilvin氏。

　Jabilでは、ESBでメッセージングを管理したり、レジストリでサービス・リポジトリを管理したりすることはしていない。また、サービスの開発にSOAのような開発環境を利用することもない。それらはすべて、Sterling Commerceの統合プラットフォーム「Gentran Integration Suite」を利用して行っている。このツール・セットはサプライチェーンをサポートするために設計されたもので、Jabilのニーズをほぼ完全にカバーしている。同ツール・セットについてはGilvin氏も、「われわれは標準ビジネス・プロセスの小さなセットを持つだけでよい」と満足げだ。

（月刊Computerworld 2008年5月号に掲載）

前のページへ < ｜1｜2｜3｜