SOAと「つなぐ」技術 第3回 「SOAのレイヤ構造の概略と、SOAが経営にもたらす変化について」

Avatar
dstn

アプレッソ開発部の渡辺です。

今回は、SOAの概略についての説明と、SOAが業務部門や経営にもたらす変化について紹介します。 

SOAの概略

これまでの記事でSOAの基本的な考え方として以下をあげました。 

  • 業務システムの構成要素を「サービス」として部品化する
  • 各サービスには「標準化されたインタフェース」があり、外部から呼び出すことが出来る
  • 上記のようなサービスを組み合わせ、業務に必要なアプリケーションを作り上げる 

以上より、SOAにより構築されるシステムの最も簡単なレイヤ構造は以下のようになります。 

  • プレゼンテーション層:業務に必要な機能を具体的に提供するアプリケーション 
  • HUB/BUS:様々なサービスを呼び出せるようにする 
  • サービス:業務機能単位でリソースがブラックボックス化され、標準IFで呼び出せる 
  • リソース:具体的なアクセスする情報や、具体的に行う処理の本体 

SOAでは、最終的に利用される機能の実体(リソース)が、サービスとしてブラックボックス化されて部品化されます。その際に、どのような単位や粒度で「サービス」として部品化をするのかが問題となりますが、一般的には業務の単位で部品化を行ってサービスとします。そのようにすることにより後述する様々なメリットが生まれます。 

各サービスは標準インターフェースで呼びだせるようにし、さらにHUB/BUSによって様々なサービスを呼び出せるようにします。HUBはEAIによる実現例で代表され、サービスをハブで結びつける方法です。BUSは、標準IFを持つサービスをバス(ESB)に接続することで、BUS経由でサービスを呼び出せるようにする方法です。HUBとBUSは組み合わせて使うこともできます。 

そして、業務に必要な機能を具体的に提供するアプリケーションは、HUB/BUS層経由で必要な機能を呼び出すことで実現される、という構成になっています。 

上記に加え、サービスの種類を区分したりレイヤ構造を増やすなど様々な提案があります。その中でも、シンプルで効果的なものを以下に紹介します。プロセス層を設ける考え方です。 

  • プレゼンテーション層:業務に必要な機能を具体的に提供するアプリケーション 
  • プロセス:サービスをワークフローなどで組み合わせて、業務プロセスレベルにする 
  • HUB/BUS:様々なサービスを呼び出せるようにする 
  • サービス:基本業務機能単位でリソースがブラックボックス化され、標準IFで呼び出せる
  • リソース:具体的なアクセスする情報や、具体的に行う処理の本体 

サービスを少し小さめの粒度で作り、複数のサービスを組み合わせて業務プロセスを組み上げるレイヤーを追加したモデルです。後述しますが、プロセス層にBPMツールを導入することにより、強力な変更容易性と変更迅速性を得ることが出来ます。 

SOAの導入が経営や業務部門にもたらす変化

ここまでの連載では、業務システムをいかにして効率的ないしは合理的に作るかという説明をしてきました。つまり、技術者によるシステム開発の手段としての説明が主でした。しかし、SOAの導入は、つくり方の変更だけでなく、経営層からの業務システムの見え方を変えたり、業務部門によるシステムの利用に変化をもたらす効果があります。 

ビジネスの迅速化 

現在のビジネスにとってITは必須です。ITの柔軟性やITの速度は、そのまま業務の柔軟性や速度につながります。 

システムを迅速に作り上げられることは、新規事業を迅速にサービスインできることを意味しますし、迅速にシステムを変更できることは、様々な事態に素早く対応できることを意味します。小さい投資で少しずつシステムを作れることは、新しいビジネスを開始するハードルが低くなることを意味します。 

SOAは「見える化」である:業務がサービスとして「見える化」する 

IT部門にとっては、SOAは他の部品化を指向する考え方、例えば分散オブジェクト技術と部品化の流儀が異なる程度のもの、あるいはより便利になったもの程度に見えることがあるかもしれません。しかし業務部門にとってはSOAでの部品化の結果には大きな違いがあります。 

IT部門と業務部門には「考え方」のギャップがあることが知られています。通常の業務システムはIT部門の考え方や世界の見え方で作られていることが普通ですから、業務部門にとって業務システムは、違う考え方の人たちが作ったブラックボックスであることが通常です。 

しかし、SOAでは、サービスを「業務機能の単位」で部品化することが一般的に行われます。これはつまり「業務部門の目線で部品化(サービス化)をする」ことになります。 

従来のシステムにおいても内部構造はあります。しかしIT部門の考え方にあわせて作られた内部構造でした。しかしSOAでは、サービスレベルでの内部構造の意味が、業務担当者にも読み取りやすいものになっています。 

従来:業務システム全体がブラックボックス
SOA:業務システムは透明な箱になって中が見えるようになり、サービス(部品)の意味が解るようになり、どのように部品を組み立てて業務を実現しているかも理解容易になる 

これまでは、どのような業務を実現したいかをIT部門に説明し、IT部門に実現してもらわねばなりませんでした。しかしSOAでは、サービスをどのように組み合わせて必要な業務にするかは、業務部門の言葉で考えて語れるようになります。 

また、サービスを一覧することで、業務部門が自社の業務システムが持っている「業務」を一望することもできるようになります。結果として、重複など無駄なものは無いか、足りないものがないか、投資が偏っていないかなどを確認しやすくなります。つまり、「見える化」することで、全体最適化もできるようになります。 

BPM+SOAは「できる化」である:業務部門が業務を作り・動かし・変更できるように 

さらにSOAにプロセス層(本記事の最初の説明を参照してください)を設け、プロセス層に業務部門が自ら業務プロセスをデザインできる「BPM」を導入すると、業務部門が自らBPMを用いてサービスを組み合わせてプロセスを作り、必要な業務を自ら実現し・実行し・変更して改良することができるようになります。 

つまり、SOAの部品化による「見える化」の実現に加え、BPMにより「サービスを組み合わせて、業務に必要なアプリケーションを作り上げる」ことが現場主導で実現できるようになります。 

例えば、従来からある配送業務に追加して、雪が降る地域の降雪時期の配送業務を新しく作ることにしたとします。従来ならば新しい業務に必要なことをまとめてエンジニアの力を借りてシステム化をせねばなりません。 

しかし、BPM+SOA化がなされていると現場主導で迅速に新業務に必要なアプリケーションを構築できるようになります。 

サービス化が済んでいれば「見える化」していますから、新しい業務の実現のために必要な部品(サービス)は何であるか容易に判断ができるようになります。さらに、BPM上でビジュアルな図を描いて必要なサービスをつなぐことで、現場で新業務に対応したシステムが作れるようになります。さらに、作ったものに要改良点があっても、業務部門主導で素早く修正することまで出来てしまいます。 

トップダウンの導入も、ボトムアップの導入もできる

業務の改革にはトップダウン型とボトムアップ型がありますが、SOAはいずれも対応ができます。また、SOAは変更の柔軟性を売りにしていますから、トップダウン型にせよボトムアップ型にせよ、段階的にSOA化を進めることもできます。 

トップダウン型とは、業務のあるべき姿をトップダウンで描き、あるべき姿から必要なサービスおよび、サービスを組み合わせて実現する業務アプリケーションについて明らかにし、あるべき姿をSOA基盤上で実現するような導入方法です。大掛かりな導入事例で採用されやすい方法です。 

ボトムアップ型は、現場主導で業務システムの機能をサービス化してゆき、そうやって作ったサービスを使ってシステムを組み立てなおしてゆく方法です。小さく始めて次第に導入する際に採用されやすい方法です。 

おわりに

SOAが業務部門や経営層にとって、どのような価値を持つかを紹介させていただきました。

SOAは部品化してシステムを組み立てようという考え方ですが、部品化の考え方はSOA固有の考え方ではなく、他の様々な取り組みでも見られる考え方です。そのため、SOAとは何か、他とはどう違うのか解りにくく思えることがあります。そこで、エンジニア目線ではない目線で見ると、部品化の意味が違うことと、加えてSOAとBPMを組み合わせる意義について紹介させていただきました。

 

 

引き続いての記事では、SOAを構成する個別の技術やトピックについて紹介をさせていただく予定です。

コメント

ログインしてコメントを残してください。

Powered by Zendesk