データマネジメント知識体系(DMBOK)第8章「データ統合と相互運用性」概説

しばたー

基本的な考え方

データ統合と相互運用性とは
データストア、アプリケーション、組織などの内部とそれらの相互間で実行される、データの移動と統合を管理する

ビジネス上の意義

  • データの移動を効率的に管理する

    • 組織には数多くのデータベース・データストアが存在し、その間のデータの移動の管理がIT組織の重要な任務である

    • 適切に管理されていないと、データ移動がITリソースや能力を圧迫してしまう

    • 標準的なツール・インタフェースの導入により維持費用を削減する

  • データの取り扱い標準と規則を遵守できる

    • コンプライアンス規則に準拠するプログラムが再利用でき、コンプライアンスの検証を簡素化できる

ゴールと原則

ゴール

  • 人とシステムそれぞれが必要とするフォーマットと時間枠でデータを提供できるようにする

  • データを物理的及び仮想的にデータハブに集約する

  • モデルとインタフェースを開発し共有することでソリューションを管理する費用と複雑さを削減する

  • 重要なイベント（機械と脅威）を特定し、自動的にアラートとアクションを起動する

  • ビジネスインテリジェンス、アナリティクス、マスターデータ管理、業務効率化の取り組みをサポートする

原則

  • 設計上は将来の拡張性を確保するために全社視点が必要

  • 実装は反復的かつ段階的に行う

  • 担当部署のデータニーズと全社的データニーズのバランスをとる（サポートと捕手の視点も含むこと）

  • 業務専門家が関与すること

本質的な概念

ETL（抽出、変換、ロード）

  • Extract（抽出）

    • ソースから必要なデータを選択、抽出する

    • ステージングデータストア（ディスク or メモリ）に格納する

  • Transform（変換）

    • フォーマットの変更（EBCDIC→ASCII）

    • 構造の変更（非正規化レコード→正規化レコード）

    • 意味的変更（性別コード 1 → Male）、重複排除、並び替え

  • Load（ロード）

    • ターゲットシステムに格納または提供する

レイテンシ

レプリケーション

  • データベース管理システムの機能により、複数の物理的な場所にデータの複製を保持する

  • 異なるロケーションのアプリケーションを短時間で応答するため

  • 準リアルタイムでのコピーが可能

  • 通常、データセットの変更ログを受け渡す（データセット自体ではない）

アーカイブ

  • 利用頻度が低い、現在あまり利用されていないデータをよりコストのかからないデータ構造、場所に退避する

エンタープライズ・メッセージフォーマット / カノニカルモル

  • 企業全体で共通となるメッセエージフォーマット

  • カノニカル (Canonical) とは「聖典の、標準的な」という意味

  • ハブ＆スポーク型の全社でーっ統合を試みる際には必要となる

データ連携モデル

DIIアーキテクチャの概念

アプリケーションカップリング

  • カップリングとは2つのシステムが関連しあう結合度合いのこと

  • 可能であれば疎結合が望ましい

    • 応答を待たずにシステム間をデータがやりとり

    • 一つのシステムが利用できなくても他のシス テムは利用できる

  • 密結合の場合、両方の事業継続性を揃えることが必要

オーケストレーションとプロセスコントロール

  • オーケストレーションとは複数のプロセスがシステム内でどのように構成され、実行されるかを表す

  • プロセスコントロールはデータの発信、配信、抽出、取込が正確かつ完全であることを保証するため に必要な要素

エンタープライズアプリケーション統合(EAI)

  • 定義された インターフェース呼び出し (API) だけを介して連携する

エンタープライズ・サービスバス(ESB)

  • システム間の仲介役として機能し、システム間でメッセージをやりとりするシステム

サービス指向アーキテクチャ(SOA)

  • 予め定義したサービスを呼び出すことで、データ提供・更新を行う方式

    • 呼び出す側は、サービスの内側のシステム機能を知る必要がない

  • 開発したサービス・APIはカタログに定義する

    • APIの再利用・スケーラビリティ向上のためにAPIの設計・登録にガバナンスを聞かせるべき

複合イベント処理(CEP)

  • 発生した事象（イベント）に関するデータを追跡・分析し、結論を引き出す処理

  • 事例: 

    • クレジットカードの不正利用検出

    • 消費者行動に応じた製品の提案

  • 対象イベント・データの例: 

    • 顧客行動: ウェブクリック、注文…

    • 公的データ: 天気、SNS、株式…

データフェデレーションと仮想化

  • 物理的に馬場署や構造が異なるデータストア軍のデータを、仮想的に単一のアクセス方法でアクセス可能とする技術

データ・アズ・ア・サービス(DaaS)

  • ベンダーがライセンス提供 し、必要に応 じてデータを 提供する形態

クラウドベースの統合

  • IPaasと呼ばれるクラウドベースのシステム統合の形態

    • DMBOKではIPaaSと表記されているが一般にはiPaaSの表記

    • また、一般的な説明としては「異なるアプリケーションやデータソースを統合するためのプラットフォームで、ンプレミスとクラウドのアプリケーション、データ、およびプロセスをシームレスに接続するためのソリューション」と言われる

アクティビティ

計画と分析

2.1.1 データ統合とライフサイクル要件の定義

  • 特定の場所で、特定のフォーマットで、統合されたデータを取得したい

2.1.2 データ探索の実行

  • 技術的な探索: メタデータやデータのスキャンツールを利用するなど

  • 業務専門知識による探索: ユーザへのインタビューなど

  • 探索結果はメタデータリポジトリで管理する

2.1.3 データリネージのドキュメント化

  • 利用したいデータが組織内で、どのように取得・作成・移動・更新されるのか、どのように利用し・意思決定するのかを明らかにする

2.1.4 データプロファイリング

  • データの定義と実際を比較し、データの品質を評価する

2.1.5 業務ルールの収集

  • 業務用語の定義、用語間の関連、制約や実行条件、導出　の4カテゴリ

設計

2.2.1 データ統合アーキテクチャの設計

  • 全社レベルと個々のレベルそれぞれでデータ統合ソリューションを明確化する

  • データ連携モデルを選択する

  • 既存のデータ統合と相互運用性のコンポーネントをなるべく再利用する

2.2.2 データハブ、インターフェース、メッセージ、データサービスのモデル化

  • 永続的なもの: データウェアハウス、データマート、オペレーショナルデータストアなど

  • 一次的なもの: インタフェース、メッセージレイアウト、カノニカルモデルなど

2.2. データソースのたーげゲットへのマッピング

  • マッピング仕様を定める: フォーマット、変換、演算など

2.2.4 データオーケストレーションの設計

  • バッチ型: データの移動と変換の頻度、依存関係を持つ複数のステップ

  • リアルタイム型: 更新データ発生など起動イベントの定義

開発

2.3.6 メタデータの維持

  • DII開発過程で明確化されるメタデータを管理維持する

  • データ統合にかかわるデータ構造をドキュメント化する

    • 業務上の定義と技術上の定義、永続的データストア間でのデータ変換仕様など

  • SOA利用登録簿を設ける

    • 情報カタログへのアクセスを管理する

    • 情報カタログには、アプリケーション内の利用可能なデータと機能にアクセスし、利用するためのサービスを記述

実装と監視

2.4 監視と実装

  • 問題に対する監視を行う

    • 潜在的な問題についても監視対象とする

  • サービスレベルは、最も要求の厳しいターゲットアプリケーションやデータ利用者と同じにする

ツール

  • 3.5 データとプロセスのモデリングツール

    • データ構造をデータモデリング・ツールにより設計する

      • ターゲットだけでなく、データ統合における中間のデータ構造についても対象とする

    • データフロー（システム間・組織間）も必要に応じ設計する

  • 3.6 データプロファイリング・ツール

    • データセットの内容に関する統計的分析を行い、データの書式・完全性・一貫性・有効性やデータ構造を評価、把握する

  • 3.7 メタデータリポジトリ

    • データ構造、コンテンツ、データ管理のための業務ルールなど「データに関するデータ」を格納する

導入ガイドライン

5.1 対応状況評価 / リスク評価

各アプリケーションチームは局所的な管理を優先したしまうため、以下が必要

  • 全社データ統合導入に十分な権限を持つレベルからの支援が必要

  • データ統合技術に集中して予算をつける（積極的インセンティブ）

  • 新たな代替データ統合技術の導入申請は却下する（否定的インセンティブ）

新しいデータ統合技術を実装するケース、ITに重点を置きすぎて業務目標に対する商店が失われることがよくある
そのため、業務アプリケーション側からも参加し、業務のも京都要件に焦点を置いていることを確認する

5.2 組織と文化の変革

集中 or 分散

  • データ統合の実装を管理する責任を集中化させるべきか、アプリケーション担当チームに分散させるのかを判断する必要がある

  • 多くの組織では全社データ統合ソリューションの設計と展開に特化した組織横断チームを構築している

  • 分散化チームと集中化チームが協力して各アプリケーションを全社データ統合ソリューションに接続する

業務側リソースの参画

  • データア統合ソリューションは技術的なものだけでは成立しない

  • データ分析とモデリング活動は、業務側のリソースによって実行される

    • カノニカル・メッセージモデルの開発、組織内のデータ共有の標準化

    • データ変換のマッピングの設計と変更のレビュー

DIIのガバナンス

変換・提供されるデータの信頼を支えるガバナンスが必要

  • 管理手順を定める

  • ガバナンスレビューを発動するイベントを決定する

この記事が気に入ったらサポートをしてみませんか？