【読書メモ】Fundamentals of Software Architecture ~第一章 Introduction~ (1)
『Fundamentals of Software Architecture: An Engineering Approach』(以下、FoSA)の読書メモ、今回は第一章 Introductionです。
そもそもソフトウェアアーキテクトとは何なのか。
本章の始まりは、「ソフトウェアアーキテクトは人気職種の一つだが、それになるための明確な道筋がないのはなぜか？」という問いから始まります。
対比として、ナース・プラクティショナーやファイナンス・マネージャも人気の職だが、キャリアパスが明確にあると例示されています。アーキテクトは学位だったり資格を取ればまずはokという訳ではないと言うことが言いたいのだと思います。
さて問いに戻ると、4つの理由が本章では提示されています。
- ソフトウェアアーキテクチャについての明確な定義がない
- 担う責任範囲が広い
- ソフトウェア開発のエコシステムが急激に進化している
- 時代依存が強い
ひとまず、アーキテクトという職に正解はないという事なのだと雑に理解。 このセクションで印象的だった箇所を引用します。
“Hey, I have a great idea for a revolutionary style of architecture, where each service runs on its own isolated machinery, with its own dedicated database (describing what we now know as microservices). So, that means I’ll need 50 licenses for Windows, another 30 application server licenses, and at least 50 database server licenses.”
(Kindle の位置No.159-161). O'Reilly Media. Kindle 版.
これは、2002年にマイクロサービスを実現しようとしたら、どうなるかという例です。 アーキテクチャ的な"正しさ"は、時代や状況(文脈)に依存するとはどういう事か、 なるほどこれはイメージしやすいと思いました。
Because everything changes, including foundations upon which we make decisions, architects should reexamine some core axioms that informed earlier writing about software architecture. (Kindle の位置No.153-154). O'Reilly Media. Kindle 版.
"正しさ"すらも変化する中で、良い姿を検討・検証することがアーキテクトの責務だと一旦理解して読み進めていきます。
ソフトウェアアーキテクチャを定義づける
アーキテクト がアーキテクチャを分析するとき、”何”を分析しているのか？ 本セクションではこの問いを通じて、ソフトウェアアーキテクチャとは何か定義しています。
本書の定義によれば、ソフトウェアアーキテクチャは、
以下の3つを組み合わせた「システムの構造(Structure of the system)」
・アーキテクチャ特性(Architecture characteristics)
・アーキテクチャの決定(Architecture decisions)
・設計原則 (Design principles)
によって構成されるとされています。 以下、それぞれ詳細に触れていきます。
システムの構造
システムの構造は、アーキテクチャスタイルとも言われ、例えば microservices・layerd・microkernel といったもの。ただし、これだけではソフトウェアアーキテクチャ全体を言い表せないことに注意。 Architecture characteristics・Architecture decisions・Design principlesを理解して初めて、アーキテクチャを理解したと言える。
アーキテクチャ特性(Architecture characteristics)
一言で言うと、ソフトウェアを成功に導くための基準。 例えば、可用性・スケーラビリティ・信頼性など。
アーキテクチャの決定(Architecture decisions)
一言で言うと、システムがどう構築されるべきか定めるルール。 例えば、ビジネス層とサービス層のみがDBにアクセスできる、など。 アーキテクチャの決定は、システムに制約を設け、何が許容され許容されないかを開発者に指示するもの。
何らかの制約や条件によって、アーキテクチャの決定に則った実装ができないこともある。 そういった例外については、ARB(アーキテクチャ・レビュー・ボード)もしくはチーフアーキテクト により、 トレードオフの分析・検討を経て承認・却下されるべき。
※ARB: 組織横断的に構成される、アーキテクチャに関する意思決定機関。部門・企業を跨がり、経営層・パートナー企業・ステークホルダーから参加する。
設計原則 (Design principles)
一言で言うと、好ましい方法を示すためのガイドライン。 例えば、マイクロサービスのサービス間通信はパフォーマンスを高めるために非同期であること、という指針。 アーキテクチャの決定で、全ての条件・オプションをカバーするのは難しい。 代わりに、開発者が適切な選択をできるようにガイドラインを決めておくのが設計原則。
アーキテクトに求められる8つのこと
1. アーキテクチャの決定を作ること
アーキテクトとして、技術の選択ではなく、アーキテクチャの決定を作りチームを導くことが重要。 ただ、アーキテクチャ特性を維持するために、特定の技術を決定することもある。 アーキテクチャの決定については、19章で触れるよう。
2 継続的にアーキテクチャを分析すること
ビジネス・テクノロジーの変化に対して、過去に作られたアーキテクチャが現在もどれだけか、 構造に老朽化していないか分析すること。 また、テスト・リリースの環境についても考慮が必要。
3. 最新のトレンドから遅れをとらないこと
開発者が利用技術を追うことが必要なのに対し、アーキテクトは技術的・ビジネス的なトレンドを追うことが求められる。 アーキテクトの判断は、長期間影響し続け、一度決めたら容易に変更できないため、 間違った判断はよりクリティカルになる。
4. アーキテクチャの決定と設計原理が遵守されていることを確かめる
なんらかの理由によりアーキテクチャの決定に違反する実装が行われる可能性は0ではない。 例えば、パフォーマンスの問題から、プレゼンテーション層からDBアクセスしようとする開発者がいるかもしれない。 実装がアーキテクチャの決定に基づいているか確認することもアーキテクトの責務。
5. 多様なテクノロジー・フレームワーク・プラットフォーム・環境に触れること
深く知っているより、幅広く知識を持っていることが重要。 1のプロダクトのエキスパートであるよりも、10のプロダクトのpros/consを理解している方が アーキテクトにとって有益。
6. ビジネスドメインの知識を持つこと
アーキテクトがビジネスドメインについて理解していると、 ステークホルダーや経営陣とコミュニケーション取るのに有効に働く
7. 対人能力を持つこと
ジェラルド・ワインバーグが言う様に、"No Matter What They Tell You, It's a People Problem"、 つまり解決すべきは「人間が抱える問題」であり「技術的な問題解決」は手段にすぎない。 チームビルディング・ファシリテート力・リーダーシップなどのスキルを持つことはアーキテクトとして重要。
8. 企業の政治的風土を理解しナビゲートする
アーキテクトがどんなに素晴らしいアーキテクチャを設計しても、 それが現場で承認されなければ意味をなさない。 アーキテクトの決定は、コストや労力を伴う。 その時にプロジェクトマネージャ・ステークホルダー・開発者と交渉・説得することが求められる。 交渉力はアーキテクトに求められる能力の一つであり、23章で詳しく記されている。
今回はここまで。
英単語メモ
■elucidate (verb)
def: to make something clearer by explaining it more fully
synonym: explain
■hard-and-fast (adj)
def: definite and not to be changed, avoided, or ignored
■fool’s errand (noun)
def: a task that has no hope of being done successfully
■viable (adj)
def: that can be done; that will be successful
synonym: feasible
