⛅️ 🍅 👨🏿‍🎓 システムアーキテクチャとビジネスアーキテクチャ 🏫 🧒 ❔

さまざまな専門家がアーキテクチャの理解をどのように説明（確立）するかについて十分に熟考した後、私は彼らがまだ助けを必要としていると判断しました:)私

は批判しませんでしたが、何か提供できるものがあります。

建築と建築構造

建設の分野からの建築と建築家の元の概念を考えてみましょう。

建築とは、建物、構造物、およびそれらの複合体を設計および構築する技術、つまり、物質的に組織化された環境を作成する技術です。

アーキテクトとは、専門家として、空間計画やインテリアソリューションの開発など、建物の設計を含む建築設計を行うスペシャリストです。

建設プロジェクトは、建築と建設およびエンジニアリングの2つの主要部分で構成されています。

プロジェクトの建築と建設の部分は次のとおりです。

建築セクションは、建物の正確な幾何学的パラメータ、その構造、およびそれらの要素（フロアプラン、フロア、ルーフプラン、ファサード、セクション、視覚化）を示す建築図面と建設図面で構成されています。
設計セクションには、一般的なデータ、基礎、床、屋根の設計ソリューション、個々のアセンブリと部品の図面、製品と材料の仕様（基礎、天井、リンテル、屋根、構造アセンブリ、および詳細）が含まれています。

プロジェクトのエンジニアリング部分は、詳細な図で構成されています。

上下水道システム-給水配線図、アキソノメトリック給水図、下水道配線図。
暖房と換気-暖房配線図、換気配線図、ボイラー配管（ある場合）。
電源-照明配線、電源ネットワーク配線、ASU回路、接地システム。

アーキテクトは建築セクションのみを扱い、構造セクションとエンジニアリング部分は対応するエンジニアが扱います。

...考える場所..。

「タンク内」にいて、アーキテクトと比較したいITアーキテクトの場合：

, . , , , .

システムアーキテクチャー

次に、ITに近い定義を見てみましょう。記事からの抜粋を参考にします。

アーキテクチャ-その環境におけるシステムの基本的な概念またはプロパティ。その要素、関係、および設計と進化の原則に具体化されています。（From：ISO / IEC / IEEE 42010：2011）

このような同様の定義は、通常、TOGAFやSAFeなどの大規模なアーキテクチャフレームワークで使用されます。これらのフレームワークは非常に重く、体系化され、多くの異なる技術や技術で希釈された一連の小さなプラクティスで構成されています。そして、これはすべて「ベストプラクティス」として提示されていますが、誰もテストしておらず、この形式で完全に適用しているわけではありません。

– , . ( )

ただし、「変更しにくい」という特徴を持つ微妙な点があります。

開発者がJavaコードをどのように構成するかを説明する設計ソリューションがあるとします。コードがたくさんある場合、そのすべてのコードをある構造から別の構造に変更するには、多くの作業が必要になります。言い換えれば、それは難しいです。したがって、この選択されたソリューションは「アーキテクチャ」、この場合はソフトウェアアーキテクチャです。しかし、1人の開発者はこの決定を簡単に無視して、異なることを行うコードを書くことができます。結局のところ、ソフトウェアに「変更」を加えるのは簡単です。実装されたアーキテクチャ全体を変更することは困難ですが、一部のみを変更することは非常に簡単です。

ソフトウェアに関して何かを変更するのが難しいという理論的な理由はありません。ソフトウェアの1つの側面を選択すれば、それを簡単に変更できますが、すべてを簡単に変更できるようにする方法はわかりません。何かを簡単に変更できるようにすると、システム全体が少し難しくなり、簡単に変更できるようにすると、システム全体が非常に複雑になります。（ラルフ・ジョンソン）

これは、ISOによる「建築」の定義における「基本」という言葉の意味を明らかにしていると言えますが、これは変更が難しいものです。

アーキテクチャの本質は構造化です。構造化とは、フォームを機能に変換すること、混乱から秩序を取り除くこと、またはクライアントの部分的に形成されたアイデアを実行可能な概念モデルに変換することを意味します（EberhardRechtin）。

アーキテクチャの構築は、その構成要素からシステムを編成および維持するアクティビティです。そして、すべてのアーキテクチャの原則は、システムの構成要素の分解と編成を目的としています。

問題

上記の定義の問題は、有用ではありますが、依然として存在しますが、システムに組み込まれているアイデアから切り離されています。「変更しにくい」という基準に従ってアーキテクチャを区別するのはかなり奇妙です。

また、この場合のコンポーネントによる定義は、必要な意味を伝えていません。

...考える場所...

ほとんどのシステムアーキテクトはプログラマーから来ており、彼らはすべて技術者です。彼らはそれをすべて思いついた。 :)

アーキテクチャを扱うときは、システムの目的に焦点を合わせる方がよいでしょう。

アーキテクチャは、一連の設計ソリューションを目的に対応するシステムに編成する設計ソリューションです。

これは、ホイール、エンジン、ボディ、ステアリングを車にまとめる設計ソリューションです。

言い換えると、アーキテクチャは、緊急効果を生み出す設計ソリューションです。出現-要素に個別に固有ではないプロパティのシステムの外観。そのコンポーネントのプロパティの合計に対するシステムのプロパティの還元不可能性。抽象化のレベル

を混在させないことが重要です。また後で、疑問が生じるかもしれません、良いアーキテクチャとは何ですか？アーキテクチャは、システムの品質の3つの主要な属性である信頼性、効率、柔軟性の実装を保証する必要があります。他にも、たとえば、スケーラビリティ、テスト容易性、保守性などがありますが、必ずしもそれほど重要ではありません。

ビジネスアーキテクチャ

ビジネスアーキテクチャには独自の詳細があります。まず、理解して説明する必要のある実用的なアーキテクチャがあります。第二に、ビジネスにはあなたが知る必要のある独自の原則と基本的な概念があります。ビジネスと基本的な概念を理解することによってのみ、変更を提案できます。

他のアーキテクチャと同様に、ビジネスアーキテクチャの基盤を説明するために3つの側面が使用されます。

主題は組織的なスタッフ構造です。
アクティビティは、ビジネスプロセス、機能、およびサービスです。
オブジェクトは、アクティビティの結果であり、アクティビティのマテリアルです。この場合、結果と資料は物理的または情報的である可能性があります。

しかし、それでも、これはこれを理解するのに十分ではありません。基本的な概念と原則を考慮する必要があります。

「3種類の活動」のコンセプト

アクティビティには次の3つのタイプがあります。

マネージャー-システムの機能を制御するアクティビティ。管理プロセスの例は、Corporate Governance and StrategicManagementです。
メイン（運営） -会社の事業の基盤であり、収入の主流を生み出す活動。運用ビジネスプロセスの例は、調達、製造、マーケティング、販売です。
支援的-主な事業に役立つ活動。たとえば、会計、採用、技術サポート、管理部門。

支援活動はしばしば外部委託されます。上記の例で「メインとして」示されているアクティビティは、外部委託することもできるため、必ずしもメインのアクティビティであるとは限りません。常に管理活動があり、理論的には管理以外のすべてを「外部委託」して会社を仮想化することが可能です。

アウトソース管理：

? outsource. :)

デミングサイクルコンセプト

そこで、アーキテクトとして、会社の活動を3つの部分に分けました。次に、すべてがどのように連携するかを理解する必要があります。これを行うには、もう1つの古い、しかしまだ関連性のある概念、つまりデミングサイクル、別名PDCAが必要です。

計画

行為

小切手

調整

文字通りに解釈する必要はありません。それは単なる比喩であり、企業によって実装方法は異なりますが、これらの段階は常に存在します。

私たちの特定の設計作業、製品製造、またはサービス提供を見てみましょう。

このプロセスを計画したのは誰ですか？
規制および規制文書とは何ですか？
誰が行動しますか？
検証はどのように行われますか？
調整はどのように行われますか？

「アクション」と「チェック」の段階ですべてが明確に見える場合は、「計画」と「調整」を詳しく調べる必要があります。

意思決定の概念

ここでは、3番目の概念である意思決定が必要です。これは、管理上の問題とプロジェクト管理を解決するための普遍的なアプローチです。

タスクを理解する

評価状況

ソリューションオプションの開発

ソリューションの選択

このシーケンスのすべてのステップと、それを完了するために必要なものを理解することが重要です。このアプローチは、計画や、状況に応じて調整に適用されます。

この概念を私たちのデザインにマッピングしましょう：

タスクの明確化はどのように行われますか？
状況はどのように評価されますか？
..。

それでは、リーダーシップのレベルに上がりましょう。

リーダーシップは、状況を調整および評価するという点で、どのように情報を提供されますか。つまり、プロジェクトのレポートはどこにあるので、すべてをよくまたはよく理解できませんか。

原則「目的はアーキテクチャを決定する必要がある」

ここでアーキテクチャの定義を思い出すことが重要です。

アーキテクチャは、一連の設計ソリューションを目的に対応するシステムに編成する設計ソリューションです。通常、

最終用途が主な活動です。管理活動は主な活動に焦点を合わせています。支援活動がそれを提供します。

また、品質の上記の属性である信頼性、効率、柔軟性を忘れないでください。主な活動は個人的なものですが、ここでは自分で対処できると思います。

原則「アーキテクチャはガイドラインに準拠する必要があります」

利害関係者のサポートがなければ、アーキテクチャは実装されません。私たちはすべての利害関係者、彼らの動機と目標を研究する必要があります。

内部競合が発生する可能性があります。

...考える場所..。

ビジネスアーキテクチャの定義

専門的な定義については、ビジネスとITが肩を並べて進んでいるという事実を考えると、私の意見では、ビジネスアーキテクチャをエンタープライズアーキテクチャの抽象化の上位レベルの一連のソリューションとして認識する方がよいと思います。

既存の定義の中で、私はArchitecture Board Special Interest Group（BASIG）（OMG Architecture Board）によって与えられたものが好きです。

A Blueprint Of The Enterprise That Provides A Common Understanding Of The Organization And Is Used To Align Strategic Objectives And Tactical Demands.

, .

建築の通常の概念を与えると、建築家の役割が非常に明確になります。

靴屋の仕事は靴を作って修理することです。

アーキテクトの仕事は、アーキテクチャを作成および管理することです。彼は、他のすべてのソリューションをシステムに収集するソリューションを作成する必要があります。

彼はどのような能力を持っているべきですか？

アーキテクトは、ビジネスまたはシステムレベルでアーキテクチャの原則と概念を知っている必要があります。これらは、彼のハードスキルです。

また、アーキテクトはドライバーである必要があります。アーキテクチャは戦いの半分であると説明しますが、それを実装して常にサポートするように人々を説得することは、2番目のタスクです。

これを行うには、アーキテクトは十分に訓練されたソフトスキルを持っている必要があります。..。

アーキテクトをアナリストやプログラマーと区別するもう1つの特徴があります。彼は、操作の技術を習得する必要があります。

...考える場所..。

システムアーキテクチャとビジネスアーキテクチャ