序文

ソフトウェアアーキテクチャは、ソフトウェアエンジニアの間で議論される紛らわしい用語です。どの視点から見るかによって、さまざまな意味が生まれます。

最近、経験豊富なソフトウェアエンジニアと話をする機会に恵まれました。彼は、ソフトウェアアーキテクトの称号を達成することにある種の熱狂的な焦りを感じていました。さらに深く掘り下げていくと、彼らは独自の定義によりすでに建築家であることが明らかになりました。タイトルなしだけで。

この記事では、さまざまな規模の組織にソフトウェアアーキテクチャが根付いているのを私が見てきたさまざまな形について、私の視点を共有します。私の意見では、ソフトウェアアーキテクチャは技術組織のあらゆるレベルで発生します。本当の違いは、ソフトウェアアーキテクチャの「実行する行為」、「所有する行為」、および「表現」の間のニュアンスにあります。

船 — 建築をする

船は、コンポーネントレベルのアーキテクチャ作業が実際に行われるチームを表しています。これらの船では、ソフトウェアエンジニアがコードレベルでシステムコンポーネントを構築するスキルを磨きます。継続的な努力を通じて、時間の経過とともに、品質、効率、保守性のレベルが向上したコードを作成するパターンと機会が見え始めます。

キャリアの初期の私は、後のことを意識せずに、配信目標を達成するために急いでコードを書き始めました。自分の書いたコードをサポートしなければならないときに初めて、自分のアプローチの欠陥に気づきました。必然的に、要件が変化すると、元のパラダイムがいかに柔軟性に欠けているかに直面し、その後、柔軟性を向上させるためにスパゲッティコードをよりクリーンでより高い抽象レベルにリファクタリングするという苦痛を感じることになります。

「何が良いものなのか」について私の意見を固めるパターンを実際に理解するには、さまざまなシステムの設計、構築、サポートを何度も繰り返す必要がありました。逆説的ですが、適切なシステムを構築する方法を知るには、アンチパターンに関する参考文献の合計が必要になるように感じます。「悪い」からの消去法による一種の「良い」。

キャプテンズ — アーキテクチャを所有する

キャプテンは、エンドツーエンドの品質の熟練した構築者となった個人を代表します。完全な統合ソリューションを作成するための知識の幅広さと深さには、すべてのコンポーネントがどのように組み合わされるかを知る経験が必要です。船のどの部分が機能に適しているかを知るには、何が良いのか、何が悪いのかを知ることが重要です。

このレベルのアーキテクチャは、船舶上のコーディングシステムコンポーネント以上の所有権を表します。船長の仕事は、システムの運用効率を確保しながら、品質と適時性の両方で乗組員にビジネス価値を提供することです。これには、人々とテクノロジーに影響を与える幅広いスキルが必要です。

ビジネス— 利害関係者の期待を調整します。
人材– チームが積極的に関与し、成果を上げ、成長できるようにします。
テクノロジー— 効率的で、統合され、拡張可能です。
運用 —テクノロジーと人材の両方が機能し、運用可能です。
スケジュール– 一貫して品質と適時に納品します。

キャプテンとしての私の役割は、品質システムを提供するだけでなく、時間どおりに配送するための最適なルートを見つけるためにスケジュールできるプロジェクト設計を作成する責任もありました。私は、まず分解された一連の作業が存在することを確認し、その後チームに委任しながら、全員が全体像を把握できるようにします。

最適なルート— 時間と品質のトレードオフを考慮した、最もリスクの少ないスケジュールです。
リスクの管理— 知識のギャップから人事問題まで、幅広い考慮事項。
トレードオフの交渉— 短期的なトレードオフを強制することでシステムの長期的な存続が危うくなる場合に、利害関係者の期待を管理します。
優先順位を下げる —配信のクリティカルパスの一部ではない作業であり、「迅速なフォロー」として扱うことができます。

タイズ — 建築を表現する

ID 238028814 © オルガユビライロ | Dreamstime.com

潮汐は、船と船長が航行しなければならない環境と条件を表します。この場合のアーキテクチャ作業には、エコシステム全体の保守性、相互運用性、寿命に責任を負うという使命が課せられています。本質的に組織性とコストを重視したビジネス成果を調整するには、さまざまな要因が考慮されます。

活用— 共通の機能を 2 回以上構築することを避けるために、再利用性を構築します。
相互運用性— 標準の一貫性により、人々がチームを簡単に移動できるようにします。
柔軟性— チームが要件に合ったシステムを効率的に構築するための十分な余地を生み出します。
雇用— テクノロジーの選択に十分な規模の業界人材を擁すること。
可能性 —投資が成熟して実を結ぶのに十分な予算を確保すること。

上の図は、スケールに関する高レベルのガイドラインを提供するために環境を設計する方法に関する制約を強調しています。これらの境界により、サポートされている環境で大規模な投資が行われる場所から抜け出すことなく、チームの自由なイノベーションが促進されます。

環境のどの側面に厳しい制約を追加するかを検討するとき、私の経験則では、組織全体の平均的な認知負荷を考慮に入れながら、新しいテクノロジーの選択に投資できる予算がどれだけ存在するかバランスをとることです。

プログラミング言語— 各言語には、効果的なオプションとなる一連のサポートツールが付属しています。
テクノロジースタック— 各統合スタックには、最初に滑らかな道路を舗装するための投資が必要で、その後のメンテナンス費用もかかります。
CI/CD — コード配信の速度を高めるには、標準化されたパイプラインの規則と構成が必要です。
インフラストラクチャ— 主要な機能のデフォルトオプションを選択してサポートする必要があります (つまり、おそらく単一の RDBMS (PostgreSQL または MySQL の両方をサポートする必要はありません) のみをサポートする必要があります)

ローカルチームは、好み、慣れ、またはパフォーマンスの向上に基づいて選択を最適化することで短期的には利益を得るかもしれませんが、チェックを行わずに放置した場合、長期的な結果はサポートの表面積が広くなり、規模の経済性が損なわれることになります。

機会

ID 132581362 © マリーナ・クリウチェンコ | Dreamstime.com

航行中、船は配達中の課題や変動に直面することになります。私の経験では、海が荒れているときは、環境が時間的に制約されており、それがショートカットや技術的負債の増加につながります。

穏やかな海域では、チームは再び出発する前に船を修理する時間が与えられる状況です。目標は、システムが不安定性に耐えられるように、コードとシステムを継続的にモジュール化することです。新しい要件が発生した場合、システムの重要な部分を更新したり、新しいコードを追加したりする必要はありません。

このモジュール性とデカップリングの考え方は、ニールフォード、レベッカパーソンズ、パトリッククア著『Building Eevolutionary Architectures』の中で「Architectural Quantum」として概要が説明されています。

アーキテクチャクォンタムは、機能の凝集度が高く、独立して展開可能なコンポーネントであり、システムが適切に機能するために必要なすべての構造要素が含まれています。モノリシックアーキテクチャでは、量子はアプリケーション全体です。すべてが高度に結合されているため、開発者はそれを一括してデプロイする必要があります。

つまり、システムをモジュール化して分離したい場合は、小規模でデプロイ可能な変更セットであるアーキテクチャクォンタムの単位を目指す必要があります。船長は、穏やかな海域での時間を常に利用して、船を修理し、乗組員を休ませるべきです。

あるべきか否か

ID 131782006 © OneLineStock | Dreamstime.com

それが質問です。建築を行う、所有する、または表現するという行為は、明らかに異なる役割と責任を持ちます。「実行して所有する」アーキテクチャは、短期的な局所的な懸念に対処するために実行を最適化します。一方、「表現する」アーキテクチャは、長期的に効率を最大化するために動作環境を最適化します。

すべてのアーキテクチャ作業は同様の主要なアクティビティを共有していますが、違いは、何を最適化するのか、どの期間で最適化するのかにあります。

Ships — ローカルな一貫性を重視し、スプリントや四半期などのより短い期間で提供するよう奨励されています。
キャプテン— 隣接するチーム間のより広範な一貫性と、四半期や数年の長期的な期間を重視します。
Tides — 数年から数十年の長期にわたる保守性を備えた組織全体の一貫性を重視します。

したがって、建築における主要な活動に費やす時間の割合は、あなたが担う役割に対応します。システム設計やコーディングの形でアーキテクチャの仕事をするのが好きなら、スタッフ以上のレベルのエンジニアリングの仕事へのキャリアを検討すると思います。むしろ、組織全体の戦略や環境の適切な動作条件を導き出すことに喜びを感じるのであれば、アーキテクチャを代表することは非常にやりがいのある仕事となるでしょう。