ページの先頭です。
サイト内の現在位置を表示しています。
  1. ホーム
  2. ソリューション・サービス
  3. SOA
  4. コラム
  5. 第3回 SOAシステム/BPMシステムのSI現場
ここから本文です。

【コラム】 第3回 SOAシステム/BPMシステムのSI現場

NECソフトウェア九州 岡木

NECソフトウェア九州
ソリューション基盤事業部
シニアマネージャ
岡木 孝浩

1.はじめに

はじめてのSOA

2003年春に構築したB2B購買ASPサービスのシステムが最初に私が構築したSOAのシステムでした。

この頃はまだ世の中でSOAという言葉が一般化する前で、特にSOAという言葉を意識して設計した訳ではなく、柔軟性・拡張性を考えて設計したら結果的にサービス指向になっていました。

当時はNEC内でもSOAの事例が殆どなかったため、SOA構築事例ということで何度か社内外への紹介もしましたが、いま思えばSOA事例として紹介させて頂くには設計思想も自分自身の知識も不十分で、反省すべきところが多々あります。

設計思想が左右するシステムの行方

それから約6年、SOAシステムやBPMシステムをいくつか構築してきましたが、いずれも「このように構築しなければならない」という正解はなく、お客様のニーズにあった形で構築し、それをお客様のニーズの変化に応じて成長させていくことのできる構築手法だと感じています。だからこそ、構築する上での思想は開発プロジェクトメンバ全員が常にそれを意識しておく必要があります。それを怠ると、SOAPとWSDLを採用しただけで他は従来と何ら変わらない、機能同士が密結合した変化に弱いシステムが出来上がってしまう危険性があります。

完全なスクラッチでSOAシステムやBPMシステムを開発することも可能ですが、最近では有効な製品も出ており、標準技術の利用が簡単に行えるとともに、思想の方向性を示してくれるなどのメリットも多いので、これらの製品を使われることをお勧めします。

この場合も前述と同様に、SOA製品を使って開発すればすべてSOAのシステムができあがるわけではないこと、BPM製品を使えばBPMが実現できるわけではないということは注意が必要です。

2.SI経験から学んだこと

基本的なSOAの心構え

まず、SOAについて私が構築した事例を交えながら少し述べさせて頂きます。SOAシステムの構築において最も検討が必要なことは、サービスをどの単位で提供するかです。よく言われる「サービス粒度の切り方」です。

サービスの単位はビジネスプロセスの単位である必要があります。従来の開発思想でサービスの粒度をモジュール化と同様に考えてしまうとSOAのメリットを出せないシステムになってしまうので注意が必要です。

私が設計時に常々意識しているのは、「会社・組織レベルの変更があったとき、どのサービスを改修すればいいか」「ビジネスモデルを変えたとき影響がでるのはどのサービスか」など、影響範囲の局所化です。ビジネスプロセスの単位でサービスを実装することは、小さなビジネスプロセスの組合せで大きなビジネスプロセスを実装し、そのビジネスプロセスの組合せでビジネスモデルを組み立てることを可能にします。その結果、会社・組織レベルの変更にも柔軟に対応できるSOAシステムが実現できると考えています。

このような話は市販の書籍やいろんなサイトに多く書かれているので詳細はそちらを参考にして頂くとして、ここでは私がシステム構築において経験してきた話について記述したいと思います。

流通業B2B購買ASPサービスでのSOAシステム構築事例

以下の図は文頭で紹介させて頂いた6年前に構築したシステムのイメージです。

流通業B2B購買ASPサービスでのSOAシステム構築事例

ここで特徴的なのは、当初製品として殆ど実用化されてなかったESBの役割を、EAI機能を用いて実現しているところだと思います。

EAIサーバでSOAPインタフェースを提供すると同時に、レガシープロトコルにも多数対応できているというところです。あらゆるプロトコルやフォーマットをEAIサーバで吸収し、それをSOAPの標準モデルに変換して業務プロセス群を呼び出しています。

本来のESBの役割とは異なり、EAIで実装していることにより、この部分にビジネスロジックの一部を持ち、複数のプロトコルを集約し、電文の種別で呼び出すサービスを振り分けるところまで行なっていました。

ビジネスプロセスのサービス化の観点で見ると、一番粒度の大きいビジネスプロセスとして、「注文」「出荷」「請求」などのレベルがあります。更に細かい粒度として「採番」「在庫引き当て」「出荷指示」などがあります。

いま振り返ってみると、業務プロセスのサービス粒度の切り方という点でもっと深く踏み込んで設計すべきだったと思っています。当初はSOAを意識してサービス設計を行ったわけではなかったため、お世辞にも再利用性が高いとは言い難いサービスの粒度になっています。

余談になりますが、開発当初で一番苦労したのはEAIサーバと業務プロセスサーバのSOAP接続がなかなかうまく行かなかった点です。双方のサーバでサポートするSOAPの形式が異なったことが原因だったのですが、まだSOAPが一般化する前であったがゆえに起こりうる問題で、今では考えられないようなことです。

製造業 設計基盤でのSOAシステム構築事例

次に最近の事例で製造業のSOA基盤の内容を紹介します。このお客様ではグループ企業内でそれぞれ固有のシステムが運用されており、それぞれにコストが発生しているため、これらシステムのインタフェースを統一することで全体の開発コストと今後の改修コストなど維持・運用にかかるコストをおさえようという目的でSOAを採用されています。

このシステムは共通の画面インタフェースからBPELエンジン/ESBを経由してレガシーシステムや新規導入するシステムの各種サービスを利用するといった構成になっています。

機能数が多く、いかに再利用性の高いサービス構造にするかが最大の課題となるシステムで、サービスの粒度と拡張性の高いアーキテクチャにするという点に設計の殆どの工数をつぎ込んでいます。このフェーズはまさにSOAシステムの生命線であり、今後のシステム拡張におけるコストおよびシステムそのものの寿命を決めると言っても過言ではないと思っています。

以下にシステムのイメージを示します。

製造業 設計基盤でのSOAシステム構築事例

流通業でのBPMシステム構築事例

次にBPMシステムの事例をひとつご紹介します。通常のビジネスプロセスは人が主導で動いていきます。それはたとえシステムのインタフェースがSOA化されたとしても変わるものではありません。そこにBPMシステムを導入することで、主導権が人からシステムに移り、ビジネスプロセス全体を効率的に管理し、全体最適を実現することが可能になって行きます。システムの処理と人の作業により構成されるビジネスプロセスおよび複数のビジネスプロセス間のやり取りをシステムが管理することで、無駄なオペレーションやタイムラグを徹底的に無くしていくのがBPMシステムの役割となります。

ここで紹介する事例では、本部と店舗および本部内において人と人との間でやり取りするヒューマンワークフローをBPMシステム上に実装し、本部や店舗で使用する業務システムから人への通知(作業指示)もBPMシステムで実装することで、本部や店舗の人が行うべき作業の一覧がポータルサイトにタスクリストとして表示されるというものです。そのタスクリストには作業内容とともに、期限・優先度なども示されているので、今何を最優先で実施しないといけないのかが一目でわかる仕組みを実現しています。

また、人と人、人とシステムのインタフェースに加え、次期フェーズでの計画にはなりますが、システムとシステムのやり取りもBPMシステムが管理することで、ビジネスプロセス全体の流れをBPMシステムが把握し、BAM機能を活用することで、ビジネスプロセス全体のどこにボトルネックがあるかを簡単に見つけ出すことができます。見つかったボトルネックに対し、それを改善するためにビジネスプロセスを組み替えた場合の効果をBPMシステムでシミュレーションすることも可能です。このようにPDCAサイクルを常時回しながら業務改善を実現できるのがBPMシステム導入の最大の効果となります。

以下は現状の利用範囲でのイメージ図です。

流通業でのBPMシステム構築事例

3.拡大していくSOA/BPMへのニーズ

最後に、ここ数年お客様はITの流行を追うのではなく本当に効果が見込めるIT投資のみを行うようになってきています。そんな中でSOAやBPMが注目を集め、投資を検討されるお客様が増えているのにはそれなりの理由があります。レガシーの資産を有効に活用でき、新しい技術との融合で全体最適が図れ、会社・組織レベルの大きな変革にも柔軟に対応できるような拡張性に優れたシステムが必要とされているからであり、システムが企業の発展の足かせになるなど決してあってはならないからです。

上記のような理由から、未曾有の不景気と言われる今だからこそSOAを採用し、(部分的でも構わないので)BPMを行う時期だと思っています。

ここ数年はSOA/BPMの需要が大きく拡大していくことに違いありません。クラウド化のニーズ拡大が更に拍車をかけています。SOA/BPM技術者の供給をそれに追従できるようにしていくことが我々IT技術者の課題であり責任だと感じています。

ページの先頭へ戻る