真の建築家のメモ：最も重要なこと（パート2）

アーキテクチャは未来についてです...

-私たちが記事の最初の部分の終わりに止まったのはこの考えでした 。 続けます。

良いアーキテクチャとは何ですか？

優れたアーキテクチャは、その目的に合ったものです。 割り当てられたタスクを解決できます。



タスクは異なります。 標準および特定。 ローカルおよび大。

しかし、いずれにせよ、誰かが「1シーズンの間」家を望んでいる可能性は低いです（ただし、これも可能ですが、「特定」のカテゴリからのみであり、そのような建設のために建築家のサービスに頼ることはほとんどありません）-それは疑わしいですその結果、誰かが将来的にその開発の見通しなしで結果としてシステムを得たいと思うように。



システムの有用な特性の質量は、アーキテクチャの構築の正確さに依存しますが、その中でも重要なのは、機能を構築し、データ量と負荷を増大させるプロセスにおけるその寿命の指標です。

優れたアーキテクチャには、持続可能性の特性が必要です。つまり、 上記のパラメーターを変更しても、決定の実施を徹底的にレビューする必要はありません。



これは、設計がいわゆる非機能要件のセットを考慮する場合に可能です。 ユーザーは、違反があった場合にのみそれらに気付き始めます。ユーザーは、主に必要な機能に集中します。 しかし、これは、この側面が私たちの注意の焦点を離れることを意味するものではありません。 これらの要件に違反すると、ユーザーにとっては単純に見えることが多く、システムは機能しません。



したがって、非機能プロパティには次のものが含まれます。

• 信頼性
• 性能
• 変更可能性;
• 拡張性
• 統合する能力;
• 安全性

さらに、適切に設計されたアーキテクチャにより、複数のパフォーマーによるシステムの同時開発が可能になります。 責任の境界とコンポーネントの統合のポイントが明確に定義され、理解可能である。

そして、これはプロジェクトのタイミングにプラスの効果をもたらします。



アーキテクチャは複雑さに対処する方法です



誰も事実に異議を唱えるとは思いません。ITシステムは一般に複雑なシステムです。 また、ITシステムとシステムを作成する全体のプラクティスは、複雑さを克服するという旗の下にあります。



素晴らしい学生時代の長い歴史を思い出すことができます。

私の論文を準備する時が来たとき、私は非常に「正しい」教師に会いました。彼は私に「ハードウェアとソフトウェアの複合体」の信頼性を計算するための章を必ず要求しました。 私はinして、動揺しようとしました-そのような正式な質問に貴重な時間を費やすのは非常に無意味で無駄に思えました...しかし、図書館に来たとき、私は多くの興味深いことを学びました。 特に、G.J。Myersの優れた研究「ソフトウェアの信頼性：原則と実践」の手に落ちました。



マイヤーズは、例えば、ソフトウェアの信頼性を計算するアプローチは、ハードウェアの計算とは非常に異なると言いました。 また、ソフトウェアの信頼性のレベルは、その複雑さと直接相関しています。 したがって、ソフトウェアシステムの信頼性を高めるための重要なアプローチは、複雑さを扱うさまざまなプラクティスに帰着します。



ハードウェアとは異なり、ソフトウェアは「絶対に信頼できる」には複雑すぎます。 また、ソフトウェア信頼性理論の教義の1つは、 「プログラムには少なくとも1つの誤りがあります 。 」



したがって、ソフトウェア業界には、複雑さを軽減して管理できる多くのプラクティス、アプローチ、ツールがあります。

特に、高レベル言語、特殊な（インフラストラクチャ）ソフトウェア-DBMS、アプリケーションサーバーなどの作成 これらはすべて、ソフトウェア実装の複雑なプロセスを階層レベルに分解する試みであり、それぞれが独自のレベルの問題を解決します。後続の各プロセスは、実装方法を「考えずに」前のサービスを使用します。



上で明らかにしたように、アーキテクトのタスクの1つは、システム全体をコンポーネントに分解し、責任の領域を強調し、相互作用の共通ロジックを構築する機能です。

したがって、アーキテクチャを構築するとき、「分割して征服する」というよく知られている原則を積極的に使用します。 この場合、「コンポーネント、モジュール、レイヤーに分割し、各コンポーネントを個別に管理し、ゲームの共通ルールを構築します」と言うことができます。



信頼性の向上に加えて、システムの別の重要な非機能プロパティである変更機能にも触れます。

モノリシック構造を回避し、システムをコンポーネント部分に分割します-機能し、理解可能な方法で相互作用するモジュールは、個々のコンポーネントに変更を加える能力を高め、他の部分への影響を最小限に抑えます。 将来的には、システムの開発プロセスを単純に言うと、「ここに触れてください-そこに散りばめられる」という状況に陥ることはありません。

アーキテクチャは、システム内の変更管理の将来のプロセスをサポートし、コンポーネントが相互に及ぼす影響を制限し、今後の変更の影響を評価する手段を提供する必要があります。



さらに、システムを構築するための思慮深いモジュール方式の場合、異なるエグゼキューター、さらにはチームや請負業者によってシステムのさまざまなコンポーネントを（ある程度まで）並列かつ条件付きで独立して実装することが可能になります。

さらに、個々のレイヤーを実装するために、さまざまなテクノロジーとプラットフォームを使用できます。 内部統合の相互作用を解決するだけです。



したがって、たとえば、概念的なアーキテクチャスキームのいくつかの層を見るとき、これは悲しみの理由ではありません。 これは、システムが長期にわたって進化し、機能を獲得し、その複雑さを超えない素晴らしい機会を獲得することを喜ぶ理由です-したがって、信頼性と変更可能性の品質を維持します。

なぜ建築家が必要なのですか？ 彼らの役割は何ですか？ 彼らに何を期待できますか、そしてその理由は何ですか？

さて、「エンタープライズ」の高レベルから、私たちは地面に行きます-すなわち。 プロジェクトに。 また、ソフトウェア開発プロジェクトの参加者の目を通して、アーキテクトの世界を見てください。



この建築家はどんな神秘的な人ですか？

コードは記述しません（記述することはできますが、あまり頻繁ではなく、現在は見ていません）。 最初に彼は隅に座ります-考え、描き、考え出します...「彼は雲の中にいます」と開発者は考えます。 「まあ、見てみましょう」と上司は考えます。



はい、コードは書きません。 しばしば紙に書きます。 またはボード上。 一人でまたは誰かと-描く、描く...議論。 もう一度描きます。

その後、成熟します...概念（またはビジョン-タスクの規模に応じて）。

この概念は、「アーキテクチャの顧客」から来た主なアイデアを実装しています（ 記事の第1部を参照 ）。

コンセプトのプレゼンテーション（ビジョン）

その結果、アーキテクトは、問題の本質、タスク、およびその実装へのアプローチを説明する一連の写真と短いプレゼンテーションを持ちます。 次に、「ビジネス」側とITスペシャリスト側の両方から、関係者にアーキテクチャを提示し、調整するプロセスが開始されます。 質問は全員で異なる場合があります。 そして、それらは考慮に入れられなければなりません。 この段階の目的は、平等な理解を達成することです。 見た目ほど単純ではありません。 そして、これは常に成功するとは限りません...そして...これは正常です。 これは職業の一部です。



要するに、この段階で、建築家の芸術は概念を考え出し、それを提示し、承認を得ます。その後、それは実装の基礎として機能します（このプロセスについては、この記事の前半で詳しく説明しました）。



建築家は、単なる幸運な「コーダー」ではなく、独創的な「クリビン」です。 これは、方向性、チーム、システムに対する責任を与えられた人です...多くの人々の成功は、彼の専門知識、思慮深さ、そして「未来を見る」能力にかかっています。



先ほど述べたように、システムの設計と開発の前には、対象となるアーキテクチャとビジョンを作成する必要があります。 つまり プロジェクトを開始する前に、目標を明確に定義し、将来のアクションの意味を確認する必要があります。



建築家はこの目標を信じなければなりません。 道路に沿った「分隊」が何らかの奇妙な方向に合流しないようにする責任があるのは彼だからです-例えば、彼は浴場に行ったり、スチームバスをしたり、誰かの庭を掘ったりすることを決めました...

ターゲットビジョンが選択されると、誰もが理解し、子音を発します。それが、動きの正確さを制御する基礎となります。

「1000マイル」の旅があります。 ステップバイステップ-動作する具体的な何かが現れる前 そして、建築家の仕事は「ねじ込みを防ぐ」ことです。 したがって、技術的背景と戦略的に考える能力に加えて、彼は真のリーダーシップスキルとソフトスキルと呼ぶのに今流行しているものが本当に必要です。 交渉する能力、人々と仕事をする能力、自分自身をうまく管理し、状況を管理する能力。

これらの多様な資質がすべて自然から与えられるのはまれです。 何かが私たちに与えられましたが、何かを育て上げる必要があります。

あなたは誰ですか-理想的な仕様ですか？

コンセプトまたはビジョンは最初の一歩にすぎません。

次に、「詳細に進む」必要があります-将来のシステムとそのコンポーネントの重要なポイントを見つけるために。

また、このステップには、データモデル、相互作用、ビジネスプロセス、状態遷移など、さまざまなレベルと目的のいくつかのモデルの開発が含まれます。

このために、モデリングの1つまたは別の側面（いわゆるCASEテクノロジー）用に設計された専用ツールが使用されます。 この領域には、よく開発された標準もあります-ERモデル、UML図、ビジネスプロセスを記述するための表記法（BPMN、EPC）など



ここで重要な点は、継続的な開発プロセスをサポートできることです。システムの特定の「動作」部分はモデルから作成する必要があります。データベース構造は、UMLクラス図に基づいたデータモデルに基づいて作成されます。将来のプログラムコードのクラスとインターフェイスの準備です。 また、ツールのCASE側では、コードからモデルまでの逆プロセスをサポートできることが重要です。



しかし、これはまだコードではありません。 これらは、コンセプトから将来の製品までの最初の「橋」、つまりフレームワークです。



グラフィック表記とモデルが適しています。 しかし、それだけでは十分ではありません。 いくつかの説明があるはずです-それをどのように使用するか。 はい、はい-テキストなし-どこにもありません。 これは、仕様などのアーティファクトが表示される場所です。



誰が仕様を書いていますか？

仕様は、機能面とシステムアーキテクトの観点から、システムアナリストによって、コンポーネントのシステム（一般、キー）プロパティとそれらの相互作用の観点から書かれています。

仕様は実際には形式化された要件であり、開発者にとっての問題の詳細な声明です。



仕様には何が重要ですか？

まず、次のバランスを取ります。

• 正確性、明瞭性、および高すぎる詳細。
• 汎用性とシンプルさ。
• カバレッジ/および現実的なリソースの完全性。

別のポイントが重要です。

奇妙なことに、仕様は開発者を制限するだけでなく、開発者にある程度の自由を与えるべきです-彼が決定を下す（そして責任を負う）領域で。 もちろん、彼はそれについて知っている必要があります。

これは何のためですか？

第一に、すべてを事前に予測および予測することは困難です。 ソフトウェア開発はかなり複雑な分野であり、可能な作業シナリオの無限の可変性を備えています。

第二に、これが行われない場合、これは「システム」とそれを開発するチームから自己開発のためのスペースを奪います。



過度の「組織」は創造性を奪います。 人は「歯」のように感じ始めます。 そして、それはひどくやる気をなくします。 私の記憶では、開発者が興味を失い、この理由で去ったいくつかのケースがありました。 奇妙なことに、システムのアーキテクチャを作成するとき、他の人々の創造性のために「混ofの島」-「自由の島」を提供する必要があります。

企業はいつ建築に投資する必要がありますか？ そして、これが行われないとどうなりますか？

エンタープライズアーキテクチャを構築し、その開発の実践を実装する必要性を認識していることは、会社の成熟度が十分なレベルであることを示しています。

少なくとも1年間は、近い将来であってもITアーキテクチャを計画する必要性を理解していない企業が数多くあります。 それにもかかわらず、彼らは何らかの形で発展しています-ビジネスの変化、新しい要件の出現、ITシステムの近代化、新しい統合フローの出現、企業全体への情報伝達チャネルなど。



エンタープライズアーキテクチャについて考えない場合はどうなりますか？

答えは簡単です-いくつかの機会が見落とされるか（利益の損失）、またはいくつかの損失が発生します（追加費用）。

「未来の絵」を調べなければ、今日それを見ようとはしないので、「突然」追い越されますが、とにかく追い越されます。 どうなるの？ 悪いことは何も起こらないでしょう。 または、会社が競争力を少し失うか、コアビジネスを危険にさらすより深刻な何かが起こるかもしれません。 これは事前にはわかりません。

しかし、希望と「ルーレット」は非常に信頼性の低い開発戦略です。ビジネスとITの両方であり、ビジネスを提供します。

いずれにしても、偶然とカオスの要素が必ず存在します。 すべてを予測することはできません。 状況に影響を与える外部要因が多すぎます。

しかし、問題は-それを管理しやすくしたいですか？ 影響力のゾーンを拡大するのか、それとも「偶然」に依存するのか？



必要に応じて、これは次のレベルの成熟度です。エンタープライズのアーキテクチャを構築および管理する必要性が認識されている場合です。 この場合、会社は「未来を見据える」準備ができていることを「伝え」、1〜3〜5年前に特定の状況を形成します。 もちろん、「プレイ中に」調整されます。 しかし、私たちはどの分野が私たちにとって価値があるのか​​、何に投資する準備ができているのか、そしてその理由を理解しなければなりませんか？ 私たちはどこでチャンスを得るつもりですか？ 私たちのすごいところはどこにありますか？ まず第一に、安定性、そして少し「クレイジー」になり得る場所が必要なのでしょうか？ 私たちが他の会社よりも才能を持ちたいと思うもの、私たちの本当のチャンスは何ですか？ そして、実証済みの複製ソリューションが必要なのはどこですか？



意識だけでは十分ではありません。 アーキテクチャを「見る」こと、アーキテクチャプロセスを構築すること（変更や制御を含む）はそれほど単純ではありません。 これを「基本」（ルーチン）アクションと呼ぶことはできません。 そして、誤った決定と誤ったアプローチにより、利益よりも害をもたらす可能性があります。そして、美しいが現実的ではない写真を追求する企業は、追加費用を被ることがあります。

ここでは、ある程度まで、前述のアーキテクチャフレームワークが役立ちます。これには、アーキテクチャの記述に関する標準とその開発プロセスの方法論の両方が含まれます。 それらへの依存は除外されませんが、この困難な問題における失敗のリスクを減らします。

標準、参照プラクティスを適用することの価値は、適応する能力です。 どの会社もユニークです。 同一の銀行、小売企業、工場、市政などはありません。 どこでも、地理的、人間的、組織的、技術的など、独自の詳細があります。 したがって、ある組織から「紙の追跡」を試み、変更を加えずに同様のプラクティスを別の組織に適用しようとしても、ほとんど何も良い結果にはなりません。 特定の経験から学ぶことができます。 ただし、会社に合わせて調整する必要があります。

企業のアーキテクチャを構築することは創造的でユニークなプロセスです。各企業とその中で働く人々はどれほどユニークなのでしょうか。

さらに、アーキテクチャプロセスは企業の企業文化、特に意思決定モデル、コミュニケーション方法、情報の透明性などの影響を受けます。



アーキテクチャとは、未来、人々、会社の持続可能な発展に関するものです。

したがって、企業が着実に発展したい場合は、変更を管理するためのアーキテクチャとプロセスに投資を開始する必要があります。