» 【143号】 分かりやすいSOA設計の提案

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【143号】 分かりやすいSOA設計の提案

■分かりにくいSOA
昨年来、SOAの話題が花盛りですが、その説明はいまひとつわかりにくく、
議論がかみ合っていないように見えます。

原因の第1は、「試行錯誤中の技術」にあるわけですが、説明に実装環境が
絡むこともあって、システムの現状や問題点に関する認識が、説明する側と
これを聞く側にズレが生じ、さらに作業手順についての説明が明示されてい
ないことにあるようにと思われます。
そこで筆者のSOAが正当か否かはさておき、以上の条件を明らかにして、
SOAの分かりやすい説明を試みるものとします。

■現状システム
SOAを検討する際の現状のアプリケーションシステムは、次のような状況に
あるとします。
・社内には、開発・導入の担当者・時期の異なる、手作りやパッケージのシス
テムがたくさんあるが、必要に応じて個別に連携稼動しており、いわゆるSI
LO(孤島)システムとなっている。
・全システムの一覧は関係者によって必ずしも共有されておらず、データや機
能の重複・矛盾も可視化されていない。
・システム間インターフェースの全社一覧も可視化されておらず、担当者任せ
の管理となっている。
・特定のアプリケーションに限っては神様のように分かっている担当者がいる
としても、全社システムまでカバーできる神様はいない。
・各システムの大きさは過大あるいは過小のものがあるようであるが、まだそ
の適正サイズに関する本格的な検討を行ったことはない。
・リソースデータ(マスターデータ)はアプリケーションごとに管理されてお
り、全社一元化はできていない。
・このため、ユーザニーズの変更に際しては、当該システムは勿論、他のシス
テムを含む多くの関係者が調査や改変・テストに動員され運用・保守工数は8
0%になっている。

■SOA化の目的
「うまい・はやい・やすい」といった経営目標にもとづく、ユーザニーズやI
T変革に、迅速に対応できる体制に移行するために、SOA化を図るものとし
ます。ただし、それは大きな文化変革であり、ビッグバン的にはできないので、
試行錯誤を最小限にし、人材を育成しながら、かつ効果を確認しながら遂行す
るものとします。

■SOA化の条件
次のような条件のもとに遂行するものとします。
・実装独立先行:
機械化は、多くのアプリケーションから成るビジネスモデル(データモデル+
プロセスモデル)のあるべき姿を固めてから、これをマッピングして行うべき
という考え方のもとづき、まずは実装独立に重複・矛盾のないビジネスモデル
を描く。したがってESBなどのツールの議論は別途行う。
・フェデレーションアーキテクチャ:
営業、生産、経理、人事など個別アプリケーションは独自の文化を持っており、
これに対応してアプリケーションが作られてきた。いまこれらを連携するニー
ズが高まっているが、一旦これらを分解して統合するERP的な方法でなく、
個別アプリケーションはロウレベルとして残し、アプリケーション間をハイレ
ベルとして連携する、2階層のアーキテクチャ、いわば在来線はそのままに新
幹線を追加したようなアプローチを採用する。
・Hub & Spoke通信場先行:
これはDOA(データ中心アプローチ)方式と同義でもあるが、プロセス(プ
ログラムやアプリケーション)同士が直接連携するP2P(Peer to Peer)方
式でなく、プロセスは通信場とだけ交信するものとする。このため通信にかか
わるメッセージ(平たくはレコード)を集めこれを調整(標準化)してまず通
信場を設計し、各プロセスはこれを前提に設計する。したがって既存のレガシー
やパッケージは必要とあらば変換して接続することになる。メッセージには取
引先コードや商品コードなどが含まれるが、ハイレベルメッセージに含まれる
ものが最も共用性が高く、これをアプリケーションから分離し一元管理する、
いわばハイレベルMDMをねらう。これはMDMの中核であり最も重要かつ効
果的課題である。
・スコープはプロジェクトの戦略課題:
多くに企業において、SOAはSILO解消の目的で登場しており、ハイレベ
ル、すなわちアプリケーション間に限って進めるならば、当初より全社スコー
プで進めることができる企業も少なくないと思われるが、人材不足、方法論習
得不全、リソース標準化未熟、緊急アプリ連結ニーズなど、これを妨げる事情
もありうる。その場合は若干の手戻りを覚悟の上、ある事業のバリューチェー
ン系に限定してこれを先行するなどの工夫が必要となろう。これは続くプロジ
ェクトのパイロットとなるものであり、人材育成と分かりやすい自社事例の作
成を心がけるべきである。
・現状可視化先行:
現状システムに不備があり、新しい変革のイメージがあるとしても、「事業の
売却」のような場合を除き、まずは現状の可視化を先行する。これは一般に
「順次化可能の問題は順次解決するのが速い」というDP(Dynamic
Programming)の原理、および「データの変化はプロセスの変化の1/10程
度のものだ」という経験に基づくものである。

■SOA化の手順
現状におけるSILOを解消し、これに変革を反映して実装独立のToBeモ
デルを可視化する手順を示すものとします。主観的な「サービスの粒度の吟味」
を避けるためにメッセージ(≒トランザクション)を手がかりにします。
(1)アプリケーションの列挙(一般には現状に若干の修正を加えたものになるで
あろう)
(2)SOA化のスコープの決定((1)をベースにアプリを選択する)
(3)アプリ間メッセージの収集(明らかにアプリ内となるものを除き一旦は多め
に収集し以下で順次確定していく)
(4)IPF(Information Process Flow)チャート作成(論理的検証により品
質アップを狙うもの。業務フローのうちメッセージが明示されるIPFチャー
トが最適と考える)
(5)アプリ間メッセージによるデータモデリング(EDH(EnterpriseData Hub)
およびハイレベルリソースDB(MDM)設計、すなわちアプリ間の調整・標
準化)
(6)データモデリング結果のアプリ間メッセージへの反映(これでサービスが列
挙される)
(7)アプリケーションのスコープの吟味、必要とあらば(1)−(6)を再実行
(8)AsIsの問題点まとめと分析
(9)ToBeへのニーズ収集・分析まとめ
(10)ToBeに関し(1)−(7)を実行(AsIsの品質が高い場合は確認程度で
済む)
(11)既存アプリ接続のための変換仕様まとめ
SOA化における最重要成果物は、整合性のとれたサービスの仕様であり、
(5)が鍵となる作業と考えます。これはアプリケーションのスコープに依存し
ますので、これを適正に決めるための(7)には若干の試行錯誤や高度の判断が
必要になります。一般にアプリケーション間でやり取りの必要なメッセージは、
原材料・製品やお金の在庫/残高に関するものが中心になると思われますので、
これを念頭に(3)を進めるとスムーズに展開できると考えます。
なお、EDHの構造は個々のアプリケーションの確定およびその相互独立性を
保障するものですから、EAのドキュメントとしても最重要のものと考えられ
ます。

■まとめ
以上はPLAN−DB手法をアプリケーション間に自然に適用したもので、
「SOA=DOA2.0」とでも言える、さほど新規性のあるものではありま
せん。以上で実装独立レベルの作業は終了し、ESB系やDWH系のベンダー
ツールなどを活用した実装設計に入って行くことになります。DWH系のツー
ルの場合は仮想化をうまく使うことによって排他制御問題などもクリアできる
と考えます。