RUP の拡張: Zachman フレームワーク |
このホワイトペーパーの題材は、Scott W. Ambler、John Nalbone、Michael Vizdosによる「エンタープライズ統一プロセス: IT 業務の全体最適化のためのプロセスフレームワーク」から抜粋したものです。 |
エンタープライズ・モデリングや一般的なモデリングについて、人はいつもある基本的な質問をしているように思えます。1 つのプロジェクトにおいて、エンタープライズ・ビジネスモデリング、エンタープライズ・アーキテクチャモデリング、設計モデリングといったさまざまなアプローチは、それぞれ互いにどう関係しているのか、という質問です。1980 年代に John Zachman によって作られた Zachman フレームワーク (ZF) には、まさにこの質問に答える1つの優れた方法が示されています。図1の ZF は、エンタープライズモデリングに関する一連のものの見方を表したものです。フレームワークの横の行はさまざまな種類の利害関係者の視点を表し、縦の列はアーキテクチャのさまざまな側面や視点を表しています。もともとモデルは、1つの列の中では各行の利害関係者の視点を反映して発展/書き換えられ、1つの行の中では互いに矛盾しない状態になっているはずです。
What (データ) |
How (機能) |
Where (場所) |
Who (人) |
When (時間) |
Why (動機) |
|
スコープ {文脈的} プランナー |
ビジネスにとって重要なものの一覧 | ビジネスで行う処理の一覧 | ビジネスが行われる場所の一覧 | ビジネスにとって重要な組織の一覧 | ビジネスにとって重要なイベント / サイクルの一覧 | ビジネスの目的 / 戦略の一覧 |
エンタープライズモデル {概念的} 事業経営者 |
例: 意味モデル | 例: ビジネスプロセスモデル | 例: ビジネスロジスティックスシステム | 例: ワークフローモデル | 例: マスタースケジュール | 例: ビジネスプラン |
システムモデル {論理的} 設計者 |
例: 論理データモデル | 例: アプリケーションアーキテクチャ | 例: 分散システムアーキテクチャ | 例: ヒューマンインターフェース・アーキテクチャ | 例: プロセス構造 | 例: ビジネスルールモデル |
技術モデル {物理的} 実装者 |
例: 物理データモデル | 例: システム設計 | 例: 技術アーキテクチャ | 例: プレゼンテーション・アーキテクチャ | 例: 制御構造 | 例: ルール設計 |
詳細表現 {範囲外} 開発委託先 |
例: データ定義 | 例: プログラム | 例: ネットワークアーキテクチャ | 例: セキュリティアーキテクチャ | 例: タイミング定義 | 例: ルール定義 |
機能するシステム | 例: データ | 例: 機能 | 例: ネットワーク | 例: 組織 | 例: スケジュール | 例: 戦略 |
ZF には次のような長所があります。
しかし、ZF には短所もあります。
私たちの経験では、長所に着目し、短所に対処すれば、RUP や EUP に ZF をうまく適用することが可能です。図2は、RUP や EUP の作業分野に当てはめられるよう、私たちが ZF をどう拡張したかを示しています。見れば分かりますが、かなり大きな変更が加えられています。
図 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 のこの拡張版を組織に適用する場合には、以下の点を心がけると役立つでしょう。
簡潔にしておく: すべてのマスの成果物を作成する必要はありません。大切なのは、そのマスに書かれている問題を少なくとも考慮することです。実際に、そうしようと思えば、アジャイルに ZF を使うことも可能です。その秘訣は、ZF を取り巻く、文書を大量に作成する官僚的なプロセスを避けることです。目標は動くソフトウェアの開発であって、大量の凝ったモデルやドキュメントの作成でないことを覚えておいてください。
選択肢があると覚えておく: 各マスが示しているのは要求される視点であって、推奨されるモデルではありません。たとえば図1の ZF の構造の列でいうと、 David Hay は、2 行目で様々な異なる言語で表現されるデータモデルを、3 行目で収束するエンティティ/リレーションシップモデルを、4 行目でデータベース設計を作成するよう述べています。 Moriarty は同じ行で、それぞれビジネスクラス図、クラス図、スキーマデータモデルを作成するよう述べています。オブジェクト指向開発者なら、おそらく、コンポーネント図、クラス図、別のクラス図を提案するでしょう。この 3 つの方法はどれも有効ですが、どれも個々の方法論者の経験や先入観を反映しています。それよりも、それぞれのマスが表す視点を理解し、各種モデリング成果物の長所/短所を理解し、適切な成果物を使う方が、ずっとよいやり方だといえるでしょう。
本ページの元ページ: (改訂されている可能性あり) www.enterpriseunifiedprocess.com/essays/zachmanFramework.html Copyright 2004-2007 Scott W. Ambler
|