ブロードバンド音声・データ通信を手掛けるコバッド・コミュニケーションズ・グループにとって、サービス指向アーキテクチャ（SOA）への移行は自然な進化だった。

　DSL、VoIP、Webホスティング、マネージドセキュリティ、ダイヤルアップといったサービスを提供するコバッドは、1997年にEnterprise Java Beans（EJB）をいち早く採用した。そのおかげでコバッドのソフト開発者は、約60に上る社内アプリケーションを次々と作り出すことができた。これらのアプリケーションは在庫管理、顧客関係管理（CRM）、顧客注文処理など、さまざまなビジネスプロセスをサポートした。

　EJBアーキテクチャは、企業が個々のマシンを更新するのではなく、サーバレベルで変更を管理するのを支援するように設計されている。だが、EJB環境の複雑さが増大し、コバッドのITエンジニアがその管理に費やす時間がいつの間にか増えていった。そこでソフト・情報システム担当副社長のポール・グランサム氏は、SOAの検討に乗り出した。

　「問題は、こうしたEJBアプリケーションがややこしく複雑に接続されていて、その環境の管理や変更が非常に困難になっていたことだった」とグランサム氏。「より柔軟に変更を行えるようにするという明確な目的のために、われわれはSOAへの移行を決めた」

　具体的には、コバッドはアプリケーションをサービスとして社内に提供し、個々の部門がそれらを分解して組み合わせることで、ビジネスプロセスを構築できるようにすることを目指した。

　そのためには、変更が加えられたコンポーネントがすべてのマシンで迅速に利用でき、ネットワークパフォーマンスの低下を回避できる分散コンピューティング環境が必要だった。

　コバッドがアーキテクチャの移行に着手してすぐに明らかになったのは、あつらえ向きのSOAプラットフォームは市場に存在しないことだった。グランサム氏のITチームは既にBEAシステムズのソフトパッケージ「WebLogic Integration」を使っていたが、それがコバッドが必要としていた機能に最も近いものを提供する製品だった。

　それでも、コバッドのJavaエンジニアは結局、SOAの実装基盤となるエンタープライズサービスバス（ESB）の一部として、多数のミドルウェアアプリケーションを作成する羽目になった。アダプタからアプリケーションまで、セキュリティを管理するものは、すべて用意しなければならなかった。

　「われわれはミドルウェアの部類に入ると思われるものを作成した。それはわたしの望むところではない。ミドルウェアの開発はわれわれの仕事の本分ではないからだ」とグランサム氏は振り返る。「だが残念ながら、われわれは必要なものをすべて購入することはできなかった」

　さらに同氏はこう付け加える。「一番がっかりしたのは、ベンダーの商用製品でSOAが十分にサポートされていないことだ。IBMやサンマイクロシステムズはこの1年にSOAサポートプログラムを発表しているのに」

　オラクルも最近、「Fusion」ラインのミドルウェア製品の幾つかを「Oracle SOA Suite」としてセットで提供すると発表している。

苦労に見合う効果

　グランサム氏は苦労したものの、ポイントツーポイント接続に見切りをつけてSOAを採用したことを後悔していない。コバッドは2004年にSOAの運用を開始し、それ以来、SOAを利用して新しい在庫管理システム、シーベルの注文管理システム、オラクルフレームワークを採用したCRMシステム、新しい請求システムを導入展開してきた。

　「SOAを活用してこれだけの成果を上げた企業はあまり多くない。自画自賛になるが、われわれのSOAアプローチのおかげだと考えている」とグランサム氏は語る。

　SOAをいち早く推進してきた企業は、常に変化する膨大な情報を社内のシステム間などで共有する必要がある企業、とりわけ金融サービス会社やコバッドのような通信会社が多い。しかし、SOAは戦略であり、導入しても明確な効果が必ずしもすぐに出るとは限らない。

　「多くのIT組織はSOAの導入に熱心だ。彼らは2つの異なるシステムが同じ機能を果たしていると、それらのシステムを共有サービスとして統合しようとする。問題は、IT組織がSOAのビジネス効果をユーザーにうまく明示できていない場合が多いことだ」と調査会社ガートナーの副社長ダン・ショラー氏は語る。

　さらに、ショラー氏はこう指摘する。「SOAは、ITアーキテクチャの構築方法に、クライアント／サーバが考案されて以来の最も重要な変化をもたらすものだ。ただ、SOAの構築に関しては、まだ模索中の部分も多い。このアーキテクチャに基づくシステムは既存システムと比べて、求められるものが格段に高度になっているからだ」

　はっきりしているのは、SOAの構築に関連して追加コストが掛かることだと、ザップシンクのアナリスト、ジェーソン・ブルームバーグ氏は語る。共有サービス・コンポーネントは一般に、Webサービスの利用による相互運用性の向上を活用するために、XMLをベースに開発される。ブルームバーグ氏は、SOAの導入を考えている企業は、ハードウェア費用と人件費の両方の増加に備えるべきだと語る。

　「XMLは冗長なため、ネットワークの負担を増やしてしまい、その適切な運用のためにはハードとソフトを追加する必要がある。また、共有サービスは担当者が管理する必要があり、そのためには新しい組織体制を整えなければならない。もちろん、これもコストアップにつながる可能性がある」（ブルームバーグ氏）

ROIをどう設定するか

　SOAの有望性は、企業が統合コストを削減したり、共有サービスを用いて優良顧客の情報を一元的に管理するのに利用できることにあると、ブルームバーグ氏は語る。さらに、サーベンス・オクスリー法（SOX法）などの厳しい規制に対応しなければならない企業のCEOにとっては、SOAにより、システムやアプリケーションがどのように組み合わされているかが把握できるようになり、監査可能なビジネスプロセスに必要な可視性が得られることもメリットだ。

　「実のところ、SOAはこうしたIT課題の多くを解決するための唯一のアプローチだ。肝心なのは、『いつ』『どのように』SOAを導入するかだ」とブルームバーグ氏は語る。

　コバッドのグランサム氏はSOAを導入するにあたって、経営陣にSOAインフラの技術的優位性を売り込もうとはしなかった。そうする代わりに、同氏は具体的な効果に焦点を絞り、共有サービスベースのアーキテクチャによっていかに在庫管理業務を円滑化したり、注文処理、在庫管理、CRM、請求といったさまざまな機能を統合したりできるかを訴えた。

　「われわれは経営陣に、アーキテクチャではなくビジネスメリットを売り込んだ」（グランサム氏）

　SOAの導入規模が十分に拡大するまでは、ROI（投資対効果）に関する議論はあまり意味をなさないだろうとガートナーのショラー氏は語る。それでも、企業はいかにコストを削減するかではなく、営業の強化や顧客ロイヤリティーの向上、自社の効率化にSOAをいかに活用するかに重点を置くべきだ、と同氏は指摘している。

　「SOAが解決しようとしているのは、どうすればIT予算を数パーセント削減できるか、といった問題ではない」と同氏。「ビジネスの世界の変化に応じて迅速に変更できるITシステムを、いかに構築できるかという問題だ」

（この記事は2006年1月18日に掲載されたものを翻訳しました。）