エンタープライズアーキテクチャとAlchemy Enterprise。 主な神話

錬金術師は 、現代の科学者とほぼ同じものに駆り立てられました 。 世界がどのように機能するかを理解したかったのです。 彼らはできる限りそれを研究しました。 後に、古代の原始科学は現代の科学状態に進化しました。



これは現代の規律「エンタープライズアーキテクチャ」にも当てはまります。「21世紀の錬金術師が動いた...」と「...エンタープライズの仕組みを理解する」という2つの明確化だけが必要です。



ITインターネットのページでは、トピック「エンタープライズアーキテクチャ（EA）」は最も人気のあるトピックの1つです。 それは、「大文字」についての「建築家」アプローチ、数十のフレームワークについて、「大文字の」建築家のように感じることを可能にします。



多くの人が書いたり書いたりします。 記事「エンタープライズアーキテクチャ」の読者は、「王様のドレス」を称賛してうなずいてうなずきました。 「肥沃な土地」でEAはあらゆる種類の「建築家」と離婚しました。



書籍、学問分野、コンサルティングプロジェクト、グループ、コンソーシアム、EAに特化した機関全体（IFEAD、iEAiなど）、グローバル組織（GEAO）、同名のジャーナル（Journal of Enterprise Architecture）、国際標準（ISO 15704、42010など） 。）などなど。



それにもかかわらず、EAのコンテキストでは、「アーキテクチャ」とは何か、「エンタープライズ」とは何か、「エンタープライズアーキテクチャ」とは何か、またEAの主な消費者は誰か、なぜこのEAの具体例はないのかという疑問が残ります。



メソッド、参照モデル、およびアーキテクチャフレームワーク（通常「AF」で終わる：FEAF、TEAF、DoDAFなど）-「汚れのように」、しかし実際の結果を見る場所はありません。



はい、この分野の重要な特徴です。パブリックドメインには、この同じ不思議なエンタープライズアーキテクチャの具体的な完全な例はありません。



建築家は、それがNDA、「大きな秘密」、チップボード（おそらく「国家秘密」でさえある）であると言います。 しかし、「アーキテクチャ」はどのようにして秘密にすることができますか？ それが認識できるようにするための「アーキテクチャ」である理由です：区別可能で比較可能です。 しかし、「企業の錬金術」-厳重に守られるべきです。



「リトマス試験」として-記事でなされた結論の確認または反論として、彼らの「家庭建築」の説明のための競争が発表されます。記事の終わりを参照してください。 単純な問題を解決できないのに、なぜ複雑な問題の解決に着手するのか-EAと同じフレームワークであなたの世帯のアーキテクチャの説明を提供しますか？



ファッショナブルであると同時に素晴らしいエンタープライズアーキテクチャを理解しようとしています。

驚いたことに、「エンタープライズアーキテクチャ」（「アナログ」など）が何であるかはまだ明確ではありませんが、窓の外では、「超新星について」、「デジタルエンタープライズアーキテクチャ」、デジタルエンタープライズアーキテクチャをトランペットしています。

1エンタープライズアーキテクチャの神話

1.1情報システムアーキテクチャのフレームワーク

最も人気のある神話から始めましょう。 これは、「エンタープライズアーキテクチャ」を「エンタープライズ情報システムのアーキテクチャ」に置き換えるときです。 EAはまったくITアーキテクチャではありません。「家具工場のアーキテクチャ」というタイトルのシートに、SOAまたはIT界からの同様のホラーストーリーの碑文がある大きな広場を見たら、知っておくべきです。これは「不合理な誤解」（妄想）または「古典的な」意識詐欺です。



90％以上のオブジェクトがITからの名前である「エンタープライズアーキテクチャ」という見出しのあるエンタープライズのディレクターが写真（スキーム）を持ってくると、写真はおかしく見えます。



これに対して、ディレクターは次のように述べています。「私は15年間エンタープライズを運営してきましたが、あなたが示した名前の90％以上を理解していません（初めて「SOA、コーポレートクラウド」などを見る）、あなたは私のエンタープライズのアーキテクチャを知らないと言いたいです？”これはEAの消費者の問題です。



構造、フレームワーク、説明へのアプローチ、原則、フレームワーク方法論（フレームワーク）のよく知られた記述のほとんどは、ITアーキテクチャ、情報システムのアーキテクチャの記述のために特別に作成されました。 最初は、1984年、1987年、1992年には、たとえば「情報システムアーキテクチャのフレームワーク」JA Zachman

ザックマン87（5x3）

Zachman92（5x6）

より正確には、ISAフレームワーク（情報システムアーキテクチャ）という名前が使用されます。



しばらくして、IBM（J. Zahmanが働いていた）を含むIT巨人の「軽い」手からの「異なる規模が必要である」という理解を通じて、「情報システムのアーキテクチャの構造」は「企業のアーキテクチャの構造」と呼ばれ始めました（置き換えられました）。 このような「魔法」の助けを借りて、ITの要素（アーティファクト、エンティティ）の議論から「エンタープライズビルディング」の議論への「定性的な移行」が行われました。



これは、異なる規模、異なる価格タグと予算（EAは安くは発生しません）、異なる方向/規律のステータスです。



1つは「ITモデリング」、もう1つは「ビジネスモデリング/エンタープライズモデリング」です。 同様に、BPMという用語による概念の「魔法の」代替は、 ビジネスプロセス：すべての起動と混乱の方法で示されました。 第1章



ITの伝説によると、ITアーキテクチャを構築するアプローチは、ITシステムだけでなく、企業全体を説明するために一般化されました。 しかし、これは物議を醸す声明です。なぜなら、 説得力のある例はまだありません（パブリックドメインのEAの詳細な例）。



そのため、実際のEAと「エンタープライズ情報システムのアーキテクチャ」を区別することを学ぶ必要があります。 これらは「2つの大きな違い」です（ハエとミートボール）。 Real EA-名前の両方の単語が正しく適用されているという事実から始まります。



「エンタープライズシステムアーキテクチャ」という用語が使用されることもありますが、これは「エンタープライズ情報システムアーキテクチャ」「ITアーキテクチャ」と同義語です。 同時に、多くの場合、これはまさに「システム」または「IT」アーキテクチャであることが明確にされます（接頭辞）。 さらに、この用語は「デジタル化」、「自動化」、「情報化」という時代に依存しています。



したがって、意識的にまたはそうではないが、概念の置換、導入された用語の目的の最初の理解があります。



値の置換があります。最初の値の代わりに、特定の数学的装置の構築、新しい工学分野のプロトタイプ、そしておそらく科学的方向性があります。錬金術のレベルに留まったEAのアイデアとその説明へのアプローチを収益化するために、宴会に「ローリング」があります。 これは、エンタープライズアーキテクチャに対する重要な批判です。

1.2 2番目の神話-「建築」

プロセス、設計、システム、統合、プログラムターゲット、その他の「正しい」アプローチなど、多くの「スマートな」アプローチが考案されています。 私は彼が非体系的なアプローチまたは不完全なアプローチに依存していると言って誰かを試してみます。



ほとんどの場合、「正しいアプローチ」についての「美しい」言及の代わりに、例えば、「体系的な」ものの場合に、このまさにシステムの図を与える、詳細を与える方がよい。



「エンタープライズアーキテクチャ」の方向を検討するとき、アーキテクチャアプローチが使用されたと仮定するのは論理的です。 これは何ですか 別の「正しい」アプローチ？



人々が「建築」という言葉を発音するとき、彼らはほとんどの場合、建物や構造の建築を意味します。 アーキテクチャに関連して。



しかし、「アーキテクチャ」という用語には、より広い概念、より深い意味があります。 しかし、EAで（錬金術師によって）意味するのが慣習的ではありません。



何らかの理由で、「EAのIT指向のトレンドセッター」（ITアーキテクトおよびCIOを含む）の解釈では、EAという名前はITの特定の領域であり、EAの「アーキテクチャ」の概念は特別な意味を持ちます（「アーキテクチャ」という用語には一般的に使用されません） ）原則に基づいてのみ：「最初に起きた人、それとスリッパ」。 ITオブジェクトが主にEAを表示する画像に描かれているのはなぜですか？ IT戦略などへの参照はありますか？



Wikiが完全に客観的な名前を付けているという事実にもかかわらず（これらはすべて、一般的にITについて言及せずに）：



エンタープライズアーキテクチャ（EA）は、希望するビジネスビジョンと結果の方向に必要な変更を特定して分析することにより、破壊的な力に対応することにより、積極的かつ全体的な企業管理の分野です。

www.gartner.com/it-glossary/enterprise-architecture-ea

Wikaは同様に曖昧な答えを与えます： en.wikipedia.org/wiki/Enterprise_architecture



エンタープライズアーキテクチャ（EA）は、戦略の開発と実装を成功させるために、統合アプローチを使用して、企業の継続的（永遠！）分析、設計、計画、および実装を明確に定義したプラクティスです。



EAには非常に多くのEAの定義があり、EAについて-明白な何かとして-言うのは無意味です。



EAとは何ですか？

アーキテクチャとは？

1.2.1「詳細」のサブ神話

「アーキテクチャ」の説明は、問題のオブジェクトの特定の要素（エンタープライズとそのコンポーネント）の詳細な説明を意味すると理解される場合があります。仕様タイプの仕様、作業ドラフト\作業文書（建設またはACSのGOSTに適用）まで。 アーキテクチャは詳細な説明ではありません。



アーキテクチャという用語は概念的な表現であり、アーキテクチャの説明は概念の説明、概念モデル、エンタープライズタイプの構造の一般的な「アーキテクチャ要素」（フレームの説明、スケルトン）です。



サブアーキテクチャ、マイクロアーキテクチャ、ナノアーキテクチャがありますが、すべて同じですが、これらはいくつかの概念、一般的なモデル、一般的な構築の原則、スタイルです。 さらに、このルール（少なくとも、ロシア語のルール）は、アーキテクチャ（アーキテクチャ）、プロセッサアーキテクチャ（x86アーキテクチャ、マイクロアーキテクチャ）、および「アーキテクチャ」という用語のその他の多くの正しい使用方法を構築します。



例



アーキテクチャに適用：アーキテクチャのスタイルと多様性は同義語です：

古代ギリシャ建築、古代ローマ建築など



古代ローマの建築は、古代ローマの建築様式とまったく同じ方法で使用されます。

基本的なポイント：企業は「異なる」べきですが、そのアーキテクチャ-いいえ！ いずれにせよ、「各企業には独自のアーキテクチャがある」という記述は正しくありません。 このため、「アーキテクチャ」という用語が造られました。



アーキテクチャとは、特定のフレームワーク（特定の種類のフレームワークを定義する特定の順序で構築されたarch骨、アーチ、柱などの特定の要素）、建物または企業を構築するための一般的なアプローチです。 さまざまな建物がありますが、建築物はほとんどありません。



たとえば、アーキテクチャという用語以外では、次のアプローチがあります。

• 規模の違い：「大」と「小」の両方で同じアーキテクチャを使用できます。
• 製造材料の違い：「ピラミッド」のアーキテクチャを持つ建物は、多くの材料オプションで作成できます。

同じアーキテクチャーのマイクロプロセッサーは、異なるテクノロジー（トポロジー）を使用して製造できます。



「プロセッサアーキテクチャ」を見てみましょう。google「architecture x86」と入力します。

すべての画像はほぼ同じです：データバス、アドレスバス、コントロールバスなど。 完全に異なるコンピューター（組み込みサーバーからハイエンドサーバーまで）で同じアーキテクチャ（x86）を使用できます。



なぜ企業はこれができないのですか？ アーキテクチャおよびマイクロエレクトロニクス（およびその他の分野）の「アーキテクチャアプローチ」では、すべてが明確です。 しかし、EAでは-いいえ、「アーキテクチャ」の概念の中で-彼らは別の特別な意味（マーケティング）を置きます。 なんで？



EAに関連して、「アーキテクチャ」は、特定の組織構造またはITシステムに関係なく、企業の主要なコンポーネントと活動を構造化された形式で記述する高レベルの表現（オブジェクトとプロセスの一般構造、企業コンセプト）です。



モデル。特定の企業の特定のモデルではなく、特定のクラスの企業の（ITコンポーネントではなく、さまざまなコンポーネントの）概念的な高レベルの完全なモデル。 このトピックに関する議論がありました。 「bipiem」からのコメントを参照してください habrahabr.ru/company/technoserv/blog/343350



EA科学には、「スケルトン」だけでなく、フレームワーク、アーキテクチャを説明するための特定のテクニック、マニュアルだけでなく、典型的なエンタープライズアーキテクチャの参照（参照）モデルも含める必要があります。 標準とアーキテクチャの自由な交換に焦点を当てる必要があります。 次に、説明と表記のアプローチがあります。図のどの四角と丸がEAオブジェクトを示します。



すべての建物とプロセッサにアーキテクチャがあるように、すべての企業にはアーキテクチャ（概念的な高レベルモデル）があります。 それは典型的またはユニークかもしれませんが、それは常に概念です。



アーキテクチャの抽象化のレベルは限られています、なぜなら 「概念」と「詳細」は相互に排他的です。 すべての「企業は一意であるため、そのEAは特定（一意）である、つまり EAは常に一意です-これは、同じアーキテクチャのすべての建物が一意であるというステートメントと同じです。 はい、建物は独特ですが、建築はそうではありません（まれな例外を除きます）。



企業の詳細なレビューのために、「製品としてのエンタープライズ」アプローチは、「すべてのねじ」までの「エンタープライズの仕組み」図面の完全なセットで適用できます。



このようなセットは、製品をコンポーネントに分割するスキームから始まり、ソフトウェアを含む各ソフトウェアの説明に続きます（ACS 24.xxxまたは34.xxx、PB 15.xxxのGOSTを参照）。 このプレゼンテーションは、「エンタープライズ」と呼ばれるシステムの要素（ネジ）を作成する方法（開発されたコンポーネント）または購入する方法（購入した製品）の質問に対する答えで終わります。 しかし、これはアーキテクチャ上の表現ではありません。



アーキテクチャの提供-特定のアルゴリズムの説明、オブジェクトの関係（一部の要素と他の要素）-これは、アーキテクチャ表現から別のタイプ（クラス）の設計ドキュメントを作成しようとすることを意味します。



すなわち アーキテクチャ記述は、GOSTまたは同様の西部標準化システム（BPM錬金術を除く）の通常の表現における設計（作業）文書（これの配置方法）ではなく、運用文書（操作方法）ではなく、技術文書（作成方法）ではありません＆EA）。



説明EA-これは詳細な考慮事項ではなく、アーキテクチャの機能を識別し（抽象化を通じて）、他のアーキテクチャと比較して、企業のアーキテクチャをあらゆる種類（スタイル、多様性、概念）に関連付けるための共通および異なるものを見つけるための試みです。



企業の仕事、そのすべてのビジネスプロセス、ビジネスオブジェクトとITオブジェクト間の相互依存性、企業とその個々のデバイス（コンポーネント）の論理構造の形式化の詳細な説明について話している場合、これは企業の完全な（絶対的な）ドキュメントと呼ばれるべきです、プロセスは、そのための一連の設計ドキュメントの開発です。



これだけの場合は、「象のハエから」「EA euphoria」を手配する必要はありません。 「製品」の説明の原則を基礎とするだけで十分です。「サッパーショベル」または「潜水艦」があること、自動プロセス制御システムまたは「戦略的核軍の自動制御システム」であること-基本的な違いはありません。 彼らはあなたのテーブルにドキュメントのセット「シャベル」または「エンタープライズ」を置き、あなたはそれを工場に渡すことができます-彼らはあなたのためにまったく同じようにします。



技術仕様（TU）に従って、製造された企業（製品）のドキュメントセットとの適合性をチェックし、「企業のあらゆるねじ」について、それが示されている仕様コードとシート番号まで知ることができます。



EAの詳細な説明のための多くの達人、しかし多くのコンサルタントは反対します：EAの詳細な説明は、アーキテクチャのすべての要素を説明するためのリソースの分散であり、これを行う必要はありませんが、「アーキテクチャ」の説明のみ、具体的かつ詳細に、すべてではありません。

しかし、まだ詳細があり、「アーキテクチャ」がすでに存在する境界線は、明らかにコンサルタントへの「贈与」であり、贈り物です。 これは、原則として、ツールまたはフレームワークの「柔軟性」、企業の仕様への一般的な方法（技術）の「適応」、「ベストプラクティス」の「有能な」アプリケーション、すなわち これは、使用されるアプローチの非効率性を正当化し、錬金術を偽装する完全な異端です。



dragon1に示されているアーキテクチャを詳しく見てみましょう



概念は、その実装から抽象化されたアプローチとして定義されます。 ローマの典型的な建物にスタジアムと劇場を建てるという原則を組み合わせた「円形劇場」とその実装のコロッセオの例-円形劇場が与えられます。



驚くべきことに、EAの多くの書籍や記事の表紙では、古代の建築アーキテクチャのイメージが強調されており、借用されたアプローチを示唆していますが、将来、実装の詳細とITプレーン（魔法の「デジタル変換」）への移行によって、古典的なアーキテクチャアプローチが歪められます）



アーキテクチャを表示するために必要なA4ページの数は？ ザックマンによると-1つのランドスケープ形式（30セル）で十分でしょうか？



「人気のあるEAの書籍、TOGAFやIAFなどのフレームワーク、さらには学術論文でも、EAが組織の現在および将来の状況の包括的な説明とそれらの間の移行のロードマップを提供することが示唆されています。



基本的に、EAコアの文献では、EAを、ビジネスアーキテクチャ、データアーキテクチャ、アプリケーションアーキテクチャ、およびテクノロジアーキテクチャという4つの異なる「章」を持つさまざまな図でいっぱいの厚い「本」として説明しています。



有名なEAの第一人者Jaap Schekkermanは、EAは「企業の完全な表現（説明）」であると主張しています。 したがって、TOGAF ADMなどのEAへの主なアプローチは、EAが包括的な本として、章ごとに段階的に開発され、計画ツールとして使用されることを示しています。



エンタープライズアーキテクチャアーティファクト間の関係

8つの必須エンタープライズアーキテクチャアーティファクト



すなわち 「ネジ」と各「プロセス」に至るまでの企業全体の包括的な説明 また、「現状のまま」+「あるべき」+「ロードマップ」では？ ほとんどの場合、3つのコンポーネントはすべて、多くの建築家がフィニッシュラインに到達するまで（EAの詩を仕上げるまで）廃止されます。

1.2.2「独自性」のサブ神話

上記のアプローチに従うと、「アーキテクチャ」は、ITランドスケープ、特定のITオブジェクトの構造、およびITアーティファクトを含む、企業のオブジェクトおよびアーティファクトの詳細な説明を意味しません。 「アーキテクチャ」-比較可能な（これがアプローチの目的である）概念であり、「コンクリート」からの抽象概念である。



各企業には独自のアーキテクチャがあります-コンサルタントによって埋め込まれた「管理の流行」です​​（売り上げを伸ばすための有利な位置）。 それらのいずれも主張していません。各プロセッサには独自のアーキテクチャがあり、各建物には独自のアーキテクチャがあります。



場合によっては、独自のエンタープライズアーキテクチャを開発することも可能ですが、これは「新しい星の発見」を含む、新しいプロセッサアーキテクチャ、計算プロセスアーキテクチャ、アーキテクチャの新しいアーキテクチャスタイルなどの開発に匹敵します。



つまり、これは例外的なケースであり、まったく異なるレベルの研究、コスト、リスクを必要とします。 ほとんどの場合、これは標準、統一、標準化、承認の拒否を伴います。 他の標準アーキテクチャ（EA）から借用したブロックから新しいアーキテクチャを統合（組み立て）することだけを話している場合でも。



エンタープライズアーキテクチャは、分類および標準化する必要があります。 多くはないはずです。 彼らは多くのことはできません これらは、「概念」、「フレーム」、「企業のサポート構造」（梁とスケルトン）です。 ただし、このため（比較と分類）、それらを確認（公開）する必要があります。



いずれにせよ、EAの立場からすると、2つの企業は、一方が「すべてMicrosoft上に」、もう一方が「すべてLinux上」または一方が「すべてIT上」（高レベルの自動化）、および他方がコンピューターはまったくありません（ゼロレベルの自動化）。 ITアーキテクチャは異なる場合がありますが、EA-アーキテクチャは同じです。



「EAの独自性」と「EAの宣伝」に関する図を次の段落に示します。

1.3「裸の王」の神話

現象や物体が肉眼で見えない場合があります。 しかし、彼らは信仰として受け入れられています。 彼らによれば、それらの存在には科学的な正当性があり、間接的に検証するか、一貫した厳密な理論があります。



このアプローチとは対照的に、ビジネスで広く普及している「裸の王様」効果（PRコンポーネント）があり、おとぎ話で歌われています。

EAに関連して、私はそのような効果に傾いています。なぜなら、企業は「ダース」であり、最小のものでもアーキテクチャを持っているからです（これが論争にならないことを望みます）。建築家は、「@ ...」、書籍、コース、トレーニング、一般的なアプローチ、フレーム-フレームワーク-電子廃棄物のギグトン。

しかし、この非常に神秘的なEAの単一の例はありません。 なんで？



「裸の王様」のお気に入りの伝説は次のとおりです：EAが存在します！ それはすべての企業に固有です。 パブリックドメインで公開する-それは不可能です。 これは、敵（競合他社）に対する競争上の優位性です。 説明EAは競争上の優位性を低下させます。 敵はあなたの（素晴らしい）アーキテクチャを理解します！ EAは企業の最大の企業秘密であり、企業管理の給料と同様に秘密にしておく必要があります。



したがって、EAの詳細を公開したり、NDAを保護したりする人はいません。

信じられないほどの愚かさ-それを信じるのは簡単です。 そもそも、EAは（定義により）概念的な層であり、IPアドレスはありません。 その中に秘密はありませんが、非常に深刻なコストを伴う紙くずであることがほとんどです（これらは実際には2つの大きな秘密です）。

したがって、コンサルタント（NDA、および企業自体）にとっては、これは「パーティクルボード」であり、「特別に重要な情報」までです。



実際のEAの公開が開始されるとすぐに、「厄介な一時停止」が形成されます。なぜこれほど多くのお金が「これに」費やされたのですか？ 間違えたいです。 いずれにせよ、神話は払拭されます：たとえば、「王は裸」またはその逆-「彼にとってEAとはどんなスタイル」であり、このEAへの投資が正当化されたということは、誰もがすべて明らかになります。

1.3.1神秘主義。 とらえどころのないエンタープライズアーキテクチャの例

google：「エンタープライズアーキテクチャの例」のボタンが機能しないのはなぜですか？ 例はどこにありますか？ 具体的かつ詳細。



特定のロシアの会社がアーキテクチャをモデル化するために、「Zachman Framework」という名前の単純なテーブルを埋めるオプションを見つけることすらできませんでした...（何のアーキテクチャですか？EAまたはISA）。



「EAの特定の例を見よう」という試みは、すべて1つ（2つ）です。「EAでプロジェクトを購入する」または（最も安い）「有料コースを受講して、TAMを紹介します（そして、非常に大きな秘密のために）」。



通りで彼らは時々「調理鍋」と言って、同じこと（実際に既製のEAコンサルタント）とEAと同じ話について話します。「見て-光沢があり、とてもクールで、あなたはそれを買うだけです。」 リエンジニアリングからデジタル化まで、古くて新しいEAおよびBPMスペルと比較してください。 さらに、BPM \ EAセラーの典型的なスクリプトからの必須フレーズ：「主なことは理解することです-詳細があります！ 排他的なものだけがあなたに適しています、あなたはソースパン（EA）ユニークで独特なものが必要です ''：







典型的なアプローチの利点、宣伝、および実践的な経験の交換（マントラではない）の認識、EAの説明（BPM）の公開は、錬金術にとって圧倒的な打撃です。 ただし、これまでの状況は図のとおりです。「ビジネスの独自性」、「デジタル変換の道に沿った特別な道」、NDA-EAプロジェクトの失敗の鍵、非効率性と自転車の永遠の発明。



フレームワークの有無にかかわらず、本格的なホリスティックEAをどこで見ることができますか？ Zachmanによると少なくとも1つのA4で、またはシェッカーマンに関する本のぽっちゃりした山ですか？ EAはベーカリーですが、EAでさえ「パブリックドメイン」です（ガスプロムなど）。 少なくとも「片目」？

1.3.2王のテーラーの公開

「そして王は裸だ！」と証明するか、「すべてが大丈夫だ！」と証明する簡単な方法があります。 王の服装は正しく、EAはあなたにとって錬金術ではなく、本当の科学です。」これを行うには、EAのまさにその説明を公開する必要があります。



錬金術との戦いをどこから始めますか？ 「最小」の小さな企業から始めることができます。 彼らのEAは、企業のEAよりも単純でなければなりません。 質問に戻って、EAのコンテキストにおける企業とは何ですか？

これらは、中小企業や持ち株、さらには家庭や州そのものです。 コンサルタントとシステムインテグレーターが「複雑なEA」、保有、産業クラスター、大企業のみに関心があるのはなぜですか。 簡単な例から始めたほうがいいです。



企業に対する独占的な関心は、彼らが「豊かなピノキオ」であるという事実のみに起因するため、プロジェクト「EAの説明」は「総計」で測定されます。 ただし、このEA自体の説明に対するアプローチは、 「EA世帯」の説明とまったく同じです。



EAの概念をジャグリングしながら、それぞれの「建築家」が自分の家庭用のアーキテクチャを設計しないのはなぜですか。 EAブティック、ベーカリー、幼稚園について誰も説明しないのはなぜですか？



2番目のアプローチ。 インテグレーターとコンサルタントが他のアーキテクチャを喜んで説明し、「これが競争上の優位性である」ことを「納得させる」などの理由で、彼らは（自社の）アーキテクチャを公開せず、それも説明しません。

それとも、コンサルタント会社にはEAがありませんか？ 彼らはどのようにNDAを正当化しますか？



ルールを導入する必要があります：「他のEAを説明したい場合」-「自分から始めて」、「自分自身を説明して」、EAを公開します。 これは、少なくとも研究自体のテーマ（EAの説明）とこのテーマにおけるコンサルタントの能力について何かを言うでしょう。 結論：サードパーティ企業のEAの説明-ライセンスを取得する必要があります。ライセンスがなくても、EAの説明を作成できるのは自社のみです。



私はこのルールをEAに関する本の出版物に拡張し、序文には特定のEAの完全な説明への必須URLリンクがあります。



三番目。 国有企業。 政令または政令を発行する：州の構造によって少なくとも1ペニーの資本参加があるすべての企業（つまり、州の参加がある企業）は、EAを公開する必要があります。 EAの記述をどの方法論で構築するかは重要ではありません。既知のベストプラクティスを選択する（またはリストに制限する）か、独自のベストプラクティスを開発できます。



異論があります：「EAはIPです。 誰がそのような贈り物を配りますか？」 これは、知的財産、知的財産、一種の秘密のサクセスストーリーを指します。



«IP» — , — . EA №1. () . №2 EA. , , . () .

№3 , (.. ) .



« IP»? ( EA) , , ?

, : « » «» ( ) « » «» ( ).



私は統一、複製、宣伝（透明性、購入の事実だけでなく結果の公表）、再利用（借入）、以前に支払った予算資金（私のものを含む）の効果的な使用、PEOPLEの投資の最適化について話している。



4番目。 , () « », « ». « », - ( «»): , .



«BPM — »: bpmaward.ru

« — », «BPM — »? ?



. « » : , : ? ? ?



« », : ? ? ( )?



, « », , « » - , : « , «» , ».



. , , : .

本があったことを思い出してください：Jordain R.-Programmer's Guide。最初に「何をすべきか」と述べた後、ソリューションの3つのオプションを詳細に示します。上位レベル（基本）、中、低です。EAに似たものを見つけたいと思います：いくつかのEAの方法論/フレームワークに従って実装されている1つの企業の例です！

1.3.3合計、オープンEA

特定のEA（実際の企業）の公開後、EAについての完全な混乱を観察します（間違いを犯したいと思います）。おWhyはなぜですか？なぜなら、説明には「森の中に誰か、woodによって誰か」がいるからです。そのような記述の中心にあるのは、まだ工学ではなく錬金術です。



アプローチの「承認」は、次のEAプロジェクトの完了時に、建築家自身の想像力のみにあり、段ボールのフレームワークに別のスターを付けます。客観的な確認はまだありません（満たされていません）。

私たちは、ITアーキテクチャではなく、EAの説明について主に話していることを思い出してください。「説明」は、製品（プレゼンテーション）を宣伝しないことを意味します。ソリューション\システム（SA）およびインフラストラクチャ（IA）の設計者の創造性は、パブリックドメイン（フラグメントではなく、実物大の例）でも興味深いものになります。



«» «» () «-» (-, .. SA, IA .), «-» .. : , .

, , — « », .. « Enterprise Architecture», , Enterprise Architect.



, , , , .. : , ( , ) () ().



, « », , « » 30 : « »! - « ».



: , , « », — . «» ( ).



, - « » ( « »), « ». , :

" « » , ." www.osp.ru/os/2006/03/1156580

:

2 Enterprise Architecture

2.1 wiki

, , , , .

, , , Criticism

— Ivar Jacobson: EA . , 90 % - »;

— Erasmus University Rotterdam IDS Scheer: «» .



«Business and IT alignment» — - . , , «» -, ( -) : — , « » (.. ).

— « », «» « », ( ).



() — «» — CIO « » , – ;

— Stanley B. Gaver: - .



, - (FEA \ FEAF ) USA , ARPANET , TCP\IP -, .. «business net». , , -, , « », «-» ..

wiki framework en.wikipedia.org/wiki/Enterprise_architecture_framework

• EA , «EA frameworks» — « , , ».
• : en.wikipedia.org/wiki/Management_fad
• , «EA frameworks» .
• , : «EA frameworks» — «, ».
• , «EA frameworks» , . «EA frameworks» — — (, , ), frameworks».

2.2 Laws of #BPM (Business Process Management)

improving-bpm-systems.blogspot.ru/2015/07/laws-of-bpm-business-process-management.html

. BPM – . , .



1



BPM (), BPM (), « » BPM () (“body-of-knowledge”), , BPM () BPM () -. .



7



BPM — 50% Enterprise Architecture (EA).



: – 50% BPM.

一般的に、EAと比較してBPMを考慮に入れないのは奇妙なことですか？組織構造がなく、プロセスの入力と出力がないBPMと見なすことができるものは何ですか？



EAの「ダイナミクス」はすでにプロセスです。つまり、 BPMまた、BPMでは、プロセスに関連するすべてのことを尋ねて説明します。実際、オブジェクトまたはアーティファクトのライフサイクルは、プロセスを介したその状態の接続です。遷移の方向（ある状態から別の状態へ）。



特に理解しにくいのは、「エンタープライズアーキテクチャ」とエンタープライズビジネスプロセス管理（BPM）の管理という1か所で会う人です。 「アーキテクチャ管理」や「プロセス管理」など、「データアーキテクチャ」やその他の「サブアーキテクチャ」は、これらのコンテナの両方に即座に任意にパックできます。



第8幕



BPMの問題（EA）は、彼の理論が完成しておらず、確認されていないという事実により発生します。言い換えれば、錬金術でなければ、科学や工学の分野ではありません。興味深い、そして何？



最も正確な結論は法律14にあります：

系1 BPM（EA）コミュニティは錬金術師のグループです。

彼は例（法律）の一部のみを引用し、残りはA. Samarinのブログへのリンクを調べます。

2.3エンタープライズアーキテクチャは...死んだ！

BPM : A fool with a tool is still a fool.

Enterprise Architecture: Don't Be a Fool with a Tool

www.forbes.com/sites/jasonbloomberg/2014/08/07/enterprise-architecture-dont-be-a-fool-with-a-tool



« » — . , «» 50+ «Best Practice», – .. – (, , , ). « ». , .



(Jason Bloomberg) ,

, « » () 1987 «IBM Systems Journal», EA ().

… EA EA, .

エンタープライズアーキテクチャは完全に壊れていますか？



「残念ながら、EAはしばしば、会社のITに関する1人の意見を文書化することと同義です」とGrisey氏は言います。

私が強調するのは、IT、ドキュメント、そしてアーキテクトの主観だけです。このアプローチは最初は死ぬはずだった。



ただし、2番目のスライド：Enterprise Architecture is ... DEAD！ -楽観的すぎる。

www.opengroup.org/public/member/proceedings/Johannesburg-2015-03/Presentations/The%20State%20of%20Enterprise%20Architecture%20Globally%20-%20James%20Thomas.pdf



– , « – » — , , ( ?), « » ( ). - «-», : . «» .



: () , , , « » «»: ( ), .



, , EA — , «», & BPM, framework ( ), , :



« - - .” Jaab Schekkerman, Institute For Enterprise Architecture Development (IFEAD).



( ): - , , « »: , - , , .

2.4 Enterprise Architecture Frameworks: The Fad of the Century

世紀の流行

EAに対する率直で「鋭い」批判の数少ない例の1つ：

「 ...人気のあるすべてのEAフレームワークとそれらの概念の前身は、実装の成功例を提供することなく、明らかにマーケティング指向の管理のトリック（空想）です。 多数のマーケティング出版物が一貫してEAフレームワークを「ベストプラクティス」と位置付けていますが、エビデンスに基づく研究は一貫して反対の結論を示しています。



さまざまなコンサルタントや達人は、効果があるかどうかに関係なく、効果的に売れるものを売ってお金を稼ぎます。

たとえば、以前のIBMでの26年のマーケティングキャリアでBSPの誤った方法論を推進していたEAの「父」であるJohn Zahmanは、最近Federal Corporate Architecture Certification Institute（FEAC）を買収し、現在、FEAF、EAフレームワークで証明書とトレーニングを積極的に販売していますこれは、FEAプログラムに投資した納税者が費やした10億ドルの主な原因です。



FEACメンバーは、誤った「ベストプラクティス」である同じEA構造の認証プログラムを引き続き推進しています。 ここでの狂気は、EAエキスパートコミュニティがまだEAフレームワークを別の管理流行として認識しておらず、多くのEAエキスパートがまだこれらのEAフレームワークの一部の認定を取得したいということです。



信頼できる情報が公開されていても、コンサルタントが「ベストプラクティス」と呼ばれる同じ最悪の販売方法を数十年間販売できるという事実は、無限のマーケティングの約束の無限の力と証拠に基づいた常識の完全なインポテンスを示しています。 この状況は、もう1つの悪名高い声明を明確に示しています。「1000回言われた嘘が真実になる」。



... 30個または15個のZachmanフレームワークセルにデータを取り込む実用的な方法はありません。 ... TOGAFが推奨するドキュメントの全部または半分を開発する実用的な方法はありません... "



管理の流行 -美しい名前を持ち、効率を高めるための新しい方法を提供する管理コンセプト。 通常、経営理論家またはコンサルティング会社によって開発され、その後、幅広い経営理論家および実務家に人気があり、多数の研究、出版物、セミナーなどを引き起こします。

その後徐々にその人気は低下し、新しいファッショナブルな概念に取って代わります。 成功した人気のあるコンセプトを作成することは、コンサルタントと理論家にとって非常に有益なビジネスであるため、後者はその効果的な定式化とプロモーションに特別な注意を払い、時には外部側が実際のコンテンツを大きく上回ることがあります。

slovar-vocab.com/english-russian/new-management-work-economics-vocab/management-fad-1127771.html



私はSvyatoslav Kotusevに同意します。EAは世紀の詐欺です。 もちろん、フレームワークでEAを批判し、「石を投げる」ことは、より建設的なものを提供するよりも簡単ですが、誰かが「王は裸です」と言うべきです。

透明な「王の服」を賞賛し、錬金術を崇拝することは、多くの人にとってさらに簡単で便利な方法です。 新しいものを構築するには、「場所をクリア」して、以前のアプローチの神話を明らかにする必要があります。



Svyatoslavから「貧しい」トガフに行きました。

TOGAFの重要な調査

抜粋：

「 ... TOGAFは1995年に登場し、ADMなどの主要な要素はそれ以降実質的に変更されていません。20年以上前に開発された「ベストプラクティス」がまだどこでも実装できないこと...



... TOGAFはTAFIMに基づいていますが、EAプロジェクトはプロジェクトの完了前にアーキテクチャが古くなり、ビジネスの顧客がそれらを理解することができないため、時間とお金の莫大な投資を必要とするため、TAFIMは失敗することが確認されました。 TOGAFがTAFIMに基づいており、TAFIMが失敗した場合、TOGAFはどのようにベストプラクティスに基づくことができますか？



これらの観察に照らして、TOGAFは実際の慣行を反映していないことが明らかになります...同時に、TOGAFが「ベストプラクティスを提供する」というOpen Groupの約束は、販売促進を目的とした典型的な無意味なマーケティングステートメントとしてのみ見ることができます...



たとえば、現在世界中で52,000人以上のTOGAF認定者がいます。 これは、Open GroupがTOGAF証明書のみで少なくとも2,300万ドルを獲得したことを意味します。

The Open Groupが提供するさまざまなトレーニング、コース、書籍、会議、相談、その他の有益なTOGAFサービスを追加すると、この数ははるかに大きくなる可能性があります。 あなたがThe Open Groupの場合、TOGAFはベストプラクティスを表しているとは思わないでしょうか？



多数のグル、トレーナー、インストラクター、専門家、コンサルタント、認証機関などが、彼らの運命をTOGAFの「販売」に関連付けています。 当然のことながら、彼らは皆TOGAFの宣伝に興味を持ち、それに対する批判を避けています。



... EA市場の影響力のあるプレーヤーの1人がTOGAFに代わるものを提供する動機を持たないため、状況は絶望的です。TOGAFにお金を払うつもりなら、なぜ他の何かを発明するのですか？



3番目の要因は、私が属するEA研究コミュニティの恥ずべき（または犯罪的な）慣性です。 残念ながら、EAの研究者は通常、EAの分野の状況について客観的な分析を行いません。この無知の雰囲気の中で、EAに関連する多くの神話、伝説、迷信が非常に急速に広まります...実際の実用的な問題。

TOGAFが現在一流の大学で教えられているという事実は、マーケティングの侵略者に対する学者の軍隊の降伏を示しています。 "



ターゲットを右。 EAに特化した国内の大学における「ビジネス情報学」の方向性は、実際には錬金術に関するマニュアルに変わりました。 それで、国の科学はペンの中にあります、そして、ここで、錬金術師は後部に定着しました。



エンタープライズアーキテクチャからはTOGAFではありません

「 ... EAコミュニティは、EAの既存の文献を冷静で現実的な視点で捉え、理想的なアイデアを批判的に再考し、再考しなければなりません。

EAに関するエビデンスに基づく新しい情報源は、ほとんど役に立たないが積極的に推進されているEAフレームワークの代替として不可欠です。 」



TOGAFの愛好家の皆様へ-私は、「家庭用建築」の説明のための競争に参加することを提案します（この記事の3番目の段落）。

2.5ソフト批判

インターネット上でのEAへの現代的アプローチやまったく現代的アプローチに対する「ソフト」な批判（グーグルを参照）が長い間存在していましたが、おそらく「非常に多くの人々が共有している」ために、「沸点」しかまだ到達していません。



上記の多くのことは西洋​​の批評家のブログで繰り返されていますが、軟化した処方ではありますが、おそらく彼らはこのEAからパンを手に入れているからでしょう。



filipebartolomeu.weebly.com/blog/tackling-enterprise-architecture-criticism

searchcio.techtarget.com/blog/TotalCIO/Two-IT-gurus-face-off-on-value-of-enterprise-architecture-frameworks



Runetでそのような批判を見つけられなかったことは奇妙です。 これは、西洋の経験とは異なり、ロシアではほとんどのEAプロジェクトが成功していること（私たち全員とブルジョア階級のvy望の的）またはEAでのロシアの教育の成熟度のレベルを示唆しています。 私は2番目の選択肢に屈します。



錬金術について話しているのでなければ、原則を考慮に入れる必要があります。「思考する自己のみの存在は確かであり、他のすべての存在は疑問視されなければなりません。」

3「家庭用建築」の説明のための競争

私は、あらゆるEA宗派の初心者および由緒ある建築家に、彼らの世帯の建築の説明を書くように提供しています：「世帯建築」。 これは、彼らが理解している「エンタープライズアーキテクチャ」が存在する権利を持っていることを最もよく確認するものです。



建築家は、世帯に建築物があり、EAを記述するためのよく知られたアプローチに基づいて「世帯建築物」（HA）を代表できることに同意することを願っています。 また、HAについて説明するときに、配偶者にNDAが不要になることを願っています。



参加の条件は簡単です。アーキテクトは「家庭用アーキテクチャ」を詳細に示し、どのように構築したかを伝え、使用するフレームワークへのリンクを提供します。 ただし、「単純な企業」の他の「単純なアーキテクチャ」：幼稚園、キオスク「アイスクリーム」などを持ち込むことができます。



次の場合はさらに改善されます。

A）建築家はいくつかのNAアーキテクチャを引用し、アーキテクチャの違いを示します。

B）同じONの記述は、異なるアプローチ、記述方法論、フレームワークで示されます。



この章または次の章（記事）に関するコメントでNAの説明へのリンクを示します。 その中で、順番に、NAのビジョンを公開します。 投票することにより、最も「正確な」、最も「建築的な」家庭のアーキテクチャを決定します。 EA、SA、IA、およびその他のを含むおなじみの建築家に通知し、EA \ NAの開発に実行可能な貢献をする機会を与えます。 建築家がこれを行うのに十分ですか？ タスクは難しいものではありません。



EAに関する記事の執筆者、特にハブに住んでいる人は、NA \ EAを送信してください。 あなたは恥ずかしがり屋である必要はありません：考え、描き、「建築」。 なぜ複雑なEAについて話すのか、単純なNAについて話しましょう。

「非錬金術師」、アレン・レンダー、真っ先に！



多くの錬金術師の悔しさを想像してください：

• 簡単な言語では、EAが何であるかが示され、わかりやすいマニュアルの具体的な例によって確認されます。
• 普通の人間は錬金術師の魔法の助けなしに建築の記述を作成できることを理解するでしょう。
• ほとんどの場合、車輪を再発明する必要はまったくなく、標準（典型的な）アーキテクチャを借用するだけであることがわかります。 または、必要なアーキテクチャを満たす設計ソリューション全体でさえあります。

あなた、bipiem