Enterprise Unified Process

RUP の拡張: Zachman フレームワーク

Order now! このホワイトペーパーの題材は、Scott W. AmblerJohn NalboneMichael Vizdosによる「エンタープライズ統一プロセス: IT 業務の全体最適化のためのプロセスフレームワーク」から抜粋したものです。

by Scott W. Ambler

エンタープライズ・モデリングや一般的なモデリングについて、人はいつもある基本的な質問をしているように思えます。1 つのプロジェクトにおいて、エンタープライズ・ビジネスモデリング、エンタープライズ・アーキテクチャモデリング、設計モデリングといったさまざまなアプローチは、それぞれ互いにどう関係しているのか、という質問です。1980 年代に John Zachman によって作られた Zachman フレームワーク (ZF) には、まさにこの質問に答える1つの優れた方法が示されています。図1の ZF は、エンタープライズモデリングに関する一連のものの見方を表したものです。フレームワークの横の行はさまざまな種類の利害関係者の視点を表し、縦の列はアーキテクチャのさまざまな側面や視点を表しています。もともとモデルは、1つの列の中では各行の利害関係者の視点を反映して発展/書き換えられ、1つの行の中では互いに矛盾しない状態になっているはずです。

 

図 1 Zachman フレームワーク

What
(データ)
How
(機能)
Where
(場所)
Who
(人)
When
(時間)
Why
(動機)
スコープ
{文脈的}
プランナー
ビジネスにとって重要なものの一覧 ビジネスで行う処理の一覧 ビジネスが行われる場所の一覧 ビジネスにとって重要な組織の一覧 ビジネスにとって重要なイベント / サイクルの一覧 ビジネスの目的 / 戦略の一覧
エンタープライズモデル
{概念的}
事業経営者
例: 意味モデル 例: ビジネスプロセスモデル 例: ビジネスロジスティックスシステム 例: ワークフローモデル 例: マスタースケジュール 例: ビジネスプラン
システムモデル
{論理的}
設計者
例: 論理データモデル 例: アプリケーションアーキテクチャ 例: 分散システムアーキテクチャ 例: ヒューマンインターフェース・アーキテクチャ 例: プロセス構造 例: ビジネスルールモデル
技術モデル
{物理的}
実装者
例: 物理データモデル 例: システム設計 例: 技術アーキテクチャ 例: プレゼンテーション・アーキテクチャ 例: 制御構造 例: ルール設計
詳細表現
{範囲外}
開発委託先
例: データ定義 例: プログラム 例: ネットワークアーキテクチャ 例: セキュリティアーキテクチャ 例: タイミング定義 例: ルール定義
機能するシステム 例: データ 例: 機能 例: ネットワーク 例: 組織 例: スケジュール 例: 戦略

 

ZF には次のような長所があります。

  1. データ派の人々に十分に受け入れられていて、エンタープライズ・アーキテクチャのデファクトスタンダードだと考えられています。
  2. エンタープライズモデルに含めなければならない考え方が定義されていて、その内容を EUP などのプロセスに適用することができます。
  3. エンタープライズ・モデリングにはエンタープライズ・アーキテクトや開発者以外にも複数の利害関係者が関わっていること、その人たちにモデリング作業に加わってもらう必要があることが、ZF から明らかに分かります。

しかし、ZF には短所もあります。

  1. 文書を大量に作成するアプローチになりがちです (絶対にそうなるとは限りませんが) 。図 1 には 36 のマスがあり、そのそれぞれに対して 1 つ以上のモデルが挙げられています。
  2. 重量級プロセスによる開発アプローチになりがちです。ZF をサポートするために一連の厳密なプロセスを定義してしまう可能性があることは、これを見るとすぐに分かります。
  3. 開発者の世界ではあまり受け入れられておらず、これについて聞いたことがあるという開発者もほとんどいません。
  4. ZF はトップダウンの開発アプローチを推進しているように見えます。最初にZFについて読んだ人はたいてい、1 行目のモデルから作業を始め、次に 2 行目のモデルに取り掛かるといったトップダウンのアプローチだと考えてしまいます。しかし実際のところはそうである必要はなく、任意のマスから始めて、反復的に他に進んでいくことができます。
  5. 従来型のデータ中心手法に片寄っているように見えます (だからデータ派の人々で人気があるのでしょう) 。

 

私たちの経験では、長所に着目し、短所に対処すれば、RUP や EUP に ZF をうまく適用することが可能です。図2は、RUP や EUP の作業分野に当てはめられるよう、私たちが ZF をどう拡張したかを示しています。見れば分かりますが、かなり大きな変更が加えられています。

  1. 6 つの行を EUP の 17 の作業分野に置き換えて、一連の視点をさらに詳細化しました。ZF のトップダウンのアプローチに合わせて、最初にエンタープライズ管理作業分野の行を、それからプロジェクトレベルの作業分野を置きました。作業分野を行として示すことによる 1 番の利点は、フレームワークの列が示している質問を EUP の各側面にどう適用すればよいかが明らかになることです。しかし残念なことに、このやり方をすると ZF の欠点の多くも浮き彫りになりかねません。
  2. 費用の列を追加しました。DAMA 2004 カンファレンスのパネルで、Graeme Simsion は、ZF は英語の 1 単語の疑問詞を集めただけであり、もし John Zachman が違う言語を話していたなら ZF は異なるものになっていただろうと、感慨深げに言いました。たとえばフランス語には「how much」や「how many」を表す「combien」という単語があります。IT組織で金銭面が重要なことは明らかなので、7番目の列を追加したわけです。この列のほとんどのマスは、その作業分野を効果的に実施することでどのような節約が可能になるかを示しています。もちろん、各作業分野の作業を行うための運用コストもかかりますが、表をシンプルにするためにそれは表示していません。おもしろいことに、ドイツ語を使えばこれらの列のタイトルはすべて、「w」で始まる1単語の疑問詞にすることができます。順に「was」、「wie」、「wo」、「wer」、「wann」、「warum」、「wieviel」です。
  3. 最初の列を見直しました。「What」という疑問に対応する最初の列が、実際はデータの問題ではなく構造の問題であることを示しました。このようにシンプルに一般化することで、ZF のデータ指向的な傾向を取り除き、データ指向の成果物の他にもさまざまな選択肢があることを明示できます。
  4. マスには対処しなければならない問題を記述しました。各マスでは、対処しなければならない可能性のある問題を示し、その問題を調査するための成果物の候補を挙げています。マスの中には空白のものがありますが、それはその列がその作業分野に該当しないためです。

 

図 2. ZF と EUP の作業分野とのマッピング

What
(構造)
How
(機能)
Where
(場所)
Who
(人)
When
(時間)
Why
(動機)
費用/効果
(財政)
エンタープライズ管理作業分野 エンタープライズ・ビジネスモデリング もっとも重要なビジネス上の概念 (エンタープライズ用語集) エンタープライズ・ビジネスプロセス (プロセスモデル) 国際的視点での拠点 (拠点の地図) 組織戦略
(組織図)
業務イベントと業務計画 エンタープライズ構想 / ミッション 会社の財務
ポートフォリオ管理 システムとその相互関係の一覧 ビジネスプロセスとシステムとのマッピング プロジェクトチームと拠点のマッピング プロジェクトチームの割り当て IT 計画 IT 構想 管理の改善による節約
エンタープライズ・アーキテクチャ ドメインアーキテクチャ (UML コンポーネント図) ワークフローアーキテクチャ 物理ネットワークアーキテクチャ (UML 配置図) 実際の/潜在的な相互作用 ミドルウェアおよびスケジューリングアーキテクチャ エンタープライズ技術要求 共通アーキテクチャによる節約
戦略的再利用 ドメインコンポーネント 機能 (Web サービス、CICS トランザクション)
ユーザインターフェースコンポーネント
ルールベース 再利用による節約
要員管理 職位と職位間の関係 それぞれの拠点における役割と役割間の関係 オフィスとオフィス間の関係 人事に関する哲学と戦略 年に 1 度の見直し、プロジェクトマイルストーン キャリア管理戦略 チーム構成の改善による節約
エンタープライズ・アドミニストレーション 情報資産 (全社的データソース、ライセンス、…) ガイダンス (標準および指針) 物理資産 セキュリティポリシー

共通プラットフォーム、ガイダンス、コーポレートライセンスによる節約
ソフトウェアプロセス改善/TD>
ソフトウェアプロセス定義 ソフトウェアプロセスの範囲 (例: 一部 vs 全体) SEPG (Software engineering process group) の指示
IT 部門の改善目標 プロセスの改善による節約
基本開発作業分野 ビジネスモデリング もっとも重要なビジネス上の概念 (プロジェクト用語集) プロジェクトミッション、戦略プロセス (プロセスモデル) プロジェクトの視点での拠点 (拠点の地図) 影響を受ける職位 (組織図) 業務イベント システム構想/ミッション ビジネスプロセスのリエンジニアリングによる節約
要求 ドメインモデル (CRC カード、UML クラスモデル) システムの使い方 (ユースケース)
システムのユーザ (アクター、登場人物) タイミング要求 (ユースケース、ビジネスルール) 経営方針および技術要求 利害関係者のニーズの理解向上による節約
分析/設計 構造設計 (UML クラス図、物理データモデル) ドメインクラス/サービスの実装設計 プロセスと場所とのマッピング ユーザインターフェース設計 イベントスケジュール ビジネスルールと「〜性」
実装 ソースコードとデータ定義言語 (DDL) ソースコードと DDL ハードウェア、ネットワーク、ミドルウェア ユーザインターフェースの実装 システムトリガーの実装 ビジネスルールの実装
テスト テストスイート テスト テスティングフレームワーク テスト計画 テストおよび不具合追跡の戦略 品質目標 品質改善による節約
導入 インストールパッケージ インストールスクリプト



システム導入コスト(エンドユーザのトレーニングなど)
補助作業分野 構成及び変更管理 (C&CM) 構成ビルド ビルドスクリプト CM リポジトリ C&CM 計画 C&CM 戦略 品質目標
プロジェクト管理 プロジェクトタスクリスト (ガントチャート) プロジェクトスケジュール (ガントチャート) チームの作業場所の戦略 人材計画 プロジェクトスケジュール (ガントチャート) プロジェクト憲章
環境 必要なツールの一覧とガイダンス ツールインストール計画



ツールや手法の統一による節約
運用及びサポート 導入されたクラス、コンポーネント、テーブル、… 導入された機能/操作 導入されたハードウェア、ミドルウェア、ソフトウェア 導入されたユーザインターフェース (ドキュメントを含む) 導入されたシステム 導入されたソフトウェア

 

EUP で ZF を使っても使わなくても良いことを忘れないでください。対処しなければならない非常に重要な問題に気づくことができるため、ZF はモデリングや開発の作業にとってとても優れた手引きとなると私たちは考えています。ZF のこの拡張版を組織に適用する場合には、以下の点を心がけると役立つでしょう。

 

 

 

本ページの元ページ: (改訂されている可能性あり) www.enterpriseunifiedprocess.com/essays/zachmanFramework.html

Copyright 2004-2007 Scott W. Ambler


元ページ公開日: 2004/10/22
日本語訳最終更新日: 2008/6/24