BPMでシステムインフラを作り変える：特集：企業システムを柔軟に統合する Part.3
システム開発・実行環境だったWebアプリケーションサーバが、BPM機能を取り込んできた。これがどのようなメリットに結び付くのかを押さえよう。
本特集「システムを柔軟に統合する」最終回では、Webアプリケーションサーバ系のBPM製品を取り上げる。というのも、前回紹介したEAI系のBPM製品も、単なる“システム同士をつなぐアダプタ群”ではなく、機能の拡充によりWebアプリケーションサーバの世界に近づきつつあるからだ。このようなBPM製品の方向性が何を目指しているのかを確認するとともに、企業システム構築において、具体的に何が実現できるかを押さえておこう。
なぜWebアプリケーションサーバとの統合が進んでいるのか
もともとWebアプリケーションサーバは、J2EEアプリケーションの開発・実行環境として、開発者の間で注目されてきた。J2EEの特徴は、システム側の処理と業務プロセスを分離した「コンポーネント化」にある。コンポーネントをユーザー要件に合わせて組み合わせることで、ニーズに合致したシステムを手早く構築できるわけだ。ちなみにJ2EEの規格にはメッセージやデータの受け渡し方法も含まれており、アプリケーション同士の連携も容易。また稼働後に何らかの変更が生じた場合でも、該当するコンポーネントのロジックを追加・修正するだけで済むので、大掛かりなシステム変更作業の必要はない。さらにJ2EEアプリケーションは互換性が高いという特徴もある。こうした背景から、ここ数年、新規開発案件でJ2EEの適用が格段に増えてきた。ちなみにSAP R/3など汎用パッケージも数年前よりJ2EE対応を打ち出してきている。
これをさらに敷延させ、企業システム全体を「コンポーネントの組み合わせ」とすることで、システムの柔軟性を高めつつプロセスの最適化を実現する動きが出てきた。企業システムはJ2EEアプリケーションだけでなく、パッケージやメインフレームなどさまざまな環境から成り立っている。こうした異機種環境をWebサービス技術によって連携させる。簡単にいえば、これまで「会計」「人事」「生産管理」「販売管理」とバラバラに存在していた業務アプリケーションを、「会計管理サービスを提供するコンポーネント」「人事管理サービスを提供するコンポーネント」……というように、Webサービス技術を使って各アプリケーションを“サービス”としてディレクトリに登録し、企業のビジネスプロセスにのっとって各サービス間を連携させるというものだ。こうしたシステム・アーキテクチャの考えは「SOA」（Service Oriented Architecture）と呼ばれている。
SOAの特徴はシステム全体を疎結合させるため、ビジネスプロセスの変更に容易に対応できること。またWebサービスという標準技術を用いるので、異機種間の違いを吸収しやすい面もメリットだ。日本IBM ソフトウェア事業部 ビジネスインテグレーション営業部 酒井秀雄部長は「簡単にいえば、既存資産を十分に活用して柔軟なビジネスプロセスを迅速に実現できるということです」という。具体的には、サービス同士をビジネスプロセスにのっとって連携するためのWebサービス規格「BPEL4WS」を用い、サービスを登録しているディレクトリを参照し、必要なサービスを呼び出して連携させるという仕組みだ。
こうした「WebサービスによるSOAの実現」と、「J2EEによる新規アプリケーションや業務ロジックの迅速な開発」を統合し、企業システムの基盤としてしまうのが、Webアプリケーションサーバ系のBPM製品の特徴といえる。酒井部長は、「一枚岩のERPパッケージやメインフレーム上の基幹システムから、最適な個別アプリケーションの組み合わせへ、さらにサービス・コンポーネントを連携させるSOAへと、企業システムのアーキテクチャが進化していく中で、Webアプリケーションサーバと統合ミドルウェア製品が同じ方向へ集約していくのは当然の流れです」と述べる。日本IBMが4月7日に投入する「WebSphere Business Integration Server Foundation 5.1」（WebSphere BI Server Foundation）も、まさにこうした流れを先取りしたものだ。
WebSphere Business Integration Server Foundation5.1（日本IBM）
企業システム全体をSOAに整備し直す
「システム連携」というインフラ技術の観点でいえば、日本IBMは間違いなくこの分野のトップを走ってきたといえる。メッセージ・キューイングシステムの「MQSeries」を皮切りに、ハブ＆スポーク型EAIを実現する「MQSeries Integrator」、ワークフローの流れを統制する「MQ Workflow」など、システム連携・ビジネスプロセスの分野で圧倒的なシェアを誇ってきた。同社はこうしたMQ製品群に加え、汎用パッケージやメインフレームとのアダプタ群や、ビジネスプロセスの設計・実装・監視機能を持つ製品を「WebSphere」ブランドの中で体系化し、「WebSphere Business Integration」製品群として提供してきた。
今回発表するWebSphere BI Server Foundationは、WebSphere Business Integrationの後継製品の“基礎”部分であり、加えて同社のWebアプリケーションサーバ「WebSphere Application Server Enterprise」の後継でもある。製品の位置付けは、表のとおりだ。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
具体的に何ができるかといえば、「MQ Workflowが得意とする人間系処理を含むLong Running Processの実行環境と、WebSphere InterChange Serverが持つシステム間連携などShort Running Process実行環境を併せ持つ次世代のインテグレーション製品です」（酒井部長）という。WebSphere BI Server Foundationは、「WebSphere Application Server 5.1」を実行環境とし、BPELやJ2EEベースで企業内のアプリケーションを構築・配置する。簡単にいえば、WebアプリケーションサーバとBPM製品を1つのプラットフォームとして統合したわけだ。これと併せて、BPELなど標準技術に準拠しシステムを連携・構築する開発環境「WebSphere Application Development Integration Edition 5.1」もリリースされる。
とはいえ、すべてのアプリケーションをJ2EE／Webサービスで連携させるわけではない。従来MQがカバーしていたメッセージ・キューイングのように、大量データを安全かつ高速に連携させる分野もある。例えば金融機関のATMの残高照会や資金移動のように、ある程度決まりきった単純なビジネスプロセスだが、大量のデータを安全に連携するにはMQSeriesのような製品が適しているし、受発注など例外処理が発生する複雑な業務プロセスの連携や、業務手順の変更が予測されるプロセスでは、J2EEやWebサービスなどで連携した方がよい。こうした技術の適材・適所の見極めは、設計の際にIBMおよび同社パートナー企業のコンサルタントがきっちりサポートするという。
製品アーキテクチャは図のとおり。紫の線で囲っている部分が、今回新たにリリースされる製品になる。
酒井部長によると、WebアプリケーションサーバとBPM機能が一体になることで、2つのメリットが生まれるという。1つは、人間系のワークフローもシステムフローも一体化し、同じBPELで実装できる点だ。これまで同社には、「Lotus Notes」なども含めワークフローを制御する製品が20近くあった。これらそれぞれは定義言語が異なるため、企業全体から見たワークフローを統合するにはやはり技術的に困難な面があった。それを標準技術のBPELで統一することにより、システムと人間系処理が統合できるようになるという。
もう1つの特徴としては、補償（コンペンセーション）機能により、アプリケーションサーバではトランザクションを自動的にロールバックできない場合でも、ロールバック的な処理を定義できること。これにより、従来のWebアプリケーションサーバだけでは困難だった受注のキャンセル処理や受注商品の変更処理を、柔軟に定義・実行・管理することが可能になる。
またSOAを実現する方式として、Enterprise Service Busを定義しているが、実装方式は、Webサービス技術や、従来からのメッセージング・キューイングと関連ブローカー製品群を組合せることが可能だ。Enterprise Service Busは図中赤い点線で囲んだ部分。アプリケーションのサービス化やデータ変換などをつかさどる部分だ。
製品機能が拡大されるということは、選ぶ側からすると機能の重複が気になってくる。例えばすでに他社のインテグレーション・サーバやアプリケーションサーバを導入していれば、「大掛かり過ぎる」と本製品を敬遠するユーザーも出てくるだろう。酒井部長はこれに対し、「すでに他社のEAIやBPM製品を導入していてもROIは十分に訴求できます」と断言する。
その理由として挙げられるのは、新しい統合は、既にシステム統合やプロセス統合された部分と共存し、より広範囲に、ビジネスプロセスに即した統合を可能にすることにある。 しかも、特別な統合サーバを独立で用意することなく、新しいアプリケーションを構築するアプリケーションサーバそのもので統合が行えるからだ。
またBPELやJ2EEの標準技術に完全に対応している点。これまでのEAI製品における連携は、結局そのEAI製品個別の要素技術に頼らざるを得ないため、技術者を確保するなど運用負荷が高くなる傾向があった。オープンスタンダードな技術なら、技術者の確保や製品知識の習得が容易になり、運用負荷が削減される。またBPM基盤とアプリケーション実行基盤が統一されているため、信頼性や拡張性、パフォーマンスなどの非機能要件が一定レベルで確保されるというメリットもある。これらはいずれもソフトウェア価格、構築・運用・保守費用など、TCOの改善に大きく貢献する。
ちなみにこうした標準技術に基づく製品戦略は、前回紹介したシービヨンド・テクノロジー・コーポレーションも表明している。こうした他社の動きに対し、酒井部長は「Webアプリケーションサーバとしても、BPM製品としても、これまで圧倒的な実績を誇ってきた2つの機能が組み合わさったことで、さらに相乗効果を生み出すはず」と自信を見せる。
また製品のメリットを最大限に生かすために、IBMではパートナーとともにシステム統合に関するコンサルティングサービスも充実させている。具体的には、（1）ビジネス改革プランニング、（2）ビジネス（業務）プロセス設計、（3）Enterprise Architecture、（4）BPI／EAI構築計画だ。どのコンサルティングについても、基本は「ビジネス戦略を基にプロセスを設計し直し、実装、モニタリングを継続的に続けていく体制をIBMが支援する」というもの。これにより、BPMの効果を拡大させる構えだという。
企業システムのインフラを作り変えるBPM
以上、WebSphere BI Server Foundationを取り上げ、Webアプリケーションサーバ系BPM製品の特徴と具体的な製品概要を見てきた。前回紹介した製品らと細かい技術や得意とする適用分野に違いはあるものの、方向性としては「企業システム全体のアーキテクチャを作り変える」インフラを目指していることが分かる。
いまはまだ、製品のこうした方向性はベンダが提示している理想形に過ぎない。実際には「とにかく異機種システムを連携させなければならないから」という“待ったなし”のニーズからBPMを導入しているケースが大半だ。とはいえ、そこには「堅牢で硬直したITがビジネスの足かせにならないように」という意思決定が必ず存在する。
最後に、そのようなユーザー企業の取り組みを紹介して本シリーズを締めくくりたい。
事例―300社の部品サプライヤと調達システムを連携―
日産自動車は2003年、グローバル規模のシステムインフラとしてビトリア・テクノロジーの「Vitria：BusinessWare」を採用した。導入プロジェクトは北米、北アフリカ、日本で進められており、主に部品サプライヤ側との受発注を円滑にするための基盤として採用されている。今回は国内300社のサプライヤとの受発注をつかさどる部品調達システムを例に、導入ノウハウと効果を検証してみよう。
日産自動車が開発した部品調達システムの機能は主に2つある。1点目は受発注情報の配信だ。納品指示情報は1日当たり約100万件発生する。これを各サプライヤ別にXMLファイルを作り、自動車業界の電子商取引共通基盤「CAI」（Common Application Infrastructure）のデータ交換ボックスに配信する。サプライヤ側はこのデータをダウンロードし、部品を生産、出荷情報を同様の手順で送るわけだ。もう1つの機能は、Webを通じた納期調整のやり取り。Webサーバは10分あたり約500件のアクセスに耐えられるように設計しており、この情報が部品調達システムを経由し、サプライヤのレガシーシステムやCAIの交換ボックスに送信される。
同社がBusinessWareを導入した理由は、大きく分けて3つある。1つはシステム負荷を削減させるという目的だ。従来同社ではサプライヤとのやりとりに専用の調達サーバを利用していた。サプライヤにとってこの調達の仕組みの導入・運用は非常に負荷が高く、「取引先拡大」という同社の方向性に支障を来す恐れがあった。
もう1つは、業界で進められている標準化に対応させるというもの。自動車業界では受発注取引に際し、EDI標準が進められており、システムを規格に準拠させる必要があった。さらに自動車工業会と自動車部品工業会と共同で、物流業務の効率化やコスト削減などを狙って標準帳票のガイドラインを作成するなど、標準化の動きが活発化している。これにいち早く対応するために、選んだのがBusinessWareだった。
最後に、サプライヤ300社それぞれ異なるシステム環境に合わせ、情報を統合しなければならなかったこと。これを手組みで開発していたら、工数もコストも膨大なものになる。同時に、後々の運用負荷も効率化する必要があった。
- 自動車業界のEDI標準に対応
- 自動車業界の帳票標準に対応
- サプライヤのシステム運用負荷を軽減
- ビジネスプロセスの効率化
システムの基本構想に着手したのは2002年6月ごろ。同年12月には基本設計を開始し、外部設計・内部設計フェイズを経て、実際に開発・テストを行ったのが2003年3月〜5月にかけてだ。6月に総合テストを実施し、7月に実際の業務に適用、300社のサプライヤと順次接続を始めた。
開発に際して最も留意したのが、データ更新時間を保証すること。国内各拠点からほぼ同時に発生する指示・内示情報をEDIFACT変換し、自動車業界の電子商取引共通基盤「CAI」（Common Application Infrastructure）のデータ交換ボックスに送らなくてはならない。従来は3拠点ごとに調達用サーバを1台立て、約1時間で処理していたという。これと同様のパフォーマンスを保ちつつBusinessWareに集約する必要があった。テストを実施した結果、サーバのチューニングとオブジェクト構成を見直すことでパフォーマンスを維持。システムの品質についてもコーディングミスはなく、順調に稼働しているという。
導入効果としては、早くも受発注業務に関して改善がみられているという。従来は納品や受領に関して、ラベルを専用リーダーで読み込ませ、プリントアウトする必要があった。これをすべて画面上で行うことで、飛躍的に業務効率が上がったとのことだ。
Copyright © ITmedia, Inc. All Rights Reserved.