データアーキテクチャの設計方法

データアーキテクチャ

は、

• どのデータを統合するのか
• どのデータを統制するのか
• どのデータ資産に投資をするか

など、データマネジメントに関する意思決定を導く青写真です。
データマネジメントにおけるデータアーキテクチャの位置づけは次の図のようになります。

また、データマネジメントの導入プロセスにおけるデータアーキテクチャの設計の位置づけは次の図のようになります。

データアーキテクチャがなくデータマネジメントを進めるというのは、地図を持たない宝探しと同じです。
データアーキテクチャは、エンタープライズデータモデルとデータフローをスコープ（全社・業務・アプリケーション）×レベル（概念・論理・物理）で分けることで構成することができます（データアーキテクチャの構成）
次の図は、データアーキテクチャを設計するプロセスを示しています。

※実線は、順番、点線は参照を示す線です。
今回は、このデータアーキテクチャ設計プロセスに従って、次の順で、データアーキテクチャの具体的な設計方法について説明します。

1. 全体概念マスターデータモデルの設計
2. 全体概念トランザクションデータモデルの設計
3. 全体概念分析データモデルの設計
4. 全体概念データフローの設計
5. 業務概念データフローの設計
6. 業務概念データモデルの設計
7. 全体論理マスターデータモデルの設計
8. 全体論理トランザクションデータモデルの設計
9. 全体論理分析データモデルの設計
10. 業務論理データモデルの設計
11. アプリケーション連携モデル（概念）の設計
12. アプリケーション連携モデル（論理）の設計

全体概念マスターデータモデルの設計

ビジネスアーキテクチャとして、資産、場所、ジョブが設計されると、全社概念マスターデータモデルを設計することができます。
資産、場所、ジョブは、ビジネスを構成する最も重要な要素です。
ビジネスアーキテクチャ（概念レベル）の設計では、ビジネスの原点となる顧客、製品、メンバー、パートナー、場所、財務資産を決めます。

なので、顧客、製品、メンバー、パートナー、場所、財務資産のマスターデータを概念レベルで設計することができます。
全体概念マスターデータモデルは、マスターデータを企業全体で一元管理するマスターデータ管理の考え方を前提として、顧客、製品、メンバー、パートナー、場所、財務資産を企業全体でどのような考え方に基づいて管理するか設計します。

顧客マスターデータモデルの設計

次の図は、法人顧客の概念データモデルの例です。

の概念データモデルを見ると、このビジネスでは、次のような観点で法人顧客を管理することがわかります。

• 法人番号を持つ法人をベースに法人顧客を管理する。
  国税庁が管理する13桁の法人番号や、全世界の企業を一意に識別できる9桁のDUNSナンバーを法人番号の候補として考えることができます。
• 法人は、関連会社の関係もわかるようにする。
• 法人顧客ごとに複数の顧客担当者を定義できるようにする。
• 法人顧客ごとに販売条件を設定できるようにする。
• 法人顧客ごとに複数、銀行口座を設定できるようにする。
• 同じ法人顧客でも、契約先、出荷先、請求先など役割の違いが識別できるようにする。
• すでに取引がある顧客かまだ取引がない潜在的な顧客か識別できるようにする。
• 例えば、業種、規模、地域など様々な切り口で法人顧客を分類できるようにする。

このように、全体概念マスターデータモデルでは、ビジネスアーキテクチャで設計された資産をどのように管理すべきかをデータモデルとして記述します。
もし、ビジネスが個人の顧客も対象にするのであれば、個人顧客のデータモデルも設計する必要があります。
次の図は、個人顧客の概念データモデルの例です。

個人顧客の場合、家族関係のある個人をベースに個人顧客を管理していることがわかります。

製品マスターデータモデルの設計

次に、製品の概念データモデルの例を示します。

これを見ると、このビジネスでは、次のような観点で製品を管理することがわかります。

• 製品は、その種類の最小単位である品目として管理する。
• 品目は、「PN（Parts Number）」という品目情報と、「PS（Part Structure）」というPNの親子関係を管理するBOM（Bills of materials：部品表）の構造を持つ。
• 品目の種類には、設計品目、製造品目、販売品目、購買品目、サービス品目がある。
• 各品目は、種類ごとに、複数の単価を持つことができる。
• 各品目は、種類ごとに、仕様、サイズ、色など様々な分類基準で分類することができる。

「マーケティングマネジメント―持続的成長の開発と戦略展開」という書籍で、フィリップ・コトラーは、製品の階層構造を次のように説明しています。

• ニーズ・ファミリー
  製品ファミリーのもととなる中核ニーズ。
  生命保険の例
  安全。
• 製品ファミリー
  中核ニーズを満足させる全ての製品クラス。
  生命保険の例
  貯蓄と所得。
• 製品クラス
  製品ファミリーの中で機能的一貫性を持っているとみなされる製品グループ。
  生命保険の例
  金融手段。
• 製品ライン
  製品クラスの中で、機能、顧客、販路、価格水準などを同じくすることで密接に関連づけられている製品グループ。
  生命保険の例
  生命保険。
• 製品タイプ
  製品ラインの中で、形態や様式が同じもの。
  生命保険の例
  長期契約の生命保険。
• ブランド
  製品ラインの中の一つあるいは複数のアイテムにつけられた名前であり、アイテムの特性や出所を明らかにするもの。
  生命保険の例
  プルーデンシャル。
• 品目（アイテム）
  製品ラインやブランドの中で、サイズ、価格、外見、その他の特性で区別される単位。
  生命保険の例
  プルーデンシャル更新可能長期保険。

上図の概念データモデルでは、この分類の品目を管理し、その上位概念としてのニーズ・ファミリーからブランドまでを品目分類基準とその値で定義できるようにしていることがわかります。
次に、設計品目、製造品目、販売品目、購買品目、サービス品目の関係を次のように設計します。

この概念データモデルは、設計→製造→サービスのエンジニアリングチェーンと、購買→製造→販売というサプライチェーンの流れから構成されています。
それから、各関連の多重度によって、ビジネス上、次の要件を満たす必要があることがわかります。

• 製造品目から販売品目への関連
  同じ製造品目であっても販売独自の視点で販売単価の異なる販売品目を設ける可能性がある。
• 販売品目から製造品目への関連
  複数の製造品目をまとめて一つの販売品目にする可能性がある。
• 製造品目から購買品目への関連
  同じ製造品目（この場合部品です）であっても購買独自の視点で購買単価の異なる購買品目を設ける可能性がある。
• 購買品目から製造品目への関連
  購買独自の購買品目がある可能性がある（製造品目が0になる場合がある）。
• 製造品目から設計品目への関連
  「工程」など製造独自の製造品目がある（設計品目が0になる場合がある）。
• 設計品目から製造品目への関連
  一つの設計品目に対して異なるバージョンの製造品目がある可能性がある。
• 製造品目からサービス品目への関連
  一つの製造品目に対して異なるバージョンのサービス品目がある可能性がある。
• サービス品目から製造品目への関連
  「役務」などサービス独自のサービス品目がある（製造品目が0になる場合がある）。
  複数の製造品目をまとめて一つのサービス品目にする可能性がある。

このようなビジネス上のデータ要件は、ビジネスメタデータとして定義します。
そして、システム開発や業務パッケージ導入の要件定義の際、それが満たすべきデータ要件として定義します。

取引先マスターデータモデルの設計

次に、ビジネスが仕入先や販売代理店など協業パートナーと関係する場合、パートナーのデータモデルを設計する必要があります。
次の図は、取引先の概念データモデルの例です。
ここでは、仕入先や販売代理店など顧客以外で取引がある法人を取引先と定義します。
※このビジネスでは顧客以外で個人とは取引しないものとします。

これを見ると、取引先も法人ベースで管理することがわかります。
なので、同じ法人でも顧客になる場合もあれば取引先になる場合もあり得ます。

社員マスターデータモデルの設計

次に、メンバー（ここでは社員）の概念データモデルの例を示します。

これを見ると、社員も個人ベースで管理することがわかります。
なので、社員でも顧客でもあるというケースもあり得ます。
また、この概念データモデルは、社員の様々な異動の履歴を管理できなければならないことを示しています。

場所マスターデータモデルの設計

次に場所の概念データモデルの例を示します。

これを見ると次のことがわかります。

• 具体的な住所（ロケーション）を持つ拠点を場所として定義する。
• 場所区分で、在庫場所など、各場所の位置づけを明確にする。
• 様々な切り口で場所を分類することができるようにする。

次の図は、在庫場所を明確にした在庫の概念データモデルの例です。

在庫は、品目と在庫場所によって規定されることがわかります。

全体概念トランザクションデータモデルの設計

次に、全体概念トランザクションデータモデルを設計します。
ビジネスアーキテクチャとしてバリューチェーンが設計されると、全体概念トランザクションデータモデルを設計することができます。
特に、戦略マップの内部プロセスの視点を構成する

• 価値を創る活動、
• 価値を伝える活動、
• 価値を届ける活動

の活動領域は、顧客価値を創出する戦略的な活動になります。
マスターデータが資産や場所など業務活動に関連する共通概念を表すのに対して、トランザクションデータは、業務活動によって発生した事実を表します。
全体概念トランザクションデータモデルは、バリューチェーンを構成する業務活動間の関係、つまり、価値の連鎖を設計します。
具体例で説明します。
例えば、ある産業機械メーカーのバリューチェーンが次のように設計されたとします。

このうち、価値を届ける活動のバリューチェーンに対する全体概念トランザクションデータモデルを次のように設計します。

※本図は、代表的なエンティティのみ記載したものです。
全体概念トランザクションデータモデルの枠組みは、バリューチェーンに対応するアプリケーションタイプです。
なので、全体概念トランザクションデータモデルを設計するためには、アプリケーションタイプの構成であるアプリケーションポートフォリオが設計されている必要があります。

さて、全体概念トランザクションデータモデルを構成するエンティティの粒度ですが、これは、次のガイドラインに基づいて考えます。

• ドメイン駆動設計のドメインオブジェクトのうエンティティを対象とし値オブジェクトは対象にしない
  例えば、下図の法人顧客の概念データモデルで考えると、顧客分類基準、顧客ステータス、顧客役割、取引条件は値オブジェクトに該当するので省きます。
  
• ドメイン駆動設計の集約のルートにする
  例えば、受注と受注明細が強い所有関係になっている場合、受注明細は受注に集約されるものとし、受注エンティティを全体概念トランザクションデータモデルのエンティティにします。
  また、上図の法人顧客の概念データモデルでいうと、銀行口座や顧客担当者は、法人顧客に集約されると考えることができます。
  結果的に、法人顧客の概念データモデルで全体概念トランザクションデータモデルの対象となるエンティティは、法人顧客のみになります。

さて、全体概念トランザクションデータモデルで重要なのはトランザクションデータ（活動）間の関連（連鎖）です。
特に、ビジネス上のデータ要件のうち、

• データのトレーサビリティ、
• データ関連の制約

を、この段階で明確にしておきます。
これらのデータ要件は、ビジネスを遂行するための必要条件になるからです。
例えば、上図の全体概念トランザクションデータモデルの、受注と出荷の関係を見ると、次のデータ要件が発生することがわかります。

• データのトレーサビリティ
  出荷の元となる受注データがトレースできなければならない。
  これは、財務報告の信頼性を確保する上で（内部統制上）、取引の実在性を担保するために重要です。
• データ関連の制約
  複数の受注の製品をまとめて出荷（一括納品）できなければならない。
  一つの受注の製品を分割して出荷（分納）できなければならない。

もう一つ例を上げると、販売管理システムの受注データと、在庫管理システムの引当データの関連から、「受注したタイミングで在庫の引当をしなければならない」というデータ関連の制約を定義することができます。
これらのデータ要件は業務パッケージの導入やシステム開発のときの仕様になります。
このように、全体概念トランザクションデータモデルを設計することによって、バリューチェーンが備えるべきビジネス上のデータ要件を全体的に洗い出すことができます。
全体概念トランザクションデータモデルが設計できたら、それを構成するエンティティ（データ）を、どのアプリケーションが管理するか明確にします。
次の図は、アプリケーションポートフォリオを一覧化した表です。

アプリケーションポートフォリオを構成するアプリケーションタイプに対して、全体概念トランザクションデータモデルのエンティティ（データ）を割り当てると次のようになります。

アプリケーションポートフォリオには、社員管理システムなど３つの主要なバリューチェーンを構成する活動に関係するアプリケーション以外のアプリケーションもあります。
なので、アプリケーションタイプにエンティティ（データ）を割り当てときは、企業全体のエンティティ（データ）を考えて割り当てるようにします。

全体概念分析データモデルの設計

全体概念分析データモデルは、BSCのKPIを参考にして設計します。
次の例は、BSCのKPIに対して分析データを設定した例です。

ここでは、LTV分析システムにおけるLTVのデータアーキテクチャの例について説明します。
まず、LTV分析システムではLTV（顧客生涯価値）を次のように管理すると考えます。

• 既存顧客のLTV=（取引期間における顧客の粗利益）−（取引期間における顧客維持コスト）と考える。
• 製品カテゴリの定義
  販売品目（完成品、部品、サービス）を製品カテゴリ（ハイエンド製品など）で分類する。
• 顧客セグメントの作成
  例えば、ハイエンド製品を購入した顧客を顧客セグメント・ハイエンドとして分類する。
• 期間（年、四半期など）ごとの顧客維持コストを記録する。
• 売上計上の都度、売上データをLTV分析システムに蓄積する。
• LTV分析システムでは、売上明細から継続的に期間（年、四半期など）ごとのLTVを測定する。

まず、販売品目（完成品、部品、サービス）を製品カテゴリ（ハイエンド製品など）で分類します。

次に、例えば、ハイエンド製品を購入した顧客を顧客セグメント・ハイエンドとして分類します。

このモデルでは、期間（年、四半期など）ごとの顧客維持コストを顧客ごとに記録できるようにしています。
さて、次のように売上データから製品一個あたり粗利益を計算することができます。

なので、コマンド・クエリ分離パターン（CQRS）を適用して、「製品の出荷登録」アクションのタイミングで売上管理システムから売上データをLTV分析システムに渡します。
LTV分析システムのDWHには、その都度、売上データが蓄積されます。

売上管理システムからLTV分析システムに渡される売上データのカノニカルモデルは次のようになります。
※
カノニカルモデル
システム間を異動するメッセージのデータモデル。

LTV分析システムでは、定期的にバッチで売上データからLTVデータを統合します。
その際、バッチ処理の一環として、顧客管理システムから最新の顧客セグメント別顧客データを取得するとともに、販売管理システムから最新の製品カテゴリ別販売品目データを取得します。

結果的に、LTV分析システムでは、次のようなLTVデータが生成されます。

全体概念データフローの設計

ここでは、

• 全体概念マスターデータモデル
• 全体概念トランザクションデータモデル
• 全体概念分析データモデル

に対する全社レベルの概念データフローを設計します。

マスターデータの全体概念データフロー

顧客マスターの全体概念データモデル

顧客マスターデータは、バリューチェーンのビジネスプロセスでいうと「顧客の獲得」プロセス、「顧客の活性化」プロセス、「顧客の維持」プロセス、「顧客の処分」プロセスで生成、更新、削除されます。
次の図は、顧客マスターデータが更新されるときの全体概念データモデルの例です。

これを見ると、マスターデータ管理の方針として、顧客マスターは、データの構造を一般化して多くのシステムに適用にする必要がないため、顧客マスターの主管システムである顧客管理システムをトランザクションハブにしていることがわかります。
また、データ統合の方針として、顧客マスターデータの統合は、リアルタイム性を求められないため、顧客マスターデータの更新の都度、非同期メッセージングによるイベント駆動で統合していることがわかります。
この全体概念データフローは、トランザクションハブである顧客管理システムの顧客データが更新される都度、顧客データを必要とするシステムにTopicを介して配布（ブロードキャスト）するというイベント駆動統合の仕組を表しています。
顧客データを必要とするシステムは、顧客管理システムから送られていくる最新の顧客データで、自身の持つ顧客データを更新します。

品目マスターの全体概念データモデルー

品目マスターデータは、バリューチェーンのビジネスプロセスでいうと「製品の開発」プロセス、「製品の改良」プロセス、「製品の改修」プロセス、「製品の廃止」プロセスで生成、更新、削除されます。
次の図は、「製品の開発」プロセスのアクティビティフローの例です。

流れは次のようになります。

1. 製品管理者が製品を設計すると、
2. 生産管理者がそれを受けて量産化の準備をする。
3. 量産化の準備ができると、販売管理者、購買管理者、保守サービス管理者が、それぞれ、販売、購買、サービスの企画をする。
4. 販売、購買、サービスの企画ができると、顧客管理者が市場に向けて製品のプロモーションを行う。

製品開発の流れを受けて、各システム（アプリケーションタイプ）間のデータフローは次のようになります。

これを見ると、マスターデータ管理の方針として、品目マスターは、データの構造を一般化して多くのシステムに適用にする必要がないため品目マスターの主管システムである製品管理システムをトランザクションハブにしていることがわかります。
また、データ統合の方針として、品目マスターデータの統合は、リアルタイム性を求められないため、品目マスターデータの更新の都度、非同期メッセージングによるイベント駆動で統合していることがわかります。
データ統合の流れは次のようになります。

1. 製品管理者の製品設計を受けて製品管理システムが、設計品目データを、Queueを介して生産管理システムに送る。
2. 生産管理者の生産準備の過程で、設計品目データから製造品目データが生成され、それがTopicを介して販売管理システム、購買管理システム、サービス管理システムに送られ、各システムで販売品目、購買品目、サービス品目が生成される。
3. また、生産準備を受けて、製造品目データがQueueを介して在庫管理システムに送られることで、製造品目に対応した在庫データが生成される。
4. 販売、購買、サービスの企画ができると、販売管理システムの販売品目がQueueを介して顧客管理システムに送られ、製品のプロモーションに活用される。
5. なお、顧客の問い合わせやクレームによって蓄積された製品の改善要求データは、製品管理システムに送られ、製品の改良に活用される。

トランザクションデータの全体概念データフロー

トランザクションデータの全体概念データフローは、全体概念トランザクションデータモデルに対する概念データフローです。
下図は、全体概念トランザクションデータモデルの例です。

このデータモデルのトランザクションデータ間のトレーサビリティから、次のようなトランザクションデータの全体概念データフローを設計することができます。

例えば、上の全体概念トランザクションデータモデルを見ると、受注データと出荷データの間に「出荷の元となる受注データがトレースできなければならない」というトレーサビリティがあることがわかります。
これは、財務報告の信頼性を確保する上で（内部統制上）、取引の実在性を担保するために重要です。
なので、何らかの方法で、販売管理システムの受注データを、出荷管理システムに渡す必要があります。
上図のトランザクションデータの全体概念データフローでは、販売管理システムと出荷管理システム間で受注データのフローを記述しています。
このトランザクションデータの全体概念データフローは、業務概念データフローを設計するときの見取り図になります。
それから、必要に応じてCRUD図の形式でトランザクションデータの全体概念データフローを作成することもできます。
次の図は、全体概念データフロー（CRUD表）の例です。

分析データの全体概念データフロー

次の図は、LTV分析システムに売上データが蓄積される分析データの全体概念データフローを表しています。

これを見ると「製品の出荷登録」アクションのタイミングで売上管理システムから売上データをLTV分析システムに渡していることがわかります。
LTV分析システムのDWHには、その都度、売上データが蓄積されます。

業務概念データフローの設計

業務概念データフローは、アクティビティフローのアクティビティごとに設計します。
ビジネスアーキテクチャのバリューチェーン設計で次のようなバリューチェーンを設計したとします。

一つひとつのホームベースアイコンは、活動領域を構成するビジネスプロセスになります。
さらに、ビジネスアーキテクチャのアクティビティフローの設計で「製品の販売」プロセスのアクティビティフローを次のように設計したとします。

次に、ビジネスアーキテクチャのアクションフローの設計で、上記アクティビティフローの「製品の受注」アクティビティのアクションフローを次のように設計したとします。

そこで、上記「製品の販売」プロセスの「製品の受注」アクティビティの業務概念データフローを次のように設計します。

「受注の登録」アクションと「出荷の予約」アクションのデータフローになっていることがわかります。
データフローを構成する要素は、アプリケーションアーキテクチャのアプリケーションポートフォリオで設計されたアプリケーションタイプです。
さて、全体概念トランザクションデータモデルを設計した際、アプリケーションポートフォリオにエンティティ（データ）を割り当てました。

ここで、アプリケーションが管理するエンティティ（データ）を見ると、「受注の登録」アクションで生成される受注エンティティは、販売管理システムが管理していることがわかります。
また、「出荷の予約」アクションで生成される出荷エンティティ（データ）は、出荷管理システムが管理していることがわかります。
なので、「製品の受注」アクティビティの業務概念データフローを設計するときは、販売管理システムと、出荷管理システム間のデータフローを考える必要がありあります。
それから、上述したトランザクションデータの全体概念データフロー（下図）で販売管理システムに関係するデータフローを見ると、販売管理システムと出荷関連システム間のデータフローだけではなく、販売管理システムと在庫管理システム間のデーターフロー、販売管理システムと請求管理システム間のデーフローもあることがわかります。

販売管理システムと請求管理システム間のデーフローは、請求データと受注データのトレーサビリティを実現するためのデータフローなので、今回は関係ありません。
しかし、販売管理システムと在庫管理システム間のデーターフローは、受注データと引当てデータのトレーサビリティを実現するためのデータフローなので、受注のタイミングで、それを実現する必要があります。
つまり、受注のタイミングで、受注の販売品目に対する在庫の引当を行う必要があるということです。
以上より、業務概念データフローでは、販売管理システムと出荷管理システムにたいするデータフローを上図のように設計しています。
業務概念データフローでは、販売管理システムと出荷管理システム受注データを渡すことで受注エンティティと出荷エンティティの関連を実現しているわけではなく、受注を登録するタイミングで、その受注データをベースに出荷を予約することで実現しています。
また、「受注の登録」するとき、販売品目に対する在庫を引当する必要があるので、在庫管理システムに対するデータフローも設計しています。
さて、業務概念データフローを設計するときは、各アプリケーション間でデータをどう連携するかとうフローだけでなく、データ統合の方針に従って、データをどう統合するか、データの統合の方法（バッチ、イベント駆動、リアルタイム）も設計します。
上図の例では、「受注の登録」の一環として在庫を引き当てる必要があるため、販売管理システムが在庫管理システムのAPIを介してリアルタイム統合することでトランザクション整合性を保持していることがわかります。
下図は、「製品の製造」アクティビティで製品を製造したあと「製品の製造登録」をする際の業務概念データフローです。

これを見ると、「製品の製造登録」のトランザクションの一環として納入機管理システムから納入機部品データを取得する必要があるので、それらの間を、APIを介してリアルタイム統合していますが、「製品の製造登録」後、納入機データを在庫管理システムや品質管理システムに渡すときは、特にリアルタイム性は求められないのでTopicを介したイベント駆動統合していることがわかります。

業務概念データモデルの設計

業務概念データモデルの設計

業務概念データモデルは、全体概念トランザクションデータモデルに比べて一段と粒度が細かくなります。
全体概念トランザクションデータモデルは、下図のようにバリューチェーン全体の概念データモデルです。

業務概念データモデルは、バリューチェーンを構成する活動領域のビジネスプロセスごとに設計します。
先に、業務概念データフローで「製品の受注」アクティビティのデータフローを次のように設計しました。

「製品の受注」アクティビティのアクションフローは次のようになります。

業務概念データモデルは、業務概念データフローにある各アクション×アプリケーションタイプごとに設計します。
例えば、「受注の登録」における販売管理システムの業務概念データモデルを設計すると、次のようになります。

全体概念トランザクションデータモデルを構成する受注エンティティが、業務概念データモデルでは受注と受注明細に展開されていることがわかります。
また、受注の元となる販売見積や社員など、受注に関連すべきすべてのエンティティが抽出されていることがわかります。
次に、「受注の登録」における在庫管理システムの業務概念データモデルを設計すると、次のようになります。

全体概念トランザクションデータモデルを設計した際、「受注したタイミングで在庫の引当をしなければならない」というデータ要件が発生することがわかりました。
なので、在庫管理システムの業務概念データモデルでは、受注明細に対して在庫が引当てられていることがわかります。
また、全体概念トランザクションデータモデルを見ると、在庫は、製造品目で管理されることになっているので、在庫管理システムの業務概念データモデルでも販売品目ではなく、製造品目に対する在庫が引当てられるように設計されています。
次に、「出荷の予約」アクションの業務概念データモデルを設計すると、次のようになります。

全体概念トランザクションデータモデルを設計した際、次のようなデータ要件が発生することがわかりました。

• 出荷の元となる受注データがトレースできなければならない
• 複数の受注の製品をまとめて出荷（一括納品）できなければならない
• 一つの受注の製品を分割して出荷（分納）できなければならない

このデータ要件を満たすために、「出荷の予約」アクションの業務概念データモデルでは、出荷と受注の関連、出荷明細と受注明細の関連を上図のように設計しています。
概念データモデルを、このように詳細な粒度で設計することで、ビジネス上のデータ要件やデータの品質要件など、ビジネスメタデータとして定義する内容を明確にすることができます。

ビジネスメタデータの定義

• ビジネスメタデータとして定義する内容の定義

  ビジネスメタデータとして定義する内容を定義します。
  例
  
  

• ビジネス上のデータ要件を定義する観点の整理

  ビジネス上の要件を満たすために定義すべきデータ要件があれば次の観点で記述します。

  • データのトレーサビリティの確保
    財務報告の信頼性を確保する場合など、データが発⽣した原因となるデータがトレースできなければならない場合、それをデータ要件として定義します。
    「出荷の予約」アクションの業務概念データモデルの例の場合
    • 出荷の元となる受注データがトレースできなければならない。
      これは、財務報告の信頼性を確保する上で（内部統制上）、取引の実在性を担保するために重要である。
    • 出荷明細の元となる受注明細データがトレースできなければならない。
      これは、財務報告の信頼性を確保する上で（内部統制上）、取引の実在性を担保するために重要である。
  • データ関連の制約
    分納や⼀括納⼊などのビジネスルール上、データ間の関連に制約がある場合、それをデータ要件として定義します。
    「出荷の予約」アクションの業務概念データモデルの例の場合
    • 複数の受注の製品をまとめて出荷（一括納品）できなければならない。
    • 一つの受注の製品を分割して出荷（分納）できなければならない。
    • 複数の受注明細の製品をまとめて出荷（一括納品）できなければならない。
    • 一つの受注明細の製品を分割して出荷（分納）できなければならない。
  • データ記録者の記録
    財務報告の信頼性を確保する場合など、誰がデータを記録したか証跡を残す必要がある場合、それをデータ要件として定義します。
    「出荷の予約」アクションの業務概念データモデルの例の場合
    • 内部統制のため販売管理者、出荷管理者、請求管理者の職務を分掌する場合、出荷管理者のどの社員が受注したかを記録し履歴を残しておく必要がある。
  • データの状態管理と、それに伴う制約
    ビジネスルール上、データの状態を管理し、それに伴う制約を担保する必要がある場合、それをデータ要件として定義します。
    • 「製品の出荷登録」アクションのタイミング（製品が出荷されたタイミング）で、出荷の出荷日が設定され、出荷ステータスが完了にならなければならない。
      出荷ステータスが完了になると、出荷内容の変更や出荷明細の追加ができないようにならなければならない。
    • 「製品の出荷登録」アクションのタイミング（製品が出荷されたタイミング）で、出荷明細のステータスが「出荷済」にならなければならない。
    • 「納品報告の確認」アクションのタイミング（製品が納品されたタイミング）で、出荷明細のステータスが「納品済」にならなければならない。
  • データの記録に関する制約
    ビジネスルール上、記録されなければならないデータ項⽬などがあれば、それをデータ要件として定義します。
    • 「製品の出荷登録」アクションのタイミング（製品が出荷されたタイミング）で、出荷明細の出荷数量が設定されなければならない。
    • 「製品の出荷登録」アクションのタイミング（製品が出荷されたタイミング）で、出荷明細の出荷数量が、出荷明細が関連する受注明細の出荷数量に設定されなければならない。
  • データの参照に関する制約
    ビジネスルール上、データと関連するデータを参照できなければならない場合、それをデータ要件として定義します。
    • 受注に基づいた出荷がある場合、それが参照できなければならない。
    • 受注明細に基づいた出荷明細がある場合、それが参照できなければならない。
    • 出荷明細には、販売品目ではなく、それに対応する製造品目が関連しなければならない。
  • 法規遵守（コンプライアンス）に関する制約
    法規を遵守する上で必要な制約があれば定義します。

  「出荷の予約」アクションの業務概念データモデルの例
  

• データ品質の評価項目の定義

  データ品質の評価項目（データの一意性など）を定義します。
  例
  データ品質の評価項目を次のように定義します。

  • 正確性
    データが現実の実体を正しく表している程度を表す。
  • 完全性
    必要なデータが全て存在しているかどうか、その程度を表す。
  • 一意性
    同じ実体を表すデータが同じデータセット内に複数存在していないか、その程度を表す。
  • 一貫性
    データが、正しいルールに貫かれて表現されているか、その程度を表す。
  • 適時性
    データが適切な時点のものであるか、その程度を表す。

• データセキュリティを測る基準の定義

  データセキュリティを測る基準（機密レベルと規制対象カテゴリ）を定義します。
  例

  機密性レベル
  次のように機密性レベルを分けます。
  • 公開用
    公衆を含む誰でも利用できる情報。
  • 社内向け
    情報は社内のメンバーに限定されるが、共有した場合のリスクは最小限である情報。
    組織外部に向けて表示したり、説明することはできるがコピーすることはできない。
  • 社外秘
    適切に結ばれた機密保持契約や、それに類するものがない場合は、組織外で共有することができない情報。
  • 制限付機密
    「知る必要がある」一定のロールを持つ個人に限定された情報。
    制限付機密データにアクセスするには、個人が権限付与手続を踏む必要がある。
  • 登録者限定機密
    非常に機密レベルが高い情報で、データにアクセスするためには、情報にアクセスするすべての人が法的な合意に署名し、秘密のための責任を負わなければならない。
規制対象カテゴリ
規制対象のカテゴリは次のようになります。
• 個人識別情報（PII：Personal Identification Information）
  個人の私的情報で、氏名、住所、電話番号、スケジュール、政府のID番号、年齢、人種、宗教、民族性、誕生日、家族の氏名や仲間の名前、雇用情報（人事データ）、報酬など、個人一人一人を識別できる情報が含まれるもの。
• 財務上のセンシティブデータ
  インサイダーデータと呼ばれるもので、まだ公表されていない現在の財務情報を含む、すべての財務情報を指す。
• 医療上のデータ/個人健康情報（PHI:Personal Health Information）
  個人の健康や医療に関するすべての情報。
• 教育記録
  個人の教育に関するすべての情報。

• データドメインの定義

  データドメインとは、属性の定義域のことで、属性が取りうる値一式を定義したものです。
  データドメインを使うと、属性の特性を標準化することができます。
  例えば、有効な日付をすべて含む日付というドメインを定義すると、それを論理データモデル内の任意の日付属性や物理データモデル内の日付カラム（フィールド）に割り当てることができます。
  DMBOKではデータドメインの種類を次のように紹介しています。
  

• ビジネスメタデータの定義

  上記基準に従ってビジネスメタデータを定義します。
  ビジネスメタデータの例（Excel）のダウンロード
  ビジネスメタデータを定義する際、必要に応じて、概念CRUD表を作成して、ビジネスメタデータのビジネス上のデータ要件をさらに詳細化しアクション別に展開します。
  概念CRUD表は、アクションフローのアクションと業務概念データモデルのエンティティのマトリクスによって、次の観点で、業務とデータの整合性を確認するための表です。

  • データのライフサイクル
    アクションが発生した際、データが生成（Create）、参照（Read）、更新（Update）、削除（Delete）されるのか定義します。
    データの削除には、データが物理的に削除される場合だけでなく、例えば、契約データのステータスが解約になるなど、データ（エンティティ）のライフサイクルの終了を表す場合も含みます。
  • ビジネス上のデータ要件
    アクションが発生した際、ビジネス上守るべきデータ要件を定義します。
    ここでは、ビジネスメタデータのビジネス上のデータ要件をアクション別に展開します。

  次の図は、概念CRUD表のイメージです。
  

全体論理マスターデータモデルの設計

現在の全体論理マスターデータモデルの課題が解決されるように、あるべき全体論理マスターデータモデルを設計します。
次の図は、クラス図で記述した顧客マスターデータの全体概念マスターデータモデルです。

これを、ER図を使って全体論理マスターデータモデルに展開すると、次のようになります。

全体論理トランザクションデータモデルの設計

現在の全体論理トランザクションデータモデルの課題が解決されるように、あるべき全体論理トランザクションデータモデルを設計します。
次の図は、クラス図で記述した全体概念トランザクションデータモデルの例です。

これを、ER図を使って全体論理トランザクションデータモデルに展開すると、次のようになります。

全体論理分析データモデルの設計

データアーキテクチャ（論理レベル）を設計する基準に従って、全体概念分析データモデルを全体論理分析データモデルに展開します。
次の図は、クラス図で記述したLTVの全体概念分析データモデルです。

れを、ER図を使って全体論理分析データモデルに展開すると、次のようになります。

業務論理データモデルの設計

業務概念データモデルを業務論理データモデルに展開します。
その際、業務概念データモデルのビジネスメタデータとして定義されたデータ品質要件やビジネス上のデータ要件を満たす業務論理データモデルを設計します。
次の図は、データの品質要件が、それが満たされない場合のリスクとして定義された業務概念データモデル（クラス図）の例です。

例えば、社員エンティティと部品品質検査エンティティの関連に、参照整合性リスクが定義されていますが、これは、部品品質検査エンティティに対する社員エンティティの参照整合性が確保されないリスクがあることを示しています。
このリスクを解消するためには、リレーショナルスキームで論理データモデルに展開するとき、部品品質検査エンティティの外部キーとして、社員エンティティの主キーを定義する必要があります。
この業務概念データモデルのデータ品質要件を満たすべく業務論理データモデル（ER図）の例は次のようになります。

これを見ると、参照整合性制約として、部品品質検査エンティティに、社員エンティティの主キーである社員番号が、外部キー社員番号（FK）として定義されており、先程示した参照整合性リスクを解消していることがわかります。
また、業務概念データモデルにおける社員エンティティと部品品質検査エンティティの間の一貫性を保持するために、業務論理データモデルでは、社員エンティティと部品品質検査エンティティの間に存在制約が働くように設計しています。
また、業務概念データモデルの部品品質検査エンティティの検査日の有効性を保持するために、業務論理データモデルでは、部品品質検査エンティティの検査日に日付ドメイン制約（日付に関するデータドメインに準拠するようにする制約）を設定しています。

アプリケーション連携モデル（概念）の設計

アプリケーション連携モデルとは、アプリケーションの各ユースケースを、関係するアプリケーションタイプ同士がどう連携して実現しているかを表したモデルのことです。
アプリケーション連携モデルは、業務概念データフローを参照して設計します。
業務概念データモデルの設計で例にした「製品の受注」アクティビティの業務概念データフローを例にします。

この業務概念データフローは、次の販売管理フロントエンドシステムのユースケースを実現します。

フロントエンドアプリケーションとは、ユーザーとのインターフェース（ユーザーインターフェース、UI）を司るアプリケーションです。
マイクロサービスは、フロントエンドアプリケーションのバックエンドでサービスを提供します。
これを参考にして、上記販売管理フロントエンドシステムのアプリケーション連携モデル（概念レベル）を設計します。
次の図は、上記「販売フロントエンドシステム」のユースケースモデルの「受注の登録」ユースケースの場合の例です。

販売管理フロントエンドシステムが、製品管理システム、顧客管理システム、販売管理システム、および、在庫管理システムと連携して「受注の登録」ユースケースを実現していることがわかります。
次の図は、上記「販売フロントエンドシステム」のユースケースモデルの「出荷の予約」ユースケースの場合の例です。

販売管理フロントエンドシステムが、出荷管理システムと販売管理システムと連携して「出荷の予約」ユースケースを実現していることがわかります。
もう一つ例を示します。
顧客マスターの全体概念データフローをアプリケーション連携モデル（概念レベル）にすると次のようになります。

これは、顧客管理フロントエンドシステムに対する顧客管理者の「顧客情報の更新」ユースケースのアプリケーション連携モデル（概念レベル）になります。

アプリケーション連携モデル（論理）の設計

選定された業務パッケージやフロントエンドアプリケーション、BFF、マイクロサービスの製品でアプリケーション連携モデルを更新します。
その際、データ統合の設計（製品レベル）で選定されたデータ統合製品も反映します。
アプリケーション連携モデル（論理レベル）は、アプリケーション連携モデル（概念レベル）を参照して設計します。
データ連携の設計の全体的な流れは次のようになります。

下図は、設計フェーズで設計した、「販売管理フロントエンドシステム」のユースケースモデルの「受注の登録」ユースケースの場合のアプリケーション連携モデル（概念レベル）です。

業務パッケージを導入する場合

現行のSCMシステムを業務パッケージに置き換える場合、上図のアプリケーションタイプ、販売フロントエンドシステム、販売管理システム、在庫管理システムは、同じ業務パッケージのアプリケーションカテゴリになります。
なので、アプリケーション連携モデル（論理レベル）の例は次のようになります。

この例の場合、製品管理システムはPLMシステム、顧客管理システムはCRMシステムで実現されています。

スクラッチ開発の場合

マイクロサービスを適用する場合、アプリケーション連携モデル（論理レベル）の例は次のようになります。

アプリケーションタイプである販売管理システム、在庫管理システム、製品管理システム、顧客管理システムが、アプリケーションカテゴリである販売管理サービス、在庫管理サービス、製品管理サービス、顧客管理サービスというマイクロサービスで実現されています。
上図では、UIの部分がフロントエンドアプリケーションになります。
また、BFFとはBackends For Frontendsの略で、アーキテクチャパターンの1つで、フロントエンドとバックエンドの中間に位置し、双方の複雑な処理を緩和させる役割を担うサーバー機能のことです。
BFFは、UIの種類ごとに作成します。
それから、データ統合の設計（製品レベル）の結果を受けて、Queueの製品としてApacheのActiveMQが設定されていることがわかります。
次の図は、設計フェーズで設計した、「販売フロントエンドシステム」のユースケースモデルの「出荷の予約」ユースケースを実現するアプリケーション連携モデル（論理レベル）を設計した例です。

フロントエンドがモバイルデバイスの場合、次のようになります。

UIがWebの場合とモバイルデバイスでBFFが違うことがわかります。
次の図は、シングルサインオンの認証サーバーもマイクロサービスで実現した、「受注の登録」ユースケースの場合のアプリケーション連携モデル（概念レベル）の例です。

認証、認可の流れは次のようになります。

1. ユーザーがUIのログイン画面でIDとパスワードを入力します。
2. UIはSSOゲートウェイにIDとパスワードとジョブ（例えば、販売管理システムの場合、SALES）を渡します。
3. SSOゲートウェイは認証サービスにDとパスワードとジョブを渡します。
4. 認証サービスはユーザーのIDとパスワードを検証し、ユーザーが社員の場合、社員管理サービスから、ユーザーがアプリケーションの場合、情報管理サービスにからIDにするジョブを取得し、SSOゲートウェイから渡されたジョブと一致しているか検証します。
   ID、パスワード、ジョブが正しい場合、認証サービスは、IDやジョブが設定された認証トークン（例えばJWT：JSON Web Token）を生成してSSOゲートウェイに返します。
5. SSOゲートウェイは認証トークンをUIに渡します。
6. UIは認証トークンを付加してマイクロサービスにリクエストを送信します。
7. マイクロサービスは、認証トークンを検証し、認証トークンに設定されたジュブが適切である場合、ユーザーのリクエストに応じた処理を行います。

この例の場合、社員やアプリケーションごとに設定されたジョブ（役割）によって、アクセスできる（認可される）サービスが決まっています。
社員管理サービスでは、社員とジョブが関連する社員マスターデータを管理しています（全体概念マスターデータモデルの設計参照）。
情報管理サービスでは、アプリケーションとジョブが関連するアプリケーションのマスターデータを管理しています。
もう一つ例を示します。
下図は、設計フェーズで設計した、「顧客管理フロントエンドシステム」の「顧客情報の更新」ユースケースのアプリケーション連携モデル（概念レベル）です。

これをベースにアプリケーション連携モデル（論理レベル）を設計すると次の例のようになります。

データマネジメントのデータ連携の設計（製品レベル）で、Topicの製品としてApacheのActiveMQが選択されていることがわかります。