データマネジメントに関するコンセプト・システム編
データマネジメントの実践的な導入方法の説明に入る前に、データマネジメントに関するコンセプト（概念）を次の観点でまとめます。
システム
データ
今回は、まず、もっとも基本的なシステムに関するコンセプトについて整理します。
システムとは
私たちは、情報システム、経済システム、エコシステムなど私達は日常的に「システム」という言葉を使っています。
システムは、ビジネスやITなどあらゆる物事の基本概念なので、まず、システムについて見ていきましょう。
システムとは何か？
それは、
相互に影響を及ぼし合う要素から構成される、まとまりや仕組みの全体
で、次のような特徴があります。
システムは複数の要素によって構成される
システムに含まれる全ての要素は必ず自分以外の要素に何らかの影響を及ぼす
システムは時間に沿って動作する
１つ目の特徴から、システムは複数の要素を持つ集合であることになります。
２つ目の特徴から、システムは、それを構成する要素が互いに関係する構造を持つということになります。
３つ目の特徴から、システムを構成する要素同士が相互作用して動作しているということになります。
相互に連関し合って全体を構成している要素の各々が担っている働きが機能（Function）ですが、機能という概念でシステムを表すと、
システムとは何らかの機能を持つ要素が有機的に繋がっている全体
ということになります。
ここで、開かれたシステム（オープンシステム）、つまり、システムの外部から入力を受けたり、システの外部に出力を行ったりするシステムのことを考えると、システムは、さらに大きなシステムを構成する一つの要素であるということになります。
モデルとは
最近、ビジネスモデル、数理モデル、機械学習モデルなど✗✗モデルという言葉をよく聞きます。
データマネジメントでもデータモデルという概念があります。
このモデルとは何でしょうか？
モデルとは、
現実のシステムの特別な一面を簡略化した形で表したもの
です。
なので、飛行機の模型や、建築物の設計図はモデルになります。
数理モデルも、現実の現象の特徴を数式で簡略化したモデルです。
システムのモデルを考えることをモデル化とかモデリングといいます。
次に、システムをモデル化するときのアプローチについて考えてみましょう。
システムをモデル化するときの３つの視点
システムは、次の３つの視点でモデル化することができます。
静的視点・動的視点
論理的視点・物理的視点
外部的視点・内部的視点
静的視点、動的視点のモデルを静的モデル、動的モデル、論理的視点、物理的視点のモデルを論理的モデル、物理的モデルといいます。
静的視点・動的視点から見ていきましょう。
まず、動的視点ですが、動的とは「動いてゆく様」ということです。
なので、動的視点とは、
動いている状況を追って見る
という視点です。
例えば、組織があって、その構成員である営業担当の山田さんが、総務担当の田中さんに出張申請をし、田中さんは、経理担当の佐藤さんに経費申請をするという活動の流れ（業務フロー）があるとしましょう。
このような組織を構成する要素同士の動作を表してるモデルが動的モデルになります。
標準的なモデリング言語、UML（統一モデリング言語）では、動的モデルを、状態遷移を表すステートマシン図、アクティビティ図、相互作用を表すコミュニケーション図、シーケンス図で記述することができます。
次に静的視点について見ていきましょう。
静的とは「動かない様」ということです。
なので、静的視点には次の２つの視点があると考えることができます。
動いている途上の断面を見る
様々な状況を一貫して見る
まず、動いている途上の断面ですが、これは、動作が行われている、ある場面のスナップショットを撮ったモデルになります。
例えば、営業担当の山田さんと総務担当の田中さん、経理担当の佐藤さんが何らかの動作をしている場面のスナップショット
また、営業担当の鈴木さんと総務担当の田中さん、経理担当の野田さんが何らかの動作をしている場面のスナップショットなど様々な場面のモデルを考えることができます。
それに対して、「様々な状況を一貫して見る」視点は、不変的な視点になります。
例えば、組織を構成する営業担当、総務担当、経理担当の関係を表すのが不変的な視点の静的モデルになります。
「動いている途上の断面を見る」スナップショットの視点の場合、上記「動いている途上の断面を見た例１」、「動いている途上の断面を見た例２」のように、場面、場面で異なった静的モデルになりますが、「様々な状況を一貫して見る」視点の場合、各場面の共通部分を抽出して、一貫した不変的モデルになります。
この例の場合、鈴木さん、矢部さん、山田さんを営業担当という共通した役割で分類しています。総務担当、経理担当も同様です。
集合と、それを構成する要素を、型（タイプ）と実例（インスタンス）の関係で考えると、営業担当など役割がタイプで、山田さんなど具体的な担当者がインスタンスになります。
そう考えると、
「動いている途上の断面を見る」スナップショットの視点は、インスタンスの視点で、
「様々な状況を一貫して見る」不変的な視点は、タイプの視点
ということになります。
多く物事から、それらの範囲の全部に共通な性質を抜き出し、これを一般的な概念としてとらえることを抽象化といいますが、インスタンスから、集合の条件となる特徴を抽出してタイプを考える過程が抽象化ということになります。
UML（統一モデリング言語）では、インスタンスの静的モデルをオブジェクト図、タイプの静的モデルをクラス図で表すことができます。
ちなみに、インスタンスからタイプを考える抽象化に対して、「犬、猫、人」から「動物」のように下位概念（サブタイプ：部分集合）から上位概念（タイプ：集合）を考える過程を一般化といいます。
UMLのクラス図では一般化を「汎化関係」で表すことができます。
次に論理的視点・物理的視点について見ていきましょう。
物理的とは「物理法則にかなっている様」なので物理的視点とは、
物理法則にかなっている対象や様子を見る
視点です。
また、論理的とは「論理（物事の間にある法則、筋道）にかなっている様」なので論理的視点とは、
論理にかなっている対象や様子を見る
視点です。
論理的であるということは、筋道が通っていれば良く、必ずしも物理的な法則にかなっていなくてもよいということになります。
UML（統一モデリング言語）では、論理的な構造をクラス図、物理的な構造をコンポーネント図や配置図で表すことができます。
最後に、外部的視点・内部的視点です。
外部的視点とは、
システムの外部要素に、システムがどう働きかけるかを見る
視点です。
システムが、システムの外部要素に提供する機能を洗い出すのです。
この場合、機能の中身はブラックボックスです。
外部的視点で重要なのが、ユーザーなどシステムの外部要素の視点に立って、外部要素が求めている機能を考えるということです。
次に、内部的視点ですが、これは、
システムの内部でシステムの機能がどのように実現されるかを見る
視点です。
システムを構成する要素同士がどのように相互作用しながら、システムの機能を実現するのかを表すのです。
外部的視点と内部的視点を分けるということは、仕様、つまり、「何をするのか（What）」という、やることを規定した部分と、「それをどう実現するのか（How）」具体的なやり方を示した部分を分離して考えるということです。
仕様と実現の関係の例としては、数学の関数と、関数を実現す数式の関係や、システムの仕様と、それを実現するプログラムの関係があります。
仕様と実現ですが、仕様をインターフェース、実現を実装と言い換えることができます。
インターフェースと実装を分離することによって、外部に対するインターフェースを変えずに、内部の実装部分を自由に交換することができるようになります。
これは、内部の実装部分を変えても、外部要素は影響受けないということです。
システムは、構成要素であるサブシステム（モジュール）が有機的につながってできています。
システムにとって重要なのは、相手のシステムのインターフェース（What：何ができるか）であって、それがどう実装されているか（How）を知る必要はありません。なので、相手のシステムに対してインターフェースのみ公開して使わせるようにすれば、実装部分を交換しても、相手のシステムに影響を及ぼすことはありません。
これによって、例えば、インターフェースを実現する新しい技術が開発された場合、インターフェースの内部を新しい技術で実装して置き換えても、相手に影響しないという保守性の高いシステムをつくることができます。
オブジェクト指向プログラミングでは、同じインターフェスに対して様々な振舞をするオブジェクトの性質を多態性（ポリモーフィズム）といいます。インターフェースと実装を分離し実装部分を交換可能にすることで多態性を実現し、システムの保守性を上げることができるのです。
UML（統一モデリング言語）では、外部要素と、システムの機能の関係をユースケース図として表すことができます。
さて、外部的視点の機能（何をするのか）と、それを実現する内部の論理的な構造（誰が実現するのか）と振舞（どのように実現するか）でシステムをモデル化することができます。
下図は、UMLのユースケース図、クラス図、相互作用図（シーケンス図あるいはコミュニケーション図）で、情報システムの機能（何をするのか）、構造（誰がするのか）、振舞（どのようにするのか）をモデル化することができることを表しています。
ユースケースを起点としてシステム開発の各工程を進めるアプローチをユースケース駆動開発といいます。
ビジネス（型）の場合、機能をビジネスプロセス、構造を組織構造、振舞を業務フローとしてモデル化することができます。
なぜモデル化が重要なのか
次に、なぜ、モデル化が重要なのか見ていきましょう。
建築家は、家を建てる前に設計図を書きます。
ソフトウェアエンジニアは、ソフトウェアを開発するまでにソフトウェアのモデルをつくります。
DBエンジニアは、DBを構築するまえにデータモデルをつくります。
私たちは、物事を進めるとき、最初にモデルをつくります。
なぜでしょうか？
それは、物をつくるまえに、一旦、仕組みを見える化することで、
目的は実現できるか？
もれダブりはないか？
どういう順番でつくればよいか？
誰が何をつくればよいか？
など、重要事項を事前に検討することができ、
効率的かつ効果的に物事を進めることができる
からです。
さらに、既存の仕組みを一旦、抽象化、一般化することで、それを応用することができ、
新しい物事を創り出すことができる
のです。
アーキテクチャとは
これまで、システムのモデル化について見てきましたが、最後に、アーキテクチャについて見ていきましょう。
エンタープライズアーキテクチャやデータアーキテクチャなど✗✗アーキテクチャという言葉が多く出てくるからです。
アーキテクチャは、もともと建築用語で、建物のデザイン、建築様式を表す言葉です。
ここでは、アーキテクチャを一般化して、
システムの基本的な仕組（構造×振舞）
と定義します。
アーキテクチャは、
システムの目的と、
それを仕組として実現するための要件（設計思想）
に基づいて設計され、モデルとして表現されます。
情報システムのアーキテクチャ
アーキテクチャを中心にした個々の情報システムの開発プロセスに、統一プロセス（UP：Unified Process）があるので紹介します。
統一ソフトウェア開発プロセスの特徴は次の３つです。
ユースケース駆動プロセス
アーキテクチャ中心プロセス
反復でインクリメンタルなプロセス
一つひとつ説明します。
ユースケース駆動プロセス
情報システム（以降、略してシステムとする）は、ユーザーに価値を提供すること目的として存在しています。
ここでいう、ユーザーとは、システムと相互作用する人またはもの（対象のシステムの外部にある別のシステムなど）を表します。
統一ソフトウェア開発プロセスでは、ユーザーにとって価値のある結果をもたらす一連のアクションをユースケース（システムの使い方）として表します。
このユースケースを起点としてシステム開発の各工程が進められる考え方をユースケース駆動プロセス、あるいは、ユースケース駆動開発といいます。
ユースケース駆動プロセスでは、まず、要件定義で、システムが実現すべき機能をユースケースとして定義し、そのあとの工程で、その機能をどう実現するのか分析、設計、実装していきます。
アーキテクチャ中心プロセス
ユースケースは、システムが実現すべき機能を表しますが、その機能を実現するシステムの構成要素の仕組（構造と振舞）を表すのがアーキテクチャです。
システムのアーキテクチャは、システムの設計思想に基づいたシステムの基本的な仕組のことです。
基本的な仕組とは、詳細を省いた土台となる骨組みを表します。
システムに求められる要件を機能要件と、非機能要件に分けるならば、機能要件からユースケースが導かれ、ユースケースおよび非機能要件がシステムの設計思想となり、アーキテクチャを規定します。
非機能要件とは、システムの品質に関する要件と、課題を解決するために予め決められた、ソフトウェアを実行するIT基盤や、導入のための考慮事項などの制約条件のことです。
統一ソフトウェア開発プロセスでは、建築物と同じように、まず、システムの骨組みであるアーキテクチャ（土台）を設計し、それに肉付けしてシステムを完成させることで、より堅牢（Robust）なシステムを構築することができるという考え方に基づいています。
より本質的で変わりにくいアーキテクチャと、変化しやすい具体的な実現手段（テクノロジーなど）を分離し、環境の変化に応じて実現手段を交換できるようにすることで、環境の変化に強い柔軟なシステムを構築することができます。
反復でインクリメンタルなプロセス
システム開発を進める方法には、ウォーターフォール型開発と反復型開発があります。
ウォーターフォール型開発とは、ソフトウェアの開発工程を時系列に分けて、順番に開発していく方法です。
ソフトウェア開発が、工程ごとに、あたかも滝（Waterfall）のごとく水が上から下に落ちていくように進んでいくのでウォーターフォール型開発と呼びます。
ウォーターフォール型開発では、一つ工程を一度で終わらせる計画を立て進捗を管理するので、原則として、前工程が完了しないと次工程に進みません。
なので、ウォーターフォール型開発のメリットは、開発工程が順番に流れていくシンプルな構造になっており進捗管理しやすいということです。
逆に、ウォーターフォール型開発のデメリットは、比較的、開発のリスクが高いということです。
なぜでしょうか？
ウォーターフォール型開発の問題点は前工程に間違いがないことを前提にしている点です。
顧客の要求を事前に詳細に定義することは非常に困難です。
なぜならば、顧客の要求はふわふわしており、時の変化に応じて変わりやすいからです。
なので、顧客の要求を徹底的に確認したにも関わらず、下流工程になって始めて顧客の目に見えるものが出来上る場合、それを見た顧客から修正要望が出ることがあります。
この要望に応えるには、時間をかけて進めてきた工程を、前に戻ってやり直す必要があります。
開発の逆流により、開発の予算や納期をオーバーしてしまう可能性があるのです。
次に、反復型開発ですが、これは、ソフトウェアを小さな単位に分けて、小単位で一連の開発工程を繰り返し、段階的にリリースしていく開発方法です。
この小さな単位をイテレーション（反復）といいます。
イテレーションのサイクルが比較的小さい反復型開発がアジャイル開発です。
反復型開発のメリットは、比較的、開発のリスクが低いということです。
反復型開発の場合、小さな単位で顧客の目に見えるものが出来上がっていくので、その都度、顧客の要求が明確になり、その要求を製品に反映していくことができます。
なので、開発の初期段階から顧客の要求とのズレを調整しいくことができ、ウォータフォール型開発のように、後工程で、いきなり顧客の要求との大きなズレが発覚することは、まずありません。
それでは、反復型開発デメリットは何でしょうか？
それは、進捗管理が難しいということです。
反復型開発の場合、小さな開発単位が反復しながら進んでいくとともに、状況状況に合わせて反復を設計する必要があるので進捗管理が複雑です。
統一ソフトウェア開発プロセスは、反復でインクリメンタルなプロセスなので反復型の開発プロセスです。
ただ、統一ソフトウェア開発プロセスでは、反復的（イテラティブ）プロセスと漸増的（インクリメンタル）プロセスを分けて考えます。
反復的プロセスでは、サイクルを繰り返すごとに、システム全体の濃度が上がるように仕上げていきます。
システム全体の濃度を上げるとは、システムのアーキテクチャを構成する要素であるモジュール（ソフトウェア部品）の完成度を段階的に上げていくということです。
一方の漸増的プロセスでは、システムを、ユースケースなどの小さな機能単位に分解し、サイクルを繰り返すごに要素を一つづつ仕上げていきます。
反復的でインクリメンタル（漸増的）なプロセスとは、この２つの組み合わせで、骨組みであるアーキテクチャが固まったあとは、ユースケース一つ一つを漸増的に仕上げていき、システム全体を反復的に肉付けしていくという方法です。
統一ソフトウェア開発プロセスは、ユースケース駆動とアーキテクチャ中心というコンセプトを活かした反復型開発で、ユーザーに対する価値を持続的に提供し続けられるシステムを構築するための方法になっているのです。
統一ソフトウェア開発プロセスの構成
次に、統一ソフトウェア開発プロセスの構成を説明します。
統一ソフトウェア開発プロセスは、次の図のようなフェーズ×工程で構成されます。
まず、フェーズですが次のような内容になります。
方向づけフェーズ
方向づけフェーズの目標は、システムを開発する正当性について確証を得ることです。
要件定義を通して、システム開発に関する主要なリスク（不確実性）を洗い出し、それをどうコントロールするか検討します。推敲フェーズ
推敲フェーズの目標は、システムの土台となるアーキテクチャを確立することです。
アーキテクチャに基づいて、開発要員の配分、コストの詳細見積もりを行いプロジェクト計画（詳細レベル）を完成させます。構築フェーズ
構築フェーズの目標は、アーキテクチャ（骨格）に基づいてシステムを実装（肉付）し、システムテストを通してシステムのベータ版をリリースすることです。移行フェーズ
移行フェーズの目標は、運用テストを通して、システムのベータ版を完成版に移行し、システムを使って業務活動を遂行できる状態にすることです。
次に、工程ですが、次のような内容になります。
要件定義
システムの目的（存在意義）を明確にし、それを実現するためにシステムに求められる要件（必要な条件）を定義します。外部設計
外部設計では、システムのユーザーインターフェースを設計します。
ユーザーは、システムが価値を提供する相手であり、システムと相互作用する人またはもの（対象のシステムの外部にある別のシステムなど）を表します。分析
分析では、システムのユースケースを実現する内部の論理的な仕組を分析します。
記事「DXとデータマネジメント」の「変化に強い構造」のレイヤでいうと論理レベルの設計、MDA（モデル駆動アーキテクチャ）でいうとPIMの設計になります。設計
設計では、システムのユースケースを実現する内部の物理的な仕組を設計します。
記事「DXとデータマネジメント」の「変化に強い構造」のレイヤでいうと物理レベルの設計、MDA（モデル駆動アーキテクチャ）でいうとPSMの設計になります。実装
設計の結果を受けてシステムを実装します。テスト
システムが要件を満たし、業務で運用できるか検証します。
この要件定義、分析、設計を上述した「システムをモデル化する３つの視点」の機能、構造、振舞で見るとモデルの変遷は次の図のようになります。
要件定義で、機能をユースケースモデル、構造をMDAのCIMであるドメインモデルで表し、分析で、分析モデルがどうユースケースを実現するかクラス図（PIMの構造）とシーケンス図（PIMの振舞）で検証し、設計で、設計モデルがどうユースケースを実現するかクラス図（PSMの構造）とシーケンス図（PSMの振舞）で検証します。
さて、統一ソフトウェア開発プロセスでは、推敲フェーズで、外部設計、分析、設計を通して要件定義で定義した要件を満たすアーキテクチャ（骨組）を確立します。
アプローチとしては、まず、分析工程で、機能要件を満たす（ユースケースを実現する）基本構造を分析します。
その際、システムの構成要素をバウンダリ、コントロール、エンティティの役割に分けて堅牢（robust）な構造を分析するロバストネス分析という手法を使います。
次の図は、ロバストネス分析で分析した分析モデル（構造）の例です。
次の図は、ロバストネス分析で分析モデル（構造）の妥当性を検証した分析モデル（振舞）の例です。
次に、設計工程で、非機能要件を満たす基本構造を設計します。
アプローチとしては、まず、テクノロジーアーキテクチャ（IT基盤）を設計し、それに適する物理的な基本構造を設計します。
物理的な基本構造を設計するときは、既に先人たちにより考えられたアーキテクチャパターンやデザインパターンを適用します。
アーキテクチャパターンに関しては、「ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン」が参考になります。
また、デザインパターンに関しては「オブジェクト指向における再利用のためのデザインパターン」、通称、GoFのデザインパターンが参考になります。
ここでは、「ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン」「オブジェクト指向における再利用のためのデザインパターン」にあるMVCパターンを紹介します。
MVCとはModel、View、Controllerの略で、それぞれ次のような役割になります。
Model
アプリケーションの核となるデータと、それに対する処理を担う。View
Modelの情報をユーザーに表示する。Controller
Viewから取得したイベントをModelやViewに対する要求に変える。
MVCを適用するときは、Modelの再利用性を上げるために、Modelをモジュール化してインターフェースを公開して他からアクセスできるようにします（仕様と実現の分離）。
分析のときに適用したBCE（バウンダリ、コントロール、エンティティ）を、設計でMVCに変換する場合、次のような例が考えられます。
これは、テクノロジーアーキテクチャとしてSpringMVCを適用した場合の例になります。
エンタープライズアーキテクチャ
次に、企業の業務とシステムのアーキテクチャ、エンタープライズアーキテクチャについて説明します。
エンタープライズアーキテクチャ（Enterprise Architecture）を一言でいうと、企業の業務とシステムの設計図です。
エンタープライズアーキテクチャは次の４つの要素から構成されます。
アプリケーションアーキテクチャ
テクノロジーアーキテクチャ
記事「DXとデータマネジメント」の「変化に強い構造」では、ビジネスの基本構造であるびビジネスストラクチャマトリクスを紹介しました。
ビジネスストラクチャマトリクスでいうと、データの部分がデータアーキテクチャ、アプリケーションの部分がアプリケーションアーキテクチャ、ITの部分がテクノロジーアーキテクチャ、それ以外（目的は除く）がビジネスアーキテクチャになります。
次の図は、レベル別に整理した経営方針とエンタープライズアーキテクチャを表しています。
このうち、アプリケーションアーキテクチャのアプリケーション構成は、情報資本ポートフォリオのアプリケーションの部分、テクノロジーアーキテクチャの部分は、情報資本ポートフォリオの情報システム基盤の部分に該当します。
それでは、エンタープライズアーキテクチャの設計思想（事業パーパスを業務とシステムの仕組として実現するための要件）は何でしょうか。
ERM（エンタープライズリスクマネジメントあるいは全社的リスクマネジメント）のフレームワークを考慮すると、次の３つのビジネス要件がエンタープライズアーキテクチャの設計思想になると考えることができます。
各種戦略目標の有効性
各種報告の信頼性
各種法規の遵守
なので、エンタープライズアーキテクチャは、これらのビジネス要件を阻害するリスクにどう対応するか（リスクへの対応）という観点で設計します。
各種戦略目標の有効性
戦略マップの戦略目標を阻害するリスクに対応するためのビジネス、アデータ、アプリケーション、ITの構造と振舞を設計します。
例えば、「製品品質の維持」という戦略目標がある場合、製品を製造する職務と、品質を管理する職務を分掌し、製造の後、品質管理が品質を検証するという業務フローにすることにより製品品質のガバナンスを強化することができます。各種報告の信頼性
各種報告の信頼性を阻害するリスクに対応するためのビジネス、アデータ、アプリケーション、ITの構造と振舞を設計します。
財務報告の信頼性に対するのリスク（下図「財務報告の信頼性要件」参照）をコントロールするのが内部統制です。
なので、内部統制が実現できるよう職務を分掌し、業務フローを設計します。例えば、不正を防ぐため物財を管理する在庫管理と帳簿を記録する会計の職務を分掌する例が考えられます。各種法規の遵守
各種法規の遵守を阻害するリスクに対応するためのビジネス、アデータ、アプリケーション、ITの構造と振舞を設計します。
そのビジネスに関連する法規を洗い出し、どのビジネスプロセスで、どの法規が遵守されるべきか分析し、コンプライアンスに対するリスクをコントロールする職務と業務フローを設計します。
次の図は、財務報告の信頼性要件の例です。
各種報告の信頼性の一環として、内部統制を実施する場合は、この要件に対するリスクに対する対応を考える必要があります。
ビジネスアーキテクチャ
ここでは、上記、経営方針とエンタープライズアーキテクチャの図のビジネスアーキテクチャの部分を詳細化します。
設計レベル
静的モデル
資産（タイプ）構成
顧客タイプ構成
事業成長モデルを設計するとき、顧客と、顧客の価値観（顧客の欲求を満たす性質）を定義しますが、それを受けて顧客タイプを設計します。
その際、顧客の分類基準を設計します。
個人顧客であれば、年齢層、性別など市場をセグメンテーションするときの基準が考えられます。製品タイプ構成
事業成長モデルを設計するとき、製品と、製品の価値提案（顧客価値を満たすための機能や性質）を定義しますが、それを受けて製品タイプを設計します。
その際、製品の機能、構成技術、分類基準を設計します。
製品を機能や構成技術で分解できれば、複数の製品に共通の機能や技術を明確にすることができます。メンバータイプ構成
事業成長モデルを設計するとき、メンバーと、メンバーのモチベーションを上げる価値を定義しますが、それを受けてメンバータイプを設計します。
その際、メンバーの分類基準を設計します。パートナータイプ構成
事業成長モデルを設計するとき、パートナーと、パートナーのモチベーションを上げる価値を定義しますが、それを受けてパートナータイプを設計します。
その際、パートナーの分類基準を設計します。財務資産タイプ構成
事業成長モデルを設計するとき、ニーズ、シーズになる資産として、設備や材料などの財務資産を定義しますが、それを受けて財務資産タイプを設計します。
その際、財務資産の分類基準を設計します。
場所（タイプ）構成
営業場所や物流場所など事業を行う場所を定義します。
その際、場所の分類基準を設計します。組織（ジョブ）構成
事業を行う主体となる職務（ジョブ）を定義します。
ジョブのタスクやスキル、条件などを職務記述書に明記します。
動的モデル
ビジネスプロセス構成
事業を構成するビジネスプロセスを定義します。業務フロー
各ビジネスプロセスの業務フローを設計します。
業務フローには、アクティビティフローとアクションフローがあります。
戦略レベル
静的モデル
資産（種類）構成
顧客カテゴリ構成
顧客タイプを定義するとき設計した顧客の分類基準の値で顧客タイプを分類します。
これは、事業戦略のマーケティング戦略のセグメンテーションを受けて行います。製品カテゴリ構成
製品タイプを定義するとき設計した製品の分類基準の値で製品タイプを分類します。
これは、事業戦略のマーケティング戦略のポジショニングを受けて行います。メンバーカテゴリ構成
メンバータイプを定義するとき設計したメンバーの分類基準の値でメンバータイプを分類します。
これは、人材戦略の一環になります。パートナーカテゴリ構成
パートナータイプを定義するとき設計したパートナーの分類基準の値でパートナータイプを分類します。財務資産カテゴリ構成
財務資産タイプを定義するとき設計した財務資産の分類基準の値で財務資産タイプを分類します。
場所（種類）構成
場所タイプを定義するとき設計した場所の分類基準の値で場所を分類します。組織（部門）構成
事業（市場×製品）別にジョブを分けることで部門を定義します。
動的モデル
アクションプラン
ビジネスプロセスを、事業のビジョンを実現するアクションプラン（実行計画）に展開します。
実例レベル
静的モデル
資産（実例）
顧客（実例）
顧客である具体的な個人や法人です。製品（実例）
製造番号を持つ具体的な製品個体です。メンバー（実例）
メンバーである具体的な個人です。パートナー（実例）
パートナーである具体的な個人や法人です。財務資産（実例）
製造番号を持つ具体的な個々の財務資産です。
場所（実例）
住所がある具体的な場所です。
動的モデル
ワークフロー
実行されたアクションプランがワークフローになります。
次の図は、記事「データマネジメントの導入」で紹介する山田産業の組織（ジョブ）構成の例です。
次の図は、記事「データマネジメントの導入」で紹介する山田産業のビジネスプロセス構成の例です。
次の図は、記事「データマネジメントの導入」で紹介する山田産業の「部品の入荷」プロセスの業務フロー（アクティビティフロー）の例です。
アプリケーションアーキテクチャ
ここでは、上記、経営方針とエンタープライズアーキテクチャの図のアプリケーションアーキテクチャの部分を詳細化します。
設計レベル
静的モデル
アプリケーション構成（概念レベル）
概念レベルのアプリケーションの構成です。動的モデル
アプリケーション間連携モデル（概念レベル）
概念レベルでアプリケーション間の連携を表したモデルです。
戦略レベル
静的モデル
アプリケーション構成（論理レベル）
論理レベル、つまり、具体的な製品など分類されたアプリケーションの構成です。動的モデル
アプリケーション間連携モデル（論理レベル）
論理レベル、つまり、具体的な製品など分類されたアプリケーション間の連携を表したモデルです。
実例レベル
静的モデル
アプリケーション構成（実装レベル）
実装レベル、つまり、電子ファイルとして存在する具体的なアプリケーションの構成です。動的モデル
アプリケーション間連携モデル（実装レベル）
実装レベル、つまり、電子ファイルとして存在する具体的なアプリケーション間の連携を表したモデルです。
次の図は、記事「データマネジメントの導入」で紹介する山田産業のトランザクション処理アプリケーション構成（概念レベル）の例です。
トランザクション処理アプリケーションとは、企業の基本的な定型業務を自動化するアプリケーションのことです。
次の図は、記事「データマネジメントの導入」で紹介する山田産業のアプリケーション間連携モデル（概念レベル）の例です。
次の図は、記事「データマネジメントの導入」で紹介する山田産業のアプリケーション構成（論理レベル）の例です。
トランザクション処理アプリケーション、分析アプリケーション、変革アプリケーションは、「戦略マップ」という書籍のアプリケーション分類を適用しています。
トランザクション処理アプリケーション
企業の基本的な定型業務を自動化するアプリケーション。分析アプリケーション
分析、解釈、情報と知識の共有を促進するアプリケーション。変革アプリケーション
企業の現行のビジネスを変革するアプリケーション。
トランザクション処理アプリケーション、分析アプリケーション、変革アプリケーションに分類されている黒字の部分が概念レベルのアプリケーションで、色をつけて記述されているSCMシステム、PLMシステム、CRMシステム、ERPシステム、市場品質監査システムが論理レベルのアプリケーションです。
なお、SCMシステム、PLMシステム、CRMシステム、ERPシステム、市場品質監査システムには、具体的なパッケージ製品、あるいは、固有のシステム名が設定されているものとします。
次の図は、記事「データマネジメントの導入」で紹介する山田産業のアプリケーション間連携モデル（論理レベル）の例です。
