Oracle Open World 2009 3日目に参加してきました。

更新日：

Oracle Open World 2009 3日目に参加してきました。
http://www.oracle.co.jp/openworld/2009/index.html

今回参加したセッションは、下記の通りです。

Oracle Open World 2009 3日目 参加レポート

日時場所

2009/04/24（金） 09:30-20:00 国際フォーラム＠有楽町

11:30～12:20 BEA｜Oracleが提供するSOA基盤の圧倒的実力、圧倒的コスト削減効果

Oracleが目指す企業情報システムのToBeモデル

  • 外部環境の変化に対応する企業情報システム
    • ビジネス・プラットフォーム（組織／事業部を超えて、ビジネスアプリケーション群と既存資産をつなぐ）
    1. ビジネスの変化に対応する情報システム、とずっと私達は言ってきている。
    2. ところで言い続けて何年経ってますか？7年経っていますよね。
    3. つまり、7年間何も変わってない？
    4. 何も変わっていないことはない、実は企業にSOAは浸透してきている。
    5. 経営陣と情報システムとの間には、まだまだ差がある。
  • 問題解決に向けたアプローチの例
    1. これまでは、増築、改築の繰り返し
  • ITに求められる変化対応力とは
    • 従来の課題
テーマアップ 要件整理 影響範囲分析 仕様策定 設計・開発 テスト サービスイン
業務、ITのコミュニケーションギャップ 影響範囲の分散により、影響度分析に時間がかかる 影響範囲が広いため、多くの開発工数がかかる
  • テクノロジー/方法論でリードタイム短縮
テーマアップ=> <=サービスイン
  • 開発リードタイム短縮
    1. 重複作業の排除
    2. アーキテクチャの標準化
    3. 実装方式の標準化
    4. システムの可視化
    5. 業務/IT間の円滑な意思疎通
  • 機能要件を分類しておくことで、具体的な実装方法をパターン化し、スピーディーな実装を実現する
  • オラクルが目指す問題解決に向けたアプローチ
    1. 他社との優位性が求められる機能を分類する（カテゴリ１～３）
      1. C1：共通要件
      2. C2：他社との差別化要件
      3. C3：部門・地域限定要件
    2. 会社全体で分類分けを実施することが必要
  • プラットフォーム型アプリケーション
柔軟性向上 ガバナンス徹底
開発生産性向上
  • 「作らない」企業情報システムの追求
    • テーマアップあらサービスインまでの開発リードタイムを短縮するポイント
統一プラットフォーム環境 管理ツールによる統合管理
ひな形となるテンプレート テンプレートの利用
作らない開発、完全性の高い統合開発環境 パッケージの有効利用、組み合わせ開発
  • 方式別のスピード感の違い
  • オラクルの事業戦略 Innovation & Acquisition
  • オラクルがお届け出来る価値
  • システムに求められる要件
    1. 業務の可視化とモニタリング
    2. 全社レベルの最適化へ
    3. システム固有の違いを吸収する
    4. 疎結合化

以降の話は、2日目のセッションとスライド・内容共に全く同じだったため、省略

  • BPMの実現を目指す製造業のお客様の例
  • 本当にお客様がやりたかったこと
    1. 経営レベルのハイレベルの粒度
    2. 実装レベルのプロセスまで階層構造
  • まとめ
    1. 投資対効果の最大化と、変化対応力の両立を目指し、SOAを利用した「作らない企業情報システム」を実現

12:50～13:40 SOAプロジェクト日誌 - コスト削減・生産性向上・品質確保の記録　

SOAとは？

  • [Q} SOAに対する期待
    1. [A] 市場の変化への迅速な対応
    2. [A] 組織の変化への迅速な対応
    3. [A] システム観連携
    4. [A] 社外システムとの連携
    5. [A] 既存システム資産の有効活用
    6. [A] 開発期間の短縮
    7. [A] 開発コストの短縮
    8. [A] 保守の簡素化
  • [Q] SOAで実現出来る結果
    1. [A] データ統合
    2. [A] マスター統合
    3. [A] アプリケーション連携
    4. [A] レガシー連携
    5. [A] システム間バッチ連携の自動化
    6. [A] ワークフロー
    7. [A] リアルタイム監視
    8. [A] コンポジット・アプリケーション
  • [Q] 様々なカットでSOAは語られる
    1. [A] 統合・連携
    2. [A] 柔軟性・可変性
    3. [A] 再利用性
    4. [A] 可視化・監視
  • [Q] SOAに対する視点の違い
    1. 直接的目的
    2. 間接的目的
    • 経営者
    • ビジネス部門
    • IT部門
  • SOAに関連するTechnology
    • Adapterを経由することであらゆるテクノロジーを仲介することが可能

SOAプロジェクトを成功させる3つのポイント

  1. Objective、Priorityの明確化
    • すべての目的を一度に達成することは困難
    • 目的、Goalの優先順位付けが必須
    • 長期的、短期的な視点
    • 繰り返し、継続、カイゼンが必要（PDCA）
  2. Architecture-Centric
    • 「統合・連携」を可能とするアーキテクチャ
    • 「柔軟性・可変性」を保持するアーキテクチャ
    • 「再利用」を促進するアーキテクチャ
    • アーキテクチャの「可視化」
    • アーキテクチャの「標準化、共通化」
    • 「繰り返し、継続、改善」出来るアーキテクチャ
  3. 繰り返し、継続、改善出来るアプローチ、方法論
    • 業界標準の方法論（UP,UML,PMI）とOracleの経験値を融合させた「Oracle Unified method」
    • OUMの5つの大原則
      1. Iterative and Incremental 繰り返し＆継続改善出来るアプローチ
      2. Architecture-Centric 長期的＆継続的に改善できるアーキテクチャ
      3. Fit-for-Purpose 目標に併せたもの
      4. Business Process and Use Case-Driven
      5. Risk-Focused
  4. Oracle Unified Method(OUM)とは？
    • 業界標準の方法論とOracleに蓄積された経験値を融合
    • すべてのOracle Productsをサポート
    • 5つの原則に基づくアプローチ
  5. OUMアプローチの採用メリットについて
    • 再利用が促進される
    • 継続的、反復的なテストの実施により、プロジェクトステータスの客観的・定量的な評価が早期に可能
  6. POC、スモール・スタート

Architecture-Centric

Oracleが提案するSOAのリファレンス・アーキテクチャ

  • SOA標準アーキテクチャ
業務ドメイン：コンポジット/アプリケーション
プレゼンテーション層
プロセス層
サービス連携層
サービス層
ビジネスロジック層
データアクセス層
データベース層
サブシステム
  • Bad use case of SOA Projects...
    1. プロセス層、サービス連携層を介したアプリケーションにて障害が発生
    2. 調査した結果、2つのBPELプロセスで実装されており、各プロセスは複数のシステム及びアプリケーションと連携
    3. 1つのプロセス内でDBアダプタが利用されていることがわかった
    4. 詳細なログを調査したところ、タイムアウトが発生している模様
    5. どういった連携パターン、処理方式を採用しているかは、開発担当に聞かないとわからない
    6. トランザクション制御がどうなっているかもわからない
  • Oracleが提案するSOA標準アーキテクチャ
    • SOAはXMLにてメッセージを送信するが、そのメッセージの共通オブジェクト（EBO）を中央に定義
    • ビジネスデータを標準化、共通化した共通オブジェクトを定義（例：顧客、契約、品目）
    • 共通オブジェクトを介したシステム連携を実現することにより、各システムの疎結合を推進
APP1 サービス連携層 APP2
UI UI
RequestorApp 共通サービス(EBS) ProviderApp
Data 共通オブジェクト（EBO） Data
  • 共通サービスと各サービスの間に「連携元/連携先コネクタサービス（ABCS）」を中継
Requestor App 連携元コネクタサービス 共通メッセージ 共通サービス 共通メッセージ 連携先コネクタサービス 連携先アプリケーション
  • SOA標準アーキテクチャの柔軟性・再利用性
    • 各Requestorに対する共通サービスが1つ
    • 1つの共通サービスを保守
    • 変換が必要なRequestorに対してはコネクタサービスにて対応
  • ビジネスプロセスとSOA標準アーキテクチャ
Requestor サービス連携層 プロセス層 サービス連携層 Provider
共通サービス ビジネス・プロセス・サービス 共通サービス Provider App

デザイン・パターンの選定と標準化

  • 策定したリファレンス・アーキテクチャに基づくデザイン・パターンの選定、標準化が必要
  • 選定されたデザインパターンを実装対象となるユースケースとマッピングし、実装アーキテクチャのガバナンス、可視化を図る
  • デザインパターンの主な抽出ポイント
    1. 連携方式（ex.同期/非同期、一方向/双方向）
    2. 接続方式（ex.SOAP、JMS、MQ）
    3. 処理パターン（ex.参照、更新）
    4. 技術要素（ex.BPEL、OSB、ODI）
    5. アプリケーション・アーキテクチャ

リファレンス・アーキテクチャを実装するOracleのTechnology

  • Oracle SOA Technology and AIA
    • AIA FPにて提供される共通オブジェクト
      • 特定業種向けを含む約70個のオブジェクト

SOAによるシステム実装上のKey Topics

  • 大量データ向けのSOA標準アーキテクチャ
    • 大量なPayloadを伴うシステム連携基盤としてODI（Oracle Data Integrator）の利用を検討
  • サービス・コンポーネント化とアクセス・パス
    • SOAのアーキテクチャのメリットを享受するためには、サービス連携層を介したサービスの公開が可能となるアプリケーション実装が必要となる（サービス・コンポーネント化）
    • サービス・コンポーネントへのアクセス・パスとして、サービス連携層による中継の有無は一つの検討ポイント
    • 主に以下のポイントに関するトレードオフを考慮し、検討・決定が必要
      1. IT戦略（Objective、Priority）
      2. ・・・
  • サービス粒度の検討における主な考慮事項
    • 2つの視点
      1. ビジネス視点、IT視点
      2. サービス利用者と提供者
    • 再利用性、柔軟性、可視化
    • トランザクション単位
      1. グローバル・ローカル
      2. 補償トランザクション
    • 保守性、エラー対応
    • 性能、Payload
  • 上記を踏まえた、サービスの集約と分割を検討（細粒度）
  • サービス粒度に関する基本方針
    • サービス内でトランザクションは完結する
  • サービス粒度とコンポジット・サービス
    • コンポジットサービス作成の検討
      1. 既存サービスの再利用・有効活用
      2. トランザクション制御の簡素化
      3. 補償トランザクションの回避
      4. 性能、キャパシティ、Payload
  • サービス粒度とSOA標準アーキテクチャ
    • Oracleが提案するSOA標準アーキテクチャでは、サービス（Provider App）に対応する共通オブジェクト、共通メッセージ、共通サービスを定義

-Blog

Copyright© fullvirtue.com プロダクトオーナー支援スペシャリストのBlog , 2024 All Rights Reserved.