技術動向――SOAに連なる分散アーキテクチャの発展経緯サービス指向アーキテクチャ 第2部(1/2 ページ)

企業内部に存在するさまざまなシステムを相互に連携させ、さらに価値のあるサービスを実現したいというのは、大規模なシステムを運用している組織であれば誰もが抱く希望である。

» 2005年01月21日 00時00分 公開
[Open Enterprise Magazine]
OPEN Enterprise magazine

 現在では、インターネットという地球規模の広がりを持つネットワークに接続されていることを前提としてシステムを設計できるため、インターネットを介して相互にやり取りしながら自動的/自律的に処理をこなしていくシステムを発想するのはごく当然といえる。しかし、現実にこうしたシステムを実現するには、さまざまな技術的要素が必要となり、現在でもまだすべてが完備したとはいえない状況だ。ここでは、SOAを取り巻く技術面での動向を紹介したい。

システム・アーキテクチャの変化

 企業内におけるコンピュータ・システムの利用は、大量の数値を扱うなど、もともとコンピュータが得意とする処理で、人手で処理したのでは時間やコストがかかりすぎる分野から順次段階的に始まった。人手で行なっていた作業を部分的にコンピュータ化する段階では、システム全体のアーキテクチャを変更する必要はなく、コンピュータ化された処理も、最終的には人手によって他の業務と統合される。具体的には、コンピュータ処理された情報が、最終的に帳票に打ち出され、従来の処理との違いは単に帳票が手書きなのかプリンタによる印字なのか、という違いだけ、という状況である。その帳票を元に次の処理を行なうのが人間なのであれば、帳票が手書きかプリンタ印字かという違いは何の影響も及ぼさないため、業務システム全体のアーキテクチャとしては、部分的に導入されたコンピュータのことを無視することが可能であった。こうして構築された業務処理単位に特化したコンピュータ・システムは、いわゆる「部分最適」という形で洗練度を高めていった。当該処理のことだけを考えて最適化されたシステムは、実用上は低コストで効率的な運用を可能とする。

図1■業務別のコンピュータ化。全体の仕組みを変えずに特定要素だけをコンピュータ化するため、部分最適とならざるを得ない

 しかし、ITの発展に伴い、コンピュータ化はさまざまな業務に拡大され、現在では事実上ほぼすべての業務が何らかの形でコンピュータ化されているという企業が大半だろうと思われる状況になってきた。この状況では、人手による処理を前提に組み立てられた全体システムに手を加えることなく、特定部分だけを「部分最適化されたコンピュータ・システム」で置き換えていく、というアプローチには無駄が生じる。今となっては笑い話にもならないが、コンピュータ化が順次拡大していく局面では、あるコンピュータ化された処理で出力された帳票を、別のコンピュータ化された処理に引き渡すために、オペレータがプリンタ印字された帳票を見ながら再度データ入力していた、などという状況さえ生じていたのである。処理をコンピュータ化することで得られるメリットを最大限に引き出すためには、人手による処理を想定した全体アーキテクチャの中に他の部分に影響を与えない形で部分最適化されたシステムをはめ込んでいくという考え方から、最初からコンピュータ処理を前提とした全体アーキテクチャに切り替えていく必要がある。こうして生まれてきたのが、最新の企業システム・アーキテクチャであり、具体的には、EA(EnterpriseArchitecture)やSOA(ServiceOriented Architecture)なのだ。

分散システムの相互接続

 企業全体の活動のなかでは、さまざまな業務プロセスが実行されている。それをコンピュータ化していくうえで利用されるのが、さまざまな業務アプリケーションということになる。初期の業務アプリケーションは、当然だが他のシステムとの連携などはまったく意識せず、完結した存在として設計された。

 つまり、この段階の業務アプリケーションは、単独で完結した「業務システム」だったのである。完結しているが故に独自の手法で最適化され、必要な処理要素はすべて自前で揃えている。

 しかし、企業全体の活動は、こうした個々の業務システムの結果を統合することで動いているため、何らかの形で相互連携を実現し、取りまとめていく必要がある。前述の、出力帳票を見ながら再度データ入力する、という方法も、条件によっては現実的な解の1つではあるのだが、これではあまりに非効率的であることは明らかだ。そこで、各業務システム間を連携させ、必要な情報をやりとりする仕組みが必要となった。

 初期の段階では、相互連携が必要なシステム同士を再設計し、独自に連携を実現するという手法が採られた。これは、考え方としては、従来独立したシステムであった業務Aと業務Bを、新たな統合業務である業務Cにまとめ、業務Cのためのシステムを新たに設計する、という手法だといえる。つまり、システムの粒度が上がり、内部に比較的独立性の高い複数の業務が存在すると捉えているのである。

       1|2 次のページへ

Copyright (c) 2005 Socius Japan, Inc. All Right Reserved.

注目のテーマ