http://www.sodec.jp/jp/conference/

参加対象

1. 2009/05/13（水）09:30-12:20 [SD-9] SOA成功へのポイントと先進事例紹介

● SOA成功へのポイント ～サービス指向・モデル・ドリブン開発とライフサイクル管理～

日本アイ・ビー・エム（株） インダストリー・ソフトウェア SOAビジネス開発部長
宮田 直幸

• SOAを導入することとは、「機能中心」->「サービス中心」
• 2003年ガートナーレポートにて、サービス指向への提言があった
• IBMでは、2年に1度、CEO・CFOに対してヒアリングを実施している
  1. IBMのコンサルタントが実施したヒアリング結果は、下記にて公開中
     • http://www.ibm.com/services/bcs/jp/solutions/sc/reports/ceostd2008/
  2. [調査結果] CEOの関心事
     1. 変化の早さを機会ととらえる
     2. 顧客の創造を超える
     3. 世界中の優れた能力を活用する
        • グローバルデリバリを実施
        1. インド・中国のリソースを使用
        • （ここでは、よくあるオフショア開発の利点を説明）
     4. ビジネスの常識を破壊する
     5. 社会問題に誠実に取り組む
        • （コンプライアンスなどの社会的な脅威を、ビジネスチャンスとして捉えているという話）
• グローバルのCEOが望む変革
  1. 2006年に比べて2008年は、必要とされる変革の度合いが83％から96％に増えている
     • ところが、変革の実現度合いは、2006年が61％、2008年が62％と、ほとんど変化がない
• ITシステムの周りには、関心の異なるステークホルダーが存在
• 変革の度合いを早くしていく為には、改善活動として捉えることが大事
  • 下記のように変遷している
  1. ITは変化を実現する要素：改善手法（Total Quarity C?）
  2. ITは変化を発想する要素：ITの帰納法的活用（BPR・改革）
  3. ITは変化を制約する要素：SOA（BPM・継続的改革） ITは使いこなすもの
• ビジネス・レベルの設計には、重要なポイントがある
  1. [反復] ビジネスレベル設計（モデル化とシミュレーション）
  2. [ITレベル開発] 「IT要求」->「設計」->「実装・テスト」
  • BPMは、企業のバリューチェーンを解決するモデル
  • 最近は、企業のアジリティを解決する、という展開が主流
• ビジネスの柔軟性は、ITの柔軟性によって決定される
  • 複数のサービスやコンポーネントを組み合わせたものを「コンポジット・アプリケーション」と呼ぶ
  • SOAによって、コンポジット・アプリケーションが促進される
  • コンポジット・アプリケーションを実現することで、柔軟なITとなり、柔軟なビジネスが可能になる、というシナリオ
• 現代のアプリケーションを複雑にしている原因
  1. Value
     1. 複雑なUI
     2. 込み入った画面遷移
     3. トランザクション
     4. 永続性
  2. Agility
     1. サブシステム分割
     2. コンポーネント化
     3. 配布の必要性
     4. 数十万から数百万行のコード
  3. Integration
     1. セキュリティの確保
     2. 接続の多様性
     3. 多数のランタイム・オブジェクト
  4. Technology
     1. 拡張性の実現
     2. 信頼性の獲得
• モデリングは、現代のアプリケーションの複雑性を解決となる手法
• なぜモデリングが必要か
  1. システムやアプリケーションの複雑性を管理するため
  2. ライフサイクルの早い時点で、エラーや漏れを発見するため
  3. ステークホルダーとコミュニケーションするため
  4. 顧客の要求を理解し、確認するため
  5. システムやアプリケーションの実装を促進するため
  6. 変更時の影響範囲を明確にするため
  7. リソースが効果的にデプロイされているか補償するため
• モデル・ドリブン開発（MDD: Model Driven Development）とは
  1. ソフトウェア開発におけるアプローチの一つ
  2. 「モデル」にフォーカス
  3. 主たる成果物は「モデル」
     • プログラム・コードにはフォーカスしていない
  4. OMG（Object Management Group）では、様々なオープン・スタンダードを定義し、モデル・ドリブン開発（MDD）をサポート
• モデル・ドリブン開発（MDD）の特徴
  1. モデリング言語による抽象化
  2. モデリング・ツールによるモデルからコード生成の自動化
• モデル・ドリブン開発（MDD）に必要なこと
  1. モデルは、Machine Readableな必要がある
     • 紙に綺麗に書いたモデルでは、ツールによる自動化が出来ない
     • モデリング・ツールを使用して、属人性を排除
  2. 適切なレベルで詳細、かつ、正しいモデルを作成する必要がある
     • モデルは、段階的に詳細化されていく
     • 不正確なモデルは、モデルが無いことよりも有害
     • あまりにも概要レベル／高レベルのモデルは、役に立たない
  3. モデルは常に最新に保つ必要がある
     • 変更が発生したら、まずモデルを修正
     • 修正したモデルから、下位モデルを再生成する
• モデル・ドリブン開発（MDD）におけるTransformation
  1. モデルを変換し、後工程のインプットとなるものを生成
     • モデルから、他のモデルを生成
     • モデルから、プログラム・コードを生成
     • モデルから、ドキュメンテーション（仕様書）、ビルド用スクリプト等の、その他の成果物を生成
  2. ツールを使用して変換・生成を実施し、属人性を排除することで、上流から下流までのトレーサビリティを確保
• Transformationの例

ここまでは、ビジネス・レベル設計時にきちんとモデリングをしましょう、という話。

ここからは、よくあるSOAとはなんぞや、という話。

• SOA = サービス指向アーキテクチャ（Service Oriented Architecture）
  1. 従来のようなIT機能指向ではなく、サービスを指向しているアーキテクチャ
  2. 稼働しているサービスを統合技術を使って組み合わせ、システムを構築する考え方
• サービス = ビジネスにおいて繰り返し使用される業務機能
  1. 繰り返し可能なビジネスタスクを共通化・抽象化
  2. ビジネス的に意味のある単位で切り出した機能の固まり
• サービス化を実施することで
  1. サービスにより、ビジネス変化へのITの追従性を高める
     1. ビジネス目標、KPI
     2. ビジネス・プロセス
     3. 業務フロー
     4. 準拠すべき業務ルール
     5. etc.
  2. サービスにより、ビジネスとITの隔たりを無くす
     1. システム、サブ・システム
     2. インタフェース
     3. コンポーネント
     4. ITセキュリティ
     5. etc.
  3. サービスはどこを切り出せば再利用性が高いのか、ROIの高い開発実装できるのか、が難しい
  • SOAは、ビジネスの視点とITの視点をうまく融合させる必要がある

ここで、配付資料にはないスライドが数枚登場
デジタルカメラを持ってくればよかった。。。orz

• SOAが登場した背景：既存のITシステムの状況
  1. 「その時点でできること」を採用
  2. 案件毎／部門別の開発
  3. 変更を前提としていない開発
• サービスの定義は、立場や視点によって異なる

• SOAはビジネスとITをモジュール化で連動
  1. 「ビジネス」と「IT」の「摺り合わせ」がサービス指向アーキテクチャ

• SOAにおけるモデル・ドリブン開発（MDD）
  1. 「仕様書中心」から「モデル中心」の開発スタイル
     • モデルを段階的に詳細化
     • Transformationにより、モデル間でのトレーサビリティを確保
  2. 目指すもの
     • 属人性の排除
     • トレーサビリティ（追跡可能性）の確率
     • 部門を超えたコミュニケーションの円滑化
  3. 「ものづくり」と同じような考え方（エンジニアリング）でアプリケーションを作成
     • 部品表 => モデル
     • 部品、モジュール => オブジェクト、コンポーネント、サービス
     • 図面 => ダイアグラム
  4. 反復開発によってアーキテクチャを構築
• SOAで作成する主なモデル

• ビジネス・モデリングの目的
  1. ITの側面だけでなく、ビジネス全体の活動や情報を捉えること
     • As-Is（現状）と、To-Be（あるべき姿）の2つのモデルを作成
     • 現状とあるべき姿のギャップを把握
     • ITは、ビジネス・モデリングに含まれないのではない
     • ITは、あくまでもビジネスの一要素と位置づける
• 主なビジネス・モデリング手法
  1. コンポーネント・ビジネス・モデル（CBM）
  2. BPMN（ビジネス・プロセス・モデリング表記法）によるビジネス・プロセス・モデル
  3. RUP（Rational Unified Process）（ビジネス・モデリング）
  • これらの手法を補完的に使用
  • ビジネスをモデリング
• コンポーネント・ビジネス・モデル（CBM）
  1. 組織構造ではなく、ビジネス構造に着目して、企業全体をコンポーネント化
  2. ビジネスの構造・機能・関係を把握
  3. コア機能・経営資源配分・改革の優先度を定義
  4. 縦軸は事業領域、横軸は活動を定義
• ビジネス・プロセス・モデル
  1. To-Beのビジネス・プロセス・モデルを定義
  2. 必要なKPIやKAIを設定
  3. ツールのシミュレーション機能などにより、改善の効果を検証

APQC（American Productivity & Quality Center） PCF（Process Classification Framework）の紹介があった

• サービス・モデリングの目的
  1. SOAの主要な構成要素である、サービス、サービスコンポーネントの仕様を定義すること
     1. サービス候補の識別
     2. サービス仕様の定義
     3. サービス実現の決定
• 主なサービス・モデリング手法
  1. IBM SOMA（Service Oriented Modeling and Architecture）
  2. RUP（Rational Unified Process） - サービスモデリング
• サービス・モデリングでの主な成果物
  1. サービス・モデル
     1. サービス・ポートフォリオ
        • サービス候補のリスト
     2. サービスの階層構造
        • 領域毎のサービス候補の階層構造を表したもの
     3. サービスの依存性
        • サービス間の依存性を表したもの
     4. サービスの構成
        • 複数のサービスから成るコンポジット・サービスを表したもの
     5. サービスの非機能要件
        • サービスの非機能要件の定義
     6. サービス・メッセージ
        • サービス間でやりとりされるメッセージの仕様の定義
     7. 状態管理の決定
        • サービスがステートフルかステートレスかの決定
     8. サービス公開の決定
        • サービスとして公開するかどうかの決定
     9. サービス実現の決定
        • サービスとして実現するかどうかの決定
• IBM SOMA（Service Oriented Modeling and Architecture）
  1. IBM SOMAは、サービスモデリングのためのIBMのメソドロジー
  2. IBM SOMAにおける5つのステップ
     1. サービスの識別：再利用可能なサービスを判別して探し出し、サービス一覧を作成
     2. サービスの仕様の定義：再利用可能なサービスを公開するための仕様を定義
     3. サービスの実現：サービスをどのようなコンポーネントによって実現するか定義
     4. サービスの実装：サービスをプロセスやサービス・コンポーネントとして実装
     5. サービスの配置：実装されたサービスをSOA稼働環境へ配置
• 3つの主要なサービスの識別手法
  1. ドメイン分割（プロセス分割）
     • ビジネス・プロセスを分割していき、サービス候補を見つけ出す
  2. ゴール・サービス・モデリング
     • ビジネス目標（ゴール）を分割していき、サービス候補を見つけ出す
     • 非機能要件も含めることが大事
  3. 既存資産の分析
     • 既存業務で使用されているITシステムを調査して、サービス候補を見つけ出す
• IBMが定義しているSOA稼働環境の論理アーキテクチャ
  1. Existing Application Assetレイヤー
  2. service Componentsレイヤー
  3. Serviceレイヤー
  4. Business Processレイヤー
  5. Consumerレイヤー
  6. Integrationレイヤー（ESB）
  7. QoSレイヤー
  8. Data Architectureレイヤー
  9. Governanceレイヤー

まとめ

SOAについて多少でも知っている人にとって、今回のセッションでは特に目新しい話はなかった。

結局は、ビジネス・レベルでのモデリングと、反復的な改善がキーである。

● 日立ソフトにおけるSOAの取組み ～社内営業システムSOA化事例の紹介と日本流SOAの進め方～

日立ソフトウェアエンジニアリング（株） 通信・産業システム事業部 第2通信・産業システム本部
ユニットリーダ・プロジェクトマネージャ
北林 拓丈

• SOAとは
  1. お客様のビジネス視点から、システムを見直す設計思想
• SOAのポイント
  1. 柔軟性、再利用性、疎結合、拡張・統合性
• SOAのメリット

• SOAが注目されだした背景
  1. 相次ぐ企業の統廃合や事業再編によるIT環境統合の必要性
  2. 市場競争の激化によるビジネスニーズへの迅速な対応の必要性
  • 企業のシステムが柔軟に対応しなければならない
• IT環境の現状
  1. 異機種環境が乱立する複雑なIT環境
  2. ウォーターフォール型フルスクラッチの大規模開発
  • 改修時の影響範囲が広い
  • 仕様を決めたら後戻り出来ない
  • 改修コスト大、開発期間延長
• IT環境の現状の課題
  1. IT環境統合が進まず、企業内の業務が改善できない
  2. ビジネスニーズに対応できず、市場競争に勝てない
• SOAを実現するための技術要素の進歩
  1. ハードウェア・ネットワーク技術の進歩
     • ブロードバンドの普及
     • 高性能ハードウェアの低価格化
  2. サーバサイド技術の進歩
     • Javaや.NETによるWebアプリケーション開発の普及
  3. 高負荷でもパフォーマンスが確保でき、トランザクション、セキュリティ機能を持つ環境を容易に構築できるようになった
  4. 標準化技術の進歩
     • XMLの普及
     • Webサービス、BPELの実用化
  5. 業界標準の仕様が整備されてきたことで、異機種環境間での通信が容易になった
  • ビジネス上のニーズだけではなく、技術要素の進歩もSOA化を促進
• 業界内におけるSOA主要トピックの変遷
  1. SOAに対する認識や成熟度合いの変化
     • 単なるSOAインフラ導入やサービス実装から、BPMと絡めた企業における課題解決手段へ
     • 逆に言えば、SOA化を目的としたプロジェクトは効果がうたいにくい
     • SOA自体の効果は中長期的に見る必要がある
     • なかなかスタートが切れない
  2. 関心事が技術トピックからビジネス的トピックへ
     • ビジネス単位でサービスを切り出すには、当然ながらシステムをビジネス単位で見れる力が必要
     • 技術的な側面だけではSOAは理解できない
     • 従来の設計・実装にフォーカスしていた技術者が、ついていけない
• SOA開発プロセスガイドラインの作成
  1. システム開発標準に、反復型開発プロセス（Unified Process）を組み合わせた、SOA開発プロセスガイドラインを策定
     • 初めての人でも理解できるよう「導入編」も用意
• 業種別標準コンポーネントを用いた実記検証
  1. 業種別標準コンポーネントの有用性を確認
  2. 業務フローやデータモデルの検証も実施

• 社内システムSOA化プロジェクト開始のきっかけ
  1. 話がキレイで私達の企業にマッチするかどうかわからない
  2. 実際に導入した実績ベースで語ってもらわないと説得力がない
  3. 話としてはわかって貰えるが、実際の案件までにはなかなかならない
  4. 話が進むと、必要以上に規模が膨らんでしまい、結局開始までにものすごく時間がかかる、もしくは開始できない
  • まず社内で導入した実績を作り、それを基にSOAをアピールが必要
  1. 解決すべき課題がありそうな業務と付随するシステム
     • 課題がないのにSOA化しても効果を説明できない
  2. 解決手段としてSOAが使えそうなところ
     • 単にWeb化、自動化して済むものであれば意味がない
  3. その結果、社内営業システムをSOA化するのが効果ありそう？
• [事例] 営業プロセスを取り巻く環境の現状
  1. 各プロセス毎に個別のシステムが乱立
  2. 顧客IDがシステム毎に個別管理なので、同じ顧客の紐付けが人手
  3. プロモーションがどのくらい引き合いや受注に影響したのかわからない
• 営業プロセスに関連する課題
  1. 見込み顧客が管理されず、プロモーションがどのぐらい引き合いや受注に影響したのかわからない
  2. 各業務プロセスにおける責任の所在、対象となるアクターが誰なのかが不明確であり、問題発生時にすぐに適切な対応を取りにくい
  3. 手動で何度も入力する業務が発生したり、複数システムの画面を参照しないと、必要な情報がわからなかったり、営業の手間が増えている
  4. 今現在の営業状況がどうなっているのか、目標値に対してどれぐらい達成できているのかどうか、異常値はあるのかどうかなどが把握しにくい
  • 社内システムSOA化プロジェクトの実施によって、課題解決が可能に。
• [実施手順1] 対象業務の分析
  1. ユーザ部門にヒアリングしつつ、IDSシェアー社のARIS SOA ArchitectでAsIs業務フローを作成
     • [気づき] お客様からの問い合わせ情報をコンタクトに伝えていない（業務・データが繋がっていない）
     • [気づき] リードと引き合いの状態が、システム的・データ的に管理されていない
  2. Salesforceを活用したToBe業務フローを作成
• [実施手順2] 概要ビジネスプロセス設計
  1. 作成した業務フローから、プロセスとしてステータス管理する部分をビジネスプロセスとして切り出し、作成開始
• [実施手順3] サービスインタフェースの設計
  1. Salesforceが提供するWebサービスにアクセスして、必要となる情報を取得するためには、最初にログインWebサービスを呼び出して認証を行う必要がある
  2. 必ず複数回のWebサービス操作になるので、ESBを用いて、一連のWebサービス呼び出し操作をまとめて、一つの仮想的なWebサービスとして呼び出し側に提供
  3. Salesforceは既にWSDLが公開されているので、こちらの業務に合う形で、インタフェースを設計し直し
  4. 既存アプリケーションは、必要となる形でインタフェースを設計
  5. DBアダプタの場合は、必要となる情報を取得するためのSQLを検討=>結果を元にインタフェースを設計
• [実施手順4] 詳細ビジネスプロセス設計
  1. FaultをCatchした際の挙動（例外系の処理）を追加
  2. サービス呼び出し間の変数受け渡し処理を詳細化
  3. ダッシュボードで表示させるために取得・保持する情報を確定
• [実施手順5] サービス・ビジネスプロセス実装／テスト
  1. サービス実装にかかったコストはほとんどなし（ビジネスプロセス／ESBとしての設定でほとんど対応）
  2. サービス単体は、WSDLからWebサービスクライアントを生成し、JUnitでテストを実施
  3. ビジネスプロセス、バッチ起動によるシナリオテストや多重起動テストを実施
• 導入後の成果

• 日本流SOAの進め方
  1. ユーザ部門の参加が必須
     • 欧米では・・・CEOやCIOの号令により、ユーザ部門参画指示（トップダウン型）
     • 日本では・・・現場の合意ありきのボトムアップ型意志決定
       • 現場での説得の必要がある
• ユーザ部門参画時の問題点
  1. SOA（サービス化）による具体的なメリットを感じて貰いにくい
     • IT環境統合というだけでは、なかなか訴えない
  2. サービスは目に見えないので、具体的に何が実現できるのかがわかりにくい
     • IFやビジネスプロセスを見せても、実際の利用シーンが思い浮かばない
  3. ユーザ部門が目に見えて嬉しい画面や情報、機能など、わかりやすい成果物を併せて提供すると、説得しやすい
• SOAの開発アプローチ
  1. トップダウンアプローチ
     • 対象となるドメインのビジネスモデリング（例：業務フロー作成）を行い、個々のビジネスプロセスをサービス化
     • ビジネスフロー全体は、BPELで記述されていることが望ましい（必須ではない）
  2. ボトムアップアプローチ
     • 既存システムからサービス及びIFを切り出し、それらを連携させて一つのアプリケーションを構築
     • 既存システムのサービス洗い出し作業が必要
  3. トップダウンで始めるのは、相応のスキルが必要。
  • 日本においては、まず見えているところをボトムアップで始めるのも手（ただしユーザ部門の理解は得にくい）
• データモデルの整理
  1. 業務を分析し、フローを記述する際に、データモデルの整理も併せて行う必要がある（まずは概念データモデルから検討）
  2. これを行わないと、サービス同士がビジネスプロセスで繋げなかったり、コンポジット時にマッピングできなかったりするケースが発生する
  3. 本プロジェクトでは、引き合い以降のデータモデルについて、フェーズ2にて再度整理（見積システム再構築時にデータモデルを再度検討中）
  • サービスを考える前に、データモデルの整理をする必要がある
  • 業種によっては、業界標準データモデルを参照モデルとして活用とする
    • ただし、そのまま合わせようとすると日本の場合は難しい
• サービス粒度の決定
  1. 単独で業務を満たせないもの => 複数サービスを組み合わせてコンポジット
  2. 戻りの方が抽象的であるもの => 具体的な片付けをしたサービスを個別定義
  • 画面があるものは、画面の単位が粒度として考えやすい
• SOAと反復型開発プロセス
  1. SOAに限らず、ユーザ部門をうまく惹きつけるためには、早期の開発成果物のレビュー、フィードバックが必要
  2. SOAにおいては、ビジネスプロセスやサービス粒度決定の早期着手、サービス開発、テスト、管理手法の早期確立によって、ビジネスプロセス・サービス個数が増加した場合の工数を知恵源、開発を効率化する
  3. ウォーターフォールであっても、プロジェクトの成功のためには早期プロトタイピングが必須=>開発プロセスとして管理できた方が効率的
  • 特にサービス粒度決定に当たっては、一度では決まらず、何度となく施行することとなる
  • 反復型開発によって開発プロセスとして繰り返すことを管理できる手法が効率的
• SOAと反復型開発プロセス
  1. 反復型開発と契約形態
     • 初期からの一括請負契約では、反復型開発を採用するのは難しい
     • 要件や計画の変更に対応する開発プロセスを取ったとしても、変更をあまり許容しない契約形態がそれを阻む
  2. 工事進行基準の施行が、反復型開発の追い風となる
     • 反復型開発（UP）での契約形態例

• BPEL（ビジネスプロセスエンジン）に任せる範囲
  1. 人手の作業が残る前提で、ビジネスプロセスを構築する必要がある
  2. 業務の性質によって、ヒューマンワークフローの位置づけを考える必要がある
  3. バージョンアップ処理をプロセス毎に検討する必要がある
     • ビジネスの変化に強いSOAではあるが、ビジネスプロセスエンジンはまだ、そこまで変化には強くない
     • 開発側だけでは挙動や制御方法がわかりにくいところが多く、ベンダーの手厚いサポートが現状では必須
• 今後の展望
  1. 来年あたりから、効果や今後のビジネス基盤としてのSOAの価値が問われてくるはず
• 今後期待すること
  1. SOA製品の成熟
     • 使いやすい、ハイパフォーマンス、運用上の柔軟性、より変化に強く、スケールアウト対応、価格
  2. 反復型開発の増加
     • 工事進行基準に期待
  3. BPELやWebサービス、SCA等標準化の更なる促進