読者です 読者をやめる 読者になる 読者になる

そごうソフトウェア研究所

SOA、開発プロセス、ITアーキテクチャなどについて書いています。Twitterやってます@rsogo

SOA(いまさら)再考

SOAについて過去の経験から俺理論で整理してみます。


まず前提。

現在の企業のITは複数のシステムで構成されている。
ホストやERPを中心に小規模なオープン系のシステムが周辺に配置された中央集権型や、業務領域ごとに複数のシステムから構成される連邦型など、その企業のITの生い立ちによっていろいろと形は違いますが、比較的規模の大きな企業では複数のシステムを持っていると思います。


次に、受注情報や、請求情報などイベント系データはある業務が終わると次の業務に情報を渡す必要があるのでシステム間連携は必ずあると思います。リアルタイムか締め日に合わせたバッチ連携かは別にして。

Webで受注を受け付けたら、その情報を製造へ渡す。製造の情報を物流に渡す。などなど。

または人事マスタは部品マスタのようなリソース系データを複数のシステムで参照したいというニーズもあるはずです。


ここまでは企業システムに関われている方はそうだね、という感じでしょうか?
不特定多数のユーザ向けの軽い処理を非常に大量に処理するようなWebシステムは違うのかも知れません。企業内やグループ会社間で使用されるようなシステムの話しです。


ここまでの前提は良いとして、このような企業システムへのニーズに対するSOA適用のアプローチは大きく二つの流れがあったと思います。

一つはシステム間連携にSOAPという標準的でシンプルな(安価な)プロトコルを使うことに着目したアプローチ。システム間連携には本当にいろいろな方式がありますが、企業内でいろいろなハード、ミドルウェアが稼働しているのでSOAPは比較的受け入れられやすかったと思います。
ただし、SOAP over HTTPは比較的ライトなプロトコルであり、機能的に不足している部分を場合に寄ってはアプリケーションの作り込みでカバーすることもあったかと思います。具体的にはトランザクションの問題、大量データの連係、非同期連携の問題などです。
第3回 SOAの4つの事例から見るデータマネジメントの本当


もう一つがサービスに着目したアプローチ。このアプローチを取ったプロジェクトはシステムの機能をサービスという抽象度を高めた層を作って、そこで機能を提供することにしました。抽象度を高めるというのは具体的にはシステムの言葉から業務の言葉にしています。
例えば、特注品の受注という業務的な意味・行為は今のシステムが別のシステムになったとしても変わらないよね、という考えました。また、特注品の受注というサービスは実際は複数のシステムで実現されている機能をとりまとめている場合もあります。


このアプローチは「あれ、受注ってこのシステムにも、あのシステムにも、こっちの部門のシステムにもあるよね?無駄じゃない?」という気づきもあり、EAのような全社最適の考え方とも融合していったと思います。

EAもそうなのですが、こうなると1プロジェクト、1部門の話しではないのでかなり上の層のオーナシップ、リーダシップが必要となり、また長い改善の取り組みの話しになるのでビジョンを持って、この活動に意味を見いだした企業しか取り組まなかったと思います。


自分が考えるSOAの最大のメリットは上の2つの組み合わせで、いろいろなシステムで実現されている機能を重複して作るのではなくって、既にある機能は使って行きましょう(新しい付加価値に投資できたらいいですよね)。そのためには個々のシステムに依存してなく、標準的なやりかたでやりましょう、だと思います。
別にSOAPでなくてもいいけど、現状ではデファクトで一番安く手に入るので、わざわざ否定することはないのでしょう。でも非同期と大量データは別かな。


SOAの課題としては、その用語の曖昧さ・広さ。今までのものと何が違うのか?といったところで混乱があったと思います。個人的には技術が標準化されて安価に実現できるようになった点は進歩しているけれど、その考え方は以前からあったものの組み合わせ(ベストプラクティス?)だと思っています。