ソフトウェアアーキテクチャというのは、プロセス（仕様やビジネス目標をアーキテクチャ設計にマッピングする、一連の戦略的な設計判断）であり、もの（さまざまなステークホルダーに向けて書かれた、プロセスによって生み出されるビューの集合）である。Michael Stal氏はソフトウェアアーキテクチャの定義をこう説明する。
ソフトウェア工学の教授で、Siemensで主幹エンジニアとして働いているStal氏によると、アーキテクチャの目的は実装の骨組みを作ることにあるという。これまで提案されてきたアーキテクチャの定義の多くは、コンポーネントの協調に注目していて、ぼんやりしているという。その代わりに、彼はアーキテクチャの特性について検討し、すぐれた特性を追加してリストを完成させるべきだと考えている。
すべてのソフトウェア集約型システムは、ソフトウェアアーキテクチャを示している。 時としてアドホックな判断に基づいたとしても、そこには常にアーキテクチャがある、と彼は主張する。求めているのは、関連する要求とリスクを明確に定義し、それらを優先順位付けることで導かれた、組織立ったアーキテクチャ設計だ。
アーキテクチャ品質には2種類ある。 ひとつは、品質属性によって要求される、目に見える振る舞いを定義した外的品質、もうひとつは、たとえば開発者による簡潔さや表現力といった特性の選択を定義した内的品質だ。
一貫性のあるガイドラインとツールがアーキテクチャ設計を導かなくてはならない。 これは高い品質を達成するために必要なものだ、と彼は言う。ガイドラインがあることは、内部品質を低下させるパターンやテクノロジによって、アーキテクチャが肥大化するのを避けるのに役立つ。
ものとしてのソフトウェアアーキテクチャは、設計判断を伝える手段である。 すべてのアーキテクチャ判断は、さまざまなステークホルダーの役割と責務に従い、明確化され、記述される必要がある。アーキテクチャは設計の土台であり、コードベースの初期の骨格を定義する。
ソフトウェアアーキテクチャは、問題ドメインとソリューションドメインの両方をカバーしなければならない。 Stal氏によると、これは多層設計がアーキテクチャでないことを暗に意味している。また、モノリシックな設計を避けるため、両方のドメインはサブドメインと、（組織ではなく）そのサブドメインによって導かれたソフトウェアアーキテクチャ活動組織に構成されるべきである、と彼は言う。Conwayの法則を参照。
Stal氏が記事の最後に挙げた4つの特性は、いかにアーキテクチャ設計がシステムのライフサイクル全体に及ぶか、いかにアーキテクチャ設計がテスト駆動アプローチに従う必要があるか、アーキテクチャはその環境から分離しておく必要があること、アーキテクチャはドメイン内のシステムのシステムを定義するかもしれないこと、について述べている。
InfoQとの対談において、Stefan Tilkov氏は、Stal氏の記事はすばらしいが、自分自身は必ずしもアーキテクチャを開発とは別のプロセスだと見ておらず、プロジェクトや組織のサイズに応じて考える、と述べている。彼はまた、アーキテクチャを「システムやシステムが目指す形の説明」だと見なす考え方に反し、アーキテクチャとは、それがどのように作られたかによらず「システムが持っているもの」だと述べている。