SOAの定性効果５つ - 情シスは何度でも甦るさ。

SOAが微妙なのは、SOAの考え方、コンポーネットセットなどは理解できても、それをどう実装すれば良いかがわからないからだと思う。

そのためには、ＳＯＡとは、こういうものだけど、これを使うとこんなことができるんだよ。
という、事例集が、圧倒的に不足しているからではなかろうか。

まぁ、ＳＯＡはアーキテクチャだから、オブジェクト指向と同じく、こういうアーキテクチャなんです、でも、実際の使い方はお客さんで考えてねっ！
っていう言い方もわかるんだけど、いかんせんＳＯＡは、レイヤーも違うし、金もかかるし、それでもうユーザーは慎重になっちゃいますよね。

そうかと思えば、うちみたいに、ベンダーの口車に乗せられてしまい、ＳＯＡの魔力に取り付かれた上層部から

「SOAとやらを導入して効果を出すのだ！」

と、言われちゃうことも。

そこで、言葉どおり、SOAを導入することを目的にした時点でそのプロジェクトは終わる。

手段が目的化してしまっているからだ。

SOAは手段であり、目的ではない

と、声だかに言われる所以である。

そんな経営層の無茶ブリを成功させるには、まず、その会社の現状の課題を洗い出し（ai-is）、その課題が、SOAにより効果が出るかを検討し、SOA導入後の姿を描く（to-be）

では、SOAでは、一般的にどのような課題に対して効果が出るのだろうか。

というわけで、うちの会社で検討したＳＯＡが効きそうな課題を出してみる。

１．システム間連携
　基幹システムに複数のサブシステムがデータ連携している。
　でも、サブシステムが増えるたびに、工数がやたらかかる仕組みになっている。
　そんな時は、基幹システム側で該当のデータを提供できるサービスを公開することで効果がある。

２．シングルサインオン（システム統合）
　複数のクラサバ、Webシステムがある。ユーザーは、複数のUIを使い分ける必要がある。
　しかも、同じような情報を複数のシステムで見れてしまうため、ユーザーが混乱する。
　そんな時は、各システムが、ビジネスロジックはそのままに、サービス化し、統合的なUIからそれらのサービスを呼び出す。
　これにより、画面統合、及びシングルサインオンなどが出来、その会社内の統合システムが構築できる

３．コーディングのスキル不足を補う
　ユーザー企業だと、IT部門にあまり人材がいない。または、スキルも低い。
　そこで、BPELなどのコーディング不要のツールを導入することにより、スキルの低いIT部門でも、教育コストをかけずにシステム開発ができる。

４．マスタ統合
事業の拡大などで、システムがいくつも追加されていく。
結果的に、マスタもシステム毎に保持してしまい、またそのマスタをお互い参照し合うなどの結果になりがち。
特に参照系については、DBを直接参照するという安易な手順に逃げがちだが、それではどのシステムがどのDBに接続しているかという管理をDBのレイヤーで実施しなくてはならない。しかも、それはテーブルの定義をマスタごとに確認し、SQLをゴリゴリ書くはめになる。
そこで、マスタを参照する標準的なサービスを定義し、その単一のサービスを呼び出すことにより、全てのマスタの情報を呼び出せるようにする。
呼び出し側は、どのシステムのどのマスタからデータを取得しているかなどは意識しなくてよく、裏側でマスタの統廃合などを実施しても、サービス内でそれらの変更を吸収できる。

５．ビジネスプロセスの見える化
個人的には、これはもうBPMのエリアだと思うので（SOAとBPMの境界線は凄くあいまい。個人的には、業務部門がメインに動かないといけないのがBPMで、システム側がメインで動くのがSOAというイメージを持っているのだが、どうなのだろう）、詳しく書かないが、ビジネスプロセスを見える化し、現状のフローの課題を洗い出し改善を実施する。

番外編．複数ベンダーへの発注
よく最初に頼んだベンダーに、保守開発も頼んでしまうというのがよくある。
当然、最初に開発した会社は勝手がわかってるので、保守開発のコストも下がる。
これは、１つのシステムを全て１ベンダーに委託しているが故に起こる。
だが、逆にその会社が潰れちゃったり、お気に入りの担当者がいなくなったりした場合に非常に困る。
また、初期開発の時でも、仕様変更が走りまくったりした際に、ベンダーの人材不足で、工数が追加できずに納期が守れなかったりすることもある。
そんな時は、１システムを複数ベンダーに発注できるとリスクを低減できるのだが、それはそれでベンダーコントロールや責任境界線が指南の技。
なので、１システムを丸々発注するのではなく、１システムを複数のサービスに分割しサービス単位でベンダーに発注すれば、複数ベンダーに頼むことができるんじゃないか。という話が出た。
確かに、サービスのI/Fだけガッチリ決めとけばうまくいくような気もするが、やはり複数の窓口だと色々大変だから、番外編扱いで。
でも、実際そういう要件のために、SOAを採用した事例もあるので、ベンダーコントロールさえできれば、良い手なのかもしれない。

SOAなので、結局は共通化、標準化、再利用、（そして見える化）という視点になる。ただ、上記の課題はどこの企業でも起こり得そうな課題である。

それらのうち最も効果がありそうな課題に対してSOAを導入し効果を出すべきだ。

と、簡単に書いたが、課題が見つかったところで、そこから実際にどうSOAを導入するかというのは、また大変難しいところだったりするのよね。