エンタープライズ、システム、およびアプリケーションのアーキテクチャ (ベスト プラクティス?)

Question

私は現在、ソフトウェア開発のための文書化された一貫したアーキテクチャ ガイドを作成する任務を負っています。私たちには正しいことをしている賢い人材がたくさんいますが、それは一貫性と反復性ではありません。

Microsoft のアプリケーション アーキテクチャ ガイド 2.0 を出発点として使用しています。したがって、アプリケーション アーキテクチャを思いつくことは、かなり (簡単とは言いませんが) 簡単です。おそらく、私には開発者として数年の経験があるため、この領域についてはかなりよく理解しており、サンプルやガイダンスもたくさんあるからでしょう。

私たちの組織には 1 つ以上のシステムを形成するアプリケーションがいくつかあるため、それらをクライアント「に」インストールします...私たちは、システム アーキテクチャとエンタープライズ アーキテクチャも作成することが合理的であると考えました。そしてここから問題が始まります。

そこには一貫したガイダンスはありません。「システム アーキテクチャの例」を検索すると、返される内容が非常に異なるため、これを行う「標準的な」方法があるのではないかと疑問に思っています。

私の (限られた - 明確な) 理解によれば、システム アーキテクチャは、1 つ以上のアプリケーション アーキテクチャを抽象化し、それらがどのように連携してシステムを形成するかを示しています。さらに、エンタープライズ アーキテクチャは、システムが組織エンタープライズにどのように適合するか、ビジネス プロセス、IT 戦略とどのように相互作用するか、およびエンタープライズ内の他のシステムにどのように統合されるかを示すさらなる抽象化です。

• 完全に間違っているのでしょうか？
• 何か基準はありますか (どこで見つけられますか)?
• 標準は存在するべきなのでしょうか、それとも「良い」システム アーキテクチャとは、単純に読者にとって明確かつ簡単に理解でき、役立つ任意の形式の文書でしょうか?
• しかし、経験豊富な建築家はそのアプローチについてどう思うでしょうか?

役立つと思われる SOA 関連のパターンのセットを単にリストするつもりはありません...私たちが行っていること、つまりサービス指向アーキテクチャ上で金融ソリューションを構築することにもう少し焦点を当てたいと思います。

アップデート：どうですか トガフ(9). 。誰かがそれを経験したことはありますか、そしてそれを詳細に理解しようとする努力の価値はありますか。

Answer 1

数日前に質問を送信しましたが、調査を続け、読んだ結果、 リトルギークさんの回答を読んで、非常に有益で興味深いホワイトペーパーを見つけたと思います。

読む： 上位 4 つのエンタープライズ アーキテクチャ手法の比較による：ロジャー・セッションズ

断片...

-- - - - - - - - - - - 8< - - - - - - - - - - - -

過去 20 年間に、多くのエンタープライズ アーキテクチャ手法が生まれては消えていきました。現時点では、おそらく現場の 90% が次の 4 つの方法論のいずれかを使用しています。

• エンタープライズ アーキテクチャのための Zachman フレームワーク - フレームワークであると自称していますが、実際には分類法としてより正確に定義されています。
• Open Group Architectural Framework (TOGAF) - フレームワークと呼ばれていますが、実際にはプロセスとしてより正確に定義されています。
• 連邦エンタープライズ アーキテクチャ - 実装されたエンタープライズ アーキテクチャ、またはエンタープライズ アーキテクチャを作成するための規範的な方法論として見ることができます。
• Gartner の方法論 - エンタープライズ アーキテクチャの実践として最も適切に説明できます。

このホワイトペーパーでは、エンタープライズ アーキテクチャに対するこれら 4 つのアプローチについて説明します。これは、非常に架空の業務上の問題に直面している架空の会社のコンテキスト内で行われます。これらの問題には次のようなものがあります。

• IT システムは管理不能なほど複雑になり、維持コストがますます高くなっています。
• IT システムは、組織が現在および将来の市場状況にタイムリーかつコスト効率の高い方法で対応する能力を妨げています。
• ミッションクリティカルな情報が常に古い、またはまったく間違っている、あるいはその両方。
• 組織のビジネス側とテクノロジー側の間にある不信感の文化。

-- - - - - - - - - - - 8< - - - - - - - - - - - -

ホワイトペーパーはいくつかの点で役に立ちました。

1. アーキテクチャ (特にエンタープライズ アーキテクチャ) についての良い紹介と歴史を得ることができました。
2. 著者が示唆する、利用可能な 4 つの主要なエンタープライズ アーキテクチャを紹介しました。
3. そして、私が共感できる良い例と論理的かつシンプルな方法でそれらを比較し続けます。

すべての質問が解決され、もう死ぬ準備ができているとは言えません :-) ですが、多くのことがより明確になったので、他の誰かもこれが役に立つかもしれないと思いました。

この件に関する追加のコメント、提案、ご質問をお待ちしております。

Answer 2

あなたは状況を非常によく把握しており、アーキテクチャの領域を理解しているようです。

「システム」アーキテクチャを定義するのは少し難しく、「ソリューション」または「IT」を探すことになるかもしれませんが、ネットワークを少し追加して、ソフトウェア アーキテクチャが物理サーバーの世界にどのように関連するかを探しているように思えます。

「私たちには正しいことをしている賢い人材がたくさんいますが、一貫性と再現性はありません。」

そして、私自身 TOGAF 8 認定を受けているので、TOGAF はアーキテクチャを定義するさまざまな側面に「方法論」の感覚をもたらし、さまざまな専門技術グループをまとめてそれをビジネス目標にしっかりと固定する方法であると言えます。TOGAF はまた、アーキテクチャ ガバナンスの必要性を理解するのに役立ち、(技術、データ、システム、ソフトウェア、ビジネスのすべての部分から) 変化のアイデアをプロセスにしっかりと導入します。

の

1. アーキテクチャ開発手法
2. テクニカルリファレンスモデル
3. 規格情報ベース
4. エンタープライズ・コンティニュアム

これらはすべて、Archtecture の取り組みに関する情報を収集し、開発と EA に対する一貫したアプローチを提供するのに役立ちます。

また、顧客が何を行っているか、そして TOAGF がどのように組み合わされるかを示す方法として TOAGF をどのように提示できるかを顧客が理解するのにも役立ちます。

PS - TOAGF がこの問題に対処するため、私が抜粋した引用文を参考にして TOGAF が役立つとだけ述べておきます。

他にもアーキテクトのフレームワークは存在します。

Answer 3

私は、EAには実務経験を持っていないが、私はそれでボード上で実際にです。トップ4 EA手法の中で、私は最初の3に遭遇しました。私はもしかしたら、その文書の使用不能のため、Gartnerのいずれかを知りません。我々はEAについて話しているときIMHO、私たちは実際に技術とビジネスを揃えるについて話しています。だから、EA手法のすべては、ビジネス志向でなければなりません。ない場合は、それがすべてでEAはありません。

私は、TOGAFは非常に便利で分かりやすいと思います。はい、それはターゲットアーキテクチャに現在のベースラインアーキテクチャを進化過程です。アーキテクチャの原則は、EAの開発の高レベルのガイダンスとして機能します。 TOGAFのコアコンポーネントは、ビジネス・アーキテクチャ、情報アーキテクチャ、および技術アーキテクチャです。そして、それらのそれぞれが独自のアーキテクチャパターンを持つことができます。 NIH にはFEAFとEAを実施しています。これは、EAを実装するための良い例です。私はそれが、少なくとも成果の観点から、TOGAFのアプローチと非常によく似ていると思います。

Answer 4

これまでにEAのためのモデリングフレームワークを作成するための唯一の賢明な試みはArchimateされています：ます。https：// en.wikipedia.org/wiki/ArchiMateする

ArchiMateは、The Open Groupの技術標準であり、IEEE 1471標準のコンセプトに基づいています。

また、それらの間のEAの成果物とトレーサビリティに関する次のリンクを参照してください。

<のhref = "https://www.ontario.ca/document/go-its-56-ops-enterprise-architecture-principles-and-artefacts-appendix-ontario-public-service" のrel = "nofollowをnoreferrer "> https://www.ontario.ca/document/go-its-56-ops-enterprise-architecture-principles-and-artefacts-appendix-ontario-public-service の