情シスは何度でも甦るさ。

OracleDB/Ruby好きの情シス部員がお送りします

SOAの定性効果5つ

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

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

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


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

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

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

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

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

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

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


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

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

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


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


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


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


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


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


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


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

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


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