Shoeisha Technology Media

EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

SOAへのアプローチ~ビジネスサービスとエンティティサービス

  2007/07/30 10:30

 一時のSOAへの熱狂や高い期待の時期は過ぎ去りましたが、SOAは幻想だったのでしょうか? ビジネスとITという非常に大きな文脈の中で語られることが多いだけに、どこから手をつけてよいか難しく、導入を躊躇するケースも見られます。 

 この連載では、SOAをとりまく環境から、SOAの現状と課題を整理し、導入を進めるにあたっての考慮点を紹介します。1回目の今回は、SOAの主要な構成部品であるサービスの種類とその整備の進め方について検討します。

動き出したSOA

 「SOA」がキーワードとしてIT業界で最も話題になったのは2002、3年頃のことだったでしょうか? 90年代後半にXMLが、2000年頃にはWebサービスが大きな話題となり、これに続くように、SOAとは何か? という議論が広く行われ、盛んに書籍の出版やセミナーの開催が行われました。SOAという概念が生まれたのはさらに時代をさかのぼりますが、IT業界におけるマーケティングキーワードとしても広く利用され、さまざまな製品がSOA対応として発表されたこの頃がSOAブームであったといってよいでしょう。

 一方、この1、2年を振り返ってみると、SOAということばが上述のSOAブームの時期ほどは話題にならなくなってきたように感じられます。これはどういうことでしょうか? SOAはすでに過去のものになってしまったのでしょうか? それともすでに当たり前のものとなり、議論の対象から外れてしまったのでしょうか?

 筆者が想像するに、次のように考えている企業の情報システム担当者が多いのではないでしょうか。

  • SOAのメリットについては勉強したし、十分理解した。だが、自社にどのように適用していけばよいのだろうか?
  • SOA対応を謳った製品は多数発表されているが、自社の問題は単にソフトを導入すれば解決するほど単純ではない。
  • SOAは技術ではなく、考え方であって、ビジネスとITの橋渡しをするものといわれているけれど、全社的にこのような考え方を推進している部署は存在しないし、情報システム部も既存のシステムのメンテナンスで精一杯。情報システムの企画や開発は事業部ごとにおこなわれていて、全社レベルでのサービスによるビジネスプロセスの実現を推進するのは難しい。
  • 全社システムを企画、検討する部署においても、SOAの方向性については理解を示しているものの全面的な採用を進めるには、まだリスクが大きいように感じられる。

 このような悩みはSOAの導入を真剣に検討しているからこそ出てくるものであり、もし上記の推測が正しいものであれば、SOAはすでに製品ベンダーだけのキーワードではなく、現場への導入へ向けて動き出しつつあると言ってもよいでしょう。また、筆者の関連している案件や雑誌記事等の動向を見ても、必ずしも5年前に期待したような速度ではないですが、SOA導入に向けて動き始めた企業も少なくないようです。

 この連載では、複数の企業や部署にまたがる多数の関係者を巻き込み、かつ、さまざまな技術要素も関係するSOAを、企業のビジネスに直結した情報システムのアーキテクチャとして導入していくにあたって課題となるポイントを順次取り上げて、その対応策を検討していきたいと思います。

 1回目の今回は、SOAで実現するシナリオとしてしばしば取り上げられるサービス連携によるビジネスプロセスの実現に必要なビジネスサービスの整備と、SOAの導入段階で特に有効と考えられるデータ連携のためのエンティティサービスの整備を、筆者が「仕事の流れで理解する 実践!SOAモデリング」(翔泳社)で紹介したサービスモデルの観点から考えます。

ビジネスプロセス実現のためのビジネスサービスの整備

 SOAは、企業のビジネスとITのギャップを埋め、企業のビジネスプロセスを情報システムで実現するための考え方であると紹介されることが多いため、SOAの導入にあたっては、企業のビジネスプロセスの自動化およびその管理、改善という観点から進められることが多いようです。SOAが話題になった当初にはBPEL4WS(現在はWS-BPELとしてOASISで標準化中)というビジネスプロセス記述言語がIBM、Microsoftなどから発表され、注目を集めました。当時は、BPELによってWebサービスを連携させ、ビジネスプロセスを自動化することがSOAを実現することとほぼ同義であるとであるとみなされたような時期でした。

 また、Enterprise Architecture(EA)を整備し、これを実現するための情報システムのアーキテクチャとしてSOAの導入を検討することもあります。EAでは、ビジネスアーキテクチャ(BA)、データアーキテクチャ(DA)、アプリケーションアーキテクチャ(AA)、テクニカルアーキテクチャ(TA)の4階層で、企業のビジネスおよび情報システムを整理します。BAでは、社内外の関係者による業務の流れであるビジネスプロセスをそのアーキテクチャの一部として取り扱い、モデリングを行うことから、BAの整備をSOAの出発点とすることもできます。上述の「仕事の流れで理解する 実践!SOAモデリング」では、BAからサービスを発見する手法について紹介しています。

 ビジネスプロセスを実現するために識別されたサービス群は、これを組み替え、置き換えることでビジネスプロセスの処理の流れの変更や、ある処理をアウトソースすると行った業務の変更に対して柔軟に対応可能となることから、SOAを実現するためのサービスの中でも特に重要な構成部品となります。このようにビジネスプロセスから直接呼び出されるサービスを、「ビジネスサービス」と呼びます。

 企業においてSOAの適用範囲を広げ、ビジネスの変化に柔軟に対応するITを実現するためにはビジネスサービスの整備が不可欠です。ところで、新しく起業する場合を除いて、すでに企業は多数の業務システムを抱えています。ビジネスサービスの実現を考えたときに、すべてを一から作り直すことは現実的ではありません。既存のシステムをできる限り利用し、これらを新しいシステムアーキテクチャの上で、価値を高めていくことが重要だといえるでしょう。

※この続きは、会員の方のみお読みいただけます(登録無料)。


※この続きは、会員の方のみお読みいただけます(登録無料)。


著者プロフィール

  • 大場 克哉(オオバ カツヤ)

    (株)オージス総研技術部勤務。90年代からオージス総研にて、オブジェクト指向分析・設計、ミドルウェアに関するコンサルティングに従事。2000年から、シリコンバレーを拠点として現地のエンジニアと共に、Webサービス、SOAに関するツール開発、方法論開発を行う。現在は、ふたたびオージス総研にて複数のSO...

All contents copyright © 2007-2019 Shoeisha Co., Ltd. All rights reserved. ver.1.5