有名なZahmanモデルは、企業のアーキテクチャとは何かという質問に答えようとし、どのようにモデル化されるべきかについて話します。 このモデルの基礎となるのは、誰が、いつ、どこで、なぜ、どのように何かに何かをするかという質問に答えることです。 これは、企業のアーキテクチャを記述するための論理的なフレームワークであると思われ、多くの人がそうだと考えています。
ただし、このフレームワークをざっと見ただけでも不満の気持ちが残ります。なぜなら、誰が、なぜそのパーツを作ったのかという質問に答える方法が明確ではないからです。 誰：イヴァン・イヴァノヴィッチ、またはターナー、その役割はイヴァン・イヴァノヴィッチによって演じられましたか？ 理由：ターナーがタスクを受け取ったため、またはイヴァンイバノビッチが契約を締結したため、彼はそれと引き換えに、食糧と引き換えにターナーの役割を果たしますか？ 理由：Ivan Ivanovichが食べたいのか、部品が組立工場で必要なのか？
このフレームワークのより深い研究により、技術プロセスの記述への適用性について考えることができます。 たとえば、トウモロコシを畑で育てます。 Zachmanモデルを適用して、質問に答えなければなりません。 誰？ トウモロコシ。 何してるの？ 成長しています。 なんで？ これが世界の仕組みだからです。 なんで？ しかし、誰が知っている、なぜトウモロコシが成長するのか！
エンタープライズアーキテクチャの説明のトレーニングを受けた読者がすぐに私を修正します。 彼は私が間違った質問をしていると言うでしょう。 誰が成長するのか、なぜ成長するのか、何が成長するのかを問う必要があります。 しかし、その後、トウモロコシを栽培している被験者の活動を説明することはできますが、成長自体を説明することはできません。 成長プロセスを説明できないという事実に辞任しましたが、未解決の疑問が残っています。トウモロコシを誰が、なぜ成長させるのか（上記参照）？
一見論理的な質問をすると、せいぜいいくつかの答えしか得られず、最悪の場合、まったく得られないことがわかりました。 まったく人がいない完全にロボット化された企業がある場合に極端なケースを取り上げると、「誰？」という質問に対する答えは「誰も」ではなくなります。 その結果、この企業については何も言えません！ 確かに、この状況から抜け出すには、少しcraftな方法が1つあります。神話的な意識を使用し、ロボットをアニメートするだけです。 次に、無生物をアニメートして、次の質問に答えます。 ロボット。 なんで？ このロボットはこのように設計されているか、プログラマーがそのようにプログラミングしたためです。 2番目の質問に対して、再び奇妙な答えが得られます。 なぜそれが起こったのか、そしてどの質問が本当に質問する価値があるのか？ このテーマに関する私の意見を要約し、Zahmanモデルで見つかった論理エラーについてお話します。
Zachmanモデルで求められる質問を見ると、それらが活動理論に正確に対応していることを確認できます。 アクティビティは、被験者（被験者のグループ）の精神機能です。 したがって、ザックマンの質問に答える際に、対象の精神機能のモデルを構築しています。 被験者の精神機能を研究する科学は心理学と呼ばれます。 ザックマンは心理学者によって提起された質問に答えていることが判明しました：なぜ被験者はこれまたはその行動をするのですか？ または、特定のアクションを実行するように被験者を動機付ける方法は？ これらの質問は確かに興味深く、重要ですが、それらへの答えは企業のアーキテクチャの説明ですか？ この質問に答えるには、企業とは何かを理解する必要がありますか？
それでは、エンタープライズデザインは実際にどのように行われ、どのようなアーティファクトが発生しますか？ 企業を設計する前に、企業の要件のモデルが構築されます。 要件モデルは、すべての参加者、請負業者、および利害関係者によってこの会社に提示された要件に基づいて形成されます。 ITのアナログは、ソフトウェア製品の要件です。 さらに、これらの要件に基づいて、必要な詳細度を備えたエンタープライズプロセスのモデルが構築されます。 ITの類似物は、ソフトウェア製品の機能のリストになります。 次に、機能オブジェクトのモデルが、上記のプロセスに参加する必要がある技術的な場所の、または専門的な言語で構築されます。 ITの類似物は、手順の説明と、どの手順がどの機能に関与するかの説明になります。 次に、リストされた技術的な場所の役割を果たすことができる機器を選択します。 ITの類似物はプログラムコードです。
企業は、特定の要件を満たすように設計された機能エンティティです。 この意味で、企業は時計や生産ラインなどのオブジェクトと変わりません。 多くの場合、機能オブジェクトという用語の代わりに、技術的な場所という用語を聞くことができます。 機能的な場所は、機器が機能的な場所として機能するという点で機器とは異なります。 たとえば、変圧器は電圧変換器の役割を果たしますが、異なる変圧器は同じ変換器の役割を果たすことができます。 技術的な場所のもう1つの例は、役職、部署、部署、スタッフです。 たとえば、ターナーは部品の製造機能に関与しています。 これは技術的な場所であり、その役割はさまざまな時間にさまざまな機器（個人）によって実行できます。 技術空間と機器のユニットをモデル化することの難しさについて、「 企業の資産をモデル化する：現代の標準と実践」の記事で簡単に書きました 。
技術的な場所をモデル化する場合、これらのプロセスのプロセスと参加者について説明します。 変圧器がアニメーション化された存在ではないため、変圧器が電圧を変換できないのは、正確には参加者であり、出演者ではないことに注意してください。 これについては、以前の記事「 モデリング活動と神話意識 」で書いています。 それでも、変圧器が電圧を「変換」すると言うと、これは次のように明らかになります。変圧器は電圧変換器の役割を果たします。 換metについては、著者のジョージア・ラコフ、マーク・ジョンソンによる「Metaphors We Live」という本で読むことができます。 別の一般的な言い回しは、「コンピューターが問題を解決する」ということわざです。 トランスフォーマーまたはコンピューターが実際に何かをしていると本当に信じている人は、神話的な意識を使って無生物を動かします。
これまでは、目標、パフォーマー、因果関係について語っていませんでした。 要件、機能、およびこれらの機能の参加者-技術的な場所について話しました。 目標は企業の要件を形成する段階にとどまり、それ以上進むことはありませんでした。 私たちはこれらの目標を知っているかもしれませんが、知らないかもしれません-企業のモデルにとってこれは重要ではありません。 エンタープライズモデルは、これらの要件がどこから来たのではなく、どのように要件を満たすのかという質問に答えます。 活動の参加者を記述するために活動の理論を使用する必要がないため、パフォーマーもいません。 私たちは因果関係を構築していません。 因果関係のモデルを構築する必要がある場合、これは別の追加モデルです。 これは、技術者が企業を設計するときに使用する知識であり、そのようなモデルを作成する人は誰もいません。 これは業界の知識であり、長年にわたって研究所で教えられてきました。 飛行機が飛ぶ理由をモデル化するのは非現実的に難しく、誰もそれを行いません。 彼らは単に飛行機の飛行をシミュレートします。
したがって、Zahmanモデルには企業の要件は含まれず、プロセスモデルが含まれますが、かなり具体的な方法で-プロセスエグゼクティブを示します機器の一部。
前にも言ったように、Zahmanモデルは活動に関するものです。 アクティビティを記述する方法として、Zahmanモデルがその意図された目的に使用された場合、それは素晴らしいでしょう。 これにより、作業における人々の動機と関心を分析することが可能になりますが、問題はこのモデルが誤って使用されていることです。 たとえば、「なぜターナーで部品を削るのですか？」という質問には、「組立工場で必要です」という答えが得られます。 しかし、彼女が組立工場を必要としているのは、ターナーがなぜ部品を研ぎ澄ませるのかという質問には答えません。 答えは提起された質問に対するものではなく、他の誰かに対するものでした。 たとえば、そのような答えの場合、正しい質問は次のようになります。どのプロセスで、またはどの操作でターン部分を関与させる必要がありますか？ または、どの職場で必要ですか？ これは「なぜ」という質問ではないことがわかります。 さらに、私はザックマンが何かをする能力を備えたコンピューターまたは情報システムに恵まれていることに非常に困惑しています。 ほとんどの場合、彼はそれらをアニメーション化しませんが、モデリングではメトニーを使用しますが、これは私の意見では受け入れられません。
正しい質問は次のとおりです。企業の要件は何ですか？ 企業ではどのようなプロセスが行われますか？ どのプロセスにどの技術的な場所が関係していますか？ どの機器がどの技術的な場所の役割を果たしますか？
実際には、それだけです。 よろしくお願いします！