EA(エンタープライズアーキテクチャ)とSOA(サービス指向アーキテクチャ)

EA(エンタープライズアーキテクチャ)と SOA(サービス指向アーキテクチャ) 2005/2/21 by sasaki@pochi.cc 1

発表の流れ ◼ 背景となる技術的要素について ◼ ◼ ◼ ◼ エンタープライズアーキテクチャについて ◼ ◼ ◼ アーキテクチャ 階層構造 コンピュータシステムの本質 概要 行政における取りくみについて サービス指向アーキテクチャについて ◼ 2005/2/21 概要 by sasaki@pochi.cc 2

背景となる技術的要素について ◼ ◼ ◼ アーキテクチャ 階層構造 コンピュータシステムの本質 2005/2/21 by sasaki@pochi.cc 3

アーキテクチャとは？ ◼ ◼ ◼ 辞書的には「建築（学）」や「構造」 ハードウェア等の「基本設計」、という意味 で使われる。 様々な文脈で様々な物を指す。 2005/2/21 by sasaki@pochi.cc 4

アーキテクチャの例 (CPUアーキテクチャ) ◼ ◼ ◼ ◼ ◼ ◼ ◼ ◼ データ幅(bit数) CISC、RISC データと命令を一緒に扱う？分離する？ レジスタの数 命令の対称性 キャッシュ I/O ※「命令セットの仕様」のことのみを指す場合もある ◼ インテルアーキテクチャ、MIPSアーキテクチャなど 2005/2/21 by sasaki@pochi.cc 5

アーキテクチャの例 (ハードウェアアーキテクチャ) ◼ ◼ CPUには何を使う？ バスに何を使う？ ◼ バス毎にもアーキテクチャがある ◼ メモリ ストレージ(ハードディスク) 外部インターフェイス グラフィックカード ◼ ※典型的なアーキテクチャには名前が付いている ◼ ◼ ◼ ◼ 2005/2/21 PC互換機アーキテクチャ、SPARC システム by sasaki@pochi.cc 6

アーキテクチャの例 (システムアーキテクチャ) ◼ 典型的なウェブデータベースシステム 負荷分散装置 ウェブサーバ データベースサーバ 大容量ストレージ 2005/2/21 by sasaki@pochi.cc 7

アーキテクチャの例 (ソフトウェアアーキテクチャ) ◼ 典型的なウェブデータベースシステム ウェブアクセス CGIプログラム バックエンドロジック データベース 2005/2/21 by sasaki@pochi.cc 8

アーキテクチャの例 (業務アーキテクチャ) ◼ 流通業モデル 商品仕入れ 営業活動 販売 2005/2/21 by sasaki@pochi.cc 9

アーキテクチャの例(その他) ◼ ◼ ◼ ◼ ◼ ◼ クライアント・サーバ・アーキテクチャ .NETアーキテクチャ TCP/IPアーキテクチャ 企業内のテクノロジー標準の意味で使う アプリケーションの共通基本設計の意味で使う デザインパターンの意味で使う 2005/2/21 by sasaki@pochi.cc 10

アーキテクチャのまとめ ◼ ◼ ◼ アーキテクチャとは、「システムの組織的な構造」 という意味で使われる。 アーキテクチャ、という言葉は様々な文脈で様々 な物について使用される。 どの文脈で使っているかを正しく理解しないと思 わぬ誤解を生むことになる。 ◼ ※他のコンピュータ用語でも同じような例がある。 ◼ 2005/2/21 ウェブ、サービス など by sasaki@pochi.cc 11

階層構造モデル ◼ ◼ システムを階層構造で捉えることにより構 造的に考えることができるようになる。 ネットワークにおけるOSIの7層モデル等で 有効性が広く認知された。 2005/2/21 by sasaki@pochi.cc 12

階層構造の例 (ネットワークアーキテクチャ) アプリケーション層 プレセンテーション層 セッション層 トランスポート層 ネットワーク層 MAC層 物理層 2005/2/21 by sasaki@pochi.cc 13

階層構造の例 (マネージメントシステム) 組織の経営方針、経営理念 情報セキュリティ マネジメントシステム （個人情報を含む） 方針 目標 情報セキュリティに対する、経営方針 ルールを管理・ 改善する仕組み 教育、監視、監査、問題発見、 環境変化への対応、経営陣による見直し等 技術を管理するルール セキュリティの技術 2005/2/21 下記技術に関する各種規定 ネットワークセキュリティ 物理的セキュリティ（施設、安全） 人的セキュリティ（教育、守秘） 業務上のセキュリティ（外注管理等） by sasaki@pochi.cc 14

階層化のメリット ◼ ◼ 階層毎に扱う情報を限定できる。 階層毎に扱う処理を限定できる。 ◼ ◼ ◼ →実装が容易になる 全体では高度な処理が可能 各レイヤを自由に交換可能。 ◼ ◼ 2005/2/21 インターネットにおいては、アプリケーションのプロトコ ルを変えるだけで様々な処理を実現 インターネットでは1、2層目を高速化することにより20 年以上も同じプロトコルを利用できている。 by sasaki@pochi.cc 15

コンピュータシステムの本質 ◼ ◼ コンピュータシステムとは何物なのか？ コンピュータシステム発達について 2005/2/21 by sasaki@pochi.cc 16

コンピュータシステムとは何か (論理的背景)？ ◼ ◼ ◼ ◼ ◼ 数学(論理学)から誕生したもの アルゴリズムを実行する情報機械 何かをインプットし、何かをアウトプットする 学校でやった「関数」のイメージに近い 現在のシステムは、そのような生の姿を隠してい る場合が多い。 ◼ 2005/2/21 見方によっては、この世の万物すべてを情報機械とと らえることも実はできる。 by sasaki@pochi.cc 17

コンピュータシステムとは何か (技術的背景) ◼ ◼ 論理学の成果を、数学、物理学(量子力学、 電気学)、工学(通信工学、生産技術)、社 会学(教育、認知心理学)、などの様々な技 術や学問により実装したもの。 幅広い技術から成りたっている。 2005/2/21 by sasaki@pochi.cc 18

コンピュータシステムの限界 ◼ ◼ ◼ ◼ ◼ ◼ 数学的限界 : 計算できないものは実行不能 物理学的限界 : 光の速さは超えられない 社会学的限界 : 人が使う部分がボトルネックに なる リソース的限界 : 資源、時間は有限 万能ではない。 万能ではないことを認識した上で利用する。 2005/2/21 by sasaki@pochi.cc 19

歴史的背景 ◼ ◼ ◼ コンピュータの捉え方は時代ごとに変わっ てきた。 利用ターゲット、開発手法などにより捉え 方が決定されてきた。 人間は近視眼的に物を見る傾向がある。 ◼ 2005/2/21 道具が思考を限定してしまう by sasaki@pochi.cc 20

手続型言語の時代 ◼ ◼ ◼ ◼ ◼ Fortran、COBOLなどの手続型言語が開発の主 力となっていた時代。 情報の処理手順を記述する。 流されるデータが決まっていて、処理したいこと も決まっている。 扱うデータは少なく、処理も単純 コンピュータはデータを処理する機械である、と 捉えられていた。 2005/2/21 by sasaki@pochi.cc 21

オブジェクト指向の時代 あるいはGUIの時代 ◼ ◼ ◼ ◼ オブジェクトという概念が一般化した時代。Smalltalkなど が切り開き、JavaやVBなどの開発言語により概念が広 まった。 情報をオブジェクトと捉え、処理はオブジェクトの性質とし て記述される。 実社会を比喩的に表現することができ、人間が感覚的に 利用するためのインターフェースを実現。した。 コンピュータは文房具のような道具の高性能なもの、と捉 えられていた。 2005/2/21 by sasaki@pochi.cc 22

ネットワークの時代 ◼ ◼ ◼ ◼ インターネットが一般化し、HTMLや電子メールが使われ るようになった時代。 情報は通信により得られるものと捉え、処理は通信の一 部として記述される。 情報を流通させる基盤が共通化されることにより、コミュ ニケーションが加速。必要な情報へすぐに到達できること による進化の加速。 コンピュータはコミュニケーションツール、情報収集ツー ルと捉えられている。 2005/2/21 by sasaki@pochi.cc 23

セマンティックWebの時代 ◼ ◼ ◼ ◼ ネットワークによる流通される情報を、システムが収集加 工し、人にとってより便利な情報を集めることができるた 時代。 システムどおしがネットワークを介在し積極的に情報交 換を行なう。人間が仲介しないため劇的にスピードアップ。 人間が直接目に触れる1台のシステムの裏側では多数 の別のシステムが協調し動作を行なう。 コンピュータは生活のために必要な社会インフラとなる。 2005/2/21 by sasaki@pochi.cc 24

コンピュータシステムのまとめ ◼ ◼ ◼ ◼ ◼ 実社会におけるコンピュータシステムの適用範囲は広がっている。 限定された用途から、社会インフラに成長 しかしコンピュータの限界がなくなるわけではない。 本質は変わらない。 ◼ 情報処理機械 ◼ インプットがあり、アウトプットがある 今後さらに重要になってくること ◼ インプットできるオリジナル情報。 ◼ オリジナル情報が資産になる。 2005/2/21 by sasaki@pochi.cc 25

EA エンタープライズアーキテクチャ ◼ ◼ ◼ ◼ ようやく本題 EAとはなにか EAが必要な理由 EAの具体例 ◼ 2005/2/21 政府における取り組み by sasaki@pochi.cc 26

EAとは何か ◼ ◼ ◼ ◼ ◼ 組織、業務的視点からシステムを分析・再構築 する手法。 組織（enterprise）の構造と機能をある一定の考 え方・方法で包括的に体系化 全体と構成要素の相互関係を明確化 構造の背景にある基本理念・設計思想を含めて 企業活動の全体最適を実現を指向 あるべきモデル（To Be）を目指して、長期的かつ 体系的に行われる 2005/2/21 by sasaki@pochi.cc 27

EAの誕生 ◼ ◼ ◼ ◼ 1987年にジョン・A・ザックマン（John A. Zachman）がIBM System Journalに発表した「A Framework for Information Systems Architecture」という論文。 ここに示された枠組みが「ザックマン・フレーム ワーク」 情報システムを対象としていたが、1992年に組 織そのものを対象とするように拡張。 米国においてはEAフレームワークのデファクト・ スタンダーになっている 2005/2/21 by sasaki@pochi.cc 28

EAの考え方 ◼ 4層の視点から業務を分析し整理を行なう 政策・業務体系 データ体系 適用処理体系 技術体系 2005/2/21 by sasaki@pochi.cc 29

EAが必要な理由 ◼ ◼ ◼ ◼ 部門毎にシステムが存在し、機能が重複し ていることによる投資の無駄をなくしたい システムにかかわる技術や用語を統一す ることで混乱を避けたい トップダウンによるシステム、業務の見直し を行なうことにより戦略を実現したい 部分最適ではなく全体最適を実現するた めには統一的な枠組みが必要 2005/2/21 by sasaki@pochi.cc 30

EAのポイント ◼ ◼ ◼ ◼ ◼ ◼ EAは組織戦略そのもの 全体最適を重要視 実現テクノロジーはそれほど重要ではない 無駄を省き、投資効率の最適化をはかる 経営とシステムを結合させるための手段 現状のシステムの検証だけでなく、よりよ いシステムへの改善を指向している 2005/2/21 by sasaki@pochi.cc 31

具体的なEAの導入方法 ◼ フレームワークを導入するのが一般的 ◼ ◼ 枠組み／ガイドラインを用いて実際の組織の 構成要素をあてはめていく 具体的な進め方 ◼ 2005/2/21 経産省(ITアソシエイト協議会)資料参照 by sasaki@pochi.cc 32

政府における取り組み ◼ ◼ ◼ 電子政府の実現のため「ITアソシエイト協 議会」を設置 EAの導入を推進することを決定。 成果物(一部配布) ◼ 2005/2/21 http://www.meti.go.jp/policy/it_policy/itaso ciate/it.associate.htm by sasaki@pochi.cc 33

• http://www.meti.go.jp/policy/it_policy/itasociate/it.associate.htm

政府によるEAの定義 ◼ ◼ 電子政府の構築にかかわる関係者がその政策・ 業務ごとに必ず共有しなければならない知識を 参照しやすく整理したもの 知識共有を促進するために必要なもの ◼ ◼ ◼ ◼ ◼ 2005/2/21 制度化 参照知識の整備 Web化 研修 コーチング by sasaki@pochi.cc 34

EAについてのまとめ ◼ ◼ ◼ EAは哲学。 コンピュータを支える様々な考え方の1つと して押さえておくべきもの 具体化についてはまだ発展途上 2005/2/21 by sasaki@pochi.cc 35

SOA サービス指向アーキテクチャ ◼ ◼ SOAとはなにか。 SOAの背景。 2005/2/21 by sasaki@pochi.cc 36

サービスとは ◼ リクエストに対して提供される何らかの機 能。 通信の考え方がベースになっている。 ◼ (例)ブラウザからウェブを見る場合 ◼ ◼ ◼ 2005/2/21 ブラウザが特定のディレクトリの情報を送るよ うにウェブサーバにリクエスト ウェブサーバはブラウザに情報を送信 by sasaki@pochi.cc 37

従来型サービスの例 ◼ メール送受信 ◼ ◼ 時刻同期 ◼ ◼ メールクライアントがメールサーバにrequest 時刻を同期したいPCがサーバに時刻を聞く データベースリクエスト ◼ 2005/2/21 データベースにある特定の情報をデータベー スサーバにrequest by sasaki@pochi.cc 38

従来型サービスの問題点 ◼ ◼ ◼ Request を出す側、受ける側、ともに専用 の実装がされている Requestの手順やサービス手段はサービ スによって異なる 統一フレームワークがあると便利 ◼ 「Webサービス」フレームワーク ◼ 2005/2/21 通信の一部分を共通化 → 大きなメリット by sasaki@pochi.cc 39

Webサービスの技術的ポイント ◼ ◼ 既存の技術を活用 通信はWeb技術がベース ◼ ◼ データ形式はXMLを利用 ◼ ◼ TCP/IP および HTTPを利用 XMLによるデータのカプセル化を行なう データの中身については各アプリケーションが実 装を行なう。 ◼ 2005/2/21 ある程度のデータ型はW3Cで定義が行なわれている by sasaki@pochi.cc 40

Webサービスのメリット ◼ システム間での連携を取ることができる ◼ ◼ ◼ ◼ RPCなどのプロセス間通信と考え方は一緒 ウェブ技術を使っているためインターネット を介しての利用が可能 広範囲な用途に利用可能 標準化された技術を元にしており、サービ スを部品化が可能 2005/2/21 by sasaki@pochi.cc 41

Webサービスの例 ◼ Amazon ◼ ◼ Google ◼ ◼ Googleの検索エンジンの様々な機能を利用可能 .NETテクノロジー ◼ ◼ Amazonの機能を外部から利用可能 システム間の連携をWebサービスで簡単に構築可能 SalesForce.com ◼ 2005/2/21 ASPと外部システムとをWebサービスで連携 by sasaki@pochi.cc 42

SOAとWebサービス ◼ SOAはWebサービスとセットで捉えるのが 一般的 ◼ ◼ 個々のシステムは、requestに対してなん らかのサービスを提供するもの、と考える ◼ ◼ ただし概念的には別 Input : request / Output : サービス 業務プロセスは個々のシステムがWeb サービスにより連携を行ない実現される。 2005/2/21 by sasaki@pochi.cc 43

SOAの概念図 2005/2/21 by sasaki@pochi.cc 44

SOAのメリット ◼ ◼ ◼ システムが実現するビジネス・プロセスを「サービ ス」と見なすことにより、ビジネス・プロセスの構 築を非常に柔軟にできる サービスは必ずしも自社でインストール＆カスタ マイズする必要はない 利用可能なサービスが存在する場合には、イン ターフェイスのみ用意すれば良いので短期間、 低コスト、低リスクでシステム追加が可能 2005/2/21 by sasaki@pochi.cc 45

SOAのビジネス的インパクト ◼ ◼ オフショア・アウトソーシングと並ぶプログ ラマーへの脅威として位置付けられている SOAはアウトソーシングの活用を促すIT アーキテクチャである 2005/2/21 by sasaki@pochi.cc 46

SOAについてのまとめ ◼ ◼ SOAは業務をサービスのまとまりとして捉 える SOAの考え方で構築されたシステムは柔 軟性が非常に高い 2005/2/21 by sasaki@pochi.cc 47

まとめ ◼ ◼ ◼ ◼ EAとSOAという新しい考え方について説明を行 なった アーキテクチャという単語は同じだが視点は違う コンピュータシステムは捉え方により様々な見方 ができる システム、業務に関して、柔軟な視点を常に持ち、 変革に対処し続けなければいけない 2005/2/21 by sasaki@pochi.cc 48