requirement development meets soa

要求開発とSOAはセットで入れろ～要求開発ベースのSOA方法論～

株式会社豆蔵 BS事業部

岩崎浩文

1 Copyright 2008 Mamezou. CONFIDENTIAL

SOA型システム設計・実装時の問題点


Copyright 2008 Mamezou. CONFIDENTIAL2

SOAプロジェクトは「大変な事」になる可能性が高い


SOAでありがちな「大変な事」の例製品ありきで突っ走って大変な事に

SOA製品の知識を誰も持っていない状況で楽観視して暴走

ベンダー主導で製品導入に走ったがその後を誰も考えてなかった

明確な設計方針無く突っ走って大変な事に各サービスの切り方で揉めに揉めてグチャグチャに

各サービスをバラバラの担当者や企業に発注して大変な事に

社内調整で時間を使い果たして大変な事に部署間にまたがる連携時に各部署間の調整で大揉めに

エラー発生時の責任所在を巡り社内政治が発生して大喧嘩

実装技術が低くて大変な事に SOAの経験と知識を持つ技術者が揃わず現場は修羅場に

運用経験ゼロで勘所が分からずサービスイン時に大問題に

何故「大変な事」になるのか?


設計の根拠が無い、または不明瞭

すべてのシステムは業務命題を解決するために存在するのだが・・・そうなっていない?

業務担当者の思い込みや思い入れでねじ曲げられる仕様

実装を知らない設計者の、実装できないトンデモ設計

システム実装側の勝手な理屈でへし折られるまともな設計

とにかく全ての作業が「繋がってない」事が原因

これらは全て通常の開発でも起こる問題だが、多くのシステムにまたがるSOAプロジェクトではより濃縮されて問題が露呈しやすい

結局どうすればいいか?→業務システムにトレーサビリティーを


業務システム構築のためには、業務命題から設計に繋がる「根拠」が必要何故そうなっているのか、どうしてそうなったのか。積み重なるコストの要因は全て業務命題に繋がっている必要がある。

業務からシステムに繋ぐ根拠の導出には、的確な手法が必要企業非依存のオープンスタンダード「OPENTHOLOGY」の豆蔵版である「enThology」（エンソロジー）では、統合開発作業に必要な、設計時における遡及可能性（トレーサビリティー）を工学的な手法として整備

実装時に設計の根拠で揉めるのは、業務命題に繋がる設計がされてない為

↓業務から繋がった客観性を持つ設計が必要

SOAの諸問題に対する豆蔵の具体的解決支援策



SOA型のシステム統合設計には、それに対応した定式化された方法が必要


業務から導き出された要求と、既存システムは、直接繋がらない現実がある

シンプルで美しい理想像と、想像以上にスパゲッティー化している既存システム群のギャップは激しい

イチから全部新規で構築するのであれば容易いが、あくまでSOAの主眼は「既存システムの統合」

業務命題から導出された理想像としての

仮想単一システム像

現実としての重複の多く泥臭い

複数の既存システム連携設計

Java

.NETホスト

VB6

定式化された方法が無ければ、担当者によりバラツキある品質どころか失敗しかねない

豆蔵の具体的解決策の例:enThology大規模分散システム方法論


enThologyの中で、インテグレーション（システム連携）分野のアーキテクチャー設計を担当する方法論

「戦略的情報化企画」、つまり設計部分での方法論

ITアーキテクトをメインターゲットとしたもの

SOAにも対応した汎用的方法論として整備

オブジェクト指向分析から具体的システム連携まで、一貫したトレーサビリティーを担保した実践的手法

既存システムをいかに合理的に繋ぐか、に特化した手法

情報の構造に着目し、仮想的な「分散システム」として、全体で整合性を担保する形で設計を行う手法を採用

本方法論の位置づけ


IT投資の局面と活動領域 (ITSS V3)

経営戦略策定

戦略的情報化企画開発運用・保守

契約の観点

業務要件定義

システム要件定義

システム適格性確認テスト

IT戦略策定

運用テスト

戦略効果評価

ソフトウェア要件定義

ソフトウェア適格性確認テスト

ソフトウェア開発

ソフトウェアテスト

準委任契約

請負契約

本方法論はこの辺!

要求開発はこの辺!

本方法論の対象読者


ITスキル標準 (ITSS V3)より

本方法論はこの辺!

付属資料の例:enThology業務プロセスパターン


本方法論の追加資料として、業務プロセスのパターン例集を完備

OMGにより2003年より定義されているワークフローパターンを、より具体的なBPMNによる業務例と解説を加える形で整備

分散システム方法論の中で、システム連携部分にワークフローエンジンを採用する場合、本方法論をそのまま参考にすることが可能に

参考例として、Microsoft .NET Framework 3.5 Windows

Workflow Foundation (WF) による実装例も添付

旅行予約システム

航空券を予約する

ホテルを予約する

レンタカーを予約する

クレジットカードの支払を処理する

顧客

ホテルが不要

レンタカーが不要

申込みを受け付ける

予約完了を通知する

予約情報申込

レンタカー予約サービス予約

結果

ホテル予約サービス

航空券予約サービス

予約

結果

予約

結果

航空券が不要

A

B

C

A

B

C

A

B

C

OMG Workflow PatternsenThology

業務プロセスパターン .NET WF例

付属資料の例:複数プラットフォームのプロトタイプでの検証


異種混在型統合を前提とした実践的アプローチの為、Java EE及び.NET Frameworkでのプロトタイプで検証を実施 WS-BPELやWS-Atomic Transaction、WS-Security等を用いた次世代統合技術を中心とする

本検証の資料が添付

▲Java EE 5版 (JBI + BPEL + Glassfish V2 + DB2 V9.5)

▲.NET Framework 3.5版(WCF + WF + Windows Server 2008

+ SQL Server 2005)

要求開発とSOAはセットで!


要求開発から先の話には、SOAが待っている!

要求開発が扱う領域は大きい!!

大きい領域をシステム化する時には、結局SOAのようなシステム間連携が登場する事になる

SOA型システム設計には、要求開発が必須!

SOA化する時にいつも「サービスの切り出し方」が話題になるが、それは要求開発で業務から開発すべき

トレーサビリティー担保の為にも、やはりきちんと上流からやるべきです


株式会社豆蔵http://www.mamezou.com

〒163-0434

新宿区西新宿2-1-1新宿三井ビル34F（私書箱302号）TEL: 03-5339-2114（代表）FAX: 03-5339-2380

requirement development meets soa

Technology