視点(ビュー)が処理単位を決める
2007/12/27実装独立な(概念)レイヤーで考えられる処理は、入力処理・出力処理・加工処理です。ユーザに見えるデータ項目の組が認識され、その単位でカプセル化すべき処理が決まります。
実装独立な(概念)レイヤーで考えられる処理は、入力処理・出力処理・加工処理です。ユーザに見えるデータ項目の組が認識され、その単位でカプセル化すべき処理が決まります。
「部分の中に全体がある」は、エンタープライズアーキテクチャの講演やお客様との打ち合わせで、最近よく使っているフレーズです。
普通に考えれば、「全体の中に部分がある」のですから、逆説的な表現です。
去年は、建築偽装問題や有名企業の不正などが明らかになりました。仕事を始めた当初は、みなそれぞれに理想や熱い思いを抱いていたはずです。どこで階段を踏み外してしまうのでしょうか?利益を上げなければならないプレッシャー?
Partyパターンはオブジェクト指向やデータモデリングの世界で有名なパターンです。ここではPartyパターンをデータモデルパターンと認識して説明します。
トップダウンにモデリングする方法は、エンティティを始めに認識し、従属するデータ項目をそこに定義します。しかし、この方法では人の頭にあるものをただ表現するだけです。
我々は、自然言語を使ってビジネス世界の出来事を共有します。よく5W2Hというように、Who・Where・Whatなどを区別して理解するのが一般的です。
取引先エンティティは、社内組織エンティティと同様にWhoやWhereを表します。社内組織エンティティがどの業界においてもさほど違いがないのに対して、取引先エンティティは業界の特徴が表われます。
エンタープライズアーキテクチャの仕事が最近増えています。しかも、非常に大規模な連結経営のエンタープライズアーキテクチャです。会社数が10〜200あるいはシステム数100〜500の全体最適化です。おそらく10年に一度の需要期なのでしょう。こんな大規模な仕事を同時期にいくつか掛け持ちするのは、非常にきついです。私の担当はデータアーキテクチャですが、業務アプリケーション構成も同時に考えなければなりません。
今、いたるところでデータの整合性に関する問題が顕在化し、これを解決する活動が盛んです。コード統一・マスタ統合と称して、データを標準化するプロジェクトは、データの不整合を解決する典型的な例と言えるでしょう。
「人事組織・会計組織・物流組織の3つの社内組織エンティティが存在する」は、1つのパターンです。
しかし、このパターンは、現状を素早く調査するために知っておくべきもので、新規設計の美しい型ではありません。
光は粒子の性質を示すこともあれば波の性質を示すこともあります。同時に粒子であり波であることはありえないそうです。たとえば、オシロスコープで観測した光は波であって粒子ではありません。
従来のシステム開発方法論は概要から詳細に作業工程が進みました。その際、実装独立に決められる仕様(概念仕様)も実装従属に決めなければならない仕様(実装仕様)も混在していました。
私たちのデータ中心アプローチは、まず概念仕様を詳細化します。一方で、実装仕様特に制御構造を決めておき、最後に概念仕様を実装仕様にマッピングします。
XMLのタグはデータ項目の表現法の一種です。XMLが登場したことによって、今までのデータの扱い方は大きく変わりました。従来は、一度決めたデータ項目の組たとえば画面・帳票・論理レコードを変更することは非常に困難でした。しかし、XMLを使うことによりデータ項目の追加、削除が簡単になり、変更に強いシステム構造を実現できるのです。XMLは、メタデータとアプリデータをいつもいっしょに扱うからです。
データ制約はデータ項目の粒度で記述する処理ですが、データ制約の他に「データのかたまり」すなわち画面・帳票の粒度で記述する処理もあります。画面・帳票の粒度の処理は、入力処理と出力処理の2つになります。
機能中心の処理設計は、概要機能を詳細に分解し、機能自身とその機能に必要なデータを定義します。オブジェクト指向は、振る舞いを持つ対象をオブジェクトとして認識し、その振る舞いに必要とされるデータを定義します。これに対して、データ中心は、データのかたまりあるいは1つのデータを認識し、そのデータがあるところに処理を記述します。
BPMN(ビジネスプロセスモデリングノーテーション)は、業務フローを記述する言語です。先日BPMNを少し勉強したのですが、驚くほどIPF(インフォメーションプロセスフロー)と似ていました。IPFとは、弊社が20年使っている業務フローを記述する言語です。
業務群から1単位の業務を切り出す視点の1つに役割(論理組織)があります。
役割(論理組織)の粒度は、抽出する業務の数をコントロールするのに役立ちます。役割(論理組織)の粒度は、粗い方から並べると、企業、部、課、担当の順になります。
業務群から1単位の業務を切り出す視点の1つにトリガがあります。
トリガとは、端的に言えば「条件」です。ある業務が始まるきっかけとなる条件は、すべてトリガとみなすことができます。
その中で、業務を切り出すときに着目するトリガについて説明します。
複数の参加者で業務フロー図を分担して記述する場合、いくつかの注意事項があります。それぞれが勝手バラバラに記述すると、全体の整合性が保てなくなるためです。
「DOAだから業務機能階層図や業務フロー図を作成しないですよね!」などと言われたことがあります。その人達の認識では、「データ中心というのはデータモデルと画面・帳票イメージだけで設計していく」らしい。しかし、そんなことはありません。今日は、業務機能の話です。
データ中心アプローチ(DOA)という言葉が初めて雑誌に取り上げられてから、今年でちょうど22周年です。その間、多くの人々がDOAに携わり現在まで進化してきました。
本質的であればこそ、時代の趨勢を乗り越えて生き残っているのでしょう。
DOAの普及とさらなる発展のために、有志が集まってDOA+コンソーシアムを設立しました。現在設立4年目ですが、会員数は1000名を超えるまでになりました。
http://www.doaplus.com/
データ中心アプローチは、ビジネス系の業務アプリケーションを構築・保守するための方法論であり、設計思想や価値観を含みます。
データモデルを記述しただけでデータ中心アプローチであると言う人がいるかもしれませんが、私はもう少し広く捉えています。
グローバル企業のデータディクショナリを構築するときの話です。一般に、エンティティやデータ項目の名称は、日本語、英語、現地語の3つを用意します。
定義域は、標準定義域と活動定義域の2つに分類できます。
典型的な標準定義域は、日付、金額、率、数量、文、コードなどです。
活動定義域は、商品コード、取引先コードなど、実際に使われている(活動している)値の集合を表します。典型的なものは、エンティティのKEYです。参照KEYにおける参照制約は、参照KEYの値がKEYの活動定義域に含まれていることを保証するものです。
電話番号や郵便番号は、標準定義域とは異なります。どちらかと言えば、活動定義域に対応すると考えられます。
電話番号というデータ項目をモデリングする際、これをKEYとしてもつエンティティ「電話」を認識する企業はまれです。電話を管理する権限や責任をもっているわけではないためです。当然、KEYである電話番号の発番権限もありません。