ガートナーの調査によれば、2007年に構築されたミッション・クリティカルなITシステムの半分以上は、「サービス指向アーキテクチャー」（SOA）によるものだという。この話を聞いて、新手のIT投資物件の登場かといぶかる向きもあろうが、SOAが登場してきた背景、その目的と期待される効果について理解すれば、そのような疑いも解けるはずである。

かつて一世を風靡したリエンジニアリングは、自社固有のビジネスプロセスをカスタマイズすることで、効率性と生産性の向上を目指すものだったが、SOAは、ビジネスプロセスの目的や成果、代替サービスや外部化の可能性に注目し、重複の解消と部門横断的な共有、標準化されたプラグ・アンド・プレーによって、21世紀の事業環境にふさわしいビジネスプロセスの構築を目指す。

本稿では、保険会社のハーバード・ピルグリムなどのケースを通じて、SOAのポテンシャルとその導入方法について検討する。

課題はプロセスからアクティビティに移行

　リエンジニアリングへの取り組みが始まって、かれこれ20年が経つ。分散していた多くの作業やデータを統合し、部門横断的なビジネスプロセスを築き上げることで、コスト削減、サイクルタイムの短縮、サービスの改善など、それなりの効果は上がっている。その一方で、リエンジニアリングを導入した企業の多くがいま、壁にぶつかっている。

リック・メリフィールド
Ric Merrifield
マイクロソフトのディレクター。ビジネス・アーキテクチャー事業のリーダーの一人。

ジャック・カルフーン
Jack Calhoun
マサチューセッツ州ランドルフのコンサルティング会社、アクセレアのCEO。

デニス・スティーブンス
Dennis Stevens
ジョージア州ノークロスのコンサルティング会社、シナプタスのCEO。

　ただし幸いにも、その壁を乗り越える方法が登場している。インターネットを介してさまざまな機能を使ったり、共有したりできる新技術が開発されたおかげで、取り組むべき課題はもはやプロセスではなくなりつつある。

　取り組むべきは、プロセスを構成する、たとえば製品の価格設定、請求書の発行、顧客別のリスク評価、開発中の新製品で優先すべき性能や特徴の決定など、事業にまつわるアクティビティになっている。

　これらアクティビティを、〈レゴ〉のようにくっつけたり、外したりできるソフトウエア・コンポーネント（ある仕様に従って書かれたオブジェクト）として、設計できるようになった。これに大きく貢献しているのが「サービス指向アーキテクチャー」（SOA）である。

　これは比較的新しい方法で、アクティビティをサポートするソフトウエアを設計して展開する。SOAの強みは、ユビキタス化しつつあるインターネットを標準化された方法によって利用し、単一のアクティビティ、あるいは複数のアクティビティからなるプロセスにアクセスできることである。

　そのアクティビティを実行するためのケイパビリティが手作業であれ、完全に自動化されたものであれ、あるいはその両方であれ、その土台となるソフトウエアやユーザー・インターフェースをSOAによって設計することで、そのアクティビティを事実上、ウェブ・サービスへと転換できる。

　その結果、個々のアクティビティやプロセスを社内で共有したり、その実行をサプライヤーや顧客に委ねたり、あるいは他社に売買したり、さらにはITシステムの更新やメインテナンスなどもきわめて容易になる。

　とはいえ、このような方法にSOAを使うに当たって、やはりボトルネックが存在する。その1つは世界標準がないことである。ベンダーや業界が現在使っているSOAのバージョンはバラバラである。

　しかし、これはさしたる問題ではない。というのも、バージョンが違っていても、ほとんどのアクティビティをシステム間でやり取りできるからだ。さらに言えば、現状を判断する限り、SOAの標準は早晩統一され、専門家たちで構成された運営組織によって監督されることになるだろう。