システムの構造とアーキテクチャ
ここまでで、SOAという言葉が何回か出てきたが、このService Oriented Architectureというのは一体なんなのか、どういう定義なのかと、言ってみたが、極端な話そんなことはどうでもよくて、要はビジネスサイドかつシステム技術サイドからの変更要求に早く、柔軟に対応できる仕組みを作りたいだけで、SOAを実行することが目的でもなんでもない。だから、SOAを実践した事例はこれですなんておかしな話なわけで、システムを作ったらそれがSOA的であったというのが正しいのであり、サービスをつないでシステムを作ればみんなSOAでいいのだ。
このあたりは、4～5年前に筆者がシステムの構造をどうしようとしていたかを説明するのがいいのかもしれない。
当時、メインフレームかオフコン上の基幹業務システムの外でいろいろなサブシステムや情報系システムが作られていた。それが、ほとんど連携しないで独立していた形でせいぜいFTPみたいなものでつながっていた。そこにやっとWebサービスのような技術あるいはEAIやBPMのようなツールが登場し、システム間の連携ができるようになったが、まだ多くの問題を抱え普及は大きくは進展しなかった。
ただ、システム間の連携という場合、まずはシステムを構造化することが大事であると考えた。「構造化する」とは、（1）全体を俯瞰したうえで、構成要素に分解し（2）それらの構成要素間の関係を分かりやすく整理し（３）統合化されたモデルを作ることであり、それぞれのレイヤで必要になる。
例えばEAでいうところの政策・業務体系では、業務をコア業務とサポート業務に分けさらにサプライチェンサポートとプロフェッショナルサービスや定型業務に整理してみることや、適用処理体系では、ＥＲＰを使うのか、手組みにするのか、外部サービスを利用するのかとか、もう少しシステム寄りで入力・出力系のアプリケーションをどう配置するかだとかになる。
こうして、アプロケーションやシステムコンポーネントを整理した後、重要になってくるのがシステムの骨組みをどうするか、そこの血流をどうするかである。
こうした、連携・協調に対する骨格としては、ハブ＆スポーク型の構造が有効である。まあ、有名なあのＦｅｄＥｘモデルだ。例えば、各アプリケーションで生成されたデータは一旦統合データベースに集められて、そこから各ユーザに配信されるというイメージだ。
このような、ハブになる仕掛けがいろいろある。いまデータの話をしたがデータの場合のハブはＥＡＩやデータウエアハウスであり、帳票印刷・配布なんかも同じ考えができる。（その当時はこの統合プリントシステムがなかった） また、機能のハブがBPMであり、処理（プログラム）のハブはデータベースである。
こうしたハブ＆スポーク型の構造が今でいうSOAにつながっていると思っている。ＦｅｄＥｘモデルも当初は単にモノを運ぶだけの仕組みであったが、最近は空港の近くに倉庫を持って物流・在庫管理を含めたサービスも提供するようになった。ということは、当初はハブ＆スポーク型の構造でデータやその他の情報を行き来させるだけだったのが、サービスという形に変えて連携するSOA型に進化してきたのは、ＦｅｄＥｘと同じだと考えればわかりやすい。
ということで、最近ではハブが企業内だけにとどまらずインターネット全体に存在し、単純な構造から網の目のような複雑で柔らかい構造になってきている。ここで言ったようにこうした展開は、別にSOAを意識したものではなくある意味必然的にたどりつく道であるような気がする。繰り返すが、SOAを構築しましょうではないのです、柔軟で変化に強い仕組みが作りたくて、できたものがSOAだったということなのです。