ほとんどの開発者は、ほとんどの場合、特定のプロジェクト、つまり 彼らから「ソフトウェアアーキテクチャ」をよく聞くことができますが、これは一般的な概念に含まれるもののほんの一部です。 グローバルコンセプトを、一般的なものから特定の部分まで、いくつかの部分に分割することは条件付きで可能です。 それらをピラミッドの形で想像できます：
- ビジネスアーキテクチャ
- 情報システムアーキテクチャ（データストリーム）
- 技術的アーキテクチャ
したがって、開発者はほとんどの場合、アプリケーションの技術的アーキテクチャについて話します。
エンタープライズとも呼ばれるビジネスアーキテクチャは、成功するビジネス開発と目標の達成のための主要な要件、原則、モデルを作成、改善、組み合わせることにより、ビジネスと戦略の目標を効果的に再現する方法を表しています。 英語版ウィキペディアから取られた定義。 エンタープライズアーキテクトは、ビジネスニーズに焦点を合わせ、データフローを分析する必要があります。 示された2つのポイントをカバーします。 ソリューションアーキテクトは、プロジェクトの技術的側面を扱います。 また、ここでは指定されていないインフラストラクチャアーキテクト、プロジェクトの実装のための技術的能力のグローバルな開発と分析に携わっている人々に言及する価値があります。
建築家には3つのタイプ/レベルがあります：
- エンタープライズ（EA）
- ソリューション（SA）
- インフラストラクチャ（IA）
開発の側面では、IAの重要な役割を忘れずに、EAとSAのタスクと責任をさらに調べます。
Enterprise ArchitectとSolution Architectの違い
非常に簡単な場合：
- エンタープライズ-何をすべきか
- ソリューション-方法
EAが直面している問題と課題の範囲は次のとおりです。
- アプリケーションおよび/またはその部品が機能する機器の定義と決定。
- データフローの定義、社内およびその他の情報システムとの相互作用。
- アプリケーション展開計画を作成し、依存関係を定義します。
- アプリケーション管理計画とアクセス/セキュリティの問題を作成します。
ソリューションアーキテクトへの質問は、単純な開発者にとってより身近なものです。たとえば、次のようなものです。
- 仕事のためのフレームワークの選択;
- ユーザーへの提出。
- アプリケーション開発管理;
- 開発者の間で議論のある問題の解決策。
違いは、次のようにグラフィカルに表すことができます。
EAは、アプリケーションのグローバル計画、他のアプリケーションとの相互作用を開発しています。 SAは特定のソフトウェアに取り組んでいます。 同時に、EAはアプリケーションの開発方法を常に監視し、アプリケーションの概念的な部分を調整できます。
たとえば、ある時点で、アプリケーションAによって生成されたデータを使用する新しいアプリケーションXが必要になります。この場合、EAはアプリケーションXのデータプロバイダーとなる別のサービスにアプリケーションAの一部を割り当てることを決定します。新しいアプリケーションの実装に関する作業が大幅に削減されました。
提示された例から、EAは非常にうまく機能し、すべてのアプリケーションがどのように連携するかを分析および監視し、すべての情報を明確で構造化された方法で保持し、説明された決定を下すことができると結論付けるのは簡単です サービスとデータの再利用、データとサービスの詳細の記憶または認識、これはすべてEAの責任です。
私の意見では、SAは実践的なプログラマーである必要があります。使用する製品とフレームワークを十分に理解し、使用する技術の限界と長所を知る必要があるからです。 同様に、EAは技術の世界から離婚していません。なぜなら、一般的な技術の概念的な違いを知り、その開発動向を認識する必要があるからです。 グローバルなソフトウェア開発計画で下された決定は、その後のすべてのプロジェクトを埋めるか、選択がビジネスの技術的構造に対応しない場合、その開発を長く困難にする可能性があるためです。
責任と影響力のレベル
この図は、さまざまなレベルのアーキテクチャ計画間の関係と関係を示しています。 彼らのお互いへの影響。 コメントする価値はないと思う。
エンタープライズアーキテクチャの可能なアーティファクト：
- プロジェクト計画
- システムへのビジネスプロセスのマッピング
- 業務プロセス
- 組織構造
- システム統合の技術的アーキテクチャ
- データ構造
- システムとそのコンポーネントを展開するためのトポロジ
- ネットワークトポロジと機器の接続
- システムの物理的な配置
- システムおよび機器の登録
- 機能システム
下の写真のそれらの間の関係。 品質が悪い。
リストの各項目については、個別にグーグル検索できますが、一般的にはそれらの意味が明確です。 おそらく最も便利なプレゼンテーション形式を選択することになるでしょう。
建築家の仕事
一部の人々は、企業の意思決定プロセスがどのように構築されているかについて話しました。 たとえば、1年間の計画を承認する場合、必要な期間内に実装の実現可能性を分析しようとするアーキテクトの参加は必須です。 彼らは、どのプロジェクトが力の最大の投資を必要とするかを決定します。それは消費者になるだけで、多くのリソースを必要としません。
開発と制御のための特定のツールを呼び出す人はいません。 いずれにせよ、Visio、SharePoint、Wikiのツールのコンパイルが使用されます。
私にとっては、データ成長の傾向、データ管理メカニズムをどのように評価するかについて疑問が残ります。 アーキテクチャの移行に関するベストプラクティス、近代化中のシステムの動作。 多くの多くの質問が実際的な性質から生じているので、セミナーで出会った実践的な人々からそれを見つけようとします。 結果があれば、さらに書きます。
追加の資料から、TOGAF9とNick Malikブログをお勧めできます。
UPD
ナレーターはセルゲイ・オルリクで、建築に関する彼の過去の物語をまとめたものでした。 スライドはwww.slideshare.net/sorlik/presentationsで入手できます。