エンタープライズ アーキテクチャ分野で長老の一人と考えられている、John Zachman氏は最近、彼の人気のあるフレームワークの 第3版をリリースした。このバージョンには、幾つかの小さなテキストの変更、改善された図、そしてこの成果物をフレームワークではなく、オントロジーとして再分類するための微妙な取り組みが含まれている。
Zachman Framework は、エンタープライズ アーキテクチャのような複雑なエンティティに関する、記述方法の構造を明確に述べている。 エンタープライズ アーキテクチャ方法論の比較の中で、Roger Sessions 氏は、フレームワークの血筋について述べている。
Zachmanの考え方は、ビジネス価値とアジリティが、あらゆる重要な観点からそれぞれの重要な課題をはっきりと見るシステムアーキテクチャへの全体的なアプローチによって、最も上手く実現し得る、というものである。システムをアーキテクチャ化する、彼の複数視点のアプローチは、 Zachmanが当初 information systems architectural framework と表現し、すぐに enterprise-architecture frameworkと名称変更した。
明白に、このフレーム ワークは、6x6マトリクス表現の基盤を形成する分類のペアを識別する。一番目の分類は、列を占め、“What” (製品目録), “How” (プロセス), “Where” (分散ネットワーク), “Who” (責任), “When” (タイミング) 、“Why” (動機)から成る。マトリクスの行は、登場人物とその人の視点から成り、“Executive Perspective” (計画者), “Business Management Perspective” (オーナー), “Architect Perspective” (デザイナー), “Engineer Perspective” (作成者), Technician Perspective” (コンポーネント作成者) 、“Enterprise Perspective” (ユーザー)を含む。各セルは、グラフィックな概要の中心部を表し、その成果物が分類の交点を満足するように書かれている。
Zachman自身もフレームワークの支持者も、直ぐにこのフレームワークは方法論ではない、と言っている。成果物を創りだすのに必要なデータを収集する規範的な戦略は無いし、いかにアーキテクチャそのものを作るかをユーザーに述べていないし、アーキテクチャの成熟度を測ることもできない。これは、TOGAFのような実際のEA方法論を補完するものである。
フレームワークのこの第3版は、Business Rules JournalのRon Ross と Keri Anderson Healy氏によって 指摘された 2,3の主要な変更を入れている。まずフレームワークは、オントロジー (“The Enterprise Ontology”)として識別するサブタイトルを導入した。また “データ” という言葉がマトリクスの第一列からなくなったのは、非常に際立つ。
幾つかの新しい用語が取って変わっているが、「ビジネス」メッセージをより良く伝えることを狙っている、と Zachman氏は説明している。
「私は、情報コミュニティから来ましたので、第１列にデータのような言葉を最初に使いました。大きな誤りです！ 人々はこのフレームワークをITに関するものだ、と考えてしまいました。人々が最初に見た言葉が「データ」でした。
Anderson HealyとRossの両氏は、フレームワークの一番下の行への変更を指摘した。
第6行が何を意味するかをもっと良く伝えるために、調整がなされてきました。フレームワーク図の初期のバージョンでは、第6行は単に銀色でした。それはいつも「エンタープライズ」でした。第6行はその上の5つの行とは実際違っています。その上の行は、実際のモノ自身ではなく、エンタープライズにおけるモノのエンジニアリング仕様書です。
LinkedInグループの議論 “Time to rethink Zachman?”で、一人の参加者がZachmanの寄与の永続的な価値を以下のように説明している。
Zachmanに関わっているか？私の答えは、明快にイエスであるが、条件がある。この世界の指導的な思想家として、 Zachmanはこの分野といかに考えて、エンタープライズをアーキテクチャ化するかについて、核心を突く影響を与えてきました。 Zachmanを無視して、彼はもはや必要ない、と言うことは、ローマやギリシャ時代のアーキテクチャと、それらと現代の建築物との関係を忘れるようなものです。しかし、ローマやギリシャ時代のアーキテクチャとの比較のように、その関連性は、基本に関するモノ以上です。原理や理論は、エンタープライズアーキテクチャが一体どういうモノかを理解するのに絶対に必要です。しかし、それは、非常に多くの他のモノと混ぜ合わせる必要があります。